关于评价测试用例好坏的讨论

摘自测试时代论坛

Leveret :

    现在大家在写测试用例的时候每个人都有自己的特点，但是什么样的一个测试用例才是一个比较好的用例，这是一个比较真实的现象，有这样几个问题大家可以交流一下自己的心得（如果愿意交流的朋友）：系统测试的用例要如何设计才能验证需求？有时候不知道结果的情况下如何预测结果，测试用例应该在不同的阶段下实施的时候应该是独立的。一般在设计测试用例的时候要包括合理输入，不合理输入，预测结果，一般常用的测试用例的设计主要用到：等价类划分，边界值分析法，错误推测法，但是这些都是理论方面的概念，我们在实际设计当中往往并不是按照这些去做的。大家在设计测试用例的时候应该都有自己的心得，如果愿意，可以把自己的观点分享出来大家来讨论。

Seanhe :

    我感觉测试用例没有什么好坏之分：）当初的那句话，能发现最多错误的，发现至今为止没有发现的bug的用例就是好的用例，我认为是错误的。
因为，测试不是解决问题，测试用例的好坏不是指单个的用例，而是用例的覆盖度，单个用例再好，所有用例的覆盖度不够，那测试工作还是失败的。所以测试的关键不是用例设计，而是测试范围的圈定，使用的方法，用例的设计只是自然而然的事情。
    再说说一开始的用例怎么写，开始肯定有很多不清楚所以用例中很多的内容无法填写，所以我们应该默认用例的书写是个迭代的过程，不同阶段完成不同的内容，执行之前全部完成就可以了。

Leveret :

    用例的覆盖率也应该是从单个开始的，而且很多时候发现用例在很多输入输出方面的设计基本都是雷同的，至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？根据测试的类别来考虑还是根据需求方面呢？不过对你所说的用例的书写的迭代过程比较赞同，我们一般测试正式开始之前会对用例有一个评审过程，明白了这个道理之后我想应该会比较轻松的。对设计测试用例的同行来说。欢迎大家分享自己的观点.

Zhybing :

    测试用例的好坏，主要看本测试用例是否满足了测试内容的要求，满足了测试内容要求的测试用例就是好的，不满足测试内容要求的测试用例就是不好的.

Leveret :

    那测试内容是在测试计划里面反映的？按照你的说法。仅仅只是满足测试内容吗？你是这么认为的？

Jackei :

    下面列举了我的一些看法：
        01.对于“有时候不知道结果的情况下如何预测结果”，个人觉得这个问题比较明确，如果需求无法明确，或者说需求不够明确，则对于该需求的测试用例设计应该推迟，并及时同需求人员进行交流，尽快将需求准确的定义下来。
        02.一般在系统测试阶段考虑的测试方法是黑盒测试，这时对于测试用例的设计如何使用那几种方法呢？个人认为可以先使用等价划分的方法划分出等价类，然后使用边界分析法确定下测试数据，最后通过自己以往的厕所经验或者其他的经验来进行错误推测，增补一部分用例。对于这个问题，个人对于现在市面上的很多测试书籍都有负面的看法，很多书提到的一些用例设计的例子都是用windows计算器或者其他单纯用几个数字来作为例子——比如输入域是0-100，让你设计用例。很多时候我们在进行用例设计时看到的并不是很明显的数字，这些东西都是隐含在业务规则中的，感觉我们现在很多初学测试的朋友这种分析业务规则的能力还是比较欠缺，看不到深层的测试需求。当然这些方法也就应用的很有限了。
        03.对于“测试用例应该在不同的阶段下实施的时候应该是独立的”，我也比较赞成。个人认为关键要搞清楚测试用例的作用。作为开发过程，是先有需求人员进行需求的收集，然后是系统分析员对需求整理分析，形成用例或者软件需求规格说明书，之后由系统架构人员进行架构设计，开发人员完成详细设计和编码工作——当然这也未必是一成不变的，但是大体的任务都是这么多。同样，我们看一下RUP中对于测试工作的流程介绍，为什么要把测试设计同测试实现以及测试执行明确的区分开来呢？因为测试工作现在同开发工作已经越来越相似，包括测试需求的整理、测试用例的设计以及测试用例的实现。我们现在很多同行所在的公司可能从人力资源或者从公司的流程上无法保证完全按照这个规范来操作，但是我们可以从RUP中明确测试用例的作用。用例本身就是用来指导实现的，用例实现的时候可以是自动化脚本也可以是手工操作的具体步骤。测试用例是可以同具体的应用程序实现完全独立的，可以不受应用程序具体实现变动的影响。至于为什么我将在下面说明。
       04.对于“很多时候发现用例在很多输入输出方面的设计基本都是雷同的”，我觉得这个就可以考虑测试用例的“复用”。其实雷同也是正常的。
       05.下面将阐述我个人对于测试用例设计工作的一些看法。
    我很赞成 seanhe 对于测试用例迭代开发的观点，现实中我们也是这样考虑的。
    测试用例不会平白无故的被设计出来，它是有目的和前提的。个人认为测试用例是用来指导具体测试实现的，包括自动化脚本的实现和手工测试步骤的实现。对于测试用例对测试需求的覆盖，个人认为不是测试用例编写的目的，而是对测试工作的要求——是要求测试用例设计人员的阶段性工作的结果必须符合一定的要求的。测试用例本身是无法保证覆盖需求的。
    那么说到了测试需求，这里顺便说说测试需求的确定。leveret 也问到了这个问题——“至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？”个人认为测试范围的圈定也就是测试需求的确定。
    对于一个产品来说，它的开发和测试都不是一次性的，随着开发版本的迭代，测试工作也将继续进行下去，同时，我们对每个版本的测试范围都是不同的。注意，这里有一个关键，也就是测试范围圈定的出发点——软件需求的确定。那么怎样来明确软件的需求呢？——版本。如果希望工作的进度和内容可以明确的定义下来，就首先要考虑版本的确定——软件需求的版本确定。
    通过软件需求的版本控制，可以明确每个不同版本的产品中所实现的特性，哪些特性将在以后的版本中实现。这里重点提到的是对于需求也需要使用版本的概念来进行管理。
    既然某个版本的软件需求已经确定，那么接下来的开发工作就可以在这个需求版本划定的范围内开展。
    测试需求是什么呢？个人认为就是需要测试的内容，它的来源有很多方面。
    1.在需求阶段，软件需求规格说明书和用例中对于软件的描述、业务规则的描述就可以整理出我们最早的测试需求，这部分测试需求将完全来源于软件需求，是当前阶段测试工作的一个基础。
    不过大家要看到，我们的测试工作从现在开始。
    这个时期我们有一个非常非常重要的工作，我们将尝试着进行需求文档的检查。这里，对于需求文档的检查主要是两个方面：
    （1）检查需求文档描述的正确性，愚以为测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务制度熟悉，在检查需求文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符合，那么是否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。
    （2）检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——我得意思是说保证需求是可以完全为测试工作服务的。再说的具体一点，要保证所有的软件需求都是可以用某种方法来明确的判断是否符合要求的。如果对于某个需求，无法获得一个明确的判断标准，则应该请需求人员对需求进行修改或补充——一个缺乏准确定义的需求，我们可以认为开发人员也无法准确的实现或者实现一个错误的需求，如果在应用程序交付测试时才发现这个问题，带来的后果就因项目而异了。
    2.随着开发工作的开展，开发部门的架构设计以及详细设计也将陆续提交，这时候，我们可以根据设计文档来对原来的需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有符合软件需求规格说明书或用例中已经定义的部分才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一个为准，然后调整测试需求。这部分工作其实已经包含了对设计的检查，我们将继续努力尽早的发现缺陷出现的征兆。
    3.在应用程序交付后，测试部门开始执行测试。这时很有可能通过一些我们根据测试需求设计的测试用例所没有包含的方法会找到一些缺陷，那么，这部分方法我们也应该整理到测试需求中。
    OK，相信说到这里，各位看客也应该可以理解了我的观点。对于一个持续发展的公司或者持续开发的产品，它的所有东西都是要不断积累的。对于测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间也是不断迭代的。
    既然明确了测试需求，测试用例的考虑也就变成 seanhe 所说的那种自然而然的事情了。我们可以根据不同阶段已经确定下来的那些测试需求来进行测试用例的设计，然后随着开发过程的继续，在测试需求增补或修改后不断的调整测试用例。如果我们从产品的整个生命周期来看，就会发现其实根本没有测试工作终结而测试需求和测试用例维护结束的时候，因为一个版本的结束就是下一个版本的开始。从这个大的范围来看，我们的测试需求和测试用例将永远的不断迭代下去。
    啊，今天心情好，比原来那个回复又多写了很多，希望对所有的朋友多可以有些帮助。不过好像有些跑题，本来题目是“关于评价测试用例的好坏”，我还是要给出答案的：个人认为测试用例的好坏可以有几个方面。第一，是否独立于具体的实现；第二，是否可以比较方便的指导实现工作；第三，是否比较容易维护。而其他方面，个人认为则可以看做是“关于评价测试用例设计人员工作的好坏”的一些标准。
    以上均为个人看法，仅供参考。如果朋友们希望就这些问题展开讨论，可以发送email到我的邮箱：[e-mail] 。

Jackei :

    我又想到了一点评价测试用例好坏的因素：
    01.易用性：是否方便使用，比如是否可以随便哪个人都可以拿来简单的看看就知道如何根据用例进行测试；
    02.易维护性：是否方便维护，特别是当需求或者设计发生变化的时候，是否付出较少的成本就可以完成维护工作；
    03.有效性：是否可以保证一个用例在整个产品的一个相对较长的生命周期中可以反复使用，保证有效性。
抛砖引玉，望大家继续补充。