過猶不及，這是古代《論語》中的乙個成語，做得過了就好比沒有做夠一樣。在軟體測試行業中同樣也會存在過度測試的情況，今天我就班門弄斧一下說說我對過度測試的理解。
很詳細的需求文件會導致維護成本劇增
我所經歷過的專案中有過幾種很有代表性的prd(product requirement document的簡稱，即產品需求文件）：1. 很詳細的文件，詳細到會定義乙個鏈結是新開乙個tab還是在原tab開啟，告訴你你想知道的一切資訊； 2. 包含了產品主要功能流程的文件，會以流程圖輔助說明，不會太細化，細節性的內容更多要通過交流和討論獲取； 3. 一封郵件說明或直接幾個人討論決定。
特別對於網際網路
專案，需求變更頻繁，需求資訊巨多，對於pm(產品經理)來說，完成一篇很詳細的文件需要的時間不說，每次的需求變更或評審後的需求漏洞都需要更新到prd中，對於測試人員而言，需要重新閱讀prd中改動的部分，而且詳細的需求就需要更詳細的用例來覆蓋，是否有必要這麼詳細的文件呢？對於網際網路專案能保持一年不大改都是少有的了，我們是否有必要考慮下不為文件所累呢。
詳細的測試用例會拖累我們
以前我的觀點一直都是秉承著乙個基準來要求我自己和團隊其他人來寫用例：讓不懂業務的人也能順手拈來執行用例。而在後來的一段時間，用例維護起來竟是如此頭疼，每次更新詳細的測試步驟和結果都需要大量的時間，而且發現專案中很少有讓乙個不熟悉業務的人來執行這些用例的時候，即便是新人來了看著用例仍然比較迷惑，仍然會多次詢問詳細的業務，發現還是prd看著更系統更有邏輯條例，能更快的了解業務內容。畢竟看著用例，我們彷彿執行了40，50條用例仍然在乙個功能上，根本不能跟其他功能串起來，對於業務的熟悉是多大的阻礙啊。我覺得從巨集觀到微觀再到巨集觀才是正確之道。而對於測試技能則更需要導師指導，並不能從用例中掌握太多東西，除了考慮問題的周密性外。
之前在維護用例的目錄時也有過度維護的情況，比如有ab兩個頁面都有乙個子功能c，每次回歸測試時需要對ab兩個頁面上功能進行回歸，避免遺漏，就把c對於的用例都copy到ab兩個目錄下了，那麼每次更新維護時也都需要維護多份，重複的工作
可想而知。
如何讓用例不拖累我們呢？
標題能說明的就無需步驟和結果，內容太多實在是放不下的時候再有詳細步驟和結果說明，可以以附件形式上傳excel**的多條用例，不要為了規範而規範，而且用例多是給測試執行人員使用的，不是為了讓新人了解業務而存在的。目錄結果過於臃腫的再優化，比如c有專門的目錄存放用例，ab下建個目錄僅說明有c這項功能，好比是linux下的軟鏈結，原來那種方式連硬鏈結都不如，它不能同步更新(ps.我們使用的是qc管理用例)。
過度設計的用例會降低我們的效率
你是否遇到過這樣的情況，比如有三個輸入框，但是沒有很強的邏輯關聯，只不過他們是必填項決定著是否能成功提交，如果設計出8個case來覆蓋是必填項這個條件才夠放心的話，對於有更多的輸入框時我們是否會崩潰掉呢？
另外一種情況，比如需要呼叫第三方分享，就說微博吧，我們是否需要覆蓋含有特殊字元的文字內容能否成功分享，超長文字內容能否成功分享?
上面這兩種很顯然是過度設計，我們完全沒有必要為了這類等價類邊界值的case用判定表方式來完成，像這型別很簡單的頁面控制項，應該編寫好統一的測試用例集，不同的也就是字元長度限制了。我們也沒有必要花心思來測試第三方軟體。當然工作中可能還有很多類似這樣過度設計的案例，工作經驗比較足的人都能從過往中總結出我們更有效的測試思路。
過度回歸測試會導致測試週期延長
什麼叫過度回歸測試呢？我總結成兩點：1. 測試過程中環境的不穩定性導致之前測試結果的不可信賴，剛剛還好好的地方又出現問題了，又得回過頭來跑一遍原來的用例，這樣反覆何時才是個頭啊?! 2. 回歸測試時我們總是要善於判斷哪些功能需要回歸，如果不想漏掉任何乙個功能會導致測試週期嚴重延長，也就需要全部回歸。
第一點解決好了測試環境的穩定性就可以避免，在測試每一輪次過程中保持**不隨意更新，資料庫
不任意更改不刪除插入資料，各種服務不任意重啟，讓每個case執行結果都是可信的，那麼會節省我們很多時間。
而回歸測試時，我們只要判斷好軟體功能間是否有依賴，內容就明確了。
1. 有關輸入：這些功能會不會處理同樣的輸入？？
2. 有關輸出：這些功能會不會在用於介面上顯示在同乙個區域？會產生同乙個輸出嗎？
3. 有關資料：是否會操作同樣的資料？是讀取還是修改？
以上只要有乙個答案是肯定的，那必然有依賴，就需要回歸一下。
過度自動化會讓我們力不從心
我經歷過以下兩種情況：1. 我們有時候為了盲目追求覆蓋率，會對一些簡單的基於頁面層面的case實現自動化，而這些內容適合自動化嗎？2. 有些自動化case種都是基於某個前提下完成的(比如登陸)，而為了追求case間獨立性，每一條都實現了該前提(登陸)，是否屬於過度自動化呢？
如果頁面改版，登陸功能重設計，對於**的改動量可想而知，我們需要找出那些頻繁地被拿來手動執行的用例，屬於業務核心的用例進行自動化開發，而且我們完全可以在測試方法之外額外實現乙個方法來實現登陸，只需要以下的所有測試方法都有異常捕獲並且在該方法執行成功之後才執行。
軟體測試的那些事兒 軟體測試行業探秘
軟體測試的那些事兒 軟體測試行業探秘 我曾經歷過這樣乙個專案，當時所在的公司急需上線一套新的系統來替代現有的系統，以滿足日益增長的需求，解決現有系統效能 功能瓶頸問題。由於需求時間非常緊，所以領導也來不急前期考察 調研，直接找了一家國內名氣比較大的軟體公司，細節也沒有溝通，直接說了粗線條的需求，然後...
自動化測試的那些事兒
什麼是自動化？編寫軟體去測試其他軟體 編寫驅動被測試應用程式的測試指令碼以執行鍵盤 滑鼠動作和後台程序並驗證應用程式響應和行為。手工測試的侷限性 無法做到覆蓋所有 路徑 機械 重複，工作量大 許多與時序 死鎖 資源衝突 多執行緒等有關的錯誤，通過手工測試很難捕捉到 進行負載 效能測試，很難通過手工測...
開發中Performance的那些事兒
效能 這個詞，不管是在日常生活還是寫程式的時候，都經常被提到。比方說，買新電腦的時候，我們會說 原來的電腦效能跟不上了 寫程式的時候，我們會說，這個程式效能需要優化一下 那麼，你有沒有想過，我們常常掛在嘴邊的 效能 到底指的是什麼呢？我們能不能給效能下乙個明確的定義，然後來進行準確的比較呢？在計算機...