專家眼中的QA、敏捷測(cè)試、探索式測(cè)試及測(cè)試的開放性
編者按:測(cè)試、QA一直是大家關(guān)注的話題,只要有軟件開發(fā),就離不開QA和軟件測(cè)試。本次特別邀請(qǐng)到一淘網(wǎng)測(cè)試架構(gòu)師 @公直_黃利 ,諾基亞敏捷及精益教練 @徐毅-Kaveri 和百度高級(jí)測(cè)試工程師楊進(jìn),請(qǐng)他們談下各自對(duì)QA和測(cè)試的理解,內(nèi)容涉及如何衡量軟件測(cè)試的有效性,探索式測(cè)試,敏捷測(cè)試,開源對(duì)測(cè)試的影響,測(cè)試的開放性以及測(cè)試框架推薦等。
請(qǐng)先做下自我介紹。
徐毅:我叫徐毅,現(xiàn)在在諾基亞北京擔(dān)任敏捷及精益教練的工作。我是從05年在杭州諾基亞網(wǎng)絡(luò)的時(shí)候開始轉(zhuǎn)做專職測(cè)試的,同期也加入公司剛成立的測(cè)試自動(dòng)化小組,這對(duì)我的理念有很大的影響,基本上我認(rèn)為所有的測(cè)試都應(yīng)該自動(dòng)化。06年初加入當(dāng)時(shí)的第一個(gè)Scrum試點(diǎn)項(xiàng)目,體會(huì)了一把敏捷測(cè)試,當(dāng)時(shí)還根據(jù)我們的經(jīng)驗(yàn)總結(jié)出了一套輕量化的測(cè)試流程。后來我們?cè)诠緝?nèi)推廣使用robotframework這個(gè)工具,作為培訓(xùn)師指導(dǎo)大家學(xué)會(huì)使用這個(gè)工具來進(jìn)行測(cè)試自動(dòng)化。后來還擔(dān)任了一段時(shí)間的測(cè)試自動(dòng)化教練的工作。
公直:阿里巴巴一淘網(wǎng)測(cè)試架構(gòu)師。
楊進(jìn):百度高級(jí)測(cè)試工程師,06年加入百度,之前有過4年的測(cè)試開發(fā)工作,加入百度以來,主要從事自動(dòng)化開發(fā)、測(cè)試方法改進(jìn)以及系統(tǒng)測(cè)試相關(guān)的工作。
最近主要在從事哪方面的工作?
徐毅:最近主要是在敏捷及精益教練這個(gè)方面做得比較多,輔助組織和個(gè)人進(jìn)行敏捷轉(zhuǎn)型,由于有很強(qiáng)的測(cè)試背景,所以同時(shí)也做敏捷測(cè)試相關(guān)的工作。
公直:最近半年一直在做代碼質(zhì)量的相關(guān)工作。在一淘業(yè)務(wù)線測(cè)試團(tuán)隊(duì)支持之下,與測(cè)試、產(chǎn)品架構(gòu)師、PE等合作,從系統(tǒng)層面出發(fā),優(yōu)化目前的測(cè)試策略和方法,提升系統(tǒng)的可測(cè)試性和可部署性。
楊進(jìn):近1年主要focus在系統(tǒng)測(cè)試和效果監(jiān)控等系統(tǒng)層面的工作,目前是線下百度和大搜索效果監(jiān)控的負(fù)責(zé)人,線下百度是一個(gè)基礎(chǔ)的系統(tǒng)測(cè)試平臺(tái),對(duì)外提供預(yù)上線、故障預(yù)演、數(shù)據(jù)測(cè)試等系統(tǒng)層面的服務(wù),而效果監(jiān)控目標(biāo)是快速發(fā)現(xiàn)產(chǎn)品嚴(yán)重影響用戶體驗(yàn)的效果問題,它和線下百度相互相成,共同提升百度對(duì)外服務(wù)的質(zhì)量。
國(guó)內(nèi)外一直有很多人把測(cè)試與質(zhì)量保證混為一談,其實(shí)測(cè)試屬于質(zhì)量控制(QC),而QA還有更多內(nèi)容,請(qǐng)談?wù)勀鷮?duì)QA和測(cè)試的理解。
徐毅:其實(shí)不管是保證還是控制,都很難達(dá)到名副其實(shí)的效果。測(cè)試做得再充分、再?gòu)氐住⒃倏焖伲矡o法把質(zhì)量給控制起來,最多只能夠更頻繁地展現(xiàn)出質(zhì)量的現(xiàn)狀。關(guān)于QA么,我曾經(jīng)在微博上發(fā)起過一個(gè)討論,還是比較熱鬧的,大家可以去看看,What is the value of Quality Manager。至于“質(zhì)量保證”這個(gè)詞,大家可以想一想,如果我跟你拍胸脯說某件事情包在我身上,我保證辦到,但實(shí)際情況是,回過頭去我得催著一撥人做這個(gè)做那個(gè)才能保證你的事情辦妥,你覺得這是你理解中的“保證”嗎? 更重要的問題在于,“質(zhì)量是什么”。如今,我們可以說質(zhì)量的外延發(fā)生了變化,已經(jīng)涵蓋了許多方面;也可以說,質(zhì)量已經(jīng)不再重要,用戶體驗(yàn)才是最重要的。溫伯格在他的《質(zhì)量 軟件 管理》書中說到“quality is value to some person”,對(duì)于不同的人來說,同一件東西的價(jià)值可以是不同的。
公直:其實(shí)一直以來個(gè)人不太喜歡把測(cè)試工程師稱呼為QA,QA一般是指質(zhì)量保證,范疇更大一些,在一淘,像過程改進(jìn)工程師、配置管理工程師都在做質(zhì)量控制的事情。單純地靠測(cè)試工程師本身也是沒有辦法控制質(zhì)量的,因?yàn)閷?duì)決定軟件質(zhì)量的還是開發(fā)工程師。這個(gè)在博客中的《Google如何測(cè)試》系列文章中提及,對(duì)于質(zhì)量來說,預(yù)防問題比發(fā)現(xiàn)問題本身更重要。質(zhì)量更多是開發(fā)人員的問題,而不是測(cè)試人員的。通過把測(cè)試工作融入到開發(fā)過程中,我們能降低那些富產(chǎn)Bug的人的出錯(cuò)機(jī)會(huì),不僅可以避免了大量最終用戶的使用問題,而且還可以極大地降低測(cè)試人員報(bào)無效Bug的數(shù)量。測(cè)試的未來在于發(fā)現(xiàn)設(shè)計(jì)和編程人員解決問題方法上的局限、思路中的狹隘和技能方面的不足,這是我對(duì)測(cè)試的理解,也認(rèn)為是以后測(cè)試發(fā)展的一個(gè)方向。
楊進(jìn):我理解測(cè)試關(guān)注的更多是被測(cè)對(duì)象上線前的質(zhì)量,而QA關(guān)注的是宏觀意義上的質(zhì)量,包括開發(fā)環(huán)節(jié)的質(zhì)量控制(如何提高代碼本身質(zhì)量)、測(cè)試環(huán)節(jié)、上線環(huán)節(jié)以及運(yùn)維環(huán)節(jié)(如線上出現(xiàn)問題后如何快速止損),甚至還包括用那種開發(fā)模式能更有效的提升項(xiàng)目開發(fā)質(zhì)量和效率,因而是一個(gè)更寬泛的領(lǐng)域。
如何衡量軟件測(cè)試的有效性?
徐毅:衡量一個(gè)東西的有效性,對(duì)我來說就看比較有無之間的區(qū)別,也就是說比較“有軟件測(cè)試”和“無軟件測(cè)試”在“效果”上面的差異,那就是有效性啦,也即是有效的程度。那么,你所期望的“效果”又是什么呢?
公直:從90年代末開始,測(cè)試進(jìn)入所謂的“Prevention oriented period ”(參見wiki)階段,強(qiáng)調(diào)2點(diǎn),第一個(gè)缺陷預(yù)防,第二就是軟件度量。就是這個(gè)問題本身(如何衡量軟件測(cè)試的有效性),如何度量你做的測(cè)試有什么收益,如何判斷你的測(cè)試活動(dòng)的有效性,無論是學(xué)術(shù)界還是工業(yè)界,好像也還沒有什么比較好的方法,特別是在國(guó)內(nèi)目前的現(xiàn)狀(人治,部門經(jīng)理或者項(xiàng)目經(jīng)理決定太多東西),度量系統(tǒng)(例如sonar)計(jì)算出的測(cè)試ROI本身可能也不一定準(zhǔn)確,人的因素變化太多。我就簡(jiǎn)單說下我們這邊判斷測(cè)試有效性做法好了,基本上還是還是從結(jié)果來看,上線失敗次數(shù)、線上故障、線上Bug幾個(gè)維度來評(píng)估測(cè)試的有效性。
楊進(jìn):要想全面評(píng)判測(cè)試的有效性是比較困難的,目前比較通用的手段是在產(chǎn)品發(fā)布以后,利用用戶報(bào)告bug的數(shù)量和趨勢(shì)來判斷測(cè)試的有效性,然后這種判斷方法需要上線后才能進(jìn)行因而顯得價(jià)值有限,上線前也有一些可參考的手段,比如UT完成后的代碼覆蓋率,測(cè)試用例完后的評(píng)審,測(cè)試報(bào)告的評(píng)審等。我自己比較喜歡手段是代碼覆蓋率,因?yàn)榇a覆蓋率是一個(gè)利用客觀標(biāo)準(zhǔn)進(jìn)行判定的方法。此外基于測(cè)試需求覆蓋率也是一個(gè)好方法。
請(qǐng)談下您對(duì)探索式測(cè)試的理解,請(qǐng)分享下這方面的實(shí)踐經(jīng)驗(yàn)?
徐毅:其實(shí)探索式測(cè)試是什么,Cem Kaner和James Bach的一些文章、PPT都已經(jīng)寫得非常清楚。
首先探索式測(cè)試是一種測(cè)試的“方式”(Way,或Approach),而不是測(cè)試“技術(shù)”(Technique),方式也即是指完成整體測(cè)試工作所選擇的辦法,而技術(shù)則是指對(duì)于局部測(cè)試工作進(jìn)行操作的方法。
其次,ET的目的在于“探索”,也即有一個(gè)明確的測(cè)試目標(biāo),但是目標(biāo)的細(xì)節(jié)或是達(dá)成目標(biāo)的步驟尚不清晰,所以需要邊走邊看,同時(shí)間地進(jìn)行學(xué)習(xí)、設(shè)計(jì)、執(zhí)行、解析的結(jié)果,與PDCA循環(huán)頗有相似之處。
第三要區(qū)分開ET和手工測(cè)試的關(guān)系。“手工測(cè)試”所強(qiáng)調(diào)的是執(zhí)行的手段,也即“手工”。而ET主要強(qiáng)調(diào)目的,也即“探索”,當(dāng)然還有就是,執(zhí)行只不過是ET中的一部分而已,而這一部分,可以借助自動(dòng)化。例如,修改某個(gè)已有自動(dòng)化測(cè)試腳本中的部分測(cè)試數(shù)據(jù),借助于腳本快速地執(zhí)行某些操作,而去掉或暫停分析部分的腳本執(zhí)行,因?yàn)榇藭r(shí)測(cè)試的結(jié)果未知,需要依賴人工來判斷、分析測(cè)試結(jié)果。
公直:探索式測(cè)試最近2年異常火爆,很多人以為是最新出的一個(gè)測(cè)試技術(shù)或者方法。Cem Kaner 在1983年(都快30年了)就提出了。這是一種強(qiáng)調(diào)個(gè)人自由與責(zé)任的測(cè)試方法,讓獨(dú)立測(cè)試人員可以借由不斷的學(xué)習(xí)來改善測(cè)試的規(guī)劃與測(cè)試的執(zhí)行,而在測(cè)試的過程中也會(huì)同時(shí)改善測(cè)試用例從而達(dá)到相輔相成的效果。在一淘這邊,其實(shí)很早就開始使用這種實(shí)踐方法了,但很多一線的測(cè)試人員并不知道自己的做法就是探索式測(cè)試,在互聯(lián)網(wǎng)研發(fā)模式下,一般都或多或少地使用敏捷模式,或者其他的土方法,但迭代周期都很短,一個(gè)月就要上線。在這樣的環(huán)境下,文檔少,在測(cè)試計(jì)劃制定設(shè)計(jì)上都不可能完善,一般在測(cè)試過程中是用freemind等腦圖工具來記錄測(cè)試執(zhí)行過程的同時(shí)做測(cè)試用例的設(shè)計(jì),這種方式可以做常規(guī)測(cè)試的補(bǔ)充。
楊進(jìn):我很喜歡探索性測(cè)試,它讓測(cè)試工作變得輕松和富有創(chuàng)造力,它能讓你無需復(fù)雜的測(cè)試準(zhǔn)備,就直接進(jìn)入最核心的測(cè)試工作,并且不拘泥用什么方法、什么工具,也不用考慮能否能被自動(dòng)化,只需要關(guān)注能否快速的找到bug就行。當(dāng)然好的探索性測(cè)試實(shí)際上對(duì)工程師的邏輯分析能力和產(chǎn)品整體理解要求很高,這種依賴于個(gè)人能力的測(cè)試手段,執(zhí)行的效果也比較難以控制。
探索性測(cè)試的實(shí)踐方面,我們之前嘗試過多人組隊(duì)測(cè)試,這種方式適用于多人進(jìn)行的大型項(xiàng)目,大家一起進(jìn)行探索性測(cè)試,bug系統(tǒng)即時(shí)顯示你在這個(gè)版本發(fā)現(xiàn)了多少個(gè)bug,并且排名,我們每天樂于尋找更多的bug,并且分享找bug的技巧,在這個(gè)過程中我們都得到了很多的成就感,并且對(duì)產(chǎn)品的理解和測(cè)試技巧也大幅提升。現(xiàn)在回想起來也還是一個(gè)很有意思的事情。
您怎么看敏捷測(cè)試,執(zhí)行后會(huì)質(zhì)量有哪些明顯的改善?
徐毅:我認(rèn)為,敏捷測(cè)試(關(guān)于敏捷測(cè)試的定義、介紹,請(qǐng)參考Lisa Crispin書中的描述)并無法單獨(dú)的執(zhí)行,必須在敏捷的環(huán)境下,結(jié)合開發(fā)人員方面的敏捷實(shí)踐(以及組織結(jié)構(gòu))齊頭并進(jìn)方可實(shí)現(xiàn)。而此時(shí),質(zhì)量的提升乃是源于軟件開發(fā)工作整體的改善,很難說一定是測(cè)試的功勞。另一方面則在于,測(cè)試本來就無法“控制”質(zhì)量,自然也無法改善質(zhì)量,因?yàn)闇y(cè)試工作本身并不改變那些可以影響質(zhì)量產(chǎn)生的因素。但敏捷測(cè)試的實(shí)踐對(duì)于質(zhì)量的提升是肯定有影響的。
● 敏捷中對(duì)于團(tuán)隊(duì)內(nèi)外參與、交流的追求,能夠更容易“do things right”
● 快速地交付和反饋,有助于做到更多地“do right things”
● 完整團(tuán)隊(duì)、跨職能團(tuán)隊(duì)等實(shí)踐,團(tuán)隊(duì)負(fù)責(zé)自己的工作方式改進(jìn),更容易做到“do things rightly”
公直:敏捷測(cè)試是一個(gè)被過度炒作的概念,和架構(gòu)師、云計(jì)算一起被大家私下稱呼“大忽悠”的工具,特別是最近幾年。傳統(tǒng)上將敏捷測(cè)試就是在敏捷研發(fā)流程下的測(cè)試,例如使用XP、或者scrum的研發(fā)流程下的測(cè)試活動(dòng),怎樣在這樣的研發(fā)背景下做測(cè)試,挑戰(zhàn)在于如何使用敏捷的流程。另外一種敏捷測(cè)試,就是按照敏捷宣言中的幾個(gè)關(guān)鍵詞,“速度快”、“反饋”、“持續(xù)”,做的測(cè)試。由于敏捷強(qiáng)調(diào)的重點(diǎn),還是在“快”上,無論中文含義的字面解釋,“敏”、“捷”其實(shí)都是快的意思,這正是自動(dòng)化程序的特長(zhǎng),機(jī)器的運(yùn)行速度總是比人的操作要快,所以我們一般在敏捷項(xiàng)目中使用了非常多的自動(dòng)化技術(shù)。個(gè)人感覺十分使用敏捷測(cè)試與質(zhì)量提升方面沒有直接關(guān)系。
楊進(jìn):我理解敏捷測(cè)試就是讓項(xiàng)目相關(guān)的角色全體直接承擔(dān)項(xiàng)目最終目標(biāo),由于都是為最終目標(biāo)服務(wù),因而角色也變得模糊,并且每個(gè)人的工作也需要考慮是否對(duì)當(dāng)前最急迫的事情,這種集中所有角色力量為共同目標(biāo)前進(jìn)的開發(fā)方式,減少了大家溝通和項(xiàng)目迭代成本,最終很容易得到項(xiàng)目整體效率和質(zhì)量的提升。由于各角色對(duì)目標(biāo)理解一致,對(duì)產(chǎn)品理解都很深入,因而可以更多的把bug消滅在開發(fā)的早期,比如單元測(cè)試、新功能測(cè)試階段,使得后期的集成和系統(tǒng)測(cè)試問題變得更少,尤其是產(chǎn)品最終的效果問題也會(huì)減少。
開源對(duì)測(cè)試的影響,如何看待測(cè)試的開放性?
徐毅:平臺(tái)、工具、框架在我看來屬于比較相同的情況,我就拿我自己的經(jīng)歷來做例子吧。在諾西的時(shí)候,我們有使用過一個(gè)叫robotframework的測(cè)試自動(dòng)化框架,它最開始是一個(gè)和諾西合作的芬蘭專家開發(fā)出來的,在諾西(當(dāng)時(shí)還叫諾基亞網(wǎng)絡(luò))最先開始使用, 而后逐步推廣,在此過程中這個(gè)框架也在不斷地更新、改進(jìn)、完善。后來在公司之外也有很多的使用者,于是開發(fā)者和諾西把這個(gè)框架開源出來,也吸引了更多的人加入到這個(gè)框架的開發(fā)中來,包括衍生工具的開發(fā),這都推動(dòng)了這個(gè)工具的廣泛使用和不斷完善。諾西作為最主要的支持者,并沒有因?yàn)殚_源而受損,反而因?yàn)檫@個(gè)開源框架龐大的用戶群體和開發(fā)者隊(duì)伍而受益頗多,有更多的人可以分享經(jīng)驗(yàn)、討論問題,也有更強(qiáng)大的開發(fā)力量提供所需的功能。不過,開源的軟件,或者開源的社區(qū)相對(duì)來說更傾向于Linux的設(shè)計(jì)理念,也即是更專注于某一個(gè)領(lǐng)域、某一塊功能,做精,而不像是Windows那樣的設(shè)計(jì)理念,強(qiáng)調(diào)易用性、一站式體驗(yàn)。這意味著,企業(yè)內(nèi)要完成所有的測(cè)試工具,可能需要和多個(gè)開源工具、框架打交道,整體上如何協(xié)調(diào)使用并不容易,需要培養(yǎng)相關(guān)方面的人才。
測(cè)試開放性,沒有特別想法,也沒啥體驗(yàn),只能憑感覺談?wù)劇€(gè)人觀點(diǎn)比較悲觀或者比較現(xiàn)實(shí)。測(cè)試就是測(cè)自己產(chǎn)品的功能、特性,讓別人知道自己的測(cè)試,也就是知道了自己產(chǎn)品的細(xì)節(jié)和特性。出于商業(yè)上的考慮,我認(rèn)為各企業(yè)恐怕會(huì)較難把最核心部分的東西拿出來公開。不過這個(gè)很可能會(huì)是一個(gè)趨勢(shì),即使拿出來的測(cè)試用例的范圍比較小而已。對(duì)于產(chǎn)品也有要求,得要是相對(duì)標(biāo)準(zhǔn)化程度比較高的產(chǎn)品,不然拿出來的測(cè)試最多別人參考一下,而無法直接使用,也無法反饋改進(jìn),意味著拿出來的那一方也無法受益,這樣的話這些測(cè)試也就等同于是“死亡的文檔”(dead documentation),沒有實(shí)效。
公直:開源意味著更多可以利用的資源,特別是在測(cè)試工具上,開源也是一種開放的心態(tài)。測(cè)試的開放性,在于比較坦誠(chéng)地把自己在怎樣的場(chǎng)景下如何去做測(cè)試給大家做個(gè)介紹。非常典型的就是Google,在James的帶領(lǐng)下,有一系列的博客、文章、工具在介紹他們的測(cè)試,介紹他們測(cè)試中遇到的問題已經(jīng)他們是怎么解決的。非常期望各個(gè)公司,無論大小,測(cè)試做的程度,都可以把自己的測(cè)試通過微博、博客、文章、公開演講等形式公布出來,畢竟這一部分不太涉及太多的商業(yè)機(jī)密或者核心技術(shù)。
楊進(jìn):測(cè)試的開放性,或者說基于某種特性測(cè)試的開放性是未來發(fā)展的趨勢(shì),原因是互聯(lián)網(wǎng)的創(chuàng)業(yè)越來越依托一些基礎(chǔ)的平臺(tái),比如iOS、Android,而就一個(gè)公司內(nèi)部而言,云的廣泛應(yīng)用也使得不同產(chǎn)品基于一個(gè)相同的基礎(chǔ),由于有了共同的基礎(chǔ),這些都表征出測(cè)試也會(huì)慢慢走向開放,從部門走向公司,從公司內(nèi)走向開源。一個(gè)好的開放性測(cè)試框架,是依托于具體測(cè)試資源,以滿足具體某種測(cè)試需求而誕生的。這種測(cè)試框架因?yàn)楹陀脩舻哪承┬枨蠼壎ㄒ蚨婺芰軓?qiáng),并且也能很好的一站式完成用戶的需求。
我們把測(cè)試當(dāng)成了質(zhì)量保證的主要手段,當(dāng)質(zhì)量低下時(shí),或者為了達(dá)到高質(zhì)量時(shí),一般的選擇都是加大測(cè)試的工作量。您怎么看?
徐毅:臨時(shí)抱佛腳,沒用。就算真要加大,同時(shí)也得加大開發(fā)的工作量,找出來的bug沒人修復(fù)的話,質(zhì)量是不會(huì)提高的,只不過是我們更加清楚自己的產(chǎn)品質(zhì)量很爛而已。
公直:測(cè)試工程師做的測(cè)試活動(dòng)一般都被稱之為是“檢測(cè)”,與之對(duì)應(yīng)的開發(fā)工程師做的測(cè)試都是在“預(yù)防”,質(zhì)量高低可以通過測(cè)試“檢測(cè)”出來,但測(cè)試永遠(yuǎn)無法提升產(chǎn)品質(zhì)量。所以,為了達(dá)到高質(zhì)量,可以做更多的測(cè)試,加大測(cè)試工作量來發(fā)現(xiàn)產(chǎn)品的缺陷并修復(fù),但對(duì)于質(zhì)量,這都是“事后”,是一種下策,不是不可以。更好的辦法,是測(cè)試前移,讓開發(fā)來做單元測(cè)試、簡(jiǎn)單的功能測(cè)試,在這個(gè)過程中會(huì)發(fā)現(xiàn)大量的問題并自行修復(fù),測(cè)試更過地關(guān)注在用戶使用上,這樣高質(zhì)量會(huì)更容易達(dá)到一些。
楊進(jìn):質(zhì)量的主體其實(shí)是Dev,試想QA完成某個(gè)被測(cè)對(duì)象的測(cè)試,它最核心的價(jià)值是什么?發(fā)現(xiàn)bug 或是證明產(chǎn)品能滿足具體應(yīng)用的需求?我選擇后者,因而如何讓Dev開發(fā)出質(zhì)量更高的代碼是每個(gè)產(chǎn)品質(zhì)量可控的測(cè)試團(tuán)隊(duì)首先考慮的事情。當(dāng)然如果當(dāng)前質(zhì)量低下的時(shí)候,一個(gè)比較快速見效的方法就是投入更多的測(cè)試,但是這不能是唯一手段,必須有人走到開發(fā)的階段,從上游逐步開始改善代碼的質(zhì)量和可測(cè)試性,否則這就是一個(gè)死循環(huán)。更多的低效投入,更多的測(cè)試和debug成本,這足以壓壞這個(gè)項(xiàng)目的所有角色,而不僅僅是QA。
工作中推薦的測(cè)試框架?使用的范疇?
徐毅:我推薦使用robotframework,它是一種基于關(guān)鍵字驅(qū)動(dòng)理念的的測(cè)試自動(dòng)化框架(也支持?jǐn)?shù)據(jù)驅(qū)動(dòng)),用于敏捷測(cè)試象限(參看Lisa的書或者Brian Marick的博客)中的Acceptance Testing。更多的信息可以參看它的主頁(yè),www.robotframework.org。最初是由諾基亞西門子網(wǎng)絡(luò)資助開發(fā)的,如今已經(jīng)開源,大家都可以使用,國(guó)內(nèi)也有許多的實(shí)踐者可以交流經(jīng)驗(yàn)。它支持多種的測(cè)試文件格式,包括HTML、CSV和文本文件,測(cè)試用例的格式主要是一個(gè)表格形式,和FIT、FitNesse比較像。然后通過內(nèi)部的機(jī)制驅(qū)動(dòng)底層的Library進(jìn)行測(cè)試,而Library可以用Python和Java編寫,目前已經(jīng)有很多現(xiàn)成的,例如Selenium、Telnet、SSH、AutoIt等。
我使用這個(gè)工具已經(jīng)很多年,覺得它非常的好用,非常貼合敏捷開發(fā)的方式,能夠支持我們的ATDD,如今它甚至已經(jīng)內(nèi)嵌可以支持BDD格式的關(guān)鍵字腳本。
公直:Selenium,主要做Web UI級(jí)別的功能測(cè)試; JUnit/GTest, 代碼級(jí)別的單元測(cè)試或者API調(diào)用級(jí)別的自動(dòng)化測(cè)試;staf/stax,遠(yuǎn)程調(diào)用,在測(cè)試環(huán)境部署自動(dòng)化中可以用到;JMeter/ab/http_load, 性能相關(guān)的測(cè)試;另外,給大家推薦一款自動(dòng)化調(diào)度的工具TOAST,http://toast.taobao.org/ ,是我們這邊的一個(gè)開源的測(cè)試調(diào)度工具,主要解決持續(xù)集成中的測(cè)試執(zhí)行。
楊進(jìn):百度內(nèi)部有一個(gè)測(cè)試工具平臺(tái),里面有百度內(nèi)部開發(fā)的很多很棒的工具和框架,后續(xù)這些工具會(huì)慢慢開源出來。大家熟知的工具中,比如:代碼覆蓋率的gcov、BullseyeCoverage(支持邏輯判斷的覆蓋率統(tǒng)計(jì)),代碼掃描工具pclint,內(nèi)存泄露檢查工具Valgrind,單元測(cè)試工具GTest,如果測(cè)試移動(dòng)產(chǎn)品,MTC會(huì)是一個(gè)好選擇
在工作中會(huì)遇到各種各樣的bug或缺陷,能否分享1-2個(gè)?
楊進(jìn):在測(cè)試分布式系統(tǒng)中,曾經(jīng)遇到過在同一個(gè)目錄下出現(xiàn)兩個(gè)同名文件的情況,導(dǎo)致系統(tǒng)直接crash掉了,這個(gè)bug讓我覺得一切皆有可能。監(jiān)控發(fā)現(xiàn)過工程師在進(jìn)行換庫(kù)導(dǎo)致流量下降的問題,這個(gè)case讓我明白bug不僅來自程序和數(shù)據(jù),也來自每個(gè)可能對(duì)線上造成影響的環(huán)節(jié)。
posted on 2012-08-01 10:24 順其自然EVO 閱讀(859) 評(píng)論(0) 編輯 收藏 所屬分類: 測(cè)試學(xué)習(xí)專欄