《Ch软件测试基础知识实用实用教案》由会员分享，可在线阅读，更多相关《Ch软件测试基础知识实用实用教案（117页珍藏版）》请在金锄头文库上搜索。
1、2024/7/2613.1序言(xyn)困惑：软件测试可以说是一个非常令人捉摸不定的领域。“应该怎样对我们的产品进行(jnxng)测试？”和“怎样才算对产品进行(jnxng)了足够的测试？”等问题，对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品,实际操作上都会有很大的不同。第1页/共116页第一页，共117页。2024/7/262软件(runjin)过程现状实际项目中，看不到完全符合客户需求的产品需求规格说明书。客户需求不断变化。代码频繁更改。资源有限，进度逼人理想(lxing)的软件过程只是追求的目标。测试人员应该面对现实。第2页/共116页第二页，共117页。202
2、4/7/263软件测试现状(xinzhung)软件测试的技术和方法多年以来并没有(mi yu)取得令人振奋的进展。软件测试的效果主要还是依赖于测试人员的经验。第3页/共116页第三页，共117页。2024/7/264对软件测试的认识(rn shi)的发展测试=调试测试是证明软件正确测试是发现软件中的错误测试是减小软件不工作的风险(fngxin)测试是一种认识上的训练第4页/共116页第四页，共117页。2024/7/265关于(guny)软件测试的讨论这个软件(runjin)已经经过了测试。这个软件(runjin)已经经过了严格的测试。这个软件(runjin)通过了测试。STE概述概述(i s
3、h)第5页/共116页第五页，共117页。2024/7/266软件测试的发展(fzhn)二十世纪70年代以前Ad-hoctesting，指的是测试者想到哪测到哪，没有周密的测试计划和过程，没有测试文档，测试不能复用，与调试没有区分。70年代末80年代中期测试基础理论和实用技术形成(xngchng)，测试作为软件质量保证（SQA）的主要职能。第6页/共116页第六页，共117页。2024/7/267软件测试的发展(fzhn)80年代末90年代中期测试工具(gngj)在质量和数量上不断增长，测试与SQA分离，SQA注重于过程和质量监督，专职测试岗位产生。并且注重工具(gngj)对测试效率的影响，测
4、试自动化开始广泛应用。90年代后期关注有效的过程管理对于软件测试的重要性，形成各种测试模型、测试能力成熟度模型。第7页/共116页第七页，共117页。2024/7/268软件测试的发展(fzhn)二十一世纪初软件测试的重要性越来越被人们接受，甚至出现了软件开发活动应以测试为主导的思潮，如XP方法。而且，随着软件测试分工的细化和成熟，软件企业注重于自身核心竞争力的提升，促使大量的独立软件测试服务机构涌现出来。这些测试服务机构运作机制日趋成熟，从单一的第三方认证评测，逐步转向参与整个软件开发过程的测试服务，并按照软件领域形成(xngchng)市场细分，已经形成(xngchng)一个成熟和广阔的市场
5、区间。第8页/共116页第八页，共117页。2024/7/269软件测试的发展(fzhn)官方软件(runjin)评测机构软件(runjin)工程师资格认证专业软件(runjin)测试企业专门的软件(runjin)测试课程专门的软件(runjin)测试学位（不远的将来）第9页/共116页第九页，共117页。2024/7/26104.2软件测试定义(dngy)曾有的定义：软件测试是为了发现错误而执行程序的过程。软件测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入(shr)数据及预期的输出结果），并利用这些测试用例去运行程序，以发现错误的过程。第10页/共116页第
6、十页，共117页。2024/7/2611软件测试的定义(dngy)（推荐）【国家标准GBT114571995】由人工或自动方法来执行(zhxng)或评价系统或系统部件的过程，以验证它是否满足规定的需求；或识别出期望的结果和实际结果之间的差别。【ISO/IEC2号导则】测试是指由给定产品、过程或按照规定的规程服务的一个或多个特性的测定组成的技术操作。第11页/共116页第十一页，共117页。2024/7/2612软件测试定义(dngy)（推荐）【IEEE/ANSI,std829-1983】对软件(runjin)进行分析，找出其现有状况与要求状况之间的差异。基础基础(jch)概念概念 第12页/共
7、116页第十二页，共117页。2024/7/2613关于(guny)软件测试的著名论点关于软件测试的著名论点GrenfordJ.Myers：测试是为了发现错误而执行程序的过程一个好的测试是指很可能找到尚未发现的错误的测试一个成功的测试是指发现了至今(zhjn)未发现的错误的测试Hetzel：软件测试是对软件建立信心的过程测试是评估软件或系统的品质或能力的一种积极的行为测试是对软件质量的度量第13页/共116页第十三页，共117页。2024/7/26144.3软件测试目的(md)Grenford J. Myers关于软件测试的著名论点:测试是程序的执行过程，目的在于发现错误(cuw)；一个好的测
8、试用例在于能够发现至今未发现的错误(cuw)；一个成功的测试是发现了至今未发现的错误(cuw)的测试。第14页/共116页第十四页，共117页。2024/7/2615软件测试目的(md)个人认为(rnwi)这是一种比较狭窄的观点。第15页/共116页第十五页，共117页。2024/7/2616软件测试目的(md)一个被人忽略的软件测试目的是：测试可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行(jnxng)改进。 测试并不仅仅是为了要找出错误。第16页/共116页第十六页，共117页。2024/7/2617软件测试目的(md)通过分析错误产生的原因, 分析错误产生于哪一个开发阶段、而又
9、在哪一个阶段被发现，我们可以判断从错误的产生到错误的发现，跨越了多少个开发阶段。一个错误能够超越本开发阶段而不被发现，就指明了该开发阶段的检测手段有缺陷，从而有针对性地制定出加强的措施与办法。这也就是软件过程改进(gijn)的一项重要内容。第17页/共116页第十七页，共117页。2024/7/2618对软件测试目的(md)理解以最少时间和最小代价，发现最多数量的错误。测试具有发现错误的能力，但不能说明软件中不存在错误，恰恰相反，测试只能证明软件中存在错误。测试可以减少软件中的错误。测试过程中的数据和测试结果，可以为软件质量的评价提供(tgng)依据，可以得到软件性能指标。对测试而言，困难和挑
10、战在于无法预知软件中潜在的错误总量。但完整的测试是评定软件质量的一种方法。没有发现错误的测试也是有价值的。第18页/共116页第十八页，共117页。2024/7/26194.4对软件测试的认识(rnshi)软件测试能做什么?发现软件中残存的错误为软件质量的评价提供支持为软件开发过程的改进提供帮助一种有效的软件工程(runjinnchn)验证与确认方法第19页/共116页第十九页，共117页。2024/7/2620测试(csh)设计 测试是需要设计的。一个好的测试计划和测试用例往往能达到事半功倍的效果。测试是一项具有很大创造性的工作，其工作量一点也不比软件设计小。软件测试的创造性主要表现在测试方
11、案选择、测试计划制定、测试用例设计、测试结果的分析以及(yj)测试过程的管理等方面第20页/共116页第二十页，共117页。2024/7/2621测试(csh)目标测试目标我们的目标是设计一个能够系统地发现不同阶段的错误的测试，且消耗最短的时间和最小的工作量。测试的附带收获示证了软件的功能依据其需求说明而工作表明软件满足其性能需求测试中收集(shuj)的数据提供了软件可靠性和软件质量的部分信息第21页/共116页第二十一页，共117页。2024/7/2622对软件测试的理解(lji)基于上述(shngsh)定义，测试并不仅仅意味着运行程序的动态测试，也包括对需求定义和设计等进行分析的静态测试。
12、测试是攻击和破坏软件的方法和过程，以达到提高软件质量的目的。测试是努力发现上述(shngsh)三类软件错误的活动，即：努力发现偏离错误努力发现语言使用错误努力发现功能缺陷基础基础(jch)概念概念 第22页/共116页第二十二页，共117页。2024/7/2623对软件测试的理解(lji)从软件过程的角度来看测试： 测试是指软件产品生命周期内所有的检查、评审和确认活动。如：设计评审、代码(di m)走查、系统测试等。测试的最终目的是确保交给用户的产品符合用户的需求。第23页/共116页第二十三页，共117页。2024/7/2624对软件测试的理解(lji)v软件测试要解决的问题是：软件的行为是
13、否符合“规定的”要求。它有两个方面的含义(hny)：第一，软件测试要解决的问题是，是否做了规定要做的事；第二，软件是否做了没有规定要做的事？第24页/共116页第二十四页，共117页。2024/7/2625软件测试的局限性无法实现彻底的测试(csh)被测系统存在故障敏感性和巧合正确性不能直接验证需求获得预期结果困难，甚至不可能测试(csh)本身也可能存在错误第25页/共116页第二十五页，共117页。2024/7/2626软件测试的致命(zhmng)缺陷测试(csh)的不完全、不彻底性。由于任何软件只能进行有限的测试(csh)，发现了错误说明软件有问题；未发现错误不能说明软件没有问题。第26页
14、/共116页第二十六页，共117页。2024/7/2627对测试(csh)的正确认识软件测试不是解决软件质量问题的唯一方法；软件测试不能取代其他的质量保证手段；软件测试不能保证发现软件中的所有错误，完全的测试是不现实的；软件测试是巨大的效益和艰苦的工作并存，测试的组织和管理就是在其中取得(qd)平衡。第27页/共116页第二十七页，共117页。2024/7/2628软件测试的重要性项目持续时间项目持续时间 延迟上市延迟上市测试人员测试人员测试人员测试人员100%50%0%完成比率完成比率代码实现代码实现消除缺陷消除缺陷质量问题质量问题维护的费用维护的费用1x 10x 100x 问题发现得越早，
15、解决的代价就越小第28页/共116页第二十八页，共117页。2024/7/2629项目持续时间项目持续时间 100%50%0%完成比率完成比率消除缺陷消除缺陷消除缺陷消除缺陷保证软件质量保证软件质量缩短上市时间缩短上市时间Close the Quality Gap软件测试重要性Close the Quality Gap So We Can Release Working Software on timeClose the Quality Gap So We Can Release Working Software on time第29页/共116页第二十九页，共117页。2024/7/2630
16、系统性能系统性能应用性能应用性能功能功能可靠性可靠性100%软件测试重要性第30页/共116页第三十页，共117页。2024/7/2631风险风险风险风险代码完成代码完成可靠性可靠性功能功能应用性能应用性能系统性能系统性能风险风险风险风险越早测试越好越早测试越好自动自动(zdng)的测试的测试测试每一个版本测试每一个版本 传统的测试传统的测试是在代码实是在代码实现现(shxin)之后进行之后进行 软件测试重要性第31页/共116页第三十一页，共117页。2024/7/2632一个好的软件工程(run jin n chn)的守则软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开发的“实现
17、(shxin)阶段”才开始的，在此之前的“可行性研究与计划阶段”，“需求分析阶段”，“概要设计阶段”，和“详细设计阶段”，都必须有切实的手段与措施对开发结果进行检验，以保证阶段的正确完成第32页/共116页第三十二页，共117页。2024/7/2633测试(csh)的重要性测试是软件生存周期中一个独立的、关键的阶段，是保证软件质量的重要手段，也是软件质量保证的最后一个环节。测试活动贯穿于软件活动中的所有阶段。 从需求阶段高层设计低层设计编码阶段单元测试集成测试系统测试验收测试测试越早开始(kish)，故障越早被发现，消除故障的成本越少。第33页/共116页第三十三页，共117页。2024/7/
18、2634内容(nirng)概要：1)序言2)软件测试定义3)软件测试目的4)对软件测试的认识5)软件测试理论6)软件测试原则7)软件测试的分类(fnli)8)软件测试的术语和定义9)其它第34页/共116页第三十四页，共117页。2024/7/26353.5软件测试理论(lln) 后面总结了9条软件测试的基本原理，是软件测试和软件开发的“交通规则”、“生活法则”。理解它们有助于透彻了解(lioji)软件过程。第35页/共116页第三十五页，共117页。2024/7/2636 Parito Parito法则(fz) (fz) 一般情况下，在分析、设计、实现阶段的复审和测试工作只能够发现和避免80
19、%的Bug，而系统测试也只能找出其余Bug中的80%，最后剩余的Bug只有在用户的大范围、长时间使用后才有可能会曝露出来。因为测试只能够保证尽可能多地发现错误，无法(wf)保证能够发现所有的错误。 也称80-20理论。第36页/共116页第三十六页，共117页。2024/7/2637木桶理论(lln)(lln)在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件(b yo tio jin)，也是提高产品质量最直接、最快捷的手段，但决不是
20、一种根本手段。反过来说，如果将提高产品量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。木桶理论就是要强调改进我们木板最短的那一块.只有短木板变为长木板,桶装水才会更多。第37页/共116页第三十七页，共117页。2024/7/2638测试不能证明(zhngmng)(zhngmng)软件无错 软件测试的不完全、不彻底性。测试无法显示潜伏(qinf)的软件缺陷。 由于任何程序只能进行有限的测试，在发现错误时能说明程序有问题；但在测试未发现错误时，不能说明程序中没有错误。第38页/共116页第三十八页，共117页。2024/7/2639完全(wnqun)(wnqun)测试软件是不可能的主要原因：
21、输入量太大输出结果(ji gu)太多软件实现的途径太多软件需求规格说明书没有客观标准。“太多”的可能性加在一起，致使测试条件难以确定。第39页/共116页第三十九页，共117页。2024/7/2640完全(wnqun)测试软件是不可能的例如：WinX操作系统带的计算器程序。单个数据、多个数据的组合；+,-,*./各种算法组合；正常、异常情况组合输入组合无穷多，无法完全测试。注：如果觉得(ju de)某些测试条件是重复的或者无必要的而将其剔除，那么就不能称作完全测试。第40页/共116页第四十页，共117页。2024/7/2641软件测试是有风险(fngxin)(fngxin)的行为 如果决定不
22、去测试所有的情况，那就是选择了风险(fngxin)。（泄漏故障的可能性）（碰巧在某个特定的输入组合下软件留有缺陷）如何把无边无际的输入可能减少到可以控制的范围？去粗存精，减小风险(fngxin)。第41页/共116页第四十一页，共117页。2024/7/2642测试量和发现(fxin)的软件缺陷数量之间的关系第42页/共116页第四十二页，共117页。2024/7/2643软件测试是有风险(fngxin)的行为 由上图，随着测试工作量的增加，费用(fi yong)增加，遗漏软件缺陷数目减少。最佳平衡点在哪？找到了它，就找到了最合适的测试工作量。第43页/共116页第四十三页，共117页。202
23、4/7/2644测试(csh)(csh)无法显示潜伏的软件缺陷 软件测试工作可以报告已发现的软件缺陷；却不能保证软件缺陷全部找到；也不知道还有多少潜伏的软件缺陷。继续测试，可能(knng)还会找到一些。第44页/共116页第四十四页，共117页。2024/7/2645程序中存在错误(cuw)(cuw)的概率与该程序中已发现的错误(cuw)(cuw)数成比例。 软件缺陷的“群集”现象， 80%的错误存在于20%的代码中。原因(yunyn)：程序员疲倦。一个软件缺陷很可能是附近有更多的软件缺陷的征兆。程序员易犯同样的错误。个人偏好。多个软件缺陷相互关联，甚至是由同一个原因(yunyn)造成的。缺陷
24、的“传递”和“放大”。第45页/共116页第四十五页，共117页。2024/7/2646程序(chngx)(chngx)中存在错误的概率与该程序(chngx)(chngx)中已发现的错误数成比例。 找到软件缺陷越多的模块，遗留的软件缺陷越多。如果某软件无论如何也找不出软件缺陷，也可能(knng)是软件经过精心编制，确实存在极少的软件缺陷。第46页/共116页第四十六页，共117页。2024/7/2647软件缺陷的免疫力软件会对相同类型的测试会产生“免疫力”。(开发小组VS.测试小组)。经过几轮的测试，该发现的错误都被发现了，再测试下去也不会有新的发现了。农药(nngyo)杀虫剂怪事。解决：不断
25、编写新的测试用例，采用新的测试程序，对程序的不同部分进行测试，以找出更多的软件缺陷。第47页/共116页第四十七页，共117页。2024/7/2648并非所有(suyu)(suyu)软件缺陷都能修复 项目组需要对每一个软件缺陷进行评估和取舍，根据风险和成本决定哪些必须修复，哪些不用(byng)修复，哪些可以延期修复。通常有CCB会议决定。CCB由软件项目各方代表组成。第48页/共116页第四十八页，共117页。2024/7/2649并非所有(suyu)软件缺陷都能修复不需要修复的软件缺陷的原因：没有足够的时间。不算是真正的软件缺陷。小功能，小改进。修复的风险太大。技术难度，引入新的缺陷，不值得
26、修复。商业风险（intel奔腾(bntng)浮点数运算缺陷）第49页/共116页第四十九页，共117页。2024/7/2650相互(xingh)关系1.不可能进行完全的测试。2.由于(yuy)1，测试是有风险的，即测试会遗漏软件缺陷。3.由于(yuy)2，测试不能证明程序无措，而仅能证明程序有错。4.由于(yuy)1，2，3，测试发现的错误越多，则说明软件的错误越多。错误密度大，遗漏的也多。基础基础(jch)概念概念 第50页/共116页第五十页，共117页。2024/7/2651内容(nirng)概要：1)序言2)软件测试定义3)软件测试目的4)对软件测试的认识(rnshi)5)软件测试理论
27、6)软件测试原则7)软件测试的分类8)软件测试的术语和定义9)其它第51页/共116页第五十一页，共117页。2024/7/26523.6软件测试的基本(jbn)原则 基于上述的测试理论，下面列举一些测试原则，它们是软件测试工作中常用(chn yn)的策略。它们建立在实践的基础上。第52页/共116页第五十二页，共117页。2024/7/2653测试(csh)的基本原则(一)所有的测试都应追溯到用户需求 产品最终是为了给用户使用，对用户来说，最严重的错误是那些导致程序不能够满足他们的需求的错误，所以测试应该从用户的角度来测试产品。 事实上，需求是驱动整个研发过程的源头，不仅仅设计、开发要需求
28、驱动，测试更是要需求驱动。 实际的做法：测试设计依据需求设计，并建立需求追踪矩阵，测试活动按照测试设计进行。测试人员把握用户真实的需求，不仅仅做验证(ynzhng)(ynzhng)工作，也要做确认工作。第53页/共116页第五十三页，共117页。2024/7/2654测试(csh)的基本原则(二)所有测试活动都应该是有计划的，并且计划能够得到保障。 严格执行测试计划, ,排除测试的随意性。要坚决反对无计划、无明确(mngqu)(mngqu)目的、随意的测试活动；反对过程不可重复的即兴测试。 测试计划应在需求一确定或需求模型一完成就开始，总之要在代码产生之前就开始。测试计划包括日程计划、资源计划
29、、方案设计、测试用例设计等。 现实工作中，常见的问题就是测试无计划或计划性不强、随意更改测试计划、迫于市场压力压缩测试计划等。第54页/共116页第五十四页，共117页。2024/7/2655测试的基本(jbn)原则(三) Good-enough原则 测试要权衡(qunhng)投入产出比，即要充分也不要过分。不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。 过分测试指无意义的重复测试和需要消耗过大投入的非关键性测试。 困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。第55页/共116页第五十五页，共117页。2024/7/2656测试(csh)
30、的基本原则(三续) 答案： 制定最低测试通过标准和测试内容，然后具体问题具体分析。 持续地对测试过程进行度量，对测试和测试结果评价，在保证充分性的前提下去除冗余测试，确保测试过程的有效性。 然而，实际测试工作中，我们很少去关注这方面的数据。 对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则(yunz)。 寻求合适的测试策略，在质量和成本之间寻求合适的平衡点。第56页/共116页第五十六页，共117页。2024/7/2657测试的基本(jbn)原则(四)软件测试应遵循ParitoParito法则（二八法则）。 二八法则最初来源于社会经济现象研究结果，也
31、同样适用(shyng)(shyng)于软件测试领域。 80 80的故障存在于2020的代码中； 80 80的故障归因于2020的故障原因； 关注测试中的群集现象；关注发现缺陷较多的代码。 掌握这一法则有助于我们在测试过程中抓住重点，有针对性，做到事半功倍。第57页/共116页第五十七页，共117页。2024/7/2658测试(csh)的基本原则(五)尽早地和不断地进行软件测试在软件生命周期中，越早发现软件故障，修复它所花费的费用越少，造成(zo chn)的损失越小。软件开发全过程进行测试，力争在本阶段发现和修正错误。第58页/共116页第五十八页，共117页。2024/7/2659测试(csh
32、)的基本原则(六)测试应由小到大，从小规模到大规模。 测试的粒度和范围应该(ynggi)(ynggi)由小到大，最初的测试应该(ynggi)(ynggi)把焦点放在单个程序模块上，也就是单元测试，然后是多个模块的集成（集成测试），最后是全系统测试（系统测试）。 现状是缺乏小粒度的测试，所以即使系统测试投入足够的资源和时间也难以将产品质量提高到一个新的层次。 第59页/共116页第五十九页，共117页。2024/7/2660测试的基本(jbn)原则(七)穷举测试是不可能的，充分覆盖程序逻辑是有可能的。 真实运行情况下，产品将运行于不同的环境和条件下。特别是对于复杂软件，做到穷举测试是不可能的。
33、但是我们应该提高测试的覆盖率，保证程序的每一个逻辑判断分支可以测试到。 正是因为不能穷举测试，所以软件总会遗留（潜在的）缺陷，所以测试覆盖率提高是测试永恒的追究目标。 因穷举测试是不可行的。为了节省时间和资源，就必须从数量极大的可用测试案例(n l)(n l)中精心地挑选出少量的具有代表性测试案例(n l)(n l)（采用这些测试案例(n l)(n l)是最佳平衡点）；并在测试执行过程中严格按测试计划执行，才能达到最佳的测试效果。第60页/共116页第六十页，共117页。第61页/共116页第六十一页，共117页。第62页/共116页第六十二页，共117页。2024/7/2663程序员避免测试
34、自己(zj)的程序 原因2：思路受局限难以发现功能理解错误。 程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当程序员测试自己(zj)的程序时，往往还会带着同样的误解致使问题难以发现。第63页/共116页第六十三页，共117页。第64页/共116页第六十四页，共117页。2024/7/2665测试(csh)的基本原则(九)为了达到最佳效果，应由独立于开发的专门测试人员来构造测试。 全面的独立第三方测试对测试的效果有保障（后面详细介绍），但需要在测试的人力(rnl)(rnl)和设备上有较大投入。如微软的测试，在开发Exchange Exchange 20002000
35、时测试人员和开发人员的比例是2.5:1,2.5:1,在开发Win2000Win2000时，测试人员和开发人员的比例是1.9:11.9:1。 我们的实际情况目前难以做到这样的投入。第65页/共116页第六十五页，共117页。2024/7/2666软件测试的其它(qt)原则 1.分派有经验、富有创造性的人员承担测试(csh)。 2.不能为了便于测试(csh)擅自修改程序。3.既测试(csh)软件应该做的也检查软件不该做的。4.既测试(csh)有效的和期望的输入也测试(csh)无效的和不期望的输入。第66页/共116页第六十六页，共117页。2024/7/2667“好的”测试(csh)的基本特征1.
36、具有( jyu)高的发现错误的概率2.没有冗余测试3.测试是“最佳类别”4.既不太简单也不太复杂第67页/共116页第六十七页，共117页。2024/7/2668谁来完成(wnchng)测试1、开发者测试(csh)2、对等测试(csh)3、独立测试(csh)小组4、独立测试(csh)机构第68页/共116页第六十八页，共117页。2024/7/2669独立测试(csh)的好处独立测试是指软件测试工作由在经济上和管理上独立于开发机构的组织进行。软件测试由独立测试机构承担有许多(xdu)好处。独立测试可以避免软件开发者测试自己开发的软件。由于心理学上的问题，软件开发者难以客观、有效地测试自己的软件
37、，而找出那些因为对问题的误解而产生的错误就更加困难。 第69页/共116页第六十九页，共117页。2024/7/2670独立(dl)测试的好处独立测试还可以避免软件开发机构测试自己的软件。软件产品的开发过程受到时间、成本和质量三者的制约(zhyu)，时间和成本指标便于衡量，而质量却很难度量，因此在软件开发过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视。如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试过程受到干扰。 第70页/共116页第七十页，共117页。第71页/共116页第七十一页，共117页。第72页/共116页第七十二页，
38、共117页。第73页/共116页第七十三页，共117页。第74页/共116页第七十四页，共117页。2024/7/2675典型项目(xingm)的软件测试投入(IBM)一般(ybn)项目：项目总投入的30%40%高可靠性和高安全性项目：项目其它投入的35倍第75页/共116页第七十五页，共117页。2024/7/2676典型项目的人工(rngng)统计(HP)第76页/共116页第七十六页，共117页。2024/7/2677内容(nirng)概要：1)序言2)软件测试定义(dngy)3)软件测试目的4)对软件测试的认识5)软件测试理论6)软件测试原则7)软件测试的分类8)软件测试的术语和定义(
39、dngy)9)其它第77页/共116页第七十七页，共117页。2024/7/26783.7软件测试分类(fn li)不同的分类(fn li)方法，得出不同的分类(fn li)。第78页/共116页第七十八页，共117页。2024/7/2679软件测试的分类(fnli)(一)按测试(csh)(csh)对象分文档测试(csh)(csh) 包括用户需求文档、软件需求文档、系统设计文档、用户手册等。代码测试(csh)(csh)版本测试(csh)(csh) 对代码集成、编译后的软件运行版本的测试(csh)(csh)。第79页/共116页第七十九页，共117页。2024/7/2680软件测试的分类(fnl
40、i)(二)按测试对象的粒度分单元测试集成测试系统测试确认测试 如验收(ynshu)(ynshu)测试就是典型的确认测试。第80页/共116页第八十页，共117页。2024/7/2681软件测试的分类(fnli)(三)按测试方法分白盒测试 白盒测试又叫结构测试。已知软件的内部工作过程，通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经通过检查。黑盒测试 黑盒又叫做功能测试。已知软件的功能设计规格，进行测试证明每个实现了的功能是否符合要求，它不仅用于开发阶段的测试，更重要的是用于产品的测试阶段及维护阶段。灰盒测试 白盒测试和黑盒测试方法的结合运用。目前(mqin)(mqin)最常用
41、的测试方法。第81页/共116页第八十一页，共117页。2024/7/2682软件测试的分类(fnli)(四)按测试执行方法分人工测试自动测试 由工具实现自动的测试运行、记录测试值并和设定(sh dn)(sh dn)的期望值进行比较，自动输出测试结果和测试报告。半自动测试 借助一定的工具辅助手工测试，或者对自动测试进行人工干预。 第82页/共116页第八十二页，共117页。2024/7/2683软件测试的分类(fnli)(五)按运行状态分动态测试 动态测试就是通过选择适当的测试用例，实际运行测试程序，比较运行结果，动态测试能使所测程序有控制地运行，自动地监视、记录、统计程序的运行情况(qngk
42、ung)(qngkung)。 动态测试更具真实性，但是动态测试必须生成测试数据来运行程序，开展测试工作费时费力，动态测试中涉及多方面工作，要求有完善的管理和工作流程。静态测试 静态测试是指静态分析程序。静态测试不需要执行所测试的程序，它扫描所测试程序的正文，对程序的数据流和控制流进行分析，然后提出测试报告。 代码走查可以看作是一种静态测试。静态测试可以使用一些辅助工具如：PCLintPCLint、Logiscope Logiscope 、CodeWizardCodeWizard第83页/共116页第八十三页，共117页。2024/7/2684软件测试的分类(fnli)(六) 按测试执行者分开发
43、人员自测(z c)(z c)测试人员测试第三方测试机构测试验收测试用户测试 第84页/共116页第八十四页，共117页。2024/7/2685软件测试的分类(fnli)(七)按被测对象技术领域分系统平台类软件测试数据库软件测试工具软件测试应用软件测试不同领域的软件对测试的要求也不一样，如系统平台类软件关注系统的稳定性和健壮性，数据库软件关注数据处理的性能(xngnng)(xngnng)和流量，工具类软件关注易用性等。第85页/共116页第八十五页，共117页。2024/7/2686软件测试的分类(fnli)(八)按测试内容分功能测试性能测试 性能测试用来衡量系统的响应时间、事务处理速度和其它时
44、间敏感的需求。并能测出与性能相关(xinggun)(xinggun)的工作负载和硬件配置条件等。界面测试压力测试 可找出由于资源不足或资源竞争引起的错误，在较少的内存和磁盘空间状态下可能会暴露常态下不易发现的问题。安全性测试第86页/共116页第八十六页，共117页。2024/7/2687软件测试的分类(fnli)(八)（续）安装测试 确保软件在各种条件下能正确安装，包括初次安装、升级、完全安装和客户定制安装。以及检查软件安装之后操作的正确性。配置测试 检查测试应用在不同的软硬件配置状态下的操作。大多数情况下，不同的客户工作站、网络(wnglu)(wnglu)、数据库服务器配置具备不同的性能，
45、甚至系统性能随软件配置的变化而不同。恢复性测试（容错测试）兼容性测试等等第87页/共116页第八十七页，共117页。2024/7/2688软件测试的分类(fnli)(九)按测试范围分验证测试 仅仅验证变更的修改是否达到了预期目的。通常会对修改做变更波及(bj)(bj)分析，但不会重新执行所有的测试用例。完整测试：执行所有的测试用例。回归测试 测试范围介于前两者之间。其测试范围通常是：前一次执行未通过的测试用例；变更波及(bj)(bj)分析后预计受影响的测试用例；因变更修改而新增的测试用例；部分前一次执行通过的测试用例；部分很长一段时间没有执行过的测试用例。第88页/共116页第八十八页，共11
46、7页。2024/7/2689软件测试的分类(fnli)(九)还有：冒烟测试 进行检验系统是否能够正常上电运行，是否提供最基本的业务功能。BVTBVT（Basic Verify TestBasic Verify Test）测试 BVT BVT测试是测试的最基本要求，也是最先进行的测试。基准测试 Benchmark Test Benchmark Test： 和其它相似产品的质量比较 和给定的/ /设计的质量指标比较 和政府发布的标准(biozhn)/(biozhn)/公布的行业数据比较第89页/共116页第八十九页，共117页。2024/7/26903.8软件测试的术语(shy)和定义不要：混淆(
47、hnxio)误用理解：含义差别第90页/共116页第九十页，共117页。2024/7/2691准确(zhnqu)和精确举例：飞镖靶盘（图）既不准确(zhnqu)又不精确精确但不准确(zhnqu)准确(zhnqu)但不精确既准确(zhnqu)又精确第91页/共116页第九十一页，共117页。2024/7/2692既不准确(zhnqu)又不精确第92页/共116页第九十二页，共117页。2024/7/2693精确(jngqu)但不准确第93页/共116页第九十三页，共117页。2024/7/2694准确(zhnqu)但不精确第94页/共116页第九十四页，共117页。2024/7/2695既准确(
48、zhnqu)又精确第95页/共116页第九十五页，共117页。2024/7/2696Verification&ValidationVerification: do the things rightValidation: do the right things.第96页/共116页第九十六页，共117页。2024/7/2697验证(ynzhng)与确认验证(verification)为确定(qudng)某一开发阶段的产品是否满足在该阶段开始时提出的要求的评估过程。一般采用静态测试的方式(不基于程序的运行)。通过检查并收集客观的证据来确定(qudng)特定的需求得到满足。验证对象包括所有选定的需求
49、，包括客户的、产品的以及产品部件的需求，对产品和中间工作产品进行验证。验证是一个渐进的过程。第97页/共116页第九十七页，共117页。2024/7/2698验证(ynzhng)与确认确认(Validation)为确定系统或部件是否满足需求的评估过程。一般采用动态测试的方式(基于程序的运行)。通过检查并收集客观(kgun)的证据来确定针对某种特定需求在提供时满足预期的使用。确认活动适用于产品在其诸如运行、培训、制造、维护、以及支持服务等任何预期环境中的任何方面。确认活动即可以用于工作产品，也可以用于产品或产品部件。确认活动常常需要用户的参与。第98页/共116页第九十八页，共117页。2024
50、/7/2699验证(ynzhng)与确认验证：构造的产品正确(zhngqu)吗？-评审n确认：是否构造了正确(zhngqu)的产品？- 测试第99页/共116页第九十九页，共117页。2024/7/26100质量(zhling)和可靠性错误观点：软件一直稳定、可靠运行，就认定是高质量的产品。用户对质量的看法：功能是否齐全；可靠性；易用性；文档齐套性；产品外观（包装(bozhung)、界面等）；售前售后技术支持程度；等等。第100页/共116页第一百页，共117页。2024/7/26101质量(zhling)和可靠性可靠性只是质量(zhling)的一个方面。第101页/共116页第一百零一页，共
51、117页。2024/7/26102QC和QA质量控制验证产品的正确性，当发现与设计不一致的时候进行( jnxng)纠正。质量保证充当支持执行全面质量管理的角色第102页/共116页第一百零二页，共117页。2024/7/26103测试(csh)和QA软件测试员（QC）：检测软件产品找出缺陷，评价软件质量质量保证人员（QA）：检测软件过程创建和加强(jiqing)促进软件开发并防止软件缺陷的标准、方法和过程。第103页/共116页第一百零三页，共117页。2024/7/26104测试(csh)和QA在小型软件(run jin)公司，可能QA和QC的工作交织在一起，人员交叉和兼任的情况比较普遍。大
52、公司，有专门的测试部门和质量部门，有专职的测试人员和质量人员。第104页/共116页第一百零四页，共117页。2024/7/261053.9其它(qt)v软件(run jin)的可测试性v测试用例第105页/共116页第一百零五页，共117页。2024/7/26106软件(runjin)的可测试性可操作性。运行得越好，测试的效率就越高没有影响操作的错误没有阻碍测试执行的错误允许开发和测试并行可观察性。你所看见的就是你所测试的一个输入对应一个输出系统状态和变量可见(kjin)历史状态可观察或查询所有影响输出的因素都可见(kjin)源代码第106页/共116页第一百零六页，共117页。2024/7
53、/26107软件(runjin)的可测试性可控制性。控制越好，测试越能够自动化和优化所有可能的输出都产生于某种输入或输入组合系统状态和变量直接可控可分解性。模块化各模块可独立测试简单(jindn)性。需要测试的内容越少，测试就越快功能简单(jindn)性结构简单(jindn)性代码简单(jindn)性第107页/共116页第一百零七页，共117页。2024/7/26108稳定性。变更越少，对测试的影响就越小不经常( jngchng)变更变更是可控的易理解性。得到的信息越多，对测试越有利设计能够被很好地理解技术文档资料丰富文档组织合理文档描述准确清晰软件(runjin)的可测试性第108页/共1
54、16页第一百零八页，共117页。2024/7/26109软件测试完成(wn chng)(wn chng)准则使用了特定的测试用例设计方法查出了预定数目的错误错误强度曲线下降到预定的水平达到测试计划中所规定的完备(wnbi)性其它标准第109页/共116页第一百零九页，共117页。2024/7/26110测试用例设计(shj)(shj)所谓测试用例，是一份关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。测试用例可以是纯文本的说明文档，也可以是用脚本语言或高级语言编写的一段代码。测试用例应当包括测试标识、测试用例名称、目标、测试条件、测试
55、设置、输入数据要求(yoqi)、步骤、以及预期的结果等第110页/共116页第一百一十页，共117页。2024/7/26111优秀(yuxi)(yuxi)测试用例的特点发现错误的可能性大。这要求测试者要理解软件，并尝试设想软件如何才能失败好的测试用例并不冗余(rn y)。每一个测试都应该有不同的用途好的测试应该是“最佳品种”。在一组目的相似的测试用例中，时间和资源的限制可能只影响其中某个子集的执行好的测试用例既不会太简单，也不会太复杂好的测试用例应该是可维护的第111页/共116页第一百一十一页，共117页。2024/7/26112测试用例的设计(shj)(shj)方法若被测程序与特定的功能相
56、联系，我们可以(ky)针对功能设计测试，以证实各功能完全可执行，同时在功能中寻找错误黑盒法。篇若被测程序与特定的结构相联系，我们可以(ky)针对结构设计测试，以确保内部的“所有齿轮相吻合”，即软件的内部操作是遵照规定执行的，且所有的构件被充分利用白盒法第112页/共116页第一百一十二页，共117页。2024/7/26113小结(xioji)截止到目前(mqin)，学习了软件过程和软件测试的一些基础知识，了解了测试人员的角色，定位。下一部分，讲软件测试的基本技术。第113页/共116页第一百一十三页，共117页。2024/7/26114欢迎提问(twn)和讨论第114页/共116页第一百一十四
57、页，共117页。2024/7/26115谢谢 谢谢 ！第115页/共116页第一百一十五页，共117页。2024/7/26116感谢您的欣赏(xnshng)！第116页/共116页第一百一十六页，共117页。内容(nirng)总结11月-21。测试活动贯穿于软件(run jin)活动中的所有阶段。+,-,*./各种算法组合。软件(run jin)会对相同类型的测试会产生“免疫力”。(开发小组VS.测试小组)。小功能，小改进。所有测试活动都应该是有计划的，并且计划能够得到保障。软件(run jin)测试应遵循Parito法则（二八法则）。独立测试是指软件(run jin)测试工作由在经济上和管理上独立于开发机构的组织进行。一般项目：项目总投入的30%40%。高可靠性和高安全性项目：项目其它投入的35倍第一百一十七页，共117页。
