測試流程模板_第1頁
測試流程模板_第2頁
測試流程模板_第3頁
測試流程模板_第4頁
測試流程模板_第5頁
已閱讀5頁,還剩2頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、測試流程模板-標準化文件發(fā)布號:(9456EUATWKMWUBWUNNINNULDDQTYKII目錄1 概述32 目的33 測試流程3(一)需求分析3(二)測試計劃3測試背景.3測試依據.3測試資源.3測試策略.3測試日程.3其它.3(三)測試設計3(四)測試環(huán)境搭建4(五)測試執(zhí)行4(六)缺陷管理4(七)回歸測試4(A)測試報告4(九)總結分析44 附錄A測試用例相關5(一)概述5(二)好測試用例的特點5(三)測試用例的編寫5(四)編寫測試例的常見錯誤671 概述軟件測試不是簡單的運行被測系統(tǒng),然后看看有什么問題,有問題提出, 沒問題發(fā)布。實際上軟件測試如果沒有一個嚴謹的測試流程,可能會導致

2、測試 用例設訃不夠完善,功能點覆蓋不夠全面等問題。那么軟件測試從哪里開始到 哪里結束?中間要經過哪些環(huán)節(jié)以及各環(huán)節(jié)要注意哪些事項。本文檔就這些問 題根據公司的具體情況一一說明。2 目的為了提高軟件產品質量,測試過程增加了開發(fā)團隊的前期工作量,但卻能 減少項LI后期的維護丄作量和成本。而如果用戶拿到了滿是bug的軟件產品, 損失的不光是后期的維護成本,更重要的是損失了公司的質量信譽。所以測試 無論是對日后系統(tǒng)維護的工作量,還是對公司名譽都起到了不可替代的積極作 用。3 測試流程(-)需求分析需求分析應該說時軟件測試的一個重要環(huán)節(jié),測試開發(fā)人員對這一環(huán)節(jié)的 理解程度將直接影響到接下來有關測試工作的

3、開展。一般而言,需求分析包括軟件功能的需求分析、測試環(huán)境的需求分析、測 試資源的需求分析等。其中最基本的是軟件功能需求分析,拿到測試需求首先 要讀懂需求,然后確定么個需求的具體測試方法。為了實現(xiàn)這些功能需要哪些 測試設備以及如何搭建相應的測試環(huán)境等。總的來說,做測試需求分析的依據主要有軟件需求文檔、軟件規(guī)格 說明書以及軟件設計文檔等,根據文檔中提供的信息進行具體的需求分 析。(二)測試計劃測試計劃一般山測試負責人來編寫,測試計劃的依據主要是項II開發(fā)設計 和測試需求分析結果而制定。測試計劃一般包括以下一些方面:測試背景測試依據測試資源測試策略測試日程其它測試計劃還要包含測試計劃編寫的日期、作者

4、等信息,計劃越詳細越好。雖說計劃越詳細越好,但根據咱們公司的實際測試情況來說,可能沒有那 么多充足的時間來編寫詳細的測試計劃,那么我們可以把重點的流程介紹清楚 就可以了,重點的流程就是測試策略,盡量寫得詳細些。(三)測試設計測試設訃主要包括測試用例編寫和測試場景設訃兩方面。一份好的測試用例對策是有很好的指導作用,能夠發(fā)現(xiàn)很多軟件問題。關 于測試用例的編寫,見附錄A。(四)測試環(huán)境搭建不同軟件產品對測試環(huán)境有著不同的要求。如C/S及B/S架構相關的軟件 產品,那么對不同操作系統(tǒng),如Windows Unix、Linux M至是蘋果OS等,這 些測試環(huán)境都是必須的。而對于一些嵌入式軟件,如我們的終端

5、系統(tǒng),如果我 們想測試一下報警功能,拍照功能等,那么我們可能就需要搭建相應的帶攝像 頭的測試環(huán)境了。當然測試中對于GSM網絡等環(huán)境都有所要求。測試環(huán)境很重要,符合要求的測試環(huán)境能夠幫助我們準確的測岀軟件問 題,并且做出正確判斷。為了正確測試一款軟件,我們可能根據不同的需求點要使用很多不同的測 試環(huán)境。有些測試環(huán)境我們是可以搭建的,有些環(huán)境我們無法搭建或者搭建成 本很高。無論如何,我們的LI標是測試軟件問題,保證軟件質量。測試環(huán)境問 題,還是根據具體產品以及開發(fā)者的實際情況而采取最經濟的方式。(五)測試執(zhí)行從測試的角度而言,測試執(zhí)行包括一個量和度的問題。也就是測試范圉和 測試程度的問題。針對整個

6、送測需求的實際情況而定了,建議測試執(zhí)行最好控 制在兩天以內(1016小時之間)。(六)缺陷管理缺陷的記錄總的來說包含兩方面:由誰提交和缺陷描述。在缺陷描述上,至少要包含以下一些方面內容:序號、標題、預置條件、 操作步驟、預期結果、實測結果、注釋、嚴重程度、概率、測試者和測試日 期。以上是描述一個Bug是通常所要描述的內容,當然在實際提交Bug時可以 根據實際情況進行補充,如附上圖片、Log文件等。(七)回歸測試待缺陷修改之后,我們除了要驗證上一次岀現(xiàn)的問題是否仍然存在,還要 檢查缺陷相關功能有沒有。(八)測試報告測試報告格式見測試報告模板。為保障測試報告的質量,至少要為編寫測 試報告準備2個小

7、時的時間。(九)總結分析整個測試完成之后要對本次測試進行相關總結,如碰到的問題,解決方 法,吸取到的教訓,問題歸類,此類問題以后如何避免等。4 附錄A測試用例相關(一)概述用例文檔(checklist),是關于具體測試步驟的文檔,它描述了測試的輸入 參數、條件及配置、預期的輸出結果等,以判斷被測軟件的工作是否正常。從 表現(xiàn)形式上而言,測試用例可以是純文本的說明文檔,也可以是用腳本語言或 高級語言編寫的一段代碼。測試用例文檔山簡介和測試用例兩部分組成。簡介部分編制測試LI的、測 試范圉、定義術語以及測試背景等。測試用例部分逐一列示各測試用例,測試 用例應當包括測試標識、測試用例名稱、LI標、測試

8、條件、測試設置、輸入數 據要求、步驟、以及預期的結果等。(二)好測試用例的特點1. 完整完整性是對測試用例最基本的要求,尤其是一些基本功能項上,如果有遺 漏,那將是不可原諒的。完整性還體現(xiàn)在中斷測試、臨界測試、壓力測試、性 能測試等方面,這方面測試用例也要能夠涉及到。2. 準確測試者按照測試用例的輸入一步步測試完成后,要能夠根據測試用例描述 的輸岀得出正確的結論,不能出現(xiàn)模糊不清的語言。3. 簡潔好的測試用例每一步都應該有響應的作用,有很強的針對性,不應該出現(xiàn) 一些冗繁無用的操作步驟。測試用例不應該太簡單,也不能夠太過復雜,最大 操作步驟最好控制在10-15步之間。4 清晰清晰包括描述清晰,步

9、驟條理清晰,測試層次清晰(山簡而繁,從基本功能測試 到破壞性測試)。清晰簡潔對測試用例編寫者的邏輯思維和文字表達能力提出了 較高的要求。5. 可維護性山于軟件開發(fā)過程中需求變更等原因的影響,常常需要對測試用例進行修 改、增加、刪除等,以便測試用例符合相應測試要求。測試用例應具備這方面 的功能。6. 適當性測試例應該適合特定的測試環(huán)境以及符合整個團隊的測試水平,如純英語 環(huán)境下的測試用例最好使用英文編寫。7. 可復用性要求不同測試者在同樣測試環(huán)境下使用同樣測試用例都能得出相同結論。8. 其他如可追朔性、可移植性也是對編寫測試用例的一個要求。(三)測試用例的編寫首先,要充分搜集有關軟件需求文檔、軟

10、件規(guī)格等有關資料,充分了解軟 件的功能特點,在編寫測試用例時按照完整準確、清晰簡潔的原則,做到有的 放矢。其次,一般而言,具體的測試用例在內容上都包括以下信息:用例編號、 用例名稱、測試等級、預置條件、操作步驟、預期輸岀、實際輸出、注釋等。 這也是很多大公司的測試用例的都有包括這些方面內容。再者,如果有同類產品的測試用例、測試報告等,可以拿來進行參考,參 考不是抄襲,而是對比發(fā)現(xiàn)自己設訃測試用例的不完整之處,以便及時充實、 彌補。尤其是開展自己不太熟悉的產品測試的時候,這樣做尤為重要,這樣可 以避免測試用例編寫的盲區(qū)。第四,編寫測試用例時,應將常用測試方法,如臨界測試、等值測試、中 斷測試等包含進來,這些方法技巧有助于發(fā)現(xiàn)更多潛在的問題。笫五,測試用例要根據不同測試階段有所差異,一套測試用例不應該用于 不同階段的測試,最好能夠為不同測試階段設計不同的

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論