怎麼寫出好的敏捷測試（Agile Tesing）策略文檔

敏捷測試策略

在敏捷環境中，咱們在短時間衝刺或迭代中工做，每一個sprint只關注一些需求或用戶故事，所以文檔在數量和內容方面可能不會那麼普遍。

以前咱們得出的結論是，因爲時間限制，咱們可能不須要在每一個sprint的敏捷項目中都有一個普遍的測試計劃，但咱們確實須要一個高級敏捷測試策略做爲敏捷團隊的指導。

敏捷測試策略文檔的目的是列出團隊能夠遵循的最佳實踐和某種形式的結構。請記住，敏捷並不意味着非結構化。

在這裏，咱們來看一個敏捷測試策略樣本以及文檔中包含的內容。

有關：

測試策略一般有一個任務陳述，可能與更普遍的業務目標和目標相關。

典型的使命宣言多是：

經過提供快速反饋 和 缺陷預防而不是缺陷檢測，不斷提供知足客戶需求的工做軟件 。

支持者：

• 在咱們首次定義其驗收標準/測試以前，不會爲故事編寫代碼
• 在全部驗收測試經過以前，故事可能不被認爲是完整的

在敏捷測試策略文檔中，我還會提醒每一個人關於質量保證

• 質量保證是一系列活動，旨在確保產品以系統，可靠的方式知足客戶要求。

• 在SCRUM（敏捷）QA是每一個人的責任，而不只僅是測試人員。質量保證是咱們爲確保新產品開發過程當中的正確質量而開展的全部活動。

測試級別

敏捷測試象限

單元測試

爲何：確保代碼正確開發

世衛組織： 開發人員/技術架構師

內容： 全部新代碼+遺留代碼的從新分解以及Javascript單元測試

時間： 一旦編寫新代碼

地點：本地Dev + CI（構建的一部分）

如何： Automated，Junit，TestNG，PHPUnit

API /服務測試

緣由： 確保組件之間的通訊正常

世衛組織： 開發人員/技術架構師

什麼： 新的Web服務，組件，控制器等

時間： 一旦新API開發並準備就緒

地點： 本地Dev + CI（構建的一部分）

如何： 自動化，肥皂用戶界面，休息客戶端

驗收測試

爲何： 確保知足客戶的指望

世衛組織： 開發人員/ SDET /手冊質量保證

內容： 驗證故事的驗收測試，功能驗證

時間： 功能準備就緒並進行單元測試時

地點： CI /測試環境

如何： 自動化（黃瓜）

系統測試/迴歸測試/ UAT

爲何： 確保整個系統在集成時工做

世衛組織： SDET /手冊質量保證/業務分析員/產品負責人

內容： 場景測試，用戶流程和典型用戶旅程，性能和安全測試

時間： 驗收測試完成後

地點： 臨時環境

如何： 自動（Webdriver）探索性測試

產品積壓

軟件開發失敗的最多見緣由是因爲團隊中不一樣成員的要求不明確和要求的不一樣解釋。

用戶故事應簡潔，簡潔，明確。做爲一個很好的指導方針，最好按照INVEST模型編寫用戶故事。

一個好的用戶故事應該是：

我獨立（全部其餘人）

N egotiable（不是特定的特定合同）

V aluable（或垂直）

E stimable（很好的近似）

S mall（以便適合迭代）

T estable（原則上，即便尚未測試）

應使用如下格式編寫用戶故事

As a [role]

I want [feature]

So that [benefit]

重要的是不要忘記「福利」部分，由於每一個人都應該經過開發故事來了解他們所添加的價值。

驗收標準

每一個用戶故事都必須包含驗收標準。這多是鼓勵與團隊中不一樣成員溝通的最重要因素。

接受標準應該在建立用戶故事的同時編寫，而且應該嵌入到故事的主體中。全部驗收標準都應該是可測試的。

每一個驗收標準應該有許多驗收測試，以Gherkin格式編寫，例如

Scenario 1: Title

Given [context]

And [some more context]...

When [event]

Then [outcome]

And [another outcome]...

故事研討會/ Sprint計劃

在每一個故事研討會中，團隊中的每一個人都會了解故事的細節，以便開發人員和QA瞭解工做的範圍。每一個人都應該對故事的內容有相同的理解。

開發人員應該很好地理解提供故事所涉及的技術細節，QA應該知道如何測試故事，以及是否有任何障礙來測試故事。

有關：

• 若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

防止缺陷

在故事研討會中， 必須參與PO，BA，Dev和QA。

應該考慮場景（有效，無效和邊緣狀況）（QA能夠經過抽象地思考故事在這裏增長巨大價值）並寫在特徵文件中。

重要的是要注意，在測試產品時會出現缺陷（更重要的是），所以在此活動上花費的精力和時間越多，最終的結果就越好。

因爲大多數缺陷都是因爲要求不清晰和模糊，這項活動還有助於防止錯誤行爲的實施，由於每一個人都應該對故事有相同的理解。

一樣，在sprint計劃會議中，爲故事提供的估算應包括測試工做，而不只僅是編碼工做。QAR（手動和自動化）也必須出現在sprint計劃會議中，以提供對故事測試的估計。

發展

測試自動化金字塔

開發開始時，新的生產代碼和/或遺留代碼的修改應該由開發人員編寫的單元測試支持，並由另外一個開發人員或熟練的SDET進行同行評審。

對代碼存儲庫的任何提交都應該觸發從CI服務器執行單元測試。這爲開發團隊提供了快速反饋機制。

單元測試確保系統在技術級別工做，而且邏輯中沒有錯誤。

開發者測試

做爲開發人員，表現得好像您在團隊或組織中沒有任何QA。誠然，QAs有不一樣的心態，但你應該盡力測試。

您認爲經過快速進入下一個故事節省時間，但實際上，當發現並報告缺陷時，糾正問題須要更長的時間，而不是花費幾分鐘來確保該功能正常運行。

遺留代碼的任何新代碼和/或重構都應該具備適當的單元測試，這些單元測試將成爲單元迴歸測試的一部分。

自動驗收測試和非功能測試

自動驗收測試包括集成測試和服務測試以及UI測試，旨在證實軟件在功能級別工做，而且知足用戶的要求和規範。

自動驗收測試一般用Gherkin語言編寫，並使用黃瓜等BDD工具執行。

因爲這些測試一般須要通訊HTTP，所以須要在已部署的應用程序上執行，而不是做爲構建的一部分運行。

非功能測試 （性能和安全性）測試與功能測試一樣重要，所以須要在每次部署時執行。

性能測試應檢查每一個部署的性能指標，以確保性能不會下降。

安全測試應檢查從OWASP派生的基本安全漏洞

相當重要的是，這應該是一個徹底自動化的過程，只需不多的維護就能夠從自動化部署中得到最大的收益。這意味着不該出現間歇性測試失敗，測試腳本問題和破壞環境。

故障應僅歸因於真正的代碼缺陷而不是腳本問題，所以任何不是因爲真正故障致使的故障測試應當即修復或從自動化包中刪除，以便可以得到一致的結果。

迴歸測試

不指望發現不少缺陷。他們的目的只是提供咱們還沒有破壞主要功能的反饋。應該進行很是少許的手動迴歸測試。

煙霧包 - 不該超過15分鐘

此包僅包含高級功能，以確保應用程序足夠穩定以進行進一步開發或測試。

例如，對於電子商務網站，此包中包含的測試多是：

• 產品搜索，
• 產品審覈
• 購買物品
• 賬戶建立/賬戶登陸

完整迴歸包 - 不該超過1小時

此包包含完整的迴歸測試套件，幷包含煙霧包中未包含的全部其餘內容。

在這裏，目標是經過更多的測試得到快速反饋。若是反饋時間超過1小時，則不會很快。經過使用成對測試技術減小測試數量，根據風險建立測試包或並行運行測試。

UAT和探索性測試

若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

沒有理由認爲UAT和探索性測試不能與自動驗收測試並行運行。畢竟，它們是不一樣的活動，旨在找到不一樣的問題。UAT的目標是確保開發的功能具備商業意義並對客戶有所幫助。

PO（產品負責人）應運行用戶驗收測試或業務驗收測試，以確認構建的產品符合預期並知足用戶的指望。

探索性測試應該關注用戶場景，而且應該找到自動化錯過的錯誤。探索性測試不該該找到瑣碎的錯誤，而應該找到微妙的問題。

完成標準

完成上述全部活動而且未發現任何問題後，故事就完成了！

以上是關於敏捷測試策略文檔中可包含的內容的一些指導原則。顯然，這須要根據您組織的需求進行定製，但但願此模板能夠幫助您建立本身的敏捷測試策略文檔。

感興趣的小夥伴能夠來加羣：747981058，你們一塊兒來交流，討論~