大家周末快乐，我又来更新第三篇内容了~

之前我们有讲到过测试开发工程师日常工作的一部分是：支持业务迭代，保障需求顺利发布上线，需要在需求测试完成之后给出是否允许上线的结论（很多时候RD没有得到我们的结论都不敢上线的）。但有一点我希望大家明白的是，在互联网公司中无论是RD、QA、PM，我们最终目标其实都是为我们的业务负责，因为只有业务发展的好，我们才能获得相应的工资回报，只不过在这个过程中我们的职责分工是不一样的，所以我们都是需要关注业务的，不是说RD就只写代码，搞搞技术，RD也要关注技术之外的业务相关的内容的。

本篇内容主要是带着大家一起感受一下在公司里面我们是如何保障一个需求顺利发布上线的。

一些误解

在关于测试工程师的流言蜚语中，听到最多的是：测试工程师就是不断的在点点点。不可避免的很多人对测试工程师会抱有一些负面的印象。

关于这个说法，在一定程度上我认同，在大部分新需求的测试过程中，不可避免的我们要用手工测试的方法执行我们的测试用例，除非某些需求他的本质特性就不需手工介入：比如对外开放的API接口，这种是因为该产品形式就是这种无法通过手工进行测试的，或者手动测试的效率十分低下。

关于这一点，我要表达的内容是：手工测试是我们进行测试用例执行的一种方式，在客户端测试过程中这种执行方式能帮我们发现很多问题。而在进行测试用例执行之前，我们花了四分之一的时间用于测试用例设计，一个测试工程师的4分之一的价值也就在于她是否能熟练的掌握测试用例设计技术，我们更应该花费更多的时间关注测试设计的部分，本篇我们将会围绕测试设计介绍我们日常过程中的业务测试流程。

一次测试所包含的关键环节

对于一次业务测试来说，为了保障其顺利上线&良好的上线质量，我们的行动需要分布在测试前、测试中、测试后三个阶段来完成，在总的研发流程中测试是上线前的最后一个环节，优秀的QA应该掌握在前期化解质量风险的技能，确保测试过程能够顺利的进行，也能够顺利避免传说中的加班压力，并且能够对线上质量有一个好的保障。

测试开始前

在规范的研发流程中，测试开始前我们会经历以下几个环节：
（1）和RD、PM一起进行需求评审：需求评审会议的主持人为PM，目的是和项目的主要成员一起针对需求的正确性、完整性、一致性、不含糊进行review，保证三方对需求理解的一致，从而保证研发人员能够根据PRD制定正确的技术方案，测试人员能够根据PRD编写测试用例；对于优秀的测试人员来说，在这个过程中通常能够发现很多问题，并预判到该需求的上线风险点所在

（2）和RD一起进行技术方案评审，对于一些大型项目的研发，为了确保技术方案的有效性，避免后续需要重构的风险，RD通常需要编写技术方案，并邀请自己的leader以及测试同学进行技术方案评审。测试同学参与本次评审的目的通常有两个，一方面是评估技术方案是否合理，另一方面是对技术方案实现进行了解，从而能够更加充分地进行测试设计；

（3）在某些前后端交互特别复杂的需求中，通常后端RD还需要在完成api接口定义之后，和前端RD以及测试同学一起针对接口定义进行评审，确保后续开发和测试能够正常进行；前端同学的开发往往比较依赖后端同学定义的api，因此往往需要后端同学尽可能早的完成接口定义；测试同学了解接口定义，也便于后续接口自动化工作的开展以及开展