由国际机票搜索自动化想到的

chrishetong

本人是一名国际机票测试人员，公司不便透露，今日跟大家探讨一下国际机票的搜索，如何进行快速有效的测试。


事先注明：本话题虽然起因于我所测试的业务，但本思路应该可以覆盖到较广范围的查询类接口测试，只要你理解了思路，我相信聪明的你知道在何处可以用到你自己所在的业务中去。


标题：由国际机票搜索自动化想到的
副标题：快速迭代下的自动化回归测试模型思考


近日一直在研究国际机票接口自动化的事，之所以选定这块优先做自动化。有几个原因：
1.
国际机票搜索接口稳定，参数不变
2.
有大量的线上基础数据可以用（产品信息、AV缓存）
3.
可重复测试性强
4.
要响应国际机票开发团队的快速迭代
5.
国际机票搜索回归量大，占用QA资源


最开始的思路其实很简单，就是利用线上数据搭建国际机票的自动化测试环境。并小规模的针对单程直飞的接口进行了近万次的接口调用测试。这个思路其实可以叫做压力测试，但是我的调用方式是顺次调用，并比对结果（比对方式就是看接口报文的某个标记位是否标识本次请求正常应答了）。这种测试方式虽然好，但是只能测出类似程序崩溃、抛异常之类的错误。
在你的业务每两周上一个版本迭代的今天，你通常要回归更多的搜索内部逻辑处理，而不仅仅是简单的程序崩溃、抛异常之类的错误，我们该怎么办呢？
由此我想到了一个快速迭代下的自动化回归测试模型。




上图说明：
在如上图的软件迭代过程中，V1可认为是基线版本。
在由基线版本过渡到版本V1.1，可认为功能未有改变，可能仅仅是代码重构or软件运行环境改变等。
由V1.1过渡到版本V1.2，可认为有功能改变，导致输出结果的变化。


本模型的基调为：上一个版本的输入对应的输出总是正确的。
对应到上图，就是认为V1版本的输入对应的输出都是正确的，大家也可以理解为线上运行的版本的输出总是正确的。在输入相同并且数据量足够大的情况下，通过记录上一个版本与迭代后的版本的输出结果，进行比较，得知本次版本迭代是否影响到了原有功能。


举例说明：
在V1版本中相同的10万种输入，对应10w种输出，定义为V1版本的10万种输出。
在V1.1版本中还是同样的10万种输入，对应10w种输出，定义为V1.1版本的10万种输出。
在V1.2版本中还是同样的10万种输入，对应10w种输出，定义为V1.2版本的10万种输出。


根据之前的理解，本自动化回归模型使用方式为：
一、
V1版本的10万种输出，与V1.1版本的10万种输出进行比较，比较结果为：全部相同。结论：由V1版本到V1.1版本的迭代过程没有影响到已有功能。
二、
V1版本的10万种输出，与V1.1版本的10万种输出进行比较，比较结果为：不全部相同。结论：由V1版本到V1.1版本的迭代过程影响到已有功能，提示开发修正。
三、
V1.1版本的10万种输出，与V1.2版本的10万种输出进行比较，比较结果为：不全部相同。结论：分析结果不相同的输入输出，若为功能改进，则认为此案例通过。若为原有功能，则迭代过程被影响，提示开发修正。
四、
延展一下思路，当不相同的输出/总输出占比大时，还可提示本次迭代风险较高，需引起足够重视。


本模型优缺点：
原有的测试回归方式，测试人员在快速迭代又资源紧张的情况下，只有几条路可选：
1.
放弃全部回归，冒风险上线
2.
增加测试时间，牺牲快速迭代
3.
增加更多的测试人员，扩大成本

在有了自动化回归模型后，软件的快速迭代上线变为可能，测试人员只需将精力专注于本次迭代改造的功能上，其余的回归部分由模型自动完成。优势：
1.
仍然能做到全部回归，不需冒风险上线
2.
不需要增加测试时间，仍然可以保证快速迭代
3.
不需要增加更多的测试资源，只有自动化运行环境那几台机器的成本而已
4.
测试人员因为只需专注于新功能，减少重复劳动，工作成就感新鲜感加强
5.
辅助测试人员判断本次迭代风险是高还是低（依据不相同的输出/总输出占比）
缺点：
难以发现上一个版本中已存在的bug


欢迎大家一起讨论