第1个回答 2022-06-04
大家好，我是十一。
前面我们用了7篇介绍了5种测试用例设计方法，分别是 等价类划分法 、 边界值分析法 、 因果图法 、 判定表法 、 正交实验法 。5种方法各有利弊，根据我多年测试经验，综合使用多种设计方法比使用一种设计方法更有效，设计出来的测试用例覆盖率更高。另外，我们在设计测试用例的时候需要根据任务说明、需求说明、选定的测试策略以及自身因素来综合考虑具体选择哪些设计方法对当前的测试工作更有效！
接下来我为大家分享一个我认为合理有效的策略，该策略原型来源于梅尔斯的《软件测试的艺术》，根据我的经验做了稍微改变以及说明，供大家参考：
1.如果规格说明中包含输入条件组合的情况。
a.如果输入条件较少，应优先考虑因果图分析法；
b.如果输入条件较多，测试用例量过大，则应优先考虑正交实验法。
2.在任何情况下都应使用边界值分析方法。
边界值分析可以产生一系列补充的测试条件。事实上，我们在实际工作中边界值分析法是一个必不可少的重要的设计方法。但是缺点也显而易见，他不能担起测试用例设计的重任，必须与其他设计方法结合使用。
3.应为输入和输出确定有效和无效等价类。
a.等价类划分法可以同边界值分析法一样与其他测试用例结合使用，在必要情况下对上面确认的测试用例进行补充
b.另外，为其他设计方法提供技术支持，比如：在正交表构建过程中，我们确定因素水平就会用到等价类划分法和边界值分析法。
4.使用错误推测法补充更多的测试用例。
这个方法主要是根据规范、经验、常识等提取/增补测试用例。
5.针对上述测试用例集检查程序的逻辑结果。
此处会用到白盒测试用例设计方法，比如：判定覆盖、条件覆盖、判定/条件覆盖或者多重条件覆盖准则。（这些设计方法我们往后放放，暂时先忽略这部分）
要注意的是：使用上述策略并不可能发现所有的错误，但实践证明，这是一个有效的且合理的方案。
另外，关于测试用例还有一些点需要大家注意。
1.一个测试用例必须包含前置条件（背景）、测试输入、测试输出（期望结果）；
2.测试用例的粒度越小越好；粒度小的测试用例具有如下优点：
a测试用例的覆盖边界定义更清晰
b.测试结果对产品问题的指向性更强
c.测试用例间的耦合度最低，彼此之间的干扰也就最低
d.测试用例可读性比较高，信息含量越小，可读性越高
3.测试用例必须描述简洁清晰；
a.测试用例必须描述清晰。因为测试用例并不是给自己用的，而且测试用例大多数不是一次性的，所以我们必须要描述清晰，保证下次可用，他人可用。
b.测试用例必须简洁。通常，我们的工作周期都是有限的，且现在迭代更新速度越来越快，所以我们在编写测试用例的时候要注意在描述清晰的前提下，使用简洁的语言。
4.测试用例必须要持续更新；
a.需求大多数情况不是永恒不变的，所以我们在需求发生了改变的时候或者在测试时候发现测试用例描述不准确，不完全时就要及时修改测试用例，以保障测试用例的准确性；
b.测试用例都是人工设计出来的，设计者可能对需求的理解或者功能知识点的理解存在偏差，这样就会造成设计出来的测试用例不准确甚至不正确，这时候我们就需要有辨别是非的能力，且发现测试用例错误后要及时修订，以免造成二度损失/二度浪费。
5.测试用例集合必须是一个“完备”的集合，保证需求中的每个功能点都被覆盖到；这里要注意的是，测试用例要覆盖所有的功能点，而不是要做完全测试；
a. 完全测试： 对产品进行穷尽测试，把所有可能以及所有可能的组合均测试一遍
b. 覆盖所有的功能点： 要求覆盖需求中所有显性功能点（需求说明书提到的）、隐性功能点（没有提到，但是是约定俗成的或者常识性的点，比如我们在测试身份证号码的文本框时候，需求说明书可能只会写：合法允许保存，不合法文本框后提示非法用户，此处不会给出身份证号码具体什么是合法，什么是非法；那么这个点就是隐性功能点；再比如：密码框必须是密文，很多需求中也不会强调，但是我们在测试时候一定要设计这个点的测试用例），我们可以对所有数据通过等价类划分和边界值分析法提取出有代表性数据来做测试即可。
6.只有在深入理解软件需求、甚至架构设计后，我们才有可能设计出“完备”的测试用例集 ；因此，我们在设计测试用例之前一定要好好研究软件需求（对于初级测试人员来讲,大家只要做好这点即可）、架构设计、实际设计等。
7.先正常再异常，且一定要对异常进行测试。 这个很重要，很多人不是忽略了异常情况，就是次序混乱，导致测试用例遗漏或者重复。
8.最最重要的一点，我们在测试用例设计之前一定要先对需求进行测试！ 这个就是在需求分析、需求评审阶段测试一定要参与进去，测试参与到项目的时间越早越好。
好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！