2025年軟件測試與性能測試培訓(xùn)及答案一、單項(xiàng)選擇題（每題2分，共30分）1.在敏捷開發(fā)模式下，測試活動(dòng)最強(qiáng)調(diào)的原則是A.測試階段后置B.測試與開發(fā)同步進(jìn)行C.測試用例必須全部自動(dòng)化D.缺陷必須清零才能上線答案：B解析：敏捷強(qiáng)調(diào)“持續(xù)測試”，測試與開發(fā)并行，快速反饋。2.下列哪項(xiàng)不是性能測試的核心指標(biāo)A.吞吐量B.并發(fā)用戶數(shù)C.代碼覆蓋率D.響應(yīng)時(shí)間答案：C解析：代碼覆蓋率屬于白盒測試范疇，與性能無關(guān)。3.JMeter中用于模擬“登錄后保持會(huì)話”的元件是A.HTTPCookie管理器B.響應(yīng)斷言C.聚合報(bào)告D.隨機(jī)控制器答案：A解析：Cookie管理器自動(dòng)維護(hù)會(huì)話狀態(tài)。4.對微服務(wù)架構(gòu)進(jìn)行性能壓測時(shí)，首先應(yīng)確定的瓶頸邊界是A.數(shù)據(jù)庫連接池B.網(wǎng)絡(luò)帶寬C.服務(wù)間調(diào)用鏈D.磁盤I/O答案：C解析：微服務(wù)瓶頸往往出現(xiàn)在跨服務(wù)調(diào)用鏈路上。5.以下哪項(xiàng)最符合“可重復(fù)性”原則A.每次執(zhí)行用例都重新手工輸入數(shù)據(jù)B.用例依賴當(dāng)前系統(tǒng)時(shí)間C.用例數(shù)據(jù)由腳本自動(dòng)構(gòu)造并回滾D.用例步驟口頭傳達(dá)給測試人員答案：C解析：自動(dòng)構(gòu)造與回滾保證環(huán)境一致，結(jié)果可重復(fù)。6.在Linux下定位Java進(jìn)程CPU飆高最優(yōu)先使用的命令組合是A.ps-ef|grepjavaB.top-H-p<pid>結(jié)合jstackC.df-hD.netstat-anp答案：B解析：top-H查看線程級(jí)CPU，jstack打印線程棧。7.關(guān)于“并發(fā)”與“并行”的區(qū)別，描述正確的是A.并發(fā)強(qiáng)調(diào)同時(shí)啟動(dòng)，并行強(qiáng)調(diào)同時(shí)執(zhí)行B.二者在單核CPU上無區(qū)別C.并發(fā)一定依賴鎖機(jī)制D.并行不需要調(diào)度器答案：A解析：并發(fā)是邏輯同時(shí)，并行是物理同時(shí)。8.使用Grafana展示JMeter實(shí)時(shí)數(shù)據(jù)時(shí)，需安裝的插件是A.BackendListenerB.JSONPathExtractorC.BeanShellSamplerD.HTTPHeaderManager答案：A解析：BackendListener把指標(biāo)推送到InfluxDB，Grafana讀取。9.對金融交易系統(tǒng)進(jìn)行性能測試時(shí)，必須首先驗(yàn)證的約束是A.緩存命中率B.事務(wù)一致性C.日志壓縮比D.前端渲染速度答案：B解析：金融場景下數(shù)據(jù)一致性優(yōu)于一切。10.在持續(xù)集成流水線中，最適合做“冒煙性能”驗(yàn)證的階段是A.單元測試B.代碼掃描C.集成環(huán)境部署后D.生產(chǎn)灰度后答案：C解析：集成環(huán)境部署后最早具備完整鏈路，可執(zhí)行輕量壓測。11.以下哪項(xiàng)屬于“容量測試”范疇A.驗(yàn)證系統(tǒng)在1000TPS下響應(yīng)時(shí)間<500msB.驗(yàn)證系統(tǒng)在內(nèi)存耗盡時(shí)觸發(fā)OOM告警C.驗(yàn)證系統(tǒng)在斷電后數(shù)據(jù)零丟失D.驗(yàn)證系統(tǒng)支持最大并發(fā)4000用戶不崩潰答案：D解析：容量測試關(guān)注“最大承載”。12.關(guān)于“ThinkTime”描述錯(cuò)誤的是A.模擬用戶思考停頓B.過短會(huì)導(dǎo)致TPS虛高C.過長會(huì)掩蓋內(nèi)存泄漏D.只能固定為3秒答案：D解析：ThinkTime可隨機(jī)、可動(dòng)態(tài)計(jì)算，非固定值。13.在性能調(diào)優(yōu)中，發(fā)現(xiàn)GC次數(shù)頻繁但單次耗時(shí)短，應(yīng)優(yōu)先調(diào)整A.堆大小B.新生代比例C.老年代比例D.垃圾回收器類型答案：B解析：頻繁MinorGC說明新生代偏小，調(diào)大Survivor區(qū)。14.使用“梯度加壓”策略的主要目的是A.快速找到系統(tǒng)崩潰點(diǎn)B.減少網(wǎng)絡(luò)包重傳C.降低測試腳本復(fù)雜度D.繞過防火墻限制答案：A解析：梯度加壓可精細(xì)觀察性能拐點(diǎn)。15.在測試報(bào)告中，SLA被定義為“99.9%請求響應(yīng)時(shí)間≤1s”，則以下結(jié)果符合的是A.第99百分位900ms，均值500msB.第99.9百分位1100ms，均值400msC.第95百分位800ms，均值600msD.第99.9百分位950ms，均值700ms答案：D解析：99.9%請求≤1s即P99.9≤1000ms。二、多項(xiàng)選擇題（每題3分，共30分）16.以下哪些屬于非功能測試類型A.負(fù)載測試B.兼容性測試C.可維護(hù)性測試D.單元測試答案：A、B、C解析：單元測試屬于功能測試最小粒度。17.造成“虛假失敗”的常見原因有A.測試數(shù)據(jù)被其他腳本篡改B.環(huán)境時(shí)鐘不同步C.斷言寫死絕對路徑D.被測代碼存在缺陷答案：A、B、C解析：D是真缺陷，非虛假失敗。18.在JMeter中使用“事務(wù)控制器”可以A.合并多個(gè)Sampler的響應(yīng)時(shí)間B.生成子樣本標(biāo)記C.自動(dòng)處理JSON斷言D.在報(bào)告里展示事務(wù)級(jí)別指標(biāo)答案：A、B、D解析：事務(wù)控制器不處理斷言邏輯。19.以下哪些手段可降低性能測試環(huán)境成本A.使用容器按需啟停B.采用服務(wù)虛擬化模擬下游C.直接復(fù)用生產(chǎn)數(shù)據(jù)庫D.利用云競價(jià)實(shí)例答案：A、B、D解析：復(fù)用生產(chǎn)庫風(fēng)險(xiǎn)高，不符合隔離原則。20.關(guān)于“基準(zhǔn)測試”描述正確的是A.需在固定軟硬件配置下執(zhí)行B.結(jié)果作為后續(xù)回歸參照C.必須包含全量功能驗(yàn)證D.每次版本發(fā)布前都要重新運(yùn)行答案：A、B、D解析：基準(zhǔn)測試聚焦性能，不強(qiáng)制全量功能。21.以下哪些指標(biāo)可直接反映用戶體驗(yàn)A.FP（FirstPaint）B.ApdexC.錯(cuò)誤率D.代碼行覆蓋率答案：A、B、C解析：行覆蓋率與體驗(yàn)無直接映射。22.在分布式壓測中，可能遇到的“協(xié)調(diào)瓶頸”有A.主控機(jī)網(wǎng)絡(luò)帶寬不足B.從壓測機(jī)時(shí)鐘漂移C.被測系統(tǒng)限流IPD.RMI端口被防火墻封閉答案：A、B、D解析：C屬于被測側(cè)策略，非協(xié)調(diào)瓶頸。23.以下哪些做法符合“測試左移”理念A(yù).開發(fā)編寫單元測試B.測試參與需求評審C.生產(chǎn)環(huán)境全鏈路壓測D.接口契約測試在編碼前落地答案：A、B、D解析：C屬于右移。24.關(guān)于“性能調(diào)優(yōu)金字塔”層級(jí)，自下而上包括A.硬件層B.操作系統(tǒng)層C.應(yīng)用層D.用戶層答案：A、B、C解析：用戶層不在金字塔模型內(nèi)。25.在編寫性能測試腳本時(shí)，應(yīng)遵循A.冪等性B.可參數(shù)化C.硬編碼絕對路徑D.可回滾數(shù)據(jù)答案：A、B、D解析：硬編碼降低可移植性。三、判斷題（每題1分，共10分）26.性能測試通過即代表系統(tǒng)無功能缺陷。答案：錯(cuò)解析：性能僅驗(yàn)證容量與延遲，不覆蓋邏輯錯(cuò)誤。27.在JMeter中，GaussianRandomTimer比ConstantTimer更能模擬真實(shí)用戶停頓。答案：對解析：Gaussian呈正態(tài)分布，更接近人類行為。28.使用“最大并發(fā)”作為唯一指標(biāo)足以評估系統(tǒng)容量。答案：錯(cuò)解析：需結(jié)合響應(yīng)時(shí)間、錯(cuò)誤率、資源利用率綜合評估。29.在微服務(wù)場景，服務(wù)網(wǎng)格（ServiceMesh）可自動(dòng)注入延遲故障，方便做混沌測試。答案：對解析：Istio等支持故障注入。30.性能測試腳本無需版本控制，因?yàn)楦膭?dòng)頻率低。答案：錯(cuò)解析：腳本隨接口變更頻繁，必須納入版本庫。31.當(dāng)CPU利用率低于50%時(shí)，系統(tǒng)一定無性能問題。答案：錯(cuò)解析：可能存在鎖等待、IO阻塞。32.在Grafana中設(shè)置Alert規(guī)則可實(shí)現(xiàn)性能regression自動(dòng)告警。答案：對解析：閾值告警可對接Slack、郵件。33.采用“凌晨定時(shí)壓測”可完全避免對生產(chǎn)用戶的影響。答案：錯(cuò)解析：夜間也有批處理、對賬任務(wù)。34.性能測試報(bào)告無需包含資源監(jiān)控截圖，只需文字描述。答案：錯(cuò)解析：截圖、時(shí)序圖能直觀佐證數(shù)據(jù)。35.在同樣TPS下，響應(yīng)時(shí)間越短，所需并發(fā)用戶數(shù)越少。答案：對解析：Little定律N=λ×T，T減小則N減小。四、填空題（每空2分，共20分）36.在JMeter中，使用________元件可提取JSON響應(yīng)字段并保存為變量。答案：JSONExtractor37.若某接口90%響應(yīng)時(shí)間為300ms，99%為900ms，則該接口的________極差較大，需關(guān)注長尾請求。答案：百分位38.Linux下查看磁盤實(shí)時(shí)I/O性能的常用工具是________。答案：iostat39.在性能測試中，用于衡量系統(tǒng)“可擴(kuò)展性”的指標(biāo)是________，即資源增加與吞吐量提升的比值。答案：擴(kuò)展系數(shù)40.當(dāng)數(shù)據(jù)庫出現(xiàn)“熱點(diǎn)行”更新沖突時(shí)，可通過________拆分或________隊(duì)列緩解。答案：分區(qū)、異步41.若JMeter腳本中忘記添加“HTTP默認(rèn)請求”配置元件，會(huì)導(dǎo)致________冗余，進(jìn)而壓測結(jié)果失真。答案：重復(fù)連接42.在Grafana中，使用________函數(shù)可對InfluxDB的響應(yīng)時(shí)間序列做移動(dòng)平均平滑。答案：moving_average43.性能測試環(huán)境應(yīng)盡量與生產(chǎn)________，但規(guī)?？傻缺萠_______。答案：同構(gòu)、縮容44.若錯(cuò)誤率曲線與并發(fā)用戶數(shù)曲線同時(shí)陡升，則系統(tǒng)大概率進(jìn)入________狀態(tài)。答案：崩潰45.在編寫Java壓測代碼時(shí)，采用________框架可復(fù)用JMeter的并發(fā)模型與報(bào)表。答案：JMeterAPI（或JMeterJavaSampler）五、簡答題（每題10分，共30分）46.描述一次完整的“性能瓶頸定位”流程，并給出每個(gè)階段的關(guān)鍵工具與輸出物。答案：1)需求澄清：與PO確認(rèn)SLA（TPS≥800，P99≤600ms，錯(cuò)誤率≤0.1%），輸出《性能需求清單》。2)基線建立：在隔離環(huán)境執(zhí)行10min基準(zhǔn)腳本，收集CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤、GC、SQL慢查詢，輸出《基線報(bào)告》。3)梯度加壓：以100并發(fā)為步長遞增，觀察拐點(diǎn)，使用JMeter+InfluxDB+Grafana實(shí)時(shí)繪圖，輸出《梯度壓測圖》。4)瓶頸初判：發(fā)現(xiàn)TPS達(dá)600后不再上升，CPU65%、內(nèi)存50%，數(shù)據(jù)庫慢查詢占比升至18%，鎖定數(shù)據(jù)庫。5)深入剖析：-數(shù)據(jù)庫：使用pt-query-digest分析慢日志，發(fā)現(xiàn)索引缺失，輸出《慢SQL列表》。-應(yīng)用：jstack抓取線程棧，發(fā)現(xiàn)200線程阻塞在getConnection，輸出《線程熱點(diǎn)圖》。6)優(yōu)化實(shí)施：-增加復(fù)合索引，慢查詢降至1%。-調(diào)整Druid連接池maxActive從50到150。7)回歸驗(yàn)證：重新壓測，TPS升至950，P99降至480ms，錯(cuò)誤率0.02%，輸出《回歸報(bào)告》。8)復(fù)盤：歸檔腳本、配置、監(jiān)控Dashboard，更新《性能基線庫》。47.解釋“連接池泄漏”如何導(dǎo)致性能測試指標(biāo)逐漸惡化，并給出排查與解決步驟。答案：連接池泄漏指借用連接后未歸還，致使池內(nèi)可用連接數(shù)遞減。表現(xiàn)：-初期TPS平穩(wěn)，響應(yīng)時(shí)間正常；-中后期線程阻塞在borrowObject，響應(yīng)時(shí)間陡升；-最終連接耗盡，錯(cuò)誤率飆升，出現(xiàn)“Poolexhausted”異常。排查：1)實(shí)時(shí)監(jiān)控：使用Micrometer輸出activeConnection指標(biāo)，Grafana繪制曲線，發(fā)現(xiàn)該值持續(xù)遞增且不下降。2)代碼掃描：靜態(tài)工具SpotBugs搭配“OBL_UNSATISFIED_OBLIGATION”檢測規(guī)則，定位未關(guān)閉連接代碼塊。3)運(yùn)行時(shí)追蹤：借助ByteBuddy在Connection.close()做埋點(diǎn)，打印堆棧，發(fā)現(xiàn)某分支在異常時(shí)未執(zhí)行close。解決：1)統(tǒng)一使用try-with-resources語法；2)在finally塊顯式歸還連接；3)設(shè)置removeAbandonedTimeout=300s，logAbandoned=true，臨時(shí)自愈；4)壓測腳本增加“連接池指標(biāo)”斷言，防止回歸。48.闡述“混沌工程”在性能測試中的價(jià)值，并設(shè)計(jì)一個(gè)針對支付網(wǎng)關(guān)的混沌實(shí)驗(yàn)。答案：價(jià)值：-驗(yàn)證系統(tǒng)在性能拐點(diǎn)下的韌性；-提前暴露隱藏瓶頸，避免生產(chǎn)突發(fā)故障；-為自動(dòng)擴(kuò)縮容策略提供數(shù)據(jù)支撐。實(shí)驗(yàn)設(shè)計(jì)：目標(biāo)：驗(yàn)證支付網(wǎng)關(guān)在TPS600時(shí)，若數(shù)據(jù)庫主節(jié)點(diǎn)延遲增加80ms，系統(tǒng)是否仍滿足P99≤1s、錯(cuò)誤率≤0.2%。步驟：1)穩(wěn)態(tài)假設(shè)：歷史數(shù)據(jù)表明600TPS時(shí)P99=550ms，錯(cuò)誤率0.05%。2)實(shí)驗(yàn)組：使用ChaosBlade對MySQL注入網(wǎng)絡(luò)延遲tcqdiscadddeveth0rootnetemdelay80ms，持續(xù)5min。3)監(jiān)控：Prometheus采集P99、錯(cuò)誤率、訂單流水一致性；Grafana實(shí)時(shí)告警。4)穩(wěn)態(tài)差異：P99升至980ms，錯(cuò)誤率0.08%，仍在SLA內(nèi)；但訂單一致性100%，無臟寫。5)擴(kuò)容驗(yàn)證：觸發(fā)HPA，Pod從10擴(kuò)至14，P99回落至720ms，證明彈性有效。6)復(fù)盤：輸出《混沌實(shí)驗(yàn)報(bào)告》，將80ms延遲場景納入性能基線，后續(xù)每季度回歸。六、綜合設(shè)計(jì)題（30分）49.某社交APP上線“短視頻點(diǎn)贊”功能，技術(shù)棧：SpringCloudGateway+RedisCluster+MySQL8.0+Kafka+ES。業(yè)務(wù)要求：-支持5萬QPS點(diǎn)贊寫操作；-點(diǎn)贊狀態(tài)讀取P99≤80ms；-消息不能丟失；-可橫向擴(kuò)展。請給出：1)性能測試策略（含場景、數(shù)據(jù)模型、環(huán)境配置）；2)關(guān)鍵監(jiān)控指標(biāo)與閾值；3)潛在瓶頸與調(diào)優(yōu)預(yù)案；4)報(bào)告模板大綱。答案：1)策略場景：-寫場景：5萬QPS點(diǎn)贊，用戶行為模型80%重復(fù)點(diǎn)贊（冪等），20%新點(diǎn)贊；-讀場景：15萬QPS查詢點(diǎn)贊狀態(tài)，緩存命中率95%；-混合場景：讀寫比例3:1，持續(xù)30min，梯度遞增到目標(biāo)QPS。數(shù)據(jù)模型：-用戶池5000萬，視頻池1000萬，采用Zipf分布模擬熱點(diǎn)；-預(yù)置點(diǎn)贊記錄3億條，Redis緩存過期策略LRU，MySQL分庫分表按video_id分128表。環(huán)境：-容器化K8s，Gateway20Pod，Redis16主16從，MySQL32核128GB×8實(shí)例，Kafka12分區(qū)，ES12節(jié)點(diǎn)