软件测试的分类方法
从软件产业的发展初期到目前的大型软件开发过程，软件测试已成为其中一个不可分割的部分。随着软件规模的日益增大，软件测试问题也日益突出，现代社会对软件的依赖越来越强,高可信软件测试有着广泛的需求，基于缺陷模式的软件测试技术作为高可信软件的重要保证,可以大大降低软件的缺陷密度,提高软件的可信性。本文从测试的基本概念入手,深入剖析软件测试相关理论
目录
摘要........................................................................................................................... 错误!未定义书签。1软件测试的发展史. (3)
2软件测试的相关背景 (4)
3软件测试的概述 (5)
3.1软件测试的定义 (5)
3.2软件测试的描述 (5)
3.3软件测试的目的 (6)
3.4软件测试的原则 (7)
4软件测试的发展趋势 (8)
4.1国外发展前景 (8)
4.2国内发展前景 (8)
4.3谈国内软件测试行业目前发展遇到的瓶颈问题 (10)
5软件测试的内容 (11)
5.1验证(VERIFICATION) (11)
5.2确认(V ALIDATION) (12)
6软件测试的分类 (12)
6.1常用分类 (12)
6.1.1黑盒测试 (14)
6.1.2白盒测试 (14)
6.1.3静态测试 (17)
6.1.4动态测试 (17)
7软件测试的过程 (17)
8总结 (19)
9参考文献................................................................................................................ 错误!未定义书签。
1软件测试的发展史
软件测试的发展历史：20世纪60年代（软件工程建立前），为表明程序正确而进行测试。1972年在北卡罗来纳大学举行了首届软件测试正式会议。 1975年John Good Enough和Susan Gerhart在IEEE 上发表了《测试数据选择的原理》的文章，软件测试被确定为一种研究方向。 1979年，Glenford Myers的《软件测试艺术》，对测试做了定义：测试是为发现错误而执行的一个程序或者系统的过程。. 20世纪80年代早期，“质量”的号角开始吹响。软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。制定了各类标准。. 1983年，Bill Hetzel在《软件测试完全指南》中指出：测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。. 20世纪90年代，测试工具盛行起来。. 1996年提出的测试能力成熟度TCMM（Testing Capability Maturity Model）、测试支持度TSM（Testability Support Model）、测试成熟度TMM（Testing Maturity Model）。. 到了2002年，Rick 和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命过程。
2软件测试的相关背景
相关背景：前段时间, 就是在我没有认真了解测试行业之前, 可能由于测试在中国的重视程度的问题, 我也一直认为测试应该是不重要的, 甚至认为有必要有专门的测试职业吗？认为软件主要是开发人员的事, 软件的成果也是由开发人员决定的, 当我在参加工作后, 真正从学校的学习环境中走上实际运用开发的时候, 事实上真的不是那么一回事哦。软件无处不在, 软而, 软件是人编的——所以不完美。臭名昭著的软件测试案例：
1、迪士尼的狮子王（1994～1995）软件在少数系统中能正常工作, 但在大众使用的常见系统中不行。后来证实, 迪士尼公司没有对市场上投入实用的各种pc机型进行正确的测试。
2、英特尔奔腾浮点除法软件缺陷（1994）英特尔为自己处理软件缺陷拿出4亿美元支付更换坏芯片的费用。导致付出如此昂贵的代价, 其主要原因是发现了软件缺陷没有正确的处理。
3、美国航天局火星极地登陆（1999）该项目使用前有经过测试, 两个测试小组双方独立工作都很好, 但从未走在一起。
4、爱国者导弹防御系统（1991）一枚导弹在多哈击毙28名美国士兵, 症结在于一个软件缺陷：一个很小的系统时钟错误累积起来就可能拖延14小时, 造成跟踪系统失去准确度。在多哈袭击战中系统被拖延100小时。
5、千年虫（大约1974）估计世界各地更换或升级该系统程序解决原有2000年错误的费用已经超过数亿美元。
3软件测试的概述
3.1软件测试的定义
软件测试使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的重要子域。
(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进；
(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；
(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法。
3.2软件测试的描述
测试是软件开发过程的重要组成部分, 是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的,
第一是确认软件的质量, 其一方面是确认软件做了你所期望的事情（Do the right thing）, 另一方面是确认软件以正确的方式来做了这个事件（Do it right）；第二是提供信息, 比如提供给开发人员或程序经理的反馈信息, 为风险评估所准备的信息；第三软件测试不仅是在测试软件产品的本身, 而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题, 这说明此软件开发过程很可能是有缺陷的。
3.3软件测试的目的
如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。在谈到软件测试时，引用Grenford J. Myers在《The Art of Software Testing》一书中的观点:
(1)软件测试是为了发现错误而执行程序的过程;
(2)测试是为了证明程序有错，而不是证明程序无错误;
(3)一个好的测试用例是在于它能发现至今未发现的错误;
(4)一个成功的测试是发现了至今未发现的错误的测试。这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发
现错误是软件测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。
3.4软件测试的原则
1．应当把"尽早和不断的测试"作为开发者的座右铭。
2．程序员应该避免检查自己的程序, 测试工作应该由独立的专业的软件测试机构来完成。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件, 特殊情况下要制造极端状态和意外状态, 比如网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象, 这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程, 一般有A测试出来的错误, 一定要有一个B来确认, 严重的错误可以召开评审会进行讨论和分析。
6．制定严格的测试计划, 并把测试时间安排的尽量宽松, 不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意, 修改一个错误而
引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档, 意义是不言而喻的, 测试的重现性往往要靠测试文档
4软件测试的发展趋势
4.1国外发展前景
在软件比较发达的国家，特别是美国，软件测试已经发展成为一个独立的产业，主要体现:
软件测试在公司中占有重要的地位。比尔?盖茨曾在马萨诸塞州技术学院的一次演讲中说:“在微软，一个典型的开发项目组中测试工程师要比编码工程师多得多，可以说我们花费在测试上的时间要比花费在编码上的时间多得多”。
在微软测试人员与开发人员比例一般为1:1,甚至在Windows 2000开发团队中，有1800个测试人员，900个开发人员，测试人员与开发人员比例为:1:2。
软件测试理论研究蓬勃发展，每年举办各种各样的测试技术年会，发表了大量的软件测试研究论文，引领软件测试理论研究的国际潮流。
软件测试市场繁荣。美国有一些专业公司开发软件测试标准与测试工具，MI、Compuware、MaCabe、Rational等都是著名的软件测试工具提供商，它们出品的测试工具已经占领了国际市场，目前我国使用的主流软件工具大部门是国外产品，而且世界各地都可以看到它们出品的软件测试工具，可见国外的软件测试已经形成了较大的产业。
4.2国内发展前景
中国的软件测试技术研究起步于“六五”期间，主要是随着软件工程的研究而逐步发展起来的，由于起步较晚，与国际先进水平相比差距较大。知道1990
年，成立了国家级的中国软件评测中心，测试服务才逐步开展起来。因此，我国无论是在软件测试理论研究还是在测试实践上，和国外发达国家都有不少差距，主要体现在对软件产品化测试的技术研究还比较贫乏，从业人员较少，测试服务没有形成足够的规模等方面。但是，随着我国软件产业的蓬勃发展以及对软件质量的重视，软件测试越来越人们重视。软件测试正在逐步成为一个新兴的产业。我国正在迈入测试时代，主要体现在以下几个方面:
我国著名著名的软件公司都已经或者正在建立独立的专职软件测试队伍，虽然测试人员规模以及所占比例还不能和国外的大公司相比，但是毕竟在公司内部贯彻了独立测试的意识。国家人事部和信息产业部2003年关于职业资格认证第一次在我国有了“软件评测师”的称号，这是国家对软件测试职业的高度重视与认可。
在信息产业部关于计算机系统集成资质以及信息系统工程监理资质的认证中，软件测试能力已经被定为评价公司技术能力的一项重要指标 ,2001年信息产业部发布的部长5号令，实行了软件产品登记认证制度，规定，凡是在我国境内销售的产品必须到信息产业部备案登记，而且要经过登记测试。
自2001年起，国家质检总局和信息产业部每年都通过测试对软件产品进行质量监督抽查。国家各部委，各行业正在通过测试规范行业软件的健康发展起到了很好的促进作用。
用户对软件质量要求越来越高，信息系统验收不再走过场，而要通过第三方测试机构的严格测试来判定。
“以测代评”正在成为我国科技项目择优支持的一项重要举措，比如，国家“863”计划对数据库管理系统、操作系统、办公软件、ERP等项目的经费支持，都是通过第三方测试机构科学客观的测试结果来决定的。软件测试正在成为部分软件学院的一门独立课程，对我国软件测试人才的培养起到了很好的作用。
第三方测试机构得到了蓬勃的发展，最近两年，在全国各地，新成立的软件
测试机构有10多家，测试服务体系已经基本确立。
可见我国的软件测试行业正处于一个快速成长的阶段，我们有理由相信，经过一段时间的发展，我们会逐步缩小与国外发达国家的差距，从而带动整个软件产业的健康发展。
4.3谈国内软件测试行业目前发展遇到的瓶颈问题
可见软件测试在国内发展是如此之快,但是不可忽视的是,在技术方面跟国外的还有较大的差距.毕竟软件测试在国内起步的晚,是相对年轻的行业.为了以后更好的发展软件测试打下扎实的根基,应该多吸取国外的测试经验.那让我们一起来看一下现今国内软件测试主要存在哪些瓶颈.
企业不够重视软件测试。软件行业在国内是属于一个热衷阶段，很多企业只是看到了眼前的利润，追求短时间的价值回报。软件测试在企业是一个消耗资金的部门，很多国内的很多中小企业还没有测试部门，就算是有也是不怎么受重视。如果软件测试得不到重视，那么软件质量在未来是让人堪忧。久而久之，导致客户对软件市场失去信任，结果是致命的，会严重的阻碍未来计算机的发展。
缺少专业的从业人员。由于在国内软件测试行业起步晚，在企业里还没得到足够的重视。企业招人也只要求是计算机相关专业的人都可以做测试，甚至有些企业只要有相关培训机构的培训非计算机专业的人也可以做测试。这就导致软件测试人员的专业素质普遍降低。为什么会出现这样的情况，很大程度上是因为软件测试人员的培养在国内只有极少的高校才有该专业。目前我国多数的检测工作还停留在设计人员一人身兼多职，这不仅不能保证检测工作的专业程度，同时由于主观因素也会对最终的检测结果真实性受到一定的影响，使检测工作貌似形同虚设，没有使最完善的软件系统投放到市场中去。如果雇佣专业的检测分析人员会从更专业校验角度来为软件把关。不仅在研发投放之前进行软件检测，在使用的过程中也会跟踪性服务，与客户和设计人员之间及时沟通，及时对后期的问题进行修复并对下一批次软件的研发起到提醒的作用。但这些我国目前都无法达到
相应的标准。
软件测试缺乏统一标准。无论任何的检测都应该有一个与全国统一或是全世界统一的标准，如此在交付完整软件时其兼容性可以得到最大的满足。如果任意按自行设定的标准检测其结果不够具有说服力。一般来说。软件测试的代码都是按一定标准进行编写，在实际工作中，测试代码是不能随意编写的，但是实际工作中，编写出来的测试代码以及测试代码运行的情况往往表现出一种随意性和无序性。当今软件测试行业对影响软件缺陷的重要度和修复度都缺乏统一的标准，使得部分软件缺陷在修复的过程中难免引入新的软件缺陷，影响了软件的正常使用。所以在今后的软件测试中，必须确保测试的标准要统一，要求测试者真正做到按照统一的规定来测试。举一个简单的例子:软件工作人员一般都知道，在软件测试中矩阵的行为测试，列为需求。矩阵中，用数字l标识该行的测试用例核
实了该列的需求。
总之，软件测试也应该是被扶植的计算机领域的朝阳产业，无论从人员的纳入还是技术水平提高要双管齐下，突破目前的发展问题，大力弘扬产业的内涵文化真正实现软件测试行业的发展创新。才能推动我国软件测试业的高效发展。
5软件测试的内容
5.1验证(verification)
验证(verification)是保证软件正确地实现了一些特定功能的一系列活动, 即保证软件做了你所期望的事情。(Do the right thing)
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程；
2.程序正确性的形式证明, 即采用形式理论证明程序符号设计
规约规定的过程；
3.评市、审查、测试、检查、审计等各类活动, 或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
5.2确认(validation)
确认(validation)是一系列的活动和过程, 目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right)
1.静态确认, 不在计算机上实际执行程序, 通过人工或程序分析来证明软件的正确性；
2.动态确认, 通过执行程序做分析, 测试程序的动态行为, 以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试, 软件测试应该包括整个软件开发期问各个阶段所产生的文档, 如需求规格说明、概要设计文档、详细设计文档, 当然软件测试的主要对象还是源程序。
6软件测试的分类
6.1常用分类
软件测试的分类可以按照开发阶段、测试实施组织、测试技术、测试过程等划分。下面重点介绍按照开发阶段划分:
按照开发阶段划分软件测试可分为:单元测试、集成测试、系统测试、确认测试和验收测试。
单元测试
单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试
集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
确认测试
确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与验证软件是否满足软件需求说明书中规定的要求。
系统测试
系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接，并满足用户需求。
验收测试
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
按照测试实施组织划分:开发方测试、用户测试、第三方测试。 , 按照测试技术划分:白盒测试、黑盒测试、灰盒测试。或静态测试盒动态测试。
从是否需要执行被测软件的角度, 可分为：静态测试和动态测试
从测试是否针对系统的内部结构和具体实现算法的角度来看, 可分为：白盒测试和黑盒测试
6.1.1黑盒测试
指的是把被测软件看作是一个黑盒子, 我们不去关心盒子里面的结构是什么样子, 只关心软件的输入数据和输出结果。
黑盒测试方法是在程序接口上进行测试, 主要是为了发现以下错误:
?是否有不正确或遗漏了的功能?
?在接口上, 输入能否正确地接受? 能否输出正确的结果?
?是否有数据结构错误或外部信息(例如数据文件)访问错误?
?性能上是否能够满足要求?
?是否有初始化或终止性错误?
用黑盒测试发现程序中的错误, 必须在所有可能的输入条件和输出条件中确定测试数据, 来检查程序是否都能产生正确的输出。但这是不可能的。
n假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数, 按黑盒方法进行穷举测试：
n可能采用的测试数据组：232×232＝264 n如果测试一组数据需要1毫秒, 一年工作365× 24小时, 完成所有测试需5亿年。
黑盒测试的测试用例设计
?等价划分法
?边界值法
?错误推测法
?因果图法
6.1.2白盒测试
白盒测试指的是把盒子盖打开, 去研究里面的源代码和程序结构。
白盒测试也称结构测试或逻辑驱动测试, 它是知道产品内部工作过程, 可通
过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 按照程序内部的结构测试程序, 检验程序中的每条通路是否都有能按预定要求正确工作, 而不顾它的功能。使用被测单元内部如何工作的信息, 允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例, 对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识, 测试是基于覆盖全部代码、分支、路径、条件。
白盒测试的主要方法：
?逻辑驱动测试
?基本路径测试
主要用于软件验证。
使用程序设计的控制结构导出测试用例。
逻辑驱动测试：
主要是测试覆盖率, 以程序内在逻辑结构为基础的测试。包括以下6种类型：?语句覆盖
?判断覆盖
?条件覆盖
?判定-条件覆盖
?条件组合覆盖
?路径覆盖
白盒测试的主要目的
?保证一个模块中的所有独立路径至少被执行一次；
?对所有的逻辑值均需要测试真、假两个分支；
?在上下边界及可操作范围内运行所有循环；
?检查内部数据结构以确保其有效性
白盒测试的实施方案
在开发阶段
要保证产品的质量, 产品的生产过程应该遵循一定的行业标准。软件产品也
是同样, 没有标准可依自然谈不上质量的好坏。所有关心软件开发质量的组织、单位, 都要定义或了解软件的质量标准、模型。其好处是保证公司实践的均匀性, 产品的可维护性、可靠性以及可移植性等。
在测试阶段
与软件产品的开发过程一样, 测试过程也需要有一定的准则, 来指导、度量、评价软件测试过程的质量。
定义测试准则
为控制测试的有效性以及完成程度, 必须定义准则和策略, 以判断何时结束测试阶段。准则必须是客观的, 可量化的元素, 而不能是经验或感觉。
根据应用的准则和项目相关的约束, 项目领导可以定义使用的度量方法, 和要达到的覆盖率。度量测试的有效性、完整性
对每个测试的测试覆盖信息和累计信息, 用图形方式显示覆盖比率, 并根据测试运行情况实时更新, 随时显示新的测试所反映的测试覆盖情况。
允许所有的测试运行依据其有效性进行管理, 用户可以减少不适用于非回归测试的测试的过程。
概念：
1.语句覆盖：语句覆盖就是设计若干个测试用例, 运行被测试程序, 使得每一条可执行语句至少执行一次；
2.判定覆盖（也称为分支覆盖）：设计若干个测试用例, 运行所测程序, 使程序中每个判断的取真分支和取假分支至少执行一次；
3.条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的每个可能取值至少执行一次；
4.判定-条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的每个条件的所有可能取值至少执行一次, 并且每个可能的判断结果也至少执行一次, 换句话说, 即是要求各个判断的所有可能的条件取值组合至少执行一次；
5.条件组合测试：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的所有可能的条件取值组合至少执行一次；
6.路径测试：设计足够多的测试用例, 运行所测程序, 要覆盖程序中所有可能的路径。
6.1.3静态测试
是指不实际运行被测软件, 而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。
其中包括代码测试、界面测试和文档测试3个方面。对于代码测试, 主要测试代码是否符合相应的标准和规范。对于界面测试, 主要测试软件的实际界面与需求中的说明是否相符。对于文档测试, 主要测试用户手册和需求说明是否符合用户的实际要求。
6.1.4动态测试
是指实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结果是否相符的过程。所以, 我们判断一个测试属于动态还是静态测试 , 唯一的标准就是看是否运行程序。
7软件测试的过程
1,测试计划
首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,即制订的最高标准,以后所有的测试都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的,同时,还要适当选择测试内容,合理安排测试人员、测试时间及测试资源等。
2,测试设计
将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并为每个测试过程选择适当的测试用例,测试用例选择的好坏将直接影响到测试结果的有效性,。
3,测试开发
建立可重复使用的自动测试过程。
4,测试执行
执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理。测试执行一般由、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责的态度,一步一个脚印地进行测试。
5,测试评估
第一，结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。
在进行测试前,首先必须理解业务和需求。需求和业务理解了,才知道客户想要系统实现什么。然后按照需求来进行测试,不满足需求要求的都可以认为是BUG。虽然在实际工作中,拿到一份完整详细的需求是很不容易的,但要做好一个软件测试,前提就是要对需求比较熟悉,各个业务细节都很了解,甚至做到比开发人员还要了解。除此之外,对于现在很多的信息处理相关的系统,还需要对整个业务
中数据库的操作比较清楚。比如哪个业务需要用到哪些表,做怎么样的操作。了解了这个就可以不单单从程序前台来看程序,看到数据库的过程,更有利于你找到隐藏的BUG。这些是从前台看不出来的,但实际可能会导致程序出现问题。
第二,了解程序的框架结构。比如很多B/S结构的系统中,前台是如何和后台通信的,之间是什么协议,什么格式,后台是如何处理这些数据的。再比如C/S结构的系统,服务器端和客户端之间是如何通信的,中间的数据包是什么格式,哪些功能由服务器端实现,哪些功能由客户端实现等等。了解这些有助于你更好的去
测试程序以及定位程序错误。
第三,和开发人员沟通。这里说的沟通并不仅仅指通过沟通试图让开发人员修改每个BUG,这个当然需要沟通,但是并不是指所有的BUG都需要修改,这中间涉及到成本、技术,还有别的问题。除此之外,通过和开发人员搞好关系,对于BUG 我们可以问他发生该BUG的原因,修改的大致方法,甚至不修改的原因等等,这有助于以后测试中多注意、多发现这样的问题,甚至提出修改建议。
第四,决定BUG严重性的时候,可以根据该被测对象在整个系统中充当的角色,实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响,对产生的影响打分,从而定义BUG的严重程度,决定BUG优先级的时候,可以先假设不修复该BUG,出现的这些问题会产生哪些影响,然后判定这些影响的严重性来判定BUG的优先性。
第五,容易产生BUG的情况,虽然在开发过程中,软件需求通常都会发生改动,所以如果某一部分的软件需求频繁发生变动,那么就会导致和这部分相关的编码和设计会相应的频繁变动,那么在测试中,这部分编码设计实现的部分出现BUG 的可能性就很大。
8总结
给软件带来错误的原因很多,具体地说,主要有如下几点,?交流不够、交流上有误解或者根本不进行交流 ?软件复杂性 ?程序设计错误 ?需求变化 ?时间压力等等。要解决这些错误就应该做好测试工作, 尽早的开始测试工作,并且测试工作贯穿于软件开发的整个生命周期。必须认真地做好每一步测试工作。当需要运行的测试多于现有资源所能运行的测试用例的测试时,一定要考虑分层增量测
试。要学会采用软件测试工程化的思想,要求建立正式的测试组织、明确测试的目标和流程、确定测试的活动、对测试的过程和活动进行监控,从而保证软件测试的质量.
通过对本课程的学习,对软件测试有了系统性的认识,了解到了软件测试在程序开发中的重要性,对软件测试的方法和测试的过程有了比较详细的认识,为以后的工作和学习奠定了一定的基础。
软件测试中常见问题分类说明 一、规范化问题 包括软件规范和业务规范两大类，软件规范问题主要指操作过程中显而易见的错误或缺陷，非人性化设计、友好度较差等；业务规范问题主要指使用非标准或非惯例的业务术语、以及概念错位等。 ㈠软件规范问题 1、操作指示不明确 提示存在二意性、提示操作项“忽略”、“取消”、“退出”等含义不明确。（一般） 2、简单界面规范问题 ①按钮图片丢失、按钮图片不配套、按钮大小排列不美观；（一般） ②在引用数据窗口的下拉框中，没有根据实际数据来调整下拉框显示的%的大 小和垂直滚动条，导致文本只显示了一部分；（严重） ③界面中存在色块；（一般） ④菜单排列顺序有误；（一般） ⑤窗体最小化以后在屏幕上找不到了，无法恢复原窗体；（一般） 3、操作过程缺乏人性化考虑 ①选项过于烦琐且不必要、设置不合适导致使用者遗漏、常规按钮排列顺序 不一致（一般） ②常用功能不支持键盘操作。（严重） ③单据处理中当由于存在空行时，提示用户输完其余内容，而没有自动删除 空行。（严重） 4、帮助文件规范问题 ①联机帮助字体、背景风格不统一；（较小） ②点击“？”按钮打开帮助文件，没有直接定位到内容；（较小） ③内容定位错误；（一般） ④帮助文件内部链接没有做全；（较小） ⑤文档内容排版错误；（严重） ⑥其他帮助错误。（一般） 5、软件风格规范问题 ①控件的切换顺序有误、DataWindow的切换顺序有误； （视控件使用频繁程度设为（严重）和（一般）） ②DataWindow内容的对齐方式不正确（数值右对齐、日期中对齐、文字左对 齐）；（较小） ③数值的EditMask（掩膜）设置有误、日期的EditMask（掩膜）设置有误、 日期的默认格式非YYYY.MM.DD、默认日期存在1900.00.00现象或其他不合 理的值（一般） ④弹出窗口不在屏幕中间位置、退出系统缺少提示；（较小） ⑤重大操作（月结、恢复、修复等）缺少提示、重大操作没有自动弹出备份 提示；（一般） ⑥快捷按钮定义不准确、快捷字母或数字重复、工具栏快捷键定义错误（一 般），工具栏常用快捷键缺少（较小）；
软件测试流程及规范V1.1
二、各阶段具体流程 1.需求分析阶段 立项 需求调研 编写/修改SRS 提交SRS SRS 审核 审核是否通过 达到要求 提交最终版SRS 审核是否通过 审核通过 依据SRS ，项目整体计划，设计、编写《测试计划》 和《测试设计》《测试计划》根据SRS 定义相应的测试需求报告，即制订测试的标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试 时间及测试资源等。 《测试设计》 将测试计划阶段制订的测试需求 分解、细化为若干个可执行的测 试过程，并为每个测试过程选择 适当的测试用例。 进入概要设计阶段评审测试计划 和测试设计优化测试计划、 测试设计1.1步骤说明 1、需求定义基本完成，SRS 编写完成。 2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题，相关人员解答并确认。 3、当评审未通过，直接打回，重新修改SRS ，问题解决后，重新提交评审。
4、当评审通过后，依据SRS，项目整体计划，设计、编写《测试计划》和《测试设计》，具体模板见附件。 5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。 6、当审批未通过，直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。 7、审核通过后，进入下一阶段。 1.2测试通过打回标准 1.3、阶段的输出 输入：最新SRS、项目计划 输出：测试计划、测试设计 2、单元及集成测试流程
软件测试基本流程与要求（提纲） 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试--测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。
软件测试基本流程与规范 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。
测试设计中需要考虑的22种测试类型 黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性。 白盒测试：基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。 单元测试：最微小规模的测试；以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。 累积综合测试：当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作，或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。 集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。 功能测试：用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。 系统测试：基于系统整体需求说明书的黑盒类测试；应覆盖系统所有联合的部件。 端到端测试：类似于系统测试；测试级的“宏大”的端点；涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。 健全测试：典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。 衰竭测试：软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。 接受测试：基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。 负载测试：测试一个应用在重负荷下的表现，例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。 强迫测试：在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。
软件测试基础教程 测试的基本概念 测试是软件生存周期中十分重要的一个过程，是产品发布、提交给最终用户前的稳定化阶段。 1、测试的分类： 从测试方法的角度可以分为手工测试和自动化测试。 手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。 自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理都是录制、回放技术。 从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。 单元测试：是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。 单元测试的依据是系统的详细设计；一般由项目组开发人员自己完成。 集成测试：在单元测试的基础上，将所有模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。 系统测试：系统测试是在所有单元、集成测试后，对系统的功能及性能的总体测试。 确认测试：模拟用户运行的业务环境，运用黑盒测试方法，验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性（功能、非功能）上的。 从测试原理上分为：白盒测试、黑盒测试和灰盒测试。 白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。 黑盒测试：是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时，把程序看作一个不能打开的黑盆子， 在完全不考虑程序内部结构和内部
软件测试标准规范 1目的 为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考 2适用范围 本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。 测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 项目负责人组织测试环境的建立。 项目经理审核负责控制整个项目的时间和质量。 研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》
在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容： 测试目的； 所需人员及相应培训要求； 测试环境、工具和测试软件； 测试用例、测试数据和预期的结果。 4.3 单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。 单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； 单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； 单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4 集成测试 编码开发完成，项目组内部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。 集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。 4.5 系统测试
软件测试基础教程 测试是软件生存周期中十分重要的一个过程，是产品发布、提交给最终用户前的稳定化阶段。 一、测试的分类： 从测试方法的角度分为： （1）手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。 （2）自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理都是录制、回放技术。 > 从整体的角度分为： （1）单元测试：是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。单元测试的依据是系统的详细设计；一般由项目组开发人员自己 完成。 （2）集成测试：在单元测试的基础上，将所有模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。 （3）系统测试：系统测试是在所有单元、集成测试后，对系统的功能及性能的总体测试。 （4）确认测试：模拟用户运行的业务环境，运用黑盒测试方法，验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性（功能、非功能）上的。 从测试原理上分为： . （1）白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。 （2）黑盒测试：是通过使用整个软件或某种软件功能来严格地测试，而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时， 把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它 只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收和正确的输出。 黑盒测试方法主要有等价类划分、边界值分析、因—果图、错误推测法。 A、等价类划分：是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子 集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试 用例设计方法。 B、边界值分析：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是 发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错 误。 C、错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的 方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特 殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的 错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据 和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错 误的情况。可选择这些情况下的例子作为测试用例。
第一章 什么是软件测试？软件测试的目的和作用是什么? 答： 软件测试是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。 软件测试的目的是以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。测试是为了证明程序有错，而不是证明程序无错。一个成功的测试是发现了至今未发现的错误的测试。 软件测试的原则包括：所有的测试都应追溯到用户的需求；尽早地和不断地进行软件测试；不可能完全的测试，因为输入量太大，执行路径太多；注意测试中的群集现象；避免测试自己的程序；设计周密的测试用例。 软件缺陷产生的原因？ 答：A．软件需求说明书编写的不全面，不完整，不准确，而且经常更改B．软件设计说明书C．软件操作人员的水平D．开发人员不能很好的理解需求明书和沟通不足 软件测试的意义？ 意义： 对产品质量完成全面的评估，为软件产品发布（如验收测试）、软件系统部署（如性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托方纠纷仲裁（第三方独立测试）和其它决策提供信息； 通过持续的测试（包括需求评审、设计评审、代码评审等）可以对产品质量提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地改进产品的质量，并减少各种返工，降低软件开发的成本； 通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷，降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的忠诚度。 通过对缺陷进行分析，找出缺陷发生的根本原因（软件过程中的问题，包括错误的行为方式）或总结出软件产品的缺陷模式，避免将来犯同样的错误或产生类似的产品问题，达到缺陷预防的目的 软件测试与软件开发的关系？ 答：软件开发是一个系统的工程。包括需求分析，设计，编码，测试，维护等等几个环节。测试是整个软件开发流程中的一个环节。 简述软件测试过程v模型和w模型的主要区别： V模型是软件开发完了之后才开始测试活动。 而W模型则是软件测试活动伴随着软件开发活动。和软件开发同时开展。 W模型更加敏捷，对于软件的交付期和品质的保证能力更强。 第二章 测试计划的目的是什么？ 答：软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。 什么是黑盒测试?黑盒测试主要采用的技术有哪些? 答：黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。它从用户观点出发的测试。用这种方法进行测试时，把被测试程序当作一个黑盒，在不考虑程序内部结构的内部
详细分析：软件测试的14种类型 文章来源：中国IT实验室收集整理文章作者：佚名发布时间：2007-09-03 字体： [大中小] 软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。 1. 数据和数据库完整性测试 数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。 数据库完整性原即： 主码完整性：主码不能为空; 外码完整性：外码必须等于对应的主码或者为空。 数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。 在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统(DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。 比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号;员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。 员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。 2. 白盒测试
白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。 白盒测试分为动态白盒测试和静态白盒测试 2.1 静态白盒测试 利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下： Function NameGet(){ …. } 这是属于不符合开发规范的错误。 有这样一段代码: if (i<0) & (i>="0) … 这段代码交集为整个数轴，IF语句没有必要 I="0; while(I>100){
软件测试必备基础知识 一、基本概念 软件测试 在规定条件下对程序进行操作，以发现错误，对软件质量进行评估，包括对软件形成 过程的文档、数据以及程序进行测试 软件测试的目的 发现程序中存在的错误发现程序中存在的错误，而不是证明程序无错误。一个好的测试用例在于它能发现至今尚未发现的错误。一个成功的测试则是发现了至今未发现的错误。开始我们认为做测试无非是为了证明我们编的程序是无错误的，那是大错特错了。因为bug会因时间不同，条件不同而出现。永远无法证明我们的程序是绝对正确的。 为反馈信息做准备为开发者或软件项目经理提供反馈信息，以及为风险评估所准备的信息 软件测试的原则 所有的测试都应追溯到用户需求。因为软件的目的是使用户完成预定的任务，满足其 需求，而软件测试揭示软件的缺陷和错误，一旦修正这些错误就能更好地满足用户需求。 应尽早地和不断地进行软件测试。由于软件的复杂性和抽象性，在软件生命周期各阶 段都可能产生错误，所以不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把 它贯穿到软件开发的各个阶段去。在需求分析和设计阶段就应开始进行测试工作，编写相 应的测试计划及测试设计文档，同时坚持在开发各阶段进行技术评审和验证，这样才能尽 早发现和预防错误，杜绝某些缺陷和错误，提高软件质量，测试工作进行得越早，越有利 于提高软件的质量，这是预防性测试的基本原则。 在有限的时间和资源下进行完全测试，找出软件所有的错误和缺陷是不可能的，软件 测试不能无限进行下去，应适时终止。因为，测试输入量大、输出结果多、路径组合太多，用有限的资源来达到完全测试是不现实的。
测试只能证明软件存在错误而不能证明软件没有错误。测试是无法显示潜在的错误和缺陷，继续进一步错误可能还会找到其它错误和缺陷。 充分关注测试中的集群现象。在测试的程序段中，若发现的错误数目多，则残存在其中的错误也越多，因此应当花较多的时间和代价测试那些具有更多错误数目的程序模块。 程序员应避免检查自己的程序。考虑到人们的心理因素，自己揭露自己程序中的错误是件不愉快的事，自己不愿意否认自己的工作;另一方面，由于思维定势，自己难以发现自己的错误。因此，测试一般由独立的测试部门或第三方机构进行。 尽量避免测试的随意性。软件测试是有组织、有计划、有步骤的活动，要严格按照测试计划进行，要避免测试的随意性。 软件测试对象 程序开发过程中的各个文档、源程序、目标程序及数据 软件测试的模型 V模型 从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。 V模型问题： "测试是开发之后的一个阶段，"测试的对象就是程序本身。 "实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。 "整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度 W模型相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。 W模型也有局限性。W模型和V
受控状态（章）：受控号： ******************有限公司 软件测试规程 文件编号: &&&&&&&/TE82402-2013 文件版本: ******************有限公司对本文件资料享受着作权及其他专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
修订履历
1. 目的 软件测试是软件工程的重要组成部分，测试工作的质量直接影响软件产品的生命力。测试工作的标准化是软件质量保证重要而且必须的环节。制定本标准的目的在于使测试流程更标准，测试过程更规范。从而使整个软件产生纳入更系统化、更专业化的轨道。 2. 范围 本标准适用于软件测试流程的管理和测试的具体操作过程。本标准的使用者可以是企业内部的测试人员和开发人员。 3. 职责 测试负责人：根据测试任务优先级制定测试计划。根据测试计划负责监控软件测试过程，及时调整测试策略和方法，进行测试任务安排。 测试人员：配置测试环境及准备测试数据，参与《测试分析报告》的编写，评价软件功能的性能及正确性，确保所负责模块的测试质量。 4. 术语定义 软件测试 软件测试是指通过一定的制度、方法、技术、流程和工具对软件测试对象进
行检查、验证和分析，根本目的是验证和确认软件测试对象与需求的一致性，最终保证软件系统的质量。 测试执行 在测试环境中按照测试用例完成测试，主要工作包括执行测试用 例；记录、分析、解决测试过程中发现的错误，并执行回归测试；评估测试结果，提交测试总结报告。 测试环境 是指满足软件系统测试要求的硬件、网络和系统软件环境，包括主 机、存储、网络、外围设备、操作系统软件、数据库、中间件、系统配置参数和测试用业务数据等。 5. 测试规程 软件测试流程 软件测试流程图 软件测试流程细则 需求阶段： 测试人员了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等。 测试人员了解项目需求变更。 测试人员会同项目主管根据软件需求制定并确认《测试计划》（附录五）。 设计编码阶段： 各项目部对完成的功能模块进行单元测试，测试人员参与单元测试过程；单元测试完成，产生单元测试报告。 所有单元测试及相应的修改完成后，各项目部组织进行集成测试，测试人员参与集成测试过程；集成测试完成后，产生集成测试报告。 测试阶段： 各项目部完成集成测试后，提交测试所要求的待测软件及各种文档、手册。 测试组安排和协调测试设备、环境等准备工作。 测试组按测试计划、测试大纲的要求对待测软件进行有效性测试、集成测试。 填写《程序错误报告》。
软件测试规范 1目的 确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。 2适用范围 适用于项目开发过程中的系统测试 3角色职责 项目测试负责人根据《用户需求说明书》、《软件设计方案》、《硬件设计方案》组织编制《测试计划》、《测试方案》，指导和督促 测试人员完成各阶段的测试工作。 项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。 测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 项目负责人组织测试环境的建立。 项目经理审核负责控制整个项目的时间和质量。 研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据 用户需求说明书和设计方案是测试的依据。因此设计人员应向测试人员提供《系统需求规格说明书》、《详细设计》、《概要设计》等有关资料。同时测试人员需要评审设计方案的合理性和可测试性。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》 在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容：
测试目的； 所需人员及相应培训要求； 测试环境、工具和测试软件； 测试用例、测试数据和预期的结果。 4.3 系统测试 4.3.1系统测试。 4.3.1.1 进入系统测试一般应具备以下条件： a)被测软件完成开发且已经置于软件配置管理之下： b)相关的自测报告、软作变更报告等齐全 c)具有相关测试的全部文档及资源，如需求说明书、软件设计方案、硬件设计方案、使用手册 d)具备相关测试的设施环境。 4.3.1.2 测试过程 1、系统测试由测试负责人组织策划（编写测试计划、测试方案、测试用例）并实施， 2、测试人员根据测试计划、测试方案、测试用例执行测试过程，形成测试记录、问题报告及维护记录。 3、系统测试一般进行如下几种情况的测试： 正常情况 非正常情况 破坏性测试 边界情况 非法情况 强度测试 性能测试 兼容性测试 用户友好性测试 界面设计规范测试： 光标的初始位置
软件测试分类 1、黑盒测试：指把被测软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。 2、白盒测试：指把盒打开，去研究里面的源代码和程序结构。 3、静态测试:指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在错误的过程。 对于代码测试，主要测试代码是否符合相应的标准和规范。 对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。 对于文档测试，主要测试用户手册和需求说明是否真正符合用户的实际需求。 4、动态测试：指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。 5、单元测试：指对软件中最小可测试单元进行检查和验证。例如：C语言中，单元一般指1个函数；在Java里，单元一般指1个类;在图形化的软件中，单元也可以指1个窗口，1个菜单等。总结起来，单元就是人为规定的最小的被测功能模块。 单元测试的通过标准是什么： (1)程序通过所有单元测试的用例 (2)语句的覆盖率达到100% (3)分支覆盖率达到85% 如何进行单元测试: 单元测试主要用白盒测试方法，一般我们先静态地检查代码是否符合规范，然后动态地运行代码，检查其它实际运行结果。当然检查程序的运行结果是否正确是一个最基本的要求，我们还要检查很多项，比如程序的非法数据的容错处理，程序的边界值处理等。 桩模块：是指模拟被测模块所调用的模块。 驱动模块：是指模拟被测模块的上级模块。 桩模和驱动模块例子： include
软件测试流程及规范 (2) 一、目标 (2) 二、测试流程说明 (2) 三、需求分析 (2) 四、需求评审（需求澄清） (3) 五、开发人员编写排期 (3) 六、测试计划排期 (3) 七、编写测试用例 (3) 八、用例评审 (3) 九、提交基线 (3) 十、Showcase (3) 十一、转测 (4) 十二、测试通过 (4) 十三、测试评估 (4) 十四、测试总结文档报告输出 (4) 十五、测试报告 (5) 十六、备注 (5)
软件测试流程及规范 一、目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。最终目标是实现软件测试规范化、标准化。 二、测试流程说明 三、需求分析
需求分析由SA制定，要求细化每一个功能的细节，每一个按钮的位置以及边界范围，对于稍大或稍复杂需求要求建模。 （1）测试需求是制订测试计划的基本依据，只有确定了的测试需求才能够为测试计划提供客观依据; （2）测试需求是设计测试用例的指导，只有确定了要测什么、需要测哪些方面，才能有针对性的设计测试用例; （3）测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖. 四、需求评审（需求澄清） 参与人员，包括：SE、OM、PC、AD、TE以及QA。 SE提出需求。 开发人员（OM、PC、AD）考虑功能实现的方案与可行性。 TE主要是对需求的理解提出疑问，以便才能根据需求写用例。 QA人员是最终对软件质量进行验证的人，所以也需要了解需求 五、开发人员编写排期 开发人员需要根据需求功能点进行排期，然后将开发计划发送给参与项目的所有人员 六、测试计划排期 测试人员根据开发计划，安排测试的具体测试时间（包括SIT转测），然后将测试计划发送给参与项目的所有人员。 七、编写测试用例 根据详细的需求文档，开始进行用例的编写。 八、用例评审 用例评审前，先将用例发送给相关人员，以便他们事先了解用例将对哪些功能进行验证以及验证的细节。 在用例评审中，参与人员需要对用例中与实际功能不符合的用例或者格式不规范规用例提出修改建议。 九、提交基线 开发人员完成所有功能后，会对自己的功能进行一个自测。自测完成后提交测试进行基线。 十、Showcase 开发人员自测完成后将实现的功能演示给测试人员。 测试人员可以提出疑问由开发人员解答或者后续提单解决。
软件测试作业 1、什么是动态测试？动态测试的分类有哪些？ 动态测试是指通过运行被测程序来检查运行结果与预期结果的差异，并分析运行效率和健壮性等指标。这种方法由三部分构成：构造测试实例、执行程序、分析程序的输出结果。动态测试和静态测试最大的区别就是静态测试不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。动态测试是必须要运行程序代码来检测其中的各种错误。 动态测试的分类： 从是否关心软件内部结构和具体实现角度划分，可分为白盒测试、黑盒测试和灰盒测试。从软件开发的角度软件测试可分为：单元测试、集成测试、确认测试、系统测试、验收测试及回归测试。 从软件执行时是否需要人工干预的角度划分，软件测试可分为人工测试和自动化测试。从测试实施组织角度划分，软件测试可分为开发方测试、用户测试、第三方测试。 2、什么是白盒测试？白盒测试采用哪些方法？ 白盒测试是一种典型的测试方法，是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法，因此又称为结构测试或逻辑驱动测试。它是基于一个应用代码的内部逻辑知识，测试覆盖全部代码、分支、路径和条件。它利用查看代码功能和实现方式得到的信息来确认哪些需要测试、哪些不需要测试、如何开展测试。白盒测试需要具有一定代码阅读能力，并且白盒测试需要做的工作与开发具有很大的联系。白盒测试关心内部机构，就好像一个透明的盒子一样要看到里面的结构。白盒测试和调试是不同的概念，他们本质的目标并不相同。白盒测试包括处理软件缺陷和查看代码的过程，但白盒测试只是要发现其中的错误，并不太关心具体的处理过程。 白盒测试采用哪些方法：白盒测试一般分为静态测试和动态测试，静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估，采用的是代码走查、代码审查、程序结构分析、控制流分析、数据流测试及信息流分析。 动态测试需要在host环境或target环境中实际运行软件，并使用设计测试用例去探测软件缺陷。所采用的测试方法是逻辑覆盖（包括语句覆盖、分支覆盖、条件覆盖、判定/条件覆盖、组合条件覆盖、路径覆盖） 语句覆盖：保证每条语句都执行一次。优点：检查所有语句、结构简单的代码的测试效果较好容易实现自动测试代码覆盖率高，如果是程序块覆盖，则不必考虑程序块中的源代码。缺点是不能检查出条件语句错误，逻辑运算错误，循环语句错误。 分支覆盖：保证程序中每一个分支至少通过一次，即每一条分支语句的“真” 和假都至少执行一次。分支覆盖比语句覆盖的查错能力强一些，但是不能查出条件语句错误，不能查出逻辑运算错误，不能查出循环次数错误，不能查出循环条件错误。 条件覆盖：即是每个条件都取一次来执行。能够检查所有条件错误，不能实现对每个分支的检查，用例数增加。
【下载本文档，可以自由复制内容或自由编辑修改内容，更多精彩文章，期待你的好评和关注，我将一如既往为您服务】 软件测试基本概念 1、软件=程序+文档，软件测试=程序测试+文档测试。 “程序”是指能够实现某种功能的指令的集合，“文档”是指软件在开发、使用和维护过程中产生的图文集合。； 2、软件的分类 按功能分：系统软件、应用软件 按技术架构分：单机版软件、C/S结构软件（C是指客户端，S指服务器端）、B/S 结构软件（B是指浏览器） 按照用户划分：产品软件、项目软件 按开发规模划分：小型、中型、大型 3、BUG的定义：软件的BUG指的是软件中（包括程序和文档）不符合用户需求的问题。常见的软件BUG分三种类型：完全没有实现的功能；基本实现了用户需求的功能；实现了用户不需要的功能。 4、测试环境=软件+网络+硬件。搭建环境：真实、干净、无毒、独立 5、软件环境的分类：软件开发环境软件生产运行环境 6、测试用例：指在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和与其结果！测试用例=输入+输出+测试环境。测试用例有两个模板，word 和excel，前者适合性能测试，后者适合功能测试。 软件测试分类
1、黑盒测试：指的是把被测的软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果 白盒测试：指的是把盒子盖打开，去研究里面的源代码和程序结构。 2、静态测试：是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。 动态测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。 注：同一个测试，既有可能属于黑盒测试，也有可能属于动态测试；既有可能属于静态测试，也有可能属于白盒测试。他们之间也有可能交叉。 3、单元测试：编译运行程序——静态测试——动态测试 集成测试：是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分。 4、系统测试：指的是将整个软件系统看作1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。 5、验收测试：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员 共同参与的测试，它也是软件正式交给用户使用的最后一道工序. 验收测试又分为α测试和β测试，其实α测试指的是由用户、测试人员、开发人员等共同参与的内部测试，而β测试指的是内侧后的公测，即完全交给最终用户测试。 功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。功能测试又可以细分为很多种：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等。
软件测试流程规范整体的流程图 1.详细的流程执行 1.1 计划与设计阶段 整体流程图
1.1.1 立项会议 由高层主管立项会议，会议主要对项目的可行性进行分析，并且确定项目经理及项目测试组长。 1.1.2 需求评审 注：1．需求定义基本完成，此时应在评审会议召开之前发给测试团队，预留时间给测试相关人员熟悉、理解。 2．测试部参与人员由测试部经理指定，主要由测试组长、测试设计等人员组成（还应包括配置管理人员、质量保证人员）。
1.1.3 测试工作启动 注：在正式测试任务下达前，开发团队应在项目（产品）开发计划完成后及时向测试团队下达预通知，告之较为确切的测试日期，提供当前最新的相关资料。部门经理和测试组长组建测试小组，并视具体情况决定是否需要调整人力、时间安排、测试环境等其它资源。测试小组成员可预先熟悉必要的项目（产品）资料。 1.1.4 测试设计阶段 1.1.4.1 设计测试计划 注：针对需求分析文档和项目开发计划文档测试完成后，测试组需要编写测试计划文档、制定测试测略及预估测试过程中的风险，并设计出合理的规避风险的策略，为后续的测试工作提供直接的指导。
1.1.4.2 设计测试用例 注：在需求分析文档确立基线以后，测试组需要针对项目的测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。
1.1.4. 2.1设计测试用例的常用方法 a．等价划分法 有效等价类:是指对于程序的规格说明来说是合理的有意义的输入数据构成的集合利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能 无效等价类:与有效等价类的定义恰巧相反 b．边界值法： 边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种 情况下，其测试用例来自等价类的边界。 通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。 相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满等情况下。 边界值分析的基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值处取输入变量值，记为：min、min+、nom、 max-、max考虑到健壮性测试，还可以加一个略大于最大值max+， 以及一个略小于最小值min-的值。 举例说明：例如要求0 < X<5,在编写用例时需考虑到以下几种 情况： ?x=0的情况 ?x=5的情况 ?x=-1的情况 ?输入一个X大于5的值，例如输入X=6 c．错误推断法 基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性 的设计测试用例的方法。 思路：分析程序中最易出错的场景和情况，在此基础上有针对性的设 计测试用例，需要完成的前提条件如下： ●深度熟悉被测系统的业务、需求。 ●对被测系统或类似系统之前的缺陷分布情况进行过系统的分析。 包括功能缺陷，数据缺陷，接口缺陷和界面缺陷等等。 举例说明： 聊天窗口功能 ?输入特殊字符（全角，半角）后，窗口是否能够正常显示 ?输入空格，是否能够过滤，是否会算入长度计算 ?输入html字符 ?输入脚本语言函数 ?在需要密码验证，或者需要二次输入确认的地方，通过复制粘贴第一次的输入内容是否能够通过