前段時間在錄制，增強，整合
LoadRunner腳本，期間兩次遇到了中文亂碼問題。在此記錄一下中文亂碼問題的解決辦法。
一、錄制回放中文亂碼
我錄制登陸的腳本，用戶名中出現中文，回放的時候總是提示登陸失敗。如下圖：
圖1 LR回放中文亂碼
解決中文亂碼可以在錄制的時候在Virtual User Gen的 Tools->Recoding Options -> Advanced -> Support charset -> UTF-8。重新錄制后中文亂碼問題得到解決。
二、整合腳本中文亂碼
錄制增強（參數化，關聯，檢查點，事務）腳本后決定將幾個腳本整合在一起。于是新建了一個空的腳本，將登陸退出公用操作分別放在vuser_init和vuser_end中，其他操作放在各自的Action中。整理完成回放后又出現中文亂碼。為解決這個問題，最關鍵的是要把本地GBK編碼的漢字轉換成UTF-8編碼格式的信息，為此我們引進loadrunner自帶的編碼函數lr_convert_string_encoding。
int lr_convert_string_encoding ( const char *sourceString, const char *fromEncoding, const char *toEncoding, const char *paramName);
該函數有4個參數，含義如下：
sourceString：被轉換的源字符串。
fromEncoding：轉換前的字符編碼。
toEncoding：要轉換成為的字符編碼。
paramName：轉換后的目標字符串。
實踐一：
lr_convert_string_encoding("登陸賬號",LR_ENC_SYSTEM_LOCALE, LR_ENC_UTF8, "Account");
web_submit_data("login.quick",
……
"Name=account", "Value={Account}", ENDITEM,
……
LAST);
回放腳本的時候依然報錯。查看lr_convert_string_encoding的解釋，它會在其轉換的字符串末尾加上\x00。在C語言中\X00是一個字符串的結束，而正是這個\x00的存在導致了腳本回放失敗。
實踐二：
char tmp[100]; lr_convert_string_encoding("登陸賬號",LR_ENC_SYSTEM_LOCALE, LR_ENC_UTF8, "Account"); strcpy(tmp,lr_eval_string("{Account}")); lr_save_string(tmp,"Account"); web_submit_data("login.quick", …… "Name=account", "Value={Account}", ENDITEM, …… LAST); |
通過strcpy和lr_save_string的處理屏蔽\x00的影響，
測試結果正常
在做
web項目的自動化端到端
測試時主要使用的是
Selenium WebDriver來驅動瀏覽器。Selenium WebDriver的優點是支持的語言多，支持的瀏覽器多。主流的瀏覽器Chrome、Firefox、IE等都支持，
手機上的瀏覽器
Android、IPhone等也支持，甚至還支持PhantomJS（由于PhantomJS跑測試時并不需要渲染元素，所以執行速度快）。
但是我在使用Selenium WebDriver時，遇到了很多坑。這些問題，有的是因為Selenium WebDriver與瀏覽器不同版本之間兼容性的問題，有的是Selenium WebDriver本身的bug，當然也不乏自己對Selenium WebDriver某些功能理解不透徹。我花時間總結了一下，分享給大家，希望大家以后遇到問題可以避過這些坑，少走彎路。另外也總結了一些使用WebDriver的比較好的實踐，也一并分享給大家。
WebDriver每次啟動一個Firefox的實例時，會生成一個匿名的profile，并不會使用當前Firefox的profile。這點一定要注意。比如如果訪問被測試的web服務需要通過代理，你想直接設置Firefox的代理是行不通的，因為WebDriver啟動的Firefox實例并不會使用你這個profile，正確的做法是通過FirefoxProfile來設置。
public WebDriver create() { FirefoxProfile firefoxProfile = new FirefoxProfile(); firefoxProfile.setPreference("network.proxy.type",1); firefoxProfile.setPreference("network.proxy.http",yourProxy); firefoxProfile.setPreference("network.proxy.http_port",yourPort); firefoxProfile.setPreference("network.proxy.no_proxies_on",""); return new FirefoxDriver(firefoxProfile); } |
通過FirefoProfile也可以設置Firefox其它各種配置。如果要默認給Firefox安裝插件的話，可以將插件放置到Firefox安裝目錄下的默認的plugin文件夾中，這樣即使是使用一個全新的profile也可以應用此plugin。
使用WebDriver點擊界面上Button元素時，如果當前Button元素被界面上其他元素遮住了，或沒出現在界面中（比如Button在頁面底部，但是屏幕只能顯示頁面上半部分），使用默認的WebElement.Click()可能會觸發不了Click事件。
修正方案是找到該頁面元素后直接發送一條Click的JavaScript指令。
((JavascriptExecutor)webDriver).executeScript("arguments[0].click();", webElement);
當進行了一些操作發生頁面跳轉時，最好加一個Wait方法等待page load完成再進行后續操作。方法是在某個時間段內判斷document.readyState是不是complete。
protected Function<WebDriver, Boolean> isPageLoaded() { return new Function<WebDriver, Boolean>() { @Override public Boolean apply(WebDriver driver) { return ((JavascriptExecutor) driver).executeScript("return document.readyState").equals("complete"); } }; } public void waitForPageLoad() { WebDriverWait wait = new WebDriverWait(webDriver, 30); wait.until(isPageLoaded()); } |
如果頁面有Ajax操作，需要寫一個Wait方法等待Ajax操作完成。方式與上一條中的基本相同。比如一個Ajax操作是用于向DropDownList中填充數據，則寫一個方法判斷該DropDownList中元素是否多余0個。
private Function<WebDriver, Boolean> haveMoreThanOneOption(final By element) { return new Function<WebDriver, Boolean>() { @Override public Boolean apply(WebDriver driver) { WebElement webElement = driver.findElement(element); if (webElement == null) { return false; } else { int size = webElement.findElements(By.tagName("option")).size(); return size >= 1; } } }; } public void waitForDropDownListLoaded() { WebDriverWait wait = new WebDriverWait(webDriver, 30); wait.until(isPageLoaded()); } |
以此類推，我們可以判斷某個元素是否呈現、某個class是否append成功等一系列方法來判斷ajax是否執行完成。
如果網站使用了JQuery的動畫效果，我們在運行測試的時候其實可以disable JQuery的animation，一方面可以加快測試的速度，另一方面可以加強測試的穩定性（如果啟用了Animation，使用WebDriver驅動瀏覽器時可能會出現一些無法預料的異常）。
((JavascriptExecutor)driver).executeScript("jQuery.fx.off=true");
由于WebDriver要驅動瀏覽器，所以測試運行的時間比較長，我們可以并行跑測試以節省時間。如果你使用的是maven構建工具，可以配置surefire plugin時，在configruation節點加入以下配置。
<parallel>classes</parallel>
<threadCount>3</threadCount>
<perCoreThreadCount>false</perCoreThreadCount>
當測試fail的時候，如果當前使用的WebDriver實現了TakesScreenshot接口，我們就可以調用相應的方法截下當前瀏覽器呈現的web頁面，這樣有利于快速定位出錯的原因。
public void getScreenShot() { if (webDriver instanceof TakesScreenshot) { TakesScreenshot screenshotTaker = (TakesScreenshot) webDriver; File file = screenshotTaker.getScreenshotAs(savePath); } } |
如果頁面彈出了瀏覽器自帶的警告框（使用JavaScript的Alert方法），Selenium WebDriver在點選次警告框時會偶發性失敗。具體原因還未查明。解決方案是盡量不使用Alert方法的警告框，而是自己實現模式窗口（比如Jquery UI的模式窗口）來實現警告框效果。這樣即保證了測試的穩定性，另外我們自己可以控制警告框的樣式，給用戶帶來更好的體驗。
經常更新Selenium的版本。注意經常上Selenium的官網看是否發布了新的版本，新的版本都修復了那些bug，如果包含你遇到的bug，就可以升級到目前的版本。
首先簡要介紹一下我們的系統。我們整個系統中，可視化的應用（
web，APP）都是基于后端的saasapi。我們的saasapi采用rest風格，采用http協議，以json作為數據載體。所以，對后端的api接口進行
測試很有必要。
用到的技術包括：maven、junit4，json開發包、hudson、jdbc等等。
1.項目目錄結構（采用maven）
2.用例組織和規則約束
用例組織
例如：trackSegListWithTime（軌跡分段）、segTrackData（軌跡點顯示）接口屬于我的車模塊。那么就在src/test/java源文件夾下面建立一個我的車模塊包com.cpsdna.saasapi.test.vehicle，然后新建測試接口的類: TrackSegListWithTimeTest.java、 SegTrackDataTest.java
命名規則
測試類命名規則：接口名稱+Test，例如SegTrackDataTest.java（軌跡點顯示接口的測試類）
方法命名規則：test+方法意義，例如testSegTrackDataWithNoObjId（以沒有objId參數方式測試segTrackData接口 ）
3.測試方法步驟
1.聲明參數變量
3.組裝發送的json報文，把參數變量加入其中
4.向服務器端發送json
5.接收從服務器端返回的信息（json或者其它）
6.通過json開發包（json-lib，gson）解析從服務器返回的json
7.添加斷言（預期的結果和解析的實際結果是否一致）
下面給一個實例：
我認識一個朋友，也是
程序員出身，他在一家還不錯的外企上班，每個月工資收入也就差不多15K，五年的
工作經驗了，在他面前，我算是小弟。那天我們幾個朋友一起打完球就去附近的飯館吃飯，環境還不錯，于是就邊吃邊聊工作、賺錢的事情。
那天了解到，他不僅拿著15K的高薪，業余還有著更高的收入，從聊天中，我總結了幾點程序員賺錢的技巧，分享給大家，也許你可以參考一下，哪天發財了記得回到這篇
文章中來贊一下。
利用Adsense可以將廣告發布到你的網站上去，通過訪客點擊廣告來賺取傭金。這似乎是一個很不錯的主意，如果你有一個不錯的創意，寫一個網站對于程序員的你應該不難，網站放上Adsense廣告，推廣、引流、收美金。
首先，他的Android應用是免費的，他并不是靠賣App來賺錢，而是通過向App中投放廣告來賺取傭金的。如果你對Android技術非常熟悉，或者你的工作就是做Android開發，那么為什么不自己開發一個應用放到Android市場，為自己創造另一份收入。
三、參加一些開發者大賽
這是一種最實在的方法了，拿獎金，只賺不賠，不過前提是你得有足夠的實力。他參加過Google的Android開發者大賽，很得瑟的跟我們說那時候他贏得了2000美金，盡管不是很多，但從中也可以學到不少知識，至少，通過
學習，他可以自己開發Android應用來賺取廣告費了。
四、承接一些項目
當然這要花費你很大一部分時間，承接時你要考慮時間成本，至少這些時間要和你的工資相當。個人不怎么推薦這種方法，有時候周期會很長，很容易喪失積極性，不過也算是一種方法。
五、刷機、越獄
現在都是智能
手機，有些用久了，卡了，像電腦一樣要重裝系統，一些小白有教程都搞不定，這時候你可以借此開展刷機業務。還有iOS的越獄，這個需要你對iOS的操作非常熟悉。你可以將此業務掛到淘寶上，幫助買家實現他們要的功能。
六、做黑客
黑入銀行，盜取前女友現任老公的所有錢，哈哈，開玩笑了。不過，做一名優秀的計算機黑客確實可以幫你賺取很大一筆收入，比如幫助一些企業提高計算機網絡的安全性、做一些抵御攻擊的積極措施等。
這是我們討論結果的幾個要點，因人而異，如果你要更好的建議，歡迎在評論中告訴我們。
回答：本期話題分幾個要素點，我將根據命題劃分的幾個關鍵詞：緊急情況，壓縮，測試周期，來一起分析探討。
項目中難免會碰到很多“緊急情況”，如：
1、需求變更
客戶是善變的，我們必須伺候好客戶，不是么？沒有任何理由，他們要變更需求，一般情況下，最為乙方、丙方只有服從。
2、項目外包
很少有人碰到過吧？不過的確存在！項目進行到一半時由于自身團隊或者高層決策、成本等方面上的要求，直接將項目外包出去，或者重新讓一個項目團隊接手。
3、開發設計架構存在明顯嚴重缺陷
顯然，架構師、項目經理等沒有在前期做好評審和確認，但是很多項目，尤其是政府項目團隊成員很隨意，反正是有扶持款項。但這不是質量低下的理由！
4、不確定因素造成人員減少
如核心員工跳槽離職、女同事懷孕、家里生老病死等。
5、客戶要求提前上線
在交付階段，再次回到客戶，他是老大，出錢的，給項目的！甲方要求提前項目上線，這不得不加快進度，不是么？
關鍵點把握——“壓縮”
綜合上述我列舉的幾個原因，在項目決策和進度上已經批復下來，我們必須得“壓縮”進度安排。這里明顯不存在溝通、協商的必要了，或者說與相關部門、人員溝通/協商無效了。
但是對于我們測試團隊的“測試周期”，個人認為，有必要澄清或者繼續不斷與相關涉眾進行溝通和協商！畢竟整個周期被砍，直接最大影響的是我們測試部門同事！
這里根據之前列舉的5大理由，我會有側重地整理下解決方案：
1、需求一旦變更，項目團隊前面階段也肯定有影響，開發需要重新設計編碼，然后才是到測試階段。由于需求變更是客戶方提出的，我們有權利去交涉爭取最長“測試周期”。這里作為測試經理必須和項目經理統一戰線，和客戶方達成共識。因項目后期客戶自身提出的臨時需求變成要求，本不在合約范圍內，所以綜合已有的項目計劃和人員安排，在強制要求“壓縮”進度、或者保證原有進度的情況下，個人認為必須給客戶列舉出詳細的測試風險和影響要素。讓客戶方明確在進度被壓縮的前提下，我們能保證的質量效果和最佳狀態！知道風險是多方面必須一起承擔的。
2、項目突然被外包給別人，有點不可思議！但是整個項目被第三方接手，這里的交接情況，主要是新項目組對需求的快速把握、理解，開發方對項目架構、設計及代碼的熟悉都是不得不去考慮的。這樣對于測試團對來說，只能延后開始執行測試時間點，那勢必得把握測試要素的重點。個人建議按測試優先級、功能重要等級進行分類和劃分，給客戶方一個明確能保證質量的測試業務點清單。畢竟不可能在短時間項目被重新分包情況下，讓測試團隊控制什么進度來交付產品/項目。這個是整個項目進度的問題。
3、開發設計有嚴重問題。這個是自己團隊得承擔的責任！但是也因此影響到了測試部門人員。我們在開發人員緊急處理問題時，可以同步參與
單元測試、
接口測試等。因為已經大架構上錯誤了，測試人員協助開發人員一起確保系統設計、搭建沒有問題，其實是不能再出問題！
4、非受迫性減員很普遍，但是各項目組或者總的測試團隊負責人/測試項目經理必須分配好冗余資源進行補充，自己得多承擔責任。作為缺崗人員的備份者，更加要協調好剩余同事的任務安排，穩定軍心。
5、客戶要求趕工上線，正常情況下不能保證質量是否完全可靠，同問題1，得讓他們承擔接受潛在風險！上線交付是個很嚴肅的過程，對系統功能、性能、安全、穩定性，軟、硬件環境要求必須都滿足上線的前提，才能正式交付，客戶在計劃外要求提前上線，除去自己業務方面需求，沒有對項目團隊有啥合理理由或者要求，我們作為測試團隊，得把握其上線要求的最佳業務點，如某個功能模塊一定要運行正常穩定，有側重的去測試該部分，若他們可以接受條件的話。
其實上述方面我還是側重與責任方進行交流溝通！雖然已經被壓縮了進度，但有些情況必須闡明，才能安心工作，對于測試部門，測試經理也有義務進行責任承擔的同時，給予同事們最大程度保護！
對于傳統的加班加點，加人加米等方式，這里我其實不想多說，因為這些都是非正常的要求，才稱之為“緊急情況”，所以除去那些人力、費用、資源等成本不說，在項目進度，這里主要是測試進度加快情況下，只能先理清思路，針對不同要求去協商并溝通，爭取最佳的效果吧。盡可能保證項目在預期內打到理想的最好質量狀態。
我個人是沒有見過被壓縮進度下，又要做到很好，又要滿足各種要求的！這不現實！這里只是給出最可能的、理想的、較好的處理方式和技巧而已~
希望其他大神補充，指正！
測試代碼來自 Progremming Erlang。
Erlang： R13B (erts-5.7.1)， 啟動參數 +P 5000000
系統： Window XP
CPU： E8200 2.66G 雙核
內存： 4G
Erlang R13B (erts-5.7.1) [smp:2:2] [rq:2] [async-threads:0] Eshell V5.7.1 (abort with ^G) 1> c(processes). {ok,processes} 2> processes:max(1000000). Maximum allowed processes:5000000 Process spawn time = 2.703(2.688) microseconds ok 3> processes:max(1000000). Maximum allowed processes:5000000 Process spawn time = 3.203(2.938) microseconds ok 4> processes:max(1000000). Maximum allowed processes:5000000 Process spawn time = 3.25(3.015) microseconds ok |
結果：
創建100W，平均3us左右。因為物理內存比較多。測試時內存高峰在1.2G左右, 由此可以估計一下進程的內存消耗。
測試創建200W, 150W都不能正常運行。測試時，內存到1.8G以上時，werl進程死循環。不能結束。
在WINDOW下，單進程的內存不能超過2G。可見，進程的上限也就100W多一點吧。如果加上其它開銷。單個結點能創建的進程數量還會少很多。
看下測試代碼 for函數的編寫并不是最優化的方式，改成尾遞歸形式：
for(I, N, F) -> for_h(I, N, F, []).
for_h(_N, _N, _, L) -> L;
for_h(I, N, F, L) -> for_h(I+1, N, F, [F()|L]).
再測試：
5> c(processes). {ok,processes} 6> processes:max(1000000). Maximum allowed processes:5000000 Process spawn time = 1.891(1.64) microseconds ok 7> processes:max(1000000). Maximum allowed processes:5000000 Process spawn time = 2.266(1.641) microseconds ok 8> processes:max(1000000). Maximum allowed processes:5000000 Process spawn time = 2.234(1.625) microseconds ok |
結果在2us左右，看來尾遞歸還是影響挺大。
回答：與其說考核成果，不如我們來稱之為對測試結果的分析更為準確。
主要可以考慮以下幾個方面：
1、性能測試需求是否覆蓋完整
業務不僅是
功能測試的根本，也是性能測試的前置條件。一個成果性能測試肯定是最大最優化覆蓋了業務路徑，包括核心業務功能模塊和邏輯。
2、性能測試計劃是否合理
a）測試前計劃所需的軟、硬件環境配置
包括服務器CPU/Mem/HD等，還有網絡帶寬和路由/交換機等網絡拓撲。其對整個測試結果起到決定性作用，也對測試代理機和工具等給予支持。
b）測試進度安排是否充分
這里主要指對于測試方案制定、測試腳本開發、測試執行、測試結果分析總結等一系列時間節點是否滿足整個項目測試計劃和進度。我們知道性能測試比較依賴環境、工具等，若該階段花費太多時間成本，對整個測試項目會有嚴重影響。
3、性能測試方案是否有效
測試方案及策略是整個性能測試的指導性綱要，對于測試方法、技術、選擇的業務腳本，都得在性能測試方案中體現。
4、性能測試腳本是否高效
這里已經默認選擇了充分的業務場景進行測試。對于整個性能測試結果來說，核心部分就是開發的測試腳本，能夠用最高效的代碼來執行每一個業務功能，充分、完整的覆蓋所有路徑，則可以保障測試結果的有效和整個性能測試的質量。另外，腳本本身如開發之代碼，過多調用進程和不釋放內存等低質量語句，會使得測試執行變本加厲，從而影響到整個測試，甚至產生的結果會有嚴重差異。
5、性能測試執行日志是否加載
這里注意不是整個測試結果數據，是執行測試時每個細節、步驟的日志信息。若性能測試執行時不開啟或開發產生日志信息，則丟失了第一時間的問題列表數據，對于日后分析帶來不便。
6、性能測試結果分析是否到位
對于完成的性能測試結果，我們基本會使用圖表形式來直觀查看測試情況，并通過結果數據如CPU/MEM占用率，吞吐量，響應時間等來量化服務器資源消耗和系統性能。但我們更加需要去把握幾個峰值或異常數據的節點，分析其產生的原因和當時的狀況，然后給出自己建言和想法，幫助開發去進行性能調優。
7、性能測試問題發現和總結
其實不僅僅是性能測試，每次完成測試后對測試整個過程和產生的問題進行整理，并作總結，幫助下次測試時避免再發生相同的問題，是必須進行的步驟，也是成功測試的有效手段。
8、所有過程是否文檔化
這個其實也不僅僅是性能測試，對于每次測試過程，無論功能、性能或者安全，都得文檔化，通過產生記錄、各階段的測試準入、準出等，來輔助相關測試人員等進行
工作。若有體系標準，如CMMI/ISO9001等，則更佳。
以上大致列舉了下性能測試及其成果度量時需要考慮的部分，通過周而復始的操作，比對前后性能測試過程與結果，這樣就可以不斷改進和提高性能測試的質量。說大點可就能考評自己性能測試是否高效、系統功能更優化的那些成果了。
純個人想法，請不吝指正。
在編寫代碼高亮腳本的時候，問了瓶子一個問題，就是在循環里處理刪除DOM元素的時候，會動態改變NodeList的length，所以
測試許久， 最后發現是這個問題，狂暈。但是期間談到了一個關于removeChild的時候在IE下無法回收內存的泄漏問題，他展示了一個EXT里針對IE使用的方 法：
var div=document.getElementById("div"); var first=div.firstChild,next=first; while(next){ var d=document.createElement("div"); d.appendChild(next); d.innerHTML=""; next=div.firstChild; } /////////////////////////////////////////////////// //簡單的removeChild方式： var div=document.getElementById("div"); var first=div.firstChild,next=first; while(next){ next.parentNode.removeChild(next); next=div.firstChild; } |
但是經過使用Drip工具（測試IE是否內存泄漏的工具，download），測試還是存在內存泄漏的問題，但是使用IE JS Leaks Detector卻啥也檢測不出來（全部的測試都檢測不出來，就連網上都吹捧的內存泄漏的方式也檢測不出來），還有使用了話說是Drip的增強版的sIEve(download)，也測試不出來。既然這樣，那就暫且信任Drip吧。下面幾種傳說中的內存泄漏的方式都是在Drip下測試的。
在開始講述之前，先大概了解一下javascript的GC機制：
垃圾回收進程嘗試推斷何時可以安全地回收不再使用的變量，通常是通過判定程序是否能夠通過變量之間形成的引用網絡到達該變量。當確信變量是不可達的，就在它上面標上可以回收的記號，并且在回收器的下一次清理中（可能在未來的任意時刻)釋放相關的內存。
也就是說，垃圾回收機制會定時的檢查程序中的對象，查看它是否跟別的對象之間已經完全斷開了引用鏈而“孤單一人”，這時，垃圾回收機制就會回收這個 對象的內存，否則，將不會回收。所以說，對象在使用完了之后，就應該被回收內存，而不是一直占用著內存不放，導致瀏覽器的內存使用量節節飆升。
第一種：既然上面談到了關于removeChild，那就從它開始吧，通過Drip測試，簡單的使用 removeChild刪除子節點的方式確實存在內存泄漏，但是使用了上面EXT使用的方式，也還是存在。經過一番搜索，有
文章說需要清除節點的全部屬性 來實現內存的正確回收，那就進行了下面的測試。結果通過將節點的屬性都delete掉之后，Drip顯示沒有內存泄漏了。
var div=document.getElementById("div"); var first=div.firstChild,next=first; while(next){ div.removeChild(next); for(var k in next){ delete next[k]; } next=div.firstChild; } |
第二種：將一個DOM對象和一個JS對象相互成為對方的屬性。對于這點，IE官方也都有說法：在IE6中，對于 javascript object內部，jscript使用的是mark-and-sweep算法，而對于javascript object與外部object(包括native object和vbscript object等等)的引用時，IE 6使用的才是計數器的算法。也就是說，IE 6對于純粹的Script Objects間的Circular References是可以正確處理的，可惜它處理不了的是JScript與Native Object(例如Dom、ActiveX Object)之間的Circular References。所以，當我們出現Native對象(例如Dom、ActiveX Object)與Javascript對象間的循環引用時，內存泄露的問題就出現了。當然，這個bug在IE 7中已經被修復了。（Fuck，難怪我用Drip測試不出來（系統是IE8的內核））。下面是我的一個測試：
function Encapsulator(element){ this.elementReference = element; element.expandoProperty = this; } function SetupLeak2(){ var obj=new Encapsulator(document.getElementById("test")); document.body.removeChild(document.getElementById("test")); //alert(document.getElementById("test").expandoProperty); 出現錯誤 //說明從element.expandoProperty ---> obj的引用已經斷開了 //但是從obj.elementReference到element的引用依然存在， //這樣的話在IE6下element就無法回收內存，但是其他瀏覽器的GC機制都會很好的處理了這個問題。 document.body.appendChild(obj.elementReference); } |
第三種：將事件處理函數放在定義它的函數的內部。這種情況之前就看到過，回想下自己以前編寫js的方式：外包一個自執行函數，里面定義閉包內的變量和功能函數，也不乏對事件處理程序的處理。這樣是否會造成IE下的內存泄漏呢？下面是兩個測試程序：
var test=function(){ var div=document.getElementById("test"); var i=0; while((i++) < 20){ (function(index){ var o=document.createElement("p"); o.innerHTML="AAA"; o.onclick=function(){ alert("haha,leap"); } div.appendChild(o); o.onclick=null; div.removeChild(o); })(i); } } function addEvent(){ var div=document.getElementById("event"); div.onclick=function(){ this.parentNode.removeChild(this); } } |
上面的一段程序也是從網上摘錄下來做測試的，在閉包中動態生成一個div元素，并給它添加事件，事件處理程序寫在閉包里面，也就是內涵在test函數里 面，可是在removeChild的時候，Drip下顯示還是內存泄漏了，即使是把它的onclick屬性設置為null也不行。第二個測試程序中，在事 件處理程序中通過removeChild刪除當前節點的時候，也顯示內存泄漏。
第四種：在創建DOM對象時插入script。這個還是第一次看到。即是通過createElement創建DOM元 素的時候，直接在字符串中插入了js代碼：document.createElement(“<div onclick=’foo();’>”)，但是這種方式只在IE下有效。通過測試下面的程序，在Drip中也確實顯示內存泄漏了
var leakMemory=function(){
for(i = 0; i < 5000; i++){
var parentDiv = document.createElement("<div onClick='foo()'>");
}
}
第五種：總是先將新創建的DOM對象插入到文檔后，在對其進行其他操作。對于這點，我想象不到它是如何造成內存泄漏 的。而且，它跟頁面優化的一些方式可能存在沖突。在某些情況下，在創建了DOM元素之后，先處理DOM的操作，最后才插入到文檔中，這樣可以避免盡可能的 由于reflow影響性能的情況。這可能就需要一個權衡了吧，因地制宜~
總結：
上面是本人通過使用Drip工具測試的結果，但是由于在sIEVE和JS Leaps Detector下測試都沒發現內存泄漏的情況，所以糾結的很。經過這一番折騰，也不枉自己一番倒騰倒騰吧，在以后的編寫代碼中，可以或多或少的去避免這 些不必要的可能造成內存泄漏的情況出現。
同時，如果有說錯的地方，歡迎指正，共同學習~~
一、Appium中，經常會遇到會遇到滑動操作，但往往用各種手勢操作后還是滑動不了，今天主要講下如何正確使用appium的手勢操作。系統環境為最新的iOS 7.1+ Xcode 5.1
首先講下滑動操作的幾個基本方法。
1.swipe操作，主要用于緩慢拖動，代碼示例
JavascriptExecutor js = (JavascriptExecutor) driver; HashMap<String, Double> swipeObject = new HashMap<String, Double>(); swipeObject.put("startX", startX); swipeObject.put("startY", startY); swipeObject.put("endX", endX); swipebject.put("endY", endY); swipeObject.put("duration", duration); swipeObject.put("element", Double.valueOf(((RemoteWebElement) element).getId())); js.executeScript("mobile: swipe", swipeObject); |
①X,Y可為coordinator，也可以是percent，duration單位為秒
②可以指定的element，也可以不指定
③appium mac端有swipe的按鈕可以試下
2.flick操作，類似swipe，但沒有duration，用于快速滑動，如ViewController的切換，代碼示例
JavascriptExecutor js = (JavascriptExecutor) driver; HashMap<String, Double> flickObject = new HashMap<String, Double>(); flickObject.put("startX", 0.8); flickObject.put("startY", 0.5); flickObject.put("endX", 0.2); flickObject.put("endY", 0.5); flickObject.put("element", Double.valueOf(((RemoteWebElement) element).getId())); js.executeScript("mobile: flick", flickObject);); |
3.scroll操作，專為iOS 7.x而生，官方的解釋如下
An unfortunate bug exists in the iOS 7.x Simulator where ScrollViews don't recognize gestures initiated by UIAutomation (which Appium uses under the hood for iOS). To work around this, we have provided access to a different function, scroll, which in many cases allows you to do what you wanted to do with a ScrollView, namely, scroll it!
簡而言之，iOS 7的系統ScrollView無法識別手勢操作，使用scroll方法可完美替代，代碼見例子
二、接下來以三個不同app的引導圖為例，分別為看游戲，云閱讀和云音樂，演示下不同方法實現的滑動操作
1.看游戲，引導圖以ScrollView引導，只需要使用srcoll方法即可
JavascriptExecutor js = (JavascriptExecutor) driver;
HashMap<String, String> scrollObject = new HashMap<String, String>();
scrollObject.put("direction", "right");
js.executeScript("mobile: scroll", scrollObject
2.云音樂，引導圖以ScrollView引導，分別為4張image
接口測試是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
接口測試適用于為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的接口，驗證其正確性和穩定性。接口測試同樣適用于一個上層系統中的服務層接口，越往上層，其測試的難度越大。
接口測試實施在多系統多平臺的構架下，有著極為高效的成本收益比，接口測試天生為高復雜性的平臺帶來高效的缺陷監測和質量監督能力。平臺越復雜，系統越龐大，接口測試的效果越明顯。
基于接口測試的重要性，以及它比較容易自動化的特性，通過持續集成的接口監控能夠及時的發現項目中存在的問題，這對持續運營的項目來說，非常重要。
二、接口測試的流程
1、 項目啟動后，測試人員要盡早找到開發人員拿到接口測試文檔
2、 獲取接口測試文檔后，就可以進行接口用例的編寫和調試
3、 接口用例編寫調試完成后，部署到持續集成的測試環境中，
4、 設定腳本運行頻率，告警方式等基本參數，進行接口的日常監控
5、 每日進行接口腳本的維護更新，接口異常的處理
三、編寫接口測試腳本
大部分性能工具都可以用來進行接口測試,jmeter就是一個好用的
性能測試工具，他也同樣可以用來進行接口測試，jmeter比較適用于CGI、webservice、DB等類型的接口測試。下面以websevice api接口為例說明如何編寫接口測試用例（本文側重于接口測試平臺的搭建，對于具體工具是使用只進行簡單介紹，對于工具不了解的，可以自行
百度）：
jimter接口腳本的編寫步驟如下：
1、 編寫接口請求
通過錄制或者查看接口文檔，編寫接口請求，進行調試，確保接口調試通過
對于http的請求來說，就是正確的填寫域名，查詢字符串，查詢參數等信息
2、 對接口的返回結果進行斷言
斷言的目的是對輸出結果進行判斷，確認接口測試結果是否有異常
這些
工作完成后，接口測試腳本就準備好了
四、生成接口測試報告
接口測試腳本運行后生成的是JTL（xml）格式的文件，這些文件不具備可讀性，因此我們要把他轉化為可以閱讀的html格式報告。
轉化的步驟如下：
1、 安裝ant工具
Ant是一個功能強大的打包編譯工具。我們使用他的目的是將xml文件轉化為html格式的文件
2、 找到jmeter自帶的xsl文件
Xml文件要轉化為html文件，需要編寫xsl文件，實際上,jmeter已經自帶了xsl文件，如果你不想自己定義格式的話，可以直接使用自帶的格式，這樣可以省不少事情。這些文件的位置位于jmeter的extras文件夾下，只需要簡單修改一些文件路徑配置就可以正常使用。
3、 編寫ant的buildfile文件
Ant自帶了把XML轉化為html的lib庫，因此，這個轉化也是相當簡單的，示例如下：
<target name="xslt-report" depends="_message_xalan"> <tstamp><format property="report.datestamp" pattern="yyyy/MM/dd HH:mm"/></tstamp> <xslt classpathref="xslt.classpath" force="true" in="${resultpath}/${test}-${TODAY}.jtl" out="${resultpath}/${test}-${TODAY}.html" style="${jmeter.extras}/jmeter-results-detail-report${style_version}.xsl"> <param name="showData" expression="${show-data}"/> <param name="titleReport" expression="${report.title}"/> <param name="dateReport" expression="${report.datestamp}"/> </xslt> </target> |
完整的buildfile文件，請自行百度
4、 運行ant命令，生成html文件
Cmd運行ant –buildfile xsl文件，你就可以生成html報告了
生成的測試報告如下：
五、部署到持續集成平臺
部署到持續集成平臺可以實現腳本的定時運行，這是接口測試的核心。
這里我們選用了jenkins,,jenkins是一個強大的持續集成系統，使用起來也很簡單。
使用步驟如下：
1、 安裝jenkins
Jenkins的安裝是非常簡單的
注意：請將jenkins安裝到一個空間比較大的系統盤中。因為jenkins運行起來，生成的文件比較占空間。
2、 安裝完成后，配置一個項目