精华内容
下载资源
问答
  • 测试设计技术

    千次阅读 2018-05-04 09:03:21
    本文是根据测试架构师修炼之道(第二部分 突破:向软件测试架构师的目标迈进)整理的,主要分为5个小部分:测试设计四步走、测试设计软技能、设计技术之控制用例粒度、设计技术之自动化测试、设计技术之探索式测试。...

           本文是根据测试架构师修炼之道(第二部分 突破:向软件测试架构师的目标迈进)整理的,主要分为5个小部分:测试设计四步走、测试设计软技能、设计技术之控制用例粒度、设计技术之自动化测试、设计技术之探索式测试。学习的话优先学习测试设计四步走,四步分别为建模、设计基础用例、补充测试数据、扩展用例;在此基础上学习用例粒度控制、自动化测试、探索式测试,对测试设计及测试用例有基本的理解和认识,最后辅以测试设计软技能,不断融会贯通,结合实际项目应用,定会有收获。

          第二部分详细阅读笔记请参考我之前的一篇博客文章,https://blog.csdn.net/zimingzim/article/details/80149047,希望对各位有所帮助。


    展开全文
  • 测试设计之状态转换图

    万次阅读 2018-06-01 16:57:24
    基于状态转换软件测试设计是软件测试设计的另一种方法,这种方法具有以下4个特征: (1)软件测试对象的输出和行为方式不仅受当前输入数据的影响,同时还与软件测试对象之前的执行情况、之前的事件或以前的输入数据...

    状态转换图简介    

    基于状态转换的用例设计是软件测试设计的一种传统方法。这种方法具有以下4个特征:

      (1)软件测试对象的输出和行为方式不仅受当前输入数据的影响,同时还与软件测试对象之前的执行情况、之前的事件或以前的输入数据等有关。
      (2)通过引入状态图(State Diagram)来描述软件测试对象和软件测试数据、对象状态之间的关系。
      (3)状态图中的各个状态是通过不同的事件驱动的,如函数的调用。
      (4)基于状态图开展的测试称之为状态转换测试。
        状态图转化法最早运用于嵌入式测试用例设计。在嵌入式软件中,系统通过某种行为驱动能够从一种状态改变到另一种状态。下面的示例图是关于内存的状态转换图。
      

    状态转换树

      上面的状态转换图“循环往复”,不利于初学者理清状态转换关系。下面以视频播放软件作为案例,来给大家介绍一个比较简单易懂的状态转化图,如下图所示。

      上图为一个主流程为“开机”-“运行”-“停机”流程结构呈“树状”的状态转换图,也可以称为状态转换树。
           从图中可以清晰得看出这个软件的功能是:打开视频播放机,系统处于"开机"状态,单击【运行】键,系统处于"运行"状态;单击【停机】键,播放结束,系统处于停机状态;在"运行"状态单击【快进】键,进入"快进"状态,【快进】键最多可以按4次,分别为2倍数、4倍数、8倍数和16倍数前进;快进状态单击【停止】键返回"运行"状态,停机状态单击【播放】键,重新进入"运行"状态。

    状态转换图转为状态转换树的方法

    复杂的状态转换图不利于编写完备的测试用例,为此,我们需要将其转换为状态转移树,然后基于状态转换树去设计每个阶段的测试用例。转换的基本思路是:

      (1)状态树的节点描述状态图的状态,状态树的枝干描述状态图的事件。
      (2)转换树的根节点为状态图的初始状态,转换树的终节点为叶节点。
      (3)转换树的每个节点,在状态图中如有直接后续状态,则添加一个枝干和节点(不同的事件应有不同的枝干和节点),直到出现如下情况,可将此节点作为叶节点:
      从根节点到新添加的节点的路径上已经出现过相同状态。
      或者:
      新添加节点是状态图的一个结束状态,且不需要考虑其他状态转换。
      来源:"Testing Software Design Modeled by Finite-State Machines", IEEE Transactions on Software engineering, vol.4, no 3, may 1978, p 178-187
      状态转换软件测试覆盖率:
      (1)覆盖软件测试对象所有的状态;
      (2)覆盖软件测试对象所有的事件;
      (3)覆盖软件测试对象所有的状态转换至少一次;
      (4)覆盖软件测试对象所有的状态、事件和状态转换。
     下面讨论视频播放软件状态图是如何转换成状态树的。
      下图为该软件的0-switch转换图。有了这棵树,就可以设计测试用例了。从树的根节点到所有叶子节点就是一个测试用例,这样就得到4个测试用例,分别为:
      
      (1)开机->运行->快进->运行;
      (2)开机->运行->快进->快进;
      (3)开机->运行->停机->运行;
      (4)开机->运行->停机。
      上面这棵树叫作0-switch展开,也就是最基本的展开法。为了得到更多的测试用例,可以把这棵树的非结束的叶子节点再进行一次展开,也就是1-switch展开,如图2-7所示。
      这样,可以得到7个测试用例:
      (1)开机->运行->快进->运行->快进;
      (2)开机->运行->快进->运行->停机;
      (3)开机->运行->快进->快进->运行;
      (4)开机->运行->快进->快进->快进;
      
      (5)开机>运行->停机;
      (6)开机>运行->停机->运行->停机;
      (7)开机>运行->停机->运行->快进。
      按照这种方法可以设计2-switch、3-switch……但是,在实际 工作中,航空和医疗等特殊领域除外,一般做到1-switch就已经足够了。

    展开全文
  • 测试计划、测试设计、测试执行

    千次阅读 2017-09-01 10:59:04
     最近在一个接一个的做项目,每做一个项目都有不同的感受,我想按照测试计划,测试设计,测试执行三个方面梳理一下,和大家谈谈感受 。  最初做测试计划的时候会根据测试工作量来估评测试时间和资源,然后对...

    测试计划
      最近在一个接一个的做项目,每做一个项目都有不同的感受,我想按照测试计划,测试设计,测试执行三个方面梳理一下,和大家谈谈感受 。

      最初做测试计划的时候会根据测试工作量来估评测试时间和资源,然后对三轮测试的时间点做一个细分。可是随着经历越来越多的项目,感受到这样计划是远远不够的,为了避免后续的测试执行工作节外生枝,我们在做测试计划时就必须多想一点,不光要多想还得想细致了。下面我谈一下项目计划中存在的风险,因为整个计划中有很多模块都是模板制定的,只有风险这一块需要经验积累才能识别更多,谈到的还是不很全面的,和大家交流交流。

      1.提交应用测试的前提保证

      这里说的提交应用测试的前提保证是指提交测试的时间,和提交测试的质量保证,如果说项目中开发新人较多,或者说项目属于改造重构性质的,这个能否按时按量提交测试是更需要关注的,那么面对这样的风险我们如何做好计划呢?

      首先是在开发提交测试之前就需要pm整理出自测场景表单,然后我们评估是否有遗漏。那么对于这个是否遗漏又该如何把控呢?基本上是项目中每个模块中的主功能点必须进行自测。

      其次需要和pm及时沟通,询问现在项目是否存在这样的风险,如果pm说按时提交测试确实有,那我们听下pm的打算并可以根据具体情况给出我们的建议,然后一定要求开发按照自测表单上的场景自测完全。

      2.测试过程的保证

      大部分项目在测试过程中都是按照三轮模型来执行,可是具体细节会根据项目性质的不同而不同。比如说有的项目涉及第三方,那么你在计划中就必须考虑到第三方合作伙伴那边出了问题该如何解决,找谁解决,同时需要注意解决方式,这里建议大家在和第三方合作的时候用邮件来说明问题并抄送合作方的老大,这样解决问题比较有效率。如果项目中涉及多条产品线,那么计划中就需要考虑到产品线合作间的划分问题以及依赖关系等等。

      在做测试计划时就尽可能的将会发生的问题想到,并评估该风险发生的概率,事先想到缓解措施,那么你在后期的项目执行中才能有条不紊的按计划进行。

      记得上次培训的时候老师也说过用户经验的积累是最有价值的,我现在感觉能很好很全面的做出计划也是很有价值的。

    测试设计

      从刚开始做测试起,接触的设计就是先以rose整理出流程图,必要时还需要用到子流程,从而一点点的将功能点的逻辑整理清晰,形成自己的思路,再转换成用例。可是后来渐渐做了几个项目之后,就感觉出问题来了。

      1. 常常比较细节的点在流程图中体现不出来,从而设计过程中没有关注它,或者说仅仅只是想到那些细点,到写用例的时候才发现就这个细节上还有很多东西需要去确认。

      2. 流程图中仅仅体现了是和否的逻辑,对于那些数据或者条件的多样性很难表现出来,到写用例的时候还是需要用表格或者在草稿纸上罗列一下。

      于是再后来做测试设计就会先通过流程图来整理业务逻辑,而后再用excel来补充细节校验和场景罗列,这样做了几个项目之后又有问题了。

      excel表格比较零散,针对某个功能点的校验,比如说边界值等等的融合会显得清晰很多,但是整个业务功能来说感觉还是不能串起来。模块之间的关联还是显得不够紧密,尤其是这样的一个个独立的excel使得细小的点太分散,存在很多重复劳动。

      再后来做一个项目的时候尝试了一种新的方法,完全用excel做设计,不能说是最好的,但是感觉比设计比以前做的更清晰少遗漏了。这个方法是以用户的行为路径为主导,结合项目的业务逻辑来制作excel表头,其中表头还包括数据账号,预期结果,存在的疑问等等信息,这个是最难做的,需要头脑里有一个流程的概念,然后根据表头下面的业务逻辑进行条件细化,最后在各种条件下进行组合,整个excel会很庞大,但是连贯性比较好,而且非常方便的写用例,可以说接下来写用例完全没有什么难度。

      这个方法我还在实践中,它当然也存在缺点,就是新人来看excel的测试设计没有看流程图的excel设计容易理解,而且这个设计方法对业务的熟练程度是有一定要求的,接下来的项目我会继续使用这样的方法,慢慢体会好与不足之处,一点点的做的更好。

    测试执行

      带过多次项目之后越来越觉得测试执行是最能体现团队合作和管理控制能力的。当然,前期的测试计划做的周全对测试执行帮助是很大的。但是常言计划赶不上变化,而且测试计划是从大局观来说的,执行过程中是每天的一个活动,所以常常在执行阶段还需要好好的把控。我习惯性是这样做:

      1.前期做好约定

      对用例执行pass和failed进行一个约定,可能很多人会觉得多此一举,和测试用例的预期结果一致就pass,和结果不一致出现bug就failed 呗,这还有什么好约定的,其实细细想一下,在执行过程中会不会遇到多个用例都是因为其中一个功能点的校验不通过而failed呢?如果这个功能点比较独立,不影响测试流程,开发在修改的过程中我们继续执行,是将这些用例都因为这个功能点不通过而置为failed呢还是将其中一个用例failed提一个 bug,将其他用例pass呢?我个人觉得两种方法都可以,可是事先需要做一个统一约定,大家都按照同一个方式去处理问题,后续负责人统计需要重新执行的用例量时也是非常清楚,方便评估的。

      如果某个功能点不好影响测试进行的时候,测试人员是将受影响用例置为failed呢还是让它弄no run呢?其实这个也不存在谁对谁错,只是前期如果不提出来约定一下的话,恐怕每个测试人员有每个人的习惯,那么测试负责人从QC中分析执行情况以及项目进度时就不能获得比较准确的信息。

      2.分阶段来细化每天工作量

      前期做好约定之后,再每一个阶段开始的时候需要做一个工作量预估表,细化到每天的工作量,这使整个测试过程能更好的得到保证,比如在第一轮测试将开始的时候就根据执行的用例数和工作日做一个预估,第一轮计划是执行5天的话,那么第一天大家测试可能不会那么顺利,需要预估少一点的工作量,在后面的测试中需要抓紧时间多执行一些用例,第一轮接近尾声的时候需要预估少一点的工作,因为交接是或许遇到一些问题,这期间少一点任务能给留出一些时间冗余没想到的风险和困难。

      另外,象这样预估好每天的工作量,可以和实际完成的工作量进行对比,可以尽早知道测试进度是正常还是延期,提早控制好风险。

      最后,从对比的结果可以分析出整体的测试计划是否做的合理,总结经验教训,逐渐成长。

      当然,测试过程中还是需要及时调整的,对于这块就只能意会不能言传,大家慢慢体会吧,我以后还有心得再和大家分享。

    展开全文
  • 敏捷测试(9)--验收测试设计

    千次阅读 2014-02-12 17:40:51
    验收测试设计 传统的测试设计的一个case是这样的: 测试项目编号:   测试项目描述:   测试说明:   测试步骤及输入:   期待结果及输出   测试结果:   是否自动化...

    验收测试设计

    传统的测试设计的一个case是这样的



    传统测试设计虽然很全面,但存在诸多缺陷:

    1.    测试case很详细,导致测设设计文档特别长;

    2.    测试case间,测试步骤可能存在大量冗余和重复;

    3.    测试case无结构,某些case之间有先后顺序或者依赖,不能直观地表现出来;

    4.    编写、评审、阅读和修改这些测试case需要大量时间;

    使用这种测试设计,理论上虽然很保险,不容易造成二义性,但现象往往是这样的:RD不按测试设计自测,bug一大堆

    问题:RD为什么不按测试设计自测?

    思考:真的是RD太懒?

    调研:

    a、文档太长,每次评审的时候都要睡着,别说按它自测了;

    b、case不清晰,很难一眼看明白;

    c、没有时间;

    总结:看来,除了客观原因c外,需要从QA自己身上找原因了。

    改进:

    1、以story为粒度编写测试设计(每个story一个文件);

    特点:每次自测量小,不易烦。

    2、以树形结构组织case,story编号和名字为根,依次是功能块、子功能块、功能点。每个从根到叶子节点的路径为一个测试case;

    特点:逻辑清晰,RD看起来简单明了。

    3、每个case执行时可标记;

    特点:不遗漏、不走冤枉路;

    先举例说明前面两点:

    需求 :


    用户输入用户名、密码和验证码,登录系统。
    具体执行步骤如下:
    步骤一:在浏览器的地址栏中输入地址 http://xxx.xxxx.com,浏览器打开系统的用户登录页面如图所示。用户名称、密码、验证码为空,验证码提示区域自动生成验证码。

    步骤二:录入用户名、密码和验证码,点击“登录”按钮,系统按顺序验证用户名、密码和验证码。如果用户名称错位,提示“用户名错误”;如果密码错 误、提示“用户密码错误”;如果验证码错误,提示“验证码错误”。验证错误后保留用户名,其他项目清空。如果验证通过,则登入系统。密码栏采用暗码显示方式。

    Case:


    上图看不完整,请右键用图片地址访问。

    上图点击登录按钮部分,类似伪代码;而其他部分就是功能点的罗列,使其结构化。这样阅读起来会很清晰简洁。

    试想一下,上面这个case,如果用传统方式来写,case之间的关系很难一眼看明白,会产生很多重复的输入步骤,15个case,大概需要5+页word,而这仅仅是一个登陆

    注意:此测试设计不再只是为自己的测试执行时提供思路,需要完整、细致清晰、无二义性,以保证RD能正确地按照测试设计者的设想来完成代码实现自动化,以及case的执行,否则存在风险。

    弊端:

    1.    文字太少,没有具体的输入输出,容易产生二义性;

    2.    没有特别精确的输出,通过的标准可能仁者见仁;

    但是传统方式写出的case,RD真的愿意一个字一个字地去看么?以上两个问题可以通过不断磨合(尽量按RD舒适的方式写)和必要的沟通(遇到问题及时沟通)来解决。

     

    展开全文
  • 本文介绍典型测试设计方法,如场景分析法、等价类划分、边界值分析、因果图、判定表、正交法等。灵活运用测试设计方法可以帮助减少测试用例冗余,提高测试覆盖率、用例可维护性、用例复用程度,减轻无效的测试执行...
  • 测试设计之等价类和边界值

    万次阅读 2017-02-16 19:32:10
     一般来说,软件测试设计方法分为5类:传统的黑盒测试方法、基于质量的测试方法、基于风险的测试方法、基于经验的测试方法以及白盒测试方法。下面分篇介绍下传统的黑盒测试和白盒测试方法。  5种黑盒测试方法如下...
  • 经典测试设计之方法脑图

    千次阅读 2014-05-03 18:43:20
    我总结的经典测试设计方法的图,后续会针对每一类画单独的脑图。
  • 一、制定测试计划 测试计划编写六要素: Why----为什么要进行这些测试; What----测试哪些方面,不同阶段的工作内容; When----测试不同阶段的起止时间;... Where----相应文档和缺陷的存放位置...三、测试设计 ...
  • 接口测试设计总结

    千次阅读 2018-12-06 22:20:34
    二、 测试用例设计: 一、 设计准备: 1. 概念: 定义  接口测试测试的主要对象是接口,是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是...
  • 软件测试之魂:核心测试设计精解

    千次阅读 2013-05-20 11:12:27
    软件测试之魂:核心测试设计精解(第2版)(掌握核心竞争力成为不可替代的测试精英) 肖利琼著 ISBN 978-7-121-19677-5 2013年5月出版 定价:59.00元 356页 16开 编辑推荐 本书之所以被数位测试界...
  • ISTQB 初级认证 课件PPT 第4章 测试设计技术
  • 测试设计和测试金字塔

    千次阅读 2016-08-28 23:35:39
    这就给测试人员在短时间内全面地测试app带来了很大的挑战。 面对这种情况,很显然,不断地增加手动测试人员和加班不是一个有效的解决办法,而自动化测试是一个不错的选择。 对于自动化测试,很多项目经理甚至测试...
  • 所有模块设计均遵循POM(Page Object Model)结构,从上到下大体分为三层: 用例层:编写测试用例代码的地方,调用业务逻辑层。 业务逻辑层:根据业务需要,封装常用的业务逻辑(相比于Page层的业务逻辑封装,它的...
  • 常见功能测试设计方法

    万次阅读 2018-09-20 09:47:00
    并合理地假定: 测试某等价类的代表值就等于对这一类其它值的测试.因此, 可以把全部输入数据合理划分为若干等价类, 在每一个等价类中取一个数据作为测试的输入条件, 就可以用少量代表性的测试数据.取得较好的测试结果...
  • 基于场景的性能测试设计

    万次阅读 2008-11-26 17:13:00
    基于场景的性能测试设计选自《Web性能测试实战》 图书配套性能测试课程: 1、LoadRunner性能测试入门与虚拟用户开发基础(点击进入) 2、LoadRunner Controller使用基础(点击进入) 注:转载请注明出处与原文...
  • MBIST:用于嵌入式存储器的可测试设计技术 作者:牛风举,DFT应用工程师 明导(上海)电子科技有限公司 术可以自动实现存储器单元或阵列的RTL级内建自测试电路,MBIST的EDA工具支持多种测试算法的自动实现,可针对...
  • 黑盒测试的几个实测试设计

    万次阅读 2016-04-19 23:19:16
    1. 熟练掌握黑盒测试的等价类划分法,并能进行实际程序测试。 2. 熟练掌握黑盒测试的边界值分析法,并能进行实际程序测试。 3. 熟练掌握黑盒测试的因果图法,并能进行实际程序测试。 4. 熟练掌握黑盒测试的...
  • ISTQB AL-TA/TTA认证中文参考书:《软件测试设计》连载系列 作为测试人员,你是不是每天都会碰到各种测试设计方面的问题:没完没了的测试用例、多变的质量要求、太少的测试时间和测试资源、不完善的需求甚至没有...
  • 测试设计员的职责

    千次阅读 2016-08-17 17:04:24
    1)确定并描述相应的测试技术 2)确定相应的测试支持工具 3)定义并维护测试自动化架构 4)详述和验证需要的测试环境配置 5)验证与评估测试途径
  • 问题: 如何能够有效的完成测试用例的输出? 解决方案: 产品需求作为输入,软件设计和测试一起讨论具体的测试细节,测试将其归纳总结为单功能、...测试设计:从MFQ需求到测试用例的转化。 讨论(按优先级): 1
  • 数据组合覆盖测试技术 1,分析被测对象,识别测试输入及可能取值 2,使用数据组合覆盖技术识别测试条件 ...
  • 软件测试设计与软件测试件管理

    千次阅读 2005-04-21 17:36:00
    软件测试设计与软件测试件管理本文版权归计算机世界报所有。任何刊用和大幅引用,请务必征求作者同意。(戴金龙 谢敏 沈雪芳 )越来越多的软件企业已经意识到了软件测试在软件质量管理工作中的重要位置,并开始着手...
  • 网站可用性测试设计

    千次阅读 2014-06-28 15:11:38
    在Internet飞速发展的今天,各种企业、组织、政府和个人网站...用户的真实需求在网站设计生命周期至关重要,用户中心设计,即通过不同途径让用户参与设计过程,已经被证明是设计开发出可用性更强的网站因素,而可
  • 测试设计与测试项目实战训练

    千次阅读 2011-06-17 14:36:00
    面向对象:测试工程师、测试分析与设计工程师、测试经理参考教材:《软件测试技术大全》 训练大纲:1、测试用例设计 (1)等价类设计法(2)边界值设计法(3)正交表设计法与TCG的应用(4)组合覆盖设计法(5)...
  • web安全测试设计----OWASP测试框架

    千次阅读 2015-04-14 22:30:56
    安全测试设计
  • 测试设计中需要考虑的22种测试类型 -- 黑盒测试:不基于内部设计和代码的任何知识,而是基于需求和功能性。 白盒测试:基于一个应用代码的内部逻辑知识,测试是基于覆盖全部代码、分支、路径、条件。 单元测试:最...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,571,235
精华内容 628,494
关键字:

测试设计