《系统测试续一》word版.doc

系统测试续一8.8.4系统测试设计在系统测试需求确定后，可以开始测试设计工作。而测试设计又是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个系统过程的测试质量。因此，为了保证系统测试质量，必须在测试设计阶段就对系统进行严密的测试设计。测试设计一般的流程是：首先理解软件和测试目标，然后设计测试用例，接着运行测试用例并处理测试结果，最后评估测试用例和测试策略。在确定测试设计流程时既强调目的性也强调计划性，目标是追求测试的高效率和测试的理想结果。当然，水能载舟，亦能覆舟。文档化和按部就班可以降低管理难度，增强计划性，但也可能扼杀测试人员的经验作用和灵感。1.理解软件和测试目标目的：建立软件故障模型，了解测试目标，来确定测试策略和测试计划。任务：了解软件的功能和业务背景、用户环境，了解软件的开发背景和系统结构、技术选型，了解软件的质量历史、版本变化，了解系统的测试目标和资源限制，确定测试策略和测试计划。方法：阅读软件使用手册，理解软件运行环境和用户行为，了解同类软件的功能和使用，了解软件要解决的问题域和解域(业务背景知识)；试运行软件，从中熟悉软件功能，确定软件基本可以测试；了解软件体系结构、技术选型、开发环境和工具；阅读早期版本测试报告，以及单元测试和集成测试报告；确定测试人员限制和时间限制，制定初步测试策略和测试计划，确定测试结束标准。结果：1)建立错误模型，指导回答该软件可能的错误会出现在哪里(用户环境与测试环境不一致会不会出问题，没有测试过的代码或功能里面会不会出问题，没有测试过的输入组合、极端环境或功能使用方法、使用顺序等会不会出问题)，如何做才能发现这些错误等问题.。2)在了解测试目标和资源限制之后，按照错误的性能价格比制定设计测试用例的优先级，并确定初步的测试策略和测试计划。3)确定测试结束标准或测试退出机制(已经解决的错误没有重现，所有缺陷报告已经关闭，所有测试用例全部执行完毕，通过错误播种、错误发生曲线分析、历史数据等相应方法统计出所遗留的未发现错误数量可以被接受，以及不属于技术层面且实际表明测试失败或者部分失败的市场和管理因素、预算和时间用完等因素)。2.设计测试用例目的：设计尽可能多、快、好、省发现错误的测试用例(即能够找到尽可能多的、以至于所有的BUG；能够尽可能快或早地发现最严重的BUG；找到的BUG是关键的、用户最关心的，且找到BUG后能够重现找到的BUG，并为修正BUG提供尽可能多的信息；能够用最少的时间、人力和资源发现BUG，且测试的过程和数据可以重用)。任务：理解故障模型、理解现有的测试用例库、设计具体的测试用例。方法：采用基于故障模型如经验、历史数据/错误、软件开发和运行环境的软件攻击法(这需要创造性思维，而且要注意保证满足测试多、快、好、省的要求，并要有以孙子兵法进行指导的战役思想，当然还要记住没有银弹的教诲)。结果：测试用例(IE4.0的测试用例数目：10万)。测试用例没有标准文档格式，对于特殊人或在特殊情况下可以在运行后再形成文档。测试用例文档由简介和测试用例两部分组成：简介部分描述了测试目的、测试范围、定义术语、参考文档、概述等；测试用例部分逐一列出各测试用例(包含的要素为标题和编号、版本号、修改记录等，针对目标和假设前提/可能发现的错误，输入和数据/代码，测试步骤，预期输出和错误发现方法)。表8-3是一个简单的测试用例设计表格。表8-3测试用例设计表测试用例ID输入预期结果实际结果测试统计利率贷款期限(年)贷款金额(元)月支付总支付总利息月支付总支付总利息通过/失败测试日期测试人员TC-001 8%30 80000 578.01 TC-002 8.5%30 80000 615.13 TC-003 8.5%15 80000 787.79 3.运行测试用例并处理测试结果目的：使用测试用例发现错误并关闭错误。任务：运行测试用例并记录结果，评估测试结果并记录缺陷，处理缺陷直至缺陷关闭(即修改、延迟处理、不修改、不是错误)。方法：选择测试用例库中的测试用例运行，选择新设计的测试用例运行，录制/回放或者笔录中间步骤和结果，记录下执行过程中的灵感(但不要轻易修改本次执行任务)，分析测试结果并尽量重现和优化错误步骤，详细填写缺陷报告并提供尽可能多的信息(如尽可能提供错误分析和修改建议)，认真审核错误处理结果并及时关闭缺陷报告。结果：记录下的运行结果，记录下的新的测试用例设计思路，提交并处理的缺陷报告。4.评估测试用例和测试策略目的：检验测试用例和测试策略的有效性，必要时对测试用例和测试策略进行完善和修改，增加测试经验。任务：根据测试结果完善、修改、合并测试用例，如果没有文档化测试用例，此时需要文档化；另外，对测试用例库进行维护。即增加新的测试用例(尤其是已经发现了错误的测试用例)，删除不必要的测试用例(要谨慎，除非是功能改变)，修改刚刚使用的测试用例(根据测试结果)，合并部分测试用例；最后，根据测试结果完善和修正测试策略和测试计划、产生新的测试用例设计思路。方法：基于经验(发现了什么问题，这种问题出现的原因是什么，为什么会发现这种问题，还可以更快地发现吗?测试用例可以合并吗?可能联想到还会出现什么问题-新的测试用例)，流程控制/尤其是测试用例库的维护可以借助于工具实现。结果：优化的测试用例库，优化的软件故障模型，优化的测试策略和测试计划，测试的经验和新的测试用例设计思路。事实上，测试设计过程是循环往复的、并且过程中的每一步骤都可以返回前面的任何一个步骤，即使单独一个测试用例也可能经过以上步骤多次。另外，测试设计最重要的工作就是设计测试用例。测试用例的衡量标准：多、快、好、省。测试用例库是一种经验积累，是测试活动最宝贵的财富。最后，在系统测试中设计测试用例的最常用到的思路是软件攻击。8.8.5系统测试中的软件攻击测试如同打仗，孙子兵法中的知己知彼、百战不殆；攻其薄弱、避其锋芒；分而治之、逐个歼灭作战策略在软件测试，特别是软件的系统测试中是非常具有指导意义的。作战的最主要手段就是进攻或攻击。软件测试中的攻击-软件攻击就是要寻找系统中最容易出现错误的地方进行测试(如寻找开发过程中容易出现疏忽的地方)，保证多快好省地找出错误。软件攻击的核心是基于故障模型的测试用例设计。1.软件故障模型故障模型是将测试员的经验和直觉尽量归纳和固化，使得可以重复使用。测试员通过理解软件在做什么，来猜测可能出错的地方，并应用故障模型有目的地使它暴露错误。可以认为故障模型类似于系统设计中的定式(Pattern)思想，具体的攻击方法就是一个一个的定式。因此，对测试员来说，首先是要能够构造出一个准确的故障模型，然后使用该故障模型来决定测试策略、测试设计和测试用例运行。在建立故障模型时，希望故障模型在框架上是通用的，但是建立具体的故障模型时一定要针对具体的软件类型、应用环境、甚至开发工具才有意义。在进行故障模型设计时，要重点考虑软件的行为特性。如，软件功能和技术特点(包括输入、输出、数据以及处理等)，软件操作环境(用户界面、文件系统、操作系统环境以及其他软件及操作系统API等)。按照这种思路设计的故障模型是一个二维模型，该模型从软件功能和技术特点来说，只接受正确的输入并正确地处理，只输出用户接受的并且正确的输出，保持数据结构的完整性(数值、精度和位置)和自我保护的合法的计算、功能交互和数据共享；而从软件操作环境来说：关注用户界面，关注文件系统接口、数据库系统接口，关注资源调配和管理，以及关注系统API调用。2.典型攻击方法基于上述软件行为特性的分析，和故障模型设计的考虑，重点关注一些典型的攻击方法。这些攻击方法从4个方面进行考虑：首先是何时施加攻击(Where)，即软件在实现什么功能的时候适合使用这种攻击，这种攻击针对的功能是什么；其次是什么样的软件故障会使攻击成功(Why)，即本攻击方法主要会暴露实现过程中哪方面的问题，在实现技术上是什么原因产生了这种错误；然后是如何确定攻击暴露了失效(What)，即本攻击方法成功的标志是什么?需要掌握业务背景知识，或者说理解什么是预期的输出结果；最后是如何进行攻击(How)，即本攻击方法的操作步骤。下面就25种典型攻击方法(Pattern)为例来进行攻击方法的说明。1)用户接口输入攻击6种320使用非法输入：所有非法输入是否有错误处理代码，代码是否正确。321攻击使用默认值的输入：变量是否初始化了。322使用特殊字符集和数据类型的合法输入：是否正确处理了特殊字符和数据类型。323使用使缓冲区溢出的合法输入：是否检查字符串/缓冲区的边界了。324使用可能产生错误的合法输入组合：是否考虑了输入之间的组合关系。325重复输入相同的合法输入序列：是否考虑了循环处理的边界。2)用户接口输出攻击4种326产生同一个输入的各种可能输出：一个正确的输入在不同情况下产生不同的输出，这些不同情况是否都考虑充分。327强制产生不符合业务背景知识的无效的输出：开发人员是否了解解域/业务背景知识，是否会产生不符合业务背景的输出。328强制通过输出修改一些属性：初始化代码和修改代码是否同步。329检查屏幕刷新：屏幕刷新时机是否正确，屏幕刷新区域计算是否正确。3)用户接口数据攻击3种330制造使内部数据与输入的组合不相容的情况：处理输入的时候，是否考虑到内部数据的各种可能的组合。331制造使已有内部数据结构集合溢出的情况：上溢-增加一个元素到集合中，下溢-删除集合中最后一个元素，或者从空集合中删除元素。332制造使已有内部数据结构不符合约束的情况：初始化代码和修改代码是否同步。4)用户接口计算攻击4种333使用非法的操作数和操作符组合，攻击用户可以控制计算要求的情况：是否考虑到操作符和计算要求的合法性。334使函数递归调用自身：是否考虑到循环/递归的中止。335使计算结果溢出：考虑数据结构是否能够正确存储可能的计算结果。336攻击共享数据或互相依赖的功能计算：一个函数在修改共享数据的时候是否考虑到其他函数对这个共享数据的访问。5)文件系统介质攻击3种337使文件系统超载：检查文件访问函数的返回值，是否正确处理文件访问失败的情况。338使介质处于忙或者不可用状态：检查文件/介质访问函数的返回值，是否正确处理文件/介质访问失败的情况。339损坏介质(这时候OS可能认为介质可用)：检查文件/介质访问函数的返回值，是否正确处理文件/介质访问失败的情况。6)文件系统文件攻击3种340使用特殊字符/特殊长度/无效的文件名：处理文件名的代码是否考虑到各种情况。341改变文件访问权限：访问文件的函数是否考虑到文件访问权限；文件访问失败，是否有正确处理错误的代码。342使文件内容错误，并让系统使用这个文件：是否检查文件访问函数的返回值，错误处理代码是否正确。7)操作系统和软件接口攻击2种343记录-仿真攻击：模拟操作系统和操作环境故障，并记录软件对该故障的反应。软件是否正确处理内存故障/网络故障等操作系统和软件接口故障。344观察-失效攻击：观察底层API调用，并动态修改API调用，制造错误。软件是否正确处理操作系统和软件API调用错误的情况。本攻击方法一般用于对可靠性和稳定性要求非常高的软件。上述攻击中的许多要用到软件攻击工具，如：文件系统介质攻击，文件系统文件攻击，操作系统和软件接口攻击等。否则，攻击成本太高-例如物理毁坏介质；工作量太大-例如使用大文件填充硬盘、使用多任务抢占CPU/网络/内存等资源；有一些不容易实现-例如动态监控和修改API调用。一般采用软件故障植入的方法设计软件攻击工具。3.软件故障植入一般软件中的程序代码分为功能代码(通过实现用户需求来完成软件任务)和异常代码(通过异常或者其他错误处理机制来处理程序错误)，故障植入的目标是强制执行异常代码(没有异常代码也是一种错误)，从而发现其中的错误。故障植入方法分为编译期植入(在源代码中插入引发故障现象的代码)和运行期植入(在目标代码或运行环境中植入引发故障现象的代码)两类。而运行期软件故障植入具有更大的优势：(1)不需要源代码，因为系统测试阶段经常没有源代码。(2)可以达到模拟环境故障的目标，比如：网络中断、网络繁忙、内存匮乏等。(3)可以以API调用失败的方式模拟故障，因为在程序看来，任何环境故障实质上都是一系列的API调用失败。(4)可以只影响被植入的程序，因为使用的是模拟API调用失败方式。运行期软件故障植入可通过截获API的方式来实现。例如：基于调用源截获，找出程序中调用API的名字或DLL，然后用自己的函数替换掉；路径内截获，如果程序中使用VTable等技术间接记录调用API地址，则直接修改VTable中的API地址，用自己的函数替换掉；目的地截获，修改被调用API地址，修改头部代码，转向自己的函数，这实际上采用的是病毒方式。运行期软件故障植入的实现策略有两种：1)基于模式的故障植入：模拟环境故障，记录故障特征和影响到的API，修改影响到的API；采用乱棒打师傅方式的软件攻击法-canned HEAT(Hostile Enviroment Application Tester)，并记录下由此引起的故障产生情况。2)基于调用的故障植入：观察使用的API，并独立地、细粒度地修改影响任何一个API；采用偷梁换柱、李代桃僵的方式进行软件攻击，并观察其破坏性而引起的失效攻击。8.8.6系统测试中的典型测试类型介绍1.错误处理测试健壮性是软件质量的一个重要因素。错误处理测试是检查软件在面对错误时，是否进行了正确的处理。错误处理测试的目的是要发现软件是否做了用户不期望的事情、发现软件在发生异常的时候是否有能力进行处理。此时，测试人员需要以否定的态度来思考问题。另外，在错误处理测试中发现的部分问题可能不会被修复。错误处理测试主要考虑典型的异常情况：如用户输入非法数据(不输入数据、输入无效数字数据，如负数和字母数字串、输入任何被认为是非法的数据类型格式、尝试不常用的数据组合、确保使用零值、输入超过或者短于要求长度的数据)，在系统不支持的平台上运行，网络连接异常，数据文件(或者数据库)被破坏，数据文件(数据库)中有混乱的数据，计算机断电后启动，在用户界面上违反操作步骤的操作等。2.内存泄露测试内存泄漏是一种典型的程序缺陷，导致应用程序不断消耗系统内存(或虚拟存储器)，使程序运行出现响应变慢、某些功能无法实现、甚至整个系统瘫痪等问题。尤其对于嵌入式系统这种资源比较匮乏、应用非常广泛，而且往往又处于重要部位的程序，内存泄漏将可能导致无法预料的重大损失。在某些语言(如C/C+语言)编写的程序中，内存泄露是一个极其普遍的问题。内存泄露测试可采用静态测试和动态测试技术，通过测量内存使用情况，可以了解程序内存分配的真实情况，发现对内存的不正常使用，在问题出现前发现征兆，在系统崩溃前发现内存泄露错误；发现内存分配错误，并精确显示发生错误时的上下文情况，指出发生错误的原因。MI Compuware公司的BoundChecker，IBM Rational的Purify就是一种典型的内存泄露检查工具。3.用户界面测试图形用户界面测试和评估的重点是正确性、易用性和视觉效果，界面中的文字检查和拼写检查也是用户界面测试的重要环节。用户界面测试的过程中，有时要依赖于测试人员的主观判断，但用户界面测试也要遵循一些基本原则，如：易用性、规范性、合理性、美观与协调性、菜单位置、独特性、快捷方式的组合、排错性考虑等。表8-4给出了界面测试的一些基本考虑。4.性能测试性能测试包括并发性能测试、强度测试、破坏性测试等。并发性能测试是评估系统交易或业务在渐增式并发情况下处理瓶颈以及能够接收业务的性能过程；强度测试是在资源受限的情况下，找出因资源不足或资源竞争而导致的错误；破坏性测试重点关注超出系统正常负荷若干倍的情况下，错误出现状态和出现比率以及错误的恢复能力。性能测试可以通过黑盒测试或者白盒测试方法来进行，一般要借助工具。如IBM Rational Performance Tester、Compuware QALoad以及HP Loadrunner等。在进行性能测试时，要求：测试程序在获得定量结果时程序计算的精确性；测试程序在有速度要求时完成功能的时间；测试程序完成功能所能处理的数据量；测试程序各部分的协调性，如高速、低速操作的协调；测试软/硬件中哪些因素限制了程序的性能；测试程序的负载潜力；测试程序运行占用空间。性能测试应用场合有：软件中某个模块涉及到复杂的计算，特别是一些基于人工智能的分析；涉及到大量数据的读写、通信；涉及到数据检索，而被检索的数据具有很大的数据量；具有多个并发用户；软件在运行时，可用资源(特别是CPU和内存)可能在某些情况下很紧张。例如一些嵌入式系统软件。5.压力测试压力测试也叫负荷测试，即获取系统能正常运行的极限状态，如表8-5所示。压力测试用于检查软件在面对大数据量时是否可以正常运行。大数据量，往往是发生概率比较小的情况。压力测试所涉及的方面主要包括：数据库大小、磁盘空间、可用内存空间、数据通信量。表8-4界面测试指标指标检查项测试人员评价合适性和正确性用户界面是否与软件的功能相融洽是否所有界面元素的文字和状态都正确无误容易理解对于常用的功能，用户是否不必阅读手册就能使用是否所有界面元素提供(例如图标)都不会让人误解是否所有界面元素都提供了充分而必要的提示界面结构是否能够清晰地反映工作流程用户是否容易知道自己在界面中的位置，不会迷失方向是否有联机帮助及时反馈信息是否提供进度条、动画等反应正在进行的比较耗时间的过程是否为重要的操作返回必要的结果信息出错处理是否对重要的输入数据进行校验执行有风险的操作时，是否有确认、放弃等提示是否根据用户的权限自动屏蔽某些功能是否提供Undo功能用以撤销不期望的操作(续表)指标检查项测试人员评价风格一致同类的界面元素是否有相同的视感和相同的操作方式字体是否一致是否符合广大用户使用同类软件的习惯适应各种水平的用户所有界面元素都具备充分必要的键盘操作和鼠标操作初学者和专家是否都有合适的方式操作这个界面色盲或者色弱的用户是否能正常使用该界面国际化是否使用国际通行的图标和语言度量单位、日期格式、人的名字等是否符合国际惯例合理布局和谐色彩界面的布局是否符合软件的功能逻辑界面元素是否在水平或者垂直方向对齐界面元素的尺寸是否合理?行、列的间距是否保持一致是否恰当地利用窗体和空间的空白，以及分割线条窗口切换、移动、改变大小时，是否界面正常界面的色调是否让人感到和谐、满意重要的对象是否用醒目的色彩表示色彩使用是否符合行业的习惯个性化是否具有与众不同的、让用户记忆深刻的界面设计是否在具备必要的一致性的前提下突出个性化设计表8-5压力测试模版极限名称A如最大并发用户数量前提条件输入/动作输出/响应是否能正常运行如10个用户并发操作如100个用户并发操作6.回归测试回归测试是指对某些已经被测试过的内容进行重新测试，如软件增加新功能后影响软件的结构，软件修改考虑不周而引入问题。回归测试策略：测试人员可以按照实际情况选择回归策略，如每两周需要进行一次完整的回归测试；当修复的缺陷数量累计到50个时，进行一次完整的回归测试；在产品递交用户前5个工作日，进行完整的回归测试。回归测试通常可以使用自动化测试工具。8.8.7系统测试工具举例目前用于系统测试的主流测试工具主要有以下4类：1.负载压力测试工具这类测试工具的主要目的是度量应用系统的可扩展性和性能，是一种预测系统行为和性能的自动化测试工具。在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所发现问题对系统性能进行优化，确保应用的成功部署。负载压力测试工具能够对整个企业架构进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。1)LoadRunner特点a，支持的协议多且个别协议支持的版本比较高；特点b，负载压力测试方案设置灵活；特点c，丰富的资源监控；特点d，报告可以导出到Word、Excel以及HTML格式。2)QALoad测试接口多，可预测系统性能，通过重复测试寻找瓶颈问题，从控制中心管理全局负载测试，可验证应用的扩展性，快速创建仿真的负载测试，性能价格比较高。此外，QALoad不单单测试Web应用，还可以测试一些后台的东西，比如SQL Server等。只要它支持的协议，都可以测试。3)Benchmark Factory首先它可以测试服务器群集的性能；其次可以实施基准测试；最后可以生成高级脚本。4)E-Test Suite：由Empirix公司开发的测试软件，能够与被测试应用软件无缝结合的Web应用测试工具。工具包含e-Tester、e-Load和e-Monitor，这三种工具分别对应功能测试、压力测试以及应用监控，每一部分功能相互独立，测试过程又可彼此协同。5)JMeter是一个专门为服务器负载测试而设计、100%的纯Java桌面运行程序。早期它是为Web/HTTP测试而设计的，但是它已经扩展，以支持各种各样的测试模块。它和HTTP和SQL(使用JDBC)的模块一起运行。它可以用来测试服务器运行情况，可以用来模拟服务器或网络系统在重负载下的运行情况。它也提供了一个可替换的界面用来定制数据显示，测试同步及测试的创建和执行。6)WAS是Microsoft提供的免费的Web负载压力测试工具，应用广泛。WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器和Modem速度，它的功能和性能可以与数万美元的产品媲美。7)ACT或称MSACT它是微软的Visual Studio和Visual S自带的一套进行程序压力测试的工具。ACT不但可以记录程序运行的详细数据参数，用图表显示程序运行情况，而且安装和使用都比较简单，结果阅读也很方便，是一套较理想的测试工具。8)OpenSTA它的全称是Open System Testing Architecture。OpenST的特点是可以模拟很多用户来访问需要测试的网站，它是一个功能强大、自定义设置功能完备的软件。但是，这些设置大部分需要通过script来完成，因此在真正使用这个软件之前，必须学习好它的script编写。如果需要完成很复杂的功能，script的要求还比较高。当然这也是它的优点，一些程序员不会在意编写script的。9)PureLoad一个完全基于Java的测试工具，它的script代码完全使用XML。所以，编写script很简单。它的测试包含文字和图形并可以输出为HTML文件。由于是基于Java的软件，因此PureLoad可以通过Java Beans API来增强软件功能。10)网站压力(负载)测试工具Webserver Stress Tool可以模拟任何人数在同一时间内进站或是迅速进站时Server的反应表现。只要输入网站的URL网址以及模拟的上站人数，就可以看出Server在这种压力测试下的评比，用条状图明白地表示出Server反应时间、传递速率等相关数据。除了Http的网页外，还支持CGI或ASP等语言撰写的程序。支持Proxy设定、密码输入、Cookies与ASP的Session-IDs等功能。2.功能测试工具通过自动录制、检测和回放用户的应用操作，将被测系统的输出记录同预先给定的标准结果比较，功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进行测试，提高测试人员的工作效率和质量。其主要目的是检测应用程序是否能够达到预期的功能并正常运行。1)WinRunner WinRunner是企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行，自动执行重复任务并优化测试工作，从而缩短测试时间。通过自动录制、检测和回放用户的应用操作，从而提高测试效率。2)QARun QARun是一款自动回归测试工具，与Winrunner相比较学习成本要低很多。不过要安装QARun必须安装.net环境，另外它还提供与TestTrack Pro的集成。3)IBM Rational Robot IBM Rational Robot是人们经常使用的测试工具，属于IBM Rational TestSuite中的一员，对于Visual studio 6编写的程序支持得非常好，同时还支持Java Applet、HTML、Oracle Forms、People Tools应用程序。要支持Delphi程序的测试还必须下载插件。IBM Rational Robot的语法使用Basic语法，它的语言使用SQABasic。4)Functional Tester Functional Tester是IBM Rational Robot的Java实现版本，在Rational被IBM收购后发布的。在Java的浪潮下，Robot被移植到了Eclipse平台，并完全支持Java和.net。可以使用VB.net和Java进行脚本的编写。由于支持Java，使得用测试脚本进行测试也成为了可能。更多的信息请到IBM developerworks上查看，另外还提供试用版本下载。5)QuickTest Professional QuickTest Professional是一个B/S系统的自动化功能测试的利器，软件程序测试工具。Mercury的自动化功能测试软件(现已被HP收购)，可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。是一款先进的自动化测试解决方案，用于创建功能测试和回归测试。它自动捕获、验证和重放用户的交互行为，为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。6)SilkTest SilkTest是面向Web应用、Java应用和传统的C/S应用，进行自动化的功能测试和回归测试的工具。它提供了用于测试的创建和定制的工作流设置、测试计划和管理、直接的数据库访问及校验等功能，使用户能够高效率地进行软件自动化测试。为提高测试效率，SilkTest提供多种手段来提高测试的自动化程度，包括：从测试脚本的生成、测试数据的组织、测试过程的自动化、测试结