測試用例的編寫需要按照一定的思路進行，而不是想到哪寫到哪，一般測試機制成熟的公司都會有公司自己自定義的測試用例模板，以及一整套的測試流程關注點，當然我們自己在測試生涯中也應當積累一套自己的測試框架，所有功能性的測試都可以依據框架的思路來進行，達到事半功倍的效果。
功能測試框架可以包括：界面友好性測試、功能測試、鏈接測試、容錯測試、穩定性測試、常規性能測試、配置測試、算法測試等等。
1.1.1 界面友好性測試
-
風格、樣式、顏色是否協調
-
界面佈局是否整齊、協調（保證全部顯示出來的，儘量不要使用滾動條
-
界面操作、標題描述是否恰當（描述有歧義、注意是否有錯別字）
-
操作是否符合人們的常規習慣（有沒有把相似的功能的控件放在一起，方便操作）
-
提示界面是否符合規範（不應該顯示英文的cancel、ok，應該顯示中文的確定等）
-
界面中各個控件是否對齊
-
日期控件是否可編輯
-
日期控件的長度是否合理，以修改時可以把時間全部顯示出來爲準
-
查詢結果列表列寬是否合理、標籤描述是否合理
-
查詢結果列表太寬沒有橫向滾動提示
-
對於信息比較長的文本，文本框有沒有提供自動豎直滾動條
-
數據錄入控件是否方便
-
有沒有支持Tab鍵，鍵的順序要有條理，不亂跳
-
有沒有提供相關的熱鍵
-
控件的提示語描述是否正確
-
模塊調用是否統一，相同的模塊是否調用同一個界面
-
用滾動條移動頁面時，頁面的控件是否顯示正常
-
日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XXXX:XX:XX
-
頁面是否有多餘按鈕或標籤
-
窗口標題或圖標是否與菜單欄的統一
-
窗口的最大化、最小化是否能正確切換
-
對於正常的功能，用戶可以不必閱讀用戶手冊就能使用
-
執行風險操作時，有確認、刪除等提示嗎
-
操作順序是否合理
-
正確性檢查：檢查頁面上的form, button, table, header, footer,提示信息，還有其他文字拼寫，句子的語法等是否正確。
-
系統應該在用戶執行錯誤的操作之前提出警告，提示信息.
-
頁面分辨率檢查，在各種分辨率瀏覽系統檢查系統界面友好性。
-
合理性檢查：做delete, update, add, cancel, back等操作後，查看信息回到的頁面是否合理。
-
檢查本地化是否通過：英文版不應該有中文信息，英文翻譯準確，專業。
-
背景灰度凍結
1.1.2 功能測試
-
使用所有默認值進行測試
-
根據所有產品文檔、幫助文檔中描述的內容要進行遍歷測試
-
輸入判斷
-
所有界面出現是和否的邏輯，要測試
-
異常處理
-
敏感詞
-
根據需求文檔的流程圖遍歷所有流程圖路徑
-
根據程序內容，遍歷if elif else switch的邏輯點要遍歷
-
界面各種控件測試
如對於輸入框測試：
一、字符型輸入框：
-
字符型輸入框：英文全角、英文半角、數字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特別要注意單引號和&符號。禁止直接輸入特殊字符時，使用“粘貼、拷貝”功能嘗試輸入。
-
長度檢查：最小長度、最大長度、最小長度-1、最大長度+1、輸入超工字符比如把整個文章拷貝過去。
-
空格檢查：輸入的字符間有空格、字符前有空格、字符後有空格、字符前後有空格
-
多行文本框輸入：允許回車換行、保存後再顯示能夠保存輸入的格式、僅輸入回車換行，檢查能否正確保存（若能，檢查保存結果，若不能，查看是否有正常提示）、
-
安全性檢查：輸入特殊字符串
（null,NULL,javascript,)、doucment.write(“abc”)、hello）
二、數值型輸入框：
-
邊界值：最大值、最小值、最大值+1、最小值-1
-
位數：最小位數、最大位數、最小位數-1最大位數+1、輸入超長值、輸入整數
3.異常值、特殊字符：輸入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]:"<>?;’,./?;:’-=等可能導致系統錯誤的字符、禁止直接輸入特殊字符時，嘗試使用粘貼拷貝查看是否能正常提交、word中的特殊功能，通過剪貼板拷貝到輸入框，分頁符，分節符類似公式的上下標等、數值的特殊符號如∑，㏒，㏑，∏，+，-等、
輸入負整數、負小數、分數、輸入字母或漢字、小數（小數前0點捨去的情況，多個小數點的情況）、首位爲0的數字如01、02、科學計數法是否支持1.0E2、全角數字與半角數字、數字與字母混合、16進制，8進制數值、貨幣型輸入（允許小數點後面幾位）、
- 安全性檢查：不能直接輸入就copy
三、日期型輸入框：
- 合法性檢查：(輸入0日、1日、32日)、月輸入[1、3、5、7、8、10、12]、日輸入[31]、月輸入[4、6、9、11]、日輸入[30][31]、輸入非閏年，月輸入[2]，日期輸入[28、29]、輸入閏年，月輸入[2]、日期輸入[29、30]、月輸入[0、1、12、13]
考慮開始日期與結束日曆的比較，特別是在查詢的時候.
-
異常值、特殊字符：輸入空白或NULL、輸入~！@#￥%……&*（）{}[]等可能導致系統錯誤的字符
-
安全性檢查：不能直接輸入，就copy，是否數據檢驗出錯？
1.1.3 業務流程測試(主要功能測試)
業務流程，一般會涉及到多個模塊的數據，所以在對業務流程測試時，首先要保證單個模塊功能的正確性，其次就要對各個模塊間傳遞的數據進行測試，這往往是容易出現問題的地方，測試時一定要設計不同的數據進行測試。
如某一功能模塊具有最基本的增刪改查功能，則需要進行以下測試：
-
單項功能測試（增加、修改、查詢、刪除）
-
增加——>增加——>增加（連續增加測試）
-
增加——>刪除
-
增加——>刪除——>增加（新增加的內容與刪除內容一致）
-
增加——>修改——>刪除
-
修改——>修改——>修改（連續修改測試）
-
修改——>增加（新增加的內容與修改前內容一致）
-
修改——>刪除
-
修改——>刪除——>增加（新增加的內容與刪除內容一致）
-
刪除——>刪除——>刪除（連續刪除測試）
1.1.4 鏈接測試
主要是保證鏈接的可用性和正確性，它也是網站測試中比較重要的一個方面。
可以使用特定的工具如XENU來進行鏈接測試。
1.1.5 容錯測試
-
輸入系統不允許的數據作爲輸入
-
把某個相關模塊或者子系統停掉，驗證對當前系統的影響
-
配置文件刪除或者配置錯誤
-
數據庫注入錯誤數據
1.1.6 穩定性測試
-
系統不間斷運行（7*24），驗證是否內存泄露、系統其他資源是否存在泄露
-
如果很緊急上線，可以跑一晚上或者週末跑兩天。
一般壓力很大的情況下，數據庫連接數問題、內存泄露問題會曝露的比較快但是死鎖可能不能體現，所以要看系統重要性，如12306穩定性則最好7*24小時
1.1.7 常規性能測試
-
連接速度測試
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。 -
負載測試
負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量用戶對同一個頁面的請求？ -
壓力測試
負載測試應該安排在Web系統發佈以後，在實際的網絡環境中進行測試。因爲一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果纔是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統重新啓動時獲得存取權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等
1.1.8 易用性測試
-
系統界面的控件是否可以通過tab鍵遍歷，並且順序合理
-
主要功能的入口和操作是否易於理解
-
界面是否佈局合理，功能是否易於查找和使用
-
操作步驟
-
操作習慣
-
有足夠的提示信息，且信息文字描述準確
1.1.9 兼容性測試
兼容性測試不只是指界面在不同操作系統或瀏覽器下的兼容，有些功能方面的測試，也要考慮到兼容性，
包括操作系統兼容和應用軟件兼容，可能還包括硬件兼容
比如涉及到ajax、jquery、javascript等技術的，都要考慮到不同瀏覽器下的兼容性問題。
除了上面所說的這些測試以外，還有算法測試、配置測試、安全性測試等等，在工作中不斷總結和分析，形成自己的功能測試框架，當你把這份工作做起來以後，對於你自己對於測試團隊而言都是一份很有價值的事情，你的測試思路也會變得更全面。