要求不超过3组,可以设计以下3组：
1）执行路径：123578；两个判定(3)和(5)的结果:FF
输入值（数据符合执行路径 ），如：2,1,3。(即x1=2,X2=1,X3=3,所以4个条件就是FFFF)
输出值(根据你设计的输入值和执行路径而定) :3。(X3=3)
2）执行路径：1234578；两个判定(3)和(5)的结果:TF
输入值 ，如：3,2,3 (4个条件就是TTTF)
输出值:6
3)执行路径：1235678；两个判定(3)和(5)的结果:FT
输入值,如:4,0,0, (4个条件就是FFTT)
输出值:1
以上设计的执行路径覆盖了判定条件
输入值设计覆盖了判定中的每个条件的F和T
我讲的应该挺清楚了吧，希望能看明白。这样如果不采纳，就真太伤我心了。1软件定义：一系列按照特定顺序组织的计算机数据和指令的集合。
软件=数据 + 指令
2软件的分类：
(1)类型：工具类软件、游戏型软件、媒体型软件、电商型软件等
(2)架构：
①单机软件：office、红警等
②分布式软件：
C/S架构软件：客户端需安装专门软件，如QQ 微信等
B/S架构软件：客户端为浏览器 ，如百度、hao123等
面试题：C/S和B/S的区别
3软件测试:
定义：通过人工或自动化的方式来验证软件的实际结果与用户需求是否一致的过程
原则：
1测试显示软件存在缺陷
2穷尽测试是不可能的
3测试尽早介入
4缺陷集群性（2/8原则）
5杀虫剂悖论
6测试活动依赖于测试内容
7没有错误是好是谬论
4测试模型：
1V
2W
3H
4X
5测试流程
角色：项目总监、产品经理、UI设计、项目经理（项目总监）、开发、测试
面试题：测试流程
6软件分类
(1)技术：黑盒测试、白盒测试、灰盒测试
(2)阶段：单元测试、集成测试、系统测试、验收测试
(3)其他：冒烟、回归、随机、兼容、内测、公测
1模板
(1)测试目的：测试内容、最多遗留bug、上线时间
(2)测试资源
①人力资源：岗位、姓名、职责
②软件资源：浏览器、 *** 作系统、DB、运行环境、服务器
③硬件资源：手机、电脑、平板、机器人、汽车
④网络资源：互联网、局域网
(3)测试范围
①测试对象
②测试特性
③测试非特性
(4)测试进度：任务、测试人员、预期开始时间、预期结束时间、时间进度、备注
(5)测试风险
①内容：人资源环时
②模板：风险编号、风险描述、责任人、风险等级、对项目的影响、规避方法
(6)测试准则：启动、暂停、再启动、停止准则
(7)人员分工：岗位、姓名、工作内容
(8)测试策略、功能测试、接口测试、接口测试、兼容测试、性能测试、易用性、安全测试
(9)测试输出
①模板：文档名称、文档编号、编写人、文档详情
②内容：测试计划、测试用例、测试报告、缺陷报告
2如何写
(1)封面
(2)九大项：标题 填内容
(3)插入目录
九大项：测试目的、测试资源、测试范围、测试风险、人员分工、测试策略、测试准则、测试进度、提交测试文档。
只要第一项和最后一项的位置是固定的，其他都可以微调位置
1测试用例概述
(1)定义：执行测试的用例
(2)原因
(3)如何保证高质量的测试用例：
①覆盖率
②简单明了
③符合需求
④用最少的用例覆盖最多的需求
(4)方法：等价类划分、边界值分析法、场景法、错误推断法、因果图法、正交实验法
2设计测试用例方法
(1)等价类划分
①定义：把所有可能输入的数据分为若干个区域，然后从每个区域中取少量有代表性的数据进行测试。
②分类：
1)有效等价类：符合需求的数据
2)无效等价类：不符合需求的数据
③案例：
1)手机号案例
2)实名认证
(2)边界值分析法
①定义：取稍高于或稍低于边界的一些数据进行测试
②取点：
1)左上点：边界坐点
2)右上点：边界右点
3)左离点：闭外开内
4)右离点：闭外开内
5)内点：区间任意一点
③边界值和等价类划分分法去重：内点和有效等价类一个点重复
(3)场景法
①定义：模拟用户场景
②分类：
1)基本流：正确的流程
2)备选流：不正确的流程
③案例：注册
(4)因果图法
①定义：因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。
②案例：自动售货机
(5)错误推断法
①定义：经验丰富的测试工程师
②案例：手机无法拨通
(6)判定表法
①定义：设计测试用例时，分析和表达多输入条件下执行不同 *** 作的黑盒测试方法。
②案例：修车
(7)正交实验法
①定义：使用正交小助手
②案例：字符设置
3用例核心要素
必须掌握：用例编号(如何命名)、所属模块、用例标题（验证谁在什么情况下，去做什么，最后结果是什么）、优先级、前置条件、 *** 作步骤、测试数据、预期结果、实际结果
了解内容：通过否、bugID、编写人员、编写时间、测试人员、测试时间、备注软件测试用例就是指导你执行测试，帮助你证明软件功能或发现软件缺陷的一种说明。
可以总结为 ：每一个测试点的数据设计的步骤设计。
微信红包用例？
用例编号：HB_001
功能模块：发送红包
测试标题：输入正确的金额和密码后，能否正常发送红包
前提条件：1、网络正常和钱包有钱
*** 作步骤：
1、进入红包发送页面
2、输入正确的金额和密码（）
3、点击发送按钮期望结果:发送成功
实际结果：
1测试标题描述一定要包含具体测试点
2测试步骤一定要包含
3预期结果一定为唯一，不能出现“发送成功或发送失败”
测试用例的重要性：
1便于测试计划的实施
2规划测试数据的准备
3编写测试脚本的根本
4评估测试结果的基准
5分析缺陷的标准
1、组成：测试用例文档由简介和测试用例两部分组成。
简介部分编制测试目的、测试范围、定义术语、参考文档、概述等。
测试用例包括 ：用例编号、功能模块、用例名称、前提条件、 *** 作步骤、期望结果、实际结果、备注。
2、编写方式：一般是按照功能+业务逻辑
1）首先保证功能是正常的 2）然后才是功能联合起来的业务逻辑是对的。比如说：登录、充值、体现功能分别都是好的，业务逻辑，就是要把所有的功能联合起来走一遍，看是否好的。
3、用例覆盖：测试用例旅游分为正常事件和异常事件。
1用例需要评审么？紧急情况用例也需要评审么？
2一天能够写多少用例？执行多条用例？
3自己写的用例可以打多少分？
4如果被测项目很紧急。来不及写用例，怎么办
5电梯、雨伞、杯子、笔写测试点
6遇到隐性需求如何写用例（需求不明确）
7用例有没有优先级？如果一定要有优先级，依据什么来确定呢
8如何编写测试用例？我一直在想，作为测试人员应该用脑袋去测试，也就是说应该在工作中不断的总结经验，把自己的发现应用到测试中去，这样你才能有真正的提高，你所具备的理论和能力才有竞争力。回到测试用例中来，我觉得做好以下三点就是一个好的用例。第一：依据分明众所周知，一个项目首先立项，然后经过一系列的动作到了需求分析，昨晚需求分析后，测试就可以做测试需求，然后就可以写测试用例了。所以写测试用例的依据就是需求。这么说太笼统，举一个例子。一个系统经过前期的需求分析，详细设计，模块设计等一系列的动作，最后生成了详细的需求说明和详细设计文档等等，在这些文档中，已经很详细的描述了所有的需求点和功能点，也有较详细的技术说明，接下来的工作就是怎么把这些功能点和需求点变成测试点，这就需要做好测试需求分析和测试方案工作，生成一个个可测试的测试点。这也是需求必须可测的一个体现。假设经过上一步工作，分析出这个系统有5个模块，50个大的功能点，500个具体需求点，最后生成了5000个测试点。那么 ok，我们就要写5000个测试用例。还是那句话，一个测试用例只能对应一个测试点，测试点和用例是1对1的关系；一个需求点可以对应多个用例，需求点和用例是1对多的关系。这样做的目的在统计中讲。第二：目的明确用例都有个测试目的，这就是要目的明确，并且也只能有一个目的。前面无论多少步骤，都是为了找到这个目的途径。功能从大到小有层次的划分，我们做测试用例也是有层次的，不然你怎么定义用例的优先级呢？等到测试最小的功能点是，支持这个功能点的其他上层功能点，我们都默认正确就可以了，这就是我们的预期，所以在测试步骤中不用对上层的功能专门考虑测试数据，只把他当成一个正确的找到目前的功能点的途径就行。换句话说，你要测试的功能点需要点10个连接才能找到，那么前9个连接我们再以前就应该设计了用例，在第10个连接中默认他们正确就ok，这个用例的前9步，只是告诉你如何找到第10步。就是这样。第三：便于统计测试用例对整个测试过程的质量控制和评估有很重要的意义。一，可以做测试需求覆盖分析。这样如果一个用例写几个测试点，那么就无法完成需求覆盖分析工作，至少是不符合规则的。你还可以通过模块划分，来分析哪个模块存在的问题较多，还有可能存在更多的问题（应为程序员不同，能力就不同，缺陷喜欢扎堆分布，这个大家都知道），存在问题较多的模块需要做进一步的测试或者下一次作为测试重点。如果你统计的数据不准确，会误导结果的。三，做缺陷分析。用例失败了，就生成一个缺陷。 测试设计是将概括的测试目标转化为具体的测试条件和测试用例的一系列活动。
①评审测试依据（需求，系统架构、设计和接口说明）。
②评估测试依据和测试对象的可靠性。
③通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定优先级。
④设计测试用例，并确定优先级
⑤确定测试条件和测试用例所需要的必要的测试数据。
①依据在测试策略或测试计划中确定的测试技术。
②通过对测试依据和测试目标的分析，可以确定需要测试的内容，获得测试条件。
测试用例是通过使用在测试计划中确定的测试技术，对于已确定的测试条件进行逐步推敲，精炼而设计出来的重点说明如何具体 *** 作产生何种结果的文档。（指引我们测试的文档）
测试用例应该具有可重复性、可验证性和需求可追踪性。
①前提条件，如项目或局部测试环境的需求，及其交付计划。
②测试步骤。
③测试数据。
④预期结果。
①测试两个参数的值相加后的结果是否正确
②期中：输入的数值在-99到99之间，大于99或小于-99的输入应该被拒绝，并显示错误信息。
根据测试需求，我们开始测试：
①分别给第一个参数和第二个参数输入表中的值，得到的测试加过如表所示：
②如果我们对第一个参数的值分别取从-99到99的199个数，第二个参数的值分别取从-99到99的199个数，我们不可能对两位数相加的所有情况进行穷举测试。
③如果不能进行穷举测试，我们将面临以下的问题：
在测试了1+1，1+2,1+（-1）和1+（-2）之后，还是否有必要测试1+3,1+4呢？
如果不对加法计算器程序进行穷举测试，是否放心的认为所有的参数组合都是正确的呢
对于以上两个问题，我们可以采用等价类划分法来进行解决。
①等价类划分的办法就是把程序的输入域划分成若干部分。
②从每个部分中选取少数代表性数据当做测试用例。
③每一类的代表性数据在测试中的作用等价于这一类中的其他值。
④也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误。
⑤繁殖，如果某一类中的例子没有发现错误，则这一等价类中的其他例子也不会发现错误。
①如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。
②如果一个输入条件说明了一个“必须成立”的情况，则可划分一个有效等价类和一个无效等价类。
③如果输入条件规定了输入数据的一组可能的值，而且程序使用不同的方式处理每一种值，则可为每一种值划分一个有效等价类，并划分一个无效等价类。
④如果我们确定，已划分的某等价类中的各元素（例子）在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类。
⑤在确定了等价类之后，建立等价类表，列出所有划分出的等价类。
①明确测试对象，非测试对象保证正确。
②为每个等价类规定一个唯一的编号。
③设计一个测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖。
④设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有的无效等价类均被覆盖。
例子是前面的加法计算机
①一个有效数据等价类，两个无效数据等价类。
有效数据等价类就是：由那些对程序的规格说明有意义的、合理的输入数据所构成的集合。
无效数据等价类就是：那些对程序的规格说明不合理的或无意义的输入数据所构成的集合。
在实际工作中，我们通常在确立了等价类以后，把程序中所有的等价类建立等价类表，一遍在编写测试用例的时候有所依据。
①为等价类表中的每一个等价类分配一个唯一的编号。
②设计一个新的测试用例，使他能够尽量覆盖尚未未覆盖的有效等价类。
③重复这一步骤，从而使所有有效等价类均被测试用例所覆盖。
④与上述类似，设计一个新的测试用例，使它只覆盖一个无效等价类。
⑤重复这一步骤，从而使所有无效等价类均被测试用例所覆盖。
①在测试“-99≤数值99”的这个等价类区间的时候，我们会发现如10+40，-20+30和-30+（-30）这类的正数相加，正数负数相加，负数相加也是不同的等价区间。因此我们可以使用更多的等价类划分。
②根据以上等价类划分的加过，得出下表的等价类表：
根据上面划分的4个等价类，我们至少需要有5个测试用例：
①测试相同的内容。
②如果等价类中的一个测试能够获取一个缺陷，那么选择该等价类中的其他测试也能获取该缺陷。
③如果等价类中的一个测试不能获取缺陷，那么选择该等价类中的其他测试也不能获取缺陷。
④如果正确的花粉都能加了，可以大大降低测试用例的数量，测试会准确有效。
⑤如果错误的将两个不同的等价类当作一个等价类，那就会遗漏一种测试情况。
⑥相反的，把同一个等价类看作了两个不同的等价类，那么测试就会是冗余的。
①不但要考虑有效等价类，也要考虑无效等价类。
②仔细划分，审查划分。
③过于粗略可能会漏掉软件缺陷。
⑤组织评审。
①余额宝体现到yhk增加新规则：快速到账（2小时）日限额1W元。
②超过1W元只能选择普通到账。
③按照等价类划分方法设计测试用例。
①设计用例：
②细致分析需求，日限额1W,所以要区分两个场景：
边界值分析法是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类便捷的测试用例。
实践证明，在设计测试用例时，对边界附近的处理必给予足够的重视，为检验便捷附近的处理专门设计测试用例，常常去的良好的测试效果。
边界值分析法不仅重视输入条件边界，而且也从输出域导出测试用例。
如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例。
eg1:以a和b为边界，测试用例应当包含a和b以及略大于a和略小于b的值。
eg2:根据以上计算器的例子，根据边界值分析的方法来看看如何对边界值进行测试：
由于允许输入的额数值在-99到99之间，所以我们可以把-99和99看做两个边界值。我们测试的时候可以去临近边界值的数值和边界值本身作为输入：
eg3:余额宝体现到一囊卡增加新规则：快速到账（2小时）日限额1W元：
等价类划分法和边界值分析方法都是着重考虑输入条件而不考虑输入条件的个各种组合、输入条件之间的相互制约关系。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字；因此必须考虑采用一种适合于描述多种条件的组合、产生多个相应动作的测试方法，这就需要利用因果图（逻辑模型）。
因果图法基于这样的思想：一些程序的功能可以用决策表的形式来表示，并根据输入条件的组合情况规定相应的 *** 作；因此，可以考虑为决策表中的每一列设计一个测试用例，以便测试程序早输入条件的某种组合下的输出是否正确。
概括的说，因果图方法就是从程序规格说明书的描述中找出因（输入条件）和果（输出结果或程序状态的改变）。将因果图转换为判定表，为决策表中的每一列设计一个测试用例。这种方法考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。
判定表（Decision Table）是分析和表达多逻辑条件下执行不同 *** 作的工具。是编写程序的辅助工具，可以把复杂的逻辑关系和多种条件组合的情况表达得及具体又明确。
判定表通常由四个部分组成：
①条件桩（Condition Stub）:列出了问题的所有条件，通常认为列出的条件的次序无关紧要。
②动作桩（Action Stub）：列出了问题规定可能采取的 *** 作，这些 *** 作的排列顺序没有约束。
③条件项（Confition Entry）:列出针对它左列条件的取值，在所有可能情况下的真假值。
④动作项（Action Entry ）:列出在条件项的各种取值取值情况下应该采取的动作。
①分析软件规格说明中哪些是原因（即输入条件或输出条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
②分析软件规格说明中语义的内容，找出原因与结果之间、原因与原因之间的对应关系，根据这些关系画出因果图。
③由于语法或环境的限制，有些原因和原因之间、原因和结果之间的组合情况不可能出现。为表名这些特定的情况，在因果图上使用一些记号表名约束或限制条件。
④把因果图转换为判定表。
⑤根据判定表中的每一列设计测试用例。
eg:使用因果图+判定表设计测试用例测试两位数计算器。
①输入1： ②输入2：
条件1：0≤X≤99 条件1：0≤X≤99
条件2：-99≤X<0 条件2：-99≤X<0
条件3：X<-99 条件3：X<-99
条件4：X>99 条件4：X>99
输出：
正确计算
错误提示
输入1：
1、2、3、4互斥
输入2：
1、2、3、4互斥
输出：
输出结果正确和错误互斥
得到的测试用例：
正交实验设计法（Orthogonal experimental design）,是从大量的试验点中挑选出适量的、有代表性的点，应用依据伽罗卡瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法。
1、提取功能说明，构造因子—状态表
2、加权筛选，生成因素分析表
计算个因子和状态的权值，删去一部分权值较小，即重要性比较小的因子或状态，使最后生成的测试用例集缩减到允许的范围。
3、利用正交表构造测试数据集
① 如果每个因子的状态树是不统一的，几乎不可能出现均匀的情况，必须首先用逻辑命令来组织个因子的状态，作出布尔图。
②根据布尔图得到相应结束的正交表。
③依照因果图上根节点到叶子节点的顺序逐步替换正交表上的中间节点，得到最终的正交表。
4、利用正交表每行数据构造测试用例
正交表：
正交表的表示形式：Ln（t^c）其中：L为正交表的代号，n为行数（试验行数），t为水平数，c为列数（因素数）。
eg：L4（2^3），它表示需做四次实验，最多可观察3个因素，每个因素均为2水平：
1：正确
2：错误
eg：一个正交表中也可以割裂的水平数不相等，我们称它为混合型正交表，如L8(2^4 4^1）：
根据正交表的数据结构可以看出吧，正交表是一个n行c列的表，其中第j行由数码1,2，tj组成，这些数码均各出现n/t次。
第二列的数码个数为2，t=2，即由1、组成，各数码均出现2次。
1、Technical Support (supportsaacom)
>
一、等价类划分法
所谓「等价」，就是具有相同属性或者方法的集合，这个集合中某个个体所表现的特征与其他个体完全一致。
由此可知，等价类划分就是将所有可能的输入数据，划分成若干个等价类，然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，分为有效等价类和无效等价类。
例如，规定的用户名长度区间为4～8个字，那么它的有效等价类是用户名长度在[4,8]，无效等价类为用户名长度大于8位，或用户名长度小于4位。
二、边界值
测试经验告诉我们，在测试有时会涉及到大量的数据，遍历所有数据会使测试效率低下，如果是手工执行，更加难以覆盖所有数据。这时更有效率的做法是，先划分等价类，再从等价类中选择部分参数测试，边界值是等价类所有可选参数中最容易出问题的地方，所以我们一般会选择边界值作为测试的重点，边界值法的应用步骤如下：
1先根据等价类法划分有效等价类和无效等价类，确定上点、离点及内点。上点是边界上的点，离点是离上点最近的点，内点则是边界有效范围内的任意一点。同样以用户名长度为4～8位为例，4和8为上点，3和9为离点，6则为内点。
2设计一个新的测试用例，使其尽可能地覆盖所有尚未覆盖的有效等价类，直到所有有效等价类完全覆盖。
3设计一个新的测试用例，使其仅覆盖一个无效等价类，直到所有无效等价类都被覆盖。
三、判定表法
判定表又称策略表、决策表，能表示输入条件的组合，以及与每一输入组合对应的动作组合。判定表法适合逻辑判断比较复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，具体又明确地表达复杂地逻辑关系和多种条件组合情况。
判定表主要由条件桩和动作桩两部分组成。条件桩是功能要满足地所有条件，动作桩则是所有可能的 *** 作以及产生的结果。
判定表能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。其缺点是判定表的建立过程较烦杂，当条件过多时，需要分析的逻辑组合呈2的倍数增长。测试工程师可根据实际情况与等价类划分法、边界值法结合使用。
四、正交试验法
正交试验法是研究多因素、多水平组合的一种实验法，它是利用正交表来对实验进行设计，通过少数的实验替代全面实验。正交表中所有参与试验的、影响试验结果的条件成为因子，影响试验因子的取值或输入的成为水平。
在设计测试用例时，采用正交试验法能够有效地、合理地减少测试的工作量与和成本。正交试验的一般流程包括以下几个步骤：
1）分析测试需求，获取因子和水平
2）根据因子和水平选择合适的正交表
3）替换正交表中的因子和水平，获取试验次数
4）根据经验或者其他因素补充试验次数
5）细化输出获得测试用例
以上是一些常见的测试用例设计方法，希望能够解答你的问题。
黑盒测试，设计用例的方法主要有：等价类划分、边界值设计、经验设计、正向和逆向测试设计等等，按不同的项目，还有不同的设计，比如汽车电子测试中需要场景分析测试，服务器测试中，还有性能和压力测试等。欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）