Scrum敏捷测试

什么是敏捷测试

敏捷测试的定义

首先敏捷测试是敏捷一种测试，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。在传统的测试定义上，还需要添加

敏捷测试是遵循敏捷宣言的一种测试实践：

l 强调从客户的角度，即使用系统的用户的角度，来测试系统

l 重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

l 建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

什么是Scrum？

Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的、创新性的项目。

Scrum由三个角色、六个时间箱和四个工件组成：

三个角色

1. 产品负责人（Product Owner） 2. Scrum Master 3. Scrum团队

六个时间箱

1. Sprint

2. 发布计划会议（Release Planning Meeting）可选 3. Sprint计划会议（Sprint Planning Meeting） 4. 每日站会（Daily Scrum Meeting）

5. Sprint评审会议（Sprint Review Meeting） 6. Sprint回顾会议（Sprint Retrospective Meeting）

四个工件

1. 产品Backlog（Product Backlog）

2. 发布燃尽图（Release Burndown Chart）可选

3. SprintBacklog

4. Sprint燃尽图（Sprint Burndown Chart）

Scrum最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。目前Scrum是应用最为广泛的敏捷方法之一

SCRUM理论基础

Scrum是以经验过程控制理论作为理论基础，通过迭代、增量的方法来增强产品开发的可预见性，并控制风险。Scrum经验过程控制理论的实施由三大支柱支撑： 第一：透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。 第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应：

每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；

Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；

Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

Scrum三个角色及其职责介绍

每个Scrum团队包括3个角色： 产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。

产品负责人

产品负责人的职责：

? 确定产品的功能，负责维护产品Backlog。 ? 决定产品的发布日期和发布内容。 ? 为产品的投资回报率(ROI)负责。 ? 根据市场价值确定功能优先级。

? 在每个Sprint开始前调整功能和调整功能优先级。

? 在Sprint结束时接受或拒绝接受开发团队的工作成果。

产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。

为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。

ScrumMaster

ScrumMaster 作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:

保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。

解决团队开发中的障碍。

做为团队和外部的接口，屏蔽外界对团队成员的干扰。

保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。

ScrumMaster 除了主持每日站会（Daily Scrum Meeting）之外，还有三个主要职责：

ScrumMaster 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。ScrumMaster 需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图（Burndown Chart）。

ScrumMaster 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，

以实现精益生产率的收益。

该ScrumMaster 需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。

最后但并非最不重要， ScrumMaster 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。ScrumMaster 必须注意去确保团队资源完全可被利用并且全部是高产出的。

Scrum 团队

Scrum团队的职责是在每个Sprint中将产品Backlog中的条目转化成为潜在可交付的功能增量。

Scrum团队的一些特点：

1. Scrum团队的规模控制在5-9个人。

如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能限制，从而导致无法交付可发布的产品模块。如果成员多于9人，那么成员之间就需要太多的协调沟通工作。大型团队会产生太多复杂性，不便于经验过程控制。对于大型项目来说，可以采用多个小的Scrum团队，通过Scrum of Scrums解决团队间的沟通协调问题。

2. Scrum团队是跨职能的团队。

团队成员必须具备交付产品增量所需要的各种技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。团队中不允许包括测试或业务分析等在特定领域工作的子团队。

3. Scrum团队是自组织的。

任何人，包括ScrumMaster都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体效率。

团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。

敏捷测试的挑战

参考：Bret Pettichord 的《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

我们从上下文驱动测试的七大原则(www.context-driven-testing.com)可以看出，上下文驱动测试倾向于快速的反馈和适应变化的环境。所以上下文驱动测试的很多原则和做法可以应用到敏捷开发的软件测试中来。

什么是敏捷开发？

敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。 西、反馈以及商业机会而调整。

在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。定义好接受标准，开发直到单元测试和接受测试通过才算完成。

敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。

在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），持续地进行回归测试。

为什么以前的开发模式不再适用？

以前的开发模式要求有详细的测试计划，但是缺乏足够的时间来写，而且测试计划受很多因素的影响经常改变。

以前的开发过程会专门留出一个阶段来测试，但是你不能定义进入和退出的标准，测试阶段会随之而过。

以前的开发模式强调变更控制，但是现在的软件需求变更非常频繁，变更成了家常便饭。

以前的开发模式要求测试要对软件做出权威的判断，但是测试很难做出权威的关于软件正确性的判断。

测试驱动开发，开发人员在写代码之前要先写单元测试，用于激发代码的编写、改进设计（降低耦合度，增加内聚）、支持重构。很多开源的测试工具支持单元测试（xUnit）。

用户故事是需要编码实现的功能特性的简短的描述。可接受性测试验证用户故事的完整性。理想的情况下，用户故事是在代码编写前就写完。

测试人员是否应该拥抱敏捷开发？

有些人说XP会导致差的质量并且是偷懒的借口。我认为XP是令人激动的，并将在行业中改进测试的实践。

敏捷测试实践

通过对话产生测试，谁来测试？客户往往太忙了，不可能参与测试。定义测试是很关键的活动，应该把开发人员和顾客代表包括进来，不要只是测试员自己做。

把用户故事转换成测试。测试提供的是目标和指南、及时的反馈、进度度量。测试应该用指定的格式出现，以便让用户或顾客能清楚明白，还要足够的明确，以便能被执行。

开发人员负责提供支持自动化测试的特性。大部分情况下，为产品添加测试接口，而尽量不用外部测试工具。

计划在每个迭代中探索产品，寻找bug、遗漏的特性和改进的机会。

敏捷测试的启示

什么是敏捷？

敏捷宣言：个体和交互比过程和工具更有价值；能工作的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。- www.agilemanifesto.org

敏捷开发是递增式的、迭代的、不断调整的开发模式。在敏捷开发中，工作被分解成“故事”，也叫特性或用例，组合成任务分派给不同的程序员。敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。在敏捷开发中不存在回退，讲究持续地集成，单元测试（通常使用测试驱动的开发方式），持续地进行回归测试。

敏捷测试是指在敏捷开发模式中的测试。敏捷测试包括单元测试（通常由程序员完成）和可接受性测试（通常由测试人员完成）。

如何应对敏捷？

敏捷来了，测试人员何去何从？有人认为在敏捷的团队中，在实行极限编程方式的团队中，测试员应该被“废掉”！有人认为，测试员应该拥抱敏捷，不要管什么测试计划、不要测试报告！

对于第一个论点，我们很容易就能推翻。即使是在一个完全采用XP方式的团队中，测试员还是必不可少的。只不过是测试员在XP中扮演的角色与传统软件开发模式中扮演的不大一

样了。

在敏捷开发中，测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。测试人员不再作出发布的决定。测试员不保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标。

对于第二个论点，我们要分析一下，问一下自己，你现在是在一个怎样的团队中工作的，工作得怎样？如果你是在一个传统开发模式的团队中工作，而且工作得挺好的，则第二个论点对于你来讲是错误的。

因为在传统的软件开发模式中，项目文档不仅仅是驱动项目前进的必要条件，而且很多企业的客户，尤其是软件的军方客户，对于产品的最终配套文档，还有阶段性文档都是很看重的；另外，对一些外包的软件也需要有完整的文档。而敏捷模式抛弃文档的做法在这些企业是行不通的。

传统的开发模式中，测试人员可能要兼任测试和质量保证、甚至配置管理的工作。那么按照谁负责谁决定的原则，则你作为质量方面的负责人，必须对产品的质量把关，做好“守门员”，对产品的放行有绝对权威的发言权。

敏捷测试的启示

对于我们测试员来说，如果你是在一个敏捷的团队，采用完全的XP方法，则你应该按照敏捷测试的原则，调整自己的角色，让自己成为一名真正的敏捷测试员。在敏捷的团队中，测试工作的核心内容是没有变的，就是不断地找BUG。只是你要调整好自己的心态，一切以敏捷的原则为主。更多的采用探索性测试方法，更多地采用上下文驱动的测试方法论，更多地采用敏捷自动化测试原则。

如果你是在一个传统的开发团队中，你不可能背叛整个团队的一贯做法，自己去“拥抱敏捷”，毕竟很多公司按照ISO、CMM的做法也在不断地成熟。那么我们需要做的是多吸收一些敏捷的思想，优化一下自己的测试流程。

敏捷提出的用户故事的说法，其实是把需求规格说明书敏捷化了，那么其实它是指出了需求文档冗长和管理不当的问题，那么通过一些控制工具是否能解决问题呢？同时也给我们一个启示，敏捷测试为什么能在缺乏文档的环境下工作？我们为什么就非要依赖文档呢？测试员是否能自动地寻找和挖掘更多的关于软件的信息来指导我们的测试呢？探索性测试，这种强调同时设计、测试和学习被测试系统的测试方式是我们可以借鉴的。

敏捷讲求合作，其实是指出了我们传统工作方式沟通上的毛病，开发人员与测试人员往往都比较对立，我们传统的方式过分依赖书面的沟通，文档驱动，缺乏很多面对面的交流，我们能否主动点，多与开发人员聊聊需求、讨论设计、一起研究BUG出现的原因呢？

敏捷测试认为要持续地测试，不断地回归测试，快速地测试。其实是指出我们传统的测试阶段过于冗长、没有根据项目的上下文作出调整，速度太慢，过分依赖手工测试。那么我们能否多点借鉴上下文驱动测试的方法，适当自动化我们的测试呢？

敏捷与质量

陈能技

2007-10-9

原文：Agility and Quality – Alan S.Koch

摘要

对于什么是“质量”有很多的定义，“质量是由旁观者定义的”，有些人会说这是不可能使用的定义，因为它很难在真正的业务场景中工作。但是敏捷方法不同意。敏捷方法就是用这种方

法让产品的质量由顾客塑造。他们承认不同的人会用不同的观点看问题，所以对于项目来说谁的观点最能说了算（最终顾客）就是敏捷方法要追求的。

项目的高质量是什么由什么组成的？不要问我！问你的顾客！

项目是用来学习的

在传统的软件开发方法中，我们努力构建顾客想要的产品。我们花费大量的时间努力从顾客那里获取需求，我们针对需求进行分析和建模，并且归纳成说明书。然后我们评审说明书，与顾客开会讨论，最后签字。看起来我们将要构建的产品确实是满足顾客要求的。但是通常那不是最终结果。通常，在项目快要结束的时候，需求和范围、产品的适用性成为争论的焦点。开发人员埋怨顾客改变了主意，顾客则不明白开发人员怎么会偏离这么远。

是谁的错？敏捷方法指出每个人都有错，但是每个人都没有错。他们告诉我们开发项目不是别的，而是一个学习的体验。没有谁能完全理解所有需求之后才开始项目；即使是顾客也一样。顾客一开始有一些主意，但是他们也在项目的进展过程中学到关于他们的需要。同样的，开发人员在一开始学习到他们能知道的东西，但是他们需要继续通过项目来学习更多的东西。

没有人完全清楚会构建出什么来，直到项目结束。因为每个人都在通过项目学习，敏捷方法改变了过程以便识别出持续学习，并培养每个人的学习能力。

他们通过把与顾客交互的过程从项目的开始阶段移到项目的“心脏”。不是摘取顾客的想法然后使用写下来的说明书作为开发的基础，敏捷方法使用顾客自己！他们让顾客有规律地参与到项目的每个迭代过程中来。

敏捷方法中的质量

在敏捷项目开始的时候，顾客和开发人员一起定义项目会做什么。他们建立XP所说的“项目隐喻”，这是用快速的大笔触描绘产品的大概样子。另外，会提炼出一份需求列表（XP称之为“故事”），但是不像传统的需求，这些故事不会有详细的细节，也不是一成不变的。

敏捷项目通过很多一个月左右的短期开发周期来增量地构建产品。每个周期开始于顾客决定哪个故事应该先构造。开发人员通过对技术可行性的分析来调节顾客的期望值，然后一起决定在这个迭代开发中需要成功构建哪些内容。

随着开发人员构建了增量的部分，他们需要通过测试来保证产品没有很多缺陷，像顾客需要的那样工作。在他们工作的过程中能随时得到顾客的回答，因此能感觉自信他们构建的是顾客想要的。然后，当开发的增量部分完成后，系统会交付顾客进行测试或使用（如果顾客选择这样做的话）。

开发人员和顾客之间都有很多反复的过程，任何人都可以随时对现在的需求提出更改，甚至删减或增加需求。对于顾客，这是他们对“高质量”进行微调的机会，结果是改变了对开发人员的指导。

从简单的bug修正到激进的需求改变都添加到“需求”列表。然后，在下一次的迭代计划中，

3、 执行自动化测试脚本

从上到下，设计所需的时间要不断增加，但是测试执行的时间不断减少，因为自动化测试可能仅会验证你在脚本里写好要验证的东西，那就意味着你要预测什么缺陷会出现。而在手工测试过程中，你可能看到间接的证据表明存在某些缺陷。测试用例越详细，测试人员已经测试的时间就会越多（现在会执行得更快了），能找到那些间接验证的问题的可能性越低。

讲了这么多理论，现在来点实践性的东西。我在新项目是按下面的方式做的：

首先，我会找出所有在第一个版本中界面自动化失效的地方。这可能会与那些只发布一次的项目不一样，但是我在那些方面没有什么经验。当然单元测试像JUnit执行指定的API函数也会很有用，能被开发人员很好地创建，但是测试人员有时候也应该帮助一下他们。

接下来，在测试执行周期中，我不会写任何测试用例。我只会在版本发布后更新测试计划，详细地写出被测试功能特性的列表，以及对应有哪些功能特性不生效、对应的缺陷ID。在版本发布后，我创建详细的测试用例文档描述怎样调用每个功能特性，输入什么数据等等。看起来像是文档，但是有着不同的目标和用途：目的是让回归测试执行更快速进行。例如，我把数据附加上去，从而减少准备数据的时间；我细化一些琐碎的测试用例，测试人员（新手除外）会添加错误处理的一些细节。

我尝试使用测试白板（Testing Dashboard）去替换正式的包含测试用例执行/通过/失败/未执行等信息的测试报告。有时候，我只是通过非正式的所谓我的感觉之类的东西来沟通进度，而这其实是PM（项目经理）想要知道的，而不是测试用例的数字。

敏捷测试用例设计

敏捷宣言：

个体和交互比过程和工具更有价值；

能工作的软件比全面的文档更有价值；

顾客的协作比合同谈判更有价值；

及时响应变更比遵循计划更有价值。

- www.agilemanifesto.org

并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。

测试用例的设计是其中一项。

测试用例的粒度

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。

测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没

有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

基于需求的测试用例设计

基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。

要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。

不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。

测试用例的评价

测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。

因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。

测试用例数据生成的自动化

在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。

很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。

可利用一些工具，例如TConfig、PICT等来产生这些数据。

在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用

工具生成。

工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。

very different practices (even different definitions of common testing terms) will work best under different circumstances.

Contrasting context-driven with context-aware testing.

Many testers think of their approach as context-driven because they take contextual factors into account as they do their work. Here are a few

examples that might illustrate the differences between context-driven and context-aware:

Context-driven testers reject the notion of best practices, because they present certain practices as appropriate independent of context. Of

course it is widely accepted that any “best practice” might be inapplicable under some circumstances. However, when someone looks to best practices

first and to project-specific factors second, that may be context-aware, but not context-driven. Similarly, some people create standards, like IEEE Standard 829 for test documentation, because they think that it is useful to have a standard to

lay out what is generally the right thing to do. This is not unusual, nor disreputable, but it is not context-driven. Standard 829 starts with a

vision of good documentation and encourages the tester to modify what is created based on the needs of the stakeholders. Context-driven testing starts

with the requirements of the stakeholders and the practical constraints and opportunities of the project. To the context-driven tester, the standard

provides implementation-level suggestions rather than prescriptions.

Contrasting context-driven with context-oblivious, context-specific, and context-imperial testing.

To say “context-driven” is to distinguish our approach to testing from context-oblivious, context-specific, or context-imperial approaches:

Context-oblivious testing is done without a thought for the match between testing practices and testing problems. This is common among testers who

are just learning the craft, or are merely copying what they’ve seen other testers do.

Context-specific testing applies an approach that is optimized for a specific setting or problem, without room for adjustment in the event that

the context changes. This is common in organizations with longstanding projects and teams,

wherein the testers may not have worked in more than one

organization. For example, one test group might develop expertise with military software, another group with games. In the specific situation, a

context-specific tester and a context-driven tester might test their software in exactly the same way. However, the context-specific tester knows only

how to work within her or his one development context (MilSpec) (or games), and s/he is not aware of the degree to which skilled testing will be

different across contexts.

Context-imperial testing insists on changing the project or the business in order to fit the testers’ own standardized concept of “best” or

“professional” practice, instead of designing or adapting practices to fit the project. The context-imperial approach is common among consultants

who know testing primarily from reading books, or whose practical experience was context-specific, or who are trying to appeal to a market that

believes its approach to development is the one true way.

Contrasting context-driven with agile testing.

Agile development models advocate for a customer-responsive, waste-minimizing, humanistic approach to software development and so does context-driven

testing. However, context-driven testing is not inherently part of the Agile development movement.

For example, Agile development generally advocates for extensive use of unit tests. Context-driven testers will modify how they test if they know

that unit testing was done well. Many (probably most) context-driven testers will recommend unit testing as a way to make later system testing much

more efficient. However, if the development team doesn’t create reusable test suites, the context-driven tester will suggest testing approaches that

don’t expect or rely on successful unit tests.

Similarly, Agile developers often recommend an evolutionary or spiral life cycle model with minimal documentation that is developed as needed.

Many (perhaps most) context-driven testers would be particularly comfortable working within this life cycle, but it is no less context-driven to

create extensively-documented tests within a waterfall project that creates big documentation up front.

Ultimately, context-driven testing is about doing the best we can with what we get. There might not be such a thing as Agile Testing (in the sense

used by the agile development community) in the absence of effective unit testing, but there can certainly be context-driven testing.

Contrasting context-driven with standards-driven testing.

Some testers advocate favored life-cycle models, favored organizational models, or favored artifacts. Consider for example, the V-model, the mutually

suspicious separation between programming and testing groups, and the demand that all code delivered to testers come with detailed specifications.

Context-driven testing has no room for this advocacy. Testers get what they get, and skilled context-driven testers must know how to cope with what

comes their way. Of course, we can and should explain tradeoffs to people, make it clear what makes us more efficient and more effective, but

ultimately, we see testing as a service to stakeholders who make the broader project management decisions.

Yes, of course, some demands are unreasonable and we should refuse them, such as demands that the tester falsify records, make false claims about

the product or the testing, or work unreasonable hours. But this doesn’t mean that every stakeholder request is unreasonable, even some that we don’

t like.

And yes, of course, some demands are absurd because they call for the impossible, such as assessing conformance of a product with contractually-

specified characteristics without access to the contract or its specifications. But this doesn’t mean that every stakeholder request that we don’t

like is absurd, or impossible.

And yes, of course, if our task is to assess conformance of the product with its specification, we need a specification. But that doesn’t mean we

always need specifications or that it is always appropriate (or even usually appropriate) for us to insist on receiving them.

There are always constraints. Some of them are practical, others ethical. But within those constraints, we start from the project’s needs, not from

our process preferences. Context-driven techniques?

Context-driven testing is an approach, not a technique. Our task is to do the best testing we can under the circumstances–the more techniques we

know, the more options we have available when considering how to cope with a new situation.

The set of techniques–or better put, the body of knowledge–that we need is not just a testing set. In this, we follow in Jerry Weinberg’s

footsteps: Start to finish, we see a software development project as a creative, complex human activity. To know how to serve the project well, we

have to understand the project, its stakeholders, and their interests. Many of our core skills come from psychology, economics, ethnography, and the

other socials sciences. Closing notes

Reasonable people can advocate for standards-driven testing. Or for the idea that testing activities should be routinized to the extent that they can

be delegated to less expensive and less skilled people who apply the routine directions. Or for the idea that the biggest return on investment today

lies in improving those testing practices intimately tied to writing the code. These are all widely espoused views. However, even if their proponents

emphasize the need to tailor these views to the specific situation, these views reflect fundamentally different starting points from context-driven testing.

Cem Kaner, J.D., Ph.D. James Bach

我们为什么要写测试用例？

原文： Why do we write Test Cases？ - Ainars Galvans

测试用例的编写作为QC特定的概念、技能，成为唯一广泛公认的东西，这是我进入测试行业时感到很惊讶的事情。现在，过去10多年了，我终于有点明白了。现在，我是探索性测试（Exploratory Testing）的鼓吹者，我在这之前甚至没有听过这个术语和方法。但是，我现在仍然写测试用例，在一些有意义的地方，相信“银弹”适用于任何地方是错误的。

在上年的时候，我曾经把测试用例比喻成盾，而把测试比喻成剑。（http://www.testingreflections.com/node/view/3041），我仍然相信测试用例的创建会有两个用途或目的：

1） 测试用例被认为是要交付给顾客的产品的一部分。测试用例在这里充当了提高可信度的作用。典型的是UAT（可接受）级别。

2） 测试用例只作为内部使用。典型的是系统级别的测试。在这里测试效率是目的。在代码尚未完成时，我们基于设计编写测试用例，以便一旦代码准备好了，我们就可以很快地测试产品。

在转向敏捷开发的过程中，第二条失去了它的价值。我在我们公司和其他公司都看到了这样的事情。看起来要变成以下的方式：

a） 测试用例被内部使用，但是目的是可信度，而不是效率。也意味着测试用例会在测试执行过程中被不断修改和重写。

b） 探索性测试会取而代之，不写测试用例

我不回进一步去探讨a）的方式，因为很明显这种是很不可靠的测试管理 – 你不能使管理层相信这是低效的利用资源的方式。也有一些时候，测试用例被创建只是用于报告测试进度。比如说，我们有80%的测试用例编写了，而其中70%通过测试。我已经在抨击这种方式，并且还会继续抨击它。因为这是典型的用缺陷数字来衡量质量，用测试用例个数来衡量测试进度的错误方法。

上面两种方式是否正确依赖于我们是否需要可重用的测试用例。我相信回归测试用例的编写和自动化测试脚本的编写有很多共同点。甚至可以说它们有3个级别：

1、 纯探索性测试

2、 执行编写好的测试用例

本文来源：https://www.bwwdw.com/article/kczf.html