测试基于Web的应用程序(3)

　　在测试这个应用程序过程中，我发现图表功能可以在以上的配置上运行，但是却不能在其他配置上工作。在我更进一步的研究之后，我认识到问题可能出现在two-box配置中。在检查代码之后，我认识到问题在步骤2和3中。在步骤2中，查询结果被写到数据库服务器本地驱动器中c:\temp\chart.val。在步骤3里，Chart JavaApplet是运行在应用服务器上而不是和数据库服务器在一个相同的盒中。当它试图在应用服务器本地驱动器中打开c:\temp \chart.val文件时，文件并不存在。

　　在这个用例中，我不建议在遇到问题时就阅读代码，我把调试的工作留给开发人员。我只不过想指出识别哪个服务器配置是有问题的，并且在bug报告中含括这些信息。我也会在测试下的应用程序支持的全部的分别式配置下运行一个粗略的测试用例包。

　　配置问题在静态操作环境中也是很终于的。例如，在图3中我们看到在Netscape Navigator和IE浏览器的一个兼容性区别。

　　这个例子并不是要说IE比Netscape Navigator更好，它只不过意味着在浏览器之间有不兼容性问题-并且代码应该假设相对路径在所有的浏览器中都可以工作。更重要的是，它建议当你在一个环境中发现一个错误时，如果它是一个环境相关的错误的话，同样的错误可能不会出现在不同的环境中。

　　动态的操作环境：事情不会保持一样

　　当特定环境的属性值不是每次都在测试过程中保持常量时，它会引起操作环境变为动态。属性可以从资源特定(可用的RAM，磁盘空间等)转变为时间特定的(网络反应时间，用户要提交的交易顺序等)。

　　当一个测试用例取决于步骤集和操作环境的准确复制，然而(由于它的动态本质)操作环境不可能被复制，错误变得不可重现或很难重现。

　　顺便说一下，这也是内存相关错误通常较难重现的原因。当一个内存覆盖的错误出现在代码中时，例如，它常常会引起一个内存覆盖的问题。然而，从一个黑盒测试的角度看，我们永远没有机会看到这个错误的症状直到执行或读取特定的代码或数据溢出字节。在这个例子中，步骤集代表了黑盒测试的准确集合。内存覆盖错误代表了在代码中的真实的错误。被执行或读取的被覆盖的字节的条件代表了动态的操作环境或需要揭露(重现)错误的条件。

　　这是一个动态环境相关错误的Web应用程序例子，我们在其中将调查一个时间相关错误。功能说明书要求：

　　· 在系统中的项目名称必须是唯一的

　　· 为了可能的复制需要在客户端使用JavaScript来执行错误识别和处理

　　· 用户将可以通过请求项目设置页面增加或删除项目名称

　　· 当一个用户创建一个新的项目名称时，浏览器端的JavaScript检查输入的名称和内嵌在HTML页面中选择列表(如图4)。

　　看看图5中的时间相关的错误。在项目设置页面之前和之后的屏幕截图中说明了应用程序失败检测重名的“Doomed”。图4解释了这个时间相关的错误，它包括了两个用户增加新的项目名称到同一个数据库中。

　　如表1中所示，用户A和B同时创建新的项目，但是并不知道其他人的动作。在步骤3中，用户A增加了一个名为Another的项目。由于这个项目名称已经存在，他浏览器的JavaScript会显示一个提示他输入不同项目名称的信息。

　　用户B增加了一个项目名称为Doomed。她浏览器的JavaScript不会检测Doomed为一个已经存在的项目名并且添加它到数据库中并返回列表。更新过的项目名称列表被发送到用户B。

　　用户A随后添加相同名称Doomed到项目列表中。他浏览器的JavaScript没有在HTML列表中检测，因此Doomed会再次被添加到数据库中-同样到了返回的列表中。更新的项目名称列表被发送给用户A，并且包括两个Doomed的条目。

　　这个结果未能满足产品的说明书。除非这种情况出现在一个设计良好的测试用例，偶然发现这个错误并且试图重现它不是一个简单的工作。在这个例子中，实际的错误是应用程序在检查服务器端重名(除了客户端检查以外)的失误。这些步骤包括用户A的活动。通过用户B的活动创建了动态操作环境-这些活动对于用户A是隐藏的或不知道的。

　　总结

　　为了有效的在Web环境中分析并重现错误，你需要对操作环境有个掌握。你也需要理解环境特定的变量可能会影响你复制错误的能力。在应用程序有着这份文章中的一些技能，我希望你的Web测试经验将会更少的被挫败和更加开心。

原文转自：http://www.uml.org.cn/Test/201006282.asp