联盟客户更新验证系统架构
　　文化

　　成功的测试自动化在很大程度上是一种文化和心理学。技术在其中只是起到次要的作用。

　　无论我们有多少技术，我们仍然需要鼓励正确的人类行为，致使自动化测试成功。每一次测试失败，人们必须正视它并判断这个失败是否是正在测试项目中一个真正的失败、还是一个行为不端的编写差的测试，或是某种其他环境或基础设施问题，比如网络故障。

　　传统的自动化测试策略是先有一个有质量保证的团队为开发和运行测试来维护负责。这种方法有一定的优点，你最终会得到完全拥有测试系统的主题专家。它通常适合长发布周期的项目，如果你的团队一周之内对一个新的构建只测试一次，那么即时反馈并不是那么重要。

　　此外，这对专业的测试工程师有好处，工程师们能花时间设计复杂的测试用例，充分锻炼每个构建。我让我们的艺术家来想象这个过程:


　　然而，这也有明显的缺点。当开发团队不运行测试，或者只关注结果时，他们就会倾向于采用“各管一摊”的心态。开发者自己失败的代码学习反馈循环往往是缓慢的，这并不是可接受的。联盟客户端更新动作极快，从早上到晚上，基本的开发环境每15分钟会接受一个新的构建。以那样的速度，即时反馈是至关重要的。即使测试本身迅速执行，我们也不能等开发人员等待测试工程来解释结果。团队效率是我们的核心目标之一，所以传统的自动化测试就不会为我们工作。我们的方法是这样的：


　　我们的信条是使测试和自动化成为整个团队最关心的问题。每个开发人员都有参与其中。我们的标准项目新员工培训过程包括详细的如何编写文档和运行测试，我们会让开发人员弄清楚，我们期望他们完全拥有自己代码的单元测试、功能测试、性能测试和负载测试。测试、构建和部署团队专注于建立和维护测试工具和基础设施，但这个团队并不自己编写测试——这是个别特殊团队的责任。

　　我们现在能达到一个高度，联盟客户端更新测试失败时团队能快速反应和调查。然而，很难达到这一点。学习如何应对片状测试由始至终都是难题。

　　原来的工作流程是这样的：

　　1、注意到一个测试是偶然性失败；

　　2、只是偶尔失败，所以它可能不如其他坏掉的东西紧要，可以忽略它几个小时或几天；

　　3、最终开始调查，如果测试确实是错了就检查修复。

　　结果就是：团队开始假设，任何失败都可能只是一个片状测试，所有的结果将被忽略。如果团队在测试系统时没有信心，该系统就是一文不值的。如果你的汽车检查引擎灯随机打开时，你可能会开始忽略它。为了防止这种类型的习惯，我们目前的工作流程是立即调查失败的测试，以确定该测试已经跑偏还是我们发现一个合法的bug。

　　将被破坏的测试移动到我们阶段测试套件，是以尽可能高地保持完整测试套件的信噪比。为了测试，阶段套件在正常的构建渠道之外运行。新的或重构的测试被放在某一阶段几天，确保在我们将其放到全套之前它们是健康的，在那里他们可以通知开发人员失败和block部署。

　　我们不断强化通过面对面讨论的方式、发布会议公告的方式、或团队间邮件的方式来保持我们的测试和构建健康的重要性。关于bug或测试的任何讨论都是一个宣传自动化福音的很好的机会(礼貌地)。每一个团队都会定期地进入“必须停船”的心态，然后开始不重视测试的重要性，这是很自然的，有时会为测试要求感到沮丧。当然，我们必须小心地找到没有提醒和太多提醒之间的适当平衡，在这两种极端的情况下，没有人能得到消息。当有远程团队参与其中时这可能需要特别注意。

　　这些文化的态度并不是放之四海而皆准的。他们必须仔细定制以满足各种项目和涉及的人员。最重要的部分是没什么是理所当然的，不做任何假设。总有改进的余地——我们时常留意系统是如何顺利工作的，并适当作出调整。

via：杰微刊【原译文】

相关阅读：揭秘《英雄联盟》的自动化测试

锐亚教育，游戏开发论坛|游戏制作人|游戏策划|游戏开发|独立游戏|游戏产业|游戏研发|游戏运营| unity|unity3d|unity3d官网|unity3d 教程|金融帝国3|8k8k8k|mcafee8.5i|游戏蛮牛|蛮牛 unity|蛮牛