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

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

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 容器规避了这个问题。对于一个通用性的工具或者框架，以上三个因素都非常重要，如果不能兼顾的情况下，根据业务需求自行取舍吧。