人們共同關注的焦點。不論軟件的生產者還是軟件的使用者，均生存在競爭的環境中，軟
件開發商為了占有市場，必須把產品質量作為企業的重要目標之一，以免在激烈的競爭中
被淘汰出局。用戶為了保證自己業務的順利完成，當然希望選用優質的軟件。質量不佳的
軟件產品不僅會使開發商的維護費用和用戶的使用成本大幅增加，還可能產生其他的責任
風險，造成公司信譽下降，繼而沖擊股票市場。在一些關鍵應用 (如民航訂票系統、銀行
結算系統、證券交易系統、自動飛行控制軟件、軍事防御和核電站安全控制系統等) 中使
用質量有問題的軟件，還可能造成災難性的后果。
軟件危機曾經是軟件界甚至整個計算機界最熱門的話題。為了解決這場危機，軟件從
業人員、專家和學者做出了大量的努力�，F在人們已經逐步認識到所謂的軟件危機實際上
僅是一種狀況，那就是軟件中有錯誤，正是這些錯誤導致了軟件開發在成本、進度和質量
上的失控。有錯是軟件的屬性，而且是無法改變的，因為軟件是由人來完成的，所有由人
做的工作都不會是完美無缺的。問題在于我們如何去避免錯誤的產生和消除已經產生的錯
誤，使程序中的錯誤密度達到盡可能低的程度。
給軟件帶來錯誤的原因很多，具體地說，主要有如下幾點：
①、交流不夠、交流上有誤解或者根本不進行交流
在應用應該做什么或不應該做什么的細節(應用的需求)不清晰的情況下進行開發。
②、軟件復雜性
圖形用戶界面(GUI)，客戶/服務器結構，分布式應用，數據通信，超大型關系型數據
庫以及龐大的系統規模，使得軟件及系統的復雜性呈指數增長，沒有現代軟件開發經驗的
人很難理解它。
③、程序設計錯誤
象所有的人一樣，程序員也會出錯。
④、需求變化
需求變化的影響是多方面的，客戶可能不了解需求變化帶來的影響，也可能知道但又
不得不那么做。需求變化的后果可能是造成系統的重新設計，設計人員的日程的重新安排
，已經完成的工作可能要重做或者完全拋棄，對其他項目產生影響，硬件需求可能要因此
改變，等等。如果有許多小的改變或者一次大的變化，項目各部分之間已知或未知的依賴
性可能會相互影響而導致更多問題的出現，需求改變帶來的復雜性可能導致錯誤，還可能
影響工程參與者的積極性。
⑤、時間壓力
軟件項目的日程表很難做到準確，很多時候需要預計和猜測。當最終期限迫近和關鍵
時刻到來之際，錯誤也就跟著來了。
⑥、自負人更喜歡說:
'沒問題'
'這事情很容易'
'幾個小時我就能拿出來'
太多不切實際的‘沒問題’，結果只能是引入錯誤。
⑦、代碼文檔貧乏
貧乏或者差勁的文檔使得代碼維護和修改變的異常艱辛，其結果是帶來許多錯誤。事
實上，在許多機構并不鼓勵其程序員為代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和
容易理解，相反他們認為少寫文檔可以更快的進行編碼，無法理解的代碼更易于工作的保
密(“寫得艱難必定讀的痛苦”)。
⑧、軟件開發工具
可視化工具，類庫，編譯器，腳本工具，等等，它們常常會將自身的錯誤帶到應用軟
件中。就象我們所知道的，沒有良好的工程化作為基礎，使用面向對象的技術只會使項目
變得更復雜。 為了更好地解決這些問題，軟件界做出了各種各樣的努力。
人們曾經認為更好的程序語言可以使我們擺脫這些困擾，這推動了程序設計語言的發
展，更多的語言開始流行，為了使程序更易于理解開發了結構化程序設計語言，如PL/1,P
ASCAL等；為了解決實時多任務需求開發了結構化多任務程序設計語言，如Modula，Ada等
；為了提高重用性開發了面向對象的程序設計語言，如Simlasa等；為了避免產生不正確的
需求理解，開發形式化描述語言，如HAL/S等，這使得建立基于自然語言的描述成為可能，
人們以形式化語言來描述需求；為了支持大型數據庫應用，開發了可視化工具，如Visual
Studio、Power Builder等。程序語言對提高軟件生產效率起到了一定的積極作用，但它
對整個軟件質量尤其是可靠性的影響，與其他因素相比作用較小。
可能是因為程序語言基于嚴格的語法和語義規則，人們企圖用形式化證明方法來證明
程序的正確性。將程序當作數學對象來看待，從數學意義上證明程序是正確的是可能的。
數學家對形式化證明方法最有興趣，在論文上談起來非常吸引人，但實際價值卻非常有限
，因為形式化證明方法只有在代碼寫出來之后才能使用，這顯然太遲了，而且對于大的程
序證明起來非常困難。 受到其他行業項目工程化的啟發，軟件工程學出現了，軟件開發被
視為一項工程，以工程化的方法來進行規劃和管理軟件的開發。
針對需求不確定的應用，可以使用漸進和迭代類的開發模型。還可以采用快速應用程
序開發(RAD)和協同應用程序開發（JAD）技術，由軟件開發者和用戶代表共同參與開發軟
件規范。RAD和JAD的基本思路是開發者和用戶共同設計系統中的屏幕，開發者迅速地把實
現這些屏幕的最基本功能編寫好，然后把它們交給用戶看，然后用戶和開發者回顧這些屏
幕以確認它們達到了用戶的要求，這個周期一直持續到系統的基本部分定義完畢。一旦設
計被用戶接受，開發者將完成完全實現屏幕需要的代碼。RAD和傳統軟件開發項目之間的一
個基本區別是：應用程序RAD系統是按階段發布的。傳統項目一般一次發布，也叫“big b
ang”。RAD方法使用高效開發工具，開發者能夠非常迅速地設計出系統的基本屏幕，允許
用戶在開發周期中很早就能見識到系統將來看起來怎么樣，避免了在傳統開發項目中長篇
大論并且枯燥難懂的說明。
IBM的Dr.Harlan Mills提出了凈室過程。凈室過程組合了形式化程序驗證和統計過程
控制(SPC)。在這種方法中，首先用正確性數學證明預防缺陷發生，然后用MTBF度量軟件質
量。凈室過程是一種相當新的軟件開發方法，它要求軟件開發在管理方式和技術方法上作
重大改變，特別是要求SPC應用到軟件的知識，這影響了其被廣泛的接受。
硬件成本持續降低，可支持CASE工具運行的新的強大的工作站和網絡已經成為軟件工
程使用的工作平臺，CASE工具可完成一些特定的軟件開發過程。這些工具提供給軟件設計
者以圖形方式描述軟件設計的能力，這樣就易于維護、易于交叉檢查、易于理解。許多人
（尤其是CASE工具供貨商）相信CASE工具扮演了解決軟件危機和拯救軟件工業的角色，但
事實上我們看到的情形卻是許多公司花了大量的金錢買回的CASE工具但很少使用，原因在
于這些工具執行的過程與機構的軟件設計過程不相適用。
在可以借助許多新的技術和工具進行軟件開發的今天，軟件開發過程的成熟性問題開
始引起人們的重視。這種產品一致性問題的主要癥結在于管理，因此人們將目標轉向了管
理的改善，一些以改進軟件開發過程為目標的活動已經展示出積極的結果。
以下是一些比較典型的文本。
SEI SW-CMM
ISO SPICE(Software Process Improvement and Capability dEtermination)
Bootstrap
ISO-9000-3
TickIT
Trillium
事實上，對于軟件來講，還沒有象銀彈那樣的東西。不論采用什么技術和什么方法，
軟件中仍然會有錯。采用新的語言、先進的開發方式、完善的開發過程，可以減少錯誤的
引入，但是不可能完全杜絕軟件中的錯誤，這些引入的錯誤需要測試來找出，軟件中的錯
誤密度也需要測試來進行估計。 測試是所有工程學科的基本組成單元，是軟件開發的重要
部分。自有程序設計的那天起測試就一直伴隨著。統計表明，在典型的軟件開發項目中，
軟件測試工作量往往占軟件開發總工作量的40％以上。而在軟件開發的總成本中，用在測
試上的開銷要占30％到50％。如果把維護階段也考慮在內，討論整個軟件生存期時，測試
的成本比例也許會有所降低，但實際上維護工作相當于二次開發，乃至多次開發，其中必
定還包含有許多測試工作。因此，測試對于軟件生產來說是必需的，問題是我們應該思考
“采用什么方法、如何安排測試?”
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
