一个完整系统的测试过程 软件测试流程-全程软件测试

时间:2024-02-15 21:21:40

 

 
一、需求审查方面
  首先我们从最开始接触的文档开始,那就是测需求文档;需求审查主要是我们对需求文档的理解,并熟透整个系统的每个功能和流程,对后期所有的测试建立思路,后续的工作基本依照需求进行操作,所以需求审查是一个很重要的一步。
  对于初次进行需求审查,我采用我以前文章的方向方法,看完每一个模块,就将这个模块的功能流程做成流程图。依次扩大,就将整个需求流程了解清楚,每次将流程图多浏览几次,差不多流程就这样熟透!
  1、 需求变更
  需求变更让我们测试人员,在其中吃透苦头,每次需求的变更导致我们前期的工作好多都需要重新开始(流程图,测试点的提取,测试用例)。导致后续工作难于开展或经常出现变更。
  2、 需求不明确
  对于青少年足球系统而言,需求全来自教育厅,里面同样有很多需求不明确,全过程尽量与教育厅的需求进行延伸,然后结合开发人员实际开发的效果,进行测试过程!
  二、提取测试需求的过程:
  测试点提取我们依据每个测试阶段的测试输入的文档(需求分析)结合前面的需求分析的审查,覆盖测试需求和隐藏的业务需求,我们后期的测试,全是建立在提取的测试点之上进行的,可以说测试点提取是后续工作进展必要必经路径。主要步骤就是,将每个模块可能存在的问题全部罗列出来,并对其最初可以输入或者流程路径的不同,将每个测试点细分,写成文档!
  测试点提取的方法:
  1、测试需求分析法
  2、功能点分析法
  3、业务流程分析法
  4、节点分析法
  5、顺序提取法
  6、流程判断法
  在测试点提取的过程中,测试人员主要存在的问题是,除了输入框,链接,按钮,文字显示等外,流程测试点是最难提取的(提取此处测试点需要了解整个流程),我们采取的方式是,多阅读需求书,并且按照我们的思路将流程图做出来,在提取测试点,最终交于指导老师处,一对一的修改,另一方面,就是对那些隐藏的测试点提取,对于初次做项目测试的我们,基本没有择,只能和指导老师一起寻找和编写!
  ●测试点提取不局限于任何一种特定的方法。
  ●很多时候测试点提取需求用到很多测试点提取方法
  ●测试点提取需要根据测试阶段,测试输入文档以及测试对象进行合理的方法选择。
  ●测试点提取完毕后不等于已经测试点提取完毕,还需要我们再次进行测试点的审查,以防有遗漏或者是泛泛的情况
  ●一份好的测试点提取文档不但能够覆盖所有业务分支和功能点,而且能够将相关隐藏需求体现出来
  三、测试用例设计
  测试用例是为特定的目的而设计的一组测试输入,执行条件和预期结果,以便测试某个程序路基和核实是否满足某个特定需求!
  在做功能测试时我们唯一能做的就是保证这个业务逻辑的正确性以及各个功能的尽可能的正确。业务和功能的正确性就要你自己去判断了,我只是简单写下输入、输出方面功能的测试。
  作为一位功能测试人员,主要的职能就是进行测试用例的设计上,并根据测试用例执行测试,通过全面的测试来验证产品的质量。因此测试用例提取,也从侧面反映了一个测试人员的测试思路的严密和发散性,要做好功能测试,测试用例的重要性无法忽视,现就对”四川省青少年校园足球信息化管理系统”设计测试用例的流程和思路进行总结:
  1)首先要对测试用例的组织结构进行划分
  在进行需求评审的时候,我们就应该根据需求对测试用例的结构进行分类,对于我们现在做的青少年足球系统相对较大型的管理系统,那么测试用例就可以根据功能模块来进行分类
  对测试用例的组织结构进行划分的思路,主要根据需求文档的测试切入点来进行参考。
  2)根据功能点细致地设计测试用例
  进行完需求评审后,我们将会根据需求文档及自己所负责的工作提交自己的设计文档来进行评审,可以参考设计文档中的内容提取出各个功能模块中的功能点来设计测试用例,如果是管理模块,首先可以将增删查改功能作为第一层功能点,然后再根据必填项非空判断、输入格式验证来作为第二层功能点;
  划分好功能点后,就可以利用等价类划分、边界值分析等一些测试方法来编写测试用例,并且可以进行标注,这样对于后期的测试用例整理相当有帮助。
  3)执行完一轮测试之后,都要对测试用例进行补充和整理
  执行完一轮测试之后,都会对所测试的内容有进一步的了解,并且开发人员在实际开发过程中,会对某些功能的细节部分做出一些修改,测试人员应该根据变更和熟悉程度对之前编写的测试用例进行完善,主要是对测试步骤的修改和异常情况的补充,提高测试用例对需求的覆盖率,以便能发现更多的BUG。
 
 
4)测试结束之后,根据测试用例整理出测试思路进行总结
  测试结束之后,测试人员在提交测试报告之后一般基本就会有一段短暂的休闲期,在此期间,再看看被自己不断完善的测试用例,根据用例中的标注,可以将之前的测试思路很条理地整理出来,反思有哪些地方考虑不足,这就是经验积累。
  做好这些工作之后,在面对领导问你功能测试会测试到哪些功能,会测试哪些情况,执行一轮测试所需的大概时间问题时,测试人员就可以根据自己编写的测试用例进行流利回答。套用郭德刚的一句词:做科学的人都是很严谨的。大家作为都是有身份证的测试人员,只有工作做得细致严谨,自身的水平才能得到提高。
  A.测试用例该如何设计(总)
  在软件测试工作中,测试用例设计和编写时最重要的,测试用例是测试工作的指指导,是软件测试的必须遵循的原则,更是软件测试质量稳定的基本保障!
  1.     测试用例的测试
  个人认为,简单来说,就是方法+经验,即比较成熟的测试用例设计方法为指导,再加上设计人员个人的经验积累!
  设计入手:
  ü 菜单树
  ü 需求规格书,模块的详细规格图
  ü 软件的基本雏形
  ü 相关标准规格(软件规格书)
  设计步骤
  自我认为多看需求文档,多与需求设计人员沟通,至少保证覆盖需求规格说明书和菜单树的各项功能。
  ü 根据需求规格和菜单树得出基本功能测试用例;
  a)等价类划分法
  将输入范围进行划分,测试每个等价类的代表性数据等同于测试该类的其他数据。确定有效和无效等价类,一个等价类,如果有充足理由,可以再划分为多个更小一些的等价类。部分更小一些的等价类,就凭借个人经验和用户角度去考虑取舍。
  b)功能,路径混合分析法:即实现某功能,从进入功能实现——退出的各种路径的操作组合。
  进入:如果只有一种进入方式,则就没必要描述了,2种或者2种以上的进入方式,则需要分别描述。常见的进入方式:主菜单进入,链接进入!
  功能实现:通过主页导航界面进入并实现相关功能
  退出;为实现和已实现的功能退出
  ü  边界值测试用例(所谓边界条件,是指输入和输出等价类中那些恰好处于边界,或超出边界,或在边界一下的状态)
  a)输入值
  b)输出值
  c)边界状态
  在我们的足球管理系统中,对照片的缩放,就用到这一块!
  d)其他边界
  ü  容错测试用例(错误猜测主要是一项依赖于直觉的非正式的过程,其基本思想是列举出可可犯的错误或者错误易发生情况的清单)
  a)0或者空值
  b)负数
  c)删除源文件内容
  我们在赛事测试的过程中,设计上传参赛表明表,在测试过程中,我将部分信息删除,进行测试!
  ü  并行测试用例(即多个功能同时进行,比如:在青少年足球系统中,我们需要在发布赛事以后,同时进入公示,并且下级报名依然不能给报名)
  a)并行测试与交叉测试的区别
  1.交叉测试是当一个功能运行时,另一功能打断了原来事件的执行,属于被动;并行测试不会中断原有程序,是一个主动发起多功能。
  2.交叉测试发送在一瞬间,并行测试营同时运行一段时间。
  ü串行测试用例(主要是单个模块内一串深层次路径的测试,采用自顶而下的方法,从程序的顶部一直访问至程序顶部)
  比如:像我们青少年足球系统,我从首页进入赛事发布成功进入公示页面,然后再往上级返回到网页首页!
  ü  交叉测试用例(交叉测试,即是中断测试,当一个事件执行时,另一事件中断原有事件的执行。)
  a)两不写
  1.操作时间过短,如:我们按下首页的赛事发布管理按钮
  2.使用概论低的界面,如:我们青少年足球系统中,下面的脚码出的超链接,我们很少点击
  b)两必写
  1.操作时间长,如:在我们的青少年足球系统中,登陆账号后,30分钟对网页没有做任何处理,是否有报警触发。
  ü 极限测试用例(压力测试,就是个软件施加一定的压力,从而找出中的错误)
  这一块我在整个系统使用的很少,还处于学习阶段!
  a)测试用例的检查
  1.检查,写完后自己在重头到尾的检查一遍,然后再拿给我们的小伙伴一起查看
  2.试用,测试用例写完后应该有一个使用期,在我们使用的过程中发现漏写或者不合适的地方,应及时增加或者更改。
  b)“期望结果”与”测试方法”混淆,”期望结果”中出现原本该书写在”测试方法”的步奏
  c) 但是上面是错误的,应该按照下面方法进行设计编写
  B.再次总结测试用例设计的要点,注意事项
  测试用例设计是个不断思考的过程,首先要搞清楚自己所测试的软件系统的需求和功能,以及所有能变化的因素,将这些功能点列成一个设计框架,在分别细化各个功能点的测试方法和期望结果,细化过程中,通过等价类划分,正交矩阵等方法来详细各个测试点,保证覆盖的充分性,同时站在用户的角度,考虑用户常用和不常用的操作路径,依次来取舍测试要点,最后考虑设计步奏中的七种测试类型是否需要添加相应用例。
  测试用例设计也是个不断优化的过程,平时发现的bug,总结经验,积累更多的经验,测试用例也会更全面,软件品质也能得到更好的保障!
  四、测试报告缺陷的提交和编写
  A.强调这一块的重要性!
  下面就是我们在测试过程的满足的条件:
  精简的:缺陷的描述应该是清晰而简要的。
  正确的:提交的问题确实是一个缺陷。
  中立的:对缺陷及其特征进行实事求是的描述,避免夸张、幽默、讽刺的态度,避免在测试缺陷报告中带有个人感情色彩,因为这种感情色彩可能会影响团队之间的合作和沟通。
  准确的:准确而明白地描述问题,不仅对做了什么进行描述,而应该对发生或者发现了什么进行描述。
  隔离:尽量寻找简短的步骤复现缺陷,即将缺陷进行隔离。
  推广:确定系统其他部分是否可能也存在同样的问题,以及使用不同的数据时是否也会出现这种问题等。
  复现:确定系统是否可以复现这个问题,以及复现该缺陷的步骤。对于能够复现的问题,应该提供简单的步骤和输入
  证据:如同写测试用例需要测试条件一样,在缺陷报告中,需要提供测试的期望结果和实际得到的输出结果或者行为之间的差距,以及提供测试的依据。
  评审:在提交缺陷报告之前,最好有一个有经验的测试人员阅读一遍。  
  缺陷报告编写的过程:
  B.缺陷报告的提交
  缺陷报告的提交,在测试过程中,我们采用了两种方式
  1、提交给我们的指导老师!接下来的工作就是指导老师与相关开发人员沟通(这种提交的方式是我们前期的提交方式)
  2、便是跳过我们的指导老师,直接将问题和呈现过程交于开发人员,并且让其快速修复!(这种方式比较快捷,能够快速的解决问题和加快开发的过程)
  C.如何编写好的(易读)的缺陷报告
  1、标题(简单明显,不需要含有修饰语)
  2、执行动作(步骤)
  3、预期与实际结果
  D.缺陷报告的返回,检验是否修改!
  此环节,主要在我们提交缺陷报告后,开发人员将缺陷报告再次返回与我们测试人员,测试人员主要是检查缺陷报告上面的问题是否已经修复,一遍我们能够提交缺陷报告和了解缺陷的修复情况!
  E.并描述与开发人员的交互过程
  在我们与开放人员交互的时候:交互过程中存在的问题,当部分子功能模块做出来的时候,我们测试人员开始测试子功能模块的时候,测出问题的时候,我们便直接与开发人员提出此问题,可能是刚开始合作,还有他们对自己写的代码还有强烈的自信感!对我们的问题采用避让的方式,在我们继续的讲述和演示功能的过程,才得以让他们信服。现在这些问题都不存在,都能够在规定的时间完成每个功能的修复!
  F.过程中的问题如何解决
  输入框和文字显示在此不做详细说明,我在项目中主要是承担逻辑很强的赛事模块,这块设计的逻辑和流程交互挺多,除此测试这块的时候很难把握流程问题,整个项目在随时改变和需求分析存在一定的差异,所以造成这块测试逻辑流程比较难以实施,为了更好的完成测试,我采用了,进行测试之前,然相关模块开发的人员演示一下流程,让我更好的进程下一步测试!
  G.最后对测试缺陷报告的综述(好方法,注意事项,怎样才能够做好测试缺陷报告)
  测试执行过程注意事项:
  注意前提条件和特殊说明
  测试用例要全部执行
  不要忽视任何偶然现象
  加强测试过程的记录
  详细预期与实际的不一致等
 

前言 

“尽早的介入测试,遇到问题的解决成本就越低” 

 

随着软件测试技术的发展,测试工作由原来单一的寻找缺陷逐渐发展成为预防缺陷,探索测试,破坏程序的过程,测试活动贯穿于整个软件生命周期中,故称为全程软件测试

 

全程软件测试,强调整个软件生命周期中,各阶段的测试活动。无论是需求阶段,开发阶段,还是测试阶段,都需要确定在当前阶段测试活动的内容以及成都,确保每个阶段的质量,才能保证产品最终的质量。

 

 

全程软件测试

 

全程软件测试图解

 

根据全程软件测试的时间轴线图,我们可以发现测试活动贯穿软件开发的整个生命周期,各个阶段测试活动内容如下:

 

 

那每个测试活动又到底是如何进行的?需要用的哪些技能或者方法呢?

 

需求阶段

 

 一、测试需求分析

我个人一直认为需求分析是整个测试活动中除了测试用例设计之外最重要的部分。

  • 需求分析目的是理解需求,理解业务。

  • 弄清楚我们的产品有哪些功能?有哪些非功能性需求?

  • 明白我们的用户群体是什么?用户会如何来使用我们的产品?

那我们到底该怎么来进行需求分析呢?

 

具体执行如下:

 

二、测试计划制定

         当对需求有完整和全面的理解后,接下来我们需要制定详细的测试计划,为即将开始的测试工作做好充足的准备。对于测试计划的理解,我一直分为两种工作规模去看(个人理解,不正确的地方还请见谅)

 

小公司团队

         小公司测试团队可能本身都没几个人,按照传统理论需要考虑测试活动中各方面的问题,给人的感觉就像杀鸡用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:测试管理要素