軟件測試-環境搭建思路/測試流程

1.軟件測試環境搭建

思考：
在什麼條件下做軟件測試？
怎麼做軟件測試？

1.1 搭建測試環境前

確定測試目的
功能測試（驗證軟件是否滿足用戶的需求），穩定性測試，還是性能測試（軟件的效率），測試目的不同,搭建測試環境時應注意的點也不同。

例如：
1.功能測試：不需要大量的數據，需要覆蓋率高，測試數據要儘量真實；
性能測試：需要大量存量數據或者與實際硬件環境儘可能相似的硬件配置；（比如對於app在當一千萬個用戶同時訪問的時候能否應付）

2.測試的軟件環境要儘可能模擬真實的環境，選用合適的操作系統和軟件。（比如有的用戶用ios系統，有的用安卓系統）

3.瞭解測試軟件運行的最低要求及用戶使用的硬件配置

4.瞭解用戶常使用的軟件，避免我們做的軟件配置與其相沖突（萬一產生衝突可能會閃退或者別的錯誤，所以要避免和用戶常用軟件配置衝突。）

5.產品化的測試需要考慮兼容性測試（舉例就是對外的app或者網頁，即不管什麼手機裝了什麼軟件都能使用我的軟件）

6.營造獨立的測試環境，不同人員和項目不要對當前測試產生影響（希望我們的測試不要因爲其他人員，項目而改變。比如我現在做的測試，萬一開發也能看到他改動了，對我的測試就會有影響。）

7.構建可複用的測試環境
通過備份或數據隔離的方式。
重複運用一套測試環境進行多版本多時間段的測試。

1.2 環境搭建模式

線下搭建：在公司本地進行搭建

申請獨立測試服務器或者虛擬機

測試環境配置

測試項目導入

例如：
對於搭建java環境：
配置java環境(下載jdk並配置環境變量)
下載並安裝中間件(tomcat、 jetty或其他)
安裝數據庫並導，入初始化腳本

線上搭建：
Docker模式（我把我的環境，想要的東西封到一個大盒子裏，然後想用的時候就把盒子扔出去，盒子就直接構建出環境。）
構建自己的image鏡像，然後執行deploy

依賴第三方平臺：
比如一個雲環境，上面有可以使用的虛擬機，數據庫等，自己按需組合即可
eg.螞蟻金融雲

1.3 測試環境建設思路

考慮點:
用途、使用成本、維護成本

基本架構:
研發環境:用於研發自測、集成測試（基於研發使用的環境，他自己可以進行自調）
測試環境:用於日常單系統或兩兩微服務之間測試，可同時集成自動化測試迴歸

聯測環境:
完備環境，用於大型聯測。
（整體的聯測涉及到所有的業務流，接口等，所以要一個非常完備的環境）

外聯環境(如果有需求) :
穩定版本環境，用於外部商戶等聯調

灰度/沙箱環境：
用於生產數據測試，仿真測試。
僅僅在測試中自己造數據可能會遺漏，所以引入生產數據
（灰度 生產驗證等；沙箱 數據查詢 生產數據，生產文件校驗等）

2.測試過程

在邏輯上。測試活動是按順序進行的
但是實際測試過程中，這些活動是可以重疊或同時進行的（比如支付寶的加好友，登錄，轉賬等。對於加好友模塊的測試，還是需要先登錄這個模塊的操作的）

2.1 測試策劃過程

測試策劃分爲以下三個部分：
測試策劃步驟：

進行 測試需求的分析

確定需要測試的內容或質量特徵

明確測試的充分性要求

提出 測試的基本方法

測試策劃需要進行：

確定 測試的資源和技術需求

進行 風險分析與評估

根據上述分析結果制 定測試計劃

根據測試計劃開展相應的 測試控制活動

2.1.1 需求分析

過往的軟件生命週期中，需求分析階段是沒有測試人員參與的。但隨着軟件過程的優化， 測試人員的加入對需求分析階段有了更大的作用。

測試在需求分析階段加入的原因

1.測試工程師參與需求分析， 對需求瞭解很深刻，減少與開發人員的交互，節省時間（針對一些功能，測試需要在初期和開發人員來進行溝通）
2.早期確定測試用例的編寫思路， 爲測試打好了基礎
3.可以 獲取一些測試數據，爲測試用例設計提供幫助（產品可能會更瞭解用戶的需求和掌握更多的數據，所以早一點可以獲取一些測試數據）
4.可以 發現需求不合理的地方，降低測試成本（違反正常的操作準則等 可以提早發現，避免更多的回爐重造。）

需求測試的作用：
1.測試需求的分析用來確定整個測試工作，明確測試對象以及測試工作的範圍和作用，並作爲測試覆蓋的基礎。
2.被確定的測試需求項必須是可覈實的，測試需求必須有一個可觀察、可評測的結果。
3.如果無法覈實的需求就不是測試需求。
4.測試需求分析還包括與客戶的交流以澄清某些混淆
5.明確哪些需求更重要
6.確保風險承擔者儘早對項目達成共識
7.對將來的產品有清晰的認識
8.測試需求是制訂測試計劃的基本依據
9.測試需求是設計測試用例的指導
10.確定了要測什麼、測哪些方面纔能有效設計用例

需求驗證：
◆審查需求文檔
◆對需求文檔及相關模型進行仔細檢查
◆另外在需求開發期間所做的非正式評審也是有所裨益的

應當這樣做：
以需求爲依據編寫測試用例：
編寫用戶手冊
在需求開發早期即可起草一份淺顯易懂的用戶手冊，用以描述出所有對用戶可見的功能並用它作爲需求規格說明的參考並輔助需求分析

確定合格的標準：
讓用戶描述什麼樣的產品纔算滿足他們的要求和適合他們的使用
將確認合格的測試建立在使用情景描述或使用實例的基礎之.上

餘額寶需求測試實戰

以支付寶上餘額寶業務爲例分析

1.原始需求:
早在2012年左右，支付寶雖然很快被大衆接受,但是卻面臨着一種比較普遍的現象:支付寶賬戶餘額內總是有一 筆閒置資金，雖然不同賬戶資金數額有多有少，但總的來說，這筆躺在賬戶什麼做不了的閒置資金數額還是比較龐大的，對於支付寶的發展而言非常不利

2.產生需求：
於是，產生了這樣一個需求，與基金公司合作推出貨幣基金產品，同時用戶購買貨幣基金後，可直接通過貨幣基金金額進行支付購買商品或服務。
貨幣基金可以視同餘額、集分寶一樣作爲支付工具進行消費。

3.審查需求文檔：
我們一起簡單看下需求文檔，大概分爲以下：
需求分析
流程圖
文字流程
約束條件
扣款的優先級
異常處理
安全控制
頁面

需求分析過程中我們會將上面的流程分爲:
貨幣基金購買、提現、消費、資產管理、交易查詢幾部分
可以通過需求規格說明書檢查列表進行檢查

2.1.2 測試策略

測試之前需要考慮的問題：

你知道要測試的系統是幹什麼的嗎?
你瞭解系統有些什麼特點嗎?
系統有些什麼功能?
系統哪些部分需要測試?哪些不要測試?
系統對性能有什麼要求?
系統對安全性有什麼要求?

由以上問題可以得出測試策略的要求：
測試策略是描述測試項目和測試任務之間的關係。
它用來說明要測什麼，如何測，如何協調測試資源和測試時間等。

測試策略要素：
1.測試安排、發佈計劃
羅列測試項目本身重要的里程碑
每個里程碑都需要有明確的結束時間，這個時間可以指導我們後續的測試

2.測試時間
如果測試時間安排不足，我們就可以在後續的測試範圍中挑選優先級比較高的特性來執行測試
這樣可以最大限度的保證產品的質量

3.測試範圍（按照優先級排列）
分爲In Scope和Out Of Scope（分爲在範圍內和範圍外）
需要說明哪些模塊是在測試範圍中的，哪些是本階段測試不考慮的
對於在測試範圍中的模塊，需要給出優先級，以便相應測試時間不足的情況
對於不在測試範圍中的模塊，需要給出原因

4.測試資源

測試資源在測試策略中也是很重要的一環，它分爲人力和工具兩部分
人力資源主要說明參與測試的人員，當然可以包括很多的角色，如專業測試人員，客戶，產品經理等
工具即可能用到的其他軟件

5.測試環境
測試環境主要包括推薦環境解決方案，操作系統要求，軟硬件要求
對於推薦解決方案，需要陳述的是對測試項目對其他軟件的依賴
比如測試項目對JAVA有依賴，推薦版本可能就是1.7

6.測試方法
測試方法的羅列主要是爲了說明針對測試項目我們要開展哪些類型的測試
功能測試是必須的，非功能測試是可選的

7.文檔管理
對於一個完整的產品來說，文檔是很重要的一環，它一般包括安裝、升級文檔，用戶指南等
文檔不單單是一個文件，已經是軟件的一部分，所以需要完成測試才能發給用戶，以免文檔不正確誤導用戶從而使他們對測試項目失去信心。

8.風險管理
風險管理模塊需要羅列出來現在已知的可能會出現不確定性的因素（比如我們這個公司的技術沒法達到用戶的要求，比如同時有3億人來訪問某個app）
這些因素可能來自技術，資源或者其他方面的（對於需要的軟件，有可能非常貴，公司負擔不起，或者需要和銀行對接才能測試成功，但是有可能無法和銀行對接）

2.1.3 測試方案設計

測試策略:
側重需求分析，評估風險，定義測試範圍
確定測試方法，制定測試啓動、停止、完成標準和條件

測試計劃:
制定項目 測試過程中的測試重點
各個階段的任務分配以及時間進度安排
並提出對各項任務的評估，風險分析，可以包括測試策略

測試方案:
側重測試的方法，測試環境的規劃
測試工具的設計和選擇，測試用例的設計方法，測試代碼的設計方案

測試策略VS測試計劃VS測試方案
◆實際實施過程中，往往存在這樣類似的方式:

◆ 測試方案=測試計劃+用例設計方案+工具選擇+自動化/性能測試具體方案

◆ 測試計劃=測試策略+測試任務分配+時間進度安排
貨幣基金消費測試方案分析過程
1.分析需求:
當前測試包含需求項(需求文檔或wiki鏈接等)
2.測試計劃(里程碑)及負責人:
整理當前項目各模塊測試負責人、任務分配及測試時間安排
3.測試範圍、測試重點:
那些point需要測試， 重點放在什麼地方，優先級安排
4. 策略及工具: 是否需要進行自動化、性能、安全測試?使用哪些工具.
5. 測試用例設計方法:
使用什麼樣的黑盒測試方法進行設計(等價類?邊界值?因果圖?等等)
6. 測試環境:
測試環境是什麼?需要哪些服務器、數據庫，配置如何等
7.聯調測試:
是否需要與第三方或其他部門進行聯調?何時開展?聯調包括哪些功能?例如基金公司
8.測試限制:
在測試環境中哪些內容無法測試?
9.測試風險:
在測試或計劃測試過程中由於時間安排、測試限制、優先級分佈可能帶來的測試風險考量

2.1.4 測試方案評審

如果不進行測試方案的評審，會造成嚴重後果：
僅從文檔、溝通獲取信息，可能會造成信息不對稱，認識片面，理解錯誤或不深入等問題
缺少同行交叉評審和開發評審機制，無法充分發揮集體智慧,個人的思維難以突破，可能會出現測試遺漏的情況

測試評審的目的：
呈現測試的工作
與開發達成共識.（比如發紅包這個操作，對於開發來說：錢到了賬上 就算操作完成；對於測試：用戶是否有不想要這個紅包的需求）
不同的思維方式碰撞出火花，借鑑被人的思考方式
培養這樣的行爲模式:願意爲團隊或他人出謀劃策
發揮團隊協作，最大限度發揮個人的經驗，特長，實現技能互補.

評審重點:
採用的測試方法（比如我認爲這個項目不需要用性能測試，但是有可能他需要）
等價類劃分的依據
測試數據的選取和準備方法（比如現在做一個加法計算器，驗證它是否選取，不可能輸入所有的數據，那麼選取那些數據爲什麼選取就是需要評審的）
流程測試的路徑組合（在淘寶中如何進行購買商品的流程）
數據比對選取的對象和檢查點（比如在淘寶上買了新手機，評估下單後數據庫的接口，數據等是否正常）
是否需要模擬數據及模擬數據的方法（比如預言雙十一的活動，那麼需要模擬多少數據多少下單量來制定方案）
基於風險的測試取捨（當克服不了風險的時候需要批漏出來）