在本文中，我们要讨论为什么进行测试，尤其是自动化测试，是必需的。然后，我们将介绍制定计划的概念：为什么制定计划是如此的重要？在随后的文章中，我们将分解测试计划中的不同因素，并且研究如何进行制定计划的过程才能最大程度地增加成功的机会。

现代客户端/服务器应用程序是非常复杂的，因此测试也就成为开发过程中关键的并且至关重要的一部分。现在，没有人会考虑（或者承认）不对自己开发的软件进行测试工作。但是，研究和调查表明，在软件开发过程中，制定测试计划却常常是优先级较低的工作项目。而且，更加糟糕的是，计划往往没有被执行，或者即使执行了，也进行的不很完整、不很准确，或者没有持续进行。

假设我们都赞成测试是必要的，那么我们接下来必须回答这些问题：我们如何进行测试？实际上都包括哪些内容？我们如何保证已经进行了有效的工作，并且真正地改善了应用程序的质量？

答案很简单：制定计划。

本文是系列文章中的第一篇，该系列文章将评审在软件生命周期中制定测试计划的作用，以及有效制定测试计划的有关概念。在本文中，我们要讨论为什么进行测试，尤其是自动化测试，是必需的。然后，我们将介绍制定计划的概念：为什么制定计划是如此的重要？在随后的文章中，我们将分解测试计划中的不同因素，并且研究如何进行制定计划的过程才能最大程度地增加成功的机会。

为什么花费精力制定计划？

现在看来，没有怎么制定测试计划而造成的后果比以前更加明显了。失败的案例有很多--看看报纸或者杂志就知道了。还有一些明显的低质量软件的案例，它们包括：

• 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 软件集成解决方案

IBM Rational 支持大量的 IBM 软件产品。IBM 软件解决方案可以赋予您实现优先业务和 IT 目标的能力。

• DB2® 软件提供了数据支持、数据管理和数据分布的解决方案，可以帮助您有效地利用数据。
• Lotus® 软件提供了编辑、管理、交流和共享知识的解决方案，可以帮助提高职员的生产率。
• Tivoli® 软件帮助您管理那些运行在您的电子商务基础设施上的技术。
• WebSphere® 软件帮助您把原来的关键业务扩展到 Web 上。
• Rational® 软件提供的工具、服务和最佳实践可以帮助您提高软件开发能力。

回页首

IBM 的 Rational 软件

来自 IBM 的 Rational 软件可以提高企业的软件开发能力来帮助他们创造商业价值。Rational 软件开发平台综合了软件工程最佳实践、工具和服务。通过它企业可以提高响应能力、更富有弹性、更加专注，从而在当前随需应变的世界中脱颖而出。Rational 基于标准的跨平台解决方案可以帮助软件开发团队创建和扩展业务应用程序、嵌入式系统和软件产品。《财富》100 强中有 98 家公司依靠 Rational 工具更快地开发更好的软件。更多信息可以访问 www.rational.com 和 www.therationaledge.com，以及每月一期的 Rational 社区电子杂志。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  

关于作者

		IBM has authored this article

Elliotte Harold (elharo@metalab.unc.edu), 副教授, Polytechnic University

2006 年 7 月 06 日

即使最杰出的开发人员有时也会忘记测试对象串行化，但那并不能作为您犯下同一错误的借口。在这篇文章中，Elliotte Rusty Harold 将解释对对象串行化进行单元测试的重要性，并为您展示一些应牢记的测试。

测试驱动的开发的总体原则之一就是应测试一个类已发布的所有接口。如果客户机能够调用方法或访问字段，那么就测试它。但在 Java™ 语言中，许多类都有一个已发布的接口容易被遗漏：通过类实例生成的串行化对象。有时这些类显式实现 Serializable。而有时则是直接从超类继承这一特性。在任何一种情况下，您都应该测试其串行化形式。本文将介绍几种测试对象串行化的方法。

测试串行化

对串行化来说，测试极其重要，因为串行化非常非常容易出错。在修复 bug 或优化类时，非常容易破坏所有已有串行化对象。如果您在更改代码时未考虑串行化，几乎可以肯定您必将破坏原有对象。若您正在为任何形式的持久性存储使用串行化，那么这将是一个严重的 bug。即便仅为流程间的瞬时消息传递（如在 RMI 中）使用对象串行化，更改串行化格式也会使那些各类的版本不完全相同的系统无法顺利交换数据。

幸运的是，若您谨慎对待串行化问题，在处理类时通常可以避免不兼容的更改。Java 语言提供了多种方法，可维护一个类的不同版本之间的兼容性，包括：

• serialVersionUID
• transient 修饰符
• readObject() 和 writeObject()
• writeReplace() 和 readResolve()
• serialPersistentFields

对于这些解决方案来说，最大的问题就在于程序员未使用它们。当您将精力集中在修复 bug、添加特性或解决性能问题时，往往不会停下来思考您的更改对串行化造成的影响。然而串行化是一个涉及范围极广的问题 —— 跨越一个系统的多个不同层。几乎所有更改都会涉及对串行化有某种影响的一个类的实例字段。这正是单元测试发挥作用的时机。在本文后续各节中，我将为您展示一些简单的单元测试，这些单元测试能确保您不会不经意地更改可串行化类的串行格式。

我能否将其串行化？

通常您编写的第一个串行化测试就是用于验证串行化是否可行的测试。即使一个类实现了 Serializable，依然不能保证它能够串行化。例如，如果一个可串行化的容器（如 ArrayList）包含一个不可串行化的对象（如 Socket），则在您尝试串行化此容器时，将抛出 NotSerializableException。

通常，对此测试，您只需在 ByteArrayOutputStream 上写入数据。若未抛出任何异常，测试即通过。如果您愿意，还可测试一些已写入的输出。例如，清单 1 所示代码片段用于测试 Jaxen 的 BaseXPath 类是否可串行化：

  
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 类是否可写入并在之后重新读回：

  
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 所示：

 
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 类的程序：

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 类的兼容性测试：

  
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 是不可串行化的：

  
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 所示：

@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 测试覆盖工具的开发工作。

QTP连接数据库

----------------------------------------------------------------------------------------------------------------------

引用地址: http://www.51testing.com/?135582/action_viewspace_itemid_18118.html

----------------------------------------------------------------------------------------------------------------------

(1)    首先要在控制面板中，加一个odbc数据源。

(2)    {6j ~
iu&M:F78029(((在qtp中建立连接和记录集51Testing软件测试网+@K[D*LE
set cnn=createobject("adodb.connection")
m-G|m/qp78029set ōbjrsa=createobject("adodb.recordset")51Testing软件测试网?9\ t'T|fJ#w

(3)    连接数据库

(4)    @R(_0V7n,yF78029对数据库进行操作。
`Y#J9G/T78029objrsa.open "select bustypefullname from bustypeinfo",cnn,3,251Testing软件测试网JV
{"F)y%L[!`&K‑i
a=objrsa("bustypefullname").value得到字段bustypefullname的值赋值给了变量a

在QTP中建立一个数据库检查点

----------------------------------------------------------------------------------------------------------------------

引用地址: http://www.rapidtesting.cn/Html/QTP/07102.html  

----------------------------------------------------------------------------------------------------------------------

与Robot相比，QTP直接提供了对数据库中的数据进行检查的检查点，这样如果在我们的测试中需要对后台的业务数据进行检查，只需要建立一个数据库检查点就可以了。建立数据库检查点对于一些比较复杂的业务逻辑的测试非常重要。

在QTP 8种，建立一个数据库检查点的基本步骤如下：

1、  从Insert菜单或工具条上选择新建一个Database Checkpoint  

2、  接下来需要为这个Database Checkpoint建立相应的Database Query，这里我们可以通过QTP 8提供的向导完成建立Database Query的过程。

在QTP 8里，我们有两种建立数据库query的选择：一种是通过Microsoft Query建立，这种方法比较简单，但是需要安装Microsoft Office中的Microsoft Query；另一种方法是手动建立，如果你对在Windows中手动建立ODBC数据源和SQL语句比较熟悉，那么可以选择这种方法。

使用Microsoft Query建立数据库query的画面如下图，Microsoft Query可以帮助我们建立数据连接，选择数据源并建立数据库的qeury：

最后Microsoft Query会把建立好的query返回给QTP 8。

3、  在query建立好之后，QTP 8将打开Database Checkpoint的属性对话框让我们决定如何建立这个数据库检查点。

数据库检查点对话框上方的表格中有蓝色对号的单元格表示将会作为基准数据在执行测试时参加检查，我们可以选择那些单元格的数据作为我们的基准数据。而在对话框下方有三个属性页，第一个属性页表明当前选择的基准数据是怎样配置的，可以是常数，也可以从数据表中读取，或者从被测软件的输出数据中读入。

第二个属性页用来设置比较数据的规则。

而第三个属性页用来设置在进行数据检查时怎样识别数据表的行，列以及单元格。如果我们选择通过键值来定位行数据，那么被选择为主键的列标题会加上图标作为标识。

当属性设置完成以后，一个数据库检查点就建立成功了。

4、  修改数据库检查点

如果需要对建立好的数据库检查点进行修改，可以通过选择该数据库检查点，然后选择检查点的Object Properties，在数据库检查点的Object Properties对话框中修改连接字串或者SQL query。

如果需要修改数据库检查点的数据或其它属性，也可以再次打开盖数据库检查点的Checkpoint Properties对话框。

QTP识别和操作对象的原理

QTP为用户提供了两种操作对象的接口，一种就是对象的封装接口，另一种是对象的自身接口。 对象的自身接口是对象控件本身的接口，只要做过软件开发，使用过控件的人应该很清楚。
    对象的封装接口是QTP为对象封装的另一层接口，它是QTP通过调用对象的自身接口来实现的。
    两种接口的脚本书写格式的差别在于：
    自身接口需要在对象名后面加object再加属性名或方法名，    封装接口就不用在对象名后面加object。
    比如操作JavaEdit对象，通过QTP封装的封装接口，脚本如下：
    设置JavaEdit的内容：
     JavaDialog("Add NE").JavaEdit("NE Name").Set "NE1"
    读取JavaEdit的内容：
     msgbox JavaDialog("Add NE").JavaEdit("NE Name").GetROProperty("value")
    如果通过JavaEdit的自身接口，脚本如下：
    设置JavaEdit的内容：
    JavaDialog("Add NE").JavaEdit("NE Name").object.setText("NE1")
    读取JavaEdit的内容：
    Msgbox JavaDialog("Add NE").JavaEdit("NE Name").object.getText()
    QTP执行JavaEdit().Set语句时，是通过执行JavaEdit().object.setText()来实现的。
    QTP执行JavaEdit().GetROProperty("value"),是通过执行JavaEdit().object.getText()来实现的。
    JavaEdit对象的封装接口Set()和GetROProperty("value")，是QTP封装JavaEdit对象的自身接口setText()和getText()而得来的。
    对象的封装接口是QTP使用的缺省接口，我们录制出来的脚本都是使用封装接口，大家用的也都是封装接口。但是封装接口不如自身接口丰富，因为QTP只是封装了部分常用的自身接口嘛。所以我们在需要时，可以绕过封装接口，直接调用对象的自身接口。不过有些自身接口不够稳定，在实践中偶尔会出现问题，但是概率很少。封装接口有相应功能的话，就尽量用封装接口吧！  
    理解了封装接口和自身接口的原理，我们就可以更加灵活的操作对象了。
    但是我们怎么知道对象都有哪些封装接口和自身接口呢？
    其实很简单，用对象查看器（Object Spy）查看对象，在查看窗口里有列出这些接口，包括属性和方法。
    窗口中间有选择栏让你选择Run-time Object或者Test Object，    当你选择Run-time Object时，它显示的就是对象的自身接口（自身的属性和方法）当你选择Test Object时，它显示的就是对象的封装接口（封装的属性和方法）
    明白了这些，你还等什么呢？快拿起对象查看器，看看对象都有哪些封装接口和自身接口，肆意的操作它，玩弄它吧！
    比如执行
    JavaDialog("Add NE").JavaEdit("NE Name").object.setVisible(false)
     哈哈，你的JavaEdit对象就当场消失不见了！！！

QTP日志记录方法

QTP自动化脚本执行中,QTP工程师肯定要考虑如何记录运行中的信息,什么时间执行了什么,中间遇到什么问题等等

1.通过Shell记录windows事件,在windows事件查看器中查看

优点是操作方便

Set WshShell = WScripit.CreateObject("Wscrīpt.Shell")

0是信息,1是错误,2是警告

WshShell.LogEvent 0, "Logon scrīpt Completed Successfully"
WshShell.LogEvent 1, "Logon scrīpt failed"
WshShell.LogEvent 2, "中文,且2" 

2.通过FileSystemObject来打开文件来记录

优点是功能强大,想记录啥就是啥

3.利用Desktop.CaptureBitmap来记录当前Screen

填写问题单时,发生错误的页面抓图很有说服力,也便于查看,当出错时调用此函数

QTP专家视图

专家视图

专家视图，也叫脚本视图，属于QTP中比较高级的功能选项。在该视图中，测试人员可以直接修改测试脚本（VB脚本）的代码，来增强测试脚本的功能，它要求测试人员具有一定VB脚本语法基础。
当然，测试脚本中也不完全是VB脚本，严格意义上来说，QTP的测试脚本应该是标准 VB脚本和QTP测试对象的组合体。
所谓的QTP测试对象，就是QuickTest定义的用来表示Windows窗体元素的对象，如同窗口，命令按钮等，每一个QTP测试对象都有若干个方法和属性，允许用户加以修改。
就是我们刚才录制的测试脚本的专家视图：

我们直接在该视图中修改和在关键字视图中修改的效果是一样的。
VB脚本是一种容易学习并且功能强大的脚本，它是VB的一个子集，遵循VB的语法。
如果读者原来没有接触过VB脚本的话，可以将关键字视图和专家视图中的对应项结合起来学习。

下面简单介绍一下其语法：

Ø
常见的对象名：
Dialog:对话框，括号里面的参数表示对话框标题栏上的名字
WinEdit:Windows窗体中的文本框
WinButton: Windows窗体中的命令按钮
ActiveX: ActiveX控件
WinComboBox: Windows窗体中列表框

Ø
常见的事件名：
Set:当在文本框中输入信息时会触发该事件
Click:当点击命令按钮时会触发该事件
Select:当选择列表框或是单选按钮时会触发该事件
Close:当关闭一个标准窗口或对话框时会触发该事件

查看(1867) 评论(3) 收藏 分享 管理

软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。
　　(1) 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。
　　(2) 非法测试，例如在输入数字的地方输入字母。
　　(3) 跟踪测试，跟踪一条数据的流程,保证数据的正确性。
　　(4) 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。
　　(5) 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心
　　(6) 代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。
　　(7) 突发事件测试，服务器上可能发生意外情况的测试。
　　(8) 外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。
　　(9) 在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。
　　(10) 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。
　　(11) 文字测试，如果在系统中有用词不当的地方，我想这是不应该的。
　　(12) 系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。
　　(13) 用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。