信息系统综合测试与管理

Posted 2022-12-14 左直拳

本文包括软件测试模型、测试技术和测试管理。

一、测试基础

1、软件测试模型

所谓测试模型（Test Model），是测试和测试对象的基本特征、基本关系的抽象。

1）V模型

V模型实际是软件开发瀑布模型的变种，它反映了测试活动与分析、设计的关系。V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别。

如图所示，左边为开发过程各阶段，右边为对应的测试阶段。V模型，优点是在开发阶段，测试工程师就可以介入，准备相应的测试工作，比如审查需求分析、编写测试计划等；缺点是仍然要在开发完成后才进入测试阶段，导致问题一直拖到后期才被发现。

V模型失败的原因是把系统开发过程划分为具有固定边界的不同阶段，导致测试人员很难及时采集测试所需信息，以及综合不同阶段信息加以总体考虑。

2）W模型

W模型是为了解决V模型的缺陷而演化出来的模型。解决V模型在软件开发编码完成后才介入测试工作，导致一些在需求和设计中的问题在后期验收测试中才被发现，不能体现“尽早地和不断地进行软件测试”的基本原则的问题。

W模型认为，测试工作应对应软件各开发阶段同步进行，由两个V字型模型组成，分别代表测试与开发过程，即一个测试V，一个开发V。

W模型强调测试阶段和开发阶段是同步进行的，而且测试的对象不仅仅是程序，还包括需求分析、概要设计和详细设计，测试伴随着整个软件开发周期。W模型有利于尽早地全面发现问题，减少总体测试时间，加快项目进度。

W模型的局限性，是与V模型一样，将软件的开发视为需求、设计、编码等一系列串行的活动，测试和开发仍然保持一种线性的前后关系，严格遵守先后顺序，无法支持迭代的开发模型，未能应付复杂多变的情况。对于开发过程中，需要事后补充文档，或者根本没有文档的情况，W模型中的开发和测试人员面临同样的困扰。

3）H模型

V模型和W模型都存在一定的局限性，它们都把软件的开发过程视为需求、设计、编码等一系列串行的活动，但实际上这些活动之间存在相互牵制的关系，并且大部分时间内都可以交叉进行。严格的阶段划分只是一种理想的状态。事实上，软件项目不可能等需求非常明确才开始进行，一般最初需求评审通过后，开发工作随即进行，边做边改。相应地，测试也不存在严格的次序关系，还会有反复触发、迭代和增量的关系。这一点，V模型和W模型都没有很好地体现出来。

倚天不出，谁与争锋？有专家提出了H模型。H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

H模型揭示了软件测试模型是一个独立的流程，贯穿于整个软件产品的周期，与其他流程并发地进行。优点是将测试从开发中独立出来，有利于研究更新的测试技术，可同时对多个项目进行测试，与项目的耦合程度较低，独立性强；但也因此对系统认识不够深入，影响测试质量和效率。

4）X模型

X模型诟病V模型无法引导项目的全部过程，认为一个模型不应该与实际脱节，是对V模型的纠正和改进。X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接和集成最终合成可执行的程序。

左边：针对单独程序片段进行相互分离的编码和测试，然后频繁交接，最终集成为可执行程序，之后又是一轮测试（系统测试？），通过后封装，提交给用户，或者作为更大规模和范围内集成的一部分。多根曲线表示变更可以在各个部分发生。

优点，强调单元测试及集成测试，测试更贴近实际，修复缺陷不受项目组人员限制（就是有一定的独立性？）；
缺点，测试不够全面，没有需求测试、验收测试。

5）前置测试模型

将测试和开发紧密结合，提供一种轻松的方式，可以使项目加快速度。

前置测试将测试执行和开发结合在一起，并在开发阶段以”编码-测试-编码-测试“的方式来体现。当程序片段一旦编写完成，就会立即进行测试。一般是单元测试，也有可能是集成测试或其他测试。这是发现错误最经济的方式。

前置测试将测试分为技术测试和验收测试两个独立的进程。技术测试针对代码的正确性，验收测试验证需求的满足性，另外还可能包括负载测试、安全性测试、可用性测试等。

6）各测试模型比较

这是我根据个人理解的总结，可能有误。

V模型、W模型、H模型、X模型、前置模型，都以V模型作为参照，作出各自的改进。V模型在测试种的地位，就相当于开发模型中的瀑布模型，绕不过去，是基础。

V模型的特点，是开发在先，测试在后，阶段分明，缺点显而易见，开发与测试脱节；
W模型，是开发一段，测试一段，如影随形。但仍然是阶段分明。
H模型，将测试完全独立出来，按照自己的节奏，想测就测，但测试跟系统关系不够密切，有点貌合神离的味道。
X模型，针对开发阶段进一步划分，划分成一个个片段，加大测试的频率，最后再集成测试、封装成完整系统进行交付。貌似太琐碎了，并且只侧重测试开发，对需求分析、系统验收的测试不够，缺乏总体性。真是明察秋毫，不见舆薪。
前置模型，将测试分为技术测试和验收测试，各自独立，完美。

2、软件测试类型

1）分类

1、按开发阶段：单元测试、集成测试、系统测试、验收测试
2、按测试实施组织：α测试（开发方）、β测试（用户方）、第三方测试
3、按测试执行方式：静态测试、动态测试
4、按是否查看代码（或测试技术）：黑盒测试、白盒测试、灰盒测试
5、按是否手工执行划分：手工测试、自动化测试
6、按测试对象划分：性能测试、安全测试、兼容性测试、文档测试、易用性测试（用户体验测试）、业务测试、界面测试、安装测试
或进一步细分，其中质量属性测试有：容错性测试、兼容性测试、安全性测试、可靠性测试、维护性测试、可移植性测试、易用性测试。
7、按测试地域划分：本地化测试、国际化测试

负载测试压力测试强度测试稳定性测试

2）名词解释

（1）集成测试
又称为组装测试、联合测试、子系统测试或部件测试。

分为
非增值式：先分别测试每个模块，然后结合在一起测试；
增值式：又称为渐增式组装，首先一个个模块测试，然后逐步组装，边组装边测试

非增值式简单，资源利用率高，缺点是成本高，难以定位错误；增值式能较早发现和定位问题，缺点是测试周期长，资源利用不够充分。

（2）系统测试
对已集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要素。

（3）验收测试
完成了功能测试和系统测试之后，产品发布之前所进行的软件测试活动，是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试。

【验收测试标准】
完全执行了验收测试计划中的每个测试用例
在验收测试中发现的错误已经得到修改并且通过了测试
完成软件验收测试报告

【注意事项】
必须编写正式的、单独的验收测试计划
验收测试必须在实际的用户运行环境中运行
由用户和测试部门共同执行比较好。如果是公司自我开发产品，由测试部门联合多个部门共同进行。

（4）灰盒测试
介乎于白盒测试和黑盒测试之间。既关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征、事件、标志来判断内部的运行状态。灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序，并采集程序路径执行信息，和外部用户接口结果的测试技术。

黑盒测试只需关心整个软件系统的边界，灰盒测试需要关心模块之间的交互，白盒测试需要了解模块内部的实现细节。

二、软件测试技术

1、黑盒测试法

黑盒测试也称为功能测试，通过测试来检测每个功能是否都能正常使用。测试时，把被测试程序视为一个不能打开的黑盒子，在完全不考虑内部结构和内部特性的情况下进行测试。旨在检查程序功能是否能按照需求规格说明书的规定正常使用，输入输出是否正确等。

黑盒测试有两种基本方法：通过测试和失败测试。通过测试确认软件能做什么；失败测试则是通过搞垮软件来观察软件的缺陷（比如压力测试？）

黑盒测试的优点是简单、方便，缺点是覆盖率低，自动化测试复用率不够。

黑盒测试不可能采用穷举法输入测试，测试用例是将测试行为具体量化的方法之一。

黑盒测试的测试用例设计方法主要有：
1）测试区域确定法
2）数据覆盖法
3）逻辑推断法
4）业务路径覆盖法

2、白盒测试法

白盒测试又称为结构测试或逻辑驱动测试。

白盒测试将测试对象看作一个透明的盒子，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按照预定要求正确工作，而不顾它的功能。

1）静态白盒测试
在不执行的情况下，有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。优点是尽早发现缺陷，为黑盒测试提供思路。

2）动态白盒测试
又称为结构测试。查看并使用代码的内部结构，从而设计和执行测试。

三、信息系统测试管理

测试管理是为了实现 测试工作预期目标，以 测试人员 为中心，对 测试生命周期 及其所涉及的资源进行有效的 计划、组织、领导和控制 的协调活动。

1、测试管理概述

随着软件开发规模增大，复杂程度增加，软件测试更加困难，加强对测试工作的组织和管理就显得尤为重要。

软件测试不能只针对程序进行测试，因为如果是系统设计上的错误，返回来修改代价非常高。较理想的做法是对软件的开发过程，按照软件工程各阶段结果进行严格的审查。测试的准备工作，在系统分析和设计阶段就要开始。

测试管理是以测试人员为中心，对测试生命周期及相关资源进行计划、组织、领导和控制的协调活动。管理的要素包括测试策略的制定、测试项目进度跟进、项目风险评估、测试文档评审、测试内部和外部的协调沟通、测试人员的培养等。

注：测试周期，传统上划分为测试计划、测试设计和测试执行。

2、测试管理内容

按照管理范围和对象，测试管理可以分为部门管理和测试项目管理。部门管理就是管人，管资源等；测试项目管理就是管项目测试人员，测试计划、策略，各项测试工作等。

3、测试监控管理

为测试活动提供反馈信息和可视性。记录，评估，分析。重点是分析缺陷，比如存活时间，分布密度，趋势分析等。

4、配置管理

包括搭建满足要求的测试环境，还包括获取正确的测试、发布版本。

5、测试风险管理

对需求的理解、测试用例设计、测试技术、回归测试不完全、沟通协调等，很多，不一一细说。

6、测试人员绩效考核

测试周期，传统上划分为测试计划、测试设计和测试执行。测试计划面向测试经理，测试设计和执行面向测试人员。

考核内容包括：
1）工作内容考核

2）工作效率与工作质量考核

3）自动化测试人员效率的度量
自动化测试引入和使用是否合理，测试结果如何等

4）对测试项目负责人效率的度量
比如测试介入时机，测试计划的合理性，测试跟进情况，等等

5）测试管理的度量

注意事项：
考核每月进行，应根据项目进度选择不同的考核指标；
测试时间长短也要纳入测试系数；测试指标良好，但时间短，考核分数不会太高；
测试经理设计和执行部分和测试人员一起考核，但管理工作单独考核；
考核要考虑项目实际情况，不可轻言激励措施或淘汰机制。