软件测试服务
发布人:上海迪真计算机科技有限公司       



软件测试方案及技术细则

 

 

1.      静态测试

1.1.    文档代码审查

1.1.1.     技术说明

借助人工方式,对需求文档和设计文档进行完备性、非二义性、一致性、平衡性的检查;

借助人工或测试工具辅助方式评审代码,对代码和需求的吻合、代码和设计的一致性、对标准的遵循性、逻辑表达的正确性、代码结构的合理性等进行确认。

1.1.2.     基本进入条件

被测代码状态稳定,同时已无错误地通过编译。

1.1.3.     被测方需要提供的文档资料

A.   软件需求文档

B.   软件概要/详细设计说明

C.   软件源代码

D.   软件接口说明

E.   软件静态编码规则集

1.1.4.     测试结果交付项

A.   文档代码审查报告(一般包含在静态测试报告文档中)

B.   软件问题报告单

1.1.5.     具体实施方案参考效率

代码审查平均参考行数:300/人天;

文档审查平均页数:n/a

1.2.    编码规则检查

1.2.1.     技术说明

按照指定的编码规则对代码进行逐行扫描,通过评审违反规则的可疑现象,来发现潜在软件错误。

国际主流编码规则标准如下:

A.   国内军口单位如没有特别指定,C语言推荐参考GJB5369规则

B.   航天行业C语言推荐参考CMSECAST规则

C.   其他行业C语言推荐参考MISRA C 2004规则

D.   航空行业C++语言推荐参考JSF AV C++规则

E.   其他行业C++语言推荐参考MISRA C++ 2008规则

F.   针对C#Java语言参考对应的国际编码规则进行检查

G.   针对各种CPU对应的汇编语言推荐参考行业内编码规则进行检查

H.   对于混合编码文件,针对用户关心的代码指令集语言进行编码规则检查

1.2.2.     基本进入条件

被测代码状态稳定,同时已无错误地通过编译。

1.2.3.     被测方需要提供的文档资料

A.   软件源代码

B.   用户指定编码标准(可指定已有行业标准和用户自定义编码标准)

C.   软件详细设计说明

D.   软件接口说明

1.2.4.     测试结果交付项

A.   软件编码规则报告(显示代码中违反规则的结果文档,一般包含在静态测试报告文档中)

B.   软件问题报告单

1.2.5.     具体实施方案参考效率

编码规则检查平均参考行数:300/人天。

1.3.    静态控制流分析

1.3.1.     技术说明

借助人工或工具分析的方式检查源代码控制流程结构,对程序进行结构化验证;同时帮助用户进行函数调用关系确认,程序整体结构分析,函数内部结构分析,并且分析出不合理的控制流程结构,比如:

A.   无条件跳转指令(GOTO语句)使用

B.   不适当的循环嵌套、分支嵌套

C.   多重入口、出口

D.   不允许的递归调用等

1.3.2.     基本进入条件

被测代码状态稳定,同时已无错误地通过编译。

1.3.3.     被测方需要提供的文档资料

A.   软件源代码

B.   软件详细设计说明

1.3.4.     测试结果交付项

A.   代码函数调用关系图

B.   代码函数静态控制流程图

C.   代码结构化验证报告

D.   上述3者,均可选择性包含在静态测试报告文档中

E.   软件问题报告单

1.3.5.     具体实施方案参考效率

静态控制流分析平均参考行数:300/人天。

1.4.    静态数据流分析

1.4.1.     技术说明

静态数据流分析是一种较深入的静态分析技术,建立在静态控制流分析基础之后,对变量的使用情况进行分析。

较之传统的编译器数据流分析,专业测试工具的数据流分析具有全路径分析和数据流异常种类更多等优势,通过排除代码异常错误来提高程序的健壮性。

对于有“苛刻性”质量要求的项目,必须进行静态数据流分析。

静态数据流分析通过对函数参数及调用信息、数据流反常、全局变量等特性进行分析,可以帮助查找如下典型的程序错误:

A.   用错的局域变量和全局变量

B.   不匹配的参数

C.   未使用过的变量或标号

D.   未定义的变量

E.   不允许的递归等

1.4.2.     基本进入条件

代码成功通过静态控制流分析、相应的报告确认及错误更正工作。

1.4.3.     被测方需要提供的文档资料

A.   软件源代码

B.   软件详细设计说明

C.   软件接口说明

1.4.4.     测试结果交付项

A.   软件问题报告单

1.4.5.     具体实施方案参考效率

静态数据流分析平均参考行数:300/人天。

1.5.    软件质量度量

1.5.1.     技术说明

引入业界主流的MccabeHalstead软件度量标准,对软件产品内部特性(代码大小、代码结构等)和外部特性(可靠性、可用性、可维护性等)进行客观和直观的分析,结合软件行业最佳工程实践参考模型进行评估。

目前常用的度量元主要包括:

A.   McCabe圈复杂度

B.   结点度量

C.   Halstead 软件科学度量

D.   循环深度

E.   基本圈复杂度

F.   基本结点度量

G.   LCSAJ密度

H.   扇入/扇出

I.   注释行数及比例

J.   代码可达性等

例如:在国内军方对于圈复杂度有参考要求,圈复杂度>15的函数个数不超过整体软件函数个数的10%

1.5.2.     基本进入条件

A.   被测代码状态稳定,同时已无错误地通过编译

1.5.3.     被测方需要提供的文档资料

A.   软件源代码

B.   用户自定义质量度量模型或者行业内推荐质量模型

1.5.4.     测试结果交付项

A.   静态质量度量报告

1.5.5.     参考软件质量模型

资料来源于“satc.gsfc.nasa.gov

NASA软件保证技术中心(Software Assurance Technology Centre

软件度量模型:

A.   每个模块代码行小于100

B.   每个模块可执行语句小于50

C.   注释行比例20%-30%

D.   GOTO语句使用

E.   McCabe圈复杂度小于10

1.5.6.     具体实施方案参考效率

软件质量度量平均参考行数:500/人天。

1.6.    静态代码缺陷专项分析

1.6.1.   技术说明

静态测试技术可以检查软件代码的编程规范,分析程序结构,对软件的质量进行度量。借助于静态测试技术,可以使代码更加规范,结构更加清晰,但由于静态测试技术不分析代码的动态行为,不分析各个变量之间的关系,因此普通的静态测试技术不能有效的检查出只有动态运行才会出现的错误,即运行时错误。

反观动态测试技术,又存在如下的缺点:

A.   不完全。我们较常规的测试步骤是:测试计划——测试用例——测试执行——发现并提交BUG。这种方法只能发现一部分运行时错误,即测试用例所能覆盖到的错误,但是完全的测试是不可能的(软件测试的公理之一:即不可能穷尽所有的输入),所以依赖于测试用例的测试最终只能保证测试过的输入不会导致运行时错误,不敢保证其他大部分的输入也能正常工作。

B.   效率低。动态测试技术能发现一部分运行时错误,但它发现的只是现象,而不是问题的根源。测试人员提交BUG后,开发人员还需要重现BUG,然后使用传统的调试工具来定位问题所在。对于一般的错误,定位并修复一个错误大约需要10个小时,而对于类似偶尔死机这样的软件错误现象,则需要更多的时间去调试定位。

基于以上两种测试方法的优缺点,引入代码缺陷性分析来弥补不足之处。通过人工或专项工具遍历代码的每条可执行路径进行扫描,发现传统上只有通过动态测试才能发现的代码缺陷,如内存泄漏、空指针引用等严重问题,分析代码的质量缺陷,以及存在的安全漏洞。

典型的运行时错误有以下几种:

A.   未初始变量的引用

B.   对空指针和越界指针的引用

C.   对超界数组的访问

D.   非法类型转换(long to short, float to integer)

E.   非法的算数运算 (例,除零错误,负数开方)

F.   整数和浮点数的上溢出/下溢出

G.   多线程应用中未保护数据的访问冲突

H.   不可达到的代码等

1.6.2.   基本进入条件

A.   被测代码状态稳定,同时已无错误地通过编译

1.6.3.     被测方需要提供的文档资料

A.   软件源代码

1.6.4.     测试结果交付项

A.   软件问题报告单

1.6.5.     具体实施方案参考效率

静态缺陷分析平均参考行数:500/人天。

2.      动态单元测试

2. 

2.1.    单元(函数)白盒覆盖测试

2.1.1.     技术说明

根据被测程序的控制流结构设计测试用例,验证软件中所有语句、分支、条件组合是否都能正常执行,以发现潜在错误。按照不同的行业标准要求,提供不同级别的覆盖测试(比如语句、分支、MCDC等)。

2.1.2.     基本进入条件

A.   被测代码状态稳定,同时已无错误地通过编译链接,执行无重大异常

B.   符合规定的软件单元源程序代码(比如已完成静态编码规则分析和代码审查等)

C.   已确定的测试环境(软件模拟器或硬件CPU平台)和软件测试工具

2.1.3.     被测方需要提供的文档资料

A.   软件源代码

B.   软件概要设计说明

C.   软件详细设计说明

D.   软件接口说明

2.1.4.     测试结果交付项

单元白盒测试覆盖率报告

单元白盒测试问题报告单

单元白盒测试用例集

2.1.5.     具体实施方案参考效率

单元白盒覆盖测试平均参考行数:200/人天。

2.2.    单元(函数)黑盒功能测试

2.2.1.     技术说明

根据需求规格说明或者设计文档说明设计测试用例,关注被测单元的功能接口,要求对每个需求至少覆盖一次,确认测试结果的正确性。常用的黑盒功能测试方法包括有等价类划分、边值分析、随机测试法、猜错法、因果图法等。

2.2.2.     基本进入条件

A.   被测代码状态稳定,同时已无错误地通过编译链接

B.   符合规定的软件单元源程序代码(比如已完成静态编码规则分析和代码审查等)

C.   已确定的测试环境(软件模拟器或硬件CPU平台)和软件测试工具

2.2.3.     被测方需要提供的文档资料