如何进行接口自动化测试
在开发子系统的时候，接口测试是至关重要的，但是往往子系统间的接口也会随着版本的演进发生变化，这导致面向接口的测试用例的维护成本提高。为了提升子系统间接口的测试效率，项目考虑自动化的对接口进行测试。
接口自动化用例需要满足维护成本足够小，能够模拟用户操作的各种参数，测试用例可以无人值守的执行等要求。次要因素包括不包括用户行为的逻辑性，即自动化测试用例不需要客户的参与，这是为什么呢？毕竟接口的是下层系统对上层客户（系统）提供的服务，客户的操作是否合理，应该是在系统接口的测试范围之内。《Automated Acceptance Tests Are Not The Right Move》 一文中提到了对这个问题的讨论，其中主要的观点是寄希望于客户参与完成自动化测试以满足客户使用满意度，是不现实的。其中主要的问题在于首先客户可能在系统做出来之前并不知道他想如何操作，那更别提客户参与的自动化测试用例能够描述客户的真实意图；其次这样的自动化用例的维护随着系统的演进可能变成开发人员的噩梦。
但是问题是如果完全不考虑接口的逻辑的正确性，也是行不通的。所以项目考虑把问题一分为二来看，自动化测试完全是一种随机构造的参数，它的目的是发现系统的不稳定因素，例如边值问题，漏洞问题等等，通过自动化测试的子系统能够保证其鲁棒性。第二我们把用户参与的逻辑性测试采用录制的方式，来抓取用户真正的操作。
对于自动生成用例来说，接口参数的取值范围等约束条件是必要的输入（否则只能随机取值了，这样测试效果可能不是很好）。如果接口是使用XSD来表述的，上述问题应该很好解决。但是目前项目中有很大一部分接口是通过ASN.1来定义的，它只规定了数据结构，而没有描述字段的取值范围，也没有相关的约束条件（如是否是key，是否必填等等），这导致单纯生成的用例可能碰撞效果不明显。为了提高 ASN.1接口自动化用例的碰撞效果，一种方法是使用EXCEL 或者其他形式对ASN接口进行重描述，另外是通过可配置的生成策略模板。相对来说后一种方式维护工作量可能会小一些。
对于接口逻辑性的测试环节，计划是采用录制的方式+手工用例的方式，其中录制方式有几个问题有待解决，一是各个接口在真正的操作时序上是有先后顺序的，例如上一个接口的输出时下一个接口的输入，这种情况下如何模拟接口的返回是个问题。二是逻辑性严重是否需要遍历各种参数情况，仅严重一种逻辑的正确性，再加上自动化测试，能否保证各种逻辑的正确性。
对于第一个问题，我们可以通过自动生成一份mock数据，以便能够抓取到尽可能多的用户操作逻辑。对于第二个问题是需要探讨的问题，自动化的测试像上面提到的，有可能碰撞效果并没有预想的好，那可能造成通过自动化测试没有模拟出一种隐蔽的操作逻辑，而偏偏这个逻辑的处理存在漏洞。要解决这个问题单靠一方面是不可能完成的，通过手工枚举所用的操作逻辑可能明显是不可行的，单独靠自动化测试也有可能有漏网之鱼。所以如何是二者的结合尽可能做到的覆盖，是我们下一步的重点目标。
