常見測試點整理

1、序序號號類類型型1數(shù)據(jù)的一致性，正確性測試2新增，搜索，修改，排序，刪除，打印等功能點的測試3校驗規(guī)則測試4界面風(fēng)格測試5狀態(tài)轉(zhuǎn)換的測試6壓力測試7參數(shù)設(shè)置校驗8文件傳輸測試9數(shù)據(jù)導(dǎo)入導(dǎo)出測試10與計算機(jī)通訊測試11安裝測試12配置測試13文檔測試14重要業(yè)務(wù)功能測試15回歸測試16交叉測試測測試試要要點點數(shù)據(jù)類型的字段10進(jìn)制與16進(jìn)制的轉(zhuǎn)換的測試刪除被引用基礎(chǔ)數(shù)據(jù)的測試數(shù)量的數(shù)值是否計算正確的測試檢查域的長度，是否有字符被截掉？檢查數(shù)字域的最大值和最小值？檢查數(shù)字域是否正確接受負(fù)數(shù)？數(shù)據(jù)庫對數(shù)據(jù)的存儲是否完整？有沒有出現(xiàn)字符串被截，數(shù)值沒有4舍5入等？特定數(shù)據(jù)的格式是否正確？如日期型數(shù)據(jù)有

2、沒有“-”或“/”等分隔符；金額字段的數(shù)據(jù)有沒有每三位數(shù)字自動添加“，”分隔符？連續(xù)新增，修改，刪除的測試需求功能是否實現(xiàn)的測試新增，修改后，TREEVIEW中數(shù)據(jù)是否及時更新的測試查詢條件與新增,修改時,輸入單引號及特殊字符進(jìn)行查詢的校驗的測試修改時編碼不能修改的測試新增時編碼是否需要自動更新的測試新增與修改時的校驗規(guī)則測試見序號3用鼠標(biāo)點擊只讀域，能否進(jìn)入？當(dāng)打開窗口時，光標(biāo)/焦點是否位于第一個可輸入域？編輯框域Edit Box是否限制了字符的長度？使用ALT+TAB組合鍵從一個應(yīng)用到另一個應(yīng)用切換時是否有沖突？ID、編號或單據(jù)號重復(fù)時，是否給出提示？排序項目是否正確、全面？項目的排列順序

3、是否與顯示的排列順序一致？特定權(quán)限人員搜索特定資料的測試特定權(quán)限人員使用特定功能的測試清除數(shù)據(jù)的測試，即沒有基礎(chǔ)數(shù)據(jù)的異常處理的測試全部展開樹中所有數(shù)據(jù)，看看滾動條的是否能拖動到樹中最低下的數(shù)據(jù)的測試日期格式是否校驗的測試小數(shù)類數(shù)據(jù)是否校驗的測試整數(shù)類數(shù)據(jù)是否校驗的測試校驗提示信息是否正確，觸發(fā)提示信息的時機(jī)是否恰當(dāng)?shù)臏y試。字母是否校驗的測試特殊字符是否校驗的測試郵箱格式是否校驗的測試數(shù)據(jù)超長是否校驗的測試數(shù)字最大最小值的校驗的測試數(shù)據(jù)是否選擇的校驗的測試數(shù)據(jù)是否為空的校驗的測試數(shù)據(jù)唯一性的校驗的測試年份最大，最小值校驗的測試數(shù)據(jù)被要求范圍校驗的測試定義文件名規(guī)則的校驗的測試上傳文件名超長的校

4、驗的測試上傳文件名輸入框為單引號的測試備注信息最長輸入是否校驗的測試閏年日期是否正確，是否不產(chǎn)生錯誤和計算誤差？月份是否只能在1和12之間（包含本身）？日期是否只能在1和31之間（包含本身）？二月是否有28、29、30日？日期的周期性計算是否正確？是否有日歷選擇器？是否與手工輸入有沖突？除零的情況是否不允許？在數(shù)字后面帶有空格的數(shù)字域是否正確接受？數(shù)據(jù)聯(lián)動性的測試繁體字，簡體字，英文的測試字體大小的測試按鈕大小的測試窗口大小的測試按鈕標(biāo)題大小的測試頁面標(biāo)題的測試編輯框是否夠?qū)拤蜷L的測試主頁面顯示在800X600下是否滿屏的測試快捷鍵的校驗的測試導(dǎo)航條的測試界面亂碼的測試腳本錯誤的測試查詢時間段

5、風(fēng)格的測試窗口中的按鈕是否有適當(dāng)?shù)目旖萱I？快捷鍵工作是否正常？用TAB鍵在元素間移動的次序是否正確，一般缺省從左上到右下？數(shù)據(jù)列太長，能否調(diào)整列寬？翻頁的測試各個相關(guān)功能界面的數(shù)據(jù)字段的排列順序是否一致，是否美觀。報表頁碼顯示的測試頁面設(shè)置的測試關(guān)閉，保存等按鈕是否使用專用圖標(biāo)的測試頁面窗口不需要有問號標(biāo)識的測試界面排版是否都是95%的排列的測試嘗試在非登陸狀態(tài)開啟頁面，任何人都可以進(jìn)行修改和刪除數(shù)據(jù)，是否做到頁面級別權(quán)限控制的測試所有頁面標(biāo)題是不是以系統(tǒng)名命名的測試是否有溫馨提示指導(dǎo)用戶很好的使用系統(tǒng)交互式對話以彈出式風(fēng)格顯示，提示式信息以懸掛式風(fēng)格顯示。各個數(shù)據(jù)狀態(tài)的限制的測試系統(tǒng)長時間運(yùn)

6、行是否會出現(xiàn)死機(jī)的現(xiàn)象的測試系統(tǒng)長時間運(yùn)行是否會出現(xiàn)SESSON丟失的現(xiàn)象的測試長時間運(yùn)行，是否會出現(xiàn)連數(shù)據(jù)庫不成功的現(xiàn)象的測試大量數(shù)據(jù)導(dǎo)入導(dǎo)出是否會出現(xiàn)死機(jī)的現(xiàn)象的測試同時打開多個應(yīng)用程序的測試的測試各個參數(shù)的值全部沒設(shè)置的測試設(shè)置部分參數(shù)的測試全部設(shè)置參數(shù)的測試參數(shù)設(shè)置是否正確的測試設(shè)置錯誤的數(shù)據(jù)類型的參數(shù)的測試參數(shù)文件保存編碼格式的測試參數(shù)文件不完整的測試文件上傳到FTP或SERVER服務(wù)器端后，系統(tǒng)是否會死機(jī)的測試下載文件上傳文件成功與否反饋信息的測試FTP有文件，PC機(jī)中沒有文件的測試FTP有文件，PC機(jī)中有文件的測試FTP有文件，PC機(jī)中有文件的測試FTP中大量文件下載的測試同時下

7、載上傳多個文件的測試單個文件上傳或下載斷續(xù)連網(wǎng)測試的測試多個文件上傳或下載斷續(xù)連網(wǎng)測試的測試上傳與下載文件同時進(jìn)行的測試文件上傳后光標(biāo)如何定位的測試多條記錄導(dǎo)入的測試導(dǎo)入模板的測試導(dǎo)入模板數(shù)據(jù)類型錯誤的測試部分?jǐn)?shù)據(jù)導(dǎo)入不成功是否會出現(xiàn)提示信息的測試多個文件導(dǎo)入數(shù)據(jù)庫的測試大量插數(shù)據(jù)導(dǎo)致數(shù)據(jù)庫的表空間不足的測試導(dǎo)入文件名的測試長時間等待的過程中，是否有動態(tài)的標(biāo)識進(jìn)度？是否給出數(shù)據(jù)處理成功與否的信息？若不成功， 是否給出失敗原因？導(dǎo)入多條完全相同的基礎(chǔ)數(shù)據(jù)的測試導(dǎo)入非法數(shù)據(jù)是否有校驗的測試多次導(dǎo)入不完全相同的數(shù)據(jù)，系統(tǒng)會否覆蓋原有數(shù)據(jù)的測試計算機(jī)與機(jī)器硬件接口，波特率等的測試通訊過程中斷電的測試人

8、為中斷通訊的測試連續(xù)多次通訊的測試通訊過程中隨意操作按鈕鍵或都鍵盤鍵的測試長時間連接而不做任何操作的測試通訊過程中讀錯文件的測試通訊過程中讀取多個文件的測試將系統(tǒng)安裝在WIN2000，WINXP運(yùn)行的測試IE瀏覽器版本的測試運(yùn)行之前各個環(huán)境設(shè)置的測試部份運(yùn)行程序文件被刪除的測試特定系統(tǒng)的重要業(yè)務(wù)功能的測試（需求中必須明確哪些是重要的業(yè)務(wù)功能才能對此進(jìn)行測試）測試客戶提出來的BUG或需求之前，必須先看看這些BUG與需求的修改會影響到哪些地方，哪些頁面，哪些功能，然后針對這些影響項測試，從而使測試做到更加全面。以免漏掉有些地方?jīng)]有測試到。測試人員負(fù)責(zé)一個模塊或者功能的測試一段時間后發(fā)現(xiàn)的問題達(dá)到了

9、極限，在這種固定的思維方式下很難發(fā)現(xiàn)新的問題，這種情況需要采用交叉測試以解決此問題，但是另一個測試的人熟悉業(yè)務(wù)需要一段時間的。這時候又要怎么辦？是的，可以讓組員之間的模塊進(jìn)行交換測試，因為對于測試員自身來講，別人手中的模塊更具備吸引力，如同圖1中的左邊那個蘋果，也具有更多未知的領(lǐng)域，從而也能發(fā)現(xiàn)更多的缺陷。這就是傳說中的交叉測試方法。那是經(jīng)過幾輪回歸后就整體交換測試員手中的模塊嗎？不，那樣帶來的成本太高，因為采用這種方式，測試員對手中的新模塊的完全了解需要花一定長的時間，從而使時間成本提升了。如果你告訴項目經(jīng)理，我們當(dāng)前版本（與剛開始測試的版本比沒有添加額外的模塊和功能點）的測試所需要花的時間

10、和系統(tǒng)剛開始測試的時候是一樣的，項目經(jīng)理肯定會覺得不可思議，因為測試組已經(jīng)測試過多個回歸版本了，無論從業(yè)務(wù)流程到功能點，肯定是熟悉了很多，正確的結(jié)果應(yīng)該是測試的周期時間會慢慢減少啊。如果你告訴項目經(jīng)理，我們采用了交叉測試，以此想發(fā)現(xiàn)更多的缺陷，或許在項目進(jìn)度不是很緊的時候，項目經(jīng)理會覺得可以接受，那在進(jìn)度很緊張的時候，可能就夠嗆了。如何在有限的項目進(jìn)度時間內(nèi)，有效的實施交叉測試呢？本人拋磚引玉地提出三階段實施法：項目前期測試階段：在這一階段，組內(nèi)所有測試員對系統(tǒng)的功能和業(yè)務(wù)流程都沒有比較深刻的認(rèn)知，此時安排不同測試員負(fù)責(zé)不同模塊的測試。功能點和業(yè)務(wù)流程測試任務(wù)的分配通過測試用例進(jìn)行。項目中期測試階段：將功能點的測試，如外觀，單個按鈕或控件功能等測試任務(wù)通過測試用例分配進(jìn)行逐步交叉，使得交叉測試開