SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?

不管是文档化的测试用例,还是存在于测试人员头脑中的测试想法和思维,针对测试对象的分析和设计都是整个测试过程的重要测试活动之一。在进行测试分析和设计之前,测试人员首先需要确定测试的需求来源,即测试用例设计需要参考哪些测试依据文档?

测试用例设计的输入文档是什么?测试人员头脑中第一个蹦出的参考依据就是需求规格说明。确实,需求文档是我们测试设计的最主要参考文档。但是,由于时间限制、成本限制和个人能力限制等方面的原因,提供完备的需求规格说明几乎是不可能的。现实情况是,需求规格说明常常是不全的、模糊的,甚至是错误的。

因此,测试设计中仅仅参考需求规格说明是不够的,测试人员需要从更广的范围来定义测试用例设计的参考来源。图1是作者提出的测试用例设计的参考输入的主要来源架构图。

图1 测试用例设计的参考输入的主要来源

除了软件产品相关的的开发文档之外,测试人员还需要收集来自用户的需求、与产品相关的标准与规范、以前类似产品的需求、测试团队的经验知识库,以及其他的一些隐现需求等。通过收集和分析这些参考输入来源,测试人员才能不断提高测试的覆盖率和质量。

1)开发文档

开发文档是测试人员进行测试用例分析与设计的最直接且必不可少的主要来源。这里的开发文档是一个统称,不同组织对其的称呼不同,包含了系统需求规格、概要设计规格、详细设计规格等不同的开发文档。

2)用户需求

软件测试同时包含了验证(Verification:Do you build the product right?)与确认(Validation:Do you build the right product?)两方面的工作。验证主要基于系统需求,来验证测试对象是否按照需求的定义实现了其中的功能和特性。而确认主要从用户的角度,保证经过测试的产品是真正客户所需要的,而不仅仅是了满足了系统的需求。因此,测试不仅仅是面向开发的,同时也应该关注面向用户。

用户需求可以来自各个方面,例如早期产品系统人员与客户直接沟通获取的需求、从产品技术支持人员和市场人员了解到的客户要求,以及从用户现场反馈的针对产品的缺陷和要求等。

3)标准与规范

针对特定的软件产品,不同标准组织和行业都制定了不同的标准和规范,而这些参考资料是开展测试分析和设计的又一个重要输入。例如电信产品相关的ITU-T标准、IEEE标准、RFC文档、国家电信行业规范等。

4)类似产品需求

随着软件产品越来越复杂,行业内采用增量-迭代开发模型的场合越来越多,例如敏捷开发。测试人员经常面临的软件产品是基于已有的系统之上,即测试对象是基于以前版本的功能增加、缺陷修复、平台移植等变更基础之上。因此测试人员需要分析历史测试是否全面,测试对象变更是否影响以前运行的软件版本等。基于这些信息,测试人员可以获取新的测试需求。

5)测试经验知识库

测试并不是存在编码之后的一个阶段,测试应该贯穿于整个软件开发生命周期。类似于开发过程改进一样,测试也应该是PDCA(戴明质量环)的过程。因此,不同项目中的测试经验是每次测试用例设计的重要输入。通过测试经验知识库,测试团队的测试经验和技能才能在整个组织中共享。

测试经验知识库可以来自测试执行的经验、测试过程中发现的缺陷分析和分类、用户反馈的缺陷分析和分类等。

6)其他隐现的需求

测试用例设计的参考输入,除了上面提到的一些来源之外,测试人员还需要考虑其他一些隐现的需求来源:

(1)不同产品利益相关者针对测试对象中间版本的变更而达成的备忘录;

(2)已经发布的用户使用风格指南和用户接口标准等;

(3)和不同的利益相关者,例如:开发人员、用户和技术专家等面谈得到的备忘录或者邮件内容等;

(4)通过杂志、网络等查找类似测试对象产品的一些常见缺陷、失效,以及测试对象支持功能在用户现场使用的讨论。

SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?,布布扣,bubuko.com

时间: 2024-12-09 10:30:13

SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?的相关文章

SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?

开发人员奋斗了很多个夜晚,终于把版本提交测试了.他们可以松一口气了.但是噩耗很快传来,软件没有通过测试团队的预测试(为了保证测试进程,对开发人员提交的代码进行基本功能或业务流程的验证).开发经理老王,迅速找到负责预测试的测试经理老张. 老王说:老张啊,怎么回事?出什么问题了?我们好不容易开发完成了,你们怎么不测试还把版本打回来了? 老张说:你们提交的版本质量太差,没有我们的预测试,需要重新修改后,符合我们的要求,我们才能测试.你看看我们发现的这两个问题. 老王并没有看这两个问题,而是直接质疑老张

SWTBOK测试实践系列(6) -- 开发人员为什么不做静态分析?

场景 某年某月某日,产品环境的2000多封自动发出的Email让我们项目组许多人的邮箱爆了.追查下来根源是一个很不起眼的缺陷.我们的程序对一个布尔值做了if(XXX = true)的判断,可来自上游系统的这个值不光是有true和false,还有空.也就是说上游系统中使用的是一个大布尔,是有true, false,null三态的,  而我们程序使用的是小布尔,只有true和false两态. 掉在大小布尔这个坑里也不是头一回了.记忆中前两年我们也掉进来过.有执著的QA一枚,翻箱倒柜地找,终于找到了当

SWTBOK测试实践系列(3) -- 既然计划永远赶不上变化,我们还要测试计划干嘛?

一天,测试经理老马迟疑着点下了Email的"发送"按钮,长叹一声,往后一仰靠到椅背上.发送这个主题为"回归测试将推迟一周"的通知实为无奈之举啊!一些重要的缺陷开发团队还来不及修复,加上最近几天测试环境的部署经常出现莫名的异常,导致半天都无法测试,原定下周开始的回归测试不得不推迟了!几分钟后,测试人员小王兴冲冲地跑到老马跟前,满脸疑惑地问:"经理,我刚看到你的Email了.又要延期啊!既然我们的测试计划老是在变,干嘛还要定计划?"老马坐正,略带欣慰

SWTBOK测试实践系列(1) -- 测试在项目前期的评审投入划算吗?

测试策略:静态测试还是动态测试? [对话场景] 成功发布某个软件版本之后,项目团队召开了项目的经验教训总结大会.在会议期间,项目经理小项和测试经理小测进行了如下的对话: 小项:"小测,我们的项目时间压力很大,测试执行是我们的关键路径,测试团队是否可以在测试执行阶段投入更多的人力和物力?"限定时间和人力资源同等条件. 小测:"啊!假如增加我们的测试执行时间,在整个周期不变的情况下,我们就需要压缩前期的学习和评审投入的时间和工作量,是吗?" 小项:"是的,你看

SWTBOK测试实践系列(9) -- 设计的测试用例是否越详细越好?

测试人员设计测试用例的时候,面临的第一个问题就是测试用例的步骤是否越详细越好?或者如何把握测试用例的详细步骤?在这个问题上,赞成测试用例详细化的人肯定有不少,因为详细测试用例可以提供如下优点: 1)缺乏经验或者技能的测试人员,可以按照测试用例的步骤顺利开展测试执行工作.这是脚本化测试实践中的思维:有经验与技能的测试人员设计测试用例,而缺乏经验的人员去执行测试用例. 2)缺乏经验的测试人员,按照详细测试用例的步骤执行的过程,不仅可以帮助他们了解测试对象的功能与业务知识,也可以帮助他们了解测试设计技

测试面试题集-测试用例设计:登录、购物车、QQ收藏表情、转账、充值、提现

以下内容首发于微信公众号[ITester软件测试小栈]: 测试面试题集-2.测试用例设计 大家好 我是coco小锦鲤 上周五给大家分享了测试基础理论题 这个周五给大家分享测试用例设计题 测试用例的考察无非是检验 是否可以理解给定的需求 是否有设计测试用例的能力是否熟悉各种测试方法 是否有灵活的发散思维 以下给大家列举 登录功能 购物车模块 QQ收藏表情包 网上银行转账 支付宝充值 支付宝提现 6大常见的测试用例设计面试题 Q: 一.登录功能,设计测试用例. A: 功能测试: 1.输入正确的账号和

测试笔试题之测试用例设计题

1.假设京东有一个Web API:http://p.jd.com?p1=90&p0=100,输入打折价p1和原价p0,返回折扣信息0.9,请设计测试用例进行测试. 答案: (1)输入打折价错误+输入原价错误(输入值不在正常范围内) (2)输入打折价错误+输入原价正确 (3)输入打折价正确+输入原价错误 (4)输入打折价正确+输入原价正确(打折价高于原价) (5)输入打折价正确+输入原价正确(打折价高于原价 返回折扣信息不对) (6)输入打折价正确+输入原价正确(打折价高于原价 返回折扣信息对)

关于接口测试用例设计的一些思考

接口测试发现的典型问题 传入参数处理不当,引起程序错误 类型溢出,导致数据读取和写入不一致 对象权限校验出错,可获取其他角色信息 状态出错,导致逻辑处理出现问题 逻辑校验不完善 定时任务执行出错 接口测试用例设计 接口测试用例设计主要针对输入.处理.输出进行考虑 针对输入进行设计 对于接口来说,输入就是入参,一般的参数类型 数值型 边界内.边界值.边界外三个方面去考虑 特殊值处理不当程序异常.类型边界溢出.错误信息返回不正确 字符串 主要考虑字符串长度和字符串的内容 空.特殊字符.数字.表情符号

移动APP测试用例设计实践经验(转载)

前言杂谈 在聊移动APP测试用例设计之前,我请大家先思考如下2个问题: 第一,我们为什么要做好测试用例设计?--why? 第二,好的测试用例设计有什么共性? --what? 深入思考这2个问题的答案是一件很有意义的事情,作为移动互联网时代的产品质量守卫军,我们必须提升自己的测试设计能力,必须清楚的知道要测什么,怎么测.但单从我们测试团队现状来看,有很多人都没有做好准备,测试设计方法仍然比较落后,所以我整理此文,旨在总结沉淀移动客户端测试用例设计实践,帮助测试人员时刻审视完善自我测试能力提升. 那