WinRunner™是一种企业级的功能测试工具，用于检验企业应用程序是否能如期进行。通过自动捕获、检测和重放用户的交互操作，WinRunner能够发现系统缺陷，并确保那些跨越多个应用程序和数据库的业务流程在初次发布就避免故障的出现，并且保持其长期稳定地运行。您的公司的程序开发员刚创建完成一个新的Web应用程序，然而在布署应用程序之前，您必须测试该程序，以确保其正常运行，不会产生错误，但这并非是您唯一需要检测的对象，因为人事部门刚刚升级他们的erp系统，而你的客户不再加一个CRM程序，所以问题就是如何有效的测试不断变化着的多重应用程序，而且这些应用程序存在于您的企业内部的不同环境之下--其实该问题也同样困扰着许多其他的公司。 如果资源有限的话，这个问题就比较棘手。人工测试的工作量大，况且您负担不起额外的时间来培训新的测试人员。为了确保那些复杂的应用程序在不同的环境下都可以可靠的运行，您需要一个易操作的测试工具来自动完成功能测试。MercuryInteractive的WinRunner软件为企业提供一个强大的功能测试工具。通过捕获、检测和重放用户对您企业Web应用程序的互动操作，WinRunner可自动执行功能测试。您因此可以辨认错误，确保应用程序顺利部署，并且能够安排和执行测试。一旦测试计划建立后，TestDirector的TestLabManager为测试日程制订提供一个基于Web的框架。他的SmartScheduler™根据测试计划中创立的指标对运行着的测试计划中创立的指标对运行着的测试执行监控。当网络上任何一台主机空闲，测试能够彻夜执行于其上，SmartScheduler能自动分辨是系统还是应用错误，然后将测试重新安排到网络上的其他机器。 TestDirector，对于不断改变的Web应用，经常性地执行测试是至关重要的，能够追查出错发生的环节并评估应用质量，然而，这些测试运行都要消耗测试资源和测试时间。使用GraphicDesigner图表设计，您可很快的将测试分类以满足不同的测试目的，如功能测试，负载测试，完整性测试等，他的拖动功能可简化设计和排列在多个机器上运行的测试，最终根据设定好的时间、路径或其他测试的成功和否，为序列测试制订执行日程。SmartScheduler能让您在更短的时间内，在更少的机器上完成更多的测试。用Winrunner®、Astra®、QuickTest™、AstraLoadTest或LoadRunner来自运动运行功能或负载测试，无论成功和否，测试信息都会被自动汇集传送到TestDirector的数据储存中央。同样，人工测试也以次方式运行。当测试完成后，项目经理必须解读这些测试数据，并将这些信息用于工作中。当有出错发现时，他们还要指定相关人员及时纠正。TestDirector的错误管理功能直接贯穿并作用于检测的全过程，以提供管理系统终端--终端的出错跟踪包括，从最初的问题发现到修改错误再到检验修改结果。由于同一项目组中的成员经常分布于不同的地方，TestDirector基于浏览器的特征，使出错管理能让多个用户何时何地都可通过Web查询出错跟踪情况。利用出错管理，测试人员只需要进入一个URL，就能够汇报何更新错误。过滤整理错误列表并作出趋势分析。再进入一个出错案例之前，测试人员还能够自动执行一次错误数据库搜寻确是否已有类似的案例记录，这已查寻功能能够避免重复劳动。测试过程的最后一步时分析测试结果，确定应用程式是否已部署成功或需要再次测试。TestDirector常规化的图表和报告和再测试的任何的任一环节帮助你对数据信息进行分析。TestDirector还以标准的HTML或Word形式提供一种生成和发送正式测试报告的一种简单方式。测试分析数据还能够简便地输入到一种工业标准化的报告工具，如Excel，Reportsmith，Crystal，Reports和其他类型的第三方工具。应用测试工具最广为人知的就是自动化工具，它们尝试来取代人力 ——让电脑完成点击并检查。测试自动化最常见的类型就是用户界面驱动的，用户记录一系列操作及其预期结果。用户界面自动化的两大常见类型是记录/回放这里一个工具记录下交互操作并且随后将这些操作自动化，期望得到相同的结果—并且是关键词驱动的—这里用户界面的元素。关键词驱动的测试通常在某个编程语言里创建，但是不一定非得如此；可以在电子表格里记录元素标识符，命令，输入和预期结果。持续集成工具就是支持类工具，可以检测到新代码的check-in，从而开始构建build，创建一个新的虚拟Web服务器—或者更新某个staging服务器—将新代码交付到目标机器上，运行自动化来测试程序，检查结果并且用邮件将失败信息发送给相关团队。对于很简单的软件而言，可以使用便利贴或者电子表格来跟踪bug报告。但是当软件更为复杂时，这就会变得很难用，公司就需要使用为解决此类问题而设计的专业软件。通常来说，专业的bug跟踪工具会报告bug的严重程度，优先级，发现问题的时间，确切的重现步骤，修复问题的人，问题在哪个build上被修复，以及提供搜索和标签的机制来帮助使用者找到某个defect。这些工具不仅仅能够帮助编程人员和项目经理；客户服务和已有用户也可以使用这些工具来查找某个问题是不是已知问题，是否已经计划修复，升级某个已知问题，并且汇报非已知问题。Bug跟踪工具也能够有助于工作流，因为可以将bug分配给编程人员，然后给测试人员重新检查，然后标记为待部署，并且在部署之后，标记为已部署。当我们讨论软件测试领域的覆盖率时，我们实际在探讨两个领域的问题。第一个领域是代码覆盖率，关注于被测试覆盖的软件的代码百分比。代码覆盖率最常见的类型是statement覆盖率，它是在测试流程运行过的statement的百分比——手动测试，自动测试或者两者。第二个领域是应用程序覆盖率，从另外的维度查看测试流程——通常是，被“覆盖”的需求百分比。常见的应用程序覆盖率工具之一是一个可跟踪的矩阵——一个列表，列出哪些测试覆盖了哪些需求。通常来说，测试用例管理软件记录了所有计划的测试，并且允许测试人员为某个给定版本将某个测试用例标记成“已执行”，这使得管理层可以了解多少百分比的测试已经“被覆盖”了。这是一种“质量保证”，检查测试流程，和管理控制一起来确保应用程序的每个部分都被覆盖了。 [1]