Ch3软件测试基础知识

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

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

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

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

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

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

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

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

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

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

11、18/202227软件测试的致命缺陷测试的不完全、不彻底性。由于任何软件只能进行有限的测试，发现了错误说明软件有问题；未发现错误不能说明软件没有问题。8/18/202228对测试的正确认识软件测试不是解决软件质量问题的唯一方法；软件测试不能取代其他的质量保证手段；软件测试不能保证发现软件中的所有错误，完全的测试是不现实的；软件测试是巨大的效益和艰苦的工作并存，测试的组织和管理就是在其中取得平衡。8/18/202229软件测试的重要性项目持续时间 延迟上市测试人员测试人员100%50%0%完成比率代码实现消除缺陷质量问题维护的费用1x 10 x 100 x 问题发现得越早，解决的代价就越小8/1

12、8/202230项目持续时间 100%50%0%完成比率消除缺陷消除缺陷保证软件质量缩短上市时间Close the Quality Gap软件测试重要性Close the Quality Gap So We Can Release Working Software on time8/18/202231系统性能应用性能功能可靠性100%软件测试重要性8/18/202232风险代码完成可靠性功能应用性能系统性能风险越早测试越好自动的测试测试每一个版本 传统的测试是在代码实现之后进行 软件测试重要性8/18/202233一个好的软件工程的守则软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开

13、发的“实现阶段”才开始的，在此之前的“可行性研究与计划阶段”，“需求分析阶段”，“概要设计阶段”，和“详细设计阶段”，都必须有切实的手段与措施对开发结果进行检验，以保证阶段的正确完成8/18/202234测试的重要性测试是软件生存周期中一个独立的、关键的阶段，是保证软件质量的重要手段，也是软件质量保证的最后一个环节。测试活动贯穿于软件活动中的所有阶段。 从需求阶段高层设计低层设计编码阶段单元测试集成测试系统测试验收测试测试越早开始，故障越早被发现，消除故障的成本越少。8/18/202235内容概要：序言软件测试定义软件测试目的对软件测试的认识软件测试理论软件测试原则软件测试的分类软件测试的术语

14、和定义其它8/18/2022363.5软件测试理论 后面总结了9条软件测试的基本原理，是软件测试和软件开发的“交通规则”、“生活法则”。理解它们有助于透彻了解软件过程。8/18/202237 Parito法则 一般情况下，在分析、设计、实现阶段的复审和测试工作只能够发现和避免80%的Bug，而系统测试也只能找出其余Bug中的80%，最后剩余的Bug只有在用户的大范围、长时间使用后才有可能会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。 也称80-20理论。8/18/202238木桶理论在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设

15、计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。木桶理论就是要强调改进我们木板最短的那一块.只有短木板变为长木板,桶装水才会更多。8/18/202239测试不能证明软件无错 软件测试的不完全、不彻底性。测试无法显示潜伏的软件缺陷。 由于任何程序只能进行有限的测试，在发现错误时能说明程序有问题；但在测试未发现错误时，不能说明程序中没有错误。8/18/202240完全测试软件是不

16、可能的主要原因：输入量太大输出结果太多软件实现的途径太多软件需求规格说明书没有客观标准。“太多”的可能性加在一起，致使测试条件难以确定。8/18/202241完全测试软件是不可能的例如：WinX操作系统带的计算器程序。单个数据、多个数据的组合；+,-,*./各种算法组合；正常、异常情况组合输入组合无穷多，无法完全测试。注：如果觉得某些测试条件是重复的或者无必要的而将其剔除，那么就不能称作完全测试。8/18/202242软件测试是有风险的行为 如果决定不去测试所有的情况，那就是选择了风险。（泄漏故障的可能性）（碰巧在某个特定的输入组合下软件留有缺陷）如何把无边无际的输入可能减少到可以控制的范围？

17、去粗存精，减小风险。8/18/202243测试量和发现的软件缺陷数量之间的关系8/18/202244软件测试是有风险的行为 由上图，随着测试工作量的增加，费用增加，遗漏软件缺陷数目减少。最佳平衡点在哪？找到了它，就找到了最合适的测试工作量。8/18/202245测试无法显示潜伏的软件缺陷 软件测试工作可以报告已发现的软件缺陷；却不能保证软件缺陷全部找到；也不知道还有多少潜伏的软件缺陷。继续测试，可能还会找到一些。8/18/202246程序中存在错误的概率与该程序中已发现的错误数成比例。 软件缺陷的“群集”现象， 80%的错误存在于20%的代码中。原因：程序员疲倦。一个软件缺陷很可能是附近有更多

18、的软件缺陷的征兆。程序员易犯同样的错误。个人偏好。多个软件缺陷相互关联，甚至是由同一个原因造成的。缺陷的“传递”和“放大”。8/18/202247程序中存在错误的概率与该程序中已发现的错误数成比例。 找到软件缺陷越多的模块，遗留的软件缺陷越多。如果某软件无论如何也找不出软件缺陷，也可能是软件经过精心编制，确实存在极少的软件缺陷。8/18/202248软件缺陷的免疫力 软件会对相同类型的测试会产生“免疫力”。(开发小组VS.测试小组)。经过几轮的测试，该发现的错误都被发现了，再测试下去也不会有新的发现了。农药杀虫剂怪事。解决：不断编写新的测试用例，采用新的测试程序，对程序的不同部分进行测试，以找

19、出更多的软件缺陷。8/18/202249并非所有软件缺陷都能修复 项目组需要对每一个软件缺陷进行评估和取舍，根据风险和成本决定哪些必须修复，哪些不用修复，哪些可以延期修复。通常有CCB会议决定。CCB由软件项目各方代表组成。8/18/202250并非所有软件缺陷都能修复 不需要修复的软件缺陷的原因：没有足够的时间。不算是真正的软件缺陷。小功能，小改进。修复的风险太大。技术难度，引入新的缺陷，不值得修复。商业风险（intel奔腾浮点数运算缺陷）8/18/202251相互关系不可能进行完全的测试。由于1，测试是有风险的，即测试会遗漏软件缺陷。由于2，测试不能证明程序无措，而仅能证明程序有错。由于1

20、，2，3，测试发现的错误越多，则说明软件的错误越多。错误密度大，遗漏的也多。基础概念 8/18/202252内容概要：序言软件测试定义软件测试目的对软件测试的认识软件测试理论软件测试原则软件测试的分类软件测试的术语和定义其它8/18/2022533.6软件测试的基本原则 基于上述的测试理论，下面列举一些测试原则，它们是软件测试工作中常用的策略。它们建立在实践的基础上。8/18/202254测试的基本原则(一)所有的测试都应追溯到用户需求 产品最终是为了给用户使用，对用户来说，最严重的错误是那些导致程序不能够满足他们的需求的错误，所以测试应该从用户的角度来测试产品。 事实上，需求是驱动整个研发过

21、程的源头，不仅仅设计、开发要需求 驱动，测试更是要需求驱动。 实际的做法：测试设计依据需求设计，并建立需求追踪矩阵，测试活动按照测试设计进行。测试人员把握用户真实的需求，不仅仅做验证工作，也要做确认工作。8/18/202255测试的基本原则(二)所有测试活动都应该是有计划的，并且计划能够得到保障。 严格执行测试计划,排除测试的随意性。要坚决反对无计划、无明确目的、随意的测试活动；反对过程不可重复的即兴测试。 测试计划应在需求一确定或需求模型一完成就开始，总之要在代码产生之前就开始。测试计划包括日程计划、资源计划、方案设计、测试用例设计等。 现实工作中，常见的问题就是测试无计划或计划性不强、随意

22、更改测试计划、迫于市场压力压缩测试计划等。8/18/202256测试的基本原则(三) Good-enough原则 测试要权衡投入产出比，即要充分也不要过分。不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。 过分测试指无意义的重复测试和需要消耗过大投入的非关键性测试。 困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。8/18/202257测试的基本原则(三续) 答案： 制定最低测试通过标准和测试内容，然后具体问题具体分析。 持续地对测试过程进行度量，对测试和测试结果评价，在保证充分性的前提下去除冗余测试，确保测试过程的有效性。 然而，实际测试工作

23、中，我们很少去关注这方面的数据。 对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。 寻求合适的测试策略，在质量和成本之间寻求合适的平衡点。8/18/202258测试的基本原则(四)软件测试应遵循Parito法则（二八法则）。 二八法则最初来源于社会经济现象研究结果，也同样适用于软件测试领域。 80的故障存在于20的代码中； 80的故障归因于20的故障原因； 关注测试中的群集现象；关注发现缺陷较多的代码。 掌握这一法则有助于我们在测试过程中抓住重点，有针对性，做到事半功倍。8/18/202259测试的基本原则(五)尽早地和不断地进行软件测试在软件生命

24、周期中，越早发现软件故障，修复它所花费的费用越少，造成的损失越小。软件开发全过程进行测试，力争在本阶段发现和修正错误。8/18/202260测试的基本原则(六)测试应由小到大，从小规模到大规模。 测试的粒度和范围应该由小到大，最初的测试应该把焦点放在单个程序模块上，也就是单元测试，然后是多个模块的集成（集成测试），最后是全系统测试（系统测试）。 现状是缺乏小粒度的测试，所以即使系统测试投入足够的资源和时间也难以将产品质量提高到一个新的层次。 8/18/202261测试的基本原则(七)穷举测试是不可能的，充分覆盖程序逻辑是有可能的。 真实运行情况下，产品将运行于不同的环境和条件下。特别是对于复杂

25、软件，做到穷举测试是不可能的。 但是我们应该提高测试的覆盖率，保证程序的每一个逻辑判断分支可以测试到。 正是因为不能穷举测试，所以软件总会遗留（潜在的）缺陷，所以测试覆盖率提高是测试永恒的追究目标。 因穷举测试是不可行的。为了节省时间和资源，就必须从数量极大的可用测试案例中精心地挑选出少量的具有代表性测试案例（采用这些测试案例是最佳平衡点）；并在测试执行过程中严格按测试计划执行，才能达到最佳的测试效果。8/18/202262测试的基本原则(八)程序员避免测试自己的程序。开发者被指定测试自己的代码是一件很糟糕的事。开发是创造或者建立什么东西的行为，一个模块或者整个系统。而测试的唯一目的是证明一个

26、模块或者系统工作不正常。这两个活动之间有着本质的矛盾。一个人不太可能把两个截然对立的角色都扮演的很好。 基于这个想法，应该限制开发者在测试中的参与。给他们比较合适的任务是进行有可能的最低层的测试-单元测试。8/18/202263程序员避免测试自己的程序 原因1：心理学因素 当一个程序员在完成了设计，编写程序的建设性工作后，要一夜之间突然改变他的观点，设法对程序形成一个完全否定的态度，那是非常困难的。大部分程序员都由于不能使自己进入必要的精神状态（不是抱着要揭露出自己程序中错误的态度），因而不能有效地测试自己的程序。 心理作用：对自己的程序“偏心” ,不愿否定自己写的程序（特殊感情）。可以把测试

27、看做是对一篇论文或本书作校对，或与写评论相类似的工作。正如许多作者所知，校对或批评自己的著作是非常困难的。也就是说，在自已的工作中找出缺陷往往是人的心理状态所不容忍的。 8/18/202264程序员避免测试自己的程序 原因2：思路受局限难以发现功能理解错误。 程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当程序员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。8/18/202265声明 以上看法并不意味着程序员不可能测试自已的程序。不过相比之下如果由另外些人来进行程序测试，就会更有效、更成功。注意：这个论断并不适用于纠错（改正已知错误），由原来程序的作

28、者纠错肯定效率更高。 8/18/202266测试的基本原则(九)为了达到最佳效果，应由独立于开发的专门测试人员来构造测试。 全面的独立第三方测试对测试的效果有保障（后面详细介绍），但需要在测试的人力和设备上有较大投入。如微软的测试，在开发Exchange 2000时测试人员和开发人员的比例是2.5:1,在开发Win2000时，测试人员和开发人员的比例是1.9:1。 我们的实际情况目前难以做到这样的投入。8/18/202267软件测试的其它原则 分派有经验、富有创造性的人员承担测试。 不能为了便于测试擅自修改程序。既测试软件应该做的也检查软件不该做的。既测试有效的和期望的输入也测试无效的和不期望

29、的输入。8/18/202268“好的”测试的基本特征具有高的发现错误的概率没有冗余测试测试是“最佳类别”既不太简单也不太复杂8/18/202269谁来完成测试1、开发者测试2、对等测试3、独立测试小组4、独立测试机构8/18/202270独立测试的好处独立测试是指软件测试工作由在经济上和管理上独立于开发机构的组织进行。软件测试由独立测试机构承担有许多好处。独立测试可以避免软件开发者测试自己开发的软件。由于心理学上的问题，软件开发者难以客观、有效地测试自己的软件，而找出那些因为对问题的误解而产生的错误就更加困难。 8/18/202271独立测试的好处独立测试还可以避免软件开发机构测试自己的软件。

30、软件产品的开发过程受到时间、成本和质量三者的制约，时间和成本指标便于衡量，而质量却很难度量，因此在软件开发过程中，当时间、成本和质量三者发生矛盾时，质量最容易被忽视。如果测试组织与开发组织来自相同的机构，测试过程就会面临来自与开发组织同一来源的管理方面的压力，使测试过程受到干扰。 8/18/202272独立测试的好处采用独立测试方式，无论在技术上还是管理上，对提高软件测试的有效性都具有重要意义 。、客观性对软件测试和软件中的错误抱着客观的态度，这种客观的态度可以解决测试中的心理学问题，既能够以揭露软件中错误的态度工作，也能不受发现的错误的影响。经济上的独立性使其工作有更充分的条件按测试要求去完

31、成。8/18/202273独立测试的好处、专业性独立测试作为一种专业工作，在长期的工作过程中势必能够积累大量实践经验，形成自己的专业优势。同时软件测试也是技术含量很高的工作，需要有专业队伍加以研究，并进行工程实践。专业化分工是提高测试水平，保证测试质量，充分发挥测试效用的必然途径。 8/18/202274独立测试的好处、权威性由于专业优势，独立测试工作形成的测试结果更具信服力，而测试结果常常和对软件的质量评价联系在一起，由专业化的独立测试机构的评价，更客观、公正和具有权威性。 8/18/202275独立测试的好处、资源有保证独立测试机构的主要任务是进行独立测试工作，这使得测试工作在经费、人力和

32、计划方面更有保证，不会因为开发的压力减少对测试的投入，降低测试的有效性，可以避免开发单位侧重软件开发而对测试工作产生不利的影响。 8/18/202276典型项目的软件测试投入(IBM)一般项目：项目总投入的30%40%高可靠性和高安全性项目：项目其它投入的35倍8/18/202277典型项目的人工统计(HP)8/18/202278内容概要：序言软件测试定义软件测试目的对软件测试的认识软件测试理论软件测试原则软件测试的分类软件测试的术语和定义其它8/18/2022793.7软件测试分类不同的分类方法，得出不同的分类。8/18/202280软件测试的分类(一)按测试对象分文档测试 包括用户需求文档

33、、软件需求文档、系统设计文档、用户手册等。代码测试版本测试 对代码集成、编译后的软件运行版本的测试。8/18/202281软件测试的分类(二)按测试对象的粒度分单元测试集成测试系统测试确认测试 如验收测试就是典型的确认测试。8/18/202282软件测试的分类(三)按测试方法分白盒测试 白盒测试又叫结构测试。已知软件的内部工作过程，通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经通过检查。黑盒测试 黑盒又叫做功能测试。已知软件的功能设计规格，进行测试证明每个实现了的功能是否符合要求，它不仅用于开发阶段的测试，更重要的是用于产品的测试阶段及维护阶段。灰盒测试 白盒测试和黑盒测试

34、方法的结合运用。目前最常用的测试方法。8/18/202283软件测试的分类(四)按测试执行方法分人工测试自动测试 由工具实现自动的测试运行、记录测试值并和设定的期望值进行比较，自动输出测试结果和测试报告。半自动测试 借助一定的工具辅助手工测试，或者对自动测试进行人工干预。 8/18/202284软件测试的分类(五)按运行状态分动态测试 动态测试就是通过选择适当的测试用例，实际运行测试程序，比较运行结果，动态测试能使所测程序有控制地运行，自动地监视、记录、统计程序的运行情况。 动态测试更具真实性，但是动态测试必须生成测试数据来运行程序，开展测试工作费时费力，动态测试中涉及多方面工作，要求有完善的

35、管理和工作流程。静态测试 静态测试是指静态分析程序。静态测试不需要执行所测试的程序，它扫描所测试程序的正文，对程序的数据流和控制流进行分析，然后提出测试报告。 代码走查可以看作是一种静态测试。静态测试可以使用一些辅助工具如：PCLint、Logiscope 、CodeWizard8/18/202285软件测试的分类(六) 按测试执行者分开发人员自测测试人员测试第三方测试机构测试验收测试用户测试 8/18/202286软件测试的分类(七)按被测对象技术领域分系统平台类软件测试数据库软件测试工具软件测试应用软件测试不同领域的软件对测试的要求也不一样，如系统平台类软件关注系统的稳定性和健壮性，数据库

36、软件关注数据处理的性能和流量，工具类软件关注易用性等。8/18/202287软件测试的分类(八)按测试内容分功能测试性能测试 性能测试用来衡量系统的响应时间、事务处理速度和其它时间敏感的需求。并能测出与性能相关的工作负载和硬件配置条件等。界面测试压力测试 可找出由于资源不足或资源竞争引起的错误，在较少的内存和磁盘空间状态下可能会暴露常态下不易发现的问题。安全性测试8/18/202288软件测试的分类(八)（续）安装测试 确保软件在各种条件下能正确安装，包括初次安装、升级、完全安装和客户定制安装。以及检查软件安装之后操作的正确性。配置测试 检查测试应用在不同的软硬件配置状态下的操作。大多数情况下

37、，不同的客户工作站、网络、数据库服务器配置具备不同的性能，甚至系统性能随软件配置的变化而不同。恢复性测试（容错测试）兼容性测试等等8/18/202289软件测试的分类(九)按测试范围分验证测试 仅仅验证变更的修改是否达到了预期目的。通常会对修改做变更波及分析，但不会重新执行所有的测试用例。完整测试：执行所有的测试用例。回归测试 测试范围介于前两者之间。其测试范围通常是：前一次执行未通过的测试用例；变更波及分析后预计受影响的测试用例；因变更修改而新增的测试用例；部分前一次执行通过的测试用例；部分很长一段时间没有执行过的测试用例。8/18/202290软件测试的分类(九)还有：冒烟测试 进行检验系

38、统是否能够正常上电运行，是否提供最基本的业务功能。BVT（Basic Verify Test）测试 BVT测试是测试的最基本要求，也是最先进行的测试。基准测试 Benchmark Test： 和其它相似产品的质量比较 和给定的/设计的质量指标比较 和政府发布的标准/公布的行业数据比较8/18/2022913.8软件测试的术语和定义不要：混淆误用理解：含义差别8/18/202292准确和精确举例：飞镖靶盘（图）既不准确又不精确精确但不准确准确但不精确既准确又精确8/18/202293既不准确又不精确8/18/202294精确但不准确8/18/202295准确但不精确8/18/202296既准确又

39、精确8/18/202297Verification&ValidationVerification: do the things rightValidation: do the right things.8/18/202298验证与确认验证(verification)为确定某一开发阶段的产品是否满足在该阶段开始时提出的要求的评估过程。一般采用静态测试的方式(不基于程序的运行)。通过检查并收集客观的证据来确定特定的需求得到满足。验证对象包括所有选定的需求，包括客户的、产品的以及产品部件的需求，对产品和中间工作产品进行验证。验证是一个渐进的过程。8/18/202299验证与确认确认(Validati

40、on)为确定系统或部件是否满足需求的评估过程。一般采用动态测试的方式(基于程序的运行)。通过检查并收集客观的证据来确定针对某种特定需求在提供时满足预期的使用。确认活动适用于产品在其诸如运行、培训、制造、维护、以及支持服务等任何预期环境中的任何方面。确认活动即可以用于工作产品，也可以用于产品或产品部件。确认活动常常需要用户的参与。8/18/2022100验证与确认验证：构造的产品正确吗？- 评审确认：是否构造了正确的产品？- 测试8/18/2022101质量和可靠性错误观点：软件一直稳定、可靠运行，就认定是高质量的产品。用户对质量的看法：功能是否齐全；可靠性；易用性；文档齐套性；产品外观（包装、界面等）；售前售后技术支持程