1. 测试计划
1. 预估测试周期
2. 预估整个测试过程中存在的潜在风险,以及应对策略
2. 测试范围
指的是:被测对象(功能/模块)以及主要的测试内容
明确两点:
- 测试什么
- 不测试什么
2.1 测试策略
首先明确两点:测什么?怎么测?
- 先测什么后测什么
- 如何来测试
其次采用什么样的测试类型和测试方法:
- UI测试
- 功能测试
- 兼容性测试
- 双端对比测试
- 网络测试
- 中断测试
- 覆盖安装测试
- 性能测试
- 接口测试
- 压力测试
- 安全测试
- ……
3. 测试资源
4. 测试进度
版本接受测试build acceptance test
P0测试/冒烟测试 smoke test
回归测试
注:BDD behavior-driven development 行为驱动开发
5. 测试风险评估
常见的影响版本正常封包原因有以下几点:
需求变更
明确需求变更的类型(建议整理需求变更的详细信息),如:
(1)增加需求
(2)修改需求
(3)删减需求
PS:不管是哪种类型的变更,都需要重新进行测试需求的分析,确定变更后的测试范围和资源,并及时和项目经理,产品经理等沟通测试进度的变化
开发延期
发现重大严重bug
人员变动
框架更改
要想做得漂亮,还需要以下几点的支撑:
a. 立根之本:业务
了解业务,认识业务,熟悉业务,掌握业务,挖掘业务等等
b. 沟通
沟通强,能够有条理的把问题表述清楚,可以定位问题,可能出现的原因,建议给出的解决方案,比如一,二,三等
能听清楚对方表达的问题,表达哪个意思,提炼要点,并再次确认
c. 推动
推动强,有问题时及时汇总记录,上报---定位---明确其影响范围---后续的规避措施
d. 协调
在开发,产品,运营等合作伙伴中周旋
e. 响应快
可以在第一时间回复对方的消息,并在一定的时间内给出进度或者结果
f. 技术支持
可以给开发,产品同学提供对应的技术支持,比如,抓个包哈,查找版本修改的记录详情等等