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