测试理论（四-4）功能测试

6.1 功能测试

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

        功能测试通常是一项黑盒测试。

        在进行功能测试时，需要对规格说明进行分析以提炼测试用例，具体方法可参考等价类划分、边界值分析、因果图分析法和错误猜测法。

6.2 系统测试

        系统测试有着特定的目的：将系统或程序与起初始目标进行比较。

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

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

系统测试用例的分类：

6.2.1 能力测试

最基本的系统测试类型是判断目标文档提及的每一项能力是否都确实已经实现。

6.2.2 容量测试

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

6.2.3 强度测试

强度测试使程序承受高负载或强度的检验。高强度是指在很短的时间内达到的数据或操作的数量峰值。

6.2.4 可用性测试

又叫用户体验测试。

6.2.5 安全性测试

设计测试用例来突破程序安全检查。方法之一是研究类似系统中已知的安全问题，生成测试用例。

6.2.6 性能测试

性能可描述为特定负载和配置环境下程序的相应时间和吞吐率。

6.2.7 存储测试

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

6.2.8 配置测试

某些程序支持多种硬件配置，，应至少遍历最大和最小配置来测试应用程序。

6.2.9 兼容性测试

6.2.10 安装测试

软件安装测试。

6.2.11 可靠性测试

有点类似稳定性测试，指系统长时间运行下正常运行时间占比达到目标值。

6.2.12 可恢复性测试

说明系统如何从程序错误、硬件失效和数据错误中恢复过来。系统设计目标之一是使平均恢复时间（MTTR）最小。

6.2.13 服务/可维护性测试

软件有服务或可维护性的目标，所有此类目标都必须测试到。

6.2.14 文档测试

系统测试也需要检查用户文档的正确性。  

6.2.15 过程测试

对大型系统的人工操作部分进行测试。

6.2.16 系统测试的执行

参考第二章的测试人员分配

6.3 验收测试

6.4 安装测试

在安装软件系统期间会发生很多事件。作为示例的简短列表包括了下列事件:
1.用户必须选择大量的选项。
2.必须分配并加载文件和库
3.必须进行有效的硬件配置

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

安装测试应由生产软件系统的机构来设计,作为软件的一部分来发布,在系统安装完成之后进行。除此之外,测试用例需要检査以确认已选的选项集合互不冲突,系统的所有部件全部存在,所有的文件已经创建并包含必需内容,硬件配置妥当等。

6.5 测试的计划于控制

1.目标。必须定义每个测试阶段的目标。
2.结束准则。必须制定准则以规定每个测试阶段何时可以结束。
3.进度。每个阶段都须有时间表。应指出何时设计、编写和执行测试用例某些软件技术,如极限编程要求在程序编码开始之
前就设计测试用例和单元测试
4.责任。对于每一个阶段,应当确定谁来设计、编写和验证测试用例,来修改发现的软件错误。由于在大型项目中讨论特定的测试结果是否代表错误时,有可能出现争端,因此还需要确定一名仲裁者。
5.测试用例库及标准。在大型项目中,用于确定、编写以及存储测试用例的系统方法是必须的
6.工具。必须确定需要使用的测试工具,包括计划由谁来开发或采购、如何使用工具以及何时需要使用工具
7.计算机时间。计划每个测试阶段所需的计算机时间,包括用来编译应用程序的服务器(如果需要的话)、用来进行安装测试所需的桌面计算机、用来运行基于Web应用程序的Web服务器、联网的设备(如果需要的话)等
8.硬件配置。如果需要特别的硬件配置或设备,则需要一份计划来描述该需求,该如何满足需求以及何时需要满足
9.集成。测试计划的一部分是定义程序如何组装在一起的方法(例如自顶向下的增量测试)。一个系统如果包含大的子系统或程序,可按增量的方式组装在一起,例如可以使用自顶向下或自底向上的方法,但是这些构造块是程序或子系统,而不是模块。如果是这种情况,就需要一个系统集成计划。系统集成计划规定了系统集成的顺序、系统每个版本的功能以及编写“脚手架”代码以模拟不存在的部件的职责分工。
10.跟踪步骤。必须跟踪测试进行中的方方面面,包括对错误易发模块的定位以及有关进度、资源和结束准则的进展估计
11.调试步骤。必须制定上报已发现错误、跟踪错误修改进程以及将修改部分加入系统中去的机制。调试计划中还应包括进度、责任分工、工具以及计算机时间/资源等。

12.回归测试。回归测试在对程序作了功能改进或进行了修改之后进行,其目的是判断程序的改动是否引起了程序其他方面的退步。回归测试通常重新执行测试用例中的某个子集。回归测试很重要,因为对程序的改动和对错误的纠正要比原来的程序代码更容易出错(与报纸排版错误很相似,这些错误通常由于最后所做的编辑改动而引|起的,而不是修改先前版本而引起的)。回归测试计划规定了测试人员、测试方法和测试时于间,它也是必须的。

6.6 测试结束准则

 判断测试停止的准则最常见的两个准则：

（1）用完了安排测试的时间后，测试便结束；

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

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

第一类，测试用例来源于（1）满足多重条件覆盖准则，（2）对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。

在以下原则上，可以结束功能测试：

测试用例来源于（1）因果图分析（2）边界值分析（3）错误猜测，产生的所有测试用例最终都是不成功的。

第二类，是以确切的数量来描述测试结束的条件。

缺点：需要做一下预测：

1.预测出程序中的错误总数量；

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

3.预测这些错误中油多少是有各个设计阶段产生的，一级在什么样的测试阶段能够发现问题。

根据经验表明，大约40%的错误是由编码和逻辑设计错误，剩下的错误则产生于早去的设计阶段。

第三类准则需要在测试过程中记录每单位时间内发现的错误数量。 

6.7 独立的测试机构

设立或雇佣独立的公司进行软件测试。