[Cucumber & Cheese 中文版]1. 让我们开始吧

1. 让我们开始吧

Cucumber^[2]是一种便于用通俗语言（包括英语和其他超过40种的语言^[3]）描述应用系统需求并将这些需求转换为自动化功能测试的工具。在为应用系统创建功能测试时，它能使测试更加易读、易理解、易协作，并使我们的工作方式和软件交付质量具有重大变革和改进的潜力。

为了理解这种潜在的深远意义，我想先从当前典型软件测试方法面临的挑战开始谈起。后续章节中的一些内容则取自一种敏捷观点。如果你不幸还未以这种观点阐述的方式工作，那么我觉得你大可尝试在自己的环境中应用它们，并看看是否有效。

我们的软件测试方法有问题吗？

软件测试行业正处在一个转变的阶段。我们以往的软件测试方法已被证明效率低下且作用有限。效率低下的原因是我们遵从的许多实践已经不能适应软件不断增长的规模和复杂度，而且在我们的过程和流程中存在大量因较迟发现缺陷带来返工而导致的资源浪费^[4]。作用有限的原因是开发团队尽力按时交付的软件质量仍然较低，且包含大量缺陷。

大约11年前，一个私人团体发表了《敏捷软件开发宣言》^[5]。他们耗费多年用于尝试如何使团队以更具预见性的方式来协作创造出更高质量的软件产品。在“敏捷运动”^[6]较早期，软件开发和管理角色更受关注。而来自传统测试背景的人员在开发过程中的参与并未得到重视。

正因为对软件测试角色的关注如此之少，许多团队在敏捷工作模式中声称他们并不需要测试人员。而其他一些团队虽然独立引入了测试人员，但仍然让他们以传统方法来测试软件。这两种情况都带来了很多问题，这些问题我们将在这一章中进行讨论。

使用偏传统（例如waterfall^[7]，RUP^[8]）或更通用的迭代^[9]方法工作的团队，在开发软件时通常需要等待开发阶段完成之后才开始软件测试阶段。这种方式在缺陷修复或交付计划变更时会导致大量返工。

以下部分罗列了一些我们在以相当传统的方法来测试软件的团队中经常会遇见的问题。

一个乒乓游戏

大部分软件开发结束时都会将工作从开发人员移交给测试人员。开发人员完成了一些功能，而测试人员需要确认这些功能是否正确。在非敏捷的开发模式下，开发人员需要为这次移交编码几周乃至几个月。而在敏�峭哦又校�此类转移在每个预计花费一两天编码的故事结束时就会发生。这些流程看起来都很合理，那么你再看看图片，是否可能会有问题？

当测试人员在应用系统中发现缺陷时问题也来了。一些意想不到的活动随着缺陷被找到而开始发生。

1. 测试人员最先做的事情通常是在他们的跟踪系统中记录缺陷，记录需要足够详细以便开发人员在晚些时候可以重现。足够详细还意味着大部分时候它还包含缺陷发生时的准确数据。

2. 他们往往会中止在缺陷发生部分的相关测试计划，转而关注应用的其他部分。我们一般不认为应该在发生缺陷的位置继续执行工作流。因为我们无法保证缺陷不会影响后续的应用行为。同样，我们也知道这部分代码（在修复问题时）会被修改，所以之后仍然需要运行所有的测试用例。

3. 很多组织都有如此多的缺陷以致需要安排专人优先处理，并且他们还得决定何时将这些修复工作插入到忙碌的进度计划中。低优先级缺陷会被推迟到较晚时间修正。这使得资源浪费更加严重。开发人员理解和修复代码需要耗费大量时间。并且较低的软件质量（因为大量的缺陷）也导致团队的整体开发活动进展变慢。更糟的是，由于应用程序中堆积了数量较多的缺陷，会让整个团队误以为软件质量不高也是可以被接受的。

4. 等到缺陷终于被安排至当前工作流并得到处理，开发人员必须停止正在进行的工作来定位问题。即使缺陷可以被重现，也需要花费一些时间或请求其他人的帮助。如果这个缺陷还依赖于特定数据，他们可能还需要将一些数据从测试数据库拷贝到开发数据库。倘若已经过了一段时间，这些测试数据库中的数据甚至可能会丢失，使重现变得更加麻烦。

5. 一旦缺陷被重现出来，开发人员就必须开始思考采用哪种解决方案。如果他需要更新的代码不是很简洁（大部分情况是这样），他将缓慢且小心地进行以确保在修改当前缺陷时不会带来新的缺陷。

6. 最终缺陷被修复了，下一步要做的是确认更新并交付一个新的软件版本给测试人员，整个流程重新开始。

在许多项目中，这种开发人员和测试人员之间的反复占据了相当可观的一部分项目时间表，并且很多情况下还会导致项目交付的延迟。它占用的具体时间量很难被预知和管理。如果你从精益化^[10]的角度来观察整个开发过程，会发现应用系统每时每刻都有缺陷，以致它在价值流程^[11]中经常反向流转。这显然是一种浪费，我们应该试着找到方法来消除它。

缺陷的实际成本

我们都知道缺陷会带来一些返工，但有可能知道它的实际成本吗？人们用相当长的时间来研究这个课题。这里举出一小部分他们的研究成果。

• Capers Jones，在他的^[12]《Software Assessments, Benchmarks, and Best Practices》^[13]中阐明了在开发阶段修复缺陷的成本只有977美元，但如果是在开发完成之后的测试阶段修复缺陷，成本会上升到7136美元。

  
  

• Barry Boehm发表了近三十年的研究成果，这个成果证实了“消除一个软件缺陷的成本取决于它发生在开发生命周期的哪个阶段，每个下游阶段的成本都比上一阶段呈指数级增长，而且仍会有未被发现的缺陷”^[14]。

• 很多研究^[15]都证实了Boehm的发现。

• 一个美国商务部和美国国家标准和技术研究所主导的重要研究项目表明，在典型的软件开发项目中“足有80%的软件研发经费花在了缺陷修复上”^[16]。
  

这个列表还可以延伸很长，但我觉得这些已足够让你明白重点所在。花时间修复缺陷消耗了我们大量资金。还有其他的关联成本吗？这里再列举一些可能的成本点。尽管难以用货币来衡量，但它们的确在消耗团队和公司的资源。

• 不满意的客户。如果客户对我们的产品质量低下感到不满意，那么他们也许会决定使用我们竞争对手的产品。此外他们也可能因为害怕新版本中包含的缺陷影响他们的业务而不愿意进行软件升级。这个问题导致我们需要同时支持多个软件版本，这也是一种成本，并会影响到我们的帐本底线。

• 团队受到的压力。管理者经常认为提高质量或降低应用系统缺陷数量会使团队工作负担加重并且延长。他们请求（有时甚至是命令）团队在周末加班或平时工作到更晚。但问题是施加给团队的这种压力往往会起到相反的效果：压力过大或休息不足导致了更多的缺陷。

• 士气低落和消极的团队。为一个低质量的软件开发项目工作很无趣，人们喜欢在工作中满足他们的自尊心，但这在一个包含许多缺陷的软件开发过程中很难实现。久而久之，如果团队持续处在低质量的状况中，那么就会有失去优秀雇员和团队成员的潜在危险。
  

>>>> 未完待补......

备注：

[2]  https://cukes.info

[3]  https://github.com/cucumber/wiki/Spoken-languages

[4]  http://en.wikipedia.org/wiki/Lean_manufacturing#Types_of_waste

[5]  http://agilemanifesto.org

[6]  http://en.wikipedia.org/wiki/Agile_software_development

[7]  http://en.wikipedia.org/wiki/Waterfall_model

[8]  http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

[9]  http://en.wikipedia.org/wiki/Iterative_and_incremental_development

[10]  http://en.wikipedia.org/wiki/Lean_manufacturing

[11]  http://en.wikipedia.org/wiki/Value_stream_mapping

[12]  http://www.amazon.com/Assessments-Benchmarks-Addison-Wesley-Information-Technology/dp/0201485427?ie=UTF-8&s=books&qid=1209056706&sr=1-1

[13]  Capers Jones, Software Assessments, Benchmarks, and BestPractices-Addison-Wesley, 2000

[14]  Barry Boehm, Software Engineering Economics-Prentice-Hall, 1981

[15]  Robert Grady, Applications of Software Measurement Conference, 1999

[16]  National Institute of Standards & Technology, US Dept of Commerce, The Economic Impacts of Inadequate Infrastructure for Software Testing, May 2002