pythonav.com
首页
知识库
内部资料
免费视频
每天20道面试题
登录
注册
#缺陷管理 ##什么是缺陷 - 软件中任何不满足用户需求的问题,都可以识别为软件缺陷。 - 从产品内部看,缺陷是产品开发或维护中存在的错误,异常等问题。 - 从产品外部看,缺陷是违背了某种功能的实现。 ##缺陷识别方法 - 用户体验差,进行反馈 - 界面上有明显错误信息 - 功能缺失,与需求说明书不符 - 程序运行崩溃,停止运行 - 程序逻辑不正确,与用户使用手册不符 - 程序性能差,不能够承载压力访问 与专业人员来沟通识别缺陷 **注意不得站在自己主观意识去判断缺陷** ## 缺陷出现的原因 - 需求不断变化 - 工期短,软件复杂 - 编码中出错 - 设计文档不完善 - 沟通交流少 - 软硬件不支持 ## 常见软件缺陷术语 - bug 泛指软件程序的漏洞和缺陷。 - Debug **调试**(英语:Debug)是发现和减少计算机程序或电子仪器设备中程序错误的一个过程。 - 错误(mistake) 人为造成软件的故障 - 缺陷(bug&defect) 软件产品中存在的错误 - 故障(Fault) 某个组件功能不能完成所有任务的一个意外情况 - 失效(Failure) 软件功能完全损坏,无法使用  ### 经典传话游戏  `传话游戏` 老板对产品经理说:明早八点,我们公司可能来一个新的CEO,要求大家必须穿西服,打领带,新的CEO讲给大家开个会,指引新的战略。 产品经理对人事主管说:老板说,明天要来一个新的CEO,大家必须着正装,老板将给大家开会。 人事主管对研发主管说:根据老板意思,明天要新来一个新的副总,大家必须穿白衬衫,老板要开会。 研发主管对手底下人说:老板说了,明天早上开会,大家穿的干净点,听说要开掉那个副总。 ## 为什么引入缺陷  ## 缺陷的类型 `功能遗漏` 规定的时间或功能未在产品系统中体验,如缺少忘记密码功能 `程序错误` 没有按照用户需求正确实现,可能需求理解出错,可能编码出错 `额外的功能` ## 尽早引入测试 单位时间内,尽早引入测试,可以更早的发现缺陷,减少修复成本  ##缺陷的重现 可以重现的缺陷,存在一系列明确的重现操作步骤,条件和数据使得缺陷可以稳定的反复出现。 不可复现的缺陷,无法找到明确的步骤,缺陷出现是随机的,只做记录,不做报告。 不可重现的缺陷,后续再深入的挖掘,尝试转为可再现的缺陷,再进行缺陷报告。 ##缺陷报告 缺陷报告指的是测试执行过程中,发现软件缺陷,进行书写记录的文档,提供给开发人员或者测试负责人作为定位缺陷的依据,也用作缺陷数量统计的重要依据。 提供准确、完整、简洁的缺陷报告是软件测试专业性、高质量的评价标准 ## 撰写缺陷报告5c原则 **5c原则** - Correct(准确):每个组成部分的描述准确,不会引起误解; - Clear(清晰):每个组成部分的描述清晰,易于理解; - Concise(简洁):只包含必不可少的信息,不包括任何多余的内容; - Complete(完整):包含复现该缺陷的完整步骤和其他本质信息; - Consistent(一致):按照一致的格式书写全部缺陷报告。 **缺陷报告结构** - 报告的缺陷信息具体、准确 - 缺陷特征描述与复现缺陷步骤 - 缺陷类型以及严重级别 - 缺陷标题 - 缺陷基本信息 - 测试环境描述 - 缺陷严重程度 **撰写缺陷报告注意点** - 按照缺陷发生的因、果进行书写 - 避免模糊不清的词语,比如`功能不对`、`登录不起作用`,应该具体描述`某一个功能如何不对`、`登录具体流程如何不正确` - 中立评价,公正表达自己对软件缺陷的理解,对软件错误以及造成的事实进行描述 ## 常见软件缺陷 | 编号 | 问题描述 | | ---------- | ------------------------------------------------------------ | | 中文英统一 | 不要使用中英文混合提示,不要去挑战用户的英文能力.. | | 容错性 | 例如用户注册,需要限制手机号长度,年龄范围等,输入错误需要有醒目提示 | | 用户体验 | 比如某高校学生信息登记网,填写一堆信息后,由于一个信息填写错误,内容全部被清空,还得重新输入,用户体验极差 | | 兼容性 | 需要考虑操作系统、浏览器类型、版本,网络类型 | | 错别字 | 例如网站的"登录"写成"登陆" | | 安全性 | 注意SQL注入,XSS攻击 | | UI友好度 | 比如删除、保存按钮离得太近,用户手指头难以正确点击... | | ….. | 未完待续 |  ##bug学习目标 - bug类型 - bug等级 - bug生命周期 ##bug是什么 bug泛指软件程序的漏洞和缺陷。 值测试工程师或用户发现与提出的,软件可以改进的细节部分、或者与需求文档存在功能偏差的实现。 测试工程师职责就是发现bug,提交bug信息给研发人员,研发人员修复bug。 ### bug案例 例如登录时,要求输入账号密码。 输入正确的账号密码: 结果提示:用户名不存在/密码 再三确认账号密码是否错误,可以重新再注册一个账号进行登录 如新账号也是账号不存在,此登录已经是bug了! ##bug的类型 想要确定bug的类型,需要对产品有较深的理解。 禅道系统中对bug定义划分如下: - 代码错误(指的是研发代码有误,功能未实现) - 设计缺陷 - 界面优化 - 性能问题 - 配置相关 - 安装部署 - 安全相关 - 标准规范 - 测试脚本 - 其他(功能类、界面类、性能类、易用性类、兼容性类、其他) ##bug严重程度 顾名思义就是软件缺陷对软件质量造成的破坏程度,将会给软件使用带来怎样的影响。 Bug等级越高,可能被修复的等级也越高,公司也会根据测试提交的bug数量以及bug等级作为绩效考核标准。 判断bug的等级,如下分类: `1.致命错误` - 常规操作缺引起系统崩溃、死机、死循环 - 造成数据库泄露的安全问题,如恶意攻击造成的账户私密信息泄露 - 涉及金钱隐患,金钱计算bug(如金额不足,还可以购买产品,对公司金额造成重大损失 `2.严重错误` - 重要功能未实现,如点击注册无反应,无法登录 - 非常规操作(误操作)导致程序崩溃、死机、死循环 - UI界面的严重问题 - 密码明文显示,数据库泄露 `3.普通错误` - 不影响产品运行,不会影响故障,但对产品外观界面影响较大,如删除了好友,好友却未消失 - 功能无法正常显示功能 - 操作界面错乱 - 查询数据错误 - 页面未做输入格式限制 - 删除错误未给与提示 `4.错误提示` - 网页UI错误, - 错别字 - 标点符号 ## bug处理优先级 优先级(Priority)指的是缺陷被修复的紧急程度。 - 立即解决:软件缺陷已导致软件系统崩溃,需立即修复 - 高优先级:缺陷比较严重,已经影响用户正常使用 - 普通优先级:缺陷排队,等待修复 - 低优先级:等待开发人员闲时进行修复,缺陷影响很小 ## 常见bug管理状态 在不同的缺陷管理系统中,对bug的标记状态有如下种类: - New 缺陷初始状态 - Open 缺陷修复中 - Fixed 缺陷修复完毕 - Closed 缺陷已通过回归测试,关闭缺陷 - Reopen 缺陷未通过回归测试,重新修复 - Postpone:推迟修改缺陷 - Rejected:开发拒绝修复缺陷 - Duplicate:重复提交的缺陷 - Abandon:开发与测试经过讨论,确定不是缺陷,可以标记缺陷关闭 ##bug生命周期图  ## 缺陷跟踪管理系统 早期缺陷管理大多是以缺陷记录表单形式完成,如今也还有很多项目使用此方法,但是随着用户需求提升,软件复杂度提升,缺陷缺陷也随之增长,管理也就愈加麻烦。 软件行业发展,出现大量缺陷管理系统。 - JIRA - BUGZILLA - HP Quality Center(QA) - 禅道(中文、优秀!) 实力雄厚的公司还会自研缺陷跟踪管理系统,大部分公司则是选择禅道来缺陷跟踪以及项目管理。 ## 测试执行过程  **执行测试的主要任务** - 确定测试用例的优先级 - 创建测试数据,准备测试工具以及编写自动化测试脚本 - 根据测试流程创建测试套件,提升测试执行效率 - 搭建测试环境 - 根据测试计划的执行顺序,通过功能测试或是代码测试 - 记录测试结果,编写测试报告 - 将测试结果和预期结果进行比较,将结果的差异提交上报,分析差异原因 - 缺陷修复后,进行回归测试,验证产品 ## 测试准入标准 `没有经过自测的代码,就是在耍流氓` `通过冒烟测试` `测试范围已明确` - 开发编码结束,并且在开发环境完成单元测试 - 开发需求规定的功能均实现,如没有完全实现,请提供测试范围 - 已经完成集成测试,被测系统的基本流程已经走通,界面上功能均实现,经过代码评审并符合软件编码规范 - 开发提交最新版本代码,告知测试组进行测试 - 测试环境兼容性确认 - 安全测试与性能测试的要求确认 ## 测试停止 - 测试人员首次冒烟测试,若是发现重大缺陷或缺陷过多,导致测试卡壳基本流程无法进行,可以暂停测试回馈开发。 - 被测项目由于需求调整,被迫暂停测试 - 存在更高级的测试任务,需要暂停测试 - 被测系统达到系统准出标准,测试流程结束,可以停止测试 ## 测试准出标准 
目录
预科:为什么学测试
什么是计算机
第一章 测试理论
软件测试方法
软件测试需求
软件测试计划书
测试用例
缺陷管理
配置管理
禅道
软件质量