|
|
|
|
|
|
|
软件测试作为保证软件质量和可靠性的关键技术，正日益受到广泛的重视，但随着软件工程的规模越来越大，客户对软件的质量要求越来越高，测试的工作量也越来越大。如何进行测试，如何提高测试的质量和效率，从而确保软件产品的质量和可靠性，就成了许多人深感困扰的问题。
|
|
|
|
目前，企业级应用系统越来越多，这些系统可能包括ERP系统，CRM系统等。这些系统在发布之前或升级之后都要经过测试，确保主要功能都能正常运行，错误最少。如何有效地测试不断升级和不断更换应用环境的应用系统，是每个公司都会面临的问题。如果时间或资源有限，这个问题会更加棘手。人工测试的工作量太大，同时还需要额外的时间来培训测试人员等。为了确保那些复杂的企业级应用在不同环境下都能可靠地运行，需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。
|
|
|
|
同时，目前企业的网络应用环境都必须支持大量用户和不同的软硬件应用环境。难以预知的用户负载和越来越复杂的应用环境使公司时时担心会发生用户响应速度过慢、系统崩溃等问题。这些都不可避免地导致公司收益的损失。为了在终端用户正式使用前，对应用系统各个环节的质量、可靠性和可扩展性进行测试和评价，就需要适用于不同体系架构的自动负载压力测试工具，以预测系统行为并为系统优化提供依据。
|
|
|
|
总之，为了更加快速、有效地对软件进行测试，提高软件产品的质量，我们必然会利用测试工具，也必然会引入自动化测试。
|
|
|
|
|
|
自动化测试就是通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动的测试，它是软件测试的一个重要的组成部分，它能够完成许多手工无法完成或者难以实现的一些测试工作。正确、合理地实施自动化测试，能够快速、全面地对软件进行测试，从而提高软件质量，节省经费，缩短产品发布周期。
|
|
|
|
软件测试自动化涉及到测试流程、测试体系、自动化编译以及自动化测试等方面的整合。也就是说，要让测试能够自动化，不仅是技术、工具的问题，更是一个公司和组织的文化问题。首先公司要从资金、管理上给予支持，其次要有专门的测试团队去建立适合自动化测试的测试流程和测试体系；最后才是把源代码从受控库中取出、编译、集成、发布并进行自动化的功能和性能等方面的测试。
|
|
|
|
|
|
|
|
自动化测试能够替代大量手工测试工作，避免重复测试，同时，它还能够完成大量手工无法完成的测试工作，如并发用户测试、大数据量测试、长时间运行可靠性测试等，概括地说，自动化测试具有如下优点。
|
|
|
|
. 提高测试质量：软件开发的过程就是一个持续集成和改进的过程，而每一次修改都有可能产生错误。因此，当软件产品的一部分，或者全部，或者应用环境被修改时都需要对软件产品重新进行测试，其目的是验证修改后的系统或者产品的质量是否符合规格说明。例如，对于产品型的软件，每发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特别适合于自动化测试，由于自动测试工具提供了简便的回归测试，能以便利的方式验证是否有新的错误进入软件产品，既节省了重复手工输入的工作量，保证了测试案例的一致性，避免了人为因素，也可以使测试达到测试每个质量特性的目的，从而提高软件测试的质量。
|
|
|
|
. 提高测试效率，缩短测试工作时间：软件系统的规模越来越大，功能点越来越多，达到几千个上万个，人工测试非常耗时和繁琐，这样必然会导致测试效率低下，而自动化测试工具可以较好地执行这些频繁的测试任务。在充分并合理地使用了测试工具以后，可以减轻测试工程师的手工测试工作，同时，测试工具还可以把控制和管理引入整个测试过程，能够保证测试的进度。
|
|
|
|
. 提高测试覆盖率：通过自动化测试工具的录制回放及数据驱动来测试功能，可以提高测试覆盖率。通过测试工具的辅助分析功能，可以提高测试的深度。
|
|
|
|
. 执行手工测试不能完成的测试任务：有些非功能性方面的测试，例如，压力测试、负载测试、大数据量测试、崩溃性测试等，人工测试是不可能实现的。例如，找若干台电脑和同样数目的操作人员在同一时刻进行操作，然后拿秒表记录下反应时间，这样的手工作坊式的测试方法不切实际且无法捕捉程序内部变化情况。
|
|
|
|
. 更好地重现软件缺陷的能力：自动化测试具有更好的一致性和可重复性，由于每次自动化测试运行的脚本是相同的，所以每次执行的测试具有一致性，人是很难做到的。由于自动化测试的一致性，很容易发现被测软件的任何改变。
|
|
|
|
. 更好地利用资源：理想的自动化测试能够按计划完全自动地运行，在开发人员和测试人员不可能实行三班倒的情况下，自动化测试可以胜任这个任务，例如，完全可以在周末或者晚上执行测试。这样充分地利用资源，也避免了开发和测试之间的冲突。
|
|
|
|
. 增进测试人员与开发人员之间的合作伙伴关系：测试工程师为了更好地使用自动化测试工具，需要对开发技术有深入的理解和实践，因此测试工程师也有了与开发工程师更多、更平等地交流的机会，自动化测试为测试工程师与程序开发人员协同工作提供了一种便利的手段，双方将有更多的合作与尊重。
|
|
|
|
测试工具能够提高软件质量，改进测试过程，因此在许多公司中得到了广泛应用，由于自动化测试工具自身的特点，为达到较高的投资回报率，在以下项目和环境中更适合使用自动化测试工具。
|
|
|
|
. 需要反复进行的工作。在持续修改软件功能的项目中，对功能的测试需要反复进行，人工测试工作量极大。功能性测试工具能够自动进行重复性的工作，验证软件的修改是否引入了新的缺陷，旧的缺陷是否已经修改。减少人工测试的工作量。
|
|
|
|
. 负载压力测试。负载压力测试需要模拟大量并发用户和大数据量，这样的测试用手工不能完成或不能很好地完成，而自动化测试工具则可以很好地解决这个问题，在测试脚本运行过程中也不需要人工干预，能够充分利用非工作时间。
|
|
|
|
. 公司有大量的测试人员和开发人员，他们合作完成一个产品，那么如何在产品的生命周期中进行有效管理和合作，借助于自动化的测试管理工具，会取得事半功倍的效果。
|
|
|
|
. 如果需要进行测试系统后台或者内部的性能特性，进而进行故障定位和性能调优，自动化测试工具会是一个不错的选择。
|
|
|
|
|
|
虽然自动化测试可以提高测试效率，能够完成手工测试不能完成的工作，但自动化测试在实际应用中也存在局限性，并不能完全替代手工测试，在下面的领域中自动化测试会有一定的局限性。
|
|
|
|
. 定制型项目：为客户定制的项目，甚至采用的开发语言、运行环境也是客户特别要求的，开发公司在这方面的测试积累少，这样的项目不适合作自动化功能测试。
|
|
|
|
. 周期很短的项目：项目周期很短，相应的测试周期也很短，因此花大量精力准备的测试脚本，不能得到重复地利用。当然，为了某种特定的测试目的专门执行的测试任务除外，比如，针对特定应用的性能测试等。
|
|
|
|
. 业务规则复杂的对象：业务规则复杂的对象有复杂的逻辑关系和运算关系，工具很难实现，或者要实现这些测试过程，需要投入的测试准备时间比直接进行手工测试所需的时间更长。
|
|
|
|
. 人体感观与易用性测试：界面的美观、声音的体验、易用性的测试，无法用测试工具来实现。
|
|
|
|
. 不稳定的软件：如果软件不稳定，则会由于这些不稳定因素导致自动化测试失败，或者致使测试结果本身就是无效的。
|
|
|
|
. 涉及物理交互：自动化测试工具不能很好地完成与物理设备的交互，比如刷卡器的测试等。
|
|
|
|
任何工具都有它的可用范围，就像我们不能拿剪刀去劈柴，不能拿斧头去裁减布料一样，面对任何一个待测系统，我们也应该考虑选用的测试工具是否合适，引入测试工具是否有利于该项目的开发等，否则，有可能适得其反。
|
|
|
|
以上介绍了自动化测试的局限性，因此，作为测试工程师，在考虑选用自动化测试的过程中，还需要了解公司领导、项目负责人等对于自动化测试的期望并消除他们一些不正确的期望，如下所示。
|
|
|
|
. 自动化测试可以完成一切测试工作：很多人一听到测试自动化，就认为自动化测试工具可以完成一切测试工作，从测试计划到测试执行，再到测试结果分析，不需要任何人工干预等，很显然，这是一种理想状态，现实中还没有哪个测试工具有这个能力，并且将来也不会有。在现实中有关的测试设计、测试案例以及一些关键的测试任务还是需要人工参与的，即自动化测试是对手工测试的辅助和补充，它永远不可能取代手工测试。
|
|
|
|
. 测试工具可适于所有的测试：每种自动化测试工具都有它的应用范围和可用对象，所以不能认为一种自动化测试工具能够满足所有的测试需求。针对不同的测试目的和测试对象，我们应该选择合适的测试工具来对它进行测试，在很多情况下，需要利用多种测试工具才能完成测试工作。
|
|
|
|
. 测试工具能使工作量大幅度降低：事实上，引入自动化测试工具不会马上减轻测试工作，相反，在更多情况下，首次将自动化测试工具引入企业时，测试工作实际上变得更艰巨了。只有在正确合理地使用测试工具，并有一定的技术积累后，测试工作量才能逐渐减轻。
|
|
|
|
. 测试工具能实现百分之百的测试覆盖率：由于自动化测试可以增加测试覆盖的深度和广度，比如，利用白盒测试工具可能实现语句全覆盖、逻辑路径全覆盖等，但因为穷举测试必须使用所有可能的数据，包括有效的和无效的测试数据，所以在有限的资源下也不可能进行百分之百的彻底测试。
|
|
|
|
. 自动化测试工具容易使用：对于这一点，很多测试工程师也有同样的错误观点，认为测试工具可以简单地通过捕获（录制）客户端操作生成脚本，且脚本不加编辑就可用于回放使用。事实上，自动化测试不是那么简单，捕获的操作是否正确以及脚本编辑是否合理都会影响测试结果，因此，自动化测试需要更多的技能，也需要更多的培训。
|
|
|
|
. 自动化测试能发现大量的新缺陷：发现更多的新缺陷应该是手工测试的主要目的，不能期望自动化测试去发现更多新缺陷，事实上自动化测试主要用于发现老缺陷。
|
|
|
|
|
|
|
|
自动化测试工具可以减少测试工作量，提高测试工作效率，但首先是能够选择一个合适的且满足企业信息系统工程环境的自动化测试工具，因为不同的测试工具，其面向的测试对象是不一样的。按照测试工具的主要用途和应用领域，可以将自动化测试工具分为以下几类。
|
|
|
|
. 负载压力测试工具：这类测试工具的主要目的都是为了度量应用系统的可扩展性和性能，是一种预测系统行为和性能的自动化测试工具。它们通过模拟成百上千直至上万用户并发执行关键业务，而完成对应用程序的测试，在实施并发负载过程中通过实时性能监测来确认和查找问题，并针对所发现问题对系统性能进行优化，确保应用的成功部署。负载压力测试工具能够对整个企业架构进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。这类工具的主要代表有LoadRunner、QALoad、SILK PERFORMA V和E-Test Suite等。
|
|
|
|
. 功能测试工具：通过自动录制、检测和回放用户的应用操作，将被测系统的输出记录同预先给定的标准结果进行比较，功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进行测试，提高测试人员的工作效率和质量。其主要目的是用于检测应用程序是否能够达到预期的功能并正常运行。功能测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。这类工具的主要代表有WinRunner、QARun等。
|
|
|
|
. 白盒测试工具：白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。静态测试工具直接对代码进行分析，不需要运行代码，也不需要对代码编译链接和生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。静态测试工具的代表有Logiscope软件和PRQA软件。动态测试工具与静态测试工具不同，动态测试工具一般采用“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。动态测试工具的代表有DevPartner、Rational Purify系列等。
|
|
|
|
. 网络测试工具：这类工具主要包括网络故障定位工具、网络性能监测工具、网络仿真模拟工具等。它们分析分布式应用性能，关注应用、网络和其他元素（如服务器）内部的交互式活动，以便使网络管理员能够了解网络不同位置和不同活动之间应用的行为。你可以用它在交易执行过程中、Web查找和检索中或在日常数据库上载/下载中跟踪应用行为。它可在会话级、代码级，甚至在帧级和包级观察应用的行为过程，并深入代码内部的结构，解析有问题的会话。
|
|
|
|
. 测试管理工具：测试管理工具用于对测试进行管理。一般而言，测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理，并且测试管理工具还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员通过一个中央数据仓库，在不同的地方就能交互信息。测试管理工具将测试过程流水化，从测试需求管理到测试计划、测试日程安排、测试执行到出错后的错误跟踪，实现了全过程的自动化管理。测试管理工具的代表有TestDirector、TestManger、TrackRecord等。
|
|
|
|
. 测试辅助工具：这些工具本身并不执行测试，例如它们可以生成测试数据，为测试提供数据准备等。
|
|
|
|
|
|
随着软件测试地位的逐步提高，测试的重要性逐步显现，测试工具的应用已经成为了普遍的趋势。总的来说，测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用测试工具的时候，我们也应该看到，在测试过程中，并不是所有的测试工具都适合我们使用，同时，有了测试工具并且会使用测试工具并不等于测试工具真正能在测试中发挥作用，因此，如何确定自动化测试策略显得至关重要。应用测试工具的目的很明确，一般而言，在测试过程中应用测试工具主要有以下几个目的。
|
|
|
|
|
|
|
|
|
|
为了更好地达到测试目的，在信息系统中应用自动化测试需要考虑以下问题。
|
|
|
|
. 选择合适的自动化测试工具：面对众多不同用途的测试工具，如何正确地选择合适的测试工具，是能否正常实施自动化测试的前提，我们在选用工具的时候，建议从以下几个方面来权衡。
|
|
|
|
①功能：功能当然是我们最关注的内容，选择一个测试工具首先就是看它提供的功能。当然，这并不是说测试工具提供的功能越多越好，在实际的选择过程中，适用才是根本。“钱要花在刀刃上”，为不需要的功能花费金钱是不明智的行为。事实上，目前市面上同类的软件测试工具之间的基本功能都是大同小异的，各种软件提供的功能也大致相同，只不过有不同的侧重点。例如，同为白盒测试工具的Logiscope和PRQA软件，它们提供的基本功能大致相同，只是在编码规则、编码规则的定制、采用的代码质量标准方面有不同。除了基本的功能之外，以下的功能需求也可以作为选择测试工具的参考。
|
|
|
|
. 报表功能：测试工具生成的结果最终要由测试人员进行解释，而且，查看最终报告的人员不一定对测试很熟悉，因此，测试工具能否生成结果报表，能够以什么形势提供报表是需要考虑的因素（标准符号有些混乱）。
|
|
|
|
. 测试工具的集成能力：引入测试工具是一个长期的过程，应该是伴随着测试过程改进而进行的一个持续的过程。因此，测试工具的集成能力也是必须考虑的因素，这里的集成包括两个方面的意思，首先，测试工具能否和开发工具进行良好的集成；其次，测试工具能够和其他测试工具进行良好的集成。
|
|
|
|
. 操作系统和开发工具的兼容性。测试工具可否跨平台，是否适用于公司目前使用的开发工具，这些问题也是在选择一个测试工具时必须考虑的问题。
|
|
|
|
②价格：除了功能之外，价格就应该是最重要的因素了，作为一个测试工程师，在选择购买测试工具时，应该具有成本意识，必须利用有限的资金满足企业对测试工具的大多数需求。
|
|
|
|
③测试工具的长期投资考虑：测试工具引入的目的是测试自动化，引入工具需要考虑工具的连续性和一致性，也就是说，对测试工具的选择必须有一个全盘的考虑，分阶段、逐步的引入测试工具。
|
|
|
|
. 确定测试工具的应用时机：购买了测试工具以后，如何让测试工具真正发挥作用，是应用自动化测试的关键。任何测试工具都有其应用范围，也许我们具备不同的测试工具，那么在不同的软件工程阶段，我们应该有计划地去使用相应的测试工具，并将测试工具的使用明确定义进公司的开发流程。例如，在单元测试阶段，我们应该重点采用白盒测试工具，当软件产品的功能以及用户界面基本确定和逐步实现后，则可以考虑开始使用功能测试工具。集成测试阶段，则可以引入负载压力测试工具，对系统可能承受的负载压力进行测试与评估，并辅以相应的资源，使用监控工具进行故障定位等。
|
|
|
|
. 确定测试重点：对于一些测试项目，尤其是在测试时间有限的情况下，比如，执行一次性能测试，我们必须能够确定被测项目的主要应用和关键步骤，应该对那些质量要求较高并且风险大的部分进行重点测试，例如在金融领域，对于那些每天管理数百万、数千万人民币流动的系统，需要特别对其硬件、软件的安全可靠性、可用性进行测试。
|
|
|
|
. 确定测试目标和指标：针对不同的软件，其软件质量要求的等级和目标是不一样的，通过测试工具可以更好地验证系统设计是否达到了预期目标，因此，在正式开始测试前，我们应该能够清楚地了解测试预期目标。
|
|
|
|
. 充分利用测试工具的优势：每个测试工具都有自己独特的实现技术，对于同一个测试项目，测试工具可能也提供了多种测试方案供选择，比如脚本录制过程中协议的选择，回放过程中用户并发模拟机制和方式的选择等，只有充分利用了测试工具提供的这些技术，才可能更好、更真实地测试应用系统的实际质量。
|
|
|
|
. 加强对测试工程师的技能培训，测试工具的使用者必须对测试工具非常了解。在这方面，有效的培训是必不可少的。测试工具的培训是一个长期的过程，不是通过一两次讲课的形式就能达到良好的效果的。而且，在实际使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专家负责解决，否则的话，对于测试工具使用者的积极性将造成很大的打击。
|
|
|
|
|
|
|
|
传统的手工测试是测试人员执行测试用例，然后将测试结果和预期结果相比较并记录测试结果。然而，随着软件工程的规模越来越大，软件产品的功能越来越复杂，同时，软件的更新换代也越来越频繁，软件测试部门的工作难度越来越大，手工测试已经跟不上这种发展趋势了。
|
|
|
|
功能自动化测试工具可以帮助测试工程师自动处理测试开发到测试执行的整个过程中的问题。你可以创建可修改且可复用的测试脚本，甚至可以在下班后让计算机自动执行脚本，从而减少劳动量，提高测试效率。
|
|
|
|
功能测试自动化工具的主要功能，就是为了确保应用能够按照预期设计执行而将业务处理过程记录到测试脚本中。当应用被开发完成或应用升级时，测试工具支持测试脚本的编辑、扩展、执行和报告测试结果，并且保证测试脚本的可重复使用，贯穿于应用的整个生命周期。
|
|
|
|
当一个应用开发完毕后，程序界面基本定型，这个时候，针对该应用的自动测试应该展开。自动测试的引入，大大提高了测试的效率和测试的准确性，而且测试人员一次设计的脚本，可以在软件生命周期的各个阶段重复使用，尤其在软件交付后，随着企业的发展，你的应用就会随之在数量和范围上增长。为了满足业务的需求，应用的改变会很频繁，对于这些需求，将可以通过小范围修改测试工具录制的脚本来完成。对于功能测试工具的使用，比较重要的是测试规划问题。如何规划一次录制，使它具有良好的可扩展性、重用性，整个脚本能够有清晰的层次和最大限度地适应以后程序的修改，这些也是在实际工程中用户最普遍遇到的问题，它的实施就需要有经验的软件测试人员介入并结合应用来进行具体分析。
|
|
|
|
|
|
功能自动化测试工具基本上都是采取录制回放的方式来模拟用户的实际操作。当你在软件操作中点击图形用户界面上的对象时，测试工具会用一种类C或者其他的脚本语言（TSL）生成一个测试脚本，该脚本记录了你的操作过程，然后测试工具就可以回放刚才的操作过程。当然你也可以手工编程生成这个脚本。通常情况下，测试工具采取两种录制模式。
|
|
|
|
|
|
这种模式根据你选取的图形用户界面对象（如窗体、清单、按钮等），把你对软件的操作动作录制下来，并忽略这些对象在屏幕上的物理位置。每一次你对被测软件进行操作，测试脚本语言会记录并描述你选取的对象和你的操作动作。当你进行录制时，测试工具会对你选取的每个对象做惟一描述并写入相应的文件中。当软件用户界面发生变化时，你只需更新特定的对象记录文件。这样一来，环境判断模式的测试脚本将非常容易地被重复使用。执行测试只需要回放测试脚本。回放时，测试工具从指定文件中读取对象描述，并在被测软件中查找符合这些描述的对象并模拟用户使用鼠标选取该对象、用键盘输入数据的操作。
|
|
|
|
|
|
这种模式记录鼠标点击、键盘输入和鼠标在二维平面上（x轴和y轴）的精确运动轨迹。执行测试时，测试工具让鼠标根据轨迹运动。这种模式对于那些需要追踪鼠标运动的测试非常有用，例如画图软件等。
|
|
|
|
不论测试工具采用的是哪种录制模式，通常情况下，其实施测试必须经历的几个操作步骤如下。
|
|
|
|
. 创建脚本：你可以通过录制、编程或两者同用的方式创建测试脚本。测试工具可以自动记录你的操作并生成所需的脚本代码，你还可以直接修改测试脚本以满足各种复杂测试的需求。录制测试时，在需要检查软件反应的地方插入检查点（checkpoint）。你可以插入检查点来检查GUI对象、位图（bitmap）和数据库。在这个过程中，测试工具会自动捕捉数据，并将该数据作为期望结果储存下来。例如，在创建测试时，可以设定哪些数据库表和记录需要检测，在测试运行时，测试程序就会自动核对数据库内的实际数值和预期的数值是否一致。
|
|
|
|
. 调试脚本：脚本录制或编辑结束后，你可以先在调试模式下运行脚本。并可以设置中断点（breakpoint）来监测变量，控制对象识别和隔离错误。
|
|
|
|
. 执行测试：脚本调试结束后，便可以在检验模式下测试被测软件。运行测试时，测试工具会自动操作应用程序，就像一个真实的用户根据业务流程执行着每一步的操作。此时，测试工具在运行脚本过程中如果遇到了检查点，就把当前数据和事先捕捉并保存的期望值进行比较。如果发现有不符合，就记录下来作为测试结果。在具体的测试过程中，为了全面地测试一个应用程序，需要使用不同类型的数据来测试。一般情况下，测试工具都能提供动态数据处理及参数化技术，可以用参数去代替定值，从而真实地反映多个用户行为。以一个订单输入的流程为例，你可能希望把订单号或客户名称作为可变栏，用多套数据进行测试。使用数据驱动向导，你可以选择订单号或客户名称用数据表格文件中的哪个栏目的数据替换。你可以把订单号或客户名称输入数据表格文件，或从其他表格和数据库中导入。数据驱动测试不仅节省了时间和资源，又提高了应用的测试覆盖率。
|
|
|
|
. 结果分析：每次测试结束，测试工具都会把测试情况显示在测试结果报告中。测试结果报告会详细描述测试执行过程中发生的所有主要事件，如检查点、错误信息、系统信息或用户信息。如果在检查点有不符合的情况被发现，你可以在测试结果窗口查看预期结果和实际测试结果。如果是位图不符合，你也可以查看用于显示预期值和实测结果之间差异的位图。如果由于测试中发现错误而造成测试运行失败，你可以直接从测试结果中查看有关错误信息。
|
|
|
|
|
|
|
|
当一个企业自己组织力量或委托其他的软件公司开发了一套应用系统的时候，尤其是以后在生产环境中实际使用起来时，用户往往会产生疑问，这套系统能不能承受大量的并发用户同时访问，随着生产数据的不断累积，系统的响应处理能力是不是会明显下降直至用户不能接受。这类问题最常见于采用联机事务处理（OLTP）方式的数据库应用、Web应用和视频点播应用等系统。
|
|
|
|
比如，电信计费软件，众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动，收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生的费用，然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤，当成百上千的终端同时执行这样的操作时情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统承受力。预见软件系统的并发承受力，这是在软件测试阶段就应该解决的。
|
|
|
|
如何模拟实际情况呢？找若干台电脑和同样数目的操作人员在同一时刻进行操作，然后拿秒表记录下反应时间？这样的手工作坊式的测试方法不切实际且无法捕捉程序内部的变化情况。这就需要负载压力测试工具的辅助。
|
|
|
|
那么，什么是负载测试和压力测试呢？负载测试是为了证明在与产品（预期）规模等同的数据库中处理给定的事务请求的容量下，系统功能与性能是否与需求规格说明中规定的，可接受的响应时间一致的测试过程。而压力测试则是使客户机在大容量情况下运行的测试过程，目的是查看应用将在何时何处出现中断，即识别系统的薄弱环节。压力测试中可能暴露的系统缺陷有内存泄漏、系统资源过量消耗、磁盘空间用完等。
|
|
|
|
负载压力测试工具可以记录下客户端的操作，并以脚本的方式保存，然后建立多个虚拟用户，在一台或几台PC机上模拟上百或上千虚拟用户同时操作的情景，同时记录下每一事务处理的响应时间、中间件服务器资源使用、数据库负载等，测试工程师可以根据测试结果分析系统瓶颈。
|
|
|
|
在各种类型的并发测试中，基于Web的应用占了很大的比例，现在有相当数量的联机事务处理（OLTP）类型系统采用Web方式，还有一些网站，对并发连接的数量和自己网站对大量用户访问的支持能力，都表示出了相当程度的关心。对于负载压力测试工具，它提供了对Web页面压力测试的完整解决方案，包括用户模拟、Web服务器监控、页面每秒钟点击率统计、单独页面加载时间分析等各种专门针对Web的特性。
|
|
|
|
随着服务器端处理任务的日益复杂以及网站访问量的迅速增长，服务器性能的优化也成了非常迫切的问题。在优化之前，最好能够测试一下不同负载条件下服务器的性能表现。定位性能瓶颈所在，是设计性能改善方案之前的一个至关紧要的步骤。
|
|
|
|
负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的Intranet网站，测试能够暴露出最终会导致服务器崩溃的内存漏洞、资源竞争等情况。但是在实际的开发过程中，要按照实际投入运行的情况，组织成千上万的用户来进行压力测试，无论从哪个方面看，都是不现实的。而且一旦发现了问题，不仅需要重复地进行这种耗费巨大的测试，而且问题不容易重现，不能方便地找出性能的瓶颈所在。而使用测试工具进行压力测试就不会存在这种情况。
|
|
|
|
无论是哪种情形，花些时间对应用进行负载压力测试可以获得重要的基准性能数据，为未来的代码优化、硬件配置以及系统软硬件升级带来方便。即使经费有限的开发组织也可以对它们的网站进行负载压力测试，因为有些测试工具是可以免费下载的。
|
|
|
|
在测试阶段使用负载压力测试工具进行测试，还可以模拟数据库死锁情况，结合压力分析SQL效率，优化应用程序和数据库配置等工作，使软件系统更加健壮和高效。这样的实例也很多，比如有公司在测试某省的大型电信业务网上受理系统时，200个并发用户同时联机时速度正常，但当达到用户量达到500个的时候，受理速度明显变慢，通过监控发现Web服务器的流量有所降低，而表空间对应的数据文件中发生的磁盘物理读的次数却大于正常水平，最后通过诊断确定有部分复杂的SQL查询（如大表连接操作，嵌套查询等）没有利用合适的索引和采用最优的解释方案，而造成全表扫描。而且数据库配置参数DB_BLOCK_BUFFERS太小，不能适应500个用户或更大规模的并发情况。经过测试人员和开发人员对系统的共同调整，再次测试的时候一切恢复正常，500个用户的并发测试顺利通过。
|
|
|
|
|
|
负载压力测试工具基本上都是采取录制回放的方式来模拟用户的实际操作的，而且测试工具一般都会有一个后台代理进程，通过该代理进程，测试工具可以监视并获取在各种通信协议下应用系统的客户与服务器端的通信信息，测试工具会用一种类C或者其他的脚本语言（TSL）生成一个测试脚本，该脚本记录了你对服务器的请求过程，然后测试工具就可以回放刚才的访问过程，接收服务器的响应，当然你也可以用手工编程生成这个脚本。
|
|
|
|
通常情况下，实施负载压力测试的工作示意图如下图所示。
|
|
|
|
|
|
|
|
当被测系统运行时，脚本生成器会自动获取系统客户端与服务器的通信信息并转换成测试工具可以识别的脚本，测试工具通过控制台将测试脚本分发到其他负载生成器上以模拟多用户对服务器的并发访问，同时，控制台还可以通过服务器上开启的远程RPC服务，获取相关的资源使用信息，最后可以收集测试数据。
|
|
|
|
在进行测试脚本录制与分配的过程中，应遵循如下几个原则。
|
|
|
|
. 脚本越小越好。就像编写程序代码一样，不要太长，尽量做到一个功能一个脚本。如果那些功能是连续有序的，必须先做上一个，才能执行下一个，那就只好放在一起了。
|
|
|
|
. 选择负载压力最高的业务功能进行测试。有些人总希望能够测试几乎所有的功能，但事实上，这种想法不可行，因为测试是需要投入时间和金钱的，我们应该结合用户实际的使用情况，选择负载压力最高的业务功能进行测试，以满足性能测试的需求，达到测试的预期目的。
|
|
|
|
. 选择所需要的操作进行录制。例如，需要测试服务器承受负载压力的性能，某些客户端的操作不会对后台服务器产生负载压力，就可以不录制。比如一些查询操作，选择查询条件的页面可以不录制，但对于一些页面有可能要与后台服务器传递参数，就需要录制了。如何确定哪些操作需要录制，一是可以找开发人员了解清楚程序设计结构和运行模式，二是可以靠自己的经验，熟能生巧当然不会错。
|
|
|
|
由于负载压力测试工具是一种预测系统行为和性能的负载测试工具。它需要模拟成百上千甚至上万的用户同时操作应用系统，实施并发负载及实时性能监测。通常情况下，测试工具模拟多用户并发访问可以有以下两种方式。
|
|
|
|
①进程回放模式：模拟多进程运行方式，即客户端与服务器的访问采用进程方式，每一个虚拟用户通过一个进程建立与服务器的通信连接并访问。
|
|
|
|
②线程回放模式：模拟多线程运行方式，即客户端与服务器的访问采用线程方式，每一个虚拟用户通过一个线程建立与服务器的通信连接并访问。
|
|
|
|
不论测试工具采用的是哪种录制回放模式，其必须经历的几个操作步骤如下。
|
|
|
|
. 协议选择：如前所述，测试工具都是通过获取在各种通信协议下应用系统的客户端与服务器端的通信信息并进一步来实现负载压力测试的，所以首先要确定被测应用系统客户端与服务器端的通信所使用的协议类型。一般而言，B/S系统选择Web（Http/Html），两层C/S系统则根据C/S结构所用到的后台数据库来选择不同的协议，协议的选择请参考有关章节。
|
|
|
|
. 创建测试脚本：选择好相应的录制协议以后，就可以启动脚本录制工具，通过测试工具的代理进程获取应用系统客户端和服务器端的通信信息，测试工具可以自动记录客户端对服务器端的访问操作并自动转换成所需的脚本代码，还可以直接编辑测试脚本以满足各种复杂测试的需求。
|
|
|
|
. 参数化测试数据。对于创建的测试脚本，你可以利用数据池技术对其中的某些数据参数化，从而更好地模拟真实应用访问。以一个订单输入过程为例，参数化操作可将记录中的常量数据，如订单号和客户名称，由变值来代替，以更好地模拟多个实际用户的操作行为。
|
|
|
|
. 创建虚拟用户，设定负载方案：由于负载压力测试的目的就是要模拟多用户并发访问应用系统，所以在开始测试之前就应该设计好需要模拟的虚拟用户数，然后使用测试工具控制台设定负载方案。
|
|
|
|
. 执行测试：设定了相应的负载测试方案后，就可以开始测试了，测试过程中，测试工具会自动记录测试结果，包括事务处理的响应时间，服务器的资源占用情况等。
|
|
|
|
. 结果分析：测试结束后，测试工具会收集汇总所有的测试数据并生成测试结果报告，这些数据主要包括交易性能数据（如响应时间等）、服务器资源占用情况、网路设备和数据库的实时性能数据等。通过这些数据就可以从客户端、服务器端以及网络三方面来评估系统组件的运行性能，从而定位应用系统存在的主要问题，为系统改进做准备。
|
|
|
