自動化測試輔助軟體迭代

1. 常用的自動化測試工具及特點分析

想要進入 自動化這行業，知道常用的自動化測試工具及特點相當關鍵。下面就由我為你帶來常用的自動化測試工具及特點，希望你喜歡。

常用的自動化測試工具及特點
1、RunnerMercury

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

2、Rational

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

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

3、AdventNet

QEngineAdventNet QEngine是一個應用廣泛且獨立於平台的自動化軟體測試工具，可用於Web功能測試、web性能測試、Java應用功能測試、Java 、API測試、SOAP測試、回歸測試和Java應用性能測試。支持對於使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、傳統客戶端/伺服器等開發的應用程序進行測試。此工具以Java開發，因此便於移植和提供多平台支持。

4、SilkTest

是業界領先的、用於對企業級應用進行功能測試的產品，可用於測試Web、Java或是傳統的C/S結構。SilkTest提供了許多功能，使用戶能夠高效率地進行軟體自動化測試。這些功能包括：測試的計劃和管理;直接的資料庫訪問及校驗;靈活、強大的4Test腳本語言，內置的恢復系統(Recovery System);以及具有使用同一套腳本進行跨平台、跨瀏覽器和技術進行測試的能力。

5、QA

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

6、Test

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

7、Holodeck

強大的故障植入軟體測試工具Holodeck is an advanced fault-injection

tool that gives you the power to attack an application while it monitors and

logs everything your application does - every function call, registry entry,

piece of data read or written.

8、Telelogic

TAUTAU第二代包含三個最新的、最強大的技術用來加速大規模軟體開發和測試：統一建模語言(UML)及它的許多最新修訂版本中的特性，UML2.0;功能強大的測試語言TTCN-3和新的構造系統的方法：Model

Driven Architecture(模型驅動構架)。這三個新的業界標准結合成TAU的已經過認可的軟體開發平台，形成了一個系統，一個一流的穩定可靠的工具解決方案。TAU第二代是系統與軟體開發解決方案的一個突破，它把業界從使用了太長時間的手工、易出錯、以代碼為中心的方法中釋放出來，自然而然地邁向下一步，一個更加可視化、自動化及可靠的開發方法。

9、TelelogicTAU/Tester

是基於通用測試語言TTCN-3,用於自動化的系統和集成測試的強大工具。TAU/Tester以現代化的開發工具為基礎，提供高層測試功能，支持整個測試生命周期，加速自動化測試。TAU/Tester可使用戶特別關注於測試的開發，因為TTCN-3語言是獨立於開發語言或測試設備的，且是抽象和可移植的。
Android手機自動化測試工具
1、Monkey是Android SDK自帶的測試工具，在測試過程中會向系統發送偽隨機的用戶事件流，如按鍵輸入、觸摸屏輸入、手勢輸入等)，實現對正在開發的應用程序進行壓力測試，也有日誌輸出。實際上該工具只能做程序做一些壓力測試，由於測試事件和數據都是隨機的，不能自定義，所以有很大的局限性。

2、MonkeyRunner也是Android SDK提供的測試工具。嚴格意義上來說MonkeyRunner其實是一個Api工具包，比Monkey強大，可以編寫測試腳本來自定義數據、事件。缺點是腳本用Python來寫，對測試人員來說要求較高，有比較大的學習成本。

3、Instrumentation是早期Google提供的Android自動化測試工具類，雖然在那時候JUnit也可以對Android進行測試，但是Instrumentation允許你對應用程序做更為復雜的測試，甚至是框架層面的。通過Instrumentation你可以模擬按鍵按下、抬起、屏幕點擊、滾動等事件。Instrumentation是通過將主程序和測試程序運行在同一個進程來實現這些功能，你可以把Instrumentation看成一個類似Activity或者Service並且不帶界面的組件，在程序運行期間監控你的主程序。缺點是對測試人員來說編寫代碼能力要求較高，需要對Android相關知識有一定了解，還需要配置AndroidManifest.xml文件，不能跨多個App。

4、UiAutomator也是Android提供的自動化測試框架，基本上支持所有的Android事件操作，對比Instrumentation它不需要測試人員了解代碼實現細節(可以用UiAutomatorviewer抓去App頁面上的控制項屬性而不看源碼)。基於Java，測試代碼結構簡單、編寫容易、學習成本，一次編譯，所有設備或模擬器都能運行測試，能跨App(比如：很多App有選擇相冊、打開相機拍照，這就是跨App測試)。缺點是只支持SDK 16(Android 4.1)及以上，不支持Hybird App、WebApp。

5、TestWriter是上海博為峰結合多年為企業做測試服務的經驗所研發的一款具有自主知識產權的自動化測試工具，跨Web、Android、iOS三大平台，為企業用戶提供真正的低成本、高效率的自動化測試，引領軟體測試自動化運用由技術層面向業務層面轉變。用戶可在TestWriter中通過統一圖形化界面輕松創建測試計劃，並驅動執行引擎完成自動化測試任務，有效降低了測試人員能力要求及腳本維護工作量，讓自動化測試更簡單，更專注於業務。
app自動化測試工具
Monkey Runner

Monkey Runner是AndroidSDK提供的測試工具。嚴格來講Monkey Runner它其實就是一個Api工具包，它是比Monkey強大，用它是可以編寫測試腳本來自定義數據、事件。唯一不足的是腳本用Python來寫，對測試人員來說要求較高，它的學習成本也是比較高的。

Monkey

Monkey是AndroidSDK自帶的測試工具，它在測試過程中會向系統發送偽隨機的用戶事件流，比如一些按鍵輸入、觸摸屏輸入、手勢輸入等)，它可以實現對正在開發的應用程序進行一個壓力的測試，同時也是有日誌輸出，實際上該工具只能做程序做一些壓力測試，由於測試事件和數據都是隨機的，並不能自己自己定義，這也是它的局限性所在。

Ui Automator

Ui Automator這個工具也是Android提供的自動化測試框架，基本上支持所有的Android事件操作，對比Instrumentation它不需要測試人員了解代碼實現細節(可以用Ui Automatorviewer抓去App頁面上的控制項屬性而不看源碼)。

它是基於java，因此它的測試代碼結構比較簡單、編寫也是比較容易、學習成本，可以是一次編譯，所有設備或模擬器都能運行測試，能跨App。它的缺點是只支持SDK16(Android4.1)及以上，不支持HybirdApp、WebApp。

Espresso

我們聽說過的Espresso是Google的開源自動化測試框架。它是相對於Robotium和UIAutomator，它最主要的特點就是規模是更小、更加的簡潔，並且API是更加的精確，編寫的測試代碼簡單，由於是基於Instrumentation的，因此是不能跨App。

Appium Android自動化框架

這個框架是iOS，android自動化測試的一個框架。它是可以支持多種的語言：Java，C#，Ruby也是可以支持。並且是還可以去調用selenium的API，所以一般是可以利用selenium來測試在手機上面的網頁應用。

研究過appium，它不僅是支持雲計算服務，還可以為客戶提供許多虛擬手機來測試，這塊不過是付費的。如果你想要的要求越多，你就必須付更多的費用，這是它的特點所在。

軟體自動化測試的工具是比較多的，不同的軟體也是有它的不同的特點，功能上的差異，如何深入了解這些工具並且是合理的使用，這是我們需要做的事情。

猜你還感興趣的：

1. ios自動化測試框架有哪些

2. 軟體QTP自動化測試

3. ios自動化測試流程

4. ios自動化測試工具有哪些

5. 常用的自動化測試工具及流程

2. 互聯網公司的軟體測試工程師們都在干什麼

互聯網和傳統行業的不一樣，變更多，迭代快，測試工程師們能大噶說一下嗎？還有，怎麼樣才能提高自己的價值呢？ 精彩答案： 會員jijiting： 拋磚引玉，了解皮毛而已。 測試要做的是，檢測和監控產品的質量，提高測試效率，優化測試流程，改善評測辦法，為產品的改進和上線提供保障。 測試工程師大概在做： 1、功能測試：包括和開發、產品確認產品需求，做測試計劃，設計測試用例，做測試用例評審，做冒煙測試或者准入測試，執行測試用例，多輪迭代測試，一直跟蹤到上線之後的回測，以及看下用戶的反饋，確認測試過程中有沒有遺漏（算作是KPI的一部分）。在這個過程中，可以反思自己的疏漏，完善測試的流程，完善測試的檢查點，增加各種類似的測試，思考可以自動化的部分並實現。 2、自動化測試：對界面、介面或者後台進行自動化的測試，在測試的前期可以保障基本功能的正常，在測試中期可以保障開發的修改沒有對產品質量引起嚴重問題，在測試的後期可以做上線前的回歸測試，上線之後可以作為日常的監控。自動化的測試在不同平台、不同操作系統、不同瀏覽器下使用不同的工具，採用不同的框架，所以在沒有這些的時候需要調研目前行業內比較流行的解決方案，尋找到適合自己產品的方法來解決問題。之後開始設計測試用例，並進行實現。產品的改進過程中需要進行維護，保證隨時都可以通過。 3、性能測試：測試產品的性能，在多大的壓力下可以滿足當前預期的用戶請求。需要使用各種壓力工具，做壓力文件，安排與線上一致的測試機器或者精簡後的環境進行測試，對測試出來的數據進行分析，確認現有的系統是否存在問題。貌似環境部署可能是個問題，所以公司裡面會有大牛做一些自動部署的工具，甚至會開發出一些獨立的平台來完成多台機器的部署工作，可以節省很多的時間。測試出來的數據跟產品以及開發人員確認，也可能會找到一些方案來解決。 4、測試開發：相對來說開發的工作比一般測試工作要多一些。開發一些自動化的測試的平台，比如一些評測系統，供人工評測試用；設計一些測試框架，來滿足日常自動化以及性能測試的需要。制定持續集成測試的平台和方案並且實現，結合自動化的測試實現人工測試之前的自動化測試實現，對開發的代碼進行監控，跟蹤並盡量幫開發改進產品質量等等。這塊我比較白，還在仰視階段。接受其他測試人員的需求，開發合適的工具來提升整體測試效率，改進測試方法。 5、測試工具以及測試理念的推進。測試在大多數人看來還是比開發要差一些的，測試工具還可以，能夠直接快速的反映出測試人員的價值，但是更多的功能測試、性能測試還需要跟開發去溝通，讓他們意識到測試的重要性，但是最重要的還是要提升測試自己的工作能力，嘗試影響開發人員並且和開發人員一起，最終提升產品的質量。 6、測試人員還是要多學習吧。要是覺得測試是個人都可以做的就別來趟這個渾水了。 會員 姜雷： 我當時是做實習生，實習生的時間比較自由，也沒有具體的產品、KPI捆綁，所以我做的主要是沒有具體產品關聯的長線項目。比如說自動測試平台的搭建，測試自動化輔助工具的開發，原有測試腳本的集成、改寫、自動化等工作（比較雜，有些隨性，我甚至寫過單元測試——這個應該是dev做的）。還有就是一些具體的模塊覆蓋率的提高、測試自動化的探索。 具體到身邊的入職同事們，工作就比較雜了。忙起來的時候，是黑盒、白盒；自動化、手動的都要做。項目上線之前的功能、性能、壓力測試等都是必要做的，由於目前國內互聯網發展較快，項目改進迭代的壓力很大，所以有的時候感覺身邊的同事都被項目糾纏得忙——這就是為什麼上下一心都覺得自動化很重要。 當然，還有些人專門做測試工具的開發和測試流程改進的探索，我當時所在的部門也開發了很不錯的自動化測試工具——這應該是我接觸過的最接近開發的測試開發人員了。 我實習的組測試人員比較主動，去做了一些項目敏捷化的探索，還主導了項目的敏捷化，但是開發人員那邊跟進得並不是很積極——我個人認為這個應是開發人員主導的，而且整個團隊都參與進來，各個人員的角色需要有交叉——可惜我在實習期間沒有體驗到這些，這個在形成了一定的規模的國內公司估計很難改變。我實習結束的時候，有些組在流程上已經非常敏捷、自動化了，但是畢竟是上線的產品，自動化的初期肯定有一定的陣痛，估計現在應該好多了。 另外，談談我個人的一些感受，如果專門做測試的話，我覺得最大的問題就是成就感的問題。你做的似乎永遠只能是內部使用的東東，永遠不會成為呈現在用戶面前的產品（gtest等測試框架產品除外）。當一個項目上線以後，你得到的relief多一些，但是成就感相對少一些。 我只是從實習生的角度談的。

3. 自動化測試的成本高效果差，那麼自動化測試的意義在哪呢

本文章出自【碼同學軟體測試】

碼同學公眾號：自動化軟體測試

碼同學抖音號：小碼哥聊軟體測試

01 關於問題本身

我覺得這個問題帶有很強的誤導性，是典型的邏輯陷阱之一。 「自動化測試的成本高效果差」是真的嗎？ 當然不是。而且我始終相信，回答問題的最好方式是把問題本身弄清楚。也就是問關於問題的問題。樓主也學可以進一步 說明下面幾個問題，有助於自己理解自己的問題，更有助於問題得到准確的回答：

請定義「自動化測試」的范疇。 自動化測試簡單來講，包括用例的撰寫，代碼的實現，環境的搭建，用例的執行，報表的生成，結果的分析，缺陷報告等等 。每個項目自動化程度不一樣，測試人員對自動化的理解有偏差，實際實行自動化的范疇差別很大

請定義「成本「包括哪些

請定義什麼是「高」。 高是相對的。比較對象可以是另外的項目或者項目組，也可以是他人的期望

請定義什麼是「效果」
請定義什麼是「差」。 差也是相對的，可以是同手工測試比較，也可以是同老闆的期望比較

如果樓主仔細思考並且回答了以上的問題，我有七成的把握樓主要麼不想問這個問題，要麼想換個問題。

換一種問法

好吧，為了避免灌水嫌疑，我且以最大的善意揣摩樓主的意圖。樓主是想問：

如果有的項目的自動化測試，我們發現成本高於預期，效果不符合預期，那麼問題可能出在哪裡？怎麼判斷自動化測試是否有效？

02 這里是正文開始

關於錯誤的預期

我一點都不奇怪有人會告訴我說：

我都不知道我或者我的老闆對自動化測試有什麼預期，沒人跟我說過。

或者：
自動化不就是不用手工測試了嗎？用例用代碼實現都能自己跑，測試人員就可以去干別的了，可以少招幾個不產生價值的測試攻城獅了。老闆就是這樣計劃的。

這是兩種非常典型的關於自動化測試的預期問題：

每個人對自動化測試理解都不一樣，每個項目組做自動化的方式都不一樣。我講個故事，是我認識之前一個印度自動化項目的真實例子。這個項目95%以上的測試場景都是比較復雜的UI測試（Web +Windows Application）他們的自動化是這樣做的：

你覺得這個自動化做的怎麼樣？我當時的感覺是幾乎要吐血了，因為這個項目是我要接手的。更加吐血的還在後面，這個部門的QA的VP對自動化測試的效果很不滿意（絕對的），他的設想包括：

免費領取 碼同學軟體測試 課程筆記+超多學習資料+完整視頻+最新面試題，可以 轉發文章 + 私信「碼同學666」獲取資料哦

這個就是一個典型的 不懂自動化的團隊+期望脫離現實的老闆 。

關於什麼是自動化

James Bach 曾經在一篇博文提到，自動化測試這個名字是非常有誤導性的。它讓一般的人誤以為就是測試完全被自動化了，就像一個自動的咖啡機一樣，我只需要把杯子放在那裡，按一個button就夠了。James說更加准確的叫法應該是「工具輔助的測試」。當然他還有另一層意思，就是 好的測試用例是沒有辦法100%被自動化的 ，測試人員的經驗，邏輯判斷和 探索 性的測試方法都不能被有效自動化。

我非常同意這個觀點。作為這個論斷的補充和擴展，自動化應該是審視軟體研發活動的每一個環節，去發現那些可以被工具化自動化的重復性活動，然後去實現。廣義的自動化應該包括但不限於以下環節：

一個過於簡化的公式可以這樣寫：

自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本

或者如果假設迭代次數和維護次數近視相等，這個在某些情況下可以成立，比如一個比較新的產品：

自動化的收益 = 迭代次數 * (全手動執行成本 - 維護成本) - 首次自動化成本

解讀：

自動化的收益與迭代次數成正比
自動化收益可能為負數：即當自動化成本和維護成本比手動執行成本還高時

很多時候自動化成本並不比手動成本高，但是維護成本很高

為什麼強調過於簡化，因為這里的自動化收益僅僅考慮時間和資源成本的節省。 好的自動化帶來的迭代周期的縮短，是可以縮短項目周期 ，在某些時候能變不能做為能做，進而帶來的機會收益是巨大的，也是很難量化的。這個就要求決策者對軟體工程和自動化有比較正確的直覺和理解。片面追求自動化的資源節省，或者要求精確量化自動化的收益，本人覺得都不可取。

推論1：什麼項目適合自動化

從ROI的簡化公式可以看出，下面幾中情況比較適合自動化：

回歸測試為主的Support Engineering項目，即需要長期做支持維護的產品。或者有過去版本需要長期做支持維護的產品。這種產品（比如企業軟體，操作系統等）一個版本在發布之後往往需要支持好多年，做bug fix和patch。這個時候每次小版本的開發都會增加迭代次數，並且每次產品變動都非常有限，維護成本相對偏低，自動化收益就非常好。這也是很多企業級軟體或者硬體產品有專門自動化團隊的原因。因為產品的支持維護開發的回歸測試基本靠自動化。

介面比較穩定的產品，同上
手動測試特別費時費力，甚至無法達到測試目的的項目。比如壓力測試，大數據或者大量重復數據測試，必須有自動化工具的支持。

推論2：自動化的介入時間點

同樣從ROI的簡化公式推斷出，一個項目的初期可能不太適合自動化。因為項目初期用戶界面和介面沒有穩定，自動化代碼會被動的被要求頻繁改變，維護成本非常高。自動化收益不好。而反而手動測試能夠快速發現問題，反饋給開發人員。而到了項目後期和維護期，自動化再介入為回歸測試做准備，可以最大化自動化收益。

推論3：自動化的程度和自動化率

這里自動化的程度是指整個軟體研發活動中引入自動化的程度。推論2中說，有些項目早期可能不太適合高度自動化，但是項目早期仍然可以選定某些環節進行自動化。比如穩定的公用介面，軟體的編譯和部署，環境的搭建等從一開始就比較穩定的部分。

自動化率同樣也要看產品和項目的特性 ，對於產品的UI部分如果會頻繁改動，可以做比較低的自動化。對於介面比較穩定的服務組件可以提高自動化率。

你有什麼樣的團隊 ，工具和基礎設施，其實這個因素是做所有事情都必須考慮的。自動化測試本身就是軟體開發。好的自動化測試框架，架構設計很重要。這些會決定自動化的開發成本和維護成本。這些都要求很強的開發能力。如果你的團隊只有很有限的開發能力，那麼怎麼去做自動化，是做最原始的錄制回放，還是數據驅動。復雜自動化也需要良好的基礎設施支持。比如你有很好的DevOps的虛機管理系統，就不用自己去開發，省下的資源和人力也是很可觀的。

工具是另外一塊 ，如果公司有實力支持商業測試軟體和管理軟體，就可以降低編程要求（當然這會帶來一些其他問題）。如果沒有辦法用商業工具，只能考慮開源和自己開發，這個對自動化測試開發的能力要求就高。總之必須選擇和團隊，技能儲備，基礎設施與工具匹配的自動化策略。

管理層的理解程度和支持

這個就不再展開。我見過很糟糕的情況，一個帶好幾百人兼顧產品技術的VP，越3到4級直接給測試團隊提技術需求和建議。你說是做還是不做，怎麼做？還有一個團隊，自動化測試人員從來沒有寫過Java或者其他OO語言的程序，被要求從頭設計自動化框架，那就是一場災難。還有一個團隊，管理層幾次要求更換自動化工具，相當於整體重寫自動化腳本。

總結

以上應該是一個很粗淺的回答。自動化測試是一個很專門化的領域，自動化測試又是對工程師的技術廣度深度要求很高的工作。對於團隊管理和決策者來講，請不要簡單化和孤立看待自動測試。最重要的是確保聽取真正理解產品，團隊和自動化測試的技術人員的判斷。

END

本文著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並註明出處。

4. 如何預估迭代中測試的排期

想要預估測試的排期，那就要先了解下測試的工作量都在哪裡。由於我們是預估迭代中的排期，所以像一些自動化測試開發等弱迭代性的工作就不會考慮了。

以下我們就針對測試具體的工作量來分析，所有時間的預估都是以2周一迭代&1個QA為標准（個人經驗，歡迎討論）：

開始時間和結束時間應該和需求確認過程同步，但往往在需求完全定好後還會有少量的消化時間來服務之後的測試用例編寫 - 0.3d

編寫測試用例我認為就是需求的再確認及拆解，最後落在紙面上供RD和QA使用 - 1d

測試用例是要QA、PM、RD一起評審的，評審過程中有時會發現需求歧義導致需求的變更優化，這個時間也需要考慮到 - 0.5d

考慮范圍應包括但不限於：線上環境&測試環境，功能，性能，介面，埋點，ios&android，低版本ios兼容（如ios8），web，新舊版本兼容，數據遷移...

這是佔比最大的時間，排期的預估應以測試用例為依託，由於每一個迭代的業務需求不同，時間會有所浮動 - 2d～3d

* 測試人力資源多少可直接影響排期的預估

由於集成新功能有可能會影響老服務，需要按優先順序回歸下老功能 - 1d

* 如果配以卓有成效的自動化測試輔助，時間會縮短甚至大幅縮短。

缺陷的回歸往往會成為吃時間的怪獸（比如修改缺陷再次引入新的缺陷），尤其在項目工期緊或者倒排工期的時候。所以這個時間不容小視 - 1d

測試報告產生時間排期，相對固定 - 0.5d

浮動項目，時多時少，可根據實際情況修改排期或根據經驗提前預估排期 - 0.3d

浮動項目，根據業務時多時少，可根據實際情況修改排期或根據經驗提前預估排期 - 0.1d

浮動項目，時多時少，可根據實際情況修改排期或根據經驗提前預估排期 - 0.3d

5. 一般大公司UI自動化測試使用什麼工具呢

1、Selenium：該軟體是一個用於Web應用程序測試的工具。其測試直接運行在瀏覽器中，支持的瀏覽器包括IE、Mozilla Firefox、Mozilla Suite等。支持Net、Java、Perl等不同語言的測試腳本。

2、Soapui：SoapUI是一款開源測試工具，通過soap/http來檢查、調用、實現Web Service的功能/負載/符合性測試。可快速的幫助用戶進行http的介面測試，並且還支持進行檢查，監控、符合等功能。

3、Robot Framework：該軟體是一款python編寫的功能自動化測試框架。具備良好的可擴展性，支持關鍵字驅動，可以同時測試多種類型的客戶端或者介面，可以進行分布式測試執行。主要用於輪次很多的驗收測試和驗收測試驅動開發。

4、QTP：該軟體提供符合所有主要應用軟體環境的功能測試和回歸測試的自動化。採用關鍵字驅動的理念以簡化測試用例的創建和維護。它讓用戶可以直接錄制屏幕上的操作流程，自動生成功能測試或者回歸測試用例。

5、Jmeter：JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現；可以用於測試靜態或者動態資源的性能（文件、Servlets、Perl腳本、java對象、資料庫和查詢、ftp伺服器或者其他的資源）。

6. 迭代測試是什麼意思

問題一：軟體測試中，版本和迭代有什麼區別？ 跪求高手指點 其實個人覺得沒什麼差別的，只是說法不一樣，都是一個大型的項目，在分成不同的模塊，不同的時期來一步步完成，每一次迭代都是一次循環，就拿你要做一個大型網站需要一年做完，但是第一個版本就是只做登錄注冊，然後測試，這個版本完成了，繼續下一次的迭代，希望幫到你

問題二：招聘「軟體測試工程師」信息中，參與計劃版本和迭代版本測試是什麼意思 這句話到底有哪裡不清楚呢？
「參與測試」 這個 理解吧，別說不知道什麼叫軟體測試……那死了……
「參與 版本測試」 也能理解吧，是說不是單元測試，不是集成測試，是版本測試。
「參與 計劃版本 和 迭代版本 測試」，也就是說參與2 個版本的測試。
以上有什麼不懂的 追問吧，我准備給你寫本書。
這句話里唯一可能不清楚的 就是 什麼是計劃版本，什麼又是迭代版本。
這兩個概念是 敏捷開發里的（別的開發模式里也有用到，而且都概念一樣），
先說計劃版本，一般認為就是一個大的階段，時期最後出來的軟體版本。多以一年半年，為單位，也有幾年的。
迭代版本，就是小的 階段，由於敏捷開發要求每個最小階段，合入的代碼都要保證當前編譯的版本可用，所以，這個可用要經過測試，也就是迭代版本，一般以周（或2周），長的一個月左右為一個迭代版本，而這個一個一個小階段的開發過程被稱為迭代過程。
同樣是版本測試，計劃版本和迭代版本測試起來有哪些不同呢，因為迭代版本發布很快，無法在一個迭代中對全部內容進行完整的測試，所以迭代版本測試是有重點的，迭代關注修改和新開發內容，而次要關注沒有改變的內容。
計劃版本測試則是全面的，細粒度的完整性測試。

問題三：如果遇到版本迭代 怎麼測試 怎麼編寫測試用例? 1 准備一份關鍵業務測試用例.(主要業務場景) 每次版本迭代需要測試
2 將增加的功能 修改的功能對應修改用例..並進行修改對應的測試. 其中需注意修改點影響涉及到的功能.

問題四：每個版本的迭代都需要進行性能測試嗎? 迭代測試與性能測試不是同一級別的概念，要不要進行性能測試，應該根據產品的需求來定，而非是不是迭代測試

問題五：軟體測試遇到版本迭代 你如何處理 如果版本迭代比較快，會考慮自動化測試。

問題六：迭代的時候，小需求和大需求的回歸測試有區別嗎 沒區別~~~~~~~~

問題七：軟體測試遇到迭代如何處理 有沒有調試的
設置循環變數
一步一步來~

問題八：產品開發迭代速度加快，要怎麼樣測試才能跟得上？ 作為TestBird的老工程師，我懂你的意思，產品發布之後，會一直在持續不斷的加入新特性，每次發布前除了新增功能之外，舊的核心功能也是發布之前必須確保的。
但是，新增功能的用例直接添加上去存檔，並不會修改優先順序，當前版本新增功能中有些路徑的優先順序是1，2級，但是站在整個版本上來看或許並不是這么重要。
舊功能的修改或刪減，對已有功能做出修改或者是廢棄，用例也是直接歸檔，並沒有對之前的用例修改或刪除，雖然用例後面都有寫最後需改的版本，但是因為數量太過龐大，想要找到那個點修改也是力不從心。
你需要將用例做一個精簡，方法是這樣的：經驗沉澱＋代碼覆蓋率＋知識庫
1.充分利用經驗，把經驗轉化為可見的東西，即運用集體智慧
第一輪：人工篩選，由於是要善於利用外包同學的經驗
力度：粗，不必要太精細，每個模塊的要大膽刪除
2.工具輔助：代碼覆蓋率+知識庫
通過工具輔助來補充人工的不足和冗餘
完善整個模塊的知識庫，便於後續利用
另外我還推薦功能自動化測試，你可以試試。

問題九：迭代版本出來後由產品經理先確認需求是否實現才交給測試嗎 這個看公司規定，不過我個人覺得迭代版本出來後應該先由產品經理確認需求是否實現再交付給測試，因為這樣相當於對產品的迭代進行了兩次測試，而且減少了因需求不明確造成的麻煩～

7. 如何通過自動化測試 應對App的頻繁迭代

在開始設計自動化測試框架之前，需要考慮下：

使用該框架寫出來的自動化測試案例，需要給開發，手動測試，可能還有客戶查看，所以寫的測試案例需要盡量的清晰明了，不要有太多復雜邏輯，及比較好的可讀性。

使用這個框架做自動化的人，不會有太深的編程能力，所以要提供足夠好的，最好是傻瓜化的測試點驗證方法，及很好的異常容錯處理能力。

測試框架最好是app測試，網頁測試，介面測試，統統都能支持。

TestBird - 手游和App自動化測試平台

8. Python Appium自動化測試 Monkey搭建+操作

Monkey 是 Android SDK 提供的一個命令行工具， 可以簡單，方便地運行在任何版本的 Android 模擬器和實體設備上。 Monkey 會發送偽隨機的用戶事件流，適合對 App 做壓力測試。

Monkey 測試就像一隻猴子，在電腦面前亂敲鍵盤在測試。 通過 Monkey 程序模擬用戶觸摸屏幕、滑動 Trackball 、 按鍵等操作來對設備上的程序進行壓力測試，檢測程序多久的時間會發生異常。

Android 官方自動化測試領域這只 「猴子」 一旦啟動，就會讓被測的 Android 應用程序像猴子一樣活蹦亂跳，到處亂跑。常用 Monkey 來對被測程序進行壓力測試，檢查和評估被測程序的穩定性。

Android 官方對與 Monkey 的描述：

Monkey 是一個程序，運行在模擬器或設備上，並生成偽隨機的用戶事件流，如點擊、觸摸、手勢，以及一些系統級事件。 你可以使用 Monkey 以隨機但可重復的方式對正在開發的應用程序進行壓力測試。

官方文檔： http://www.android-doc.com/tools/help/monkey.html

安裝 Android SDK 並配置環境變數。

Monkey 主要用於 Android 的壓力測試，自動的一個壓力測試小工具， 主要目的就是為了測試 app 是否會 Crash 。

（1） Monkey 程序由 Android 系統自帶，使用 Java 詫言寫成，在 Android 文件系統中的存放路徑是： /system/framework/monkey.jar；

（2） Monkey.jar 程序是由一個名為 「monkey」 的 Shell 腳本來啟動執行， shell 腳本在 Android 文件系統中 的存放路徑是：/system/bin/monkey；

（3） Monkey 命令啟動方式：

Monkey 運行在設備或模擬器上面，可以脫離 PC 運行。普遍做法是將 monkey 作為一個像待測應用發送隨機按鍵消息的測試工具。驗證待測應用在這些隨機性的輸入面前是否會閃退或者崩潰。

Monkey 雖然可以根據一個指定的命令腳本發送按鍵消息，但其支持條件判斷，也支持讀取待測界面的信息來執行驗證操作。

Monkey 程序是 Android 系統自帶的，其啟動腳本是位於 Android 系統的 /system/bin 目錄的 Monkey 文件，其 jar 包是位於 Android 系統的 /system/framework 目錄的 Monkey.jar 文件。用戶主要是通過 adb 命令來啟動 Monkey 的， Monkey 在運行時，會根據命令行參數的配置，生成偽隨機的事件流，並在 Android 設備上執行對應的測試事件。同時， Monkey 還會對測試系統進行監測，當出現以下幾種情況時會進行特殊處理：

以夜神模擬器為例：

1、檢查設備連接狀態

2、從上圖看出，設備未連接，連接移動設備

3、再次查看設備連接狀態

4、連接成功後輸入命令：adb shell

5、進入到指定目錄，命令：cd /system/bin

6、輸入 monkey命令看到如下提示則說明啟動成功

monkey 命令格式如下：

[options] 是指 monkey 可傳入的參數，是可選項（如果不指定options，Monkey將以無反饋模式啟動，並把事件任意發送到安裝在目標環境中的全部包）

<event-count> 是指隨機發送事件數。如：輸入100就是執行100個偽隨機事件，為必選項

測試工程師職業發展路線：
功能測試 — 介面測試 — 自動化測試 — 測試開發 — 測試架構師

內容就到這里，如果你對Python自動化軟體測試感興趣的話可以加入我們175317069扣裙一起學習。群里會有各項測試學習資源發放，更有行業深潛多年的技術人分析講解。

作為測試工程師，不斷提升自己工作能力是提高薪資待遇最重要的基礎。另外也要注重學習， IT 行業是個不斷發展、更新迭代相對較快的行業，技術具有明顯的時代特徵，所以緊跟時代技術的發展才能讓自己不掉隊，在職場當中具有足夠的競爭力。

9. Android 手機自動化測試工具有哪些

1、Monkey是Android SDK自帶的測試工具，在測試過程中會向系統發送偽隨機的用戶事件流，如按鍵輸入、觸摸屏輸入、手勢輸入等)，實現對正在開發的應用程序進行壓力測試，也有日誌輸出。實際上該工具只能做程序做一些壓力測試，由於測試事件和數據都是隨機的，不能自定義，所以有很大的局限性。

2、MonkeyRunner也是Android SDK提供的測試工具。嚴格意義上來說MonkeyRunner其實是一個Api工具包，比Monkey強大，可以編寫測試腳本來自定義數據、事件。缺點是腳本用Python來寫，對測試人員來說要求較高，有比較大的學習成本。

3、Instrumentation是早期Google提供的Android自動化測試工具類，雖然在那時候JUnit也可以對Android進行測試，但是Instrumentation允許你對應用程序做更為復雜的測試，甚至是框架層面的。通過Instrumentation你可以模擬按鍵按下、抬起、屏幕點擊、滾動等事件。Instrumentation是通過將主程序和測試程序運行在同一個進程來實現這些功能，你可以把Instrumentation看成一個類似Activity或者Service並且不帶界面的組件，在程序運行期間監控你的主程序。缺點是對測試人員來說編寫代碼能力要求較高，需要對Android相關知識有一定了解，還需要配置AndroidManifest.xml文件，不能跨多個App。

4、UiAutomator也是Android提