第六篇 实现.pptVIP

第六章 实现 实现:编码与测试 编码:设计结果用程序设计语言书写 程序设计语言与编码风格影响程序的可靠性、可读性、可测试性和可维护性 6.1 编码 选择程序设计语言 软件用户对编程语言的要求 系统运行环境要求 工程规模 可使用的软件工具 程序员掌握的编程语言 软件可移植性要求 软件的应用领域 编程语言 汇编 面向过程 C PASCAL 面向对象 C++ 托管类 C#，Java 基于框架开发 6.1 编码 编码方法 控制结构 If(age50) then GetMoney=min Elseif(age60) then GetMoney*2 Elseif(age70) then GetMoney*2+bonus Else GetMoney=max 算法 平衡效率与设计质量、标准、需求之间的关系 注意程序优化 数据结构 数据结构影响程序 6.1 编码 编码标准和规范 规范：建议的最佳做法、推荐的好方法 标准：必须遵守 编码风格 程序内部文档 恰当的标识符、注释和程序组织 变量命名：例如：C++的编程命名原则 注释：头注释、程序间注释（块注释、单行注释、尾注释、） 头注释：名称，参数、开发者、日期、功能描述、版本等 程序间注释：说明一段程序的功能或算法 程序组织 缩进、空行、续行 6.1 编码 数据说明 数据结构是设计时确定的，数据说明的风格是编程时确定的 数据说明的次序（如按数据类型说明） 复杂的数据结构应说明用程序设计语言实现数据结构的方法和特点 语句编写 不要因节省空间而把多行写成一行 尽量避免复杂的条件测试 尽量减少对“非”的测试 避免使用循环嵌套和条件嵌套 使用括号使逻辑表达式和算术表达式的运算次序清晰 写程序前简化算术或逻辑表达式 分析嵌套，是否有语句可以移出嵌套 尽量避免多维数组 避免使用指针和复杂的表 使用执行时间短的算术运算 不要混合使用不同的数据类型 尽量使用整数运算和布尔运算 6.1 编码 输入与输出 对所有输入进行检验 检查输入项重要组合的合法性 输入风格尽量简单 设计良好的输出报表 6.2 软件测试基础 测试的目的:尽可能发现并排除软件中潜藏的错误 软件测试的目标 测试是为了发现程序中的错误而执行程序的过程； 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； 成功的测试是发现了至今为止尚未发现的错误的测试。 测试:为了发现程序中的错误而执行程序的过程 测试不能证明程序是正确的 6.2 软件测试基础 软件测试的准则 所有的测试都应该能追溯到用户需求。 应该在测试开始之前的相当长时间，就制定出测试计划。 测试应该从“小规模”开始，并逐步进行“大规模”测试。 穷举测试是不可能的。 把Pareto原理应用于软件测试。Pareto原理告诉我们，测试发现的错误中的80%很可能是由程序中20%的模块造成的。问题在于如何孤立这些有疑点的部分并进行彻底地测试。 测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。应该由独立的第三方来从事测试工作。 6.2 软件测试基础 测试方法 白盒测试、黑盒测试 测试步骤 6.2 软件测试基础 6.2 软件测试基础 错误类型 算法: 由于处理步骤的错误，当一个组件的算法或逻辑对于给定的输入不能产生正确的输出时，一个算法错误产生了 典型的算法错误包括 分支过早 分支过晚 对错误条件检查 忘记初始化变量或者设置循环常数 忘记检查特殊条件（例如当除以零时发生） 比较两个不恰当数据类型的变量 压力过载 需求规格描述通常详细记录了系统中用户和设备的数量，通讯的需求。有了这些信息，设计者经常考虑系统的特性而不考虑可能超过需求中描述的最大负载情况。这些特性诸如队列长度、缓冲区大小、表的维度等等将贯穿程序设计始终。当这些数据结构超过其容量大小时将发生重压（stress）和超载错误 6.2 软件测试基础 容量、边界错误 当系统运行达到规定上限时，系统的性能变得不可接受时，容量（capacity）、边缘错误（boundary faults）发生。例如，如果需求描述规定系统必须处理32设备，程序必须经过所有32个设备运行时监测系统的行为的测试。而且，系统还要在可能的配置下测试超过32个设备运行时系统的运行情况。通过测试和文档记载系统对超载的反应，测试小组能够帮助维护小组确定在未来增加系统容载的结果。容载状况跟磁盘访问的数量，中断的数量，并发运行任务的数量，诸如此类的系统相关指数相关。 时间协同错误 开发实时系统时，首要考虑的是协调一些并行执行或按照预定义顺序执行的进程。当代码不足以协调这些事件时，定时（timing）和协同错误发