在軟件開發(fā)過程中，軟件質(zhì)量是軟件工程中一個經(jīng)常被忽略的要素。在現(xiàn)代的RAD領域和視頻開發(fā)領域，軟件質(zhì)量幾乎是被人忽略的。標準組織不厭其煩地對軟件質(zhì)量作出規(guī)范，有些甚至提供了用來度量軟件質(zhì)量的工具、評價等級及證明。許多政府要求軟件承包商遵守一定的公共標準。但對于大多數(shù)人來說，軟件質(zhì)量是由用戶喜歡使用軟件的程度決定的。如果軟件運行得好，則視其質(zhì)量好，反之，則不好。這給人們對軟件質(zhì)量的評價標準方式造成錯覺。

　　越來越多的公司在購買軟件時有了這樣一個概念，即軟件質(zhì)量是一個過程，從軟件應用開始，直到停止使用為止。許多組織都確認自己在軟件質(zhì)量方面投入了大量資金，但同時又承認在許多關鍵任務的應用中，許多軟件質(zhì)量標準是強制執(zhí)行的結(jié)果，而非通過嚴格控制成本的戰(zhàn)術或戰(zhàn)略來實現(xiàn)。

　　軟件質(zhì)量工程耗資不低，而且也不易實現(xiàn)，但如果實施的早，達到高水平就相對要容易些。質(zhì)量從分析和設計開始，貫穿整個構造過程，并在測試和開發(fā)過程中不斷完善。在使用應用軟件的維護階段，質(zhì)量不易完善。度量軟件質(zhì)量并不是件容易的事。我曾經(jīng)做過調(diào)查，問一些開發(fā)人員在他們的應用軟件出臺之前進行多少次合理的編碼檢查？回答是28％。沒有檢查編碼的原因是由于計劃完成的期限太短，時間和資源不充足。組織不能簡單地為全職的軟件測試者提供時間和資金。由于這些客觀原因，我們需要找到提高質(zhì)量的方法。

　　在這里我們不但強調(diào)軟件質(zhì)量的重要性，也想找出度量軟件質(zhì)量的方法，以及確定我們要達到怎樣的質(zhì)量水平和借助何種工具才能及時正確地完成任務。

　　什么是軟件質(zhì)量

　　所謂軟件質(zhì)量就是對應用軟件的質(zhì)量進行三個主要方面的度量：編碼、功能、性能。沒有充分的分析和設計就不可能達到較高的軟件質(zhì)量。過于簡單，難以滿足功能或性能上的需求，也就談不到編寫出好的軟件。一個不符合用戶需求的軟件就是失敗。

　　要說清楚正確的發(fā)現(xiàn)和設計路徑需要許多筆墨，并不是區(qū)區(qū)一篇文章就能夠完成的，但有些公司如Rational 及Riverton等公司花費了大量的時間和金錢創(chuàng)建了能夠幫助提高分析設計階段質(zhì)量的產(chǎn)品。我向大家強力推薦Riverton公司的HOW系列產(chǎn)品，它運載于PowerBuilder上，是免費的。提高了第一階段的質(zhì)量也就等于提高了整個應用軟件的質(zhì)量。本文更側(cè)重軟件質(zhì)量的物理方面，讓我們從編碼開始談起。

　　編碼質(zhì)量

　　編碼質(zhì)量是應用軟件的健康診斷。你可以想象編碼就是應用軟件的肺。無論看起來多小的缺陷都會影響整體健康，可能引起呼吸（運行）的中斷。

　　我們學習怎樣更好地做事，但我們學到的往往是經(jīng)驗。經(jīng)驗的不利之處在于只有在我們經(jīng)歷過之后它才成為經(jīng)驗。而對目前應用的軟件來說已太遲，沒有什么幫助，只能寄希望于下一次的軟件。更有利的辦法是與其他軟件開發(fā)者共同學習，分享經(jīng)驗。

　　SEI的研究表明，經(jīng)過軟件質(zhì)量培訓的開發(fā)人員編寫的軟件錯誤更少，能減少50％以上。研究還表明稍稍經(jīng)過培訓，便會加速經(jīng)驗的獲得。培訓是一個解決辦法，對已完成工作進行度量是另一個方法。我們可以建立幾個可度量的編碼質(zhì)量的目錄：

　　遵守工業(yè)及企業(yè)標準，遵守編碼規(guī)則和結(jié)構標準，可提高其可用性及可維護性、最佳實際應用。

　　企業(yè)標準依據(jù)其背景而變化。微軟的商品遵循微軟標準，Unix商品遵循Unix標準。直到PowerBuilder基礎等級（PFC）的數(shù)據(jù)庫出現(xiàn)，PowerBuilder的開發(fā)人員才獲得了對買方標準的一些提示�，F(xiàn)在許多公司遵循PFC命名約定，因為它最接近于工業(yè)標準體系結(jié)構。這就是說，甚至連Sybase都不遵循自己的標準，而是遵守PFC標準。PFC的版本6集成了一些它自己對外公布命名規(guī)范的結(jié)構標準。

　　關鍵的一點是如果什么也不做就誰也幫不了你。學習的關鍵是經(jīng)驗。如果你不知道自己已擁有經(jīng)驗，你就無法從中獲益。你知道的越早就越有效。你可以通過實施一些標準加速此過程。這完成了兩個目標：

　　要實施標準，必須先度量。如果你度量應用標準及質(zhì)量，開發(fā)人員就會對所度量的要素及他們出的錯誤更清楚，加強了目標的認識。糾正發(fā)現(xiàn)的問題并找到錯誤原因，可以再次提醒開發(fā)人員要達到的目標，并指出達到的方法。

　　一旦進行度量，應用軟件中不通順的地方立刻被糾正。可以達到兩個目的：最終的編碼十分整潔，具有高質(zhì)量；開發(fā)人員完成這一步就會得到最重要的益處——經(jīng)驗。

　　功能性質(zhì)量

　　功能性質(zhì)量是度量應用軟件與其用戶需求的匹配程度，即完成必要性功能的好壞，以及是否完成了所有必要的功能。你可以想象這是應用軟件的大腦。如果所有必需的功能并沒有全部完成，那么其結(jié)果難以預測。

　　由于許多應用已事先規(guī)定應該怎樣，所以功能性質(zhì)量比編碼質(zhì)量更難度量。只有對開發(fā)完的應用才能度量。這意味著改變代價很大。我們應該怎樣度量？在開發(fā)周期的早期階段應該做什么才能保證我們正朝著更高質(zhì)量的目標前進？

　　我們應當保證應用滿足客戶提出的所有需求。這主要取決于開發(fā)過程的一開始這些需求被確定的程度，但這可通過檢驗正進行的基礎來保證它符合需求目的。這是一個手工完成的測試，但有些自動工具如Rational ClearQuest也可以跟蹤設計、構造、測試等不同階段。我們還必須保證為滿足需求而設計的商業(yè)功能完全，用好、壞或沒有輸入來檢驗。養(yǎng)成用這種方法測試商業(yè)功能可以達到更高質(zhì)量。

　　測試的另一方面是應用編碼。這需要花費更多的時間，因為每一個編寫的功或沒有輸入來檢驗。養(yǎng)成用這種方法測試商業(yè)功能可以達到更高質(zhì)量。

　　測試的另一方面是應用編碼。這需要花費更多的時間，因為每一個編寫的功能都必須經(jīng)過檢驗以確保它的運行完全符合所期待的那樣。這便是這些能夠生成測試案例的自動工具的有價值之處，但并不是所有自動工具都能達到這樣的水平。有些工具能夠通過運行測試案例看應用軟件的每一部分是否經(jīng)過了檢查，如Rational公司的 Teamtest、Mercury公司的 WinRunner產(chǎn)品，但沒有一個自動工具能生成你所必需的測試。

　　我們要強調(diào)的第三個方面是應用軟件能否實現(xiàn)設計的功能，更重要的是它是否有效，這就需要開發(fā)人員與用戶之間進行交流，比較初始步驟和需求，檢查它們在應用中是否相符。

　　最后，我們應該確保應用軟件具有要求的一切功能。一個有效的應用軟件能完成一半需求不是非常有用，而一個能夠完成所有需求的應用軟件卻附加了一些用戶不需要的過程和商業(yè)功能，也不是有效的，而且容易導致用戶及軟件支持程序員的混亂。這也應該由需求管理。

　　顯然，關鍵因素在于需求。需求必須詳細列出，在整個過程中保持記錄，并且所有應用編碼都應由需求證實。需求管理十分重要，它形成了CMM的脊柱——允許企業(yè)檢驗自己所處的等級。這里有五個等級。所有公司至少在等級1，極少數(shù)在等級5.通過這些等級，我們可以看出關鍵問題是需求管理。需求帶動了應用的整個最高目的。根據(jù)SEI，達到等級3的公司可以在產(chǎn)量及質(zhì)量方面提高200％到300％。

　　性能

　　這是軟件質(zhì)量的注意力最集中的方面。性能是每個應用的表現(xiàn)。性能可以分為以下四個部分：用戶性能、客戶端應用性能、網(wǎng)絡性能、可伸縮性性能。

　　用戶性能是最難度量的部分。用戶對兩個方面感興趣：第一，完成任務的速度。如果它比以前的方法耗費時間還長，那么，即使是世界上運行最快的編碼用戶也感覺很慢。第二，感覺上的性能。如果用戶感覺一個過程太慢，那它就慢。這就是說，在嚴格的時間控制下性能的度量并不總是精確。感覺上的性能有時比真正的性能更重要。

　　當然不總是這種情況，當發(fā)生比較重大的延遲時，你只要能夠保證用戶對發(fā)生的過程清楚，三秒鐘是可接受的延遲極限。

　　但如果我們發(fā)現(xiàn)一個應用的性能比較困難，可以使用包括PowerBuilder版本6及更高的版本在內(nèi)的工具是Profiler，它可以為對象、功能甚至編碼行提供更精確的時間測試。這種工具很容易使用，可提供出色的圖像結(jié)果幫助你發(fā)現(xiàn)性能的真正問題。

　　度量網(wǎng)絡性能是一個經(jīng)常不被開發(fā)人員重視的方面。那么當數(shù)以千記的用戶同時下載龐大的會計報表時我們怎樣測試應用呢？實踐證明適合這種類型的性能檢測工具要比其它方面的多。經(jīng)銷商有高質(zhì)量的裝載測試工具。它只需要很小的測試環(huán)境就可以模擬產(chǎn)品環(huán)境。你僅需三臺機器就可模擬數(shù)以千記的用戶上述行為的概況。用這些工具你可以發(fā)現(xiàn)瓶頸可能出現(xiàn)的地方并制定與之適應的對策。也許你需要附加硬件來運行應用�；蛟S要建立控制以預防同時發(fā)生上千個對會計報表的需求�；蛟S你需要開發(fā)一種方法，使你一旦得到會計報表，別的用戶可以共享。在這方面我們也對數(shù)據(jù)庫進行受壓測試。有些公司用一些產(chǎn)品來度量多個請求對數(shù)據(jù)庫的影響或者長時間運行的交易對數(shù)據(jù)庫有無影響。越早發(fā)現(xiàn)問題意味著解決問題的費用越少。

　　度量的最后方面是可伸縮性。這種度量是看用戶數(shù)的增加應用表現(xiàn)如何。有時又稱它為壓力測試。我所見過的最好壓力測試是期望用戶數(shù)的兩倍。壓力測試的精確定義是：通過超過事先期望的用戶數(shù)并發(fā)訪問來測試你應用的結(jié)構、客戶端機器、應用服務器、網(wǎng)絡和數(shù)據(jù)庫。經(jīng)過這個過程，你就能知道何時需要額外的硬件，你具有的硬件能否支持用戶，能準確預見確保維持一定性能需要做什么。

　　結(jié)論

　　關于軟件質(zhì)量還有許多事情要做。要知道自己寫的每一行編碼從簡單的GUI、命名標準到壓力測試復雜的網(wǎng)絡配置都是馬虎不得的。需要提醒的是：我們?yōu)橛脩糸_發(fā)應用軟件，用戶在使用我們的系統(tǒng)時花費了很多金錢和時間。我們應該為他們提供可運行的、可維護的、可擴展的、高性能的應用。我們要有責任感。雖然許多工具可以幫助我們，但最終還是要靠我們的責任心去完成。