【IT168技术文章】作者记录了三名受人尊敬的测试专家和分析师的看法与观点：Theresa Lanowitz，Gartner公司的研究执行官；Hung Nguven，LogiGear公司的董事长和CEO；以及Sam Guckenheimer，IBM的自动化软件质量高级技术执行官。在访谈的第一部分中，他们交流了测试人员所面对的挑战，以及迎接挑战所需要的技术、技能和策略。第二部分集中了讨论有关架构变更是如何影响测试和自动化测试工具的问题。

***技能***
    让我们先从讨论技能开始吧。在过去的两三年中，分布式应用程序的爆炸式发展是如何影响测试人员所需的有效的技能和领域知识的呢？

    Hung Nguyen，LogiGear：我认为这种发展带来的影响是巨大的。在过去，在测试环境中要进行的所有事情都是非常独立的。您拿到了一套交付的产品，开始运行安装程序，然后进行测试。但是，当使用更加分布式的，或者电子商务的模型时，测试人员就要面对两个主要的问题了。第一个问题，在技术方面，所有的事情都发生了变化。由于您的系统可能使用分布于各个地方的组件，一些是您的团队开发的，一些是第三方组件，所以您无法控制您的环境。这样，仅仅是了解环境并且弄清如何进行有效地测试就是一个很大的技术挑战。

    第二个问题，在业务方面，规则也有所改变。过去，用户购买软件包，安装后就可以使用。现在您的用户可能购买软件包，或者他们可能仅仅使用您的电子商务基础设施进行业务交易。所以，在业务的基础上，测试人员还需要进行学习才能有效地工作。例如，考虑性能方面，这只是测试的一个角度。在新环境中，测试人员需要了解非功能性的问题，例如，什么是性能？我如何才能得出"合理的"响应时间，并且对其进行测试呢？这些都是他们在功能方面不总是能够看到的。另一个要考虑的方面就是进行安全的测试。测试人员需要询问，我如何才能知道我的用户是否受保护或者业务是否受保护呢？这些正是测试的灰色区域，因为几乎没有几个测试人员知道如何有效地进行这种测试。

    我们已经开始意识到要使测试有效地进行，您需要具备技术技能。因为该领域还不是那么的成熟，我们的测试团队中还有不懂技术的人员。目前，在业务逻辑和用户级，这是无可厚诽的。但是您也需要弥补技术方面的缺陷。直到所有人都了解到我们需要技能熟练的人员进行工作时，我还认为测试人员，会非常不幸地，一直处于发展不充分的状态，并且平均起来挣得较少。在理想情况下，技能熟练的测试人员与开发人员所了解的技术知识应该差不多，因此理应拿到同等的报酬，或者与他们的能力相匹配--而且管理层应该了解这个道理。如果工资结构有所改变，为将更多的天才人员转变为混和工程师添加了预算的话，那么更多的开发人员就会有兴趣成为一名测试工程师。

    Theresa Lanowitz, Gartner：即使我们已经看到了分布式应用程序的爆炸式发展，我们还没有看到技能方面的爆炸性发展，对于开发人员或者测试工程师来说都是如此。使用许多分布式应用程序的话，应用程序就是业务。突然间，企业的应用程序都是面向客户的，在传统企业中的IT组织现在都负责创建创造利润的产品，而不只是应用程序。

    但是技能并没有什么发展；实际上，我认为它们还有所减退，因为越来越多的企业都匆匆忙忙地创建这些面向客户、利润驱动的产品，他们无法找到技术足够熟练的人员，所以他们常常雇佣那些没什么经验的人员。回到1999年和2000年，我们看到了许多这样知名的网站以失败告终。在大概相同的时候，您听到过许多有关测试工具的大肆宣传，说它们是如何地易于使用，您不必了解技术就可以使用它们。但是我认为这样传达了错误的信息；您确实需要具有技术技能以完成我们所希望的对应用程序的测试。

    而且，分布式应用程序只会变得越来越复杂。从发展的角度看，您可以知道使用大型机应用程序的用户是谁，您也可以了解使用了什么样的架构。然后出现了客户端-服务器应用程序，后来又进入了Internet世界，而现在有了无线的应用程序。为了从测试的角度处理这种新出现的复杂情况，您就需要使用熟练的质量工程师--就是那些既了解过程又明白质量工程内容的人。

    公司都了解这个情况，但是几乎没有哪家公司愿意这么做。通过调查，我们知道让职工具有坚实的技术技能是企业最关心的问题。不过，他们最不可能做的一件事就是花钱进行培训。所以，这是一个一直存在的问题。

    另一个问题就是测试常常是开发组织需要削减预算时首先要考虑的事情，测试人员也可能被认为是入门级的角色，或者将测试看作是您在成为一名开发人员之前，首先要接受的岗位。正如Hung指出的那样，测试人员确实没有被给予与专业人员同等的关注和应有的尊敬。所以，组织常常重复地出现相同的问题，因为他们还做得不够，核心测试人员还不具备原理性的知识。

    Sam Guckenheimer, IBM Rational：所以，我们正在讨论的就是，以前人们认为不需要具备关于正在进行测试的软件的深入技术知识，也可以进行测试，但是当面对分布式应用程序时--尤其是在Web上的应用程序--这个假设就站不住脚了。Hung的一本有关测试基于Web应用程序的书极好地解释了这一观点。测试人员需要知道技术是如何影响他们所发现的错误和风险的种类的。他们需要理解技术问题--例如部署拓扑--就像理解他们进行测试的技术所内在的错误种类一样。甚至要了解一些细节，例如在应用服务器上bean管理和容器管理持久性之间的差异--所有这些问题都对会影响到您将要发现的错误的种类。现在的测试人员需要了解技术以及相关领域，同时也要掌握通用的测试技巧。

    例如，假设您在浏览器中看到一条错误信息"404-Page not found"。这种错误可能是由于一个损坏的链接引起的，或者也可能是由于某些服务不存在。一名优秀的测试人员不仅仅应该对不存在的服务产生疑问，而且也应该能够肯定他的这种怀疑--例如，通过查看其他与该服务有关的页面来判断。这是分离判断错误的关键技术。

    另一项技能最近也受到了广泛的关注，也就是测试人员是否具备一名优秀探索者的能力。从历史角度来看，测试所要进行的许多内容都已经被高度脚本化，并且进行了周密的计划，但是，实际上，优秀的测试人员应该是优秀的探索者。他们可以发现可能作为提示的东西，而且知道如何在此基础上进一步探索。这些提示可能非常简单，例如某个页面的加载时间惊人地漫长。一名优秀的测试人员会怀疑，这意味着什么呢？而且知道接下去应该采取什么策略。James Bach 编写了一些有关探索性测试的非常好的资料，而且对该主题也进行了深入的运用。我认为这当然是一种关键的技能，也是测试团队需要具备的技能。

***压力***
    多年来，组织不断地努力"更快地、更好地、更节省地"开发软件，测试人员的存在只是保证要实现"更好地"这个方面。现在，测试人员是不是要承受更大的压力解决"更快地"和"更节省地"这两方面问题呢？

    Theresa Lanowitz：我们真正在谈论的其实是使用了多年的选择三角形：预算、日程还是质量。您的问题认为测试人员的存在就是为了保证"更好地"这个方面；但是他们确实能够做到吗？请考虑一下，测试工程师已经被强迫赋予了一种角色。在传统的瀑布式开发中，测试仅仅在应用程序将要付诸使用之前的一个很短的时间段内才开始进行。测试工程师实际上从没有在开发过程中使用过用例或者测试用例。而且如果开发期间的日程安排有所顺延，那么测试工程师就遭殃了。我认为测试人员并不总是能够保证"更好"。

    如果要保证"更好"，测试人员实际上就需要成为客户的代言人。而且我不认为他们会受到尊重，拥有足够的时间，使用优秀的工具，或者甚至没有正确的文化背景来支持。组织总是更加关心更快与更节省，而不是更好，而且常常只有发生了灾难性的或者接近灾难性的事件，才会使大部分人意识到他们的开发能力并不是像假设的那样优秀。在过去几年中，我们经历过所有那些高知名度的运行中断和网站故障，我们一次又一次地感受到历史在重演。

    在预算内准时地创建高质量的应用程序，这需要那些非常严谨的组织才行--在管理和过程两方面都很严谨。但是这种文化氛围还没有在业界中流行起来。

    这种文化需要什么样的基石呢？熟练的职业人员；可以文档化并且重复的过程和过程；强大的工具和服务。人们常常认为工具将会是功能较多的，但是事实并非如此。如果您的目的是要较快地发布，那么您可能就要牺牲质量，而且可能会超过预算。这就是在.com蓬勃发展时我们所看到的。但是真实的情况是比较悲观的，您即无法真正地加快面世时间，而且由于超时，新项目开发的费用也会失去控制，超过维护费用，而且使您无法准时将正确的产品推向市场。

    Hung Nguyen：我认为，这个问题可以追溯到缺乏对于测试团队的预算。管理层常常想要创建质量更好的产品--我没有遇到过意见相左的人--那么这就需要更好的过程、使用更先进的开发方法学和更好的测试策略。但是，如果您看一看大部分的业务预算，就会发现没有为测试留出余地；这都归咎于研发或者开发。所以，在组织中没有为测试留下一席之地，也没有业务策略和管理级的预算，但是测试人员仍然承担全部的责任，要确保系统运行正常。

    另一个问题就是，几乎不存在什么可靠的度量方法来表示以前您已经作了多少工作，所以也就无法追溯判定您是工作得更好了还是更差了。如果您的产品中出现一个巨大的故障，那么千夫所指的是哪里呢？首先就是测试，但是最后所有人都会收到责备，没有人可以为单独一件事情负责。我认为这是从管理层角度出发所面临的最大问题。如果您想要"更好"，那么您必须提升测试和质量工程的可见度，而且您可以通过提高预算来完成，这是很有效的。应该让测试人员与开发人员合作来弄清如何完成工作。测试预算可以是开发预算的百分之几，或者优选方案，应该为业务预算的百分之几，实际的数值还在争论中，但是肯定是要制定计划的。我们将资金分配于市场、销售和研发，那么为什么没有测试的份呢？

    "更节省地"开发也并不是件容易的事。工具和过程当然可以有所帮助。培训，尤其是如何有效地使用工具，也会有所帮助。实际上，这又回到了我们刚才讨论过的技能问题上来。寻找优秀的测试培训是个问题；严肃的、基于技能的软件测试课程数量是有限的。我绞尽脑汁只想到目前在美国惟一一个开设良好培训的例子，是由Florida技术学院提供的，Cam Kaner和James Whittaker进行讲授。California大学在Berkeley 与Santa Cruz Extension、LogiGear 与 SQE所进行的课程也是提供有用软件测试课程有限的几个的例子。除了这些，我认为也存在巨大的技能鸿沟，在大学级别上，增加更多的教育课程会是一个好办法。例如Rational的公司一直都在开发支持新技术的工具，但是测试人员需要在更广阔的环境中对其进行了解。工具只是解决问题的方法。要想有效地使用它们，我需要知道我已经出现了问题，这个问题是如何定义的，而且存在很多的方法来解决它。这才是我所谈论的教育的类型。

    Sam Guckenheimer：实现更快与更节省的关键是在开发周期内使用迭代的开发过程使测试不断向前，这样，在发现缺陷时，才可能更节省地、更轻松地修复。不过，我不认为测试人员已经进行了良好的培训能够使用迭代的过程进行工作。项目经理也可能没有进行良好的培训以考虑测试的角色；那就是为什么我们向Rational Unified Process和Rational大学培训中加入大量内容并且还要持续进行扩展以展示测试人员是如何进行迭代工作的原因。

    但是，即使您并没有进行迭代式开发--如果您在使用瀑布方法--也适用相同的概念：为了节省时间和金钱，首先要把测试作为基础。在早期迭代中，您首先想要检验技术条件并且在简单的测试中进行功能级的测试，然后逐渐上升到复杂场景和配置测试，在稍后的版本中又进行多变量的混和测试。理想情况下，您会不断积累自动化测试方法，但同时您也需要不断地进行优化。例如，对于接口的自动化测试是绝对关键的，而且应该在任何时候不断地进行。但是在用户的场景中，可能会在可用性、测试反馈或者设计变更方面有所变化，您也需要肯定、清楚地了解您测试的内容是什么，以及当应用程序在测试发生变化的状态下您如何进行优化测试。

    非常重要的一点就是要了解不同级别测试的强大威力，而不认为测试只是在已完成的系统GUI上进行操作。作为测试人员，我们需要仔细地理解单元测试和交互测试，什么样的测试种类才算恰当以及在哪里进行测试。

***过程变更***
    让我们来更多地讨论一下过程吧。在测试人员与扩展开发团队的其余人员协同工作时会出现什么样的变更阻止前进的步伐呢？敏捷的开发过程提倡进行测试为先的设计和单元测试。测试团队现在是否在更深入地进行代码级和模型驱动的测试呢？

    Sam Guckenheimer：我们来一次回答这些问题，首先从测试人员与扩展开发团队协同工作开始吧。我坚信测试人员必须与开发人员紧密合作；他们应该一起工作，同时进行迭代过程。我认为市场中大概有一半的公司正在以这种方式进行工作。另一半则认为测试人员应该比较独立，他们中的大部分将测试外包。从我的观点来看，您这样做就丢掉了测试的一半好处。您雇佣人员来发现错误，但是您并没用创建出以不断的和探索性的学习为基础的过程。如果您的测试人员与开发人员工作联系比较紧密的话，那么在过程中都会有所收获，而且也都会为创建出更好的产品而贡献力量。如果您将测试放手交给外包测试人员或者项目之外的测试团队的话，他们能够发现一些机械的错误同时进行报告，但是真正以迭代的方式发展产品或过程的能力却会受到限制。

    下面就是有关"敏捷开发过程"问题的部分。发展式开发的概念是极限编程（XP）的基础，极限编程已经发展成为一种敏捷的活动。在敏捷开发中进行测试还没有被明确地定义，对于它应该包括的内容有许多观点。我倾向于使用Brian Marick 与Bret Pettichord所使用的定义，基于6个原则--实际上他们称其为口号--都是从实践得出的。一个原则就是您应该以实现技术说明书的方式开发测试；本质上，测试就是面向设计说明书的。因此，Rational Unified Process所称的用例实现都是通过测试完成的。您在软件创建的同时进行探索性测试，您要不断进行迭代和优化，主要关注于为可测试性而设计。我认为，这些都是伟大的实践，而且许多测试人员已经开始注意到它们了。

    测试人员已经在源代码级就更深入地进行测试了吗？这里，这个命名会有点让人犯晕。在一个组织中被称为测试人员的人可能在另一个组织中被称为开发员，反之亦然。在大多数组织中，测试人员并不是直接从源代码阶段就开始进行测试，除非他们与开发人员配对工作。我认为这样是恰当的，因为开发人员应该为源代码的质量负责。很久以来我们就已经知道测试源代码的非常好的人选就是编写源代码的人，而且Rational也提供了强大的工具支持开发人员进行测试活动。

    模型驱动的测试也会带来另一个问题。模型提供了一种伟大的方法，进行文档化系统、可视化系统行为并且在团队中以一种易于理解的、减少复杂度的方式沟通共享的工作。使用模型进行测试的好处正在成指数地增加，而且呈现出一种奇妙的趋势。模型驱动的测试包括很多的内容。一个就是可以专门为测试而开发模型，与源代码开发分离开来，这可以作为一种创建大量测试的方法。（Microsoft 的Harry Robinson在他维护的网站中体现了这重意思：www.model-based-testing.org）。

    从另一方面来讲，Rational 的观点就是，模型驱动的测试意味着模型描述了测试状态下的软件--其结构和行为。相同的模型可以捕获对所要进行测试的内容的定义，也可以捕获测试的结果。我们正在努力为模型驱动测试的发展做着贡献。例如，Rational Test RealTime以UML顺序图的形式表示了测试状态下软件的行为。我们的模型驱动开发的概念与在OMG工作组进行的用于UML测试简档的工作相一致。如果UML测试简档被OMG所采用，我预言我们会看到使用模型进行结果可视化和定义测试的急速发展。

    我们还没有讨论测试人员与分析师协同工作的方式问题。在这两个角色之间一直都存在一种关系，即使在最明显的"瀑布"过程中（比如IEEE 829），人们也可以了解测试需求。建模不断地发展为分析和开发的实践，这将分析师和开发人员紧密地联系在一起，因为它将帮助开发人员使用级别不断增加的技术条件将需求转换为设计。另一方面，它也会允许他们以不断增加的抽象度将设计可视化。起初，测试人员并没有被考虑进该循环中，但是仍然享受到了这些益处。确实，当他们意识到模型不仅仅会描述构思，而且也会捕获实际系统行为时，他们就体会到了其中的妙处。人们频繁地克扣模型中的用例实现方式，但是如果团队能够将应用于结构上的相同类型的反复工程应用到行为上去的话，这种情况即将改变。那也就是我们正在前进的方向。如果您使用了Rational Test RealTime，那么您就会发现，在序列图中的值正是您通过捕获系统行为而得到的。

    Theresa Lanowitz：过程，包括早期测试的方法，对于任何取得成功的组织来说都是很关键的，但是许多人并没有意识到这一点。两三年前，Gartner 听到许多的组织说："我们开发这套应用程序就是为了[适合您最需要的垂直行业]，而且我们想将其转变为商业产品。我们的计划就是把它卖到行业中的其他公司去，并且使我们脱离母组织。"但是，当我们探讨了作为一家商业软件公司所需要的条件时，他们就会退缩。我们没有看到任何成功脱离的案例。但是，实际上，企业确实需要能够并且也愿意表现得像商业软件公司那样。他们需要了解创建周期、需求和日程；他们需要能够与工程组进行沟通的产品经理等等。目前，我们还没有看到企业组织全部都采取了这种更加结构化的行为。

    要实现这种改变，就需要建立起支持它的文化。资深人员常常告诉我，管理层并不想要过程，因为那样会占用太多的时间。要建立一个优秀的过程，您必须理解它应该包括什么内容，并且在整个过程采用的最初阶段保持对其的管理，贯彻完整的原则。您也必须记住，最终目标是为了准时并且在预算内发布高质量的人们所公认可以作为产品的应用程序。除非组织中从上到下每个人都重视产品质量，否则组织就会以一种混乱或者无法发挥作用的模式运行。

    应该牢记编写代码实际上仅仅是任何项目开发中的一小部分内容，这一点是很重要的。识别正确的架构，开展恰当的过程，确保您遵守企业已经建立的标准--这些都是很关键的事。

    对于进行源代码级的测试，开发人员现在正在编写更多的单元测试，这是值得肯定的。一些确实不错的工具已经在市场上出现，这些工具都可以帮助开发人员创建单元测试。不过，我仍然认为，随着时间的过去，测试人员需要变得更加地懂得技术，而且组织需要进行更大的投资培训测试人员，使其跟上技术的发展。那么，随着测试人员技能的不断成熟，组织就会更加公平地对待和尊敬测试部门。测试人员肯定也会更多地参与进代码级的测试中。

    对于模型驱动的测试，UML为此做了很大努力。如果您编写了测试用例，那么您就已经编写出测试用例了。如果您能够将一个优秀与稳定的过程完全集成入您的软件开发生命周期中，那么这就是一件很值得肯定的事。

    Hung Nguyen：当然，测试人员与开发团队的其余人员的融合程度随公司的不同变化幅度很大。一家公司可能使用并不是很懂技术的测试工程师，但是他们应用了很棒的过程，完全能够使测试、开发与业务团队协同工作一起探讨需求和特性，并且全部将其文档化。但是，在整个行业的范围内，这种情况肯定会发生改变，测试人员会更早地参与过程，并且与业务分析师和开发团队进行更多的合作。

    让开发团队在源代码级考虑其代码的可测试性并且考虑进行单元测试是很好的。但是如果您看看要进行测试的阶段--需求级、源代码级、接口级、组件级以及集成测试所在的系统级--测试人员在源代码级、接口级和组件级的表现都不够理想。在接口（API）级，合作进行得还不错，但是在源代码级，就仍然是开发人员的事情了；测试人员还需知道如何才能在那个环境中发挥作用。

    例如，Rational Purify属于一种开发人员经常使用的动态工具，这是很好的。但是，要想进行更广泛的测试，您就需要执行更多的代码，而开发人员没有时间这样做。所以，一种明智的办法就是将开发团队与过程相集成，并且也让测试人员在测试过程中使用Rational Purify。同样地，让开发人员先进行一遍单元测试，然后再让测试人员进行一遍测试，这样做也是可以的。虽然可能由于缺少对测试过程的学习，我们仍然将代码级的测试看作主要是开发人员的活动，但是我们确实需要填平开发人员与测试人员之间的沟壑。但是测试人员仅仅需要运行测试，记录所有的错误，然后把结果发送给开发人员；他们甚至不需要解释这些结果所包含的意义。

    我认为模型驱动的测试在测试设计和分析方面扮演了很重要的角色。例如，Rational Quality Architect能够创建基于模型和依赖性的测试。如果您发现了错误，您实际上就可以使用模型来缩短推算出故障的路径。所以，模型驱动的测试就是进行测试设计和生成的关键因素，也可以作为自动化故障分析与精确定位问题的知识基础。

***故障的代价***
    人们常常讨论把过程作为一种减少软件故障的方式。很多著述也记录了与面向公众的电子商务站点有关的故障的代价在不断地增加。业务的变更很大程度上影响了测试实践吗？

    Theresa Lanowitz：绝对如此。当使用电子商务时，故障并不仅仅意味着人们将不能使用该软件；这还是有关公众形象的问题。因为使用这些应用软件的人都没有技术基础，也因为软件的应用范围正在逐渐增大，所以软件必须是能够防止错误操作的。您的用户并不具备丰富的经验，所以您仅仅有一次机会。如果他们想要使用什么--例如Web服务--而它根本就无法执行或者工作，那么他们就不会继续进行，只会转向其他的站点。这就直接说明了需要将产品（例如Web服务）的质量提高这一问题。

    Sam Guckenheimer：我认为故障代价的增加已经使管理层更加意识到测试和质量的重要性。幸运的是，我们已经超越了这个阶段，也即一些以前的网站忽略了质量，而完全关注速度问题。因为我们经历了那么多高知名度网站的故障，所以管理层变得越来越精明，越来越仔细。

    Hung Nguyen：我不认为故障带来的高代价确实是一个新问题；我们以前就已经面对过这个问题了。它确实会影响测试人员；它给我们施加了压力，使我们更有效地发现错误。但是这个问题与质量保证过程更加紧密相关。我们该如何实施更好利用人员和技术的质量过程呢？我们该如何使QA与开发团队协同工作以开发更好的实践呢？在电子商务故障的环境下，我们现在进行测试的方式与曾经进行测试的方式有所不同了。我们不会停止工作，知道产品已发布；我们持续地进行着测试。这也是为什么一个新的监理市场已经兴起的原因，我们正在使用机制来提醒我们注意故障。

    目前，公众也受到了更好的教育。他们明白如果他们付了钱，那么您就必须提供优秀的产品。他们可以进行选择；行业内的竞争如此的激烈，如果您无法提供优秀的、高质量的产品，那么他们就会离你而去。

    这些故障也造成了一个非常积极的结果，管理层已经开始从金钱的角度看待质量问题了。他们正在告诫他们的开发组织："我并不关心你称它是高质量或者低质量的产品。如果它让我的站点关闭两分钟，那就会花费我一百万美元，我不想这类事情发生。所以，你回去应该弄清如何才能不让这类事情发生。"而且管理层也知道如果他们给测试小组提供相当的预算，那么测试小组就应该负起责任。当您制定年预算时，会想要把测试置于列表的顶部，因为这是获取高质量软件的主要途径。最终，那将赋予测试人员权力、责任和义务。