軟體測試培訓筆記

標籤：style   color   io   使用   strong   檔案   資料   sp   2014   

《單元測試及持續整合實戰》  201409

1.        品質(Quality)：一組內在特性滿足需求的程度；一個系統、構件或過程滿足特定需求(顧客或使用者需要或期望)的程度。

軟體品質管理：確定一個軟體產品的品質目標，建立實現這些目標的計劃，監督、調整軟體計劃、軟體工作產品、活動和品質目標，以滿足顧客、終端使用者需要和期望的過程。

一般在軟體企業中，提到品質管理(quality management, QM)主要是兩個方面：品質控制(qualitycontrol, QC)、品質保證(quality assurance, QA)。

品質控制(QC)主要是指對文檔的評審、代碼複查、單元測試、整合測試、系統測試、驗收測試等等。

品質保證(QA)主要是指通過過程評審、產品審計等對中間環節過程、工作產品品質的監控來確保最終產品品質符合要求。

QC、QA在某種情況下專指角色，譬如測試人員被稱作QC角色；品質保證人員被稱為QA角色。

品質管理(QM)除品質控制、品質保證之外，還包括確定品質方針、目標和職責，品質體系建設、品質策劃、品質改進等活動(EPG(品質體系建設)工作)。

QC各環節包括：(1)、各種文檔的走查；(2)、各種文檔的評審；(3)、代碼複查；(4)、單元測試；(5)、整合測試；(6)、系統測試；(7)、驗收測試；(8)、准生產/投產測試。

2.        單元測試(UnitTest, UT)：是針對軟體設計的最小單位----程式模組，進行正確性檢驗的測試工作。其目的在於發現每個程式模組內部可能存在的差錯。

如果把所有測試環節比作是清洗一台機器：(1)、系統測試就是清除機器外面的塵土；(2)、整合測試就是保證機器各個組件的接頭處乾淨；(3)、單元測試就是清洗各零件的內部。

單元測試的目的：(1)、缺陷排除前移使得企業品質成本降低；(2)、儘早發現缺陷，節省項目總工作量；(3)、改進品質的本質----儘早消除缺陷。

軟體專案管理四要素：成本、範圍、進度、品質。

專案經理在專案管理期間中最為重要的任務是均衡項目四要素。

3.        單元測試方法簡介：

什麼是單元？：(1)、物件導向的軟體開發：以Class(類)的方法作為測試的最小單元。以方法的內部結構作為測試的重點；(2)、結構化的軟體開發：以模組(函數、過程)作為測試的最小單元。

單元測試內容：(1)、面向代碼的代碼複查(靜態單元測試)；(2)、面向單元的黑箱測試(單元功能測試)；(3)、面向單元的白盒測試(單元覆蓋率測試)。

單元測試是程式員的基本職責，也是程式員的基本職業素質能力，必須對自己編寫的代碼認真負責。編碼人員除了編碼、單元測試(靜態、動態)外，還包括整合測試、參與系統測試案例走查等，還有輔助專案管理等等工作。

4.        單元測試的策劃：項目測試時要充分考慮單元測試過程並為各過程留出足夠多的時間：(1)、單元測試計劃；(2)、單元測試設計；(3)、單元測試實現；(4)、單元測試執行；(5)、單元測試評估。以上活動QA、專案經理在檢查專案計劃時需要驗證這些計劃是否存在。

單元測試計劃：時間進度表；工作量；任務分配；資源安排；測試載入器；結束標準(可以設定量化標準)；風險分析(譬如被壓縮工作量、技能不足等)；風險應對；輸出單元測試計劃文檔。

單元測試設計：對哪些單元進行測試；被測單元與其他模組之間的關係；測試策略選擇；如何設計測試案例；如何設計單元測試代碼；輸出單元測試案例文檔。

單元測試實現：編寫測試案例；測試指令碼編寫；測試驅動構建；樁構建；輸出測試案例；輸出測試代碼和指令碼。

單元測試執行：搭建測試環境；執行測試指令碼；記錄測試結果；跟蹤缺陷；迴歸測試；輸出單元測試報告。

5.        單元測試的裁剪：不建議裁減掉整個單元測試。

單元測試環節的裁剪策略：(1)、範圍裁剪；(2)、過程裁剪。

單元測試的範圍裁剪，如果測試時間不夠，可優先考慮以下部分：(1)、對項目目標達成最重要的功能；(2)、使用者最常用的功能；(3)、對系統安全效能影響最大的功能；(4)、和“錢”最有關係的功能；(5)、對使用者最重要的功能；(6)、在開發過程早期就可以測試的部分；(7)、代碼最複雜的部分；(8)、開發得最匆忙的部分；(9)、前一版本或類似項目中造成問題的部分或相關部分；(10)、類似項目中花費大量維護費用的部分或相關部分；(11)、需求或設計中不清晰的部分；(12)、開發人員認為最可能有問題的部分；(13)、一旦有問題會造成客戶最大損失的部分；(14)、一旦有問題會造成最大維護成本的部分；(15)、風險/時間比最大的部分。

6.        單元測試的跟蹤監控：

跟蹤監控的形式：(1)、項目周例會的召開(最佳實務)：本周完成情況；下周計劃情況(擷取承諾)；風險問題；目前各種定性、定量指標的監控。進度、工作量、範圍、品質、風險問題、承諾、資料、關鍵軟硬體資源、人員參與等。(2)、項目裡程碑的召開：階段工作成果；下階段是否開展及開展工作計劃等等；階段定性定量指標監控；風險問題等等；(3)、事件驅動。

項目跟蹤監控的兩大件：(1)、進度表：任務是否在要求時間點結束；(2)、品質目標表：任務是否達到完成的標準。

項目跟蹤監控的新理念：品質目標 & 進度跟蹤的配合使用。

7.        TDD測試驅動開發：(1)、TDD以測試作為編程的中心，它要求在編寫任何代碼之前，首先編寫定義代碼功能的測試案例，編寫的代碼要通過案例，並不斷進行重構最佳化；(2)、TDD不是為了全面測試，而是在品質保證的前提下提高開發的效率。測試驅動開發強調測試並不應該是負擔，而應該是協助減輕工作量的方法。

TDD測試驅動開發的基本流程：(1)、定義應用程式的功能要求，可以記錄成一個TODO列表；(2)、熟悉應用程式的功能區域，確定要使用的單項功能項或功能要求；(3)、建立驗證要求的測試清單；(4)、為功能或要求定義介面和類；(5)、編寫測試代碼；(6)、運行測試案例不通過；(7)、根據測試編寫/修改產品代碼；(8)、運行測試直到所有測試都通過；(9)、整理、重構代碼，並運行測試代碼通過；(10)、重複上面的步驟。

TDD不僅僅是測試技術，它的目的也不是僅僅用來測試代碼。TDD是一種物件導向的開發方法。(1)、TDD首先是一種分析方法。它迫使程式員仔細思考要做什麼和不要做什麼，特別是各種例外的情況，並用程式語言正式的寫下來。這就好像在程式員的任務和程式員之間簽訂了一個清晰的正式合約。(2)、TDD是一種設計方法。程式員必須清晰的定義程式的驗收準則才能寫出它的Function Test。而此時程式員無需清除內部如何?的。程式員只需要考慮Class的介面和功能，這不就是物件導向的封裝設計。(3)、TDD是一種重構和最佳化的方法。我們總希望代碼可以漂亮、運行效率高，所以我們會不斷地去改進。

測試驅動開發的最佳實務：(1)、簡化：保持測試案例、原始碼儘可能的簡單，以驗證業務為首要目標；(2)、業務導向：功能性測試，針對每一個需要驗證的業務情境進行測試，而不是對代碼的每一個方法進行測試；(3)、測試隔離：每一個測試類別都可以單獨運行，不依賴於其它任何測試；也可以一起執行，而不會互相干擾，提高案例的可維護性；(4)、測試清單：在開始開發之前，先列出所有需要的測試，並在開發中不斷維護該列表，避免遺忘一些必要的測試；(5)、及時重構：開發出來的單元測試和功能代碼都需要不斷重構，改進代碼的可讀性，可維護性，減少冗餘代碼等；(6)、反向工程：在某些開發環境中，如Eclipsse，可以使用IDE所提供的反向工程能力從測試代碼自動產生必要的類、方法等；(7)、代碼注釋：不需要另外單獨的文檔，而是在測試類別中對每個測試方法對應的業務情境，輸入和期望的輸出進行詳細的描述；(8)、小步前進：當功能單元較大時，為降低難度，可分解為多個更小的功能單元，並逐一用TDD實現。

TDD測試案例的編寫：採用傳統的功能測試技術，集中功能測試，集中容易出現問題的模組的測試工作。(1)、案例應盡量類比正常使用情境，深入測試測試案例再考慮白盒內容。TDD的難易程度可以通過測試案例的深入程度來調節；(2)、全面的功能性測試應該盡量做到正常值、邊界值、異常值；核心的代碼如有必要，最好能做到白盒的語句、分支、路徑覆蓋，但此時也要考慮案例與代碼過於相近，不好維護的情況；(3)、測試案例和測試資料應該盡量簡單，容易理解；(4)、為了避免對其它代碼過多的依賴，可以實現簡單的樁函數等；(5)、如果內部狀態非常複雜或者應該判斷流程而不是狀態，可以通過輔助輸出日誌字串的方式進行驗證。

TDD只適用於功能性明確的工程項目，不適用於某些探索性的，輸入輸出不確定的開發，比如密碼系統，人工智慧，安全等領域的研發。

8.        白盒測試：(1)、測試依據：根據程式的內部結構，比如語句的控制結構，模組間的控制結構以及內部資料結構等進行測試；(2)、優點：能夠對程式內部的特定部位進行覆蓋測試；(3)、缺點：無法檢驗程式的外部特性，無法對未實現規格說明的程式內部欠缺部分進行測試；(4)方法舉例：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、路徑覆蓋。

幾種常用的白盒邏輯覆蓋方法：(1)、語句覆蓋；(2)、判定覆蓋；(3)、條件覆蓋；(4)、判定----條件覆蓋；(5)、路徑覆蓋。

語句覆蓋：在測試時首先設計若干個測試案例，然後運行被測程式，使程式中的每個可執行語句至少執行一次。這裡所謂“若干個”當然是越少越好。語句覆蓋在測試被測試程式中，除去對檢查不可執行語句有一定作用外，並沒有排除被測程式包含錯誤的風險。因為被測程式並非語句的無序堆積，語句之間的確存在著許多有機的聯絡。

判定覆蓋：按判定覆蓋準則進行測試是指，設計若干測試案例，運行被測程式，使得程式中每個判斷的取真分支和取假分支至少經曆一次，即判斷的真假值均曾被滿足。

條件覆蓋：是指設計若干測試案例，執行被測試程式以後，要使每個判斷中每個條件的可能取值至少滿足一次。

判定/條件覆蓋：要求設計足夠的測試案例，使得判斷中每個條件的所有可能至少出現一次，並且每個判斷本身的判定結果也至少出現一次。

路徑覆蓋：按路徑覆蓋要求進行測試是指，設計足夠多的測試案例要求覆蓋程式中所有可能的路徑。

由此看出，各種結構測試方法都不能保證程式的正確性，必須多種方法結合進行。我們可以通過代碼複查來補充單元測試，適當降低單元測試難度。

測試只是為了儘可能的挑選錯誤，而不是用來證明測試對象是正確的。

9.        黑箱測試：(1)、測試依據：根據使用者能看到的規格說明，即針對命令、資訊、報表等使用者介面及體現它們的輸入資料域輸出資料之間的對應關係，特別是針對功能進行測試；(2)、優點：能站在使用者立場上進行測試；(3)、缺點：不能測試程式內部特定部位。如果規格說明有誤，則無法實現；(4)、方法舉例：等價類別劃分、邊值分析、因果圖。

等價類別：(1)等價類別劃分：是典型的黑箱測試方法。設計測試案例時，完全不考慮程式內部結構。(2)、方法：把程式的輸入欄位劃分成若干部分，然後從每個部分中選取少數代表性資料當作測試案例。有效等價類別和無效等價類別。(3)、選取理由：窮舉測試的案例數量太大，以至於無法完成。促使我們在大量的案例中選取一部分作為測試案例。

有效等價類別指的是對程式的規格說明是有意義的、合理的輸入資料所構成的集合。利用有效等價類別可以檢驗程式是否實現了規定的功能。有效等價類別可以是一個，也可以是多個。

無效等價類別指對程式的規格說明是不合理的或無意義的輸入資料所構成的集合。利用無效等價類別可檢驗程式容錯能力。無效等價類別至少應有一個，也可能有多個。

等價類別劃分的原則：(1)、如果輸入條件規定了取值範圍或值的個數，則可確定一個有效等價類別和兩個無效等價類別；(2)、輸入條件規定了輸入值的集合，或是規定了“必須如何”的條件，則可確定一個有效等價類別和一個無效等價類別；(3)、如果我們確知，已劃分的等價類別中各元素在程式中的處理方式是不同的，則應將此等價類別進一步劃分成更小的等價類別。

10.    改良後的單元測試：(1)、單元測試是針對軟體設計的適當單位----大單元(改良1)，進行正確性檢驗的測試工作。其目的在於發現“大單元”模組內部可能存在的差錯；(2)、專業測試人員與開發人員一一結對(改良2)的方式；(3)、先黑盒，後輔助白盒分析補充測試案例(改良3)。

11.    靜態單元測試：代碼複查(code review)，一種通過複查代碼提高代碼品質的過程。代碼複查俗稱“靜態單元測試”，通俗講，大家幫那個同事看看他寫的代碼，替他把把關。

代碼複查要求代碼適當穩定；同時因為代碼複查可能會大規模修改代碼，使得以前做的單元測試失效，因此應放在單元測試前面。

代碼複查發現的問題是內部邏輯問題，其測試的內容及效果不是可以通過系統測試、驗收測試等正式發行前小眾測試替代的。缺少代碼複查環節，品質控制上就少了有力環節。

選取不同的代碼複查自動化工具，如PMD、findbugs、sourcemonitor、C++ Test、Jtest、FindBug、checkStyle等等。

12.    結對程式設計：兩位程式員在一台電腦前工作，一個負責敲入代碼，而另外一個即時檢視每一行敲入的代碼。操作鍵盤和滑鼠的程式員被稱為“駕駛員”，負責即時評審和協助的程式員被稱為“領航員”。領航員檢視的同時還必須負責考慮下一步的工作方向，比如可能出現的問題以及改進等。

13.    組態管理(configurationmanagement, CM)：採用技術手段和行政手段進行管理和監督的一套正常化方法；包括，對配置項的功能特性和物理特性加以標識，並將其檔案化；控制這些特性的變更；報告變更進行的情況和變更實施的狀態，並驗證與規定需求的一致性。

配置項(configurationitem, CI)：是組態管理的指定實體。包括軟體產品的所有組成元素(技術文檔、電腦程式、資料檔案和分包商的軟體組件。例如源碼、執行碼、系統內容定義、資料庫定義、參數檔案、編譯器、資料轉換程式、安裝程式等)。

基準(BaseLine)：是描述一個或多個配置項以及構成配置項的相關實體，一般在項目或產品過程各階段的結束點形成，其形成標誌是有一個或多個軟體配置項通過驗證與確認而獲得認可。基準為持續地評價配置項提供穩定的基礎。

版本(Version)：一組配置項在某一時刻或某一特定點的集合。

組態管理(CM)的目的是通過組態識別、配置控制、組態狀態報告、配置審計等來建立和維護產品生命週期中的工作產品一致性和完整性。

組態管理各庫介紹：(1)、開發庫：僅供開發人員個人使用的開發工作環境，由開發人員自己管理；(2)、配置庫：用於儲存和管理變更受控的工作產品，供項目組/團隊及其相關人員共同使用，由版本管理員管理；(3)、產品庫：用於儲存和管理已形成產品基準並可發布的軟體產品。公司有且僅有一個產品庫，是向客戶發布軟體產品的唯一源頭；(4)、構建庫：進行產品構建(從源碼產生執行碼)的環境，由版本管理員負責管理，在構建過程中不能進行變更操作，要保證源碼和執行碼的一致性；(5)、測試庫：進行產品測試的環境，由版本管理員負責管理，包括搭建測試環境及更新測試環境中的版本；(6)、組態管理庫：開發庫、配置庫、構建庫、測試庫、產品庫統稱為組態管理庫。

14.    產品整合：包括計劃、整合和發布三個主要活動。在整合的同時對介面進行管理。

計劃中的關鍵元素：整合方案、整合順序、Integration Environment配置、Build方案。

整合的目標：將分模組編碼後得到的各個分離的構件或子系統進行串連，合并成一個統一的系統。

介面管理目標：確保介面之間的相容性，減少整合失敗的可能。

15.    持續整合(continuousIntegration, CI)：是一種軟體開發實踐，即團隊開發成員經常整合它們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建(包括編譯、發布、自動化測試)來驗證，從而儘早地發現整合錯誤。

持續整合要求開發人員頻繁地提交他們的所完成的工作產品，這個頻率通常是至少每天一次，有時候可以多次。每次整合會通過自動化構建(automated build)的方式進行盡量快速地驗證，以確保新提交的變化不會造成新的問題。如果在整合的過程中出現異常，則應當快速的反饋給相關的人員。

構建是將原始碼放在一起，並驗證軟體可以作為一個一致的單元啟動並執行過程；驗證活動一般包括編譯、測試、審查和部署。

持續整合的價值：減少風險；減少重複過程；任何時間、任何地點產生可部署的軟體；增強項目的可見度；建立團隊對開發產品的信心；免費的測試專家----編譯器。

持續整合要素：統一的程式碼程式庫；自動構建；自動化的測試；每個人每天都要向程式碼程式庫主幹提交代碼；每次代碼遞交後都會在持續整合伺服器上觸發一次構建；保證快速構建；類比生產環境的自動化的測試；每個人都可以很容易的擷取最新可執行檔應用程式；每個人都清楚正在發生的狀況；自動化的部署。

持續整合原則：所有的開發人員需要在本地機器上做本地構建，然後再提交的版本控制庫中，從而確保他們的變更不會導致持續整合失敗；開發人員每天至少向版本控制庫中提交一次代碼；開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器；需要有專門的整合服務器來執行整合構建，每天要執行多次構建；每次構建都要100%通過；每次構建都可以產生可發布的產品；修複失敗的構建是優先順序最高的事情。

持續整合第二版：只維護一個源碼倉庫；自動化build；讓你的build自行測試；每人每天都要向mainline提交代碼；每次提交都應在整合電腦上重新構建mainline；保持快速build；讓每個人都能輕易獲得最新的可執行檔；每個人都能看到進度；自動化部署。

持續整合的分級管理模型，包括構建管理、系統部署、自動化的測試和分析報告四個維度五個等級，貫穿軟體開發全過程。

自動化構建工具：ApacheAnt、Phing、NAnt.

持續整合(CI)：(1)、CI要求Team Dev能夠頻繁地整合開發與測試工作，以便儘早發現問題，減少項目風險；(2)、CI其實是由一系列的最佳實務所構成：原始碼的版本控制和管理、日構建、煙霧測試 (Smoke Test)、代碼複查、自動部署等；(3)、持續整合提供產品品質的快速反饋，保證隨時擁有可工作的軟體產品。

持續整合的好處：(1)、儘早排除缺陷，避免整合時爆發大量問題，降低品質成本；(2)、面向客戶交付，任何時間、任何地點產生可部署的軟體；(3)、使得系統測試儘早開始，測試人員儘早介入；(4)、採用免費的測試人員----編譯器；(5)、確保良好開發環境，提升開發效率；(6)、降低專案管理(尤其是版本管理)的成本，約10%；(7)、增加專案管理的可視性；(8)、減少項目風險。

敏捷開發強調UT、CI，敏捷開發最佳實務：(1)、增量迭代式開發；(2)、面向客戶交付的開發模式；(3)、需求的優先順序排序(產品待辦列表)；(4)、任務拆分成細粒度的管理方法(多級專案規劃)；(5)、項目跟蹤監控時的每日站立會議(不要超過15分鐘)；(6)、跟蹤監控的公示(看板、燃盡圖 (burndown chart))，避免項目前松後緊；(7)、加強單元測試、代碼複查，強調測試驅動開發(test driven development, TDD)；(8)、引入持續整合等開發環境(持續整合)；(9)、引導客戶積极參与開發過程(客戶緊密參與)；(10)、當規模較小時，溝通無需文檔驅動時，後續補文檔；(11)、鼓勵項目群組成員去主動學習項目已定義過程的能力；(12)、持續流程改善(自適應，sprint回顧會議)。

 

軟體測試培訓筆記