我觉得是分阶段的,去不去听则需要自己的判断了。
1.小白阶段——可以去听一下 前提是自己有一定的认识,不然会听不明白
2.提升阶段——听一些最佳实践的案例。看别人是怎么解决问题的,对比一下自己实践方案,我想你会产生疑问并有所收获
3.重认识阶段——这个可能是圆桌会议的方式。
我建议你可以做一些自动化功能帮助自己减轻功能测试的工作量。后面由机会再申请资源来搞大的。
三国志 战略版?
我的做法是做个自动发版的功能,思路与 14 楼的类似,通过 commitize(提交代码规范) 来控制,然后在发版的时候,自动化为代码仓库打 tag,遍历提交信息与需求管理工具建立关系,生成发布日志。对比一下需求范围,一目了然。
PS:还可以用新的 tag 来构建服务,发布到预发布环境什么的。
在执行过程中,发现一定是以需求驱动才好做,比较合适敏捷开发的团队。
一转测试深如海,只能起辅助作用,功劳不大,背锅第一。
这个笔误有点大
个人建议选择 B
月薪 30+,30 岁的我 望尘莫及啊。。
触动心灵,说得太实在了。
盖楼灌水做分母
分享故事做分子
3 年上 W 很不错了
已入群
报名了 加群还没有通过
既然选择了,就奋力去做,头破血流后再回安逸窝吧~
再不拼一下,当老的时候可能会后悔,把如果常挂嘴边
嗯嗯,有机会交流一下
谢谢楼主的分享,说实话,我在看这本书的时候会犯困,抓不住作者的写作思路,在作者阐述各个设计方法以及举例,我看到有点晕(感觉自身功能测试实践还不够深刻,水平不行理解不了 好抓急),敢请楼主给一下建议,指点迷津
谢谢大佬
可以提供相关的 link 或者进一步说明吗?
请问请求 body 为复杂的 json,该平台是怎么支持的?
@heyniu 你好,我看到代码是 API >= 23 才能使用,请问 23 以下能兼容吗?
感谢分享,先学习学习
获取 view,获取当前值,如果当前不是想要的值,把 view 分成 5 等分,再根据目标值与当前值的比较上下滚动 1 等分,直至当前值与目标值相等位置