目录
1.软件测试基本概念
软件测试流程:
1.获取测试需求
2.编写测试计划
3.指定测试方案
4.开发和设计测试用例
5.执行测试(与开发交集)
6.提交缺陷报告
7.测试分析与评审
8.提交测试总结
软件测试过程模型:
V模型(揭示了开发过程和测试过程各阶段对应关系)
缺点: 忽略测试对需求分析、系统设计的验证 没有体现"尽早地和不断地进行软件测试"的原则
W模型(两个V模型,分别代表测试与开发过程)
缺点: 需求、设计、编码等过程被视作串行,无法灵活迭代
H模型(软件测试是一个独立的流程)
X模型(改进V模型,定位探索性测试)
软件测试理念:
尽早测试、全面测试、全过程测试、独立的、迭代的测试
软件测试分类:
单元测试(模块测试)涉及到代码和程序
集成测试(接口测试)
确认测试(冒烟测试)
系统测试(全面、全方位的)
验收测试(供求双方 α测试、β测试)
按测试技术:黑盒测试、白盒测试和灰盒测试
按代码运行:静态测试和动态测试
软件测试的原则:
用户需求、质量第一 、不可穷举
测试用例
设计一个情况,软件程序在这种情况下,必须够正常运行并达到程序所设计的预期结果
用例设计模板
1.标识符: TestCase_项目名称_模块名称_功能名称_0001
2.测试项。测试用例的测试目的,表明测试模块、测试对象、方式、事件
3.依赖用例。一般功能流程上,下游功能测试依赖于上游功能测试用例
4.测试步骤。用最朴实的语言写出软件的操作步骤。
5.测试数据。单独整合测试数据。
6.预期结果。内容、对象准确。重要步骤之后,设定预期结果。
7.测试结果。测试执行完成之后添加。 通过/失败 Pass/Fail
8.测试人。测试的执行人,和设计者相同,也可以不同
9.备注。为了测试用例正常执行而做的特殊准备。
作用 :
1 有效性 2 可复用性 3 易组织性 4 可评估性 5 可管理性
注:测试用例需要经常更新,避免杀虫剂效应。
2.黑盒测试用例设计方法
等价类划分法
划分原则
一个文本框规定,输入字符个数为6~18位
1个有效:范围内有效 2个无效:小于6个 大于18个
划出等价类和列出等价类表
用例问题:
1.按照测试分类 (功能、UI、性能、安全、接口)
2.测试项
3.身份证号业务知识
4.测试项一般只写一个测试目的
5.依赖用例
边界值分析法
输入条件:值的范围 输入数据:范围边界值、刚刚超过边界范围的值
输入条件:值的个数 输入数据:最大个数、最小个数、比最小个数少1、比最大个数多1
分析规格说明,找出其他可能的边界条件
三角形判断,数据和顺序有没有关系?输入顺序不影响结果。
因果图法
适合于描述对于多种输入条件组合的测试方法
根据输入条件的组合、约束关系和输出条件的因果关系
原因与结果的关系: 恒等、非、或、与
约束条件:
原因约束:互斥、包含、唯一、要求(原因A成立,要求B一定成立)
结果约束:屏蔽(Mask)(结果之间A结果出现,B结果一定不出现)
优势:能够发现设计中存在的不足
局限性:原因和结果很多的时候,关系连线就会很多,导致因果图的可读性变差,一般用于局部小功能分析
判定表法
判定表驱动法: 条件桩、动作桩、条件项、动作项
应用场合: 适用于多条件内容组合与结果分析
使用的条件: 所有条件桩在表中的位置和顺序互相不影响,所有动作桩的顺序不会因为条件顺序的变化而产生不同
1.所有的软件,都是因为某种操作才会导致一定的结果 --因果图
2.所有的软件都有文本框 考虑必须一定使用等价类、边界值
场景法
事件触发控制流程。测试时,生动描述事件触发时的情景,有利于设计测试用例,
同时使测试用例更容易理解和执行。
基本流(软件功能正确实现的流程)、备选流 (基本功能流程之外的过程)
场景法适用于解决业务 流程清晰的系统或功能
正交实验法
利用排列整齐的表-正交表 ,用少数实验次数找到较好生产条件,达到最好的效果
核心概念:
1.影响实验结果的--实验因素(因子)、因素
2.每一个因素的不同取值(状况)--水平
例如,字的显示效果--字体、字号、颜色,称为因素
选择正交表--
1.n实验次数,m水平数,k因素的数量,这三个数字之间没有任何数学关系
2.仅适用于每一个因素的水平数都相同的正交表
功能图法
状态迁移图:遇到有事务流或者由于某种条件成立导致状态改变的软件时
使用条件:软件的状态会根据某些内容、条件、操作的变化而变化。
目标:尽可能覆盖软件状态、状态-条件组合的覆盖以及状态迁移路径的覆盖
步骤:
1.识别和列举所有的输入操作
2.定义空闲(初始)状态
3.为空闲状态加操作(只加一次)
4.为第3步所产生的新状态加操作(只加1次,并且曾经加过的操作不再重复添加)
5.循环为所有的新增状态加操作,直到没有新状态产生为止
6.组合任意状态,以列表的形式展现,设计和编写测试用例
测试大纲法
着眼于需求,无需测试用例,用于快速的测试和过程记录
探索性测试
基于经验和直觉
是计划内测试用例设计的补充
执行前需要设计测试用例
猴子测试(随意测试)
没有测试用例
缺点:测试不真实、不能达到一定覆盖率、许多测试冗余、同样随机数才能重建测试
3.其它
用例设计方法综合选择
·首先进行等价类划分
·在任何情况下都必须使用边界值分析方法
·如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法和判定表驱动法
·对于参数配置类的软件,要用正交试验法选择较少的组合方式达到最佳效果
·状态迁徙图法也是很好的测试用例设计方法,我们可以通过不同时期条件的有效性设计不同的测试数据
·对于业务流程清晰的系统,可以利用场景法贯穿整个测试案例过程,
·可以用错误推测法追加一些测试用例
·对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例
用例设计方法分类
1.等价类分析法
2.边界值分析法
3.因果图法
4.判定表法
5.场景法
6.正交实验法
7.状态迁徙图法(功能图法)
8.其他用例设计方法
记住方法的名称很简单,但是如何使用却是一个大问题:如何使用。用例设计方法的使用不是孤立存在的,而是存在于项目中!尤其是一个项目中。
教育APP为例设计各种用例设计方法
1.启动页
①读取版本更新信息。匹配当前APP与线上需要更新的APP版本是否一致。
②读取用户信息。未登录用户,则不用获取;已登录用户,验证是否登录过期。
用例设计方法:采用场景法进行设计。
设计场景:
①APP的安装版本比最新版要低。启动就需要进行版本检测,并进行提示。
②APP安装版本与最新版一样。默认检测过程成功。
③APP启动检测用户登录状态,如果登录过期或者未登录,启动完成后直接跳转登陆界面。
④APP启动检测用户登录状态,如果登录信息有效,启动完成后直接跳转首页界面。
2.在登录界面,看需求
用例设计方法:采用等价类划分法和边界值分析法。
等价类划分法:
①手机号的有效性。(手机号包含各种不合法字符);
②验证码包含各种不符合需求的字符
边界值分析法:
①手机号超过/不足长度限制;
②验证码超过不足长度限制;
③验证码有效期为30分钟;所以超过30分钟后使用验证码,就是边界值的使用。
④弹商提示1s消失;超过或者不足的测试都是边界值的应用。
3.课程内容页。需求如图所示
用例设计方法:场景法、等价类划分、边界值分析法。
场景法:
①该课程今日有作业、有提问的内容展示。老师发布作业的时候,学生提问。
②该课程今日有作业、无提问的内容展示。老师发布作业的时候,学生没有提问。
③该课程今日无作业、有提问的内容展示。老师没有发布作业的时候,学生提问。
④该课程今日无作业、无提问的内容展示。老师没有发布作业的时候,学生也不提问。
等价类划分法、边界值分析法:
①日期的显示。有没有出现2017年2月有29天的现象?
②日期的显示。会不会出现2017年2月1日和2017年1月31日重复或者相隔一天现象?
总结:所有测试用例的设计方法,没有独立使用的。都是融合在一起使用的,往往在一个软件界面中,都可以使用好几种测试用例的设计方法。
缺陷:
软件未实现产品说明书要求的功能
软件出现产品说明书指明不应该出现的功能
软件实现产品说明书未提到的功能
软件难以理解、不易运行、运行缓慢或者最终用户认为不好
缺陷类型、严重程度、优先级、状态、起源、来源、根源
缺陷类型: 功能、用户界面、文档、软件包、性能、系统/模块接口
注意:需求分析、设计阶段,文档类型的缺陷多;
集成测试阶段,一般接口类型的缺陷多一些;
系统测试阶段,功能、界面类型的缺陷多一些;
验收测试阶段,更多的关注性能缺陷;
实施过程,可能会遇到一些软件包的缺陷;
缺陷严重程度: 致命、严重、一般、较小 S1>S2>S3>S4
学习过程中,以PPT上所描述的严重等级进行缺陷严重程度划分
缺陷修复优先级: P1(立即解决)>P2(高优先级)>P3(正常排队)>P4(低优先级)
很大程度取决于缺陷对测试工作的影响程度。
优先级的衡量,一般可以根据测试的软件系统的全业务流程划分,软件的基本功能缺陷,优先级高,甚至需要理解解决。软件的备选流、基本功能测试中的反向测试的内容,优先级较低,甚至有些可改可不改。
面试提问:缺陷的严重程度和优先级有什么关系?
1)没有任何直接的关系。
2)不要认为严重的缺陷,修复优先级就高;
3)如果碰到,优先级和严重程度都高的缺陷,也只是偶然。例如,QQ的帮助按钮,会有经常闪退的现象。严重程度很高;但是优先级就很低。企业logo错误,不影响任何功能;但是必须优先修复。
面试提问:提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级?
1)不能搞“狼来了”。
2)也不能私人关系“帮”好朋友减少不良影响。
缺陷的状态
缺陷通过一个跟踪修复过程的进展情况。表明缺陷的处理进度。
发现缺陷是缺陷处理的前提,但是还还没有进入缺陷的处理流程。
1.激活/打开(新建)。由测试人员进行标注。
2.确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、或者质量保证(QA)、由产品经理进行确认。经确认后,有效的缺陷会指派给相关人员进行处理。
3.已修复/修正。在缺陷被修复后,一般由开发人员进行。
4.关闭/非激活。缺陷被修复完成后,经过测试人员的验证后,没有问题。
5.重新打开。经过测试人员的验证后,缺陷没有修复成功,需要重新打开进行再次处理和修复。
6.推迟。缺陷现在不修复,推迟到下一个版本或者阶段。测试要跟开发或者其他相关的管理人员进行确认。
7.保留。缺陷暂时修复不了。一般也是由开发人员去设定。也需要测试人员进行确认。
8.不能重现。开发按照却显得复现步骤不能再次发现缺陷。一般闪退、崩溃类型的缺陷具有类似的特征。或者由于操作系统的差异、浏览器的缓存等信息,出现的问题。所以作为测试人员,提交bug之前,要再三的确认bug。
9.需要更多信息。作为测试人员,撰交bug的时候,要尽可能的把所有相关的文件一起提交。(图片、视频)
10.重复。测试中,一定要避免这种情况的出现。尤其在软件的某一个功能频繁被多个模块(由不同的测试人员测试)调用的情况下
11.不是缺陷。一定不要在测试工程师的工作生涯中被开发标注缺陷状态不是bug。
12.需求修改需求说明书。缺陷不是技术原因造成的,而是由于需求不明确或者设计不明确造成。
缺陷的起源、来源、根源。一般关注较多的是缺陷的来源(直接原因);在测试总结的时候,关注缺陷的根源。
缺陷的来源
缺陷来源指缺陷的起因
缺陷的生命周期
1.发现缺陷。由测试人员。开发也能知道自己哪里写错了,但是不会广而告之。
2.提交缺陷。由测试人员。开发更不可能提交bug。
3.确认缺陷。一般由测试主管、或者质量保证QA、由产品经理确认。
4.分配缺陷。经确认后,有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷,就由谁分配。
5.修复缺陷。主要由开发修复,也有可能是产品经理修复问题。
6.验证缺陷。测试去验证缺陷有没有修复成功。
7.关闭缺陷。只能是测试人员进行。否则出了问题,测试认识一律不背锅。
缺陷的识别
依据:需求文档、设计文档、产品原型、测试用例,都是客观的依据
同行业的类似成熟软件。
测试人员在识别缺陷的时候,要很灵活的对待
缺陷报告
1、缺陷编号。Bug_ 项目名称_模块名称_0001。
2、所属模块。一级模块/二级模块/三级模块。
3、优先级。缺陷修复紧急程度.P1>P2>P3>P4。
4、严重程度。S1>S2>S3>S4。
5、缺陷概述。用一句话描述缺陷的基本情况。
6、缺陷的描述。将缺陷的复现步骤、预期结果和实际结果列出来。
7、提交人。是谁就写谁的名字。
8、备注。一般写该缺陷的特殊情况。将bug的截图作为备注信息。
缺陷报告预期读者
开发人员、质量管理人员、市场人员、运维人员
缺陷报告编写目的
1.展现缺陷的详细信息
2.展现缺陷的影响程度和方式
缺陷报告编写准则
准确、清晰、简洁、完整、一致
缺陷描述的规则:
1.可以再现
2.不做评价
缺陷跟踪系统
Bugzilla、Bugfree、禅道、QC