寫給五年前的本身（軟件測試工程師總結）（未更新完）

時間 2019-11-18

標籤寫給五年前本身軟件測試工程師總結更新简体版

原文原文鏈接

五年前，偶然機會進入測試行業，那個時候，實習什麼都不懂，特別羨慕有三五年測試經驗的人，想着，等本身也有五年經驗了，也要像博客園的大神同樣，給初入測試行業的同窗一些有用的建議和指導，現在，已經五年了，卻沒有成爲本身當初想成爲的那種大神，這篇博文，權當是完成本身整年前的一個心願，爲這五年作個小結。css

1，軟件測試方法分類html

小結：前端

根據開發階段劃分：單元測試、集成測試、系統測試、開發測試；
根據是否運行劃分：靜態測試、動態測試
根據是否查看源代碼劃分：黑盒測試、白盒測試
其餘還有迴歸測試、冒煙測試、隨機測試
其中黑盒測試包括功能測試和性能測試；
功能測試有：邏輯功能測試、界面測試、易用性測試、安裝測試、兼容測試；
性能測試有：通常性能測試、穩定性測試、壓力測試、負載測試 sql

        測試方法概念：

        1.1，按是否查看程序內部結構分爲：

              1.1.1，黑盒測試（black-box testing）：只關心輸入和輸出的結果

              1.1.2，白盒測試（white-box testing）：去研究裏面的源代碼和程序結構
         1.2，按是否運行程序分爲：
            1.2.1，靜態測試（static testing）：是指不實際運行被測軟件，而只是靜態地檢查程序代碼、界面或文檔可能存在的錯誤的過程。
                       靜態測試包括：
                       對於代碼測試，主要是測試代碼是否符合相應的標準和規範。
                       對於界面測試，主要測試軟件的實際界面與需求中的說明是否相符。
                       對於文檔測試，主要測試用戶手冊和需求說明是否真正符合用戶的實際需求。
            1.2.2，動態測試（dynamic testing），是指實際運行被測程序，輸入相應的測試數據，檢查輸出結果和預期結果是否相符的過程
         1.3，按階段劃分：
             1.3.1，單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。
                       樁模塊（stud）是指模擬被測模塊所調用的模塊，驅動模塊（driver）是指模擬被測模塊的上級模塊，驅動模塊用來接收測試數據，啓動被測模塊並輸出結果。
             1.3.2，集成測試（integration testing），是單元測試的下一階段，是指將經過測試的單元模塊組裝成系統或子系統，再進行測試，重點測試不一樣模塊的接口部門。
                        集成測試就是用來檢查各個單元模塊結合到一塊兒可否協同配合，正常運行。
             1.3.3，系統測試（system testing），指的是將整個軟件系統看作一個總體進行測試，包括對功能、性能，以及軟件所運行的軟硬件環境進行測試。
                        系統測試的主要依據是《系統需求規格說明書》文檔。
             1.3.4，驗收測試（acceptance testing），指的是在系統測試的後期，以用戶測試爲主，或有測試人員等質量保障人員共同參與的測試，它也是軟件正式交給用戶使用的最後一道工序。
                        驗收測試又分爲a測試和beta測試，其中a測試指的是由用戶、 測試人員、開發人員等共同參與的內部測試，而beta測試指的是內測後的公測，即徹底交給最終用戶測試。
        1.4，黑盒測試分爲功能測試和性能測試：
              1.4.1，功能測試（function testing），是黑盒測試的一方面，它檢查實際軟件的功能是否符合用戶的需求。
                         包括邏輯功能測試（logic function testing）
                         界面測試（UI testing）UI=User Interface
                         易用性測試（usability testing）：是指從軟件使用的合理性和方便性等角度對軟件系統進行檢查，來發現軟件中不方便用戶使用的地方。
                         兼容性測試（compatibility testing）：包括硬件兼容性測試和軟件兼容性測試
              1.4.2，性能測試（performance testing）
                         軟件的性能主要有時間性能和空間性能兩種
                         時間性能：主要指軟件的一個具體事務的響應時間（respond time）。
                         空間性能：主要指軟件運行時所消耗的系統資源。
                         軟件性能測試分爲：
                         通常性能測試：指的是讓被測系統在正常的軟硬件環境下運行，不向其施加任何壓力的性能測試。
                         穩定性測試也叫可靠性測試（reliability testing）：是指連續運行被測系統檢查系統運行時的穩定程度。
                         負載測試（load testing）：是指讓被測系統在其能忍受的壓力的極限範圍以內連續運行，來測試系統的穩定性。
                         壓力測試（stress testing）：是指持續不斷的給被測系統增長壓力，直到將被測系統壓垮爲止，用來測試系統所能承受的最大壓力。(Validate the system or software can allowed the biggest stress.)
         1.5，其餘測試類型：
                 迴歸測試（regression testing）是指對軟件的新的版本測試時，重複執行上一個版本測試時的用例。(When a new build or release is deployed, repeat all the test cases which has executed in the last build or release.)
                 冒煙測試（smoke testing），是指在對一個新版本進行大規模的測試以前，先驗證一下軟件的基本功能是否實現，是否具有可測性。(validate the major function is deployed or not in software of system when a new build or release is implement.)
                 隨機測試（random testing），是指測試中全部的輸入數據都是隨機生成的，其目的是模擬用戶的真實操做，並發現一些邊緣性的錯誤。(means or all the test data is random, to validate the some edge bugs.)

測試方法概念

2，幾種常見測試方法詳解：數據庫

2.1，文檔測試瀏覽器

文檔：安裝手冊，操做手冊，維護手冊（文檔由產品和UI提供）
測試內容：
2.1.1，文檔是否齊全，是否包含產品使用所需的信息和全部功能模塊；
2.1.2，文檔描述是否正確，是否沒有歧義和錯誤的表達；
2.1.3，文檔是否容易理解，是否經過使用適當的術語和圖形等方式來表達；
2.1.4，文檔對主要功能和關鍵操做是否提供應用實例；
2.1.5，文檔是否有詳細的目錄表，索引表，連接；
2.1.6，文檔描述與軟件當前版本符合（使用方法，使用約束，FAQ等）
2.2，易用性測試安全

小白體驗+測試經驗習慣+業務知識服務器

測試內容：
2.2.1，軟件是否沒有徹底不符合IT行業習慣的操做，完成一次業務過多的操做步驟和彈出窗口，業務邏輯不符合思惟邏輯；
2.2.2，軟件中是否不存在提示信息過於複雜或者簡單；
2.2.3，軟件中的各模塊的界面風格是否一致；
2.2.4，軟件的用戶界面是否友好；
2.2.5，軟件中的查詢結果的輸出方式是否比較直觀，合理cookie

2.3，安全測試網絡

軟件安全性測試包括程序、網絡、數據庫安全性測試。根據系統安全指標不一樣測試策略也不一樣。

　　     2.3.1，用戶程序安全的測試要考慮問題包括：

　　　　　① 明確區分系統中不一樣用戶權限;

　　　　　② 系統中會不會出現用戶衝突;

　　　　　③ 系統會不會因用戶的權限的改變形成混亂;

　　　　　④ 用戶登錄密碼是不是可見、可複製;

　　　　　⑤ 是否能夠經過絕對途徑登錄系統(拷貝用戶登錄後的連接直接進入系統);

　　　　　⑥ 用戶推出系統後是否刪除了全部鑑權標記，是否可使用後退鍵而不經過輸入口令進入系統。

　　　2.3.2，系統網絡安全的測試要考慮問題包括：

　　　　　① 測試採起的防禦措施是否正確裝配好，有關係統的補丁是否打上;

　　　　　② 模擬非受權攻擊，看防禦系統是否堅固;

　　　　　③ 採用成熟的網絡漏洞檢查工具檢查系統相關漏洞;

　　　　　④ 採用各類木馬檢查工具檢查系統木馬狀況;

　　　　　⑤ 採用各類防外掛工具檢查系統各組程序的客外掛漏洞。

　　　2.3.3，數據庫安全考慮問題：

　　　　　① 系統數據是否機密(好比對銀行系統，這一點就特別重要，通常的網站就沒有過高要求);

　　　　　② 系統數據的完整性;

　　　　　③ 系統數據可管理性;

　　　　　④ 系統數據的獨立性;

　　　　　⑤ 系統數據可備份和恢復能力(數據備份是否完整，能否恢復，恢復是否能夠完整)。

程序，網絡，數據庫安全性概念

2.3.1，常見的安全測試內容

權限控制

SQL注入

URL安全測試

XSS（跨站腳本攻擊）

CSRF（跨站請求僞造）

URL跳轉漏洞

2.3.2，權限控制

權限控制相對來講比較簡單，功能測試的過程當中也接觸過很多，主要就是考慮如下方面：

1.用戶權限：咱們假設存在兩個用戶A,B；其中A的權限級別很高，B的權限級別則很低：

只有A能進行的操做，B能不能進行操做；

只有A能看到的頁面，B能不能看到；

2.頁面權限：

必須登陸才能看到的頁面，不登陸直接訪問可否看到？

必須A-B-C的頁面，可否直接A-C？

一般來講單純的權限控制頁面測試不復雜，可是由於權限控制和後續的URL跳轉、Session等方面結合的比較緊密，因此單獨提出來。

2.3.3，SQL注入

1，SQL注入原理

以Sql Sever爲例，C#提供了兩種操做數據庫的方法，以實現Sql Sever的查詢功能爲例(Mysql只須要將Sql對象替換爲MySql對象便可)：

A，直接使用傳入的Sql進行數據庫操做：

public static DataSet QuerySql(string sSql)
        {
            DataSet ds = new DataSet();
            try
            {
                Open();
                SqlDataAdapter mDataAdpter = new SqlDataAdapter(sSql, conn);
                mDataAdpter.Fill(ds);
            }
            catch (SqlException ex)
            {
                throw new Exception(ex.Message);
                DataBaseException = ex.Message;
            }
            finally
            {
                conn.Close();
            }
            return ds;
        }

View Code

B，使用SqlParameter對象，對參數進行格式化，分離控制語句與執行語句：

public static DataSet QuerySql(string sSql, SqlParameter[] Params)
        {
            DataSet ds = new DataSet();
            SqlCommand comm = new SqlCommand();
            try
            {
                Open();
                comm.Connection = conn;
                comm.CommandType = CommandType.Text;
                comm.CommandText = sSql;
                comm.Parameters.Clear();

                foreach (SqlParameter p in Params)
                {
                    comm.Parameters.Add(p);
                }
                SqlDataAdapter mAdapter = new SqlDataAdapter(comm);
                mAdapter.Fill(ds);
            }

            catch (SqlException ex)
            {
                DataBaseException = ex.Message;
                throw new Exception(ex.Message);
            }
            return ds;
        }

View Code

接下來咱們來看如下場景：

用戶登陸，帳號密碼存在User表中，該表字段爲ID，Name，PassWord三個字段，驗證用戶登陸時直接傳用戶輸入的用戶名與密碼給數據庫，若是咱們直接採用方式一，那麼代碼實現以下：

//獲取傳入的用戶UserName與PassWord

string sql = "SELECT * FROM User WHERE UserName = '"+UserName+"' AND PassWord = '"+PassWord+"'";

//其餘處理代碼

假設咱們的帳戶名稱是admin，密碼是123，那麼構造出的sql就是：

SELECT * FROM User WHERE UserName = ’admin’ AND PassWord = ’123’

執行結果看起來沒有問題，可是若是這個時候咱們輸入的密碼是 ‘’or 1=1時，那麼實際執行的SQL就變成了：

SELECT * FROM User WHERE UserName = ’admin’ AND PassWord = '''' OR 1=1

（這裏輸入兩個分號是由於構造sql的時候就已是分號了，在sql sever中查詢的字符串中帶有分號則是須要再加一個分號進行轉義）

因爲1=1恆等式的存在，這條sql會直接查詢出整個表的數據；就算沒有相關權限，服務器也會認爲是一個有效用戶進行處理。

若是咱們再進一步，輸入密碼‘’or 1=1;drop table User

那麼結果會是什麼樣呢？User這個表會直接被刪除掉！這個時候網站就會由於User表不存在而報錯，產生嚴重的異常。

綜上所述，SQL注入的原理就是經過構造符合SQL語法的參數傳入程序，經過執行SQL語句進而執行攻擊的操做；緣由是程序徹底信任了傳入的數據，導致非法數據可以入侵系統。

2，解決方案：

在瞭解了SQL注入原理後，咱們能夠作出針對性的一些措施，如：

儘可能避免使用動態構造SQL，而是使用SqlParameter對參數進行格式化或使用框架提供的一些功能，分離控制語句與執行語句；

對傳入的字符進行轉義處理，’和%、_、[]等通配符進行轉義處理，保證執行SQL的時候這些字符是正確在字符串內進行處理的；

在前端表單或控件中增長驗證，保證傳入後臺的數據是合法的；

數據庫權限控制，只給對應功能須要的權限，好比登陸頁面只能進行查詢，不賦予其執drop、update、delete、truncate等操做的權限。

2.3.4，URL安全測試：

1，MVC下的URL構成：

1)，使用Get方式的URL構造方式：

~/控制器名/調用的方法?入參1=參數1&……&入參n=參數n，例如：

http://localhost:10344/AbnormalPunch/ApplySubmit?ID=13244&EmployeeID=1D2DE5AD8BC74E2A9CA70DE3567472EB

能夠看到，在不通過處理的狀況下，Get方式生成的URL能夠看到數據和參數

2)，使用Post方式的URL構造方式：、

~/控制器名/調用的方法，入參則放在報文實體主體部分中，例如：http://localhost:12688/Order/OrderList

經過接口測試手段能夠獲取到訪問的入參：

{

"OrderType": "0",

"QueryType": "1"

}

URL安全測試主要是基於URL的構成方式進行的測試，不少時候會涉及到和其餘方向的交叉；瞭解各個原理後，就能比較全面的考慮問題了。

2，參數檢查：主要就是檢查URL或者主體報文中的參數

使用Get方式時，URL中顯示的參數正確；敏感參數如用戶名、密碼不該被顯示；

使用Post方式時，敏感參數應該進行加密處理

極端可是比較安全的處理方式是URL只顯示網站地址，

3，根據URL的構成方式直接篡改URL：

咱們回過頭去看這個URL：

http://localhost:10344/AbnormalPunch/ApplySubmit?ID=13244&EmployeeID=1D2DE5AD8BC74E2A9CA70DE3567472EB

這個URL的內容是的查詢某個用戶提交的某個申請的明細，URL的傳入的ID爲要查詢的申請，EmployeeID是從Session中取的當前登陸用戶的ID。

那麼咱們能夠基於如下場景篡改URL進行驗證：

用戶未登陸時，直接輸入該網址進行訪問（涉及到登陸驗證）；

其餘用戶登陸時，輸入這個網址（涉及到權限控制）

構造ID和EmployeeID爲SQL注入的參數，而後訪問（涉及到SQL注入）

以及稍後會涉及到的XSS、Session、Cookie等場景。

2.3.5，XSS

跨站腳本攻擊（Cross Site Scripting），爲了和層疊樣式表css區分，簡寫爲XSS。

1，原理

攻擊者在網頁中嵌入客戶端腳本(例如JavaScript), 當用戶瀏覽此網頁時，腳本就會在用戶的瀏覽器上執行，從而達到攻擊者的目的。

例：

              存在一個文本控件，其中value1from來自用戶的輸入：

                <input type="text" name="address1" value="value1from">

直接輸入 "/><script>alert(document.cookie)</script><!-，那麼實際執行的語句：

               <input type="text" name="address1" value=""/><script>alert(document.cookie)</script><!- ">

也能夠將內容放到URL中進行訪問：

http://localhost:10344/AbnormalPunch/ApplySubmit?ID=<script>alert(document.cookie)</script>

咱們能夠看到，輸入的內容直接改變了程序的執行代碼，致使程序執行結果爲攻擊者想要的。

2，類型：

反射型XSS：須要欺騙用戶進行操做才能觸發XSS代碼，主要威脅個體用戶

持久性XSS：代碼儲存在服務器中，用戶訪問時便可直接觸發XSS代碼，威脅大量用戶

3，解決思路：對數據進行html編碼處理，保證用戶輸入的數據不會改變程序代碼

將重要的cookie標記爲http only,這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了.

只容許用戶輸入咱們指望的數據。例如：　年齡的textbox中，只容許用戶輸入數字。而數字以外的字符都過濾掉。

過濾或移除特殊的Html標籤，例如: <script>, <iframe> , < for <, > for >, &quot for

過濾JavaScript 事件的標籤。

4，XSS漏洞的測試：

A，查看代碼，驗證變量是否通過html編碼處理

B，準備測試腳本：

"/><script>alert(document.cookie)</script><!--

"onclick="alert(document.cookie)

遍歷TextBox或者其餘文本控件，輸入這些測試腳本，若是瀏覽器彈出窗口且窗口內容爲cookie，證實存在XSS漏洞。

C，使用掃描工具如appscan

D，自行設計自動化測試腳本，用HttpWebRequest類，把包含xss 測試腳本發送給Web服務器，而後查看HttpWebResponse中，咱們的XSS測試腳本是否已經注入進去了。

5，其餘：

目前主流瀏覽器如Chrome、FireFox、IE8以上版本等都加入了安全機制用來過濾XSS；

ASP.NET中有防範XSS的機制，對提交的表單會自動檢查是否存在XSS，當用戶試圖輸入XSS代碼的時候，ASP.NET會拋出一個錯誤，暫時不清楚其餘語言是否

有這種機制。

2.3.6，CSRF

跨站請求僞造（Cross-Site Request Forgery），也被稱爲「One Click Attack」或者Session Riding，簡寫爲CSRF或XSRF。。儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，而且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。

1，CSRF的原理：CSRF能夠理解爲攻擊者盜用了你的身份，以你的名義發送惡意請求，具體步驟以下：

1)，用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登陸網站A；

2)，在用戶信息經過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登陸網站A成功，能夠正常發送請求到網站A；

3)，用戶未退出網站A以前，在同一瀏覽器中，打開一個TAB頁訪問網站B；

4)，網站B接收到用戶請求後，返回一些攻擊性代碼，併發出一個請求要求訪問第三方站點A；

5)，瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的狀況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求實際上是由B發起的，因此會根據用戶C的Cookie信息以C的權限處理該請求，致使來自網站B的惡意代碼被執行。

所以，對於一個用戶來講，完成給CSRF攻擊必需要兩個步驟：

A，登陸受信任網站A，並在本地生成Cookie。

B，在不登出A的狀況下，訪問危險網站B。

2，解決思路：

A，驗證 HTTP Referer 字段：

在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在一般狀況下，訪問一個安全受限頁面的請求來自於同一個網站；所以只須要驗證Referer的域名，驗證合法後再進行下一步操做。

然而，Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，可是每一個瀏覽器對Referer的具體實現可能有差異，並不能保證瀏覽器自身沒有安全漏洞。對於某些瀏覽器，好比 IE6 或 FF2，目前已經有一些方法能夠篡改 Referer 值。

B，在請求地址中添加 token 並驗證：

要抵禦 CSRF，關鍵在於在請求中放入黑客所不能僞造的信息，而且該信息不存在於cookie 之中。能夠在 HTTP 請求中以參數的形式加入一個隨機產生的 token，並在服務器端創建一個攔截器來驗證這個 token，若是請求中沒有 token 或者 token 內容不正確，則認爲多是 CSRF 攻擊而拒絕該請求。

C，在 HTTP 頭中自定義屬性並驗證:

把它放到 HTTP 頭中自定義的屬性裏。經過 XMLHttpRequest 這個類，能夠一次性給全部該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，經過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔憂 token 會透過 Referer 泄露到其餘網站中去。

3，CSRF漏洞的測試：

A.，最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段後再從新提交，若是該提交還有效，那麼基本上能夠肯定存在CSRF漏洞。

B，使用相關工具進行測試：CSRFTester，CSRF Request Builder等；原理使用CSRFTester進行測試時，首先須要抓取咱們在瀏覽器中訪問過的全部連接以及全部的表單等信息，而後經過在CSRFTester中修改相應的表單等信息，從新提交，這至關於一次僞造客戶端請求。若是修改後的測試請求成功被網站服務器接受，則說明存在CSRF漏洞，固然此款工具也能夠被用來進行CSRF攻擊。

2.3.7，URL跳轉漏洞

1，實現原理：

服務端未對傳入的跳轉URL變量進行檢查和控制，可能致使可惡意構造任意一個惡意地址，誘導用戶跳轉到惡意網站。

通常來講，URL跳轉的測試方法爲修改參數中的合法URL爲非法URL，而後查看是否能正常跳轉或者響應包是否包含了任意的構造URL。

2，測試方法：

修改參數中的合法URL爲非法URL，而後查看是否能正常跳轉或者響應包是否包含了任意的構造URL

2.3.8，其餘安全角度的考量

1，安裝包測試：對C/S端的程序，安裝包主要考慮反編譯、簽名、完整性、權限等

2，數據庫：對於數據庫中的敏感字段，如用戶名、密碼等應該進行加密處理後再存儲；Cookie等敏感信息也要考慮設置過時時間等；

3，日誌、配置文件中儘可能不要包含敏感信息

4，帳戶安全：數據庫中的密碼加密存儲，傳輸的密碼加密，密碼屢次輸入錯誤後進行鎖定，多設備登陸的處理、註銷後的身份驗證等

5，結合實際版本須要的考量：好比一款電商APP，提交訂單接口時傳入了訂單信息和訂單總金額，支付接口根據提交訂單接口傳入的總金額進行支付；問題在於支付接口徹底信任了訂單金額沒有作驗證，那麼能夠直接調用訂單接口僞造金額從而以便宜的價格購物。