《软件测试技术实战 设计、工具及管理》联载-46

简介: 《软件测试技术实战 设计、工具及管理》联载-46

2.2  退测标准

  •  10%以上(含10%)的冒烟测试用例没有通过。
  •  新发现有5个以上(含5个)BlockerCritical级别的缺陷。


版本发布的命名规则:

"V"+X+"."+Y+". "+Z+ Name+"V"+X+"."+N+". "O+"-"+yyyymmdd

Ø    X:大版本号。

Ø    Y.Z:小版本号。

Ø    NameBuild/ Final/…参见本节7.3定义,目前采用Build

Ø    N0/1版本是否送交用户,0表示不送交客户,仅供内部软件测试组使用;1表示送交客户。

Ø    O:是否为里程碑版本,0非里程碑,可以不进行回归测试;1里程碑,大的模块或者新的版本完成,需要进行回归测试。

Ø    yyyymmdd:发布的年月日。

比如:一个具体的版本说明V5.1.2 Build V5.1.1-20150925

含义:软件版本是5.1.2V5版本的升级版本),这个版本是2015925日发布的V5版本,需要提交给用户的里程碑版本,需要回归测试。


版本发布情况规定一般如下:

  •  平均每两周发布一个小版本,一个半月到两个月发布一个正式版本。
  •  发布一个正式版本后,两周后发布一个内部测试版本(这个版本仅作内部复测使用)。
  •  两周后发布一个准发布版本(此版本需要对产品进行回归测试,开发工程师在此版本中只允许修改软件测试提交的缺陷,不允许添加任何新的功能)。
  •  两周后发布正式版本(此版本软件测试工程师进行复测,回归测试后按照发布版本控制流程提交版本)。
  •  如果在正式版本发布前的两周内需要添加非常重要的新功能,在接下来一周进行修改添加,一周后再发布一个正式版本。
  •  两周后发布一次内部测试版本。
  •  如果在执行过程中用户有非常重要的功能需要实现,可以在24天的时间内建立分支完成,但是不主张建立过多的分支,建立分支需要得到开发经理的同意。临时给客户一个版本,但要在正常流程中把分支流程合并进来。
  •  版本发布一般放在周五,周五12点后开发工程师停止提交代码,等到软件测试工程师编译成功,打上Tag(标记)后,开发工程师才可以往SVN中提交新的代码。


3.软件测试缺陷提交流程


如图12-29所示:


3.1  步骤描述

3.1.1  流程启动条件

软件测试工程师在软件测试过程中发现一个新问题。


3.1.2  步骤

1)软件测试工程师发现新问题,提交到JIRA,书写格式参考7.2节。

2)软件测试经理对提交的缺陷进行抽查。

3)软件测试经理如果认为提交的缺陷有问题,就与软件测试工程师进行讨论。

4)否则保留软件测试工程师的记录。

5)开发工程师处理缺陷(软件测试工程师提交上的缺陷都要进行处理,处理没有解决的标记状态In progress)。


image.png

12-29 软件测试缺陷提交流程


6)对处理后的缺陷标示已处理类型。

7)开发经理对开发工程师设置为Won’t fix[J1] Suspend[J2] Reject的问题进行核实。

8)核实通过,保留开发工程师提交的状态,流程结束。

9)否则修改状态为Reopen

10)软件测试工程师对fixed[J3] Temporarily Solution的问题进行复测。

11)如果fixed的问题已经解决,关闭缺陷,流程结束。

12)如果Temporarily Solution的问题已经解决,保持不变。

13)如果fixedTemporarily Solution的问题还存在,reopen这个缺陷,回到步骤(2)。


注意:

所有的新添加的任务也放在JIRA中统一管理(Issue Type为New Feature或者Task),开发工程师接受缺陷或任务时,应该选择每一个缺陷或任务的fix version版本,表明这个问题在以后哪个版本解决,如果过程中没有及时完成,提交版本前请及时修改,否则软件测试工程师认为这个版本中的这个问题已经解决。

 

如果同一个问题有5处以上(含5处),软件测试工程师可以在这一轮中不进行相关问题的软件测试,问题由开发经理安排时间统一解决;如果同一个问题在同一个人身上发现2处(含2处),不是普遍存在的问题,交由开发工程师进行解决,软件测试工程师可以在这一轮中不进行对该开发工程师提交相关问题的软件测试。


如果软件测试工程师发现随机性错误,立即在JIRA中记录下来,以后发现第一时间内找开发工程师查看。如果随机问题半年没有出现,视为问题已解决,软件测试工程师关闭这个缺陷。


软件测试工程师应该经常检查需求文档与实际情况的差别,一旦发现问题,就记录到JIRA中(Bug Type为“需求文档错误”),开发工程师对这一类问题解决状态不允许为Won’t fixRejectSuspendTemporarily Solution


4.技术支持部问题提交流程


如图12-30所示:


image.png

12-30  技术支持部问题提交流程


顾翔凡言:

不是好的工作会给你带来好的心情,而是好的心情会给你带来好的工作。

目录
相关文章
|
SQL 测试技术 数据库
《软件测试技术实战 设计、工具及管理》联载-16
《软件测试技术实战 设计、工具及管理》联载-16
76 0
《软件测试技术实战 设计、工具及管理》联载-16
|
测试技术
软件测试技术实战 设计、工具及管理》联载-56
软件测试技术实战 设计、工具及管理》联载-56
61 0
软件测试技术实战 设计、工具及管理》联载-56
|
测试技术
《软件测试技术实战 设计、工具及管理》联载-8
《软件测试技术实战 设计、工具及管理》联载-8
91 0
《软件测试技术实战 设计、工具及管理》联载-8
|
缓存 网络协议 关系型数据库
《软件测试技术实战 设计、工具及管理》联载-22
《软件测试技术实战 设计、工具及管理》联载-22
107 0
《软件测试技术实战 设计、工具及管理》联载-22
|
SQL 编解码 前端开发
《软件测试技术实战 设计、工具及管理》联载-5
《软件测试技术实战 设计、工具及管理》联载-5
153 0
《软件测试技术实战 设计、工具及管理》联载-5
|
存储 敏捷开发 编解码
《软件测试技术实战 设计、工具及管理》联载-11
《软件测试技术实战 设计、工具及管理》联载-11
107 0
《软件测试技术实战 设计、工具及管理》联载-11
|
安全 Unix 测试技术
《软件测试技术实战 设计、工具及管理》联载-13
《软件测试技术实战 设计、工具及管理》联载-13
116 0
《软件测试技术实战 设计、工具及管理》联载-13
|
Web App开发 测试技术 Linux
《软件测试技术实战 设计、工具及管理》联载-9
《软件测试技术实战 设计、工具及管理》联载-9
125 0
《软件测试技术实战 设计、工具及管理》联载-9
|
传感器 编解码 测试技术
《软件测试技术实战 设计、工具及管理》联载-37
《软件测试技术实战 设计、工具及管理》联载-37
80 0
《软件测试技术实战 设计、工具及管理》联载-37
|
Java 测试技术 开发工具
软件测试技术实战 设计、工具及管理》联载-36
软件测试技术实战 设计、工具及管理》联载-36
118 0
软件测试技术实战 设计、工具及管理》联载-36