测试基础 简单聊聊,如何构建测试工程师的能力模型 (持续更新 2020.08.26)

Kyle · 2020年08月10日 · 最后由 OllieForever 回复于 2021年01月26日 · 661 次阅读

大家好我是个摸爬滚打多年的小管理者,刚开始,测试团队基本上都是以功能测试为主,慢慢地,在实践的过程中发现测试工程师应该给他们更多的权利,让他们能够在团队的帮助下,发挥更大的作用,所以也把相应的一些理解和一些重点分享给大家,从组建队伍的角度,我是如何构建公司的测试能力模型,招募到适合自己团队的成员,以及在整个测试生命周期里,对一些工具和方法的理解,希望对测试的小伙伴有帮助;

在做这些之前,先对测试人员的能力做个简单的分析:

测试工程师的要求:

软实力(1 级为必备实力,2 级为上升的实力,3 级为加分的实力)


1级:有责任心、有条理性

2级:善于沟通、协调能力、情绪控制;

3级:主观能动性、分析能力、业务理解能力

首先针对级别的分层,先来聊聊一级分类,一级分类我觉得是每个测试工程师该具备的,或者说,是初级测试工程师就该具备的,相信大家常听过,招测试,就是要招有 “责任心” 和 “细心” 的人,这里我先把细心归类为条理性,我们先来讲讲有关 “责任心” 这东西;

责任心:

大家都有疑问,如何判断一个人有责任心,这里给大家一句话,责任的反面是风险,规避风险就是负责,而放任风险是不负责;举个经常例子:

员工同事,每天都是最后一个离开,离开时,通常会花 15 分钟检查好公司的门窗,把门锁上,老板每次说起时,都会夸这个员工有责任心;
这里的 “责任心” 就是,关闭者,规避了 “公司因未锁大门而发生偷窃的风险”,而不关闭者则放任 “公司因未锁大门而发生偷窃的风险” 发生;

如果你们对责任心有一定的认知之后,其实招聘要问的题目就很简单了,可以定几个方向,一是对风险的认知,二是对交叉事项的判断,三就是做事的方式是否有规划性;

面试可以这么问:

现实场景的提问:产品经理评审结束之后,已经进入开发阶段,在一次用例编写中,你发现了产品设计里面有个小问题,但是并不影响现有的功能,这时候你怎么做(交叉事项)?
变换场景的提问:除了你们部门的工作之外,你有觉得日常工作中,你的上一家公司有哪些安全的问题需要改善的吗?

接着我们再来说说条理性:

条理性

条理性指的是,有顺序、有条不紊,除了日常的工作习惯之外,通常还体现在测试用例的编写上(个人认为,测试用例是功能测试的核心),条理性强的人,能有效的保证测试用例的覆盖面;

说到这我们可以用设计方法里的的场景法来举例,场景法跟等价和边界还是有所不同的(后面可以给大家也说一下),通常用在业务流程的测试上,所以在利用场景法去做用例设计的时候,整个用例的覆盖程度取决于你备选流和异常流梳理,并且要注意每个关键节点的操作,假如你一开始并不能很好的分析出来,并且做组合,那就将会导致很多场景不会被你的用例覆盖到,所以说条理性很重要;

在这一块的面试考核上,我不知道其他面试官是否会纳入考核,我对条理性进行考核,通常是给个场景,做场景的用例分析,在分析及步骤的拆解中,就能比较容易的看出来了;

聊完一级分类,我们简单的说下二、三级分类,二级分类很简单,相信大家套一套基本了解是什么,除非是非常流程化的公司,否则绝对少不了沟通协调这两个方面,项目本身讲的就是一个团队协助,至于情绪控制这一点,大家可以去总结归纳下,产品经理与测试,开发与测试,三方之间在一些矛盾点上会有什么问题,这里就不细讲了;

三级分类无论在哪个岗位里,都是我比较喜欢的人的一些特性(包括开发),只是在测试的垂直领域里,我觉得具备这 3 个特点,已经可以算是比较优秀的测试工程师了;

硬实力(相对于软实力,我分为四级)


1级:功能测试、接口测试、测试基础理论;

2级:数据库、抓包;

3级:自动化测试、python、性能测试;

4级:Linux、版本控制;

通常,对技能的考核,大小型公司都会包含 3 级以上;

以下对一些工具和内容做一些说明和解答:

缺陷管理:TAPD、Gitee、JIRA、禅道等等

说明:缺陷管理工具视团队而选择,基本都很成熟,基本都用过,个人喜好禅道多点

用例编写:XMIND、excel;

说明:这里强调一下

1、现在越来越多的人喜欢使用 XMIND (或其他脑图工具)来编写测试用例,但很多人在执行时会犯下一个较为严重的错误,表面上像取代掉了excel了,担实际上编写的不是测试用例,而是“测试思路”,这种行为,会使您的测试覆盖率大大降低,所以要特别注意;

2、用例还是推荐使用 excel格式,不过可以与 xmind相结合,首先定好格式,再通过 xmind编写,接着以表格形式导出,最后加上数字导入禅道即可;

用例编写方法

场景法:https://testerhome.com/topics/28051

接口测试:Postman、Jmeter、Swagger、Charles、Apizza

说明:
1、现在我们用的是Apizza,一个加强版的Postman,除了前后端联调接口使用之外,做接口测试以及接口说明非常便利,而且还可以组合接口测试,唯一不足点就是付费,哈哈;

2、可能有一部分的测试工程师,对接口测试可能不是很在意,觉得这是开发做的事情,其实不然,学会接口测试,能解决很多问题,后面有关在测试优化的环节,我会给大家一些方法和案例,教大家去规避测试组经常面临的一些典型的问题,其中就包括“冒泡通过率”低下的问题,这里给大家提一嘴,是不是有很多测试工程师,提BUG的时候不知道是前端的问题还是后端的问题,这里有个判断的标准:如果前端传输的数据没问题,后端返回的结果有问题,那么就是后端问题;如果前端传输的数据有问题,或者是后端返回给前端正确的数据,而前端展示的数据有问题,那么就是前端问题;而懂这一些内容,除了要学会监控接口数据和状态,你首先也要学会接口测试吧。

数据库类型:Mysql、Oracle、Redis(下面第三点划重点)

说明:
1、测试工程师最好能掌握公司的主要用的数据库的操作,一般都是mysqloracle,也有用nosql的,这个因公司而异;

2、会的sql操作其实不用太复杂,简单的增、删、查、改外加联表查询;

3、重点来了,敲黑板,有人经常问,测试工程师会数据库有什么用,我送给大家一句话:你会的越多,你能把控的东西就越多,你依赖别人就变少;你会的很少,那么意味着你依赖别人会很多,你所做的事情就会变得更被动。你们是否有一个场景,本来改个状态你们就可以重新走流程了,结果开发半天才给你处理,是否有一个场景,状态是开启的,实际数据状态是关闭的,导致发布到线上才有问题,所以你们细品,好好细品,我就不多说了,有空后面单独拎出来说;

4、续上面3点,给大家一个告诫,测试过程中,不要过度地依赖数据库,因为某些BUG不是因数据引起,而是因流程引起,大多数开发工程师在测试时,为了方便也是通过修改数据来测试,所以当你的方法和他一致时,他们无法发现的问题,也意味着你也无法发现问题;

5、造假数据、模拟数据的工具很多,利用sql制造假数据进行测试就是其中的一个方法;

抓包工具:Fiddler、Badboy

说明:

1、现在抓包的工具大家用的比较少,不是因为没用,是因为现在请求大多数谷歌浏览器一个F12就可以搞定了,什么Network啊,Disable cache啊,Online模拟弱网环境啊,Lighthouse分析啊,功能都很强大了,所以在web测试里用的比较少;

2、至于小程序和公众号,有对应的工具了,大家都知道;

3、啥用的比较多,APP

自动化类型:接口自动化、UI 自动化

说明:
我相信很多测试管理者和执行者都会有这样的一个问题,UI/接口自动化该不该做,怎么做才是合理的,我跟很多个面试者和行业的测试管理者有过多次的沟通,我发现一个问题,大家对自动化,特别是UI自动化,在认知上会有一定的偏差,很多人都在尝试着做出初步的判断,觉得 UI自动化可以提高效率,然后就大手大脚地去做,并要求每个项目的自动化覆盖率达到多少,接着越执行越发现不对,工时比较长,于是又开始加班,最后累死累活得整出来,产品经理迭代了一个新的版本,UI发生了变动,然后脚本直接GG;想骂人的心都有了;
那么,为什么会有以上的现象呢?其实:

1、现在互联网讲的就是敏捷开发,快速迭代,而UI自动化测试是要确保流程稳定,UI上不要出现大的变动,否则XPATH节点要重新获取或者是新增修改删除;
2UI自动化测试,编写成本较高,维护成本往往随着版本的迭代次数增加而增加;
3UI自动化要明确,主要解决的是回归测试的问题,而不是取代功能测试;

较优方案:(敲黑板)结合以上三点,个人建议,UI 自动化测试,应侧重于对主要流程的测试,针对性的编写自动化脚本,确保主要的流程在任何功能的迭代下都能得到快速的回归测试,而且这种形式应该是投入最少收益最高的,即使 UI 发生了变化,从价值上来说,进行维护也是值得的;

python(编程能力及思想): 待编写 ing......();

性能测试(教程不多说,网上一搜一大把):

说明:
问大家一个问题,大家在什么时候接触性能测试比较多,答曰:面试的时候;我还听过一个调侃,国内的大部分公司都高估了自己的用户量(笑);但实际上也不一定要用到性能测试才会在面试中出现,大多数都是为了观察面试者是否具备相关知识和经验,以及掌握的测试的知识面如何,好了,下面进入正题;

其实绝大部分公司有这种情况很正常,据我观察,大部分的性能测试需求都是来自技术端,技术端开发出了一个系统/功能,然后给了测试端,然后说我要达到某一指标,你们帮我测试验证,接着测试人员利用测试工具开测,所以,一旦技术端没有需求就等于没有性能测试(是不是冥冥之中感受到了什么),大多数情况下,测试端仍然过于依赖技术端的驱动。

要打破这个僵局,还需测试端转换下思路,当有一个需求进入分析阶段时,或者进入测试阶段时,测试人员应该思考,该需求是否需是否需要性能测试,测什么,怎么测(3H/5H大法),从而提供该系统/功能性能测试方案。

那测试人员怎么进行性能测试,我觉得分2大块:

linux: 待编写 ing......();

版本控制: 待编写 ing......();

工作中的规范化文档:

测试工程师 BUG 编写规范和要点(自家公司的,只供参考)
https://docs.qq.com/doc/DUGdPaE9yT1lWZFVU

测试工程师 BUG 评级规范和要点(自家公司的,只供参考)
https://docs.qq.com/sheet/DUElZWnpQUUxBcHhm

测试流程的疑难杂症:

典型问题 1:冒泡测试通过率低下的问题 

解决方案 1(常规操作):建立规范化的测试流程,在开发转交给测试团队时,可以审查功能是否符合要求(验收流程),如果没有通过,则驳回给开发团队,由修改完成再继续提交;   

解决方案 2(进阶操作):提前向开发成员提供冒泡测试用例,并在开发成员完成冒泡测试后将其转交给测试;   

解决方案 3(砖石操作):建立产品演示的验收流程。当开发成员完成开发阶段后,由开发主管(或开发主要负责人)发起,同项目组各成员一起进行产品演示,由测试人员现场验收产品,若冒泡测试无法走通,或者出现 1 级 BUG,记录并在当天进行修正,如果问题比较严重,则由各组的负责人一同拍板,是否顺延项目周期来处理问题,顺延的后果,由开发组承担; 

分享下思路:

首先分析下冒泡测试通过率低的问题,找出问题的本质,其实该问题不是来自测试端,而是来自开发端,这样的话,你会发现,单纯优化测试的流程,通常指标不治本。也许有人会说,这是开发人员要做的事情,关测试什么事,出的问题也是开发的问题,你们可以往下拉去看测试工程师的第六段位的描述,里面就有说到,“走向前端做缺陷预防” 并 “固化测试流程”,你们应该学会打破你们的圈子思维,这样才能从本质上去解决你们遇到的难题,所以我们先来简单看下技术侧到底有哪些现象:

1、有部分后端工程师会进行测试接口,但是比较少去核对数据准确性,更少的去做组合测试(冒泡一定是组合测试);

2、有部分前端工程师大多都是模拟数据(有些公司不提前出接口文档的,是在联调阶段直接对接),在真实的接口输出之后,直接验证数据类型和接口是否有问题就结束了;

3、有部分的开发工程师,会因为项目周期较短,将部分的功能遗留到测试阶段进行开发(特别需要注意的一个点);

4、有部分的后端工程师,不做接口测试;

5、有部分的开发工程师,认为应该有测试工程师去暴露问题;

那么,怎样让他们按照我们的要求,有效地进行冒泡测试呢?很简单,找一个动因,化被动为主动,让开发人员自动去暴露问题,从而避免出现问题,当然,绩效也是一种手段,但是绩效相对是一个硬性的手段,而上面提到的第三种方法,是我个人觉得非常好的一个措施,而且也得到了有效的验证,自实行这一过程以来,我们冒泡的通过率是 100% 的,而且 BUG 也呈现出下降的趋势,至于为何效果比较明显,其实也很简单,应该没有一个开发工程师,愿意在大庭广众之下频繁的暴露自己的 BUG,从而让他们懂得去规避这样的问题(风险);

PS:可能有些开发人员,会因此感到不爽,对这种行为感到厌恶,但别忘了,开发本来就应该为其代码质量负责;另外,有些 BUG 的问题是因为历史原因所导致的,例如耦合度较高,改一发动全身,这些并不在此次说的范围内,这个是技术问题;

测试工程师的方向

待编写 ing......()

测试工程师的优化方向

待编写 ing......()

测试的基本流程

待编写 ing......()

测试工程师的角色段位(先更新下这个)

待编写 ing......()

测试工程师的分层测试模型

待编写 ing......()

共收到 26 条回复 时间 点赞

欢迎楼主,等更新😀

写的好,谢谢楼主!

写的好!

Kyle #26 · 2020年08月10日 Author

写的有点范,只是跟大家大致讲下逻辑和思维,有一些深入的点,想要了解的,可以在下面留言,尽能力解答;有些点后面会重新开贴展开去说;

插个眼

有用,特别好,感谢分享!!!

Kyle 关闭了讨论 08月11日 15:47
Kyle 重新开启了讨论 08月11日 15:47

学习了,谢谢分享

仅楼主可见
Lasha 回复

1、微信开发者工具,让技术给你加个开发者权限即可;微信公众号、小程序官方的软件;

软件地址:https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Web_Developer_Tools.html#5

2、测试方案这东西,直接百度一大把,我这里给你讲几点核心的,方便你去理解这个词汇;

所谓的方案,就是面对一件事情,怎么去做,对应到测试方案来,就是面对一个需求/项目,你怎么去测,测什么,用什么测,怎么测,需要多少资源,进度计划是什么样的,什么标准才算测试完成,有可能产生什么风险,等等;

然后转换成指标就是:测试范围、测试策略、测试类型、测试资源、测试进度、发布标准、风险说明;

当然方案有很多内容,基本是因地制宜,就像 PMP 里有 5 大过程组,49 个过程,但是实际项目管理中,都是有选择性的;所以不要太过纠结这个名词,分析你所面临的需求,需要去做什么样的计划,包括什么内容,这是最重要的;

感谢楼主的分享

很好的文章

很接地气。等后续。

匿名 #15 · 2020年08月14日

测试菜鸟来报道~ 楼主的文章写得很通俗易懂呢,读起来很接地气,期待楼主的更新,这里菜鸟想补充一个自己在工作中会用到的抓包工具 whistle,自我感觉比 fiddler 好用

Kyle #15 · 2020年08月14日 Author

感谢关注,你提到的抓包晚点会更新上去。因为时间关系,会抽空持续更新,慢慢先把一些常用的内容跟大家分享一遍;

写的很好,看看先

腾讯的?

插眼插眼,等待更新

收藏,期待楼主更新😀

同感 +1

写的真是好啊。

Kyle 关闭了讨论 08月26日 17:55
Kyle 重新开启了讨论 08月26日 17:56
chenxin 回复

好好,来更了,更新下疑难杂症部分;

感谢楼主,感觉思路更清晰了,现在有点困扰是关于测试同事的绩效如何制定由哪些方面组成

超民 回复

绩效头疼很正常,不知道怎么处理绩效,是暂时没想到,从管理的角度来讲,你准备拿绩效来干什么,我个人觉得有几个点,

1、我想要我的组员遵守同一套规范做事;
2、我需要要求我的组员工作的完成的质量和效率;
3、我要评判组员之间,谁更优秀;

第一点很简单,基本的测试规范要有,测试规范不统一,测试效率会低下的,开发也会头疼,但是你定出来的规范组员不一定遵守执行,所以首先围绕着测试规范去定绩效内容(可定量);
第二点其实就讲的是质量和效率,举几个指标:项目 delay 天数、1 级 bug 的回归周期、正式环境进行回归的 bug 数,正式环境运行时的 bug 数等等,以上都是可以量化的;

说明:
1、以上 1、2 点信息,其实你仔细去看里面的一些指标就会发现,实际上就是管理者从各个方面去考核下属在岗位上的匹配程度;
2、通常情况下,是根据自己的管理方向而决定的,例如,你更关注上线后的 bug 数,那么该项权重就要高点;
3、所有的指标,都是可量化的,既然都是可以量化的,那么就应该是可以追踪的,比如上线后的 bug 数量,应该同步建立统计机制;
4、谨慎地将测试环境 bug 数和用例的数作为测试指标,想清楚目的和反效果(大家会为了增加 bug 而加 bug);
5、基于以上 2 点会出现一种情况,就是大家都做得非常好的情况下(都遵守规范了,并且没出现 bug 问题),出现的分数是一致的,此时千万别认为你的考核出现问题,你应该心目再次默念下你考核的目的,要想清楚,制定考核不是为了扣分的,但是可以通过改进改善这个问题,我们继续往下;

实际上考核应该分为 2 部分,1 部分是定量,另外 1 部分是定性,完全定量的做法是不科学的,你无法定性的话,你会发现,除了日常的工作以外,你的组员的发展缺乏了一定的方向感,所以需要定性的指标,有一些掺杂着主观意识的考核,这个和我上面的第三点很吻合,就是大家都在做的好的前提下,怎么做才超越期望,也会管理上你给你组员的一个方向;例如:鼓励你的组员提供解决方案、优化团队效能、引进新的技术、组织技术分享、编写技术文章,鼓励团队配合程度高、面对问题不推脱不抱怨、价值观、甚至你还可以把发现除了代码以外的安全问题(甚至可以提供解决方案),以便来培养测试发现问题的能力以及责任心,这些都是给你组员除了定量的考核以外,增加一个方向,结合这 2 点,基本上考核就比较完整了;

PS:当然,有些定性的考核,有可能出现一些声音,这个没啥问题的,大不了建立委员会机制,让大家举证,但是看有没有必要,都是有办法的,另外可以量化的东西,千万别量化太细,可以采用抽查的方式,或者交叉检查的方式;

dongfanger 测试行业 1-3年 的发展路线 中提及了此贴 10月09日 10:55

坐等楼主更新~

2021 年了~坐等大佬更新~

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册