qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

基于需求的软件测试

● 目的:保证需求质量

  ● 手段:针对需求开展测试设计

  ● 测试设计面临的挑战:

  1、测试准则不确定(测试是比较预期结果与实际结果的过程,预期结果最了解的人群是开发、需求人员还是客户?答案未知,但是如果需求的质量更高些的话,会更利于更准确的知道预期结果)

  2、测试无穷尽:要用少的用例覆盖尽可能多的需求,如何挑选合适的用例显得尤其重要

  3、用例执行pass是否真正代表对应场景或功能就pass =>缺陷隐藏效应证明不一定,那么在挑选用例时如何做到,RBT会有所考虑

  RBT是如何实现上面所提挑战的?

  ● 为什么要基于需求来开展测试?

  1、导致软件失败的原因如下:

  a)需求不完整

  b)需求多变

  c)需求缺少来自用户的实际输入

  从而导致仅有60%~70%的需求交付量,且此其中50%左右的需求未被使用过,而开发团队针对这些未使用过的需求,投入了大量精力,存在一定程度的浪费。

  2、BUG分析缺陷来自哪个阶段?=>60%来源于需求阶段(怎么有效区分BUG是哪个阶段?)

  ● RBT解决的是偏重型的测试问题(考虑项目的可适用性),是针对每条需求进行分析设计

  ● RBT倡导的思维是先测试,再构建

  ● RBT过程两大步:需求模糊度分析、因果图方法进行测试设计

  1、需求模糊度分析

  实际是分析需求是可测试的、可观察可触发的、结果是确定的(结果是确定的指:给定输入后,能准确得出其唯一的结果,对于输入A,结果为C,再次输入A,结果为B的情况则是不符合“结果是确定的”原则。当出现这种情况,则需求是肯定有问题的)

  2、因果图方法进行测试设计,以下是几类设计方法的对比分析

  a)根据用户实际使用场景、环境参数来设计用例的情况:30%左右的覆盖不乐观,且异常考虑不充分,依赖时间的场景无法覆盖

  b)依据直觉进行设计的情况:依赖测试者经验,覆盖不确定,只能代表执行过的是OK,不能证明其完整覆盖度

  c)组合测试设计的情况:所有场景组合全部覆盖,量太大

  d)因果图方法设计的情况:借鉴了硬件领域的一些工程算法,覆盖率高

  ● RBT方法选择用例的标准:

  1、体现变量间的各种逻辑关系

  2、体现每个变量各种状态间的约束

  3、考虑各节点的可观察性,如下面的例子

  例子:

  A、B、D、E全为T,C、F、G均为True,假定当A恒为False的缺陷存在时,直接通过对G的观察是无法发现此缺陷的,因为C、F是不可观察的

  4、需测试哪些功能块


 ● RBT过程12步骤(12步记录不全)

  1、分析为什么要做这个需求?(如同敏捷测试中要求一样,即:需求来自于哪里?用户是什么样的群体?基于什么原因提出这样的需求?要解决什么样的问题?有无其它可替代方案来解决?是否一定要做这样的需求?

  2、用场景分析方法来分析需求的应用情况

  3、进行模糊度分析,即:识别不清晰、不完整、疑惑点的地方(此点更期望是不了解需求的人来做,而非专家)

  4、领域专家进行更深层次的审视

  5、针对需求建模,理出所有业务逻辑,采用因果图方法

  6、用工具检查逻辑不一致问题,可能是需求本身的问题,也可能是建模的问题

  7、工具自动生成用例(此处的用例可以理解为是测试验证点,而非具体的测试数据)

  8、确认生成的用例是否正确(此处有一个个人问题:既然自动生成的用例已经是很精简了,再进行评审怎么保证评审出的问题是否需要补充到用例的?=>答案:评审的目的一是确认是否正确理解了规则与需求,二是通过评审问题反向识别出需求遗漏的场景(如果可能,要求客户对需求进行review是最合适的)

  9、设计编码阶段,用生成的用例进行验证

  ● RBT工具用途(记录了一些,不全)

  1、自动生成测试用例

  2、自动生成两张表单:因与果清单、规则VS用例覆盖率的对照表(“X”表示多个用例覆盖此规则,“#”表示1个用例覆盖此规则)

  3、生成测试统计数据

  4、自动反向生成较规范的需求文档,适用场景:a、review需求时发现的问题确认后,不会更新需求,通过自动生成更新得到全集;b、敏捷项目中适用,项目结束后形成需求与用例的匹配

  5、生成用例过程中自动进行功能逻辑一致性校验,并给出提示,如同开发程序编译时的错误提示

  6、维护过程会考虑对原有用例的最大程度复用

  7、告诉你可优先执行哪些用例

  8、支持快速设计(推荐在配置测试中使用,如移动领域测试环境支持验证,可生成基础用例)

  9、可定义节点间的状态、约束,以便生成的用例是可执行或真实的组合,对于不可执行的用例前面会有“I”标识,点击后会显示原因

posted on 2013-06-04 10:28 顺其自然EVO 阅读(335) 评论(0)  编辑  收藏 所属分类: 测试学习专栏defalut managerment system 缺陷管理系统


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年6月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜