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

解析软件测试的认识误区作者：本文选自：由于人们对于软件质量的重视程度越来越高，就导致了测试在软件开发中的地位越来越重要。测试是目前用来验证软件是否能够完成所期望的功能的唯一有效的方法。在这一趋势的引导下，现在很多软件相关的公司都非常重视对于他们所开发的软件的测试，甚至不惜花费巨资的测试工具，但是效果却不一定理想。究其原因主要是存在着对于软件测试的诸多误解。本文试图对一些比较普遍的关于测试的误解测试在软件开发过程中一直都是备受关注的，即使在传统的软件工程中，也有一个明确、独立的测试阶段。随着软件的频频出现以及人们对于软件本质的进一步认识，测试的地位得到了前所未有的提高。测试已经不仅仅局限于软件开发中的一个阶段，它已经开始贯穿于整个软件开发过程，人们已经开始认识到：测试开始的时间越早，测试执行的越频繁，所带来的整个软件开发成本的下降就会越多。ExtremeProgramming更是把测试推到了极限的位置，一切软件开发活动都要从首先编写测试代码开始。但是，相对于测试这个词的流行程度而言，有关测试教育方面的工作做的还远远不够，很多关于测试的文章都是针对某种测试工具使用方面的，而测试工具厂商也往往出于商业的目的对于测试工具的作用夸大其词。这样，很多的软件从业者就很容易陷入一些误区，导致了测试并没有在他们所在的软件开发项目中起到有效的作用。下面几个小节将对于一些比较具有代表性的误区进行剖析，并对于测试背后所蕴含的一些设计思考进行了阐述，希望能够起到抛砖引玉的作用。误区之一：使用了测试工具，就是进行了有效的测试这个误区可以说是一种通病，几乎每一个领域中的CASE工具刚刚出现时都会带来这个问题，比如：如果一个软件开发团队在软件的开发中使用了RationalRose工具来进行UML图的绘制，他们可能就会声称他们采用了面向对象的方法，也不管他们的设计和代码实际上是过程化。在测试领域中也一样如此，一个软件开发团队往往认为只要自己使用了某种软件测试工具，那么就应该可以获取测试带来的种种好处，这种想法当然是错误的。因为，要想对一个软件或者模块进行有效的测试，首先该软件或者模块应该是可测试的。可测试性是反映软件质量的一个内在属性，不会因为你使用了某种测试工具进行了测试行为，就使得被测试的软件具有了可测试性。如果被测试的软件本身并不具备可测试性，那么使用多么昂贵的测试工具进试所能够带来的收益都是微乎其微的。巧的是，可测试性和好的软件品质的其他方面有天然的关联，一个具有可测试性的软件必然是一个强内聚、弱耦合、接口明确、意图明晰的软件，而不可测试的软件往往具有过强的耦合和的逻辑。关于可测试性方面的内容不在本文的论述范围，请自行参见相关的文献（本文所附的参考文献中有关于可测试性的更深入的信息。要想真正获取测试带来的巨大好处，并且使得测试工具能够发挥最大的效率，关键就是要使软件本身具有很好的可测试性。这种能力的获取是一个逐步的过程，是不可能一蹴而就的。最关键的一点就是要不断实践，不断学些优秀的经验，不断的。要想获取好的结果，就必须要付出努力，这是亘古不变的真理。ExtremeProgramming中的测试先行的实践倒是一个很好的起点。对于测试工具的选择，只要满足需要并能够自动运试用例就可以了。不要一味的追求复杂的功能和不必要的灵活性。对于大多数项目来说，一些非常著名的源码开放的测试工具就足够了，比如：Java方面的单元测试工具JUnit和C++方面的单元测试工具CppUnit。关于验收测试方面，目前没有比较好的满足各方面需要通用的测试工具，不过使用脚本语言，循序渐进的自行开发一个适合自己的验收测试工具也不是一件的事情，一句话：只有提高了自身团队内在的素质，外在的工具才能够发挥作用。误区之二：存在太多的无法测试的东西在软件开发领域，确实存在一些东西看起来要比另外一些东西难测试一些，但是远非无法测试。并且在大多数的情况下，还是由于被测试的软件本身在设计时没有考虑到可测试性的问题。只不过这种不可测试性不是由于被测试的软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧，从而表现出被测试的软件本身很难测试。这些很难测试的部分比较常见的有：图形界面、硬件、数据库等。下面以图形界面为例进行说明。如果一个软件模块必须要通过图形界面才能够触发它的应用逻辑时，那么要对这个软件模块进试时就必须要使用图形界面。但是图形界面又是很难测试的看起来好像很难办。让我们换一个角度考虑一下，其实我们真正想要测试的是软件模块本身的应用逻辑，而不是图形界面的触发逻辑。如果我们在设计时能够把被测试的软件模块本身进行很好的封装，定义良好的服务提供接口，那么我们就完全可以通过软件模块本身提供的接口进试。这样就可以绕过难以测试的图形界面。造成上述软件模块很难测试的原因正是由于在设计时把软件模块本身的应用逻辑和图形界面这两个无关的逻辑耦合在了一起。把这两个逻辑分离，不仅可以对该软件模块进行更容易、更有效的测试，而且也使得该软件模块具有了很好的可重用性和可移植性。那么对于不好测试的图形界面，我们该怎么办呢？原则很简单，如果某种东西不好测试，那么就让它做肯定不会出错的事情，而把可能会出错的逻辑剥离出来，放到一个可以测试的模块中。对于图形界面来说，就是仅仅保持一个很薄的图形界面逻辑，它的工作就是把用户的请求简单的转发给真正处理该请求的软件模块（一般称之为ApplicationFacade。转发逻辑足够简单以至于它肯定不会出错，所以我们也无需对它进试。如果在进行软件开发时能够首先编写测试代码，那么就会迫使你从易使用性，易测试性的角度开考虑问题，从而你就会专注于软件模块的抽象和职责。这样就会定义出清晰的、明确反映意图的模块接口来，另外，为了使得测试能够进行，你就会主动把那些导致不好测试的耦合去掉。这样的结果不仅仅是获得了可测试性，并且也产生了更好的设计和系统架构。但是确实存在一些不好测试的东西并且很难只让它执行一些非常简单的逻辑，比如嵌入式系统中的BSP（板级支持包。开发它们所使用的语言、环境以及它们本身的特性等决定了它们是很难测试的。这里说的难测试其实是一个测试代价问题，具体的说就是要付出的时间和努力。这就需要你在付出的代价和测试带来的收益之间进行平衡。如果付出的代价所带来的收益（更少的调试、、发布成本）是巨大的，那么付出的代价就是非常值得的。误区之三：测试代码可以随意大家肯定知道测试代码是不能随意编写的，并且在编写测试代码时也不是抱着一种随意的态度，但是你编写出来的测试代码以及测试代码运行的情况却表现出了一种随意性和无序性。因为你可能并没有弄清楚测试的真正意图所在。本人曾经看到过有关验收测试的这样一个案例，验收测试者使用昂贵的测试工具对一个具有图形界面的软件进试。测试的方法是通过编写测试驱鼠标在图形界面上随机的点击（事件的区域），然后等待着被测试软件的。当然这种测试方法可以作为验收测试的一个方面，但是决不是唯一的一个方面。还有更重要的内容被忽视了。测试的目的是用来检验软件系统是否满足了需求。所以，你的测试代码一定要明确的表达出这一点来。就那上面的案例来说，如果测试者真正从用户的需求出发，那么他写出来的测试肯定不会是那样的，而应该是每一个测试用例都清晰的刻画了一项用户的需求，然后检验系统是否实现了用户期望的功能。这样的测试才是有明确目的，才是最有效的测试。和把界面逻辑和应用逻辑，采用明确表现用户需求测试用例进试相比，上面的测试方法不能不说是随意了一点。在针对类进行的单元测试中，也经常会看到一些错误的测试方法。很多的测试者往往针对类中的每个特定的实现细节进试。类中的特定的实现细节是很容易变化的，在快速的迭代式开发中更是如此。一旦你测试的类中的某个实现细节发生了变化，你原先的测试代码就要进行相应的更改，否则就失去了意义。这种频繁更改的代价是巨大的。类是一种抽象，它反映了更面的内聚性，它应该有明确的职责和定义良好的服务接口，它的职责和对外的接口相对于内部的实现细节来说要稳定的多，并且我们要验证的正是这个类是否具备了它的职责。因此，在对类进测试时，我们应该针对类的接口来验证类是否实现了它的职责而不是其他。这样写出来的测试代码要稳定的多，也有效的多。细想一下，造成容易陷入针对实现细节测试的原因主要是由于先实现了类，然后才去进试。如果先实现了类的功能，然后在去对类进试，中就会不由自主的想去验证已经完成的类的某种实现细节。如果能够在编写实际类前，首先编写针对该类的测试代码，情况就会有很大的不同，因为这会迫使你从类的使用者的角度去考虑问题。结果就是会把关注点放在类的易用性上，放在类的职责上面，放在类提供服务的接口上面，而不是某种实现细节。总之，测试代码的编写应该从被测试的对象是否满足需要的层面进行，而不是误区之四：单元测试和验收测试没有什么区别和误解之三一样，可能很多人并不承认这一点。但是他们却又不能比较清楚的说出二者的差别来。这样，在他们进试代码的编写时就会比较迷茫。本小节结试图给出一些区分单元测试和验收测试的一些原则来。我们还以经常用来和软件进行类比的建筑为例，首先给大家一个感性的认识。单元测试可以类比为一个建筑的质检人员对建筑进行的检测，他关注的重点是建筑的内部结构、地基、框架以及墙壁是否垂直等。他的检测是要保证建筑的各个部分试可以类比为建筑的使用者来对建筑进行的检测。首先，他认为这个建筑是满足规定的工程质量的，这是有建筑的质检人员来保证的。使用者关注的重点是住在这个建筑的中的感受。他关心建筑的外观是否美观、各个房间的大小是否合适，窗户的位置是否合适，是否能够满足家庭的需要等。这里，建筑的使用者执行的就是验收测试，他是从用户的角度出发的。建筑的质检人员执行的就是单元测试，他是从构建者的角度出发的。正是这种角度的不同决定了单元测试和验收测试之间的区别。它们是对系统的不同的方面进行的测试，二者是互相补充的。不管我们在系统的构建中使用了多么聪明的方法，不管我们的系统是多么的灵活，但是首先我们的产品必须是可用的，否则我们所做的就是浪费时间，从这一点上来说验收测试要比单元测试显得更加重要。还以上一小节给出的案例为例，案例中所使用的测试方法仅仅是从系统是否健壮的角度出发进行的，即使系统从不也不能证明那是一个可用的系统。因为测试根本就不是从用户使用的角度出发的，测试者本应该和用户一起来编写验收测试。单元测试保证我们把事情作对，而验收测试则保证我们做正确的事情。关于单元测试和验收测试之间的明确划分，没有一个通用的标准，只有通过自己的不断实践来增加这方面的经验。你进行的有关测试的实践越多，你就会越清晰的感觉到单元测试和验收测试之间的界限所在。下面给出一些指导原则，在你编写测试代码时可能会有帮助。如果一个单元测试要类的边界，那么它可能应该是一个验收测如果一个单元测试经常要随着用户需求的变化而改变，那么它可能应该是一个验收测试如果一个单元测试比它要测试的代码本身要难以编写，那么它可能应该是一个验收测试结测试是用来保证软件开发过程的高效性，以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一件非常的事情，这也决定了有效的测试决不是简单的依靠一些测试工具就可以进行的。在使用工具的同时，我们更要加强关于测试的培训、教育，使大家对于测试首先有一个正确的认识。，我们才能够更加有效、高效的使用工具，才能够使测试真正起到它应有的作用。希望本文能够对大家在进试方面的工作时有所帮助。参考文献ExtremeProgrammingExplained:EmbraceChange，KentBeck，AgileSoftwareDevelopment,Principles,Patterns,andPractices，RobertC.Martin，2002TestDrivenDevelopment:ByExample，KentBeck，2002Refactoring:ImprovingtheDesignofExistingCode，MartinFowler,KentBeck，1999TestingThingsThatSeemHardtoTest，RobertS.Koss，2001关于作者，软件工程师，主要在OO、GenericProgramming。可以通过dhui@263.net联系到作者。，软件工程师，目前在一个大型通信公司从事数据的开发，主要在Java和数据库。可以通过dhui@263.net联系到作者。慧灵科技依慧灵科技依托测试时代资源，推出面向实践的软件测试专业课程，由国内著名软件企业的一线技术专家主讲，为您的企业解决实践中的关键问题。如果您培训的目的不是拿一个 ，而是想学习软件测试的最佳实践，那我们会是您一个不错的选择。登陆公 关于测试人员何时介入项目小组?应该说这不是一篇文章，这应该属于是一个讨论的话题吧，无论观点是否正确，希望大家能够在里面可以自己的见解。尤其在这方面深有感触的朋友。提起这个话题的原因是因为现在一个项目里面测试人员的介入是到开发后期阶段——编码工作完成之后介入的，我认为很不合理，所以提出这个问题。从大的方面来考虑的话，现在流程的测试模型有三种：V模型，W模型，H模型。而在这三种模型里面，无论哪一种模型，测试的介入都是在软件开发过程的前期介入的。测试工作在这时介入，无论从哪方面考虑，都比我们直到开发过程的后期才介入更有好处。从成本方面来看：前期介入也许增加了测试人员的成本，但是相对于后期的投入和项目的风险方面，这个成本显然远远小于后期的投入，前期发现的Bug的修改代价比后期的修改代价了，如果把成本投入跟介入时间进行比较的话，那么应该可以得到如下的结论：介入时间越早，成本投入越小，反之越大。在需求调研阶段，设计阶段，编码阶段，测试阶段，产品出货阶段我们都会发现 bug，但是处理bug的代价在这几个阶段却是截然不同的，越往后代价越高。做过项目的人应该都有体会的。从项目风险来看：如果把编码阶段作为岭的话，编码阶段之前的工作为前期工作，编码阶段包括编码之后的工作为后期工作。一个问题在开发过程的前期被发现，则可以很大程度上降低项目的风险问题，如果在后期发现一个问题，将不可避免地要面对项目风险问题。很多时候一个项目最后实施大部分都是在后期发现的问题所致的。当然这不是实施失败的全部因素。从其他方面来考虑，都是前期介入比后期介入的情况好的。但是目前所遇到的情况是：等需求调研完成之后测试人员一起进行需求整理，这个时候我觉得很迷糊的一点就是测试人员都没有参加过需求调研，让测试人员进行需求调研整理，那不是需要重复一次工作吗？很多问题测试人员还是要去问进行调研的人的。我觉得效率不是很高。而且经过中间的一道程序很多时候会发生一种曲解需求的现象。所以测试人员的介入从有些方面来说还是值得一个项目小组的考虑的，不能只是从投入成本来考虑，而且如果要从成本方面考虑的话那么请考虑整个项目周期的成本。项目风险是项目必须面对的一个问题，而在这个问题上最重要的一个环节就是测试人员来进行把关的，当然有的公司在测试人员之后还有QA来负责质量的。其实关于这个话题要详细展开的话不是三言两语就可以说完的。今天只是有感而发。更何况有时候很多公司的规定都是不一样的。有时候有些流程不一定往日的经验就是很好的总结，该改新的时候还是需要动手术的。一成不变只能固步自封。墨守成规只能停滞不前。我希望我们的测试人员不只是在程序员写好程序之后直接把程序交付我们，并且附上一些应该算不上的但是并不很完整的文档就交付成功了，然后我们按照流程说明进行键盘输入，鼠标点击的动作。我希望我们能更早的介入到项目当中。了解，做到，同时也学到。不要当一个廉价的可有可无的角色。那是其实有时候觉得测试也可以进行分阶段，比如需求调研时候了解需求，然后等开发人员进行设计时候我们对需求进行剖解，然后提交代码之后再开始执试，中间可以根据需求和设计做很多测试计划，测试设计策略等方面的事情，主要包括测试计划，测试用例的设计，产出，并且准备相关测试数据。然后主要的一点就是要对自己进行的项目测试有一个很可观，比较全面的测试风险等的评估。以下是几个的跟帖，供大家参考不为：程序开发人员进行的是创造代码的活动，所以，很多初级程序员在写代码之前很明白自己在要做什么，该怎么做。但是，当开始写代码时，随着时间的流逝，目的就不再那么清晰了，也偏离了原先自己的思路，只是顾全自己的部分逻辑，而对整体的业务逻辑不是很清楚。所以，为了保证程序员的正确航向，测试人员应该在程序员写代码前，先写出测试用例，因为测试人员关心的是代码运行的结果是否符合用户的业务流程以及是否实现了预定的目标。相对来说，测试人员比开发人员更了解用户对软件的需求。因为测试是面向业务流程的，而软件开发是按模块分工的。所以，我们的做法是，在调研用户需求的时候，首先写出测试用例，用来规范程序开发人员的工作范围，使他们能在正确的道前进而不会偏离用户需求太远。当用户需求变化时，测试人员更改用例，开发人员修改代码，以通过用例为准。周舟：提到介入阶段，做了这么多项目我倒以为这不是该有很严格界定的，也确实真的很难界定，因为不论是需求，设计，不变的都在变，甚至上线应用之后，用户认为不满意，那也还得再变。所以依据需求分析，概要设计写出来的测试用例也很难一成不变。所以只要需求，设计都要变，测试就是有风险的。就算一切都是安装需求和设计写出来的，但那些不是用户最终要求，最终就这样白忙活了一场。我以为测试不论什么时候介入，了解和理解用户的最终需求是必须和万无一失并适合中国国情的。当然若是需求分析和设计能够很好的了解和理解需求，那测试的工作到是可以减轻许多，并风险也会小很多。只要测试“实现的功能是否正确”就行了，而不必费心于“系统是否实现了正确的功能”的测试。逐渐的行业背景知识竟也成了对测试人员的一种竟聘要求。eveet：To:周舟,"逐渐的行业背景知识竟也成了对测试人员的一种竞聘要求。"这句话正在被越来越多的企业应用到，不仅仅是测试知识，相关的行业背景知识也是很重要的，需求很难被固定，用例总是在改动，这都是很正常的。思考了很久，也真的很难总结出真正的一个介入的分水岭。还是活学活用吧，根据自己的实际，不要脱离科学的轨迹。您是否对软件测试的整体规划一直比较模糊您是否对软件测试的整体规划一直比较模糊？您是否觉得软件测试工作技术含量不高，不知道如何提高自己？您是否发觉测试用例的复用率非常低而且检索困难？您是否觉得测试工作不太容易规划，总是不如预期？您是否觉得性能测试很重要但是不知道如何组织和实施有效的性能测试？您是否非常想知道大型的企业级系统是如何进行性能规划的？您是否想知道流行的测试工具的使用方法？ WEB下的整体测随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进试的。B/S下的功能测试比较简单，关键是如何做能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：通用指标（Web应用服务器、数据库服务器必需测试项）ProcessorTime:指服务器CPU占用率，一般平均达到70%时，服务就接近饱MemoryAvailableMbyte:可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存则比较严重；PhysicsdiskTime:物理磁盘读写时间情况；Web服务器指标：AvgRps:平均每秒钟响应次数＝总请求时间/Avgtimetolastbyteperterstion（mstes）:平均每秒业务角本的迭代次数有人会把这两者SuccessfulRoundsFailedRoundsSuccessfulHits：成功的点击次数；FailedHitsHitsPerSecondSuccessfulHitsPerSecondFailedHitsPerSecondAttemptedConnections：尝试数数据库服务器指标：User0ConnectionsNumberofdeadlocksButterCachehit：数据库Cache中情况上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS 支持分布式机群测试,ACT 则是与.NET 集成比较好，支持ViewState（.NET下控件缓存的支持）的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧，呵呵。在这一阶段测试你要不断的跟据系数的测各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。这个我们要对子系统进行详细测试，由于B/S结构下,的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进试，这样才有更高的可信度。上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种，一、性能达不到目标；二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；三、服务器稳定性的问题，比如内存泄漏……。要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与f,主要是他对.net与java,C++都有支持，而且分析效果特别专业，我们先了解一下RationalPurif,RationalPurify能自动找出isualC/C++和Java代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的isualC/C++程序中的传统内存错误，以及Java，C#代码中与内存收集相关的错误方面；Rationalty则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比个函数它的执行时间为30秒，优化了一百倍则执行时间为0.3秒,提升了2.7秒，而如果它的执行时间为03秒，优化后为0.003秒，0.297秒，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用ty时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库，呵呵。数据库的分析原则是先索引，后过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句，可以程序流程使用的SQL语句与过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用rfy进行运行时分析，通常++内存问题比较多，aa与.NET比较少，一般由C不合理引起。++的内存错误就比较多了，主要常见的有:1、ArrayBoundsRead(ABR)：数组越界读2、ArrayBoundsWrite(ABW)：数组越界写3、BeyondstackReadBSR)：堆栈越界读4、FreeMemoryRead(FMR)：空闲内存读5、InvalidpointerRead(IPR)：指针阅读6、NullPointerRead(NPR)：空指针阅读7、UninitializedMemoryRead(UMR)8、MemoryLeak注：如果需要的信息，可以参见Purify的帮助信息顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具ureovage来做就更完美了，呵呵。完成此文，已经是凌晨了，也算是回答了前一段时间提出要进行BS结构测试又无从下手的朋友的要求，在这里要向大家表达一下歉意，由于工作比较忙，难免对大家的来信有所疏漏，请大家原谅。此文的要求的读者，对测试工具有所了解，希望进入更深测试的同仁，希望我的文章给大家带来帮助,同时也借此文表达一些曾经帮助过我的朋友与同事。注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标。浅谈ClearQuest建库指运行前提

作者：Windows2000 服务器上已经安装RationalClearQuest 版Windows2000Server服务器上已经安装SQLServerWindows2000Server+SQLServer上建立空的数据库先在SQLServer上建立一个空的数据库，建库时请注意给ClearQuest的主数据库(SchemaRepository)数据文件分配至少50M的空间。如图一所示：为ClearQuest主数据库建立专门的用户。注意：不要使用SA作为ClearQuest数据库的Owner,这是因为当你将来要进行更新或迁移ClearQuest主数据库时，ClearQuest将会向SQLServer请求一个空的数据库。可是，如果以SA用户登录ClearQuest主数据库时，因为SA可以到系统表，故在迁移或更新ClearQuest主数据库时将不能够继续进行。建立ClearQuest专门的登录用户步骤可见图二和图三.ClearQuest用户必须使用SQLServer的验证，同时将默认的数据库设置为ClearQuest.使用MaintenanceToolClearQuest的主数据库ClearQuestMaintenanceTool,从菜单上选择“Connection->New”来建立一个ClearQuest的主数据库（schemarepository），即保存你定义的各种方案。如图四:接下来我们需要在SQLServer2000服务器上建立ClearQuest服务器。当然如果你选择ACCESS数据库直接按回车即可。当你在Vendor:中选择SQLServer后(见图五)，将会出现有关与SQLServer服务器连接的信息设置。具体设置如图六:可以通过右键改变CQ主数据库名，我们可以将其命名为上次有个网友问我：“HTTP,当使用Read-OnlyUser我怎么也连接不到数据库中”。当时我试了多种方法也仔细查过相关资料，只能通过其DBOwner才可连通。如果使用只有[读]权限的用户会失败的，不知道其它人是如何解决此问题的？有人知道有劳通知大家。：）不过在使用过程中没有较大的影响，如果是在2002.05以前的版本时，使用时会存在一些安全，因为必竟DBOwner的权限过大些。呵呵，事在人为嘛。接下来CQMaintenanceTool将会显示建立CQ主数据库的过程，按提示点击确定即可。到此为止CQ的主数据库即大功告成了。接下来进行如何在ClearQuestDesigner中建立各种方案(Schema)。4、使用CQDesigner建立各种方案(Schema)当你运行ClearQuestDesigner时，会出现请你选择使用哪个CQ主数据库，我们在这里选择上面建立的:MyTest.在这里请注意，我们说明界面均是CQ2002.05版，以前的版本界面不是这样的。如图七:第一次运行ClearQuestDesigner时,请使用用户为：Admin为：空，登陆进入到ClearQuestDesigner中.此处的用户不同于主数据库的用户.Designer中的用户是用来在使用你设计的方案时所需的用户,由Designer自已的用户管理器创建.并为其分配相关的数据库权限.当你在Designer中建立数据库时,前提是你必需在SQLServer上建立好一个空的数据库,同时为此库建立自已独立的DBOwner.然后才可运行Designer进行建立方案.当进入CQDesigner后，首先弹出的窗体为CQ中向你提供的八个应用方案.你可以根据自已的应用情况选择合适的方案，当然可以自已完全定制一个方案，关键是看你对CQ的了解程度。我建议先自已学习它提供的方案，然后自已动手定制一个完全符合自已的应用方案。因为CQ中提供的方案一般与Rational的其它产品结合较为紧密，许多功能我们暂时用不上，没有必要花很大的力气了解它，路要一步步走嘛。在此我们以CQ提供的”DefectTracking”方案为例，建立一个自已的方案步骤。如图八：进入CQDesigner后，先取消图八的窗体。然后在CQDesigner的主菜单上选择”Database→NewDatabase”项。将出现如图九所示窗体，即为建立方案库的第一步。该窗体中的LogicalDatabaseNameCQDesigner管理各种方案而使用的一种逻辑库，在CQDesigner中使用这些逻辑库来进行方案的删除，恢复删除和更新.这里的逻辑库并不是你在SQLServer建立的表。点击[下一步]后,进入建立方案库的第二步；将出现连接你已经在连接数据库的用户必须是该空表的DBOwner/写的用户仍连接不成功。原因同上面我说的，待查。：（在最下的请选择ProductionDatabase，它代表此方案用于实际应用，而并非专为测试方案----TestDatabase使用。有关测试方案库我们会在以后再讲。在图十上点击[下一步]将进入建立方案库的第三步,即为方案定制超时设置。一般情况下可以为默认值。再点击[下一步]为建立方案库最后一步，在CQ提供的方案模板中选择我们要创建的“DefectTracking”方案。如图十一所示：最后点击[完成]按钮，拿一杯热茶等着吧，如果一切顺利将会出现”Databasewascreatedsuccessfully”框。恭喜你成功了!想进一步验证，可以通过ClearQuest客户端来进行，动行ClearQuset,在其出现的首个框中选择你刚才建立的方案，使用管理员进入后便可进行其应用了。aonalaQuest功能很强大，以后有机会我们大家多交流，写出更好的使用经验点滴，希望我这陋文能起到抛砖引玉的作用。同时也希望能与大家交流使用经验. 43《单元测试技术――Nunit3《测试管理――TD》2《自动测试工具――Robot2《自动测试工具――LoadRunner2关注性能：压力负载压力测试和负载测试

来源在性能列表中最常问的问题是：“是否有一种工具可以帮助我对J2EE应用程序进行压力测试？”在回答这个问题之前，让我们问一问自己：压力测试是什么，为什么这些开发人员需要它？（我相信中相当一部分人曾经遇到一定要在昨天完成测试这种感到压力的情况，但是我们在这里说的不是这个）。压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请求的频率、请求的混合程度，等等）并描绘性能的变化。对于一些应用程序，您需要做的就是这些。但是如果有许多输入，或者需要在大的范围内改变输入，那么就可能需要一个自动化的工具。另外，在手工测试中，如果想在进行一些改变后重新测试应用程序，可能很难精确地重复一组测试。如果是让多个用户测试您的应用程序，那么几乎不可能一致性地运行手工测试，除非您有很多失业的朋友，否则扩大测试应用程序的用户数量是非常的。没有一刀切的方案不幸的是，没有一种通用的压力测试工具，因为每一个应用程序所接受的输入以及对它们进行处理的方式都是不同的。但是对于许多J2EE应用程序来说，从客户机到达服务器的通信使用的是HTTP协议。幸运的是，有许多负载测试工具可以以一种可控制和重复的方式模拟HTTP上的用户活动。它们包括免费工具如ApacheJMeter、TheGrinder以及PushToText，和相当昂贵的工具如MercuryAstraload。一般来说一分钱一分货——工具越贵，它能做的事情就越多。为了了解它们的差别，我们运行一个线程的程序。每一个线程需要与服务器通信，可能使用 .URL类。这种方法使您得到基本的HTTP客户机模拟，它可以执行GET和PUT。每个线程需要做的就是发送HTTP请求、收集回复、等待一些时间（复。这一组行动可以相当容易地抽象到一个单独的配置文件中。很快，您就得到一个基本的负载测试工具。您可能需要增加一些配置选项以确定运行多少个线程（模拟的客户机）以及它们是同时开始还是慢慢增加负载。当然，您需要对与服务器的交互计时，因为这是您要测试的内容。如果这么简单…那么，对于处理扩展的交互（即一个请求取决于上一个请求的结果）如何呢？对于处理 s如何呢？ s对于许多面向会话的J2EE系统是必不可少的。改变数据输入呢？如果J2EE应用程序客户机需要处理一些JavaScript以进入下一次通信呢？在收集了响应时间数据后，如何对它进行分析？其他类型的监视，如CPU时间、网络使用、堆大小、分页活动或者数据库活动呢？像这样和其他的功能，如用于记录浏览器会话并将它们加入到测试中的工具，是高端负载测试工具与基本工具的差别所在。如何为自己选择正确的工具呢？当然，这取决于您的需要、您的计划和您的预算。最重要的是，您需要使用可以正确地模拟您的应用程序要求的客户浏览器功能的工具。具备了基本功能后，可以考虑工具的生产率。一般来说，包含的分析工具越多，可以记录的性能数据类型越多，您可以达到的生产率就越高——您愿意付的钱也就越多。顶级的负载测试程序可以模拟多个浏览器，与大多数应用服务器集成，收集多个服务器主机的性能数据（包括操作系统、JVM和数据库统计数字，生成可以在以后用高级的分析工具分析的数据集。另一方面，负载测试程序是免费的。在那些预算有限的日子里，“免费”的意义是不言自明的。图1展示了免费的负载测试程序ApacheJMeter，它显示了一个自动记录的图1.JMeter显示一个自动记录的我们已经看过了压力测试工具的基本功能，还适合增加什么附加功能呢？不同的负载测试工具的区别在什么地方呢？当然，您最主要的要求是这个工具必须可以模拟您的应用程序客户机。如果您的应用程序使用一些不常见的浏览器功能组合或者其他非标准客户机技术，那么就排除了相当一部分候选者。除此之外，还有其他功能使负载测试的生产率更高。对于决定适合于自己项目的负载测试工具，下面的列表是一个有用的出发点：模拟您的客户机首要要求一定是负载测试程序能够处理您的应用程序所使用的功能和协议。运行多个模拟的客户机这是负载测试程序最基本的功能，它有助于确定哪些是负载测试程序以及哪些不是（一些框架试图成负载测试程序。化执行并能编辑如果不能编写客户机与服务器之间交互的，那么就不能处理除最简单的客户机之外的任务东西。编辑的能力是最基本的——小的改变不应该要求您重新生成。支持会话负载测试程序如果不支持会话或者 s，那么就不算是真正的负载测试程序，并且不能对大多数J2EE应用程序进行负载测试。可配置的用户数量测试程序应该可以指定每个由多少个模拟用户运行，包括随时间改变模拟用户的数量，因为许多负载测试应该从小的用户数量开始，并慢慢增加到的用户数量。报告成功、错误和失败每一个都必须定义一个方法来识别成功的交互以及失败和错误模式（错误完全不会有页面返回，而失败可能在页面上得到错误的数据。页面显示如果负载测试程序可以检查一些发送给模拟用户的页面，这会很有用，这样您就可以确保测试工作是正确进行的。导出结果您常常希望可以用不同的工具来分析，这些工具包括电子表格和可以处理数据的自定义。虽然许多负载测试工具包括大量的分析功能，但是导出数据的能力使您在以任意的方式分析和编目数据方面具有更大的灵活性。考虑时间真实世界的用户不会在收到一页后立即请求另一页——一般在查看一页和下一页之间会有延迟。考虑时间这个标准术语表示在中加入延迟以更真实地模拟用户行为。大多数负载测试程序支持根据统计分布随机生成考虑时客户机从列表中选择数据用户一般不会使用同样的一组数据，每位用户通常与服务器进行不同的交互。模拟用户应该也这样做，如果在交互的关键点，可以从一组数据中选择数据，则可以更容易地的模拟用户表现出使用不同数据的行为。从手工执行的会话记录相对于编写，用浏览器手工运行会话并记录这个会话然后再编辑会容易得多。一些应用程序大量使用JavaScript并且需要模拟客户机支持它。不过，使用客户端JavaScript可能会增加对测试系统上系统资源的需求。分析工具测量性能只是成功的一半。另一半是分析性能数据。谁能比编写测试工具的人能更好地开发这种分析工具呢？是的，至少理论是这样。无论如何，您的工具箱提供的分析工具越多，您就能做得越好。测量服务器端统计数字基本负载测试程序测量客户机/服务器交互中基于客户机的响应时间。如果同时收集其他统计数字，如CPU使用情况和页面错误率就更好了。您得到的统计数字越多，您用负载测试系统可以做的就越多。如果有这种数据，那么就可以做一些有用的工作，如查看服务器负载上下文中的客户机响应时间和吞吐量统计。结束语用任何一种工具可以完成的工作常常受到人的技能、知识和想像力的局限。在描述用负载测试工具查看什么内容的时候，我们也展示了使用这种工具的各种可能性。现在，您可以运用您的想像力去开拓的可能性。性能测试：软件测试的重之作者：中国软件评测中心性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。应用在客户端性能的测试应用在客户端性能测试的目的是客户端应用的性能，测试的是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。并发性能测试是重点并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源指标来确定系统并发性能的过程。负载测试（LoadTesting）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（StressTesting）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运试，当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问?这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和点播等系统。这种问题的解决要借助于科学的软件测试和先进的测试工具。举例说明：电信计费软件众所周知,每月20日左右是市话交费的期，全市几千个网点同时启动。过程一般分为两步,首先要根据用户来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端，同时执行这样的操作时，情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力,预见软件的并发承受力,这是在软件测试阶段就应该解决的问题。目前，大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户反应慢、系统失灵等问题。其结果就是导致公司收益的损失。如何模拟实际情况呢?找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间？这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。并发性能测试前的准备工作测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的。测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、BenarkFactory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、多种平台、自动执试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。模拟真实环境测试，有些软件，特别是面向大众的商品化软件在测试时常常需要在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。并发性能测试的种类与指标并发性能测试的种类取决于并发性能测试工具的对象，以QALoad自动化负 WinSock、WWW、JavaScript等不同的对象，支持Windows和UNIX测试环境。最关键的仍然是测试过程中对对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择JavaScript对象，手工编写脚本，可以达到测试目的。采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试录制、编写与调试，脚本分配、回放配置与加载策略，测试执行，结果分析与定位问题所在，测试报告与测试评估。并发性能测试的对象不同，测试的主要指标也不相同，主要的测试指标括交易处理性能指标和UNIX资源。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，Median：中值响应时间；9090％事务处理的服务器响应时间、虚拟并发用户数。应用实例：“多数据库V1.0”性能测中国软件评测中心（CSTC）根据技术局《多数据库（一期）性能测试需求》和GB/T17544《软件包质量要求和测试》的，使用工业标准级负载测试工具对使用的“多数据库V1.0”进行了性能测试。性能测试的目的是模拟多用户并发 多数据库，执行关键检索业务，分析系统性能。性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200，进试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及UNIX（Linux、Oracle、Apache资源等。测试结论：在机房测试环境和内网测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户数为200的负载压力，最大交易数/分钟达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。系统能够承受200并发用户数持续周期约8通过对系统UNIX（Linux、Oracle和Apache资源的，系统资源能够满当并发用户数超过200时，到HTTP500、connect和超时错误，且Web服务器报内存溢出错误，系统应进一步提高性能，以支持更大并发用户数。疲劳强度与大数据量测试疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源指标来确定系统处理最大工作量强度性能的过程。疲劳强度测试可以采用工具自动化的方式进试，也可以手工编写程序测试，其中后者占的比例较大。一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源数据。如出现错误导致测试不能成功执行，则及时调整测试指标，试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。大数据量测试可以分为两种类型：针对某些系统、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。应用在网络上性能的测试应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能、网络应用性能分析和网络预测。网络应用性能分析网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如ApplicationExpert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用ApplicationExpert调整应用在广域网上的性能；ApplicationExpert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。网络应用性能在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在LAN或AN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Networkantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。网络预测考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。从网络管理软件获取网络拓扑结构、从现有的流量软件获取流量信息（若没有这类软件可人工生成流量数据，这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。应用在服务器上性能的测试对于应用在服务器上性能的测试，可以采用工具，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面。UNIX资源指标和描述指标描述平均负载系统正常状态下，最后60秒同步进程的率在以太网上监测到的每秒进程/线程交换率进程和线程之间每秒交换次数CPU利用率CPU占用率（％）磁盘交换率磁盘交换速率接收包错误率接收以太网数据包时每秒错误数包输入率每秒输入的以太网数据包数目中断速率CPU每秒处理的中断数输出包错误率发送以太网数据包时每秒错误数包输入率每秒输出的以太网数据包数目读入内存页速率物理内存中每秒读入内存页的数目写出内存页速率每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目内存页交换速率每秒写入内存页和从物理内存中读出页的个数进程入交换率交换区输入的进程数目进程出交换率交换区输出的进程数目CPU利用率系统的CPU占用率用户CPU利用率用户模式下的CPU占用率（％）磁盘阻塞磁盘每秒阻塞的字节数成功软件测试管理的九大原则作者简介许多测试管理者是从技术部门进到管理阶层的。尽管他们有可能受过很多测试或软件工程的培训和指导，但他们还是很难经常从失败和错误中学到管理技巧。作为一个管理者，你有两项基本工作：找出为你工作的最好的员工并且建立一个能够使员工完成工作的环境（使他们最好地完成工作。这篇文章讲述了一些我学过的关于这些管理工作的经验。第一．为工作雇佣最好的员工我遇到许多管理者，他们要雇佣的员工仅仅是他们上一个雇佣的。作为一个测试管理者，你必须对你需要什么人做出评估。假设现在你的部门满是极好的探索型的测试员。如果你还要雇另一个探索型的测试员，也许比你现在的要好，但是他对你的空白领域有作用吗？也许有，也许没有。工作的最佳人选也许就是你现在这个小组里所没有的类型。最佳人选或许并不“适合”你通常的工作方式。作为一个测试管理者，雇佣一个最佳的员工要用发展的雇佣策略，面试时要检验他是否符合这个策略。这可以让你找到最适合这份工作的人员，他能够完成必要的工作。第二.安排每周与你的每个小组成员在不被打扰的环境进行谈最为一个测试经理，主要工作之一就是定期的评定你的组织做了些什么并且是怎样做的。你还要为你的员工做一个报告，关于充分了解他们正在做什么和他们是怎样做的，以此来给做他们正式的和非正式的工作成绩考核。如果你没有了解到每个人的动态你就不应该对你的报告满意。我定期地给我的小组成员每周在不被打扰的条件下做一对一的谈（当我管理12个员工的时候，我安排在另外一周会见另一些人。周用30分钟来和每个员工谈谈他们的工作：他们工作中的问题或是意见；他们是否需要帮助，他们的表现和他们达到目标的兴奋。我一般安排一周的某天来进行一对一谈话。我事先安排出和每个人的特定时间，接下来我亲自会见他们每个人。如果我们不能把所有需要谈到的细节都包括，我们会安排另外一个时间来继续。许多管理者说他们没有时间在一周会见每一个员工来谈他们的工作。据我的经验，如果我不能安排时间和我的员工进行每周的谈话，他们会来打扰我的工作，因为他们无论如何还是必须要来找我。如果你安排和你员工的谈话，你必须减少计划外的打扰（既有他们的也有你自己的，并且的了解他们在做什么。当你清楚你的小组正在做的，你才能更有效率地帮助他们明确优先应该做的工作，重聚资源，重新计划工程的部分，排除等等。第三.假定员工知道如何完成他们的工作的人员因为很多管理者起初做的是技术工作，他们知道他们的员工现在从事的工作。他们认为他们现在知道。如果你已经管理了两三年，你也许还没有你的技术员工知道的多，尤其是怎么样完成日常工作。你或者你的前任者雇佣你小组的员工。假设你雇佣这些人因为你认为他们能够完成工作，如果你设想每个人都知道如何完成他们的工作，你将得到比假设他们都不知道怎么完成的更好的效果。即使有些员工在无论你设想是否都能成功完成工作，但是有些员工将会被你对他们的想法所影响工作。因为我知道我的员工都知道怎样做他们的工作，我给他们分派任务。问他们是否需要帮助，然后留他们独自完成（除非他们寻求帮助。我的意思并不是你不应该在他们工作的时候和他们说话，你只是不该打扰他。打扰可以分为几种不同的形式：·,这将仍然不能使你对他们的要如果你每天都问，更糟的是每个钟头都问,他们是如何做的。这看起来就像对你员工进行微机管理，很惹人烦。毕竟,你没有工作要做吗？另外,他们会以为你认为他们不知道该如何完成工作。如果当他们没有问你意见，你说“我会用这种方法”。这种予以打击的帮助不会有用。.如果你不确定怎样能知道你的员工是否胜任，和每一个小组成员商讨寻求帮助的时机。每个人，包括你自己，应该选择一个规则来知道他或她什么时候成为了一个令人讨厌的家伙了。我的一个客户有一个15分钟。如果有人在某方面令人讨厌持15当你分配工作时，问问你的员工是否明白该做什么，他或她是否有方法完成。确定工作进程，如果员工遇到麻烦，他应该主动找你寻求帮助，但是如果你坚决，你的员工将会把找你寻求帮助作为最后的解决方法。第四.对待你的员工要用他们能接受的方式,而不是你可以自己可以接受的方式“对待别人要用你愿意接受的方式”（己之不予，勿施于人）――这条黄金法则可能会对许多生活中的纯的社交因素有效，但是并不是总对工作有用。有效率的管理者知道他的每一个员工需要怎样的对待方式。当其他的人更乐意接受的信息。一些人去需要特定的任务和指示。一些因为解决新的，很棒的，复杂的问题而更有冲劲，但是还有一些只是对他们已经知道如何去处理的问题而感另外，针对于不同的工作，我们都喜欢不同的认同方式。金钱不是表示认同的唯一方式，你可以用其他的方式来酬劳你的员工。有些人喜欢对他个人的感谢，有人乐意在公众面前的认可，一些喜欢以M﹠M方式，或者是票，还有人希望有团队的排队来庆祝。记住无论什么的激励你的方式都不一定能激励你小组的每一个其他成员。和你的小组成员们通过讨论来了解他们每个人对比较喜欢的予方式。创造一个好的工作环境第五重视结果而非时间许多认可建立在员工完成工作的时间上，而不是他们最后的成绩上。但是，花费在工作上的时间不一定和创造性有必然的联系。如果你真的想改善对创作性和工作效率的认可的话，不妨考虑保证你员工每周只工作40个小时。我常常听到一种表示对员工的异议就是“你整整一天什么都做不出来。”假设你自己处在一个巨大的前，考虑你可以做什么来解决的时候，你是不是取消了会议？你的小组成员能否安排他们的工作以至于能够最大限度发挥创造性？当人们每周工作超过40个小时的时候，他们开始在工作的时候关心他们自己的事。他们花钱，他们给很久没有联系的人打，因为他们一直都在工作。一旦你创造了一个环境，让员工在工作时间完成工作，开始鼓励他们每周不要超过40小时，接着你就可以基于他们在40个小时能够完成的工作量给他们酬劳。我总是发现这样能够提升创造力（因为员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己。当你开始注意规律，不仅仅是时间，还包括更容易地给员工的表现给予精确的适度的评价。你的员工是否完成了他们的计划和测试设计？当他们开发测试的时候，他们还要修订那些他们需要的改进的部分？（如果你只是注意有多少测试可以使用，我可以重复地开展相同的测试）计划每周工作40个小时，并且为你要在这段时间完成的工作付。第六.承认自己的错误每个人都会犯错。他们会因为忘记开会而使客户发怒。承认你犯错是令人尴尬的。我们中的许多人认为对小组承认自己犯错会失去尊严。如果你不是经常犯错，你承认错误的时候其实能够赢得尊敬。如果你忘记一次会议，你为此道歉，其他的人会理解你并且最终原谅你。不管你做了什么，不要否认或故意忽略你的。故意忽略不会让错误这只会让错误成长为怪物。最近，有一个委托人在会上对他的员工大声斥责。会后，他认识到他不应该那样在小组会上那样做。他只是想让他们安心工作，等过几天再道我建议在他们对他积累怒气之前，应该用正确的方式和他的员工交谈。他起初都是这样对他说的：“在会后才对你感到生气的。如果您能够立即和我谈谈，我就不会把它们积累起来。但是现在已经两天过去了,我仍然对您感到生气，事实上，我还更加恼火，我现在不能确信现在是否能相信您。我不介意你对我们大吼，但是我不能确定是否还会再这样做。我的客户不知道应该如何处理这种情况。他认为他的等待是正确的，但是却让问题变得更加严重。.他已经决定再也不会犯这样的错误了，而且会立刻和会员工交流。他的员工用了好几个月来重新相信他，但是我的这位客户的确通过承认过错而增加了他的。现在，他和他的员工对这件事可以当做是玩笑来说。他们说这是他的认知和能力的巨大转折点。第七.决定承担一个项目必须首先问你的组员是否有能力完成当你是一个下级的员工，你的对你说“我们是否可以在下个十月完成项目？”回答说“当然”会令人惊讶。但是，你的员工会因为你回我要考虑一而表示赞赏。即使你已经在考虑这个问题，告诉了你