2011软件水平考试软件测评师测试技术辅导(5)2

 二、原因：

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

　　1、没有适合的规范

　　"适合的规范"或称"本地化的规范"。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、指导步骤和书本上的定义，但它适合我们当前的项目么?

　　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好?

　　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。我们有太多经验，但却没有形成适合的规范。

　　2、功能与业务的分离

　　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

　　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

　　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务"格格不入"。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)，只能自己添加note向开发人员指出可能出错的源头。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

　　用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

　　3、测试未能跟上变化

　　变化!想象一下，当我们越来越多的听到开发人员在那里高呼"拥抱变化""敏捷开发"的时候，测试又有什么举措呢?当地区特性，软件版本越来越多的时候，测试是否在积极响应呢?变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

　　对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些"不必要"的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

　　疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐"脱离"，可能还会出现相互违背的情况，但这我们却无法及时发现。

　　永远是变化决定我们的下一步工作，这也是混乱的开始。