qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          軟件測試bug收集策略

            Error = 0 的程序是不存在的,怎樣收集和處理程序中的錯誤?怎樣更好地利用錯誤信息的收集和反饋來協助程序的調試?怎樣讓產品發布后,用戶能夠反饋出更有價值的問題 信息?這些問題是本文將要涉及的,最近對自己所做項目中的錯誤處理機制做了一些總結與思考,故在此討論,希望對大家有所幫助。

            目前,按照我個人的理解,軟件中的錯誤收集和反饋方式主要有如下幾種:

            第一種方式:使用常用的信息輸出語句。

            對于控制臺程序,可以使用 printf 語句或者 std::cout 將錯誤信息打印出來;對于MFC程序,可以使用 TRACE 宏,將錯誤信息輸出到 output 窗口,或者使用 MessageBox直接彈出對話框將錯誤信息告知用戶 。

            這些處理策略往往針對于 “交互性” 的代碼段,可以實現 實時反饋錯誤信息,以供用戶實時地進行處理,以免后面產生更大的錯誤。

            第二種方式:使用錯誤日志方式

            思想:將程序中的所有錯誤信息輸出到錯誤日志文件中,這樣有以下這些好處:

            1、當程序發布后,客戶在使用中遇到問題后,可以直接將錯誤日志發送給程序員,將極大地方便了問題的定位及原因的分析。

             2、便于調試多線程或者涉及網絡通信等復雜的程序,因為在這樣的程序中,設置斷點的調試方式非常地不方便,一旦暫停在斷點處,往往為引起線程異常或者 網絡連接斷開等問題,極大影響了調試的效率。如果將錯誤信息打印到文件中,錯誤描述詳細豐富一些,可以極大地提高調試的效率。

            3、便于程序進行大規模的性能測試。例如:C/S模式的系統,進行100個客戶端對服務器的訪問測試,使用這種錯誤收集策略可以方便地通過分析錯誤日志文件來推測系統的性能。

             下面思考這樣一個問題:很多軟件的設計上都有一個類似TCP/IP協議的應用層的模塊,該模塊一般是直接與客戶端交互的一層,它隔離了核心代碼模塊與客 戶端的耦合,那么,對于這樣一種層次結構比較深設計方案,最底層發生的錯誤信息怎樣傳遞到最上層?每一層都提供獲取錯誤信息的接口?這樣開銷太大,也往往 不夠理想,那該怎樣處理呢?

            我想應該主要有以下兩種處理策略,也就是我即將引出的錯誤收集和反饋的第三種和第四種策略:

            第三種方式:C++異常機制

            C++異常處理機制是一個用來有效地處理運行錯誤的非常強大且靈活的工具,它提供了更多的彈性、安全性和穩固性,克服了傳統方法所帶來的問題.

            異常的拋出和處理主要使用了以下三個關鍵字: try、 throw 、 catch 。

            拋出異常、捕獲異常 ,這些是C++提供的極其方便地處理異常策略,可以實現在最底層拋出異常,由最上層捕獲,并且處理。

             說實話,C++異常機制的確是一種處理錯誤和異常的很好的策略,如果需要使用該機制,需要從軟件架構和設計時就要開始考慮,一旦軟件結構和代碼寫到一定 程度后,再引入異常機制將很難達到很好的效果。其實,要想用好c++異常機制,不是一件很容易的事,特別是對于項目組里面有大量新人的時候,故使用成本還 是挺高的。

            關于C++異常機制很多C++書籍都有介紹,我也不在此贅述,本博客也有一篇C++異常機制的入門示例代碼,有興趣可以看看http://www.51testing.com/html/17/n-209117.html

            第四種方式:GetLastError模式

            經常開發windows程序的人應該都了解,windows程序有一個API:GetLastError,它其實代表著一種錯誤收集處理機制。

             當一個Windows函數檢測到一個錯誤時,它會使用一個稱為線程本地存儲器(thread-localstorage)的機制。當函數返回時,它的返 回值為flase就能指明一個錯誤已經發生。若要確定這是個什么錯誤,可以調用GetLastError函數來獲取:該函數只返回線程的32位錯誤代碼。

            WinError.h頭文件包含了Microsoft公司定義的錯誤代碼的列表。

            當Windows函數運行失敗時,應該立即調用GetLastError函數。如果調用另一個Windows函數,它的值很可能被改寫。

            Visual studio還配有一個小的實用程序,稱為Error Lookup.

            如果在編寫的應用程序中發現一個錯誤,可能想要向用戶顯示該錯誤的文本描述。Windows提供了一個函數,可以將錯誤代碼轉換成它的文本描述。該函數稱為FormatMessage。

             以上就是GetLastError模式的介紹,可以簡單地把它想象成為這樣一種模式:有一個全局的變量,可以用來存放32位錯誤代碼,一旦 Windows函數運行失敗,就將錯誤代碼賦值給這個全局的變量,每當調用GetLastError,則將該錯誤代碼返回出來以供外部分析原因。

             其實,我們自己也可以實現這樣一個GetLastError模式的錯誤收集機制,收集整個程序中最新的錯誤信息,供上層及時調用查詢,定義自己的錯誤代 碼和錯誤描述信息串,那么,怎樣才能更好地實現屬于自己的類似的錯誤收集反饋機制呢?怎樣使它具有更好地移植性、健壯性(支持多線程等)和易擴展性(加入 新的錯誤代碼和信息)呢?我將在后面的文章中介紹我的思考和設計。

            以上就是我對軟件中的錯誤收集策略的思考和總結,希望對各位有所幫助,也歡迎大家提出意見和建議。

          posted on 2012-07-04 09:33 順其自然EVO 閱讀(236) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2012年7月>
          24252627282930
          1234567
          891011121314
          15161718192021
          22232425262728
          2930311234

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 绥滨县| 普格县| 房产| 墨江| 会昌县| 平顺县| 江油市| 阿鲁科尔沁旗| 招远市| 汝南县| 开远市| 蒙自县| 左权县| 霍州市| 吉林市| 广灵县| 陆良县| 泸定县| 长沙县| 宜黄县| 广平县| 谢通门县| 九台市| 六枝特区| 武城县| 准格尔旗| 师宗县| 大名县| 庆阳市| 黑龙江省| 高州市| 西盟| 孝义市| 桐乡市| 衡山县| 上思县| 永川市| 拜城县| 温宿县| 玛曲县| 大竹县|