posts - 97,  comments - 5,  trackbacks - 0
          @import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

          性能壓測在活動測試中的應(yīng)用  《轉(zhuǎn)載》

                  第四季度運營活動頻頻,雙11 12等等,在這幾次活動測試中,感觸比較深刻的還是在抽獎活動的送獎問題上。曾經(jīng)出現(xiàn)過一次尷尬的事故:紅包送多了,假設(shè)每天本來限量100W,結(jié)果送出去了150W,多送了50W。且拋開該活動是否有帶來多大的宣傳效果,牽扯到支損,還是一件需要引起重視的事,得想些方法來避免這種故障發(fā)生。

          下面是某活動中在統(tǒng)計剩余獎池數(shù)量截取的一段代碼:


          實現(xiàn)的是更新剩余二等獎獎數(shù),及時統(tǒng)計到tair的工作,低流量下一般不會有問題,但是并發(fā)量大的時候,若同時有2個用戶抽到二等獎均取到同個SECOND_PRIZE_AMOUNT值,均需對其進行減1的工作,上次未操作完畢,后一次已經(jīng)取到開始處理,兩次操作后,只讓SECOND_PRIZE_AMOUNT值減了1, 但應(yīng)該是要減2,這樣累積多個用戶并發(fā)操作后,便會出現(xiàn)少算剩余獎數(shù)而多送獎的事故了。

          通過類似這種事故啟發(fā),并發(fā)的問題我們可以通過性能壓測模擬來測試這個問題,防止此類事故發(fā)生。以我們曾經(jīng)一活動為例,來說下如何通過簡單的性能壓測來驗證是否多送獎的問題。

          活動的內(nèi)容大概是這樣:購買一本電子書,將有機會獲得單筆購買的電子書價的1倍、或10倍、或100倍的紅包?;顒娱_始前,在后臺配好中獎的概率和不中獎的概率,再包括中獎概率中分別中1倍、中10倍、中100倍的概率,每天限制總金額M,不限數(shù)量,總金額一到,后面一律不中獎。

          測試目標:

          1.      保證全部獎項抽完后,實際中1倍、10100的概率與后臺配置一致;

          2.      保證實際送出去的紅包總金額不超過每天限制總金額;


          按照做數(shù)學(xué)題的方式,

          設(shè)后臺配置中獎的概率為p,中獎機會中中1倍概率為P1,中10倍、100倍分別為P10,P100,

          實際中獎概率為p’,中1倍概率為P’1,中10倍、100倍分別為P’10,P’100,

          n個中1倍紅包的金額為y1n,

          n個中10倍紅包的金額為y10n,

          n個中100倍紅包的金額為y100n,

          1倍紅包個數(shù)為c1,

          10倍紅包個數(shù)為c10,

          100倍紅包個數(shù)為c100,

          實際中紅包總個數(shù)為C ,

          每天限制總金額為M

          實際發(fā)送紅包總金額為M’;


          開始進行抽獎接口的壓測工作(具體性能測試方法與普通的接口性能壓測一樣),但需要注意:

          1.      并發(fā)用戶數(shù)盡量多些,讓每個隊列數(shù)至少有2到3個用戶(并發(fā)用戶數(shù)如果太少,上面提到的計數(shù)器統(tǒng)計故障可能無法測試出來);

          2.      壓測時間盡量長,目的是讓總transactions 個數(shù)盡量把所有獎覆蓋到,讓獎盡量全部抽完;

          壓測結(jié)束后,中獎的金額與個數(shù)情況均可通過埋點日志記錄統(tǒng)計得到,再由活動內(nèi)容可得:


          P’1 = c/ C ,    

          P’10 = c10 / C 

          P’100 = c100 / C

          結(jié)果比對下M’->M, P’1 ->P1, P’10 -> P10, P’100 -> P100 。

          如果統(tǒng)計結(jié)果出來,幾個實際概率值與配置的概率值仍有所偏差,可以再嘗試加長壓測時間,以努力將所有獎項全部抽完,多嘗試幾次壓測,記錄每次的抽獎情況。

          正常情況下,最后一個獎抽到的時間點之前所有事務(wù)數(shù)假設(shè)為T1,p’中  = C/T1, p’中 -> p ; 壓測時間夠長,當(dāng)M’無限趨近M,此時統(tǒng)計出來的各倍數(shù)概率正常會無限逼近配置值,若相差太大,便可能是問題了。

          后面以上述的這個性能壓測方法測試了幾個類似活動的抽獎概率和發(fā)獎情況,均有些幫助,也希望對大家有所啟發(fā)。每次的大型活動結(jié)束后,總是會留下一些可以對后續(xù)工作有所幫助的教訓(xùn),目前在活動測試中,除了送多的問題外,還有許多值得思考的問題,例如如何防惡意刷獎,這塊的測試與風(fēng)險預(yù)防感覺做得還不是很到位,也許也是個值得深究的方向



          天貓 軟件自動化測試開發(fā)

          posted on 2014-03-31 18:07 zouhui 閱讀(408) 評論(0)  編輯  收藏 所屬分類: 2.軟件測試 性能自動化
          <2014年3月>
          2324252627281
          2345678
          9101112131415
          16171819202122
          23242526272829
          303112345

          常用鏈接

          留言簿(2)

          隨筆分類(94)

          隨筆檔案(94)

          搜索

          •  

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 弥渡县| 米易县| 涟水县| 曲松县| 景德镇市| 林甸县| 麻阳| 高邮市| 策勒县| 怀安县| 讷河市| 永川市| 黄龙县| 金昌市| 秀山| 太保市| 通榆县| 香港| 霍邱县| 长沙市| 西华县| 新余市| 滦南县| 汶川县| 沅江市| 抚宁县| 雅安市| 铁岭市| 福贡县| 凤城市| 武功县| 常州市| 吉首市| 怀仁县| 宜章县| 曲周县| 稷山县| 弋阳县| 商城县| 祁东县| 潜江市|