再谈“虫子”的问题
很感谢“加大码”同志在上篇随笔的恢复,让我想起了许多问题。
常言道,千里之堤,毁于蚁穴,软件同样如此。虽然软件中的BUG本身不会像蚁穴那样慢慢变大,但对用户而言,它引起的错误/异常等的次数却会越积越多,最终我们会失去用户,造成不可挽回的损失,因此,这些质量的问题,我们必须注意,并制定相应的措施、计划、方案去预防、测试、修正BUG的出现。
至于如何做测试计划、如何写测试用例等之类如何预防“虫子”、如何查找“虫子”的文章比比皆是,但是发现“虫子”之后该怎么办呢?细想一下,这个问题并不十分简单。
首先,对于有明显“病症”的BUG,一旦出现,我们需要立即详细记录BUG的表征,记录的越细致越好,对于用户而言,这一点往往很难达到,因为用户往往没有这方面的意识,因而我们得到的反馈往往是“有一个错误”、“运行到**地方突然提示出错了”等之类模糊的BUG报告。对于这一点,不管是做项目还是做产品,我们都因该在程序中建立尽可能完善的缺陷机制,这样,我们的程序的容错性、健壮性、可靠性等才能得到基本的保障。那么对于BUG,我们在缺陷机制的设计中因该包含哪些内容呢?我认为至少我们应该有一个日志文件,来记录BUG的时间、原因、导致BUG的语句或方法、堆栈,甚至包含上下文数据的描述,当然,这是在不严重影响性能的前提下完成的。当程序员拿到日志文件之后,就能够比较容易的再现BUG,进而改正之了。
以上谈得是能够捕捉到的BUG。那么对于不能捕捉到的错误怎么办呢?我想在进行β测试之前,我们应该告诉参与测试的人员,一旦出现异常,应当细致的描述异常之前的操作步骤、使用了哪些数据、异常提示了什么,甚至干脆直接把异常抓图写在测试报告中,上面这些,在测试用例中都应有所体现。
上面是偶的一些经验和想法,偶不是做测试的,算是抛砖引玉吧,提供一点思路,欢迎大家讨论。