Google 软件测试之道 (2)

Posted on Wed, 25 Dec 2024 10:37:24 +0800 by LiangMingJian

版本划分 #

Google经常在最初的版本里只包含最基本的可用功能，然后在后继的快速迭代的过程中得到内部和外部用户的反馈，而且在每次迭代的过程中都非常注重质量。一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta或正式发布版本。

Google发布的过程虽然快，但也并不像想象中如牛仔一般的鲁莽与仓促。实际上，为了发布我们称之为beta的版本，一个产品要经历一系列的内部版本验证，用以证明它已经具备了一定的质量。

• 金丝雀版本：这是每日都要构建的版本，用来排除过滤一些明显不适宜的版本。就像煤矿井里的金丝雀（译注：17世纪，英国人将金丝雀放到煤矿井里检测井中空气质量。如果金丝雀死了，则表示矿井中的空气已达到令人中毒的水平。此处意为对一件事情的预警），如果构建失败了的话，意味着我们的流程可能在哪里出了问题，需要去复查一遍我们的工作。使用金丝雀版本需要极强的容忍度，而且在这个版本下可能无法使用应有的基本功能。一般来说，只有这个产品的工程师（开发或测试人员）和管理人员才会安装使用金丝雀版本。
• 开发版本：这是开发人员日常使用的版本，一般是每周发布一个。该版本具有一定的功能并通过了一系列的测试（我们将会在随后的章节里讨论这点）。所有这个产品下的工程师都会被要求去安装这个版本，并在日常工作中真正使用它，这样可以持续对这个版本进行测试。如果一个开发版本不能够满足日常真实工作的需求，那么它将会被打回为金丝雀版本。发生这种情况不但令人郁闷，工程团队也需要再花费大量的时间去重新评估。
• 测试版本：这是一个通过了持续测试的版本。这个版本基本上是最近一个月里的最佳版本了，也是工程师在日常工作中使用的最稳定最信任的一个版本。测试版本可以被挑选作为内部尝鲜（译注：dog food）版本，如果该版本有比较持续的优良表现，也是作为beta测试的候选版本。一些情况下，如果测试版本在公司内部使用得足够稳定，一些想更早尝试这个产品的外部合作伙伴也会使用这个版本。
• beta或发布版本：这个版本是由非常稳定的测试版本演变而来，并经历了内部使用和通过所有质量考核的一个版本，也是对外发布的第一个版本。

测试类型 #

Google并没有使用代码测试、集成测试、系统测试等这些命名方式，而是使用小型测试、中型测试、大型测试这样的称谓（不要和敏捷社区发的那些T恤型号混为一谈），着重强调测试的范畴规模而非形式。小型测试意味着涵盖较少量的代码，其他的测试类型以此类推。Google的三类工程师都会去执行其中的任何一种测试，无论是自动化的还是手动的。测试的规模越小，就越有可能被实现成为自动化的测试。

小型测试 #

一般来说（但也并非所有）都是自动化实现的，用于验证一个单独函数或独立功能模块的代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差一错误等方面的验证。小型测试的运行时间一般比较短，通常是在几秒或更短的时间内就可以运行完毕。通常，小型测试是由SWE来实现，也会有少量的SET参与，TE几乎不参与小型测试。小型测试一般需要使用mock和fake（译注：mock fake环境是实际依赖系统的替代者，会提供相应的功能，但这些系统可能不存在，或者缺陷太多不可靠，或者是一些很难模拟的错误条件）才能运行。TE几乎不编写小型测试代码，但会参与运行这些测试，来诊断一些特定错误。小型测试主要尝试解决的问题是"这些代码是否按照预期的方式运行"。

中型测试 #

通常也都是自动化实现的。该测试一般会涉及两个或两个以上，甚至更多模块之间的交互。测试重点在于验证这些"功能近邻区"之间的交互，以及彼此调用时的功能是否正确（我们称功能交互区域为"功能近邻区"）。在产品早期开发过程中，在独立模块功能被开发完毕之后，SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试和维护这些测试。如果一个中型测试运行失败，SWE会自觉地去查看分析原因。在开发过程的后期，TE会通过手动的方式（如果比较难去实现自动化或实现的代价较大时），或者自动化地执行这些用例。中型测试尝试去解决的问题是，一系列临近的模块互相交互的时候，是否如我们预期的那样工作。

大型测试 #

涵盖三个或以上（通常更多）的功能模块，使用真实用户使用场景和实际用户数据，一般可能需要消耗数个小时或更长的时间才能运行完成。大型测试关注的是所有模块的集成，但更倾向于结果驱动，验证软件是否满足最终用户的需求。所有的三种工程师角色都会参与到大型测试之中，或是通过自动化测试，或是探索式测试。大型测试尝试去解决的问题是，这个产品操作运行方式是否和用户的期望相同，并产生预期的结果。这种端到端的使用场景以及在整体产品或服务之上的操作行为，即是大型测试关注的重点。

小型测试涵盖单一的代码段，一般运行在完全虚假实现（fake）的环境里。中型测试涵盖多个模块且重点关注在模块之间的交互上，一般运行在虚假实现（fake）环境或真实环境中。大型测试涵盖任意多个模块，一般运行在真实的环境中，并使用真正的用户数据与资源。

自动化测试和手动测试 #

最后，关于自动化测试和手动测试的比例，对于所有的三种类型测试，当然更倾向于前者。如果能够自动化，并不需要人脑的智睿与直觉来判断，那就应该以自动化的方式实现。但在一些情况下需要人类智慧的判断，如用户界面是否漂亮、保留的数据是否包含隐私等方面，这些还是需要手动测试来完成。

正如上文中提到的，同时也是值得重点关注的一点，Google也有大量的手动测试，有些使用脚本的方式在记录（译注：scripted ，脚本的方式，通过把每一个步骤都记录下来的方式表示用例的内容），而另外一些使用探索式的方法，这些测试都在被密切地关注，以后可能被自动化方式所替代。通过使用定位点击的验证方式、录制技术等可以把一些手动测试转变成自动化测试，这些自动化测试在每次建立之后都会重复地回归运行，而手动测试更倾向于关注于新功能。我们甚至把开bug和日常的手动工作都自动化实现了，例如，如果自动化用例运行失败，系统会自动检查到最后一次代码变更的内容，这些变更极有可能是造成失败的罪魁祸首。系统会自动给代码变更的提交者发送一封邮件，并新开一个bug来记录这个问题。 将自动化推至"最后一英寸人类的智慧"是Google 正在构建的下一代测试工具的设计目标。