读书笔记(十—)核心测试过程：计划，准备和完善

第11章
进入浴缸：测试系统覆盖率和质量
1.1 测试覆盖率分析技术简介
测试覆盖率（test coverage）
1. 结构性的：测试系统覆盖或测试的范围，正在测试的系统中的结构---代码，子系统或组件；
2. 行为性的：测试系统覆盖或测试的范围，正在测试的系统中的行为---对质量，操作，活动，功能和其他使用方面的风险。（构造一个矩阵的方法来测量这种覆盖率，矩阵的一个轴是测试用例，而另一个轴是质量风险。对于每一个测试用例和质量风险的交点，也即在矩阵体内的每一个单元，可以测试那个测试用例覆盖的质量风险）

1.2 Jamal 评估覆盖率

评估测试同在失效模式与影响分析中找到的每个质量风险之间的相关性。相关性估计分成四种类型：
0：没有覆盖率---这个测试用例并不引起任何与这种质量风险相关的行为，因而不大可能发现相关的失败；
1：机会性覆盖率---这个测试用例引起了与质量风险相关行为的少量例子，提供了对于相关的失败的机会性探索。
3：平衡的覆盖率---这个测试用例引起了与这种质量法风险相关的大量例子，并深入了地探索这些行为，提供了相关失败的广泛搜索。
9：全面覆盖率---这个测试用例引起了与这种质量风险相关的大量例子，并深入地探索了这些行为，提供了相关失败的广泛搜索。

1.3 认识一个好的测试系统设计和实现的过程
1.3.1 给质量评估提供好用的工具
测试系统必须是一套具有高性能的测试系统，真正的代表顾客和用户对质量的体验。测试执行过程必须按照与用户一样的方式使用待测试系统。测试系统应该使测试人员能够评估系统在所有的工作流程和使用场景下的行为的正确性，并使用所有重要的数据集。测试系统必须创建使测试人员对于质量的经验值与用户和顾客对于质量的经验值一致所必需的所有的测试。测试环境尽可能地与部署的环境或顾客的环境接近，我们能够发现环境，配置和兼容性问题。

1.3.2 高效率地实现，使用，重复使用和维护测试系统

测试数据（test data）
在测试用力中使用的输入数据的集合，可以使从用户界面，从存储文件，或从另一个通信系统输入。

测试工具（testing tools）
帮助人们执行测试任务的任何系统，例如设计，实现，验证，执行，测试或解释测试用例，测试数据或测试结果。工具可以使电子数据表，模板，数据库，用户开发的复杂的内部使用的公用程序，或可以采购的系统。工具可以使组合的和集成的。某些测试工具，如捕获/重放系统和代码覆盖工具，被设计为测试工具，而其他的工具，如调试器和脚本语言偶尔担当这个角色。

测试管理工具（testing management tools）
用来管理与测试系统相关的对象和测试系统产生的结果的工具。错误和测试跟踪系统是常见的范例，但是更先进的系统提供终端到终端的工具，用于测试的设计，实现和执行过程。这样的系统经常是与测试工具集成的，尽管这样做有时会限制对于测试工具支持的测试工具的有用性。

使用所必要的最少的时间和金钱来构建测试系统。
平衡在设计和实现方面的效率与在使用时的效率。
平衡初次实现时的效率和重复使用时的效率。
与效率紧密相关的是可靠性。一遍又一遍地运行相同的测试以获得可信的结果不是高效的。不能够在无人注意的情况下运行的自动化测试不是可靠的。紧密的耦合在一起的测试，也就是一个测试用例设置了下一个测试用例的数据和初始状态，经常受到串联失败的困扰。
测试低效率的潜在来源来自在测试用例之间和在测试用例共享的数据集之间的依赖性。

1.3.3 选择正确的技术
对于系统质量的风险决定了测试人员必须创建的测试条件。然后，测试条件决定了技术的选择。除了组织上和技术上的条件，有两个主要的考虑因素。一个考虑因素是与手工测试技术相对的测试自动化的程度。另一个考虑因素与测试时动态的还是静态的，结构性的还是行为性的，基于代码，数据还是需求等相关联的。
测试脚本（test script）
在手工测试中，如何执行一个或多个测试用例的指令，也叫做测试过程（test procedure）。在自动化测试中，这个术语指的是相应的由机器执行的指令。
1.3.4 防止错误
1.4 处理挑战
1.4.1 在一个测试用例中包括多少条件
效率好像隐含了将要在每个测试用例中最大化覆盖的测试条件的数量。然而将太多的条件组合到单个测试用例中会得到很多坏的结果。
1） 可能会在测试用例的一次操作中遇到多个错误，弄不清在系统状态中的哪些改变造成了失败。
2） 在多个失败中，可能有一个失败的影响是巨大的，以至于掩盖了其他不明显的错误，导致了倒下个测试周期活到发布中测试漏洞。
3） 可能存在一种失败停止了测试的进行，防止你执行能够发出后继失败的测试条件，这些失败有时候是同样的重要。
4） 一个具有很多条件的测试用例比一个只有较少条件的测试用例更有可能失败，如果其他的所有条件都是相同的，因此用测试用例失败或成功来表示的测试状态的汇总可能被描绘成一幅过度悲观的图像，这可能会损害测试组的可信度。
Smoke testing，sanity testing
对于一个提议的测试版本运行的测试，以确保它足够的稳定，可以进入当前活动的测试阶段进行测试。这种测试通常是总体测试集的一个子集，通常是自动化的，至少用一种好奇性的方法接触系统的每一个部分。好的smoke测试也将系统保持足够长的运行时间，以至于与可靠性和可用性相关的显著问题将会表现出来。

1.4.2 重新测试第三方软件
技术上，存在两种基本的测试挑战。首先，由第三方的测试可能不是与系统质量风险的评估和优先级相一致。
其次，由第三方执行的测试可能并不包括将这个组件集成到你的系统中。

政治挑战是第三方的供应商可能不想与你共享他们的测试结果和测试系统。

1.4.3 模糊定义的需求，使用配置和环境
如果有疑问就编写一份错误报告。

1.4.4 平衡覆盖率，进度和预算
11.5实现改进
1）如果有可能的话，评估你现有的测试系统的质量；
2）研究和应用在测试技术上取得的发展；
3）执行一个长期的计划；
4）采用合适的文档；
5）评估和协调测试人员的技能。