项目初期的测试,程序不稳定,有的功能模块还没有做完,会导致在测试过程中遇到很多问题。
1. 最基本的功能存在问题;
基本功能的问题一定要隔离清楚,如果发生错误的现象千奇百怪,在写bug的时候,Description可统一概括为失败,然后在bug主体中详细列出具体的现象;
没有必要隔离什么情况下出现什么结果,由于存在很多不确定的因素,一些现象的发生条件摸不准,隔离这些情况往往会花费很多时间,而只要把问题报给developer,他们自会知道问题所在。
2. 其他模块也出现问题,分不清是基本功能导致的,还是其他模块本身的问题;
对于这种问题,如果是在操作过程中就已经出现了其他bug,通过”绕道”的方式走到这一步出现问题,那么可以先不报bug,有可能是前面的问题导致后面的问题,等前面的bug解决后,再验证这个问题发不发生;如果在操作过程中没有其他问题,到了这一步才出现问题,我们可以提交bug,至于bug发生的原因由developer来分析。总之,不管什么解决方法,不能让问题漏掉,也不能让问题重复的报bug,给developer带来不好的影响。
在这时,可以通过每个模块的现象来大致了解相互之间的联系,比如A模块的某个功能出现bug,B模块的功能也出问题,A模块的问题解决了,B模块的问题也随着解决,或许A模块和B模块之间有某种联系,那么以后在分析bug的时候,可以查一查相关模块的功能。
3. 问题太多,导致测试根本无法执行,几乎所有的case都是failed;
项目初期,很多问题都存在,甚至最基本的安装都会出错。这个时候的测试重点应该是软件框架,看看流程合不合适,软件设计合不合适,有意见尽早和developer商量。
初期,很多事先设计好的config都运行失败,此时就不必在QC中添加run,即使添加了,也会有80%以上fail,没有意义。
版权声明:本文出自 chenyuting89 的51Testing软件测试博客:http://www.51testing.com/?414547
原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。