敏捷軟件測試讀書筆記

第一章   敏捷測試的定義

敏捷方法：Scrum（迭代式增量軟件開發過程）、極限編程（XP）、Crystal、動態系統開發方法（DSDM）或特性驅動開發（FDD）等。

敏捷是迭代的和增量的。

 

極限編程是一個輕量級的、靈巧的軟件開發方法；同時它也是一個很是嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何一個軟件項目均可以從四個方面入手進行改善：增強交流；從簡單作起；尋求反饋；敢於實事求是。極限編程和傳統方法學的本質不一樣在於它更強調可適應性而不是可預測性。 

 

敏捷軟件開發宣言：

• 個體和交互賽過流程和工具
• 可用的軟件賽過完備的文檔
• 客戶協做賽過合同談判
• 響應變化賽過遵循計劃

 

敏捷測試人員的十條法則

提供持續反饋、爲客戶創造價值、進行面對面的溝通、勇氣、簡單化、持續改進、響應變化、自我組織、關注人、享受樂趣

 

支持團隊的面向技術測試

單元測試驗證代碼段的行爲。組件測試經過測試類和方法間的交互幫助鞏固系統的一個可部署部分的總體設計。

可靠的源碼控制、配置管理和持續集成是從指導開發的程序員測試中獲取價值的要素。

 

持續集成是敏捷團隊的核心實踐。

 

單元測試的工具

Java的Junit、 .NET的NUnit、Perl和Ruby的Test::Unit、Python的PyUnit

 

爲了幫助支持團隊的面向技術測試，敏捷團隊須要例如源代碼控制、測試自動化、IDE和構建管理工具等。

 

支持團隊的面向業務測試

面向業務的測試同時基於示例和使用編程語言描述需求。

 

第一象限的活動確保內部質量，最優化項目生產力，減小技術性負債。第二象限測試定義和驗證外部質量，同時幫助咱們瞭解什麼時候完成。`

 

覈對如下內容以解決需求問題：

• 業務知足條件
• 對現有功能的影響，如網站、文檔、票據、表格和報表
• 法律方面的考慮
• 平常運轉流程的影響
• 對UI故事的實物模型的引用
• 幫助文本，或者由誰來提供它
• 測試用例
• 數據遷移（若是適用的話）
• 所需的內部交流
• 與業務夥伴和廠商的外部交流

 

面向業務測試工具包

面向業務測試的目標是促進客戶和開發人員之間的溝通和協做，確保團隊在每一次迭代中都產生真正的價值。

做爲一名（角色），我須要（功能），所以（業務價值）。

Windows NetMeeting和VNC這樣的工具使不一樣地區的兩位同事可以結對測試。 視頻會議工具如WebEx和Skype支持遠程團隊和客戶之間的協做和演示。在線白板（如Scriblink）和交互式白板（Mimeo）方便了分散式的白板討論。

 

行爲驅動開發（BDD）是測試驅動開發的變種。它與領域驅動設計有關，關注領域而不是技術。一些BDD工具包括：用於Java平臺的easyb和JBehave、用於.NET的NBehave和Nspec、用於Ruby的RSpec。

 

Fit（集成測試框架）。可經過http://fit.c2.com瞭解Fit。

FitNesse是一個基於Fit的Web服務器、Wiki、軟件測試開源工具。FitNesse和Fit之間的主要區別在於FitNesse的測試經過Wiki標記符而不是HTML表格編寫。它也支持在電子表格中建立測試並導入到測試中。

可經過http://www.fitnesse.org瞭解FitNesse。

 

測試Web服務

• CrossCheck——是測試Web服務的一種工具。經過提供WSDL（Web服務描述語言），CrossCheck編譯頁面並顯示一個標籤頁式的菜單，其中包含的文本框由用戶填寫。它提供運行模式，能夠添加測試到測試集中而後運行。
• Ruby Test::Unit
• soapUI——可用於性能和負載測試。它能夠在Excel電子表格或者文本文件中循環遍歷各行，能夠用於數據驅動測試。

敏捷開源測試工具（GUI測試）

Watir——Watir（Ruby測試Web應用）是一款開源Ruby庫，用於自動化Windows上的IE瀏覽器。還提供對其它瀏覽器的支持，包括FireWatir（用於Firefox）和SafariWatir（用於Safari）。

Selenium——測試工具集，開源，用於測試Web應用。測試能夠寫成HTML表格形式或者經過經常使用編程語言編寫，而且能夠運行於大多數瀏覽器。名爲Selenium IDE的Firefox插件提供了快速學習該工具的途徑。

Canoo WebTest——在WebTest腳本中，測試在XML文件中以「步驟」描述，模仿了用戶對web界面的操做。WebTest不像Selenium和Watir那樣驅動真實的瀏覽器，它使用HTML模擬須要的瀏覽器。WebTest支持測試PDF文件和Excel文件。

 

如何有效使用工具編寫面向業務測試的策略？

1.    增量構建測試

首先確保最明顯的用例是正常工做的。編寫一個簡單、經常使用路徑的自動化測試來證實代碼完成了最基本的功能。在測試經過後，再開始考慮其它狀況。編寫面向業務測試是一種迭代過程。

討論測試會讓開發人員意識到他忽略或者誤解了某個需求。

2.    確保測試經過

每當測試在持續集成和構建過程當中失敗時，全隊的最高優先級（除了關鍵的生產問題）應該是讓構建經過測試。

3.    使用合適的測試設計模式

4.    構建/操做/檢查 （搭建/執行/驗證）

依據測試的目的在內存或者數據庫中構建輸入數據；調用產品代碼來操做這些輸入；檢查運算結果。

使用真實數據庫的測試能夠幫助測試那些數據訪問層和業務邏輯層沒法輕易分離的遺留代碼。

5.    基於時間的、活動和事件模式

6.    瞭解更多

業務邏輯和算法應該可以被測試模塊訪問，而不須要經過用戶界面或者批處理過程。這保證了測試驅動開發，也會生成可測試的架構。

7.    關鍵詞和數據驅動測試

 

可測試性

o    代碼設計和測試設計

o    自動化與手動第二象限測試

o    測試管理

 

團隊須要正確的工具來啓發需求和示例，從全局到細節，包括覈對表、思惟導圖、電子表格、模型、流程圖和各類軟件工具。

 

第10章   評價產品的面向業務測試

敏捷開發增量迭代的特性帶來了一個在開發軟件的同時演示其業務價值的機會。

 

探索測試（ET）——同時進行的測試設計、測試執行和學習。探索測試自己不是一種測試技術，而是一種能夠應用於任何測試技術的方式或態度。探索強調我的和交互而不是過程和工具。

做爲一個研究性工具，是用戶故事測試和自動化迴歸集的重要補充。探索測試並非經過詳盡的測試來評估軟件，它的一個反作用是增長了測試人員對被測系統的瞭解。它揭示了產品中能夠更多地使用自動化測試的區域，並能引出很多對於新特性的想法，而這些新特性每每會演變成新的故事。

 

可用性測試

o    用戶需求和角色測試

o    導航

o    研究競爭對手

 

API（應用程序編程接口）是能夠被其它軟件應用或構件執行的一組功能。

o    改變輸入參數

o    改變調用順序

 

探索測試輔助工具

o    設置測試數據

PerlClip能夠用不一樣類型的輸入數據測試文本輸入框。從http://www.satisfice.com免費獲取。

o    幫助評估測試會話的輸出

LogWatch用於監控日誌文件中的錯誤信息。

o    模擬器——用於爲系統生成具備關鍵特徵和行爲的，相似於真實數據的工具。

o    仿真器——仿真器能複製一個系統的功能，從而與被測的系統行爲一致。當要測試系統中與其它系統或設備的接口代碼時，仿真器十分有用。

 

第11章   利用面向技術的測試評價產品

非功能性需求包括配置、安全、性能、內存管理、各類ility（好比可靠性、交互性以及可伸縮性）、恢復，甚至還有數據轉換。

可靠性（PSR）測試

 

如何完成安全性測試任務？

1.    採用持續集成（CI）週期性地運行自動化測試套集。

2.    學習使用開源的靜態代碼分析工具，將其加到CI中。

3.    安裝自動化安全漏洞檢測工具，如Nessus（http://www.nessus.org/nessus/）。能夠在非GUI模式的命令行中運行Nessus，這樣就能夠將其集成到CI工具中了。

4.    學習使用開源的fuzzing工具，將其加到CI中。

詳情參見https://en.wikipedia.org/wiki/Buffer_overflow和https://en.wikipedia.org/wiki/Uncontrolled_format_string

關於可用於靜態代碼分析的工具列表，參見https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

 

可維護性

傳統項目經過完整的代碼審查或是檢測來實現。敏捷團隊常用結對編程，這自己就包含了持續的代碼審查。此外還需：

• 鼓勵開發團隊使用標準和指南進行應用編碼
• 創建GUI的開發標準
• 數據庫設計須要靈活和可重用

 

交互性——不一樣系統和組織協同工做與分享信息的能力。交互性測試會檢查兩個或多個通訊系統之間端到端的功能。

 

兼容性

項目類型代表了須要進行多少兼容性測試。

 

可靠性——軟件的可靠性是指系統在常規與意外環境下執行和保持其功能的能力。

一些用於度量可靠性的統計數據有：

• 首次失敗時間
• 平均失敗時間

 

性能、負載、壓力以及可伸縮性測試

可伸縮性——可伸縮性測試驗證應用在多用戶訪問的狀況下是否依舊可靠。重要的是要考慮整個系統而非應用自己。

 

一般性能測試的目的是肯定系統中的瓶頸或是創建基準以供將來測試所用。此外，它還會確保系統符合性能目標和需求並幫助負責人就應用的總體質量作出決策。

負載測試用於在愈來愈多的用戶同時訪問時評估系統的行爲。壓力測試用於在負載超出預期的狀況下評估應用的健壯性。

性能與負載測試工具：

開源： Apache Jmeter、Grinder、Pounder、ftptt以及OpenWebLoad

付費： NeoLoad、WebLoad、eValid、LoadTest、LoadRunner以及OSATest

 

敏捷回顧也是每次迭代計劃會議的一部分。

 

測試自動化前期須要：適當的輔導、充足的時間和強大的管理支持。

 

將單元測試自動化與持續集成放在首要位置。

 

測試矩陣是以被測試的功能爲縱軸，測試條件爲橫軸而造成的矩形圖表。

 

有用的迭代度量

• sprint發佈的代碼通過重構並按要求編碼
• sprint發佈的代碼通過單元測試
• sprint發佈的代碼包括經過的、自動化的驗收測試
• sprint發佈的代碼被成功集成
• sprint發佈的代碼完好陷

 

測試人員經歷的一個迭代

1.    發佈或主題計劃階段：

• 故事評估、設定優先級
• 制定測試計劃（測試種類、測試基礎設施、測試環境、測試數據、測試結果（報告））
• 準備可見性（跟蹤測試任務及其狀態、傳達測試結果、經過的測試數、代碼覆蓋率、缺陷度量）

2.    迭代前的準備

• 事先明確（客戶意見一致、用戶故事的規模、資源）
• 肯定缺陷的優先級

3.    迭代開始（是確保故事可測試並提供充足測試數據的最後機會）

• 瞭解細節，肯定工做量
• 製做並審查高層次的測試和示例

4.    編碼和測試

• 與開發人員合做、與客戶交流、處理缺陷、完成測試
• 迴歸測試

5.    迭代結束時的收尾：

• 迭代演示
• 迭代回顧
• 慶祝成功

 

用戶驗收測試（UAT）

 

敏捷測試成功的7個要素：

1.    使用全隊參與方法

2.    利用敏捷測試思惟

3.    自動化迴歸測試

4.    提供和得到反饋

5.    構建核心實踐的基礎（持續集成、可控的測試環境、管理技術債務、增量工做）

6.    與客戶協做

7.    保持大局觀