目錄

前言

       隨著技術的發展，各種應用程式、各種App應運而生!在早期，這些應用程式只是通過開發人員、產品以及部分使用者使用之後，給出相應的修改意見，感覺都OK後就進行上線，在網上或一些app下載平臺上就可以直接使用，沒有進行過規範的軟體測試！這些軟體或多或少會存在一些bug，這些bug有可能是功能上、相容性、效能等各方面的問題！

         為了改善軟體質量不高的問題，軟體測試這門行業才開始受到重視！軟體測試的目的就是為了提高軟體質量，給使用者更好的體驗感！

         不管開發還是測試都有需求方，通過與需求方進行溝通交流，整合資訊，制定成需求說明書！需求說明書：是指使用者對於軟體的功能、效能、相容性、UI等各方的需求文字

         下面給出個人認為比較嚴謹或者規範的測試流程圖：

提取測試點

       在需求說明書通過評審後，這時候開發、產品、測試有統一的需求文件，基於需求說明書，測試根據需求說明書中的內容，提取測試點，測點提取的準則一般是：一個測試點對應一條測試用例！以確保需求的覆蓋率！一般測試人員根據需求說明書，直接進行編寫測試用，這樣容易造成需求覆蓋的不全面！測試點不僅包括需求說明書中指示出的需求點，還包括一些隱性的需求，確保提取的測試點能儘可能多的覆蓋需求！

         測試用例是軟體測試最小顆粒單元也是測試的關鍵點之一。不管是測試的菜鳥還是從事測試多年的老鳥，測試用例測試中必不可以的一環！根據公司業務，每個公司的測試用例都不一樣，通用的模板核心引數主要有以下幾點：用例ID、用例名稱、用例描述、執行步驟、預期結果、實際結果、所屬功能模組、用例狀態、所屬版本號、作者、建立日期。有的公司還有優先順序、前置條件等，這些屬性根據自己公司業務，自己用於完善。測試用例設計要點就是：簡單明瞭、條理清晰！

         下圖給出一個簡單的測試用例模板，模板中的屬性可以根據自己的需求或者業務進行擴充套件和刪除，一般是用例屬性在一列展示，我這邊給出的一個表格模板：

用例設計完成後，不是就要開始進行測試的下一步，而是要經過用例評審。雖然需求說明書已經給定了，但是產品、開發、測試對統一需求點理解上可能存在差異，那麼在實現和測試上就會出現不同的結果，這一部分的目的主要有如下幾點：

1.     明確測試要點，統一對需求的理解，確保測試的完備性

2.     評審測試用例設計是否充分覆蓋功能需求；

3.     確定測試時間節點。

這個階段參與人員主要是：產品、開發、測試，在大型公司專案負責人也會參與用例評審。

         用例設計並評審完畢，這時候就要選擇不同的測試方法來進行測試實現。大體上一個專案包括的測試型別有如下幾種：手工測試、黑盒測試/功能測試、白盒測試、自動化測試、相容性測試、介面測試、效能測試、滲透測試等。

l  手工測試

主要做一些邏輯比較複雜、使用頻率比較少的功能！不過目前大部分公司的app測試，使用手工測試佔比在70%左右。

l  自動化測試

主要做一些重複性、使用頻次比較高的場合。自動化實現可以根據自己所屬技能選著適合語言和工具來實現自動化！目前市場用的比較多的：RF、UFT(QTP)、winrunner、selenium、appium、uiautomator、XCUITEST等。感興趣的可以自己去了解！設計自動化指令碼之前，需要梳理相關業務、設計好測試執行流程、測試資料準備

l  介面測試

介面測試就是校驗這個介面返回引數和狀態是否正確，介面測試前期需要做如下準備工作：

a.開發人員提供服務介面（介面路徑、標頭檔案、請求資料格式等）;

b. 給出測試資料。以登入為例：需要各種組合的使用者名稱和密碼;

c.根據前兩部可以選著postman、RESTClient、Fiddler、Charles任意一款工具模擬請求。當請求成功傳送並返回時！

d.根據模擬的的設計請求格式，選則相應的測試工具。目前主流的介面測試主要有：Jmeter、Locust、以及自己編寫的一些的指令碼。對於剛入門的個人推薦學習Jmeter，Jmeter既可以做介面測試，還可以基於介面做併發測試、壓測、負載測試，不過效能和穩定性沒有loadrunner好。

寫指令碼的專案目錄一般包括：庫檔案lib、測試資料檔案data、測試用例檔案、測試報告、日誌檔案和主程式。

l  相容性測試

由於現在裝置多樣性、瀏覽器多樣性、作業系統多樣性，在產品上線前，通常在不同的裝置(不同的解析度)、瀏覽器、作業系統上操作使用產品，檢視應用程式是否正常顯示、應用程式功能能否正常響應！相容性測試目前主要是指移動裝置相容性、作業系統的相容性、瀏覽器的相容性。

相容性測試方法就是確定一個測試基準，以測試基準作為預期結果，在其他裝置、瀏覽器、作業系統上進行相同的操作，與測試基準一致，說明應用程式在相容性方面是滿足使用者或產品需求的。

l  效能測試

效能測試是基於功能、介面完整的情況下，對服務端進行壓力測試、負載測試、疲勞測試、併發測試，來發現效能瓶頸。

效能測試主要包括：

1.        需求提取，該部分包括：響應時間、併發使用者數、TPS、吞吐量、CPU利用率、記憶體使用率、線上併發使用者數等。

2.        需求策略制定：設計效能測試場景！這裡以登入為例：

併發使用者數：150、200、250和300；

使用者間隔時間：1、2、2和2；

持續執行時間：20、30、30和30。

3.        準備測試資料

這裡測試資料和自動化測試所使用的測試資料不一樣，這裡的測試資料都是有效複合要求的資料，請求使用該資料能響應成功的資料。

4.        選著測試工具

測試工具個人推薦loadrunner破解版，主要原因是：a.我在使用jmeter的進行長時間壓測時多次堆疊溢位，沒有loadrunner穩定；b. 其次loadrunner生成的報告也比較規範可選擇性比較多。如果對於要求不是很規範的可以選著jmeter，jmeter併發使用者數與壓測的客戶端配置有很大關係，不過適合入門，對於你們的話，公司不要求我推薦你們用這個，能滿足基本的效能測試和介面測試。loadrunner內部程式設計指令碼是使用C語言，入門比較高。

5.        選著合適的效能計數器、以及相關的效能分析指標

注意這裡的效能計數器是設定在服務端的不是在客戶端，如果沒有服務端許可權，這是需要記錄下壓測時間節點，給服務端溝通，要出這段時間的伺服器的效能指標。

效能分析指標：響應時間、併發使用者數、TPS、吞吐量、線上併發使用者數

效能計數器連結：http://blog.csdn.net/henni_719/article/details/52024562

6.        進行壓力測試，獲取測試測試測試資料或報告

7.        編寫效能測試報告

l  滲透測試

隨著技術的發展，移動支付的發展，安全測試逐漸受到重視。安全測試需要知識面非常廣，我個人水平有限，在此不做誤人子弟的事！不過目前主流的滲透測試平臺主要有：BT5、Kali，這兩個平臺匯聚安全測試使用最多的工具和命令，感興趣可以去網上查閱，或者私信我，我給出學文件！

測試執行包括:手動執行測試用例、執行自動化測試指令碼、介面測試指令碼、效能測試指令碼、相容性測試等。在這過程中如果發現bug，可以選著公司裡的bug管理系統記錄bug。bug管理系統目前有：bugzilla、mantis、bugtags等。如果沒有使用過這些工具，可以使用doc或者excel自己建立一個bug模組。bug的核心屬性包括： bugId、bug名稱、bug描述、嚴重等級、優先順序、所屬功能模組、版本號、開發人員、重現步驟、預期結果、實際結果。

缺陷生命週期流程圖：

下文給出一個缺陷報告模板：

         迴歸測試根據時間安排，選著合適的迴歸策略，如果時間充分，那就執行所有的測試用例，如果時間不充足，選著執行核心的測試用例以及bug修復的測試用例。

驗收測試，需要產品或者使用者根據需求說明書來檢查產品功能實現、頁面展示、效能是否與需求說明書要求的一致，如果一致，這說明產品符合需求通過驗收。

測試報告

測試結束後，需要給出各個階段的測試產物。如測試需求文件、測試用例、自動化指令碼、效能測試指令碼、效能測試報告、自動化執行報告、介面指令碼及報告等。

總結

         上述給出軟體測試的流程，以及每個流程需要做什麼？通過該文章需要關注的重點是：測試流程、測試用例的編寫、bug的編寫和管理這三個核心。至於其中所涉及的測試型別只是在此簡單提及，文中所提及的工具和技術可以自己網上查詢，如果感興趣可以，可以加入QQ群：320542475，一起討論測試的那些事，共同學習共同進步，一起在測試路上同舟共濟！