负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么;而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。

　　正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，而负面测试则主要根据错误猜测，逆向思维来测试系统，一定程序上的的依赖测试人员的经验积累。

　　执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。

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

　　1、检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束;

　　2、测试系统是否处理了用户的异常操作;

　　3、检查系统的错误提示是否清晰且充分。

　　以下是Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。

　　负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的十大负面测试用例。

　　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应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。

　如何提高SQL Server数据库的性能，该从哪里入手呢?笔者认为，该遵循从外到内的顺序，来改善数据库的运行性能。如下图：

　　

　　第一层：网络环境。

　　到企业碰到数据库反映速度比较慢时，首先想到的是是否是网络环境所造成的。而不是一开始就想着如何去提高数据库的性能。这是很多数据库管理员的一个误区。因为当网络环境比较恶劣时，你就算再怎么去改善数据库性能，也是枉然。

　　如以前有个客户，向笔者反映数据库响应时间比较长，让笔者给他们一个提高数据库性能的解决方案。那时，笔者感到很奇怪。因为据笔者所知，这家客户数据库的记录量并不是很大。而且，他们配置的数据库服务器硬件很不错。笔者为此还特意跑到他们企业去查看问题的原因。一看原来是网络环境所造成的。这家企业的客户机有200多台，而且都是利用集线器进行连接。这就导致企业内部网络广播泛滥，网络拥塞。而且由于没有部署企业级的杀毒软件，网络内部客户机存在病毒，掠夺了一定的带宽。不仅数据库系统响应速度比较慢，而且其他应用软件，如邮箱系统，速度也不理想。

　　在这种情况下，即使再花十倍、百倍力气去提升SQL Server数据库的性能，也是竹篮子打水一场空。因为现在数据库服务器的性能瓶颈根本不在于数据库本身，而在于企业的网络环境。若网络环境没有得到有效改善，则SQL Server数据库性能是提高不上去的。

　　为此，笔者建议这家企业，想跟他们的网络管理员谈谈，看看如何改善企业的网络环境，减少广播包和网络冲突;并且有效清除局域网内的病毒、木马等等。三个月后，我再去回访这家客户的时候，他们反映数据库性能有了很大的提高。而且其他应用软件，性能也有所改善。

　　所以，当企业遇到数据库性能突然降低的时候，第一个反应就是查看网络环境，看看其实否有恶化。只有如此，才可以少走冤枉路。

　　第二层：服务器配置。

　　这里指的服务器配置，主要是讲数据库服务器的硬件配置以及周边配套。虽然说，提高数据库的硬件配置，需要企业付出一定的代价。但是，这往往是一个比较简便的方法。比起优化SQL语句来说，其要简单的多。

　　如企业可以通过增加硬盘的数量来改善数据库的性能。在实际工作中，硬盘输入输出瓶颈经常被数据库管理员所忽视。其实，到并发访问比较多的时候，硬盘输入输出往往是数据库性能的一个主要瓶颈之一。此时，若数据库管理员可以增加几个硬盘，通过磁盘阵列来分散磁盘的压力，无疑是提高数据库性能的一个捷径。

　　如增加服务器的内存或者CPU。当数据库管理员发现数据库性能的不理想是由内存或者CPU所造成的，此时，任何的改善数据库服务器本身的措施都将一物用处。所以，有些数据库管理专家，把改善服务器配置当作数据库性能调整的一个先决条件。

　　如解决部署在同一个数据库服务器上的资源争用问题。虽然我们多次强调，要为数据库专门部署一个服务器。但是，不少企业为了降低信息化的成本，往往把数据库服务器跟应用服务器放在同一个服务器中。这就会导致不同服务器之间的资源争用问题。如把文件服务器跟数据服务器部署在同一个服务器中，当对文件服务器进行备份时，数据库性能就会有明显的下降。所以，在数据库性能发现周期性的变化时，就要考虑是否因为服务器上不同应用对资源的争夺所造成的。

　　故，笔者建议，改善数据库性能时第二个需要考虑的层面，就是要看看能否通过改善服务器的配置来实现。

    第三层：数据库服务器。

　　当通过改善网络环境或者提高服务器配置，都无法达到改善数据库性能的目的时，接下去就需要考察数据库服务器本身了。首先，就需要考虑数据库服务器的配置。

　　一方面，要考虑数据库服务器的连接模式。SQL Server数据库提供了很多的数据库模式，不同的数据库连接模式对应不同的应用。若数据库管理员能够熟悉企业自身的应用，并且选择合适的连接模式，这往往能够达到改善数据库性能的目的。

　　其次，合理配置数据库服务器的相关作业。如出于安全的需要，数据库管理员往往需要对数据库进行备份。那么，备份的作业放在什么时候合适呢?当然，放在夜晚，夜深人静的时候，对数据库进行备份最好。另外，对于大型数据库，每天都进行完全备份将会是一件相当累人的事情。虽然累得不是我们，可是数据库服务器也会吃不消。差异备份跟完全备份结合将是改善数据库性能的一个不错的策略。

　　第四层：数据库对象。

　　若以上三个层面后，数据库性能还不能够得到大幅度改善的话，则就需要考虑是否能够调整数据库对象来完成我们的目的。虽然调整数据库对象往往可以提到不错的效果，但是，往往会对数据库产生比较大的影响。所以，笔者一般不建议用户一开始就通过调整数据库对象来达到改善数据库性能的目的。

　　数据库对象有表、视图、索引、关键字等等。我们也可以通过对这些对象进行调整以实现改善数据库性能的目标。

　　如在视图设计时，尽量把其显示的内容缩小，宁可多增加视图。如出货明细表，销售人员可能希望看到产品编号、产品中英文描述、产品名字、出货日期、客户编号、客户名字等等。但是，对于财务来说，可能就不需要这么全的信息。他们只需要产品编号、客户编号、出货日期等等少量的信息即可。所以，能可浪费一点代码的空间，设计两张视图，对应不同部门的需求。如此，财务部门在查询数据时，不会为不必要的数据浪费宝贵的资源。

　　如可以通过合理设置索引来提高数据库的性能。索引对于提高数据的查询效率，有着非常好的效果。对一些需要重复查询的数据、或者数据修改不怎么多的表设置索引，无疑是一个不错的选择。

　　另外，要慎用存储过程。虽然说存储过程可以帮助大家实现很多需求。但是，在万不得已的情况下，不要使用存储过程。而利用前台的应用程序来实现需求。这主要是因为在通常情况下，前台应用程序的执行效率往往比后台数据库存储过程要高的多。

　　第五层：SQL 语句。

　　若以上各个层面你都努力过，但是还不满足由此带来的效果的话，则还有最后一招。通过对SQL语句进行优化，也可以达到改善数据库性能的目的。

　　虽然说SQL Server服务器自身就带有一个SQL语句优化器。他会对用户的SQL语句进行调整、优化，以达到一个比较好的执行效果。但是，据笔者的了解，这个最多只能够优化一些粗略的层面。或者说，80%的优化仍然需要数据库管理员的配合。要数据库管理员跟SQL优化器进行配合，才能够起到非常明显的作用。

　　不过，SQL语句的调整对于普通数据库管理员来说，可能有一定的难度。除非受过专业的训练，一般很难对SQL语句进行优化。还好笔者受过这方面的专业训练，对这方面有比较深的认识。如在SQL语句中避免使用直接量。任何一个包含有直接量的SQL语句都不太可能被再次使用。我们数据库管理员要学会利用主机变量来代替直接量。不然，这些不可再用的查询语句将使得程序缓存被不可再用的SQL语句填满。这都是平时工作中的一些小习惯。

　　总之，笔者认为，在数据库性能调优的时候，若能够遵循如上的顺序，必定可以让我们少走冤枉路，不花无用功。其实，数据库调优并没有我们想象的这么难。只要我们能够掌握其中的诀窍，数据库调优将可以手到擒来。

 

1）软件测试技术网： http://www.testabc.cn/tech/index_c6_3.htm