测试用例好难写怎么办?

上一篇 / 下一篇  2022-04-19 10:58:43 / 个人分类:测试

在说怎么写测试用例之前呢,先来聊聊为什么要写测试用例。

理由有5点:

  1. 理顺思路,避免漏测和重复测试

  2. 帮助预估测试排期,把控进度

  3. 方便bug回归验证

  4. 便于发现、记录并复现问题

  5. 标记测试结果,即对于测试结果有个交代

知道了写用例目的之后,你还需要知道,什么样的测试用例才是好的!

优秀测试用例的特征:

  1. ​包含基本信息,包括测试人/开发/产品/需求文档链接地址/技术文档链接地址,等等你测试过程中需要的物料。

  2. ​每一条用例,有很明显的突出测试预期和测试目的。

  3. ​所有用例都是可执行的。

  4. ​逻辑脉络清晰,几乎不存在重复的用例,简约而不简单。

  5. 用例做到分级分层。

  6. 待测功能点覆盖全面。

同时还是想要强调2个观点:

  1. ​不要纠结测试用例的格式或形式!

  2. 测试用例并不是写得越细越好!

有了以上基础,接下来才能够讲明白如何去写好测试用例,不,确切的说是写好测试方案。

(为什么这里会提到测试方案呢?因为测试用例是测试方案的一部分,你不能仅仅只是会去写用例和执行用例,你还需要针对不同的测试场景去制定测试方案)

写测试用例(测试方案)的步骤

一、基础信息

摘自美团技术团队文章

这里再补充一点:测试排期/上线时间/Bug提交地址 等

所以,基础信息至少要包含:

  1. 标题:【xxx】测试用例

  2. 新功能简介(或者需求目的目标)

  3. 参考资料

  4. 干系人

  5. 测试排期

  6. 上线时间

  7. Bug提交地址

如果项目有 业务流程图 或者 系统框架图,也可以po到测试方案里面去体现,方便熟悉业务目的或者上下游系统间的依赖。

二、测试方法

根据需求的不同,又可以分为多种测试手段(手段)

最主要的:

  1. 功能测试

  2. 单元测试

  3. 性能测试

  4. 稳定性测试

  5. 兼容性测试

  6. 安全测试

  7. UAT测试

等等。

需要全部都写吗?

不需要!

根据测试项目的实际情况而定,比方说:你只是测试一个搜索框改了个默认提示文案,你就没必要去单独再去硬套模版测试性能了。

其实谈到写测试用例,大家更多的还是在写功能测试用例,所以这块重点讲。

功能测试用例,要做好分层设计(至少2层):

第一层:冒烟测试用例

第二层:常规测试用例

冒烟测试用例,其实也可以当作是 提测准入测试用例 以及 验收回归测试用例

这部分用例相当于P0级的测试用例,主要是为了保证主流程是完全走通的,如果走不通,则测试有权利打回给开发,让开发把主流程跑通后,测试再继续往下进行。

摘自美团技术团队文章

常规测试用例

设计测试用例的时候,是有一些策略和方法可循的。

测试方法不必多言,掌握几种常用的黑盒测试方法即可:

  1. 等价类

  2. 边界值

  3. 场景法

  4. 判定法

  5. 正交试验法

  6. 因果图

  7. 状态迁移图

其中用得最多的,恐怕就是 等价类、边界值、场景法 了。

测试策略就比较有讲究,需要大量的测试实践,才能形成一套自己的测试策略。

我总结了几条:

1、二八原则:重点抓主流程进行测试,不过分钻牛角尖。

  • 80%的问题,集中在20%的模块里

  • 80%的Bug,由20%的开发者写出(日久见人心,你懂)

2、要模拟真实的用户场景,不要YY出来一个永远都不可能发生的场景。

3、相互依赖的服务之间,最容易滋生Bug。

4、金字塔原理编写法,可以自上而下或者自下而上,杜绝重复用例。

三、数据构造

很多人不注重数据的重复利用,每次测试,都花费大量时间在构造数据上。

但是假如你在些测试方案时,就把数据构造和数据构造的方法写上去,

包括一些SQL、表格数据、json数据、账号密码等等测试数据

当下次还有相同的测试场景时,可以翻一翻之前的测试方案,就不用再花费太多精力在构造数据上了。

写测试用例的五大注意事项:

第一步、明确测试范围

有些需求是多个部门一起合作的,可能会有多个测试和你一起分工合作。

你需要明确自己主要负责测试哪些地方,细化到功能模块。

这个时候,你应该明确两点:

  1. 你测试的模块到底依赖哪些其他模块

  2. 有哪些模块依赖你所负责测试的模块

设计测试用例的时候,把重点放在设计你自己负责的测试范围上;

对于有依赖的模块,也需要考虑降级和容错,也就是你要考虑,你负责的模块出问题了,对人家造成什么影响;

或者,人家负责的模块出问题了,对你所负责的模块有什么影响。

明确测试范围的2个好方法:

  1. ​需求评审会一般产品会按功能模块去划分,分别评审,你需要和与你对接的产品和开发步调一致。

  2. ​测前沟通,找开发和产品去做测试前的沟通,必要时,甚至要找关联的测试人员去做一次沟通,明确测试范围。

第二步、熟悉需求文档

需求文档至少要看三遍!

在你熟悉需求文档的时候,也相当于已经进入测试了,像一些公司美其名曰:文档测试。

产品经理写需求没想到的,你想到了,都可以大胆的提出来,要有质疑的精神。

另外这里还有一个小建议:尽量让产品经理把产品的流程图画上,流程图可以反映出数据流向是怎样的,这可比文字更加直观。

这样你会对整个需求文档有更深的理解。

第三步、熟悉开发文档

开发的系统设计文档、接口设计文档、数据库表结构,如果有的话,最好都看一遍。

第四步、设计和编写测试用例

现在大部分测试工程师手工测试都喜欢用Excel或者Xmind来编写测试用例。

  • Excel 比较适合用例较少、操作步骤简单、可能性有限、结果预期比较明确的功能。

  • Xmind 比较适合用例较多、功能相对复杂、结果预期比较多样的功能。

以下分别举两个使用场景:

(1)假如说测app的话,个人感觉用Xmind可能会更合适,

用Excel的话,由于功能比较繁琐,可能用例条数会很庞大,一方面测试起来,看太多表格,容易头晕。另一方面维护起来也比较麻烦。

而Xmind可以只是把功能点写上,本身结构化的设计思维会让测试思路比较清晰,测试用例维护起来比较方便。

(2)对于上线后的回归测试验证点(CheckList),我们可以用Excel去表达,主要是针对主流程主功能的正向操作进行验证,逐条操作也防止漏测。

但其实用哪种软件编辑测试用例,都是看个人的使用习惯,关键是自己能看懂,别人也可以看懂就可以了。

设计测试用例时的,需要结合需求文档,把测试点罗列清楚,尽量用简洁的语句表述,非常忌讳写出过于啰嗦的用例。

另外,设计测试用例的几条思路我也简单介绍一下:

  1. 按模块把功能点罗列全,切记不要照抄需求文档,这样写不写有什么区别?

  2. 软件测试的基本测试方法要有效利用上,像边界值法、等价划分类、场景法等等,都是特别实用测试方法。

  3. 不要在细枝末节上纠结太多,根据二八法则,80%的bug都集中在主流程里面,要确保主功能主流程没问题。

第五、用例评审

测试用例设计完,一定要和产品研发一起评审测试用例,漏掉的测试点要及时补充。


TAG:

 

评分:0

我来说两句

Open Toolbar