十大异常测试用例（转载）

     此文乃转载，原名为《十大负面测试用例》，我以为负面测试不如异常测试来的好理解，本身改了改。恩，先说一说我本身的心得。前八个用例都是原来已经在个人思惟体系中的，也是测试中经常覆盖的部分。第九个会话测试，有这个概念，可是没有很系统的作，之后要在工做中尽可能的融合进来。第十个，性能改变测试，原文表述的有点罗嗦，我本身理解以后对此的总结是对增、删、改、查等操做，从用户输入、点击触发了请求以后，到响应、输出这样的一个时间，或者称为速度，须要有一套综合测量体系。并对每次的版本进行统计，纵向比较，以发现由此可能形成的潜在性能问题。这在我以前的测试中也会涵盖一部分，好比响应时间一会儿明显超长了以后，会做为一个BUG来提出，可是纵向的版本比较，这个是个人盲点之一，须要改进。

原文以下：

负面测试（Negative testing）是相对于正面测试（Positive testing）而言，它们也是测试设计时的两个很是重要的划分。具体区别参考下表：

 

正面测试	负面测试
测试系统是否完成了它应该完成的工做	测试系统是否不执行它不该该完成的操做
就象一个毕恭毕敬的小学生，老师叫我作什么，我就作什么	就象一个调皮捣蛋的孩子，你叫我这样作，我偏不这样作，并且和你对着干 开发人员也是最讨厌修改此类bug的。
主要根据需求，功能说明书，设计文档等相关参考文档来执行测试	主要根据错误猜想，逆向思惟来测试系统，必定程序上的的依赖测试人员的经验积累。 执行负面测试时，不仅仅要测试系统是否处理了用户的异常操做，还要检查系统对于这些异常操做是否给予了正确的错误提示。它是系统对用户进行继续正确操做的指引。

 

简言之负面测试的三部曲就是：

1． 检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；
2． 测试系统是否处理了用户的异常操做；
3． 检查系统的错误提示是否清晰且充分。
 
        如下是Steve Miller的《Top 10 Negative Test Cases》，归纳性的提到了一些作负面测试时常常须要注意的测试。
 
 负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工做的一部分。如下就是在设计测试工做量时你应该考虑的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补充】从第一条到第八条是咱们在测试字段时经常须要作的测试，通常的测试人员都不陌生。第九条在测试web应用程序中会做为检查应用程序的安全性而作的一项测试。而第十条估计不少公司都不会将它考虑到测试的范畴中，通常最多也就是在测试用例中添加校验某一个操做是否在系统容许的响应时间里，不多去作这样的比较，除了一些有针对性的性能测试。 

 

https://blog.csdn.net/java_user/article/details/2095901