软件研发中的测试
软件需求完成后，需要进行需求的评审，此时测试人员可以参与需求的评审。当需求确定后，测试人员可以开始进行系统测试方案及计划的制订。
软件项目总体设计方案完成后，测试人员可以开始进行集成测试方案及计划的制订。
详细设计完成后，测试方可以开始进行模块测试方案及计划的制订。
单元测试和编码一般是同步的，由开发人员自己完成。
整个模块开发完成后，测试人员开始进行模块测试。当然在这之前，所有的模块测试用例已经准备完毕。
模块测试后是集成测试和系统测试。
软件运行维护期间则要对运行期间发现的问题进行回归测试。
软件测试模型
V模型
项目研发中的开发活动是从需求分析到概要设计，之后到详细设计，再到编码，然后是测试活动。在这个模型中，把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。测试活动在编码之后，并且只对代码测试，未能体现尽早测试的原则。虽然该模型有局限性，但是该模型仍然是指导测试开展的一个重要模型。
测试活动对应开发的4个阶段，分别是单元测试、集成测试、系统测试和验收测试。
- 单元测试：对软件中的最小可测试单元进行检查和验证，是指在编码完成后，对所实现的方法/函数的内部逻辑进行的测试。
- 单元测试的依据是方法/函数的功能与功能实现流程；
- 单元测试的主要对象是方法/函数的功能在实现过程中的错误或不完善的地方；
- 单元测试所采用的测试方法是白盒测试，即针对方法/函数的内部实现逻辑，并结合方法/函数的输入及输出的可能取值范围，进行程序的针对性测试。
- 集成测试：也叫组装测试或联合测试，将所有模块按照设计要求（如软件架构图）组装成为子系统或系统，进行集成测试。之所以进行集成测试，是因为一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。一些局部反映不出来的问题，在全局上很可能暴露出来。在实际项目实践中，集成测试之前还会安排模块测试。模块测试是指针对产品设计所识别出的各个模块在本产品版本所承载的功能实现，测试模块级功能的实现，模块间的接口、交互，以及依赖关系的正确与否。
- 系统测试：将经过集成测试的软件，作为计算机系统的一个部分，与系统中的其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。系统测试是针对产品版本系统进行的整体测试，主要采用的测试方法是黑盒测试，系统测试除了关注功能测试外，还需要关注软件产品的非功能需求，包括但不限于容量测试、性能测试、压力测试、负载测试、兼容性测试、稳定性测试、可靠性测试、可用性测试和用户文档测试。
- 验收测试：也称为交付测试，目的是确保软件准备就绪，向未来的用户表明系统能够像预定的要求那样工作，即软件的功能和性能如同用户所合理期待的那样。
- 验收测试阶段，相关的用户和独立测试人员根据测试计划及结果对系统进行测试和接收。
- 它让系统用户决定是否接收系统。
- 它是一项确定产品是否能够满足合同或用户所规定的需求的测试。
- 非正式验收测试（Alpha测试）：是由用户在开发环境下进行的测试，也可以是公司内部的用户（比如技术支持人员、销售人员、代理商等）在模拟实际操作环境下进行的受控测试。Alpha测试不能由程序员或测试员完成。
- 正式验收测试（Beta测试）：是软件的用户在实际使用环境下进行的测试，开发者通常不在测试现场。Beta测试不能由程序员或测试员完成。比如，游戏的公开测试就属于Beta测试。一般Beta测试通过后就可以正式发布产品了。
W模型
- 从V模型演化而来，在这个模型中增加了与软件各开发阶段同步的测试活动。
- 测试伴随着整个软件开发的周期。
- 用户不仅需要对程序进行测试，还需要对需求和设计进行测试。
- 测试和开发是同步的，有利于尽早地发现问题。
- 但是W模型存在一个和V模型相同的问题，它们把软件研发的过程视为一系列串行的活动，没有融入迭代及变更的元素。
H模型
- 强调测试活动是独立的，贯穿于整个产品的周期，和研发流程是并发的。
- 只要测试就绪点达到了，就可以开始进行测试。
- 可以满足测试尽早开始这样一原则。
- 模型本身并没有太多的执行指导，可以把它理解为一种理念，测试就绪点满足了就可以测试了。
软件测试流程
- 测试需求分析
- 测试计划及监控
- 测试设计与开发
- 测试执行及报告
- 软件评估报告及批准
- 测试总结及资产归档
软件测试过程资产
- 测试方案文档（测试计划文档）。
- 测试用例列表。
- 测试缺陷列表。
- 测试总结报告。
- 其他。
- 新开发或引入的测试工具。
- 测试工作会议记录。
- 测试计划（测试方案）、测试用例的评审报告。
- 测试总结。
- 测试原始数据及度量数据。
- 测试日志：每天测试日程记录。
- 周期性测试报告。
- 任务报告：任务完成情况报告。
| 文档名 | 作用 | 主要内容 |
|---|---|---|
| 测试计划（测试方案） | 描述为完成软件特性的测试而采用的测试方法的细节 描述测试活动的安排和管理 | - 测试范围和策略:包括被测对象、应测试的特性不被测试的特性、测试模型、测试需求、测试设计 - 测试环境和工具 - 测试出入口准则及暂停标准 - 测试人员要求 - 测试管理约定 - 任务安排和进度计划 - 风险和应急 |
| 测试用例 | 描述测试用例的具体细节 | - 测试项目 - 用例编号 - 用例级别：测试用例的重要程度 - 用例可用性 - 输入值 - 预期输出 - 实测结果 - 特殊环境需求（可选） - 特殊测试步骤（可选） |
| 测试缺陷 | 描述测试缺陷 | - 缺陷简述 - 缺陷描述 - 缺陷级别 - 缺陷状态 |
| 测试报告 | 描述测试结果 | - 测试时间、地点、人员 - 测试环境 - 测试结果统计分析 - 测试评估 - 测试总计和改进 - 遗留缺陷列表 |
软件测试流程中的度量分析
- 测试度量作用：积累数据，评价工作，改进过程，预测趋势。
- 缺陷遗漏统计：
- 用例未覆盖
- 用例覆盖未执行
- 测试通过线上复发
- 缺陷分布统计：
- 严重程度
- 阶段
- 模块
- 开发人员
- 用例统计：
- 用例执行率
- 用例通过率
- 用例需求覆盖率
- 用例缺陷发现率
- 用例执行工作量
- 回归用例执行工作量
- 缺陷分布统计：缺陷模块分布、缺陷开发人员分布、缺陷严重程度分布
- 缺陷修复统计：缺陷每日修复率、缺陷阶段修复率
- 缺陷收敛统计：缺陷收敛速率
- 工作量统计：发现缺陷数量、测试用例执行数量
度量的意义
| 度量项 | 含义 | 目标和意义 |
|---|---|---|
| 测试生产率 | 单位时间所测试的代码量/单位时间执行测试用例的数量 | 一个团队的测试能力 |
| 工作量变化率 | 实际花费工作量相对于估计工作量的偏差百分比 | 提高估计能力、避免过载分配任务 |
| 测试进度变化率 | 项目实际测试进度相对于计划进度的偏差百分比 | 监控项目以便适时采取纠偏措施 |
| 工作量 | 测试所做的工作小时数 | 测试为整个项目贡献的工作量 |
| 缺陷密度 | 千行代码发现的缺陷数/千条用例发现的缺陷数 | 用于度量被测试系统的可靠性 |
| 测试问题的严重性 | 测试发现问题的严重性分布 | 用于确定目前被测试系统的可靠性 |
| 测试用例的问题发现效率 | 测试用例发现问题的数量 | 用于度量测试用例的有效性 |
| 测试用例覆盖率 | 需求覆盖率、功能点覆盖率、代码覆盖率等 | 度量测试的充分性 |
| 问题遗漏率 | 发布后反馈问题数/产品问题总数量 | 衡量内部测试质量 |