一、概述二、軟件測試的目的三、軟件測試的基本方法四、軟件測試的復雜性與經(jīng)濟性五、軟件測試的心理學問題六、好的測試工程師應具備的素質(zhì)七、參考文獻一、概述
信息技術(shù)的飛速發(fā)展，使軟件產(chǎn)品應用到社會的各個領(lǐng)域，軟件產(chǎn)品的質(zhì)量自然成為人們共同關(guān)注的焦點。不論軟件的生產(chǎn)者還是軟件的使用者，均生存在競爭的環(huán)境中，軟件開發(fā)商為了占有市場，必須把產(chǎn)品質(zhì)量作為企業(yè)的重要目標之一，以免在激烈的競爭中被淘汰出局。用戶為了保證自己業(yè)務的順利完成，當然希望選用優(yōu)質(zhì)的軟件。質(zhì)量不佳的軟件產(chǎn)品不僅會使開發(fā)商的維護費用和用戶的使用成本大幅增加，還可能產(chǎn)生其他的責任風險，造成公司信譽下降，繼而沖擊股票市場。在一些關(guān)鍵應用 (如民航訂票系統(tǒng)、銀行結(jié)算系統(tǒng)、證券交易系統(tǒng)、自動飛行控制軟件、軍事防御和核電站安全控制系統(tǒng)等) 中使用質(zhì)量有問題的軟件，還可能造成災難性的后果。
軟件危機曾經(jīng)是軟件界甚至整個計算機界最熱門的話題。為了解決這場危機，軟件從業(yè)人員、專家和學者做出了大量的努力?，F(xiàn)在人們已經(jīng)逐步認識到所謂的軟件危機實際上僅是一種狀況，那就是軟件中有錯誤，正是這些錯誤導致了軟件開發(fā)在成本、進度和質(zhì)量上的失控。有錯是軟件的屬性，而且是無法改變的，因為軟件是由人來完成的，所有由人做的工作都不會是完美無缺的。問題在于我們?nèi)绾稳ケ苊忮e誤的產(chǎn)生和消除已經(jīng)產(chǎn)生的錯誤，使程序中的錯誤密度達到盡可能低的程度。
給軟件帶來錯誤的原因很多，具體地說，主要有如下幾點：
①、交流不夠、交流上有誤解或者根本不進行交流
在應用應該做什么或不應該做什么的細節(jié)(應用的需求)不清晰的情況下進行開發(fā)。
②、軟件復雜性
圖形用戶界面(GUI)，客戶/服務器結(jié)構(gòu)，分布式應用，數(shù)據(jù)通信，超大型關(guān)系型數(shù)據(jù)庫以及龐大的系統(tǒng)規(guī)模，使得軟件及系統(tǒng)的復雜性呈指數(shù)增長，沒有現(xiàn)代軟件開發(fā)經(jīng)驗的人很難理解它。
③、程序設(shè)計錯誤
向所有的人一樣，程序員也會出錯。
④、需求變化
需求變化的影響是多方面的，客戶可能不了解需求變化帶來的影響，也可能知道但又不得不那么做。需求變化的后果可能是造成系統(tǒng)的重新設(shè)計，設(shè)計人員的日程的重新安排，已經(jīng)完成的工作可能要重做或者完全拋棄，對其他項目產(chǎn)生影響，硬件需求可能要因此改變，等等。如果有許多小的改變或者一次大的變化，項目各部分之間已知或未知的依賴性可能會相互影響而導致更多問題的出現(xiàn)，需求改變帶來的復雜性可能導致錯誤，還可能影響工程參與者的積極性。
⑤、時間壓力
軟件項目的日程表很難做到準確，很多時候需要預計和猜測。當最終期限迫近和關(guān)鍵時刻到來之際，錯誤也就跟著來了。
⑥、自負人更喜歡說:
‘沒問題‘
‘這事情很容易‘
‘幾個小時我就能拿出來‘
太多不切實際的‘沒問題’，結(jié)果只能是引入錯誤。
⑦、代碼文檔貧乏
貧乏或者差勁的文檔使得代碼維護和修改變的異常艱辛，其結(jié)果是帶來許多錯誤。事實上，在許多機構(gòu)并不鼓勵其程序員為代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和容易理解，相反他們認為少寫文檔可以更快的進行編碼，無法理解的代碼更易于工作的保密(“寫得艱難必定讀的痛苦”)。
⑧、軟件開發(fā)工具
可視化工具，類庫，編譯器，腳本工具，等等，它們常常會將自身的錯誤帶到應用軟件中。就象我們所知道的，沒有良好的工程化作為基礎(chǔ)，使用面向?qū)ο蟮募夹g(shù)只會使項目變得更復雜。
為了更好地解決這些問題，軟件界做出了各種各樣的努力。
人們曾經(jīng)認為更好的程序語言可以使我們擺脫這些困擾，這推動了程序設(shè)計語言的發(fā)展，更多的語言開始流行，為了使程序更易于理解開發(fā)了結(jié)構(gòu)化程序設(shè)計語言，如PL/1,PASCAL等；為了解決實時多任務需求開發(fā)了結(jié)構(gòu)化多任務程序設(shè)計語言，如Modula，Ada等；為了提高重用性開發(fā)了面向?qū)ο蟮某绦蛟O(shè)計語言，如Simlasa等；為了避免產(chǎn)生不正確的需求理解，開發(fā)形式化描述語言，如HAL/S等，這使得建立基于自然語言的描述成為可能，人們以形式化語言來描述需求；為了支持大型數(shù)據(jù)庫應用，開發(fā)了可視化工具，如Visual Studio、Power Builder等。程序語言對提高軟件生產(chǎn)效率起到了一定的積極作用，但它對整個軟件質(zhì)量尤其是可靠性的影響，與其他因素相比作用較小。
可能是因為程序語言基于嚴格的語法和語義規(guī)則，人們企圖用形式化證明方法來證明程序的正確性。將程序當作數(shù)學對象來看待，從數(shù)學意義上證明程序是正確的是可能的。數(shù)學家對形式化證明方法最有興趣，在論文上談起來非常吸引人，但實際價值卻非常有限，因為形式化證明方法只有在代碼寫出來之后才能使用，這顯然太遲了，而且對于大的程序證明起來非常困難。
受到其他行業(yè)項目工程化的啟發(fā)，軟件工程學出現(xiàn)了，軟件開發(fā)被視為一項工程，以工程化的方法來進行規(guī)劃和管理軟件的開發(fā)。
針對需求不確定的應用，可以使用漸進和迭代類的開發(fā)模型。還可以采用快速應用程序開發(fā)(RAD)和協(xié)同應用程序開發(fā)（JAD）技術(shù)，由軟件開發(fā)者和用戶代表共同參與開發(fā)軟件規(guī)范。RAD和JAD的基本思路是開發(fā)者和用戶共同設(shè)計系統(tǒng)中的屏幕，開發(fā)者迅速地把實現(xiàn)這些屏幕的最基本功能編寫好，然后把它們交給用戶看，然后用戶和開發(fā)者回顧這些屏幕以確認它們達到了用戶的要求，這個周期一直持續(xù)到系統(tǒng)的基本部分定義完畢。一旦設(shè)計被用戶接受，開發(fā)者將完成完全實現(xiàn)屏幕需要的代碼。RAD和傳統(tǒng)軟件開發(fā)項目之間的一個基本區(qū)別是：應用程序RAD系統(tǒng)是按階段發(fā)布的。傳統(tǒng)項目一般一次發(fā)布，也叫“big bang”。RAD方法使用高效開發(fā)工具，開發(fā)者能夠非常迅速地設(shè)計出系統(tǒng)的基本屏幕，允許用戶在開發(fā)周期中很早就能見識到系統(tǒng)將來看起來怎么樣，避免了在傳統(tǒng)開發(fā)項目中長篇大論并且枯燥難懂的說明。
IBM的Dr.Harlan Mills提出了凈室過程。凈室過程組合了形式化程序驗證和統(tǒng)計過程控制(SPC)。在這種方法中，首先用正確性數(shù)學證明預防缺陷發(fā)生，然后用MTBF度量軟件質(zhì)量。凈室過程是一種相當新的軟件開發(fā)方法，它要求軟件開發(fā)在管理方式和技術(shù)方法上作重大改變，特別是要求SPC應用到軟件的知識，這影響了其被廣泛的接受。
硬件成本持續(xù)降低，可支持CASE工具運行的新的強大的工作站和網(wǎng)絡(luò)已經(jīng)成為軟件工程使用的工作平臺，CASE工具可完成一些特定的軟件開發(fā)過程。這些工具提供給軟件設(shè)計者以圖形方式描述軟件設(shè)計的能力，這樣就易于維護、易于交叉檢查、易于理解。許多人（尤其是CASE工具供貨商）相信CASE工具扮演了解決軟件危機和拯救軟件工業(yè)的角色，但事實上我們看到的情形卻是許多公司花了大量的金錢買回的CASE工具但很少使用，原因在于這些工具執(zhí)行的過程與機構(gòu)的軟件設(shè)計過程不相適用。
在可以借助許多新的技術(shù)和工具進行軟件開發(fā)的今天，軟件開發(fā)過程的成熟性問題開始引起人們的重視。這種產(chǎn)品一致性問題的主要癥結(jié)在于管理，因此人們將目標轉(zhuǎn)向了管理的改善，一些以改進軟件開發(fā)過程為目標的活動已經(jīng)展示出積極的結(jié)果。
以下是一些比較典型的文本。
SEI SW-CMM
ISO SPICE(Software Process Improvement and Capability dEtermination)
Bootstrap
ISO-9000-3
TickIT
Trillium
事實上，對于軟件來講，還沒有象銀彈那樣的東西。不論采用什么技術(shù)和什么方法，軟件中仍然會有錯。采用新的語言、先進的開發(fā)方式、完善的開發(fā)過程，可以減少錯誤的引入，但是不可能完全杜絕軟件中的錯誤，這些引入的錯誤需要測試來找出，軟件中的錯誤密度也需要測試來進行估計。
測試是所有工程學科的基本組成單元，是軟件開發(fā)的重要部分。自有程序設(shè)計的那天起測試就一直伴隨著。統(tǒng)計表明，在典型的軟件開發(fā)項目中，軟件測試工作量往往占軟件開發(fā)總工作量的40％以上。而在軟件開發(fā)的總成本中，用在測試上的開銷要占30％到50％。如果把維護階段也考慮在內(nèi)，討論整個軟件生存期時，測試的成本比例也許會有所降低，但實際上維護工作相當于二次開發(fā)，乃至多次開發(fā)，其中必定還包含有許多測試工作。因此，測試對于軟件生產(chǎn)來說是必需的，問題是我們應該思考“采用什么方法、如何安排測試?”
二、軟件測試的目的
軟件測試的目的決定了如何去組織測試。如果測試的目的是為了盡可能多地找出錯誤，那么測試就應該直接針對軟件比較復雜的部分或是以前出錯比較多的位置。如果測試目的是為了給最終用戶提供具有一定可信度的質(zhì)量評價，那么測試就應該直接針對在實際應用中會經(jīng)常用到的商業(yè)假設(shè)。
不同的機構(gòu)會有不同的測試目的；相同的機構(gòu)也可能有不同測試目的，可能是測試不同區(qū)域或是對同一區(qū)域的不同層次的測試。
在談到軟件測試時，許多人都引用Grenford J. Myers在《The Art of Software Testing》一書中的觀點：
①、軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程；
②、測試是為了證明程序有錯，而不是證明程序無錯誤。
③、一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；
④、一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。
這種觀點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這一觀點可能會產(chǎn)生誤導，認為發(fā)現(xiàn)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。
首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，這種分析也能幫助我們設(shè)計出有針對性地檢測方法，改善測試的有效性。
其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定測試質(zhì)量的一種方法。詳細而嚴謹?shù)目煽啃栽鲩L模型可以證明這一點。例如 Bev Littlewood發(fā)現(xiàn)一個經(jīng)過測試而正常運行了n小時的系統(tǒng)有繼續(xù)正常運行n小時的概率。
三、軟件測試的基本方法
軟件測試的方法和技術(shù)是多種多樣的。
對于軟件測試技術(shù)，可以從不同的角度加以分類：
從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試和動態(tài)測試。
從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實現(xiàn)算法的角度來看，可分為白盒測試和黑盒測試；
1、黑盒測試
黑盒測試也稱功能測試或數(shù)據(jù)驅(qū)動測試，它是在已知產(chǎn)品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，測試者在程序接口進行測試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用于軟件確認測試。
“黑盒”法著眼于程序外部結(jié)構(gòu)、不考慮內(nèi)部邏輯結(jié)構(gòu)、針對軟件界面和軟件功能進行測試?！昂诤小狈ㄊ歉F舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
2、白盒測試
白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅(qū)動、基路測試等，主要用于軟件驗證。
“白盒”法全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進行測試?！鞍缀小狈ㄊ歉F舉路徑測試。在使用這一方案時，測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。貫穿程序的獨立路徑數(shù)是天文數(shù)字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。
3．ALAC(Act-like-a-customer)測試
ALAC測試是一種基于客戶使用產(chǎn)品的知識開發(fā)出來的測試方法。ALAC測試是基于復雜的軟件產(chǎn)品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。
四、軟件測試的復雜性與經(jīng)濟性
人們常常以為，開發(fā)一個程序是困難的，測試一個程序則比較容易。這其實是誤解。設(shè)計測試用例是一項細致并需要高度技巧的工作，稍有不慎就會顧此失彼，發(fā)生不應有的疏漏。
不論是黑盒測試方法還是白盒測試方法，由于測試情況數(shù)量巨大，都不可能進行徹底的測試。所謂徹底測試，就是讓被測程序在一切可能的輸入情況下全部執(zhí)行一遍。通常也稱這種測試為“窮舉測試”。 “黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。 “白盒”法是窮舉路徑測試，貫穿程序的獨立路徑數(shù)是天文數(shù)字，但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設(shè)計規(guī)范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。E．W．Dijkstra的一句名言對測試的不徹底性作了很好的注解：“程序測試只能證明錯誤的存在，但不能證明錯誤不存在”。
在實際測試中，窮舉測試工作量太大，實踐上行不通，這就注定了一切實際測試都是不徹底的。當然就不能夠保證被測試程序中不存在遺留的錯誤。軟件工程的總目標是充分利用有限的人力和物力資源，高效率、高質(zhì)量地完成測試。為了降低測試成本，選擇測試用例時應注意遵守“經(jīng)濟性”的原則。第一，要根據(jù)程序的重要性和一旦發(fā)生故障將造成的損失來確定它的測試等級；第二，要認真研究測試策略，以便能使用盡可能少的測試用例，發(fā)現(xiàn)盡可能多的程序錯誤。掌握好測試量是至關(guān)重要的，一位有經(jīng)驗的軟件開發(fā)管理人員在談到軟件測試時曾這樣說過：“不充分的測試是愚蠢的，而過度的測試是一種罪孽”。測試不足意味著讓用戶承擔隱藏錯誤帶來的危險，過度測試則會浪費許多寶貴的資源。
測試是軟件生存期中費用消耗最大的環(huán)節(jié)。測試費用除了測試的直接消耗外，還包括其它的相關(guān)費用。能夠決定需要做多少次測試的主要影響因素如下：
①、系統(tǒng)的目的
系統(tǒng)的目的的差別在很大程度上影響所需要進行的測試的數(shù)量。那些可能產(chǎn)生嚴重后果的系統(tǒng)必須要進行更多的測試。一臺在Boeing 757上的系統(tǒng)應該比一個用于公共圖書館中檢索資料的系統(tǒng)需要更多的測試。一個用來控制密封燃氣管道的系統(tǒng)應該比一個與有毒爆炸物品無關(guān)的系統(tǒng)有更高的可信度。一個安全關(guān)鍵軟件的開發(fā)組比一個游戲軟件開發(fā)組要有苛刻得多的查找錯誤方面的要求。
②、潛在的用戶數(shù)量
一個系統(tǒng)的潛在用戶數(shù)量也在很大程度上影響了測試必要性的程度。這主要是由于用戶團體在經(jīng)濟方面的影響。一個在全世界范圍內(nèi)有幾千個用戶的系統(tǒng)肯定比一個只在辦公室中運行的有兩三個用戶的系統(tǒng)需要更多的測試。如果不能使用的話，前一個系統(tǒng)的經(jīng)濟影響肯定比后一個系統(tǒng)大。除此而外，在分配處理錯誤的時候，所花的代價的差別也很大。如果在內(nèi)部系統(tǒng)中發(fā)現(xiàn)了一個嚴重的錯誤，在處理錯誤的時候的費用就相對少一些，如果要處理一個遍布全世界的錯誤就需要花費相當大的財力和精力。
③、信息的價值
在考慮測試的必要性時，還需要將系統(tǒng)中所包含的信息的價值考慮在內(nèi)，一個支持許多家大銀行或眾多證券交易所的客戶機/服務器系統(tǒng)中含有經(jīng)濟價值非常高的內(nèi)容。很顯然這一系統(tǒng)需要比一個支持鞋店的系統(tǒng)要進行更多的測試。這兩個系統(tǒng)的用戶都希望得到高質(zhì)量、無錯誤的系統(tǒng)，但是前一種系統(tǒng)的影響比后一種要大得多。因此我們應該從經(jīng)濟方面考慮，投入與經(jīng)濟價值相對應的時間和金錢去進行測試。
④、開發(fā)機構(gòu)
一個沒有標準和缺少經(jīng)驗的開發(fā)機構(gòu)很可能開發(fā)出充滿錯誤的系統(tǒng)。在一個建立了標準和有很多經(jīng)驗的開發(fā)機構(gòu)中開發(fā)出來的系統(tǒng)中的錯誤不會很多，因此，對于不同的開發(fā)機構(gòu)來說，所需要的測試的必要性也就截然的不同。
然而，那些需要進行大幅度改善的機構(gòu)反而不大可能認識到自身的弱點。那些需要更加嚴格的測試過程的機構(gòu)往往是最不可能進行這一活動的，在許多情況下，機構(gòu)的管理部門并不能真正地理解開發(fā)一個高質(zhì)量的系統(tǒng)的好處。
⑤、測試的時機
測試量會隨時間的推移發(fā)生改變。在一個竟爭很激烈的市場里，爭取時間可能是制勝的關(guān)鍵，開始可能不會在測試上花多少時間，但幾年后如果市場分配格局已經(jīng)建立起來了，那么產(chǎn)品的質(zhì)量就變得更重要了，測試量就要加大。測試量應該針對合適的目標進行調(diào)整。
五、軟件測試的心理學問題
1、程序測試的過程具有破壞性
人類的活動具有高度的目的性，建立適當?shù)哪繕司哂兄匾男睦碜饔?。如果我們的目的是要證明程序中沒有錯誤，那我們就會不自覺地朝這個方向去做；也就是說，我們會傾向于挑選那些使程序出錯的可能性較小的測試數(shù)據(jù)。另一方面，如果我們的目標是要證明程序中有錯，那就會選擇一些易于發(fā)現(xiàn)程序所含錯誤的測試數(shù)據(jù)。而后一種態(tài)度會比前者給程序增添更多的價值。
測試的定義意味著程序測試的過程是具有破壞性的，其程度甚至達到了不可容忍的地步。社會上大多數(shù)人的人生觀是建設(shè)性的，而不是破壞性的。人們傾向于創(chuàng)造一個物品，而不是輕易毀壞—個物品。因此，程序壞—個物品。因此，程序測試的破壞性的定義使人們對程序測試工作望而生畏。程序測試定義還隱含著如何設(shè)計測試情況（測過數(shù)據(jù)），以及應該由誰和不應由誰來測試一個給定程序等等觀點。
心理學研究還告訴我們，當人在干一件已經(jīng)知道是不合適的或不可能做到的事時，往往做得不好。例如：如果讓一個人在15分鐘解出一個刊登在星期曰《紐約時報》上的交叉填字字謎，10分鐘后我們會看到這人幾乎沒一點進展，因為他會感到實際上不可能做到而放棄自已的努力。然而，如果我們要求花4小時解出這題，那也許就會看到他在開頭的10分鐘內(nèi)有較大的進展了。把程序測試定義為在程序中找出錯誤的過程，就使測試成了可以做到的任務，從而克服了心理上存在的問題。
另一個令人煩躁的問題是即使程序完成了預期要求，仍可能含有錯誤。也就是說，如果程序不按要求工作，它顯然有錯，但是如果程序做了不要它做的事，它也有錯。
2、程序員應避免測試自己的程序
開發(fā)者被指定測試自己的代碼是一件很糟糕的事。開發(fā)和測試生來就是不同的活動。開發(fā)是創(chuàng)造或者建立什么東西的行為，一個模塊或者整個系統(tǒng)。而測試的唯一目的是證明一個模塊或者系統(tǒng)工作不正常。這兩個活動之間有著本質(zhì)的矛盾。一個人不太可能把兩個截然對立的角色都扮演的很好?；谶@個想法，應該限制開發(fā)者在測試中的參與。給他們比較合適的任務是進行有可能的最低層的測試--單元測試。不同當一個程序員在完成了設(shè)計，編寫程序的建設(shè)性工作后，要一夜之間突然改變他的觀點，設(shè)法對程序形成一個完全否定的態(tài)度，那是非常困難的。許多戶主都知道，揭掉糊墻紙（破壞性過程〉是不容易的，若糊墻紙原先是由他而不是別人貼上的，他幾平會感到難以忍受的沮喪。所以，大部分程序員都由于不能使自己進入必要的精神狀態(tài)（不是抱著要揭露出自己程序中錯誤的態(tài)度），因而不能有效地測試自己的程序。
除了這個心理學問題之外，還有一個重要的問題：程序中可能包含由于程序員對問題的敘述或說明的誤解而產(chǎn)生的錯誤。如果是這種情況，當程序員測試自己的程序時，往往還會帶著同樣的誤解致使問題難以發(fā)現(xiàn)。
再者，可以把測試看做是對一篇論文或—本書作校對，或與寫評論相類似的工作。正如許多作者所知，校對或批評自己的著作是非常困難的。也就是說，在自已的工作中找出缺陷往往是人的心理狀態(tài)所不容的。
以上看法并不意味著程序員不可能測試自已的程序。不過相比之下如果由另外—些人來進行程序測試，就會更有效、更成功。注意：這個論斷并不適用于糾錯（改正已知錯誤），由原來程序的作者糾錯肯定效率更高。
3、程庫設(shè)計機構(gòu)不應測試自己的程序
在許多意義上來說，一項工程或一程序設(shè)計機構(gòu)是個有生命的有機體，它同樣有心理學問題。再者，在大多數(shù)情況下，人們都是以在給定日期內(nèi)，以一定代價編制程序的能力來衡量程序設(shè)計機構(gòu)和項目管理人員的。這祥做的一個理由是時間和成本指標便于衡量，而程序的可靠性卻很難度量。要程序設(shè)計機構(gòu)在測試自己的程序時持客觀態(tài)度是困難的，因為如果用正確的定義看待測試，就不大可能按預定計劃完成測試也不大可能把耗費的代價限制在要求的范圍以內(nèi)。
計算技術(shù)的進步，意味著在經(jīng)濟領(lǐng)域中信息系統(tǒng)更新的速度更快。新的硬件技術(shù)的發(fā)展，均會使軟件過時，系統(tǒng)交付使用的時間變得日益重要，新產(chǎn)品在其性能和費用上被其他產(chǎn)品取代之前的推銷時間，即市場窗口就已經(jīng)縮小了。
由于費用和進度的限制，要開發(fā)一種高質(zhì)量、快速交付和低成本的軟件產(chǎn)品變得越來越困難，也就是說要同時達到三個目標是困難的。因此在軟件產(chǎn)品的開發(fā)中就要權(quán)衡它們之間的關(guān)系，使軟件的特性能滿足用戶的要求，這意味著軟件產(chǎn)品特性的度量和預計是必要的。
軟件測試由獨立測試機構(gòu)承擔有許多好處。獨立測試是指軟件測試工作由在經(jīng)濟上和管理上獨立于開發(fā)機構(gòu)的組織進行。獨立測試可以避免軟件開發(fā)者測試自己開發(fā)的軟件，由于心理學上的問題，軟件開發(fā)者難以客觀、有效地測試自己的軟件，而找出那些因為對問題的誤解而產(chǎn)生的錯誤就更加困難。獨立測試還可以避免軟件開發(fā)機構(gòu)測試自己的軟件，軟件產(chǎn)品的開發(fā)過程受到時間、成本和質(zhì)量三者的制約，時間和成本指標便于衡量，而質(zhì)量卻很難度量，因此在軟件開發(fā)過程中，當時間、成本和質(zhì)量三者發(fā)生矛盾時，質(zhì)量最容易被忽視，如果測試組織與開發(fā)組織來自相同的機構(gòu)，測試過程就會面臨來自與開發(fā)組織同一來源的管理方面的壓力，使測試過程受到干擾。
采用獨立測試方式，無論在技術(shù)上還是管理上，對提高軟件測試的有效性都具有重要意義。
①、客觀性
對軟件測試和軟件中的錯誤抱著客觀的態(tài)度，這種客觀的態(tài)度可以解決測試中的心理學問題，既能夠以揭露軟件中錯誤的態(tài)度工作，也能不受發(fā)現(xiàn)的錯誤的影響。經(jīng)濟上的獨立性使其工作有更充分的條件按測試要求去完成。
②、專業(yè)性
獨立測試作為一種專業(yè)工作，在長期的工作過程中勢必能夠積累大量實踐經(jīng)驗，形成自己的專業(yè)優(yōu)勢。同時軟件測試也是技術(shù)含量很高的工作，需要有專業(yè)隊伍加以研究，并進行工程實踐。專業(yè)化分工是提高測試水平，保證測試質(zhì)量，充分發(fā)揮測試效用的必然途徑。
③、權(quán)威性
由于專業(yè)優(yōu)勢，獨立測試工作形成的測試結(jié)果更具信服力，而測試結(jié)果常常和對軟件的質(zhì)量評價聯(lián)系在一起，由專業(yè)化的獨立測試機構(gòu)的評價，更客觀、公正和具有權(quán)威性。
④、資源有保證
獨立測試機構(gòu)的主要任務是進行獨立測試工作，這使得測試工作在經(jīng)費、人力和計劃方面更有保證，不會因為開發(fā)的壓力減少對測試的投入，降低測試的有效性，可以避免開發(fā)單位側(cè)重軟件開發(fā)而對測試工作產(chǎn)生不利的影響。
六、好的測試工程師應具備的素質(zhì)
人是測試工作中最有價值也是最重要的資源，沒有一個合格的、積極的測試小組，測試就不可能實現(xiàn)。然而，在軟件開發(fā)產(chǎn)業(yè)中有一種非常普遍習慣，那就是讓那些經(jīng)驗最少的新手、沒有效率的開發(fā)者或不適合干其他工作的人去做測試工作。這絕對是一種目光短淺的行為，對一個系統(tǒng)進行有效的測試所需要的技能絕對不比進行軟件開發(fā)需要的少，事實上，測試者將獲得極其廣泛的經(jīng)驗，他們將遇到許多開發(fā)者不可能遇到的問題。
①、溝通能力。
一名理想的測試者必須能夠同測試涉及到的所有人進行溝通，具有與技術(shù)（開發(fā)者）和非技術(shù)人員（客戶，管理人員）的交流能力。既要可以和用戶談得來，又能同開發(fā)人員說得上話，不幸的是這兩類人沒有共同語言。和用戶談話的重點必須放在系統(tǒng)可以正確地處理什么和不可以處理什么上。而和開發(fā)者談相同的信息時，就必須將這些活重新組織以另一種方式表達出來，測試小組的成員必須能夠同等地同用戶和開發(fā)者溝通。
②、移情能力。
和系統(tǒng)開發(fā)有關(guān)的所有人員都處在一種既關(guān)心又擔心的狀態(tài)之中。用戶擔心將來使用一個不符合自己要求的系統(tǒng)，開發(fā)者則擔心由于系統(tǒng)要求不正確而使他不得不重新開發(fā)整個系統(tǒng)，管理部門則擔心這個系統(tǒng)突然崩潰而使它的聲譽受損。測試者必須和每一類人打交道，因此需要測試小組的成員對他們每個人都具有足夠的理解和同情，具備了這種能力可以將測試人員與相關(guān)人員之間的沖突和對抗減少到最低程度。
③、技術(shù)能力。
就總體言，開發(fā)人員對那些不懂技術(shù)的人持一種輕視的態(tài)度。一旦測試小組的某個成員作出了一個錯誤的斷定，那么他們的可信度就會立刻被傳揚了出去。一個測試者必須既明白被測軟件系統(tǒng)的概念又要會使用工程中的那些工具。要做到這一點需要有幾年以上的編程經(jīng)驗，前期的開發(fā)經(jīng)驗可以幫助對軟件開發(fā)過程有較深入的理解，從開發(fā)人員的角度正確的評價測試者，簡化自動測試工具編程的學習曲線。
④、自信心。
開發(fā)者指責測試者出了錯是常有的事，測試者必須對自己的觀點有足夠的自信心。如果容許別人對自己指東指西，就不能完成什么更多的事情了。
⑤、外交能力。
當你告訴某人他出了錯時，就必須使用一些外交方法。機智老練和外交手法有助于維護與開發(fā)人員的協(xié)作關(guān)系，測試者在告訴開發(fā)者他的軟件有錯誤時，也同樣需要一定的外交手腕。如果采取的方法過于強硬，對測試者來說，在以后和開發(fā)部門的合作方面就相當于“贏了戰(zhàn)爭卻輸了戰(zhàn)役”。
⑥、幽默感。
在遇到狡辯的情況下，一個幽默的批評將是很有幫助的。
⑦、很強的記憶力。
一個理想的測試者應該有能力將以前曾經(jīng)遇到過的類似的錯誤從記憶深處挖掘出來，這一能力在測試過程中的價值是無法衡量的。因為許多新出現(xiàn)的問題和我們已經(jīng)發(fā)現(xiàn)的問題相差無幾。
⑧、耐心。
一些質(zhì)量保證工作需要難以置信的耐心。有時你需要花費驚人的時間去分離、識別和分派一個錯誤。這個工作是那些坐不住的人無法完成的。
⑨、懷疑精神。
可以預料，開發(fā)者會盡他們最大的努力將所有的錯誤解釋過去。測式者必須聽每個人的說明，但他必須保持懷疑直到他自己看過以后。
⑩、自我督促。
干測試工作很容易使你變得懶散。只有那些具有自我督促能力的人才能夠使自己每天正常地工作。
11、洞察力。
一個好的測試工程師具有“測試是為了破壞”的觀點，捕獲用戶觀點的能力，強烈的質(zhì)量追求，對細節(jié)的關(guān)注能力。應用的高風險區(qū)的判斷能力以便將有限的測試針對重點環(huán)節(jié)。
七、參考文獻
1、Grenford J. Myers，《The Art of Software Testing》
