测试策略
-
1
、软件测试策略
1.1
软件测试策略概述
测试活动需要采用各种不同的策略。
这些策略表明了为确保软件质量而采用了不同的出
发点、
不同的
事例、
不同手段和测试方案。
我们通常用的较多的方法有：
静态方法和动态方
法；单元测试，集成测试，确认和系统测试；下面
的重点将介绍各种测试方法的应用。
1.2
单元测试策略
1.2.1
什么是单元测试？
单元测试是对软件基本组成单元进行测试，
< br>这里的基本单元不一定是指一个具体的函数
（
Funct
ion
或
Procedure
）
或一个类的方法，
“
单元
”
具有一些基本属性，
如：
明确的
功能、
规格定义，明确的接口定义，可清晰地与同一程序的其它单元划分开来。
在纯
C
语言的代码中，为了操作方便期间，我们一般认为一个函数就是一个单元
。
1.2.2
单元测试的主要目的：
1.
验证代码是与设计符合的
2.
跟踪需求和设计的实现
3.
发现设计和需求中存在的错误
4.
发现在编码过程中引入的错误
1.2.3
何时开展单元测试
一般地，
在编码阶段就应开展单元测
试，
边写程序边测试是一个好习惯。
一个组织不要
孤立的划分出编码和单元测试两个阶段，也不要等代码都写完了才开始单元测试。
有时候需要将单元测试时间
推后到集成阶段，甚至系统完成阶段。
单元测试可以分为计划、设计、实现、执行几个阶段。
“
计划
”
是作好人和
时间的安排。
“
设计
”
确定采用什么样的测试方法，
达到一个什么样的覆盖率标准等。
“
实现
”
是设计生成各
个测试用例。
“
执行
”
包括驱动和桩函数的设计实现，测试数据准备，测试结果验证等等。
< br>
1.2.4
单元测试所遵循的原则
对于测试来说，
我们应当尽早地和不
断地进行软件测试。
对于单元测试来说我们需要遵
循一定的单元
测试规范，
根据公司
CMM
规范中的规
定，
我们列出了一些原则但是这些并不
是足够的。
1.
仅对全新的代码或修改过的代码进行单元测试
2.
被测试的对象为实现一组相关功能的代码（一个或一组函数）
3.
单元测试根据单元测试方案进行，排除测试的随意性
4.
项目管理者保证测试用例经过审核
5.
当测试用例的测试结果与预期
结果不一致时，单元测试的执行人员需记录实际的测
试结果
6.
对被测试单元需达到的一定的代码覆盖率要求
7.
当
程序进行了修改，由测试执行人员执行回归测试以保证对发现错误的修改没有引
入新的错
误
测试
技术组总结的
《单元测试过程与结果验收指导书》
在这方面给出
了比较详细的说明，
大家有时间可以看一下。
在做单元测试的时候有时会遇到这
样一种现象：
既设计人员在设计测试用例的时候或者
在调试测试
脚本的时候发现了详细设计或者代码中错误，
并且改正了这些错误。
因此在单元
测试用例最后执行的时候发现的问题变少了。
这
不能表示单元测试的效果变差了。
因为在单
元测试过程中，
通过单元测试方法发现的问题也是属于单元测试发现的问题。
单元测
试发现
的问题不能局限于单元测试用例执行时发现的问题。
<
/p>
仅考虑被测单元的语句覆盖率并不是足够的。语句覆盖
100%<
/p>
这是公司硬性的规定，但是
不是除此以外我们就不需要兼顾其他覆
盖率了呢？不是！
有很多错误不是通过达到一定的语
句覆盖就能
发现的。
我们还必须考虑一定的判定覆盖，
条件覆盖甚至路径覆
盖。
一般来说要
完全达到路径覆盖几乎是不可能的。但是我们可
以考虑
McCabe
提出的圈路径或
Z
路径覆
盖情况。
同时单元测试不仅仅是作为无错编
码一种辅助手段在一次性的开发过程中使用。
单元测
试必须是可
重复的，
无论是在软件修改，
或是移植到新的运行环境的过程中
。
因此，
所有的
测试都必须在整个软件
系统的生命周期中进行维护。
<
/p>
在
VV
测试中有一个致命的弱点，
也就是它把测试的阶段划分的太明显。
其实在实际开
< br>发过程中你无法在时间点上严格的结束任何一种测试，
因此说单元测试什么时候结
束是没有
意义的，
如果一定要划分，
我
们可以认为我们的工作重点有单元测试进入另一种测试的标准。
1.2.5
正规检视和代码走读
一般在单元测试期间，
我们会同步启
动一些测试活动，
例如代码走读，
正规检视，
< br>以进
一步保证代码质量。
正规检视和代码走读属于同行评审中的两中评审类型，正规检
视有严格的流程和纪律，
发现错误的效率比较高，
但工作量很大
，
一般一次正规检视的代码量不要超过
500
< br>行代码。
正规检视参与的人员来自于不同领域的人，
可以
从各个不同的角度去发现代码或文档中深层
次的错误。
走读相对来说是比较自由的，
没有严格的流程，
参与人员一般都是来自于同项目组的人。
走读的工作量相对来说是比较小的，
一般用于寻找一些浅显的错误。
同时走读也作为一种技
术交流或理解代码和文档的手段。
单元测试的工作量
介于走读和正规检视之间，
单元测试是由开发人员完成的，
通过
设计
测试用例来寻找代码中存在的错误。
测试用例设计的好坏直
接影响单元测试的结果。
单元测
试比较正规检视和走读的最大不
同是单元测试可以通过代码的运行来发现错误，
而这是正规
检视
和走读做不到的。单元测试不可缺少，因为有很多错误只有在运行时才能发现得了。
在代码进行单元测试之前应当先进
行代码走读和正规检视，它们的侧重点不同。
CMM
过程规范要
求至少
40%
的代码必须经过正规检视。单元测试的代码
+
走读的代码
+
正规
检
视的代码
>=
总的代码。
总结：
单元测试是一种白盒测试
有数据显示，进行适当的单元测试
可以发现一个程序中多达
70%
的缺陷。因此，越早
启动单元测试，效果越好。
正规检视、代码走读和单元测试一起进行，可以起到良好的效
果。
1.3
集成测试策略
集成测试策略就是在测试对象分析
的基础上，
描述软件模块集成
（组装）
的方式、
方法。
集成测试的基本策略比较多，
分类比
较杂，
一般来说，
可以按测试过程中组合模块的方
式，分为增式、非增式和衍变式集成等策略。
（
1
）非增
式集成方式：
也称整体组装。
首先对每个模块分别进行模块测试，然后再
把所有模块组装在一起进
行测试，最终得到要求的软件系统。
（
2
）增殖
式集成方式：
也称渐增式组装。
<
/p>
首先对一个个模块进行单元测试，然后将
这些模块逐步组装成较大
的系统，在组装的过程中，
边连接边测试，以发现连接过程中
产
生的问题，
最后通过增殖逐步组装成为要求的软件系统。
增殖式集成方式有三种实现方式：
自顶向下的增殖方式，
自底向上的增殖方式和混合增殖方式。
（
3
）衍变式集成方式：结合非增式集成方式和增殖式集成方式，包括，衍变的自顶向
下的增殖测试，自底向上
-
自顶向下的增殖测试等
。
总结：
集成测试关注的是模块间接口的正确性。
选择良好的集成方式能减少大量的测试工作量。
1.4
验证和确认测试（
Verfication and
Validation
）
在广义上，软件测试是验证和确认
VERFICATION
AND VALIDATION
（
V
﹠
V
〕。
验证指保证软件正确地实现了
一特定功能的一系列活动。
确认是指保证所生产的软件可追溯
到
用户需求的一系列活动。
BOEHM
对
V
﹠
V
的解释是：
VEIFICATION:
VALIDATION:
V&V
的
定义包含了许多活动，即软件质量保证
SQA
。
1.4.1
确认测试
(Validation
Testing)
确认测试又称为效性测试。它的任务是验证软件的功能
和性能及其特性是否与用户的要求
一致。
对软件的功能和性能要求在软件需求规格说明
中已经明确
规定。
在软件需求规格说明中描述了全部用户可见的软件属性，
其中有一节叫做
有效性准则，
它包含的信息就是软件确认测试的
基础。
集成测试完成以后，
分散开发的模块
被联接起来，
构成完整的程序。
其中各模块之间接口存在的
种种问题都已消除。
于是测试工
作进入最后阶段
--
确认测试
(Validation testin
g)
。什么是确认测试，说法众多，其中最简
明、最严格的解释
是检验所开发的软件是否能按顾客提出的要求运行。若能达到这一要求，
则认为开发的软
件是合格的。因而有的软件开发部门把确认测试称为合格性测试
(qualificat
ion testing)
。这里所说的顾客要求通常指的是在软件规格说明书中确定的
软件
功能和技术指标，或是专门为测试所规定的确认准则。
1.5
系统测试策略
由于软件只是计算机系统中的一个组成部分，
软件开发完成以后，
最终还要与系统中其
它部分配套运
行。
系统在投入运行以前各部分需完成组装和确认测试，
以保证
各组成部分不
仅能单独地受到检验，
而且在系统各部分协调工作
的环境下也能正常工作。
这里所说的系统
组成部分除去软件外，
还可能包括计算机硬件及其相关的外围设备、
数据及其收集和传
输机
构、
掌握计算机系统运行的人员及其操作等，
甚至还可能包括受计算控制的执行机构。
显然，
系统
的确认测试已经完全超出了软件工作的范围。
然而，
软件在系统
中毕竟占有相当重要的
位置，
软件的质量如何，
软件的测试工作进行得是否扎实势必与能否顺利、
成功地完成系统
测试关系极大。另一方面，系统测试实际上是针对系统中各个组成部分进行的综合性检验。
尽管每一个检验有着特定的目标，
然而所有的检测工作都要验证系统中每个
部分均已得到正
确的集成，并能完成指定的功能。以下分别简要说明几种系统测试：
1.5.1
功能测试（
Function
Test
）
功能测试是系统测试中的一种重要测试方法，
它不管软件内部的实现逻辑，
以检验输入
输出信息是否
符合规格说明书和需求文档中有关功能需求的规定为目标。
功能测试主要是为
了发现以下几类错误：
1
、是否有不正确或遗漏了的功能？
2
、功能
实现是否满足用户需求和系统设计的隐藏需求？
3
、输入能否正确接受？能否正确输
出结果？
这要求测试设计者对产品的规格说明、
需求文档、
产品业务功
能都非常熟悉，
同时对测
试用例的设计方法也有一定掌握，
才能设计出好的测试方案和测试用例，
高效地进行功能测
试。
功能测试分为功能测试用例设计，
用例执行，
输出测
试报告等。
功能测试的关键在于设
计高质量的用例，
但用例的设计通常和业务紧密相关，
很难给出一般有实际意义的操作指导，
但一些方法是共通的。例如：等价类划分，边界值分析，错误推测等。
< br>
1.5.2
恢复测试
恢复测试是要采取各种人工干预方式使软件出错，
而不能正常工
作，
进而检验系统的恢
复能力。如果系统本身能够自动地进行恢
复，则应检验：重新初始化，检验点设置机构、数
据恢复以及重新启动是否正确。
如果这一恢复需要人为干预，
则应考虑平均修复时间是否在
限定的范围以内。
1.5.3
安全测试
安全测试的目的在于验证安装在系
统内的保护机构确定能够对系统进行保护，
使之不受
各种非常的
干扰。
系统的安全测试要设置一些测试用例谋略实在系统的安全保密措施，
检验
系统是否有安全保密的漏洞。
安全测试要考虑：
●
设备本身的安全性，当受到恶意
攻击时，设备的自我保护能力，病毒防护能力，自
定义通信协议安全性。
●
物理特性安全性测试（如接地，静电等），
●
业务
的安全性测试（如
200
业务密码验证，
201
业务密码验证）
●
信息安全性测试。