隨筆-60  評論-117  文章-0  trackbacks-0

                   經常有這樣的經驗:想要學一樣東西,有一本關于它的厚厚的書擺在我面前。快速的翻了翻之后,又將它合上。然后無奈的嘆了口氣。是啊,到底該怎么下手呢?可當得知明天就要考這本書的時候,再打開,發現它們突然變得簡單了。只是自己想學的太多,時間有點不夠用……
          軟件測試
          定義:測試是為了發現錯誤而執行程序的過程。

          目的:

          • 為了尋找錯誤,并盡可能地為修正錯誤提供更多的信息。
          • 為了證明軟件有錯誤,而不是證明軟件沒有錯誤。

          作用:

          • 發現并管理缺陷
          • 度量質量
            • 評價工作效率和效果
            • 與其項目風險

          原則:

          • 座右銘:“盡早地和不斷地進行軟件測試”。
          • 測試用例應由測試輸入數據和對應的語句輸入結果這兩部分組成。
          • 程序員應避免檢查自己的程序。
          • 在設計測試用例時,應當包括合理的輸入條件和不合理的輸入條件。
          • 充分注意測試中的群集現象。經驗表明,測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比。
          • 嚴格執行測試計劃,排除測試的隨意性。
          • 應當對每一個測試結果作全面檢查。
          • 妥善保存測試計劃,測試用例,出錯統計和最終分析報告,為維護提供方便。
          • 所有的測試都應可追溯到客戶的需求。
          • 應該在測試工作開始之前的較長時間就進行測試計劃。
          • pareto原則:測試發現的錯誤中80%很可能起源于20%的模塊中。
          • 測試從“小模塊”開始,逐步轉向“大規模”。
          • 窮舉測試是不可能的。

          對象:

          • 軟件包括程序、數據和文檔,軟件測試并不等于程序測試。
          • 軟件測試應貫穿于軟件定義與開發的整個其間。
          • 開發過程所得到的文檔,都應成為軟件測試的對象。
          • 驗證與確認都屬于軟件測試,它 包括對軟件分析、設計以及程序的驗證和確認。
            • 驗證:是保證軟件符合產品描述的過程。
            • 是保證軟件滿足用戶要求的過程。

          缺陷:

          • 軟件未達到產品描述表明的功能。
          • 軟件出現了產品描述指明不會出現的錯誤。
          • 軟件功能超出產品描述指明范圍。
          • 軟件未達到產品描述雖未指出但應達到的目標。
          • 軟件測試人員認為軟件難以理解、不易使用、運行速度緩慢、或者最終用戶認為不好。

          缺陷產生的原因:

          • 編寫代碼
          • 設計
          • 編寫產品描述
          • 其他

          特征:

          • 軟件測試具有一定的風險:完全測試是不可能的,如果決定不去測試所有的情況,那就是選擇了風險。
          • 軟件缺陷的寄生蟲性:找到的軟件缺陷越多,就說明軟件缺陷越多。
          • 軟件測試的殺蟲劑現象:軟件測試越多,其免疫力越強的現象。
          • 軟件測試的不修復原則 :并非所有軟件缺陷都能修復。有些缺陷不需要修復:*沒有足夠的時間*不算真正的軟件缺陷* 修復的風險太大*不值得修復。

          軟件測試方法、技術和策略
          框架:

          1. 靜態測試方法
            1. 人工測試方法
            2. 計算機輔助靜態分析方法
          2. 動態測試方法
            1. 白盒測試方法
            2. 黑盒測試方法

          靜態測試:
          基本特征

          • 對軟件進行分析、檢查和審閱,不實際運行被測試的軟件。
          • 靜態測試約可找出30-70% 的邏輯設計錯誤 。

          比如說:對需求規格說明書、軟件設計說明書、原程序作檢查和審閱。



          動態測試:
          基本特征:
          通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。
          兩個基本要素:

          • 被測試程序
          • 測試數據(測試用例)

          動態測試方法流程

          • 選取定義域有效值,或定義域外無效值
          • 對已選取值決定預期的結果
          • 用選取值執行程序
          • 執行結果與對已選取值決定預期的結果相比,不吻合程序有錯。

          白盒測試:

          • 結構測試(玻璃盒測試)
          • 對軟件的過程性細節做細致的檢查
          • 可利用程序內的邏輯結構,設計或選擇測試用例,對程序的邏輯羅景警醒測試。

           白盒測試方法:

          • 邏輯覆蓋
            • 語句覆蓋:被測程序中每個語句至少執行一次
            • 判定覆蓋:使每個判定的真假分支都至少執行一次
            • 條件覆蓋:每個語句至少執行一次,切實判定表達式中的每個條件都取到各種可能的結果
            • 判定/條件覆蓋:判定每個條件的所有可能條件至少執行一次,同時每個判定的所有的可能判定結果至少執行一次。
            • 條件組合覆蓋:所有可能的條件去之組合至少執行一次
          • 控制結構測試
            • 基本路徑測試:通過分析由控制構造的環路的復雜性,導出基本路徑集合,從而設計測試用例,保證這些路徑至少通過一次
            • 條件測試:是檢查程序模塊中包含的邏輯條件。
            • 循環測試:專注于測試循環結構的有效性
              • 簡單循環
              • 嵌套循環
              • 串接循環

          黑盒測試:

          • 功能測試(行為測試)
          • 數據驅動測試
          • 注重測試軟件的功能性需求
          • 在程序借口進行測試,只檢查程序功能是否按規格說明書的規定
          • 不深入代碼細節的測試

          測試方法:

          • 等價劃分
          • 邊界值分析
          • 錯誤推測
          • 其他方法

          等價劃分:
          基本思想:
          將所有可能的輸入數據(有效的和無效的)劃分成若干個等價類,從每個等價類中只取一組數據作為測試數據。
          基本步驟:

          • 劃分輸入數據的等價類(有效和無效)
            • 等價類:指某個輸入域的子集合,在該子集合中,個個輸入數據對于揭露程序中的錯誤是等效的。
          • 涉及測試方案
            • 不斷地覆蓋所有的有效等價類
            • 不斷地覆蓋所有的無效等價類

          劃分等價類的規則:

          1. 如果輸入條件規定了取值范圍,可定義一個有效等價類和兩個無效等價類。
          2. 如果輸入條件代表集合的某個元素,則可定義一個有效等價類和一個無效等價類。
          3. 如規定了輸入數據的一組值, 且程序對不同輸入值作不同處理,則每個允許的輸入值是一個有效等價類,并有一個無效等價類(所有不允許的輸入值的集合)。
          4. 如果規定了輸入數據必須組遵循的規則,可確定一個有效等價類(符合規則)和若干個無效等價類(從不同角度違反規則)。
          5. 如已劃分的等價類各元素在程序中的處理方式不同,則應將此等價類進一步劃分成更小的等價類。

           邊界值分析:
          通過關注于在某等價類的“邊緣”的數據而擴展了等價劃分。
          與等價劃分的區別:

          • 邊界值分析不是從某等價類中隨便挑一個作為代表, 而是使這個等價類的每個邊界都要作為測試條件。
          • 邊界值分析不僅考慮輸入條件,還要考慮輸入空間產生的測試情況。

          邊界值分析的步驟:
          確定邊界情況:

          • 輸入等價類和輸出等價類的邊界,就應該著重測試的程序邊界的情況。
          • 選取的測試數據應剛好等于,剛好小于鶴崗好大于邊界值。
          • 聯合使用等價劃分和邊界值分析兩技術。

          因果圖:

          • 描述對于多種條件的組合,相應產生多個動作的形式。適合于檢查程序輸入條件的各種組合情況。

          使用因果圖設計測試用例:

          • 考慮了多個輸入之間的相互組合,相互制約關系。
          • 能夠幫助我們按一定步驟,高效率地選擇測試用例,同時還能為我們指出, 程序規格說明描述中存在著什么問題

          利用因果圖導出測試用例的一般步驟

          • 分析程序規格說明的描述中,哪些是原因,哪些是結果。
          • 分析程序規格說明的描述中語義的內容,并將其表示城連接各個原因與各個結果的因果圖
          • 在因果圖上使用若干個特殊的符號表明特定的約束條件
          • 把因果圖轉換成判定表
          • 把判定表中每一列表示的情況寫成測試用例

          錯誤推測:
          基本思想:

          • 列舉程序中可能有的錯誤和容易發生的特殊情況,并且根據他們選擇測試方案

          軟件測試模型:

          • v模型:按時間順序進行:用戶需求,需求分析與系統設計,概要設計,詳細設計,編碼,單元測試,集成測試,確認測試與系統測試,驗收測試
            • 它是最具具有代表意義的測試模型
            • 它是軟件開發瀑布模型的變種,它反映了測試活動與分析和設計的關系。
            • 從左到右,描述了基本的開發過程和測試行為,非常明確的表明了測試過程中存在的不同級別,并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系。
            • 箭頭代表了時間方向 ,左邊下降的是開發過程各階段,與此相對應的是右邊上升的部分,即個測試過程的各個階段。
          • w模型
            • v模型存在一定的局限性,它僅僅把測試過程作為在需求分析,概要設計,詳細設計及編碼之后的一個階段。容易使人理解為測試是軟件開發的最后的一個階段,主要是針對程序進行測試徐兆錯誤,而需求分析階段的隱藏的問題一直到后期的驗收測試才被發現。
            • 在v模型中曾家軟件各開發階段應同步進行的測試,被演化為一種w模型。
            • 開發是v,測試也是與此相重疊的v。
            • 相比于v模型,w模型更科學。w模型可以說是前者自然而然的發展,它強調:測試伴隨著整個軟件開發周期,而且測試的對象不僅僅是程序,需求,功能和設計同樣要測試。
            • 測試與開發是同步進行的,從而有利于僅在地發現問題。與需求為例,而不是等到最后才進行針對需求的驗收測試。
            • 測試不僅僅是評定軟件的質量,測試還可以盡可能早的找出缺陷所在,從而幫助改進項目內部的質量。
          • x模型

           軟件測試技術:
          靜態測試的技術主要有:代碼走查,技術評審,代碼審查。
          黑盒測試的技術主要有:功能測試,性能測試,攻擊測試。
          回歸測試:程序修改或者版本更新以后,為了確保以前正確的能能和其他指標仍舊正確,而重新進行的測試。
          測試過程分為:

          • 單元測試:
            • 檢驗程序最小單元有無錯誤。接口、數據結構、邊界、覆蓋、邏輯。檢驗單元編碼與設計是否吻合。
            • 時機:編碼完成后,首先要實施的測試。
            • 方法:靜態測試,白盒測試
            • 責任:開發工程師
          • 集成測試:
            • 目標:檢驗組成系統的模塊節后有無錯誤。代碼實現的系統設計與需求定義是否吻合。
            • 時機:主要的單元測試完成后,經常與單元測試同步進行。
            • 方法:黑盒測試
            • 責任:開發工程師,測試工程師
          • 系統測試:
            • 目標:檢驗組成整個系統的代碼、以及系統的軟硬件配合有無錯誤
            • 代碼實現的系統與用戶需求是否吻合
            • 檢驗系統的文檔等各種是否完整、有效
            • 模擬驗收測試的要求,檢察系統是否符合用戶的驗收標準
            • 時機:多數集成測試完成后
            • 方法:黑盒測試
            • 責任:測試工程師
          • 系統測試----穩定期測試
            • 目標:度量是否可以結束測試
            • 時機:傳統的系統測試完成后
            • 方法:黑盒測試
            • 責任:測試工程師
          • 驗收測試:
            • 目標:使客戶驗收簽字,系統是否符合事先約定的驗收標準。
            • 時機:系統測試完成后,在項目組開來開發和測試工作已經全部完成,可以交付使用。
            • 方法:黑盒測試
            • 責任:產品經理或其他高級經理,開發工程師,測試工程師,用戶。
          • 回歸測試:
            • 目標:驗證程序修改或者版本更新以后,以前正確的功能和其他指標仍舊正確。
            • 時機:每次錯誤修改之后,或者版本更新之后。
            • 方法:白盒測試,黑盒測試
            • 責任:開發工程師,測試工程師
          • 缺陷跟蹤:
            • 目標:確保所有發現的錯誤被正確記錄、分發、評估、關閉、統計
            • 時機:從錯誤發現開始到錯誤關閉為止,每次錯誤裝袋修改之后。
            • 方法:缺陷跟蹤系統
            • 責任:開發工程師,測試工程師,測試經理,用戶

           

          posted on 2007-04-28 08:55 靜兒 閱讀(852) 評論(1)  編輯  收藏

          評論:
          # re: 關于軟件測試 2007-10-19 08:53 | bigboy
          寫的很好,收藏了  回復  更多評論
            

          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          主站蜘蛛池模板: 通州市| 新竹县| 伊吾县| 中西区| 宁明县| 东辽县| 文登市| 南平市| 远安县| 桂东县| 苗栗县| 体育| 会理县| 雅江县| 许昌县| 东丽区| 阳新县| 牡丹江市| 揭阳市| 海兴县| 双江| 当涂县| 仙居县| 渝北区| 沧源| 文水县| 阳江市| 晋中市| 平湖市| 天柱县| 通渭县| 酒泉市| 宁夏| 永寿县| 敦化市| 固镇县| 襄汾县| 苏尼特左旗| 长葛市| 潜山县| 蒙城县|