3、 回归与更改点有关的基本功能,用户常用功能或操作;
3、 开发人员在修改bug状态的时候,要注明修改了哪个模块的哪些函数,这些信息有助于懂代码的测试人员去分析判断该bug是否真的修复好并对系统产生哪些影响。
测试人员:
4、 开发改好BUG后,先在开发环境下自行调试,然后安装版本到真实环境下,对更改点进行确认及按更改点影响到的功能点进行smoking test。控制好提交测试的版本,不出现影响测试进度的低级问题,如执行正常功能时失效,死机等。
开发解决了一个BUG,但同时引入了新BUG,测试人员在回归BUG时没有及时发现,这就叫回归不充分。这种现象不管对开发人员,还是测试人员都是相当痛心疾首的事。该如何彻底解决此类问题呢?有如下建议:
1、 首先开发解决问题时,须全面考虑,把更改方案记录来,并作好更改的影响分析,包括此更改对本模块、其他模块的影响,提出对测试的建议。
2、 在故障库上的BUG解决说明中附上更改说明及对测试的建议,对测试很有用,时间长了,需要时追溯起问题来特别有用。
5、 测试人员主动找开发人员、需求人员沟通,加深对系统业务,设计原理的理解,可以就回归BUG的测试点或测试路径与开发一起交流,扩展或缩小回归路径;
4、 在故障库的“验证记录”中列出所有回归的路径及内容(即bug回归路径的测试用例简述);
以上步骤都已完成,问题不再出现,验证通过,关闭此问题,置“关闭”状态。
6、 测试技术经理或主管对测试回归充分性进行监督与审核(回归不完善可能引发出系统严重问题,,故障库上留下的回归信息也方便项目组其他相关人员分析)。
开发人员:
1、 熟悉系统,各模块的关联关系,更改点会影响到的地方作好用户层的影响分析;
关键点:解决BUG的彻底性,回归BUG的全面性,与解决BUG的开发人员,回归BUG的测试人员对系统业务、软件系统逻辑的熟悉程度有很大关系。
文章来源于领测软件测试网 https://www.ltesting.net/