这是我购买的"极客时间"上的一套课程的笔记，总共52讲，定期对其中的内容做一笔记，巩固学习内容。
02 如何设计一个"好的"测试用例
1.好用例的必备特征
- 整体完备性：能够完全覆盖测试需求
- 等价类划分的准确性
- 等价类集合的完备性：保证所有可能的边界值和边界条件都已经正确识别
- 三种最常用的测试用例设计方法
- 等价类划分法
- 边界值分析法
- 错误推测法：
比较依赖测试人员对被测软件的需求理解，个人能力，以及经验。它和目前流行的"探索式测试"的基本思想和理念不谋而合，缺点是难于系统化，过度依赖个人能力。
因此，为了降低对个人能力的依赖，在中小企业中经常使用建立缺陷知识库的方式，而这种方式最简单的实践方法就是建立wiki页面。在中大型企业，则会使用该缺陷知识库作为数据驱动测试的输入，来自动生成部分的测试数据。
【心得】
作者所阐述的缺陷知识库这一条，个人觉得很有意义。虽然最终目的都是一致的，但是对于不同规模的企业，考虑到具体的投入产出比，会有不同的工程实践形式：建立wiki页面，或者作为自动生成测试数据的输入来源。
- 测试用例本身设计的关键点
- 从软件功能需求出发，全面地、无遗漏地识别出测试需求
- 对于识别出的每个测试需求点，综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例
- 用例设计的其他经验
- 深入理解被测软件的架构：测试工程师不能把整个系统看作一个大黑盒，必须对内部的架构有清楚的认识，比如数据库连接方式，数据库的读写分离，消息中间件Kafka的配置、缓存系统的层级分布、第三方系统的集成等。
- 深入理解被测软件的设计与实现细节：仅根据测试需求点设计用例，往往覆盖不到内部的处理流程、分支处理。同时，应该依据原始需求设计测试用例，而不要以开发代码的实现为依据设计。
- 引入需求覆盖率和代码覆盖率来衡量测试执行的完备性。
【心得】
作者阐述的深入理解被测软件的架构和设计实现细节部分，就需要测试人员自身拥有软件开发相关的知识，而这部分是不少测试人员所欠缺的。所以对于这部分人员，从作者这段话，也能够找到自身提升技能的一个方向，那就是多去了解软件开发的知识，对被测软件了解的越多，你就能测试的越好。
关于应该依据原始需求设计测试用例这一条。在实践中，测试人员不能盲目相信开发人员，因为开发人员对原始需求的理解可能就产生了错误。因此必须从原始需求出发。当然，这里我想根据自己的经验再补充一条，那就是，测试人员根据自身对被测软件系统的理解，有时候也需要指出原始需求本身的问题，因为提出需求的人员也可能犯错。
