简答题
开发各阶段缺陷放大图
- 同行评审的种类
- 正式评审
- 技术审查
- 走查
同行评审方式的选择
- 工作产品刚勾画,起草时—走查
- 完成了某一个单独的章节时—技术审查
- 整个产品完成时—正式评审
软件缺陷发现
- 同行评审
- 软件测试
- 管理评审
- PPQA发现
- 项目组内部发现
- 客户反馈
软件缺陷生命周期
软件缺陷生命周期主要由四个阶段组成:
- 识别
- 调查
- 改正
- 总结
缺陷度量
- 缺陷度量:CMMI第四级(量化管理级)的软件组织会根据已收集的缺陷数据,采用统计过程控制(Statistical Process Control,SPC)的方法建立软件过程能力基线(Process Capability Baseline,PCB),定量地刻划出软件或过程的特点,进行量化管理。
SPC:利用统计方法对过程中的各个阶段进行控制,从而达到改进与保证质量的目的;强调以全过程的预防为主;方法是建立控制图
PCB:用基线形式量化地表示过程能力;PCB是个不断随着数据累积校正的过程,本身数据收集必须遵循客观、准确、事实,确保组织基线可以持续为各项目研发作为参考标准;运用PCB有助于对过程的分析和改进;
PCB是一组能力指标,是过程实际能力的具体体现。通常包括期望值(Mean)、控制上限(Upper Control Limit,UCL)、控制下限(Low Control Limit,LCL)。以缺陷密度为例, Mean描述了未来项目的缺陷密度的预期值,UCL和LCL描述了未来项目的缺陷密度的合理变化范围。
- 这样的过程能力基线可用来:
(1)帮助未来的项目设立量化的项目质量目标;
(2)理解和控制未来项目的实际结果。
软件缺陷跟踪管理流程
- 总体流程
- 提交流程
- 修复流程
- 验证流程
- 拒绝流程
- 争议处理流程
- 缺陷挂起流程
缺陷状态
常用软件缺陷状态
编号 | 缺陷状态 | 描述 |
---|---|---|
1 | 提交(Submitted或New) | 已提交的缺陷 |
2 | 打开(Open或Active) | 经审查后确认的缺陷,等待处理 |
3 | 拒绝(Rejected、Refuse或Not a bug) | 经审查确认不是缺陷、不需要修复或不需要提交 |
4 | 修复(Resolved或Fixed) | 或为Fixed。缺陷已被修复 |
5 | 关闭(Closed或Inactive) | 经审查确认已被修复的缺陷,可将其关闭 |
6 | 推迟(Later、Pending或Deferred) | 当前无法修复,以后条件具备时再解决,但要确定修复的日期 |
7 | 重新打开(Reopen) | 经过修复的缺陷未通过验证测试,或已关闭的缺陷重新出现 |
软件缺陷报告
“5C”原则:
- 内容正确(Correct):每个组成部分的描述正确,不会引起误解。
- 内容清晰(Clear):每个组成部分的描述清晰,易于理解。
- 步骤简洁(Concise):只包含必不可少的信息,不包括任何多余的内容。
- 结构完整(Complete):包含复现该缺陷的完整步骤和其他本质信息。
- 风格一致(Consistent):按照一致的格式书写全部缺陷报告。
优秀的缺陷报告
重现步骤 |
---|
(1) 打开编辑文字的软件 (2)创建一个新文档(这个文档可以录入文字) (3)在这个文档里随意录入一两行文字(任意) (4)选中录入的一两行文字,选择Font菜单,然后选择Arial字体格式 (5)一两行文字变成了无意义的乱字符 |
期望结果 |
当用户选择已录入的文字并改变文字格式时,文本应该正确显示选中的文字格式,不会显示成乱字符 |
实际结果 |
这是字体格式的问题,如果把文字格式改变成Arial前保存文件,缺陷不会出现。缺陷仅发生在Win98,且改变文字格式成其他字体格式时正常。 |
缺陷工具:
- Bugzilla是一款免费、跨平台的开源缺陷跟踪系统,最初是专门为Unix定制开发的,目前也可在windows、Mac OS平台安装使用,在wins操作系统下的安装和配置略为复杂。bugzilla历史悠久、功能强大、受到很多企业用户的欢迎。
- Mantis是一款开源的基于PHP的轻量级跟踪系统,简洁灵活,安装容易,扩展性强,其实用性足以满足中小型项目的缺陷管理和跟踪需要。
- 禅道:集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,避免了一个团队使用多个工具,较bugfree功能更全面。
- TestCenter是一款集测试需求、测试用例、测试过程、测试结果、以及测试报告管理的测试管理工具。
- BugFree基于浏览器,简单、方便、易用的免费、开源的缺陷管理工具。
大题
注入-发现矩阵实例
缺陷注入阶段/缺陷发现阶段 | 需求阶段 | 概要设计阶段 | 详细设计阶段 | 编码阶段 | 单元测试阶段 | 集成测试阶段 | 系统测试阶段 | 现场阶段 | 注入合计 |
---|---|---|---|---|---|---|---|---|---|
需求评审 | |||||||||
概要设计审查 | 49 | 681 | 730 | ||||||
详细设计审查 | 6 | 42 | 681 | 729 | |||||
代码审查 | 12 | 28 | 114 | 941 | 1095 | ||||
单元测试 | 21 | 43 | 43 | 223 | 2 | 332 | |||
集成测试 | 20 | 41 | 61 | 261 | —— | 4 | 387 | ||
系统测试 | 6 | 8 | 24 | 72 | —— | —— | 1 | 111 | |
现场 | 8 | 16 | 16 | 40 | —— | —— | —— | 1 | 81 |
发现合计 | 122 | 859 | 939 | 1537 | 2 | 4 | 1 | 1 | 3465 |
本阶段缺陷移除率 | —— | 74% | 61% | 55% | 36% | 67% | 58% |
思路:
单元测试:
332/(122+859+939+1537+2-730-729-1095)x100%=36%
故障树
参考:故障树PPT
故障树分析
逻辑门
例题
使用MOCUS算法确定最小割集。首先画出一个足够大的矩阵表格,然后按下面的步骤填充矩阵:
- 将故障事件门的字符放在左上角(0,0)单元格
- 将每个门的字符用其下方较低级别的门或基本事件的字符或数字替换,重复此过程。
- 对于或门:将字符写成一竖排(也就是竖着写);对于与门:将字符写成一横排。