【原创】系统接口测试有感

    最近忙于两个系统间的测试。现在将近测试尾期了，自己觉得在测试过程中收获了很多，也有一些值得改进的地方。所以把感触写出来，希望给自己和别人以后的测试工作有所帮助。

    接口是基于两个不同的系统，进行的信息交互。因为是不同的系统，所以各个系统间的很多的设置和业务逻辑是不一样的。可以肯定的一点是系统间还是有部分相同的操作和信息的，要不然也不用做接口了。

    首先，业务分析人员会给出系统间接口的业务逻辑和需求，以及两个系统间的一些字段的mapping表。（就是A系统的某个字段对应到B系统的某个字段，都应该在这个文档中清晰正确的给出）

    QA在拿到需求和匹配文档之后，就应该结合自己所测系统的逻辑跟接口逻辑比较（有些系统的接口逻辑和应用软件的逻辑不一样，接口会增加或放开某些逻辑限制 ）。QA应该仔细比较异同处，因为文档当中也有可能有错误。

    在编写测试用例初期，QA应仔细分析需求和进行静态测试。对于mapping表里面的字段，如果是真正系统实施的时候，有些字段是需要做同步的。mapping表里面的系统下拉菜单的字段要特别留意，像下拉菜单里面的value是不是完全匹配的，而且不能只是凭UI上的值去判断，一定要用DB里面的code去判断。因为有些字段，虽然在两个系统UI上的值是一样的，但是在DB里面的code是不一样的，而接口测试肯定是用code来传递参数值的。（我在测试初期就犯了这个错误，只在UI上判断两个系统里面的菜单value。忽略了code，导致在测试过程中很多defect是因为这种原因产生的，而这些其实是可以在测试前发现并提出的。）测试用例的设计基本上采用"End-To-End" 流程模式。

   一般在测试的第一，二个版本上系统都是不稳定的，可能只是实现了需求中的部分功能。所以在测试初期我们不需要去测试很具体的东西，只需要走大概的流程。去确认一下在这个测试版本上实现了哪些功能，哪些功能还没有实现。

   在第三、四个版本上功能基本上都实现了，这个时候我们就需要仔细的测试各个"End-To-End"的flow了，一般还会有挺多的defect的。这两个版本测试过程中，我们应该注意要插入对于mapping表里面所有字段的测试，看是不是所有的字段都能正常显示，某些特殊字段我们还需要去xml文件里面核对一些code。（在这次测试过程中，我的失误就是对于字段的测试进行的太晚，以至于到测试后期出现某个字段的defect导致function flow走不下去的情况。） 这个阶段还有一个值得注意的问题就是，有些字段在第一次从接口传送的时候是可以成功发送的。但是一旦修改后，即使没有修改的一些字段再次发送的时候都有可能被miss掉的。

  在第五、六个版本上，基本上就比较稳定了。但是此时也不能掉以轻心，还是要把所有的flow都仔细的走一遍，可能还会有漏网之鱼呢，呵呵。

  以上就是我这次接口测试的心得，希望对大家的测试有帮助。^_^