软件测试中的测试用例Test Case原来是这么回事！
如果你去找一份功能测试的工作，在软件测试工程师面试过程中，有一些面试官会来一两个非常简单的问题什么是Test Case？你是如何去写Test Case的？我们先来看一下测试用例的介绍什么是测试用例？测试用例（Test Case）是为项目需求而编制的一组测试输入、执行条件以及预期结果，以便测试某一个程序是否满足客户需求。其实测试用例它就是一个文档，或者说是一个说明性的文档。文档中间包括了一些关键性的内容比如它要有输入、要有条件，要有预期结果，通过你的条件、输入以及预期结果，我就可以去执行的时候来判断这个程序是不是满足客户（用户）的需求。我们把这一类型的文档就叫做测试用例。（测试人员的依据内容）当然说，对于一些不规范的或者说一些小公司。本来就我一个软件测试工程师，然后我也没有时间去写测试用例，那我拿着这个软件就直接开测了呗，那么在这种情况下，它也是没有测试用例的。但是在没有测试用例的情况下，极有可能导致非常多的问题，比如说漏测，比如说测试重复、无法去衡量软件测试完成的工作量。没有依据等等之类的。所以说稍微规范的公司，咱们都要去写测试用例，我们也会花很多的时间用在编写测试用例上面。为什么要写测试用例？
[*]1.熟悉被测软件的业务
[*]2.明确测试的思维和方式
[*]3.保证测试的时候不遗漏测试功能点
[*]4.测试工作的一个输出
就是为了避免前面说的一些问题。
第一个，我们在写测试用例的时候，其实也是熟悉软件测试业务的一个过程，其实这个是非常有必要的，包括咱们在测试这个项目之前，比如说你去一个新公司，你前一周或者前一个月，你都是在做同一件事情——看文档。通过看文档尽快的去熟悉被测试软件的业务。你对这个被测试的软件的业务越熟悉，那么你在测试的过程中你才能测试得越准确。可以避免一些不必要的错误。第二个，我们可以明确在软件测试中的思维和方式。第三个，这是你在软件测试工作的一个输出。也就是说我早上九点钟去晚上六点钟下班，当老大问你说你今天做了什么事情的时候，结果你这也没有那也没有。我把测试用例写好了，一天写了三五百条测试用例，这也是工作的一种衡量。（当然多少条是没有硬性规定的）能够发现bug的测试用例就是好的用例？这个是错误的！
什么是好的测试用例？
能够全部覆盖需求的测试用例就是好的测试用例测试用例的使用范围
[*]1.手工测试用例（功能测试）
[*]2.自动化测试（接口自动化、UI自动化）
[*]3.性能测试用例
不论是在手工测试还是自动化测试、性能测试我们都是需要去写测试用例的。测试用例的四要素
[*]上下文--前置条件，进入条件
比如说我们要对知乎进行登录的一个测试那么他的条件是什么，我们是不是先得把知乎这个APP安装，这个就是他的上下文。再比如我们要在知乎发文章，他的前提条件也是必须要登录，这个登录的操作就是他的上下文或者说前置条件）
[*]测试数据
测试数据是非常关键的，比如说我们知乎的登录，登录的数据要准备的就是用户名与密码，准备好了，才能对这个功能去进行测试。这个数据是非常多的，在这里我们要想到的一个点，是无法进行穷举测试的。我们在讲测试原则的时候会讲到这个。因为第一个咱们的项目时间有限，第二个我们的人力成本也是有限，第三个实在这个数据量十分庞大，我们根本无法对它去进行一个穷举测试。因为我们就要对这些数据去进行一些分类、筛选。选一些有代表性的数据来进行测试。
对于测试数据的话，肯定要用一些方法对它进行分类，选取一些具有代表性的数据。这一个其实就是咱们测试用例非常重要的一个环节，就是设计用例的方法。包括等价类、边界值、判定表等等这一些，都是帮助你去筛选数据的。
[*]测试步骤
第一步做什么第二步做什么第三步做什么，这个好理解吧。因为咱们去写测试用例不仅是给自己看的，首先你自己写的测试用例，你自己肯定要看得明白，除了当时能看明白，可能我隔两个月隔一年以后我再来看这个测试用例我也要能看得明白。同时也是给别人看的，因为我们自己写的测试用例并不一定是我们自己执行，这也是咱们测试的原则之一。因为容易形成思维定式（交叉测试）
[*]断言--预期结果
我们要去设置一个预期结果，来判断咱们的这个测试用例以一个什么样的标准来判断它是正确的还是错误的，从而来验证这个功能是否OK
测试用例必须要包含这四个要素，缺一不可！
文章首发于公众号：程序员一凡，转载请注明出处！
:time:
页:
[1]
