【文章內容簡介】 配置： 包括操作系統(tǒng)類型版本和補丁版本、當前被測試軟件的版本和補丁版本、相關支撐軟件，比如數(shù)據庫軟件的版本和補丁版本等。 硬件配置： 計算機的配置情況，主要包括 CPU 、內存和硬盤的相關參數(shù)，其它硬件參數(shù)根據測試用例的實際情況添加。如果測試中使用網絡，那么網絡的組網情況，網絡的容量、流量等情況。硬件配置情況與被測試產品類型密切相關，需要根據當時的情況，準確翔實的記錄硬件配置情況。 測試用例輸入 \ 操作步驟 \ 輸出： 這部分內容可以根據測試用例的描述和測試用例的實際執(zhí)行情況如實填寫。 輸出設備的相關輸出信息： 輸出設備包括計算機顯示器、打印機、磁帶等等輸出設備，如果是顯示器可以采用抓屏的方式獲取當時的截圖，其他的輸出設備可以采用其它方法獲取相關的輸出，在問題報告單中提供描述。 日志信息： 規(guī)范的軟件產品都會提供軟件的運行日志和用戶、管理員的操作日志，測試人員應該把測試用例執(zhí)行后的軟件產品運行日志和操作日志作為附件，提交到問題報告單中。 根據被測試軟件產品的不同，需要在 “ 問題描述 ” 中增加相應的描述內容，這需要具體問題具體分析。 1．6 測試結果分析 軟件測試執(zhí)行結束后，測試活動還沒有結束。測試結果分析是必不可少的重要環(huán)節(jié)， “ 編筐編簍，全在收口 ” ，測試結果的分析對下一輪測試工作的開展有很大的借鑒意義。前面的 “ 測試準備工作 ” 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發(fā)現(xiàn)的軟件缺陷。測試結束后，也應該分析自己發(fā)現(xiàn)的軟件缺陷，對發(fā)現(xiàn)的缺陷分類，你會發(fā)現(xiàn)自己提交的問題只有固定的幾個類別；然后，再把一起完成測試執(zhí)行工作的其他測試人員發(fā)現(xiàn)的問題也匯總起來，你會發(fā)現(xiàn)，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個測試人員都有自己思考問題的盲區(qū)和測試執(zhí)行的盲區(qū)，有效的自我分析和分析其他測試人員，你會發(fā)現(xiàn)自己的盲區(qū)，有針對性的分析盲區(qū)，必定會在下一輪測試用避免盲區(qū)。 1．7 總結 限于文章的篇幅，本文不可能給出一個類似于 checklist 的指導性的軟件測試新手入門。無論從事軟件測試還是從事其它的工作，技術上的和技巧上的問題都可以通過查詢相關的軟件測試技術書籍獲取，掌握一套基本的方法論是最重要的。以上文字，都是作者從事軟件測試工作積累的經驗之談，如發(fā)現(xiàn)謬誤之處請不吝指出。二 軟件測試的常識2．1 引言軟件開發(fā)和使用的歷史已經留給了我們很多由于軟件缺陷而導致的巨大財力、物力損失的經驗教訓。這些經驗教訓迫使我們這些測試工程師們必須采取強有力的檢測措施來檢測未發(fā)現(xiàn)的隱藏的軟件缺陷。 生產軟件的最終目的是為了滿足客戶需求，我們以客戶需求作為評判軟件質量的標準，認為軟件缺陷（ Software Bug ）的具體含義包括下面幾個因素： ? 軟件未達到客戶需求的功能和性能； ? 軟件超出客戶需求的范圍； ? 軟件出現(xiàn)客戶需求不能容忍的錯誤； ? 軟件的使用未能符合客戶的習慣和工作環(huán)境。 考慮到設計等方面的因素，我們還可以認為軟件缺陷還可以包括軟件設計不符合規(guī)范，未能在特定的條件（資金、范圍等）達到最佳等?？上У氖?，我們中的很多人更傾向于把軟件缺陷看成運行時出現(xiàn)問題上來，認為軟件測試僅限于程序提交之后。 在目前的國內環(huán)境下，我們幾乎看不到完整準確的客戶需求說明書，加以客戶的需求時時在變，追求完美的測試變得不太可能。因此作為一個優(yōu)異的測試人員，追求軟件質量的完美固然是我們的宗旨，但是明確軟件測試現(xiàn)實與理想的差距，在軟件測試中學會取舍和讓步，對軟件測試是有百益而無一弊的。 2．2 軟件測試常識下面是一些軟件測試的常識，對這些常識的理解和運用將有助于我們在進行軟件測試時能夠更好的把握軟件測試的尺度。 2．2．1 測試是不完全的（測試不完全） 很顯然，由于軟件需求的不完整性、軟件邏輯路徑的組合性、輸入數(shù)據的大量性及結果多樣性等因素，哪怕是一個極其簡單的程序，要想窮盡所有邏輯路徑，所有輸入數(shù)據和驗證所有結果是非常困難的一件事情。我們舉一個簡單的例子，比如說求兩個整數(shù)的最大公約數(shù)。其輸入信息為兩個正整數(shù)。但是如果我們將整個正整數(shù)域的數(shù)字進行一番測試的話，從其數(shù)目的無限性我們便可證明是這樣的測試在實際生活中是行不通的，即便某一天我們能夠窮盡該程序，只怕我們乃至我們的子孫都早已作古了。為此作為軟件測試，我們一般采用等價類和邊界值分析等措施來進行實際的軟件測試，尋找最小用例集合成為我們精簡測試復雜性的一條必經之道。 2．2．2 測試具有免疫性（軟件缺陷免疫性） 軟件缺陷與病毒一樣具有可怕的 “ 免疫性 ” ，測試人員對其采用的測試越多，其免疫能力就越強，尋找更多軟件缺陷就更加困難。由數(shù)學上的概率論我們可以推出這一結論。假設一個 50000 行的程序中有 500 個軟件缺陷并且這些軟件錯誤分布時均勻的，則每 100 行可以找到一個軟件缺陷。我們假設測試人員用某種方法花在查找軟件缺陷的精力為 X 小時 /100 行。照此推算，軟件存在 500 個缺陷時，我們查找一個軟件缺陷需要 X 小時，當軟件只存在 5 個錯誤時，我們每查找一個軟件缺陷需要 100X 小時。實踐證明，實際的測試過程比上面的假設更為苛刻，為此我們必須更換不同的測試方式和測試數(shù)據。該例子還說明了在軟件測試中采用單一的方法不能高效和完全的針對所有軟件缺陷，因此軟件測試應該盡可能的多采用多種途徑進行測試。 2．2．3 測試是 “ 泛型概念 ” （全程測試） 我一直反對軟件測試僅存在于程序完成之后。如果單純的只將程序設計階段后的階段稱之為軟件測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利于保證軟件質量。需求缺陷、設計缺陷也是軟件缺陷，記住 “ 軟件缺陷具有生育能力 ” 。軟件測試應該跨越整個軟件開發(fā)流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟件測試（建議稱為：需求測試和設計測試）的一種。軟件測試應該是一個泛型概念，涵蓋整個軟件生命周期，這樣才能確保周期的每個階段禁得起考驗。同時測試本身也需要有第三者進行評估（信息系統(tǒng)審計和軟件工程監(jiān)理），即測試本身也應當被測試，從而確保測試自身的可靠性和高效性。否則自身不正，難以服人。 另外還需指出的是軟件測試是提高軟件產品質量的必要條件而非充分條件，軟件測試是提高產品質量最直接、最快捷的手段，但決不是一個根本手段。 2．2．4 8020 原則 80% 的軟件缺陷常常生存在軟件 20% 的空間里。這個原則告訴我們，如果你想使軟件測試有效地話，記住常常光臨其高危多發(fā) “ 地段 ” 。在那里發(fā)現(xiàn)軟件缺陷的可能性會大的多。這一原則對于軟件測試人員提高測試效率及缺陷發(fā)現(xiàn)率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻仍在漫無目的地到處搜尋。 8020 原則的另外一種情況是，我們在系統(tǒng)分析、系統(tǒng)設計、系統(tǒng)實現(xiàn)階段的復審，測試工作中能夠發(fā)現(xiàn)和避免 80% 的軟件缺陷，此后的系統(tǒng)測試能夠幫助我們找出剩余缺陷中的 80% ，最后的 5% 的軟件缺陷可能只有在系統(tǒng)交付使用后用戶經過大范圍、長時間使用后才會曝露出來。因為軟件測試只能夠保證盡可能多地發(fā)現(xiàn)軟件缺陷，卻無法保證能夠發(fā)現(xiàn)所有的軟件缺陷。 8020 原則還能反映到軟件測試的自動化方面上來，實踐證明 80% 的軟件缺陷可以借助人工測試而發(fā)現(xiàn)， 20% 的軟件缺陷可以借助自動化測試能夠得以發(fā)現(xiàn)。由于這二者間具有交叉的部分，因此尚有 5% 左右的軟件缺陷需要通過其他方式進行發(fā)現(xiàn)和修正。 2．2．5 為效益而測試 為什么我們要實施軟件測試，是為了提高項目的質量效益最終以提高項目的總體效益。為此我們不難得出我們在實施軟件測試應該掌握的度。軟件測試應該在軟件測試成本和軟件質量效益兩者間找到一個平衡點。這個平衡點就是我們在實施軟件測試時應該遵守的度。單方面的追求都必然損害軟件測試存在的價值和意義。一般說來，在軟件測試中我們應該盡量地保持軟件測試簡單性，切勿將軟件測試過度復雜化，拿物理學家愛因斯坦的話說就是： Keep it simple but not too simple 。 2．2．6 缺陷的必然性 軟件測試中，由于錯誤的關聯(lián)性，并不是所有的軟件缺陷都能夠得以修復。某些軟件缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟件缺陷。很多軟件缺陷之間是相互矛盾的，一個矛盾的消失必然會引發(fā)另外一個矛盾的產生。比如我們在解決通用性的缺陷后往往會帶來執(zhí)行效率上的缺陷。更何況在缺陷的修復過程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟件缺陷。因此評估軟件缺陷的重要度、影響范圍，選擇一個折中的方案或是從非軟件的因素（比如提升硬件性能）考慮軟件缺陷成為我們在面對軟件缺陷時一個必須直面的事實。 2．2．7 軟件測試必須有預期結果沒有預期結果的測試是不可理喻的。軟件缺陷是經過對比而得出來的。這正如沒有標準無法進行度量一樣。如果我們事先不知道或是無法肯定預期的結果，我們必然無法了解測試正確性。這很容易然人感覺如盲人摸象一般，不少測試人員常常憑借自身的感覺去評判軟件缺陷的發(fā)生，其結果往往是把似是而非的東西作為正確的結果來判斷，因此常常出現(xiàn)誤測的現(xiàn)象。 2．2．8 軟件測試的意義 事后分析 軟件測試的目的單單是發(fā)現(xiàn)缺陷這么簡單嗎？如果是 “ 是 ” 的話，我敢保證，類似的軟件缺陷在下一次新項目的軟件測試中還會發(fā)生。古語說得好， “ 不知道歷史的人必然會重蹈覆轍 ” 。沒有對軟件測試結果進行認真的分析，我們就無法了解缺陷發(fā)生的原因和應對措施，結果是我們不得不耗費的大量的人力和物力來再次查找軟件缺陷。很可惜，目前大多測試團隊都沒有意識到這一點，測試報告中缺乏測試結果分析這一環(huán)節(jié)。 2．2．9 結論： 軟件測試是一個需要 “ 自覺 ” 的過程，作為一個測試人員，遇事沉著，把持尺度，從根本上應對軟件測試有著正確的認識，希望本文對讀者對軟件測試的認識有所幫助。三 淺談軟件開發(fā)中的注意事項本人從事了四年左右的軟件開發(fā)工作，曾參與開發(fā)過多個大型項目，對于整個項目開發(fā)中我覺得有很多地方都應該應當值得注意，特寫如下觀點和各位看客共同探討！3．1 項目設計項目設計的主導思想，我覺得可以理解為兩種，一種是完全設計，一個是簡單設計。完全設計是指在具體編寫代碼之前對軟件的各種方面都調查好，做好詳細的需求分析、編寫好全部的開發(fā)文檔，設計出程序全部流程后再開始寫代碼。 換句話說，就是全部的計劃好了，能看到最終的樣子，再開戰(zhàn)。這好像也是很多“軟件工程”書里要求的那樣。開始的時候，我覺得這種方法不錯也。什么都計劃好了，照著做就是了。不過這里有個明顯的問題，就是誰來做這個完美的計劃？估計只有及其BT的人了，但是大部分人的想要完全設計，并且沒有錯誤，或者已經有幾種后備的容錯方案，并能準確無誤的推行。以達到最終目標。這樣的境界，沒有很多年的工作經歷是不可能的。我也沒有這樣的本事，所以我也就放棄了這種想法。簡單設計：簡單設計一種概念，一種可以接受的簡單的設計，最起碼數(shù)據庫已經定下來，基本流程已經確定的方案，來作為程序設計的開始，并隨時根據實際情況的進展來修正具體的功能設計，但這種功能修改不能是修改數(shù)據庫結構。也就是說數(shù)據庫結構是在編程之前經過反復論證的。這種方法減少了前期設計的時間，把代碼編寫工作和部分設計工作放在了一起，實際縮短了項目開發(fā)的時間。如果說完全設計方法要求有很厲害的前期設計人員，那么簡單設計要求有很有設計頭腦的編程人員。編程人員不僅僅是K代碼的人而且要負責程序架構的設計。所以對程序員的要求就很高了。 簡單設計的成功的一個基點是編程人員設計的邏輯結構簡單并能根據需要來調整其邏輯結構，就是代碼結構靈活，簡單設計帶來的另外一個變化就是會議會比較多，編程人員之間的交流就變的很重要?，F(xiàn)在一般的中小型軟件公司基本上都是采用簡單設計的，除非那些很大型的軟件公司。總結，簡單設計考驗的是開發(fā)人員的能力。完全設計考驗的是前期設計人員和整個項目組完整能力。(各種文檔的編寫，開發(fā)人員一定會要寫一部分的。)3．2 設計變化和需求變化開發(fā)人員最怕的是什么呢？設計變化，還是需求變化？我覺得需求變化是最最致命的。當你的一個項目數(shù)據庫都定下來后，而且已經開發(fā)了若干個工作日，突然接到甲方公司提出，某個功能要改變，原先的需求分析要重新改，如果這個修改是涉及的數(shù)據庫的表結構更改的話，那真是最致命的。這就意味著項目的某些部分得重新推倒重來，如果這個部分跟已完成的多個部分有牽連的話，那就后果更可怕了。所以當碰到這種情況發(fā)生，作為項目經理的你就應該考慮先查責任人，究竟是自己的需求分析做的不夠好，還是客戶在認同了需求分析后做出的修改，如果是后者的話，你完全可以要求客戶對他的這個修改負責任！那么，呵呵，客戶先生，對不起了，本次新增加的需求將歸入另外一個版本。如果是改變前面某個需求的定義，那么說不定就要推倒重來了，不過這個時候到不用太在意，畢竟錯的是客戶。(項目正式開始前沒有沒有說清楚其需求)。所以，各位看客，在需求分析做好后，在開工之前一定要叫客戶認可簽字，并且在合同上要注明，當由客戶原因引起的需求改變而造成開發(fā)成本的增加，客戶要為此買單地。如果在需求不變的情況之下，設計發(fā)生了變化，這個僅僅是我們內部之間的矛盾，商量一下就能解決。在簡單設計中，因為前期的設計是不完整的，那么當進入任何一個新的模塊進行開發(fā)時，都有可能引起設計的變化。開發(fā)人員的水平的高低就基本上決定了軟件的好壞。3．3 代碼編寫當需求定下來數(shù)據庫也定下來后， 其實我們就可以進行實質性的編碼了，按照我的看法，一個人單獨編程最好，能隨時偷懶。(上網，和MM聊聊)，但是現(xiàn)在的軟件項目越來越大，工期也越來越緊，事實上我們一個小組里面，一般有35程序員，所以我們要強調團隊合作性。那么你寫的代碼使得別人要能夠看懂，我們必須在實際的編寫代碼過程中要有詳細的編碼規(guī)范，編碼規(guī)范在很多書籍里面都提到過。但最起碼以下的一些規(guī)范是我們必須要遵守的：3．3．1 源程序文件結構每個程序文件應由標題、內容和附加說明三部分組成。 （1）標題：文件最前面的注釋說明，其內容主要包括：程序名，作者，版權信息，簡要說明 等，