做有生命力的接口测试
最近一直在忙碌组内的接口测试，一直从技术上想着如何让接口测试变得简单，上手快，傻瓜式的用法，觉得只有这样才能更加广泛的推广。于是一直想着尝试如何将各种方法打包封装，学习各种接口测试技术。然而在做接口测试日常后，却感触很大。接口测试，技术也许是难点，但它构建的只是接口测试实现的平台。接下来的接口文档评审，测试设计，数据准备，用例实现才是直达高质量接口测试的阳光大道。如果说接口测试主要是技术，那么它似乎就只剩下代码和文档了，和开发的代码的本质区别在哪，会干皱，没有水分。那么，如何改变这个状态，让接口测试变得生动起来呢，这也许更值得思考。在任何状况下，业务都是测试的充分条件。如果接口测试能和业务点更好的结合，那么会是什么情况呢？1.测试评审时尽量和业务点结合起来。虽然看到的可能只是接口输入参数，返回参数，但是如果联系到业务，这些参数变得有灵魂起来，很有意义。页面上好多连续的操作，最后的提交，转化为一个接口的参数的请求。这个在理解接口的含义很有帮助。
2.有时候参数非常的多，如果每种情况都去测试，那么最简单的2的n次方也会有上千条数据，但经过分析，其中很多条就是等价类测试数据。灵活缜密的判断参数的组合条件，那么和业务结合起来，是最佳之路，可以提高测试的精准度和有效性。不同参数值组合起来就是一条条的业务点和对应的测试用例。具体实现可以采用正交表来做组合。
3.测试数据的准备。有人说跟功能测试数据一致。我觉得要更难一点。因为不再那么直观了。有的数据是数据库查询的id，有的是经过加密的格式，有的是cookie一串看不懂的字符串等等。因为会看不懂，但是结合了业务点去确认参数值，这似乎会容易多了。
4.接口测试和业务点功能回归测试是绝配。做接口测试，停留在代码阶段，而客户端或者页面的处理依旧需要功能测试来把握最后一道质量的关，必要流程的功能测试的回归，这个也是与业务点分不开的。
不知为什么，我有时候看一条条测试用例，觉得它们鲜活，有生命力，栩栩如生的在那静静的展示着业务点。我想我是很喜欢这个职业。接口测试，技术是支撑，掌握业务是指明灯。灯亮着，就不再迷茫。结合业务，让接口测试更加有活力起来吧。
:lol
页:
[1]
