测试团队工作计划篇1

我首先尝试的是如何与工程师团队进行头脑风暴专题讨论会。团队头脑风暴乐趣多多，每个人都会踊跃提出自己的想法。在会议室待上几个小时后，我们会写满一大摞便利贴，而且每个人都像打了鸡血一样情绪激昂。

但是事实令人尴尬：我调查过参与者是否喜欢这种讨论形式，却从来没有评估过实际的效果。接下来我审查了我组织过的每一场头脑风暴的成果，发现真正付诸实践并且获得成功的想法并不是来自大喊大叫的头脑风暴。

那些更棒的点子来自个体依然用过去习惯的方式思考创意时――坐在办公桌前时、在咖啡店等咖啡时、洗澡时。这些由人们独自想出的点子更胜一筹。

我重新思考了团队讨论会的形式。如果我把这些神奇的元素――专注于个人工作，制作原型的时间，无法避免的最后期限――加进来，会怎么样呢？我决定把这叫做“设计冲刺”（DesignSprint），并在不断验证这一方法的过程中逐渐组建了四人团队。

“设计冲刺”是谷歌风投独特的五天式流程，可以通过原型设计和用户测试来解决关键问题。它是商业战略、发明创新、行为科学、设计等领域的“超级精选专辑”，而且还被改造成了一个循序渐进的过程，任何团队都可以参照实施。

“设计冲刺”

好的想法来之不易。即使是最妙的想法要在现实中取得成功，也面对着种种不确定因素。无论你是在管理初创公司、教授一门课程还是在一家大企业任职，都是一样的。

为了帮助迅速解决问题，自给自足，我们优化了“设计冲刺”的流程。这个流程避免了无休止的争论，并将几个月的任务压缩进了短短一周内。我们不需要等到做出一个最小可行产品才能确定我们的点子是否够好，初创公司只需要用一个看起来真实的原型就能得到清晰的答案。

它给我们的初创公司带来了一种超能力：可以在付出昂贵的代价之前，就穿越到未来，了解他们的产品以及用户反馈。如果一个冒险的想法能够在“设计冲刺”中获得成功，那么真正实践的回报更会好到不可思议。当然那些痛苦的惨败经历也会给我们带来最大的投资回报。仅用五天时间就能找到关键性的不足之处，这是非常高效的，又不需要承受真的栽个大跟头的痛苦。

我们已经与多家公司合作实践过“设计冲刺”，试验各种流程，并检验结果，寻找改进的方法，在谷歌风投投资的各类型初创公司进行了100多场实践，提供了解决大难题、尝试新创意、增加新成果、获得高效率的捷径。

实施前的准备

开始“设计冲刺”之前，你需要确定正确的挑战，组建合适的团队。你还需要订好进行的时间和地点。

挑战越大，效果越好。“设计冲刺”能够解决三种挑战和困难：一是风险高的。你面临着一个重大问题，而解决方案可能会耗费大量的时间或资金。此刻你就是船长，“设计冲刺”能够帮助你在马力全开之前看清航海图。二是时间紧的，你面临着严格的最后期限，需要好而且快的解决方案。“设计冲刺”正是为速度而生。三是起步难的，有些重要的项目很难启动，有些则在中途失去动力。在这种情况下，“设计冲刺”就像一个火箭加速器，带来新方法和新视角，帮助你摆脱地心引力的束缚，顺利找到解决方案。

“设计冲刺”就像一场精心策划的大劫案。你和你的团队成员将你们的才能、时间和精力发挥到极致。首先你需要一个有权威、能够做决定的人，这个人是决策者。在我们合作过的很多初创公司，这个人是创始人或首席执行官。在大一点儿的公司，可能会是副总裁、产品经理或者其他团队领导。这些决策者通常对问题理解得很深刻，而且通常具有很强的观点和原则，这样他们才能协助团队找到正确的解决方案。

团队最理想的人数是七人或更少，人更多进程就会减缓，而且要维持所有人的专注和高效也需要更多的努力。你肯定需要那些设计产品或者运营服务的家伙――工程师、设计师、产品经理等等。毕竟他们更了解公司的产品和服务如何运行，知道如何找到解决方案，而且他们很有可能对问题已经有一些想法。

“团队”这个词已经泛滥，但是在“设计冲刺”中，团队是真正意义上的团队。连续五天，你们将会并肩战斗。到了星期五，你们会凝聚成一台解决问题的机器，并且在挑战及可能的解决方案上达成深刻的共识。“设计冲刺”的合作氛围非常适合把平时经常与你意见不合的人拉进来。

还要选一个引导者，负责控制时间、组织谈话以及整个过程。他应该对组织会议有信心，既能总结讨论要点，又能在恰当的时机结束争论，进入下一个环节。引导者需要对各种决定保持中立。一般来说，让一个之前没有和团队成员合作过的人担任引导者，效果不错。

为什么定成五天？我们试过更短的时间，但是那样搞得大家都精疲力竭，而且没有时间来制作原型、进行测试。我们也试过六周冲刺、一个月冲刺，还有十天冲刺，最终都没有超出一周冲刺的成果。五天时间带来的紧迫性让人们更容易集中注意力、打断不必要的争论，同时又有喘息的空间来制作原型、进行测试，不至于忙到吐血。而且由于大部分公司都实行五天工作制，把“设计冲刺”安排到现有的日程规划中切实可行。

如何实施五日计划

星期一：描述问题，选出集中解决的着力点结构化讨论为整个星期确定方向。上午从结果出发，并在长远目标上达成一致。接下来描绘挑战的全貌。下午邀请公司的专家分享他们的观点和看法。最后选择着手点：要解决问题的哪一个方面？这个方面既富有抱负又可管理，并且能在一周内解决。

星期二：回顾已经存在的点子，并进行重组和改进。然后到了下午，每个人都要拟定方案，按照四步流程，重思考轻技巧。这有点儿像玩乐高积木：先收集有用的部件，然后把它们改造成原创又新鲜的东西。下午画方案，把抽象概念变成具体方案。

星期三：做出艰难的抉择，并将选中的方案转化为可测试的猜想上午评估每一个解决方案，然后决定哪一些最有可能助你实现长期目标。下午在草图中选出优胜者，编进原型分镜脚本中：形成一个步步为营的原型制作计划。

测试团队工作计划篇2

【关键词】Scrum敏捷开发方法软件开发实训教学应用

【中图分类号】G【文献标识码】A

【文章编号】0450-9889（2014）12C-0059-03

一、问题的提出

1970年温斯顿・罗伊斯在软件开发中提出了著名的“瀑布模型”。该模型将软件生命周期划分为制订计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本阶段，各阶段工作必须按次序自上而下开展，每个阶段要撰写大量文档，并对工作结果进行严格验证，只有上一阶段工作结束，才能开启下一阶段工作。这种开发模式应对上世纪60年代出现的软件危机问题，是一种很好的解决方案，成为了软件开发模型的经典。

当前，随着软件开发技术的进步，人们发现“瀑布模型”灵活性差，不适用于需求不明确的软件项目，很多软件企业已不再使用“瀑布模型”，但它作为软件开发模型的经典仍广泛应用在高校软件开发实训课堂中。实际上，应用“瀑布模型”进行教学的高校计算机软件开发相关专业学生毕业时的动手能力远远达不到企业的要求，这说明该教学方法和实训模式存在问题。为了提高学生实践能力，很多高校与计算机软件开发培训机构或企业进行联合办学，以弥补学校实训教学能力的不足。

二、“瀑布模型”实训教学存在的问题

应用“瀑布模型”进行的实训教学中主要存在如下问题：

首先，学生把握项目需求的能力差，难以达到“瀑布模型”对开发者的要求。“瀑布模型”适用于需求明确的项目，要求开发者具有很强的整体把握能力和前瞻性。但是对于初学开发的学生来说，需求再明确的项目，他们也不能很准确地把握细节，导致实训进程不能按计划正常开展，影响了实训效果。在实际教学中，虽然很多实训项目在以往的教材中有类似的解决方案，但是区别还是存在的，学生看不到软件在实际应用中可能出现的问题，到了项目开发后期才发现错误，导致实训项目失败。

其次，在“瀑布模型”开发的每一个阶段，都要求撰写细致准确的文档，这大大占用了学生的实训时间。据统计，如果严格按瀑布模型的要求来撰写文档，消耗的时间至少是整个实训时间的1/5。本来实训课堂留给学生实训的时间就不多，对一些效率低的学生来说，文档还没写完实训期就结束了，整个实训过程变成了纸上谈兵的演练。

最后，“瀑布模型”实训方式过时，学生不能学以致用，实训技能与企业要求脱节。当今的软件开发中，已经很难看见完全实施“瀑布模型”的企业，大家都已对“瀑布模型”进行了改进或者实施其他更先进的开发方法。教育部曾多次指出，高校教育应服务地方和行业，密切与行业、企业合作，为企业提供人才培养和技术服务支撑。这要求我们必须改革过时的实训模式，使教学与行业结合，与企业接轨。

三、Scrum敏捷开发方法概述

近年来，很多先进的软件开发模型在实际应用中得到了推广，这里要特别提出的是敏捷开发。著名IT组织VersionOne在2013年进行的敏捷现状调查结果显示，在全世界收集的3501份调查报告中，使用敏捷开发方法的占88%，其中使用Scrum敏捷开发方法或Scrum变种开发方法的占73%。这个调查数据充分说明了敏捷开发方法在行业中的主导地位。

敏捷开发（Agiledevelopment）是一种以人为核心、迭代、循序渐进的开发方法，它把项目分割分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。敏捷开发方法包括Scrum、Crystal和极限编程（XP）等，是一组开发方法的总称。它也是软件开发的一个过程管理框架，遵循了敏捷开发的主要价值观：个人与交互重于开发过程与工具;可用的软件重于面面俱到的文档;与客户的合作重于对合同的谈判;响应变化胜过遵循计划。

Scrum敏捷开发过程是迭代的增量开发，整个开发过程由若干个短周期的迭代组成，每一个迭代周期称为Sprint（冲刺），每个迭代实现不同的特性，迭代中重大的、优先级高或风险高的特性优先实现。Scrum敏捷开发方法重视软件的可用性，强调与客户的沟通，开发过程能够快速响应用户需求变更，尽早处理风险问题。

四、Scrum敏捷开发方法在软件开发实训教学中的优势

相对于“瀑布模型”，Scrum敏捷开发方法具有更多适合软件开发实训教学的优势，主要表现在如下方面：

第一，能够快速响应需求变更。与实际开发相似，学生的实训项目都是在重复多次的修正需求、修改设计后才交付实现的。Scrum敏捷开发方法中的Sprint都很小，即使需求变更很大，也可以在短时间内修改设计完成开发。而“瀑布模型”希望需求是稳定的，但不变只是愿望，变化才是永恒。如果在软件设计后期提出需求变更，那会是一种灾难。这种影响小则使实训进度不可控，重则导致实训项目失败。

第二，Scrum敏捷开发方法要求尽早编码，尽快开发出系统原型，尽早使客户见到可运行的软件，暴露项目的技术风险，从而提出优化意见。这恰好迎合了学生开发实训时急切渴望进行编程实现的心理，激发了学生学习的积极性。而“瀑布模型”要求推迟实现，要尽可能把需求分析透彻，设计完整，完成文档编写后才能进行编码实现。这个过程对急切渴望编程的学生无疑是一种打击。

第三，Scrum敏捷开发方法不要求文档面面俱到，更注重于软件可用性设计。在敏捷开发中，很多文档只是一个草图，大部分文档在集成测试阶段产生，而且只写有必要的文档。所以实训团队不需要安排专人撰写完备的开发文档，从而使学生有时间专注于开发实训工作。

第四，Scrum敏捷开发方法能更全面地培养学生的软件开发技能。在Scrum项目中，每个开发成员主动认领开发任务，开发过程涉及的设计、编码和单元测试全部是个人独立完成，实际上一个人承担了传统开发模式中系统架构师、程序员、测试员和产品构建经理等角色工作。这种实训方式有助于提升学生软件开发的单兵作战能力，从而快速适应企业软件开发工作的各个环节。

五、Scrum敏捷开发方法在软件开发实训教学中的实施

综上所述，在软件开发实训教学中使用Scrum敏捷开发方法，可以更好地促进教学，提高学生实践能力，实现教学与行业结合，与企业接轨。具体实施方法如下：

（一）组建开发团队，实行双教师教学

在实训中，可将教师和学生按Scrum敏捷团队角色分组，主要有以下三类角色：一是ProductOwner（产品负责人）。该角色可安排熟悉产品需求的教师承担，负责产品需求的提炼、条目化和优先级排序。二是ScrumMaster（团队负责人）。该角色可安排熟悉Scrum开发流程的教师承担，负责整个Scrum团队的协作运行，并协作解决非技术问题。三是Team团队成员。Team团队由Team小组长和3～5名小组成员组成。小组长由开发能力较强的学生担任，其他成员根据开发能力强弱穿插分配。每班学生可分为若干个Team团队，每个开发实训项目由一个或多个开发小组的学生在老师指导下完成开发任务。

在实训开发课堂中，之所以要实行双教师教学，一是开发团队角色需要，二是为了让教师能在实训过程中相互讨论，取长补短，弥补高校教师在实践经验上的不足，提高实训教学的整体质量。

（二）约定开发规范，精简开发流程

实训开始前，开发团队应约定统一的开发规范和流程，以便学生掌握团队开发方法，并养成良好的编码习惯。图1为经过精简的Scrum实训开发过程模型。

图1Scrum开发过程模型

图1是Scrum开发的一个迭代周期。其中，ProductBacklog为软件产品总的需求条目，这些需求多以用户故事（Userstory）的形式展现，ProductOwned负责维护;SprintBacklog是ProductBacklog的一部分，通过计划会议（PlanningMeeting）讨论选定，是需要在当前迭代（Sprint）中完成的需求条目;圆环为迭代开发（Sprint）的过程，一般周期为2～4周，迭代过程包含分析―设计―实现―测试等工作。迭代开发过程中，Team成员每天进行15分钟的站立会议（Dailymeeting），主要汇报昨天做了什么、今天要做什么和遇到了什么问题。Scrummaster每天负责绘制任务燃尽图（BurnDownChart），以曲线展现当前Sprint任务的剩余量，这对团队开发有很大的鼓舞作用。每一次迭代开发完成后，教师要组织Team团队成员召开评审会议（ReviewMeeting），一个可执行的软件版本（Release），并让相关人员和团队成员提出优化意见。

（三）结对编程，以强带弱，相互促进

学生的学习能力和实践能力是强弱不一的。在实训过程中，教师的指导作用固然重要，但师生间的沟通往往没有学生间的沟通那么自如。因此，可以安排一个能力强的学生与一个能力弱的学生结对编程，充分发挥先进学生的带头作用，让后进学生有机会学习别人优秀的学习方法和实践经验，互相监督，互相促进，最终实现实训目标。

（四）持续集成，交换测试

在我们的实训中，并没有设立专门的软件测试小组，开发团队只是对软件进行了简单的单元测试。如果整个项目都要等到软件开发后期才进行集成测试，项目失败的风险就会很高。Scrum要求团队开发要尽可能频繁地进行集成测试，也就是持续集成。持续集成可以尽可能快地发现集成错误，通常每个成员每天至少集成一次，也可能进行多次集成。每次集成都通过自动化的构建（包括编译、、自动化测试）来验证，减少开发团队进行集成测试的时间消耗。实践基础好的团队可尝试实施测试驱动开发（TDD），即先编写测试代码，后编写功能代码，用测试代码驱动功能开发，这可以降低自动化测试的出错率，提高软件运行质量。如要进行人工测试，可安排各个开发团队进行交换测试，因为他人测试比自己测试更容易发现软件存在的错误。（下转第87页）（上接第60页）

总之，Scrum敏捷开发方法是一种新兴的软件开发方法，很多实践方法和理论还在不断地研究中。实训教学终究是以传授技能为主，不需要拘泥于Scrum开发的全部形式，教师可对Scrum开发方法进行修剪和优化，从而更好地实现教学目标。自2013年起，柳州师范高等专科学校在软件开发实训教学中实施Scrum敏捷开发方法，现已成功开发了教学质量监控系统、科研工作管理系统两个真实项目，用户对软件的满意度很高，实训教学取得了良好的效果，但相关管理制度和实训措施还需要进一步探索和优化。

【参考文献】

[1]VersionOneInc.8thAnnualStateofAgile[R].VersionOneInc，2013

[2]MikeCohn.Scrum敏捷软件开发[M].北京：清华大学出版社，2010

[3]FrederickP.Brooks，Jr.人月神话[M].北京：清华大学出版社，2007

[4]陈国栋，罗省贤.Scrum敏捷软件开发方法实践中的改进和应用[J].计算机技术与发展，2011（12）

[5]HenrikKniberg.ScrumandXPfromtheTrenches[M].C4MediaInc，2007

[6]商惠华.计划驱动下敏捷开发过程的软件质量管理[J].汕头大学学报（自然科学版），2011（4）

【基金项目】广西高等教育教学改革工程项目（2013JGB301）

测试团队工作计划篇3

关键词：甘特图大型软件研发管理项目管理

0引言

软件已经成为现今人们工作和生活中不可缺少的一部分。随着科技的进步，大家期望软件能处理更多的事项、更大的数据和复杂度更高的逻辑。因此，软件的体量越来越大，软件研发团队的人员也越来越多。

软件是一种人类智慧产品，一个软件产品内部各部分之间存在着多种依赖关系。因此，在大型软件研发过程中，对于人员、任务、时间的管理非常困难。

甘特图是近现代管理学上的有效工具之一，东方地球物理公司物探技术研究中心尝试将甘特图技术用在大型软件项目的管理过程中，以求解决管理难题。

1大型软件研发项目中的管理难题

大型软件研发项目［1］，其团队规模一般在30人以上，周期在一年以上，软件代码行规模在十万行以上。

与硬件产品不同，软件产品是人类逻辑的产物［2］，有着抽象、不可见、无弹性、难检测的特点。一个软件产品中包含着成千上万个业务逻辑流程，各部分功能相互依赖、相互影响。

对于一个大型软件项目来说，一般要再划分团队进行工作，每个团队负责研发产品的一部分（例如一个子系统）。在每个研发团队中，还会将软件功能进一步分解，拆分成更小的任务进行实现。对于每个功能，按照软件工程的整理做法［3］（图1），一般会分解为软件需求分析、软件设计、软件编码、单元测试等子任务。随后，将通过单元测试的功能逐渐集成到软件产品主干上，进一步开展集成测试、系统测试、验收测试等任务。

每一单个功能的开发过程虽然大致相同，但是在同一时刻，不同的软件功能所处的任务却不相同。这一方面是因为不同软件功能之间有依赖关系，有些功能必须在其他功能完成之后才能进行开发；另一方面，也是为了让一个软件项目中的所有人员都保持一定的工作饱和度，不能因为上一个功能没有开发完成而出现人员等待的现象。

此外，研发软件产品并不是一蹴而就的工作。一般都要进行多轮次开发，从初始原型到精化原型再到正式产品，需要反复工作才能实现原本存在于人类头脑中的软件需求。即便是开发出正式产品，还要针对软件需求进行细致的测试，再通过开发修改软件bug，通过测试验证bug是否修改正确，如此往复循环n次才能达到软件释放的标准（图2）。

因此，对于一个大型软件研发项目，影响项目顺利开展并走向成功的因素中，高深的技术难题仅占很少的一部分，而大部分难点是整个团队任务中的依赖性和协调性［4］。例如，不同任务的前后关系是否合理、任务估算与人员资源是否匹配、关键任务能否在规定的时间内优先保证完成、功能迭代的轮次安排是否适合、需求设计开发测试这些不同类型工作时间量的配比是否合理、出现任务变更后如何应对并合理调整，等等。

按照软件工程的指导，可以将软件研发任务拆分到比较小的颗粒度，一般可以细分到单人单周粒度。在一个计划周期为一年的大型软件研发项目中，仅工程类任务一般会有几百个，再加上诸如项目计划制定、项目例会等管理类任务，整个项目运作下来，任务项有上千个。这些任务之间有大量的依赖关系，更有对不同人力资源的占用。如果任务安排不当，很容易造成窝工、误工、返工甚至停工的现象。

2用甘特图管理大型软件研发项目

2.1什么是甘特图

甘特图（GanttChart）是由美国的甘特（GannttHL）发明的一种表现任务从属关系和时间排列顺序的图表，也被称作条状图或横道图［5］（图3）。

甘特图通过条状图形来显示任务项之间的关系及其在时间上的前后顺序，帮助管理者进行计划编排和任务拆分，被看作是一项管理技术革命。通过对甘特图的条状图形加以改进，形成了跟踪甘特图，可以体现每项计划任务的进展情况（图4）。

在甘特图中，还可以体现各任务项之间的依赖关系，例如“开始—开始”、“开始—结束”、“结束—开始”、“结束—结束”等关系，以便找到决定整个项目成败的关键路径（图5）。

甘特图的出现对现代管理技术的影响很大，之后的网络图、关键路径法和计划评审等技术和工具，其思想基础都来自于甘特图。

2.2甘特图在大型软件项目中的应用

东方地球物理公司物探技术研究中心是一家专门研发找油找气软件的机构，其主要产品为Geo-East地震数据处理、解释一体化软件。该软件有着超过千万行源代码的体量，能够高效处理海量数据。全中心有近200名研发人员在围绕这一产品工作，每次新版本升级，都会划分成多个数十人组成的研发项目组开展工作。

在多年的研发实践中，物探技术研究中心的项目团队通过不断尝试和摸索，总结了使用甘特图管理大型研发项目的经验，不断开发出成功的软件新版本。

2.2.1总结出甘特图框架

甘特图只是一种工具，在不同项目团队中的实际用法不同。为了统一各项目的管理模式，研究中心依照软件工程中的任务分解关系，根据找油找气软件的技术特点，参考IBMRUP的软件开发迭代模型，总结出适用于科研院所管理要求的甘特图框架（图6～图9）。

除以上几个高位节点的甘特图框架之外，还对项目跟踪监控、项目培训、过程与产品质量保证、软件测试、bug修改等各类工作给出了甘特图框架。

2.2.2确定各类任务占比

一个软件研发项目中，有各种类别的工作，例如：工程类的软件需求分析、软件设计、软件实现、软件测试等工作；管理类的项目计划制定、项目例会、项目里程碑评审等工作；支持类的度量与分析、过程产品质量保证等工作。由于项目有明确的开始和结束时间，人员和资源也是有限的，因此必须对这些工作的占比进行合理安排，以免顾此失彼，最后造成项目不能按时保质完成的后果。

为了得到各类任务的合理占比关系，研究中心设计了不同任务的数据分类（表1），对项目执行数据进行了严格的采集（表2），以项目为单位进行归一化处理（表3）。进行异点排除、数据校正等处理之后，得到了整体的组织过程数据基线（表4），作为指导制定后续研发项目计划的依据（表5）。

2.2.3近细远粗逐渐分解

对于一个大型软件研发项目来说，项目计划任务的分解工作是无法一蹴而就的，必须分层次分阶段进行工作推进。

经过多年的实践，物探技术研究中心总结了“近细远粗”和“632”原则。具体是：对甘特图任务的拆分遵循“近细远粗”的原则，近期任务的时间跨度要拆分得小一些，远期任务的时间可以跨度长一些；时间跨度遵循“632”原则，即项目中两个里程碑任务的时间跨度不超过6个月，一个月以后开始的任务时间跨度不超过3个月，一个月以内开始的任务时间跨度不超过2周（图10）。

2.2.4周五填报、周一审批

如果仅做计划而不做跟踪，那计划就没有意义，起不到任何管理作用。在一个大型软件研发项目的甘特图中，任务项往往有几百个乃至上千个。这些任务项的完成情况形成合力，反映了整体研发的进度执行情况。

在物探技术研究中心的研发项目管理中，强调“周五填报、周一审批”的管理原则，即：每个甘特图任务的任务成员在每周五填报自己任务的完成情况，包括工作量和完成内容（图11）；任务负责人每周五填报该任务的完成百分比（图12）；任务审批人每周一对填报过的任务进行确认和审批（图13）。

通过任务的填报和审批，能得到每个甘特图任务的完成数据，再结合甘特图任务的计划数据，使用挣值分析工具，很容易得到反映项目整体进度执行情况和成本投入情况的挣值图（图14）。

2.2.5刚性与弹性的统一

一个大型软件研发项目中任务众多，绝大部分甘特图条目是在制定项目计划时确定和下发的。然而，随着项目的推进，总会出现与做计划时预期不一致的情况，包括任务的增减、任务的进一步拆分、任务无法按时开始或者按时完成等多种情况。这样就不可避免地要对甘特图任务进行调整。

有些任务项之间是有依赖关系的，例如关键任务，对其调整会对其他任务特别是后续任务造成影响，甚至会影响项目里程碑能否按期达成；有些任务项本身比较独立，对项目里程碑影响不大，早点开始晚点完成都可以容忍。

为了既能保持甘特图的实时指导作用，又要减少随意变更对项目造成的冲击，给出了甘特图调整原则：影响项目里程碑达成的任务只能通过正式的变更流程进行调整；其他情况可以随时进行任务调整；未按计划完成的任务可以不作调整，继续填报直到任务结束（图15）。

该原则很好地体现了项目管理中刚性与弹性的统一，让甘特图的应用既严格又灵活，成为项目长得心应手的管理工具。

3结束语

团队中的任务依赖和协调问题是影响大型软件研发项目成功的关键。在研发过程中，团队不仅需要对各种任务进行合理地组织归类，还需要在任务估算、拆分下发、跟踪填报、变更调整等方面进行合理的规定，以便于科学管理，不漏不乱。

测试团队工作计划篇4

关键词：机械产品研发控制类型原则阶段

机械产品的研发是以市场需求为目标的，其过程分别为：市场调研、整体计划、研发计划、草案图、计划图、工程图等。机械产品的研发是通过市场调查，以及对社会变化的洞察和对技术发展的预测而开展的一项产品研发过程。而机械产品研发包括了前期对社会变化的洞察、对技术发展的预测、技术研发、加工生产、市场销售、售后服务等过程，做好研发过程的控制相当重要。

1、明确机械产品研发控制的类型

第一，循序渐进式。机械产品创意可能数量极多，但只有极少数能通过筛选，而评估的重点在于竞争力、获利率、市场销售量、技术可行性、企业资源能力等。在形成共同的产品概念之前，往往需要经过反覆的讨论与评估，因此步骤一至叁是反覆的循环进行。产品概念形成后，要进行市场机会分析、销售量预测、财务预测，目的是进一步明确机械产品的市场机会与检测机械产品开发有关的决策。完成产品原型开发后，要先进行试产与市场测试，以便在正式上市前有修订与弥补的机会，并且为量产与上市做最充分的准备。循序渐进的机械产品开发模式的优点是，可以确保有关机械产品开发可能面临的议题或困难，均在事前经过详细的评估，因此可以降低产品开发的风险；不过因此可能也要付出相当的时间与成本的代价，尤其这种模式的弹性与灵活应变的程度相对较低。一般在市场情况变化不大，企业组织较结构化、产品开发有充足的时间与资源支持、以及面对不确定高的全机械产品开发案时，较常采用这种循序渐进的开发模式。

第二，同步并行式。循序渐进式主要的缺点是部门间的联系与沟通，每一个部门都必须要花费许多时间来试着去了解上一部门移转过来的研发成果。经常由于部门间认知差距与沟通障碍，造成时间拖延与成本上升，尤其严重的是无人需要为产品开发的成败负起全责。为了克服这些问题，因此产生所谓同步并行式的机械产品开发程序，又称为同步工程。同步并行的模式采用专案研发的方式，将与机械产品开发有关部门的人员整合起来，并以团队合作方式来运作。

第三，机动团队式。由于市场环境的快速变迁，企业对于机械产品开发活动与相关决策，要求更高的弹性与应变速度。如果将循序渐进式视为大队接力，那么所谓机动团队式就如同篮球团队一般。机动团队式的机械产品研发，强调授权与学习的组织特色，并以独立专案团队的方式来运作。在这个专案团队中，虽然没有明确的作业程序或作业规范，但非常重视成员共识的建立，产品各发展阶段机动的同步进行，独立、自主、创新、学习是机动团队的主要特色。一般企业为克服机械产品创新的阻力，经常会采取这种组织模式，企业主要以预算与绩效做为控制与评量这类专案团队的主要手段。

2、遵循机械产品研发控制的重要原则

无论采用上述何种的机械产品开发程序，企业都必须要掌握以下五项基本原则。第一，建立与企业目标一致的机械产品开发策略。将经营目标、策略与机械产品开发策略两者相结合，如此机械产品开发可以长远的规划，获得充分的组织配合，发展最适合的开发程序，并成为企业的经营策略中重要的一部分。第二，对于机械产品开发资源配置，应重视弹性运用的原则。过去许多研究证明，充分的资源配置与弹性的运用空间，对于机械产品开发绩效发挥将有很大的帮助，这是企业投入机械产品开发活动必须要有的认知。第三，在机械产品开发过程中，要重视企业关系人间的互动与充分沟通。尤其在产品概念产生的初期，良好的沟通与互动，是产品开发成败的关键因素。第四，要发展整合性的专案团队，来进行机械产品开发。由于产品开发涉及到许多部门的业务与功能，因此形成团队将是最佳的运作方式。第五，以永续发展的观点来看待机械产品开发有关的业务。每一项机械产品开发都不是独立的计划个案，而是企业在追寻永续发展过程中的持续创新行为。

3、把握好机械产品研发控制的阶段

机械产品研发由抽象意念而致具体产品，大致可分为创意产生、产品概念、产品雏形、最终产品、营销计划等五个过程阶段，而对于研发的有效控制也有必要对这五大阶段加以重视。

第一，产品创意。产品创意是机械产品开发的源头，若能有效管理产品创意的来源，对于机械产品开发绩效会有很大的帮助。机械产品创意主要来源于与产品开发利益相关的企业关系人，包括顾客、制造商、供应商、竞争对手、组织成员等。据了解，在科学仪器产品创新行为中，有77%的创意来自于客户的意见，而车辆工程产品创意来源，则有94%是制造商所提供的。获得大量机械产品创意后，必须进行筛选评估，只有少数的创意可能具体发展成为产品概念，评估的一项主要因素是未来市场潜力的大小。

第二，产品概念。产品概念是综合各组织成员与企业关系人需求与意见而成，对于机械产品的各项特征给予具体的说明，做为未来开发产品的具体指引与沟通基础。产品概念也需要经过较详细的市场机会分析与销售预测的考验，以确保产品开发成功的机会。

第三，产品雏形。产品雏形是产品概念具体化的结果，较多由研发人员、制造工程人员与营销人员共同参与发展，主要做为机械产品试产与试销的工具。

第四，最终产品。机械产品经反覆修正后，终于完成最终产品，展开大规模的量产投入与市场营销计划。

第五，营销计划。营销计划的内容包括：定价、通路规划、促销手段、产品定位、人员训练、后勤服务支援规划等，虽然营销计划早在产品概念阶段即已着手进行，但必须产品实际完成后，才能具体的定案执行。

4、结语

无论做什么样的工作，总结和分析永远是有效而必须的。机械产品研发的反馈可以通过销售部门和售后服务部门来获取，也可以通过小范围的市场调查来获取，具体使用什么样的方法则取决于产品的重要性，以及当时具体的情况。

参考文献

测试团队工作计划篇5

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结语

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