无论在哪个时代， 品质是最基本最不可妥协的原则。
你是不是编写了很多代码， 却对所编写的代码缺乏足够信心？ 如果代码经过了严格的测试， 那么， 你更可能会自信满满地说：“No Problem”， 尽管并不完美。
我也有“测试怠惰”的习惯。 归结起来， 主要有三个原因：
(1) 缺乏清晰强烈的品质意识。 能跑通不就是最好的见证么？ 不就足够了么？
(2) 没有写测试的习惯。写测试多没劲多耗时间？ 还是做开发完成功能更有意思。
(3) 不知道如何写测试。 大抵是知道写点什么， 但无法构建比较完整专业的测试集； 此外， GUI 测试被认为是枯燥乏味的无技术含量的， 不容易被认可。但还是要做， —— 要完成一件卓越的产品， 没有技术或非技术的差别， 只有用心与不用心的差别。
第一个问题的解决， 是在心态里建立“品质意识”， 在时间上增加“测试时间”， 至少在内心里要给“测试”留下一席之地。第二个问题的解决， 是在项目开始时就构建好测试的目录结构和框架。要是连测试目录都没有， 还能指望自己写测试啊？ 马云说， 连电脑都不买好一点的企业， 你能指望他们做成什么事么？ 因此， 赶紧把项目里的测试目录补上吧。第三个问题的解决， 就是要多多阅读测试方面的书籍， 多多练习了。《xUnit单元测试之道》， 《软件测试实践》， 《软件测试的艺术》， 《测试之美》等。
写不写测试， 实际上涉及一个大局观： 你是希望做出最终能让客户爱用受欢迎的好产品， 还是只为了完成自己的那一小块功能？ 这是成就领导的关键气度： 能做别人所不愿做之事， 能承别人所不能承之事。 大凡能够使人得到提升的， 常常是那些自己不太愿意做的事情。
万事开头难。 没有运动习惯的人， 要他立即去跑步去健身， 很困难， 不过也可以从一点一滴慢慢做起， 比如说在室内做做简易的体操， 骑骑自行车等。
从简单容易的做起
工具库函数通常是独立的， 无任何依赖， 遵循“输入/输出模型”， 并且很容易自动化， 只要设计出良好的测试输入集合和期望输出值集， 就能完成很好的测试。不妨从这个地方入手。 相关测试概念： 等价类划分， 典型值， 边界值，空值 。在这个层次上， 可以学习和获得测试的很多基础技能。
在项目初始时一定搭好测试框架， 强制编写单元测试
一定要在项目初始时搭好测试环境和测试框架。 如果最开始不去编写测试， 越到后面就越不愿意去补测试。测试越少， 软件产品欠下的债就越多， 迟早有一天， 从软件获得的收益将少于因测试不足导致的成本， 最终导致软件产品失败。 相反， 如果一直有良好的测试保驾护航， 就更有底气做大胆的改进， 超越竞争对手。 开发与测试必须齐头并进， 共同创造辉煌。 强制编写完善的单元测试， 适当的模块交互测试， 少量端到端测试， 足够覆盖实际场景的业务用例测试。
在“攻防战”中提升
有时测试确实是很乏味的。 输入一个值， 判断输出值是否合乎期望， 很容易失去新鲜感， 尤其是 GUI 程序测试，手工测试真是既无趣又耗费时间， 可还是要做。如果仅仅是为了完成测试的任务， 很难达到测试的真正效果。 要真正建立“测试”的心态， 不妨将自己想象成一位极具攻击力的杀手， 一位黑客， 想方设法去破坏程序的正常执行， 施加过量的压力， 输入非法值， 恶意值， 观察程序的反应， 然后完善程序， 让程序在“攻防战”中不断强大， 建立有效的工事。 也许在这个过程中会喜欢上一件事。
开发与测试的合理分配与交替进行
测试的工作常常是繁重的。如果完全投入进去， 也许会延缓开发进度， 扰乱程序的主进程开发。 最好的办法是制订时间比例， 比如 8:2， 八成时间用于开发， 二成时间用于测试。开发一段时间后转向测试， 测试一段时间后转向开发， 交替进行， 在开发与测试思维之间进行切换， 也可以保持思维的活跃度。开发、测试、产品三种思维， 以技术为基础， 但是各有侧重。 如果同时兼具两种或三种思维， 会比单纯拥有开发思维的同学更有优势。
集中强化训练
如果平时真是没习惯没时间， 不妨抽出一个固定的时间段专门来练习测试技能， 培养测试习惯。 持之以恒是一件很难做到的事情， 尤其是初期习惯尚未形成时， 这时采用集中强化训练的方法可能更有效果。一件事要做到一定程度， 才会感受到乐趣； 一件事要做到很娴熟， 才会进入创造的境界。 要多多学习测试的技能， 会写测试才会去写测试。
认可测试的价值
在心里要认可测试的价值， 才会做的更好。 不仅要自己认可， 还要设法让同事认可， 领导认可， 当你致力于添加完善的测试、改进产品品质时， 领导能够理解你这样做的价值， 给予支持， 是最好的双赢。通常， 有一定技术背景的领导会更倾向于认可测试的价值， 甚至严格要求做好单元测试， 鼓励做好单元测试。