更高级别的测试

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

根据这个定义，即便完成了一次很是完美的模块测试，仍然不能保证已经找出了程序的全部错误。所以，要结束整个测试任务，必须进行其余形式的更深刻的测试，将这些新型形式的测试称为“更高级别的测试”

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

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

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

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

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

肯定软件开发周期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.独立的测试机构

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