如何衡量軟體測試過程的質量

Ⅰ 如何對軟體質量進行評估(1)

1.2 軟體質量特徵
按照軟體質量國家標准GB-T8566--2001G，軟體質量可以用下列特徵來評價：
a.功能特徵：與一組功能及其指定性質有關的一組屬性，這里的功能是滿足明確或隱含的需求的那些功能。
b.可靠特徵：在規定的一段時間和條件下，與軟體維持其性能水平的能力有關的一組屬性。
c.易用特徵：由一組規定或潛在的用戶為使用軟體所需作的努力和所作的評價有關的一組屬性。
d.效率特徵：與在規定條件下軟體的性能水平與所使用資源量之間關系有關的一組屬性。
e.可維護特徵：與進行指定的修改所需的努力有關的一組屬性。
f.可移植特徵：與軟體從一個環境轉移到另一個環境的能力有關的一組屬性。
其中每一個質量特徵都分別與若乾子特徵相對應。
2 評估指標的選取原則選擇合適的指標體系並使其量化是軟體測試與評估的關鍵。評估指標可以分為定性指標和定量指標兩種。理論上講，為了能夠科學客觀地反映軟體的質量特徵，應該盡量選擇定量指標。但是對於大多數軟體來說，並不是所有的質量特徵都可以用定量指標進行描述，所以不可避免地要採用一定的定性指標。
在選取評估指標時，應該把握如下原則：
a.針對性即不同於一般軟體系統，能夠反映評估軟體的本質特徵，具體表現就是功能性與高可靠性。
b.可測性即能夠定量表示，可以通過數學計算、平台測試、經驗統計等方法得到具體數據。
c.簡明性即易於被各方理解和接受。
d.完備性即選擇的指標應覆蓋分析目標所涉及的范圍。
e.客觀性即客觀反映軟體本質特徵，不能因人而異。
應該注意的是，選擇的評估指標不是越多越好，關鍵在於指標在評估中所起的作用的大小。如果評估時指標太多，不僅增加結果的復雜性，有時甚至會影響評估的客觀性。指標的確定一般是採用自頂向下的方法，逐層分解，並且需要在動態過程中反復綜合平衡。
3 軟體質量評估指標體系通常，我們在軟體的測試與評估時，主要側重於功能特徵、可靠特徵、易用特徵和效率特徵等幾個方面。在評價活動的具體實施中，應該把被評估軟體的研製任務書作為主要依據，採用自頂向下逐層分解的方法，並參照有關國家軟體質量標准。
3.1 功能性指標功能性是軟體最重要的質量特徵之一，可以細化成完備性和正確性。目前對軟體的功能性評價主要採用定性評價方法。
a.完備性完備性是與軟體功能完整、齊全有關的軟體屬性。如果軟體實際完成的功能少於或不符合研製任務書所規定的明確或隱含的那些功能，則不能說該軟體的功能是完備的。
b.正確性正確性是與能否得到正確或相符的結果或效果有關的軟體屬性。軟體的正確性在很大程度上與軟體模塊的工程模型（直接影響輔助計算的精度與輔助決策方案的優劣）和軟體編制人員的編程水平有關。
對這兩個子特徵的評價依據主要是軟體功能性測試的結果，評價標准則是軟體實際運行中所表現的功能與規定功能的符合程度。在軟體的研製任務書中，明確規定了該軟體應該完成的功能，如信息管理、提供輔助決策方案、輔助辦公和資源更新等。那麼即將進行驗收測試的軟體就應該具備這些明確或隱含的功能。
目前，對於軟體的功能性測試主要針對每種功能設計若干典型測試用例，軟體測試過程中運行測試用例，然後將得到的結果與已知標准答案進行比較。所以，測試用例集的全面性、典型性和權威性是功能性評價的關鍵。

Ⅱ 軟體質量評估的軟體質量評估指標體系

通常，我們在軟體的測試與評估時，主要側重於功能特徵、可靠特徵、易用特徵和效率特徵等幾個方面。在評價活動的具體實施中，應該把被評估軟體的研製任務書作為主要依據，採用自頂向下逐層分解的方法，並參照有關國家軟體質量標准。 功能性是軟體最重要的質量特徵之一，可以細化成完備性和正確性。對軟體的功能性評價主要採用定性評價方法。
a.完備性
完備性是與軟體功能完整、齊全有關的軟體屬性。如果軟體實際完成的功能少於或不符合研製任務書所規定的明確或隱含的那些功能，則不能說該軟體的功能是完備的。
b.正確性
正確性是與能否得到正確或相符的結果或效果有關的軟體屬性。軟體的正確性在很大程度上與軟體模塊的工程模型（直接影響輔助計算的精度與輔助決策方案的優劣）和軟體編制人員的編程水平有關。
對這兩個子特徵的評價依據主要是軟體功能性測試的結果，評價標准則是軟體實際運行中所表現的功能與規定功能的符合程度。在軟體的研製任務書中，明確規定了該軟體應該完成的功能，如信息管理、提供輔助決策方案、輔助辦公和資源更新等。那麼即將進行驗收測試的軟體就應該具備這些明確或隱含的功能。
對於軟體的功能性測試主要針對每種功能設計若干典型測試用例，軟體測試過程中運行測試用例，然後將得到的結果與已知標准答案進行比較。所以，測試用例集的全面性、典型性和權威性是功能性評價的關鍵。 根據相關的軟體測試與評估要求，可靠性可以細化為成熟性、穩定性、易恢復性等。對於軟體的可靠性評價主要採用定量評價方法。即選擇合適的可靠性度量因子（可靠性參數），然後分析可靠性數據而得到參數具體值，最後進行評價。
經過對軟體可靠性細化分解並參照研製任務書，可以得到軟體的可靠性度量因子（可靠性參數）。
a.可用度
可用度指軟體運行後在任一隨機時刻需要執行規定任務或完成規定功能時，軟體處於可使用狀態的概率。可用度是對應用軟體可靠性的綜合（即綜合各種運行環境以及完成各種任務和功能）度量。
b.初期故障率
初期故障率指軟體在初期故障期（一般以軟體交付給用戶後的三個月內為初期故障期）內單位時間的故障數。一般以每100小時的故障數為單位。可以用它來評價交付使用的軟體質量與預測什麼時候軟體可靠性基本穩定。初期故障率的大小取決於軟體設計水平、檢查項目數、軟體規模、軟體調試徹底與否等因素。
c.偶然故障率
指軟體在偶然故障期（一般以軟體交付給用戶後的四個月以後為偶然故障期）內單位時間的故障數。一般以每1000小時的故障數為單位，它反映了軟體處於穩定狀態下的質量。
d.平均失效前時間（MTTF）
指軟體在失效前正常工作的平均統計時間。
e.平均失效間隔時間（MTBF）
指軟體在相繼兩次失效之間正常工作的平均統計時間。在實際使用時，MTBF通常是指當n很大時，系統第n次失效與第n+1次失效之間的平均統計時間。對於失效率為常數和系統恢復正常時間很短的情況下，MTBF與MTTF幾乎是相等的。
國外一般民用軟體的MTBF大體在1000小時左右。對於可靠性要求高的軟體，則要求在1000~10000小時之間。
f.缺陷密度（FD）
指軟體單位源代碼中隱藏的缺陷數量。通常以每千行無註解源代碼為一個單位。一般情況下，可以根據同類軟體系統的早期版本估計FD的具體值。如果沒有早期版本信息，也可以按照通常的統計結果來估計。「典型的統計表明，在開發階段，平均每千行源代碼有50~60個缺陷，交付後平均每千行源代碼有15~18個缺陷」。
g.平均失效恢復時間（MTTR）
指軟體失效後恢復正常工作所需的平均統計時間。對於軟體，其失效恢復時間為排除故障或系統重新啟動所用的時間，而不是對軟體本身進行修改的時間（因軟體已經固化在機器內，修改軟體勢必涉及重新固化問題，而這個過程的時間是無法確定的）。 易用性可以細化為易理解性、易學習性和易操作性等。這三個特徵主要是針對用戶而言的。對軟體的易用性評價主要採用定性評價方法。
a.易理解性
易理解性是與用戶認識軟體的邏輯概念及其應用范圍所花的努力有關的軟體屬性。該特徵要求軟體研製過程中形成的所有文檔語言簡練、前後一致、易於理解以及語句無歧義。
b.易學習性
易學習性是與用戶為學習軟體應用（例如運行控制、輸入、輸出）所花的努力有關的軟體屬性。該特徵要求研製方提供的用戶文檔（主要是《計算機系統操作員手冊》、《軟體用戶手冊》和《軟體程序員手冊》）內容詳細、結構清晰以及語言准確。
c.易操作性
易操作性是與用戶為操作和運行控制所花的努力有關的軟體屬性。該特徵要求軟體的人機界面友好、界面設計科學合理以及操作簡單等。
3.4 效率特徵指標
效率特徵可以細化成時間特徵和資源特徵。對軟體的效率特徵評價採用定量方法。
a.輸出結果更新周期
輸出結果更新周期是軟體相鄰兩次輸出結果的間隔時間。為了整個系統能夠協調工作，軟體的輸出結果更新周期應該與系統的信息更新周期相同。
b.處理時間
處理時間是軟體完成某項功能（輔助計算或輔助決策）所用的處理時間（注意：不應包含人機交互的時間）。
c.吞吐率
吞吐率是單位時間軟體的信息處理能力（即各種目標的處理批數）。未來的社會情況復雜、信息眾多，軟體必須具有處理海量數據的能力。吞吐率就是體現該能力的參數。隨著信息的泛濫，要求軟體的吞吐率應該達到數百批。
d.代碼規模
代碼規模是軟體源程序的行數（不包括注釋），屬於軟體的靜態屬性。軟體的代碼規模過大不僅要佔用過多的硬碟存儲空間，而且顯得程序不簡潔、結構不清晰，容易存在缺陷。
因為這些參數屬於軟體的內部表現，所以需要用專門的測試工具和特殊的途徑才可以獲得。將測試數據與研製任務書中的指標進行比較，得到的結果可以作為效率特徵評價的依據。 隨著計算機技術、數據融合技術、網路技術和通信技術的飛速發展，對軟體功能提出的要求也越來越高，如何評估軟體質量已成為一個迫切需要解決的課題。選擇合適的指標體系並使其量化是做好軟體質量評估的關鍵。當然，由於軟體的評估具有其特有的規范和要求，其評估指標涉及面廣、不確定性因素較多、量化困難，至今還沒有統一的標准。

Ⅲ 如何評估軟體質量

Q：最近我們組想自己審視一下軟體質量，但是缺少相關的經驗知識（組內沒有qa)。 想向你了解一下，現在常用的軟體質量評估方法? 你有關於軟體質量相關的文章推薦嗎？ 或者有哪些書籍推薦?

A：軟體質量評估，我暫時還一時想不起來。對於軟體質量（測試）相關的書籍我這有基本，具體的可以參考我之前參加的播客： https://music.163.com/#/program?id=903513756 和 http://codetimecn.com/episodes/test ，裡面有書籍的介紹。

單純的評估這塊，我之前做過一個軟體測試成熟度模型，可以用於評估團隊的測試能力。

Q： 其實我有一個問題，軟體質量該如何體現。感覺測試何軟體質量有區別，但是我說不出來。特別是現在客戶非常依賴手動測試，有專門的測試部門

A： 首先，質量是個很大的概念，本質是一種主觀感受。我們通常所指的狹義質量為可靠性，軟體的可靠性可以通過線上bug數來衡量（或者數量的變化趨勢）。 更加准確的計算為線上bug數/開發中的bug數。
這個指標是量化可靠性的其中一種理論，由於業界本身對於軟體質量的度量還沒有統一的結論，我們可以採用這個值作為相對值進行對比。例如當比率很大時，可靠性質量很不好。
還有一個評估方法是工業界的的質量體系。也就是說，你的開發流程需要符合一定的標准，我就認為你的質量是有保證的。但是這個方式比較復雜而且不好量化
線上bug數屬於簡單粗暴型，用比例會准確一下是因為產品的規模不同，線上bug數是不同的。

在回答了上述問題後，我對自己的答安並不十分自信，因為我的觀點是來源於自己的經驗加上一些碎片話的知識。

為了更加准確的找尋關於「軟體質量」 的概念，我再次查閱了維基網路： https://en.wikipedia.org/wiki/Software_quality 。

如上所示軟體質量的定義與軟體測試一樣，並沒有統一的定義。大的有三個維度的定義：

這段話的最後部分也指出了最早的質量定義是主觀的感受。後面還提到了用戶滿意度。

總之，准確的定義軟體質量依然是困難的，不過，我們還是有一些可以依據的定義，他們採用的是質量模型：

如 ISO/IEC 9126的定義的： https://en.wikipedia.org/wiki/ISO/IEC_9126
以及 CISQ's quality model

由於軟體質量定義暫時難已統一，並且是主觀的感受。那麼評估它也就顯得比較主觀了。

當然，最簡單的非軟體測試莫屬，那麼Bug數毫無疑問的成為了一種可行的評估方式，因為軟體測試最早的定義即是，「為了發現錯誤而執行程序的過程」，其中的錯誤，我們就可以狹義的理解為Bug。那這里又會存在一個問題，什麼bug才有測量意義呢？
根據上述軟體質量的定義，「用戶」，「客戶」，這些真正使用軟體的人的感受才是最能反應質量的，所以說，「用戶」， 「客戶」遇到的bug 才是更加符合質量的定義的可用於反應軟體質量的Bug類型。（也就是我們所說的線上Bug）

另外，我們可以參考IT界的一些常用的定義來評估質量，例如：
ISO 9126-3
所提到的質量模型，我們可以通過檢查軟體開發過程中，以及軟體自身是否具備某些特質，以及對應於該特質相關的用於評估的屬性來評估軟體的質量是好是壞。例如：
我們通過右側的屬性來評估左側的質量特性：

從而得到一個綜合的質量評估結果。

盡管上面給出了很多屬性，但是相信大家讀完了，依然疑惑，即便是有了這些屬性，每個屬性本身也並非都是標准化，且容易度量的，如coding practices即是典型的例子，裡面提到了compliance with OO，可是這一點卻是評估的人不同，顯然量化的結果是不同，假如OO compliance的滿分是10分，對於某OO設計，打6，還是7分，還是8，就仁者見仁，智者見智了。

假如我們狹義的理解質量為質量模型中的可靠性，需要check的點：

盡管已經有了這么多點，上面最後一句依然表明了可靠性的衡量需要考慮被評估軟體本身的架構以及使用的第三方庫，然後通過自定義的check點來做。也就是說，這個需要可靠性的評估標准，需要因地制宜，看情況而定。顯然這種措辭依然表達出了主觀標準的意思。

也正是如此，我們身邊的日常用品的質量往往會打著IOS9001/IOS9002質量體系認證，來表明其質量是保證的，也就是說，我的產品是在質量保證的流程體系下生產出來的。這樣以來，貌似這種評估定義，跟上述定義大體類似，實際上都是難以准確度量的，更大的意義也許是跟沒有質量保證的產品去分開吧。

總之，度量軟體質量是如此的復雜，且不一定真的能夠准確量化質量。那倒不如就在開發過程中時刻按照這些check list約束開發過程，讓開發過程是在有保證的情況下交付軟體。讓真正的質量交給時間，交給我們的線上去體現吧。這也想汽車界的著名質量雜志的JD Power的做法，用線上故障數來評估質量吧（對於汽車，准確的是每百輛故障數）。

Ⅳ 如何保證軟體測試質量

我認為高質量的軟體產品是一個軟體團隊所有成員都負責任的完成自己任務以後的必然產物。
首先說說團隊，這其中涉及的需求人員、設計人員、開發人員、測試人員都應該真切的視自己為團隊的必不可少的力量，都應該為了項目或產品的成功竭盡所能的去工作，只有團隊真正的擰成一股繩的時候才具備了產出高質量軟體的基本條件。這是我要說的第一點：團隊認同感、歸屬感。
高質量的需求調研文檔是軟體成功必不可少的條件，但是不同的人對同一句話的理解往往會有差異，因為立場不同。所以想要保證需求的質量，需求人員必須把自己置身到用戶的立場去感受、去調研、去理解目標用戶反饋的信息。對於不確認的信息要想盡辦法搞清楚。所以需求調研人員最好是行業專家。需求文檔整理出來後，必須經過客戶方代表和公司設計、開發、測試的共同評審才能最終定稿，並最終進入軟體設計流程。這是我要說的第二點：軟體需求必須用「心」去做，並且監督評審必須到位。
接下來就進入了軟體的生產流程，在設計階段，設計人員是主角，開發人員、測試人員、需求人員要可以及時獲得設計文檔。設計人員必須在實現需求的情況下，站在用戶的立場上去設計功能，實現最好的用戶體驗。在設計評審時，開發、測試、需求要從用戶的角度去評判設計，根據需求從用戶的角度去評審設計，這真的很重要。問題如果能在設計階段就發掘出來會極大的減少資源的浪費，縮短產品或項目周期。這是我要說的第三點：設計要注重用戶體驗，同時監督評審也必須到位。
軟體進入開發測試流程後，實際的開發人員應該站在用戶的角度上去開發每一個功能，如果有比設計更好的實現方法，應及時和設計、測試、需求人員溝通，共同確認是否更改設計。每一個功能完成後，必須進行完整的自測，然後及時送測給測試人員，測試人員也要在用戶的角度進行測試，發現問題或建議及時反饋、溝通和處理。還有很重要的一點，測試必須要有測試用例。測試開始前，測使用例必須經過評審，當然評審粒度根據公司資源確定。這是我要說的第四點：開發是軟體的製造者，測試是軟體質量的保證者，兩者相輔相成，榮辱與共。
高質量的軟體是一個軟體團隊共同努力的結果，任意一個環節出問題都可能造成團隊的災難。團隊領導者必須要想辦法、盡全力將自己的團隊凝結在一起，使大傢具有團隊榮譽感和使命感。軟體生命周期的各個階段都有工作重點，團隊領導必須把握好。團隊領導不能輕視任何一個環節的工作，否則高質量的軟體只能是一句空話。古人說「三人行，必有我師焉」。任何一個團隊，所有人的力量都發揮出來肯定比所謂幾個精英累死累活搞出來的結果要好。人們說的「兵熊熊一個，將熊熊一窩」也是說團隊領導的重要性。
呵呵，總結完了。最後再說一下自己的看法：高質量的軟體是軟體團隊共同努力的結果，用戶體驗是軟體質量很重要的方面，軟體的需求、設計、開發和測試都應該是從用戶的角度出發去工作。

Ⅳ 軟體測試中對軟體質量進行度量的指標常用的有哪些

你好！

有N多種指標：
缺陷統計數據的度量(I)
所有缺陷數量的時間走勢或趨勢統計 (Bug Trends By Time)
未被處理的缺陷按照嚴重程度的統計 (Active Bugs By Severity)
未被處理的缺陷按照優先程度的統計 (Active Bugs By Priority)
未被處理的缺陷數量的時間走勢或趨勢統計 （Active Bugs Over Time）
已發現缺陷的數量和已修復的缺陷的數量的比率 (Fixed/Found)。也被稱為修改率或糾錯率(Fix Rate)
未處理的缺陷數量和已處理的的缺陷數量的比率 (active/resolved)
已處理的被修復的缺陷數量和已處理的缺陷數量的比率（Resolved as Fixed/resolved）
重新被激活的已修復的缺陷數量(Bug re-activation rate)
通過測試找到的缺陷的統計(Bugs opened by testing activity)
所有的缺陷按照嚴重程度的統計(All Bugs By Severity)
新被發現的缺陷按嚴重程度的統計 (Opened Bugs By Severity)
已處理的缺陷按照嚴重程度的統計 (Resolved Bugs By Severity)
被修復的缺陷按照嚴重程度的統計 (Fixed By Severity)
不同語言版本缺陷數量的統計(Bugs opened by Language version)
被報告存在缺陷的各功能統計(Where your bugs were found)
處理缺陷的平均時間的統計(Average Time to Resolve)
關閉缺陷的平均時間的統計(Average Time to Close)
被處理缺陷的不同結論統計(Resolved Bugs By Resolution)

詳細的信息你可以留下郵箱，我發給你文件！