测试团队工作计划篇（1）

・ 测试数据的规划和创建

・ 项目的客户化定制

质量团队人员情况和技能水平

列出的机构规划形式是一种灵活的模式，可以被各种规模和各种资源类型的机构所采用，能够成功地推动美科利质量中心的部署和运作。

组件团队

为了最大化资源利用，有效使用现有的技术产品，关键是要组建一支团队来支持美科利质量中心的部署。在项目初期，选用合适的人员将加快规划和调查步骤，在流程中尽早发现潜在的实施阻碍。

表二所示的是组成一个子团队的人员说明，其中包括个体的功能、所需的技术能力、必要的知识，以及在整个流程中团队成员所要承担的具体职责。一个完整的列表必须覆盖团队中所有成员的详细说明，在美科利质量中心的部署过程中，每个职位应具有详细说明。

具有相当技能的人员的选择是以项目运作的规模和范围为基础的，同时能和新的质量管理流程实现统一。成功的美科利质量中心的实施需要受过培训的用户的参与。尽管正规的用户培训只需要一天的时间，但是，建议另外采用大约为期大约一周、在实际工作中展开的指导（on-the-job mentoring）服务。这样就能最终建立起一种交流计划，使团队在面临任何可能的问题时，都可以与美科利质量中心的核心力量取得联系。

其它有关机构规划方面的主题，如：何时才是团队扩展的最佳时机，什么是美科利团队与其它IT、业务团队的最佳结合点，如何将知识传递到每个开发团队中去，这些问题都包括在美科利质量中心的工作中。

测试数据的规划和创建

管理测试数据是系统、环境和测试管理流程的一个重要组成部分。建议组建一支团队去开发一套数据服务，并在项目生命周期的关键点上完成服务实施。这些服务能确保测试数据得到合理的规划和实施。此外，所有主要的项目干系人应该召开数据审核会议，检查服务情况，并提出反馈意见。

以下所列的是一些服务和流程，是为提供高质量的支持服务而展开的。

・ 测试数据的规划

在软件开发生命周期中，第一次需要涉及测试数据规划工作是发生在设计完成阶段。

当项目需求或变更请求最终确定，用于每次项目时，测试数据管理团队将完成一份用于的测试数据计划。该文件是在管理将所有事宜进行打包之后才创建完成的。测试数据计划和其里程碑需要和管理的时间进度和里程碑保持统一。

测试数据计划应包含来自所有项目干系人的输出信息，这样测试数据管理团队就能协调和促进必要的、和数据相关活动的展开，协助实现一次成功的。此外，测试数据计划的重点应放在规划，以及明确测试数据管理团队所需要付出的工作量上。测试和开发团队应该和测试数据管理团队合作完成测试数据计划。测试数据计划包括以下信息（但不仅仅限于如下信息）：

・需支持的测试阶段

・的范围

・测试数据管理团队的工作

・项目、测试阶段和环境的保障和里程碑

・资源和流程的确认，用于创建测试数据

・数据更新和/或数据恢复方面的需求。

一旦测试数据计划文件完成，应提交给测试执行机构审核通过。

・ 创建数据

根据测试计划中制定的需求，测试数据管理团队负责为测试机构提供测试数据。测试数据管理团队在测试执行阶段之前提供测试数据。

提供和管理测试数据的最有效、最实际的方式就是使用正规化的数据流程和工具。为了确保成功，测试数据管理团队会执行无数次的测试数据准备流程，如数据的重复使用、数据合并、数据恢复和数据共享。

测试数据管理团队将和DBAs和系统支持管理员一起，根据特定的数据需求，用各种不同的方式，推动数据的创建。

其中一种是将数据从生产或其它环境中复制到目标测试环境的方式，这是在其它环境中发现符合需求的数据时所采用的。第二种采用的方式就是手动输入数据的方式，是在其它环境中没有发现数据时所采用的方式。 其它可行的方式包括使用数据生成工具，如Usage Generator；恢复存储在数据存储器中的数据；修改环境中的现有数据来满足新的数据需要。尽管测试脚本是由测试机构来创建的，但是测试数据管理团队可以提供测试数据，作为对脚本的输入信息。

如果在开始测试之前，需要对现有方案进行修改，测试数据管理团队将负责该方案中数据方面的改动。任何作为测试环节的一部分而做的数据修改属于执行团队的职责范围。

其它有关系统、环境、和数据管理流程方面的信息都是美科利质量中心工作的组成部分。

项目的客户定制

美科利质量中心为特定的项目提供广泛的、项目客户定制方面的灵活性。仔细地规划客户定制是非常重要的一个方面。随着可用的用户空间愈来愈多，用户可以增加Memo空间，可以创建输入模式，使用户能够定制他们的美科利质量中心项目，从而获取测试流程所需的任何数据。

美科利质量中心管理员增加和定制空间，创建分类和表单来反映特定测试项目的需要，满足测试团队的特定需要。管理员可以通过以下方式来修改美科利质量中心空间的行为：

・限制用户仅仅从相关表单中选择值。

・强制从特定空间进入

・保留输入到特定空间内的值记录。

・通过创建用户空间来获取您项目的独有数据。

・将这些空间和美科利质量中心和用户定义表单结合起来。

管理员可以定制和增加其它空间，用于相关质量指标的收集。通过使用下拉表单和自动填写功能，数据质量得到了提升。验证所需的信息，用于评估应用的就绪状况，以及测试、开发和其它相关IT流程的进展情况。正确定制美科利质量中心可以帮助您管理好各类应用测试工作。

・ 推荐的空间客户定制

以下所推荐的空间客户定制选项和美科利质量中心所支持和影响的主要IT流程相关：

・需求管理：通过创建定制空间可以将不同类型的需求区分开来。这些空间可以显示出一个特定需求是否和规模、系统、性能、业务流程优先级、业务关键性等因素有关。如，需求变更的成本方面的考虑也可以通过定制空间来体现。

・变更管理：需求变更请求可以通过定制空间――指出请求的当前状态（新的/未决的/取消的）――从而展开跟踪和管理。其它定制空间可以在流程之后跟踪变更请求数量。

・配置管理：使用定制空间来监测每个模块在测试计划树状图（test plan tree）中被发现的配置错误数量。

・应用开发：为了获取更全面的成本和资源信息，应该建立定制空间来估算测试开发时间，并预测预期开发时间和实际时间之间的差异。

・质量保证：跟踪适用于测试项目的特定缺陷标准，创建定制空间

・管理：创建定制空间，在每个之前跟踪版本信息，或在某些情况下跟踪将执行的缺陷版本或提高版本的数量。

・生产管理：通过定制空间来跟踪回复时间，从而发现性能和可用性问题。

・问题汇报和管理：通过定制空间来监测调优或更新之后所产生的问题，指出问题的数量、根源和修复成本。成本空间可以选择性地对一些项目规划人、经理或QA分析人员开放。

空间定制的模式

测试团队工作计划篇（2）

软件开发团队的质量意识不断提升，团队对测试的重视与依赖程度也逐步提高。软件质量是各种特性的复杂组合，软件测试是软件质量保证的一个重要环节，通过软件测试来验证软件是否满足了需求，验证产品是否满足内部质量和外部质量。

复杂的项目和有限的工期，要求测试人员用更短的时间、更高的效率进行软件测试。测试人员组成的团队，需要有效而明确的管理。软件测试管理是一种活动，可以对各阶段的测试计划、测试用例、测试流程、测试文档等进行跟踪、管理并记录其结果。随着软件产品的迅速发展，软件复杂度逐渐提升，这给软件测试带来了更多挑战，测试的组织与执行成为软件工程的重要部分。

借助工具，可以使测试管理可视化，协助测试顺利进行。在IT企业的软件测试团队中，结合软件测试理论与方法，适当选择工具软件，可以促进企业工作规范化，提升团队工作效率，让多人协作完成复杂测试工作成为一项管理清晰、目标明确的系统工程。

1 Quality Center简介

Quality Center是HP（惠普）公司的软件测试管理产品，该产品前身是Mercury Iteractive（美科利）公司的Test Director，后被惠普公司收购，正式命名为HP Quality Center（后文简称QC）。QC是一个基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。此外，通过Quality Center还可以创建报告和图来监控测试流程。

QC功能比较丰富，善用QC可以完成复杂的测试管理工作。相比其他过程管理与缺陷管理软件，QC是一个“重量级”的软件帮手。介于使用成本的限制，更适合于企业级应用。在系统测试的组织与管理方面，更显优势。

2 使用QC管理系统测试

QC软件模块较多，本文从最实用模块入手，主要包含版本管理、测试需求、测试版本管理、测试用例、测试执行与缺陷管理六个方面，完成整个测试过程的监控、管理与执行。下文将通过图文描述，展示具体的操作过程与方法。该测试方法的解决方案经过实际系统测试工作的检验，是一种有效的测试管理手段。

2.1 权限管理――自定义中的“组”

测试管理的主体是“测试人员”，测试人员在测试团队中有不同的分工，测试经理、测试用例设计人员、测试用例执行人员各司其职。根据项目复杂度的区别，人员配置会有不同。

测试经理的职责是制定测试计划和进度并及时反馈、建立与维护测试基线、团队成员能力了解与工作安排等[4]；测试用例设计人员应掌握项目的具体细节和操作流程，设计出合理用例。在实际工作中，存在着人员复用情况。管理与设计人员需要拥有操作QC的较高权限。测试执行人员根据设计的用例进行执行，对整个测试需求、用例的修改需要较为慎重，所拥有的权限应较低。可以根据实际项目的人员分工设施操作权限。

设置权限的方法如下，管理员账号登陆，点击右上方“工具”--“自定义”，出现权限管理界面。点击“组”，可以建立或修改权限分类。点击“项目用户”，可以添加、编辑和删除用户，并确定测试人员所属的组。

2.2 测试需求――QC中“需求”模块

项目需求不同于测试需求，不能够指导实际的测试工作。而如何将项目需求转化为测试需求，考验着每一个测试经理的工作能力。使用QC，可以清晰地梳理测试需求，是需求处理工作的得力助手。

QC支持以树状结构建立需求，并为每一个需求分配ID。实际测试过程中，可以将“需求”模块用作测试需求的梳理，结合整体需求文档建立所需要测试的需求。每个功能需求均须有测试需求对应，根据实际情况，功能需求可能需要对应多个测试需求来进行测试。

2.3 测试版本――QC中“版本”模块

测试工作非一蹴而就，测试需求与用例都可能存在多个版本。可以在QC的“版本”模块建立相应的测试版本。版本名可以根据项目具体需要确定。在版本的下一级建立循环以表明测试的轮次，可以在每一轮次中，记录本轮次的开始日期和结束日期。

这里提供一些实用技巧：

当系统测试只涉及一个基线时，可以使用“轮次_基线”来命名测试轮次当系统测试包含几个基线时，可以使用“轮次”作为测试轮次名，在详细信息中写明所有系统的基线。在“详细信息”中写明所有系统的基线。

可以在每一轮次中，记录本轮次的开始日期和结束日期。

建议使用“系统名_模块名_基线日期”来规范基线名称。

2.4 测试用例设计――QC中“测试计划”模块

用例编写是测试工作的核心任务之一。

测试计划中包含所编写的所用用例，并可以控制用例的版本。介于QC的测试实验室部分展示不方便，所以实际的执行结果，也会体现在测试计划之中。

2.4.1 从“需求”导出“测试计划”中的用例

“需求”模块可以直接转换为测试计划中的用例或者文件夹，右键点击要转换的需求，选择“转换为测试..”，之后会弹出对话框，可以根据需求粒度，来选择转换方式。可以将最底层子需求转换为设计步骤、测试或主题。当需求较复杂，未拆分到具体步骤时，建议选择的是“将底层的子要求转换为测试”。转换后，测试计划中，就会生成与需求对应的测试主题，根据具体需求可以增减主题，调整目录结构，设计具体的测试用例。

2.4.2 关联用例与需求

设计用例时，可以让用例与需求关联，这样可以清晰显示测试需求的覆盖度与完成度。在每个用例中，点击“需求覆盖”，然后点击“选择需求”，右侧会出现具体的需求，选择相应需求则可以将此需求关联到用例中。

2.4.3 用例设计

具体到每一个用例，可以分为“步骤名称”“描述”和“预期结果”三个部分。不同项目对此三个模块的应用方式不同。以某具体项目为例，定义用例编写规范如下：

步骤名称：以步骤编号开头，并简要描述步骤执行的意义

描述：此步骤执行的具体方法，根据此描述，可以指导测试的输入

预期结果：这部分填写实际测试结果，记录真实的测试情况

2.4.4 保存每一轮次的用例

QC的测试实验室模块对测试结果的保存有待优化，所以，在非自动化执行的测试中，建议项目选用测试计划模块保存用例结果。值得注意的是，如果选择在测试计划中呈现具体的执行结果，即将“预期结果”填写为实际执行结果时，一定要注意：对于多轮测试时要复制测试计划中的用例，并单独与轮次关联和命名。

2.4.5 测试执行――QC中“测试实验室”模块

QC设计测试实验室模块是希望用此模块来记录实际测试的执行情况。但因为展现不清晰，所以，实际测试结果记录在了测试计划的“预期结果”中。这部分内容可以根据项目具体调整。此外，测试实验室还有以下作用：管理每一轮测试所执行的用例，监控本轮次用例状态、测试进度，以及分派测试任务。

测试实验室可以根据测试计划，来建立测试用例集。通常，测试计划的树状结构和测试实验室的树状结构是一致的，测试计划中最底层文件夹，对应测试计划中的一个测试集。当然，也可以建立一个测试集，将测试计划中所有的用例放置在一个测试集中，并分配测试给相关测试人员。具体建立测试集的方法如下：根据测试建立测试文件夹，在测试文件夹下建立测试集，并使用“选择测试”将测试计划中的测试用例拖入相应测试集中，分配测试给相关测试人员。

在测试过程中根据测试用例的实际执行情况，由测试人员将测试用例的状态置为：

测试未执行，状态为“No Run”

测试正在执行，状态为“Not Completed”

测试执行完成并通过，状态为“Pass”

测试失败，状态为“Failed”

2.5 缺陷管理――QC中“缺陷”模块

使用工具管理缺陷，可以清晰地向开发人员反馈问题，记录问题沟通和修改状况，是测试历史过程的重要参考。

缺陷由测试人员根据实际情况填写，进入“缺陷”模块，点击“新建缺陷”，并根据提示填写“摘要”、“测试版本”、“测试轮次”、“测试日期”、“测试者”、“模块”、“缺陷状态”、“严重程度”、“原因分类”以及“描述”，并将缺陷与引发此缺陷的测试用例关联起来。在笔者工作过程中发现，缺陷的描述越清晰对开发人员定位问题越有帮助。

一个完整的缺陷描述应包含以下元素：

测试数据：运行该测试用例时建立的数据，如指令内容、输入字符串等。

测试步骤：执行该测试用例的操作过程。如果是前台程序，需要详细描述打开界面的title、录入的内容、点击的按钮等；如果是后台程序，需要详细描述测试环境（服务器、环境变量）运行的指令、SQL语句等。

期望结果：根据需求确定该测试用例的预期。

实际结果：测试用例执行后的真实结果 试用例执行后的真实结果，可以用文本形式或截图形式来展现。

3 结论

QC工具拥有自身的一些特点，会给测试工作带来一定影响。通过企业级项目测试的应用，发觉QC最大的优点是使得工作分配与测试用例完成情况可视化，并可以清晰地梳理测试用例等。而同样有QC带来的缺点，最显著的缺点是网页反应慢，操作耗时长，贴图不方便，内容导出困难等。

在笔者工作的测试团队中，同样一个项目的测试人员来自不同的部门，甚至所属不同城市。这时，测试的管理是非常棘手的问题。多人合作的项目测试，使用QC管理带来的好处完全弥补了它的不足。使用QC进行系统测试的维护和管理，能够达到降低沟通成本、明确任务划分、实时反馈测试问题的良好效果。

参考文献

[1]苏秦，何进，张涑贤.软件过程质量管理[M].北京：科学出版社，2008.

[2]吴慧韫，李卓群.基于H 模型的软件测试管理应用模型研究[J].计算机工程与设计.2006，27（11）：1993-1995.

[3]Black.R，龚波.软件测试过程管理[M].北京：及其工业出版社，2003.10：1-53.

测试团队工作计划篇（3）

敏捷体验设计的开始其实并不简单。市场与销售部门、业务部门和技术部门之间很可能因为产品开发与交付的问题而纠缠不清。敏捷体验设计就是想实现快速而有效的创新。敏捷体验设计包括的协作设计(Collaborative Design)与快速启动(Inception)是成功实现软件交付的关键。

协作式设计通过紧凑、高互动的方式进行,以求用合理的技术和运营成本提供让消费者满意的体验,交付可验证的用户价值。协作式设计有如下特点:包括大量可视化设计过程,由集中的高协作性的工作坊完成设计,面向设计过程而非过程的产物,尽可能晚地使用高保真的设计工具,尽可能地缩短反馈周期。协作设计本身是软件交付团队快速进入迭代式用户测试和交付设计的基础。

快速启动是将设计变成合理交付计划的实践集合。通过快速启动,开发者一般用一两周的时间就可以制定出一份合理的交付计划,其中包括优先级、产品演进地图以及拆分的用户故事。快速启动除了具有轻流程、重交互的特点之外,最重要的是可以帮助一支小规模的设计团队在最短时间内制定出交付计划。

交付:重体验而非功能

当一个软件交付项目的开始时间从以前的数个月缩短到一两周时,软件开发团队就可以快速地进入软件编码阶段,但新的挑战也随之产生。由于没有进行过大规模的提前设计,产品设计在交付过程中必须不断进行调整和改进,其驱动因素包括以下两方面:第一,新的需求导致功能的变化,原有的信息架构或交互模式已经不能满足需求;第二,原有的需求也许因为市场变化或用户的及时反馈而产生变化,原有的设计需要进行修正。

一个适应性设计(Adaptive Design)需要持续不断且频繁的重构。在敏捷体验设计中,设计全功能团队和迭代式用户测试能够保证设计重构的顺利进行。

设计全功能团队 对于软件来说,最重要的是应用体验而非功能。敏捷体验设计尝试建立一个融合的交付团队。在这个团队里,无论是程序员、设计师、需求分析人员或测试人员,都更加关注产品的最终用户体验,而非功能实现。所谓设计全功能团队,就是团队中的每个成员或多或少都具备一定的体验设计能力,可以在不同细节上对产品设计提出自己的意见,对产品的用户价值和体验设计有全局性的了解。敏捷体验设计倡导的实践包括以下几方面:鼓励设计师与程序员结对工作;对设计师和程序员进行前端编程技巧的培训;将设计引入日常需求讨论,例如将典型用户建模中的人物作为基础;制定体验设计的规则,例如基础信息架构、页面命名规则、视觉规范等;增强测试人员对产品体验的理解,除了在产品的功能性上进行质量把控以外,还要针对产品体验提出合理的改进建议;将协作式设计的方法引入到产品交付过程中。

迭代式用户测试 用户测试的核心目标是获取用户对产品体验的真实反馈,并在尽量减少工作量的情况下验证设计的正确性。很多时候,用户测试都放在产品上线前的某个阶段,而在敏捷体验设计中,用户测试则越早越好。迭代式用户测试应遵循以下几项原则:只测试最多拥有两个迭代交付的设计;在得到测试结果后,还应找出新的问题,以便在下一个测试迭代中进行改进和二次验证;在无法获得真实的用户体验数据之前,应保证测试的节奏,并可选择性地对未来的重大设计进行测试;尽可能真实地模拟使用场景。

演进:满足所有客户需求

测试团队工作计划篇（4）

从需求规划、需求分析到需求设计的过程，都可以归类为产品的设计过程，这中间现在有很多细分，诸如市场调研、竞品分析、交互设计等，其本质都是产品设计，并在最终可以形成一份产出物《产品需求设计说明书》，以提供给开发和测试人员去实现产品。瀑布型开发模式要求需求必须先全部梳理清楚，才会投入开发资源，这样的好处是需求完整，可以从整体上把握产品；而敏捷模式下的产品设计，也需要从整体上规划产品，但会拆分成若干个相互间较为独立的部分，分别实现，最后又能整合成为一个完整的产品，这就对产品设计人员提出了更高的要求。

通常情况下，当我们接到一部分产品的需求之后，会按业务优先级来做分析，并将相互关联的需求放在一起，或者是按优先级高低进行分类，这个过程将需求进行了划分，可以依据这个划分来决定哪些需求是要先做的，哪些是可以后做的。不过这里有一个问题需要注意，那就是什么样的需求适合拆分，一般有以下几种类型：

第一，各需求功能之间较为独立的适合拆分。一个产品有十个功能点，各个功能点之间相互依赖关系不强的，松耦合的，就可以每个功能点单独抽取出来做设计；

第二，需求功能本身的逻辑遵循某种操作流程的适合拆分。功能的实现是按照一个较为固定的流程一步一步往下走的，这样可以将每一个步骤单独拆分开来设计；

第三，产品上线之后的版本维护适合拆分。上线之后，对一些BUG、问题、小需求的缝缝补补，都适合用敏捷的方式来设计；

第四，产品上线后的新增需求适合拆分。新增需求一般都针对某个功能模块来进行设计，相对来说较为独立，因此也适合敏捷设计。

拆分后的需求会分别写PRD，最后合成一份。敏捷开发模式中把需求都称为Backlog，维护Backlog表就是一个对产品需求进行拆分的过程，拆分完成后再根据迭代计划来设计具体的实现。一般有名称、优先级、工作量估算、描述、备注信息等几个维度，实例如图表所示。

通常都把Backlog存放在共享的Excel文档里面，以便团队成员都可以随时查看。一般来说这个文档归产品经理维护，但也并不把其他团队成员排斥在外。开发人员和测试人员常常要查阅这个文档或者修改工作量估算。需要注意的是，描述Backlog的时候只需说明要达到什么结果即可，而不能说如何去达到。

产品的敏捷开发

需求Backlog清单都列出来了之后，开发人员需要根据排定的需求优先级，从需求池当中选出需求排到当前的迭代中，直到所有需求的估算工作量加起来达到迭代周期的工作量为止，一般会留一小部分时间来做为缓冲。开发人员集体估算每个需求的工作量并维护到上述的Backlog列表中，这些都是在敏捷的迭代计划会上完成的。通常一个迭代都是通过计划会议来开始的。

接下来是确定Backlog是否还需要拆分，即判定是否可以在一个迭代内完成，或者是否可以在一天内完成，敏捷开发模式可以建立详细的考核机制，每天都跟踪之前一天的任务是否已经完成。开发人员拆分Backlog出来的结果就是一条条的Task，然后开发人员根据各自的任务来编写《产品系统设计说明书》，最后汇总。

这里涉及到工时估算的问题，一般的估算方法都是让团队中不同级别的成员对某个Backlog进行估时，并取某个中间值或者团队都可接受的值为最终的估算工时。一般拆分的依据如下：

1、 每个拆分出来的Task都是可单独验证并上线的；

2、 每个拆分出来的Task都是可以在单个迭代内完成的；

每日站会可以跟踪需求实现的进度，检查每天的工作进展是否按照迭代计划在进行，永远确保资源投入在高优先级的Backlog上；该完成而未完成的任务有哪些以及是什么原因？及时识别出对迭代中后续问题的影响，并根据风险和应急方案努力规避；遇到的问题应该由谁来负责解决以及何时必须解决，否则会影响后续计划中哪些条目？尤其是那些有前后依赖关系的条目；开发过程中会出现对原有需求的进一步细化，可能会和迭代计划时讨论的结论有一些差异，那么变更的内容是否会对既定的业务需求产生调整？

需求变更一般发生在计划会议之后，既定的Backlog尽可能保持稳定。但是需求变更是很难避免的，若业务或者技术发生变化时，敏捷团队该如何响应呢？一般从需求的紧急程度来考虑，紧急的需要团队内部开发讨论，如果能在缓冲时间内完成的就完成掉，如果不能则需要从已安排的任务当中挪出一部分到下个迭代。

产品的敏捷测试

有人说敏捷测试是顺应敏捷开发方法，是力求达到质量和效率平衡的一系列测试实践，其实并不是一定要敏捷开发了才敏捷测试，其他开发模式下也可以采用敏捷测试。敏捷测试只是测试的一种，强调从用户的角度，即从使用系统的用户的角度来测试系统。重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

所以在敏捷开发模式下，开发人员不是等整个迭代的任务都开发完了才送测，而是做完一个送测一个。前面也讲到Backlog拆解成Task时要求每个Task都是可以单独验证的，也就是说每个Task都是可以单独测试的，这样测试人员可以对每个已开发完成的Task进行测试，及时发现问题，及时改进。这种模式下，效率高的话可以精确控制到每天的开发结果验证，这样可以确保产品需求都是按照计划来进行的，并且不会偏离需求本身。

测试团队工作计划篇（5）

中图分类号：TP31 文献标识码：A 文章编号：1674-098X（2014）09（a）-0255-01

随着社会的发展，行业竞争的加剧，原有的螺旋和RUP模型已无法适应企业快速的需求变化。为了解决这个问题，我们引入了敏捷开发和敏捷测试的概念，该文主要阐述了敏捷方法及如何在企业中实施敏捷测试。

1 敏捷开发的概念和构成

1.1 敏捷开发的概念

敏捷开发是一种以人为核心，迭代、循环渐进的开发方法。在敏捷开发中，软件项目的构建被切成多个项目，各个子项目的成果都经过测试，具备集成和可以运行的特征。

1.2 敏捷开发的构成

Scrum是一个敏捷开发框架，是一个增量的，迭代的开发过程。在这个框架中，整个开发周期包括若干个小的迭代周期，每个小的迭代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品Backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。

Scrum的开发团队总是先开发对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析，讨论和估算，得到一个Sprint的任务列表，我们称它为Sprint Backlog。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。

2 敏捷测试开发的特征、原则、及框架

敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保及时最终产品。

敏捷测试特征：敏捷测试的成员需要有自发组织能力，敏捷测试需要编写需求备份列表。

敏捷测试原则：敏捷测试的原则是确保所交付的软件满足客户的需求。

敏捷测试的框架：敏捷测试框架主要包括3个角色，5个会议，3个产物，两个过程控制物。三个角色：敏捷测试管理中，角色分为三种，测试经理，测试组长，测试工程师。

3 敏捷测试的管理职责及五个会议

3.1 测试职责

确定测试需求，将测试任务分解成多个task并分发给测试组长。与客户沟通并确定测试优先级。每个Sprint，根据需求调整测试策略及优先级。接受或拒绝测试团队的工作成果；参与Scrumplanning；为项目盈利能力负责。

测试组长职责：保证资源完全被利用并全部是高产出；保证各个角色及职责的良好协作；解决测试过程中的障碍；作为测试团队与外部的接口，屏蔽外界对团队成员的干扰；保证测试过程按计划进行；组织DailyScrum、Sprint Review和Sprint PlanningMeeting。

测试工程师职责：评估工作量，拆分工作量并定义任务，评估资源利用率及工作时间，确保测试质量；改进测试流程。

3.2 敏捷测试的五个会议

（1）Product backlog估算会议：确定具体的测试需求，确定做还是不做。（2）评估storypointSprint计划会议：确定Sprint目标和每日立会的时间地点。任务拆分，工作量和point合计调整。（3）每日站立会：收集障碍，领取或分配任务，更新任务版和燃尽图。（4） Sprint评审会议：向客户提交测试成果并以之创建或变更backlog。（5）Sprint回顾会议：吸取经验教训，改进迭代过程，重点是改进团队和组织的工作流程。

4 敏捷测试的输出

敏捷测试的输出的三个产物：

Product Backlog，Sprint Backlog，

work software；两个过程控制物：燃尽图，障碍backlog。

5 案例分析

目的：为企业提供高效的测试服务，满足企业快速发展的需求。

解决方案：采用敏捷测试方法（图1）。

首先，测试经理将与客户一起参加 Sprint meeting并获取客户的测试需求，然后记录Product Backlog，其中包括待办事项，测试任务的优先级，测试周期等。然后测试经理将测试任务分发给测试组长并记录 Sprint Backlog。其中包括待办事项，测试任务的优先级，测试周期，测试计划等。确定测试任务后测试组长再与测试工程师进行开会讨论，安排测试资源、测试策略、测试周期、每日站立会时间地点。测试工程师明确测试任务后，开始开展测试工作。每天测试组长和测试经理会利用10分钟的每日站立会收集测试障碍信息，测试进度等信息并在Sprint Backlog中记录这些信息。测试任务完成后，向客户提交测试结果。测试结束后测试相关人员要吸取经验教训，改进测试流程。

6 结语

随着敏捷开发Scrum的广泛应用，敏捷测试也并将成为测试领域的发展趋势。我们也可以从敏捷测试中寻找到更多的发展机遇，为企业的快速发展和需求提供更好的解决方法，更好的为企业服务。

参考文献

[1] 王璇.敏捷测试理论与实践[J].软件导刊，2009（1）：38-39.

测试团队工作计划篇（6）

软件开发过程的质量决定软件的质量，软件测试过程的质量直接影响测试结果的准确性和有效性。

1 软件测试过程常用的模型

1、V模型

V模型反映出测试活动与分析设计活动的关系，指出单元测试和集成测试应检测程序的执行是否满足软件设计的要求。系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标。验收测试确定软件的实现是否满足用户需求或合同的要求。

2、W模型

W模型指出软件各开发阶段中应同步进行的验证和确认活动，即测试与开发也应是同步进行的。W模型有利于尽早和全面的发现问题。

3、H模型

V模型与W模型有不妥，即它们都把软件的开发视为需求、设计和编码等一系列串行的活动，而事实上，这些活动可以交叉进行的。H模型揭示这一点：软件测试是一个独立的流程，贯穿于产品的整个生命周期中，与其他流程并发进行。

除了上面的几种常见模型外，还有X模型、前置测试模型等。在实践中，建议以W模型作为框架，及早全面地开展测试，同时灵活运用H模型独立测试的思想，在达到恰当的就绪点时就应该开展独立的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。

2 测试阶段中的测试活动

软件测试过程主要包括以下四项基本活动：

1、测试策划

在测试策划中的活动有：制定测试计划，以确定测试范围、测试策略和测试方法，规划测试任务日程表，对测试资源进行安排，并提前评估测试风险，制定风险控制策略。

2、测试设计与实现

在测试设计与实现中的活动有：制定测试的技术方案，选择测试工具，并根据测试技术方案设计测试用例。

3、测试执行

在测试执行中的活动有：建立相关测试环境、配置测试数据、按日程安排执行测试用例并记录测试执行结果，对发现的软件缺陷进行报告，并配合开发人员进行软件缺陷的分析、处理和追踪。

4、测试总结

在测试总结中的活动有：对测试结果进行综合分析，以确定软件产品质量的当前状态，为产品的改进和提供数据和依据，同时编制测试报告，提交相关的测试文档。

3 软件测试过程管理的特点

软件测试过程管理的基本内容包括计划、组织和监控；测试过程中存在的问题有：

1.软件质量标准定义不准确、任务边界模糊。

2.软件测试项目的变化控制和预警分析要求高。

3.软件测试项目具有智力密集，劳动密集的特点，受人力资源的影响最大。

4.测试任务的分配比较困难。

5.测试要求的人力资源十分稳定。

6.软件测试人员在待遇、地位上可能会受到一些不公平的待遇。

软件测试项目的过程管理能否成功，通常受到三方面的影响：项目组内的环境，项目所处的组织环境，整个开发流程所控制的全局环境。

4 软件测试过程管理的原则

1、有关测试需求，应当有一个经各方同意的、完整的、清楚的、详细的、整体的、可实现的和可测试性的需求并文档化，尽可能坚持最初的需求。

2、测试计划先行。软件项目管理过程从项目的计划活动开始，软件测试项目也不例外，也是从测试计划开始。

3、建立任务优先级。在测试任务较多的情况下，应该为各项任务建立测试优先级，这样也可以根据优先级来先后处理各项任务。

4、建立客观的评估标准。这样使得整个项目过程具有良好的可测性和可跟踪性，强调以数据说话。

5、尽早测试。这是从W模型中抽象出来的理念。一方面指测试人员尽早参与测试项目，另一方面指尽早开展测试执行任务。

6、全面测试。这也是W模型的重要思想，其含义一方面只要对软件所有产品进行全面的测试；另一方面指软件开发人员与测试人员全面参与到测试工作中。

7、全过程测试。这是从W模型中抽象出来的另一理念。其含义一方面指测试人员要充分关注开发过程；另一方面指测试人员要对测试的全过程进行全程的跟踪。

8、独立的、迭代的测试。这是H模型的重要思想，强调只要达到测试就绪点，即测试条件成熟，测试准备活动完成，测试执行活动就可以开展。

5 软件测试过程的人员组织

测试团队的组织直接关系到测试团队的工作效率和生产力，其组织方式由测试团队的规模、具体任务和技术来决定。

一个测试团队的基本角色有：测试经理、实验室管理人员、内审员、测试组长、测试设计人员、资深测试工程师、一般测试工程师。

若测试团队规模较大，则测试工程师分为三个层次：初级测试工程师、测试工程师和资深测试工程师，同时设置自动化测试工程师、系统测试工程师和架构工程师。

测试过程人员组织的一个方面是考虑测试团队的规模，测试团队的规模可以考虑在整个开发部门所占的比重，或相对开发人员所占的比例。从经验看，不同的应用，软件测试和软件开发人员的比例也是不同的，大致可分为三类。

1、操作系统类型的产品，对测试要求最高，测试人员和开发人员的比例为2：1。

2、应用平台、支持系统类型的产品，对测试要求比较高，通常测试人员和开发人员的比例为1：1。

3、对于特定应用系统一类产品，由于以后对象清楚、范围小，甚至可对应用平台或应用环境加以限制，所以测试人员可以再减少，但测试人员和开发人员的比例至少保证在1：2的水平以上。

6 结束语

相比之下，目前中国软件企业在软件测试方面与国际水准仍存在较大差距。首先，在认识上重开发、轻测试，没有认识到软件项目的如期完成不仅取决于开发人员，更取决于测试人员；其次，在管理上随意、简单，没有建立有效、规范的软件测试管理体系；另外，缺少自动化工具的支持，大多数企业在软件测试时并没有采用软件测试管理系统。所以对国内软件企业来说，不仅要提高对软件测试过程管理的认识，同时要建立起完善的软件测试过程管理体系，确保软件测试管理在软件质量保证中发挥应有的关键作用。

参考文献

[1]朱少民. 软件测试方法和技术 [M].北京：清华大学出版社， 2005年

[2]郑文强，马均长. 软件测试管理[M].北京：电子工业出版社， 2010年

测试团队工作计划篇（7）

随着信息技术的发展，用户对软件的需求也逐渐提高，这就对软件开发者提出了更高的要求。由于传统软件开发理论的不足，软件开发一般耗时较长，用户从中的收益较小，而敏捷管理方法以实践为基础，为软件开发提供了新的思路，充分提高了软件的适应性，有效地满足了用户的需求。

一、敏捷管理方法概述

软件开发的难度随着用户的需求在逐步提高，市场竞争的激烈化也刺激着软件开发者必须使用新的软件工程管理理论。目前，敏捷管理方法包括极限编程、自适应软件开发等，这些方法都以用户的需求为中心，减少了所需要的文档，提高了软件的灵活性。敏捷软件开发主要有一下几条原则：要尽早、持续地交付有价值的软件供用户使用；即使到了开发后期也能够满足客户的需求，为客户的利益着想；经常性的交付可工作的软件；在软件开发期间，开发人员要和业务人员积极沟通；为软件开发者提供他们所需要的环境，给予充足的支持；在开发团队内部，要面对面的交流，以提高信息传递效率；软件开发必须保证可持续的、恒定的开发速度；积极关注技能的创新；从最简的工作开设等。这些原则涵盖了敏捷管理的核心思想，颠覆了传统的重载软件的过程，显示了以人为本、以技术为支持、注重实效的思想，国内外的实践也证明了敏捷管理方法在软件开发中的重要作用。与传统的管理方法比较，敏捷管理主要有以下几个优点：

①较强的灵活性。敏捷管理方法较为灵活，以现有的事物为基本管理职责，由市场驱动竞争力的储备，能够有效地满足用户需求的变化。

②错误率低。敏捷管理方法将设计工作与编码工作融合到了一起，能够及时发现错误。

③项目风险较低。敏捷管理方法提高了有价值、可运行软件的速度，使用户能够尽早地使用软件。

④能够提高人员的能动性。敏捷管理为员工提供了充足的资源，对客户的个性需求有较强的应对能力。⑤降低了成本。敏捷管理方法降低了文档的维护成本，面对面的信息交流也较低了交流成本，同时轻快开发过程也降低了时间成本。

二、敏捷管理方法在软件开发中的应用

1、团队管理

软件开发不是由个人单枪匹马就能够完成的，它需要团队的合作，因此，“以人为本”是团队管理的基本原则。团队管理需要以项目为中心，为开发人员提供必要的环境和技术支持，同时还要给予积极的鼓励。一方面，要“恩威并济”。团队管理需要融入一定的纪律，保证软件开发的标准性，同时也要容忍一定的个体变化。在传统的管理方法中，严格的纪律保证了很多行业的高生产力，但在软件开发中，如果项目负责人单从自身的角度出发制定严格的标准，而忽视了员工的独特思想，则很可能造成很多不利的影响。另一方面，促进团队合作。敏捷软件开发需要促进人与和人之间、小组和小组之间的合作，不再以命令的形式调节他们之间的关系，而是以互信为基础。第三，提高开发人员的荣誉感。团队管理的困难之一在于提供适应性强的奖励机制，如果单纯以奖金的形式进行奖励，长时间也会影响团队的动力，因此，需要以更好的形式激励团队。为员工提供一定的荣誉感，能够让员工真实感受到自己劳动成果的价值，能够更加有效地激发员工的主动性、积极性和创造性。第四，提高信息的反馈效率。敏捷管理方法较为灵活，但评估起来较为困难。国内外的实践表明，在管理过程中实施积极的、经常性的反馈，并认真分析评估反馈结果能够及时地、清楚地了解团队的精神状态和项目进展情况，从而为项目负责人优化管理方法提供了科学的参考。反馈方法较多，如检测用户故事的完成数、验收测试通过率等，另外也包括每周的评估等。启动团队是软件项目开发的重要步骤，每一个团队的启动都需要一定的时间和过程，是工作关系的构建，只有做好启动团队工作才能够有效地促进项目开发目标的实现，确定团队和员工的工作目标。一般的，从组建团队开始，调查员工的基本情况，如工作能力、人际关系等，然后分配责任，最后在启动项目前，召开团队会议，制定团队目标、做动员等。

2、开发管理

在敏捷软件管理中，多以迭代开发为主，但对管理人员的缺乏可操作性的指导，同时也缺少开发方法的阐述，缺少了单元测试、验收测试。由于项目团队的规模、人员构成、项目目标等方面的不同，软件开发项目没有统一的开发策略，只有结合具体情况制定开发策略才能够满足实际的需要。敏捷管理方法指导下的开发策略需要注意以下几个问题：第一，努力实现软件的可运行。从阶段性设计看，可运行的软件代表了团队的开发成果，为团队带来了成就感和信心；从用户的角度出发，只有给用户展示了可运行的软件才能够让他们真实地看到自己的需求是否得到了满足。第二，制定周密的开发计划。传统的软件开发在项目进度方面的掌握程度较低，系统正式完成的时间不确定，因此，敏捷开发要求将开发进度可衡量化，将每一个任务制定一定的点数，将所有任务的点数相加就是本次开发所需要的工作量，用所完成的任务点数比上总任务点数就是开发进度百分比。第三，尽量减少文档的数量。在开发时要根据实际需要增减文档的制定，降低项目的风险。第四，加强交流。敏捷开发要求开发成员之间要加强交流，保证数据采集、团队合作、软件设计的效率。第五，积极考虑客户的需要。敏捷开发要积极满足用户的需要，让用户直接参与软件开发的过程中，让客户亲临现场，与其探讨软件开发中的各种问题，提高软件的实用性。

3、需求管理

需求管理以掌握用户对软件的需求为目的，是项目启动的第一步，是一支指挥棒，以灵活的变动将“用户故事”和“现场客户”结合起来，表达了用户真正的、迫切的需求。“用户故事”是一种较为简单的搜集客户需求的新方式，独立表达了用户的需求，用户可以随时删除也可以随时加入，是一种概述性的描述；“现场客户”是指让用户代表亲临开发现场给予指导。用户故事与现场客户两种方法的结合，让客户对团队开发软件的细节有更加深入地了解，同时也能够给予必要的指导，节省了交流时间，提高了开发的效率。

4、规划

在对用户故事进行轻重排列后，从业务和技术方面逐一制定实现计划。在业务方面要积极考虑业务价值加大的用户故事；在技术方面，技术小组从技术难度及风险的角度出发，划分功能区，要将所存在的问题说明给客户，让客户做出选择。

5、迭代规划

敏捷开发要求尽可能为客户提供可工作的软件，因此，要尽量缩短迭代的周期，一般为1~4周。迭代的优先级由技术组确定，但其价值又客户决定。在第一次迭代中，小组要建立基本的开发设施，另外，要避免技术迭代，减少耗时。对团队开发来说，在历经几个月甚至几年的时间才有所突破，每一次的迭代都是一次成就，是一种较好地员工激励形式。

6、任务分配

在客户将用户故事提出后，开发团队商讨如何分界为几个任务，然后分配给开发人员。第一步，客户提出用户故事。客户将用户故事宣布告知给开发团队，团队成员可以提出问题，以充分理解客户故事。第二，讨论任务。开发团队在讨论过后将用户故事分成多个任务，做好接受任务的准备。第三，选定任务。团队成员选定合适的任务，做好估算工作。

7、软件设计管理

在敏捷设计中，迭代开发的过程要力求减少文档，另外，敏捷管理要努力实现全局视图和软件源代码一起演化，从当前的系统需求出发构建所需的基础结构，保持结构的简洁、干净，病富有表现力，同时还要提高其灵活性。在分配给开发人员任务之后，要测试代码，提高源代码的质量，让开发人员有更加充足的信心，同时，测试也能够迫使程序员从不同的角度观察所要编写的程序。软件开发都是由结对的程序员使用同一台电脑实现的，由一位出入代码，另一外观察代码及其需要改进的地方，两者可以交换角色，最后所生成的代码成果由两人共享。结对关系每天至少要改变一次，以减少两者的压力，提高编码质量，同时也能够促进他们编码技术的提高。

8、跟踪

跟踪能够让程序员、客户及管理者明确工作进度、质量等问题，同时也能够发现潜在的问题等。一方面，要跟踪资源，即计划和实际的对比、团队成员的人数、客户参与次数、测试人员数量、参与开发的计算机数量等，这些是软件开发的必要条件。另一方面，跟踪范围，即跟踪故事的变化情况。第三，跟踪质量，即测试表所显示的通过测试数及未通过测试数。第四，跟踪团队成员，即观察开发成员的问题、开发成员之间人际关系问题，看其是否全身心地投入等。

9、测试验收管理

当一个迭代完成后，用户会与团队商议下一步的需求。测试验收过程中，越早的发现问题，就能够缩短程序投入运行所需的时间，期间，客户需要提供验收测试，所提供的测试越多，项目进展速度就越快，价值也就越高。客户可以通过制定的形式采集所需要的素材，通过自动的脚本根据客户的需求运转。一旦某项测试通过需求，则决不允许该测试再次失败，随着测试的不断累积会形成一个测试集合，它能够测试系统的运行，一旦测试失败，系统的创建也就失败。因此，要保证需求的实现，避免其遭到破坏。

三、结语

敏捷管理方法渗透于整个软件开发过程中，是一个长期的信息构建原则，而不是某一个独立的事件它，适应了复杂软件开发的要求，同时也适应了软件技术发展的需要。随着客户对软件要求的不断提高，敏捷开发适应了复杂的环境，并且尽可能地保持软件开发的简单化和系统化，适合团队型的开发项目，它能够及时反馈信息，有效提高客户的满意度，也能够保证系统的质量。

参考文献：

[1]沈成莉.敏捷项目管理在软件开发中的实践应用[D].复旦大学2009

测试团队工作计划篇（8）

中图分类号：G642 文献标识码：B 文章编号：1673-8454(2012)07-0061-04

一、引言

随着远程教育需求的日益增长和网络教育支撑技术的飞速发展，设计适用于网络上教学的高质量课程已经成为网络教育发展的一项重要课题。

“软件工程”课程的目的是使学生能够系统地掌握软件工程的基本概念和原理，以及实用的开发方法和技术，了解软件工程各领域的发展方向，学习用工程化的思想和方法开发和管理软件项目，了解软件开发过程中应遵循的流程、准则和规范，为从事软件工程研究或应用开发工作打下坚实的基础。[1-3]考虑到软件工程是一门注重工程实践能力的课程，课程的学习既要求要掌握软件工程基本理论，又要求锻炼运用这些理论知识解决实际问题的能力，做到理论与实践相结合。

当前“软件工程”网络课程的设计日益受到重视，但在实际教学中还存在着一些问题，包括：在理论课程中贯穿整个软件工程过程的系统化案例不多，以及实践课程中项目开发实践平台不完善等。[4-6]这些缺陷都影响了学生对于软件工程整体思想的理解与实践。

解决上述问题已成为当前“软件工程”网络课程设计的迫切需求。因此，本文以理论结合实践的方式将IBM公司的下一代软件开发协作平台Jazz整合到课程的设计中：使用基于Jazz平台的工具集（尤其是其中的RTC、RRC、RQM，以及ClearCase和ClearQuest），提供对软件工程生命周期各阶段任务的支持，并将Jazz平台跨地域的团队协作能力和适用于敏捷软件开发的特点充分利用到学生的工程实践中，具有一定的创新性，取得了良好的效果。

二、“软件工程”网络课程的总体教学设计

本文在“软件工程”网络课程的教学设计中注重理论知识的掌握，同时以培养工程实践能力为导向, 强调学生能力的培养。通过对该课程的学习，让学生理解工程化方法在软件开发中的应用，以理论结合实践的方式进行同步教学：理论讲授部分采用网络多媒体教学模式，辅之以课后测验和课后作业，课程实践部分采用学生分组完成一个中小规模软件项目开发的教学模式。

在课程开展的可行性方面，苏州大学计算机科学与技术学院在与IBM公司的合作框架下，能够获取学生课程培训与实践所需要的工具和相关电子资源。此外，通过校、院或系一级的教学管理系统和FTP服务器建立教师与学生的互动平台。教师可以通过网络教学课件和案例分析等电子资源，还可以布置课后测验、课后作业以及实践项目；学生则可以通过网络下载教学资源进行课程学习，也可以通过网络进行课后测验、提交课后作业以及参与实践项目的开发。

该课程的教学设计分为两个部分：授课部分和学生工程实践部分，其中授课部分又可进一步分为理论知识授课部分和工具培训授课部分。这两部分的结合能达到配合理论教学，进行工具使用能力训练，并提高学生工程实践能力的目的。

1.授课部分

（1）理论知识授课：本部分由主讲教师完成，提供网络多媒体教学课件。理论知识授课部分主要介绍软件工程的历史、现状，以及发展趋势，以软件工程发展历史上的两个主流方法学（结构化软件工程和面向对象软件工程）为基础，深入讲解软件工程的基本原理、方法和技术，并涉及软件工程的管理话题，如软件质量管理、配置管理、过程管理、项目管理等。该课程的理论知识授课内容可以划分为结构化软件工程，面向对象软件工程，软件过程管理与质量这三个主要部分。在课程教学中，注重提供贯穿整个软件工程过程的系统化案例，使得学生能够对于软件工程的理论知识有一个全面、直观、感性的认识。

（2）工具培训授课：本部分由辅讲教师和工具提供商工程师完成授课和辅导，与理论授课部分同步进行，采用专题讲座方式进行相关工具的使用培训。工具培训授课部分主要针对IBM公司新一代的软件开发协作平台Jazz，采用IBM公司Jazz平台系列集成工具的培训教材和教学资源，对学生进行Jazz平台及相关工具体系的使用方面的培训，并对工具使用的实验进行指导，该实验也可通过网络完成。

2.学生工程实践部分

本部分由辅讲教师和助教完成，指导学生分组完成软件项目的开发。学生工程实践部分主要参考IBM公司的Jazz平台实验方案，选用一组典型的中小规模软件项目，由学生分组并选择适当的项目进行开发。在软件开发过程的不同阶段中，学生项目组需要展示对理论课程内容的掌握程度和工具使用的熟练程度，每周就项目进行进展报告，并提交各阶段相应的成果。教师需要对学生项目组进行过程管理和技术辅导，并对集中的问题进一步进行辅导。

三、IBM-Jazz平台简介

Jazz平台是IBM推出的面向跨地域团队的下一代团队协作平台，也是一个整合软件工程生命周期各阶段任务的软件开发平台。[7]

1.Jazz平台的特点

Jazz平台的主要特点包括下述三项，这些特点使得Jazz平台能够提供对于“软件工程”网络课程工程实践的支持：

（1）跨地域的开发团队实时协作能力。Jazz平台支持Web2.0技术，能帮助分散的软件开发团队克服地域障碍，搭建实时协作的平台。Web2.0技术支持实时的信息和信息反馈，通过网络，分布在各地的开发团队成员都可以在Jazz上了解最新的开发进度，提交最新的开发和测试结果，找到应遵循的工作流，在该工作流的指引下循序渐进地工作，而不必担心偏离了开发目标。项目的管理者也能够在Jazz上找到需要了解的信息，包括团队的进度、每位开发者的现状，以及资源的配置等，从而帮助其配置资源，确保开发按时按目标完成。这种通过网络提供的协作能力很适合网络课程中工程实践部分的团队协作工作，包括了学生的参与和教师的管理。

（2）支持整个软件生命周期各阶段任务的无缝集成。Jazz平台提供了对于软件开发和管理流程的定义和执行能力，在这些自定义流程的基础上，能够跨越包括需求、设计、编码、测试、配置与交付等软件生命周期的各个阶段，对各阶段的任务进行无缝集成。Jazz平台对软件工程生命周期各阶段任务的支持，符合“软件工程”课程的工程实践要求，使得学生能够对于软件工程过程有一个全面和系统的理解和实践。

（3）支持敏捷软件开发。Jazz平台还预定义了一些适用于敏捷软件开发的流程，对RUP的支持使得最新的需求能及时交付给软件开发项目的提出者，并且能很快得到最新的反馈意见。Jazz平台对于敏捷软件开发提供了支持，符合“软件工程”网络课程的工程实践部分中“开发中小规模软件项目”的要求。

2.Jazz平台工具集

从2008年开始，IBM陆续推出了基于Jazz平台的工具集，这些工具都是以与Jazz平台集成的插件或连接器的形式的。主要的工具包括：

（1）Rational Team Concert（简称RTC）：RTC是IBM推出的第一个基于Jazz平台的产品。作为一个协作软件交付平台，RTC通过提供整合的项目计划、工作管理、配置管理、团队构建、版本构建、报告能力等，为整个开发团队提供了协作的基础。RTC还能够帮助开发团队简化、自动化和监管整个软件交付过程。

（2）Rational Requirements Composer（简称RRC）：RRC是基于Jazz平台的需求开发管理平台。辅以Rational DOORS Requirements Professional，RRC将各种需求定义手段和需求相关人员有机地结合在统一的集成协作平台上，实现协作化的需求定义与需求管理。RRC采用多种需求开发方法和协作技能，使需求相关人员能更好地进行需求的获取、分析、精化、管理、评审以及验证。使用RRC能够尽量确保在开发之前将需求定义清楚，减少因为需求定义不良为后续开发带来的问题。

（3）Rational Quality Manager（简称RQM）：RQM是基于Jazz平台的全生命周期质量管理协作平台。RQM在整个软件工程生命周期中提供了从测试需求管理、测试计划、测试用例设计、测试执行、测试评价和缺陷管理等完整的测试生命周期管理方法，能够简化和自动化繁杂的测试任务，支持手工测试以及自动测试。通过与其扩展组件Rational Test Lab Manager的集成，RQM还能提供自动化的测试环境和测试资源的管理，从而提高测试的效率。

（4）Rational Project Conductor（简称RPC）：RPC是基于Jazz平台的项目及资源管理平台。RPC可以帮助项目经理进行项目计划、制定项目进度，为项目和任务安排合适的资源。RPC还提供了对项目状态和进度进行管理监控和可视化的功能，可以作为项目开发的核心数据库。

（5）Rational Insight：Insight可以帮助获取关于开发团队的度量数据，客观地度量开发的状态和进度。Insight能够提供关于系统和软件交付准确的深入信息，确认高优先级的业务目标，并给出软件交付的最佳实践，从而更好地定位开发团队的目标、度量最佳实践和业务成果。

（6）Rational Build Forger（简称RBF）：RBF是基于Jazz平台的过程执行框架，可以对软件工程生命周期中重复的开发任务和构建过程进行自动化的安排、管理和追踪。RBF支持主流的开发语言、工具及平台，能够在沿用现有开发资源的同时，增加有价值的自动化、加速、通知和日程安排等功能。

（7）Rational Asset Manager（简称RAM）：RAM可以帮助组织了解所拥有资产的状况，资产之间的关系，以及资产所交付的业务价值，从而使组织能够基于一致的可重用资产更快地向市场交付高品质的软件解决方案，并减少解决方案实现和维护的成本。

除了上述工具外，IBM还将陆续基于Jazz平台推出相关工具，并进行众多上一代Rational工具的Jazz化过程，已完成的包括ClearCase和ClearQuest等。

在“软件工程”网络课程中，主要涉及的基于Jazz平台的工具是：Rational Team Concert、Rational Requirements Composer、Rational Quality Manager，以及ClearCase和ClearQuest。

四、“软件工程”网络课程的工程实践部分设计

“软件工程”课程具有实践性强的特点，其工程实践环节既重要又困难，需要深入研究该课程整个工程实践环节的教学内容和方法，确保相关实践平台，设计完整的实践体系，包括：实验大纲、计划、教材等。本章中对于“软件工程”网络课程，即所述“学生工程实践部分”做进一步研究。

1.工程实践部分的目的

（1）让学生在实践环节中加深对软件工程课程理论知识的理解，通过让学生参与一个中小规模软件开发的完整过程，建立对软件开发过程各阶段活动的全面、直观、感性的认识。

（2）要求参与的学生在实践环节中分成若干个项目组，并以项目组为单位完成软件系统从需求分析到测试交付的完整过程，在该过程中学习有效的沟通方法，培养团队合作精神，为将来进入软件工程行业做好准备。

（3）让学生通过实践环节掌握Jazz平台系列工具的使用方法，培养学生灵活运用所学理论知识分析和解决问题的能力。

“软件工程”网络课程的工程实践部分的总体要求包括：遵循敏捷软件开发的定义，各个学生项目组独立完成从需求获取与分析、设计与建模、编码、测试、配置与交付、过程管理等软件工程关键活动，熟练使用各种工具完成上述活动，养成规范化软件开发的习惯，并根据国标版软件开发文档模板最终提交相应的软件制品与规范化文档。

2.工程实践部分的具体要求

（1）项目管理与计划。根据实验课程的安排，各学生项目组首先进行的是基于项目管理知识使用Jazz-Rational Team Concert进行所选项目的开发过程管理，使用Jazz-ClearCase实施配置管理，基于Jazz-ClearQuest进行缺陷与变更管理。需要学生项目组制定项目计划，包括过程计划、开发计划、测试计划、配置管理计划等，在网上提交相关文档和进展报告。

（2）需求获取与分析。在该阶段中要求各学生项目组获取并分析目标软件项目的需求，采用用例模型描述系统的需求规约，使用Jazz-Rational Requirements Composer管理需求分析阶段的结果并进行需求评审。需要学生项目组给出需求规约文档，在网上提交相关文档和进展报告。

（3）设计与建模。在该阶段中要求各学生项目组以需求阶段的结果为基础，使用工具Rational Software Architect为目标软件项目进行设计和建模（注：IBM尚未为该阶段提供基于Jazz平台的工具），基于模型描述系统的设计规约。需要学生项目组给出设计规约文档，在网上提交相关文档和进展报告。

（4）软件编码。在该阶段中要求各学生项目组以设计阶段的结果为基础，完成目标软件项目的最终编码过程，并对软件产品进行评审。需要学生项目组给出源代码和可执行的系统，在网上提交相关软件制品和进展报告。

（5）软件测试。在该阶段中要求各学生项目组使用Jazz-Rational Quality Manager及其他测试工具完成测试：设计测试用例，完成测试脚本的编制，实现自动化测试执行，进行测试结果的收集和分析，进行测试评估，将确认的缺陷提交到缺陷追踪系统中。需要学生项目组给出测试文档，在网上提交相关文档和进展报告。

（6）软件部署与项目总结。在该阶段中要求各学生项目组结合实际运行环境，完成目标软件项目的部署，并对各个阶段的执行情况进行总结，必要时可录制系统演示。需要学生项目组在网上提交报告和相关资料。

五、结束语

针对当前“软件工程”网络课程的现状，本文在对该课程的设计中整合了IBM公司的下一代软件开发协作平台Jazz，利用该平台对软件工程生命周期各阶段任务的支持，及其跨地域的团队协作能力和适用于敏捷软件开发的特点，以理论结合实践的方式设计了该课程的总体教学计划：着眼于培养学生的工程实践能力，从授课部分（包括理论知识和工具培训）以及学生工程实践部分两个方面展开，在实践中取得了良好的教学效果。

参考文献：

[1]Roger S. Pressman. Software Engineering: A Practitioner's Approach, 7th edition[M]. McGraw-Hill，2009：928.

[2]Ian Sommerville. Software Engineering, 9th edition[M]. Addison Wesley，2010：792.

[3]Shari L. Pfleeger, Joanne M. Atlee. Software Engineering: Theory and Practice, 4th Edition[M]. Prentice Hall，2009：792.

[4]许家,白忠建,吴磊.软件工程――理论与实践, 第2版[M].北京:高等教育出版社，2009：399.

测试团队工作计划篇（9）

一、工作职责

1、规划所负责产品的研发前景和功能方向；

2、充分了解产品需求，并对用户提交的需求仔细分析评估，对于合理需求要不断完善补充到需求分析说明书中；

3、负责安排新增需求或变更需求的设计工作，负责检查设计工作是否遵照公司的各项设计标准，编制并上报设计阶段工作计划；

4、提交各项设计成果进行评审，并及时将评审中发现的问题安排整改，负责评审报告的；

5、充分了解开发团队中每个成员的特长和优势，做好开发任务的分配，提交编码和测试阶段工作计划；

6、负责产品的开发质量和进度控制，保证按期保质完成开发任务；

7、将开发中的各种文档及时整理并提交；

8、负责开发团队成员的绩效考评工作。

二、工作标准

1、需求分析阶段

1）每天上午和下午上班前登录客户呼叫平台收集客户呼叫，负责提交对新增需求和变更需求的评估申请，由研发部经理或副经理组织相关人员进行评估，评估结论为：可行、不可行、需进一步沟通。对于可行的需求，要评估大致完成时间。

2）负责整理评估报告，并将评估报告2小时内录入客户呼叫平台，及时反馈给技术支持。

3）按照公司的需求说明书规范要求，负责将本次评估通过的所有需求4小时内添加完善到产品需求说明书中，并新版需求说明书。

4）需求评审通过后，制定设计工作计划。

2、用例设计阶段

1）按照公司的《用例设计规范》进行用例设计，设计完成后提交评审申请。由公司评审主持人负责组织评审。

2）评审不通过的要及时整改并再次提交申请。评审通过但存在问题的要在24小时内改进，并提交给评审主持人验证。

3）负责评审报告。

3、概要设计阶段

1）按照公司的《界面设计规范》进行界面设计，设计完成后提交评审申请。由公司评审主持人负责组织评审。

2）按照公司的《数据库设计指南》进行数据库设计，设计完成后提交评审申请。由公司评审主持人负责组织评审。

3）按照公司的《概要设计模板》和《概要设计指南》进行概要设计，设计完成后提交评审申请。由公司评审主持人负责组织评审。

4）所有评审不通过的要及时整改并再次提交申请。评审通过但存在问题进的要在24小时内改进，并提交给评审主持人验证。

5）所有设计，如果在公司的标准库里面能找到相关设计示例，必须在设计示例基础上进行修改，不允许不依照公司设计范例而自行设计，违者按照公司绩效考核办法进行考评。

6）负责评审报告。

7）概要设计评审通过后编制开发计划。

4、开发准备阶段

1）产品经理要将每个模块的概要设计同开发人员沟通好，要求开发人员复述和模拟所开发模块的场景，确保每个开发人员明确知道自己的工作任务，对于开发人员模拟中发现的问题及时沟通解决。负责记录沟通情况。

5、编码实现阶段

1）

开发人员未提交功能模块测试时：

a)

要求产品经理每天检查开发人员的编码规范，出具模块编码规范检查表。对于不合格的及时安排整改，并进行复查。

b)

要求产品经理每天检查开发人员的界面规范，出具界面规范检查表。对于不合格的及时安排整改，并进行复查。

2）开发人员提交功能模块测试后，对开发人员提交的测试模块，进行仔细检查，主要检查功能实现是否正确，只有符合要求的才下达测试任务给测试人员，否则，退回开发人员修改。

3）编码实现过程中随时检查每天的进度情况，对于延期的要求帮助开发人员分析原因，并帮助他们解决进度延期问题。

6、测试验证阶段

1）对于测试人员发现的所有bug都要在2小时内下达修复任务，对于测试人员提交的bug有异议的，及时报告给研发部经理，由研发经理判断决定bug成立。研发经理认为有异议的，及时报告公司领导，由公司领导负责决定是否成立。

2）根据进度要求，下达系统测试任务给测试人员。

3）定期阅读测试周报，对于具有普遍意义的问题和经常反复的问题要在每周的学习例会上进行讲解，对于讲解后仍然重犯的团队成员要予以扣分，并做好记录。

4）根据测试反馈的性能测试报告，及时下达性能优化任务。

7、内部验收阶段

1）根据测试报告情况，具备内部验收条件的，负责提交内部验收报告，经过研发部经理批准后，由客服部组织进行内部验收。

2）对验收发现的问题，简单的问题2小时内下达整改任务，复杂的问题进行内部讨论后8小时内提出整改计划，并负责安排监督整改计划完成。

8、团队绩效管理

1）依照公平公正原则，根据开发任务的进度要求和团队成员的能力素质和特长，下达工作任务。

测试团队工作计划篇（10）

中图分类号：F426.6 文献标识码：A文章编号：1007-9599(2012)05-0000-02

一、引言

随着计算机技术的迅猛发展，计算机软件已渗透到各个领域。人们对计算机软件质量的要求越来越高，要开发出高质量的软件产品，利用传统的软件测试方法已不能适应现在的要求，这使得软件的开发规模和复杂程度呈螺旋状递增。为了尽可能多地测试出程序的错误，开发出高质量的软件产品，势必加强对测试工作的组织和管理。

二、设计软件测试，排除“近忧”

（一）测试策略设计

软件测试策略主要考虑如何把设计测试用例的技术组织成一个系统的、有计划的测试步骤。在测试的各个阶段应选择适宜测试方法，由软件开发人员和一个独立的测试小组共同完成测试任务。对小项目做大测试和对大项目做小测试都是不应该的。通常，对于工作量小于5个人月的普通软件，应全面测试，重点进行功能测试、性能测试及验收测试等。而对于一个工作量接近30个人月的中型软件而言，不仅要注重系统测试，还应该认真完成单元测试、集成测试及验收测试等。

设计测试策略时应注意如下几个方面：1.测试成本与测试预期效果之间应达到最佳平衡；2.测试需求与测试活动安排之间应达到最佳平衡；3.设计策略形成的技术路线可行与否，有无设计依据；4.该的技术路线在工程实际与企业质量承诺之间应达到最佳平衡。

（二）测试方法设计

测试方法是对测试策略设计形成的技术路线的逐步细化，主要包括要测试的功能，准备输入的数据及其对应的预期输出结果。设计测试方法时，应考虑以下几个方面：测试成本与测试产生的效益是否处于最佳比值；每个测试活动是否描述清晰；测试手段是否可行；测试产生的结果能否改进产品质量。

具体设计测试方案时，最常见问题的就是测试人员少，而测试工作枯燥、繁重。加强测试人才专业技能、行业知识和个人素养，并建设高效测试团队是解决这一问题的根本途径。然而，远水解不了近渴。那么，可以寻求其他途径来解决。比如软件外包和外协、自动测试工具等都是解决问题的办法。

（三）测试用例设计

测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，是对测试方法实现技术部分的更细致、更具体的描述。由于不可能进行穷尽测试，因而设计测试用例时要选用少量的、高效的测试数据，尽可能找出更多的潜在错误，尽可能完善地进行测试。

等价类划分法（EP）是黑盒测试中典型的一种方法。等价类是输入条件都是等效的输入域的集合。EP法把程序的输入数据集合划分为互补相交的子集，即若干个等价类，包括有效等价类和无效等价类。在每个等价类中，作为代表的这组数据测试程序并发现错误。经验表明，大多数错误都发生在输入的边界值上。为此，专门引入边界值分析法（BVA），把它最为EP方法的补充。

白盒测试根据程序逻辑结构进行通路测试。要想穷尽路径测试往往做不到，但是尽可能选取有代表性的通路，对各种通路测试是可以做到的。这里值得指出的是，在不同的测试阶段，黑盒测试法与白盒测试法可发现不同类型的错误。因此，两种方法缺一不可，相辅相成，灵活运用，事半功倍。

三、管理好软件测试件，消除“远虑”

测试件是指在测试团队知识库中的所有输入和输出数据，并且这些数据必须受控于或者必须划入一切手工测试和自动测试活动中。测试件像其他软件一样，需要被管理和被工程化。

（一）测试用例管理系统

一个中等规模的待测软件，需要设计的测试用例往往有数万个之多，如果不进行专门的管理，测试人员很快就被淹没在测试文档及测试用例的海洋中。测试用例设计人员需要了解目前已经为哪些模块设计了测试用例？为哪些部件设计了测试用例？还需要完成哪些设计工作？而测试执行人员则应该清楚的知道“今天要测试什么？需要执行多少个测试用例？”等等。测试用例管理系统就是基于这些需求而开发的，其目的是为了提高测试活动的效率，统一管理该项目测试用例的设计、执行及执行结果等。

（二）配置管理

测试件可以使用配置管理的方式进行管理，但除了测试用例、测试缺陷报告之外。现提供两种配置管理方式。一种方式是把每一个的测试件作为配置项，每个测试件有各自的版本信息。这种方式适用于比较完善的配置管理体系，因为该方式基于一个或多个测试件组进行基线化。如若使用不当，可能导致使用的测试件版本错误。另一种方式是在配置库中将测试件组作为配置项进行保存。每个测试件组有各自的版本信息，而组内的各个测试件成员没有相应的版本信息。这种方式适用于不成熟的配置管理体系，因其操作简单，所以出现版本错误的可能性较小。

（三）测试件的复用与迁移

测试件可被复用，因此测试件中包含的知识和经验可被他人获取并应用到适合的项目中，这是管理测试件的又一个重大意义。测试团队内部人员之间能够有效地、充分地、完全地传递知识，这将从很大程度上提高团队的整体水平。各项目中所使用的大量的测试技术和获取的丰富的知识经验都记录在测试件管理库中，这些不仅对于团队中的新人而言，即使是参加测试工作多年的老手来说，都是非常宝贵的财富资源。因为测试件的复用与迁移能把人们从大量的、繁重的、复杂的、重复的、枯燥的劳动中解放出来。此外，测试团队负责人还应提倡团队内部成员在深入了解和学习测试件库的同时多提改进意见，让测试件库能长久地为人们服务。

参考文献：

[1]钱坤.层次化测试在银行系统的设计与实现

[2]郭群,卢海燕.软件测试基本技术

[3]侯海霞.基于软件测试技术的软件质量保证研究