软件测试大全11篇

绪论：写作既是个人情感的抒发，也是对学术真理的探索，欢迎阅读由发表云整理的11篇软件测试范文，希望它们能为您的写作提供参考和启发。

篇（1）

1.组件测试

组件测试又称单元测试，其目的就是验证应用程序能够很好的工作，以及尽早的发现错误。所谓组件测试其实就是测试单个组件的过程，是一种细粒度的测试。组件测试其实就是一个缺陷测试的过程，基本上使用结构化测试即白盒测试来对组件进行测试。在软件中，组件算是最小的单元，因此，组件测试可以对多个组件来进行。

1.1组件测试的类型

在组件测试阶段，需要测试不同类型的组件（对象内的单个函数或方法、有多个属性和方法的对象类、有不同对象或是函数组成的复合组件）。组件测试的内容主要有模块接口、局部数据结构测试、路径测试、错误处理测试以及边界测试。从测试的类型可以看出，比较简单的就是对单个函数或方法的测试，但是当测试多个组件组成的复合组件时，测试组件间的接口是否能正确执行是首要关心的问题，而这个测试中的关键就是对组合组件的接口测试。

1.2接口测试

接口测试是组件测试中最常用的一种测试。测试符合组件间的接口就是接口测试。由于在符合组件之间存在很多交互行为，因此，在对复合组件中的单个组件进行访问时，是要通过接口来对它们进行调用。所以，接口测试就成为组件测试中的重点。

复杂系统中最常见的错误形式包括接口错误，接口错误主要指接口误用、计时错误、接口误解等等。一般情况在不寻常的条件下、交互双方都存在接口缺陷，而这是很难发现的，因此，接口测试是非常重要的。

组件的开发和测试都是交叉进行的，组件的设计者对组件是十分熟悉的，因此，由组件的设计者来进行组件测试是在合适不过了。

2.集成测试

所谓集成测试就是指测试时将组件集成为系统来进行。集成测试的目的就是检查在一起的组件是否工作，能否正确及时进行组件与组件间的交互。集成测试就是将与接口相关的错误找出，从而使得添加的功能模块确保没有传播不期望的副作用，并且使得由于新模块的添加引起的变更不引入需求外的行为或是增加额外的错误。集成测试过程如图1所示。

图1 集成测试过程

2.1集成系统的策略

集成顺序不同，集成测试也将不同，二者密切相关。集成系统的策略从理论上来讲，其可分为自上而下的集成和自底而上的集成。但是在实际中，大多数的集成策略都是混合型的。自上而下的集成就是指先把系统框架开发出来，然后再向其中添加组件。这种方法存在一个非常普遍的问题，即在测试下一层时，还要兼测上一层。自底而上的集成就是指集成和测试都是从组件开始。不管使用哪种策略，开发额外的代码是必须的，通过额外代码的开发来仿真其他组件，从而使得系统运行起来。

对错误的定位就是集成测试中存在的主要问题。由于组件之间有复杂的交互行为存在，因此，当发现一个错误时，很难将其出错的位置找到。

2.2集成测试的方法

集成测试通常采用增量法来进行测试，从而使得集成测试中的主要问题得以解决。使用增量法，从一个集成度最小的系统配置开始，然后测试这个系统，测试完成后，一个增量一个增量地往系统中增加组件，每次增加组件后再进行测试。这种方法其优点在于易于分离和纠正错误以及彻底测试接口。这种方法的缺点在于在测试过程中经常会出现重复测试。

2.3回归测试

回归测试就是指把测试过的再进行测试。回归测试虽然出现重复测试，但是其能够保证新增模块后不会给原系统组件间的行为产生不期望的变更。回归测试是保证软件的正确运行的必要条件，但是，对测试过的再进行重新测试明显会产生不必要的浪费。

要想在使用回归测试时减少系统资源的浪费，可以从以下几个方面进行：（1）引进自动化测试。这种方法的引入，使得测试自动地重复，从而回归测试对系统资源的浪费得以减少；（2）严格规定增加快增加顺序。先增加最常用的功能块，从而对最常用的组件进行多次测试，确保在各种情况下常用功能能够实现。

集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

3.性能测试

性能测试就是测试系统对在非正常条件下的运行情况。它的任务是验证软件的功能和性能及其他特性是否达到了需求规格书上的要求。一般情况下包括恢复测试、安全测试、压力测试、性能测试。恢复测试是通过各种方式强制地让系统发现故障并验证其能够重新恢复的一种系统测试。安全测试是验证在系统内的保护机制是否能够实际保护系统不受非法入侵。压力测试是以一种要求反常数量、频率或容量的方式执行系统的测试方法。

4.接收测试

接收测试是对将要分给客户的系统版本的测试过程。通常是一个黑盒测试过程，将软件与计算机的其他系统元素结合在一起，在实际运行环境下，由用户通过真实的数据测试对软件在内的计算机系统，以求能发现系统需求定义中的错误和遗漏。同时也期望能发现因系统的设施不能满足用户的需求或系统的性能无法接受的错误。

4.1接收测试的方法

接收测试的最好测试方法是基于脚本的测试，先设计出多个脚本然后再从脚本中开发错测试用例。

4.2接收测试的分类

接收测试根据用户的不同可以分为α测试和β测试。无论是α测试还是β测试都是在实际的使用环境下进行的。α测试是测试为特定的用户开发的系统，且由最终用户在开发者在场的情况下进行的，开发者在旁边记录用户所遇到的错误和使用问题，α测试要持续进行直到开发者和用户双方都对最后交付的系统满意。β测试的对象是一个将要在市场上销售的软件产品，β测试是所有愿意使用该软件的用户在使用该软件是所遇到的所有问题，然后在反馈给开发者，开发者再根据反馈回来的信息决定对软件做如何处理。通常情况下β测试能暴露开发者无法预见得错误。

随着软件应用越来越广，所要求的设计也越来越复杂，所需的开发周期越来越短，而质量要求越来越高，那么软件企业目前面临着巨大的挑战。由此，软件测试变得越来越重要，软件测试可以有效地提高软件质量。重视软件测试过程和技术是软件企业快速发展的有效途径。

篇（2）

居住地：上海

电　话：153********（手机）

E-mail：

最近工作 [ 1年7个月 ]

公　司：XX计算机软件有限公司

行　业：计算机服务(系统、数据服务、维修)

职　位：软件测试

最高学历

学　历：本科

专　业：软件测试

学　校：西北大学

自我评价

本人熟悉软件开发测试流程，丰富的自动化测试经验，善于学习。能在成功与失败中完善自己，活泼开朗，乐观向上，适应力强，勤奋好学，认真负责。待人诚恳，做事踏实细心，对工作有热情有责任心。

求职意向

到岗时间： 一周之内

工作性质： 全职

希望行业： 计算机软件

目标地点： 上海

期望月薪： 面议/月

目标职能： 软件测试

工作经验

2012 /12—至今：XX计算机软件有限公司[ 1年7个月]

所属行业：计算机服务(系统、数据服务、维修)

测试部 软件测试

1.负责需求分析，制定测试计划，编写测试计划和测试案例；

2.负责测试环境的搭建；

3.负责使用JIRA 缺陷管理系统, 管理跟踪BUG；

4.负责系统的功能测试，以及处理客户的回馈，重现问题；

5.负责熟练使用LINUX脚本语言，实现测试环境的自动安装和定时运行，并进行日志的查看及排错等；

6.负责根据用户需求，编写用户使用说明手册；

7.负责系统的安装及配置,负责客户版本升级。

2011 /1—2011 /12：XX软件科技有限公司[ 11个月]

所属行业：计算机软件

事业部 软件测试

1、负责根据软件开发年度进程表，与美国微软测试及开发团队沟通，确定各阶段测试目标；

2、负责在项目测试过程中，制定测试计划，参与测试用例的编写、修改和审核；

3、负责定期组织技术交流会议，以提高组员工作效率；

4、负责及时处理客户对软件提出的问题，执行测试定位问题,以帮助产品的修复。

2010 /7—2011 /1：XX网络游戏有限公司[ 6个月]

所属行业：娱乐/休闲/体育

技术部 软件测试

1、负责了解软件的测试流程，并制定测试流程；

2、负责编写测试用例，BUG提交给开发人员；

3、负责开发人员修复，进行回归测试；

4、负责根据需求写测试大纲、编写测试用例、测试报告。

教育经历

2006 /9--2010 /7 西北大学 软件测试 本科

证 书

2009 /6 大学英语六级

篇（3）

0 概述

（1）软件测试现状

随着软件的快速发展，软件产品质量面临着前所未有的挑战，提高测试的效率、降低测试的成本，对软件产品提高质量和应对日趋激烈的市场竞争有着重要意义，而软件质量的提升主要靠软件测试来实现。

统计表明，在典型的软件开发项目中，软件测试的工作量往往占到总工作量的40%以上，而在总成本中，测试成本要占30%～50%。尽管目前大部分公司已经非常重视软件测试，但软件质量提升的实际效果不尽人意，一部分原因是软件测试方面的投入不足，更大一部分原因是软件开发人员、甚至软件测试人员的测试意识不足，测试时间不足，导致无法展开快速、有效的软件测试。

（2）软件测试面临的问题

首先，国内软件相对起步较晚，现在在软件开发上投入了大量的人力物力，相对而言在软件测试方面]有引起足够的重视，更没有进行成熟的软件测试研究，软件测试环境等测试资源国内暂时没有形成完善的氛围。

其次，软件测试人员较少，难以投入足够的人力展开大规模的、规范的软件测试，甚至在大部分公司软件测试人员地位收入要低于软件研发人员，软件测试远远没有引起重视。

第三，软件时间紧凑，开发时间紧张，测试时间就会被大大缩短。测试的效果会大打折扣。

软件日益复杂，软件错误日益增多，软件测试手段不成熟，测试人员不足，测试时间紧张等种种原因导致目前国内测试水平较差，软件测试没有完全展开。针对现状思考，综合考虑测试时间和测试效果兼顾，制定程序静态扫描的单元测试与探索性测试的系统测试相结合，先进行程序静态扫描的单元测试，通过后再进行探索性测试的系统测试的快速测试策略。

1 快速软件测试策略

软件测试是为了更快、更早的将软件产品中存在的缺陷找出来，并敦促软件开发人员尽快解决软件缺陷，向客户提供高质量的产品。确定有效的软件测试策略可快速找出软件中的缺陷。

1.1 单元测试

单元测试是检查软件单元是否正确实现了详细设计中的各项功能、性能要求，发现软件单元内可能存在的各种缺陷。

1.1.1 测试策略

针对单元测试目的，结合实际开发现状，拟采用静态测试工具对源代码进行程序静态扫描。

程序静态分析是：在不运行代码的前提下，通过词法分析、语法分析、控制流等白盒测试技术对软件源代码进行扫描，验证源代码是否满足规范性、安全性的一种代码分析技术。

1.1.2 常用静态分析技术

1.1.3 程序静态扫描的优缺点

程序的静态分析与动态分析是相对应的两种代码分析技术，主要实现方式是通过对程序代码的自动扫描发现隐含的程序缺陷，主要具有以下两条优点：

a）不执行程序，对源程序不会产生任何破坏。程序静态扫描不运行源代码，只是通过静态扫描对源代码进行语法、结构等方面的分析；

b）执行速度快、效率高。成熟的程序静态分析工具每秒可完成上万行代码的扫描，具有执行速度快、效率高的特点。

程序静态扫描的缺点也比较明显：误报率比较高，目前国际最好的程序静态分析工具误报率在5-10%之间，还是比较高的一个状态。

在软件程序实现的过程中使用程序静态分析工具对程序进行扫描，有助于快速发现代码缺陷，提高代码的质量，是一种在节省人力物力的前提下快速的提升源代码质量的有效手段。

1.2 系统测试

系统测试的目的是：在真实或者仿真环境下检验软件程序是否满足“软件研制任务书”和“软件需求规格说明”规定的功能、性能等要求。

1.2.1测试策略

针对系统测试目的，结合人员紧张、开发时间短的实际开发现状，拟采用使用探索性测试的测试策略对软件程序进行功能、性能的合格性验证。

探索性测试首先假设软件存在某缺陷，然后对提出的假设进行逐步验证。在进行探索性测试的过程中，学习知识、测试设计和测试执行是在同一时间交叉进行的。探索性测试的核心是依据测试的实际情况，即时设计测试用例并在软件程序上进行验证，测试结束后将测试的结果整理形成“软件测试报告”。

1.2.2探索性测试常用方法

探索性测试是对传统测试技术的补充，它的关注点更多是有目的性地验证程序是否存在某个缺陷。所以，探索性测试适用于所有的系统测试，但作为一种新兴的软件测试理论，它有着自己独特的测试方法和管理方式。一般使用如下两种方法来进行测试：

（1）结对测试法

结对测试的一般测试形式是两名测试人员共同对一套软件程序或者一台机器展开测试。它要求必须有一名测试组长来负责统筹测试全程，进行合理的测试安排。测试组长制定合理的软件测试计划，依据计划，测试成员两两组队，分工合作。在测试过程中，两位测试人员各有分工，一位进行测试操作，另一位主要负责提出建议、记录测试发现的缺陷、提出测试过程中对程序的探索性问题等。

结对测试要求测试人员都能清晰地进行交流，因为当一名测试人员将自己的探索性想法与其他测试人员进行沟通时，极有可能会触发其他测试人员的灵感，这种发散性的交流方式会碰撞出更多的思维火花，设计出更加准确、完整、符合实际测试情况的的软件测试用例，这比传统测试中要求测试人员按照固定的测试计划进行软件测试更有效率。除了以上优点，结对测试还有以下优点：

a）轻松的测试环境：轻松的测试环境将避免测试过程中测试人员产生的的枯燥和无聊情绪，明显提高软件测试效率；

b）良好的连续性：结对测试中，两位测试人员分工明确，一名软件测试人员专注于执行测试，另一名软件测试人员负责记录及文档整理，分工明确将大大增加测试的连续性，使测试具有更好的可持续性；

c）降低外界干扰：两人组成一个小的团队，其他无关人士前来打扰测试的机会将会大大降低，排除外界干扰 ，提高工作效率；

d）清晰的报告测试结果：结对测试中一人专注负责记录和整理测试结果，这将使测试报告的数据清晰完整；

e）有利于培养新的测试人员：结对测试，两两结对，有经验的测试前辈趁此机会将探索性测试中规律性的经验传授给新的测试人员，新的测试人员一边学习一边实践，帮助新人快速成长，提升测试技能。

（2）会话测试法

探索性测试的创始人James Bach提出过另一种有效的测试方法：会话测试法。这种测试方法的优点是既不影响探索性测试灵活性和探索性的特点，又能避免探索性测试人员松散不服从统一管理。目前是探索性测试所有方法中比较公认的一个有效的测试方法。

会话测试法中的会话主要包括两部分：一部分是明确的测试主题，另一部分是可以被检查的测试过程。“测试主题”指的是测试中想要发现的软件缺陷或计划完成被测试的功能。“可以被检查”是指阶段性的软件测试报告，该软件测试报告来表征会话测试期间的工作成果。

持续时间1.5小时的会话测试为最优会话测试，但这不是绝对的时间限制，一般而言小于45分钟的会话测试称之为短会话测试，大于2个小时的会话测试称之为长会话。一般情况，每天可以使用会话测试法对软件程序进行三轮测试。

会话测试中没有固定的模式对测试步骤及测试用例进行规定和限制，依据测试人员和测试主题来进行灵活选择和执行，例如测试人员可能会从某项功能开展测试，也有可能从频繁出现的缺陷打开测试入口。

1.2.3 探索性测试的优缺点

探索性测试最大的特点是具有强大的缺陷发现能力，作为一种高效率的测试方法，主要具有以下优点：

a）测试方式灵活、富有创造性和主观能动性。它比传统的测试方法更加灵活，例如探索性测试对测试文档的要求没有传统测试那么严格，但是它能够发现正常测试用例执行以外的缺陷，更有效地发现隐性缺陷，发现很多正常途径无法发现的缺陷也能够激发测试人员的创造性和主观能动性。

b）测试时间短，执行效率高。测试学习、测试设计和测试执行交叉进行，只对测试缺陷进行详细的记录，会大大缩短测试时间，为项目的整体开发节省大量时间。据统计，有经验的测试人员在使用探索性测试方法进行测试时，执行测试的时间能占到测试总时间的80%，而测试设计只占总测试的20%。

探索性测试的缺点也是显而易见的：对软件测试工作没有一个整体的规划，不利于测试的规范化、标准化；重复性测试的几率比传统测试要大很多，很难确定哪些测试已经执行过。

在测试时间短、测试资源不充足的情况下，使用探索性的测试策略展开系统测试，可以有效快速地发现软件缺陷，提高软件质量。

2 结论

软件质量是软件的生命，由于软件缺陷而造成经济损失、导致严重后果的事例屡见不鲜，软件测试作为软件质量保证的重要手段一直都是软件工程研究和应用的热点。在有限的人力物力情况下，如何展开有效的软件测试，显著提升软件质量更是每个软件研发人员的关注重点。

程序静态扫描提升源代码质量、探索性测试保证软件功能的合格性，二者有效地结合，在极短的时间内，节省开发人员精力的前提下，可以有效地_到软件测试的目的，是一种有效的测试策略。

【参考文献】

[1]张晓明，黄琳译.软件测试的艺术，机械工业出版社.

[2]朱少民编.软件测试方法和技术，清华大学出版社，2005.

[3]汪颖译.人月神话，清华大学出版社.

篇（4）

0　引言

随着Intemet的普及和电子商务应用的深入。Web应用程序得到越来越广泛的应用，B／$架构也逐渐代替C／S架构成为主流的应用模式。与传统软件相比，Web应用程序具有分布式、并发、多用户异构等特点，这些特点对软件测试提出了新的要求。Web测试是保证Web应用程序质量的有效手段，目前在Web测试的方法和技术以及相关工具等方面的研究已进行了一些尝试。软件测试的自动化技术有助于开发出更高质量的产品，并且可以节省开发时间和开支。

1　Web软件体系结构

Web应用程序采用B／S结构，它是伴随着Intemet技术的不断进步，由C／S结构改进和发展起来的新型体系结构。B／S结构利用不断成熟和普及的浏览器技术实现原来需要复杂专用软件才能实现的强大功能。是一种全新的软件系统构造技术。这种结构已成为当今应用软件开发的首选体系结构。

Web系统的基本工作过程是：在客户端，用户通过浏览器向Web服务器中的控制模块和应用程序输入查询要求，Web服务器将用户的数据请求提交给数据库服务器中的数据库管理系统DBMS；在服务器端，数据库服务器将查询的结果返回给Web服务器，再以网页的形式发回给客户端。在此过程中，对数据库的访问要通过Web服务器来执行。Web系统的基本体系结构及工作过程如图1所示。

从上面的体系结构可以看出，Web测试应该分为三个层次，客户端测试、服务器端测试和数据库测试。客户端主要测试用户浏览器的基本功能和页面现实情况；服务器端主要测试用户请求响应情况；数据库端主要测试数据一致性和输出错误。

2　Web软件测试的主要特点与难点

Web软件由于其分布式应用、具有各种运行时行为、涉及多种标准协议，可能在硬件、软件、通信、对象管理等环节出现各种缺陷。其体系结构和应用的复杂性，以及技术和规范不断地发生变化，对测试提出了新的挑战。Web软件测试的特点与难点主要体现在以下几个方面：

(1)Web软件的开发环境与其应用环境有很大的不同，在之前，很难对其实际的运行场景进行预测，如用户类型、并发用户数量、Web服务调用的装载模式和访问方式等，这些差异和应用的不确定性都增加了Web服务测试的困难。

(2)Web软件测试主要基于软件接口进行设计和实现，因此必须采用自动化测试方法，与传统的需要大量人工干预的测试方法截然不同。

(3)Web软件由于其分布特征，会出现大量用户通过不同的环境访问同一个服务的情形，因此，性能和可扩展性是Web软件测试的重要方面。

(4)Web软件及软件集成的、发现和绑定都是动态完成的，其过程的不确定性和不可见性增加了测试难度。

(5)Web软件访问接口和访问方法后增加了Web软件的安全隐患，提高了被系统攻击的机会。此外，对于所调用的分散、异构的外部Web服务的安全性的管理也非常困难。如何提高Web软件的安全性也是测试者要考虑的重要问题。

(6)Web软件的应用通常涉及到软件提供者、者和使用者三种角色，都需要参与到测试的不同阶段，其分布式合作的特征使得测试的组织、缺陷管理、结果评估等活动都更加困难。

目前。针对Web软件的测试方法和技术的研究还处于初始阶段，代表性的研究主要有基于形式化方法对协议及规格说明的验证(如WSFL验证技术、SOAP验证)和Web服务的集成测试。

3　传统软件测试与Web软件测试

传统软件测试经常是静态、离线的测试，尽管这些传统的测试技术也可以应用到Web服务的测试当中，然而相当有意义的一部分Web软件测试都必须是动态的和在运行时间内的即时测试。Web软件这种动态和即时测试对传统的测试理论提出了新的挑战和要求。表1比较了传统软件和Web软件测试的差别。

4 Web软件测试的内容和方法

Web测试主要目标是确保提交高质量的Web软件。对于错综复杂的Web软件，从什么地方开始测试。哪些方面是测试的核心，有限的测试资源如何分配，这些都是Web软件测试需要重点考虑的问题。下面介绍Web软件测试的主要内容和方法。

4.1　功能测试

链接测试　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：①测试所有链接是否按指示的那样确实链接到了该链接的页面。②测试所链接的页面是否存在。③测试Web应用系统上有无孤立的页面。所谓孤立页面是指没有链接指向的页面，只有知道正确的URL地址才能访问。

表单测试　单元当用户给Web应用系统管理员提交信息时，就需要使用表单操作。例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。

Cookies潮试Cookies通常用来存储用户信息和用户在某应用系统的操作。当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登录等信息。如果Web应用系统使用了Cookies。就必须检查Cookies是否能正常工作而且对存储的信息已经加密。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

设计语言测试　Web设计语言版本的差异，例如使用不同版本的HTML等，可以引起客户端或服务器端严重的问题。在分布式开发环境中，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaSeript、ActiveX、VBScript或Perl等也要进行验证。

数据库测试　数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的。针对这两种情况，可分别进行测试。

4.2　性能测试

网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做得不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立一整套网站的性能测试方案将是至关重要的。

连接速度测试　用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。连接速度太慢。还可能引起数据丢失，使用户得不到真实的页面。

负载测试　负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线；如果超过了这个数量，会出现什么现象。

压力测试　压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

4.3接口测试

服务器接口　第一个需要测试的接口是浏览器与服务器的接口。测试方式一般是，测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

外部接口有些Web系统有外部接口，例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生，测试的时候，要使用Web接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。

错误处理　最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。为此，可以尝试在处理过程中中断事务，看看会发生什么情况，订单是否完成，尝试中断用户到服务器的网络连接，系统能否正确处理这些错误。

4.4　兼容性测试

平台测试市场上有很多不同类型的操作系统，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下运行可能会失败。因此，在Web系统之前，需要在各种操作系统下对其进行兼容性测试。

浏览器测试　浏览器是Web客户端最核心的构件。来自不同厂商的浏览器对JavadavaScript、ActiveX或不同的HTlML规格有不同的支持，例如，ActiveX是Microsoft的产品，是为Intemet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。测试浏览器兼容性的一个方法是创建一个兼容性矩阵，在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

4.5　安全测试

景登　现在的Web应用系统基本采用先注册，后登录的方式，因此，必须测试有效和无效的用户名和密码。要注意到系统是否对大小写敏感，可以试行登录多少次，是否可以不登录而直接浏览某个页面等。

日志文件为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

篇（5）

正确性测试又称功能测试，它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素，所以其测试也最重要。

基本的方法是构造一些合理输入，检查是否得到期望的输出。这是一种枚举方法。倘若枚举空间是无限的，那可惨了，还不如回家种土豆有盼头。测试人员一定要设法减少枚举的次数，否则没好日子过。关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。等价区间的概念可表述如下：

记（A,B）是命题f(x)的一个等价区间，在（A,B）中任意取x1进行测试。

如果f(x1)错误，那么f(x)在整个（A,B）区间都将出错。

如果f(x1)正确，那么f(x)在整个（A,B）区间都将正确。

上述测试方法称为等价测试，来源于人们的直觉与经验，可令测试事半功倍。

还有一种有效的测试方法是边界值测试。即采用定义域或者等价区间的边界值进行测试。因为程序员容易疏忽边界情况，程序也“喜欢”在边界值处出错。

例如测试的一段程序。凭直觉等价区间应是（0,1）和（1,+∞）。可取x=0.5以及x=2.0进行等价测试。再取x=0以及x=1进行边界值测试。

有一些复杂的程序，我们难以凭直觉与经验找到等价区间和边界值，这时枚举测试就相当有难度。

在用“白盒测试”方式进行正确性测试时，有个额外的好处：如果测试发现了错误，测试者（开发人员）马上就能修改错误。越早改正错误，付出的代价就越低。所以大多数软件公司要求程序员在写完程序时，马上执行基于单步跟踪的“白盒测试”。

2容错性测试

容错性测试是检查软件在异常条件下的行为。容错性好的软件能确保系统不发生无法意料的事故。

比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错，例如：

（1）输入错误的数据类型，如“猴”年“马”月。

（2）输入定义域之外的数值，上海人常说的“十三点”也算一种。

粗暴一些的容错性测试俗称“大猩猩”测试，除了不能拳打脚踢嘴咬，什么招术都可以使出来。这里我举不出例子，因为我没有对程序粗暴过，并且这辈子也不打算学会粗暴。

3性能与效率测试

性能与效率测试主要是测试软件的运行速度和对资源的利用率。有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。

在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如计算机主频，总线结构和外部设备都可能影响软件的运行速度；若与多个计算机共享资源，软件运行可能慢得像蜗牛爬行。

在获取测试的“相对值”时，我们要确保被测试的几个软件运行于完全一致的环境中。硬件环境的一致性比较容易做到（用同一台计算机即可）。但软件环境的因素较多，除了操作系统，程序设计语言和编译系统对软件的性能也会产生较大的影响。如果是比较几个算法的性能，就要求编程语言和编译器也完全一致。

性能与效率测试中很重要的一项是极限测试，因为很多软件系统会在极限测试中崩溃。例如，连续不停地向服务器发请求，测试服务器是否会陷入死锁状态不能自拔；给程序输入特别大的数据，看看它是否吃得消。

4易用性测试

易用性测试没有一个量化的指标，主观性较强。调查表明，当用户不理解软件中的某个特性时，大多数人首先会向同事、朋友请教。要是再不起作用，就向产品支持部门打电话。只有30%的用户会查阅用户手册。[Cusumano1995]

一般认为，如果用户不翻阅手册就能使用软件，那么表明这个软件具有较好的易用性。

5文档测试

文档测试主要检查文档的正确性、完备性和可理解性。好多人甚至不知道文档是软件的一个组成部分。

正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。

篇（6）

头信息包括：测试软件名称、版本号、缺陷或错误类型、可重复性、测试平台、平台语言、缺陷或错误范围。要求填写完整、准确。

简述是对缺陷或错误特征的简单描述，可以使用短语或短句，要求简练、准确。

操作步骤是描述该缺陷或错误出现的操作顺序，要求完整、简洁、准确。对命令、系统变量、选项要用大写字母，对控件名称等加双引号。

注释一般是对缺陷或错误的附加描述，一般包括缺陷或错误现象的图像，包括其他建议或注释文字。

书写专业软件问题报告的技巧

书写软件问题报告的目的是为了正确地重复缺陷或错误，从而在后续工作中可以准确验证并加以处理。因此，基本要求是准确、简洁、完整、规范。为了正确书写专业的软件问题报告，应该注意以下要点：

每个软件问题报告只书写一个缺陷或错误

这样可以每次只处理一个确定的错误，定位明确，提高效率，也便于修复错误后方便的进行验证。

对错误的描述要做到简洁、准确、完整，揭示错误实质

描述要准确反映缺陷或错误的本质内容，简短明了。为了便于在答数据库中寻找，包含错误发生时的用户界面是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

明确指明错误类型和严重程度

根据错误的现象，总结判断错误的类型和严重程度，例如，是功能错误？还是界面布局错误？该错误是属于特别严重的错误还是一般错误？是否影响软件的后续开发和？

每一个步骤尽量只记录一个操作

简洁、条理井然，容易重复操作步骤，以便确认、修复、验证该错误.

复现的操作步骤要完整，准确，简短

保证快速准确的重复错误，完整即没有缺漏，准确即步骤正确，简短即没有多余的步骤。

附加必要的错误特征图像

为了直观的观察缺陷或错误现象，通常需要附加错误出现的界面，作为附件附着在记录的附件部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。

附加必要的测试用例

篇（7）

抛开具体的软件工程的具体模型，一般的产品周期流程可以如下划分

篇（8）

3、第2阶段：功能测试；工作方向：功能/手工测试；市场价值：薪资可达到7000元/月以上

篇（9）

一般地，项目启动过程组包括两个过程:即制定项目章程和制定项目初步范围说明书;而项目规划过程组则会综合项目的成本、范围、时间、质量、风险、人力、沟通、采购等因素制定项目计划，该项目计划将用于指导项目的实际执行。

对任一项目而言，有三个文件是非常重要的。即:项目章程、项目范围说明书，项目管理计划。这三个文件均产生于项目启动阶段和项目规划阶段。其中项目章程被认为是三大文件之首（项目章程、项目范围说明书，项目管理计划）。一个项目，不论大小，都应该有项目章程。

项目章程由项目发起人(Sponsor)签发，自签发之日起，项目经理即获得法定权力。

项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。为了制定这份文档，他/她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。

项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。这个阶段将会涉及项目管理方方面面的规划、计划。有经验的项目经理在此过程中总是会认真听取和吸收团队骨干成员和同行们的经验意见，从而形成广为认可和接受的规划、计划。

经过权衡和必要的调整，这些文档最终将被集成到一个完整的项目管理计划中。项目管理计划经由项目发起人、高级管理层审批以后，即可生效。

此后，项目经理将召开项目开工会议，宣布项目正式开始进入执行阶段。

项目启动阶段的项目章程和项目初步范围说明书，也可以体现在分包或采购合同中。这在软件外包服务型企业中最为常见。

通常，伴随合同到达项目经理手中的还有项目建议书，项目建议书由项目发起人制定，内容和项目章程中有关产品、可交付成果的描述大致类似，此外，还应包括对项目经理成功完成此项目的一些指导性建议。项目经理进行综合考虑，与相关干系人磋商，在项目团队相关专家的帮助下，制定出合适的项目管理计划。

上面讨论的是一般项目启动过程组与规划过程组。具体到测试项目的启动与规划，工作内容也是类似的。读者朋友请根据所在测试项目的特点做适当调整。需要交待清楚的是测试项目启动与规划过程组有可能与其他六个过程组（测试需求分析、测试设计、测试执行、测试项目收尾、测试交付、测试项目监控与调整）在项目实施过程中有频繁的迭代关系（参见图1）。

比如，规划过程组有可能在整个项目生命期内都有更新和完善。

对于整周期软件开发项目的测试而言，上述过程组的内容会有较大的差异。

比如:项目章程将重点关注开发，而不会过多讨论测试相关的工作。对于这一类型的软件测试，笔者建议在任命开发项目经理的同时，由项目经理[适用于项目型或强矩阵组织]或高层经理[适用于弱矩阵或职能型组织]指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计，并和项目经理沟通、协调，以将一些重要的信息及时反映给项目经理，从而使项目计划能较好地支持测试工作的开展。

软件测试需求分析

理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。

在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求。由于后者涉及需求工程的专门知识，本文略过不做细述;这里重点讨论前者。在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求（体现在项目章程、SOW、项目建议书等文档中）细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。在UML表示方法中，用户需求通常通过Use Case来进行刻画。

接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。

理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。（注意:为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。）

然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。

软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试（这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求和设计的确认），测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求（由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求）。

又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。

再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。

最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。

读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢？是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。测试需求的开发总是有赖于相应层次的软件规格说明书

只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明->概要设计规格说明->软件需求规格说明->用户需求规格说明->项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。

篇（10）

软件测评是保证软件质量的重要步骤，它在软件运行之前对软件进行分析、预测、试用等一系列的方法，找到软件存在的问题和缺陷，以免为以后造成不必要的麻烦和损失。这样可以使软件稳定、正常地运行，提高其可靠性。软件可靠性评估是对软件正确评估的重要手段。软件的可靠性主要是指软件在一定的时间和条件下达到预期的目的的能力。软件的可靠性是软件的固有特性，它表明的是软件用户对软件的满意度，可靠的软件是完整的、能够满足用户需求、正确的。它的要素主要有：一定的时间限制、特定的环境、特定的功能。

1 软件测试与可靠性评估的现状

就目前来看，软件测试并没有受到人们的充分重视，还存在着许多的误区，这样不利于软件质量和性能的提高。首先，人们普遍认为软件测试实在软件开发后进行的，其实并不是这样，软件测试是贯穿整个软件项目中的，在的每一个软件活动中都要进行不同的测试，用以保证每个阶段的正确性，从而来保证软件的质量。其次，在软件发现问题之后，往往将责任归咎于软件测试人员，这是不正确的。软件出现错误应该要从多方面考虑，要查清楚原因再做定夺，否则会挫败软件测试人员的工作积极性。然后就是，对软件测试的要求过低，工作人员的职业素质比较低下。绝大多数人认为软件测试是一项简单的工作，任何人都有能力胜任，其实不然，软件测试工作需要具备专业技能的人才，掌握了相关的知识，具有很强的责任心。此外，大部分人认为软件测评只与测试人员有关。实际上，软件测试还与程序员有关。因为软件测试需要各个工作人员保持密切的联系。最后，软件测评往往会在时间比较紧时做少量的测试，而有充足的时间会做比较多大测试。

我国在软件可靠性评估这一块发展得比较晚，还存在着许多的不足。首先对软件评估没有一个完整规范的管理系统，在软件项目工作安排上缺乏科学有效性，导致各种评估误差，影响软件的进一步发展，影响到软件占据市场的份额。此外，目前我国的软件可靠性评估一般将重点放在软件的研制阶段，对软件的评估程度不到位，导致软件项目后期出现一定的误差。而且我国关于软件评估的可靠性没有相对其他国家严谨规范的标准，对软件的评估存在着许多的问题，再加上软件评估人员的职业素质有限，对其认识具有不一致性，导致无法有实际意义、正确、有效地进行评估，相关的部门得不到有用的信息，从而误导软件公司做出错误的决策，不利于企业的竞争与发展。

2 软件测试与可靠性评估的意义

软件测评与可靠性评估能够发现软件存在的错误与缺陷，促进软件的完善与改进，让其更好地为软件用户服务，满足软件用户的需求。然后，能够有效定义软件成分有低层到高层的组装过程，便于日后软件的维护与修改。此外，能够有效验证软件那是否符合原有和相关规定要求，迫使企业软件从开发到软件投放市场，都有利于是软件正规化，符合相关规章制度，避免一些非法操作的软件投入市场，损害某些个人以及集体的利益。

3 使得软件测试与可靠性评估有效的措施

软件的测试与可靠性评估的方法是极为重要的，如何让其高效、正确的为软件服务，是软件研发、研究组织应该为之努力的目标。其一，要科学的管理系统，对软件人员进行很好的管理，让其充分发挥优势，使整个系统有组织、有次序的运行，既能节约资源，又能提高工作效率。其二，软件人员要充分认识到软件测试与可靠性评估的重要性，在工作当中认真负责，不能因为个人原因而影响了整个软件开发运行的进度和质量。其三，要注意对软件测试与评估的宣传，让其他人认识到这不仅仅只是软件检测员与软件评估员的事情，要求大家团结合作，避免某一环节出现错误。其四，要培养出一批具备专业水平的软件测试与评估人才，充分发挥其作用。所以组织要对其进行定期的培训，并要保证培训的质量，不能仅仅将其当成一种形式与任务，要将培训工作落到实处，真正提高工作人员的职业技能，要对培训过程中不认真的人进行一定程度的惩罚，每次培训完后要进行考核，检测培训质量，并为下一次的培训提供经验。这样就能够在很大程度上提高培训的效果，不至于培训无效，浪费人力、物力、财力。

4 软件测试与软件可靠性评估的原则

首先，软件测试与评估应该要及时，并且要增加测试、评估的力度，尽可能地多进行测试，进行评估。此外，要注意软件开发过程的整体性，保证软件测试贯穿于整个软件设计当中，与其他步骤结合起来，及时发现错误的早期阶段，降低组织软件的成本，测试时要将相关的数据结合起来，比如说：测试的输入数据与其对应的输出数据。要防止软件工作人员检测自己所设计的程序。要按计划、全面地实施软件测试。软件评估要保证客观、科学，不能以主观心态来评判，要有科学依据。采纳一些比较科学的方法来进行评估。要遵循谨慎原则，不能过于随意，要加强重视，以防止评估出现误差，造成不必要的损失。

5 小结

软件测试与可靠性评估对于软件的进步发展有着重大的意义，相关的部门、组织要高度引起重视，客观、正确、科学地看待软件测试与评估，针对自己关于软件测试与评估所出现的问题采取相关的措施，从而促进软件自身的完善与发展，提高软件的市场竞争力。由于本人的学识有限，如果本文存在着任何的缺点和不足，请大家谅解。

参考文献

[1]科教导刊编辑部；软件测试外包一站式人才培养模式的探索与实践[J]；科教导刊；2013年第33期

[2]易敏捷；基于多平台的计算机软件测试方法分析[J]；科技传播；2013年第20期

[3]王文斌、刘方舟、刘雪；基于云计算平台的软件测试策略[J]；计算机光盘软件与应用；2013年第17期

作者简介

篇（11）

1.课程的定位与教学设计

1.1 课程定位

《软件测试》课程作为软件专业二年级下学期的专业课，它的前导课程是《数据库设计》、《数据结构》、《软件工程实施》，后续课程是课程实训及毕业实习。通过本课程的学习，使学生加深对软件测试基本理论和基本方法的理解与应用，能熟练使用常用软件测试工具，并能运用软件测试工具完成应用软件的测试工作，提高学生对软件的测试与维护能力，并进一步培养学生的的团队协作能力。

1.2 课程设计思路

软件测试是高职计算机软件专业学生在以后的工作岗位上要用到的核心技能。因此，本课程应该作为专业必修课程和核心课程，重点培养学生在以后的工作岗位上所需的职业能力：白盒测试、黑盒测试、自动化功能测试与性能测试。

《软件测试》课程的总体设计思路是，转变传统的学科课程模式，不再以知识传授为主，构建以工作任务为中心的企业培训体系，引入企业项目，让学生在真实的企业项目中完成相应的工作任务，从而储备相关的专业知识，发展职业能力。授课内容重点突出对学生职业能力的培养。课堂上不再单纯地只讲授理论知识，而是围绕实际工作任务的需要来选取，这充分考虑了高职学生动手能力强，理论知识薄弱的特点。

2.教学设计

2.1 教学情境设计

本课程小组通过学院专业指导委员会、重庆亚德科技、重庆大佳、重庆港澳大家等软件公司的企业技术人员进行实际调查，制定了适合高职学生的软件测试课程体系与职业能力，确定了软件测试课程典型的教学情景与子情景，在教学情景中给出具体的工作任务、工作方法以及要求学生掌握的知识与技能等，在教学中贯彻理论实践一体化的教学模式，做到教、学、做三结合，充分体现工学结合的优势，培养学生的职业素质。本课程的5个工作过程及11个典型工作任务如表1所示。

2.2 教材设计

（1）教材应充分考虑软件测试的实践特性，以工作任务为导向，引入必须的软件测试理论知识，让学生在实际测试的过程中，循序渐进地掌握必要的理论知识。

（2）编写的内容要以项目驱动为原则，以企业的实际案例、场景模拟、工作过程录像为载体，增强课后的能力拓展，并根据高职学生的职业能力所需知识的深度和广度来编写，并在具体的工作任务中使学生逐渐形成团队协作意识。

（3）教材应突出软件测试技术的实用性、前瞻性和开放性，不能只是简单地介绍一些技术上的操作，而忽略了软件学生所需的职业能力，在教材中应融入软件测试技术中所用到的新规范、新技术、新标准、新工具、新知识，让学生能系统地掌握软件测试的前沿知识。

（4）教材应充分引领学生主动、积极地去学习，因此，文字表述要简明扼要，内容展现应图文并茂，内容应详略得到。

2.3 教学方法设计

由于本课程的主要教学内容涉及白盒测试、黑盒测试、自动化功能测试与性能测试等操作性很强的教学环节，必须通过课程实训才能达到对项目作规范需求分析的培养目标。具体教学方法设计如下：

（1）全班学生分为N个项目小组，3人一小组，1人任组长，组长要求协调沟通能力比较强。

（2）在教学过程中应加强学生对软件总体的测试能力，采用任务驱动教学，注重以任务引领，提高学生学习兴趣；

（3）组建软件外包中心，引进企业项目，让学生真实地体验在软件公司的测试流程。外包中心作为理论实践一体化教室，达到理论和实际不脱节。

（4）教学过程中可参考软件测试评师考试中规定的知识要求和技能等级职业标准。

（5）教师模拟企业的项目经理，必须具有开拓精神，带领团队完成工作任务，并在完成工作任务的过程中，探索基于工作过程的职业教育新模式，培养学生的软件测试能力，构建软件测试知识体系。

2.4 教学评价设计

（1）突出过程评价，结合课堂提问、实作测试、课后拓展、任务考核等手段，加强实训教学环节的考核，并注重平时考核。

（2）强调目标评价和理论与实践一体化评价，注重引导学生进行学习方式的改变。

（3）每个项目小组在完成课程后，要将所学的内容做ppt，汇报本小组项目完成的情况以及体会。

（4）实行学习过程的过程化考核。平时作业、期中与期末考试均采用上机实训的方式考核，对于不合格者，在团队的协作帮助下持续练习，直至过关。这样可以督促学生不断地练习，真正提高动手能力。

（5）课程的学期成绩=平时作业（10%）+上课考勤（10%）+小组项目测试情况（30%）+小组ppt总结情况（10%）+期末成绩（40%）

3.课程资源的开发与利用

（1）围绕软件测试课程，收集教师和学生必备的软件测试工具，制作适宜教学的多媒体教学课件。

（2）组建软件外包中心，搭建实训工作平台，为学生实训提供真实的工作环境，从而提高其职业素养。

（3）要充分开发网络课程，让学生在课余时间可以自主学习，弥补学生课本知识的不足。

（4）充分利用和开放实训中心，将教学与实训合一，将理论与实践合一，满足学生综合能力培养的要求。

（5）积极利用电子书籍、电子期刊、数字图书馆、校园网、各大网站等网络资源，使教学内容从单一化向多元化转变，通过企业技术人员的指导，课程教师的辅导，使学生知识和能力的拓展成为可能。

4.课程的实施效果

（1）基于项目化的授课内容

建立软件外包中心，引入企业项目内容，软件测试的授课内容紧紧围绕企业项目的典型工作任务开展，学生的能力与素质参照软件测试工程师的岗位要求，让学生真实感受企业环境，就业零距离上岗。

（2）基于过程化的授课方式

老师授课不再单纯地讲解理论，完全按照企业的软件测试流程开展，制定规范的软件测试计划、编写测试用例、利用测试工具测试、编制测试报告，有利于学生养成职业化的学习习惯与工作习惯。

（3）基于理论实践一体化的教学设备

学生在软件外包中心上课以及实验，真正实现了“做中学，学中做”的企业工作环境。

（4）基于能力化的学习评价

学生的评价不再单纯地以理论考试为依据，而是从学生的软件测试专业能力、利用软件测试工具的能力、团队沟通协调能力进行综合地评价。

参考文献

[1]郑泳.基于工作过程系统化的高职《软件测试》课程设计[J].漯河职业技术学院学院，2010（9）.

[2]程茂，温静，吴玉洁.《软件测试》课程的教学研究[J].河北师范大学学报，2010（4）.