一、需求评审

  1. 认真了解需求，尽可能在此阶段找出隐藏需求同步给dev，减少后续工作量；
  2. 尽可能指出prd中有误以及功能交互存在不合理的地方，以减少测试过程中折返跑；
  3. 站在用户角度分析需求，如果存在不合理地方，提出来和大家讨论；
  4. 大致构想下如何开展测试，是否存在人力、硬件设备不足的情况以及测试技术达不到的情况，提出来和大家讨论解决方案。

二、用例

1.往往是新功能和改动较大需求时编写，优化和平移一般情况下不写用例；

2.尽可能在需求评审后不久内完成用例编写，减少重复了解需求的工作量；

3.除了常规用例外，需要额外注意极端场景和隐藏需求的用例覆盖，防止漏测；

4.根据项目情况决定是否测试评审，如果非上线紧急的项目，尽可能评审用例，评审过程中标记他人提出的合理case，将这些case归类记录到本地，定期review。

三、测试

1.冒烟测试：多用于待测需求多的时候，先大致冒烟下，找出明显和影响后续测试的bug，提出来让dev先解决，预防最后只剩该需求未测试但无法测试的情况；

2.分支测试：详细的进行debug环境单机测试，如果因其他需求导致卡住也可以再此进行兼容性测试，测试过程中发现prd不合理的地方及时找pm确认并同步给dev，配置问题也找pm，待主要缺陷都已经解决验证过后发出合develop分支请求；

3.develop集成测试：先尝试打release包（报错让dev解决），检查版本号（不对的话让pm修改），尽早使用release包测试，最终是要保证release质量符合要求。该分支主要测试功能之间的交互，包括新功能与新功能，新功能与老功能，以及兼容性稳定性；

1>兼容性：主要是针对功能适配、授权以及UI变更的测试；

2>稳定性：使用monkey测试，也有现成的python稳定性脚本，实质也是monkey，每次使用不同的种子值进行测试（相同种子值执行内容一致），时间尽可能保证2h以上，如果时间允许可以利用下班时间跑6～8h，作用是确保长时间操作app不会出现崩溃和内存泄漏以及不容易发现的crash，该阶段保证质量已经完全合规后发出合master的请求。

4.master回归测试：按照trello上线前check项进行回归测试。

四、Bug

  1. 提出测试过程中发现的所有缺陷，尽可能发现问题第一时间截屏或抓取相关log，预防埋雷；
  2. 跟踪每个bug至关闭状态，尽可能了解bug产生原因以及dev的解决方案，这样可以确保有方向的验证bug和确保该bug不会影响其他地方；
  3. 要求dev要每个bug都修改状态和备注发生原因、解决方法、提交节点。
  4. 不是很确定的bug可以先和pm确定；
  5. dev不想改的bug及时和dev沟通，询问其原由（耗时太多还是技术达不到），将自己意见和dev反馈结果同步给pm，由pm定夺是否修复。

五、紧急上线

  1. 一般情况是合规性整改，也可以是修复线上bug；
  2. 了解需求（口头确认），了解dev修改内容和大致提测时间（口头确认）；
  3. 提前准备好测试点，根据了解情况确保产品质量，回归测试需要着重注意；