1、从软件需求文档中，找出待测试软件或模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测试对象具有哪些功能；
2、在做复杂的测试用例设计前，先画出软件的业务流程，如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充，如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图；
3、完成了测试需求分析和软件流程分析后，开始着手设计测试用例，对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生
测试用例设计方法之异常分析法
什么是异常分析法
异常分析法就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，依此设计测试用例。主要针对系统的容错能力、故障恢复能力进行测试。简单一点说就是人为让系统出现故障，然后检查系统的故障恢复能力。
如何使用异常分析法
该方法的步骤非常简单，依赖于测试者的经验。
步骤1：针对系统罗列可能的故障
这些故障包含软件和硬件方面的故障，常见的故障有：
1. 断电
2. 断网
3. 硬件损坏
4. 数据损坏
5. 内存不够
6. .......
为了能更好的罗列故障，需要多查看用户反馈的故障报告，多深入了解被测的系统。
步骤2：针对每种可能故障设计测试用例
设计测试用例时主要要考虑如何更有效更经济的制造各种故障。
案例
例如：针对某在线音乐播放器进行测试，需要考虑断网的异常。从测试用例的角度来说，就是先用该播放器播放歌曲，然后拔掉网线，人为制造断网的故障，过一段时间后再接上网线，恢复网络，这时候来查看一下播放器是否还能正常工作。
异常分析法可以作为典型的测试用例设计方法的一个补充。
如何写测试用例
问题一：如何才能写好一个软件的测试用例 写好一个软件的测试用例的建议有：
1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。
2、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。
3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可操作性。
4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
5、测试用例级别要划分清楚，这样在测试执行时有主次之分。
6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。
问题二：如何写好一份测试用例 写好一个软件的测试用例的建议有： 1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。
问题三：写测试用例应该怎么写？我想知道具体的模式。谢谢！ 假设一下吧。现在要求你测试一下百度知道的提交回答功能。
用例编号：提交问题001（编号通常会根据功能或模块编写）
测试目的：验证当用户回答完问题后，可以正常提交答案。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）
测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。
重要级别：像提交回答这条用例，多数会被列为最高级别用例，因为是最基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）
操作步骤：1、将光标点入“我来帮他解答”下的输入栏。
2、输入想提交的答案
3、点击提交回答
4、验证提交后答案是否能显示到当前问题下
（输入数据多数时候是合并到操作步骤中的，比如这条里的输入数据就是“答案”）
预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的答案可以正确显示……
问题四：编写测试用例有哪些方法？ 你好！
1.等价类
2.边界值
3.错误推测
4.因果图
5.判定表
6.正交实验
7.功能图
等等，个人感觉前三个最常用了，正交表偶尔用下！
复杂业务可能会用到因果图！
你可以参考： 360doc/....shtml
问题五：如何高效编写测试用例 测试用例设计和执行是测试工作的核心，也是工作量最大的任务之一。
测试用例(Test Case)目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试用例编写准备
1
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；
2
根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
测试用例制定的原则
1测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
2测试数据应该选用少量、高效的测试数据进行尽可能完备的测试。
用例覆盖
1正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录进行测试。
6性能：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
7可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
8可移植性：在不同操作系统及硬件配置情况下的运行性。
测试方法
1边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
2等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
3错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
测试用例的填写
1一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。
问题六：如何编写一个完整全面的测试用例 一、编写测试用例的原则
测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。测试用例编写应该遵循的原则：
1、测试用例要达到最大覆盖软件系统的功能点。测试工程师应该测试计划编写完成之后，在开发阶段编写测试用例，参考需求规格说明书和软件功能点对每个功能点进行操作上的细化，尽可能趋向最大需求覆盖率。
2、测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。
3、 测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力等。
4、 测试用例的管理。使用测试用例管理系统对测试用例进行管理。
一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性，而一个成功的测试案例能够发现某个尚未发现的错误，通常一个好的测试案例有以下特性：
1、具有高的发现错误的概率
2、没有冗余测试和冗余的步骤
3、测试是“最佳类别”
4、既不太简单也不太复杂
5、案例是可重用和易于跟踪的.
6、确保系统能够满足功能需求
测试用例不可能设计得天衣无缝，也不可能完全满足软件需求的覆盖率，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试。
二、如何编写测试用例
测试用例的信息有很多，可以根据实际的情况进行增删，一般来说一个优秀的测试用例应该包含以下信息：
1、产品相关信息
（1）软件产品或项目的名称
（2）软件产品或项目的版本
（3）功能模块名
（4）功能描述
（5）测试平台
这些信息建议可以在测试案例手工选择。
2、基本记录信息
（1）测试用例入库者
（2）测试用例入库时间
（3）测试用例更新者
（4）测试用例更新时间
这些信息建议可以由测试案例自动生成。
3、测试用例的属性
（1）测试用例ID：测试用例的ID（由案例管理系统自动生成，方便跟踪管理）
（2）测试用例名称：测试用例的名称
（3）测试功能点：测试的功能检查点
（4）测试目的：该测试功能点的测试目的
（5）测试级别：主路径测试、烟雾测试、基本功能测试、详细功能测试。
下面对这几个测试级别进行说明：
A、主路径测试：对照需求中重要模块和功能的最主要功能路径，主路径测试为设计探针模块，快速检查程序的可测试性（可测试性还包括安装测试是否成功）的主要依据的测试案例
B、烟雾测试：对照需求中所有模块的主要功能路径，主路径测试案例为烟雾测试案例的子集，烟雾测试为做回归测试的主要依据的测试案例。
C、基本功能测试：对照需求和总体设计中所有模块和功能的基本功能路径，基本功能测试为测试软件产品的非重要级别模块，书写完全的自动测试脚本的主要依据。
D、详细功能测试：对照总体设计中所有模块和功能的功能路径，测试各个模块及功能各个层次，各种类型。详细功能测试案例为对重点模块，易发生错误的模块的主要依据。
（6）测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。
（7）预置条件：对测试的特殊条件或配置进行说明
（8）测试步骤：详细描述测试过程，案例的操作步骤建议少于15个。
（9）预期结果：预期的测试结果
三、测试用例设计过程
对一个全新的产品来说，首先需要了解的是产品需求文档和产品模块之间的关系。然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例，这个时......>>
问题七：如何编写单元测试用例 一、 单元测试的概念
单元通俗的说就是指一个实现简单功能的函数。单元测试就是只用一组特定的输入(测试用例)测试函数是否功能正常，并且返回了正确的输出。
测试的覆盖种类
1.语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
2.判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。
3.条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。
4.判定――条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。
5.条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。
6.路径测试：设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
用例的设计方案主要的有下面几种：条件测试，基本路径测试，循环测试。通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。
二、开始测试前的准备
在开始测试时，要先声明一下，无论你设计多少测试用例，无论你的测试方案多么完美，都不可能完全100%的发现所有BUG，我们所需要做的是用最少的资源，做最多测试检查，寻找一个平衡点保证程序的正确性。穷举测试是不可能的。所以现在进行单元测试我选用的是现在一般用的比较多的基本路径测试法。
三、开始测试
基本路径测试法：设计出的测试用例要保证每一个基本独立路径至少要执行一次。
函数说明 ：当i_flag=0；返回 i_count+100
当i_flag=1；返回 i_count *10
否则 返回 i_count *20
输入参数：int i_count ，
int i_flag
输出参数： int i_return;
代码：
1 int Test(int i_count, int i_flag)
2 {
3 int i_temp = 0;
4 while (i_count>0)
5 {
6 if (0 == i_flag)
7 {
8 i_temp = i_count + 100;
9 break;
10 }
11 else
12 {
13 if (1 == i_flag)
14 {
15 i_temp = i_temp + 10;
16 }
17 else
18 {
19 i_temp = i_temp + 20;
20 }
21 }
22 i_count--;
23 }
21 }
22 i_count--;
23 }
24 return i_temp;
25 }
1.画出程序控制流程图
圈中的数字代表的是语句的行号，也许有人问为什么选4,6,13,8......作为结点，第2行，第3行为什么不是结点，因为选择结点是有规律的。让我们看程序中；第2行，第3行是按顺序执行下来的。直到第4行才出现了循环操作。而2，3行没有什么判断，选择等分支操作，所以我们把2，3，4全部合并成一个结点。其他的也是照这个规则合并，然后就有了上面的流程图。
2.计算圈复杂度
有了图以后我们要知道到底我们有写多少个测试用例，才能满足基本路径测试。
这里有有了一个新概念――圈复杂度
圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量。将该度量用于计算程序的基本独立路径数目。为确保所有语句至少......>>
问题八：如何写好测试用例的设计心得 先分测试类型，再根据数据流设计测试模块，整理好测试检查点，最后设计点诡异的测试用例
问题九：测试用例如何写 用例1，输入正确的手机号码，点击获取验证码 预期结果：手机收到验证码
用例2，输入错误的手机号码，点击获取验证码 预期结果：提示输入正确的手机号码
用例3，输入英文字母，点击获取验证码 预期结果：提示输入正确的手机号码
用例4，输入特殊字符，点击获取验证码 预期结果：提示输入正确的手机号码
用例5，输入超长字符，点击获取验证码 预期结果：提示输入正确的手机号码
用例6，输入正确的验证码，点击确定 预期结果：验证通过
用例7，输入错误的验证码，点击确定 预期结果：验证不通过，提示验证码错误
用例8，输入特殊字符的验证码，点击确定 预期结果：验证不通过，提示验证码错误
用例8，输入超长的验证码，点击确定 预期结果：验证不通过，提示验证码错误
纯手打，忘采纳，可以联系854155141继续沟通。
测试用例设计方法有哪些？
1、等价类划分
为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号。设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤，使得有效等价类均被测试用例所覆盖设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被覆盖。
2、边界值分析
从测试规格中分析得到输入参数类型，对于输入等价类划分方法进行等价类的划分，运用域测试分析方法确定域范围的边界（上点、离点与内点）。如果存在多个输入域，则需要运用因果图、判定表方法这些输入域边界值的组合情况进行进一步分析，选择这些上点、离点与内点或者这些点的组合形成测试项。
3、判定表
判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
列出所有的条件桩和动作桩，填入条件桩、条件项和动作桩、动作项，化简，合并相似规则，将每条规则转化为用例。
基本格式
1、用例编号
测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：PROJECT1-ST-001，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
2、测试标题
对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时，软件的响应情况”。
3、重要级别
定义测试用例的优先级别，可以笼统的分为四个不同的等级。
4、输入限制
提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
5、操作步骤
提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
6、预期结果
提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
3、测试用例设计方法
场景法是对系统的功能点或业务流程的描述来进行设计，模拟出用户的正常操作流程和异常的流程，也就是基本流和备选流。一般情况下是一条基本流，N条备选流。
其中，基本流就是每个步骤都是最正常的情况；备选流就是有步骤不是最正常情况，导致生成的新分支。
等价类划分法一般分成两类：有效等价类、无效等价类；等价类其实就是子集。
1、完备测试、避免冗余
2、集合的划分，划分为互不相交的一组子集，而子集的并集是整个集合；子集互不相交：保证一种形式的无冗余性
3、同一等价类标志一个测试用例；因为同个等价类中，往往在程序中的处理方式相同。比如说：
在确立了等价类后，可建立等价类表，列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：
列出正三角形的有效等价类和无效等价类（答案百度有）
边界值法是对等价类划分法的一种补充（等价类法得到的测试数据太多，几乎无限），一般是对等价类划分法的分类进行边界值划分。根据经验，大量的错误是出现在输入或输出的边界值上，因此针对各种边界值情况设计测试用例，可以查出更多的错误。
不仅是考虑输入值的边界，也要考虑输出值的边界
if、while等语句的判断条件、定义域、值域边界、空、畸形输入、未受控状态等。
拓展知识
因果图法是对等价类法的一种补充（等价类法没有考虑到多个输入情况的组合）。如果一个功能逻辑，涉及多个条件或控件，则这时候要考虑它们之间的组合关系，不同的组合之间会触发什么样的输出结果。
与、或、非、恒等、唯一、包含、互斥
靠经验和直觉推测系统可能存在的错误，从而有针对性地去检查这些错误的方法。嗯...看人的一种“方法”。
分析系统中最容易出错的场景和情况，在此基础上有针对性地设计测试用例。需要完成的前提条件如下：
选美投票中如何设计测试用例
测试用例是业务测试过程中测试者的生命线。
在大需求面前无从下手测试时，测试用例是测试者对全盘概念的梳理和深度探索；
在测试过程中碰到任何问题阻断测试场景或思路时，测试用例是测试者的执行指令和方向盘。
当需求文档及对应的需求技术方案产出时，测试者需要根据提供的文档对需求进行解构，解构出需求的原子内容后，再进行测试用例的设计，而测试用例即需要考虑测试验证的全面性又需要考虑测试的深度。那么，这就需要测试人员进行全方位考虑来构建测试思路和使用什么样的测试策略和方法来尽可能保证测试覆盖的全面性。
试问，当面对一个大型需求（此处是指需要花费至少 2 个迭代才能完成的需求），测试人员需要有什么样的测试用例设计思路才能达到高时效、高人效、全面的做到测试覆盖呢？
测试用例设计核心
重要程度
测试用例的设计首要考虑的是主流程场景（一定要搞清楚需求的背景及需求是为了解决什么问题而产生的），主流程包括：
1. 测试用例的设计围绕产品需求文档的描述进行设计
2. 测试用例的设计场景是否符合实际用户的使用场景
在主流程中，把握测试用例的优先级，能够尽早在测试过程中发现严重问题，尽早暴露问题
等价性
测试用例的设计需要根据开发的实现逻辑去设计，黑盒测试可能存在设计的多个测试用例间存在无效测试用例的情况，比如有些交互场景中，存在表单中有多个填入项，如果测试者设计时，将每个输入项都作为一个测试场景去设计，而不了解实现的话，那测试用例将呈指数增长，必定会存在很多无效测试用例。当然，此处的比喻比较极端，但测试者需要有这样的意识，去把开发侧实现的逻辑分支梳理清楚，防止产生垃圾测试用例的情况。
边界性
测试用例的设计涉及到功能模块间的交互，既然涉及到交互那必然存在边界。测试者需要明确该需求的上下游，该需求有几个入口和几个出口。
基于以上几点，作为设计测试用例的核心思想贯穿整个测试用例编写过程，再配合测试方法，你的脑海中将呈现一个需求完整的骨架，那么测试者对质量的把握度会大大提升。
测试点
主流程
主流程，即需求中说明的所有功能点场景，这里是测试的重点，也是冒烟测试去检查提测质量的重要手段。
分支流程
主干逻辑以外的分支逻辑场景。
异常流程
数据异常：如关键数据缺失、数据重复推送
调用链异常：如业务调用链路异常，系统的处理
常见异常有：
依赖服务不可用，是否有降级处理，是否有监控告警？
依赖数据缺失，是否 catch 异常，确保程序不 crash，并产生 error 日志？
服务重启，是否容错？
基础组件服务异常，如 redis、kakfa、mysql 等异常，是否丢数据，基础服务恢复以后，能否恢复服务？
UI 测试点
风格、样式、布局
校验：必填、选填等
显示是否有遮盖和不合理的省略情况
提示语是否友好
等等（此处可对不同项目的 UI 关注点进行补充）
向前兼容
针对对已有的需求进行改造时，需要考虑接口或者 GUI 上的向前兼容。
关联功能
需要评估该需求是否会影响到已有功能，比如：代码中对公共模块的改动。
历史数据影响
需求改造是否需要对历史存在的数据进行处理？如：已有表结构更改等。
性能影响
这里指的性能影响比较简单，如：接口响应速度（大数据量的查询、高并发访问等）、GUI 的渲染速度（大数据量时的渲染）作为基本的性能达标指标；
对于系统最大的业务处理能力、处理速度等性能表现，需要另起一个大话题来说了。
终端兼容性
若产品支持：PC、小程序、APP 端等多个终端，需要在多终端验证功能可用性。
安全性
业务数据安全：如，重要数据非明文；
业务场景安全：如，绕过登录验证、交易中的数据篡改、接口的恶意调用等
以上设计测试用例的思路和方法是个人工作经验中的沉淀和总结，属于个人浅薄之见，但应该对测试新人有一定的参考作用，同时也希望业内精英能够发现不足和缺陷，提出改进意见。
如何设计好测试用例
什么是测试用例
测试用例也叫测试案例，是在执行测试之前由测试人员编写的指导测试过程的重要文档，主要包括：用例编号、测试目的、测试步骤、预期结果等
注意：不同公司使用的用例模板可能存在差异，但都大同小异
为什么要写测试用例
1、防止测试点的遗漏，让测试覆盖的更全面
2、方便做版本的回归测试
3、监督测试过程，评估结果
4、提高测试效率，避免盲目测试
5、缩短周期，比如当版本更新或升级时，只需修正少部分测试用例即可，用例资源可以做到重复使用
测试用例编写依据
1、业务需求文档或需求规格说明书
2、开发文档，比如概要设计文档、详细设计文档
3、参考已开发出来的程序，即一边对照程序+需求文档，一边写测试用例
4、与开发人员、需求人员、客户进行沟通确认
什么是好的测试用例
1、用例覆盖率最大化：好的测试用例是完整的用例集合，能够完全覆盖测试需求
2、测试数据的准确性：等价类划分准确，每个等价类范围的数据，测试效果一致
3、测试数据的全面性：保证所有可能的边界值和边界条件涵盖在内，且正确识别
设计测试用例的常见方法
1、等价类划分法
2、边界值分析法
3、错误推测法
4、因果图法
5、判定表法
6、正交排列法
7、功能图分析法
8、场景法等
其中，等价类划分法、边界值法、错误推测法是平时工作中最常用的方法，也是设计好一个测试用例的装备武器，本节课主讲等价类划分法和边界值分析法。
方法一：等价类划分法
将所有可能的输入数据划分为若干子集，从每一个子集中，挑选任意输入数据，测试效果是一样的。那么这样的子集就是一个等价类。
比如有一个需求是：某输入框只能输入-99（含）至99（含）之间的整数，且不能为空
有效等价类（有效数据）可划分为：
-99至0之间的任意整数
0至99之间的任意整数
无效等价类（无效数据）可划分为：
小于-99的整数
大于99的整数
为空的情况
非整数的情况（浮点数、字母、特殊字符、中文字符）
如下图：
方法二：边界值分析法
对输入或输出的边界值进行测试的一种黑盒测试方法，即选取边界值进行测试。因为测试数据的边界值在程序中最容易出错，所以边界值应该重点测试。
还是以上面需求为例：某输入框只能输入-99（含）至99（含）之间的整数，且不能为空
有效边界值包括：
-99（最小边界值）
-98（有效最小次边界值）
-1（边界值）
0（边界值）
1（边界值）
98（有效最大次边界值）
99（最大边界值）
无效边界值包括：
-100（无效最小次边界值）
100（无效最大次边界值）
备注：测试过程中，只要是需要输入数据的地方，就可以使用等价类划分法和边界值分析法，这两个方法一般是搭配使用的。
方法三：错误推测法
基于对被测软件系统的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。
即错误的操作，比如输入输出数据为0或空格等容易错误的情况。将其作为测试用例来执行。
测试用例设计方法（三）正交试验和场景法
正交试验设计法，是从大量的试验点中挑选出适量的、有代表性的点，应用依据迦罗瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法。
• 因子：所有影响试验指标的条件
• 因子的状态：而影响试验因子的取值，叫做因子的状态
每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。
场景法简介
场景法一般包括基本流和备选流，如图所示。从一个流程开始，图中经过用例的每条路径都可以用基本流和备选流来表示。
直黑线表示基本流，是经过用例的最简单的路径。
场景法的设计步骤如下：
1）根据说明，描述出程序的基本流及各项备选流。
2）根据基本流和各项备选流生成不同的场景。
3）对每一个场景生成相应的测试用例。
4）对生成的所有测试用例重新审查，去掉多余的测试用例，确定测试用例后，为每一个测试用例确定测试数据值。
如何应用场景法设计软件测试用例
黑盒测试具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、场景法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。这些方法是比较实用的，但采用什么方法，在使用时自然要针对开发项目的特点对方法加以适当的选择。等价类划分法等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的需求和说明，即需求规格说明书。由于穷举测试工作量太大，以致于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。等价类划分法等价类划分法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。使用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。划分等价类和列出等价类表可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据取得较好的测试结果。等价类划分有两种不同的情况：有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类：与有效等价类的定义恰巧相反。设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性。确定等价类的原则在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。建立等价类表在确立了等价类之后，建立等价类表，列出所有划分出的等价类：确定测试用例根据已列出的等价类表，按以下步骤确定测试用例：为每个等价类规定一个唯一的编号；设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖；设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。边界值分析法由测试工作的经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。边界值设计原则对边界值设计测试用例，应遵循以下几条原则：如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。根据规格说明的每个输出条件，使用前面的原则1。根据规格说明的每个输出条件，应用前面的原则2。如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。分析规格说明，找出其他可能的边界条件。其他一些边界条件另一种看起来很明显的软件缺陷来源是当软件要求输入时(比如在文本框中),不是没有输入正确的信息，而是根本没有输入任何内容，单单按了Enter键。这种情况在产品说明书中常常忽视，程序员也可能经常遗忘，但是在实际使用中却时有发生。程序员总会习惯性的认为用户要么输入信息，不管是看起来合法的或非法的信息，要不就会选择Cancel键放弃输入，如果没有对空值进行好的处理的话，恐怕程序员自己都不知道程序会引向何方。正确的软件通常应该将输入内容默认为合法边界内的最小值或者合法区间内某个合理值，否则返回错误提示信息。因为这些值通常在软件中进行特殊处理，所以不要把它们与合法情况和非法情况混在一起，而要建立单独的等价区间。场景法现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。提出这种测试思想的是Rational 公司，并在RUP2000 中文版当中有其详尽的解释和应用。用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。测试方法选择的综合策略测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平。 畛域值剖判法：畛域值剖判法假定大多半的舛错产生在各种输入条件的畛域上，如果在畛域邻近的取值不会招致舛错，那么其他取值招致舛错的或许性也很小。这种方法在很多时间能卓殊有效地暴露程序的舛错，但是它与等价类分别法一样没有切磋输入之间的组合状况，另外，畛域值在关切畛域范围的同时，或许纰漏了输入类型的题目。根本途径剖判法：根本途径剖判法通常使用在白盒测试中，用于笼罩程序分支途径。但在一些黑盒测试中也能使用。 （该图是一个单据审批流程）依照根本途径剖判，可以简便的归结出以下几种必要笼罩的流程：编辑请求单→确认→审批始末→生成请求呈报编辑请求单→确认→废止确认→重新编辑编辑请求单→确认→审批不始末→重新编辑根本途径剖判法的重点在于笼罩流程，确保让程序显示所有或许的逻辑。但是这种方法也生活必然的缺陷，即只笼罩一次流程，看待一些生活循环的流程没有切磋。例如：编辑请求单→确认→废止确认→重新编辑→确认→废止确认时出错。因果图法：因果图是一种简化了的逻辑图，能直观地阐明程序的输入条件（理由）和输入手脚（下场）之间的相相互干。因果图法是借助图形来设计测试用例的一种编制方法，特别适用于被测试程序具有多种输入条件，程序的输入又依赖于输入条件的各种状况。因果图法设计测试用例的方法如下：1）剖判所有或许的输入和或许的输入。2）找出输入和输入之间的对应相干。 3）画出因果图。4）把因果图转换成占定表。5）把占定表对应到每一个测试用例。因果图法设计测试用例的优点是让测试人员始末画因果图，能越发了解输入条件之间的逻辑相干，以及输入与输入之间的相干。缺点是必要画图和装换成占定表，看待对比杂乱的输入和输入必要破费多量的时间。场景设计法：场景设计法必要测试人员充盈施展对用户实际业务场景的遐想。舛错推度法：舛错推度法是测试体验富厚的测试人员喜好使用的一种测试用例设计方法。舛错推度法始末基于体验和直觉推测程序中或许产生的各种舛错，有针对性的设计测试用例，由于测试素质上并不是一门卓殊缜密的学科，测试人员的体验和直觉能对这种不缜密性做出很好的补充。正交实习法：要是：看待一个必要输入5个条件，每个条件参数为5个的界面，如果切磋所有的笼罩，则必要5×5×5×5×5=3125个测试用例，这样的劳动量是卓殊之大的。如何简化测试用例，用最少的用例得到尽或许所有的笼罩率呢？始末正交表可以有效的省略用例个数。欺骗正交表设计测试用例的方法如下：1）判断有那些身分。身分指输入的条件2）每个身分有哪几个参数。即水平3）选择适宜的正交表【正交表：L4(2^3) 其中4表示用例个数、2表示水平、3表示身分】4）把变量的值映照到表中。5）把表中每一行的各种身分和参数的组合营为一个测试用例。正交表法的依据是galois实际，从多量的实习数据当选择过量的、有代表性的点，从而合理地布置实习的一种迷信实习设计方法。在测试用例的设计中，可以从多量的测试用例数据当选择过量的、有代表性的测试数据，来合理布置测试。平均实习法：平均实习法是与正交表法相像的一种测试用例设计方法。正交表法的特质是划一并具有可比性和平衡星散性。平均表则是甩掉了划一可比性，仅切磋平均星散性的一种实习方法，它的优点是进一步省略实习的次数。组合笼罩法：组合笼罩法是另一种有效省略测试用例个数的测试用例设计方法。根据笼罩水平的不同，可以分为单身分笼罩、成对组合笼罩、三三组合笼罩等，其中又以成对组合笼罩最为常用。成对组合笼罩法请求随意两个身分（输入条件）的所有参数组合至多要被笼罩一次。组合笼罩的算法仍旧被很多工具实行，测试人员可以间接使用这些工具。例如：Tconfig、微软的PICTPICT罗致一个纯文本的Model文件作为输入，然后输入测试用例的会集。Model.txt文件的格式如下：<ParaName>：<value1>,<value2>,<value3>,……<ParaName>表示条件，<value1>,<value2>,<value3>表示参数分类树方法：分类树法是软件功用测试的一种方法，通太过类树把测试对象的整个输入域决裂成独立的类。
网络通信测试--如何测试各种异常场景?
我们对网络通信测试一般会使用一些抓包工具，比如Wireshak, TcpDump等，通过这些工具来抓取和查看通信过程的各种消息及数据，而现实测中我们经常面临这种困难：通信的对端通常只能返回一些正常的消息，一些异常的场景却很难覆盖到。
如何对通信设备（软件）进行更全面的测试呢？为了测试覆盖更多的测试场景，一些对产品质量要求比较高的企业会专门设计测试工具来模拟现实中可能出现的各种场景，对通信业务进行全面覆盖测试。这些工具的开发不仅需要专业的开发工程师，而且维护的成本也很高。有了这样的专门的测试工具，测试人员可以进行的更多的场景测试，但这些工具的使用增加了测试人员的负担，测试人员需要手工在工具上进行一个个场景的配置，然后手工执行相关测试，整个测试过程需要耗费大量的时间。
如何既能对通信业务场景进行全面覆盖又能高效地执行呢？小蚂蚁测试(Antestin.com)提供了完整的测试解决方案。小蚂蚁协同自动化测试平台支持对通信过程各种场景进行模拟，支持各种异常状态注入，实现对各个通信场景的自动化测试覆盖。
支持对通信过程各种场景进行模拟，支持各种异常状态自动注入，支持回复消息自动配置，支持对接受消息全面检查
实现支持HTTP协议测试， 支持对测试Web通信的服务端和客户端进行测试。
支持TCP/IP测试， 支持对通用TCP服务端和客户端进行测试。
支持无线通信测试，支持对2G，3G，4G，5G及Wifi的无线通信AT命令进行测试。
网址：https://www.antestin.com
如何设计出高质量的测试用例
做为一个测试人员，设计测试用例可以说看家本领，不管你到那一个层次，都需要时时揣摩。我也一直在考虑，经过多年的学习和实践，从中得出一些心得，在此班门弄斧一番，另外也想抛一块砖换块玉回去。 我把测试用例分成几个大类，一类是场景用例，一类是个别用例，一类是体验用例。 1. 场景用例，我把用户使用或操作习惯搭配称之为场景，不同的用户可能有不同的操作习惯，所以要完全模拟出用户的操作是比较难的，但是入口确是我们可以控制的，因此我们要整理出达到测试目标的入口，然后根据入口搭配出各种路径，针对这些路径进行覆盖，这样就可以设计出的场景用例。要写好场景用例，需要仔细了解测试目标的业务逻辑，然后根据业务逻辑来筛选出有效场景和无效场景，此类用例贴近用户使用习惯，查不出缺陷则已，一旦查出都是影响比较大的。举例来说：比如一个查询页面，有三个查询条件，其中两个个是选择型输入，一个是输入框，然后加一个按钮。这样的页面，普通用户比较实在，只找他想要的，所以选择条件和输入都比较规矩。这类场景比较好写。但是有些刁钻的用户可能会随意选择，然后输入的时候会空着，或者输入一些奇怪的字符进去。还有一些比较专业的用户，可能会尝试输入一些sql注入之类的东西。如果数据量太大，搜索响应比较慢，性急的用户可能反复点击搜索按钮，或者反复刷新页面。诸如此类的场景我们都会遇到，所以这些场景要保证有保护或者正常，不能出现异常或崩溃。 2. 个别用例，主要是指针对输入或者各类参数进行的针对性的用例，比如上例中的输入框，选择框的针对性用例。这类用例比较好设计，因为大家见得比较多了，这类用例可以抽出其共同部分写成通用用例，这样不但可以让用例看起来清楚，还能突出重点。设计方法不外乎极限值，等价类划分，因果图之类的。 3. 体验用例，用户体验可以说是很重要的部分，做好了产品的粘性就好，竞争力也就强力了，做的不好，用户也就浅尝辄止，没有粘性的产品很难说是成功的产品。用户体验分为视觉体验，操作习惯体验，心理体验几个部分，视觉主要是颜色搭配，界面模式等；操作习惯主要是符合人体工学，符合大众口味，简洁，易于使用，傻瓜型；心理体验方面主要是培养成就感，归属感等。这部分用例扩展出来比较多，而且也是仁者见仁智者见智的事情，我这里就不细说了，大家有兴趣可以探讨一下。 最后一点就是测试用例和测试数据分离，用例中不出现具体的测试数据，保证用例的灵活性和可操作性。
