想漲薪的同鞋，都想搞錢，你做好搞錢的準備了嗎？直接進入正題吧

小黃雞歡迎同學前來面試自動化篇

引言：自動化永遠是避不開的，反正你入職的崗位要不要用自動化，你必須得會一點，加分項。這一塊包括，自動化一些理念和自動化的工具使用。

理念和概念

1.如何看待自動化和手動測試？怎樣的一個比例才是健康的？

曾經有專案已經實現了80%+的自動化，但是考慮到專案迭代週期短（還有個別業務場景），自動化還是成了輔助和迴歸（實際迴歸還是手工為主的）。而且個別新功能一新增，導致測試程式碼邏輯需要大調整，在測試人員不足的情況下（比如PM每日安排量化手工測試任務的時候，就需要你自己擠時間改程式碼），真的很無奈。不過做自動化還是能學到不少東西的，只是PM和QA Manager都要考慮投入產出比，所以測試人員少的小專案不少還是會回到手工為主，學自動化反而成了激勵組員的手段。 

2.自動化測試用例的覆蓋率多少？

1.不是覆蓋所有手工測試用例

2.從手工用例中選取核心用例進行優化改寫，形成自動化測試用例

3.覆蓋率是績效考核範圍，建議爭取領導支援適當降低期望

3.完整執行一次自動化用例需要多久時間？

這個要根據自動化的所測試到的模組以及用力條數去進行分析，可以簡單的列下你們公司每次執行自動化一個具體的時間進行回答

4.什麼是分層自動化？

分層的自動化測試倡導產品的不同層次都需要自動化測試，這個金字塔也正表示不同層次需要投入的精力和工作量。

其中Unit代表單元測試，Service代表服務整合測試，UI代表頁面級的系統測試

5.你的測試資料是怎麼準備的？

首先看資料的來源，資料的來源一般來講有三個個，一個是根據被測系統需求的分析，針對正常業務，異常情況，邊界情況等來構建完整的資料，又稱為“造”資料。這不僅僅包括最基本的基礎資料，比如：使用者、許可權、配置、基礎編碼、原資料等，還包括上面提到的業務資料。這對於比較小型的系統來說還是可行的，對於大型的系統來說可能就是一個巨大的工程了。 第二種方式就是利用現有系統，這適合已有類似系統，測試是針對升級或者增加功能的產品化的系統。這種情況把已經在生產環境中執行的資料匯出。在此基礎上再進行資料的整理、加工為測試資料。 還有一種方式就是將現有非電子化的業務資料錄入到系統中，在驗證業務的同時也完成了測試資料的積累。即邊測試邊積累資料。但是這種情況積累的資料往往有一定侷限性，因為已經發生的業務資料基本是正確的、一致的，而且可能缺少某些特定業務的資料（不常發生的業務）。這樣就需要根據對測試需求的分析，追加新的測試資料，以便能完整覆蓋業務型別。 確定好資料來源後，還需要對已有資料進行分析、驗證、檢查，保證資料的質量，資料的質量一般要滿足測試需求、覆蓋被測業務、覆蓋測試邊界，以及要滿足完整性、一致性等要求。檢查完後要整理和完善資料，清除無用和冗餘的資料、補錄不完整的資料，修改一些錯誤的資料。 經過整理好的資料要納入配置管理，以後根據需求和變更要進行資料的維護和更新，以保證滿足系統測試的要求

6.測試指令碼的維護成本是怎麼樣的？

自動化測試的必要性就不再多做闡述,使用QTP毋庸置疑是為，降低測試成本,提高測試效率。或許剛剛入門的朋友都會覺得QTP使用很簡單，基本上不用培訓就能直接上手操作。但是其實不然，長期做自動化的朋友們或許就能明白QTP有一難點，那就是指令碼維護。

一個龐大的測試專案必然包含了大量複雜的測試指令碼，如果說對於指令碼的管理沒有一個好的制度，那麼隨著程式的頻繁更新，指令碼的反覆執行，這些指令碼必將步履維艱！

比如說相容問題，如果專案組提出新需求,要求我們的產品支援最新版本的IE。而我們當初錄製的IE是舊版的，那麼在新版的IE上執行這些指令碼時可能就困難重重，甚至是寸步難行。

再比如，按照業務的操作流程，我們在測試時都會遵循新增再刪除的方式去執行系統交易，但是由於更新上來的程式在處理刪除時出錯，於是，出現了新增成功，刪除失敗的尷尬局面。我們都知道,在每次迴歸測試時,都要執行自動化指令碼，所以在這種刪除失敗的情況下，再次執行指令碼就出現了同樣的資料新增兩次的情況。因此，毫無疑問，這種操作必將以失敗而告終，此時，只有一種方法去解決這個問題了，那就是我們手動去刪除已經新增成功的資料。大家可以想象，在成百上千的測試案例中，如果出項大量這樣的指令碼我們要怎麼去維護呢。不要說去發現問題，我們的主要任務估計就會被迫轉向除錯指令碼了。

7.自動化測試工具有哪些

QTP全名HP QuickTest Professional software ，最新的版本為HP QuickTest 

Professional 11.0QTP是quicktest 

Professional的簡稱，是一種自動測試工具。使用QTP的目的是想用它來執行重複的手動測試，主要是用於迴歸測試和測試同一軟體的新版本。因此你在測試前要考慮好如何對應用程式進行測試，例如要測試那些功能、操作步驟、輸入資料和期望的輸出資料等QuickTest針對的是GUI應用程式，包括傳統的Windows應用程式，以及現在越來越流行的Web應用。它可以覆蓋絕大多數的軟體開發技術，簡單高效，並具備測試用例可重用的特點。其中包括：建立測試、插入檢查點、檢驗資料、增強測試、執行測試、分析結果和維護測試等方面。

WinRunnerMercury 

Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程式是否能夠達到預期的功能及正常執行。通過自動錄製、檢測和回放使用者的應用操作，WinRunner能夠有效地幫助測試人員對複雜的企業級應用的不同釋出版進行測試，提高測試人員的工作效率和質量，確保跨平臺的、複雜的企業級應用無故障釋出及長期穩定執行。企業級應用可能包括Web應用系統，ERP系統，CRM系統等等。這些系統在釋出之前，升級之後都要經過測試，確保所有功能都能正常執行，沒有任何錯誤。如何有效地測試不斷升級更新且不同環境的應用系統，是每個公司都會面臨的問題。

Rational 

Robot是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高階指令碼技術之前幫助其進行成功的測試。它整合在測試人員的桌面IBM 

Rational Test 

Manager上，在這裡測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。這種測試和管理的雙重功能是自動化測試的理想開始。

QA 

RunQARun的測試實現方式是通過滑鼠移動、鍵盤點選操作被測應用，即而得到相應的測試指令碼，對該指令碼可以進行編輯和除錯。在記錄的過程中可針對被測應用中所包含的功能點進行基線值的建立，換句話說就是在插入檢查點的同時建立期望值。在這裡檢查點是目標系統的一個特殊方面在一特定點的期望狀態。通常，檢查點在QARun提示目標系統執行一系列事件之後被執行。檢查點用於確定實際結果與期望結果是否相同。

Test 

Partner是一個自動化的功能測試工具，它專為測試基於微軟、Java和Web技術的複雜應用而設計。它使測試人員和開發人員都可以使用可視的指令碼編制和自動向導來生成可重複的測試，使用者可以呼叫VBA的所有功能，並進行任何水平層次和細節的測試。TestPartner的指令碼開發採用通用的、分層的方式來進行。沒有程式設計知識的測試人員也可以通過TestPartner的視覺化導航器來快速建立測試並執行。通過可視的導航器錄製並回放測試，每一個測試都將被展示為樹狀結構，以清楚地顯現測試通過應用的路徑。

更多文章請關注作者微信公眾號：城事十則