设计测试用例的目的是发现 BUG?那测试人员不能发现 BUG 就没价值？有意思。

可以参考这个addict

学管理和更高的职位有关系吗？更高的职位是啥？？

看老板的背景和态度，但大多不靠谱。

#5 楼 @ruoya503 那还是 **dict 方便

a=11;b=22 是 str 类型？然后传给 function A？

#14 楼 @ivy520 可以啊，人生赢家啊

魔都买房？16 年年初买的？

已赞，等下篇

#23 楼 @kasi 哦，数据驱动模式，不错。

“用例自动生成” 比较感兴趣，能说下大概思路吗？

这才是正规路子，将琐碎的事交给 “自动化” 留出更多的时间专心做好 “本职工作”！

测试还是一个技术岗当然要会 code。至于受不受重视还要看自己！如果你是老板，你觉得什么是公司的核心力量？

很好，很强大。
测试只是一小个环节，多学点其他知识是很正常的。“活” 永远都是干不完的，关键是越能帮忙到他人个人价值也就越大。

好文

确实有充分的时间，每个环节都严谨到位，质量确实有了很大的保障。感觉适合养老

#7 楼 @quqing 确实 QA 和 QC 的概念现在很模糊了，有必要做个提醒。

#4 楼 @dongdong 完全不用写到交给第三方执行的，还不如直接测试外包呢。我是没见过写用例和执行用例的人是 2 个，基本都是 1 个人，我觉得更多是一个思路的提现和提醒的作用。

#7 楼 @CwXwWw

#5 楼 @CwXwWw 代码能力不一可以靠 code review，写多自然会提高。不会代码那就要学啊，测试也是技术岗位会代码是件很正常的事。不想学？ 呵呵，那就等着被淘汰吧！

自动化是必须要做的，特别是对需要快速迭代的业务系统。没有一个领导不喜欢提高效率的事，成本太大？我觉得那是测试代码写的太烂，抽象度不高等的问题（当然也有特例）

现在是第几轮啊？

先保证服务端，手机前端（app，H5，微信）不会很重的，主要业务逻辑都在后端（也有例外）。服务接口没问题了，基本就剩下兼容性和特殊场景覆盖了。

很早就有了组合测试法中的全对偶测试法