软件测试技术经典教程笔记修.docx

第一章 基础知识 1.1、软件 1)、软件=程序+文档 2)、分类 功能：系统+应用 架构：单机+C/S+B/S 用户：产品+项目 规模：小型+中型+大型 1.2、Bug 1)、类型一(广义上，软件生命周期，与用户需求不符的问题)： 完全没有实现的功能 基本实现功能，但有功能上或性能上的问题 实现了用户不需要的功能 2)、类型二(测试执行阶段的问题) Defect---------RequirementsDesign Error-----------Development Bug------------Testing Failure---------Post production 1.3、测试 1)、概念： 测试是为了检验实际的软件是否符合用户需求，所以不能为了发现错误而发现错误。使用人工或自动手段，来运行或测试某个系统的过程。 2)、测试环境：硬件+软件+网络 要求：真实(项目、产品)+干净+无毒+独立(测试与开发) 1.4、测试用例 测试用例=输入+输出+测试环境 便于团队交流，便于重复测试，便于跟踪统计，比纳与用户自测 开发生命周期 需求分析 → 概要设计 → 详细设计 → 编码 → 维护 测试生命周期 测试计划 → 测试设计 → 测试执行 → 测试评估 需求分析和测试计划完成后，根据《系统需求规格说明书》和软件原型(DEMO)写测试用例 1.5 其他 1)、测试人员素质要求：细心、耐心、信心、服务意识、团队合作意识、沟通能力 2)、如何成为优秀的测试工程师：1、不断学习充电 2、阅读原版书籍 3、阅读缺陷管理系统中的缺陷报告 4、阅读高手写的测试用例 5、学习产品相关的业务知识 1.6 软件测试的基本规则 1) Zero Bug 与 Good Enough Good Enough原则：不充分测试是不负责任，过分的测试是一种资源浪费。 参考：*遗留bug不超过10个，严重的不超过5个 *测试用例执行率为100%，通过率为95% *单元测试，关键模块语句覆盖率达到100%，分支覆盖率达到85% 2) 不要视图穷举法 3) 开发人员不能既是运动员又是裁判员 4) 软件测试要尽早执行 5) 软件测试应该追溯需求 原始需求 需求分析 正确的规格说明 错误的规格说明 设计 正确的设计 错误的设计 对错误说明的设计 编码 正确编码 错误的编码 对错误设计编码 对错误说明设计的编码 测试 正确功能 可改正的错误 不可改正的错误 潜伏的错误 不完善的软件产品 6) 缺陷的二八定理 一般情况下，软件80%的缺陷集中在20%的模块中。 7) 缺陷具有免疫性 缺陷具有免疫性，需要根据新版本修改维护测试用例，另外，有一个值得注意的经验：没修复3-4个bug，可能会产生一个新bug。 第二章 测试分类 2.1、是否运行程序 Static Testing------------代码规范、界面、文档 Dynamic Testing--------运行程序 2.2、根据阶段分类 Unit Testing(单元测试)----------10% 最小模块，依据源程序和《详细设计》 白盒测试人员||开发人员 编译代码→静态测试→动态测试 桩模块(Stub)、驱动模块(Driver) Integration Testing(集成测试)----------20% 模块间的接口，依据单元测试的模块和《概要设计》 白盒测试人员||开发人员 一般单元和集成同步进行 System Testing(系统测试)----------40% 整个系统(功能、性能、软硬件环境)，依据《需求规格说明书》 黑盒测试工程师 Acceptance Testing(验收测试)----------20% 整个系统(功能、性能、软硬件环境)，依据《需求规格说明书》和验收标准 用户，可配合黑盒测试工程师 α测试：内侧 β测试：公测 2.3、是否查看代码 1)、White-Box Testing-----源代码的测试 2)、Black-Box Testing-----功能测试、性能测试 Function Testing(功能测试) Logic Function Testing(逻辑功能测试) UI Testing(界面测试)：窗口、下拉式菜单和鼠标操作 Usability Tseting(易用性测试) Installation Testing(安装测试) Compatibility Testing(兼容性测试) 其他：恢复测试、裸机测试、确认测试、接口测试、数据库测试、安全测试、配置测试 Performance Testing(性能测试) 时间性能：主要指一个事务的具体响应时间(Respind