1、關(guān)志勇 20090316,高效測試案例設計,前言 前半部 測試用例設計5板斧 第一板斧需求細分 第二板斧產(chǎn)品實現(xiàn)邏輯 第三板斧產(chǎn)品應用場景 第四板斧測試角度 第五板斧產(chǎn)品實現(xiàn)技術(shù) 設計手段 測試列表設計思想及應用 技術(shù)理解文檔模板思想及應用 后半部 完善補充設計測試案例,高效測試案例設計_大綱,本次培訓的目的：介紹設計測試案例的思路 本次培訓介紹的設計測試案例的思路基于黑盒測試方法實現(xiàn) 不管黑貓白貓，逮到耗子是好貓，本次培訓介紹的設計測試案例思路不是否定現(xiàn)有黑盒測試方法，其中的思路也借鑒了白盒測試的一些方法 本次培訓介紹的設計測試案例的思路在網(wǎng)絡通信產(chǎn)品、網(wǎng)絡安全產(chǎn)品、應用客戶端產(chǎn)品、網(wǎng)站產(chǎn)品

2、應用,高效測試案例設計_前言,功能需求逐級細分最終形成功能點 測試人員最初依據(jù)需求文檔編寫測試case，不同的公司功能需求文檔描述細程度不一樣，功能從層次劃分的角度來看存在大小之分，可以采用樹形分層的設計思路，層層剝離，最終形成不能往下細分、沒有歧義的功能點,高效測試案例設計_第一板斧,高效測試案例設計_第一板斧_舉例,層次太多說明模塊過大，這個問題在講測試列表的時候會列舉解決方案,功能點的定義：影響功能點的預期結(jié)果只有一個因素/條件 ，如果存在多個因素/條件并會導致不同的結(jié)果 ，這個功能還不是功能點，需要繼續(xù)往下細分 功能點分的很細有必要嗎？從測試覆蓋度來說是越細越好，但是很多情況下會根據(jù)項

3、目的時間資源、人力資源來綜合分析，具體問題具體分析,高效測試案例設計_第一板斧_faq,知己知彼方能百戰(zhàn)不殆！ 需求文檔的內(nèi)容是黑盒層面的內(nèi)容，當我們完全站在黑盒外面設計測試案例，相對產(chǎn)品而然測試案例的覆蓋度和精準度不好評估，如果我們能掌握產(chǎn)品黑盒內(nèi)部的邏輯結(jié)構(gòu)，再用黑盒的測試手法執(zhí)行case去覆蓋產(chǎn)品的功能，相對于完全依據(jù)需求來設計的case來說多了一層保證,高效測試案例設計_第二板斧,在介紹流程圖分析法之前先拋出幾個問題： 開發(fā)需要為測試提供什么支持幫助，概要設計文檔、詳細設計文檔是否應該提供給測試？ 這些文檔對測試工作有作用嗎？ 測試工程師從這些文檔吸取什么？,高效測試案例設計_第二板斧

4、,高效測試案例設計_第二板斧邏輯流程圖的模型舉例,單一交互業(yè)務流模型,1,2,3,4,5,6,1,2,3,4,高效測試案例設計_第二板斧,多業(yè)務交互流模型,1,2,3,1,2,3,1,2,3,1,2,3,高效測試案例設計_第二板斧,使用自然語言把概要設計、詳細設計當中的內(nèi)容用業(yè)務流/功能描述的形式展現(xiàn)， 表現(xiàn)形式不局限剛才列舉的幾種模型 概要設計和詳細設計會有很多計算機專業(yè)術(shù)語，在設計邏輯流程圖時需要 把這些計算機術(shù)語（如變量名、函數(shù)名、類名、對象名）翻譯后（轉(zhuǎn)為動作名稱、功能名稱、業(yè)務名、數(shù)據(jù)流名稱等）用自然語言表達出來,高效測試案例設計_第二板斧,FAQ：1、看不懂概要設計和詳細設計怎么辦

5、： 和開發(fā)溝通，理解后及時寫成邏輯流程圖 2、所有的邏輯流程圖都需要讓相對應的開發(fā)人員審核，如果有錯誤及時修正 3、當功能實現(xiàn)異常復雜，可以根據(jù)實際情況把一個復雜的實現(xiàn)邏輯分解成幾個流程圖如下圖：,高效測試案例設計_第二板斧,續(xù)上,高效測試案例設計_第二板斧,FAQ： 存在復雜調(diào)用關(guān)系的模塊間的流程圖可以單獨使用流程圖描述模塊之間復雜的調(diào)用關(guān)系，忽略模塊內(nèi)部的處理流程，按照流程圖設計測試case去覆蓋模塊間的調(diào)用關(guān)系 邏輯流程圖每一鏈接都必須加上唯一的標號標記（英文、數(shù)字等都可以） 邏輯流程圖后續(xù)需要用文字對整個邏輯流程圖進行描述解釋，便于理解,高效測試案例設計_第二板斧,高效測試案例設計_第

6、二板斧,用邏輯流程圖設計測試case： 整體角度：把邏輯流程圖看成一顆樹，把根節(jié)點和頁節(jié)點的路徑鏈接起來設計黑盒測試case去覆蓋對應的路徑 拆分角度：每一段路徑代表著開發(fā)人員的設計實現(xiàn)，測試人員要從功能應用的角度分析這段路徑可能發(fā)生的各種情況分析，例如存在不同的業(yè)務流經(jīng)過，當前設計是否能正確處理； 邏輯流程圖的描述文字當中以段為單位注明用途（如轉(zhuǎn)化為case；加深產(chǎn)品理解；用在定位問題等； ）,在設計邏輯流程圖時，需要定義所負責模塊的重要程度級別和模塊內(nèi)部路徑的重要程度級別(比方從出現(xiàn)故障的影響程度大小和使用的頻繁程度判斷)，當項目時間緊張或者人力資源不足時就可以根據(jù)這些情況選取最重要或者最

7、適合的case去測試 邏輯流程圖體現(xiàn)著開發(fā)人員的設計實現(xiàn)思路，通過邏輯流程圖設計case的主要思想是用黑盒的測試方法把開發(fā)的設計思路覆蓋，保證產(chǎn)品的設計可以在真實的環(huán)境當中得到驗證,高效測試案例設計_第二板斧,從產(chǎn)品/功能的應用場景去設計case 相對開發(fā)人員而言測試人員就是開發(fā)人員所開發(fā)產(chǎn)品/功能的用戶；在公司，測試人員就代表用戶，測試人員的思維要貼近用戶，要站在用戶的立場上去檢驗產(chǎn)品 應用場景是黑盒測試相對白盒測試的一大優(yōu)勢是真實應用和模擬應用（如樁）的區(qū)別,高效測試案例設計_第三板斧,我們的產(chǎn)品會被各種不同的用戶使用，不同的用戶對我們的產(chǎn)品的影響體現(xiàn)為：不同的配置（產(chǎn)品的具體配置）、不同

8、的操作行為、不同的運行環(huán)境（如硬件環(huán)境、軟件環(huán)境、網(wǎng)絡環(huán)境、負載等）、不同的要求、不同的區(qū)域、不同的使用習慣等,高效測試案例設計_第三把斧,從測試角度的方向設計測試case 前面三板斧覆蓋了需求、開發(fā)設計和客戶應用場景，到現(xiàn)在為止設計測試case的思路基本都圍繞著產(chǎn)品，這時候需要把設計思路做一個轉(zhuǎn)變，把思路從產(chǎn)品身上暫時抽出來，從測試的角度去設計case,高效測試案例設計_第四板斧,什么是測試角度？ 測試角度是否等同于測試類型？ 測試角度為什么說測試角度是集體智慧的結(jié)晶？,高效測試案例設計_第四板斧,用舉例來說明測試角度： 測試類型屬于測試角度是測試角度的子集，測試類型是測試同行經(jīng)驗的結(jié)晶。

9、列舉一些測試類型：界面測試、邊界測試、安裝/卸載測試、易用性測試、一致性測試、可恢復測試、安全性測試、兼容性測試、容錯性測試、壓力測試、可靠性測試、性能測試等等,高效測試案例設計_第四板斧,續(xù)上 上面列舉的測試類型比較普遍，除此之外，應該把測試過程當中積累的一些技巧、經(jīng)驗抽象出來轉(zhuǎn)化為類似測試類型的文字信息，在設計測試case時作為參考如：功能關(guān)聯(lián)性測試、狀態(tài)測試、互斥測試、存儲測試、表項測試、交互式測試、破壞性測試、及時性測試等等 測試人員由于性格、知識技能、經(jīng)驗的差別，對同一個功能會有不同測試反應，在日常注意從case當中反推測試角度、測試思路：這個case是咋來的呢？用文字把思路抽象出來

10、，配合例子說明，成為測試角度的一分子,高效測試案例設計_第四板斧,續(xù)上 上面這些都是大類，下面還可以繼續(xù)進行細分，如表項測試可以細分為表項容量、表項老化、表項讀寫、表項刷新等等，細分可以到達2級、3級甚至更多，具體要結(jié)合產(chǎn)品而定 可以把測試角度制作成checklist，在設計測試case時強制要求執(zhí)行,高效測試案例設計_第四板斧,產(chǎn)品的實現(xiàn)技術(shù)能為測試case設計帶來思路 前面4把斧過后，回過頭來分析：為什么當前存在測試工程師不如開發(fā)工程師的現(xiàn)象？ 測試人員是否需要了解產(chǎn)品的實現(xiàn)技術(shù) 產(chǎn)品的實現(xiàn)技術(shù)如何能跟黑盒測試相結(jié)合,高效測試案例設計_第五板斧,產(chǎn)品的實現(xiàn)技術(shù)諸如編程語言、平臺技術(shù)、數(shù)據(jù)庫

11、技術(shù)等，測試人員可以學習些技術(shù)的特點和弱點，這些技術(shù)的特點和弱點很多“老人”已經(jīng)總結(jié)出來，我們只需要拿過來用就可以 不可以用自己的短處去和對方的長處較量，比方說測試人員和開發(fā)人員比編程能力，怎么比的過？ 換個角度，如果產(chǎn)品是采用c/c+開發(fā)，可以參考針對指針運用常見的問題，針對使用指針技術(shù)的功能設計黑盒case去PK，對于存在嵌套使用內(nèi)存的功能設計黑盒case去PK，找出內(nèi)存泄漏的問題等等,高效測試案例設計_第五板斧,測試列表的思想 測試列表是：產(chǎn)品測試功能點的集合 測試列表能減輕測試用例編寫和更新維護成本 測試列表采用樹形分層的思想，把功能需求拆分、邏輯流程圖、測試角度、應用場景和產(chǎn)品實現(xiàn)技

12、術(shù)這些測試case設計的思路融合到一張表格里面,高效測試案例設計_測試列表,測試列表的優(yōu)點 編寫成本低，頻繁更新帶來的維護成本低 滿足一定的 測試項目管理需求，和產(chǎn)品需求關(guān)聯(lián)化、便于統(tǒng)計、便于查詢、便于考核、便于功能擴展，融入一些新需求 便于閱讀，結(jié)構(gòu)清晰，內(nèi)容集中 便于設計，方便的融入各種測試思路 便于執(zhí)行，測試列表可以轉(zhuǎn)化為測試記錄列表，測試任務得以量化 測試列表在測試計劃制定和測試執(zhí)行、測試報告等過程當中發(fā)揮等同于測試用例的作用 便于評審,高效測試案例設計_測試列表,測試列表的內(nèi)容 編號 應用場景/功能描述/邏輯流程圖分析 測試項、測試分項1、2、3 測試角度 測試功能點 預期結(jié)果及判斷

13、方法 關(guān)聯(lián)測試點 優(yōu)先級別 編寫修改原因 支持版本 ,高效測試案例設計_測試列表,技術(shù)理解文檔的思想 技術(shù)理解文檔是為了讓測試人員掌握好測試所必須產(chǎn)品技能和測試技能提供一些參考指導 技術(shù)理解文檔是設計測試case的重要依據(jù) 技術(shù)理解文檔是一面鏡子，可以讓編寫文檔的人找出自己的問題，也可以讓周圍的人通過文檔找出編寫人在產(chǎn)品技能及相關(guān)測試技能理解存在的問題 技術(shù)理解文檔起到技術(shù)共享、技術(shù)存檔的作用 技術(shù)理解文檔對個人文檔組織能力和邏輯思維能力的提高有幫助,高效測試案例設計_技術(shù)理解文檔,技術(shù)理解文檔模板的內(nèi)容： 產(chǎn)品的定位 產(chǎn)品術(shù)語解釋 產(chǎn)品功能說明 產(chǎn)品功能業(yè)務描述 產(chǎn)品規(guī)格說明 產(chǎn)品的運行環(huán)境

14、 產(chǎn)品的部署指導 同類產(chǎn)品分析對比,高效測試案例設計_技術(shù)理解文檔模板,續(xù)上 產(chǎn)品整體架構(gòu) 功能模塊邏輯流程圖 模塊接口 數(shù)據(jù)庫技術(shù) 開發(fā)平臺技術(shù) 產(chǎn)品/功能主要實現(xiàn)算法/策略 產(chǎn)品測試技能 測試重點 自動化需求,高效測試案例設計_技術(shù)理解文檔模板,高效測試案例設計_前半部總結(jié),功能內(nèi)部處理,輸入,輸出結(jié)果,五板斧,接招處理,業(yè)務數(shù)據(jù)流 參考需求文檔 第一板斧,業(yè)務數(shù)據(jù)流 參考研發(fā)設計文檔當中列舉處理的數(shù)據(jù)業(yè)務流 第二板斧,從應用場景角度去考慮數(shù)據(jù)業(yè)務流 第三板斧,從測試角度去考慮數(shù)據(jù)業(yè)務流 第四板斧,從產(chǎn)品實現(xiàn)技術(shù)角度考慮數(shù)據(jù)業(yè)務流 第五板斧,設計測試case沒有最好，只有更好！ 在系統(tǒng)測試開始后，隨著測試進程的不斷深入，測試人員對產(chǎn)品的實現(xiàn)和應用的理解不斷加深，原先沒有考慮到的測試點會不斷的涌現(xiàn)，需要及時的把這些涌現(xiàn)的測試點及時補充到測試列表當中,高效測試案例設計_后半部,測試case的更新思路 來源于之前的外部故障 新測試工具的引入或者現(xiàn)有測試工具應用的挖掘，從對口的測試工具功能/參數(shù)去反推測試case 從bug庫去尋找思路，別人發(fā)現(xiàn)bug的思路和方法也可能適合自己所負責的模塊,高效測試案例設計_后半部,高效測試案例