义乌公司网站建设,东莞一站式网站推广运营,大连网站制作431,石家庄小学网站建设 文章目录为什么测试人员要写测试用例#xff1f;怎样设计测试用例#xff1f;#xff08;总的方面#xff09;1.基于需求设计测试用例#xff08;总的方面#xff09; 2.页面#xff08;总的方面#xff09; 3.非功能性测试#xff08;具体方面#xff09; 4.1 等… 文章目录为什么测试人员要写测试用例怎样设计测试用例总的方面1.基于需求设计测试用例总的方面 2.页面总的方面 3.非功能性测试具体方面 4.1 等价类解决穷举问题具体方面 4.2 边界值法解决边界限制问题具体方面4.3使用多条件依赖问题具体方面 4.4 解决业务测试点覆盖问题具体方面 4.5 错误猜测法练习测试分类介绍(除功能测试之外)1.按照是否查看代码划分2. 按照开发阶段划分3.按照实施组织划分4.按照代码是否运行划分5. 按照是否手工划分6. 按照地域划分Bug1.衡量是否为缺陷的标准2.缺陷产生的原因3.缺陷描述的核心内容4.提交Bug的要素5.缺陷类型6.如何区分是前端Bug还是后端Bug7.管理Bug的工具8.使用execl管理Bug什么是测试用例测试用例是向被测试系统发起的一组集合也就是执行测试的文档。
测试用例书写的八大要素
1.测试编号项目模块编号
2.用例标题预期结果操作步骤
3.模块/项目所属项目或模块
4.前置条件要执行此条用例有哪些前置操作
5.优先级表示用例的重要性或者影响力P0 ~ P4(P0最高)
6.测试步骤描述测试步骤
7.测试数据:操作的数据没有话可以为空
8.预期结果期望达到的结果为什么测试人员要写测试用例
测试用例是测试执行的依据。测试用例可以复用在进行回归测试的时候不用重新编写用例。测试用例可以衡量需求的覆盖率后人可以借鉴手工测试用例是自动化测试的依据防止漏测实时测试的标准
怎样设计测试用例
总的方面1.基于需求设计测试用例
需求是测试人员进行测试的依据测试人员分析需求验证需求的正确性和合理性无二义性。从需求当中提取测试项。根据测试项进行进一步的细分提取测试点编写测试用例
从界面开始进行测试(符合UI设计稿和原型图)验证软件的功能把业务相关的功能串起来进行测试不能光关注每一个孤立的功能一个功能不同的输入和相应的不同的输出功能之间的交互性同一个系统不同的角色之间的交互异常功能的测试功能用到的算法验证从易用性兼容性等几个方面考虑
那么最终总结出来一种模型质量模型
针对任何的软件和硬件测试要覆盖的方面
功能性兼容性可靠性可维护性性能效率易用性信息安全可移植性
重点功能兼容性能易用安全
总的方面 2.页面
从上到下从左到右依次去分析碰到的测试点
总的方面 3.非功能性测试
易用性兼容性性能安全可移植性可靠性可维护性非功能性测试就是测试在软件本身有的功能之上做的一些限制。
具体方面 4.1 等价类解决穷举问题 方法使用等价类实现 如果此时让我们对这个QQ登录写出测试用例。那么我们应该首先想到的就是找到一些数据填写账号和密码。那么如果此时有大量的测试数据我们要一个一个的测试吗
其实不然我们要对这些测试数据做出分类那么我们在每个分类中选出一两个此时数据填写到账号栏和密码栏验证QQ 登录即可。
这就相当于我们在衣柜中把春夏秋冬的衣服归类一样。
分类
有效等价类在所有有效数据集合中取一个即可无效等价类在所有无效数据集合中取一个即可
步骤
明确测试需求确定有效和无效等价类提取数据编写测试用例
测试案例 此时有一个登录场景只需要输入QQ号QQ号限定是8位自然数方可登录成功
测试点
测试用例
测试案例
1.区号空或者是三位数字
2.前缀码每0且非1开头的三位数字
3.后缀码 四位数字
合格
确定有效和无效等价类
2个合格测试用例8条不合格测试用例
等价类使用场景
针对需要有大量的数据测试输入当时没法穷举测试的地方
如输入框下拉列表单选复选框
经典代表页面级的输入框类测试
具体方面 4.2 边界值法解决边界限制问题 方法边界值设计方法 所以说我们如果要对这个范围做测试的话那么就要测试 -100 -99 99 100 50
案例一
首先明确需求 标题长度大于0小于等于30个字符
明确有效等价类和无效等价类
有效 大于0小于等于30长度的字符等于0大于30长度的字符
边界值 有效1个30个 无效0个31个
测试用例
使用场景
常见词语描述大小尺寸重量最大最小至多至少等修饰词语
典型代表有边界范围的输入框类测试
**提示**边界值可以覆盖等价类的长度但是无法覆盖类型所以设计用例是必须两者结合
具体方面4.3使用多条件依赖问题 方法判定表法 定义是一种以表格形式表达多条件逻辑判断的工具
组成
条件桩列出问题中的所有条件列出条件次序无关紧要
动作桩列出问题中可能采取的操作操作的排序没有约束
条件项列出条件对应的取值所有可能情况的真假值
动作项列出条件项的个中取值情况下应该采取的动作结果
规则
判定表中贯穿条件项和动作项的一列就是一条规则假设有n个条件每个条件的取值有两个(0,1)全组合有2的n次方中规则
步骤
明确需求画出判定表 列出条件桩和动作桩填写条件项对条件进行全组合根据条件项的组合确定动作项简化合并相似规则(有相同的动作)
3.根据规则编写测试用例
案例一
需求
订购单检查
如果金额大于500有未过期则发出批准单的提货单如果金额大于500但是过期了则不发批准单与提货单如果金额小于等于500则不论是否过期都发出批准单和提货单在过期的情况下不论金额大小还需要发出通知单
画判定表
根据判定表写测试用例
案例二
需求
输入的第一列字符必须是A或B第二列字符必须是一个数字如果第一列字符不正确则给出信息L如果是第二列字符不正确则给出信息M如果两列字符输入正确则修改文件成功
画出判定表
根据判定表写出测试用例
使用场景
有多个输入条件多个输出结果输入条件之间有组合关系输入条件和输出结果之间有依赖关系判定表一般适用于条件组合数量较少的情况(比如4个条件一下)提示如果碰到项目中多条件组合大于4个相互依赖可以用正交法和因果图法来实现
具体方面 4.4 解决业务测试点覆盖问题 那么此时就可以使用场景法就是用我们的流程图来梳理每个条件 根据流程图写测试用例
具体方面 4.5 错误猜测法
定义通常经验推测系统可能出现的问题
思想根据经验列举出可能出现的问题的清单根据清单分析问题可能原因推测发现缺陷。
场景时间紧任务中根据之前项目类似经验找出出错的模块重点测试
时间宽裕通过该方法列出之前问题较多的模块再次测试
就如用户在输入密码的时候在密码的前面和后面都输入了大量的空格等
练习
单模块测试
测试点
测试用例ps 我们这里仅仅对功能测试用例作以描述
测试分类介绍(除功能测试之外)
易用性测试: 软件需求具备简单易上手的属性
安装卸载测试移动端测试很容易一楼掉的此时
安全测试:SQL注入XSS漏洞越权问题
文档测试: 通常来说是在需求评审是测试人员需要进行需求分析(文档测试)
兼容性测试平台兼容不同平台也有版本不同
可靠性测试正常运行的时间 除以 正常运行的时间 非正常运行的时间 * 100 可用性指标一般要求达到4个或者5个9 即 99.99% 或者 99.999%
容错性测试 系统能够处理异常用户的错误操作而不至于系统崩溃从而能够提高系统的可用性。
**性能测试:**性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试
压力测试。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点来获得系统能提供的最大服务级别的测试。
负载测试 通过负载测试确定在各种工作负载下系统的性能目标是测试当负载逐渐增加时系统各项性能指标的变化情况
强度测试 强度测试检查程序对异常情况的抵抗能力是检查系统在极限状态下运行的时候性能下降的幅度是否在允许的范围内。
容量测试 容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值如最大并发用户数、数据库记录数等系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。
1.按照是否查看代码划分 黑盒测试 不去关心代码内部实现的逻辑结构不去查看代码只关心软件功能的外部的输入和输出是否满足用户需求相当于把软件的内部实现给屏蔽掉了。 站在用户的角度设计测试用例容易培养产品思维。设计测试用例是根据软件需求设计的不容易遗漏需求 黑盒测试的方法等价类边界值场景法判定表法因果图法错误猜测法正交法。 白盒测试 查看代码是否规范代码风格是否和公司设计一致分析代码的逻辑结构对代码进行测试看代码是否实现了需求 我们通常说的单元测试就是白盒测试的一种这个通常是由开发人员实施的。 白盒测试的方法语句覆盖路径覆盖逻辑覆盖判定覆盖条件覆盖判定组合覆盖判定和条件组合 覆盖条件和条件组合覆盖 路径覆盖有if else switch case try catch finally 等价类边界值 灰盒测试 即关心软件功能的输入和输出也关心软件内部程序的实现。
2. 按照开发阶段划分 特点越往底层走测试效率越高越往低走定位问题越容易越往底层走测试独立性越高耦合性变低。
单元测试阶段 指的是对软件组成的最小单元进行测试
集成测试阶段 按照一定的逻辑和策略把单元模块组合在一起形成一个具体完整功能的大模块
测试阶段 单元测试测试方法 灰盒测试测试人员 黑盒测试工程师白盒测试工程师测试依据 概要设计文档测试内容 模块功能的正确性组成模块的单元之间的接口测试全局数据结构测试单个模块的功能缺陷对整个模块的影响。
系统测试阶段 对软件系统进行全面的功能的非功能测试
测试阶段集成测试以后测试对象整个软件系统测试方法黑盒测试测试人员黑盒测试工程师测试依据:需求设计文档测试内容系统的功能界面可靠性容错性易用性可移植性兼容性安全性性能安装卸载
这里我们有必要说明一下冒烟测试冒烟测试是由测试人员来执行检验系统只要功能和主要流程是否正常评估软件系统是否具备可测试条件可测试标准。
回归测试:当系统引入新代码的时候测试人员往往需要验证新的代码对旧的功能的影响。
验收测试: 软件在上线之前最后一次的测试也称为交付测试
测试阶段系统测试之后测试对象整个软件系统测试依据用户需求测试人员用户测试方法黑盒测试测试内容同系统测试文档测试可用性分析文档需求设计文档软件设计文档软件开发文档功能手册
3.按照实施组织划分
α测试: 在β测试之前把用户或者非测试和开发的人青岛开发现进行检测
测试环境开发现场测试人员非开发和测试的人
β测试 让实际用户在实际使用环境中进行测试测试完成之后对问题进行同一汇总反馈
α测试和β测试的区别测试环境不同测试时间集中长度不同α测试优先于β测试
第三方测试 是软件第三方测评机构按照软件行业的标准规范对软件进行测试
4.按照代码是否运行划分
静态测试 不运行代码通过检查代码风格格式是否符合公司标准规范检查代码的逻辑结构是否满足需求要实现的功能。
动态测试: 运行代码给程序响应的输入看是否得到期待的结果。
5. 按照是否手工划分
手工测试 按照测试用例手工去测试系统的功能
缺点量大容易出错效率低有些极端情况无法测试到优点进行探索性测试比较灵活
自动化测试 把手工测试用例转化为自动化测试机器按照人的设定好预设条件运行这些预设包括正常的异常的去检查软件系统有没有符合设定的条件。
6. 按照地域划分
软件国际化 进行软件设计和开发的时候使用一种工程技术使得软件在转化为不同的国家语言的时候可以不用修改源码适应不同的语言不同国家人民的风俗习惯
国际化软件测试外观上开界面功能没缺失正常使用是否适应这个国家人的使用习惯文字日期度量单位货币不同分辨率下软件的正常使用
软件本地化 具体到每个国家
Bug
1.衡量是否为缺陷的标准
和需求规格说明书上不符。这里是少功能功能实现错误多功能隐形功能错误不易使用
2.缺陷产生的原因
需求阶段需求描述不易理解有分歧错误等。设计阶段设计文档存在错误或者缺陷编码阶段代码出现错误运行阶段软硬件系统本身故障导致软件运行失败
3.缺陷描述的核心内容
缺陷的标题描述缺陷的核心问题缺陷的预置条件缺陷产生的前提缺陷的复现步骤复现缺陷的过程缺陷的预期结果希望得到的结果缺陷的实际结果实际得到的结果缺陷的必要附件图片日志等信息(证据)
4.提交Bug的要素
缺陷报告编号 缺陷的唯一性标志严重程度严重(主功能)一般(次要功能)微小(易用性界面)建议(建议性问题)缺陷优先级 Priority24小时内解决 Priority1发布前必须修复。Prioity2可以在写一个版本修复Bug类型 代码错误兼容性错误设计缺陷性能问题缺陷状态 New 新建 Open 打开 Closed 关闭 Postponed 延期
5.缺陷类型
功能缺陷界面错误兼容新数据易用性改进建议架构
6.如何区分是前端Bug还是后端Bug
在写的web项目仅设计到前端代码和后端代码在测试的时候发现有个字段展示的数据不正确首先通过在页面上使用F12开发者工具查看接口的请求参数和返回值是否正确当时发现接口返回值是正确的所以判定是前端代码写的有问题。如果是接口返回值就是错误的那可能是代码逻辑出现了问题需要对后端代码进行调试。
7.管理Bug的工具
这里我们可以通过禅道和jire 进行Bug管理 https://78945.chandao.net/
8.使用execl管理Bug
在这里我们使用execl表格对Bug进行管理
现在利用的是我们以上的测试用例执行相关程序之后得到的对缺陷的描述
