前言
“尽早的介入测试,遇到问题的解决成本就越低”
随着软件测试技术的发展,测试工作由原来单一的寻找缺陷逐渐发展成为预防缺陷,探索测试,破坏程序的过程,测试活动贯穿于整个软件生命周期中,故称为全程软件测试
全程软件测试,强调整个软件生命周期中,各阶段的测试活动。无论是需求阶段,开发阶段,还是测试阶段,都需要确定在当前阶段测试活动的内容以及成都,确保每个阶段的质量,才能保证产品最终的质量。
全程软件测试
全程软件测试图解
根据全程软件测试的时间轴线图,我们可以发现测试活动贯穿软件开发的整个生命周期,各个阶段测试活动内容如下:
那每个测试活动又到底是如何进行的?需要用的哪些技能或者方法呢?
需求阶段
一、测试需求分析
我个人一直认为需求分析是整个测试活动中除了测试用例设计之外最重要的部分。
-
需求分析目的是理解需求,理解业务。
-
弄清楚我们的产品有哪些功能?有哪些非功能性需求?
-
明白我们的用户群体是什么?用户会如何来使用我们的产品?
那我们到底该怎么来进行需求分析呢?
具体执行如下:
二、测试计划制定
当对需求有完整和全面的理解后,接下来我们需要制定详细的测试计划,为即将开始的测试工作做好充足的准备。对于测试计划的理解,我一直分为两种工作规模去看(个人理解,不正确的地方还请见谅)
小公司团队
小公司测试团队可能本身都没几个人,按照传统理论需要考虑测试活动中各方面的问题,给人的感觉就像杀鸡用3米长的大砍刀一样。
我的理解是小团队的测试计划讲清楚以下四个要素就行。
-
时间:根据以往经验以及需求理解进行时间估算(小建议:时间节点多争取1到2天时间缓冲,项目过程中难免出现意外事件)
-
任务:将测试活动拆分成具体的任务
-
人:任务的执行人以及质量监控负责人
-
风险控制
大作坊团队
大公司测试团队往往是涉及多个项目,整个公司的硬件、时间、人力等资源的分配就更为复杂。在这种情况下,需要对各方面有更为精细的计划。
-
资源估算:整个项目需要多少资源?硬件资源,人力、时间资源等
-
进度控制:每个测试活动时间点控制
-
风险控制:对于在测试活动过程中出现问题的解决方案
-
资源配置:如何更有效率的使用资源
-
验收标准:文档、项目、测试过程的验收标准定义
-
测试策略:测试中使用的测试策略
小结:
在需求分析阶段,测试人员既要详细的理解产品需要,又要从用户的角度出发,分析出需求中不完善的地方,还要协调开发与测试对于需求理解的一致性,保证需求信息在开发和测试双方中的统一。
这也就是尽早的将产品缺陷给暴露出来,也会有效的预防缺陷。
开发阶段
在经过需求阶段的准备工作后,进入开发阶段就意味着撸起袖子加油干的时候。开发阶段对于软件生命周期而言是最重要的阶段。那在这个阶段,又是如何开展测试活动的呢?
一、测试用例设计
测试用例设计是软件测试工作的灵魂。
任何一项测试活动的核心都是测试思维,即如何进行测试。而测试用例就是测试思维的体现。功能的测试优先级、如何操作、输入什么数据、应该有什么的结果等等都体现在测试用例中。那么问题来了
到底怎么设计测试用例呢?
(由于篇幅原因,这次我主要介绍一下接口测试用例设计方法)
首先,我们来看一看接口的执行过程
任何一个接口其实都由这三部分构成,那我们在设计测试用例时就可以根据这方面进行考虑。
针对接口的输入条件进行设计:
针对接口的处理逻辑进行设计:
针对输出结果设计:
其他方面考虑:
-
接口超时处理
-
废弃接口处理
二、测试用例评审
测试用例的评审无疑是为了给测试用例进行查漏补缺。
评审方式:
-
测试内部评审
-
项目组评审:项目相关人参与评审(开发、测试、产品)
注意:
项目组评审时,一般是会议的形式,由于测试用例的数量关系,会议上评审会占用很长的时间,造成时间资源的浪费。
建议大家在评审前先将测试用例邮件发送给评审会议相关人,让他们提前能对测试用例进行了解,熟悉。会议中进行反馈,记录后,会后再修改。
三、测试执行
前面的工作做的充足的话,在测试执行的时候就会非常简单了。只需要根据测试用例一条一条去执行程序即可。发现缺陷就提交缺陷,测试通过就继续回归。
各位看官现在应该是心里一万个XXX呼啸而过~~哪有说的那么简单。
其实测试执行的过程真的很简单,只是在执行的过程中各部门的协作,沟通以及各项文档的输出很复杂。下面我们来聊聊在测试执行过程要注意的几方面问题。
1、测试与开发的沟通
“XXX 我这有个问题,你过来看下”
“什么问题?你演示下我看看”
“这不是问题,这个地方只能这样做”或者 “这不是问题,我刚刚跟需求确认过的”
“这样做不合逻辑啊!”
“那你说怎么处理?”
“我觉得应该....处理”
“你先跟需求确认下吧”
这应该是测试工程师的日常吧。测试与开发沟通无疑是关于某个功能或者产品的,主要围绕几个以下几个点:
-
程序某个地方存在问题
-
产品需求信息在测试和开发中不统一
-
程序某功能应该是怎么处理
-
缺陷修复后的验证
既然知道问题的核心,我们就要想办法规避这些问题。假设一开始提问题的时候就把问题的特征,位置,以及操作步骤,截图都一目了然的提交给开发,是不是很大程度上可以节省测试演示的时间?
另一个最容易出现的问题就是信息不统一,这个需要整个项目组有意识的培养健全的工作流程,通过工作流程来规避这种信息不对称的情况。这种情况将大大增加测试与开发的沟通成本。
2、测试与需求的沟通
测试人员与需求的沟通难点主要还是体现在需求不明确或者需求变更上。
很多时候需求人员的需求文档都是不全面的,测试人员在写测试用例时需要一次又一次的与需求进行确认,一来二去,需求估计有种想把桌子里40米长的大刀放桌上来。
另一方面在项目过程中,不可避免的会出现需求变更,只要出现变更就意味着之前的测试准备工作就作废。
所以在与需求的沟通是非常频繁又火星四溅的,那怎么更好的与需求进行沟通呢?
-
切记不能停留在口头沟通,确认
-
所有的需求确认或者需求变更都需要文档化,实在不行也需要发邮件
-
每一次确认、变更都需要通过项目相关人
-
建立完善的需求变更体系,流程上控制需求变更
3、测试结果的反馈
相信大家应该遇到过偶现的缺陷,开发重现时就没有了,忙活了半天,被开发嫌弃了一顿
测试结果的反馈容易出现问题的地方就是结果描述不清楚,增加项目的时间和沟通成本。解决这个问题最好的办法就是将测试结果尽可能的描述清楚。
测试结果反馈分为两种:
-
在沟通工具中向开发反馈缺陷
-
在缺陷管理工具中提交缺陷
到底怎样提交/描述清楚一个缺陷?在下文中,我会详细介绍。
四、缺陷管理
在开发阶段,测试人员最重要的产出就是缺陷。缺陷不仅仅是数量多,就越有价值。更应该关注缺陷的质量、缺陷的管理以及缺陷分析。
怎么样提出质量高的缺陷?怎么样对缺陷进行管理和分析?见下图
缺陷处理流程图
缺陷管理是软件测试活动中极其重要的一环,很多时候测试用例并没有发现多少缺陷,反而自己在运行程序的过程中发现了很多缺陷,那这些缺陷就是对测试用例的补充,对之后的测试就可以提供思路。
小结:
在开发阶段,测试人员最主要的工作就是发现缺陷,但是在这个过程中会伴随着很多其他的问题,需要我们在工作流程中去规避。最重要的就是把测试放在整个项目中,是各个部门的团队协作。
很多团队的问题并没有出在测试用例设计,测试执行,缺陷提交中,更多的出现在各部门之间的沟通、协作中。
发布阶段
进入发布阶段就意味着产品已经通过了测试,可以发布到线上,交付给用户使用。那如何确认测试已经通过?在发布过程中,我们测试人员又需要完成哪些工作?
测试通过准则规范
上线前,需要确认测试已经通过,现在程序越来越复杂,如果没有量化的规范,就很难确定测试到什么时候可以上线。所以我们需要设定测试通过的准则,只有达到准则才能上线
-
测试需求功能覆盖率100%
-
测试用例通过率95%以上
-
遗留缺陷没有严重程度3级以及以上的缺陷
测试报告
完成测试后,提交测试报告,给出此次测试过程中的数据,例如:测试用例的数量,发现缺陷的总数,各个严重程度的缺陷数量,总共修复的缺陷数量以及缺陷修复率等等
系统回滚方案
每一次发布都不能说百分之百的没有问题,如果真的出现问题,我们该如何处理?
-
如果线上出现的问题不是很严重,尽量当时处理掉再上线
-
如果线上出现的问题很严重,就必须要系统回滚,保证线上用户的正常使用
-
系统回滚方案须跟开发/项目经理确认
线上功能检查
-
程序原有功能的回归测试
-
新上线的功能全面测试
小结:
每一次发布后,测试人员都应该持续反馈,改进、总结每个版本中遇到的问题,不管是缺陷还是流程问题,从一次次的问题中总结一些经验,提高整个软件生命周期的质量
日常维护阶段
产品上线后,用户能稳定的长期使用,就意味着发布的功能进入到日常维护阶段。而这里并不是终点,这个阶段将一直存在。
在这个阶段,测试人员的主要工作就比较简单
-
持续测试,没有产品是没有缺陷的
-
即使收集用户反馈的问题,并尽快组织人员修复
-
长时间稳定性测试(自动化测试)
总结
全程软件测试,关注的是在整个软件生命周期中,各个阶段的测试活动。
测试过程管理
https://blog.csdn.net/winteroak/article/details/80266247
通过对各个阶段的过程质量把控,从而提高产品的测试质量。产品的质量并不是测试能决定的,而是整个项目构建过程中,通过一次次的优化过程,不断的总结成长,是整个项目团队决定的。
不同的工种都在这个过程中起到举足轻重的作用,而全程软件测试强调不断提高每个阶段的质量,最终提高项目团队的综合能力,从而提高产品质量
测试过程管理介绍的内容包括:测试演化、测试设计、测试执行、测试监控。
测试演化
软件测试应该是软件研发全生命周期的测试,包括软件需求测试、软件设计测试、单元测试、集成测试、接口测试、系统测试、用户验收测试和非功能测试等。软件非功能测试一般会有性能测试、容量测试、易用性测试、安全测试等。
迭代开发对应迭代测试
软件开发方式一般分为了多次迭代开发,每次迭代都对应相关的测试,直至整个软件功能齐备然后进行系统测试,如下图所示。
瀑布模型测试
瀑布模型在1970年由 Winston W. Royce 最早提出,提供了软件开发的基本框架。瀑布模型软件开发的生命周期分为用户需求阶段、软件需求阶段、软件分析阶段、软件设计阶段、编码阶段、测试阶段和运行维护阶段,如下图所示。软件开发工作依次进行,给人感觉很有条理性。从测试的角度而言,对于软件需求明确且比较固定的软件项目开发也许比较适合,但对于软件需求不明确或软件需求多变的项目就存在重大的缺点。一是软件需求变化后不能及时响应,二是测试阶段在软件产品发布之前进行,测试中发现的问题和缺陷修复起来将会有巨大的成本。
为了尽量降低瀑布模型缺点的影响,结合 TMMI 思想,在瀑布模型研发生命周期的各个阶段可以加入不同的测试(评审)。例如用户需求和软件需求中都可以进行需求合理性、完整性、逻辑性等方面的测试。在需求分析阶段可以对需求分析的产出进行分析的覆盖完整性,分析的合理性等方面的测试。在软件设计阶段可以对软件设计产物进行设计文档测试,检查设计文档对软件功能和各项指标的要求是否合理和可行。在编码阶段对编码进行代码评审并进行相关的单元测试和接口测试。
V模型测试
由于瀑布模型存在的明显缺陷,根据瀑布模型演变出了 V 模型的软件开发方式。在 V 模型中开发任务由对等的测试任务与其相对,如下图所示。
V 模型中软件测试分成了不同的级别和相关的软件开发阶段相对应。例如组件说明对应组件测试,系统技术设计对应集成测试,软件需求对应系统测试,用户需求对应验收测试。
用户需求是从客户或用户获得的需求,并对需求进行详细的描述,在获得客户或用户的批准和认可后,作为软件开发工作需要实现的特性和功能的输入。软件需求是用户需求在软件的系统功能和架构上的映射,说明的软件需要实现的功能特性以及相关系统指标。系统技术设计是软件系统的具体实现方式,它包括定义系统环境的接口、系统分解成更小更容易实现的子系统,从而每个子系统都可以独立开发。组件说明是提供一个独立功能的软件单元,它定义了该单元的任务、行为、内部结构和与其它组件协同工作的接口。编码是使用具体的编程语言,例如 Java、C/C++、PHP 等,实现已经定义的软件组件,例如模块、单元、类等。
接下来,对 V 模型中的各部分做解释说明。
(1)组件测试
组件测试是针对一个软件单元的测试,组件可以是软件测试的最小单元。组件测试有时也称为模块测试、单元测试或类测试等。组件测试是为了检查相关组件是否满足组件说明或详细设计说明的要求,保证每个最小的单元满足功能和相关指标要求并能够正常运行。组件测试可以由开发人员执行,也可以由测试人员进行。组件测试首先确定最小的测试单元,然后设计相关的测试用例检查功能的正确性、健壮性(对错误输入的适当反应)以及组件的性能。
(2)集成测试
集成测试主要检查系统与系统之间的接口交互是否满足系统设计的要求。集成测试可以发现接口缺陷和系统之间协同工作的缺陷,例如操作系统、文件系统、硬件接口等。
(3)系统测试
系统测试是形成完整的系统后,对整个系统进行测试,检查系统是否满足了软件需求。系统测试中应重点检查软件需求中定义的功能是否实现并能按照需求要求正确运行,功能的输入和输出是否合乎要求,以及非功能的质量特性是否满足软件需求要求。
(4)验收测试
验收测试一般由客户或用户进行,它的目的是检查整个软件系统是否满足由客户需求预先定义验收条件。通常根据客户需求或业务流程进行正式测试,确保软件系统满足客户的要求。
敏捷项目测试
使用敏捷开发管理方式的开发过程一般分为多次冲刺,每次冲刺拥有自己的用户故事,相对应的软件测试既包括新增故事的用户故事测试,也包括已有故事的故事覆盖。因此敏捷项目的开发测试应尽量采用自动化测试来提高开发效率。
常见的敏捷项目测试方法有以下几种。
(1)测试驱动开发
TDD 的全称为 Test Driver Development,测试驱动开发就是开发要以测试为驱动。编码之前,测试先行。
TDD 带来的好处有以下几点。
你会更加站在用户的角度去看你将要完成的产品,你要尽可能想到用户所有进行的操作。而不是从程序员的角度想用户应该会如何去使用我们的产品。
测试用例是对功能进行测试。在写代码之前先写测试用例,可以对我们编写代码提供指导性的参考。防止我们漏掉一些功能。它使我们对自己代码有了信心,因为我们事先设计好的所有测试用例都 Pass 了,如下图所示。
如果在更改代码后测试用例不能通过,我们可以根据不能通过的测试用例精确的定位问题,并轻而易举的解决的这个 Bug。
(2)验收测试驱动开发
验收测试驱动开发英文全称为 Acceptance Test Driver Development,简称 ATDD,是产品人员、开发人员、测试人员都需要参与到产品验收测试中来。在验收测试开发活动中团队需要就需求定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动产品的代码开发和测试脚本开发。一般来说 ATDD 一定是基于测试自动化和持续集成的,如下图所示。
(3)行为驱动开发
行为驱动开发英文全称 Behavior Driven Development,行为驱动开发是一种敏捷软件开发的技术,它鼓励软件项目中的开发者、QA 和非技术人员或商业参与者之间的协作,如下图所示。
测试设计
软件测试指导思想主要有以下三项。
在当前大规模的软件系统生产过程中,软件测试是无法找到全部缺陷的。
发现大规模系统中的所有缺陷是一个无限期的工作,而能用于测试的时间、人员、设备是有限的。
测试的关键,就是测试的覆盖。应该使用有限的测试资源完成最有价值的测试覆盖(用户使用的软件功能应该完全覆盖测试)。如下图所示。
案例设计技术
软件测试技术分为白盒测试和黑盒测试。白盒测试技术一般使用在代码走查、单元测试、接口测试等较为底层的测试类型当中。白盒测试当中一般使用语句覆盖和判定覆盖案例设计方法。黑盒测试一般使用在系统功能测试和验收测试中。常用案例设计方法包括等价类划分、边界值分析、决策表、状态转化测试等。
总体而言,软件测试设计遵循以下指导原则:
依据系统功能进行测试大纲的设计,保证测试的覆盖范围;
引入用户场景的描述,保证测试覆盖的重心不偏离;
进行系统的业务流程分析和数据流向分析,保证测试数据的全面性;
依据被测试部分的复杂度和关键度以及质量的要求,选择不同的测试设计方法;
针对用户的业务特征、角色权限和数据特征,进行流程测试设计,保证测试与实际应用的一致性;
按照用户需求,功能的复杂度、重要度和测试执行的要求,对测试用例进行优先级、适用阶段的分类,保证测试设计可以更好地指导测试执行。
执行测试用例评审活动,保证测试设计的准确性。
测试执行
软件测试执行,是指执行测试用例,并发现系统缺陷的活动。测试执行与缺陷修正活动同时开展,它是软件测试的关键环节。
软件测试执行,是软件测试活动中周期最长,工作量最大的环节,在测试执行中要关注以下内容:
接收测试
回归测试
扩展测试
交叉测试
自动化测试
缺陷管理
4.测试监控
需求和测试的双向追踪
需求的变化应该反映在测试需求跟踪矩阵表中,并进行测试需求分析、测试范围调整。测试计划、测试用例、测试执行也应有相应的改变和对应,如下图所示。
测试过程的质量控制和质量保证活动
在测试过程的每个阶段,均应有相对应的 QA 和 QC 活动相对应。
例如,测试准备阶段应该评审需求变更和测试方案。在测试设计阶段应该评审开发计划、测试计划、接收测试标准、风险管理计划等。在测试执行阶段应该监控测试进度、缺陷密度和缺陷分布。测试总结阶段应该编写测试总结报告对测试状态、缺陷数据进行分析;测试过程的经验教训也应该总结。相关测试数据和缺陷数据应该进入质量数据库,为以后测试过程改进提高支撑。
本文主要对测试管理的要素人、过程和技术以及测试过程进行了说明。由于测试管理是一个庞大的话题,作者从个人工作经验的角度进行了总结。欢迎大家参加讨论。
GITBook:测试管理要素