標籤:
為期8周的軟體測試課程,讓我學會了關於測試的很多知識,測試是一門需要細心的大工程,測試分為很多的內容,也許有人認為測試容易,但其實不然。
從我做的兩次實驗來看,僅僅是一個非常簡單非常小的應用就可以做很長的時間,而做出一個好的測試報告也需要付出很多的時間來寫好寫完整。
現在需要很多軟體測試的人才,我們也很有必要好好學習軟體測試這個模組。
以下是具體的體會整理:
體會一:軟體測試在整個軟體周期中的重要性。
它存在於整個項目周期,在項目開始之初需求調研的時候就開始了,在形成需求規格說明書的時候就需要針對文檔進行測試。
這個環節在後續整個項目中佔了很大的比重,能主導整個項目的走向,成敗與否全在於開始階段的決策。
體會二:軟體測試的真正意義在於發現錯誤,而不在於驗證軟體是正確的。 再嚴密的測試也不能完全發現軟體當中所有的錯誤,
但是測試還是能發現大部分的錯誤,能確保軟體基本是可用的,所以在後續使用的過程中還需要加強快速響應的環節。
結合軟體測試的理論,故障暴露在最終用戶端之前及時主動的去發現並解決。這一點就需要加強研發隊伍的建設。
自己也做了一個軟體測試內容大的方面的總結為軟體測試課程畫上一個句號:
一:系統測試,整合測試,單元測試
二:1.幾個黑箱測試常用的方法:
等價類別劃分法
邊界值分析法
因果圖法
決策表法
錯誤值推測法
2.測試案例設計方法選擇的綜合策略
在任何情況下都必須使用邊界值分析方法。經驗表明用這種方法設計出測試案例發現程式錯誤的能力最強。
必要時用等價類別劃分方法補充一些測試案例。
用錯誤推測法再追加一些測試案例。
對照程式邏輯,檢查已設計出的測試案例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準,應當再補充足夠的測試案例。
如果程式的功能說明中含有輸入條件的組合情況,則一開始就可選用因果圖法。
三:幾個白盒測試常用的覆蓋準則:
1.
2.還有一個重要的路徑覆蓋準則!!
四:Peer Review
1.同行評審的關鍵點:
moderator
inspector
author
reader
recorder
2.The organizational form of PR
技術評審(Technical review )
正規檢視(Formal Inspection)
走讀(Walkthroughs)
管理評審(Management Review)
3.關鍵過程:
4.區別階段評審的與同行評審
同行評審目的:發現小規模工作產品的錯誤,只要是找錯誤;
階段評審目的:評審模組 階段作品的正確性 可行性 及完整性
同行評審人數:3-7人 人員必須經過同行評審會議的培訓,由SQA指導
階段評審人數:5人左右 評審人必須是專家 具有系統評審資格
同行評審內容:內容小 一般文檔 < 40頁, 代碼 < 500行
階段評審內容: 內容多,主要看重點
同行評審時間:一小部分工作產品完成
階段評審時間: 通常是設定在關鍵路徑的時間點上
5.同行評審的意義:
1.成功的同行評審是提高品質和生產率的重要因素,不管人們喜歡與否,審查過程會迫使每個人在一種開放式的環境中工作。
一旦人們懂得了他們的工作都要接受同行評審,他們就會越早地將他們的工作公之於眾,以待監督。
在同儕審查上的投入把組織的一些品質成本從昂貴的測試以及後期的大規模返工轉變為早期的缺陷發現。
更重要的是,工作產品的作者學到了如何將工作做得更好,從而避免了缺陷。
2.固然同行評審的準備、活動和跟蹤需要花費一定的時間和工作量,但這些可以在測試中節省更多。從經濟角度考慮,
許多缺陷是在早期階段注入的,越早消除缺陷就越能降低開發成本。據統計,對於儲存精確記錄的大系統,
一套完整的同行評審體系能夠使項目在每個測試階段出現的錯誤減少了90%。這樣一來,即使在綜合考慮了同行評審活動成本的情況下,
同行評審活動也會使測試成本下降50%~80%。同時,通過同行評審,開發人員能夠及時地得到專家的協助和指導,
加深對工作成果的理解,更好地預防缺陷,在一定程度上提高了開發生產率。再者,消除工作成果的缺陷,可以提高產品品質,提高客戶滿意度。
軟體測試 總結