软件测试-ch2软件测试的质量要求.pptVIP

（2）大公司 * （3）测试外包公司 项目经理 测试组长 测试工程师 * 2.4 软件测试工程师所需的素质 三心二意一能力 三心 二意 一能力 细心 耐心 信心 服务意识 团队意识 沟通能力 * 技术能力 黑盒工程师 搭建黑盒测试环境 掌握黑盒测试技术 白盒工程师 阅读代码 * 测试工程师 项目经理 测试经理 开发人员 客户 * （1）不断学习充电。---与时俱进。 （2）阅读原版书籍。 （3）阅读缺陷报告。--前车之鉴，后事之师。 （4）阅读高手写的测试用例。--站在巨人的肩膀上会看的更远。 （5）学习产品相关的业务知识。 * 优秀测试工程师 项目组 总经理 项目经理 系统架构师 程序员 测试工程师 SQA * SQA SQA是独立于项目组之外的第三方监督机构，理论上，他的权力与项目经理平行，监督整个项目的管理，需求分析，设计，编码，测试与维护等软件工程的各个环节。 * SQA要做的工作 （1）通过监控软件开发过程来保证产品质量。 （2）保证开发出来的软件和软件开发过程符合相应标准与规程。（ISO9000， CMM） （3）保证软件产品，软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者。 （4）确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要。 * 2.5 软件测试的基本原则 Zero Bug 没有任何Bug Good Enough 软件达到一定质量要求，就可以停止测试了。 * Good Enough 权衡投入/产出比原则。 不充分的测试—不负责任 过分的测试—资源的浪费 一.Zero Bug 与 Good Enough （1）遗留Bug在10个以下，严重的Bug在5个以下。 （2）测试用例的执行率为100%，通过率为95%。 （3）单元测试中，关键模块的语句覆盖率要达到100%，分支覆盖率要达到85%。 * Good Enough通过准则 1. 测试时考虑所有可能的输入值。--太耗费时间。 2. 在测试用例上下功夫，用最少的测试用例达到最大的覆盖率。 * 二. 不要试图穷举测试 三. 开发人员不能既是运动员又是裁判员 测试应该由独立的第三方机构来完成。 1. 实践证明：需求分析阶段引入的缺陷是最多的，修复成本确是最低的。 2. 测试需求说明是否真正符合用户的需要，测试设计是否严格按照需求说明的要求。可以减少后期测试和维护的工作量。 * 四. 软件测试要尽早执行 原始需求 正确的规格说明书 错误的规格说明书 正确的设计 错误的设计 对错误的说明的设计 正确的编码 错误的编码 对错误设计编码 对错误说明编码 正确功能 可修复错误 不可修复错误 潜伏的错误 不完善的软件产品 * 五. 软件测试要追溯需求 一般情况下，软件80%的缺陷集中在20%的模块中，测试的时候抓住主要矛盾重点测试。 ——缺陷的集群现象或是虫子窝现象。 * 六. 缺陷的二八定理 程序员在修改完缺陷，把新版本提交给测试人员进行回归测试，测试用例依然用相同的，效果会大大折扣。——测试人员根据新版本的特点，修改维护测试用例。 每修复3 - 4个缺陷，一般就会产生一个新的缺陷，所以要充分注意修改错误所产生的影响和波及效果。 * 七. 缺陷具有免疫性 2.6 软件测试流程细则要求 软件测试流程细则要求分需求阶段、设计编码阶段、测试阶段、用户测试阶段。 1.需求阶段 ★ 测试人员了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等； ★ 测试人员了解项目需求变更； 1.需求阶段 ★测试人员会同项目主管根据软件需求制定和确定测试进度时，必须由开发人员和相关的测试部门人员共同进行。在制定测试进度时，必须考虑到合理地配置测试资源（测试设备、测试所要用技术文档资料、测试人员和对人员进行必须地培训） ★为了使所制定的测试进度正常有效，必须对其所制定的测试进度加以量化。要制定测试的各个阶段的测试进度。有特殊情况时还必须制定特定系统的测试进度。如文件管理系统、资料库内容功能测试等。 ★ 所制定的测试进度中必须含有修改问题和复查的时间。 2.设计编码阶段 ★ 测试人员制定测试大纲、测试设计、测试用例； ★ 对每一个测试需求，确定其需要的测试用例； ★ 对每一个测试用例，确定其输入及预期结果； ★ 确定测试用例的测试环境配置、需要的驱动界面或稳定性； ★ 为测试用例准备输入数据； ★ 编写测试用例文档； 2.设计编码阶段 ★ 对测试用例进行同行评审； ★ 项目开发组对完成的功能模块进行单元测试，测试人员参与单元测试过程；单元测试完成，产生单元测试报告； ★ 所有单元测试及相应的修改完成后，项目开发组组织进行确认测试和系统集成测试，测试人员参与集成测试过程