分享嘉賓阿輝簡介：
6年測試宋梧，帶領過測試團隊，在測試整體體系狰挡、測試流程把控捂龄、項目質量把控方面非常有經(jīng)驗
第五期主題：測試思路
在進行需求評審之前，先要清楚有哪些需求
只有深刻理解了軟件產(chǎn)品的需求加叁，才能有效地完成需求的評審倦沧。
要把握好需求，需要從多個方面去思考和分析它匕，包括用戶展融、用戶業(yè)務、和外部條件等豫柬，最終理解用例告希、產(chǎn)品功能性特性和非功能性等。
一張圖勝過千萬字烧给，如下是課間分享的內容：
課間案例分享
1暂雹、需求分析
需求分析一般可分為功能需求、非功能需求和領域需求
-
功能需求：
主要說明了系統(tǒng)實際應做到什么创夜。這是用戶最直觀也是最主要的需求，如系統(tǒng)的輸入輸出仙逻、系統(tǒng)能完成的功能以及其它相關處理等 -
非功能需求：
也稱“約束”驰吓，主要從各個角度對系統(tǒng)起約束和限制作用。如響應時間系奉、存儲效率檬贰、報表的規(guī)格和界面的樣式等 -
領域需求：
來源不是用戶，而是系統(tǒng)應用的領域缺亮，其主要反映了該領域的基本問題翁涤。
例如勤工儉學管理系統(tǒng)，其領域需求就涉及到應聘合同書萌踱、酬金發(fā)放及勞工考核等相關內容葵礼，如果這些需求得不到滿足，系統(tǒng)就無法正常運行并鸵。
PS：領域需求可能是功能需求鸳粉，也可能是非功能需求。
相信很多朋友都有這種體驗：
1）早上來到公司园担，接到通知參與項目需求評審届谈，需要測試介入
2）一個緊急項目枯夜，可能已經(jīng)在開發(fā)階段了，需要測試接入
3）一個緊急項目已經(jīng)完成艰山，需要測試
......
那么碰到這種情況要如何處理呢湖雹？
在需求評審前，一般產(chǎn)品經(jīng)理會把需求發(fā)到與會者郵箱（郵件通知）或 將文檔傳到公司的共享目錄下曙搬，群里通知各位參與會議
測試人員可以提前1天或1個時間段摔吏，把文檔下載下來，進行綜合分析织鲸，對不理解的或產(chǎn)生歧義的地方進行批注舔腾，尤其是對需求挖掘不夠的地方，對功能需求不明確的地方
上述做法的好處：
1）需求評審（靜態(tài)測試）前了解了需求搂擦，知道了大概功能稳诚，在評審時進一步了解，在會上可以對標注問題針對性提問瀑踢，這樣就可以在需求階段把存在的風險避免掉了
2）在評審時集中式提問扳还，而不是打斷產(chǎn)品經(jīng)理的思路，不然評審會議時間會比預期長
（會議期間帶上紙筆橱夭，在產(chǎn)品經(jīng)理講述的時候記錄想到的問題氨距，等一個階段闡述完后再進行提問）
3）站在用戶的角度考慮問題
需求的制定滿足哪些用戶，用戶什么情況下使用系統(tǒng)/功能棘劣，用戶如何使用系統(tǒng)俏让，使用頻率（高/低），該系統(tǒng)的優(yōu)勢
2茬暇、把需求轉化為功能點
UI與數(shù)據(jù)分離首昔，是指把顯示與數(shù)據(jù)進行分離：通過鎖定需求文檔，將UI與數(shù)據(jù)接偶糙俗，優(yōu)先關注數(shù)據(jù)的產(chǎn)生與業(yè)務處理的正確性勒奇、UI對數(shù)據(jù)顯示的正確性、用戶體驗
輪播條：前臺通過ajax請求巧骚，在網(wǎng)頁加載數(shù)據(jù)時加載輪播條數(shù)據(jù)赊颠，用JS生成輪播條，利用接口測試數(shù)據(jù)正確性劈彪，然后看顯示的正確性（合不合適要看功能UI對數(shù)據(jù)的封裝程度）
一般的輪播條竣蹦，接口返回 json格式的數(shù)據(jù)，但UI將其分門別類去封裝去展示沧奴，變成一個無序的滾動顯示草添，與衍生的數(shù)據(jù)有很大差別，這種情況很適合前后端的數(shù)據(jù)分離扼仲。
名詞解釋：
原生數(shù)據(jù)：是指不依賴于現(xiàn)有數(shù)據(jù)而產(chǎn)生的數(shù)據(jù)远寸，例如用戶發(fā)表的評論數(shù)據(jù)抄淑、用戶使用服務的日志數(shù)據(jù)等。
衍生數(shù)據(jù)：是指原生數(shù)據(jù)被記錄驰后、存儲后肆资，經(jīng)過算法加工、計算灶芝、聚合而成的系統(tǒng)的郑原、可讀取、有使用價值的數(shù)據(jù)
3夜涕、黑盒測試法拆解
分析輸入輸出犯犁，根據(jù)輸入的分類劃分功能點，進行枚舉女器，輸出
功能輸入：用戶數(shù)據(jù)輸入
- 表單
- 系統(tǒng)提供的數(shù)據(jù)（股票實時交易過程中價格酸役、成交記錄）
- 時間變量
- 某些功能可以運行的前提條件，即某個功能存在的意義必須依賴于其他的輸入驾胆，但這輸入并不屬于該功能的輸入（就是寫case時的前置條件）
如客服系統(tǒng)：需要聊天涣澡，就必須先建立會話
4、自頂向下拆解功能
功能劃分（用Xmind進行思維發(fā)散）：以系統(tǒng)提供的功能為中心來組織系統(tǒng)丧诺。
首先定義各種功能入桂，然后把功能分解為子功能，同時定義功能之間的接口驳阎。
舉例：客服系統(tǒng)--考慮系統(tǒng)可以干什么抗愁，有哪些輸入哪些輸出。
如智能回復呵晚、人工回復驹愚，根據(jù)智能回復再分有會話生命周期，如何使用......
5劣纲、瀏覽器兼容性測試
測試一個web應用：用戶登錄，生成報表谁鳍，發(fā)送報表癞季，退出系統(tǒng)，管理功能（管理員登錄后可查看哪些人做了哪些改動）
為了覆蓋更多的瀏覽器倘潜，可以采用A瀏覽器來測試“登錄”功能绷柒，在B瀏覽器中測試“發(fā)送報表”的功能，用C瀏覽器測試“生成報表”的功能......
上述看似是一個有效的方法涮因，但還是存在一些問題的废睦，比如說，如果“生成報表”這個功能在C瀏覽器中正常养泡，而在B瀏覽器里是有問題嗜湃，那么就會發(fā)現(xiàn)不了奈应。
多瀏覽器的支持是我們心中永遠的痛，特別是如今瀏覽器更新如此頻繁的狀況下购披，哎~
PS：有些瀏覽器有兼容模式杖挣，可以通過兼容模式來模擬老版本。像Chrome/IE刚陡，都提供了開發(fā)者工具可以幫著定位問題
Q&A環(huán)節(jié)
Q：一輪測試用例惩妇，在發(fā)現(xiàn)漏洞是要馬上提交？研發(fā)聲稱已經(jīng)解決并提交之后筐乳，測試是應該繼續(xù)執(zhí)行完一輪測試用例還是應該優(yōu)先驗證漏洞是否已經(jīng)解決歌殃？
A：看對版本如何處理，一輪測試結束后新版本重新發(fā)布重新測試Q：測試下來蝙云，太詳細的測試用例氓皱，在實際測試過程中基本不會去使用，怎么改變這個現(xiàn)象贮懈，是只寫測試點嗎匀泊？
A：整理通用用例（庫）和個性化用例（Xmind或某個項目），可以用 Xmind 列測試點Q：兼容性朵你，是主要功能走流程各聘，還是每個功能點細測呢？
A：首先保證功能正常抡医，其次是UI方面交互體驗測試Q：系統(tǒng)需要用哪些瀏覽器是否由需求決定躲因？
A：若是內部系統(tǒng)，就簡單很多忌傻，可以由項目經(jīng)理決定大脉，非內部使用的話還是看市場占有率吧Q：兩個瀏覽器的內核一樣的嗎，如果一個通過了水孩，另一個我也可以默認是通過嗎镰矿？
A：不一定
瀏覽器版本信息
瀏覽器打開開發(fā)者工具（F12），輸入navigator.appCodeName俘种，navigator.appVersion秤标，可以查看內核與版本信息
以下是常見的瀏覽器信息
Trident內核的瀏覽器：IE、Maxthon宙刘、TT苍姜、The World
Webkit內核的瀏覽器：Safari、Chrome悬包、360衙猪、Edge
雙核/多核的瀏覽器：如搜狗瀏覽器，由Trident和Webkit 組成
Presto內核的瀏覽器：Opera7及以上版本
Netcape6及以上版本、FireFox垫释、MozillaSuite/SeaMonkey
這次分享都是滿滿的干貨丝格，收貨很多，希望能用到工作中去饶号。
比如說我們目前是沒有維護bug庫的铁追，已經(jīng)關閉的bug，存在被重新激活的情況
以后要系統(tǒng)的分析產(chǎn)生bug的原因茫船，分門別類的統(tǒng)計成文檔琅束，測試與開發(fā)共享，督促開發(fā)不再犯同樣的錯誤不再產(chǎn)生同樣的bug算谈。
