计算机娱乐供应商协会开发者大会，简称CEDEC，是目前日本最大的面向游戏开发者的行业大会之一。就在在前段时间举办的 CEDEC 2023 上，开展了一场主题为「测试工程师告诉你：测试前应该思考些什么」的讲座。

这场讲座中提到了一个观点：如果能在软件正式开发之前，就针对必要的测试进行一些讨论的话，能够有效降低开发的成本和工作量。

聊起软件测试，我们通常会认为测试是在软件开发完之后再进行的，那么，前面提到的「需要在开发之前就开始的测试」，指的到底是怎么的测试呢？

本次讲座的演讲者是来自 10X 公司 B-Testing QA 团队的风间裕也先生。除了团队成员的身份之外，风间先生同时也是 JaSST Review 和青年测试工程师研究小组 WACATE 的主席。

在开始前，风间先生表示，本次演讲的主题并非传统的游戏QA，更多的是关于「系统测试应当如何进行以及如何降低其成本」。

当然，这并不代表本次演讲会与游戏完全无关。一般来说，游戏测试大致可分为两大类：即「测试游戏的世界观是否有被正确地传达」和「测试系统是否能够正常运行」。

如果能降低系统测试相关的成本，对游戏整体的成本控制自然也会有积极的影响。因此，本次演讲的重点更多将会放在「系统测试的成本控制」这一点上。

当我们谈到软件测试，一般都会联想到诸如「测试者与QA团队的职能」或者「应该如何编写测试代码」之类的话题。却很少有人会思考软件开发者的在测试中的作用。

因此，风间先生表示，本次演讲想要第一个重点探讨的问题就是：在软件测试期间，开发者应当做些什么？

对于这个问题，风间先生提出了第一个观点：比起等软件开发完成后再交给 QA 团队去进行测试，如果能让软件开发者也加入并进行事前测试的话，可以有效控制成本，整个开发流程也将变得更加顺畅。

顺带一提，这个定义也印证了业内常说的「测试七原则」之一，即测试只能指出软件中缺陷的存在，而不能指出造成缺陷的原因。

而在上述提到的目的中，风间先生特别强调了「防止缺陷的产生」这一点。他表示，如果能在编程阶段开始之前就发现软件中可能存在的问题，那么修正的成本就会降到最低。发现的阶段越早，成本越低。

为了方便大家理解修正成本究竟能降低多少，风间先生提出了一个假设。如果将在需求阶段发现错误并修正的成本设定为 1 的话，设计阶段的修正成本就会变为 5，实施（编程）阶段变为 10，发布阶段甚至会变为 200…随着项目阶段的推进，修正的成本也会迅速增长。

此外，在更晚的阶段发现并修正 bug 不仅意味着成本的提升，如果在软件在发布阶段后才进行修正，还可能会导致企业信誉方面的损失，可谓是百害而无一利。

那么。既然预防缺陷的产生能够有效控制成本的话，开发者的参与到底能对预防起到什么样的帮助作用呢？

为了帮助大家更直观地理解，风间先生首先向观众提出了一个问题。

题干：

现在要设计一个密码输入界面，密码字数要在4~12字之间，3分钟内输入密码错误4次以上的话，账号会锁定5分钟。

问题：

1. 请提出测试的内容

2. 比较在意的点（对题干有疑惑的点）

3.  写下可能会产生的 bug

对于这个问题，观众给出了五花八门的回答。有人提到了要对密码的文字数、所包含的字符种类进行测试，也有人表示需对密码填写空白时的反应进行测试等等。这些回答的着眼点广泛，思考的维度也十分丰富。

而上述这些回答仅仅代表了一部分测试人员的想法，如果让开发人员也参与进来的话，是否能够从另一个视角获得更多元的回答呢？

让开发者参与事前测试的目的之一，便是为他们提供一个能让与其他开发者和测试者共同交流的平台。

为了阐释这种事前沟通的重要性，风间先生举了一个例子。假设我们正在设计一个需要用户输入密码的界面。

如果不进行事前测试的话，则可能会出现以下问题：

负责按键功能设计的开发者 A 可能会认为「输入密码错误后显示的跳错页面」属于页面设计的范畴，应当会由负责页面设计的 B 来负责完成。

而负责页面设计的 B 可能会认为「跳错页面」应当属于按键功能设计的衍生范畴，应当会由负责按键功能设计的 A 来负责完成。

于是乎，最终可能会导致的情况便是，大家都认为这是属于对方的工作，而软件就这样在有所欠缺的情况下被完成了，事后才作为「跳错页面缺失」的问题被 QA 团队抓出来作为 bug 上报，进而回炉修改，大大影响了开发效率。

而这类问题，是能够通过沟通来大幅降低出现概率的。让开发者参与事前测试，一方面是希望借这个机会让开发者从他们的视角提出开发中存在的隐患，另一方面也是希望为他们提供一个事前沟通的平台，解决一些类似责任划分的问题。在真正意义上做到「防患于未然」。

通过前半段的演讲，我们已经大致了解了事前测试的重要性以及开发者参与的必要性。那么，究竟在事前测试中具体要做些什么才能实现提效降本呢？我们将在本文的后篇中为大家带来风间先生的回答。