【软件测试】从零开始的软件测试 基础篇(02):测试流程

前言

从零开始学软件测试这个系列会分成三个阶段

基础篇
过渡篇
自动化测试篇

基础篇(01)谈过了bug的分类,让大家对软件测试的工作对象有了简单的了解,这篇基础篇(02)将会带大家具体了解测试流程,也就是怎样才能更好地找bug

正文

测试过程(以下左图)与测试阶段(或类型)(以下右图)图-1
图文说明

  1. 以上左图描述的通用软件测试过程。右图描述的是具体的测试活动阶段,按不同的测试阶段分可分单元测试、集成测试、确认测试、系统测试、验收测试,回归测试,冒烟测试等测试类型。

  2. 回归测试是指修改了旧代码后,重新进行测试以确认缺陷的修复,及修改没有引入新的错误或导致其他代码产生错误。软件开发的各个阶段都会进行多次回归测试。

  3. 冒烟测试(也叫提交测试),正式测试前对软件主业务流程和主功能进行验证与确认,确保后续测试能正常进行的测试。现状:一般是在新版本提交前,进行正式测试前的进行冒烟测试

  4. 右边的每个测试活动阶段,可以按左侧的测试过程进行,文档评审,测试计划、测试设计、测试执行、测试总结等(可根据实际情况对测试过程进行适度裁剪)

  5. 左边的和右边两幅图进融入软件开发过程中,就产生了以下将说到的各种测试模型

  6. 阶段(类型)细分:如下图在这里插入图片描述
    测试过程和开发过程协作(典型模型举例说明)

W模型为例

图-2

强调说明

  1. 其中系统设计也叫概要设计。

  2. 软件需求评审,主要是评审软件需求规格说明书、主要依据是产品需求文档

  3. 系统设计评审,主要是评审系统架构设计等,主要依据系统概要设计说明书

  4. 详细设计评审,主要是评审详细的设计,比如接口设计是否合理,主要依据详细设计说明书

ps:现实状况是:一般的公司,一般的项目都做不到这么规范的
有些公司甚至没有文档,目前我见过的比较规范的也就银行的质量管理(瀑布模型对银行类项目似乎还是比较实用的)

H模型

在这里插入图片描述

说明:

  1. V、W模型均存在一些不妥之处。如前所述,它们都把软件的开发视为需求、设计、编码等一系列串行的活动,而事实上,虽然这些活动之间存在相互牵制的关系。
    但在大部分时间内,它们是可以交叉进行的,虽然软件开发期望有清晰的需求、设计和编码阶段,但实践告诉我们,严格的阶段划分只是一种理想状况。
    试问,有几个软件项目是在有了明确的需求之后才开始设计的呢?
    所以,相应的测试之间也不存在严格的次序关系。同时,各层次之间的测试也存在反复触发、迭代和增量关系。
    其次,V、W模型都没有很好地体现测试流程的完整性。
    为了解决以上问题,提出了H模型。它将测试活动完全独立出来,形成一个完全独立的流程,将测试准备活动和测试执行活动清晰地体现出来。

  2. H模型图仅仅演示了在整个生存周期中某个层次上的一次测试“微循环”。
    图中的其他流程可以是任意开发流程。
    例如,设计流程和编码流程、也可以是其他非开发流程,甚至是测试流程自身。也就是说,只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以(或者说需要)进行了。

  3. 概括地说,H模型揭示了:

  • 软件测试不仅仅指测试的执行,还包括很多其他的活动。
  • 软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。当某个测试时间点就绪时,软件测试即从测试准备阶段进入测试执行阶段。
  • 软件测试要尽早准备,尽早执行。
  • 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的,但也可能是反复的
  1. 结合软件项目开发流程,不同开发阶段,可以根据实际情况,把图-1的测试过程融合到不同开发阶段中(可根据实际情况对测试过程进行适度裁剪)。
    如需求分析阶段,可以用纳入“文档评审”过程,进行业务需求文档评审和软件需求规格说明书评审,同时也纳入“测试计划“,”测试设计“对系统测试进行计划和设计。
    系统设计阶段,可纳入“文档评审”过程,对系统架构设计说明书,概要设计说明书进行评审

测试过程详述

测试计划

测试计划阶段主要工作包括确定测试目的,测试约束,测试需求,测试风险,测试策略,测试资源,测试量化计划,测试进度,测试计划工作量,交付物

测试计划阶段

  • 确定测试目的,测试约束,测试需求,测试策略等。
  • 依据历史数据、类似项目数据和估计的系统测试用例数,估计测试工作量与测试进度。
  • 根据估计出的测试工作量和项目计划,估计测试资源(人力资源及环境资源,工具)
  • 根据测试工作量、测试资源、进行风险分析与规避。
  • 编制测试计划;
  • 评审测试计划

测试设计

定义:分析测试需求,设计测试用例,进行测试用例的评审并跟踪测试计划的执行情况

测试设计阶段

  • 测试相关人员参与软件需求开发过程,分析软件测试需求,参与软件需求评审,确保软件需求的可测性。
  • 编写测试需求,并设计测试用例。
  • 组织搭建测试环境,准备测试数据。
  • 评审测试用例设计。

测试执行

定义:通过测试执行过程中的版本控制、测试环境监控、测试执行进度控制以及变更控制等手段,确保测试对象的质量。

测试执行阶段

  • 测试相关人员进行测试脚本的编写和修改。
  • 测试相关人员建立测试执行流并进行联调。
  • 测试相关人员分配测试任务给测试执行人员。
  • 测试相关人员根据测试用例执行测试,保证测试用例的覆盖率达到测试计划要求。
  • 测试相关人员记录测试结果,跟踪缺陷的修改状况并对修改完成的缺陷进行验证。
  • 测试相关人员对测试环境进行监控,并组织进行测试过程量化数据的搜集工作。
  • 测试相关人员进行对测试执行进度进行跟踪控制

测试总结

定义:对完成的测试任务进行分析、总结,并给出测试结论或建议。

测试总结阶段

  • 测试相关人员评估测试活动。
  • 测试相关人员分析测试结果。
  • 测试相关人员组织编写测试报告。
  • 测试相关人员进行测试报告评审。

测试阶段详述

单元测试

定义:主要由开发人员对编写的代码进行自测和交叉测试,检查代码是否实现模块功能,是否符合编码规范,是否存在明显的逻辑错误。

单元测试

  • 编写单元测试用例;
  • 执行单元测试,进行自测和交叉测试;
  • 记录单元测试结果;
  • 评估单元测试活动的有效性;

集成测试

定义:将通过单元测试的模块逐步组装成具有良好一致性的完整的程序,制订集成测试实施策略,确定集成测试的实施步骤,设计集成测试用例,逐一地添加模块进行测试。

集成测试

  • 编写集成测试计划;
  • 开发集成测试用例;
  • 执行集成测试;
  • 对缺陷修复版本进行回归测试;
  • 记录集成测试结果;
  • 进行增量集成模块测试,重复步骤(二)~(五),直到增量集成结束;
  • 编写集成测试报告;
  • 评审集成测试报告

确认测试

定义:确认测试本身就是属于系统测试,只是有时候强调它的重要性,而单独出来。确认测试确认测试又称有效性测试,的目的是向未来的用户表明系统能够像预定要求那样工作。

确认测试

软件测试的工作归结起来就是两个V,Verification和Validation 。

Verification翻译为验证,在在 ISO9000 中,“验证”的严格定义是:验证是通过检查和提供客观证据,表明规定要求已经满足的认可。

Validation翻译为确认,在 ISO9000 中,“确认”的严格定义是:确认是通过检查和提供客观证据,表明一些针对某一特定预期用途的要求已经满足的认可。

从定义上可以看出“验证”关注是否满足规定,即需求规格说明书
“确认”关注的是是否满足预期用途,即用户的真正需求
我们知道,软件的设计,编码实现都是依据软件的需求规格说明书。对于软件测试来说单元测试,集成测试,系统测试的目的是验证软件是否符合软件的需求规格说明,因此都可归于验证过程。
然而需求规格说明书并不能代表用户的真正需求,而且依据需求的设计也往往同需求会有些偏差,所以得出的软件产品在经过了系统测试以后还需要进行确认测试。
确认测试软件产品是否就是用户想要的产品。

最简单的解释是:

Verification:Are we building the product right?

(功能验证)是否按需求做出了正确的产品

Validation:Are we building the right product?

(有效性确认)是否作出了用户想要的产品

总而言之,验证针对的是软件规则需求说明书,检验软件是不是根据需求来设计实现的,确认针对的是用户,检验软件能否满足用户的需求。

图-3
备注:是否要采用确认测试具体要看被测系统的大小。如果被测系统是比较大型的系统,包括软件、硬件等,就需要在集成测试后进行专门针 对软件子系统的确认测试,然后再针对整个系统进行系统测试;如果整个系统就是由软件构成的,就不需要进行专门的确认测试了,在集成测试后直接进行系统测试 就可以了。

系统测试

定义:验证需求规格说明书中的各个功能点是否齐全、是否正确实现,同时对系统的安装、部署、适应性、信息安全、界面等非功能性需求进行测试。

系统测试

  • 编写系统测试计划;
  • 开发系统测试案例;
  • 执行系统测试;
  • 记录测试结果;
  • 编写系统测试报告;
  • 评审系统测试报告

用户验收测试(UAT)

定义:验证需求规格说明书中的业务功能是否满足,并关注系统界面、响应时间等非功能性需求。

用户验收测试(UAT)

  • 制定UAT测试计划;
  • 编写UAT测试用例;
  • 执行UAT测试;
  • 记录UAT测试结果;
  • 编写UAT测试报告。
  • 评审UAT测试报告

后话

以上无绝对描述,具体情况具体分析

测试行业虽然已经步入很多互联网公司的眼帘,但依旧势微,很多公司都不是按着标准的流程再走,况且每家公司不一样,项目不一样,资源不一样,开发模式不一样,流程自然也会不一样
但是讲述本系列的目的,不只让大家知道这些知识,而是需要了解大致思想,了解了测试的思想就可以根据实际情况进行适度裁剪,该有的还是要有的,即便是敏捷测试
以上总结,主要是帮助新手入门,让新手有个大概的印象

最后大家又想交流学习的,可以来我的大家庭聊聊呀点击并输入暗号:CSDN
有资料大礼包相送哦
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/Chaqian/article/details/108852187