测试报告与验收

测试方法抉择

1. 输入分类选等价
2. 给定范围加边界
3. 条件孤立想判定
4. 无限穷举取正交
5. 业务复杂场景法
6. 测试充分全覆盖

实际设计的思路

• 任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强
• 必要时用等价类划分方法补充一些测试用例
• 如果程序的功能说明中，含有输入条件的组合情况，则一开始就可选用判定表法
• 如果程序业务复杂度比较高，则适当使用场景法补充一部分测试用例

每条测试用例有唯一的测试目的

提测阶段，优先做冒烟测试

冒烟测试时间不超过整体测试时间的 10%；选取正向流程；

• 核心流程冒烟测试，要求100%通过
• 主流程冒烟测试，不能超过30%的场景出现异常
• 探索式冒烟：半小时随机测试，发现 bug 不超过 10个

如果冒烟测试不通过，视为不进入测试阶段，测试大会，需要重新提测，重新冒烟

缺陷

• 实际工作中，在敏捷开发的模型下，以口头沟通，提高处理效率

与开发人员沟通的正确姿势

1. 熟悉基本的开发原理，做到专业，清晰，有条理地表达
2. 站在开发的角度去理解思考问题
3. 同时也要熟悉开发人员的沟通习惯

项目上线

需要注意的问题

1. 代码合并有遗漏
2. 线上环境和测试环境不同，忘记对哪些配置进行了修改
3. 数据库增加配置项时，有配置项遗漏增加，或者增加不正确

上线前把控--上线前通知上下游系统--特殊情况考量--上线后测试验收--线上问题跟踪--紧急发布测试--持续跟进--补测试用例

项目迭代

测试报告

• 将测试的过程与结果写成文档
• 对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据
• 为软件验收和交付打下基础
• 测试报告是测试阶段最后的文档产出物
• 优秀的测试人员应该具备良好的文档编写能力
• 一份详细的测试报告包含足够的信息，包括产品的质量和测试过程的评价
• 测试报告基于测试中的数据采集以及对最终的测试结果分析

内容

1. 报告信息
2. 引言
3. 测试概要
4. 测试结果与缺陷分析
5. 测试结论与建议
6. 测试限制

验收测试

验收测试是部署软件之前的最后一个测试操作

目的：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务

任务：

• 向未来用户表名系统能够像预定要求那样工作，也就是验证软件的有效性
• 验证软件的功能和性能如同用户所合理期待的模样

验收测试策略

• Alpha测试

  • 由用户在开发环境中进行的测试
  • 开发机构内部的用户在模拟实际操作环境下进行的测试
  • 是在开发者受控的环境下进行的测试
  • 在系统开发接近完成时，对应用系统的测试
  • 测试后仍然会有少量的设计变更
  • 一般由最终用户或其他人员完成

• Beta测试

  • 由软件的多个用户在一个或多个用户的实际使用环境下进行的测试
  • 由用户记录下遇到的所有问题，定期向开发者报告
  • 模拟真实的环境从而发现缺陷的一种测试