测试用例（Test Case）设计是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

1. 测试流程简述

　　测试流程如下图所示，使用黑色斜体标注的阶段为业务测试人员需要参与的阶段。了解整体的开发测试流程，我们可以更清楚地了解测试用例设计的方法。 

　　2. 测试用例设计方法

　　2.1 测试需求评审

　　需求评审阶段由产品人员主导，开发、测试、设计人员共同参与，测试人员在本阶段的任务是评审新需求的可测点，及时抛出具有风险的测试点，确定测试周期。

　　2.1.1 测试需求分析

　　进行测试需求分析时，可分为两种实际情况：

• 在开发能够实时的完善的维护软件需求文档的前提条可以先看软件需求文档，了解软件待测软件（模块）的待测需求（包含软件需求，具有可测性）。

• 如果待测软件的改动较为频繁，单位时间内版本发布数量大，开发实时维护软件需求文档时，就需要找开发实时确认最新版本的详细需求及流程，确认可测的软件需求，了解其详细的流程和功能点。

　　在确认测试需求后，可以对其在软件需求的基础上进行归纳、分类，以便于测试用例设计。

　　2.1.2 业务流程分析                                           

　　指针对软件的内部处理流程逻辑进行测试。

　　在测试需求分析完后最好能够通过画出对应的流程图来了解软件测业务流程，能更全面的覆盖所有测试点。

　　为了确保流程图的正确性，需要和开发确认是否存在流程错误或者有缺失的情况。如果软件设计文档中已有对应的流程图，就要根据测试需要对流程进行补充，需要测试未画出来的需要添加，不需要测试的部分可以简化，需要重点测试的部分可以细化。

　　通过流程图，了解：软件的主流程是什么；关键的判断条件是什么；数据流向是什么等；条件备选流程是什么等。

　　2.2 测试用例设计

　　测试用例的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界，异常的情况，以便发现更多的隐藏问题。性能和压力问题视软件的实际使用情况而定。

　　另外一个补充就是：在进行测试用例编写的时候，开发往往会给出一些建议，这些建议都是从实践中总结出来的有着血的教训，所以要格外关注此类问题上避免犯同样的错误。

　　测试用例设计方法包括等价类划分法、边界值分析法、错误推断法、因果图法、判定表驱动法、正交试验设计法、功能图法、流程图法等等。

等价类划分法:

  等价类划分是把程序的输入域划分为若干部分（子集），然后从每个部分中选出少数具有代表性作为测试用例，每一类的代表性数据在测试中的作用等价于这一类中的其他值。等价类主要能缩小设计用例的范围，并能覆盖所以输入域。

　　等价类分为两大类：有效等价类与无效等价类。

　　例如：

　　设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的“日期检查功能”。

　　1.划分等价类并编号，下表等价类划分的结果：

　　2.设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：

　　3.为每一个无效等价类设计一个测试用例，设计结果如下：

　　边界值分析法:

　　边界值分析法是对输入域或者输出域边界值进行测试的一种方式，通常情况下边界值作为等价类划分的一种补充出现。

• 根据大量的测试数据统计，很多错误是发生在输入或者输出范围的边界值上，而不是输入输出域中，因此针对各种边界值情况设计测试用例，可以查出更多的错误。

• 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

　　错误推断法:

　　基于经验和直觉推出程序中可能存在的各种风险或错误，从而有针对的设计测试用例的方法。

　　因果图法:

　　利用图解分析输入的各种组合条件，从而设计测试用例的方法，它适合于程序中的输入条件的各种组合情况。

　　判定表驱动法(很少用)：

　　判定表是分析和表达逻辑条件下执行不同操作的情况的工具。

　　正交试验法(很少用)：

　　正交试验法是从大量的用例中挑选出适量的，有代表性的用例，从而合理的安排测试的一种科学设计方法。

　　功能图法：

　　功能图法是由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来描述，一个状态指出数据输入的位置或时间，而迁移则指明状态的改变，同时要依靠判定表或因果图表示的逻辑和功能。

　　场景法:

　　按照控制流程的设计。事情出发时的情景形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

　　在不同场景中使用不同的测试用例设计方法，可混用。

　　PS: 一些常遇到的场景用例设计思考分析：

• 碰到存在下载的情况，就需要考虑：下载正确，异常下载情况，断点续传，小运营商缓存的情况的处理，使用不存在的服务器，文件下载完成后是否会校验下载文件的正确性。

• 碰到存在帐号登录的情况，就要考虑：正确帐号密码，错误帐号密码，异常帐号，帐号输入异常字符，帐号长度过长过短，反复登录等情况。

• 碰到存在文件修复或替换的情况，就要考虑：文件出错如何修复，其本身出错如何处理，需修复文件路径较深的情况下是否修复，修复时文件被占用如何处理等。

• 碰到对话框输入的情况，就要考虑：容易出错的字符集，比如 web 特别敏感的一些字符 <\script>等web页面常用到的一些语法关键字等。

　　2.3 测试用例评审

　　测试用例设计完成以后，为了确认测试过程和方法是否正确，是否存在被遗漏的测试点，则需要进行测试用例的评审。这个过程属于最后的完善阶段，个人思维上的盲点，和对产品了解不足的地方都可以在此时被发现，也是一个完善自我的好机会。

　　2.4 测试用例更新完善

　　测试用例编写完成之后需要不断的完善，软件产品新增功能或更新需求后，测试用例最好能够配套修改更新。

　　同时可以根据软件的主要功能和流程以及经常出现错误的用例整理出一份简化的冒烟测试用例，测试时根据冒烟用例先运行一遍，可以尽早的发现一些常见和较为严重影响软件主要流程的bug，有助于尽早发现问题解决问题，提高软件质量。

要使最终用户对软件感到满意，最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

  以上，关于软件测试的全部内容讲解完毕啦，欢迎大家继续关注!更多关于软件测试的干货请关注职坐标软件测试频道!希望这篇软件测试文章可以帮助到你。总之，同学们，你想要的职坐标软件测试频道都能找到!
  本文由职坐标整理并发布，希望对同学们学习软件测试的知识有所帮助。了解更多详情请关注职坐标软件测试频道!