软件测试基础理论知识.docx
《软件测试基础理论知识.docx》由会员分享，可在线阅读，更多相关《软件测试基础理论知识.docx（41页珍藏版）》请在冰豆网上搜索。
软件测试基础理论知识
一、软件测试概论
一.1基础概念
【定义】
软件测试是使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度、完全度和质量的软件过程。
【内容】
软件测试主要工作内容是验证（verification）和确认（validation）。
验证是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。
（Dotherightthing）
确认是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。
即保证软件以正确的方式来做了这个事件（Doitright）
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。
【目的】
软件测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
软件测试的出发点就是质量，软件测试的一切工作应该围绕质量而开展，测试是保证质量的重要手段之一，测试本身就是为质量服务的。
【原则】
（1）测试的标准是用户的需求
所有的软件测试都应追溯到用户需求，测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
（2）事先定义好产品的质量标准
有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。
同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
（3）应当“尽早地和不断地进行软件测试”作为测试者的座右铭
在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%。
，缺陷存在放大趋势。
如需求阶段的一个错误可能会导致N个设计错误，因此，越是测试后期，为修复缺陷所付出的代价就会越大。
（4）制定测试计划，排除随意性
在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。
测试计划应包括：
所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等以及评价标准。
（5）周密的测试用例，不可将测试用例抛开
要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
（6）充分注意群集现象
抓住80/20原则可以有针对性的优化测试，在最短的时间内发现更多的问题，同时也能保证测试者对测试过程的整体把握。
特别是当项目时间紧、复杂度高时，可以分时间、阶段、模块解决问题，是有效的解决问题的方式之一。
（7）避免测试自己的程序
由于心理因素，人们潜意识都不希望找到自己的错误。
基于这种思维定势，人们难于发现自己的错误。
因此，软件开发者应尽量避免测试自己的产品，应由第三方来进行测试，当然开发者需要在交付之前进行相关的自测。
一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效。
但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷。
在软件开发的早期，开发人员对自己的工作产品进行认真的测试，这也是开发人员的一个职责之一。
（8）完全测试是不可能的，测试需要终止
穷尽测试是不可能的，应结合当前实际情况当满足一定的测试出口准则时测试就应当终止。
（9）回归测试
修改程序后，应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
（10）妥善保存一切测试过程文档
一.2软件测试要素
（11）质量：
软件质量是软件测试的目标，也是软件测试工作的中心，一切从质量出发，也就是一切从客户需求出发。
任何违背质量的东西都是问题，测试就是要找出这些问题。
（12）人员：
人是决定的因素，测试人员的态度、素质、能力决定着测试的效果，对测试产品的质量也有很大的影响。
测试人员因素包括测试组织结构、角色和责任的定义。
（13）技术：
软件测试技术，包括方法、工具。
（14）资源：
主要是指测试环境中所需要的硬件设备、网络环境，甚至包括测试数据。
另外一个重要因素就是测试时间，时间也是测试的资源，但测试人员不能看做资源，每个人的能力千差万别，不同的测试人员担任不同的角色，不能相互代替。
这也是软件图书的经典之作——《人件》的作者反对将人作为资源对待的原因。
（15）流程：
从测试计划和测试用例的创建、评审到测试的执行、报告，设定每个阶段的进出标准。
一.3软件测试与质量保证
一.3.1软件质量
软件产品质量评价国际标准ISO14598把软件质量定义为：
软件特性的总和，软件满足规定或潜在用户需求的能力。
上述定义反应如下3个方面的问题：
（16）软件需求是度量软件质量的基础；
（17）软件人员必须遵循软件过程的规范；
（18）如果软件只是满足规定的需求，而不能满足可能存在的隐含需求，软件质量也不能保证。
一.3.2软件测试与软件质量保证的区别
软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作。
质量保证是通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产物；软件测试是通过执行软件来对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量。
具体说来，软件测试盒软件质量保证的区别体现在：
从性质上看，软件测试属于技术性工作，而软件质量保证属于管理性工作；从对象上看，软件测试的对象是软件产品，而质量保证的对象是整个软件过程，覆盖公司层面的各个领域；从手段上看，软件测试以事后检验为主，而软件质量保证则强调缺陷的预防。
质量不是测试人员测试出来的，糟糕的早期设计结合最优的后期质量保证往往颇费力气，仍然打造不出用户满意度高的产品。
二、软件测试过程管理
二.1测试团队
二.1.1测试团队的基本责任
（19）发现软件程序、系统或产品中所有的问题
（20）尽早地发现问题
（21）督促和协助开发人员尽快地解决程序中的缺陷
（22）帮助项目管理人员制定合理的开发计划
（23）对缺陷进行跟踪、分析和分类总结，以便让项目的管理人员和相关的负责人员能够及时、清楚地了解产品当前的质量状态
（24）帮助改善开发流程、调高产品开发效率
（25）促进程序编写的规范性、易读性、可维护性等
二.1.2测试团队的组成
如何组织一个测试团队，应当视企业的人力资源而定。
一般，一个比较健全的测试组，所具有的角色包括测试组长、实验室管理人员、自动化测试工程师、资深测试工程师、初级测试工程师。
测试组长：
业务专家，负责项目的管理、测试计划的制定、项目文档的审查、测试用例的设计和审查、任务的安排、与项目经理和开发组长的沟通等
实验室管理人员：
设置、配置和维护实验室的测试环境，主要是服务器和网络环境等
资深测试工程师：
负责产品设计规格说明书的审查、测试用例的设计和技术难题的解决，主要参与数据库、系统性能和安全性等技术难度较高的测试
自动化测试工程师：
负责测试工具的开发、测试脚本的开发等
初级测试工程师：
执行测试用例和相关的测试任务，侧重功能测试用例的设计和执行
二.1.3软件测试团队与开发团队的关系
软件测试与软件开发具有天然的联系。
软件测试的输入是软件开发的产品，测试输出的结果需要开发人员相应处理，处理后的结果再次需要测试人员的验证。
因此，软件测试与软件开发如影相随，互为服务对象。
开发人员和测试人员需要不断的沟通合作，才能持续优化项目。
对于开发人员而言，利用测试人员对需求的理解，越早将测试提到项目周期，帮助就越大；对于测试人员而言，搞好和开发人员的关系，则可以在测试方向上获得更多的帮助：
编写测试用例时询问可能遗漏的用例，在测试即将结束时询问测试是否有风险。
二.2软件测试风险分析
（26）风险类型
项目风险：
指潜在的预算、进度、人力、资源、客户、需求等方面的问题，以及它们对软件项目的影响
技术风险：
指潜在的设计、实现、接口、验证和维护等方面的问题
商业风险：
商业风险威胁到要开发软件的生存能力
（27）识别风险
识别风险是试图系统化地确定对项目计划的威胁，识别风险的一个方法是建立风险条目检查表，检查表包括：
产品规模：
与要建造或要修改的软件的总体规模相关的风险
商业影响：
与管理或市场所加诸的约束相关的风险
客户特性：
与客户的素质以及开发者和客户定期通信的能力相关的风险
过程定义：
与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险
开发环境：
与用以建造产品的工具的可用性及质量相关的风险
建造的技术：
与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险
人员数目及经验：
与参与工作的软件工程师的总体技术水平及项目经验相关的风险
（28）评估风险影响
风险的性质：
当风险发生时可能产生的问题
风险的范围：
结合了严重性及整体分布情况
风险的时间：
主要考虑何时能够感到风险，风险会持续多长时间
（29）风险应对
风险分析活动的目的是辅助项目组建立处理风险的策略，一个有效的策略必须考虑如下3各问题：
风险避免
风险监控
风险管理及意外事件计划
二.3软件测试成本管理
【测试费用有效性】
测试的策略由商业的经济利益来决定，对风险测试过少，会造成软件的缺陷和系统的瘫痪，测试的过多，会增加测试成本。
下图的测试费用-质量曲线可以形象的表示测试费用的有效性：
【测试成本】
测试实施成本：
测试准备成本、测试执行成本、测试结束成本
【缺陷探测率】
缺陷探测率DDP是另一个衡量测试工作效率的软件质量成本的指标。
缺陷探测率DDP＝Bugs（tester）/（Bugs（tester）+Bugs（customer））
缺陷探测率越高，也就是测试者发现的错误多，发布后客户发现的错误就越少，降低了外部故障不一致成本，达到节约总成本的目的，可获得较高的测试投资回报率。
三、测试流程
三.1测试过程
软件测试过程一般包括:
测试计划、测试设计、测试准备、测试执行、测试评估和缺陷跟踪等阶段，每个阶段都有一系列的任务。
测试过程具有以下几个特点：
（30）测试工作开始于需求分析之后；
（31）测试经过评估后，达到了结束的标准后才能结束；
（32）测试也是迭代过程；
（33）测试需求来自于软件需求；
（34）测试过程与开发过程的关系；
（35）都是软件过程的有机组成部分；
（36）测试过程与开发过程同步进行；
（37）测试过程与开发过程相互依赖，又相互独立；
（38）开发过程、测试过程、项目管理过程以及其他支撑过程相互交织共同组成了软件过程。
三.2测试过程的常见模型
三.2.1V模型
映出了测试活动与分析设计活动的关系。
从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。
三.2.2W模型
W模型强调：
测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。
W模型有利于尽早地全面的发现问题。
但W模型也存在局限性。
在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
这样就无法支持迭代的开发模型。
三.2.3H模型
H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
测试准备和测试执行分离，有利于资源调配，降低成本，调高效率。
有组织、结构化的独立流程，有助于跟踪测试投入的流向。
H模型还充分体现了测试过程（不是技术）的复杂性。
四、测试技术
四.1软件测试类型
四.1.1按测试阶段划分
【单元测试】
（39）定义：
又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试
（40）目的：
发现模块内部可能存在的各种差错
（41）内容：
模块接口测试（IO测试，数据的流入流出）、局部数据结构测试、路径测试、错误处理测试、边界测试。
（42）步骤：
利用设计文档设计测试用例；创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试
【集成测试】
（43）定义：
又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装
（44）目的：
发现模块连接中的接口可能存在的各种差错
（45）内容：
穿越模块之间的数据是否会丢失；
一个模块组装后是否会对另一模块或其他模块存在影响；
各个子功能组装在一起是否会达到预期的父功能；
全局数据结构是否有问题；
单个模块的错误累积起来是否会放在
（46）组装方法：
包括一次性组装方式、增殖式组装方式两种组装方法
（47）完成标志：
成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审
【确认测试】
（48）目的：
验证软件的功能和性能及其他特性是否与用户的要求一致
（49）测试内容：
验证所测软件是否满足需求规格说明书列出的需求；所有文档正确且便于使用；软件可移植性、易用性、兼容性进行测试；软件配置复查；保证软件配置的所有成分都齐全
【系统测试】
（50）目的：
验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试
（51）测试内容：
在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（硬件设备、网络、系统软件）正确配置、连接，满足用户需求
【验收测试】
（52）测试目的：
在用户环境中进行测试，以确定系统和产品是否能够满足合同或用户所规定的需求
（53）测试内容：
根据任务书或合迥、供需双方约定的验收依据文档进行对整个系统的测试与评审，确认是否接收或拒绝系统
四.1.2按测试实施组织划分
【产商测试】
开发方测试通常也叫“验收测试”或“a测试”，在软件开发环境中，开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。
【用户测试】
在用户的应用环境下，用户检测与核实软件实现是否符合自己预期的要求。
β测试通常被认为是用户测试，把软件有计划地免费地分发到目标市场，让用户大量使用、评价检查软件。
【第三方测试】
由第三方测试机构来进行的测试，也称独立测试。
四.1.3按测试方法划分
【静态测试】
静态测试又称为静态分析技术，不执行被测试软件，对需求分析说明书、软件设计说明书、源程序做结构检测、流图分析、符号执行等找出软件的错误。
【动态测试】
通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程。
四.1.4按测试技术划分
【白盒测试】
白盒测试也称为结构测试或逻辑驱动测试，是通过对程序内部结构的分析、检测来寻找问题，检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定正常进行。
【黑盒测试】
黑盒测试又称功能测试，通过运行程序发现其缺陷和错误。
黑盒测试是对程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息的完整性。
【灰盒测试】
介于白盒和黑盒测试之间，关注输出对于输入的正确性，也关注程序的内部结构，但没有白盒测试那样详细、完整。
四.2白盒测试
四.2.1白盒测试方法
四.2.1.1代码检查法
【检查内容】
代码检查包括桌面检查，代码审查和走查等方式，主要对以下内容进行检查：
检查代码和设计的一致性
代码对标准的遵循、可读性
代码逻辑表达的正确性
代码结构的合理性
程序编写与编写标准的符合性
程序中不安全、不明确和模糊的部分
编程风格问题等
【检查方式】
（54）桌面检查：
由程序员对源程序代码进行分析、检验，并补充相关的文档，发现程序中的错误。
（55）代码审查：
由程序员和测试员组成的审查小组通过阅读、讨论和争议，以程序进行静态分析的过程。
（56）走查：
程序员和测试员组成的审查小组通过逻辑运行程序，发现问题。
【检查项目】
检查变量的交叉引用表：
检查未说明的变量和违反了类型规定的变量，变量的引用和使用情况
检查标号的交叉引用表：
验证所有标号的正确性
检查子程序、宏、函数：
验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致
等价性检查：
检查全部等价变量的类型的一致性
常量检查：
确认常量的取值和数制、数据类型
标准检查：
检查程序中是否违反标准的问题
风格检查：
检查程序的设计风格
比较控制流：
比较设计控制流图和实际程序生成的控制流图的差异
选择、激活路径：
在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错
对照程序的规格说明，详细阅读源代码，比较实际的代码，从差异中发现程序的问题和错误
四.2.1.2静态结构分析法
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表，检查软件有没有存在缺陷或错误。
主要包括控制流分析、数据据流分析、接口分析、表达式分析。
四.2.1.3代码质量度量法
代码质量度量法即根据ISO9126质量模型的6个方面（即功能性、可靠性、易使用性、效率、可维护性、可移植性）对软件进行的动态测试方法。
白盒测试的动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
动态测试通常在静态测试之后进行。
白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
保证每个模块的所有独立路径至少被使用一次
对所有的逻辑值均测试true和false
上下边界及可操作范围内运行所有循环
检查内部数据结构以确保其有效性
四.2.2白盒测试综合策略
（57）在测试中，首先尽量使用测试工具进行静态结构分析
（58）采用先静态后动态的组合方式，先进行静态结构分析，代码检查和静态质量度量，然后现进行覆盖测试
（59）利用静态结构分析的结果，通过代码检查和动态测试的方法对结果进一步确认，使测试工作更为有效
（60）覆盖率测试是白盒测试的重点，使用基本路径测试达到语句覆盖标准；对于重点模块，应使用多种覆盖标准衡量代码的覆盖率
（61）不同测试阶段，侧重点不同：
单元测试：
以代码检查、逻辑覆盖
集成测试：
增加静构结构分析、静态质量度量
系统测试：
根据黑盒测试结果，采用白盒测试
四.3黑盒测试
四.3.1黑盒测试方法
四.3.1.1等价类划分法
（62）划分基础：
需求规格说明书中输入、输出要求
（63）等价类：
某个输入域的子集合；分为有效等价类和无效等价类
有效等价类：
指对于程序规格说明书来说是合理的、有意义的输入数据构成的集合。
利用有效等价类可以检验程序是否实现了规格说明书中的功能和性能
无效等价类：
与有效等价的定义恰巧相反
（64）划分等价类原则
序号
输入条件（数据）
划分等价类
1
规定了取值范围
值的个数
一个有效等价类
两个无效等价类
2
规定了输入值的集合
规定了“必须如何”的条件
一个有效等价类
一个无效等价类
3
是一个布尔量
一个有效等价类
一个无效等价类
4
输入数据的一组值（n个），并且程序对每一个输入值分别进行处理
n个有效等价类
一个无效等价类
5
规定必须遵守的规则
一个有效等价类（符合规则）
若干个无效等价类
6
在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
（65）确定测试用例步骤
第一步：
为每个等价类规定一个惟一的编号
第二步：
设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。
重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
第三步：
设计一个新的测试用例，使其只覆盖一个无效等价类。
重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
四.3.1.2边界值分析法
（66）边界类型
边界条件：
可以在产品说明书中有定义或者在使用软件过程中确定
次边界条件：
在软件内部，也称为内部边界条件
其他边界条件：
如输入信息为空（对于此类问题应建立单独的等价类空间）、非法、错误、不正确和垃圾数据
（67）边界值的选择方法
序号
输入条件（数据）
输入边界值数据
1
规定了取值范围
刚刚达到这个范围
刚刚超越这个范围
2
规定值的个数
最大个数、比最大个数大1
最小个数、比最小个数少1
3
根据规格说明书的每个输出条件，使用原则1、2
4
输入或输出是个有序集合
集合的第一个、最后一个元素
5
程序中使用一个内部数据结构
内部数据结构边界上的值
6
分析规格说明，找出其他可能的边界
四.3.1.3错误推测法
错误推测法就是基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。
错误推测法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
四.3.1.4因果图法
因果图法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出条件），通过因果图转换成判定表。
四.3.1.5判定表驱动法
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
适合使用判定表设计测试用例的条件：
规格说明以判定表的形式给出，或很容易转换成判定表
条件的排列顺序不影响执行哪些操作
规则的排列顺序不影响执行哪些操作
当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
四.3.1.6正交试验法
正交试验法从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计。
正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，每个参数就是一个因子，参数的不同取值就是水平，这样我们可以采用正交试验法设计出最少的测试组合，达到有效的测试目的。
正交试验法有如下优点：
节省测试工时
可控制生成的测试用例的数量
测试用例具有一定的覆盖率
四.3.1.7功能图法
一个程序的功能说明通常有动态说明和静态说明组成，动态说明描述
升级会员 