一个系统往往是接口衔接的地方最容易出问题。对于跨多个系统的项目接口多，交互多，有一个地方衔接的不好或者有差错都可能会产生严重的BUG乃至导致系统重新设计的可能。最近做了两个项目都是跨系统的项目，我这里谈谈跨系统的项目需要注意的几个问题，怎么做的一些建议。

　　需求阶段测试将如何做？

　　对于跨多个系统的项目在需求阶段一定要熟悉彼此的系统，如果是改造性的项目需要自己去熟练其他系统，多问问相关熟悉的人，另外对于全新的需求不要只关心自己的系统的需求，其他系统需要做的需求也同样需要关注，特别是涉及到交叉的地方。一有疑问就提出来不要把问题遗留到后面设计阶段，就怕提不出问题来，大家把所有有疑问的全部罗列出来，只要能提出问题不怕没人来解决问题。这就是所谓的知己知彼百战不殆。但目前很多情况下是大部分只熟悉自己的系统，对其他系统不熟悉，这种情况下在需求阶段需要多花费一些心思，找出需求中问题，静下心来想想需求中的接口交互的部分可能会存在什么问题，应该如何设计才能避免那些问题。

　　跨多系统的项目计划应该注意什么？

　　对于跨多系统的，交互多的项目，很多时候计划两天开发联调，实际情况往往要多出两天左右才能联调好，所以计划中联调的时间要留有两天左右的余地。另外多接口的测试时间也要留有余地，很多时候我们我们认为既然联调通过了，流程通了，测试起来应该很快，应该就没有什么问题，但是往往事与违背，不要把希望寄托于开发自测，不要太相信开发的自测程度，当然不排除有自测还是可以的。所以对于这种牵涉到接口多的，需要多方联调的联调测试时间也要稍微多加两天左右。另外系统多了，接口多了，环境因素也会浪费很多时间，哪个应用不可用都会导致测试无法继续进行，所以环境因素，协调时间也需要考虑进去。

　　设计阶段测试将如何做？

　　一般在开发方案设计，UC设计的时候，测试一般花费的时间比较少，这种情况下提不出什么问题，建议在UC设计的时候自己也画画流程图，多想想一些异常情况，特别是对于一些交互的地方需要注意是如何调用的。不拘泥于形式，最重要的是自己去写UC的时候才会不断的发现问题，解决问题，评审的时候才能找出一些问题，进一步熟悉系统，也加强了评审的意义。写测试设计尽量详细点，对于交互的地方如何回写修改什么状态等等能写的最好都写出来，便于设计用例。对于有疑问的要多沟通，当然不是开发怎么说就怎么做，有不同意见的时候需要把自己的意见和开发的意见做个交流，权衡一下如何做好。再者就是写测试用例的时候建议交互多的情况，多考虑场景测试，都考虑一些异常流情况，这类用例不需要写的很详细，基本上见名思议的形式。可以用场景用例来验证开发的设计是否合理。如果设计即能满足正常流程也能满足一些异常场景这说明设计基本没什么问题。另外需要与对方的开发，测试多交流，相互的设计和测试设计大家一起过一遍，看看是否有交叉点遗漏。

　　数据准备阶段将如何做？

　　对于跨系统的项目，我认为数据准备阶段是最能熟悉对方的系统的时候了，通过造数据，走流程等一系列动作后，对对方系统相关部分一般都能了解的七七八八，如果此时对系统有疑问的敢快提出，也许是设计上没有考虑到的。当然在造这些数据的时候会遇到很多麻烦，遇到很多自己不知道的东西，没有关系，找到相关的人问清楚怎么做，问过之后把这些个操作流程沉淀下来，方便以后自己造数据。另外，需要多准备些数据，有些数据经常是使用一次性的，或者用途不一样。在造这些数据之前要计划好哪种类型要准备多少，能在测试之前准备好的数据尽量测试之前准备好。

　　测试执行阶段应该如何做？

　　上面提到测试阶段我们往往以为联调都好了，冒烟应该没有什么问题，应该很快，但是往往交给我们的还是一盘散沙，不是这个系统走不下去就是那块走不下去了，此时不要急燥，要淡定。我们可以配合开发联调，往往有测试一起参与联调的速度会快很多，流程也比较容易通，如果冒烟之前能主动参与他们的联调就更好。另外，往往冒烟阶段页面都是走不通的，需要知道修改哪些表哪些数据，怎么造数据来执行测试。对方系统数据库表也需要去了解（在测试准备阶段了解）。跨多系统的项目，环境经常出现问题，不是这个系统环境问题就是那个系统环境问题，测试执行不下去了，此时要淡定，先告诉相关的人让其把问题解决，另外想想还有没有遗漏点没有考虑到，是否需要补充用例，是否可以造一些数据，等环境好了再测等等。