① 常用的軟體測試方法和工具
工業標准級負載測試工具LoadrunnerLoadRunner 是一種預測系統行為和性能的負載測試工具。通過以模擬上千萬用戶實施並發負載及實時性能監測的方式來確認和查找問題，LoadRunner 能夠對整個企業架構進行測試。通過使用LoadRunner ，企業能最大限度地縮短測試時間，優化性能和加速應用系統的發布周期。自動化功能測試工具AutoRunnerAutoRunner是黑盒測試工具，可以用來完成功能測試、回歸測試、每日構建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調試功能的、支持IE測試和Windows native測試的自動化測試工具，是目前國內最好的銀行業務測試工具。全球測試管理系統testdirectorTestDirector 是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。通過在一個整體的應用系統中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。測試用例管理工具TestCenterTestCenter是一款功能強大測試管理工具，它實現了測試需求管理、測試用例管理、測試業務組件管理、測試計劃管理、測試執行、測試結果日誌察看、測試結果分析、缺陷管理，並且支持測試需求和測試用例之間的關聯關系，可以通過測試需求索引測試用例。終端自動化測試工具TARTAR適用於VT100、VT220等標準的應用系統，支持命令行模式和窗口模式（使用Cursors編寫的應用程序）。 支持針對終端應用的自動錄制。支持連續錄制和單獨的窗口錄制。支持的窗口組件：欄位、表格、對話框、窗口等。功能測試工具Rational RobotBorland SilkTest 2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。 性能測試工具WASMicrosoft Web Application Stress Tool 是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。自動化白盒測試工具JtestJtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。parasoft同時出品的還有C++ test，是一款C/C++白盒測試工具。功能和性能測試的工具JMeterJMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。性能測試和分析工具WEBLODEwebload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。企業級自動化測試工具WinRunnerMercury Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平台的、復雜的企業級應用無故障發布及長期穩定運行。
測試經理和PM對TC進行Review：
敏捷測試流程總結：
在敏捷方法中，XP方法強調測試在整個項目開發過程中的重要性。針對敏捷開發方法的敏捷測試不同於以往針對傳統開發模式的測試,在敏捷團隊中,測試是整個項目組的「車頭燈」，它告訴大家現在到哪了，正在往哪個方向走。測試員為項目組提供豐富的信息，使得項目組基於這些可靠的信息作出正確的決定。不僅是測試員要保證質量，而是整個項目組的每一個人都要對質量負責。測試員不跟開發人員糾纏錯誤，而是幫助他們找到目標,共同為達到項目的最終目標而努力。敏捷測試也需要高度迭代工作、頻繁得到客戶的反饋，需要動態調整測試計劃、測試的執行。並且，敏捷測試人員參與到了更多的敏捷生產活動中，積極的影響了團隊做出的決定和計劃。
根據公司項目目前採用的敏捷開發模式，相應的敏捷測試建議採用以下流程：
1. 驗證需求和設計
需求和設計具體來說一般包括：(1)由項目經理根據需求文本而編寫的功能設計文本(Functional Design Specification);(2)由開發人員根據功能文本而編寫的實施設計文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設計的可測性.
在測試初期，測試人員要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一用戶積極參與項目和系統的需求分析，設計和開發。積極地參與前期工作，並迅速反饋給設計和開發其靜態測試結果。要盡早的開始測試，不要等待到功能完全做好才開始。
產出物:測試需要提交評審結果文檔,可以讓測試更多的參與DB Design,框架的評審中來
2. 測試計劃，測試用例
2.1 編寫計劃、測試用例
在敏捷開發的過程中由於是根據每個user story來估算時間的。開發人員將對本次迭代所需要的完成的user story進行評估。開發人員可以和客戶直接溝通，來確定每個user story的優先順序。
好處：
客戶可以很清楚的了解到哪些user story需要花費多長的時間，以及他們的優先順序。
問題：
在user story的時間估算上，開發人員常會估算過少。引起版本無法按時發布或者必須進行加班才能進行發布。
分析：
由於版本更新很快，任務的時間都是以小時來進行估算的。開發人員一般會忽略掉開發以外的時間，比如開發中遇到問題的時間，開會，給其他成員提供幫助的時間，等等。
舉個例子：
開發人員估算某個user story編碼的時間需要1.5天，開發人員自己估算了其他時間為半天。於是開發人員給的估算時間是2天。開發階段實際的花費時間如下，每天花費開例會的時間。在例會中項目的其他成員需要技術上的支持。於是發費了3個小時進行幫助。在開發的過程中遇到了一些沒有預見到的問題，結果解決問題花費了4個小時。(也許更多)。需要處理一些公司突發性的事務等等。所以非常建議大家在估算時間上能充分的考慮到以外的因素，某本XP相關的書上寫到，在時間估算上最好的時間是編碼時間的2-3倍。聽起來很嚇人，但是實際的過程中，的確需要這么多的時間。
測試人員根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文本中，功能設計文本是主要依據。測試的這兩個文本也要被項目經理和開發人員審核。
2.2 測試用例的審核
為使開發人員能參與到Test Case的Review中來，以保證TC的質量和可行性，確保測試工作的順利進行，讓開發人員迅速地了解測試的重點並給出相應的意見和建議，測試人員在出 TC的同時，應出一份TC_Matrix(Test Case跟蹤矩陣)，其中註明TC已覆蓋了哪些Features，具體每個Features對應的TC的編號，這樣在測試經理和PM對TC進行 Review的時候，能夠對TC的覆蓋率一目瞭然，對覆蓋率不足(如某個重點Feature的Test Case不夠)的地方能夠及時給出意見。
另外，在每天早上的Morning Meeting上，測試人員可以簡潔地講述一下當天測試的重點部分，以及項目中存在哪些嚴重的bug，讓開發人員了解當天測試的重點是什麼，怎樣進行測試，並提出自己的意見和建議。這樣做加強了開發與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。
在迭代後期測試要抽時間更新test case。
3. 實施運行測試
在敏捷方法中，測試有兩種：單元測試和接收測試。單元測試是由開發人員來完成的，接收測試是由客戶代表來完成。
由於我們客戶無法在現場，我們採取了，開發人員做單元測試，測試人員做驗證測試，最後由客戶進行接收測試。在每個版本發布給客戶之前必須由測試人員進行測試，發布版本之後由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下一個發布完成。
?? 單元測試
在daily build版本給測試前，開發首先要做單元測試，提前告知軟體中的薄弱環節，幫助測試人員調整測試重點。Unit test
做單元測試的好處是可以提高版本質量，減輕測試的工作量，減少淺層次的bug的發生率，使測試人員能夠將更多的精力投入到尋找深層次的bug上面。
?? 驗證測試
測試人員的驗證測試從總體上說就是將上一步設計的測試用例按計劃付諸實施的過程。這一階段的測試必須在周密的計劃下進行。這種計劃性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃共同推進。從測試的過程來看，測試執行的一開始可以是針對部分功能的，之後可以逐步擴展。接著開始採用迭代的過程完成測試任務，即將測試任務劃分為多個周期，一開始可以做些關鍵的功能性測試，可以對代碼中的可復用部分(組件，構件)做完整的測試。接著的迭代周期可以做邊緣化的功能測試和其他測試，最後的幾個迭代應該用於回歸測試，和關鍵的性能和穩定性測試。
3.1 每日提供bug趨勢
為方便衡量項目的進度，測試可每天測試完畢後提供測試的bug趨勢，即將每天新生成的Bug數和每天被解決的Bug數標成一個趨勢圖表。一般在項目的開始階段新生Bug數曲線會呈上升趨勢，到項目中後期被解決Bug數曲線會趨於上升，而新生Bug數曲線應下降，到項目最後，兩條曲線都趨向於零。PM會持續觀察這張圖表，確保項目健康發展，同時通過分析預測項目Bug，
對於每個版本的bug，開發都應該想想為什麼會出現這樣的問題，特別是很低級的bug，對於同類的bug，是否可以避免。
測試需要考慮:探索性測試用例的編寫
3.2 測試用例的維護
在執行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增一些測試用例：一是對於當初測試設計不周全的領域，二是對於外部的Bug(比如從Beta客戶報告來的)，沒有被現有測試用例所覆蓋。當產品的功能設計出現更改時(敏捷項目中功能設計的更改頻繁)，所涉及的測試用例也要相應地修改，使測試用例保持和現有的功能需求同步。
3.3 根據項目不斷補充Common Sense
在項目進行過程中，測試人員需要不斷積累經驗，不斷補充、完善各類目的Common Sense標准。例如，由CTTS項目總結出的Common Sense for USA標准，在以後的美國項目中要嚴格按照它來執行測試，保證以前出現過的失誤在以後的項目測試中不會再出現。在保證項目質量的同時，不斷積累新的經驗。
3.4 控制中間版本
為更好地保證軟體質量，規避風險，必須加強對中間版本的控制。例如，客戶要求或者計劃周五要提交版本，則周三一定要提交一個中間過程的版本進行測試，也就是控制中間版本，避免所有的工作都壓到後期最緊急的時候去完成。以前的項目中出現過項目前期很輕松，到後期bug越來越多，開發人員和測試人員都異常忙碌，經常加班的情況。為減少後期工作量，規避風險，建議開發進行Daliy Build，或者按照完成一個feature就進行一次build，針對這個feature進行測試，這樣就可以有效避免後期bug越來越多的狀況發生，後期工作量也就會相應減少，項目的質量也會更有保證。
3.5 發布版本前編寫Release Note
在每次發布版本之前，測試人員要根據待發布的版本情況編寫Release Note，使客戶對發布的版本情況一目瞭然。Release Note主要包括三方面的內容：Fixed，New Features，Known Problems。其中，Fixed部分寫明此版本修復了上個版本中存在的的哪些比較大的bug;New Features部分寫明此版本新增加了哪些功能;Known Problems部分寫明此版本尚存在哪些比較大的問題，有待下個版本改善;或者列出需求不太明確的地方，有待客戶給出明確答復意見，在下個版本中完成。
4. 需求管理
採用敏捷開發模式的項目中，客戶對於需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應的歷史記錄，方便後期的管理和維護工作。可將每次的變更整理記錄到需求跟蹤文檔中，並使該文檔始終保持最新更新的狀態，與需求的變化保持同步。
問題：
客戶可能會在一個功能點上來回修改他們的需求，也許開始需要某個功能，結果做完以後又覺得不好，於是讓去掉這個功能。後來又由於一些原因，有需要加上。在整個過程中可能來回修改了很多次。那一定要記錄下變更的內容和日期。可能後期客戶會覺得一個功能怎麼會花那麼多的時間，不是以前很早就做過了嗎?這時這些記錄才是解決客戶疑慮的最好證明。說白了，是有證據證明我們做了很多的變更。大家可能覺得，怎麼會有這個問題。其實當一個項目長達半年以上，也許大家的記憶力都不可靠了(:p)
建議：
目前採用的是vss工具，對每天的Email中提到的需求變更做一次backup，文檔以當天收到Email的日期命名
5. 項目開發末期開展「bug大掃除」
在項目開發的末期，可以開展「bug大掃除」活動。劃出一個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。注意以下要點：
(1)盡管這是一個測試活動，但參與者並不僅限於測試人員。項目經理，開發人員甚至於高層管理人員都應參加，如同全民動員。目的是要集思廣益;(2)要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助於發現更多的Bug;(3)為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發現Bug最多，發現最嚴重Bug的個人，給以物質和精神獎勵。(4)可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。
② 介面自動化測試工具有哪些
1、CTS，CTS 測試基於Android instrumentation 測試， 其又基於JUnit 測試。說白了， CTS 就是一堆單元測試用例。這也是Java 語言的擅長部分。
2、 Monkey工具，Monkey是Android中的一個命令行工具，可以運行在模擬器里或實際設備中。它向系統發送偽隨機的用戶事件流(如按鍵輸入、觸摸屏輸入、手勢輸入等)，實現對正在開發的應用程序進行壓力測試。Monkey測試是一種為了測試軟體的穩定性、健壯性的快速有效的方法。
3、ASE，ASE 意思為Android 腳本環境， 即我們可以通過腳本（比如Python）調用Android 的功能，從而定製一些測試。比如打電話，發簡訊，瀏覽網頁，等。我們可以擴充它的API（Java 部分）, 並用python 腳本調用這些API, 從而實現豐富的測試功能。用於API 部分可以訪問到Android 全部API, python 又能靈活部署測試，所以ASE 的擴展性非常好。
4、Robotium，該工具用於黑盒的自動化測試。可以在有源碼或者只有APK 的情況下對目標應用
進行測試。Robotimu 提供了模仿用戶操作行為的API，比如在某個控制項上點擊，輸入Text
等等。 http://mag.big-bit.com/
分層的自動化測試
這個概念最近曝光度比較高，傳統的自動化測試更關注的產品UI層的自動化測試，而分層的自動化測試倡導產品的不同階段（層次）都需要自動化測試。
相信測試同學對上面的金字塔並不陌生，這不就是對產品開發不同階段所對應的測試么！我們需要規范的來做單元測試同樣需要相應的單元測試框架，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，幾乎所有的主流語言，都會有其對應的單元測試框架。
集成、介面測試對於不少測試新手來說不太容易理解，單元測試關注代碼的實現邏輯，例如一個if 分支或一個for循環的實現；那麼集成、介面測試關注的一是個函數、類（方法）所提供的介面是否可靠。例如，我定義一個add()函數用於計算兩個參數的結果並返回，那麼我需要調用add()並傳參，並比較返回值是否兩個參數相加。當然，介面測試也可以是url的形式進行傳遞。例如，我們通過get方式向伺服器發送請求，那麼我們發送的內容做為URL的一部分傳遞到伺服器端。但比如 Web service 技術對外提供的一個公共介面，需要通過soapUI 等工具對其進行測試。
UI層的自動化測試，這個大家應該再熟悉不過了，大部分測試人員的大部分工作都是對UI層的功能進行測試。例如，我們不斷重復的對一個表單提交，結果查詢等功能進行測試，我們可以通過相應的自動化測試工具來模擬這些操作，從而解放重復的勞動。UI層的自動化測試工具非常多，比較主流的是QTP，Robot Framework、watir、selenium 等。
為什麼要畫成一個金字塔形，則不是長方形 或倒三角形呢？ 這是為了表示不同階段所投入自動化測試的比例。如果一個產品從沒有做單元測試與介面測試，只做UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。如果你妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低於所支付的成本。因為越往上層，其維護成本越高。尤其是UI層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與介面測試階段進行。
既然UI層的自動化測試這么勞民傷財，那我們只做單元測試與介面測試好了。NO! 因為不管什麼樣的產品，最終呈現給用戶的是UI層。所以，測試人員應該更多的精力放在UI層。那麼也正是因為測試人員在UI層投入大量的精力，所以，我們有必要通過自動化的方式幫助我們「部分解放」重復的勞動。
在自動化測試中最怕的是變化，因為變化的直接結果就是導致測試用例的運行失敗，那麼就需要對自動化腳本進行維護；如何控制失敗，降低維護成本對自化的成敗至關重要。反過來講，一份永遠都運行成功的自動化測試用例是沒有價值。
至於在金字塔中三種測試的比例要根據實際的項目需求來劃分。在《google 測試之道》一書，對於google產品，70%的投入為單元測試，20%為集成、介面測試，10% 為UI層的自動化測試。
③ 自動化測試工具有哪些
自動化測試工具有如下幾種：
1、WinRunner
Mercury Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。
通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平台的、復雜的企業級應用無故障發布及長期穩定運行。企業級應用可能包括Web應用系統，ERP系統，CRM系統等等。
2、Rational Robot
是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。它集成在測試人員的桌面IBM Rational Test Manager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。
這種測試和管理的雙重功能是自動化測試的理想開始。
3、AdventNet QEngine
AdventNet 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 Run
QARun的測試實現方式是通過滑鼠移動、鍵盤點擊操作被測應用，即而得到相應的測試腳本，對該腳本可以進行編輯和調試。在記錄的過程中可針對被測應用中所包含的功能點進行基線值的建立，換句話說就是在插入檢查點的同時建立期望值。
在這里檢查點是目標系統的一個特殊方面在一特定點的期望狀態。通常，檢查點在QARun提示目標系統執行一系列事件之後被執行。檢查點用於確定實際結果與期望結果是否相同
④ 想自學軟體測試自動化測試工具，有方向卻不知道如何著手，請教專業人士給出合理具體的計劃
1、Appium
官網：http://appium.io
AppUI自動化測試
Appium 是一個移動端自動化測試開源工具，支持iOS 和Android 平台，支持Python、Java 等語言，即同一套Java 或Python 腳本可以同時運行在iOS 和Android平台，Appium 是一個C/S 架構，核心是一個 Web 伺服器，它提供了一套 REST 的介面。當收到客戶端的連接後，就會監聽到命令，然後在移動設備上執行這些命令，最後將執行結果放在 HTTP 響應中返還給客戶端。
License：免費
2、Selenium
官網：https://www.seleniumhq.org/download/
WebUI自動化測試
Selenium是一個用於Web應用程序測試的工具，Selenium已經成為Web自動化測試工程師的首選。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。支持的瀏覽器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。這個工具的主要功能包括：測試與瀏覽器的兼容性——測試你的應用程序看是否能夠很好得工作在不同瀏覽器和操作系統之上。測試系統功能——創建回歸測試檢驗軟體功能和用戶需求。支持自動錄制動作和自動生成 .Net、Java、Perl等不同語言的測試腳本。Selenium 是ThoughtWorks專門為Web應用程序編寫的一個驗收測試工具。其升級版本為Webdriver。
License：免費
3、Postman
官網：https://www.getpostman.com
介面測試
Postman 提供功能強大的 Web API 和 HTTP 請求的調試，它能夠發送任何類型的HTTP 請求 (GET, POST, PUT, DELETE…)，並且能附帶任何數量的參數和 Headers。不僅如此，它還提供測試數據和環境配置數據的導入導出，付費的 Post Cloud 用戶還能夠創建自己的 Team Library 用來團隊協作式的測試，並能夠將自己的測試收藏夾和用例數據分享給團隊。
License：免費
4、Soapui
官網：https://www.soapui.org
介面測試
SoapUI提供了所有所需的工具來測試和完善的測試。總覽標簽給你一個項目的所有內容和全面的看法。只需一次點擊，您可以添加任何數量的斷言為驗證傳入的消息TestStep。使用功能強大的HTTP監視器記錄，分析甚至修改客戶機 - 伺服器通信，因為它發生。和SoapUI臨帶來了更專業和先進的功能，保持遙遙領先其他測試工具。輕松創建和運行數據驅動測試。該數據源TestStep讀取測試數據從任何外部來源 - Excel中，XML，JDBC，文件，等等 - 到標准SoapUI屬性。
License：免費
5、Robot Framework
官網：http://robotframework.org
WebUI自動化測試，介面測試，APP測試
Robot Framework是一款python編寫的功能自動化測試框架。具備良好的可擴展性，支持關鍵字驅動，可以同時測試多種類型的客戶端或者介面，可以進行分布式測試執行。主要用於輪次很多的驗收測試和驗收測試驅動開發。
Robot framework為不同的自動化測試需求提供了不同的框架。它的測試能力可以通過 Python 和 Java 測試庫得到擴展。Selenium WebDriver 是 Robot Framework 中內置的流行庫。
Robot Framework 不僅僅是網頁測試工具，同樣可以用來做 Android 和 iOS 的自動化測試。對於關鍵字測試驅動熟悉的測試員可以輕松上手 Robot Framework。
License：免費
6、QTP
官網：https://software.microfocus.com/en-us/procts/unified-functional-automated-testing/overview
WebUI自動化測試，介面測試，APP測試
HP QuickTest Professional 提供符合所有主要應用軟體環境的功能測試和回歸測試的自動化。採用關鍵字驅動的理念以簡化測試用例的創建和維護。它讓用戶可以直接錄制屏幕上的操作流程，自動生成功能測試或者回歸測試用例。專業的測試者也可以通過提供的內置腳本和調試環境來取得對測試和對象屬性的完全控制。目前版本名為Unified Functional Testing，簡稱UFT。可以測試非常多的應用，比如介面API，Web services，桌面程序，Web系統，手機APP。
License：商業
⑤ 常用的軟體測試自動化工具有哪些
1、測試類型可以包括：白盒測試、黑盒測試（功能測試、性能測試）等。
2、不同的測試類型使用的自動化測試方法不同，白盒測試主要針對代碼級的單元測試、黑盒測試主要面對功能級和系統級的驗證測試。
3、自動化測試，針對白盒測試，一般需要有一定的編程基礎，即能夠基於功能代碼寫測試代碼，常用的單元測試方面的自動化測試工具很多，上網一搜全是。
4、自動化測試，針對功能測試，有幾種情況，基於CLI、API和GUI的測試；基於CLI、API的測試，即應用腳本技術向設備模擬發送CLI命令或者API請求，以達到控制設備的效果。基於GUI功能測試，即應用傳統的界面自動化測試工具(例如：RFT、QTP等）控制界面控制項操作的方法，以達到模擬用戶操作，這幾種方式都需要你有一定的編碼基礎；基於CLI、API的需要你懂腳本技術（例如:tcl、python、ruby等），RFT需要你懂java或者.net、QTP需要VB等。
⑥ 如何對一項自動化的應用控制實施控制測試
對一項自動化的應用控制實施控制測試的方法包括：
一、時間
控制測試的時間包含兩層含義：一是何時實施控制測試；二是測試所針對的控制適用的時點或期間。一個基本的原理是，如果測試特定時點的控制，注冊會計師僅得到該時點控制運行有效性的審計證據；如果測試某一期間的控制，注冊會計師可獲取控制在該期間有效運行的審計證據。因此，注冊會計師應當根據控制測試的目的確定控制測試的時間，並確定擬信賴的相關控制的時點或期間。
關於根據控制測試的目的確定控制測試的時間，本准則第四十條第一款指出，如果僅需要測試控制在特定時點的運行有效性（如對被審計單位期末存貨盤點進行控制測試），注冊會計師只需要獲取該時點的審計證據。如果需要獲取控制在某一期間有效運行的審計證據，僅獲取與時點相關的審計證據是不充分的，注冊會計師應當輔以其他控制測試，包括測試被審計單位對控制的監督。換言之，關於控制在多個不同時點的運行有效性的審計證據的簡單累加並不能構成控制在某期間的運行有效性的充分、適當的審計證據；而所謂的「其他控制測試」應當具備的功能是，能提供相關控制在所有相關時點都運行有效的審計證據；被審計單位對控制的監督起到的就是一種檢驗相關控制在所有相關時點是否都有效運行的作用，因此注冊會計師測試這類活動能夠強化控制在某期間運行有效性的審計證據效力。
二、測試范圍
注冊會計師在確定某項控制的測試范圍時通常考慮的一系列因素：
1．在整個擬信賴的期間，被審計單位執行控制的頻率。控制執行的頻率越高、控制測試的范圍越大。
2．在所審計期間，注冊會計師擬信賴控制運行有效性的時間長度。擬信賴控制運行有效性的時間長度不同，在該時間長度內發生的控制活動次數也不同。注冊會計師需要根據擬信賴控制的時間長度確定控制測試的范圍。擬信賴期間越長，控制測試的范圍越大。
3．為證實控制可以夠防止或發現並糾正認定層次重大錯報，所需獲取審計證據的相關性與可靠性。對審計證據的相關性及可靠性要求越高，控制測試范圍越大。
4．通過測試和認定相關的其他控制獲取的審計證據的范圍。針對是同一認定，可能存在不同控制。當針對其他控制獲取審計證據的充分性與適當性較高時，測試該控制的范圍可適當縮小。
5．在風險評估的時候擬信賴控制運行有效性的程度。注冊會計師在風險評估時對控制運行有效性擬信賴程度越高，需要實施控制測試范圍越大。
6．控制的預期偏差。預期偏差可以用控制未得到執行的預期次數占控制應當得到執行次數的比率加以衡量（也可稱作預期偏差率）。考慮該因素，是因為在考慮測試結果是否可以得出控制運行有效性的結論時，為不可能只要出現任何控制執行偏差就認定控制運行無效，所以需要確定一個合理水平預期偏差率。控制預期偏差率越高，需要實施控制測試范圍越大。如果控制預期偏差率過高，注冊會計師應當考慮控制可能不足以將認定層次的重大錯報風險降至可接受低水平，從而針對某一認定實施控制測試可能是無效的。
三、測試內容
控制測試應包括兩個方面：
一是控制設計測試，即對被審計單位的內部控制政策和程序的設計是否適當所進行的審計程序。目的是確定被審計單位的內部控制是否能夠防止和發現特定財務報表認定的重大錯報或漏報。例如：注冊會計師了解到，會計人員記錄存貨購入時，必須有檢驗部門出具的檢驗報告、倉庫管理人員簽字的入庫單和采購部門認可的購貨發票。據此，注冊會計師可以推斷，該項控制可以防止由於虛假購貨產生的存貨高估的風險。
二是控制執行測試，即被審計單位的內部控制政策和程序是否發揮應有的作用。如果被審計單位的控制政策和程序未能發揮其應有的作用，即使設計得再完整，也不能減少財務報表中出現重大錯報或漏報的風險。因此，針對被審計單位現已存在的內部控制，注冊會計師應測試其是否得到有效執行。對此，注冊會計師應測試其是否得到有效執行。對上述控制，注冊會計師就應檢查會計人員所記錄的購貨是否均附有入庫單、驗收報告和采購部門認可的購貨發票。
控制測試指的是測試控制運行的有效性。控制運行有效性強調的是控制能夠在各個不同的時點按照既定設計得以一貫執行。控制測試是為了確定被審計單位控制政策和程序的設計與執行是否完整與有效而實施的審計程序。注冊會計師在了解被審計單位的內部控制之後，只有對那些准備依賴的內部控制執行控制測試，並確信其得到正確的執行時，才能減少實質性測試審計程序，從而減少審計取證工作，提高審計工作的效率。
⑦ 如何使用win7自帶的測試工具測試電腦性能
win7自帶的內存檢測工具使用方法： 點擊開始按鈕，選擇控制面板。 打開控制面板以後，查看方式選擇「大圖標」。 在「大圖標」的查看方式下，找到「管理工具」。 在打開的「管理工具」中，找到「Windows 內存診斷」；雙擊打開即可使用。
⑧ 常用的自動化測試工具有哪些
1、Appium
AppUI自動化測試
Appium 是一個移動端自動化測試 開源工具，支持iOS 和Android 平台，支持Python、Java 等語言，即同一套Java 或Python 腳本可以同時運行在iOS 和Android平台，Appium 是一個C/S 架構，核心是一個 Web 伺服器，它提供了一套 REST 的介面。當收到客戶端的連接後，就會監聽到命令，然後在移動設備上執行這些命令，最後將執行結果放在 HTTP 響應中返還給客戶端。
2、Selenium
WebUI自動化測試
Selenium是一個用於Web應用程序測試的工具，Selenium已經成為Web自動化測試工程師的首選。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。支持的瀏覽器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。這個工具的主要功能包括：測試與瀏覽器的兼容性——測試你的應用程序看是否能夠很好得工作在不同瀏覽器和操作系統之上。測試系統功能——創建回歸測試檢驗軟體功能和用戶需求。支持自動錄制動作和自動生成 .Net、Java、Perl等不同語言的測試腳本。Selenium 是ThoughtWorks專門為Web應用程序編寫的一個驗收測試工具。其升級版本為Webdriver。
3、Postman
介面測試
Postman 提供功能強大的 Web API 和 HTTP 請求的調試，它能夠發送任何類型的HTTP 請求 (GET, POST, PUT, DELETE…)，並且能附帶任何數量的參數和 Headers。不僅如此，它還提供測試數據和環境配置數據的導入導出，付費的 Post Cloud 用戶還能夠創建自己的 Team Library 用來團隊協作式的測試，並能夠將自己的測試收藏夾和用例數據分享給團隊。
4.Robot Framework
Robot Framework是一個開源自動化框架，它實現了用於驗收測試和驗收測試驅動開發（ATDD）的關鍵字驅動方法。 Robot Framework為不同的測試自動化需求提供框架。 但是，通過使用Python和Java實現其他測試庫，可以進一步擴展其測試功能。 Selenium WebDriver是Robot Framework中常用的外部庫。
測試工程師可以利用Robot Framework作為自動化框架，不僅可以進行Web測試，還可以用於Android和iOS測試自動化。 對於熟悉關鍵字驅動測試的測試人員，可以輕松學習Robot Framework。
5、Soapui
介面測試
SoapUI提供了所有所需的工具來測試和完善的測試。總覽標簽給你一個項目的所有內容和全面的看法。只需一次點擊，您可以添加任何數量的斷言為驗證傳入的消息TestStep。使用功能強大的HTTP監視器記錄，分析甚至修改客戶機 - 伺服器通信，因為它發生。和SoapUI臨帶來了更專業和先進的功能，保持遙遙領先其他測試工具。輕松創建和運行數據驅動測試。該數據源TestStep讀取測試數據從任何外部來源 - Excel中，XML，JDBC，文件，等等 - 到標准SoapUI屬性。
針對上面的自動化測試工具，每一個都有自己優勢的功能，隨著計算機行業的發展，自動化測試工具會越來越多，越來越完善。
⑨ 自動化測試的工具有哪些
商業工具：
1、RFTRational Functional Tester 的基礎是針對於Java、.NET的對象技術和基於 Web 應用程序的錄制、回放功能。工具為測試者的活動提供的自動化的幫助，如數據驅動測試。IBM RFT是一個用於功能和回歸測試的數據驅動的測試平台。它支持大范圍的應用，例如.Net、Java、SAP、Flex和Ajax。RFT使用Visual Basic。Net和Java作為腳本語言。RFT有一個獨特的功能，稱為 Storyboard 測試，用戶的動作被記錄下來，並通過應用截圖在 Storyboard 格式中可視化。RFT的另一個有趣特性是它與IBM Jazz應用生命周期管理系統（如IBM Rational Team Concert和Rational Quality Manager）的集成。
2、kylinTOP:這是一款國產的自動化測試工具，支持WEB和APP的自動化測試，其中元素智能定位是這款自動化軟體主要特點，是設計理念比較超前的測試工具，算是國內眾多自動化測試工具中，做的比較突出的一款。與傳統的RFT和UFT相比，的確有過人之處，算是後起之秀，使用起來，簡單高效、穩定。這樣描述估計也沒幾個人能體會到的。說白一點就是一個人可以干三個人的活，使用者只需關注業務即可。
3、UFT：UFT（別名：QuickTest Professional簡稱QTP）是一種自動化測試工具，以VBScirpt為內嵌語言,其前身是QTP。UFT支持功能測試和回歸測試自動化，可用於軟體應用程序和環境的測試。UFT自動化測試的基本功能包括：創建測試、檢驗數據、增強測試、運行測試腳本、分析測試結果、維護測試；UFT支持兩種視圖，一種是Keyword View(關鍵字視圖)，另一種是Expert View(專家視圖)。是一款老牌的自動化測試工具。
4、SilkTest：這個也是比較相對著名的工具，不過同樣還是沒有了解過，對於商業的工具，因為其佔地面積大，還要破解等麻煩事，最關鍵的是使用的公司少，所以只使用過QTP，其它的一概未了解過
開源工具：1、Selenium：這個應該大多數人都知道的，現在也是大多數互聯網公司在使用的測試框架；selenium僅支持web的UI級別測試，但是其優點在於：a、支持多種語言編寫測試腳本，比如：java、python、ruby、perl等；同時也就意味著其後的支持類庫也是很多的b、支持多瀏覽器，如：ie，ff，safari、chrome等c、支持多平台，如：windows、linux、MAC、android、iphone等d、支持分布式執行，一套測試用例可以同時分布到不同的測試機上執行，而且還可以進行任務細化，比如：針對liunx執行系統只分配linux下需要執行的用例此外還有錄制工具支持，簡單也說，web類測試基本上是首選，不過對flash的支持好像不是太好其主要分2個版本，1.X版本是以js驅動來進行自動化實現的；2.X重新開發了webdriver來代替js驅動，直接調用瀏覽器底層介面來完成自動化實現的前提：如果使用remote或者RC功能，需安裝jre下載地址：http://seleniumhq.org/download/
2、EFT【easy function testing】：這個是在.net3.0 的UIAutomatuon的基礎上封裝的一個dll文件，同樣還封裝了部分windows api以實現滑鼠和鍵盤事件。所以這個只能叫測試類庫，且僅支持windows程序，而且同樣支持uiautomain所支持的WPF程序的測試。前提：安裝了.net3.0使用：引入該文件，uiautomation 相關dll，VS環境下編寫測試用例
3、UIAutomation：這個是微軟提供的UI自動化框架，當然它的初衷並不僅僅是為自動化測試而產生的，它的任務是給更多的開發或者應用去調用windows的UI控制項，不過還是可以用於自動化測試的；因為之前微軟就有類似的工具，而這個是重新設計的ui操作類框架，其目的是為了兼容支持windows系列操作系統的UI自動化操作【xp，vista，server2003】，還有就是天然支持WPF。當然其設計與通常的自動化工具就不一樣了，比如：沒有把控制項支持的方法綁定在控制項對象本身，沒有提供專門的滑鼠/鍵盤事件，但是卻提供了特定控制項對象的事件響應監聽及處理方法的定製。其工作流程大概是這樣的：a、先獲取特定的元素對象，有多種方法。如：句柄，屬性值b、獲取這個元素對象的模式。模式是這個框架的設計的獨具之處，成就了它的靈活性，統一性c、通過這個模式在進行具體的方法調用，屬性值獲取等d、監聽指定對象的特定事件，一旦發生則執行指定的事件處理函數
4、Robot FrameworkRobot Framework是一個完全基於關鍵字測試驅動的框架，它即能夠基於它的一定規則，導入你需要的測試庫（例如：其集成了selenium的測試庫，即可以理解為操作web控制項的測試底層庫），然後基於這些測試庫，你能應用HTML、TXT等文檔形式編寫自己的關鍵字（這些關鍵字即你的庫組成），之後，再編寫測試用例（測試用例由測試關鍵字組成）進行測試。例如：一個簡單的登陸測試由：登陸+輸入密碼+登出三個關鍵字組成，也可以由一個關鍵字登陸組成，關鍵字顆粒的大小可以自行定製。
⑩ 項目如何讓自動化測試工具(AutoRunner)來做軟體測試呢這個工具是怎麼用的
AutoRunner 是自動化的功能測試工具。功能測試的目標是根據 GUI 的界面或者報表來檢查軟體的實際功能是否和需求定義的功能相一致。
autoRunner使用方法 ：
1.新建項目
a) 在項目管理器空白區域,右鍵滑鼠,選擇新建項目。
b) 輸入項目名後,點擊[確定]，在初次打開autoRunner時選擇的用於存放測試文件的文件夾里會有一個以項目名稱為名的文件夾,各種測試腳本,參數表都存放在這里。
2.新建腳本
a) 在項目名上右鍵滑鼠,選擇新建腳本 。
b) 輸入腳本名(最好是英文和數字),點擊[確定]後,在右邊腳本編輯區域,會打開腳本頁 。
3.錄制腳本
a) 點擊工具欄 ,或者點擊菜單欄 。
b) 點擊開始錄制後, 會彈出對話框 。
根據自己需要,選擇是否記錄擊鍵和記錄時間間隔,選好後點擊[確定]。
c) 點擊[確定]後,開始錄制測試過程,autoRunner會自動最小化,在屏幕右下打開錄制過程記錄窗口,此時,開始測試操作.
4.編輯測試腳本
a) 錄制完成後,在腳本編輯區域會生成本次操作的腳本；
b) 如果需要在腳本中增加循環或者對當前步驟的某個對象的屬性值進行驗證,可以在腳本編輯區域,右鍵滑鼠。
c) 增加驗證 ，在腳本編輯區域空白處右鍵滑鼠,選擇注意游標位置,會在游標處插入代碼。
5.查看對象庫
1) 在工具欄點擊 ,打開對象庫。
2) 這里需要查看,腳本中用到的對象,在對象庫中是否都有,如果缺少,運行腳本時會出錯.對象不足時,可以點擊對象庫左下的[增加對象]按鈕,會像錄制時一樣,此時選擇需要的對象,錄制好以後停止錄制。
6.編輯參數
a) 在控制台標簽頁上點擊[參數表],打開參數表 。
b) 對參數表進行設置。
7.執行腳本
a) 點擊工具欄,或者點擊 菜單欄,開始執行腳本。
b) 執行開始後,autoRunner會自動最小化,程序會完整重復錄制的過程。
運行結束後,在autoRunner控制台會列印出本次腳本執行情況。