卷麻了,00后测试用例写的比我还好,简直无地自容.....

Posted 测试界的彭于晏

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了卷麻了,00后测试用例写的比我还好,简直无地自容.....相关的知识,希望对你有一定的参考价值。

前言

作为一个测试新人,刚开始接触测试,对于怎么写测试用例很头疼,无法接触需求,只能根据站在用户的角度去做测试,但是这样情况会导致不能全方位的测试APP,这种情况就需要一份测试用例了,但是不会写,求指教!还有就是测试出来的bug该如何追踪?与开发的接触基本上面对面的交流,没有很好的一个规范

带着问题学习是最高效的学习方法。

目录

前言

一.什么是测试用例

二.为什么要写测试用例

三.如何编写测试用例


因此,在介绍如何编写测试用例之前,先看一个软件系统登录功能的测试(如下截图所示):

要做这个登录页面的测试用例,你会从哪些方面思考进行测试呢?

看似简单的页面功能能够设计多少条测试用例完成较全面的测试呢?10条以内?20条?.......

那么在给出上述答案之前,先带大家熟悉一下 什么是测试用例?测试用例有什么作用? 然后在结合上述抛出的案例抛砖引玉一起讨论 如何编写测试用例?

下面就是此文目录截图:

一、什么是测试用例

测试用例:为了特定的目的(证明软件存在某问题)而设计的一组由测试输入、执行条件、预期结果构成的文档

1、测试用例简单来说就是指导如何做测试的文档,该文档主要记录需要验证被测软件的是否满足需求

2、测试用例表现形式常见的有两种,可以以模板形式展示

1)一种是通过Excel直接编写

——大多数项目中都需要按照这种方式设计编写

2)一种是通过xmind直接整理测试点

——时间紧迫,项目没有强制要求时,可以设计测试点的形式编写
——对于业务流程类的测试,也可以整理为测试点进行测试

3、设计及执行人员:测试工程师

4、用例的模板:描述编写用例核心内容,一般项目都有自己的设计用例的模板,常见测试用例模板可参照如下:

为了支持一下新入行的朋友们,这里也把我入行多年精心整理的上百份学习资料和讲解视频分享出来,新手入门绝对用得上,一并放在下面了,废话不多说,文末免费获取~

二.为什么要写测试用例

为什么要写测试用例,实际中产品出现问题,第一责任人首先想到的是测试为啥没有测到?

产品出现问题了,你为啥没有测出来呢?

当然,除了避免“甩锅和背锅”,其实写测试用例更重要的作用如下:

  • 技术上将需求转化为具体可验证的指标
  • 以文档的形式记录软件可能存在的问题
  • 防止测试过程的活动出现遗漏,提高工作效率
  • 测试工作量的展示

三.如何编写测试用例

既然写测试用例如此重要,那么如何更好的编写测试用例呢?个人认为需要满足如下几点: - 常规思考,设身处地的从用户角度出发(比如:实际用户是这么使用的么,会不会遇到异常情况呢?) - 测试理论方法的支撑(比如:根据需求设计测试用例时,能用到哪些常见的测试用例设计方法?) - 产品的熟悉和经验的积累(比如:已经有过类型项目经验,曾经在某个方面有过问题,当时是如何处理的呢?) 上述的设计用例过程,有个前提,就是对于测试有耐心和毅力,加上日常有意识的思维训练,才会写出全面的用例。

1、常规思考

回归到开篇的问题,对于一个基本的登录页面,按照常规思路能否会想到如下截图的测试点呢?实际,这些测试点都是源于从用户角度出发,结合需求进行细化设计的过程。实际测试中是不是只有这些测试点呢?

2、学习积累

相信大多数测试工程师都能够想到上述基本的测试点,然在实际工作中面对的项目不同,设计测试用例的颗粒度也有不同的要求,如果针对上述登录的模块,更深入一层考虑呢?此时需要对产品的熟悉程度及测试经验的加持,而且这些点的设计是不断学习、熟悉项目、测试积累中得到的。

3、理论支撑

有了常规的思考,有了经验的积累,还需要理论的支撑。测试用例毕竟是通过人去思考设计,这个过程不可避免有疏漏。如何规避?实际就需要测试理论的支撑,个人认为深入思考设计用例不外乎以下两方面:

1)测试用例的设计方法

测试理论中很关键一块就是将需求拆分为具体的测试点,然后根据用例设计方法进行具体的设计,其中拆分需求的关键是熟悉需求,将文档中已有的描述内容,按照用户使用场景、个人测试经验的积累(如果有的话)、把大段的内容拆分成能够直接用用例设计方法的测试点,这样就直接可以通过简明扼要的文字描述转化为Excel的测试用例,在这个过程通俗理解就是拆分细化的过程,直到可以直接写用例验证一个具体的功能点即可。

其中熟知的设计用例方法有:

- 观察法

- 等价类、边界值

- 判定表、因果图

- 流程图、场景法

- 错误推测法等

2)测试设计的思路开拓

倘若按照需求将已有的描述信息都已经拆分完毕了,是不是就可以确保测试没有问题了呢?
其实不然,在上述基础上如果还需要再拓展全面测试,还需要借助于软件质量模型的特性,从这些特性出发,给予测试用例设计者更多的思考空间。这样的设计就更加的全面可靠。

常见软件质量模型特性说明:

- 功能性:功能有没有,好不好用

- 性能效率:对应系统的资源耗费程度及响应时间

- 易用性:容易理解、学习、使用

- 兼容性:能够兼容不同的软硬件平台

- 可靠性:不易出问题,万一出问题容易恢复

- 安全性:对于用户的安全保障(外在的人生安全、内在的信息安全等)

- 可移植性:能否在不同环境条件下无故障运行

- 可维护性:对于后期的修复维护是否方便快捷

因此,对于上述登录功能,按照上述质量模型的思路指导,就得到如下的测试点:

四、写在最后

此时的你再回过头来看看,还会认为登录这个百试不爽的功能就设计十几条甚至几十条测试用例了吗?显然不是那么简单,需要在熟悉需求基础上,进行拆分细化,将常规的思考、经验的积累、理论的支撑结合起来使用,最终才能转化为测试待验证的结果。

熟悉需求上第一步,在此基础上进行测试点的拆分细化,这个过程如果对于复杂一点的功能点,需要借助于测试用例的设计方法,对于页面级的测试点应用最多的不外乎是等价类、边界值。

仅仅熟悉了需要,还需要结合经验的积累,从质量模型的特性出发,进行全面的思考功能点的设计,是否出现遗漏的,是否有项目特殊要求的。

用例的设计不是一蹴而就的事情,好的用例也是需要不断的练习反复的修改评审,才能编写出卓越的用例。

福利福利

如果你还有许多困惑,那么我整理的视频资源和文档会是你的良师益友,或许可以给你带来一些实际性的帮助与突破【保证100%免费】

卷麻了,00后测试用例写的比我还好,简直无地自容......

经常看到无论是刚入职场的新人,还是工作了一段时间的老人,都会对编写测试用例感到困扰?例如:

 如何编写测试用例?

作为一个测试新人,刚开始接触测试,对于怎么写测试用例很是头疼,无法接触需求,只能站在用户角度去做测试,但是这样情况会导致不能全方位测试APP......

如何写出高效的软件测试用例?

从事软件测试大半年,基本上都是靠着对软件产品的大致了解来进行测试工作,很难对产品 进行一个全面细致的测试。现在想学习一下怎么写测试方案和测试用例,有哪些相关书籍可以参考?

固然,编写一份好的测试用例需要:充分的需求分析能力 + 理论及经验加持。 但这并不意味着,没测试经验、分析能力弱就不能写好用例,还是有方法可循的。作为混迹测试职场 9 年的老人,给大家分享一些用例编写的心得,接下来我会从以下几个方面展开来讲:

  1. 测试用例概念、作用、内容等介绍
  2. 如何编写测试用例?
  3. 微信发送朋友圈案例分享

​​​​​​《测试用例模板大全》

 一、测试用例介绍

测试用例是为项目需求而编制的一组包含测试输入、执行条件以及预期结果的文档,以便测试某个程序是否满足客户需求。

1、为什么要写测试用例?

  1. 是测试工作的指导,是软件测试质量稳定的根本保障,评估测试结果的基准。
  2. 有一份用例来指导测试执行,可以在测试人员疲累的时候起到一个牵引作用。
  3. 编写用例的过程中,通过熟悉需求,对系统架构或业务有更深入理解
  4. 可避免测试背锅

2、测试用例模板:每家公司模板可能会有差异性,一般大致包含以下内容

  • 用例编号:唯一性,一般规则:产品名_测试阶段(it st uat)_测试项_数字
  • 测试项目:对应一个功能或子功能模块
  • 测试标题:一句话总结当前测试的用意和目的
  • 重要级别:高/中/低
  • 预置条件:需要满足一些前提条件,否则用例无法执行
  • 测试输入:需要加工的输入信息,跟步骤结合起来一定要具有指导性意义
  • 操作步骤:明确给出每个步骤的描述,执行人员可以根据该步骤完成执行工作
  • 预期结果:根据预期输出比对实际结果,来判断被测对象是否符合需求
  • 实际结果:通过测试执行后的实际结果,写用例时为空。

3、测试用例编写形式

  1. 通过 Excel 编写,上述给出的模板就是该种形式 ,适用于项目开发时间比较充分的情况下
  2. 通过 Xmind 梳理测试点,适用于项目开发时间紧急情况下
  3. 项目管理平台例如禅道上编写,不常用

二、如何编写测试用例

大体思路分为三步:

第 1 步:依据需求梳理功能及功能点

第 2 步:通过测试理论方法及经验,梳理测试点

第 3 步:挖掘隐性需求,覆盖非功能测试层面

举例: 微信朋友圈动态发送

第 1 步,依据需求梳理功能及功能点

简而言之,就是把你能看得到的功能及功能点梳理出来。公司一般都有产品需求资料,例如需求规格说明书文档、原型图、UI 设计图;当没有任何需求资料情况下,可以通过操作软件来熟悉业务。像发送朋友圈,我们可以先功能模块—> 再子功能—> 再到功能需求细节来梳理,注意一些不明确的需求细节需要及时跟产品确认。大致梳理如下:

 

第 2 步:通过测试理论方法及经验,梳理测试点

这一步非常重要,依据需求梳理完功能点后,接下来我们需要针对每个功能点拆分整理具体的测试点,这时候我们需要设想用户操作的所有情况,包含到正常及异常场景。

我们需要同时具备测试理论方法和测试经验,才能较好地设计出一份全面可靠的测试用例。常见的测试用例设计方法包括:等价类划分、边界值分析、判定表、因果图、错误推测法、场景法、正交试验法、状态迁移法等。测试经验需要多个项目测试的积累及沉淀。对于测试新人来说,测试经验可能趋于 0,这个时候可以先借鉴一些前人的经验。对于此,我曾经整理过一份资料,很多测试新人用过资料后都觉得对测试用例有了豁然开朗的感觉,知道怎么去写用例了。

这份资料分享如下:

 

注:这份资料我们可以用在任何的软件产品的分析上面,从本质上来说,任何一款基于用户角度操作的软件产品,操作功能无外乎都是对数据做增删改查,所以当需要对软件产品进行分析编写测试用例时,我们可以依据当前功能是增删改查的哪一个操作,用上面梳理的测试点来套用编写用例。按增删改查操作来梳理,分为:

  1. 表单测试:涉及到数据提交的页面,包含新增或删改数据页面
  2. 搜索测试:为数据查询的页面
  3. 删除测试:为数据删除的页面
  4. cookies、session 等测试:用户操作角度,补充测试
  5. 数据库测试:页面添加、修改、删除、查询业务相关操作,就是对数据库数据的增改删查

通过测试理论方法和测试经验,我们可以得出微信朋友圈的测试点:

编写为 Excel 文档用例,可为:

 

728 x 291 1254 x 502

第 3 步:挖掘隐性需求,覆盖非功能测试层面

除了以上这些功能层面的,对于微信移动端产品,还需要考虑到一些特性方面的测试,包括非功能测试层面,如:

三、总结

编写用例虽然不是那么简单的事,但是通过以上,是不是发现还是有方法可循的?不会写的先模仿着来写,日积月累,通过项目中测试思维的长期训练,工作中出现 bug 的经验总结,相信某一天你会发现编写测试用例也没有那么难!

《测试用例模板大全》

 学习资源安排上:

 

 

 

 

 

 

以上是关于卷麻了,00后测试用例写的比我还好,简直无地自容.....的主要内容,如果未能解决你的问题,请参考以下文章

卷麻了,00后性能测试玩得比我还6,简直无地自容了...

.NET测试用例写的好不好?让变种来测试一下!

为啥 fwrite 写的比我告诉它的要多?

在 Appium Sendkeys 中没有按预期工作,它发送的比我给它的多

软件测试需要学习些啥技能?

pytest数据驱动的缺点