【正文】 測試注釋（2）BUG處理信息處理者姓名處理時間處理步驟錯誤記錄的當前狀態(tài)軟件錯誤的狀態(tài)新信息（New）：測試中新報告的軟件BUG打開（Open）：被確認并分配給相關(guān)開發(fā)人員處理。測試工具采取兩種錄制模式：（1）環(huán)境判斷模式這種模式根據(jù)你選取的圖形用戶界面對象（如窗體、清單、按鈕等），把你對軟件的操作動作錄制下來，每一次你對被測軟件進行操作，測試腳本語言會記錄并描述你選取的對象和你的操作動作。同時，控制臺還可以通過服務器上開啟的遠程RPC服務，獲取相關(guān)的資源使用信息，最后還可以收集測試數(shù)據(jù)。它是一個分層質(zhì)量模型，有6個影響質(zhì)量的特性。GB/《軟件工程 產(chǎn)品評價》第6部分，評價模塊的文檔編制。GB/《軟件工程 產(chǎn)品質(zhì)量》第4部分，使用質(zhì)量度量。功能性功能性是指在當軟件在指定條下使用時，軟件產(chǎn)品滿足明確和隱含要求功能的能力。（1）可重復性：由同一評價者按同一評價規(guī)格說明對同一產(chǎn)品進行重復地評價，應產(chǎn)生同一種可接受的結(jié)果。組織和質(zhì)量體系請求者的職責評價者的職責評價需求確立的目的評價需求分析分析評價需求的活動由下列5個子活動組成：（1）請求者提出評價需求建議；（2）請求者說明評價覆蓋范圍；（3）評價者分析評價原因和描述評價需求來響應請求者；（4）評價者解釋評價的保密范圍和嚴格程度；（5）評價者同意評價需求；評價需求內(nèi)容（1）評價需求應包含對評價產(chǎn)品應用領(lǐng)域的描述，以及產(chǎn)品用途的描述。規(guī)定測試基線，對每個基線必須描述下列內(nèi)容：（1）每個基線的項（包括文檔、樣品和工具）；（2）與每個基線有關(guān)的評審、批準事項以及驗收標準。選擇合理高效的測試組織結(jié)構(gòu)方案的準則是：（1）提供軟件測試的快速決策能力；（2）利于合作，尤其是產(chǎn)品開發(fā)與測試開發(fā)之間的合作；（3）能夠獨立、規(guī)范、不帶偏見地運作并具有精干的人員配置；（4）有利于協(xié)調(diào)測試與質(zhì)量管理的關(guān)系；（5）有利于滿足軟件測試過程管理要求；（6）有利于為測試技術(shù)提供專有技術(shù)；（7）充分利用現(xiàn)有測試資源，特別是人；（8）對測試者的職業(yè)道德和事業(yè)產(chǎn)生積極的影響。測試準備成本控制測試準備成本控制的目標是使時間消耗總量、勞動力總量，尤其是準備工作所需的熟練勞動力總量最小化。投資回報率（ROI）=節(jié)約的成本i利潤i/測試投資=405000218000/68000*100%=275%缺陷探測率（DDP）=(100+150)/(100+150+50)*100%=%第二篇 測試技術(shù)第5章黑盒測試案例設計技術(shù)黑盒測試中運用等價類劃分、邊界值分析、因果圖法、判定表法、正交試驗法、功能圖法等測試用例設計方法的原理與實現(xiàn)，并從測試設計說明、測試用例說明、測試程序說明三個方面介紹如何編寫測試用例。每一類的代表性數(shù)據(jù)在測試中的作用等價于這一類中的其他值。（5）在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。因果圖設計方法因果圖法是從用自然語言書寫的程序規(guī)格說明的描述中找出因（輸入條件）和果（輸出或程序狀態(tài)的改變），通過因果圖轉(zhuǎn)換為判定表。條件項：列出針對它所列條件的取值，在所有可能情況下的真假值。（5）如果某一規(guī)則要執(zhí)行多個操作，這些操作的執(zhí)行順序無關(guān)緊要。包括：在表達式中不正確地使用了括號造成錯誤；數(shù)組下標越界造成錯誤；除數(shù)為零造成錯誤；對負數(shù)開平方，或?qū)Ζ星笳性斐慑e誤。Beizer指出了適合使用判定表設計測試用例的條件：（1）規(guī)格說明以判定表的形式給出，或很容易轉(zhuǎn)換成判定表。條件樁：列出了問題的所有條件。（6）如果程序中使用了一個內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應當選擇這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)邊界上的值作為測試用例。（1）在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，可以確立一個有效等價類和兩個無效等價類。等價類劃分是一種典型的黑盒測試方法，用這一方法設計測試用例完全不考慮程序的內(nèi)部結(jié)構(gòu)，只根據(jù)對程序的要求和說明，即需求規(guī)格說明書。缺陷探測率是衡量測試投資回報的一個重要指標?！疤俚臏y試是犯罪，而太多的測試是浪費。確定發(fā)現(xiàn)問題的處理方法。 此外，評價者還可以管理在評價者的承諾之外執(zhí)行的評價動作；（1）軟件部件的管理（2）評價數(shù)據(jù)管理（3）工具使用的管理（4）現(xiàn)場評價（5）特定評價技術(shù)的需求（6）評審和報告評價結(jié)論的目的評價報告的聯(lián)答評審評價數(shù)據(jù)和文檔的處置軟件測試過程的配置管理和軟件開發(fā)過程的配置管理是一樣的。（5）評價報告：執(zhí)行測量和分析的結(jié)果，以及能被重復和重新評價的必要信息。使用質(zhì)量是從用戶角度看待的質(zhì)量，其屬性分為4種：有效性、生產(chǎn)率、安全性和滿意度。外部質(zhì)量和內(nèi)部質(zhì)量的質(zhì)量模型軟件，其質(zhì)量屬性劃分為6種特性（功能性、可靠性、易用性、效率、維護性和可移植性），并進一步細分為一些子特性。該系列標準由以下4部分組成。GB/《軟件工程 產(chǎn)品評價》第2部分，策劃和管理。我國的軟件產(chǎn)品質(zhì)量評價標準GB/T 162601996。結(jié)果分析：每次測試結(jié)束，測試工具都會把測試情況顯示在測試結(jié)果報告中。若需要進行測試系統(tǒng)后臺或者內(nèi)部的性能特性，進而進行故障定位和性能調(diào)優(yōu)。只有正確、迅速、準確地處理這些錯誤，才能消除軟件錯誤，保證要發(fā)布的軟件符合需求設計的目標。軟件錯誤（software error）軟件缺陷（software defect）軟件故障（software fault）軟件失效（software failure）軟件失效機理可描述為：軟件錯誤232。軟件測試過程的任務與管理也要符合軟件Vamp。進行有效性測試。在做回歸測試時，也應該集中測試關(guān)鍵模塊的功能。1）一次性組裝方式它是一種非增殖式組裝方式，也叫做整體拼裝。為此，對模塊接口可能需要如下的測試項目： 調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形式參數(shù)在個數(shù)、屬性、順序上是否匹配； 所測模塊調(diào)用子模塊時，它輸入給子模塊的參數(shù)與子模塊中的形式參數(shù)在個數(shù)、屬性、順序上是否匹配；是否修改了只作輸入用的形式參數(shù)；輸出給標準函數(shù)的參數(shù)在個數(shù)、屬性、順序上是否正確；全局量的定義在各模塊中是否一致；限制是否通過形式參數(shù)來傳送。輸入和輸出的方式和格式應當盡可能方便用戶的使用。如下：主要評測內(nèi)容：可追溯性；接口；風險；實用性；技術(shù)清晰度；可維護性；質(zhì)量；各種選擇方案；限制；其他具體問題。文檔中的所有描述是否完整、清晰、準確地反映用戶要求； 與所有其他系統(tǒng)成份的重要接口是否都已經(jīng)描述； 被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠、確定； 所有圖表是否清楚，在不補充說明時能否理解；主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明； 軟件的行為和它必須處理的信息、必須完成的功能是否一致； 設計的約束條件或限制條件是否符合實際； 是否考慮了開發(fā)的技術(shù)風險； 是否考慮過軟件需求的其他方案； 是否考慮過將來可能會提出的軟件需求； 是否詳細制定了檢驗標準，它們能否對系統(tǒng)定義是否成功進行確認； 有沒有遺漏、重復或不一致的地方； 用戶是否審查了初步的用戶手冊或原型； 項目開發(fā)計劃中的估算是否受到了影響。（4）測試和開發(fā)結(jié)合在一起；前置測試將測試執(zhí)行和開發(fā)結(jié)合在一起，并在開發(fā)階段以編碼——測試——編碼——測試的方式來體現(xiàn)。216。 W模型W模型建立V模型的局限性在于沒有明確地說明早期的測試，不能體現(xiàn)“盡早地和不斷地進行軟件測試”的原則。 靜態(tài)測試它是指不運行程序，通過人工對程序和文檔進行分析與檢查； 靜態(tài)測試技術(shù)又稱靜態(tài)分析技術(shù)，靜態(tài)測試實際上是對軟件中的需求說明書、設計說明書、程序源代碼等進行非運行檢查，靜態(tài)測試包括：走查、符號執(zhí)行、需求確認等。驗證測試是在軟件開發(fā)環(huán)境下，由開發(fā)者檢測與證實軟件的實現(xiàn)是否滿足軟件設計說明或軟件需求說明的要求。單元測試又稱模塊測試，是針對程序模塊進行正確性檢驗的測試工作。測試過程按4個步驟進行，即單元測試、集成（組裝）測試、確認測試和系統(tǒng)測試。測試無法顯示軟件潛在的缺陷充分注意測試中的群集現(xiàn)象。應當把“盡早地和不斷地進行軟件測試”作為軟件測試者的座左銘。ISO14598中“軟件質(zhì)量”定義是：軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力。軟件評測師教程（第一版）筆記第一篇 理論篇第1章軟件測試概論早期的測試等同于“調(diào)試”。ISO9126定義的軟件質(zhì)量包括“內(nèi)部質(zhì)量”、“外部質(zhì)量”、“使用質(zhì)量”三部分。完全測試是不可能的，測試需要終止。程序員應避免檢查自己的程序。軟件測試分類按照開發(fā)階段劃分軟件測試可分為：單元測試、集成測試、系統(tǒng)測試、確認測試和驗收測試。216。主要是指在軟件開發(fā)完成以后，開發(fā)方對要提交的軟件進行全面的自我檢查與驗證，可以和軟件的“系統(tǒng)測試”一并進行。216。在V模型中增加軟件各開發(fā)階段應同步進行的測試，被演化為一種W模型，因為實際上開發(fā)是“V”，測試也是與此相并行的“V”。 H模型H模型建立它將測試活動獨立出來，形成一個完全獨立的流程，將測試準備活動和測試執(zhí)行活動清晰地體現(xiàn)出來。（5）讓驗收測試和技術(shù)測試保持相互獨立。（1）需求說明書評測編制良好的需求說明書8條原則。（1）設計出來的結(jié)構(gòu)應是分層結(jié)構(gòu)，從而建立軟件成分之間的控制；（2）設計出來的結(jié)構(gòu)應是分層結(jié)構(gòu)，從而建立軟件成分之間的控制；（3）設計應當既包含數(shù)據(jù)抽象，也包含過程抽象；（4）設計應當建立具有獨立功能特征的模塊；（5）設計應當建立能夠降低模塊與外部環(huán)境之間復雜連接的接口；（6）設計應當根據(jù)軟件需求分析獲取的信息，建立可驅(qū)動、可重復的方法。一定要避免因設計不當給用戶帶來的麻煩。2）局部數(shù)據(jù)結(jié)構(gòu)測試設計測試用例以檢查以下各種錯誤：不正確或不一致的數(shù)據(jù)類型說明；使用尚未賦值或尚未初始化的變量；錯誤的初始值或錯誤的缺省值；變量名拼寫錯或書寫錯；不一致的數(shù)據(jù)類型。使用這種方式，首先對每個模塊分別進行模塊測試，再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。集成測試的組織和實施。有效性測試是在模擬的環(huán)境下，運用黑盒測試的方法，驗證所測軟件是否滿足需求規(guī)格說明書列出的要求。V過程的有關(guān)規(guī)定。軟件缺陷232。在實際的軟件測試過程中，每個BUG都要經(jīng)過測試、確認、修復、驗證等的管理過程，這是軟件測試的重要環(huán)節(jié)。自動化測試的局限性定制型項目周期很短的項目業(yè)務規(guī)則復雜的對象人體感觀與易用性測試不穩(wěn)定的軟件涉及物理交互自動化測試工具分類自動化測試工具分以下幾類：負載壓力測試工具功能測試工具白盒測試工具網(wǎng)絡測試工具測試管理工具測試輔助工具自動化測試應用策略在測試過程中應用測試工具主要有以下幾個目的：提高測試質(zhì)量；減少測試過程中的重復勞動； 實現(xiàn)測試自動化，解決手工測試不能解決的問題。負載測試是為了證明在與產(chǎn)品（預期）規(guī)模等同的數(shù)據(jù)庫中處理給定的事務請求的容量下，系統(tǒng)功能與性能是否與需求規(guī)格說明中規(guī)定的，可接受的響應時間一致的測試過程。它是一個分層質(zhì)量模型，有6個影響質(zhì)量的特性。GB/《軟件工程 產(chǎn)品評價》第3部分，開發(fā)者用的過程。GB/《軟件工程 產(chǎn)品質(zhì)量》第1部分，質(zhì)量模型。軟件的每個質(zhì)量特性和子特性都有定義。第4章軟件測試過程與管理軟件的測試過程一般分成測試計劃、測試設計與開發(fā)、測試實施、測試評審與測試結(jié)論等階段。評價報告首先作為評審草案來發(fā)布，其最終版本將交給請求者。軟件測試配置管理包括4個最基本的活動：（1）配置項標識（2）配置項控制（變更控制）（3）配置狀態(tài)報告（4）配置審計標識測試樣品、標準、工具、文檔（包括測試用例）、報告等配置項的名稱和類型。配置管理是管理和調(diào)整變更（change）的關(guān)鍵，對于一個參與人員較多、變更較大的項目，它是至關(guān)重要的。”對風險測試得過少，會造成軟件的缺陷和系統(tǒng)的癱瘓；而對風險測試得過多，就會使本來沒有缺陷的系統(tǒng)進行沒有必要的測試，或者是對輕微缺陷的系統(tǒng)所花費的測試費用遠遠大于它們給系統(tǒng)造成的損失。假設發(fā)現(xiàn)的錯誤為300個，測試過程的估算如下：（1）單元測試階段，軟件開發(fā)人員發(fā)現(xiàn)及修改一個錯誤需要50元（2）建立獨立的測試進行集成和系統(tǒng)測試，開發(fā)人員修改后，測試人員再確認，一個錯誤需要300元（3）在產(chǎn)品發(fā)布后，由客戶發(fā)現(xiàn)，報告技術(shù)支持人員、相關(guān)開發(fā)人員修改，測試組再進行回歸測試，一個錯誤需要2000元。我們必須仔細分析和推敲說明書的各項需求，特別是功能需求。（2）在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，可以確立一個有效等價類和一個無效等價類。（7）分析規(guī)格說明，找出其他可能的邊界條件。通常認為列出的條件的次序無關(guān)緊要。（2）條件的排列順序不影響執(zhí)行哪些操作。接口分析接口一致性是程序的靜態(tài)錯誤分析和設計分析共同研究的題目。（4）當某一規(guī)則的條件已經(jīng)滿足，并確定要執(zhí)行的操作后，不必檢驗別的規(guī)則。這些操作的排列順序沒有約束。錯誤推測法的基本思想是列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試用例。（4）在規(guī)定了輸入數(shù)據(jù)的一組值（假定n個），并且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。等價類劃分的方法是把程序的輸入域分成若干部分，然后從每個部分中選取少數(shù)代表性數(shù)據(jù)作為測試用例?？傎|(zhì)量成本下降到218000元，手工測試總質(zhì)量成本節(jié)約了187000元，即為利潤。測試實施成本組成部分包括：測試準備成本、測試執(zhí)行成本和測試結(jié)束成