第一步，需求评审
当项目经理与各领导确定立项之后，产品经理输出了需求，这个时候相关的项目经理，研发人员与测试人员与产品经理都必须参与。通过需求评审，我们可以清晰的了解到产品到底想要做的是一个什么东西，对于开发来说，通过这些可以确定技术方案，而我们测试也可以通过这些来确定测试方案。并且通过技术方案和测试方案，我们就可以有效的开展风险评估和工作计划排期。
我之前所在的公司在需求评审之前，会给我们最少半天的时间去熟悉需求文档，为什么要给这半天的时间呢，因为我们要提前去了解会议内容与需求，有充足的时间去思考其他的问题，也不会在评审的时候一脸懵。
有些公司是不给这个时间的，就会产生一个问题，在评审的时候讲什么都听得懂，都觉得没有问题，因为我们当时的思路完全被产品经理带着跑，是没有多余的时间思考更多的问题，虽然会考虑到一些问题，但是遗漏会有些多，真的实际开工实施的时候会发现各种问题。
第二步，编写测试用例
一般来说需求评审完了之后就是编写测试用例，具体如何编写，如何规范用例，后面我会出文章来讲，这里咱们就讲讲写用例的作用。
用例的作用首先是可以有效的进行工作交接，因为实际工作中，不可能你一直负责你编写的用例的部分，总是会接手别人的工作或者会有别人接手你的工作的，所以就要有用例能够进行工作的交接。
其次就是在实际测试的时候，我们每天的工作强度其实也很高，是不可能完全记得自己的进度以及所有的测试场景的，这个时候如果有用例，就会方便很多了。而且用例是可复用的，版本更新，后期维护都是用的上的。
第三步，用例评审
用例评审最主要的作用就是让参与项目的开发和产品去了解到我们测试的想法，并且在评审的过程中纠正我们的错误，包括且不局限于对需求的错误理解以及错漏的用例。
毕竟一个人的思想是有局限性的，我们无法判断自己对需求的理解是否符合产品的设计。
并且通过用例的评审，能够让开发的同事更加了解需求，因为产品只是出了需求，但是我们的用例会涉及到各种场景。
第四步，执行测试
执行测试没啥说的，按照用例把冒烟，功能，数据，兼容，健壮性，稳定性，弱网，这些做一遍，跟踪定位一下bug，就OK了。
第五步，编写测试报告
在达到上线标准后，我们就可以编写测试报告了。怎么写报告就不说了，百度一大堆模板。
测试报告的作用首先就是对本版本测试工作的总结，可以更直观的让同事以及领导了解到本版本的测试工作的情况，也可以通过报告分析出本次版本的风险与问题，下次可以避雷。
第六步，上线以及线上测试
确定上线之后，线上测试是很有必要的，毕竟线上环境和测试环境是不一样的，万一有什么问题，还可以进行补救，比如补发版本，热更新，或者更严重就版本回滚。
第七步，文档归档
上线之后且线上版本也趋向于稳定的时候，就可以进行归档了，需要归档的文档包含本次版本中测试人员所有产出的文档，包括测试计划，方案，用例，报告，放在版本控制工具中，以便于日后更新以及维护。
看了这篇内容后，坚信以下两件事，也会对你的自我提升有一定的帮助：
1、点赞，让更多人能看到，同时你的认可也会鼓励我创作更多优质内容。
2、要让自己变得更强：想想，假如你是要在测试这个行业长期做下去，你的工作经验和测试技术是绝对不够的，你需要提升，你需要丰富你的技术栈！还等什么！
最后:【可能给你带来帮助的教程】
