何为靠谱?
在带新人过程中,交待测试新人测试任务时,都不会忘记交待这样的一句话:这个开发如何如何......
比如这个开发代码质量很好,少 bug,修改 bug 也快.
比如这个开发编码有点慢,跟任务时多催一下.
比如这个开发编码质量不怎么样,bug 多,你测试的时候多注意一点,仔细测试下.
像这样的交代有很多,特别刚开始还不熟悉开发的时候,等时间久了,只要测试过某个开发人员的项目一二次,就这个开发人员的编码质量基本也就清楚了.
靠谱的开发人员代码质量高,转测之前会先进行自测,代码 bug 少,有 bug 时影响也很快,和这类开发人员一起搭档做项目会感觉很轻松,代码质量高,上线有保证,测试人员都喜欢这样的靠谱开发,王豆豆就经常碰到这类开发,真是好运爆棚.
今天王豆豆并不是想分析如何找一个靠谱的开发,而是要分析如何成为一个靠谱的测试人员.
既然测试人员喜欢靠谱开发,那相反开发人员也会喜欢靠谱的测试人员.
那靠谱的测试人员是什么样的呢?
王豆豆认为靠谱测试人员应该具备以下几个特点:
1. 业务能力强,测试流程清晰
2. 测试覆盖面广,测试深度足够
3. 对 bug 敏感,能发现隐藏极深的 bug
总之一句话,你测试,我放心,软件质量有保证.
靠谱技能之一:尽可能多的覆盖测试范围
这个技能特别适合那种项目时间很短,需要紧急上线的小项目,这类项目需求太多不明确,且留给测试人员的时间非常少,测试之前测试人员对项目需求不了解,这类项目如果一拿到就开始测试,很容易就造成了漏测,那作为一个靠谱的测试人员就要想办法避免这种情况.
该类项目大部分都无需求,只靠与产品经理和开发人员的沟通整理需求.
1. 沟通确定测试范围
接到项目之后,首先查看提测邮件,配置测试环境和数据库,根据情况判断是否先进行一笔正常场景的测试,当成熟悉需求一种方法,当自己对需求有了大致的了解之后,就与找产品经理或开发人员进行沟通.
沟通内容主要围绕以下几点:
1. 此项目修改点是什么?主要做了哪些功能?2. 代码是如何实现的?
比如一个对用户敏感信息的加密解密功能,当前端将用户信息传入进来时,调用加密 API,将用户的敏感信息进行加密操作,然后存表数据,当再次取表数据进行其他操作时,这时调用解密 api,将用户的敏感信息进行解密操作.
这时业务流程上的实现方式,那对应到代码中代码是如何实现的?加解密 API 是怎么调用的?地址是多少?如何传参的等等
3. 本次项目修改的代码覆盖的范围,确实测试范围 4. 测试过程中需要注意哪些点?5. 异常情况会有哪些?
对照这几个问题一个一个的问清楚,理清楚.
2. 画出测试范围
如果上面几点在沟通中能到位,那测试人员基本对整个项目有了相对清晰的认识了.
这时拿出一个本子和一支笔画出测试流程,测试范围,注意点等等.
这个地方大家注意,王豆豆说的是画,并不是写,画代表在这个过程中会有修改或不明确的地方,将不确定的地方再次明确.
(今天以最近做的一个小项目为例,隐去了业务,见谅)
王豆豆经常在桌子上准备一个本子和一支笔,不管是对需求不理解的点,还是测试过程中遇到的不明确问题都先在本子上记录下来,这种方法特别适合新人,当上级或带你的前辈在安排任务或讲业务的时候,都拿笔记下来,俗话说得好 "好记性不如烂笔头",这是古人留给我们的智慧,我们理当好好传承.
3. 明确测试范围
将在本子上整理的测试点,测试范围,用 XMIND 等工具快速整理出来.
这时推荐用这种思维导图的工具整理,不推荐用 excel 或 word 文档整理,将整理好的内容发给开发人员和产品经理确认是否覆盖完全,检查点是否设置正确等问题.
为什么要做这步?因为每个人的理解都有所不同,做这步其主要目的在于消灭这种因理解不同,而导致后期测试不全,出现漏测的情况.
这些操作其实对应到测试流程就是需求分析,写测试用例和用例评审,在项目时间偏紧的情况下,可以通过这样的方式来进行,这些操作一定不能省,如果以这样的方式来做也需要不了多少时间就能完成.
靠谱的测试人员经手的项目覆盖面全,测试结果会很让人放心,测试质量更有保证,只有成为一个靠谱的测试人员,你的上级才会放心把项目交给你负责.看了王豆豆的分享,大家有什么不同的看法?欢迎一起来分享你们在工作中是使用何种技能让自己更靠谱的.
来源: https://www.cnblogs.com/evangline/p/8322018.html