软件测试-7

2019-05-28

软件测试

字数统计: 3.7k | 阅读时长≈ 12 分钟

测试用例的设计

什么是测试用例呢？测试用例对测试工作会起到怎样的作用呢？测试用例与需求文档之间存在什么样的关系呢？

测试用例的格式

在前面的内容里已经为矿泉水瓶设计了33个测试点，然后依据这些测试点来测试矿泉水瓶。其实在软件测试领域，这个测试点指的就是测试用例。接下来一起来看看如何把一个测试点一步步演变成测试用例，下面举例说明

如果现在要对这个登录模块进行功能测试，那应如何测试呢？以下4个测试点是某同学在没有任何测试经验的情况下想出来的。

（1）输入正确的用户名和错误的密码测试能否登录成功。

（2）输入错误的用户名和错误的密码测试能否登录成功。

（3）用户名和密码都不输入的情况下测试能否登录成功。

（4）输入正确的用户名和正确的密码测试能否登录成功。

针对以上4个测试点，从中任选一个测试点来分析一下，例如直接选择第一个测试点：输入正确的用户名和错误的密码测试能否登录成功。单从字面上看，这个测试点似乎写得很清楚，输入正确的用户名，然后再输入错误的密码，之后看能不能登录邮箱。事实真的如此简单吗？

第一个问题，“输入正确的用户名和错误的密码测试能否登录成功”，这个测试点是针对邮箱的哪个模块进行测试的呢？在测试点中没有明确说明。

第二个问题，测试时如果网络不通畅，是无法进行这个登录测试的，所以测试前提条件就是要保证网络通畅，这一点也没有在测试点中说明。

第三个问题，邮箱登录功能是在什么环境下测试的呢？是在Mac操作系统上还是在Windows 10操作系统上测试的，用的是Safari浏览器还是Chrome浏览器，具体的测试环境在测试点中没有说明。

第四个问题，在输入用户名和密码前，测试人员是通过什么网址打开登录页面的，这一点在测试点中也没有说明。

第五个问题，输入正确的用户名和错误的密码，那么这个正确的用户名和错误的密码具体的测试数据是什么呢？这个在测试点中也没有明确出来。

第六个问题，“输入正确的用户名和错误的密码测试能否登录成功”，对测试人员而言是期望它登录成功还是登录失败呢？这在测试点中也没有明确写清楚。

对于以上几点，有人会说，我当然清楚这里面相关的测试数据和判断。可如果软件的测试点多达成百上千个时，你真能记得住这些测试点的每个测试步骤和测试数据吗？所以测试人员在最初设计测试点时，一定要把测试所针对的模块、测试的前提条件、测试所用到的环境、测试的具体步骤、测试步骤中所用到的具体测试数据以及测试人员想到得到一个什么样的预期结果等这些关键元素写清楚，以便在后期执行测试用例时能够顺利进行。结合以上几点，便可对“输入正确的用户名和错误的密码测试能否登录成功”这个测试点进行完善，具体内容如下。

此测试点针对的是某邮箱的登录模块，测试之前，确保网络是通畅的。首先在Windows 10操作系统中打开IE11浏览器，并在浏览器网址中输入该邮箱登录页面的网址http://mail.***.com，然后打开邮箱的登录页面，接着在用户名输入框中输入一个正确的用户名“test123”，在密码输入框中输入一个错误的密码“123456”，单击登录按钮，查看是否登录成功。测试人员期望的结果：邮箱登录不成功，并提示用户名和密码错误。

这样编写测试点后，就细致了很多，因为测试的关键元素都被写出来了。依据这个测试点的描述，即使不是测试人员，也能顺利执行。但这里有一个问题，如果每个测试点都写成一段话，那么登录模块的所有测试点会像是一篇文章，写的时候费力，读的时候也费时，无形地增加工作量。为了增强测试点的可写性和可读性，可以把一个测试点所必须包含的内容划分成9个基本元素，并通过表格的形式将它们展示出来

（1）从上表可以看到，这9个基本元素分别是测试序号、测试模块、前置条件、测试环境、操作步骤和数据、预期结果、实际结果、是否通过、备注。而原先测试点中的内容也被相应地分割，并把分割后的内容放置在了相对应的元素下面，这就构成了一个标准的测试用例。

（2）测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便核实是否满足某个特定需求。测试用例是测试的一个例子，而这个例子包括测试序号、测试模块、前置条件、测试环境、操作步骤和数据、预期结果、实际结果、是否通过、备注这9个关键的基本元素。每个公司的规范可能不一样，有的还包括测试时间、测试人员、软件的版本名称、优先级等一些附加元素。

（3）接下来再把前面所写的第二个测试点“输入错误的用户名和错误的密码测试能否登录成功”也转化为表格形式的测试用例。

（4）从表2可以看到第二个测试点也已转化为表格形式，转化的过程其实很容易，就是把测试用例的内容依次填写到相应的表格中。通过以上的表格形式来编写测试用例，测试用例中各个元素信息一目了然，使得用例的编写、阅读和执行更加容易。

（5）其中“操作步骤和数据”是测试用例中最关键的地方，结合表2中的第二个测试用例，观察一下操作步骤和数据的演变过程。如下图：

通过图中3个测试步骤的对比，最后一个操作步骤和数据是最详细的，不仅加入了如何打开邮箱登录页面的步骤，还加入了用户名和密码的详细信息。那么对于初级软件测试人员而言，测试步骤和数据一般要细致到什么程度呢？在实际的工作中，对初级软件测试人员曾有这么一个标准，即如果你写出来的测试步骤和数据能够让一个从未接触过测试工作的普通人也能顺利执行的话，那么说明这个测试步骤和数据就写得很详细了。待有一定的工作经验后，测试用例的操作步骤可以适当简化，但简化之后也要清晰明了，具体的测试数据也是不能少的。

（6）“预期结果”是测试用例中的第二个关键元素，结合表6-2中的第二个测试用例，也来观察下预期结果的演变过程。

通过图3中3个预期结果的对比，最后一个预期结果是最全面的。其实核心的预期结果只有一个：邮箱登录不成功，并提示用户名和密码错误。但严格来讲，每个测试步骤都应该有一个预期结果。例如在第二个测试用例中，操作步骤和数据中一共有3个步骤，那么预期结果也应该有3个，对于初级软件测试人员来说，应当尽可能地把每个操作步骤所对应的预期结果写完整。当然，写出操作步骤，就很好写预期结果了，除非测试人员不熟悉测试系统或需求文档。

接下来，再把前面所写的第三个测试点“用户名和密码都不输入的情况下测试能否登录成功”和第四个测试点“输入正确的用户名和正确的密码测试能否登录成功”都转化为表格形式的测试用例。

（7）对于测试用例的“实际结果”这一元素，在实际测试软件时才能填写。例如针对测试点“输入正确的用户名和错误的密码测试能否登录成功”，如果执行测试用例的时候发现邮箱是登录失败的，那么该测试用例的实际测试结果就是“登录失败”。

（8）对于测试用例的“是否通过”这一元素，它指的是如果实际结果与预期结果相符，则表明此测试用例通过；如果实际结果与预期结果不相符，则表明此测试用例不通过，说明程序的处理是有问题的，需要测试人员提交Bug单给开发人员进行修改。

（9）对于测试用例的“备注”这一元素，指的是对本测试用例额外补充的一些说明，如无特殊情况，这个选项一般可以不填。

至此，已介绍完测试点演变成测试用例的整个过程了。通俗来讲，测试点就是一个测试用例的中心思想，或者说测试点就是设计测试用例的大纲；而测试用例是在测试点的基础上进一步细化了其中的内容。在实际的工作中，测试人员可采用Excel表格或者是Word文档来编写测试用例，也可以使用相应的测试管理工具编写。

测试用例的作用

开发人员在拿到通过评审的需求文档后，就会按照需求文档进行概要设计和详细设计的工作，然后再进入编码阶段，在开发人员进行软件开发的这段时间里，测试人员会设计出各模块的测试用例。待开发人员开发完成软件之后，测试人员就可以依据之前设计好的测试用例测试软件是否有问题，而不是等开发软件完成后，测试人员再去设计测试用例。

测试用例是测试人员具体执行测试的依据，它是非常关键的文档，它作为测试的标准并指导测试人员进行测试工作。测试人员会按照测试用例中的操作步骤和具体数据逐一执行测试用例，发现问题并提交Bug单，最终完善软件的质量。

测试用例与需求的关系

在前面的内容里，设计矿泉水瓶测试点时，放置了矿泉水瓶这个明显的参照物在测试人员面前，所以测试点设计起来就比较容易。但测试人员在设计软件测试用例时，这个软件并没有完成开发，没有明显的参照物可以给到测试人员，那此时测试人员是依据什么来设计测试用例的呢？其实测试人员是依据需求文档来进行测试用例的设计的。

需求文档包含了软件的所有需求规格，包括功能需求和非功能需求（例如性能安全方面的需求）等，其信息量很大，可能大部分的需求内容是初级软件测试人员暂时不涉及的，过早的展示会影响测试人员的学习理解。而初级软件测试人员需要关注的是需求文档里每个功能模块的需求，因为初级软件测试人员主要做的是功能测试。接下来，就选取某需求文档中的一个片段，该片段描述的是某网站登录模块的功能需求说明。

（1）功能描述：对用户进行身份验证，只有输入了正确的用户名和密码的用户才能成功登录到网站首页；当输入错误的用户名或密码时，则无法登录到网站首页，并会给出相应的提示信息。

（2）该网站登录原型界面如图