业务优化科技
概述
近年来，在应用测试领域有了突飞猛进的发展。随着当今应用复杂性的不断提升、竞争压力的不断加大，以及在应用失败和宕机方面的成本激增，使得对测试的需求不断攀升。
实施高质量应用的压力持续加大，其挑战在于日益紧缩的开发和部署进度、分散的机构组织、外包、技术熟练员工的高调动率，这些都造成了应用测试难度的提升。
为了实现以较少资源完成更多任务的目标、同时展开多个项目、管理多元化和分布式的项目团队，许多机构正采用测试管理方法论和自动化测试管理工具来帮助机构集中、管理、优先级和归档他们的测试工作。
目录
概述
测试管理的需要
什么是测试管理？
是正确实施还是实施过度？——测试管理的主要原因
测试管理流程
需求管理
规划测试
运行测试
管理问题
美科利质量中心
基于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的全球测试管理
