Get best of the week

预订“如何在Google上进行测试”-免费电子版

图片您好，habrozhiteli！

本书介绍了在Google测试软件产品的过程：流程的组织方式，团队的组织方式，使用的技术以及对质量负责的人。Google测试所依据的原则适用于任何规模的项目和公司。该书的作者自己研究了Google产品，创建了测试工具，自定义了流程并直接进行了测试。

本书面向软件开发行业的专业人员：测试专家，程序员，管理人员。

摘抄。降低风险


完全消除风险的可能性很小。我们开车，虽然很危险，但是我们需要上班吗？通常，发生事故的可能性并不意味着会发生，并且很可能不会发生任何可怕的事情。为什么？因为通过我们的行动，我们减少了可能的风险。例如，我们在醉酒时不开车，也不在能见度不足的情况下开车。因此，我们降低了风险。

在软件产品开发中，最简单的方法是避开风险区域：代码越少，风险就越小。但是除了使用“ ax and axe”，我们还可以做更多的事情来降低风险：

  • , , .
  • -, , .
  • , .
  • .
  • , . , .

具体解决方案取决于应用程序的功能，取决于用户对其安全性和可靠性的期望。作为测试人员，我们当然可以参与降低风险的过程，但是我们当然也参与了确定风险的过程。我们首先确定表中红色标记的功能的优先级。我们要进行测试以降低风险。这很重要：如果您无法测试所有内容，请先测试最重要的内容。最重要的是，它最容易遭受最严重的风险。

在某些项目中，测试人员会询问产品是否准备发布。优秀的测试人员只需看一眼热图就可以确定它是否仍然值得在烤箱中保存，还是该将其放在桌子上了。如果我们正在谈论启动一个试验性的Google实验室，那么红色风险区的存在并不是那么重要，当然，如果它们与安全性无关。如果这是Gmail的新版本发布，那么即使黄色区域也将构成严重危险。这样简单的颜色渐变对每个人，甚至高层管理人员都是显而易见的。

随着时间的流逝，对风险的担忧逐渐消退，大量成功的测试表明风险处于可接受的水平。在这里，我们受益于将测试用例链接到单个产品功能，然后链接到风险表中的属性和组件。“ ACC分析”非常适合这种情况，这就是我们如此创建此工具的原因。

詹姆斯·惠特克处方测试计划（十分钟）


, , . , , — ? , , . Google, , -. , , : «», « » — « » ( ). ’, , - , .

— . -, , — , , ( ), , , . : , ,
?

- , , , . , — . : ?

- , - . . : -.

, : - . - , .

, . : . , , .
-, .

. : « , - ». , , . , , , , .

, , , (Google Docs, App Engine, Talk Video . .), .

, ACC-. , . — , — . , . - — . , , .

’, - . . ,
- .

, . , . 80% . ? , , ? , (, , ) . , , .

. -!


Google Test Analytics将上述风险评估标准（“非常罕见”，“很少”，“有时”，“经常”）作为基础。我们特别不想将风险分析变成一项艰巨的任务，否则将无法完成。我们对确切的数学细节不感兴趣，因为数字意义不大。只需知道“ A”比“ B”更具风险，而不必注意风险的确切含义就足够了。简单地了解哪个机会比另一个风险更大，就可以使测试经理更有效地分配测试人员的工作。而且像Patrick Copeland这样的人可以轻松决定要分配给每个开发团队的测试人员人数。了解风险将使整个公司受益。

风险分析是许多行业都尊重的独立科学领域。我们使用该方法的简化版本，但这并不妨碍我们对新研究产生兴趣，以改进我们的测试方法。如果您想了解有关风险分析的更多信息，请从Wikipedia上的文章“风险管理”开始。

GTA有助于识别风险，而测试有助于降低风险。测试人员在此过程中充当中介。他可以在某些风险最大的区域中执行内部测试，也可以在任务开发人员和测试人员中进行测试，以便他们添加回归测试。他的工具库中还有其他工具：研究测试，吸引内部和Beta用户以及外部社区的力量。

测试人员有责任了解所有危险区域。他应尝试以任何可能的方式降低风险。以下是一些我们认为对处理风险有用的建议。

  1. 对于用红色标记的最具风险的功能和属性/组件对，请编写一组用户案例，使用场景或测试指南。在Google，测试人员应承担最危险的机会。他可以与同事协调工作，使用不同的工具，但个人责任仍在他身上。
  2. , . , GTA? ? ? . , , .
  3. , / , , . .
  4. — . , . , . , : «!», . , .
  5. , . , , . , « ?» « ?». Google , , .
  6. 6 , , , . ! .




, . , , , .

, , - . - , , , . , , . , , .

, , . -, - — !

— . - . — . Google , . -: Google Documents — , .

, , , . — .

低风险的机会我们不会太过错。我们可能会决定为这些区域编写测试用例过于昂贵。相反，我们可以将自己局限于研究测试或众包测试。为了管理外部社区的测试人员的工作，我们经常使用游览的概念-这些是研究测试的高级说明。简而言之，此方法可为您的请求提供所需的详细信息。例如，向社区询问：“进行联邦快递的一系列功能介绍”-我们将获得比仅提供应用程序并期待最好的效果更好的结果。我们会立即确定需要测试的功能，并提供有关如何执行此操作的说明。

众包




— . , , - ! , . . ?

, , . , , — , , -. , Chromium, . , , . , .

( ) — . , , . , , ? — .

, , , . , : -1000 , : Chrome, : 1 = 1000 20 = 50 . .

, , , . , , . Chrome, , , ( « Chrome»). . , . « , » , .

- — Google: , , . , . , , , (, uTest). .

因此，ACC分析的优势在于，我们获得了可以按风险分类并分配给不同执行者的产品功能列表。在同一个项目上工作的测试人员可能会收到不同的测试功能集。内部用户，“百分之二十”的参与者，测试人员，社区测试人员，开发人员，正在测试的开发人员都将收到其功能列表，并且让测试人员感到高兴的是，与我们简单地将应用程序分发给应用程序相比，重要区域的覆盖面要小得多测试给大家。

与开发人员进行测试相反，测试人员的工作并未随产品的插入而终止。

» 下载epub和pdf

More articles:


All Articles