第二篇软件测试的技术从方法到技术，熟悉业务领域知识，深入系统架构、设计模式和开发框架，灵活运用测试工具，才能真正解决问题第5章单元测试
与集成测试第6章系统测试第7章验收测试第8章软件本地化测试第9章测试自动化及其框架软件测试方法和技术第5章单元
测试与集成测试第五章单元测试与集成测试5.1单元测试的目标和任务5.2静态测试5.3动态测试5.4代码评审案例5.5分
层单元测试5.6单元测试工具5.7系统集成的模式与方法5.1单元测试的目标和任务5.1.1单元测试的目标和要求1、单元测试的
目的尽早发现错误2、定义单元测试是对软件基本的组成单元进行独立的测试,而且软件单元是在与程序的其他部分相隔离的情况下进行独立的
测试。5.1单元测试的目标和任务3、测试对象软件设计的最小单位：一个具体函数，或一个类的方法，也可以是一个功能模块、组件。4、
测试目标（1）总体目标：检验各单元模块是否被正确编码，即检查代码是否符合设计和规范。同时还需确保代码在结构上可靠且健壮。概括起来单
元测试是对单元代码的规范性、正确性、安全性、性能等进行验证。5.1单元测试的目标和任务（2）分类目标信息能否正确地流入和流出单元
在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，全局变量在单元中的处理和影响数据处理的
边界处，能否正确工作单元的运行能否做到满足特定的逻辑覆盖单元中发生了错误，其中的出错处理措施是否有效指针是否被错误引用、资源是否被
及时释放有没有安全隐患？是否使用了不恰当的字符串处理函数5.1单元测试的目标和任务5、单元测试的一般准则软件单元功能与设计需求一致
软件单元接口与设计需求一致能够正确处理输入和运行中的错误在单元测试中发现的错误已经得到修改并通过了测试达到了相关的覆盖率要求完成软
件单元测试报告5.1单元测试的目标和任务5.1.2单元测试的任务任务１:模块独立执行路径测试检查每一条独立执行路径的测试，并保
证每条语句被至少执行一次。Checklist:误解或用错了算符优先级混合类型运算变量初值错精度不够表达式符号错其
它测试方法举例：判定覆盖条件覆盖基本路径覆盖5.1.2单元测试的任务任务2:局部数据结构测试检查局部数据结构正确性、完整性Che
cklist:不适合或不相容的类型说明变量无初值变量初始化或默认值有错不正确的变量名或从来未被使用过出现上溢或下溢和地址
异常其它5.1.2单元测试的任务任务３:模块接口测试检查模块接口是否正确checklist:输入的实际参数与形式参数是否一致(
个数、属性、量纲)调用其他模块的实际参数与被调模块的形参是否一致。(个数、属性、量纲)调用预定义函数时所用参数的个数、属性和次序是
否正确全程变量的定义在各模块是否一致。是否存在与当前入口点无关的参数引用是否修改了只读型参数是否把某些约束作为参数传递5.1.2
单元测试的任务任务３:模块接口测试如果单元内包括外部输入输出（打开某文件、读入文件数据、向数据库写入等）checklist:文件
属性是否正确OPEN/CLOSE语句是否正确格式说明与输入输出语句是否匹配缓冲区大小与记录长度是否匹配文件使用前是否已经打开是否处
理了文件尾是否对异常输入输出进行判断输出信息中是否有格式错误5.1.2单元测试的任务任务４:单元边界条件测试检查临界数据处理的正
确性Checklist:普通合法数据的处理。普通非法数据的处理。边界值内合法边界数据的处理。边界值外非法边界数据的处理。
其它5.1.2单元测试的任务任务5:单元容错测试预设的各种出错处理是否正确有效。Checklist:输出的出错信息难以理解
记录的错误与实际不相符异常处理不当未提供足够的定位出错的信息其它5.2静态测试技术5.2.1编码的标准和规范5.2.2
代码评审5.2静态测试技术静态测试技术：不运行被测试程序，对代码通过检查、阅读进行分析。三步曲：互查（PeerReview
）走查（WalkThrough）评审（Inspection）5.2静态测试技术5.2.1编码的标准和规范标准：建
立起来必须遵守的规则规范：建议最佳做法，推荐更好方式实施代码规范的原因：可靠性可读性和可维护性可移植性5.2.1编码的标准
和规范编码标准示例（MISRA的C语言编码标准）（1）不得使用类型char，必须显式声明为unsignedchar或者signe
dchar。（2）所有数字常数应当加上合适的后缀表示，例如51L，42F（3）不得定义与外部作用域中某个标识符同名的对象，以避免
遮盖外部作用域中的标识符。（4）具有文件作用域的对象尽量声明为static（5）同一个编译单元中，同一个标识符不应该同时具有内部链
接和外部链接的声明。5.2.1编码的标准和规范Java代码书写规范一、目的二、整体编码风格1、缩进2、空格3、对齐4、空行5、注
释6、代码长度7、页宽8、行数三、代码文件风格四、函数编码风格五、符号风格5.2.2代码评审代码审查是一种有效的测试方法。据有
关统计，代码中60%以上的缺陷可以通过代码审查（包括互查、走查、会议评审等形式）发现出来。代码互查一次检查少于200～400行代码
努力达到一个合适的检查速度：300～500LOC/hour有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟在复审前
，代码作者应该对代码进行注释使用检查表（checklist）肯定能改进双方（作者和复审者）的结果验证缺陷是否真正被修复……htt
p://smartbear.com/docs/BestPracticesForPeerCodeReview.pdfBestPra
cticesforPeerCodeReview(?http://www.smartbearsoftware.com/ww
w.SmartBearSoftware.com)示例走查（WalkThrough）定义：采用讲解、讨论和模拟运行的方式进行的查
找错误的活动。注意：引导小组成员在走查前通读设计和编码。限时，避免跑题发现问题适当记录，避免现场修改检查要点是代码是否符合
标准和规范，是否有逻辑错误审查（Inspection）以会议形式，制定目标、流程和规则按缺陷检查表（不断完善）逐项检查发现
问题适当记录，避免现场修改发现重大缺陷，改正后会议需要重开。走查与审查的比较走查审查准备通读设计和编码事先准备Spe
c、程序设计文档、源代码清单、代码缺陷检查表等形式非正式会议正式会议参加人员开发人员为主项目组成员包括测试人员主要技术方法无缺陷检
查表生成文档会议记录静态分析错误报告目标代码标准规范无逻辑错误代码标准规范无逻辑错误5.2.2代码评审缺陷检查表通常是把程序设计
中可能发生的各种缺陷进行分类，以每一类列举尽可能多的典型缺陷，然后把它们制成表格，以供在会议中使用，并且在每次审议会议之后，对新发
现的缺陷也要进行分析和归类，不断充实缺陷检查表。代码评审通用检查表1.格式2.程序语言的使用3.数据引用错误4.数据声明错误5.计
算错误6.比较错误7.入口出口的连接8.存储器的使用9.控制流程错误10.子程序参数错误11.输入输出错误12.逻辑和性能13.维
护性和可靠性5.3动态测试动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。5.3.1驱动程序和
桩程序5.3.2类测试5.3动态测试5.3.1驱动程序和桩程序运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模
块。驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。桩模块（stub）：对顶层或上层模块进行测试时所编
写的替代下层模块的程序。5.3.1驱动程序和桩程序示例：大型网络服务系统，需实现多台数据库服务器的数据实时复制。当前数据传输模块开
发完成。测试人员对该模块进行性能测试。（1）根据设计文档中的性能指标、网络运行环境指标和服务器环境等指标搭建测试环境。（2）根据程
序接口设计测试驱动程序和桩程序。驱动模块被测试单元驱动模块同一个小程序即作驱动模块又作桩模块。模拟数据库的数据，随机产生可设置大小
的数据包，按设置好的单位时间发包数量进行数据包发送，同时也可以接收数据，并对接收到的数据包数量和大小进行统计5.3.1驱动程序和桩
程序（3）设计测试用例并实施测试。根据指标考虑数据包的大小和频率，如大包低频或小包高频；考虑两个驱动程序的数据对发；从两个驱动程序
变多个驱动程序的数据对发；从同一网段变为多个网段，验证代理服务器或网关造成的影响。（4）发现问题先排除网络故障，再报告开发人员进行
调试。5.3动态测试5.3.2类测试类测试要验证类的实现是否和该类的说明完全一致。如果类实现正确，那么类的每一个实例的行为也
应该正确。类的测试不能限定在子类中定义的成员变量和成员方法上，需要考虑父类对子类的影响。在最复杂的情况下，对于子类的测试可能只能采用展平测试的策略。所谓展平测试就是将子类自身定义的成员方法和成员变量以及从父类继承来的成员方法与成员变量全部放在一起组成一个新类，并对其进行测试。5.4代码评审案例分析空指针保护案例分析5.4代码评审案例分析格式化数字错误案例分析5.4代码评审案例分析字符串或数组越界案例分析35.4代码评审案例分析资源不合理使用 |
|
