当一个测试运行完，它将测试的结果提供给一个独立的报告服务，那里存储了过去六个月的运行数据。基于测试数据，这个服务采取不同的行动。一个本地运行的测试会在测试执行的机器上打开一个web页面，包括通过的与失败的测试用例的详情。如果在测试场运行，当有任何测试用例失败的时候，系统会自动根据测试结果创建bug标签及issue等，并给提交者发送邮件。测试数据也会通过报告服务聚合及跟踪，使我们可以知道什么情况下测试不通过，以及失败的频率，还有bug存在多久了。
在Wood 5级的比赛中我们不使用守卫，因此在我看来这个严重故障也没什么问题
出于防止古怪及不可靠测试的目的，每个测试都必须经过一个标准的流程来保证可信。当一个测试经过了代码审查并提交，它加入一个测试集合叫做BVSStaging。在那里测试在提交运行前必须稳定运行至少一周。如果在Staging中的测试失败了，只会通知测试的开发者，来避免困惑。
当一个测试被证明可靠后，它被提交进两个集合中的一个。第一个集合，BVSBlocker，包括的测试指出该构建是否值得进一步测试。如果一个构建在Blocker集合测试不通过是不会部署到测试环境的，因为游戏不能开始，或者有好几个会导致服务端崩溃的bug影响游戏。相对的，BVS Core，使我们功能测试的核心集合，包括对每个英雄技能的测试。
框架深度游览
BVS分三个层面实现：执行器，驱动及脚本。执行器为功能测试实现了一套通用的API，驱动实现的一个测试的配置与执行的具体步骤。最后，脚本实现测试用例的具体逻辑。当下，我们只有一个驱动在使用（LOL游戏），但是执行器与驱动分离的设计意味着在将来的项目里可以通过实现各自的驱动来使用BVS系统，而且可以共享使用LOL的驱动编写时编写的工具。
由于一些原因，我不能对流程图要求更多...
个别的组件注册了他们必选和可选的参数，作为它们声明的一部分。当命令行提供了参数，参数被作为字典存储下来，然后组件会在初始化时处理这些参数。BVS早期的版本使用Python标准的argparse库，但是出于两个原因，我们选择放弃argparse库：第一，潜在参数的数量变得非常巨大，通过系统跟踪变得非常困难；第二，驱动需要有一些驱动特有的参数，这意味着在启动时声明一个解析器是不可行的。
classTestFactory(API.TestFactoryAPI):requiredArgs = [ArgsObject('driver','Driver you wish to use'), ArgsObject('name','Name of the test to run')] optionalArgs = [ArgsObject('overrideConfig','Use a non-standard game.cfg',None), ArgsObject('gameMetadataConfiguration','A string identifying which game metadata to use',None), ArgsObject('listener','Log listener to use',None), ArgsObject('mutator','A string name for mutator to apply to test object',None), ArgsObject('testInfoID','Test and metadata this test run is related to',None), ArgsObject('testSubsetNumber','The number out of total if test is subsectable',None), ArgsObject('totalSubsetNumber','The total numbers of subsets test is split into',None)] |
一个驱动对象的样例参数
相关的尺度共分为三个等级：测试集合，测试，测试用例。
1、测试集合 是同时运行的一组测试。例如，之前提到的BVSBlocker 测试集合就是运行在CI上的一组冒烟测试。测试集合现在通过JSON文件的方式描述给BVS，可以在VCS或On-The-Fly中创建。
2、测试 是单独的类实现了一组相似测试用例，使用相同的基础游戏的配置。例如，LoadChampsAndSkins测试包含了加载各个英雄的资源、皮肤以及确认加载正确的测试用例。
3、测试用例? are是一个测试中对期望功能测试一个单一单位。例如LoadChampsAndSkins中的loadChampionAndSkin方法就是一个单独的测试用例，为了覆盖所有英雄和皮肤的组合要执行数百遍。上文提到的Kog’Maw整个测试用例被一个更高级别的测试执行，这个测试允许更复杂的测试用例使用比一个函数更复杂的结构。
BVS并行化通常是在测试集合这一层实现的，但是也可以在测试这一层实现。由于BVS通过JSON存储和读取测试集合，因此我们可以在JSON中创建一个子列表，这样既可以被单个执行器顺序执行，也可以在测试场中并行执行。早期的BVS系统中，这个操作是允许我们手工进行平衡的，当测试列表比较小时候，这个比自动化的并行更有效。由于主要测试集合的增长，我们切换到了一个自动化的负载平衡工具来产出这个JSON文件，依据每个测试的之前10次的平均运行时间来进行调整。
BVS的大多数用户只跟测试本身打交道，因为我们通过自己的方式来保证测试人员不需要考虑驱动处理的细节。同时，我们用一个非常大的标准类库来封装RPC的端点，用于与游戏交互。部分原因是为了防止测试与RPC接口过紧的耦合，但主要原因是为了提供一组标准的行为，来防止草率的编写测试，进而保证测试之间的一致性。
特别的BVS的标准测试类库不支持纯粹的sleep。早期的测试编写者，大量使用sleep，导致一大批脆弱的测试在他们各自执行的硬件上表现完全不同。所有标准类库中的等待操作都是条件等待，都是在等待游戏中一个特定的条件。
@annotate("Wait until a unit drops the specified buff.",arguments=[argument("unitNameOrID","Unit name (or unique integer unit ID).", (str, int)), argument("buff","Buff you want to drop.", str), argument("timeout","How long to wait.", float, default=STANDARD_TIMEOUT), argument("interval","How often to check for a change.", float, default=SERVER_TICK), argument('speedUp','Whether to speed the game up.', bool, default=False)], tags=["wait","buff","change"])defwaitForBuffLost(self, unitNameOrID, buff, timeout=STANDARD_TIMEOUT, interval=SERVER_TICK, speedUp=False):conditionFunction =lambda:notself.hasBuff(unitNameOrID, buff)returnself.__waitForCondition(conditionFunction, timeout=timeout, interval=interval, speedUp=speedUp) |
另一个我们对BVS做的重要的适应是由于早期分离出了除了了运行测试之外的所有逻辑。过去BVS决定使用什么设备，标记构建通过还是失败，以及排版测试报告。为了保持一个职责的清晰划分，我们分离出了一个服务来处理与运行测试并不直接相关的所有内容。这个服务是一个 Django应用，使用 Django REST 框架 来提供了一组API供BVS及其它服务使用。
运行及预运行流程(点击放大)
总体性能
总的来说，BVS对每个英雄联盟的新构建会在大约18分钟的时间里运行大约5500个测试用例。一天总共运行大约10万个测试用例。从一个缺陷提交到BVS的第一份失败报告之间的平均时间大概是一到两个小时。50%的critical及blocker级别的bug都是BVS系统发现的，其余的通过内部QA或者PBE发现。没有被BVS发现的问题通常是由于测试覆盖不足的问题，而不是因为差的测试编写。
虽然我们发现的大多数Bug都输入功能缺失或游戏崩溃的领域，偶尔我们也会成为一些真正优秀的bug的第一发现者。我个人的得意之作发现一个缺陷：游戏中所有的塔都缓慢移向地图的右上角，结果紫色基地的圣塔附近就出现了交通拥堵。我们的发现也包括一些非自动化测试可能无法发现的东西，比如曾经有个问题是点射技能可能会穿过一个敌人，如果英雄恰好攻击了敌人空白点的范围。
总体来说，自动化测试代替手工测试并不是必要的，但是它帮助我们加快了开发的反馈循环而且解放了更多的手动测试人员使他们可以关注更有害的问题的测试。随着英雄联盟内容的增加，我们持续增加更多的覆盖，这样可以提高我们的对缺陷的命中率，也让我们对构建的健康程度更有信心。
谢谢你花时间来阅读这篇文章，如果有问题可以在评论中直接提问。我们下一篇关于自动化测试的文章中将会讨论测试的吞吐量及返回的速度。
