推薦：想了解一個(gè)項(xiàng)目完整測試流程，看這篇文章就OK了

寫在前面：本文來自真實(shí)企業(yè)測試人員的工作總結(jié)，用一個(gè)項(xiàng)目的進(jìn)行流程為線索，記錄每個(gè)階段測試包含的內(nèi)容及關(guān)注點(diǎn)。

<ignore_js_op>

　　項(xiàng)目的測試流程大只包含的幾個(gè)階段：立項(xiàng)、需求評審、用例評審、測試執(zhí)行、測試報(bào)告文檔
　　一、立項(xiàng)后測試需要拿到的文檔
　　1、需求說明書
　　2、原型圖（及UI圖）
　　3、接口文檔
　　4、數(shù)據(jù)庫字典（表的數(shù)量、緩存機(jī)制）

　　二、需求評審
　　參加人員：開發(fā)、測試及需求人員，由需求人員主持講解。
　　為了會(huì)議的有效舉行，測試及開發(fā)人員需要在會(huì)議開始之前熟悉需求文檔及原型，將有疑問 的點(diǎn)標(biāo)注出來在會(huì)議中一一確認(rèn)，對不明確的點(diǎn)要督促開發(fā)及需求一并關(guān)注，對不能立馬得到肯定回復(fù)的點(diǎn)記錄在一起，會(huì)議結(jié)束后，郵件整理好發(fā)出給各位參與的人員。
　　在項(xiàng)目可控的進(jìn)度中，需求評審時(shí)必要的環(huán)節(jié)。當(dāng)然，有些比較小的項(xiàng)目會(huì)忽略此階段，個(gè)人認(rèn)為這是非常有必要的環(huán)節(jié)，這不但減少了后期開發(fā)、測試、需求人員的意見分歧，保證項(xiàng)目的進(jìn)度的必要手段。

　　三、用例編寫（同時(shí)根據(jù)開發(fā)計(jì)劃編寫測試計(jì)劃）
　　用例功能類型
　　所在就職部門將用例分成7類：
　　1、主流程：該模塊實(shí)現(xiàn)的主要功能流程。
　　2、備選流：不一定完成執(zhí)行一個(gè)功能，而是終止了流程。
　　3、異常流：由于某些異常原因，使流程的功能無法實(shí)現(xiàn)。
　　4、業(yè)務(wù)規(guī)則：必填項(xiàng)，強(qiáng)制的要求。
　　5、正常類：返回功能、必填項(xiàng)輸入范圍、頁面按鈕的切換等。
　　6、異常類：網(wǎng)絡(luò)異常、返回異常等。
　　7、界面檢查：針對每個(gè)頁面的樣式及內(nèi)容檢查。
　　注：幾個(gè)大類中主流程、正常類、異常類、和界面檢查四個(gè)大類使用的比較多，一個(gè)項(xiàng)目不需要涵蓋所有的用例類別，只需要根據(jù)所在項(xiàng)目的實(shí)際情況來進(jìn)行測試用例的分類即可。
　　編寫用例可在TestLink及excel上進(jìn)行，一般會(huì)在TestLink上進(jìn)行，小項(xiàng)目會(huì)比較習(xí)慣用excel進(jìn)行，excel記錄測試用例的字段有：
　　用例編號、功能模塊、功能類型、用例等級、用例描述、前置條件、數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、客戶端、執(zhí)行結(jié)果、備注、設(shè)計(jì)人、執(zhí)行人等
　　用例編寫注意點(diǎn)：
　　1、盡可能結(jié)合用例設(shè)計(jì)方法設(shè)計(jì)測試用例
　　2、不要只根據(jù)需求文檔明確標(biāo)出的需求編寫用例，還需要多考慮一些衍生的場景；
　　3、用例編寫前，先畫出整個(gè)功能的簡要流程圖；
　　4、用例描述簡潔且?guī)в薪Y(jié)果，不要重復(fù)贅述；
　　5、用例步驟和預(yù)期結(jié)果要一致，且一個(gè)步驟對應(yīng)一個(gè)預(yù)期結(jié)果。
　　測試用例的編寫方法
　　1、等價(jià)類劃分
　　2、邊界值分析法
　　3、錯(cuò)誤推斷法
　　4、因果分析法
　　5、場景法

　　四、用例評審
　　參與人員：開發(fā)、測試、需求人員、項(xiàng)目經(jīng)理，由測試人員主導(dǎo)。
　　此環(huán)節(jié)在開發(fā)完成功能之前進(jìn)行，根據(jù)評審時(shí)提的點(diǎn)進(jìn)行用例完善，完善后郵件發(fā)給參與人員。
　　在項(xiàng)目組中，更多情況下測試比開發(fā)會(huì)更了解需求，專業(yè)決定我們對需求的理解是肯定更接近客戶的，我們的對需求理解后的輸出產(chǎn)物是測試用例，某種意義上講用例是對需求細(xì)化的一種。 而開發(fā)對需求理解會(huì)更偏向于功能實(shí)現(xiàn)，產(chǎn)物就是程序。所以開發(fā)、測試經(jīng)常會(huì)存在需求理解不一致的情況，開發(fā)也不會(huì)那么細(xì)致的去理解需求，這點(diǎn)相信所有的項(xiàng)目經(jīng)理和需求分析都是有共鳴的：
　　我們做測試用例評審的作用有但不局限于以下3點(diǎn)：
　　1、統(tǒng)一開發(fā)、測試、需求三方對需求的理解
　　2、幫組開發(fā)更細(xì)致的去理解需求、同時(shí)養(yǎng)成看需求的習(xí)慣
　　3、需求分析人員在一定程度上對需求的理解也是有盲點(diǎn)的，通過評審可以挖出這些盲點(diǎn)（需求評審的作用也是一樣）
　　4、測試人員的能力和經(jīng)驗(yàn)不一樣，所有用例也會(huì)有差異性，通過評審可以指出我們遺漏的場景，從而能更好的保障咱們的項(xiàng)目質(zhì)量
　　5、在用例評審時(shí)，很多交互設(shè)計(jì)上的問題，前后臺(tái)交互的問題等都會(huì)暴露
　　6、如果測試用例在開發(fā)完成前進(jìn)行評審，很多時(shí)候開發(fā)人員即使不去看需求說明書，只要他認(rèn)真的參加了用例評審會(huì)，基本上也不會(huì)出現(xiàn)遺漏需求，需求實(shí)現(xiàn)偏差太大的情況了.因?yàn)槟阋ッ總€(gè)開發(fā)人員那么仔細(xì)的去看需求，短時(shí)間內(nèi)是不太可能的。用例評審是這個(gè)過渡期的橋梁。
　　一般可根據(jù)計(jì)劃時(shí)間完成用例編寫，中間會(huì)預(yù)留1天給他們看需求。在評審每一個(gè)模塊的用例之前，會(huì)明確點(diǎn)名這幾個(gè)人要注意，在評審的過程中，問開發(fā)一些問題,不是只單純的講用例,他們可以不看需求，但是我會(huì)提問一下,們要同時(shí)提升開發(fā)人員的參與感。

　　五、測試執(zhí)行
　　showcase測試：
　　測試到開發(fā)的電腦上進(jìn)行，主要執(zhí)行一下關(guān)鍵測試用例、流程用例，由開發(fā)操作，測試人員一起查看。showcase不通過，則打回，郵件發(fā)出。
　　冒煙測試：
　　showcase測試通過后，提交到測試，由測試人員開始大量跑關(guān)鍵測試用例。若針對某個(gè)模塊跑用例時(shí)，出現(xiàn)較多問題，則也可重新打回給開發(fā)。冒煙測試報(bào)告郵件如下字段：測試模塊 是否通過 不通過原因 測試詳情 備注
　　郵件描述大致如下：以下是截止到某個(gè)日期，已提交的功能冒煙測試結(jié)果，都不通過，詳情如下：
　　ps:冒煙測試不通過的原因基本上都是。。。。。，麻煩大家相互配合，早點(diǎn)修復(fù)提測，謝謝~
　　功能測試：
　　功能測試在手工測試中是主要的階段，這個(gè)階段主要是全量跑測試用例，提交bug到缺陷管理工具。
　　1、表單測試：
　　a、表單數(shù)據(jù)的字段、完整性及表單輸入框的長度限制問題
　　b、一些常理性邏輯驗(yàn)證，比如：出生日期和職業(yè)，工作年限是否恰當(dāng)，所在地省份城市區(qū)域間的匹配等，如果設(shè)定使用默認(rèn)值，也需要測試。
　　2、導(dǎo)航測試：
　　導(dǎo)航測試，就是在不同的頁面跳轉(zhuǎn)之間，或者按鈕、對話框、列表以及窗口等，通過考慮這些因素去判斷一個(gè)應(yīng)用是否易于導(dǎo)航：是否直觀？系統(tǒng)的主要模塊是否可以通過主頁訪問或者到達(dá)？站點(diǎn)是否需要站內(nèi)地圖或者搜索引擎等其他幫助？web系統(tǒng)導(dǎo)航的另外一個(gè)重點(diǎn)就是頁面結(jié)構(gòu)、導(dǎo)航、菜單、風(fēng)格等是否一致，確保用戶可以憑借直覺或者簡單的判斷就可以找到自己想要的內(nèi)容。
　　3、UI測試：
　　也可以理解為UI測試，其中包括圖片、動(dòng)畫、邊框、顏色、字體、背景、按鈕等等。
　　注： 其中要考慮的幾個(gè)重點(diǎn)，我做了一個(gè)大概的總結(jié)：
　　a、圖片要有明確的用途，代表；圖片尺寸盡量小，一般采用JPG或者GIF壓縮（即規(guī)格大小的限制）
　　b、頁面整體風(fēng)格是否和系統(tǒng)的用途一致
　　c、背景顏色，字體，搭配是否合理
　　4、內(nèi)容測試：
　　這個(gè)主要用來檢測web系統(tǒng)提供信息的準(zhǔn)確性、相關(guān)性。
　　比如：商品的價(jià)格，文字描述；信息的準(zhǔn)確性，是否有拼寫錯(cuò)誤；（這點(diǎn)比較容易忽略，需要多注意）信息的相關(guān)性，比如很多網(wǎng)站的“相關(guān)文章列表，視頻列表等”
　　5、整體界面測試
　　a、 這個(gè)也就是我們常說的用戶體驗(yàn)。用戶瀏覽時(shí)是否感覺舒適，整體風(fēng)格等等
　　b、建議一般做一個(gè)類似問卷調(diào)查的形式，來判定用戶的反饋信息，最好有最終用戶的參與，可參考類似的筆記哦啊普遍的系統(tǒng)風(fēng)格是怎樣的，結(jié)合實(shí)際來考慮本測試系統(tǒng)的風(fēng)格

　　6、鏈接測試（平時(shí)在測試過程中并不關(guān)注，而是在權(quán)限分配的安全測試中比較注重，主要是不同權(quán)限的人分享的鏈接是否能正確過濾，保證安全）

　　7、輸入框測試
　　在web測試中，我們經(jīng)常遇到這種輸入框的測試，輸入框測試看似簡單，實(shí)際上包含了很多的測試基本的方法，思考邏輯，下面就是我總結(jié)出來的一些注意點(diǎn)：
　　1）驗(yàn)證輸入輸出信息的一致性
　　2）輸入框前面的文字提示是否正確
　　3）對特殊字符的處理、識(shí)別：單雙引號，括號，逗號、分號等等，以及大小寫狀態(tài)，半角全角狀態(tài)下的情況
　　4）輸入框的大小、長度、邊框等
　　5）不同字符的輸入，以及字符組合情況的處理（數(shù)字+字母+字符等）
　　6）對空格、tab換行鍵的處理機(jī)制
　　7）密碼輸入框字符星號或者其他星號的轉(zhuǎn)行，加密
　　8）輸入框輸入字符長度是否有限制
　　9）字符本身顯示的顏色，規(guī)格等
　　10）有些輸入框需要加以限制，如輸錯(cuò)，是否有提示？提示是否簡單合理？
　　11）輸入狀態(tài)，某種情況下輸入框出于不可編輯，當(dāng)再次處于編輯狀態(tài)，輸入框的輸入狀態(tài)是否有變化？
　　12）輸入類型：是否允許復(fù)制黏貼剪切等輸入操作
　　13）關(guān)鍵字是否支持通配符，以及關(guān)鍵字的搜索能力，敏感字等情況
　　14）輸入框輸入空格的情況
　　15）比如登陸注冊，各項(xiàng)輸入條件的判定：是否輸入，輸入是否正確等

　 用戶權(quán)限測試
　　用戶權(quán)限，顧名思義，就是該賬號擁有哪些執(zhí)行操作的權(quán)利
　　1）給某賬號賦予權(quán)限后，登陸該賬號，查看是否擁有已賦予的權(quán)限，以及權(quán)限設(shè)置是否正確（權(quán)限是否超過或者不足）
　　2）刪除或修改已經(jīng)登陸并且正在執(zhí)行操作的賬號權(quán)限，程序能否正確處理，驗(yàn)證
　　3）重新注冊系統(tǒng)變更登陸身份后再登陸，程序能否正確執(zhí)行，之前所擁有的權(quán)限能否繼續(xù)使用
　　4）在用工作分配或者角色管理情況下，刪除包含用戶的工作組或者角色，程序能否正確處理
　　5）不同權(quán)限賬號登陸同一個(gè)系統(tǒng)，權(quán)限范圍是否正確
　　6）能否給信息為空、長用戶名的賬號添加權(quán)限
　　7）是否允許刪除系統(tǒng)管理員或者修改管理員權(quán)限？刪除或者修改后的實(shí)際情況
　　8）已登錄的用戶能否修改或者刪除自己或者他人的權(quán)限，信息
　　9）添加用戶（有編號或者標(biāo)識(shí)），不同用戶名標(biāo)識(shí)的組合情況下，權(quán)限能否處理正確
　　10）修改用戶權(quán)限或者信息后，對其他模塊是否有影響
　　11）如果修改用戶信息為和已存在的其他用戶信息相同，能否修改成功？是否有對應(yīng)提示？
　　12）修改某些設(shè)置，是否會(huì)對與該賬號權(quán)限相同或者高于/低于該賬號的其他賬號的權(quán)限造成影響
　　13）同一用戶是否可以同時(shí)屬于其他組，各個(gè)組的權(quán)限能否交叉？

回歸測試
　　回歸測試書要是根據(jù)在測試執(zhí)行過程中記錄的bug及執(zhí)行失敗的用例來進(jìn)行的，根據(jù)記錄的bug進(jìn)行驗(yàn)證是否已經(jīng)修改更新好，必要時(shí)，根據(jù)bug量的多少來評估是否需要重新跑一下系統(tǒng)的流程。

　　兼容性測試
　　a、平臺(tái)兼容
　　在有很多的操作系統(tǒng)，比如Windows、Unix、Linux、macintosh等；用戶使用哪個(gè)系統(tǒng)取決于用戶，因此，系統(tǒng)兼容測試就很有必要了。
　　b、瀏覽器兼容
　　瀏覽器是web客戶端最核心的組件，不同的瀏覽器，對Java，JavaScript，css或者HTML的規(guī)格都有不同的支持；
　　另外，采用的框架和結(jié)構(gòu)風(fēng)格在不同瀏覽器中也存在不同的顯示甚至不顯示，不同的瀏覽器對安全性的設(shè)置也是不同的。
　　測試瀏覽器兼容，有個(gè)方法就是創(chuàng)建一個(gè)兼容性矩陣，來測試不同廠商不同版本的瀏覽器兼容。
　　比如測試IE瀏覽器，可以通過一個(gè)叫做IEtester的工具來測試兼容，或者可以通過F12控制臺(tái)來切換瀏覽器版本來測試兼容以前一些前端元素的顯示等
　　鑒于國內(nèi)市場瀏覽器很多，比如360、搜狗，搜狐、QQ瀏覽器等，這些本土的瀏覽器基本都采用的IE瀏覽器內(nèi)核的雙核配置

　 安全測試
　　安全測試的主要區(qū)域有以下幾點(diǎn)：
　　a、現(xiàn)在很多web應(yīng)用系統(tǒng)都采用先注冊后登錄的方式，因此，測試用戶名和密碼的有效無效性，注意大小寫敏感，次數(shù)限制，是否可以不登錄而瀏覽某些頁面等
　　b、是否有超時(shí)限制，鏈接分享，cookie劫持
　　c、測試用戶操作時(shí)相關(guān)信息是否寫入了日志文件、是否可追蹤等
　　d、如果使用了安全套字，需要測試加密是否正確，加密前后的信息完整性，正確性
　　e、沒有經(jīng)過授權(quán)，是否可以在服務(wù)器端或者前端放置和編輯腳本的問題
　　f、輸入框的SQL注入驗(yàn)證

　　六、測試報(bào)告及操作手冊
　　測試報(bào)告每個(gè)公司的使用模板可能不盡相同，但是重點(diǎn)都是反映測試結(jié)果及測試中出現(xiàn)的bug分配模塊，還要關(guān)注bug解決的狀態(tài)，只要根據(jù)模板中的需要去進(jìn)行統(tǒng)計(jì)即可。
　　操作手冊主要是寫給使用該系統(tǒng)的人員看的，要求是具體詳細(xì)，什么角色什么模塊可進(jìn)行什么操作的描述要清晰，一步一步配上截圖和文字。

總結(jié)

以上是生活随笔為你收集整理的推荐：想了解一个项目完整测试流程，看这篇文章就OK了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。