找到最长路径，一条用例尽可能的覆盖更多的系统。
以某个系统为中心，找到它的辐射范围，设计用例来覆盖这些范围内的系统。
用例分组，根据不同执行策略执行不同分组用例。
正统集成测试概念：
WHAT：集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行测试。
WHY：实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
HOW：它最简单的形式是：把两个已经测试过的单元组合成一个组件，测试它们之间的接口。
中通集成测试概念：
中通集成测试是指关联业务之间的测试。
WHAT：提升了一层，在项目组内部测试的基础上，将全链路的所有相关功能串联起来，进行测试。
WHY：业务的诉求一般是为了解决一个特定的问题，转化为需求，也会是一个闭环的解决方案；当下公司的组织形式，往往是划分为不同的业务领域，分别解决不同特征的问题的项目组；在这两个背景下，一个解决方案会涉及到多个业务部门多个项目组相互协作。大的项目或者需求被分割后，每个项目组会专注在自己负责的这部分，加上自己的理解进行开发，内部测试也会基于自己项目组的需求文档来做质量保障，每个项目组内部可能都不会有问题，多个项目组串联起来可能存在风险。
HOW：为了解决上述所讲的问题，科技中心这边会有一套流程规范来约束跨团队（项目组）需求（项目）做集成测试，关注整体流程的通畅。
集成测试的目标是：确保跨项目组功能正确组合，整体上符合需求预期。
集成测试需要确保各系统组合在一起后能够按既定需求协作运行，并确保增量的行为正确。测试的内容包括各个系统间的数据流向，各个系统之间的接口传参值是否符合其他系统的要求以及集成后的功能实现。
（1）需求阶段
在中通，各个需求开始准备及评审时，集成测试就已经开始参与了；通过各个渠道（各测试负责人，项目经理，产品经理等）了解到当前或计划中的跨团队需求，集成测试的小伙伴会要求参与整个需求的需求评审及架构评审，此外，我们会找到所有涉及系统的需求文档。通过整体的需求时序图，各个系统详细的需求文档，及开发的架构设计图，来了解到整个需求的背景，各个系统主要负责实现的功能，以及各个系统之间是如何交互的，从而判断需求是否能够符合预期，及需求是否存在错误。例如：在做 T1COD 的需求时，整体的架构文档定义了一个新的类型 type=4，而有些系统的需求文档中，type 仍然写的是 type=2，我们在熟悉这些需求的同时，也就发现了这些潜在的缺陷。
（2）测试计划
整体需求评审、整体架构评审以及各个系统的需求评审结束后，整个需求会进行一个排期，集成测试也会开始制定测试计划。集成测试与各个系统的测试过程一样，必须精心计划，并且与各个业务系统功能测试时间协调起来，制定好集成测试的范围，涉及系统，以及起止时间等。
集成测试计划包括了：集成测试范围、涉及系统、开始时间、结束时间、测试人员等信息。
测试范围：根据集成测试所有需求的文档，综合评定测试范围。一般包括整体流程，分支流程及所涉系统存在与其他系统交互的场景等。此外还需评估一下回归范围，例如有的需求是分为多个迭代完成的，集成测试需要把之前涉及的流程进行回归。
涉及系统：所有参与该需求的系统都应涵盖在内，当然无系统交互的只是单系统独自改造的也可以由本系统的测试伙伴进行测试，集成测试不包含该系统。
开始时间：为了满足需求的快速迭代，集成测试开始时间一般会在所有的系统都进入测试阶段时开展
结束时间：根据集成测试的工作量、开始时间及上线时间综合评定。
（3）集成测试用例
制定好集成测试计划后，接下来我们要开始输出集成测试用例，及组织集成测试用例评审。
设计集成测试用例的前提：整体时序图，整体需求文档，架构文档，各个子系统详细需求文档。
设计集成测试用例思路：
找到最长路径，一条用例尽可能的覆盖更多的系统。
以某个系统为中心，找到它的辐射范围，设计用例来覆盖这些范围内的系统。
用例分组，根据不同执行策略执行不同分组用例。
用例设计好了之后，我们需要组织一次用例评审，目的主要在于集成测试用例的完整性，有无遗漏的场景以及测试用例的正确性等。
具体参与人员：主产品经理，主项目经理，开发负责人，各个系统的产品经理，各个系统具体的开发人员，各个系统的测试。
（4）集成测试执行
在所有系统都进入测试阶段后，集成测试也开始同步开展。集成测试人员按照测试用例逐项进行测试，并且将测试结果标注清楚。对于集成测试过程中发现的 bug，首先提交给对应的几个系统的测试进行确认，测试人员能直接确认是各自系统的 bug 后则直接提交缺陷给对应的系统开发。如若各自系统的测试无法确认是否为自己系统的缺陷，则提交给主产品经理，由主产品经理协商解决或者是确定不解决。
（5）集成测试报告
完成测试执行后，集成测试人员需要发送集成测试报告，主要内容有：项目名称，项目负责人、缺陷总数，遗留缺陷数，测试过程的分析与总结，执行用例情况等。
集成测试完成标准为：集成测试用例执行完毕并且所有用例通过。
如有未解决的缺陷遗留，经各方产品经理确认无需当下立刻解决时会发送准出报告，同时注明未修复缺陷以及后续缺陷修复计划，给到对应责任人。
若存在需要解决的缺陷，因为集成测试执行时间已经非常靠近上线日期，会经由主产品及项目经理确认，修复缺陷时效 以及后续回归风险大小，是否进行项目变更。
集成测试模式探索已经有 2-3 年了，一开始，集成测试走的很慢，困难重重。
各方不理解集成测试跟项目组的功能测试有何区别；
集成测试会需要额外的测试时间，各方不认为集成测试有价值；
集成测试的介入点很难找到，过程中发现的问题往往找不到对应的人来处理；
做集成测试需要全流程把握业务，对测试要求高，难度大，没有人愿意做。
到现在：
只要有涉及到跨项目组的需求，产品，PMO 都会主动来要求集成测试介入；
集成测试人员提出的缺陷，主产品会非常重视；
部分项目组会主动留一点时间给集成测试。
我们是看到了显著改善的，但是前路漫漫，我们需要优化的问题还有很多，比如这种全流程的自动化应该如何做？在每个项目组的步调不一致的情况下，我们该怎么控制整体的发版？如何预警一些容易发生问题的关节？如何让更多的业务测试人员有端到端的测试能力？等等都是我们目前没有解决的。
路漫漫其修远兮，吾将上下而求索。后续会跟大家继续分享集成测试中发现一些有意思的缺陷，期待关注！
