環境搭建思路/測試流程

• 1.軟件測試環境搭建
• • 1.1 搭建測試環境前
  • 1.2 環境搭建模式
  • 1.3 測試環境建設思路
• 2.測試過程
• • 2.1 測試策劃過程
  • • 2.1.1 需求分析
    • 余額寶需求測試實戰
    • 2.1.2 測試策略
    • 2.1.3 測試方案設計
    • 2.1.4 測試方案評審

是看著課程聽的，做的課程的隨堂筆記
課程的鏈接如下：
https://coding.imooc.com/class/411.html

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 測試方案評審

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

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

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

總結

以上是生活随笔為你收集整理的软件测试-环境搭建思路/测试流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。