测试Web Application之二：准备作战

---www.qalabs.com《Testing Web Applications Part 2: Preparing for Battle!》

---Kiki翻译于2005/8/18

在“测试Web Applications之一：准备团队”中，我论述了一些测试web application和测试其他一些应用程序不同的原因，例如桌面应用程序。在这篇文章中，我将要概要说明一些可以帮助你保持注意力并且有希望让你在计划你的测试工作量时避免一些常见错误的关键点。

何时做计划：

一旦市场需求被搜集好并且已经稳定了/被签署批核了，测试计划就应该认真地开始了。这个经验法则应该用于所有的软件开发项目，但是对于web application，就必须应用这个规则。因为这种类型项目的时间是那么的短，并且它们在如此紧张的压力下要在规定日期里上线（go live），以致于测试计划必须尽快开始。

怎样做计划：

在计划测试一个web application时，我已经列出了一组浓缩的需要考虑的项目。通常这类型的信息用任何书面形式，甚至或用口头形式，对测试人员来说都是不适用的。大多数的测试团队在开始他们的测试计划活动时会被一个不完整的景象捆住。以下的项目是用于帮助你填补缺口，在那里信息常常被错误传达或根本没有交流。事先考虑下在发布之前的二周里，产品经理对测试团队说：“你们已经在Mac9.0上的IE4.5上测试过了，对吗？”的时候。这是保证你可以回答上问题的一种方法。


1).     定义网站的目标

如果只是从你的测试计划中排除非目的因素，这是非常有用的。例如，如果站点的首要目的是信息交换其中之一，而不是电子商务，那么测试计划将只有较少的描述站点电子商务功能的细节或焦点。

2).     定义网站的访客对象

了解这一点将帮助你集中在用户的类型和它们最常在站点上执行的功能上，同样还有他们的期望。然后就可以很容易地创建有用的用户场景以帮助你定义你的测试范围和焦点。

3).     定义网站的质量标准

或许可靠性和安全性是可以集中你测试的关键区域；或许是速度和性能。问这些类型的问题将帮助你集中精力在最重要的地方。如果性能和负载测试是你web application的标准，而且你以前从未做过此类型的测试，那么从在这一领域中有着更多技术头脑的人中获得帮助 。开始的合适位置是利用内部的开发资源，可能他们可以创建一些直接测试web服务器并能模拟很多用户的测试脚本 。

4).     定义网站的功能性需求

那么就开始计算它们。这将让你产生为测试web application功能而需测试用例数量的球场的（ball-park）估计。一个快速的经验法则（rule of thumb）是每个不同的功能需求最少有4个测试用例：一个有效的用例，一个无效的和两个边界的用例（最高的和最低的）。一次更密切的对功能需求本身的检查将显示需要比最小量更多的测试用例以取得足够的功能覆盖率。

例如：100个功能需求×4个测试用例/需求＝ 400测试用例。这是一个最小值。你仍然将不得不仔细检查需求及其关联的测试用例以确保测试计划的水准对于所有的需求而言是足够。使测试用例可以追溯到原始的需求将使这个任务更简单些。

5).     定义网站的非功能性需求

因为这个领域将以最快的速度增加你的测试工作量，得到一个对项目管理所期望范围的全面了解是一种好主意。这是一个测试计划能够揭示由于在测试时间表增加一额外的浏览器或者操作系统所带来巨大影响的地方。 这也是一个谨慎谈判，预计划，和风险管理可以维持你的测试进度表在控制之下的地方。你对测试所需操作系统/ 浏览器的组合了解的越清楚，你就能越容易地沟通花在其他平台和/或浏览器上额外测试的费用。

例如：400个测试用例×4种环境＝总共1,600测试用例。每个额外的测试环境（例如，操作系统和浏览器的组合）就要为你的测试工作量增加400个测试用例。试想一下如果它花1个人/周（5个工作日）来执行100个测试用例，每个额外的测试环境将增加4人/周的测试时间。

6).     将所有的这些信息写到一份文档中

尝试不要太详细或过度得正式：这份文档是一个让测试团队在整个项目中使用的概要视图（high-level view）。它不是为项目组的其他成员使用而设计的，也不是其他项目文档的替代品。有希望地是，大量的信息将已经写在其他一些你可以参考的文档中。一旦完成了这份文档，让项目的涉众者审查以保证它的正确性。

7).     创建你的测试用例并为它们划分优先级

我建议你按这种顺序创建测试用例：有效功能测试用例，无效功能测试用例；边界功能测试用例，用户场景测试用例。因此，你将在创建你的边界功能测试用例之前创建一组有效功能测试用例。同样地，你通过连接你的有效功能测试用例创建用户场景（注意用户场景是由功能测试用例组成地，并且因此在步骤中提到的“球场数量”仍然是有效的）。如果你的时间非常短，在创建边界功能测试用例之前创建用户场景（这将给你的前进带来更大的冲击）；否则的话在边界测试用例之后创建用户场景以确保你测试了所有的边界条件。根据重要性和频率为它们划分优先级别。你将运行最频繁或测试重要功能的测试用例比你将很少运行或仅仅运行一次的测试用例将拥有更高的优先级。