《软件工程 第7章：实现1编码风格与测试基础讲解》由会员分享，可在线阅读，更多相关《软件工程 第7章：实现1编码风格与测试基础讲解（85页珍藏版）》请在金锄头文库上搜索。
1、1.第7章：实 现 编码和测试统称为实现 编码：把软件设计结果翻译成程序 测试：检测程序并改正错误的过程 7.1 7.1 编码编码 机器语言几乎不使用 汇编语言特殊场合使用 高级语言优势明显、普遍使用 1. 1. 选择程序设计语言选择程序设计语言 （1）程序设计语言的划代 划代语语言特点级级 别别 1GL机器语语言 不直观观，出错错率高、运行效率 高 低 级级 2GL汇编语汇编语 言 比较较直观观，出错错率较较小 与机器码码一样长样长 特殊情况下使用 3GL BASIC PASCAL C、C+等 利用类类英语语的语语句和命令 一条语语句相当于5-10条机器码码 要规规定详细详细 的算法过过程
2、高 级级 4GL 数据库查询语库查询语 言 程序生成器 图图形语语言 与自然语语言接近 一条语语句相当于30-50条机器码码 非过过程化问题问题 定义义 运行开销销大，效率低 有理想的模块化机制 可读性好的控制结构和数据结构 便于调试和提高软件可靠性 编译时发现错误能力强 有良好的独立编译机制 （2）选择编程语言的理论标准 系统用户的要求 可以使用的编译程序 可以得到的软件工具 工程规模 程序员的知识 软件可移植性要求 软件的应用领域 （3）主要的实用标准 良好的编码风格：程序代码逻辑清晰，易读、易 理解、易维护，能高效利用系统资源等方面。 2. 编码风格 编码风格：又称程序设计风格，是程序设
3、计者在创 作中喜欢或习惯使用的表达自己作品的方式。 清晰第一、强调效率 内部文档、数据说明、语句构造、输入输出、效率 恰当的标识符 适当的注解 程序的视觉组织 （1）程序内部的文档 数据说明的次序应该标准化 多个变量时，应按字母顺序排列 复杂的数据结构，应用注明数据结构的方法 和特点 （2）数据说明 不要为了节省空间而把多个语句写在同一行 尽量避免复杂的条件测试 尽量减少对“非”条件的测试 避免大量使用循环嵌套和条件嵌套 利用括号使逻辑表达式或算术表达式的运算次序 清晰直观 （3）语句构造 输入数据的检验 输入项组合的合法性检查 输入格式要简单 使用数据结束标记 输入要求明确（可选项、边界值）
4、 输入格式一致性 良好的输出报表 给所有输出数据加标志 （4）输入输出 效率的三个基本原则 效率是性能要求（需求分析阶段确定） 良好的设计能有效的提高效率 不能牺牲清晰性和可读性来提高效率 （5）效率 运行效率 输入输出效率 存储器效率 u 简化算术和逻辑的表达式； u 减小嵌套循环的深度； u 避免使用多维数组； u 避免使用指针和复杂的表； u 使用执行时间短的算术运算； u 不要混合使用不同的数据类型； u 尽量使用整数运算和布尔表达式； u 使用有良好优化特性的编译程序。 提高运行效率途径 u 控制结构的功能域明确固定； u 尽量使用高级语言（硬件要求苛刻时使用紧缩存 储器特性的编译程
5、序以及汇编语言）； u 提高执行效率的技术通常也能提高存储器效率。 提高存储效率途径 关键简单 用户向计算机提供可理解的输入信息 计算机向用户提供可理解的输出信息 提高输入输出的效率措施 良 好 的 人 机 交 互 关键简单 u 输入/输出有缓冲（减少通信次数）； u 简单的辅存访问方法； u 辅存的输入/输出以块为单位； u 考虑终端外设的特性，以提高的质量和速度； u 不采用难以理解的超高效的输入/输出。 1.19 例1：注释 1./*add amount to total */ 2.TOTAL = AMOUNT+TOTAL 1./*add monthly-sales to annual-
6、total */ 2.TOTAL = AMOUNT+TOTAL 例2：视觉组织空格 1. (A17)ANDNOT(B49)ORC 1. (A17) AND NOT (B49) OR C 例3：视觉组织移行与缩进 1. IF () THEN 2. IF () THEN ELSE ENDIF ELSE ENDIF 例4：数据说明标准化 1. INTEGER size，length，width，cost，price 1. INTEGER cost，length，price，size，width 例5：一行一条语句 1. FOR I:=1 TO N-1 DO BEGIN T:=I; 2. FOR J:
7、=I+1 TO N DO 3. IF AJAT THEN T:=J; IF TI 4. THEN BEGIN WORK:=AT; 5. AT:=AI; AI:=WORK; END END; 1. FOR I:=1 TO N-1 DO 2. BEGIN 3. T:=I; 4. FOR J:=I+1 TO N DO 5. IF AJ=a) 2.if (char=z) 3. cout “This is a letter.”; 4.else 5. cout =a 3.else 4. cout = 0 & char = 9) 病人生病 打喷嚏、发高烧、流鼻涕 医生诊断 测血压、量体温，是否存 在数据异常
8、 医生确定症状根源 确定病人感冒 治疗与处方 处方 三天后复诊 测血压、量心跳 1.发现失效 1.观察错误 1.定位缺陷 1.处理缺陷 1.回归测试 测试：为了发现程序中的错误而执行程序的过程 1.1. 软件测试的 目标 7.2 软件测试基础 成功的测试：发现了以前未发现的错误 好的测试方案：有可能发现尚未发现的错误 2. 软件测试准则 测试应能追溯到用户需求； 在测试前就制定出测试计划； 把Pareto原理应用到软件测试中； 从“小规模”测试开始，逐步进行； 第三方测试，效果更佳； 有用户参与的测试，更完美。 测试只能证明缺陷的存在，但绝不能证明缺陷不存在 不可能做穷尽测试 3. 3. 软件
9、测试的基本原理软件测试的基本原理 Dijkstra定律: 假设一段接受六个字符密码的程序，并保证第一 个字符必须是数字，其余的是字符数字型。如果我们 的目标是穷尽测试，那么需要测试多少个输入数据的 组合呢？ 共有10（625）=9161328320 假设每个组合测试时间10秒，测试这些组合将用2905 年。 早测试，早发现，早解决 目标在用户发现缺陷之前找到缺陷 1.需求阶段 1.设计阶段 1.编码阶段 1.测试阶段 1.已发 现 2.的缺 陷 1.正确 的需求 1.正确 的设计 1.正确 的编码 1.需求 中的缺 陷 1.需求 中的缺 陷 1.需求 中的缺 陷 1.需求 中的缺 陷 1.设计
10、 中的缺 陷 1.设计 中的缺 陷 1.设计 中的缺 陷 1.代码 中的缺 陷 1.代码 中的缺 陷 1.没有发 现的缺陷 1.早期阶段产生的缺陷传递过程 1.缺陷对软件成本的综合作用 1.10 1.100 1.1000 1.需求 设计 编码 测试 交付后 1.代 价 3W1H（Why、What、Where、How）同 样重要！ 有缺陷的测试用例比有缺陷的产品更危险 ！ 测试用例需要逐步完善； 缺陷的集群中效应 1.已发现的缺陷 1.尚未发现的缺陷 1.缺陷对软件成本的综合作用 缺陷预防和缺陷检测间的精心平衡 钟摆的终结 1.关注缺陷预防 1.关注缺陷检测 最后一分钟匆忙 质量更依赖测试人员
11、测试者是“英雄”、“对手” 占用资源但可得到好的回报 质量制度化 使质量对用户可见 不是一个健康的状态！ 没有标准，缺陷滋生 缺少检测，缺陷到达用户 双刃剑 过度注重过程 缺少检测，缺陷到达用户 自信的团队、信任的团队 为“测试”而自豪，就会处理好“所有的一切” De Marco、Lister 人件黑衣团队 职业测试的最大瓶颈是缺乏自信 自动化综合症 自动化失败的例子比成功的多 重复的劳动必然导致自动化，对自动化缺乏了解必 然导致测试的失败 根据现有的软件测试知识，以下哪种产品可 以认为是高质量的？对自己的答案进行说明 。 请思考： A产品连续三个版本分别发现0、79和21个缺陷。 B产品连续
12、三个版本分别发现85、90和79个缺陷。 （1）定义 缺陷（Faults） 错误（Errors） 失效（Failures） 4. 4. 软软软软件缺陷（件缺陷（BugBug） 计算机系统或程序中存在的任何破坏正常运行能力 的问题、错误，或者隐藏的功能缺陷、瑕疵，导致软件 产品在某种程度上不能满足用户的需要。 技术问题 软件本身 团队协作问题 （2 2）缺陷的产生的因素）缺陷的产生的因素 （3 3）缺陷的构成）缺陷的构成 功能理解 特性描述 需求变化 重视不够 沟通不够 （4 4）缺陷的修复代价）缺陷的修复代价 1 3-6 10 20-70 40-1000 Boehm Software Engi
13、neering Economic （5）测试阶段的信息流 1.测 试 1.评 价 1.调 试 1.可 靠性 模型 1.软件配置 1.测试配置 1.测 试结 果 1.预期结果 1.错误 1.错误率数据 1.正确 1.可靠性预测 1.测试阶段的信息流 7.3 软件测试类型 1.软 件 2.测 试 1.是否运 行程序 1.静态测 试 1.动态测 试 1.功能测 试 1.性能测 试 1.逻辑功能测 试 1.界面测试 1.易用性测试 1.安装测试 1.兼容性测试 1.一般性能测 试 1.稳定性测试 1.负载测试 1.压力测试 1. 1.2 2 4 4 1 1 3 3 1.其它 1.回归测 试 1.冒烟测
14、 试 1.随机测 试 1.本地化测 试 1.ALAC测 试 1.阶段 1.单元测 试 1.集成测 试 1.系统测 试 1.验收测 试 1.测试 1.测试 1.是否查 看源代码 1.白盒测 试 1.黑盒测 试 1.灰盒测 试 1.1. 黑盒测试和白盒测试黑盒测试和白盒测试 功能测试 / 基于规格说明的测试 / 数据驱动测试 （1 1）黑盒测试）黑盒测试 观点：任何程序都可以看作是从输入定义域到 输出值域的映射，把被测程序看作一个打不开 的黑盒，黑盒里面的内容(实现)是完全不知道 的，只知道软件要做什么（功能）。 1.黑盒测试 2.的内容 1.不正确或遗漏了的功能 1.正确地接受输入数据 2.并产生正确地输出 1.界面出错和界面美观问题 1.安装中的出现的问题 1.初始化和终止错误问题 1.操作逻辑问题 测试用例重用不关心软件实现 缩
