進(jìn)公司以來(lái)，對(duì)于LoadRunner的使用以及對(duì)性能測(cè)試的理解和認(rèn)識(shí)，一直都是一知半解，僅僅停留在基本腳本的編寫和優(yōu)化上，對(duì)于腳本對(duì)服務(wù)端的壓力和性能的測(cè)試，總是模模糊糊，沒(méi)有系統(tǒng)的認(rèn)識(shí)。經(jīng)過(guò)幾次跟同事的討論，碰撞，產(chǎn)生了一些思路，今夜涼風(fēng)習(xí)習(xí)，騎著車，腦海里任由思路上躥下跳，慢慢地變得規(guī)律起來(lái)，到家之后，略作整理，形成了一套重構(gòu)方案，將之前的一些牛角尖問(wèn)題解了開(kāi)來(lái)。后續(xù)會(huì)慢慢同步學(xué)習(xí)和實(shí)踐的經(jīng)驗(yàn)教訓(xùn)和心得。
1、獨(dú)立單個(gè)接口的腳本結(jié)構(gòu)，盡量避免接口之間的互相依賴，因?yàn)槲覀冏觥拘阅軠y(cè)試】的目的是測(cè)試服務(wù)端的性能，而不是邏輯或流程，那個(gè)屬于【接口測(cè)試】或【功能測(cè)試】的范疇；
2、剝離登錄、登出接口，放入init和end里；
3、每個(gè)原本就相對(duì)獨(dú)立的接口，按場(chǎng)景封裝到一個(gè)USR文件或Action里，便于分析不同接口對(duì)應(yīng)的服務(wù)端和DB的處理性能；
4、測(cè)試數(shù)據(jù)的準(zhǔn)備：現(xiàn)網(wǎng)數(shù)據(jù)或者創(chuàng)建數(shù)據(jù)；
a. 例如Phone數(shù)據(jù)，要根據(jù)實(shí)際估算量來(lái)選定數(shù)據(jù)源，不能無(wú)限制的使用，沒(méi)有意義；
b. 商戶數(shù)據(jù)，老用戶，新用戶，不同狀態(tài)的訂單數(shù)據(jù)，
5、原本互相依賴的接口，盡可能地剝離開(kāi)來(lái)，針對(duì)該接口所處理的業(yè)務(wù)，設(shè)計(jì)業(yè)務(wù)數(shù)據(jù)的準(zhǔn)備腳本：
以訂單接口為例：
a. 建立LR Test的服務(wù)類型，在手工測(cè)試和性能測(cè)試的數(shù)據(jù)庫(kù)沒(méi)有分離開(kāi)之前避免影響手工測(cè)試；
b. 取一組號(hào)碼創(chuàng)建該服務(wù)類型的店鋪；--數(shù)據(jù)庫(kù)查詢當(dāng)前50VUser，生成店鋪的效率；
c. 取同一組號(hào)碼發(fā)送對(duì)應(yīng)服務(wù)項(xiàng)目的訂單；--數(shù)據(jù)庫(kù)查詢當(dāng)前50VUser，生成訂單的效率，包括用戶訂單和商戶訂單；
d. 同一組號(hào)碼的店鋪執(zhí)行搶單；
e. 依次進(jìn)行，放在不同的USR文件里，分組執(zhí)行，比如b/c可以順序執(zhí)行，d可以隔天執(zhí)行；
6、將不同場(chǎng)景的腳本分發(fā)到不同的負(fù)載終端上執(zhí)行，模擬接近真實(shí)的線上場(chǎng)景；
階段I：
負(fù)載測(cè)試：對(duì)系統(tǒng)不斷加壓，直到飽和不能再壓了，目的是為了找到系統(tǒng)最大的負(fù)載能力，為性能調(diào)優(yōu)提供數(shù)據(jù)。
壓力測(cè)試：指將系統(tǒng)壓到一定的飽和程度，此時(shí)系統(tǒng)處理業(yè)務(wù)的能力，系統(tǒng)是否會(huì)出現(xiàn)錯(cuò)誤。
階段II：
配置測(cè)試：通過(guò)調(diào)整系統(tǒng)軟硬件環(huán)境，將系統(tǒng)調(diào)優(yōu)到最佳配置。
并發(fā)測(cè)試：通過(guò)模擬用戶并發(fā)訪問(wèn)某個(gè)模塊或接口，觀察系統(tǒng)是否會(huì)出現(xiàn)死鎖、處理速度是否明顯下降等性能問(wèn)題。
階段III：
基準(zhǔn)測(cè)試：在一定的軟件、硬件和網(wǎng)絡(luò)環(huán)境下，模擬一定數(shù)據(jù)量的VU運(yùn)行一種或多種業(yè)務(wù)，將測(cè)試數(shù)據(jù)作為基線數(shù)據(jù)，在系統(tǒng)調(diào)優(yōu)或評(píng)測(cè)過(guò)程中，通過(guò)運(yùn)行相同的業(yè)務(wù)場(chǎng)景來(lái)比較調(diào)優(yōu)效果。
可靠性測(cè)試：當(dāng)系統(tǒng)在一定的業(yè)務(wù)壓力下，持續(xù)運(yùn)行一段時(shí)間，觀察系統(tǒng)是否達(dá)到要求的穩(wěn)定性，比如無(wú)故障運(yùn)行多少天。
【原計(jì)劃細(xì)節(jié)】
1、基于梳理好的接口做用戶場(chǎng)景分析，甄別出需要做接口測(cè)試的和性能測(cè)試的接口；
2、采用當(dāng)前的運(yùn)行場(chǎng)景，執(zhí)行10次腳本，執(zhí)行過(guò)程中可以在40
3、分析baseline數(shù)據(jù)，從多維度檢查存在性能問(wèn)題的地方，并提交給開(kāi)發(fā)做優(yōu)化方案；
4、同步基于產(chǎn)品運(yùn)營(yíng)提供的期望并發(fā)用戶數(shù)+不同場(chǎng)景，換算成期望的性能targetline；
5、根據(jù)產(chǎn)線服務(wù)器配置和本地服務(wù)器配置的對(duì)比，粗略換算出當(dāng)前的baseline和targetline的差距；
6、評(píng)估不同優(yōu)化方案的可行性；
7、代碼調(diào)優(yōu)或配置調(diào)優(yōu)；
8、腳本驗(yàn)證，并更新baseline；
9、重復(fù)6、7、8；
吞吐量=（虛擬用戶數(shù)*在測(cè)試時(shí)間內(nèi)每個(gè)虛擬用戶數(shù) 發(fā)出的請(qǐng)求字節(jié)數(shù)）/測(cè)試時(shí)間，即單位時(shí)間內(nèi)服務(wù)器處理的字節(jié)數(shù)。
吞吐量應(yīng)該是隨著VU數(shù)量的增加而增大，當(dāng)系統(tǒng)出現(xiàn)性能瓶頸時(shí)，吞吐量就不會(huì)隨著VU的數(shù)量而增大了，而是趨于平衡，所以我們必須通過(guò)不斷添加VU來(lái)測(cè)試吞吐量的拐點(diǎn)，即服務(wù)器吞吐量的最大值。
吞吐率=吞吐量/測(cè)試時(shí)間：?jiǎn)挝粫r(shí)間從服務(wù)器返回的字節(jié)數(shù)，也可以指單位時(shí)間內(nèi)服務(wù)器處理客戶提交的請(qǐng)求數(shù)，是衡量網(wǎng)絡(luò)性能的一個(gè)重要指標(biāo)。
從事務(wù)的角度說(shuō)，如果把每次點(diǎn)擊作為一次提交事務(wù)來(lái)對(duì)待，那么TPS和每秒點(diǎn)擊率的概念是等同的。
注意：每秒點(diǎn)擊率是Web系統(tǒng)服務(wù)器處理的最小單位，但點(diǎn)擊一次不代表客戶端只向服務(wù)器端發(fā)送一個(gè)HTTP請(qǐng)求。僅僅反應(yīng)的是客戶端提交的請(qǐng)求數(shù)，而不能表現(xiàn)服務(wù)器端當(dāng)前承受的壓力，因?yàn)榉?wù)器端不一定會(huì)全部處理，有可能出現(xiàn)被拒絕，所以每秒點(diǎn)擊率不能直接反映服務(wù)器處理請(qǐng)求的能力。
