软件测试技术介 绍.ppt

1、软 件 测 试 技 术 介 绍,上海创景计算机系统有限公司 ,内 容,1. 软件测试基本概念 1.1 为何软件测试 1.2 什么是软件测试 1.3 软件测试的作用 1.4 软件测试公理,2. 软件测试技术介绍 2.1 静态测试技术 2.2 静态分析 2.3 动态测试技术,3. 软件生命周期中的软件测试 3.1 软件测试过程模型 3.2 软件开发过程 3.3 单元测试 3.4 集成测试 3.5 系统测试 3.6 测试进入条件,4. 软件测试管理,随着软件功能越来越强、复杂程度越来越高，导致致命故障越来越多。,1.1 为何软件测试？,“The day the software crashed”-福

2、布斯杂志 Tandem - 金融交易系统宕机； AT&T - 电话系统； Chemical bank-双倍借贷给客户； IRS 向纳税人征收680亿美金税金； Patriots & Scuds - 爱国者导弹故障； Bank of New York - 236亿美金； Ariana5-火箭故障； DSC Communications - 电话系统故障； ,软件错误开销： 美国航空公司 储运损耗每分钟损失2万美金； 1989 - 12小时储运损耗 1994 - 5小时储运损耗 飞行系统故障 - $50,000,000损失； Boeing - 每分钟损失5万美金； 美国联邦快递 - 每分钟损失16

3、.7万美金。,1.1 为何软件测试？,2018年10月14日,5,历史上： 1973年W.Hetzel指出测试是对程序或系统能否完成特定任务建立信心的过程。 异议：我们不应该只是为了对一个程序建立信心或显示信心而去作测试。,1.2 什么是软件测试？,修正观点： 测试目的在于鉴定程序或系统的属性或能力的各种活动，它是软件质量的一种度量。,1983年IEEE： 使用人工或自动手段来运行某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清结果与实际结果之间的差别。,2018年10月14日,6,软件测试的重要性软件设计与编码过程是引入错误的过程，而软件测试是排除软件错误的过程。,1.3 软件测试

4、的作用,2018年10月14日,7,确定需求,设计,编码,测试,排除,故障隔离,故障分类,改正,故障,故障,故障,故障,故障等级,失效,通过测试排除软件故障,1.3 软件测试的作用,2018年10月14日,8,1.3 软件测试的作用,通过测试排除软件故障,2018年10月14日,9,测试只能证明错误的存在，而不能表明程序中没有错误。,1.4 软件测试公理,2. 测试的两个作用是：确定程序中缺陷的存在；有助于判断该程序在实际上是否可用。,3. 软件测试最困难的问题之一是知道何时停止测试(When to stop testing? ),4. 自己测试自己的程序是不可能的。,5. 当一个软件被测出的

5、缺陷数目增加时，更多的未被发现的缺陷存在的概率也随之增加。,2018年10月14日,10,一个好的测试用例应当是一个对以前未被发现的缺陷有高发现率的用例，而不是一个表明程序工作正确的用例。,1.4 软件测试公理,7. 要对有效的和无效的输入状况写测试用例。（测试用例要兼顾有效与无效的输入）,8. 每个测试用例必备的部分是描述预期的输出。,9. 像做其它事情一样，测试在其一开始就必须要有一个目标。,测试技术,静态测试,代码审查代码走查 桌面检查 技术评审 静态分析,控制流分析数据流分析 接口分析 表达式分析,动态测试,黑盒测试技术白盒测试技术,2. 软件测试技术介绍,动态测试,控制流覆盖数据流覆

6、盖,黑盒测试技术白盒测试技术,功能测试 等价类划分 边值分析 因果图 随机测试 猜错法,2. 软件测试技术介绍,语句覆盖分支覆盖路径覆盖错误处理路径,全定义使用路径全使用路径全定义路径数据流异常状态图,2018年10月14日,13,不执行程序代码，通过审查文档、代码的方式查找软件中的缺陷。,2.1 静态测试技术,76%以上错误； 不需特别条件，容易开展； 在发现了错误的同时也就定位错误，不需额外的工作定位错误； 对评审人员要求高； 可借助于工具进行。,2018年10月14日,14,静态测试方法 技术评审 软件需求分析与设计； 对需求规格文档、设计文档进行非二义性、平衡性、一致性检查。 代码走查

7、（Walkthrough） 设计测试数据人工方式执行代码。 代码审查（Code Inspection）,2.1 静态测试技术,2018年10月14日,15,代码审查（Code Inspection）,2.1 静态测试技术,代码审查测试内容： 代码与设计的一致性； 代码对标准的遵循性； 代码的逻辑表达的正确性； 代码结构的合理性。,代码审查实施 审查会 代码审查单,2018年10月14日,16,静态分析 静态分析是对被测软件进行特性分析的一些方法的总称； 静态分析的查错功能是编译系统所不能替代的；,2.2 静态分析,静态分析可辅助代码评审人员： 发现可能的程序欠缺； 找到潜伏着问题的根源； 提供

8、间接涉及程序欠缺的信息； .,2018年10月14日,17,静态分析方法,2.2 静态分析,编码规则检查 控制流分析 数据流分析 软件度量分析,2018年10月14日,18,改善代码质量 避免编程语言本身在使用过程中容易造成的误用； 提高开发速度： 开发人员不需要总是从一些基本原则出发进行决策； 增进团队精神： 有助于减少团队内部在一些小事情上的不必要的争论，使团队成员更易于阅读和维护其他成员的代码； 在正确的方向上取得一致： 使开发人员放开手脚，在有意义的方向上发挥创造力；,2.2.1 为什么进行编码规则检查,2018年10月14日,19,C语言本身容易出错的问题 词法”陷阱“ 语法”陷阱“

9、 语义”陷阱“ 连接 库函数 预处理器 可移植性缺陷,2.2.1 编码规则检查改善代码质量,2018年10月14日,20,容易和混淆； &和|容易和&和|混淆； 词法分析中的“贪心法” y = x/*p /* p指向除数 */ 会被编译器理解为/*p /* p指向除数 */为注释 字符与字符串 C语言中的单引号和双引号含义不同，易错用带来问题； s表示一个整数； “s”表示一个字符指针；,2.2.1 编码规则检查词法“陷阱”,2018年10月14日,21,运算符的优先级问题； 注意作为语句结束标注的分号 If （a b）big a； If （a b）;big a； “悬挂”else的问题； s

10、witch语句遗漏break；,2.2.1 编码规则检查语法“陷阱”,2018年10月14日,22,指针与数组； 非数组的指针； 作为参数的数组声明； 空指针并非空字符串； 边界计算与不对称边界； 求值顺序； 运算符&、|和！ 整数溢出,2.2.1 编码规则检查语义“陷阱”,2018年10月14日,23,在循环语句中使用“break”语句。,#include “c_standards.h“ /* * Standard 31 S : Use of break statement in loop */ void static_31 (void) SINT_32 i=10 ; while (i -1

11、) if (i = 0) break; i = i - 1; ,2.2.1 编码规则检查典型规则举例,2018年10月14日,24,#include “c_standards.h“ /* * Standard 56 S : Equality comparison of floating point. */ void static_56 ( void) FLOAT_32 fl, f2; fl=1.01f; f2=2.01f; if (fl = f2) /* . */ if (fl = 0.0f) fl = fl + 0.01f; ,2.2.1 编码规则检查典型规则举例,浮点数比较。,2018年1

12、0月14日,25,功能函数无返回值。,#include “c_standards.h“ /* * Standard 36 S : Function has no return statement. */ UINT_32 static_36(UINT_32 p_1, UINT_16 p_2) UINT_32 y=p_1; /* Not returning a value */ ,2.2.1 编码规则检查典型规则举例,2018年10月14日,26,MISRA C /MISRA-C：2004 MISRA国际发动机工业软件可靠性协会组织制定了“汽车软件C语言使用指南”的标准。这份标准的产生在自动化行业

13、极大地推动了使用“安全的C”进行编程。这份标准在汽车行业被广泛接受，同时它也被其它行业所广泛借鉴 。 ISO 9126 ISO 国际标准化组织 IEC 61508 IEC 国际电工委员会 DERA C DERA 英国防护评估和研究机构,2.2.1 编码规则,2018年10月14日,27,在语言的底层面上，前面列出的C语言存在的隐患，在C中基本都存在，所以从这个角度来看，C语言的大多数规则同样适用于C；C应用比较广泛的编程规则 Ellemtel Coding Standards C Codeing Standards More Effective C+,2.2.1 关于c+编码规则,2018年1

14、0月14日,28,编码规则主要是针对语言使用本身的； 编程风格主要是针对代码书写风格的；对于质量“苛刻性”系统，执行严格的编码规则后，弱化了对于编程风格的要求； 规则约束很全面很严格，很大程度上已经完成了编程风格检测所要达到的效果；对于非质量“苛刻性”系统，执行宽松的编码规则，编程风格的作用就显得比较重要；,2.2.1 关于编码规则与编程风格,2018年10月14日,29,编码规则检查实施 项目之初制定编码规则可提高软件产品质量，做到“有法可依”； 培训软件编程人员理解规则； 加强管理，项目进行过程中需严格按编码规则检查，做到“执法必严”； 有效的编码规则检查工具支持；,2.2.1 编码规则检

15、查的实施,控制流分析 使用控制流程图系统检查程序的控制流程结构； 结构化验证； 分析不合理的控制流程结构： 无条件跳转指令（GOTO语句）使用； 不适当的循环嵌套、分支嵌套； 多重入口、出口； 不允许的递归调用等。,2.2.2 控制流分析,数据流分析 在控制流基础上分析数据使用情况； 静态数据流分析可帮助查找典型的程序错误： 用错的局域变量和全局变量； 不匹配的参数； 未使用过的变量或标号； 未定义的变量； 不允许的递归； 静态数据流分析包括： 过程函数参数及调用信息分析； 数据流反常分析； 全局变量分析。,2.2.3 数据流分析,过程或函数调用信息分析: 参数； 全局变量； 函数返回值。 过

16、程或函数调用信息分析用途： 编写程序接口文档； 检测错误。 查找错误时，下列两种情况需特别关注： 存在Clear Path使得输出参数或变量不能正常取值； 存在Clear Path使得过程或函数不能正常返回值。,2.2.3 数据流分析,典型数据流异常 UR 声明后没有初始化就被引用 ； 真实错误（genuine error) DU 初始化后没有被引用 ； 可疑错误（suspicious error) DD 两次初始化之间没有被引用； 可疑错误（suspicious error),1 void proc ()2 3 int x,y,z,t;4 x = 1;5 if (y 0)6 x = 2;7

17、/* end if */8 z = x + 1;9 10,2.2.3 数据流分析,2.2.3 数据流分析,一般编译器会进行简单的数据流分析，并且会有相应的警告或者报错信息；相对于编译器的数据流分析，专业工具的数据流分析更全面更彻底 专业工具是全路径的数据流分析，而编译器一般不是； 专业工具检查的数据流异常的种类比编译器检查的种类多；,2.2.3 数据流分析,数据流分析是较深入的静态分析技术； 对于程序进行数据流分析，并且排除相应的数据流异常可以提高程序的健壮性； 对于有“苛刻性”质量要求的项目，要求进行数据流分析；,什么是软件度量？ 体检 身高； 体重； 血压； 软件度量 直观性； 客观性；

18、与软件错误相关性。,2.2.4 软件质量度量与跟踪控制,软件产品质量 内部特性 代码大小 代码结构 外部特性 可靠性、可用性、可维护性等 软件开发过程,复杂度,2.2.4 软件质量度量与跟踪控制,2018年10月14日,38,常用度量元 McCabe圈复杂度 结点度量 Halstead 软件科学度量 循环深度 基本圈复杂度 基本结点度量 LCSAJ密度 扇入/扇出 注释行数及比例 代码可达性 .,2.2.4 软件质量度量与跟踪控制,NASA软件保证技术中心 Software Assurance Technology Centre 软件度量模型 每个模块代码行小于100行； 每个模块可执行语句小

19、于50行； 注释行比例20%-30%； 无GOTO语句使用； McCabe圈复杂度小于10。 资料来源于“satc.gsfc.nasa.gov”,2.2.4 软件质量度量与跟踪控制,动态测试是在抽样测试数据上执行程序并分析输出以发现错误的过程。根据测试理论,如果抽样测试数据满足一定要求，通过测试可以发现程序中大多数错误，并且可以评估程序的质量(正确性,可靠性等)。,2.3 动态测试技术,动态测试技术具有以下特点： 实际运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析。 必须生成测试数据来运行程序，测试质量依赖于测试数据。 生成测试数据，分析测试结果工作量大，使开展测试工作费时、费

20、力。 动态测试中涉及多方面工作，人员多、设备多、数据多，要求有较好的管理和工作规程。动态测试包括三部分核心内容：生成测试数据，执行程序与验证程序的输出结果。,2.3 动态测试技术,动态测试适用的层次： 单元测试 集成测试 系统测试,2.3 动态测试技术,黑盒测试与白盒测试方法,2.3 动态测试技术,黑盒测试(BLACK-BOX TESTING)是一种按照需求规格说明设计测试数据的方法。它把程序看作内部不可见的黑盒子，完全不需考虑程序内部结构和编码结构，也不需考虑程序中的语句及路径，测试者只需了解程序输入和输出之间的关系，或是程序的功能，完全依靠能够反映这一关系和程序功能的需求规格说明确定测试数

21、据，判定测试结果的正确性。黑盒测试方法可用于功能测试、边界测试、强度测试、随机测试。,2.3.1 黑盒测试,黑盒测试-基于需求（规格说明）的测试根据规格说明生成测试用例每个需求至少覆盖一次 方法： 功能/性能测试（最普通的，最低限度的测试） 边值测试（Boundary Values） 强化测试(Stress testing : at Capacity Limits) 最坏情况测试(Worst cases Testing) 随机测试缺点：在进行上述所有各种测试后，仍有部分程序未被执行。,2.3.1 黑盒测试,规范 （Specification）,生成测试用例,生成预期的输出结果,规范 （Spec

22、ification）,测试用例,被测软件,输出,比较和分析,预期的输出结果,正确/错误,黑盒测试技术,2.3.1 黑盒测试,黑盒测试方法 关心被测系统或模块功能接口； 不必了解软件实现结构； 基于软件需求规格说明。 黑盒测试方法有效性很大程度依赖于被测软件需求规格说明、设计说明 要求规范的软件需求分析、设计； 相关项目规范有非常明确的、具体的要求； 分析师、设计师不使用规范的方法； 测试人员很难对软件需求分析、设计文档进行评审。 方便有效的工具支持。,2.3.1 黑盒测试,黑盒测试用例设计 等价类划分； 边值分析； 因果图法； 随机测试法； 猜错法； 数据域分析法； .,2.3.1 黑盒测试,

23、等价类划分 将输入或输出划分为等效的几个区间： 保证每个区间中任何数据或值具有相同特征； 分区之间无依赖性。 无效等价类与有效等价类。 输入或输出不仅只是参数： 外部数据； 时间； 顺序/历史； 状态。 必须设计测试用例以覆盖每一分区。,2.3.1 黑盒测试,等价类划分 - 需考虑的几个问题： 分区手工划分； 当软件复杂性增加时； 等价类划分变得复杂。 如果分区之间具有依赖性； 使得测试用例变得困难。 偏向于正向划分等价类： 必须补充反向测试数据。,2.3.1 黑盒测试,边值分析 边值分析法与等价类划分方法相近： 软件错误易于在各分区的边值范围发生。 基于如下原则设计测试用例： 以边值执行测试

24、； 以边值邻近值执行测试,2.3.1 黑盒测试,边值分析 - 需考虑的问题： 需具备硬件先验知识 移植性 使用每个最小边值； 使用每个最大边值； 往往只做正向测试,2.3.1 黑盒测试,因果图法 因果图法的基本原理是通过因果图，将自然语言描述的功能说明转换为判定表，最后为判定表的每一列设计测试用例。 使用因果图法设计测试用例步骤： 列出一个模块的输入条件(因)和动作(果)，并给每一个原因与结果赋予一个标识符； 画出因果图； 将因果图转换为判定表； 按判定表规则设计为测试用例。,2.3.1 黑盒测试,随机测试 采用随机数据产生测试用例。,2.3.1 黑盒测试,错误推测法： 通过估计可能发生的错误

25、类型： 基于经验。 需建立一错误类型清单： 使用错误类型清单进行测试； 添加并维护错误类型清单。,2.3.1 黑盒测试,数据域分析法： 根据对数据域的划分，在域边界选择测试数据； 被实践证明是十分有效的一种方法；,2.3.1 黑盒测试,白盒测试技术 根据被测程序的内部结构设计测试用例。 控制流分析； 数据流分析； 验证软件中所有语句、分支、条件组合都能正常执行； 软件设计与最终代码不一定完全一致； 通过白盒测试确保不一致部分的代码能正常。,2.3.2 白盒测试,白盒测试-基于结构的测试覆盖度量： 语句覆盖100%：适用于单元、集成测试 分支覆盖 95%100%85% 每个条件语句至少两次（T，

26、F） 路径覆盖：每条路径至少一次，适用于单元测试缺点：发现缺陷的效率不如黑盒子。,2.3.2 白盒测试,逻辑覆盖 vs. 数据流覆盖 vs. 路径覆盖,2.3.2 白盒测试,100% 语句执行 ABCDEFG 100% 分支执行 ABHDEJG 100% 数据流 ABCDJG ABHDEG,2.3.2 白盒测试,代码覆盖率指标 语句覆盖； TER1 分支覆盖； TER2 LCSAJ路径覆盖； TER3 过程/函数调用覆盖； 分支条件覆盖； Tsub(C)/TERcon(Ada) 分支条件组合覆盖； Tsub(C)/TERcon(Ada) 修正条件/判定覆盖。 Tsub(C)/TERcon(Ad

27、a) 数据流覆盖率,2.3.2 白盒测试,代码覆盖率效率,2.3.2 白盒测试,不同标准/组织对覆盖率要求不同。 A级-灾难性(Catastrophic) MC/DC 发动机控制 惯导系统 B级-危险性(Hazardous) 分支覆盖 差分GPS导航,C级 - 严重性 语句覆盖 无线通讯 D级 - 较轻性 基本块覆盖BBC 机上环境控制 E级 - 无影响 Entry/Exit 覆盖 机上娱乐系统,2.3.2 白盒测试,不同测试阶段代码覆盖率要求不同： 单元测试/渐增集成测试； 根据不同的标准，代码覆盖率要求不同； DO-178B A级MC/DC100%； DEF-STAN 00-55 LCSA

28、J100%； 集成测试； 过程/函数调用覆盖率100%； 系统测试； 过程/函数调用覆盖率100%；,2.3.2 白盒测试,根据程序流程结构在程序的特征点插装代码，插装过的代码在执行时将特征值记录保存供分析； 程序入口、出口； 程序分支； 通常情况下插装代码将特征值写入历史文件。 通过分析特征值从而分析程序执行流程、路径。,2.3.2 白盒测试-代码插装技术,主机平台软件测试 静态分析； 判断被测软件流程结构； 插装代码并执行； 动态覆盖率分析； 执行结束后，工具分析历史文件得出代码动态执行信息。,2.3.2 白盒测试-代码插装技术,嵌入式平台软件测试,2.3.2 白盒测试-嵌入式平台,主机平

29、台软件测试往往不考虑代码插装影响； 嵌入式软件测试必须考虑代码插装影响； 代码空间有限； TI TMS320C25(64K字节程序区，64K字节数据区)。 实时性； 大都嵌入式系统实时性要求强。 代码插装影响： 代码大小增加20%40%； 不同系统时间影响不定。 单元测试/渐增集成测试时通常不考虑代码插装影响； 系统测试需考虑代码插装影响。,2.3.2 白盒测试-嵌入式平台,黑盒测试与白盒测试方法使用策略,测试策略：1、基于软件需求定义设计测试用例进行功能测试；2、使用覆盖率分析工具对功能测试进行代码覆盖率分析；3、如功能测试不满足代码覆盖率要求，补充白盒测试用例。,2.3 动态测试技术,顺序

30、软件开发模式 瀑布式(Waterfall) 渐进软件开发模式 迭代开发 交互软件开发模式 渐进原型 RAD,3. 软件生命周期中的软件测试,2018年10月14日,71,软件生存期的瀑布模型和软件工程过程,3. 软件生命周期中的软件测试,2018年10月14日,72,软件测试过程,3. 软件生命周期中的软件测试,需求分析与系统设计,概要(结构)设计,详细设计,编 码,单元测试,集成测试,系统测试,用户需求,验收测试,3.1 软件测试过程模型-V模型,忽略了测试活动对需求分析，系统设计等活动的验证和确认的功能,描述了测试阶段和开发过程期间各阶段的对应关系,3.1 软件测试过程模型-W模型,测试是

31、与开发同步进行；有利于尽早全面的发现问题；,需求、设计、编码等活动被视为串行；测试和开发活动也保持着一种线性的先后关系；对于复杂多变的情况，不能解除测试管理面临的困惑,3.1 软件测试过程模型-H模型,X模型 针对单独的程序片断进行单独的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序；前置测试模型 体现了开发与测试的结合，要求对每一个交付内容进行测试；,3.1 其它软件测试过程模型,在实践测试工作中应该尽可能的去应用各个模型对项目有实用价值的方面，不能强行为使用模型而使用模型；以W模型为框架，及早的、全面的开展测试；同时灵活的应用H模型独立测试的思想，在达到恰当的就绪点时就应该

32、开展独立的测试工作，同时将测试工作进行迭代；,3.1 软件测试过程模型的选择策略,经过确认测试后的软件配置项,3.1 国内航天软件测试过程模型,产生软件需求 收集并分析软件需求； 要求软件需求具有完整性、非二义性及逻辑性； 定义系统测试需求 需对软件需求进行评审 纠正软件需求错误,3.2 软件开发过程需求分析阶段,产生概要设计需求 将已确定的软件需求转换成相应的体系结构； 确定软件中功能模块； 定义功能模块间接口。 定义软件集成测试需求 评审概要设计 纠正概要设计错误,3.2 软件开发过程概要设计阶段,产生详细设计需求 对每个功能模块进行具体的描述； 为程序编写打下基础。 定义单元测试需求 评

33、审详细设计需求 纠正详细设计错误,3.2 软件开发过程详细设计阶段,产生软件代码 将软件设计转换成计算机可以接收的程序； 要求程序结构良好、清晰易读，且与设计相一致。 进行静态分析或测试 并不真正执行 代码评审 纠正代码错误,3.2 软件开发过程编程阶段,对各个软件功能模块分别进行测试 验证被测模块正确地实现了详细设计需求。 引入动态测试或分析 确保被测软件没有做错误的事或行为。 评审测试结果 纠正错误： 编程错误 设计错误 测试错误,3.3 单元测试阶段,单元测试是指测试程序中单个子程序或过程。在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其它模块的功能之间没

34、有相互依赖关系，因此，有可能把每个模块作为一个单独的实体来测试。模块测试一开始不是把程序作为一个整体来测试，而是首先集中注意力来测试程序中较小的结构块，其优点是：由于一开始把注意力集中在程序的较小单元上，发现错误，就可以肯定错误所在模块，因而便于纠错；单元测试提供了同时测试多个模块的机会，使得测试过程得以并行进行。 单元测试检查要点 单元测试的目的是验证模块满足功能、性能和接口等的要求。单元测试主要是模块接口、局部数据结构、重要的执行路径、错误处理和边界测试等五个基本特性进行考察。,3.3 单元测试,适用对象：任一计算机软件单元。进入条件：计算机软件单元代码无错误地通过编译或汇编。对于A（适合

35、时还有B）级软件应已进行静态分析。 测试内容 计算机软件单元的功能测试； 重要的执行路径测试； 局部数据结构测试； 错误处理测试； 影响上述各条的界线条件（边界值）； 语句覆盖测试，分支覆盖测试。,3.3 单元测试,实施步骤 制定计算机软件单元测试计划，应在详细设计阶段完成； 建立计算机软件单元测试环境、编写测试说明； 执行计算机软件单元测试用例，并详细记录执行信息； 根据每个测试用例的预期输出结果和实际运行结果，判定该测试是否通过； 如果测试不通过，应分析错误原因，并在修正错误后进行回归测试，直至通过； 完成计算机软件单元测试报告； 测试完成并通过后，将被测软件和有关文档纳入配置管理。,3.

36、3 单元测试,测试评估 根据详细设计说明书、计算机软件单元测试结果和发现的错误信息，评价每个计算机软件单元的设计及其实现。 通过准则 完成并通过了计算机软件单元静态分析； 计算机软件单元功能同设计需求一致； 计算机软件单元接口同设计需求一致； 能正确处理输入和运行中的错误； 对测试发现的问题进行修改后，又执行并通过了有关测试； 达到规定的测试覆盖类及覆盖率且单元执行正确； 完成了计算机软件单元测试报告；,3.3 单元测试,2018年10月14日,88,单元测试的被测对象是程序单元，而程序单元不是一个独立可运行的程序，同时在对每个单元进行单元测试时，也不能完全忽视它们和周围模块的相互关系。为了模

37、拟这类关系，为程序单元的执行构造一个完整的环境，需设置两种辅助测试模块：驱动模块和桩模块。驱动模块用以模拟被测模块的上层模块，测试执行时由驱动模块调用被测模块使其运行，桩模块模拟被测模块执行时所调用的模块，测试执行时桩模块使被测模块能完整闭合地运行。在下一页的图中表示了被测模块、驱动模块、桩模块所构成的单元测试执行环境。由于测试模块，可能调用多个其它模块，因此可能有多个桩模块。驱动模块和桩模块要设计得尽量简单，避免因其错误干扰被测模块运行和测试结果判别。,3.3 单元测试方法,2018年10月14日,89,驱动模块,被测模块,桩模块,桩模块,桩模块,模块测试执行环境构成,3.3 单元测试方法,

38、2018年10月14日,90,3.3 单元测试方法,单元测试可以采用白盒测试方法，也可以采用黑盒测试方法。 单元测试的任务： 按照所选择的白盒测试方法和/或黑盒测试方法设计测试用例； 将测试用例编写成测试程序； 建立单元测试环境； 执行测试程序； 进行测试结果分析，包括覆盖分析。,根据模块结构图将各模块连接起来测试。 渐增式与非渐增式； 很好地检查模块间接口错误。 动态分析 评审集成测试结果 纠正错误： 接口错误 设计错误 测试错误,3.4 软件集成测试阶段,2018年10月14日,92,集成测试是有序进行的一种测试。在这种测试中，把各个模块逐步装配成高层的功能模块并进行测试，直到整个软件成为

39、一个整体。集成测试的目的是检验软件模块之间的接口关系，并把经过测试的模块构造成符合设计要求的软件。,3.4 集成测试,2018年10月14日,93,3.4 集成测试,集成测试的主要内容： 模块间的接口测试：接口测试是集成测试的基本任务。在接口测试中应从调用关系和数据项的相容性两方面考虑。数据项的相容性是指调用时数据传递的正确性。 全局数据结构测试：全局数据结构是一种常用的接口方式，因此要在集成测试中进行测试。 性能测试：在必要时应进行组装成的中间功能模块的运行时间、运行空间、计算精度的测试。由于系统还没有完全结合进来，一些性能的度量容易进行，也容易较早察觉真实模块结合后给性能带来的影响。 软件

40、功能模块的功能测试：如果我们不是一下把所有的模块集成为一个整体软件，会获得一些中间功能模块，这也是规范有效的组装测试过程要求的。在测试了构成这个功能模块内接口的正确性后，我们还应测试整个功能模块是否满足相应的功能需求。虽然在接口测试时已证实功能模块的一些功能，但只是侧重于接口方面。因此，如果若干子功能形成了一个如设计文档中要求的一个高层功能，必须进行功能测试。,2018年10月14日,94,增量测试和非增量测试：增量测试是指不断地把待测模块组合到已经测试过的模块上去，然后再进行测试；非增量测试是指独立地测试每个模块，再把它们组合成完整的程序。,3.4 集成测试,2018年10月14日,95,3

41、.4 集成测试,增量测试相对于非增量测试的优点是： 增量测试需要的工作量较非增量测试要少。因为非增量测试要为每个模块构造相应的驱动模块和桩模块，而增量测试可利用一些已测试的模块。 非增量测试先分散测试，再集中起来一次完成组合和测试，如果在模块接口处存在差错，只会在最后的组合时一下子暴露出来。使用增量测试方法可以较早地发现模块接口错误，这是由于较早地把模块组合起来进行测试所致。 增量测试使调试工作变得容易，因为增量逐步组合和逐步测试模块，把可能出现的错误逐步分散暴露出来，并且由于每次组合一个模块，错误发生时，可以比较容易定位，这些错误肯定是在最新增加的模块的连接中出现的。而非增量测试，直到对各个

42、模块测试结束，对整个程序进行组合时才能发现错误，这时再要确定错误的位置就非常困难，因为错误可能出现在程序的任何地方。 增量测试利用已测试过的模块取代非增量测试中所需要的驱动模块或桩模块，这样对后续模块的测试会使得前面已测试过的模块得到更多的检验，因而整个程序的测试能取得较好的效果。,2018年10月14日,96,非增量测试相对于增量测试的优点是：在模块测试阶段可以并行工作。自顶向下测试与自底向上测试这是增量测试的两种不同方式。自顶向下测试是从顶端模块开始的测试，选择下一次测试的模块的原则是：至少有一个调用它的模块已经测试过。自底向上的方法是从程序的末端（即不调用别的模块的模块）开始测试的，选择

43、下一个测试模块的原则是：所有下层的模块（即它能调用的模块）必须事先都被测试过。,3.4 集成测试,将软件、硬件和环境连在一起全面的测试。 检查系统与需求说明是否相符； 不同系统测试内容不同。 结果评审 纠正错误： 需求错误 接口错误 设计错误 测试错误,3.5 系统测试阶段,2018年10月14日,98,3.5 系统测试,系统测试的特点： 系统测试的环境是软件真实运行环境的最逼真的模拟。系统测试中各部分研制完成的真实设备逐渐取代了模拟器或仿真器，有关真实性的一类错误，包括外围设备接口、输出/输入、或多处理器设备之间的接口不相容，整个系统时序匹配等，在这种运行环境下能得到比较全面的暴露。 系统测

44、试的困难在于不容易从系统目标直接生成测试用例。,2018年10月14日,99,3.5 系统测试,适用对象在真实或仿真环境中的计算机软件配置项。 进入条件完成并通过计算机软件配置项测试并已纳入配置管理。 测试内容在系统测试中,计算机软件配置项加入到系统中进行测试,以检验软件是否满足软件任务书规定的要求。应根据软件的复杂性,重要性,类型和关键级别,选择进行以下测试,但必须包括功能测试,性能测试和强化测试。,2018年10月14日,100,3.5 系统测试,系统功能测试； 系统性能测试； 软件和系统接口测试； 系统强化测试； 系统余量测试； 系统可靠性测试； 系统安全性测试； 系统恢复性测试； 系统

45、边界测试； 系统敏感性测试。,2018年10月14日,101,3.5 系统测试,具体要求 系统功能测试 测试在真实系统环境或系统仿真环境中软件的各项功能满足系统需求; 系统性能测试 测试在真实系统环境或系统仿真环境中软件的各项性能指标满足系统需求; 测试软件性能和硬件性能的集成; 软件和系统接口测试 测试软件对系统每一个真实接口的正确性.验证接口信息的内容和格式; 测试硬件提供的接口是否便于软件使用; 测试软件在真实系统环境或系统仿真环境中提供的人机交互接口,验证操作有效性,显示和信息输出清晰; 测试系统特性(如数据特性,错误特性,速度特性)对软件功能,性能特性的影响。,2018年10月14日

46、,102,3.5 系统测试,系统强化测试在真实系统环境或系统仿真环境中进行强化测试。系统余量测试软件在真实系统环境或系统仿真环境中运行时,测试系统全部存储量,输入/输出通道及处理时间的余量,应满足系统/子系统设计文档要求。系统可靠性测试在真实系统环境或系统仿真环境中进行可靠性测试。系统安全性测试在真实系统环境或系统仿真环境中进行安全性测试。,2018年10月14日,103,3.5 系统测试,系统恢复性测试对有恢复或重置(RESET)功能的系统,必须验证恢复或重置功能,对每一类导致恢复或重置的情况进行测试。验证软件自身运行的恢复或重置,软件控制的系统的恢复或重置,系统控制的软件的恢复或重置.系统

47、边界测试测试软件在系统输入域(或输出域),状态转换,功能界限,性能界限,容量界限等的边界或端点情况下的运行状态。系统敏感性测试包括软件可能的扩展性和系统电,磁,机械干扰对软件特性的影响。,2018年10月14日,104,测试进入条件,3.6 测试进入条件,2018年10月14日,105,3.6 测试进入条件,2018年10月14日,106,效率 发现的软件缺陷 / 总缺陷,认真进行上述6种测试，约可达到85%的检错效率，花费开发成本的33%45%,各种测试检测软件缺陷的效率,3. 软件生命周期中的软件测试,2018年10月14日,107,软件测试是软件工程中的一个子过程，为使软件测试工作系统化

48、、工程化，必须合理组织测试过程管埋，包括签定第三方独立测试合同、制定测试计划、组织项目人员、建立项目环境、监控项目进展等等。,4. 软件测试管理,2018年10月14日,108,测试工作流程,4. 软件测试管理,1)制定测试计划；包括活动的范围和测试方法：制定测试要素、如覆盖程度；明确测试终止的要求和异常终止的情况；确定资源要求；制定总的进度安排。 2)制定测试说明；确定需测试的特性；细化测试计划的有关内容（测试方法、所需资源、详细进度）；设计测试用例集，制定测试规程，给出相关的说明。 3)执行测试计划；实现测试设计（获得并验证测试数据，获得指定的资源，获得测试项）；执行测试规程（运行测试，判定结果、对每次失效加以记录、分析和解决）；核对终止情况（正常终止、必要是补充测试集）,2018年10月14日,109,4. 软件测试管理,测试工作流程,4) 评价传送效果和被测试软件；依照评价准则，评价测试工作和被测软件；当发现测试工作不足时，应修订测试计划，重复1）开始的工作，直到测试完备时止。 5) 产生完整的测试文档，包括测试计划、测试说明、测试报告或测试计划、测试分析报告。,