当程序无法实现最终用户要求的合理功能时，就会发生一个软件错误。

根据这个定义，即使完成了一次非常完美的模块测试，仍然不能保证已经找出了程序的所有错误。因此，要结束整个测试任务，必须进行其他形式的更深入的测试，将这些新型形式的测试称为“更高级别的测试”

软件开发周期的文档说明：

●要求规格说明定义了为什么要开发程序

●目标定义了程序要做什么，以及做得怎样

●外部规格说明了程序对用户的准确表现

●与后续阶段相关的文档越来越详细地规定了程序是如何建立起来的

确定软件开发周期7个阶段包括了信息的沟通，理解和转换，以及大多数的软件错误都源于信息处理中的故障，现在有三个方法来预防和识别这些错误。

  1. 可以是软件开发过程更加精密，以防其中有很多错误。

  2. 引入独立的验证过程，在进入下一阶段前尽可能多地发现错误。

  3. 对不同的阶段的采用不同的测试方法，应该在开发和测试过程之间建立一对一的联系。

        ●模块测试的目的是是发现程序与规格说明之间的不一致

        ●功能测试的目的是为了说明程序未能符合其外部规格说明

        ●系统测试的目的是为了证明软件产品与其初始目标不一致

注：我们讨论功能测试，系统测试，验收测试和安装测试的过程。这里忽略了集成测试。因为集成测试往往不是作为独立测试步骤，而且在增量模块测试中，它是模块测试的隐含部分。

1.功能测试

功能测试是一个试图发现程序与其外部规格说明之间存在的不一致的过程。外部规格说明是一份最终的用户角度对程序行为的精确描述。

功能测试通常是一项黑盒操作，也就是说，依赖早期的模块测试过程来实现理想的白盒逻辑规则。

在功能测试时，需要对规格说明进行说明以获取测试用例集，如等价类划分，边界值分析，因果图分析和错误猜测法。最后应该牢记测试的目的是为了暴露程序的错误以及规格说明不一致之处，而不是为了证明程序符合外部说明。

2.系统测试

系统测试并不是测试整个系统或程序功能的过程。因为有了功能测试这样会显得多余。系统测试有着特定的目的：将系统或程序与其初始目标进行比较，给定这个目标后，隐含两方面的含义：

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

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

再寻找程序与其目标不一致的过程中，应重点注意那些设计外部规格说明所犯的错误。这也暗示了与功能测试不同，外部规格说明不能作为系统测试用例的基础，否则就破坏了系统测试的目标。另一方面，也不能用文档本身表示测试用例，因为这些文档并不包含对接口的准确描述。

克服方法：利用程序的用户文档，通过分析目标文档来设计系统测试，分析用户文档来阐明测试用例。

目标虽已阐明，但没有确认生成测试用例的方法，仅含一些含糊却有用的指南来指导如何编写测试用例，以证明程序与中的目标文档每一句都存在不一致性。事实上，设计好的系统测试用例比设计系统或程序需要更多的创造性。

2.1能力测试

最明显的系统测试类型是判断目标文档提及的每一项能力是否确实以实现，能力测试的语句是逐条检查目标文档，语句定义了一个“要做什么”，就判断该程序是否满足，这种类型的测试常常在不同的计算机情况下运行，又是人工对目标文档和用户文档进行比较久足够了。

2.2容量测试

是使程序经受大容量数据的检验，例如：编译器可能要处理编译规模非常大的源程序，编译器可能需要处理一个包含上千模块的程序等等。而操作系统的作业队列可能已经达到饱和容量。如果程序需要处理跨越不同的卷，则应产生足够的数据使程序从一个卷转到另一个中。故：容量测试的目的是为了证明程序不能处理目标文档中规定的数据容量

2.3强度测试

强度测试使程序承受高负载或强度的检验。所谓高强度就是指在短时间间隔内达到数据或操作的数量峰值。类似一名打字员，容量测试是判断打字员能否处理大篇幅的稿子，而强度测试是判断打字员能否达到每分钟50个单词的速度。

基于web的应用程序是最长接受强度测试的软件之一，在这里，我们需要确信是应用程序以及硬件能够处理一定容量 的并发用户，但有人会狡辩说，也许数百万人在同一时刻访问该站点，但这是不现实的，我们需要弄清用户群，然后设计一个强度测试，体现出可能访问站点的最大人群的情况。

2.4易用性测试

今天的软件系统，尤其那些广大的商业市场而设计的软件。通常有广泛的人为因素的研究。列举测试中的一些问题：

  1. 每个用户界面是否能够根据最终用户的智力，教育背景和环境进行了调整

  2. 程序输出是否有意义，不模糊且没有计算机杂乱信息

  3. 诊断错误（如错误信息）是否直接。

  4. 整体的用户界面是否在语法，惯例，语义，格式，风格和缩写方面展现出相当程度的概念完整性。

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

  6. 系统是否包含过多或不大可能遇到的选项？

  7. 对于所有的输入，系统是否返回了某些类型的及时的确认消息。

  8. 程序是否易用。如输入是否区分大小写这一点对用户来说是否清楚。此外，如果需要浏览一系列的菜单操作，返回主菜单的方法是否清楚。

2.5安全型测试

安全性测试是设计测试用例来破坏程序安全性检查的过程。举例来说，我们可以设计测试用例来规避操作系统的内存保护机制，破坏数据库管理系统的数据安全机制。设计这种测试用例的方法之一是研究类似系统中已知的安全问题，然后生成测试用例，尽量暴露被测系统存在的相似问题。

基于web的应用程序常常比绝大多数程序所需的安全测试级别更高，对于电子商务网站尤其如此，尽管已经有了足够多的技术（密码学）允许客户在因特网上安全地完成交易，但不能单纯地依赖技术的应用来确保安全。

2.6性能测试

很多软件都有特定的性能或效率目标，这些特性描述在特定负载和配置环境下程序响应时间和吞吐量，再一次强调，由于系统测试的目的是为了证明程序不能实现其目标，因此，应设计测试用例来说明程序不能满足其性能目标。

2.7存储测试

类似的，软件可能偶尔有存储目标，举例来说，可能描述了程序使用内存和辅存的容量，以及临时文件或溢出文件的大小，应用测试用例来证明这些存储目标没有得到满足。

2.8配置测试

诸如操作系统，等都支持多种硬件配置，包括I/O设备，通信线路，或不同的存储容量。通常可能配置的数量非常大，无法面面俱到，但至少有一种类型的设备，以最大最小的配置来测试程序。如软件本身的配置可忽略掉某些程序组件，或可运行在不同的计算机上，软件所有可能的配置都应测试到。

如今的软件都设计在可运行的多种操作系统环境下，因此如果设计此类程序，应该在该程序面向的所有操作环境中进行测试。

2.9兼容性/配置/转换测试

大多数开发软件并不是全新的，常常为了替换掉某些不完善的软件，往往有着特定的目标，设计现有系统的兼容以及现有系统的转换过程。针对这些目标测试程序，测试用例的目的是为了兼容性目标未被满足，转换过程为生效。将数据从一个系统转换到另一个系统时，应尽力发现这些错误。升级数据库管理就是一个例子。很多不同的方法测试这个过程，但这些方法都高度依赖于所用的数据库系统。

2.10安装测试

有些类型的软件系统安装过程非常复杂，测试安装过程是系统测试中一个重要的部分，对于包在软件安装包的自动安装系统而言，尤其重要，安装如果出现错误，可能会影响用户对软件的成功体验。

2.11可靠性测试

当然，所有类型的测试是为了提高软件的可靠性，但软件的目标中包含了对可靠性的特别描述，就必须专门设计可靠性测试。此种类型的软件证明或测试听起来很复杂，但是对于那些必须维持非常高的正常时间运行时间的系统。重要性日益增加。

2.12可恢复性测试

诸如操作系统，数据库管理系统，和远程处理系统等软件，通常有可恢复性目标，说明系统是如何从错误、硬件失效和数据错误中恢复过来，系统测试的一个目标是为了证明这些恢复机制不能够正常发挥作用。我们可以故意将程序错误步入某个系统中，判断系统是否可以从中恢复。诸如内存错误，I/O错误等硬件错误可以模拟。而如通信中的线路噪音或数据库中的无效指针等数据错误也可以模拟出来。以分析系统的反应。

2.13适用性测试

软件还可以有适用性或可维护性的目标，所有此类的目标必须测试到，这些功能可能定义了系统提供的辅助功能，包括存储转发程序或诊断程序，调试明显问题的平均时间、维护过程以及内部业务文档的质量等。

2.14文档测试

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

2.15过程测试

很多软件都是较大系统的组成部分，这些系统并不是完全自动化的，包含了很多人员操作过程。在系统测试中，必须对所有已经规定的人工过程，如系统操作员、数据库管理员或最终用户的操作过程进行测试。

数据库管理员必须记录备份和恢复数据库系统的操作过程。在可能的情况下，应由与数据库管理不相关的人来测试这些情况。然而，公司必须为充分测试这些过程提供所需资源，这些资源通常包括硬件和额外的软件许可证。

2.16系统测试的执行

系统测试执行的最关键的一个考虑是决定由谁来进行测试。（1）不能由程序员来进行系统测试；（2）在所有的测试阶段之中，这是唯一一个明确地不能由负责该程序开发的机构来进行测试

第一点基于的事实是，执行系统测试的人思考问题的方式必须与最终用户相同，显然，理想的测试小组应由几位专业的系统测试专家（以执行系统测试为职业）、一位或者两位最终的用户代表，一位人类工程学工程师以及该程序主要分析人或者设计者所组成。

第二点基于现实的是，大多数开发机构最关心的是让系统测试进行的尽可能顺利并且按时完成，而不会尽力去证明程序不能满足其目标。系统测试至少应由很少受开发机构左右的独立人群来执行，也是最经济的执行系统测试的形式。

3.验收测试

验收测试是将程序与最初的需求及最终用户当前的需要进行比较的过程。这是一种不寻常的测试用例，因为这通常是由程序的客户或最终用户来进行一般不认为软件开发机构的职责，由订购方（用户）来验收测试。将程序的实际操作与原始合同进行对照。与其他类型的测试一样，验收测试最好的方法是设计测试用例，尽力证明程序没有满足合同的要求。

4安装测试

它与其他测试过程不同，与设计过程中的任何阶段都没有联系，它的目的不是为了发现软件的错误，而是为了发现安装过程中出现的错误。

在安装软件系统期间会发生很多事件，简单概括下列事件

  1. 用户必须选择大量的选项。

  2. 必须分配并加载文件和库

  3. 必须进行有效的硬件配置

  4. 软件可能要求网络连通，以便与其他软件连接。

测试用例需要检查以确认已选的选项集合互不冲突，系统的所有部件全部存在，所有文件已经常见并包含必须内容。

5测试计划与控制

与大多数项目的情况一样，计划是管理测试过程中至关重要的一部分，一个良好的测试计划包括：

1）目标。必须定义每个测试阶段的目标

2）结束准则。必须制定准则以规定每个测试阶段何时该结束

3）进度。应何时设计、编写执行测试用例。

4）责任。对于每一个阶段，应当有谁来设计、编写验收测试用例，谁来修改发现软件错误。

5）测试用例库及标准

6）工具。包括由谁来开发或采购，如何使用工具以及何时需要使用工具。

7）计算机时间。计划每个测试所需要的时间

8）硬件设备。如特别需要的硬件设备或装备，则需一份计划来描述该需求，应该如何满足需求以及何时需要满足。

9）集成。测试计划的一部分是定义程序如何组装在一起的方法（如自顶向下的增量测试）。一个系统如果包含大的子系统或程序，可按增量方式组装在一起，例如自顶向下或者自底向上的方法，但这些构造块是程序或者子系统，而不是模块。如果是这种情况，就需要个系统集成计划。系统集成计划规定了系统集成的顺序。

10）跟踪步骤。必须跟踪进行中的方方面面，包括对错误易发模块的定位以及有关进度、资源和结束准则的进展估计。

11）调试步骤。必须制定上报已发生错误、跟踪错误修改进程以及将修改部分加入系统中去的机制。调试计划中还应包括进度、责任分工，工具以及计算机时间/资源等。

12）回归测试。是对程序功能改进或者修改之后进行，其目的是判断程序的改动是否引起了程序其他方面的退步。回归测试通常是执行测试用例中的某个子集。回归测试很重要，因为因为程序的改动和对错误的纠正要远比原来程序代码更容易出错。回归测试计划规定测试人员，测试方法和测试时间，它也是必须的。

6测试结束准则

1)用完了安排的测试时间后，测试便结束。

2)当执行完所有测试用例都为发现错误，测试便结束。

以上两条没有任何作用。不能保证测试用例的质量。

有三类较为有用的结束准则。

第一类：

测试用例来源于：

（1）满足多重条件覆盖准则

（2）规模块接口规格说明进行了边界值分析，产生的所有测试用例最终都是不成功的

在满足下列情况时规定测试功能结束

测试用例来源于

（1）因果图分析

（2）边界值分析

（3）错误猜测产生的所有测试用例均不成功

第二类：

（1）预测出程序中错误的总数量

（2）预测这些错误中有多大比例可能通过测试而发现

（3）预测这些错误中有多少是由各个设计阶段产生的，以及什么样的测试用例能够发现这些问题。

第三类结束准则表面上看上去很容易，其中涉及很多判断和直觉，需要在测试过程中记录单位时间发现错误的总量。假设某个程序正在进行功能测试，对于每周发现的错误数量都进行了记录，如果第七周的曲线仍然相对于前几周处于上升状态，那么这时候结束显然有些草率。此时应该继续进行功能测试。另一方面，如果程序中的错误一直处于下降阶段，并且第七周比前几周都低，此时也许就是最佳的行动结束功能测试并开始新的测试类型。当然也要考虑其他因素。

最佳结束准则可能是上述三种类型的结合

7.独立的测试机构

就公司的架构而言，而是部门用该尽可能远离开发部门。事实上，最理想的测试机构不应该是同一公司的一部分。而是雇佣独立的公司进行软件测试。