【delphi开源代码栏目提醒】:网学会员鉴于大家对delphi开源代码十分关注,论文会员在此为大家搜集整理了“Ch5-单元测试-STMT PDF - 综合课件”一文,供大家参考学习
Zhu.Kerrygmail.com 朱少民 Kerry Zhu Zhu.Kerrygmail.com 第2版 5 第4章 回顾 Zhu.Kerrygmail.com 4.1 测试过程模型 V模型、W模型、TMap 4.2 测试过程改进模型 TMM、TPI、CTP、STEP 4.3 软件测试标准和规范 4.4 建立软件测试管理和评判体系 第二篇 软件测试的技术 在实际项目的测试过程中我们会面对许多复杂的问题和具体的困难不仅要采用前面所学的方法还要拥有很好的技术熟悉业务领域知识深入系统架构、设计模式和开发框架灵活运用测试工具才能真正解决问题。
第5章 单元测试 第6章 集成测试和系统测试 第7章 验收测试 第8章 面向对象软件的测试 第9章 基于应用服务器的测试 第10章 软件本地化测试 第11章 软件测试自动化 第五章 单元测试 Zhu.Kerrygmail.com 5.1 什么是单元测试 5.2 单元测试的目标和任务 5.3 静态测试 5.4 驱动程序和桩程序 5.5 调试与评估 5.6 单元测试的管理 5.7 单元测试工具 5.1 测试的测试的44个阶段个阶段 单元测试单元测试集成测试集成测试 系统测试系统测试验收测试验收测试 按阶段进行测试是一种基本的测试策略 Zhu.Kerrygmail.com 定义: 单元测试是对软件基本组成单元进行的测试。
时机: 一般在代码完成后由开发人员完成QA人员辅助. 概念: 模块 组件 单元 Zhu.Kerrygmail.com 尽早发现错误 错误发现越早成本越低. 开发人员过于自信后期复杂 度高发现解决BUG困难. 检查代码是否符合设计和规范 Zhu.Kerrygmail.com 12小时 6小时 3小时 单元测试 集成测试 系统测试 开发流程时间表与修改Bug代价的关系图 开发结束开发结束 开发早期开发早期 修改代价修改代价 Zhu.Kerrygmail.com 续 编程过程中每写100行代码会犯150个错误 编程与编译运行结束后每100行代码中大约残留有1-3个Bug 寻找与修改程序错误的代价占总体开发投资的40-80 Bug在整个研发流程中被发现的越早修改的代价就越低 Zhu.Kerrygmail.com 5.2 目标: 单元模块被正确编码 信息能否正确地流入和流出单元 在单元工作过程中其内部数据能否保持其完整性包括内部数据的形式、内容及相互关系不发生错误也包括全局变量在单元中的处理和影响。
在为限制数据加工而设置的边界处能否正确工作。
单元的运行能否做到满足特定的逻辑覆盖。
单元中发生了错误其中的出错处理措施是否有效。
Zhu.Kerrygmail.com 检查每一条独立执行路径的测试。
保证每条语句被至少执行一次。
Checklist: 误解或用错了算符优先级。
混合类型运算。
变量初值错 。
精度不够 。
表达式符号错 。
其它 Zhu.Kerrygmail.com 2 检查局部数据结构完整性 Checklist: 不适合或不相容的类型说明。
变量无初值。
变量初始化或默认值有错。
不正确的变量名或从来未被使用过。
出现上溢或下溢和地址异常。
其它 Zhu.Kerrygmail.com 检查模块接口是否正确checklist: 输入的实际参数与形式参数是否一致。
个数、属性、量纲 调用其他模块的实际参数与被调模块的形参是否一致。
个数、属性、量纲 全程变量的定义在各模块是否一致。
外部输入、输出 文件、缓冲区、错误处理 其它 Zhu.Kerrygmail.com 检查临界数据处理的正确性 Checklist: 普通合法数据的处理。
普通非法数据的处理。
边界值内合法边界数据的处理。
边界值外非法边界数据的处理。
其它 Zhu.Kerrygmail.com 5 预见、预设的各种出错处理是否正确有效。
Checklist: 输出的出错信息难以理解。
记录的错误与实际不相符。
程序定义的出错处理前系统已介入。
异常处理不当。
未提供足够的定位出错的信息。
其它 Zhu.Kerrygmail.com Microsoft Zhu.Kerrygmail.com 验证产品实现符合功能规格书 验证产品代码运行的正确性 边缘条件测试 产品安全性测试 从已有Bug增加的回归测试 产品代码覆盖度测试Code Coverage 产品代码注射测试Code Injection 异常测试 Zhu.Kerrygmail.com 产品速度性能的比较测试 产品极限情况测试 产品与国际标准的兼容性测试 产品与以前版本的操作系统文件格式的兼容测试 同一产品不同版本共同运行的兼容性测试 产品在不同语言操作系统下的运行测试 Zhu.Kerrygmail.com 测试过程从产品设计开始 Spec Review 非常重要 微软产品Spec Review演示 Sharepoint Server的应用 测试代码编写由软件开发设计者SDE自己开始 DRT Developer Regression Test的重要性 没有相随的DRT Feature Area不算开发完 DRT不全部编译并100通过不允许Check-in 测试组的测试不100编译并100通过0级测试BVT 70通过1级测试不允许Check-in Zhu.Kerrygmail.com 续 测试代码主体由软件测试工程师SDETSTE编写 测试从写软件测试规格书Test Spec开始 Test Spec必须通过PMDev与同组Tester共同开会研究通过 测试代码根据不同测试的情景分为0-4级的优先级 0级测试称为BVT Build Verification Test 在Dev主要的功能实现Check-in前0-1级测试代码必须已由测试工程师完成 在Dev进行Check-in时0级测试必须100通过 Zhu.Kerrygmail.com 续 在Dev进行Check-in时1级测试必须至少有70通过 Dev进行产品代码的Check-in Test进行测试代码的Check-in 产品编译由Build团队每日进行 Test编译由测试团队在产品编译完成后进行 测试编译完成后由测试自动化系统进行测试 在随后的代码优化与稳定期内测试工程师编写2-4级测试代码并报告产品BugDev负责修改Bug稳定并优化产品 Zhu.Kerrygmail.com 5.3 静态测试技术 不运行被测试程序对代码通过检查、阅读进行分析。
三步曲 走查 Walk Through。
审查 Inspection。
评审 Review Zhu.Kerrygmail.com 标准建立起来必须遵守的规则。
规范建议最佳做法推荐更好方式。
实施标准和规范的原因 可靠性。
可读性和可维护性。
可移植性。
Zhu.Kerrygmail.com Walk Through 定义采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
注意 引导小组成员在走查前通读设计和编码。
限时避免跑题。
发现问题适当记录避免现场修改。
检查要点是代码是否符合标准和规范是否有逻辑错误。
Zhu.Kerrygmail.com Inspection 定义采用讲解、提问方式进行一般有正式的计划、流程和结果。
主要方法采用缺陷检查表。
注意 以会议形式制定会议目标、流程和规则结束后要编写报告。
按缺陷检查表逐项检查。
发现问题适当记录避免现场修改。
发现重大缺陷改正后会议需要重开。
检查要点是缺陷检查表所以该表要根据项目不同不断积累完善。
Zhu.Kerrygmail.com Zhu.Kerrygmail.com 走 查 审 查 准备 通读设计和编码 应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表 形式 非正式会议 正式会议 参加人员 开发人员为主 项目组成员包括测试人员 主要技术方法 无 缺陷检查表 注意事项 限时、不要现场修改代码 限时、不要现场修改代码 生成文档 会议记录 静态分析错误报告 目标 代码标准规范无逻辑错误 代码标准规范无逻辑错误 Review 定义通常在审查会后进行审查小组根据记录和报告进行评估。
注意 充分审查了所规定的代码并且全部编码准则被遵守。
审查中发现的错误已全部修改。
Zhu.Kerrygmail.com 5.4 动态测试需要真正将程序运行起来需要设计系列的测试用例保证测试的完整性和有效性。
白盒测试 黑盒灰盒测试 Zhu.
上一篇:
基于构件的物流软件开发模式探索输
下一篇:
让我掉下眼泪的