⑴ 比較好的web安全掃描工具有哪些
隨著網站業務所承載內容的日益增多且重要性日益增強，網站本身的價值也越來越大，隨之由網站漏洞帶來的安全性問題也愈發嚴峻。新開通網站、新增專欄的准入質量評估，網站系統日常運行狀況的檢查預防和風險掌控，這些已成為各行業每年安全大檢查中的關鍵要素。作為具體落實定期檢查工作的安全人員，也急需選擇一款優秀的網站掃描產品進行高效徹底的Web脆弱性評估檢查，而如何選擇一款真正實用的產品成為一個比較糾結的難題。
常見Web掃描方案的優劣勢
目前常見的支持Web掃描解決方案的產品有很多，大家比較熟悉的有集成Web掃描模塊的多合一系統掃描器，網上可免費下載的開源掃描器軟體以及近幾年剛嶄露頭角的獨立Web掃描器產品等，都可以進行一定程度的Web安全掃描和漏洞發現。那麼面對如此琳琅滿目的選擇時，大家如何細致區分辨識其差異，就需嚴格立足於實際需要，最終做出最佳的判斷。
多合一的系統掃描器，通常會集主機掃描、配置核查、Web掃描及弱口令掃描於一身，是一款強大全面的多功能產品。但多合一的高度封裝導致其在進行安全掃描時，除不能分配全部計算資源在Web掃描方面，掃描引擎自身還要兼顧到全方位的權衡與調優。反觀目標Web應用呈現的種類多樣性、規模龐大性和運行特殊性，在面對動輒上萬、十萬甚至百萬級別網頁數量的網站時，這種多合一產品就表現得差強人意，使用起來有種牛拉火車的感覺;同時，高效執行掃描評估就必須具備高並發的網頁鏈接爬蟲識別和Web插件交互邏輯判斷能力，這一現實的沖突導致多合一掃描器在Web掃描及性能體驗方面效果平平，優勢不突出。
網上開源的Web掃描器軟體，盡管完全免費並可以發現一些基本的漏洞信息，但其在第一時間發現新爆Web漏洞和漏洞趨勢跟蹤分析、修補方面，完全不具備後期支撐能力。而且在人性化設計及低學習門檻方面也存在太多先天的不足，其性能與穩定性更是與商業軟體相差甚遠。
面對綜上同類產品，困惑於Web掃描場景需求種種局限的我們，很欣喜地看到了近幾年聲名鵲起的Web掃描器產品。它作為一款自動化評估類工具，依據制定的策略對Web應用系統進行URL深度發現並全面掃描，尋找出Web應用真實存在的安全漏洞，如跨站點腳本、SQL注入，命令執行、目錄遍歷和不安全的伺服器配置。Web掃描器產品可以通過主動生成統計分析報告來幫助我們正確了解Web應用漏洞的詳細分布、數量和風險優先順序，並對發現的安全漏洞提出相應有力的改進意見供後續修補參考，是幫助我們高效徹底地進行Web脆弱性評估檢查的堅實利器。
Web掃描器的三個誤區
針對現有市面上諸多品牌的Web掃描器，大家在評價它們孰優孰劣時時常過於片面極端，主要表現為三個認識誤區。
誤區1：多就是好!
認為漏洞庫條目多，檢查出來的漏洞多就是好。Web掃描器面對龐大繁多、千差萬別的應用系統，為提升檢測性能，多採用高效率的Web通用插件，以一掃多，其不再局限於某個專門應用系統，深層次聚合歸並，盡可能多地發現多種應用系統的同類漏洞。同時，對於掃描出來的非誤報漏洞，若同屬某一頁面不同參數所致的相同漏洞，歸納整理，讓最終呈現的漏洞報表簡約而不簡單，避免數量冗餘、雜亂無章。故若以毫無插件歸並能力，僅靠大量專門Web系統插件、羅列各類漏洞列表數量多來博取贊許的Web掃描器，其本質存在太多的不專業性。
誤區2：快就是好!
認為掃描速度快耗時短的就是好。網站規模日趨復雜，日常檢查時我們期待Web掃描器能有更高效率地完成掃描任務，這點無可厚非，但檢查的本質是要最大限度地提前發現足夠多的漏洞，並第一時間制定後續相應的修補計劃。故在面對同一目標站點時，Web掃描器若能在單位時間內檢測出來的有效存在漏洞數越多，這個快才是真的好。
誤區3：小就是好!
認為掃描過程中對目標業務影響小就是好!這句話本身也沒有問題，只要Web掃描器在執行掃描過程中，對目標系統負載響應和網路鏈路帶寬佔用，影響足夠小，也就是我們常說的「無損掃描」，它就具備了一款優秀Web掃描器應有的先決條件。但是，這必須是在能最大限度發現Web漏洞的前提下才能考慮的關鍵因素，脫離這個產品本質，就本末倒置了。
五個基本評優標准
那麼，評優一款Web掃描器，我們該從何處著手?具體的判斷標准有哪些呢?
全——識別種類繁多的Web應用，集成最全的Web通用插件，通過全面識別網站結構和內容，逐一判斷每一種漏洞可能性，換句話說，漏洞掃描的檢測率一定要高，漏報率務必低，最終才能輸出全面詳盡的掃描報告。這就要求其在Web應用識別方面，支持各類Web語言類型(php、asp、.net、html)、應用系統類型(門戶網站、電子政務、論壇、博客、網上銀行)、應用程序類型(IIS、Apache、Tomcat)、第三方組件類型(Struts2、WebLogic、WordPress)等;插件集成方面，支持國際標准漏洞分類OWASP TOP 10和WASC插件分類模板，允許自定義掃描插件模板，第一時間插件更新速度等。
准——較高的漏洞准確性是Web掃描器權威的象徵，可視化分析可助用戶准確定位漏洞、分析漏洞。而誤報是掃描類產品不能迴避的話題。Web掃描器通過通用插件與目標站點任一URL頁面進行邏輯交互，通過可視化的漏洞跟蹤技術，精準判斷和定位漏洞，並提供易讀易懂的詳細整改分析報告。除此之外，一款好的Web掃描器還要更具人性化，在漏洞發現後，允許掃描者進行手工、自動的漏洞批量驗證，進而雙重保障較高的准確性結果。
快——快速的掃描速度，才能在面對越來越大的網站規模，越發頻繁的網站檢查時游刃有餘，進度保障。一款快速的Web掃描器除了有強勁馬力的掃描引擎，高達百萬/天的掃描速度，還要具備彈性靈活的集群掃描能力，任意增添掃描節點，輕松應對可能苛刻的掃描周期時間要求。
穩——穩定可靠的運行過程，對目標環境近乎零影響的Web掃描器，才能在諸行業大面積投入使用，特別是一些對業務影響要求苛刻的行業會更受青睞，畢竟沒有人能夠接受一款評估類產品，會對目標造成額外的損傷。市面上現在已有一些Web掃描器產品，其通過周期探尋目標系統，網路鏈路，自身性能負載等機制，依據目標環境的負載動態變化而自動調節掃描參數，從而保障掃描過程的足夠穩定和幾乎零影響。此外，隨著網站規模，檢查范圍的不斷擴大，保證持續穩定的掃描執行和統計評估，盡量避免掃描進度的半途而廢，也提出了較高的可靠性運行要求。
易——人性化的界面配置，低成本的報表學習和強指導性修補建議。尤其是漏洞分布詳情和場景重現方面，市面上大多數Web掃描器的報表都需要專業安全人員的二次解讀後，普通的安全運維檢查人員才能看懂，才知道長達百頁報表給出的重要建議和下一步的具體修補措施，這無疑給使用者造成了較高的技術門檻，那麼如何解決此易讀、易用問題，就成為評定其優劣與否的一個重要指標。
總之，一款優秀的Web掃描器產品，它需要嚴格恪守五字核心方針，全、准、快、穩、易，做到全方位均衡，這樣才能做到基本優秀。同時，隨著網站檢查訴求的日益多元化，它若能附帶一些差異化特性，滿足大家不同場景的網站安全運維掃描要求，如網站基本信息搜集，漏洞全過程時間軸跟蹤，逐步可視化的漏洞驗證和場景重現，自動修補直通車等，定會大大增加該款掃描器的評優力度。
⑵ 軟體測試工具有哪些
目前由於軟體測試工作在軟體的生產過程中越來越重要，很多軟體測試工具應運而生，這里介紹一下目前最流行的一些軟體測試工具，一個十個，介紹如下：
一、企業級自動化測試工具WinRunner
這款軟體是MercuryInteractive公司的。
WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平台的、復雜的企業級應用無故障發布及長期穩定運行。
二、工業標准級負載測試工具Loadrunner
這款軟體是惠普公司開發的。
LoadRunner是一種預測系統行為和性能的負載測試工具。通過以模擬上千萬用戶實施並發負載及實時性能監測的方式來確認和查找問題，LoadRunner能夠對整個企業架構進行測試。通過使用LoadRunner，企業能最大限度地縮短測試時間，優化性能和加速應用系統的發布周期。
三、功能測試工具RationalRobot
IBMRationalRobot是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。它集成在測試人員的桌面IBMRationalTestManager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。這種測試和管理的雙重功能是自動化測試的理想開始。
四、功能測試工具SilkTest
BorlandSilkTest2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。
五、功能和性能測試的工具JMeter
JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。
六、單元測試工具xUnit系列
目前的最流行的單元測試工具是xUnit系列框架，常用的根據語言不同分為JUnit(java)，CppUnit(C++)，DUnit(Delphi)，NUnit(.net)，PhpUnit(Php)等等。該測試框架的第一個和最傑出的應用就是由ErichGamma(《設計模式》的作者)和KentBeck(XP(ExtremeProgramming)的創始人)提供的開放源代碼的JUnit.
七、全球測試管理系統testdirector
TestDirector是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。通過在一個整體的應用系統中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。
八、自動化白盒測試工具Jtest
Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。parasoft同時出品的還有C++test，是一款C/C++白盒測試工具。
九、性能測試工具WAS
是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。
十、性能測試和分析工具WEBLODE
webload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試;webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。
⑶ web 系統的掃描漏洞的軟體有哪些
Wed系統的掃描漏洞的軟體有哪些？我覺得這個系統的掃描軟體有很多，但是還是使用正規的騰訊公司生產的掃描軟體比較靠譜。
⑷ web測試方法有哪些測試技術又有哪些軟體測試工具又有哪些呢，優劣勢分別是什麼
web網站本質上帶有web伺服器和客戶端瀏覽器的C/S結構的應用程序。主要考慮web頁面、TCP/IP通訊、Internet鏈接、防火牆和運行在 web頁面上的一些程序(例如，applet、javascrīpt、應用程序插件)，以及運行在伺服器端的應用程序(例如，CGI腳本、資料庫介面、日誌程序、動態頁面產生器，asp等)。另外，因為伺服器和瀏覽器類型很多，不同版本差別很小，但是表現出現的結果卻不同，連接速度以及日益迅速的技術和多種標准、協議。使得web測試成為一項正在不斷研究的課題。其它要考慮的如下：
1、伺服器上期望的負載是多少(例如，每單位時間內的點擊量)，在這些負載下應該具有什麼樣的性能(例如，伺服器反應時間，資料庫查詢時間)。性能測試需要什麼樣的測試工具呢(例如，web負載測試工具，其它已經被採用的測試工具，web 自動下載工具，等等)?
2、系統用戶是誰?他們使用什麼樣的瀏覽器?使用什麼類型的連接速度?他們是在公司內部(這樣可能有比較快的連接速度和相似的瀏覽器)或者外部(這可能有使用多種瀏覽器和連接速度)?
3、在客戶端希望有什麼樣的性能(例如，頁面顯示速度?動畫、applets的速度等?如何引導和運行)?
4、允許網站維護或升級嗎?投入多少?
5、需要考慮安全方面(防火牆，加密、密碼等)是否需要，如何做?怎麼能被測試?需要連接的Internet網站可靠性有多高?對備份系統或冗餘鏈接請求如何處理和測試?web網站管理、升級時需要考慮哪些步驟?需求、跟蹤、控制頁面內容、圖形、鏈接等有什麼需求?
6、需要考慮哪種HTML規范?多麼嚴格?允許終端用戶瀏覽器有哪些變化?
7、頁面顯示和/或圖片占據整個頁面或頁面一部分有標准或需求嗎?
8、內部和外部的鏈接能夠被驗證和升級嗎?多久一次?
9、產品系統上能被測試嗎?或者需要一個單獨的測試系統?瀏覽器的緩存、瀏覽器操作設置改變、撥號上網連接以及Internet中產生的「交通堵塞」問題在測試中是否解決，這些考慮了嗎?
10、伺服器日誌和報告內容能定製嗎?它們是否被認為是系統測試的主要部分並需要測試嗎?
11、CGI程序、applets、javascrīpts、ActiveX 組件等能被維護、跟蹤、控制和測試嗎?
測試技術大體分為黑盒和白盒測試，當然有的還用灰盒測試。
而功能、性能、用戶界面、兼容性、安全測試都屬於測試方法。大部分的測試是手動的，用基本的辦公軟體就可以解決；部分白盒測試需要了解程序內部的語句、數據結構和演算法邏輯。
現在企業認同的高名氣軟體就是功能測試工具：QTP 性能測試工具：LOADRUNNER
bug追蹤、記錄工具：Bugfree、Bugzilla、TD等，用一個即可。
而QTP和LOADRUNNER是性能非常龐大的軟體，如果可以熟練的分析出錄制的內容，那麼就入門了。可以運用到工作上。
說道這些軟體的劣勢，就是實現自動化需要這個團隊購買正版軟體、組織和培訓組內成員進行新知識的培訓。這些都是成本的一部分。
⑸ 基於web的系統用什麼方法測試軟體
一般軟體的發布周期以月或以年計算，而Web應用的發布周期以天計算甚至以小時計算。Web測試人員必須處理更短的發布周期，測試人員和測試管理人員面臨著從測試傳統的C/S結構和框架環境到測試快速改變的Web應用系統的轉變。
一、功能測試
1、鏈接測試
鏈接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
鏈接測試可以自動進行，現在已經有許多工具可以採用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之後進行鏈接測試。推薦使用XENU這個小工具，可以方便快速的進行鏈接測試。
2、表單測試
當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給伺服器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。
3、Cookies測試
Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web伺服器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，在瀏覽器直接輸入二級以下的頁面地址看是否能直接到達這個頁面，刷新對Cookies有什麼影響等。
4、設計語言測試
Web設計語言版本的差異可以引起客戶端或伺服器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
5、資料庫測試
在Web應用技術中，資料庫起著重要的作用，資料庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的資料庫類型是關系型資料庫，可以使用SQL對信息進行處理。
在使用了資料庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網路速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
⑹ App測試與Web測試的區別是什麼
App測試和web測試都屬於軟體測試，它們在整個測試流程上沒有太大的區別，主要的區別體現在以下幾個方面： 功能、性能、兼容性、專項測試、操作方式 等，下面我們一一舉例說明。
1、功能方面：
App和web基於不同的網路架構，App是C/S架構（即客戶端/服務端），web是B/S架構（即瀏覽器/伺服器），對於web來說，一般情況下如果服務端發生了更新，那麼瀏覽器端也會隨著更新，這個更新是即時的，不需要用戶額外操作的，用戶只需要打開瀏覽器訪問具體的伺服器地址便可以完成這個過程；而App端則首先需要用戶在自己的終端上安裝一個應用，當服務端發生了變更時，不能保證每個客戶端的內容都獲得更新，除非用戶自己手動選擇更新。
2、性能方面：
App和web在性能上都會關注響應時間以及負載情況等，但App還需要額外考慮應用的耗電情況、流量、CPU和內存佔用情況、後台進程等。
3、兼容性方面：
Web是基於瀏覽器架構，在兼容性方面，一般只需要考慮所使用的瀏覽器版本，如Google Chrome、edge、Firefox等，而App就復雜一些，除了要關注終端系統，如iOS、macOS或Android等移動操作系統，還需要測試不同的硬體設備型號，比如iPhone系列、華為、小米、OPPO、vivo等廠商，每一家在設備的CPU、屏幕尺寸、解析度等硬體系統上都是有差別的，App測試需要確保在軟體和硬體系統上的兼容性。
4、專項測試：
正如我們前面所說的，App是基於C/S架構，所以App測試需要關注某些專項測試，比如客戶端的安裝、卸載和更新，而web是基於B/S架構是不需要考慮這些的。
此外，App還要考慮一些特殊場景，比如系統和應用的優先順序、操作許可權、應用奔潰、後台進程、中斷、重啟、以及網路專項測試等，網路專項又包括網路切換（如2/3/4/5G/WIFI等）、網路中斷以及弱網測試等。
5、操作方式：
Web端在操作方式上是基於滑鼠點擊和鍵盤輸入實現的，一般來說相對簡單，而App端是基於屏幕，一般是通過觸摸屏幕或者功能設備（如觸摸筆）來實現具體步驟的，由於操作方式的不同，App測試時要留意屏幕的旋轉和縮放、多點觸控、特殊事件觸發區域、應用層等。
小結
隨著軟體和技術的不斷發展，App和web端測試在具體細分領域的區別會越來越明顯，有效地加深二者異同的認識對於我們的測試能力的提升具有良好的指引作用，或許測試在具體領域還會進一步細分，但是對於測試工程師能力的要求會不斷地提高，如何提高對於不同分支的認知情況值得我們去思考。