阿里、有赞都已经有了各自的实现方式,感兴趣的同学可以去他们的公众号上查阅相关文章
建议文章地址一并附下?
你这个问题写得不清不楚,要回答你还得问一堆问题,例如:
你当前用的是什么账号,有什么权限?
你要 get 的是怎样的项目,这个账号在里面有什么权限?
你看过哪些官方文档,尝试过哪些解决方案,得到了什么进一步的线索?
redmine 的服务器日志里又没有其它更详细的说明?
建议看下 让我们重拾一个沉重的话题:提问的艺术 / 技巧 ,补全一些信息,相信你在这个过程能有所收获,甚至就自行解决这个问题了。
教的不少了,要让你的学生练一下,看下是不是都学到位了。
PS:教了这么久,应该要出去面试或者实习练手下了吧,毕竟不是学校,不是期末考试冲刺下知识点就可以的,面试官可没那么好忽悠。想要有 bug 的练手项目,可以去开源项目找,有些刚开源不久还不是很完善的,可以找出不少 bug ,也可以通过 issue 反馈贡献下,一举两得。
个人觉得,这个是个伪命题,不同的场景两者的重要程度不一样。关键是你当前的工作更需要哪个,以及你自己个人的判断。
另外,从正文的说明里,只是说业务测试能力已经很成熟,但是技术能力偏弱
,并没有把测业务的 QA 价值贬得疑问不值吧,这个结论会不会主要是楼主的主观判断?
建议楼主更详细一点说下当前技术能力的大致水平是怎样,这样能帮助大家更好的给意见建议?
那你现在的设计应该可以满足了。不用太纠结 PO 。
需求覆盖率 这个有没有更具体的一些参考度量方式供参考?
很多时候需求并非想用例那样一条一条来的,大多是一个文档或者原型,按模块划分。文中提到的用例和需求映射关系,感觉好像不大好落地?
看了下正文,有几个问题建议楼主自己先思考下,否则可能换了个公司也帮不了你太多:
1、测试团队没有技术追求,产品质量不高,开发不愿修。这个是大部分团队都存在的问题,你在这种情况下,有做出过什么样的努力尝试改变?效果如何,自我总结的成功/失败原因是?如果有机会让你重来,什么是你会坚持的,什么是你会改进的?
2、沟通能力不强。这个问题对于测试人员来说是一个很明显的短板,很限制你的发展。你计划怎么去提高自己沟通方面的能力?(不要虚的,要可落地的。比如去尝试和更多人员沟通这个就很虚,1 个月内推动 xxx(一个以前推动不了的开发)修复一个 bug 并获得成功,这个就很落地,因为可以很明确知道你有没有做到)
3、倾向于走技术路线,那你接下来 2-3 年的职业规划是怎样的,每年技术上要达到什么样的程度,反推到你接下来一个月的技术学习计划是什么?每周输出什么结果?
从公司角度,需要的不是你的能力,而是你这个能力在实际项目中可以创造出来的价值。作为过来人,我理解你很期望得到有经验前辈的指导分享,但这个终归是可遇不可求的,更重要的是你自己的破局能力,比如通过参加沙龙活动结识人脉、和有经验的前辈沟通获取这方面的知识;比如通过读书 + 做笔记 + 业余项目实践,强化巩固你的技术能力。你的正文提出的都是现状,都是问题,但没看出你在解决问题方面的努力和思考,所以看不出你的价值。
和 bug 一样,发现它不产生价值,解决它才产生价值。
没有最好的设计,大部分情况只需要够用的设计。如果你觉得目前的设计没遇到什么大问题,沿用就好。
po 偏设计模式,主要应用在大量用例、协作写脚本比较多的场景,用尽量少的额外成本,解决这个场景下不好协作维护的问题。
从楼主的说明看,用例不多、协作也基本没有,不必强求。
先说结论: 不能!docker 解决的是应用部署步骤多、容易因环境差异引起功能差异的问题。如部署 jenkins 可以简化为一条命令。但你的并不是应用运行环境部署,而是开发环境 gui 软件安装。
重复部署问题: mac 下有 timemachine,windows 不大了解有没有这类工具,可以从学校电脑室怎么同步软件这个方向找下。
数据同步问题: 网盘或 github。代码建议 github
最简单的解决方案: 背个笔记本电脑,全程一台电脑
开源项目越来越多了,特别是一机多控,在兼容性测试里很实用。
比较好奇,一机多控,对于分辨率不同的机器,目前可以适配吗?
正文好像没介绍 自动生成 相关的功能?
基于代码去做测试,确实是更加有效。而且这块个人觉得不一定必须白盒,也可以灰盒,本质上应该是怎么提升代码本身的可测试性。
期待你后续的进一步分享。
PS:iOS 的智能 monkey ,可以考虑在社区推广下,找一个 app(如 TesterHome 的 iOS app )作为示例,介绍下它的用法?
没用过 marker ,简单看了下官方文档,貌似你的用例里缺少 marker 的装饰器?
官方例子:
也有过类似经历,确实是挺好的经验。大家应该是一起解决最初的问题,保证目标一致
在此也分享一个我平时用得比较多的经验,那就是和别人讲任何事情,都遵循 why->how->what 的顺序。先说明 why-背景,同时也是做这个事情的价值(即文章中提到的 X),然后说 how-想怎么做(接近文章中的 Y ),最后是 what-要做成什么样 。
如果用文章中的例子,类似于:
why:(前半脑补)因为目前系统 A 是不少系统的底层支撑,而近期出现的问题比较多,暴露出在这方面测试的不足。而由于它是遗留型系统,手工做全量测试既耗时也难以确保质量。(脑补结束)因此,需要为系统 A 建设接口自动化回归的能力。
how:从接口梳理时了解到,...(直接用那 2 个理由),因此希望以读接口接入工具 B,写接口另外通过其他工具编写用例覆盖
what:(同样脑补)以尽可能地低接入成本,低维护成本的方式,把这个系统 80% 的接口都提供接口自动化回归,覆盖系统 100% 的核心功能。这样以后这个系统就可以把回归测试时间缩减到 3 小时内了。
how 和 what 的顺序可以根据情况调整,但 why 记得放在第一位。
没问题。欢迎分享。
太好了,很赞!
我也把你的这段内容更新到正文里吧,感谢感谢!
也可以看看这个:
https://testerhome.com/topics/7978
这个是 16 年的帖子,里面用到的证书有效期只到 16 年 12 月。不大确定现在还能不能用。
还没,后面一直没有再去投入。。。
这个月抽时间把这个尾结掉。
不大明白 "用代码录制回放" 是什么意思?
Appium desktop、airtest 可以用更简便的方式生成代码,不知道是否符合你的要求?
可以看下 https://segmentfault.com/a/1190000004362731
正常来说浏览器会缓存的,只要手动输一遍,后面一定时间内就不用重复去输入了。
有个疑问,这里只提到了如何让 iOS 设备出现在设备列表中,好像没有提到如何使用 stf 控制 iOS 设备?
这是写到一半?
加精理由: 梳理总结很体系化,点赞
公司政策如此。
如果您觉得能力特别强,也欢迎投递,对于能力很强的我们会考虑适当放松学历上的要求。