《《軟件測試技術》PPT課件.ppt》由會員分享，可在線閱讀，更多相關《《軟件測試技術》PPT課件.ppt（74頁珍藏版）》請在裝配圖網上搜索。

Module2 軟件測試技術 主要內容 軟件測試基本方法靜態(tài)分析白盒測試黑盒測試測試模式范圍測試說明書測試風險測試情景測試組合測試探索測試實際練習 什么是靜態(tài)分析 不實際運行程序 通過檢查和閱讀等手段來發(fā)現錯誤并評估代碼質量的軟件測試技術 作用通過對代碼標準及質量的監(jiān)控提高代碼可靠性盡可能早地通過對源代碼的檢查發(fā)現缺陷組織代碼審核定位易產生錯誤的模塊非常有效的質量保證手段越來越多地被采用 靜態(tài)分析的主要內容 檢查需求檢查設計檢查代碼 檢查需求 需求的標準完整性是否完整描述一個功能正確性是否正確反應客戶要求可行性必要性Goldplating 無二義性會引起歧義嗎可驗證性測試用例怎么寫 實施無關性 需求規(guī)格說明的標準完整性是否包含所有需求FURPS一致性相互矛盾重復 需求檢查練習 例1產品必須在固定的時間間隔內提供狀態(tài)信息 并且每次時間間隔不得小于60秒 完整嗎 清晰嗎 例2分析程序應該能生成HTML標記錯誤的報告 從而使HTML初學者可以用它來快速排錯 是否有歧義 可驗證嗎 例3如果可能的話 應當根據系統(tǒng)貨物編號列表 在線確認輸入的貨物編號 如果可能的話 是什么意思 需求檢查練習 例4產品不應該提供將帶來災難性后果的查找和替換選擇 真正的需求是什么 例5系統(tǒng)對標準XYZ1 4 1的支持是可選的 有歧義嗎 例6當用戶選擇 緊湊內存 選項時 程序通過Huffman解析矩陣方法將郵件列表數據壓縮到相應的大小 可測嗎 代碼無關嗎 規(guī)格說明用語清單 絕對的肯定總是 每一種 所有 沒有 從不注意隱含的假設當然 因此 顯然 必然模棱兩可的詞某些 有時 常常 通常 經常 太多 幾乎不可測的描述良好 迅速 廉價 高效 穩(wěn)定隱藏的需求已處理 已拒絕 已忽略 已消除缺少的分支如果 那么 沒有 否則 分支 檢查設計 在編碼開始前進行檢查功能設計說明 消除歧義功能的用意 總體位置輸入 輸出可能的錯誤 例外接口定義交互細節(jié)實施建議 檢查代碼 通過檢查代碼發(fā)現模塊中的錯誤 通過代碼檢查能夠發(fā)現大部分的錯誤 檢查代碼 研究分析代碼而不用實際執(zhí)行包括可執(zhí)行的代碼和非執(zhí)行的代碼提供的信息度量標準容易產生錯誤的代碼代碼規(guī)則的執(zhí)行流圖和調用圖的分析 80 的問題是由于20 的代碼引起的 度量元 復雜度度量McCabeHalstead嵌套級別 最大 平均 規(guī)格度量行數語句數注釋數聲明數 代碼審核內容 分析容易產生錯誤的代碼 控制流分析非結構化的代碼死代碼數據流分析未定義的數據的使用未使用的數據信息流分析斷言分析 代碼審核內容 流圖和調用關系圖作為理解代碼的幫助作為審核符合設計的幫助作為測試設計的幫助作為調試的幫助代碼規(guī)則的執(zhí)行針對不同語言的特征格式和形式命名規(guī)范度量標準的強制 靜態(tài)分析方法 走查 Walkthrough審查 Inspection自動化工具 走查 Walkthrough 開發(fā)組內部進行的采用講解 討論和模擬運行的方式查找錯誤的活動限時 避免跑題參加人員經驗豐富的開發(fā)人員和本模塊相關的開發(fā)人員本項目組的新人由本模塊的開發(fā)者進行講解 回答問題并記錄不要現場修改檢查要點邏輯錯誤代碼標準 規(guī)范 風格 審查 Inspection 開發(fā)組 測試組和相關人員 QA 產品經理等 聯合進行 采用講解 提問并使用Checklist方式進行的查找錯誤的活動 以會議的形式 制定目標 流程 規(guī)則和結果報告 相關資料要在會議前下發(fā)并閱讀 參加人員經驗豐富的開發(fā)人員和本模塊相關的開發(fā)人員測試組和相關人員 審查 Inspection 由另外一名開發(fā)者進行講解 其他開發(fā)者主要按照Checklist進行提問并填表 本模塊開發(fā)者回答問題并記錄不要現場修改檢查要點設計需求代碼標準 規(guī)范 風格文檔的完整性和一致性 自動化工具 基于編碼規(guī)則LogiscopeLDRANuMega的CodeReview基于質量度量LogiscopeMcCabeLDRA 如何使靜態(tài)分析更有效 必須引入 別人 的眼睛根據團隊及項目的實際情況 設計合理的實施辦法有準備地進行應該有包含所有關注要點的Checklist把握會議時間每次以2小時為限可以進行多次 白盒測試 把測試對象看做一個透明的盒子利用程序內部的邏輯結構及有關信息 設計或選擇測試用例 對程序所有邏輯路徑進行測試通過在不同點檢查程序的狀態(tài) 確定實際的狀態(tài)是否與預期的狀態(tài)一致 白盒測試目標 盡可能高的覆蓋率對程序模塊的所有獨立的執(zhí)行路徑至少測試一次對所有的邏輯判定 取 真 與取 假 的兩種情況都至少測試一次在循環(huán)的邊界和運行界限內執(zhí)行循環(huán)體測試內部數據結構的有效性執(zhí)行效率 邏輯覆蓋 以程序內部的邏輯結構為基礎的設計測試用例的技術主要包含以下幾種情況語句覆蓋判定覆蓋條件覆蓋路徑覆蓋 邏輯覆蓋 語句覆蓋設計若干個測試用例 使得每一可執(zhí)行語句至少執(zhí)行一次判定覆蓋設計若干個測試用例 使得程序中每個判斷的取真分支和取假分支至少經歷一次判定覆蓋又稱為分支覆蓋條件覆蓋設計若干個測試用例 使得程序中每個判斷的每個條件的可能取值至少執(zhí)行一次路徑覆蓋設計足夠的測試用例 覆蓋程序中所有可能的路徑 黑盒測試 把測試對象看做一個黑盒子不考慮程序內部的邏輯結構和內部特性只依據程序的需求規(guī)格說明書檢查程序的功能是否符合它的功能說明 黑盒測試 在程序接口上進行測試主要是為了發(fā)現以下錯誤是否有不正確或遺漏了的功能 在接口上 輸入能否正確地接受 能否輸出正確的結果 是否有數據結構錯誤或外部信息 例如數據文件 訪問錯誤 性能上是否能夠滿足要求 是否有初始化或終止性錯誤 黑盒測試 在過去的測試中 我們常從開發(fā)者的視角出發(fā)分析代碼和規(guī)格說明書 規(guī)格說明書僅能給我們提供一部分風險類型 我們必須在更廣的范圍內進行測試 不同領域的專家能夠看到不同的使系統(tǒng)產生缺陷的機會 并設計出能夠引發(fā)這些缺陷的測試用例 跳出框框進行思考和設計 是黑盒測試的精髓 黑盒測試模式 模式與技術 測試技術是進行測試的方法 測試模式指用于指導設計測試的思路 一種測試模式可能會用到一種或多種技術 設計任何測試需要包含五個方面的內容 測試什么 試圖發(fā)現什么問題 如何判斷測試通過或失敗 怎么進行測試 誰來執(zhí)行測試 測試模式 范圍測試規(guī)格說明測試風險測試情景測試探索測試組合測試 模式 范圍測試 采用 抽樣 的策略 從眾多的可能情況中抽取合理的典型用例常見辦法等價類劃分將輸入劃分成若干等價組 從每一類中取一個代表值作為整個組的代表 如果一個測試發(fā)現的缺陷 也能被另一個測試發(fā)現 則兩個測試等價 邊界值測試邊界值是一個等價類向另一個等價類過度的點 程序在邊界更容易出錯 所以邊界值和邊界附近的值是最佳的測試點 范圍測試 優(yōu)點可以通過較少的用例檢測出最可能發(fā)生的錯誤很直觀的方法 易于普及弱點漏掉不位于邊界或典型值的錯誤邊界不易確定 范圍測試典型案例 三角型問題輸入 a b c 分別為三角形的三個邊長值輸出 該三角形為等邊 等腰 或不等邊如何設計測試用例 選擇什么樣的輸入值 模糊邊界問題 理論上說 等價類劃分的任務是將輸入分類成相互獨立并排斥的范圍 3D動畫游戲對顯卡的要求處理速度畫面效果兼容性必須測試游戲程序可支持的顯卡 模糊邊界問題 續(xù) 如何從數目眾多的顯卡中選出典型的測試對象 分類的思路市場占有率時間范圍品牌 驅動工業(yè)標準 芯片支持的操作系統(tǒng) 劃分等價類 設備兼容性測試顯示了多維空間無法明確劃分的情況 范圍測試成功的關鍵是記住 分區(qū)只是一種抽樣策略 它的目標是從大量潛在的測試中 選出最為合理并有價值的幾個代表 好的抽樣策略依賴于我們對具體領域的了解 而不僅僅是說明書 如果你知道多種使程序出錯的方法 那么對每一種錯誤 尋找最有可能使錯誤產生的設備 型號 版本 劃分等價類 客戶的問題 等價類方法對那些要求支持所有OEM系統(tǒng) 所有聲卡和顯卡 所有操作系統(tǒng) 及所有技術 例如DirectX3和5 的人非常有用 那么測試人員怎樣才能保證他的等價類表可以提供很好的覆蓋率 令人失望但真實的回答 即使分析和執(zhí)行的過程非常好 我們也很可能錯過一個可能造成缺陷的設備或驅動 或它們的組合 模式 規(guī)格說明測試 檢查產品滿足所有規(guī)格 需求文檔中的每一條陳述 檢查用戶手冊 安裝步驟 操作范例 優(yōu)點徹底分析每個被測功能項避免向客戶傳遞虛假或誤導信息 減少支持成本 客戶申告弱點未考慮交互影響任何沒有列入規(guī)格說明 和處理不當的問題 沒有規(guī)格說明怎么辦 所有存在的文檔內部版本的軟件變更備忘錄用戶手冊草稿 或舊版本 有關產品的文章公布的樣式指南或UI標準第三方產品兼容性測試系列公布的規(guī)范內部備忘錄 項目經理給工程師的功能描述 采訪參與上一個版本開發(fā)的人員查看舊版本的客戶電話記錄 查看現場發(fā)現的缺陷易用性測試結果Beta測試結果 沒有規(guī)格說明怎么辦 市場演示 產品概念推銷缺陷報告及回復工程師對產品的審核會個人采訪開發(fā)負責人技術寫作人員客戶服務領域專家項目經理察看header文件 源代碼 數據庫表定義原型 實驗室有關原型的記錄 模式 風險測試 從可能發(fā)生的問題 風險 出發(fā) 設計測試 先找最大的缺陷 風險測試實例失敗模式和影響分析從預報的缺陷清單中抽取測試用例壓力測試 安全性測試測試預期的或擔心的錯誤 風險測試 優(yōu)點測試作用大直觀的測試弱點沒有識別或想像到的風險 風險測試 主要任務識別風險因素 系統(tǒng)發(fā)生故障的情形 對每一種風險因素 設計有足夠能力對付它的測試評估風險測試的覆蓋率 查找測試工作的漏洞評估測試結果和發(fā)現的缺陷 判斷這些測試所針對的風險是什么 考慮是否有更有效的測試方法 哪里有風險 質量屬性能力可靠性易用性性能易安裝性兼容性可支持性可測試性可移植性可維護性 哪里有風險 從公布的缺陷統(tǒng)計和缺陷分類中 尋找你感興趣的缺陷 從清單中找出一個缺陷分析你的軟件是否會出現這個缺陷如果從理論上分析被測系統(tǒng)可能存在這個缺陷 思考如何把它找出來思考這個缺陷存在的可能性有多大 及它的嚴重性針對這類缺陷設計一個或多個測試公布的缺陷信息往往是過時的 且與你的被測系統(tǒng)相差很大 應逐步積累并建立自己的缺陷模式 哪里有風險 需求 不完整 不正確 不清楚新東西 新功能可能出錯新技術 新的概念可能引發(fā)新錯誤學習曲線 由于無知或習慣而造成的錯誤修改 變更可能會破壞舊的代碼倉促的工作 經費和時間不足造成低質量工作疲勞的程序員 長時間的持續(xù)工作造成低效和錯誤 模式 情景測試 模擬真實使用情景的測試情景測試實例依照商業(yè)規(guī)范 客戶數據 或競爭對手的結果 對產品進行評估測試生命周期測試特點很現實 來自真實用戶或競爭對手的情形 測試通過或失敗的判定很明確測試覆蓋多個特征或功能每個測試都關系到某些涉眾 stakeholder 的利益 情景測試 優(yōu)點復雜 真實的事件 可以處理那些不易模擬的情形 能暴露隨時間發(fā)展而發(fā)生的問題弱點單個功能失敗可以使測試效率降低必須仔細考慮測試的覆蓋率 構造情景的方法 目標驅動 某人想得到X 他怎么能得到X 序列驅動 某人 或系統(tǒng) 通常按照某個順序完成任務X 完成X所要經歷的常見順序是什么 交易驅動 我們想完成一樁交易 如開銀行帳戶或發(fā)送信息 完成這個交易的步驟 數據 輸出和顯示是什么 從競爭對手的產品中獲取思路 文檔 廣告 幫助等 所有關于如何最好或最新穎地使用產品的途徑 我們的產品如何完成這些事情 構造情景的方法 競爭對手的輸出 嗨 看看他們生成的這些漂亮的文件 或者 瞧他們能夠把語法錯誤的網頁顯示出來 咱們的產品能嗎 客戶的表格 這兒有幾種客戶在業(yè)務中使用的表格 我們的程序能處理 讀 填寫 顯示 確認 它們嗎 用例分析中提到的情景XP開發(fā)過程中的客戶故事 電視連續(xù)劇法 基于實際生活經驗構造情景 即用戶 客戶的經驗 夸大其中的每一個方面 例如 對每一個變量 輸入一個極端的值例如 如果一個情景包含一個重復的環(huán)節(jié) 那就重復很多很多次將測試用例所處的環(huán)境設置得很糟糕 減少內存 減少硬盤空間 網絡故障 打印機分辯率低 視頻分辨率低 等等 不要忘了所有可能發(fā)生問題的情形 將所有元素包含在一個 真實 的故事中 模式 組合測試 系統(tǒng)化地對測試變量進行合理組合為使某些缺陷發(fā)生 或重現 你必須有意識地控制兩個或多個變量的值 將數目眾多的組合減少到合理的程度組合測試實例組合多個變量的邊界值組合多個測試 因果圖 測試優(yōu)點可以用很少的測試達到很高的測試覆蓋率弱點可信度 組合測試實例 一個汽車保險公司的保險購買系統(tǒng)保險的檔次分為 1類 高風險 2類 中等風險 3類 低風險 系統(tǒng)根據用戶的年齡及駕齡 判斷應給予哪一類的保險 組合測試實例 保險公司政策年齡 18 駕齡不計 拒絕服務18 年齡 22 且駕齡 1 1類18 年齡 22 且1 駕齡 2類22 年齡 55 且駕齡 1 1類22 年齡 55 且1 駕齡 3 2類22 年齡 55 且3 駕齡 3類55 年齡 75 且駕齡 1 1類55 年齡 75 且1 駕齡 2類75 年齡 駕齡不計 拒絕服務 組合測試實例 組合表 模式 探索測試 測試文檔缺少或不足的軟件時 測試人員必須在測試的過程中學習產品 及測試用例 策略可能發(fā)現的缺陷 邊學邊計劃 邊測試探索測試實例對整個產品進行熟練的探索測試游擊式測試 對某個方面進行一段苛刻的測試 緊急測試第三方構件測試故障排除 發(fā)現缺陷后的補充測試 探索測試 在同一時間段里 了解產品了解市場了解導致產品失敗的途徑了解產品弱點學習如何測試產品測試產品報告問題要求修復在對產品已有了解的基礎上 設計新測試 探索測試 優(yōu)點關注用戶 關注風險利用測試者的能力應變能力強可以避免重復的分析和測試高缺陷發(fā)現率弱點知道的越少 錯過的缺陷越多受測試者弱點的限制 可通過好的協(xié)調管理減輕對個人能力要求很高 沒有監(jiān)督的初期測試人員不能很好完成任務 需要注意的問題 適應程度會影響發(fā)現問題的可能缺乏足夠信息會阻礙探索昂貴或困難的系統(tǒng)設置可能增加探索的耗費探索的反饋環(huán)節(jié)可能會比較慢問題可能會重復出現如果沒有完善的測試用例和過程 MTBF MeanTimeBetweenFailure 可能較低 探索的風格 經驗豐富 老練的探索者形成自己特有的風格 通過觀察這些經驗豐富的探索者 可以發(fā)現非常不同的風格 配對測試 PairedTesting 與XP開發(fā)模式中的PairedProgramming類似兩個測試人員工作結伴完成測試工作自愿結合負責某項測試任務的人 征召一個或多個同伴 每次一人 輔助自己的工作一個測試人員負責操作 另一人負責提供思路 意見 做記錄 詢問問題 找參考資料 等 探索測試模式的推薦方法 配對測試過程 從項目概要出發(fā) 選擇一個需要化一天或更少時間完成的任務略述將要進行的一期測試活動測試什么用什么工具使用什么測試方法可能有哪些風險關注什么樣的缺陷檢查什么文檔期望的結果是什么 每期測試活動一般持續(xù)60 90分鐘 配對測試的好處 有利于開發(fā)思路 產生建議的活動啟發(fā)式 開放式 多維的迫使測試人員解釋的思路 或對別人的建議做出反應交流的過程能夠促使更多的想法產生鼓勵創(chuàng)造性思維有助于獲得更多深入的信息有助于讓一個測試人員集中精力 進行持續(xù)的測試 非操作的測試人員可以 收集和記錄思路和零星的想法在第二臺機器上再現某個事件獲取執(zhí)行測試所需要的資源 查手冊 工具 打電話 找開發(fā)人員 等等 配對測試的好處 提供缺陷報告的質量重現的可能更大所有報告的內容都有第二個人審閱對每個設計問題進行合理性檢查有效的培訓方式對新手極有效的培訓不斷從別人那里學習新知識對經驗豐富的測試人員快速掌握新領域很有幫助還有一些技術上的益處可以在兩臺機器上進行同樣的測試人工的負載測試易于完成一些需要多角色交互的測試 一些建議 應允許初級測試人員執(zhí)行操作和發(fā)表看法 而不只是做一些雜物 責任應當明確 配對測試組中的一人應對任務的完成付責任 有些內向的人可能需要一些獨立思考和工作時間 以準備團隊的合作 有些人有很強的思維主導性 不愿意接受別人的意見 需要接受一定的培訓 測試模式小結 測試模式只是輔助測試人員構思測試的框架 并不局限于列舉的這些 模式相互可以重疊 例如你可以采用 基于規(guī)范說明的組合測試基于風險的情景測試探索式的范圍測試 最重要的是思考的方式 而不是教條 你可以總結自己的模式 并不斷提高 黑盒測試技術練習 BroadbandGateway 互聯網 服務器 ISPRouter 用戶電腦 被測系統(tǒng) 規(guī)格說明及相關信息 具有4個10 100Base TEthernet端口 可與PC網卡相連LAN側支持DHCP協(xié)議 可給PC分配動態(tài)IPWAN側通過一個寬帶口與ISP路由器相連 最高可支持雙方向速率1 5MbpsWAN側支持NetworkAddressTranslation NAT 協(xié)議有一個電源開關Router啟動后 自動與ISPRouter取得連接 獲得WAN側IP地址 默認網關地址 及DNS 用戶電腦可同時通過該Router訪問互聯網 進行上傳及下載前面板有三個指示燈 分別顯示電源開啟 ISP連接 網絡數據活動 WAN側連接 規(guī)格說明及相關信息 需要在一臺機器上安裝管理軟件 并通過Ethernet連接在Router上設置以下參數 LANIP地址范圍 默認為 192 168 0 1 192 168 0 255Router的LAN端IP地址 默認為 192 168 0 1管理員名稱和密碼 默認為 admin 1234可以啟動防火墻功能 進一步進行設置 略 用戶可通過管理軟件查看網絡使用情況LAN側IP分配WAN側IP及DNS信息與ISP連接的實際帶寬 分組練習 分別按照下面模式設計測試用例規(guī)范說明模式根據前面的說明 及你對Router的了解 分析被測系統(tǒng)可能具備的功能對每個功能 設計可能發(fā)現缺陷的測試用例風險模式列出被測系統(tǒng)可能出現的問題 風險 對每種可能的問題 設計相應的測試用例情景模式構想被測系統(tǒng)可能經歷的情景 包括每一種情景中可能出現的 意外 設計一組情景的測試用例 測試練習分析 對每個測試用例 分析 可能發(fā)現的問題是否有其它的方法發(fā)現同樣問題 哪種更有效匯總幾種模式所產生出的測試 分析 各模式的長短處相互補充能力 回顧 軟件測試技術 靜態(tài)測試 動態(tài)測試 代碼走查 代碼審查 代碼評審 黑盒測試 白盒測試 規(guī)范說明測試 情景測試 探索測試 語句覆蓋 分支覆蓋 路徑覆蓋 范圍測試 風險測試 EndofModule2