软件测试的基础知识

1、测试基础 软件测试定义：使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规 定的需求或是弄清预期结果与实际结果之间的差别。软件生命周期：软件生命周期包括几个阶段：1.计划planning1)确定软件开发总目标;2)给出软件的功能、性能、可靠性以及接口等方面的设想；3)研究完成该项目的可行性，探讨问题解决方案；4)对可供开发使用的资源、成本、可取得的效益和开发进度做出估计；5)制定完成开发任务的实施计划。2.需求分析requirement analysis对开发的软件进行详细的定义，由需求分析人员和用户共同讨论决定并给予确切的描述，写出软件需求规格说明书SRS(Softwa

2、re Requirement Specification).3.设计design设计是软件工程的技术核心，这个阶段需要完成设计说明书；概要设计HLD详细设计LLD4.程序编码coding把软件设计转换成计算机可以接受的程序，即写在以某个程序设计语言表示的源程序清单，使用RDBMS工具建立数据库。5.测试testing单元测试UT，参照LLD对每一个函数进行测试；集成测试IT，参照HLD对函数与函数的集成、模块与模块的集成进行测试；系统测试ST，参照SRS对每个功能需求、性能需求等进行测试。6.运行和维护run and maintenance本阶段将软件交付用户投入正式使用，以后便进入维护阶段，

3、可能有多种原因需要对它进行修改，如软件错误、系统软件升级、增强软件功能、提高性能等。缺陷的类型：缺陷Defect：以静态的形式存在于软件内部，可被激活，相当于Bug故障Fault：当缺陷被激活后，软件运行中出现的状态，可引起意外情况，不处理会产生失效，是动态行为。失效Failure：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。测试用例Test Case：包括：测试用例编号：测试项目：测试标题：重要级别：预置条件：输入：执行步骤：预期输出：测试工程师的主要工作：1)检视代码、评审开发文档；2)进行测试设计、写作测试文档 (测试计划，测试方案，测

4、试用例)；3)执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正；4)通过测试度量软件的质量。测试过程单元测试UT：是针对软件基本组成单元(软件设计的最小单位)来进行正确性检验的测试工作，单元测试的目的是检测软件模块对详细设计说明书LLD 的符合度。（Unit Testing）集成测试IT：是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证 组装后功能以及模块间接口是否正确的测试工作；其目的是检测软件模块对概要设计说明书HLD的符合度。（Integration Testing）系统测试ST：是将已集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬

5、件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对计算机系统进行一系列的测试工作；其目的在于通过与需求规格说明书SRS作比 较，发现软件与系统需求定义不符合或与之矛盾的地方。（System Testing）UT，IT，ST比较区别：1)测试方法不同UT-IT-ST-2)考察范围不同 UT-处理等；IT- 以及模块组合后的整体功能；ST-3)评估基准不同 UT-IT-ST-回归测试Regression Testing：软件在测试或其他活动中发现的缺陷经过修改后，应该进行回归测试；目的是：验证错误是否修复，并检测对代码的修改是否引入了新的错误；回归测试可以发生

6、在任何一个阶段，包括UT，IT，ST； 回归测试策略包括：完全重复测试和选择性重复测试。验收测试Acceptance Testing：是根据合同、需求规格说明书SRS、验收测试计划对产品进行验收和测试；一般采用测试和测试。测试： 行的测试；开发者坐在用户旁边，随时记下错误情况和使用中的问题，这是在受控制的环境 下进行的测试；其目的主要是评价软件产品的FLURPS(功能、局域化、可用性、可靠性、性 能等)，尤其注重产品的界面和特色；在现场，因而测试是在开发者无法控制的环境下进行的软件现场应用；测试中由用户记 录下遇到的所有问题，包括真的和主观认定的，定期向开发者报告，开发者在综合用户的报 告后作

7、出修改，再将软件交付给全体用户使用。Verification &确认Validation）列活动；确认：确认是否把事情做正确了；指保证所生产的软件可追溯到用户需求的一系列活动；测试过程阶段划分：计划-设计-实现-执行系统测试计划软件测试计划系统测试计划系统测试计划系统测试方案需求规格说明书系统测试方案系统测试用例系统测试规程系统测试预测试项输出系统测试计划系统测试方案系统测试用例系统测试预测试报告系统测试规程系统测试报告系统测试预测试项软件缺陷报告集成测试计划概要设计说明书集成测试计划集成测试计划集成测试方案 集成测试方案集成测试用例集成测试规程输出集成测试计划集成测试方案集成测试用例集成测试

8、报告集成测试规程软件缺陷报告概要设计说明书单元测试计划单元测试计划单元测试方案 单元测试方案单元测试用例单元测试规程输出单元测试计划单元测试方案单元测试用例单元测试报告 单元测试规程软件缺陷报告软件概要设计阶段的任务：软件质量需求的三个层次：显示需求：验收质量（合同、验收准准则等）隐式需求：使用质量（、测试检测，用户反馈等）用户实际需求。软件质量的三个层次：流程(过程)，技术(工具)，组织(人)三者共同决定软件的质量。软件质量管理体系：ISO：不具体针对某个行业的质量标准，是普遍适用的质量管理体系。 International Organization for Standardization

9、(ISO)ISO9000族2000版标准主要由三个核心标准组成：ISO9000：基础,术语 / ISO9001：要求 / ISO9004：改进指南八项质量管理原则：以顾客为中心，领导作用，全员参与，过程方法，管理的系统方法，持续改进，基于事实的决策方法，互利的供方关系.6Sigma：不具体针对某个行业，不只关注质量，还关注成本、进度。在质量上6Sigma表示每百万个产品的不良品率(PPM)不大于3.4，意味着每一百万个产品中最多只有3.4个不合格品，即合 格率是99.99966%.原则：注重客户，注重流程，全员参与，预防为主，事实依据的决定，持续和突破性改进。CMM：特定针对软件行业的质量管理

10、体系。(过程决定质量)Capability Maturity Model (CMM) 能力成熟度模型Capability Maturity Model Integration (CMMI)能力成熟度模型集成CMM等级过程质量：过程设计的完善程度和过程执行的力度。 -测量活动：SQA内部质量：软件研发过程中，中间过程产品(软件的零部件)的质量。-测量活动：静态测试：SRS、HLD、LLD、代码评审；动态测试：UT、粒度小的IT外部质量：软件系统作为完整的整体运行时所表现出来的各方面的质量特征。-测量活动：动态测试：ST使用质量：最终用户在其真实环境中运行软件系统时，所感受到的软件各方面特性与其目

11、标的符合程度。 -测量活动：验收测试、测试过程质量，内部质量，外部质量，由软件组织内部人员评估：SQA、开发、测试使用质量，由软件组织外部人员评估：用户软件质量模型：ISO9126软件质量模型由6个特性、27个子特性组成。（测试分析checklist）软件的基本度量项：规模size：(eg: SRS,HLD,LLD文档页数, 代码量KLOC, UT, IT, ST用例数等)工作量effort：(eg: SRS,HLD,LLD所用人时数, CODE所用人时数,UT,IT,ST计划方案用例执行所用的人时数等)进度schedule：(eg: SRS,HLD,LLD阶段开始时间结束时间，CODE阶段开

12、始时间结束时间，UT,IT,ST计划方案用例执行阶段开始时间结束时间)质量quality缺陷defect：(eg：SRS,HLD,LLD评审发现缺陷数，CODE评审发现缺陷数，UT,IT,ST发现缺陷数)其他度量指标：缺陷密度：研发活动发现缺陷密度:SRS,HLD,LLD评审发现缺陷密度(defects/page)；CODE评审；UT,IT,ST发现缺陷密度(defects/kloc). 研发活动引入缺陷密度：SRS,HLD,LLD文档引入缺陷密度(defects/page)；CODE阶段引入缺陷密度(defects/kloc). 工作产品缺陷密度：SRS,HLD,LLD文档缺陷密度(defe

13、cts/page)；CODE缺陷密度(defects/kloc).生产率：SRS,HLD,LLD阶段文档生产率:页/人天;CODE阶段生产率：KLOC/人天；UT,IT,ST用例设计阶段生产率：用例/人天.测试执行效率：执行用例数/人天 (按测试阶段进行度量)。用例密度：用例数/KLOC (按测试阶段进行度量)(用例密度说明用例设计的充分性).需求稳定性：变更过的需求数/总需求数.测试方法白盒测试(White Box Testing)：白盒测试又称：玻璃盒测试Glass Box Testing, 透明盒测试Clear Box Testing,开放盒测试Open Box Testing, 结构化

14、测试 Structured Testing,基于代码的测试Code-Based Testing, 逻辑驱动测试Logisc-Driven Testing白盒测试技术一般可分为以下两类技术：静态分析：控制流分析技术，数据流分析技术，信息流分析技术。动态分析：逻辑覆盖率测试(分支测试，路径测试等)，程序插装等。逻辑覆盖率：语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，路径覆盖.黑盒测试Black Box Testing:又称：功能测试Functional Testing最常见的黑盒测试有：功能性测试容量测试安全性测试负载测试恢复性测试标杆测试稳定性测试可靠性测试外场测试(必须有用户参加，类似Beta

15、测试)实验室测试(必须有用户参加，类似Alpha测试)白盒测试只考虑测试软件代码，它不保证完整的需求规格是否被满足；黑盒测试只考虑测试需求规格，它不保证实现的所有部分是否被测试到；黑盒测试会发现遗漏的缺陷，指出规格的部分没有被完成；白盒测试会发现代码方面缺陷，指出实现部分是错误的。灰盒测试Grey Box Testing: 是界于白盒测试和黑盒测试之间的测试；常见的灰盒测试是：集成测试.按被测对象是否被运行起来，可分为：静态测试和动态测试 自动化静态分析工具：语法分析器和符号执行器 静态分析中的手工技术：软件检视和走读配置管理配置管理：配置管理就是通过对在软件生命周期的不同的时间点上所产生的文

16、件进行标识，并对这些被标识的文件的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。基线化：在配置管理系统中，基线就是配置项在其生命周期的不同时间点上通过Review而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的基准。常用的配置管理工具：商用：IBM Rational ClearCase , VSS (Microsoft Visual Sourcesafe),Borland StarTeam开源：CVS(Concurrent Version System), SVN(TortoiseSVN)软件配置管理的过程：配置计划-配置标识-配置控制-配置状

17、态发布-配置审计配置管理SCM (Software Configuration Management)项目经理 PM (Project Manager)变更控制委员会CCB (Change Control Board ) or (Configuration Control Board)配置管理员 CMO (Configuration Management Officer)配置项 CI (Configuration Item)变更申请CR (Change Request)基线Baseline需求管理同行评审的类型：正规检视，技术评审，走读变更控制流程：需求跟踪表RTM 前景和范围vision a

18、nd scope 业务需求Business requirement 粒度好fine-grained市场需求Project charter 或market requirement “待确定”TBD用户需求user requirement 需求工程requirement engineering, RE 系统需求system requirement 需求获取requirement elicitation 功能需求functional requirement 可扩充open-ended行为需求behavioral requirement 关键过程域key process areas, KPA 软件需求

19、规格说明software requirement specification,SRS 工作任务书SOW Statement of Work 建模的定时和目的timing and intent of the modeling 审核Certification总体会议overview meeting 准备Preparation评审会议inspection meeting 重写rework重审follow-up 工作流workflow需求管理活动：需求分配，需求跟踪，需求评审，需求基线，变更控制.通用用例写作通用用例八要素：用例编号：产品编号-ST/IT/UT-测试项名-测试子项名-XXX测试项目：S

20、T:功能点(功能测试),性能指标(性能测试),界面中控件(GUI测试)等.IT: 集成后的模块功能或者内部接口.UT: 对应函数名.测试标题：测试目的重要级别：高，中，低预置条件：环境的设置，先要运行的其它用例等测试输入：手工输入、文件、数据库存记录等需要加工的外部信息操作步骤：明确写出每一步骤的描述预期输出：可从三个方面考虑：界面显示、数据库的变化、相关信息的变化缺陷管理软件缺陷相关属性：缺陷发现人、缺陷发现时间、缺陷状态、缺陷严重程度、缺陷所属版本、缺陷修改日期软件缺陷的状态：New-Open-Fixed-Closed-Reopen-Postpone-Rejected-Duplicate-

21、Abandon缺陷的严重程度：Critical致命-Major严重性-General一般-Suggest提示缺陷报告的写作要点：标题，状态，严重级别，优先级，详细步骤，版本，环境，发现人，发现时间，修复人，修复时间，附件.缺陷记录的写作要点：序号，缺陷ID，测试者，缺陷描述及重现缺陷操作，等级，出现频率，状态，解决方法，解决人，解决日期，验证人，验证日期.软件缺陷管理工具：商用：Mercury Quality Center ， Rational ClearQuest开源：Bugzilla, Mantis, Jira.测试覆盖率 白盒测试覆盖率：逻辑覆盖，语句覆盖，指令块覆盖，判定路径覆盖. 灰

22、盒测试覆盖率：函数覆盖，接口覆盖 黑盒测试覆盖率：功能覆盖率(最常见的是需求覆盖) 面向对象的覆盖率：继承上下文覆盖，基于状态的上下文覆盖，基于线程的上下文覆盖.单元测试单元测试：目的是在于发现各模块内部可能存在的各种错误，主要是基于白盒测试，有三方面：1）验证单元代码和详细设计文档的一致性；2）跟踪详细设计文档中设计的实现，发现详细设计文档中存在的错误；3）发现在编码过程中引入的错误. 单元测试关注的错误重点：单元接口：被测单元的输入输出参数在个数属性顺序上和LLD中的描述不一致.修改了只做输入用的形式参数，可能会导致数据的错误修改.约束条件通过形式参数来传送，导致函数间的控制耦合增大.局部

23、数据结构： 不正确或不一致的数据类型说明;使用尚未赋值或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错误或书写错误;不一致的数据类型.独立路径： 运算的优先次序不正确或误解了运算的优先次序；运算的方式错误；不同数据类型的比较；关系表达式中不正确的变量和比较符;”差1错”。即不正确的多循环或少循环一次；错误的或不可能的循环终止条件；不适当地修改了循环变量等.出错处理：出错的描述难以理解；出错的描述不足以对错误定位和确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等.边界条件：在n次循环的第n次，取最大最小值时容易发生

24、错误；特别要注意数据流，控制流中刚好等于、大于、小于确定的比较值时出现错误的可能性.无论是UT还是IT，都涉及到以下三个函数：主控函数int ctrl ( int x, int y)加法函数intadd( int x, int y)减法函数intsub ( int x, int y)辅助测试单元：驱动单元Driver和桩单元Stub 单元测试策略：孤立的单元测试策略Isolation Unit Testing自顶向下的单元测试策略Top Down Unit Testing自底向上的单元测试策略Bottom Up Unit Testing混和测试单元测试过程：UT计划阶段-完成UT计划UT设计阶

25、段-完成UT方案UT实现阶段-完成UT用例、UT规程、UT脚本、数据文件的编写工作.UT执行阶段-执行UT用例、修改发现的问题并进行回归测试、提交UT报告. 集成测试集成测试目的：确保各组件组合在一起后能够按既定意图协作运行并确保增量的行为正确。集成测试关注的重点：接口和功能集成测试划为三个级别： 1)模块内IT； 2)子系统内IT； 3)子系统间IT.集成测试策略：自底向上Bottom-Up Integration 自顶向下集成Top-Down Integration大爆炸集成 Big Bang Integration 三明治集成Sandwich Integration基干集成Backbone Integration其他：分层集成Layers Integration 基于功能的集成Function-Based Integration 高频集成High-frequency Integration 基于进度的集成Schedule-Based Integration 基于风险的集成Risk-Based Integration基于事件(消息)的集