高级测试管理的工具和技术
业务优化科技
概述
近年来，在应用测试领域有了突飞猛进的发展。随着当今应用复杂性的不断提升、竞争压力的不断加大，以及在应用失败和宕机方面的成本激增，使得对测试的需求不断攀升。
实施高质量应用的压力持续加大，其挑战在于日益紧缩的开发和部署进度、分散的机构组织、外包、技术熟练员工的高调动率，这些都造成了应用测试难度的提升。
为了实现以较少资源完成更多任务的目标、同时展开多个项目、管理多元化和分布式的项目团队，许多机构正采用测试管理方法论和自动化测试管理工具来帮助机构集中、管理、优先级和归档他们的测试工作。
目录
概述
测试管理的需要
什么是测试管理？
是正确实施还是实施过度？——测试管理的主要原因
测试管理流程
需求管理
规划测试
运行测试
管理问题
美科利质量中心
基于Web的全球测试管理
需求管理
计划测试
运行测试
管理问题
分享美科利质量中心的客户定制分析工具
特点和优势
总结
测试管理的需要
在应用开发过程中，往往临近编程结束才会将测试正式列入考虑的范围。显而易见，这种方式对于高质量的软件要求和紧缩的发布周期来说是苍白无力的。因此，应该立即改变在应用生命周期中展开测试的时间。
随着竞争压力的提升和宕机的高成本，应用测试正在发展成为一种拥有一套独特方法论、架构、组织结构和文档，且具有多个步骤的流程。越来越多的机构在进行应用开发的同时就开始启动测试流程，使测试与项目同步展开。与其它大多数的开发流程一样，测试流程需要一套系统的、有机的管理方式，其中包括：需求定义、规划、设计、执行和分析，这样才能确保测试的覆盖面和统一性，以及测试资产的可重复使用性。
一旦项目需求确定下来，就可以展开测试计划。测试与开发同步进行的好处在于应用设计所用的知识不至于丢失，可以利用在测试战略的设计中。
在项目目标基础上，测试经理可以创建一个测试主计划，使测试团队的其它成员了解测试战略、任务优先级和测试目标。在主计划基础上，测试人员可以定义测试需求，或确定测试目的。需求定义就是确定要测试什么，测试人员面临的目标是什么——如性能目的。一旦需求定义确定之后，测试人员可以着手开发测试步骤，以实现或生效这些需求，并且运行测试。
测试管理的目的就是创建一个中央控制点，使所有的测试小组成员都能使用。这个中央点可以容纳所有的测试资产，并为整个测试流程——从确定测试内容到创建测试、运行场景，直至跟踪缺陷——提供一个清晰的基础库。测试管理方法论还支持测试数据的分析和覆盖面的统计，从而提供应用生命周期中每个点的应用正确性和质量信息。
什么是测试管理？
测试管理是一种管理应用测试资产和成果的方法——其中包括管理测试需求、测试计划、测试文档、测试脚本和测试结果——从而使这些资产和成果易于使用和能被重复使用。测试管理的目的是在较短的时间内实现高质量的应用。完善的组织结构、通力协作和信息共享是测试管理扎根的基础。规划、设计和运行测试需要消耗相当大的工作量，但是当测试人员、开发人员和测试经理等相关人员能够一起来分享这些测试成果；当一个测试人员离开团队，其测试信息能完整地保留下来；当这些测试资产能够在整个应用生命周期被重复使用的话，您就会发现，您所做的这一切都是值得的。
是正确实施还是实施过度？——测试管理的主要原因
尽管很多机构称测试项目管理是一种被普遍接受的实践方式，但是他们并没有一种标准的流程用于组织、管理和归档他们的测试成果。通常，他们将测试作为一种特别的活动来展开，根据不同的项目而改变。
更好、更快、更经济
如果没有遵循一种标准的规划和设计流程将导致测试规划和设计的成果具有不可重复性，因此无法在未来的反复测试中被重复使用。
有些机构认为测试流程很难实施，巩固和维护工作将更为困难，但是如果他们考虑一下大量多余工作所消耗的成本，以及测试资产的意外损失和重复测试所造成的浪费，将会意识到实施标准测试流程的必要性。只有拥有一个中央控制点和一套清晰的、可反复使用的方法论，才能顺利地展开测试项目，利用有限的资源及时实现高质量的应用。
每日构建和冒烟测试
如今在web环境中、在拥有复杂、灵活应用的机构中，每日发布一个新的构建（build），并检测其一致性、功能点和兼容性，这种流程正日益变得普遍。虽然冒烟测试相当简单，但是测试的绝对数量和版本使测试流程不再是一个简单的、易于管理的过程。拥有一套定义完善、有条不紊的测试方法，拥有一个用于存储测试内容、规划和执行结果的中央存储器能使冒烟测试的正确性得到提升，提升日常构建的价值。
管理变更需求
完整的基于需求的测试确保了系统能最终满足用户的需要。理想的情况下，每个需求至少需要测试一次，有些甚至要经过多次测试。但是，由于时间和资源的限制，很难对所有的需求展开全面的测试。因此，测试人员必须对需求进行优先级排序。与应用设计和开发等其它领域一样，需求也要经历多次修订和改变，这在测试中也必须被反映出来。
在应用功能需求测试中，如果没有测试管理流程来展开测试计划，机构也不能跟踪测试案例和需求变更两者间的互动关系的话，就根本无法展开测试设计，从而也无法验证系统是否涵盖了特定的功能点。
全球测试
像其它IT部门一样，测试也正在受到全球化的影响。甚至是那些小公司，其测试团队也分布在全国或全球各地。此外，有些公司为了节约开支，更高效地利用好有才能的测试人员，会转而采用一种外包的测试模式。由分散在各地的公司内部员工和外包人员组成多个开发和测试团队，为同一项目通力协作，这已成为一种普遍模式。
互联网成就了便捷的团队间交流，但是如何确保在一个分布式团队中，成员间不会意外地互相删除文件，或者避免出现处理同一缺陷的可能。这就需要一套定义明晰的测试流程和一种易于使用、团结协作的方式来进行管理，否则，这种地域意义上分布式“虚拟”测试团队的建立只能为公司带来更多的问题，是一种得不偿失的做法。
更多测试、更多项目
有效的测试需要一套系统的流程。当一个测试团队同时处理多个项目的时候，每个项目都有本身的周期和重点，因此测试团队很容易将项目要点忽视。几乎没有一个机构会将某个测试团队只投入到一个项目的开发中。一个测试团队至多只是开发团队的一个组成部分，负责某个特定产品的测试。并且，测试团队要涉及多个功能区域、构建和基线；工作在不同的平台和环境中；需要去验证无数个集成部署。为了确保多个测试案例的顺利展开，测试人员需要一种流程来管理多个项目，确立每个项目的目标。
不仅仅是缺陷跟踪——还要确保业务成果
在某些小型IT企业中，人们还只是把测试看作一种跟踪缺陷行为。当然，发现缺陷确实是测试小组的主要任务，但是，除了记录错误、并将错误移交给R&D团队之外，测试小组更多的工作是流程的测试。当今的测试重点是验证应用的设计和功能点是否满足了业务的需求和用户的需要。为了实现这些目标，一个测试流程需要拥有明确定义的系统说明和应用业务规则。
生命周期的前期
正如之前提到的，在开发末期和实施初期之间的这段时间内开始测试并非明智之举。测试和开发同步进行才能尽早发现问题（这比在上线后发现问题，其问题的解决成本要低10倍之多）。但是，如果在生命周期早期开始测试，测试人员需要一套明确的目的和优先级定义，这样就能更好地理解系统设计、需求和测试的目标。
测试管理流程
无论是什么系统，无论该系统是如何编写的，或无论它在什么平台上运行，其测试管理的主要原理都是相同的。开始是测试需求的收集和归档，接着是设计和开发测试、运行测试——包括手动和自动测试、功能和负载测试——然后是分析应用缺陷。
测试流程不是一个线形的流程，通常由于机构的实际情况和方法论的不同而有所差异。但是，其基础原理却是相同的。在这一章节中，将深入到管理流程的每个阶段中，探讨如何才能有效地管理、归档、优先级和分析一个机构的整体测试工作。
需求管理
制定明确的、全面的测试需求是展开测试流程的良好开端。需求的开发和管理在软件应用的开发和测试过程中扮演着一个关键的角色。毕竟，业务分析人员没法定义需求的话，工程师将无从创建，测试人员也无从测试。
用一个简单的比喻：一个工程队在建造一幢房屋的时候，如果没有事先咨询屋主的意见，没有了解他/她的需求，最后建造完成的房屋将和屋主的愿望大相径庭。不了解需求来建造房屋尚且如此困难，在软件应用的处理上就更为复杂了，因为应用是一种无形资产，它错综复杂且不断地发生着变化。
调查显示，有超过30％的软件项目在临近完工之际却失败了，超过半数的原因是由于需求模糊、用辞不当、定义不明确所造成的。绝大多数情况下，由于忽视了测试需求，导致整个流程的混乱，测试人员只能修复部分可以修复的问题，有些功能点问题只能被遗留下来，无法再被验证。
只有根据系统要求进行测试，才能实现质量目标。虽然在开发阶段对单个组件进行单元测试已经足够了，但是只有根据需求展开整个系统的测试才能确保应用功能的如期运作。在需求类型中，功能和性能需求是测试流程中经常采用的类型。功能需求能协助确认系统的特定功能点，应该直接从开发人员用来创建系统的使用案例中直接获取功能需求。
性能需求包括由项目小组制定的所有性能标准和说明，如交易响应时间或最大用户数量。这些需求——也就是服务水平目标（SLOs）——主要用于确保系统可以承受期望的用户数量，提供良好的用户使用体验。
功能和性能需求被设计用于提供一套清晰、简明且实用的蓝图，使测试小组能以此开发测试案例。大多数的软件测试经理承认，即使在一个简单的系统中，测试也不可能做到面面俱到。要测试每个特性和功能置换（permutation），您可能需要开发上千个甚至是上万个测试案例，这对于处在上市时间压力和其它压力下的测试团队来说，绝对是天方夜谭。基于需求的测试才是帮助您理顺测试工作优先级的唯一途径。
根据对测试任务的成功与否所起的关键性作用，可以将需求分成不同的组。那些对系统核心功能有影响的需求必须展开广泛地测试，而非关键性的需求可以投入较少的测试力度，或者在生命周期的稍晚阶段测试。
例如，如果被测应用是只是一款成熟产品在几处功能变化后的新一轮发布，那么测试的重点就要集中在修改过的或被提高的区域。这些变更通常在开发文档和/或市场推广说明书中有着详细的论述，测试的需求就可以在这些说明中直接获取。
当测试行业意识到以需求为基础的开发和测试的重要性，众企业就相继推出了各款设计用于创建、跟踪和管理应用需求的工具。有些企业的需求工具非常复杂，而有些则提供基本的功能，只设计用于协助创建、存储和记录需求。选择一款合适工具的关键是看它的功能点。大多数机构还在使用文字处理工具或电子表单来跟踪需求。但是，对于那些想要创建一种稳固、灵活、且基于需求的测试流程的机构来说，专门设计用于需求管理的商业工具应该是一种更佳的选择。基于需求的测试能时刻掌握测试的进展——甚至当优先级发生变化、资源紧缺、或测试时间不足时，都能牢牢控制好整个测试工作。基于需求的测试能够根据最终用户的需要来衡量应用质量。
规划测试
即使是较短的测试周期，也要进行全面的测试规划。测试规划和应用设计同步展开确保了测试能够覆盖系统设计运行的每个功能。如果测试规划只在应用生命周期末开始进行，将会遗失很多设计知识，并且测试人员将不得不返回到分析步骤来重做以前的工作。
在测试规划阶段，测试小组确定测试创建标准和指导方针；为测试环境选择硬件和软件；分配角色和任务；制定测试进度；并安排程序来运行、控制和衡量测试流程。
测试计划本身包括测试设计、测试步骤、命名机制和其它测试属性。规划阶段将决定需要运行哪些测试，如何执行这些测试，哪些风险和意外需要列入计划之中。
制定基础规则
测试人员并非需要一些形式化的流程来约束他们，但是定义模糊、缺乏系统性的流程更会造成测试的瓶颈。在此阶段，需要制定一套基础规则，用来测试日志和文档保存、分配小组内部角色、达成测试和缺陷的命名协定，并且根据项目目的定义跟踪流程。
建立测试环境
需要建立一个测试环境来支持所有的测试活动。在测试流程的初期就应把所有具有长期性的问题列入考虑范围。规划阶段要完成硬件和软件的购买、安装网络、设计测试环境，并就实际测试阶段可能出现的问题做好明确的安排。
定义测试过程
在规划阶段，测试人员决定是手动或是自动运行测试。如果是自动测试，测试人员需要了解哪些工具可用于自动化测试，需要运用哪些技术和技能才可以有效地使用这些工具。对许多机构来说，自动化测试已是一种必须，但还有大部分的企业仍然使用手动测试的模式。无论机构使用手动或自动测试，都需要具有一个稳固的测试管理流程。
开发测试设计
测试设计描绘了用于执行一个测试（手动测试案例）所需的一系列步骤，或者是用于支持更为复杂测试所需的一套解题步骤和代码。在测试规划中，测试人员创建每个测试的详细说明，并确定测试需要哪些类型的数据或数据范围。
映射测试数据
需要将测试数据需求映射到测试过程中。测试小组必须了解要取得哪些类型的数据来支持各种测试类型，并知道如何取得或生成这些数据。
设计测试架构
测试架构帮助测试人员了解测试的各个组成部分，协助开发实际的测试。测试架构协助规划数据的依赖性；在不同的测试间映射工作流程；并确定可以在未来测试中重复使用的通用脚本。
交流测试计划
一旦测试案例创建完成，关键是要建立一个主测试计划，并使机构上下——特别是项目主管、开发人员、市场推广人员——了解测试团队所测试的内容是什么。通过这种方式，才能使更多的人了解项目内容，在实际测试开始之前，让他们为项目提供其意见、问题或见解。测试计划还能作为一种基础库，为管理层提供有关测试项目的各类信息。管理层可以查看有序的、详细的计划数据，确认QA机构的运作是合乎专业标准的，确认他们在技术和人力资源方面的投资是物有所值的。
运行测试
在测试设计和开发事宜完成之后，测试小组着手准备运行测试。为了把系统作为一个整体来测试，测试人员需要执行各种类型的测试——功能测试、回归测试、负载测试、单元测试和集成测试——每种测试类型都具有各自的需求、进度和过程。
测试环境在规划阶段都已准备就绪，因此在该阶段，测试人员可以看到所有可用的硬件设备，可以选择不同的机器来运行不同的测试。大多数的应用必须在不同的操作系统、不同的浏览器版本、或不同的配置下展开测试。在测试运行阶段，测试人员可以建立不同的机器组，从而最有效地利用起实验室资源。
安排自动化测试进度是另外一种优化利用实验室资源的方式，可以将多个测试安排在网络中的多台机器上同时运行，从而也节约了测试人员的时间。测试可以在无人监管条件下自动运行，或者在系统处于空闲状态下运行。这样，脚本的反复利用率也得到了提高，也更易维护，因为可以用脚本来创建更多的模块测试，并按照一定的顺利来运作。
有了一种系统的、具有详细说明的流程不仅能对自动测试产生帮助，也能使手动测试运行地更为精确，因为该流程为测试人员提供一套定义明确的过程，使他们了解手动测试的每个步骤中需要具体执行哪些任务。测试人员要为手动和自动测试保留所有测试运行信息，这有助于建立审计线索，跟踪测试和测试运行的历史记录。
创建测试包
在管理多个测试的问题上，有一种较为普遍的方法，就是根据业务流程、环境或特性的不同将测试分组，形成各类测试包。例如，所有设计用于验证登录流程的测试可以归入“登录”测试包中。单个测试（手动和自动测试）都可以分配到测试包中，确保测试覆盖应用的每个功能区域。
制定执行逻辑
为了验证应用功能点和可用性，测试必须逼真模拟最终用户行为。因此，测试执行应该遵循预定义的逻辑，比如，某些特定测试应在其它测试通过、失败或完成之后才能运行。让我们看看以下的例子：一个用户登录系统，输入一个新的订单，接着退出系统。为了模拟这个简单的业务流程，就要按照完全相同的顺序来运行测试：登录、插入订单、退出。执行逻辑规则应该在执行实际测试之前设定完成。
运行手动测试
运行手动测试将会手动接触应用，随后记录真实测试结果和预期结果之间的差异。有些手动测试可能需要经常性地展开，它们是测试过程的重要组成部分，测试人员可以由此来验证某些自动测试无法处理的功能点和状态。
安排运行自动测试
在决定运行自动测试、测试开发完成且被分配到主机之后，测试小组需要创建一个执行进度表。进度安排
能避免在硬件和软件资源的使用上发生冲突——测试可以安排在无人监管的条件下持续运行，或者在系统处于空闲状态下运行。
分析测试运行结果
在测试执行阶段，测试人员将发现如应用缺乏一致性、功能中断、特性遗失等“错误”或“缺陷”。接下来的一步就是查看所有失败的测试，确定造成测试失败的原因何在。如果测试人员确定测试失败是由一个应用缺陷造成的，那么该缺陷必须汇报给缺陷跟踪系统，用于更进一步的调查、修复和重新测试。
管理问题
管理或“跟踪”问题和缺陷是测试流程中的关键组成部分。随着当今系统的复杂性和重要性日益提升，缺陷的严重程度也不断增加。使用一套有效的方法来进行缺陷管理，受益的将不仅仅是测试小组。一个定义明确的方法可以让开发人员、经理、客户支持、QA、甚至是测试用户都能进入一个开放的、易于使用的、功能缺陷跟踪系统，从而为测试流程献计献策。要创建一个好的缺陷报告和问题解决流程，关键在于设定缺陷工作流和分配权限规则。通过这种方式，测试人员可以确定该如何运作一个缺陷周期，谁有权限来启动一个新的缺陷，谁可以将缺陷状态改为修复，在何种条件下可以将缺陷正式关闭。此外，留存整个缺陷生命周期的历史记录和审计线索也是非常重要的一点。
花费一定的时间来记录缺陷和缺陷历史信息将有助于缺陷分析，缩短修复时间，并实现更高的应用质量。
缺陷分析有助于经理来决策应用部署是否能上线。通过分析缺陷数据，测试人员可以对被测应用有简明了解，获知目前的缺陷数量、状态、严重等级、优先级、时段等信息。通过为不同团队成员提供缺陷信息的查看权限，测试人员就能提高机构内部的信息交流水平，让每个人都能对应用的最新状况有相同程度的了解。
达成命名机制协定
要进行有效的缺陷管理，关键在于各个团队间的交流。在汇报机制运作之前，测试小组需要设定基础规则，如定义缺陷的严重等级，确定缺陷报告必须包括哪些信息。例如，许多测试机构将缺陷按照以下标准分类：
l 有待改善/UI
l 不一致
l 功能缺乏
l 系统死机
l 数据丢失
有待改善和不一致的缺陷类型最容易汇报和处理。虽然该类型缺陷对系统使用造成一定的困难，但是他们不会影响系统功能。那些导致功能缺乏的缺陷则要严重得多，需要尽快修复。会造成系统死机或数据丢失的缺陷通常被认为是“致命级”的缺陷，必须尽可能地全面归档记录，在系统上线之前必须得到修复。
建立汇报过程
要创建一个好的缺陷报告，关键在于要提供给开发人员尽可能多的必要信息，使他们能以此再现和修复问题。一个缺陷报告通常包括一段总结和详细的问题说明、版本和系统配置情况、再现问题所需的步骤，以及相关信息，和协助问题说明的附件。
一个缺陷报告不仅要提供有关缺陷的信息，还要包括能促进问题修复所需的所有数据，这一点是非常重要的。
设置权限规定
对测试管理流程的每个步骤来说，必须要有不同的权限设定，在缺陷管理阶段就更应如此。缺陷信息能协助管理层制定“上线/不上线”决策。测试开始之前，测试人员必须决定哪个小组成员有权汇报、启动或再次启动缺陷；哪个成员可以调整缺陷状态；哪个有权决定缺陷已经修复，可以被关闭。
建立流程（Process Flow）
发现缺陷之后，应将其提交给缺陷库。接着开发人员将对其进行检查，决定这个提交问题是否属于真正的缺陷。如果是缺陷，会将其状态设定为“新的”。由于少有开发机构具备足够的资源来修复所有已知的缺陷，因此开发人员或项目经理必须设定缺陷的优先级。如果R&D部门正在全力赶制新版本应用，那项目经理可能决定只修复“致命级”的缺陷，其余缺陷可以保留到发布周期。流程对于责任链的创建来说，是非常关键的，它确定谁负责哪个缺陷，以及缺陷修复的状态。
重复测试修复
对一个已知缺陷进行任何修改或变更，都需要对应用进行再次测试，以验证变更生效，确定该修复不会造成额外的问题和无法预测的“副效应”。
如果在重复测试阶段没有出现缺陷，那么就可以将其状态改变成为“关闭”。如果该问题还是存在，并且/或者缺陷修复产生了额外问题，缺陷将重新启动，再次进入缺陷周期。
分析缺陷
缺陷分析是缺陷跟踪流程中最为关键的组成部分。测试人员可以从中对被测应用有简明了解，获知目前的缺陷数量、状态、严重等级、优先级、时段等信息。在缺陷分析的基础上，管理层能够就应用部署的就绪情况作出正确的决策。
美科利质量中心
测试管理流程是Mercury Quality Center™（美科利质量中心）的核心支持，它是业界首款基于web的测试管理工具，它将整个测试管理流程合并在一个强大的、可扩展的、灵活的解决方案之中。美科利质量中心的四大模块——需求管理、测试规划、测试实验室和缺陷经理——在设计中就时刻考虑到测试流程的因素。这四大模块的紧密集成使测试流程各个阶段的信息流变得更为顺畅。一些增添技术，如Mercury Quality Center Dashboard™（美科利质量中心面板）和Mercury Business Process Testing™（美科利业务流程测试）则提供企业层级的功能点，可满足最复杂的应用测试项目的需要。
美科利质量中心的需求经理将测试案例和测试需求相联系，确保整个测试流程的可跟踪性。
基于web的全球测试管理
美科利质量中心是一款全球测试管理工具。该工具完全基于Web，无论测试小组分散在各个地区或各个机构，它都能为这些小组间的交流和协作提供支持。
在当今机构中，每个测试流程会涉及多个团队——经理、开发人员、客户支持人员、内部和离岸测试小组、以及客户等。仅仅通过一个浏览器，这些团队就能便捷地查看测试信息，实现团队间的紧密协作。此外，美科利质量中心还能够配置用户组，并设定信息权限，限制用户只能查看和其相关的测试和资产信息。这是一个非常出色的功能，特别适用于离岸测试场景。
该款基于web的工具的另一显著优势就是通过即刻更新工具版本或安装新模块，完成所有人员的同步。用户不再需要下线来更新他们的测试管理工具，只要方便地刷新一下浏览器，机构中的其他人员都能自动实现同步操作。
需求管理
美科利质量中心的需求经理将测试案例和测试需求相联系，确保了整个测试流程的可跟踪性。用户从而能方便地了解到测试覆盖了百分之几的应用功能需求，有多少个这样的测试在运行，有多少个已经通过测试或失败了。
开发测试需求需要查阅所有有关被测应用的可用文档，如市场推广和业务需求文档，系统需求说明，以及设计文档。这些文档有助于测试人员全面了解被测应用，从而确定测试范围——包括测试目的、目标和战略。
有了测试目的和目标，QA经理就可以登录到美科利质量中心的需求树型图中，分配各个区域的任务，开始测试需求的开发工作。需求树型图是一种显示机构明确需求的图表状结构，可表现出不同需求间的层级关系。每个树型图中的需求都有详细的说明，如审核状态、优先级、创建数据，以及一些相关的附件。
美科利质量中心的需求经理提供两种方式来联系需求和测试。
测试人员可以根据应用需求自动生成测试。或者如果他们具有一个现成的测试计划，可以直接将需求和与缺陷有关的测试相联系。通过这种方式，测试人员可以全程跟踪他们的测试需要。如果测试需求发生改变，他们可以立即发现哪些测试和缺陷受到影响，谁可以负责解决问题。
测试人员可以在树型图中划分和筛选需求，监控任务的分配情况和需求的进展状况，并生成详细的报告和图表。
在测试流程的任意环节中，美科利质量中心都能帮助测试人员快速创建图表和报告，获取被测应用的确切状态信息。例如，一旦需求创建完成，测试人员可以快速提取信息，了解测试覆盖了百分之几的需求、这些测试处于什么状态、在审核流程中有多少需求被驳回，需要进行修复、以及哪些需求非常紧急，需要尽快得到确认。
在美科利质量中心，所有的筛选结果、报告和图表都能以公开或不公开的方式存为“优选（Favorites）”查看视图。那些以非公开方式存储的优选视图，只能由该保存人员来查看。公开的优选视图则可以由所有小组成员来查看。例如，在每周会议上，一个经理需要某个应用的所有测试需求的最新信息，她只需创建一次报告，并将筛选结果保存为“优选”。今后，美科利质量中心将自动更新此份信息报告，经理将在每周的会议上得到所有需求的最新信息。
美科利质量中心通过提供有关需求变更过程的所有历史信息，为机构保留了一份核查线索。这种方式维护了信息的完整性，确保测试人员可以跟踪需求生命周期中——从创建初期，直至状态、优先级或测试覆盖面等方面——所发生的任何变化
美科利质量中心的测试计划树型图以图表的形式显示了整个机构的测试计划。
规划测试
美科利质量中心的测试计划树型图以图表的形式显示了整个机构的测试计划。它根据不同的主题类型将测试进行划分和归类，并说明必须执行哪些测试以满足事先所定义的质量需求。测试人员还可以将某个测试与一些确定的缺陷相联系。这种方法非常有用，比如，当创建的一个测试是和已知缺陷相关的，通过该方式建立联系，测试人员就可以根据缺陷状态来决定是否要运行这个测试。
美科利质量中心还允许测试人员将测试计划树型图中的每个测试与需求树型图中的某个需求相联系。通过定义测试需求覆盖范围，测试人员可以在测试计划中跟踪测试案例之间的相互关系，并发现它们原有的测试需求。
美科利质量中心帮助测试人员为每个测试建立测试步骤，说明需要执行哪些操作、必须检测哪些区域、以及期望的结果是什么。在步骤制定完成之后，测试人员可以决定用手动还是自动方式来运行测试。
除了支持手动和自动测试之外，美科利质量中心还支持将手动测试转换为自动测试。如果测试人员决定将某个测试实现自动化，美科利质量中心会根据设计步骤，为该类型的自动化测试创建一个模板。测试人员只需要使用一种自动化测试工具（如Mercury WinRunner®或Mercury QuickTest Professional™）来记录业务流程，就能完成测试。
在进入测试执行阶段前，关键是要审核测试计划，查看该计划是否能完全地满足先前所定义的测试目的。测试人员可以生成定制化的报告和图表，从而分析测试计划。例如，他们可以创建一个报告来显示测试计划树型图中每个测试的设计步骤数据。根据此份报告，测试人员决定测试设计的优先级。
测试人员可以将这份包含报告和图表的测试规划视图存为“优选”项，以确保该信息随时可用。
如果机构已经用Microsoft Word或Excel等文字处理工具保存过类似的规划信息，测试人员也可以使用此信息，并将其导入美科利质量中心，这样就能保留原有的投入，避免重复的计划工作。此外，美科利质量中心允许测试人员创建附件来为某个测试增添信息－如设计文档或特性说明等。
在美科利质量中心内，测试可以在网络中任意一台可用机器上运行，无论它在本地还是远程。
运行测试
美科利质量中心的测试实验室帮助测试小组管理不同测试类型的测试进度和运行状况。为了系统安排测试运行，美科利质量中心支持一种“测试包”的概念。一个测试包是位于项目数据库中的一组测试，设计用于实现特定的测试目的。测试包可能包括实现某个功能点而展开的所有测试，如验证特定功能点（如登录流程），或是验证应用在特定浏览器版本上运行等。有了美科利质量中心，测试人员可以直接从计划树型图中将测试拖放至测试包中。
测试人员还能从计划树型图中筛选测试，将符合特定标准的所有测试导入一个测试包中。
此外，测试人员可以制定一套执行条件，控制某个测试包中的自动化测试的执行。他们可以为执行自动化测试设定条件、日期和时间，以及设定测试执行的顺序。
例如，验证一个简单的业务流程：用户登录系统，下了一个订单，输入付款信息，随后退出系统。对此，可以创建四个模块测试：“登录”、“下订单”、“付款”、“退出”。测试人员可以根据实际的业务流程，将四个测试依次排序，先是“登录”，接着就是“下订单”、“付款”和“退出”。测试人员还可以定义执行条件。在这个例子中，“下订单”测试只能设在“登录”测试通过之后运行。另一方面，“退出”测试无论之前的测试通过与否，都可以运行。因此，测试人员可以设定在“付款”完成后运行“退出”，无论“付款”测试的结果是什么。
在美科利质量中心内，测试可以在网络中任意一台可用机器上运行，无论它在本地还是远程。通过主机经理（Host Manager），测试人员可以定义哪些机器可以运行测试，并将其分组。分组可以依照任务类型（功能或负载测试）、操作系统（Windows或UNIX）、浏览器类型和版本（Netscape或Internet Explorer），以及其它规格或配置。
美科利质量中心可以和其它的美科利应用实施产品实现紧密地集成。通过开放的API完成配置后，质量中心就可以运行由第三方测试工具展开的测试。测试人员可以安排自动测试在无人监管的条件下运行，或是持续运行，或是在测试实验室机器空闲状态下运行。使用这种进度安排机制，该工具就能作为一种自动化测试工具来运行测试，并将报告结果返回至中央存储器。
管理问题
有关问题或缺陷的信息对测试人员来说都是至关重要的，他们必须由此来确定应用的状况，决定应用是否做好了部署准备。美科利质量中心的缺陷经理是一个用于登录、跟踪、管理和分析应用缺陷的完整系统。它允许不同类型的用户——测试人员、项目经理、开发人员、测试用户等——直接将缺陷输入到数据库中，
从而协助展开测试流程。
美科利质量中心的缺陷经理是一个用于登录、跟踪、管理和分析应用缺陷的完整系统。
一个有效的缺陷跟踪流程必须以有序的工作流程和权限规定为扎根的基础。测试人员可以定义缺陷在其生命周期中——从最初的发现问题，到解决问题，直至验证修复——的确切进展，还可以设置权限规定，为机构成员建立使用权限。
机构可以使用多种定制选项，为其测试流程选择创建最为适合的工作流规则。例如，缺陷在生命周期中必须以“新的”状态为开始。没有QA经理的第一轮审核，缺陷是不能被关闭的，随后它将被移交至R&D。R&D小组成员既可以驳回缺陷，也可以对问题进行修复并将问题状态改为“已修复”。项目经理接着审核修复情况，并将状态改为“关闭”，该缺陷才能真正关闭。测试人员通过为各类小组成员设定工作流和权限规则，从而对美科利质量中心进行配置，使其能反映出机构的流程图和需求。
共享美科利质量中心的客户定制分析工具
根据个人在机构中的角色定位，他/她可能被限制查看缺陷跟踪流程中的某些记录。例如，开发小组中的一些成员可能无权查看缺陷，但是某些授权的成员则可以。同样的，有权限进入缺陷数据库的测试用户也不能查看任何缺陷的“目标修复数据”。
和其它模块中使用附件形式一样，测试人员也可以为缺陷添加附件信息，如说明文档或被测应用的截图，从而协助对问题的阐述。为了进一步帮助R&D小组，测试人员可以附加如内存、操作系统、或颜色设定等系统组件方面的信息。这些数据以文本文件的形式附加至缺陷中，协助问题的说明并加速问题解决。
缺陷跟踪流程中的筛选结果、报告、图表和优选项都可以用于评估应用是否做好了部署准备。测试人员发现的缺陷是否多于他们修复的缺陷？分配给开发人员的缺陷数量是否过多，以至于他们超负荷工作？目前版本中的缺陷数量是否多于前次版本？这些信息都可以通过使用客户定制分析工具来找到，还能在机构上下实现共享。
特点和优势
支持整个测试流程：美科利质量中心将测试流程的所有方面——需求管理、规划、进度安排、运行测试、问题管理和项目状态分析——都归入一个基于浏览器的应用中。
随时随地使用测试资产：使用基于web的界面，测试人员、开发人员和业务开发人员可以跨地域、跨机构实现协作，共同服务于测试流程。
提供整个测试流程的可跟踪性：美科利质量中心提供需求和测试案例之间、测试案例和问题之间有机链接，确保整个测试周期的可跟踪性。当需求发生改变，或者缺陷被修复时，测试人员可以收到变化的通知。
集成第三方应用：无论测试人员使用的是行业标准的配置管理解决方案、Microsoft Office、或是自行开发的缺陷管理工具，美科利质量中心都能实现集成。通过一个开放的API，美科利质量中心能保护用户对现有解决方案的投资，并协作用户创建一种端到端应用生命周期管理的解决方案。
管理手动和自动测试：美科利质量中心提供并运行手动和自动化的测试，并通过将手动测试转换成自动化测试脚本，协助用户实现项目自动化的飞跃。
加快测试周期：美科利质量中心的Test Lab Manager通过自动安排测试进度和运行测试，加快了测试执行的周期。测试结果汇报到中央存储器中，用于精确的审计分析。
促进形成统一、可重复的测试流程：美科利质量中心通过为所有的测试资产提供一个中央存储器，推动形成了一种更为统一的测试流程。该流程可以在整个应用生命周期、或在多个应用或业务部门中被反复使用。
提供分析和决策支持工具：美科利质量中心的集成图表和报告工具能协助分析应用在测试流程的任意点上的就绪情况。测试经理使用有关需求覆盖面、规划进展、运行进度或缺陷统计等方面的信息，可以就应用否能上线做出正确的决策。
总结
每个机构的应用测试流程都是独特唯一的。但是，许多测试小组遵循的测试方法论却是相似的，其中包括确定功能需求、创建测试计划、运行测试和跟踪应用缺陷。
这种测试方法需要一种强大的工具来促进测试小组间的交流和协作，同时加强测试流程的结构和框架。美科利公司的质量中心首次提出了全球测试管理的理念，通过将基于需求管理的测试计划、测试进度安排、测试执行和缺陷跟踪集成在单一的、基于web的应用中，推动了测试流程的合理化和发展。