测试编写测试用例的思路和方法

Posted 黑黑白白君

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了测试编写测试用例的思路和方法相关的知识,希望对你有一定的参考价值。



1)什么是测试用例?

1.1 测试用例的定义

测试用例是对一项特定的软件产品进行测试任务的描述指定输入,预期结果和一组测试项的执行条件的文档。

  • 它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。
  • 体现了测试方案、方法、技术和策略。
  • 测试用例的内容:

    内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。具体有:
    • 用例编号、用例名称
    • 测试背景
    • 前置条件
    • 优先级、重要级
    • 测试数据
    • 测试步骤
    • 预期结果、实际结果
    • 备注等

*为什么需要测试用例?

测试用例的作用:

  • 检验软件是否满足客户需求
  • 体现一个测试人员的工作量
  • 展现测试用例的设计思路
  • 测试用例是测试人员在测试过程中的重要参考依据

  • 测试用例可以帮助实施有效的测试,所有被执行的测试都是有意义的,不执行毫无意义的测试操作。

  • 测试用例是一个知识传递的过程,能保持一致、稳定的测试质量

  • 从项目管理的角度来说,测试用例的通过率是检验代码质量最主要的指标之一

  • 测试用例也可以作为评估测试人员进度、工作量以及跟踪/管理测试的工作效率的主要因素,从而更加合理地做出测试安排或调整。

  • 良好的测试用例不断地被重复使用,使得测试过程事半功倍。
    • 在软件产品的开发过程中,开发人员不断的推出新的版本,测试人员需要对原有功能进行多次的回归测试,即使在一个版本中,也要进行 2~3次的回归测试。这些回归测试,就要求能重复使用测试用例
  • 如果没有测试用例,很可能到执行的时候测试点就遗漏了,另外也不便于用例评审,用例总结,对后期测试工作没大的改进作用。
    • 所以测试用例一定要写,颗粒度视情况而定。针对测试人员少,上线时间紧的项目,可只做思维导图列出测试点。

1.2 测试用例的元素

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

  • 测试目标(Why):

    为什么而测?功能、性能、可用性、容错性、兼容性、安全性等。
  • 测试对象(What):

    测什么?被测试的项目,如对象、函数、类、菜单、按钮、表格、接口、整个系统等。
  • 测试环境(Where):

    在哪里测?测试用例运行时所处的环境,包括系统的配置和设定等要求,也包括操作系统、浏览器、通讯协议等单机或网络环境。
  • 测试前提(When):

    什么时候可测?测试用例运行时所处的前提或条件限制。
  • 输入数据(Which):

    哪些数据?在操作时,系统所接受的各种可变化的数据,如数字、字符、文件等。
  • 操作步骤(How):

    如何测?执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。

2)测试用例的编写流程

主要分为以下四步:

需求分析 -> 提取测试点 -> 测试用例编写 -> 测试用例评审

2.1 需求分析

如果直接去测试,会发现有很多需求理解的偏差,测试过程中会发现自己理解的需求跟开发实际做出来的功能不一致。

所以拿到需求后:

1、过需求文档:

  • 先自己过一遍需求文档,标出不理解或者可能会有争议的地方。
  • 可以借鉴一下同类产品类似的功能是怎样处理的,这样更有助于理解需求。
  • 针对有疑义的地方与产品经理和开发人员一起讨论,尽量减少大家对需求理解上的误差。

2、根据需求文档,拆分测试点。

  • 需求的种类:

    • 业务需求:关注系统是否满足业务要求。
    • 用户需求:关注系统是否满足用户习惯。
    • 功能需求:关注系统是否满足功能要求。

*什么是产品需求文档?

产品需求文档就是产品功能说明书,包含大量的功能细节,目的是提高沟通效率,避免研发过程出现误会。

产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。

在这里插入图片描述

  • 需求背景与目标说明:让别人知道为什么要做,要做到什么程度,用户检验功能完成情况。
  • 特性列表:所谓特性其实就是功能模块,把需要做的功能模块都罗列出来,主要用于明确需要做的功能有哪些,用图表体现更佳。
  • 主要逻辑:每个特性之下的操作逻辑,简单特性可以文字说明,复杂特性建议用流程图表现。
  • 特性功能点:补充每个功能点的相关细节描述,是开发,与测试工作的重要依据。包括:
    • 流程细节描述
    • 正常逻辑表现,异常逻辑表现
    • 文案内容,性能需求
    • 交互图(可无)
  • 特性需求,性能需求,数据上报:这一部分类似备注,说明了做这个功能要达到怎样的程度,需要再哪些地方进行数据埋点。

*什么是交互需求文档?

交互需求文档是给交互设计师看的文档,应该在需求文档之外单独呈现,主要目的是让交互设计师理解产品的交互需求。

  • 交互需求文档主要是对功能的交互设计,包含功能列表,每个功能的交互要点说明,包含元素等等。

*如果没有需求文档,怎么设计测试用例?

  • 查找其他相关文档,来帮助理解所要测试的产品需要完成的目标。
  • 尽量多参加项目组内的会议,比如需求讨论、设计讨论、计划讨论等,能够加深对产品的理解。
  • 咨询相关人员:项目负责人、市场人员。
  • 如果是一款已经上线的产品,可以多使用产品,有不懂的问产品经理。
  • 可以去看历史bug,了解到一些需要关注的东西。

2.2 提取测试点

对各个功能模块进行测试点分析,提取测试点,再对测试点进行用例编写。

  • 测试点:通过需求分析后,对得出的需求进行测试的具体内容。

【举例】对PC端QQ账号的登录模块,提取测试点:

在这里插入图片描述

  • 登录:
    • 正常登陆
    • 账号为空时点击登录
    • 密码为空时点击登录
    • 账号密码都为空时点击登录
    • 密码错误时点击登录
  • 记住密码功能是否有效
  • 自动登录功能是否有效
  • 找回密码功能是否有效
  • 注册账号能否正确跳转

【举例】对CSDN的web端登录界面,提取测试点:

在这里插入图片描述

  • 登录:
    • 正常登录
    • 账号为空时点击登录
    • 密码为空时点击登录
    • 账号密码都为空时点击登录
    • 密码错误时点击登录
  • 判断输入的手机号或者邮箱是否符合规范
  • 判断输入的账号是否存在
  • 下次自动登录按钮是否生效
  • 忘记密码按钮是否生效
  • 第三方登录是否有效
  • 注册账号按钮是否生效

2.3 测试用例的编写

2.3.1 编写测试用例该注意什么?

  • 根据项目的实际情况设计测试用例表格
  • 用例格式不要生搬硬套
  • 根据具体情况进行编写
  • 小技巧:
    • 把测试管理工具中的缺陷全部分类导出,总结一下哪些模块容易产生哪些缺陷,重点看一下自己没发现或没有考虑到的缺陷。
    • 把测试管理工具中的用例详细看几遍,学习别人的用例编写方法和思想。
  • 测试用例的模板:

    在这里插入图片描述
    在这里插入图片描述

2.3.2 测试用例的写作

  • 用例编号/ 序号

    • 应该简单且唯一

  • 用例说明(检查点)

    • 也称测试点、检查点、测试概述、用例概述、测试说明。
    • 用一句话对测试用例进行概述,最好看到这句话就能知道如何测试。
    • 可以总结测试目的,可以用“检查、验证、测试”等字眼(如验证 QQ 默认安装)。
    • 用例执行多轮时,越往后执行可能越快,如果用例写得好,直接看概述就行。

  • 初始条件

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

  • 操作步骤

    • 步骤要都有序号。
    • 每一步用分号分开,最后用一个句号。每一步必须换行。
    • 参数前加冒号(如用户名:admin)。涉及按钮界面用【】、“”等成对符号间隔。
    • 功能的详细用例步骤 4-6 步左右。
    • 若对数据要求高,需要把数据分离出来。

  • 预期结果

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

  • 用例状态

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

  • 优先级

    • 用例的执行顺序。

*举例:

在这里插入图片描述

2.4 测试用例的评审

评审就是对测试用例进行检查。用例编写完成后,要组织人员进行用例的评审。

  • 评审包括:同行评审、小组评审、部门评审和第三方评审等。
  • 参与人员:包括需求人员(如产品经理)、测试人员、开发人员等。
  • 评审流程:评审后改进测试用例,再进行评审再改进测试用例,这样一直循环直到评审都通过,这时候才结束评审,也标志着测试用例编写的完成。

*为什么要进行用例的评审?

测试用例包含了功能的边边角角,我们不能保证能把所有的测试点都列出来,也不能保证我们所列出来的测试点方向都是正确的,那么就需要其他人来查缺补漏、纠正错误,看一下有没有我们漏掉的点,看一下我们用例的方向是否正确,防止对需求的理解错误。

  • 通过评审发现用例的不足
  • 方便测试人员改进用例
  • 提高测试质量

2.4.1 测试用例评审要点

  • 根据检查单或检查表(Check List)进行评审。
  • 用例“文字校对”:错别字、病句、语句不通顺、含义不清晰、语句有歧义、格式不一致、标点不一致、中英文混合等。
  • 用例质量:遗漏用例、冗余用例、不清晰用例、错误用例、不可测用例等。
  • 确定用例的优先级。
  • 规划服务器和客户机。
  • 用例的分工执行与人员安排。
  • 记录评审过程,记录测试环境规划。

2.4.2 测试用例的维护

  • 为什么需要更新测试用例?

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

    • 原始的Excel管理
    • TestLink: 免费开源可扩展性高,可以和bugzilla等缺陷管理工具的整合,适合中小型项目的管理。
    • ZenTao(禅道):免费开源,不过定制能力不足,不好用层级结构管理用例。
    • Bugzilla、ALM等,更详细的可以参考:有哪些比较好的测试用例管理工具?(https://www.zhihu.com/question/26898212)

3)编写测试用例的方法

常见的方法有等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。

具体可参考本栏目的《【测试】编写测试用例的常用方法》。(https://blog.csdn.net/m0_37621024/article/details/116860859)



【部分内容参考自】

  • 测试开发之编写测试用例:https://bqleng.blog.csdn.net/article/details/105284818
  • 一份优秀的需求文档:https://www.pianshen.com/article/8729120291/
  • 编写测试用例及一个例子:http://www.51testing.com/html/24/n-3727424.html
  • 测试开发之编写测试用例:https://bqleng.blog.csdn.net/article/details/105284818

以上是关于测试编写测试用例的思路和方法的主要内容,如果未能解决你的问题,请参考以下文章

编写测试用例常用的五种方法

测试2:编写测试用例的方法

测试用例编写思路

软件测试的分类&测试用例的设计&如何编写测试用例

编写Python用例脚本遇到的问题

所有现有测试用例的代码覆盖率?