【導(dǎo)讀】使用人工或自動手段來運行或測定某個系統(tǒng)的過程，結(jié)果與實際結(jié)果之間的差別。程提高過程能力，最終降低缺陷數(shù)量和缺陷密度。質(zhì)量的一種方法。你在學(xué)校里學(xué)過測試嗎？你所在的企業(yè)重視測試嗎？（小公司程序員的技能。臨時抱佛腳行嗎？你以為有文檔模板就會測試了嗎？如果不懂得有效地進行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲勞。職業(yè)軟件工程師應(yīng)當(dāng)掌握需求開發(fā)、系統(tǒng)設(shè)計、編?！胺侄沃钡乃枷?。單元測試的粒度最小，一般由開發(fā)小組采用白盒方式來測試，主要測試單元是否符合“設(shè)計”。集成測試界于單元測試和系統(tǒng)測試之間，起到“橋梁作用”，驗收測試與系統(tǒng)測試非常相似，主要區(qū)別是測試人員不同，驗收測試由用戶執(zhí)行。當(dāng)缺陷引發(fā)運行錯誤或產(chǎn)生負面影響時，構(gòu)。成事故，造成損失或傷害。到正確的預(yù)期結(jié)果。3)盡可能避免測試自己寫的程序。堅持獨立測試原則，必要的

　　

【正文】 理論 七、 一些問題 ? 問題 2：由于單元測試要寫測試驅(qū)動程序，非常麻煩，能否等到整個系統(tǒng)全部開發(fā)完后，再集中精力進行一次性地單元測試呢？ ?如果這樣做，在開發(fā)過程中，缺陷會越積越多并且分布得更廣、隱藏得更深，反而導(dǎo)致測試與改錯的代價大大增加。最糟糕的是無法估計測試與改錯的工作量，使進度失去控制。因此為圖眼前省事而省略單元測試或者 “ 偷工減料 ” ，是 “ 得不償失 ” 的做法。 167。 4 軟件測試的一般性理論 七、 一些問題 ? 問題 3：如果每個單元都通過了測試，把它們集成一起難道會有什么不妥嗎？集成測試是否多此一舉？ ?要把 N個單元集成一起肯定靠接口耦合 ， 這時可能會產(chǎn)生在單元測試中無法發(fā)現(xiàn)的問題 。 例如：數(shù)據(jù)通過不同的接口時可能出錯；幾個函數(shù)關(guān)聯(lián)在一起時可能達不到預(yù)期的功能；在某個單元里可以接受的誤差可能在集成后被擴大到無法接受的程度 。 所以集成測試是必要的 ， 不是多此一舉 。 167。 4 軟件測試的一般性理論 七、 一些問題 ? 問題 4：在集成測試的時候，已經(jīng)對一些子系統(tǒng)進行了功能測試、性能測試等等，那么在系統(tǒng)測試時能否跳過相同內(nèi)容的測試 ? ?不能！因為集成測試是在仿真環(huán)境中開展的，那不是真正的目標系統(tǒng)。再者，單元測試和集成測試通常由開發(fā)小組執(zhí)行。根據(jù)測試心理學(xué)的分析，開發(fā)人員測試自己的工作成果雖然是必要的，但不能作為成果已經(jīng)通過測試的依據(jù)。 167。 4 軟件測試的一般性理論 七、 一些問題 ? 問題 5：既然系統(tǒng)測試與驗收測試的內(nèi)容幾乎是相同的，為什么還要驗收測試？ ? 首先是 “ 信任 ” 問題。對于合同項目而言，如果測試小組是開發(fā)方的人員，客戶怎么能夠輕易相信 “ 別人 ” 呢 ? 所以當(dāng)項目進行系統(tǒng)測試之后，客戶再進行驗收測試是情理之中的事。否則，那是客戶失職。 ? 不論是合同項目還是非合同項目，軟件的最終用戶各色各樣（如受教育程度不同、使用習(xí)慣不同等等）。測試小組至多能夠模仿小部分用戶的行為，但并不具有普遍的代表性。 167。 4 軟件測試的一般性理論 七、 一些問題 ? 問題 6：能否將系統(tǒng)測試和驗收測試 “ 合二為一 ” ？ ? 系統(tǒng)測試不是一會兒就能做完的 ， 比較長時間的用戶測試很難組織 。 用戶還有自己的事情要做 ， 他們?yōu)槭裁匆獮閯e人測試呢 ？ 即使用戶愿意做系統(tǒng)測試 ， 他們消耗的時間 、花費的金錢大多比測試小組的高 。 ? 系統(tǒng)測試時會找出相當(dāng)多的軟件缺陷，軟件需要反反復(fù)復(fù)地改錯。如果讓用戶發(fā)現(xiàn) “ 內(nèi)幕 ” ，一是丟臉，二是會嚇跑買主。所以還是關(guān)起門來，先讓測試小組做完系統(tǒng)測試的好。 167。 5 軟件測試的挑戰(zhàn)和問題 一、如何正確對待測試工作 １．明確測試工作意義 ２．加強責(zé)任心，疏忽可能造成惡果 ３．學(xué)習(xí) ——實踐 ——鉆研，積累經(jīng)驗， 努力提高業(yè)務(wù)水平 ４．處理好與編程人員關(guān)系 167。 5 軟件測試的挑戰(zhàn)和問題 對于測試人員的職業(yè)素質(zhì)要求： ? 責(zé)任感 ? 堅持原則、不放棄 ? 有問題及時匯報 ? 溝通能力、移情能力 ? 與用戶、項目組的溝通 ? 獨立的判斷和自學(xué)習(xí)能力 ? 堅持觀點，不隨聲附和 ? 喜歡探尋、鉆牛角尖不一定是壞事情 ? 耐心、自我督促 ? 團隊精神 ? 與開發(fā)組整體為一個目標開展活動，有時需要妥協(xié) 167。 5軟件測試的挑戰(zhàn)和問題 二、測試工作評估問題 1. 你單位是否有專人負責(zé)測試工作？ 2. 你們是否有、是否用測試計劃規(guī)范？ 3. 你們是否有、是否用單元計劃規(guī)范？ 4. 你們是否有、是否用測試報告規(guī)范？ 5. 測試過程（包括計劃和實施）與整個開發(fā)過程是否并行開展？（測試在開發(fā)初期著手，在開發(fā)結(jié)束完成） 6. 測試能夠確認規(guī)格說明得到正確的實現(xiàn)嗎？ 7. 除規(guī)格說明以外，你能否確認用戶的期望也能滿足嗎？ 8. 測試人員能驗證開發(fā)的階段（如需求和設(shè)計）的精確性和完全性嗎？ 9. 測試人員向開發(fā)人員報告缺陷以期進一步采取措施嗎？ 10. 在制定計劃之前測試人員能估計業(yè)務(wù)風(fēng)險嗎？ 167。 5 軟件測試的挑戰(zhàn)和問題 11. 針對被測軟件是否提出了可度量的測試目標？ 12. 如已提出，它與商業(yè)風(fēng)險有關(guān)嗎？ 13. 測試中發(fā)現(xiàn)的缺陷是否做了紀錄和總結(jié)，使其用于改進開發(fā)過程和測試過程？ 14. 測試人員是否根據(jù)以前的工作經(jīng)驗判斷可能的缺陷？ 15. 是否有改進測試過程的辦法？ 16. 你為缺陷命名嗎？ 17. 是否利用缺陷記錄、總結(jié)和事故數(shù)據(jù)來評價測試過程的有效性？ 18. 是否采用度量（如千行代碼缺陷數(shù)）來計劃和評價測試過程？ 19. 是否已建立了測試人員的培訓(xùn)制度？ 20. 采用測試工具來支持測試過程嗎？ 三、不同等級的測試機構(gòu) 否 狀態(tài) 特點 1 1720 把測試工作當(dāng)作技藝 (art) ?測試依賴于測試人員個人的技巧和創(chuàng)造性 ?對測試人員無指導(dǎo)，無要求 ?測試工作效果不穩(wěn)定，有時好，有時糟 ?顧客和用戶不能靠測試的有效性判斷質(zhì)量 2 1316 把測試工作當(dāng)作工藝 (craft) ?有測試過程、規(guī)范、標準和測試計劃 ?測試計劃得不到實施 ?測試人員只熱衷于找缺陷，報告開發(fā)人員 ?用戶不信任測試過程，只好做驗收測試 3 912 執(zhí)行已確切定義的測試過程 ?測試過程已被定義，單位但未得到有效執(zhí)行 ?測試工作針對規(guī)格說明，重視問題的需求 ?測試結(jié)束時沒有提供表明被測軟件能否投入使用的正式報告 三、不同等級的測試機構(gòu) 4 58 先進的測試機構(gòu) ?有明確的測試目標，可優(yōu)化利用測試資源實現(xiàn)目標 ?重視測試過程薄弱環(huán)節(jié)的改進 5 04 最先進的測試機構(gòu) ?測試工作基于降低風(fēng)險，測試人員工作有效 ?測試得到度量，過程得到很好定義 ?缺陷得到記錄、分析和總結(jié)，且用其改進過程 ?測試成本顯著下降 ?顧客和用戶相信測試過程，不依靠驗收測試取得滿意產(chǎn)品 167。 5 軟件測試的挑戰(zhàn)和問題 四、小結(jié) １選擇測試用例是測試工作的關(guān)鍵 ２測試的有效性不應(yīng)被忽視測試后評審其充分性 ３重要的是何時停止測試 ４回歸測試一定不可省 167。 5 軟件測試的挑戰(zhàn)和問題 五、經(jīng)驗之談 ? 測試能提高軟件的質(zhì)量，但是提高質(zhì)量不能依賴測試。 ? 測試只能證明缺陷存在，不能證明缺陷不存在。 “ 徹底地測試 ” 難以成為現(xiàn)實，要考慮時間、費用等限制，不允許無休止地測試。我們應(yīng)當(dāng)祈禱：軟件的缺陷在產(chǎn)品被淘汰之前一直沒有機會發(fā)作。 ? 測試的主要困難是不知道如何進行有效地測試，也不知道什么時候可以放心地結(jié)束測試。 ? 每個開發(fā)人員應(yīng)當(dāng)測試自己的程序（份內(nèi)之事），但是不能作為該程序已經(jīng)通過測試的依據(jù)（所以項目需要獨立測試人員）。 ? 8020原則： 80％的缺陷聚集在 20％的模塊中，經(jīng)常出錯的模塊改錯后還會經(jīng)常出錯 ? 測試應(yīng)當(dāng)循序漸進，不要企圖一次性干完，注意 “ 欲速則不達 ” 。