2023軟件測(cè)試常見的筆試題目

　　在平平淡淡的日常中，我們都經(jīng)�？吹皆囶}的身影，借助試題可以更好地考查參試者所掌握的知識(shí)和技能。你所見過的試題是什么樣的呢？以下是小編幫大家整理的2023軟件測(cè)試常見的筆試題目，僅供參考，歡迎大家閱讀。

　　1、您認(rèn)為做好測(cè)試用例設(shè)計(jì)工作的關(guān)鍵是什么?

　　白盒測(cè)試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果

　　黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測(cè)試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題

　　2、問：一臺(tái)客戶端有三百個(gè)客戶與三百個(gè)客戶端有三百個(gè)客戶對(duì)服務(wù)器施壓，有什么區(qū)別?

　　300個(gè)用戶在一個(gè)客戶端上，會(huì)占用客戶機(jī)更多的資源，而影響測(cè)試的結(jié)果。線程之間可能發(fā)生干擾，而產(chǎn)生一些異常。

　　300個(gè)用戶在一個(gè)客戶端上，需要更大的帶寬。

　　IP地址的問題，可能需要使用IP Spoof來繞過服務(wù)器對(duì)于單一IP地址最大連接數(shù)的限制。

　　所有用戶在一個(gè)客戶端上，不必考慮分布式管理的問題;而用戶分布在不同的客戶端上，需要考慮使用控制器來整體調(diào)配不同客戶機(jī)上的用戶。同時(shí)，還需要給予相應(yīng)的權(quán)限配置和防火墻設(shè)置。

　　3、軟件配置管理的作用?軟件配置包括什么?

　　軟件配置管理(Software Configuration Management，SCM)是一種標(biāo)識(shí)、組織和控制修改的技術(shù)。軟件配置管理應(yīng)用于整個(gè)軟件工程過程。在軟件建立時(shí)變更是不可避免的，而變更加劇了項(xiàng)目中軟件開發(fā)者之間的混亂。SCM活動(dòng)的目標(biāo)就是為了標(biāo)識(shí)變更、控制變更、確保變更正確實(shí)現(xiàn)并向其他有關(guān)人員報(bào)告變更。從某種角度講，SCM是一種標(biāo)識(shí)、組織和控制修改的技術(shù)，目的是使錯(cuò)誤降為最小并最有效地提高生產(chǎn)效率。

　　軟件配置包括如下內(nèi)容：配置項(xiàng)識(shí)別、工作空間管理、版本控制、變更控制、狀態(tài)報(bào)告、配置審計(jì)

　　4、目前主要的測(cè)試用例設(shè)計(jì)方法是什么?

　　白盒測(cè)試：邏輯覆蓋、循環(huán)覆蓋、基本路徑覆蓋

　　黑盒測(cè)試：邊界值分析法、等價(jià)類劃分、錯(cuò)誤猜測(cè)法、因果圖法、狀態(tài)圖法、測(cè)試大綱法、隨機(jī)測(cè)試、場(chǎng)景法

　　5、什么是測(cè)試用例 什么是測(cè)試腳本 兩者的關(guān)系是什么?

　　為實(shí)施測(cè)試而向被測(cè)試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以及期望結(jié)果的一個(gè)特定的集合。

　　測(cè)試腳本是為了進(jìn)行自動(dòng)化測(cè)試而編寫的腳本。

　　測(cè)試腳本的編寫必須對(duì)應(yīng)相應(yīng)的測(cè)試用例

　　6、簡(jiǎn)述什么是靜態(tài)測(cè)試、動(dòng)態(tài)測(cè)試、黑盒測(cè)試、白盒測(cè)試、α測(cè)試 β測(cè)試

　　靜態(tài)測(cè)試是不運(yùn)行程序本身而尋找程序代碼中可能存在的錯(cuò)誤或評(píng)估程序代碼的過程。

　　動(dòng)態(tài)測(cè)試是實(shí)際運(yùn)行被測(cè)程序，輸入相應(yīng)的測(cè)試實(shí)例，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，判定執(zhí)行結(jié)果是否符合要求，從而檢驗(yàn)程序的正確性、可靠性和有效性，并分析系統(tǒng)運(yùn)行效率和健壯性等性能。

　　黑盒測(cè)試一般用來確認(rèn)軟件功能的正確性和可操作性，目的是檢測(cè)軟件的各個(gè)功能是否能得以實(shí)現(xiàn)，把被測(cè)試的程序當(dāng)作一個(gè)黑盒，不考慮其內(nèi)部結(jié)構(gòu)，在知道該程序的輸入和輸出之間的關(guān)系或程序功能的情況下，依靠軟件規(guī)格說明書來確定測(cè)試用例和推斷測(cè)試結(jié)果的正確性。

　　白盒測(cè)試根據(jù)軟件內(nèi)部的邏輯結(jié)構(gòu)分析來進(jìn)行測(cè)試，是基于代碼的測(cè)試，測(cè)試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判斷軟件的質(zhì)量，一般黑盒測(cè)試由項(xiàng)目經(jīng)理在程序員開發(fā)中來實(shí)現(xiàn)。

　　α測(cè)試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測(cè)試，也可以是公司內(nèi)部的用戶在模擬實(shí)際操作環(huán)境下進(jìn)行的受控測(cè)試，Alpha測(cè)試不能由程序員或測(cè)試員完成。

　　β測(cè)試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測(cè)試。開發(fā)者通常不在測(cè)試現(xiàn)場(chǎng)，Beta測(cè)試不能由程序員或測(cè)試員完成。

　　7、軟件測(cè)試分為幾個(gè)階段 各階段的測(cè)試策略和要求是什么?

　　和開發(fā)過程相對(duì)應(yīng)，測(cè)試過程會(huì)依次經(jīng)歷單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試四個(gè)主要階段：

　　單元測(cè)試：?jiǎn)卧獪y(cè)試是針對(duì)軟件設(shè)計(jì)的最小單位––程序模塊甚至代碼段進(jìn)行正確性檢驗(yàn)的測(cè)試工作，通常由開發(fā)人員進(jìn)行。

　　集成測(cè)試：集成測(cè)試是將模塊按照設(shè)計(jì)要求組裝起來進(jìn)行測(cè)試，主要目的是發(fā)現(xiàn)與接口有關(guān)的問題。由于在產(chǎn)品提交到測(cè)試部門前，產(chǎn)品開發(fā)小組都要進(jìn)行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測(cè)試是由開發(fā)人員來完成的。

　　系統(tǒng)測(cè)試：系統(tǒng)測(cè)試是在集成測(cè)試通過后進(jìn)行的，目的是充分運(yùn)行系統(tǒng)，驗(yàn)證各子系統(tǒng)是否都能正常工作并完成設(shè)計(jì)的要求。它主要由測(cè)試部門進(jìn)行，是測(cè)試部門最大最重要的一個(gè)測(cè)試，對(duì)產(chǎn)品的質(zhì)量有重大的影響。

　　驗(yàn)收測(cè)試：驗(yàn)收測(cè)試以需求階段的《需求規(guī)格說明書》為驗(yàn)收標(biāo)準(zhǔn)，測(cè)試時(shí)要求模擬實(shí)際用戶的運(yùn)行環(huán)境。對(duì)于實(shí)際項(xiàng)目可以和客戶共同進(jìn)行，對(duì)于產(chǎn)品來說就是最后一次的系統(tǒng)測(cè)試。測(cè)試內(nèi)容為對(duì)功能模塊的全面測(cè)試，尤其要進(jìn)行文檔測(cè)試。

　　單元測(cè)試測(cè)試策略：

　　自頂向下的單元測(cè)試策略：比孤立單元測(cè)試的成本高很多，不是單元測(cè)試的一個(gè)好的選擇。

　　自底向上的單元測(cè)試策略：比較合理的單元測(cè)試策略，但測(cè)試周期較長(zhǎng)。

　　孤立單元測(cè)試策略：最好的單元測(cè)試策略。

　　集成測(cè)試的測(cè)試策略：

　　大爆炸集成：適應(yīng)于一個(gè)維護(hù)型項(xiàng)目或被測(cè)試系統(tǒng)較小

　　自頂向下集成：適應(yīng)于產(chǎn)品控制結(jié)構(gòu)比較清晰和穩(wěn)定;高層接口變化較小;底層接口未定義或經(jīng)�？赡鼙恍薷�;產(chǎn)口控制組件具有較大的技術(shù)風(fēng)險(xiǎn)，需要盡早被驗(yàn)證;希望盡早能看到產(chǎn)品的系統(tǒng)功能行為。

　　自底向上集成：適應(yīng)于底層接口比較穩(wěn)定;高層接口變化比較頻繁;底層組件較早被完成。

　　基于進(jìn)度的集成

　　優(yōu)點(diǎn)：具有較高的并行度;能夠有效縮短項(xiàng)目的開發(fā)進(jìn)度。

　　缺點(diǎn)：樁和驅(qū)動(dòng)工作量較大;有些接口測(cè)試不充分;有些測(cè)試重復(fù)和浪費(fèi)。

　　系統(tǒng)測(cè)試的測(cè)試策略：

　　數(shù)據(jù)和數(shù)據(jù)庫(kù)完整性測(cè)試;功能測(cè)試;用戶界面測(cè)試;性能評(píng)測(cè);負(fù)載測(cè)試;強(qiáng)度測(cè)試;容量測(cè)試;安全性和訪問控制測(cè)試;故障轉(zhuǎn)移和恢復(fù)測(cè)試;配置測(cè)試;安裝測(cè)試;加密測(cè)試;可用性測(cè)試;版本驗(yàn)證測(cè)試;文檔測(cè)試

　　8、軟件測(cè)試各個(gè)階段通常完成什么工作?各個(gè)階段的結(jié)果文件是什么?包括什么內(nèi)容?

　　單元測(cè)試階段：各獨(dú)立單元模塊在與系統(tǒng)地其他部分相隔離的情況下進(jìn)行測(cè)試，單元測(cè)試針對(duì)每一個(gè)程序模塊進(jìn)行正確性校驗(yàn)，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能。生成單元測(cè)試報(bào)告，提交缺陷報(bào)告。

　　集成測(cè)試階段：集成測(cè)試是在單元測(cè)試的基礎(chǔ)上，測(cè)試在將所有的軟件單元按照概要設(shè)計(jì)規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達(dá)到或?qū)崿F(xiàn)相應(yīng)技術(shù)指標(biāo)及要求的活動(dòng)。該階段生成集成測(cè)試報(bào)告，提交缺陷報(bào)告。

　　系統(tǒng)測(cè)試階段：將通過確認(rèn)測(cè)試的軟件，作為整個(gè)給予計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行全面的功能覆蓋。該階段需要提交測(cè)試總結(jié)和缺陷報(bào)告。

　　9、黑盒測(cè)試和白盒測(cè)試是軟件測(cè)試的兩種基本方法，請(qǐng)分別說明各自的優(yōu)點(diǎn)和缺點(diǎn)!

　　黑盒測(cè)試的優(yōu)點(diǎn)有：比較簡(jiǎn)單，不需要了解程序內(nèi)部的代碼及實(shí)現(xiàn);與軟件的內(nèi)部實(shí)現(xiàn)無關(guān); 從用戶角度出發(fā)，能很容易的知道用戶會(huì)用到哪些功能，會(huì)遇到哪些問題;基于軟件開發(fā)文檔，所以也能知道軟件實(shí)現(xiàn)了文檔中的哪些功能;在做軟件自動(dòng)化測(cè)試時(shí)較為方便。

　　黑盒測(cè)試的缺點(diǎn)有：不可能覆蓋所有的代碼，覆蓋率較低，大概只能達(dá)到總代碼量的30%;自動(dòng)化測(cè)試的復(fù)用性較低。

　　白盒測(cè)試的優(yōu)點(diǎn)有：幫助軟件測(cè)試人員增大代碼的覆蓋率，提高代碼的質(zhì)量，發(fā)現(xiàn)代碼中隱 藏的問題。

　　白盒測(cè)試的缺點(diǎn)有：程序運(yùn)行會(huì)有很多不同的路徑，不可能測(cè)試所有的運(yùn)行路徑;測(cè)試基于代碼，只能測(cè)試開發(fā)人員做的對(duì)不對(duì)，而不能知道設(shè)計(jì)的正確與否，可能會(huì)漏掉一些功能需求;系統(tǒng)龐大時(shí)，測(cè)試開銷會(huì)非常大。

　　10、如何測(cè)試一個(gè)紙杯?

　　功能度：用水杯裝水看漏不漏;水能不能被喝到

　　安全性：杯子有沒有毒或細(xì)菌

　　可靠性：杯子從不同高度落下的損壞程度

　　可移植性：杯子在不同的地方、溫度等環(huán)境下是否都可以正常使用

　　兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等

　　易用性：杯子是否燙手、是否有防滑措施、是否方便飲用

　　用戶文檔：使用手冊(cè)是否對(duì)杯子的用法、限制、使用條件等有詳細(xì)描述

　　疲勞測(cè)試：將杯子盛上水(案例一)放24小時(shí)檢查泄漏時(shí)間和情況;盛上汽油(案例二)放24小時(shí)檢查泄漏時(shí)間和情況等

　　壓力測(cè)試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時(shí)會(huì)穿透

　　11、你自認(rèn)為測(cè)試的優(yōu)勢(shì)在哪里?

　　該面試也沒有固定不變的答案，但可參考以下幾點(diǎn)，并結(jié)合自身特點(diǎn)：

　　有韌性、有耐心、做事有條理性、喜歡面對(duì)挑戰(zhàn)、有信心做好每一件事情、較強(qiáng)的溝通能力、從以前的經(jīng)理處都得到了很好的評(píng)價(jià)表明我做的很好。

　　軟件測(cè)試工作的面試題目

　　1、什么是兼容性測(cè)試？兼容性測(cè)試側(cè)重哪些方面？

　　2、我現(xiàn)在有個(gè)程序，發(fā)現(xiàn)在Windows上運(yùn)行得很慢，怎么判別是程序存在問題還是軟硬件系統(tǒng)存在問題？

　　3、檢查系統(tǒng)是否有中毒的特征；

　　4、檢查軟件/硬件的配置是否符合軟件的推薦標(biāo)準(zhǔn)；

　　5、確認(rèn)當(dāng)前的系統(tǒng)是否是獨(dú)立，即沒有對(duì)外提供什么消耗CPU資源的服務(wù)；

　　6、如果是C/S或者B/S結(jié)構(gòu)的軟件，需要檢查是不是因?yàn)榕c服務(wù)器的連接有問題，或者訪問有問題造成的；

　　7、在系統(tǒng)沒有任何負(fù)載的情況下，查看性能監(jiān)視器，確認(rèn)應(yīng)用程序?qū)�CPU/內(nèi)存的訪問情況。

　　8、測(cè)試的策略有哪些？黑盒/白盒，靜態(tài)/動(dòng)態(tài)，手工/自動(dòng)，冒煙測(cè)試，回歸測(cè)試，公測(cè)（Beta測(cè)試的策略）

　　9、正交表測(cè)試用例設(shè)計(jì)方法的特點(diǎn)是什么？

　　10、用最少的實(shí)驗(yàn)覆蓋最多的操作，測(cè)試用例設(shè)計(jì)很少，效率高，但是很復(fù)雜；

　　11、對(duì)于基本的驗(yàn)證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復(fù)雜的缺陷，還是無能為力的；

　　12、具體的環(huán)境下，正交表一般都很難做的。大多數(shù)，只在系統(tǒng)測(cè)試的時(shí)候使用此方法。

　　13、描述使用bugzilla缺陷管理工具對(duì)軟件缺陷（BUG）跟蹤的管理的流程？標(biāo)記就是Bugzilla的狀態(tài)轉(zhuǎn)換圖。

　　14、你覺得bugzilla在使用的過程中，有什么問題？標(biāo)記界面不穩(wěn)定； 根據(jù)需要配置它的不同的部分，過程很煩瑣。流程控制上，安全性不好界定，很容易對(duì)他人的Bug進(jìn)行誤操作；沒有綜合的評(píng)分指標(biāo)，不好確認(rèn)修復(fù)的優(yōu)先級(jí)別。

　　15、描述測(cè)試用例設(shè)計(jì)的完整過程？需求分析 + 需求變更的維護(hù)工作；根據(jù)需求， 得出測(cè)試需求；設(shè)計(jì)測(cè)試方案，評(píng)審測(cè)試方案；方案評(píng)審?fù)ㄟ^后，設(shè)計(jì)測(cè)試用例，再對(duì)測(cè)試用例進(jìn)行評(píng)審。

　　軟件測(cè)試筆試的題目及答案

　　1、客戶交付一個(gè)性能測(cè)試項(xiàng)目，請(qǐng)闡述你的實(shí)施流程。

　　答案：

　　測(cè)試設(shè)計(jì)階段：

　　1)了解被測(cè)系統(tǒng)的性能需求，定義測(cè)試目標(biāo)和范圍;

　　2)了解系統(tǒng)的技術(shù)信息，如系統(tǒng)架構(gòu)等;

　　3)確定測(cè)試方案、進(jìn)度安排，并制定測(cè)試計(jì)劃，場(chǎng)景設(shè)置方案，及需要收集的測(cè)試數(shù)據(jù);

　　4)同相關(guān)人員協(xié)商討論測(cè)試方案;

　　5)準(zhǔn)備數(shù)據(jù)收集模板;不同項(xiàng)目的性能測(cè)試，需要收集的數(shù)據(jù)不同;針對(duì)性的制定一個(gè)模板，更符合需要;

　　測(cè)試環(huán)境準(zhǔn)備：

　　1)技術(shù)準(zhǔn)備;選擇性能測(cè)試工具;測(cè)試方案中涉及到的技術(shù)問題;測(cè)試數(shù)據(jù)的收集方案實(shí)現(xiàn);如：如何監(jiān)控系統(tǒng)資源等;

　　2)搭建測(cè)試環(huán)境;

　　3)創(chuàng)建初始數(shù)據(jù);如虛擬用戶使用的賬號(hào)等;

　　測(cè)試執(zhí)行階段：

　　1)錄制腳本;

　　2)調(diào)試腳本;

　　3)執(zhí)行場(chǎng)景;

　　4)收集測(cè)試數(shù)據(jù)，并簡(jiǎn)單整理;

　　測(cè)試分析階段：

　　1)分析測(cè)試數(shù)據(jù);

　　提交測(cè)試報(bào)告 。

　　2、解釋5個(gè)常用的性能指標(biāo)的名稱與具體含義。

　　答案：

　　并發(fā)：所有用戶在同一時(shí)刻對(duì)系統(tǒng)執(zhí)行操作，一般指做同一件事情或操作。

　　在線：所有用戶在一段時(shí)間內(nèi)對(duì)系統(tǒng)執(zhí)行操作。

　　請(qǐng)求響應(yīng)時(shí)間

　　從client端發(fā)出請(qǐng)求到得到響應(yīng)的整個(gè)時(shí)間;

　　包括：client端響應(yīng)時(shí)間+網(wǎng)絡(luò)響應(yīng)時(shí)間+Server端響應(yīng)時(shí)間。

　　事務(wù)請(qǐng)求響應(yīng)時(shí)間

　　完成相應(yīng)事務(wù)所用的時(shí)間;這個(gè)是性能測(cè)試中重點(diǎn)關(guān)注的指標(biāo)。

　　TPS(Transaction Per Second)

　　每秒鐘系統(tǒng)能夠處理的交易或事務(wù)的數(shù)量。它是衡量系統(tǒng)處理能力的重要指標(biāo)。TPS是LoadRunner中重要的性能參數(shù)指標(biāo)。

　　點(diǎn)擊率(Hit Per Second)

　　每秒發(fā)送的HTTP請(qǐng)求的數(shù)量;點(diǎn)擊率越大對(duì)Server的壓力越大。

　　資源利用率

　　對(duì)不同資源的使用程度，如CPU，I/O，內(nèi)存，……

　　3、寫出5個(gè)Loadrunner中常用函數(shù)，并對(duì)其中2個(gè)舉例說明用法。

　　答案：

　　字符串復(fù)制

　　strcpy(str，”Hello “) ;

　　字符串連接

　　strcat(str，”World !”);

　　lr_message(“str: %s”，str);

　　sprintf(s， “%s love %s.”， “I”， “ocean”); //產(chǎn)生：”I love ocean. ”

　　變量轉(zhuǎn)為參數(shù)，將變量str的值存到參數(shù)Param中

　　lr_save_string(str，”Param”);

　　參數(shù)復(fù)制

　　lr_save_string(lr_eval_string(“{Param}”)，”Param_1″);

　　參數(shù)轉(zhuǎn)為變量

　　strcpy(str1，lr_eval_string(“{Param_1}”));

　　4、簡(jiǎn)述LoadRunner的工作原理?

　　答案： loadrunner會(huì)自動(dòng)監(jiān)控指定的URL或應(yīng)用程序所發(fā)出的請(qǐng)求及服務(wù)器返回的響應(yīng)，它做為一個(gè)第三方(Agent)監(jiān)視客戶端與服務(wù)器端的所有對(duì)話，然后把這些對(duì)話記錄下來，生成腳本，再次運(yùn)行時(shí)模擬客戶端發(fā)出的請(qǐng)求，捕獲服務(wù)器端的響應(yīng)。

　　5、LaodRunner腳本中action()和init、end()除了迭代的區(qū)別還有其他嗎?

　　答案： 集合點(diǎn)只能插入到Action部分，vuser_init和vuser_end中不能插入集合點(diǎn)。action()和init、end()都可以插入事務(wù)點(diǎn)。

　　6、什么是集合點(diǎn)?設(shè)置集合點(diǎn)有什么意義?LoadRunner中設(shè)置集合點(diǎn)的函數(shù)是哪個(gè)?

　　答案： 集合點(diǎn)：是一個(gè)并發(fā)訪問的點(diǎn)，例如在測(cè)試計(jì)劃中，可能會(huì)要求系統(tǒng)能夠承受1000 人同時(shí)提交數(shù)據(jù)，在LoadRunner 中可以通過在提交數(shù)據(jù)操作前面加入集合點(diǎn)，這樣當(dāng)虛擬用戶運(yùn)行到提交數(shù)據(jù)的集合點(diǎn)時(shí)，LoadRunner 就會(huì)檢查同時(shí)有多少用戶運(yùn)行到集合點(diǎn)，如果不到1000 人，LoadRunner 就會(huì)命令已經(jīng)到集合點(diǎn)的用戶在此等待，當(dāng)在集合點(diǎn)等待的用戶達(dá)到1000 人時(shí)，LoadRunner 命令1000 人同時(shí)去提交數(shù)據(jù)，并發(fā)訪問的目的。

　　注意：集合點(diǎn)經(jīng)常和事務(wù)結(jié)合起來使用，常放在事務(wù)的前面，集合點(diǎn)只能插入到Action 部分，vuser_init和vuser_end中不能插入集合點(diǎn)。集合點(diǎn)函數(shù)如下：lr_rendezvous(“SubmitData”)

　　7、錄制Web腳本時(shí)，生成的腳本中存在亂碼該如何解決?

　　答案 ： 錄制腳本前，打開錄制選項(xiàng)配置對(duì)話框Record-Options，進(jìn)入到Advanced標(biāo)簽，先勾選”Support charset”，然后選擇中支持UTF-8再次錄制，就不會(huì)出現(xiàn)中文亂碼問題了。

　　8、HTML-based script與URL-based script的腳本有什么區(qū)別?

　　答案： 使用”HTML-based script”的模式錄制腳本，VuGen為用戶的每個(gè)HTML操作生成單獨(dú)的步驟，這種腳本看上去比較直觀;使用”URL-based script”模式錄制腳本時(shí)，VuGen可以捕獲所有作為用戶操作結(jié)果而發(fā)送到服務(wù)器的HTTP請(qǐng)求，然后為用戶的每個(gè)請(qǐng)求分別生成對(duì)應(yīng)方法。

　　通常，基于瀏覽器的Web應(yīng)用會(huì)使用”HTML-based script”模式來錄制腳本;而沒有基于瀏覽器的Web應(yīng)用、Web應(yīng)用中包含了與服務(wù)器進(jìn)行交互的Java Applet、基于瀏覽器的應(yīng)用中包含了向服務(wù)器進(jìn)行通信的JavaScript/VBScript代碼、基于瀏覽器的應(yīng)用中使用了HTTPS安全協(xié)議，這時(shí)使用”URL-based script”模式進(jìn)行錄制。

　　9、使用LoadRunner進(jìn)行綜合場(chǎng)景測(cè)試，如何設(shè)置能夠使被測(cè)系統(tǒng)所受壓力減輕，請(qǐng)分別加以說明。

　　答案： 若使被測(cè)系統(tǒng)所受壓力減輕，可從如下方面進(jìn)行綜合調(diào)解：

　　將測(cè)試腳本中think time值加大并在控制臺(tái)中按比例實(shí)現(xiàn)，此處think time指在transaction外部的時(shí)間;

　　Controller中Run-Time Setting的Pacing設(shè)置值加大;

　　虛擬用戶登錄時(shí)使用遞增策略，間隔稍長(zhǎng)。

【軟件測(cè)試常見的筆試題目】相關(guān)文章：

關(guān)于軟件測(cè)試筆試題目10-10

軟件測(cè)試筆試題及答案05-17

軟件測(cè)試之綜合類筆試12-31

騰訊校招軟件測(cè)試筆試經(jīng)驗(yàn)08-25

軟件測(cè)試工程師筆試試題02-14

華為Java筆試題目02-08

采編記者筆試題目02-08

護(hù)士招聘筆試題目02-09

銷售崗位筆試題目06-30