软件测试网学习教程-中文员

本期导游戏软件的测试方法简述简单介绍了游戏软件的测试方法，决玩家所遇问题的预测工作，同时也是不断 [详见P3.]微软公司软件接收测试过程一个公司业务过程的应用软件对它的经营效率起了关键性的作用。然而，1995年之前，微软没有一个正式的、连续的、面向企业的适当步骤，来确保它内部的应用软件按照一系列统一的公司标准开发。今天……[P4.]自动化测试成功的关键.在本文中，我们要讨论为什么进行测试，尤其是自动化测试，是必需的。然后，介绍制定计划的概念：为什么制定计划是如此的重要……[详见P7.]性能测试指标介绍TPC-作为一家非 性机构事务处理性能 （TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试我们细致地研究JUint框架并思索如何来构造它…… [详见P11.]对Web服务进行压力Web服务处于分布式计算的位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使Web服务的开发变得越来越容易隐藏错误…… [详见P16.] 强化测试用例在测试活动的作用本文的目的不是将软件测试流程优化的话题阐述的面面俱到，而是从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理……[P19.] 高手过招的乐趣—测试用例预演投稿主编：审阅：协作：高手过招，手中无需用剑，只要轻描淡写地以口代手，三两句话便投稿主编：审阅：协作：一、游戏软件的测试方法简测试的定义如果个义，觉得：试作，决家遇题预工，同时也是不断调试平衡的一个长期观察任务。无论在什么时间段，功能实现、内测、公测等。测试都应该是分硬件与软件两部分测试。硬性问题硬件的BUG部分是指会引起不能让游戏流程进行的BUG。死机、画面出错等硬性问题。这种问题只要按照一定流程进行游戏，就会发生。但对一些会不断增加服务器负担的高级BUG，应该不会短期测试出来。而对这种在有计算机就出现的问题，现在的游戏在制作过程中都有可自动记录问题的LOG功能，所出现的BUG大多会被程序部门解决掉。部分的LOG功能可保留到正式客户端，以收集因为升级客户端，而不断产生的新问题。这里应该不会在讨论范围内吧。软性问题而软件的逻辑部分大多会在后期进行，比如公测。是各种功能的数值调整。主要为游戏的世界定义一个平衡。除了初级的数值设定外，内部测试人员很少有能把一个功能测试千万遍的。于是有可能产生出猫耍的团转，这种经典的寓言故事。策划及相关测试人员注重的应该是这部分的测试原理及方法。而这部分问题的测试，同硬性问题一样，需要一定流程及要求。而具体流程只有根据具体游戏来决定，大多是将问题存放，并将理由归纳。但有几点是不变的。平衡的目标而如何让各种设定不偏离，明确世界背景及制定等级概念应该是首要的。尤其在一些角色等系统十分复杂的情况下。那种ADD的规则，可由主角的5~种基础属性影响到数十种战斗、非战斗技能。还可根据各种物品来休整这些数值。而无论如何。他们都有个明确的等级观念。从弱到普通，再到强，甚至到最强的龙。这是因为他们知道一个人，最强也不能强过龙。这样就给自己定下上限目标。所以，测试时首先不要去看玩家可选择的等等是否足够多。都会获得什么强大的技能、体力等等。先了解到里，各个种族之间的关系、职业的互补、各个角色的互相的关系，在整个世界中是什么位置，是否够合理、让常人可以现实中的逻辑去衡量，这个角色在游戏是否合理。之后才需要针对每个种族、每类职业、每个角色的平衡。最后到一个一个角色的测试。有人会说这是前期策划制定讨论的部分，没错，因为测试从这里就已经在策划的头脑中开始了。在这里定义的过程，正好与现实世界中相反。现实世界是总结出整体的平衡，划分等级测试时同样要明确问题的严重等级，一个数值影响的事物越多，那他的严重等级越高。现在的MMRPG整个属性结构，基本都类似树形结构，之间也有着一些交错的枝叶。力量等最基本的角色属性，为根。这类属性会影响到的其他属性，最终到达游戏的胜负，任务的完成等等。而这些属性的等级自然也就十分明确。根为最高，最低。而修整树木不会从根开始。力，础性，结中对敏，影理。同样也影响着可拿的。但如果这个人力过高。那是谁的原因？是，还是角色的力量。需要修改那一个？那些角色的基础属性是最不能随便修改的。因此，还是吧。实在不行在从由属性的其他部分着手，如技能的熟练度等。越基础的部分，越大，也最容易出错。角色的基础属性测试的根源，同样也是最不能随便更改的一类。更不应该因为某个问题而被指明要求更改。而添加删除任何一个属性，更会让之前的测试工作有2/3付之一炬，也许。而对于各种，基本可以与角色测试分开。在角色属性有数十条的游戏中，更不会容易出现大的问题。尽量在自己的范围内修正。不要妄想在其他级别动手，更别想在比自己之前高的级别里动手脚。而在这些属性里面同样还各种属性，就需要根据具体游戏进行划分测试。虽然这里以属性距离，但任务也同样如此，相互关连的任务网同样十分重要。只不过之前变化较属性掠少。玩家是否付出与获得成正比现实世界中，没有可能可用捷径获得某一种事物、，只有拼搏。游戏世界里是否也是？获得一个强大技能之前，给角色的锻炼是否足够。让他足够珍惜这一种技能或物品。这是游戏中较为关键的一部分，多体现在任务上。时间、精力的消耗，是否足够让玩家获得物品时有足够的满足感。以及对得起测试人员的劳动。记录、调整，总结软性问题应该同硬性问题一样拥有足够多的文档资料来记录，同时也方便对以往数值的效果再思考。这也应该是所有文档资料应该具备的，记录每次关键更新的工作。调整方面SidMeier，每一次调整都要多一些。这样可以看到数值中的巨大差别，从中找到合适的数值。这几乎是知道SidMeier的人都知道的一句话（大意相似，具体内容没办法记起来，惭愧）很多时候，测试时会直接将测试的内容按自己的想法修改。即便记录下来也是只要改好就好。其实很多时候这些修改都有一定规律，一些修正往往是没改变任何事情。多一些时间去探讨大家是否按照原来制定的目标去修正，会更合理的利用剩下的时间测试。同样，全部结束后的总结也会让下次制作时避免出现需要大量修正慧灵科技依托测试时代资源，推出面向实践的软件测慧灵科技依托测试时代资源，推出面向实践的软件测试专业课程，由国内著名软件企业的一线技术专家主讲，为您的企业解决实践中的关键问题。如果您培训的目的不是拿一个 ，而是想学习软件测试的最佳实践，那我们会是您一个不错的选择。登陆公 二、微软公司软件接收测试过来自：一个公司业务过程的应用软件对它的经营效率起了关键性的作用。然而，1995年之前，微软没有一个正式的、连续的、面向企业的适当步骤，来确保它内部的应用软件按照一系列统一的公司标准开发。今天，微软小组的软件接收测试过程确保证关键任务的应用软件能在公司的硬件设施上高效地运行，与严格的操作标准一致。这些标准建立起来是为了最优化应用软件的运行和集成，减少来自上面的行政管理。卓越的产品对公司的成功非常重要；一支有动力的销售力量也是成功关键。但是，如果一个公司二者兼具，但业务过程上的应用程序与它的产品实力、销售力量、不相适应，该公司的发展速度仍然会渐渐变慢。这些应用程序帮助管理企业内部最次的工作，如对报告系统的指令和融资、帮助桌面呼叫系统等所有这些内部开发的用于支持创新性的、竞争性的商业实践的应用软件。为了保证它的业务过程上的应用软件能够提供最良好的运行、最小程度的上级管理，微软公司依赖于它的小组的软件接收测试过程。这个过程保证所有内部开发的、为公司环境使用而设计的应用软件都是按照一系列正规的、以公司为基础的标准来建造和测试的。这些标准定义了一个应用软件是如何与其他的软件互相作用，它如何使用公司的数据库，它是如何被建造在世界范围内的网络上最优化地运行。结果，内部应用软件开发商能够改进开发周期，微软数据中心的经理能比从前更有效地运行和这些内部应用软件。从195年开始帮助微软减少内部开发和费用每年超过两百万。它还帮助微软建立了一个更加化和强有力的软件环标准的要求"我们从1995年的七月开始开发SAT(软件接收测试)过程"格瑞吉·吉斯维兹说，他是微软组中SAT小组的经理。"在那之前，内部开发的业务过程应用软件是直接到数据中心和直接挂到国际网上的--简而言之，它是自己进入微软的产品环境中去的--没有任何一种运行标准，也没有任何一种正式的软件接收过程。"当开发商在这些应用软件被投放市场之前对它进行常规性的功能测试的时候，这种功能测试并不能保证此应用软件在微软的公司范围内的产品环境中工作得很好。在1995年之前，微软的业务过程上的应用软件开发商所的一个最基本的问题是，缺乏关于如何为开发业务过程应用软件来最优化微软的产品环境的的信息库。这些应用软件的开发在单个经营单元小组内进行，公司没有集中的工程或开发小组，单个BUIT开发小组很少知道其它BUIT小组的开发商在做什么。并且，没有一个小组和微软公司内负责运行公司的网络与数据库系统的组织直接挂结果，当这些应用软件最后被挂到公司的网络上去，并开始和公司的数据库与其它应用软件互相作用的时候，他们并不总能象期望的那样工作。一些应用软件在网络上工作地很差，一些不能与它们的整体融合，还有一些要占用准备进入的服务器和数据库的所有资源。开发商不得不极其费力地降低这些波动性，或者重新修改这些应用软件，直到它们能连续、可靠地运行。信息、指令以及合法性的唯一资源为了开发系列正式的指导性原则，以利于优化微软公司业务过程的应用软件的开发，为了让这些指导性原则在整个BUIT中趋于严格的一致,为了给全公司的开发者、经营单元经理和执行者提供关于开发中的业务过程上应用软件的单一的信息源，ITG创建了一套正规的程序。在微软执行者的支持下，SAT小组与管理公司数据中心和公司网络的组织密切合作，去创建一套业务过程应用软件的正式标准。这些标准现在为内部应用开发提供了最好的实践指导，使微软的开发者能为硬件设计应用软件，在系统软件上运行，并且数据库管理系统在微软的产品环境中工作得更好。微软的SAT过程在SAT过程的最开始，内部应用软件开发SAT的局域网工具登记他们的开发计划。登记提醒SAT小组一个新的软件开始进行，由此产生一系列会议，把开发者们、SAT小组成员，和真正管理产品环境中的小组成员召集到一起。局域网工具提供给开发者一套版本的微软运行标准文件，其中呈列了最近的硬件、网络、操作系统、业务过程应用软件数据库管理的标准，使这些信息通过SAT在微软局域网上的站点发布，在程序开发过程中，开发者不断向SAT的工具数据库添加新信息：安装手册、使用和指南、非标准化的模板的文字稿（保证使用者有足够的信息支持程序。SAT小组和开发者一起工作，建立一个确保企业质量（EQA）的测试以确信程序符合微软操作标准，能够在微软产品环境中正常运行。EQA测试计划和日程被列入SAT工具数据库，并成为永久部分，这样在后来的设计和运行出现问题后可以进行参考。工程支持于质量保证测试新的LOB程序实际测试之前，SAT组和BUIT开发者密切合作来确保大家在合作中能从对方的经验获益。微软公司企业程序服务部总经理BobLunn说："SAT工程小组的每个人从BUIT队伍中获得了经验和知识，然后把这些知识化为最优秀的实践，使所有的BUIT成员都可使用。这样，有助于调整大家一起开发程序。"微软企业数据管理主管TimThiers说："我可以给你一个特殊的例子，当遇到了广域网（WAN）中用户的运行问题时,微软公司使重的基于客户-服务器的程序跟踪意外情况。SAT组中的工程组就能在程序上进行重点测试，在微软终端服务器上诊断它能否通过广域网解决问题。如果我们使用终端服务器来支持程序，他们就可以提供功能上定量精细的帮助。""在意外程序的一项关键功能上，SAT工程组证明：对在通常微软带宽为X、延迟率为Y的辅助环境的通常用户,当使用终端服务器时，功能调用的行为将导致z%性能增加。他们能告诉我，反应时间从多少秒到多少秒--反正是一些很难记住的数字--这样就有足够的信息进行成本-收益决策，确定采取什么样的技术。"除了为了提供测试支持来开发最佳程序设置，在微软新产品环境下运行时,SAT组中的工程组还可以帮助测试LOB程序性能。作为微软产品销售的SAT过程的部分，微软最大的销售收入和库存数据软件，SAT工程组要测试它在MSSQL7.0环境下的性能。这不仅使开发者可以提前预见并克服它与新数据库系统合作时的性能问题，还为MSSQL7.0找到了企业环境的实验台。AlanPerkins是SAT组的高级系统分析员，他说"这有助于SQL服务器开发组在发布产品之前强化其功能。他们带来改进型版本，要我们对现有版本进行针对测试。测试后，我们反馈回结果：哪些查询快，哪些慢，什么时候发生饱和，诸如此类的问题。"Gicewicz补充说，"这些反馈对SQL服务器7.0起了积极影响。版本响应MSSales查询的速度比前期版本提高了65%。"除了开发过程中的咨询作用、确保SAT过程最终成功外，SAT小组使LOB新程序通过了正常的EQA测试。Gicewicz说"在软件产品真正降生前，它要先获得SAT准生证。这意味着我们已经成功安装，该软件可以跻身于模拟的产品环境，通过了真实条件的测试。"作为测试过程的一部分，SAT组应用广域网模拟和一套内置的第工具来拟微软企业产品环境。这些工具包括NetworkMonitor和PerformanceMonitor（用于WindowsNTServer操作系统），RadView公司的WebLoad、Optimal公司的ApplicationExpert以及两种内部开发的工具（用来管理和测试SQL服务器。当成千的用户在Intranet上同时点击应用程序时，这些工具可以模拟服务器的行为，可以通过广域网模拟网络连接来测试程序的表现，甚至可以模拟众多用户同时查询数据库的情况。另外，EQA过程检验程序是否符合微软操作--以确保它与为LOB程序已建立的引导相匹配。推出最好的产品微软公司有大约250个企业系统，ST过程是为加强它们的稳定性、可靠性、可度量性设计的，为遍布世界各地的决策者提供有用和高效的信息管理工具。如何把优化程序做得最好，如何在软件进入产品环境前彻底测试--这些知识被集合在一起，为微软公司每年节约200万（自1995年开始。这一过程也缩短了LOB程序返工的时间（目的是优化其性能，使之能在微软产品环境正常工作。返工时间从196年起下降了3%。微软公司从SAT过程中了另外的切实的、可度量的、本质固有的利益。质保测试过程提供了机会，从中可以发现和改正程序中的缺陷，避免了在演示和发布后引起问题。Gicewicz阐述说，通过EQA测试后的IT基础设施效率更高。对程序不熟悉的人要进行安装测试，这样可以促使开发者注意到并解决一些安装问题--如果是由熟悉程序的人来安装，他们可能对这些问题意识不到。最后，通过对所有内部LOB程序开发的巩固和调整，SAT过程对微软公司的所有人起了促进作用：如果微软的雇员想得到关于提供商业支持的程序时,它提供了一个单一答案库。格瑞吉·吉斯维兹说："如果你是CIO或行政主管，你就想知道在微软公司到底有多少这样的LOB程序。很简单，在微软主页上就能见到答案。你还可能希望了解关于程序框架的不同观点--比如，共有多少种金融信息管理系统。你可以深入钻研SAT数据来发现按商业功能分类的程序。在以前，你对微软的LOB现在，容易多了！"优异的产品、充满激励的销售、一整套的协调的LOB程序（已经针对企业优化，并且经过了SAT的严格测试）--这一切，使微软公司的市场表现卓越不凡。三、自动化测试成功的关键在本文中，我们要讨论为什么进试，尤其是自动化测试，是必需的。然后，我们将介绍制定计划的概念：为什么制定计划是如此的重要？在随后的文章中，分解测试计划中的不同因素，并且研究如何进行制定计划的过程才能最大程度地增加成功的机会。现代客户端/服务器应用程序是非常复杂的，因此测试也就成为开发过程中关键的并且至关重要的一部分。现在，没有人会考虑（或者承认）不对自己开发的软件进试工作。但是，研究和调查表明，在软件开发过程中，制定测试计划却常常是优先级较低的工作项目。而且，更加糟糕的是，计划往往没有被执行，或者即使执行了，也进行的不很完整、不很准确，或者没有持续进行。假设我们都赞成测试是必要的，那么我们接下来必须回答这些问题：我们如何进试？实际上都包括哪些内容？我们如何保证已经进行了有效的工作，并且真正地改善了应用程序的质量？答案很简单：制定计划。本文将评审在软件生命周期中制定测试计划的作用，以及有效制定测试计划的有关概念。在本文中，我们要讨论为什么进试，尤其是自动化测试，是必需的。然后，介绍制定计划的概念：为什么制定计划是如此的重要？在随后的文章中，分解测试计划中的不同因素，并且研究如何进行制定计划的过程才能最大程度地增加成功的机会。为什么花费精力制定计划？现在看来，没有怎么制定测试计划而造成的比以前更加明显了。失败的案例有很多--看看报纸或者杂志就知道了。还有一些明显的低质量软件的案例，它们包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（动态连接库、事务处理器或者应用程序与数据库管理服务。软件的每个附加"层"都在客户端/服务器架构中增加了额外的复杂度（并且需要进试。多种类型的测试另外，测试客户端/服务器应用程序也需要使用许多不同类型的测试方法，例如，功能测试、用户界面、性能测试以及配置测试。这些测试都针对一个或几个测试目标。为了防止测试迂回不前或者尝试同时测试所有内容，每种测试必须制定仔细的计划。当您进行自动化测试时，这一点尤其正确。数对于我们执行的每种类型的测试，都必须使用数据。数据对于测试的执行和成功完成来说是至关重要的，因为要使用数据识别最初的应用程序数据状态（，并且调用或者引出特定的事件或者操作。而且也要使用数据来验证测试事件或者操作是否运行正常！制定测试计划的其他原因如前所述，现代的应用程序与以前开发的应用程序相比具有很大的不同。客户端/服务器技术加强了我们开发与部署以任务关键型的企业系统的能力，而且花费的周期更短，提供的功能更加强大。客户端/服务器应用程序也为开发人员与终端用户提供了大量的选择和控制。但是使用这些好处的同时，也需要加强测试。测试自动化逐渐地，测试软件必须使用测试自动化工具和技术，以满足具有性的日程安排。但是，单单使用工具还不足够，成功的测试自动化需要制定测试计划。在没有进行计划的条件下，实施测试自动化只会带来自动化的。使用测试自动化工具，我们可以管理并且识别过程中造成的因素，同时管理项目费用（例如"未被文档化的特性/变更"。测试自动化是使软件测试人员跟上开发人员脚步的惟一方式，软件测试人员可以像测试早先构建版本那样，充满信心地、可靠地测试新构建的版本。但是测试常常为测试人员带来，他们必须最有效地、生产力极高地使用时间，进行工作。测试自动化引入了一种新型的资源需求--测试开发。手工测试需要进试设计，以识别测试的内容和方式，但是由于没有使用工具，所以也没有必要开发任何的测试或过程，仅仅来调试一下系统，然后使用键盘就可以了！如果对于每个要进行的测试，需要使用的资源仅仅是键盘，那么就可以看出，您并没有有效地利用时间。测试开发是一种新技术，在设计完成之后，需要使用工具并且创建测试过程。作为一种有效的方式，可以使用三名不同的技术员，并确保将的资源用于设计与制定计划任务上，而将中级资源（或外界资源）用于开发与执行。这样可以增强职员所需的能力，并且共享资源，同时也不会对项目计划产生什么影响。缺陷管理与分析缺陷是肯定会被发现的。这是进试的结果，或者说是目的，所以须对缺陷的生命周期进行识别和沟通，同时分析结果以确保缺陷已被有效地并且高效地处理。制定测试计划能够确保缺陷管理与分析是一笔面向整个项目的宝贵资产，而不会带来阻碍。如果您还没有配备缺陷管理系统和过程，或者已具有但是工作得不是很理想，那么制定测试计划就会给您带来创建（或者修正）它的机会。制定测试计划也可以识别应该使用什么样的度量方法。制定测试计划可以处理您所度量软件质量程度的问题。它也可以处理如何度量与沟通缺陷密度或缺陷趋势的问题。风险分析制定测试计划提供了进行风险评估的机会。风险与不利因素对于组织来说是就一场噩梦，但是它们也是可以被控制的。不过首先必须对其进行分析。风险分析有助于制定测试工作的优先级，并且关注所进行的工作，确保测试内容的正确性，以正确的顺序解决正确的问题。（所谓正确，是以组织的风险与可接收度为基础的。）对于每个项目来说，都要进行风险评估并将其用于识别潜在的风险或者未发现缺陷带来的影响。风险应该用来评估缺陷对于直接终端用户、数据或者其他终端用户和应用程序带来的影响。这些数据可以用来建立测试优先级，并且评估所有约束，例如面市时间、预算或者费用，或者质量问题。风险评估还应该包括对于现有标准、指南和需求的评审。其目的就是为了分析这三种文档，判断它们对于项目是否恰当，并且由此进行实施或者修正。评审任何可能影响或者对项目带来冲击的外界因素也是很重要的。这些影响可以包括特定用户请求、规范的需求、或者市场条件，这其中的任何一项都可以变更风险或者优先级的评估结果。过程改善制定测试计划就是为测试过程制定文档。为测试制定计划不仅仅为文档化并且沟通测试工作提供机会，也可以评审测试工作的有效性。您曾听到过以下吗"我知道你已经说了需要三个月的时间进试，但是你只有两个改善产品质量（具有较少的软件缺陷）需要对产品开发过程进行持续的完善工作。之，可以从几个理由来说明制定良好计划的自动化测试的必要性。首先，不进试的组织会大大增加出现重大系统故障的可能，带来延迟，花费巨资进行修复，而且还可能潜在地带来对于客户信心无法修补的破坏。其次，现代客户端/服务器应用程序的本质允许快速地开发出复杂度很高的系统，该系统完全无法使用传统的手工方法进行正确的测试。最后，制定计划的目的就是为了管理不断增加的测试过程，分析并且已被发现的缺陷，执行关键性风险分析，并且持续改善测试与开发过程。您是否对软件测试的整体规划一直比较您是否对软件测试的整体规划一直比较模糊？您是否觉得软件测试工作技术含量不高，不知道如何提高自己？您是否发觉测试用例的复用率非常低而且检索困难？您是否觉得测试工作不太容易规划，总是不如预期？您是否觉得性能测试很重要但是不知道如何组织和实施有效的性能测试？您是否非常想知道大型的企业级系统是如何进行性能规划的？您是否想知道流行的测试工具的使用方法？ TPC-

四、性能测试指标介作为一家非性机构，事务处理性能（TPC）负责定义诸如TPC-CTPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设TPC-C是一种旨在衡量联机事务处理（OLTP）统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准进行，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPCWeb站点()上获得。tpmC定义:TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。TPC-C规范概要TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为300010项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。该系统需要处理的交易为以下几种：New-Order：客户输入一笔新的订货交易；Payment:更新客户账户余额以反映其支付状况;Delivery:发货(模拟批处理交易);Order-Status:查询客户最近交易的状态；Stock-Level:查询仓库库存状况，以便能够及时补货。对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。逻辑结构图：评测指标TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C，随着计算机技术的不断发展，这些也在不断刷新。TPC-C的测试结果主要有两个指标：流量指标(Throughput，简称按照TPC的定义，流量指标描述了系统在执行PaymentOrder-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。流量指标值越大越好！性价比(Price/Performance，简称即测试系统价格（指在的报价）与流量指标的比值。性价比越小越好！结果发布各厂商的TPC-C都按TPC组织规定的两种形式发布：概要(ExecutiveSummary)和详细测试报告(FullDisclosureReport)。概要中描述了主要的测试指标、测试环境示意图以及完整的系统配置与报价，而详细测试报告中除了包含上述内容外，还详细说明了整个测试环境的设置与测试过程。P690tpmC测试值：76,389,839.00$/tpmC：美金报价：IBMDB2UDBAIX5LTUXEDO测试日期：2003.6.30P690TPC-C测试的配置：：1xeServerpSeries690with32x1.7GHzPOWER4+processorswith128MBL3cacheperMCM(totaloffourMCMs),512GBmemory前端：30xeServerpSeries630Model6E4eachwith4x1.0GHzPOWER4CPUswith32MBL3cache,16GBmemorySPECweb:SPECweb96:在SPECweb96基准测试程序上实现的每秒钟超文本传输协议（HTTP）操作最多次数，响应时间无明显。SPECweb99:接入数，网络服务器可用预先确定的工作量支持的同时接入数。SPECweb99检测设备模拟客户通过慢Internet联接，向网络服务器发送HTTP工作量SPECweb99测试WebSPECweb99是由标准性能评估组织（SPEC）开发的Web服务器基准测试。它测量满足特定吞吐量和客户请求响应速率要求的WEB服务器的最大并发连接数量。并发连接的合计波特率在320Kbps到400Kbps范围内，则满足相应规范。SPECweb99在一台称为主客户端的机器上运行，这台机器上包含有允许用户加载特定负载请求的配置文件。主客户端也要处理在客户端和服务器或测试中的系统（SUT）之间的传输协调问题。客户端通过许多子进程／线程生成独立HTTP请求流，仿真足够的负载发送给SUT。图二表示客户端／服务器的层次关系。SPECweb99实验环境在这个测试中，客户端向测试中的服务器发送请求数据。测试规范要求客户端和服务器之间的连接不能使用片段大小大于1460比特的TCP协议。因此，每一个客户端1460比特或更少数据块的响应。测试中使用两种类型的负载量：静态负载.静态负载具有四种类型的文件。最小的文件的增幅为0.1KB，第二种文件类型的增幅为1KB，最后两种类型的文件的增幅为10KB和100KB。每一个包含每种类型9个文件共36个文件。目标请求的文件类型在各类型中分散使用。在每一类中的9个文件中又进行二次分布。最终目标文件混合为：35％150％1014％100KB，101％1000KB，100动态负载.动态负载是基于和用户。共有四种在SPECweb99中使用的请求内容类型，分别是标准动态取操作、动态随机取操作、动态发送操作和客户图形接口动态取操作。标准动态取操作和客户图形接口动态取操作表现web服务器的简单轮转特性。带有轮转的动态取操作追踪用户和用户选择，所以可以由不同的方式来定制。最终，动态发布实施一个用户在相应的上。P690SPECweb99测试值21,000Web服务器：Zeus4.0AIX5LV5.1(64-测试日期：2001-10-测试配置：16x1.3GHzPOWER-4Processorsw/1440KBunifiedonchipL2cache,192GBmemory,32x32IBMGigabitEthernet-SXPCI32xGigabitEthernetnetwork(1Gigabit/sec),96xClients(4x375MHzPOWER3-II,RS/600044P-270),RequestedConnections=21000,MaxFilesetSize=67319.6MBP650SPECweb99测试值12,400Web服务器：Zeus4.1r3AIX5LV5.2(64-测试日期：2002-10-测试配置8x1.45GHzPOWER4+processorsw/1.5MB(I+D)unifiedonchipL2cache,32MBunifiedoffchip/SCML3cache,64GBmemory,8xGigabitEthernet-SXPCI-Xcontrollers,8xGigabitEthernetnetwork(1Gigabit/sec48xClients(6x668MHzRS64-IV,pSeries620ModelRequestedConnections=12400,MaxFilesetSize=39801.28MBp630SPECweb99测试值：6,895WebZeusAIX5LV5.2(64-测试日期：2003-2-测试配置：4x1450MHzPOWER4+Processorsw/1536KB(I+D)unifiedonchipL2cache,8MBunifiedoffchip)/SCML3cache,32GBmemory,4xGigabitEthernet-SXPCI-Xcontrollers,4xGigabitEthernetnetworks(1Gigabit/sec),24xClients(4x375MHzPOWER3-II,pSeries640ModelB80),RequestedConnections=6900,MaxFilesetSize=NotesBench:NotesBench是测试各种不同LotusNotes方面的驱动程序。目的是执行自定义工作量教本中令，模拟客户机的操作。NotesBench测试“仅测试邮件”和“测试邮件和数据库”。所有已经公布的IBM结果均为“仅测试邮件工作量”。p680NotesBench测试值150,197用户数：108,000平均反应时间：0.584秒Domino5.06a操作系统：AIX4.3.3IBMeServerpSeries680(24*RS64IV/600MHz;96GBRAM,30五、对Web服务进行压力测试作者：ChrisWeb服务处于分布式计算的位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使Web服务的开发变得越来越容易隐藏错误。这些类型的错误极难检测出来。压力测试是检测这类代码错误的一种有效方法，但是只有在压力系统设计得比较有效的情况下才能发挥作用。本文将深入了解一下这种压力系统的基本要求。测试方法传统的测试方法包括某种形式的简单单元测试，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的部分。这些类型的测试非常适合与其他代码组件极少交互，甚至没有交互的简单Web服务。功能验证（FuncionalVerifiation）也是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进试以确认产品或服务的功能。设计这种测试是为了证明这个功能符合某个规范。举个例子，我的拍卖显示的是输入的正确出价吗？我的保险经纪人系统找到最便宜的报价了吗？如果这些测试失败，通常就意味着检测到了产品的一个基本问题（这个问题通常是可以直接修复。这种测试也是适合简单的Web服务，使您可以检查服务是否能够正确执行它的各个功能。系统测试（SystemTest）通常是在功能验证阶段完成，验证了功能后进行。它倾向于把整个系统作为一个整体来查找问题—弄清Web服务作为系统的一部分怎样运作，以及Web服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的日程安排以及开发的各个重要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是：性能（Performance：这涉及到确定相关的产品统计数据的过程。例如：每秒有多少条消息？一个服务可同时接受多少个用户？案例（Scenario：这是重新创建客户所需的确切配置的过程。因此在案例中发现的任何问题都可以在客户使用该产品之前被检测出来。压力（或称工作负载平衡）：它与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用（但不超过性能统计数字确定的限制）的错误，而这些错误用上面提到的任何其他技术都是发现不了的（是最难修复的。从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是压力测试部分。但由于这个过程经常跟系统的其他要素或功能测试在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。压力下的错误使用压力测试，您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：内存泄漏（Memoryleak：一种极难检测的现象。内存泄漏经常发生在已的产品中，原因很简单，很难设计测试用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的次数以使内存消耗达到能引起注意的程度。尽管与其它编程语言（如C/C++）相比，Java程序更难引入内存泄漏错误，但只要程序仍保持着对对象的，该对象仍有可能被实例化并且它占用的内存不会被释放。并发与同步（ConcurrencyandSynchronization）压力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现（5分钟或5天后发生。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑他或代码将与其他地方的代码（在执行单元测试时这些代码可能还没写出来）进行交互。现有的压力测试工具有许多声称能够对产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对Web服务的那些工具。然而，这些工具中有许多只是简单的HTML/SOAP生成器，它们模拟许多客户机连接，并因此对Web服务器生成高负载（这对于查找Web服务器的问题很有用，但对于查找Web服务的问题就没那么有用了。这些工具对基本的压力测试比较有用，但它们经常是仅仅扩展功能验证阶段来重复地执行相同的功能任务。如果足够的时间和资源可用，就可以通过创建定制构建的压力测试系统来实现更有效的测试。由于压力系统的设计者通常对要测试的产品和Web服务有的了解，所以他们将能够确保压力系统可以用于哪些具体的代码区域。设计压力应用设计试图对Web方式运行代码。这些风格了功能验证，目的是要弄清楚被测试的Web服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对Web服务应用四个基本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件：（Repetition：或许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品是否适用于某种生产情况至关重要。客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。并发（Concurrency：并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多Web服务。这个原则不一定适用于所有的产品（比如无状态服务，但是多数软件都具有某个并为或多线程行为元素，这一点只能通过执行多个代码示例才能测出来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个Web服务压力测试需要一次模拟多个客户机。Web服务（或者任何多线程代码）通常会多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序（例如以特定的定时条件执行时才会被发现。把这个原则与重复原则结合在一起，您可以应用许多代码路径和定时条件。量级（Magnitude压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个Web服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它—例如，数据的大小、延迟的长度、数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误（仅能发现功能上的缺陷），但与其他压力原则结合在一起时，您将可以增加发现问题的机会。随化：最后一点，任何压力系统都多多少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的Web服务的顺序。使用并发，您可以改变一起执行的Web服务、同一时间运行的Web服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的—每次重复测试时都可以更改应用程序中出现的变量（例如，发送各种大小的消息或数字输入值。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机的随化。这样，用同一个，重现错误的机会就会更大。一个压力测试通常会结合上述的所有原则，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成—否则可能就必须花费同样多的时间来重现这个错误。结束语 测试是软件开发过程中至关重要的部分，并且一个重要的、经常被曲解或忽略的部分是压力测试。遵循上面详细说明的原则，您就可以设计并实现有效的压力测试系统，用来查找一些与您的代码相关的、比较隐蔽的问题。无论是利用预先写好的工具，还是创建一个完全的压力系统，压力测试都是用于查找Web服务（ 43《单元测试技术――Nunit3《测试管理――TD》2《自动测试工具――Robot2《自动测试工具――LoadRunner2六、强化测试用例在测试活动的作本文的目的不是将软件测试流程优化的话题阐述的面面俱到，而是从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。常闻软件测试者的如此抱怨：测试用例在实际中根本没有起多大作用？测试人员在实际测试时都没有按测试用例来执行？测试执行后没有把需要更新的测试用例补充到用例库中？当前国内软件企业测试流程不规范的原因分析：从事物的发展规律看，软件测试行业在我国还是新兴行业，目前还处于起步和探索期，虽然国外的业发展到了一定阶段，但事实上他们也在不断的否定自我并探索着更成方法、寻求着更有效的方案；而国内的测试行业发展期不过10来年，所谓的测试管理流程不规范，也就情有可原了。从企业角度讲，测试部门的整顿和加强，按照企业自身发展的优先层次，还没有被纳入优先解决的程度，开拓市场、签订定单才是首要问题，也是维系企业生存发展脉。当然国内很多优秀的大中型软件公司的测试部门相对完善，如神州数码、、联想等，他们和大型软件公司的合作，也从中汲取了宝贵的管理经验。还有一个普遍存在的问题。近几年国内软件企业为了加强企业的竞争优势和名气提升，通常大搞特搞ISO/CMM认证；笔者也很支持这么做，但更关注的是通过这些认证后的企业有多少真正按照那些规范、设计的标准在后续的测试或软件开发管理工作中着手开展下去呢？社会上流传着这样的话：任何认中国，最后都免不了砸牌儿！笔者读书时很多高校搞的MCSE认证，有培训机构明目张胆声称"百分百通过率"！当年也有专门此事。听到这样的话，我们都会寒心真心希望我们的软件企业通过ISO/CMM后真正为企业的内部软件开发流程带来一点新生的曙光。最后一个原因，是企业内部测试管理人员和技术人员技能的不足，还有自身工作态度的不够端正。有了再好的规范标准，没人遵守不行！没人实施不行！应该说，很多中小软件企业的都或多或少的逐渐软件测试的重要性和必要性，以及它的标准化、流程化的紧迫性，但也有很多的工程师、技术人员并不理会这套，常常在实际工作中投机取巧；也有很多测试管理人员后天的经验不足、技能不够，对公司测试管理工作考虑，和开发工程师交流不充分，和上层反映不及时等等。总之，任何问题的出现都不是单方面的原因，从宏观的社会形势到微观的企业个人，都有无可推卸的责任；正因为如此，解决问题也要对症下药，如何完善软件测试流程，就要从小处出发；本文不可能将软件测试流程优化的话题阐述的面面俱到，因此只从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。强化测试用例在测试活动的作测试用例在实际中没有起多大作用,在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中……为何如此？我们分析认为，根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，从三个方面具体来说：测试用例的重要性是毋庸置疑的，它是软件测试全部过程的，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！制定了完备有效的测试用例，为什么不按测试用例执试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。改进测试用例执行过程那么究竟如何做，才能尽量避免上述问题呢？我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将其扼杀在萌芽阶段，软件需求分析阶段，笔者从来认为测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？虽然该观点被大多数所认可，但我知道依然有很多公司为了节省费用，不让测试人员参与前期调研或制定需求，经常的做法是等到系统开发完毕或将近完成，跟测试经理说一声"这边有个项目，你找几个人来测试一下吧！"经验表明，这样的做法实不可取。测试人员（指项目的测试和测试工程师）在需求阶段的任务有：方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。推荐企业采用类似于IBMRationalRequisitepro（参考其官方说明：http /cn/software/rational/products/requisitepro/index.shtml）的需求管理工具来制定和管理软件需求，同时需要测试人员的配合，保证对软件测试环节的充分考虑。软件分析设计阶段，测试人员除制定测试计划书等基本工作外，笔者认为还有一个相当必要的任务，那就是将系统的可测性到文档，以备将来编写测试用例。之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因。如果公司采用类似于IBM Rational Rose（参考官方说明：http /cn/software/rational/products/rose/index.shtml的建模分析工具和 IBM Rational Rose XDE Developer（参考官方说明：http /cn/software/rational/products/xdedeveloper/index.shtml）的可视化设计开发环境，这个工作更好执行；如果没有，那么测试人员更有必要编写一《软件功能点测试描述书它是软件的详细测试分析文档其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等这些信息都是描述性的无须具体数据它的作用是据此编写测试用例以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。当然该文档不是非要不可，笔者只是提倡一种原则，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！笔者之所以推荐IBMRational系列产品在软件项目中的应用，是因为IBMRational倡导的RUP（RationalUnifiedProcess）方法论采用了用例驱动的原则。所谓用例驱动，是以体系结构为中心，采用迭代、增量方式的开发过程；而其Rational工具系列正是将这一理念进行行为表述，是当前软件工程领域一套无可比拟的强大工具集，从需求到测试，它都以用例为基本模型，全面贯穿软件开发的每个环节。3）软件开发阶段，编写测试用例。我不想从技术角度探讨到底如何编写功能强大、质量优秀的测试用例（可参考笔者主页的"如何设计编写软件测试用例"），这里只想从管理角度和大家谈谈如何有效控制和增强测试用例在测试活动中的应用。应该遵守的原则是：首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。按照我上述所言的方式，测试工程师从前期阶段顺次下来，编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。其次，从数量来讲，笔者觉得很多公司的测试用例太少，甚至远远不能覆盖系统需求，这也是很多测试人员在测试工作开展初期按照用例执行、而后渐渐凭"意念"去执试的原因。应该说测试用例的数量很难用数学模型来模拟，更没办法衡量，但凭借个人经验来说，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于4000个，甚至！也许有人惊讶这一数字，不过了解IBM等大公司测试过程的会认为4000还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出5000个用例，那它的测试覆盖率还怕不高么！再次，如此众多测试用例的管理问题。是的，需要管理工具软件！笔者从来都以word或excel来编写测试用例：首先，格式上难于编写--通常方式是企业自己设计表格模版，但编辑上始终存在不便，尤其对于一些共性内容，如测试目标、测试环境、参考说明等，每次都要大量的、粘贴。其次难于管理--如果把几千个文档文件放在一个共享文件夹里，即便以子方式管理，但是每次查找一个特定用例，你的眼睛也必将饱受煎熬！更是难于执行--莫非真要针对几千个用例都是打开一个word-执试-输入测试结果-关闭word吗？最重要的是，根本没办法追踪测试结果--在本轮回归测试输入完，但是下一轮结果输入到哪里？输入了这些测试结果什么用？能方便的根据其结果统计软件质量吗？还有，可以用它追踪发现的软件缺陷吗？有办法追踪吗？使用word等软件编写测试用例的种种不便大致如上但换个思路思考一下使用集成工具的种种优势便更加一见分晓。测试同业者们都了解的测试用例管理工具便是IBMRationalTestManager（查看官方说明： /cn/software/rational/products/testmanager/index.shtml），它是专业的测试用例管理和测试管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案。以其为测试管理平台，测试人团队成员可以计划、管理、组织、执行、评诂以及报告等纵向测试活动，如果与IBMRational （查看官方说明： /cn/software/rational/products/clearquest/index.shtml）集成使用，还可即时软件的需求变更，从而增强整个软件团队的横向沟通与合作。而且，个人觉得测试行业的快速发展，必将带来从每个环节都逐渐向自动化和标准化方向迈进，尽早适应这一趋势，不仅提高了工作效率，也提高了企业的信誉和名誉。最后，一、是在测试管理工具中制定适合本公司的测试用例模版二、是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工自动两种）三、是测试用例要有状态，可根据用例执行状态索例（测试通过、测试失败、测试中断等）四、是执行失败的用例要到相应的缺陷报告，根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小五、是测试用例的修改，以及每个测试周期的运行都有日志记录，以便后期追踪和新员工参考软件测试阶段，测试划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等，再划分不同的子测试周期（如前两个星期做冒烟测试，测试方式是手工/自动，测试版本是**，测试环境是**，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：A）有健全且严格的体制保证测试执行者严格按照测试用例执试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。B）对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试与项目其他管理人员同意方可更新用例库。测试每日负责本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目或其他测试执行者负责执行自己区域的测试用例，还要负责该区域软件缺陷的修改进展，根据其状态不断验证软件功能点。应该提及的是，大多数软件公司都采用集成的缺陷管理工具来管理软件缺陷，如MaonalClearQuet变更管理与缺陷管理工具等，这是值得称颂的好迹象；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限缺陷管理工具，并不断软件缺陷的状态对于自动测试（包括自动化功能测试和性能、压力测试，有一些特殊要点。本人的原则是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试，并运行自动测试。例如IBMRational Robot （参考官方说明http /cn/software/rational/products/robot/index.shtml）或XDEester（http /cn/software/rational/products/xde_tester/index.shtml，现更名为RationalFunctionalester。针对自动化测试原则，可参阅笔者的"自动化测试要点"译文，这里要提的其他几个基本原则是：二、是项目的自动化测试工作有专人负责，以保证工作质量，他们可不参与日常测试；三、是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试，同样其工作状态；四、是选择最简单、最重用的测试用例使用自动测试方法；五、是使用工具厂商提供的测试框架编写，千万别采用单纯录制-加校验-回放的方式，以开发出健壮且重用性强的测试；六、是有专人更新，也有专人自动；七、是一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；八、是在多人协作开发测试、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本，IBMRationalClearCase（参考官方说明： /cn/software/rational/products/clearcase/index.shtml）是当前业界功能最强大的配置管理工具，可以将开发代码和测试代码都集中管理，进行高效的版本控制和工作空间管理，保证多人开发大量代码的稳定性。对于局域网范围内的开发工作，使用ClearCaseLT版足够。由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。软件验收阶段，除了提交软件测试评估报告（各种类型的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期，阶段需要重新测试某功能点，然而用例如果确，碰巧又是一个新员工来做，那就死翘翘了退一步说，如果您公司的测试部门经历一次这样重大的洗礼，有一个项目真正按照此原则实施一次，也必将对未来测试工作的开展发挥的作用、起到事半功倍的效果。其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行此可见，我们的测试工程师需要培训的空间还很大。另外，笔者不赞成对人员的强制性管理，例如大张旗鼓整顿公司测试部门的管理，采取缺陷报告数和人员绩效挂钩、不按测试规范执行就适当惩罚等；个人认为切不可急功近利，当，鼓励+促进甚善然、甚妙哉！综上所述，我们得出结论--测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利；测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全、不规范；至于如何解决，笔者提出了微薄建议，供业界朋友参考与交流。国内软件测试行业目前仍处在群雄逐鹿、百家的时期，芸芸纷说，不如从企业自身出发，确立最适合自我的测试管理解决方案，整顿自身的测试工作流程，那才是金玉良言的上上策！【作者简介】网名Sink，本名张振兴，是的一名测试工程师，擅长软件功能测试和和自动化功能测试，也从事过白盒测试、性能测试与测试管理工作，BMatinal工具套件和RUP理论具有深入的了解和研究，年也积累了一定测试经验和测试思想，此给业界。七、高手过招的乐---测试用例预演：高手过招，手中无需用剑，只要轻描淡写地以口代手，三两句话便高下立判，胜的方法，用模拟的测试用例执行发现程序中潜在的问题，竟有何神奇呢？请见内文。武侠小说中的高手大抵有三个层次，第一个级别是“静若处子，动如脱兔，身负成名绝技”的高手，印象中这一个级别的基本是或是性情豪爽的江湖侠客，这种人一旦遇到，打杀的场面最为宏伟，刀枪不绝，各出奇招，直到一方倒地或是被制；境界，这种高手若是过招，全不闻金戈，全无杀伐之意，轻描淡写的以口代手，三两句话便高下立判，赢的赢得痛快，输的输得潇洒，在武侠中看到此，常不免心潮澎湃，艳羡不已，巴不得自己也能有这个机会一尝绝顶高手之间的这种至高默契。可惜身为开发或是测试工程师，又出生在这个真实的世界，恐怕实在是不太会有机会这种所幸，我们虽不能飞进武侠小说尝试这种生活，却能在我们的测试工作中体会到这种乐趣。真耶？假耶？且与我一起，探究个究竟。回到我们的题目“高手过招的乐趣——测试用例预演”，这里我要是一种可以让你体会到高手过招乐趣的方法：“测试用例预演”。且慢试图在头脑中搜索你对这种方法的印象，因为这是我自创的名词（申明：如果很不幸你通过其他途径确实听到或是见过这种描述，请一定告知本人，本人会慎重考虑，至少到目前为止，我还能有把握地说这是我首先命名和以正式文档描述的法。之所以把这种算不上十分复杂的方法写下来，是因为本人在实际的工作中发现该方法确实能起到比较大的作用，而且更重要的是，那种高手过招的感觉，很希望能和有高手梦的朋友能够感受得到。测试用例预演是一种非正式的测试用例执行方法，概括说来，这种方法是无需通过测试用例的真正执行（静态或是动态执行），而只需要开发人员和测试人员之间的口头交流，就能发现被测系统中存在的问题。设想一下，无需动手（测试执行，通过以口代手（开发和测试人员之间的口头交流（），这不是高手过招是什么？测试用例预演的一般步骤是测试工程师与开发工程师以某种方式坐在一起，进入交流状态，这个过程中需要尽可能避免干扰，比较好的时机是坐在一起进餐的时候；不要偏离测试用例太远，可以考虑一些在测试用例中没有明确写明的异常情况处理；的响应即可，不需要描述具体的实现方法；测试工程师仔细聆听开发工程师的回答，需要对开发工程师的答复敏锐反应，不放过任何一个开发人员的迟疑，对拿的问题应该记录并需要马上验证；双方继续预演直到预期的预演时间结束或是有一方感到疲倦；记录预演过程中发现的问题到缺陷库。只有一个：系统的缺陷，这点务必要牢记，以免弄错了对手，伤了和气。测试用例预演不是一种复杂的方法，但根据我的经验，要想在实际工作中应用这种方法并取得较好的效果，必须了解这种方法的适用范围，遵循一定的使用方法，并需要注意一定的技巧。这里我以 FAQ的方式提供秘笈一部，各位请留意：Q：测试用例预演可以取代测试执行吗？A：这个问题是我捏造出来的，大概不会有人真的这么认为，不