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

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

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

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

　　什么是軟件質(zhì)量

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

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

　　編碼質(zhì)量

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

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

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

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

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

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

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

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

　　功能性質(zhì)量

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

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

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

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

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

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

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

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

　　性能

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

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

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

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

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

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

　　結(jié)論

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