“好的”测试用例所具备的特点
- 整体完备性：好的测试用例是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求
- 等价类划分的准确性：每个等价类都能保证只要其中一个输入通过，其他输入也一定测试通过
- 等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别
三种最常用的测试用例设计方法
等价类划分方法
1 | 举例：学生信息系统的录入页面中“考试成绩”一项。 |
边界值分析方法
边界值分析是对等价类划分的补充，从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试。通常选取正好等于、刚刚大于、刚刚小于边界的值，作为测试数据。针对上面的学生信息系统的例子，选取的边界值数据应该包括：
-1
0
1
59
60
61
99
100
101
错误推测方法
错误推测方法是指基于对被测软件系统设计的理解、过去的经验和个人的自觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法，这里强调的是对被测软件的需求理解以及设计实现的细节把握，还有个人的能力。在企业的具体实践中，通常会建立起常见缺陷知识库，在测试设计过程中，依据缺陷知识库作为checklist，来优化测试设计。同时，还需要组织和鼓励测试工程师之间的技术和技术交流，减少测试设计中可能存在盲点
某些测试用例可能更依赖于过去发生过的问题，和测试人员的个人能力
举例：
web界面的GUI功能测试，需要对浏览器的缓存与否进行分支考虑
web service的API测试，需要考虑被测试的API所依赖的第三方API出错的情况下，所应有的处理逻辑
单元测试，需要考虑被测函数的输入参数为空的情况下，所应有的处理逻辑
测试基础架构比较成熟的大中型企业中，通常还会依据缺陷知识库，自动整理生成数据驱动测试中的测试输入数据
以面向终端用户的GUI测试来讨论测试用例设计的流程、注意事项
最核心的测试点是验证软件对需求的满足程度，这就要求QA人员对被测软件的需求有深入的理解。而理解需求最好的办法则是QA人员在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
朴素的测试用例设计流程
首先搞清楚每一个业务需求说对应的多个软件功能需求点 >> 分析出每个软件功能需求点对应的多个测试需求点 >> 针对每个测试需求点设计测试用例
回到测试用例本身的设计
需要注意的关键点：
- 从软件功能的需求触发，全面而细致地识别出测试需求，这会直接关系到测试用例的覆盖率
- 对于识别出的每个测试需求点，要综合运用等价类划分和边界值分析，和错误推测方法来全面而灵活地设计测试用例
有关用例设计的其他经验总结
作为测试人员，只有深入理解被测软件的架构，才能设计出更加有目标性的测试用例集合，去发现系统边界和系统集成中的潜在缺陷。
不可用开发代码的实现为依据设计测试用例或自动化测试代码，应该依据原始需求来设计。
需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据寻找遗漏的测试点。
更多的补充
测试用例本身也具有和被测试软件版本一一对应的版本属性，也即需要在软件需求变更等情况下，对测试用例进行更新和维护。同时测试用例的维护工作也是测试工作的重要组成部分，其花费的时间，也需要计入测试设计的整体考虑。
测试用例的语言描写，需要简洁而明确，在测试部门可以使用一些公有缩写约定来简化测试用例的书写，提高测试用例的开发速度。