6.編程語言規(guī)范
廣泛地講,用于開發(fā)應(yīng)用程序的編程語言在質(zhì)量保證過程中起著重要作用。測試員經(jīng)常選擇過程語言,例如Perl,Python,Ruby等來為自動(dòng)化測試用例創(chuàng)建腳本,因?yàn)檫@些編程語言通常更容易學(xué),不需要匯編(這節(jié)省了不少時(shí)間),擁有大量用戶群和庫可供選擇以解決各種自動(dòng)化難題。使用一個(gè)面向?qū)ο蟮木幊陶Z言開發(fā)了測試腳本時(shí),自動(dòng)化經(jīng)常選用面向?qū)ο蟮恼Z言,如Java,C++,.NET等,這對(duì)于解決方案的體系結(jié)構(gòu)十分重要。除了選擇正確的工具和編程語言,測試員工分配也很重要。重復(fù)利用現(xiàn)有內(nèi)部知識(shí),經(jīng)驗(yàn)和技巧比采用新技巧更有效。
7.運(yùn)行時(shí)對(duì)象識(shí)別
功能和負(fù)載測試工具有個(gè)根本區(qū)別。功能測試工具在用戶界面層進(jìn)行,而負(fù)載測試工具是在協(xié)議層進(jìn)行的。功能測試工具的運(yùn)行時(shí)對(duì)象識(shí)別幾乎從未達(dá)到過。如果對(duì)象識(shí)別成功率低于50%,那么測試自動(dòng)化團(tuán)隊(duì)將執(zhí)行這么多解決方案以擊敗測試自動(dòng)化的對(duì)象。在負(fù)載測試中,這個(gè)問題并不重要。應(yīng)用程序變化和它們對(duì)測試腳本中對(duì)象識(shí)別的影響對(duì)于測試自動(dòng)化團(tuán)隊(duì)往往是個(gè)難題。獨(dú)特的對(duì)象識(shí)別大大降低了變化的影響并簡化了測試腳本維護(hù)。你必須了解并評(píng)估怎樣在運(yùn)行中使用特定工具進(jìn)行對(duì)象識(shí)別,如果有可能的話,獲取特定對(duì)象以便在收集對(duì)象庫中的識(shí)別性能上輕松進(jìn)行檢查。
8.數(shù)據(jù)驅(qū)動(dòng)輸入
如今大多數(shù)app都是交互式的,需要用戶在某些時(shí)候鍵入一些東西。知道應(yīng)用程序如何回應(yīng)各組輸入對(duì)于將穩(wěn)定有質(zhì)量的產(chǎn)品推向市場很有必要。數(shù)據(jù)驅(qū)動(dòng)測試幫助我們理解應(yīng)用程序如何應(yīng)對(duì)各種輸入。不是讓測試員手動(dòng)將無窮的數(shù)據(jù)組合或硬-特定代碼輸入測試腳本,而是測試基礎(chǔ)設(shè)施框架工作自動(dòng)從數(shù)據(jù)源取值,將取出的數(shù)據(jù)輸入應(yīng)用程序,驗(yàn)證應(yīng)用程序在用另一組值重復(fù)測試前反應(yīng)正確。自動(dòng)化數(shù)據(jù)驅(qū)動(dòng)測試極大地?cái)U(kuò)大了測試覆蓋面,同時(shí)減少了創(chuàng)建更多有不同變量的測試的需求。重視對(duì)數(shù)據(jù)驅(qū)動(dòng)測試的使用可以確保應(yīng)用程序是用來測試限制條件和無效輸入的。數(shù)據(jù)驅(qū)動(dòng)測試常常是基于模型的測試的一部分,具有覆蓋廣泛輸入數(shù)據(jù)的隨機(jī)性。為了確保擁有不同數(shù)據(jù)組合的測試執(zhí)行,應(yīng)該要恰當(dāng)管理數(shù)據(jù)源。所選測試自動(dòng)化工具應(yīng)該包含驅(qū)動(dòng)程序并支持多種數(shù)據(jù)格式,比如平面文件,電子表格和數(shù)據(jù)庫存儲(chǔ)。
9.結(jié)果和錯(cuò)誤日志
在測試用例開發(fā)和執(zhí)行期間,常常有必要記錄展示更多開發(fā)人員特定信息的內(nèi)容?墒菍(duì)于測試經(jīng)理來說,知道一個(gè)特定測試是通過還是失敗足夠了。根據(jù)要求,或許有必要自動(dòng)抓取失敗測試過程的截圖和錄像,讓開發(fā)員可以更輕易地再現(xiàn)問題并找出其根本原因。自動(dòng)化工具也應(yīng)該要有必要的過濾器來根據(jù)類型,文本,優(yōu)先級(jí),時(shí)間及其他重要屬性挖掘日志信息。允許從時(shí)間軸上的一個(gè)自動(dòng)化測試運(yùn)行到另一個(gè)查看日志總結(jié)并用于配置報(bào)告格式的工具也是挑選測試自動(dòng)化工具時(shí)需要考慮的功能。
10.連續(xù)測試
連續(xù)測試方法背后的中心思想是,經(jīng)常推進(jìn)代碼變化并快速得到關(guān)于這些變化對(duì)現(xiàn)有系統(tǒng)的影響的反饋。一個(gè)強(qiáng)大的測試自動(dòng)化框架應(yīng)該能夠支持團(tuán)隊(duì)合作和自動(dòng)化測試基礎(chǔ)設(shè)施組件(比如:集成開發(fā)環(huán)境即IDE,測試框架,版本控制,測試配置管理,問題追蹤,報(bào)告生成等等)的集成。連續(xù)測試以及使用現(xiàn)有質(zhì)量保證工具和技術(shù)的集成對(duì)QA流程效率非常重要。不進(jìn)行連續(xù)測試會(huì)讓缺陷有機(jī)可乘。發(fā)現(xiàn)了缺陷,要在上面放更多代碼,使得對(duì)后面所發(fā)現(xiàn)缺陷的修復(fù)更難更貴。即刻測試變化大大減少了找出缺陷的成本,因此自動(dòng)化工具應(yīng)該用每個(gè)提交觸發(fā)生成并自動(dòng)執(zhí)行相關(guān)測試或中隔一段時(shí)間執(zhí)行一次。此外,將測試集分解得更小,平行運(yùn)行測試集,自動(dòng)給正在弄已發(fā)現(xiàn)缺陷的代碼的開發(fā)員分配缺陷是獲得高質(zhì)量結(jié)果的便宜快速的方法。該方法也給開發(fā)員提供了嘗試的空間,同時(shí)從回歸保護(hù)主代碼庫。如此,測試每段代碼分支都和測試主代碼一樣嚴(yán)格。這樣一個(gè)從連續(xù)集成到新分支的應(yīng)用程序一旦建立可以幫助發(fā)現(xiàn)兼容問題并緩解后的集成。
11.定價(jià)模式
測試自動(dòng)化經(jīng)常被視作成本很高的一個(gè)主要原因是:自動(dòng)化工作是單獨(dú)完成的,與主開發(fā)工作完全分開。有效躲開阻礙測試的設(shè)計(jì)決策的后果,開發(fā)員繼續(xù)創(chuàng)建幾乎無法自動(dòng)化的軟件。有效的敏捷團(tuán)隊(duì)(團(tuán)隊(duì)中每個(gè)參與自動(dòng)化測試的開發(fā)員)打破了這些限制,自動(dòng)化測試進(jìn)入一個(gè)開發(fā)者可以在里面檢查他們的代碼的常用庫。這樣大大減少了測試自動(dòng)化的成本。有一些免費(fèi)的開源和專門的測試工具可以用來評(píng)估。選好了開源工具,有機(jī)會(huì)檢查工具評(píng)估有多穩(wěn)定以及那些工具有多快能否支持技術(shù)的新變化。對(duì)于專門的解決方案,工具的價(jià)格是證明投資和ROI計(jì)算時(shí)需要考慮的關(guān)鍵因素之一。檢查許可模式也很重要,比如按使用次數(shù)、節(jié)點(diǎn)、站點(diǎn)許可證、有效期等支付。另一個(gè)需要重點(diǎn)考慮的是加載項(xiàng)、支持和更新的可用性以及這些功能是否需要額外花費(fèi)。后也是重要的一點(diǎn),所選工具的易用性。工具的復(fù)雜度應(yīng)該和測試團(tuán)隊(duì)接受新工具的能力,公司的編程能力相匹配。
版權(quán)聲明:本文出自SPASVO澤眾軟件測試網(wǎng):http://xmdc.net/news/html/201535152658.html
原創(chuàng)作品,轉(zhuǎn)載時(shí)請(qǐng)務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明,否則將追究法律責(zé)任。