項(xiàng)目中如何充分利用自動(dòng)化測(cè)試？

一、首先，需要分析當(dāng)前項(xiàng)目是否適合自動(dòng)化測(cè)試：

1. 測(cè)試需求明確，不會(huì)頻繁變動(dòng)

2. 回歸測(cè)試為主的項(xiàng)目

3. 軟件系統(tǒng)界面穩(wěn)定，變動(dòng)少

4. 每次迭代需要在多平臺(tái)（或多OS、多Browser）上運(yùn)行重復(fù)的case。

5. 軟件維護(hù)支持周期長(zhǎng)

6. 手工測(cè)試無法模擬的場(chǎng)景。如壓力測(cè)試、并發(fā)測(cè)試等

7. 具備基礎(chǔ)的自動(dòng)化測(cè)試平臺(tái)

   
   

二、以下是曾經(jīng)參與過的一個(gè)項(xiàng)目的自動(dòng)化測(cè)試框架

    實(shí)現(xiàn)了自動(dòng)更新代碼、編譯、打包、部署、重啟服務(wù)、定時(shí)執(zhí)行腳本任務(wù)，日志報(bào)告輸出，自動(dòng)發(fā)送郵件通知。

在自動(dòng)化開始前需要確定預(yù)期，需要達(dá)到怎樣的目的。而不是抽象的減少人力成本，盡可能多地發(fā)現(xiàn)Bug或節(jié)省時(shí)間等等。自動(dòng)化測(cè)試應(yīng)該是發(fā)現(xiàn)那些可以被工具化自動(dòng)化的重復(fù)性活動(dòng)而后實(shí)現(xiàn)的，并非100%的Case都可以自動(dòng)化，測(cè)試人員的經(jīng)驗(yàn)，邏輯判斷和探索性的測(cè)試方法都不能被有效自動(dòng)化。

在一般的項(xiàng)目中，需要保證被測(cè)版本的基本質(zhì)量，可以進(jìn)行大量的功能測(cè)試和壓力測(cè)試。

（1）發(fā)現(xiàn)環(huán)境層級(jí)的缺陷。

項(xiàng)目系統(tǒng)測(cè)試階段發(fā)現(xiàn)的很多缺陷，都會(huì)聽到開發(fā)人員自測(cè)時(shí)沒問題的，甚至在本地測(cè)試時(shí)無此缺陷 ，直接將Bug打回，標(biāo)注為無法重現(xiàn)。這就是環(huán)境問題了，曾經(jīng)遇到過一個(gè)一級(jí)菜單點(diǎn)選時(shí)導(dǎo)致子菜單錯(cuò)亂的問題（與其他一級(jí)菜單的子菜單混淆顯示了）。經(jīng)排查才知是，開發(fā)將菜單的坐標(biāo)值寫死了，導(dǎo)致?lián)Q環(huán)境后無法正常識(shí)別菜單信息。這是典型的環(huán)境問題，只有通過復(fù)測(cè)才能發(fā)現(xiàn)。另一種就是開發(fā)自測(cè)時(shí)是在本地，而自己機(jī)器上利用管理員權(quán)限部署了一些安裝包或工具，自測(cè)時(shí)也無法清楚地知道被測(cè)版本是否依賴了這些包或工具。而部署到測(cè)試環(huán)境時(shí)才發(fā)現(xiàn)一些問題。類似于以上的問題如果及時(shí)構(gòu)建了被測(cè)版本，且自動(dòng)執(zhí)行了基本功能，會(huì)在正式測(cè)試前發(fā)現(xiàn)這些環(huán)境問題，而不是等到系統(tǒng)測(cè)試階段才去排查 。

（2）盡快發(fā)現(xiàn)集成階段的錯(cuò)誤。

集成測(cè)試階段的缺陷若未暴露出或不影響到正常流程，無法確定錯(cuò)誤是哪個(gè)開發(fā)人員負(fù)責(zé)的模塊，同時(shí)開發(fā)人員因時(shí)間問題，不能測(cè)試出大部分的潛在的集成缺陷 ，導(dǎo)致部署到系統(tǒng)測(cè)試階段暴露出的錯(cuò)誤，無疑更增加了開發(fā)測(cè)試的時(shí)間。如果每次構(gòu)建都可以自動(dòng)化執(zhí)行到基本功能 ，使開發(fā)能及時(shí)地發(fā)現(xiàn)集成錯(cuò)誤 ，同時(shí)也可彌補(bǔ)單元測(cè)試的不足，快速提供系統(tǒng)級(jí)的測(cè)試反饋。