测试错误代码

测试错误代码

---James Whittaker原著《Testing Error Code》
---Kiki翻译于2005/7/19

开发人员会编写两种代码：功能代码和错误代码。这篇文章是关于了解在测试错误代码时的空前的挑战，我们将从一个开发人员的角度讨论错误代码开始。随后我们将探索作为测试人员一种最好的攻击这一挑战的方法。

开发人员会编写两种代码。第一个是让工作执行的代码，我们称这种代码为功能代码因为它提供了满足用户需求的功能性。第二种是为了防止功能代码由于不正确的输入（或一些意外的环境状况）而引起的失败，我们称它为错误代码是因为它是处理错误的。对于许多的开发人员而言，这是出于需要而被强迫编写的，并不是因为它特别有趣。
同时编写两种类型的代码是有问题的，是因为在软件开发人员的头脑里必须在两种代码之间做上下文的切换（context shift）。这种上下文的切换是值得怀疑的，因为他们需要开发人员停止思考一种代码并开始思考另一种代码。
假设Johnny，一个我们假想的辛勤的开发人员，正在开发一个新的应用程序。Johnny通过编写功能代码开始工作，你甚至可能想的更远，想使用一些象UML的技术以让Johnny充分理解必须要编写的各种各样的用户场景。这样很好，实际上，象Johnny一样的优秀的编程人员可以查找到大量的可以帮助他们编写优秀的功能代码的信息。有很多的书，指南，还有许多有用的出版物中的示例都可以帮助你。
但是，当Johnny意识要需要编写错误代码时会发生什么事情呢？可能当他在编写或指定一些他确定要做的代码对象时，他说，这个输入需要校验边界（bounds-checked）。Johnny会怎么做呢？其中一个选择是停止编写功能代码并且改为编写错误代码。这需要在Johnny的开发员的脑子里做一个上下文的切换。他必须停止思考用户的场景和他正在实现的功能代码，然后开始思考如何处理错误。由于处理错误可能会比较负责，这可能要花他一些时间。
现在，当Johnny返回到编写功能代码的任务里，yes它们变得编写任何不平凡的程序。你看到了问题：可怜的Johnny不得不忍受着两种上下文切换以除了一个错误。设想以下在编写一个（即使是一个小的）应用程序将有多少象这样的上下文切换。
另一个选择是推后编写错误代码以避免上下文切换。假设Johnny记得在最后抽出时间来编写错误代码，他或许不得不发一些时间来回忆他以前试图编写一个处理器来处理的错误事件的本质。因此现在Johnny在没有上下文利益的前提下编写错误代码。编写错误代码是有问题的不管你如何面对。因此对于象我一样的人来说，发现错误。因此现在让我们用测试的角度看看，我们要用什么方法测试错误代码呢？

强制错误信息出现是使错误代码执行的最好方法。软件应该正确地响应错误的输入或者首先应该成功地防止输入进入到软件中。有把握了解的的唯一办法是用一批错误的输入测试应用程序。或许最重要的是了解应用程序如何响应不正确的输入。我设法验证以下三种不同的错误处理器的类型：
输入过滤器（Input filters）：能够用于预防错误的输入进入所测试的软件（software under test）。有效的过滤错误的输入，例如，一个图形用户界面，只允许合法的输入通过界面
输入校验（Input checking）： 可以执行以确保软件不会执行使用错误的输入。最简单的例子是每次输入一个到系统中，开发人员插入一条IF语句以确保数据在处理之前输入是合法的。换句话说，如果输入是合法的，那么就除了它，否则显示一个错误信息。在这个优先的攻击时，我们的目标是确保我们看见了所有这样的错误信息。
异常处理器（Exception handlers）： 是一种最后才采用的方法，并且常用于在系统由于处理了错误输入而导致的失败之后清理错误。换句话说，错误的输入允许进入稀土女冠，被处理后，系统出现了错误。异常处理器是一种常见的程序，在软件失败时被调用。它通常包括重新设置内部变量，关闭文件并且恢复软件和用户交互能力的代码。一般来说，也会显示一些错误信息。
测试人员必须考虑所测试软件可以接受的输入并且集中在不正确数值上。在这里的方法是输入太打，太小，太长，太短的数值，这些数值是超出了可接受的范围或是错误的数据类型的数值。这种方法可以发现的主要的缺陷是遗漏了错误的情况－开发人员不知道哪些输入的数据是错误的或被忽略的个别情况。遗漏的情况通常导致软件中止或崩溃。测试人员也应该查看错误信息放错位置的情况。有时开发人员正确地获得了错误信息，但是却把它安排给了错误的输入数值。因此，对于那个提交的输入数值而言，这个错误信息就好像是胡说八道。
最后，纯粹恶作剧的数据是不能提供任何信息的错误消息。尽管这样的信息不会引起对用户直接的伤害，但是他们是草率的并且在用户的头脑里投下了对软件制造商的诚信的怀疑。“Error 5—Unknown Data” 对于一些开发人员来说可能看上去是一个好的主意，但是它将在用户的头脑里产生挫败，用户不知道他们什么地方做错了。不管测试人员正在测试一个GUI面板中的输入字段还是测试一个API调用中的参数，测试人员必须在执行这个攻击时思考输入的属性。如下是一些常见的应该思考的属性：
输入类型（Input type）: 输入无效类型通常将产生一个错误信息。例如，如果“问题”的输入类型是整数，那些尝试输入一个真实的数字或一个字符。
输入长度（Input length）: 对于字符（字母和数字）类型的输入，输入少量的很多的字符将引起错误信息。
边界值（Boundary values）：每一个数字数据类型有边界值，并且有时这些数值代表着特殊的情况。例如，整数0就是正数和负数的边界。
让我们准备发现一些鼓舞人心的bug吧！

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=429711