1671软件工程与软件测试模型1672软件缺陷和缺陷排除的两种重(编辑修改稿)

1671软件工程与软件测试模型1672软件缺陷和缺陷排除的两种重(编辑修改稿)内容摘要：

 缺陷重现率  BUG能按照一定的测试过程稳定重现  效率  平均每人天发现的 BUG数（ 5个 /人天）  成本  少。 合理的测试人力和软、硬件资源安排  重用价值  测试的数据或者样例可以重用 静态测试和动态测试 静态测试 是指不实际运行被测程序，而只是静态地检查程序代码、界面或文档中可能存在的错误。 对于代码测试：主要测试代码是否符合相应的标准和规范。 对于界面测试：主要测试软件的实际界面与需求中的说明是否符合。 对于文档测试：主要测试用户手册和需求说明是否符合用户的实际需要。 程序代码的静态测试需要我们按照相应语言的代码规范模板来逐行检查程序代码 C语言程序的例子 include Max(float x,float y) { float z。 Z=xy?x:y。 return (z)。 } Main() { float a,b。 int c。 scanf(“%f,%f”,amp。 a,amp。 b)。 c=max(a,b)。 printf(“max is %d\n”,c)。 } 必须修改的问题有三个 程序没有注释 一般注释语句要占到代码总行数的 1/5——1/4； 注释语句包括程序的基本信息如作者、版本号、创建日期等，以及主要功能模块。 子函数 max没有返回值得类型 由于 Z的值为单精度型，可以在 max前面加一个 float类型声明 精度丢失问题 注意语句 c=max（ a， b）， c的精度为整型，而 max为 float。 建议修改的问题也是 3个 Main函数没有返回值类型和参数列表 建议改为： void main（ void）， 表明 main函数的返回值和参数都为空。 1行代码只定义 1个变量 程序适当加一些空行 C语言编码规范（简易版） 规范编号 规范内容 是否通过 1 一行代码制作一件事情，如只定义一个变量，或只写一条语句，容易阅读和注释。 2 代码行的最大长度宜控制在 7080个字，否则不便于阅读和打印。 3 函数与函数之间，定义语句和执行语句之间最好加空行，空行不会浪费内存。 4 在程序的开头加注释，说明程序的基本信息；在重要的函数模块处加注释，说明各函数的功能。 5 低一层次的语句比高一层次的语句缩进一个 tab键（ 4个字符），使程序结构更清晰。 6 不要漏掉函数的参数和返回值，如没有，则用 void表示。 动态测试（ dynamic testing） 顾名思义，是指实际运行被测程序，输入相应的测试数据，检查实际的输出结果和预期结果是否符合。 白盒测试黑盒测试、静态测试和动态测试只是一个测试的不同分类的角度而已。 黑盒测试可以是动态测试，也可以是静态测试； 白盒测试可以是动态测试，也可以是静态测试； 动态测试可以是黑盒测试，也可以是白盒测试； 静态测试可以是黑盒测试，也可以是白盒测试。 167。 4 软件测试的一般性理论 二、单元测试 什么是单元测试。 是指对软件中的最小可测试单元进行检查和验证 单元：人为规定的最小的被测试单元。 如：在结构化语言中（ C语言），单元指一个函数；在面向对象语言中（ Java语言）单元指一个类；在图形化的软件中，单元也可以指一个窗口、一个菜单等。 167。 4 软件测试的一般性理论 二、单元测试 单元测试的内容：  模块接口测试  检查局部数据结构能否保持完整性  模块边界条件测试  模块执行路径测试  检查模块内部错误处理是否有效 单元测试方法：  白盒测试为主 167。 4 软件测试的一般性理论 二、单元测试 单元测试或模块测试 对模块进行正确性检验的测试工作，测试用例以白盒测试为主、黑盒测试为辅 . 模块 出错处理 模块接口 局部数据结构 边界条件 执行路径 调用参数 全局量定义一致性 数据定义、 使用 循环边界 输入边界 重要路径 关键路径 非合理输入 系统异常 167。 4 软件测试的一般性理论 二、单元测试 单元测试检查单  逻辑和算法：正确实现了逻辑和算法  数据结构（全局和局部）：使用了全局数据结构。 哪些。 如果有，作了哪些关于全局数据的假设。 这些假设正确吗。 使用了局部数据。 在算法执行的所有步骤期间，保持局部数据的完整性了吗。  接口：来自调用模块的数据匹配被调用的模块的期望接收的数据。 被调用模块的数据匹配调用的模块提供的数据。  独立路径：标识了所有穿过模块的独立路径。 执行了吗。  边界条件：了解边界条件吗。 进行了测试确保该模块在其边界条件上的适当的操作了吗。  出错处理：所有出错处理路径均执行到了吗。 167。 4 软件测试的一般性理论 二、单元测试 什么时候进行单元测试。 代码经过编译后，在前期要做准备工作，如： 167。 4 软件测试的一般性理论 三、集成测试 集成测试（ Integration test） : 将通过单元测试的多个模块组合成更大的模块或子系统或产品，然后进行测试。 测试内容：各单元的接口是否吻合、代码是否符合规定的标准、界面标准是否统一等。 人员安排：既要求参与的人熟悉单元的内部细节，又要求他们能够从足够高的层次上观察整个系统。 一般由有经验的测试人员和主要的软件开发者来完成集成测试的计划。 167。 4 软件测试的一般性理论 三、集成测试 集成测试计划：集成测试计划由系统设计人员在设计阶段制定，它是和设计规格说明同时完成的。 内容有：  测试的描述和范围  测试环境  测试时间表  集成次序  测试用例以及测试的预期结果等 测试方法：集成测试阶段是以黑盒法为主。 167。 4 软件测试的一般性理论 四 、 系统测试  经过集成测试之后，分散开发的模块被联接起来，构成完整的程序，其中各模块间接口存在的种种问题都已基本消除。 测试开始进入到系统测试的阶段。  为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试 一般使用黑盒测试技术 一般由独立的测试人员完成 167。 4 软件测试的一般性理论 四、系统测试 系统测试 (System test):  应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。 这里所谓的系统不仅仅包括软件本身，而且还包括计算机硬件及其相关的外围设备，数据及其收集传输机构，甚至掌握计算机运行的人员及其操作等。 通常意义上的系统测试包括：功能测试、压力测试(Stress test)、 性能测试 (Performance test)、 容量测试(Capacity test)、 用户界面测试、兼容性测试等。 167。 4。