经常有人会问我,软件出了问题,修改了代码,怎么做验证? 当然是回归测试啦!——我通常都会给出同样的回答。 可是,实际上很多获取了GJB5000资质的组织,软件修改之后,还只是软件工程师编译通过之后就直接提交去应用,根本不进行回归测试,甚至也不做更改测试。 这种修改代码的方式,被称之为“编辑并祈祷”——软件工程师按照自己对问题的理解找到代码中错误位置,修改、编译之后就祈祷通过联试或相关的实验。 可是,这种听天由命的方式并不都是很“灵”。这样修改的软件提交上去,问题可能根本没有解决,或者解决了当前问题,却又出现新的问题。
这个故事说明,科学来不得弄虚作假,靠祈祷而不是回归测试来验证修改的正确性是行不通的。 正确的修改代码方式是“覆盖并修改”。这里说的“覆盖”是用测试覆盖验证修改部分是正确的,同时修改也没有引入新的Bug。 换句话说,就是要做好回归测试。 也许有人会说,联试/实验任务那么紧张,我没有时间进行测试? 那么,如果不进行测试,软件在后续的联试/实验中出现问题,你就有时间解决问题吗?在联试/实验前花费测试人员和开发人员一点时间验证正确地进行了修改所需要的时间多还是在联试/实验过程中出来问题,暂时中止联试/实验,等待软件修复所需要的时间多? 明明可以第一次就把事情做对,为什么非得要事后补救?
如果组织能够实现自动化测试,那么回归测试的成本会大大降低,组织也就不用担心“覆盖并修改”的修改代码方式花费的时间太长。 你的修改代码方式是“编辑并祈祷”还是“覆盖并修改”? 这正是: 代码修改需验证,光靠祈祷可不中 验证测试要回归,更改测试还不行 参考书目:修改代码的艺术,作者:(美)费瑟(Michael C.Feathers)著,出版社:机械工业出版社 |
|