一般功能測試指的都是黑盒測試。就是測試工程師基於需求文檔，對開發完的功能進行測試。也就是說，功能測試都是基於需求的黑盒測試。而需求主要歸爲兩大類：
- 顯式功能性需求:指的是需求中明確規定且用戶可以感知到的需求，比如“訪客用戶訪問管理員頁面時會跳轉到登錄頁”。
- 非功能性需求:指的是用戶無法直接體驗到的，非具體功能性的需求，但這種非功能性需求在做功能性測試的時候也會涉及到，因爲很多非功能性的需求會影響到功能的可用性與用戶體驗，比如性能測試。
顯式功能性需求
對於顯式功能性需求我們最長用到的方案主要有三種：
- 等價類劃分法
- 邊界值分析法
- 錯誤推斷法
等價類劃分
•在軟件測試中，窮舉法雖然是最安全最保險的一種方法但成本代價高，一般是不可取的。我們可以通過等價類劃分方法花費最小的代價來完成最高效的測試。
•等價類劃分是把程序輸入域劃分成若干子集，然後從子集中選取少數具有代表性的數據進行測試。在子集集合中，各個輸入數據對於揭露程序中的錯誤是等價的。
•等價類分爲有效等價類和無效等價類。
• 1.1有效等價類-----正常流
對於程序規格來說合理的、有意義的輸入數據的集合，檢驗程序是否實現了規格說明中的功能和性能。
• 1.2無效等價類-----異常流
不合理的、無意義的輸入數據集合，驗證程序處理意外數據的能力。至少應有一個，也可能多個。
劃分等價類的標準
•1)完備測試、避免冗餘;
•2)劃分等價類重要的是：集合的劃分，劃分爲互不相交的一組子集，而子集的並是整個集合;
•3)並是整個集合：完備性;
•4)子集互不相交：保證一種形式的無冗餘性;
•5)同一類中標識（選擇）一個測試用例，同一等價類中，往往處理相同，相同處理映射到相同的執行路徑
等價類劃分方法
掌握必須使同類數據的處理過程及處理結果完全一致的大原則，可參考以下劃分方法
• 1） 輸入條件規定了取值範圍或值的個數的情況下，可以確定一個有效等價類和兩個無效等價類，如合格成績取值範圍爲[60,100]，則範圍內取值爲有效等價類，範圍外<60和>100爲無效等價類
• 2） 輸入條件規定了輸入值的集合或“必須如何”的情況下，可以確定一個有效等價類和一個無效等價類，如：規定數據庫類型必須選擇oracle，則選擇oracle時爲有效等價類，否則爲無效等價類
• 3） 輸入條件是一個布爾量的情況下，可以確定一個有效等價類和一個無效等價類
• 4） 輸入條件規定必須遵守某種規則的情況下，可以確定一個有效等價類和若干個無效等價類（從不同角度違法規則），如：規定輸入必須爲非0正整數，則無效等價類可以分爲空、0、負整數、小數、字符等
• 5） 在規定了輸入數據的一組值（假定N個），並且程序要對每個輸入值分別處理的情況下，可以確立N個有效等價類和一個無效等價類。例：輸入條件說明 學歷可爲:專科、本科、碩士、博士四種之一，則分別取這四種這四個值作爲四個有效等價類，另外把四種學歷之外的任何學歷作爲無效等價類。
• 6） 在確知已劃分的等價類中各元素在程序處理鎮南關的方式不同的情況下，則應再將該等價類進一步的劃分爲更小的等價類
等價類表
•在確立了等價類後，可以建立等價類表，列出所有劃分出的等價類
| 輸入條件 | 有效等價類 | 無效等價類 |
|---|---|---|
| 合格成績取值範圍爲[60,100]之間的整數 | [60,100]之間的整數 | 大於100；小於60小數位，如96.3含有字母的字符串；含特殊字符的字符串 空 |
等價類劃分實例1
•設有一個檔案管理系統，要求用戶輸入以年月表示的日期。假設日期限定在1990年1月~2049年12月，並規定日期由6位數字字符組成，前4位表示年，後2位表示月。現用等價類劃分法設計測試用例，來測試程序的"日期檢查功能"。
等價類劃分實例1:結果
•1)劃分等價類並編號,下表等價類劃分的結果
| 輸入等價類 | 有效等價類 | 無效等價類 |
|---|---|---|
| 日期的類型及長度 | ①6位數字字符 | ②有非數字字符③少於6位數字字符④ 多於6位數字字符 |
| 年份範圍 | ⑤在1990~2049之間 | ⑥小於1990⑦大於2049 |
| 月份範圍 | ⑧在01~12之間 | ⑨等於00⑩大於12 |
2)設計測試用例，以便覆蓋所有的有效等價類在表中列出了3個有效等價類，編號分別爲①、⑤、⑧，設計的測試用例如下：
測試數據 期望結果 覆蓋的有效等價類
200211 輸入有效 ①、⑤、⑧
3)爲無效等價類設計測試用例，設計結果如下：
測試數據 期望結果 覆蓋的無效等價類
95June 無效輸入 ②
20036 無效輸入 ③
2001006 無效輸入 ④
198912 無效輸入 ⑥
200401 無效輸入 ⑦
200100 無效輸入 ⑨
200113 無效輸入 ⑩
使用等價類劃分法測試的實例（續）
•實例2 保險公司計算保費費率的程序
某保險公司的人壽保險的保費計算方式爲：
投保額×保險費率
其中，保險費率依點數不同而有別，10點及10點以上保險費率爲0.6%，10點以下保險費率爲0.1%；而點數又是由 投保人的年齡、性別、婚姻狀況和撫養人數來決定，具體規則如下：
計算保費費率的程序
（1）分析程序規格說明中給出和隱含的對輸入條件的要求，列出等價類表（包括有效等價類和無效等價類）。
•年齡：一位,兩位或三位非零整數，值的有效範圍爲1~130
•性別：一位英文字符，只能取值‘M’或’F’
•婚姻：字符，只能取值‘已婚’或‘未婚’
•撫養人數：空白或一位非零整數（1~9）
•點數 ：一位或兩位非零整數，值的範圍爲1~99
（2）根據（1）中的等價類表，設計能覆蓋所有等價類的 測試用例。
邊界值分析方法
•1.定義：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作爲對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。
以往的測試經驗表明，由於需求界定不準確、設計不嚴密、程序書寫手誤等等原因，對於這些數據範圍邊界的判斷是軟件極容易出錯的地方。大量的錯誤往往發生在輸入或輸出範圍的邊界上，因此針對各種邊界情況設計測試用例，可以檢查出更多的錯誤。
•2.怎樣用邊界值分析法設計測試用例？
1)邊界值分析不是從某等價類中隨便挑一個作爲代表，而是使這個等價類的每個邊界都要作爲測試條件。選取正好等於、剛剛大於或剛剛小於邊界的值作爲測試數據
2)邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。
3)首先確定邊界情況。通常輸入或輸出等價類的邊界就是應該着重測試的邊界情況，因此在等價類的邊界上以及兩側的情況設計測試用例。
•3.邊界值適用場景
-
輸入（輸出）條件規定了取值範圍
-
輸入（輸出）條件規定了值的個數
-
程序規格說明書中提到的輸入或輸出是一個有序的集合
-
程序中使用了一個內部數據結構
-
邊界值取值應當選取正好等於、剛剛大於最大邊界值和剛剛小於最小邊界值最爲測試
邊界值選擇測試用例原則
•1） 如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界值、以及剛超越這個範圍邊界的值作爲測試輸入數據。 例如，如果程序的規格說明中規定：“重量在10公斤至50公斤範圍內的郵件，其郵費計算公式爲……”。作爲測試用例，我們應取10及50，還應取10.01,49.99,9.99及50.01等。
•2） 如果輸入條件規定了值的個數，則選取最大個數、最小個數、比最大個數多一、比最小個數少一的數作爲測試數據。
•比如，一個輸入文件應包括1~255個記錄，則測試用例可取1和255，還應取0及256等。
•例如，某程序的規格說明要求計算出"每月保險金扣除額爲0至1165.25元"，其測試用例可取0.00及1165.24、還可取一0.01及1165．26等。
再如一程序屬於情報檢索系統，要求每次"最少顯示1條、最多顯示4條情報摘要"，這時我們應考慮的測試用例包括1和4，還應包括0和5等。
•5） 若輸入域是有序集合，則選取集合的第一個元素和最後一個元素作爲測試用例
•6） 如果程序使用了一個內部數據結構，則應當選擇內部數據結構上得邊界值作爲測試用例
•7） 分析規格說明，找出其他可能的邊界條件
錯誤推斷法
•錯誤推斷法一般基於以往的測試經驗和直覺，參照以往的軟件系統出現的錯誤，推測程序中可能存在的各種錯誤，列出程序中所有可能有的錯誤和容易發生錯誤的情況，有針對性的設計測試用例。
• 單元測試用例中列出許多在模塊中常見的錯誤、以前產品測試中曾經發現的錯誤等
• 例如, 輸入數據和輸出數據爲0的情況；輸入表格爲空格或輸入表格只有一行。 這些都是容易發生錯誤的情況。各種情況在產品說明中常常被忽視，也可能被程序員遺忘，但在實際使用中卻經常發生。測試人員要站在用戶的角度，考慮他們要輸入的信息，而不管這些信息看起來是合法的輸入還是非法的輸入。
因果圖法
•因果圖法產生的背景：
等價類劃分法和邊界值分析方法都是着重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關係。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮採用一種適合於描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）
因果圖法的簡介
•因果圖法是基於這樣的一種思想：一些程序的功能可以用判定表（或稱決策表）的形式來表示，並根據輸入條件的組合情況規定相應的操作。
•因果圖法的定義：是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程序輸入條件的各種組合情況。
•採用因果圖法設計測試用例的步驟：
（1）根據程序規格說明書描述，分析並確定因（輸入條件）和果（輸出結果或程序狀態的改變），畫出因果圖。
（2）將得到的因果圖轉換爲判定表。
（3）爲判定表中每一列所表示的情況設計一個測試用例
因果圖
•因果圖中用來表示4種因果關係的基本符號：
因果圖中的4種基本關係
在因果圖的基本符號中，圖中的左結點ci表示輸入狀態（或稱原因），右結點ei表示輸出狀態（或稱結果）。ci 與 ei 取值0或1，0表示某狀態不出現，1則表示某狀態出現。
Ø恆等：若 c1 是1，則 e1 也爲1，否則 e1 爲0。
Ø非：若 c1 是1，則 e1 爲0，否則e1爲1。
Ø或：若 c1 或 c2 或 c3 是1，則 e1 爲1，否則 e1 爲0。
Ø與：若 c1 和 c2 都是1，則 e1 爲1，否則 e1 爲0。
因果圖
•因果圖中的約束
在實際問題中輸入狀態相互之間、輸出狀態相互之間可能存在某些依賴關係，稱爲“約束”。對於輸入條件的約束有E、I、O、R四種約束，對於輸出條件的約束只有M約束。
ØE約束(異)：a和b中最多有一個可能爲1，即a和b不能同時 爲1。
ØI 約束(或)：a、b、c中至少有一個必須爲1，即 a、b、c不能同時爲0。
ØO約束(唯一)：a和b必須有一個且僅有一個爲1。
ØR約束(要求)：a是1時，b必須是1，即a爲1時，b不能爲0。
ØM約束(強制)：若結果a爲1，則結果b強制爲0。
因果圖
•因果圖中用來表示約束關係的約束符號：
。。。。。。
判定表
•因果圖法最終生成的是判定表。
•在所有的黑盒測試方法中，基於決策表（也稱判定表）的測試是最爲嚴格、最具有邏輯性的測試方法。
•決策表的概念：決策表是分析和表達多邏輯條件下執行不同操作的情況的工具。
•決策表的優點：能夠將複雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用決策表能夠設計出完整的測試用例集合。
•在一些數據處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。決策表很適合於處理這類問題。
“閱讀指南”判定表
決策表的組成
•決策表通常由以下4部分組成：
Ø條件樁—列出問題的所有條件
Ø條件項—針對條件樁給出的條件列出所有可能的取值
Ø動作樁—列出問題規定的可能採取的操作
Ø動作項—指出在條件項的各組取值情況下應採取的動作
將任何一個條件組合的特定取值及相應要執行的動作稱爲一條規則。在決策表中貫穿條件項和動作項的一列就是一條規則。
決策表的生成
•構造決策表的5個步驟：
（1） 確定規則的個數。
Ø有n個條件的決策表有2n個規則（每個條件取真、假值）。
（2） 列出所有的條件樁和動作樁。
（3） 填入條件項。
（4） 填入動作項，得到初始決策表。
（5） 簡化決策表，合併相似規則。
Ø若表中有兩條以上規則具有相同的動作，並且在條件項之間存在極爲相似的關係，便可以合併。
合併後的條件項用符號“-”表示，說明執行的動作與該條件的取值無關，稱爲無關條件
測試方法的選擇
•通常，在確定測試方法時，應遵循以下原則：
Ø根據程序的重要性和一旦發生故障將造成的損失來確定測試等級和測試重點。
Ø認真選擇測試策略，以便能儘可能少的使用測試用例，發現儘可能多的程序錯誤。
•通常在確定測試策略時，有以下5條參考原則：
（1）在任何情況下都必須採用邊界值分析法。這種方法設計出的測試用例發現程序錯誤的能力最強。
（2）必要時採用等價類劃分法補充測試用例。
（3）採用錯誤推斷法再追加測試用例。
（4）對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋 程度。如果沒有達到要求的覆蓋標準，則應當再補充更多的測試用例。
（5）如果程序的功能說明中含有輸入條件的組合情況，則應一開始就選用因果圖法。
非功能性需求
在測試工程師測試完顯示功能需求之後，還要考慮到系統的非功能性需求。這種需求可能在文檔中有明確提到，也可能並沒有明確的提出。但是我們的測試工程師在測試的時候卻必須要關注到。
2.1 兼容性測試
兼容性指的是開發的軟件是否在各種平臺都可以使用。比如我們開發一個網站，我們的用戶可能會用到各種不同的瀏覽器訪問我們的網站。這樣我們在測試的時候，就不能只考慮到某一種瀏覽器。我們需要考慮到多種瀏覽器的兼容性。
兼容性測試可能會涉及到：
- 不同廠商的瀏覽器及相同廠商不同版本的瀏覽器。
- 不同的設備終端及操作系統
- 不同的屏幕分辨率
- 不同的用戶軟件環境（比如是否禁用了cookie、是否可以連接外網等）
2.2 安全性測試
我們的測試人員還需要關注到開發軟件的安全性。這涉及到：
-
用戶隱私信息是否加密
-
需要權限的資源是否有沒有權限也可以被拿到的風險
-
會不會受到跨站腳本的攻擊
-
會不會受到sql注入攻擊等等
2.3 壓力測試
測試人員也需要考慮的軟件是否能夠承載其需求所需的壓力，例如：
-
軟件是否能在合理的時間內響應用戶行爲
-
軟件是否可能承載足夠的請求
-
軟件在處理大數據量時會不會產生資源鎖死等等
總結
用戶登錄界面測試用例設計：
• 1、用戶名、密碼正確登錄
• 2、默認頁面直接提交
• 3、用戶名、密碼錯誤的檢測
• 4、用戶名不存在的檢測
• 5、TAB鍵的檢測
• 6、Enter鍵的檢測
• 7、被刪除的用戶名是否能夠登錄
• 8、被禁止的用戶名是否能夠登錄
• 9、用戶重複登陸
• 10、用戶名大小寫的敏感檢測
• 11、用戶名、密碼對複製粘貼內容的敏感檢測