测试工程师的光荣与梦想

Posted 笑哼

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了测试工程师的光荣与梦想相关的知识,希望对你有一定的参考价值。

水之积也不厚,则其负大舟也无力。-庄子

前两篇主要谈了谈测试的成长与瓶颈,并未涉及到测试工作本身的内容,从本篇起,笔者将与大家就测试的实际工作内容与大家一起交流与探讨。

测试的实际工作千差万别,各个细分领域差别非常大,比如自动化测试,性能测试,客户端测试,web测试等等,同为测试中人,如果一个测试工程师接触面不够广,基本上听不懂对方说什么,更别谈融会贯通了。如果非要找出一个关键点是所有测试工程师都很熟悉和绕不过去的,那无疑就是测试用例了。

笔者从事一线测试多年,对测试用例也有比较深刻的思考与实践,在不同的公司也见过五花八门的用例,可谓是求同存异,雅俗共赏。

下面我们就逐一来分析下用例的几个关键节点:

1,格式

一个用例如果在格式上乱七八糟,让人一看就就天然的厌恶感,执行起来自然不会有很好的效果。有人会问,我用例写完了,覆盖度完整了就行呗,强调格式有什么用?那么我们就来看看格式的作用,笔者认为至少有以下几点重要性:

01) 让用例变的脉络清晰,富有美感,让执行过程不至于过于枯燥。

02) 方便执行人员的认知和理解

03) 方便需求变化后的更新维护

04) 方便用例的统一管理

那么问题来了,什么样的格式才是个好格式呢?这个就是见仁见智了,但是以下几点至少是应该做到的:

01) 脉络清晰且有逻辑性,不能想怎么写就怎么写

02) 尽量保持输入和输出的单一对应,一条用例中包含多个输入或输出,会给执行人员带来巨大困扰

03) 要能够被维护,这个是常见的问题所在,有时候维护一个旧用例的痛苦超越人类忍受极限,还不如重新写一份

04) 同一个用例的不同模块之间尽量保持统一格式,举个例子,不能一会a代表a,一会a代表b,这样会严重损害执行人员的身心健康

2,需求分析

笔者遇到很多测试工程师拿到需求文档后都没通读和深入分析,就直接上来写,遇到这种情况,笔者只能说,哥们还是回家卖红薯吧,比较有前途一些。。。 笔者认为至少经历4个阶段才能动手去写,即详细阅读->沟通探讨->逻辑梳理->拓展思考。

第一个阶段:阅读。让我们来看看如何阅读才能在我们真正动手时有如神助

01) 详细阅读至少2-3遍

02) 尝试站在需求人员的角度去理解其设计意图和思路

03) 推敲逻辑,关注细微,有些需求隐藏在一些不起眼的语句中,或者是需求人员想要的但是没有写明的,都可以在阅读的过程中推敲出来。

04) 超越需求,如果让你来设计,有没有可以设计的更好的地方

05) 记录问题,阅读过程中记录不理解的地方,及时与需求方核实并做备注

这样阅读,我们才能深入到设计核心,理解为什么这样设计及当前存在哪些误区或不理解的地方。

第二阶段:沟通探讨。这个阶段可能很多人都忽视,等动手写用例的时候才会去与需求方探讨,这样不仅会打乱双方的工作节奏,也会增加很多没必要的沟通成本。让我们看看在阅读需求阶段,怎样做好沟通。

01) 遇到拿不准的地方,及时跟需求方沟通探讨,还是那句话,不要以为你以为的就是你以为的

02) 探讨问题时最好与需求人员,开发人员一起探讨,不要让沟通出现断裂或增加二次沟通

03) 关注变更,要思考变更对上下文的影响

第三阶段:逻辑梳理。文档我读了,也理解了,为什么还要梳理逻辑呢?笔者认为主要基于以下几点原因:

01) 需求文档不一定是按照流程顺序书写的。尤其是不同模块之间出现功能交叉的时候,可能一会描述a模块,一会描述b模块。如果我们不梳理,按照文档顺序写,一会就写乱了,会出现完全写不下去的情况。

02) 去除冗余,面对复杂的需求,覆盖度是一个层面,冗余度也是一个层面,逻辑不梳理清晰,冗余太多会导致执行过程效率低下,甚至拖累项目周期。

第四阶段:拓展思考。软件实际运行的情况太过复杂,稍有不慎就可能酿成大错。这个阶段也是考察一个测试人员功力的地方,毕竟大家练的套路看似都差不多,至于内功如何,就只能呵呵了。在这一阶段,我们主要应该关注以下几点:

01) 设计缺陷思考:我们知道在一款游戏中,功能与功能之间的藕合度比较高,牵一发而动全身。有时候设计人员考虑的并非完善,这就需要我们要整体考虑,把跟本次需求有关的旧有功能梳理一下,看看是否有需要一起调整的地方。

02) 测试难点思考:阅读过程中要思考每个点怎样才能测到,是否有以现有技术手段无法测试的地方,如果有则需要及时提出让开发人员提供技术支持。

03) 兼容性思考:兼容性的注意点比较多,比如数据兼容,版本兼容,功能兼容,操作系统兼容,分辨率兼容等等,尽量要提前考虑到可能遇到的问题,毕竟用户的实际情况非常多。

04) 特殊情况思考:比如断网,断电,低网速,重启等等

3,模块划分

笔者经过多年的实践和总结,整理了下模块划分的原则和方法,不一定全,供大家参考。

模块划分原则:

01) 高内聚。指的是单一模块划分后,模块内部之间要在逻辑上有紧密的关联度,也就是说这个模块不能继续被拆分下去。举例,比如邮件中的附件功能,虽然它包含各种类型的附件都需要测试充分,但是这个功能本身作为独立模块就不能继续拆分了。

02) 低耦合。指的是模块与模块之间的关联度比较低,不能合并为一个模块。举例,邮件中的收件功能和发件功能,这2个功能关联度很低,不能合并为一个模块来梳理。

03) 重整体轻局部。指的是要有大局观,从整体层面去关注模块之间的构成和联系,不纠结于具体的细节。举例,测试UI的时候经常会与具体功能相掺杂,这时候就要从整体层面来看怎么拆分逻辑更清晰,不要扎在细节泥潭里不能自拔。细节问题可以在模块划分完毕后细化模块的过程中再具体分析。

常用的模块划分方法:

01) 功能流程法:将功能的基本流程图画出来,根据流程走向来划分模块。举例,银行的ATM取款功能划分就比较符合这种方法,我们可以粗略的划分为一下几步流程:插卡环节->密码登录环节->输入金额环节->取走钱币环节->取卡环节,这样我们根据不同的环节流程来划分不同的模块,基本能使整体结构看上去逻辑清晰,简单易懂。

02) 层次划分法:按照逻辑层次逐层细化出模块的过程。以大家比较喜欢玩的dota游戏来举例,第一层我们可以分为战斗外内容和战斗内内容2部分,第二层的战斗外内容又可以分为账号登陆,按键设置,外部链接等内容。。。依次类推,我们就可以逐层细化,从而将整个游戏的模块划分清晰。

03) 类型划分法:按照功能包含内容的不同类型来划分。还是以dota举例,比如测试英雄系统,我们就可以先根据英雄类型来划分成,物理攻击类和魔法攻击类或者近程攻击类和远程攻击类。然后可以继续根据小类型来划分。

类型的划分原则和方法有时候不会单一出现,更多的时候要结合使用,最终目的是使得模块划分的清晰、全面。

4,用例编写方法

这个过于老生常谈,笔者没什么原创跟大家分享,网上的内容比较全面,比如常用的边界值,等价类,判定表等,笔者就不班门弄斧了,大家可以自行求助百度大神。

5,整理与维护

很多人认为用例编写完毕后,任务就完成了,实际还有后续的问题需要大家关注,常见的有以下几点:

01) 需求变化后需要及时更新旧用例,并就更新做详细的注释,方便执行人员理解和执行

02) 测试用例应该在保证覆盖度的情况下尽量避免冗余

03) 注意备份,遇到用例丢失或者被误删除,那简直生不如死啊

以上笔者就用例的书写环节与大家做了简单沟通,欢迎大家批评指正。下一篇笔者会就执行环节跟大家继续探讨。

 


链接:https://zhuanlan.zhihu.com/p/20878039

以上是关于测试工程师的光荣与梦想的主要内容,如果未能解决你的问题,请参考以下文章

测试工程师的光荣与梦想

游戏测试工程师的光荣与梦想-百炼成钢

测试工程师的光荣与梦想

练习搭建接口自动化测试框架详细过程

从零基础到车载测试工程师,薪资11K,肯拼搏的人,总会有所收获

光荣的梦想