软件测试规范(2)

　　验证(Verification)，则试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。

　　确认与验证工作都属于软件测试。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节上发生了问题都可能在软件测试中表现出来。

　　1.4. 测试信息流

　　测试信息流如图1所示。测试过程需要三类输入：

　　软件配置：包括软件需求规格说明、软件设计规格说明、源代码等;

　　测试配置：包括测试计划、测试用例、测试驱动程序等;

　　测试工具：测试工具为测试的实施提供某种服务。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的工作台等。

　　测试之后，用实测结果与预期结果进行比较。如果发现出错的数据，就要进行调试。对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。

　　通过收集和分析测试结果数据，对软件建立可靠性模型。

　　如果测试发现不了错误，那么可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40倍到60倍。

　　.5. 测试与软件开发各阶段的关系

　　软件开发过程是一个自顶向下，逐步细化的过程，而测试过程则是依相反的顺序安排的 自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。参看图1.2，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试，检测和排除子系统(或系统)结构上的错误。随后再对照需求，进行确认测试。最后从系统全体出发，运行系统，看是否满足要求。

　　2. 程序错误分类

　　由于人们对错误有不同的理解和认识，所以目前还没有一个统一的错误分类方法。错误难于分类的原因，一方面是由于一个错误有许多征兆，因而它可以被归入不同的类。另一方面是因为把一个给定的错误归于哪一类，还与错误的来源和程序员的心理状态有关。

　　2.1 按错误的影响和后果分类

　　较小错误：只对系统输出有一些非实质性影响。如，输出的数据格式不合要求等。

　　中等错误：对系统的运行有局部影响。如输出的某些数据有错误或出现冗余。

　　较严重错误：系统的行为因错误的干扰而出现明显不合情理的现象。比如开出了0.00元的支票，系统的输出完全不可信赖。

　　严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。

　　非常严重的错误：系统运行中突然停机，其原因不明，无法软启动。

　　最严重的错误：系统运行导致环境破坏，或是造成事故，引起生命、财产的损失。

　　2.2 按错误的性质和范围分类

　　① 功能错误

　　规格说明错误：规格说明可能不完全，有二义性或自身矛盾。

　　功能错误：程序实现的功能与用户要求的不一致。这常常是由于规格说明中包含错误的功能、多余的功能或遗漏的功能所致。

　　测试错误：软件测试的设计与实施发生错误。软件测试自身也可能发生错误。

　　测试标准引起的错误：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。

　　② 系统错误

　　外部接口错误：外部接口指如终端、打印机、通信线路等系统与外部环境通信的手段。所有外部接口之间，人与机器之间的通信都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外还包括对输入/输出格式错误理解，对输入数据不合理的容错等等。

　　内部接口错误：内部接口指程序之间的联系。它所发生的错误与程序内实现的细节有关。例如，设计协议错、输入/输出格式错、数据保护不可靠、子程序访问错等。

　　硬件结构错误：这类错误在于不能正确地理解硬件如何工作。例如，忽视或错误地理解分页机构、位址生成、信道容量、I/O指令、中断处理、设备初始化和启动等而导致的出错。

原文转自：http://www.uml.org.cn/Test/201511262.asp