學習 總結 記錄=成長,！

自動化測試介紹

自動化測試(Automated Testing),，是指把以人為驅動的測試行為轉化為機器執(zhí)行的過程。實際上自動化測試往往通過一些測試工具或框架,，編寫自動化測試用例,，來模擬手工測試過程,。比如說，在項目迭代過程中,，持續(xù)的回歸測試是一項非?？菰锴抑貜偷娜蝿眨⑶覝y試人員在每天重復勞動的工作之下,，也絲毫得不到成長,。此時開展自動化測試就能夠幫助測試人員從重復、枯燥的手工測試中解放出來,，提高測試效率,，縮短回歸測試時間。一般來說,，自動化測試通常都會跟持續(xù)集成系統(tǒng)（比如Jenkins）配合使用,。

但在自動化實踐過程中，往往會發(fā)現(xiàn)理想和現(xiàn)實之間的差距很大,。自動化測試的劣勢,，主要體現(xiàn)在以下幾方面：

1. 相對手工測試，自動化測試對測試人員的要求相對較高,；
2. 測試用例需要根據(jù)版本迭代進行更新,，有一定維護成本；
3. 不能指望自動化測試去發(fā)現(xiàn)更多新的BUG,，自動化測試能發(fā)現(xiàn)的缺陷遠遠比手工測試少,；
4. 自動化測試的產出價值往往在于長期的回歸測試，短期內發(fā)揮的作用可能不明顯,；

希望借助自動化流程解決的問題

1. 測試時間緊張,，手工測試可能覆蓋不全，容易錯過某些邊界情況,；
2. 模塊間強耦合時,，單純從頁面進行測試時，比較難深入的發(fā)現(xiàn)問題,；
3. 回歸測試時,，需要投入較大的人力/工時；
4. 實現(xiàn)手工測試無法達成的測試任務,；
5. 通過編寫測試用例,，加深對業(yè)務/數(shù)據(jù)的認知，有助于下階段迭代中發(fā)現(xiàn)隱藏的問題,；

引入自動化測試的前提條件

項目周期長,，需求變動不頻繁
測試用例的穩(wěn)定性決定了自動化測試的維護成本。如果軟件需求變動過于頻繁,，測試人員需要根據(jù)變動的需求來更新測試用例以及相關的測試腳本,，而腳本的維護本身就是一個代碼開發(fā)的過程,，需要修改、調試,。如果所花費的成本不低于利用其節(jié)省的測試成本,，那么自動化測試便是失敗的。

項目中的某些模塊相對穩(wěn)定,，而某些模塊需求變動性很大,。我們便可對相對穩(wěn)定的模塊進行自動化測試，而變動較大的仍是用手工測試,。

自動化測試腳本可重復使用
如果費盡心思開發(fā)了一套近乎完美的自動化測試腳本,，但是腳本的重復使用率很低，致使其間所耗費的成本大于所創(chuàng)造的經(jīng)濟價值,，自動化測試便毫無意義。

測試任務手工測試難以實現(xiàn)
比如壓力測試,，大數(shù)據(jù)或者大量重復數(shù)據(jù)測試,，必須有自動化工具的支持。

做自動化測試需要具備的能力

• 擁有編碼能力
  至少要熟悉自動化工具/框架的代碼語言,，最好有一定的編碼能力,，同時代碼邏輯要清晰，否則不僅不能保證用例的邏輯性,、業(yè)務性與健壯性等要素,，也不能保證效率；
• 熟悉被測系統(tǒng),；
  熟悉被測系統(tǒng)對任何測試人員來說都是最起碼的要求,；
• 掌握一個自動化測試框架/工具；
  可以根據(jù)所掌握的代碼,，學習一門自動化測試的框架,，如 Selenium/Appoum/Robot Framework/Nunit/TestNG等；
• 不斷學習,，善于學習,，知其然知其所以然；
  “落后就要挨打,?！?/li>

自動化用例一般在哪個階段完成

一般落后于新功能的手工測試階段，可以在手工用例執(zhí)行完成或功能上線后,，再去補充自動化的用例,。
自動化不是跟著新需求走，而是測變化的東西對不變東西的影響,，一定不要做為了自動化而自動化的工作,。

分層自動化測試

在理解分層自動化之前,，我們先看一下經(jīng)典的測試金字塔。

• UI層：界面自動化測試,?？梢钥闯鏊膬r值最小，它最接近用戶真實場景,，也容易發(fā)現(xiàn)問題,，但它的實現(xiàn)成本最高且太容易受外部依賴，容易影響腳本成功率,?？傮w來說，適當?shù)慕缑孀詣踊瘻y試是有必要的,，但是沒有必要在UI層投入太多,；

• Service層：接口自動化測試。它的價值居中,，覆蓋大多數(shù)主要的接口是比較合適的,。這一層要求測試人員對系統(tǒng)的結構和系統(tǒng)間的調度非常清楚，同時要了解接口邏輯關系,，否則接口測試代碼很容易遺漏一些異常場景,；

• Unit層：單元測試。最有價值的測試,，但是對測試人員要求比較高,，一般由開發(fā)人員完成，否則只能采用結對編程,。
  通常來說,，手工測試是最基本的，可以做到接近100%,而對于自動化測試來說,，它更像是一件'防彈衣',，用來防護身體的主要部位。有人認為自動化率提高了,，就可以節(jié)省人力,，這實際是非常片面的，因為提高自動化率,，意味著需要投入更大的人力在維護的成本上,。因為系統(tǒng)的需求是在不斷變化的，每一個變化都會導致自動化測試用例需要更新調整,。

  所以,，自動化測試做到什么樣才算好，也要結合上面的測試金字塔來分析,。對于UI層面的自動化測試,，保證少量必要的主流程即可,，切勿在這一層面將自動化測試的'防彈衣'變成臃腫的'宇航服'；Service層面的接口自動化測試,，可以考慮覆蓋大部分的流程,；Unit層面的單測，做到100%是最好的,，即使有需求變化,，一般也很少影響到已有的用例。一般來說,，單元測試可以發(fā)現(xiàn)80%的缺陷,。

設計自動化用例的原則

基本原則

• 自動化測試用例的范圍必須是相對核心的業(yè)務流程，即覆蓋主體功能的核心測試點和重復執(zhí)行率較高的模塊,；
• 在測試腳本和被測代碼都保持不變的情況下,，測試用例的結果應該是穩(wěn)定的，這一點非常重要,；
• 除非是必要的情況,，否則任何用例都應當避免做持久化的操作，以保證環(huán)境始終是干凈的,；
• Once Written, Run Anytime as Desired ；
• 不是所有的手工測試用例都可以使用自動化測試來實現(xiàn),，自動化測試替代不了手工測試,，兩者的有效結合是保證項目質量的關鍵。
• 回歸測試場景中,，測試用例的選擇一般以正向為主,，逆向為輔；

用例設計原則

保持Case的獨立性

通常來說,，一個Test Suite下包含了一組相近的或者有關聯(lián)的Test Cases,。而每一個 Test Case 應該只測試一種場景，根據(jù)case復雜程度,，不同場景同樣可大可,，可以是某個單元的測試，也可以是端到端的測試(E2E),，當然也有特殊的寫法比如工作流測試和數(shù)據(jù)驅動,。

Case的獨立性有哪些需要關注的點呢?

首先Test Suite內的Cases在執(zhí)行時不應該相互影響，意思是說當我們有隨機的跑其中某個Case或亂序的跑這些Cases時,，測試的結果都應該是準確的,。Suite level和Directory level同樣要注意獨立性的問題。系統(tǒng)較為龐雜時,，可能會將數(shù)百上千的Cases放在一起跑,，Robot本身不會規(guī)定Case執(zhí)行的順序,，所以從某種程度上來說同一層級的Cases是隨機執(zhí)行的。很典型的情況就是,，測試用例在本地調試時怎么跑怎么過,，放到Server上所有Cases一起跑的時候就會Fail,還可能是偶發(fā)的，這種情況下就很可能是由于其他Case的痕跡影響到了它,，查找問題的根源往往比較耗時,。

保持Case的可遷移性

Case的可遷移性主要考慮三點 : Case對執(zhí)行環(huán)境的依賴 ; Case對外部設備的依賴;Case對測試對象的依賴。

Case對執(zhí)行環(huán)境的依賴
盡量減少對執(zhí)行環(huán)境的依賴,。舉一個例子,，你在本地PC上使用rf框架編寫、調試用例后,，上傳到Git,，然后你的領導可能會拉取你的用例在他的本地運行，隨后又被部署到持續(xù)集成服務器上,。所以你編寫的用例時就要盡量避免使用不同平臺的庫或者shell命令,。

再舉個例子，如果你因為業(yè)務需要而修改了測試庫源碼的話,，此時不管是組內其他人還是CI服務器,，肯定都會運行失敗，這種情況該怎么解決呢,？這里提供兩個解決方法：

1. 將修改后的庫做成測試庫,，上傳到Git或者Pypi，對方可以通過pip安裝更新,；
2. 使用robotremoteserver做一個共享庫放在遠程主機上,，具體請參考蟲師的文章；

Case對外部設備的依賴
有時為了業(yè)務測試需要,，我們會引入一些外部設備來輔助測試,，外部設備可能會持續(xù)升級或者更換，在編寫用例時我們就需要考慮如何用一套Case更好的兼容這些測試設備,。比如可以將外部設備的操作從測試用例中抽離出去,，封裝成測試庫或關鍵字；

Case對測試對象的依賴
如果測試對象是一個軟件平臺,，軟件平臺通常需要適配多種的設備,，而設備的硬件配置可能是多種多樣的：CPU、內存,、組件的性能和數(shù)量都可能不同,。對測試對象的依賴不僅要考慮在不同設備上的可執(zhí)行性，重點還要考慮測試覆蓋率。由于設備組件的增多你的用例可能無法覆蓋到這些組件,，或者捕捉不到某個性能瓶頸,，這樣測試結果的可靠性也大打折扣。

提升Case執(zhí)行效率

不同的case執(zhí)行時間相距甚遠,，短則數(shù)秒長則持續(xù)數(shù)天,。數(shù)秒鐘的簡單功能測試用例和耗時數(shù)天的穩(wěn)定性測試用例本身是沒有什么可比性的。但是我當我們放眼某一個或者某一組case時,，我們就需要重視Case的執(zhí)行效率,。不論是敏捷流程還是持續(xù)集成都講究快速的反饋，開發(fā)人員能在提交代碼后快速的獲得測試結果反饋,，測試人員能在最短的時間內執(zhí)行更大范圍的測試覆蓋,，不僅能提高團隊的工作效率，也可增強團隊的信心,。

以使用rf為例,，在編寫用例時可以通過以下方面來提高用例的執(zhí)行效率。

1.如果有對執(zhí)行條件的檢查,，若檢查失敗,，則盡快退出執(zhí)行；
2.將數(shù)據(jù)準備或環(huán)境清除等工作抽取成關鍵字放到更高的層級中,,，抽取時可能需要做一些組合, 但不允許出現(xiàn)重復的建刪操作,；
3. 用例中盡量少的出現(xiàn)sleep，建議用'wait until ...'來代替,；
4. 可以采用并發(fā)執(zhí)行用例的方法來提升效,；

自動化用例編寫規(guī)范

命名規(guī)范

Keyword命名

第一個單詞應以小寫字母作為開頭，后面的單詞則用大寫字母開頭,。 如：getProjectId, connectDB

常量命名

常量的名字應該都使用大寫字母，并且指出該常量完整含義,。如果一個常量名稱由多個單詞組成,，則應該用下劃線來分割這些單詞。 如：MAX_CHAR_LENGTH

參數(shù)命名

參數(shù)的命名規(guī)范和方法的命名規(guī)范相同,，請在盡量保證參數(shù)名稱為一個單詞的情況下使參數(shù)的命名盡可能明確,。如：${account} , ${investorName}

使用Tags

RF提供了通過在Settings中設置tags來管理用例的方法。Tag的應用非常的廣泛和靈活,，比如可以用來做用例篩選,、版本管理、統(tǒng)計策略等,。

怎么打tag看起來會更便捷,？

• 可以在各個文件夾下打文件夾名字的tag，這樣就可以根據(jù)tag單獨的跑該文件夾下的用例，查看測試報告也更好看些;
• 在一些重要的用例上打上tag,，可以單獨跑關鍵用例;
• 某些用例如果不想執(zhí)行,，可以打上tag，設置不執(zhí)行,。

image

讓case具有文檔性

在考慮Coding Style時我們可以設置一些固定的規(guī)則,大家只要按照這個規(guī)則來做,實踐幾次之后Coding Style就會趨于統(tǒng)一. 而考慮將Case寫的如同文檔一般則需要更多的主觀能動性,。

敏捷開發(fā)(Agile Development)在國內的發(fā)展已經(jīng)越完善，伴隨之而來的便是敏捷測試(Agile Testing),。敏捷思想強調以人為核心,，在整個開發(fā)流程中，只寫有必要的文檔或盡量少寫文檔,，這也是它與傳統(tǒng)的瀑布模型的差別,。

為了不造成誤解，這里有必要插入的說一下敏捷測試的幾個特點：

• 敏捷測試應該是敏捷開發(fā)的一部分,；
• 敏捷測試具有鮮明的敏捷開發(fā)的特征,，如測試驅動開發(fā)(TDD),驗收測試驅動開發(fā)(ATDD)。也就是說,，單元測試是敏捷測試的基礎,，如果沒有足夠的單元測試，就無法應對將來需求的快速迭代,，也無法實現(xiàn)快速而穩(wěn)定的持續(xù)交付,；
• 優(yōu)秀的敏捷測試是基于自動化測試的；
• 敏捷測試無時不在,，無處不在,。

需求設計不斷的更新，而文檔往往不能被很及時的更新,，那這樣的話怎么才能讓測試人員如何快速的掌握某個功能或者產品的需求和當前狀態(tài)呢?

'Tests as Documentation.'

清晰易懂的用例名

在實際的工程中,，我們可能會新建一個目錄來存儲測試點相近的測試用例。每一個Case都對應一個測試點,，而用例名則應該概括總結對應測試點的核心內容,，這樣當我們在瀏覽一組用例時,僅僅通過用例名就能大致了解里面的測試內容,也方便尋找某個Case。

清晰易懂的用例名

在實際的工程中,，我們可能會新建一個目錄來存儲測試點相近的測試用例,。每一個Case都對應一個測試點，而用例名則應該概括總結對應測試點的核心內容,，這樣當我們在瀏覽一組用例時,僅僅通過用例名就能大致了解里面的測試內容,也方便尋找某個Case,。