关闭

软件质量基础知识

标签: 软件质量知识测试什么
2068人阅读 评论(4) 收藏 举报
分类:

一、目录

软件质量模型

测试技术类型

测试流程规范

研发质量规范

问题交流

 

二、软件质量模型

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

一次通过率

一次测试就通过的被测包数/提交测试包数

评价研发人员开发质量

    1. 对日常变更包测试进行管理,统计一次测试就通过的变更包数和提交测试包数
    2. 对于通过率低的开发人员进行原因分析,是组织问题还是个人问题,并进行改进

2

平均每包缺陷数

测试发现缺陷数/已测包数

评价研发人员的开发质量

    1. 测试人员对变更包进行测试
    2. 统计每个研发人员被测试包检出缺陷数和已测试包数
    3. 可用于定义组织的基线和目标,对产品质量进行整体改进
    4. 对平均每包缺陷数高的人员进行原因分析和质量改进

3

平均每包研发时长

每个任务包在研发阶段的时间求平均

 

评价研发人员研发效率

    1. 使用工具跟踪每包研发时长
    2. 统计平均每包研发时长
    3. 对存在问题进行分析制定改进计划

     

序号

质量指标

指标公式

指标说明

为建立、改进质量指标拟采取的质量活动

4

缺陷修复率

经验证已正确修复的缺陷数/确认缺陷数

评价研发人员修复效率

    1. 对测试出的缺陷进行状态跟踪
    2. 统计已经正确修复的closed状态的缺陷数和已经研发经理确认的open的缺陷数
    3. 横向比较研发人员的缺陷修复效率
    4. 对修复较慢的人员进行督促改进

5

代码审查缺陷数

代码审查出问题数

评价研发人员静态代码质量

    1. 在研发过程中加入代码审查环节
    2. 统计研发人员代码审查出问题数
    3. 对常见代码问题进行原因分析
    4. 对常见代码问题及解决方式进行培训

 

3、常用测试人员工作评价指标

序号

质量指标

指标公式

指标说明

为建立、改进质量指标拟采取的质量活动

1

平均每天Bug数

测试出的有效bug数(个)/工作量(天)

评价测试质量和效率

    1. 对测试出的缺陷进行记录
    2. 统计测试工作量
    3. 月度指标排名
      1. 遗漏缺陷原因分析
      2. 增加功能测试用例

2

测试规范

每月抽查测试用例规范和BUG规范与部门标准比较

评价测试质量

    1. 测试执行之前撰写测试用例
    2. 发现缺陷,按规范录入
    3. 测试经理进行抽查
    4. 发现问题进行改进

3

缺陷根因分析

对关键、严重的问题进行代码级别的原因分析;与部门标准比较

评价测试质量

    1. 建立缺陷根因分析规范
    2. 抽查分析情况
    3. 发现问题进行改进

4

工作量饱和度

实际工作量(天)/正常工作量

评价测试工作饱和度

    1. 报工系统
    2. 月度统计揭示指标
    3. 作为组织绩效指标
2
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:318609次
    • 积分:4683
    • 等级:
    • 排名:第6563名
    • 原创:142篇
    • 转载:56篇
    • 译文:7篇
    • 评论:37条
    文章分类