簡介
軟件測試是當前保證軟件産品質量控制、管理與檢測的重要手段，越來越受到各國企業的關注。随着軟件測試的地位逐步提高，測試的重要性逐步顯現，測試工具的應用已經成為了普遍的趨勢。用于測試的工具種類繁多，一般包括白盒測試、黑盒測試、性能測試，以及測試管理等。
WinRunner™是一種企業級的功能測試工具，用于檢驗企業應用程序是否能如期進行。通過自動捕獲、檢測和重放用戶的交互操作，WinRunner能夠發現系統缺陷，并确保那些跨越多個應用程序和數據庫的業務流程再初次發布就避免故障的出現，并且保持其長期穩定地運行。您的公司的程序開發員剛創建完成一個新的Web應用程序，然而在布署應用程序之前，您必須測試該程序，以确保其正常運行，不會産生錯誤，但這并非是您唯一需要檢測的對象，因為人事部門剛剛升級他們的erp系統，而你的客戶不再加一個CRM程序，所以問題就是如何有效的測試不斷變化着的多重應用程序，而且這些應用程序存在于您的企業内部的不同環境之下--其實該問題也同樣困擾着許多其他的公司。
如果資源有限的話，這個問題就比較棘手。人工測試的工作量大，況且您負擔不起額外的時間來培訓新的測試人員。為了确保那些複雜的應用程序再不同的環境下都可以可靠的運行，您需要一個易操作的測試工具來自動完成功能測試。MercuryInteractive的WinRunner軟件為企業提供一個強大的功能測試工具。通過捕獲、檢測和重放用戶對您企業Web應用程序的互動操作，WinRunner可自動執行功能測試。您因此可以辨認錯誤，确保應用程序順利布署，并且能夠安排和執行測試。
一旦測試計劃建立後，TestDirector的TestLabManager為測試日程制訂提供一個基于Web的框架。他的SmartScheduler™根據測試計劃中創立的指标對運行着的測試計劃中創立的指标對運行着的測試執行監控。當網絡上任何一台主機空閑，測試能夠徹夜執行于其上，SmartScheduler能自動分辯是系統還是應用錯誤，然後将測試重新安排到網絡上的其他機器。
TestDirector，對于不斷改變的Web應用，經常性地執行測試是至關重要的，能夠追查出錯發生的環節并評估應用質量，然而，這些測試運行都要消耗測試資源和測試時間。使用GraphicDesigner圖表設計，您可很快的将測試分類以滿足不同的測試目的，如功能測試，負載測試，完整性測試等，他的拖動功能可簡化設計和排列在多個機器上運行的測試，最終根據設定好的時間、路徑或其他測試的成功和否，為序列測試制訂執行日程。SmartScheduler能讓您在更短的時間内，在更少的機器上完成更多的測試。用Winrunner®、Astra®、QuickTest™、AstraLoadTest或LoadRunner來自運動運行功能或負載測試，無論成功和否，測試信息都會被自動彙集傳送到TestDirector的數據儲存中央。同樣，人工測試也以次方式運行。
當測試完成後，項目經理必須解讀這些測試數據，并将這些信息用于工作中。當有出錯發現時，他們還要指定相關人員及時糾正。TestDirector的錯誤管理功能直接貫穿并作用于檢測的全過程，以提供管理系統終端--終端的出錯跟蹤包括，從最初的問題發現到修改錯誤再到檢驗修改結果。由于同一項目組中的成員經常分布于不同的地方，TestDirector基于浏覽器的特征，使出錯管理能讓多個用戶何時何地都可通過Web查詢出錯跟蹤情況。利用出錯管理，測試人員隻需要進入一個URL，就能夠彙報何更新錯誤。過濾整理錯誤列表并作出趨勢分析。再進入一個出錯案例之前，測試人員還能夠自動執行一次錯誤數據庫搜尋确是否已有類似的案例記錄，這已查尋功能能夠避免重複勞動。
測試過程的最後一步時分析測試結果，确定應用程式是否已部署成功或需要再次測試。TestDirector常規化的圖表和報告和再測試的任何的任一環節幫助您對數據信息進行分析。TestDirector還以标準的HTML或Word形式提供一種生成和發送正式測試報告的一種簡單方式。測試分析數據還能夠簡便地輸入到一種工業标準化的報告工具，如Excel，Reportsmith，Crystal，Reports和其他類型的第三放工具。
評測工具标準
自動化
應用測試工具最廣為人知的就是自動化工具，它們嘗試來取代人力——讓電腦完成點擊并檢查。測試自動化最常見的類型就是用戶界面驅動的，用戶記錄一系列操作及其預期結果。用戶界面自動化的兩大常見類型是記錄/回放這裡一個工具記錄下交互操作并且随後将這些操作自動化，期望得到相同的結果—并且是關鍵詞驅動的—這裡用戶界面的元素。關鍵詞驅動的測試通常在某個編程語言裡創建，但是不一定非得如此；可以在電子表格裡記錄元素标識符，命令，輸入和預期結果。
基礎架構和支持
持續集成工具就是支持類工具，可以檢測到新代碼的check-in，從而開始構建build，創建一個新的虛拟Web服務器—或者更新某個staging服務器—将新代碼交付到目标機器上，運行自動化來測試程序，檢查結果并且用郵件将失敗信息發送給相關團隊。
Bug跟蹤
對于很簡單的軟件而言，可以使用便利貼或者電子表格來跟蹤bug報告。但是當軟件更為複雜時，這就會變得很難用，公司就需要使用為解決此類問題而設計的專業軟件。通常來說，專業的bug跟蹤工具會報告bug的嚴重程度，優先級，發現問題的時間，确切的重現步驟，修複問題的人，問題在哪個build上被修複，以及提供搜索和标簽的機制來幫助使用者找到某個defect。這些工具不僅僅能夠幫助編程人員和項目經理；客戶服務和已有用戶也可以使用這些工具來查找某個問題是不是已知問題，是否已經計劃修複，升級某個已知問題，并且彙報非已知問題。Bug跟蹤工具也能夠有助于工作流，因為可以将bug分配給編程人員，然後給測試人員重新檢查，然後标記為待部署，并且在部署之後，标記為已部署。
覆蓋率
當我們讨論軟件測試領域的覆蓋率時，我們實際在探讨兩個領域的問題。
第一個領域是代碼覆蓋率，關注于被測試覆蓋的軟件的代碼百分比。代碼覆蓋率最常見的類型是statement覆蓋率，它是在測試流程運行過的statement的百分比——手動測試，自動測試或者兩者。
第二個領域是應用程序覆蓋率，從另外的維度查看測試流程——通常是，被“覆蓋”的需求百分比。常見的應用程序覆蓋率工具之一是一個可跟蹤的矩陣——一個列表，列出哪些測試覆蓋了哪些需求。通常來說，測試用例管理軟件記錄了所有計劃的測試，并且允許測試人員為某個給定版本将某個測試用例标記成“已執行”，這使得管理層可以了解多少百分比的測試已經“被覆蓋”了。這是一種“質量保證”，檢查測試流程，和管理控制一起來确保應用程序的每個部分都被覆蓋了。
