diffy,一款使开发和测试从测试中解脱的工具 (一、背景及简介)

背景

测试,是软件开发的一个十分重要的环节,是软件质量的保证.几乎没有一个产品团队敢向用户/客户交付未经测试的代码.测试虽然只是一个验证阶段,但要完成所有用例的测试,却是一个费时费力的过程.

一个项目,从第一个版本发布,到形成一个相对完善的版本,再到后面的重大更新甚至重构,需要经过许多版本的迭代.随着项目的迭代,产品功能不断增加,项目会变得越来 越复杂.然而在后期,我们修改增加的功能相对上一版本已存在功能的比例却是越来越小.但每一次或大或小的版本升级,我们都需要保证新增或修改的功能不影响上一版本已存在的功能. 但要达到这一点却是困难异常,哪怕只改了一行代码,哪怕这项更改由非常优秀的开发者完成,我们都很难保证这项功能对上一版本的功能无任何影响.

要保证每次上线的安全,我们需要开发和测试完成两项工作.
一是开发者在增加或变动某项新功能后,补充相应的测试用例,但写过单元测试的同学都知道,完成一个测试用例所花费的时间可能比完成相应功能花费的时间更多得多,有时甚至达到2至3倍.特别在后期,一个小的修改可能需要增加几十甚至上百个用例.假如一个服务存在三个相互关连的逻辑逻辑A,B,C, A有3个case,B有4个case,C有5种case,那整体就是345=60个case,如果我们在后续功能中需要给A增加一个case,需要增加的不是一个用例测试,而是145=20个case,若是时间有较多盈余,完成这个需要很多的时间,大多情况只能写几个核心的测试用例;而在人员不足,时间紧张的情况下,则更是难上加难了.
再是在上线前,由测试人员对前面的功能完成一轮回归测试.前面我们提到过,在后期,我们修改增加的功能相对上一版本已存在功能的比例却是越来越小,但是因为功能在不断增加,回归测试的工作量却是越来越大.同时因为是回归,可能几百甚至上千用例中才会发现一个问题,甚至一个问题也没有,测试投入工作的时间与最终的收益不成比例.另外**测试人员对相同内容的重复测试,会有一种疲惫感,这样一是会给测试人员带来消极情绪,当真的有问题(尤其是较复杂的数据问题)发生时,也可能会因为这种疲惫而将问题忽略(如果一个用例测了10遍都没问题,第11遍测的时候心里可能会默认这个地方是没问题的了).**这时候有些测试人员可能会考虑做自动化测试,但是自动化测试前期投入的成本较高,另外对测试人员的要求较高,如果项目变动比较频繁,部分自动化测试可能需要重新设计,会带来较高的成本.

而Diffy为上述问题问题提供了较好的解决方案.不同于我们常用的其他测试工具或框架,从代码或接口的返回结果的正确性去验证;而是如其名,通过代码的差异去验证测试.
差异,至少是两者之间比较才有差异,对于第一行代码或新增的功能,无法比较,自然也就无法验证,这时diffy无法发挥作用,但在后续增加修改,项目不停迭代的周期中,diffy就可以发挥它的舞台了. 有了上一版本以及测试人员在上一版本测试工作的基础,我们就通过上一版本和当前版本比较差异了.

diffy是怎样工作的?

首先我们需要运行三个项目实例,分别是primary(上一版本1),secondary(上一版本二),candidate(当前版本),然后diffy作为一个代理服务器.我们将所有请求发送到diffy上,diffy将相同数据转发到三个应用实例上,之后diffy将对三台服务器返回的数据比较差异,如果数据完全相同,那我们基本可以认为本版本的修改对这个服务接口是无影响的了.
如果有差异呢?前面也许你已经开始好奇为什么上一版本需要两个应用实例了,对同一服务的同一请求,我们返回的结果并不一定是不变的,所以我们需要两个服务去看这个接口本身是不是变化的.比如说我们最常用的验证码,基本每次和上一次取都不相同.如果primary和candidate不同,而primary和secondary也不同,那虽然这个接口本版本和上一版本是有差异的,但我们也可以认为是安全的.而仅primary和candidate有差异时,它则有较大可能是修复了上一版本的bug,也可能是引入了新的bug,这时候我们就需要对比差异,验证这个接口了.

下一篇Diffy的安装与使用将介绍如何安装部署使用diffy.