单元测试-STMT省公开课金奖全国赛课一等奖微课获奖课件

软件测试方法和技术

-Ch.5单元测试tscxjtu@163.comleontscxjtu@163.com1/33第三四章不讲tscxjtu@163.com软件质量标准软件测试规范

CMM思想和结构体系建立软件测试管理和评判体系2/33第五章单元测试tscxjtu@163.com5.1什么是单元测试5.2单元测试目标和任务5.3静态测试技术利用5.4动态测试技术利用5.5调试与评定5.6单元测试过程与文档管理5.7单元测试惯用工具介绍3/335.1什么是单元测试测试4个阶段：单元测试

集成测试

系统测试

验收测试按阶段进行测试是一个基本测试策略tscxjtu@163.com4/335.1什么是单元测试程序员喝酒比喻大家喝是啤酒。这时你入座了。你给自己倒了杯可乐，这叫低配置。你给自已倒了杯啤酒，这叫标准配置。你给自己倒了杯茶水，这茶颜色还跟啤酒一样，这叫木马。你给自己倒了杯可乐，还滴了几滴醋，不但颜色跟啤酒一样，而且不冒热气还有泡泡，这叫超级木马。你同事给你倒了杯白酒，这叫推荐配置。人到齐了，酒席开始了。你先一个人喝了一小口，这叫单元测试。你跟旁边人说哥们咱们随意，这叫交叉测试。不过他说不行，这杯要干了，这叫压力测试。于是你说那就大家一起来吧，这叫内部测试。这个时候boss向全场举杯了，这叫公开测试。tscxjtu@163.com5/335.1什么是单元测试菜过三巡，你就不跟他们客气了。你向对面人敬酒，这叫p2p.你向对面人敬酒，他回敬你，你又再敬他……，这叫tcp.你向一桌人挨个敬酒，这叫令牌环。你说只要是弟兄就干了这杯，这叫广播。可是你上司jj听了不高兴了，只有弟兄么，罚酒三杯。这叫炸弹。可是你下级mm听了不高兴了，我喝一口，你喝一杯，这叫恶意攻击。有一个人过来向这桌敬酒，你说不行你先过了我这关，这叫防火墙。你小弟们过来敬你酒，这叫一对多。你是boss，全部些人过来敬你酒，这叫服务器。酒是一样，可是喝法是不一样。你喝了一杯，boss喝了一口，这叫c#。你喝了一杯，mm喝了一口，这叫vb。你喝了一杯，你大哥喝了半杯，这叫c++。你喝了半杯，你小弟喝了一杯，这叫汇编。你喝了一杯，你搭档也喝了一杯，这叫c。tscxjtu@163.com6/335.1什么是单元测试酒是一样，可是喝酒人是不一样。你越喝脸越红，这叫频繁分配释放资源。你越喝脸越白，这叫资源不释放。你已经醉了，却说我还能喝，叫做资源额度不足。你明明能喝，却说我已经醉了，叫做资源保留。你喝一段时间就上厕所，这叫cache。酒过三巡，你也该活动活动了。你一桌一桌走，这叫轮巡。你突然看到某一桌漂亮mm，走了过去，这叫优先级。你去了坐下来就不打算走了，这叫死循环。你老大举杯邀你过去，你只好过去，这叫开启事件。你向一桌敬酒，他们说不行不行我们都喝白，于是你也喝白，这叫当地化。你向boss敬酒，可是boss被围了起来，你只能站在外圈，这叫排队。你终于到了内圈，小心翼翼向前一步，这叫访问临界区。你拍着boss肩膀说哥们咱们喝一杯，这叫越界。你不知喝了几圈了，只会说两个字，干了，这叫udp。可是还有些人拿着酒瓶跑过来说，刚才都没跟你喝，这叫丢包。tscxjtu@163.com7/335.1什么是单元测试喝酒喝到最终结果都一样你突然跑向厕所，这叫捕捉异常。你在厕所吐了，反而以为状态不错，这叫清空内存。你在台面上吐了，以为很惭愧，这叫程序异常。你在boss面前吐了，以为很害怕，这叫系统瓦解。你吐到了boss身上，只能索性晕倒了，这叫硬件休克。

tscxjtu@163.com8/33单元测试定义定义:单元测试是对软件基本组成单元进行测试。时机:普通在代码完成后由开发人员完成,QA人员辅助.概念:模块,组件,单元单元测试对象是软件设计最小单位——模块。单元经常被误解为详细函数或一个类方法。一个最小单元应该有明确功效、性能定义、接口定义并能够清楚地与其它单元区分开来。

tscxjtu@163.com9/33为何要进行单元测试?尽早发觉错误错误发觉越早,成本越低.开发人员过于自信,后期复杂度高,发觉处理BUG困难.检验代码是否符合设计和规范

tscxjtu@163.com12小时6小时3小时单元测试集成测试系统测试10/335.2单元测试目标和任务目标:

单元模块被正确编码详细目标：信息能否正确地流入和流出单元；在单元工作过程中，其内部数据能否保持其完整性，包含内部数据形式、内容及相互关系不发生错误，也包含全局变量在单元中处理和影响。在为限制数据加工而设置边界处，能否正确工作。单元运行能否做到满足特定逻辑覆盖。单元中发生了错误，其中犯错处理办法是否有效。tscxjtu@163.com11/33任务1：模块接口测试检验模块接口是否正确Checklist:输入实际参数与形式参数是否一致。个数、属性、量纲调用其它模块实际参数与被调模块形参是否一致。个数、属性、量纲全程变量定义在各模块是否一致。外部输入、输出文件、缓冲区、错误处理其它tscxjtu@163.com12/33任务2：模块局部数据结构测试检验局部数据结构完整性Checklist:不适合或不相容类型说明。变量无初值。变量初始化或默认值有错。不正确变量名或从来未被使用过。出现上溢或下溢和地址异常。其它tscxjtu@163.com13/33任务3：模块边界条件测试检验临界数据处理正确性（单元测试中最主要一项任务）Checklist:普通正当数据处理。普通非法数据处理。边界值内正当边界数据处理。边界值外非法边界数据处理。其它tscxjtu@163.com14/33任务4：模块独立执行通路测试检验每一条独立执行路径测试。确保每条语句被最少执行一次。Checklist:算符优先级。混合类型运算。精度不够。表示式符号。循环条件，死循环。其它tscxjtu@163.com15/33任务5：模块各条错误处理通路测试预见、预设各种犯错处理是否正确有效。Checklist:输出犯错信息难以了解。统计错误与实际不相符。程序定义犯错处理前系统已介入。异常处理不妥。未提供足够定位犯错信息。其它tscxjtu@163.com16/335.3静态测试技术利用静态测试技术：不运行被测试程序，对代码经过检验、阅读进行分析。三步曲：走查（WalkThrough）。审查（Inspection）。评审（Review）tscxjtu@163.com17/33编码标准和规范标准：建立起来必须恪守规则。规范：提议最正确做法，推荐更加好方式。实施标准和规范原因：可靠性。可读性和可维护性。可移植性。如Java代码书写规范、C语言编码标准等tscxjtu@163.com18/33走查（WalkThrough）定义：采取讲解、讨论和模拟运行方式进行查找错误活动。注意：引导小组组员在走查前通读设计和编码。限时，防止跑题。发觉问题适当统计，防止现场修改。检验关键点是代码是否符合标准和规范，是否有逻辑错误。tscxjtu@163.com19/33审查（Inspection）定义：采取讲解、提问方式进行，普通有正式计划、流程和结果。主要方法采取缺点检验表。注意：以会议形式，制订会议目标、流程和规则，结束后要编写汇报。按缺点检验表逐项检验。发觉问题适当统计，防止现场修改。发觉重大缺点，更正后会议需要重开。检验关键点是缺点检验表，所以该表要依据项目不一样不停积累完善。tscxjtu@163.com20/33走查与审查比较tscxjtu@163.com走查审查准备通读设计和编码应准备好需求描述文档、程序设计文档、程序源代码清单、代码编码标准和代码缺点检验表形式非正式会议正式会议参加人员开发人员为主项目组组员包含测试人员主要技术方法无缺点检验表注意事项限时、不要现场修改代码限时、不要现场修改代码生成文档会议统计静态分析错误汇报目标代码标准规范，无逻辑错误代码标准规范，无逻辑错误21/33评审（Review）定义：通常在审查会后进行，审查小组依据统计和汇报进行评定。注意：充分审查了所要求代码，而且全部编码准则被恪守。审查中发觉错误已全部修改。tscxjtu@163.com22/335.4动态测试技术利用动态测试需要真正将程序运行起来，需要设计系列测试用例确保测试完整性和有效性。白盒测试黑盒（灰盒）测试tscxjtu@163.com23/33白盒测试方法主要要逻辑驱动法和基本路径法。语句覆盖。判定覆盖。条件覆盖。判定/条件覆盖。条件组合覆盖。路径覆盖。循环覆盖。tscxjtu@163.com详细内容第14章软件测试用例设计24/33黑盒测试方法运行单元程序有时需要基于被测单元接口，开发对应驱动模块和桩模块（根）。有些参考书误导：单元测试采取白盒测试技术，由开发人员完成。驱动模块（drive）:对底层或子层模块进行测试所编写调用这些模块程序。桩模块（stub）：对顶层或上层模块进行测试时所编写替换下层模块程序。tscxjtu@163.com25/33黑盒惯用方法等价类划分法边界值分析法三种数据：错误推测法--正常数据因果图法--错误数据功效图法--边缘数据另外还得考虑接口测试、性能测试、内存测试性能分析内存分析tscxjtu@163.com26/335.6调试与评定调试与测试对象及采取方法有很大程度上相同，调试还用到断点控制等排错方法，但其目标却完全不一样。测试是为了找出软件中存在缺点，而调试是为了处理存在缺点。单元测试经过普通准则：软件单元功效与设计需求一致。

软件单元接口与设计需求一致。能够正确处理输入和运行中错误。在单元测试中发觉错误已经得到修改而且经过了测试。到达了相关覆盖率要求。完成软件单元测试汇报tscxjtu@163.com27/33单元测试检验表(1)借助单元测试检验表进行评定。案例：单元测试检验表单元名称___________系统_______________结构______________任务编号____________________首次测试日期_________________关键测试项是否已纠正有没有任何输入参数没有使用？有没有任何输出参数没有产生？有没有任何数据类型不正确或不一致？有没有任何算法与PDL或功效需求中描述不一致？有没有任何局部变量使用前没有初始化？有没有任何外部接口编码错误？即调用语句、文件存取、数据库错误。有没有任何逻辑路径错误？该单元是否有多个入口或多个正常出口？tscxjtu@163.com28/33单元测试检验表(2)额外测试项8.该单元中有任何地方与PDL与PROLOG中描述不一致？9.代码中有没有任何偏离本项目标准地方？10.代码中有没有任何对于用户来说不清楚错误提醒信息？11.假如该单元是设计为可重用，代码中是有可能妨碍重用地方？采取动作和说明（请用单独一页或多页。每一项动作必须指出所引用问题。）审查结果1.假如上述11个问题答案均为"否"，那么测试经过，请在此标识而且在最终署名。2.假如代码存在严重问题，比如多个关键问题答案为"是"，那么程序编制者纠正这些错误，而且必须重新安排一次单元测试。下一次单元测试日期：_________________________3.假如代码存在小缺点，那么程序编制者纠正这些错误，而且仲裁者必须安排一次跟踪会议。跟踪会议日期：_________________________测试人署名：_____