在之前的敏捷相關(guān)的課程中，我們講過一種開發(fā)模式叫做 TDD ，也就是測試驅(qū)動開發(fā)。這種開發(fā)模式是先寫單元測試，然后再寫代碼，代碼完成的標(biāo)準(zhǔn)就是通過測試。如果你是在一個需要開發(fā)非常高質(zhì)量產(chǎn)品的團(tuán)隊中，相信這種開發(fā)模式一定不會陌生。
測試，對于軟件的重要性不言而喻。沒有測試的軟件相信你也是不敢交到客戶手中的，至少我們手動點點點的也得把功能都測試完。當(dāng)然，就和軟件工程中的其它部分一樣，測試本身也是一個非常大的知識技能分類，也有專門的測試工程師這一職位，因此，在這里，我們還是只能在入門的水平上略做了解而已。
軟件測試的目的就是驗證軟件是否滿足軟件開發(fā)合同或項目開發(fā)計劃、系統(tǒng)/子系統(tǒng)設(shè)計文檔、SRS、軟件設(shè)計說明和軟件產(chǎn)品說明等規(guī)定的軟件質(zhì)量要求。通過測試，我們可以發(fā)現(xiàn)軟件缺陷，為軟件產(chǎn)品的質(zhì)量測量和評價提供依據(jù)。
根據(jù)是否運行程序來測試，我們可以將測試分為 靜態(tài)測試 和 動態(tài)測試 兩種。很明顯，靜態(tài)測試是不需要我們把代碼運行起來的，而動態(tài)測試就是程序需要運行起來，跑起來才可以進(jìn)行的測試。
靜態(tài)測試主要是對文檔、代碼進(jìn)行靜態(tài)的檢查，它又可以分成三種類型，我們一個一個來看看：
桌前檢查（Desk Checking）：這個就是自己對自己寫完的代碼進(jìn)行檢查，在提交代碼之前完成自查的步驟。不過這個步驟效果一般不會太好，為什么呢？自己寫的東西，不管是文章還是代碼，都很難檢查出問題。這個不怪你粗心，是大部分人都會存在的問題，就像我的很多文章里面都會有錯別字，但其實每次我發(fā)文章前都會好好看兩遍的。
代碼走查：代碼走查就是通過測試小組進(jìn)行模擬計算機(jī)運行的測試。這個是啥？不就是我們常說的 Code Review 嘛。一般會是開發(fā)小組一起進(jìn)行，由一個主持人來挑選除自己以外團(tuán)隊成員的代碼一起閱讀。大家一起在腦中模擬代碼運行的結(jié)果，一起發(fā)現(xiàn)問題并記錄下來。這種效果最好，不過呢，太費時間，而且還要坐在一起開會。
代碼審查：剛說完的走查，好是好，但效率不行，還耽誤大家的事，感覺還是不太合適呀。那么你可以試試代碼審查，它是團(tuán)隊成員之間互相審核代碼。不用坐在一起開會，就是互相查看團(tuán)隊成員其他人的代碼。最典型的就是 Github 的 Pull Request ，可以設(shè)置團(tuán)隊中必須多少人審核完成你的代碼才能將這段代碼合并到主分支中。這種方式，一是可以多人互查，二是大家可以自己安排審查的時間。因此，代碼審查是靜態(tài)測試中比較綜合平衡的一種測試方式，也是比較推薦的代碼檢查方式。
動態(tài)測試就是在計算機(jī)上實際運行程序進(jìn)行軟件測試，這個時候軟件是跑起來的。根據(jù)我們測試的工具或者方法是否對業(yè)務(wù)代碼有了解，也可以分為三種類型：
白盒測試：白盒的意思就是我們對代碼很清楚、很了解，將程序看作是一個白盒，測試人員完全清楚程序的結(jié)構(gòu)和處理算法。一般白盒測試針對的是 單元測試 ，也就是代碼級別的測試，通過程序員自己完成。在 單元測試 中，我們需要關(guān)注的是覆蓋率的問題，也就是有多少代碼被測試到了。我們應(yīng)該盡量追求高的覆蓋率，但也不能一味追求 100% 的覆蓋率，有的時候?qū)⒏采w率從 99% 提升到 99.1% 就需要我們付出 200% 的努力，這樣反而是得不償失的。在覆蓋率中，我們會比較關(guān)注 語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋 等。
黑盒測試：也稱為功能測試，主要是用于 集成測試、確認(rèn)測試和系統(tǒng)測試 中。黑盒很明顯就是和白盒反過來的，將程序看作是一個不透明的黑盒，完全不考慮（或不了解）程序的內(nèi)部結(jié)構(gòu)和處理算法，一般是 程序員、測試工程師 或項目其它相關(guān)人員來進(jìn)行測試。在黑盒測試中，我們要依據(jù) SRS 所規(guī)定的功能來設(shè)計測試用例，一般包括 等價類劃分（比如將 1-100 的參數(shù)值分成 1-50和51-100兩部分）、邊界值分析（比如 1-100 我們選取 0、2、99、101來測試）、判定表、因果圖、隨機(jī)測試、猜錯法 和 正交試驗法 等。
灰盒測試：灰盒測試，是介于白盒測試與黑盒測試之間的一種測試，灰盒測試多用于集成測試階段，不僅關(guān)注輸出、輸入的正確性，同時也關(guān)注程序內(nèi)部的情況?；液袦y試不像白盒那樣詳細(xì)、完整，但又比黑盒測試更關(guān)注程序的內(nèi)部邏輯，常常是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運行狀態(tài)。
上面這一大段我們提到了一堆名詞，不知道有沒有把你整暈。反正我第一次學(xué)的時候真的是暈頭轉(zhuǎn)向了。后面我們還會再詳細(xì)的講解其中的一部分測試，不過我們先看一張有利于記住這一堆名詞的圖，這個是我們今天文章的重點之一。
對于測試的類型，其實我們在上一段就已經(jīng)全部都提到過了，在這里我們再來簡單地挨個說明一下。根據(jù)國標(biāo) GB/T 15532-2008 ，軟件測試可以分為如下幾種：
單元測試：也稱為模塊測試，單位最小，是代碼中方法、函數(shù)級別的測試。目的是檢查每個模塊能否正確地實現(xiàn)設(shè)計說明中的功能、性能、接口和其他設(shè)計約束等條件，發(fā)現(xiàn)模塊內(nèi)可能存在的各種差錯。前面說過，單元測試關(guān)注覆蓋率，并且是由程序員自己來完成的。
集成測試：檢查模塊之間，以及模塊和已集成的軟件之間的接口關(guān)系，并驗證已集成的軟件是否符合設(shè)計要求。其實它就是在單元測試的基礎(chǔ)上測試多個函數(shù)接口之間一起聯(lián)合運行的情況。主要測試的是模塊間的接口和通信，一般也是以程序員為主。
確認(rèn)測試：主要是驗證軟件功能，也稱為有效性測試，根據(jù)用戶的參與程度還有三種類型。內(nèi)部確認(rèn)測試，是開發(fā)組織內(nèi)部按照 SRS 進(jìn)行的測試；Alpha測試和Beta測試，Alpha測試是指由用戶在開發(fā)環(huán)境下測試，而Beta測試則是指用戶在真實環(huán)境下進(jìn)行測試；驗收測試，針對 SRS ，在交付前以用戶為主進(jìn)行的測試。這一部分的測試一般都在項目開發(fā)比較后期的階段，以測試工程師輔助并通過用戶參與為主的測試。
系統(tǒng)測試：系統(tǒng)測試的對象是完整的、集成的計算機(jī)系統(tǒng)，系統(tǒng)測試的目的是在真實工作環(huán)境下，驗證完整的軟件配置項能否和系統(tǒng)正確連接，并滿足系統(tǒng)/子系統(tǒng)文檔和軟件開發(fā)合同規(guī)定的要求。在這個階段，我們應(yīng)該是軟硬件以及系統(tǒng)的所有相關(guān)功能組件的聯(lián)調(diào)測試。一般包括 功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、安裝與反安裝測試 等。主要采用的是 黑盒測試 法。以測試工程師為主，程序員及產(chǎn)品經(jīng)理等職能部門輔助。
配置項測試：測試的對象是軟件配置項，目的是檢查軟件配置項與 SRS 的一致性。這個不太常見，也就不多說了。
回歸測試：目的是測試軟件變更之后，變更部分的正確性和對變更需求的符合性，以及軟件原有的、正確的功能、性能和其他規(guī)定的要求的不損害性?；貧w測試非常重要，最簡單的一種回歸方式就是在修改完程序之后整體全部地運行一遍單元測試。注意，不僅是變更的部分，系統(tǒng)所有的部分都應(yīng)該進(jìn)行回歸測試以確認(rèn)變更是否對系統(tǒng)整體有影響。
除了上面 國標(biāo) 中規(guī)定的測試之外，我們再補充兩個教材之外的測試知識點。
負(fù)載測試：模擬實際軟件系統(tǒng)所承受的負(fù)載條件的系統(tǒng)負(fù)荷，通過不斷加載（如逐漸增加模擬用戶的數(shù)量）或其它加載方式來觀察不同負(fù)載下系統(tǒng)的響應(yīng)時間和數(shù)據(jù)吞吐量、系統(tǒng)占用的資源（如CPU、內(nèi)存）等，以檢驗系統(tǒng)的行為和特性，以發(fā)現(xiàn)系統(tǒng)可能存在的性能瓶頸、內(nèi)存泄漏、不能實時同步等問題。
壓力測試：在強(qiáng)負(fù)載（大數(shù)據(jù)量、大量并發(fā)用戶等）下的測試，查看應(yīng)用系統(tǒng)在峰值使用情況下的操作行為，從而有效地發(fā)現(xiàn)系統(tǒng)的某項功能隱患、系統(tǒng)是否具有良好的容錯能力和可恢復(fù)能力。
注意它們兩個的區(qū)別就好了，壓力測試是看系統(tǒng)的最大承受能力，要壓到系統(tǒng)接近崩潰的水平，并看系統(tǒng)的恢復(fù)能力；而負(fù)載一般不會給到那么大的壓力流量，而是看在常態(tài)壓力情況下系統(tǒng)的穩(wěn)定性。
軟件測試的管理包括過程管理、配置管理和評審工作。
過程管理：包括測試活動管理和測試資源管理。整個測試過程中的活動有制定測試計劃及用例、執(zhí)行測試、發(fā)現(xiàn)并報告缺陷、修正缺陷、重新測試等。而測試資源則包括測試團(tuán)隊的管理、測試計劃的管理、錯誤（缺陷）跟蹤管理、測試件管理等。
配置管理：按照軟件配置要求，將測試過程中產(chǎn)生的各種工作產(chǎn)品納入配置管理。
評審：包括測試就緒評審和測試評審。一個是在測試之前就工具準(zhǔn)備情況進(jìn)行的評審，一個是在測試完成后對測試過程和測試有效性進(jìn)行的評審。
運維這個東西吧，往大了說，可以說是整個系統(tǒng)生命周期中最重要的一環(huán)。我們可以將軟件維護(hù)定義為需要提供軟件支持的全部活動，這些活動包含在交付前完成的活動，以及交付后完成的活動。交付前完成的活動包括交付后運行的計劃和維護(hù)計劃等，交付后的活動包括軟件修改、培訓(xùn)、幫助資料等。在這里，我們了解一下軟件維護(hù)的 4 種類型。
改正性維護(hù)：也就是出問題了進(jìn)行修改，說白了，把出現(xiàn)的 BUG 改好。一般占總維護(hù)的 25% 。
適應(yīng)性維護(hù)：對于已開發(fā)的產(chǎn)品，看看在用戶環(huán)境下合理不合理，有沒有與預(yù)期不適應(yīng)的地方，有的話就得調(diào)整修改。這種維護(hù)一般占總維護(hù)的 20% 。
完整性維護(hù)：也叫完善性維護(hù)，就是增加功能模塊，提升性能之類的工作，這個就是我們?nèi)粘Ｋ斫獾哪欠N運維操作。如果是運營公司自己的團(tuán)隊運維那肯定是沒問題的，如果是外包公司的話，一般的售后是不會包含這個的，這種維護(hù)對于外包來說就是一個新的項目，是要加錢的。這種運維占總維護(hù)的 50% 。
預(yù)防性維護(hù)：定期備份、檢查，為有可能到來的修改變更做好準(zhǔn)備。這種維護(hù)比較少，一般占總維護(hù)的 5% 左右。
大家可以結(jié)合自己的實際工作經(jīng)驗和情況，看看我們平常做得最多的是哪種運維，如果不是外包公司的話，那么估計大部分人都是在進(jìn)行 完整性維護(hù) ，而且這個比例可能比 50% 還要高。
說了半天軟件工程，“軟件”到底是個啥？其實我們前面有隱約的提到過，【信管1.5】計算機(jī)網(wǎng)絡(luò)基礎(chǔ)（三）網(wǎng)絡(luò)存儲與網(wǎng)絡(luò)接入 https://mp.weixin.qq.com/s/dNEnCyL0zNRgs3AMVhGqSA 中，我們說過程序是怎樣運行起來的，其實軟件，不就是一個程序嘛。不過，真正軟件的定義還是要更寬泛一些。
軟件是計算機(jī)程序及其有關(guān)的數(shù)據(jù)和文檔，也包括固化了的程序（比如COMS、BIOS等）。
除了程序外，數(shù)據(jù)和文檔也是軟件的一部分。對于軟件來說，最重要的是什么？能耗、節(jié)約存儲、速度、性能？這些確實很重要，但更重要的是質(zhì)量。也就是說，你得能用，不能出 BUG ，性能在可接受的范圍內(nèi)，那么這款軟件可以說是成功的。如果你的速度很快，但是用不了兩下就崩潰黑屏直接退出的話，那估計大部分人還是沒法授受的。當(dāng)然，如果速度太慢，慢得你無法忍受，那么這也可以劃分到質(zhì)量問題中。那么，軟件質(zhì)量到底是什么呢？
軟件質(zhì)量，是指軟件產(chǎn)品中能滿足給定需求的各種特性和總和。這些特性稱做質(zhì)量特性，它包括功能特性、可靠性、時間經(jīng)濟(jì)性、資源經(jīng)濟(jì)性、可維護(hù)性和移植性等。
其實，真正決定質(zhì)量的，是你和甲方、或者高層領(lǐng)導(dǎo)溝通出來的質(zhì)量指標(biāo)。比如說系統(tǒng)的第一版，我們要求系統(tǒng)整體響應(yīng)能在2秒內(nèi)，年故障率不能低于 3 個 9 ，所有功能都可以正常使用，兼容主流瀏覽器等。你只要達(dá)到了這些要求，那么這一版你的質(zhì)量就是合格的。在這樣的指標(biāo)下，我們就可以根據(jù)情況選擇合適的架構(gòu)和項目資源。要知道，質(zhì)量其實是一個相對的指標(biāo)，大家都會追求最好的質(zhì)量，但就像性能指標(biāo)或者單元測試的覆蓋率一樣，可能最后那幾個點就能達(dá)到完美的質(zhì)量指標(biāo)卻需要付出成百上千倍的努力，這樣對于一個商業(yè)化的項目來說，反而是得不償失的。
好了，話說回來，軟件質(zhì)量管理過程和我們后面要講的項目質(zhì)量管理是有區(qū)別的，我們在這里先介紹軟件的質(zhì)量過程。
質(zhì)量保證過程：通過計劃制訂、實施和完成一組活動提供保證，這些活動保證項目生命周期中的軟件產(chǎn)品和過程符合其規(guī)定的需求。也就是不管做什么事，我們要遵守一定的程序步驟。
驗證過程：確定軟件開發(fā)周期中一個給定階段的產(chǎn)品是否達(dá)到上一階段確立的需求的過程。這個在敏捷中就是每次迭代沖刺之后的回顧會議，而在傳統(tǒng)瀑布式開發(fā)中則是每個里程碑總結(jié)時的進(jìn)行的驗證。確?；顒拥妮敵霎a(chǎn)品滿足活動的規(guī)范說明。
確認(rèn)過程：在軟件開發(fā)過程結(jié)束時對軟件進(jìn)行評價以確定它是否和軟件需求相一致。確認(rèn)過程的目的是確保產(chǎn)品滿足其特定的目標(biāo)。
審計過程：評價軟件產(chǎn)品和過程對于 設(shè)定規(guī)則、標(biāo)準(zhǔn)、流程 等的遵從性的獨立評價。
評審過程：對現(xiàn)有的或提出的項目成果所做的正式評估和審查，找出可能會影響項目產(chǎn)品、過程或服務(wù)工作的適用性和環(huán)境方面的缺陷，并制定補救措施，以及找出在性能、安全性和經(jīng)濟(jì)方面的可能的改進(jìn)。
上面五個過程，記名字和加粗的部分就可以了。其實評審過程還包括兩種評審：
技術(shù)評審：目的是評價產(chǎn)品，看產(chǎn)品是否滿足需求，以確定使用意圖的適合性。
管理評審：目的是監(jiān)控進(jìn)展，看的是過程是否滿足管理計劃，決定計劃和進(jìn)度的狀態(tài)，或評價用于達(dá)到目標(biāo)所用管理方法的有效性。
同樣的，這兩種不同的評審要知道它們的區(qū)別，一個是從技術(shù)產(chǎn)品的角度，一個是從管理過程的角度。
最后，我們再來看兩張圖，它們是 GB/T 16260.1-2006 質(zhì)量標(biāo)準(zhǔn)，也就是國標(biāo)的軟件質(zhì)量模型。
這兩張圖大家了解一下就好了，第一張圖上的四個圈其實就是 開發(fā)過程質(zhì)量、內(nèi)部質(zhì)量、驗收質(zhì)量和最終的用戶質(zhì)量。一般來說，開發(fā)過程中的質(zhì)量問題最好解決，內(nèi)部質(zhì)量也是比較好解決的，而到了驗收時出現(xiàn)的質(zhì)量問題往往就會影響我們的項目收益，而用戶在使用過程中出現(xiàn)的質(zhì)量問題則有可能帶來非常嚴(yán)重的后果。這四個點是需要我們注意一下的。
今天的內(nèi)容其實從段落情況就可以看出，測試部分很重要。測試的分類，不同的測試的概念最好都能記下來。其它的就是系統(tǒng)運營的 5 種維護(hù)過程以及軟件質(zhì)量管理的五個過程，不過不需要像測試的那些概念那樣記得詳細(xì)，主要是記一些關(guān)鍵點就可以了。
參考資料：
《信息系統(tǒng)項目管理師教程》
《某機(jī)構(gòu)培訓(xùn)資料》
聯(lián)系客服
