1.明确需求范围和重点

在开需求会的时候,明确本次需求作用的是哪个模块,可能会影响到哪些模块。之前有没有类似的需求,测试的重点是什么,需求模块之间的优先级是什么。将这些问题提前处理掉。

2.设计高效的测试用例

画流程图,梳理流程和数据流转

画状态转换图,因果图等分析流程

编写测试用例,去重(异常测试等价类,测试数据等价类,测试步骤等价类,测试结果等价类)

3.测试用例评审,技术评审

4.核心用例开发自测

5.不做无效的测试

如果需求的冒烟测试质量比较低,由多个较为严重的BUG,甚至可能阻塞测试流程,测试可以将需求打回,让开发重新自测。一方面是因为功能阻塞,下游的功能无法完成测试,另一方面,新的问题可能还是由于已存在的BUG引起的。

6.不做重复的测试

熟悉整个项目的架构,相互之间的关系。很多看似不同的测试点,实际上只是一个测试点,仅仅是外面的包装不同。

当一个测试点出现问题时,那么其他的测试点也可能有问题,其他的可暂时先不用测试了。提BUG的时候可以列出核心问题所在,并将其他涉及的点提出来。等验证的时候,再把涉及的测试点都过一遍,这样就减少了很多重复的工作,只是在验证的同时把测试点覆盖全。

7.不同测试版本的测试重点

对于测试来讲,基本上一个需求要验证三个版本,(test环境,beta环境,product环境)。如果每个需求都要详细的过一遍,遇到大需求的话,测试估计会累死。

如果针对三个环境,进行一个合理的分配和取舍,测试也会减少很多工作量。

结合日常的工作,提供一个思路:

test环境:验证BUG,全面测试,尽可能找出所有的BUG。

beta环境:验证上一轮的bug;

prod环境:验证全部bug,并全面检测。

这样其实只是第一轮和最后一轮需要全面测试,这样对于测试轮数多的情况下又能节约很多测试时间。另外一般beta环境的数据库和线上的数据库是一个,数据不可以随便增删改,风险较高,对数据的操作更多的集中在test环境。即使生成脏数据也没有关系。

8.优化测试顺序

先接口,后功能;先异常情况,后正常情况。

冒烟测试的时候,开发基本会把正向工作流程走一遍,没有问题才会提测,这个无疑给我们节省了时间,那么接下来,作为测试,我们拿到一个产品,可以先从接口开始测试。

执行接口测试时候,可以先进行单接口测试,校验单接口的输入输出参数是否符合要求。如果接口有传入新的参数,可以从:合法但不符合要求的参数,不合法也不符合要求的参数等,然后再简单过一下正合法的参数。对于输出参数,也是同理。当单个接口没有问题,可以考虑将接口进行串联,流程性测试。

当接口测试通过,说明后端的处理逻辑基本符合要求,接下来就进行功能的测试,不关注产品内部如何交互,进行黑盒测试。在进行测试的时候,也可以优先考虑异常流程,这里借助一个例子:

就拿注册功能来说,一般会分为3个步骤,注册,验证,登录,一般正常情况都是先测试正常注册,正常验证,正常登录,然后测试异常注册,异常验证,异常登录。但这样有一个缺点,会有重复无用的操作:

当完成正常测试后再测试异常之前,需要从登录状态退出,然后再点击注册入口进行注册。

当测试异常验证的时候,需要再次测试正常注册,不然就进入不了验证的步骤。

当测试异常登录的时候,又需要再次测试正常验证,不然就进入不了登录的步骤。就这3点也许大家觉得最多浪费几十秒的时间,但如果注册信息要填很多呢,如果验证邮件或者短信要延迟很久才收到呢,这样就是浪费了几分钟吧。如果其中有bug,那可能要测试多次来定位问题,那就可能浪费了10分钟,而这仅仅是一个并不复杂的测试,如果涉及到更复杂的关联,可能会浪费更多的时间在于无效和重复的测试中。

那么问题来了,怎么调整测试顺序呢?

先测试异常注册,输入各种错误的注册信息,如果没有bug的情况下是跳不到验证界面的

然后测试正常注册,可以正常跳到验证界面

接着测试异常验证,如果没有bug的情况下是跳不到登录界面的

再测试正常验证,可以正常跳到登录界面

再测试异常登录,如果没有bug的情况下是无法正常登录的

最后测试正常登录,可以登录完成这样其实覆盖的测试点一个没少,但却没有无效和重复的测试,调整顺序之后可以减少不必要的操作,积少成多的节约测试时间。

9.他山之石可以攻玉

对于实在无法避免的重复劳动,可以借助自动化测试技术去解决,这一点需要基础的编程能力,同时也需要适合的工具。

以上内容为大家介绍了软件测试工程师如何提高工作效率,本文由多测师亲自撰写,希望对大家有所帮助。https://www.duoceshi.com/xwzx-hydt/1811.html

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信小程序

微信扫一扫体验

立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部