#读书笔记#《The Art of Software Testing》——第六章

《软件测试的艺术》——第6章：更高级别的测试

1.当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。即使完成了一次非常完美的模块测试，仍然不能保证已经找出了程序中的所有错误。因此，还必须进行其他形式的更深入的测试。即“更高级别的”测试。

2.假定大多数的软件错误都来源于信息处理中的故障，那么现在有三个补充的方法来预防或识别这些错误。首先，我们可以使软件开发的过程更加精密，以防其中出现很多错误；其次，在每个阶段结束时可以引入一个独立的验证过程，在下一个阶段之前尽可能多地发现问题。第三个方法是对不同的开发阶段采用不同的测试方法。也就是说，将每一个测试过程都重点针对一个特定的转换步骤，从而也针对一类具体的错误。如下图所示，测试周期就是模仿软件开发周期建立起来的，换言之，我们应该能够在开发和测试过程中建立起一对一的联系。

这种结构的好处是避免了没有效果的多余测试，并使我们不会遗漏掉大量的错误类型。

3.更高级别的测试方法最适用于软件产品（作为合同的结果或面向广泛应用而编写的程序，与做试验用的或仅供作者本人使用的程序有所不同）。同时，对更高级别测试的需求是与程序的规模一同增长的。这是由于在大型程序中，设计错误与编码错误之间的比率要比在小程序中的比率高很多。

4.系统测试并非定义为“功能测试之后进行的测试类型”，而是定义为一种特定类型的测试，关注于具体类型的错误，因此它很有可能与其他测试过程在时间上发生部分重叠。

    系统测试最容易被错误理解，也是最困难的测试过程。系统测试并非是测试整个系统或程序功能的过程，因为有了功能测试，这样会显得多余。系统测试有着特定的目的：将系统或程序与其初始目标进行比较。因此隐含两方面的含义：

（1）系统测试并不局限于系统。如果产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。

（2）根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。

      外部规格说明不能作为获得系统测试用例的基础，否则就破坏了系统测试的目标。然而另一方面，也不能利用目标文档本身来表示测试用例，因为这些文档不包含对程序外部接口的准确描述。所以，解决方法是利用程序的用户文档或书面材料。通过分析目标文档来设计系统测试，分析用户文档来阐明测试用例。

5.以下介绍15种测试用例，设计测试用例时应考虑全部的15种类型。

（1）能力测试（为避免与功能测试发生混淆使用“能力”一词）

        确定目标文档提及的每一项能力是否都确实已经实现。能力测试的过程是逐条语句地检查目标文档，当某条语句定义了一个“要做什么”，就判断程序是否满足。有时人工对目标和用户文档进行比较就足够了。

（2）容量测试

       容量测试是使程序经受大容量数据的检验。换言之，容量测试是为了证明程序不能处理目标文档中规定的数据容量。

       由于容量测试需要大量的资源，鉴于对机器和工时的考虑，不可进行过多的容量测试。当然每个程序应该至少进行几次容量测试。

（3）强度测试

       强度测试是程序承受高负载或强度的检验。注意避免和容量测试发生混淆：所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。举个例子，测试一名打字员，容量测试是判断打字员是否能处理大篇幅的稿子，而强度测试则是判断打字员是否能达到每分钟50个单词的速度。

      由于强度测试涉及时间因素，因此，它不适用于很多程序。强度测试适用于在可变负载下运行的程序，以及交互式程序、实时程序和过程控制程序。

      基于Web的应用程序是最常接受强度测试的软件之一。我们需要确定的是应用程序及硬件能够处理一定容量的并发用户。我们需要弄清用户群，然后设计一个强度测试，体现出可能访问站点的最大人群的情况。

     有时候在不可能发生的情况下的测试并不是无用的。如果在这些不可能发生的情况中检查出了错误，那么同样的错误也可能发生在现实强度稍低的环境中。

（4）易用性测试

      以下列举需要测试的人为因素或易用性的问题：

    1）每个用户界面是否都根据最终用户的智力、教育背景和环境要求而进行了调整？

    2）程序的输出是否有意义、不模糊且没有计算机的杂乱信息？

    3）错误诊断（如错误信息）是否直接，用户是否需要计算机学科的博士学位才能理解它们？避免“出现一个未知错误”、“程序遇到一个错误需要重新启动”这样无用的信息。

    4）整体的用户界面是否在语法、惯例、语义、格式、风格和缩写方面展现出了相当程度的概念完整性、基本的一致性和统一性？

    5）在准确性极为重要的环境中，输入中是否有足够的冗余信息？如网银系统可能会要求输入账号、用户名和PIN来验证访问账户信息的合法用户。

    6）系统是否包含过多或不太可能用到的选项？一个设计良好的软件可以向用户学习，并开始向不同的用户展示其经常访问的菜单项。

    7）对于所有的输入，系统是否返回了某些类型的即时确认信息？如在点击鼠标进行输入的环境中，被选项可以变换颜色。或者某个按钮对象可以显示凹进去或凸起的状态。

    8）程序是否易于使用？如输入是区分大小字符的这一点对用户来说是否清楚？此外，如果程序要求浏览一系列的菜单或操作，那么返回到主菜单、浏览到上一层或下一层的方法是否清楚？

 （5）安全性测试

       安全性测试是设计测试用例来突破程序安全检查的过程。涉及此种测试用例的方法之一是研究类似系统中已知的安全问题，然后生成测试用例，尽量暴露被测系统存在的相似问题。基于Web的应用程序常常比绝大多数程序所需的安全测试级别更高。

（6）性能测试

      很多软件都有特定的性能或效率目标，这些特性描述为在特定负载和配置环境下程序的响应时间和吞吐率。

（7）存储测试

      软件的存储目标可能是程序使用的内存和辅存的容量，以及临时文件或溢出文件的大小。应设计测试用例来证明这些存储目标有没有得到满足。

（8）配置测试

      通常可能的配置数量非常之大，以致于测试无法面面俱到。但是至少应该使用每一种类型的设备，以最大和最小的配置来测试程序。如果软件本身的配置可忽略掉某些程序组件，或可运行在不同计算机上，那么该软件所有可能的配置都应测试到。

       如今的很多软件都设计成可运行在多种操作系统下，因此如果测试此类程序，应该在该程序面向的所有操作系统环境中对其进行测试。对设计在Web浏览器里运行的程序，需要特别的注意，因为Web浏览器的种类繁多，并不是所有的浏览器都按同样方式运行。除此之外，即使是同一种Web浏览器，在不同的操作系统之下，运行方式也会不同。

（9）兼容性/配置/转换测试

       测试的目的是证明兼容性目标未被满足，转换过程并未生效。在将数据从一个系统转移到另一个系统时，应尽力发现错误。

（10）安装测试

       有些类型的软件系统安装过程非常复杂。测试安装过程是系统测试中的一个重要部分。对于包含在软件包中的自动安装系统而言，这尤其重要。因为用户对软件的第一次体验来自于安装软件的过程。如果这个过程进行的很糟糕，用户要么寻找其他的产品，要么对软件的有效性不抱太大信息。

（11）可靠性测试

       如果软件的目标中包含对可靠性的特别描述，就必须设计专门的可靠性测试。 

（12）可恢复性测试

      诸如操作系统、数据库管理系统和远程处理系统等软件通常都有可恢复性目标，说明系统从程序错误、硬件失效和数据错误中恢复过来。我们可以故意将程序错误置入某个系统中，判断系统是否可以从中恢复。

（13）适用性测试

（14）文档测试

       根据文档来确定系统测试用例的形式  。也就是说，一旦设计完成某个具体的测试情况，应该使用文档来作为编写实际测试用例的指南。同时用户文档应成为审查的对象，检查其正确性和清晰性。在文档中描述的任何范例应编成测试用例，并提交给程序。

（15）过程测试

       在系统测试中，必须对所有已规定的人工过程，如系统操作员、数据库管理员或最终用户的操作过程进行测试。

（16）安装测试

       发现在安装过程中出现的错误，在系统安装完成之后进行。除此之外，测试用例需要检查以确认已选的选项集合互不冲突，系统的所有部件全部存在，所有的文件已经创建并包含必需内容，硬件配置妥当等。