《精通自动化测试框架设计》—第1章 1.1节奥运年的新挑战

本节书摘来自异步社区《精通自动化测试框架设计》一书中的第1章，第1.1节奥运年的新挑战，作者陈冬严 , 邵杰明 , 王东刚 , 蒋涛，更多章节内容可以访问云栖社区“异步社区”公众号查看。

你多吃点饭，到东吴的路很长，很费体力。

——《赤壁》

第1部分 构建ui自动化框架

在本书的这一部分，将介绍数据管理、底层公共框架构建等主题，并借助testlink web ui自动化测试框架构建的实践案例来展示如何从底层框架开始，搭建一个具有良好可维护性以及后续可扩展性的web ui自动化框架。

1.1 奥运年的新挑战

2008年的夏天是一个举国欢腾的日子。an君在办公室里正对着“厨房三件套”的office开始一段全新的奇妙旅程。

an君加入的团队是p公司上海研发中心组建的第一个所谓种子团队（seeded team）。上班第一天所看到的是略显空荡荡的办公室，以及拥有同样兴奋心情的其他团队成员。团队里绝大部分人拥有硕士学位，5年左右的相关行业软件测试工作经验。他们面对的产品是一个已经有十多年历史，服务于上万家企业客户的行业标杆级产品。开发工程团队分布在全球各地、高度分工，且这个千人团队正酝酿着敏捷转型。

这个团队接手的第一个项目叫做bco。

1.1.1 bco是什么

这几乎也是每个新成员问的第一个问题。bco是build checkout（版本签出）的简称。bco测试团队负责检查和验证集成团队发布的每个build是否通过既定的质量标准，并将通过测试的build对组织进行发布。这一过程将在某一发布（release）的第一个build开始，直到rtm（release to manufacture）build结束。

bco针对每一个build的测试周期是5个工作日，从接到集成团队的email通知开始，到全部bco缺陷修复且验证通过、发出build release的email为止。之所以是5个工作日，是因为这个一千人的产品开发组织按照每周一个build的节奏进行组织级版本构建。

1.1.2 为什么需要bco

bco的出现是为了解决一个庞大软件开发组织的版本集成的问题。经过多年的实践摸索，该组织建立起了如图1.1所示的多阶段持续集成模式。而bco是该模式中的一环，是背后庞杂的产品开发流程中简单而又非常关键的一环。

所谓多阶段持续集成，可以参考damon poole于2008年所发表的文章[1]。这个模式与这个组织的团队结构是吻合的。在采用了scrum之后，开发团队按照产品的功能和专业职能，划分成了约60个scrum team。这些团队又根据特性与模块间的相似性，以及产品组合间的市场接受程度，聚合成了大约15个integrated scrum team，也就是所谓的集成scrum团队。这种模式也被称为scrum of scrum。这个组织的多阶段持续集成是按照如下的模式运行的。

（1）每周中央集成库签入与签出—每个scrum team的配置管理员维护自身团队的代码库。每周初，从中央集成库中更新同步最新发布的代码基线。每周末，将团队代码库中通过集成的代码签入中央集成库。

（2）团队每日集成—每天由团队的配置管理员进行该团队的版本集成，接受团队成员签入的新代码。

（3）个人每日集成—scrum团队成员每日在团队代码库中进行签入和签出，并随时在私有代码库上进行私有构建。

（4）对于系统测试团队和本地化、市场等其他团队而言，只使用（1）中由集成团队构建的版本进行测试。

这套流程能顺利运转的关键一环是发生在组织级构建与系统测试之间的bco测试。从图1.1中组织级构建与不同版本bco之间的双向箭头也可以看出，开发团队所使用的也是经过bco验证的build。

1.1.3 测试任务与测试内容

bco测试的主要任务是在集成团队发布了版本之后，进行bco测试与版本发布。该级别的测试主要完成以下内容。

（1）安装测试：在既定的操作系统、数据库、ldap服务器产品和其他第三方产品上安装既定的解决方案。通常，出于安装测试和后续测试的需要，一般要安装若干套系统。当然，相对于专门的安装测试团队所实施的几十个场景的安装测试来说，bco 只涉及其中极其有限的场景。

（2）schema比较测试：对于使用了数据库的企业级系统来说，数据库以及其中的数据定义的一致性是非常关键的。在bco测试中，针对本次build、本次build的前一个build、前一次修订发布（maintenance）和前一次整体发布（feature）的oracle schema 分别进行比较。

（3）api测试：大约有1500条来自开发团队的api测试用例需要执行。

（4）dev/qa check：根据开发进程的不同，测试将分为dev check（约200条ui用例）及qa check（约400条ui用例，包含dev check）。

（5）产品集成测试：该产品与公司其他上游产品的交互集成，约200条用例，需要一些行业及上游产品的使用技能。

（6）最终版本验证与发布：在所有该build上发现的bco缺陷全部修复后，集成团队将进行该build的重新编译集成。在此基础上，bco团队将运行前述所有用例，验证所有缺陷。如果一切顺利，就进行build release。

从上述内容得知，这个团队不负责具体的系统模块，却涉及几乎全部的系统模块。他们的ui用例大约占整个测试组织全部用例的1%。

1.1.4 利益干系人

划分利益干系人是建设一个新团队必须要做的事情。对于bco来说，其划分大致是这样的。

（1）bco团队成员，位于上海，负责该项目的执行。

（2）bco团队主管，上海与北美，接力把控项目的整体进度与质量。

（3）integration team集成团队：负责各产品版本的每周构建。bco是他们的客户之一，为后者提供build以及bco patch。

（4）qa：系统测试团队，内部客户以及国庆、春节黄金周期间的替补。bco测试用例的评审者。

（5）dev：开发团队，内部客户，bco缺陷修复者以及bco测试用例的评审者。

（6）installation and upgrade dev：同dev，专注于安装以及升级相关领域的开发团队。

（7）po：产品经理，triage（缺陷分类）时的参与者及bco测试用例的评审者。

（8）release management：发布管理团队，产品及build发布计划的制定者、内部客户、bco board成员。

（9）bco board：包括所有测试和开发的经理和总监，bco流程的拥有者，审核bco用例变更以及版本丢弃等重大事项。

（10）bco-all：一个邮件组，所有与bco的产出物相关的邮件需要抄送该邮件组。几乎所有上述人员均在该邮件组内。

可以看出来bco是一个纯服务于产品工程团队的内部团队。

1.1.5 pink mail、escalation和sprtracker

这是an君最喜欢的部分。pink mail是内部对于bco break mail（缺陷通知邮件）的昵称。每当bco团队成员在执行测试用例中发现了问题并经过团队负责人的确认，就可以直接在缺陷管理系统中新增一个带有bco标签的缺陷，并且这个缺陷基本上就是blocking（阻塞）的严重级别，这是其他普通系统测试人员所不具有的特权。

这还不够，作为信息传递与沟通的主要方式，bco成员还要在系统中发出一封以粉红色为背景的email。email中包括常规的缺陷信息，以及对于所有后续流程的提示，还要抄送给缺陷负责人的直接上级以及bco-all。在an当年访问其他研发中心时，曾有同事打趣说，他每天到公司的第一件事情，就是看一下有没有属于他的pink mail。如果没有，很庆幸，可以继续正常干活了。

按照bco的规程，一个bco缺陷如果在规定的时间内（如36小时）没有有效响应，就可以向修复者的上级（经理或者总监）进行escalation，然后就会触发后续的沟通协调与更频繁的修复进度状态跟踪。基本上没有人愿意接到escalation。

email的沟通还是有些不够及时和醒目，最终团队成员ken做出了他们的熔岩灯（lava lamp），一个web版本的缺陷计时器来作为可视化的版本状态提醒工具。这个取名叫做sprtracker 的工具，会以 10 分钟每次的频率去扫描缺陷库，遴选出属于在建发布的所有带有 bco 标签的未修复缺陷，列出修复者的大名，缺陷开出的时间，以及一个距离escalation 还有多少小时的沙漏计时器。大家都喜欢这个工具，它还被要求做成了一个rss（really simple syndication）源，成了很多人使用的公司内网首页的一个组件。

1.1.6 沟通，还是沟通

做到这里，还是不够。bco团队每天会将所有上述工作写成一个进度报告，发布给bco-all。此外，还有每日的上海/北美bco主管会议，主要沟通存在的问题与需要交棒的工作内容。在每周一次、全部测试经理和产品经理都要参加、由测试副总主持的全产品线测试沟通会议上，bco团队的进展报告通常都是第一个议题。按照测试副总的说法，bco团队的每个人都是名人。