processes測試過程-免費閱讀
【正文】 8. 輸出 測試計劃 測試案例 測試結(jié)果表格 測試報告 測試代碼 缺陷數(shù)據(jù)庫中的缺陷日志 /追蹤 /關(guān)閉 在單元測試中僅需要出具測試報告 9. 方法學 這部分的目標是用來提供按不同技術(shù)分類的多種項目的進程 /工具的觀察。 ? 在編碼階段中識別的問題需文檔化和追蹤至結(jié)束。這可能會導致源碼或設計文檔的修改。 測試用例將在此后生命周期內(nèi)的每次迭代過程中改進。這是通過生成包含測試需求和測試策略的測試計劃來完成的。從用戶視角的接收測試收益，那樣它不可能徹底地測試在產(chǎn)品操作中出現(xiàn)的例外條件，如系統(tǒng)失敗，時間問題等。在沿著程序結(jié)構(gòu)上升的同時，簇被不斷的增加。 單元測試采用走查的方式進行 ,項目經(jīng)理在走查完畢后出具單元測試報告 。 執(zhí)行測試案例并記錄測試結(jié)果。如需要應該執(zhí)行相應的培訓。應該由和客戶簽字。 集成測試所關(guān)心的集聚行為通常體現(xiàn)在部件之間的界面上。 ? 核實所有需求是否已經(jīng)正確實施。 ? 確定缺陷并確保在部署軟件之前 將缺陷解決。集成測試被視為設計的測試。 2 2. 入口準則 1) 單元測試入口 ： 代碼已編寫并編譯通過。 應通過比較實際的結(jié)果和接受標準確認接受測試案例的結(jié) 果。 在測試過程中，除錯并修復任何問題后 重新運行測試案例直到退出標準令人滿意。 2) 集成測試 : 集成測試是將系統(tǒng)部件整合在一起并且測試結(jié)果是否符合需求的進程。 ? 合二為一：總的來說，傾向于綜合使用自底向上和自頂向下的測試方法。 我們經(jīng)常區(qū)別兩種接收測試： ? Alpha測試 ： 由在研發(fā)者場地的客戶在研發(fā)者的幫助和監(jiān)督下做?？梢灾贫ㄒ粋€單獨的測試計劃，用于描述所有要實施和執(zhí)行的不同測試類型，也可 以為每種測試類型制定一個測試計劃。 測試的執(zhí)行 入口見 2 入口準則 執(zhí)行測試時應遵循以下步驟： ? 設置測試環(huán)境，確保所需的全部構(gòu)件（硬件、軟件、工具、數(shù)據(jù)等）都已實施并處于測試環(huán)境中。 測試報告 入口條件 :所有缺陷已關(guān)閉 由項目經(jīng)理負責 測試結(jié)果應該在每個測試完成的時候生成。 ? 滿足或超出期望的覆蓋標準（可選） 集成測試的退出準則應該由單個項目自行定義。 檢查結(jié)果和方法學有文檔記錄在軟件測試文檔的技術(shù)分類中。 ? 接收測試的目的，如通過 % ? 由客戶或項目組結(jié)束的接收測試報告。 建議的退出標準： ? 所有單元測試成功執(zhí)行。 缺陷數(shù)據(jù)應該在缺陷跟蹤工具中記錄并跟蹤到其關(guān)閉。 ⑶ 預期結(jié)果 執(zhí)行該測試用例完畢后得到的狀態(tài)或數(shù)據(jù)。 測試計劃 測試計劃入口條件 : 需求規(guī)格說明書入基線 ,開發(fā)計劃完畢 測試計劃由項目經(jīng)理或系統(tǒng)分析員制訂 . 確定和描述要實施和執(zhí)行的測試。從用戶的角度看，這意味著每個用戶導向的功能應被完全地測試。 4 ? 自底向上的綜合：這里低級別的模塊會被捆綁入簇（構(gòu)建物）來運行具體的軟件子功能，并且開發(fā)測試簇的驅(qū)動程序。 單元測試為了發(fā)現(xiàn)如下缺陷： ? 模塊邊界缺陷 ? 不恰當或不一致的數(shù)據(jù)輸入 ? 不正確的變量名 ? 錯誤的開始或默認值 單元測試對于所有的項目是強制性的 。 系統(tǒng)分析人員 制訂測試用例 3 測試人員 參與測試案例發(fā)展。 3. 責任 客戶 ( 在驗收測試階段 ) 很好地解釋了正在執(zhí)行的產(chǎn)品 /
公司管理相關(guān)推薦
鄂ICP備17016276號-1