如何提升测试用例设计水平?

一、定义


测试用例(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。

首先,测试需要保证以下两点:

  • 程序做了它应该做的事情
  • 程序没有做它不该做的事情

因此,作为测试实施依据的测试用例,必须要能完整覆盖测试需求,而不应针对单个Case去评判好坏。



二、如何设计测试用例


1、对被测版本足够了解

由粗略详细步骤来解读产品需求文档,如交互、功能流程、边界、约束等等。充分理解技术实现原理(实现的逻辑原理、架构及对其他平台的依赖、接口等)。深入理解用户群,分析用户使用场景、可能的使用方法及用户心理,完全从用户角度出发,来设计Case,同时对用户体验做出一定的判断。

2、设计Case优先级

一般BugFree或禅道工具中编写好Case后可以按优先级来筛选优先级,如果是用Excel文档来写可以来通过不同背景色来标识相应的优先级,无论评审还是执行,都可以按此来查阅。无论是冒烟测试用例还是功能测试用例,节省大量时间。

3、从粗到细分析需求

可以使用工具辅助,第一遍需求分析时,粗略画出测试需求框架;第二遍分析需求时,开始延伸每个出子测试点;细化测试点时,可参考或引用写好的公共Case, 也要考虑到被测版本中该功能的特性。另外需要考虑的就是测试点的颗粒度要把握好。

4、测试用例Update

需求分析阶段和开发阶段 ,都可能出现需求变更,这时对于我们前期粗略整理好的测试点就需要及时的同步更新了。另外在Case评审阶段,可能会出现Case冗余或遗漏,也需要在评审结束后在Case池里及时修整。如果项目中有使用需求工具之类的,可以利用工具去同步通知到每个节点的负责人,会大大 减少UPdate的时间。



三、新手如何快速提升设计Case能力


1、   非常熟悉业务

这是必备条件,因为所有Case都是从业务层开始入手的,而终端使用者也是以业务为出发点。

2、   培养用户思维

测试人员需要站在客户的角度分析用户需要什么、想要什么、不想要什么,这样有利于我们更好的挖掘隐含需求。所以设计场景时也同样是站在用户角度。

3、   勿限制测试思维

对于好的测试人员,都会有自己的一份通用测试用例表, 每次编写测试用例时,会将重复或公共的功能摘出来,去参照已有的通用Case。但若不能做到及时更新 ,随公司项目变更等,很可能在某些项目中固步自封,不能灵活地运用。所以通用Case总结更新是必不可少的,也可以分享出来让同行参谋 ,大家集思广益,也许其他人有更新奇的方法,这样会不断地开拓自己的测试思维 ,而不至于一直重复原有的经验。

4、   乐于分享,有计划地总结

给自己的学习过程制订一个详细的计划,量化到天,排好每天要学习的东西。同时最重要的是,一定要养成总结的习惯 ,每天总结 ,每个项目总结 ,总结测试方法,总结Bug原因,奇葩Bug等等,这些将会成为你日后工作的宝贵财富。同时主动总结久了, 你会发现自己有质的提升,而且对于当前的工作会更游刃有余,所以经验是靠日积月累的。

原文地址:http://blog.51cto.com/hongz/2067283

时间: 2024-08-03 06:09:11

如何提升测试用例设计水平?的相关文章

【测试设计】如何提升测试用例设计水平?

原文链接:http://www.51testing.com/html/22/n-3724422.html 定义 测试用例(Test Case)是为某个特殊目标而编制的一组测试输入.执行条件及预期结果,以便测试某个程序路径或核实是否满足某个特定需求. 首先,测试需要保证以下两点: 程序做了它应该做的事情 程序没有做它不该做的事情 因此,作为测试实施依据的测试用例,必须要能完整覆盖测试需求,而不应针对单个Case去评判好坏. 如何写好测试用例 1.对被测版本足够了解 由粗略详细步骤来解读产品需求文档

转:如何提高测试用例设计的测试覆盖率

说到测试用例的设计,我想每个有过测试经历的测试工程师都会认为很简单,不就是:按需求或概要设计,得到软件功能划分图,然后据此按每个功能,采用等价类划分.临界值.因果图等方法来设计用例就行了. 但事实上撇开测试数据的设计不谈,仅就测试项来说,我们发现,对同一个项目,有经验的测试人员,在写用例或测试时总会有更多的测试考虑点,从而发现更多的问题:而有些测试人员测试用例的撰写却只有那么三板斧,表面看好象已经把页面所有信息的测试都考虑到了,实际上却还是遗漏了大量测试覆盖点,导致其测试出来的程序总是比较脆弱.

测试用例设计——如何提高测试覆盖率

前言 说到测试用例的设计,我想每个有过测试经历的测试工程师都会认为很简单,不就是:按需求或概要设计,得到软件功能划分图,然后据此按每个功能,采用等价类划分.临界值.因果图等方法来设计用例就行了. 但事实上撇开测试数据的设计不谈,仅就测试项来说,我们发现,对同一个项目,有经验的测试人员,在写用例或测试时总会有更多的测试考虑点,从而发现更多 的问题:而有些测试人员测试用例的撰写却只有那么三板斧,表面看好象已经把页面所有信息的测试都考虑到了,实际上却还是遗漏了大量测试覆盖点,导致其测试 出来的程序总是

转:黑盒测试用例设计方法

1. 概述 黑盒测试用例设计方法包括等价类划分法.边界值分析法.错误推测法.因果图法.判定表驱动法.正交试验设计法.功能图法等. 2. 等价类划分法 2.1.              概念 等价类划分法是把程序的输入域划分成若干部分(子集),然后从每个部分中选取少数代表性数据作为测试用例.每一类的代表性数据在测试中的作用等价于这一类中的其他值. 2.2.              等价类划分法的应用 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理

软件测试实战 - 测试用例设计方法

一.测试分析 测试需求来源 开发需求DR:协议标准需求PR:用户需求UR:案例库需求LR:竞争需求CR:继承需求SR: 2. 测试项分析步骤 a. 为分析的测试项编号:b. 注明来源:开发文档/法律条款/案例库编号c. 整合测试项:删除合并重复测试项:大的测试项分解为测试子项:d. 分析测试项之间的关系: 3. 测试分析方法 a. 质量模型分析法:功能测试项.效率测试项.可靠性.易用性.可维护性.可移植性:b. 用户场景分析法:游客.普通用户.VIP用户.管理员用户等,不同角色权限不同,测试点也

提升PPT设计的几点要求(上)

[1.文字,PPT的天敌] 在制作PPT时我们经常听到这样的言论:“PPT很简单,就是把Word里的文字复制.粘贴呗.”这其实是对PPT的一种无知与亵渎.假如直接把文字复制粘贴到PPT上就能到达演示的效果,PPT基本就没有存在的必要了.  PPT设计的实质在于可视化,就是要把原来摸不着.看不见.晦涩难懂的笼统文字转化为由PPT图表.PPT图片.PPT动画及声音所构成的生动场景,以求浅显易懂.栩栩如生. 形象,至少能给你带来三方面的感受: 一是便于了解. 文字总是高度笼统的,人们需求默读.需求转换

更好的测试用例设计

? Nicolaas Kotze是一个有着离奇扭曲幽默感(这种幽默感讽刺地与墨菲定律及对详细解释质量是如何被感知的人类行为的理解很好结合了起来)的自信的现实主义悲观者.他在英国伦敦时开始接触游戏行业的测试,并头冠不少AAA级称号. 他的测试职业生涯正式开始于回到南非测试(使用用来自荷兰客户公共服务交付领域的谷歌地图的)GIS软件系统,再后来他转移到繁忙的零售信贷和金融服务业.他选择测试为职业道路是因为它使人们能够将创造性思维融入常规程序或规定中,且仍有"打破"东西的令人振奋的快感.测试

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

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

测试用例设计白皮书--功能图分析方法

一.方法简介 一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输