测试用例模板如何写出好的测试用例

如何编写出漂亮的测试用例

测试用例是测试设计的一个产出物，它直接体现测试设计的思想，一份漂亮的测试用例不仅仅是设计思路的优，更是便于流转和执行，具有可读性、传递性。

首先，一份漂亮的测试用例-需有一个用例模板 模板的作用：将测试用例的结构形式固定化、标准化，对编写者启引导作用，保证一份测试用例数据完整。

两份模板差别在于 机顶盒1和机顶盒2，因在IPTV行业，是通过机顶盒展示给用户的，而当前机顶盒厂商多，需要进行兼容性测试，将需要测试的机顶盒直接标记在用例中，执行哪款盒子，就直接在哪款盒子上写结果即可。

同一个功能在多个机顶盒上是否OK 一目了然。

哪款盒子测试用例通过率/失败率也非常清晰。

如你测试的是网站可将机顶盒改成 IE11 Chrome 等。

其次，测试用例具有目标、可读、简洁。

测试用例的目标、可读、简洁是从各个属性所填的内容散发出来的。

1、用例编号 用例编号就是测试用例文档中一个代号，需全局唯一，我们可以通过代号快速找到测试用例。

用例编号的书写，建议是项目名_模块名_001，我们可以通过编号快速知道一个项目有多少用例，项目中一个模块有多少用例。

2、用例标题 目的:概述测试用例的主要内容，明确用例意图 在做用例评审时，通过浏览一个模块的用例标题，能快速判断有没有遗漏功能；通过浏览一个功能用例标题，能快速判断出有没有遗漏正常或异常case。

一个测试用例的好坏，一半体现在测试用例标题上。

一个好用例的标题，书写方式有三种： 一：一句完整的话（不超过30个汉字） 二：功能简报形式 例：电影详情页-返回 例：栏目-发布 例：电影-添加 三：按条件/状态 例：发起转码-无源媒体文件 例：发起转码-有源媒体文件 例：鉴权-已订购产品已过期 例：鉴权-已订购产品未过期 例：鉴权-未订购产品 3、预置条件 预置条件-测试用例能执行的前提条件。

可以是到达某一状态，也可以是一些配置。

书写要求：一个简洁的结果。

用户已成功登陆 自动审核的开关已关 不需要写是怎么登陆的/如何将开关关掉的。

这个测试用例怎么写

比较好的软件测试人员也只能写出一半的测试用例吧,这个应该可以写40多个吧，我先写写试试(大概思想就是两边之和大于第三边，两边之差小于第三边，输入含一个字母，两个字母，三个字母，一个负数，两个负数，三个负数) 1、 1 3 5 2、 1 5 3 3、 5 1 3 4、 0 1 2 5、 1 0 2 6、 2 1 0 7、 a 0 1 8、 0 a 1 9、 1 0 a 10、-1 2 6 11、1 -1 5 12、5 3 -1 13、a b 0 14、a 0 b 15、0 a b 16、a b c 17、-1 -1 2 18、-1 2 -1 19、2 -1 -1 20、-1 -1 -1 先写一部分，写的肯定不全，你再好好想想吧

软件测试用例实例

自动取款机取款用例规约和测试用例 取款用例说明： 此用例完成用户利用自动取款机取款的全部流程，分为以下流程：插卡，输入密码，选择金额，取款，取卡等操作。

事件流： 该用例在用户插卡之后启动 1. 系统提示用户插卡； 2. 提示客户输入密码信息； 3. 密码输入完毕后，客户选择“确认”，向系统提交信息； 4. 系统验证客户输入的密码信息，确认正确后，进入选择系统主界面； 5. 用户选择取款选项； 6. 系统进入取款金额界面并提示用户输入金额； 7. 系统验证可以取款并输出钱款； 8. 系统提示用户取卡，操作完成。

基本流： 用户取款。

备选流： 1.用户密码错误 2.取款金额不符合要求。

前置条件： 用户必须插入正确的银行卡才能开始执行用例。

后置条件： 如果系统确认用户信息正确，成功登陆，则系统启动主界面，等待用户发送消息，进行查询和取款等操作。

事件流 系统 用户 1 系统提示用户插卡 插入银行卡 2 提示客户输入密码信息 输入密码 3 如果密码错误，提示密码不正确，并返回到2 4 如果密码正确，转入主界面 5 提示用户选择选项 选择取款选项 6 系统进入取款金额界面并提示用户输入金额 输入取款金额 7 如果金额符合则输入钱款 8 如果金额小于余额则提示取款失败并返回7 9 如果金额不是整百则提示不符合规范，取款失败并返回7。

10 提示用户取款 取出钱款 11 提示用户取卡 取出银行卡 测试用例： 事件 用户操作 覆盖等价类 系统反应 1 插入正确银行卡 功能测试 提示输入密码 2 密码正确 功能测试 进入主界面，提示用户选择 3 密码不正确 功能测试 提示密码错误 重新输入 4 输入金额<余额 功能检查 提示用户金额不足，重新输入或取卡 5 输入金额为150 功能检查 提示用户取款金额不符和规范，重新输入或退出 6 输入正确金额 功能检查 输出钱款 7 用户未按时取款 错误处理 自动收回钱款 8 用户未按时取卡 错误处理 自动吞卡 9 用户按时取卡 功能测试 返回到主页面

测试用例的设计

（一）白盒技术 白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。

⒈逻辑覆盖 程序内部的逻辑覆盖程度，当程序中有循环时，覆盖每条路径是不可能的，要设计使覆盖程度较高的或覆盖最有代表性的路径的测试用例。

下面根据图7-1所示的程序，分别讨论几种常用的覆盖技术。

⑴语句覆盖。

为了提高发现错误的可能性，在测试时应该执行到程序中的每一个语句。

语句覆盖是指设计足够的测试用例，使被测试程序中每个语句至少执行一次。

如图7-1是一个被测试程序流程图： ⑵判定覆盖。

判定覆盖指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，从而使程序的每一个分支至少都通过一次，因此判定覆盖也称分支覆盖。

⑶条件覆盖。

条件覆盖是指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。

⑷判定条件覆盖。

该覆盖标准指设计足够的测试用例，使得判定表达式的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。

⑸条件组合覆盖。

条件组合覆盖是比较强的覆盖标准，它是指设计足够的测试用例，使得每个判定表达式中条件的各种可能的值的组合都至少出现一次。

⑹路径覆盖。

路径覆盖是指设计足够的测试用例，覆盖被测程序中所有可能的路径。

在实际的逻辑覆盖测试中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标准。

⒉循环覆盖 ⒊基本路径测试 （二）黑盒技术 ⒈等价类划分 ⑴划分等价类。

①在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

③在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

④在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

⑵确定测试用例。

①为每一个等价类编号。

②设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。

重复这步，直到所有合理等价类被测试用例覆盖。

③设计一个测试用例，使其只覆盖一个不合理等价类。

⒉边界值分析 使用边界值分析方法设计测试用例时一般与等价类划分结合起来。

但它不是从一个等价类中任选一个例子作为代表，而是将测试边界情况作为重点目标，选取正好等于、刚刚大于或刚刚小于边界值的测试数据。

⑴如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择刚好越过边界值的数据作为不合理的测试用例。

如输入值的范围是[1，100]，可取0，1，100，101等值作为测试数据。

⑵如果输入条件指出了输入数据的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1等情况分别设计测试用例。

如，一个输入文件可包括1--255个记录，则分别设计有1个记录、255个记录，以及0个记录的输入文件的测试用例。

⑶对每个输出条件分别按照以上原则⑴或⑵确定输出值的边界情况。

如，一个学生成绩管理系统规定，只能查询95--98级大学生的各科成绩，可以设计测试用例，使得查询范围内的某一届或四届学生的学生成绩，还需设计查询94级、99级学生成绩的测试用例（不合理输出等价类）。

由于输出值的边界不与输入值的边界相对应，所以要检查输出值的边界不一定可能，要产生超出输出值之外的结果也不一定能做到，但必要时还需试一试。

⑷如果程序的规格说明给出的输入或输出域是个有序集合（如顺序文件、线形表、链表等），则应选取集合的第一个元素和最后一个元素作为测试用例。

⒊错误推测 在测试程序时，人们可能根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例，这就是错误推测法。

⒋因果图 等价类划分和边界值方法分析方法都只是孤立地考虑各个输入数据的测试功能，而没有考虑多个输入数据的组合引起的错误。

⒌综合策略 每种方法都能设计出一组有用例子，用这组例子容易发现某种类型的错误，但可能不易发现另一类型的错误。

因此在实际测试中，联合使用各种测试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充一些必要的测试用例。

·能发现到目前为止没有发现的缺陷的用例是好的用例。

首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。

我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&AMp;V”的活动，测试需要保证以下两点： 程序做了它应该做的事情 程序没有做它不该做的事情 因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

·测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试。

不知道国内有没有公司真正做到这点，或者说，不知道国内有没有公司能够将每个测试用例都写得如此详细。

在我的测试经历中，对测试用例描述的详细和复杂程度 也曾有过很多的彷徨。

写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实 现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。

但我偏偏就能遇到 一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

在讨论这个问题之前，我们可以先考虑一下测试的目的。

测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个ProjECt，也需要在 给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目 标，一切围绕测试的目标进行。

除了资源上的约束外，测试用例的详细程度也需要根据需要确定。

如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。

在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

·测试用例设计是一劳永逸的事情。

这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。

我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例 却没有任何修改。

导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰 后，对测试人员不屑一顾。

这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中却是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

·测试用例不应该包含实际的数据。

测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行 性。

当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software TeST》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

·测试用例中不需要明显的验证手段。

我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。

例如，对一个订货系统， 输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？ 显然不是。

订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

用于功能性测试的测试用例来源于测试目标的用例。

应该为每个用例场景编制测试用例。

用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。

基本流用直黑线来表示，是经过用例的最简单的路径。

每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。

备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。

用例的事件流示例 遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。

从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景： 场景 1 基本流 场景 2 基本流 备选流 1 场景 3 基本流 备选流 1 备选流 2 场景 4 基本流 备选流 3 场景 5 基本流 备选流 3 备选流 1 场景 6 基本流 备选流 3 备选流 1 备选流 2 场景 7 基本流 备选流 4 场景 8 基本流 备选流 3 备选流 4 注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。

例如，假定上图描述的用例对备选流 3 规定如下： “如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。

系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2‘输入提款金额’，此时银行客户可以输入新的提款金额。

” 据此，可以开始确定需要用来执行备选流 3 的测试用例： 测试用例ID 场景 条件 预期结果 TC x 场景 4 步骤 2 - 提款金额 > 帐户余额 在步骤 2 处重新加入基本流 TC y 场景 4 步骤 2 - 提款金额 < 帐户余额 不执行备选流 3，执行基本流 TC z 场景 4 步骤 2 - 提款金额 = 帐户余额 不执行备选流 3，执行基本流 注：由于没有提供其他信息，以上显示的测试用例都非常简单。

测试用例很少如此简单。

下面是一个由用例生成测试用例的更符合实际情况的示例。

示例： 一台 ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流： 本用例的开端是 ATM 处于准备就绪状态。

准备提款 - 客户将银行卡插入 ATM 机的读卡机。

验证银行卡 - ATM 机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。

输入 PIN - ATM 要求客户输入 PIN 码（4 位） 验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN 对该帐户来说是否正确。

对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。

ATM 选项 - ATM 显示在本机上可用的各种选项。

在此事件流中，银行客户通常选择“提款”。

输入金额 - 要从 ATM 中提取的金额。

对于此事件流，客户需选择预设的金额（10 美元、20 美元、50 美元或 100 美元）。

授权 - ATM 通过将卡 ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。

对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。

出钞 - 提供现金。

返回银行卡 - 银行卡被返还。

收据 - 打印收据并提供给客户。

ATM 还相应地更新内部记录。

用例结束时 ATM 又回到准备就绪状态。

备选流 1 - 银行卡无效 在基本流步骤 2 中 - 验证银行卡，如果卡是无效的，则卡被退回，同时会通知相关消息。

备选流 2 - ATM 内没有现金 在基本流步骤 5 中 - ATM 选项，如果 ATM 内没有现金，则“提款”选项将无法使用。

备选流 3 - ATM 内现金不足 在基本流步骤 6 中- 输入金额，如果 ATM 机内金额少于请求提取的金额，则将显示一则适当的消息，并且在步骤 6 - 输入金额处重新加入基本流。

备选流 4 - PIN 有误 在基本流步骤 4 中- 验证帐户和 PIN，客户有三次机会输入 PIN。

如果 PIN 输入有误，ATM 将显示适当的消息；如果还存在输入机会，则此事件流在步骤 3 - 输入 PIN 处重新加入基本流。

如果最后一次尝试输入的 PIN 码仍然错误，则该卡将被 ATM 机保留，同时 ATM 返回到准备就绪状态，本用例终止。

备选流 5 - 帐户不存在 在基本流步骤 4 中 - 验证帐户和 PIN，如果银行系统返回的代码表明找不到该帐户或禁止从该帐户中提款，则 ATM 显示适当的消息并且在步骤 9 - 返回银行卡处重新加入基本流。

备选流 6 - 帐面金额不足 在基本流步骤 7 - 授权中，银行系统返回代码表明帐户余额少于在基本流步骤 6 - 输入金额内输入的金额，则 ATM 显示适当的消息并且在步骤 6 - 输入金额处重新加入基本流。

备选流 7 - 达到每日最大的提款金额 在基本流步骤 7 - 授权中，银行系统返回的代码表明包括本提款请求在内，客户已经或将超过在 24 小时内允许提取的最多金额，则 ATM 显示适当的消息并在步骤 6 - 输入金额上重新加入基本流。

备选流 x - 记录错误 如果在基本流步骤 10 - 收据中，记录无法更新，则 ATM 进入“安全模式”，在此模式下所有功能都将暂停使用。

同时向银行系统发送一条适当的警报信息表明 ATM 已经暂停工作。

备选流 y - 退出 客户可随时决定终止交易（退出）。

交易终止，银行卡随之退出。

备选流 z - “翘起” ATM 包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。

在任一时刻，如果某客户做出暴力举动，便启用适当的措施。

如何写出好的测试用例

一个好的测试用例是每个人都能执行的测试用例，不管你是否是测试人员，不管你是否了解整个软件的工作流程，你都能顺利的执行完测试用例，并对这个测试用例覆盖到的功能点有了大概的了解。

好的测试用例的设计相当了软件开发中的详细概要设计，要写出好的测试用例首先要对所测试的软件很熟悉，熟悉软件的每个功能点和系统的整个业务流程。

其次，对整个测试用例有个好的规划，理清主线，功能点的在哪个地方被覆盖都是需要考虑的。

最后，需要良好的心态，写测试用例是个繁琐的过程，测试用例不是随随便便就能写出来的，好的测试用例更需要你在写的过程中不断去理清思路，并把每个功能点都恰当的写进去。

测试用例的规划： 用例的规划非常的重要，它决定整个测试用例的思路、风格、覆盖率。

即对整个测试用例的成败都有直接的响。

对测试用例的规划我个人总结出两条思路：一条是用例的线性规划，另一条是功能点覆盖型。

这两条思路的侧重点各不相同，各有优缺点。

线性的测试用例的要点是在理清每一条思路，即以业务线和流程线为主，每一条线都是一个流程，然后把功能点穿插到每条线里去。

把每条业务流程比作竖线，功能线比作横线，那么功能点就是横线和竖线的节点，这样整个用例就是一张大网，我们可以随时向网中添加横线或竖线，使得覆盖率不断增加，“漏网之鱼”越来越小。

另一种思路是功能点覆盖型。

在设计之前把要整套软件的功能点理清楚，这当然是非常的难的。

但我们可以参考系统设计的功能流程图，软件的需求来进行分析和提取。

还有一点就是测试人员的经验来完善所需要的功能点。

这种思路的重点是把每个功能点都要在设计中体现出来，以功能点覆盖为主，不管工作的业务流程。

也就是说是按照各个功能模块进行划分的，分模块进行用例的设计。

两种思路相辅相承，各有各的优点。

在实际的执行过程中，有时以业务流程来编写比较容易，有时以功能模块编写比较容易。

一个是以线为主，一个是以块为主。

测试用例的设计： 规划好测试用例的整体思路之后，就是测试用例的具体设计设计了。

用例的设计的格式主要由测试环境，准备数据，前置条件，用例ID，预期输入值，期望输出结果，测试执行结果和优先级等几个部分组成。

其余的还有一些统计页，打印输出的模板等。

个人认为用excel设计比较简便，excel可以有多个页面，一个页面为统计测试结果和用例维护，一个为测试用例的主页面，还有一个页面可以放一些打印后的模板。

这样的设计有利于用例的维护。

用例的预期输入值和操作步骤是用例设计最重要的部分。

设计好这两个部分对经后测试用例的执行至关重要，特别是操作步骤的描述，要描述清楚每一步的操作步骤，这样才能让测试的执行者准确操作，不会产生歧义。

用例所写的每一句话都应该清晰的，没有歧义的，否则就会出现用例维护时，其他测试人员看不懂你写的是什么，测试用例执行的时候，看着很费力，达不到文中刚开始的要求。

测试用例的维护： 每个测试用例都要在经后执行的过程中去维护修改，使得测试用例的覆盖率不断提高。

特别的测试用例的第一个版本时，需要维护的量是非常大的。

我们可以边测试边修改测试用例，也可以根据需求添加测试用例。

每维护一次测试用例，就必修记录下你修改的内容，以便于经后的阅读和别人的维护。

以上是我近期对于测试用例设计的理解，也是我近期工作的一个总结和体会，测试用例设计是一门高深的技术，也是软件测试的重要组成部分，我们需要经验来不断提升用例的质量，设计出好的测试用例。