[原创]测试用例设计之"正面测试与和负面测试"

[原创]测试用例设计之"正面测试与和负面测试" 

 

       通常在测试用例设计过程中，测试用例根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变；所以测试用例设计过程中为每个测试需求至少编写两个测试用例；其中 一个测试用例用于证明该需求已经满足，通常称作“正面测试用例”，另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。更为简单的表述为，“正面测试用例”它是测试系统是否完成了它应该完成的工作；负面测试就是测试系统是否不执行不应该完成的操作完成的工作。

     所以在测试用例设计过程中，需要从正面和负面测试两个角度去考虑问题，以下是非常有名的Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。
    后面内容引自KiKI《10大负面测试用例》内容，大家可以更实际的感受什么是负面测试用例的内容

 

负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的10大负面测试用例。
1.植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
【Kiki补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格）。单引号，逗号，/，<，>（对于web的应用程序）都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。
 
2.必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
【Kiki补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。
 
3.字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等）
【Kiki补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正确的处理。
 
4.字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
【Kiki补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。
 
5.数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。
 
6.数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。
【Kiki补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。
不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。
 
7.日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。
【Kiki补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。
 
8。日期的有效性。对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。
 
9。web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。
 
10.性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕（列出信息的屏幕，add/update/delete数据的屏幕等等）速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。

     后面内容引自KiKI《获取负面测试技术》内容，大家可以从中了解更多的内容：

 

 

--- 原著James Lyndsay《A Positive View of Negative Testing》
---Kiki翻译于2007/121/30
 
1.         负面测试的目的
负面测试在BS7925-1中的英国标准定义是采用Beizer的定义，其定义负面测试为“旨在说明软件不能工作的测试”（原文：Testing aimed at showing software does not work）。它可以带出一系列补充性的和竞争性的目的。
•发现导致重大失效、崩溃、破坏和安全漏洞的故障
•观察和度量系统对外界问题的响应
•揭露软件的弱点和开发的潜力
虽然有个一个公正的定义，但是它离被普遍接受还差的很远。负面测试是一个紧跟着被重新定义的术语，有时甚至是各小组的。一个常见的方法，其实践和英国标准定义不同的是它包括旨在使用专门对付失效的功能的测试。
• 输入验证，拒绝和重新请求的功能（人工输入和外界系统）
• 内部数据验证和拒绝
• 应付缺乏的，缓慢的或坏掉的外界资源
• 错误处理功能，例如消息，日志，监视功能
• 恢复功能，例如故障恢复，回滚和恢复
 
2.         获取测试用例的技术
负面测试不是一种测试设计技术，说是一种方法或分类更加合适。使用许多正式的测试设计技术来获取那些能够被划分为‘负面测试’的测试是很有可能。这一节详述了各种各样的知名技术的应用。
• 边界值分析和等价类划分Boundary Value Analysis and Equivalence Class Partitioning
• 状态转换测试State Transition testing
• 逆着已知的约束测试Test against known constraints
• 故障模式和结果分析Failure Mode and Effects analysis
• 并发Concurrency
• 用例和误用的用例Use cases and mis-use cases
 
2.1.   边界值分析和等价类划分
有两种基于输入和输出数据和系统行为期望的技术。
边界值分析（BVA：Boundary Value Analysis）利用关于预知系统行为转换位置的边界的需求和设计来检查那些能够带出一连贯范围数值的数据元素。
这个方法用于产生三个数值－一个就是边界本身，另外两个在前者的两边（尽可能的和数字相接近）。如果边界在有效和无效范围之间，使用无效数值的测试用例将成为一个负面测试用例。例如，使用66在只接受从18～65数值的年龄字段。 
等价类划分（ECP：Equivalence Class Partitioning）着眼于边界之间的范围。给出的等价类中的每个成员应该在一个已知测试的环境里，使系统做同样的事情－这样测试员不必要测试在等价类中每一个数值。无效输入数据的范围可以被看成为负面测试－例如，一个年龄字段可能被期望用相同的方法拒绝所有的负数。
ECP一般被延伸到包括非连续数值的集合，胜于连续的数值范围。要注意一些输入可能看上去等价，但是实际上出现很多不同的行为。例如，一个简单web的表单的输入是为空或者太长时可能会被拒绝，但是控制字符的正确组合可能危害潜在web服务器的安全。
 
2.2.   状态转换测试
假设有一个状态转换图或者一个与其等价的理解，那么就很容易获得可以明确地检查不可到达的状态是否真的不可到达的测试用例。与这种方法相同的变种称为n-switch 测试，在一套已知的转换之后，那些不可到达的状态仍然是不可到达吗？图形工具，例如Compendium-TA [4]能够帮助你获得这样的测试。
 
2.3.   逆着已知的约束测试
大多数的系统有明确的和含蓄的限制和约束。如同需求一样对待这些约束（参加Robinson+Robinson, [5])）就可以得到各种负面测试。例如：
• “The site is designed to be viewed with Internet Explorer 4.5 or later” – 负面测试可以使用IE3.0或Netscape.
• “No more than five users will use the system at the same time” –负面测试可以尝试6个，然后8。
概括来说，测试包括度量和观察系统的行为胜于直接逆着期望结果测试。这只能在系统的操作参数之外工作时被使用，并且这种观察可能导致对系统的进一步了解。
 
2.4.   故障模式和结果分析
从对潜在的技术，实现和已知故障的分析来预见系统特有的故障是很有可能的。这种分析是观察在故障条件下系统行为的测试基础。捕获和文档化这种信息是非常重要的－特别是如果他们允许诊断数据和环境。对于那些监视他们系统并且拥有在系统被使用时（例如银行，电话公司）可以采取行动的技术专家的组织而言，这些文档通常是测试的必要输出。 另一方面，对于更广泛的分布式软件包来说，这些信息也可以成为FAQ或故障诊断指南的一部分。
这些测试可能不可能在没有一个有效的测试工具或应用驱动下执行。这样的工具通常是自定制的，并且可能需要在代码的已提交版本里运行。
然而，象Canned HEAT和Holodeck (都出自the Florida Institute of Technology, [6])这样的工具允许将普通性故障引入到运行在Windows的软件中。
6.4.1. 故障家族
有很多来源可以帮助你开发故障模式的家族。既有故障的根本原因分析，系统设计文档，基础设施特有问题的知识能够帮助识别故障模式，并且因此为获取测试提供来源。
以下列表虽不详尽，但或许可以帮助引发更多的关于可能的故障想法。
• 外部资源：反应迟钝或缓慢的，莫明其妙或不恰当的反应。
• 协处理器故障：独特的间断处理器，多任务和递归
• 并发使用：资源锁定，请求已拒绝的锁定，死锁，锁定响应延迟
• 牺牲处理器Sacrificial processes：允许失败的处理器并且用可控方式恢复
• 文件系统：文件不能被找到，打开，读，写，权限变更，文件系统识别介质错误，介质移除，介质装满
• 网络：网络中断，网络忙碌/缓慢，传输段丢失、损坏、无序，处理器之间的对话被中断 
• 内存：不足以给请求的分配，碎片
• 已达到的限制：排队，licences，线程，连接，数组大小，资源分配
 
2.5.   并发
测试对资源的并发使用可以是一个非常富有成效的找bug方法。初始分析包括鉴别也许会尝试同时使用的数据，数据库条目，文件、连接和超过一个处理器的硬件。通过允许测试者在系统之前利用资源，简单，定制的工具可能有些帮助, 并且在他们选择的时候发布它。测试也应该检查第二个请求者最终得到了资源。更加复杂的测试将着眼于二个以上的请求, 排队, 超时和死锁。
 
2.6.   用例和误用的用例
用例，在实践中趋向于处理系统的‘happy path’。各种错误输入的覆盖，拒绝的循环和部分转换通常是很稀少的。‘误用的用例’术语，虽然不是偏僻的标准，但是能够帮助明确地识别和区分他们。执行这些路径地用例可以通过图解期望结果正常范围外的用户的活动来帮助提高设计，并且允许一个正式的方法来测试选择和覆盖 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/imlogic/archive/2007/12/30/2004400.aspx