当前位置:首页 » 《资源分享》 » 正文

【软件测试】来看一下你是否是一名优秀的软件测试工程师?_m0_58026506的博客

24 人参与  2021年10月09日 08:23  分类 : 《资源分享》  评论

点击全文阅读


互联网高级测试工程师至少具备的能力

熟悉本系统

测试人员参与测试的系统的各种业务场景,必须做到精熟 。一旦需求有改动,可以清楚快速的知道上下文。同时可以清楚的知道哪些点是需要重点测试的。

熟悉跟本系统有通讯的上下游系统业务

跟本系统有通讯的上下游系统也要非常熟悉。这样一旦系统出现问题,可以知道影响的范围。

熟悉公司主流程业务

熟悉公司主流程业务。虽然不是自己测试的系统,但是熟悉公司主流程业务,可以让测试人员在考虑问题的时候,有更好更广的思路。

逻辑思维好,气场也要好

互联网应用一般是切分成多个子系统的,各个系统都有自己的业务范围,一个任务的完成,通常要有多个部门或者小组进行协作。这个时候,就不可避免的进行各种会议沟通,小组内的或者小组之间的。

那么测试人员如果脑子不好使,不能快速的理解别人的意图和想法,会很容易被人忽悠或者陷入各种坑,到时候就会有无穷无尽的测试任务了。

 另外,当对方太强势的时候,测试人员不能太弱势,应该根据自己对业务和系统理解,提出自己的意见,该做的就做,不应该做的别硬塞过来。积极配合对方,但不是傻傻的啥都做。

掌控系统上线排期

如果开发任务非常的多,测试人员要测试的功能也就非常的多。这个时候,如果功能的上线时间都是由开发经理或者PMO等来定,那测试人员就只能进行无穷无尽的加班。

这样是不行的。测试人员有自己专业,对业务精熟,必须清楚的知道哪些任务的优先级是高的,哪些是低的,将任务进行优先级排序。规定某个时间段里,就只能上多少个功能。

测试小组能够承受的最大任务队列是多少,测试人员必须有个底。测试任务超过这个队列,可以根据优先级把部分任务挤出去。

能编写覆盖关键路径的测试用例

对业务需求准确的理解后,测试人员能根据业务需求,设计关键的测试用例,能够完整的覆盖业务关键路径和场景,保证只要这些重点用例能通过,就说明需求的重点功能已经OK了。

重点功能OK了,就算立刻上线,如果出现问题,也只是小问题。当然能够用测试用例覆盖所有当然是最好的。

熟悉测试技术

在测试互联网应用的时候,测试至少得掌握下面的技术和概念:

  1. 懂得用jmeter进行性能测试;

  2. 懂得搭建性能测试需要的环境,例如服务器、redis、memcache等等;

  3. 懂得如何编写性能测试报告。例如至少包含接口响应时间、QPS、最佳并发数、CPU使用情况、内存情况、抖动、GC情况等等。

  4. 懂得上下文切换、内存溢出、内存泄露、QPS、稳定性测试等等的概念。

约束开发人员,保证开发质量

当开发提测代码的时候,测试人员应该具备下面的意识:

  1. 让开发人员先把master分支的代码merge或者rebase到自己分支上,保证提测的时候,代码已经包含了master的代码,这样可以提前发现问题。

  2. 代码功能测试完毕后,必须再做一次回归测试。这个时候必须强烈的约束开发人员,不许再提交代码了。除非是bug。不然的话,测试人员回归测试完后,开发人员跑来告诉测试说,代码有改动。这样的话,测试人员辛辛苦苦的回归测试就白测了,又得重新回归一次。

  3. 测试人员必须回收master分支的代码提交权限,一旦开发者要提交代码,只能通过和测试沟通,说明代码做了什么改动。绝对不能让开发人员悄悄的提交代码,这种行为非常造成线上故障的。

会写代码进行自动化测试

现在微服务非常的流行,各大互联网公司都在搞微服务接口。针对微服务接口,测试人员一定要懂得编写代码去进行接口自动化测试。大家想想看,假设某系统有50个微服务接口,测试人员测试完一次后,开发人员修改了其中10个接口的代码,这个时候应该可以通过跑自动化case来验证这10个接口的改动有没有影响到其他40个接口。这种回归测试的效率非常的高。如果每次都得人工手动的进行接口回归测试,那测试人员就得累死了。

如果对你有一点点帮助,各位的「点赞」就是小编创作的最大动力,我们下篇文章见!


点击全文阅读


本文链接:http://zhangshiyu.com/post/29611.html

测试  人员  代码  
<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1