标签：需求 定义 等价 功能测试 用例 测试用例 测试 输入
-------------软件测试是什么-----
依据需求熟悉业务，确定测试范围，设计测试用例，等开发完成后，用手动或自动化执行被测软件，检测预期和实际结果是否一致，如不一致提交BUG，再次交给开发修改，开发修改完成后，执行回归测试，所有用例执行完成后，交给客户做验收测试
这个面试题给一个水杯如何测试一样，
-------------测试用例------------对某一个功能点怎么设计用例（怎么进行用例设计）
一：查找需求说明、网站设计等相关文档，分析测试需求。
1、测试需求分析
-
1.1、测试需求来源：开发需求DR；协议标准需求PR；用户需求UR；案例库需求LR；竞争需求CR；继承需求SR；
-
1.2、针对需求了解：1软件主要流程是什么，2分析次要流程。3剩下的细节功能
-
1.3、可以使用xmind列大纲和测试点，进行功能点拆分。
-
1.4、为什么要进行需求评审：梳理业务需求，所有人对这个需求的认知不易一致。
2、测试项细化，需求细化、分析步骤
-
2.1、质量模型分析方面：功能测试项，效率测试项，可靠性，易用性，可维护性，可移植性
-
2.2、用户场景分析方面：游客，普通用户，VIP用户，管理员用户，权限不同，测试点不同
-
2.3、继承性分析方面：新增功能，继承旧功能，新旧功能之间关系，影像程度高低
-
2.4、功能交互分析方面：功能点与功能点之间，时序（并行，串行），主被动
3、划分测试优先级
4、测试设计：测试不能穷举，根据一些设计方法去选取一些数据尽量覆盖多个测试点
二：制定测试计划，确定测试范围和测试策略。
1、测试计划是什么
它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。1分析测试时间节点，什么节点交付什么，例如：1用例编写完成时间，评审时间，2冒烟时间，根据用例大纲 3首轮测试验收时间4首轮bug回归时间。5复测第二轮时间，6尾轮测试时间。
①根据测试计划做宏观调控，进行相应的资源配置，宏观反映项目的测试任务，测试类型（功能测试、性能测试）、测试阶段（单元测试，系统测试，集成测试），资源需求，不一定很详细，也不是一成不变的，这里稍微包含测试范围
②测试人员能够了解整个项目测试情况，以及项目测试不同阶段所要进行的工作等
③便于其他人员了解测试人员的工作内容，进行有关配合工作
测试需求分析前进行总体测试计划书-------测试需求分析后详细测试计划书
经验丰富的项目负责人
1）why——为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
1.分析测试时间节点，什么节点交付什么，
1.1 用例编写完成时间，评审时间，
1.2 冒烟时间，根据用例大纲
1.3 首轮测试验收时间
1.4 首轮bug回归时间。
1.5 复测第二轮时间，
1.6 尾轮测试时间
1.7 测试报告
1.8 线上验收
2.投入人员
3.验收测试标准（ 】
2、测试策略是什么
是一个宏观的方案：采取什么工具、做什么流程、做那儿些输出等。简单来说就是测试中总体方法和目标，进行那一阶段的测试（单元测试、集成测试、系统测试），以及那个阶段进行那种测试种类（功能测试、性能测试、覆盖测试等）。可以分成3个方面：
①确定测试过程中要使用的技术和工具②制定测试启动，停止，完成标准③进行风险分析和对应方案， 例如测试与外部接口或者模拟物理损坏、安全性威胁。
选择测试方法 测试方法列表
选择测试工具 测试工具列表
选择测试平台 测试平台列表
选择自动化测试策略和平台 自动化测试策略书
编写测试策略和文档 测试测试书
2.2.1、测试级别：常见的测试级别是单元测试，集成测试和系统测试，大部分的测试组织里面，单元测试有开发负责，而集成测试和系统测试有测试部门或者质量保证部门负责
2.2.2、角色和职责：需要在测试策略里面明确定义各个角色，以及该角色的职责。比如项目经理，项目测试工程师
2.2.3、环境需求：描述测试时需要需要的系统环境，包含软硬件以及网络环境，在澄清环境需求时，测试组织可识别资源方面风险
2.2.4、风险分析：影响测试过程中的风险应该尽早识别，必须有相应的解决方法以便于消除或减轻这些风险
2.2.5、测试进度：评估测试完成所需要的时间。在设定进度时，首先明确测试范围，然后根据测试资源的多少来制定能被各方面认可的测试进度计划。 做一个非常准确的进度计划是困难的事情，因为测试过程中充满了各种不确定性，所以一般计划者需要考虑增加一定的buffer。当然，制定进度计划的时候可以参考已有的项目的数据。如果是一个全新的软件项目，专家认为将初始计划的时间翻倍比较靠谱！
2.2.6、回归测试方法：回归测试用来保证之前 fix bug的代码不会影响软件的其他部分，这样需要我们选择已执行过的用例重新运行。 测试人员需要找到一个方法来确定哪些测试用例应该在回归测试中运行，用例不能太多，因为资源有限，用例也不能太少，否则会达不到必须的测试强度。不过，如果测试部门对待测系统以及软件架构非常了解的话，就比较容易找到合适的回归测试集合
2.2.7、测试范围：要测的内容，模块，某些指标，比如功能、性能、易用
2.2.8、测试优先级：测试范围内的东西不是一样重要的，资源有限，需要排优先级
三：设计测试用例，包括功能、兼容、性能、安全等方面
1、用例设计概括
正向逆向，边界的 场景分析。 用了哪些测试方法，。 颗粒度，。 1确定用例编写颗粒度，细致程度，验收标准，进行 满足需求原定需求，点击跳转，移入显示。 2pict用例场景设计工具。 拆分出来，对于输入框的检验，对于按钮的检验，3用例编写的设计，正向用例，逆向用例，场景用例，冒烟的过程中
2、如何做用例设计
-
2.1.用例分析：跟进领导/产品说的验收颗粒度，进行设计用例需要编写到什么程度（验收颗粒度细了，写的就细点）
-
2.2.用例设计
2.2.1.正向用例设计: 优先满足需求设计重点需求点
2.2.2.反向用例设计: 用例编写方法扩展用例
-
2.3.用例执行：跟进编写好的用例按优先级执行（一般会从正向用例评审出来优先级为1的用例）
3、提取测试点
-
1. 检查页面元素是否齐全2. 输入正确or错误的用户名进行验证3. 输入正确or错误的邮箱进行验证4. 输入正确or错误密码进行验证5. 验证密码强度显示是否正确6. 输入正确or错误的确认密码7. 验证下拉框内容是否正确以及能否正常选择8. 输入正确or错误的下拉框答案9. 复选框能正常选择or取消10. 用户协议连接跳转是否正常11. 注册按钮正确性12. 密码与确认密码的约束关系
-
用例示范：
有效规则：6-18位、以字母开头、由字母或数字、下划线
无效规则：小于6位、大于18位、不以字母开头、含有其他字符
4、科学测试设计（黑盒测试用例测试设计）
4.1、等价类划分：
-
4.1.1、概念：将输入输出分成若干个子集，从中选取代表数据，如果被选取的数据测试没问题，就认为未被选取的数据测试也没问题
-
4.1.2、相关术语：有效等价类/无效等价类，（针对输入的数据是否有意义，是否合法，是否正确）输入参数含有有效与无效规则
-
4.1.3、原则：
4.1.3.1、若输入（输出）是一个取值范围或者值的个数，则划分一个有效等价类，两个无效等价类
4.1.3.2、若输入（输出）是一个有限的集合或者必须如何的条件或布尔值，则划分成一个有效等价类和一个无效等价类
4.1.3.3、若输入（输出）已经划分好有效等价类和无效等价类，针对有效等价类具体的值有不同的处理结果和方式，则划分成多个有效等价类和一个无效等价类
4.1.3.4、若输入（输出）要同时满足多个条件，则划分成一个有效等价类和多个无效等价类（从不同角度违反规则）
将SRS划分成规格片段->找出输出条件->进行等价类划分->给划分每一个等价类编号->选代表数据设计用例->直到所有等价类都被覆盖（罗列出所有有效和无效规则；构造测试数据）
有效测试数据尽可能符合有效规则已减少亢余用例&&无效测试数据只能符合一条无效规则
（一条测试用例要尽量覆盖多个有效等价类&&一个测试用例只覆盖一个无效等价类）
4.2、边界值分析
-
4.2.1、概念：边界值分析法是对等价类划分法的一种补充，大量的经验数据表名，边界是问题多发区，如果边界测试没问题，就认为内部数据发生概率较小
-
4.2.2、相关术语：输入参数所在区间，上点->边界上的点；内点->边界内任意点OR区间中心点；离点->离边界最近的点（闭区间，离点在边界外，开区间，离点在边界内）
-
4.2.3、原则：
4.2.3.1、如果输入（输出）是一个取值范围或者值的个数，则以边界或者边界附近的值作为测试用例数据选取；
4.2.3.2、如果输入（输出）是一个有序的集合，则以第一个元素和最后一个元素作为测试用例数据选取；
4.2.3.3、如果输入（输出）的值的个数是一个取值范围，则以最大值；最大值+1；最小值；最小值-1作为测试用例数据选取；
4.2.3.4、如果是一个内部数据结构，则以极限值作为测试用例数据选取；
将SRS划分为规格片段->找出输入条件->进行等价类划分->给划分每一个等价类编号->分析每个数据类型，判断是否有边界值->生成用例
只有等价类和边界值才能生成最终测试用例，其他测试设计方法的生成都是测试规则或者测试路径（逻辑测试）
4.3、判定表
-
4.3.1、概念： 分析和表达多种输入条件进行不同组合来完成不同动作的一种工具，目的是分析复杂逻辑关系的条件组合；（ 输入参数之间有约束关系且不同的逻辑组合会输出不同结果。）
-
4.3.2、相关术语： 条件桩（输入），条件项（输入的取值情况），动作桩（输出），动作项（输出的取值情况）
-
4.3.3、原则：
-
4.3.4、步骤：
将SRS划分成规格片段→找出条件桩、条件项，动作桩，动作项→对条件项进行排列组合生成规则数→合并化简→设计最终用例；
1把输入参考数据转化为条件桩；2把输出结果转化为动作桩；3开减2n个条件项（N为条件桩的个数）；4画表，一列为一条格式用例
a. 弥补了等价类不考虑组合的情况；
b. 是一种全排列组合情况，测试较全面；
c. 测试规则数目庞大，测试用例数量庞大，导致测试工作量大；
d. 合并有风险，化简需谨慎；
e. 能发现需求规格说明书中不符合逻辑的需求；
f. 对于逻辑关系比较复杂的需求无法胜任；
4.4、因果图
-
4.4.1、概念： 将复杂逻辑关系的需求转化为判定表的一种中间系统化方法。目的是为了得到判定表；
-
4.4.2、相关术语： 因（条件），果（动作）；
-
4.4.3、原则：
a.因果之间：恒等/非/与/或；
b.原因之间：E（排斥：最多一个为真）、I（包容：至少一个为真）、O（唯一：有且只有一个为真）、R（要求：a为真，b需为真）、 M（强制：a为真，b需为假）
中间节点： 当多个输入之间的关系不是单纯一种与，或的关系，利用中间节点存取中间结果；
当多个输入都在描述同一件事情的时候，可以利用中间节点归并逻辑；
将SRS划分成规格片段→分析原因和结果→画因果图→判断制约关系→生成判定表→合并删除→设计用例
a. 弥补了等价类不考虑组合的情况；
b. 是一种全排列组合的测试方法，测试的比较全面；
c. 测试规则数目庞大，测试用例数量庞大，导致测试工作量大；
d. 能发现需求规格说明书中不符合逻辑的需求；
e. 能够分析复杂逻辑关系的需求；
f. 制约关系可以快速删减不符合逻辑的规则，从而提高测试设计效率；
4.5、正交实验法
-
4.5.1、概念： 利用正交表进行试验的一种方法，是一种两两组合的方法，经验表明，如果两两组合测试没有问题就认为其他组合发生问题的概率较小。（ 两两组合；直接套用；经济高效；
-
4.5.2、相关术语： 因子（输入）、状态（水平：输入的取值）
-
4.5.3、原则：
-
4.5.4、步骤：
将SRS划分成规格片段→找出因子和状态→构造因子状态表→加权筛选→套用正交表→对生成的组合进行增删→设计用例
输入参数间无约束关系。不同的逻辑组合会输出不同的结果。输入参数均为必填
-
4.5.5、方法规则： 适用范围：功能测试，配置测试
4.6、状态迁移图
-
4.6.1、概念： 针对有限状态机的状态和合法的跳转条件进行测试，目的是为了测试所有的状态能够按照正确的条件进行跳转和迁移。不要有未覆盖到的状态和非法的跳转； 点到点，内部路径不可循环）
-
4.6.2、相关术语： 状态（某个时间点或某个指令后的表现）；跳转条件（操作/指令）；事件（输出）
-
4.6.3、原则：
-
4.6.4、步骤：
将SRS划分成规格片段→找出状态和跳转条件→设定初始状态，画状态迁移图→事件转换表→状态转换树→测试路径→添加非法路径→设计用例
-
4.6.5、方法规则： 有限状态机： web网页，嵌入式系统
4.7、流程分析法
-
4.7.1、概念： 针对整个软件系统的业务流程进行分析测试的一种方法，这种方法借鉴了 白盒测试中的语句覆盖测试法；（一个场景的实现需要多个页面跳转完成） 端到端，内部路径可循环
-
4.7.2、相关术语： 节点（某个功能点），箭线（功能点之间的连接路线）
-
4.7.3、原则：
-
4.7.4、步骤：
分析SRS→找到主要功能点→画出主干图（基本流）→细化分支→进行路径组合确定优先级
4.7.4.1、分析需求，画出业务流程图
4.7.4.2、找出基本路径，个数为判定框个数+1
4.7.4.3、一条基本路径就是一条测试用例
4.8、输入域覆盖法
主要有三点内容：中间值测试（相当于内点），极端值测试（边界中的上点），特殊值测试（业务相关，根据软件功能）
4.9、输出域覆盖法
分析输出的等价类和边界值，达到输出域等价类覆盖和输出域边界值覆盖，使用此测试方法需要对系统的功能有特别深入的了解，采用该方法的一般来说是行业内的专家；
4.10、 异常分析法
对系统有可能存在异常的操作进行测试，主要针对系统的容错能力，故障恢复能力进行测试；
4.11、 错误猜测法
基于经验和直觉推断程序中可能出现的问题，进而针对性地设计测试用例。（ 基于经验的测试法，是对其他测试方法的补充，不单独使用）
5、 Web测试策略汇总
四、开展测试执行
1、执行测试用例
-
1.1、在测试环境进行全功能用例，提交BUG，跟踪修复，有时间进行压力测试
-
1.2、在测试环境中没有严重BUG下，再线上环境执行全功能测试用例，提交BUG，跟踪修复，有时间进行压力测试
-
1.3、性能测试，兼容测试，压力测试，异常测试，安装或卸载
-
1.4、交叉测试，灰度测试
：∂测试（内侧）ß测试（公测）
2、三轮系统验收标准：
1.1）首轮测试：
a. 开始首轮测试的前提：开发自测通过，测试环境构建ok（通常在冒烟测试之后，特殊情况可和冒烟测试并行跟进）
b. 首轮需要验证的内容：完全按照编写好的用例执行测试；
c. 首轮测试通过原则：用例全部可执行完成
①如主模块有bug但不影响子模块的用例执行，视为首轮测试通过，但有bug需修复；
②如主模块有阻碍性bug，导致无法继续往下跑，则视为当前模块首轮测试不通过；
③如联动模块有阻碍性bug，导致当前模块无法继续跑的，则视为当前模块首轮测试不通过（联动模块可根据实际情况在另外判断是父模块不通过，还是子模块不通过）；d. 首轮测试驳回原则：
①被测系统的主要功能模块测试不通过，进行整体版本驳回测试；
②被测系统的主要功能模块测试通过，非主要功能模块测试不通过的较多，则进行部分模块暂停测试，
1.2）首轮回归：
a. 开始首轮回归的前提：首轮测试全部完成（阻碍性bug不计算在内，如与）
对一轮修复的bug进行回归，经常和二轮测试并行开展；2）中轮扩展测试：又称细节测试或扩展测试 ，此阶段也是系统测试周期中耗时最长的一个阶段，期间包含多轮跑系统，直至整体功能稳定，中伦验证才会认为通过；
开始尾轮验证的前提：是需要把确定好需要修复的已知bug全部关闭后方可进入尾轮验收；
开始尾轮验证的环境准备：需要把整体系统（代码+数据库结构）还原到master的状态、然后走模拟上线验证
五：回归测试及测试总结。
1、测试报告
人员
测试环境说明
测试过程：
BUG统计：BUG总数、解决数、BUG分解。
标签：需求,
定义,
等价,
功能测试,
用例,
测试用例,
测试,
输入
From： https://www.cnblogs.com/liuruimiku/p/17896334.html