测试基于Web的应用程序

　　测试web应用程序和测试桌面系统用很多共同点：例如你需要和执行所有标准测试类型一样测试常见的功能点，配置及兼容性。但是由于与应用程序交互的所有分布式系统组件的复杂性成倍的增加的原因，导致web应用程序测试更加的困难。当我们在web环境中看到一个错误时，通常很难指出错误发生的地方，并且由于我们看到的行为或我们接受到的错误信息可能是发生在Web系统中不同部分的错误的结果。错误可能是很难重现的。那么我们如何在web系统中分析错误呢，并且为了重现那些错误又应该做哪些考虑呢?

　　当我们对潜在的技术有一个了解时，我们可以更好的最大化测试效率-编写更多可重现的bug报告并且在较少的时间里发现更多的错误。说比做更加容易-特别是在web环境里。Web环境在错误倾向技术变量是密度高的。以下是测试Web应用程序的需要考虑的5个基本事项：

　　1. 当我们在客户端看到一个错误时，我们所看到的是错误的症状，而不是错误本身。

　　2. 错误可能是与环境相关的，并且可能不出现在不同的环境里

　　3. 错误可能是存在代码或是配置中的

　　4. 错误可能驻留在几个层中的任一个层中

　　5. 检查操作系统中的两个类别-静态vs动态-需要不同的方法。

　　现在让我们来详细的看看这5个需要考虑的事项。

　　1. 什么是我们真正看到的东西?是一个错误还是一个症状?

　　如果不诊断环境，我们不能够确定是什么导致了一个症状出现。如果客户端和服务器端的一个环境特定的变量被移除或被改变的话，我们或许将不能够重现问题。

　　例如，我正在测试一个Web的缺陷跟踪应用程序，并且遍历创建一个bug报告的流程。当我选择 “新建”按钮时，我接收到一个错误信息：Microsoft OLE DB Provider for ODBC Drivers error '80040e14'。在花了一些时间调查我的浏览器环境后，我发现JavaScript在浏览器的参数设置对话框中被禁止了。启用JavaScript 就消除了这个错误。(这个问题是否是个bug不在我们今天讨论的范围里)这里是要说如果我在bug报告中增加关于JavaScript的信息，我可以节约我们团队花费在分析这个问题的时间。此外，“禁用JavaScript”从此应该要添加到我的测试包中;它将被应用到应用程序的各个地方，以使所有潜在的相关问题不会出现。

　　2. 这个错误是环境依赖的吗?

　　为了重现一个环境相关的错误，我们不得不完全地复制活动的准确顺序和应用程序操作所在环境的条件(操作系统，浏览器版本，插件的组件，数据库服务器，web服务器，第三方组件，服务器/客户端资源，网络带宽和通信量等等)。例如，当你试图使用一个28.8 kbps的拨号连接登录到你的Web应用程序中，你会碰到一个由于在认证过程中因超时而导致的登录失败-但是同样的登录步骤如果你用一个1.54 mbps 的T-1连接将会成功的通过认证。在这个案例中，你有一个环境依赖的错误，这个依赖条件是在带宽中。

　　环境无依赖的错误，用另一种话说，相对来说是容易重现的-它没有必要复制操作环境。环境无关的错误，需要复制所有都能够揭示错误的步骤。例如，如果公司的名称在所有产品在线页面上错误地拼写为WebTessting.Con, 你就总能看到这个错误-它是和硬件，软件和你操作环境中资源变量无关的。更为常见的是，我们将环境无关的错误称为功能特定的错误。

　　3. 是一个代码错误或是一个配置问题

　　错误(或是假定错误的症状)可能会在代码修复中或系统重新配置(客户，服务器或网络)解决(假设错误是真实的)。不要太快的下结果它是一个bug。

　　Microsoft OLE DB Provider for ODBC Drivers error '80004005' 对比真正的软件错误，这是一个说明识别可能的配置问题挑战。它显示了由于Web应用程序“登录失败”而引起的一个错误信息。只是简单的查看这个错误信息，是不可能判断这个错误是由于软件bug引起的还是服务器端配置问题，或是兼容性问题，浏览器配置问题或以上所有的。

　　在进一步分析这个失败以后，我发现几个可能的产生这个错误信息的条件:

　　IIS (Web server) virtual directory has not been set up properly当虚拟目录没有被正确的配置时，将找不到请求的文件，脚本或数据。这是一个典型的服务器配置的问题。然而，如果安装程序未能根据说明书一样配置web服务器，那么这是一个软件的错误。如果一个系统管理员未能根据说明书正确地配置web服务器，这个就变成了用户错误。

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