从测试代码级别也需要保证不同测试之间的隔离性，构建的结果不应该依赖于测试被执行的顺序。在优化过程中我们遇到过这样的情况：基于UI的功能性测试依赖于一部分用户基础数据，其中测试T1在运行过程中需要修改特定用户的角色，在测试T2需要使用该用户完成其他的业务操作。如果T1在T2之前执行可以构建成功，反之则会构建失败。

解决这类问题通常有两种做法，测试运行之前创建不同的用户或者测试运行结束之后恢复用户数据。对于第二种方法，如果当前测试没有正确地清理数据会导致下一个执行测试失败，增加了定位问题的难度，所以更推荐使用前者来保证不同测试之前数据隔离。

　　2.增加必要的等待

在UI测试中很多操作都依赖于页面元素出现的时间、位置等，在不同的网络环境、机器性能不同，页面的加载速度也不一样，测试运行的结果也会有所不同。通常web driver会提供一系列的方法来帮助开发者判断元素是否已经加载完成、是否可见、页面是否已经加载完成等（比如Watir的when_present, wait_until_present等），在测试代码中合适的地方使用这些方法可以让测试代码更加健壮，从而提升Pipeline构建的成功率。

　　3.正确测试异步行为

系统中的异步操作可以为用户提供更好的使用体验，系统不需要等待当前操作完成就可以继续处理其他操作，但是异步操作也增加了测试的复杂度。在项目的集成测试代码中我们发现类似这样的等待操作：sleep 10， 这种原始的等待策略不够稳定，对于网络状况、机器性能、数据量等外部因素依赖较大。回调（callback）和轮询（loop）是两种推荐的测试异步的方法，回调不会有任何尝试任何多余的等待时间，但是使用场景比较有限；轮询通用性更高但是会产生一定的多余等待时间，对于轮询操作，建议使用更小的等待时间间隔（interval）和重试（retry）上限。

　　调整测试结构

不合理的测试结构也是影响Pipeline性能的重要因素，根据测试金字塔理论，就测试数量来说，从低层级到高层级的测试需要保证金字塔状的结构。测试的运行时间呈现的却是一个倒金字塔状，测试的层级越高测试运行的时间越长，对应Pipeline的构建时间也越长。所以改进Pipeline也可以从调整测试层级结构开始。

　　1.梳理业务流程，简化测试结构

新的功能在不断增加，已有的需求也不断在变动，产品本身也不断接受来自最终用户和市场的反馈，现有的测试有可能并没有覆盖那些最有价值的场景而已经覆盖的场景也许在真正的产品环境下使用率很低；有些场景已经在低层级的单元测试覆盖，在高层级测试中出现了很多重复的用例。

调整测试结构可以和领域专家一起，重新梳理业务流程，把测试的重点放在那些最有价值的业务场景上，在高层级增加适当的UI测试保证核心功能没有被破坏。对于出现重复或者价值不大的测试，可以考虑删除高层级的测试，用更多的单元测试来替代，从而降低测试的运行时间。关于自动化测试更多的优化手段可以参考一个遗留系统自动化测试的七年之痒。

除此之外还需要构建有效的反馈回路，通过Google Analytics等网站分析平台收集来自于最终用户和市场的数据、用户使用习惯、时区语言等地域性信息对应地调整现有的测试结构，让测试环境下的业务场景更加接近真实的产品环境。

　　2.用契约测试替代集成测试

Integrated tests are a scam. A self replicating virus that threatens the very health of your codebase, your sanity, and I’m not exaggerating when I say, your life.” - JB Rainsberger

JB Rainsberger的这个说法一点也不夸张，在项目中总是有关于集成测试的各种“吐槽”，构建时间慢、问题难以复现和定位、修复难以验证、不稳定等。而契约测试就是那个可以拯救你，让你脱离“苦海”的利器。

契约测试是“单元级别”的集成测试，基于消费者驱动的契约测试把契约测试分为了两个阶段：消费者（Consumer）生成契约和提供方（Provider）验证契约，在生成契约时通过Mock隔离真实的服务提供方，运行单元测试生成用JSON描述的契约文件；服务端验证只需要部署自身就可以验证契约文件的正确性。

契约测试有很多优点，首先它不依赖于完整的集成环境，部署成功率高，其实在测试运行期间无真实的API调用和模拟的UI操作，测试运行的速度快，成功率高；而且在本地开发环境就可以验证契约测试，问题容易定位，修复的反馈周期短。引入契约测试不但给Pipeline性能带来大幅度的改善，还可以提升整个团队的开发效率。

　　如何保护改进成果