整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
1、目前正在研究jmeter，請問初期做性能，應先從幾點做起？
Jmeter和LR都是目前性能測試的首選工具，如果你有LR的學習背景，那么Jmeter上手會很快，重點理解線程和進程的概念，流程和LR是類似的。如果沒有，從入門的角度我建議先了解常用網絡協議和操作系統線程和進程的概念，Jmeter用java比較理想，可以考慮了解一些編程基礎。PS:其實用Jmeter先學習接口測試會更好理解性能。
2、請問零基礎，計算機硬件專職業轉行到這個行業，需要準備哪些？
計算機硬件已經具備了基礎的計算機知識，要轉軟件是相對容易的，可以考慮從如下維度準備：
1)先準備自己拿手的網絡和操作系統部分，網絡主要是應用層協議，為性能和接口測試做鋪墊，操作系統主要是為了搭建測試環境
2)建議熟悉一種編程語言，java或者Python都是首選語言，不需要精通，至少要能夠進行簡單的腳本編寫
3)找一本介紹全面的專業的軟件測試書籍精讀，一定是精讀。
4)如果可能最好找項目練手，從功能測試開始
3、目前做接口測試，進階的時候還是會茫然，希望您能給點建議，另外您在做管理的時候，對員工一般是持什么態度，或者說姿態呢？如何培養，如何相處，如何分配任務，控制項目進度，質量？
這問題好大，我挑些重點說:
1)接口測試實際上是協議的測試，建議你從網絡協議入手，這樣才能做好接口測試
2)至于測試管理工作我認為因人而異，有些人天生強勢，但有些偏平和，最關鍵的還是自身實力，如果自己不夠強，一句俗話叫做將熊熊一窩就是這個理，姿態不重要，實體才重要。
3)至于培養，相處，分配任務這些是管理細則，總的思路是用其所長補其所短，人無完人，而且大多數都會覺得自己比領導牛B，讓每位員工發揮最大價值，有成就感比較重要。
4)控制項目進度和質量 這個是方法問題，有很多方法可以控制，例如：測試版本控制，缺陷分析等手段，可以參考一下軟件工程，敏捷過程等方面的資料。希望對你有所幫助
4、用做壓測，響應時間比實際要高很多，用LR做壓測，平均響應時間幾十秒鐘，實際手動打開鏈接1秒不到，差距很大，請問有哪些原因會導致這個問題呢？
比如下圖，vuser才十幾個，響應時間就十幾秒了，但是實際上的體驗還是很快，如何解決？
初步猜測應該是響應時間的設置不當導致的，舉例說明：你要錄制登錄腳本，并記錄登錄的響應時間，你在LR的腳本中插入了事務函數（注意是一組函數），結果得到的響應時間是5s，但實際登錄你感覺不到1s，那么可能是你的函數位置不對，包含了輸入用戶名和密碼的時間，也可能是你的響應時間函數內包含了思考時間。前者你需要調整事務的位置；后者你需要在run time setting中排除掉思考時間。供參考
5、請教一下怎么樣去抓程序的頁面元素啊？ 像 web那樣 抓頁面的元素？有什么好的工具或者方法？
z如抓取頁面元素，推薦Chrome tools，在下查看。如果是為gnodi了自動化測試，除了也可以考慮QTP（ALM）
6、請問軟件疲勞測試應該怎么做？
一般是做壓力測試，壓測依據項目和業務的不同都會有所差異，推薦三種，一種是4H峰值壓力的80% ；一種是24H，壓力量可以控制在60%70%，還有一種是7*24小時（有的是一直持續50%的壓力，有的是按時間波動壓力值進行測試）
7、對B/S系統做壓力測試前需要做哪些準備？如何客觀的去分析一個系統？壓力測試工具以前只接觸過 ，所以打算用，不太熟，里面的需要做的系統指標的設置看起來很麻煩，不知怎么去分析系統。還有就是做壓力測試前除了選擇熟悉工具之外，我還需要做寫什么呢？
你的問題很難一兩句話說清楚，對于前期準備工作，只能談談我在性能測試項目中的拙見：
1）先對需求進行初步分析，確定哪些環節需要性能測試，也就是對于你們系統來說壓力最大的點在哪里
2）看現有資源，提前做好環境的準備工作，最好測試環境和生產環境1：1（實在做不到也要盡量接近，這點很重要，不然你要做等比換算 ）
3）看被測系統使用的協議以及操作系統和應用服務器等各類配置，選擇匹配的測試工具（多數WEB系統LR是可以應對的）
4）看時間，大多數情況下性能測試的時間并不充裕，需要抓重點優先測試。
8、如何取舍和Jmeter？
全看心情，玩笑哈~~如果從學習入門的角度就看代碼和網絡基礎，如果代碼和網絡基礎還不錯直接用Jmeter入門就好，反之用LR入門更好。如果從企業應用的角度就看哪種更合適，對被測系統支持的更好。
工具只是形式，理解性能測試的基本原理用什么工具都可以的。
9、對Java頻繁GC怎么定位問題?
請嘗試用尋找內存異常，例如短時間過多的對象創建，或者較大的對象創建。
10、我想實現50個用戶并發上班打卡簽到，參數化、迭代已設，然后，在簽到函數前面添加了集合點函數,運行結果發現，用戶簽到后返回的簽到時間是一分鐘一個，并沒有在同一個時間點進行簽到！請教這是為什么？如何解決?
先去掉集合點試試看呢？同時啟動50個用戶并行（不設置集合點也可以實現并發操作的），如果還是持續一分鐘，那請你檢查事務時間和思考時間，事務時間是需要你手動配置的，思考時間默認是啟動狀態，你可以在Runtime Setting中查看一下，有可能你最終得到的1分鐘是整個腳本運行一次的時間或者是包含了思考時間的結果，不是同時打卡的時間。
11、請問電商秒殺產品是如何測試的？
和其他產品的測試沒有太大區別，主要是對時間點的要求比較高，可以考慮在性能測試腳本中使用集合點函數實現同一秒鐘的并發。
12、壓力測試和性能測試一樣嗎？
分類方法各有不同，沒有定論，普遍來講性能測試是對這類測試的統稱。我傾向于下面的分類方式
性能測試（狹義）——性能測試方法是在特定的運行環境下，通過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否滿足生產性能要求。
基準測試——在一定的軟件，硬件和網絡環境下，模擬一定數量的用戶運行一種或多種業務，將測試結果作為基線數據，供后續測試活動參考。
負載測試——通過在被測系統上不斷加壓，直到性能指標達到極限，例如“響應時間”超過預定指標或某種資源已經達到飽和狀態。
壓力測試——壓力測試也稱為強度測試，主要測試系統在一定飽和狀態下，例如cpu、內存在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤。PS：在極限值80%左右的情況下持續運行一段時間（2~4小時）
配置測試——配置測試方法通過對被測系統的軟\硬件環境的調整，了解各種不同對系統的性能影響的程度，從而找到系統各項資源的最優分配原則。
可靠性測試——在系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定。
并發測試——并發測試方法通過模擬用戶并發訪問，測試多用戶并發訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或其者他性能問題。
PS：分類其實不那么重要，在實際項目中往往都是混合應用的
13、Web性能測試除了并發登陸以外，還有哪些比較常見的測試場景？
場景取決于業務，例如你是電商網站，你肯定要測試同時下訂單的情況? ?；如果你是醫院掛號網站，你肯定要測試多人搶一個醫生的號源；如果你是銀行系統，要考慮多人同時取款吧？
14、一般網站壓力多大百萬用戶？
這要看計算方式，理論值100萬/天的業務訪問量 拆分到每秒鐘是非常少的；但這不符合實際情況。
如果系統已上線，直接取線上數據做參考即可，一天中的峰值有幾個，峰值時段分布情況可以推算出并發用戶量；
如果系統未上線，可以利用2/8原則，80%用戶集中在20%的時段，推導出業務訪問量
15、目前遇到一個問題，在一臺配置為8g，i3的win7系統運行壓力測試，并發總是上不去，總是在140左右就會出現異常，超時等問題，請問如何分析呢，是因為服務器還是電腦的問題？
服務器壓力上不去可以從如下維度分析：
網絡流量是否有限制、
數據庫/應用服務器是否報了異常，如果有請查看一下日志；
查看操作系統的資源監控情況，CPU占用率如何，是否達到了100%
代碼方面是否存在性能問題，可以在大并發訪問的時候手動訪問系統，看看業務上有無異常。
PS：性能瓶頸分析和定位需要一個積累的過程，要學會看一些基礎指標，提升編碼能力，理解軟件架構。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
