您正在帮助 QA 团队推出新的负载测试工具，以测试在 Google Compute 上运行的主要云服务的可扩展性 带有 Cloud Bigtable 的引擎。
他们应该包括哪三个要求？ （选择三项。）
A.确保负载测试验证 Cloud Bigtable 的性能
B.创建一个单独的 Google Cloud 项目以用于负载测试环境
C.安排负载测试工具定期针对生产环境运行
D.确保您的服务使用的所有第三方系统都能够处理高负载
E.检测生产服务以记录每个事务以供负载测试工具重放
F.通过详细的日志记录和指标收集来检测负载测试工具和目标服务
正确答案：ABF
一些网站建议答案是 BEF。
....我觉得应该是BEF
有人能解释一下上面的内容吗？提前谢谢你
【问题讨论】：
标签： google-cloud-platform load-testing scalability qa
这是一个具有挑战性的问题，将测试您在许多领域的知识。
让我们分析一下这个问题。问什么？
测试主要云服务的可扩展性。
关键点是什么？
负载测试是测试两种类型的系统：Compute Engine（自管理平台）和 Cloud Bigtable（托管服务）。这种区别对于选择好的答案可能很重要。
新的负载测试工具这个短语的用法很有趣。工具是否可靠稳定？验证负载测试工具是目标的一部分吗？问题不清楚。假设不需要测试负载测试工具。
什么是可扩展性的定义？有两种基本类型：静态和自动缩放。推论的问题是哪一个？让我们假设在大小 X 上进行静态意义测试，在大小 Y 上进行测试，等等。
主要云服务的定义是什么？这是否意味着只测试 Compute Engine 和 Cloud Bigtable？大多数实际实施使用的次要服务（Pub/Sub、存储、网络）的影响如何？系统的强度通常受到最薄弱环节的限制。对于这个问题，我们假设次要服务是托管服务，而第三方系统不是等式的一部分。
下一项是用于验证可扩展性的指标。这也没有在问题中定义。让我们假设指标是一个关键项目。
也没有说明测试标准。我们知道正在测试什么，但不知道如何测试。
答案分析
让我们分析每个答案。
A.确保负载测试验证 Cloud Bigtable 的性能
不验证 Cloud Bigtable 的负载测试有什么意义？其中一个关键点是 Compute Engine 和 Cloud Bigtable。但是，衡量单个项目的性能可能不是问题的目标。目标可能是衡量两个系统的综合性能。假设 Cloud Bigtable 是一项可根据需要进行扩展的托管服务，那么衡量其单独的性能并不是要求的一部分。
这可能不是一个好的选择。
B.创建一个单独的 Google Cloud 项目以用于负载测试环境
问题中没有任何地方说明将对生产系统执行负载测试。在生产项目中创建负载测试系统是一个警告标志。
责任分离和权限分离建议为负载测试创建一个单独的项目。除了不授予可能破坏生产系统的权限的好处之外，创建一个单独的项目有助于破坏测试系统，以便可以根据需要重新创建干净的负载测试环境。
这可能是个不错的选择。
C.安排负载测试工具定期针对生产环境运行
针对生产系统定期运行负载测试通常不是一个好主意。您可能会运行一次负载测试来验证系统功能和性能，但通常这是在测试环境中的相同系统上执行的。我会使用生产中的指标来监控生产性能。
这可能不是一个好的选择。
D.确保您的服务使用的所有第三方系统都能够处理高负载
问题的关键是主要云服务的可扩展性。如果您使用第三方服务并假设它们是托管服务，则可能不需要确保它们能够承受高负载。此外，该问题涉及可伸缩性，并未将高负载指定为一项。
这可能不是一个好的选择。
E.检测生产服务以记录每个事务以供负载测试工具重放
这是一个有趣的选项。今天，在开发、测试和部署中实施自动化（机器人）通常是一个明确定义的目标/要求。记录重放交易意味着可以针对各种规模的系统运行可重现的测试。可能存在安全问题，但让我们忽略该选项以进行此选择。
这可能是个不错的选择。
F.通过详细的日志记录和指标收集来检测负载测试工具和目标服务
这个答案的关键是检测负载测试工具AND目标服务。问题是否需要验证新负载测试工具？损坏的工具可能会导致错误的结果。但是，如果我们查看主要问题可扩展性，那么这可能不是必需的。但是，此答案的第二部分 target services 确实符合关键问题。
这可能是个不错的选择。
结果：
如果我们计算出可能的好选择，那么我们就剩下三个好的选择作为最终答案。
【讨论】：