软件测试PPT 第一章 软件测试导论

软件测试第一章软件测试导论第二章软件测试技术第三章软件测试用例的设计方法第四章软件测试的过程方法1.1软件测试的基本概念1.2

软件测试的依据与人员组织1.3

软件测试的生命周期与模型1.4软件测试计划及其相关文档第一章软件测试导论1.1.1

软件测试的定义1.1.2软件测试的必要性1.1.3软件缺陷1.1.4软件测试的原则1.1.5软件测试的误区1.1.6软件测试与软件质量保证的关系1.1.7

软件测试技术的发展1.1软件测试的基本概念

软件质量是软件的生命。为了保证软件的质量，人们在长期的软件开发过程中积累了许多经验，形成了许多有效的方法（技术的和管理的）。但是借助这些方法，只能减少软件中的错误和不足，但不能完全避免错误。技术：软件开发技术，软件测试属于技术管理：软件项目管理软件产品特点:无形性、逻辑性、复杂性，一般产品质量通过参数确定，软件产品？

1.1软件测试的基本概念1.什么是软件测试软件测试就是在软件投入运行前，对软件需求分析、架构设计和编码实现的最终复审，是软件质量保证的关键。对软件测试的定义很多，但一般可描述如下：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一组测试用例，利用测试用例去运行程序，以发现程序错误的过程。简言之，软件测试是为了发现错误而执行程序的过程。1.1.1软件测试的定义1.什么是软件测试目前，根据侧重点的不同，主要有以下三种观点：1983年IEEE将软件测试定义为：“使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。明确地提出了软件测试是以检验软件是否满足需求为目的。Myers认为：“是为了发现错误而执行程序的过程”。明确提出软件测试是以对软件“寻找错误”为目的。

多数软件开发商认为：软件测试是一种重要的软件质量保证活动，其动机是通过一些经济、高效的方法，捕捉软件中的错误，保证软件内在质量。明确提出软件测试是以保证软件内在质量。1.1.1软件测试的定义2.软件测试与软件调试的区别概念不同：软件测试是一个在可控环境中执行软件的过程，以验证是否按预期运行。软件调试是一个分析和定位软件BUG的过程。作用不同：调试是测试的一个基础，调试支持测试，但不能完全替代测试。目的不同：调试使软件能正确运行，而测试是发现软件中的错误。对象不同：调试的对象是代码，测试的对象是开发过程中的所有的产品。1.1.1软件测试的定义3.软件测试的目的

基于不同的立场，存在两种完全不同的测试目的。从用户的角度，希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否接受该产品。从开发者的角度，希望通过软件测试表明软件产品中不存在错误，验证软件已正确地实现了用户的要求，确立对软件质量的信心。综合明来，测试的目的是通过对软件错误的原因和分布进行归纳，来发现并排除软件产品的缺陷，对在需求和设计过程中存在的问题查缺补漏，确保软件产品的质量。

1.1.1软件测试的定义4.软件测试的基本职责软件测试有两个基本职责：一是验证：前后阶段的需求是否一致。即正向思维，所有特性功能通过，达到预期。二是确认：满足最终需求。即反向思维，存在错误而尽力发现错误，直到找不到错误1.1.1软件测试的定义1.为什么要进行软件测试软件由人开发，人会犯错误——〉软件（程序+数据+文档）都有缺陷。无法避免人犯错，但是可以通过努力寻找隐藏在软件中的缺陷。多、快、好、省提高软件质量。1.1.2软件测试的必要性用户所说的需求分析人员理解的《系统需求规格说明书》开发人员理解的实际软件人不是完美的，在设计和实现时会出错

信息传递的误差1.1.2软件测试的必要性1.为什么要进行软件测试工程硕士12没有软件工程和项目管理概念下，软件开发现象1.1.2软件测试的必要性2.软件缺陷案例软件缺陷将造成灾难性危害或对用户产生巨大的影响。2003年，软件问题造成美国东部及加拿大停电，导致5000万人受影响，3人丧生，60亿美元的损失。2000年，美国海军飞机控制软件问题导致飞机坠落，4人丧生。1997年韩国空难，导致225人丧生（雷达控制软件问题）2004年，北美银行已新安装的软件的缺陷，使数以百万计的客户受影响，缺陷修复花费两个星期，造成亿元损失。2003年，美国专门为学生贷款的公司由于软件出错，错误计算80万学生的贷款利率，导致800万元的损失……1.1.2软件测试的必要性3.软件测试是软件开发的重要环节4.软件测试是保证软件质量的主要手段。

1.1.2软件测试的必要性1.1.3

软件缺陷1．软件缺陷的定义

软件缺陷（bug）的定义很多，综合说来是程序中存在破坏软件正常运行的问题、错误或瑕疵，导致软件产品在某种程度上不能满足用户的需要。

软件缺陷是指软件产品中所存在的导致不能完全满足用户需求的错误。

按IEEE729标准，软件缺陷的含义有2个方面：软件产品的内部：软件缺陷是软件产品开发或维护过程中所存在的错误、瑕疵等。软件产品的外部：软件缺陷是软件所需要实现的某种功能的失效或违背。2.软件缺陷外部表现的判断规则

软件未实现产品说明书要求的功能。软件出现产品说明书指明不会出现的错误。软件实现超出产品说明书提到的功能。软件未实现产品说明书虽未明确指出但应该实现的功能。软件难以理解，不易使用，运行缓慢或用户认为不好。第５条规则是全面的。如果软件测试员发现某些地方不对劲，无论什么原因，都可认为是缺陷。1.1.3软件缺陷

以计算器为例说明判断规则。若产品说明书声称能够准确无误地进行加、减、乘、除运算，当你按下（＋）键，结果什么反应也没有；根据第１条规则，是一个缺陷。假如得到错误答案；根据第１条规则，同样是一个缺陷。若产品说明书声称永远不会崩溃、锁死或者停止反应，当你任意敲键盘，计算器停止接受输入。根据第２条规则，是一个缺陷。若在测试计算器过程中，发现除了加、减、乘、除之外它还可以求平方根，而产品说明书中没提到该功能。根据第３条规则，是一个缺陷。若在测试计算器过程中，发现电池电量很少时，会导致计算不正确，但产品说明书未指出该问题。根据第４条规则，是一个缺陷。若“＝”键布置的位置使其极不好按，或在明亮光下显示屏难以看清。根据第５条规则，是一个缺陷。1.1.3软件缺陷3．软件缺陷的种类从功能表现形式分，软件缺陷有三种类型：完全没有实现的功能。例如用户要求实现A、B、C三个功能，但是软件只实现了A、B两个功能。基本实现了用户需求的功能，运行时出现功能或性能上的问题。例如满足软件要求，但运行经常报错、死机，响应时间要求为5秒，实际为10秒。实现了用户不需要的功能。例如用户要求实现A、B、C三个功能，实际实现了A、B、C、D四个功能。1.1.3软件缺陷还表现在其他方面。如：特性没有实现或部分实现；设计不合理；实际结果和预期结果不一致；运行出错(运行中断、系统崩溃、界面混乱)；数据结果不正确、精度不够；用户不能接受的其他问题(存取时间过长、界面不美观)。1.1.3软件缺陷4．软件缺陷的级别软件测试员发现的大多数缺陷是难以觉察的简单错误，不明显，也不严重；且有些是真正的错误，有些不是。一般来说，问题越严重的错误，优先级越高，越应得到及时纠正。软件公司对缺陷后果的严重程度的定义不尽相同，但一般可以分为4种级别：1.1.3软件缺陷4．软件缺陷的级别

致命的：指造成系统或应用程序崩溃、死机、悬挂，或造成数据丢失、主要功能完全失效等。严重的：指功能或特性没有实现，主要功能部分丧失，次要功能完全丧失，或致命的错误声明。一般的：指虽然不影响系统的基本使用，但没有很好实现功能，没有达到预期效果。如次要功能丧失，提示信息不太准确，用户界面差，操作时间长等。微小的：指对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等。

除了这4种之外，有时需要“建议”级别来处理测试人员所提出的建议或质疑，如建议程序做适当的修改，来改善程序运行状态，或对设计不合理、不明白的地方提出质疑。

1.1.3软件缺陷轻微：词语拼写错误中等：误导或重复信息使人不悦：被截断的信息，0.00￥帐单影响使用：有些交易没有处理严重： 丢失交易非常严重：不正确的交易处理极为严重：经常出现“非常严重”的错误无法忍受：数据库破坏灾难性：系统停机容易传染：扩展到其他系统的系统停机缺陷类型具体可参见软件异常IEEE标准分类（IEEE，1993）1.1.3软件缺陷5.软件缺陷的状态

为便于跟踪和管理软件的缺陷，可以定义不同的状态。软件缺陷的状态一般有3种：激活状态：问题还没有解决，测试人员新报的bug，或验证后bug仍然存在。已修正状态：开发人员针对所存在的缺陷，修改程序，认为问题已解决，或通过单元测试。关闭或非激活状态：测试人员验证已经修正的bug后，确认bug不存在后的状态。1.1.3软件缺陷6．软件缺陷产生的原由

造成软件缺陷的原由归纳起来有3个方面：技术问题算法错误。语法错误。计算方法与精度要求不匹配或取值精度不够。结构不合理。接口参数不匹配。

1.1.3软件缺陷

团队工作问题

与用户的沟通不够，对需求不是十分清楚。不同阶段的开发人员对同一问题理解不一致。设计或编程上的假定或依赖性沟通不充分。软件本身问题文档错误、内容不正确或拼写错误。数据考虑不周全，引起强度或负载不合理。对边界考虑不周全，如漏掉几个边界条件。实时软件的同步不精确，引起时间不协调、不一致没有考虑系统崩溃后在安全性、可靠性的隐患。硬件或系统软件上存在的错误。软件开发标准或过程上的错误。1.1.3软件缺陷7．软件缺陷的构成从按软件开发过程来看，不同阶段的工作，导致软件缺陷的差异性很大，如图所示。需求分析是软件缺陷出现最多的阶段。图1-1软件缺陷构成示意图1.1.3软件缺陷

缺陷放大模型

因此，从需求开始，则制定测试计划，坚持软件开发的阶段性技术评审，才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝隐患，提高软件质量。1.尽早不断地进行软件测试

IBM的研究结果表明，缺陷存在放大趋势。从图可见，问题发现越早，解决问题的代价就越小，这是软件开发过程中的黄金法则。1.1.4软件测试的原则2.不可能完全测试对程序完全测试则意味着在测试结束之后，不会再发现软件错误。但这是不可能的，主要原因有以下几点：不可能对程序所有可能输入的响应进行测试。不可能对程序所有可能执行的路径进行测试。无法找出所有的设计错误。不能采用逻辑来证明程序的正确性。1.1.4软件测试的原则如果测试一个计算器程序的功能，需要进行多少次输入？不计其数！整型:从1+1到999999999999999999999999999999+999999999999999999999999999999小数:1.0+0.1,1.0+0.2…等等键盘上的任何一种组合乘法和除法运算重复上面的操作1.1.4软件测试的原则

由小到大是指软件测试的粒度。即多个单元组合过渡到集成测试，集成测试过渡到系统测试。虚线是测试阶段的发布基线，随着测试的逐步深入，范围的逐步扩大，测试时间、可用资源也随之增大。3.由小到大增量测试测试过程关系图1.1.4软件测试的原则4.避免程序员测试自己的程序

程序员不会轻易承认自己的程序有错误。程序员的测试思路有局限性，测试时容易受到编程思路的影响。

多数程序员没有严格正规的职业训练，缺乏专业测试人员的意识。

程序员没有养成错误跟踪和回归测试的习惯。由别人测试，会更客观，更有效。

1.1.4软件测试的原则5.设计周密的测试用例。测试用例是测试工作的核心，只有设计周密细致的测试用例，才能保证测试工作的质量。

1.1.4软件测试的原则6.注意错误集中的现象对错误群集的程序段进行重点测试，以提高测试投资的效益。软件缺陷的“扎堆”现象的常见形式：对话框的某个控件功能不起作用，其他控件的功能也可能不起作用。某个文本框不能正确显示双字节字符，其他文本框也可能不支持双字节字符。安装文件某个对话框的“上一步”或“下一步”按钮被截断，在其他对话框中这两个按钮也可能被截断。1.1.4软件测试的原则

7.BUG有效性确认有时测试人员提交的BUG并不是真正的BUG，无效BUG的来源如图所示。一般由A测试人员发现的BUG，一定要由B测试人员进行确认，如果发现严重的BUG可以召开评审会进行讨论和分析。1.1.4软件测试的原则无效BUG来源构成图1.1.4软件测试的原则

8.合理安排测试计划

合理的测试计划有助于测试工作顺利有序地进行。测试计划应结合多种针对性强的测试方法，列出所有可使用资源，建立一个正确的测试目标。要有明确规定，不要随意解释。本着严谨、准确的原则，周到细致地做好测试前期的准备工作，避免测试的随意性。尤其是要尽量科学合理地安排测试时间。严格执行测试计划，排除测试的随意性。妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。，1.1.4软件测试的原则错误依赖关系9.回归测试

错误之间存在简单的依赖或复杂的多重依赖关系。（a）图中：A错误依赖于B错误的关闭而关闭；（b）图中：A错误依赖于B错误和C错误的同时关闭而关闭；（c）图是（a）和（b）的复合方式。程序中的错误存在着一对多、多对多的复杂关系而变得难以处理，且有些依赖关系处于隐性状态。1.1.4软件测试的原则

10.测试结果的统计和分析

只有对测试输出信息进行深入地统计、分析和比较，才能正确的鉴别测试输出的数据，给出清晰的错误分析报告。当输出的信息很庞大时，可以借助专业的测试工具。1.1.4软件测试的原则

11.及时更新测试

导致测试失败的原因有很多，一般有如下几点：

1、测试团队管理者失职；

2、测试团队中沟通不好；

3、测试团队和项目团队沟通不良；

4、测试过程中，执行角色无准确定义；

5、测试团队缺乏良好的培训。

1.1.4软件测试的原则

误区1调试和测试是一样的误区2软件测试在软件开发过程中并不重要误区3在软件开发结束之后进行测试误区4过分依赖Beta测试误区5过分依赖自动化测试误区6测试是可穷尽的误区7测试是证明软件的正确性误区8可以忽略测试的设计

1.1.5软件测试的误区41SQA(SoftwareQualityAssurance)：为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。面向管理层，提供正确的信息，工作的对象是产品；促进和协调过程改进；预防问题。软件测试：使用人工或者自动手段来运行或测定某个系统的过程，检验其是否满足规定的需求或判定预期结果与实际结果之间的差别。工作的对象是开发的软件，寻找缺陷；强调书写正式的测试文档，实现可重复的结构化软件测试；发现问题。1.1.6软件测试与质量保证的关系

软件=程序+数据+文档+服务软件质量：系统、组件或过程满足明确的需求。----IEEEStandardGlossaryofSoftwareEngineeringTechnology软件测试：挑毛病，发现Bug（缺陷）。软件测试是软件质量保证的手段。1.1.6软件测试与质量保证的关系1．软件测试技术的发展历史

起步阶段（1957～1971）----验证为导向在软件发展初期，就实施软件测试，但不是真正意义的软件测试，更多是调试。直到1957年，随着高级语言诞生，程序复杂性远超过以前，软件测试才与软件调试区别开来。但测试没有计划和方法，测试用例的设计和选取凭经验随机的，测试目的是证明软件可以正常运行。另外，由于软件仍处于次要位置，测试理论和方法的发展比较缓慢，软件正确性的把握仍然主要依赖于编程人员的技术水平。1.1.7软件测试技术的发展1．软件测试技术的发展历史

初级阶段（1972～1982）----确认为导向

软件技术的成熟和完善，软件测试规模和复杂度加大，软件测试逐渐形成一套体系并走向规范。随着计算机处理速度的提高、存储容量的增加，软件变得越来越重要。随着软件开发技术的成熟和完善，软件规模越来越大，复杂度增加，软件的可靠性面临着前所未有的危机，主动寻找缺陷给软件测试带来新的挑战，也造就了一批批出色的测试人才。1.1.7软件测试技术的发展1．软件测试技术的发展历史

发展阶段（1983～198？）----质量为导向在软件产业化发展的趋势下，人们对软件质量、成本和进度的要求越来越高，质量控制已不是传统的软件测试（执行测试）----基于代码运行且是软件开发的后期进行的。大量研究表明，设计阶段引入的错误占所有错误数量的50%～65%，规范软件开发过程是质量控制的基础。在整个软件开发过程中，测试不再仅是基于程序代码的开发活动，而是基于整个软件生命周期的质量控制活动，贯穿于软件开发全过程。1.1.7软件测试技术的发展1．软件测试技术的发展历史

成熟阶段（198？～现在）----预防为导向

1.1.7软件测试技术的发展2．软件测试的现状国外现状软件测试在软件公司中占有重要地位软件测试理论研究蓬勃发展，每年举办各种各样的测试技术年会，发表了大量的软件测试研究论文，引领软件测试理论研究的国际潮流软件测试市场繁荣国内现状我国软件测试起步于“六五”期间(90)，目前国家863、973以及大力支持软件测试的研究1990年，成立中国软件评测中心，测试服务开始发展软件测试正在逐步成为一个新兴的产业国家确定“软件评测师”的职业资格认证；“以测代评”正成为我国科技项目择优支持的一项重要举措；第三方测试机构繁荣发展1.1.7软件测试技术的发展与一些发达国家相比，国内测试工作还存在一定的差距。在我国，软件测试可能算不上一个真正的产业，软件开发企业对软件测试认识淡薄，软件测试人员与软件开发人员比例失调，而在发达国家和地区软件测试已经成了一个产业。但在软件测试实现方面并不比国外差，国际上优秀的测试工具，我们基本都有，这些工具所体现的思想我们也有深刻的理解，很多大型系统在国内都得到了很好的测试。1.1.7软件测试技术的发展1.2软件测试的依据与人员组织1.2.1软件测试的依据1.2.2软件测试人员职责分配1.2.3软件测试人员必需的素质1.2.4软件测试的经验501.软件质量标准ISO9000-3软件质量标准：考虑软件行业的特殊性制定，是ISO质量管理和质量保证标准在软件开发、供应和维护中的使用指南。核心内容包括：合同评审需求规格说明开发计划质量计划设计和实现测试和确认验收复制、交付和安装维护1.2.1软件测试的依据512.软件测试规范软件测试规范就是对软件测试的流程过程化并对每一个过程元素进行明确的界定，形成完整的规范体系，包括：规范目的、范围、文档结构、词汇表、参考信息、可追溯性、方针、过程/规范、指南、模板、检查表、培训、工具、参考资料等等。1.2.1软件测试的依据523.软件测试国家标准GB/T9386-1988《计算机软件测试文件编制规范》GB/T15532-1995《计算机软件单元测试规范》GB/T17544-1998《信息技术软件包质量要求和测试》GB/T16260.1-2003《软件工程产品质量》第1部分质量模型GB/T16260.2-200X《软件工程产品质量》第2部分外部度量GB/T16260.3-200X《软件工程产品质量》第3部分内部度量GB/T16260.4-200X《软件工程产品质量》第4部分使用质量度量GB/T18905.1-2002《软件工程产品质量》第1部分概述GB/T18905.2-2002《软件工程产品质量》第2部分策划和管理GB/T18905.3-2002《软件工程产品质量》第3部分开发者用的过程GB/T18905.4-2002《软件工程产品质量》第4部分需求方用的过程GB/T18905.5-2002《软件工程产品质量》第5部分评价者用的过程GB/T18905.6-2002《软件工程产品质量》第6部分评价模块文档编制1.2.1软件测试的依据

1.软件测试的组织结构和人员结构软件测试在组织结构上一般分为功能测试组、性能测试组和文档工作组。软件测试在人员结构上一般需要有测试文档审核师、测试工程师和操作人员。1.2.2软件测试人员的职责分配工程硕士54

2.测试职责分配系统分析设计人员软件开发人员软件测试人员配置管理员质量保证人员对测试过程进行审计对测试文档及测试代码等进行配置管理提出测试需求；进行测试需求跟踪；进行软件系统可测性分析；确定测试的对象、范围和方法提供软件开发计划SDP，参与测试计划的制定和评审，提供软件功能需求规格、需求分析、测试建议、响应测试需求、参与测试方案的评审；跟踪解决缺陷问题报告单，参与测试报告的评审。制定测试计划、方案并组织评审，实现测试用例，代码和工具等设计、编写测试规程；执行测试、反馈并跟踪缺陷问题报告单，完成测试报告并组织评审，输出测试案例、总结等经验文档1.软件测试人员必需的基本素质三心二意一能力细心耐心责任心服务意识团队意识沟通能力1.2.3软件测试人员必需的素质

2.软件测试人员必需的知识素养

深入理解软件测试理论掌握各类软件测试技术接受专门的测试训练对软件缺陷警觉性高对缺陷出现的各种情况较熟悉掌握多种计算机语言掌握一般的软硬件、数据库及网络知识对所要测试的软件的功能、结构、要求有深入的认识。1.2.3软件测试人员必需的素质

57（1）心理素质最重要开发人员我不会犯错---任何人都可能犯错这种错误不能算作错误---质量是由用户来评价的发现我的错误是对我工作的否定---是对我的工作的帮助测试人员责任心不够，反正测试是不可能发现所有错误的职业教育+激励措施没有创造性、枯燥总结经验，培养敏锐度，提升个人价值和权威技术比开发人员差，自信心不足代表用户，决定成功的是用户满意1.2.4软件测试的经验58（2）测试前必须明确预期的输出结果否则实际的输出结果很可能成为检验的标准，测试失去意义（3）必须检查每一个实际输出结果很可笑，但是却是事实：不认真检查输出结果（4）一段程序中存在错误的概率与这段程序中已经发现的错误数成正比编码规范、需求理解、技术能力、内部耦合性都会导致这种“虫子窝“现象1.2.4软件测试的经验工程硕士59（5）可能的情况下，避免测试自己的软件发现不了思路错误发现不了环境错误心理因素导致测试可能不够彻底和全面（6）依照用户的要求、配置环境和使用习惯进行测试并评价结果（7）测试设计决定了测试的有效性和效率，测试工具只能提高测试效率1.2.4软件测试的经验工程硕士60（8）注意保留测试设计，并注意测试设计的可重用性和说明文档（9）测试活动要有组织、有计划、有选择穷举测试是不可能的不充分的测试是不负责任，过度的测试是浪费资源有计划的活动能提高效率（10）不要放弃随机测试的方法测试的不成熟性和艺术性1.2.4软件测试的经验

1.软件测试人员的工作内容

根据软件需求规格说明书、设计说明书、代码等软件产物选取恰当的输入组合运行被测试对象输入数据执行操作查看输出结果是否和预期的结果一致，如果一致则认为被测对象没有问题，否则，则认为被测对象中可能存在缺陷缺陷修改完毕，验证缺陷修改，确认缺陷是否修改正确，是否引入新问题1.2.5软件测试人员的工作流程核心工作产品测试用例缺陷报告单其他重要的工作产品测试计划测试策略测试报告。。。。2.软件测试人员的工作流程1.2.5软件测试人员的工作流程

3.软件测试人员的工作目标

G．Myers给出了关于测试的一些规则，可以把它看作是测试人员的工作目标：软件测试是为了发现错误而执行程序的过程。测试是为了证明程序有错，而不是证明程序无错。一个好的测试用例在于他能发现至今未发现的错误。一个成功的测试是发现了至今未发现的错误的测试。要强调的是软件测试不只是软件测试人员的工作，也是软件开发人员和软件使用者的工作。1.2.5软件测试人员的工作流程1.3软件测试的生命周期与模型1.3.1软件的开发模型1.3.2软件测试的生命周期1.3.3

软件测试与软件开发的关系

1.经典瀑布模型

由美国WinstonRoyce向IEEEWESCON（Royce,Winston1970）提交的一篇名为《管理大规模软件系统的开发》的论文中首次提出的。由于方法的一个阶段成瀑布流入下一个阶段，所以为“瀑布模型或线性模型”。瀑布模型有很多的变化，但都包括以下的阶段：需求分析与定义，系统设计与软件设计，系统实施与单元测试，系统集成与系统测试，系统运行与系统维护，也是软件开发的基本过程。需求分析：可行性分析与软件需求分析软件需求分析：业务需求功能需求非功能需求1.3.1软件的开发模型该处测试仅指执行测试1.3.1软件的开发模型

2.原型模型直观、形象，更多地遵循了人们认识事物的规律，因而更容易被人们接受。采用模拟的手段，缩短了用户和系统分析、设计人员之间的距离。在整个系统开发过程中反馈是及时的，标准是统一的，可及时地暴露问题，确保系统实现的正确性。充分利用了新一代的软件工具，使得系统开发和运行的效率都大大提高。

1.3.1软件的开发模型1.3.1软件的开发模型1.3.1软件的开发模型1.3.1软件的开发模型3.增量与迭代模型增量开发迭代开发

AnalysisDesignCodeTestDeliveryof1stincrementIncrement1AnalysisDesignCodeTestAnalysisDesignCodeTestDeliveryof2ndincrementDeliveryof3rdincrementIncrement2Increment31.3.1软件的开发模型

风险分析风险分析风险分析风险分析原型1原型2原型3可用原型建模模拟评价软件需求需求确认操作概念需求计划开发计划软件产品设计设计确认与验证集成与测试计划详细设计编码单元测试集成测试接收测试实现成本评审制订下阶段计划确定下阶段目标和约束条件风险分析、构造原型开发、验证阶段软件产品过程迭代

4.螺旋模型(风险驱动的过程模型，增量模型与爆布模型相结合)

1.3.1软件的开发模型

5.渐进模型1.3.1软件的开发模型软件测试的生命周期分为6个阶段，前３个阶段是引入错误时期，也就是开发过程中的需求规格说明、设计、编码阶段，此时极易引入错误或者导致开发过程中其他阶段产生错误。后3个阶段是通过测试发现错误、时期，这需要通过使用一些适当的测试技术和方法来共同完成，主要任务是进行缺陷分类、缺陷隔离和解决缺陷。其中在修复旧缺陷的时候很可能引进新的错误，导致原来能够正确执行的程序出现新的缺陷。在软件测试生命周期的每个阶段都要完成一些确定的任务，在执行每个阶段的任务时，可以采用行之有效的结构分析设计技术和适当的辅助工具；在结束每个阶段的任务时都进行严格的技术审查和管理复审。最后提交最终软件配置的一个或几个成分（文档或程序）。1.3.2软件测试的生命周期图1-2软件测试生命周期1.3.2软件测试的生命周期

1．测试与开发各阶段的关系

软件开发过程是一个自顶向下，逐步细化的过程。首先在软件计划阶段定义软件的作用域，进行软件需求分析，建立软件的数据域、功能和性能需求、约束和一些有效性准则。然后进入软件开发---软件设计和编写代码。

测试过程则是依相反的顺序安排的自底向上，逐步集成的过程，低一级测试为上一级测试准备条件。首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。随后再对照需求，进行确认测试。最后从系统全体出发，运行系统，看是否满足要求。1.3.3软件测试与软件开发的关系图1-3软件测试与软件开发过程的关系1.3.3软件测试与软件开发的关系

2．测试与开发的并行性在软件的需求得到确认并通过评审后，概要设计工作和测试计划制定设计工作就要并行进行。如果系统模块已经建立，对各个模块的详细设计、编码、单元测试等工作又可并行。待每个模块完成后，可以进行集成测试、系统测试。并行流程如图1-4所示。1.3.3软件测试与软件开发的关系图1-4软件测试与软件开发的并行性1.3.3软件测试与软件开发的关系

3．测试与开发模型软件测试不仅仅是执行测试，而是一个包含很多复杂活动的过程，并且这些活动贯穿于整个软件开发过程。在软件开发过程中，应该什么时候进行测试，如何更好地把软件开发和测试活动集成到一起？这是软件测试工作人员必须考虑的问题，因为只有这样，才能提高软件测试工作的效率，提高软件产品的质量，最大限度地降低软件开发与测试的成本，减少重复劳动。1.3.3软件测试与软件开发的关系

（1）V模型在传统开发过程中，测试不受重视，仅把它作为在需求分析、概要设计、详细设计及编码之后的一个阶段。在V模型中，描述了一些不同的测试级别，并指出了这些级别所对应的软件生命周期中不同的阶段和测试活动和开发活动的对应关系。这是V模型的主要价值。V模型适用于所有类型的开发过程，但并不一定适用于开发和测试过程的所有方面。特别地，V模型并不是瀑布模型（线性关系）的变形。1.3.3软件测试与软件开发的关系软件测试与开发的V模型1.3.3软件测试与软件开发的关系

（2）W模型由于各种原因，开发的每一个环节都可能产生错误，如果坚持各个阶段的技术评审,就可尽早发现和预防错误。软件开发与测试的W模型，形象地说明了软件测试与开发的同步性。应用W模型的优点在于：每个软件开发活动结束后就可以执行相应的测试。如在需求分析结束后，就可以进行需求分析测试。1.3.3软件测试与软件开发的关系W模型示意图

1.3.3软件测试与软件开发的关系

（3）H模型

与前两种模型相比，H模型充分地体现了测试过程。H模型揭示了:软件测试不仅仅指测试的执行,还包括很多其他的活动。软件测试是一个独立的流程,贯穿软件开发周期,与其它流程并发进行。软件测试要尽早准备,尽早执行。软件测试根据被测物的不同是分层次的，不同层次的测试活动可以是按照某个次序先后进行的,但也可能是反复的。1.3.3软件测试与软件开发的关系H模型示意图1.3.3软件测试与软件开发的关系1.4软件测试计划及其相关文档1.1.1

软件测试计划1.1.2软件测试计划的制订1.1.3开发、测试及计划制定的并行关系1.1.4软件测试文档1.1.5软件测试总结报告1.1.6软件生命周期各阶段交付的测试文档1.4.1

软件测试计划1．测试计划的定义软件测试是一个有组织有计划的活动，应当对时间和资源制订测试计划，才能在合理的控制下正常进行。测试计划作为测试的起始步骤，是整个软件测试过程的关键。测试计划规定了测试各个阶段所要使用的方法策略、测试环境、测试通过或失败的准则等内容。《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”

2．测试计划的目的和作用测试计划的目的是明确测试活动的意图，规范软件测试内容、方法和过程，为有组织地完成测试任务提供保障。尽管测试的每一个步骤都是独立的，但是必须要有一个起到框架结构作用的测试计划。软件测试计划是整个测试过程中最重要的部分，为实现可管理且高质量的测试过程提供基础。1.4.1

软件测试计划3．测试计划书测试计划文档化即是测试计划书，分为总体计划和分级计划，是可以更新改进的文档。测试计划书描述了软件测试预计达到的目标，确定测试过程所要采用的方法策略。从文档的角度看，测试计划书是最重要的测试文档。1.4.1

软件测试计划

4．测试计划的内容测试计划包括测试目的、测试范围、测试对象、测试策略、测试任务、测试用例、资源配置、测试结果分析和度量以及测试风险评估等，测试计划应当足够完整但也不应当太详尽。实际的测试计划内容因不同的测试对象而灵活变化。1.4.1软件测试计划

正规的测试计划应该包含以下几个项目（参考样本）。

（1）测试的基本信息：包括测试目的、背景、测试范围等。（2）测试的具体目标：列出软件需要进行的测试部分和不需要进行的测试部分。（3）测试的策略：测试人员采用的测试方法，如回归测试、功能测试、自动测试等。

（4）测试的通过标准：测试是否通过的界定标准以及没有通过情况的处理方法；

（5）停测标准：给出每个测试阶段停止测试的标准。1.4.1软件测试计划

（6）测试用例：详细描述测试用例，包括测试值、测试操作过程、测试期待值等。（7）测试的基本支持：测试所需硬件、自动测试软件等。（8）部门责任分工：明确所有参与软件管理、开发、测试、技术支持等部门的责任细则。（9）测试人力资源分配：列出测试所需人力资源以及软件测试人员的培训计划。（10）测试进度：制定每一个阶段的详细测试进度安排表。（11）风险估计和危机处理：估计测试过程中潜在的风险以及面临危机时的解决办法。1.4.1软件测试计划5．测试计划的特点一个理想的测试计划应该体现以下几个特点：检测主要缺陷时有一个好的选择；具有灵活性；提供绝大部分代码的覆盖率；定义要执行测试的种类；易于执行、回归和自动化；没有测试冗余；明确说明期望的测试结果；确认测试风险；当缺陷被发现时提供缺陷核对；文档化确定测试的需求；明确定义测试目标；明确定义测试策略；明确定义测试通过标准；定义可交付的测试件。1.4.1软件测试计划6．测试计划的应用借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，明确了测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。一份好的测试计划需要综合考虑各种影响测试的因素。测试计划是软件测试流程工作的基本依据，测试计划中所列条目在实际测试中必须一一执行。在测试的过程中，若发现新的测试用例，就要尽早补充到测试计划中。若预先制定的测试计划项目在实际测试中不适用或无法实现，那么也要尽快对计划进行修改，使计划具有可行性。1.4.1软件测试计划1．测试计划制定的工作内容测试计划制定需要完成的主要工作内容有：拟定测试计划、论证在开发过程中难于管理和控制的因素，明确软件产品的最重要部分（风险评估）。1.4.2测试计划的制订

2、测试计划制定的活动在制定测试计划过程中，核心活动包括：（1）确定测试策：确定测试的范围与方法、确定测试标准和质量检查点、确定自动化测试策略。（2）确定测试系统（硬件和软件）测试架构：测试用例的组织结构；测试工具测试环境：物理测试设施，运行的操作系统与计算平台等。测试配置情况：排列配置的优先级，决定哪些配置需要全面测试，哪些可以进行部分测试。1.4.2测试计划的制订

（3）预估测试工作量（资源和时间进度计划）对项目进行预估有5个准备步骤：确定需完成的任务。确定每项任务所需的工作量和整个测试过程的工作量。确定完成每项任务以及整个测试过程所需的时间。为测试工作建立详细的时间进度计划和里程碑表。评估时间进度风险并准备缓解风险计划。

（4）准备并复查测试计划文档。

1.4.2测试计划的制订测试计划制订活动1.4.2测试计划的制订软件开发过程测试计划制定需求分析功能设计详细设计编码概要测试计划详细测试计划测试大纲测试用例实施测试结果分析纠错质量评审产品发布项目任务书

软件开发、软件测试与测试计划制定的并行关系1.4.3开发、测试及计划制定的并行关系

1．软件测试文档的定义测试文档（TestingDocumentation）记录和描述了整个测试流程，是测试的产出物，是整个测试活动中非常重要的文件。常见的测试文档包括测试计划、测试规范、测试用例（大纲）、缺陷报告和测试报告等。测试报告内容包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终测试结果的分析。测试文档在测试过程中的作用在于：有助于测试任务的完成、更好的协调测试任务与测试过程、为测试项目的组织、规划与管理提供了一个架构。1.4.4测试文档

2．测试文档的类型测试文档一般分为两类：测试计划和测试分析报告。测试计划文档描述将要进行的测试活动的范围、方法、资源和时间进度及测试准则等。在软件的需求和设计阶段就要开始制定测试计划，不能在开始测试的时候才制定测试计划。测试计划的编写要从需求分析阶段开始，直到软件设计阶段结束时才完成。测试报告是执行测试的总结，对测试结果进行分析说明。软件经过测试以后，结论性的意见如何，软件的能力如何，存在哪些缺陷和限制等。测试报告既是对软件质量的评价，又是决定该软件能否交付用户使用的依据。1.4.4测试文档3.软件测试文档的规范《计算机软件测试文档编制规范》国家标准给出了的测试文档编制建议，具体包括以下几个内容。其中前4项属于测试计划类文档，后3项属于测试分析报告类文档。测试计划：描述测试活动的范围、方法、资源和进度，其中规定了被测试的对象，被测试的特性、应完成的测试任务、人员职责及风险等。测试设计规格说明：详细描述测试方法，测试用例设计以及测试通过的准则等。1.4.4测试文档测试用例规格说明：描述一个完整的测试用例所需要的必备因素，如输入、预期结果、测试执行条件以及对环境的要求、对测试规程的要求等。测试步骤规格说明：指明了测试所执行活动的次序，规定了实施测试的具体步骤。它包括测试规程清单和测试规程列表两部分。测试日志：日志是测试小组对测试过程所作的记录。测试事件报告：说明测试中发生的一些重要事件。测试总结报告：对测试活动所作的总结和结论。1.4.4测试文档测试总结报告主要包括测试结果统计表、测试问题表和问题统计表、测试进度表、测试总结表等。1.4.5软件测试总结报告计划测试项实际测试项【Y】项【P】项【N】项【N/A】项备注数量百分比1．测试结果统计表测试结果统计表主要是对测试项目进行统计，统计计划测试项和实际测试项的数量以及测试项通过多少、失败多少等。测试结果统计表1.4.5软件测试总结报告其中：【Y】表示测试结果全部通过，【P】表示测试结果部分通过，【N】表示测试结果绝大多数没通过，【N/A】表示无法测试或测试用例不适合。另外，根据表可以按照下列两个公式分别计算测试完成率和覆盖率，作为测试总结报告的重要数据指标。测试完成率＝实际测试项数量/计划测试项数量×100%测试覆盖率＝【Y】项的数量/计划测试项数量×100%1.4.5软件测试总结报告问题号