《軟體測試專案實作：技術、流程與管理》筆記
一、軟體實作方法論
1.測試的策略：
（1）靜態測試：不測試程式本身，而直接尋找程式中可能存在的缺陷或評估程式碼品質的行為。主要是在單元測試行為中，對技術、設計文件進行評核，程式無法執行或需要對原始程式進行規範符合性檢查時該使用這種策略。
（2）動態測試：運作被測程式，輸入測試資料，檢查運作結果與預期結果的差異，從而判斷系統中是否存在缺陷的過程。
2.動態測試的測試技術：
（1）黑箱測試：測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能性說明的測試方法。主要是在系統測試階段時採用。
（2）白箱測試：使用被測程式內部如何工作的資訊，允許測試人員對程式內部邏輯結構及有關資訊來設計和選擇測試案例，對程式的邏輯路徑進行測試。其測試基於覆蓋全部程式碼、分枝、路徑、條件。
（3）灰箱測試：基於被測試程式邏輯結構的基礎上，從系統功能介面上設計測試案例。通常是作為黑箱測試的補充或在黑箱發現缺陷以後，回到原始程式碼分析原因確認問題時採用。
3.測試的階段：
（1）單元測試：為最小單位的測試。在單元測試行為中，各獨立單元模組在與系統其他模組隔離的情況下進行測試，檢查每個程式模組是否實現了規定的功能。
（2）整合測試：是在單元測試的基礎上將已經通過測試的單元模組按照設計要求組裝成系統或子系統進行測試的活動。測試著重在各模組、各子系統之間介面上的缺陷。
（3）系統測試：透過整合測試的軟體，同其運作環境、資料和使用者結合在一起，在實際或模擬實際環境下，對系統進行全面的測試。目的在於通過與系統需求規格書進行比較，發現軟體與系統定義不符合的地方。
（4）驗收測試：為最後一個測試行為。它是以使用者為主的測試，由使用者設計測試案例，使用實際資料進行測試。
4.測試的方法：
（1）功能測試：檢查軟體的功能是否符合規格說明書上的需求。
（2）效能測試：檢察系統是否實現了規定的效能指標要求。
5.測試的實施組織劃分：
（1）開發者測試（α 測試）：開發者透過檢測和提供客觀證據，證實軟體的實現是否滿足規定的需求。主要是在系統交付給第三方測試或驗收測試之前進行的活動。
（2）使用者測試（β 測試）：在使用者的應用環境下，透過使用檢測軟體來驗證是否符合自己預期的需求。
（3）第三方測試（外包測試）：軟體發展方和使用者方之間的測試團隊進行的測試行為。
6.測試的其他概念：
（1）人工測試：由測試人員來執行測試案例，然後根據實際的結果和預期的結果進行比較，並記錄測試結果。
（2）自動化測試：透過重播錄製或編寫的自動化腳本，驅動系統運行的測試行為。
（3）回歸測試：軟體在修改以後再次運作之前，為尋找錯誤而執行程式曾用過的測試案例，以測試缺陷是否再次出現的行為。
（4）煙霧測試：軟體版本交付後，對其重要的部分先進行大概的測試，檢查主要功能是否正確，再進行後面的測試。
7.軟體測試模型請參考「软件测试过程管理实践 」
二、軟體品質和缺陷報告
1.規範需求需包括：
（1）使用者可能認為我們理解或遺漏的。
（2）行業規範。
（3）電腦領域的規範和習慣。
（4）客戶對電腦技術的限制。
2.外部品質與內部品質模型的六種屬性：
（1）功能性：
（2）可靠性：
（3）易用性
（4）效率性：
（5）維護性：
（6）可攜性：
3.使用者品質模型的四種屬性：
（1）有效性
（2）生產率
（3）安全性
（4）滿意度
4.缺陷報告應填寫的元素：
（1）缺陷摘要
（2）缺陷所在的子系統（模組）
（3）缺陷位置
（4）缺陷類型、原因
（5）缺陷狀態
（6）詳細描述
（7）嚴重程度
（8）緊急程度
（9）附件
（10）發現行為
（11）發現途徑
（12）測試案例編號
（13）提交的版本
（14）提交的循環週期
（15）提交日期
5.缺陷處理後要填寫的三項資訊：
（1）修復的版本
（2）修復人
（3）拒絕者
6.缺陷的六種狀態：
（1）New：預設值，測試工程師填寫一個新缺陷報告時。
（2）Open：測試團隊組長對缺陷進行審查後，將缺陷狀態從「New」改為「Open」，並在一定的時間內指派給對應的開發工程師。
（3）Fixed：當缺陷被修復並通過了驗證測試，開發工程師將缺陷狀態從「Open」改為「Fixed」。
（4）Pending：當缺陷由於各種原因無法修復時，開發工程師或專案經理將缺陷狀態從「Open」改為「Pending」。處在此狀態的缺陷將等待條件具備時再進行修復。
（5）Closed：當缺陷在一個新建版本中完成了驗證測試時，測試工程師將狀態從「Fixed」改為「Closed」。
（6）Reopen：當缺陷驗證失敗時，測試工程師會將狀態從「Fixed」改為「Reopen」。當以前已經關閉的缺陷又在測試過程中出現時，測試工程師會將狀態從「Closed」改為「Reopen」。
三、文件審查和測試需求分析
1.業務規格需求說明書為整個軟體生產活動的依據，其審查項目包括：
（1）個業務功能和效能指標的描述是否清晰、明確。
（2）同需求描述之間是否存在矛盾和衝突。
（3）業務功能描述是否有遺漏。
（4）業務需求是否可以測量。
（5）業務功能描述是否會和行業規則、企業規範；國家法律規範、政策等發生衝突。
（6）需求中計算公式是否明確，公式中各因數是否明確。
（7）計算是否有精度要求。
（8）多角色和多使用者的系統角色、權限等是否合適。
（9）其引用的文件中是否正確且文件中是否有相應敘述。
2.概要設計文件為描述功能設計、資料結構、資料目錄、效能指標等的文件，其審查項目包括：
（1）設計是否涵蓋了業務需求。
（2）功能模組設計和內外介面之間的資料交換是否明確。
（3）資料結構或類別圖設計是否明確。
（4）資藥庫邏輯結構和物理結構設計描述是否正確，有無遺漏。
（5）應用邏輯設計、網路設計、安全設計是否正確。
3.安裝部署文件為描述系統的部署，其審查項目包括：
（1）文件閱讀者為維護人員，所以要注意技術描述而非業務描述。
（2）開發團隊使用的一些術語或縮寫詞語要有解釋說明。
（3）部署中的硬體設備要與上線設備一致。
（4）部署應用系統所需要的作業系統、支援軟體等要確定的版本要求和配置參數要求。
（5）文件中的截圖要與系統實際上線環境中的系統介面、操作一致。
（6）有條件時應該對照部署手冊進行實際部署測試。
4.使用者手冊為產品最終的規範，其審查項目包括：
（1）按照手冊描述的操作步驟來操作程式。要確認手冊中的描述是正確的，不要出現導致使用者錯誤操作的情況。
（2）手冊中的建議操作應做重點驗證。建議應該是使用者選擇的操作，所以要按步驟去驗證使用者依照建議所做的操作，測試人員應嘗試更多的可能性。
（3）檢查每條陳述。測試人員需要對每條陳述進行檢查。
（4）檢查圖表、截圖是否與發佈的版本一致。
（5）對業務術語和縮寫詞要進行必要的解釋。使用者手冊中不應該出現閱讀者可能不熟悉的專業術語和縮寫詞。
（6）像使用者一樣使用樣例和示例，按步驟去驗證每個樣例或示例。
（7）尋找容易誤導使用者的內容。應盡早標示出如意被人誤解的內容。
5.系統功能測試需求的六大分類：
（1）業務功能測試需求。
（2） 可靠性測試需求。
（3）安全性測試需求。
（4）易用性測試需求。
（5）可攜性測試需求。
（6）可維護性測試需求。
6.測試工作的依據首先是業務需求規格說明書，所以首先應該把需求從中提取出來，再把業務需求分解為測試需求，每個業務需求對應一條或多條測試需求。
四、測試設計
1.測試案例是為了驗證受測系統的某一品質子屬性而設計的。共有四個基本要素：
（1）案例描述：測試的目的和預期的結果。
（2）測試資料：執行測試案例時所載入的輸入資料。
（3）執行步驟：測試案例執行時所要進行的操作佇列。
（4）預期結果：測試案例執行完後所期望系統提供的結果。
2.測試案例的設計方法－等價類劃分：
等價劃分是把系統某個輸入資料集合劃分成若干部分，然後從每個部份中選取少數代表性資料作為測試案例的輸入。
步驟：
（1）為每個等價類別限定一個唯一的編號。
（2）設計一個新的測試案例，使其盡可能多地覆蓋尚未覆蓋的有效等價類（對於程式的規格說明書來說是合理的、有意義的輸入資料構成的集合）。重複這一步，最後使得所有有效等價類均被測試案例所覆蓋。
（3）設計一個小的測試案例，使其只覆蓋一個無效等價類（對於程式的規格說明書來說是不合理的、無意義的輸入資料構成的集合）。重複這一步，使所有無效等價類均被覆蓋。
3.測試設計階段的工作包括：
（1）把測試需求轉化為測試案例。
（2）補充完善的測試需求。
（3） 完善的測試策略。
（4）測試條件、設備、環境的準備。
五、做好專案測試計劃
1.測試計畫包含的要素：
（1）測試目標和範圍。
（2）測試資源。
（3）進度計畫。
（4）測試約束條件。
（5）測試循環週期。
（6）測試策略。
（7）專案風險。
（8）測試約定。
2.進行測試策略的三步驟：
（1）確定測試需求。
（2）評估專案風險並確定測試優先順序。
（3）確定測試策略。
六、單元測試及結果測試
1.語法涵蓋：設計若干測試案例，執行受測程式，使得每一條可執行語法至少被執行一次。
2.判定（分支）覆蓋：設計若干測試案例，執行受測程式，使程式中每個判斷的邏輯為真和邏輯為假至少被執行一次。
3.條件覆蓋：設計足夠多的測試案例，執行受測程式，使程式中判斷的每個條件的每個可能取值至少被執行一次。
4.判定－條件覆蓋：設計足夠多的測試案例，執行受測程式，使程式中判斷的每個條件的每個可能取值至少執行一次，並且每個可能的判斷結果也至少被執行一次。
5.條件組合測試：設計足夠多的測試案例，執行受測程式，使程式中每個判斷的所有可能的條件取值組合至少被執行一次。
6.路徑測試：設計足夠多的測試案例，覆蓋受測物件中的所有可能路徑。
7.單元測試的步驟：
（1）計畫：確定測試需求，制定測試策略，確定測試所用資源，建立測試任務的時間表。
（2）設計：設計單元測試模型，制定測試方案，制定具體的測試案例，建立可再使用的測試腳本。
（3）執行：執行測試案例，對單元模組進行測試，驗證測試的結果並記錄測試過程中出現的缺陷。
（4）評審：對單元測試的結果進行評審。主要進行測試完備性評估。
七、產品整合測試
1.產品整合測試的重點：
（1）在把各個模組 / 子系統連接起來的時候，跨模組介面的資料是否會遺失。
（2）一個功能模組 /子系統是否會對另一個功能 / 子系統模組產生不利的影響。
（3）各個子功能 / 子系統模組累加起來，是否能達到預期的功能。
（4）全域資料結構是否有問題。
（5）單個模組的誤差是否會累加放大到不能接受的程度。
2.煙霧測試的重點：
（1）整個系統是否會實現全部主要功能。如果沒有實現，這些未實現的功能是否會給系統其他部分造成很大的影響。
（2）著重已經實現功能的品質，透過簡單執行主要業務流程，分析功能完成品質。
（3）看看是否有具體的實現，而不要被系統功能功能表和視窗所迷惑。
3.整合測試流程：
（1）測試計畫：確認測試物件、範圍，分析測試需求，測試策略、方法和出、允入準則，估算工作量，估算所需資源。
（2）測試設計：設計測試案例、測試資料、測試環境部署等。
（3） 測試執行：執行案例，記錄測試過程日誌，提交缺陷並追蹤缺陷處理流程，測試案例維護。
（4）測試總結：發現評估整合測試、測試報告。
4.整合測試設計需考量的要點：
（1）考慮支援本系統執行而需要的測試環境及測試環境與生產環境的差別。
（2）測試案例的執行策略。
（3）測試案例運行需要的外部條件。
5.整合測試報告應包括的內容：
（1）測試案例執行情況分析。
（2）整合測試需求符合程度分析。
（3）缺陷分析。
（4） 測試過程分析。
八、專案功能測試
1.專案經理在功能測試執行之前的準備工作：
（1）完成對功能測試計畫的評審。
（2）完成對功能測試案例的評審。
（3）測試環境建置完成，且通過審查。
（4）功能測試需要的測試資料和結果記錄形式準備完成。
（5） 系統中的參數配置等已準備好。
九、專案效能測試
1.測試允入準則：
（1）效能測試計畫撰寫完成，且通過評審。
（2）與業務人員溝通，選擇常見交易和混和業務比例。
（3）整個系統功能趨於穩定。
（4）測試環境搭建完成，且通過驗收。
（5）測試環境應用部署完成，並驗證可用性。
（6）效能測試腳本和測試資料準備結束。
（7） 預期效能指標確定。
2.測試允出準則：
（1）校能測試完成，系統達到效能測試指標。
（2）校能測試完成，若未達到效能測試指標，則返回最佳化處理。
（3）滿足上述兩個條件之一，且系統效能報告評審通過，則退出效能測試。
十、客戶驗收測試和測試報告評核
1.測試報告的內容：
（1）目的。
（2）測試環境。
（3）測試實際進度和計畫進度對比。
（4）測試版本。
（5）測試結果。
（6）落差分析。
（7）測試有效性分析。
（8）輸入文件。
（9）遺留缺陷分析。
（10） 缺陷清單。
2.撰寫測試報告的注意事項：
（1）在測試報告的文字中只是描述問題、事情或過程等，不要出現帶有明顯感情色彩的字眼。
（2）提供明確的資訊，而不要出現不確定的詞語。
（3） 測試報告的每一個資料都要有測試結果進行驗證，且是經過多次測試驗證的資料，是經得起推敲的資料，不同地方的資料要一致。
十二、測試專案管理
1.專案工作量評估模型－專案經驗模擬法：
根據公司以前所作的類似專案，所累積的經驗或歷史資料來估算工作量。
步驟：
（1）在公司的知識庫中搜索類似的專案，獲得類似專案的資訊。
（2）把目前專案與類似專案進行比較，找出差異性。
（3）對差異性進行分析，找出目前專案的特點。
（4）對目前專案進行評估。
（5）最後統計出總體工作量，請相關的主管、專案經理、測試專家參與討論，確定最後的工作量。
2.專案工作量評估模型－WBS估算法：
將專案或產品分解為實際的工作，然後分別對各個工作進行時間估算，最終求和統計得出專案或產品的測試工作量。
單元測試的步驟：
（1）如果有系統詳細設計說明書，則依據詳細說明書中劃分的模組來計算劃分的單元模組數量﹔若沒有該文件，確定是否可透過其他文件估算單元模組的數量。
（2） 確定單元測試審核中每個活動的工作量。
產品整合測試的步驟：
（1）把整個系統分解成子系統，確定每個子系統的介面數量。
（2）對每兩個子系統之間含有介面的子系統進行評估，需要建構多少測試案例覆蓋介面，也要考慮介面之間的測試方案。
（3） 需要考慮整個整合測試所用的工作量。
系統功能測試的步驟：
（1）把整個系統中的各子系統分解成需求點 / 功能點，在各功能點上確定運算元素，確定功能點的劃分密度。
（2）統計出所有的需求點為整個系統中的功能需求總數，再考慮測試中實際方案的工作量，是否考慮自動化測試、是否需要建構大量基礎資料等。
（3）需要考慮整個系統功能測試所用的工作量。
系統效能測試的步驟：
（1）把整個系統中的效能需求點整理出來，包括功能測試之外的所有測試行為。
（2）評估每個效能點需要的工時，形成整個系統效能測試的總工時。
3.專案工作量評估模型－Delphi 法：
要求有多種相關經驗的人參與，互相說服對方。
（1）專案協調人和各測試專家和專案經理介紹專案規格和估計表格。
（2）專案協調人召集小組會，各測試專家和專案經理討論與規模相關的因素。
（3）各測試專家匿名填寫迭代表格。
（4）專案協調人整理出一個估計總結，以迭代表格的形式送回給測試專家。
（5）專案協調人召集小組會，討論較大的估計差異。
（6）測試專家複查估計總結，並在迭代表格上提交另一個不記名估計。
（7）重複步驟4~6，直到達到一個最低和最高估計基本一致。
1.測試的策略：
（1）靜態測試：不測試程式本身，而直接尋找程式中可能存在的缺陷或評估程式碼品質的行為。主要是在單元測試行為中，對技術、設計文件進行評核，程式無法執行或需要對原始程式進行規範符合性檢查時該使用這種策略。
（2）動態測試：運作被測程式，輸入測試資料，檢查運作結果與預期結果的差異，從而判斷系統中是否存在缺陷的過程。
2.動態測試的測試技術：
（1）黑箱測試：測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能性說明的測試方法。主要是在系統測試階段時採用。
（2）白箱測試：使用被測程式內部如何工作的資訊，允許測試人員對程式內部邏輯結構及有關資訊來設計和選擇測試案例，對程式的邏輯路徑進行測試。其測試基於覆蓋全部程式碼、分枝、路徑、條件。
（3）灰箱測試：基於被測試程式邏輯結構的基礎上，從系統功能介面上設計測試案例。通常是作為黑箱測試的補充或在黑箱發現缺陷以後，回到原始程式碼分析原因確認問題時採用。
3.測試的階段：
（1）單元測試：為最小單位的測試。在單元測試行為中，各獨立單元模組在與系統其他模組隔離的情況下進行測試，檢查每個程式模組是否實現了規定的功能。
（2）整合測試：是在單元測試的基礎上將已經通過測試的單元模組按照設計要求組裝成系統或子系統進行測試的活動。測試著重在各模組、各子系統之間介面上的缺陷。
（3）系統測試：透過整合測試的軟體，同其運作環境、資料和使用者結合在一起，在實際或模擬實際環境下，對系統進行全面的測試。目的在於通過與系統需求規格書進行比較，發現軟體與系統定義不符合的地方。
（4）驗收測試：為最後一個測試行為。它是以使用者為主的測試，由使用者設計測試案例，使用實際資料進行測試。
4.測試的方法：
（1）功能測試：檢查軟體的功能是否符合規格說明書上的需求。
（2）效能測試：檢察系統是否實現了規定的效能指標要求。
5.測試的實施組織劃分：
（1）開發者測試（α 測試）：開發者透過檢測和提供客觀證據，證實軟體的實現是否滿足規定的需求。主要是在系統交付給第三方測試或驗收測試之前進行的活動。
（2）使用者測試（β 測試）：在使用者的應用環境下，透過使用檢測軟體來驗證是否符合自己預期的需求。
（3）第三方測試（外包測試）：軟體發展方和使用者方之間的測試團隊進行的測試行為。
6.測試的其他概念：
（1）人工測試：由測試人員來執行測試案例，然後根據實際的結果和預期的結果進行比較，並記錄測試結果。
（2）自動化測試：透過重播錄製或編寫的自動化腳本，驅動系統運行的測試行為。
（3）回歸測試：軟體在修改以後再次運作之前，為尋找錯誤而執行程式曾用過的測試案例，以測試缺陷是否再次出現的行為。
（4）煙霧測試：軟體版本交付後，對其重要的部分先進行大概的測試，檢查主要功能是否正確，再進行後面的測試。
7.軟體測試模型請參考「软件测试过程管理实践 」
二、軟體品質和缺陷報告
1.規範需求需包括：
（1）使用者可能認為我們理解或遺漏的。
（2）行業規範。
（3）電腦領域的規範和習慣。
（4）客戶對電腦技術的限制。
2.外部品質與內部品質模型的六種屬性：
（1）功能性：
- 適合
- 準確
- 互動
- 保密安全
- 功能依從
（2）可靠性：
- 成熟
- 容錯
- 易回復
- 可靠依從
（3）易用性
- 吸引
- 易學
- 易理解
- 易操作
- 易用依從
（4）效率性：
- 時間特性
- 資源利用
- 效率依從
（5）維護性：
- 穩定
- 易分析
- 易改變
- 易測試
- 維護依從
（6）可攜性：
- 適用
- 相容
- 易安裝
- 易替換
- 可攜依從
3.使用者品質模型的四種屬性：
（1）有效性
（2）生產率
（3）安全性
（4）滿意度
4.缺陷報告應填寫的元素：
（1）缺陷摘要
（2）缺陷所在的子系統（模組）
（3）缺陷位置
（4）缺陷類型、原因
（5）缺陷狀態
（6）詳細描述
（7）嚴重程度
（8）緊急程度
（9）附件
（10）發現行為
（11）發現途徑
（12）測試案例編號
（13）提交的版本
（14）提交的循環週期
（15）提交日期
5.缺陷處理後要填寫的三項資訊：
（1）修復的版本
（2）修復人
（3）拒絕者
6.缺陷的六種狀態：
（1）New：預設值，測試工程師填寫一個新缺陷報告時。
（2）Open：測試團隊組長對缺陷進行審查後，將缺陷狀態從「New」改為「Open」，並在一定的時間內指派給對應的開發工程師。
（3）Fixed：當缺陷被修復並通過了驗證測試，開發工程師將缺陷狀態從「Open」改為「Fixed」。
（4）Pending：當缺陷由於各種原因無法修復時，開發工程師或專案經理將缺陷狀態從「Open」改為「Pending」。處在此狀態的缺陷將等待條件具備時再進行修復。
（5）Closed：當缺陷在一個新建版本中完成了驗證測試時，測試工程師將狀態從「Fixed」改為「Closed」。
（6）Reopen：當缺陷驗證失敗時，測試工程師會將狀態從「Fixed」改為「Reopen」。當以前已經關閉的缺陷又在測試過程中出現時，測試工程師會將狀態從「Closed」改為「Reopen」。
三、文件審查和測試需求分析
1.業務規格需求說明書為整個軟體生產活動的依據，其審查項目包括：
（1）個業務功能和效能指標的描述是否清晰、明確。
（2）同需求描述之間是否存在矛盾和衝突。
（3）業務功能描述是否有遺漏。
（4）業務需求是否可以測量。
（5）業務功能描述是否會和行業規則、企業規範；國家法律規範、政策等發生衝突。
（6）需求中計算公式是否明確，公式中各因數是否明確。
（7）計算是否有精度要求。
（8）多角色和多使用者的系統角色、權限等是否合適。
（9）其引用的文件中是否正確且文件中是否有相應敘述。
2.概要設計文件為描述功能設計、資料結構、資料目錄、效能指標等的文件，其審查項目包括：
（1）設計是否涵蓋了業務需求。
（2）功能模組設計和內外介面之間的資料交換是否明確。
（3）資料結構或類別圖設計是否明確。
（4）資藥庫邏輯結構和物理結構設計描述是否正確，有無遺漏。
（5）應用邏輯設計、網路設計、安全設計是否正確。
3.安裝部署文件為描述系統的部署，其審查項目包括：
（1）文件閱讀者為維護人員，所以要注意技術描述而非業務描述。
（2）開發團隊使用的一些術語或縮寫詞語要有解釋說明。
（3）部署中的硬體設備要與上線設備一致。
（4）部署應用系統所需要的作業系統、支援軟體等要確定的版本要求和配置參數要求。
（5）文件中的截圖要與系統實際上線環境中的系統介面、操作一致。
（6）有條件時應該對照部署手冊進行實際部署測試。
4.使用者手冊為產品最終的規範，其審查項目包括：
（1）按照手冊描述的操作步驟來操作程式。要確認手冊中的描述是正確的，不要出現導致使用者錯誤操作的情況。
（2）手冊中的建議操作應做重點驗證。建議應該是使用者選擇的操作，所以要按步驟去驗證使用者依照建議所做的操作，測試人員應嘗試更多的可能性。
（3）檢查每條陳述。測試人員需要對每條陳述進行檢查。
（4）檢查圖表、截圖是否與發佈的版本一致。
（5）對業務術語和縮寫詞要進行必要的解釋。使用者手冊中不應該出現閱讀者可能不熟悉的專業術語和縮寫詞。
（6）像使用者一樣使用樣例和示例，按步驟去驗證每個樣例或示例。
（7）尋找容易誤導使用者的內容。應盡早標示出如意被人誤解的內容。
5.系統功能測試需求的六大分類：
（1）業務功能測試需求。
（2） 可靠性測試需求。
（3）安全性測試需求。
（4）易用性測試需求。
（5）可攜性測試需求。
（6）可維護性測試需求。
6.測試工作的依據首先是業務需求規格說明書，所以首先應該把需求從中提取出來，再把業務需求分解為測試需求，每個業務需求對應一條或多條測試需求。
四、測試設計
1.測試案例是為了驗證受測系統的某一品質子屬性而設計的。共有四個基本要素：
（1）案例描述：測試的目的和預期的結果。
（2）測試資料：執行測試案例時所載入的輸入資料。
（3）執行步驟：測試案例執行時所要進行的操作佇列。
（4）預期結果：測試案例執行完後所期望系統提供的結果。
2.測試案例的設計方法－等價類劃分：
等價劃分是把系統某個輸入資料集合劃分成若干部分，然後從每個部份中選取少數代表性資料作為測試案例的輸入。
步驟：
（1）為每個等價類別限定一個唯一的編號。
（2）設計一個新的測試案例，使其盡可能多地覆蓋尚未覆蓋的有效等價類（對於程式的規格說明書來說是合理的、有意義的輸入資料構成的集合）。重複這一步，最後使得所有有效等價類均被測試案例所覆蓋。
（3）設計一個小的測試案例，使其只覆蓋一個無效等價類（對於程式的規格說明書來說是不合理的、無意義的輸入資料構成的集合）。重複這一步，使所有無效等價類均被覆蓋。
3.測試設計階段的工作包括：
（1）把測試需求轉化為測試案例。
（2）補充完善的測試需求。
（3） 完善的測試策略。
（4）測試條件、設備、環境的準備。
五、做好專案測試計劃
1.測試計畫包含的要素：
（1）測試目標和範圍。
（2）測試資源。
（3）進度計畫。
（4）測試約束條件。
（5）測試循環週期。
（6）測試策略。
（7）專案風險。
（8）測試約定。
2.進行測試策略的三步驟：
（1）確定測試需求。
（2）評估專案風險並確定測試優先順序。
（3）確定測試策略。
六、單元測試及結果測試
1.語法涵蓋：設計若干測試案例，執行受測程式，使得每一條可執行語法至少被執行一次。
2.判定（分支）覆蓋：設計若干測試案例，執行受測程式，使程式中每個判斷的邏輯為真和邏輯為假至少被執行一次。
3.條件覆蓋：設計足夠多的測試案例，執行受測程式，使程式中判斷的每個條件的每個可能取值至少被執行一次。
4.判定－條件覆蓋：設計足夠多的測試案例，執行受測程式，使程式中判斷的每個條件的每個可能取值至少執行一次，並且每個可能的判斷結果也至少被執行一次。
5.條件組合測試：設計足夠多的測試案例，執行受測程式，使程式中每個判斷的所有可能的條件取值組合至少被執行一次。
6.路徑測試：設計足夠多的測試案例，覆蓋受測物件中的所有可能路徑。
7.單元測試的步驟：
（1）計畫：確定測試需求，制定測試策略，確定測試所用資源，建立測試任務的時間表。
（2）設計：設計單元測試模型，制定測試方案，制定具體的測試案例，建立可再使用的測試腳本。
（3）執行：執行測試案例，對單元模組進行測試，驗證測試的結果並記錄測試過程中出現的缺陷。
（4）評審：對單元測試的結果進行評審。主要進行測試完備性評估。
七、產品整合測試
1.產品整合測試的重點：
（1）在把各個模組 / 子系統連接起來的時候，跨模組介面的資料是否會遺失。
（2）一個功能模組 /子系統是否會對另一個功能 / 子系統模組產生不利的影響。
（3）各個子功能 / 子系統模組累加起來，是否能達到預期的功能。
（4）全域資料結構是否有問題。
（5）單個模組的誤差是否會累加放大到不能接受的程度。
2.煙霧測試的重點：
（1）整個系統是否會實現全部主要功能。如果沒有實現，這些未實現的功能是否會給系統其他部分造成很大的影響。
（2）著重已經實現功能的品質，透過簡單執行主要業務流程，分析功能完成品質。
（3）看看是否有具體的實現，而不要被系統功能功能表和視窗所迷惑。
3.整合測試流程：
（1）測試計畫：確認測試物件、範圍，分析測試需求，測試策略、方法和出、允入準則，估算工作量，估算所需資源。
（2）測試設計：設計測試案例、測試資料、測試環境部署等。
（3） 測試執行：執行案例，記錄測試過程日誌，提交缺陷並追蹤缺陷處理流程，測試案例維護。
（4）測試總結：發現評估整合測試、測試報告。
4.整合測試設計需考量的要點：
（1）考慮支援本系統執行而需要的測試環境及測試環境與生產環境的差別。
（2）測試案例的執行策略。
（3）測試案例運行需要的外部條件。
5.整合測試報告應包括的內容：
（1）測試案例執行情況分析。
（2）整合測試需求符合程度分析。
（3）缺陷分析。
（4） 測試過程分析。
八、專案功能測試
1.專案經理在功能測試執行之前的準備工作：
（1）完成對功能測試計畫的評審。
（2）完成對功能測試案例的評審。
（3）測試環境建置完成，且通過審查。
（4）功能測試需要的測試資料和結果記錄形式準備完成。
（5） 系統中的參數配置等已準備好。
九、專案效能測試
1.測試允入準則：
（1）效能測試計畫撰寫完成，且通過評審。
（2）與業務人員溝通，選擇常見交易和混和業務比例。
（3）整個系統功能趨於穩定。
（4）測試環境搭建完成，且通過驗收。
（5）測試環境應用部署完成，並驗證可用性。
（6）效能測試腳本和測試資料準備結束。
（7） 預期效能指標確定。
2.測試允出準則：
（1）校能測試完成，系統達到效能測試指標。
（2）校能測試完成，若未達到效能測試指標，則返回最佳化處理。
（3）滿足上述兩個條件之一，且系統效能報告評審通過，則退出效能測試。
十、客戶驗收測試和測試報告評核
1.測試報告的內容：
（1）目的。
（2）測試環境。
（3）測試實際進度和計畫進度對比。
（4）測試版本。
（5）測試結果。
（6）落差分析。
（7）測試有效性分析。
（8）輸入文件。
（9）遺留缺陷分析。
（10） 缺陷清單。
2.撰寫測試報告的注意事項：
（1）在測試報告的文字中只是描述問題、事情或過程等，不要出現帶有明顯感情色彩的字眼。
（2）提供明確的資訊，而不要出現不確定的詞語。
（3） 測試報告的每一個資料都要有測試結果進行驗證，且是經過多次測試驗證的資料，是經得起推敲的資料，不同地方的資料要一致。
十二、測試專案管理
1.專案工作量評估模型－專案經驗模擬法：
根據公司以前所作的類似專案，所累積的經驗或歷史資料來估算工作量。
步驟：
（1）在公司的知識庫中搜索類似的專案，獲得類似專案的資訊。
（2）把目前專案與類似專案進行比較，找出差異性。
（3）對差異性進行分析，找出目前專案的特點。
（4）對目前專案進行評估。
（5）最後統計出總體工作量，請相關的主管、專案經理、測試專家參與討論，確定最後的工作量。
2.專案工作量評估模型－WBS估算法：
將專案或產品分解為實際的工作，然後分別對各個工作進行時間估算，最終求和統計得出專案或產品的測試工作量。
單元測試的步驟：
（1）如果有系統詳細設計說明書，則依據詳細說明書中劃分的模組來計算劃分的單元模組數量﹔若沒有該文件，確定是否可透過其他文件估算單元模組的數量。
（2） 確定單元測試審核中每個活動的工作量。
產品整合測試的步驟：
（1）把整個系統分解成子系統，確定每個子系統的介面數量。
（2）對每兩個子系統之間含有介面的子系統進行評估，需要建構多少測試案例覆蓋介面，也要考慮介面之間的測試方案。
（3） 需要考慮整個整合測試所用的工作量。
系統功能測試的步驟：
（1）把整個系統中的各子系統分解成需求點 / 功能點，在各功能點上確定運算元素，確定功能點的劃分密度。
（2）統計出所有的需求點為整個系統中的功能需求總數，再考慮測試中實際方案的工作量，是否考慮自動化測試、是否需要建構大量基礎資料等。
（3）需要考慮整個系統功能測試所用的工作量。
系統效能測試的步驟：
（1）把整個系統中的效能需求點整理出來，包括功能測試之外的所有測試行為。
（2）評估每個效能點需要的工時，形成整個系統效能測試的總工時。
3.專案工作量評估模型－Delphi 法：
要求有多種相關經驗的人參與，互相說服對方。
（1）專案協調人和各測試專家和專案經理介紹專案規格和估計表格。
（2）專案協調人召集小組會，各測試專家和專案經理討論與規模相關的因素。
（3）各測試專家匿名填寫迭代表格。
（4）專案協調人整理出一個估計總結，以迭代表格的形式送回給測試專家。
（5）專案協調人召集小組會，討論較大的估計差異。
（6）測試專家複查估計總結，並在迭代表格上提交另一個不記名估計。
（7）重複步驟4~6，直到達到一個最低和最高估計基本一致。
Reference:
http://w1a2d3s4q5e6.blogspot.ca/2012/11/blog-post_7.html
No comments:
Post a Comment