一、软件开发的阶段划分(生命周期)
A、需求分析阶段 需求分析人员 -》 需求规格说明书
B、设计阶段 架构师 -》 概要设计说明书、详细设计说明书
C、编码阶段 -》程序代码
-- A引入的bug大约占缺陷总数55%左右,B 25% ,C 15%【由于系统配置原因和系统兼容性占5%】
!测试不能只测程序,文档也必须测试;要贯穿整个开发周期(不断测试原则)(早测试早发现,成本更低)
二、什么是缺陷(default--bug)
★定义缺陷方式(5条)【在理解的基础上熟记】
1、需求要求的功能没有实现
2、实现了需求没有要求的功能(画蛇添足)
3、软件出现了指明不应该出现的错误(需求不一致的)
4、需求虽未明确说明,但是应该出现的功能没有实现(应有文档未说明,对文档内容补充测试)
5、软件运行缓慢,不宜使用、难以理解,站在用户角度一切不对的、不正常的都可以定义为bug
☆缺陷定义方式2【了解】
IEEE给缺陷的定义:
A、从软件产品外部来看(黑盒测试):缺陷是系统所需要实现的某种功能的实效或违背
B、从软件产品内部来看(白盒测试):缺陷是软件产品开发或维护的过程中存在的错误、毛病等各种问题
C、缺陷的同义词错误、异常、毛病、问题等功能的违背
三、什么是软件测试?
1、定义:简单来说就是从现有的软件中尽可能多的查找缺陷的过程。(确实软件的质量)
★重点:a. 查找bug而不是消灭; b. 不是只有查找到bug才是测试,只要完成了bug查找的过程就是测试
四、计算机的层次
1、计算机硬件(裸机)
2、操作系统
3、应用软件
--按结构分类
A、单机软件
B、分布式软件(有网络)特点:需要网络才能应用
1、C/S结构(client/server) 客户端/服务器
2、B/S结构(browser/server) 浏览器/服务器
【区别】C/S结构需要在客户端安装专门的客户端应用程序,才能享受服务器提供的服务,eg.QQ
B/S结构不需要客户端安装专门的客户端应用程序,只需要有公共的浏览器,输入相应的网址就可以享受服务器所提供的服务,eg.百度网址
【注意】B/S结构要做浏览器兼容性测试(IE(微软)、FIreFox、chrome、safair……)
缺陷报告
一、软件项目测试流程(步骤)【★重点面试问题★】
1、熟悉、分析需求(阅读 -》 分析需求 -》 整理业务,划分功能模块)
2、制定计划
1)由测试组长或者经理进行制定计划
2)测试人员应该阅读并执行测试计划
3、设计测试(设计并使用测试方法和编写 [测试用例] )
4、执行测试
5、记录测试结果(无论是否有bug都需要记录测试结果)
6、分析测试结果,记录缺陷(缺陷报告)
7、缺陷的跟踪和处理
8、测试总结(填写测试报告/测试总结报告)
二、什么是缺陷报告
1)测试人员发现bug,将缺陷记录在缺陷报告中
2)缺陷报告要提交给开发方,并且完成缺陷的跟踪和管理过程
3)缺陷报告是开发人员跟测试人员之间的重要沟通方式
问答:
1、什么是软件测试?
2、软件由哪些部分组成
3、如何定义软件缺陷
4、软件开发的阶段划分
三、如何编写缺陷报告
1)说明:在企业中会使用测试管理工具或缺陷管理工具对bug进行管理,比如:禅道、QC、螳螂、bugzilla,不同企业工具不同,缺陷报告的模板也不完全相同,但大同小异
2)缺陷报告的主要组成
①缺陷编号(defect id):唯一标识的顺序号
②缺陷标题(summary):简明扼要的将缺陷概括说明。
③发现者
④提交日期
发现缺陷后应该确认缺陷,避免“假缺陷”提交
⑤指派给谁处理
⑥功能模块:指出发现bug的功能模块
⑦发现缺陷在哪个版本中:版本不仅仅指发布的最终版本,也包括在研发过程中出现的临时版本
(☆)回归测试:在新版本中对上一个版本中测过的所有功能重新测试一遍
为什么要做回归测试?
A、修复bug的同时有可能会带来新的bug
B、新增加的功能有可能会给原有的功能带来影响,产生新的bug。(某些企业采用自动化的方式进行回归测试,节省成本、提高效率)
⑧状态:表示缺陷目前的处理情况
A、常用状态:新的(new) -- 激活的(open) -- 修复的(fixed) -- 关闭(closed) -- 被拒绝的(rejected) -- 重新激活的(reopened)
(☆重点面试问题)缺陷报告的处理流程(生命周期、步骤)
1)测试人员发现缺陷,填写缺陷报告,将新的(new)缺陷报告提交给开发经理
2)开发经理验证缺陷
Ⅰ 验证通过,激活,并指派给开发人员
Ⅱ 未通过,拒绝,测试人员自查,部门沟通,如果确认缺陷那么谁拒绝谁负责重新激活缺陷,重新纳入测试流程;如果确认是假缺陷,则由测试人员或测试组长将该缺陷进行关闭
3)开发人员修改该缺陷后,将缺陷修改后的状态设置为已修复的状态
4)测试人员对已修复的缺陷进行返测
Ⅰ 返测通过,closed
Ⅱ 未通过,reopened,指派回开发人员继续修复,直到缺陷修复成功关闭为止。
⑨缺陷的严重程度(severity)
表明该缺陷有多严重,多程序的影响有多坏
严重程度(有的严重程度也有1-2-3-4表示)
注意:缺陷严重级别的定义比较笼统,在实际工作中容易引起争论,所以企业通常会制定详细的缺陷严重级别说明。
⑩优先级(priority):建议开发在什么时间或版本解决该bug
(☆ 影响优先级的因素有哪些?☆)
1)不是缺陷严重程度越高,优先级越高,不是绝对的,要看实际情况
2)开发人员的开发压力越小,解决缺陷的优先级越高(比如错别字,修改起来很简单)
3)缺陷影响的范围越大,优先级越高
4)解决缺陷的成本(时间),成本越低优先级就越高
(☆ 缺陷的严重程度和优先级确定后可以修改吗?☆)
答:严重程度确定后原则上不修改(专业严谨的态度),优先级可以修改,而且通常会向后拖延。
①①缺陷的描述:将发现bug的过程记录下来(步骤、测试数据),让开发人员能重现bug
(☆ 随机bug☆)
1、随机缺陷:也叫不可重现缺陷
2、处理:
1)随机bug也要提交,要说明该缺陷为随机bug
2)测试人员应尽量详细的将发现的随机bug过程记录下来(最好截图或视频)
3)测试人员要在开发方的要求内,保留测试环境,提供随机bug的出现机率
4)如果有需求,开发方可以用白盒测试方法进行辅助测试
Day 2 -- 6.12
即时贴练习:
练习一:新增50个便签
Bug1:
时间:2023/6/12
反馈人:***
处理人:***
环境:即时贴1.0
优先级:高
重要程度:中
问题描述:
①需求:【新增】即时贴应有错位显示,区分不同即时贴
②需求:不同即时贴标题边框栏应自动生成不同名字,以示区分
示例:
缺陷报告 | |
缺 陷 I D | 1 |
缺陷标题 | 能够添加超过50个便签 |
所属产品 | 即时贴 |
所属项目 | 即时贴(windows版) |
所属模块 | 添加新便签 |
影响版本 | Version1 |
创 建 | 张三 |
当前指派 | 李四(开发经理) |
Bug类型 | 代码错误 |
操作系统 | windows |
严重程度 | 3类-中等程度 |
优 先 级 | 2级-下版本修改 |
Bug 状态 | 激活 |
重现步骤 | 【步骤】 1、点击即时贴图标 2、在即时贴弹出菜单中点击“添加新便签” 3、按照同样的方法添加50个便签 4、再添加第51个便签 【结果】 4、可以添加第51个便签 【期望】 4、程序提示不能添加第51个便签(或者添加完50个便签后,添加新便签菜单项置灰) |
四、缺陷报告总结
1、缺陷报告的作用
缺陷报告可以把软件存在的缺陷准确的描述出来,便于开发人员修正缺陷报告可以反映项目产品当前的质量状态,便于项目整体进度和质量控制软件测试缺陷报告是软件测试的输出成果
2、如何识别缺陷?
1)对比需求 - 如果与需求不符就是bug
2)参考缺陷的定义(5条定义)
3)通过与测试人员、开发人员、产品人员、客户进行沟通来确定bug