项目初期的测试，程序不稳定，有的功能模块还没有做完，会导致在测试过程中遇到很多问题。
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
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
