我的測試生活感悟(2)

　　說實話，挺高的。我們目前對自己的要求是至少70%，我們認為追求過高的代碼覆蓋率的意義并沒有想象中的大。相反，過度要求高的代碼覆蓋率，可能會造成反面影響。

　　* 測試用例中對接口業務規則的驗證是否完整。

　　關鍵詞：業務規則，保證了業務規則，就保證了用戶使用的大部分功能。

　　* 測試用例中是否覆蓋接口之間的關聯性測試。

　　* 遺留的 bug對系統的影響程度。

　　* 測試用例與測試代碼是否一致。

　　我們主要通過CodeReview和自己的人品，并沒有做太多嚴格的審核。

　　* 測試用例是否可持續回歸。

　　* 經過測試的接口是否達到了調用方的標準，調用方能否使用該接口來開發出產品設計說明書所設計的應用。

　　可以看出，淘寶的接口測試評估標準還是挺全面的，做的確實不錯!非常值得學習!

　　5. 還可以繼續提高的地方(都是我們想要做的，就不一一點評了)：

　　* 測試數據管理框架構建與統一

　　* 接口測試項目構建基礎框架

　　* mock 框架化

　　* 高比例代碼自動生成框架

　　* 接口測試工具集與三方庫的本地化應用

　　6. 測試未來遐想(想象力確實很豐富啊，同樣也是我的夢想)：

　　* 測試虛擬化：提供接口測試虛擬機，構建測試虛擬化層。將被測系統運行在虛擬機中，與外部系統剝離，進行內部代碼檢測、內存檢測、數據校驗與邏輯檢測。

　　* 測試智能化：智能分析系統代碼，智能生成測試代碼，智能 mock 外部系統，智能執行測試代碼，智能分析測試結果，智能定位缺陷，智能修復缺陷。

　　7. 測試框架及工具組合：JUnit+DbUnit+Spring TestContext Framework+Unitils+TestNG+CruiseControl+Clover

　　感嘆一下Java相關的框架就是多啊，不像C++，難啊!我們的組合是：GTest + GMock + CCNET(MSBUILD+Svn) + 自己開發的C++代碼覆蓋率統計工具

　　談談面試

　　我是一個沒有什么經驗的面試官，偶爾才參與幾次面試。發現面試他人是一件技術要求非常高的工作，我們必須在很短的時間內了解一個人，如果方法不當，很有可能錯失一個人才或是招入不合適的人。最近又參加了一個結構化面試的培訓，由于之前并沒有專門去研究面試，整個講座聽下來還是蠻有收獲的。在講座之后，我們又繼續分享和交流了自己面試的一些感想和對結構化面試的一些看法。

　　1. 什么是結構化面試?按照我的理解就是：面試官使用精心設計的題目，讓應聘者作答，作答過程中對題目只重復不解釋，對解答的結果進行嚴格的評分?？梢哉f，結構化面試對面試官的要求非常低，不需要解釋題目意思，不回答應聘者提問，不需要隨機問任何其他問題，只需要對照答案填1或是0。因此，可以看出，結構化面試對題目的要求是非常高的。

　　2. 為什么需要結構化面試?很多時候，面試官都是依靠感覺去面試別人，問的問題也比較即興，感覺好了就招進來。然而，并不是每個面試官的感覺都是對的，依靠感覺做出的判斷經常會出現偏差。因此，就需要對面試過程進行結構化，形成固定的模式，依靠高質量的、全面的、科學的試題，來衡量一個人的綜合素質。

　　3. 應聘者只往好的方面答怎么辦?結構化面試的試題中，并不一定往好的方面答就能給分。

　　4. 冰山以上的職業技能容易被發現，冰山以下的職業素質、道德、心態是比較難發掘和衡量的。

　　5. 面試他人前一定要提前了解應聘者履歷，應聘職位的要求，準備一個安靜舒適的環境進行面試。

　　6. 面試時不要輕易打斷應聘者，不要發表自己的觀點，不要告訴應聘者你答錯了，不要把面試結果當場告訴應聘者。

　　7. 有的面試官比較自大，他們認為從來都不會輸，因為被他們拒絕的應聘者根本沒有機會展示他們的才能，而被他們招聘進來的人卻總是最好的。

　　8. 有的面試官優越感太強，總是想方設法難倒應聘者，以顯示其的威信。

　　9. 有的面試官不注重形象，給應聘者帶來非常不好的印象，從而對整個的公司的形象造成影響。

　　10. 應該先對職業技能進行面試還是對性格態度心理素質進行面試?我認為應該先對職業技能進行考核，然后再對其他方面進行考核。職業技能的要求就是最基本的，在其上再討論比如團隊合作，工作心態才有意義。

　　11. 我覺得不應該只招聘同樣性格的人，性格可以有多樣化，內向的，外向的，都可以。

　　12. 照搬結構化面試其實是不行的，一定要依據自身特點，進行合理的運用才能獲得最好的效果。

　　13. 面試是一個很大的學問，我現在只能領悟到這么多了。

　　不要被代碼覆蓋率蒙蔽雙眼

　　新年新開始，繼續我的測試生活感悟。“代碼覆蓋率”是一個有意思的話題，圍繞它的討論有很多?；旧?，人們都認識到了，代碼覆蓋率并不能說明測試的好壞，它只是一個度量方法，用于度量我們測試的廣度。它只能告訴你，你的測試代碼覆蓋了哪些被測的代碼，并沒有告訴你，覆蓋的被測代碼是否測試好。

　　代碼覆蓋率有諸多好處：

　　1. 能一定程度上說明測試覆蓋的廣度。

　　2. 通過代碼覆蓋率結果，能夠比較直觀的了解到哪些代碼未被測試，哪些分支未被覆蓋，進而補充相應的測試案例。

　　3. 代碼覆蓋率具有非常好的可操作性，可以在一定程度上衡量測試人員的工作。

　　4. 代碼覆蓋率給程序員和測試人員以信心。

　　但是，即使你的代碼覆蓋率達到了80%或者更高，不要被代碼覆蓋率蒙蔽了雙眼!

　　1. 好好回想一下覆蓋的80%的代碼中，你一共發現了幾個Bug?

　　2. 剩下的20%代碼，極有可能產生80%的Bug!

　　3. 覆蓋的80%代碼中，你真正進行驗證的代碼函數有多少?

　　4. 覆蓋的80%代碼中，你真正了解的代碼有多少?或者說，有多少代碼是無意間被執行的。

　　5. 你是否保證了不同操作系統下測試案例的執行?

　　6. 這80%覆蓋的代碼中，你是否偷懶省去了某些復雜的檢查點的檢查?

原文轉自：http://www.anti-gravitydesign.com