如何做好服务端功能测试

近期，业务的功能测试渐渐多了起来，我之前一直负责的是PC方面的测试，而现在除了负责PC的业务测试之外，还负责无线业务的测试。骤然间自己所有的时间差不多都被功能测试任务占据了，截至目前，关于测试任务的档期都排到2个月后了。

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

Part.1

功能测试就是手工测试？

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

在某些同学的潜意识里，认为web端的功能测试就是点点点，服务端方面的功能测试也就是手动构造数据，验证逻辑，这虽然比点点点好上一些，但仍没有跳出手工测试的范畴。

对于以上的观点，我个人是不认同的，我认为将功能测试完全等同于手动测试是不恰当的，同样将功能测试与自动化测试完全分开来看也是不合理的。

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

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

在两条业务线实验了一段时间发现，无线业务线所采用的方法，也就是将功能测试变为自动化测试的一部分，效率要高很多。特别是由于一些需求变动，或者少量代码修改，需要验证是否影响之前所测功能的时候，效果尤为明显。

这个时候我就让开发人员自己去跑一遍自动化case，而我也从重复的功能性结果验证中解放了出来。这个小主题的意义在于：是否能将现有的功能测试，整合进自动化测试中，当然不同的业务的要求也不一定一致，大家根据自己业务的特点，自行评估即可。

Part.2

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

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

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

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

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

Part.3

如何高效的写自动化case

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

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

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

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

Part.4

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

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

如果分散到三台机子上跑，可能半个小时就跑完了，case数量的不断增加，分布式执行成为必要。相信小伙伴们都了解这些内容，就不赘述了。

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

我之前设计的第二版分布式系统，解决了易用性和高效执行两个方面，但是在通用性上做的不好，所以到现在就pc业务线在用，甚至我想把无线的分布式迁移过来，也不是几行代码或者几个小时能搞定的。

由于现有的框架和业务联系太紧密，导致了扩展性也不好，现在正在开发基于ansible和docker的分布式解决方案。特别是在大部门，多业务线的情况下，一个框架的设计要兼顾几个方面，能复用就复用，不要重复的开发，浪费人力物力。

高效执行之前也谈到过了，就是如何在尽可能短的时间内，将程序运行完。第一版的分布式系统虽然利用分布式主机的特点，提高了执行时间，但是还是没有把现有的计算机资源利用起来。第一版的分布式系统，单主机情况下，同一时间只有一个服务实例在运行，而现有的主机资源，可以同时支持3个甚至更多的运行实例，所以第二版分布式系统和第三版就利用docker 容器规避了这个问题。

最后，对于一个通用性的工具或者框架，以上三个因素都非常重要，如果不能兼顾的情况下，根据业务需求自行取舍吧。

作者： Airong