原文：RUNNING AN AUTOMATED TEST PIPELINE FOR THE LEAGUE CLIENT UPDATE译者：杰微刊兼职译者张迪大家好，我是Kisel，我的工作是为英雄联盟客户端更新做测试，构建和部署团队。在这里，我们要谈论的是项目的自动化测试。
如果您曾经使用过当前的联盟客户端(“AIR“客户端)，您可能已经遇到了一些奇怪的错误。即使那些问题是罕见的，你仍然可能会想到“wtf Rito，这怎么可能存在，“你这么做是完全有道理的——因为体验不符合我们想提供给玩家的质量。之前一篇关于在客户端更新架构的文章提到了我们在发展原始客户端时使用AIR的决定——它支持丰富的多媒体效果，但是不可能在HTML中使用。然而，遗憾的是，AIR客户端自动化测试覆盖面有限。开发和发布更新是一个缓慢而危险的过程，因为要想变更一些内容就必须要手动测试——这是一个耗时和不连贯的进程。理想情况下，我们会让机器测试枯燥的，重复的东西，让人类做更有创意的测试工作(在吉姆最近的文章中有更多的相关内容)。
联盟客户端更新的核心目标之一是让简单粗暴的测试自动化，那么我们就可以给玩家提供他们应该得到的优质体验。客户端更新的架构包括一个基于谷歌浏览器的前端和一个C++的后端，这些为进行交流提供了REST api和websockets 。此体系结构为我们提供了两个方便的自动化接口：对于前端来说，我们可以使用ChromeDriver，这是行业标准Selenium WebDriver协议的具体实施。对于后端来说，我们使用开源的HTTP请求和websocket库。这些都是地球上最常见的自动化接口，所以我们没有必要实现自定义的自动化测试驱动程序。我们已经实现了功能测试和运行使用Cucumber.js。
这些都是具有丰富文档的常见工具，所以，在本文中，我将关注我们的流程和渠道，而不是我们的工具。我希望这将有助于任何想要接近一个类似于自动化挑战的人。
运行时间的测试示例
联盟客户更新验证系统架构
文化
成功的测试自动化在很大程度上是一种文化和心理学。技术在其中只是起到次要的作用。
无论我们有多少技术，我们仍然需要鼓励正确的人类行为，致使自动化测试成功。每一次测试失败，人们必须正视它并判断这个失败是否是正在测试项目中一个真正的失败、还是一个行为不端的编写差的测试，或是某种其他环境或基础设施问题，比如网络故障。
传统的自动化测试策略是先有一个有质量保证的团队为开发和运行测试来维护负责。这种方法有一定的优点，你最终会得到完全拥有测试系统的主题专家。它通常适合长发布周期的项目，如果你的团队一周之内对一个新的构建只测试一次，那么即时反馈并不是那么重要。
此外，这对专业的测试工程师有好处，工程师们能花时间设计复杂的测试用例，充分锻炼每个构建。我让我们的艺术家来想象这个过程:
然而，这也有明显的缺点。当开发团队不运行测试，或者只关注结果时，他们就会倾向于采用“各管一摊”的心态。开发者自己失败的代码学习反馈循环往往是缓慢的，这并不是可接受的。联盟客户端更新动作极快，从早上到晚上，基本的开发环境每15分钟会接受一个新的构建。以那样的速度，即时反馈是至关重要的。即使测试本身迅速执行，我们也不能等开发人员等待测试工程来解释结果。团队效率是我们的核心目标之一，所以传统的自动化测试就不会为我们工作。我们的方法是这样的：
我们的信条是使测试和自动化成为整个团队最关心的问题。每个开发人员都有参与其中。我们的标准项目新员工培训过程包括详细的如何编写文档和运行测试，我们会让开发人员弄清楚，我们期望他们完全拥有自己代码的单元测试、功能测试、性能测试和负载测试。测试、构建和部署团队专注于建立和维护测试工具和基础设施，但这个团队并不自己编写测试——这是个别特殊团队的责任。
我们现在能达到一个高度，联盟客户端更新测试失败时团队能快速反应和调查。然而，很难达到这一点。学习如何应对片状测试由始至终都是难题。
原来的工作流程是这样的：
1、注意到一个测试是偶然性失败;
2、只是偶尔失败，所以它可能不如其他坏掉的东西紧要，可以忽略它几个小时或几天;
3、最终开始调查，如果测试确实是错了就检查修复。
结果就是：团队开始假设，任何失败都可能只是一个片状测试，所有的结果将被忽略。如果团队在测试系统时没有信心，该系统就是一文不值的。如果你的汽车检查引擎灯随机打开时，你可能会开始忽略它。为了防止这种类型的习惯，我们目前的工作流程是立即调查失败的测试，以确定该测试已经跑偏还是我们发现一个合法的bug。
将被破坏的测试移动到我们阶段测试套件，是以尽可能高地保持完整测试套件的信噪比。为了测试，阶段套件在正常的构建渠道之外运行。新的或重构的测试被放在某一阶段几天，确保在我们将其放到全套之前它们是健康的，在那里他们可以通知开发人员失败和block部署。
我们不断强化通过面对面讨论的方式、发布会议公告的方式、或团队间邮件的方式来保持我们的测试和构建健康的重要性。关于bug或测试的任何讨论都是一个宣传自动化福音的很好的机会(礼貌地)。每一个团队都会定期地进入“必须停船”的心态，然后开始不重视测试的重要性，这是很自然的，有时会为测试要求感到沮丧。当然，我们必须小心地找到没有提醒和太多提醒之间的适当平衡，在这两种极端的情况下，没有人能得到消息。当有远程团队参与其中时这可能需要特别注意。
这些文化的态度并不是放之四海而皆准的。他们必须仔细定制以满足各种项目和涉及的人员。最重要的部分是没什么是理所当然的，不做任何假设。总有改进的余地——我们时常留意系统是如何顺利工作的，并适当作出调整。未完待续......
