软件测试用例设计时的颗粒度

很多工作了好几年的测试工程师初次听到“用例的颗粒度”的时候会感觉很惊讶，这是个什么东西？我们工作里用到过？其实在实际的工作当中已经有意无意的涉及到了“颗粒度”。比方说，用例编写的时候，可以写得很简单，也可以很复杂，就跟我们经常会听到的覆盖率差不多，简单的用例只需要指出要测试的内容、要测试产品的关键要素、要达到的质量目标、使用的测试方法等。而复杂的用例会指定每个逻辑分支的输入，期待的结果以及验证的方法，再具体到界面的操作顺序，测试的方法和工具、后台数据如何传输等等。

在上测试基础课单元测试的时候，学员们肯定都学过逻辑覆盖、路径覆盖、组合覆盖之类的。如果严格按照每个数据输入、每个条件、每个环境、每个逻辑都去设计用例的话那用例数量会非常的多，用例数量几乎是指数型上涨。虽然覆盖率得到了保证，项目出bug的风险也很小，但是面对严格的上线时间，海量的用例数量，是个人都会发怵：这么多用例，我7*24小时的测也测不完啊……除非有哪位大佬已经提前给你准备好了自动化脚本，就等你去点了，可惜并没有这样的大佬；可是如果用例写的很粗，到了执行的时候，有经验的测试工程师会发现bug，而没有经验的新人来测的时候，他就可能几十个用例都测不出一个bug，其实很多bug已经被他遗漏了，他只是呆板的按照用例写的去测，没发挥出自己的创造性思维。

那么问题来了，该怎么做才会让用例的“颗粒度”正好满足自己项目的需求呢？

1. 数据交换频繁的模块要写的细，就是那些优先级别高的模块“颗粒度”要细，因为那些代码很容易出大的bug，而对于那些简单的文本输入框、多选框的用例就没必要全路径覆盖的设计用例，浪费时间不说，还不容易测出bug；

2. 根据客户对项目的期望来决定，比方说一个刚开始的web项目的第一个release，时间三个月，只需要完成不同权限的用户登录到 页上显示的内容不同就可以了，这个时候就需要对登录和登录之后的验证来缩小“颗粒度”，尽量测到所能想到的各种方面，如果这么个简单的功能都出现了bug，那这个项目离黄也不远了；

3. 根据项目的时长来决定，最理想的情况当然是全覆盖测试，但是考虑到项目周期，长的几个月，短的一两周甚至几天，采取的策略就会不一样；

4. 根据测试的阶段来决定，通常SIT阶段都会尽量的细“颗粒度”，但是对一个UAT做细“颗粒度”测试就完全没必要了。

新的问题又来了，该怎样才能决定哪些模块需要粗”颗粒度“哪些需要细”颗粒度“呢？

1. 根据代码的行数来决定，通常代码量越大，逻辑就越复杂，数据交换就越频繁，出bug的几率也越高，对应的用例”颗粒度“应该尽可能的细；

2. 根据功能来决定，只接收前端数据并直传的模块就没必要细”颗粒度“；

3. 根据使用的频繁程度，比如一个 站上的<反馈>模块，就没必要细”颗粒度“的设计用例，因为用户一般很少用到；

所以如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。