【正文】 量控制三大方面。1常見的軟件配置演化模型有線性演化模型和樹演化模型。3軟件缺陷打開/關(guān)閉圖表、根本原因圖表、軟件缺陷關(guān)閉周期表是常用的軟件缺陷跟蹤圖表。50、支持性質(zhì)量手段有模板和檢查表。6軟件質(zhì)量保證的目標(biāo)包括面向產(chǎn)品的軟件開發(fā)和面向過程的軟件維護兩大方面。8計算機輔助靜態(tài)分析利用 靜態(tài)分析工具對測試程序進行 特性分析。23．軟件測試一般經(jīng)過4個測試：單元測試集成測試確認(rèn)測試系統(tǒng)測試。10調(diào)試也稱糾錯，是在成功的測試之后才開始進行，其目的是確定錯誤的 原因和位置，并改正錯誤。12在單元測試中，測試一個模塊時，需要設(shè)計驅(qū)動模塊和樁模塊。我們經(jīng)常會碰到某些功能方面的問題被當(dāng)成缺陷來處理，這類問題可以以后有時間時考慮再處理。“缺陷一個連著一個”不是一個客觀規(guī)律，只是一個常見的現(xiàn)象。內(nèi)部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況,一般外部測試報告要滿足下面幾個要求：根據(jù)內(nèi)部測試報告進行編寫，一般可以摘錄；不可以向客戶報告嚴(yán)重缺陷，即使是已經(jīng)修改的缺陷，開發(fā)中的缺陷也沒有必要讓客戶知道；報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復(fù)的；報告上面的內(nèi)容盡量要真實可靠；整個測試報告要仔細(xì)審閱，力爭不給項目帶來負(fù)面作用，尤其是性能測試報告。③對程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。項目管理的問題：缺乏質(zhì)量文化，不重視質(zhì)量計劃，對質(zhì)量、資源、任務(wù)、成本等的平衡性把握不好，容易擠掉需求分析、評審、測試、等時間，遺留的缺陷會比較多。4． 單元測試一般以白盒測試法為主，測試的依據(jù)是模塊功能規(guī)格說明。10． 軟件測試按照開發(fā)階段劃分單元測試、集成測試、系統(tǒng)測試、確認(rèn)測試、驗收測試。1． 測試過程中會產(chǎn)生哪些基本文檔？（1）測試計劃（通常包括單元測試和集成測試）：確定測試范圍、方法和需要的資源（2）測試過程：詳細(xì)描述和每個測試方案有關(guān)的測試步驟和數(shù)據(jù)（包括測試數(shù)據(jù)及預(yù)期的結(jié)果）；（3）測試結(jié)果：把每次測試運行的結(jié)果歸入文檔，如果運行出錯，則應(yīng)產(chǎn)生 問題報告，并且必須通過調(diào)試解決所發(fā)現(xiàn)的問題。這樣做的具體目的有如下幾點：(1)可以在準(zhǔn)生產(chǎn)環(huán)境中運行新系統(tǒng)而又不冒風(fēng)險；(2)用戶能有一段熟悉新系統(tǒng)的時間；(3)可以驗證用戶指南和使用手冊之類的文檔；(4)能夠以準(zhǔn)生產(chǎn)模式對新系統(tǒng)進行全負(fù)荷測試，可以用測試結(jié)果驗證性能指標(biāo)。動態(tài)測試的兩個基本要素：被測試程序和測試數(shù)據(jù)（測試用例）。？根據(jù)程序的輸入特性，將程序的定義域劃分為有限個等價區(qū)段“等價類”，從等價類中選擇出的用例具有“代表性”，即測試某個等價類的代表值就等于對這一類其他值的測試?！?． 某報表處理系統(tǒng)要求用戶輸入處理報表的日期，日期限制在2003年1月至2008年12月，即系統(tǒng)只能對該段期間內(nèi)的報表進行處理，如日期不在此范圍內(nèi)，則顯示輸入錯誤信息。軟件測試的基本格式：軟件測試用例的基本要素包括測試用例編號、測試標(biāo)題、重要級別、測試輸入、操作步驟、預(yù)期結(jié)果。：性能測試—Loadrunner、Robot、Silk performer，功能測試—QTP、Winrunner、Robot、Silk test，其他測試—Xenu、AiRoboForm。6，團隊合作精神。分類：1白盒測試用例；2軟件各項功能的測試用例；3用戶界面測試用例；4軟件的各項非功能測試用例；5對軟件缺陷修正所確認(rèn)的測試用例。2，具有創(chuàng)新精神和超前意識。：配置測試環(huán)境是測試實施的一個重要階段，測試環(huán)境適合與否會嚴(yán)重影響測試結(jié)果的重要性和真實性。黑盒測試也稱之為功能測試和數(shù)據(jù)驅(qū)動測試。不可能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題1． 根據(jù)下面給出的規(guī)格說明，利用等價類劃分的方法，給出足夠的測試用例。d)因果圖：通過畫因果圖，在圖上標(biāo)明約束和限制，轉(zhuǎn)換成判定表，然后設(shè)計測試用例。靜態(tài)測試約可找出30～70%的邏輯設(shè)計錯誤。驗收測試的目的是驗證系統(tǒng)確實能夠滿足用戶的需要，在這個測試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。通常在編碼階段進行，必要的時候要制作驅(qū)動模塊和樁模塊。6． 系統(tǒng)測試時在集成測試完成后，確認(rèn)測試之前進行的測試。驗收測試主要就是用戶在拿到軟件的時候，在使用現(xiàn)場，會根據(jù)前邊所提到的需求，以及規(guī)格說明書來做相應(yīng)測試，以確定軟件達到符合效果的。語法錯誤：對于編譯性語言程序，編譯器可以發(fā)現(xiàn)這類問題；但對于解釋性語言程序，只能在測試運行時發(fā)現(xiàn)。測試不是在編碼完成后才開始介入，而是貫穿于整個軟件生命周期。做軟件產(chǎn)品通常是研發(fā)中心來開發(fā)，進度壓力要小些。實際上完全測試是不可能的。發(fā)生這種現(xiàn)象的主要原因如下：沒有足夠的時間資源。1用等價類劃分法設(shè)計測試用例時，如果被測程序的某個輸入條件規(guī)定了取值范圍，則可確定一個合理的等在和兩個不合理的等價類。10確認(rèn)測試在模擬環(huán)境下運用黑盒測試方法，由專門測試人員和用戶 參加的測試。9在測試程序時，根據(jù)經(jīng)驗或直覺推測程序中可能存在的各種錯誤，稱為 錯誤推測法。7動態(tài)測試通過 運行程序發(fā)現(xiàn)錯誤。6軟件更改的質(zhì)量保證工作需要每個更改的SCI的質(zhì)量保證和整個新軟件系統(tǒng)版本的質(zhì)量保證兩個級別的活動。4McCall模型產(chǎn)品修改緯度的質(zhì)量因素有可維護性、可測試性、靈活性。2從內(nèi)容和重點上我們可以把質(zhì)量管理標(biāo)準(zhǔn)劃分成和評估標(biāo)準(zhǔn)兩種類型。1依據(jù)合同評審的目標(biāo)對合同評審主題進行分類為建議草案評審主題和合同草案評審主題兩種類型。RMA可以劃分成三組類別 內(nèi)部風(fēng)險管理措施，分包風(fēng)險管理措施，顧客風(fēng)險管理措施支持性質(zhì)量手段有模板和檢查表。2軟件質(zhì)量保證的目標(biāo)包括面向產(chǎn)品的軟件開發(fā)和面向過程的軟件維護兩大方面。3為了考察測試用例的重要性，我們可以從有效性、可重用性、易組織性、可評估性、可管理性五方面理解。5McCall模型劃分了軟件運行、軟件轉(zhuǎn)移、軟件修改三個緯度的11個軟件質(zhì)量因素。70、軟件更改的質(zhì)量保證工作需要每個更改的SCI的質(zhì)量保證和整個新軟件系統(tǒng)版本的質(zhì)量保證兩個級別的活動。8實際的邏輯覆蓋測試中，一般以 條件組合覆蓋為主設(shè)計測試用例，然后再補充部分用例，以達到 路徑覆蓋測試標(biāo)準(zhǔn)。9集成測試指在單元測試基礎(chǔ)上，將所有模塊按照設(shè)計要求組裝成一個完整的系統(tǒng)進行的測試。11在單元測試時，需要為被測模塊設(shè)計驅(qū)動模塊與樁模塊。第二篇：軟件測試（推薦）一、簡答5*6’表面上看這體現(xiàn)了管理的效率和靈活性，但實際上也體現(xiàn)了管理者對測試的輕視。 測試要注意下面的事項：（1）用戶現(xiàn)場測試不可能測試全部功能，因此要測試核心功能。測試人員的主要工作是測試，質(zhì)量保證人員日常工作重要內(nèi)容是檢查與評審，測試工作也是測試保證人員的工作對象。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。⑦由于通信端口多、存取和加密手段的矛盾性等，會造成系統(tǒng)的安全性或適用性等問題。①繪制示意圖②闡述每個步驟是做什么 需求分析即首先要明確客戶需要的是什么，需要軟件作成什么樣子，需要有那幾項功能概要設(shè)計主要是架構(gòu)的實現(xiàn)，指搭建架構(gòu)、表述各模塊功能、模塊接口連接和數(shù)據(jù)傳遞的實現(xiàn)等項事務(wù)。白盒測試是根據(jù)程序的內(nèi)部邏輯來設(shè)計測試用例,黑盒測試是根據(jù)軟件的規(guī)格說明來設(shè)計測試用例。3． 動態(tài)測試 通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。2）.子系統(tǒng)測試子系統(tǒng)測試是把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。3）測試開發(fā)建立可重復(fù)使用的自動測試過程。驗證SRS中的性能需求，是否實現(xiàn)。(3)pareto原則：測試發(fā)現(xiàn)的錯誤中的80%很可能是由程序中20%的模塊造成的。若投入1元5角硬幣，按下“可樂”、“雪碧”或“紅茶”按鈕，相應(yīng)的飲料就送出來。② 開發(fā)的接口人員。5，設(shè)計用例時，應(yīng)該考慮各種情況。五、簡述集成測試的實施方案有哪些？答：集成測試的實施方案有很多種，如非增量式集成測試和增量式集成測試，三明治集成測試，核心集成測試，分層集成測試，基于使用的集成測試等；常用的是前兩種。自底向上增量是集成測試是從最底層的模塊開始，按結(jié)構(gòu)圖自下向上逐步進行測試工作。7，制定嚴(yán)格的測試計劃。④ bug 的嚴(yán)重程度?！崩玫葍r類劃分的方法，設(shè)計測試該軟件的全部測試用例。（5）測試用例應(yīng)由輸入數(shù)據(jù)和預(yù)期的輸出結(jié)果兩部分組成，并兼顧合理的輸入和不合理的輸入數(shù)據(jù)（6）窮舉測試是不可能的。因此是屬于性能測試范圍的。5）測試評估結(jié)合量化的測試覆蓋域及缺陷跟蹤報告，對于應(yīng)用軟件的質(zhì)量和開發(fā)團隊的工作進度及工作效率進行綜合評價。3）.系統(tǒng)測試系統(tǒng)測試是把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試。白盒測試是把測試對象看作一個打開的盒子