时间：2023-02-03 16:58:47
导语：在软件测试项目总结的撰写旅程中，学习并吸收他人佳作的精髓是一条宝贵的路径，好期刊汇集了九篇优秀范文，愿这些内容能够启发您的创作灵感，引领您探索更多的创作可能。
关键字：软件；测试过程；管理
软件开发过程的质量决定软件的质量，软件测试过程的质量直接影响测试结果的准确性和有效性。
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年
[3]布莱克（美）.软件测试过车管理[M].北京：机械工业出版社，2003年
关键词：软件测试管理；测试团队；测试过程；事件管理；配置管理
中图分类号：TP311 文献标识码：A 文章编号：1674-7712 （2013） 04-0075-01
一、引言
现在，软件测试已经成为一个很有潜力的专业，软件测试可以提高质量，降低维护成本。
对于大型相对复杂的软件项目，做好软件测试就会相对困难，因此，为了尽可能提高软件质量，减少错误，必须有效对测试工作进行计划和管理。
要想对测试工作进行有效策划和管理，需要采取系统的方法建立软件测试管理体系，对测试活动进行监管和控制，以确保软件测试在软件质量保证中发挥应有的关键作用。
二、建立测试管理体系
软件测试的过程及应用即测试规划，设计，执行，配置与资源管理，缺陷管理等。从项目管理的角度来说，这些过程里，前一过程的输出是后一过程的输入。其中，配置与资源管理是这些过程的支持，测试管理对其他测试过程进行监视、测试和管理
三、测试管理过程和基本内容
（一）测试团队管理
做好软件测试需要一个独立的团队，测试团队独立于开发团队之外去做测试工作，可以更加公正的进行测试。虽然测试人员可能需要花时间去熟悉被测对象然后才能设计出测试用例，但是测试人员具备了专业的测试理念和设计技术，而这些测试技术是一个开发人员所没有的或测试前必须花时间去学习掌握的。
测试团队管理的主要任务：确定测试队伍的组织模式，确定测试需求和组织测试设计，估计测试工作量，安排测试任务，确定应交付的测试文档，管理测试工具。
（二）测试过程管理
软件测试贯穿于软件开发整个生命周期，在软件开发的每一个阶段，都有相对应的测试任务，从计划、设计、执行到缺陷管理、总结等步骤，构成了一个测试过程。（如图1）
因此，软件测试过程管理主要集中在测试准备、测试计划、测试用例设计、测试执行、测试结果分析，以及如何开发和使用测试过程管理工具上。
（三）资源和配置管理
1.资源管理包括人力资源和环境资源
人力资源：测试人员的数量及其测试技能，在测试的各个阶段中对人员和技能要求不同。
环境资源：建立测试环境所需要的计算机软件资源和硬件资源。硬件提供了一个支持操作系统、应用系统和测试工具等运行的基本平台，软件资源则包括操作系统、第三方软件产品、测试工具等。
2.配置管理
配置管理是是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
（四）事件（缺陷）管理
事件即缺陷管理，为了有效地管理缺陷（事件），在项目内应该引入规范、高效的缺陷（事件）管理系统。
软件测试的任务就是寻找缺陷，缺陷从被发现、分析、修改，到修改的确认形成了一个缺陷的生命周期（lifecycle）。在缺陷周期内要对缺陷进行跟踪。缺陷可能会在开发过程中被发现，也可能在评审和测试过程中发现，甚至在系统最后使用过程还会发现缺陷。缺陷可能在代码内、在运行的系统中、也可能在各种文档内。缺陷与软件的版本、运行的环境有关。缺陷与人员有关：测试员、开发人员、管理者和客户等
四、总结与展望
测试管理涉及的范围非常广泛，如测试组织管理、测试过程管理、事件管理、人力资源与配置管理、风险管理、进度管理等。软件测试贯穿于软件开发整个生命周期，软件开发周期模型为我们提供了软件测试的流程和方法，为测试过程管理提供了依据。但实际的测试工作是复杂而烦琐的，不会有哪种模型完全适用于某项测试工作。因此，在实际工作中，我们要考虑实际情况灵活地运用测试过程管理理念，依据这些理念来策划测试过程，以不变应万变。
参考文献：
[1]杨小平，王胜开.面向对象软件测试探讨[J].计算机科学，2009，36（11）.
[2]王文东，耿国华，张根耀.软件可靠性保证与评测技术[J].微机发展，2004（11）.
[3]叶言苓，崔彦军.软件测试管理的研究与应用[J].计算机应用与软件，2003（09）.
关键词：软件测试；企业需求；教学方法
中图分类号：TP311.53—4 文献标识码：A 文章编号：1007—9599 （2012） 14—0000—02
随着软件产业迅速发展，软件产品的质量成为人们共同关注的焦点，软件测试的作用和地位越来越显得突出，它是软件产品质量控制的具体实现环节及其根本保证[1]，社会对软件测试人才的需求量剧增，对软件测试人员的综合素质要求也越来越高。
但由于我国的软件测试技术起步比较晚，并由于主客观方面的种种原因，在大学计算机教育中，软件测试教育存在很多问题，无法达到《软件测试》课程教学的目的和要求，也无法满足业界对软件测试人才的需求。
一、教学现状
在目前的教学环境中，虽然《软件测试》是一门理论性和实践性都很强的专业课，但大多数院校在教学过程中，仍会忽视强调测试理论和相关基础的重要性。在理论教学过程中，不重视测试的基础教学，在培养过程中更多地停留在知识传授，忽视软件测试职业素质的培养，实际上，一个合格的测试人员除了具备测试专业知识外，严谨的工作习惯、良好的沟通能力和团队合作精神也是软件测试人员所必需的[2]。在实验教学过程中，一味依赖教材的理论内容，忽略思考的智力技能培养，所设计的实验内容不符合现实需求，软件测试的实践教学存在同社会脱节。在教学方法方面，传统教学方法形式单一，学生学习兴趣很低，自主学习能力较低。本文针对教学过程中理论教学、实践教学、教学方法三个方面，对软件测试人才的培养总结一些思考和心得。
二、思考和实践
（一）重视并渗透理论教学
重视软件测试课程的理论教学，基础的扎实与否直接影响了能力的可持续发展性。在制定课程大纲时，加大理论课时的分配，使学生从根本上认识到理论在课程学习中的重要性，不再简单的认为软件测试只是简单的“点击”等操作，而是一门对思考和逻辑要求很高的课程。好的软件测试人员拥有高敏感能力，高发散能力，高分析能力，而这些都是以扎实的理论基础为前提的。并在教学过程中，不仅仅以教材为理论传授基准，应结合项目中的实际测试场景和案例，加深对各个理论点的理解和运用，以树型结构串联零散的知识点，注重知识的内部体系结构，使学生系统的掌握测试的理论知识，锻炼思维发散和思考能力，从而引导学生对知识和技能进行举一反三、触类旁通的迁移。
将软件测试的思想深入广泛地渗透到所有的专业课程中。例如在各类程序设计语言基础课程中引入单元测试的思想，在软件工程课程中，强调软件测试的重要性，增强软件质量管理意识，在面向对象的分析和设计课程中，强调测试和开发并行并重的思想[3]。
（二）以企业需求作为实验教学的目标
1.以企业项目为教学内容
在传统教学中，软件测试实验的内容通常只单纯的利用教材上介绍的不同测试方法来“设计”实验，所设计的实验内容泛泛化，不仅不符合企业的需求，而且不符合项目测试中的完整性和规范化。在实际工作中，一个项目中所涉及到的测试技术和方法，以及这些技术的重难点，都很难在现有的实验教材中得以体现。而以项目为实验教学的方法，是以企业的需求和实践流程为出发点，在实验的教学过程中以项目为主线展开，以测试的流程由浅入深，把相关知识点融入到项目的各个环节中去，将项目完整的进行剖析，循序渐进[3]。
2.重视文档和流程
在企业的实际测试工作中，文档是非常重要的。我们以一个符合现实性的完整B/S模式的“图书管理系统”作为测试案例，该项目涵盖课程的主要知识要点和基本技能，项目大小和难易适中，提供给学生系统的代码、需求分析、概要设计书、详细设计书等必须文档[4]，只有具备以上资料，才可真实的模拟实际工作模式。通过文档，使得学生明白所测软件提供什么功能？是否符合用户的需求，设计是否合理，结果与设计是否一致，通过文档，使得学生一边熟悉系统一边思考软件研发者在设计过程中的遗漏点。文档，不仅是测试人员与开发人员之间沟通的直接桥梁，而且这种彼此的不断沟通以及思考，直接影响了软件测试的最终质量。同时，除了以项目为教学的基本单位，并强调文档在项目中的重要性，还要严格按照工作中的实际情况，将学生分成若干个项目组。项目组分别设置测试经理、测试负责人、测试组员等角色，各尽其责。这种强调文档，各尽其责的项目教学方式，更加符合企业的实际需求，并有效锻炼了学生的团队合作能力。
关键词：CDIO；软件测试；教学改革；分组教学
中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2014）03-0670-03
1 概述
软件测试技术是高职软件技术专业的一门必修的专业核心课程。该课程是针对软件测试员/程序员岗位的任职要求所设置的具有综合性质的课程，主要任务是通过对软件测试基础理论、技术方法、流程管理和使用自动化工具实施项目测试的学习，使学生了解完整的软件测试的工作过程，能对完整的项目进行测试的实施工作，从而实现与测试技能要求的无缝对接。但是笔者通过几年的教学发现，很多同学学完这门课程后只是了解了软件测试方面的相关知识，根本就不能够综合运用这些知识进行实际项目的测试工作。笔者通过分析总结认为最主要的原因是我们教学的过程中没有采用工程的思想，使得学生不能有效地把这些知识碎片整合到一起，当然就不能谈不上实际应用能力。
CDIO模式作为近年来国际工程教育改革的最新成果，它是“做中学”和“基于项目教育和学习”的集中概括和抽象表达，它以工程项目从研发到运行的生命周期为载体，让学生以主动的、实践的、课程之间有机联系的方式学习工程[1-2]。无锡商业职业技术学院软件技术专业结合自身的实际情况，对基于CDIO模式的高职软件技术人才培养方案进行了初步探索。软件测试技术作为软件技术专业的专业核心课程之一，在CDIO工程教育模式的指导下进行一系列的教学实践应用，取得了很好的效果。
2 传统教学模式存在的问题
现代IT企业需要具有较高专业技能、职业素质和团队协作能力的实用复合型人才[3]，但
高职院校软件专业培养出来的人才普遍只是掌握了相关的知识，而不能有效的利用这些知识进行实践应用。为了解决这个问题，各个院校的软件技术专业都一直在尝试探索更好的人才培养方案[4]，主要的专业课程也在进行各种各样的教学改革[5]。因此，几年来，“实践教学”、“案例教学”、“情景教学法”等等教学模式进行了进一步的应用，但是在这些传统的教学模式下，还是存在一些问题。软件测试技术课程也是如此，存在的问题主要有以下几个方面：
（1） 实践教学死板化。各个院校的软件技术专业在人才培养方案的制定中，都明确规定了课程的实践教学环节，体现了对实践教学的重视。以作者所在专业为例，规定专业课程的实践课时比例至少达到50%。但是在实际教学中，实践教学一般都是教师通过案例先讲解演示，学生再模仿训练，总体还是采用填鸭式的教学方式，因此造成学生一开始还表现强烈的新奇感，对课程学习充满着动力和信心，但是由于无法真正调动学生的主观能动性，随着教学的推进，学生逐渐失去学习兴趣，后面的实践训练只能是敷衍了事。并且，由于课堂教学课时的限制，实训机制死板、不健全，使得学生的真正动手机会还是很少。
（2） 项目教学虚拟化。教学过程中，案例教学法得到了普遍的应用。以软件测试技术课程为例，包括一些具有软件测试精品课程的院校，无非都是采用了比如三角形测试、NextDate案例测试、飞机票订票系统等作为教学案例，虽然使学生对相关知识和技术有了更深入地认识，但是这些项目大多都是虚拟项目，这些虚拟项目主要存在两方面的弊端：一是功能过于单一，内容陈旧，只能起到说明相关测试技术的作用，却与实际应用脱节，缺乏实战性，使得学生在真正面对一个综合项目的时候却感觉无从下手。二是由于每个项目功能单一，不能把一个完整的项目贯穿于整个课程的教学，通过这些虚拟项目，不利于培养学生形成从测试计划、测试执行、测试用例设计到测试报告的整个测试过程的工程思想，也不利于发掘学生自身的潜能。
（3） 知识内容缺乏系统化。教学过程中，授课教师只关注学生知识点的掌握，而忽略了知
识点之间的系统联系和实际应用，使得学生一知半解，不知道学习这些知识点的用处，也不知道如何把所学内容运用到实际项目当中。在这种情况下，学生的工程管理、项目规范、项目文档编制、团队协作和沟通能力没有得到有效提升，因此难以满足企业对综合素质人才的要求。
3 CDIO模式在软件测试技术课程中的应用
在CDIO模式指导下，我院软件技术专业课程体系围绕软件产品开发为主线，以每位同学都要参与几个项目开发为目的进行课程安排。在整个课程体系中，将CDIO项目按规模和范围划分为三级，一级为包含软件专业主要核心课程和能力要求的项目。我们选取了与企业合作开发的实际案例：洗衣管理系统和校外实训系统；二级为包含一组相关核心课程、能力要求的项目。主要是阶段实训和综合项目实训项目；三级为单门课程内为增强该门课程能力与理解而设的项目，其中三级项目的设立与否及形式由各门课程大纲根据需要确定。
在软件测试技术课程中，我们把CDIO模式贯穿于教学过程的每个环节，从如下几个方面对课程进行了教学改革和实践应用：
3.1 教学目标和内容
在CDIO模式下，软件测试技术的教学目标为“掌握软件测试的理论知识，掌握主流的测试技术和方法；具备测试计划的制定能力、测试用例的设计能力、测试代码及文档的编写能力；具有良好的分析问题和解决问题的能力以及沟通和团队协作能力；具备自主学习和可持续发展能力”。
在课程内容方面，我们基于CDIO的构思、设计、实现、运作的思想，贯穿“做中学”和“基于项目教育和学习”的方式，以工程项目从研发到运行的生命周期为载体，把软件测试技术课程的内容分成五个项目任务。并且在课程中，选取校外实训系统和洗衣管理系统的测试作为贯穿于整个课程的任务。在这两个项目的引领下，实施课程教学。课程的五个项目任务如下表所示：
3.2 教学组织
在CDIO模式下，为了使学生由接受者转变为主动参与者和积极探索者，在发挥教师主导作用的同时，充分发挥学生的主体作用。在教学组织方面，我们采用行动导向的教学模式，以小组模式为基础组织教学。在具体教学过程中，我们对学生进行分组，让每个学生充当企业中的真实角色，以一个职业人的身份，在真实的工作环境中，模拟软件企业工作模式，每位同学承担工作岗位相应的责任和任务[6]。课堂教学也不再采用“教师演示讲解、学生模仿练习”的模式，每一次课堂教学，教师先演示项目，提出任务需求，进行必要的知识讲解，然后教师为学生发放项目任务书，再由组长带领小组成员分析项目任务，探讨实施方案，撰写任务计划，完成项目任务，并提交相关文档。在整个任务完成过程中，授课教师不断和学生交流，对于学生在完全任务过程中存在的问题，指导学生解决。这样，不仅能够调用学生的主观能动性，引导学生思考问题，解决问题，并在解决问题的过程中研究新的实现方法，而且突破了传统的以学校和课堂为中心的封闭式教学组织形式，将实际生产与学习真正融合为一体，在掌握业务知识、培养技能的同时，培养敬业精神、团队意识和职业道德等综合素质，使师生在职业岗位中学习，在学习环境中工作。
3.3 教学手段
在教学手段应用上，充分利用现代教育技术，采取密切的产学结合方式，聘请企业兼职教师进行实践指导，并充分利用网络平台和网络教学资源。授课教师在课堂上通过多媒体教学的方式讲解重点难点问题，相关的项目任务探讨和知识扩展通过网络化平台进行。对于网络化平台，我们主要采用两种方式：一是建立课程QQ群，为学生提供一个资料共享和课程讨论和交流的平台，二是要求学生访问中国测试网，通过论坛和专业测试人员和其他测试学习者进行沟通交流。在网络教学资源方面，要求每一位同学使用高等职业教育软件教学资源库网站，访问网站的课程资源和培训资源，其中软件测试的课程资源包括：学习指南、授课录像、实训指导、课程案例、参考和素材资源等方面。通过这样的方式，能够解决课堂教学课时的限制，使得课程的教学从课堂延伸到课后，对学生可持续学习的能力具有很大的促进作用。此外，利用与江苏微软技术中心的合作优势，邀请他们在期末来校进行项目实训指导。
3.4 考核方式
根据CDIO培养大纲，将学生的能力分为工程基础知识、个人能力、人际团队能力和工程系统能力四个层面[7]，再使用传统的考核方式已经不能满足要求。软件测试技术课程打破了单一的考核方式，从学生的专业能力、社会能力培养的要求出发，建立基于教学全过程、以学生能力提升为导向的学习评价体系。具体包括过程性考核、综合素质评价和终结性考核。其中过程性考核占30%，综合素质评价占20%，终结性考核占50% 。
过程性考核：对学生完成实践类项目的情况进行综合评定，考查项目包括课堂学习、小组学习、创新能力、课堂实践和实践报告等方面，每一个项目的考核都制定严格的评分标准。
综合素质评价：对学生在平时学习和实践中表现出来的职业素养进行综合评定，主要包括团队协作能力、沟通交流能力、分析和解决问题的能力、自学能力、工作态度等方面，并对这些方面制定出严格的评分标准。
终结性考核：建立试题库，实施考教分，在期末对学生进行包括笔试和上机考试的综合测试。其中笔试考查学生软件测试的基础理论知识以及对测试理论的应用能力，该部分占终结性考核的60%；上机考试通过对实际测试项目的工作过程进行检查和考核，对任务完成情况进行考核，还包括对测试工具运用的考核，该部分占终结性考核的40%。
4 结束语
通过在CDIO模式指导下进行软件测试技术课程的教学，解决了传统教学模式存在的主要问题，为达到学生的知识能力与测试技能要求之间的无缝对接奠定了良好的基础。下一步的工作是进一步完善CDIO模式在软件测试技术课程中的应用，并把这些经验总结应用到软件专业其它课程的教学过程当中。
参考文献：
[1] 顾配华.以设计为导向的EIP-CDIO创新型工程人才培养模式[J].中国高等教育，2009（3）.
[2] 查建中.论“做中学”战略下的CDIO模式[J].高等工程教育研究，2008（3）.
[3] 单光磊，韦良福.高职教育教学改革借鉴CDIO模式解析[J].山东水利职业学院院刊，2011（1）.
[4] 唐宝燕，冯娜.CDIO模式在高职软件技术专业教学改革中的应用[J].电脑知识与技术，2012（2）.
[5] 陈翔，鞠小林.卓越计划驱动下的软件测试技术课程教学改革[J].计算机教育，2013（13）.
案例教学是软件测试教学中的常用手段，对学生理解测试方法有着很重要的作用，但是目前高校教学普遍存在着教学案例陈旧过时，大部分教学都沿用了传统的教学案例。这些案例大都没有介绍软件测试的工程方法和实现过程，并且没有进行难度的区分，很难达到好的教学效果。
本专业的教师经过多年的实践，总结了大量的教学经验，按照实际工作中典型的工程师团队所需的各种技能知识为导向，按照复杂度渐增、螺旋递进的原则设置卓越软件工程师课程体系与内容，把传统的以学科知识的系统性为导向的横向课程体系改造为以个人职业角色发现和能力提升为导向的、适应团队教育培养的新型纵向课程体系。软件测试课程是软件工程卓越工程师培养课程体系的重要组成部分，课程总体跟随整体培养课程体系的大方向，并结合自身的特点进行建设。
1复杂度渐增式开设课程
在传统的以面向开发为主的培养模式下，测试课程设置单一，知识针对性连贯性不强。为了解决这些问题，在专业课程开设过程中将软件测试课程课程拆分，穿插到整个培养过程中，紧密联系软件工程其他阶段的课程，并且使用案例贯穿所有阶段，复杂度逐渐递增，让学生在学习过程中循序渐进，逐步建立学习的兴趣和信心。在第5学期分成两个阶段分别开设《单元测试与软件质量》和《软件验证与确认》。在第一阶段旨在培养学生小规模程序测试的能力不涉及复杂系统，以提高个人开发测试的基本能力为目标，学生可以运用测试课程中学习的方法在开发过程中使用，针对性强。第二阶段旨在培养学生对系统整体测试的能力，此时学生以完成基本开发能力的训练，其他相关课程的培养中也进入了系统级别。在该阶段以上一阶段培养的能力为基础，提高复杂度，跟软件开发其他阶段紧密结合。完成第5学期的测试基础课程开设之后，在第6学期还开设了《web软件测试》、《测试案例分析》、《数据库测试》等专业选修课，给有兴趣的学生提供更多的学习选择。
2基础与实践并重，充分利用虚拟实践平台课程
的开设充分考虑到测试重实践，并且与软件开发其他阶段联系紧密等特点；同时也考虑到了此时学生正处于学习阶段，直接参与实际项目对学生的学习并不能起到很好的作用，因此在课程学习阶段充分利用了校内软件实训基地，创建网上“虚拟企业”，引入企业管理模式，在这种虚拟平台下，针对基础的知识点开设虚拟项目[3]，模拟软件测试的真实工程环境。学生在自己组合团队中有各自的工程任务，针对性实用性很强，学生能够在完成自己任务的同时感性的认识测试岗位工作，体会到软件测试在整个软件开发过程中的作用，将单项知识技能之间关联在一起，系统的运用专业知识和技能。
3采用螺旋式的案例教学，案例与其他软件开发阶段贯穿
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结语
敏捷开发中的软件测试应当遵循敏捷开发的基本原则，面对不同的开发方法和应用环境，软件测试方法也不同。敏捷测试作为从敏捷开发中成长起来的测试方法，与敏捷过程密不可分，本文对敏捷开发中的软件测试特点和方法进行了详细描述。然而，真正在面对软件测试时，测试用例的生成与覆盖标准、测试的充分性和有效性、不同阶段的测试关系等，以及如何将传统测试中的一些方法应用到敏捷测试中，需要探讨的问题及方法仍然很多。
摘要：通过校企合作能够有效支撑应用性本科和高职高专教育人才培养的校外实践教学基地、学生实习基地和教师职场体验基地，建立毕业生质量追踪调查机制、用人单位对学校和学院教学质量评价和反馈机制。本文介绍了我院在校企合作构建特色专业课程方面的探索。
关键词：特色专业；软件测试；校企合作；高职高专
中图分类号：G642
文献标识码：B
1引言
计算机应用技术是一个应用范围很广的专业，可以从事计算机行业的几乎所有工作。因此，计算机应用技术专业学生应学习的内容很多，内容涵盖很广。对于高职学生来说，三年学习内容不可能涵盖所有的计算机应用领域。因此，必须对该专业定向。而专门化方向须根据市场需求方能确定。为此，我们在北京及周边等地进行专业调研，了解社会对计算机应用技术专业学生的就业岗位、能力与素质需求。并由此确定计算机应用技术的专业化方向为软件测试。
旺盛的社会需求是人才培养面临的最大机遇，教育发展的最大动力是社会需求。软件测试专业就是一个朝阳专业，社会需求较大，以就业为导向构建高职计算机应用特色专业人才培养模式及课程教学改革研究，将按照“就业导向明确、层次定位准确，培养模式先进，专业特色鲜明，人才质量优良”的要求，推进人才培养模式、课程体系和人才培养质量。
以计算机软件测试方向作为高职计算机应用特色专业的研究与建设是新的探索。一个正规的软件开发项目应该包括软件开发和软件测试两大部分，而且旨在提供质量保证的测试部分应该占更大的比重，国际上标准的软件开发和测试人才的比例应该为1:1或1:2，而目前国内这个比例则为5:1。计算机软件测试专业在国内尚属待开发专业，就业前景非常看好。但由于是新专业，现有的中青年教师在授课之前基本没有系统的软件测试理论和工程实践、更无教学经验。基于这种情况，就更加应该尽快开展专业研究和建设，并借助于各方力量，以提高教师的理论水平和实践能力，使他们能尽快掌握理论和具备实践能力，承担起教学与实践任务。
2计算机应用特色专业建设思路
由于国内软件开发和软件测试人员比例的严重失调，行业急需软件测试人才。而该专业正在创建和开发时期，没有教学经验。基于这种情况，开展特色专业人才培养模式及课程教学改革研究，是很有必要的。为了使软件测试专业教学更加贴近教学，使教学更具针对性，教学素材、案例更符合实际需要，必须引进实际项目，聘请校外专家，及时与实力雄厚的教育集团及企业合作进行专业共建。
特色专业建设的目的是：寻找促进人才培养与市场需求紧密结合的路子，突出软件测试专业方向应用性人才培养特色，加强学校与社会企业的合作与交流，构建适应社会发展需求的产、学、研合作教育平台。提高教师教学科研能力和技术实践水平，带动学校学科专业结构调整和人才培养模式创新。建设能够有效支撑高职高专教育人才培养的实践教学平台，建立毕业生质量追踪调查机制，为学校摸索出一条构建特色专业课程的新路。
改革创新软件测试专业人才培养模式，深入研究校企专业建设内容，真正将行业所需人才应具备的知识、技能引进到专业人才培养过程中，确保专业建设内容的先进性与实用性。
人才培养模式以培养学生的全面职业化素质、技术应用能力和就业竞争能力为主线，充分利用学校和企业两种不同的教育环境和教育资源，通过企业与学校的长期合作和双向互动，将在学校的理论学习、基本训练与在企业的实际工作经历有机结合起来实现高素质高技能人才培养。
在开展本课题研究时，我们将本着“面向实际、站在前沿、重在应用、加强合作”的指导思想，努力创造一种团结民主、互帮互学、求实创新的科研氛围，力求做到边学习培训，边研究应用，边推出成果，边总结推广，力求通过三年的研究，在课程体系设置、实训基地建设、师资队伍建设、毕业生就业引导等方面，探索出一套“高职计算机应用――软件测试专业人才培养”的新模式。
3课程体系的建设
课程体系从原来的以学科为体系的课程设置转变为以能力为主线的课程体系设置，即先按各专业方向对岗位能力的要求，及每岗位能力从入门、基础、应用到综合的过程来设置课程。根据软件测试的特点设计了个性化的课程体系，确保学生们能够学成上岗。课程体系按以下几个模块来实施：
3.1基础课程阶段教学计划
3.2集中实训阶段教学计划
3.3职业素质培养教学计划
4专业建设研究目标
4.1技术路线和实施步骤
软件测试特色专业的研究，主要是以就业为导向构建高职计算机应用特色专业人才培养模式及课程教学改革研究，研究计算机应用特色专业如何与社会需求密切结合的专业发展模式，培养学生的软件测试的实际应用能力，加强专业建设和人才培养，让教师与学生的培养一起成长，培养学生具有较强的实践能力、岗位适应能力、创新能力的从事软件测试的高等技术应用性专门人才。主要从以下几个阶段实施：
第一阶段(2008年9月~2009年8月)
该阶段是基础课和专业基础课程的改革和建设，主要由教研室负责这部分课程的建设与授课、课程资料及辅助科学软件的开发。把开发小型应用系统作为教学的主线，鼓励和引导学生参加项目建设。为后续课程的学习奠定基础。
第二阶段(2009年9月~2010年8月)
该阶段通过构建软件测试的基本概念框架，掌握使用软件测试系统中软件测试的基本方法、基本技能等。从软件测试的基本概念到单元测试、集成测试、性能测试的实践活动，设计与课程密切相关的单元测试。
第三阶段(2010年9月~2011年8月)
该阶段是软件工程与测试实验室搭建、软件测试平台搭建及综合实训基地建设搭建。该阶段需要借助多方力量进行专业课程的构建、进行软件工程与测试实验室搭建、软件测试平台搭建等实训课程的实施阶段。
第四阶段(2011年9月~2011年12月)
该阶段是结题阶段。收集、整理子课题结题实验报告，举办课题成果评奖活动；撰写课题结题报告，发表相关论文，上交申请成果评估验收；课题组结题大会，成果出版与展示等。
4.2研究假设和拟创新点
(1) 结合所学课程，让学生直接参与公司项目开发，有利于学生职业能力的培养。通过校企合作探索软件测试人才培养模式，涉及到的合作机制、教学机制、运行机制的改革与创新。
(2) 通过课题研究，促进校企合作，以及人才培养与市场需求紧密结合，突出软件测试专业方向应用性人才培养特色，构建适应社会发展需求的产学研合作教育平台。
(3) 以就业为导向，围绕专业核心能力，构建课程体系；通过产学结合，建设优质核心课程，制定课程标准，编写适用教材；建设双师结构的教学团队和校内外实训基地。
(4) 将传统的课程进行整合，理论够用为度，以讲座、学术报告等形式增加现实社会所急需内容。课程模块化教学，采用“事件驱动”式的培养方式，根据就业岗位确定课程设置，培养学生的基本技能。根据社会的需求大力实施订单教育。
(5) 从课程学习到课程设计、毕业设计各阶段，贯穿实施项目教学法，在项目教学中，学习过程成为一个人人参与的创造实践活动，注重的不是最终的结果，而是完成项目的过程。
4.3专业建设的预期目标
学院与企业合作，实施实训人才培养模式，共同致力于软件测试应用人才的培养，开启我院计算机应用人才培养与企业需求零距离对接的先河。注重人才培养的针对性和实用性，可以有力地促进我院教育教学的改革，提高办学效益，实现学校、企业、学生“三赢”，产生良好的社会影响。使学生掌握必需的科学文化基础知识和软件测试等方面的专业知识，具有较强的实践能力、岗位适应能力、创新能力的从事软件测试的计算机技术应用性专门人才。特色专业预期培养目标如下。
5结束语
计算机软件测试专业正在创建和开发时期，以就业为导向构建高职计算机应用特色专业人才培养模式及课程教学改革研究是新的探索。总之，高职计算机应用特色专业教学改革是培养数以亿计高素质劳动者和数以千万计高技能专门人才的需要，且大有文章可做。只要我们在教学实践中不断探索，不断总结，高职计算机应用特色专业的教学改革就一定能结出丰硕果实，高职计算机教育就一定能为社会培养出“适销对路”的计算机应用人才。
参考文献：
[1] 朱鸿,金凌紫. 软件质量保障与测试[M]. 北京:科学出版社,1997.
【关键词】软件测试 教学改革 软件测试工程师
【基金项目】2015年中央高校基本科研业务费专项资金项目“C程序代码级内存缺陷的充分性检测技术研究”（15CX02050A）。
【中图分类号】G64 【文献标识码】A 【文章编号】2095-3089（2015）09-0229-01
一、引言
随着软件产业的迅猛发展，软件的复杂性也日益增加，导致对软件的质量提出了更高的要求，这也使得软件测试工程师成为每个软件企业都不可或缺的技术人才。“软件测试”就是一门培养软件测试工程师的专业课[1]，本课程较为系统的介绍了软件测试的基本理论、测试方法、测试过程以及常用测试工具等内容。本课程知识的掌握将为学生系统的掌握软件工程知识体系以及毕业后从事软件测试、软件开发等职位打下良好的基础。
如何扎实有效的培养软件工程学生在软件测试领域既具有理论基础、又具有工程实战能力，目前许多软件工程专业教育者进行了积极的探索 [2-4]。我校软件工程专业已入选山东省卓越工程师培养计划[5]，为了执行国家对软件工程专业卓越工程师培养的精神，融合学校的“三三三”培养体系[6]的顶层设计，以贯彻培养理论扎实、具备工程实践能力、创新能力强、适应经济社会发展需要的高质量软件工程师为目标，我们也在软件测试课程的培养方案、课程结构、教学方法和考评体系等方面进行了一系列的改革和探索[7，8]。其中最为重要的改革是借鉴CDIO（Conceive-Design-Implement-Operate）工程教育理念，落实了“基于项目的教学”方法，增开了大量的课程设计和综合实践环节，在理论教学的同时注重了工程实践能力得培养。
二、“软件测试”教学面临的问题
“软件测试”课程的已有的教学改革改善了教学效果，但是由于传统的教学方法依然影响着教学，所以目前的软件测试课程教学过程中依然面临一系列问题。
（一）教学内容抽象，学生学习兴趣不高
软件测试是软件工程知识体系的九个知识域中理论性最强的一个知识域，必然造成软件测试教材与教学内容较抽象。目前，软件测试课程教学中普遍存在着理论教学偏重的特点，扎实的理论素养是卓越工程师的必备基础，但是即便对于软件工程专业的本科学生，也欠缺软件项目的实际开发经验，所以课程内容的抽象性增加了学生对课程内容的理解难度。为促进学生对理论知识的理解与应用，必须结合软件测试的课程特点，将抽象的内容分化到软件测试过程的不同阶段中，并采用相应的测试工具体现测试的方法，再应用于教学案例，才能促进学生对抽象的测试理论知识的理解与应用。
（二）教学内容碎片化，学生没有完善的测试知识体系
按照软件开发过程的要求，软件测试是贯穿于整个开发过程的一项活动。而在教学中，软件测试的理论出现了割裂，各知识点呈现碎片化，理论内容与实际的软件测试流程不同步。将不同的测试理论与方法进行了分割，这样利于教材内容的安排以及教学内容的组织，但这也必然造成教学内容碎片化，学生形成不了一个统一的测试理论框架，难以把握所学的理论与方法在软件开发与测试的过程中如何应用。为促进教学效果，有必要基于软件测试过程，定位软件测试的介入点，在不同的介入点进行理论知识的分配，形成一个以软件测试过程为主线、各理论知识在介入点进行分配的鱼骨图式的软件测试理论知识体系。
（三）轻视测试工具应用，培养的学生与企业需求难以衔接
因为软件测试方法众多，这也造成有大量可选的软件测试工具。虽然工具的培训是培养卓越工程师的一个必备环节，然而卓越工程师的培养毕竟不等同于职业教育，不能只是简单的掌握一个测试工具，而应该了解测试工具所体现的测试理论、所适用的测试阶段以及所应用的场景。在进行测试工具培训锻炼的同时，必须结合所讲授的测试理论，以及该工具适用的测试过程与测试场景。为了全面的掌握各种具有代表性的测试工具，需要搭建一个测试工具箱。
（四）教学案例简单，学生没有完整的测试思路
因为理论知识碎片化的讲授，也造成目前教学中只能采用简单的案例，简单的案例虽然有助于学生对具体测试方法的理解，但是难以融会贯通的掌握对一个完整项目的测试。为此，需要基于鱼骨图的软件测试理论知识体系，精心设计能够贯穿整个测试流程的案例，并有必要设计不同类型的案例，形成一个分层次、分类别的测试案例库，以保证对各种测试方法的掌握。
（五）学生对软件测试存在认识偏差，缺乏从事软件测试职业的意愿
目前国内软件行业依然蔓延着“重开发、轻测试”的观点，这种观点也延伸到软件工程专业的教学中，导致部分学生对软件测试这个职业存在认识偏差。这就要求软件测试课程需要从原来偏重理论讲解、学生欠缺软件测试训练的教学中摆脱出来，应该与软件测试工程师要求的能力培养集合起来，注重理论培养的同时，加强与软件测试职业的衔接，增设对软件测试工具的训练，加大基于案例与项目的实战训练，通过工程能力的培养以加深学生对软件测试的正确认识。
三、总结
为了执行我校软件工程专业的卓越工程师培养计划，解决“软件测试”教学中存在的上述问题，我们计划在已有的教学改革基础上，提出“方法为基、过程引导、工具跟进、案例贯穿”的“方法-过程-工具-案例”四位一体的教学方法，以解决目前“软件测试”课程中存在的诸多问题。
本文分析了“软件测试”这门课程随着卓越工程师培养、研究型教学的要求下在理论培养与工程能力训练等方面逐渐显露出的各种亟待解决问题，只有充分认识到这些问题，才有可能针对问题进行教学改革，进而培养理论与功能能力具备的软件测试人才。
参考文献：
[1]吴春雷， 刚旭， 张俊三. 基于“卓越计划”的软件测试类课程改革[J]. 计算机教育， 2014，11：88-91.
[2]李月龙. 高校软件测试课程教学改革研究[J]. 计算机教育， 2014，7：16-18.
[3]邓松. 递进式软件测试创新人才培养模式研究[J]. 计算机教育， 2014，7：5-7.
[4]周雪妍， 林泽鸿， 罗秋滨， 路雯靖， 刘玉利. 软件测试技术四面体培养模式的探索与研究[J]. 教学研究， 2013，5：56-58.
[5]张国平等. 软件工程卓越培养计划的研究与设计[C].软件工程2011年会，2011，10.
[6]刘华东. 构建“三三三”培养体系 推进本科教育迈向更高目标[J]. 中国高等教育， 2012，18：34-36.
[7]吴春雷. 面向应用型软件人才教学模式的探索与实践[J].中国成人教育， 2014.04：124-126.
[8]张国平，吴春雷. 软件工程专业核心课程案例化教材的规划与设计[J].高等理科教育，2013.10：85-87.
关键词： 探索性软件测试； 嵌入式系统软件测试； 基于会话的测试管理； 敏捷测试
中图分类号： TN911?34； TP311.5 文献标识码： A 文章编号： 1004?373X（2014）20?0074?06
Exploratory software testing approaches and their application in embedded systems
LIU Xi
（Nanjing Research Institute of Electronics Technology， Nanjing 210039， China）
Abstract： To apply the exploratory testing technology to the software testing of embedded systems is one of the promising ways to solve the problems including tight schedule， heavy tasks and incomplete software documentations. Rigorous testing management process and documentation are usually required for testing embedded systems， which is however weakened in exploratory testing. In order to guide proper application of exploratory testing in embedded system software testing， it is necessary to survey and review exploratory testing technology， analyze the correlation and conflict between exploratory testing technology and software testing system of embedded systems. Based on the survey， some suggestions are given on the application model in software testing of embedded systems. The problems andfollow?up study concerning the application are also discussed.
Keywords： exploratory software testing； embedded system software testing； session?based testing management； agile testing
0 引 言
软件在嵌入式系统中的作用越来越大。软件的质量不仅直接影响任务的成败，也关系着设备甚至人员的安全。随着用户对嵌入式系统软件质量要求的提升，软件测试已成为嵌入式系统交付前必不可少的环节[1]。
经典的测试方法要求依据软件需求和设计文档，遵循既定的测试流程，严格按照预先设计的“脚本”开展。因此经典测试方法也称为脚本测试（Script Testing）。随着嵌入式软件迭代的加速，给软件测试留出时间逐渐减少。嵌入式系统软件测试呈现出一些新特点，包括软件需求变化快、软件文档缺乏、软件测试周期短、测试时间不足等。
探索性测试（Exploratory Testing）具有在时间短和文档不完善的情况下，充分发挥测试人员的经验和能力，快速、高质量完成软件测试等优点。已形成了一套管理方法和应用模型[2?3]，并在微软等多个企业开展了成功的实践[3?5]。探索性测试方法关注于实用，对它的研究也多数集中在实际应用方法而不是理论研究上[3，6?8]。
探索性测试是解决嵌入式系统软件测试需求变化快、软件文档缺乏、测试周期短等现实问题的可行手段之一。为了恰当运用，需要总结探索性测试的一般性应用方法体系，并探讨其与嵌入式系统软件测试体系的联系和冲突。在此基础上提出适用于嵌入式系统软件测试的探索性测试应用模型。
1 探索性软件测试的基本原理
探索性测试的概念形成较早，经过随后的发展已形成了一定的应用体系。
1.1 探索性软件测试的概念
传统的软件测试分为测试需求分析、测试策划、测试用例设计、测试执行和测试总结等主要阶段，依次开展[1]。传统软件测试流程依赖于完整、详实的软件需求和设计文档作为输入。而在现实的测试任务中，软件需求和设计文档往往有误或不完备，这导致脚本测试活动无法正常有效开展。
“探索性测试是同时进行学习、测试设计和测试执行的一种测试方法；也就是说，测试没有事先通过确定的测试计划定义，而是动态地被设计、执行和修改”[9]。探索性测试（也称为探索式测试）最早于1983年提出，并在实践中发展 [10?11]。与传统脚本测试相比，探索性测试具有以下技术特点：
（1） 测试活动的同时性。鼓励在测试执行的过程中，同时进行对被测软件的学习和测试设计。
（2） 关注测试任务。更关注于被测软件本身和需要测试的问题。
（3） 测试中的演绎推理。通过前一个测试活动的结果来指导后期测试的开展。
（4） 利用人的优势。关注于人本身的优势，如判断、分析、应变和协作的能力。
作为一种敏捷软件测试方法，探索性测试弱化了对测试的预先设计和测试流程的严格要求，而强调测试的同时性以及人的经验和创造性，关注于发现软件缺陷，持续优化测试工作[12?13]。测试人员在测试?理解?再细化测试的迭代中，通过测试活动本身不断深入学习被测软件，从而能够缩减测试准备时间，发现更多缺陷，并使得软件测试可以在被测软件说明或文档不齐全的情况下开展[14]。
1.2 探索性软件测试的主要方法
探索性测试的概念提出后，经过工业界和学术界人士的工作，已初步形成包含经验运用、执行策略、管理模型的体系。
1.2.1 探索方法
探索性测试强调对测试人员的知识和经验的运用。这些经验和知识可分为领域知识、系统知识和一般的软件工程知识[15]。领域知识指领域规则、客户流程和操作场景等，包括用户使用和具体应用领域知识。系统知识是关于待测软件的特性和技术细节的具体知识，包括系统级的交互以及个体功能细节。一般的软件工程知识即不需要对被测软件系统和应用领域的具体知识。
丰富的知识和经验是对探索性测试人员的基本要求，以此为基础，探索性测试的发挥人的创造性，并由此增强了测试过程的适用性。从工程应用的实践中，已总结出了一些有用的启发式方法。运用这些策略和启发式方法，可以帮助软件测试人员在具备了基本的知识和经验的情况下，尽快熟悉被测系统，并在测试过程中充分运用经验和创造性。
在开展具体的测试活动时，测试人员则可以借助一些启发式方法在测试活动中“探索”被测软件。这些启发式的方法是测试中为了发现可能的缺陷，测试人员常用的一些技巧 [16]。这其中典型的有Hendrickson的检查单[17]以及Whittaker的漫游方法[3]。这些方法的共同特性是提醒测试人员：
（1） 应关注软件最主要的功能，并在测试的过程中对软件的行为进行联想、质疑并发散，充分利用逆向输入、边界情况、近似值、错误输入和特殊值（如0），通过软件行为的原因、表现等举一反三；
（2） 应刻意构造一些特殊的行为，如尝试遍历所有输出、尝试最长操作路径、尝试关注关键数据的演化、打散或集中事物、长时间运行软件等；
（3） 应构造测试检查软件主要功能往往不关注的情景，例如启动和退出、全选、空值、资源过量和紧张、取消操作、重复、同时运行等。
传统方法假设软件文档中说明了软件的各种预期行为，因而可以通过分析文档来提取测试预期（Test Oracles）。然而，在软件信息不完备的情况下，测试预期则无法提前预知。HICCUPPS的启发式方法，从历史（History）信息、顾客形象（Image）在软件中的恰当映射、类似软件的对照（Comparable Products）、与软件和商业声明（Claims）、用户预期（User’s Expectations）、同类产品本身（the Product itself）、明显的意图（Purpose）和法律规章（Statutes）等角度，帮助测试人员在判定测试是否通过[14]。
1.2.2 管理模型
良好的测试管理模型是保证测试质量、提高测试效率的必要保障。基于会话的测试管理（SBTM）是探索性测试领域中最常用的管理实践。SBTM将软件测试活动分解为若干会话（Session）[2]。会话特征如下：
会话围绕主旨（Charter）开展：即待测试的任务和目标；会话时间较短：时间长度在90 min左右；会话需要记录：借助会话记录单；每轮会话需要计划和总结：一轮会话执行通常是一天，其中包含若干个会话测试。
基于会话的测试过程如图1所示。当接到测试任务时，测试小组通过对测试任务进行分析讨论，确定各会话的主旨。会话主旨包含被测软件的主题、测试人员的角色、目的、条件、优先级、参考文档、数据、思路、预期等信息[18]。测试项目负责人分配各会话测试人员，随后开展首轮会话执行。一轮会话执行通常为一天。每轮会话执行结束后，需组织会话总结，主要借助以下维度进行：会话执行情况、笔记、缺陷、问题、数据、时间分解、人员安排等。通过总结确定下一轮会话、资源分配。下一轮会话执行按照相似的方式开展。在测试达到预期时间和充分度要求后，测试结束，并根据每轮会话报告单整理测试报告。
图1 基于会话的测试管理示意图
会话还可以根据需要进行扩展，例如可以包含对会话的风险评估和资源统计[4]，也可以将会话延伸为对特定问题的关注，形成测试的线索[19]。
1.3 探索性测试工具
探索性测试的有效开展同时依赖于工具的辅助。已有一些探索性测试的工具可供参考，例如Microsoft Test Manager（与Visual Studio组件），BBTestAssistant、TestExplorer，Session Tester，Rapid Reporter，Wink。这些工具通过基于录制回放、截屏和辅助文字信息的方式帮助测试人员记录探索性测试的执行过程，其中Session Tester、Rapid Reporter和Wink是免费的，Session Tester和Rapid Reporter则专门针对会话机制进行了设计和优化。
虽然这些基于录制回放原理的工具能够辅助测试人员整理测试报告，但是却缺少对测试人员运用其知识和经验的指导，对探索性测试的执行也缺少引导作用。目前没有专门的探索性测试流程管理工具，不能起到控制测试流程的作用。有必要针对具体应用研发相应的辅助工具。
2 探索性测试的应用及其效果
经过发展，探索性测试已在多个企业运用。人们对探索性测试方法的优缺点也有了更加明确的认识。
2.1 探索性测试在工业界的应用
微软是较早实践探索性测试方法的软件企业。微软在Windows 2000系统徽标认证、必应搜索引擎和地图、Visual Studio、Windows Media Player等系统、网络和桌面应用中广泛使用了探索性测试的技巧和方法，尤其是漫游探索法[3，7，20?21]。在其他公司，探索性测试也成功的运用于互联网应用行业以及信息系统的软件测试中。这些测试任务往往在软件文档不全、测试时间紧、企业对采用传统的脚本测试流程不满意的背景下开展，通过运用基于会话的方法，测试团队都能够高效的完成测试任务，甚至发现了采用传统方法在类似项目中遗漏的缺陷，在系统上线后也没有发生重大问题，软件项目组对测试团队的满意度有提升[22?24]。
虽然可能没有直接说明采用探索性测试，开源软件的测试往往具有探索性测试的特点。这些测试往往在没有详细的软件文档和测试用例设计的基础上，利用志愿测试人员的经验和兴趣开展 [25]。在敏捷软件研发团队中，探索性测试的方法也多有运用[26]。成功案例包括与XP和Scrum敏捷软件开发的结合[5，27]。
除了在工业界的运用，也有学者对敏捷软件测试的应用进行了系统的研究和讨论。Itkonen等人在芬兰多个软件公司中研究了测试人员对探索性测试的使用方法、效果和评价[28]，对探索性测试的优缺点、应用条件合场景以及推荐的方法进行了总结[29]；通过研究和实验，发现了探索性测试在缺陷检测能力上能达到甚至超过传统脚本测试的水平[6]。Naseer，史亮和高翔也总结了探索性软件测试在瑞典软件公司、国内的微软和淘宝等企业运用的经验，对探索性测试的活动进行了总结[8，10]。Bach等人还成立了公司专门从事测试方面的研究和推广。另外，也有一些研究将探索性测试思想与测试自动化方法结合[30]，或利用探索性测试的思想提高测试效率和质量的工作[5]。
从目前的应用情况来看，探索性测试技术多数是在桌面应用、B/S架构信息系统等领域的应用，在嵌入式系统软件测试中的应用较少。
2.2 探索性测试的优缺点
经过实践，总结上述对探索性测试的应用，能够发现，探索性测试尤其适用于要求在短时间内发现被测软件一些重要缺陷或事先没有能够进行详细测试设计的情况；但也具有测试过程不易控制、测试文档不全等问题。因此，在具体领域中运用探索性测试技术时，有必要根据领域特性，设计适合的测试流程，扬长避短。
一般认为探索性测试的主要优点和缺点如下：
优点：便于利用人员经验；适合于从用户角度的测试；适用于缺少软件文档、测试时间紧情况；灵活且适应性强；对测试人员和开发人员的反馈较快；能够为测试带来新内容，降低“杀虫剂”效应。
缺点：缺少足够的文档，不易度量覆盖率；测试统计数据不足，不利于决策；对测试人员经验要求较高；在测试人员经验不足、管理不严格的情况下，可能会影响测试质量；如缺少恰当工具，则不利于缺陷复现。
3 探索性测试在嵌入式系统中的应用
探索性测试技术却是能够应对嵌入式系统软件测试中软件需求变化快、测试周期短、软件文档不全等现实问题的可行方法之一。本文首先分析探索性测试在嵌入式软件测试中应用的需求和困难，然后探讨探索性测试技术与嵌入式系统软件测试体系的结合方法，对应用模型提出建议，并对应用中可能的问题和后续研究进行讨论和展望。
3.1 探索性测试一般性方法的适用性
随着IT技术的发展和各国在国防、智能电网、物联网、智能手机等行业投入的加大，嵌入式软件产品越来越多，测试任务越来越重，往往难以保证充裕的测试时间。软件需求和开发文档存在不准确、不完备的情况。而同时，嵌入式软件的测试具有较强的领域特性，领域内测试人员对被测系统的经验比较丰富。因此，需要也有条件在嵌入式系统软件中开展探索性测试，以降低对软件需求和设计规约的依赖、发挥探索性测试对软件变化的适应性和充分利用测试人员经验的优势。
然而，探索性测试技术在嵌入式领域中的应用却较少。探索性测试的通用方法没有直接用于嵌入式系统软件测试的原因主要是 [1，31?33]：
（1） 软件测试文档：探索性测试不鼓励测试花费精力在策划和准备上，而测试执行记录风格随意性较大，不利于形成统一、完备的测试文档；这与按照国标和军标中对完整的软件测试文档的要求冲突。
（2） 软件测试充分性度量：不易度量测试覆盖率，不易评价测试质量。
（3） 软件测试过程控制：缺少对配置和测试流程的系统性管理，可能造成测试过程失控。
3.2 探索性测试应用模型探讨
为了解决嵌入式系统测试中软件需求变化快、测试周期短、软件文档不完备等现实问题，有必借鉴探索性测试技术在信息系统、网络应用、操作系统等方面的成功经验，将其融入嵌入式系统软件测试体系中来[24，34]。为了与相应的软件测评体系和标准匹配，必须对探索性测试通用方法进行调整，设计探索性测试在嵌入式系统软件测试的应用模型。
一种可参考的“脚本会话模型”如图2所示，是以探索性测试一般性理论、探索性测试各特性在各型产品软件的适用性研究为基础，将探索性测试与传统脚本测试相结合的软件测试模型。为充分利用两者的优势，脚本会话模型的整体仍以传统脚本方法为基础，从而利用脚本测试管理中测试文档完备和过程管理控制完善等优点，而在测试执行过程中充分发挥探索性测试的灵活、高效优点，引入会话、漫游测试法等探索性测试等方法，同时借助嵌入式系统软件测试典型数据复用库来实现对测试人员经验的固化和复用。
图2 嵌入式系统软件脚本会话测试模型
如图3所示，脚本会话模型整体流程遵循经典的脚本测试流程，但发挥了探索性测试对经验的利用和灵活性的特点。
图3 脚本会话测试模型流程框架
包含以下步骤：
（1） 测试策划和设计阶段；借助领域软件测试典型数据复用库（测试人员经验的固化体现）形成测试项、构造测试用例，降低对软件需求和设计文档的依赖，初步完成测试需求的提取和测试用例的设计。
（2） 测试执行阶段：测试执行以基于会话的方式开展，并对一般会话进行扩展。根据测试设计和计划，确定每个会话的主旨、用例和测试方法。在每一次会话中，测试人员可以结对开展测试执行，根据预先指定的漫游策略和启发式方法，针对一个测试项进行探索，并补充测试用例。测试人员在会话结束后整理会话记录单。根据本轮会话执行情况，记录缺陷、改善测试设计，并准备下一轮会话。如此迭代直到测试结束条件满足，测试执行结束[35]。
（3） 测试总结阶段：借助测试执行中各个会话报告单，总结和报告缺陷。
3.3 讨论和展望
探索性测试在互联网和桌面应用已经成功实践[34]，而在嵌入式领域应用仍然较少。在嵌入式系统软件测试中运用诸如脚本会话模型的探索性测试技术时，应注意以下三点问题：
（1） 测试过程管理和文档。必须重视探索性测试的过程管理以保证测试过程受控。同时在适当的阶段应编写相应文档作为测试阶段性成果，并在测试执行完成后更新相应文档。
（2） 结合具体领域。具体领域的软件测试典型数据复用库可以看作是对该领域软件测试人员测试经验的固化，是软件测试团队的组织资产，有助于团队新成员快速熟悉被测系统，提高探索性测试的效率。
（3） 针对测试团队和项目制定具体策略。制定探索性测试中的典型方法的应用策略，并注意收集反馈，在实践中持续改进。
探索性测试作为一种在互联网、操作系统等领域成功运用多年的测试技术和理念，可以与其他软件测试技术结合，共同推进嵌入式软件测试质量的提升。可能的结合方向包括（但不限于）：
（1） 基于模型的测试和验证。借助软件模型可发现隐藏在软件界面和正常使用流程下的交互，其中可能隐藏了大量的缺陷；借助模型检验工具提供的反例[36]，测试人员还可以对软件进行更加深入的探索；
（2） 测试自动化。嵌入式系统软件需要处理传感器送来的大量数据，采用自动化方法能够有效减少测试人员的工作量；结合探索性测试的技术，也能够为测试用例约简和测试预期问题提供解决途径[34，37?39]；
基于剖面的测试：构造嵌入式系统的操作剖面和用户剖面，辅助测试人员能有选择性地对系统进行探索[40??41]。
4 结 语
探索性测试技术经过研究和发展，已形成了一套可行的体系。探索性测试在嵌入式系统软件测试中的应用还较少。经过对探索性测试体系的全面研究，能够更好的理解这种方法在嵌入式系统软件测试中的适用性，并为融合探索性测试与传统嵌入式软件测试方法，形成适用于嵌入式系统软件测试的探索性测试应用模型提供思路和方向。
参考文献
[1] 康一梅，张永革，李志军，等.嵌入式软件测试[M].北京：机械工业出版社，2008.
[2] BACH J. Session?based test management [J]. Software Testing and Quality Engineering， 2000， 2（6）： 1?4.
[3] WHITTAKER J A.探索式软件测试[M].北京：清华大学出版社，2010.
[4] LYNDSAY J， VAN EEDEN N. Adventures in session?based testing [EB/OL]. [2002?08?02]. http：///articl.
[5] TUOMIKOSKI J， TERVONEN I. Absorbing software testing into the scrum method [J]. Lecture Notes in Business Information Processing， 2009， 32： 199?215.
[6] ITKONEN J， MANTYLA M V， LASSENIUS C. Defect detection efficiency： Test case based vs. exploratory testing [C]// Proceedings of International Symposium on Empirical Software Engineering and Measurement （ESEM）. [S.l.]： [s.n.]， 2007： 61?70.
[7] BACH J. General functionality and stability test procedure for certified for Microsoft Windows logo [R/OL]. [1999?08?22]. http：///tools/procedure.pdf.
[8] NASEER A， ZULFIQAR M. Investigating exploratory testing in industrial practice [D]. Ronneby： Blekinge Institute of Technology， 2010.
[9] BOURQUE P， FAIRLEY R E. Guide to the software engineering body of knowledge， version 3.0 [R/OL]. [2013?03?13].. http：// /p?1714.
[10] KANER C， FALK J， NGUYEN H Q. Testing computer software， second edition [M]. New York： John Wiley & Sons， Inc.， 1999.
[11] KANER C， BACH J， PETTICHORD B. Lessons learned in software testing[M]. New York： John Wiley & Sons， Inc.， 2002.
[12] FOWLER M， HIGHSMITH J. The agile manifesto [J]. Software Development， 2001， 9（8）： 28?32.
[13] COCKBURN A. Agile software development [M]. [S.l.]： Addison?Wesley， 2002.
[14] BOLTON M. Testing without a map [J/OL]. [2011?07?18]. http：// /1137978.
[15] ITKONEN J， MANTYLA M V， LASSENIUS C. The role of the tester's knowledge in exploratory software testing [J]. IEEE Transactions on Software Engineering， 2013， 39（5）： 707?724.
[16] KANER C. A Tutorial in exploratory testing [R]. Chicago： QAI QUEST Conference， 2008.
[17] HENDRICKSON E. Explore It！： Reduce risk and increase confidence with exploratory testing [M]. [S.l.]： The Pragmatic Programmers， 2013.
[18] CLAESSON A. How to perform exploratory testing by using test charters [R]. Swedish： Swedish Association for Software Testing （SAST）， 2007.
[19] BACH J. Introducing thread?based test management [R/OL]. [2010?11?26]. http：///blog/archives/503.
[20] ROBINSON H. Explorer test automation [C]// Proceedings of the Conference for the Advancement of Science Teaching （CAST）. [S.l.]： [s.n.]， 2010： 11?21.
[21] ROBINSON H. Using simple automation to test complex software [C]// Proceedings of Annual Pacific NW Software Quality Conference. [S.l.]： PNSQC， 2010： 123?132.
[22] V?GA J， AMLAND S. Managing high?speed web testing [C]// Software Quality and Software Testing in Internet Times. [S.l.]： Springer?Verlag， 2002： 23?30.
[23] WOOD B， JAMES D. Applying session?based testing to medical software [J]. Medical Device & Diagnostic Industry， 2003， 25（5）： 90?96.
[24] 柳溪，马康，刘智.融合探索性与脚本方法的第三方软件测试模型及其应用[J].信息化研究，2013，39（6）：43?48.
[25] ABERDOUR M. Achieving quality in open source software [J]. IEEE Software， 2007， 24（1）： 58?64.
[26] KASURINEN J， TAIPALE O， SMOLANDER K. Test case selection and prioritization： risk?based or design?based？ [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： [s.n.]， 2010： 234?242.
[27] MARTIN D， ROOKSBY J， ROUNCEFIELD M， et al. Good' organisational reasons for 'bad' software testing： an ethnographic study of testing in a small software company [C]// Proceedings of International Conference on Software Engineering. [S.l.]： ICSE）， 2007： 602?611.
[28] ITKONEN J， RAUTIAINEN K. Exploratory testing： a multiple case study [C]// Proceedings of International Symposium on Empirical Software Engineering. [S.l.]： [s.n.]， 2005： 1?8.
[29] ITKONEN J， MANTYLA M V， LASSENIUS C. How do testers do it？ An exploratory study on manual testing practices [C]// Proceedings of the International Symposium on Empirical Software Engineering and Measurement. [S.l.]： ESEM， 2009： 494?497.
[30] HELLMANN T D， MAURER F. Rule?based exploratory testing of graphical user interfaces [C]// Proceedings of Agile Conference. [S.l.]： AGILE， 2011： 107?116.
[31] 中华人民共和国国家质量监督检验检疫总局.GB/T 25000.51?2010软件工程 软件产品质量要求与评价（SQuaRE）SQuaRE指南[S].北京：中国标准出版社，2010.
[32] 中华人民共和国国家质量监督检验检疫总局.GB/T 8567?2006计算机软件文档编制规范[S].北京：中国标准出版社， 2006.
[33] 中华人民共和国国家质量监督检验检疫总局.GB/T 9386?2008 计算机软件测试文档编制规范[S].北京：中国标准出版社，2006.
[34] 史亮，高翔.探索式测试实践之路[M].北京：电子工业出版社，2012.
[35] KANER C， BACH J. Exploratory testing in pairs [R/OL]. [2001?08?22]. http：///a/pairs.pdf.
[36] CLARKE E M， GRUMBERG O， PELED D A. Model checking [M]. [S.l.]： The MIT Press， 2000.
[37] DUSTIN E， RASHKA J， PAUL J. Automated software testing [M]. [S.l.]： Addison?Wesley Professional， 1999.
[38] FEWSTER M， GRAHAM D. Software test automation [M]. [S.l.]： Addison?Wesley Professional， 1999.
[39] KANER C. Architectures of test automation [R/OL]. [2000?09?28]. http：///pdfs/testarch.pdf.
[40] BUWALDA H. Soap opera testing [J/OL]. [2011?04?11]. http：///link？u...
购物车(0)