測試規範
版次 v1.0 密級 內部公開
總頁數 附錄
編寫人 測試小組 編寫時間 2017-11-16
修改記錄
序號 修改內容 修改人 修改日期 備註
目錄1 引言 1
1.1背景 1
1.2作用 1
1.3適用範圍 1
2 規範內容 1
2.1基本功能 1
1、列表展示 1
2、查詢 2
3、新增/修改 2
4、刪除 3
5、批量操作 3
6、記錄詳情/預覽 3
7、密碼設定 3
8、註冊登入 3
9、資訊校驗 4
10、佔位資訊 4
11、城市列表 4
12、手機 4
2.2流程功能 4
1引言1.1背景
在敏捷開發模式下，需要在較短的時間內設計開發產品與迭代公升級。在有限時間內，產品設計人員應更注重產品核心功能流程的設計，而不是在功能的細節上精打細磨。這就需要一套符合一般設計、開發原則的規範來對需求文件未提及的功能細節進行統一。
1.2作用
1）為產品人員在設計產品時提供參考。
2）不影響產品的主要功能、需求文件未提及時，為開發與測試人員提供參考。
3）減少由於非主要功能而產生缺陷的數量，提公升工作效率。
4）降低由於非主要功能而與產品人員確認需求的溝通成本。
1.3適用範圍
1）需求文件未提及。當規範與需求文件衝突時，以需求文件為準。
2）不影響主要功能。當需求文件未提及但有可能影響主要功能時，應與產品人員確認需求，不適用本規範。
3、新增/修改
1）必填項、非必填項。必填項應有必填識別符號，非必填項沒有必填識別符號。必填項未填寫，不能新增成功；非必填項未填寫，可以新增成功。
2）空格。必填項只輸入空格，不應識別為輸入了字元。
3）最長字元。輸入項應有允許輸入最長字元的提示。輸入允許的最長字元後，應能正常新增，不應報錯。
4）非輸入項。下拉項等非輸入項，不允許輸入字元。
5）主鍵。新增/修改時，輸入的主鍵已存在時應有提示，如「××已存在」，「××」為主鍵名稱。主鍵一般不允許修改。
6）資訊校驗。盡可能在頁面校驗，而不是在提交資料時校驗。
7）提交失敗。提交失敗時，應保留原有的輸入資訊，而不是清空，以便修改後再次提交。
4、刪除
1）敏感操作。「刪除」為敏感操作，應有是否確認刪除的提示。
2）關聯性。記錄與其他資料存在關聯時，不允許刪除，且提示資訊應說明不允許刪除的原因。
3）樹狀節點。刪除的記錄存在子節點時，彈出的提示資訊中應確認子節點是否一起刪除。
5、批量操作
1）批量修改。一般不允許批量修改，當選擇多條記錄修改時，應有提示，如「請選擇一條記錄」。
6、記錄詳情/預覽
1）最長字元。各欄位輸入允許的最長字元後，在詳情頁面應能完整展示，若字元超出輸入框時，可使用滾動條。
7、密碼設定
1）空格。密碼不允許有空格字元。
2）明文/密文。密碼設定時，預設應密文顯示。
3）校驗。在需要輸入「確認密碼」時，應對兩次輸入的密碼進行校驗，若校驗不一致，應有提示，如「兩次密碼輸入不一致」。
8、註冊登入
1）已註冊的賬號註冊。應有提示，如「該賬號已註冊」。
2）未註冊的賬號登入。應有提示，如「該賬號還未註冊」。
2）動態驗證碼有效期。應有有效期，超過有效期後，驗證碼失效。
9、資訊校驗
1）資訊校驗。輸入項是否符合規格的校驗，應盡可能在頁面校驗，而不是在提交資料時校驗。
10、佔位資訊
1）灰色。佔位資訊顏色一般為灰色。
2）消失復現。輸入內容後，佔位資訊消失；清空內容後，佔位資訊復現。
11、城市列表
1）多音字。城市應按照正確讀音排序。
–（1）長（chang ,zhang）：長春、長沙。
–（2）廈（xia ,sha）：廈門。
12、手機
1）返回鍵。在客戶端頁面中，手機返回鍵應與頁面返回鍵返回的頁面一致。
2.2流程功能
報告軟體測試規範
報告軟體測試錯誤的目的是為了保證修復錯誤的人員可以重複報告的錯誤，從而有利於分析錯誤產生的原因，定位錯誤，然後修正之。因此，報告軟體測試錯誤的基本要求是準確 簡潔 完整 規範。需要掌握的報告技術歸納如下。1.描述 description 簡潔 準確，完整，揭示錯誤實質，記錄缺陷或錯誤出現的位置 描述...
軟體測試流程及規範
制定完整且具體的測試路線和流程，為快速 高效和高質量的軟體測試提供基礎流程框架。最終目標是實現軟體測試規範化 標準化。流程圖 需求分析 需求分析由sa制定，要求細化每乙個功能的細節，每乙個按鈕的位置以及邊界範圍，對於稍大或稍複雜需求要求建模。1 測試需求是制訂測試計畫的基本依據，只有確定了的測試需求...
軟體測試流程及規範
一 目標 本文是對軟體測試的指導性檔案，制定完整且具體的測試路線和流程，為快速 高效和高質量的軟體測試提供基礎流程框架。最終目標是實現軟體測試規範化 標準化。二 測試流程說明 三 需求分析 需求分析從源頭把握軟體質量，並確保開發結果與實際需求相一致。要求細化每乙個功能的細節，每乙個按鈕的位置以及邊界...