软件测试质量体系管控
迭代发布控制
1. 确认上线时间
开发转测试时间需要在需求文档评审完成后,与测试共同确认转测试时间以及正式上线时间。
2. 迭代周期一次
所有版本在转测试开始之后,根据迭代周期,确认转测试版本时间,不允许额外的bug修改造成的临时发布和打包
3. 超纲发布特批
如果遇到阻塞性问题确实需要重新发布和打包,需要上报研发技术负责人,说明原因之后,经过批准再发版。
4. 固定发版
从每个迭代版本开始,固定时间发布新版本,开发邮件确认已经装备好当天测试的版本以及确认合入修改的bug。
bug修改控制
1. 依据修改状态回归
测试以bug状态改为Resolved为开始回归的前提,未改状态的bug,测试不进行回归。
2. Bug提前处理
所有bug在发布前都需要解决完成,剩余充足时间给测试进行QA环境bug回归和QA环境回测,以及发布测试报告。
3. Bug打回升级
开发第一次修改bug未回归测试通过,在打回的同时,可以对bug进行升级处理,升级为严重等级,提高大家对修改bug的重视程度。(根据各公司实际状态跟开发沟通确认方案)
4. 带bug可发布
在预发布环境当天发现的问题或者发布当天发现的问题,可以经过与研发总结确认,讨论是否需要修改发布时间,建议非严重问题不再发布新版本和修改发布时间。
需求合入的控制
转测试后不合入新的需求
1. 在版本转测试之后,不再接受新需求的合入。
2. 如果有特殊情况,需要技术负责人协调。
同时测试接受在可推迟发布时间的前提下,合入新需求。
产品可提bug
如果在测试过程中发现&