一份好的测试用例能够发现至今尚未发现的问题。

一份成功的测试用例能够发现软件中未发现的问题。

软件并非完美无缺。

如何设计用例才能有效度量软件产品质量？

成为软件测试人员的一项必备技能。

相信游行在测试界的朋友，一定遇到这类情况：

第一，编写测试用例到底颗粒度越小越好，还越粗越好？

第二，为什么有些人同一个功能写了30条用例，有些人只写了10条用例？

第三，测试用例条数越多软件产品质量就越好？

第四，测试人员的专业性与测试用例覆盖率有效性有关吗？

我相信上述这些问题都有困扰过大家，甚至很多同学平时编写测试用例就按照自己的思考埋头去写。

如果公司给的时间多我就写详细一点，如果给的测试时间少，我就写粗一点。

实际上这两种写法都存在一定的局限性。

无论我目前是公司的软件产品质量管理者角色，还是普通测试工程师角色，我认为有必要搞清楚测试用例的覆盖率和有效性是体现软件测试人员的专业性问题。

关于用例设计的粗细程度，没有任何的规范依据。

如果项目时间有限，建议大家根据需求的优先级来重点覆盖用例设计的优先级，将需求中的重要逻辑业务功能覆盖到。

如果公司给的项目时间宽裕，建议大家将测试用例写得更精细化一点。

测试用例的有效性和覆盖率与用例设计的精细程度关系不大。

更重要的应关注程序代码业务逻辑复杂的用例应重点进行覆盖，这比写一堆无效的测试用例数量更重要。

设计测试用例并不是条数越多越好。

有些简单的功能你可能一下子可以产生30条用例。

而有些复杂的功能你可能一天就写3-5条。

用例的复杂度与需求的逻辑复杂度有关系，如果用用例的条数来衡量测试人员的专业性，我认为这是很不合理的。

毕竟不同的功能点测试业务的难度不同。

简单的功能花的时间少，复杂的功能花的时间多，设计用例同样花的时间更多。

甚至很多测试人员，会写一堆毫无意义重复的用例来充数，这类用例基本不花时间，写一个其它就是复制、粘贴、修改即可合用，一天写个70-100条不为过。

再者项目有部分业务较稳定，可抽取部分共性化的功能用来做回归测试。

这也节约了用例的重复利用率，同样节约了用例设计的时间。

到底如何辨别用例设计颗粒度的大小呢？

根据需求功能的优先级，需要功能优先级越高，说明功能越重要，需要将用例设计得更细些，覆盖更全面些。

如果功能优先级较低，设计用例的颗粒度可粗些，因为这块功能对用户来说不是特别常用，再者不存在业务逻辑关联性问题，风险相对较少，否则其它需求功能点用例设计一定要越细越好，多站在用户角度考虑应用场景。

这样软件产品的质量才能更有保障。

我为大家准备了一份软件测试用例颗粒度规范说明文档，有兴趣的朋友可@IT测试之美领取！

更多关于软件测试的干货内容，请查看往期文章。