软件测试技术基础知识.docx
《软件测试技术基础知识.docx》由会员分享，可在线阅读，更多相关《软件测试技术基础知识.docx（31页珍藏版）》请在冰豆网上搜索。
软件测试技术基础知识
一、软件测试概述
软件是计算机系统中与硬件相互依存的一部分，包括程序、数据以及与其相关文档的完整集合。
其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操作信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。
软件测试的目的
GB/T15532—2008软件测试目的：
∙验证软件是否满足软件开发合同或项目开发计划、系统设计文档、软件需求规格说明、软件设计说明和软件产品说明等规定的软件质量要求；
∙通过测试，发现缺陷；
∙为软件产品的质量测量和评价提供依据。
软件测试的目标
∙确保产品完成了它所承诺或公布的功能
∙确保产品满足性能和效率的要求
∙确保产品是健壮的、适应用户环境的
软件质量保证和软件测试的区别
∙软件测试是软件质量保证的一部分，有助于提高软件的质量，但不是软件质量保证的全部。
∙软件质量保证与软件测试的主要区别是：
∙质量保证侧重事前预防，而软件测试侧重事后检测；质量保证要管理和控制软件开发流程的各个过程，软件测试只能保证尽量暴露软件的缺陷。
∙相关人员的角色也有较大差别。
软件质量保证人员的主要职责是创建和加强促进软件开发并防止软件缺陷的标准和方法。
软件测试工程师的目标是在最短的时间内发现尽可能多的缺陷，并确保这些缺陷得以修复。
软件测试技术分类
∙按照软件测试时是否查看程序内部代码结构分为黑盒测试和白盒测试
∙按照软件的开发阶段可以分为单元测试、集成测试、系统测试和验收测试；
∙按照是否需要执行被测软件的角度，可以分为静态测试和动态测试；
∙按照测试目标的不同，可以分为功能测试和非功能测试；
∙按照测试的执行方式，又可以分为手工测试和自动化测试。
黑盒测试方法主要有：
等价类、边界值、判定表、因果图、状态图、正交法、错误猜测法、大纲法；其局限性是着眼于程序的外部结构，不考虑内部逻辑，主要针对软件界面和软件功能进行测试
白盒测试方法主要有：
一般包括控制流测试（语句覆盖测试、分支覆盖测试、条件覆盖测试、条件组合覆盖测试、路径覆盖测试）、数据流测试、程序编译、程序插桩、域测试和符号求值;其局限性，无法检查程序的外部特性，无法对未实现的规格说明的程序内部欠缺部分进行测试。
手工测试和自动化测试
手工测试
手工测试，是利用人工的方式去执行测试和自动化测试相对应，属于最基本的测试方法。
自动化测试
自动化测试是利用工具或程序来代替人工的测试方法。
V模型的测试级别
1．单元测试
也称为组件测试，是指对软件中的最小可测试单位进行检查和验证，它的目的是检验软件基本组成单元的正确性。
单元测试是编写一小段代码，用于检验被测代码的一个很小很明确的功能是否正确，编写的这一小段代码被称为桩或驱动。
桩（Stub）：
一个软件组件框架的实现或特殊目的的实现，用于开发和测试另一个调试或依赖于该组件的组件，它代替了被调用的组件。
驱动器（Driver）：
代替某个软件组件来模拟控制和调用其他组件或系统的软件或测试工具。
2.集成测试
集成测试是通过测试的单元模块组装成系统或子系统再进行测试，目的是对组件之间的接口进行测试，以及测试一个系统内不同部分的相互作用。
集成测试实施包括自底向上集成测试和自底向下的集成测试。
自底向上的集成是从最底层模块开始；自顶向下的集成是从主控模块（主程序，即根节点）开始。
3.系统测试
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。
缺点是，它发现的是非功能性缺陷、概念性缺陷、设计整个系统的缺陷
4.验收测试
包括用户验收测试；运行（验收）测试；合同和法规性验收测试；α测试和β测试。
α测试和β测试的不同是β测试开发者通常不在现场
功能测试
功能测试就是指系统能做什么，通常是一项黑盒操作其涉及了软件在功能上正反两面的测试，而非功能测试就是所有其他方面的测试。
安全性测试、互操作性测试也是功能测试的一种。
非功能特性测试（非功能测试）
非功能测试是指为了测量系统和软件的特征，需要进行的测试。
其包括但不限于以下：
性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试和可移植性测试、兼容性测试、安全性测试、本地化测试、配置测试。
冒烟测试“冒烟测试”是指测试版本的主要功能的测试。
功能自动化测试工具
UFT（QTP）SeleniumWinRunnerSilkTest
性能自动化测试工具
LoadRunnerJMeterWebLOADWAS
测试管理工具
QCBugFree禅道
二、软件测试流程
包括：
测试需求分析测试计划制定测试用例设计测试环境搭建测试环境搭建测试执行及缺陷处理测试总结报告测试文件归档
从测试需求分析开始直至测试文档归档，形成了一个软件测试的PDCA循环（Plan-Do-Check-Analysis，戴明环，质量环）
软件需求分析
软件需求分析是软件测试流程中的基础一环，用来明确软件测试对象以及测试范围，并作为测试覆盖的基础。
软件测试计划制定
软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试范围、测试配置、测试进度、测试资源、风险分析等。
软件测试用例设计软件测试环境搭建。
测试数据准备
传统测试数据分为手动创建和自动化创建
手动创建方法（手动模拟用户的实际操作来创建重要业务流程的测试数据；通过SQL语句中where查询条件和update方法来创建符合条件的测试数据；导入本地机器上存储的一些符合条件的测试数据；导入并加工线上数据变成测试数据。
）
自动化创建测试数据
测试工具（DataGenerator、DatabeneBenerator、Testgen、Datatect以及TurboData）
大数据系统所处理的数据具有大规模（Volume）、类型多样（Variety）、产生速度快（Velocity）、商业价值高（Value）等特点，数据获取方式也与传统项目的数据获取方式有所不同。
1.真实数据引流2.生产环境数据复制3.构造数据
拿到数据后，要进行预处理，因为数据可能本身就不是完整的，缺少某些属性值;高维度，所谓的高维度是指数据的属性或字段太多；
数据可能存在重复；数据可能会由于包含代码或者名称的差异导致跟实际需要的数据不一致；数据中存在着错误或异常数据。
数据预处理的方法：
（1）缺失值的处理。
总的原则是：
使用最可能的值代替缺失值，使缺失值与其他数值之间的关系保持最大。
（2）异常值的处理。
异常值是数据集中偏离大部分数据的数据。
（3）数据的标准化处理。
数据的标准化是将数据按比例缩放，使之落入一个小的特定区间。
（4）数据连续属性离散化。
一些数据挖掘算法，特别是分类算法，要求数据是分类属性形式。
常常需要将连续属性变换成分类属性，即连续属性离散化。
软件测试过程模型
v模型
v模型是最具代表性的测试模型，清楚地描述了测试阶段和开发过程各阶段的对应关系。
局限性v模型的属性：
它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析，系统设计和确认功能。
W模型
强调软件测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，还包括需求、设计以及开发输出的文档。
相对于V模型，W模型更科学。
局限性w模型无法支持迭代
H模型优
1.软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地
进行。
2.软件测试不仅仅指测试的执行，还包括测试准备工作。
3.软件测试要尽早准备，尽早执行。
4.软件测试是根据被测物的不同而分层次进行的，支持被测物的多次迭代。
5.能够很好地体现测试流程的完整性。
总结：
在工作中不能为了使用模型而使用模型，要灵活运用各种模型的优点，取其精华，去其糟粕。
例如可以中和运用，在W模型的框架下，运用H模型的思想进行独立测试，并同时将测试和开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。
软件测试的原则
●所有的测试最终都应该以用户需求为依据
●应尽早开展软件测试工作
●程序员应该尽量避免测试自己编写的程序
●穷尽测试是不可能的
●软件测试是有风险的
●软件测试中的Pareto法则
●Good-Enough原则
Pareto法则
Pareto法则又称为80/20效率法则暗示：
软件测试发现的80%的错误很可能起源于20%的程序模块。
也可以表示，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出其余缺陷的80%（其余20%的80%），最后4%的软件缺陷可能只有在用户大范围、长时间使用后才会暴露出来
Good-Enough原则
既不要做过多的测试，也不要做不充分的测试，这就是“Good-Enough原则”在适当的时刻，找到一个适当的点，即发现的bug数与投入的成本有显著的正比例关系。
三、软件测试计划
项目类软件
项目类软件的需求由特定用户以合同等契约形式明确下来。
产品类软件
产品类软件没有特定用户以合同形式明确需求，需求主要由市场分析人员分析潜在客户的潜在需求获得。
什么是评审？
IEEE729-1983规定：
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。
其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
评审的目的是在软件开发与测试的各个阶段进行相应的检查，有利于软件产品与过程的质量提高。
软件测试计划概述
软件测试计划（SoftwareTestPlan）是一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
软件测试计划包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
●测试计划越早越好
●坚持5W1H的基本思路，明确软件测试计划内容的6要素
●采用评审和更新机制
●软件测试计划要简洁、易读
软件测试计划内容
术语定义：
对软件缺陷的定义
●软件未实现产品说明书要求的功能；
●软件出现了产品说明书中指明不应该出现的错误；
●软件实现了产品说明书未提到的功能；
●软件未实现产品说明书虽未明确提及但应该实现的目标；
●测试人员认为软件不好用，或者不应该出现的功能。
测试准则
●
（1）测试进入的准则：
是指开始执行测试的时机；
●
（2）测试暂停的准则：
描述系统在什么情况下暂停全部或部分测试工作；
●（3）测试恢复的准则：
描述系统恢复测试的必要条件；
●（4）测试退出的准则：
描述测试退出的条件，有正常退出，也有非正常或意外的退出。
四、软件测试用例概述
软件测试用例是软件测试执行的基础，是软件测试的核心。
注意以下几点：
●
（1）避免盲目测试，提高测试效率
●
（2）确保功能需求不被遗漏
●（3）便于回归测试
●（4）为测试的度量提供评估基准
测试用例的设计
●
（1）在设计测试用例的时候，会考虑以下步骤：
●
（2）获取需求的测试点
●
（2）设计测试用例模板，设计测试步骤
●（4）确定测试数据
●（5）评审测试用例
测试用例模板；例；Excel
例；word
注意测试用例的优先级
讲测试用例分为4类BVTs，高，中和低。
在测试用例的编写完成后，要注意对测试用例的维护，这是一个不断修改完善的过程。
五、高效设计测试用例
等价类划分法
●注；黑盒测试用例设计方法主要有等价类划分法、边界值分析法、判定表、因果图法、正交法、场景法以及大纲法和错误推测法
●等价类划分法:
{有效等价类、无效等价类}健壮性等价类测试
●步骤：
分析程序的规格说明，列出有效等价类和无效等价类
●列出输入条件中可能的组合输入情况。
●选取合适的数据，编写测试用例
边界值分析法
●边界值分析法（BoundaryValueAnalysis，BVA）的测试用例来自于等价类的边界，是等价类划分法的补充。
使用边界值分析法设计测试用例，首先应该确定它的边界。
边界值分析法概述原则：
●
（1）如果输入/输出条件规定了值的范围，则应该取刚达到这个范围的边界的值，以及刚刚大于最小值以及刚刚小于最大值的值作为测试输入数据。
但为了检查输入数据超过极限值时系统的情况，还需要考虑健壮性取值，会增加一个略超过最大值和略小于最小值的取值。
●
（2）如果有多个输入/输出变量，可用边界值+正常值的组合模式，即其中一个变量取边界值，其他变量取正常值。
●（3）同样的，对于有3个输入条件的程序，边界值法的运用也如此。
有一个三元函数f（x，y，z），有3个输入变量：
x，y，z。
它们的取值范围分别为1<=x<=31，1<=y<=12，1949<=z<=2050。
●边界值分析法和等价类划分法之间最大的区别就是，边界值分析考查正处于等价划分边界或在边界附近的状态。
判定表法
●概念：
判定表又称“决策表”，是一种表格状的图形工具，适用于处理判断条件较多，各条件又相互组合、有多种决策方案的情况。
●组成：
1.条件桩：
指所有条件的名称，列出的条件的先后次序无关紧要。
2.动作桩：
指所有可能采取的操作，顺序没有约束。
3.条件项：
条件桩中的条件所有可能的取值。
4.动作项：
与条件项紧密相关，列出在条件项的各组取值情况下应该采取的动作。
步骤：
●第1步：
分析需求，列出所有的条件桩和条件项；
●第2步：
分析需求，列出所有的动作桩和动作项；
●第3步：
根据规则，设计初始判定表；
●第4步：
简化判定表，合并相似规则，设计测试用例。
●优点：
能够将复杂的问题按照各种可能的情况全部列出来，简明并避免遗漏，而且对条件的组合顺序并无要求。
●缺点：
没有考虑输入条件之间的相互制约关系
因果图法
（1）E约束（异、互斥）：
a、b、c中最多有一个可能为1，也就是a、b、b不能同时为1，输入条件之间为互斥关系。
但可以同时为0。
（2）I约束（或、包含）：
a、b、c中最少有一个必须是1，也就是a、b、c不能同时为0，输入条件之间为包含关系。
但可以同时为1。
比如程序中的多选按钮。
（3）O约束（唯一）：
a、b、c中必须有一个且仅有一个为1。
比如程序中的单选按钮。
（4）R约束（要求）：
a是1时，b必须是1，a为0时，b的值不确定。
即不可能a是1时，b是0。
以上4种是输入条件的约束，输出条件的约束只有一种，就是M约束：
（5）M约束（强制、屏蔽）：
若a是1，则b强制为0；若a是0，那么b的值不确定。
正交实验法
正交实验法是一种基于正交表的、高效率、快速、经济的实验设计方法，它研究的“多因素多水平”的情况，然后套用正交表来随机地产生用例（用例之间没有主次之分），是一种提高测试覆盖率的简单易用的方法。
因素（Factor）：
在一项实验中，凡是被考查的变量就称为因素。
水平（Level）：
在实验范围内，因素被考查的值称为水平。
表现形式：
L 行数（水平数因素数）
行数：
正交表中行的个数，也就是实验的次数，也指测试用例的个数。
因素数：
指正交表中列的个数。
水平数：
任何单个因素能够取得的值的最大个数。
限性：
目前常见的正交表数量有限。
总结：
分层对应测试的方法
六、软件缺陷报告
符合软件缺陷的规则
●软件未达到产品说明书标明的功能。
●软件出现了产品说明书指明不会出现的错误。
●软件功能超出了产品说明书指明的范围。
●软件未达到产品说明书虽未指出但应达到的目标。
●软件测试人员认为软件难以理解、不宜使用、运行速度缓慢，或者最终用户认为不好。
缺陷产生的原因
●软件缺陷的第一大来源是产品说明书。
●缺陷的第二大来源是设计。
●第三大来源才是程序代码。
●第四大来源是其他的一些原因，比如硬件或软件存在错误，或者把误解当成了缺陷；还有些缺陷反复多处出现，实际上是由同一个原因引起的。
例：
完整的软件缺陷报告
软件缺陷报告的基本信息
1. 缺陷标题（或者叫缺陷摘要）
●避免使用模糊不清的词语，例如“功能不正确”、“功能中断”等。
应该使用具体文字说明功能如何不正确，如何中断。
●标题要便于搜索和查询，可以在标题中使用关键字。
●为了便于他人理解，标题要清晰、简洁，避免描述过于具体的测试细节。
●尽量按照缺陷发生的原因与结果的方式书写。
比如“执行完A后，发生B”，或者“发生B，当A执行完后”。
2．操作步骤（也叫复现步骤）3.预期结果4.实际结果
3．5.注释；包含内容；
（1）截取缺陷特征图像文件
（2）测试过程需要使用的测试文件
（3）测试附加的打印机驱动程序
（4）缺陷出现过程中的日志文件
（5）再次指明该缺陷是否在前一版本已经存在
（6）多个平台之间是否具有不同表现
（7）注释包含缺陷的隔离信息，指出缺陷的具体影响范围
缺陷的属性
1. 模块名称2. 缺陷版本号
3. 缺陷状态例；
4.缺陷类型
功能问题接口问题逻辑问题计算问题数据问题用户界面问题文档问题
性能问题配置问题标准问题环境问题兼容问题
缺陷严重级别
●
（1）1-致命缺陷
●致命缺陷是指系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危及人身安全的缺陷。
或者系统所提供的功能或服务受到明显的限制，不能执行正常工作流程或实现重要功能。
包括
●可能有灾难性的后果，如造成系统崩溃，造成事故的缺陷等；
●数据库错误，如数据丢失、数据毁坏等；
●安全性被破坏。
●处理优先级
1-立即解决（ResolveImmediately）
导致系统几乎不能使用或测试不能继续，需要立即修复的缺陷。
2-高优先级（HighPriority）
比较严重，影响测试，需要优先考虑的缺陷。
3-正常排队（NormalQueue）
需要正常排队等待修复的缺陷。
4-低优先级（LowPriority）
可以在开发人员有空余时间的时候被修正的缺陷。
缺陷来源
序号
缺陷来源
说明
1
需求Requirement
由于需求的问题引起的缺陷
2
架构Architecture
由于架构的问题引起的缺陷
3
设计Design
由于设计的问题引起的缺陷
4
编码Code
由于编码的问题引起的缺陷
5
测试Test
由于测试的问题引起的缺陷
6
集成Integration
由于集成的问题引起的缺陷
缺陷报告书写准则
●
（1）遵循5C准则
Correct（准确）：
每个组成部分的描述准确，不会引起误解和歧义，不夸大缺陷，也不要过于轻描淡写；
Clear（清晰）：
每个组成部分的描述清晰，不使用模棱两可的描述，比如出现“似乎（seem）”、“看上去可能（Possible）”等含义模糊的词汇；
Concise（简洁）：
只包含必不可少的信息，不包括任何多余的内容。
这可以通过使用关键词，使摘要的描述短小简练，又能准确解释产生缺陷的现象。
如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“及时消息”等就是关键词；
Complete（完整）：
包含复现该缺陷的完整步骤和其他本质信息，可以使开发人员很容易看懂缺陷；
Consistent（一致）：
按照一致的格式书写全部缺陷报告。
软件缺陷报告的生命周期
软件缺陷的生命周期是指一个软件缺陷从发现到关闭的全过程。
在许多情况下，软件缺陷的生命周期的复杂程度仅为：
软件缺陷被打开、解决和关闭。
然而在有些情况下（不同的公司、不同的项目），生命周期变得更复杂一些，具体操作如下：
缺陷在其生命周期中的不同状态如下：
（1）首先由测试人员发现缺陷，并提交到缺陷管理工具中，缺陷状态为New。
（2）测试经理或者项目经理审核状态为New的缺陷，把被确认的缺陷分配给对应的开发人员，状态为Open。
（3）开发人员开始处理属于自己的缺陷报告，处理完毕后状态设置为Resolved，但并非所有的软件缺陷都会得到修复。
Resolved状态的缺陷可能包括几种解决方案：
已经修复（Fixed）、推迟解决（Postponed）、无法复现（Unreproduced）、重复提交（Duplicate）、不是缺陷（Invalid）。
但也有缺陷管理工具把这几种解决方案和Resolved状态并行的单独成一个缺陷状态，而不仅仅是“Resolved”的解决方案。
（4）测试人员或者测试经理对于状态为“Resolved”的缺陷进行回归测试，在新的软件版本中验证缺陷是否已经被修正。
如果已经被修正，则缺陷的状态更改为Closed；而如果没有被正确修正，则把状态改为Reopen，重新发送给开发人员，等待继续修正，继续重复第（3）步以后的流程。
软件缺陷管理工具
BugFree软件管理工具的使用
**一、Bug管理**
为了保持用户体验的一致性，新建Bug，新建TestCase和新建TestResult的界面布局基本保持一致，只是具体填写字段有所不同。
以新建Bug为例，在主界面模式切换标签选择【Bug】，点击【新建Bug】打开新建Bug页面，如图6-6所示，黄色标注字段为必填项。
Bug的3种状态
状态
说明
Active（活动）
Bug的初始状态。
任何新建的Bug状态都是Active。
可以通过编辑修改Bug的内容，并指派给合适的人员解决。
Resolved（已解决）
开发人员解决Bug之后的状态。
Closed（已关闭）
已修复的Bug在验证无误之后关闭，该Bug处理完毕。
如果没有真正解决或者重新复现，可以重新激活，Bug状态重新变为Active。
2.Bug生命周期
BugFee工具中Bug的处理流程是比较直观简洁的
新建的Bug处于Active状态，可以通过编辑指派给合适的解决者。
解决Bug之后，Bug状态变为Resolved，并自动指派给创建者。
创建者验证Bug。
如果未修复，再重新激活，Bug状态重新变为Active；如果已经修复则可以关闭，
Bug状态变为Closed，Bug生命周期结束。
已经Closed的Bug如果重新出现，也可以直接激活。
Bug的七种解决方案
软件测试报告作用
1.是对整个项目的测试过程和质量进行评价；
2.是对产品各阶段的遗留问题进行总结；
3.是为后续的测试过程改进提供依据。
4.具体模板
5.一、项目概述1.1项目背景1.2编写目的1.3术语与缩略语1.4参考与引用文档二、测试概要2.1测试机构和人员2.2测试时间2.3测试范围2.4测试方法和工具2.5测试用例2.6测试环境与配置三、缺陷统计与分析3.1测试统计表3.2测试统计图3.3遗留缺陷列表四、测试结论与问题建议4.1测试结论4.2呈现的问题4.3改进建议
测试统计图
●缺陷分布（密度）报告
●缺陷龄期报告
●缺陷趋势报告
软件质量管理体系
ISO9000质量管理体系
1.CMM质量管理体系
2.CMM把软件企业的过程管理能力分成5个等级
CMM和ISO的区别
6.CMM不是标准，只是对过程能力的评估结果。
7.ISO9000经过权威机构的审核，可以通过认证。
8.CMM对软件企业
升级会员 