软件质量基础知识
Posted 编程之间
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件质量基础知识相关的知识，希望对你有一定的参考价值。
一、目录
软件质量模型
测试技术类型
测试流程规范
研发质量规范
问题交流
二、软件质量模型
1、好的架构
2、充分了解了用户需求
3、尽量少的bug
4、性能好
软件质量模型
功能性 可靠性 可移植性 易用性 维护性 效率
三 测试技术类型
1、功能测试
单元测试
集成测试
系统测试
验收测试
测试计划
测试用例
测试执行
缺陷跟踪
修改建议
测试报告
2、性能测试
压力测试
负载测试
疲劳测试
POC测试
性能问题分析诊断
性能问题分析诊断
数据库优化、SQL优化
中间件优化、操作系统优化
3、安全测试
等级保护
物理安全
网络安全
主机安全
应用安全
数据安全
SQL注入
DOS攻击
XSS跨站脚本攻击
工具扫描
人工扫描
4、自动化测试
自动化设计
自动化脚本开发
中断处理
调度执行
结果分析
5、用户体验测试
易用性测试
可用性测试
全面CE
A/B测试
6、云测试
云服务测试
云平台测试
云安全测试
核心模块POC测试
7、移动互联网、手机API测试
App功能测试
APP性能测试
APP兼容性测试
APP安全测试
APP用户体验测试
APP自动化测试
8、API测试
API功能测试
API性能测试
9、兼容性测试
浏览器兼容性
操作系统兼容性
数据库兼容性
移动客户端兼容性
国产化兼容性测试
四、测试流程规范
1、研发测试流程：
2、研发任务单撰写要求：
任务名称：
为该任务的名称，建议名称简洁，并能体现任务包解决的问题。（必填）
任务描述：对任务包解决问题或者功能的详细描述。
所属组件：为该任务所属组件。一个任务只能属于一个组件。（必填）
菜单路径：修改的问题涉及到的具体菜单，提供此信息可以方便测试人员测试。
需求/TD号：填写任务包修改的问题与TD或者已有的需求管理系统中得对应编号。
优先级：根据任务包的紧急程序分为高、中、低三级，根据实际情况填写。
部署说明：为该任务包生成后的构建包在运行环境中的部署方式说明。如果部署说明比较长，建议整理成文档添加在附件中。
有无sql：任务包中有升级sql，则填写有，否则为无。该字段没有实际的意义，主要用来提醒测试人员和发布人员。
依赖的任务：该任务包依赖的其他任务包。如果该任务包依赖其他的任务包，在构建和测试时，会有提示必须先构建和测试依赖的任务包。
计划完成时间：该任务包的计划完成时间。目前这个时间不做预警。
测试结果：测试人员填写该任务包的测试结果。
实际完成时间：该任务包的实际完成时间。
3、缺陷管理-缺陷严重程度
致命关键：
造成系统崩溃或引起严重数据错误的问题、可能导致敏感数据泄露的安全问题
严重：
主要业务流程无法跑通或严重影响软件使用的问题，且无其它的替代方式
一般（平均）：
不影响主要业务流程，但会影响软件使用的一般问题
较轻：
对软件使用影响较小，轻微的程序问题
建议：
针对非主要功能易用性或用户潜在需求提出建议性问题
4、缺陷原因分类
| 序号 | 一级分类 | 二级分类 |
| 1 | 程序技术 | 脚本错误 |
|
|
| 对象获取错误 |
|
|
| 逻辑判断 |
|
|
| 错误的方法 |
|
|
| java异常 |
|
|
| 浏览器兼容性 |
|
|
| 字符集 |
| 2 | SQL类 | SQL语法错误 |
|
|
| SQL兼容性 |
|
|
| 访问资源不存在 |
|
|
| SQL性能 |
|
|
| SQL注入 |
| 3 | 业务逻辑 | 需求未完全实现 |
|
|
| 需求实现错误 |
|
|
| 需求遗漏 |
|
|
| 流转环节有误 |
|
|
| 计算与精度 |
|
|
| SQL设计错误 |
| 序号 | 一级分类 | 二级分类 |
| 4 | 部署问题 | 应用系统配置 |
|
|
| 环境遗留 |
|
|
| 源文件不正确 |
| 5 | 易用性 | 校验与提示 |
|
|
| 页面问题 |
|
|
| 用户体验 |
| 6 | 自测不足 | 直接拷贝 |
|
|
| 资源不存在 |
|
|
| 拼写错误 |
|
|
| 方法无实现 |
| 7 | 第三方软件 | 楼上平台 |
|
|
| 平台使用错误 |
|
|
| 第三方插件 |
| 8 | 其它 | 其它 |
5、缺陷生命周期
| 状态 | 具体含义 | 授予的角色 |
| New | 新的缺陷,并未得到确认。 | 测试人员 |
| Open | 缺陷经过确认，研发人员必须修改 | 项目经理 |
| Fixed | 缺陷经过修改 | 开发人员 |
| Closed | 缺陷关闭，跟踪结束 | 测试人员 |
| Reopen | 缺陷重新打开，该缺陷仍然存在 | 测试人员 |
| Rejected | 缺陷被拒绝修改 | 项目经理\\开发人员 |
| Delete | 缺陷录入重复时选择此项，表明此缺陷已被录入 | 测试人员 |
| Confirm | 缺陷确认，测试人员对被拒绝的缺陷与项目经理及开发人员进行确认 | 测试人员 |
| Delay | 延迟修改 | 开发人员 |
6、缺陷管理流程
五、研发质量评价
1、统一的软件质量指标
| 指标类别 | 指标名称 | 计算公式 |
| 研发质量 | 缺陷检出率 | =检出缺陷数/(检出缺陷数+反馈缺陷数）*100％ |
|
| 严重缺陷占比 | =检出严重缺陷数/检出缺陷总数*100％ |
|
| 反馈缺陷密度 | =客户反馈缺陷数/产品研发规模（人月） |
|
| 缺陷密度 | =检出缺陷数/产品研发规模（人天） |
2、常用研发人员工作评价
| 序号 | 质量指标 | 指标公式 | 指标说明 | 为建立、改进质量指标拟采取的质量活动 |
| 1 | 一次通过率 | 一次测试就通过的被测包数/提交测试包数 | 评价研发人员开发质量 |
|
| 2 | 平均每包缺陷数 | 测试发现缺陷数/已测包数 | 评价研发人员的开发质量 |
|
| 3 | 平均每包研发时长 | 每个任务包在研发阶段的时间求平均
| 评价研发人员研发效率 |
|
| 序号 | 质量指标 | 指标公式 | 指标说明 | 为建立、改进质量指标拟采取的质量活动 |
| 4 | 缺陷修复率 | 经验证已正确修复的缺陷数/确认缺陷数 | 评价研发人员修复效率 |
|
| 5 | 代码审查缺陷数 | 代码审查出问题数 | 评价研发人员静态代码质量 |
|
3、常用测试人员工作评价指标
| 序号 | 质量指标 | 指标公式 | 指标说明 | 为建立、改进质量指标拟采取的质量活动 |
| 1 | 平均每天Bug数 | 测试出的有效bug数（个）/工作量（天） | 评价测试质量和效率 |
|
| 2 | 测试规范 | 每月抽查测试用例规范和BUG规范与部门标准比较 | 评价测试质量 |
|
| 3 | 缺陷根因分析 | 对关键、严重的问题进行代码级别的原因分析；与部门标准比较 | 评价测试质量 |
|
| 4 | 工作量饱和度 | 实际工作量(天)/正常工作量 | 评价测试工作饱和度 |
|
以上是关于软件质量基础知识的主要内容，如果未能解决你的问题，请参考以下文章