Web 应用程序 vs. 网页（Web Pages）
贵公司已决定是时候在你的服务或产品前面加上一个字母“e”了。由网络开发人员组成的团队也已装备好提供来自贵公司网站上的服务或产品了。你和你的团队将负责测试这只新的怪兽，web application。不管你公司的性质如何，你曾经都测试过企业应用程序或数据库应用程序。因此这应该是相当简单的，对吗？ 它只是一捆网页，或许是一些JavaScript，对吗？ 很遗憾，你错了。
我们说的“web application”是什么意思呢？从一个简单的带有一些订单填写的公司站点到象Yahoo或Amazon一样的站点，在web applications里这是一个难以置信的复杂度范围。一种考虑web application 架构的方法是采用传统业务交易应用程序的模型，并用网站代替了用户前端。一个客户用钱以从你的公司获得货物和/或服务。使客户和公司之间的交易适当的变得更容易些，这是我们的机制。 但不是一名销售代表，办事员或一名出纳员，而是你有一个指向网站的浏览器。公司从未被关闭！用户可以自己服务自己！
想一想自动贩卖机。它基于用户的输入填写订单，验证资金的转移，并且有一个基本的用户界面。现在增加一些复杂度。使这个用户界面变为一个基于浏览器的解决方案，它必须运行在多个操作系统的多个浏览器上，而不是在touchpad上。噢，在（实时的）跟踪存货时，让机器直接填写来自货舱的订单。并且为完成那个过程，人们不用再往机器中投入钱币，而是在读卡机上刷一下信用卡－一次你将需要让信用卡公司批准每一笔交易。嘿，另一个好点子就是为一个客户分配一个用户名和PIN（个人身份号码）以允许我们保留他们的信息。利用这个方法他们就不需要刷卡及输入发货信息。并且我猜想这些信息实际上也将安全些。
考虑到这个情景，现在很清楚了web application不是简单的，带些图片和一些HTML或JavaScript的网站。他们和传统的，在前端有些格外复杂度的交易系统很相似。那样一个系统所需的测试工作量比为没有web界面的应用程序多的多。
开发的生命周期及其对测试的影响
我们中的大多人曾经都接触过少数的软件开发生命周期模型，例如Spiral 模型，瀑布模型等等。典型的软件项目的阶段有计划，收集需求，分析和设计，实现（又叫编码），集成，测试，发布和维护。你的团队需要知道对于一个web application的项目，这些阶段该如何配合。
这些阶段有些相似，但是没有以前在工业中看到的不时的冗长的时间量度。Web application是软件，并且同样地和所有软件开发项目一样受到相同规则的影响：至少你需要需求，设计，实现和测试。如果你想限制风险，象其他任何的软件项目一样，你需要做出计划和管理。即使速度和昨天市场部总是想要的产品相似。只不过现在“昨天”甚至更早了。
最好的减少在测试一个web application 时风险的方法是在项目生命周期的初期增加正式的测试计划和分析。每个项目在项目生命周期的结束部分都有测试这一环节。当开发进度不理想时，测试的时间几乎总是被缩短以便可以迎合发布或“go-live”日期。在项目生命周期的初期增加测试计划将允许测试人员基于风险，进度约束和测试人员的能力及态度区分他们测试工作的优先级别。当在“go-live”之前时间很紧张时，这对管理测试工作量就显得非常重要。
现在就准备的5种方法
测试一个有着相对静态内容和极少表格的网页只要花很少的时间。测试一个web application将需要更加复杂的测试策略和更多的时间。由于web开发的本质，你的团队或许不能获得更多的时间，甚至可能比传统开发项目更少。你可以通过利用在初期的“停工期（downtime）”提前来筹备你的测试团队以节约时间。
更多地了解你将工作的环境
测试人员应该自己熟悉难以捉摸的浏览器，操作系统，web服务器和数据库的差异。他们知道更多的关于脚本（ASP, XML, HTML等），数据库（Oracle, SQL等），web服务器（IIS, Apache, 等）和在UI后面的数据传递的知识，他们就会更加有效率。测试人员不是简单地只通过运行UI（在这里，指的是浏览器）来测试功能。如果这样他们将遗漏掉web application要求的其他所有的测试类型，例如性能，安全，数据库完整性等。记住，解密高手不会利用浏览器去破坏网站，他们使用脚本。
文章来源于领测软件测试网 https://www.ltesting.net/