加强代码测试

  1. 云栖社区>
  2. 博客>
  3. 正文

加强代码测试

沉默王二 2015-04-24 22:04:35 浏览639
展开阅读全文
版权声明:欢迎转载,请注明沉默王二原创。 https://blog.csdn.net/qing_gee/article/details/45252073
代码测试,无疑是编程环节中重要一环,重要到什么程度呢?假如治理雾霾就是编程,如果想把雾霾治理好,最最重要的无非就是减少工业污染,而代码测试就是这样,它能够从根源上就杜绝bug的发生。实战经验告诉我,在编程的过程中,当你顺利的把代码敲完毕了,那么及时的跟上一次代码肉眼扫描,以及通过SVN版本库的对比,或者是和你认可的同事进行代码的检测,当你对重要的代码写一小段测试用例后,你会发现,你已经能够修正了大量的bug,如果按照bug10个量记的话,一遍代码测试能够做到7个bug的消除。

与客户患难与共

我曾经也一度认为,远离客户,远离用户群,会让我一个做技术的开发人员进入到编程世界的“桃花源”,那里不再有任何嘈杂的声音,没有你厌恶的那种“小白”,更能让你远离那些无知的“需求”。

然而就如同作者所说,用户才是与代码休戚与共的人,而我们一旦完成了代码的编写,很多情况下,我们就如同和代码之间隔了一座巫山,从此不再相见。而那么用户,会被迫的和你的代码成天的打交道,他们对你的代码有着最真切的体验。

由于工作角色的问题,我必须在交易平台的项目中身兼数职,从客户需求的分析到产品的上线运维,我必须亲力而为,自然的与客户就要经常打交道,我发现,我所负责的代码,客户用起来远远要比我熟练的多,他能让交易的K线图呈现完美的走势,而我,只有羡慕的份。而他们也是发现软件问题的最重要的人,刚开始,我认为他们反馈的问题是“无稽之谈”,然而相对而言,如果他们都能发现软件的问题,为什么我们不能做的更好的呢,很多时候,和客户打成一片,会让我们能够更好的保证软件的质量。

混世魔王

很多时候,软件在测试的环境下,什么问题也没有,然而一旦正式上线,各种莫名其妙的问题就会不断涌现,我们有的时候会感到无助,因为这些摸不着头脑的问题让人无从下手,对于这些问题,多半情况下,我们准备不足。

那么如何才能从容自如的处理这个问题呢,作者说要创造一种混世魔王,为程序添各种乱子,让我们能够从日常的实战中就获得足够的处理经验,另外提升我们的软件处理能力,对一场情况有着更佳的处理方式。

虽然目前阶段,我们做不到增加一个混世魔王出现,但是我们要保证,让程序足够的健全,尽量让程序去处理一些边缘情况(出现几率比较高的),这样能够保证我们的程序不再那么脆弱。另外,在上线测试之前,一定不要相信你的程序什么问题都没有,有的时候,别人会给你埋坑的,你会被迫的跳坑的。

代码评审

同级之间的代码评审是你为提高代码质量所能做的最大贡献。

在一个软件维护的组织里,在引入代码评审之前,55%的维护代码改动都是错误的,在引入代码评审后,错误率降到了2%。

从实际的经验开发中,我不难发现,有一个值得你信赖的评审者,让你倍感欣慰和荣幸!经过一个负责人的检验后,他会帮你筛选掉你花费大量时间都不能发现的问题,从自我体会来说,代码评审太重要了,我已经不想再重复这个话题了,记得找一个你信赖的人进行评审。

加大测试力度

原本以为昨天已经是对接华夏银行测试的最后一天,紧张了一个星期的神经要稍微的放松了一下,然而,就在今天早上进行清算对账的时候,原本的代码存在很大的漏洞,关于出入金的明细核对,在处理方式上显然没有做到“仁至义尽”,还埋着很多坑。而昨天晚上睡觉前的反省,也让自己发现对于冻结资金的处理,是不应该每日累加的。

这一切都足够的证明,测试根本就不是想象中就能完成的,即使在脑袋能够想到的方方面面,我们已经处理的足够优秀,然而,面对现实测试的时候,程序依然显得那么脆弱,还需要再进行精雕细琢,还需要加大测试力度,如果我们认为一个问题经过两三个测试用例后,就不会出现错误了,显然是不可能的!

单元测试

大家对于单元测试的接受,已经成为软件开发领域在过去5-7年里最大的进步之一。

我们很多人都用户junit,这东西在很大程度上能够帮我们完美的测试出当前类,当前方法存在的漏洞,以及性能如何。那么我想列出来我认为非常棒的“测试先行”的观念,因为之前在优化服务端的交易撮合速度,就是靠着单元测试的出来的:
  • 降低修复bug的成本
  • 它比直接写代码的效率更高
  • 帮助你不破坏现有功能的基础上持续改进
  • 可以作为示例代码

单元测试和beta测试

只有当你把你的代码交给beta测试人员后,真正有价值的测试才算真的开始。

的确,beta测试最能模拟真实的线上运行场景,beta测试已经成为众多软件开发的标配。我们当前的期货交易系统,在每次修改代码后,都会更新到对应的测试服务器进行相对真实环境的测试,用来尽可能的在上线之前解决问题,而这的确帮助了我们太多。

低保真的可用性测试

如果你不找来真正的用户做可用性测试,你无法知道你的程序能否正常工作。

这个无需多言,对于我们小型企业和团队来说,去找到合适的群体对产品进行可用性测试的确比较困难,但是我们必须尽量去做。很多时候,迫于无奈,我们没有这些群体,只能勉强通过自己的自我测试后,就要着急上线,而上线后,很多时候无法面对真实环境的使用压力,bug最终会压坏产品,我们的确也曾这样失去一个客户。

比程序崩溃更糟糕的是什么

到目前为止,我发现Java的异常处理已经被我们多数人玩坏了,随处可见的try catch能够让看得眩晕,为了保证程序的“健壮性”,考虑到用户的体验,我们把错误一层层的包装起来,当遇到错误的时候,我们很友好的提示用户耐心的等待,这在很多时候,让用户颇感无奈。

看到作者这篇文章,心有戚戚然,“快速失败”真的非常重要,让用户的数据在出现错误的时候,能够不至于丢失。我们没有必要把错误藏在深处,当然Java的事务回滚,能够帮我们做很多,然而尽量不要在try 中再包含try,尽量让错误中止接下来的代码继续运行,让你能够尽快的定位到问题发生的根源,尽快的解决掉问题

网友评论

登录后评论
0/500
评论
沉默王二
+ 关注