软件测试中的测试用例

谈谈测试用例         测试用例

  测试用例分为两种，一种是功能测试用例，一种是业务流程用例（Business Test Case）。功能测试用例关注的更多的是这个功能是如何实现的，比如添加，删除这样的用例，还包括这个功能的UI检查，关联检查等。这种用例不强调业务之间的流转或者数据的流转，关注的是这个功能本身的正确性。这种用例一般是最容易写的，因为步骤不会很多，只需要把你的详细的check点写出来就好了。这种用例用到的黑盒测试方法一般有边界值，等价类等等。业务流程用例关注更多的是模块之间的交互，入口对应模块的实现。一般一个业务流程用例就包含了一个完整的操作流程，也是模拟用户操作最多的一种检查用例。这里会有很多分支或者数据的流转，如果分支过多或者入口过多，可以用正交分类法去掉一些。这种用例需要参考的文档是概要设计和详细设计。为什么是这两个文档呢，因为这里可以看到系统的架构，业务的交互以及数据的流转，所以对这种用例的设计很有帮助。这种用例用到的黑盒测试方法是场景法。

一、测试用例设计方法
1.1.
白盒测试的测试用例设计（逻辑覆盖法）
这种方法是从程序内部的逻辑结构出发选取测试用例，因此要求测试用例设计人员对程序的逻辑结构十分清楚，甚至应掌握源程序的所有细节。
1.1.1.
语句覆盖
设计若干测试用例，运行被测试程序，使得每个可执行语句至少执行一次。
1.1.2.
判断覆盖
设计若干测试用例，运行被测试程序，使得程序中每个判断的真值分支和假值分支至少经历一次。对象是每个判断。
1.1.3.
条件覆盖
设计测试用例，运行被测试程序，使得程序中每个判断中的每个条件的可能取值情况至少满足一次。对象是每个条件。
1.1.4.
判断—条件覆盖
设计测试用例，运行被测试程序，使得程序的每个判断中的每个条件的所有可能取值组合至少出现一次，并且使每个判断本身的判定结果也至少出现一次。
1.1.5.
路径覆盖
设计测试用例，覆盖程序中所有的可能路径。
1.2.
黑盒测试的测试用例设计
1.2.1.
等价类划分
是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.
该方法是一种重要的,常用的黑盒测试用例设计方法.
该种设计方法分为划分等价类表和选取测试用例两步。
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
有效等价类:是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
无效等价类是指对于程序的规格说明书来说不合理的、无意义的输入数据构成的集合.利用无效等价类可检查程序中功能和性能的实现是否有不符合规格说明书的地方。.
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
等价类划分的原则：
（1）
如果输入条件规定了取值范围或值得个数，则可以确立一个有效等价类和两个无效等价类。如：1 < x < 99，则1 < x < 99是有效等价类，而x > = 99 和 x < = 1 就是两个无效等价类；
（2）
如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这是可以确立一个有效等价类和一个无效等价类。如：必须为正整数，则取正整数是有效等价类，而非正整数的是无效等价类；
（3）
如果输入条件是一个布尔值，则可以确定一个有效等价类和一个无效等价类，则满足条件的为有效等价类，而不满足条件的为无效等价类；
（4）
如果规定了输入数据的一组值(假定n个)，并且程序要对每个输入值分别进行处理。这样可以为每一个输入值确立一个有效等价类，此外可以确立针对这组值确立一个无效等价类，如：{1、5、10、20}，则取1、5、10、20分别建立有效等价类，而非1、5、10、20的值是无效等价类；
（5）
如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。如：则满足规则的为有效等价类，则不满足规则的分别建立无效等价类；
（6）
如果在确知已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步分成更小的等价类。
测试用例设计与选择：
（1）
为每一个等价类规定一个唯一的编号。
（2）
设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
（3）
设计一个新的测试用例，使其近覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
1.2.2.
边界值分析
是对等价划分方法的补充。
（1）
边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入等价类与输出等价类的边界，就是应着重测试的边界情况，应当选取正好等于、刚刚大于、或刚刚小于边界的值作为测试数据。
（2）
边界值分析方法选择测试用例的原则在很多方面与等价划分方法类似。
A.如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，及刚刚超越这个范围边界的值作为测试输入数据。
B.如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1，比最小个数少1的数做为测试数据。
C.根据规格说明书的每个输出条件，使用前面的原则A。
D.根据规格说明书的每个输出条件，使用前面的原则B。
E.如果程序的规格说明书给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
F.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界值作为测试用例。
1.2.3.

错误推测法
错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

二、当前国内软件企业测试流程不规范的原因分析

1） 从事物的发展规律看，软件测试行业在我国还是新兴行业，目前还处于起步和探索期，虽然国外的同行业发展到了一定阶段，但事实上他们也在不断的否定自我并探索着更成熟的方法、寻求着更有效的方案；而国内的测试行业发展期不过10来年，所谓的测试管理流程不规范，也就情有可原了。

    2） 从企业个体角度讲，测试部门的整顿和加强，按照企业自身发展的优先层次，还没有被纳入优先解决的程度，开拓市场、签订定单才是首要问题，也是维系企业生存发展的命脉。当然国内很多优秀的大中型软件公司的测试部门相对完善，如神州数码、用友、联想等，他们和大型跨国软件公司的合作，也从中汲取了宝贵的管理经验。

    3） 还有一个普遍存在的问题。近几年国内软件企业为了加强企业的竞争优势和名气提升，通常大搞特搞ISO/CMM认证；笔者也很支持这么做，但更关注的是通过这些认证后的企业有多少真正按照那些规范、设计的标准在后续的测试或软件开发管理工作中着手开展下去呢？社会上流传着这样的话：任何认证到中国，最后都免不了砸牌儿！笔者读书时很多高校搞的MCSE认证，有培训机构明目张胆声称\"百分百通过率\"！当年也有专门媒体报道此事。听到这样的话，我们都会寒心，这里真心希望我们的软件企业通过ISO/CMM后真正为企业的内部软件开发流程带来一点新生的曙光。

    4） 最后一个原因，我想是企业内部测试管理人员和技术人员技能的不足，还有自身工作态度的不够端正。有了再好的规范标准，没人遵守不行！没人实施不行！应该说，很多中小软件企业的高层都或多或少的逐渐意识到软件测试的重要性和必要性，以及它的标准化、流程化改革的紧迫性，但也有很多的工程师、技术人员并不理会这套，常常在实际工作中投机取巧；也有很多测试管理人员后天的经验不足、技能不够，对公司测试管理工作考虑不到位，和开发工程师交流不充分，和上层领导反映不及时等等。

    总之，任何问题的出现都不是单方面的原因，从宏观的社会形势到微观的企业个人，都有无可推卸的责任；正因为如此，解决问题也要对症下药，如何完善软件测试流程，就要从小处出发；本文不可能将软件测试流程优化的话题阐述的面面俱到，因此只从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。

原文转自：http://www.ltesting.net