-
自动化测试成功的关键: 制定计划
2007-08-30 11:21:03
在本文中，我们要讨论为什么进行测试，尤其是自动化测试，是必需的。然后，我们将介绍制定计划的概念：为什么制定计划是如此的重要？在随后的文章中，我们将分解测试计划中的不同因素，并且研究如何进行制定计划的过程才能最大程度地增加成功的机会。
现代客户端/服务器应用程序是非常复杂的，因此测试也就成为开发过程中关键的并且至关重要的一部分。现在，没有人会考虑（或者承认）不对自己开发的软件进行测试工作。但是，研究和调查表明，在软件开发过程中，制定测试计划却常常是优先级较低的工作项目。而且，更加糟糕的是，计划往往没有被执行，或者即使执行了，也进行的不很完整、不很准确，或者没有持续进行。
假设我们都赞成测试是必要的，那么我们接下来必须回答这些问题：我们如何进行测试？实际上都包括哪些内容？我们如何保证已经进行了有效的工作，并且真正地改善了应用程序的质量？
答案很简单：制定计划。
本文是系列文章中的第一篇，该系列文章将评审在软件生命周期中制定测试计划的作用，以及有效制定测试计划的有关概念。在本文中，我们要讨论为什么进行测试，尤其是自动化测试，是必需的。然后，我们将介绍制定计划的概念：为什么制定计划是如此的重要？在随后的文章中，我们将分解测试计划中的不同因素，并且研究如何进行制定计划的过程才能最大程度地增加成功的机会。
现在看来，没有怎么制定测试计划而造成的后果比以前更加明显了。失败的案例有很多--看看报纸或者杂志就知道了。还有一些明显的低质量软件的案例，它们包括：
- AT&T－一个软件交换系统，系统崩溃造成了美国几乎24小时的长距离通信中断。仅仅修改了一行源代码就解决了问题。
- Denvor机场--软件的缺陷延误了机场的开放几乎长达9个月之久，据估算，每天花费纳税人大概$500,000。
- Ashton-Tate--在80年代，Ashton-Tate的DBASE软件是基于PC的数据库应用程序的实际标准。版本中的缺陷导致了利润的减少，最终造成了Ashton-Tate（和DBASE）的转让。Ashton-Tate最后被Borland（拥有极具竞争力的数据库管理应用程序，Paradox）收购。
当然，这些都是知名度很高的公司和项目。这些问题不会出现在您的公司中，对吗？
错误！我们都要面对软件的缺陷，在我们的组织中与外界都是一样，这些问题都是关键的，也是很明显的。这里有一些低质量软件的更加共同的症状：
- 系统性能
- 缺少功能/特性
- 没有满足用户需求--无法销售
- 强迫用户以不直观的方式执行任务
- 循环工作
- 延迟
- 没有满足预期目标
- 存在用户操作错误与理解错误
回页首
客户端/服务器应用程序为质量保证专家带来了不同的挑战，下面是一些比较重要的内容：
大多数的客户端/服务器应用程序都使用快速程序开发（RAD）方法学进行开发。测试人员必须"努力跟上"这些较短的开发周期。早些时候，非客户端/服务器应用程序常常使用18-24个月就完成了整个的开发过程和初始部署。现在，使用RAD，应用程序的发布需要经过多次部署或者"块"。每个块都基于以前的版本，并且包括改善、修改和修理。每个块都需要多次创建或者迭代的原型。每个块都需要进行测试，并且在3-6个月的更短时间内完成。
当前的客户端/服务器应用程序都需要很多的软件组件结合起来以实现功能，包括客户端应用程序、工作站操作系统、网络和数据库管理系统。常常也包括其他的组件，例如为实现正确执行而包含的附加源代码的DLL（动态连接库）、事务处理器或者应用程序与数据库管理服务。软件的每个附加"层"都在客户端/服务器架构中增加了额外的复杂度（并且需要进行测试）。
另外，测试客户端/服务器应用程序也需要使用许多不同类型的测试方法，例如，功能测试、用户界面、性能测试以及配置测试。这些测试都针对一个或几个测试目标。为了防止测试迂回不前或者尝试同时测试所有内容，每种测试必须制定仔细的计划。当您进行自动化测试时，这一点尤其正确。
对于我们执行的每种类型的测试，都必须使用数据。数据对于测试的执行和成功完成来说是至关重要的，因为要使用数据识别最初的应用程序数据状态（条件），并且调用或者引出特定的事件或者操作。而且也要使用数据来验证测试事件或者操作是否运行正常！
如前所述，现代的应用程序与以前开发的应用程序相比具有很大的不同。客户端/服务器技术加强了我们开发与部署以任务关键型的企业系统的能力，而且花费的周期更短，提供的功能更加强大。客户端/服务器应用程序也为开发人员与终端用户提供了大量的选择和控制。但是使用这些好处的同时，也需要加强测试。
逐渐地，测试软件必须使用测试自动化工具和技术，以满足具有挑战性的日程安排。但是，单单使用工具还不足够，成功的测试自动化需要制定测试计划。在没有进行计划的条件下，实施测试自动化只会带来自动化的混乱。使用测试自动化工具，我们可以管理混乱并且识别过程中造成混乱的因素，同时管理项目费用（例如"未被文档化的特性/变更"）。
测试自动化是使软件测试人员跟上开发人员脚步的惟一方式，软件测试人员可以像测试早先构建版本那样，充满信心地、可靠地测试新构建的版本。
但是测试常常为测试人员带来挑战，他们必须最有效地、生产力极高地使用时间，进行工作。测试自动化引入了一种新型的资源需求--测试开发。手工测试需要进行测试设计，以识别测试的内容和方式，但是由于没有使用工具，所以也没有必要开发任何的测试脚本或过程，仅仅来调试一下系统，然后使用键盘就可以了！如果对于每个要进行的测试，需要使用的资源仅仅是键盘，那么就可以看出，您并没有有效地利用时间。
测试开发是一种新技术，在设计完成之后，需要使用工具并且创建测试过程。作为一种有效的方式，可以使用三名不同的技术员，并确保将最高级的资源用于设计与制定计划任务上，而将中级资源（或外界资源）用于开发与执行。这样可以增强职员所需的能力，并且共享资源，同时也不会对项目计划产生什么影响。
缺陷是肯定会被发现的。这是进行测试的结果，或者说是目的，所以我们必须对缺陷的生命周期进行识别和沟通，同时分析结果以确保缺陷已被有效地并且高效地处理。制定测试计划能够确保缺陷管理与分析是一笔面向整个项目的宝贵资产，而不会带来阻碍。如果您还没有配备缺陷管理系统和过程，或者已具有但是工作得不是很理想，那么制定测试计划就会给您带来创建（或者修正）它的机会。
制定测试计划也可以识别应该使用什么样的度量方法。制定测试计划可以处理您所度量软件质量程度的问题。它也可以处理如何度量与沟通缺陷密度或缺陷趋势的问题。
另外，制定测试计划可以识别与沟通数据收集与分布的方式，也应该指明使用报告的格式，以及作出报告的时间。
制定测试计划提供了进行风险评估的机会。风险与不利因素对于组织来说是就一场噩梦，但是它们也是可以被控制的。不过首先必须对其进行分析。风险分析有助于制定测试工作的优先级，并且关注所进行的工作，确保测试内容的正确性，以正确的顺序解决正确的问题。（所谓正确，是以组织的风险与可接收度为基础的。）
对于每个项目来说，都要进行风险评估并将其用于识别潜在的风险或者未发现缺陷带来的影响。风险应该用来评估缺陷对于直接终端用户、数据或者其他终端用户和应用程序带来的影响。这些数据可以用来建立测试优先级，并且评估所有约束，例如面市时间、预算或者费用，或者质量问题。
风险评估还应该包括对于现有标准、指南和需求的评审。其目的就是为了分析这三种文档，判断它们对于项目是否恰当，并且由此进行实施或者修正。
评审任何可能影响或者对项目带来冲击的外界因素也是很重要的。这些影响可以包括特定用户请求、规范的需求、或者市场条件，这其中的任何一项都可以变更风险或者优先级的评估结果。
制定测试计划就是为测试过程制定文档。为测试制定计划不仅仅为文档化并且沟通测试工作提供机会，也可以评审测试工作的有效性。
您曾听到过以下对话吗：
"用户报告发现缺陷在…，难道你没有测试它吗?"
"这是如此的明显，你怎么能发布带有这种缺陷的产品呢？"
"我知道你已经说了需要三个月的时间进行测试，但是你只有两个…"改善产品质量（具有较少的软件缺陷）需要对产品开发过程进行持续的完善工作。开发测试计划可以使测试人员能够识别、执行、度量并且改善他们的测试工作。
总而言之，可以从几个理由来说明制定良好计划的自动化测试的必要性。首先，不进行测试的组织会大大增加出现重大系统故障的可能，带来延迟，花费巨资进行修复，而且还可能潜在地带来对于客户信心无法修补的破坏。其次，现代客户端/服务器应用程序的本质允许快速地开发出复杂度很高的系统，该系统完全无法使用传统的手工方法进行正确的测试。最后，制定计划的目的就是为了管理不断增加的测试过程，分析并且跟踪已被发现的缺陷，执行关键性风险分析，并且持续改善测试与开发过程。在下一篇文章中，我们将更加深入地研究制定计划的过程，识别特定步骤，并且讨论如何才能开发出制定计划过程的有效策略。
回页首
IBM Rational 支持大量的 IBM 软件产品。IBM 软件解决方案可以赋予您实现优先业务和 IT 目标的能力。
- DB2® 软件提供了数据支持、数据管理和数据分布的解决方案，可以帮助您有效地利用数据。
- Lotus® 软件提供了编辑、管理、交流和共享知识的解决方案，可以帮助提高职员的生产率。
- Tivoli® 软件帮助您管理那些运行在您的电子商务基础设施上的技术。
- WebSphere® 软件帮助您把原来的关键业务扩展到 Web 上。
- Rational® 软件提供的工具、服务和最佳实践可以帮助您提高软件开发能力。
回页首
来自 IBM 的 Rational 软件可以提高企业的软件开发能力来帮助他们创造商业价值。Rational 软件开发平台综合了软件工程最佳实践、工具和服务。通过它企业可以提高响应能力、更富有弹性、更加专注，从而在当前随需应变的世界中脱颖而出。Rational 基于标准的跨平台解决方案可以帮助软件开发团队创建和扩展业务应用程序、嵌入式系统和软件产品。《财富》100 强中有 98 家公司依靠 Rational 工具更快地开发更好的软件。更多信息可以访问 www.rational.com 和 www.therationaledge.com，以及每月一期的 Rational 社区电子杂志。
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
IBM has authored this article
-
测试对象串行化
2007-08-30 11:20:14
Elliotte Harold (elharo@metalab.unc.edu), 副教授, Polytechnic University
2006 年 7 月 06 日
即使最杰出的开发人员有时也会忘记测试对象串行化，但那并不能作为您犯下同一错误的借口。在这篇文章中，Elliotte Rusty Harold 将解释对对象串行化进行单元测试的重要性，并为您展示一些应牢记的测试。
测试驱动的开发的总体原则之一就是应测试一个类已发布的所有接口。如果客户机能够调用方法或访问字段，那么就测试它。但在 Java™ 语言中，许多类都有一个已发布的接口容易被遗漏：通过类实例生成的串行化对象。有时这些类显式实现
Serializable。而有时则是直接从超类继承这一特性。在任何一种情况下，您都应该测试其串行化形式。本文将介绍几种测试对象串行化的方法。对串行化来说，测试极其重要，因为串行化非常非常容易出错。在修复 bug 或优化类时，非常容易破坏所有已有串行化对象。如果您在更改代码时未考虑串行化，几乎可以肯定您必将破坏原有对象。若您正在为任何形式的持久性存储使用串行化，那么这将是一个严重的 bug。即便仅为流程间的瞬时消息传递（如在 RMI 中）使用对象串行化，更改串行化格式也会使那些各类的版本不完全相同的系统无法顺利交换数据。
幸运的是，若您谨慎对待串行化问题，在处理类时通常可以避免不兼容的更改。Java 语言提供了多种方法，可维护一个类的不同版本之间的兼容性，包括：
serialVersionUIDtransient修饰符readObject()和writeObject()writeReplace()和readResolve()serialPersistentFields
对于这些解决方案来说，最大的问题就在于程序员未使用它们。当您将精力集中在修复 bug、添加特性或解决性能问题时，往往不会停下来思考您的更改对串行化造成的影响。然而串行化是一个涉及范围极广的问题 —— 跨越一个系统的多个不同层。几乎所有更改都会涉及对串行化有某种影响的一个类的实例字段。这正是单元测试发挥作用的时机。在本文后续各节中，我将为您展示一些简单的单元测试，这些单元测试能确保您不会不经意地更改可串行化类的串行格式。
通常您编写的第一个串行化测试就是用于验证串行化是否可行的测试。即使一个类实现了
Serializable，依然不能保证它能够串行化。例如，如果一个可串行化的容器（如ArrayList）包含一个不可串行化的对象（如Socket），则在您尝试串行化此容器时，将抛出NotSerializableException。通常，对此测试，您只需在
ByteArrayOutputStream上写入数据。若未抛出任何异常，测试即通过。如果您愿意，还可测试一些已写入的输出。例如，清单 1 所示代码片段用于测试 Jaxen 的BaseXPath类是否可串行化：
清单 1. 此类是否可串行化？
public void testIsSerializable() throws JaxenException, IOException { BaseXPath path = new BaseXPath("//foo", new DocumentNavigator()); ByteArrayOutputStream ōut = new ByteArrayOutputStream(); ObjectOutputStream ōos = new ObjectOutputStream(out); oos.writeObject(path); oos.close(); assertTrue(out.toByteArray().length > 0); }
接下来，您想要编写一个测试，不仅要验证输出得到了显示，还要验证输出是正确的。您可通过两种方式完成这一任务：
- 反串行化对象，并将其与原始对象相比较。
- 逐字节地将其与参考 .ser 文件相比较。
我通常会从第一种选择入手，因为它还提供了一个反串行化的简单测试，而且编码和实现相对来说比较容易。例如，清单 2 所示代码片段将测试 Jaxen 的
SimpleVariableContext类是否可写入并在之后重新读回：
清单 2. 反串行化对象，并将其与原始对象相比较
public void testRoundTripSerialization() throws IOException, ClassNotFoundException, UnresolvableException { // construct test object SimpleVariableContext ōriginal = new SimpleVariableContext(); original.setVariableValue("s", "String Value"); original.setVariableValue("x", new Double(3.1415292)); original.setVariableValue("b", Boolean.TRUE); // serialize ByteArrayOutputStream ōut = new ByteArrayOutputStream(); ObjectOutputStream ōos = new ObjectOutputStream(out); oos.writeObject(original); oos.close(); //deserialize byte[] pickled = out.toByteArray(); InputStream in = new ByteArrayInputStream(pickled); ObjectInputStream ōis = new ObjectInputStream(in); Object o = ois.readObject(); SimpleVariableContext copy = (SimpleVariableContext) o; // test the result assertEquals("String Value", copy.getVariableValue("", "", "s")); assertEquals(Double.valueOf(3.1415292), copy.getVariableValue("", "", "x")); assertEquals(Boolean.TRUE, copy.getVariableValue("", "", "b")); assertEquals("", ""); }
在测试代码基础中那些此前从未测试过的部分时，几乎总是会发现 bug，对象串行化也是这样。在我第一次运行清单 2 中的测试时，测试失败了，输出结果如清单 3 所示：
清单 3. 不可串行化
java.io.NotSerializableException: org.jaxen.QualifiedName at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at java.util.HashMap.writeObject(HashMap.java:984) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at org.jaxen.test.SimpleVariableContextTest.testRoundTripSerialization (SimpleVariableContextTest.java:90)
这表明，
SimpleVariableContext包含一个对QualifiedName对象的引用，QualifiedName类未标记为Serializable。我为QualifiedName的类签名添加了implements Serializable，这一次测试顺利通过。注意，此测试实际上并未验证串行化格式是否正确 —— 只是验证出对象能够来回转换。为测试正确性，您需要生成一些参考文件，以便与类的所有未来版本的输出相比较。
通常，您不能依赖默认串行化格式来保持类的不同版本间的文件格式兼容性。您必须使用
serialPersistentFields、readObject()和writeObject()方法和/或transient修饰符，通过各种方式进行定制。如果您确实对类的串行化格式做出了不兼容的更改，应相应更改serialVersionUID字段，以指出您这样做了。正常情况下，您不会过分关注串行化对象的详细结构。而只是关注最初使用的那种格式随着类的发展得到了维护。一旦类基本上具备了恰当的形式，即可写入一些类的串行化实例，并存储在随后可将其作为参考使用的位置处。（您很可能确实希望多多少少地考虑如何串行化才能确保足够的灵活性，以便应对未来的发展。）
编写串行化实例的程序是临时代码，只需使用一次。实际上，您根本就不应该多次运行这段代码，因为您不希望获得串行化格式中的任何意外更改。例如，清单 4 展示了用于串行化 Jaxen 的
SimpleVariableContext类的程序：
清单 4. 写入串行化实例的程序
import org.jaxen.*; import java.io.*; public class MakeSerFiles { public static void main(String[] args) throws IOException { OutputStream fout = new FileOutputStream("xml/simplevariablecontext.ser"); ObjectOutputStream ōut = new ObjectOutputStream(fout); SimpleVariableContext context = new SimpleVariableContext(); context.setVariableValue("s", "String Value"); context.setVariableValue("x", new Double(3.1415292)); context.setVariableValue("b", Boolean.TRUE); out.writeObject(context); out.flush(); out.close(); } }
您只需将一个串行化对象写入文件 —— 而且只需一次。这是您希望保存的文件，而不是用于写入的代码。清单 5 展示了 Jaxen 的
SimpleVariableContext类的兼容性测试：
清单 5. 确保文件格式未被更改
public void testSerializationFormatHasNotChanged() throws IOException, ClassNotFoundException, UnresolvableException { //deserialize InputStream in = new FileInputStream("xml/simplevariablecontext.ser"); ObjectInputStream ōis = new ObjectInputStream(in); Object o = ois.readObject(); SimpleVariableContext context = (SimpleVariableContext) o; // test the result assertEquals("String Value", context.getVariableValue("", "", "s")); assertEquals(Double.valueOf(3.1415292), context.getVariableValue("", "", "x")); assertEquals(Boolean.TRUE, context.getVariableValue("", "", "b")); assertEquals("", ""); }
默认情况下，类通常是可串行化的。例如，
java.lang.Throwable或java.awt.Component的任何子类都会从其祖先继承可串行性。在某些情况下，这也是您希望的结果，但并非总是如此。有的时候，串行化可能会成为安全漏洞，使恶意程序员能够在不调用构造函数或 setter 方法的情况下创建对象，从而规避了您小心翼翼地在类中构建的所有约束性检查。若您希望类可串行化，就需要测试它，这与您需要测试一个直接实现了
Serializable的类相同。如果您不希望类可串行化，则应重写writeObject()和readObject()，使两者均抛出NotSerializableException，随后您也需要对其进行测试。此类测试的实现方法与其他任何 JUnit 异常测试相似。只需在应抛出异常的语句两端包围一个
try块即可，随后紧接欲抛出异常的语句之后添加一条fail()语句。如果愿意，您还可在catch中作出一些关于所抛出异常的断言。例如，清单 6 验证了FunctionContext是不可串行化的：
清单 6. 测试 FunctionContext 是不可串行化的
public void testSerializeFunctionContext() throws JaxenException, IOException { DOMXPath xpath = new DOMXPath("/root/child"); FunctionContext context = xpath.getFunctionContext(); ByteArrayOutputStream ōut = new ByteArrayOutputStream(); ObjectOutputStream ōout = new ObjectOutputStream(out); try { oout.writeObject(context); fail("serialized function context"); } catch (NotSerializableException ex) { assertNotNull(ex.getMessage()); } }
Java 5 和 JUnit 4 使异常测试更为轻松。只需在
@Test注释中声明所需异常即可，如清单 7 所示：
清单 7. 带有注释的异常测试
@Test(expected=NotSerializableException.class) public void testSerializeFunctionContext() throws JaxenException, IOException { DOMXPath xpath = new DOMXPath("/root/child"); FunctionContext context = xpath.getFunctionContext(); ByteArrayOutputStream ōut = new ByteArrayOutputStream(); ObjectOutputStream ōout = new ObjectOutputStream(out); oout.writeObject(context); }
串行化格式可以说是代码基础中最脆弱、健壮性最差的部分。有的时候，似乎只要以奇异的眼神盯着它，它就会被破坏。单元测试和测试驱动的开发这些出色的工具使您可以信心十足地管理此类脆弱系统 —— 但只有在您确实使用了这些工具时，它们才能发挥作用。
若您关注对象串行化，特别是希望为长期持久性存储使用串行化对象时，就必须对串行化进行测试。不要假设您的 Java 代码所做的一切都是正确的 —— 它很可能会出错！如果您将串行化测试作为测试套件的固定部分，则维护长期兼容性就会更轻松。您花费在对象串行化单元测试上的时间将为您带来成倍的回报，此后调试时您能节省的时间将数倍于投入时间。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- “利用 Ant 和 JUnit 进行增量开发”（Malcolm Davis，developerWorks，2000 年 11 月）：介绍 Java 平台上的单元测试。
- “揭开极端编程的神秘面纱: 测试驱动的编程”（Roy Miller，developerWorks，2003 年 4 月）：介绍关于测试驱动编程的一切，更重要的是 —— 测试驱动编程与什么无关。
- “ Keeping critters out of your code”（David Carew，Sandeep Desai，Anthony Young-Garner，developerWorks，2003 年 6 月）：介绍服务器端应用服务器环境的单元测试。
- “JUnit 4 抢先看”（Elliotte Rusty Harold，developerWorks，2005 年 9 月）：介绍 JUnit 4 中基于注释的全新架构，需要 Java 5 或更新版本。
- Java I/O，第 2 版（Elliotte Rusty Harold；O'Reilly，2006 年 5 月）：深入讨论对象串行化的新版图书。
- Pragmatic Unit Testing（Dave Thomas 和 Andy Hunt；Pragmatic Programmer，2003 年 9 月）：单元测试 Java 代码的完整介绍。
- Java 技术专区：数百篇关于 Java 编程各个方面的文章。
获得产品和技术
- JUnit：影响您的测试。
讨论
- developerWorks blogs：加入 developerWorks 社区。
Elliotte Rusty Harold 来自新奥尔良， 现在他还定期回老家喝一碗美味的秋葵汤。不过目前，他和妻子 Beth 定居在纽约临近布鲁克林的 Prospect Heights，同住的还有他的猫咪 Charm（取自夸克）和 Marjorie（取自他岳母的名字）。他是 Polytechnic 大学计算机科学系的一名副教授，讲授 Java 和面向对象编程。他的 Cafe au Lait Web 站点已经成为 Internet 上最流行的独立 Java 站点之一，它的姊妹站点 Cafe con Leche 是最流行的 XML 站点之一。他编写的图书包括 Effective XML、Processing XML with Java、Java Network Programming 和 Java I/O。目前，他在从事处理 XML 的 XOM API、Jaxen XPath 引擎和 Jester 测试覆盖工具的开发工作。
-
模糊测试
2007-08-30 10:58:56
Elliotte Harold (elharo@metalab.unc.edu), 副教授, Polytechnic 大学
2006 年 11 月 02 日
模糊测试（Fuzz testing ）是一项对代码质量有着深远影响的简单技术。在本文中，Elliotte Rusty Harold 故意将随机的坏数据插入应用程序，以观察发生的结果。他也解释了如何使用如校验和、XML 数据存储及代码验证等防护性编码技术，来加固您的程序以抵制随机数据。他以一个练习进行总结，在练习中他以一个代码破坏者的角度进行思考 —— 这是一种用于防护代码的至关重要的技术。
多年来，我惊叹于有如此大量能够使 Microsoft Word 崩溃的坏文件。少数字节错位，会使整个应用程序毁于一旦。在旧式的、无内存保护的操作系统中，整个计算机通常就这样宕掉了。Word 为什么不能意识到它接收到了坏的数据，并发出一条错误信息呢？为什么它会仅仅因为少数字节被损坏就破坏自己的栈、堆呢？当然，Word 并不是惟一一个面对畸形文件时表现得如此糟糕的程序。
本文介绍了一种试图避免这种灾难的技术。在模糊测试中，用随机坏数据（也称做 fuzz）攻击一个程序，然后等着观察哪里遭到了破坏。模糊测试的技巧在于，它是不符合逻辑的：自动模糊测试不去猜测哪个数据会导致破坏（就像人工测试员那样），而是将尽可能多的杂乱数据投入程序中。由这个测试验证过的失败模式通常对程序员来说是个彻底的震憾，因为任何按逻辑思考的人都不会想到这种失败。
模糊测试是一项简单的技术，但它却能揭示出程序中的重要 bug。它能够验证出现实世界中的错误模式并在您的软件发货前对潜在的应当被堵塞的攻击渠道进行提示。
模糊测试的实现是一个非常简单的过程：
- 准备一份插入程序中的正确的文件。
- 用随机数据替换该文件的某些部分。
- 用程序打开文件。
- 观察破坏了什么。
可以用任意多种方式改变该随机数据。例如，可以将整个文件打乱，而不是仅替换其中的一部分，也可以将该文件限制为 ASCII 文本或非零字节。不管用什么方式进行分割，关键是将大量随机数据放入应用程序并观察出故障的是什么。
测试基于 C 的应用程序
当字符串包含额外的零时，许多用 C 编写的程序都会出问题 —— 这类问题太过频繁以至于额外的零能够彻底隐藏代码中其他的问题。一旦验证出程序存在零字节问题，就可以移除它们，从而让其他的问题浮现出来。可以手动进行初始化测试，但要想达到最佳的效果则确实需要采用自动化模糊测试。在这种情况下，当面临破坏输入时首先需要为应用程序定义适当的错误行为。（如果当输入数据被破坏时，您发现程序正常运行，且未定义发生的事件，那么这就是第一个 bug。）随后将随机数据传递到程序中直到找到了一个文件，该文件不会触发适当的错误对话框、消息、异常，等等。存储并记录该文件，这样就能在稍后重现该问题。如此重复。
尽管模糊测试通常需要一些手动编码，但还有一些工具能提供帮助。例如，清单 1 显示了一个简单的 Java™ 类，该类随机更改文件的特定长度。我常愿意在开始的几个字节后面启动模糊测试，因为程序似乎更可能注意到早期的错误而不是后面的错误。（您的目的是想找到程序未检测到的错误，而不是寻找已经检测到的。）
清单 1. 用随机数据替换文件部分的类
import java.io.*; import java.security.SecureRandom; import java.util.Random; public class Fuzzer { private Random random = new SecureRandom(); private int count = 1; public File fuzz(File in, int start, int length) throws IOException { byte[] data = new byte[(int) in.length()]; DataInputStream din = new DataInputStream(new FileInputStream(in)); din.readFully(data); fuzz(data, start, length); String name = "fuzz_" + count + "_" + in.getName(); File fout = new File(name); FileOutputStream ōut = new FileOutputStream(fout); out.write(data); out.close(); din.close(); count++; return fout; } // Modifies byte array in place public void fuzz(byte[] in, int start, int length) { byte[] fuzz = new byte[length]; random.nextBytes(fuzz); System.arraycopy(fuzz, 0, in, start, fuzz.length); } }
关于代码
我可以用很多种方式优化 清单 1 中的代码。例如，有着java.nio的内存映射文件是一个相当不错的选择。我也能够改进这个错误处理及可配置性。因为不想让这些细节混淆这里所要说明的观点，所以我将代码保持了原样。模糊测试文件很简单。将其传至应用程序通常不那么困难。如 Applescrīpt 或 Perl 脚本语言通常是编写模糊测试的最佳选择。对于 GUI 程序，最困难的部分是辨认出应用程序是否检测出正确的故障模式。有时，最简单的方法是让一个人坐在程序前将每一个测试通过或失败的结果都标记下来。一定要将所有生成的随机测试用例单独地命名并保存下来，这样就能够重现这个过程中检测到的任何故障。
可靠的编码遵循了这样的基本原则：绝不会让程序中插入未经过一致性及合理性验证的外部数据。
如果从文件中读入一个数字并期望其为正数，那么，在使用其进行进一步处理前对其先验证一下。如果期望字符串只包含 ASCII 字母，请确定它确实是这样。如果认为文件包含一个四字节的整数倍的数据，请验证一下。一定不要假设任何外部提供的数据中的字符都会如您所料。
最常见的错误是做出这样的假设：因为程序将该数据写出，该程序就能不用验证再一次将该数据读回去。这是很危险的！因为该数据很可能已经被另一个程序在磁盘上复写过了。它也可能已经被一个故障磁盘或坏的网络传输所破坏了或已经被另一个带 bug 的程序更改过了。它甚至可能已经被故意更改过以破坏程序的安全性。所以不要假设任何事，要进行验证。
当然，错误处理及验证十分令人生厌，也很不方便，并被全世界程序员们所轻视。计算机的诞生已进入了六十个年头，我们仍旧没有检查基本的东西，如成功打开一个文件及内存分配是否成功。让程序员们在阅读一个文件时测试每一个字节和每一个不变量似乎是无望的 —— 但不这样做就会使程序易被模糊攻击。幸运的是，可以寻求帮助。恰当使用现代工具和技术能够显著减轻加固应用程序的痛苦，特别是如下三种技术更为突出：
- 校验和
- 基于语法的格式，如 XML
- 验证过的代码如 Java
能够保护程序抵御模糊攻击的最简单的方法是将一个检验和添加到数据中。例如，可以将文件中所有的字节都累加起来，然后取其除以 256 的余数。将得到的值存储到文件尾部的一个额外字节中。然后，在输入数据前，先验证检验和是否匹配。这项简单模式将未被发现的意外故障的风险降低到约 1/256 。
健壮的校验和算法如 MD5 和 SHA 并不仅仅取其除以 256 的余数，它完成的要多得多。在 Java 语言中，
java.security.DigestInputStream和java.security.DigestOutputStream类为将一个校验和附属到数据中提供了便捷的方式。使用这些校验和算法中的一种可以将程序遭受意外破坏的机率降低到少于十亿分之一（尽管故意攻击仍有可能）。将数据以 XML 形式存储是一种避免数据损坏的好方法。XML 最初即着力于 Web 页面、书籍、诗歌、文章及相似文档，它几乎在每个领域都获取了巨大的成功，从金融数据到矢量图形到序列化对象等等。
不切实际的限定
如果真想要破坏一个 XML 解析器，有几种方法可以试试。例如，大多数 XML 解析器服从于特定的最大尺寸。如果一个元素名长度超过 22 亿字符（JavaString的最大尺寸），SAX 解析器将会失败。尽管如此，在实践中这些极限值如此之高，以至于在达到之前内存就已经耗尽。使 XML 格式抵制模糊攻击的关键特征是一个对输入不做任何 假设的解析器。这就是真正想在一个健壮的文件格式中所获得的。设计 XML 解析器是为了让任何输入（格式良好的或无格式的，有效的或无效的）都以定义好的形式处理。XML 解析器能够处理任何 字节流。如果数据首先通过了 XML 解析器，则仅需要准备好接受解析器所能提供的东西。例如，不需要检查数据是否包含空字符，因为 XML 解析器绝不会传送一个空值。如果 XML 解析器在其输入中看到一个空字符，它就会发出异常并停止处理。当然还需要处理这个异常，但编写一个
catch块来处理检测到的错误比起编写代码来检测所有可能的错误来说要简单得多。为使程序更加安全，可以用 DTD 和/或模式来验证文档。这不仅检查了 XML 是否格式良好，而且至少与所预期更加接近。验证并不会告知关于文档所需了解的一切，但它却使编写大量简单检查变得很简单。用 XML，很明显能够将所接受的文档严格地限定为能够处理的格式。
尽管如此，还有多段代码不能用 DTD 或模式进行验证。例如，不能测试发票上商品的价格是否和数据库中库存商品的价格一致。当从客户接收到一份包含价格的订单文档时，不论其是 XML 格式或是其他格式，在提交前通常都会检查一下，以确保客户并未修改价格。可以用定制代码实现这些最后的检查。
使 XML 能够对模糊攻击具有如此的抵御能力的是其使用巴科斯-诺尔范式（Backus-Naur Form，BNF）语法仔细且标准地定义的格式。许多解析器都是使用如 JavaCC 或 Bison 等解析器-生成器工具直接从此语法中构建的。这种工具的实质是阅读一个任意的输入流并确定其是否符合此语法。
如果 XML 并不适合于您的文件格式，您仍可以从基于解析器的解决方案的健壮性中获益。您必须为文件格式自行编写语法，随后开发自己的解析器来阅读它。相比使用唾手可得的 XML 解析器，开发自己的解析器需要更多的工作。然而它是一个更为健壮的解决方案，而不是不根据语法正式地进行验证就将数据简单地装载到内存中。
由模糊测试导致的许多故障都是内存分配错误及缓冲器溢出的结果。用一种安全的垃圾收集语言（在如 Java 或 managed C# 等虚拟机上执行的）来编写应用程序避免了许多潜在问题。即使用 C 或 C++ 来编写代码，还是需要使用一个可靠的垃圾收集库。在 2006 年，台式机程序员或服务器程序员不应该还需要管理内存。
Java 运行时对其自身的代码起到了额外保护层的作用。在将一个 .class 文件装载到虚拟机之前，该文件要由一个字节符验证器或一个可选的
SecurityManager进行验证。Java 并不假设创建 .class 文件的编译器没有 bug 且运转正常。设计 Java 语言之初就是为了允许在一个安全沙箱中运行不信任的、潜在恶意的代码。它甚至不信任其自身编译过的代码。毕竟，也许有人已经用十六进制编辑器手工修改了字节符，试图触发缓冲器溢出。我们大家都应该对我们的程序也有对输入这样的偏执。
回页首
之前介绍的每项技术都在阻止意外破坏方面造诣颇深。将它们综合起来恰当地实现，会将未被发现的非蓄意破坏发生的可能性几乎减少到零。（当然，并不会减少到零，但其发生的可能性就如同一束偏离轨道的宇宙射线将您 CPU 运算 1+1 的结果变为 3 的可能性一样微乎其微。）但不是所有的数据损坏都是非蓄意的。如果有人故意引入坏数据来破坏程序的安全性又该如何呢？以一个攻击者的角度进行思考是防护代码的下一个步骤。
转回到一个攻击者的角度进行思考，假设要攻击的应用程序是用 Java 编程语言编写的、使用非本地代码且将所有额外数据都以 XML（在接受前经过彻底验证）形式存储，还能成功攻击吗？是的，能。但用随机改变文件字节的低级方法显然不行。需要一种更为复杂的方法来说明程序自身的错误检测机制及路径。
当测试一个抵御模糊攻击的应用程序时，不可能做纯黑盒测试，但通过一些明显的修改，基本的想法还是可以应用的。例如，考虑校验和，如果文件格式包含一个校验和，在将文件传至应用程序前仅仅修改此校验和就可以使其同随机数据相匹配。
对于 XML，试着模糊单独的元素内容和属性值，而不是从文档中挑选一部分随机的字节进行替换。一定要用合法的 XML 字符替换数据，而不要用随机字节，因为即使一百字节的随机数据也一定是畸形的。也可以改变元素名称和属性名称，只要细心地确保得到的文档格式仍是正确的就可以了。如果该 XML 文档是由一个限制非常严格的模式进行检查的，还需要计算出该模式没有 检查什么，以决定在哪里进行有效的模糊。
一个结合了对剩余数据进行代码级验证的真正严格的模式也许不会留下可操纵的空间。这就是作为一个开发人员所需要追求的。应用程序应能够处理所发送的任何有意义的字节流，而不会因权利上（ de jure ） 无效而拒绝。
回页首
模糊测试能够说明 bug 在程序中的出现。并不证明不存在这样的 bug。而且，通过模糊测试会极大地提高您对应用程序的健壮性及抵御意外输入的安全性的自信心。如果您用 24 小时对程序进行模糊测试而其依然无事，那么随后同种类型的攻击就不大可能再危及到它。（并不是不可能，提醒您，只是可能性很小。）如果模糊测试揭示出程序中的 bug，就应该进行修正，而不是当 bug 随机出现时再对付它们。模糊测试通过明智地使用校验和、XML、垃圾收集和/或基于语法的文件格式，更有效地从根本上加固了文件格式。
模糊测试是一项用于验证程序中真实错误的重要工具，也是所有意识到安全性问题且着力于程序健壮性的程序员们的工具箱中所必备的工具。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- 追求代码质量：想要了解更多吗？这里的整个 developerWorks 系列是有关当今代码测试技术的。
- “Java 语言的 XML 验证 API”（Elliotte Rusty Harold，developerWorks，2006 年 8 月 )：看看 Java 5 XML 验证 API 能够对您有什么帮助。
- “在编码之前进行测试” （Gary Pollice，developerWorks，2004 年 6 月）：本文描述了优先测试的程序设计概念和实践。
- “Macintosh stories: Monkey Lives” （Andy Hertzfeld，Folklore）：描述了对第一台 Macintosh 进行的模糊测试（尽管该术语那时还未被发明）。
- “An Empirical Study of the Reliability of UNIX Utilities” (B.P. Miller，L. Fredriksen，B. So; Communications of the ACM 33，1990 年 12 月)：首次使用模糊 一词来描述基于随机数据的测试。
- “Fuzz Testing of Application Reliability”：最初的有关模糊测试的网站。
- “Obscuring XML” （Elliotte Rusty Harold，Extreme Markup Languages 2005）：这篇论文介绍了一种在维持良好格式的同时将 XML 数据随机化的工具。那时其目标在于协助 bug 报告，但同样的技术也可以用于模糊测试 XML。
- Java I/O，第 12 章 （Elliotte Rusty Harold，O'eilly，2006）：使用
DigestInputStream和DigestOutputStream类来探讨在 Java 中计算校验和。
- Wikipedia: Fuzz testing：被广泛认可的优秀条目。
- Java 技术专区：数百篇关于 Java 编程各方面的文章。
- 随时关注 developerWorks 技术事件和网络广播。
获得产品和技术
- Fuzzers: The ultimate list：由 Jack Koziol 收集的各种开源模糊测试工具。
讨论
- 改进代码质量论坛：作为专注于改进代码质量的顾问，Andrew Glover 将自己的许多专业意见都带到了这个他主持的讨论组中。
Elliotte Rusty Harold 来自新奥尔良， 现在他还定期回老家喝一碗美味的秋葵汤。不过目前，他和妻子 Beth 定居在纽约临近布鲁克林的 Prospect Heights，同住的还有他的猫咪 Charm（取自夸克）和 Marjorie（取自他岳母的名字）。他是 Polytechnic 大学计算机科学的副教授，他在该校讲授 Java 和面向对象编程。他的 Web 站点 Cafe au Lait 已经成为 Internet 上最流行的独立 Java 站点之一，它的姊妹站点 Cafe con Leche 已经成为最流行的 XML 站点之一。他的书包括 Effective XML、 Processing XML with Java、 Java Network Programming 和 The XML 1.1 Bible。他目前在从事处理 XML 的 XOM API、Jaxen XPath 引擎和 Jester 测试覆盖率工具的开发工作。
-
成功的 Web 应用系统性能测试
2007-08-30 10:53:37
杨敏强 (myang@cn.ibm.com), 软件工程师, IBM
2007 年 6 月 26 日
性能测试是 Web 应用系统的一项重要质量保证措施。在现实中，很多 Web 性能测试项目由于性能测试需求定义不合理或不明确，导致性能测试项目不能达到预期目标或进度超期。本文针对 Web 应用系统的技术架构和系统使用特点，探讨如何有效实施性能测试过程，并重点介绍如何分析获得合理的性能测试需求，最终对 Web 应用系统性能进行科学、准确的评估。
基于Web服务器的应用系统由于提供浏览器界面而无须安装，大大降低了系统部署和升级成本，得以普遍应用。目前，很多企业的核心业务系统均是Web应用，但当Web应用的数据量和访问用户量日益增加，系统不得不面临性能和可靠性方面的挑战。因此，无论是Web应用系统的开发商或最终用户，都要求在上线前对系统进行性能，科学评价系统的性能，从而降低系统上线后的性能风险。
在很多性能测试项目中，由于不能合理定义系统的性能测试需求，不能建立和真实环境相符的负载模型，不能科学分析性能测试结果，导致性能测试项目持续时间很长或不能真正评价系统性能并提出性能改进措施。
本文在总结许多Web应用系统性能测试实践经验和教训的基础上，从与性能测试工具无关的角度介绍Web应用系统性能测试的方法和实施过程，以及如何定义合理的性能测试需求。
性能测试：通过模拟大量浏览器客户端同时访问Web服务器，获得系统的性能数据。
虚拟用户：模拟浏览器向Web服务器发送请求并接收响应的一个进程或线程。
响应时间：浏览器向Web服务器提交一个请求到收到响应之间的间隔时间。
思考时间：浏览器在收到响应后到提交下一个请求之间的间隔时间。
请求成功率：Web服务器正确处理的请求数量和接收到的请求数量的比。
吞吐量：单位时间内Web服务器成功处理的HTTP页面或HTTP请求数量。
在线用户：用户通过浏览器访问登录Web应用系统后，并不退出该应用系统。通常一个Web应用服务器的在线用户对应Web应用服务器的一个Session。
并发用户数：Web服务器在一段时间内为处理浏览器请求而建立的HTTP连接数或生成的处理线程数。当所有在线用户发送HTTP请求的思考时间为零时，Web服务器的并发用户数等于在线用户数。
Web应用系统的前端为浏览器，后台为Web服务器（如Apache，Microsoft Internet Information Server），浏览器和Web服务器之间的交互基于HTTP协议。HTTP协议本身是无连接的，Web服务器通过Session机制来建立一个浏览器所发出的先后连接之间的关联。通过实验证明，当浏览器客户端在首次访问Web服务器后，如果该浏览器客户端不发送后续请求，服务器维持该浏览器客户端的Session变量所消耗的系统资源非常小。
标准的Web应用系统性能测试过程包括确定性能测试需求，开发性能测试脚本，定义性能测试负载模型，执行性能测试和形成性能测试报告。本章将分别介绍上述过程，并通过举例说明如何完成每一环节。
科学定义Web应用系统性能测试需求对一个成功的性能测试非常重要。通常，Web应用系统的性能测试需求有如下两种描述方法。
2.1.1 基于在线用户的性能测试需求
该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统， 通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问网上购物系统的下定单功能，下定单交易的成功率是100%，而且90%的下定单请求响应时间不大于8秒；当90%的请求响应时间不大于用户的最大容忍时间20秒时，系统能支持50个在线用户。
2.1.2 基于吞吐量的性能测试需求
该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定，如基于Internet的网上购物系统，可通过每天下定单的业务量直接计算其吞吐量，从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例，基于吞吐量的性能测试需求可描述为：网上购物系统在每分钟内需处理10笔下定单操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。
在确定Web应用系统性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。比如，针对前面定义的网上购物系统的性能测试需求，将开发下定单功能的性能测试脚本。
性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具（如IBM Rational Performance Tester， LoadRunner）所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本，也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。
任何性能测试工具都不能保证录制形成的性能测试脚本的正确性，测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确，也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本，脚本能完成期望的功能。
在完成性能测试脚本的数据关联后，需要对脚本进行参数化，也就是把脚本中的某些请求数据替换成变量，变量的值来于一个独立的数据文件，从而保证在多虚拟用户运行脚本的情况下，每个虚拟用户所提交的数据是不同的。
此外，为了测试Web应用的可靠性，还需要对请求所收到的响应进行验证（比如验证响应的HTTP返回码或验证响应的内容），便于性能测试完成后统计请求成功率。
性能测试负载模型定义了测试工具如何向Web应用系统提交请求，包括向Web应用系统发送请求的虚拟用户数，每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求，在性能测试工具中定义的性能测试负载模型应包括如下信息：
虚拟用户数：性能测试不仅仅是执行一次，而且每次执行时虚拟用户数也不固定，因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。
虚拟用户发送请求的思考时间和迭代次数：虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一，而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求，将基于录制脚本时记录的思考时间，而且由于现实中不同用户访问系统的思考时间不同，可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求，将把思考时间设置为零，此时Web应用系统的在线用户数量将等于并发用户数。同时，为了避免性能测试压力的随机性，将增加请求的迭代次数来增加测试执行持续时间，从而获得系统在稳定压力下的性能数据。
虚拟用户启动模式：在现实中，Web应用系统的用户不太可能同时做相同的操作，因此为了让Web应用系统所承担的压力随时间均匀分布，建议虚拟用户依次启动，同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例，可设置每个虚拟用户间隔30秒启动，这样10个虚拟用户可在5分钟后完成启动，并保证10个虚拟用户不会在同一时刻下定单，从而更符合实际情况。
执行性能测试是指通过多次运行性能测试负载模型，获得系统的性能数据。在执行过程中，需利用测试工具、操作系统、系统软件（如Web Server或DB Server）提供的资源监控手段对资源进行监控和分析，帮助发现资源瓶颈，并在系统层面进行优化。同时，还需对应用进行性能分析，帮助定位应用代码中的性能问题，切实解决系统的性能问题。
性能测试项目的最后阶段就是向相关人员提交性能测试报告，汇报性能测试结果。在向相关人员汇报性能测试结果时，并不是性能测试报告越丰富、性能数据越多越好。好的性能测试报告是能准确、简单地传递性能测试结论，而不需太多的技术细节。
针对基于在线用户数的性能测试需求，可通过下图总结性能测试结论。其中横轴是在线用户数，纵轴是响应时间，如40在线用户访问网上购物系统时，90%的下定单请求响应时间不超过10秒。
图一：在线用户数和响应时间时间的趋势图
针对基于吞吐量的性能测试需求，可通过下图的曲线来描述性能测试结果。以网上购物系统为例，下图描述下定单的并发用户、下定单响应时间以及吞吐量（服务器每秒处理定单笔数）之间的关系，从而快速判断系统是否能满足性能测试需求。从下图中可看出，并发用户增加，请求的响应时间也增加。服务器的吞吐量是先随并发用户数增加而增加，当吞吐量到达一定峰值后，再增加并发用户数，吞吐量会减少。原因在于当并发用户数少时，向Web服务器提交的请求量不大，服务器处理能力还有富余，所以吞吐量逐步增大；但当并发用户数超过某一值时，由于向服务器提交的请求太多，造成服务器阻塞，反而导致吞吐量减少。
图二：响应时间、吞吐量和并发用户数的趋势图
前一章介绍了Web应用系统的性能测试过程，确定性能测试需求是整个性能测试的起点和成功的重要因素。性能测试需求定义得过高，虽然确保系统上线后能满足性能需求，但可能会造成硬件资源的浪费；性能测试需求定义得过低，系统上线后可能会出现性能问题。如何通过分析系统上线后可能的用户访问行为，来获得合理的性能测试需求指标呢？
假设现有一个基于Web的办公自动化系统（简称OA系统），该系统提供公文收发和查询功能。在部署该系统前，将对该系统进行性能测试。下面将详细介绍如何分析该OA系统的使用情况，定义合理的性能测试需求。
在线用户数量是指在特定时间区间内，有多少用户访问Web应用系统（对应到Web服务器的Session数），根据系统可能访问用户数以及每个用户访问系统的时间长短来确定。
对于将要部署的OA系统，通过分析获得该系统有8000个注册用户，基本上所有的用户每天（8小时工作时间）都会访问OA系统，平均在线时间（从登录OA系统到退出OA系统之间的时间间隔，也可以是多次在线时间的合计）为12分钟，那么该OA系统的平均在线数（也就是Web应用Session变量数）为200个（8000 * 0.2 / 8），假设峰值在线用户数是平均在线用户数的3倍（该倍数可根据实际情况调整），则性能测试需求的在线用户数为600。
由于时间和资源限制，不可能对Web应用系统的所有功能进行性能测试，而是从业务的角度（如某一功能操作的用户多）和技术的角度（如某一功能虽然访问用户不多，但内部处理逻辑复杂或处理数据量大）来选择Web应用系统的特定功能作为性能测试用例。
以OA系统为例，由于所有用户都经常公文查询功能，因此确定的性能测试用例为公文查询。
响应时间的快慢直接影响了系统使用用户的满意度，采用平均响应时间来描述系统系统性能测试需求是不科学的，因为无法直接和客户的满意度挂钩。而且，在做性能测试，如果某一请求的响应时间过长或过短，将导致平均响应时间和实际情况偏离。
以OA系统为例，定义的响应时间需求为：90%（该百分比和要求的系统用户满意度相关）的查询请求响应时间不超过8秒（该时间可根据实际情况确定）。
单位时间内Web应用系统需处理多少笔特定的交易可通过统计获得。以OA系统为例，假设每个用户每天（一天按8小时计算）平均会查询公文4次，那OA应用的Web服务器平均每分钟要能处理8000 * 4 / ( 60 * 8 ) = 66.67笔查询公文交易，考虑到峰值因素，要求每分钟能处理66.7 * 3=200笔查询公文交易。
通过前面的分析，能明确定义合理的性能测试需求。OA系统性能测试需求定义如下：
基于在线用户数的性能测试需求：600个在线用户按正常操作速度访问OA系统的查询公文功能，所有查询请求的成功率是100%，而且90%的查询请求响应时间不大于8秒。
基于吞吐量的性能测试需求：OA系统在每分钟内需处理200笔查询公文操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。
Web应用性能测试项目成功的关键不在于性能测试工具，而在于有效的性能测试分析方法和实践。只有切实掌握性能测试需求分析方法，性能测试实践经验，才能保证一个Web应用性能测试的成功。
- 请访问 IBM developerWorks 中国网站 Rational 专区 能得到更多关于 IBM IBM Rational 产品的文章、教程和其他参考资源。
杨敏强，IBM Rational 软件工程师。
- 请访问 IBM developerWorks 中国网站 Rational 专区 能得到更多关于 IBM IBM Rational 产品的文章、教程和其他参考资源。
-
OA与CRM、ERP的关系和功能层次
2007-08-30 10:42:30
传统的ERP/CRM等管理软件多侧重于管理包括现金流、物流，建立一个刚性的管理系统，并且呈现出流程化、规范化的特征，而OA软件则转向管人、管事，后者称为“老板级的信息化”，如所示。
现在企业发展变化快，不光是新产品推出快，整个组织结构也要快速变化适应新形势。但ERP很难做到这一点。ERP要求企业所有的流程都要为了适应它而重新规划重组，它要适应后台管理的变化真是无能为力，这却是OA的强项。
OA使用户的管理及业务人员不再受办公室和网络的约束，从而实现一种移动办公、在家办公、远程办公等多种办公形式。另外，虽然坐在办公室内，管理的范围却并不局限于办公室，远在万里之外的分公司、办事处、其他城市的合作伙伴、经销商等，所有的沟通管理都可以突破办公室的边界。
所以，上过ERP的厂家，会需要OA软件作为补充；一个企业想上信息化系统的时候，也可以选择先上OA软件，通过OA软件建造一个柔性系统，将来再逐步地去扩展刚性系统。功能层次
不同的办公环境要求不同类型的办公自动化系统，如政府和企业的办公自动化类型就不同。总的来讲办公自动化系统的基本功能[3]有：
事务处理功能
事务处理功能是处理办公部门中大量的事务性工作，这种工作量大，重复性高。使用办公自动化系统来处理可以使办公人员从这些工作中解脱出来。事务型为基础层，包括文字处理、个人日程管理、行文管理、邮件处理、人事管理、资源管理，以及其他有关机关行政事务处理等等
信息管理功能
信息管理功能就是对信息的流通进行控制和管理，做好对信息的收集、加工、传递、交流、存取、分析、判断和反馈，从而使信息资源的利用获得良好的效益。管理型为中间层，它包含事务型，管理型系统是支持各种办公事务处理活动的办公系统与支持管理控制活动的管理信息系统相结合的办公系统。
辅助决策功能
辅助决策功能是指办公自动化系统要有决策或辅助决策功能，在对大量信息进行分析的基础之上分析制定出各种优化解决方案提供给决策者。决策型为最高层，它以事务型和管理型办公系统的大量数据为基础，同时又以其自有的决策模型为支持，决策层办公系统是上述系统的再结合，具有决策或辅助决策功能的最高级系统。 -
网站和OA系统的建设
2007-08-30 10:40:58
-
OA系统应用开发后的用户测试
2007-08-30 10:39:51
-
企业OA系统与政府政务OA的差别
2007-08-30 10:39:02
-
企业OA入门(完整版)
2007-08-30 10:38:07
-
VBScript中的正则表达式语法详解
2007-08-21 10:11:38
-
JavaScript正则表达式
2007-08-21 10:10:46
-
JScript 和 VBScript 正则表达式特殊字符
2007-08-21 10:02:50
-
什么是正则表达式
2007-08-21 09:59:32
