从测试用例看测试的问题及变化

dionysus

对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

一、问题：
许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。
当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：
 从此几乎很少被执行
 已经与程序的实现发生了冲突（界面变动，功能变动）
 执行用例发现的bug很少
 根本没有时间为新的功能需求增补用例
 有时间补充，但用例结构越来越乱，
 特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）
 知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）

通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。
但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。

二、原因：
事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

1、没有适合的规范
“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？
每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？
在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往•的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。
我们有太多经验，但却没有形成适合的规范。

2、功能与业务的分离
我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。
边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。
复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。
用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

3、测试未能跟上变化
变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。
对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。
疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。
永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能的解决办法：
在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

1、测试驱动开发，用例指导结果，数据记录变化
“测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。
首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。
如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导过程和结果。
开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。
业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。
我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。
再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

2、为用例标明时间（版本）和优先级
为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。
为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

3、功能用例与业务用例分开组织
将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。

4、审核用例，结对编写
测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。
测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。

四、发展
上面的这些解决方法只是一种建议，具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的，传统的黑盒测试并不是毫无新意，测试工作怎样适合我们而发展，将给予我们更多的思考。

希西兮兮

写好一个功能点的测试用例很容易，但是要把整个系统的测试用例设计的有效且可用性高则是一件困难的事——从树怎样到森林，不是简单的几棵树相加

suchboy

顶！！！！！

发现楼主太强了，能否留下联系方式啊，有很多问题向您请教啊！

slide

lz的问题描述和原因分析一针见血，相信很多人都会有切身的感受。

lz提到的TDD应该只是借用了TDD的概念。测试驱动开发，原意应该是单元测试级别的白盒测试，所有用例都可以自动执行，这样才能保证用例细节的准确以及执行的效率。TDD的实现对于各方面要求会很高，推广起来门槛比较高，但并不妨碍我们来借用TDD的思路，改进目前的黑盒测试流程。
lz的意思应该是以用例的形式来描述系统的需求规范，可能称为 USE CASE更合适，而不是TEST CASE。不过关系不大，很多情况下，TEST CASE都可以通过USE CASE直接转化而来。通过用例形式来描述需求，可以有效避免描述的模糊性和歧义，而且可以采用一些规范化的方法来提高质量。

以数据作为驱动本身就是开发水平提升的一个标志，其优点大家都知道了，就不多啰嗦了。

为用例增加版本和优先级是有必要的，但随之而来，对于用例的管理要求也提高了，会有新的问题出现，如多个版本之间的用例如何维护，如何根据优先级进行搜索和查询等等。需要整体测试用例的平台支持之后，才能更好地发挥作用。如果缺乏了技术层次上的支持，很可能会带来更多的混乱和维护工作量。

功能用例和业务用例分开组织是很好的思路，再推广一步，可以把用例划分为多个不同的层次，如同网络的7层协议。由低层用例支撑高层用例，形成一个完整的体系架构。把层次定义好了，用例的结构、每个用例应该涉及到的范围就清楚了，整体的架构就不会出现大的混乱。其实，如果开发的架构好的话，测试的架构也不会差到哪里去，但如果开发的架构就非常混乱，基本解耦都没有实现，但希望测试来解决问题是比较困难的。

XP结对编程的成功给我们进行结对编写测试用例的尝试指明了方向，更一步也可以在推广到结对测试。在测试中，更容易发现测试用例到底哪里还存在问题，不同的人执行可能会有不同，但需要在同一个用例的维护中体现出来。不过也需要相关的修订和评审的流程来作为保证，才能避免混乱。

黑盒测试工作要做好可不是一件容易的事情，大家多多交流，呵呵。

dionysus

原帖由 slide 于 2006-11-15 13:34 发表
lz的问题描述和原因分析一针见血，相信很多人都会有切身的感受。

lz提到的TDD应该只是借用了TDD的概念。测试驱动开发，原意应该是单元测试级别的白盒测试，所有用例都可以自动执行，这样才能保证用例细节的准 ...

谢谢slide的补充和拓展。我们怎样组织好测试用例，进而到怎样更好的掌控进度流程，还需不断探索和实践。套一句话说就是“走有中国特色的测试之路”，相信我们不会永远是学生的。
欢迎大家讨论

wuhuawu09

支持一下..不错..

wxx829

我是新手。。没太看明白LZ的意思。
再看看~顶了~

shirlincn

写的不错，希望能多多和你交流

wbjvvv

分析的很透彻，我们现在也存在用例方便的一些困惑；
用例的复用性很差

testying

测试用例的维护 不知大家有没有软件推荐一个

Joan2005

从此几乎很少被执行
 已经与程序的实现发生了冲突（界面变动，功能变动）
 执行用例发现的bug很少
 根本没有时间为新的功能需求增补用例
 有时间补充，但用例结构越来越乱，

深有体会啊.因为项目时间紧,几乎没有时间去补充,更新用例.....
不少资料都提倡由USER CASE 来写TEST CASE.但是这不是我们测试所能左右的.我们的需求说明书都是很按功能划分来写的.而且很粗糙...之后几乎没有什么设计文档了,直到程序开发出来

欣奕

lz的第二点功能与业务的分离，偶不是很明白，能否解释一下呢？谢谢。

dionysus

原帖由 欣奕 于 2006-12-29 09:57 发表
lz的第二点功能与业务的分离，偶不是很明白，能否解释一下呢？谢谢。

对于较大的程序，有时功能与业务关联不是很清晰的，我们比较习惯对窗体或按钮设计用例，而且能针对某一个输入设计出n多种分类，但从整体看来却是舍本逐末了。记得我培训新人的时候看他们做模拟项目，他们的用例都是各种合法和非法输入，对每一个输入框都不放过，但这个软件是用来实现什么的他们谁也不知道。

欣奕

sdlkfj1 现在我做的关于输入框的测试用例也差不多跟你们那里的新人一样，都是设计有效和无效的测试数据，那应该怎样设计用例才能把功能和业务关联起来呢？

dionysus

原帖由 欣奕 于 2006-12-29 11:34 发表
sdlkfj1 现在我做的关于输入框的测试用例也差不多跟你们那里的新人一样，都是设计有效和无效的测试数据，那应该怎样设计用例才能把功能和业务关联起来呢？

编写功能用例肯定是必须的，但是过于“痴迷”就有点作牛角尖了，功能与业务兼顾的用例很难写，有点鱼与熊掌的意思。那我们还不如就分来来组织，如我提到的，在开发前期主要设计业务流程的用例，提供给开发和需求人员“审核”，实践证明这样可以提前预防很多潜在的问题，避免错误的开发。

zxqpse

好文章，多谢分享

冷月

问题看的很准，我也在以功能为中心还是业务为中心之间徘徊。虽然心里面想的是以业务为中心，但用例写到后来业务都被拆成了功能点，很难看到一个整体的业务，不过如果把所有功能都执行完了，业务肯定还是被覆盖到了的。
我在想能不能写两套用例，
一套是业务流程的，一个用例写一条路由（包括多个环节）。具体的输入和输出选择一些有特点来用。这一套用例的数量应该比较少，发现的缺陷的可能也不多，但发现的缺陷可能都是大问题，因为流程都走不下去。先执行这套用例。
另一套是功能的。一个一个功能点写落。数量庞大，发现的缺陷数也多。

我以前做过一个试验，是一个比较小的流程。
先按功能点写完用例，然后再把这些用例串成一个个流程写在*.xl文档里面作为附件和功能用例保存在一起。
感觉小流程还勉强可以用，但流程一大起来，将这些用例串起来工作量太大了，所以后来就放弃了这个作法。

可能单写流程不管具体功能点可能效果要好一点。

leiying

原来在测试时代中看到这篇好文章，马上收藏了，写得真是很不错。没想原来是版主的大作，佩服！
版主说的问题也是我一直以来很困惑的问题，看了有所启发，谢谢！

luming

写的很好。
当时在看到TDD的时候，我有一个疑问就是TDD强调的是代码，而不是文档。
但测试特别是系统测试更强调文档说明，在缺少设计文档而是由各种case支撑的时候，test case如何实现？
可以看看我和别人的一些讨论。
http://www.javaeye.com/topic/13517

zhouxiao

谢谢