做自動(dòng)化測試的人，經(jīng)常碰到這樣的問題：
上司：“腳本跑得如何了？找到BUG沒有？”
員工：“沒有。”
上司：“沒找到BUG？！不可能吧？是不是你腳本寫得不夠好？”
員工：“自動(dòng)化是拿來確保后期產(chǎn)品的質(zhì)量的，不是來找BUG的”（心里一百個(gè)不情愿，埋怨上司不懂什么叫自動(dòng)化，網(wǎng)上都這么說）
上司：（我給你哪么多時(shí)間你搭建的自動(dòng)化就給我一個(gè)這樣的結(jié)果？）
自然，這樣的對話會(huì)讓上司覺得普及自動(dòng)化的意義的存在與是否再愿意投入。
自動(dòng)化測試的意義，在很早以前就被自動(dòng)化老手定位在回歸測試中，或者說是由于主流的測試工具帶來的負(fù)面影響，目的在于確保工程質(zhì)量。因此這個(gè)理念也隨著時(shí)間的推移根深蒂固，很多人不愿意思考，自動(dòng)化就是回歸測試的人力代替品，這樣也導(dǎo)致了自動(dòng)化普及成了一個(gè)瓶頸。敢說現(xiàn)在很多公司對自動(dòng)化的重視遠(yuǎn)遠(yuǎn)沒有手工測試來得多，在這里與自動(dòng)化的定位脫不了干系。
在這里先說下場景測試用例與功能測試用例，場景用例是測試建立在某種已模擬的環(huán)境上，包括數(shù)據(jù)準(zhǔn)備，數(shù)據(jù)傳遞等的流程用例。而功能測試用例更偏重的是某個(gè)環(huán)節(jié)，控件等的可操作性與功能的測試用例。
普遍按照剛才的自動(dòng)化回歸論，就是基本建立在場景用例的基礎(chǔ)上，“錄制-回放”的模式。我們需要的是產(chǎn)品的定型，穩(wěn)定后，我們的自動(dòng)化工作才能展開。自然，在團(tuán)隊(duì)開發(fā)中，自動(dòng)化工程師就成了一個(gè)單打獨(dú)斗的角色，并且自動(dòng)化的優(yōu)勢被這樣的定位完全弱勢化，自動(dòng)化工程師早期就在哪里涼菜，后期又跟著別人后面跑，如果你是領(lǐng)導(dǎo)，你會(huì)被說服去讓產(chǎn)品如此自動(dòng)化嗎？
我們在長期的實(shí)踐中，我們慢慢摸索出如何讓自動(dòng)化的更為容易被大家所接受，普及并改進(jìn)。在這里我們重新對自動(dòng)化測試定位：
獨(dú)立于產(chǎn)品的成熟與穩(wěn)定
早期能建立在功能測試用例基礎(chǔ)上，并開展測試，后期建立于場景用例基礎(chǔ)上
更大的貫穿軟件生命周期
可維護(hù)性
通用性
敏捷性
高效性
為什么如此定位而且我們要如何做到呢。
一、定位能獨(dú)立與產(chǎn)品的成熟與穩(wěn)定，這點(diǎn)是很多自動(dòng)化工程師所期望的，與第二點(diǎn)其實(shí)有著必然的聯(lián)系，也是因?yàn)槲覀兘⒃诠δ軠y試用例的基礎(chǔ)上，讓我們能不局限于產(chǎn)品的現(xiàn)態(tài)。關(guān)于產(chǎn)品的穩(wěn)定，我們使用了基于功能測試的自動(dòng)化腳本，主要需要把握的是對異常的捕獲，它越不穩(wěn)定，我們抓到的BUG會(huì)更多，自然也需要考慮到錯(cuò)誤恢復(fù)。
二、我們要如何做到基于功能能測試用例的基礎(chǔ)上并讓腳本更通用，敏捷。
簡單舉個(gè)例子：輸入框測試功能測試用例大概包括：這個(gè)輸入框是否可輸入，是否為密碼框，長度，最小長度允許是否正確，是否隱藏，是否能輸入全角，是否能輸入數(shù)字，是否能輸入特殊字符等等自然想實(shí)現(xiàn)這樣的自動(dòng)化測試腳本，我們需要一定的編碼基礎(chǔ)，建議不要太指望自動(dòng)化測試工具，他們只是給你一種測試的思想，而我們現(xiàn)在做的和它們截然不同。
1)腳本編寫：根據(jù)功能測試用例編寫測試腳本。2)通用性 ：把對象，以及我們的期望值傳給腳本。
3)敏捷性 ：在傳遞對象，期望值能“高效快速實(shí)現(xiàn)”與“簡便”，這樣可以很快投入測試中并考慮到以后給其它黑盒測試人員使用。
4)可維護(hù)性：搭建優(yōu)秀的測試框架，把通用性，敏捷性囊括其中。
三、自動(dòng)化測試更大貫穿在軟件的生命周期中，為了達(dá)到這樣的目的，我們需要再把腳本細(xì)化成另外的2部分并讓它們在運(yùn)行過程中結(jié)合起來，分別是功能測試與流程測試，這樣才能很在軟件周期中占據(jù)更多。
同樣我們需要考慮到手工測試與自動(dòng)化腳本帶來的效益，區(qū)別：
手工測試的即興發(fā)揮找到BUG比腳本找到的更多。
腳本編寫是一個(gè)漫長的過程，更考慮到可拓展與通用，成本高。
手工測試的缺乏規(guī)范，會(huì)出現(xiàn)漏測問題。
手工測試效果被測試員情緒影響著。
自動(dòng)化測試能減少勞力與乏味重復(fù)測試。
自動(dòng)化測試能在早期比全面而迅速找到BUG。
隨著腳本規(guī)范的增多，腳本測試面增光，能找到更多的BUG。
隨著自動(dòng)化的普及與提高，我們憧憬的一幕：
上司：“怎么這么準(zhǔn)時(shí)就走呢？工作缺乏激情呀！”
員工：“腳本下午已經(jīng)4點(diǎn)到5點(diǎn)已經(jīng)整個(gè)系統(tǒng)跑完一次，BUG提交并開發(fā)已經(jīng)在改了，估計(jì)周末他們要加班（周五是無BUG日）?！?BR> 上司：“這系統(tǒng)環(huán)境不是下午3點(diǎn)才搭建的嗎？怎么哪么快呢？！”
員工：“是呀，凌晨1點(diǎn)會(huì)跑第2次，到時(shí)候會(huì)自動(dòng)發(fā)郵件給您和開發(fā)員，是否需要加班您再定吧”
走出電梯，快步消失….
上司：“腳本跑得如何了？找到BUG沒有？”
員工：“沒有。”
上司：“沒找到BUG？！不可能吧？是不是你腳本寫得不夠好？”
員工：“自動(dòng)化是拿來確保后期產(chǎn)品的質(zhì)量的，不是來找BUG的”（心里一百個(gè)不情愿，埋怨上司不懂什么叫自動(dòng)化，網(wǎng)上都這么說）
上司：（我給你哪么多時(shí)間你搭建的自動(dòng)化就給我一個(gè)這樣的結(jié)果？）
自然，這樣的對話會(huì)讓上司覺得普及自動(dòng)化的意義的存在與是否再愿意投入。
自動(dòng)化測試的意義，在很早以前就被自動(dòng)化老手定位在回歸測試中，或者說是由于主流的測試工具帶來的負(fù)面影響，目的在于確保工程質(zhì)量。因此這個(gè)理念也隨著時(shí)間的推移根深蒂固，很多人不愿意思考，自動(dòng)化就是回歸測試的人力代替品，這樣也導(dǎo)致了自動(dòng)化普及成了一個(gè)瓶頸。敢說現(xiàn)在很多公司對自動(dòng)化的重視遠(yuǎn)遠(yuǎn)沒有手工測試來得多，在這里與自動(dòng)化的定位脫不了干系。
在這里先說下場景測試用例與功能測試用例，場景用例是測試建立在某種已模擬的環(huán)境上，包括數(shù)據(jù)準(zhǔn)備，數(shù)據(jù)傳遞等的流程用例。而功能測試用例更偏重的是某個(gè)環(huán)節(jié)，控件等的可操作性與功能的測試用例。
普遍按照剛才的自動(dòng)化回歸論，就是基本建立在場景用例的基礎(chǔ)上，“錄制-回放”的模式。我們需要的是產(chǎn)品的定型，穩(wěn)定后，我們的自動(dòng)化工作才能展開。自然，在團(tuán)隊(duì)開發(fā)中，自動(dòng)化工程師就成了一個(gè)單打獨(dú)斗的角色，并且自動(dòng)化的優(yōu)勢被這樣的定位完全弱勢化，自動(dòng)化工程師早期就在哪里涼菜，后期又跟著別人后面跑，如果你是領(lǐng)導(dǎo)，你會(huì)被說服去讓產(chǎn)品如此自動(dòng)化嗎？
我們在長期的實(shí)踐中，我們慢慢摸索出如何讓自動(dòng)化的更為容易被大家所接受，普及并改進(jìn)。在這里我們重新對自動(dòng)化測試定位：
獨(dú)立于產(chǎn)品的成熟與穩(wěn)定
早期能建立在功能測試用例基礎(chǔ)上，并開展測試，后期建立于場景用例基礎(chǔ)上
更大的貫穿軟件生命周期
可維護(hù)性
通用性
敏捷性
高效性
為什么如此定位而且我們要如何做到呢。
一、定位能獨(dú)立與產(chǎn)品的成熟與穩(wěn)定，這點(diǎn)是很多自動(dòng)化工程師所期望的，與第二點(diǎn)其實(shí)有著必然的聯(lián)系，也是因?yàn)槲覀兘⒃诠δ軠y試用例的基礎(chǔ)上，讓我們能不局限于產(chǎn)品的現(xiàn)態(tài)。關(guān)于產(chǎn)品的穩(wěn)定，我們使用了基于功能測試的自動(dòng)化腳本，主要需要把握的是對異常的捕獲，它越不穩(wěn)定，我們抓到的BUG會(huì)更多，自然也需要考慮到錯(cuò)誤恢復(fù)。
二、我們要如何做到基于功能能測試用例的基礎(chǔ)上并讓腳本更通用，敏捷。
簡單舉個(gè)例子：輸入框測試功能測試用例大概包括：這個(gè)輸入框是否可輸入，是否為密碼框，長度，最小長度允許是否正確，是否隱藏，是否能輸入全角，是否能輸入數(shù)字，是否能輸入特殊字符等等自然想實(shí)現(xiàn)這樣的自動(dòng)化測試腳本，我們需要一定的編碼基礎(chǔ)，建議不要太指望自動(dòng)化測試工具，他們只是給你一種測試的思想，而我們現(xiàn)在做的和它們截然不同。
1)腳本編寫：根據(jù)功能測試用例編寫測試腳本。2)通用性 ：把對象，以及我們的期望值傳給腳本。
3)敏捷性 ：在傳遞對象，期望值能“高效快速實(shí)現(xiàn)”與“簡便”，這樣可以很快投入測試中并考慮到以后給其它黑盒測試人員使用。
4)可維護(hù)性：搭建優(yōu)秀的測試框架，把通用性，敏捷性囊括其中。
三、自動(dòng)化測試更大貫穿在軟件的生命周期中，為了達(dá)到這樣的目的，我們需要再把腳本細(xì)化成另外的2部分并讓它們在運(yùn)行過程中結(jié)合起來，分別是功能測試與流程測試，這樣才能很在軟件周期中占據(jù)更多。
同樣我們需要考慮到手工測試與自動(dòng)化腳本帶來的效益，區(qū)別：
手工測試的即興發(fā)揮找到BUG比腳本找到的更多。
腳本編寫是一個(gè)漫長的過程，更考慮到可拓展與通用，成本高。
手工測試的缺乏規(guī)范，會(huì)出現(xiàn)漏測問題。
手工測試效果被測試員情緒影響著。
自動(dòng)化測試能減少勞力與乏味重復(fù)測試。
自動(dòng)化測試能在早期比全面而迅速找到BUG。
隨著腳本規(guī)范的增多，腳本測試面增光，能找到更多的BUG。
隨著自動(dòng)化的普及與提高，我們憧憬的一幕：
上司：“怎么這么準(zhǔn)時(shí)就走呢？工作缺乏激情呀！”
員工：“腳本下午已經(jīng)4點(diǎn)到5點(diǎn)已經(jīng)整個(gè)系統(tǒng)跑完一次，BUG提交并開發(fā)已經(jīng)在改了，估計(jì)周末他們要加班（周五是無BUG日）?！?BR> 上司：“這系統(tǒng)環(huán)境不是下午3點(diǎn)才搭建的嗎？怎么哪么快呢？！”
員工：“是呀，凌晨1點(diǎn)會(huì)跑第2次，到時(shí)候會(huì)自動(dòng)發(fā)郵件給您和開發(fā)員，是否需要加班您再定吧”
走出電梯，快步消失….