軟件測試與改錯——掌握有效測試的方法與技術(shù)林銳博士-資料下載頁
2024-09-28 09:29本頁面
【導(dǎo)讀】如果不懂得有效地進(jìn)行測試，你不僅得不到功勞，也沒人欣賞你的苦勞，你擁有最多的將只是疲。職業(yè)軟件工程師應(yīng)當(dāng)掌握需求開發(fā)、系統(tǒng)設(shè)計、編程、測試、維護(hù)所有技能。所以測試人員的職責(zé)是設(shè)計這樣的測試用例。，它能有效地揭示潛伏在軟件里的缺陷。千萬不要將“測試”與“演示”混為一談。例如科研鑒定會。如果產(chǎn)品通過了嚴(yán)格的測試，大家不要不吭氣，應(yīng)當(dāng)好好地宣傳一把。測試只能證明缺陷存在，不能證明缺陷不存在?！皬氐椎販y試”難以成為現(xiàn)實，要考慮時間、費。用等限制，不允許無休止地測試。單元測試的粒度最小，一般由開發(fā)小組采用白盒方式來測試，主要測試單元是否符合“設(shè)計”。集成測試界于單元測試和系統(tǒng)測試之間，起到“橋梁作用”，一般由開發(fā)小組采用白盒加黑盒的。測試的目的是找出盡可能多的缺陷。所以測試是“破壞性”的，而開發(fā)卻是“建設(shè)性”的。
【正文】 以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。如果改過了成千上萬個程序錯誤，那么少男少女們不必經(jīng)歷失戀的挫折也能變得成熟起來。 ? 軟件中的錯誤通常只有開發(fā)者自己才能找出并改掉。如果因畏懼而拖延，會讓你終日心情不定，食無味，睡不香。所以長痛不如短痛，要集中精力對付錯誤。 ? 東北有個林場工人，工作勤奮，一人能干幾個人的活。前三十年是伐樹勞模，受到周總理的接見。忽有一天醒悟過來，覺得自己太對不起森林，決心補救錯誤。后三十年成了植樹勞模，受到朱總理的接見。若能以此大勇來改錯，正是無往而不勝也。我們軟件開發(fā)人員應(yīng)當(dāng)向這位可敬的林場工人學(xué)習(xí)。 Page 34 7. 改錯的方法 對癥下藥 ? 改錯的第一步是找出錯誤的根源，如同醫(yī)生治病，必須先找出病因才能“對癥下藥”。改錯過程很像偵破案件，有些壞事發(fā)生了，而僅有的信息就是它的確發(fā)生了。我們必須從結(jié)果出發(fā)，逆向思考。一旦找到了根源，我們就知道如何改正了。 – 有人問阿凡提：“我肚子痛，應(yīng)該用什么藥？” 阿凡提說：“應(yīng)該用眼藥水，因為你眼睛不好，吃了臟東西才肚子痛。” ? 根據(jù)軟件錯誤的癥狀推斷出根源并不是件容易的事 ， 因為： – （ 1） 癥狀和根源可能相隔很遠(yuǎn) 。 也就是說 ， 癥狀可能在某一個程序單元中出現(xiàn) ， 而根源實際上在很遠(yuǎn)的另一個地方 。 高度耦合的程序結(jié)構(gòu)加劇了這種情況 。 – （ 2） 癥狀可能在另一個錯誤被糾正后暫時性消失 。 – （ 3） 癥狀可能并不是由某個程序錯誤直接引發(fā)的 ， 如誤差累積 。 – （ 4） 癥狀可能是由不太容易跟蹤的人工錯誤引起的 。 – （ 5） 癥狀可能時隱時現(xiàn) ， 如內(nèi)存泄漏 。 – （ 6） 很難重新產(chǎn)生完全一樣的輸入條件 ， 難以恢復(fù) “ 錯誤的現(xiàn)場 ” 。 – （ 7）癥狀可能分布在許多不同的任務(wù)中，難以跟蹤。 ? 人們把尋找錯誤根源的過程稱為調(diào)試（ debugging）。 Page 35 7. 改錯的方法 硬件的調(diào)試方法 ? 硬件調(diào)試據(jù)說繼承了中醫(yī)的 “ 望聞聽切 ” 診斷方法： – （ 1） 望 ， 即用眼睛查看哪些地方是否有破損 。 – （ 2） 聞 ， 即用鼻子聞哪些地方是否有燒焦的味道 。 – （ 3） 聽 ， 即用耳朵聽哪些地方是否有異常的噪聲 。 – （ 4） 切 ， 即用手觸摸哪些地方是否異常發(fā)燙 。 ? 據(jù)有經(jīng)驗的電器修理工說 ， “ 望聞聽切 ” 這 4招能解決大部分問題 。 ? 通常軟件改錯要比硬件改錯的代價低 ， 因為后者經(jīng)常拋棄原來的東西 。 軟件的調(diào)試方法 ? 軟件調(diào)試的基本方法是“粗分細(xì)找”。對于隱藏得很深的 Bug， 我們應(yīng)該運用歸納、推理、“二分”等方法先“快速、粗略”地確定錯誤根源的范圍，然后再用調(diào)試工具仔細(xì)地跟蹤此范圍的源代碼。如果沒有調(diào)試工具，那么只好用“土辦法”：在程序中插入打印語句如 printf， 觀看屏幕的輸出。 ? 有些時候，世界上最好的調(diào)試工具恐怕是那些有經(jīng)驗的人。我們經(jīng)常會長時間地追蹤某個 Bug，苦惱萬分。恰好有高手路過，被他一語“道破天機”，頓時沮喪的陰云就被驅(qū)散。 ? 改錯的最大忌諱是“急躁蠻干”。人們常說“急中生智”，我不信。我認(rèn)為大多數(shù)人著急了就會蠻干，早把“智”丟到腦后。不僅人如此，動物也如此。 – 蜜蜂和麻雀撞玻璃的故事 …… Page 36 7. 改錯的方法 改錯時的注意事項 ? （ 1） 找到錯誤的代碼時 ， 不要急于修改 ， 先思考一下：修改此代碼會不會引發(fā)其它問題 ？ 如果沒有問題 ， 可以放心修改 。 如果有問題 ， 那么可能要改動程序結(jié)構(gòu) ， 而不止一行代碼 。 ? （ 2） 有些時候 ， 軟件中可能潛伏同一類型的許多錯誤 （ 例如由不良的編程習(xí)慣引起的 ） 。 好不容易逮住一個 ， 應(yīng)當(dāng)乘勝追擊 ， 全部殲滅 。 ? （ 3） 在改錯之后一定要馬上進(jìn)行回歸測試 ， 以免引入新的錯誤 。 改了一個程序錯誤固然是喜事， 但要防止樂極生悲 。 更加嚴(yán)格的要求是：不論原先程序是否絕對正確 ， 只要對此程序作過改動（ 哪怕是微不足道的 ） ， 都要進(jìn)行回歸測試 。 ? （ 4）上述事情做完后，應(yīng)當(dāng)好好反思：我為什么會犯這樣的錯誤？怎么能夠防止下次不犯相似的錯誤？最好能寫下心得體會，與他人共享經(jīng)驗教訓(xùn)。 Page 37 8. 小結(jié) ? 優(yōu)秀的程序員敢于聲稱自己編寫的代碼沒有錯誤，這種自信讓人羨慕不已。一個錯誤自身也許很微小，但是程序存在錯誤這件事很嚴(yán)重。能否做好測試工作，態(tài)度是很關(guān)鍵的。 ? 測試的真正動機是為了讓軟件賺更多的錢，所以人們在執(zhí)行測試之前至少要搞清楚兩個問題：（1）要測試什么東西？（ 2）怎樣有效地測試？ ? 程序員應(yīng)該把測試當(dāng)成份內(nèi)之事，不要過分依賴于外界的 “ 黑盒測試 ” 。 “ 黑盒測試 ” 就象通過提問題來判斷一個人是否是個瘋子，但無法知道他為什么成了瘋子。讓程序員先對自己的代碼進(jìn)行白盒測試并非多此一舉，這將使以后的日子更加輕松，并且習(xí)慣了就感覺不到有什么不方便。 ? 程序出了錯誤一定要改錯，但是“編寫優(yōu)質(zhì)無錯”的程序才是根本的解決之道。在此，我竭力建議大家閱讀 Steve Maguire著的《 Writing Clean Code : Microsoft Techniques for Developing Bugfree C Programs》（ 有中文譯本， [Maguire 1993]）。 我深受此書的教誨，獲益非淺。 ? 開發(fā)人員總是要經(jīng)常面對各種各樣的 Bug， 但是不要過于煩惱 ， 不要忘記 “ 每天都是生活 ” 。 要懂一點養(yǎng)生之道 ， 尤其要正常作息 ， 過正常人的生活 。 熬夜編程只能偶爾為之 ， 不可習(xí)以為常 ，否則不知不覺地傷害了身體健康 ， 很不值得 。
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1