Ch3软件测试基础知识.ppt

《Ch3软件测试基础知识.ppt》由会员分享，可在线阅读，更多相关《Ch3软件测试基础知识.ppt（117页珍藏版）》请在三一办公上搜索。

1、23.7.1,1,Part One 软件测试基础,Chapter 3 软件测试基础知识,23.7.1,2,软件测试基础知识,内容概要：序言软件测试定义软件测试目的对软件测试的认识软件测试理论软件测试原则软件测试的分类软件测试的术语和定义其它,23.7.1,3,3.1序言,困惑：软件测试可以说是一个非常令人捉摸不定的领域。“应该怎样对我们的产品进行测试？”和“怎样才算对产品进行了足够的测试？”等问题，对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品,实际操作上都会有很大的不同。,23.7.1,4,软件过程现状,实际项目中，看不到完全符合客户需求的产品需求规格说明书。客户需求

2、不断变化。代码频繁更改。资源有限，进度逼人理想的软件过程只是追求的目标。测试人员应该面对现实。,23.7.1,5,软件测试现状,软件测试的技术和方法多年以来并没有取得令人振奋的进展。软件测试的效果主要还是依赖于测试人员的经验。,23.7.1,6,对软件测试的认识的发展,测试=调试测试是证明软件正确测试是发现软件中的错误测试是减小软件不工作的风险测试是一种认识上的训练,23.7.1,7,关于软件测试的讨论,这个软件已经经过了测试。这个软件已经经过了严格的测试。这个软件通过了测试。,STE概述,23.7.1,8,软件测试的发展,二十世纪70年代以前 Ad-hoc testing，指的是测试者想到哪

3、测到哪，没有周密的测试计划和过程，没有测试文档，测试不能复用，与调试没有区分。70年代末80年代中期 测试基础理论和实用技术形成，测试作为软件质量保证（SQA）的主要职能。,23.7.1,9,软件测试的发展,80年代末90年代中期 测试工具在质量和数量上不断增长，测试与SQA分离，SQA注重于过程和质量监督，专职测试岗位产生。并且注重工具对测试效率的影响，测试自动化开始广泛应用。90年代后期 关注有效的过程管理对于软件测试的重要性，形成各种测试模型、测试能力成熟度模型。,23.7.1,10,软件测试的发展,二十一世纪初 软件测试的重要性越来越被人们接受，甚至出现了软件开发活动应以测试为主导的思

4、潮，如XP方法。而且，随着软件测试分工的细化和成熟，软件企业注重于自身核心竞争力的提升，促使大量的独立软件测试服务机构涌现出来。这些测试服务机构运作机制日趋成熟，从单一的第三方认证评测，逐步转向参与整个软件开发过程的测试服务，并按照软件领域形成市场细分，已经形成一个成熟和广阔的市场区间。,23.7.1,11,软件测试的发展,官方软件评测机构软件工程师资格认证专业软件测试企业专门的软件测试课程专门的软件测试学位（不远的将来）,23.7.1,12,4.2软件测试定义,曾有的定义：软件测试是为了发现错误而执行程序的过程。软件测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即

5、输入数据及预期的输出结果），并利用这些测试用例去运行程序，以发现错误的过程。,23.7.1,13,软件测试的定义（推荐）,【国家标准GBT 114571995】由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求；或识别出期望的结果和实际结果之间的差别。【ISO/IEC2号导则】测试是指由给定产品、过程或按照规定的规程服务的一个或多个特性的测定组成的技术操作。,23.7.1,14,软件测试定义（推荐）,【IEEE/ANSI,std829-1983】对软件进行分析，找出其现有状况与要求状况之间的差异。,基础概念,23.7.1,15,关于软件测试的著名论点,关于软件测试的著

6、名论点Grenford J.Myers：测试是为了发现错误而执行程序的过程一个好的测试是指很可能找到尚未发现的错误的测试一个成功的测试是指发现了至今未发现的错误的测试Hetzel：软件测试是对软件建立信心的过程测试是评估软件或系统的品质或能力的一种积极的行为测试是对软件质量的度量,23.7.1,16,4.3软件测试目的,Grenford J.Myers关于软件测试的著名论点:测试是程序的执行过程，目的在于发现错误；一个好的测试用例在于能够发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。,23.7.1,17,软件测试目的,个人认为这是一种比较狭窄的观点。,23.7.1,18,

7、软件测试目的,一个被人忽略的软件测试目的是：测试可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行改进。测试并不仅仅是为了要找出错误。,23.7.1,19,软件测试目的,通过分析错误产生的原因,分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现，我们可以判断从错误的产生到错误的发现，跨越了多少个开发阶段。一个错误能够超越本开发阶段而不被发现，就指明了该开发阶段的检测手段有缺陷，从而有针对性地制定出加强的措施与办法。这也就是软件过程改进的一项重要内容。,23.7.1,20,对软件测试目的理解,以最少时间和最小代价，发现最多数量的错误。测试具有发现错误的能力，但不能说明软件中不存在错误，恰

8、恰相反，测试只能证明软件中存在错误。测试可以减少软件中的错误。测试过程中的数据和测试结果，可以为软件质量的评价提供依据，可以得到软件性能指标。对测试而言，困难和挑战在于无法预知软件中潜在的错误总 量。但完整的测试是评定软件质量的一种方法。没有发现错误的测试也是有价值的。,23.7.1,21,4.4对软件测试的认识,软件测试能做什么?发现软件中残存的错误为软件质量的评价提供支持为软件开发过程的改进提供帮助一种有效的软件工程验证与确认方法,23.7.1,22,测试设计,测试是需要设计的。一个好的测试计划和测试用例往往能达到事半功倍的效果。测试是一项具有很大创造性的工作，其工作量一点也不比软件设计小

9、。软件测试的创造性主要表现在测试方案选择、测试计划制定、测试用例设计、测试结果的分析以及测试过程的管理等方面,23.7.1,23,测试目标,测试目标我们的目标是设计一个能够系统地发现不同阶段的错误的测试，且消耗最短的时间和最小的工作量。测试的附带收获示证了软件的功能依据其需求说明而工作表明软件满足其性能需求测试中收集的数据提供了软件可靠性和软件质量的部分信息,23.7.1,24,对软件测试的理解,基于上述定义，测试并不仅仅意味着运行程序的动态测试，也包括对需求定义和设计等进行分析的静态测试。测试是攻击和破坏软件的方法和过程，以达到提高软件质量的目的。测试是努力发现上述三类软件错误的活动，即：努

10、力发现偏离错误努力发现语言使用错误努力发现功能缺陷,基础概念,23.7.1,25,对软件测试的理解,从软件过程的角度来看测试：测试是指软件产品生命周期内所有的检查、评审和确认活动。如：设计评审、代码走查、系统测试等。测试的最终目的是确保交给用户的产品符合用户的需求。,23.7.1,26,对软件测试的理解,软件测试要解决的问题是：软件的行为是否符合“规定的”要求。它有两个方面的含义：第一，软件测试要解决的问题是，是否做了规定要做的事；第二，软件是否做了没有规定要做的事？,23.7.1,27,软件测试的局限性,无法实现彻底的测试被测系统存在故障敏感性和巧合正确性不能直接验证需求获得预期结果困难，甚

11、至不可能测试本身也可能存在错误,23.7.1,28,软件测试的致命缺陷,测试的不完全、不彻底性。由于任何软件只能进行有限的测试，发现了错误说明软件有问题；未发现错误不能说明软件没有问题。,23.7.1,29,对测试的正确认识,软件测试不是解决软件质量问题的唯一方法；软件测试不能取代其他的质量保证手段；软件测试不能保证发现软件中的所有错误，完全的测试是不现实的；软件测试是巨大的效益和艰苦的工作并存，测试的组织和管理就是在其中取得平衡。,23.7.1,30,软件测试的重要性,23.7.1,31,项目持续时间,消除缺陷,消除缺陷,软件测试重要性,Close the Quality Gap So We

12、 Can Release Working Software on time,23.7.1,32,100%,软件测试重要性,23.7.1,33,越早测试越好自动的测试测试每一个版本,传统的测试是在代码实现之后进行,软件测试重要性,23.7.1,34,一个好的软件工程的守则,软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开发的“实现阶段”才开始的，在此之前的“可行性研究与计划阶段”，“需求分析阶段”，“概要设计阶段”，和“详细设计阶段”，都必须有切实的手段与措施对开发结果进行检验，以保证阶段的正确完成,23.7.1,35,测试的重要性,测试是软件生存周期中一个独立的、关键的阶段，是保证软

13、件质量的重要手段，也是软件质量保证的最后一个环节。测试活动贯穿于软件活动中的所有阶段。从需求阶段高层设计低层设计编码阶段单元测试集成测试系统测试验收测试测试越早开始，故障越早被发现，消除故障的成本越少。,23.7.1,36,内容概要：,序言软件测试定义软件测试目的对软件测试的认识软件测试理论软件测试原则软件测试的分类软件测试的术语和定义其它,23.7.1,37,3.5软件测试理论,后面总结了9条软件测试的基本原理，是软件测试和软件开发的“交通规则”、“生活法则”。理解它们有助于透彻了解软件过程。,23.7.1,38,Parito法则,一般情况下，在分析、设计、实现阶段的复审和测试工作只能够发现

14、和避免80%的Bug，而系统测试也只能找出其余Bug中的80%，最后剩余的Bug只有在用户的大范围、长时间使用后才有可能会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。也称80-20理论。,23.7.1,39,木桶理论,在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

15、木桶理论就是要强调改进我们木板最短的那一块.只有短木板变为长木板,桶装水才会更多。,23.7.1,40,测试不能证明软件无错,软件测试的不完全、不彻底性。测试无法显示潜伏的软件缺陷。由于任何程序只能进行有限的测试，在发现错误时能说明程序有问题；但在测试未发现错误时，不能说明程序中没有错误。,23.7.1,41,完全测试软件是不可能的,主要原因：输入量太大输出结果太多软件实现的途径太多软件需求规格说明书没有客观标准。“太多”的可能性加在一起，致使测试条件难以确定。,23.7.1,42,完全测试软件是不可能的,例如：WinX操作系统带的计算器程序。单个数据、多个数据的组合；+,-,*./各种算法组

16、合；正常、异常情况组合输入组合无穷多，无法完全测试。注：如果觉得某些测试条件是重复的或者无必要的而将其剔除，那么就不能称作完全测试。,23.7.1,43,软件测试是有风险的行为,如果决定不去测试所有的情况，那就是选择了风险。（泄漏故障的可能性）（碰巧在某个特定的输入组合下软件留有缺陷）如何把无边无际的输入可能减少到可以控制的范围？去粗存精，减小风险。,23.7.1,44,测试量和发现的软件缺陷数量之间的关系,23.7.1,45,软件测试是有风险的行为,由上图，随着测试工作量的增加，费用增加，遗漏软件缺陷数目减少。最佳平衡点在哪？找到了它，就找到了最合适的测试工作量。,23.7.1,46,测试无

17、法显示潜伏的软件缺陷,软件测试工作可以报告已发现的软件缺陷；却不能保证软件缺陷全部找到；也不知道还有多少潜伏的软件缺陷。继续测试，可能还会找到一些。,23.7.1,47,程序中存在错误的概率与该程序中已发现的错误数成比例。,软件缺陷的“群集”现象，80%的错误存在于20%的代码中。原因：程序员疲倦。一个软件缺陷很可能是附近有更多的软件缺陷的征兆。程序员易犯同样的错误。个人偏好。多个软件缺陷相互关联，甚至是由同一个原因造成的。缺陷的“传递”和“放大”。,23.7.1,48,程序中存在错误的概率与该程序中已发现的错误数成比例。,找到软件缺陷越多的模块，遗留的软件缺陷越多。如果某软件无论如何也找不出

18、软件缺陷，也可能是软件经过精心编制，确实存在极少的软件缺陷。,23.7.1,49,软件缺陷的免疫力,软件会对相同类型的测试会产生“免疫力”。(开发小组VS.测试小组)。经过几轮的测试，该发现的错误都被发现了，再测试下去也不会有新的发现了。农药杀虫剂怪事。解决：不断编写新的测试用例，采用新的测试程序，对程序的不同部分进行测试，以找出更多的软件缺陷。,23.7.1,50,并非所有软件缺陷都能修复,项目组需要对每一个软件缺陷进行评估和取舍，根据风险和成本决定哪些必须修复，哪些不用修复，哪些可以延期修复。通常有CCB会议决定。CCB由软件项目各方代表组成。,23.7.1,51,并非所有软件缺陷都能修复

19、,不需要修复的软件缺陷的原因：没有足够的时间。不算是真正的软件缺陷。小功能，小改进。修复的风险太大。技术难度，引入新的缺陷，不值得修复。商业风险（intel奔腾浮点数运算缺陷）,23.7.1,52,相互关系,不可能进行完全的测试。由于1，测试是有风险的，即测试会遗漏软件缺陷。由于2，测试不能证明程序无措，而仅能证明程序有错。由于1，2，3，测试发现的错误越多，则说明软件的错误越多。错误密度大，遗漏的也多。,基础概念,23.7.1,53,内容概要：,序言软件测试定义软件测试目的对软件测试的认识软件测试理论软件测试原则软件测试的分类软件测试的术语和定义其它,23.7.1,54,3.6软件测试的基本

20、原则,基于上述的测试理论，下面列举一些测试原则，它们是软件测试工作中常用的策略。它们建立在实践的基础上。,23.7.1,55,测试的基本原则(一),所有的测试都应追溯到用户需求 产品最终是为了给用户使用，对用户来说，最严重的错误是那些导致程序不能够满足他们的需求的错误，所以测试应该从用户的角度来测试产品。事实上，需求是驱动整个研发过程的源头，不仅仅设计、开发要需求 驱动，测试更是要需求驱动。实际的做法：测试设计依据需求设计，并建立需求追踪矩阵，测试活动按照测试设计进行。测试人员把握用户真实的需求，不仅仅做验证工作，也要做确认工作。,23.7.1,56,测试的基本原则(二),所有测试活动都应该是

21、有计划的，并且计划能够得到保障。严格执行测试计划,排除测试的随意性。要坚决反对无计划、无明确目的、随意的测试活动；反对过程不可重复的即兴测试。测试计划应在需求一确定或需求模型一完成就开始，总之要在代码产生之前就开始。测试计划包括日程计划、资源计划、方案设计、测试用例设计等。现实工作中，常见的问题就是测试无计划或计划性不强、随意更改测试计划、迫于市场压力压缩测试计划等。,23.7.1,57,测试的基本原则(三),Good-enough原则 测试要权衡投入产出比，即要充分也不要过分。不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。过分测试指无意义的重复测试和需要消

22、耗过大投入的非关键性测试。困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。,23.7.1,58,测试的基本原则(三续),答案：制定最低测试通过标准和测试内容，然后具体问题具体分析。持续地对测试过程进行度量，对测试和测试结果评价，在保证充分性的前提下去除冗余测试，确保测试过程的有效性。然而，实际测试工作中，我们很少去关注这方面的数据。对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。寻求合适的测试策略，在质量和成本之间寻求合适的平衡点。,23.7.1,59,测试的基本原则(四),软件测试应遵循Parito法则（二八法则）。二八法则最初来

23、源于社会经济现象研究结果，也同样适用于软件测试领域。80的故障存在于20的代码中；80的故障归因于20的故障原因；关注测试中的群集现象；关注发现缺陷较多的代码。掌握这一法则有助于我们在测试过程中抓住重点，有针对性，做到事半功倍。,23.7.1,60,测试的基本原则(五),尽早地和不断地进行软件测试在软件生命周期中，越早发现软件故障，修复它所花费的费用越少，造成的损失越小。软件开发全过程进行测试，力争在本阶段发现和修正错误。,23.7.1,61,测试的基本原则(六),测试应由小到大，从小规模到大规模。测试的粒度和范围应该由小到大，最初的测试应该把焦点放在单个程序模块上，也就是单元测试，然后是多个

24、模块的集成（集成测试），最后是全系统测试（系统测试）。现状是缺乏小粒度的测试，所以即使系统测试投入足够的资源和时间也难以将产品质量提高到一个新的层次。,23.7.1,62,测试的基本原则(七),穷举测试是不可能的，充分覆盖程序逻辑是有可能的。真实运行情况下，产品将运行于不同的环境和条件下。特别是对于复杂软件，做到穷举测试是不可能的。但是我们应该提高测试的覆盖率，保证程序的每一个逻辑判断分支可以测试到。正是因为不能穷举测试，所以软件总会遗留（潜在的）缺陷，所以测试覆盖率提高是测试永恒的追究目标。因穷举测试是不可行的。为了节省时间和资源，就必须从数量极大的可用测试案例中精心地挑选出少量的具有代表性

25、测试案例（采用这些测试案例是最佳平衡点）；并在测试执行过程中严格按测试计划执行，才能达到最佳的测试效果。,23.7.1,63,测试的基本原则(八),程序员避免测试自己的程序。开发者被指定测试自己的代码是一件很糟糕的事。开发是创造或者建立什么东西的行为，一个模块或者整个系统。而测试的唯一目的是证明一个模块或者系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演的很好。基于这个想法，应该限制开发者在测试中的参与。给他们比较合适的任务是进行有可能的最低层的测试-单元测试。,23.7.1,64,程序员避免测试自己的程序,原因1：心理学因素 当一个程序员在完成了设计，编

26、写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），因而不能有效地测试自己的程序。心理作用：对自己的程序“偏心”,不愿否定自己写的程序（特殊感情）。可以把测试看做是对一篇论文或本书作校对，或与写评论相类似的工作。正如许多作者所知，校对或批评自己的著作是非常困难的。也就是说，在自已的工作中找出缺陷往往是人的心理状态所不容忍的。,23.7.1,65,程序员避免测试自己的程序,原因2：思路受局限难以发现功能理解错误。程序中可能包含由于程序员对问题的叙述或说明的误解而

27、产生的错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。,23.7.1,66,声明,以上看法并不意味着程序员不可能测试自已的程序。不过相比之下如果由另外些人来进行程序测试，就会更有效、更成功。注意：这个论断并不适用于纠错（改正已知错误），由原来程序的作者纠错肯定效率更高。,23.7.1,67,测试的基本原则(九),为了达到最佳效果，应由独立于开发的专门测试人员来构造测试。全面的独立第三方测试对测试的效果有保障（后面详细介绍），但需要在测试的人力和设备上有较大投入。如微软的测试，在开发Exchange 2000时测试人员和开发人员的比例是2.5:1,在开发W

28、in2000时，测试人员和开发人员的比例是1.9:1。我们的实际情况目前难以做到这样的投入。,23.7.1,68,软件测试的其它原则,分派有经验、富有创造性的人员承担测试。不能为了便于测试擅自修改程序。既测试软件应该做的也检查软件不该做的。既测试有效的和期望的输入也测试无效的和不期望的输入。,23.7.1,69,“好的”测试的基本特征,具有高的发现错误的概率没有冗余测试测试是“最佳类别”既不太简单也不太复杂,23.7.1,70,谁来完成测试,1、开发者测试2、对等测试3、独立测试小组4、独立测试机构,23.7.1,71,独立测试的好处,独立测试是指软件测试工作由在经济上和管理上独立于开发机构的

29、组织进行。软件测试由独立测试机构承担有许多好处。独立测试可以避免软件开发者测试自己开发的软件。由于心理学上的问题，软件开发者难以客观、有效地测试自己的软件，而找出那些因为对问题的误解而产生的错误就更加困难。,23.7.1,72,独立测试的好处,独立测试还可以避免软件开发机构测试自己的软件。软件产品的开发过程受到时间、成本和质量三者的制约，时间和成本指标便于衡量，而质量却很难度量，因此在软件开发过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视。如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试过程受到干扰。,23.7.1,73,独立测试

30、的好处,采用独立测试方式，无论在技术上还是管理上，对提高软件测试的有效性都具有重要意义。、客观性对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能够以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完成。,23.7.1,74,独立测试的好处,、专业性独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效用的必然途径。,23.7.1,75,独立测

31、试的好处,、权威性由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，由专业化的独立测试机构的评价，更客观、公正和具有权威性。,23.7.1,76,独立测试的好处,、资源有保证独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性，可以避免开发单位侧重软件开发而对测试工作产生不利的影响。,23.7.1,77,典型项目的软件测试投入(IBM),一般项目：项目总投入的30%40%高可靠性和高安全性项目：项目其它投入的35倍,23.7.1,78,典型项目的人工统计(HP)

32、,23.7.1,79,内容概要：,序言软件测试定义软件测试目的对软件测试的认识软件测试理论软件测试原则软件测试的分类软件测试的术语和定义其它,23.7.1,80,3.7软件测试分类,不同的分类方法，得出不同的分类。,23.7.1,81,软件测试的分类(一),按测试对象分文档测试 包括用户需求文档、软件需求文档、系统设计文档、用户手册等。代码测试版本测试 对代码集成、编译后的软件运行版本的测试。,23.7.1,82,软件测试的分类(二),按测试对象的粒度分单元测试集成测试系统测试确认测试 如验收测试就是典型的确认测试。,23.7.1,83,软件测试的分类(三),按测试方法分白盒测试 白盒测试又叫

33、结构测试。已知软件的内部工作过程，通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经通过检查。黑盒测试 黑盒又叫做功能测试。已知软件的功能设计规格，进行测试证明每个实现了的功能是否符合要求，它不仅用于开发阶段的测试，更重要的是用于产品的测试阶段及维护阶段。灰盒测试 白盒测试和黑盒测试方法的结合运用。目前最常用的测试方法。,23.7.1,84,软件测试的分类(四),按测试执行方法分人工测试自动测试 由工具实现自动的测试运行、记录测试值并和设定的期望值进行比较，自动输出测试结果和测试报告。半自动测试 借助一定的工具辅助手工测试，或者对自动测试进行人工干预。,23.7.1,85,软件

34、测试的分类(五),按运行状态分动态测试 动态测试就是通过选择适当的测试用例，实际运行测试程序，比较运行结果，动态测试能使所测程序有控制地运行，自动地监视、记录、统计程序的运行情况。动态测试更具真实性，但是动态测试必须生成测试数据来运行程序，开展测试工作费时费力，动态测试中涉及多方面工作，要求有完善的管理和工作流程。静态测试 静态测试是指静态分析程序。静态测试不需要执行所测试的程序，它扫描所测试程序的正文，对程序的数据流和控制流进行分析，然后提出测试报告。代码走查可以看作是一种静态测试。静态测试可以使用一些辅助工具如：PCLint、Logiscope、CodeWizard,23.7.1,86,软

35、件测试的分类(六),按测试执行者分开发人员自测测试人员测试第三方测试机构测试验收测试用户测试,23.7.1,87,软件测试的分类(七),按被测对象技术领域分系统平台类软件测试数据库软件测试工具软件测试应用软件测试不同领域的软件对测试的要求也不一样，如系统平台类软件关注系统的稳定性和健壮性，数据库软件关注数据处理的性能和流量，工具类软件关注易用性等。,23.7.1,88,软件测试的分类(八),按测试内容分功能测试性能测试 性能测试用来衡量系统的响应时间、事务处理速度和其它时间敏感的需求。并能测出与性能相关的工作负载和硬件配置条件等。界面测试压力测试 可找出由于资源不足或资源竞争引起的错误，在较少

36、的内存和磁盘空间状态下可能会暴露常态下不易发现的问题。安全性测试,23.7.1,89,软件测试的分类(八),（续）安装测试 确保软件在各种条件下能正确安装，包括初次安装、升级、完全安装和客户定制安装。以及检查软件安装之后操作的正确性。配置测试 检查测试应用在不同的软硬件配置状态下的操作。大多数情况下，不同的客户工作站、网络、数据库服务器配置具备不同的性能，甚至系统性能随软件配置的变化而不同。恢复性测试（容错测试）兼容性测试等等,23.7.1,90,软件测试的分类(九),按测试范围分验证测试 仅仅验证变更的修改是否达到了预期目的。通常会对修改做变更波及分析，但不会重新执行所有的测试用例。完整测试

37、：执行所有的测试用例。回归测试 测试范围介于前两者之间。其测试范围通常是：前一次执行未通过的测试用例；变更波及分析后预计受影响的测试用例；因变更修改而新增的测试用例；部分前一次执行通过的测试用例；部分很长一段时间没有执行过的测试用例。,23.7.1,91,软件测试的分类(九),还有：冒烟测试 进行检验系统是否能够正常上电运行，是否提供最基本的业务功能。BVT（Basic Verify Test）测试 BVT测试是测试的最基本要求，也是最先进行的测试。基准测试 Benchmark Test：和其它相似产品的质量比较 和给定的/设计的质量指标比较 和政府发布的标准/公布的行业数据比较,23.7.1

38、,92,3.8软件测试的术语和定义,不要：混淆误用理解：含义差别,23.7.1,93,准确和精确,举例：飞镖靶盘（图）既不准确又不精确精确但不准确准确但不精确既准确又精确,23.7.1,94,既不准确又不精确,23.7.1,95,精确但不准确,23.7.1,96,准确但不精确,23.7.1,97,既准确又精确,23.7.1,98,Verification&Validation,Verification:do the things rightValidation:do the right things.,23.7.1,99,验证与确认,验证(verification)为确定某一开发阶段的产品是否

39、满足在该阶段开始时提出的要求的评估过程。一般采用静态测试的方式(不基于程序的运行)。通过检查并收集客观的证据来确定特定的需求得到满足。验证对象包括所有选定的需求，包括客户的、产品的以及产品部件的需求，对产品和中间工作产品进行验证。验证是一个渐进的过程。,23.7.1,100,验证与确认,确认(Validation)为确定系统或部件是否满足需求的评估过程。一般采用动态测试的方式(基于程序的运行)。通过检查并收集客观的证据来确定针对某种特定需求在提供时满足预期的使用。确认活动适用于产品在其诸如运行、培训、制造、维护、以及支持服务等任何预期环境中的任何方面。确认活动即可以用于工作产品，也可以用于产品

40、或产品部件。确认活动常常需要用户的参与。,23.7.1,101,验证与确认,验证：构造的产品正确吗？-评审,确认：是否构造了正确的产品？-测试,23.7.1,102,质量和可靠性,错误观点：软件一直稳定、可靠运行，就认定是高质量的产品。用户对质量的看法：功能是否齐全；可靠性；易用性；文档齐套性；产品外观（包装、界面等）；售前售后技术支持程度；等等。,23.7.1,103,质量和可靠性,可靠性只是质量的一个方面。,23.7.1,104,QC和QA,质量控制验证产品的正确性，当发现与设计不一致的时候进行纠正。质量保证充当支持执行全面质量管理的角色,23.7.1,105,测试和QA,软件测试员（QC

41、）：检测软件产品找出缺陷，评价软件质量质量保证人员（QA）：检测软件过程创建和加强促进软件开发并防止软件缺陷的标准、方法和过程。,23.7.1,106,测试和QA,在小型软件公司，可能QA和QC的工作交织在一起，人员交叉和兼任的情况比较普遍。大公司，有专门的测试部门和质量部门，有专职的测试人员和质量人员。,23.7.1,107,3.9其它,软件的可测试性测试用例,23.7.1,108,软件的可测试性,可操作性。运行得越好，测试的效率就越高没有影响操作的错误没有阻碍测试执行的错误允许开发和测试并行可观察性。你所看见的就是你所测试的一个输入对应一个输出系统状态和变量可见历史状态可观察或查询所有影响

42、输出的因素都可见源代码,23.7.1,109,软件的可测试性,可控制性。控制越好，测试越能够自动化和优化所有可能的输出都产生于某种输入或输入组合系统状态和变量直接可控可分解性。模块化各模块可独立测试简单性。需要测试的内容越少，测试就越快功能简单性结构简单性代码简单性,23.7.1,110,稳定性。变更越少，对测试的影响就越小不经常变更变更是可控的易理解性。得到的信息越多，对测试越有利设计能够被很好地理解技术文档资料丰富文档组织合理文档描述准确清晰,软件的可测试性,23.7.1,111,软件测试完成准则,使用了特定的测试用例设计方法查出了预定数目的错误错误强度曲线下降到预定的水平达到测试计划中所

43、规定的完备性其它标准,23.7.1,112,测试用例设计,所谓测试用例，是一份关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。测试用例可以是纯文本的说明文档，也可以是用脚本语言或高级语言编写的一段代码。测试用例应当包括测试标识、测试用例名称、目标、测试条件、测试设置、输入数据要求、步骤、以及预期的结果等,23.7.1,113,优秀测试用例的特点,发现错误的可能性大。这要求测试者要理解软件，并尝试设想软件如何才能失败好的测试用例并不冗余。每一个测试都应该有不同的用途好的测试应该是“最佳品种”。在一组目的相似的测试用例中，时间和资源的限制

44、可能只影响其中某个子集的执行好的测试用例既不会太简单，也不会太复杂好的测试用例应该是可维护的,23.7.1,114,测试用例的设计方法,若被测程序与特定的功能相联系，我们可以针对功能设计测试，以证实各功能完全可执行，同时在功能中寻找错误黑盒法。篇若被测程序与特定的结构相联系，我们可以针对结构设计测试，以确保内部的“所有齿轮相吻合”，即软件的内部操作是遵照规定执行的，且所有的构件被充分利用白盒法,23.7.1,115,小结,截止到目前，学习了软件过程和软件测试的一些基础知识，了解了测试人员的角色，定位。下一部分，讲软件测试的基本技术。,23.7.1,116,欢迎提问和讨论,23.7.1,117,谢 谢！,