软件测试的理论基础

软件测试的基础: 软件测试的定义 :在规定的条件下对程序进行操作 ,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。 软件测试的目的

 

软件测试的基础

软件测试的定义在规定的条件下对程序进行操作 ,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。

软件测试的目的:发现问题,发现至今未发现的问题,检查系统是否满足需求。测试程序执行的过程,目的在于发现错误。

软件测试的对象:UI的⻚面展示,程序内部的逻辑交互,⻚面提示信息,UI的⻚面布局展示,和色调等。

软件测试的原则:

测试应基于用户需求

做好软件测试计划是做好软件测试工作的关键

应尽早的开始软件测试并不断的进行软件测试

测试前必须明确定义好产品的质量标准

避免测试自己的软件

应充分注意测试中的集群现象

必须检查每个实际输出结果

穷举测试是不可能的

测试设计决定了测试的有效性和效率

注意保留测试设计和说明文档,并注意测试设计的可重用性

软件测试的分类

    按阶段划分:   单元测试

集成测试

系统测试

验收测试

       单元测试:单元测试又称为Unit Test,是对软件组成最小离度的测试。

测试阶段:编码后进行测试,如果是TDD的开发模式,就是先写单元测试用例

测试对象:程序最小模块的测试,如程序里面的一个方法或者是一个函数的内部逻辑

测试人员:白盒测试工程师,开发工程师,测试开发工程师

测试依据:代码内部程序逻辑和开发注释

测试方法:白盒测试,根据不同编程语言有对应的测试框架,如Java里面的Junit和TestNG框架,Python里面的UnitTest和Pytest测试框架。

集成测试(接口测试):是把单个模块的程序集成到一起后的测试,集成测试主要来验证各个模块集成后模块与模块之间的功能性,以及各个模块集成后的功能流程性和逻辑兼容性的测试

 

测试阶段:一般单元测试之后进行。在企业里面,开发各自开发完各自的模块后,就会和其他程序员之间进行模块的联调测试和验证模块集成后的逻辑和模块⻅的接口验证。

测试对象:模块间的接口

测试方法:黑盒测试与白盒测试相结合,灰盒测试

测试内容:模块之间的数据传属,模块之间功能冲突,模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响

系统测试:是对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段来验证被测程序的整体性的功能。 

阶段:集成测试通过之后

测试对象:整个系统(软件以及涉及到的硬件)

测试人员:黑盒测试工程师,功能测试工程师

测试依据:需求规格说明文档,以及产品的PRD文档

测试方法:黑盒测试,功能自动化测试

测试内容:功能、界面、可靠性、易用性、性能、兼容性、安全性

验收测试(交付测试)

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段,也称为交付测试。

互联网公司:测试完成-发送邮件给产品经理-产品经理验收测试-验收完成

外包公司;测试完成-客户验收测试-验收完成-交付完成

粒度从小到大顺序:单元->集成->系统->验收

     按查看代码分类:   黑盒测试

白盒测试

灰盒测试

  • 黑盒测试

程序是一个盒子,我们看不⻅里面的任何东⻄,我们看到的只是外面的东⻄。所以黑盒测试因为看不⻅程序里面的东⻄,所以更多的是功能层面的测试

 

 

 

 

 

 

  • 白盒测试

白盒测试更多是基于代码层面的测试,编写代码来测试程序内部的逻辑是否合理,这些测试就包含了针对程序判断逻辑,判断分支,判断循环,程序流程走向的测试。白盒测试是一种高技能的测试。对测试的技术水平要求是比较高的。

  • 灰盒测试

灰盒测试是介于白盒测试和黑盒测试之间的一种测试,对测试的能力要求是能够进行很好的业务测试,也能够使用代码对程序员的代码进行测试,同时能够参与开发代码的评审和代码走查。

    按测试编写代码分类:

                                手工测试(功能测试)

自动化测试:通过编写代码(使用工具)的方式来替代模拟人的一种行为方式来对系统进行的一种测试。自动化测试又分为UI自动化测试,API自动化测试,性能自动化测试。一般性说的自动化测试大多数时候指的是UI自动化测试和API自动化测试。

软件质量:六大特性

功能性:软件需要满足用户显式或者稳式的功能。

易用性:软件易于学习 和上手使用。

可靠性:指的就是软件必须实现需求当中指明的具体功能。

效率性:类似于软件的性能。

可维护性:要求软件具有将某个功能修复之后继续使用的能力。

可移植性:当前软件可以从一个平台移植到另一平台使用的能力

软件分类

     系统、应用、中间件

     b/s  (web)   c/s(客户端)

测试术语

冒烟测试:确认软件的流程正常

探索性测试:强调测试人员的主观能动性

安全测试;目前更多的聚焦于渗透测试这部分

回归测试:指修改了旧代码后重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

如何做软件测试需求分析

为什么要需求分析?

             软件测试需求是设计测试用例的依据。

有助于保证测试的质量和进度

软件测试需求是衡量测试覆盖率的重要指标

测试用例 

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果

测试用例步骤:拿到测试需求--分析需求(画思维导图) --编写用例 --划分用例优先级

测试用例三要素:

测试输入

执行条件

预期结果

编写测试用例的方法:

1.思维导图

2.Excel文件

3.word文档

4.testlink

测试用例编写特征:

一致性:主要包括用例模板一致;各同事的编写手法一致;以及用例的细腻度一致。

覆盖率:主要包括对需求的覆盖(也包含隐含的需求);新需求可能对那些功能会产生影响的覆盖;对各种场景的覆盖等

可执行性:主要是指步骤易于理解、信息描述准确、且能快速识别出测试点

执行准确性:是指用例执行的准确度,本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素,导致部分用例未实际执行标为通过的情况

持续更新:要及时不断的更新,要尽量减少用例库中失效的用例

复用性:主要用例可以被不断的复用,从而减少维护成本

测试用例组成要素:

【excel】

  • 用例ID
  • 用例名称
  • 测试目的
  • 测试级别
  • 参考信息
  • 测试环境
  • 前提条件
  • 测试步骤
  • 预期结果
  • 设计人员

【思维导图】

  • 前提条件
  • 测试步骤
  • 期望结果

 【checklist】

  

环境:

QA:测试环境

生产环境:线上环境

tsgae环境;预发布环境(公司使用)

测试用例设计原则:

测试用例的代表性:能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

测试结果的可判定性:即测试执行结果的正确性是可判定的,每一个测试用例都应有相应的期望结果。

测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的

测试用例设计方法:8个

1.等价类划分方法:我们把输入的数据分为有效数据和无效数据该方法是一种重要的,常用的黑盒测试用例设计方法。

有效等价类:指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

无效等价类:对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。

       设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验,这样的测试才能确保软件具有更高的可靠性

 以新浪邮箱注册为例:

 

 

划分等价类的标准:

1)完备测试、避免冗余;

2)划分等价类重要的是:集合的划分,划分为互不相交的一组子集,而子集的并是整个集合;

3)并是整个集合:完备性;

4)子集互不相交:保证一种形式的无冗余性;

       5)同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到"相同的执行路径"

划分等价类的方法;

1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如:输入值是学生成绩,范围是0~100

2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类;

3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

4)在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。 例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种这四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。

5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同⻆度违反规则);

6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类

设计测试用例 在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例:

1)为每一个等价类规定一个唯一的编号;

2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;

3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止

2.边界值分析方法:是针对等价类测试用例设计方法的补充,是功能测试用例设计方法

1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

2.与等价划分的区别 :

1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。

2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况

以拉勾网为例:

3.错误推测方法:非功能性的测试用例设计方法,它更多是一种假设程序可能存在问题,需要经过验证来假设的问题是否真的存在,

  主要应用于:性能测试 、安全测试 、兼容性的测试

  非功能:安全性 兼容性 易用性

1. 定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

2. 错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。1. 例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。2. 例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例: I. 程序是否把空格作为回答 II. 在回答记录中混有标准答案记录 III. 除了标题记录外,还有一些的记录最后一个字符即不是2也不是3 IV. 有两个学生的学号相同 V. 试题数是负数。

3. 再如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况: I.输入的线性表为空表; II. 表中只含有一个元素; III. 输入表中所有元素已排好序; IV. 输入表已按逆序排好; V. 输入表中部分或全部元素相同

以花瓣网为例:(非功能性)

页面一直往下滑动,图片的资源是否能够加载完成展示?

页面一直往下滑动,浏览器是否会卡住?

所有的图片资源加载完成后,页面上下滑动,已经加载的资源是否再次进行加载?

 

以拉勾网为例:

 

4.因果图方法:输入的数据是多个条件,可以使用排列组合的数学方法来设计测试用例      

       1.定义:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

2.因果图法产生的背景: 等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。 如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。

3.因果图介绍

4种符号分别表示了规格说明中向4种因果关系

 

and关系 以拉勾网为例:

 

 

4.因果图概念:1. 关系 ①恒等:若ci是1,则ei也是1;否则ei为0。 ②非:若ci是1,则ei是0;否则ei是1。 ③或:若c1或c2或c3是1,则ei是1;否则ei为0。“或”可有任意个输入。 ④与:若c1和c2都是1,则ei为1;否则ei为0。“与”也可有任意个输入。2. 约束 输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。

5.采用因果图法设计测试用例的步骤: 1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。 2)分析软件规格说明描述中的语义,找出原因与结果之间, 原因与原因之间对应的关系,根据这些关系,画出因果图。 3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。 4)把因果图转换为判定表。 5)把判定表的每一列拿出来作为依据,设计测试用例。

5.判定表驱动分析方法:更多考虑程序内部在不同逻辑,不同条件下的测试情况,是代码级别的测试

1.定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

2.优点:能够将复杂的问题按照各种可能情况全部列举出来,简明并避免遗漏,因此,利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题

6.正交实验设计方法:

针对排列组合的数学方法设计出的测试用例数据量是庞大的,但是资源(人力和时间)是有限的,那么就选择有代表性的数据来测试,因此该方法更多是和因果图结合的使用

正交实验设计方法:依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法等

利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率

7.功能图分析方法

功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中 的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.

       以拉勾网为例:

8.场景设计方法:

       可以看作是针对不同逻辑不同判断条件下业务场景的测试,可以理解为是系统测试的 一部分,主要考虑的是产品的业务流。 

测试用例的编写和测试用例的评审 

软件测试计划的编写

 

测试计划的定义及目的:

一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了 测试项、被测特征、测试任务、人员安排以及任何偶发事件的⻛险。软件测试计划是指导测试过程的纲领性文档 。计划可以统一认识,可以规划过程。测试计划包含了产品概述、测试区域/测试范围(测试项)、 测试目标(被测 特征)、测试优先级、测试配置/测试资源<硬件、软件、人力、技术等>、测 试周期、进度安排(测试任务、人员安排)、 测试策略、测试方法/途径、测 试交流、⻛险分析、测试标准、需交付文档等内容

途径:通过什么方式 什么技术

资源:时间 人力

测试计划的注意事项:

软件测试计划应当尽早的制定 软件测试计划在测试活动中处于中心位置 它设定了测试准备工作和执行测试的必备条件 同时形成了测试过程质量保证的基础

测试计划内容:

测试范围:测什么?比如:产品的具体业务需求有哪些?产品是web端的还是移动端的,还是两者都有?

测试策略:怎么测?对不同业务需求,具体要有哪些测试类型、测试场景、测试方法

资源安排:测试人员 测试环境 测试工具的安排

进度安排:什么时候开始测试。预计测试多久

发布标准:怎样才算是测完了 达到怎样的标准才能上线

风险预防:最后 我们需要对整个测试过程中可能存在的⻛险,以及当这些⻛险发生时的应对措施提前进行一些考虑和准备,并在测试计划中体现出来

测试计划:(以职位搜索为例)

  

测试方案:(以职位搜索为例)

 

 

 

 

 

BUG提交和BUG生命周期管理

缺陷概述

1)缺陷(Defect):是指存在于软件之中偏差,可被激活,以静态形式存在于软件内部,相当于Bug。 

2)故障(Fault):当缺陷被激活后,软件运行中出现的状态,可引起意外情况,若不加处理,可产生失效,是一个动态行为。

3)失效(Failure):软件运行时产生的外部异常行为结果,表现与用户需求不一致,功能能力终止,用户无法完 成所需要的应用。

4)Bug:电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷,都可以称之为“Bug”;有时也泛 指因软件产品内部引起的软件产品最终运行时和预期结果的偏离。

5)缺陷报告单:指测试执行过程中,发现缺陷失效后,提出书面的报告,提供给开发人员作为定位缺陷的依据

bug提交注意事项:

  • 详细的描述步骤 
  • 详细的日志文件
  • 最好有截图或者拍视频

bug的生命周期:发现bug -提交bug- 分配给开发修改 -开发修改完分配给测试 -测试验证 -通过关闭

    验证不通过-再次分配给开发修改

 

缺陷状态

新建:测试人员新提交的bug、优化或者建议的状态。

进行中:开发人员确认是bug,在修复bug过程的状态。 

已解决:开发人员已修复bug的状态。 

已关闭:测试人员验证修复的bug,确定已解决问题的状态。 

不解决:开发人员认为不是bug,拒绝解决问题的状态或者无法解决问题的状态 

重开:测试人员验证修复的bug,发现没有完全修复好bug,重新打回开发人员的状态。 

暂缓:开发人员认为该bug不急于修复,可以放置一段时间再修复的状态

缺陷类型

bug:测试人员通过测试发现的问题能称为bug。

需求:需要产品经理对需求进一步梳理。

建议:是软件产品改进建议

优化:功能已实现,需要优化问题。可以是用户体现优化、性能优化。

缺陷生命周期

 

缺陷级别

致命:系统崩溃、数据丢失、数据毁坏、安全性被破坏。 

严重:操作性错误、结果错误、功能遗漏。 

一般:小问题、拼写错误、UI布局、罕⻅错误。 

建议:对产品的改进建议

缺陷优先级

紧急:影响进一步测试,需要立即修复。

高:必须在版本发布前修复。 

中:必须要修复,不一定⻢上修复,可以讨论确定在某个时间节点修复好。 

低:对产品影响比较少,不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。

TAPD:

需求:

缺陷:

 

 

 

标签: 软件测试 视频