最近团队内部产品在做性能测试中碰到一个问题,不仅仅这次性能测试,其实这在我这近10年工作过程中,经常碰到一些类似的事情,今天拿出来一件事说叨说叨。
1、事情经过
月中上线了一个功能,该功能会应对峰值流量,测试人员由于种种琐事,导致性能测试没有完成。想着功能没有问题,性能测试相对简单,运行下性能测试脚本就行,于是把性能测试推到了周末加班测试。可是在测试过程中发现得到性能指标数据只是开发人员承诺的一半都不到,于是开始找开发人员,大周末的没人回复。
周一上班,实事求是的发了性能测试邮件,说明了实际的性能指标,总结下,QPS、错误率和时延均不满足条件,故性能测试不通过。
经过排查发现,其中有一个配置错误,流量发到了线上,但是线上配置了单实例限流,直接返回了错误码,因为该服务本身就是对互联网开发的功能,公司的网络确实可以连,但是经过了几层代理,时延高,指标自然无法满足要求。
最后开会进行了总结,基本上说的都是一些「放之四海而皆准」的大道理,加强跨团队之间的配合;尽量要把测试时间提前,如果不能提前,那么要找到相应开发人员一起配合完成工作。恕我直言,这个总结基本就是推诿扯皮、废话连篇,一句有用的都没有。
2、问题复盘
说到软件测试,有些人并不了解,软件测试工程师,说的简单一些,就是明白产品的需求,通过各种方式检查软件的质量问题,即常说的「找bug」~
上文说的性能测试,表面上来看,测试人员确实找到了bug,这个bug就是性能差,某种程度上,性能上不去,也算是一种软件缺陷。为什么低?到底需要开发人员排查,还是测试人员找到根因呢?
第一、性能测试不同于功能测试,功能测试只需要保证串行请求响应正常即可,性能测试则需要在并发请求下保证输入和输出符合预期。如果系统存在一些线程或者锁使用不当的情况,那么系统就会出现一些反常的表现,即便应用程序稳定,还是会陷入一些环境问题,性能测试工具选择错误、防火墙导致的网络不通、跨集群的延时过高等问题。碰到这种问题应该梳理整个核心链路,逐个分析问题所在,而不应该直接归结到应用程序本身存在性能问题。
第二、在做性能测试过程中,要做根因分析,不能「错把现象当原因」,比如我们的软件速度很慢,排除外界因素,可能是数据库慢,但也可能是软件自身慢;如果是软件逻辑处理慢,为什么慢,慢在了什么环节,这就需要我们通过strace、火焰图等方法去排查和分析慢的根因。如果直接给出相对笼统和模糊的答案,把问题甩给相应开发人员去分析和解决,那么开发人员又要从头开始,整个性能测试的效率大打折扣。
第三、在测试过程中要从性能测试端,网络链路、软件逻辑层,数据层等方面去验证结果的正确性,遵循性能测试方法论,正确的性能测试结果都是符合现实逻辑的,可复现的,能够被所有人理解和分析。而不仅仅是通过或者不通过的测试结果和几条冰冷的测试数据。
上面说的是性能测试,其实对于常见的功能测试、UI测试、接口测试等也是一样的。你确实找到了bug,但是根因是什么,你清楚么?因为不是自己开发的东西清楚里面逻辑,所以对于测试人员来说很难,但是这只有熟悉了底层的原理,后面的测试工作才会轻车熟路。
3、测试人员现状
目前应用软件开发主要存在如下两种架构。在实际执行中,很多公司把这两种架构进行了混合调整,常见的是把前端和测试资源化,整个公司共享。
图一
如上图一,这种多存在于大型互联网公司,以产品线划分团队,当然一个产品线会存在多个服务或者应用程序。团队人员对自己的产品熟悉度更高,团队内部配合默契高,同时更专业。这种模式缺点也很明显,不能做到资源共享,比如团队内部前端页面已经开发完成,但是其它团队也不能共享该团队的前端开发人员。
图二
如上图二,这种多存在于中小型软件公司,比如我们熟知的外包,基本就是缺少什么外派什么,完成后继续进行下一个项目。这种方式一大优势就是人员利用率优势更高,因为经常马不停蹄的连轴转,所以各个团队成员很难得到技术上的积累。
说到这里,接着回到正题,说说测试在其中的地位。
一般测试周期基本占开发周期(人/天)的1/3左右,因为相对开发还有后续线上问题解决和性能优化等工作,所以测试人员基本测试完了就没有后续了。
如果按照图一产品线划分的话,这种情况会好一点,基本会专注某一类应用软件或者客户端的测试,但是因为测试周期相对较短,所以实际情况下还会继续进行团队内部下一个应用软件的测试。
如果按照上图二的技术工种划分的话,组内的测试人员分配到相应的产品开发团队,开发完了就把测试人员收回来,然后分配到另外一个团队继续类似的工作。
这就导致了很多公司都有「测试人员资源化的趋势」,其实前端也是如此。之前我跟一个阿里的朋友聊天,他也给我聊到了这个现象。这就导致一个问题,每当公司进行晋级答辩的时候,就会非常尴尬,我们知道,一般答辩只会看功劳,很少看苦劳。前端和测试做了很多项目,但是深究一下,好像什么都没有做。
某种程度上来说,得到的成长有限。为了破解这个难题,只能在内部发起一些公司或者开源级别的项目,虽然大家在多个产品线各自忙碌,但是也有一些拿得出手的东西。那么这些事情就是加分项,比如很多互联网公司都有自动化测试平台、运维平台、前端框架等轮子。
有些测试团队的领导碰到代码开发的工作总是抛给开发团队,理由是我们没有这么充足的时间完成自动化测试用例的开发,不相信自己的团队能够完成开发工作。要我说这种领导「不是傻就是蠢」这种成长和练手的机会都不愿意抓住。还有一些工作中就是不停的点点点,如果你想延长自己的职业生涯,那么你要警觉了,尽快脱离这种环境。
事实上,这种现象是符合我国软件测试发展的,软件产业的兴起和发展只有短短的十几年,在这兴起和发展的阶段,开发软件追求「短平快,追求快速发展,追求利益,忽视质量」,在公司里,绝大多数人都在做开发,觉得只要能做出来,能用就行,也正因为如此,产品没有竞争力,这样的企业生存环境也是比较困难的。但是随着时间的推移,对应用软件的要求会越来越高,软件测试的质量越来越受到企业的关注。比如一些电商系统因为应用程序漏洞损失几千万,如果经过完善的软件测试,那么则会避免此类问题的出现。所以测试行业依然是当前不可缺少的一个岗位。
4、后续发展方向
对软件测试行业有了解的同学不难发现,现在功能测试找工作越来越困难了,归根结底还是技术原因。对这个行业不了解的人可能觉得,测试不就是找bug吗,有什么难的,简单的项目也许还能够应对,但是测试的核心就是质量保证,在产品更新速度越来越快的当下,单靠功能测试工程师是没有办法保证产品质量的。
近年来,由于多数测试人员没有太多的积累,行业内大量技术根基薄弱的测试工程师面临淘汰的现状(就目前这种裁员的趋势,很多开发人员直接转行测试开发,都没有太大的问题。)虽然这句话听起来比较残酷,但是你必须要看到这种变化。我私下跟一些测试人员沟通,也都是认为现在很多的测试工程师都不及格,要么是会点点点,要么是会一点自动化,高水平的测试工程师少之又少,这也就是为什么很多公司都要招聘测试开发工程师原因。
测试这个行业的女生偏多,很多就是为了不想写代码才要进入测试这个行业,但是依照现在的发展状况来看,若想长期在这个行业发展,不会代码是绝对不行的!会写代码将会让你在这个行业超越90%以上的测试人员。
整个行业的趋势及前景就是:
- 纯手工测试逐渐淘汰,更多的纯开发工程师进入测试领域;
- 有语言基础是测试岗位基本的招聘需求,会性能或者自动化测试是普遍要求;
- 大厂更多倾向于直接招测试开发,测试开发工程师的薪资会不断提高,这两种测试人员薪资差距会逐渐拉大。
资源分享
下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码,朋友们如果需要可以自行免费领取 【保证100%免费】