目錄 1. 概述1
1.1 產品簡介 1
1.2 範圍 1
1.3 限制條件 1
1.4 參考文件 1
2. 約定 2
2.1 測試目標 2
2.2 接收標準 2
2.3 資源和工具 2
2.3.1 資源 2
2.3.2 工具 2
2.4 送測要求 2
2.5 編號規則 2
3. 測試種類及測試標準 3
3.1 測試種類 3
3.2 測試方法及標準 3
3.2.1 功能測試 3
3.2.2 業務測試 3
3.2.3 壓力測試 3
3.2.4 安裝測試 3
3.2.5 驗收測試 3
4. 測試重點及順序 4
4.1 **風險 4
4.2 測試重點 4
4.2.1 功能測試 4
4.2.2 業務測試 4
5. 暫停標準和再啟動要求 5
6. 測試任務和進度 6
7. 測試提交物 7
1. 概述
1.1 產品簡介
本次開發是在銷售助手一期的基礎上進行的後續開發，包括新增客服功能模組、解決一期遺留的售前部分問題、完成必要的庫房管理功能。二期結束後產品就成為乙個比較完整的銷售管理軟體。
1.2 範圍
本測試計畫是針對《銷售助手二期概要設計說明書》中規定內容的測試計畫，包括：
改進後的**書
改進後的客戶關懷
銷售機會中新增加的客戶反饋
銷售機會中新增加的客戶組織分析
銷售機會中改進的競爭管理（待定）
銷售機會中改進的聯絡人
改進後的產品和**配製器
新增的銷售知識庫
新增的聯絡活動管理
新增的客戶請求模組
新增的客服活動模組
新增的客服合同模組
新增的客服計畫模組
新增的客服知識庫模組
新增的完成關聯任務模組
公共部分新加或改進的日曆瀏覽資料
公共部分新加或改進的報表功能
公共部分新加或改進的個人事務中心
1.3 限制條件
本測試計畫受限於產品開發人員提交測試的內容和時間的事實。根據開發人員提交模組的實際情況，本計畫會做出相應修改。
1.4 參考文件
2. 約定
2.1 測試目標
通過測試，達到以下目標：
測試已實現的產品是否達到設計的要求，包括：各個功能點是否以實現，業務流程是否正確。
產品規定的操作和執行穩定。
bug數和缺陷率控制在可接收的範圍之內。
2.2 接收標準
本節所述的接收標準是指可測試的標準，這個標準以測試組接收測試為限。單元測試接收標準的詳細規定參見文件三普銷售助手——測試接收標準.doc。
其餘各階段接收標準，以經過審核後的上一階段測試報告為準，每一階段停止標準的詳細規定參見文件軟體測試停止標準.doc。
2.3 資源和工具
2.3.1 資源
測試伺服器
穩定的測試伺服器，ip位址為:192.131.0.1。
人員測試審核人一名，測試實施人員4 名。
2.3.2 工具
測試中使用的bug管理工具為經過改進的bug管理工具。
自動化測試工具待定。
2.4 送測要求
銷售助手開發人員提交的測試按以下要求進行：
2.5 編號規則
與本測試計畫相關的編號規則如下：
測試用例中的編號，功能名+介面名(每個字第乙個漢語拼音大寫)+編號
例如：新增**書第乙個用例
xz bjs 0001
測試用例檔案命命名規則，模組名+測試用例
例如：客服合同模組
客服合同測試用例
3. 測試種類及測試標準
3.1 測試種類
計畫完成以下型別測試
功能測試
業務測試
壓力測試
安裝測試
驗收測試
3.2 測試方法及標準
3.2.1 功能測試
3.2.1.1 功能
系統能按照設計要求實現模組的各個功能，資料應完整、介面美觀、操作方便。
具體可參照本文件測試重點及順序部分。
3.2.1.2 介面測試
詳細的介面測試可以參考介面測試.doc。
3.2.1.3 資料項測試
字母數字資料項是否能夠正確回顯，並輸入到系統中？
圖形模式的資料項（如滑動條）是否正常工作？
是否能夠識別非法資料？
資料輸入訊息是否可理解？
3.2.1.4 幫助文件測試
文件是否精確描述了如何使用各種使用模式？
互動順序的描述是否精確？
例子是否精確？
術語、選單描述和系統響應是否與實際程式一致？
是否能夠很方便地在文件中定位指南？
是否能夠很方便地使用文件排除錯誤？
文件的內容和索引是否精確完整？
文件的設計（布局、縮排和圖形）是否便於資訊的理解？
顯示給使用者的錯誤資訊是否有更詳細的文件解釋？
如果使用超級鏈結，超級鏈結是否精確完整？
3.2.2 業務測試
功能測試完成後進行業務測試，業務測試關注的要點是業務流程，及資料流從軟體中的乙個模組流到另乙個模組的過程中的正確性。業務測試的方法及標準參考業務測試用例.doc。
3.2.3 壓力測試
3.2.3.1 壓力測試說明
本次壓力測試根據實際情況包含效能測試，重點模擬客戶進行多使用者測試。壓力測試有一條8：2原則。
及百分之八十的業務量在百分之二十的時間內輸入。例如:正常每天有100條新資料，測試時在兩小時內輸入80條資料。
我們無法知道使用者的業務量，所以只有利用公司現有資源進行大量的資料量的測試。
3.2.3.2 壓力測試工具
待定3.2.3.3 壓力測試方法及標準
壓力測試的方法及標準參考壓力測試計畫.doc
3.2.4 安裝測試
3.2.4.1 安裝測試說明
除了嵌入式軟體之外，安裝是軟體產品實現其功能的第一步，沒有正確的安裝根本就談不上正確的執行，因此對於安裝的測試就顯得尤為重要。
3.2.4.2 安裝測試方法及標準
自動安裝還是手工配置安裝，測試各種不同的安裝組合，並驗證各種不同組
合的正確性，最終目標是所有組合都能安裝成功。
安裝退出之後，確認應用程式可以正確啟動、執行。
解除安裝測試和安裝測試同樣重要，如果系統提供自動解除安裝工具，那麼解除安裝之後需檢驗系統是否把所有的檔案全部刪除，登錄檔中有關的註冊資訊是否也被刪除。
至少要在一台筆記本上進行安裝測試，因為有很多產品在筆記本中會出現問題，尤其是系統級的產品。(有條件的情況下)
安裝完成之後，可以在簡單地使用之後再執行解除安裝操作，有的系統在使用之後會發生變化，變得不可解除安裝。
安裝時間是否合理；
對於客戶伺服器模式的應用系統，可以先安裝客戶端，然後安裝伺服器端，測試是否會出現問題。
考察安裝該系統是否對其他的應用程式造成影響，特別是windows作業系統，經常會出現此類的問題。
3.2.5 驗收測試
3.2.5.1 驗收測試說明
軟體產品測試部對經過內部單元測試、整合測試和系統測試後的軟體所進行的測試，測試用例採用業務流程測試用例。
3.2.5.2 驗收測試方法及標準
參考三普軟體驗收測試規範.doc和軟體測試停止標準.doc
4. 測試重點及順序
4.1 **風險
本次測試過程中，可能出現的風險如下：
bug的修復情況
模組功能的實現情況
系統整體功能的實現情況
**的編寫質量
人員經驗以及對軟體的熟悉度
開發人員、測試人員關於專案約定的執**況
人員調整導致研發週期延遲
開發時間的縮短導致某些測試計畫無法執行
4.2 測試重點
4.2.1 功能測試
這裡僅為測試重點的描述，具體測試方法以及內容請參見測試用例。
4.2.1.1 商品組裝方案
是否使用右鍵和選單實現了增、刪、改功能
增加零配件使用產品和**配製器，檢視零配件使用商品編輯視窗
拖動功能是否正確
4.2.1.2 銷售機會修改
銷售機會中與聯絡人有關的地方是否已經關聯
增、刪、改功能是否已經實現
各列表中顯示是否正確
銷售費用中右鍵選單中增加生成費用單的功能是否實現
4.2.1.3 產品和**配製器
搜尋到的結果是否正確
按類別和檢視查詢是否正確
4.2.1.4 客戶關懷
右鍵的新增費用單功能是否實現
列表顯示是否正確
新增資料到知識庫是否正確
4.2.1.5 聯絡活動管理
瀏覽視窗是否正確
編輯功能是否實現
是否根據指定條件搜尋
新增資料到知識庫是否正確
4.2.1.6 銷售知識庫
瀏覽時列表顯示是否正確
增、刪、改功能是否已經實現
能否編輯類別
搜尋是否正確
4.2.1.7 選擇商品的修改
參考商品和**配製器
4.2.1.8 客服合同
瀏覽視窗顯示是否正確
增、刪、改功能是否已經實現
能否按照指定條件搜尋
新增資料到知識庫是否正確
4.2.1.9 客服請求
增、刪、改功能是否已經實現
瀏覽介面是否正確
能否按照指定條件搜尋
新增資料到知識庫是否正確
選擇介面是否可用
4.2.1.10 客服計畫
右鍵和選單的增、刪、改功能是否已經實現
瀏覽介面是否正確
能否按照指定條件搜尋
明細選擇介面能否使用
4.2.1.11 客服知識庫
正常的增、刪、改功能是否實現外，能否對類別增、刪、改
能否按類別進行瀏覽
搜尋介面顯示是否正確
4.2.1.12 產品缺陷
增、刪、改功能是否已經實現
瀏覽介面是否正確
能否按照指定條件搜尋
缺陷選擇介面是否實現
4.2.1.13 客服活動
增、刪、改功能是否進行了與之相關聯的增、刪、改
右鍵功能和雙擊功能是否正確
瀏覽視窗顯示是否正確
能否按照指定條件搜尋
4.2.1.14 客服報表
待定4.2.1.15 日曆
待定4.2.1.16 相關資料檢視
待定4.2.1.17 個人中心
待定4.2.2 業務測試
這裡只是描述了業務測試的大概情況，具體測試方法以及內容請參見業務測試用例。這裡的業務測試包含模組之間的關係。
4.2.2.1 銷售機會修改
增加費用時關聯到費用單
聯絡人關聯到聯絡活動、客戶計畫決策人、組織分析
與知識庫關聯
4.2.2.2 客戶關懷
右鍵增加費用時關聯到費用單
與知識庫關聯
4.2.2.3 聯絡活動管理
與知識庫關聯
4.2.2.4 客服合同
銷售合同中可以檢視客服合同
客服合同中可檢視銷售合同
客服合同中選擇銷售合同
與知識庫關聯
自動匯入商品
4.2.2.5 客服請求
客服請求的增、刪、改使用客服計畫編輯、選擇介面
新建客服計畫
檢視相關客服計畫
檢視相關客服活動
新建產品缺陷
增加資料到客服知識庫
4.2.2.6 客服計畫
檢視專案**、檢視專案執**況（相關的客服活動模組）
檢視產品缺陷
檢視客服請求
4.2.2.7 產品缺陷
新建客服計畫專案
檢視相關客服計畫專案
檢視相關客服活動
增加資料到客服知識庫
4.2.2.8 客服活動
費用單、收入單的生成
選擇、刪除關聯費用單
檢視客服請求
檢視產品缺陷
檢視計畫明細
新建產品缺陷
增加資料到客服知識庫
5. 暫停標準和再啟動要求
軟體系統在進行單元、整合、確認、系統、安裝、驗收測試時，發現一級錯誤（大於等於1）、二級錯誤（大於等於2）暫停測試返回開發。
軟體專案需暫停以進行調整時，測試應隨之暫停，並備份暫停點資料。
軟體專案在其開發生命週期內出現重大估算，進度偏差，需暫停或終止時，測試應隨之暫停或終止，並備份暫停或終止點資料。
如有新的專案需求，則在原測試計畫下做相應的調整。
若開發暫停，則相應測試也暫停，並備份暫停點資料。。
若專案中止，則對已完成的測試工作做測試活動總結。
專案再啟動時，測試進度重新安排或順延。
6. 測試任務和進度
實習計畫通用版
一 實習目的 畢業實習是學生大學學習階段重要的實踐性教學環節之一，通過實習學生將進一步了解社會，增強對社會主義現代化建設的責任感 使命感，理論與實踐相結合。通過本次實習，學生將進一步加深對財務會計理論知識的理解，進一步熟悉會計的基本核算方法，為實際工作打下良好基礎。二 實習時間和方式 一 校內實習 ...
調色通用版
調色基礎資料 1 顏色的基本知識 1 顏色的形成三要素 光物體眼 顏色我們肉眼所見到的光線，是由波長範圍很窄的電磁波 可見光,波長390nm 770nm 產生的。不同波長的電磁波表現為不同的顏色，對色彩的辨認是肉眼受到電磁波輻射能刺激後所引起的一種視覺神經的感覺，同時，我們所感受到的不同色彩還與觀察...
工作計畫格式通用版
1 標題 計畫的標題，有四種成分 計畫單位的名稱 計畫時限 計畫內容摘要 計畫名稱。一般有以下三種寫法 1 四種成分完整的標題，如 村二oo二年規劃要點 其中 村 是計畫單位 二oo年 是計畫時限 規劃 是計 劃內容摘要 要點 是計畫名稱。2 省略計畫時限的標題，如 廣東省商業儲運公司實行經營責任制...