软件测试让我更爱开发
作者:网络转载 发布时间:[ 2012/7/23 13:54:45 ] 推荐标签:
大家很幸运,没有经历过产品代码只有在某几个人电脑中有情况。来到百度知道SCM,知道SVN,但是对配置管理还是认识不够。边写代码边考虑目录结构,意味着会忽略测试脚本的存放目录;测试机和本地还有别人不知道的自测脚本,意味着没有做到测试case与代码同源,没有真正意识上的自动化。想起以前开发团队中的两个同学,提测质量都很高,都做单元测试。不同的是,A同学使用xUnit写测试case并提交配置管理,B同学是用main函数来做单元测试且不提交配置管理。B同学平时测试时重新main,或到本地找测试case的成本自己是可以忍受的,终于有,系统崩溃了,所有的测试case都没了。
开始单元测试前,花时间了解一下“没有技术含量”的配置管理,能让你的单测case发挥更大的作用。
开始了单测,但依然是被动接受
也许骨子里是将开发和测试严格分离,很长时间都是先写完代码才考虑测试。其实很多开发人员都有我同样的习惯,成千上万代码完成后,再来补单测的心情可想而知了。是不是的会冒出这样的想法:写类似接口测试的单测尽快达到覆盖率吧;测试几个重要函数算了;单测做得太完美了,QA做什么?这些想法说明了做单测时的被动,单测的效果无疑会大打折扣。在这种想法的驱动下,“大单测”的概念也会产生,接口测试和单元测试的差异也被模糊,自然不会理解没什么还需要QA?为什么要用stub或mock?
单测能帮助你尽快验证提交的代码。每日为自己生产的代码增加单测case,使用stub或mock技术隔离依赖,代码提交前在本地执行单测case(local build),这些好的习惯无疑能消除你补测试case的苦闷,主动的单测。每日的一小步,让你代码质量更高,睡得安稳。
代码需要呵护,持续重构
单测的意识在不断的提高,然而新的苦闷又来了。成长的代价,让我留下了太多没有单测的代码,它们依然在使用、在升级,下定决心来补充单测吧。“这代码怎么写得这么烂?”“这个函数我没法写出单测case了”,自己给自己挖了很多坑。这时,是放弃单测还是重构后继续单测?从短期成本来看,应当放弃;但长期来看,必须重构。每一个开发人员都希望大家认可自己的代码,希望有写代码的成感:功能好用、性能优良、代码很美。不可测的方法、代码中的坏味道需要找时间将它们消除掉,唯有持续重构:在修改bug时顺便重构;在增加新功能时重构;利用CR的机会重构。为了那一份荣耀:读你的代码如欣赏优美的艺术品,这些工作都值。
到处,我已经不再仅仅考虑软件的外部质量,而会同时关注内部质量,可测性、洁净代码原则和方法,我都会考虑,开发活动因此而更加丰满。
不再只是小码工,也是架构师
经历了将模块全面推翻重构的苦痛(严格说是重写了),我们会开始思考,为什么不能将思考提前,为什么不能未雨绸缪呢?现在我们还是完整的详细设计,开发,再测试,不过我们每天都为提交的代码写测试case,及时的发现代码可测性问题。测试和开发依然界线分明,为了实现设计而编码,为了验证编码而测试。能不能将测试case提前?能不能让测试来指导设计?TDD终于出现了。我是08年接触到TDD,不过现在它依然很“新”,没有被广泛的实践,它将带来开发模式的变革。
用一句话描述TDD:写代码是为了修复失败的测试。它是一种分析技术、设计技术。
测试先行,开始编码前你已经想到了怎么去测试、准备好了测试case,代码可测性问题提前考虑,依赖倒置原则(DIP)、开闭原则(OCP)、单一职责原则(SRP)都会用来指导你的设计,这样的代码写起来感觉很好。你又向前迈进了一步,不再只是小码工,也是架构师了。
测试让我更爱开发
一路走来,我的单测意识在升华,经历单测之惑、单测之需、单测之痒、单测之法、单测之美,消除了开发中的许多烦恼,有了一套可预测的开发方法,知道什么时候可以完工,不再担心长期被bug困恼;能不断的重新认识代码,重构它让架构更合理。测试让我享受着设计和开发,让我更爱开发。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11