测试团队工作计划第1篇

【关键词】敏捷测试 Scrum 研究

21世纪是信息化技术全面高速发展的时代，企业之间的竞争日趋激烈，产品质量对于企业的发展重要性得以凸显，并成为企业核心竞争力的突出表现之一。软件行业也面临类似的问题，软件系统变得越来越复杂，传统的软件工程理论下软件开发周期过长、无法保证软件质量、开发过程冗长、笨重，加之频繁的人员流动、迅速变化的市场，都让传统的软件开发方法无法适应新的市场竞争环境，软件的失败率变高。软件测试越来越受到重视，敏捷测试是软件测试的重要组成部分，本文尝试基于Scrum开展敏捷测试应用进行概述。

1 敏捷测试概述

敏捷开发模式正处于逐步推广阶段，具有较大的发展潜力。现代经济生活中，很难甚至无法预测基于计算的系统如何随着时间的推移而进行演化，市场情况瞬息万变，最终用户的需求也在不断变化，新的竞争危险也毫无征兆的出现，故对于轻量级的软件开发而言，需要不断变化，以应对以上软件开发问题。敏捷开发以人为核心，迭代，循序渐进，拥抱变化是其基本动力。

敏捷过程有以下要点：

（1）通过频繁迭代与客户形成早期良好合作，及时反馈提高产品质量；

（2）客户、需求人员、开发人员进行有意义频繁的交互，以及早发现问题；

（3）衡量功能实现的唯一标准是该功能的开发测试已完成，并测试通过。

敏捷测试以沟通、简单、反馈、勇气、尊重为核心价值观，在敏捷软件开发过程中开展的测试便可称为敏捷软件测试，测试人员适应变化，与技术人员、业务人员进行良好的协作，立即测试记录需求、驱动开发思想。敏捷测试法继承了敏捷软件开发原则，作为一个优秀的敏捷测试人员，需要遵守以下原则：提供持续的反馈，为客户创造价值，进行面对面的沟通，勇气，简单化，持续改进，相应变化，自我组织，关注人，享受乐趣。敏捷测试不仅仅是测试软件本身，而是包括软件测试的过程与模式，敏捷测试的目的是为了尽可能使功能与客户预期一致，确保开发、管理过程正确。敏捷测试人员需要参与所有的团队讨论与决策，测试人员需要开展更多的与测试无关，但与团队目标直接相关的工作。

相较于传统的测试，敏捷测试与开发并行，甚至优先于开发，测试团队也是开发团队的一部分，除却绝对的必要，工作软件即是文档，及时应对变化参与所有的团队会议、团队决策，极力促进团队沟通、团队与客户沟通。

2 基于Scrum的敏捷测试

Scrum是当前应用最广泛的敏捷开发方法，过程清晰有效，适合敏捷经验不足的团队使用，以下就此进行概述。

2.1 Scrum过程

Scrum过程包含三个过程：

（1）设计计划与体系结构，即将产品功能需求、缺陷、更新用户需求等待开发项，作为优先级排成等待开发项目，然后根据列表，进行风险评估，制定产品交付规则。其次，需建立体系结构，将待开发的项目分解为一系列的“问题包”，每个问题包包含一组对象集合，再将问题包按照同样的原则划分为迭代小组，在此基础上，团队建立独立的开发测试运行环境。

（2）迭代过程，包含多个迭代，每个迭代都对应相应的时间段，通常而言，一个迭代周期为2-4周，每个周期结束后开始下一个周期，每个迭代周期都需要相应的设计、测试、编码活动，每个迭代结束后，都需要完成计划内的待开发项目。

（3）交付过程：当开发产品经风险评估后，边可以进行验收测试，进入交付阶段，组装项目组，系统测试、回归测试，完成最终文档等步骤。在基于Scrum过程开发过程之中，需要达到风险评估标准才能停止开发，交付过程的最终目的在于是否在迭代过程中出现被忽视问题，为下一阶段的开发做准备。每次迭代，订单订单项不允许修改。

2.2 Scrum测试管理

（1）需要做好人员的配置，按照与项目的关系，将人员分为实际参与人员以及项目组外人员，包括经理以及最终用户等，前者主要包括管理者、产品负责人与团队，Scrum管理者不是项目经理，由能力较强熟悉Scrum成员承担。产品负责人是指一个角色，来自于用户、客户、销售部或开发部门的需求分析者，易于协作、沟通，具有代表性，有一定的授权，熟悉需求。

（2）需明确测试角色，软件开发工程师复杂编写代码，完成白盒、黑盒测试、单元测试。自动化测试工程师需要负责测试脚本、工具代码。测试工程师需要了解产品需求、编写测试案例、追踪产品，客户负责验收。

2.3 Scrum测试模型

Scrum测试过程中，做好需求分析、分解测试的需求，及时与研发产品人员沟通的是关键。测试的一阶段，需要根据软件设计、需求，完成确认对所需要使用的测试工具，包括需求管理工具、测试案例、缺陷管理工具等，大规模公司可开发适应本公司的管理工具。在迭代阶段，每个迭代周期结束前，都需要提交方针，测试该周期或上个周期完成功能，以评价开发功能是否达到预期。

2.4 Scrum测试过程管理

首选，需要编制Scrum下的测试计划，以文档形式呈现，对整个测试过程都需要有相应的测试计划书，每个迭代阶段计划书都有相应的功能性文档修改。

计划书需要突出以下几点：

（1）产品的基本信息，记录Sprint各个阶段测试情况与结果，开发测试所有角色任务列表；

（2）确认测试计划包含的测试范围，根据新开发的功能及其相关的原有功能，需要定义划入测试产品功能，进行冒烟测试；

（3）划分测试阶段、明确方法与任务。在每个测试过程中，都需要有计划书、案例，测试过程中需要提交缺陷至相应的管理系统，在测试过程中需要明_监控测试的方法，搭建测试环境，评估进度计划风险，安排测试时间。

3 小结

基于Scrum的敏捷测试非常适合小型软件开发企业，容易上手，但作为一种科学管理方法，想要完整的掌握也有一定的难度。软件开发企业需要与时俱进，掌握该方法的精髓，即重视迭代管理、团队协作，勇于创新。

参考文献

[1]杨娜，严振亚.基于Scrum方法的敏捷测试探讨[J].数字技术与应用，2017（01）：51-53.

[2]张晓静.敏捷测试在移动App开发中的研究与应用[J].电子科学技术，2015（02）：211-213.

[3]孙笑，张小晶.Scrum敏捷测试――从敏捷测试中寻找发展机遇[J].科技创新导报，2014（25）：255.

[4]曹栋.敏捷测试在银行IT领域中的研究与分析[J].电子技术与软件工程，2014（16）：98-99.

测试团队工作计划第2篇

关键词：软件测试；测试管理；测试工具；Quality Center

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

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

借助工具，可以使测试管理可视化，协助测试顺利进行。在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.

[4]http：//

测试团队工作计划第3篇

1引言

 

近几年各高校的软件开发团队参与学校信息系统开发的比例不断下降，开发出来的信息系统没有经济价值或使用价值。甚至有些高校信息化当中软件开发面临着严重的生存危机。高校虽然有优秀的人才队伍和研究基础，但比IT企业缺乏管理经验，在软件开发过程等方面没有统一的规律可言。因此如何建立符合高校的软件开发方法，使软件开发变得更有效率，如何让高校软件开发继续在信息系统建设当中起重要作用，是目前高校信息化部门面临的重要问题。

 

2敏捷开发方法研究

 

2.1了解敏捷方法

 

2001年Kent Beck和其他16位知名软件开发者、软件工程作家及软件咨询师共同签署了“敏捷软件开发宣言”。该宣言声明：个体和交互胜过过程和工具;可工作软件胜过综合的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。也就是说，虽然传统开发方法中的一些文档信息很有价值，但敏捷更看重沟通、可运行软件、客户以及灵活性。此外参与这次宣言的人描述了12条关键原则，即敏捷的关键在于持续地交付可工作的软件，同时也允许和支持不断变化的需求，它鼓励各种项目关系人的相互沟通，改变协作的态度，把客户作为开发组成员，并意识到不确定的世界里计划是有局限性的。

 

2.2敏捷过程研究

 

采用措施方面敏捷方法是从传统的工作分解结构到基于优先级实现故事(在敏捷方法中软件增量称为故事)和需求的“以交付价值为中心”的转变。

 

管理文化方面敏捷方法关心的是团队责任和团队活力两方面，目标是如何在规定的时间框架内完成尽可能多的工作。

 

需求、架构和设计方面敏捷团队所投入的时间和资源不太多，相反团队的大部分注意力集中在尽早交付可集成的有价值的需求模块。

 

代码构建方面敏捷团队首先集中精力解决最高优先级的功能模块。

 

质量保证方面测试不再是生命周期的一个阶段，而是持续的行为，测试人员的主要工作是系统测试，他们关注的是自动化测试。

 

规划方面敏捷方法采取的是制定整体规划和为迭代制定的细致规划。在开发过程中并不仅制定一次规划，在每次和每次迭代的前期都要进行规划。

 

敏捷方法是固定时间并且根据时间定义范围，所以只有一个变量保持不变，即构建的范围不变。这就使团队能够自由地根据需要进行组织，将精力持续集中在到期需要完成的软件增量上。

3敏捷开发方法在高校软件开发中的实践

 

3.1高校在软件开发方面所面临的问题

 

(1)很难建立过程管理机制

 

建立有序的软件过程管理机制需要很大成本投入。目前，高校软件开发中普遍存在的问题是项目不够大，开发人员少，开发出来的软件质量低。在这种情况下学校很难下决心改进高校软件开发过程机制，虽然认识到软件开发的必要性，但只是采取观望的态度。在高校，技术理论领域的人才是充足的，但管理领域的人才却甚少，特别是在软件过程管理领域有经验人才非常有限。

 

(2)很难实行项目管理

 

由于高校信息化部门的组织结构的特殊性，开发团队只能是临时组建。而且管理者也没有专门的软件项目管理经验，对项目管理的指导效果不明显，大部分情况是主开发者充当项目经理角色。由于主开发者的管理视野非常有限，同时没有所依靠的过程管理机制，只能在开发者的角度分析问题，很多项目管理问题很难及时解决。这种情况通常导致混乱级别的软件项目管理，项目成功的可能性比较少，所开发出来的软件质量不能保证。

 

(3)很难保持沟通的有效性

 

由于高校的项目不够大，而且人员有限，一般情况下开发者独立完成从需求到部署的全部软件过程。开发人员通常担当多种角色，所考虑的部分比较多，当然需要沟通的问题也不少。但是没有团队开发意思的高校软件开发环境中，互相之间的沟通和协作是完全不可能的事情。

 

因此，利用敏捷开发寻找一个平衡点，用柔性方法管理软件项目的整个进程，巧妙地平衡短期利益和长期利益，用尽可能少的时间来完成尽可能高质量的软件。

 

3.2敏捷软件开发方法在高校软件开发当中的实践

 

在高校软件开发中实践敏捷方法时要考虑一下几个方面内容：

 

(1)由于高校软件项目规模比较小、开发人员有限等特点，开发团队临时组建的情况比较多。敏捷开发中鼓励重构开发团队，而且要求必须有3个角色：产品主管，作为客户并制定解决方案;开发成员，能够创建高质量的代码;集成测试人员，测试自动化和QA功能。敏捷开发中，高效团队的特点是：团队中有合适的人;团队是被领导，而不是被管理;团队了解他们的任务;团队不断进行交流和合作;团队对自己的工作结果负责。

 

(2)开发计划是有序软件开发的前提，但开发计划是随着时间不断变化的。长远的详细的开发计划书对大部分高校项目中作用不够明显，反而他们需要的是短期的灵活的实施计划。敏捷方法有两个级别的计划。级计划是对主体和高级别特征的概述;迭代级计划是更详细的计划，一般把目标划分成了一些小任务，不会超过一两天。合起来看这两个级别计划提供了长远和短期目标，为敏捷方法的有序实践提供前提。

 

(3)在高校软件开发中很少有专门的测试人员，一般都是代码构建人员直接进行测试工作。这种开发模式接近敏捷开发的迭代过程。在敏捷团队中，开发人员要有在短的时间盒内创建一整套的测试和工作代码的能力，即迭代开发能力。

 

(4)在敏捷方法中提高软件质量的一种方法是更小、更频繁的。通过频繁的，让客户体验新的软件增量，持续获得来自客户的反馈。敏捷团队通过这些反馈意见进行下一轮的迭代开发。

 

(5)高校软件开发项目规模不大等特点，使持续的集成变为可能。敏捷开发通过持续的集成，持续的发现问题，持续的重构代码，持续的降低风险，结果使代码质量得到持续的改进。

 

(6)在敏捷宣言的重要原则之一是“团队应定期反省如何能够更有效，然后相应的调整和调节其行为。”在敏捷方法中团队要清除其持续提高生产力的障碍。具体方法是对迭代级别和级别的计划进行定性和定量评估。

 

4结论

 

敏捷软件开发方法已经在很多领域取得明显成就，因它自身的有效性，在软件开发方法中已经成为发展趋势。而且目前的高校软件开发情况很适合于比较灵活性的开发方法。在高校软件开发中应该根据实际情况，运用敏捷原则来有效的权衡时间、人员和成本，使软件开发变得更加敏捷、更加高效。对高校软件开发团队来说，实施敏捷方法的所有必备条件不是很难实现的，而且很多条件是已经具备的，重要的是怎样把敏捷思想应用到实际的开发当中，并持续的锻炼这种思想，使这种敏捷思想成为主导软件开发的重要哲学。

测试团队工作计划第4篇

敏捷开发强调以人为本，认为面对面沟通是软件项目成功的一个重要因素。

当我询问一个研发经理关于敏捷开发所需的工具时，他开玩笑地说，一张白板和两杯咖啡。这也反映出开发人员对于敏捷方法的普遍认知。

事实上，许多开发项目主管虽然认同敏捷开发所强调的快速反应和沟通的理念，却担心它的“杂乱无章”带来的“不安定因素”。因为它极度地强调人的因素，使得人员的素质对敏捷团队的影响，远比对其他团队更大。

举例来说，配对检入是个保证代码质量很好的方法。但编程人员不了解其重要性，可能为了进度，常常一个人草草就检入了。因此，在采用敏捷方法时，若能适当地使用工具来保存累积的知识并固化关键过程，必能使敏捷项目更加成功。我们试以敏捷开发的几个主要特点为例，探讨工具在敏捷开发中扮演的角色。

特点一:测试驱动开发

传统的瀑布方法先编码再测试，等到发现需求和设计上的问题，为了节省费用，常常不了了之。测试驱动开发是在需求产生后，设计模块和其之间的接口，并将单元测试代码完成。在此过程中，需求和设计上的偏差将会被发现。由于编码尚未进行，只需更改需求和设计即可，避免造成太大浪费。

特点二:简单设计

敏捷开发崇尚简单的渐进设计，而不是剧烈的颠覆式设计。其目标是首先只设计我们所了解的那些部分，然后使该设计随着时间的推移而逐渐改进，这有助于提高灵活性并将变化导致的成本最小化。

特点三:配对编程

尽管两人一组的配对编程从理论上看使眼前目标和长远目标都得以保证，这却是敏捷方法中备受争议的做法，反对者普遍认为它会导致耗时加倍。广义的配对编程也包括前面提到的配对检入(Pair Check-in)，也就是由两人一起检验代码的正确性，然后才检入。

特点四:小型

周期短可使对项目的评估提前，进而降低了风险性。但这所带来是大量的可执行文档，造成管理上的困难。

工具所扮演之角色

现在让我们以一个典型的敏捷团队DevAgile为例，看看该如何用工具实现其敏捷过程和设想（图1）。Smart先生是DevAgile团队的项目经理，他被要求在开发过程中体现我们以上所列的几方面特点，在配对编程方面还要求配对检入。

图1 工具对敏捷开发的支持示例

角色1:需求管理的利器

对项目需求和设计文档的管理是DevAgile必须首先面对的问题。他们要完成的，恰恰是一个需求变更很快的项目，这也是他们选择敏捷开发的重要原因。在敏捷开发中，需求的变化常常是为下一次迭代提供信息和进度计划的依据。

因此，DevAgile的大多数成员认为，记录下每一次关键的需求变更很重要，尽管最初有些人坚持敏捷开发并不需要文档。

同时，他们也注意到，要遵循简单设计的原则，并非意味着设计文档不需管理。相反，文档的数量和版本都会比采用其他开发方式更多。这些设计文档及其历史应该被妥善地管理，也要和相对应的配置项链接。

另外，小型意味着整个生命周期中有更多的，如何对这些进行系统化管理也是DevAgile团队必须解决的问题。

综合以上这几点考虑，Smart先生认为，应该找到一种需求管理的武器。DevAgile团队在进行了一番市场调研后，决定尝试TechExcel DevSpec这种需求管理工具。它不仅提出“以知识为核心”的概念，满足需求和设计文档管理的要求，还实现了真正的“功能驱动开发”。

尽管DevAgile目前没有清楚的看到后者如何实现，但DevSpec对产品需求、产品功能及知识文档的系统管理还是吸引了他们。

它成全了设计团队的敏捷性，支持简单设计，并对他们经常修改设计的做法提供了管理上的帮助。一些成员还指出，在敏捷开发的道路上，太多的不确定因素和灵活性难免会影响大家对最终产品的认识，有一个这样的工具能够时时刻刻描绘出要产品的清晰轮廓，记录下产品需求和功能变更的每一步，实在是很令人欣慰。

另外，为了配合数量多的小型，DevSpec还有整理功能点的能力。也就是说，将和某一有关的新功能、功能变更，以及缺陷修复，全都进行统一组织和管理。

例如，要完成6.1的，他们只需把6.1功能文件夹里所有的新功能、功能变更，以及缺陷修复全都做完，6.1版本也就可以了。为了更大程度上提高开发效率，Smart先生还别出心裁的对这些功能及缺陷设定了优先级，优先级低的任务可能被延缓执行。实践证明，这种具灵活性且针对来管理的系统使小型越发容易。

角色2:项目规划的利器

Smart先生发现敏捷的项目管理要能做到随机应变，应付各种可能出现的情况，也是建立在对任务的细分，并对任务的状态采取高频度的探测并及时调整的基础上。DevAgile选择了TechExcel DevPlan作为项目规划工具，因为它能够围绕DevSpec中管理的功能点进行迭代计划，对人力资源进行管理，既把握了正确的宏观方向，又能对任务细分。任务若被耽延，还可以反馈回来。

Smart先生认为，作为敏捷团队的项目经理，他应该从传统项目经理的“工头”身份中解脱出来，发挥他的领导力，去监控和协调开发过程。虽然项目经理还是必须定义和初始化项目，作项目计划，执行计划，监督并控制结果。

但是完成这些步骤的方式却是不同的。具体来说，敏捷项目的计划不再是详细的完整的项目实施步骤和资源分配，而更多的表现为一种迭代计划。在开发人员与客户或其他团队沟通的每一次迭代中，计划和资源分配随时可能被调整，以不断适应项目进展的需要。在DevPlan的帮助下，这种调整变得方向明确、清晰和有据可查。它将每一次迭代的框架确定下来，剩下的工作就是根据这个框架实施了。

角色3:测试管理的利器

有了DevPlan，测试计划和开发计划开始制定，项目在一种既有序又敏捷的机制下运有序地转着。为了实现“测试驱动开发”，DevAgile不可避免的遇到了测试管理的问题。他们注意到，需求管理工具DevSpec内的需求，可被直接导入测试管理工具TechExcel DevTest，并自动生成测试任务。所有测试任务可以遵照既定的工作流执行，保证测试工作的有序开展和管理，并在编码之前发现设计偏差。

另外，他们以往是用光盘来存储可执行版本，文件柜的每一个抽屉里都装满了光盘。在进行敏捷开发以后，光盘的数量更是与日俱增，要找某版本的光盘时，多半是很困难的。

DevTest能够保存和管理的软件版本，而且和DevSpec内的功能及缺陷文件夹相对应。也就是说，若在需求管理工具DevSpec内有个6.1功能文件夹，那么在测试管理工具DevTest中也有个相对应的6.1文件夹。这显然比用其他方式来存储软件版本更加科学和方便。

角色4:任务执行的利器

有了以上这些项目管理的利器之后，DevAgile团队的工作并非一帆风顺，因为新的问题又出现了:一些成员片面的认为敏捷开发是一种松散型开发模式，也就是不需要遵守固定的流程。这直接导致了很多开发任务的执行效果糟糕，有些任务被提出以后就失去了踪迹，就连Smart先生也难以追踪每一个任务的结果。

于是，DevAgile团队又引入了与DevSpec和DevTest可以集成的DevTrack。这是一个开发任务的跟踪管理工具，提供既固化又可灵活更改的流程，对每一个任务的生命周期进行严格管理。它保证该走的过程一定走过;该反馈的一定反馈;该提醒的一定提醒;若任务需被升级，那就一定会被自动升级。更令人兴奋的是，当任务完成之后，其结果会自动返回需求管理工具DevSpec或测试管理工具DevTest。Smart先生可以轻易地由DevSpec看到针对6.1版本的所有功能和开发任务是否全部做完，对的管理省时省事。

直到实施了任务执行管理工具DevTrack，Smart先生才逐渐认识到由DevSpec引导的“功能驱动开发”是如何实现的。DevPlan中的迭代计划、DevTest中的测试任务和DevTrack中的开发任务，都是围绕DevSpec中的功能展开的。这不仅使整个敏捷过程都严格围绕最终产品进行，而且其中的可追溯性和可核查性，也正是敏捷开发思想的有益补充。

现在，当项目成员在会议室和用户讨论得热火朝天的时候，Smart先生可以悠闲地在电脑前喝咖啡了，他知道整个过程都是可以控制的，需求和设计变化再多再大，经历再多的迭代和小型，只要所有功能都按照计划被开发和测试，项目还是会如期完成。

敏捷团队的成功案例总结

毫无疑问，DevAgile团队最终用敏捷开发方式取得了项目成功。让我们再来总结一下，他们是如何具体做到的呢？首先，需求被搜集和整理，产品功能和简单设计产生，将这些结构框架和相关文档存入DevSpec之后，开始制定迭代计划，并定义模块接口。紧跟着，针对接口做出测试代码。这些知识文档全由DevSpec来管理，因此DevSpec中形成了由需求、功能和知识文档组成的“概念产品”。

最后，功能点被导入DevTest而产生一个或多个测试任务，每一个测试任务都能按照DevTrack中定义的工作流（图2）进行。

图2 DevTrack中定义的测试任务工作流示例

图2的工作流被启动之后，编码人员在第一状态负责编写代码、重构和白盒测试。项目经理为了实现配对检入，把第二状态设为需有A和B两人一起检入的“配对检入”。每一个状态都有明确的负责人。A可以是第一状态负责人，而与A配对的人员则可以是跟A 所做的任务有关的人员。第三状态负责人可以是测试人员，在单元测试成功后便完成了整个流程。反之，则重新回到第一状态。

以上的案例中，对所提到的四个敏捷特点都有所注解。当然，这是一个可行的方案，而绝非唯一。

另外，面对面沟通也是个很好的敏捷操作，但是实际上却不易实现。客户或熟知商业逻辑的同事通常是无法长时间和开发设计人员在一起工作的。若一定要面对面，很可能会以高昂的费用为代价。更实际的方式是通过一定的沟通平台（如一些即时语音或视频通讯工具）来达到类似面对面的沟通。

无论采用何种方式，沟通后的结果都要能妥善地记录下来。知识的分类和历史的记录会使清晰度达到最高，进而使后来的一切活动，包括编码、测试、分析等，都变得容易。

测试团队工作计划第5篇

关键词：敏捷开发 Scrum 敏捷测试

中图分类号：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.

[2] 陶凌燕.基于Scrum的敏捷软件测试模型研究与应用[D].华中科技大学，2011.

测试团队工作计划第6篇

关键词：软件工程；教学改革

软件工程是一门综合性程度高、知识面广、实践性强的系统学科。开设软件工程学科的目标，是为了培养具有工程能力、综合素质、扎实专业技术基础、良好团队协作能力及职业道德的复合型人才。

一、教学现状

学生因缺乏项目实施经历，在软件工程课堂内并没有体会，到了工作岗位，经历几年实践，才会对软件工程学有领悟。软件工程入门要求较高，学生在前期必须掌握程序语言、数据库技术、开发工具、系统平台等，如何针对不同专业方向的学生开展教学工作是一个巨大考验。本文改革涉及教学内容与学生工程能力评定、教学实践等方面。

二、教学改革探讨

1.教学内容与学生能力评价体系：根据美国计算机学会制定的软件工程学科要求，掌握软件工程理论的最小子集包括软件过程与生命周期模型、需求分析、软件设计与进化、测试与评估、项目管理、软件工具和环境。现有的教材，极少在一本教材上对上述内容进行全面覆盖。按照上述教学内容，对学生在实践项目中的表现做出如下能力等级认定。1.1软件过程与生命周期模型1。软件过程定义包括项目类型定义、项目规模定义、项目风险识别、项目文档的规范模板。根据需求类型、项目风险、项目类型、用户类型、团队类型进行项目生命周期选择。分为如下5个等级：1.1.1理解软件过程流程图，理解风险识别与分析活动，理解常见软件生命周期模型；1.1.2根据教师提供的项目生命周期模型选择表，从瀑布型、迭代型、增量型模型中做出选择；1.1.3选用适合的标准过程文档模板，包括过程管理类、项目研发类、项目管理类，并采用svn等工具对文档进行版本控制；1.1.4理解风险管理活动，确定风险来源，识别风险，确定风险优先级别，建立风险行动计划，跟踪风险；1.1.5分解工作任务，制定完整的项目计划书，采用project、Git等工具进行跟踪管理。1.2需求分析与需求管理2。包括开展需求调研活动，理解用户需求，产生《用户需求说明书》。进行需求分析与定义，形成基于UML建模的产品需求规格说明书。对《产品需求规格说明书》进行评审与确认。需求管理内容包括对《用户需求说明书》、《产品需求规格说明书》进行评审。需求管理员建立与维护《需求跟踪矩阵》，确保需求一致性。需求管理员建立和维护需求跟踪矩阵，管理需求变更。根据上述知识范畴，分为如下5个等级：。1.2.1理解用户需求，理解需求规格说明书内容；1.2.2通过访谈、调查、网络收集、同类类比、征询建议等方式进行需求调查，形成《用户需求说明书》；1.2.3采用UML用例图、活动图、顺序图等方式进行建模，形成符合模板的《产品需求规格说明书》；1.2.4能识别需求描述不一致、有二义性的地方，根据需求检查单确认；1.2.5能根据需求跟踪矩阵，按照已建议、已接受、已分析、已实现、已验证需求项的状态来跟踪管理，在系统设计、编程、测试等阶段对工作产品进行跟踪，更新和维护《需求跟踪矩阵》。1.3软件设计与软件进化4。可通过强调设计规范、增设设计模式内容，以极小易懂的程序为出发点，通过持续改进，让学生理解版本改动的原因，会评价一个设计的好与坏。分为如下5个等级：1.3.1理解软件设计活动，理解概要设计、详细设计、数据库设计方案；1.3.2理解面向对象方法设计原则，能用UML类图表达设计；1.3.3根据需求文档，能产生实体-联系图，将实体间关系转化为表间约束，尽量优化表结构；1.3.4能够基于复用、可维护的考虑，进行一定程度的软件重构；1.3.5撰写数据库设计、概要设计说明书，执行设计规范、编程规范。1.4测试与评估。制定测试计划，编写测试用例，规定输入与预期输出结果、测试步骤。执行测试用例，进行测试分析，形成测试报告。分如下5个等级：1.4.1理解需求，编写系统测试用例，合理运用等价类分析、边界值分析等设计方法；1.4.2理解设计，编写集成测试用例和单元测试用例，能搭建测试环境，手动执行，并记录测试结果。理解缺陷管理，发现缺陷，填写测试报告并执行回归测试；1.4.3能使用自动化测试工具，编写测试脚本，运行脚本执行测试，将发现的问题进行报告。使用Bugfree等工具管理和维护缺陷，确保项目提交时，缺陷的状态均为关闭；1.4.4能使用大型测试管理工具进行测试计划、测试管理、跟踪需求、设计等变更对测试的影响；1.4.5采用工具进行性能测试、安全性测试、压力测试等方面，能够进行测试场景设计、脚本编写、执行和报告。1.5软件工具和环境。工具包括建模工具、开发工具、测试工具、配置管理工具、项目管理工具等6。分为如下3个等级。1.5.1在工程类活动中采用建模工具、开发工具、测试工具；1.5.2在管理活动中采用配置管理工具、项目管理工具进行项目策划、风险监控、项目监控活动；1.5.3能够根据团队人数和项目情况，选择适合项目特点的工具。1.6项目管理。强调人员、产品、过程、质量的关系，包括项目策划、项目跟踪与监控、项目风险与管理、软件质量保证、项目配置管理等。分为如下2个等级：1.6.1理解项目过程管理，定期召开例会，编写个人周报，会议纪要，进行问题追踪，坚持执行规范；1.62理解项目立项策划、项目监控、风险及结项管理，并从团队实践项目中进行组织级总结。上述六个关键内容上，不要求学生在每个活动上能力认定都达到几，可通过每个关键活动上分别评定，最后计算加权平均值的方法，折算学生的最终成绩。2.教学措施。避免一言堂式教学方式，创造引导和探讨式、学生自启发式教学模式。可采取以下措施：2.1教学采用小班制教学，学生分为三五人制团队，自我管理和团队合作完成实践项目。2.2引导学生自拟实践题目，协助定义软件过程，协助制定软件进度计划，并提供软件标准文档模板和工程标准规范。2.3引导学生在每周召开例会，完成对项目跟踪追溯。例会的内容可加入软件技术的规范、风险意识的培养和训练、软件文档写作等内容。2.4教学案例可选用一般信息管理案例讲述，项目知识不宜超出学生认知范围。2.5专家来访，引入课堂。营造良好的学习氛围，企业工程师与学生分享和交流工程应用、企业管理方面的最佳实践和教训，培养学生工程意识。2.6结合学生不同专业方向，对实践案例做出选择。软件测试方向重在理解需求、掌握软件测试工具、软件测试管理工具、自动化测试、性能测试工具和测试报告写作。嵌入式方向重在嵌入式平台使用、设计模式、UI设计、UML与软件设计、手机客户端和服务器设计实现、嵌入式数据库应用方面。游戏设计方向重在游戏策划、工程标准和规范、游戏引擎工具、项目管理工具、版本控制工具、游戏测试等方面。2.7启发学生学习新技术，包括大数据、交互设计、CMMI能力成熟度模型及标准。

三、结语

本次课程改革集中在教学内容、教学措施、能力认定等方面。软件工程课程改革是一个长期和持续过程。在实施中取得的成效值得我们不断思考和总结。

参考文献：

[1]方智.面向对象编程思维的建立和培养[J].实验科学与技术,2013年06期.

[2]张海藩.软件工程导论(第6版)[M].北京：清华大学出版社,2013.

测试团队工作计划第7篇

 

 

0引言

 

如今，软件产品被广泛应用于各个领域，如航空、机械、电子产品等，软件产品质量成为软件开发中重点关注的方向。在一些对于安全性要求较高的领域，对软件产品的质量要求更高。例如，在2011年温州发生的7.23动车追尾事故，导致212人伤亡;1996年阿里亚娜5型火箭发射39秒后爆炸，直接经济损失3.7亿美元;2002年首都机场电脑系统出现故障，导致6000多人滞留机场等。软件中存在的缺陷是造成这些严重后果的根源。因此，软件测试的重要性不言而喻。

 

传统的软件开发流程越来越无法满足当下软件需求的频繁变动，如传统的瀑布模型，测试人员在一定的控制点之前不能测试，所以在此之前无法找到缺陷。等到所有开发完成，即过了该控制点后再进行测试，缺陷数量会急剧增加，同时任何缺陷的修复都需要对一连串代码进行变动，修复时间难以确定，软件迟迟不能，损失将难以估量。

 

敏捷软件开发是基于一种更接近人类活动现实情况的方法论，采用以人为本、迭代、增量的开发过程，逐步满足软件不断变更的需求[1]。敏捷主要提倡个人为团队所作的贡献，注重各个职位的权利下发，发挥个人的主观能动性，保证随时都有可供交付的软件产品。敏捷开发更容易在项目早期控制缺陷数目。软件测试是保证软件质量与可靠性的重要手段，敏捷开发能充分发挥软件测试的重要作用。

 

1敏捷开发思想

 

敏捷开发是以用户的需求进化为核心，采用逐步迭代、循序渐进的方式进行软件开发。在敏捷开发模式中，软件项目在开发前，先将整体项目切分成多个子项目，迭代过程中根据需要可以对子项目进行拆分或同时进行多个子项目，每一个子项目都要经过测试，保证项目能运行成功。换言之，就是把一个大的软件项目分成许多小项目，每个项目独立完成，但相互之间又有联系，在该过程中软件始终处于可用状态。

 

敏捷开发本身更多的是一种概念，它是一种循序渐进的迭代开发方式，强调团队成员间的沟通。2001年，敏捷开发创始人了敏捷宣言：个体和交互胜过流程和工具，可用的软件胜过完备的文档，客户协作胜过合同谈判，响应变化胜过遵循计划[2]。也即，虽然后半部分的条目也具有价值，但是更看重前半部分的条目。他们希望这将成为成功的软件开发的基础。敏捷开发的方法很多，主要包括快速应用开发(RAD)[3]、极限编程(XP)[4]、动态系统开发方法(DSDM)[5]与Scrum[6]。本文构建的测试模型借鉴敏捷开发过程中的迭代思想，以渐进的方式完成测试工作，不仅可使测试工作具有更好的灵活性，同时也能更好地适用于现有的敏捷开发过程。

 

软件是一种非常特殊的产品，开发出的软件通常会存在一些缺陷，而有些缺陷会造成非常严重的损失。软件测试则成为保障软件质量的一种重要手段[7]。根据不同标准有多种测试方式，如集成测试、单元测试、系统测试、验收测试和回归测试。传统的V测试模型和W测试模型成为指导人们进行测试的方法，而不同于这两种测试模型的H模型，则强调测试的独立性。另外目前很多开发团队已经开始使用敏捷开发方式，敏捷开发方式非常注重客户的交互以及团队中的沟通，同时开发过程中会有许多迭代过程。本文提出的测试模型借鉴敏捷开发中的迭代思想，测试流程是一个渐进的过程。然而，即使有成功的敏捷开发方法，开发人员和测试人员依然要寻求最适合的敏捷方法，并将相关技术融入到自己的敏捷方法中。

 

2敏捷开发中的软件测试

 

2.1敏捷测试

 

敏捷测试没有已经确定的唯一定义，原有的测试定义“通过在规定条件下对程序进行操作，发现错误，衡量软件质量”仍然适用，核心思想可以理解为“遵循敏捷开发的宣言，接纳敏捷核心价值观，基于敏捷开发的软件测试”。敏捷开发宣言中提到敏捷开发的4个核心价值观：简明(Simplicity)、沟通(Communication)、反馈(Feedback)、勇气/决断(Courage)。符合敏捷核心价值观的测试实践活动都可以称为敏捷测试，敏捷不仅是一种过程，更多的是一种理念[8]。

 

2.2敏捷测试方法

 

图1为敏捷开发测试流程，此流程是一个结合了Scrum和XP方法，并加上一些基于计划性流程原则后的产物。虚线箭头两端是开发过程中与软件测试相关的部分，敏捷开发的测试人员全程参与完整的迭代开发。

 

(1)需求分析：测试工程师可以根据测试经验以及需求的测试难度对需求列表提出问题或意见，以期团队能共同提供建议或方案，在之后的实际测试过程中有助于提高测试效率。

 

(2)迭代计划：包括对需求的详细分析以及任务表等，软件工程师和测试工程师对需求进行讨论。

 

(3)迭代启动会议：项目经理、产品经理、软件工程师、测试工程师对此代计划进行讨论、完善。

 

(4)测试计划：测试工程师根据需求以及测试经验完成详细的测试计划书，团队对测试计划进行研讨并确认验收测试。

 

(5)测试驱动开发：测试工程师相当于软件的第一批用户，测试过程中要重视反馈，这也是敏捷开发的原则之一。

 

(6)验收测试：测试工程师对此次迭代的所有功能进行演示，测试产品功能是否合格。如果产品合格，则此次验收通过，可以进入下一环;如果产品不合格，则此次验收失败，重新返回开发阶段，找出失败的原因及bug并解决，并确认下一次验收测试。

 

(7)提交与验证：由测试工程师为产品负责人与参与项目的人进行演示，包括此次迭代的主要功能、产生的未解决bug，然后由产品负责人核准迭代成功。

 

(8)迭代后的研讨：对此次迭代过程中产生的问题进行讨论，对于亮点可以进行表扬，错误要分析原因。

 

从流程图和测试人员参与项目的简单描述中，可以总结出敏捷测试的方法主要有两种：与传统软件测试相似的测试和测试驱动开发(TDD，Test-DrivenDevelopment)。

 

图2展示的是测试驱动开发流程，开发人员在编写产品代码之前，要先编写单元测试代码，在进行单元测试后才能进行产品代码的编写，以保证产品代码能完全符合要求。产品代码编写完成后进行单元测试和集成测试，测试代码和产品代码都要进行代码审查，保证代码的简洁、统一，方便以后维护。在敏捷测试中，测试驱动开发的重要目的不仅仅是测试软件，同时在开发过程中帮助客户和程序员确定需求。测试驱动开发应该运用于每一个迭代中，逐步开发完成所有软件功能。

 

传统软件测试的种类非常多，在敏捷测试中应当根据当前迭代的需求进行测试[9]。某车削软件有这样一个需求，能支持直径40mm的刀具路径生成。该需求一定配备了相应的刀具路径生成方法，然后只需确定刀路生成中的一些参数，然后设计数量足够的不同表面形态的圆面即可。由于TestPart数量过多，可能会用到自动化测试，也有可能会用到一些特殊的TestPart，如圆面面型变化大，甚至不是圆面等。迭代最后一定有整体的性能测试，在整个项目进行过程中，传统的软件测试方法同样适用于敏捷开发。

 

2.3敏捷测试特点

 

在瀑布开发模式中，要求流程规范、文档齐全，测试进行时再根据软件需求总结、测试所有功能点，直到软件中没有明显bug。在传统的软件测试开始时，软件的缺陷会达到顶点，同时如果有需求变化，则需要重新编写文档，可能必须将之前的工作推翻重来，费时费力。而在敏捷测试中，一切都发生了改变。

 

敏捷开发模式中测试不是一个单独阶段，它和编码一样是软件开发的重要组成部分。敏捷开发使用一个“完整团队”的方法来保证软件产品质量。敏捷团队中的测试人员从客户需求中提炼要求，然后与开发团队合作，把这些要求变成可执行的规范，用于指导代码编写。随着测试和编码的逐渐进行与交互，将建立一些产品特性，直到提供足够的产品价值。

 

敏捷测试包括以下几个主要特点：①周期性的迭代开发方式。不同于传统测试的一次性集成或功能测试，敏捷测试在迭代进行过程中要通过及时响应客户反馈来修正软件测试策略，以此修正软件的质量指标;②每日立会，密切沟通。传统测试提供了大量文档描述产品需求，并通过文档进行测试。敏捷测试则需要团队每天进行交流，测试人员与客户持续沟通，以保证产品质量符合客户预期，并与开发人员沟通来确定需求认识的统一;③测试方法多样，贯穿整个项目开发过程。敏捷测试包括测试人员对软件的自动化测试、集成测试、功能测试等，还包括开发人员对代码的单元测试、代码评审等工作，从最底层和基础的测试来保证软件整体质量;④确保客户需求圆满实现。客户需求是敏捷开发中最核心的内容，敏捷测试同样需围绕客户需求实现。

 

2.4敏捷测试优势

 

目前大多数软件项目的共同特点是用户需求变化快、风险高，同时还能快速抢占市场，这刚好是敏捷开发能够解决的。

 

(1)良好的持续沟通可减少缺陷产生，降低风险。在敏捷开发模式下，测试人员的沟通尤为重要。一个迭代从开始到结束，测试人员都需要参与。迭代开始时，所有人都要对该阶段软件的成型有统一认识，满足用户需求的同时还要符合一次迭代的时间要求;迭代进行中，测试对开发人员的反馈非常重要，软件开发初期，测试工具十分缺乏，对测试工作的进行造成很大阻碍，这时需要和开发人员持续沟通，必要时可共同开发一些辅助测试工具，在此期间要把握好迭代进行的时间;迭代后期，也可以作为bug反馈期，测试人员不但要站在用户角度考虑需求，同时能和开发人员站在技术角度讨论问题，达到沟通的目的。

 

(2)合理的测试用例。敏捷最直接的特点就是快速，如果涉及的用例粒度太细，很难开展敏捷测试。一个合理的测试用例不仅能包含所有可能产生缺陷的地方，同时还能快速地响应需求变化。

 

(3)更多人参与测试。敏捷测试中的测试人员不再是一个独立的测试个体，研发人员、产品负责人、用户都可以参与测试。研发人员的测试可以减少编程中的bug，产品负责人的测试可以更好、更全面地把握产品现状，用户的测试则可以提供来自真正用户的反馈，以更好地促进软件开发。

 

3敏捷开发中的软件测试实例

 

本章结合一个具体的软件项目，详细介绍项目中的敏捷测试。

 

3.1项目介绍

 

针对3轴超精密加工车床，提供针对光学自由曲面进行加工的刀路轨迹计算的CAM(ComputerAidedManufacturing，计算机辅助制造)软件。该软件的目标是比UGNX中的相同功能有更快的计算速度和更高的精度。

 

3.2需求分析和项目规划阶段

 

项目经理和产品经理根据客户给定的需求进行分类，包括框架、加工方式、加工质量、刀具选择、仿真等需求，并对项目可能产生的需求进行判断和规划，形成项目计划书。项目计划书包括项目背景、、需求以及预期完成时间。项目计划书完成之后即可开始进行第一个迭代，并以第一个迭代为基础不断进行下去，直到完成所有需求。由于整体项目过于庞大，这里只对第一个迭代进行介绍。

 

项目实例：第一个迭代中有2个需求，同时根据工作量分配任务天数以及每个需求的参与人员，如表1所示。

 

3.3迭代进行阶段

 

迭代开始时，项目经理制定迭代的具体开发任务和测试任务。在迭代启动会议中，每个人都要对此次迭代任务有统一认识，并且能够承载相应的任务量，在需求确定完毕后进行任务分配。

 

.

 

开发人员进行编码时，测试人员的工作重点包括：编写测试计划、测试用例、验收测试以及提交和验证。测试计划和测试用例的编写同时完成，且在迭代初期完成。验收测试一般是在迭代后期进行集成测试，迭代过程中也可以协助开发人员进行单独的功能测试。

 

3.3.1编写测试计划和测试用例

 

测试计划需要具体的操作步骤以及相对完善的测试用例来涵盖需求，因此需要测试人员有比较丰富的测试经验。

 

项目实例如下：

 

表2和表3中的TestParts需要填写测试工件名称。测试计划编写完成后要经过开发人员和项目经理确认，保证开发人员认同并能够达到计划的目标。敏捷开发是不断迭代的过程，对于一些比较简单的功能，尽量设计简洁的测试用例。如果TestParts比较多，可以采用自动化测试，而对于一些比较复杂的功能，可以先采用手动测试，在功能更加完善后再考虑自动化测试。

 

3.3.2验收测试

 

验收测试要严格按照迭代前期写好的测试计划进行，在开发人员开发完此次迭代所有功能后，测试人员对所有功能进行集成测试、功能测试、自动化测试等，完成所有测试工作后形成测试报告。报告内容包括此次迭代基本功能完成情况、缺陷产生情况以及测试过程中的一些详细数据。

 

3.3.3提交和验证

 

团队全体成员参加验收会议，由测试工程师对迭代成果进行演示，产品经理和项目经理进行验收，项目需求全部完成则此次迭代成功，然后再对此次迭代中的不足之处进行讨论和改进，或者提出创新之处。如果项目需求未达标，或产生了过多缺陷，则此次迭代不予通过，全员讨论延后验收或将缺陷完善延后到下一个迭代。

 

项目实例：针对需求R1、R2的基本功能测试达到了计划的标准，框架的视图操作和显示功能以及CAD模型输入功能均正常运行且无缺陷。虽然框架本身存在一些缺陷，仍能满足迭代的基本需求。经过讨论此次迭代成功，产生的bug在下一个迭代进行完善。

 

3.4迭代后研讨和下一次迭代讨论

 

迭代完成后要对迭代过程进行回顾，测试人员需要对bug进行总结，包括测试过程中产生的问题，以及需要改进的地方，然后对下一次迭代的需求进行初步讨论，决定下一个周期的工作内容。

 

4结语

 

敏捷开发中的软件测试应当遵循敏捷开发的基本原则，面对不同的开发方法和应用环境，软件测试方法也不同。敏捷测试作为从敏捷开发中成长起来的测试方法，与敏捷过程密不可分，本文对敏捷开发中的软件测试特点和方法进行了详细描述。然而，真正在面对软件测试时，测试用例的生成与覆盖标准、测试的充分性和有效性、不同阶段的测试关系等，以及如何将传统测试中的一些方法应用到敏捷测试中，需要探讨的问题及方法仍然很多。

测试团队工作计划第8篇

关键词：软件工程；网络课程；教学实践；Jazz

中图分类号：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.

[5]黄河笑,杨焕宇, 陈海建等.“软件工程”网络课程的设计与开发[J].计算机教育，2009(22)：93-96.

测试团队工作计划第9篇

[关键词]国电建投内蒙古能源有限公司布连电厂一期工程计划于2012年底投产，是国内首个660MW超超临界燃煤空冷机组，为实现国优工程建设目标，全过程实行精细化管理。

中图分类号：D905.2 文献标识码：A 文章编号：1009-914X（2015）05-0349-01

一、背景

国电建投内蒙古能源有限公司布连电厂地处内蒙古鄂尔多斯市，目前开工建设的项目包括年产能达1500万吨的察哈素煤矿项目和容量为2×660MW的布连电厂一期工程。其电厂项目于2010年7月31日开工，于2013年实现双投。本工程装机方案选择了超超临界，是国内首个660MW超超临界燃煤空冷机组，是2014年中国电力优质工程、国家优质金奖工程、国家节能减排示范电厂。

二、DCs全程实施的策划

按照中国国电集团精细化调试指导意见、中国国电集团精细化调试质量控制指导意见、国电绿色电站设计原则及项目公司精细化管理、创优管理的要求，国电建投内蒙古能源有限公司布连电厂将DCS的建设工作做为工程建设中的一个重点环节高度重视，用创新精细化手段做好本项目DCS的全程实施工作，这些工作包括：做好DCS的前期策划；抓好DCS联络会质量、深化联络会深度；大力重视DCS组态工作，提高FAT质量；引进专家团队，把控出厂质量；借助调试队伍，调试工作前移；采取中间点控制措施，加大重视程度，提高重视层次。通过这些工作的开展，使得DCS的建设工作取得了较好的效果。

三、做好DCS前期策划

本项目前期对DCS进行了大量的策划工作。这些策划工作包括：根据机组自动化水平的要求设计了全厂主辅一体化DCS方案；在现场不设计常规的灰、煤、渣、水区域操作员站和集控室；DCS机柜布置采用了分散布置方案，大大减少了电缆的设计量；综合考虑投资和运行因素将启动锅炉设计为DCS方案；根据本项目特点，采取了压缩DPU或者减少备件等各种被动的措施的情况出现；在合同中约定了调试提前介入DCS组态的方案，为调试关口前移做好了准备；在合同中约定了要求进行第三方技术支持的内容，为组态过程质量把控做好了准备；结合项目特点和工程管理特点要求DCS厂家提供RB、FCB、吹灰优化、壁温管理、单列控制、MCS优化控制策略等组态方案，将一些重点工作提前进行了策划安排；设计了基建期采取就地功能区l临时加装调试站的方案；考虑到单列系统特色和运行方式的可操作性，将FGD增压风机系统和低温省煤器系统纳入了主机DCS控制。

四、抓好DCS联络会质量、深化联络会深度

本项目在做好了DCS策划和招标工作之后，在实施阶段就坚持早着手启动、实施过程中不走形式重质量、深化联络会的内容和质量的工作思路。在签订合同后虽然距离本项目计划发电还有约两年时间，但是为了精细化开展工作，就必须提前启动，因此在签订合同后一个多月就召开了一联会。在一联会上启动和规划了DCS～2作，对后续工作提出了深度、质量和进度要求。在随后召开的联络会中，采取有效措施提高联络会的成效和质量，为DCS组态工作打下了较好的基础。

五、大力重视DCS组态工作，提高FAT质量

通过过程设计之后，一个比较完整的测点设计和逻辑设计完成，后续进入了DCS工厂组态。在这个项目实施中，把硬件的合理性建设做为一个基础性工作来抓，而把软件组态当作一个核心工作来看待，而工厂组态是这个核心工作的核心。工厂组态提出了不只是按照常规的深度完成基础性组态的要求，还提出了要求所有组态必须完整，所有参数必须提前经验匹配，重点回路必须进行外部二次审核和仿真运行，到场画面不许进行差异性的修改，要求FAT（FACTORY ACCEPTANCE TEST）环节的测点测试必须达到100%且完好率100%，硬件测试100%且合格率100%，组态功能测试100%并且完整率100%。

六、引进专家团队，把控出厂质量

在DCS全程实施中，项目管理单位策划了引进专家团队指导具体工作，把控出厂质量的方案。为有针对性的深入的完成逻辑功能设计、完成网络合理性评估、完成软件组态细节工作，项目单位招聘了具有丰富专业经验的汽机、锅炉、电气、化学、热控（软硬件）等多专业的资深专家8名参与逻辑讨论、组态方案设计和审查、精细化组态把关等工作，提出了上百条改进方案和建议，对设计方案进行了优化，对组态的合理性进行了完善，为DCS的过程建设又增加了一道质量关口。

七、借助调试队伍，调试工作前移

本项目在策划之初就提出了借助调试队伍参加工厂组态，把调试工作前移到DCS组态关口的策划方案，该策划方案符合国电集团精细化调试和项目创优工作的有关要求。调试单位不但参加逻辑组态审查，还参与工厂组态学习、工厂组态、工厂组态审查和验收等工作，将调试关口前移到了工厂组态阶段，即保证了调试单位对系统、组态逻辑的熟悉，便于后续现场调试的快速介入，也保证了组态深度，让逻辑组态经过调试单位的参与把关而得到了优化和细化，另FAT的成品质量得到了切实提高。

八、采取中间点控制措施，加大重视程度，提高重视层次

在整个工程实施过程中，还增加了诸多中间点的控制措施，加大了重视程度，提高重视层次，确保工程的连续高质量实施。中间点措施包括：过程中安排专业人员定期按照计划检查组态的画面、逻辑；工程实施中间组织包括汽机、锅炉、电气、热控、化学、调试、设计院等专业在内的所有人员到厂家对半成品进行检查；组织专家团队到厂家对重点成品逻辑（女HRB＼FCB＼MCS＼FSSS等）进行审查；组织专家团队和调试单位人员参与FAT验收；在FAT出厂前又对原来的逻辑功能进行了一次审核、优化、校对。

九、调试期间精细化措施

在组态调试中，要把好FAT关；在现场按照实际系统情况再组织一次逻辑、画面审查，为调试做好准备；在实际调试中要求优化组态参数，既要保证保护逻辑的合理性正确性，还要保证调节系统的高品质；在RB＼FCB＼吹灰调试阶段，要再次制定详尽方案和反事故措施，确保各项重要功能的高品质实现。

十、需要改进和重视的其它问题

在整个工程实施过程中还存在以下一些需要改进和重视的问题：

1、目前DCS厂家组态投入不大、质量不高。而实际上DCS的稳定性和经济性也很大程度上取决于软件组态的质量好坏，这应是以后招标中或者行业操作时应该注意的问题，应该把组态服务的品质提高到较高的重视程度。

2、应该重视DCS的经济性，重视MCS品质的优化。DCS不但能够创造安全性，同时其MCS的组态品质好坏也决定了机组运行的经济性高低。一个自动化程度高、自动调节品质优良的MCS系统，除了带来机组的稳定性以外，还带来了很大的经济性，因为各类主控参数在高参数稳定区运行势必对机组性能带来好处。按照当前的形式来看，以后MCS考虑优化控制策略应该是以后的发展趋势。