功能測試（一）
web功能測試點：javascript
1、輸入框
字符型輸入框：
（1）字符型輸入框：英文全角，英文半角，數字，空或者空格，特殊字符（共32個，特別要注意單引號，下劃線，雙引號，&），禁止直接輸入特殊字符時，使用「粘貼」、「拷貝」功能嘗試輸入。
（2）長度檢查：最小長度，最大長度，最小長度-1，最大長度+1，輸入超長字符。
（3）空格檢查：輸入的字符間有空格，字符後有空格，字符先後有空格。
（4）多行文本框輸入：容許回車換行，保存後再顯示可以保存輸入的格式，僅輸入回車換行，檢查可否正確保存（若能，檢查保存結果，若不能，查看是否有正常提示）。
（5）安全性檢查：輸入字符串或腳本函數
(null、NULL、Javascript、<script>、</script>、<title>、<html>、<td>）
(<script>alert('abc')</script>)、document('abc')、<b>hello</b>html
(https://blog.csdn.net/qq_27424375/article/details/89346020)
數值型輸入框
（1）邊界值：最大值，最小值，最大值+1，最小值-1
（2）位數：最小位數，最大位數，最小位數-1，輸入超長值，輸入整數
（3）異常值、特殊字符：輸入空白（NULL）、空格或特殊字符等可能致使系統錯誤的字符，禁止直接輸入特殊字符時，嘗試使用粘貼拷貝，查看是否能正常提交、word中的特殊功能，經過剪貼板拷貝到輸入框，分頁符，分節符相似公式的上下標等、數值的特殊符號如∑，㏒，㏑，∏，+，-等、輸入負整數、負小數、分數、輸入字母或漢字、小數（小數前0點捨去的狀況，多個小數點的狀況）、首位爲0的數字如0一、0二、科學計數法是否支持1.0E二、全角數字與半角數字、數字與字母混合、16進制，8進制數值、貨幣型輸入（容許小數點後面幾位）
（4）安全性檢查：不能直接輸入就copyjava
日期型輸入框：
（1）合法性檢查：(輸入0日、1日、32日)、月輸入一、三、五、七、八、十、十二、日輸入3一、月輸入四、六、九、十一、日輸入30、3一、輸入非閏年，月輸入2，日期輸入2八、2九、輸入閏年，月輸入二、日期輸入2九、30、月輸入0、一、十二、13
（2）異常值、特殊字符：輸入空白或NULL、輸入特殊字符等可能致使系統錯誤的字符
（3）安全性檢查：不能直接輸入，就copy，是否數據檢驗出錯jquery
信息重複
在一些須要命名,且名字應該惟一的信息輸入重複的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的先後輸入空格,系統是否做出正確處理。android
2、搜索功能
若查詢條件爲輸入框，則參考輸入框對應類型的測試方法：ios
功能實現：
（1）若是支持模糊查詢，搜索名稱中任意一個字符是否能搜索到
（2）比較長的名稱是否能查到
（3）輸入系統中不存在的與之匹配的條件
（4）用戶進行查詢操做時，通常狀況是不進行查詢條件的清空，除非需求特殊說明。
組合測試：
（1）不一樣查詢條件之間來回選擇，是否出現頁面錯誤（單選框和多選框最容易出錯）
（2）測試多個查詢條件時，要注意查詢條件的組合測試，可能不一樣組合的測試會報錯。web
3、添加、修改功能
特殊鍵：
（1）是否支持Tab鍵 （2）是否支持回車鍵
提示信息：
（1）不符合要求的地方是否有錯誤提示
惟一性：
（1）字段惟一的，是否能夠重複添加，添加後是否能修改成已存在的字段（字段包括區分大小寫以及在輸入的內容先後輸入空格，保存後，數據是否真的插入到數據庫中，注意保存後數據的正確性）
數據正確性：
（1）對編輯頁的每一個編輯項進行修改，點擊保存，是否能夠保存成功，檢查想關聯的數據是否獲得更新。
（2）進行必填項檢查（便是否給出提示以及提示後是否依然把數據存到數據庫中；是否提示後出現頁碼錯亂等）
（3）是否可以連續添加（針對特殊狀況）
（4）在編輯的時候，注意編輯項的長度限制，有時在添加的時候有，在編輯的時候卻沒有（注意要添加和修改規則是否一致）
（5）對於有圖片上傳功能的編輯框，若不上傳圖片，查看編輯頁面時是否顯示有默認的圖片，若上傳圖片，查看是否顯示爲上傳圖片
（6）修改後增長數據後，特別要注意查詢頁面的數據是否及時更新，特別是在首頁時要注意數據的更新。
（7）提交數據時，連續屢次點擊，查看系統會不會連續增長几條相同的數據或報錯。
（8）若結果列表中沒有記錄或者沒選擇某條記錄，點擊修改按鈕，系統會拋異常。ajax
4、刪除功能
特殊鍵：
（1）是否支持Tab鍵 （2）是否支持回車鍵
提示信息：
（1）不選擇任何信息，直接點擊刪除按鈕，是否有提示
（2）刪除某條信息時，應該有確認提示
數據 實現：
（1）是否能連續刪除多個產品
（2）當只有一條數據時，是否能夠刪除成功
（3）刪除一條數據後，是否能夠添加相同的數據
（4）如系統支持批量刪除，注意刪除的信息是否正確
（5）若有全選，注意是否把全部的數據刪除
（6）刪除數據時，要注意相應查詢頁面的數據是否及時更新
（7）如刪除的數據與其餘業務數據關聯，要注意其關聯性（如刪除部門信息時，部門下游員工，則應該給出提示）
（8）若是結果列表中沒有記錄或沒有選擇任何一條記錄，點擊刪除按鈕系統會報錯。
如：某一功能模塊具備最基本的增刪改查功能，則須要進行如下測試
單項功能測試（增長、修改、查詢、刪除）
增長——>增長——>增長 （連續增長測試）
增長——>刪除
增長——>刪除——>增長 （新增長的內容與刪除內容一致）
增長——>修改——>刪除
修改——>修改——>修改 （連續修改測試）
修改——>增長（新增長的內容與修改前內容一致）
修改——>刪除
修改——>刪除——>增長 （新增長的內容與刪除內容一致）
刪除——>刪除——>刪除 （連續刪除測試）數據庫
5、修改密碼
不輸入舊密碼，直接改密碼
輸入錯誤舊密碼
不輸入確認新密碼
新密碼和確認新密碼不一致
新密碼中有空格
新密碼爲空
新密碼格式正確
新密碼格式錯誤
新密碼爲非容許字符
看是否支持tap和enter鍵等；密碼是否能夠複製粘貼；密碼是否以*之類的加密符號
看密碼是否區分大小寫，新密碼中小寫，確認密碼中大寫
新密碼和舊密碼同樣可否修改爲功
6、註冊、登陸模塊
註冊功能：
（1）註冊時，設置密碼爲特殊版本號，檢查登陸時是否會報錯
（2）註冊成功後，頁面應該以登錄狀態跳轉到首頁或指定頁面
（3）在註冊信息中刪除已輸入的信息，檢查是否能夠註冊成功。
登陸功能：
（1）輸入正確的用戶名和正確的密碼
（2）輸入正確的用戶名和錯誤的密碼
（3）輸入錯誤的用戶名和正確的密碼
（4）輸入錯誤的用戶名和錯誤的密碼
（5）不輸入用戶名和密碼（均爲空格）
（6）只輸入用戶名，密碼爲空
（7）用戶名爲空，只輸入密碼
（8）輸入正確的用戶名和密碼，可是不區分大小寫
（9）用戶名和密碼包括特殊字符
（10）用戶名和密碼輸入超長值
（11）已刪除的用戶名和密碼
（12）登陸時，當頁面刷新或從新輸入數據時，驗證碼是否更新
7、上傳圖片測試
功能實現：
（1）文件類型正確、大小合適
（2）文件類型正確，大小不合適
（3）文件類型錯誤，大小合適
（4）文件類型和大小都合適，上傳一個正在使用中的圖片
（5）文件類型大小都合適，手動輸入存在的圖片地址來上傳
（6）文件類型和大小都合適，輸入不存在的圖片地址來上傳
（7）文件類型和大小都合適，輸入圖片名稱來上傳
（8）不選擇文件直接點擊上傳，查看是否給出提示
（9）連續屢次選擇不一樣的文件，查看是否上傳最後一次選擇的文件
8、查詢結果列表
功能實現：
（1）列表、列寬是否合理
（2）列表數據太寬有沒有提供橫向滾動
（3）列表的列名有沒有與內容對應
（4）列表的每列的列名是否描述的清晰
（5）列表是否把沒必要要的列都顯示出來
（6）點擊某列進行排序，是否會報錯（點擊查看每一頁的排序是否正確）
（7）雙擊或單擊某列信息，是否會報錯
9、返回鍵檢查
一條已經成功提交的記錄，返回後再提交，是否作了處理
檢查屢次使用返回鍵的狀況，在有返回鍵的地方，返回到原來的頁面屢次，查看是否會出錯
10、回車鍵檢查
在輸入結果後，直接按回車鍵，看系統如何處理，是否會報錯
11、刷新鍵檢查
在Web系統中，使用刷新鍵，看系統如何處理，是否會報錯
12、直接URL連接檢查
在Web系統中，在地址欄直接輸入各個功能頁面的URL地址，看系統如何處理，是否可以直接連接查看（匿名查看），是否有權限控制，是否直接執行，並返回相應結果頁。
十3、界面和易用性測試
風格、樣式、顏色是否協調
界面佈局是否整齊、協調（保證所有顯示出來的，儘可能不要使用滾動條
界面操做、標題描述是否恰當（描述有歧義、注意是否有錯別字）
操做是否符合人們的常規習慣（有沒有把類似的功能的控件放在一塊兒，方便操做）
提示界面是否符合規範（不該該顯示英文的cancel、ok，應該顯示中文的肯定等）
界面中各個控件是否對齊
日期控件是否可編輯
日期控件的長度是否合理，以修改時能夠把時間所有顯示出來爲準
查詢結果列表列寬是否合理、標籤描述是否合理
查詢結果列表太寬沒有橫向滾動提示
對於信息比較長的文本，文本框有沒有提供自動豎直滾動條
數據錄入控件是否方便
有沒有支持Tab鍵，鍵的順序要有條理，不亂跳
有沒有提供相關的熱鍵
控件的提示語描述是否正確
模塊調用是否統一，相同的模塊是否調用同一個界面
用滾動條移動頁面時，頁面的控件是否顯示正常
日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
頁面是否有多餘按鈕或標籤
窗口標題或圖標是否與菜單欄的統一
窗口的最大化、最小化是否能正確切換
對於正常的功能，用戶能夠沒必要閱讀用戶手冊就能使用
執行風險操做時，有確認、刪除等提示嗎
操做順序是否合理
正確性檢查：檢查頁面上的form, button, table, header,footer,提示信息，還有其餘文字拼寫，句子的語法等是否正確。
系統應該在用戶執行錯誤的操做以前提出警告，提示信息
頁面分辨率檢查，在各類分辨率瀏覽系統檢查系統界面友好性。
合理性檢查：作delete, update, add, cancel, back等操做後，查看信息回到的頁面是否合理。
檢查本地化是否經過：英文版不該該有中文信息，英文翻譯準確，專業。
十4、兼容性測試
兼容性測試不僅是指界面在不一樣操做系統或瀏覽器下的兼容，有些功能方面的測試，也要考慮到兼容性，
包括操做系統兼容和應用軟件兼容，可能還包括硬件兼容
好比涉及到ajax、jquery、javascript等技術的，都要考慮到不一樣瀏覽器下的兼容性問題。
十5、連接測試
主要是保證連接的可用性和正確性，它也是網站測試中比較重要的一個方面。
能夠使用特定的工具如XENU來進行連接測試。
1.導航測試
導航描述了用戶在一個頁面內操做的方式，在不一樣的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間。經過考慮下列問題，能夠決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可經過主頁存取？Web系統是否須要站點地圖、搜索引擎或其餘的導航幫助？
在一個頁面上放太多的信息每每起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有知足本身須要的信息，若是沒有，就會很快地離開。不多有用戶願意花時間去熟悉Web應用系統的結構，所以，Web應用系統導航幫助要儘量地準確。
導航的另外一個重要方面是Web應用系統的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。
Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
2.圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的做用，又能起到美化頁面的功能。一個Web應用系統的圖形能夠包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一塊兒，以避免浪費傳輸時間。Web應用系統的圖片尺寸要儘可能地小，而且要能清楚地說明某件事情，通常都連接到某個具體的頁面。
（2）驗證全部頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，通常採用JPG或GIF壓縮，最好能使圖片的大小減少到30k如下
（5）最後，須要驗證的是文字迴繞是否正確。若是說明文字指向右邊的圖片，應該確保該圖片出如今右邊。不要由於使用圖片而使窗口和段落排列古怪或者出現孤行。
一般來講，使用少量或儘可能不使用背景是個不錯的選擇。若是您想用背景，那麼最好使用單色的，和導航條一塊兒放在頁面的左邊。另外，圖案和圖片可能會轉移用戶的注意力。
十6、業務流程測試（主要功能測試）
業務流程，通常會涉及到多個模塊的數據，因此在對業務流程測試時，首先要保證單個模塊功能的正確性，其次就要對各個模塊間傳遞的數據進行測試，這每每是容易出現問題的地方，測試時必定要設計不一樣的數據進行測試。
十7、安全性測試
SQL注入（好比登錄頁面）
XSS跨網站腳本攻擊：程序或數據庫沒有對一些特殊字符進行過濾或處理，致使用戶所輸入的一些破壞性的腳本語句可以直接寫進數據庫中，瀏覽器會直接執行這些腳本語句，破壞網站的正常顯示，或網站用戶的信息被盜,構造腳本語句時，要保證腳本的完整性。
這裏寫圖片描述
URL地址後面隨便輸入一些符號，並儘可能是動態參數靠後
驗證碼更新問題
如今的Web應用系統基本採用先註冊，後登錄的方式。所以，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，能夠試多少次的限制，是否能夠不登錄而直接瀏覽某個頁面等。
Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內（例如15分鐘）沒有點擊任何頁面，是否須要從新登錄才能正常使用。
爲了保證Web應用系統的安全性，日誌文件是相當重要的。須要測試相關信息是否寫進了日誌文件、是否可追蹤。
當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
服務器端的腳本經常構成安全漏洞，這些漏洞又經常被黑客利用。因此，還要測試沒有通過受權，就不能在服務器端放置和編輯腳本的問題。
十8、性能測試
鏈接速度測試
用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。
負載測試
負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工做。負載級別能夠是某個時刻同時訪問Web系統的用戶數量，也能夠是在線數據處理的數量。例如：Web應用系統能容許多少個用戶同時在線？若是超過了這個數量，會出現什麼現象？Web應用系統可否處理大量用戶對同一個頁面的請求？
壓力測試
負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。黑客經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存取權。
壓力測試的區域包括表單、登錄和其餘信息傳輸頁面等。
備註：(
負載/壓力測試應該關注什麼
測試須要驗證系統可否在同一時間響應大量的用戶，在用戶傳送大量數據的時候可否響應，系統可否長時間運行。可訪問性對用戶來講是極其重要的。若是用戶獲得「系統忙」的信息，他們可能放棄，並轉向競爭對手。系統檢測不只要使用戶可以正常訪問站點，在不少狀況下，可能會有黑客試圖經過發送大量數據包來攻擊服務器。出於安全的緣由，測試人員應該知道當系統過載時，須要採起哪些措施，而不是簡單地提高系統性能。
1）瞬間訪問高峯
若是您的站點用於公佈彩票的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內可以響應上百萬的請求。負載測試工具可以模擬X個用戶同時訪問測試站點。
2）每一個用戶傳送大量數據
網上書店的多數用戶可能只訂購1-5書，可是大學書店可能會訂購5000本有關心理學介紹的課本?或者一個祖母爲她的50個兒孫購買聖誕禮物(固然每一個孩子都有本身的郵件地址)系統能處理單個用戶的大量數據嗎?
3）長時間的使用
若是站點用於處理鮮花訂單，那麼至少但願它在母親節前的一週內能持續運行。若是站點提供基於web的email服務，那麼點最好能持續運行幾個月，甚至幾年。可能須要使用自動測試工具來完成這種類型的測試，由於很難經過手工完成這些測試。你能夠想象組織100我的同時點擊某個站點。可是同時組織100000我的呢。一般，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。並且，測試工具安裝完成以後，再次使用的時候，只要點擊幾下。
採起措施：採用性能測試工具WAS、ACT，LR等協助進行測試)
十9、測試中應該注意的其餘狀況
1.在測試時，與網絡有關的步驟或者模塊必須考慮到斷網的狀況
2.每一個頁面都有相應的Title，不能爲空，或者顯示「無標題頁」
3.在測試的時候要考慮到頁面出現滾動條時，滾動條上下滾動時，頁面是否正常
4.URL不區分大小寫，大小寫不敏感
5.對於電子商務網站，當用戶併發購買數量大於庫存的數量時，系統如何處理
6.測試數據避免單純輸入「123」、「abc「之類的，讓測試數據儘可能接近實際
7.進行測試時，儘可能不要用超級管理員進行測試，用新建的用戶進行測試。測試人員儘可能不要使用同一個用戶進行測試
8.提示信息：提示信息是否完整、正確、詳細
9.幫助信息：是否提供幫助信息，幫助信息的表現形式（頁面文字、提示信息、幫助文件），幫助信息是否正確、詳細
10.可擴展性：是否由升級的餘地，是否保留了接口
11.穩定性：運行所需的軟硬件配置，佔用資源狀況，出現問題時的容錯性，對數據的保護
12.運行速度：運行的快慢，帶寬佔用狀況
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
App測試點（一）
2.1安全測試
2.1.1軟件權限
1）扣費風險：包括髮送短信、撥打電話、鏈接網絡等
2）隱私泄露風險：包括訪問手機信息、訪問聯繫人信息等
3）對App的輸入有效性校驗、認證、受權、敏感數據存儲、數據加密等方面進行檢測
4）限制/容許使用手機功能接入互聯網
5）限制/容許使用手機發送接受信息功能
6）限制/容許應用程序來註冊自動啓動應用程序
7）限制或使用本地鏈接
8）限制/容許使用手機拍照或錄音
9）限制/容許使用手機讀取用戶數據
10) 限制/容許使用手機寫人用戶數據
11) 檢測App的用戶受權級別、數據泄漏、非法受權訪問等
2.1.2安裝與卸載安全性
1）應用程序應能正確安裝到設備驅動程序上
2）可以在安裝設備驅動程序上找到應用程序的相應圖標
3）是否包含數字簽名信息
4）JAD文件和JAR包中包含的全部託管屬性及其值必需是正確的
5）JAD文件顯示的資料內容與應用程序顯示的資料內容應一致
6）安裝路徑應能指定
7）沒有用戶的容許, 應用程序不能預先設定自動啓動
8）卸載是否安全, 其安裝進去的文件是否所有卸載
9）卸載用戶使用過程當中產生的文件是否有提示
10）其修改的配置信息是否復原
11）卸載是否影響其餘軟件的功能
12）卸載應該移除全部的文件
2.1.3數據安全性
1）當將密碼或其餘的敏感數據輸人到應用程序時, 其不會被儲存在設備中, 同時密碼也不會被解碼
2）輸人的密碼將不以明文形式進行顯示
3）密碼, 信用卡明細, 或其餘的敏感數據將不被儲存在它們預輸人的位置上
4）不一樣的應用程序的我的身份證或密碼長度必需至少在4一8 個數字長度之間
5）當應用程序處理信用卡明細, 或其餘的敏感數據時, 不以明文形式將數據寫到其它單獨的文件或者臨時文件中。以6）防止應用程序異常終止而又沒有側除它的臨時文件, 文件可能遭受人侵者的襲擊, 而後讀取這些數據信息。
7）當將敏感數據輸人到應用程序時, 其不會被儲存在設備中
8）備份應該加密, 恢復數據應考慮恢復過程的異常�通信中斷等, 數據恢復後再使用前應該通過校驗
9）應用程序應考慮系統或者虛擬機器產生的用戶提示信息或安全替告
10）應用程序不能忽略系統或者虛擬機器產生的用戶提示信息或安全警告, 更不能在安全警告顯示前,，利用顯示誤導信息欺騙用戶，應用程序不該該模擬進行安全警告誤導用戶
11）在數據刪除以前，應用程序應當通知用戶或者應用程序提供一個「取消」命令的操做
12）「 取消」 命令操做可以按照設計要求實現其功能
13）應用程序應當可以處理當不容許應用軟件鏈接到我的信息管理的狀況
14）當進行讀或寫用戶信息操做時, 應用程序將會向用戶發送一個操做錯誤的提示信息
15）在沒有用戶明確許可的前提下不損壞側除我的信息管理應用程序中的任何內容Μ
16）應用程序讀和寫數據正確。
17）應用程序應當有異常保護。
18）若是數據庫中重要的數據正要被重寫, 應及時告知用戶
19）能合理地處理出現的錯誤
20）意外狀況下應提示用戶
須要更多的軟件測試免費資料加羣QQ：706315665
2.1.4通信安全性
1）在運行其軟件過程當中, 若是有來電、SMS、EMS、MMS、藍牙、紅外等通信或充電時, 是否能暫停程序，優先處理通訊, 並在處理完畢後能正常恢復軟件, 繼續其原來的功能
2）當創立鏈接時, 應用程序可以處理由於網絡鏈接中斷, 進而告訴用戶鏈接中斷的狀況
3）應能處理通信延時或中斷
4）應用程序將保持工做到通信超時, 進而發送給用戶一個錯誤信息指示有鏈接錯誤
5）應能處理網絡異常和及時將異常狀況通報用戶
6）應用程序關閉或網絡鏈接再也不使用時應及時關閉) 斷開
7) HTTP、HTTPS覆蓋測試
--App和後臺服務通常都是經過HTTP來交互的，驗證HTTP環境下是否正常；
--公共免費網絡環境中（如：麥當勞、星巴克等）都要輸入用戶名和密碼，經過SSL認證來訪問網絡，須要對使用HTTP Client的library異常做捕獲處理。
2.1.5人機接口安全性
1）返回菜單總保持可用
2）命令有優先權順序
3）聲音的設置不影響應用程序的功能
4）應用程序必需利用目標設備適用的全屏尺寸來顯示上述內容
5）應用程序必需可以處理不可預知的用戶操做, 例如錯誤的操做和同時按下多個鍵
2.2安裝、卸載測試
驗證App是否能正確安裝、運行、卸載以及操做過程和操做先後對系統資源的使用狀況
2.2.1安裝
1）軟件在不一樣操做系統（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安裝是否正常。
2）軟件安裝後的是否可以正常運行，安裝後的文件夾及文件是否寫到了指定的目錄裏。
3）軟件安裝各個選項的組合是否符合概要設計說明
4)）軟件安裝嚮導的UI測試
5）軟件安裝過程是否能夠取消，點擊取消後，寫入的文件是否如概要設計說明處理
6）軟件安裝過程當中意外狀況的處理是否符合需求（如死機，重啓，斷電）
7）安裝空間不足時是否有相應提示
8）安裝後沒有生成多餘的目錄結構和文件
9）對於須要經過網絡驗證之類的安裝，在斷網狀況下嘗試一下
10）還須要對安裝手冊進行測試，依照安裝手冊是否能順利安裝
2.2.2卸載
1）直接刪除安裝文件夾卸載是否有提示信息。
2）測試系統直接卸載程序是否有提示信息。
3）測試卸載後文件是否所有刪除全部的安裝文件夾。
4）卸載過程當中出現的意外狀況的測試（如死機、斷電、重啓）。
5）卸載是否支持取消功能，單擊取消後軟件卸載的狀況 。
6）系統直接卸載UI測試，是否有卸載狀態進度條提示 。
2.3 UI測試
測試用戶界面(如菜單、對話框、窗口和其它可規控件)佈局、風格是否知足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操做是否友好等。
UI測試的目標是確保用戶界面會經過測試對象的功能來爲用戶提供相應的訪問或瀏覓功能。確保用戶界面符合公司或行業的標準。包括用戶友好性、人性化、易操做性測試。
2.3.1導航測試
1）按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間須要導航
2）是否易於導航，導航是否直觀
3）是否須要搜索引擎
4）導航幫助是否準確直觀
5）導航與頁面結構、菜單、鏈接頁面的風格是否一致
2.3.2圖形測試
1）橫向比較。各控件操做方式統一
2）自適應界面設計，內容根據窗口大小自適應
3）頁面標籤風格是否統一
4）頁面是否美觀
5）頁面的圖片應有其實際意義而要求總體有序美觀
6）圖片質量要高且圖片尺寸在設計符合要求的狀況下應儘可能小
7）界面總體使用的顏色不宜過多
2.3.3內容測試
1）輸入框說明文字的內容與系統功能是否一致
2）文字長度是否加以限制
3）文字內容是否表意不明
4）是否有錯別字
5）信息是否爲中文顯示
6）是否有敏感性詞彙、關鍵詞
7）是否有敏感性圖片，如：涉及版權、專利、隱私等圖片
2.4功能測試
根據軟件說明或用戶需求驗證App的各個功能實現，採用以下方法實現並評估功能測試過程：
1)採用時間、地點、對象、行爲和背景五元素或業務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，並明確測試標準，若用戶需求中無明確標準遵循，則須要參考行業或相關國際標準或準則。
2)根據被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋，如；涉及輸入的地方須要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試類型對其進行覆蓋。
3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋狀況，及時修正業務或需求理解錯誤。
2.4.1運行
1）App安裝完成後的試運行，可正常打開軟件。
2）App打開測試，是否有加載狀態進度提示。
3）App打開速度測試，速度是否可觀。
4）App頁面間的切換是否流暢，邏輯是否正確
5）註冊
--同表單編輯頁面
--用戶名密碼長度
--註冊後的提示頁面
--前臺註冊頁面和後臺的管理頁面數據是否一致
--註冊後，在後臺管理中頁面提示
6）登陸
--使用合法的用戶登陸系統。
--系統是否容許屢次非法的登錄，是否有次數限制。
--使用已經登錄的帳號登錄系統是否正確處理。
--使用禁用的帳號登錄系統是否正確處理。
--用戶名、口令（密碼）錯誤或漏填時可否登錄。
--刪除或修改後的用戶，原用戶登錄。
--不輸入用戶口令和用戶、重複點（肯定或取消按鈕）是否容許登錄。
--登錄後，頁面中登錄信息。
--頁面中有註銷按鈕。
--登錄超時的處理。
7）註銷
--註銷原模塊，新的模塊系統可否正確處理。
--終止註銷可否返回原模塊，原用戶。
--註銷原用戶，新用戶系統可否正確處理。
--使用錯誤的帳號、口令、無權限的被禁用的帳號進行註銷
2.4.2應用的先後臺切換
1) APP切換到後臺，再回到app，檢查是否停留在上一次操做界面。
2) APP切換到後臺，再回到app，檢查功能及應用狀態是否正常，IOS4和IOS5的版本的處理機制有的不同。
3) app切換到後臺，再回到前臺時，注意程序是否崩潰，功能狀態是否正常，尤爲是對於從後臺切換回前臺數據有自動更新的時候。
4) 手機鎖屏解屏後進入app注意是否會崩潰，功能狀態是否正常，尤爲是對於從後臺切換回前臺數據有自動更新的時候。
5) 當App使用過程當中有電話進來中斷後再切換到app，功能狀態是否正常
6) 當殺掉app進程後，再開啓app，app可否正常啓動。
7) 出現必須處理的提示框後，切換到後臺，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷。
8) 對於有數據交換的頁面，每一個頁面都必須要進行先後臺切換、鎖屏的測試，這種頁面最容易出現崩潰。
2.4.3免登陸
不少應用提供免登陸功能，當應用開啓時自動以上一次登陸的用戶身份來使用app.
1) app有免登陸功能時，須要考慮IOS版本差別。
2) 考慮無網絡狀況時可否正常進入免登陸狀態。
3) 切換用戶登陸後，要校驗用戶登陸信息及數據內容是否相應更新，確保原用戶退出。
4) 根據MTOP的現有規則，一個賬戶只容許登陸一臺機器。因此，須要檢查一個賬戶登陸多臺手機的狀況。原手機裏的用戶須要被踢出，給出友好提示。
5) app切換到後臺，再切回前臺的校驗
6) 切換到後臺，再切換回前臺的測試
7) 密碼更換後，檢查有數據交換時是否進行了有效身份的校驗
8) 支持自動登陸的應用在進行數據交換時，檢查系統是否能自動登陸成功而且數據操做無誤。
9) 檢查用戶主動退出登陸後，下次啓動app，應停留在登陸界面
2.4.4數據更新
根據應用的業務規則，以及數據更新量的狀況，來肯定最優的數據更新方案。
1) 須要肯定哪些地方須要提供手動刷新，哪些地方須要自動刷新，哪些地方須要手動+自動刷新。
2) 肯定哪些地方從後臺切換回前臺時須要進行數據更新。
3) 根據業務、速度及流量的合理分配，肯定哪些內容須要實時更新，哪些須要定時更新。
4) 肯定數據展現部分的處理邏輯，是每次從服務端請求，仍是有緩存到本地，這樣纔能有針對性的進行相應測試。
5) 檢查有數據交換的地方，均有相應的異常處理。
2.4.5離線瀏覽
不少應用會支持離線瀏覽，即在本地客戶端會緩存一部分數據供用戶查看。
1) 在無網絡狀況能夠瀏覽本地數據
2) 退出app再開啓app時能正常瀏覽
3) 切換到後臺再切回前臺能夠正常瀏覽
4) 鎖屏後再解屏回到應用前臺能夠正常瀏覽
5) 在對服務端的數據有更新時會給予離線的相應提示
2.4.6 App更新
1) 當客戶端有新版本時，有更新提示。
2) 當版本爲非強制升級版時，用戶能夠取消更新，老版本能正常使用。用戶在下次啓動app時，仍能出現更新提示。
3) 當版本爲強制升級版時，當給出強制更新後用戶沒有作更新時，退出客戶端。下次啓動app時，仍出現強制升級提示。
4) 當客戶端有新版本時，在本地不刪除客戶端的狀況下，直接更新檢查是否能正常更新。
5) 當客戶端有新版本時，在本地不刪除客戶端的狀況下，檢查更新後的客戶端功能是不是新版本。
6) 當客戶端有新版本時，在本地不刪除客戶端的狀況下，檢查資源同名文件如圖片是否能正常更新成最新版本。若是以上沒法更新成功的，也都屬於缺陷。
2.4.7定位、照相機服務
1) App有用到相機，定位服務時，須要注意系統版本差別
2) 有用到定位服務、照相機服務的地方，須要進行先後臺的切換測試，檢查應用是否正常。
3) 當定位服務沒有開啓時，使用定位服務，會友好性彈出是否容許設置定位提示。當肯定容許開啓定位時，能自動跳轉到定位設置中開啓定位服務。
4) 測試定位、照相機服務時，須要採用真機進行測試。
2.4.8時間測試
客戶端能夠自行設置手機的時區、時間，所以須要校驗該設置對app的影響。
--中國爲東8區，因此當手機設置的時間非東8區時，查看須要顯示時間的地方，時間是否展現正確，應用功能是否正常。時間通常須要根據服務器時間再轉換成客戶端對應的時區來展現，這樣的用戶體驗比較好。好比發表一篇微博在服務端記錄的是10：00，此時，華盛頓時間爲22：00，客戶端去瀏覽時，若是設置的是華盛頓時間,則顯示的發表時間即爲22:00,當時間設回東8區時間時，再查看則顯示爲10：00。
2.4.9 PUSH測試
1) 檢查push消息是否按照指定的業務規則發送
2) 檢查不接受推送消息時，檢查用戶不會再接收到push.
3) 若是用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到PUSH。
在非免打擾時間段，用戶能正常收到push。
4) 當push消息是針對登陸用戶的時候，須要檢查收到的push與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。通常狀況下，只對手機上最後一個登陸用戶進行消息推送。
5) 測試push時，須要採用真機進行測試。
2.5性能測試
評估App的時間和空間特性 ：
1)極限測試：在各類邊界壓力狀況下，如電池、存儲、網速等，驗證App是否能正確響應。
--內存滿時安裝App
--運行App時手機斷電
--運行App時斷掉網絡
2)響應能力測試：測試App中的各種操做是否知足用戶響應時間要求 。
--App安裝、卸載的響應時間
--App各種功能性操做的影響時間
3)壓力測試：反覆/長期操做下、系統資源是否佔用異常。
--App反覆進行安裝卸載，查看系統資源是否正常
--其餘功能反覆進行操做，查看系統資源是否正常
4)性能評估：評估典型用戶應用場景下，系統資源的使用狀況。
5)Benchmark測試（基線測試）：與競爭產品的Benchmarking, 產品演變對比測試等。
須要更多的軟件測試免費資料加我QQ：706315665
2.6交叉事件測試
針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法。交叉測試又叫事件或衝突測試，是指一個功能正在執行過程當中，同時另一個事件或操做對該過程進行干擾的測試。如；App在前/後臺運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互狀況測試等。交叉事件測試很是重要，能發現不少應用中潛在的性能問題。
1） 多個App同時運行是否影響正常功能
2） App運行時前/後臺切換是否影響正常功能
3） App運行時撥打/接聽電話
4） App運行時發送/接收信息
5） App運行時發送/收取郵件
6） App運行時切換網絡（2G、3G、wifi）
7） App運行時瀏覽網絡
8） App運行時使用藍牙傳送/接收數據
9） App運行時使用相機、計算器等手機自帶設備
2.7兼容測試
主要測試內部和外部兼容性
1）與本地及主流App是否兼容
2）基於開發環境和生產環境的不一樣，檢驗在各類網絡鏈接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數據和運用是否正確
3）與各類設備是否兼容，如有跨系統支持則須要檢驗是否在各系統下，各類行爲是否一致
--不一樣操做系統的兼容性，是否適配
--不一樣手機屏幕分辨率的兼容性
--不一樣手機品牌的兼容性
2.8迴歸測試
1）Bug修復後且在新版本發佈後須要進行迴歸測試。
2）Bug修復後的迴歸測試在交付前、要進行全量用例的迴歸測試。
2.9升級、更新測試
新版版發佈後，配合不一樣網絡環境的自勱更新提示及下載、安裝、更新、啓勱、運行的驗證測試。
1）測試升級後的功能是否與需求說明同樣
2）測試與升級模塊相關的模塊的功能是否與需求一致
3）升級安裝意外狀況的測試（如死機、斷電、重啓）
4）升級界面的UI測試
5）不一樣操做系統間的升級測試
2.10用戶體驗測試
以主觀的普通消費者的角度去感知產品或服務的溫馨、有用、易用、友好親切程度。 經過不一樣個體、獨立空間和非經驗的統計複用方式去有效評價產品的體驗特性提出修改意見提高產品的潛在客戶滿意度。
1）是否有空數據界面設計，引導用戶去執行操做。
2）是否濫用用戶引導。
3）是否有不可點擊的效果，如：你的按鈕此時處於不可用狀態，那麼必定要灰掉，或者拿掉按鈕，不然會給用戶誤導
4）菜單層次是否太深
5）交互流程分支是否太多
6）相關的選項是否離得很遠
7）一次是否載入太多的數據
8）界面中按鈕可點擊範圍是否適中
9）標籤頁是否跟內容沒有從屬關係，當切換標籤的時候，內容跟着切換
10）操做應該有主次從屬關係
11）是否認義Back的邏輯。涉及軟硬件交互時，Back鍵應具體定義
12）是否有橫屏模式的設計，應用通常須要支持橫屏模式，即自適應設計
2.11 硬件環境測試
2.11.1手勢操做測試
1）手機開鎖屏對運行中的App的影響
2）切換網絡對運行中的App的影響
3）運行中的App先後臺切換的影響
4）多個運行中的App的切換
5）App運行時關機
6）App運行時重啓系統
7）App運行時充電
8）App運行時kill掉進程再打開
2.11.2網絡環境
手機的網絡目前主要分爲2G、3G、wifi。目前2G的網絡相對於比較慢，測試時尤爲要注意此塊的測試。
1) 無網絡時，執行須要網絡的操做，給予友好提示，確保程序不出現crash。
2) 內網測試時，要注意選擇到外網操做時的異常狀況處理。
3) 在網絡信號很差時，檢查功能狀態是否正常，確保不因提交數據失敗而形成crash。
4) 在網絡信號很差時，檢查數據是否會一直處於提交中的狀態，有無超時限制。如遇數據交換失敗時要給予提示。
5) 在網絡信號很差時，執行操做後，在回調沒有完成的狀況下，退出本頁面或者執行其餘操做的狀況，有無異常狀況。此問題也會常常出現程序crash。
2.11.3服務器宕機或出現40四、502等狀況下的測試
後臺服務牽涉到DNS、空間服務商的狀況下會影響其穩定性，如：當出現域名解析故障時，你對後臺API的請求極可能就會出現404錯誤，拋出異常。這時須要對異常進行正確的處理，不然可能會致使程序不能正常工做。
2.12接口測試
服務端通常會提供JSON格式的數據給客戶端，因此咱們在服務端須要進行接口測試，確保服務端提供的接口並轉換的JSON內容正確，對分支、異常流有相應的返回值。此塊測試能夠採用itest框架進行測試。最方便的是採用httpclient進行接口測試。
進行服務端測試時，須要開發提供一份接口文檔。
2.13客戶端數據庫測試
1）通常的增、刪、改、查測試。
2） 當表不存在時是否能自動建立，當數據庫表被刪除後可否再自建，數據是否還能自動從服務端中獲取回來並保存。
3） 在業務須要從服務端取回數據保存到客戶端的時候，客戶端可否將數據保存到本地。
4） 當業務須要從客戶端取數據時，檢查客戶端數據存在時，app數據是否能自動從客戶端數據中取出，仍是仍然會從服務器端獲取？檢查客戶端數據不存在時，app數據可否自動從服務器端獲取到並保存到客戶端
5） 當業務對數據進行了修改、刪除後，客戶端和服務端是否會有相應的更新。
-----------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
H5頁面的基本測試點
優點：
H5能夠跨平臺使用，開發成本相對較低
H5可隨時上線就更新版本，適合快速迭代
H5能夠輕量的觸達用戶，提供更便捷的服務
(在微信入口或者瀏覽器上，用戶只需點開連接就能夠獲取咱們鎖提供的服務)
劣勢：
H5->app的轉化強依賴於瀏覽器
H5目前基本沒法將數據存儲在本地，依賴實時性數據，網絡狀態很差的時候卡到哭。
性能相對較低，影響用戶體驗
如何判斷是不是H5頁面：
基本上只要對那個view長按，而後看是否是有反應，好比手機震動（Android）、或者出現文字選擇粘貼（Android/iOS），那麼就是WebView！
如何測試H5：
1.基本功能測試：（瀏覽器、微信內置瀏覽器）
2.登錄
目前H5與native各個客戶端都作了互通，因此你們在測試的時候要注意兩點：
A、若客戶端已登陸，那麼進入H5後仍然是登陸狀態。
B、若客戶端未登陸，進入H5，點擊對應按鈕OR連接，若是須要登陸，須拉起native登陸。若取消登陸，是否可再次拉起登陸，或者停留在的頁面是否有對應的登陸提示。
ps：本次測試過程當中就發現，第一次點擊連接，能夠拉起登陸，第二次卻不能。
1.2 翻頁
遇到翻頁加載的頁面，須要注意內容爲1頁或者多頁的狀況。
A、數據分頁加載時，注意後續頁面請求數據的正確。
ps：這個須要注意在快速操做場景中，請求頁數是否是依次遞增，快速操做（如第一頁還沒有loading出來的時候仍然繼續上拉操做）時是否發出去對應的請求了。
3. 刷新與返回
A、下拉刷新是否仍然處於當前頁面。
B、用戶主動點擊刷新按鈕是否仍然處於當前頁面。
C、點擊返回與back鍵，回退頁面是不是指望頁面
ps：本次測試過程當中就發現，mtop接口請求成功，可是data內無數據時，返回到的就是個空白頁面，沒法正常發送請求。
四、H5適配相關
H5的適配其實比客戶端的相對來講，要少一些，手機品牌之間的差別不大，因此不用太多關注，最容易出現問題的是android2.3系統，這個要特別關注下：
A、大屏（如720*1280，重點關注頁面背景是否徹底撐開頁面，刷新是否有抖動）、小屏手機（如320*480，重點關注下彈框樣式和文案折行）
B、android2.三、android4.X隨機找一個便可。
C、ios五、ios六、ios7。
五、體驗相關
5.1 資源相關
A、頁面中有圖片的話，淘寶那邊建議圖片通常不大於50kb，本着一個原則，儘可能縮小圖片。
B、資源是否壓縮、是否經過CDN加載。
C、如何保證二次發佈後有效更新。
5.2 流量
A、對於一些不會變化的圖片，如遊戲動畫效果相關圖片，不須要每次都請求的東西，作本地緩存。
B、數據較多時是否作了分頁加載。
5.3 頁面展示時間
A、關注頁面首屏加載時間。
5.4 頁面提示
A、弱網絡下，數據加載較慢，是否有對應的loading提示。
B、接口獲取異常時，提示是否友好。
C、刷新頁面或者加載新內容時頁面是否有抖動。
5.5 手機操做相關
A、鎖屏以後展現頁面。
B、回退到後臺以後，從新呼出在前臺展現。
-----------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------
微信APP和小程序
1.前端頁面
微信Web開發者工具安裝、受權測試用的微信號可預覽和調試小程序...
可參考此文： 微信Web開發者工具-下載、安裝和使用圖解（https://www.jianshu.com/p/4d3190111eb0）
2.管理後臺
配置內網測試服務器環境，經過PC端Web站點管理小程序前端的輸出內容，可從開發人員獲取管理帳號進行測試
2、測試範圍
1.權限測試
須要檢查如下幾種狀況下微信用戶訪問的權限
1）未受權微信登陸小程序
未受權時，通常使用一些業務功能的時候，都會彈出提醒：先受權再操做對應功能。or在提交數據到後臺的時候，會提示補充相關身份信息才能提交成功
2）已受權微信登陸小程序
受權微信訪問小程序，意味着本身的微信帳號可被小程序管理方所獲取，自動以微信的身份行使業務操做權限，好比諮詢、支付、數據查詢等
3）同一微信號在不一樣手機端登陸受權查看數據權限
同一微信號在不一樣手機微信端受權登陸同一小程序以後，所能查看的數據和操做的權限都應該是同步一致的
2.功能測試
1）按功能模塊測試
根據設計好的各個大類功能模塊劃分，而後再逐級細化，覆蓋到每一個功能儘量全面的測試點
2）按業務流程測試
小程序的業務，好比諮詢、支付、播放、查詢、下載。把各個功能點串聯起來造成完整的業務流程來檢查；同一個業務，可能有不能的路徑來實現，每一個路徑都須要覆蓋檢查
3）按數據流向測試
根據數據從某一端操做輸入和輸出流向，設計基於數據流的測試用例，輸出的數據也可能成爲另一端的輸入，檢查輸入的數據是否按照代碼邏輯執行正確的輸出，是否數據發生異常（沒法輸入；有輸入卻無任何輸出；輸出不正確；多餘的輸出其餘信息...）
4）同一功能不一樣的入口有效性的檢查
小程序中在首頁、列表頁、詳細頁、其餘的業務功能相關頁面，都有可能存在同一個功能的入口，如付費諮詢、免費諮詢業務中，能夠直接從首頁進入付費諮詢入口，也能夠經過免費諮詢入口再切換到付費諮詢入口。每個入口路徑都須要覆蓋檢查
5）交互性檢查
通常而言，產生數據和功能交互變化的狀況主要有這幾個分類：前臺<-->前臺、後臺<-->後臺、前臺<-->後臺。前臺從A1頁面提交的數據，可能須要在前臺A2頁面查看到，也會在對應後臺的B頁面查到記錄；後臺B1頁面修改or添加的數據，對應到前臺的A頁面產生交互變化，後臺自己的不一樣頁面之間也可能存在同一個數據的輸出值
3.版本配置測試
有時候小程序一次性作了幾套不相同的模板，在前端程序代碼中修改配置參數，保存後從新編譯，便可從一個版本切換到另外一版本，同時也須要在管理後臺做相應的切換，以保證前端進行數據調用
對於非公用的部分：不一樣版本直接的切換，須要保證彼此的功能模塊和數據獨立性不受干擾影響，即不一樣版本的管理後臺所添加的數據只應該調用到各自對應模板的前臺小程序中，不一樣版本的小程序從前臺提交的數據也只會提交到各自管理後臺，不該該有交差重疊
對於公用的部分：切換不一樣的模板，都會顯示相同的內容
4.兼容性測試
1）手機操做系統
常規的手機端OS爲：Android（7.x/6.x/4.x/2.x...）、IOS（11.x/10.x/9.x...）
2）微信版本
對於已上線的小程序，有可能會由於微信版本升級以後致使對部分小程序的組件支持產生衝突，手機端微信上查看的小程序頁面出現樣式有異常，好比出現少部分區域的黑屏，這種狀況須要同步在小程序的程序包中修改一些組件再次更新
5.易用性測試
1）導航
定位到頁面某個模塊所在位置，回到頂部or底部，導航條的收展，導航標籤的文字是否容易理解
2）功能入口
重要且經常使用業務的功能入口，是否在比較顯眼的位置，業務操做過程是否便於大多數用戶使用和查看
3）上下層級進入&返回
首頁<-->列表頁、列表頁<-->詳細頁 、首頁<-->詳細頁。不一樣層級之間的進入和返回實現是否有相應按鍵易操做
4）字體、圖片、動態交互效果
字體：標籤、標題、內容、動態播放字體...
圖片：輪播圖、背景圖、封面圖、觸屏產生的交互圖...
3、注意事項
1.上線
1）上線配置
內網測試、線上測試對應不一樣url接口；上線前，須要修改內網測試接口地址爲正式環境使用的接口。同時還有一個配置參數的 轉換設置也要關注到
2）審覈
將程序包提交給微信官方進行審覈，工做日審覈通常0.5d-1d以內能夠搞定
3）發佈
微信官方審覈經過後，便可發佈小程序到正式環境中訪問使用，經過手機微信端搜索對應小程序的名字便可搜索到
2.經常使用功能
1）緩存清理
微信Web開發者工具、手機端微信的緩存清理。
使用場景：數據修改後檢查修改的效果，程序修改代碼後檢查效果等狀況，可清除緩存後再檢查
2）編譯
更新測試版本時使用。小程序須要通過幾輪的循環測試和修復，開發人員每次修復Bug完成以後會添加新的程序包給到測試人員，測試人員則須要經過微信Web開發者工具刪除舊版本的項目程序，從新添加新版本的程序包，而後編譯調試
3.經常使用操做鍵
新建項目：Ctr+Shift+N
保存：Ctr+S
關閉文件：Ctr+W
搜索：Ctr+F
刷新：Ctr+R
編譯：Ctr+B
預覽：Ctr+Shift+P
清除緩存
-------------------------------------------------------------------------------
導入導出：
1. 模板測試
1）檢查模板是否能夠正常下載，正常打開。
2）檢查Excel模板文件和系統列表中的數據字段是否一致。
3）模板中是否對必填項作了說明和標識
4）模板中是否對字段長度的約束作了說明
5）模板中是否對特殊字段的格式作了說明
6）模板的排版是否合理，樣式是否美觀
2. 導入功能
導入成功
1）輸入有效數據導入，看是否能導入成功
2）只填寫必填項看是否能導入成功
3）最後一列後面加一列數據看是否能導入成功
4）本身手動新建excel或者對其餘excel進行修改，使excel格式和模板一致，看是否能導入
5）數據中間空幾行數據看是否能導入成功
導入失敗
1）數據爲空，導入數據爲空時是否會提示「導入失敗，導入模板中無任何數據」
2）必填項爲空，必填項爲空時是否會提示「導入失敗，並說明具體某一行的某個字段爲空」
3）數據不符合規則
① 全部行均存在格式不符合規則的數據，是否會提示「導入失敗，並給出每一行對應的錯誤緣由」
② 全部行均存在超出長度範圍的數據，是否會提示「導入失敗，並給出每一行對應的錯誤緣由」
③ 部分符合規則，部分不符合規則
對於③，根據需求不一樣，可能存在下面兩種狀況：
a、符合規則的導入成功，不符合規則的導入失敗，並給出失敗行對應的錯誤緣由
b、導入失敗，並給出失敗行對應的錯誤緣由
4）模板內的數據之間存在重複
可能存在下面兩種狀況：
a、除重複行以外的其餘數據導入成功，重複行中的第一行導入成功，後面一行導入失敗，並給出失敗行對應的錯誤緣由
b、導入失敗，並給出失敗行對應的錯誤緣由
5）模板內的數據與系統中已經存在的數據衝突
根據需求不一樣，可能存在下面兩種狀況：
a、除存在衝突以外的其餘數據導入成功，存在衝突的行導入失敗，並給出失敗行對應的錯誤緣由
b、導入失敗，並給出失敗行對應的錯誤緣由
6）表頭檢查：包括去掉、修改、新增列、列之間切換，看數據是否能成功導入
7）導入其餘格式的文件，當導入的文件格式不正確時，系統是否作出正確的判斷，並給出對應的錯誤提示。
8）不選擇導入文件：沒法導入，並提示「請選擇導入文件」
9）取消導入：取消導入操做成功，並不執行導入操做
10）模板內的數據存在衝突（好比：截止日期小於起始日期以內）
11）新增一行數據，而後將數據刪除【若是開發判斷方法有誤，會認爲刪除的這條數據也存在】
3. 導出功能
1）導出的excel文件名是否有要求，若是有要求，是否正確。
2）導出的excel表格的格式檢查，主要檢查導出的excel格式是否符合預期，各字段是否正確。
3）導出所有數據功能是否正確
4）導出部分數據功能是否正確
5）選擇數據爲空時是否能夠導出。
6）導出的數據內容是否與系統中的內容一致。
7）不一樣瀏覽器導出的文件是否一致
8）excel導出時數據的分頁檢查。【通常數據量較大時，開發都會分批次去取數據，分頁時容易出現問題】
9）注意導出文件的排版問題，當某一字段的內容過長時，是否能夠自動換行
-------------------------------------
查詢：
若查詢條件爲輸入框，則參考輸入框對應類型的測試方法
一、功能實現：
（1）若是支持模糊查詢，搜索名稱中任意一個字符是否能搜索到
（2）比較長的名稱是否能查到
（3）輸入系統中不存在的與之匹配的條件
（4）用戶進行查詢操做時，通常狀況是不進行查詢條件的清空，除非需求特殊說明。
二、組合測試：
（1）不一樣查詢條件之間來回選擇，是否出現頁面錯誤（單選框和多選框最容易出錯）
（2）測試多個查詢條件時，要注意查詢條件的組合測試，可能不一樣組合的測試會報錯。
用例：
默認條件查詢
按各查詢條件是否都可以查詢出相應的值
組合查詢數據
模糊查詢
日期查詢－測試邊界值查詢是否正常
日期查詢－測試當存在開始日期及結束日期進行查詢時，是否對其進行了邏輯判斷
日期查詢－測試對日期型字段查詢時,是否進行了溢出控制
查詢功能需自動處理輸入內容兩端的空格
執行查詢操做後,查詢條件是否能保留
是否控制了各類非法字符的查詢
另外一個搜索功能測試點：
--正向測試
1.搜索功能是否符合需求並正確實現。
2.檢索網站中存在的數據 ，結果是否準確。
--反向測試
1.若是支持模糊查詢，搜索名稱中任意一個字符是否能搜索到
2.檢查超長的搜索條件是否能查到
-錯誤測試法
1.輸入當前鍵盤中的全部特殊字符 ，單個或組合，查看系統響應
2.輸入系統中不存在的與之匹配的條件是否能夠檢索到。
-易用性測試
1.檢查系統是否支持Enter鍵，tab鍵。
2.檢查搜索結果頁是否與其餘頁面風格統一，樣式一致 。
3.檢查光標置於搜索框中時，是否自動清空當前默認內容。
-安全測試法
1.輸入一些彈框代碼或SQL命令，檢查系統響應
------------------------------------------------------------
排序功能測試點：
-正向測試
1.點擊升序排列按鈕，檢查排序結果 （文字排序時是否按照拼音首字母，數字排序時是否皇家馬德里大小）。
2.點擊降序排列按鈕，檢查排序結果 。
-反向測試
1.反覆點擊排序按鈕，檢查系統響應。
2.按某個條件排序後，點擊進入中間頁，再按另外一個條件進行排序，檢查頁面刷新。
--------------------------------------------------------
登陸功能測試點：
驗證登陸流程判斷邏輯
前端
帳戶名、密碼、驗證碼 是否爲空？
密碼是否符合規則(特殊字符、大小寫、數字、長度..)
服務端
驗證碼是否正確 （對應時間戳是否過時）
帳戶是否存在 （未註冊、已註銷）
密碼是否正確 （記錄連續輸入錯誤次數，超過5次，帳號鎖定4小時。或提高驗證等級，採起帳號+密碼+驗證碼+短信驗證）
返回session、token
1、基本功能測試點：
輸入正確的用戶名和密碼登陸成功
輸入錯誤的用戶名密碼登陸失敗
用戶名正確，密碼錯誤，是否提示輸入密碼錯誤？
用戶名錯誤，密碼正常，是否提示輸入用戶名錯誤？
用戶名和密碼都錯誤，是否有相應提示？
用戶名密碼爲空時，是否有相應提示？
若是用戶未註冊，提示請先註冊，而後進行登陸
已經註銷的用戶登陸失敗，提示信息友好？
密碼框是否加密顯示？
用戶名是否支持中文、特殊字符？
用戶名是否有長度限制？
密碼是否支持中文，特殊字符？
密碼是否有長度限制？
密碼是否區分大小寫？
密碼爲一些簡單經常使用字符串時，是否提示修改？如：123456
密碼存儲方式？是否加密？
登陸功能是否須要輸入驗證碼？
驗證碼有效時間？
驗證碼輸入錯誤，登陸失敗，提示信息是否友好？
輸入過時的驗證可否登陸成功？
驗證碼是否容易識別？
驗證碼換一張功能是否可用？點擊驗證碼圖片是否能夠更換驗證碼？
用戶體系：好比系統分普通用戶、高級用戶，不一樣用戶登陸系統後可的權限不一樣。
若是使用第三方帳號(QQ,微博帳號)登陸，那麼第三方帳號與本系統的帳號體系對應關係如何保存？首次登陸須要極權等
2、頁面測試：
登陸頁面顯示是否正常？文字和圖片可否正常顯示，相應的提示信息是否正確，按鈕的設置和排列是否正常，頁面是否簡潔壯觀等。
頁面默認焦點是否認位在用戶名的輸入框中
首次登陸時相應的輸入框是否爲空？或者若是有默認文案，當點擊輸入框時默認方案是否消失？
相應的按鈕如登陸、重置等，是否可用;頁面的前進、後退、刷新按鈕是否可用？
快捷鍵Tab,Esc,Enter 等，可否控制使用
兼容性測試：不一樣瀏覽器，不一樣操做系統，不一樣分辨率下界面是否正常
三 、安全測試：
不登陸：瀏覽器中直接輸入登陸後的地址，看是否能夠直接進入
登陸成功後生成的Cookie，是不是httponly (不然容易被腳本盜取)
用戶名和密碼是否經過加密的方式，發送給Web服務器
用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript驗證
用戶名和密碼的輸入框，應該屏蔽SQL 注入攻擊
用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊）
錯誤登錄的次數限制（防止暴力破解）
考慮是否支持多用戶在同一機器上登陸；
考慮一用戶在多臺機器上登陸
4、性能測試：
單用戶登陸系統的響應時間是否符合"3-5-8"原則
用戶數在臨界點時併發登陸是否還能符合"3-5-8"原則
壓力：大量併發用戶登陸，系統的響應時間是多少？系統會出現宕機、內存泄露、cpu飽和、沒法登陸嗎?
穩定性： 系統可否處理併發用戶數在臨界點之內連續登陸N個時的場景？
5、其它測試：
連續輸入3次或以上錯誤密碼，用記是否被鎖必定時間（如：15分鐘）？時間內不容許登陸，超出時間點是否能夠繼續登陸。
用戶session過時後，從新登陸是否還能從新返回這前session過時的頁面？
用戶名和密碼輸入框是事支持鍵盤快捷鍵？如：撤銷、複製、粘貼等等
是否容許同名用戶同時登陸進行操做？考慮web和app同時登陸
手機登陸時，是否先判斷網絡可用？
手機登陸時，是否先判斷app存在新版本？
是否支持單點登陸？
是否有埋點接口
------------------------------------------------------
下拉框測試點：
基本測試：
1)默認值(爲空，提示選擇，某一值)檢查；
2)列表內容，是可變仍是固定的，可變的最好要用SQL或其餘方式驗證正確性，不容許出現重複值；
3)列表中的排序方式，特別是選項過多時尤其重要；
4)列表過長是否提供滾動條支持，通常超過10個須要滾動條；
5)選擇一個選項後是否可編輯，有的下拉菜單容許編輯選擇，這還須要驗證其合法性；
6)列表中文本的對齊方式，通常都是左對齊；
7)選擇框的長度是否可變；
8)選擇框的長度是否合適，是否會出現選擇項後不能所有顯示其內容；
9)下拉菜單獲取焦點後，是否能夠經過鍵盤操做，主要包括↑,↓,Home ,End ,PageUP ,PageDown等。
可編輯的下拉菜單測試：
1)插入新值，檢查輸入合法性，重複值要提示；插入值長度、個數是否有限制；
2)刪除一個值；可否刪除默認值；是否全部的預置選項可刪除，是否可刪除全部選項；
3)新增，刪除選項後，下拉菜單內容是否能正確顯示。
下拉菜單聯動檢查：
假設有A、B、C三個下拉菜單，A聯動B，B聯動C；這時須要檢查：
1)A選擇一個選項後，B下拉菜單內容應該是A中這一項所包括的全部內容；
2)選擇B中的一個選項，C下拉菜單內容應該是B中這一項所包括的全部內容；
3)更改A中的內容，B，C菜單應該作相應改變；
4)更改B中內容，C菜單應作相應改變。
----------------------------------------------------------
添加、修改功能測試點：
一、特殊鍵：（1）是否支持Tab鍵 （2）是否支持回車鍵
二、提示信息：（1）不符合要求的地方是否有錯誤提示
三、惟一性：（1）字段惟一的，是否能夠重複添加，添加後是否能修改成已存在的字段（字段包括區分大小寫以及在輸入的內容先後輸入空格，保存後，數據是否真的插入到數據庫中，注意保存後數據的正確性）
四、數據 正確性：
（1）對編輯頁的每一個編輯項進行修改，點擊保存，是否能夠保存成功，檢查想關聯的數據是否獲得更新。
（2）進行必填項檢查（便是否給出提示以及提示後是否依然把數據存到數據庫中；是否提示後出現頁碼錯亂等）
（3）是否可以連續添加（針對特殊狀況）
（4）在編輯的時候，注意編輯項的長度限制，有時在添加的時候有，在編輯的時候卻沒有（注意要添加和修改規則是否一致）
（5）對於有圖片上傳功能的編輯框，若不上傳圖片，查看編輯頁面時是否顯示有默認的圖片，若上傳圖片，查看是否顯示爲上傳圖片
（6）修改後增長數據後，特別要注意查詢頁面的數據是否及時更新，特別是在首頁時要注意數據的更新。
（7）提交數據時，連續屢次點擊，查看系統會不會連續增長几條相同的數據或報錯。
（8）若結果列表中沒有記錄或者沒選擇某條記錄，點擊修改按鈕，系統會拋異常。
添加功能測試點
添加按鈕
添加窗口
添加空數據
添加數據-缺乏必填項
添加一條數據
添加惟一字段重複的數據
關閉功能
Tab鍵的使用
Tab鍵和Enter鍵聯合使用
Esc鍵
字段長度的限制
下拉框
日期格式設置
非負整型數據
空格
肯定按鈕
修改功能測試點
修改按鈕
Tab鍵的使用
Tab鍵和Enter鍵聯合使用
Esc鍵
字段長度的限制
下拉框
日期格式設置
非負整型數據
空格
修改後取消
必填項不填的保存提示
將內容修改超過指定長度
添加惟一字段重複的數據
Html腳本限制
修改後保存
-------------------------------------------------------------------------------------
文件上傳和下載測試點：
文件上傳：
頁面
頁面美觀性、易用性（鍵盤和鼠標的操做、tab跳轉的順序是否正確）
按鈕文字正確性
說明文字是否正確
正確/錯誤的提示文字是否正確
提示當前位置是否正確，而且和其餘頁面保持一致格式
必填項的標示是否正確
功能
路徑是否能夠手工輸入（手工輸入的時候有沒有限長）
上傳文件超過最大值是在提交前校驗仍是提交後校驗
上傳文件格式是否所有支持（圖片：gif/jpg/bmp…文檔：doc/sxw/xls…壓縮包：zip/rar…安裝文件：exe/msi）
上傳文件是否支持中文名稱
文件名稱的最大值、最小值、特殊字符（包含空格）、使用程序語句是否會對其形成影響、中文名稱是否能正常顯示
對因而否發佈的設置是否正確（前臺校驗）
簡介最大值、特殊字符、使用程序語句是否會對其形成影響
按鈕
保存按鈕
對輸入項有錯誤提示後光標提示是否正確
對輸入項的錯誤提示是否描述正確
對必添項是否進行校驗
清空按鈕
是否清除（或還原）了填寫內容
返回按鈕
是否返回上一頁面
文件下載：
頁面
當前位置的提示是否現實正確
頁面美觀性、易用性（鍵盤和鼠標的操做、tab跳轉的順序是否正確）
按鈕文字是否正確
說明性文字是否正確
正確/錯誤的提示文字是否正確
功能*
右鍵另存爲是否能夠正確下載文件，而且記錄下載次數
工具下載是否正確，而且記錄下載次數
單擊下載是提示下載仍是在頁面打開
直接打開是否顯示正確
對於本機沒有安裝工具的文件是否可以打開，是否能給出正確的提示
對於直接在頁面內打開的內容是否可以顯示正常，頁面美觀性
保存到本地是否能正確顯示
取消下載是否會紀錄下載次數
下載次數是否被正確記錄
後臺沒有發佈的文件是否在前臺能夠找到並下載
後臺設置了下載權限的文件是否能夠被正確看到、是否能夠下載
按鈕
返回按鈕是否回到上一頁面
再補充一些其餘的常見測試點：
圖片上傳後，圖片分辨率的檢查，保證圖片不失真，不變形；
上傳相同名稱的圖片，具體看需求，是對上傳後的圖片進行重命名，仍是不容許同名；
上傳過程當中，是否可重複操做上傳；
出於安全考慮，變種的可執行文件，進行上傳，如.exe.jpg；
出於性能考慮，在服務器存放圖片的目錄查看，上傳後的圖片與原圖片，大小不會發生猛烈上漲；而通常開發會對圖片作適量的壓縮，因此上傳後的圖片通常是等於或者小於原圖片大小的；
上傳文件名測試，檢查不符合文件名規範
上傳文件名類型測試，檢查不一樣文件類型是否支持如：.rar,.mp3,avi等
上傳文件大小測試，檢查不一樣文件規格大小如：0字節文件, 1kb, 200kb, 2mb, 20mb,2g等
上傳文件容錯性測試：如檢查覆蓋同文件操做；
上傳文件異常狀況測試：如硬盤空間不足
上傳文件速率性能測試：檢查上傳不一樣的文件在不一樣的網絡環境響應速度，及系統資源佔用
上傳文件安全性測試：如上傳常見木馬
上傳文件易用性測試：檢查上傳文件操做是否讓用戶易於學習和理解使用等
上傳文件特性測試：若是支持如斷點續傳等一些特性
上傳文件後，檢查是否與源文件一致，包含目錄設置等
上傳文件，是否能打開等
-----------------------------------------------------------
文本框測試點：
1、文本框爲字符型
•必填項非空校驗：
一、必填項未輸入－－程序應提示錯誤；
二、必填項只輸入若干個空格，未輸入其它字符－－程序應提示錯誤；
•字段惟一性校驗：（不是全部字段都做此項校驗，視實際項目狀況而定）
一、新增時輸入重複的字段值－－必須提示友好信息；
二、修改時輸入重複的字段值－－必須提示友好信息；
•字段長度校驗：
一、輸入[最小字符數-1]－－程序應提示錯誤；
二、輸入[最小字符數]－－OK；
三、輸入[最小字符數+1]－－程序應提示錯誤；
四、輸入[最大字符數-1]－－OK；
五、輸入[最大字符數]－－OK；
六、輸入[最大字符數+1]－－程序應提示錯誤；
•字段爲特殊字符校驗：
一、輸入域如對某些字符禁止輸入時，限制是否成功，提示信息是否友好 ；
二、中文、英文、空格，數字，字符，下劃線、單引號 等全部特殊字符的組合 ；
三、全部特殊字符都必須進行測試（!~@#$^&*()_+{}|:「<>?/.,;‘[]\=-`￥……（）--：《》？、。，；’【】、=-· ）
•字段爲特殊代碼校驗：
一、輸入htm代碼：好比」 <font>你好</font>」；－－必須以文本的形式將代碼顯示出來。
二、輸入JavaScript代碼：好比<param name=「MovieWindowWidth」 value=「320」>；－－必須以文本的形式將代碼顯示出來。
•多行文本框輸入：
一、是否容許回車換行 ；
二、保存後再顯示可以保持輸入時的格式 ；
三、僅輸入回車換行，檢查可否正確保存；若能，查看保存結果。若不能，查看是否有正確提示 ；
四、僅輸入空格，檢查可否正確保存；若能，查看保存結果。若不能，查看是否有正確提示 。
2、文本框爲數值型
•邊界值：
一、輸入[最小值-1]－－程序應提示錯誤；
二、輸入[最小值]－－OK；
三、輸入[最大值]－－OK；
四、輸入[最大值+1]－－程序應提示錯誤；
•位數：
一、輸入[限制位數]－－OK；
二、輸入[限制位數+1]－－根據實際項目而定，是否自動四捨五入成限制位數，仍是提示信息；
三、輸入[限制位數-1]－－OK；
•異常值、特殊值：
一、輸入非數值型數據：漢字、字母、字符－－程序應提示錯誤；
二、輸入負數－－根據實際項目而定，若是不容許輸入負數，必須提示友好信息；
三、字段禁止直接輸入非數值型數據時，使用「粘貼」、「拷貝」功能嘗試輸入，並測試可否正常提交保存－－只能使用「粘貼」、「拷貝」方法輸入的特殊字符應沒法保存，並應給出相應提示 ；
四、全角數字和半角數字的狀況－－全角數字不能保存，提示友好信息，半角數字正常保存；
五、首位爲零的數值：如01＝1－－視實際項目狀況而定；
3、文本框爲日期型
•合法性檢查：
一、日輸入[0日]－－程序應提示錯誤；
二、日輸入[1日]－－OK；
三、日輸入[32日]－－程序應提示錯誤；
四、月輸入[一、三、五、七、八、十、12月]、日輸入[31日]－－OK；
五、月輸入[四、六、九、11月]、日輸入[30日]－－OK；
六、月輸入[四、六、九、11月]、日輸入[31日]－－程序應提示錯誤；
七、輸入非閏年,月輸入[2月]、日輸入[28日]，好比2009.2.28－－OK；
八、輸入非閏年,月輸入[2月]、日輸入[29日]，好比2009.2.29－－程序應提示錯誤
九、(閏年)月輸入[2月]、日輸入[29日]，好比2008.2.29－－OK；
十、(閏年)月輸入[2月]、日輸入[30日]，好比2008.2.30－－程序應提示錯誤；
十一、月輸入[0月]－－程序應提示錯誤；
十二、月輸入[1月]－－OK；
1三、月輸入[12月]－－OK；
1四、月輸入[13月] －－程序應提示錯誤；
•格式檢查：
一、不合法格式：2009-0九、 2009-09 -、200-2-2；
二、視具體項目而定是否合法：2009/09/0一、2009.09.01 、2009090一、2009-09-01 ；
•異常值、特殊值：
一、輸入漢字、字母、字符－－程序應提示錯誤；
4、文本框爲時間型
•合法性檢查：
一、時輸入[24時] －－程序應提示錯誤；
二、時輸入[00時] －－OK；
三、分輸入[60分] －－程序應提示錯誤；
四、分輸入[59分] －－OK；
五、分輸入[00分] －－OK；
六、秒輸入[60秒] －－程序應提示錯誤；
七、秒輸入[59秒] －－OK；
八、秒輸入[00秒] －－OK；
•格式檢查：
一、不合法格式：12:30:、 123000；
二、視具體項目而定是否合法：12:30、 1:3:0；
•異常值、特殊值：
一、輸入漢字、字母、字符－－程序應提示錯誤；
二、系統中所涉及時間是否取服務器時間；
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------Hello world----------------------------------------------------
常見功能測試點：
1. 登錄、添加、刪除、查詢模塊是咱們常常遇到的，這些模塊的測試點該如何考慮
1)登錄
① 用戶名和密碼都符合要求(格式上的要求)
② 用戶名和密碼都不符合要求(格式上的要求)
③ 用戶名符合要求，密碼不符合要求(格式上的要求)
④ 密碼符合要求，用戶名不符合要求(格式上的要求)
⑤ 用戶名或密碼爲空
⑥ 數據庫中不存在的用戶名，不存在的密碼
⑦ 數據庫中存在的用戶名，錯誤的密碼
⑧ 數據庫中不存在的用戶名，存在的密碼
⑨ 輸入的數據前存在空格
⑩ 輸入正確的用戶名密碼之後按[enter]是否能登錄
2) 添加
① 要添加的數據項均合理，檢查數據庫中是否添加了相應的數據
② 留出一個必填數據爲空
③ 按照邊界值等價類設計測試用例的原則設計其餘輸入項的測試用例
④ 不符合要求的地方要有錯誤提示
⑤ 是否支持table鍵
⑥ 按enter是否能保存
⑦ 若提示不能保存，也要察看數據庫裏是否多了一條數據
3) 刪除
① 刪除一個數據庫中存在的數據，而後查看數據庫中是否刪除
② 刪除一個數據庫中並不存在的數據，看書否有錯誤提示，而且數據庫中沒有數據被刪除
③ 輸入一個格式錯誤的數據，看是否有錯誤提示，而且數據庫中沒有數據被刪除。
④ 輸入的正確數據前加空格，看是否能正確刪除數據
⑤ 什麼也不輸入
⑥ 是否指出table鍵
⑦ 是否支持enter鍵
4)查詢
精確查詢：
① 輸入的查詢條件爲數據庫中存在的數據，看是否能正確地查出相應得數據
② 輸入正確的查詢條件之前加上空格，看是否能正確地查出相應的數據
③ 輸入格式或範圍不符合要求的數據，看是否有錯誤提示
④ 輸入數據庫中不存在的數據
⑤ 不輸入任何數據
⑥ 是否支持table鍵
⑦ 是否支持enter鍵
模糊查詢：
在精確查詢的基礎上加上如下一點
① 輸入一些字符，看是否能查出數據庫中全部的相關信息
2.設計功能測試用例
文本框、按鈕等控件測試
一、文本框的測試
如何對文本框進行測試
a,輸入正常的字母或數字。
b,輸入已存在的文件的名稱;
c,輸入超長字符。例如在「名稱」框中輸入超過容許邊界個數的字符，假設最多255個字符，嘗試輸入 256個字符，檢查程序可否正確處理;
d,輸入默認值，空白，空格;
e,若只容許輸入字母，嘗試輸入數字;反之;嘗試輸入字母;
f,利用複製，粘貼等操做強制輸入程序不容許的輸入數據;
g,輸入特殊字符集，例如，NUL及\n等;
h,輸入超過文本框長度的字符或文本，檢查所輸入的內容是否正常顯示;
i,輸入不符合格式的數據，檢查程序是否正常校驗，如，程序要求輸入年月日格式爲yy/mm/dd，實際輸入yyyy/mm/dd，程序應該給出錯誤提示
在測試過程當中所用到的測試方法：
1,輸入非法數據;
2,輸入默認值;
3,輸入特殊字符集;
4,輸入使緩衝區溢出的數據;
5,輸入相同的文件名;
二、命令按鈕控件的測試
a,點擊按鈕正確響應操做。如，單擊肯定，正確執行操做;單擊取消，退出窗口;
b,對非法的輸入或操做給出足夠的提示說明，如，輸入月工做天數爲32時，單擊」肯定「後系統應提示:天數不能大於31;
c,對可能形成數據沒法恢復的操做必須給出確認信息，給用戶放棄選擇的機會;
三、單選按鈕控件的測試
a,一組單選按鈕不能同時選中，只能選中一個。
b,逐一執行每一個單選按鈕的功能。分別選擇了「男」「女」後，保存到數據庫的數據應該相應的分別爲「男」「女」;
c,一組執行同一功能的單選按鈕在初始狀態時必須有一個被默認選中，不能同時爲空;
四、up-down控件文本框的測試
a,直接輸入數字或用上下箭頭控制，如，在「數目」中直接輸入10，或者單擊向上的箭頭，使數目變爲10;
b,利用上下箭頭控制數字的自動循環，如，當最多數字爲253時，單擊向上箭頭，數目自動變爲1;反之亦適用;
c,直接輸入超邊界值，系統應該提示從新輸入;
d,輸入默認值，空白。如，「插入」數目爲默認值，點擊「肯定」;或，刪除默認值，使內容爲空，單擊「肯定」進行測試;
e,輸入字符。此時系統應提示輸入有誤。
五、組合列表框的測試
a,條目內容正確，其詳細條目內容能夠根據需求說明肯定;
b,逐一執行列表框中每一個條目的功能;
c,檢查可否向組合列表框輸入數據;
六、複選框的測試
a,多個複選框能夠被同時選中;
b,多個複選框能夠被部分選中;
c,多個複選框能夠都不被選中;
d,逐一執行每一個複選框的功能;
七、列表框控件的測試
a,條目內容正確;同組合列表框相似，根據需求說明書肯定列表的各項內容正確，沒有丟失或錯誤;
b,列表框的內容較多時要使用滾動條;
c,列表框容許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標選中多項條目的狀況;
八、滾動條控件的測試
要注意一下幾點：
a,滾動條的長度根據顯示信息的長度或寬度及時變換，這樣有利於用戶瞭解顯示信息的位置和百分比，如，word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應處於中間;
b,拖動滾動條，檢查屏幕刷新狀況，並查看是否有亂碼;
c,單擊滾動條;
d,用滾輪控制滾動條;
e,滾動條的上下按鈕。
九、各類控件在窗體中混和使用時的測試
a,控件間的相互做用;
b,tab鍵的順序，通常是從上到下，從左到右;
c,熱鍵的使用，逐一測試;
d,enter鍵和esc鍵的使用;
在測試中，應遵循由簡入繁的原則，先進行單個控件功能的測試，確保實現無誤後，再進行多個控件的的功能組合的測試。
ps:密碼輸入框測試時要特別注意進行字母大寫輸入的測試。
查找替換操做
案例演示:打開word中的"替換"對話框
測試本功能有經過測試和失敗測試兩種狀況
經過測試:
1,輸入內容直接查找,或查找所有
2,在組合框中尋找已經查找過的內容,再次查找並確認文檔的內容正確,如,已經查找過"測試用例",再次進入不用從新輸入查找內容,直接在文檔中搜尋就能夠.
失敗測試:
1,輸入過長或太短的查詢字符串.如,假設查詢的字符串長度爲1到255,那麼輸入0,1,2,256,255和254進行測試;
2,輸入特殊字符集,如,在word中.^g表明圖片,^表明分欄符,能夠輸入這類特殊字符測試;
替換測試大致相同.
關於編輯操做窗口的功能測試的用例:
1,關閉查找替換窗口.不執行任何操做,直接退出;
2,附件和選項測試.假如,設定"精確搜尋","向後"搜索等附件選項等等來測試;
3,控件間的相互做用.如,搜尋內容爲空時,按鈕"搜尋所有","搜尋","所有替換","替換"都爲灰色.
4,熱鍵, Tab鍵.回車鍵的使用.
插入操做
1)插入文件
測試的狀況
a,插入文件;
b,插入圖像;
c,在文檔中插入文檔自己;
d,移除插入的源文件;
e,更換插入的源文件的內容;
2)連接文件
測試方法:
a,插入連接文件;
b,在文檔中連接文檔自己;
c,移除插入的源文件;
d,更換插入的源文件的內容.
3)插入對象
要測試的內容
a,插入程序容許的對象,如,在word中插入excel工做表;
b,修改所插入對象的內容.插入的對象仍能正確顯示;
c,卸載生成插入對象的程序,如,在word中插入excel工做表後卸載excel,工做表仍正常使用.
編輯操做
編輯操做包括剪切,複製,粘貼操做.
測試剪切操做的方法
a,對文本,文本框,圖文框進行剪切;
b,剪切圖像
c,文本圖像混合剪切
複製操做方法與剪切相似.
測試時,主要是對粘貼操做的測試,方法是:
a,粘貼剪切的文本,文本框及圖文框;
b,粘貼所剪切的圖像;
c,剪切後,在不一樣的程序中粘貼
d,屢次粘貼同一內容,如,剪切後,在程序中連續粘貼3次;
e,利用粘貼操做強制輸入程序所不容許輸入的數據.
3.界面測試用例的設計方法
1)窗體
測試窗體的方法:
a,窗體大小,大小要合適,控件佈局合理;
b,移動窗體.快速或慢速移動窗體,背景及窗體自己刷新必須正確;
c,縮放窗體,窗體上的控件應隨窗體的大小變化而變化;
d,顯示分辨率.必須在不一樣的分辨率的狀況下測試程序的顯示是否正常;
進行測試時還要注意狀態欄是否顯示正確;工具欄的圖標執行操做是否有效,是否與菜單懶中圖標顯示一致;錯誤信息內容是否正確,無錯別字,且明確等等;
2)控件
測試方法:
a,窗體或控件的字體和大小要一致;
b,注意全角,半角混合
c,無中英文混合.
3)菜單
進行測試時要注意
a,選擇菜單是否能夠正常工做,並與實際執行內容一致;
b,是否有錯別字:
c,快捷鍵是否重複;
d,熱鍵是否重複;
e,快捷鍵與熱鍵操做是否有效
f,是否存在中英文混合
g,菜單要與語境相關,如,不一樣權限的用戶登錄一個應用程序,不一樣級別的用戶能夠看到不一樣級別的菜單並使用不一樣級別的功能;
h,鼠標右鍵快捷菜單
4)特殊屬性
1,安裝界面應有公司介紹或產品介紹,有公司的圖標
2,主界面及大多數界面最好有公司圖標
3,選擇"幫助"->"關於"命令,應 看見相關版權和產品信息
------------恢復內容結束------------
- 1. 功能測試與非功能測試
- 2. 功能測試基礎（一）
- 3. 功能測試
- 4. RSpec功能測試
- 5. Selenium功能測試
- 6. 測試Mybash功能
- 7. 功能測試點
- 8. 非功能測試
- 9. webbench功能測試
- 10. 功能測試之轉帳功能如何進行測試
- 更多相關文章...
- • Maven 構建 & 項目測試 - Maven教程
- • MySQL 5.7的新特性（新功能） - MySQL教程
- • RxJava操作符（一）Creating Observables
- • Kotlin學習（一）基本語法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 功能測試與非功能測試
- 2. 功能測試基礎（一）
- 3. 功能測試
- 4. RSpec功能測試
- 5. Selenium功能測試
- 6. 測試Mybash功能
- 7. 功能測試點
- 8. 非功能測試
- 9. webbench功能測試
- 10. 功能測試之轉帳功能如何進行測試