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

2013-08-15林振文

科技视界 2013年14期

林振文

（同济大学，中国上海 200092）

1 问题分析

许多测试类的书籍都有大幅篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂、关联模块紧密、输入标准和输出的结果之间路径很多的时候，一味的遵循固有的方法只能够在心理层面上得到满足，而无法真正有效地提高测试的效果，并且我们也没有足够的时间和资源编写完备的用例。通常我们只能依靠以前项目的用例编写经验（或习惯），希望能够在一个完整的项目中更做的加规范化，但绝大多数的情况是只停留在“书写的规范”的层面上，真正的测试用例设计上还是存在很多的问题。

知道如何执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是“只见树木，不见森林”，只说明某一功能的实现，无法串起）通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展。

2 产生原因

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

2.1 没有适合的规范

“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、指导步骤和书本上的定义，但它适合我们当前的项目么？每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？

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

2.2 功能与业务的分离

举个例子来说，现在的技术往往是知道如何进行一个输入框的测试，而却忽略了对此输入框的功能来进行说明，深入的分析下去我们会发现，测试用例的选取和其功能存在着越细致分离其联系越紧密的特点。往往我们采用的测试用例选取方法如：边界值分析、等价类选取、因果图法，而这些选取用例的方法往往停留在理论层面的方法，是一种经验的总结，其本身比较偏向代码方面的考量，而对实际业务层面的测试用例的选取还需要更多的去考虑其功能上面的影响和测试。

整个软件中存在很多复杂的业务，也涉及了很多功能，其内部的分支更是繁多，这样一来测试用例的涉及就需要简明、准确。对于功能的测试用例往往依赖于程序界面，对其业务的描述往往依赖于需求分析文档。这样一来对于测试就需要更偏向于依照实际的用户接口来编写测试用例，找到其边界值，给出其等价类的代表性测试用例。对于业务流程只能凭借测试经验来进行理解，这时测试出来的BUG是最多的，可能无法使这个BUG对应到具体的用例上，只能自己添加note向开发人员指出可能出错的源头。正因为我们没有很好的积累在业务上的测试用例，才使得我们感到执行测试用例时发现的错误不多。

2.3 测试未能跟得上程序的变化

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

3 解决方法

上述问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。分析错误并不能给我们带来成功，而成功的特质也不会尽为相同。所以在这里我希望以探讨的方式提出一些可能的解决办法，不拘泥形式，以结果来确定，最适合的就是最好的。

3.1 驱动测试开发，指导用例结果，记录数据变化

“驱动测试开发”（TDD）是一个非常新的测试概念，各类刊物上也有对其描述，主要研究的是如何使代码更奏效（Work）、更洁净（Clean），“驱动测试开发的基本宗旨是在软件开发相应的功能前，先对于其所实现的功能编写测试用例代码”。显而易见，TDD是在“代码”级的驱动触发的，但目前研究的问题是如何在黑盒测试过程中实现“驱动测试开发”，一般认为可从测试用例的级别开始做起，用具体实际的业务来指导实现的结果。

软件开发人员往往注重代码如何实现其功能，而对业务上的实际操作的理解并不透彻，而需求分析报告有不会全面的给出具体要实现什么样的功能和场景，这就样一来就存在了程序开发人员和实际需求者的不一致的现象，如果最后发现程序错了就需要重做，这样不仅耗费人力更加对公司的开发进度有着很大的影响。软件测试人员与最终用户不用过分关心软件实现的细节，所以用业务用例来对开发进行驱动，是一个比较合适的选择。给出一个明确的预期结果，指导开发人员如何界定是否达成目标，还需要用到各种软件测试方法来分析出各个业务过程中需要测试的等价类和边界值。

3.2 设置测试用例版本和优先级

为不同时期的测试用例设置不同的版本能够起到基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

3.3 用例审核，结对编写

负责整个测试的管理人员对用测试例进行审核能够对用例进行补充和校正，可现实的测试过程中往往比较难实现，而普遍采用的方式是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。测试用例非自己编写自己执行，而是需要其他测试人员来进行测试并有着很好的可读性。这样一来所编写的测试用例的可移植性和可维护性大大提高，同时能拓展了测试思维，加强了对测试重点的确认，进而使得小组内部达到了统一。一定程度上结对编写也可以减少测试负责人的工作压力，提高组员的参与积极性。