一般测试场景测试用例怎么写_测试场景的设计方法

如何写测试用例

测试用例设计和执行是测试工作的核心，也是工作量的任务之一。

一般测试场景测试用例怎么写_测试场景的设计方法

一般测试场景测试用例怎么写_测试场景的设计方法

测试用例(Test Case)目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

测试用例编写准备

1从配置处申请软件配置：《需求规格说明书》和《设计说明书》；

2根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。

测试用例制定的原则

1测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。

2测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。

用例覆盖

1正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

2容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品作一点也不懂的客户，在进行任意作。

3完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。

4接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

5压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。

6性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。

7可理解（作）性：理解和使用该系统的难易程度（界面友好性）。

8可移植性：在不同作系统及硬件配置情况下的运行性。

测试方法

1边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。

2等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

3错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

测试用例的填写

1一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，作步骤应尽可能的详细，测试结论是指终的测试结果（结论为：通过或不通过）。

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

简单来说，测试用例就是指导如何做测试的文档，该文档主要记录需要验证被测软件的是否满足需求。

编写测试用例的主要思路如下：

（1）常规思考，设身处地的从用户角度出发；

（2）测试理论方法的支撑，如观察法、等价类、边界值、因果图等；

（3）产品的熟悉和经验的积累

一份的测试用例可以限度地减少产品bug，提高产品质量。

测试用例是怎么写的?

测试用例可以分为基本、备选和异常。设计基本的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本的测试用例应包含所有需要实现的需求功能，覆盖率达。

设计备选和异常的用例，则要复杂和困难得多。例如，字典的代码是的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。

往往在设计编码阶段形成的文档对备选和异常分析描述不够详尽。而测试本身则要求验证全部非基本，并同时尽量发现其中的软件缺陷。

可以采用软件测试常用的基该方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基该方法来设计完整的测试用例，并终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

设计原则

测试用例是一个文档，是执行的小实体。测试用例包括输入、动作、时间和一个期望的结果，其目的是确定应用程序的某个特性是否可正常工作，并且达到程序所设计的结果。

以便测试某个程序路径或核实是否满足某个特定需求般在进行测试用例设计前要全面了解被测试产品的功能、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术与方法等。测试用例设计一般遵循以下原则:

(1)正确性。输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

(2)全面性。覆盖所有的需求功能项;设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)作和环境设置等。

(3)连贯性。用例组织有条理、主次分明，尤其体现在业务测试用例上;用例执行粒度尽量保持每个用例都有测点，不能同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。

(4)可判定性。测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。

(5)可作性。测试用例中要写清楚测试的作步骤，以及与不同的作步骤相对应的测试结果。

想快速又简单地编写测试用例？看这里！

本文适用对象

初级软件测试人员，或想开拓思路拓展测试范围、提高测试覆盖率的所有测试人员等等。

本文目的

讲述如何快速、简单、有效、有条理地编写一条测试用例，并帮助测试人员从测试用例角度拓展测试思路。

如何简单、快速地

描述（编写）一个测试用例

测试用例的目的在于指导、帮助测试人员按照既定的步骤执行测试，并比对测试结果与预期结果是否一致。

对于中大型软件公司而言，测试用例的管理都有既定的规范和工具，如表格管理用例、测理软件管理用例（如下图1所示为MeterSphere测理软件用例编写页面）等。

但总而言之，测试用例的内容主要不外乎3个部分：前置条件、步骤、预期结果。

那么，对于没有明确地测理软件的小型软件公司，或者对于测试人员而言，需要暂时快速地编写一个测试用例或记录测试过程的时候，可以怎么做呢？

一个临时性的用例编写模板：GIVEN...WHEN…THEN。

让我们套用GIVEN…WHEN…THEN的模式来描述下编写用例的大致步骤：

有没有觉得很简单？

让我们再用实际案例，描述下如何用GIVEN…WHEN…THEN模板编实用例。以测试访问 链接这个用例为例1：

使用GIVEN…WHEN…THEN能够简单呈现用例前置条件、执行步骤和预期结果间的逻辑关系，并能清晰地表述一个用例。

那么，什么地方可以用GIVEN…WHEN..THEN这个模板呢？这个模板较之文档用例更为简洁，如下图2所示，对于测试用例提交故障，阐述引发故障的作方法或故障复现方法，以及故障修复后的验证时都可以使用。

如何使用探索式场景联想法

衍生测试用例

探索式测试更多的是一种测试风格和测试思想，要求测试人员在测试过程中不断思考、发散思维，记录、修改和更新测试方法和测试用例。

场景法则是要求测试人员认真分析测试需求，了解用户使用场景，根据不同的场景进行测试。

而本文讨论的 探索式场景联想法，则是将探索式测试方法、场景法和联想法相结合，在已有测试用例的基础上衍生更多的测试用例。

那么，如何使用探索式场景联想法衍生测试用例呢？

由上一节可知，测试用例是指导测试人员在xx预知条件（场景）下，执行xx步骤，预期得到xx结论。

显而可见，通过改变测试用例的预知条件和作步骤，则可以衍生出不同的测试用例。而这些测试用例包含不同的测试场景和不同的测试步骤。

如下图3所示，为探索式场景联想法衍生测试用例的结构脑图。

改变前置条件

测试用例的前置条件基本包括：硬件资源和软件系统两个部分。

改变前置条件可以从这几方面入手。

以上节的访问 链接用例1为例，改变前置条件衍生新的测试用例。由于该用例的前置条件较简单，改变前置条件只需改变浏览器类型和版本即可。

由此，衍生的部分测试用例可如下所示：

改变作步骤

改变用例作步骤可以从以下几方面入手：插入步骤、删除步骤、改变步骤和重复步骤。

插入步骤

如图3所示，插入步骤又可以分为插入相关联步骤和不相关联步骤。并在插入步骤中增加用户输入。

同样以用例1为例，插入步骤衍生的测试用例可如下：

删除步骤

删除步骤可以分为删除部分步骤或者删除部分步骤中的部分作。删除部分步骤，又可以分为删除关键步骤和非关键步骤。

例如，以例1为例，删除关键步骤“点击键盘回车键“衍生新的测试用例如下所示：

改变步骤

改变步骤主要涉及步骤顺序的改变和步骤内容的改变。当测试用例具有多个步骤，且步骤间具有关联性和顺序性的时候，改变步骤顺序则会变得很有意义。改变步骤内容主要是改变步骤中用户的输入（包括数据输入、用户作等）。

以用例1为例，改变步骤内容衍生的用例如下所示：

重复步骤

对于大多测试人员来说，衍生测试用例时更多关注点在于作步骤的变化。

但是，对于不同的测试场景，重复相同的测试步骤，仍然具有很大的测试意义。重复步骤进行测试能够挖掘不同前置条件（场景）下的故障，亦能挖掘软件在多个重复步骤作下潜藏的故障。

以用例1为例，重复步骤衍生的用例如下所示：

测试结论衍生测试用例

除了通过改变前置条件和作步骤衍生测试用例外，还可以根据测试结论中的异常信息，逆推测试场景，衍生新的测试用例。

这个部分更多的需要测试人员掌握探索式测试方法，对测试过程中的软件资源信息、错误日志等保持警惕性，挖掘错误信息中的内容，逆推产生错误信息的原因，构建新的测试用例。

小结

本文阐述了一种可以在提交测试故障信息和验证测试故障时使用的快速测试用例编写模板，快速记录测试场景、测试步骤等关键信息。

并在此基础上，简单讲解了基于探索式场景联想法的测试用例衍生方法，可以帮助测试人员借助已有的测试用例拓展新的测试用例，扩大测试范围，提高覆盖率，挖掘更多场景下的软件故障。

转自公众号投稿：

测试用例怎么写

编写测试用例的方法：根据需求文档，完全按照需求文档框架／功能描述，根据自己的理解整理为用例。

简单来说，就是将需求文档描述的内容，重新按照用例的格式编辑一次，把能想到的各种可能性添加进去。搜索其他测试人员编写的同类型功能用例，先理解，再根据项目实际需求的较小异，重新新增／删／改，组成满足需求的用例组。

快速掌握用例其实没有什么窍门，只有多看，多想，多写，多评审。测试用例是为了实施测试而向被测试系统提供的一组。测试用例构成要素：用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤预期结果。

测试用例设计方法

1、白盒法：又称结构化方法或逻辑覆盖法，其基本思想是把程序看作是路径的。这样，对程序的测试便转化为对程序中某些路径的测试，要设法让被测程序的“各处”均被执行到，使潜伏在程序每个角落的错误均有机会暴露出来。

2、黑盒法：又称为功能测试，是根据软件需求说明书上罗列的各项功能、性能指标，来构造测试用例的输入数据，实际执行被测软件，分析执行过程的行为与执行结果以便检查出被测软件的错误。在黑盒法测试中，测试者可以完全不关心程序的内部结构。

如何写测试案例

关于 测试 用例，我们有太多的疑惑了，测试用例的依据？好的测试用例评估....等等。我们依据需求分析，依据开发文档，依据系统设计文档，甚至依据UI写测试用例，我们就真的足够了？不够，真的不够。需求在变，开发文档跟着变，设计文档也在改动，UI也在做变化，那我们的测试用例应该怎么写？

如何写测试用例

编写测试用例需要有以下几点：

1、 测试用例编号

◇ 规则：编号具有性、易识别性，由数字和字符组合成的字符串

◇ 约定：

系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX

集成测试用例：产品编号-IT-集成测试项名-集成测试子项名-XXX

单元测试用例：产品编号-UT-单元测试项名-单元测试子项名-XXX

2、测试项目

◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等

◇ 约定：

系统测试用例测试项目：软件需求项 如：测试手机在没有SIM卡的情况下，可以拨打紧急电话

集成测试用例测试项目：集成后的模块名或接口名 如：测试模块A提供的文件接口

单元测试用例测试项目：被测试的函数名 如：测试函数int ReadFile(char pszFileName)

3、 测试标题

规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。

4、重要级别

规则

高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；

中：重要程度介于高和低之间的测试用例；

低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。

5、预置条件

规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件

6、输入

规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等

7、作步骤

规则：执行当前测试用例需要经过的作步骤，保证作步骤的完整性。

8、预期输出

规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等