第5章-函数(冲突时文件备份2015-04-28-08-05-46).pptVIP

函数设计的原则 函数的功能要单一，不要设计多用途的函数 函数的规模要小，尽量控制在50行代码以内 1986年IBM在OS/360的研究结果：大多数有错误的函数都大于500行 1991年对148,000行代码的研究表明：小于143行的函数比更长的函数更容易维护 参数和返回值的规则 参数要书写完整，不要省略 对函数的入口参数进行有效性检查 没有参数和返回值时，用void填充 每个函数只有一个入口和一个出口，尽量不使用全局变量 尽量少用静态局部变量，以避免使函数具有“记忆”功能 模块和链接 将一个程序分解成若干个模块，分别放在几个源文件中，形成一个项目文件（.prj ）（Project） 然后，对每一个源文件（.c）分别单独进行编译 再将它们的目标代码（.obj ）连同标准函数库中的函数链接在一起，形成可执行文件（.exe）。 模块之间通过互相调用函数联系起来 头文件（.h）是联系的纽带 模块和链接 例5.10可以不看 将习题5.5修改成 1个.h头文件（X5-5-1.h） 2个.c源文件（X5-5-1.c，X5-5.c） 1个.prj项目文件（X5-5.prj） 由所有源程序文件组成 X5-5-1.C X5-5.C 参见实验指导书第133页 模块和链接 优点： 当一个文件的代码被修改后，不必对所有程序重新编译，从而节省了程序的编译时间。 使程序更宜于维护，给多个程序员共同编制一个大型项目的代码提供了方便手段。 这一章我们学习了 函数的定义、调用 变量的作用域、存储类 自动变量（auto） 外部变量（extern） 静态变量（static） 寄存器变量（register） 程序调试方法 作业 P180，习题5.5~5.6 软件测试 测试 通过运行测试用例找出软件中的Bug 测试的目的 发现更多的Bug 测试人员的主要任务 站在使用者的角度，通过不断使用和攻击，尽量多的找出Bug 如何提高可测试性(tesability) 一条语句写一行才容易测试 软件测试 测试只能证明程序有错，不能证明程序无错 ——E.W.Dijkstra 测试的重要性 测试人员水平越高，找到Bug的时间就越早，软件就越容易修复，产品发行就越稳定 越大型的软件开发，测试人员占整个软件产品团队的总人数的比重就越大，甚至一半以上 成功的测试在于发现迄今为止尚未发现的Bug 软件测试方法的分类 从代码和用户使用的角度分类 覆盖性测试 从代码特性的角度（即内部）出发的测试 单元测试，功能测试，提交测试，基本验证测试，回归测试 使用测试 从用户的角度（即外部）出发的测试 配置测试，兼容性测试，性能测试，Alpha和Beta测试，强力测试，文档和帮助文件测试 软件测试方法的分类 第2种分类方法 白盒测试（结构测试） 在完全了解程序的结构和处理过程的情况下，按照程序内部的逻辑测试程序，检验程序中的每条通路是否都能按预定要求正确工作 黑盒测试（功能测试） 不考虑程序内部的结构和处理过程 软件测试方法的分类 第3种分类方法 手工测试 依靠人力来查找Bug 自动测试 编写一些测试工具，让他们自动运行来查找Bug 优点：快，广泛 缺点：只能检查一些最重要的问题，如内存泄漏、死机等，无法发现一般性的日常错误，而且编写测试工具的工作量很大 程序中常见的出错原因 编译错误 指在编译过程中发现的错误，通常属于语法错误，即编写的语句不符合C语言的语法规则。 Undefined symbol ‘xxx’ 标识符xxx未定义 Expression syntax error 表达式语法错误 Too few parameter in call 函数调用时的实参少于函数的形参 程序中常见的出错原因 运行错误 指在程序运行时发生的错误 往往是由于语义上的错误造成的，即语句虽然合乎语法，但要求计算机去做不该做或做不到的事情。 例如当用0做除数时，运行后将显示“Division by zero”错误提示信息，并立即返回编辑屏幕。查看运行结果时，可在User screen（用户屏幕）上看到给出的错误提示信息。 程序中常见的出错原因 逻辑错误 程序中有逻辑错时，不影响程序运行并得到运行结果，只是运行结果不正确。比较隐蔽，出错后不易查找。 累加求和运算时，累加和变量忘记了赋初值； 累乘运算时，累乘变量初值赋值为0； 函数声明时的返回值数据类型与实际返回的数据类型不一致，导致自动类型转换 数组下标越界（即超出了定义的范围）； 程序中存在死循环； 调试的基本方法 “粗分细找” 定位大致的范围：归纳、推理、二分、排除 缩减输入数据 设法找到能导致失败的最小输入 采用注释的办法切掉一些代码 减少有关的代码区域，调试无误后再将它