51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3143|回复: 3
打印 上一主题 下一主题

[转贴] 服务端功能测试小记

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2017-6-28 15:23:59 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
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、结语
啰啰嗦嗦说了这么多,主要是我自己的功能测试感悟,可能对某些方面的理解有些偏颇,大家不必较真,毕竟对于同样的问题,每个人都有每个人的看法。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

该用户从未签到

2#
发表于 2017-6-30 09:23:53 | 只看该作者
感觉盾比较适合我们……
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2017-6-30 09:24:18 | 只看该作者
就像好多人认为用到代码就是白盒测试一样,总是感叹自己在做黑盒(手工),做不了白盒测试(UI自动化),他们不知道UI自动化测试就是黑盒测试,只不过区别于手动点点点
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2017-6-30 09:25:26 | 只看该作者
悠悠小仙仙 发表于 2017-6-30 09:24
就像好多人认为用到代码就是白盒测试一样,总是感叹自己在做黑盒(手工),做不了白盒测试(UI自动化),他 ...

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

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-11 04:05 , Processed in 0.065594 second(s), 23 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表