定義
      在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程。
      測試就是發現錯誤而執行程序的過程。
原則
      保證測試的覆蓋度，但是窮舉測試是不可能的。
      所有的測試都應該追溯到用戶。
      越早測越好，測試過程與開發過程應該是互相結合的。
      測試的規模 從小到大，從單元測試到系統測試。
      不能為了便于測試而擅自修改程序。
      既應該測試軟件能做什么，也應該測試軟件不能做什么。
度量
      測試覆蓋率
      缺陷發現率
      測試成功率（或者說用例通過率）
顯式條件：
     項目風險
      項目經費
隱含條件：
      老板們從當前的測試結果已經獲得了足夠的信心,或者徹底摧毀了信心。只要他們還在猶豫咱就得繼續干活。
測試的原則
測試只是展示缺陷
      測試只能表明缺陷存在,卻不能證明沒有缺陷。測試能降低未發現缺陷留存的概率,卻 不能證明軟件是絕對正確的。 正如某些數學命題,你可以窮舉 1-n,證明其正確,卻依然無法證明對于 n+1 仍然正確。
窮盡測試是不可能的
      測試所有的輸入和條件組合是不可能的,除非是極其簡單的情況。可以取而代之的是基 于風險和優先級的測試。 當不懂裝懂的老板要求你徹底測試一個軟件的時候,這是你反駁的最好支持,當然要說 的委婉一點
早期測試
      要較早發現缺陷,就要在軟件周期盡可能早的時候開始測試,而且要專注于已定義的測 試目標。 盡早開始測試!這句話估計早就把大家的耳朵磨起繭了。為什么要早?因為越早發現問 題,解決的代價就越小。
缺陷簇生
      要對缺陷發現率高的模塊投入更多的測試。少量的模塊往往隱藏了大部分的缺陷。 這不僅僅是所謂的物以類聚。缺陷發現率高的模塊往往于需求不清,設計不當,編碼復 雜度高等內在原因關聯,所以從風險的角度來看必然較高,多花些時間絕對值得。
殺蟲劑悖論
      相同的測試再重復多次后就無法再找到缺陷了。要克服“殺蟲劑悖論”,測試用例要不斷評審修改,不斷添加新的和不同的測試,就有可能找到更多缺陷。 隨著對系統的加深理解,必然會有更多的測試用例產生。另外缺陷本身也是新用例的很好來源。
測試是上下文相關的
      測試在不同上下文環境中的執行是不同的。比方說安全關鍵系統 (safety critical system)和電子商務網站的測試方法就有很大不同。 這個原理相對難理解。這里其實強調的是不能用相同的態度和手段來測試不同類型的系 統。安全關鍵系統的概念要到高級大綱中才出現,指的是對系統安全要求苛刻的系統, 較之一般的電子商務系統的測試要求更為嚴苛。
無錯謬論
      假如建立的系統不穩定或不能滿足用戶需要和期望,那么發現和修復缺陷就毫無幫助了。 缺陷數量往往用來評估某軟件的質量,但要是系統本身背離了用戶要求,那就算缺陷再 少也沒用,因為沒有人會去用它。所以測試時要注意驗證(verification)和確認(validation)的區別。需求規格說明和其他文檔只是需求的不完全載體。文字說明必然有遺漏和偏差, 而各人的理解更有可能出錯。要不斷通過各種途徑保證所生產的的確就是用戶需要的。 常用的方式就是邀請領域專家或用戶盡可能多地參與到開發活動來,特別是需求評審和演示(Demo)。

      測試做到什么程度并沒有一個固定答案。只要滿足兩個顯式條件和一個隱含條件就要一直進行。

      本文由培訓無憂網千鋒教育專屬課程顧問整理發布，希望能夠對想學習軟件測試培訓的同學有所幫助。更多軟件測試培訓課程歡迎關注培訓無憂網軟件測試培訓培訓頻道或添加老師微信：15033336050

      注：尊重原創文章,轉載請注明出處和鏈接 http://m.dedgn.cn/news-id-12722.html 違者必究！部分文章來源于網絡由培訓無憂網編輯部人員整理發布,內容真實性請自行核實或聯系我們，了解更多相關資訊請關注軟件測試頻道查看更多，了解相關專業課程信息您可在線咨詢也可免費申請試課。關注官方微信了解更多：150 3333 6050