缺陷管理 + 配置管理

最新推荐文章于 2024-09-22 09:48:08 发布

Arno_007

最新推荐文章于 2024-09-22 09:48:08 发布

阅读量750

点赞数 1

分类专栏：软件测试文章标签：软件测试

本文链接：https://blog.youkuaiyun.com/Arno_007/article/details/109765881

版权

软件测试专栏收录该内容

14 篇文章

订阅专栏

一、缺陷管理

1、缺陷管理工具（禅道）

下载地址：https://download.youkuaiyun.com/download/Arno_007/13121799

⒈安装

⑴ 点击安装程序，必须英文路径，然后在安装路径中找到xampp这个文件夹

⑵ 点击运行程序

⑶ 先点击NO再点击YES

⑷ 点击服务选项-配置端口，勾选“自动更改端口号”

⑸ 点击启动禅道，然后修改密码

⒉使用禅道

⑴ 先使用管理员账号密码登录系统（admin/123456）,登录后修改密码

⑵ 在【组织管理】配置公司的名称，部门以及用户信息

⑶ 建立产品信息

⑷ 建立产品的模块

⒊禅道功能

为了方面编写测试报告，禅道提供了“统计”和“导出”功能以满足测试报告编写。

2、BUG的生命周期

⑴ 已激活-已确认-已解决-关闭

⑵ 已激活-未确认

这种一般都是提交BUG后，开发人员要么忘了，要么不想理会！这种情况我们需要即时提醒！如果不改！找领导！

⑶ 已激活-已确认

① 设计如此

领导说要这样做的，测试想多了。

② 重复BUG

这个BUG有其他测试人员提过了，无须再提

③ 外部原因

这个可能是别人接口调用有问题导致的不通现象，与我们没关系。

④ 无法重现

这个我们开发人员重试了几遍都没有出现，但根据测试的截图来看确实出现了这个问题，只是无法立即重现，需要分析系统日志或待用户真实使用的时候，遇到了这种问题的时候，需要立即提供用户操作业务的账号、密码等关键信息提供给我们开发人员。

⑤ 延期处理

这种问题影响不是很大，但确实也算一个问题，领导说了，这种小问题留在后面统一优化。（当然这种问题也存在很多需求类的建议，也就是虽然没有说，但应该要实现要做的）！

⑥ 不予解决

Ⅰ 这个BUG需求文档没有说，测试人员提给我的话加大了我的工作量，我不想改，我不改！

Ⅱ 建议：建群-拉人-@需求-@开发看到没！，可以拉甲方，但最好直接联系甲方，不要在群里说。

3、BUG严重程度定义规则

严重级别	具体表现	问题说明	说明
致命（1级）	1）数据库破坏。 2）系统停机。 3）扩展到其它系统的系统停机。	阻断性问题，导致我无法进行下一步操作	遇到1级BUG，赶紧提，开发不改？找领导！不然没法继续工作。
严重（2级）	界面： UI界面无法打开/报错，无法正常完成测试工作的。非配置文件中的错误的页面链接，此类链接属于硬编码到代码中必须重新发布程序的错误链接。程序（代码逻辑）：核心功能实现问题（指程序核心模块的功能或优先级高的特殊功能）。数据库：数据表设计字段与用户需求不符（字段缺失、字段数据类型不符、字段冗余）。数据表字段保存不完全。	表单提交出问题，数据展示出问题，定义为此级别
一般（3级）	界面（GUI）: 界面提示不规范（提示信息错误，提示内容与实际原因不符，提示信息不友好等）界面布局不规范（同级别字体样式未统一、段落未对齐、页面框架不统一）文字错误（包括按钮文字，页面文字，选项框文字等）程序（表单格式）：普通功能操作和输入输出项与用户需求不符（包括输入输出项缺失、名称不符和必填项不符）。	表单界面按这个定义，比如个人注册
建议（4级）	界面: 是否改动都不影响发布和用户验收程序: 可以更好改进的, 但是对测试质量不会构成影响的	所有界面

4、产品和项目的概念

⒈做产品的

这种叫作互联网公司，公司有独立的IT部门、有独立的产品部门，公司没有所谓的需求分析师，有也叫作“产品经理”。（比如：淘宝、腾讯、网易、百度）

⒉做项目的

这种一般都是外包公司接的项目，为了调研用户需求，会指派一个需求分析师与客户进行对接！

二、配置管理

1、概念

配置管理的概念:配置管理是通过对在软件生命周期的不同时间点上的软件配置进行标识，并对这些被标

识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可塑性的过程。

2、配置管理常用术语

配置
配置项
基线
版本
版本标示

⒈配置

配置的概念：“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了

即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持

数据，以及其他一切保证软件一致性的组成要素。

⒉配置项

配置项的概念：为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置

                        管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配

                        置项被作为一个单一的实体对待。一个系统包括的配置项的数目是一个与设计密切相关的

                        问题。

⑴配置项的大类别

文档

一篇文档就是一个配置项

代码

推荐将整个项目组的所有代码当做一个配置项。如果项目组内不同模块之间的进度相差很大的时候，

将每一个模块的代码划分为一个配置项更加方便管理。

⑵配置项的分类方法

配置项	分类
合同类文档	建议书、用户意向书、用户需求、工作任务书、合同
计划类文档	包括各类项目相关计划，比如项目过程手册、项目计划，配置管理计划等
工程类文档	包括需求规格文档、测试计划（含测试用例）、设计文档、需求跟踪矩阵等
程序代码	所有开发的源代码、包括各类支持数据，二进制文件
第三方程序代码	有供应商提供的源代码，并接受供应商的维护
工具	支持软件开发、建立、维护的工具管理，比如语言开发工具，编译工具，测试工具，配置管理工具等
用户文档	包括用户手册，安装指南等
运行环境	包括系统运行环境的相关内容，比如系统运行的平台，环境设置要求等

⒊基线

基线的概念：在配置管理系统中，基线就是配置项在其生命周期的不同时间点上通过评审而进入正式受控

的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的基准。基线具有以下属性：

通过正式的评审过程建立
基线存在于配置库中，基线的变更由变更控制委员会控制
基线是进一步开发和修改的基准

⒋版本

版本的概念：版本表示一个配置具有一组定义的功能的一种标示。随着功能的增加，修改或删除，配置项的版本随之演变。

版本以版本号进行标识。

常见版本：
Base：基本版
Alpha：内部测试
Beta：外部测试
Demo：演示
RC：候选
Release：最终

版本标识的概念：软件版本是以xx.yy.zz.pp的形式标识。

数字	发布类型	典型描述
xx	主版本号	增加了一个大的特性 - 可能导致与原先版本不兼容
yy	次版本号	增加了一个小的特性 - 保持与原先版本兼容
zz	维护版本号	可以包含一些更改，并且包含自上一次版本发布以后的所有的补丁。一般地，这个版本要根据保证和/或支持/维护协议主动提交给所有的用户
pp	补丁版本号	包含对客户或测试组发现和报告的一个或多个问题的解决。此版本只发布给报告问题的客户或测试组。解决一次问题发布一个补丁版本给报告问题的客户或测试组。补丁也可能只是一种优化