不管在哪一個時代, 品質是最基本最不可妥協的原則。
框架
你是否是編寫了不少代碼, 卻對所編寫的代碼缺少足夠信心? 若是代碼通過了嚴格的測試, 那麼, 你更可能會自信滿滿地說:「No Problem」, 儘管並不完美。
我也有「測試怠惰」的習慣。 歸結起來, 主要有三個緣由:
(1) 缺少清晰強烈的品質意識。 能跑通不就是最好的見證麼? 不就足夠了麼?
(2) 沒有寫測試的習慣。寫測試多沒勁多耗時間? 仍是作開發完成功能更有意思。
(3) 不知道如何寫測試。 大抵是知道寫點什麼, 但沒法構建比較完整專業的測試集; 此外, GUI 測試被認爲是枯燥乏味的無技術含量的, 不容易被承認。但仍是要作, —— 要完成一件卓越的產品, 沒有技術或非技術的差異, 只有用心與不用心的差異。
第一個問題的解決, 是在心態裏創建「品質意識」, 在時間上增長「測試時間」, 至少在心裏裏要給「測試」留下一席之地。第二個問題的解決, 是在項目開始時就構建好測試的目錄結構和框架。要是連測試目錄都沒有, 還能期望本身寫測試啊? 馬雲說, 連電腦都不買好一點的企業, 你能期望他們作成什麼事麼? 所以, 趕忙把項目裏的測試目錄補上吧。第三個問題的解決, 就是要多多閱讀測試方面的書籍, 多多練習了。《xUnit單元測試之道》, 《軟件測試實踐》, 《軟件測試的藝術》, 《測試之美》等。
寫不寫測試, 實際上涉及一個大局觀: 你是但願作出最終能讓客戶愛用受歡迎的好產品, 仍是隻爲了完成本身的那一小塊功能? 這是成就領導的關鍵氣度: 能作別人所不肯作之事, 能承別人所不能承之事。 大凡可以令人獲得提高的, 經常是那些本身不太願意作的事情。
萬事開頭難。 沒有運動習慣的人, 要他當即去跑步去健身, 很困難, 不過也能夠從一點一滴慢慢作起, 好比說在室內作作簡易的體操, 騎騎自行車等。
從簡單容易的作起
工具庫函數一般是獨立的, 無任何依賴, 遵循「輸入/輸出模型」, 而且很容易自動化, 只要設計出良好的測試輸入集合和指望輸出值集, 就能完成很好的測試。不妨從這個地方入手。 相關測試概念: 等價類劃分, 典型值, 邊界值,空值 。在這個層次上, 能夠學習和得到測試的不少基礎技能。
在項目初始時必定搭好測試框架, 強制編寫單元測試
必定要在項目初始時搭好測試環境和測試框架。 若是最開始不去編寫測試, 越到後面就越不肯意去補測試。測試越少, 軟件產品欠下的債就越多, 早晚有一天, 從軟件得到的收益將少於因測試不足致使的成本, 最終致使軟件產品失敗。 相反, 若是一直有良好的測試保駕護航, 就更有底氣作大膽的改進, 超越競爭對手。 開發與測試必須齊頭並進, 共同創造輝煌。 強制編寫完善的單元測試, 適當的模塊交互測試, 少許端到端測試, 足夠覆蓋實際場景的業務用例測試。
在「攻防戰」中提高
有時測試確實是很乏味的。 輸入一個值, 判斷輸出值是否合乎指望, 很容易失去新鮮感, 尤爲是 GUI 程序測試,手工測試真是既無趣又耗費時間, 可仍是要作。若是僅僅是爲了完成測試的任務, 很難達到測試的真正效果。 要真正創建「測試」的心態, 不妨將本身想象成一位極具攻擊力的殺手, 一位黑客, 千方百計去破壞程序的正常執行, 施加過量的壓力, 輸入非法值, 惡意值, 觀察程序的反應, 而後完善程序, 讓程序在「攻防戰」中不斷強大, 創建有效的工事。 也許在這個過程當中會喜歡上一件事。
開發與測試的合理分配與交替進行
測試的工做經常是繁重的。若是徹底投入進去, 也許會延緩開發進度, 擾亂程序的主進程開發。 最好的辦法是制訂時間比例, 好比 8:2, 八成時間用於開發, 二成時間用於測試。開發一段時間後轉向測試, 測試一段時間後轉向開發, 交替進行, 在開發與測試思惟之間進行切換, 也能夠保持思惟的活躍度。開發、測試、產品三種思惟, 以技術爲基礎, 可是各有側重。 若是同時兼具兩種或三種思惟, 會比單純擁有開發思惟的同窗更有優點。
集中強化訓練
若是平時真是沒習慣沒時間, 不妨抽出一個固定的時間段專門來練習測試技能, 培養測試習慣。 鍥而不捨是一件很難作到的事情, 尤爲是初期習慣還沒有造成時, 這時採用集中強化訓練的方法可能更有效果。一件事要作到必定程度, 纔會感覺到樂趣; 一件事要作到很嫺熟, 纔會進入創造的境界。 要多多學習測試的技能, 會寫測試纔會去寫測試。
承認測試的價值
在內心要承認測試的價值, 纔會作的更好。 不只要本身承認, 還要設法讓同事承認, 領導承認, 當你致力於添加完善的測試、改進產品品質時, 領導可以理解你這樣作的價值, 給予支持, 是最好的共贏。一般, 有必定技術背景的領導會更傾向於承認測試的價值, 甚至嚴格要求作好單元測試, 鼓勵作好單元測試。