测试Web Application之一：准备团队
---www.qalabs.com《Testing Web Applications Part 1: Priming the Team》
---Kiki翻译于2005/8/15
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要求的其他所有的测试类型，例如性能，安全，数据库完整性等。记住，解密高手不会利用浏览器去破坏网站，他们使用脚本。
- 寻找或创建合适的测试工具
成熟的测试工具的缺点是会使自动化变得困难。记得Java第一次击中场景是什么时候吗？开发人员和项目经理都想使用这种新技术。突然间测试人员的负担加重了，两倍，三倍，或更多。仅仅因为配置的数量和可用的成熟的测试和测试工具的缺乏。现在有很多的测试工具可以使用，但是仍然要花时间选择一个适当的工具，学习它的细节，设置自定制它到你的环境中。如果工具是不可用的，你应该即刻查明，并且构建一些你自己的测试应用程序。
- 创建一个操作系统vs.浏览器版本的矩阵
要求大量的浏览器和操作系统的兼容性测试。 如果你创建了一个操作系统与浏览器版本的矩阵，你将有一种攻击所有变化的方法。
如果你正在测试而没有定义你的环境，你将面对以下的问题：
- 当你没有先前的版本时，你如何回滚代码变更?
- 新的功能或修复的缺陷如何放到每个版本中？
- “内部版本（build）”术语意味着在web空间中的任何事情码？
如果源代码没有被归档或没有打上标签，或在版本控制库中没有进行分支，测试人员就不能够恢复到一个“已知状态”。当环境连续变得更复杂时，没有一个可以用来恢复的先前版本使得隔离和分析缺陷更加困难。如果你安装了一个友好的测试环境，你将不会必须面对由这些问题带来的新问题。
- 安装一个隔离的测试服务器
web测试人员的一个常见（并且危险）的习惯是在测试之前移植修复了缺陷和添加了新功能的代码到一个live服务器上，并且在它上面测试。实际上，你的测试团队不应关闭你的网站，他们应建立一个隔离的测试服务器。
这5 个步骤将帮助你提前为挑战性的任务而准备你的团队。在后面的文章里，我将略述一系列在开始你的测试计划时你将要问到的具体问题，以及怎样将这些问题的答案用于确定并集中你测试的策略。
测试Web Application之二：准备作战
---www.qalabs.com《Testing Web Applications Part 2: Preparing for Battle!》
---Kiki翻译于2005/8/18
何时做计划：
一旦市场需求被搜集好并且已经稳定了/被签署批核了，测试计划就应该认真地开始了。这个经验法则应该用于所有的软件开发项目，但是对于web application，就必须应用这个规则。因为这种类型项目的时间是那么的短，并且它们在如此紧张的压力下要在规定日期里上线（go live），以致于测试计划必须尽快开始。
怎样做计划：
在计划测试一个web application时，我已经列出了一组浓缩的需要考虑的项目。通常这类型的信息用任何书面形式，甚至或用口头形式，对测试人员来说都是不适用的。大多数的测试团队在开始他们的测试计划活动时会被一个不完整的景象捆住。以下的项目是用于帮助你填补缺口，在那里信息常常被错误传达或根本没有交流。事先考虑下在发布之前的二周里，产品经理对测试团队说：“你们已经在Mac9.0上的IE4.5上测试过了，对吗？”的时候。这是保证你可以回答上问题的一种方法。 如果只是从你的测试计划中排除非目的因素，这是非常有用的。例如，如果站点的首要目的是信息交换其中之一，而不是电子商务，那么测试计划将只有较少的描述站点电子商务功能的细节或焦点。 了解这一点将帮助你集中在用户的类型和它们最常在站点上执行的功能上，同样还有他们的期望。然后就可以很容易地创建有用的用户场景以帮助你定义你的测试范围和焦点。 或许可靠性和安全性是可以集中你测试的关键区域；或许是速度和性能。问这些类型的问题将帮助你集中精力在最重要的地方。如果性能和负载测试是你web application的标准，而且你以前从未做过此类型的测试，那么从在这一领域中有着更多技术头脑的人中获得帮助 。开始的合适位置是利用内部的开发资源，可能他们可以创建一些直接测试web服务器并能模拟很多用户的测试脚本 。 那么就开始计算它们。这将让你产生为测试web application功能而需测试用例数量的球场的（ball-park）估计。一个快速的经验法则（rule of thumb）是每个不同的功能需求最少有4个测试用例：一个有效的用例，一个无效的和两个边界的用例（最高的和最低的）。一次更密切的对功能需求本身的检查将显示需要比最小量更多的测试用例以取得足够的功能覆盖率。
例如：100个功能需求×4个测试用例/需求＝ 400测试用例。这是一个最小值。你仍然将不得不仔细检查需求及其关联的测试用例以确保测试计划的水准对于所有的需求而言是足够。使测试用例可以追溯到原始的需求将使这个任务更简单些。
5). 定义网站的非功能性需求
因为这个领域将以最快的速度增加你的测试工作量，得到一个对项目管理所期望范围的全面了解是一种好主意。这是一个测试计划能够揭示由于在测试时间表增加一额外的浏览器或者操作系统所带来巨大影响的地方。 这也是一个谨慎谈判，预计划，和风险管理可以维持你的测试进度表在控制之下的地方。你对测试所需操作系统/ 浏览器的组合了解的越清楚，你就能越容易地沟通花在其他平台和/或浏览器上额外测试的费用。
例如：400个测试用例×4种环境＝总共1,600测试用例。每个额外的测试环境（例如，操作系统和浏览器的组合）就要为你的测试工作量增加400个测试用例。试想一下如果它花1个人/周（5个工作日）来执行100个测试用例，每个额外的测试环境将增加4人/周的测试时间。 尝试不要太详细或过度得正式：这份文档是一个让测试团队在整个项目中使用的概要视图（high-level view）。它不是为项目组的其他成员使用而设计的，也不是其他项目文档的替代品。有希望地是，大量的信息将已经写在其他一些你可以参考的文档中。一旦完成了这份文档，让项目的涉众者审查以保证它的正确性。 我建议你按这种顺序创建测试用例：有效功能测试用例，无效功能测试用例；边界功能测试用例，用户场景测试用例。因此，你将在创建你的边界功能测试用例之前创建一组有效功能测试用例。同样地，你通过连接你的有效功能测试用例创建用户场景（注意用户场景是由功能测试用例组成地，并且因此在步骤中提到的“球场数量”仍然是有效的）。如果你的时间非常短，在创建边界功能测试用例之前创建用户场景（这将给你的前进带来更大的冲击）；否则的话在边界测试用例之后创建用户场景以确保你测试了所有的边界条件。根据重要性和频率为它们划分优先级别。你将运行最频繁或测试重要功能的测试用例比你将很少运行或仅仅运行一次的测试用例将拥有更高的优先级。
1). 定义网站的目标
2). 定义网站的访客对象
3). 定义网站的质量标准
4). 定义网站的功能性需求
6). 将所有的这些信息写到一份文档中
7). 创建你的测试用例并为它们划分优先级
文章来源于领测软件测试网 https://www.ltesting.net/
