标签：测试点 功能测试 用例 测试用例 测试 条件 软件测试
功能测试
1、软件测试的定义：
1.1认识软件及测试
1、什么是软件：控制计算机硬件工作的工具
2、软件基本组成：客户端、服务器、数据库
3、软件产生过程：需求产生->需求文档->设计效果图（UI设计师）
->产品开发->产品测试（看与需求文档是否一致）
4、什么是软件测试：使用技术手段验证软件是否满足用户需求
5、软件测试的目的： 发现软件中的错误，减少软件测试的缺陷。
1.2测试主流技能
1、功能测试：验证程序的功能是否满足需求
2、自动化测试：使用工具或代码代替手工，对项目进行测试
3、接口测试：使用代码或工具对服务端提供的接口进行测试
4、性能测试：模拟多人使用软件，查找服务器的缺陷。
1.3就业方向如何选择
1、功能测试+接口测试
2、功能测试+性能测试
3、功能测试+web自动化测试
1.4常见的测试分类（7种测试用例）
1、按阶段划分
单元测试：争对程序源代码进行测试
集成测试：又称接口测试，针对模块之间的访问地址进行测试（争对接口）
系统测试：对整个系统包括功能、兼容、文档等测试
验收测试：主要分为内测、公测，使用不同任人群来发掘项目缺陷
2、按代码可见度划分
黑盒测试（系统测试）：源代码不可见、UI功能可见
灰盒测试:(集成测试、接口测试)部分源代码可见。功能不可见
白盒测试：（单元测试）全部代码可见，功能不可见
专项：
性能测试
安全测试
注：UI：User Interface
1.5测试模型（质量模型的重点五项）
质量模型： 功能性、性能性、兼容性（浏览器，操作系统，其他软件）、易用性、安全性、可靠性（无响应，卡顿，死机）、可移植性、可维护性
1.6软件测试流程（6个步骤）
1、需求评审：各部门需求理解一致、知道有哪些功能（产品经历、开发人员、测试人员）
2、计划编写：测什么、谁来测、怎么测（功能、性能）
3、用例设计：验证项目是否符合需求的操作文档
4、用例执行：项目模块开发完开始执行用例文档实施测试
5、缺陷管理：对缺陷进行管理的过程
6、测试报告：实施测试结果文档
1.7测试用例
什么是用例：用户使用的案例
什么是测试用例：为测试项目而设计的执行文档
测试用例的作用：防止漏测、实施测试的标准
用例设计编写格式：（用例执行的八大要素）
1、用例编号：项目_模块_编号
2、用例标题：期望结果（测试点）
3、项目：所属项目模块
4、优先级：表示用例重要程度P0~P4（P0最高）
核心功能：用户使用频率最高的功能
5、前置条件：要执行此条用例，有哪些前置操作
6、测试步骤：描述操作步骤（可以简化操作步骤）
7、测试数据：操作的数据，没有可以为空
8、预期结果：期望达到的结果+不同角色隐形结果（卖家、买家、平台）
例：QQ登录
1. 能对穷举场景设计测试点：
测试点：要验证的点
实现：等价类划分法
说明：在所有的测试数据中具有某种特征数据的集合进行划分（性别、年龄）
分类：（找到代表）
有效等价类：满足需求的数据集合
无效等价类：不满足需求的数据集合
步骤：
1、明确需求（长度、类型、规则）
2、确定有效和无效
3、提取数据编写测试用例
例1：qq合法性
长度类型验证
步骤：
例2：
电话：
等价类适用场景
针对：需要有大量数据测试输入，但是没法穷举测试的地方
输入框
下拉列表
单选复选框
典型代表：页面的输入框类测试
总结：先正向，再逆向，完整的用例应该是等价类和边界值一起写
2、能对限定边界规则设计测试点（例6-8位）
实现：边界值分析法
注：使用边界值解决边界位数限制问题，不能解决类型问题，要结合等价类
1、边界范围节点（有关范围限制，最多7条用例）
选取正好等于、刚好大于、刚好小于边界的值作为测试数据
上点：边界上的点（正好等于2）
离点：距离上点最近的点（刚好小于、大于4）
内点：范围内的点（区间范围内的点1）
2、边界值法设计用例需求：
1、明确需求
2、确定有效和无效等价类（考虑类型）
3、确定边界范围值
4、提取数据编写测试用例
例：
1、明确需求
通过边界值法验证标题长度的合法性
标题长度大于0小于等于30个字符
4、提取数据编写用例
例2：
1、明确需求
通过边界值验证qq号码的合法性
6-10位自然数
2、确定有效和无效等价类
3、确定边界范围值
4、提取数据编写 用例
结论：
1、7个优化为5个点
2、上点和内点必选
3、离点 开内闭外（开区间选包含的点，闭区间选不包含的点）
使用场景
注：单个输入框，常用的方式 边界+等价
最常用的用例方法：等价类，边界值
1、在等价类的基础上针对有边界范围的测试数据输入的地方
2、常见词语描述：大小，尺寸，重量，最大，最小，至多，至少等修饰词语
3、典型代表：有边界范围的输入框类测试
3、对多条件依赖关系进行设计测试点
实现：判定表法（输入条件与输出结果之间有相互制约关系的测试）
判定表：一种以表格形式表达多条件逻辑判断工具
组成
条件桩：列出问题中所有条件，次序无关紧要
动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
条件项：列出条件对应的取值，所有可能情况下的真假值
动作项：列出条件项，各种取值情况下应该才取的动作结果
例：验证”若用户欠费或者关机，则不允许被叫“功能测试
规则
判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个（0，1）全组合有2的n次方种规则。
步骤：
1、明确需求
2、画出判定表
1）、列出条件桩和动作桩
2）、填写条件项，对条件进行全组合
3）、根据条件项的组合确定动作项
4）、简化、合并相似规则（有相同动作）
3、根据规则编写测试用例
例：
1、明确需求：
2、画出判定表
3、编写测试用例
判定表使用场景：
1、有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系
2、判定表一般适用于条件组合数量较少的情况（四个条件以下）
提示：
1.多条件之间有依赖关系，使用判定表来进行测试覆盖。
2.判定表一般适合四个以内条件依赖关系
3.条件超过四个，应采用正交法来解决
4、能对项目业务进行设计测试点
实现：场景法
测项目先测业务，基本保证项目能跑通，再测试单功能、单模块
流程图：使用标准图形和箭头来表达程序或业务的走向
提示：业务用例是根据流程图来梳理的，需要先了解流程图
开始，结束：椭圆
判断：菱形
执行语句：圆角长方形
作用：
1.能看懂流程图，设计测试用例
2.当需求文档不全时，能够根据需求，梳理出流程
离线工具：visio、excel
网页版工具：网页画图工具
案例：ATM机
1、需求分析
2、画流程图
3、编写测试用例
错误推荐法
1.定义：通过经验推测系统可能出现的问题
2.思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷
3.场景：
1）时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试
2）实践宽裕通过该方法列出之前出现问题较多的模块再次测试
使用场景：
当项目用例都执行完毕，且BUG修复完毕，离上线还有 一段时间，在这段时间中使用错误推荐法复测主要业务或未覆盖的功能。
面试问题：
当时间少，只有自己时，需要测试如何回答
1、先与产品人员确定哪些时是重要业务
2、再验证主功能 正向和逆向
3、加班
标签：测试点,功能测试,用例,测试用例,测试,条件,软件测试 来源： https://blog.csdn.net/unique_xl/article/details/122606905
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。