Web測試點
1、字元型輸入框： （1）字元型輸入框：英文全形、英文半形、數字、空或者空格、特殊字元“~！@#￥%……&*？[]{}”特別要注意單引號和&符號。禁止直接輸入特殊字元時，使用“貼上、拷貝”功能嘗試輸入。 （2）長度檢查：最小長度、最大長度、最小長度-1、最大長度+1、輸入超工字元比如把整個文章拷貝過去。 （3）空格檢查：輸入的字元間有空格、字元前有空格、字元後有空格、字元前後有空格 （4）多行文字框輸入：允許回車換行、儲存後再顯示能夠儲存輸入的格式、僅輸入回車換行，檢查能否正確儲存（若能，檢查儲存結果，若不能，檢視是否有正常提示）、 （5） 安全性檢查：輸入特殊字串（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>）、 輸入指令碼函式(<script>alert("abc")</script>)、 doucment.write("abc")、<b>hello</b>） 2、數值型輸入框： （1）邊界值：最大值、最小值、最大值+1、最小值-1 （2）位數：最小位數、最大位數、最小位數-1最大位數+1、輸入超長值、輸入整數 （3） 異常值、特殊字元：輸入空白（NULL）、空格或"
Ø 功能相關性：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確，常見的情況是，增加某個資料記錄以後，如果該資料記錄某個欄位內容較長，可能會在查詢的時候讓資料列表變形。
Ø 資料相關性：下來列表預設值檢查，下來列表值檢查，如果某個列表的資料項依賴於其他模組中的資料，同樣需要檢查，比如，某個資料如果被禁用了，可能在引用該資料項的列表中不可見。
3. 檢查按鈕的功能是否正確：如新建、編輯、刪除、關閉、返回、儲存、匯入，上一頁，下一頁，頁面跳轉，重置等功能是否正確。常見的錯誤會出現在重置按鈕上，表現為功能失效。
4. 字串長度檢查: 輸入超出需求所說明的字串長度的內容, 看系統是否檢查字串長度。還要檢查需求規定的字串長度是否是正確的，有時候會出現，需求規定的字串長度太短而無法輸入業務資料。
5. 字元型別檢查: 在應該輸入指定型別的內容的地方輸入其他型別的內容(如在應該輸入整型的地方輸入其他字元型別),看系統是否檢查字元型別。
6. 標點符號檢查: 輸入內容包括各種標點符號,特別是空格,各種引號,回車鍵。看系統處理是否正確。常見的錯誤是系統對空格的處理，可能新增的時候，將空格當作一個字元，而在查詢的時候空格被遮蔽，導致無法查詢到新增的內容。
7．特殊字元檢查：輸入特殊符號，如@、#、$、%、!等，看系統處理是否正確。常見的錯誤是出現在% ‘ \ 這幾個特殊字元
8. 中文字元處理: 在可以輸入中、英文的系統輸入中文,看會否出現亂碼或出錯。
9. 檢查資訊的完整性: 在檢視資訊和更新資訊時,檢視所填寫的資訊是不是全部更新,更新資訊和新增資訊是否一致。要注意檢查的時候每個欄位都應該檢查，有時候，會出現部分欄位更新了而個別欄位沒有更新的情況。
10. 資訊重複: 在一些需要命名,且名字應該唯一的資訊輸入重複的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的前後輸入空格,系統是否作出正確處理。
11. 檢查刪除功能:在一些可以一次刪除多個資訊的地方,不選擇任何資訊,按“delete”,看系統如何處理,會否出錯;然後選擇一個和多個資訊,進行刪除, 看是否正確處理。如果有多頁，翻頁選，看系統是否都正確刪除，並且要注意，刪除的時候是否有提示，讓使用者能夠更正錯誤，不誤刪除。
12. 檢查新增和修改是否一致: 檢查新增和修改資訊的要求是否一致,例如新增要求必填的項,修改也應該必填;新增規定為整型的項,修改也必須為整型.
13. 檢查修改重名:修改時把不能重名的項改為已存在的內容,看會否處理,報錯.同時,也要注意,會不會報和自己重名的錯.
14. 重複提交表單：一條已經成功提交的紀錄，返回後再提交，看看系統是否做了處理。對於WEB系統來說，可以通過瀏覽器返回鍵或者系統提供的返回功能。
15. 檢查多次使用返回鍵的情況: 在有返回鍵的地方,返回到原來頁面,重複多次，看會否出錯。
16. 搜尋檢查: 有搜尋功能的地方輸入系統存在和不存在的內容,看搜尋結果是否正確.如果可以輸入多個搜尋條件,可以同時新增合理和不合理的條件,看系統處理是否正確，搜尋的時候同樣要注意特殊字元，某些系統會在輸入特殊字元的時候，將系統中所有的資訊都搜尋到。
17. 輸入資訊位置: 注意在游標停留的地方輸入資訊時,游標和所輸入的資訊會否跳到別的地方。
18. 上傳下載檔案檢查：上傳下載檔案的功能是否實現，上傳檔案是否能開啟。對上傳檔案的格式有何規定，系統是否有解釋資訊，並檢查系統是否能夠做到。下載檔案 能否開啟或者儲存，下載的檔案是否有格式要求，如需要特殊工具才可以開啟等。上傳檔案測試同時應該測試，如果將不能上傳的檔案字尾名修改為可以上傳檔案的 字尾名，看是否能夠上傳成功，並且，上傳檔案後，重新修改，看上傳的檔案是否存在。
19. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示資訊，如在必填項前加“*”；對必填項提示返回後，焦點是否會自動定位到必填項。
20. 快捷鍵檢查：是否支援常用快捷鍵，如Ctrl+C、 Ctrl+V、 Backspace等，對一些不允許輸入資訊的欄位，如選人，選日期對快捷方式是否也做了限制。
21. 回車鍵檢查: 在輸入結束後直接按回車鍵,看系統處理如何,會否報錯。這個地方很有可能會出現錯誤。
22．重新整理鍵檢查：在Web系統中，使用瀏覽器的重新整理鍵，看系統處理如何，會否報錯。
23．回退鍵檢查：在Web系統中，使用瀏覽器的回退鍵，看系統處理如何，會否報錯。對於需要使用者驗證的系統，在退出登入後，使用回退鍵，看系統處理如何；多次使用回退鍵，多次使用前進鍵，看系統如何處理。
24．直接URL連結檢查：在Web系統中，直接輸入各功能頁面的URL地址，看系統如何處理，對於需要使用者驗證的系統更為重要。如果系統安全性設計的不好，直接輸入各功能頁面的URL地址，很有可能會正常開啟頁面。
25．空格檢查：在輸入資訊項中，輸入一個或連串空格，檢視系統如何處理。如對於要求輸入整型、符點型變數的項中，輸入空格，既不是空值，又不是標準輸入。
26．輸入法半形全形檢查：在輸入資訊項中，輸入半形或全形的資訊，檢視系統如何處理。如對於要求輸入符點型資料的項中，輸入全形的小數點（“。”或“．”，如４．５）；輸入全形的空格等。
27．密碼檢查：一些系統的加密方法採用對字元Ascii碼移位的方式，處理密碼加密相對較為簡單，且安全性較高，對於區域網系統來說，此種方式完全可以 起到加密的作用，但同時，會造成一些問題，即大於128的Ascii對應的字元在解密時無法解析，嘗試使用“uvwxyz”等一些碼值較大的字元作為密 碼，同時，密碼儘可能的長，如17位密碼等，造成加密後的密碼出現無法解析的字元。
28．使用者檢查：任何一個系統，都有各類不同的使用者，同樣具有一個或多個管理員使用者，檢查各個管理員之間是否可以相互管理，編輯、刪除管理員使用者。同時， 對於一般使用者，嘗試刪除，並重建同名的使用者，檢查該使用者其他資訊是否重現。同樣，提供登出功能的系統，此使用者再次註冊時，是否作為一個新的使用者。而且還要 檢查該使用者的有效日期，過了有效日期的使用者是不能登入系統的。容易出現錯誤的情況是，可能有使用者管理許可權的非超級管理員，能夠修改超級管理員的許可權。
29．系統資料檢查：這是功能測試最重要的，如果系統資料計算不正確，那麼功能測試肯定是通不過的。資料檢查根據不同的系統，方法不同。對於業務管理平臺，資料隨業務過程、狀態的變化保持正確，不能因為某個過程出現垃圾資料，也不能因為某個過程而丟失資料。
30．系統可恢復性檢查：以各種方式把系統搞癱，測試系統是否可正常迅速恢復。
31．確認提示檢查：系統中的更新、刪除操作，是否提示使用者確認更新或刪除，操作是否可以回退（即是否可以選擇取消操作），提示資訊是否準確。事前或事後提示，對於Update或Delete操作，要求進行事前提示。
32．資料注入檢查：資料注入主要是對資料庫的注入，通過輸入一些特殊的字元，如“’”，“/”，“-”等或字元組合，完成對SQL語句的破壞，造成系統 查詢、插入、刪除操作的SQL因為這些字元而改變原來的意圖。如select * from table where id = ‘ ’ and name = ‘ ’，通過在id輸入框中輸入“12’-”，會造成查詢語句把name條件註釋掉，而只查詢id=12的記錄。同樣，對於update和delete的操 作，可能會造成誤刪除資料。當然還有其它一些SQL注入方法，具體可以參考《SQL應用高階SQL注入.doc》，很多程式都是基於頁面對輸入字元進行控 制的，可以嘗試跳過介面直接向資料庫中插入資料，比如用Jmeter，來完成資料注入檢查。
33．重新整理檢查：web系統中的WebForm控制元件實時重新整理功能，在系統應用中有利有弊，給系統的效能帶來較大的影響。測試過程中檢測重新整理功能對系統或應 用造成的影響（白屏），檢查控制元件是否迴歸預設初始值，檢查是否對系統的效能產生較大影響（如每次重新整理都連線資料庫查詢等）。
34．事務檢查：對於事務性操作，斷開網路或關閉程式來中斷操作，事務是否回滾。
35．時間日期檢查：時間、日期驗證是每個系統都必須的，如2006-2-29、2006-6-31等錯誤日期，同時，對於管理、財務類系統，每年的1月 與前一年的12月（同理，每年的第1季度與前一年的第4季度）。另外，對於日期、時間格式的驗證，如2006年2月28日、2006-2-28、 20060228等。日期檢查還要檢查日期範圍是否符合實際的業務，對於不符合時間業務的日期，系統是否會有提示或者有限制
36．多瀏覽器驗證：越來越多的各類瀏覽器的出現，使用者訪問Web程式不再單單依賴於Microsoft Internet Explorer，而是有了更多的選擇：Maxthon、Firefox、Tencent Traveler等，考慮使用多種瀏覽器訪問系統，驗證效果。
37．安裝測試：對於C/S架構的系統，安裝程式的測試是一個重要方面，安裝程式自動化程度、安裝選項和設定（驗證各種方案是否都能正常安裝）、安裝過程中斷測試、安裝順序測試（分散式系統）、修復安裝及解除安裝測試。
38．文件測試：主要是對使用者使用手冊、產品手冊進行測試，校驗是否描述正確、完整，是否與當前系統版本對照，是否易理解，是否二義性等。
39．測試資料檢查：事實告訴我們，測試資料比程式碼更有可能是錯的，因此，當測試結果顯示有錯誤發生的時候，懷疑程式碼錯誤前要先對測試資料檢查一遍。
40．請讓我的機器來執行：在某些專案中，出現一個病態的問題：系統沒有問題呀，它在我的機器上是能夠通過的。這就說明了其中存在著和環境相關的BUG。 “是否所有的一切都受到了版本控制工具的管理？”、“本機的開發環境和伺服器的環境是否一樣？”、“這裡是否存在一個真正的BUG，只不過是在其他的機器 裡偶然出現？”。所有的測試必須在所有系統要求的機器上執行通過，否則的話，程式碼就可能存在問題。
41．Ajax技術的應用：Ajax有很多優點，但也有很多缺點，如果利用優點、避免缺點，是我們對新的Web2.0應用的一個挑戰。而Ajax的應用最 直接的問題就是使用者體驗，使用者體驗的效果直接關係到是否使用Ajax技術。“會做，並不意味著應該做、必須做”，這就是對Ajax技術的很重要的註解。
42．Ajax技術的應用：Ajax採用非同步呼叫的機制實現頁面的部分重新整理功能，非同步呼叫存在異常中斷的可能，嘗試各種方法異常中斷非同步的資料呼叫，檢視是否出現問題。在這裡遇到的一個問題就是對日期控制元件的操作，已經如果頁面資料較多的時候的重新整理。
43．指令碼錯誤：隨著Ajax、IFrame等非同步呼叫技術的發展，Javascrīpt技術也越來越受到開發人員的重視，但Javascrīpt存在除錯困難、各瀏覽器存在可能不相容等問題，因此在Web系統中，可能會出現指令碼錯誤。同時，指令碼錯誤造成的後果可大、可小 十二、介面和易用性測試
1、風格、樣式、顏色是否協調
2、介面佈局是否整齊、協調（保證全部顯示出來的，儘量不要使用滾動條
3、介面操作、標題描述是否恰當（描述有歧義、注意是否有錯別字）
4、操作是否符合人們的常規習慣（有沒有把相似的功能的控制元件放在一起，方便操作）
5、提示介面是否符合規範（不應該顯示英文的cancel、ok，應該顯示中文的確定等）
6、介面中各個控制元件是否對齊
7、日期控制元件是否可編輯
8、日期控制元件的長度是否合理，以修改時可以把時間全部顯示出來為準
9、查詢結果列表列寬是否合理、標籤描述是否合理
10、查詢結果列表太寬沒有橫向滾動提示
11、對於資訊比較長的文字，文字框有沒有提供自動豎直滾動條
12、資料錄入控制元件是否方便
13、有沒有支援Tab鍵，鍵的順序要有條理，不亂跳
14、有沒有提供相關的熱鍵
15、控制元件的提示語描述是否正確
16、模組呼叫是否統一，相同的模組是否呼叫同一個介面
17、用滾動條移動頁面時，頁面的控制元件是否顯示正常
18、日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
19、頁面是否有多餘按鈕或標籤
20、視窗標題或圖示是否與選單欄的統一
21、視窗的最大化、最小化是否能正確切換
22、對於正常的功能，使用者可以不必閱讀使用者手冊就能使用
23、執行風險操作時，有確認、刪除等提示嗎
24、操作順序是否合理
25、正確性檢查：檢查頁面上的form, button, table, header, footer,提示資訊，還有其他文字拼寫，句子的語法等是否正確。
26、系統應該在使用者執行錯誤的操作之前提出警告，提示資訊.
27、頁面解析度檢查，在各種解析度瀏覽系統檢查系統介面友好性。
28、合理性檢查：做delete, update, add, cancel, back等操作後，檢視資訊回到的頁面是否合理。
29、檢查本地化是否通過：英文版不應該有中文資訊，英文翻譯準確，專業。 十三、相容性測試
相容性測試不只是指介面在不同作業系統或瀏覽器下的相容，有些功能方面的測試，也要考慮到相容性，
包括作業系統相容和應用軟體相容，可能還包括硬體相容
比如涉及到ajax、jquery、javascript等技術的，都要考慮到不同瀏覽器下的相容性問題。 十四、連結測試
主要是保證連結的可用性和正確性，它也是網站測試中比較重要的一個方面。
可以使用特定的工具如XENU來進行連結測試。
1導航測試
導航描述了使用者在一個頁面內操作的方式，在不同的使用者介面控制之間，例如按鈕、對話方塊、列表和視窗等；或在不同的連線頁面之間。通過考慮下列問題，可以決 定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜尋引擎或其他的導航幫助？
在一個頁面上放太多的資訊往往起到與預期相反的效果。Web應用系統的使用者趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的資訊， 如果沒有，就會很快地離開。很少有使用者願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要儘可能地準確。
導航的另一個重要方面是Web應用系統的頁面結構、導航、選單、連線的風格是否一致。確保使用者憑直覺就知道Web應用系統裡面是否還有內容，內容在什麼地方。
Web應用系統的層次一旦決定，就要著手測試使用者導航功能，讓終端使用者參與這種測試，效果將更加明顯。
2圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字型、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都連結到某個具體的頁面。
（2）驗證所有頁面字型的風格是否一致。
（3）背景顏色應該與字型顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮，最好能使圖片的大小減小到30k以下
（5）最後，需要驗證的是文字迴繞是否正確。如果說明文字指向右邊的圖片，應該確保該圖片出現在右邊。不要因為使用圖片而使視窗和段落排列古怪或者出現孤行。
通常來說，使用少許或儘量不使用背景是個不錯的選擇。如果您想用背景，那麼最好使用單色的，和導航條一起放在頁面的左邊。另外，圖案和圖片可能會轉移使用者的注意力。 十五、業務流程測試（主要功能測試）
業務流程，一般會涉及到多個模組的資料，所以在對業務流程測試時，首先要保證單個模組功能的正確性，其次就要對各個模組間傳遞的資料進行測試，這往往是容易出現問題的地方，測試時一定要設計不同的資料進行測試。
十六、安全性測試
（1）SQL注入（比如登陸頁面）
（2）XSS跨網站指令碼攻擊：程式或資料庫沒有對一些特殊字元進行過濾或處理，導致使用者所輸入的一些破壞性的指令碼語句能夠直接寫進資料庫中，瀏覽器會直接執行這些指令碼語句，破壞網站的正常顯示，或網站使用者的資訊被盜,構造指令碼語句時，要保證指令碼的完整性。
document.write("abc")
<script>alter("abc")</script>
（3）URL地址後面隨便輸入一些符號，並儘量是動態引數靠後
（4）驗證碼更新問題
（5）現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的使用者名稱和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
（6）Web應用系統是否有超時的限制，也就是說，使用者登陸後在一定時間內（例如15分鐘）沒有點選任何頁面，是否需要重新登陸才能正常使用。
（7）為了保證Web應用系統的安全性，日誌檔案是至關重要的。需要測試相關資訊是否寫進了日誌檔案、是否可追蹤。
（8）當使用了安**接字時，還要測試加密是否正確，檢查資訊的完整性。
（9）伺服器端的指令碼常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯指令碼的問題。
十七、效能測試
1連線速度測試
使用者連線到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程式時，使用者可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鐘），使用者就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，使用者可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連線速度太慢，還可能引起資料丟失，使使用者得不到真實的頁面。
2負載測試
負載測試是為了測量Web系統在某一負載級別上的效能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的使用者數量， 也可以是線上資料處理的數量。例如：Web應用系統能允許多少個使用者同時線上？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量使用者對同 一個頁面的請求？
3壓力測試
負載測試應該安排在Web系統釋出以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是專案組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的資料負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。
壓力測試的區域包括表單、登陸和其他資訊傳輸頁面等。
備註：
1、負載/壓力測試應該關注什麼
測試需要驗證系統能否在同一時間響應大量的使用者，在使用者傳送大量資料的時候能否響應，系統能否長時間執行。可訪問性對使用者來說是極其重要的。如果使用者得到 “系統忙”的資訊，他們可能放棄，並轉向競爭對手。系統檢測不僅要使使用者能夠正常訪問站點，在很多情況下，可能會有黑客試圖通過傳送大量資料包來攻擊服務 器。出於安全的原因，測試人員應該知道當系統過載時，需要採取哪些措施，而不是簡單地提升系統性能。
1）瞬間訪問高峰
如果您的站點用於公佈彩票的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內能夠響應上百萬的請求。負載測試工具能夠模擬X個使用者同時訪問測試站點。
2）每個使用者傳送大量資料
網上書店的多數使用者可能只訂購1-5書，但是大學書店可能會訂購5000本有關心理學介紹的課本?或者一個祖母為她的50個兒孫購買聖誕禮物(當然每個孩子都有自己的郵件地址)系統能處理單個使用者的大量資料嗎?
3）長時間的使用
如果站點用於處理鮮花訂單，那麼至少希望它在母親節前的一週內能持續執行。如果站點提供基於web的email服務，那麼點最好能持續執行幾個月，甚至幾 年。可能需要使用自動測試工具來完成這種型別的測試，因為很難通過手工完成這些測試。你可以想象組織100個人同時點選某個站點。但是同時組織 100000個人呢。通常，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。而且，測試工具安裝完成之後，再次使用的時候，只要點選幾下。
採取措施：採用效能測試工具WAS、ACT，LR等協助進行測試
十八、測試中應該注意的其他情況
1、在測試時，與網路有關的步驟或者模組必須考慮到斷網的情況
2、每個頁面都有相應的Title，不能為空，或者顯示“無標題頁”
3、在測試的時候要考慮到頁面出現滾動條時，滾動條上下滾動時，頁面是否正常
4、URL不區分大小寫，大小寫不敏感
5、、對於電子商務網站，當用戶併發購買數量大於庫存的數量時，系統如何處理
6、測試資料避免單純輸入“123”、“abc“之類的，讓測試資料儘量接近實際
7、進行測試時，儘量不要用超級管理員進行測試，用新建的使用者進行測試。測試人員儘量不要使用同一個使用者進行測試
8、提示資訊：提示資訊是否完整、正確、詳細
9、幫助資訊：是否提供幫助資訊，幫助資訊的表現形式（頁面文字、提示資訊、幫助檔案），幫助資訊是否正確、詳細
10、可擴充套件性：是否由升級的餘地，是否保留了介面
11、穩定性：執行所需的軟硬體配置，佔用資源情況，出現問題時的容錯性，對資料的保護
12、執行速度：執行的快慢，頻寬佔用情況
相關推薦
web測試點和app測試點
web測試點：一、輸入框1、字元型輸入框：（1）字元型輸入框：英文全形、英文半形、數字、空或者空格、特殊字“~！@#￥%……&*？[]{}”特別要注意單引號和&符號。禁止直接輸入特殊字元時，使用“粘貼、拷貝”功能嘗試輸入。（2）長度檢查：最小長度、最大長度、最
WEB 測試點
一、輸入框 1、字元型輸入框： （1）字元型輸入框：英文全形、英文半形、數字、空或者空格、特殊字元“~！@#￥%……&*？[]{}”特別要注意單引號和&符號。禁止直接輸入特殊字元時，使用“貼上、拷貝”功能嘗試輸入。 （2）長度檢查：最小長度、最大長度
Web測試點
一、輸入框1、字元型輸入框： （1）字元型輸入框：英文全形、英文半形、數字、空或者空格、特殊字元“~！@#￥%……&*？[]{}”特別要注意單引號和&符號。禁止直接輸入特殊字元時，使用“貼上、拷貝”功能嘗試輸入。 （2）長度檢查：最小長度、最大長度、最小長度
Web測試常用測試點
1.相容性測試：瀏覽器（PC端）（注意瀏覽器的相容模式和疾速模式）：IE瀏覽器，Chrome，Firefox，360安全瀏覽器，360疾速瀏覽器，搜狗瀏覽器，QQ瀏覽器，百度瀏覽器，獵豹瀏覽器瀏覽器（移
web測試的測試點
總結，總結，新的一年開始總結下以前 1.關於web登入的操作 快捷鍵的使用是否正常： 1. TAB 鍵的使用是否正確 2.上下左右鍵是否正確 3.介面如果支援 ESC鍵 看是否正常的工作 3.ENTER 鍵的使用是否正確切換時是否正常。 佈局美感 介面的佈局
Web測試的常見測試點
Web測試是常見的測試場景，下面從頁面，頁面元素，功能，提示資訊，容錯性，許可權，鍵盤操作部分講述常見的測試點。1.頁面部分（1）頁面清單是否完整（是否已經將所需要的頁面全部列出來了）（2）頁面是否顯示（在不同解析度下頁面是否存在，在不同瀏覽器版本中頁面是否顯示）（3）頁面在
web 表單提交按鈕的測試點
軟體測試交流群，歡迎測試的大蝦，新人加入本群，一起探討測試技術的學習，群裡面也有很多資料，656721740web表單中的提交按鈕的測試點：在提交前需要理解清楚的點：1、表單中哪些欄位是必填項2、表單中欄位內容的限制：非空、重複、長度、特殊字元，空格、以及一些和業務相關的約
web頁面輸入框測試點
如何測試一個WEB的輸入框？1、首先考慮是一個文字輸入框還是數值型的文字輸入框文字輸入框測試點：1、重複2、空 也就是不填寫是否支援2、長度：例如支援100字元， 那需要測試100字元、101字元、100字元後輸入一個漢字的情況， 最大長度的顯示是否正常3、哪些是支援的字元型
WEB 表格測試點
Web頁面的表格測試點： 1、表格列名 2、表格翻頁、表格跳轉到多少頁、最後一頁、首頁 3、表格每頁顯示的資料， 資料的排序 4、表格無資料 5、表格支援的最大資料量 6、表格中資料內容超長時，顯示是否正常 7、匯出 ：正常情況、無資料、最大的資料規格 8、瀏覽器的相容性
電梯的測試點
測試 同時 小時 按鍵 對比 適用於 空間 pan 穩定 兩部電梯的測試用例 界面測試： 外觀（裏面、外面）美觀性 電梯空間尺寸是否和設計尺寸一致 按鈕是否清晰和易懂 顯示樓層的顯示屏是否安裝 是否聯系外界的電話、緊急電話 設備檢測說明書 安全規範說明書 燈 標識的承重和
app測試點-1
回滾 自動創建 不可預知 可用 錯誤 命令 智能終端 圖片 類型 一、安全測試 1.軟件權限 1）扣費風險：包括短信、撥打電話、連接網絡等。 2）隱私泄露風險：包括訪問手機信息、訪問聯系人信息等。 3）對App的輸入有效性校驗、認證、授權、數據加密等方面進行檢測 4）限制
一個支付流程要考慮到哪些測試點？
詳細 測試用例 建議 你們 link lan 網銀 驗證碼 設計 1.從買家選擇支付方式開始，選擇網上銀行或者信用卡支付，一直到支付結束，這個過程要考慮到哪些測試點？ 卡與帳號一致與否，帳號與驗證碼一致與否，扣款金額與應付金額是否一致，扣款帳號與應扣款帳號是否一致等等
有關交易的性能測試點
異常 執行 處理 正常 檢測 都在 內存泄露 mil 宕機 有關交易的性能測試點 1.交易結果(Load Test Summary) a.測試並發用戶數 b.測試的持續時間 c.交易成功個數 d.交易成功率 以上都在交易執行結果報告中 2.響應時間(Response Tim
移動端應用基礎測試點
分辨 包括 並行 其它 ui測試 可能 信息 風格 文字 這是測試人員入門需要掌握的知識，現在社會上還沒有開設測試相關專業的課程，所以如果你要做測試，你去面試的時候，最起碼要知道這個工作是做什麽的（什麽~點點點，好像也沒錯） 這個工作的流程首先是你需要知道你做什麽，你要測試
H5頁面的基本測試點
使用 用戶體驗 family 頁面請求 出現 基本 font 選擇 web 優勢： H5可以跨平臺使用，開發成本相對較低 H5可隨時上線就更新版本，適合快速叠代 H5可以輕量的觸達用戶，提供更便捷的服務 在微信入口或者瀏覽器上，用戶只需點開鏈接就可以
購物車測試點
png 點擊 nbsp style 結果 spa .com 其中 添加 現在做事兒都流行套路，寫測試用例也有套路。首先得了解需求，然後可以從這些方面入手：界面測試、功能測試、兼容性測試、易用性測試、性能測試，最後根據測試用例模版編寫測試用例。測試用例字段一般
APP測試流程和測試點
軟硬件 定位 硬件 pst 消息推送 訪問 業務 安全 目錄結構 1 APP測試基本流程 1.1流程圖 1.2測試周期 測試周期可按項目的開發周期來確定測試時間，一般測試時間為兩三周（即15個工作日），根據項目情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管確
app版本升級的測試點
新的 存在 關閉按鈕 新版 應用設置 適用於 設置 div 個人 移動端版本更新升級是一個比較重要的功能點，主要分為強制更新和非強制更新。 1.強制更新需要測試的點有： 1）強制升級是否可以升級成功 從老版本的包升級到新版版的包是否可以升級成功。 2
app的安裝與卸載測試點
處理 and 沒有 需要 spa ron OS body 適合 安裝 1）軟件在不同操作系統（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 、Windows Phone ）下安裝是否正常。 2）軟件安裝後的是否能夠正常運行
App測試流程及測試點
開始 很多 邏輯 離線 推送消息 錯誤 退出app 框架 交換 1 APP測試基本流程 1.1流程圖 接收版本 盡快申請到正式環境下測試