目前我们公司的研发流程还算正规，今天主要讲开发提测之后，作为测试人员的我是如何处理后面的流程。
1）开发提测之后都会发送提测邮件，从我拿到提测邮件开始，首先分析提测邮件，从提测邮件中提取几个最重要的点：
第一是，提测系统和分支名，我们现在是使用jenkins自动部署，在部署时只需要输入分支名和选择要部署的测试环境就可以开始部署，分支名不仅是测试过程中最频繁使用到的，而且是上线时也需要，所以记下来，方便随时查看；
第二是，环境配置，看是否有任务要配置、有没有sql语句、有没有业务开关之类的配置；
第三是，查看测试范围，在提测邮件中开发人员会根据自己修改代码的情况列出一些测试范围和影响到的场景；
第四是，上线策略，在比较大型的项目都会有上线策略和上线顺序，优化的项目若只涉及到一个子系统就没有，也就无需关心，但不管提测邮件中有没有，测试人员还是需要自己思考加分析看没有这方面的情况。
以上四点我都会从提测邮件中提取出来，同时做好记录。
2）紧接着，我也不会立马开始测试，而是在文档中写出自己平时测试过程中容易遗漏的测试点。
比如有一阵子测试总是忘记测试兼容性，临到上线的时候或已上线了，开发问起有没有测试过兼容性，然后一懵，这次需要测试兼容性么？没测，然后开发就意味深长地看你一眼。
后面我学乖了，总结出了一份测试过程中容易遗漏测试点列表，每次测试之前都拿出来过一眼，该加上的加上，没有涉及到就划掉，这个列表也同用例一样常用常更新。
3）写下本次项目的始末和原因，对于我们公司来说，我们大多都是优化和改造之类的项目居多，我会记下这次项目因为什么原因要改造或优化，可能是线上bug引起的，那就写下bug出来的场景和步骤、附上线上数据、解决方案，根据不同的项目这时可以写一些特殊的测试场景，这样写出来好处不仅有利于本次测试思维的扩展，同时方便后期对版本修改的追本溯源，只要做过很多项目的人都会理解能回溯版本的好处。
4）测试过程中，不断优化这份文档，从业务方面，画出业务流；从数据库数据落地修改方面，记录下每一个操作步骤数据的变化情况（值的变化、状态的迁移等），丰富测试点和测试场景，在原有的测试用例基础上，同时附上不同测试阶段，对本次业务的理解和当时的想法。
5）项目上线之后，若是有线上bug，在文档中记录下bug出现的场景和解决方案，同时分析当时是因为什么原因没有测试出来，漏测？还是业务覆盖到但代码没有覆盖到？重复bug？
6）总结，测试后可以立马总结，也可以隔一段时间回过头再总结，总是会受益匪浅。
测试过程中除开常规测试流程，外加这套针对个人的流程，工作效率虽提升甚微（接下来需要解决的事），但测试过程更严谨了，出现漏测的情况减少了。
这个方法我从6月中旬开始使用，不断优化过程，目前看来成效不错，至少自己做的项目忘记了立马就能翻到，回忆起当时测试的情况和当时的想法，若过段时间再回头来看，对业务的理解更深一层。
最后给大家推荐一款我一直在用的记录软件：Typora，自从公司停了网络云之后，一直找不到合适的记录工具，后面看有同事在用这一款，使用起来感觉真的很好，给我最直观的感受就是简洁，没有乱七八糟的广告，相比某云和某象，目前我更喜欢这个工具，写起markdown文档来真是得心应手，不需要多浮夸的操作就能写出一份条理清晰、重点明确的技术文档出来。
源自公众号：资深Tester