測試要考慮成本、粒度和角度問題

2019-11-18 11:13:10

字體：大中小

來源：轉載

供稿：網友

　　測試是需要成本的，也需要考慮當時當地的實際情況的，這就是一方面我非常強調測試，但也可能在特定的情況下完全沒有傳統意義的測試的原因。
　　
　　另一方面，對測試的理解和實踐是因人而異的（或者說存在某種進階，這種進階由軟件實踐的經驗和能力相對決定），根據進階不同，對其理解和實踐就會不同。
　　
　　在這里，包括單元測試究竟是不是設計以及在細致區分單元測試和測試用例都可以有不同的理解和實踐。這些理解和實踐沒有絕對的對與錯，而只是在粒度和看問題的角度上有所不同，或者說軟件實踐經驗的不同。
　　
　　但，盡管存在不同的理解和實踐，我們卻可以把分歧統一在一個前提下：
　　
　　那就是一切為了更好的軟件實踐。
　　
　　從這個基本點出發，測試可以被看作傳統意義的測試，也可以看作是設計的一部分或者是輔助設計，根據測試粒度的不同產生的其他的分歧也不再是問題，甚至是更具挑戰性的理解和實踐：測試可以看作測試，傳統意義的代碼本身也可以看作測試（從這里也可以引申為設計和代碼實踐的隨意性或者也可以說是一種非常自然的更高級的軟件實踐）。在我的軟件實踐里，我更喜歡這種實踐模式，當然，這是有前提的，他必須和具體軟件項目、人員、時間和其他輔助資源相適應，而不是一種必然選擇。顯然，在很多軟件環境下，我會采用適當保守的做法來保證我的隊伍可以輕松而且可靠地完成工作，這就是軟件賦予我們的靈活性。
　　
　　實際上，講到這里，怎么做可能是更好的實踐已經有了答案，盡管這個答案不是明確意義的對錯或者第1條第2條的方式給出的。我也試圖談論更多來更清楚這些回答，當然這些具體看法根據個體實踐經驗不同會存在不同的理解，這都是正常的。
　　
　　記住，這里沒有絕對性質的對錯，凡是能夠更好的輔助完成軟件實踐就是成功的。
　　
　　我們時常提到測試驅動開發，但實際上真正符合的不多，通常所稱的“測試驅動開發”只是有了單元測試而根本沒有驅動的意味。很多問題由此產生，在很多時候我們談論的差不多是兩個不同的概念。正常的情況下，測試是可以作為主要設計手段的，至少是極好的輔助設計手段，根據粒度和規模的不同，就體現為不同的具體實踐，包括傳統意義的單元測試來測試單個的對象或者更大規模的對象群，這都是正確的實踐。在這里，也可能存在測試轉化問題，也就是開始作為設計的實踐到后期的更趨向傳統的測試，這是更具體的實踐。
　　
　　測試成本的要素包含很多方面，是否寫了測試代碼只是其中一個重要部分，是否采用JUint以及Mock對象更加不是對其評價的決定性因素。對測試的更好評價應該是額外代碼、測試可重復性、測試范圍和邊界值識別等綜合構成（測試對設計的作用是更高級的判定）。
　　
　　對于涉及到數據庫持久方面的測試、涉及到UI（瀏覽器或者富客戶端）交互的測試以及多對象多方法過程的測試（也可體現為UI交互，這里是指獨立性質的）等，以及上面說到的一些問題（不再重復），是我們現實測試實踐要面臨的問題。對這些問題的解決，就會更多的涉及到項目具體情況的選擇和具體項目和團隊的情況來作最佳判定，這就是成本的意義。我在這里還想提醒在關注這些具體的項目因素的同時，還要注重下面的問題：
　　
　　對象的所有者和使用者問題；
　　
　　不要單純意義上理解測試，有些測試可以采用單元測試之外的手段完成；
　　
　　項目在不同進展階段測試的便捷性（也可體現為大分層概念）。
　　
　　測試，是一個理解和實踐都可能差異很大的軟件實踐，它包含了具體的代碼實踐，也是需要和項目治理和設計相適應的方法論，當然，也是體現實用哲學的軟件思想。
　　
　　在方便的時候，我很樂意具體闡述我在測試上的實踐經驗和教訓（如講座），也可以就我正在實踐和思考的更具挑戰性的思考和實踐進行探討。

上一篇：大道至簡Java23種模式一點就通

下一篇：JBuilderclass文件的Module引用