从测试用例看测试的问题及变化 - 享受测试带来的一切 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园
越来越觉得自己走测试这条路是对的，越来越觉得自己适合做测试，这么久以来兴趣一直在激发我前进，一直在寻找下一个站点，我相信测试路上我一定会走的很远，我的测试道路一定会很宽阔，努力就有收获，也希望还在测试路口迷惘的朋友，不要再犹豫了，因为你的犹豫不决，会使你错过很多~~~~~喜欢就去just do it ，因为只有尝试了才知道自己适不适合，喜不喜欢。如果一味的问别人，永远找不到最终的答案。因为每个人的感觉不一样，每个人的情况不一样，每个人的前提条件都不一样，你会得到不同的答案，这样只能会使你更迷茫~~~~
从测试用例看测试的问题及变化
& 15:24:44
/ 个人分类：
对于一个人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。一、问题：　许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。　当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：从此几乎很少被执行已经与程序的实现发生了冲突（界面变动，功能变动）执行用例发现的bug很少根本没有时间为新的功能需求增补用例有时间补充，但用例结构越来越乱，特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。二、原因：　事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：1、没有适合的规范　“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往?的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。　我们有太多经验，但却没有形成适合的规范。2、功能与业务的分离　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。　用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。3、测试未能跟上变化　变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。　对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。　疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。　永远是变化决定我们的下一步工作，这也是混乱的开始。三、可能的解决办法：　在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。1、测试驱动开发，用例指导结果，数据记录变化　“测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在中做到“测试驱动开发”。　首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。　如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导过程和结果。　开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。　业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。　我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。　再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。2、为用例标明时间（版本）和优先级　为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。　为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在的初期也可以参考这个优先级录制脚本。3、功能用例与业务用例分开组织　将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。4、审核用例，结对编写　测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。　测试用例不是一个人编写一个人执行，它需要测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。四、发展　上面的这些解决方法只是一种建议，具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的，传统的黑盒测试并不是毫无新意，测试工作怎样适合我们而发展，将给予我们更多的思考。(window.slotbydup=window.slotbydup || []).push({
id: '2014386',
container: s,
size: '234,60',
display: 'inlay-fix'
&&|&&1次下载&&|&&总23页&&|
软件详细(用例实现)设计规范
您的计算机尚未安装Flash，点击安装&
阅读已结束，如需下载到电脑，请使用积分（）
下载：10积分
4人评价22页
5人评价32页
1人评价7页
0人评价49页
4人评价195页
所需积分：（友情提示：大部分文档均可免费预览！下载之前请务必先预览阅读，以免误下载造成积分浪费！）
（多个标签用逗号分隔）
文不对题，内容与标题介绍不符
广告内容或内容过于简单
文档乱码或无法正常显示
若此文档涉嫌侵害了您的权利，请参照说明。
评价文档：
下载：10积分君，已阅读到文档的结尾了呢~~
[考试]什么是用例和用例描述
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
[考试]什么是用例和用例描述
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Posts - 382,
Articles - 1,
Comments - 209
海尔比斯特's Blogs
14:58 by HeroBeast, ... 阅读,
用例是什么？ 简单的理解： 直接理解就是使用的例子。 错误的理解： & 用例就是功能的划分和描述， 认为一个用例就是一个功能点。 在这种理解下， 用例变成了仅仅是较早前需求中功能框图的翻版， 很多人用用例来划分子系统，功能模块和功能点。 如果这样， 用例根本没有存在的必要。 把用例解释为某个参与者(actor) 要做的一件事可能更为合适。
这件事情有以下几个特征：
1.这件事情相对独立。 &&&&& 也就是说这件事从“功能” 上说是完备的。 2.这件事的执行结果对参与者来说是可观测的和有意义的。 &&&&& 例如，系统会监控参与者在系统里的操作， 并在参与者删除数据之前备份。 虽然它是系统的一个必需组成部分， 但它在需求阶段却不应该作为用例出现。 因为这是一个后台进程， 对参与者来说是不可观测的， 它应该在系统用例分析阶段定义。 又比如说，登录系统是一个有效的用例， 但输入密码却不是。 这是因为登录系统对参与者是有意义的， 这样他可以获得身份认证和授权， 但输入密码却是没有意义的， 输入完了呢？ 有什么结果吗？ 这件事要对参与者有价值。
3.这件事必须由一个参与者发起。 &&&& 不存在没有参与者的用例， 用例不应该自动启动， 也不应该主动启动另一个用例。 用例总是由一个参与者发起， 并且满足特征二。 例如从 ATM 取钱是一个有效的用例， ATM 吐钞却不是。 因为 ATM 是不会无缘无故吐钞的， 否则，我从此天天守在 ATM 旁， 生活无忧矣。
4.这件事必然是以动宾短语形式出现。 &&&& 这件事必须有一个动作和动作的受体。 例如， 喝水是一个有效的用例， 而“喝” 和“水”却不是。 虽然生活常识告诉我们， 在没有水的情况下人是不会做出喝这个动作的， 水也必然是喝进去的， 而不是滑进去的， 但是笔者所见的很多用例中类似“计算”，“统计”，“报表”， “输出”， “保存”之类的并不在少数。
5.用例是以参与者为中心。 &&&& 首先， 用例的背后是一种需求方法论。 其核心是以参与者为中心（区别于以计算机系统为中心）， 从参与者的角度来描述他要做的日常工作（区别于以业务流程描述的方式）， 并分析这些日常工作之间是如何交互的（区别于数据流的描述方式）。 换句话说， 用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的， 而是要弄清楚有多少参与者？ 每个参与者都做什么？ 业务流程分析则是后续的工作了。 其次， 用例简直就是为 OO 而的， 其思想完美的符合 OO。 用例分析方法试图找到问题领域内所有相对独立的参与者和事件， 并把业务流程当成是这些参与者和事件之间交互结果（在 UML 用活动图或序列图来描述）。
如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程， 先画出业务流程图，然后顺藤摸瓜， 找出业务流程中每一步骤的参与部门或岗位， 弄清楚在这一步参与者所做的事情和填写表单的结果， 并关心用户是如何把这份表单传给到下一个环节的。 那么很不幸， 你还在做面向过程的事情。
如果你的分析习惯是在调研需求时最先弄清楚有多少部门， 多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题： 你平时都做什么？ 这件事是谁交办的？ 做完了你需要通知或传达给谁吗？ 做这件事情你都需要填写些什么表格吗？.... 那么恭喜你， 你已经 OO 啦！
& 用例分析是 OO 的第一步。 如果用例分析本身出了问题， 对业务架构， 软件架构的影响是很大的， 将大大削弱 OO 的优势--复用、 扩展。 笔者认为软件复用可以分为三个层次： (1).最低层次的复用是代码级复用，这是由 OO 语言特性提供支持的， 例如继承， 聚合，多态； (2). 较高层次的复用是组件级复用， 这是由设计模式提供支持的， 例如 Factory 模式,Builder 模式；
(3).最高层次的复用则是服务级复用， 这在很大程度上是由应用服务器和通讯协议来提供支持的， 例如最近炒得火热的 SOA（面向服务的应用） 架构。 用例分析的好坏也许对代码级和组件级的复用影响不太大， 但对服务级的复用影响却是巨大的。 笔者认为服务级复用是 OO 的最高境界， 而结构良好的用例分析则是达到这一境界的基础。
& 参考： OO_Road coffeewoo