如何编写测试用例？

1.首先,什么是软件测试?

根据侧重点的不同，主要有三种观点：

1）Myers认为：

“软件测试是为了发现错误而执行程序的过程”，明确提出了“寻找错误”是测试目的。

2）1983年IEEE对软件测试的定义：

“使用人工或工具测试某个系统的过程，其目的在于检验它是否满足需求的规定或是弄清预期结果与实际结果之间的差别”。

明确地提出软件测试是以检验是否满足需求为目标。

3）从软件质量保证的角度看：

软件测试是一种重要的软件质量保证活动。

测试过程中的活动包括“分析”软件和“运行”软件。

也有人认为软件测试就是在软件投入运行前，对软件需求规格、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。

2.软件测试存在的意义所在

软件公司为什么要开展软件测试活动呢?

因为没有经过测试的软件，质量是不能得到保证的，可能会影响人们的日常生活、使人们的财产受到损失、甚至危机到人的生命安全。

3.编写测试用例的思维方式?

我们在编写测试用例的时候主要的思维方式有逆向思维、发散思维是我们需要重点去关注的。

逆向思维

在业界，有这么一个比喻，开发是盖房子的，测试是拆房子的，其实这种看法或许存在某种偏见。实际上开发与测试的目标其实是一致的，都是为设计出满足用户需求的高质量软件。只是由于分工不同造成了开发和测试因为工作性质而造成了天生的对立，开发是将需求实现出来，而测试是验证开发的实现是否满足需求，这种验证就是带着一种怀疑的眼光和不信任的心态，这就造成了我们在测试工作上要有与开发不一样的逆向思维。而且事实证明，这种思维方式发现的bug是最多的。

测试的目的是发现bug，说明程序有错，要证明程序有错就要有说服力的数据，而这些有说服力的数据就是bug。如果我们在设计测试用例的时候仅从正向思维去出发，设计的测试用例自然而然就是正向的，这其实与开发进行设计实现走的是同样的路，即验证程序是按需求实现了，能够达到预期，但是实现的功能有没有问题，不得而知。

逆向思维的方法，其实就是不走寻常路，这也是开发人员常常忽视的地方。大家都在走同样的路，我却往反方向走，用与正向思维相反的思维方式设计用例，发现新bug。这是一种历练，也是历练中的摸索、创新。通过这种不同寻常的历练，经常能够帮助我们总结出适合自己的方法，自己也能得以提高。

发散性思维

发散性思维其实就是一种寻求多种答案，最终使问题获得解决的思维方法。因为其眼光开阔，思维活跃，所以能产生大量独特的新思想。

概括来说，发散性思维在测试工作中可以分为以下两个阶段来体现：

1、测试设计阶段的发散

可以理解为测试方案，即测试思路的形成阶段。以下为说明例子：

某嵌入式软件有用U盘导出数据的功能，请写出测试此功能的思路。

2、用例执行阶段的发散

我们都知道，用例执行时必须严格按照已经设计好的用例来执行，其实在实际工作中，软件测试不能进行穷举测试，用例对代码的覆盖率不能够做到100%，尤其是一些组合的用例，更难去覆盖全面。根据这一特点，我们在进行用例执行完成后，都会进行随机测试，其实这就是发散性测试。就是说我们在进行测试时，可以不用按照已规定的流程去走，而是可以跳过某个步骤提前去结束，其结果往往就能发现问题。随机测试就是跳出已知的步骤，可以来回反反复复进行操作，这种过程，本身就是另外一种用例设计的过程。

除了发散，我们还需要严谨，不能无边无际的去发散，就像一匹野马，如果控制不住，就会弄巧成拙。

4.具体编写的流程

1、测试需求分析，得到测试点

在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐藏的需求；通过对需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一些测试可以提前介入的工作等。

2、分析得到用例优先级

得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优先级，一般分为高中低三个优先级。

3、细化测试点变成可执行的用例

根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。

在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。

另外需要考虑的就是测试点细化到什么程度的问题，也就是一个度的问题，我们要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易让我们纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。

4、及时更新测试用例

需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。

另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。

5、及时维护通用测试用例

什么是通用测试用例呢？通用测试用例就是：项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。所以说，通用的测试用例是一个对用例不断维护的产出，因此我们在测试软件维护的过程中一定要及时的更新通用测试用例，对后面的测试和用例维护有一个很大的指导作用。

5.平时能通过哪些方式提高软件测试功底?

如何提升用例编写能力

1、 熟悉业务，了解系统

任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。

任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题和业务问题。

2、用客观的思考方式站在用户的角度分析

作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么，客户不想要什么，也就是所谓的客户的使用场景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户基本不会用到的场景有哪些。

3、多思考，不要拘束于惯性思维

我们知道一个人做一个工作时间越久，也就是我们说的经验越丰富，可能这个思维方式就会越被限定住。比如，测试的统计表多了，当拿到一个新增的统计表的时候，首先想到的是公用用例上所列的测试点基本上就是最全的了，我都不用思考，直接用就行了。

其实这是一个误区，公用用例的目的是帮助我们减少一些不必要的内耗，但是我们的思维不要被它所限定，如果公用用例中某个点是错的，那我们岂不要一错再错。所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要被这种惯性思维束缚，不要被所谓的经验束缚。

4、不要闭门造车，利用好网络资源

提升测试用例设计能力，多思考是非常重要的，但是不是让你傻思考，当你的进步遇到瓶颈的时候，不要闭门造车，做井底之蛙，要充分利用网络上的学习资源，学习一些前辈的经验，并把这些运用到实际的测试用例设计中去。山外青山楼外楼，多浏览和关注一些关于测试用例设计的网站或者微信公众号，广开言路，相信会对你的测试用例设计能力的提升会有很大的帮助的。

5、善于总结分享

基于以上四点我们还要做到善于总结，乐于分享，把经常见到的用例设计的误区和一些好的用例设计，和用例设计习惯分享给周围的小伙伴，这样可以集众人之所长，不断提升我们的用例设计能力。