功能測試是測試工程師的基礎功，很多人功能測試還做不好，就想去做性能測試、自動化測試。
很多人對功能測試的理解就是點點點，如何自己不用心去悟，去研究，那麼你的職業生涯也就停留在點點點上了。
一、功能測試所需要掌握的技能
1.1 熟練使用SQL
1、常用的 sql 語句一定會寫。比如說增刪改查之類。
2、瞭解數據庫的事務、會編寫存儲過程、熟練常用的系統函數。
3、瞭解並可以進行數據庫的備份、遷移、還原、鏡像等操作
4、對 sql 語句進行調優，並對可以對運行的語句監控查看性能
5、瞭解數據庫集羣等操作。
1.2 Linux
Linux是測試人員的基礎功，不需要掌握太難或者很不常見的Linux命令，正常能做到查看日誌，定位問題就可以了。
1、基本命令
常用的Linux基本命令，面試經常會問的，或者給出一種場景，問你用什麼命令。
2、查看日誌
初級測試人員在工作時經常遇到，發現bug，開發不承認或者不願意解決的情況，測試人員怎麼擺脫這樣的問題呢？
那就是根據發現的bug根據日誌級別，來查看日誌，定位問題。
那這裏首先要說一下日誌級別了。
首先記住這一點：日誌級別越高，輸出的信息越少 。
具體的日誌級別分爲四級：
info : 代碼 info 信息，不包括sql語句等一些debug信息
warning warning : 代碼警告信息
error : 程序本身報錯信息 java.lang.outindexERROR.....
critical ：幾乎用不到
一般不符合需求的bug在 debug中，程序本身報錯的bug在 error中。
1.3 寫好測試用例
測試用例必須包含的內容：
用例編號、用例名稱、測試背景、前置條件、優先級、重要級、測試數據、測試步驟、預期結果、實際結果、備註。
1、測試用例的編寫流程
需求分析->提取測試點->測試用例編寫->測試用例評審
2、編寫測試用例的思路
（1）根據產品的RPD，提取測試點。
（2）根據數據流的走向。
（3）根據的架構部署。
（4）編寫測試用例的常用方法：等價類劃分法、邊界值分析法、流程圖法等。
（6）常用測試工具有：Postman、 Charles、 Fiddler 、Jemter、Loadrunner等。
3、編寫測試用例注意事項
（1）根據項目的實際情況設計測試用例表格
（2）用例格式不要生搬硬套
（3）根據具體情況編寫
（4）學會質疑需求，不要完全按照需求來寫測試用例，要從客戶和產品的角度來理解需求，看到需求之外的功能和體驗
1.4 http與https協議
1、Http協議原理
2、http和http協議的區別
3、TCP和UDP的區別
4、session和token的區別
5、公鑰和私鑰的理解
6、get和post的區別
7、從輸入URL到頁面加載發生了什麼
8、什麼叫代理，正向代理和反向代理？
1.5瞭解業務
做功能測試，一定要了解業務，甚至理解業務。只有把業務吃透，才能把功能測試做好，並且有一定的提高。
業務熟悉後，會知道很多常識，知道下面的常識之後，你就可以嘗試進階，學習做自動化測試、接口測試、性能測試
1、什麼時候介入自動化 => 當你係統趨於穩定的時候
2、什麼時候介入接口測試 => 當接口開發完畢的時候
3、什麼時候介入性能測試 => 當出現促銷的時候，或者搶購的時候(618大促，過年搶火車票，搶優惠券)
1.6 bug管理
做功能測試，還有個很重要的工作就是bug管理，一個優秀的的測試人員，線上bug非常多，多於和你一起工作的其他同事。
1、 bug定義
（1）不符合需求的
（2）程序本身報錯
（3）不符合用戶的使用習慣
2、bug生命週期當我們測試人員提交一個bug的時候，自始bug就有它的生命週期，從開始到
結束，生命週期如下
3、測試報告
同時爲軟件驗收和交付打下基礎測試報告和測試計劃一樣，一般由測試leader編寫，測試人員需要了解
一下測試報告中都有哪些內容
1.7 典型bug
1、抓包作用: 測試一個app搜索功能，抓包，抓到一個搜索接口，突然發現抓到了兩個請求接口 -> 當訪問量上來了，服務的壓力上升兩倍
2、數據流走向 : 測試時候發現頁面上數據只有一條，但是數據庫裏面多了一條 -> 1、數據量變大，查詢變慢 2、髒數據太多，瞬間爆滿，程序崩潰了
3、弱網測試：app項目一定要有弱網絡測試（模擬2g、3g、4g，wifi網絡狀態以及丟包情況）；網絡切換測試（網絡斷開後重連、3g切換到4g/wifi 等）
1.錄入的下拉選擇項進行了過濾
根據表單的檢索關鍵字作爲過濾條件進行下拉列表過濾顯示
2.錄入的下拉選擇項或單選項與別的錄入項之間的聯動過濾關係正確
檢查多重關聯的下拉列表字段的數據有效性
3.必填項字段控制與數據庫必填項控制一致
4.正確輸入所有相關內容，包括必填項，點添加按鈕，記錄成功添加
5.成功新增的記錄在數據庫顯示的值與錄入的一致
6.必填項內容不填、其它項正確輸入，點添加按鈕，系統有相應提示
7.內容項中輸入空格，點添加按鈕，記錄不能添加成功
8.內容中不輸入，保存後顯示null
9.內容項中輸入系統中不允許出現的字符、點添加按鈕，系統有相應提示
10.僅填寫必填項，點添加按鈕，記錄能否添加成功
11.添加記錄失敗時，有相應的提示，原填寫內容保存
12.添加記錄失敗時，原填寫內容保存
13.重複提交相同記錄，系統有相應提示（同一客戶端提交兩次相同的記錄，不同客戶端提交一次相同的記錄）
14.某些輸入項不允許重複（注意大小寫和前後空格問題），若添加重複的輸入項，系統應有相應提示
15.提交時自動處理了內容首尾兩端的空格
16.提交成功的記錄後，可以正常顯示此記錄
17.提交成功的記錄後，可以正常調用此記錄
18.新增數據提交後，會清空緩存，如果沒有清除再次提交有提示
19.提交成功後刷新頁面，系統不會拋異常信息
20.是否有批量新增功能，如果存在，則要考慮對批量新增進行性能和壓力測試
21.是否有批量新增功能，如果存在，則要考慮在批量新增過程中，如果出現系統異常，新增操作是否進行了數據回滾
22.新增按鈕是否對應了一組事務處理（即點擊新增的同時，在後臺數據庫進行了多項工作，而非一條添加），要在新增成功後，檢查是否所有的事務操作都進行了正確完整的處理
23.新增按鈕是否對應了一組事務處理，要在新增過程中，人爲構造新增異常，檢查是否進行了事務回滾操作
24.新增操作是否支持回車鍵或TAB鍵的輸入切換操作
25.新增操作中是否具備撤銷功能
26.新增操作異常後，不會影響其他的功能操作
27.新增操作的同時，是否在後臺創建了對應的文件夾或文件，如果存在，要在新增結束後，在系統後臺進行文件夾或文件的確認和檢查
28.新增操作的同時，是否在後臺網絡中進行了相關數據或文件的傳輸，如果存在，要在新增過程中，檢查網絡數據傳輸的完整性和正確性以及安全性
29.新增操作後，是否會自動更新系統其他頁面或數據庫表的信息（例如網站新註冊一個用戶，該網站首頁上對應的註冊用戶人數進行更新），如果存在，要明確更新的時間點，在時間點到來時，檢查是否進行了更新
30.新增操作後，是否會自動更新系統其他頁面中對應的下拉框數據（例如新增一個狀態，在前臺下拉框中會增加一個新的狀態內容），如果存在，要在相關頁面上逐一檢查下拉框內容是否進行了更新
31.如果是B/S或C/S系統，在服務器端增加了一個信息，是否會影響到前臺系統界面的數據，如果存在，那麼在後臺服務器端進行新增操作後，就要在前臺客戶端去查看相關的信息是否進行了更新
32.如果該功能存在假刪除，要考慮在新增記錄時，關於重複的校驗，是否包括假刪除數據
例如員工管理功能對應的刪除操作是假刪除，並且新增員工要求，員工姓名不能重複。
加入張三離職後，把張三假刪除，在界面上看不到張三的信息，此時再次新增員工信息，是否能再次錄入一個員工姓名爲張三的？
33.新增界面中是否有右鍵快捷菜單，支持拷貝和粘貼等常見編輯功能
34.能否支持回車或TAB鍵的切換
1.1 瞭解需求
這一點，不但是功能測試，是所有測試都需要的第1步。通過需求文檔，與產品經理的溝通，與開發的溝通，用戶的使用習慣等各方法，瞭解APP的需求。
1.2 編寫測試用例
當然之前可能是測試計劃，測試方案的確認等。這是測試經理的主要工作。測試用例的編寫，主要是建立在第1步的瞭解需求之後。測試用例主要包含：1用例標題；2用例數據；3測試步驟；4期望結果；5實際結果。當然還有其它的，包含測試人員，測試環境，測試工具等。
這裏，APP測試的內容，一般包含：
1.2.1 APP的下載，安裝，卸載。
能否正常下載
安裝是否正常（有網，無網是否都正常），路徑是否正確，文件或者佔用手機內存大小等（如果需要）
是否沒有得到用戶允許就自啓動
特殊情況下，比如內容不足情況下的安裝。不要導致系統死機，重啓，斷電等嚴重問題。要提示用戶內存不足，然後取消安裝。重新安裝沒有問題。
卸載是否正常，是否將全部必要文件刪除（如果需求需要，有的APP是要保留部分文件的，尤其是用戶使用產生的文件）
直接刪除文件導致不能使用，是否有提示
1.2.2 權限的驗證
獲取的權限是否得到用戶的許可，尤其是部分重要的權限，如使用網絡，使用攝像頭，讀取通訊錄，短信，通訊記錄等。
使用發送短信，打電話前要提示用戶。
沒有網絡時，要提示用戶。這裏包含各頁面時的提示，尤其是註冊登錄時，也可以放在功能模塊的測試中。
如果得到短信權限，可能得到短信關鍵內容。例如接收短信驗證碼。
上面這些，其實也屬於安全測試，但因爲較簡單，也可以當作功能測試。 至於是否存在用戶數據泄漏，屬於更專業的安全測試。
1.2.3 UI界面的驗證
各界面是否需要需求，以需求文檔和用戶習慣爲準。
1.2.4 各功能模塊的驗證
一般的功能模塊包含：註冊，登錄，個人中心，各相應功能。。。
1.2.5 註冊登錄的通用的重要測試點：
沒有網絡時的提示
登錄後，直接進入個人中心，或者是首頁
密碼的驗證，密碼的保存（是否加密保存在手機中），密碼的長度，錯誤的提示，找回密碼，密碼最多錯誤次數的限制及後續處理邏輯（多久後或者怎麼操作後可以重新登錄）。
是否允許多設備的登陸，臺式機和手機的同時登錄，多臺手機的同時登錄
登錄後，系統是否正確處理（個人信息是否正確，用戶權限是否正確）
登錄超時的處理
一般現在沒有註銷功能，若有，註銷後是否能重新註冊，且信息是否處理正確（新用戶不受原用戶信息的影響）
1.2.6 運行APP的重要點有：
應用前後臺的切換，是否崩潰，是否能正常使用（時間短，正常使用；時間長了，相當於重新打開應用），是否能正常接收新數據
鎖屏解屏對應用的影響，是否能正常接收新數據。
有電話進來後，再使用APP，功能是否正常。
關閉APP後再打開APP，是否正常
對於有數據交換的頁面，每個頁面都要進行前後臺切換，鎖屏觸屏，電話接入等測試，因爲這種頁面最易出問題。
1.2.7 免登錄功能
關閉APP後，再重新打開，是否免登錄
切換登錄用戶，用戶信息是否更新
修改密碼後，是下次登錄或者開戶時校驗新密碼，還是本次登錄要馬上退出重新登錄？
1.2.8 數據更新
哪些頁面的數據是自動更新，哪些手動更新
前後臺切換時，數據是否更新
哪些數據是實時從服務端請求，哪些緩存到本地
1.2.9 離線瀏覽
是否支持離線瀏覽？
支持離線時，前後臺切換或者鎖屏觸屏後，是否都能瀏覽本地信息？
手動刷新時，是否有對連接網絡的提示？
1.2.10 APP更新
打開老版本時，是否有新版本的更新提示
是否強制升級
不刪除老版本情況下，直接更新，是否正常，更新後，是否能正常使用
1.2.11 相機使用
專門提到相機，是因爲相機使用頻繁。而照相質量，用戶也很在意。所以當APP調用相機時，功能是否正常，質量是否可靠，也要多次測試。
1.2.12 消息推送
用戶接受消息推送時，是否能正常接收各類消息？
不打開應用時，能否接收消息
打開應用時，能否接收消息
登錄與不登錄情況下，接收消息是否有區別（其實這些需求中都要明確，才能針對性展開測試）
精確推送，是否只推送給指定用戶
1.2.13 兼容性測試
兼容性測試，嚴格來說不是功能測試。但這裏功能測試，只是與性能測試，專業的安全測試區分後，籠統地稱其它測試全爲功能測試。
包括設備的兼容性測試，及網絡的兼容性測試。
設備包括，不同品牌，不同系統（miui等）的手機，不同版本的android， ios， 不同屏幕大小的手機。
網絡包括，WIFI,各種制式的3G, 各種制式的4G
對http和https分別適應，這點是以前沒考慮到的。在星巴克等場所，需要輸入用戶名和密碼才能上網，這樣的網絡通常是https。
1、單元測試的內容
(1) 模塊接口測試
* 在單元測試的開始，應對通過被測模塊的數據流進行測試。測試項目包括：
– 調用本模塊的輸入參數是否正確；
– 本模塊調用子模塊時輸入給子模塊的參數是否正確；
– 全局量的定義在各模塊中是否一致
* 在做內外存交換時要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩衝區容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結束文件處理時是否關閉了文件；
– 正文書寫/輸入錯誤，
– I/O錯誤是否檢查並做了處理。
(2) 局部數據結構測試
* 不正確或不一致的數據類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數據類型
* 全局數據對模塊的影響
(3) 路徑測試
* 選擇適當的測試用例，對模塊中重要的執行路徑進行測試。
* 應當設計測試用例查找由於錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
* 對基本執行路徑和循環進行測試可以發現大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠對錯誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等
(5) 邊界測試
* 注意數據流、控制流中剛好等於、大於或小於確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素
2、 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環境 (可能就是開發的環境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規格說明書列出的需求。
* 首先制定測試計劃，規定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預定的測試計劃和測試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便於使用；
– 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完後，所有的測試結果可以分爲兩類：
– 測試結果與預期的結果相符。這說明軟件的這部分功能或性能特徵與需求規格說明書相符合，從而這部分程序被接受。
– 測試結果與預期的結果不符。這說明軟件的這部分功能或性能特徵與需求規格說明不一致，因此要爲它提交一份問題報告