全程軟件測試實踐：從需求到運營

　　1 全程軟件測試圖解

　　傳統的軟件測試，可以簡單描述為下圖所示：

　　圖-1-傳統交付測試

　　開發人員完成任務之后，最后交付給測試人員，這種模式下，測試人員不能及早發現需求階段的缺陷，同時測試工作的開展也滯后了，產品質量得不到有效的過程控制和分析，總體進度可能會由于返工問題造成拖延。

　　那什么是全程軟件測試，如下圖所示：

　　(點擊圖像放大)

　　圖-2-全程軟件測試圖

　　在整個SDLC中，三條角色主線和四個階段。

　　三條角色主線：開發、QA、測試，文中主要講解測試。

　　四個階段：需求、開發、發布、日常運營。

　　簡單來說可以歸納為下圖所示：

　　圖-3-全程軟件測試概述

　　測試人員貫穿這四個階段，開展測試活動，試實踐活動簡單描述如下圖所示：

　　(點擊圖像放大)

　　圖-4-全程軟件測試概述

　　每個階段也有開發人員對應的活動，以及QA人員對應的活動。

　　對于產品而言，每次版本迭代，都會經歷：需求、開發、發布，最后推向日常運營，發布階段虛線指向的需求階段和日常運營階段，并不是一個終止階段，而是不斷迭代的過程。

　　那測試人員是如何開展全程軟件測試活動的呢?

　　2 需求階段測試

　　在需求階段，開發人員、測試人員、QA人員主要做的事情，如下表所示：

　　作為測試人員的主要實踐如下：

　　參與用戶故事分析、挖掘故事含混性

　　在sprint會議上，對用戶故事進行分析，檢查功能性需求和非功能性需求是否描述清晰，其中可以將非功能性需求作為驗收要點，例如一個用戶故事：

　　“客戶希望提高響應時間”

　　測試人員應當協助開發人員消除故事的含混性：提高什么的響應時間和響應時間為多少?可以建議修改為：

　　“客戶信息普通查詢返回結果的響應時間為5s內”

　　說明在“客戶信息”模塊，進行“普通查詢”操作，返回結果的時間在5s內，這個陳述句已經清晰表達了，也達到了消除含混性的效果。同樣，測試人員可以編寫提高查詢效率的用戶故事：

　　“客戶在信息查詢模塊，進行普通查詢，能夠在5s內返回結果”

　　“備注：5s為非功能性需求，也是驗收要點”

　　參考經驗庫質疑開發的時間估算

　　在sprint會議上，開發人員根據經驗出牌(團隊自己定義的規則，用撲克牌)估算時間，當給出最終結果的時候，測試人員應當對其進行質疑。測試人員借鑒歷史經驗庫：開發人員在某方面的技能如何、該模塊曾經產生過何種程度的缺陷、修復缺陷的消耗時間是多少等等，綜合考慮，提出疑問，讓開發估算最終的時間，盡可能考慮這些因素。當然，測試人員能夠質疑的其中一個前提是：測試人員具備相關開發經驗。

　　小結：在需求階段，測試人員要發揮作用，減少含混性需求引入到開發階段、同時協助開發做好時間估算。

　　3 開發階段測試

　　在開發階段，開發人員、測試人員、QA人員主要做的事情，如下表所示：

原文轉自：http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational