• 14
  • 14
分享
  • 关于测试用例编写你不得不了解的那些事儿!——软件测试圈
  • 曼倩诙谐 2021-08-11 10:04:08 字数 2214 阅读 2393 收藏 14

  对于一个软件测试人员来说,编写测试用例是不可或缺的一项技能,但怎么写好一个需求的测试用例却不是很容易,特别对于新手来说,更是不容易,我也是从新手一步步走过来的,下面我就把我的经验总结出来供大家参考吧。

  测试用例是什么

  这个问题很简单但却不能不知道,刚入行,我们会很懵,弄清楚这个问题,对我们接下来写测试用例非常有帮助。

  测试用例顾名思义就是用来测试的例子,但这个例子却不是随便的,而是通过我们分析后精心设计出来的,是我们测试的一个标准。

  书写结构要符合规范

  测试用例不仅是我们测试的例子,还是我们软件功能的一个详细描述,一个好的测试用例,不仅仅是自己能看得懂、测试场景全面,还要能让别人看得懂,让别人通过你的测试案例能对你所测试的那个功能有一个全面的了解和认识。

  所以测试用例的书写也不是随便的,它有一定的结构。一般有以下几部分组成:

  测试用例名称

  这个一般是在你写多个需求测试功能点时用它来标记你当前写的是哪个功能测试点的用例,比如你正在写登录账号的测试用例,你就可以在这一栏写上账号登录测试。

  测试用例描述

  这个一般是对你当前所写测试用例功能点进行一个简单的描述,让人一眼能看出你这个是在测试哪个点。

  还拿上面的登录测试来说,我们就可以这样写:输入正确的账号、正确的密码、登录成功。

  测试前置条件

  前置条件一般就是指在你接下来的操作之前要做的准备工作。

  比如有一个需求是这样的:当订单所选国家对应的是否汇总物料的字段标识为Y时,就把这个订单下的所有备件物料汇总到一起,否则不时进行汇总。

  那么在我们写这个测试用例的时候,它就有一个前置条件就是所选国家是否汇总物料的标识为Y或N。

  测试操作步骤

  测试步骤这个很简单,就是把我们执行测试的操作一步步写下来,这个一定要写清楚,方便后来人查阅和学习。

  期望结果

  就是你在前置条件下执行当前测试用例步骤后得到的一个正确的结果也就是你想要的结果就是期望结果。

  了解需求的背景、开发实现方案

  为什么要了解需求背景和开发实现方案?了解需求背景可以帮助我们分析哪些应用场景是合理的,哪些是不合理的,哪些场景是涉及到此需求的,我们接下来的测试用例写的才能更接近实际应用。

  那如何了解需求背景,一般是从需求提出人那里了解,有的是从产品经理统一了解,这个要根据不同公司的不同安排进行了解。

  了解开发实现方案有助于我们从代码层面和实现逻辑上来识别一些潜在的风险问题,同时也给我们测试用例提供更清晰的思路和场景。

  开发实现方案的一般是通过开发设计评审,有的公司没有这个步骤,那只有自己主动跟开发小哥沟通了,只有这个了解清楚了,你才能更清楚的知道功能的实现输入和相应的输出是否正确,才能提前识别期望结果与需求提出人的结果是否一致,你的测试用例写得场景才能更全面。

  掌握必要的测试用例设计方法

  测试用例设计方法也是编写测试用例不可缺少的一部分,掌握一定的测试用例设计方法有助于我们分析测试场景。

  不同的需求不的功能实现点要用不同的方法进行分析设计。

  一般来说有做比较判断或分类的,在比较判断这个点上常用边界值分析和等价划分方法来分析设计。

  有逻辑判断的或功能较复杂的就要用因果图法,正交实验法等这些(这些方法网上都有详细的介绍我就不详细说了)。

  比如一个需求功能是这样的:根据报销单中出差人员的出差的城市进行判断所提交的报销金额是否超标。

  这里面有一个隐藏的信息就是出差城市和报销金额的对应的关系,这个是在后台的一张表中,这张表结构是这样的:

  类别城市名称金额

  类别标记这个城市是一类城市还是二类城市,金额就是报销限制金额。

  从上述的信息中我们可以看出这个既有分析还有比较判断,所以我们这里要用到边界值分析法和等价划分来分析设计场景。

  边界值来分析金额比较的场景,等价划分来划分城市分类,所以得出的分析场景如下几个:

  ·一类城市,报销金额小于给定金额

  ·一类城市,报销金额大于给定金额

  ·一类城市,报销金额等于给定金额

  ·二类城市,报销金额小于给定金额

  ·二类城市,报销金额大于给定金额

  ·二类城市,报销金额等于给定金额

  充分考虑功能、性能、安全问题

  这个是测试用例编写一个比较重要的点,无论是你做哪个功能软件测试都要考虑这几个点,一般的话我会从这几方面考虑:

1.png

  在我们了解清楚我们的需求功能以后,一般按照上面这个思路去设计我们的测试场景都是比较全面的。

  比如在一个原有的网页上面新增一个查询库存产品余量的功能。

  查询条件有:1.产品名称;2.产品型号。

  两者可组合查询。

  查询结果展示有:

  产品名称、产品型号、库存余量、出库总量。

  这是一个很简单的查询功能,通过分析我们知道:

  数据存于本地数据库表中,直接取的就是一张叫产品余量表里面的数据。

  由于产品种类型号比较多,存在单个产品名称查询时数据量比较大的情况。

  因为是在原有网页上新增的功能,网页的安全性不需要考虑,但查询接口的安全需要考虑。

  由于是新增功能影响到页面布局,所以要考虑易用性和兼容性。

  查询功能可能会存在多人同时查询和一个人多次频繁查询的情况,所以性能这块要需要考虑并发,和频繁操作的场景。

  基本场景分析完了,我们就可以根据我们上面所说的考虑点列我们的测试场景了,如下:

2.png



作者:薇薇   

来源:51Testing软件测试网原创

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 早就听过CPU火焰图的强大功能,也听过几个火焰图工具,今天终于开始尝试使用CPU火焰图生成工具。奈何由于各种原因,Intellij自带的火焰图插件并不能用,着实让人不快。故而找到一个async-profiler分析工具作为替代品。当时正在测试随机数性能的,所以就用了一个动态QPS模型的Case,学习了async-profiler的使用。很意外地发现了一个性能可以优化的地方。经过尝试,CPU使用率降低了0.24%,也算是第一个成果了。async-profiler这个工具安装和使用教程,可以网上搜一下,建议去Github仓库看看Wiki,这里我就不多说。Case code下面是Case的代码,用了...
            0 0 1096
            分享
          •   1 背景  分布式批量系统指的是采用分布式数据库架构,主体功能由批量程序实现的系统。分布式系统批量程序的性能测试,除了和联机交易性能测试一样关注服务器资源使用率是否合理、是否存在性能异常外,在测试执行阶段需要关注是否因数据分布不均衡导致部分并发子程序执行时间过长,成为整体批量程序的“短板”,从而影响批量程序的整体时间。  下面我主要介绍一种分布式系统批量程序性能优化的思路,并结合实际测试效果说明。  2 分布式系统分片和批量并发规则  被测系统数据库为分布式数据库,存储并处理某公司各个机构的业务数据,包括若干个数据库分片、500多个分片键(分布式表的一个主键字段,用来区分数据存放的分片),...
            0 0 885
            分享
          •   中国台湾《联合报》称:经多方评比后,台积电最终决定将最先进的 1nm 制程代工厂选址定在嘉义科学园区,总投资额超万亿新台币(IT之家备注:当前约 2290 亿元人民币)。  对于这一传闻,台积电表示,选择设厂地点有诸多考量因素,台积电以中国台湾地区作为主要基地,不排除任何可能性,也持续与管理局合作评估合适的半导体建厂用地。  消息人士透露,台积电 1nm 制程将落脚嘉义科学园区,台积电已向相关管理局提出 100 公顷用地需求,其中 40 公顷将先设立先进封装厂,后续的 60 公顷将作为 1nm 建厂用地。业界估,台积电 1nm 总投资额将逾万亿新台币。  在上个月举行的 IEDM 2023...
            0 0 845
            分享
          • 什么是 Newman?Newman 是一款专为 Postman 打造的命令行工具,旨在通过自动运行 Postman 集合和环境,实现 API 测试的自动化。它使得开发者无需打开 Postman 图形界面,即可直接在命令行中执行测试用例。Newman 的优势使用 Newman 进行 API 测试,可以带来诸多好处:快速反馈:每当代码发生变更,开发者都可以借助 Newman 迅速获悉 API 性能的最新状况持续集成:Newman 可以与持续集成(CI)系统无缝对接。一旦有任何代码变更被推送,CI 系统便会自动触发 Newman 运行相应的 Postman 集合。全面测试:Newman 能够全方位测...
            0 0 1568
            分享
          •   两个熟悉的场景:  ·生产环境出现问题,解决问题,原因复盘、责任分配到人;  · 无休止的测试-回归-再测试-再回归测试,已经投入了很大精力,但仍对项目质量不信心;  如果自己所负责或参与的项目经常遇到上面的两种情况,不妨从项目测试流程角度,去思考原因以及破开瓶颈的方法。  测试流程拆解  需求评审  通过参与技术设计评审,可以为测试方案提供依据。例如:核心业务是否需要接口测试、新老数据兼容问题、测试场景的数据构造以及测试所需的工具等,都可以在这个阶段进行思考和产出。  另外,可以有效的评估需求影响范围和风险点,避免遗漏。  此阶段是质量的基石,通过测试左移,尽早发现需求设计缺陷...
            0 0 1202
            分享
      • 51testing软件测试圈微信