测试用例的设计与编写

一、测试用例的简介

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。测试用例的设计一般分为黑盒测试与白盒测试，黑盒测试又被称之为功能测试，顾名思义功能测试只关注软件的界面与软件的功能是否满足验收标准，并不考虑软件内部逻辑，而白盒测试被称为逻辑测试、结构测试、透明测试以及代码测试，主要针对于程序内部逻辑结构，对所有逻辑路径进行测试。本文讲述下整体测试用例设计与编写，后期会根据黑盒测试和白盒测试分别进行讲述。

---

二、测试用例的作用

1、对测试起到指导性作用

测试用例主要适用于集成测试、系统测试、回归测试以及部分公司也会对单元测试进行用例设计，在测试过程中以此作为本次测试的标准，按照测试用例所描述的场景与步骤进行细致测试，并将测试结果进行记录，便于测试完成后生成测试报告。

2、对测试数据进行前期准备

在我们进行测试过程中测试数据与测试用例虽然是分离的，但前期数据的收集可以根据制定的测试用例进行配套准备，这样可以提升测试工作效率，减少因为数据不匹配造成的工期延期现象，尤其对于报表、金融类测试对数据的准确性与业务性匹配还是很必须的。

3、对测试脚本进行规格定制

经过多年的发展，为了提高工作效率，软件测试行业开始大力发展自动化测试。自动化测试当然就避免不了测试脚本的编写，当然测试用例此时就可以作为自动化测试的规格资格书。

4、对测试结果的度量标准

经过多轮测试过后，需要对测试结果进行评估反馈，并出具测试报告。这时判断测试是否完成，衡量软件质量是否符合预期就需要一些量化结果。可以通过测试用例所展现的覆盖率，测试过程中测试用例的合格通过率等进行量化评估，这样就可以出具一份专业权威的测试报告了。

5、对缺陷的分析与回顾

通过线上Bug与一些版本遗留Bug，对比测试用例判断是否因为用例覆盖不全导致漏测，确认漏测及时对测试用例进行补充，最终逐渐完善软件质量。

---

三、测试用例的编写

1、测试用例编写常用工具与模版

目前软件测试方法有：等价类划分法、边界值分析法、错误推断法、因果图法、逻辑覆盖法等依据这些方法设计测试用例，根据不同软件的不同性质取适合的方法进行用例设计，灵活运用方法设计测试用例也是一种艺术。

当然测试方法不是设计测试用例的唯一标准，根据每个公司业务与规定不同，编写测试用例的文档模版也各自的内部规范要求。

常用记录测试用例的工具有：Xmind、Excel以及部分大厂自研的内部测试用例管理平台，下面先介绍下Xmind与Excel如何进行用例设计与用例分类。

Xmind：如下图XXX资产管理系统测试用例，首先标明测试功能，并将各个测试点或场景列入其中

Excel：如下图标注出首页XXX测试用例，编写人，并规划测试范围、通用测试点、功能测试点以及根据自身需要的一些数据收集、分析等更能清晰的看到所分出的大类，其次以功能测试为例，可以做以下规划，加入折叠便于查看管理，表后列后也可加入测试结果，全部测试完成之后便于生成量化数据。

以上两种记录测试用例采用的工具是目前大部分公司所采用的形式，当然还有大厂所采用的自研测试用例管理平台本文就不多做介绍。

2、测试用例设计编写

测试用例可以分为基本事件、备选事件（正例）和异常事件（反例）。设计基本事件的用例，应该参照需求文档（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件也就是正常情况的测试用例应包含所有需要实现的需求功能，覆盖率需要达到100%。备选时间（其他情况）、异常事件（误操作情况），所涉及的场景的复杂程度与困难就高的多，例如业务中的一些操作步骤、各个角色权限的控制、字典新增时，代码中的若出现重复字典必须进行报错，报错提示文本正确、接口传值字符长度限制等等，所以对于这种复杂程度高的情况，我们就应该尽可能熟悉业务、软件功能或代码逻辑等，提高测试用例的覆盖率，减少线上Bug出现的风险。

---

写在最后：每个人的测试用例设计方法各有特色，本文也只是对测试用例的设计与编写进行了简述，一个完美的测试用例设计出来必定是各项功能、场景条理清晰，让人看起来赏心悦目。希望各位能多多借鉴身边的高手朋友，提升自己用例编写能力与逻辑能力。让我们共同进步吧！