第一篇：軟件質量保證報告（最終版）

軟件質量保證報告

現(xiàn)在越來越多的公司都開始真正重視起軟件質量問題，要做到高質量的軟件應該滿足軟件需求定義的功能和性能。

文檔符合事先確定的軟件開發(fā)標準軟件的特點和屬性遵循軟件工程的目標和原則，還應該考慮在預算和進度范圍內(nèi)交付，因此在項目進行過程中要對偏差進行控制質量控制和質量保證。

質量控制是為了保證每一件工作產(chǎn)品都滿足對它的需求而應用于整個開發(fā)周期中的一系列審查、評審和測試，質量控制在創(chuàng)建工作產(chǎn)品的過程中包含一個反饋循環(huán)，通過對質量的反饋，使得我們能夠在得到的工作產(chǎn)品不能滿足其規(guī)約時調整開發(fā)過程。所有工作產(chǎn)品都應該具有定義好的和可度量的規(guī)約，這樣就可以將每個過程的產(chǎn)品與這一規(guī)約進行比較。質量保證由管理層的審計和報告構成，目標是為管理層提供獲知產(chǎn)品質量信息所需的數(shù)據(jù)，從而獲得產(chǎn)品質量是否符合預定目標的認識和信心。

軟件質量保證

軟件質量保證是為了保證軟件系統(tǒng)或軟件產(chǎn)品滿足用戶要求的質量而進行的有計劃、有組織的活動，其目的是生產(chǎn)高質量的軟件。在軟件質量方面必須強調三個要點：軟件必須滿足用戶規(guī)定的要求，與用戶需求不一致的軟件，就無質量可言。

軟件應遵循軟件標準所定義的一系列開發(fā)標準，不遵循這些標準的軟件，其質量難以得到保證。

軟件還應滿足某些隱含的要求，例如希望有良好的可理解性、可維護性等，而這些隱含的要求可能未被寫在用戶規(guī)定的需求中，滿足它的顯性需求而不滿足其隱含需求，那么該軟件的質量是令人懷疑的。

我們評價一款軟件可以從以下一些角度進行

正確性

正確性是指軟件按照需求正確執(zhí)行任務的能力。正確性也涵蓋了“精確性方面。無庸質疑，這是對一款軟件最基本的要求，比如我們通過ATM自動取款機取款時，在輸入1,000時，結果只輸出了800或者輸出了1,200，可想而知這會對銀行和客戶會產(chǎn)生多大的影響。一款軟件滿足不了正確性的要求，再談其他任何方面都沒意義。

可靠性

可靠性是指在一定的環(huán)境下，在給定的時間內(nèi)，系統(tǒng)能夠正常運行的概率。我曾在手機中遇到一個問題：在待機狀態(tài)下，手機網(wǎng)絡信號等一切顯示正常，會出現(xiàn)一些無法通信的情況，電話無法撥打，短信不能收發(fā)，重新開機后方可恢復正常。想象下如果情人約會，或者緊急救助時遇到這種情況會產(chǎn)生什么樣的后果。

健壯性

健壯性是指在異常或者不利情況下，軟件能夠正常運行的能力。我們可以用生活中的一個例來說明，當流感出現(xiàn)的時候，在同樣環(huán)境下，有些人很容易就生病，而有些人卻任你東南西北風，就是安然無恙。

美觀性

美觀性主要指軟件UI設計的情況，美觀性就是從大眾化審美以及心理學角度對軟件提出的一個要求，這個要綜合考慮軟件的使用人群特點等。美觀性包括軟件的顏色搭配，字體使用，排版布局等方面。

性能

性能也就是一個軟件效率問題，也就是軟件特定時間空間環(huán)境下系統(tǒng)的響應能力。我們平時在使用手機進行編寫短信時，可能有的手機在輸入一個字符后，手機顯示的很緩慢！這就是軟件性能比較差的一個表現(xiàn)。

易用性

顧名思義，易用性是軟件能否滿足客戶容易操作使用程度。易用性也是衡量一款軟件質量好壞的一個重要方面，我們經(jīng)常會聽到有些人說某些手機太復雜了，不好用，不會用，那我想這樣的軟件并不能真正能稱為好軟件。在開發(fā)過程中，如果軟件開發(fā)人員一味關注技術而不從用戶使用的角度來考慮那就大錯特錯了。

兼容性

兼容性指一款軟件和其他不同軟件通信（或交換信息）的能力。以前我在做一些藍牙耳機測試的時候，就出現(xiàn)有藍牙耳機和某些手機配對后通過耳機端無法對手機端進行控制的問題，這就造成了和某些手機無法搭配使用，問題比較嚴重。在做兼容性測試方面，首先要保證所做軟件能和市場上一些知名品牌產(chǎn)品以及市場占有率比較高的產(chǎn)品的兼容。安全性

安全性是指軟件系統(tǒng)防止被非法入侵的能力。如我們會有聽說某網(wǎng)絡系統(tǒng)被黑客入侵導致癱瘓的情況就是一個例子。當然一個系統(tǒng)的安全性既和軟件本身的抗入侵能力有關又和一些相關保護措施有關，如是否有加密、安裝防火墻等。

可移植性

可移植性指的是軟件不經(jīng)修改或稍加修改就可運行于不同軟硬件環(huán)境（CPU、OS和編譯器）的能力，主要體現(xiàn)為代碼的可移植性。

可擴展性

可擴展性反映軟件適應“變化”的能力，如增加新功能等。可擴展性和可移植性一樣，主要都是從開發(fā)的角度對軟件提出的要求。從一些不同角度來評價一款軟件，當然實際評測過程中還要根據(jù)嵌入式、B/S架構、C/S架構等不同特點軟件來有所側重，同時還要結合軟件軟件使用對象、生命周期等來綜合評價。當然，以上各點滿足了也不能就能說明就是一款好軟件了，其他比如可維護性、可復用性、可測試性等也是我們要根據(jù)實際情況來考慮的因素。

軟件質量的目標

軟件公司生產(chǎn)軟件的最根本目標是為了讓產(chǎn)品贏得市場、贏得顧客，從而獲取利潤。如果企業(yè)連生存的能力都沒有了，軟件的質量做的再完美也無用。軟件公司開發(fā)一款軟件，并不是說質量越高越好。質量越高，成本相對會越高，這樣企業(yè)就可能支持不力，無法生存；或者價格很高，客戶無法接受。在此并不是說軟件質量并重要，質量很重要！好和壞從來都是相對的。從用戶的角度而言，在能夠正常滿足使用要求的軟件就是好軟件；對企業(yè)而言，在軟件生命周期里，能夠軟件能夠滿足用戶使用，能給自己帶來更多利潤的軟件就是好軟件。不同場合對軟件質量的要求是不一樣的，比如我們國家發(fā)射神州五號而后神州六號宇宙飛船，這就要求其軟件質量要百分百可靠，不能出哪怕一點點的差錯，相信在不久的將來我們國家在發(fā)射載人登月宇宙飛船時，對飛船軟件質量的的重視程度會有過之而無不及。人員素質

軟件是人做出來的，軟件質量的好壞和開發(fā)、測試以及有關管理人員都息息相關。在軟件開發(fā)方面，我們在此不談，只從測試的角度來談軟件質量保證。說質量保證，先問下自己，從事質量保證的人員真的有能力去做好質量保證嗎？質量保證的人員能力問題是個重要方

面，如果連軟件中潛在問題都發(fā)現(xiàn)不了，想解決問題，做高質量的軟件，談何容易？

測試人員能力是一方面，其他如從事軟件測試人員的職業(yè)素養(yǎng)也是個重要方面。如果一款軟件未有充分去測，甚至對有些概率性的問題一笑而過，耐不住性子深入去測，或者在發(fā)行版本時只簡單測試一下，這些都無法真正保證軟件的質量。而這種情況下的出現(xiàn)，測試人員根據(jù)簡單的測試，下了個軟件沒問題的結論，這樣對顧客而言影響是很大的，最終對公司而言無論形象還是未來產(chǎn)品銷售等方面的都是不利的。

公司規(guī)范

測試人員的能力再強，測出的問題再多，如果在些問題沒有解決的情況下匆匆將軟件release給客戶，軟件問題一大堆。這樣的測試其實是沒有多大的實際意義的。測試的目的是發(fā)現(xiàn)問題，解決問題，保證軟件質量。

當然這個保證單憑測試人員、QA是不行的，在我們國內(nèi)，其實很多企業(yè)測試人員和QA人員在軟件發(fā)行問題上根本沒有發(fā)言權，基本上都是公司領導說了算，如果公司領導說“這些問題沒關系，我覺得軟件可以發(fā)行”，那這時軟件基本都會發(fā)行的。至于所謂的測試、QA以及項目經(jīng)理等人員，你就一邊吹風去吧。

所以，在軟件問題評估，軟件發(fā)行等問題上一定要給質量保證人員（通常是QA）足夠的權力，QA測評通不過就是通不過！

可惜目前真正能做到這一步的公司并不多。企業(yè)為了生存，也很難把這方面真正做好，比如有些產(chǎn)品趕在某些節(jié)假日上市時有著良好的時常，而過了那一段時期，可能產(chǎn)品就很難賣了。當然，這些就不是測試人員考慮的范圍了。

我們?nèi)绾纬蔀橐幻麅?yōu)秀的軟件質量保證工程師

軟件質量保證牽扯到軟件開發(fā)的方方面面，包括從啟動到需求，到設計，到開發(fā)，到測試，到發(fā)布，到后期維護的整個過程。在啟動階段，你要理解如何制定項目章程，如何書寫項目范圍說明書，如何制定項目計劃；在需求階段，你需要理解如何與用戶確認需求，如何進行需求分析，如何與用戶確認用戶需求；在設計方面你要大體理解當前設計前沿技術，了解數(shù)據(jù)庫知識，如何進行概要設計和詳細設計；在構造階段，您需要了解編碼規(guī)范，編程技巧，集成技術；在測試階段你需要理解如何進行單元測試，集成測試，系統(tǒng)測試；在驗收階段您需要理解如何進行驗收測試，如何培訓用戶，如何替用戶搭建環(huán)境；在維護階段您需要理解如何理解代碼，如何進行再工程技術。在這里你好像是一位多面手，但是了解得越多，對你從事質量保證工作越有好處。由于現(xiàn)代分工比較細致，往往一個質量小組需要各個方面的人才組合在一起，才能發(fā)揮更大的效能，才能達到1+1>2的結果。

對于從事軟件質量保證工作，您需要一定的數(shù)學知識，尤其是概率統(tǒng)計知識。無論你是否采用6Sigma，你需要對你的軟件質量進行度量活動，需要收集數(shù)據(jù)，分析數(shù)據(jù)從而解決問題。你要理解如何使用直方圖，散點圖，魚刺圖，餅圖等工具。這樣你才能展示問題的原因，尋找解決問題的原因。

對于從事軟件質量保證工作，溝通能力非常重要。質量工作做得好壞，關鍵在于領導的支持和員工的參與。由于目前中國軟件的實際工作，公司領導往往忽視軟件質量的重要性和優(yōu)先性，你就需要與領導講清楚質量管理的優(yōu)勢，如何可以提高公司產(chǎn)品的質量，減少客戶的投訴率從而節(jié)約公司的成本，提高勞動生產(chǎn)率。有了領導強有力的支持，你的工作就好像添加了一把利劍，可以運行得得心應手。但是僅僅有領導的支持時往往不夠的，還需要員工的支持，你需要了解當前問題有什么，阻礙這些問題的要數(shù)是是什么，大家需要解決什么樣的問題?這些都需要靠你的溝通技巧來解決。

第二篇：軟件質量保證承諾書

軟件質量保證承諾書

軟件質量保證承諾書1

根據(jù)《中華人民共和國著作權法》、《計算機軟件保護條例》及單位軟件正版化工作相關規(guī)定，為確保單位使用軟件的合法性和安全性，營造使用正版軟件的良好氛圍，本人鄭重做出如下承諾：

1、不私自在計算機辦公設備及系統(tǒng)中安裝或卸載軟件;

2、不私自升級或改動計算機辦公設備及系統(tǒng)中已安裝的.商業(yè)軟件;

3、因工作需要，確需安裝或卸載軟件、升級或改動商業(yè)軟件的，主動報單位軟件正版化工作牽頭部門或信息化工作部門審核，并由其統(tǒng)一組織維護;

4、不私自將計算機辦公設備及系統(tǒng)中已安裝的商業(yè)軟件復制或遷移至單位資產(chǎn)以外的計算機設備及系統(tǒng)中使用。

若有違反以上任何承諾，在單位軟件正版化考核評議、信息安全風險、版權侵權違法等方面造成的一切后果，全部由本人負責。

承諾人簽字：

xx年xx月xx日

軟件質量保證承諾書2

如果我公司在貴單位組織的項目名稱：長沙市地方稅務局機關及稽查局大院安全技術防范設備采購項目招標中獲取中標，應項目投標的`有關要求，我方對該項目做出如下產(chǎn)品質量承諾：

（1）技術規(guī)范及相關產(chǎn)品標準：按國家標準執(zhí)行。

（2）產(chǎn)品都是廠家原裝正品產(chǎn)品。

（3）所有的附件及零配件是正規(guī)廠商生產(chǎn)的產(chǎn)品。

（4）產(chǎn)品“三包”內(nèi)容：實行包退、包換、包修服務。

（5）質量問題的處理：按廠家質量保證實行。

（6）質量投訴的處理：由專人負責本次項目投訴處理。

（7）質保期內(nèi)所有軟件維護、升級和設備維護等免費上門服務。

20xx年xx月xx日

xxx

軟件質量保證承諾書3

本公司秉持以“優(yōu)質的產(chǎn)品，合理的價格，周到的服務”的.原則和宗旨，向用戶莊嚴承諾：

一、本公司保證出廠的產(chǎn)品嚴格按國家有關標準執(zhí)行，不合格的產(chǎn)品決不出廠。

二、本公司產(chǎn)品質量保證期為一年。保修期內(nèi)，用戶對產(chǎn)品質量有異議的，本公司在24小時之內(nèi)作出處理意見，并負責缺陷產(chǎn)品免費召回、更換或按訂貨價退款;保修期外，用戶對產(chǎn)品質量有異議的，本公司在48小時之內(nèi)作出處理意見，并負責缺陷產(chǎn)品有償更換。

三、本公司產(chǎn)品質量由中國人民財產(chǎn)保險公司承保。

浙江××有限公司

20xx年xx月xx日

第三篇：淺談軟件質量保證

淺談軟件質量保證

摘要：

Software Quality Assurance軟件質量保證（SQA）是建立一套有計劃，有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用

前言：

SQA的由來：隨著第一個正式的質量保證和控制方案在1916年貝爾實驗室的出現(xiàn)，整個制造業(yè)都認可了這一方案，時至今日每個公司都有其保證其產(chǎn)品質量的機制，公司對質量的保證也漸漸成為其核心的市場策略。對于軟件開發(fā)來說，一個項目的主要內(nèi)容是：成本、進度、質量。軟件本身作為一種無形產(chǎn)品，其質量指的是：“系統(tǒng),部件或者過程滿足顧客或者用戶需要或期望的程度”。在20世紀五六十年代，質量保證曾經(jīng)只由程序員承擔。而正規(guī)的軟件質量保證標準首先在20世紀70年代初軍方的軟件合同中出現(xiàn)，此后迅速傳遍整個商業(yè)世界。提出而隨著市場化發(fā)展的成型，任何軟件公司對自己產(chǎn)品的質量問題越來越關注，測試所花費的成本越來越多。在起初國外很多的大軟件公司公司比如IBM、CA等，SQA的職責就是測試（主要是系統(tǒng)測試）。后來，由于缺乏有效的項目計劃和項目管理，留給系統(tǒng)測試的時間很少。另外由于軟件最終使用者的不專業(yè)性，需求變化太快，沒有完整的需求文檔，測試人員就只能根據(jù)自己的想象來測試。這樣一來，測試就很難保障產(chǎn)品的質量，促進了事先預防的SQA職能的產(chǎn)生。隨后隨著軟件開發(fā)模型的不斷演化和發(fā)展CMM模型的出現(xiàn)，它引入了“全面質量管理”的思想，至此許多公司將SQA人員獨立于項目組，以保證評價的客觀性。專業(yè)的SQA人員應運而生。

簡介：

軟件質量保證（SQA）是建立一套有計劃，有系統(tǒng)的方法，來向管理層保證擬定出的標準、步驟、實踐和方法能夠正確地被所有項目所采用。其根本目的是使軟件過程對于管理人員來說是可見的。它通過對軟件產(chǎn)品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質量保證組在項目開始時就一起參與建立計劃、標準和過程。這些將使軟件項目滿足機構方針的要求。

SQA的基本目標：

1: 軟件質量保證工作是有計劃進行的。

2: 客觀地驗證軟件項目產(chǎn)品和工作是否遵循恰當?shù)臉藴省⒉襟E和需求。3: 將軟件質量保證工作及結果通知給相關組別和個人。

4: 高級管理層接觸到在項目內(nèi)部不能解決的不符合類問題。

具體分析：

1：軟件質量所包含的因素及軟件質量評價標準：

軟件質量包含的因素：正確性，可靠性，效率，完整性，可用性可維護

性，靈活性，可測試性，可移植性，可復用性，互操作性等等。

軟件質量評價標準：質量需求準則，著眼點是是否滿足用戶的要求；質量設計準則，開發(fā)者在設計實現(xiàn)時是否按軟件需求保證了質量。質量度量準則，為質量度量規(guī)定了一些檢查項目。

從事專業(yè)SQA的人員所應具備的基本素質，工作中的基本職能及與其他相似職能的區(qū)別：

SQA人員所應具備的基本素質：

按照軟件界已經(jīng)達成的共識：影響軟件項目進度、成本、質量的因素主要是 “人、過程、技術”。首先要明確的是這三個因素中，人是第一位的。SQA小組的成員首先應當時刻以客戶的觀點看待軟件。從事SQA工作由于要按照相應的標準對專業(yè)的行為加以監(jiān)管，深刻了解企業(yè)的工程，并具有一定的過程管理理論知識 對開發(fā)工作的基本情況了解，能夠理解項目的活動，因此首先應具備較高的關于軟件開發(fā)方面的知識；在工作中過程為中心：應當站在過程的角度來考慮問題，只要保證了過程，QA就盡到了責任；還應具有服務精神即為項目組服務，幫助項目組確保正確執(zhí)行過程；另外應善于溝通，能夠營造良好的氣氛，避免其工作本身成為一種找茬活動。我所在的小組在課程實踐過程中就出現(xiàn)過負責設計的同學對編碼階段的同學出現(xiàn)質疑，最終出現(xiàn)不愉快的事情。

工作中的基本職能以及于其他相似職能的區(qū)別：

要做好SQA工作首先應該明確SQA人員的職能以及與QC、SEPG的區(qū)別。QC：檢驗產(chǎn)品的質量，保證產(chǎn)品符合客戶的需求；是產(chǎn)品質量檢查者； SEPG：制定過程，實施過程改進；

而SQA人員的主要工作為審計過程的質量，是過程質量審計者，其基本職能為確保過程被正確執(zhí)行。其本身并不參與過程的制定，A的職責就是確保過程的有效執(zhí)行，監(jiān)督項目按照過程進行項目活動；它不負責監(jiān)管產(chǎn)品的質量，不負責向管理層提供項目的情況，不負責代表管理層進行管理，只是代表管理層來保證過程的執(zhí)行。

3：SQA活動：

軟件質量保證由各種任務構成，這些任務分別與兩種不同的參與者有關：做設計工作的軟件工程師和SQA小組成員。

軟件工程師通過采用可靠的技術方法和措施，進行正式的技術評審，執(zhí)行計劃周密的軟件測試來考慮質量問題（并完成軟件質量保證和質量控制活動）

SQA小組成員的職責為輔助軟件工程小組得到高質量的最終產(chǎn)品。其主要工作如下：

為項目準備SQA計劃。該計劃在制定項目計劃實制定，由所以感興趣的相關部門評審。該計劃將控制由項目組和SQA小組執(zhí)行的質量保證活動。在計劃中應標識一下幾點：需要進行的評價；需要進行的審計和評審；項目可用的標準；錯誤報告和跟蹤的規(guī)程；由SQA小組產(chǎn)生的文檔；為軟件項目提供的反饋數(shù)量。另外還需明確最終審計的結果報告給誰。

參與開發(fā)該項目的軟件過程描述。軟件工程小組為要進行的工作選擇一個過程。SQA將評審過程描述以保證該過程與組織政策，內(nèi)部軟件標準，外界所訂標準（如ISO9001）以及軟件項目計劃的其他部分相符。

評審各項軟件工程活動，對其是否符合定義好的軟件過程進行核實。SQA小組識別記錄和跟蹤與過量的偏差，并對是否已經(jīng)改正進行核實。

審計指定的軟件工作產(chǎn)品，對其是否符合定義好的軟件過程中的相應部分進行核實。SQA小組對選出的產(chǎn)品進行評審；識別，記錄和跟蹤出現(xiàn)的偏差；對是否已經(jīng)改正進行核實；定期將工作結果向項目管理者報告。在審計過程中。注意審計一定要有項目組人員陪同，雙方要開誠布公，坦誠相對。審計的內(nèi)容主要包括：是否按照過程要求執(zhí)行了相應活動，是否按照過程要求產(chǎn)生了相應產(chǎn)品。

確保軟件工作及工作產(chǎn)品中的偏差已被記錄在案并根據(jù)預定規(guī)程進行處理。偏差可能出現(xiàn)在項目計劃，過程描述，采用的標準或技術工作產(chǎn)品中。

記錄所有不符合的部分并報告給高級管理者。對不符合的部分進行跟蹤直至問題得到解決。

4：軟件評審：軟件評審是軟件工程過程中的過濾器。評審被用于軟件開發(fā)過程的多個不同的點上，起到發(fā)現(xiàn)錯誤和缺陷節(jié)日引發(fā)排錯活動的作用。軟件評審起到的作用是凈化分析，設計和編碼的軟件工程活動。在課程實踐過程中由于初始需求分析的不明確以及后來概要設計過程中關鍵點的遺漏所引發(fā)的錯誤曾經(jīng)導致我們小組代碼的兩次大部分返工，現(xiàn)在看來在課程實踐過程中沒有進行軟件評審所致

5：正式技術評審（FTR）

正式技術評審是一種由軟件工程師和其他人進行的軟件質量保障活動。

正式技術評審的目標是：發(fā)現(xiàn)功能、邏輯或實現(xiàn)的錯誤；證實經(jīng)過評審的軟件的確滿足需求；保證軟件的表示符合預定義的標準；得到一種一致的方式開發(fā)的軟件；使項目更易管理。

評審會議一般由3-5人參加，不超過2小時，由評審主席、評審者和生產(chǎn)者參加，必須做出下列決定中的一個：工作產(chǎn)品可不可以不經(jīng)修改而被接受；由于嚴重錯誤而否決工作產(chǎn)品；暫時接受工作產(chǎn)品。

評審總結報告和記錄保存：評審會議結束時，生成一份評審問題列表，完成一份包括“評審什么？由誰評審？結論是什么？”的評審總結報告。

評審總結報告是項目歷史記錄的一部分，標識產(chǎn)品中存在問題的區(qū)域，作為行政條目檢查表以指導生產(chǎn)者進行改正。

評審指導原則：評審產(chǎn)品，而不是評審生產(chǎn)者。注意客氣地指出錯誤，氣氛輕松；制定日程并且遵守日程；不要離題，限制爭論和辯駁。有異議的問題不要爭論但要記錄在案；對各個問題都發(fā)表見解。問題解決應該放到評審會議之后進行；做書面筆記；限制參與者的人數(shù)并堅持事先做準備；為每個要評審的工作產(chǎn)品建立一個檢查表。應為分析、設計、編碼、測試文檔都建立檢查表。；為了讓評審有效，為FTR分配資源和時間；為了提高效益對所有評審進行有意義的培訓；評審以前所做的評審。

6結合課程實踐淺談自己的感受

下面我將結合課程的實踐講一講個人對于軟件質量保證的一些感受，首先說一說每個人所扮演的角色，負責編碼的同學相當于軟件工程師的角色，而負責需求分析及概要設計的同學責同時兼任了SQA小組成員的角色。在具體實現(xiàn)過程中，在需求分析階段，通過需求調研我們小組大體明確了客戶即TA對機動車違章管理系統(tǒng)的需求，但由于沒有把需求調研的工作做到位，在完成需求分析的過程中，我們小組出現(xiàn)了一些問題，主要是對TA要求的理解出現(xiàn)了分歧。此時承擔SQA小組責任的同學并沒有嚴格要求自己進一步與TA溝通，解決理解上的分歧，而是個人主觀的認為自己的理解就是對的。致使在具體實現(xiàn)時與初始需求出現(xiàn)了一些偏差。這個問題的發(fā)生，主要是因為承擔需求分析的同學同時兼任SQA小組工作的原因，致使監(jiān)督的客觀性方面出現(xiàn)了問題。在概要設計階段由于考慮到后期一些功能在后期具體實現(xiàn)中的困難，沒有嚴格按照獲取的需求進行設計，主要是出于實現(xiàn)難度的考慮草率的對本已獲得的需求進行了一些修改致使本就出現(xiàn)變差的需求進一步打了折扣。在編碼階段針對出現(xiàn)問題時，更是僅僅是就問題而談問題，把原始的計劃放到了一邊。回顧整個課程的過程：從在初始人員定位時并沒有認識到SQA小組的重要性，因此并沒有嚴格指定專人負責，只是在出現(xiàn)問題時才想到，而在明確兩人兼任SQA小組工作后，也沒有嚴格制定明確的計劃，也沒有正式的評審各項軟件工程活動，僅僅是想到什么就說什么，不但造成了小組成員間的沖突，更是對問題的解決沒有多大的幫助。而“軟件工程師”即從事編碼的同學雖然對軟件本身進行了一些測試，修正了一些錯誤，改進了一些BUG，但這一切都是通過想當然去做的，并沒有參考設計文檔。結論：

無論何種軟件只有在保證其質量的前提下才能體現(xiàn)出它的價值。軟件質量保證則是保證軟件質量的基石。而在軟件質量保證的過程中，首先應該明確自己的定位，而后嚴格按照上面提出的步驟與方法去實現(xiàn)才能更好的完成SQA工作。這一切，都需要我們在今后的學習、工作中積極地去實踐。

參考文獻：

軟件工程實踐者的研究方法 Roger S.Pressman

軟件質量保證 Schulmeyer,G.G

第四篇：軟件質量保證管理

1、V模型：V模型是在RAD模型的基礎上演變而來的，由于開發(fā)過程構造成一個V字形而得名。V模型強調軟件開發(fā)的協(xié)作和速度，將軟件實現(xiàn)和驗證有機地結合起來，在保證較高的軟件質量情況下縮短開發(fā)周期。V模型具有面向客戶、效率高、質量防范意識等特點。

左邊是設計和分析，是軟件設計實現(xiàn)的過程，同時伴隨著質量保證活動---審核過程，也就是靜態(tài)的測試過程；右邊是對左邊結果的驗證，是動態(tài)的過程，即對設計和分析的結果進行測試，以確認是否滿足用戶的需求。V模型避免了瀑布模型所帶來的誤區(qū)-----軟件測試是在代碼完成之后進行的。p302、什么是變更控制？（P111）

軟件開發(fā)過程中都會產(chǎn)生許多變更，如配置項，配置，基線，構建的版本，發(fā)布的版本的變更，對于這些變更，都要有一個控制機構，以保證所有的變更都是可控的，可跟蹤的，可重現(xiàn)的。這樣的一類機構對變更的管理，就是變更控制。

3、軟件可靠性概念？（P176）

軟件可靠性是指在給定時間內(nèi)，特定環(huán)境下軟件無錯運行的概率，軟件可靠性包含了以下三個要素：規(guī)定的時間，規(guī)定的環(huán)境條件，規(guī)定的功能。

4、CMM（P195）

CMM：能力成熟度模型，用來衡量組織軟件過程成熟度和評價其軟件過程能力。能力成熟度是指一個特定過程被明確定義，管理，測量，控制并且是有效的程度。分為五個等級： 初始級 軟件過程的特點是無序的，甚至是混亂的。幾乎沒有什么過程是進過定義的。可重復級 關鍵過程區(qū)域集中關注軟件項目所關心的，與建立基本項目管理控制有關的事情。

已定義級 將軟件生命周期的各個階段嚴格的劃分出來，從組織這個層次來保證過程質量該進

已管理級 軟件產(chǎn)品的質量目標被量化管理，它遵循了全面質量管理活動的科學程序，關鍵過程域的關注焦點是建立起對軟件過程和正在構造的軟件工作產(chǎn)品的定量了解。

優(yōu)化級 關鍵過程域包括那些為了實施連續(xù)不斷的和可測的軟件過程改進，組織和項目都必須解決的問題。

5、TQM的實施步驟（P265）

（1）建立質量小組，負責過程改進，流程完善，不斷發(fā)現(xiàn)質量問題提出并實施解決方案。

（2）進行TQM思想的教育，通過教育，要讓每個員工深刻認識到“滿足顧客的需求是第一的”的思想，理解“什么是顧客需求”，如何讓顧客滿意等內(nèi)容。

（3）了解市場，明確顧客需求，了解目前研發(fā)的軟件產(chǎn)品的市場，包括競爭對手，客戶群等，讓員工明白什么是質量好的軟件產(chǎn)品或軟件服務，認真對待質量要求，開發(fā)出合格的產(chǎn)品。

（4）建立明確的質量基準和質量評估機制，以便和實際質量水平進行對比，識別質量的目標和工作的重點區(qū)域，采取相應措施。

（5）建立相對完善的獎勵機制，在認可和給予獎勵的過程中，應力求公正，真實，選擇恰當?shù)臅r間，恰當?shù)膱龊希‘數(shù)姆绞健?/p>

2、版本控制的目的:是在于對軟件開發(fā)過程中文件或目錄的發(fā)展過程提供有效的追蹤手段，保證在需要時找到舊的版本，避免文件的丟失，修改文件的丟失和相互覆蓋，通過對版本庫的訪問控制避免未經(jīng)授權訪問和修改。另外軟件的控制是實現(xiàn)團隊開發(fā)，提高效率的基礎。

3、PDCA包括4個部分：計劃、執(zhí)行、檢查、行動描述總結

(1)計劃計劃：就是分析當前狀況，發(fā)現(xiàn)問題，找出原因和主要原因，制定質量方針、質量

目標、質量計劃書和管理原則。管理原則有：過程方法、管理的系統(tǒng)方法、持續(xù)改進

(2)執(zhí)行：執(zhí)行時計劃的履行和實現(xiàn)，主要按計劃實施地去做，去落實具體對策，并實施過

程的監(jiān)控，使活動按預期設想前進，最終達到計劃設定的目標。

(3)檢查：是對執(zhí)行后效果的評估。檢查是伴隨著實施過程自始至終的，不斷收集數(shù)據(jù)、信

息獲取的過程，并通過數(shù)據(jù)分析、結果度量來完成檢查。

行動：重點在于檢查完結果，要采取措施，即總結成功的經(jīng)驗，吸取失敗的教訓，實施標準化，以后依據(jù)標準執(zhí)行。

4、階段性開發(fā)模型：增量模型和迭代模型

(1)增量模型描述軟件產(chǎn)品的不同階段是按產(chǎn)品所具有的功能進行劃分的，先開發(fā)主要

功能或用戶最需要的功能，然后隨著時間的推進，不斷增 加新的輔助功能或次要功能，最終開發(fā)出一個功能完善的，穩(wěn)定的產(chǎn)品。

(2)迭代模型描述軟件產(chǎn)品的不同階段是按產(chǎn)品深度或細化程度來劃分，先將產(chǎn)品的整個框架都建立起來，在系統(tǒng)的初期，已經(jīng)具有用戶所需要的全部功能。然后隨著時間推進,不斷細化已具有的功能或完善已具有的功能,這個過程是一個迭代的過程

6、零缺陷質量管理的實施步驟：（P268）

（1）建立推行零缺陷質量管理的組織事情的推行都需要組織的保證，通過建立組織，可以動員和組織全體職工積極的投入零缺陷管理，提高他們參與管理的自覺性也可以對每個人的合理化建議進行統(tǒng)計分析，不斷進行經(jīng)驗交流，公司的最高管理者要親自參加，表明決心，做出表率，要任命相應的領導人，建立相應的制度，要教育和訓練員工

（2）確定零缺陷管理的目標，確定零缺陷小組在一定時期內(nèi)所要達到的具體要求，包括確定目標項目，評價標準和目標值

（3）進行績效評價，（4）建立相應的提案機制

（5）建立表彰制度

SQA組織的責任是審計軟件經(jīng)理和軟件工程組的質量活動中出現(xiàn)的偏差。

7、SQA計劃（P283）

SQA在項目早期要根據(jù)項目計劃制定與其相應的SQA計劃，定義各階段的檢查點。標識出檢查審計的工作產(chǎn)品對象，以及在每個階段SQA的輸出產(chǎn)品。具體實施步驟如下：

（1）了解項目的需求，明確項目SQA計劃的要求和范圍

（2）選擇SQA任務

（3）估計SQA的工作量和資源

（4）安排SQA任務和日程

（5）形成SQA計劃

（6）協(xié)商，評審SQA計劃

（7）批準SQA計劃

（8）執(zhí)行SQA計劃

SQA計劃包含以下內(nèi)容：

（1）目的，SQA計劃的目的和范圍（2）參考文件，該SQA計劃參考的文件列表（3）管理，組織，任務，責任（4）文檔，列出所有的相關文檔，如程序員手冊，測試計劃，配置管理計劃等（5）標準定義，文檔標準，邏輯結構標準，代碼編寫標準，注釋標準等（6）評審/審核（7）配置管理，配置定義，配置控制，配置評審（8）問題報告和處理（9）工具，技術，方法（10）代碼控制（11）事故/災難控制，包括火災，水災，緊急情況等。

8、評審和審核的區(qū)別？（P285）

評審：過程進行時，SQA對過程的檢查，SQA的角色在于確保當執(zhí)行工程活動時，各項計劃所規(guī)定的過程得到遵循，評審通常通過評委會的的方式進行，是對工作流程的評審

審核：在軟件工作產(chǎn)品生成時，SQA對工作產(chǎn)品進行的檢查，SQA的角色在于確保開發(fā)工作產(chǎn)品中各項計劃所規(guī)定的過程得到遵循，審核通常通過對工作產(chǎn)品的審查來執(zhí)行。側重于產(chǎn)品本身。

SQA報告應遵循三條原則SQA和高級管理者之間應有的溝通渠道，SQA報告必須發(fā)布給軟件工程組織但不必發(fā)布給項目管理人員，在可能的情況下向關心軟件質量的人發(fā)布。

SQA度量是記錄花費在SQA活動時間人力數(shù)據(jù)。涉及以下三方面：軟件產(chǎn)品評估度量、軟件產(chǎn)品質量度量、軟件過程審核度量。

SQA的評估任務是軟件開發(fā)前期對目標的軟件和硬件資源進行評估，以確保其充分性和適合性。

9、白盒測試、黑盒測試（P390）

白盒測試將被測試程序看做一個盒子，測試者能夠看到被測程序，可以分析被測程序的內(nèi)部結構。

白盒測試可以用來對代碼結構進行全面測試，常用的有語句覆蓋，判定覆蓋，條件覆蓋，判定/條件覆蓋，條件組合覆蓋，路徑覆蓋，循環(huán)測試

黑盒測試常用來驗證軟件或模塊功能是否得到實現(xiàn)，主要運用單元的性能和功能方面的測試除了測試其功能外，還需確保代碼在結構上可靠，健全并能夠有良好的響應。黑盒測試主要運用于單元的功能和性能方面的測試。功能測試包括用戶界面測試各種操作的測試不同的數(shù)據(jù)輸入邏輯思路，數(shù)據(jù)輸出和存儲的測試。

區(qū)別：關鍵區(qū)別應該就是測試對象不一樣，白盒測試主要針對的是程序代碼邏輯，黑盒測試主要針對的是程序所展現(xiàn)給用戶的功能，簡單的說就是前者測試后臺程序后者測試前臺展示功能

10、測試的原則概括為10項：

（1）所有測試的標準都是建立在用戶需求之上2軟件測試必須基于“質量第一”的思想去開展各項工作3實現(xiàn)定義好產(chǎn)品的質量標準4軟件項目一啟動。軟件測試也就是開始5窮舉測試是不可能的6第三方進行測試會更客觀，更有效7軟件測試計劃是做好軟件測試工作的前提8測試用例的設計出來的，不是寫出來的9不可將測試用例置之度外，排除隨意性10對發(fā)現(xiàn)錯誤較多的程序段，應進行更深入的測試

39、功能測試的概念：是基于產(chǎn)品功能說明書，是在已知產(chǎn)品所應具有的功能，從用戶角度來進行功能驗證，以確認每個功能是否能正常使用、是否實現(xiàn)了產(chǎn)品規(guī)格說明書要求、是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出結果等。

5、風險管理法：SEI（軟件工程研究所）風險控制一般分5個步驟：P80

(1)風險識別：試圖系統(tǒng)化的方法來確定威脅項目計劃的因素。識別方法包括：風險檢

測表、頭腦風暴會議、流程圖分析、與項目人員面談。

(2)風險分析：可以分為定性風險分析和定量風險分析。定性風險分析是評估已經(jīng)識別

風險的影響和可能性的過程。定量風險分析是量化分析每一風險的概率及其對項目目標造成的后果，同時也要分析項目總體風險的程度。

(3)風險計劃：制定風險行動計劃，應考慮以下部分：責任、資源、時間、活動、應對

措施、結果、負責人。

(4)風險控制：方法：風險避免、風險弱化、風險承擔、風險轉移。

(5)風險跟蹤：監(jiān)視風險的狀況，檢查風險的對策是否有效、跟蹤機制是否在運行，不

斷識別新的風險并制定對策。

6、評審的內(nèi)容：分為管理評審、技術評審、文檔評審、過程評審（P217簡答）

(1)管理評審是以實施質量方針和目標的質量體系的適應性和有效性為評論基準,對體系文

件的適應性和質量活動的有效性進行評價。目標：按規(guī)定的時間間隔對質量體系進行評審，確保持續(xù)的適宜性和有效性，以滿足本標準要求和提供的質量方針和目標。輸入：體系審核的結果。輸出：《管理評審報表》

(2)技術評審是對產(chǎn)品以及各階段的輸出內(nèi)容進行評估。目的：確保需求說明、設計說明書

與最初的說明書保持一致，并按照計劃對軟件進行了正確的開發(fā)。輸入：需求文檔、源代碼、測試用例、評審檢查單、其它文檔。輸出：技術評審報告

(3)文檔評審分為格式評審和內(nèi)容評審。

(4)過程評審是對軟件開發(fā)過程的評審，其主要任務是通過對流程的監(jiān)控，保證SQA組織

定義的軟件過程在項目中得到了遵循，同時保證質量方針能得到更快更好的執(zhí)行。

40.朱蘭三部曲：

質量策劃：為建立有能力滿足質量標準化的工作程序，質量策劃是必要的質量控制：為了掌握何時采取必要措施糾正質量問題就必須實施質量控制

質量改進：質量改進有助于發(fā)現(xiàn)更好的管理工作方式

40、從軟件開發(fā)的各階段論述如何提高軟件產(chǎn)品的質量？

1、需求

我們知道人與人的交流總是會存在一些誤會，同樣一句話，心情不好與心情好的時候聽起來的感覺可能會截然相反，正是因為人們之間存在著理解上的偏差，在描述需求的語言上就應該注意盡量避免歧義的產(chǎn)生。如果對UML比較熟悉的話，需求分析可以利用UML工具進行，這樣可以減少一些自然語言引起的歧義，但是UML可能與用戶溝通起來有一些障礙，因為并不是所有的用戶都了解UML各種圖形的意思。除了工具之外，我們可以從以下幾個方面來保證需求描述的質量。

1、看句子和段落是否簡短，一個很長的句子，看起來會非常困難，因此無法弄懂真正的需求，另外過長的句子和段落容易讓人忽視一些需求，所以如果一個句子不能完全描述清楚需求，應該將其拆分成多個小句子。

2、句子是否有語法錯誤，還要注意標點符號，有時，標點符號點錯了，就完全成了另外一個意思了。

3、是否存在模糊不清的需求，出現(xiàn)類似于可能，大概，或者等詞匯表述的需求。

4、另外注意引用的術語和詞匯是否前后一致。

5、是否存在一些形容詞、比較性詞語，比如：容易的、快速的、方便的、有效的、許多、很少、簡單、復雜、最新的，界面友好的，減少、擴大，不小于等等，需要將描述性詞語進行量化，并且給出具體值或者范圍，要不然不同的人根據(jù)不同的理解就會得出不同的結果，最終可能跟用戶最初的要求有偏差，那“炒回鍋肉”的事情就不可避免地會發(fā)生。

另外保證需求質量的一個很重要的因素就是需求是否細化，如果需求不細化也會很容易造成代碼的返工，于是就出現(xiàn)了我們的程序員盡管總是加班加點卻總是不能如期的完成任務的情景。那么我們怎樣才能判斷需求細化的程度呢?需求細化程度確實很難把握，什么樣的需求可以算是比較細了，不用再進行細化了呢?哪些需求又太粗了呢?答案是需求是否可以寫出相應的測試用例，如果寫不出來，就說明需求還不是很細，還需要再進行細化。

2、設計

軟件架構設計在軟件產(chǎn)品開發(fā)周期中占有很重要的位置，我們開發(fā)出來的軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會涉及到方方面面的角色，例如：用戶、項目管理人員、程序員、測試員、維護人員等等。不同的角色對架構設計的要求也不相同。例如用戶關心的是需求，因此我們的設計對需求的覆蓋率是多少?對于程序員來說模塊是否清晰，類的功能是否單一等等，對于測試人員來說系統(tǒng)的是系統(tǒng)的可測試性。對于維護人員來講系統(tǒng)的擴展性、可維護性如何?一個高質量的軟件架構，應該最大限度的考慮并滿足不同角色的不同要求。正

是因為有這些要求，我們在進行軟件設計的時候，應該進行全面的考慮。一般用來衡量軟件設計質量的標準可以從以下幾個方面來考慮：

1)、功能性：包括完全性、正確性、安全性、兼容性、互用性。完全性包括功能點覆蓋率，重點功能點覆蓋率，優(yōu)先功能覆蓋率。正確性包括需求一致度。安全性根據(jù)軟件需求的不同有不同的安全性要求。

2)、效率：包括產(chǎn)品運行的時間效率和利用的硬件資源兩方面來考慮。

3)維護性：包括架構的可改正性，可擴充性以及可測試性。如果用戶的一個很小的需求變更會引起架構設計很大的變化，那么這樣的架構設計的可改正性和可擴充性就比較差。

4)可移植性：包括硬件的獨立性、軟件獨立性、可安裝性、可重用性。軟件設計是否模塊化、每個模塊的可復用性如何都是應該考慮的因素。

5)可靠性：包括缺陷數(shù)量、容錯性、可用性。

6)使用性：包括可理解性、易學習性、可操作性、易溝通性。我們軟件的最終目的是讓用戶來使用的，如果易用性不好，可操作性不好都會影響用戶對軟件的接納程度。因此在軟件的可使用性也是非常重要的。

3、編碼

代碼質量的一個很重要的標準就是代碼的可讀性及規(guī)范性，可讀性不一定是簡單的代碼，而是容易理解的代碼，因為過于復雜的代碼難以測試和維護，同時出錯的幾率也會更高。如果一個方法內(nèi)部的代碼很長，而且使用了很多令人難以理解的數(shù)據(jù)集，這樣就會帶來代碼維護的困難，因為很少有人能夠有效地分析它們，因此也就是最容易出現(xiàn)缺陷和錯誤的地方。類之間的耦合度會造成類與類之間的相互關聯(lián)，當一個類發(fā)生改變時會使其他的類發(fā)生意想不到的變化，一般從導入類的個數(shù)判斷類之間的耦合度，如果導入類的個數(shù)很多，每一個導入類發(fā)生變化都會影響到該類本身，另外如果該類的public方法太多也會導致類之間的高耦合性增加。

也許有的程序員會認為寫出可讀、規(guī)范的代碼會影響工作進度。的確，對于程序員個體短時間來說為代碼寫上注釋是要花費些時間，但如今軟件開發(fā)是多人協(xié)作

周期很長的過程，寫過程序的人都知道，如果自己寫了不規(guī)范的代碼，隨著自己所寫的代碼越來越多，到后來需要修改某個前期寫的模塊時都不知道自己當初是怎么想的了，讀自己的代碼也需要花很長時間才讀懂。況且如果隨著人員的調動等其他原因，往往維護代碼的程序員已不是當初寫代碼的人，很多情況就是讀懂了一段糟糕的代碼還比重新寫出一段代碼花費的時間還長，嚴重影響工作效率(有些時候還影響維護人員的心情)，反過來，如果大家都講究把代碼寫成規(guī)范可讀的，無疑對于整個組織來說提高總體工作效率是非常有用的。

代碼質量另一個非常重要的衡量手段就是測試，通過統(tǒng)計測試代碼所產(chǎn)生的缺陷情況，如嚴重等級分布、缺陷曲線的變化等可以從一個方面來簡單地評估代碼質量。

4、測試

測試人員在測試過程中，需要站在不同的利益相關者的角度，對測試對象的質量進行檢查和驗證，例如：測試人員除了關注需求文檔中明確描述的需求條目之外，還應該關注隱現(xiàn)的需求，比如：競爭對手的產(chǎn)品特征、用戶的群體特征和使用習慣等。因此，在測試過程中，測試人員除了關注測試對象的功能測試之外，還需要針對其他非功能特性進行測試。

為了在測試過程中盡量多的覆蓋質量特性，測試人員需要清楚的了解產(chǎn)品有哪些質量特性是客戶最關注的因此，測試人員在進行具體的測試用例設計和執(zhí)行之前，需要定義該產(chǎn)品應該滿足的質量特性集。

第五篇：《軟件測試與質量保證》讀書報告

學生課程讀書報告

姓

名

某某某

學號＿

0000000＿

專

業(yè)＿ 軟件工程＿＿ 班級＿**級軟件*班

讀書報告題目

××××××××××××× 指導教師及職稱

XXX

開課學期

2011

至＿ 2012 學年＿1＿學期

此處寫題目(應用此格式)

學號：

姓名：

1.一級標題格式（黑體小四）

正文格式（宋體五號）

1.1 二級標題格式（楷體五號加粗）

正文格式（宋體五號）

參考文獻

[1] 作者一, 作者二, 作者三等.論文題目.期刊名稱, 年份, 卷號(期號):起始頁-終止頁.[2] 作者一, 作者二, 作者三等.書名(版次).出版社, 年份, 起始頁-終止頁.