测试用例又少又准的方法（10年测试大佬手把手教你）

软件测试工作中找bug就是这个岗位本身立足的职责，那么对于很多新人和新入行的同学们来说，这个过程会有点苦逼，毕竟经历的项目经验不多，想快速的切入寻找bug往往会比较痛苦。

那下面我就以自身的经验来普及下如何在工作快速找出系统的不足或缺陷。

1、熟悉你做的产品

不管你是Dev、Test或者PM，熟悉自己开发的产品越多越好，你不但应该熟悉自己开发的模块，也应改熟悉和自己模块相关的其他模块，他们之间是怎样协作的。比如数据库中的某个字段，是如何被各个模块使用的，这利于你在设计阶段就能够找到Bug，把修复的成本降到最低。

同样，你需要熟悉这个产品以前的版本，因为无法向后兼容和升级的产品恐怕很难获得用户的认可。在测试过程中，如果你发现你的产品和以前不兼容或者不一致，80％的情况，这是一个Bug。

2、尽早的去发现Bug

我们大家都知道，Bug修复的成本是和Bug被找到的时间成指数关系的。越早开始找Bug，你能找到的Bug也就越多，对项目的贡献也就越大。

3、每天Review别人的Bug

如果你的团队没有每日的Bug Report，我建议你们建立一个，其实技术上应该没有任何的难度，通过Bug追踪系统的API或者数据库，你完全可以得到你要的数据，这样，整个团队通过学习每天察看别人的Bug，你可以更加容易发现Bug，也不会发现那种Duplicated Bug。现在经常有人跑过来问我，某个Bug是不是一个已知的问题，因为我每天都看Bug Report。

4、在你的日常生活中多准备一些测试的模式

模式是一个很时髦的词，因为它很有用。在日常的测试中，多准备一些测试模式，你会有非常大的惊喜，有时候一个使用一个模式，你可以找到10来个Bug也不是不可能的。比如，使用特殊字符作输入数据；断开网络看UI是否会Crash；在本地化版本中，各个字符串提示是否被本地化；

5、多测试各个模块之间的合作

各个模块之间的测试往往是我们测试中的薄弱点，对于用户来说模块间的合作却至关重要。往往一个数据在模块A中是合法的，在B中却是非法的，一定要找出这些数据，往往者都是Bug

6、编写自动测试代码

你肯定不原意每天都去做同样的事情，那样太没有意思了，简直就是对你的智慧的侮辱。但是一旦我们不进行这些测试，突然有一天早上，我们发现我们的产品以前能够很好工作的功能突然就不工作了，于是大家乱作一团，有人急着修复它，有人在找是谁Check in的。

7、查看产品代码

通过查看产品代码，你往往能找到一些Dead Code或者逻辑上的Bug，这些Bug常常是你无法通过手工测试找到的。

初次怎么写用例？

有很多朋友初次写用例，不知道从何下手，虽然有的公司给出了相关说明文档，但是写起来还是不能得心应手，编写用例方法有很多种：功能导向用例（边界值、等价类等等），用户导向用例（场景法），用户、功能相结合导向用例……

软件测试的同学肯定都写过测试用例，但是如何写出一份高质量的测试用例呢？测试用例有哪些要求呢？为什么要写测试用例呢？

01

为什么要写测试用例？

在版本转测试之后，我们测试的基础是什么？如果没有测试用例，我们应该怎么展开测试？怎么样保证测试点不遗漏、而且不人力投入不重复、怎么样追溯我们的测试质量？如果没有测试用例，这些工作可能都无法开展， 所以测试用例是测试的根基，可以让我们的测试活动从不可控的状态变成可控的状态， 让测试活动开展起来更加顺利，可视化的跟踪我们的测试进度，哪些已测试、哪些未测试，所以要想成为一个高水平的测试人员，写出一份高质量的测试用例是基础。

02

测试用例由哪几部分构成？

测试用主要由8部分构成： 所属的模块、名称、编号、等级、描述、预制条件、操作步骤、预期结果

下面重点说明下面几个部分 名称、描述、预置条件 操作步骤 预期结果

名称：要求熟练的测试人员看见名称就大概明白测试用例所测试的点，大概怎么测试，不要求描述过分详细，尽量简短、精练

描述：测试点的详细描述，相当于测试用例名称的详细版

预制条件：就是在执行操作步骤前，系统需要达到的状态

操作步骤：如果有多个步骤，每一个步骤都需要填上序号，每一行一个步骤， 不能写得过于简略，至少要让熟悉过系统的测试人员可以执行，也建议不要写得太复杂。

预期结果：如果有多个检查点，需要都罗列出来，每一行一个标号， 让人一目了然有几个结果检查点， 另外检查点尽量写详细些，不要出现结果正常、不正常等字眼，应该描述 出正常的具体情况。

把测试用例的每一个部分写好仅仅是测试用例的基本要求，就算这些都做好了，也不能说明这个测试用例是一个好的测试用例。

03

测试用例好坏的评判标准？

首先纠正一个误区，测试用例不是越多越好？相反如果测试用例中冗余用例太多，这样在执行测试用例会浪费大量测试人力，而且不会产生测试效果。

标准如下：

1、测试用例书写格式正确、描述清晰， 其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去

2、测试用例对测试点覆盖完全，也就是说测测过程中发现的问题基本都是通过测试用例发现的，发现的比例越高越好， 越高说明测试用力的防护能力越强，当然测试用例不可能特别完备，在我们执行测试用例的过程，如果bug不是通过用例发现，我们需要对用例进行增加，这样我们下一次就可以把这个问题给防护住。

04

如何写出一份高质量的测试用例？

1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础

2、如果以前有类似的需求，可以参考类似需求的测试用例， 然后还需要看类似需求的bug情况

3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑， 通过等价类、边界值、判定表等方法找出大部分用例

4、 找到需求相关的一些特性，补充测试用例

5、根据自己的经验分析遗漏的测试场景

6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例

7、书写格式一定要清晰

那么对于初次编写用例，应该怎样高效率的编写用例？应该注意点什么？

一、功能导向用例是按照系统需要达到的每一个功能，进行编写用例，这样的用例着重点在功能实现上，而没有考虑到每个功能之间的关联，因而虽然用例已经达到功能覆盖，却不一定达到逻辑覆盖，因而这种方法通常会和其他方法结合使用。功能导向用例是每个用例编写者前期最常用的方法。

二、用户导向用例是按照用户的习惯，将用户使用系统的每个目的作为一个目标，以每个目标实现为基点设计测试用例，但是设计这一类用例，初写者，可能会产生很多困惑（下面写一下我第一次写的时候有哪些困惑，并针对这些困惑，后来采取了怎样的解决方案）

1、编写用例的第一步我该做什么？

理解系统，首先站在测试的角度深入理解系统的每个功能与系统业务逻辑，画出业务逻辑图（即：系统能做什么）。

其次站在用户的角度，列出用户使用系统的目的（即：用户使用这个系统，想干什么？）

2、怎样确定用户目标？

不能确定用户目标，可能由2方面原因造成:a>对系统不够熟悉，b>不了解用户背景。对于第一点原因，那是你自己的原因，只有回过去头看文档了，对于第二点原因，可以从‘系统能做什么’推算出‘用户可以做什么’然后再总结出‘用户可能想做什么’，当然这样做的前提是你对系统已非常熟悉。

3.这个月我将做什么？

刚进入测试行业是怎样总结的（利用测试管理工具进行总结）：

1）把测试管理工具中的缺陷全部分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷。

2）如果说测试新人工作的第一层次是从执行用例开始，那么第二层次就是编写测试用例了。把测试管理工具中的用例详细看几遍，学习别人的用例编写方法和思想，空闲时间可以自己试着编写，看自己编写的与别人编写的用例差距在哪，从而不断完善。重要说明；着重用例编写方法和思想的学习，而不要死搬硬套。

3）进入一些测试论坛，把自己的困惑和经验和大家一起分享，在学习中，不断进步。

总结：

正所谓功夫在诗外，测试理论知识就是那么多，理论知识掌握之后就要不断的参与到项目中来，一个一个项目的练习，锻炼自己的发现Bug的能力，就算随机测试，一个好的测试和一个坏的测试，他们发现问题的能力也是完全不同的。以上完全是个人的一点体悟，各位看官，看的时候也请多多指教。

The End

,