软件开发测试（精选12篇）
软件开发测试 篇1
软件测试是控制软件质量的重要手段。来自智联招聘、南方人才网、中华英才网等相关网站的信息显示,2007年前后国内软件测试人才缺口极为严重,目前软件测试人才就业前景仍然向好[1]。高校要培养合格的、适应市场需求的软件测试人才,需要学生对软件测试有系统的认识,理解软件测试的真正意义,还要有尽可能多的实践经验[2]。这样的需求决定了《软件测试技术》课程的讲授应包括理论讲解和测试实践两部分,理论讲授过程中需要学生用尽可能短的时间掌握软件测试的基本概念、测试过程、测试方法和测试原则,能够读懂相关技术资料,拿到一个软件项目知道该从哪里入手。
查阅软件测试资料时我们会看到许多软件测试门类:白盒测试、黑盒测试、单元测试、集成测试、静态测试、动态测试、回归测试、自动化测试、性能测试、压力测试、α测试、β测试……总结起来有三、四十个,这些测试类别常常搞得学生晕头转向,能让他们在短期内记住并理解其含义已经很困难了,对软件测试的认识更是雾里看花。其实这些词汇是从不同角度对软件测试的划分,如果能够汇总这些测试种类,引领学生从不同的角度对软件测试进行分析,会使学生更好地认识软件测试。正如通过横看、侧看、远看、近看、里看、外看、俯看、仰看……终归会识得庐山的真面目。
1对软件测试的全面总结与分类
关于软件测试分类,有的书上说“软件测试分为白盒测试和黑盒测试”,有的则说“软件测试分为单元测试、集成测试,系统测试、验收测试”,其实每种说法都只关注了软件测试的一个方面。结合前人的总结和当前软件测试的发展,本文从六个角度对软件测试进行了类别划分,具体内容如图1所示。
软件测试不仅仅是在软件开发完成后测试一通儿就可以的,软件测试通常会经历单元测试、集成测试、确认测试、系统测试和验收测试几个阶段(根据具体软件的不同特性有些阶段可能会被合并);如果从测试过程中是否分析被测程序的结构,软件测试可以分为白盒测试和黑盒测试;如果从测试过程中是否需要执行被测程序,可将软件测试划分为静态测试和动态测试;如果根据测试关注点和测试目标不同,可将软件测试划分为功能测试、性能测试、压力测试、安全性测试、可用性测试等;如果从测试过程中是否使用自动化测试工具,软件测试又可划分为手工测试和自动化测试;从测试组织角度软件测试可以划分为开发商测试、用户测试和第三方测试。若以此为主线分别对软件测试进行更详细的介绍,对软件测试的认识也就清晰了。
2课堂组织
有了上面对软件测试的全面总结,还要考虑如何将这个庞大的“关系网”传授给学生,如果直接把这张图展现给学生并从上到下依次讲解,很容易让学生感觉很枯燥,因此要考虑针对不同内容采取不同方式进行知识传授,使他们在愉快、轻松的心境中全身心地投入到学习过程中,全面认识软件测试。
2.1知识的回顾与引申
学习软件测试课程的同学基本上都学习过软件工程的基础知识,所以在讨论按测试阶段划分软件测试的时候,先引领学生回顾软件工程的瀑布模型,结合瀑布模型告诉他们软件测试工作不仅仅局限在“测试阶段”去做,告诉他们在软件开发过程中单元测试、集成测试、系统测试等都做什么,何时做;告诉他们测试的准备工作早在系统分析阶段可能就已经开始了———这样学生知道了软件测试与软件开发的关系,同时也懂得了软件测试按阶段的划分。
2.2利用有趣的实例帮助分析
G.J.MYERS对软件测试的定义“软件测试就是为了发现错误而执行程序的过程”在很长一段时间里被软件测试业所认可并经常被引用,然而随着软件测试的发展,软件测试过程不光通过“执行程序”来实现。比如校园网上有包含很多判断、循环句式的“幽默”程序用于判断“女孩是否该嫁给某个男生”,这样的程序他们一看便懂,带领学生分析这样的程序使他们认识到分析程序代码也是测试的一种方式,继而引入“白盒测试”、“静态测试”的概念。
2.3用类比法加深学生对问题的理解
关于对软件测试不同角度的分类,问学生“如果对在座同学分分类可以分成几类?”,他们有的会想到两类,有的会想到四类———因为按性别划分、按行政班级划分、按所在省份划分结果都不一样,对任何事物进行分类首先要考虑分类的角度,因此把软件测试分成那么多类也就不难理解了。
2.4设置疑问引发学生思考
经过学生认真思考过的问题他们往往都会记得很清楚。讲解手工测试和自动化测试时给学生设计题目:“自动化测试是相对于手工测试而言的,它的好处有哪些?”,“自动化测试会不会取代手工测试?”,“自动化测试有什么不足之处?”,经过学生的思考和回答,再对问题进行总结,学生对自动化测试就有了一定的理论基础,再通过后面具体自动化测试工具的使用,对自动化测试的认识就全面而深刻了。
2.5变换教学媒体
在课堂教学中,单一的教学媒体容易引起学生疲劳和注意力分散,教学效果也会受到影响。因此在通过PPT演示稿讲解课程的同时,可以就一个知识点在黑板上扩展来分析,或者结合视频、编译环境中的代码等来讲解。比如在学生回答软件工程的各个阶段时,在黑板上写出学生的答案,也可以让他们思考更改,再在其中插入软件测试的内容,富于变换。
2.6紧密结合软件测试的发展
随着软件业的日益壮大和逐步走向成熟,软件测试也在不断发展。如从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门,测试工作从简单测试演变为包括制定测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试;测试方式则由单纯手工测试发展为兼有手工测试和自动化测试;第三方专业测试公司的出现等。在分析软件测试分类的过程中适时插入这些内容,使学生了解软件测试的发展。
3课程总结与补充
通过不同方式将不同角度下的软件测试分类介绍给学生后,展现出上面的图片,以提升学生的总体认识。面对图1对问题进行总结,同时补充一些知识点,如冒烟测试、回归测试是怎么回事,白盒测试与静态测试有何异同,哪些测试阶段可以合并,单元测试与静态测试、单元测试与白盒测试是否有必然的联系等等。
对于在后面课程中有详细介绍的内容,如白盒测试、黑盒测试、自动化测试等,只需讲清概念,方法、原理、原则等姑且略过,而对于静态测试等其他概念则要讲清概念、特性及测试要点。
在学生充分理解图1的同时要求他们能够画出这张图,这样前言中所提到的那些测试种类在学生的眼中不再是杂乱无章的了,它们都有各自的含义,它们都有合适的位置,它们之间存在着某种确定的联系。这样,学生对软件测试就清晰了。
4结束语
知道软件测试共有多少类不是目的,通过分析从不同角度对软件测试的划分可以更清晰地理解软件测试,更好地掌握软件测试的相关术语。实践证明,经过对软件测试分类的全面总结,以图1所展示的内容为主线,可以更好地向学生传授软件测试的基础理论,使他们更好、更快地理解软件测试。
参考文献
[1]IT行业软件测试人才就业前景仍然良好[EB/OL].南方人才网,http://www.nfrencai.com/html/200892395010.html,2008.9.
[2]软件测试就业前景跳出“专业框架”[EB/OL].北大青鸟,http://www.nj-test.com/post/5486.htm,2009.4.
[3]贺平.软件测试教程[M].电子工业出版社,2007.6.
[4]赵斌.软件测试技术经典教程[J].科学出版社,2008.4.
[5]Andreas Spilner,等.Software Testing Foundations[M].人民邮电出版社,2008.4.
软件开发测试 篇2
基本信息
求职意向
软件测试工程师 工作经历
2016-12至2017-04
中软国际
软件测试工程师 工作内容：
1、负责项目组测试执行、基础数据的处理、story澄清签收、测试工作经验总结等工作
2、负责项目现网问题的提单、维护跟踪及问题单的回归测试和漏测问题的根因分析 2015-10至2016-11
四川观想科技有限公司
软件测试工程师 工作内容：
1、负责网格化服务管理信息系统PC用户界面(B/S结构)中组织管理、事件处理、人口信息等模块的用例编写、执行
2、负责网格化服务管理信息系统社区E通APP信号人口信息、任务清单模块的测试 2012-07至2015-09 工作内容：
1、对xxxxxx系统、大调解信息平台、维稳信息工作平台、计生通等信息化办公软件进行维护并对软件使用过程中出现的问题作好记录和上报
2、对基层社区进行相关软件使用的培训和技术支持
3、进行基层社会管理管理信息进行采集录入及数据的分析、文件的编写归档 个人技能
熟练掌握软件测试理论、方法、能独立负责测试项目工作，熟悉白盒和黑盒测试技术；
能熟练使用软件测试工具；
熟悉关系型数据库oracle的增删查改； 熟悉Linux操作系统的基本操作命令； 了解Java/C等程序语言; 熟悉计算机网络的基础知识； 项目经验 1）
项目简介： 测试环境： 测试工具： 工作内容： 项目心得：
1、需求评审是测试的基础，评审需求的过程不仅可以让测试人员快速的熟悉项目，还可以为用例编写做好准备
2、用例编写对需求的覆盖关系到测试执行的有效性，提高需求分析能力，可以更快速全面的编写测试用例
3、自由测试可以弥补用例测试的不足，因为编写测试用例总会存在一定的思维死角
4、系统测试中被测软件关联性高的功能模块可以放在一块测，这样可以调高工作效率和测试执行的有效性
2）田园美电商系统
项目简介：田园美电商系统是B2C独立网店系统，是一个适合广大农户快速构建个性化网上商店的系统，系统主要用于中小个体农户农副产品（如葡萄、枇杷、桂圆、柚子、土鸡、黑山羊等）的推广销售，系统是基于PHP语言和MySql数据库构架开发的跨平台开源程序。
测试环境：window server2003，mysql，PHP，Apache 测试工具：SVN，QC
工作内容：主要完成田园美电商系统的测试推广及平台搭建
1、完成电商系统SRS评审，协助搭建SVN和QC测试工具
2、协助编制测试计划和测试方案
3、负责地交易查询/密码找回/积分管理/后台添加会员/会员等级管理模块的用例编写及测试执行，采用的分析方法有：流程分析法、等价类、边界值、正交表及判定表，设计用例95条，发现缺陷8条
4、撰写提交缺陷报告及系统测试报告 项目心得：
1、需求评审是测试的基础，评审需求的过程不仅可以让测试人员快速的熟悉项目，还可以为用例编写做好准备
2、用例编写对需求的覆盖关系到测试执行的有效性，提高需求分析能力，可以更快速全面的编写测试用例
3、自由测试可以弥补用例测试的不足，因为编写测试用例总会存在一定的思维死角
4、系统测试中被测软件关联性高的功能模块可以放在一块测，这样可以调高工作效率和测试执行的有效性
2）网格化服务管理信息系统
项目简介：网格化服务管理信息系统是一个基于基层社会网格化服务管理的信息采集、统计分析及考核的管理工具，该工具使用B/S结构，编程语言为PHP,数据库采用Mysql,支持Windows XP、Windows 7等操作系统，可以提供用户对实际工作中的基层社会治理信息进行有效管理,并且提供统计及绩效考核功能
测试环境：XAMPP（集成PHP解析器、apache、Mysql数据库）、Windows XP、Windows 7等系统、IE11浏览器
工作内容：
1、完成网格化服务管理信息系统SRS评审
2、负责软件的测试要点的分析和测试用例的编写
3、安装XAMPP及四川省网格化服务管理信息系统，4、、负责网格化服务管理信息系统PC端组织管理、人口信息、数件处理模块的测试用例编写执行测试用例，编写提交缺陷报告及项目总结
5、负责四川省网格化服务管理信息系统社区E通APP信号人口信息、任务清单等模块的测试用例编写、执行、缺陷报告和回归测试
项目心得：
1、规范的测试流程可以有效的保证测试效率，也可以让我们的工作有条不紊的进行（QC项目管理工具及SVN配置管理工具的使用）
2、站在用户角度对系统进行测试，可以提高软件缺陷的有效性，并让测试人员体会到用户体验的重要性（社区E通APP测试）
3、测试环境的搭建搭不好，测试执行将无法进行（社区E通APP测试）教育经历
2008-09至2012-06 西南石油大学
电子信息工程专业
自我评价
有较强的环境适应能力，迅速找准定位，快速进入工作状态 有较强的团队协调能力，服从部门安排，友善处理同事关系
系统软件测试中的测试需求分析 篇3
关键词：系统软件测试；测试；需求；分析
中图分类号：TP311
1 什么是测试需求
简单来说，测试需求就是确定在项目中需要测试什么。测试需求描述测试的目标，特别是描述了产品的质量需求，测试需求分析目的是帮助定义测试对象和测试范围，发现软件需求中不完善和不明确的地方并加以完善以节省测试时间的投入，便于软件需求基线化和跟踪业务需求的变更。
一条有用的测试需求是唯一的、精确的、有边界的、可测试的。例如：软件产品可能有这样一个测试需求“系统主要事务的响应时间能满足系统要求”。这就是一个不符合要求的测试需求，怎样的指标是“满足”？系统的要求又是什么都不清晰，测试就无法开展。
一个完整清晰的可测试的软件测试需求是这样的：在1G内存和1.73兆主频的计算机上在25个并发用户执行插入、更新和删除操作时端到端的响应时间在3秒时间内。符合标准的测试需求是存在一个明确的可预知的结果，可以通过某种方法对这个结果进行判断和验证
测试需求应覆盖已经定义的业务流程，功能及非功能方面的需求。
2 为什么要做测试需求分析
测试需求是测试计划的基础与依据，我们在测试活动中，首先需要明确测试需求（What），才能决定怎么测（How），测试时间（When），需要多少人（Who），测试的环境是什么（Where）。是衡量测试覆盖率的重要指标。
确立测试需求是为了保证测试质量与进度，测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。在软件工程项目中，存在一些普遍的现象例如：需求阶段的问题，到测试的最后阶段才被发现；开发、测试、市场等不同角色的人员对软件功能细节存在理解歧义。确立测试需求可以避免这些问题的产生。
3 什么时候开始做测试需求分析
软件生存期的各个阶段都可能产生错误。而软件需求分析、设计和实现阶段是软件的主要错误来源。因此一旦软件需求确定后，即可开始进行测试需求分析。
4 如何做测试需求分析
做测试需求分析有两个关键词，一个是“测试需求”，一个是“分析”，下面我从以下几个步骤来说明如何做测试需求的分析。
4.1 对软件需求说明书进行需求验证
一个良好的软件需求应当具有一下特点：（1）清晰性；（2）组织和完整性；（3）一致性；（4）可修改性；（5）可跟踪性；（6）可检验性；（7）接口：界面、接口的说明；（7）质量、性能属性；（8）可靠性；（9）软硬件；（10）特殊问题。
4.2 搜集和提取测试需求（包括隐性的需求）
测试需求并不等同于软件需求，它是从测试的角度出发并根据软件需求整理出一个测试列表，作为该软件的主要测试内容。提取测试需求要以软件需求说明书及规格说明书为依据，以业务功能为中心，深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。隐形需求包括：用户隐式的需求如业务规则；行业规范；编写人员的技术能力所限等。提取方法可通过列表的方式对软件开发需求进行梳理，先提取出所有的需求点。这些需求点可能存在重复和冗余，再根据项目的功能模块进行组织归类，删除重复的需求、细化测试粒度太大的需求、合并相关联的需求，最后根据业务规则及相关文档等，对测试需求进行检查和完善。测试需求主要通过以下途径来收集：（1）与待测软件相关的各种文档资料。如软件需求规格、Usecase、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。（2）与客户或系统分析员的沟通。（3）业务背景资料。如待测软件业务领域的行业标准及知识等。（4）正式与非正式的培训。（5）其他途径。
4.3 根据测试阶段和重点，整理测试需求
测试处于不同的阶段，测试的重点也是不同的，例如集成测试阶段主要是检验程序单元或部件的接口关系；系统测试阶段，重点是为了验证和确认系统是否达到了其原始目标，通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。因此确立测试阶段和重点，才能在测试需求分析时，做到方向正确、目标明确。除了需要确保要求实现的功能正确，还要考虑软件的特性。银行/财务软件更强调数据的精确性，网站强调服务器所能承受的压力，ERP强调业务流程，驱动程序强调软硬件的兼容性。在做测试分析时需要根据软件的特性来选取测试类型，并将其列入测试需求当中。关注测试的焦点。测试的焦点是指根据所测的功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流、模块化、数据、输入域等。系统功能测试需求分类：（1）业务功能测试需求；（2）可靠性测试需求；（3）安全性测试需求；（4）易用性测试需求；（5）可移植性测试需求；（6）可维护性测试需求。
5 测试需求评审
测试需求的评审是质量保证的必须步骤，通过评审可保证测试需求获得相关干系人的认可，做到有据可依。测试需求评审的内容包括完整性审查和准确性审查。完整性审查是检查测试需求是否覆盖了所有的软件需求、以及软件需求的各项特征，关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束、行业标准等。同时还要关注系统隐含的用户需求。准确性审查是检查测试需求是否清晰、没有歧义、描述准确，是否能获得评审各发的一致理解，在测试需求之间以及与开发需求没有矛盾和冲突，每一项测试需求都可以作为设计测试用例的依据。
测试需求评审的形式没有固定的要求，有条件可以采用正式的小组会议形式进行评审，在评审之前确定好参会人员的各个角色和相关的责任，确保评审之前参会人员已经拿到了评审材料并有了足够的了解，评审结束时以签名及会议纪要的方式把评审结果通知相关单位及人员。此方式的优点是有计划有组织地进行，评审更加有效和权威，缺点是需要协调相关人员时间及会议场地等，在很多实际项目中有较大难度。测试需求评审还可以采取非正式的走查和轮查形式，将需要评审的内容发给相关人员，收集他们的意见，并把统一意见修改确立后的测试需求再发给相关评审人员进行确认。这种方式的优点是方便有效，缺点是少了多方人员的讨论和沟通。对于大型的重要项目，可能还会采取正式审查方式进行评审，包含了制定评审计划、组织会议、会后跟踪分析审查结果等。参与测试需求评审的人员至少要包含：项目经理、开发负责人、测试负责人、系统分析人员、相关开发和测试人员。测试需求评审通过以后，才可以跟进测试需求来制定测试计划及编写测试用例。
6 测试需求维护
在实际的软件工程中，软件需求的变更是很常见的，甚至频繁变更软件需求。如果一直使用初始的测试需求来指导我们的测试工作，必然造成测试的结果存在错误和差异。因此必须及时维护测试需求，适应实际工作的需要。在需求变化频繁的情况下，作为测试人员，最重要的就是要搞清楚以下几点：（1）哪些需求发生了变化；（2）这些需求变化后，对测试工作会产生哪些影响。包括会不会影响测试用例，如果影响，会对哪些用例产生影响。当发生较大改动时，还要明确是不是影响到了测试需求？（3）明确这些变化，会对自己的工作进度产生多大的影响。（4）对于必须更改的测试需求变化，要及时更新测试方案和用例。
软件测试需求分析是做好软件测试工作的重要条件，好的需求分析可以为后面的工作指引方向，带来便利。
浅谈软件测试和嵌入式软件测试 篇4
软件测试是指通过执行程序去找出软件错误的过程，是为评价一个程序或系统展开的各种活动，测试是度量软件质量的一个过程。软件测试是保证软件质量，提高软件可靠性的关键。无论是从软件开发方法学还是软件测试自身的效益看，软件测试在今后较长时间内仍将是保证软件质量的重要手段。
1 软件测试
1.1 软件测试的实质与意义
软件测试的实质就是找软件漏洞，即找Bug，这是一个非常重要的工作，因为任何一个产品开发出来以后。都会存在许多大大小小的Bug，轻则影响用户的正常使用，重则导致系统崩溃。软件测试是为了发现错误而执行程序的过程，测试是为了证明程序有错，而不是证明程序无错误。一个好的测试用例是在于它能发现至今未发现的错误，一个成功的测试是发现了至今未发现的错误的测试。
软件测试的重要意义已是无容质疑的。软件测试能够发现软件中存在的错误和缺陷，验证软件的功能和性能是否满足用户的需求。但是，软件评审和测试都不能证明软件的正确性，不能确认软件中已经不存在错误和缺陷，除非被测软件的输入空间是有限的和其他特殊情形。从工程的角度看，软件形式化方法对工程应用尚不成熟，除对少数软件外，离实际应用还较远。在复杂软件需求未能得到完全形式化表述之前，用形式化方法证明复杂软件的完全正确性是不现实的。
1.2 软件测试的分类与过程
软件测试不等于程序测试，它贯串于软件定义和开发的整个期间，因此，需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计说明、详细设计说明、以及源代码都是软件测试的对象。按照不同的划分方法，软件测试有不同的分类，如按测试用例设计方法可分为白盒测试和黑盒测试，按测试策略和过程可分为单元测试、集成测试、确认测试和系统测试。
软件测试过程主要分为四个测试步骤：单元测试、集成测试、系统测试和验收测试。为了在每个测试步骤中设计合适的测试例，尽可能多地找出系统中的错误，需要运用适当的测试方法。软件测试方法主要分为自盒测试和黑盒测试例如在单元测试和集成测试中，主要运行白盒测试，而在系统测试和验收测试中，大部分运行黑盒测试设计测试用例。
1.3 软件测试的原则
软件测试应该遵守其基本原则。首先应尽早和不断地进行软件测试，实践证明单元测试能够尽早发现问题，减少后期测试的错误量。其次，应当避免由程序员检查自己的程序，这里指的是后期系统测试阶段，并不包括单元测试;第三，应充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中已发现的错误数目或检锗率成正比。应该对错误群集的程序段进行重点测试;最后，应严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输人和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则以及回归测试的规定等等以及评价标准。此外，要妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
2 嵌入式软件系统测试
2.1 嵌入式系统与软件的概念
嵌入式系统是指以嵌入式应用为目的的计算机系统。起源于20世纪60年代，从最初的国防系统，逐渐进入工业控制系统。随着数字化时代的到来，大量系统架构复杂、功能日益强大的嵌入式系统正不断进入市场，应用也日趋复杂，这对嵌入式软件的开发技术和测试技术提出了更高的要求。嵌入式系统的复杂性和集成度越来越高，其中的软件部分也开始在整个嵌入式系统中占有越来越多的比例，并经常实现硬件的功能。
嵌入式软件是最难测试的一种软件，在嵌入式软件的测试过程中使用有效的测试方法、策略和工具，可以使系统开发的效率最大化，避免目标系统的瓶颈，确保嵌入式软件的质量确保嵌入式软件的质量。
2.2 嵌入式软件系统测试的特点
嵌入式软件系统测试具有以下特点：1)测试软件功能依赖不需编码的硬件功能，快速定位软硬件错误困难;2)性能测试，确定性能瓶颈困难;3)强壮性测试、可知性测试很难编码实现;4)基于消息系统测试的复杂性，包括线程、任务、子系统之间的交互，并发、容错和对时间的要求;5)交叉测试平台的测试用例、测试结果上载困难;6)实施测试自动化技术困难。大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40%以上，在极端情况，测试那种关系人的生命安全的重要行业中的嵌入式软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。
2.3 嵌入式软件的测试方法
一般来说，软件测试有两种基本的方式，即白盒测试方法与黑盒测试方法，嵌入式软件测试也不例外。
白盒测试或基本代码的测试检查程序的内部设计。根据源代码的组织结构查找软件缺陷，一股要求测试人员对软件的结构和作用有详细的了解，白盒测试与代码覆盖率密切相关，可以在白盒测试的同时计算出测试的代码的覆盖率，保证测试的充分性。把100%的代码都测试到几乎是不可能的，所以要选择最重要的代码进行白盒测试。由于严格的安全性和可靠性的要求，嵌入式软件测试同非嵌入式软件测试相比，通常要求有更高的代码覆盖率。对于嵌入式软件，白盒测试一般不必在目标硬件上进行，更为实际的方式是在开发环境中通过硬件仿真进行，所以选取的测试工具应该支持在宿主环境中的测试。
黑盒测试在某些情况下也称为功能测试。这类测试方法根据软件的用途和外部特征查找软件缺陷，不需要了解程序的内部结构。黑盒测试最大的优势在于不依赖代码，而是从实际使用的角度进行测试，通过黑盒测试可以发现白盒测试发现不了的问题。因为黑盒测试与需求紧密相关，需求规格说明的质量会直接影响测试的结果，黑盒测试只能限制在需求的范围内进行。在进行嵌入式软件黑盒测试时，要把系统的预期用途作为重要依据，根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。为了保证正确地测试，还须要检验软硬件之间的接口。嵌入式软件黑盒测试的一个重要方面是极限测试。在使用环境中，通常要求嵌入式软件的失效过程要平稳，所以，黑盒测试不仪要检查软件工作过程，也要检查软件换效过程。
2.4 两种重要的嵌入式软件测试工具
用于辅助嵌入式软件测试的工具很多，下面对两类比较常见但十分有用的有关嵌入式软件的测试工具加以介绍和分析。
2.4.1 内存分析工具
在嵌入式系统中，内存约束通常是有限的。内存分析工具用来处理在动态内存分配中存在的缺陷。当动态内存被错误地分配后，通常难以再现，可能导致的失效难以追踪，使用内存分析工具可以避免这类缺陷进入功能测试阶段。目前有两类内存分析工具———软件和硬件的。基于软件的内存分析工具可能会对代码的性能造成很大影响，从而严重影响实时操作;基于硬件的内存分析工具价格昂贵，而且只能在工具所限定的运行环境中使用。
2.4.2 性能分析工具
在嵌入式系统中，程序的性能通常是非常重要的。经常会有这样的要求，在特定时间内处理一个中断，或生成具有特定定时要求的一帧。开发人面临的问题是决定应该对哪一部分代码进行优化来改进性能，常常会花大量的时间去优化那些对性能没有任何影响的代码。性能分析工具会提供有关的数据，说明执行时间是如何消耗的，是什么时候消耗的，以及每个例程所用的时间。根据这些数据，确定哪些例程消耗部分执行时间，从而可以决定如何优化软件，获得更好的时间性能。对于大多数应用来说，大部分执行时间用在相对少量的代码上，费时的代码估计占所有软件总量的5%-20%。性能分析工具不仅能指出哪些例程花费时间，而且与调试工具联合使用可以引导开发人员查看需要优化的特定函数，性能分析工具还可以引导开发人员发现在系统调用中存在的错误以及程序结构上的缺陷。
3 总结
软件测试能够发现软件中存在的错误和缺陷,验证软件的功能和性能是否满足用户的需求,是软件产品开发中不可分割的一部分。嵌入式系统在人类生活中发挥着重要的作用,包括飞行控制器这样的控制系统,以及洗衣机这样的家用电器。嵌入式系统中软件的比重越来越大,也越来越复杂,保证嵌入式软件的可靠性正面临严峻的挑战随着计算机技术的发展,嵌入式软件测试面临着一些特殊的问题。虽然日前已经有一些针对嵌入式软件的测试和调试工具,但是在有些方面仍存在不足,包括许多任务操作系统的并发、非侵入式的测试和凋试、嵌入式系统的软件抽象等。对于嵌入式软件测试技术的研究人选测试工具有待开发,仍须要做很多进一步的工作。
参考文献
[1]红峰.软件测试风险的分析与对策[J].中国金融电脑,2009(2):129-130.
[2]钱超.软件性能测试的流程探析[J].中国金融电脑,2009(2):80-82.
[3]张军峰.如何使软件测试更有效[J].电脑知识与技术,2005(6):79.
[4]刘斌,高小鹏,陆民燕,等.嵌入式软件可靠性仿真测试系统研究[J].北京航空航天大学学报,2004(4):122-125.
[5]康一梅.嵌入式软件设计[M].北京:机械工业出版社,2007:230-236.
[6]郭春柱.嵌入式系统设计师案例导学[M].西安:西安电子科技大学出版社,2007:129-134.
[7]许育诚.软件测试与质量管理[M].北京:电子工业出版社,2004:28-30.
[8]麦格雷戈.面向对象的软件测试[M].北京:机械工业出版社,2002:120-123.
软件测试面试笔试测试题 篇5
一.简答题 (每道题10)
1. 测试的目标?
是为了尽可能多的发现程序中的缺陷
2. 测试的步骤?
单元测试(模块测试)、集成测试、系统测试、调试、系统的转换与交付使用
3. 您认为做好测试用例设计工作的关键是什么?
1)白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
2)黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口，不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
4.您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的.应用。
1)等价类划分
2)边界值分析法
3)错误推测法
4)因果图方法
5.测试人员的职业素质要求是什么?
1)责任感
2)沟通能力
3)独立的判断和自学习能力
4)耐心、自我督促
5)团队精神
二.选择题(单选题)(每道题5分)
1.软件验收测试的合格通过准则是：
A. 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求，
B. 所有测试项没有残余一级、二级和三级错误。
C. 立项审批表、需求分析文档、设计文档和编码实现一致。
D. 验收测试工件齐全。
答：B
2.软件测试计划评审会需要哪些人员参加?()
A.项目经理
B.SQA 负责人
C.配置负责人
D.测试组
答：A
软件开发测试 篇6
关键词：软件测试；软件质量保证；教学改革；软件测评师；实验教学
中图分类号：G642.0 文献标志码：A 文章编号：1674-9324（2014）51-0094-02
一、引言
随着我国软件产业迅速发展，企业面临着开发高质量软件系统的巨大压力，软件测试、软件质量保证受到越来越多的重视。软件企业对承担软件测试、质量保证工作的软件测试人才需要剧增，软件测试工程师的职业价值、发展前景得到前所未有的提升。为此，国内高校开设了软件测试相关课程。但是，由于其重理论、轻实践的教学模式使得培养出的学生软件测试实战能力差，导致大量毕业生应聘软件测试相关职位时受到冷遇。
为培养创新能力强、适应社会经济发展需要的软件测试人才，《软件测试与质量保证》实验教学亟需改变传统的教学理念，改进教学方法，更新教学内容。笔者结合自身教学科研和工程实践经验，分别从改革思路、实验教学内容设计等方面，论述常熟理工学院《软件测试与质量保证》实验教学改革的措施和体会。
二、实验教学面临诸多挑战
笔者调研国内高校软件测试课程的建设情况，发现普遍存在重理论、轻实践的教学倾向，实验教学环节存在诸多问题：
1.企业对软件测试工程师的能力要求是综合性的，要求软件测试人员具有软件项目经验，具备软件测试、软件质量保证知识，能够独立开展软件测试工作。但是，国内高校教学计划制定时片面强调软件测试的作用，对软件测试与软件质量保证之间的天然联系缺乏理解，对软件质量保证相关实验的重视程度，课时安排存在严重不足。
2.目前，《软件测试与质量保证》实验教材选择面临无书可选的尴尬局面。课程实验设计只能全凭任课教师把握，使得实验教学过程中存在较多风险。
3.国内高校在实验设计方面，多以基础性实验为主。这种单一的实验设计方式，难以适应软件测试工程实践能力培养的需要。
三、实验教学改革措施
在应用技术大学建设驱动下，以中小企业对软件测试人才的需求和软件测试工程师认证大纲为导向，我们整合已有的校企合作课程资源，按照Daniel Galan软件质量保证框架组织实验教学内容，采用项目驱动的案例教学法开展实验教学，让学生在实验实践中加深对软件测试与质量保证专业知识的理解，培养学生软件测试实践能力。
（一）教学改革基本思路
软件企业对软件测试人才的需求是软件测试课程改革的源动力和驱动力，软件测试相关的从业资格认证是学生入职的敲门砖。为此，在应用技术大学建设背景下，我们以切合中小企业对软件测试人才的需求为导向，结合全国计算机等级考试软件测试工程师认证、全国计算机技术与软件专业技术资格考试软件评测师认证的考试大纲要求，选择朱少民老师编写的《全程软件测试》[1]和NIIT培训教程《Software Testing and Quality Assurance：Student Guide》[2]作为课程教材，按照Daniel Galin软件质量保证框架组织教学内容。Daniel Galin软件质量保证框架[3]指出软件质量保证是建立企业软件质量文化所需的一些列活动的集合，认为软件测试是一种典型的软件质量保证措施，软件测试的目的是为了发现潜在的软件缺陷，软件测试工作贯穿软件项目的始终。按照Daniel Galin软件质量保证框架组织课程内容有助于保持软件测试与软件质量保证之间的内在联系，符合软件企业软件测试与质量保证的最新经验。
（二）实验设计
如何在有限的实验课时内，最大限度地加深学生对软件测试、软件质量保证的理解，增强其软件测试实践能力，是实验教学的主要任务。我们设计了导入性实验、基础性实验、创新项目实践三种类型的课程实验。导入性实验要求学生应用已修课程（包括程序设计、数据库设计、软件工程等）知识进行软件调试，在软件调试过程中理解软件调试与软件测试、软件质量保证之间的关系，实现到本课程学习的过渡；基础性实验目的在于强化课程基础理论、原理的理解，让学生在实验中理解所学知识，掌握软件测试工具的使用；创新项目实践以课程实训项目为载体，为学生运行所学知识解决软件测试实践过程中涌现的各类问题，锻炼学生的动手实践能力、自主学习能力，从而提高学生的工程实践素养。
1.导入性实验。软件测试的目的是发现软件系统中潜在缺陷，而缺陷的解决则通过软件调试手段实现。为此，设计导入性实验“软件调试”。本次实验以员工工资核算软件Employee作为实验对象，要求学生发现Employee中人为注入的软件缺陷，然后应用Java调试器的断点调试功能，结合回归测试手段修订所发现的缺陷。
通过导入性实验，学生体验了改正软件缺陷的艰辛，在教师引导下思考如何发现软件缺陷、如何提高软件质量。教师适时点拨学生，指出发现软件缺陷是软件测试工程师的职责，软件测试工程师需运行软件测试方法、技术和工具才能发现潜在的软件缺陷。教师进一步启发学生：提高软件质量需要开展包括软件测试在内的各项软件质量保证工作。
2.基础性实验。基础性实验旨在加深学生对课程基本概念、原理的理解，让学生在动手实践中加深对基础概念、原理的理解。课程安排8次基础性实验，实验2、3、4和5属于软件质量保证实验，6、7、8和9是软件测试实验。
（1）实验2：软件度量实践。实验2关注软件度量问题，介绍软件规模、项目工作量和软件成本之间的关系，要求学生掌握软件规模估算、工作量估算和成本估算的方法和过程。通过本次实验，学生可以应用USC CoCoMo II进行软件成本估算。（2）实验3：基于Microsoft Project的软件项目管理。软件项目计划及进度管理，是软件质量保证中重要的管理部件，也是开展软件测试活动的前提。实验3要求学生使用Microsoft Project建立软件项目计划、运用跟踪甘特图追踪项目进度，等等。（3）实验4：版本控制软件CVSNT。CVSNT是当前最流行的版本控制系统，是中小企业进行版本控制的利器。实验4讲解CVSNT的安装和使用，要求学生掌握CVSNT的操作技巧。（4）实验5：BugFree软件缺陷管理。软件缺陷管理贯穿软件测试项目的始终，记录软件缺陷从发现、修复直至关闭软件缺陷的全过程。实验5介绍开源缺陷管理软件BugFree的软件缺陷管理思想，要求学生掌握BugFree安装与配置、软件缺陷管理等技能。（5）实验6：软件静态测试。软件静态测试是软件测试技术中发现软件缺陷效率最高的技术。我们安排“软件静态测试”专题讲座，讲解软件制品阅读、静态分析的技巧，还介绍如何运用CheckStyle、FindBugs等静态测试工具分析程序源代码、目标程序中潜在缺陷。本次实验有学生利用课后时间，自主实践。（6）实验7：JUnit单元测试。实验7介绍单元测试工具JUnit的使用，要求理解JUnit单元测试框架，掌握单元测试脚本的编写技巧。本次实验还推荐学有余力的学生自学JMock，综合应用JUnit和JMock进行对Java应用系统进行集成测试。（7）实验8：软件功能测试。软件功能测试是检验目标软件是否正确实现了客户需求，是软件测试执行的重要内容。实验8要求学生使用QuickTest Professional（简称QTP）对机票预订系统进行功能测试。本次实验要求学生能够独立完成功能测试脚本的录制和编辑，掌握QTP检查点设计的方法及技巧。（8）实验9：软件性能测试。实验9介绍软件性能的概念和原理，讲述如何运用HP Mercury LoadRunner对Web系统进行性能测试，让学生在实验过程中理解虚拟用户技术，掌握基于LoadRunner的性能测试技术的过程及技巧。此外，本次实验要求学生利用课余时间使用开源的性能测试工具JMeter进行软件性能测试。
3.创新项目实践。为了培养学生的工程实践能力，我们从学生课程项目、毕业设计、大学生创新项目、开源软件项目等中筛选出软件规模适中的软件系统作为课程实训项目，让学生对课程实训项目进行系统化的软件测试，要到学生主动动手实践，在软件测试项目实践中培养工程素养。
在课程教学过程中，我们还加强对基础扎实、动手能力强、思维活跃的学生的培养，推荐这些学生参与到教师科研项目中，为学生在科研项目中积累软件评测经验。
四、结束语
《软件测试与质量保证》通过十余年的建设已形成了较完善的课程体系，十多轮的授课实践积累了丰富的教学经验，课程实验教学体系也日趋完善。
当前，我校正转型应用技术大学，这将对本课程的教学内容、教学方法、教学手段等提出更多、更高的要求。鉴于此，本课程教学团队正尝试通过校企合作模式开展课程教学活动，编写校本教材，多措并举提升学生软件测试能力。
参考文献：
[1]朱少民.全程软件测试[M].北京：电子工业出版社，2007.
[2]NIIT.Software testing and quality assurance[M].上海：NIIT（中国），2011.
浅析软件测试技术与测试管理 篇7
1 下面介绍几种测试的方法
1.1 静态测试和动态测试
(1) 静态是指被测试程序不在机器上运行, 而是采用人工检测和计算机辅助静态分析的手段对程序进行检测, 主要方法包括人工测试和计算机辅助静态分析。静态分析的查错和分析功能是其他方法所不能替代的, 静态分析能发现文档中问题。目前, 静态测试已被当做一种自动化的、主要的代码校验方法。但静态测试不能检测程序的实际执行情况, 无法得到程序的执行结果。
(2) 动态测试是实际运行被测程序, 输入相应的测试用例, 判定执行结果是否符合要求, 从而检验程序的正确性、可靠性和有效性。一般意义上的测试主要是指动态测试。动态测试是一种经常运用的测试方法, 无论在单元测试、集成测试中, 还是在系统测试、验收测试中, 都是一种有效的测试方法。但动态测试不能发现文档问题, 必须等待程序代码完成后进行, 发现问题相对迟得多, 一旦发现问题, 必须重新设计、重新编码, 必然增大不良质量的成本。
1.2 黑盒测试和白盒测试
(1) 黑盒测试, 也称功能测试或数据驱动测试。黑盒测试是在已知产品所应具有的功能, 通过测试来检测每个功能是否都能正常使用。测试时, 测试者只在程序接口进行测试, 它检查程序功能是否按照需求规格说明书的规定正常使用, 程序是否能适当地接收输入数锯而产生正确的输出信息, 并且保持外部信息的完整性。“黑盒”法是穷举输入测试, 只有把所有可能的输入都作为测试情况使用, 才能以这种方法查出程序中所有的错误。实际上人们不仅要测试所有合法的输入, 而且还要对那些不合法但是可能的输入进行测试。
(2) 白盒测试, 也称结构测试或逻辑驱动测试。白盒测试是通过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时, 测试者必须检查程序的内部结构。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误, 因为穷举路径测试决不能查出程序违反了设计规范, 即程序本身是个错误的程序。
1.3 自动化测试
随着软件系统规模的扩大和软件应用领域的不断扩展, 软件系统的测试也变的越来越困难, 传统的测试已经无法满足测试的需要, 自动化测试应运而生, 自动化测试是指在预设条件下运行系统或应用程序, 评估运行结果, 包括正常条件和异常条件, 自动化主要研究的是自动化框架测试、自动化测试脚本技术、自动化用例生成。通过资料了解, C-ATFM模型。该模型基于C语言, 面向对象集成环境, 采用源码嵌入有效的分析软件的代码、词法、语法、策略、指令。并且随着软件工程及软件测试的发展, 自动化的机器测试发展更有前景。
2 下面简介软件测试的过程
2.1 模块测试
模块测试主要针对软件设计中的程序模块, 通过测试技术测试程序块是否正确, 模块测试的主要目的是测试程序内部的错误, 根据程序设计的结构检查代码和程序是否合理, 是否符合设计思路和理念, 是否能够正常运行。
2.2 组装测试
在模块的基础上, 需要将所有模块的功能全部测试完成后组装成为系统, 组装测试的目的在于, 连接所有模块之后, 模块之间的接口、触发器是否能正常运行, 并且计算显示的数据是否正确, 模块之间的功能是否互相冲突, 是否达到预期的目的和结果显示, 是否构成正确的、预期的数据结构。不同模块之间的误差有多少, 有多少可以解决, 有多少不能解决。
2.3 确认测试
确认测试的目的是验证软件的功能和特性是否达到预期的愿望, 是否能按照预期的组织结构、系统结构、用例分析和时序分析运作, 并且进行验收测试和安装测试。
2.4 系统测试
系统测试是确认软件是否与硬件互相支持, 是否能满足软件使用者对软件的需求和操作简便的愿望, 比如说查询模块运行完后界面中查询条件应该为查询之间输入的查询条件。系统测试保证了系统的正常运行, 另外很重要的就是权限测试, 系统在研发之初定义的权限信息和权限功能是否实现, 是否发现软件成品与软件定义不符合或者矛盾。
3 软件测试技术的地位
程序是由人完成的, 并且软件开发是个很复杂的过程, 期间很容易产生错误, 无论是软件从业人员还是专家、学者都无法避免的产生错误, 因此, 软件中存在错误和BUG是正常的、无法改变的。所以, 软件测试的目的是通过测试技术尽可能的发现软件在研发和使用中的漏洞, 并且找到解决问题的办法, 以期提高软件的质量。一个成功的测试用例在于发现了至今尚未发现的缺陷。其实, 。软件编程的过程也会出现一些不可避免的错误, 例如:对于用户需求的错误分析和编程出现的一些语法错误, 如果软件与发票费用相关更是与测试密不可分。软件不断地接近成熟和完成以及投入使用阶段, 软件测试工程师必须更加谨慎的检测每一部分程序, 一段程序的完成, 测试工作量占有总工作量40%以上, 这就给我们说明:测试是软件开发成功的重要组成部分。
4 软件测试的展望
软件质量越来越被人们重视, 测试驱动的开发技术被人们所接受, 软件测试已不再简单的是软件生命周期中的一部分。随着技术的发展, 测试技术将被更多的应用于项目开发之中, 而未来的软件开发更多的是以测试为目的的开发, 通过工具的自动化测试功能, 保证开发人员的代码质量和整个系统的质量。通过自动化测试与人工测试相结合, 更快更好的完成测试工作, 对于测试人员, 可能更多的是需要考虑如何持续改进, 这也就是进行质量管理的目标所在。
摘要：随着计算机硬件的飞速发展, 应用范围的扩大, 软件研发的数量也急剧增长且涉及各个领域, 软件日益增长的需求使得研发的矛盾也越来明显, 引发了软件危机, 在这样的情况下, 软件工程的软件测试部分显得愈发重要, 1993年的IEEE是这样定义软件测试的:“将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程, 即将工程化应用于软件中”。软件测试就是在软件投入使用之前, 对软件的需求分析、设计规格说明和系统编码的最终复审。所以, 软件测试不止是为了测试程序, 需求分析、概要设计、详细设计和流程设计都是软件测试的对象。
关键词：软件测试,测试技术,测试工具,信息化管理
参考文献
[1]陈会霞, 周利华.关于软件测试的浅议[J].中国测试技术, 2005 (04) .
[2]王晓华.软件测试技术应用研究[J].国防科技工业, 2012 (03) .
[3]钟百成, 张言上.关于软件测试技术的探讨[J].数字技术与应用.2012 (02) .
软件测试技术与测试管理研究 篇8
在计算机行业,为了保证软件产品的质量,就需要对软件的运行过程进行控制,同时在软件开发过程之中以及在被投入使用之前,都需要对软件进行多次的检测,保证在软件开发过程中就发现问题,解决问题,防止软件安全漏洞,将最好的成果展现给客户。目前,形式性的方法和软件正确性的证明都还不是使用较多的实用性方法,因此,在相当长的一段时期之内,软件测试仍然是保证软件质量的有效方法。软件测试的工作量很大,根据有关统计,一些要求较高的正规软件,用于软件测试的时间甚至占据了软件开发时间的一半以上。并且软件测试的许多操作都是重复性的、非智力创造的。因此,在针对这些操作进行检测时,就可以运用计算机的自动化技术,这样既可以提高软件开发团队的开发效率,也可以促进自动化技术的发展。
1 关于软件测试管理
在软件测试的过程之中,为了保证软件测试的各项工作能够安全有序地进行,就要对整个测试过程进行有效的干预或管理。在这个过程中,就形成了规范化的软件测试管理方案及技术。测试管理工作在各个阶段都有所体现,包括了各阶段的测试计划、具体测试案例、管理测试流程,并且对结果进行跟踪记录,最后将软件测试的结果反馈给软件开发公司或管理者。其间,测试管理人员如发现软件的任何错误或漏洞,首先必须记录在案,然后对软件漏洞进行跟踪,寻找漏洞生成的原因,并提出解决方案,在一系列的事情完成之后,统一整理成报告,上交给软件开发的管理者审阅。其目的是最大限度地将软件错误减少到最小,保证软件的可靠性。当然,在软件测试管理过程中,如果没有相应的辅助工具,仅仅依靠人工进行处理,可以说是不现实的。下文会继续简述软件开发行业常用的测试管理技术。
2 我国软件测试管理工具研究现状
目前在我国使用较为普遍的是i-Test管理系统,属于中科软科技股份有限公司研发;还有Test Center管理系统,属于上海泽众软件科技有限公司研发。以下就比较完善的i-Test管理系统为例,简述软件测试管理系统的功能特点。
大部分的软件测试管理系统都可以有效地提高软件测试的工作效率,从而极大地降低工作人员的工作负担,并且有利于加强管理层的监督,协调软件测试过程的能力。其最终目的是保证软件的质量,减少成本,i-Test管理系统的功能特点有以下几点。
2.1 运用B/S结构
B/S结构的主要特点在于其可以有效地安装在网络服务器上,这样做的作用是保证相关软件测试的人员可以无论何时何地,通过互联网登录正规工作软件,输入软件测试相关工作人员独特的账号和密码进行查询,为工作人员的工作带来了很大的便利,也大大地较少了人员集中造成的错误和麻烦。
2.2 资源共享
在软件测试管理过程中,软件开发负责企业会提供以往测试用例数据库资料和软件缺陷的数据库,并且负责软件开发的相关技术人员可以申请访问权限,从而共享和使用这些资料。通过对以往软件管理成功经验的吸取以及对失败经验的反思,才能进一步开发出优质的软件,提高软件测试技术,并且提高软件测试管理水平。
2.3 提供相应的自动化功能
软件测试的过程是一个涉及面广且比较复杂的过程,其中难免会有一些重复、无须智力创造的测试步骤。在实际软件测试的过程中,如果这些步骤全部依赖于相关项目人员,则会大大增加工作人员的负担,导致出错。而自动化功能则能代替人工去处理简单的重复、无须智力创造的步骤,可以实现高效率的编写,运行,查询测试用例;在编写软件测试缺陷报告时,能够快速地填写并且修改、查询相关资料,协助分析缺陷原因;另外还能够自动化计算软件研发的进度,输入相关数据自动生成所需的统计图表,还能进一步测试文档的模板,传送到工作电脑中进行排版并打印出来。总之,自动化功能极大地减轻了工作人员的负担,提高了工作效率。
2.4 改善测试过程中存在的缺陷
针对软件测试过程中存在的缺陷,并将其分为6个周期进行详细记录,跟踪、管理每个软件缺陷的研发过程,直到提出解决缺陷的建设性意见,并且按照严重的程度,逐一进行解决。
2.5 加强工作人员的沟通
所有的相关人员随时可以查看相关测试文档、成功用例、缺陷的信息以及测试图表,并且随时可以参与软件的讨论,提出自己的意见。这样也增强了工作人员的团队协作精神,创造了良好的工作氛围。
2.6 加强了软件测试管理的透明度,提高了管理层的监控
软件开发的管理者能对软件测试的过程进行动态的检测,如果发现问题,其有权利协调软件调试的过程。
3 相关的软件测试技术与测试工具
软件测试的核心是测试用例,测试用例的重要性在于其质量与测试的效率息息相关,并且具有良好的发现问题的能力,因此,在软件测试管理的过程中,对测试用例的管理是最核心的功能,而软件测试管理工具则需要协助测试用例的编写。常用的测试软件的方法有黑盒实验、白盒实验、灰盒实验。
3.1 黑盒实验
一般来说,软件的黑盒实验是在软件的接口处进行,即在外部进行,不考虑内部的特征和逻辑结构。这种方法就相当于将测试的对象看成是一个黑盒子,相关工作人员只需按照说明,检查软件的功能是否符合软件的说明介绍。黑盒实验的主要目的包括以下几个方面:
(1)是否存在错误或者遗漏的功能。
(2)在测试对象的接口处,输入的信息是否能被接受,接手之后能否输出正确的信息。
(3)是否存在数据结构方面的错误,或者访问权限错误。
(4)检查软件性能上能否满足客户要求。
在使用黑盒实验时,需要注意要通过制定测试用例起到对软件测试的指导作用,保证软件测试能够有计划、有目的、有条不紊地进行。还有一点就是,在黑盒实验过程中,必须加以量化,只有这样,才能真正提高软件的质量以及客户满意度。在计算机行业,具体的黑盒实验具体量化的方法包括:等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交实验设计法、功能图法、特点图法等。
3.2 白盒实验
与黑盒实验不同,软件的白盒实验主要是对软件的细节作细致的检查。这种方法就相当于把盒子打开,让盒子里的东西展现在人们眼前,由此让工作人员了解到软件的内部逻辑结构以及相关的信息,并且可以利用这些信息,设计或选择测试用例,同时对程序中所有的逻辑路径进行测试。最后通过在不同的检查点检查程序状态,确定实际的状态是否与预期中的状态一致。
白盒实验的主要功能有:
(1)在所有的软件程序中,对于独立的软件路径,每条路径至少测试一遍。
(2)对于所有的关于逻辑的判定,取“真”和取“假”的情况至少都要测试一遍。
(3)对于循环的边界或者是运行的界限内,则选择执行循环。
(4)测试软件内部结构的数据有效性。
白盒实验的具体测验方法有静态结构分析法、代码检查法、静态质量度量法、逻辑覆盖法、基本路径测试法、符号测试、域测试、程序变异等方法。
3.3 灰盒实验
所谓灰盒实验,即是介于白盒实验与黑盒实验之间的,同时具备两者的功能。也就是说,灰盒实验既关注接口处输入以及输出信息的正确性,同时也关注内部结构的逻辑性和联系性。灰盒实验不像白盒实验般详细和完整。只是通过一些特征性的现象来判断内部的运行情况。但有时候灰盒实验又是必需的,特别是在黑盒实验检验表示不存在问题,但是软件又不能正常运行时,这时候如果进行白盒实验,则工作量比较大,但是如果先进行灰盒实验,可能会发现问题,提高检测效率,也就是分担白盒实验的工作效率。
4 软件测试管理工具设计
软件测试管理系统采用的是浏览器/服务器,B/S三层软件体系结构,其中B/S结构是随着互联网技术的发展兴起的,在B/S体系结构下,客户界面可以通过WWW浏览器实现。其有一部分的逻辑结构是在前段体现的,但是主要部分的逻辑结构是在服务器端实现的。
浏览器/服务器,B/S三层结构主要是利用浏览器技术,同时结合浏览器的多种语言,在这个过程中,仅仅使用浏览器就完成了以往多种复杂操作才能实现的功能,从而大大地减少了软件开发成本。
5 结语
近年来,伴随着计算机技术的快速发展,人们对软件的要求也越来越高。本文探讨了一些软件测试的常用实验方法,能够有效地测试软件的可靠性,保证软件的实用性和精确性。同时对软件测试管理方法也有了大概的认识,可以说,在一款软件的开发过程中,对软件的测试是非常重要的,它直接涉及软件的质量,而设计软件的初衷就是为了打开市场,获取利润。同时软件的质量与市场使用量息息相关。因此,在这个过程中,只有充分关注软件测试技术,做好测试管理工作,才能开发出用户满意的优质产品。
摘要：近年来,经济的发展与社会的进步,极大地促进了计算机技术的发展。由于当今社会互联网的普遍使用,人们生活的方方面面越来越依赖于互联网,因此也对计算机软件提出了更高的要求。在这种情况下,就要求计算机行业必须具备先进的软件测试技术以及相应的测试管理研究,前者属于技术层面,是在互联网普遍发展潮流中的必然选择,也是为了满足客户的多种要求,从而取得竞争优势;而后者则属于管理层面,软件测试管理发挥着一种整体的技术,体现在软件测试过程的每个步骤之中。文章认为,两者协同作用,可以有效提高软件测试的管理水平以及软件测试水平。
关键词：软件测试,技术研究,测试管理
参考文献
[1]张德平,聂长海,徐宝文.基于Markov决策过程用交叉熵方法优化软件测试[J].软件学报,2008(10):2770-2779.
[2]蒋芃,李健.计算机软件测试管理应用研究[J].湖南理工学院学报:自然科学版,2007(1):42-44.
[3]闫茂德,许化龙,訾向勇.软件测试技术及其支持工具介绍[J].集美大学学报:自然科学版,2003(2):154-159.
[4]柳永坡,邹磊,金茂忠,等.软件测试领域的知识管理及模型研究[J].计算机应用研究,2009(1):143-145.
[5]王君,管国红,刘玲燕.基于知识网络系统的企业知识管理过程支持模型[J].计算机集成制造系统,2009(1):37-46.
分析软件测试技术与测试管理 篇9
1软件测试管理的概述
1.1软件测试管理的内容与目标
软件测试管理的实质在于跟踪与管理各测试阶段中的相关计划与流程, 并将测试管理的相关结果向系统研发职员与管理职员举行反馈, 同时要求凭据软件系统中的缺陷天生相应的陈诉。测试管理的内容重要包罗对过程的测试、对职员的测试以及对事情产物的测试。此中在管理测试过程方面重要考量软件的应用环境与测试是否具备有用性, 在此底子上做好后期测试过程的革新。在管理测试职员方面, 需对软件职员的事情状态等相关数据举行分析与网络, 果断是否与预期测试目标相符合。而在管理事情产物测试方面重要对测试软件产物举行分析与丈量并从中获取可以大概为决议计划提供参考的数据信息。因此, 软件测试管理的目标实质是控制与管理整个测试流程, 以此保证软件产物的质量。
1.2软件测试管理重要观点分析
软件测试过程中涉及的观点重要包罗测试用例、缺陷以及协划一方面。此中的测试用例可细化为相关的数据与所得出的结果, 用于果断测试结果是否与测试计划目标相符合, 确定软件应用步伐中是否存在影响正常运行的题目。而缺陷的观点, 很多研发职员每每以Bug代指软件开发过程中存在的题目, 从狭义角度分析指为由步伐编写过程孕育发生的题目, 而在广义上以为软件应用利用过程中出现的错误。而对协同的观点, 凭据以往学者将其应用于盘算机中的界说为对空间漫衍与时间分散支持的同时, 使软件各部门派合互助。
2以P-TMS为例的软件测试管理系统分析
2.1从需求跟踪管理角度出发
举行需求跟踪管理过程中所分析的重要为用户原始需求, 此中的测试用例会合所包罗的用例具有肯定的联系关系性, 且对应测试用例每每存在肯定的缺陷题目。但值得注意的是很多需求项无需利用测试用例, 不必对其跟踪管理。别的, 在需求跟踪过程中, 由于用户对软件项目标需求差别阶段会存在肯定的变革, 要求构建需求变动流程, 详细过程包罗对需求变动的申请, 在此底子上订定变动的决议计划, 末了在落实阶段需对测试用例重新计划并修改测试用例库。
2.2从测试用例管理角度出发
软件测试事情的成败很大水平上受测试用例管理的影响。详细管理过程中起首需对其构造布局举行分析, 保证此中的上下级系统、子系统、功效模块以及测试用例集等设置公道, 通常各功效模块中每每包罗很多功效项, 而功效项中聚集部门测试用例集, 各测试用例集又存在很多测试用例。其次, 由于被测软件项目存在功效相似或同样的环境, 具有同样的测试要求。对此可引用复用技术, 测试功效项或需求项雷同的软件过程中便可在测试用例库中探求对应的测试用例完成测试过程。
2.3从缺陷管理角度出发
软件生命周期内无论研发阶段或利用阶段都存在肯定的缺陷题目, 要求做好缺陷跟踪管理事情。软件项目测试管理中的相关职员都可对存在Bug向测试主管提交, 而测试职员便需做好缺陷状态以及管理缺陷题目标相关数据统计, 以使项目希望环境可被实时掌握。同时, 应做好项目缺陷的分类, 如步伐题目、数据处置处罚中的错误、编码范例性题目、接口错误、内存管理、系统性能等方面, 在此底子上针对每种范例缺陷提出相应的管理方案并存档与缺陷方案库中, 再次出现该类缺陷时便可从方案库中找到对应管理方法。
3关键技术在软件测试管理中的应用
凭据前文中对P-TMS软件测试管理系统的分析, 在现实计划测试管理系统过程中需重点做好重要功效模块的计划事情。此中在计划重要功效模块过程中要求将模块笼罩整个测试管理过程中, 详细包罗项目范围管理模块、需求项管理模块、测试用例模块、实行计划模块、测试用例模块、管理缺陷的模块、天生报表与系统团体管理模块等。而在计划数据库过程中需凭据相应的模块内容, 保证各模块间的相关数据融于数据库系统中。这种计划测试款力模块的关键技术重要表如今以下几方面。
3.1状态流转技术的应用
状态流转技术的提出重要针对软件中存在的缺陷题目, 计划过程中思量到软件开发与应用的脚色以及详细职责内容。同时, 在现实处置处罚缺陷中除举行状态转换中的相关信息外, 其他很多活动信息都具有显着的缺陷属性, 对此需保证到处置处罚关键的缺陷处置处罚都需创建在前一关键处置处罚完成的底子上。
3.2前置测试的关键技术应用
前文在计划构建测试管理系统过程中应用的重要为前置测试技术, 其在应用过程中重要思量到软件在开发初期便通过测试管剃头现此中存在的题目, 制止开发中缺陷较多, 有利于软件开发质量的进步, 也便于后期维护事情。而除应用前置测试技术外, 现实构建测试管理系统中也应用测试驱动开发相关理念, 为各测试管理关键提供保障。
3.3测试信息共享的关键技术应用
软件测试管理过程中的测试信息共享重要表如今测试用例信息以及缺陷信息的共享。在测试用例信息方面可充实发挥测试用例库的作用, 要求计划职员将差别范例的测试用例存储于测试用例库中。同时, 在计划测试用例库中也可引入复用技术, 对需求项或功效雷同的测试用例接纳直接复用的方法。别的, 在缺陷信息共享方面, 可将差别范例的缺陷以及相应的分析管理方法存于缺陷方案库中。使软件中出现雷同缺陷时, 可在缺陷方案库中探求对应的管理方案。
4结语
软件质量的保证需充实发挥软件测试管理的作用。通过文中基于过程的软件测试管理系统计分剖辨, 要求在现实构建过程中注意应用状态流转技术、前置测试技术、信息共享以及度量测试过程与结果的相关技术, 并保证测试管理系统中个模块如项目管理模块、测试的计划以及管理缺陷等模块都可发挥应有的结果, 如许才可有用监督测试管理的全过程, 为软件质量提供坚固的保障。
摘要：随着科学技术的快速发展, 对软件质量也提出更高的要求。而软件质量的保证重要得益于有用的测试管理, 以往软件测试过程中重要会合在软件编码测试方面, 轻忽对软件项目开发的全过程举行分析。对此要求对庞大的软件测试项目构建美满的测试管理流程, 从软件测试管理中促进软件应用质量的进一步进步。文章重要对软件测试管理的根本概述、P-TMS软件测试管理系统的研究计划以及所应用的关键技术举行探析。
关键词：软件测试,管理过程,关键技术
参考文献
[1]张英.软件测试过程管理控制的研究[J].南昌航空工业学院学报, 2015 (02) .
[2]张涑贤.软件过程质量管理[M].科学出版社, 2008.
软件开发测试 篇10
近年来,国内越来越多的企业开始实施CMMI,逐步开始或者已经建立了符合CMMI模型要求的过程体系。CMMI成熟度二级中包含了一个叫做度量与分析(Measurement and Analysis)的过程域,换句话说,无论是根据CMMI成熟度二级还是三级建立组织过程,都必须对软件开发过程进行度量。
实际上,软件度量并不是CMMI创造的新概念,上世纪80年代,DeMillo和Lipton就描述了度量理论与软件度量的关系[1]。之后,与软件度量及模型相关的文章书籍相继出现,越来越多的研究人员及工程实践人员开始关注这个领域的发展。毫无疑问,使用度量对软件开发过程进行管理是提高产品质量的有效手段。
但是,由于国内许多实施CMMI的组织对于软件工程的理解不足,导致了在建立度量目标、度量项以及进行度量分析时过于依赖外部专家,而对于组织的商业目标、度量模型以及如何使用度量数据并不理解,更多是因为“模型需要”而进行度量活动。
本文目的是为正在建立CMMI过程体系或已经建立但希望在度量方面进行改进的组织提供一定的参考。
1 测试过程度量
过程改进的重要目的就是提高软件产品的质量。而软件质量工程的本质就是研究过程(in-process)度量、项目特征以及最终产品质量的关系[2]。提高软件质量的方法有很多种,包括测试(本文的测试包含静态测试——评审检查以及动态测试)以及质量保证(QA)。而实际上国内许多企业对于QA的实践不足,因此本文在这样的背景下,介绍测试过程的相关度量以及分析方法。
关于如何开展度量活动,实际上CMMI模型MA(Measurement and Analysis)过程域的一些特定实践(SP)也提供了相应的参考[3]。这些实践包括:(1)SP1.1——建立度量目标;(2)SP1.2——确定度量项;(3)SP1.4——确定分析程序。
在建立度量项以及分析方法时,组织既可以按照CMMI模型中已定的顺序,也可以循环地开展以上3个实践。
对于软件测试过程的度量项建立,我们可以参考GQM(Goal Question Metric,目标—问题—度量)方法。该方法的假设是组织首先确定组织目标以及项目目标,之后根据目标对过程、产品进行度量,度量数据必须与目标建立追溯关系,最后的度量数据能够反应目标实现的情况[4]。GQM的方法将度量体系分为3个层次:
(1)概念层(目标):更确切地说,这里的目标是指度量目标,可能是组织目标的一部分,也可能是组织目标的分解子目标。度量目标是指进行度量及分析活动的目的,是由于特定的原因,在特定的环境、过程下,根据特定的观点定义对象。
(2)操作层(问题):设定一系列的问题,通过了解目标对象的特征描述特定目标的实现情况。
(3)量化层(度量项):设定一系列的数据对所提出的问题进行量化回答。
如何为软件测试过程设立相应的目标、问题以及度量项就成为了关键。每个目标可以通过识别其三个坐标——对象(Object)、问题(Issue)、观察角度(Viewpoint)以及目的(Purpose)来确定。例如:
对象:集成测试
问题:效率
观察角度:项目经理
目的:提高
因此,我们设立了这样一个目标——提高集成测试的效率。
对象可以是过程或者产品,问题是对象的一个属性,而对于观察角度,由于选取的度量目标不可能与组织中的所有人员相关,必须在建立度量目标时,识别该过程或产品的相关人。
确定了度量目标之后,需要根据目标提出问题。这些问题可以是关于目标如何实现的或者是目标实现带来的结果[5]。例如对于上文提到的目标,可以提出以下几个问题:
(1)集成测试周期持续时间多长?
(2)集成测试阶段的缺陷移除率如何?
(3)集成测试阶段没有发现的缺陷引起的返工工作量是多少?
制定了符合目标要求的问题后,需要识别相应的度量,这些度量应该能够表现目标是否被实现,也可以认为是对于之前识别问题的量化回答。
对于度量的选择,可能来源于客观的数据,也有可能来源于主观的数据。例如,对于缺陷移除率的度量,由于对象明确,数据获取也不困难,使用客观的统计数据有助于明确地回答“问题”。而对于某些度量,例如客户满意度,由于缺少公认有效的理论模型或操作难度大,一些组织对于该度量的设定更多考虑的是客户对于产品的主观印象。
测试过程相关度量项需要根据组织的特点及需要进行选择。例如组织希望了解软件开发生命周期的薄弱点加以改进,那么可以收集所有缺陷,并对其引入阶段进行分析,统计开发过程各阶段的缺陷引入情况,并通过一定的分析确定改进机会。这些缺陷包括了评审发现的缺陷,单元测试、集成测试等内部测试发现的缺陷,以及验收测试和维护阶段发现的缺陷。
2 测试度量数据分析方法
度量的目的并不是收集数据,更重要的是通过对数据的分析了解过程、项目以及最终产品的状况,找到问题及改进机会。本小节介绍与测试度量相关的分析方法。
2.1 缺陷到达模式(Defect Arrival Pattern)
很多组织都会度量软件的缺陷率,希望能够通过该数据了解软件产品的质量以及可靠程度。各组织对缺陷个数的定义可能并不一致,有的组织仅收集发布前的遗留缺陷,有的组织还收集产品试运行阶段所发现的缺陷。但是实际开发的经验表明,交付前缺陷率相近的产品,其交付后所表现的质量可能完全不同。也就是说,在决定一个产品是否能够发布的时候,除了软件缺陷率,我们还需要其他的信息用以决策。缺陷到达模式就是其中一个可供使用的工具。
每个组织的开发模型可能类似于瀑布模型,也可能采用迭代开发模型,无论是哪一种方式,测试活动都会持续一定的时间。在整个测试过程中,可以记录各个测试时间段或者各次迭代测试发现缺陷的总数,之后描绘出类似于图1的图(X轴代表时间/次数,Y轴代表测试发现的缺陷数)。
图1记录了发布前缺陷率接近的两种软件产品的测试状况,然而两种产品的可靠程度截然不同。图1(a)展示的测试状况说明了该产品在早期就投入了大量测试工作,在产品发布前,缺陷数已经收敛;而图1(b)则说明该产品测试不足,这个时候进行产品发布会有较大的质量风险。软件开发中有一个基本的概念:越早发现缺陷,修复缺陷付出的代价越小。项目组通过对曲线的特征判断各阶段测试活动的充分性。需要指出,曲线的形态与模块的设计以及集成的顺序有关。
另外,测试是一个无止尽的活动,测试什么时候能够结束,产品什么时候才能发布也可能困扰着项目组。既然零缺陷发布的情况很少,我们只能选择产品缺陷率稳定在一个相对较低的水平后再进行发布。缺陷到达模式就能够给予我们一定的参考信息。
如果将测试的范畴扩大到技术评审,统计从需求开发、设计、编码到测试发现的缺陷率,X轴按照软件开发的阶段进行区域划分,那么可以得到各阶段的缺陷到达模式。从图中我们可以判断哪些阶段评审投入时间或效率不足,这种信息既能帮助项目作出及时的调整,也能帮助组织识别改进机会。
2.2 缺陷移除率(Defect Removal Effectiveness)
上文提到使用基于开发阶段的缺陷到达模式统计各阶段验证活动的投入是否充足,然而在计算效率时不能忽略另外一个参数——缺陷注入数。缺陷移除率就是用于表现阶段缺陷发现数以及缺陷注入数的关系。
缺陷移除率有不同的定义。以下列举出几种:
(1)Fagan(1976)定义为:
通过检查发现的缺陷数/检查前存在产品中的缺陷数*100%
(2)Jones(1986)定义为:
发现的缺陷数/(发现的缺陷数+之后发现的缺陷数)*100%
(3)Dunn(1987)定义为:
本阶段发现的缺陷数/(本阶段发现的缺陷数+后面阶段发现的缺陷数)*100%
Fagan的定义与Jones的较为类似,而Dunn的定义则与前者有细微差别。以表1数据为例:
根据Fagan及Jones的定义,集成测试阶段的缺陷移除率:
DRE=集成测试阶段发现的缺陷数/集成测试阶段存在的缺陷数=91/(50+77+97+2-7-22-60)=66%
根据Dunn的定义,集成测试阶段的缺陷移除率:
DRE=集成阶段发现的缺陷数/(集成测试阶段发现的缺陷数+系统测试阶段发现的缺陷数)=91/(91+49)=65%
可见Fagan与Jones的定义关注于某一阶段发现的缺陷数与该阶段存在缺陷数的比例,而Dunn的定义则关注本阶段发现的缺陷数与之后各阶段发现缺陷数的比例。无论使用何种定义,不难发现,缺陷移除率的度量具有滞后性,即某一阶段的缺陷移除率必须等到项目结束或者较晚才能得到,但是对于开发者而言同样具有意义。根据缺陷移除率的度量,开发者能够掌握开发过程中验证活动在各阶段的效率,能够有针对地改进验证过程,尽早地遏制缺陷的扩大。其次,通过对以往类似项目度量数据的比对,开发者能够合理地推测各阶段缺陷移除率的水平,从而预测软件产品的缺陷分布,并且制定相应的质量保证计划,既能够有效地提高软件产品的质量,又能够合理地分配资源,避免漫无目的地测试。
3 结束语
数据的收集及分析都需要花费时间和成本,而小规模企业往往考虑使用最少的资源实现度量实践,却忽略了度量的真正意义。缺少有效的需求调研及良好的设计开发,表面上看似缩短了交付周期,但是实际返工带来的投入往往是巨大而且不可控的。缺陷移除率能够帮助管理者发现开发过程的不足,以制定符合企业特点的调整策略。而对于缺陷到达模式的使用,小规模团队可以在测试的最后阶段使用,并且对关键缺陷进行统计,通过对缺陷检出趋势的观察来判断软件是否到达稳定状态足以发布。紧密地将组织目标与度量实践联系在一起,才能使度量真正地支持开发管理活动,获得更大的投资回报。
摘要：描述度量在测试过程中的使用方法。首先介绍了GQM的方法,并介绍了GQM方法针对测试度量的应用。之后对于数据如何使用及分析,介绍了两种分析方法:缺陷到达模式以及缺陷移除率,并比较了两种对于缺陷移除率计算方法的异同点。最后,针对小型企业如何进行测试度量,提出了建议。
关键词：软件开发,CMMI,GQM,度量,测试
参考文献
[1]Norman Fenton.Software Measurement:A Necessary Scientific Ba-sis[J].IEEE Transaction on Software Engineering,1994(3).
[2]Stephen H.Kan.Metrics and Models in Software Quality Engineer-ing,Second Edition[M].US:Pearson Education,1995.
[3]Victor R.Basili,Gianluigi Caldiera,H.Dieter Rombach.The Goal Question Metric Approach[M].Encyclopedia of Software engineer-ing,1994.
软件开发中的自动化单元测试浅谈 篇11
关键词：单元测试；测试驱动开发；Stub；Mock
中图分类号：TP311.52
目前国内很多软件面临的现实问题是质量较差，潜在bug较多，系统不稳定性。这其中的主要原因在于对软件测试的重视程度不够，或者没有系统的测试管理方法。软件测试可分为单元测试、集成测试、系统测试、验收测试，其中单元测试一般由软件模块的开发人员来完成，是软件质量保证的第一道关口。本文将主要针对单元测试介绍的一些技巧和指导原则，以期能给广大一线开发人员以启发和指导，提高在软件开发过程中的效率和软件的质量。
1 单元测试技巧
1.1 使用TDD测试驱动开发
测试驱动开发[1]是由Kent Beck倡导的一种以测试为中心的开发方法，它要求在开始编程之前首先编写测试代码，然后只编写使测试通过的功能代码，通过这种方式以测试驱动开发。这种方法使得代码的设计思路清晰、代码整洁，保证了其做且只做应该做的事。Kent Beck团队为此开发的xUnit测试框架使得该方法的使用更加方便。
在TDD開发中遵循：不可运行->可运行->重构的一个反复过程。首先我们编写测试代码，这时的测试代码是不可运行的，甚至于连编译都通不过，然后我们写最少的代码尽快让测试通过，为了让测试尽快通过我们甚至可以采用一些看起来不合情理的方法，然后进行重构，消除重复设计，优化设计结构，如此反复进行最终得到我们所需的整洁可用的代码。在这种开发方式生成的代码具有高的可维护性和较高的质量保证。
1.2 Stub和Mock的应用
在单元测试中难免遇到一些模块依赖于其它模块，而这些其它的模块很可能并不在我们的控制范围内，它们的开发进度、特性、发布时机等都是未知的，这就可能减缓我们的开发进度，甚至可能会导致我们的测试无法进行。为了解决这类问题我们可以使用Stub和Mock技术，从而消除在测试过程中对第三方模块的依赖。Stub和Mock是两种不同的策略，在使用上是有所不同的，但在很多时候对同一个单位模块的测试我们既可以使用Stub也可以使用Mock，他们两者的不同主要在于Stub是状态验证的，Mock是行为验证的[2]，具体如何选择可参考文献[2]。对于Mock技术，目前有很多的开源框架可以供我们选择，比较流行的有easymock，jmockit。在Stub和Mock技术的使用时机上，建议尽可能使用真实对象，只有当使用真实对象不方面时考虑才考虑使用Stub或Mock技术。
1.3 MVC构架的测试
MVC框架的测试是一个使用Mock技术的好例子。由于目前在一些主流MVC框架（如：struts，spring mvc等）下编写的一些模块（如Struts框架下的Action）在运行的过程中要依赖第三方容器，这就给自动化的单元测试带来了很大麻烦，使得这种测试很难进行，为此可以使用Mock技术来解决这一问题。我们使用Mock对象模拟容器，在这个模拟容器下对软件进行自动化测试。由于这些容器的功能一般比较复杂，所以编写这样的Mock也并不是一件轻松的事情，所幸目前和这些MVC框架对应的一般都已经有了比较成熟的Mock测试框架，我们只需要进行简单的配置就可以使用，如Struts框架有StrutsTestCase框架，Spring mvc下有Spring test框架等。
1.4 数据库测试
软件开发中比较流行分层架构，即将软件划分成多层，包括负责界面交互的表示层、负责处理业务逻辑的业务逻辑层、负责数据持久化的数据访问层。其中数据访问层中的DAO（数据访问对象）负责业务逻辑中对象的数据存取。数据的存取方案可以是多种多样的，但目前使用较多的还是关系型数据库。在这种关系型数据库做存储的系统中，DAO对象要负责和数据库管理系统进行交互。
单元测试中为依赖于外部系统的单元做测试是一件比较痛苦的事，为了消除这种依赖可以采用Stub或Mock技术，但如果要测试的对象就是DAO对象，这个问题就无法再回避。由于数据库是一个公共资源，如果测试过程中不加控制就很容易使其处于一种不可控的未知状态，使不同的测试之间相互干扰。为了在测试过程中始终保持数据库处于一种已知的可控状态，就要在DAO对象测试的过程中对测试数据库进行管理，为此在对DAO对象进行测试时要遵循以下过程：（1）对数据库当前状态进行备份；（2）为本测试准备数据；（3）进行测试；（4）将数据库恢复到测试前的状态。
目前比较成熟的数据库测试框架如：Dbunit，Unitils 等会提供的一些工具可以使我们更方便的完成数据库的备份恢复、测试数据的初始化等工作，从而使我们能够把更多的注意力集中在如何设计、编写单元测试和功能代码上来。
2 自动化单元测试中的一些原则
2.1 使得所用测试可以作为一个整体运行
自动化的单元测试要求我们将同一测试目的或同一测试环境下的所有测试用例组织成一个整体运行，以方便我们在重构或对程序修改时可以快速的对整个系统进行回归测试，可以使用xUnit框架下的testsuit将所有相关测试组织成一个测试套件。如果使用Maven开发则可以直接使用Maven提供的功能统一运行所有测试用例。
2.2 测试用例之间要做到相互隔离，避免存在相互干扰
保证各测试用例之间不产生相互干扰，这样可以方便我们在某一测试失败时快速定位问题所在。这就要求其一对于测试中公共资源的使用要特别小心，如果某测试用例对公共数据有影响，则要在测试执行前做好公共资源的备份，测试后做资源恢复，再者测试用例之间不能存在相互依赖关系，一个测试用例的成功与否不能依赖与另一个测试用例。
2.3 及时运行自动化的回归测试
对于每次重构或bug修复都要及时运行自动化的回归测试以保证此次修改没有将bug引入。无数经验证明在距离bug最近的地方发现并修复bug是代价最低的，同时及时的回归测试也可以给我们带来安全感，增强对程序的信心，提高代码的质量。
3 结束语
本文针对软件开发中的自动化单元测试，结合作者的实践经验，介绍了一些实用的测试技巧和测试基本原则。单元测试技巧部分主要介绍了一些目前业界在开发中最常使用的技术和框架，自动化测试原则部分则针对整个单元测试程序的编写和使用给出了作者的一些指导原则，通过这些方法和原则的使用以期能够帮助广大开发人员更好的做好单元测试，提高软件开发效率和软件质量。
参考文献：
[1]Kent Beck.孙平平，译.测试驱动开发[M].北京：中国电力出版社，2004.
[2]Martin Fowler.Mocks Aren't Stubs[OL].http：//martinfowler.com/articles/mocksArentStubs-.html，2007，01.
[3]Martin Fowler.王怀民，译.企业架构应用模式[M].北京：机械工业出版社，2004（07）：29-35.
作者简介：赵文杰（1979-），男，河南安阳人，助理工程师，硕士研究生，研究方向：软件工程。
试析软件开发过程中的软件测试 篇12
关键词：计算机软件,软件工程,软件测试
在软件刚开始发展的那段时期,测试被认为是毫无技术含量的“猴子的工作”。由于测试在当时完全不受重视,拥有最好的开发过程的开发人员也马上就撞上了质量墙。而在后来的软件发展过程中,又不断有无数知名的计算机软件故障被新闻大肆报道,如因为节约空间省略年份前两位导致在2000年损失几十亿美元的千年虫事件,又如未检测一个接口导致一个数据位的错误设定最终导致的火星登录事故,又如诺顿杀毒软件病毒库更新误杀Windows系统文件的赛门铁克事件。尽管已经有了无数教训,但由于软件错误或缺陷造成的悲剧仍然每天都在上演。而现在,软件测试实际上是被广泛认定为一项需要高超技术能力的行业。之所以称为“行业”是因为软件测试不再向过去那样可有可无,而是在软件开发过程中发展成必不可少的一部分。
1 软件测试的定义、目的
对于软件测试,著名学者Glenford J.Myers认为首先应该认定软件是有错误的,但之后可以通过软件测试去找出这些错误。他还就此提出一些重要的观点,这些观点也可以看作是测试的目标或定义。
测试是为了证明程序有错误,而不是证明它无错误。好的测试用例在于它能发现以前没有发现的错误。成功的测试是发现了以前从未发现过的错误的测试。
软件测试的目的如下:
(1)以最少的时间和人员成本,系统地去发现软件中存在的错误和缺陷。测试的目标就是成功地暴露程序的错误,因此,如果正确实施了测试,就能发现软件中存在的错误。
(2)通过测试证明软件的功能与需求规格说明书的要求相吻合。
软件测试与软件质量息息相关,简言之,软件测试是软件质量的保证。通过测试来发现错误并将其修正,最大程度上规避软件发布后由于潜在缺陷和隐患带来的商业风险是我们所最看重的。
2 软件测试的分类
2.1 基于测试技术的划分
2.1.1 静态测试
静态测试是指在不运行程序的情况下,依靠人工走程序进行分析,也就是平时写小程序时的测试方法。静态测试对软件的需求文档、设计文档及源码等进行检查,主要包括走查、需求确认等。
2.1.2 动态测试
动态测试是让程序运行起来的检查方式,研究程序运行后的外部表现和执行结果。
2.1.3 白盒测试
白盒测试是指通过分析程序的内部结构,检测和寻找问题。在进行白盒测试时,要对程序内部如何运行了如指掌,选出少量“最有效的”测试数据与预期结果进行比对。白盒测试主要包括语句覆盖、判定覆盖、条件覆盖及其中一些组合。
2.1.4 黑盒测试
黑盒测试是与白盒测试互补的方法,它只注重程序的外部表现,而忽略程序的内部执行过程。通过对程序功能的分析,可以发现与白盒测试不同的错误。
2.2 基于测试实施组织的划分
2.2.1 开发方测试
开发方测试是指开发商通过已有的人力和设备资源,站在开发者的角度对软件是否能满足需求规格说明书和软件设计说明书的测试,测试后需要能够提供客观证据证实软件的确通过了开发方测试。
2.2.2 用户测试
在用户所处环境下,安装运行软件,并让用户真实体验软件是否能达到自己的期望要求。用户在使用后,可以提出对软件的改进意见,并对软件进行评价。
2.2.3 第三方测试
第三方测试又叫独立测试,由不属于开发方及用户方的第三方组织对软件进行的测试,通常是在模拟用户使用软件的环境中进行测试。
2.3 基于开发阶段的划分
2.3.1 单元测试
单元测试又称为模块测试,是通常与编码发生在同一个阶段,可以运用人工测试和计算机测试(依靠驱动程序和存根程序)两种方法,对程序模块进行正确性检验的测试工作。单元测试需要从程序的内部结构出发设计测试用例,即采用白盒测试方法,可以对多个测试模块并行测试。
2.3.2 集成测试
集成测试在单元测试之后进行,是将所有的已测模块组装起来的同时进行测试。集成测试着重测试模块间的协调和通信,即模块的接口。此外,每当一个新的模块作为集成测试的一部分加入总体的时候,软件会产生一些变化,这时需要适当地做一些回归测试。
2.3.3 确认测试
确认测试用来检测与证实软件是否满足软件需求说明书中规定的要求。该测试是在用户积极参与下对软件满足所有功能的、行为的和性能的需求的最终保证,其中发现的往往是系统需求说明书中的错误。在确认测试过程中仅使用黑盒测试技术。
2.3.4 系统测试
系统测试是在完全真实的软硬件环境中检查软件系统能否正确地被安装、配置、连接和运行,确定程序最终能满足用户的需求。
3 软件测试的特性
3.1 重要性
软件测试可以保证最终设计出的软件满足需求说明和设计说明并且最终可以成功且稳定地运行,因为这其中任何一个环节出现问题都会在软件测试阶段表现出来。如果测试没有通过,则说明软件确实是在某些方面存在问题。在软件开发过程中,用在测试上的花销要在30%~50%。如果把软件维护阶段考虑在内的话,测试花销会有些降低。但考虑到维护也是软件的再开发及多次开发,其中也包含很多的测试工作。因此,通过对这部分数据的调查得出结论,软件测试在整个软件生命周期需要50%以上的时间和经济成本。总结起来就是,一个好的测试是项目成功的保证,可以大大降低将来的解决错误的成本,发现项目存在甚至潜在的众多问题。而一个不好的测试会影响软件的性能,导致在维护阶段花费巨额成本,甚至影响软件公司的名誉。
3.2 复杂性
软件测试是非常复杂的,因为软件只有在所有可能的路径下输入一切可能的数据全部执行一遍(即穷举测试),才能发现所有错误。但一般情况下,这是不可能发生的。
黑盒法是穷举输入测试,但输入的情况无穷无尽,不仅要考虑正确输入,还要考虑各种错误输入,才能保证程序的健壮性。白盒法是穷举路径测试,而程序的路径数不胜数,难免出现遗漏。而在遗漏的那些路径中,就可能存在着潜在的错误。
3.3 经济性
程序测试能证明存在错误,而不能证明不存在错误。在实际测试中,穷举测试工作量巨大,根本行不通。这说明一切的软件测试都是不彻底的。但软件工程的目标是,充分利用有限的人力、资源、时间尽最大可能进行最高质量的测试。这其中,可以通过对测试部分的轻重缓急排序进行不同程度的测试、研究测试策略等方法降低测试的花销。
4 软件测试的准则
4.1 正面和反面测试都有助于降低风险
正面测试是简单地验证软件是否向其所宣传的那样工作,这对于大家来说很容易理解,但市面上还是经常出现存在各种错误的软件,原因就是“没人测试过这个问题”。而反面测试则是验证确保不会在用户在正常业务使用中破坏。相比于正面测试,它更容易被忽略,还更需要测试人员的创造力。
4.2 静态和运行测试都有助于降低风险
现在大多数软件测试都必须运行程序代码才能完成,但一些人已经开始注意到这样一个事实----软件开发过程中会产生大量文档,如果对这些文档进行静态测试,就可以在没有开始编码前就大幅度地减少运行错误的数目。
4.3 自动测试工具有助于降低风险
在过去几年中,随着自动化性能测试工作变得越来越成熟,人们已经开始在条件允许的情况下尽量考虑用测试工具逐渐代替各种手工测试。
4.4 把最大的风险放在最先测试
当面临有限的测试人员、有限的测试工具和有限的测试时间的时候,就必须保证有足够多的测试资源用来至少把最大的商业风险测试好。
4.5 把最常用的业务行为放到第二个来测试
当测试了最大风险之后,就该选择测试最常用的那些业务行为。根据80/20法则(80%的业务行为由20%的系统功能提供),要确保将工作重点放到20%最重要的系统功能上。
4.6 统计分析错误发生模式和其他错误特征是预测测试完成的重要手段
到现在为止,还没有任何人能宣称他可以对任何规模稍大的商业软件系统进行完全的测试。那么测试人员怎么知道何时测试工作算完成呢?事实上,根据Weibull分布模型,测试人员在预测软件实现中应该发现的错误总数时,可以把误差范围控制在10%~20%。
4.7 像用户使用软件那样来测试软件
所有测试都应该能追溯到用户需求,这一准则看起来是那么的理所当然,但笔者认为,这是软件测试的灵魂。
4.8 测试不只是要花钱,也是一种投资
测试能带来明显好处,不仅能够降低商业风险,还可以大大降低将来维护的工作量,更是对软件的一种长远投资。
5 软件测试的步骤
如图1所示。
6 软件测试的现状、前景
对于软件测试行业的现状,有以下几点:企业越来越重视软件测试,但企业内测试人员所占比例仍然很低。测试行业越来越受人欢迎,但测试人员的实际水平却不尽如人意。这种矛盾反映出软件测试目前是一个巨大的人才缺口,但真正有能力填补这个缺口的人却不多。
对于该行业的前景,Harry Robinson在2004年就曾预测过软件测试的未来,他持有以下的观点:测试的方法日趋完善,测试用例会时常更新,机械化测试将被大量应用;开发人员会加入测试团队,测试与开发的界限将开始模糊,客户反馈都将成为测试的一部分。
7 结语
软件测试是软件生命周期中至关重要的一环,而软件测试行业可以说是“道路是曲折的,前途是光明的”。在所在的大连理工大学国家示范型软件学院进行调查,大部分本科生对软件测试了解甚少,甚至还有很多认识误区,认为测试是浪费时间,每次做项目在测试部分也都是草草了事,结果导致程序在交接后出现各种意想不到的错误
参考文献
[1]芦阳.云计算及其带来的机遇与挑战[J].电脑编程技巧与维护,2013,(2):104-105.
[2]陈明.软件测试.北京:机械工业出版社,2011.
[3]Gerald D.Everett、Raymond McLeod,Jr..Software Testing(Testing Across the Entire Software Development Life Cycle).北京:清华大学出版社(译),2008.