@author: penghaibo204
本期導讀：本期原創(chuàng)文章為大家推薦一篇安全掃描相關(guān)的文章滔韵，移動端測試技術(shù)也重點關(guān)注了安全測試的方法蒿柳。后端測試技術(shù)還是圍繞接口測試和壓力測試來討論舰蟆。本期要重點推薦通用測試技術(shù)專欄的精準測試相關(guān)的兩篇文章讶凉，為我們提供了很好的思路辙谜。測試雜談專欄问欠，我們帶來兩篇測試雞湯肝匆，提醒我們在埋頭測試的同時，也要多思考顺献。
原創(chuàng)文章
隨著移動互聯(lián)網(wǎng)的飛速發(fā)展术唬，移動端產(chǎn)品滿天飛，深入各行各業(yè)滚澜，移動端安全已經(jīng)變得跟PC端安全同等重要地位粗仓。但由于移動端自身特性，移動端操作系統(tǒng)以及應用程序的安全性做的還不是很成熟设捐。因此借浊，我們在開發(fā)移動端App的時候，要盡量多地避免安全漏洞問題萝招。本文主要是從預防的角度出發(fā)蚂斤，介紹一個靜態(tài)代碼掃描工具，在編譯階段來提前發(fā)現(xiàn)代碼的安全漏洞槐沼。
移動端測試技術(shù)
自動化測試曙蒸，從廣義上來說，一切通過工具(程序)的方式來代替或者輔助手工測試的行為都可以成為自動化岗钩。從狹義上來說纽窟，通過編寫腳本的方式，模擬手工測試的過程兼吓，從而替代人工對系統(tǒng)的功能進行驗證臂港。但是隨著腳本數(shù)量的增加势腮，這種自動化覆蓋的方式的弊端也逐漸暴露：執(zhí)行效率低下垂蜗，構(gòu)建成功率低(誤報率高)，受前端樣式變更影響大躺孝，外部依賴較多浑娜，覆蓋能力有限佑力。本文主要介紹了有贊測試團隊由原來的黑盒系統(tǒng)級自動化測試向分層自動化測試轉(zhuǎn)變的解決方案。
2）Android APK瘦身之Android Studio Lint (代碼審查)
隨著項目版本的不斷迭代筋遭，功能越來越多打颤，很多無效的資源將導致APK變得越來越臃腫杂数。臃腫的APK不僅影響使用，導致下載時間太長瘸洛，浪費用戶的時間揍移，也浪費用戶的流量。因此反肋，我們需要對Android APK進行資源瘦身那伐。本文介紹了如何使用Android Lint工具來排查無效的資源，并進行瘦身的思路石蔗。
相對其他 Android 性能指標（如內(nèi)存肾胯、CPU、功耗等）而言耘纱，顯示性能（包括但不僅限于我們常說的“流暢度”）的概念本來就相對復雜敬肚。讓我們更蛋疼的是，業(yè)界對顯示測試評估方式也是豐富多樣束析，這無疑更加重了我們對其理解的復雜程度艳馒。本文提及四個顯示性能指標：FPS，Aggregate frame stats员寇，Jankiness count弄慰，SM。然后從三個方面對這幾個指標進行了探討：你是誰——這些指標具體反映了什么問題蝶锋；你從哪兒來——這些指標數(shù)值是怎么得到的陆爽；你要到哪兒去——這些指標如何落地來指導優(yōu)化。
安全測試在移動App的測試過程已經(jīng)成為必不可少的一個環(huán)節(jié)牲览。測試人員了解一些安全測試的知識也是必不可少的技能墓陈。本文是安卓安全中文站總結(jié)的系列安全文章恶守，主要對常見安卓APP客戶端漏洞原理進行分析第献，并給出詳細的測試方法。對于安全測試的入門非常有幫助兔港。
雖然iOS系統(tǒng)相比于其他手機操作系統(tǒng)相對安全庸毫，但是這個安全并不是絕對的，我一直相信衫樊，道高一尺魔高一丈飒赃。此文想以實際例子出發(fā)利花，告訴大家，如何去反編譯一個app载佳，并且從某個角度來說炒事，iOS沒有傳說中的“安全”。本文簡單的介紹了iOS反編譯的方法及展現(xiàn)結(jié)果蔫慧。通過本文挠乳，也可以引起我們對iOS app安全的重視。
后端測試技術(shù)
1）接口測試理論與實踐——PiTest + GT雙管齊下姑躲，專治各種接口測試
接口測試是測試系統(tǒng)組件間接口的一種測試睡扬。接口測試主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點。測試的重點是要檢查數(shù)據(jù)的交換黍析，傳遞和控制管理過程卖怜，以及系統(tǒng)間的相互邏輯依賴關(guān)系等。因此阐枣，在接口測試中我們需要重點關(guān)注的是：數(shù)據(jù)+邏輯马靠。本文結(jié)合常用的工具，從理論和實踐相結(jié)合的方式為我們介紹了接口測試的方法蔼两。
Jmeter由于自身框架的局限性虑粥，一直被認為不適合用來做大規(guī)模并發(fā)。但大神們總能利用普通人不了解的特性做出牛逼的事情宪哩。本文將從負載測試的角度娩贷，描述了做一次流暢的5萬用戶并發(fā)測試需要做的事情。
通用測試技術(shù)
在目前的快速迭代開發(fā)模式下锁孟，測試人員需要不停覆蓋不斷調(diào)整的產(chǎn)品邏輯需求彬祖，因此測試用例也越來越龐大了，導致全量測試時間很長品抽，同時發(fā)現(xiàn)的問題并不和用例數(shù)成正比储笑。以往迭代測試用例更多是功能“點”的覆蓋，而不是用戶場景“線”圆恤、“面”的覆蓋突倍。而目前產(chǎn)品經(jīng)理給出的需求都是增量文檔，也就是很難有某個產(chǎn)品的完整需求文檔盆昙，因此羽历，每次用例更多是功能點的覆蓋，比如需求文檔里面提到點擊某個按鈕會有什么變化淡喜，那某次用例編寫時可能只是簡單的覆蓋秕磷，但這種用例并不完全符合用戶實際場景，因此還是可能出現(xiàn)覆蓋不完全問題炼团。在這樣的問題驅(qū)動下澎嚣，我們必須去思考用例精簡和精準測試了疏尿。
目前互聯(lián)網(wǎng)行業(yè)基本的開發(fā)模型采用的是敏捷開發(fā)，其顯著特點就是：1.迭代周期短易桃，2.需求經(jīng)常變更褥琐。但是傳統(tǒng)的測試模型已經(jīng)不能滿足敏捷的要求了。所以我們必須尋求其他測試方案晤郑，使得我們測試工作更加高效踩衩，更加便捷，要體現(xiàn)快贩汉。本文提出從代碼層入手驱富，分析不同版本之間的代碼差異，分析出函數(shù)的具體功能匹舞，記錄函數(shù)的變更生命周期褐鸥，建立一套分析函數(shù)模型，從而從架構(gòu)邏輯層了解測試點赐稽。
探索式測試探索式測試（Exploratory Testing）是一種自由的軟件測試風格叫榕，強調(diào)測試人員同時展開測試學習、測試設計姊舵、測試執(zhí)行和測試結(jié)果評估等活動晰绎，以持續(xù)優(yōu)化測試工作。它強調(diào)獨立測試人員的個人自由和職責括丁，為了持續(xù)優(yōu)化其工作的價值荞下，將測試相關(guān)學習、測試設計史飞、測試執(zhí)行和測試結(jié)果分析作為相互支持的活動尖昏，在整個項目過程中并行的執(zhí)行。本文首先介紹了整個探索式測試的體系构资，然后指導讀者如何去具體結(jié)合項目進行實踐抽诉。
4）創(chuàng)業(yè)公司如何成功實施持續(xù)交付？一個10年測試老兵的經(jīng)驗談
正如Kurt Bittner說的那樣吐绵，如果敏捷僅僅是個開始的話迹淌，那持續(xù)交付則是高潮！現(xiàn)代企業(yè)要求軟件開發(fā)過程保持最大的工作效率己单，傳統(tǒng)的瀑布式開發(fā)早已跌入歷史洪流唉窃，甚至敏捷宣言也已超過10年的歷史，軟件開發(fā)在經(jīng)歷了敏捷開發(fā)荷鼠、持續(xù)集成后句携，正逐步邁入到持續(xù)交付的時代。持續(xù)交付是持續(xù)集成的延伸允乐，強調(diào)以自動化矮嫉、可視化的手段更快的將產(chǎn)品交付到客戶手中。持續(xù)交付的一個重要衡量指標就是從代碼提交直到客戶能使用這個功能所花費的時間牍疏，通過實行持續(xù)交付蠢笋，這個時間往往可以從原先的幾天、幾周縮短到幾分鐘鳞陨。本文以實際項目為例昨寞，與大家一起探討了實施持續(xù)交付的解決方案。
測試雜談
經(jīng)常有人在測試論壇上會問這種問題：測試到底要會點什么援岩？每每聽到這樣的問題，總有一種莫名的感覺涌上心頭掏导。如果你真的不知道學啥享怀，請嘗試著去解決公司中存在的各種問題，各種痛點趟咆。當你用你現(xiàn)有的能力解決不了的時候添瓷，你就知道你要學點啥了。當然值纱，如果你連公司存在的問題都發(fā)現(xiàn)不了鳞贷，那你學啥也都沒意義了。
測試的核心能力有兩個：對需求的理解和把握和對產(chǎn)品失效規(guī)律的把握搀愧。--我們對需求進行分析，得到產(chǎn)品的測試范圍疆偿，并確定我們的測試目標（驗收標準）妈橄；結(jié)合設計，得到產(chǎn)品的測試重點翁脆、測試難點眷蚓，測試深度和廣度。同時我們還需要結(jié)合我們對產(chǎn)品失效規(guī)律的把握反番，基于風險來進行測試沙热。我們所有的測試，要"測什么"罢缸，"怎么測"篙贸，都是圍繞上面來進行的，作者認為這才是最核心的測試技術(shù)--定好測試策略枫疆【舸ǎ總結(jié)的非常好，給作者點贊息楔！
