實(shí)驗(yàn)室開放平臺(tái)測(cè)試報(bào)告

1、實(shí)驗(yàn)室開放平臺(tái)測(cè)試報(bào)告(v1.3)版本號(hào)修改詳情時(shí)間備注1.0完成了文檔草稿的撰寫2015-4-81.1添加了組件庫方面的用例2015-4-91.11修改了查看用戶信息等用例的細(xì)節(jié)2015-4-101.2填寫了用戶信息等用例的測(cè)試結(jié)果2015-4-101.3填寫了用戶動(dòng)態(tài)等用例的測(cè)試結(jié)果2015-4-111.31填寫了組件庫等用例的測(cè)試結(jié)果2015-4-121.4填寫了功能測(cè)試的測(cè)試結(jié)果2015-4-13本次測(cè)試的目標(biāo)系統(tǒng)是實(shí)驗(yàn)室開放平臺(tái)，本系統(tǒng)的主要功能包括：登陸、個(gè)人中心、任務(wù)管理、項(xiàng)目管理、風(fēng)險(xiǎn)管理、注銷等。相關(guān)文檔與本測(cè)試文檔相關(guān)的文檔有：實(shí)驗(yàn)室開放平臺(tái)設(shè)計(jì)文檔v1.3功能測(cè)試用例設(shè)計(jì)

2、文檔V1.4功能測(cè)試：功能測(cè)試就是對(duì)產(chǎn)品的各功能進(jìn)行驗(yàn)證，根據(jù)功能測(cè)試用例，逐項(xiàng)測(cè)試，檢查產(chǎn)品是否達(dá)到用戶要求的功能。本項(xiàng)目的功能測(cè)試采用等價(jià)類劃分，人工輸入驗(yàn)證的方法開展測(cè)試。（測(cè)試用例的設(shè)計(jì)參看文檔功能測(cè)試設(shè)計(jì)文檔）本項(xiàng)目的功能測(cè)試自2015年4月10日開始，截至4月13日，根4-據(jù)設(shè)計(jì)的測(cè)試用例，發(fā)現(xiàn)和修復(fù)defect/bug情況如下：既包括上述的測(cè)試用例，也包括一些顯而易見或其他情況下未涵蓋的用例。DEFECT/BUG數(shù)目-defect/bug數(shù)目60類別A類別B類別C類別D類別E類別F截至到2015年4月15日，修復(fù)的defect/bug情況如下：圖表標(biāo)題45已修復(fù)未修復(fù)其中：在過去

3、的大致統(tǒng)計(jì)中，將近一半被修復(fù)的defect/bug在經(jīng)過兩次以上的修復(fù)過程才得以修復(fù)，大部分出現(xiàn)的defect/bug源于設(shè)計(jì)工作力度的不夠，以及編程人員的粗枝大葉和邏輯不嚴(yán)謹(jǐn)造成的?？捎眯詼y(cè)試（用戶體驗(yàn)測(cè)試）可用性測(cè)試旨在幫助開發(fā)團(tuán)隊(duì)了解來自用戶的反饋，并依此改善現(xiàn)有設(shè)計(jì)，修復(fù)之前沒有發(fā)現(xiàn)的問題，其具體實(shí)現(xiàn)方法是讓一群具有代表性的用戶對(duì)產(chǎn)品進(jìn)行典型操作，同時(shí)觀察員和開發(fā)人員在一旁觀察，聆聽，做記錄。針對(duì)本項(xiàng)目，我們把平臺(tái)部署后，邀請(qǐng)實(shí)驗(yàn)室其他成員登錄該平臺(tái)進(jìn)行體驗(yàn)，并請(qǐng)大家提出改進(jìn)意見同時(shí)，在事先不告知該平臺(tái)具體細(xì)節(jié)的情況下，觀察他們的上手情況。面是截至到4月15日上午，用戶的反饋情況（按人

4、次統(tǒng)計(jì)）：反饋類型：統(tǒng)計(jì)數(shù)量舉例備注平臺(tái)易用性/友好性37操作會(huì)新建太多選項(xiàng)卡功能性缺陷16注冊(cè)什么都不填并直接關(guān)閉可重現(xiàn)BUG5更改個(gè)人信息并提交有時(shí)沒有響應(yīng)二次提交后崩潰待重現(xiàn)BUG7上傳PDF文件后黑屏（？）越權(quán)操作3可查看并操作別人的閱讀收藏動(dòng)態(tài)平臺(tái)效率/反饋時(shí)間23登錄響應(yīng)時(shí)間太長其他未分類9統(tǒng)計(jì)信息指代模糊不清從上表的反饋統(tǒng)計(jì)中可以看到，用戶反映最多的問題是平臺(tái)的易用性和平臺(tái)的效率問題，其中平臺(tái)的易用性是被吐槽最多的。平臺(tái)效率上線之前已經(jīng)有所預(yù)估，但是稍許意外的是登錄動(dòng)作的響應(yīng)時(shí)間也達(dá)到了令用戶不舒服的程度。另外，根據(jù)用戶的反饋，在編輯長心得的時(shí)候，系統(tǒng)經(jīng)常出現(xiàn)停止響應(yīng)或假死的情況

5、，甚至在用戶數(shù)很低的條件下，這種情況依然存在，所以系統(tǒng)在經(jīng)受大數(shù)據(jù)檢驗(yàn)的能力上很欠缺。性能測(cè)試性能測(cè)試是通過自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。在本次測(cè)試中，將針對(duì)上述的功能進(jìn)行性能測(cè)試，檢查并評(píng)估在模擬環(huán)境中，系統(tǒng)對(duì)負(fù)載的承受能力，在大量虛擬用戶情況下，系統(tǒng)的吞吐能力和響應(yīng)能力，以及在預(yù)計(jì)的數(shù)據(jù)容量中，系統(tǒng)能夠容忍的最大用戶數(shù)。本次測(cè)試是針對(duì)實(shí)驗(yàn)室開放平臺(tái)的性能特征和系統(tǒng)的性能調(diào)優(yōu)而進(jìn)行的，主要需要獲得如下的測(cè)試指標(biāo)。1、系統(tǒng)的響應(yīng)能力：即在各種負(fù)載壓力情況下，系統(tǒng)的響應(yīng)時(shí)間，也就是從用戶端發(fā)起，到服務(wù)器端應(yīng)答返回所需要的時(shí)間，包括網(wǎng)絡(luò)傳輸時(shí)間和

6、服務(wù)器處理時(shí)間。2、應(yīng)用系統(tǒng)的吞吐率：即應(yīng)用系統(tǒng)在單位時(shí)間內(nèi)完成的交易量，也就是在單位時(shí)間內(nèi)，應(yīng)用系統(tǒng)針對(duì)不同的負(fù)載壓力，所能完成的交易數(shù)量。3、應(yīng)用系統(tǒng)的負(fù)載能力：即系統(tǒng)所能容忍的最大用戶數(shù)量，也就是在正常的響應(yīng)時(shí)間中，系統(tǒng)能夠支持的最多的客戶端的數(shù)量。目前實(shí)驗(yàn)室的情況為，常駐實(shí)驗(yàn)室的人員有30人左右，在上線對(duì)外開放之前，平臺(tái)通過局域網(wǎng)對(duì)內(nèi)開放。關(guān)鍵點(diǎn)描述KP)本次性能測(cè)試的關(guān)鍵點(diǎn)，就是查看平臺(tái)在并發(fā)壓力下的表現(xiàn)，即：支持的并發(fā)用戶數(shù)目和并發(fā)用戶發(fā)送頻率，以及在較大壓力下，系統(tǒng)的事務(wù)處理能力，并找出系統(tǒng)的性能瓶頸。性能測(cè)試環(huán)境其中具體的硬件和網(wǎng)絡(luò)環(huán)境如下服務(wù)器設(shè)備：器：寶業(yè)內(nèi)存嗣阿）：LnP

7、lR)CorefTM)i5-235QPCPU3.10GHz3.10GHz8.00GB&4僅接作垂統(tǒng)操作系統(tǒng)：Windows7網(wǎng)絡(luò)環(huán)境：WLAN（10M）數(shù)據(jù)庫：MySQLcommunity5.6.23測(cè)試場(chǎng)景：模擬實(shí)際使用過程中的場(chǎng)景，實(shí)驗(yàn)室的人員的日常訪問主要會(huì)進(jìn)行下面幾種操作：站內(nèi)隨便瀏覽；讀心得；讀文獻(xiàn)；按60%、20%、20%分配上述4個(gè)事務(wù)，起始分配兩個(gè)用戶，之后每15秒增加兩個(gè)用戶，一直到40個(gè)用戶并持續(xù)10分鐘，之后每30秒減少兩個(gè)用戶，直至為零。另外，設(shè)定錄制的思考時(shí)間是1-5秒之間的任意值。設(shè)定在用戶數(shù)目小于10的情況下為輕度負(fù)載，1025為中度負(fù)載，25人以上為重度負(fù)載。為

8、了考慮用戶的體驗(yàn)程度，結(jié)合用戶體驗(yàn)測(cè)試中的反饋，設(shè)定輕度負(fù)載下響應(yīng)時(shí)間的閾值為2s,中度負(fù)載下的響應(yīng)時(shí)間為4.5s,重度負(fù)載下的事務(wù)響應(yīng)時(shí)間是7s。測(cè)試結(jié)果分析：每秒點(diǎn)擊數(shù)與吞吐量，用戶數(shù)與吞吐量每秒點(diǎn)擊數(shù)反映了客戶端每秒向服務(wù)器端提交的請(qǐng)求數(shù)量，如果客戶端發(fā)出的請(qǐng)求數(shù)量越多，與之相對(duì)的吞吐量也應(yīng)該越大，并且發(fā)出的請(qǐng)求越多會(huì)對(duì)平均事務(wù)響應(yīng)時(shí)間造成影響，所以在測(cè)試過程中往往將這三者結(jié)合起來分析。如圖顯示的是每秒點(diǎn)擊數(shù)與吞吐量的復(fù)合圖。-IAHimprSKond-11網(wǎng)細(xì)雖1刖儀8偽U4CMHlEilMHCEH園僅HUfiU11K13HI彌HHlikdIK砂ITXAItK；ItHHUUKZtlZ3

9、4C34KHeX,ElmdiziriinLimimrm2.期Mju.eui-BU/HIMXBn.wIM.*WjtM住jtHUXH從圖中可以看出，兩種圖形的曲線都正常并且基本一致，說明服務(wù)器能較為及時(shí)的接受客戶端的請(qǐng)求，并能夠返回結(jié)果。對(duì)于用戶數(shù)和吞吐量的關(guān)系，初始用戶數(shù)比較少，相應(yīng)的吞吐量也會(huì)比較低，當(dāng)用戶數(shù)增加時(shí)，吞吐量會(huì)也會(huì)相應(yīng)增加。當(dāng)用戶數(shù)繼續(xù)增加，但吞吐量卻保持平穩(wěn)時(shí)，說明帶寬夠用如下圖所示：HwimVuKribiBrdUOhFwlajmiLfMQKI炳.MEMEHOCHIH.QHHXwMVbMO1.4K.0Mt.ildiWIHOMIJKOH!?W.MIBMjLS*g32W.au|2n

10、.nn如圖可以看到，隨著用戶數(shù)的增加，吞吐量基本保持穩(wěn)步上升的趨勢(shì)，說明服務(wù)器在現(xiàn)有網(wǎng)絡(luò)帶寬條件下基本能處理來自用戶的請(qǐng)求。上述考慮到以后該平臺(tái)需要對(duì)外開放，針對(duì)事務(wù)的響應(yīng)時(shí)間的分析在這里對(duì)上述各事務(wù)的響應(yīng)時(shí)間進(jìn)行分析，如下圖：其中，閱讀心得的響應(yīng)時(shí)間隨用戶數(shù)量的增加顯著增加，而隨意瀏覽和閱讀文獻(xiàn)的響應(yīng)時(shí)間變化相比較而言卻不顯著，結(jié)合心得的存儲(chǔ)分析其原因，是心得的存儲(chǔ)結(jié)構(gòu)和對(duì)圖片等資源的優(yōu)化程度不夠造成的，另外，對(duì)心得的顯示沒有采用“懶加載”等技術(shù)也大大增加了響應(yīng)時(shí)間，特別是對(duì)于長心得的響應(yīng)時(shí)間。在另一方面，查看URL各自的響應(yīng)時(shí)間和數(shù)據(jù)傳輸量，發(fā)現(xiàn)除了心得顯示之外，首頁的資源的請(qǐng)求數(shù)據(jù)量是最

11、多的。查看其頁面資源，發(fā)現(xiàn)圖片、css和JS的體積都比較大。之前用戶體驗(yàn)測(cè)試中有用戶反饋登錄等待的時(shí)間過長，雖然心得顯示的響應(yīng)時(shí)間在所有URL中是最長的，但考慮到其大量的時(shí)間在處理文檔結(jié)構(gòu)，所以除了改善文檔存取速度，精簡css、js等資源也是降低用戶等待時(shí)間的一種方式。URLnannfrPareintiiaiiactlcnnameAveragesizeCounrToialMinIdexAvgSrdDevhripaocaihatiBQ.iiaiiive-1dion.Trsritaslon盟&3707115.11S4&4煩目915.7httpi-VloMlho&tSOBIllafcliY敘曲1嵌很

12、=2帥42祕(mì)“弗2-42a7-b1O3-f145S4iba1abActionTransaction22tB450.1747.7747.7747.71.4hHpjVlocalhostfiOeDlafclrve.nDtecontent?id2E2E6lCe-AC7-4A53-ACDFAclionTransaciion105344.55345534-5：:：；-50.5查找系統(tǒng)瓶頸通常查找瓶頸時(shí)按以下順序，由易到難。服務(wù)器硬件瓶頸一網(wǎng)絡(luò)瓶頸f服務(wù)器操作系統(tǒng)瓶頸（參數(shù)配置）f中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫，web服務(wù)器等）f應(yīng)用瓶頸（SQL語句、數(shù)據(jù)庫設(shè)計(jì)、業(yè)務(wù)邏輯、算法等）。瓶頸通常是由服務(wù)器配置不當(dāng)

13、和資源不足造成的。例如，有問題的代碼可能會(huì)使用幾乎所有的計(jì)算機(jī)處理時(shí)間（CPU）并且會(huì)在服務(wù)器上造成性能瓶頸。同樣，物理內(nèi)存容量限制和服務(wù)器內(nèi)存管理不當(dāng)很容易導(dǎo)致服務(wù)器瓶頸。因此，在調(diào)查Web或Web應(yīng)用程序服務(wù)性能較低的其他原因前，應(yīng)先檢查服務(wù)器的CPU和物理內(nèi)存。CPU：度量ProcessorQueueLength會(huì)反映出出處理器瓶頸。一般而言，隊(duì)列長度持續(xù)大于4，則表示可能出現(xiàn)處理器擁塞。如圖所示，隊(duì)列的長度最高為53，平均值為4.458，說明隊(duì)列出現(xiàn)擁塞，處理器是系統(tǒng)的瓶頸。mi祀1|欽ejr.hwl-T2J:kw另外同查看度量ProcessTime（如圖所示），發(fā)現(xiàn)隨著Vuser的增

14、加，CPU使用率急劇增加，從第5分鐘開始，持續(xù)維持在100%，甚至在用戶數(shù)量下降后，也維持了幾分鐘時(shí)間，又證明了CPU是系統(tǒng)性能的瓶頸。PinC1HC4HHHMHF.W99KHWW.WIIWI2.MH.MH.!C-.MH1?.WILF?ItK*!lHZlfl凹gK.WEUKMl如UTK価M硬盤：由于服務(wù)器使用的是SSD,在這里不考慮硬盤的瓶頸。內(nèi)存：通過查看度量AvailableMbytes,可以查看可用內(nèi)存，進(jìn)而推斷內(nèi)存是否是性能的瓶頸。系統(tǒng)的可用內(nèi)存的情況如下圖粗線所示：可以看到，可用內(nèi)存一直維持在4400M的水平，已知服務(wù)器內(nèi)存容量為819M，所以整個(gè)過程中物理內(nèi)存使用率大約為(8192-4400)/8192x100%=46.29%,如果按物理內(nèi)存使用率不超過70%來要求