软件测试基础知识（13）测试用例方法总结

一.测试用例方法总结

通常，在确定测试方法时，应遵循以下原则：根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多得程序错误。要在测试过度和测试不足中找平衡点

二.测试方法选择
通常在确定测试方法时，有以下几条参考原则
1.拿到一个测试任务时，先关注它的主要功能和业务流程，业务逻辑是否正确实现，考虑使用场景法
2.需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试
3.在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强
4.如果程序的功能说明中含有输入条件的组合情况，则一开始就应该考虑选用因果图和判定表法
5.对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试用例来获得最大的测试覆盖率）
6.对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应该再补充更多的测试用例
7.采用错误推测法再追加测试用例——依靠工程师的经验和智慧

三.测试用例的力度

测试用例可以写的很简单也可以很复杂
测试用例写的过于复杂或详细，会带来两个问题：一个是效率问题，另一个时维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

大多数的测试团队编写的测试用例的力度介于两者之间

**测试用例的本质 **
测试用例的设计本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

基于需求的测试用例设计
基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
- 要把测试用例当成活的文档，因为需求是活的，善变的。因此在设计测试用例方面应该要把敏捷方法的“及时响应变更比遵循计划更有价值”这一原则体现出来。
不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例。

**测试用例评审 **

同行评审

• 测试用例的检查方式有很多，同行评审是其中最敏捷的一种。
• “个体和交互比过程和工具更有价值”，这强调了测试用例设计者之间的思想碰撞，通过探讨、协作来完成测试用例的设计。

用户评审
“顾客的协作比合同谈判更有价值”。

如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场调查人员或相关领域专家）；
如果测试被定义为对开发提供帮助和支持，那么顾客就是程序员。