输入正文
| 详情：0579gujia.com |
PART 1
最近阅读了一篇关于自动化测试的前沿论文，颇受启发。这里做一下“搬运工”，把论文内容粗略分享给大家。这是一篇发表在2017 ICSE(IEEE国际软件工程大会)上，题目为《Taming Google-Scale Continuous Testing》，由马里兰大学计算机系学者和Google研究员、工程师共同完成。马里兰大学是全美著名的高校，“公立常春藤”之一，也是Google创始人谢尔盖·布林的母校。Google是一家能将研究(Research)和工程(Engineering)完美结合的伟大公司，在测试自动化领域更是执牛耳者(一年一度的GTAC谷歌测试自动化大会是领域内的旗舰会议之一)。深厚的背景，决定了论文必然出手不凡，单单标题就可谓霸气十足：《驯服谷歌规模的持续测试》。那么，这篇论文(关注公众号，回复数字“1”获取PDF全文)到底研究了什么问题？取得了什么研究成果呢？
持续测试是测试自动化的一个重要应用。什么是持续测试？一般认为，持续测试是一种运行在持续集成(Continuous Integration, CI)系统中的，由开发人员的代码提交所触发的，目的是验证代码改动是否满足质量(Quality)要求的自动化测试。在本公众号之前的文章《Hard Problems in Test Automation》中，我们总结了持续测试的“三高”特性，意图论证：持续测试是一件非常有挑战性的工作。
这种挑战性相当程度上来自于客观上存在的测试资源和测试需求之间的矛盾。测试资源(例如测试工具、测试环境等)是有限的。而在持续测试的情况下，测试需求随着项目规模的扩大而成几何级数增加：大量的开发人员高频率地提交代码，并且希望每次代码提交均得到充分的、不留边角的测试；另外，开发人员对测试时间的需求也很强烈，他们希望快速地得到测试反馈结果，以决定下一步行动。巨大、苛刻的测试需求与有限的测试资源之间必然有着严重的矛盾。确实，在大规模软件项目开发中自动化持续测试往往是一个巨大的瓶颈。
在谷歌，这种矛盾的程度更是史无前例。这是由于谷歌采用“One Single Repository”战略：全公司几乎所有产品线的代码均集中在一个代码库(极少数敏感项目除外)。据统计(数据来自论文《Why Google Stores Bilions of Lines of Code in a Single Repository》，发表在著名期刊Communications of the ACM上)，在2015年1月份，关于这个代码库的数据是：
| cqaokesiweixiu.com |
总文件大小86TB(不包括release分支)，
总共有900万个源文件，
总共有20亿行源代码，
历史以来一共产生3500万次提交，
平均每个工作日产生40000次有效提交，
总共25000名开发人员工作在这个代码库上。
| cqtclweixiu.com |
这真是一个“航空母舰”级的软件项目，是否前无古人，后无来者？它对持续测试的需求之高简直不可想象。对此，杰出的谷歌工程师们广泛使用了各种自动化测试先进技术。例如，使用回归测试集选择技术，在每次代码提交时，并不去执行全部测试集，而是根据测试用例和被修改文件的依赖性关系，只从回归测试集中选择一部分可能受到影响的用例执行。即使这样，由于代码库极端庞大，最坏情况下修改某一个文件需要执行420万个测试用例。即使在顶级的硬件环境下使用分布式并发执行技术，仍然需要9个小时才能获得测试结果。
即使“最厉害的人” + “最好的资源” + “最先进的技术”，持续测试依然是开发流程中的瓶颈。怎么办？还有哪里可以改进？