搜狗质量部 服务端功能测试小记

airong · 2017年03月28日 · 最后由 airong 回复于 2017年03月30日 · 95 次阅读

1、前言

过年回来之后,业务的功能测试渐渐多了起来,我之前一直负责的是 PC 方面的测试,而现在除了负责 PC 的业务测试之外,还负责无线业务的测试。骤然间自己所有的时间差不多都被功能测试任务占据了,到 2 月份末的时候,关于测试任务的排期都排到了 4 月初。

在这功能测试的狂轰滥炸中,慢慢的对于服务端重服务的功能测试有了更多的体会,趁着周末空闲的时间整理一下,以飨各位读者。

2、功能测试就是手工测试?

早些时候一直有这样的误区,认为功能测试就是手工测试。现在在脉脉的匿名区还有好多同学在感叹,不想做功能测试了,咨询自动化测试好不好学之类的问题。

在某些同学的潜意识里,认为 web 端的功能测试就是点点点,服务端方面的功能测试也就是手动构造数据,验证逻辑,这虽然比点点点好上一些,但仍没有跳出手工测试的范畴。对于以上的观点,我个人是不认同的,我认为将功能测试完全等同于手动测试是不恰当的,同样将功能测试与自动化测试完全分开来看也是不合理的。

从我自己功能测试的经验来看,将功能测试转变为自动化测试的一部分是效率最高的一种方法。在阐述这个问题之前,我先大致说一下我之前测试的一般情况。当开发提交测试之后,就根据测试单中的信息,手动构造数据,然后启动服务,验证本次提测的业务逻辑,其实这也是最典型的服务端功能测试的流程。这样做的好处就是可以快速的验证本次提测的业务功能,弊端就是当需要构造的数据量太大的时候,时间的成本也会很高。

除此之外,使用手动构造数据进行功能测试,在多次功能回归的情况下,测试人员是崩溃的,因为开发每修改一些代码,你就要把之前的 case 都过一遍。PC 业务线之前就是这样的做法,先进行手工功能测试,后续抽时间在填充相关的测试 case。无线业务线恰恰采用了另一个方法,先抽时间将 case 写完,然后根据提测需要完善相关 case。

在两条业务线实验了一段时间发现,无线业务线所采用的方法,也就是将功能测试变为自动化测试的一部分,效率要高很多。特别是由于一些需求变动,或者少量代码修改,需要验证是否影响之前所测功能的时候,效果尤为明显。这个时候我就让开发人员自己去跑一遍自动化 case,而我也从重复的功能性结果验证中解放了出来。这个小主题的意义在于,是否能将现有的功能测试,整合进自动化测试中,当然不同的业务的要求也不一定一致,大家根据自己业务的特点,自行评估即可。

3、讨论维护自动化 case 的必要性

虽然自动化测试有很多的好处,但是维护自动化 case 确充满了痛苦,甚至有些时候你恨不得从此再也不用它了。让人如此仇恨的原因,每次跑 case 失败的太多,而且失败的 case 大部分是很久之前的功能,很多时候你根本就从来没有听说过这个功能,这种情况下去查看与之相关的 case 为何失败,我相信很多人面对这种情况,心情都不会太好。

通常情况下,你排查了良久,也无法判断为何某些 case 失败,郁闷的心情可想而知,这个时候你可能会想,如果只是回归当前提测的功能该是多么幸福的一件事。在经历了多次这种事情后,慢慢的也察觉了一些规律,以及排除某些错误 case 的方法。就像电视上或者生活中没有无缘无故的爱,也没有无缘无故的恨一样,在自动化 case 的回归的世界中,也没有无缘无故就失败的 case,每一个失败的 case 都有其失败的原因。

当错误的 case 发生时,需要排查代码的上一个版本中该 case 是不是失败。一般情况下,上一个版本的 case 应该都是全部通过的,因为如果 case 不通过肯定无法上线嘛。这个时候你就对比当前代码的版本和上一个代码版本,看看究竟是修改了那些内容使得 case 失败了。通过代码文件静态对比,以及运行期间的 gdb 单步调试,我想找出失败 case 的原因不是难事。

经历过多次这样的事情后,就看的比较开了,出现失败的 case 也会慢慢的去分析原因,不用一出现问题就去喊开发。在这里多说一句,测试人员和开发人员应该保持相对的独立性,不要什么都依靠着开发,如果真的需要找开发来解决某些问题,你应该能大致知道问题出错可能的原因在什么地方。

4、如何高效的写自动化 case

谈到写自动化 case,很多同学就说,这个很简单,按照 EXCEL 表中或者 xmind 图中功能测试的用例,把所有的 case 都写上就好了。当然这个情况下是最理想的,把所有可能的情况都覆盖掉,但是现实情况下,你可能根本没有时间将所有的 case 全部写完,这个时候你就要在规定的时间内,用最少量的 case 完成最大的代码覆盖,拒绝重复的 case,以及一些非常简单的 case。

重复的 case 这个比较好理解,比如某项功能在某个测试用例中已经验证过一次了,那么就没有必要在其他的 case 中再验证一遍。那么什么是简单的 case 呢?说到简单的 case,就要提及代码 review 了,现在很多测试不参加开发的代码 review,当然各种原因都有,比如时间紧、任务重啊,或者没有这样的惯例啊等等。

我想说的是,如果有条件,尽量在进行完粗略的主功能验证后,开始进行代码 review,代码 reivew 不但可以让你对所测业务理解加深,提前发现一些代码级的 bug,对于编写自动化测试用例也是益处良多。比如代码中,有关于某些字段的验证,再仔细查看代码后,针对性的构造自动化 case,没必要根据每一个字段分别构造 case,甚至你通过查看代码某部分业务逻辑已经非常清楚了,在时间紧的情况下,可以不添加与之相关的 case。

简单的 case 是建立在你对代码逻辑异常清楚的情况下,判断某业务逻辑非常简单,不值得添加用例进行覆盖的 case。恩,比较绕口,但应该不难理解。

5、框架的易用性、通用性以及高效执行

当 case 添加完成之后,总体回归所有 case 时,一般为了节省时间会将 case 分发到多台主机上同步执行。当 case 的数量巨大时,这种设计思路非常有必要,以目前的无线的自动化 case 举例,现在差不多接近 600 个 case,如果放在单台机子上跑的话,跑完要 1 个半到 2 个小时。

如果分散到三台机子上跑,可能半个小时就跑完了,case 数量的不断增加,分布式执行成为必要。关于分布式构建之前已经写过文章分享过,这里就不再过多阐述了,有兴趣的同学可以自己找来看看。

本小节要重点谈的是框架的易用性、通用性和高效执行。易用性很好理解,就是上手非常快,只需要填写少量必须的参数,整个任务就可以跑起来了,想目前一直在使用的第一版基于 jenkins 的分布式系统,只需要填写本次代码的 svn 地址或者 bin 文件,然后根据功能需要在中控机上做少量修改,就可以执行了。因为上手非常容易,所以教开发自己来跑任务也不用花很多时间成本。

我之前设计的第二版分布式系统,解决了易用性和高效执行两个方面,但是在通用性上做的不好,所以到现在就 pc 业务线在用,甚至我想把无线的分布式迁移过来,也不是几行代码或者几个小时能搞定的。由于现有的框架和业务联系太紧密,导致了扩展性也不好,现在正在开发基于 ansible 和 docker 的分布式解决方案。关于这个方案我会在后续的文章中详细的谈,这里就不多说了。特别是在大部门,多业务线的情况下,一个框架的设计要兼顾几个方面,能复用就复用,不要重复的开发,浪费人力物力。

高效执行之前也谈到过了,就是如何在尽可能短的时间内,将程序运行完。第一版的分布式系统虽然利用分布式主机的特点,提高了执行时间,但是还是没有把现有的计算机资源利用起来。第一版的分布式系统,单主机情况下,同一时间只有一个服务实例在运行,而现有的主机资源,可以同时支持 3 个甚至更多的运行实例,所以第二版分布式系统和第三版就利用 docker 容器规避了这个问题。对于一个通用性的工具或者框架,以上三个因素都非常重要,如果不能兼顾的情况下,根据业务需求自行取舍吧。

6、结语

啰啰嗦嗦说了这么多,主要是我自己的功能测试感悟,可能对某些方面的理解有些偏颇,大家不必较真,毕竟对于同样的问题,每个人都有每个人的看法。最后,欢迎大家关注我们微信公众号"铸盾师"

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 4 条回复 时间 点赞

感觉盾比较适合我们……

就像好多人认为用到代码就是白盒测试一样,总是感叹自己在做黑盒(手工),做不了白盒测试(UI 自动化),他们不知道 UI 自动化测试就是黑盒测试,只不过区别于手动点点点

恒温 回复

😂 😂

026 回复

说的是这个事,将用到代码就约等于白盒测试的同学,应该是入行不久,入行几年后就发现在当今的互联网公司,绝大部分的测试都是黑盒,白盒基本上很少用到。相反一些传统的公司,比较重要的服务白盒还多些

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