测试思路收获

经历6-21阿辉的分享，结合自身的测试工作状况，聊聊分享收获。

1、需求评审

理想版：

• 产品部提供较完整的需求说明书。

• 至少产品、开发、测试三方会议对需求进行评审，结合实际情况，完善需求。

现实版：

• 通知测试时，还没有需求文档，甚至有口述版需求存在。

• 有需求文档，变更时靠口述，无更新最终版。

• 有时，需求评审的步骤直接省略。

学习版：

• 拿到需求后仔细阅读，把有异议出处记录下来，待三方会议时，
  带着问题去评审需求，事半功倍。

• 需求评审时，现场的问题也先记录，待产品部讲解完再统一提问。
  避免中途打断大家的思路。

• 站在用户的角度考虑，该需求能解决用户的哪些问题。

2、需求转化功能点

• 给功能点划分优先级，比如主流程、部分功能、界面显示等等层次。

• 使用Xmind思维导图对需求功能进行细分，转化为具体的测试用例场景。

• 针对系统功能，可列出通用测试用例拿来共用，具体模块再加入个性化用例。

3、需求发布前的准备

• 数据的初始化脚本是否OK

• 配置的脚本是否OK

• 发布的流程要安排妥当

• 发布需求相关人员要到位

• 发布失败的应急预案

4、需求发布完的工作

• 线上回归测试环境发现过的bug

• 回归系统的主要业务流程

• 探索性测试

• 定期定时对线上功能进行回归

5、测试总结

• 现实中经常遇到同样的bug，可系统分析产生bug的原因，将原因归类形成文档，在开发和测试中共享，督促大家避免此类问题。

• 测试工作必须沟通，大家协作完成项目需求，就是沟通完整的过程。各自适应并习惯对方的工作沟通方式，也是一种无形的总结。