中图分类号：TP311 文献标识码：A 文章编号：1674-7712 （2013） 04-0075-01
一、引言
现在，软件测试已经成为一个很有潜力的专业，软件测试可以提高质量，降低维护成本。
对于大型相对复杂的软件项目，做好软件测试就会相对困难，因此，为了尽可能提高软件质量，减少错误，必须有效对测试工作进行计划和管理。
要想对测试工作进行有效策划和管理，需要采取系统的方法建立软件测试管理体系，对测试活动进行监管和控制，以确保软件测试在软件质量保证中发挥应有的关键作用。
二、建立测试管理体系
软件测试的过程及应用即测试规划，设计，执行，配置与资源管理，缺陷管理等。从项目管理的角度来说，这些过程里，前一过程的输出是后一过程的输入。其中，配置与资源管理是这些过程的支持，测试管理对其他测试过程进行监视、测试和管理
三、测试管理过程和基本内容
（一）测试团队管理
做好软件测试需要一个独立的团队，测试团队独立于开发团队之外去做测试工作，可以更加公正的进行测试。虽然测试人员可能需要花时间去熟悉被测对象然后才能设计出测试用例，但是测试人员具备了专业的测试理念和设计技术，而这些测试技术是一个开发人员所没有的或测试前必须花时间去学习掌握的。
测试团队管理的主要任务：确定测试队伍的组织模式，确定测试需求和组织测试设计，估计测试工作量，安排测试任务，确定应交付的测试文档，管理测试工具。
（二）测试过程管理
软件测试贯穿于软件开发整个生命周期，在软件开发的每一个阶段，都有相对应的测试任务，从计划、设计、执行到缺陷管理、总结等步骤，构成了一个测试过程。（如图1）
因此，软件测试过程管理主要集中在测试准备、测试计划、测试用例设计、测试执行、测试结果分析，以及如何开发和使用测试过程管理工具上。
（三）资源和配置管理
1.资源管理包括人力资源和环境资源
人力资源：测试人员的数量及其测试技能，在测试的各个阶段中对人员和技能要求不同。
环境资源：建立测试环境所需要的计算机软件资源和硬件资源。硬件提供了一个支持操作系统、应用系统和测试工具等运行的基本平台，软件资源则包括操作系统、第三方软件产品、测试工具等。
2.配置管理
配置管理是是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
（四）事件（缺陷）管理
事件即缺陷管理，为了有效地管理缺陷（事件），在项目内应该引入规范、高效的缺陷（事件）管理系统。
软件测试的任务就是寻找缺陷，缺陷从被发现、分析、修改，到修改的确认形成了一个缺陷的生命周期（lifecycle）。在缺陷周期内要对缺陷进行跟踪。缺陷可能会在开发过程中被发现，也可能在评审和测试过程中发现，甚至在系统最后使用过程还会发现缺陷。缺陷可能在代码内、在运行的系统中、也可能在各种文档内。缺陷与软件的版本、运行的环境有关。缺陷与人员有关：测试员、开发人员、管理者和客户等
四、总结与展望
测试管理涉及的范围非常广泛，如测试组织管理、测试过程管理、事件管理、人力资源与配置管理、风险管理、进度管理等。软件测试贯穿于软件开发整个生命周期，软件开发周期模型为我们提供了软件测试的流程和方法，为测试过程管理提供了依据。但实际的测试工作是复杂而烦琐的，不会有哪种模型完全适用于某项测试工作。因此，在实际工作中，我们要考虑实际情况灵活地运用测试过程管理理念，依据这些理念来策划测试过程，以不变应万变。
参考文献：
[1]杨小平，王胜开.面向对象软件测试探讨[J].计算机科学，2009，36（11）.
[2]王文东，耿国华，张根耀.软件可靠性保证与评测技术[J].微机发展，2004（11）.
二、软件测试课程实践构建的主要思路
软件综合实践安排在大三课程开始之前的实践学期进行，为期4个星期，每天4学时的实践教学指导，软件测试专业的学生已经学过专业基础课《Java程序设计》、《计算机文化基础》、《网页设计》、《数据库设计》、《软件开发过程实践》，专业课《软件测试概论》、《功能测试》，学生初步具备了参与综合实践的专业素质能力。在综合实践开发团队中，将软件开发专业、网站规划与设计专业、数据库管理专业、软件测试专业和网络技术的同学，以3:1:1:1:1这样的比例进行团队建设，从中选出一位同学兼职项目经理，实现学生自主管理，配备具有双师素质的专业老师，一位教师负责指导5-7个团队的项目开发，当需要进行专业指导时，临时进行专业化实践指导，全方位分阶段、分岗位进行进行全程交叉技术指导，同时邀请合作单位的软件工程师，同步进行项目过程的跟踪，给予学生岗位最精准的实践指导。采用项目驱动的方法开展实践教学，通过开发真实的软件项目，以软件工程开发过程为导向，制定软件综合实践——软件测试方向的实践方案，分阶段进行实践，选择有较强的实践性和创新性的项目给学生选题，选题要贴合实际项目，需求相对容易获取，具有一定的创新性，能够激发学生的学习兴趣。首先需求的调研，需求的评审，编写测试计划，设计测试用例，测试执行，测试记录的跟踪和测试总结报告，对每个测试阶段进行教学设计，不断的将所涉及到的知识点融入到实践中，增强学生职业岗位素养能力，团队合作的意识，同时探索以学生管理学生的模式进行实践探索。
三、软件综合实践测试岗位的工作过程与方法
在软件综合开发实践过程中，对软件测试岗位的同学依据软件工程的理论进行指导，结合企业的工作流程，采用分组的教学模式，采用软件测试常用的W模型，进行教学指导，培养学生的团队合作能力，沟通能力，实践能力。测试岗位的工作主要分成两个三个部分，第一部分是需求的调研和评审，测试计划中测试策略的选择、任务的时间安排和测试用例的设计；第二部分主要是测试执行，安装测试工具，部署测试环境，按照测试所设计的测试用例进行手动功能测试，尝试利用自动化测试工具QTP进行自动化测试，运用所学过的黑盒测试方法，进行web测试，兼容性测试等方法的测试工作，将所发现的问题记录到测试管理平台（QC）的缺陷缺陷跟踪表中，修复后，进行验证性测试，第三部分就是测试总结报告。
四、软件综合实践的考核
1.答辩委员会的组成。立体化全方位的考核方式，采用学生团队答辩的方式进行最终的考核，答辩委员会成员由软件开发方向教师、网站规划与开发教师、数据库管理方向教师、软件测试技术方向教师和企业工程师共同组成。2.软件测试岗位的知识点的考核。每个专业都设计了一套科学有效的评价体系，从三个部分对学生的能力进行全方位评。第一部分IT职业素养能，占总成绩比例的30%，考勤、项目管理能力、文档编写能力、团队合作与沟通能力、演讲与答辩能力；第二部分团队实践成果，占总成绩比例的30%测试环境部署、测试工具软件的安装、测试执行中缺陷报告的跟踪、测试总结报告的编写；第三部分岗位技能成果，占总成绩比例的40%，软件开发过程文档：需求评审报告、测试计划报告、测试用例报告。
五、软件综合实践教学实践的意义
1.软件综合实践项目分组教学的意义2.软件测试岗位同学的收获3.综合实践教学的后续影响4.软件综合实践教学的改革未来方向
作者:张彤宇 李晶 姚庚梅 单位:广东东软学院计算机科学与技术系
参考文献：
回顾20xx年这一年来的工作，我在公司领导及各位同事的支持和帮助下，严格要求自己，按照公司要求，比较好地完成了本职工作。通过近一年的学习和工作，工作模式上有了新的突破，工作方式有了较大的改变。现将这一年的工作情况总结如下：
1、总体来说，2016年我主要完成了“……银行系统”、“……渠道管理平台”、“……”、“……”、“……”“……”的日常测试以及质量控制工作;“……”已经稳定上线运行6个多月，“……”即将上线。
2、日常我主要负责项目测试工作、测试文档编辑、参与功能需求设计、协调开发进度、总结经验分享、完成所需知识积累、工具学习及研究、兼容性软件测试。就在银联项目工作来说，主要的工作内容有：a、测试项目案例、测试用例的设计与编写;b、对测试过程中遇到的问题进行沟通，并提供意见;c、设计业务功能流程，提供参考意见，绘制关键业务流程;d、进行主要功能的界面测试、功能测试;e、按照测试用例执行测试计划;f、进行需求验证工作。
3、知识的总结与分享，完成客户端在安卓4.0/4.1，IOS6.0以上系统上出现的兼容等问题，完成了兼容性测试案例的编写以及兼容性测试的培训工作。在日常工作中，发现兼容上重大问题，在测试部门群中分享。
4、完成所需知识积累，学习所需知识、工具以及技能。在工作中学习了银行业务流程规范、学习公司研发规范、参加了公司组织的技术培训、学习了各种测试工具的使用。
二：对公司的建议与意见
对公司和部门建设上，我有以下几点建议：
1、对员工进行金融知识的系统培训，让测试人员了解银行业务流程，有助于测试人员更加详细了解业务流程，测试过程会少走很多弯路。
2、部门内希望多组织技术交流讨论，促进测试工作的开展和提高。一年至少有2次这样的交流。
3、公司在项目开发前期，希望尽可能的明确需求，尽可能的详尽需求说明书内容。在测试过程中发现很多项目缺少需求说明书，需求说明书不明确或者需求说明书内容错误，误导了开发和测试，浪费了时间，影响了项目进度。
4、建议项目需求设计可以有测试员参与讨论。
5、公司管理有点混乱，个人感觉公司对每位员工的重视程度不够!节假日公司应该给每位员工一定的福利和关心。
6、个人感觉平时的效率比较低，希望测试部门能够有所调整。希望公司能制定质量控制标准以及开发、测试工作流程，让开发更好的了解测试的流程，增强开发团队与测试团队的配合，提高工作效率。
7、加强部门测试成果的积累与沉淀，提高团队测试水准，希望我们的团队能够做的更好，能够已团队的形式参与软件项目的开发，而不仅仅是一个项目中毫不起眼的小小测试员。
三：20xx年工作计划与学习计划
20xx年工作计划就是希望通过自己的努力，让我们的产品更加完美，让自己在软件测试技能上有所提高，更多的关注软件产品的开发过程，提高工作效率、做到与用户的需求一致，提高公司软件产品用户满意度。
一、引言
软件工程课程是高职软件专业类学生的专业核心课，是理论和实践紧密结合的典型课程，主要培养学生软件开发能力和项目管理能力。但在实际教学过程中，因为缺乏明确工作任务并涵盖课程理论知识的综合项目，学生对软件工程理论感到十分抽象，对实践操作也只是囫囵吞枣，根本体会不到软件工程在企业项目开发中的宝贵作用。
针对软件工程课程，国内职业教育课程在借鉴外来职业教育课程开发理论的基础上，也有自己的创新。有一部分学校已经在这方面进行了改革和探索，但大多是单一的、松散地进行，这一状况的形成，一部分是因为现实客观条件的制约，另一部分还在于职业教育课程理论研究的不全面、不深入所致，因此重视和加强高等职业教育课程多元整合是提高高职职教课程开发质量的一个中心环节。
本文将以高职软件工程课程为例，将“任务驱动、项目导向、案例教学”多元整合的创新教学理念引领教学过程，强调动手能力，将工作过程的职业环境融入学习过程中，将学生对知识、职业能力的掌握程度提高到了实践这一层面，使得学生能真正进入到“在学中做，在做中学”的理想学习环境中。
二、多元整合创新教学理念
软件工程课程涉及软件项目计划、软件需求分析、软件设计、软件测试、软件配置管理、软件项目管理等软件开发过程中的各种问题。浙江商业职业技术学院(以下简称“我院”)所在浙江省高新中小企业众多，发展主要依靠技术进步以及科技来推动，对人才的需求也明显高移。经调查发现，目前浙江省软件行业在软件设计、软件测试和软件维护方面的人才缺口大，供不应求。因此，我们将教学重点放在了软件设计、软件测试和软件维护方面。以一个典型、完整、实用的项目“学生选课管理系统”为载体，将软件工程项目开发中用到的各项工作技能按照工作过程分布阶段任务，将项目分解成一个个案例，以任务驱动的方式完成技能的案例教学，同时也体现了工作过程的完整性，将“任务驱动、项目导向、案例教学”多元整合的创新教学理念贯穿于教学过程。
(一)明确工作岗位，分析工作任务，任务驱动学习
任务驱动学习是让学生完成教师精心设计的培养职业能力的工作任务，构建真正属于自己的知识和技能，提高分析和解决问题的能力。如何确定软件工程课程的工作岗位和工作任务是进行任务驱动学习首先要解决的课题。
为此，我们邀请软件行业专家、专业教师参照国家相关职业标准一起分析、论证软件工程工作岗位的工作过程和技能要求。在进行分析论证过程中，根据我院所在浙江省高新中小企业发展实际，结合高职学生学习特点，将软件工程课程培养的人才方向定位在软件设计、软件测试和软件维护三个岗位。我们明确了这三个岗位的典型工作过程，并详细分析了典型工作过程中的典型工作任务。
1 软件设计岗位的典型工作过程主要包括软件项目计划、软件需求分析、软件设计阶段。这些工作过程的典型工作任务有：(1)软件项目计划包括：软件项目计划内容的描述；度量项目的成本、规模、工作量和开发周期；确定项目开发过程模型；制订软件项目计划；(2)软件需求分析包括：定义需求工程过程模型；采用UML获取项目需求；采用UML分析项目需求；编写项目需求规格说明书；(3)软件设计阶段包括：策划项目的设计阶段；应用设计模式，执行系统的架构设计。
2 软件测试岗位的典型工作过程主要是软件测试阶段。其典型工作任务包括：软件项目单元测试用例设计；执行软件项目单元测试；软件项目功能测试用例设计；执行软件项目功能测试；软件项目性能测试用例设计；执行软件项目性能测试；软件项目压力测试用例设计；执行软件项目压力测试。
3 软件维护岗位的典型工作过程主要包括软件配置阶段和软件项目管理阶段。这些工作过程的典型工作任务有：(1)软件配置阶段包括：创建软件项目配置管理计划；对软件项目实施版本控制；(2)软件项目管理阶段包括：对软件项目进行项目估算；对软件项目进行风险管理；对软件项目进行质量管理。
(二)设计教学项目，培养职业能力，项目导向教学
项目导向教学是指通过一项完整的项目工作而进行教学活动的教学方法，它以项目导向、任务驱动，引领教学过程，强调实训环节，将工作过程的职业环境融入学习过程中，将学生对知识的掌握程度提高到了实践这一层面，使得学生能真正进入到“在学中做，在做中学”的理想学习环境中，使学生在学习过程中培养工作岗位职业能力。
我院软件工程课程定位的软件设计、软件测试和软件维护三个岗位有不同的职业能力要求，通过与专家分析论证，我们明确了三个岗位要培养的职业能力：
1 软件设计岗位。要求要培养的职业能力有：理解、实施软件项目计划的能力，编写、制定软件项目计划文档的能力；获取、分析软件项目需求的能力，编写软件项目需求分析文档的能力：理解项目数据模型、项目的架构设计的能力；编写软件项目设计规格说明书的能力。
2 软件测试岗位。要求要培养的职业能力有：设计和实施单元测试用例、功能测试用例、性能测试用例、压力测试用例的能力；撰写测试计划、报告的能力。
3 软件维护岗位。要求要培养的职业能力有：实施软件项目配置计划、管理的能力；实施软件版本控制的能力；估算项目成本、规模、进度的能力；预测、监控、计划、管理软件风险，实施软件质量保证计划的能力。
为了与岗位工作过程相适应，能够在项目教学过程中培养学生的职业能力，在设计教学项目的选择上我们从以下几个方面进行了探索：第一，项目必须包含上述岗位的基本工作过程，能够培养学生职业技能；第二，项目难度适中，符合高职学生的知识、技能结构特点；第三，项目开发周期相对较短，能够在教学时间内完成；第四，项目内容容易理解，贴近学生经验，以便学生集中精力完成软件工程工作过程的学习。
为此，我们精心设计了“学生选课管理系统”来进行项目教学，引入企业真实项目“网上书城”系统来进行模拟训练。这两个项目背景高职学生易理解、掌握和操作，并且包含了上述三个工作岗位职业能力。通过几个学年的教学实践发现，学生基本能掌握三个工作岗位的职业能力，并根据自己的兴趣有所侧重，完全达到了我们项目导向教学的目的。
(三)分解教学项目，激发学习兴趣，典型案例教学
案例教学实际上是一种“做中学”的形式，在经验和活动中获取知识和技能，增进才干。软件工程案例教学的实践反映出，案例选择是否合适、案例运用是否科学将直接影响到案例教学作用的发挥。
对于软件工程这样一门理论和实践都比较注重的课程来说，案例教学就显得特别重要。我们在案例教学中进行了以下探索和实践：第一，案例贴近学生生活，删繁就简，能适应课程教学时限要求；第二，案例有代表性和针对性，能基本涵盖基本的工作任务；第三，案例能让学生参与并易于模仿实践。如讲解软件项目计划时，针对学生选课管理系统这个项目，由老师描述项目计划应该要确定的内容，并引导学生分组讨论确定项目中角色一人员责任矩阵，利用甘特图等工具制订初步软件项目计划。这样学生不仅仅是去强记那些固定的原理、规则。学生通过案例更深刻地理解了工作过程中需要掌握的技能。
三、多元整合教学的探索与实践
任务驱动、项目导向、案例教学的教学方法各有特色，如何将这些教学方法整合在一个具体的教学项目中并让各种教学方法发挥其优点是我们要重点解决的问题。按照软件工程项目开发中典型的工作过程，我们将“学生选课管理系统”项目分解成一个个的小项目，每一个小项目对应着一个具体工作过程。对每一个小项目我们分成六个步骤进行项目教学：
第一步，确定每一个小项目的工作任务。不同的小项目对应的工作任务不同，有的工作任务比较独立、花费时间少，可以在—个教学单元中完成，我们称之为小任务；有的工作任务需要多个教学单元的综合实践才能完成，我们称之为大任务；在教学过程中，对大任务我们又将其分为若干小任务，并在各个小任务完成后进行分析总结，以便学生系统全面地掌握相应的职业能力。
第二步，教师进行案例场景描述，并通过典型案例演示项目中的具体任务。教师先对案例进行场景描述，让学生明白真实工作过程中这个小项目要做什么。然后通过典型案例的演示让学生体会到这个小项目要怎么做。
第三步，学生分组讨论，明确项目分工。软件的开发过程是一个团队合作的过程，将学生从成绩、性格、表达能力等方面进行分组，让不同的学生组合成一个团队进行项目的开发，既培养学生团队合作的精神，又让学生能发挥各自特长，调动学生积极性。在此步骤中，教师可以根据实际教学班组从整体上对团队的组合进行优化调整，对于一些比较难分工的项目，教师可以对团队进行指导，帮助团队进行分工。
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）13-3043-04
1 传统软件开发模型
传统的软件开发模型有瀑布模型，V模型，增量模型，迭代模型，螺旋模型，快速原型模型等。其中瀑布模型是最早出现的软件开发模型，1970年Royce提出，直到80年代早期，它一直是唯一被广泛使用的软件开发模型。瀑布模型的核心思想是将软件的生命周期分成可行性分析与计划、需求分析、软件设计、编码、测试及运营维护等六个阶段，每个阶段按照线性方式进行，当前阶段接受上一阶段的工作结果，实施完成所需的工作内容。当前阶段的结果需要验证，验证通过后，该结果作为下一阶段的输入，否则返回修改。此模型有很多变体，例如V模型等，但其典型性是只有当当前阶段的文档获得认可才可以进入下一个阶段。例如，在开发初期制定详细的计划，在计划中最终产品己被仔细研究，并且拟定规模说明，将一切详细资料都记录在案，通过验证后需求分析才算结束，然后进入下一阶段，也就是设计阶段。传统开发模型的主要缺点有：
1） 其突出缺点是适应不了一直变化的客户需求。现实中的项目在进行时，客户会不停的修改需求或者增加需求，导致项目开发滞留在需求分析阶段，无法有效地进入下一阶段，最终导致产品被延期。
2） 传统开发模型的线性过程过于理想化，早期的错误可能要等到开发后期才发现，例如设计阶段发现需求的错误，测试阶段发现需求或者设计的错误等，特别是开发后期才发现需求的错误，会带来非常严重的后果。
3） 客户在产品计划阶段提出需求后，直到产品Alpha/Beta测试才能见到产品，发现与预期的相差甚远，提出大量的改进需求，最终导致产品不成功或者被延期。
4） 传统开发模型的可行性分析与计划阶段要求明确需求，从而制定产品的计划与进度表，同时明确产品的成本及预算。但对于需求经常变化的项目，该阶段的成果没有任何意义，最终导致项目进度、成本等不可控。
2 SCRUM敏捷开发方法
敏捷开发是一种开发方法学，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进地开发软件。敏捷开发方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开发环境中，综合使用迭代式和增量式开发方法，使用反馈来进行思考、反省与总结，不断地实现自我完善，从而达到软件的完美交付。
Scrum是被广泛使用的敏捷开发方法之一。Scrum是在十多年前由Ken chwaber 和Jeff Sutherland博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括摩托罗拉、谷歌、雅虎、微软、华为、思科、SAP、GE等。Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期被分成若干个小的迭代周期，每个小的迭代周期称为一个Sprint，一般最多以30天为一个周期。在Scrum中，使用产品Backlog来管理产品或项目的需求，Backlog定义产品的所有任务，包括功能性和非功能性的任务。在定义Sprint时，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint Backlog。在每个迭代结束时，Scrum团队将产生可交付的产品增量。
Scrum定义的主要角色有：
1）产品负责人（Product Owner）：该角色负责产品的远景规划，平衡利益相关者（stakeholder）的利益，确定不同的产品需求和优先级等。它是开发团队与客户或最终用户之间的联络点。
2）利益相关者/客户（Stakeholder）：该角色与产品之间有直接或间接的利益关系，通常是客户或最终用户代表。他们负责收集产品需求，审查项目成果等。
3）Scrum负责人（Scrum Master）：该角色负责指导开发团队进行Scrum开发与实践。它也是开发团队与产品拥有者之间交流的联络点。
4）团队成员（Team Member）：即项目开发人员。
Scrum定义的标准流程如下：
1） 根据客户需求，定义产品功能列表Backlog以及每个功能的优先级。
2）召开Sprint计划会议，确立下一个Sprint的目标，划分并确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。
3） 进入Sprint开发周期，在这个周期内，每天需要召开Scrum会议。
4） Sprint周期结束时，召开Sprint成果评审会议，将成果演示给产品负责人或者利益相关者。
5） 团队成员最后召开Sprint回顾会议，总结问题和经验。
6） 这样周而复始，按照同样的步骤进行下一次Sprint，直到产品交付。
我们将在下一章节详细介绍大型项目中SCRUM的角色定义、软件开发模型及具体的开发流程。
3 基于Scrum的大型软件开发模型
3.1 角色定义
基于SCRUM的大型软件开发模型中的角色、文档及产品的对应关系如图1所示，具体角色有：
1）产品经理，担任产品负责人的角色，由开发方承担，作为客户和开发团队的联络点。理解客户的需求及关注点，创建和维护产品的需求清单Backlog，并按照客户要求的优先级进行排序，使得最重要的功能优先实现。产品经理还需要对每个Sprint的结果进行评审和审批，并交付给客户。客户反馈的意见实时传达给开发团队，并调整下个Sprint的Backlog。
2）客户：负责收集编写产品需求，审查项目成果等。他们通过产品经理来设定产品的期望，传达产品的需求，设置产品功能的优先级。
3）项目经理，担任Scrum负责人的角色，负责指导开发团队进行Scrum的开发与实践。项目经理的主要职责有：
①根据每一个Sprint的目标，从产品Backlog中选择优先级最高的需求进行细化，制定Sprint的Backlog；
②召开Sprint计划会议、Sprint交付产品的评审会和客户反馈之后的回顾会，并根据客户反馈调整下一个Sprint；
③协助消除项目中的障碍，维护障碍列表，确保Sprint的交付；
④敦促项目中依赖的解决，维护依赖列表；
⑤控制项目的风险，维护风险列表；
⑥培训团队，提高生产力，确保SRUM流程的执行；
⑦评价项目过程的有效性、加强执行，确保一切工作按照既定的规范来运行，规划并进行必要的改进。
4） 项目开发组：产品交付要依靠团队的努力，团队的职能是交叉的，包含所有角色：开发人员、测试人员、系统环境支撑人员、文档编写、界面设计等人员。SCRUM团队是自我组织、自我管理的，团队中的角色是不分等级、不固定职能的，例如开发人员也可以做测试。
3.2 基于SCRUM的大型软件开发模型
为了提高开发的效率，并提高产品的质量，基于SCRUM的大型软件开发模型综合了传统瀑布模型、V模型等开发的优点，在SCRUM开发流程中加了新的环节，并对某些流程进行约束。图2为基于SCRUM的大型软件开发模型示意图。
SCRUM中每个Sprint周期的开发不是无序的。Sprint中每一个任务的需求是明确的，建议使用瀑布模型、V模型或快速原型等进行开发。根据功能的大小及难易程度选择合适的开发模型。关键模块或者技术难点，可以使用快速原型开发模型。较大的任务可以使用V模型，测试人员可以从需求分析阶段就开始参与。较小的模块可以使用瀑布模型，测试的工作等编码完成后才开始。这里的瀑布模型与V模型的开发流程，尤其是文档的处理，要比传统的开发模型简化了很多，详细开发流程见下一章节。
在传统软件开发模型中，大型的软件在功能测试和系统测试后，产品要交付给客户进行Alpha测试和Beta测试，Alpha测试用于模拟环境下的测试，有时候需要开发者在场。Beta测试用于在真实环境下的测试。Alpha测试和Beta测试后，客户反馈测试结果给开发团队，开发团队进行问题的修复或者功能的改进。Alpha测试和Beta测试对产品的质量至关重要，我们将Alpha测试环节和Beta测试环节加入到SCRUM的开发流程中，作为最终产品交付前的最后两个Sprint。
3.3 开发流程
3.3.1 产品 Backlog的定义
产品Backlog是产品的需求列表，列出需要产品的所有功能及优先级。产品Backlog是客户与产品经理共同制定的。客户通过产品需求规范、平台规范等文档的形式或者邮件、会议等沟通方式提出需求，产品经理作为客户和开发团队的联络点，理解客户的需求，并进行梳理，与客户共同制定产品Backlog，包括：
1）新的操作系统、新的平台等，如Android平台
2）功能方面的需求，功能点
3）非功能方面的需求， 如性能要求
4）问题的修复与功能的改进，如前面产品出现的问题
5）每一个功能的优先级，优先级反映客户的需求及关注点
3.3.2 Sprint Backlog的定义
3.3.2 Sprint的开发
Sprint Backlog被确定后，项目经理给每一个功能点指定开发者。项目开发者对每个功能点可以使用瀑布模型、V模型或者快速原型开发模型进行开发。如果使用V模型进行开发，开发者可以定义需求文档、设计文档等，测试人员也可以定义测试需求文档和测试用例设计文档。这些文档和传统的瀑布模型的文档不一样，传统的瀑布模型、V模型中，文档编写好后，需要经过严格的审阅，审阅修改完成后，一般不能再修改，即使后期要修改，需要严格的流程。Sprint周期一般较短，2周到1个月左右，要完成V模型的开发，需要快捷的流程及工具的支持。开发人员定义的需求文档，侧重于需求功能的描述及对应的验证规范，设计文档侧重于体系结构及外部接口等，而且这些文档在后期的Sprint中可以更新的，需要根据客户的反馈，增加需求内容或者更新需求，所以版本的控制非常重要。为了保证在该Sprint周期完成的功能复合规定的质量标准，每一个Sprint周期测试人员都要参与。测试人员根据开发人员的需求与验证规范，定义测试用例。功能开发完成后，测试人员负责功能的测试。
3.3.3 Sprint的成果交付与反馈
3.3.4 Alpha测试与Beta测
产品所有功能完成，交付版本给客户后，客户进行Alpha测试。由于产品开发的整个过程中，客户都见到产品，Alpha测试的反馈中，客户需求的变更非常少，更多的实际应用环境下问题的发现。Alpha测试的反馈，作为一个新的Sprint，该Sprint的Backlog列出所有的反馈问题，团队开发的主要工作是问题的修复。修复完成后，将产品交付客户进行Beta测试。Beta测试的反馈同样作为下一个Sprint的内容，该Sprint完成后交予客户进行验收，验收通过后，产品进行。Alpha测试与Beta测试的两个Sprint，需要在产品定义阶段进行定义，客户也可以根据需要选择其中的一个或者全部。
4 小结
传统开发模型不能适应经常变化的客户需求，而且客户在Alpha和Beta测试时才能看到产品，如果产品与用户的预期相差甚远，再提出需求更改已经太晚。而在SCRUM模型中，每一个Sprint都产生可交付的产品，客户可以见到产品，及时校正自己的需求。对于需求不太明确或者经常变更的项目，SCRUM的优势更为明显，越来越多的企业使用SCRUM来开发软件项目。对于需求明确的项目，传统开发模型有质量控制的优势。该文提出的基于SCRUM的大型软件开发模型，吸取了传统开发模型的优点，并在开发流程中综合使用瀑布模型、快速原型、V模型等，提高了产品开发的效率和质量。
参考文献：
中国社会经济的高速发展，推动了企业的发展与进步。企业管理者日益认识到有效发掘人才、科学评估人才对企业的发展至关重要。采用科学的方法对人员素质进行测评，是识别人才的较好的办法，有助于企业客观的了解人员个性特点与职业发展趋向，可有效降低企业招聘成本，规避可能存在的用人风险。在实践中，人才测评广泛应用到企业人才选拔任用工作中。很多企业引入了人才素质测评工具，对人员素质进行科学的评价和预测。
人才素质测评是综合运用管理学、心理学、行为科学、统计学、成功学及计算机技术等多种学科的知识，对各种人才的知识水平、能力素质、技能、个性、职业发展倾向等测评的方法，是一套定性与定量相结合的综合的评价体系。人才素质测评工具是现代企业进行人才选拔与培养的重要依据，可作为合理配置人才资源的重要依据。
一、人才素质测评的作用
1.人才评价
人才素质测评可综合评价人才的综合素质，如领导力、应变能力、创新能力、责任感及团队合作精神等。人才素质测评有助于企业对人才与岗位的匹配度与胜任力进行评价，为企业制订合理的人力资源规划、培养人才、建立人才梯队提供依据。
2.人才预测
由于国内外经济形势的发展，使企业处于变化环境中，企业部门设置、人员配置也随之要做调整。通过人才测评对员工的发展潜力进行了初步的评价，并对员工未来发展的可能性进行预测。有计划的帮助员工制订职业发展规划，为员工提供培训与成长的机会，也为企业发展做好人才储备。
3.人才招聘
在企业招聘工作中，招聘工作的质量对企业影响较大。人才素质测评能帮助企业全面了解人才，分析应聘人员与工作的匹配度，分析候选人能否胜任工作，从而提升人力资源配置效果，规避企业可能面临的用人风险。
4.人才诊断
企业发展到一定阶段，可能会出现平台期，企业发展缓慢、停滞不前，甚至会出现后退的现象。此时，可应用人才测评技术对企业关键管理岗位的人员进行测试与评估，找出管理人员存在的素质要求差异，进行综合的诊断，找出存在的问题并制定措施加以改善。
5.职业发展
企业在员工的选拔与培养过程中，即要考虑到企业的发展战略目标，还要在充分了解岗位特点与要求的基础上，考虑员工自身的特质与职业兴趣与工作的匹配度。对于员工来说，人格特点及职业兴趣等往往都是其职业成功的关键因素，人才的测评可对有效的对员工的人格特点、能力倾向等进行分析。
6.配置团队成员
一个有效的管理团队不是简单的组合，而是优秀人员的有机组合与配置。在组建团队时，要以互补为原则，综合考虑团队成员的能力、个性、经历、知识、性别等多种因素。通过对团队核心人员的系统测评，分析团队成员的工作动机、个性、能力等特点，合理配置团队成员，促进团队高效运作。
二、人才素质测评的内容
人才素质测评主要包括以下三个方面：
1.能力因素
能力是指在工作过程中体现出来的水平及完成工作的能力与具备的潜力。通常是指在不同种类的活动中表现出来的共同能力，如观察能力、思维能力、操作能力等。
2.个人风格因素
个人在处理事情时所表现出来的行为方式的不同即为个人风格因素。包括个人的气质、性格和行为风格等。
3.动力因素
对于员工来说能力与意愿是做好工作的两个重要因素。高能力、高意愿的员工在企业中比较受欢迎。高能力、低意愿的员工，在工作中缺乏愿望和动机，很难将工作做好。具备低能力、高意愿的员工可对其进行培养。低能力、低意愿的员工则是企业需要淘汰的。
三、人才素质测评的具体方法
1．履历分析
通过履历档案分析了解人员的成长历程和工作业绩。对其人格背景进行分析，可对其今后的工作表现有一定的预测效果。
2.笔试
对参试者的专业知识、管理知识、综合分析能力及文字表达能力等素质进行测评，对评测结果进行客观的分析，以了解参试者的能力要素。在人员选拔录用时可作为初期筛选工具，能在较大规模人群中加以实施。
3.心理测验
心理测验是对被观察人的行为进行评价，观察其代表性的行为，并对其心理特征进行测试的科学手段。是对被试者个性特点进行评测的工具，在人事测评工作中应用广泛。
4.面试
面试即通过与应试者交流沟通，了解其综合素质状况、能力特征等情况的方式。面试可分为结构化面试和非结构化面试二种形式。
5.情景模拟
情景模拟测验是通过模拟设置工作环境，要求被试者完成现实工作中的具体任务，根据被试者提交的工作文件来预测被试者的实际工作能力和水平。通常包含四种形式：一是文件筐作业。将实际工作中碰到的工作放入文件筐中，要求被试者在限制的时间内完成一系列的工作，对被试者的组织规划能力、分析判断能力与决策能力进行评价。二是无领导小组讨论。即将被试者组成临时任务小组，由他们共同完成给定的任务，并提交小组意见。在完成任务的过程中，测评人员对被试者的组织协调能力、语言表达能力、说服能力及责任心、人际关系处理能力、团队合作等方面进行考察。三是管理游戏。模拟现实中的管理任务，来组织被测评者完成，被测评者可借助各种工具或手段完成。通过活动考察被测评者的管理潜质。四是角色扮演。模拟实际工作情境，要求被试者扮演某一角色，有效处理预设的各种人际矛盾和人际冲突。
6.评价中心技术
【摘要】敏捷开发可以应对客户快速变化的需求，它强调以人为核心、采用迭代的方式、循序渐进地开发软件。笔者所在的政府机关小型开发团队近年来对敏捷开发方法有选择地进行了应用，在测试驱动开发、小版本、任务投票等方面取得了一些经验。
关键词 敏捷开发；政府机关；应用
作者简介：邱明明（1982—），男，汉族，江苏阜宁人，硕士，中国人民银行南京分行营业管理部副主任科员。
1敏捷开发的出现和特点
1.1敏捷开发的出现
传统的软件开发方法定义的过程往往大而笨重，降低了软件开发团队的开发效率和响应变化能力，形成了过程膨胀即“过程泥潭”。2001年初，由于看到许多公司的软件开发团队陷入了过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则：个体和交互胜过过程和工具、可以工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划，这就是“敏捷宣言”。
敏捷开发的方法很多，有极限编程、Scrum、特征驱动开发、自适应软件开发等。敏捷开发可以应对客户快速变化的需求，它强调以人为核心、采用迭代的方式、循序渐进地开发软件。在敏捷开发中，软件项目被切分成多个子项目，各个子项目的成果都经过测试并可以随时投入运行。敏捷开发要求项目团队全体成员之间形成更加有效的合作关系，使其灵活性更高，以适应不断变化的需求。
1.2敏捷开发的特点
与传统的软件开发方法相比，敏捷开发主要有两个特点。
1.2.1敏捷开发是面向人的而不是面向过程的
敏捷开发认为，人是软件开发中最重要的因素，而且人工作的环境很复杂。它强调软件开发应当是一项令人愉悦的活动，因此更加注重调动人的积极性、主动性和创造性，并培养人在工作中的自豪感。敏捷开发的理念就是信任项目团队能够很好地完成任务，所有的管理都是围绕这个理念展开的。敏捷开发的目的是建立起一个项目团队（包括客户、需求分析人员、设计人员、开发人员、测试人员等多种角色）全员参与到软件开发中。只有这样，软件开发流程才能在项目团队中得到最广泛的接受。敏捷开发还要求开发人员在技术上进行自主决策，因为开发人员是最了解什么样的技术是需要或不需要的。
1.2.2敏捷开发是“主动适应的”而不是“预先设定的”
传统的软件开发方法试图对一个软件项目在很长的时间跨度内做出详细的计划，并形成详细的文档，然后依照计划进行开发。这类方法在计划制定完成后往往拒绝变化，后期的需求变化将会花费极大的代价。敏捷开发则乐于迎接变化，其实，它的目的就是成为更适应变化的软件开发流程。
据统计，很多软件产品提供的功能中，客户常用的功能只占20%左右，其他大部分功能是客户很少使用甚至基本不用的。在这种情况下，采用传统的软件开发方法所设计出的功能，其实很多是不必要的，也将浪费很多资源。敏捷开发则要求客户始终参与整个开发过程，这使得项目团队可以不断地获得客户反馈，不断地适应需求的变更，从而使最终的产品充分符合客户的要求，也极大地减少了资源的浪费。
2敏捷开发在政府机关的应用探讨
由于条件所限，笔者所在的政府机关从事软件开发的技术人员较少且大多不是专职，往往身兼系统运维、科技管理等其他工作，因此政府机关的软件开发往往具有团队规模微型化、开发时间碎片化、项目文档简单化等特点,瀑布模型、RUP等传统的软件开发方法已不能适应政府单位软件开发的需要。笔者所在的小型开发团队近年来对敏捷开发方法有选择地进行了应用，在测试驱动开发、小版本、任务投票等方面取得了一些经验。
2.1测试驱动开发
作为敏捷开发最重要的组成部分，测试驱动开发要求实现的每一个业务功能都是从测试开始。开发人员首先对需求进行分析，将需求分解为一个个用户故事，然后根据用户故事，从需求的角度来编写测试代码（主要是单元测试、功能测试），最后依据测试代码来编写业务功能代码。
如果没有测试代码，就不能编写业务功能代码。先写测试代码，能够让开发人员明确目标，就是业务功能代码通过测试。当然通过测试并不是结束，测试覆盖率分析工具还可以直观地显示测试未覆盖到的业务功能代码。在测试没有100%覆盖业务功能代码之前，尽快完善测试代码显得十分必要。
测试驱动开发还方便了代码的重构。重构是在不改变系统外部行为的前提下，对程序代码的内部结构进行整理优化，使得代码尽量简单、易读、可扩展。值得注意的是，敏捷开发中的重构对代码的每一次改变要尽可能小，并用单元测试来验证重构是否引起冲突，并且要求不仅对业务功能代码进行重构，如果测试代码中有重复，也要对它进行重构。
刚开始推行测试驱动开发时，我们的开发人员觉得花费了不少时间在编写测试代码上，项目开发进度不是很快，还不如多花些时间在编写业务功能代码上。不过随着项目开发的不断深入，开发人员发现如果一个业务功能的测试代码写的比较完善，业务功能代码往往不容易出现缺陷，开发人员花在缺陷修复上面的时间比较少，在对代码进行重构时也很容易验证。
2.2小版本
在敏捷开发中，不会出现拿到客户需求以后就闭门造车，直到项目开发完成了绝大部分甚至最后才将产品交付给客户的情况，而是多次小版本产品。这样，客户每隔一段时间就会拿到的小版本产品进行试用，项目团队就可以从客户那里得到更多的反馈来改进产品。
在推行小版本后，很多时候我们发现客户提出的需求往往不那么全面，一些新的需求往往是在试用的小版本产品后才反馈给项目团队。因此，小版本在一定程度上有利于发现新的需求。而对于开发人员，正因为多次小版本产品，每一个版本新增的功能简单清晰，不需要很复杂的设计，也在很大程度上简化了设计。
2.3任务投票
在敏捷开发中，每次迭代都要求项目团队在一次迭代期间（一般两到四周）内，完成本次迭代计划里的任务。此时，选择哪些任务加入本次迭代计划需要项目团队的全体成员投票决定。
在投票会议上，项目管理人员列出下一步需要完成的任务，要求项目团队的每个成员对每个任务完成所需要的时间进行现场投票。如果出现不同成员投票结果相差很大的情况，项目管理人员要求相关成员说出理由，再由全体成员商量决定该任务完成所需要的时间。在确定每个任务完成所需要的时间后，项目管理人员根据本次迭代的截止时间要求，选择合适的任务加入本次迭代计划，保证迭代计划里的所有任务完成需要的总时间不能超过项目团队全体成员可用于开发的时间。
在推行任务投票时，我们的开发人员对于一个任务完成所需要的时间进行投票，往往会出现投票结果相差很大的情况。这主要是因为每个开发人员的经验和能力存在一定的差异，对一个任务完成所需要的时间会从自己的角度做出估计。敏捷开发要求，不管是哪个开发人员都要尽可能在项目团队全体成员投票决定的时间内完成该任务。在完成任务的过程中，开发人员充分调动了自身的积极性、主动性和创造性，也培养了在工作中的成就感和自豪感。
一、 沙盘模拟的简介
沙盘模拟是一种管理仿真游戏（Simulation Game），其思想源于军事作战指挥中用沙堆对地形地貌进行模拟，将外部环境和内部资源用直观的方式明白呈现，以便组织进行讨论决策。沙盘模拟通常设计为一场操作简单、过程直观的情境式任务，对复杂的管理问题进行模拟，使企业经营管理的各个环节简单化、直观化。这种游戏可以帮助参与者快速了解企业流程，“在实践中学习”管理策略。因而最初是用于管理教学引入中国。
由于沙盘模拟集角色扮演、案例分析和专家诊断于一体，又兼具游戏性强、操作性强、团队合作性强等特点，能够展现参与者多方面的能力素质，因而很适合作为一种测评技术。在有名的央视商战模拟比赛——《赢在中国》栏目中，就多次用到ERP（Enterprise Resource Planning）沙盘模拟，用以考察参赛者们的战略思维、团队合作、资源规划、分析决策等方面的能力素质。它的新颖性、直观性和趣味性也受到了一些企业的青睐，但比起结构化面试、无领导小组讨论等评价中心技术，仍不够成熟和缺少接受度。当前的学术研究也主要围绕沙盘模拟的教学培训作用，如软件工具的使用、考核模式、教学满意度等实证研究，缺少对将沙盘模拟作为一种测评手段的应用研究。
二、 运用于人才测评
本研究目的在于考察沙盘模拟的评价功能，并对测评效果进行效度分析。
1. 施测对象。考虑到沙盘模拟是一个团队游戏，团队内部有明确的分工，应试者需要承担不同的角色，这种情况很适合经营性企业的不同职能的应试者的招聘或选拔。在本研究中，选用的施测对象是某通信公司的员工，涉及策划、采购、营销、人力资源、技术五大职能部门共64人。
2. 测验工具。在模拟情境的设计上，选用根据“沙漠掘金”这一经典的ERP沙盘模拟游戏改编的“抗震救灾”情境任务。
“沙漠掘金”课程设计了一个几支探险家队伍分别穿越沙漠争夺金矿的模拟场景，通过设计天气变化，行程路线上的障碍，金币的使用、水和食物的采购等，将企业工作中的种种问题如战略管理、目标决策、资源配置、团队关系等折射出来。参与者们通过选择、决策、行动导致不同的结果，从而引发思索，自觉引导自身行为的改变。该课程目前已经被列入清华大学、浙江大学多家高校的EMBA课程；同时也被Coco-cola、Philips、上汽集团等多家公司采用作为内训。
“抗震救灾”的情境设置与“沙漠掘金”类似，不同之处在于将前往金矿掘金的任务变成了前往灾区救灾，成功的条件是最快到达目的地，以及所余的资源（包括水、食物和金币）总量最多。其他如出发前的准备，中途各队之间可进行资源交换，以及天气障碍等等都一样。
3. 评分方法。根据任务情境，结合中层管理者胜任特征要求，专家们讨论决定将“分析决策”、“计划组织”、“沟通协调”、“团队意识”四种能力素质作为测评指标要素。其具体含义见表1。计分采用10分制。评分标准为优：9.0～10.0；良：7.5～8.5；中：6.0～7.0；差：6.0以下；最小起评分为0.5分。
三、 测评的实施和结果
1. 测验的实施。事先将64名被试分为8组，分组依据是尽量使一组包含不同部门的人，也考虑到组员之间的自主选择。并每组配备一名专家，以在比赛过程中在旁观察记录，并根据评分表对各人表现进行打分。
在安静空旷的大厅中摆有8张桌子，每组组员在规定位置就坐。每人手中都发放有规则解说单，在主持人讲解完测评规则，宣布比赛开始后，众人开始讨论和决定。中央大屏幕显示时间和天气状况，每一组都必须在规定时间内做出决策，并有工作人员帮忙督促和随时更新各组数据。
2. 测评的结果。首先将各人得分汇总，结合各指标的分数高低和小组中的表现来判断应试者的角色类型（领导者、策划者、决策者、组织者、协调者、配合者、个人主义者、一般参与者），专家根据应试者在沙盘模拟环节的综合表现以及在团队中发挥的作用对被试形成综合性评价。
在本研究中，为了检验沙盘模拟的测评效度，在沙盘模拟测验施测之前采用《管理者素质诊断测验》（MCT）对实验对象进行了测量。《管理者素质诊断测验》（MCT）是国内人才测评C公司自主研发的管理素质测验工具，包含一千五百道管理情境性试题，考察七大类通用管理素质。经过多年的实践检验，拥有良好的信度和效度。在本研究中使用了“分析决策能力”、“团队领导能力”、“计划控制能力”、“沟通协调能力”四大管理素质分测验。
此处首先通过考察沙盘模拟和《管理者素质诊断测验》（MCT）的相容效度，来验证测评的有效性。将两种评价方式的结果进行标准分数转化，然后进行相关分析，得到表2。
一、工作职责
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）依照公平公正原则，根据开发任务的进度要求和团队成员的能力素质和特长，下达工作任务。
关键词：软件测试；测试策略；测试用例；测试件
中图分类号：F426.6 文献标识码：A文章编号：1007-9599(2012)05-0000-02
一、引言
随着计算机技术的迅猛发展，计算机软件已渗透到各个领域。人们对计算机软件质量的要求越来越高，要开发出高质量的软件产品，利用传统的软件测试方法已不能适应现在的要求，这使得软件的开发规模和复杂程度呈螺旋状递增。为了尽可能多地测试出程序的错误，开发出高质量的软件产品，势必加强对测试工作的组织和管理。
二、设计软件测试，排除“近忧”
（一）测试策略设计
软件测试策略主要考虑如何把设计测试用例的技术组织成一个系统的、有计划的测试步骤。在测试的各个阶段应选择适宜测试方法，由软件开发人员和一个独立的测试小组共同完成测试任务。对小项目做大测试和对大项目做小测试都是不应该的。通常，对于工作量小于5个人月的普通软件，应全面测试，重点进行功能测试、性能测试及验收测试等。而对于一个工作量接近30个人月的中型软件而言，不仅要注重系统测试，还应该认真完成单元测试、集成测试及验收测试等。
设计测试策略时应注意如下几个方面：1.测试成本与测试预期效果之间应达到最佳平衡；2.测试需求与测试活动安排之间应达到最佳平衡；3.设计策略形成的技术路线可行与否，有无设计依据；4.该的技术路线在工程实际与企业质量承诺之间应达到最佳平衡。
（二）测试方法设计
测试方法是对测试策略设计形成的技术路线的逐步细化，主要包括要测试的功能，准备输入的数据及其对应的预期输出结果。设计测试方法时，应考虑以下几个方面：测试成本与测试产生的效益是否处于最佳比值；每个测试活动是否描述清晰；测试手段是否可行；测试产生的结果能否改进产品质量。
具体设计测试方案时，最常见问题的就是测试人员少，而测试工作枯燥、繁重。加强测试人才专业技能、行业知识和个人素养，并建设高效测试团队是解决这一问题的根本途径。然而，远水解不了近渴。那么，可以寻求其他途径来解决。比如软件外包和外协、自动测试工具等都是解决问题的办法。
（三）测试用例设计
测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，是对测试方法实现技术部分的更细致、更具体的描述。由于不可能进行穷尽测试，因而设计测试用例时要选用少量的、高效的测试数据，尽可能找出更多的潜在错误，尽可能完善地进行测试。
等价类划分法（EP）是黑盒测试中典型的一种方法。等价类是输入条件都是等效的输入域的集合。EP法把程序的输入数据集合划分为互补相交的子集，即若干个等价类，包括有效等价类和无效等价类。在每个等价类中，作为代表的这组数据测试程序并发现错误。经验表明，大多数错误都发生在输入的边界值上。为此，专门引入边界值分析法（BVA），把它最为EP方法的补充。
白盒测试根据程序逻辑结构进行通路测试。要想穷尽路径测试往往做不到，但是尽可能选取有代表性的通路，对各种通路测试是可以做到的。这里值得指出的是，在不同的测试阶段，黑盒测试法与白盒测试法可发现不同类型的错误。因此，两种方法缺一不可，相辅相成，灵活运用，事半功倍。
三、管理好软件测试件，消除“远虑”
测试件是指在测试团队知识库中的所有输入和输出数据，并且这些数据必须受控于或者必须划入一切手工测试和自动测试活动中。测试件像其他软件一样，需要被管理和被工程化。
（一）测试用例管理系统
一个中等规模的待测软件，需要设计的测试用例往往有数万个之多，如果不进行专门的管理，测试人员很快就被淹没在测试文档及测试用例的海洋中。测试用例设计人员需要了解目前已经为哪些模块设计了测试用例？为哪些部件设计了测试用例？还需要完成哪些设计工作？而测试执行人员则应该清楚的知道“今天要测试什么？需要执行多少个测试用例？”等等。测试用例管理系统就是基于这些需求而开发的，其目的是为了提高测试活动的效率，统一管理该项目测试用例的设计、执行及执行结果等。
（二）配置管理
测试件可以使用配置管理的方式进行管理，但除了测试用例、测试缺陷报告之外。现提供两种配置管理方式。一种方式是把每一个的测试件作为配置项，每个测试件有各自的版本信息。这种方式适用于比较完善的配置管理体系，因为该方式基于一个或多个测试件组进行基线化。如若使用不当，可能导致使用的测试件版本错误。另一种方式是在配置库中将测试件组作为配置项进行保存。每个测试件组有各自的版本信息，而组内的各个测试件成员没有相应的版本信息。这种方式适用于不成熟的配置管理体系，因其操作简单，所以出现版本错误的可能性较小。
（三）测试件的复用与迁移
测试件可被复用，因此测试件中包含的知识和经验可被他人获取并应用到适合的项目中，这是管理测试件的又一个重大意义。测试团队内部人员之间能够有效地、充分地、完全地传递知识，这将从很大程度上提高团队的整体水平。各项目中所使用的大量的测试技术和获取的丰富的知识经验都记录在测试件管理库中，这些不仅对于团队中的新人而言，即使是参加测试工作多年的老手来说，都是非常宝贵的财富资源。因为测试件的复用与迁移能把人们从大量的、繁重的、复杂的、重复的、枯燥的劳动中解放出来。此外，测试团队负责人还应提倡团队内部成员在深入了解和学习测试件库的同时多提改进意见，让测试件库能长久地为人们服务。
参考文献：
[1]钱坤.层次化测试在银行系统的设计与实现
[2]郭群,卢海燕.软件测试基本技术
[3]侯海霞.基于软件测试技术的软件质量保证研究
（1）建立自组织团队。传统的管理方式具有命令和控制的特点，经理制定目标和计划，团队负责完成，发挥不出员工的创造力，影响了企业的效率。软件开发的敏捷开发要求员工自我管理，个人控制时间和目标，员工能参与流程和项目决策。
（2）用户故事在需求管理中的应用。软件开发企业最大的敌人不是用户，而是变化。瀑布模型难以适应目前软件市场需要，因此软件开发工作要取得用户的参与，顺应市场的变化。
（3）用户故事的度量，它能为产品投资收益提供估计结果，辅助产品决策。对故事点大小讨论时，能鼓励团队成员重复讨论，充分理解需求。故事点度量方式一致，提高统计团队工作效率。
（4）持续集成。它能提高项目构建自动化程度，将人力成本更多投放到开发任务。项目更有可见性，构建结果更加丰富，一目了然。团队对开发产品更有信息。
（5）掌握迭代，为员工提供稳定的生活节奏，保持一致的周期循环流程，沟通过程中控制时间。
（6）坚持反馈和改进，了解自身情况，改善团队效率。
精益生产的目标为提高质量和消除消费。看板原则要求生产降低库存量、降低生产周期、生产基于交叉培训和单元并对过程进行持续改善。如同超市进货一样，当货架上货物少于设定值，供货商会及时将其填满。将看板管理与敏捷软件开发结合起来，能够达到效率和质量的有效结合，软件产品周期频繁，能达到按天级别。
2.项目看板方法流程设计
增量迭代开发开发流程存在着三点问题。
（1）每个迭代的用户故事较多，产品经理和开发工程师认为很多功能没有价值，而项目经理认为需要跟踪的项目较多。
（2）对于为期四周的迭代观念不统一，部门不同，期望值不同，测试人员认为时间不充分，产品经理认为需要等待太长时间。
（3）部门之间缺乏协作，缺乏透明的项目进展和进度，太多时间花费在流程上。敏捷软件开发有三个典型流程，分别XP、Scrum及看板，经过比较，看板原则可以解决迭代用户故事较多的情况，对于规模小及优先级别高的用户故事能够迅速完成，并满足产品经理对产品的预期。
2.1 基于看板管理的敏捷软件开发流程方案设计
看板一般应用于汽车生产等工业领域中，在敏捷软件开发中看板管理只是理论上行得通，但是在实际上还缺乏经验。而且其受到产品特点、客户差异及企业文化的影响。其流程主要为，（1）定义并可视化流程；（2）限制WIP数量，流程可视化于物理板能够让项目透明，让团队对目前的任务充分明确。限制WIP数量则能让团队在思考时排除千扰，提高个体效率，项目工作不以来时间计划，而是取决团队能力；（3）拉动式生产，每个团队成员只需要对自己环节加以关注，等待任务-完成工作-到下一环节等待区^这种方式推动了产品开发前进步伐。
2.2 看板流程准备和实施
（1）是动员和人员培训，先获取领导层的理解和信任，再向所有员工培训敏捷开发和看板方法，最后，每个部门进行讨论。
（2）制定需求管理环节，产品经理提出产品需求，创建用户故事，技术团队估算用户故事工作量。通过需求分析，工程师能够获取信息，完成研发工作，产品经理全程辅助开发和测试，解答相关问题。
（3）开发流程改造，主要变化在对程序代码的管理方式进行改变，主要有主干和分支两种。
（4）测试流程改造，主要表现为两个方面，一方面提高系统自动化测试率来加快回归测试的进度，另一方面增加测试环境满足功能测试需求。
（5）项目管理流程的建立。
2.3 看板流程的实施
当所有准备工作完成之后，看板方法第36增量迭代之后，可以正式实施。产品经理将用户故事进行排列再制成任务卡，贴在用户故事一列，完成需求分析会议。开发组建立功能分支进行开发，测试组应用功能测试环境对用户故事进行测试，直到产品。团队成员每天早上聚集看板附近，明确自己的任务，下班前，项目经理将每天的任务卡状态变化汇总。敏捷流程要求强调团队自组织和员工自我管理，但是不可忽视项目经理的作用，项目经理能够组织人员，梳理工作节奏，保证沟通流畅，促进项目进展。
