[开发测试]精读-软件测试的艺术之测试心理和经济

本文是关于精读书籍《软件测试的艺术》的一些学习笔记和分享

本书共有九章包括测试思想（心理，经济），代码检查，测试用例设计，模块测试，更高级别的测试，调试，极限测试和因特尔应用系统的测试。

本文是关于测试的经济和心理一些笔记和心得。

一、心理：

在理想情况下，测试人员是想要测试程序的所有可能的执行情况。然而，在大多数的情况下，这几乎是不可能的。程序可能的输入与输出组合可达到数百种甚至数千种，对所有可能情况的设计测试用例是不符实际的，会浪费大量的时间和人力资源。所以测试人员的态度（愿景）可能比实际测试过程本身更加重要。

那测试人员的对于测试的态度应该是什么哪？

我们了解测试的定义：

“测试是为了发现错误而执行程序的过程”

测试是为了发现错误，来改正错误，从而增加了程序的价值，提高了程序的可靠性或质量。所以，测试人员不能抱着证明程序能够正确运行而去测试程序，而是从一开始就假设程序中隐藏着错误，然后测试程序，发现尽可能多的错误。这样，我们在设计测试数据时就会有更多的发现问题。

在这里我想先引用一个小故事：

"德国人在对客运飞机进行检测，会用扳手或者锤子对客运飞机内部的薄弱地方例如座椅连接处等进行一些破坏式的检测。只有这些通过这些破坏式的检测，飞机才可以最终被验收，这就使飞机的质量得到了很大的提高"

软件测试也是一种破坏性的过程，甚至是一种‘施虐’的过程。所以，我们认为能发现新错误的测试用例我们认识值得设计的，是‘成功’，而‘不成功’的测试用例就只会使程序输出正确的结果，但不能发现任何错误。

我们可以类比病人去医院看医生，如果在经过一系列的检测，医生没有检测出问题，这无疑是一次失败的检测，但如果检测出病灶，这就是一次成功的，医生可以展开适当的治疗。

我们在前面所说，一个软件几乎不可能没有错误，所以我们是通过软件测试来建立对软件的‘信心’。在测试的过程中，我们不能只关注‘软件做了其应该做的’，还应该注意‘软件不应该做但是做了’

总结一下：软件测试更适宜被视为试图发现程序中的错误的破坏性的过程。我们要通过软件测试来建立某种程度的信心：软件做了其应该做的，未做其不应做的。

二、经济：

发现程序中的所有错误是不切实际的，所以我平衡经济和测试结果之间的平衡。为了应对这种挑战，我们需要在测试之间建立某些策略：黑盒测试和白盒测试。

黑盒测试

黑盒测试将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在程序不按其规范正确运行的环境条件。换句话说，不在乎程序内部如何运行，在乎最后的结果是不是想要的。

主要运用的就是‘穷举输入测试’，将所有可能的输入条件都作为测试用例。但是对于一个稍大些程序，穷举所有的可能是不现实的，所以我们的目标是通过有限的测试用例，最大限度地提高发现问题的数量。

这里我们可以引入一个需求覆盖率的概念：

需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。

我们通常采用 ALM，Doors 和 TestLink 等需求管理工具来建立需求和测试的对应关系，并以此计算测试覆盖率。

白盒测试

白盒测试：允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查，会关注程序内部的运行。

主要运用的是‘穷举路径测试’，即测试用例执行了程序中所有可能的控制流路径。。但是，同样针对一个稍大的程序，程序中的不同逻辑数量可能是一个天文数字并且逻辑路径可能会十分复杂，所以穷举所有路径可能也是不切实际的。

这里我们可以引用代码覆盖率的概念：

代码覆盖率就是至少被执行了一次的条目数占整个条目数的百分比。通常包括三个判定：?????????????????? ? ?

• ?????????条件覆盖：用以度量代码中每个判断的取真分支和取假分支是否各被覆盖至少各一次。
• ????????判定覆盖率：条件覆盖，是指判定中的每个条件的可能取值至少满足一次
• ?????????行覆盖率：已经被执行到的语句占总可执行语句的百分比

对于代码覆盖率，各个语言都有自己的工具。最常见的java，就有一个工具叫 JaCoCo．Coverage是一个用来测试代码覆盖率的 Python 第三方库。业界主流开源js覆盖率工具有ScriptCover，Istanbul和JSCove.

测试指导原则：

1. 测试用例一个必需部分是预期输出或结果进行定义
2. 程序员应当避免测试自己编写的程序
3. 编写软件的组织不应当测试自己编写的软件
4. 应当彻底检查每个测试的执行结果
5. 测试用例的编写不仅应当根据有效和预测到的输入情况，也应当根据无效和未预料到的输入情况
6. 检查程序是否“做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
7. 应避免测试用例用后弃用，除非程序软件本事就是一个一次性软件
8. 计划测试工作时不应默许假定不会发现错误
9. 程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
10. 软件测试是一项极富创造性，极具智力挑战性的工作