测试用例

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

在测试工作中，“直接拿到软件就测试”的做法曾经很普遍，现今这种情况应该很少了，它只属于那个特定的时期。在回答这个问题之前，我觉得有必要展现这种特殊的情况所处的背景。

无论是项目经理、业主还是监理在针对测试开发进行管理时都要涉及到这个问题，下面测试用例设计的关键点归纳如下，供大家在工作中参考。

软件测试的过程一般分为单元测试、集成测试、系统测试和验收测试几个阶段，其中单元测试、集成测试和系统测试都是软件开发商内部的测试，一般在开发商的实验室进行，而验收测试是在用户参与下的测试，一般在客户的现场环境中进行。基于这个原因，验收测试用例的设计和组织应当不同于其它测试。然而在现实情况下，由于种种原因，很多人直接将集成测试或者系统测试的用例拿来进行验收测试，这是不合适的。本文重点探讨验收测试用例的设计要点和注意事项。

如何进行有效的用例设计？作为任何一个测试用例设计者，这永远是一个非常难以回答的问题。这个问题至今为止也再不断的困扰我，人见人智。下面是我的一些个人见解，或许能对大家有一些启示。

用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。

对于测试人员而言，测试用例的设计是一件非常困难的工作，而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作，将一般应用于单元测试的路径分析方法推广到集成测试、系统测试等后续测试过程中，希望能给大家一点启示。

Test Case ID:用来标记测试用例的编号，这个编号必须是唯一的

什么样的用例是好的用例：质量属性；结构化和可测试性；配置管理。

对于测试用例进行分级，比如：Priority0： 安装系统并起系统，可以正常的login等。Priority1: 系统的一些主要功能.

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

对于一个新来的tester，给他个case和我们的软件，他就能顺利取执行case，这是最佳状态，也是我们case设计的标准，按照这个标准，我想出了以上几点要求。

没有需求文档，最头疼的问题就是不知道开发的产品应该是个什么样，要完成哪些功能，达到什么指标。下面几个步骤应该可以帮助你明确目标

一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。

一个项目在测试的过程中，不论是PM或者测分都希望随时可以了解测试的进度，以便随时掌控项目的时间走向。而测试的过程中测试人员所进行就是测试用例的执行，那么用例执行的程度显然可以直观的反应出项目在测试阶段的进度情况。

作者参考了原文，然后经过整理，融汇了作者的Excel技巧，把它整理了出来，分析了表的生成过程，比原来的设计有一定的易学易用性。

回归测试一项很重要、但也很费时且重复性很多的活动，同时由于该阶段处于后期，也许错误都被正确的修复好了、也许没有引入新缺陷、执行了很多测试用例都没有再发现新问题，这当然是我们理想的状态，但也容易给测试人员带来疲惫感，所以我认为在回归测试中引用自动化是一项不错的选择，这里的自动化主要针对4中描述的软件核心用例，对于这些每一轮测试都必须执行的用例使用自动化，可以提高不少的效率！