軟件質(zhì)量管理之測試計劃

1、精選優(yōu)質(zhì)文檔-傾情為你奉上軟件質(zhì)量管理之測試計劃A引言1目的旨在說明各種階段任務(wù)、人員分配和時間安排、規(guī)范等。在策略和方法的高度說明如何計劃、組織和管理測試項目。測試計劃包含足夠的信息使測試人員明白項目需要做什么是如何運作的。另外，清晰的文檔結(jié)構(gòu)能使任何一個讀者在瀏覽計劃的前面幾頁后，就能對項目有一個大概的認識。測試計劃只是測試的一個框架，很多細節(jié)需要跟開發(fā)人員或人員溝通，因此計劃不包括測試用例的細節(jié)和系統(tǒng)功能的詳細信息。2測試計劃內(nèi)容預(yù)定的測試活動的范圍、途徑、資源及進度安排的文檔。它確認了測試項、被測特征、測試任務(wù)、人員安排，以及任何偶發(fā)事件的風(fēng)險。3測試摘要這一節(jié)主要說明測試計劃中重要的

2、和可能有爭議的問題。本節(jié)的主要目的是將這些信息傳遞給那些可能不會通讀整個測試計劃文檔的人員。4重點事項列出測試的重點事項?？梢詫栴}按重要程度和優(yōu)先級羅列出來，然后在后面的章節(jié)中再對這些問題進行詳細說明，這樣就能讓對這些問題有重要影響的人員知道問題的所在。例如，（以測試均勻派發(fā)更新包為例）a）新進門店如果沒有最近三天的交易數(shù)據(jù)，系統(tǒng)將按默認值插入到IS_BD_TrafficSpread表中b）新進門店如果有最近三天的交易數(shù)據(jù)，但運行時間每天都小于6小時， 系統(tǒng)將按默認值插入到IS_BD_TrafficSpread表中c）新進門店如果有最近三天的交易數(shù)據(jù)，且運行時間有一天大于等于6小時，則系統(tǒng)按

3、這三天的時段平均交易量計算時段派發(fā)比率d）運行后的門店將按最近三天的時段平均交易量計算時段派發(fā)比率e）運行后的門店，如果每天運行時間8小時，而某天又突然要運行10小時，那么將有2小時派發(fā)不出贈品和獎品，此時需手工更改IS_BD_TrafficSpread表中剩余的2小時的比率才有派發(fā)5爭議事項簡要說明爭議事項（例如，數(shù)據(jù)查詢系統(tǒng)，說明其中“自定義查詢功能”，部分暫未開放，不作處理）6風(fēng)險評估通過對技術(shù)文檔的閱讀，對被測系統(tǒng)可能存在的問題：系統(tǒng)設(shè)計，設(shè)計，響應(yīng)時間，因測試環(huán)境不足可能存在的測試缺陷事先評估出來，以指導(dǎo)測試方案，進行有重點的測試。（例如：客戶端上傳下載程序，說明在這里用了6臺機器做

4、一個客戶端程序下載測試，但不能做到大型的，十幾臺機器同時下載時可能出現(xiàn)的滯后現(xiàn)象或下載不成功現(xiàn)象在公司內(nèi)無法進行測試，發(fā)布下去后再進行人工跟蹤，請相關(guān)人員注意此點）7時間進度簡要說明測試開始時間與發(fā)布時間。8測試目標簡要說明測試發(fā)布的質(zhì)量目標；測試計劃中所有測試方法和模塊已經(jīng)執(zhí)行通過（例如，模板測試已經(jīng)根據(jù)模板及配置程序測試用例標準V2.0.xls進行測試，并且執(zhí)行通過測試）；所有的測試案例已經(jīng)執(zhí)行過；所有的重要等級為1/2的已經(jīng)解決并由測試驗證。B項目背景1測試范圍說明本計劃涵蓋的測試范圍，比如系統(tǒng)程序更新包測試，模板測試，更新包測試等。通常說明什么是要測試的，什么是不要測試的是非常重要的。

5、明確規(guī)定這些問題后，測試人員對該做什么有一個清晰的認識。a）簡要地列出測試對象中將接受測試或?qū)⒉唤邮軠y試的那些性能和功能；b）如果在編寫此文檔的過程中作出的某些假設(shè)可能會影響測試設(shè)計、開發(fā)或?qū)嵤?，則列出所有這些假設(shè)；c）列出可能會影響測試設(shè)計、開發(fā)或?qū)嵤┑乃酗L(fēng)險或意外事件；d）列出可能會影響測試設(shè)計、開發(fā)或?qū)嵤┑乃屑s束。提示和技巧：（以下幾點舉例均以“處理派發(fā)錯誤和贈品修改錯誤”更新包為例）a）需要測試和特別注意測試那些部分？（例如，數(shù)據(jù)查詢需要測試“更新包執(zhí)行情況”“更換贈品”“自定義查詢”三個部分內(nèi)容，特別注意刪除更新包所牽涉的數(shù)據(jù)表變動以及更換贈品所影響的兩張表dbo.PM_PP_N

6、onCouponPromotionProduct與PM_PP_SubPromotionQuota 是否有變化）b）測試是否專門針對與某些問題的解決？（例如，主要針對均勻派發(fā)問題和數(shù)據(jù)查詢贈品修改錯誤問題進行的更新包）c）哪些部分不需要測試，為什么？d）哪些部分需要推遲測試，為什么？e）是否要驗證每個模塊的穩(wěn)定性？f）測試的優(yōu)先級和先后順序。（例如，先測試均勻派發(fā)程序，后測試數(shù)據(jù)查詢程序，因為均勻派發(fā)程序必須今天內(nèi)發(fā)布，非常緊急！）2測試目標系統(tǒng)目標對測試人員了解自己需要做什么是非常重要的。測試項目負責(zé)人應(yīng)積極與系統(tǒng)設(shè)計人員或開發(fā)人員溝通，以取得相關(guān)資料。測試人員必須知道系統(tǒng)是做什么并且?guī)椭椖?/p>

7、實現(xiàn)這種目標。在計劃中包括系統(tǒng)視圖和目標后，要確保所有的測試人員都知道項目和系統(tǒng)的目標。通常情況下項目計劃都是模糊的。模糊的目標必須通過成員的努力轉(zhuǎn)換成可衡量和實現(xiàn)的東西。沒有固定的視圖和目標，你將無法完成部分任務(wù)。而且，你會發(fā)現(xiàn)很難將對產(chǎn)品的認識向別人轉(zhuǎn)述。（例如，邏輯測試系統(tǒng)是一個能夠選擇數(shù)據(jù)庫，執(zhí)行腳本以及顯示測試用例上提到的所有參數(shù)。邏輯測試系統(tǒng)的目標：為了方便測試人員在測試邏輯腳本，提高測試人員測試促銷邏輯的速度和效率，更好地保證發(fā)布的促銷邏輯參數(shù)的準確性。）3聯(lián)系方式列出項目參與人員的職務(wù)、姓名、E-mail 和電話。表格 1 聯(lián)系方式職務(wù)姓名E-Mail電話開發(fā)人員開發(fā)經(jīng)理測試負

8、責(zé)人測試人員4風(fēng)險及約束列出測試過程中可能存在的一些風(fēng)險和制約因素，并給出規(guī)避方案。如：a）由于客觀存在的設(shè)備、網(wǎng)絡(luò)等資源原因，使得測試不全面。明確說明哪些資源欠缺，產(chǎn)生什么約束；（例如，客戶端程序-由于網(wǎng)絡(luò)資源有限，不能做到十幾臺機器同時下載的情況，無法進行大型的壓力測試）b）由于研發(fā)模式為現(xiàn)場定制，且上線時間壓力大，使得測試不充分。明確說明在此種約束下，測試如何應(yīng)對；c）只針對專門的客戶群需求的測試。明確說明此約束下的客戶群和業(yè)務(wù)范圍。（例如，測試系統(tǒng)只針對測試人員的需求進行測試）5測試文檔列出測試過程中可能用到的參考文檔、相關(guān)的設(shè)計文檔以及保存位置，測試完成后應(yīng)產(chǎn)生的文檔。（例如，測試工

9、具CMITest-參考文檔：邏輯測試系統(tǒng)測試計劃-V2.0.doc，邏輯測試系統(tǒng)測試用例-V2.0.doc；保存位置： AfterServiceupgrade目錄下，測試完成后應(yīng)該產(chǎn)生邏輯測試報告手冊V1 0.doc）6測試參考文檔表格 2 測試參考文檔文檔說明作者文檔位置需求文檔（需求規(guī)格說明書、Readme.txt或者郵件）測試計劃測試用例7測試提交文檔表格 3 測試提交文檔文檔說明作者文檔位置測試計劃測試用例測試報告Readme.txt操作說明手冊C質(zhì)量目標描述本階段目標和要求。質(zhì)量目標應(yīng)該包括產(chǎn)品的質(zhì)量目標和測試小組的質(zhì)量目標。質(zhì)量不僅是衡量系統(tǒng)的功能或性能是否正常。對系統(tǒng)來說，在開發(fā)

10、過程中盡早建立全面的質(zhì)量標準與系統(tǒng)的及時發(fā)布是一樣重要的。質(zhì)量目標是一個強有力的工具，應(yīng)該在系統(tǒng)開發(fā)過程中盡早建立。一個定義準確的質(zhì)量目標在以后的產(chǎn)品開發(fā)過程中幫助決策。例如，系統(tǒng)是否能夠正式發(fā)行？在代碼完成后，應(yīng)該修復(fù)那些缺陷？在系統(tǒng)完成后那種類型的測試是最合適的？1系統(tǒng)的質(zhì)量目標表格 4 系統(tǒng)的質(zhì)量目標測試質(zhì)量目標確認者（如需說明）測試已實現(xiàn)的產(chǎn)品是否達到設(shè)計的要求，包括：各個功能點是否已實現(xiàn)，業(yè)務(wù)流程是否正確系統(tǒng)規(guī)定的操作和運行穩(wěn)定以下例子，門店數(shù)據(jù)查詢贈品完善贈品添加功能。表格 5 例如：測試質(zhì)量目標確認者（如需說明）更改贈品顯示促銷編號功能，刪除更新包功能以及顯示均勻派發(fā)功能均已實現(xiàn)

11、，業(yè)務(wù)流程正確無誤系統(tǒng)規(guī)定的操作和運行穩(wěn)定2測試質(zhì)量目標表格 6 測試質(zhì)量目標測試質(zhì)量目標確認者（如需說明）所有的測試案例已經(jīng)執(zhí)行過所有的自動測試腳本已經(jīng)執(zhí)行通過所有的重要等級已經(jīng)解決并由測試驗證每一部分的測試已經(jīng)被Test Lead確認完成重要的功能不允許有Bug一般的功能或與最終使用者不直接聯(lián)系的功能不允許有一個以上的bug出現(xiàn)發(fā)現(xiàn)錯誤的Bug的速率正在下降并接近0D資源需求1測試環(huán)境1.1 硬件測試環(huán)境描述建立測試環(huán)境所需要的設(shè)備、用途及軟件部署計劃?！皺C型（配置）”：此處說明所需設(shè)備的機型要求以及內(nèi)存、CPU、硬盤大小的最低要求；“用途及特殊說明”：此設(shè)備的用途，如服務(wù)器，服務(wù)器等；如

12、有特殊約束，如SDK版本等，也寫在此列；“軟件及版本”：詳細說明每臺設(shè)備上部署的自開發(fā)和第三方軟件的名稱和版本號，以便系統(tǒng)管理員按照此計劃分配測試資源；如：測試環(huán)境的版本為母盤2007-12-3版本,客戶端為2007-9-11版本“預(yù)計空間”：說明第三方軟件和應(yīng)用程序的預(yù)計空間；“環(huán)境約束說明”：建立此環(huán)境時的特殊約束。如需要路由進行局域網(wǎng)環(huán)境等。表格 7 測試環(huán)境機型（配置）IP地址用途及特點軟件及版本預(yù)計空間TCL14.22.0.6WinXP2 Server 20051G虹光AV210 C21.2 軟件測試環(huán)境表格 8 軟件測試環(huán)境軟件需求用途2測試工具表格 9 測試工具測試工具用途自動測

13、試工具E測試策略1整體測試策略本節(jié)的目的是說明計劃中使用的基本的測試過程。使用里程碑技術(shù)在測試過程中驗證每個模塊，測試人員在需求階段參與測試工作，進行需求review、設(shè)計 review、測試案例設(shè)計和測試開發(fā)，在系統(tǒng)開發(fā)完成之后，正式執(zhí)行測試。系統(tǒng)達到軟件系統(tǒng)質(zhì)量要求和測試要求后發(fā)布，并提交相關(guān)的測試文檔。2開始/中斷/完成標準表格 10 中斷/開始/完成測試的標準開始/中斷/完成測試標準說明開始測試標準硬件環(huán)境可用且軟件正確安裝完成中斷測試標準安裝無法正確完成或程序的文檔有相當多的失誤或系統(tǒng)服務(wù)異?；虬l(fā)現(xiàn)Block Bug完成測試標準完成測試計劃中的測試規(guī)劃并達到程序和測試質(zhì)量目標,并由開

14、發(fā)人員與測試人員共同確認3測試類型表格 11 測試類型測試類型是否采用說明功能測試采用根據(jù)系統(tǒng)需求文檔和設(shè)計文檔，檢查系統(tǒng)是否正確實現(xiàn)了功能流程測試采用按操作流程進行的測試，主要有業(yè)務(wù)流程、數(shù)據(jù)流程、邏輯流程、正反流程，檢查系統(tǒng)在按流程操作時是否能夠正確處理邊界值測試采用選擇邊界數(shù)據(jù)進行測試，確保系統(tǒng)功能正常，程序無異常容錯性測試采用檢查系統(tǒng)的容錯能力，錯誤的數(shù)據(jù)輸入不會對功能和系統(tǒng)產(chǎn)生非正常的影響，且程序?qū)﹀e誤的輸入有正確的提示信息異常測試采用檢查系統(tǒng)能否處理異常啟動停止測試采用檢查每個模塊能否正常啟動停止、異常停止后能否正常啟動安裝測試采用檢查系統(tǒng)能否正確安裝、配置易用性測試采用檢查系統(tǒng)是

15、否易用友好界面測試采用檢查界面是否美觀合理接口測試采用檢查系統(tǒng)能否與外部接口正常工作(例如,能否與掃描儀一同正常工作)配置測試采用檢查配置是否合理、配置是否正常(例如,數(shù)據(jù)庫連接,掃描儀連接,日志存放路徑等)安全性和訪問控制測試采用應(yīng)用程序級別的安全性：檢查Actor只能訪問其所屬用戶類型已被授權(quán)訪問的那些功能或數(shù)據(jù)系統(tǒng)級別的安全性：檢查只有具備系統(tǒng)和應(yīng)用程序訪問權(quán)限的Actor才能訪問系統(tǒng)和應(yīng)用程序性能測試采用提取系統(tǒng)性能數(shù)據(jù)，檢查系統(tǒng)是否滿足在需求中所規(guī)定達到的性能壓力測試采用檢查系統(tǒng)能否承受大壓力，測試產(chǎn)品應(yīng)該能夠在高強度條件下正常運行，不會出現(xiàn)任何錯誤。(例如客戶端程序的測試能否在十幾臺機器同時下載無網(wǎng)絡(luò)堵塞現(xiàn)象)兼容性測試采用對于 C/S 架構(gòu)的系統(tǒng)來說，需要考慮客戶端支持的系統(tǒng)平臺對于 B/S 架構(gòu)的系統(tǒng)來說需要考慮用戶端瀏覽器的版本。文檔測試采用檢查文檔是否足夠、描述是否合理回歸測試采用檢查程序修改后有沒有引起新的錯誤、是否能夠正常工作以及能否滿足系統(tǒng)的需求4測試技術(shù)表格 12 測試技術(shù)測試技術(shù)是否采用說明自動測試技術(shù)采用核心業(yè)務(wù)流程采用自動測試技術(shù)審評測試采用對軟件產(chǎn)品功能說明文檔和設(shè)計說明文檔進行檢查，在需求與設(shè)計階段進行編寫測試用例采用在產(chǎn)品編碼階段編寫測試用例單元測試不采用由開發(fā)人員進行集成測試采用檢測模塊集成后的系統(tǒng)是否達到需求對業(yè)務(wù)