在实际工作中，其实很少有公司把一个完整的测试流程一步一步走下来，大多会执行测试流程的主体测试过程。那么，一个完整的测试流程包括哪些呢？测试人员又需要做些什么呢？下面，我为大家介绍从需求到上线，测试人员的完整工作流程：

1、需求交接
当一个需求确认后，产品经理一般会把需求说明书发给开发和测试人员，然后三方讨论需求，进行需求交接。这个非常重要，因为需求不明确，后续工作开展起来会有很大麻烦。

2、编写测试用例
需求确定后，测试人员就要开始编写测试用例了。
首先是梳理全部测试点。当然，这步并不是必须的。梳理全部测试点相当于是梳理一个框架，一方面，根据这个框架写测试用例，可以防止编写测试用例时丢失测试点；另一方面，项目经理会根据你的全部测试点去排期，安排人员和时间。
然后是编写测试用例。编写测试用例要尽可能的用最少的用例覆盖最多的测试点。编写测试用例的工具也有多种，要以公司使用的为准。编写测试用例最好是跟你的前辈去要一个模板，因为大家已经熟悉他们的测试用例风格，如果你是新人，尽管你的测试用例很棒，但是由于大家不熟悉你的写作方式，很可能会大打折扣。

3、冒烟测试
开发进行开发联调后，测试人员就开始正式介入了。进行联调后，测试人员首先要进行冒烟测试。好多不规范的公司会跳过冒烟测试，直接进行下一环节。如果冒烟测试不通过的话，会打回，也就是重新进入开发联调阶段。如果顺利通过，开发就会开始部署，进行下一步了。
新人可能会问：冒烟测试怎么测？这个时候，你就要明白，冒烟测试的目的就是为了保证主流程顺利通过。也就是说，你只要测试主流程就可以，或者说执行测试用例中优先级为1的测试用例。

4、SIT测试
SIT测试主要包括两轮测试：第一轮执行用例，回归bug；第二轮是系统回归测试。
也就是说，这个阶段的测试，就是你一条一条执行测试用例，遇到bug提交给开发，开发修改后要去回归bug。注意，也许当前bug的修复会引起别的bug，这个时候不要着急去关闭bug，要大致的点一点其他功能，确保没有问题后才去关闭。
这个阶段，需要同步进行的是，修改调整测试用例。测试用例是在开发还没开发完成的时候写的，会有些微的出入，在执行测试用例的时候，要进行修改，同时也会有遗漏的地方，要及时的加入测试用例中。
当所有的测试用例执行完成，所有bug都关闭掉后，要系统的再进行一边测试。SIT测试结束的标志就是覆盖率和通过率达到100%。

5、数据升级测试（视情况而定）
数据升级测试一般是在SIT测试后，也可在SIT测试的后期进行。数据升级测试不是都需要这一步的，如果需求分析中确认需要进行数据升级，就安排。

6、系统培训（视情况而定）
系统培训主要是针对客户的，为了让客户更快的熟悉系统，会由测试人员和产品共同商定，向培训对象分发操作手册，进行系统培训。

7、UAT测试
UAT测试就不仅仅是有测试人员，同时要包括业务人员一起测试。最终由客户验收，验收成功，开发会进行封版。封板之后，代码不会再进行更改。

8、上线
上线之后，测试人员还要进行上线验证。注意：这是生产环境，这个时候是不能随便操作做数据的，测试人员能做的也就是点点，保证按钮、界面正常。如果是业务人员做好数据，测试人员要验证数据的准确性和界面显示无误。
上线验证后，这个需求就算结束了。