从需求到上线,测试人员需要做哪些

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

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

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

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

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

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

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

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

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

上一篇:3D旋转相册


下一篇:算法复习:手推快排