在测试用例的重要性

        网上找了很多篇关于测试用例的重要性，答案是不能令人满意的或过于理论一。让人看了神情木讷，看完亏损后，；太旧（我不知道那个时代留在理解）。

我非常想了解测试系统，所以，我写这篇文章：

软件測试的工作，都少不了写用例的时候，我想大部分的用例都是在产品需求出来一部份之后就已经開始了。由于这个时候。已经有了写測试用例的根据。有了大致需求之后对编写用例来说一般仅仅是一个開始，我们还须要很多其它的信息，比方UE（用户交互设计稿）、UI（用户界面设计图）、需求的描写叙述、产品大纲，功能模块图来提供很多其它的信息来完好用例。

往往产品在開始设计的时候。正是用例生命周期的開始。

为什么这么说呢。在下面的文章其中。我们让他慢慢的浮现出来：

        我们有时候非常困惑。为什么要写測试用例，測试用例对后来的測试究竟起到了什么作用？有时我们甚至怀疑。项目測试中是否须要測试用例。

好。我先举个測试用例的运用场景。

        如果，这里新成立了一家新公司叫“豆比科技”，他们自己设计了一款软件产品“逗你妹”。产品的需求，用户交互，设计图。各个功能模块的具体描写叙述都有了，产品開始投入到开发其中。而开发好的产品肯定是有非常多问题的，必需要又人来保障产品的质量。

        那么谁来保障产品的质量呢，首先，产品能够做这事。由于产品是他们设计的，他们须要对产品负责，可是产品们都非常忙，由于他们须要制定产品的战略规划，功能的设计等；设计能够做这事。由于UI是他们设计的，他们对UI最了解，可是设计们也非常忙，由于他们须要很多其它的时间来调整UI。开发们也能够做測试，由于产品是他们开发的，有什么bug他们第一时间知道，可是开发们也非常忙，他们在忙着实现各种复杂的功能模块，忙得焦头烂额。他们都腾不出时间做这事儿，于是就须要交给专门的測试来进行了。而測试既不是产品的规划者。也不是产品的设计者，更不是产品的开发人员，能够说測试对产品全然就是局外人（恰恰相反。測试是对产品最了解的人。产品有哪些功能，哪些bug，怎样高效的操作，怎样解决某些问题这些都是測试最了解的，甚至測试能够扮演一个超级客服的角色，这些我都到“測试人员的自我修养”中来解释）。那么測初步要測试该产品就仅仅能建立在对需求。设计。交互等方面入手了。于是測试须要向产品，设计要相关的文档 。熟悉产品的各个模块。

        可是即使測试熟悉了，一旦产品开发出来，測试拿到參评就開始使用找bug吗，我想即使測试熟悉了产品。在測试的过程中肯定对产品的功能有所遗忘，即使是熟悉过文档，由于一款产品的功能模块实在太多。假设測试仅仅是凭着对需求文档的熟悉度。就開始乱点，没有计划没有目标開始測试，到头来自己做过哪些操作都忘记了，更别谈測试效率。能把測试工作做好了。所以在产品的规划设计阶段，測试就 已经開始參与到产品中来，開始熟悉产品，收集各种文档整理成一些操作步骤，这样就形成了測试用例，于是用例的生命周期就開始了。

所以用例的第一个作用就是，把产品需求转换为一种可操作的步骤，方便以后有步骤有计划的进行測试。

而在这种转换过程中。由于这种非常强操作的逻辑在进行，往往測试能发现产品中设计的bug，由于在设计用例的过程中，实际上是在脑海中模拟使用产品；所以。在写用例的过程实际上就是对产需求进行測试的一个过程。所以写用例的第二个作用就是验证产品的需求是否合理。

假设发现产品需求不合理，或需求有矛盾的地方，甚至不明白的地方。这时候我们的用例进行不下去了。由于我们写的前一个步骤可能有多个结果，那么产品要的是那个结果呢，或者那几个结果呢。

于是我们须要找产品确认。产品一看，这确实须要优化，或须要考虑或者须要想出更好的方案。所以这里又体现了測试用例的第三个作用：监督产品对需求做出更加具体的设计。而当产品想出好的方案之后，给了測试回复。于是測试把他写进測试文档。这有体现了測试用例的第四个作用：记录产品的设计细节，保障以后的查阅。而測试有了这样一个与产品沟通的过程。对该模块有了更深的印象，这里体香了測试用例的第五个作用：加深測试人员对产品的认识和印象。

当产品开发出来了，測试这边的准备也差点儿相同了。于是測试人员開始依照測试用例的描写叙述測试，每过完一个用例标记完毕；这样測试也知道自己做过哪些操作。避免没有目的随机測试，而且通过測试用例的运行条数，大致了解该模块的測试进度，这又体现了測试用例的第六个作用：反应測试进度。

而測试人员在运行用例的过程中往往会突然发现当初设计的用例步骤中，还能够做这样一个操作，于是发现了bug，这又体现了測试用例的第七个作用：帮助发现拓展測试范围。扩大測试覆盖面，发现软件中潜藏的缺陷。

        好了到这个时候，測试用例已经成长为一个青壮年啦。软件測试的过程中，我们依照測试用例描写叙述的运行。大致能确定測试的进度。

在測试的过程中，我们会发现bug，而这个bug或许没有在測试用例里面有步骤描写叙述。但考虑到他或许会在以后的版本号中复现。于是我们把它的步骤整理出来。形成一个新的用例。以放便測试他是否会在以后的版本号中出现，这里又体现了測试用例的另外一个作用：方便回归測试，复查bug是否还会出现。

        软件版本号上线后，因为用户的各种使用习惯，以及各式各样的使用场景，以及各式各样的终端环境。会出现一些測试过程中没有发现的bug，大致这种bug对产品的影响比較小。但也是产品的优化点。

在第一个版本号公布之后。因为用户的使用反馈。以及产品对用户操作行为的统计，产品有了更好的方案。或是产品要尝试新的东西，于是需求開始变动。

需求的变动导致測试用例部分失效，于是測试须要更新測试用例。删除无效用例。

这体现了測试用例的一个缺陷：添加了測试的维护成本。

有时候因为产品上线的时间比較紧，写用例会花掉非常多时间，而相对的给測试的时间就少了，这有体现了測试用例的另外一个缺陷：消耗了时间成本。往往在这种情况下。为了避免測试时间不够用，我们会花非常短的时间列出重要的測试点開始測试。为了避免漏測，我们会參考曾经相关模块的測试用例进行。这体现了測试用例的又一个长处：为紧急情况下的測试提供參考信息。

        好了说道这里，继续。

产品測试的过程中总会少不了人员的变动问题。

而新人进来大多不熟悉产品。而让他们依据曾经的需求測试，肯定会漏測。

由于产品在上线过程中已经经历了需求变化，并且也发现了非常多潜在的问题，新人肯定是不能从产品需求以及产品中看到这些。所以他们须要測试用例来辅助測试，了解曾经出现的潜在的问题，更加熟悉的了解产品以及他的測试；这里再添加一条測试用例的作用：培训新人。节省对新人的指导时间。为什么说这节省了对新人的指导时间呢，由于新人看到产品往往会有非常多不理解的地方。所以他们回常常去问“前辈们”。而假设前辈们安排她们运行维护好的測试用例，那么非常多问题就在运行測试用例过程中就攻克了，所以问的问题就会降低。就节约了对他们的指导时间。

        而我们看看如今的手机外包測试。

        我们知道手机的有些功能在好多年以内一般不会变化，特别是同一系列的手机。比方短信、通话、蓝牙、手机记事本、收音机、录音机等等。而測试这些手机功能的人也不是固定不变的，由于人员的流动性，一旦人员流走，那么就非常少有人熟悉这些功能的測试；他会出哪些问题，哪些行为是多余的功能。哪些功能不对这些都须要熟悉的人才干运行測试。公司非常聪明，在长期的经营其中他知道会发生这种事情，于是他们把手机easy出现故障的地方，或曾经就有问题的地方，或是刚開始设计的一些信息都整理成一个个能够操作的文档，记录下来。这就形成了我们看到的測试用例。那么新来的员工就有了測试的根据，他们往往会被分到一些測试用例去运行。一方面的原因是測试产品是都符合文档的描写叙述，还有一方面让新来的员工熟悉产品。以及产品測试的大致步骤。

        因此測试用例的目的对新人来说，提高了新人的測试效率，而且起到培训新人的作用。

        假如一款产品停止维护了，那么全部的測试用例随之失效，到此測试用例的生命周期结束。

而新起一款产品，新的生命周期又開始了。所以，測试用例伴随着整个产品的生命周期。

        文章写道这里，我们来总结一下測试用例的长处与缺点：

长处：

1、               把产品需求转换为一种可操作的步骤，方便以后有步骤有计划的进行測试。

2、               验证产品的需求是否合理

3、               监督产品对需求做出更加具体的设计

4、               记录产品的设计细节，保障以后的查阅

5、               加深測试人员对产品的认识和印象

6、               反应測试进度

7、               帮助发现拓展測试范围。扩大測试覆盖面，发现软件中潜藏的缺陷

8、               方便回归測试，复查bug是否还会出现

9、               为紧急情况下的測试提供參考信息

10、           培训新人，提高新人測试效率，节省对新人的指导时间

缺点：

1、 添加了測试的维护成本

2、 消耗了时间成本

 

完，假设我们有一个更好的视野，更多交流。

版权声明：本文博主原创文章，博客，未经同意，不得转载。