• 一份好的测试用例需要怎样的千锤百炼?


    前言

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

    在这里插入图片描述

    好用例的标准

    • 是否可以发现Bug

    设计测试用例的目的就是为了发现bug,如果bug都发现不了,怎么能称得上是一个好的测试用例呢?

    • 是否够高效

    一个好的测试用例应该不止测试一个测试点,从而减少需要的用例总量。但也不能包含太多不相关的测试点,否则你这个用例就没法测试了,并且给开发的debug造成困难。

    • 是否够经济

    这个测试用例执行起来是否容易,分析和debug是否要花太多代价,都是值得考虑的,毕竟咱也要站在组织的角度来看待测试这个事,公司是为了盈利而做这些事,而不是为了做测试而测试。

    • 是否有足够的扩展性

    主要是考察测试用例在维护时是否要花费很大的代价。

    在这里插入图片描述

    测试用例的好处

    • 理清思路,避免遗漏

    这里是我们认为最重要的一点,假如我们测试的项目大而复杂,我们可以把项目功能细分,根据每一个功能通过编写用例的方式来整理我们测试系统的思路,避免遗漏掉要测试的功能点。

    • 跟踪测试进展

    通过编写测试用例,执行测试用例,我们可以很清楚地知道我们的测试进度。

    • 历史参考

    在我们所做的项目中,也许会有很多功能是相同或相近的,我们对这类功能设计了测试用例,便于以后我们遇到类似功能的时候可以做参考依据。

    • 重复性

    我们测试一个系统不是一个人测一遍就算测完的,需要多人反复的进行测试,那么我们就需要测试用例来规范和指导我们的测试行为。

    测试用例方法

    • 等价类划分

    在某个输入域的子集合,在该子集合中,各个输入数据对于揭露程序中的错误都是等价的。

    假如有一个输入框要求输入1-10000个数,我们不可能用每一个数去试,我们输入5 和输入6去验证和揭露输入框的错误可以看做是等价的。

    那么这个时候我们就可以随机的抽取一些数据来进行验证。如:10 、99、7777…
    等价类分:有效等价类和无效等价类
    输入框要求输入1-10000的数
      
    有效等价类:可以输入1-10000之间的数来验证,如:2、5、99、8495…
      
    无效等价类:可以输入1-10000之外的任意字符验证,如:20000、字母、下划线、特殊符号、空格、回车…

    • 边界值

    边界值是对等价类的补充,测试工作经验告诉我们,大量的错误是出在输入输出的边界价上。
    我们还拿上面的例子,一个输入框要求输入1-10000之间的数。
    我们要测它有没有超出这个范围,如:0、-1、-2、1000、10001…等等,来判定是否超出了我们的范围。

    • 因果图

    因果图方法最终生成的就是判定表,它适合于检查程序输入条件的各种组合情况。举个例子:原因:A=0,B=0,结果我就可以判定:A=B。
      
    确切的说他是一种因果关系思想。它会无形中指导这我们的测试。
      
    当然了,我们为了以免遗漏,可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。

    • 错误推测法

    基于经验和直觉推测出系统可能存在的错误,从而有针对性的设计测试用例的方法。

    • 其它

    设计测试用例的方法有很多,我们常用就上面几种,其它的方法还有:状态迁移图、流程分析法、正交验证法等等。

    测试用例的格式与要素

    一个测试用例应该包括:编号,标题,测试场景,测试步骤,预期结果。当然还可加入一些它选项,如:优先级、测试阶段…

    举例:

    在这里插入图片描述
    上面的格式取自《微软的软件测试之道》,仅供大家参考,一般项目管理系统自带的用例管理,有固定的格式,搜索、修改等功能,使用起来非常方便。

    如:禅道项目管理、QC、bugfree 等等都带的有用例管理功能。

    测试用例开始设计最优时间

    当根据客户的需求整理出项目需求分析文档时,我们就可以根据需求文档来编写测试用例了。但是,一般我们(国内大多小公司)项目需求文档都非常“简陋”,所以,很难根据需求文档设计测试用例。

    我们只有等到项目开发人员把项目开发出来,给我们系统文档、部署环境、数据库结构(如果系统牵涉到数据库的话),我们根据这些文档来设计测试用例。

    什么情况下不适合写测试用例

    • 性价比低

    如果一个功能很快就测试完了,而且只需要测试一遍,但我们设计测试用例时却比较麻烦,花时间也长。这个时候就没必要编写测试用例了。

    • 需求变动大且频繁

    需求的功能变动非常频繁,而且变动很大,之前编写的测试用例根本没法使用,必须要重新编写,这个时候不建议自己做。

    建议选择第三方测试机构帮忙,比如众包测试服务。

    融入探索性测试思维

    完全的执行测试用例是一件非常枯燥的事情,个人在执行测试用例时会做一些,其它的非常规性的操作,看系统是否会有相应的处理和提示。

    当然了,真正的探索性测试需要对产品的深入了解,以及软件开发技术有一定的深度和宽度。

    如果对软件测试、接口测试、自动化、性能测试、LR脚本开发、面试经验感兴趣可以关注楼下👇公🀄️号🍁🍁 👉 程序员一凡 👈 🍁🍁,会有不定期的发放资料链接,都是从各个技术网站搜集,具体详细内容可自行查看哦!包括上面测试用例模板、测试用例思维导图下载,都是结合企业项目写的测试用例哦
    可拉进交流群 769146372 ,有大佬指点迷津你的问题往往有人遇到过。
    在这里插入图片描述

    在这里插入图片描述

  • 相关阅读:
    C++ 不同继承之间的的关系
    电池故障估计:Realistic fault detection of li-ion battery via dynamical deep learning
    python使用pandas中的read_csv函数读取csv数据为dataframe、使用map函数和lower函数将指定字符串数据列的数据转化为小写字符串
    基于Transformer实现英语-->西班牙语的翻译任务
    沙丁鱼优化算法(Sardine optimization algorithm,SOA)求解23个函数MATLAB
    解决ubuntu登录密码问题
    Gateway断言工厂
    关于SQL中json类型字段优化查询
    在centOS上安装redis步骤
    一、软件工程概述+练习题
  • 原文地址:https://blog.csdn.net/weixin_56502375/article/details/126633255