其实啊，每个人都可以「独立完成一个项目的测试 + 发布」

很多同学，工作了五六年，都没有机会（也许是：不敢）独立负责一个完整项目的测试（独立负责一个项目测试后的上线流程，机会就更少了）。

一件事，自己没经验的时候，最好的方法是模仿；看看同事怎么做的，把步骤全部记录下来 。

公司内部，关于代码发布 / 项目测试，一定都有其固定的流程，以及涉及到的固定技术的（新创公司，或者小作坊，可能流程不明显，或者没有文档沉淀，但操作者，也是有其固定的操作套路的）。

划重点：「做一件事，不一定要完全把这些技术弄懂，参考其他同事的玩法，会用就行 。」

多数从业者，每天日常工作的内容，不会有太多的创新性内容，或者太多技术性的创新事项 。基本上是固定套路的落地执行 。

优秀者，往往就体现在：基于现有流程，在现有套路基础上的「微创新」；创新后，加速完成事项的效率，或者改善事项完成的结果，使其质量更高 。

具体到测试职业：

拿到一个项目，

1、先根据产品的「需求文档 + 自己对当前行业的理解（经验）」，通过脑图的形式，拆分测试点 。
拆分测试点的过程中，把遇到的不清晰的需求（或者技术方面，不理解的知识点），通过问产品/开发/搜索引擎检索/查阅公司内部资料，搞定 。

2、根据自己梳理完成的最终测试点（此份测试点，最好是跟 产品 & 开发 & 测试 确认过的），开始设计测试用例（用例形式，不重要，可 excel / 用例工具 / 脑图 / 内部工具），然后进行二次评审（具体用例这块，老徐此公号「简尚」历史文章详细写过，有兴趣，翻来看看）。

3、测试执行过程中 ，问题提到 Bug 系统，对于一些异常状态的 Bug，关注其生命周期 。

4、测试报告（模板，之前有文章）。

5、关注风险 / 延期 ，以及 质量 & 进度 的平衡 。

6、开始发布 & 上线（把上线的步骤，自己用文档，完整的记录下来，并模拟几次，确保无遗漏）。

经验谈：
1）配置文件（各种链接串），容易出问题；
2）DB 脚本，容易漏；
3）一些第三方应用 & 服务，容易漏 ；
4）上线后，核心接口的自动化执行，确保主流业务无问题；
5）核心业务的手动回归；
6）上线后，核心业务的日志监控；
7）上线后，日志平台的 Error log 监控 ；
8）上线后，核心业务的数据监控（如果核心业务数据，明确下降，业务是此刻业务出问题了）

9、上线后，线上问题反馈流程 。

10、上线后的，值班 。

11、紧急问题的，BugFix

12、项目复盘（总结会）

13、End ，恭喜你，独立完成一个项目的测试 + 发布上线（如果还没实操过的，参考此篇文章，模拟了一遍全流程，试试；）

End ，此文结束 。

希望老徐的文章，对你有点用 。
限于篇幅 & 时间，还有很多不完善 & 写的不充分之处 ，欢迎补充 。

“学东西，实操完，才算入门 。很多技术，看起来简单，实操时，往往会遇到各种阻塞性小问题，导致放弃 。” - - IDO 老徐

IDO 老徐
2019/05/28

版权申明：
此文首发于公众号「简尚」，作者：IDO 老徐
无需授权，即可转载；转载请保留此文完整信息 。