Top 10 Negative Test Cases

step365he

Top 10 Negative Test Cases

Negative test cases are designed to test the software in ways it was not intended to be used, and should be a part of your testing effort.  Below are the top 10 negative test cases you should consider when designing your test effort:

• Embedded Single Quote         - Most SQL based database systems have issues when users store information         that contain a single quote (e.g. John's car).  For each screen that         accepts alphanumeric data entry, try entering text that contains one or more         single quotes.
• Required Data Entry -         Your functional specification should clearly indicate fields that require         data entry on screens.  Test each field on the screen that has been         indicated as being required to ensure it forces you to enter data in the         field.
• Field Type Test - Your         functional specification should clearly indicate fields that require         specific data entry requirements (date fields, numeric fields, phone         numbers, zip codes, etc).  Test each field on the screen that has been         indicated as having special types to ensure it forces you to enter data in         the correct format based on the field type (numeric fields should not allow         alphabetic or special characters, date fields should require a valid date,         etc).
• Field Size Test - Your         functional specification should clearly indicate the number of characters         you can enter into a field (for example, the first name must be 50 or less         characters).  Write test cases to ensure that you can only enter the         specified number of characters. Preventing the user from entering more         characters than is allowed is more elegant than giving an error message         after they have already entered too many characters.
• Numeric Bounds Test -         For numeric fields, it is important to test for lower and upper         bounds. For example, if you are calculating interest charged to an account,         you would never have a negative interest amount applied to an account that         earns interest, therefore, you should try testing it with a negative number.           Likewise, if your functional specification requires that a field be in a         specific range (e.g. from 10 to 50), you should try entering 9 or 51, it         should fail with a graceful message.
• Numeric Limits Test -         Most database systems and programming languages allow numeric items         to be identified as integers or long integers.  Normally, an integer         has a range of -32,767 to 32,767 and long integers can range from
          -2,147,483,648 to 2,147,483,647.  For numeric data entry that do not         have specified bounds limits, work with these limits to ensure that it does         not get an numeric overflow error.
• Date         Bounds Test - For date fields, it is important to test for lower         and upper bounds. For example, if you are checking a birth date field, it is         probably a good bet that the person's birth date is no older than 150 years         ago.  Likewise, their birth date should not be a date in the future.
• Date         Validity - For date fields, it is important to ensure that         invalid dates are not allowed (04/31/2007 is an invalid date).  Your         test cases should also check for leap years (every 4th and 400th year is a         leap year).
• Web Session Testing -         Many web applications rely on the browser session to keep track of         the person logged in, settings for the application, etc.  Most screens         in a web application are not designed to be launched without first logging         in.   Create test cases to launch web pages within the application         without first logging in.  The web application should ensure it has a         valid logged in session before rendering pages within the application.
• Performance Changes -         As you release new versions of your product, you should have a set of         performance tests that you run that identify the speed of your screens         (screens that list information, screens that add/update/delete data, etc).           Your test suite should include test cases that compare the prior release         performance statistics to the current release.  This can aid in         identifying potential performance problems that will be manifested with code         changes to the current release.

上一篇：web翻页测试用例设计思路
下一篇：鄙人做性能测试的一点点总结和疑问

step365he

负面测试（Negative testing）是相对于正面测试（Positive testing）而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作；而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么；而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。
      正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，而负面测试则主要根据错误猜测，逆向思维来测试系统，一定程序上的的依赖测试人员的经验积累。
      执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。
简言之负面测试的三部曲就是：
1． 检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；
2． 测试系统是否处理了用户的异常操作；
3． 检查系统的错误提示是否清晰且充分。

以下是Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。
负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的10大负面测试用例。

1、植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
【补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格），单引号，逗号，/，<，>（对于web的应用程序）都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。

2、必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
【补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。

3、字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等）
【补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能为数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正确的处理。

4、字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
【补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。

5、数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。

6、数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从 -2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。
【补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。

7、日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。
【补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。对于输入的日期范围，“起始日期”要小于“结束日期”。

8、日期的有效性。对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。

9、web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。

10、性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕（列出信息的屏幕，add/update/delete数据的屏幕等等）速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。
【补充】从第一条到第八条是我们在测试字段时常常需要做的测试，一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。

是从一个站点找到的译文
http://www.51testing.com/?88979/ ... e_itemid_84881.html

chenxin9821

还是英文看着舒服...

nini

英文不够好，不解其中精髓，不过这个整理还算不错。
话说这里的新帖子实在太少。灌水又不好，往往可以看见一天有一两个人集中回三五个贴，可怜的很

nini

说他是负面测试是一种习惯称呼，是和正常业务相反或不太可能在正常业务中出现的，理论上测试用例没有正面负面的说法，从基本流或备选流的概念来看，所谓的负面或者叫奇点、极限测试用例都是一种相对于基本流来说的备选流。
这些测试是不是一定要做，要看实际需求而定的，我刚做测试的时候也喜欢看这些动作，后来做的时间久了就知道测试要关注的是需求，这些在需求评审时就应该确定下来的。

比如安全性，没有绝对的安全或者绝对的不安全，如果不实现确定安全层级以及安全策略，等着测试阶段来讨论能不能这样做，项目就岌岌可危了。

所以，这篇文章的例子都很不错，拿来做如入门案例可行，但忽略了需求的重要性，先确定需求，然后在设计中体现，最终通过测试来检查代码开发中有没有把前面的贯彻进去。这是一个有效的软件工程逻辑。

曾经有常用的测试工程师面试问题：测试是发现缺陷，还是验证需求，其实，需求和缺陷是同一个事物的两面，做对了就是符合需求，做错了就是缺陷。

一个浅显的道理，测试人员越早介入测试越好，但很多公司引进测试技术、测试人才，但这方面进步不多。

chenxin9821

4# nini

1. 受金融危机的影响，测试方面的部分朋友现在的工作热情和学习热情受到了严重的阻碍，据我所知，已经有部分转行的了，而对于测试新手这更是一个持续较久的迷茫期和考验期...

2. 尽管现实是残酷的，但是我们顽强的群主仍旧继续坚持战斗。身为版主，我也被其百挫不死的精神鼓舞着并继续发挥着自己萤火虫般的余热。

3. 真诚的期盼您能够加入到我们的团队，为指导那些陷入迷茫的战友们贡献自己的一份宝贵经验。nini~

天堂海

还不错哦，如果再能多分享一些就perfect了！

复古

路过的帮顶

狐狸精

不错 支持一个了

风云神龙魂

看帖要回，回帖才健康，在踩踩，楼主辛苦了！

爱情颠倒定律

很有借鉴意义，先收藏了，谢谢楼主。

心慌ゞ

看起来好像不错的样子

晓野

好帖是需要鼓励的~

依赖式习惯丶

这么强,支持楼主，佩服

傻痴o

打酱油的人拉，顺便赚点金币