经历6-21阿辉的分享，结合自身的测试工作状况，聊聊分享收获。
1、需求评审
理想版：
- 产品部提供较完整的需求说明书。
- 至少产品、开发、测试三方会议对需求进行评审，结合实际情况，完善需求。
现实版：
- 通知测试时，还没有需求文档，甚至有口述版需求存在。
- 有需求文档，变更时靠口述，无更新最终版。
- 有时，需求评审的步骤直接省略。
学习版：
- 拿到需求后仔细阅读，把有异议出处记录下来，待三方会议时，
带着问题去评审需求，事半功倍。
- 需求评审时，现场的问题也先记录，待产品部讲解完再统一提问。
避免中途打断大家的思路。
- 站在用户的角度考虑，该需求能解决用户的哪些问题。
2、需求转化功能点
- 给功能点划分优先级，比如主流程、部分功能、界面显示等等层次。
- 使用Xmind思维导图对需求功能进行细分，转化为具体的测试用例场景。
- 针对系统功能，可列出通用测试用例拿来共用，具体模块再加入个性化用例。
3、需求发布前的准备
- 数据的初始化脚本是否OK
- 配置的脚本是否OK
- 发布的流程要安排妥当
- 发布需求相关人员要到位
- 发布失败的应急预案
4、需求发布完的工作
- 线上回归测试环境发现过的bug
- 回归系统的主要业务流程
- 探索性测试
- 定期定时对线上功能进行回归
5、测试总结
- 现实中经常遇到同样的bug，可系统分析产生bug的原因，将原因归类形成文档，在开发和测试中共享，督促大家避免此类问题。
- 测试工作必须沟通，大家协作完成项目需求，就是沟通完整的过程。各自适应并习惯对方的工作沟通方式，也是一种无形的总结。
