测试也辩论-测试用例颗粒度之粗细

这话题之前内部也探讨过。
今天参加淘宝的黑灯辩论，也是这个主题。

正方观点：写细点好。细致到从操作上不可再拆分的程度。好处：覆盖率高、可操作性强、便于工作量评估、便于跟踪、便于新同学学习理解，等等。

反方观点：写粗点好。突出测试思想框架，关注业务流程关注系统间交互，不纠缠页面细节，杜绝同类性重复用例。好处：养成有高度有宽度的测试思想，控制重复性细节性此类投入产出比低的投入。

以上，是我替他们大致总结的观点。

辩论本身并不是很精彩。但给我一个机会回炉自己的想法。

这本身是一个伪命题。用例的粗细粒度，很难有标准，更难说一定是细好还是粗好。就像我的博客上写的，测试是艺术。既然是艺术，哪有标准可言，只有是否适合口味的差别。所以这肯定是没有标准答案的。

但是，我们目前的实际做法中，肯定还是有倾向性的。我想批判一种倾向性的现象----对已知的浅显的测试需求，用例写到细的不能再细，而不花精力去思考未知的潜在的可能被遗漏的测试需求。这样下去，人慢慢就变成机器人了，只是反复的、一丝不苟的做那些已知的事情。线上故障会有，人的能力也不会上去。这个现象，暂且简称为机械主义。我想周遭是能看到这样的现象的。

我比较倾向的做法是，平时，对于已知部分，凭借经验尽可能抽象出公共可用的用例，而且要写的足够细致全面。项目中，同类测试需求，稍微加以修改就可以保证高覆盖率；多腾出一些时间来思考未知测试需求，构建新的测试用例。如果项目中的测试需求全部是新的，没有历史的可用，那么在时间进度压力下，我倾向于“重”测试分析“轻”测试用例，从分析层面/思想层面保证测试的覆盖（抓准业务流程规则/资金流转规则/系统间交互规则/非功能测试需求等），如对于资金流转，其实你画个图比你写一堆测试用例要有用简洁的多，虽然它可操作性不强，有可能会导致测试执行偏差，但我宁愿选择把这个风险靠人员的责任心去弥补，而不是担心人的责任心而要求用例一定要细致细致再细致。况且，互联网的测试跟传统软件行业的测试是有差别的，要做到快速响应，就不得不有取舍，有策略。