參考前兩版的測試問題，提出單元測試中較容易出現的錯誤，希望對提高單元測試質量有所幫助。
1.特殊字元錯誤
與提示限制條件不一致。如提示說只允許輸入*號，但實際可以輸入＋號
儲存成功，但其他介面呼叫提示錯誤。
最常出錯的字元有』」><%|-+.
2.極限值錯誤
雖然極限值是測試中最為常見的測試專案，但往往在測試驗證階段仍然會出現錯誤。
通常的錯誤有幾種：
u與提示限制條件不一致。如提示說只允許輸入20位，但實際可以輸入25位
u前台介面限制條件與資料庫儲存不一致。錄入50字元，儲存提示異常。
3.介面控制錯誤
l大小寫控制錯誤。介面控制區分字元大小寫，但儲存到資料庫時資料庫並不區分大小寫，導致儲存出錯。
l逆操作失效。比如審核單據可以成功，但取消審核提示錯誤。
l按鈕狀態控制不嚴格。比如單據審核後，提交按鈕需要置灰，但是沒控制導致報錯
l.顯示的規範性,比方說同一介面或不同介面的字型大小等. 如輸入數字型的字段時，要考慮整數字和小數字的長度控制.要注意介面、提示、選單、按鈕上沒有錯別字和病句,且漢字要顯示完整，不能出現一半漢字的情況
l產品的統一風格,如:備選框和選入框之間的選擇,有的用"選擇",有的用"<<",最好各界面都比較統一,特殊情況除外
l保證基本功能的使用,特別是介面功能,如預算的控制,介面選擇不出來預算專案或口徑等這些基本功能,往往很耽誤以後的測試程序
4.與其他產品介面錯誤
l與介面檔案定義欄位不一致。比如存貨規格允許輸入5位，但程式是按照4位來判斷，導致錯誤。
l產品內不同介面顯示不一致。比如某指標乙個模組定義了一種經濟含義，但在另乙個模組顯示該指標時，顯示的是另一種經濟含義。控制介面有誤。
5．希望儘量減少復問題的比例，特別是影響重大的反覆問題，如不能登入產品，修改後功能失效等嚴重影響測試工作進度的問題。
總結：雖然以上問題只是介面的控制，與業務流程，產品功能相比，不是很重要。但是從產品規範性來說，給使用者留下產品不夠專業的印象；從實施交付來說，如果出現問題導致的程式錯誤，實施通常很難自己解決，必須要開發出補丁解決；對於單元測試，和聯調測試，上述問題始終是測試的重點。特別是聯調提交整合，因為是測試部人員驗證，他們大多不會深層次了解產品，因此切入點一般會以特殊字元、極限值等常用功能，但組內可能會遺漏的方面測試。如果特殊字元控制不嚴，會影響提交。希望影響大家注意。
單元測試和測試驅動開發的一些常見問題總結
microsoft unittestframework 如果需要元素的順序一致，可以使用collectionassert.areequal 如果不需要考慮順序，可以使用collectionassert.areequivalent。有的地方說mstest的assert.areequal支援集合型別比較...
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...