为了提高软件测试的效率，增进测试工作的广度和深度，越来越多的公司开始引入自动化测试。本文通过笔者对测试用例设计和表达上的一些理解，阐述如何写好功能自动化测试友好的用例，供大家参考。

　　自动化测试有其自身的特点，按照笔者的经验，自动化在一个项目，乃至一个公司开展的成功与否，并不是仅仅依靠QTP等工具使用者的脚本编写水平的提高就可以掌控的。而因为其他的一些因素，一旦自动化测试失去了它本身的高效、可控的特点的话，那反而是得不偿失，会增加项目的成本。

　　自动化测试人员进入项目的时间可能不是最早的，对需求的理解并不是在第一时间就很容易做到的。测试用例作为测试需求的载体、测试执行的依据和工作量的评估，它设计和表达的优劣直接影响到自动化测试开展的前几个阶段，如：需求学习、筛选适合自动化测试的用例以及提取公司级或项目的可重用脚本等方面的工作效率。

　　1.步骤和数据的分离：

　　好的测试用例，在执行的步骤（Step）的表达上应该是尽可能和数据相分离。举例来讲，有一个ATM机取款的功能，可能有以下几个场景：

　　1. 密码正确的登录
　　2. 密码错误的登录
　　3. 密码输入三次错误，卡被锁定
　　4. 取少于余额的款项
　　5. 尝试取大于余额的款项
　　6. 尝试取等于余额的款项（考虑手续费）
　　6. 取款额度大于当次的限制
　　7. 取款额度大于当天的限制
　　7. 取款次数大于限制次数
　　等等

　　不管你用什么用例设计的方法论来做指导，作为这个简单的例子，有经验的人都应该能看出，此处的很多步骤是可以重用的，总结下来如下（此处只列出了操作的步骤，略去了系统的交互中的反馈结果）：

　　（1） 插入卡->A：输入密码->B：按“确定”键->重复A-B

　　（2） A：选择取款功能->B：填写取款金额->C：点击“确定取款”的按钮->D：取现金->重复A-D

　　因此，我们只需要写出两套比较完整的步骤，将密码和取款金额多数字用参数来表达即可。这样是不是简单了很多呢？

　　2. 单独的测试基础数据准备工作

　　第一个例子中的输入数据比较简单，但我们同样需要考虑的一个问题是：在测试中究竟我们输入什么样的具体数据呢？什么是“正确的密码”？什么又是“大于余额的款项”呢？

　　对于大的应用系统，数据之间的关系和准备过程都会很复杂，甚至也有其他外部系统导入、传输或计算出的数据。 一个比较好的做法是，将这些测试数据提前准备好，在每个阶段性测试前导入到系统中。一个比较典型的例子，假设要求你单独去测试几张复杂的财务报表，用其他的模块和外部系统，自己逐一的去创造数据，那会非常耗时耗力。这时，基础数据的准备就显得尤为重要，以此才能保证测试工作是高效的、测试结果是精确的。

　　如果有可能，复杂的测试基础数据最好是提前准备好的，类似这里例子中简单的 一个帐号为1234567890，密码为66666的有效银行卡，里面有人民币1000元正，等等。将这些内容预先准备好（可以用自动化工具来准备，或导出已有的数据为一个SQL的脚本），写到你单独的测试数据准备文档中，而不是分散到 所有使用到它的case中才去描述。

　3. 测试用例的前置条件和后置条件

　　除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。比如准备一个初始设置条件下的IE浏览器和已安装过老版本该软件的XP系统。这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为Setup Section或叫Pre-Condition。

　　对于后置条件或Post-condition，往往我们用它来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正好取完所有金额，余额为零的情况下，可以通过一些步骤或数据库脚本重置帐号余额。同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态呢？

　　集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。

　　顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在Test Set这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。

　　4. 常用业务操作（Knowledge Base）

　　对于一个大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引入自动化测试。它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚本。

　　这些完成一些预定业务操作的脚本单元，是可以直接借用的。为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。

　　举例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层的处理过程，对一般员工是不需要，也没有权限去深入掌握的。这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。如此，可以大大提高各个有相关接口的模块的自动化测试工作效率。

　　另，做以下做几点补充：

推荐	不推荐
将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。	Copy需求和设计文档中的内容；描述成：什么条件下，逻辑会是怎样。这样对测试用例的阅读和执行人员，不具有可操作性。
期待的结果要写具体，如：系统反应是什么；结果数字是多少；用户被带到什么页面；显示什么成功信息；后台或数据库中该记录的修改后结果是怎么样的。	描述成：”验证系统返回正确结果“；”页面元素显示跟SPEC一致“；”操作成功“等 比较抽象的说法。
业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。	以页面形式组织用例。
以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；使用用例管理工具。	Word格式的扁平组织结构，不利于管理和阅读。
用一个属性字段，建立用例和Spec等文档的某个章节间的映射。	无法和需求对应，以后难以计算 用例覆盖率，测试执行覆盖率。
每个Module、Function、特定业务的一组测试用例，之间做到独立、没有耦合。	用例之间有依赖，无法做到：挑选30%的用例做回归测试。
在时间和成本允许的情况下，尽量做到：用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。	在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。
对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。	对于一个长业务操作，只存在比较零散的细节用例。
将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。	用例 没有优先级和重要程度的定义。

　软件测试是保证软件优良品质的重要环节，其重要性是毋庸置疑的。怎样以最少的投入尽可能多地发现软件系统的缺陷，保证软件的优良品质，是软件公司的目标。我们都知道，影响软件测试的因素有很多，如软件本身的复杂程度、相关人员的素质、测试方法和技术的运用等等。如何保障软件测试质量的稳定当然也就有很多方面的因素，这其中测试用例的设计和编制对于保障软件测试质量的稳定起很重要的作用。

　　对于测试用例（Test Case）目前还没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　　说到测试用例的设计，很多人甚至是用例设计者都会认为很简单的事情，在他们看来，只要按照需求，将软件功能进行划分，然后据此按每个功能，采用等价类划分、边界值等方法来设计用例，再补充一些异常情况处理就行了。但事实上，对同一个项目，有经验的测试人员，在写用例或测试时总会有更多的测试思路，从而发现更多的问题；而有些测试人员测试用例的撰写却少了很多，表面看好象已经把页面所有信息的测试都考虑到了，实际上却还是遗漏了大量测试覆盖点，其结果是一方面测试过程发现的问题很少，另一方面当然是其测试出来的软件总是比较脆弱，等用户真正使用时就开始出现各种问题。

　　究其原因，还是测试用例的撰写水平不到位，更确切地说是测试用例的覆盖率太低。有些用例设计者甚至张口就是用例达到了100％覆盖率，其实还差得远着呢。要知道，并不是说每个功能都写到了这个用例就覆盖完整了，这还远远不够，还有大量的内部处理、业务逻辑等都需要考虑。而这些除了需要用例设计者的经验之外，还需要真正了解项目实现情况，了解用户的使用，才能真正地保证我们的测试覆盖率。具体来说，需要注意下面几个方面：

　　首先，还是需要按照需求，将软件功能进行划分，然后据此按每个功能或者相关功能，采用等价类划分、边界值等方法来设计用例。这其中要注意有些功能模块并不是孤立的，而是彼此相关的，对于交叉功能，一定注意设计相关的用例。千万不要出现两个交叉功能，都从各自功能出发设计用例，而相互交叉影响的部分丝毫没有用例涉及。

　　第二，注意界面上看不见的隐含功能。并不是所有的软件功能都会体现在界面上，软件往往还具有一些后台处理功能，这些有可能会在设计用例时被忽略掉。比如说软件的网络升级功能，软件客户端与服务器端的自动同步等，一般都会定时自启动。类似于这些后台功能在软件界面上一般都没有体现，这就要求用例设计者必须熟悉项目情况，否则设计出来的用例必然会遗漏掉部分功能。

　　第三，设计一些正常操作的完整业务流程用例。现在有很多业务型应用软件，它的许多功能点会结合成一个或多个完成的业务流程，此时不能孤立地仅仅设计每个功能点的用例，还需要从整体的业务流程角度出发去考虑用例。例如测试某个购物网站，那会有登录、浏览商品信息、提交购物申请、填写支付信息等完整的流程，此时就不能分开只是单独考虑每个孤立的功能。说白了，总该需要保证用户浏览后选中的商品可以放进购物筐，而放进购物筐的商品可以支付购买吧。这样就需要设计一些横跨好几个功能点的完整业务流程用例。

　　最后，关注用户的特殊使用和异常情况。很显然，这是最容易被开发忽略的方面，当然也就是软件最脆弱的地方。比如跟网络相关的功能，考虑网速慢、断网等各种情形。再比如说，跟时间处理有关的功能，考虑每日的零点、每月的月初月末、每年的年初年末、闰年等等特殊时间。总之就是要尽可能多地考虑一些特殊情况，来补充用例。

测试种类繁多，针对不同类型的测试，测试用例的设计方式完全不同。如:性能测试的测试用例中，需设计大量的测试运行场景，准备相应的性能指标表格供测试人员填写，并进行数据分析。

　　本章着重探讨的是功能测试中使用的测试用例，为避免混淆，方便叙述，后续未说明的测试用例均指功能测试的测试用例，有特殊需要之处将进行特别说明。

　　如前文所述，测试用例是测试人员执行测试时的重要参照标准。因此，测试用例必需使测试人员能够明确理解，并能够依据测试用例的描述执行测试。为此，一个设计良好的测试用例应当包括如下几个关键字段:

　　1.用例编号(testcaseIndex)，一个软件项目可能拥有数量庞大的测试用例。应根据项目设计一个良好的用例编号体系，那么通过用例编号，便可对测试用例进行快速定位，查询时事半功倍。

　　2.用例名称(testCaseName)，用例名称的编写应使用最精简的文字，描绘出用例的全貌。编写良好的用例名称如同书籍的目录，能够帮助阅读者整理思路，定位用例。

　　3.前置条件(precondition)，复杂工作流软件自动化测试方法的研究第二章软件测试理论与技术基础前置条件指测试执行者在执行测试用例的操作步骤前，必须完成的准备工作。常见的前置条件有:系统的配置、权限的设置、数据的准备、前置工序的执行等。

　　4.测试步骤 (Teststep)，测试用例中，每个操作均可设计为一个步骤。一个测试用例由一个或多个测试步骤组成。常见可将测试步骤分为正常步骤和容错步骤。正常步骤指普通用户为了实现正常功能，进行的普遍的、正确的、系统期待的操作。正常步骤描述的操作通常在需求文档中会有明确的说明，也是程序需要实现的主要功能。

　　容错步骤指用户有意或无意进行的一些错误的、甚至于有破坏性的操作。对此类错误操作，系统应有足够的容忍性，进行一些友好的提示、阻止或处理，而不是产生异常。

　　需求文档中，通常会对正常步骤进行明确定义。因此，正常步骤是严谨的，甚至是唯一的，编写者的发挥空间非常狭小。容错流程恰恰相反。一个思维活跃、经验丰富的测试人员在编写容错步骤时，能够考虑到各类不同的容错步骤，其编写出的测试用例也是全面、广泛而又犀利的。容错流程的编写深度与广度能够很好的反映编写者的技术实力。

　　综上，一个编写良好的测试用例中应该包括两部分内容:描述准确的正常步骤，以及广泛深入的容错步骤。

　　5.步骤描述(Deseription)，步骤描述是测试步骤的主体，是测试人员执行测试时的重要阅读对象。因此，测试步骤必须表述详细，描述清晰，用语必须规范、严谨而又客观。最基本的要求是能够使其他人理解，并能正确的执行编写者期望的操作。

　　6.期望结果(〔 xpeetedRes川ts)，期望结果是执行测试时，测试者所进行比对的标尺，是一个测试步骤是否通过的标准答案。期望结果必须要保证其正确性。错误的期望结果带来的后果是严重的，不在此赘述。

　　7.实际结果 (ActualResultS)实际结果供测试人员在运行测试时填写观察到的实际结果。填写的内容同样需做到规范、严谨与客观。

　　8.测试结论 (TestResult)与实际结果类似，测试结论供测试人员运行测试时填写。若实际结果与期望结果两者一致，或虽然不一致，但在可接受范围内，则可以认为该步骤是通过的，测试结论应置为passed;若两者不一致，且无法接受，则应将结果置为Failed。

如何根据需求设计测试用例？

　　从拿到需求文档不要立马开始着手写测试用例，需要仔细推敲整理需求，画出系统级、模块内流程图，并找出各种测试点，等对需求进行了头脑风暴般的整理之后，此时已对测试系统的功能很清楚了，再着手开始写测试用例。那么编写测试用例的总体思路是什么呢？通过半年的测试用例编写经验，总结如下，如有不妥之处需改进。

　　1、整理分析需求文档

　　仔细将需求文档文档阅读一遍，记录不明白的地方及关键测试点，简单画出总体流程图。然后再来一遍，仔细分析各个模块的功能，画出模块内流程图，找出所有功能，并列出主要测试点

　　2、编写用例

　　按照不同的业务规则可将测试用例分为四部分：场景用例、系统用例、功能用例

　　场景用例：按照用户的实际操作与业务逻辑设计用例，不必涉及很复杂的操作或逻辑，把用户最常用的、正常的操作流程作为一个场景设计测试用例。

　　系统用例：是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。

　　功能用例：用于验证各功能点的业务规则，包括界面元素和各功能的业务规则验证。主要针对单个功能点。

　　第一步：场景用例（关键字：模拟用户实际操作）

　　根据画出的模块内流程图，描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景。

　　第二步：系统各角色的系统用例

　　结合画出的模块内流程图，将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分别正常流程、异常流程，分支流程，以场景的形式描述。

　　第三步：功能用例

　　描述单点功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。

　　编写用例的过程中也有一些迷茫：

　　问题1：场景法用什么方式描述比较清楚，并且后期需求改动了易维护？

　　问题2：测试用例与测试数据的关系是什么呢？如何将两者区分开来？

　　3、报表类功能模块如何编写测试用例？

　　报表类的模块基本没有业务流，不适用场景法。其实报表类模块主要验证能否依据查询条件正确查询显示数据，并保证数据的正确性。可将测试用例分为功能点测试用例和报表数据正确性验证。

  第一步：编写查询功能用例

　　可将查询功能分解为多个测试场景，分别验证各个场景的预期结果。可进行如下的分类。

　　场景1：默认条件查询结果正确；

　　场景2：修改可选择输入条件查询结果正确

　　1、进入搜索（高级搜索）页面。

　　2、逐一选择各个查询条件可选项，如：“全部”、“类别1”等，点击“搜索”，查询结果正确。

　　3、组合各个查询条件可选项，如：价格＋产品，点击“搜索”，查询结果正确。

　　场景3：修改输入条件查询结果正确

　　1、进入搜索（高级搜索）页面。

　　2、逐一输入文本域条件，模糊查询值，点击“搜索”，查询结果正确。

　　3、逐一输入文本域条件，完全匹配值，点击“搜索”，查询结果正确。

　　4、逐一输入文本域条件，中文值，点击“搜索”，查询结果正确。

　　5、逐一输入文本域条件，字母大、小写值，点击“搜索”，查询结果正确。

　　6、逐一输入文本域条件，数字类型值，点击“搜索”，查询结果正确。

　　7、逐一输入文本域条件，全角、半角值，点击“搜索”，查询结果正确。

　　8组合各个文本域查询条件，点击“搜索”，查询结果正确。

　　场景4：组合可选条件、输入条件查询结果正确

　　场景5：错误、空记录查询结果为空

　　第二步：编写其他功能点测试用例，同样可将功能点分解多个场景。

　　第三步：编写数据正确性验证测试用例

　　找出影响报表的各种数据因素、列举报表展示的各种数据，列举两者编写数据正确性验证用例。

测试用例是测试的指导文档，是保证产品的基本武器，同时也是测试人员的主要输入成果，因此保证测试用例的有效性及时时性就显得尤为重要。哪么我们如何尽可能的保证测试用例的有效性及及时性呢?

　　一、明确项目的进度及计划

　　只有明确了项目的进度及计划，我们才知道应当在何时进行测试用例的编写，何时完成测试用例的编写。以保证在测试执行时，至少已经有了第一版本的测试用例。同时也可以避免因时间仓促而草草编写的测试用例。另外，测试用例编写任务的下达必须要明确完成的时间及需要达到的目标，没有时间限定及目标的测试用例编写将是低效的。

　　二、提供产品的相关文档

　　正所谓“巧妇难为无米之炊”，要求测试人员编写测试用例，就必需要为提示人员提供尽可能多的产品相关信息，如软件需求说明书、市场同类产品信息、市场反馈的相似产品的主要问题、软件及硬件环境，甚至于开发人员联系方式及项目的主要负责人信息等。这些信息都将有力的推动测试用例的有效性。

　　三、深入理解产品的相关文档

　　在正式编写测试用例之前，需要深入理解产品的相关文档。虽然需求分析人员都具有一定的产品规划能力，但是也有可能会犯错。很难想像根据一份有瑕疵的、甚至是严重错误的需求文档编写出来的测试用例是有着多么可怕的“指导”作用。因此我们在编写测试用例之前，需要深入的理解产品的相关文档。建议可以采用会议的方案来进行，各自提出自己的见解，经过讨论会将相关的疑问提前给需求分析人员重新确认。同时将这些疑问作为BUG进行提交，记住这也是工作成果的一部份。一份完美的需求应该不存在任何的歧义或含糊的地方。

　　四、编写测试用例概要

　　在充分的理解产品的相关文档之后，就可以正式编写测试用例的概要了。之所以没有要求进行详细测试用例的编写，主要是出于编写测试用例时间的压力及评审的需要。由于测试人员的工作除了编写测试用例以外，还要进行日常的测试工作及各类报告的书写，工作量大且相对繁琐，因此应当尽量的控制编写测试用例的时间，以保证测试人员有充分的休息时间。同时对于一份详尽的、完整的测试用例而言，对于进行评审是很不经济的(试想一下，让你对1000个详尽的测试用例进行评审，你会作何感想?)。

　　测试用例的概要应该简洁明了，只需要说明验证点即可。同时在编写测试用例的概要时，尽量反映时编写测试用例的基本思路。对于100个测试用例概要进行分别评审比对10类(每类10个)的测试概要进行评审要困难得多。

　　测试用例概要可以采用如下格式：

　　//以下X个测试用例用于验证XX问题：

　　◎ 验证……

　　◎ 验证……

　　◎ 验证……

　　◎ 验证……

　　……

　　五、测试用例的评审

　　在测试用例概要编写完成之后，下一步的工作就是进行测试用例的评审。个人对产品的理解及经验始终是有限的。测试用例的评审的主要目的就是集众人的经验及认识于一体，对测试用例进入查漏补缺，使得测试用例的有效性进一步提升。

　　尽管我们采用了测试用例概要及用例概要分类的方法来简化测试用例，明确测试用例编写的思路。但是对于一些比较大型的项目，其需要评审的内容仍然是巨大的。因此我们需要在测试评审开始前做好如下准备：

　　1. 提前至少一天将需要评审的内容以邮件的形式发送给评审会议相关人员。并注明详审时间、地点及偿参与人员等。

　　2. 在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。

　　3. 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。

　　在会议进行时，会议主持者应尽量把握会议进度，尽量按时有效的完成评审工作。在评审会议结束后，应提交会议记录，会议记录应由与会人员签字确认，以说明测试用例评审是一件严肃而认真的事情。用例编写人员在会议结束后应根据会议中提出的问题及疑问，对测试用例进行优化。

　　六、细化测试用例

　　经过测试用例的评审，并对测试用例进行优化之后就可以进行测试用例的细化工作了。测试用例的细化并没有标准的形式，依各个公司的不同而有所不同，但主要都包含了操作步骤、预期结果等。测试用例的细化就是根据测试概要，对各个验证点的前置条件、操作步骤、预期结果进行完善以适应公司测试招待的要求。对于自动化测试，在测试用例细化时应提示相关的测试脚本文件。

　　好的测试用例应该是具体完全的指导性，且无二义的。为了保证测试用例指导的唯一性，在测试用例细化完成后，应与测试组长进行抽查(或者与同事之间进行相关检查)。在发现问题时应及时要求测试用例编写人员进行整改。

　　七、测试用例长期更新

　　没有任何事物是一成不变的，测试用例也是如此。在进行具体的测试之后，测试人员将对产品的需求及功能等产生最为深入的理解，对于这些有用的理解应及时将其更新至测试用例中，同时对于一些不是在测试用例中发现的BUG，可根据其对价值考虑是否需要将其更新至测试用例中。测试用例在整个产品的测试过程中应一直保挂动态的更新，甚至当项目结束以后，对于市场上反馈的有价值的问题，也应及时更新至测试用例表中，直到产品退出市场为止。