51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 1846|回复: 1

[转贴] 测试用例设计怎么做?怎么设计一个好的测试用例?

[复制链接]
  • TA的每日心情
    无聊
    8 小时前
  • 签到天数: 919 天

    连续签到: 1 天

    [LV.10]测试总司令

    发表于 2021-8-24 13:09:00 | 显示全部楼层 |阅读模式
    一、测试用例的定义

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

      二、为什么要写测试用例

      1、 理清测试思路

      有的系统本来就是一个大而复杂的项目,因此需要把项目功能细分,根据每一个功能通过编写用例的方式来整理测试系统的思路,避免遗漏掉要测试的功能点。

      2、 明确测试任务

      编写完用例后,可以明确自己需要执行的用例总数,以便预估测试工作量。并且可以很清楚的知道实际测试执行的进度,还很容易统计和跟踪我们的剩余工作量和回归工作量。

      3、 规范测试行为

      每个人对于功能和开发原理的理解都是不同的,同一条案例,每个人的理解程度和扩展都是不一样的。对于没有测试经验的新人来讲,更是需要详细明确的用例来规范,以减少遗漏。

      三、如何编写用例

      1、 测试用例的来源

      a) 分析需求文档

      需求文档是编写测试用例的第一依据,需求分析的目的一般是:

      · 了解需求的背景;

      · 分析需求的合理性;

      · 明确需求的范围;

      · 挖掘隐含需求;

      b) 了解开发原理

      · 确定开发的实现框架;

      · 明确输入输出代码规则;

      · 减少测试方向偏差;

      2、 测试用例的要素

      a) 测试环境

      测试的系统是什么?硬件软件的要求是什么?

      b) 测试数据

      测试执行的输入值。

      c) 测试步骤

      提供测试执行过程的步骤。一般控制在三个步骤完成。否则需要考虑用例是否需要拆分,因为每条用例对应的测试目的应该是具有唯一性的。

      d) 预期结果

      预期结果根据软件需求中的输出得出。那么实际测试过程中,实际测试结果如果与预期结果不符,则就测试不通过;反之则测试通过。

      e) 用例标题

      用例标题是对测试用例主旨的描述,既要言简意赅,也要能够清楚表达测试用例的目的。

      f) 用例编号

      定义测试用例编号,用来标示每个用例的唯一性,进行测试用例的跟踪和维护。

      g) 用例级别

      一般分为四个等级,P0、P1、P2、P3。

    3、 用例设计方法

      结合一个需求来讲讲不同方法的应用:

      a) 等价类划分

      将输入值分为有效等价类和无效等价类。如果输入规定了输入区间,可划分出一个有效等价类,两个无效等价类。

      b) 边界值

      任何测试场景下都可以使用边界值法做设计,输入类型可以数值、字符等,要测试的边界包括上点、下点、离点。

      c) 错误推测法

      错误推测法,即猜测可能和常出现的错误,来提前制定用例,规避风险。错误推测法很受设计人员的测试经验影响,测试经验不同,设计出来的测试用例区别会很大。

      d) 因果图法

      罗列出所有的输入和输出,将输入和输出整理出因果图和依赖关系,根据每一个依赖做设计。因果图方法考虑输入的组合,特别适用于多个输入条件相关有关联又相互约束的情况。

      e) 判定表驱动法

      判定表适合于解决多个逻辑条件的组合,将各种逻辑的组合罗列出来,避免遗漏。列出每个对应条件所有可能情况下的取值,不需要考虑条件和顺序,再列出结果动作项,对每个条件进行结果判定。最后可以适当的进行规则简化和合并。

      f) 正交法

      当输入条件很多时,因果图等设计方法设计出来的用例数往往多的惊人,用正交法可有效减少用例数。正交法的核心思想是从大量测试数据中选取有代表性的点来测试,从而减少测试用例数。

      g) 场景法

      画出程序流程图,再把流程图转换成控制流图,根据控制流图设计出场景,再根据场景设计测试用例。

      结合这样一个需求:

    判定表:

    四、如何提升用例编写能力
      1、 从大往小抓起测试框架先行
      极力推荐思维导图工具,快速的梳理清晰要测试的模块、测试点、以及结构关系,让自己先对要测试的内容有个整体的框架和印象,脑图也能够快速的让开发、接手的测试同学快速理解和看出大方向上的偏差和遗漏。
      另外细节的地方,推荐几个图形工具结合用,比如流程图、鱼骨图和N-S 图。
      2、 多纬度的思考和覆盖
      从界面、功能、性能、兼容、异常等角度思考,尽可能的覆盖更全更广。
      3、 熟悉被测的业务和系统
      任何系统都有大的业务背景,比如测试金融 [url=]APP[/url],要了解金融业务,基金、理财产品的业务流程和逻辑,要了解什么是结算、账户、和支付几个系统的差异以及作用。才能更准确的把握好测试重点写好用例。
      任何系统在使用过程中,都有一个熟悉的过程,对系统越熟悉,越容易发现系统的特点,以及容易出现错误和异常的地方。
      4、 站在用户角度分析
      站在客户的角度分析:客户需要什么,客户想要什么,客户不想要什么,也就是客户的使用场景。这样有利于我们更好的挖掘和思考隐含的需求。甚至可以拉上几个同事来体验下产品,看看他们的操作行为和顺序是怎样的。
      5、 重视用例评审
      重视测试评审和评审意见,把经常见到的用例设计的误区和一些好的用例设计,还可以多看看他人的测试思路和用例,查漏补缺。

    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 17:48 , Processed in 0.064051 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表