- 相關推薦
軟件測試基礎要點總結
總結是指社會團體、企業(yè)單位和個人在自身的某一時期、某一項目或某些工作告一段落或者全部完成后進行回顧檢查、分析評價，從而肯定成績，得到經(jīng)驗，找出差距，得出教訓和一些規(guī)律性認識的一種書面材料，它可以促使我們思考，因此我們要做好歸納，寫好總結。總結怎么寫才不會流于形式呢？以下是小編收集整理的軟件測試基礎要點總結，歡迎閱讀與收藏。
從宏觀的角度講，軟件測試過程一般可劃分為單元測試、集成測試、驗收測試和系統(tǒng)測試等幾個主要測試階段。
1.測試計劃注意事項
1．測試計劃不一定要盡善盡美，但一定要切合實際，要根據(jù)項目特點、公司實際情況來編制，不能脫離實際情況；
2．測試計劃一旦制定下來，并不就是一成不變的，隨著軟件需求、軟件開發(fā)、人員流動等發(fā)生變化，測試計劃也要根據(jù)實際情況的變化而不斷進行調(diào)整，以滿足實際測試要求。
3．測試計劃要能從宏觀上反映項目的測試任務、測試階段、資源需求等，不一定要太過詳細。
測試原則
�、賾M早和不斷地進行軟件“測試”。
�、跍y試用例中，不僅要選擇合理的輸入數(shù)據(jù)，還要選擇不合理的輸入數(shù)據(jù)。
�、墼陂_發(fā)各階段應事先分別制定出相應的測試計劃，在測試開始后應嚴格執(zhí)行，防止隨意性。
�、軐Πl(fā)現(xiàn)錯誤較多的程序模塊，應進行重點測試。
�、荼苊獬绦騿T測試自己的程序。
�、抻酶F舉測試是不現(xiàn)實的，一般通過設計測試用例，充分覆蓋所有條件或所有語句即可。
�、唛L期妥善保存測試計劃、測試用例、出錯統(tǒng)計和有關的分析報告。
2.測試用例文檔
測試用例文檔通常是由簡介和測試用例兩部分組成：
簡介部分編制了測試目的、測試范圍、定義術語、參考文檔等，這個與測試計劃是一致的。
測試用例部分逐一列出各個測試用例。
測試用例（TestCase）是為某個特殊目標而編制的一組測試輸入、執(zhí)行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
測試用例部分
測試用例通常包含的信息：用例標識和用例名稱內(nèi)容描述前提條件執(zhí)行步驟預期結果評價準則
用例設計人員和設計時間用例執(zhí)行人員和執(zhí)行時間其它內(nèi)容
3.軟件缺陷
缺陷的表現(xiàn)形式不僅體現(xiàn)在功能的失效方面，還體現(xiàn)在其他方面。主要類型有：
①軟件沒有實現(xiàn)產(chǎn)品規(guī)格說明所要求的功能模塊軟件中；
�、诔霈F(xiàn)了產(chǎn)品規(guī)格說明指明不應該出現(xiàn)的錯誤；
�、圮浖䦟崿F(xiàn)了產(chǎn)品規(guī)格說明沒有提到的功能模塊；
�、苘浖䴖]有實現(xiàn)雖然產(chǎn)品規(guī)格說明沒有明確提及但應該實現(xiàn)的目標；
⑤軟件難以理解，不容易使用，運行緩慢，或從測試員的角度看，最終用戶會認為不好。
測試用例：以計算器為例
�、儆嬎闫鞯漠a(chǎn)品規(guī)格說明定應能準確無誤地進行加、減、乘、除運算。如果按下加法鍵，沒什么反應，就是第一種類型的缺陷；若計算結果出錯，也是第一種類型的缺陷。②產(chǎn)品規(guī)格說明書還可能規(guī)定計算器不會死機，或者停止反應。如果隨意敲鍵盤導致計算器停止接受輸入，這就是第二種類型的缺陷。
�、廴绻褂糜嬎闫鬟M行測試，發(fā)現(xiàn)除了加、減、乘、除之外還可以求平方根，但是產(chǎn)品規(guī)格說明沒有提及這一功能模塊。這是第三種類型的缺陷④在測試計算器時若發(fā)現(xiàn)電池沒電會導致計算不正確，而產(chǎn)品說明書是假定電池一直都有電的，從而發(fā)現(xiàn)第四種類型的錯誤。
�、蒈浖䴗y試員如果發(fā)現(xiàn)某些地方不對，比如測試員覺得按鍵太小、“=”鍵布置的位置不好按、在亮光下看不清顯示屏等，無論什么原因，都要認定為缺陷。
4.缺陷報告里通常包含：缺陷標識、所屬系統(tǒng)、所屬模塊、版本號、嚴重程度、優(yōu)先級、測試種類、缺陷概述、缺陷詳述以及開發(fā)人員意見以及其它內(nèi)容。缺陷提交報告主要供兩類人閱讀，即軟件開發(fā)人員和項目管理者。
5.常用軟件缺陷工具test Director test manager
專業(yè)缺陷管理工具bug zilla
6.測試報告文檔
測試報告是把測試的過程和結果寫成文檔，并對發(fā)現(xiàn)的問題和缺陷進行分析，為糾正軟件的存在的質(zhì)量問題提供依據(jù)，同時為軟件驗收和交付打下基礎。
測試報告是測試階段最后的文檔產(chǎn)出物，一份詳細的測試報告包括產(chǎn)品質(zhì)量和測試過程的評價，測試報告基于測試中的數(shù)據(jù)采集以及對最終的測試結果分析。比如覆蓋率分析、缺陷分析。
7.測試結果概述
這部分將被分成下面幾段來對測試結果進行概述。
1被測軟件的全面評估
本段應該包括：
a.根據(jù)本文檔中的測試結果對被測軟件的整體評價。
b.任何在測試中檢查到的殘留的不足,限制,局限�？梢杂脝栴}/修改報告來提供缺陷信息。
c.對每個殘留的缺陷,限制,局限,描述如下：
1對軟件和系統(tǒng)性能的影響，包括沒有滿足的需求
2為了更正它，會對軟件和系統(tǒng)設計產(chǎn)生的影響。
3推薦的解決方法/策略
8.軟件特性softwarefeature軟件項的顯著特性。（如功能、性能或可移植性等）。
軟件項softwareitem
源代碼、目標代碼、作業(yè)控制代碼、控制數(shù)據(jù)或這些項的集合。測試項testitem作為測試對象的軟件項。
9.測試計劃描述測試活動的范圍、方法、資源和進度。它規(guī)定被測試的項、被測試的特性、應完成的測試任務、擔任各項工作的人員職責及與本計劃有關的風險等。
測試說明包括三類文件：
（1）測試設計說明：詳細描述測試方法，規(guī)定該設計及其有關測試所包括的特性，還規(guī)定完成測試所需的測試用例和測試規(guī)程，并規(guī)定特性的通過準則。
�。�2）測試用例說明：列出用于輸入的具體值以及預期的輸出結果，并規(guī)定在使用具體測試用例時，對測試規(guī)程的各種限制。將測試用例與測試設計分開，可以使它們用于多個設計并能在其它情形下重復使用。
�。�3）測試規(guī)程說明：規(guī)定對于運行系統(tǒng)和執(zhí)行指定的測試用例來實現(xiàn)有關測試設計所要求的所有步驟。
測試報告包括四類文件：
�。�1）測試項傳遞報告：指明在開發(fā)組和測試組獨立工作的情況下或者在希望正式開始測試的情況下為進行測試而被傳遞的測試項。
�。�2）測試日志：測試組用于記錄測試執(zhí)行過程中發(fā)生的情況。
�。�3）測試事件報告：描述在測試執(zhí)行期間發(fā)生并需進一步調(diào)查的一切事件。（4）測試總結報告：總結與測試設計說明有關的測試活動。
這些文件同其它文件在編制方面的關系以及同測試過程的對應關系如圖1所示。
10.測試計劃要點內(nèi)容：
1測試計劃名稱
2引言
3測試項
4被測試的特性
5不被測試的特性
6方法
7項通過準則
8暫停標準和再啟動要求
9應提供的測試文件
10測試任務
11環(huán)境要求
12職責
13人員和訓練要求
14進度
15風險和應急
16批準
引言（本計劃的第2章）
歸納所要求測試的軟件項和軟件特性，可以包括系統(tǒng)目標、背景、范圍及引用材料等。在最高層測試計劃中，如果存在下述文件，則需要引用它們：項目計劃、質(zhì)量保證計劃、有關的政策、有關的標準等。
5.1.3測試項（本計劃的第3章）
描述被測試的對象，包括其版本、修訂級別，并指出在測試開始之前對邏輯或物理變換的要求。
5.1.4被測試的特性（本計劃的第4章）
指明所有要被測試的軟件特性及其組合，指明每個特性或特性組合有關的測試設計說明。
5.1.5不被測試的特性（本計劃的第5章）
指出不被測試的所有特性和特性的有意義的組合及其理由。
5.1.6方法（本計劃的第6章）
描述測試的總體方法，規(guī)定測試指定特性組志需的主要活動、技術和工具，應詳盡地描述方法，以便列出主要的測試任務，并估計執(zhí)行各項任務所需的時間。規(guī)定所希望的電低程度的測試徹底性，指明用于判斷測試徹底性的技術（如：檢查哪些語句至少執(zhí)行過一次）。
指出對測試的主要限制，例如：測試項可用性、測試資源的可用性和測試截止期限等。
5.1.7項通過準則（本計劃的第7章）規(guī)定各測試項通過測試的標準。
5.1.8暫停標準和再啟動要求（本計劃第8章）
規(guī)定用于暫停全部或部分與本計劃有關的測試項的測試活動的標準。規(guī)定當測試再啟動時必須重復的測試活動。
5.1.9應提供的測試文件（本計劃的第9章）
規(guī)定測試完成后所應遞交的文件，這些文件可以是前述八個文件的全部或者部分。
5.1.10測試任務（本計劃的第10章）
指明執(zhí)行測試所需的任務集合，指出任務音的一切依賴關系和所需的一切特殊技能。
5.1.11環(huán)境要求（本計劃的第11章）
規(guī)定測試環(huán)境所必備的和希望的的性質(zhì)。包括：硬件、通信和系統(tǒng)軟件的物理特征、使用方式以及任何其它支撐測試所需的軟件或設備，指出所需的特殊測試工具及其它測試要求（如出版物或辦公場地等）。指出測試組目前還不能得到的所有要求的來源。
5.1.12職責（本計劃的第12章）
指出負責管理、設計、準備、執(zhí)行、監(jiān)督、檢查和仲裁的小組。另外指出負責提供
5.1.13中指出的測試項和在
5.1.14中指出的環(huán)境要求的小組。
這些小組可以包括開發(fā)人員、測試人員、操作員、用戶代表、數(shù)據(jù)管理員和質(zhì)量保證人員。
5.1.15人員和訓練要求（本計劃的第13章）
指明測試人員應有的水平以及為掌握必要技能可供選擇的訓練科目。
5.1.16進度（本計劃的第14章）包括在軟件項目進度中規(guī)定的測試里程碑以及所有測試項傳遞時間。定義所需的新的測試里程碑，估計完成每項測試任務所需的時間，為每項測試任務和測試里程碑規(guī)定進度，對每項測試資源規(guī)定使用期限。
5.1.17風險和應急（本計劃的第15章）
預測測試計劃中的風險，規(guī)定對各種風險的應急措施（如：延期傳遞的測試項可能需要加夜班來趕上規(guī)定的進度。）
5.1.18批準（本計劃的第16章）
規(guī)定本計劃必須由哪些人（姓名和職務）審批。為簽名和填寫日期留出位置。
11.軟件測試原則
所有的軟件測試都應追溯到用戶需求應當把“盡早地和不斷地進行軟件測試”作為軟件測試人的座右銘完全測試是不可能的，測試需要終止測試無法顯示系統(tǒng)所有潛在的缺陷充分注意測試中的群集現(xiàn)象程序員應避免檢查自己的程序盡量避免測試的隨意性，應從工程的角度理解軟件測試，它是有組織、有計劃、有步驟的活動
12.軟件測試對象
程序數(shù)據(jù)文檔過程硬件網(wǎng)絡
13.確認測試
確認測試的目的是向未來的用戶表明系統(tǒng)能夠像預定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應該進一步驗證軟件的有效性，這就是確認測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣確認測試又稱有效性測試。有效性測試是在模擬的環(huán)境下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。任務是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定，它包含的信息就是軟件確認測試的基礎
14.GUI測試（ui測試）
窗體是否能夠基于相關的輸入或菜單命令適當?shù)拇蜷_2.窗體是否能夠改變大小、移動和滾動
3.窗體的數(shù)據(jù)是否能夠利用鼠標、功能鍵、方向箭頭和鍵盤操作
4.當窗體被覆蓋并重新調(diào)用后，窗體是否能夠正確再生
5.窗體相關的功能是否可以操作
6.是否顯示相關的下拉菜單、工具條、滾動條、對話框、按鈕、圖標和其他控制，既能正確顯示又能調(diào)用
7.顯示多窗體時，窗體名稱是否能夠正確表示
8.活動窗體是否能夠被反顯加亮
9.多用戶聯(lián)機時所有窗體是否能夠?qū)崟r更新
10.鼠標無規(guī)則點擊時是否會產(chǎn)生無法預料的結果
11.窗體聲音及提示是否符合既定編程規(guī)則
【軟件測試基礎要點總結】相關文章：
軟件測試個人總結05-19
軟件測試工作總結05-20
軟件測試主管工作總結05-24
軟件測試面試自我介紹12-02
軟件測試工程師工作總結05-18
軟件測試實習報告10篇11-25
軟件測試年度工作總結05-25
軟件測試實習報告（通用16篇）05-08
軟件測試工程師崗位職責04-14