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. 技术支持
可以给开发，产品同学提供对应的技术支持，比如，抓个包哈，查找版本修改的记录详情等等