• 测试用例的编写


     1.测试用例的定义和内容

    (一)测试用例的定义

       A.、对一项特定的软件产品进行测试任务的描述,指定输入,预期结果和一组测试项的执行条件的文档。
        a.体现测试方案、方法、技术和策略;
        b.内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

      (二)测试用例的元素

      A、测试用例必须给出测试测试目标、测试对象、测试环境要求、输入数据和操作步骤,概括为5W1H。

       a. 测试目标:Why——为什么而测?功能、性能、可用性、容错性、兼容性、安全性等。
       b.测试对象:What——测什么?被测试的项目,如对象、函数、类、菜单、按钮、表格、接口、整个系统等。
       c.测试环境:Where——在哪里测?测试用例运行时所处的环境,包括系统的配置和设定等要求,也包括操作系统、浏览器、通讯协议等单机或网络环境。
       d.测试前提:When——什么时候可是测?测试用例运行时所处的前提或条件限制。
       e.输入数据:Which——那些数据?在操作时,系统所接受的各种可变化的数据,如数字、字符、文件等。
       f.操作步骤:How——如何测?执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。

    2.测试用例的写作说明

     (一)测试用例的格式?模板?

         A、序号
           a.简单、唯一。

        B、测试说明(或称测试点、检查点、测试概述、用例概述、用例说明):用一句话对测试用例进行概述
           a.可以总结测试目的;
           b.可以用疑问句表示;
           c.可以用“检查、验证、测试”等字眼(如验证QQ默认安装);
           d.最好看到这句话就能知道如何测试;
           e.尽量唯一(因果图、正交表可能会有重复的测试说明);
           f.用例执行多轮时,越往后执行可能越快,如果用例写得好,直接看概述就行。

        C、初始条件(预置条件、前提条件)

          a.初始条件要是一个状态,而且是静态的,如管理员已登录后台;
          b.初始条件是第一步操作步骤之前的状态,不能太远,不用从头写到尾
          c.很多项目中不写预置条件。

        D、操作步骤
          a.若对数据要求高,需要把数据分离出来;
          b.步骤要都有序号;
          c.每一步用分号分开,最后用一个句号;
          d.每一步必须换行;
          e.参数前加冒号(如用户名:admin);
          f.涉及按钮界面用【】、“”等成对符号间隔;
          g.功能的详细用例步骤4-6步左右;
          h.最后一步一定是个动作,不能写结果。

        E、预期结果
         a.是一个状态;
         b.如果参考文档中有描述,原封不动的抄过来;如果文档中没有具体要求,则点要一致,可以有几个点,如QQ默认安装,应能启动、默认选项匹配等;

        F、用例状态
         a.通过、失败、阻塞、未执行、搁置、无效用例…
         b.初始条件达不到时,一般用例状态设置为阻塞。
         c.看如何执行用例,执行完关心什么来定。

       G、优先级
        a.用例的执行顺序。

    3.测试用例的评审和管理

      (一)保证测试用例质量的方法

         a.首先,要对用户需求、服务质量要求、产品特性有深刻且全面的理解
         b.其次,采取正确、恰当的方法进行用例设计;
         c.再者,按照测试用例的标准格式或规范的模板来书写测试用例;
         d.最后,对测试用例的检查、评审,也是提高测试用例质量的主要且有效的手段。

     (二)测试用例评审要点

        a.根据检查单或检查表(Check List)进行评审。

     (三)测试用例的优先级

     (四)如何设置测试用例的优先级

          a. 考虑成本、时间、人员等因素。
          b.考虑用例的关联性。
          c.考虑用例的干扰性。
          d.决定执行用例的先后顺序。

     (五)注意

         a. 兼顾测试充分性和效率。
         b.考虑测试执行的可再现性。

     (六)测试用例的维护

       A、通常情况下,测试用例需要更新,可能有以下几种原因:
        a.先前的测试用例设计不全面或者不够准确。随着测试的深入和对产品规格说明书的深入研究,对某些功能、特性、逻辑等的理解越来越清楚、深刻
        b.所发现的严重的软件缺陷没有被目前的测试用例所覆盖。
        c.编写的测试用例不规范或者语句错误。
        d.新的版本中有新功能的需求或者原有功能的增强而需要发生改动。
        e.旧的测试用例已经不再适用,需要删除。

     (七)使用工具管理测试用例

           Excel
           Bugfree
           ZenTao
           ALM/QC
           ...

    4.用例设计方法总结

      (一)通过测试

         a.主要用于验证系统和它陈述的需求一致,确认软件至少能做什么,一般通过分析需求说明书来设计测试用例。

    (二)失败测试

         a.纯粹为了破坏软件而设计和执行的测试案例,也称迫使出错测试。主要用于证明“一个系统不会做不需要它做的事情” 。

          

      (三)随机测试

         A、也称即兴测试(ad hoc testing),是指临时准备的、即兴的Bug搜索测试过程。

        e.g.如果让一百万只猴子在一百万只键盘上敲一百万年,它们最终就可能写出莎士比亚话剧等巨著。

          B、缺点

          a.无法度量随机测试的实际覆盖率。
          b.许多测试都是冗余的。
          c.测试数据因为是随机的,重复测试是不可能的。

       (四)应用群集效应

          a.找到的软件缺陷越多,说明那里的软件缺陷越多,若在测试中发现大量的上边界条件缺陷,则在测试时应注重上边界。
          b.程序员倾向于修复报告出来的问题,要保证除此之外可能存在的其他问题不会出现。

     (五)探索性测试

          a.可以说是一种测试思维技术。
          b.探索性测试是一种精致的、有思想的过程。
          c.探索性测试强调测试设计和测试执行的同时性。
          d.测试人员通过测试来不断学习被测系统,同时把学习到的关于软件系统的更多信息通过综合的整理和分析,创造出更多关于测试的主意。
          e.测试设计,测试执行,测试日志的记录似乎是无关紧要的工作。
          f.测试人员必须根据测试章程在规定的时间内完成。
          g.适合于

    • 没有或只有少量的有价值的文档
    • 常用于在时间压力下。
    • 为补充合适的、正式和形式化测试。

       (六)如何选择测试方法

         a.使用大纲法、场景法、因果图设计测试用例。

    • 如果程序的功能说明中含有输入条件的组合情况,则应在一开始就选用因果图法。

        b.用等价类划分方法、边界值分析方法、错误猜测法补充测试用例。

        c.执行测试时进行探索性测试或随机测试。

       d.执行完测试用例后进行随机测试。

  • 相关阅读:
    PhpStrom之添加文件夹至左侧目录树
    PhpStorm下载、破解
    ASP.NET 页面执行顺序
    委托的使用 举例猫叫,老鼠逃跑,主人惊醒
    分页显示
    WebForm页面生命周期及asp.net运行机制
    json 对象和json字符串
    说走就走??
    面向多态
    mvc 过滤器篇
  • 原文地址:https://www.cnblogs.com/tiechui2015/p/15588578.html
Copyright © 2020-2023  润新知