2.2 退测标准
10%以上（含10%）的冒烟测试用例没有通过。
新发现有5个以上（含5个）Blocker或Critical级别的缺陷。
版本发布的命名规则：
【"V"+X+"."+Y+". "+Z+ Name+"V"+X+". "+N+". "O+"-"+yyyymmdd】
比如，一个具体的版本说明：V5.1.2 Build V5.1.1-20150925。
含义：软件版本是5.1.2（V5版本的升级版本），这个版本是2015年9月25日发布的V5版本，需要提交给用户的里程碑版本，需要回归测试。
版本发布情况规定一般如下。
平均每两周发布一个小版本，一个半月到两个月发布一个正式版本。
发布一个正式版本后，两周后发布一个内部测试版本（这个版本仅作内部复测使用）。
两周后发布一个准发布版本（此版本需要对产品进行回归测试，开发工程师在此版本中只允许修改软件测试提交的缺陷，不允许添加任何新的功能）。
两周后发布正式版本（此版本软件测试工程师进行复测，回归测试后按照发布版本控制流程提交版本）。
如果在正式版本发布前的两周内需要添加非常重要的新功能，在接下来一周进行修改添加，一周后再发布一个正式版本。
两周后发布一次内部测试版本。
如果在执行过程中用户有非常重要的功能需要实现，可以在2～4天的时间内建立分支完成，但是不主张建立过多的分支，建立分支需要得到开发经理的同意。临时给客户一个版本，但要在正常流程中把分支流程合并进来。
版本发布一般放在周五，周五12点后开发工程师停止提交代码，等到软件测试工程师编译成功，打上Tag（标记）后，开发工程师才可以往SVN中提交新的代码。
3．软件测试缺陷提交流程
如图12-29所示。
3.1 步骤描述
3.1.1 流程启动条件
软件测试工程师在软件测试过程中发现一个新问题。
3.1.2 步骤
（1）软件测试工程师发现新问题，提交到JIRA，书写格式参考第7.2节。
（2）软件测试经理对提交的缺陷进行抽查。
（3）软件测试经理如果认为提交的缺陷有问题，就与软件测试工程师进行讨论。
（4）否则保留软件测试工程师的记录。
（5）开发工程师处理缺陷（软件测试工程师提交上的缺陷都要进行处理，处理没有解决的标记状态In progress）。
图12-29 软件测试缺陷提交流程
（6）对处理后的缺陷标示已处理类型。
（7）开发经理对开发工程师设置为Won't fix、Suspend、Reject的问题进行核实。
（8）核实通过，保留开发工程师提交的状态，流程结束。
（9）否则修改状态为Reopen。
（10）软件测试工程师对fixed、Temporarily Solution的问题进行复测。
（11）如果fixed的问题已经解决，关闭缺陷，流程结束。
（12）如果Temporarily Solution的问题已经解决，保持不变。
（13）如果fixed、Temporarily Solution的问题还存在，reopen这个缺陷，回到步骤（2）。
所有的新添加的任务也放在JIRA中统一管理（Issue Type为New Feature或者Task），开发工程师接受缺陷或任务时，应该选择每一个缺陷或任务的fix version版本，表明这个问题在以后哪个版本解决，如果过程中没有及时完成，提交版本前请及时修改，否则软件测试工程师认为这个版本中的这个问题已经解决。
如果同一个问题有5处以上（含5处），软件测试工程师可以在这一轮中不进行相关问题的软件测试，问题由开发经理安排时间统一解决；如果同一个问题在同一个人身上发现2处（含2处），不是普遍存在的问题，交由开发工程师进行解决，软件测试工程师可以在这一轮中不进行对该开发工程师提交相关问题的软件测试。
如果软件测试工程师发现随机性错误，立即在JIRA中记录下来，以后发现第一时间内找开发工程师查看。如果随机问题半年没有出现，视为问题已解决，软件测试工程师关闭这个缺陷。
软件测试工程师应该经常检查需求文档与实际情况的差别，一旦发现问题，就记录到JIRA中（Bug Type为"需求文档错误"），开发工程师对这一类问题解决状态不允许为Won't fix、Reject、Suspend、Temporarily Solution。
4．技术支持部问题提交流程
如图12-30所示。
图12-30 技术支持部问题提交流程
4.1 步骤描述
4.1.1 流程启动条件
当软件测试技术支持工程师在使用过程中发现一个新问题时流程启动。
4.1.2 步骤
（1）技术支持工程师发现问题，把问题记录下来。
（2）技术支持工程师书写问题提交单，书写格式参考第7.2节。
（3）技术部统一提交给研发部。
（4）软件测试工程师复测问题。
（5）如果问题存在，提交到JIRA中，按照软件测试缺陷提交流程进行。
（6）否则书写批注。
（7）技术支持工程师返测问题。
（8）如果问题不存在，关闭问题。
（9）否则与软件测试工程师讨论。
· 首先可以考虑提交截图、 日志等。
· 如果仍旧解决不了，则提供错误视频文件。
· 还是解决不了，通过视频会议系统。
· 最后可以考虑软件测试工程师到现场进行测试。
（10）如果问题不存在，关闭系统。
（11）否则由软件测试工程师提交到JIRA中。
技术支持人员在客户现场发现的问题应该在第一时间解决。
每周软件测试经理把JIRA上的Open、Reopen的问题发给技术支持经理。
5．用户版本发布控制流程
如图12-31所示。
5.1 步骤描述
5.1.1 流程启动条件
当技术总监要求向客户发布一个新的版本时流程启动。
5.1.2 步骤
（1）技术总监要求向客户发布一个新的版本。
（2）软件测试工程师进行打包。
（3）软件测试工程师进行冒烟测试。
（4）冒烟测试如果不通过，取消发布。
（5）否则软件测试工程师对此版本已经Fixed、Temporarily Solution的问题进行复测。
（6）软件测试经理书写软件测试报告。
（7）测试经理确定用户版本是否可以发布。
（8）如果可以，发布正式版本。
（9）否则交技术总监讨论。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
