軟件在沒有發(fā)布之前的開發(fā)過程主要分為需求分析、設(shè)計(jì)、編碼和驗(yàn)證四個(gè)階段，希賽軟考網(wǎng)整理了一下，最終的軟件質(zhì)量與這四個(gè)階段的各自質(zhì)量之間的關(guān)系如果用C語言來表達(dá)的話應(yīng)當(dāng)是：

    最終的軟件質(zhì)量=需求分析質(zhì)量&&設(shè)計(jì)質(zhì)量&&編碼質(zhì)量&&驗(yàn)證質(zhì)量

    即，最終的質(zhì)量來自于各階段質(zhì)量之“與”，只要其中一個(gè)環(huán)節(jié)質(zhì)量是差，則產(chǎn)品的整體質(zhì)量都將是差，千萬不要認(rèn)為是“或”的關(guān)系。由此看來每一個(gè)階段的質(zhì)量都起著決定性的作用。

    以上提及的四個(gè)階段的質(zhì)量將引出以下幾個(gè)軟件質(zhì)量保證的關(guān)鍵要素。

    完備的需求分析

    需求分析的目的是讓項(xiàng)目組明白要做什么，是決定所開發(fā)出來的軟件應(yīng)當(dāng)是“長什么樣的”，顯然完備的需求分析是高質(zhì)量軟件的前提。如果所開發(fā)出來的軟件與用戶所希望的并不一致，那不可能讓用戶說“這個(gè)軟件的質(zhì)量很好”。如果方向不對，軟件開發(fā)得再“好”也沒有意義。需求分析失誤所帶來的開發(fā)成本是高昂的，這一點(diǎn)在《軟件工程》這類書籍中都會提及，因此，整個(gè)行業(yè)對于需求分析的重要性都具有足夠的認(rèn)識。當(dāng)然，知道其重要性與如何獲得完備的需求分析又是兩回事，至于如何做好需求分析請讀者參考相關(guān)書籍。

    需求分析如果出現(xiàn)失誤的話有一個(gè)特點(diǎn)——它一定會暴露！只不過存在是暴露在軟件開發(fā)過程中還是在用戶手中之別。因此，需求分析所造成的問題盡管嚴(yán)重，但它能被發(fā)現(xiàn)進(jìn)而能得到項(xiàng)目組的重視，從而也一定能被修復(fù)，只是不同階段發(fā)現(xiàn)這類問題所花費(fèi)的成本將有所不同。

    設(shè)計(jì)

    設(shè)計(jì)階段是通過設(shè)計(jì)方法找出軟件實(shí)現(xiàn)更好的方法，注意這里是“更好”兩個(gè)字，而不是強(qiáng)調(diào)最好。

    不良設(shè)計(jì)并不會象需求分析失誤那樣很容易暴露出其本質(zhì)，相反，它所暴露出的更多是表象，比如邏輯復(fù)雜、維護(hù)時(shí)舉步為艱等等。如果參與者不具備一定的洞察力以發(fā)現(xiàn)隱藏在現(xiàn)象背后的不良設(shè)計(jì)本質(zhì)，則很有可能身受其害卻不能自拔，還以為“本來就有那么復(fù)雜”。

    項(xiàng)目的開發(fā)是一個(gè)逐步演進(jìn)的過程，項(xiàng)目組成員對于需求的理解也是逐步加深的，一開始合適的設(shè)計(jì)到后面看來很有可能就不夠全面或顯得力不從心，如果仍沿用以前的設(shè)計(jì)則自然將暴露出它的不足，進(jìn)而會出現(xiàn)需要更高的維護(hù)成本。重構(gòu)思想的提出，就是用于幫助項(xiàng)目演進(jìn)設(shè)計(jì)的，當(dāng)然，在運(yùn)用重構(gòu)方法時(shí)，應(yīng)盡可能保證項(xiàng)目有足夠的單元測試用例，以預(yù)防重構(gòu)時(shí)又引入新的缺陷。重構(gòu)不只是一個(gè)詞，其核心應(yīng)當(dāng)是一個(gè)方法論，一個(gè)用于優(yōu)化設(shè)計(jì)的方法論。

    編程好習(xí)慣

    設(shè)計(jì)階段輸出的結(jié)果就是藍(lán)圖，但好的藍(lán)圖并不能保證最后的質(zhì)量一定就好。拿造房子打個(gè)比方，圖紙?jiān)O(shè)計(jì)得再好，如果建造時(shí)用的材料不過關(guān)，那最終的房子一定好不了。那軟件開發(fā)中的“建筑材料”又是什么呢？就是程序員所編寫的代碼。如何保證其質(zhì)量呢？這需要通過良好的編程習(xí)慣去保證。

    在現(xiàn)實(shí)的項(xiàng)目中，設(shè)計(jì)有可能與編碼會有一定的揉合，即通過進(jìn)行一定的編碼來輔助設(shè)計(jì)。這種實(shí)踐方式并不影響這里將設(shè)計(jì)與編碼分為兩個(gè)質(zhì)量保證關(guān)鍵要素。

    驗(yàn)證

    驗(yàn)證很容易讓人想到質(zhì)量保證的常用方法之一，即測試。但驗(yàn)證應(yīng)當(dāng)包含更多的內(nèi)涵，比如求證軟件需求是用戶所希望的就是其中的一種。

    對于驗(yàn)證的理解仍需要拿房屋的建造作為一個(gè)比方，以便加深理解。在房屋的建造過程中，當(dāng)建筑材料到了工地以后，需要對其進(jìn)行檢驗(yàn)，以保證它的質(zhì)量是合格的，否則不能用于建造。對應(yīng)于軟件開發(fā)，這個(gè)階段就是單元測試。當(dāng)軟件工程師編寫了代碼以后如何保證代碼的行為是其所希望的呢？那只能通過單元測試去驗(yàn)證。房子建造好了以后，還得對房子進(jìn)行整體的驗(yàn)收以確保其最終是合格的。比如抽查墻壁所使用的水泥與沙的配比是合適的。雖然水泥和沙在進(jìn)入工地時(shí)都經(jīng)過了質(zhì)檢且是合格的，但在建造的過程中需要按一定的比例混合它們以作建筑粘合劑，而混合比例將確定粘合強(qiáng)度。在軟件開發(fā)過程中，軟件集成測試就如同房子在建造好了以后的驗(yàn)收。

    從上面的比方能得出幾個(gè)結(jié)論。第一，在軟件開發(fā)過程中單元測試是必不可少的。它的缺少如同將沒有檢驗(yàn)過的建筑材料用于建造一樣。第二，單元測試應(yīng)當(dāng)在集成測試之前完成。有的項(xiàng)目在一開始時(shí)并沒有單元測試流程，但后來發(fā)現(xiàn)需要增加這個(gè)環(huán)節(jié)，于是出現(xiàn)了集成測試完成了以后，再進(jìn)行單元測試這種情形。這種情形還是有點(diǎn)怪怪的，這如同房子已造好了，再將墻打掉去檢查里面的磚是否是好的一樣。“將墻打掉檢查磚”這種行為的勇氣雖然可佳，但是如果盡早地在項(xiàng)目中部署單元測試就能避免這種怪現(xiàn)象的發(fā)生。

    集成（包括開發(fā)集成和系統(tǒng)集成）測試在軟件行業(yè)被廣泛采用以保證軟件質(zhì)量，但單元測試對于軟件質(zhì)量保證的重要性在整個(gè)行業(yè)還缺乏廣泛的、深刻的認(rèn)識，其更多地被當(dāng)作是負(fù)擔(dān)而不是一種有效的質(zhì)量保證手段。

    以上內(nèi)容，希望可以讓大家對軟件測試中軟件的質(zhì)量保證有一定的幫助和理解。

    更多軟考資訊請關(guān)注希賽軟考網(wǎng)。

    相關(guān)推薦：

  軟件測試人員如何做到更好的溝通？

  軟件測試師對文檔編制的質(zhì)量有什么要求？

  軟考軟件測評師中軟件測試要點(diǎn)總結(jié)