本期導(dǎo)讀:專業(yè)的移動(dòng)端耗電量測(cè)試設(shè)備價(jià)格是非常昂貴的旺嬉,有沒(méi)有性價(jià)比更高的移動(dòng)端耗電量測(cè)試解決方案呢,本期劉慧眾給大家?guī)?lái)一種性價(jià)比非常高且有效的耗電量測(cè)試解決方案葱淳。埋點(diǎn)測(cè)試大家都聽(tīng)說(shuō)過(guò),埋點(diǎn)測(cè)試具體怎么做咕晋,要達(dá)到什么樣的效果,譚莉給大家?guī)?lái)埋點(diǎn)測(cè)試的實(shí)例筝尾。
原創(chuàng)文章
窮團(tuán)隊(duì)測(cè)試耗電量出路@劉慧眾
目前輸出的 app 已經(jīng)出現(xiàn)多次因?yàn)橘Y源釋放不當(dāng)導(dǎo)致的異常耗電,嚴(yán)重的影響了用戶在F 產(chǎn)品使用中的體驗(yàn)捡需。性能測(cè)試雖然引入了耗電量測(cè)試,但是當(dāng)前的手段效率相對(duì)較低(通過(guò)長(zhǎng)時(shí)間使用來(lái)觀察耗電狀況)。
? 軟件監(jiān)控 app 解決思路,目前已經(jīng)有市面上的開(kāi)源項(xiàng)目供使用,F 技術(shù)組也有針對(duì)的做了引入和優(yōu)化,但是使用軟件做換算,存在測(cè)試誤差,且工具本身存在兼容性筹淫。
? 硬件耗電電量測(cè)量,更可靠的方案是購(gòu)買安捷倫,不過(guò)太貴了,以下使用一種相對(duì)便宜的解決方案來(lái)硬件測(cè)試耗電量站辉。
移動(dòng)端的埋點(diǎn)及測(cè)試@譚莉
對(duì)互聯(lián)網(wǎng)不陌生,做過(guò)移動(dòng)應(yīng)用的同學(xué)损姜,都會(huì)對(duì)埋點(diǎn)這個(gè)詞不陌生饰剥。埋點(diǎn)的目的很簡(jiǎn)單,就是實(shí)現(xiàn)app的數(shù)據(jù)收集和分析摧阅。埋點(diǎn)本身其實(shí)是對(duì)于自己所設(shè)計(jì)的產(chǎn)品的有一個(gè)可視化健康檢查汰蓉,通過(guò)邏輯和數(shù)據(jù),貫穿產(chǎn)品的整個(gè)生命周期棒卷,使產(chǎn)品逐步達(dá)到最佳狀態(tài)從而實(shí)現(xiàn)硅谷最近所謂的“Growth Hacker”的效果
移動(dòng)測(cè)試技術(shù)
利用瀏覽器window.performance 監(jiān)控頁(yè)面性能
當(dāng)考慮 Web 性能指標(biāo)時(shí)顾孽,需要關(guān)注的目標(biāo)數(shù)字應(yīng)該是從您自己的用戶那里獲得的實(shí)際用戶指標(biāo)祝钢。最常見(jiàn)的方法是利用 Splunk 之類的工具來(lái)分析您的機(jī)器數(shù)據(jù),該工具支持您分析和可視化您的訪問(wèn)權(quán)限和錯(cuò)誤日志若厚。利用這些工具拦英,您可以收集某些方面的性能數(shù)據(jù),比如讀取資產(chǎn)的文件 I/O 時(shí)間测秸,以及 API 請(qǐng)求的訪問(wèn)時(shí)間疤估。但是,您仍然需要推斷客戶端性能數(shù)據(jù)霎冯,將信號(hào)調(diào)用方在某些高級(jí)的檢查點(diǎn)上铃拇,或者只利用類似 WebPagetest 的工具運(yùn)行綜合測(cè)試。現(xiàn)在沈撞,W3C 已將 API 標(biāo)準(zhǔn)化慷荔,用戶可以通過(guò)使用 Performance 對(duì)象(該對(duì)象對(duì)于所有現(xiàn)代瀏覽器中的 Windows 對(duì)象而言是一個(gè)本機(jī)對(duì)象)捕獲并報(bào)告瀏覽器內(nèi)的性能數(shù)據(jù)。
深入理解Android消息處理系統(tǒng)——Looper关串、Handler拧廊、Thread
熟悉Windows編程的朋友可能知道Windows程序是消息驅(qū)動(dòng)的,并且有全局的消息循環(huán)系統(tǒng)晋修。而Android應(yīng)用程序也是消息驅(qū)動(dòng)的吧碾,按道理來(lái)說(shuō)也應(yīng)該提供消息循環(huán)機(jī)制。實(shí)際上谷歌參考了Windows的消息循環(huán)機(jī)制墓卦,也在Android系統(tǒng)中實(shí)現(xiàn)了消息循環(huán)機(jī)制倦春。Android通過(guò)Looper、Handler來(lái)實(shí)現(xiàn)消息循環(huán)機(jī)制落剪,Android消息循環(huán)是針對(duì)線程的(每個(gè)線程都可以有自己的消息隊(duì)列和消息循環(huán))睁本。本文深入介紹一下Android消息處理系統(tǒng)原理。
后端測(cè)試技術(shù)
http狀態(tài)碼詳解
這里有各種http狀態(tài)碼的詳細(xì)介紹
Java 內(nèi)存分配和回收機(jī)制
Java的GC機(jī)制是自動(dòng)進(jìn)行的忠怖,和C語(yǔ)言有些區(qū)別需要程序員自己保證內(nèi)存的使用和回收呢堰。
Java的內(nèi)存分配和回收也主要在Java的堆上進(jìn)行的,Java的堆中存儲(chǔ)了大量的對(duì)象實(shí)例凡泣,所以Java的堆也叫GC堆枉疼。
Java在垃圾收集的過(guò)程中,主要用到了分代收集算法鞋拟,我會(huì)先講一下常用垃圾收集算法骂维。
通用測(cè)試技術(shù)
軟件項(xiàng)目的用戶驗(yàn)收測(cè)試
隨著當(dāng)今技術(shù)和市場(chǎng)環(huán)境的變化,越來(lái)越多的企業(yè)選擇將軟件項(xiàng)目外包贺纲,同時(shí)也有更多成熟的大型軟件企業(yè)加入到軟件項(xiàng)目的承包隊(duì)伍中航闺。外包的軟件項(xiàng)目越來(lái)越多,如何對(duì)這些外包的項(xiàng)目進(jìn)行驗(yàn)收測(cè)試日益成為企業(yè)的一個(gè)關(guān)鍵問(wèn)題。
如何編寫優(yōu)質(zhì)的軟件測(cè)試需求文檔
編寫需求文檔潦刃,在嵌入式開(kāi)發(fā)領(lǐng)域是非常普遍的侮措。需求文檔被用來(lái)定義開(kāi)發(fā)任務(wù),協(xié)調(diào)大規(guī)模的研發(fā)計(jì)劃福铅。對(duì)于最終的產(chǎn)品萝毛,需求文檔扮演著開(kāi)發(fā)者行為和消費(fèi)者行為之間溝通紐帶的角色项阴。當(dāng)需求文檔書寫正確的時(shí)候滑黔,便可以發(fā)揮巨大的作用。然而环揽,如果你在嵌入式開(kāi)發(fā)領(lǐng)域工作的時(shí)間足夠長(zhǎng)略荡,你就會(huì)很快發(fā)現(xiàn),這個(gè)領(lǐng)域里不合格的需求文檔實(shí)在是太多了歉胶。當(dāng)你嘗試對(duì)這些不合格的文檔進(jìn)行修復(fù)時(shí)汛兜,你又會(huì)很快發(fā)現(xiàn),書寫正確的需求文檔絕非易事通今。在這里粥谬,我們提出一些建議,希望能將書寫正確需求文檔這件事情變得清晰一些辫塌。
新技術(shù)學(xué)習(xí)-QA也瘋狂
js立即執(zhí)行函數(shù)
經(jīng)常遇到自執(zhí)行匿名函數(shù)的代碼漏策,今天我們主要就來(lái)想想說(shuō)一下自執(zhí)行。
ios10亮點(diǎn)必看! iOS10新功能全解析
iOS10新功能盤點(diǎn)
測(cè)試雜談
由豐田代碼事件引發(fā)的軟件質(zhì)量思考
2013 年 10 月臼氨,豐田公司匆匆了結(jié)了“意外突然加速” 訴訟案掺喻。經(jīng)過(guò)數(shù)小時(shí)的討論,俄克拉荷馬法庭陪審團(tuán)得出結(jié)論:豐田汽車制造商貿(mào)然不顧用戶的安全储矩,裁定豐田公司賠償原告 300 萬(wàn)美元感耙。
而在審閱了 2005 版的豐田凱美瑞汽車的軟件開(kāi)發(fā)過(guò)程和源代碼之后,兩位軟件專家得出一致結(jié)論:豐田公司的系統(tǒng)不但有缺陷持隧,而且達(dá)到了危險(xiǎn)的程度即硼。因?yàn)楣收媳Wo(hù)機(jī)制里充斥著錯(cuò)誤和不一致,這是導(dǎo)致事故的根源屡拨。
如何做好回歸測(cè)試
在總結(jié)回歸測(cè)試的方法時(shí)發(fā)現(xiàn)只酥,不管國(guó)內(nèi)國(guó)外,這都是個(gè)頭疼的話題洁仗。做是要做层皱,也能做,但是從效率角度說(shuō)可是千差萬(wàn)別赠潦。給我足夠多的人或是時(shí)間叫胖,總是可以保證回歸測(cè)試進(jìn)行的徹底,可是那并不是做事情的方法和解決問(wèn)題的手段她奥。我覺(jué)得google的James Whittaker說(shuō)的好“事實(shí)上瓮增,有些測(cè)試組堅(jiān)持要保持一個(gè)規(guī)模相對(duì)比較大的團(tuán)隊(duì)主要是因?yàn)樗麄兊募僭O(shè)前提就是有些事情做錯(cuò)了怎棱。這也意味著編碼和測(cè)試之間的工作失衡。添加更多的測(cè)試人員并不能解決任何問(wèn)題绷跑∪担”“In fact, teams that insist on having a large testing presence are generally assumed to be doing something wrong. Having too large a test team is a very strong sign that the code/test mix is out of balance. Adding more testers is not going to solve anything.”當(dāng)然,google把quality交給developer去own才能將測(cè)試人員的工作真正做到是質(zhì)量環(huán)節(jié)的最后確保砸捏。而不是去檢查developer犯的錯(cuò)誤谬运。