关于测试的目标:
每个人都知道测试是找bug的,那测试的终极目标是零bug吗?
当然不是,且不谈零bug这种理想状态是不可能实现的,有时候我也会想如果程序没有bug是不是一件非常枯燥的事情,就跟猫没有老鼠捉一样,想来是的。
执行测试的标准应当是在测试成本和用户容忍度中去找到一个合适的平衡点,过于极端都是不可取的。可能bug对于开发来讲都是一样的,但是在测试这里应当是有权重的,
一个测试应该理解业务的价值,去引导bug修复的必要性与优先级。
关于测试与开发:
一个很经典的比喻是将软件开发的过程比作修房子,开发一匹砖一匹砖的往上建造,测试拿着一条垂线到处丈量。如果先建再量,房子歪了就要推倒重建,但如果一开始就放好垂线,修好房子的成本会大大缩减。这也是测试驱动开发的价值所在。
房子建好后,开发A说这个厨房我建的,开发B说这个阳台我设计的,测试说这个房间我玩过,那个房间我也玩过,一边得瑟自己看得多,同时又遗憾房子这么好看但不是自己建的。所以你更喜欢扮演哪种角色呢?
关于测试的绩效:
有听说很多团队会用找到的bug数来衡量测试的工作成果,同时又用bug的泄露数来衡量开发的绩效,这种对立的关系我个人是非常不喜欢的,测试为了数量提很多无关痛痒的毛病或者将一个问题拆分成多个提,开发不服气啊整天跟测试吵架。这样的氛围,长期来看绝对是弊大于利的。
如果一个测试每天都能发现很多bug,我首先想到的不是他有多厉害,而是去想他有没有思考过bug出现的根本原因。是不是整个开发的流程上就是有问题的,一个合格的测试要测试的不应当只是产品,并且要关注整个开发的流程是不是合理,如何优化。这也从一方面反映出bug数量绝对不是测试绩效的标准。
用一句我好想理解了又好像没理解的话结束此文:
测试不是要证明程序是对的,而是要证明程序没有错