【正文】 件配置管理的基石，要給每個配置項提供唯一的標識。受控庫通常是階段性的工作成果，要必須對其進行管理的，它必須經過審批后方可進入受控庫。審時的時機有2個：階段性里程碑處和基線變更之后。軟件測試Error! Reference source not 、嚴格的理論與實踐體系。我們可以把所有的軟件問題統(tǒng)稱為軟件缺陷，但為了能更嚴格地定義軟件缺陷，避免開發(fā)組內產生不同的認只，可以從以下5點來定義軟件缺陷Error! Reference source not found.：(1) 軟件未達到產品說明書標明的功能； (2) 軟件產品出現(xiàn)了產品說明書指明不會出現(xiàn)的錯誤；(3) 軟件功能超出產品說明書范圍；(4) 軟件未達到產品說明雖未指出但應達到的目標，此條的目的是抓住產品說明書上的遺漏之處；(5) 軟件測試員認為軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認為不好。l 白盒測試：測試人員直接在軟件的源程序上進行測試、修改、復測。測試工程師對軟件工程結構有一定了解，但了解的程度又不需要達到白盒測試的深度。回歸測試一般是在缺陷修改之后執(zhí)行，保證原缺陷不在重現(xiàn)，并且缺陷的修改不影響其他功能。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現(xiàn)測試方案、方法、技術和策略。測試人員依據(jù)測試計劃與測試用例執(zhí)行測試工作，并對測試過程中發(fā)現(xiàn)的缺陷進行跟蹤，及時解決驗證。自動化測試并不能完全取代手測，與任何事物一樣，自動化測試也有它的不完美之處。(4) 自開發(fā)的測試軟件，適用于特定領域。(2) 挑選人員進行討論。(6) 畫出整個因果圖。帕累托圖對問題發(fā)生的頻率或影響按照從大到小的方式進行排列，從而確定解決問題的先后順序。通過帕累托圖，管理人員可以很快找到那20%的主要原因并進行解決，使系統(tǒng)的質量得到迅度提升。32第五章 質量管理在實際項目中的應用 定義合適的項目過程軟件過程是指開發(fā)和維護軟件產品的活動、技術和實踐的集合。公司在開發(fā)項目上按照規(guī)范化軟件的生產方式進行生產，在生產流程上采用ISO9000的標準進行。如上所述，配置管理小組還是保證質量保證小組得以發(fā)揮作用的基礎。對所有存檔的文檔進行版本控制；而這些測試均需要在測試計劃和測試策略中進行描述用以指導測試小組成員進行測試用例編寫和測試執(zhí)行。在正確性測試完成之后，需要測試的是軟件的性能，軟件的性能在本項目中占有重要的地位，性能要求有可能改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側重。質量保證小組對項目經理提供項目進度與項目真正開發(fā)時的差異報告，提出差異原因和改進方法。質量保證小組的檢測范圍包括：系統(tǒng)分析人員是否正確的反映了用戶的需求；如果項目開發(fā)計劃的制定的是完全合理的，那項目進度也就真正表達了項目與最終的交付使用之間的距離，然而要制定完全合理的項目開發(fā)計劃幾乎不太可能。 當項目計劃制定初期，由質量保證小組組織召開的項目計劃評審會，邀請公司技術專家、用戶以及項目組小組成員一起討論項目計劃的可行性，會議通常采用頭腦風暴法，各抒己見，會后由指定的記錄員形成質量記錄，發(fā)送給相關人員，對其計劃中不合理的地方進行修改完善，并由質量保證人員對其結果跟蹤，以確保項目計劃完整性、可行性，完善后的計劃交由配置管理人員進行版本控制。根據(jù)里程碑的完成情況，適當?shù)恼{整每一個較小的階段的任務量和完成的任務時間，這種方式非常有利于整個項目計劃的動態(tài)調整。從系統(tǒng)分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識是困難的。 解決系統(tǒng)分析錯誤的方法。但是對于無法實現(xiàn)或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進行協(xié)調會議，討論變更取舍問題或是項目進度變更問題。 公司有過一個項目，用戶指定需要采用面向對象分析、設計和開發(fā)，且開發(fā)周期短，在無奈的情況下，項目小組只能選用面向對象的軟件開發(fā)過程，由于項目小組很少從事過面向對象的開發(fā)，經驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。在這次開發(fā)中我們公司從管理人員、設計人員到開發(fā)人員都汲取了很多教訓，同時經過此次項目的開發(fā)，小組成員也積累了豐富的面向對象的開發(fā)經驗。對于項目組提供的設計文檔，由質量保證小組組織技術專家、項目組設計人員、開發(fā)人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時發(fā)現(xiàn)設計中可能存在的錯誤，降低項目開發(fā)風險，同時確保設計文檔能為開發(fā)人員、測試人員提供切實的指導。 實現(xiàn)也就是代碼的生產過程。測試過程通常在模擬環(huán)境中進行。在這測試活動過程中，我們應該遵守一條基本原則——按照用戶需求進行測試。所以通常項目維護小組成員主要由項目組的少部分開發(fā)人員承擔完成。 維護小組的人員基本上是按項目跟進的。 內部文檔包括：詳細設計說明；組件索引；測試報告；文檔分類版本索引；軟件操作手冊；如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。 從以往做大項目的經驗來看，寫作文檔在項目開發(fā)的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發(fā)者越來越需要知道其他人員的開發(fā)思路和開發(fā)過程，才能使自己的開發(fā)向前推進。認證根據(jù)文檔的不同，文檔的來源也不同，有些是通過質量保證小組經過復審之后轉交給配置管理小組，有些則會直接從文檔的出處到達配置管理小組。當有文檔模板后需要書寫文檔的人員只剩下填空的工作，從某種意義上講，書寫文檔的速度會加快。系統(tǒng)性能指標報告； 外部文檔主要包括：質量監(jiān)督報告；類索引；構件成分說明；需求分析；文檔維護主要是配置管理小組的工作。對于一般性的錯誤，如操作不當?shù)纫鸬膯栴}，全部由維護小組執(zhí)行完成，但需要用戶測試確認上線。總之，一切測試應該符合用戶需求。測試活動要盡可能覆蓋整改項目過程，從最初的需求到部署階段，都應該制訂詳細的計劃并編制相應的文檔，如測試計劃、測試用例文檔、測試報告等。軟件測試的目的是根據(jù)用戶需求檢查系統(tǒng)是否符合項目合同與任務書規(guī)定的要求。針對上一階段提供詳細設計，程序員開始編碼并且調試程序，測試人員則根據(jù)設計進行測試用例的設計，設計出來的用例需要得到項目組成員認可由項目經理審核通過才能進入配置庫。最后交由配置管理員進行設計文檔的版本控制。公共類開發(fā)可以減少工作中的重復工作，降低開發(fā)成本。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關人員發(fā)布，再由配置管理員對其發(fā)布的文檔進行整理、歸類放入配置庫以供大家共享。變更實施完后，上線前還需要指定人員協(xié)助用戶一同測試并由用戶簽字后同意方可上線。 雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求變更請求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質量。 實際運作中，當質量保證小組發(fā)現(xiàn)計劃實施的差異后，報告項目經理，由項目經理組織負責對計劃進行周期性維護，對于已經變動的計劃由質量保證小組協(xié)助配置管理小組完成版本控制。常有人道，“計劃趕不上變化”，但“要跟上變化”。 項目進度是項目進行是否順利的最直觀表現(xiàn)。測試人員是否進行了較為徹底的和全面的測試；解決當前存在的和潛在的問題。 質量保證小組作為質量保證的實施小組，主要職責是保證軟件透明開發(fā)的主要環(huán)節(jié)。 測試人員根據(jù)詳細設計的文檔對軟件要實現(xiàn)的功能進行一一測試，保證軟件的執(zhí)行正確的實現(xiàn)設計要求，在此也只證明了軟件正確的反映了設計思想，但是否真正反映了用戶的需求仍需要進一步的功能性測試。 測試小組作為質量控制的主要手段，負責軟件的測試設計和執(zhí)行工作。完善各個部門發(fā)送需要存檔和進行版本控制的代碼、文檔（包括外來文件）和階段性成果；配置管理小組是保證項目開發(fā)完畢的同時，內部文檔和外部文檔都同時完成。因此，作為一個好的軟件項目過程，必須針對企業(yè)和項目的實際情況，確定軟件項目運作流程，定義軟件功能及相關性能，明確各階段的進入條件和退出條件，進行有效的過程控制與管理，在提高軟件開發(fā)的效率和項目的成功率的基礎上保證所開發(fā)軟件的質量Error! Reference source not found.。對于開發(fā)環(huán)節(jié)中的某一特性，例如，對缺陷嚴重程度進行跟蹤時，允許其出現(xiàn)級別較高的缺陷。帕累托法則也稱為80/20法則，它是一種統(tǒng)計規(guī)律。(8) 確定糾正行動。(4) 確定下一級主要原因。通過因果圖可以刺激思維和討論，以便對問題進行深入討論，尋找潛在的根源。(2) 性能測試：LoadRunner、SilkPerformer、Rational Performance Tester、QALoad。一般認為就是使用（自動化測試）工具來進行的測試叫自動化測試，一般不需要人干預。測試人員根據(jù)測試計劃不同階段和指定的模版，設計不同階段的測試用例并進行同行評審。測試計劃作為開展軟件測試的綱領性文檔，如同項目開發(fā)計劃對一個軟件開發(fā)一樣重要，其內容一般包括如下：l 測試計劃書的文件名及版本號；l 基本情況介紹（測試目的、背景、測試范圍及參考文獻等）；l 測試的具體目標（要測的是軟件的哪些部分）；l 具體執(zhí)行的測試類型；l 測試通過的判斷準則；l 測試用例；l 測試準備工作及測試結果的處理；l 測試工作中涉及的相關事項（測試工具、硬件，第三方軟件等）；l 部門責任分工；l 測試人力資源分配；l 缺陷管理流程。黑盒測試主要是功能測試。分為：語句測試；分支測試；路徑測試；目測。只是項目組共同評審或協(xié)定通過，對開發(fā)的產品進行定義和描述的文檔、資料、口頭約定（不建議養(yǎng)成口頭約定的習慣）等均可稱為產品說明書。是幫助識別開發(fā)完成（中間或最終的版本）的