本系列文章主要的目的是提高大家對代碼的單測意識, 其中文章主要會分享單測過程中,常見的測試場景及這些場景的解決方案和處理思路。 為了能使大家更好地了解單元測試,作為程式員會從源碼入手,分享JUnit的運作原理。在了解了JUnit的原理後, 再回顧我們的問題場景,那由于内容較多,小編會分篇進行分享,文章脈絡大綱已列出如上圖所示。各位客官請自行取用。
很多人說單測沒有意義, 這是完全不正确的思想。相信随着碼齡增加你會越發的認同這句話。據國外研究統計軟體系統中最大的成本是 維護成本,是以你能看到凡是開源的架構單測一定是非常豐富的,因為它要去疊代更新,要去向下相容版本。如果沒有單測那就是完全的黑盒。 是好是壞聽從天意,這是沒有品質保證的。這點是軟體系統都具有的是以說就這一點,就證明了單測的必須性。下面談幾個不寫單元測試的說法。
或許說中國的國情跟國外的不一樣,中國的系統或者說是業務系統更新的快,單測用完就失效。寫單測會壓縮開發時間,導緻任務延期。從眼下看是壓縮了開發的時間,但是它提高了開發的品質,一定程度上減少了系統的維護成本。其次單測并不是說要對你所有的方法進行測試, 這個要針對業務系統情況,把系統的核心業務中使用到的核心方法進行詳細的單測維護即可。系統的核心邏輯是不會經常變動的, 是以這部分的單測就是你整個單測的核心。
像一般政府的項目基本都會給到外部的公司來競争,部分的外包公司隻注重傳遞,不注重品質。或者說這個項目就是一個xx工程, 沒有實用價值。 隻要上線就行。也不用維護。對于這種的确實作狀是都不會寫單元測試。(因為整個項目就是沒有任何實用價值)
代碼是有溫度的,養成好的習慣從自己做起。好習慣會傳染,需要一個好的帶頭人。團隊内部成員每個人都有自己負責的功能區域。 隻要每個人針對自己的功能區域的核心計算邏輯寫好單測,那麼一定是好處大于壞處的。另外要寫在平時,不要專門找時間來寫代碼。那樣就容易把單測當做是任務去完成,就失去了寫單測的意義。
相信你所認為雖然很正确,但是做起來很傻逼的事情,一定有人在默默的堅持着。努力做一個優秀的人。
自己測完了,要測試幹嘛。首先如果你有這樣的想法,那麼一定是因為你不了解測試的工作。測試是開發的補充,他一定不是開發的保姆。測試 是對應用或系統的整體場景或者說功能的驗證, 他不能對你代碼的最小單元進行驗證。所謂代碼的最小單元一定是開發同學最了解的,代碼的最小單元 就是你定義的代碼塊,方法,技術架構。這部分測試同學是無法幫你驗證的。我們這裡舉一個例子。
軟體工程師好比是蓋大樓的,具體每一堵牆磚頭如何擺放,房間如何設計,是否關注采光這是你設計師要幹的事情,而測試好比品質驗收,會看你整棟 大樓是否有傾斜,水電瓦斯是否可以使用。測試同學并不了解所有的細節。
開發和測試看到的東西不是完全一樣的,越往上測試的黑盒越大。
當然如果公司對這個有要求,一定會有應付的辦法。最差的情況就是全部都是為了應付而寫代碼。從價值觀上來看,這是不對的。從實用性上來看這是沒有任何價值的。那麼如何解決這個辦法呢? 價值觀來保證咯。那麼就需要一個名額了(非硬性名額), 把資料量化展示出來,作為應用品質的一個參考的因素。 就算你全是應付而寫,也一定有一定的價值。
另外要說一點的是單測行覆寫率高不代表應用的品質就一定高,但是單測行覆寫率低一定代表着這個應用出現品質問題的可能性就越大。 這無疑增加了業務風險和測試成本。為了減少業務風險和測試成本,希望大家提高對單測的意識。
那麼我們在上升一點總結下如何提高應用的品質呢? 請看下文
應用品質如何來衡量, 這是一個完全可以通過名額來進行衡量的。那麼究竟如何名額化呢? 這裡首先對應用品質進行一個拆分。
可以将應用品質分為兩種:
代碼程式設計品質(程式設計風格)
業務程式設計品質(業務是否清晰,異常場景的考慮)
代碼程式設計品質往往隻的是開發人員的程式設計風格,基于團隊成員風格的相似度。 也可以說是代碼的可讀性,可維護性,方法的複雜度,方法的執行效率。這個是最容易名額化處理的。 基于規則引擎,進行靜态代碼掃描就可以掃描出。Sonar 或者 阿裡規約都可以完成。 他們都會把問題分為四個等級Blocker, Critical, Major, Minor/Trivial。
即系統無法執行、崩潰或嚴重資源不足、應用子產品無法啟動或異常退出、無法測試、造成系統不穩定。
即影響系統功能或操作，主要功能存在嚴重缺陷，但不會影響到系統穩定性。
即界面、性能缺陷、相容性。
即易用性及建議性問題。
品質分計算
對軟體設計的最小機關進行正确性檢測，如函數或一個類的方法。
UT由開發同學保證,開發同學進行最小單元測試, 那麼資料名額如何進行衡量呢?
基于Jenkins的 Jcoco 插件,會統計行覆寫率，類覆寫率，複雜方法覆寫率等。輸出一個 可視化的圖表
IT場景測試，将後端接口,按照業務流程的順序編排成自動化的場景用例。
當然能做到這些的一定是體量不小的公司,對于小公司而言,要的是靈活開發快速疊代，出現問題,快速發現及時補償即可。是以這篇文章可能不适用于小公司内進行營運。因為這些不僅對開發者的要求高，而且對測試也有不小的要求。但是相同的是, 有一點是一樣的。就是不管是開發同學還是測試同學都應該提高對單元測試的認識。要知道: 單側不是目的而是提高應用品質的手段。
對于管理者來說，應用品質的名額是完全可以可視化展示出來的。後面小編會一步一步來搭建這個應用品質可視化方案和單元測試的分享。
本文屬于開篇隻講概念後面會講到使用到的技術。和如何搭建一個可視化的平台。感謝閱讀。
最後求關注,求訂閱,感謝您的閱讀，本文由西魏陶淵明 版權所有。