本期導讀：本期原創專欄以測試工具開發經驗的介紹為主，慶豐和遠平分別介紹了前端Web表格和PyQT開發環境搭建的經驗；測試技巧專欄我們收錄了51Testing的沒有足夠時間測試怎么辦；自動化專欄我們收錄了兩篇RN測試文章，對RN感興趣的同學可以重點學習一下；測試雜談專欄推薦了一篇金融科技趨勢的文章和一篇Rosie Sherry的訪談，都非常值得一讀。
一、原創專欄
1）Bootstrap-Table的Web表格進階---實時編輯
- 作者：平安金融壹賬通高級測試工程師 王慶豐
- 摘要：Bootstrap-table是我目前使用過比好的Web前端表格框架，在實際工作也帶了很多的實現便利，關于Bootstap-table基本的介紹可參考我之前的文章《基于Bootstrap-Table的Web表格教程》，本文將介紹Bootstrap-Table擴展功能---實時編輯。
- 作者：平安金融壹賬通高級測試工程師 張遠平
- 摘要：在PC時代，主流的操作系統有windows、mac、linux，有些產品為了能節約開發時間以及保證產品在這三個平臺的一致性，會選取一些跨平臺的技術進行桌面應用的開發，也就是"Write Once Run Anyway"。常用的的跨平臺GUI有Qt、 Java Swing等，其中Qt還有python的版本PyQt，開發者可通過python來調用Qt強大的圖形庫，腳本語言相對C++、Java等編譯型語言來說，難度會小很多，因此我們決定采用PyQt來進行Mac應用的開發。作者對整個環境的搭建做了一個簡單的記錄。
二、測試方法與技巧
- 作者：softwaretesting @ 51Testing軟件測試網
- 摘要：在進行軟件測試的過程中你有沒有經常感覺到你的時間很緊張，不夠用？你覺得你已經掌握了測試過程的每個步驟，但是很快你會意識到你又處在計劃中"時間不夠"的死循環中。我也是這樣，而且這種感覺并不是很美妙。關于這件事我苦苦思考，想要有所突破。要怎樣才能在測試中有個完美的開始，不太糟的過程，讓人滿意的結果。本文是作者對該問題的思考和分析。
- 作者：魏增藝 @ 簡書
- 摘要：啟發式測試策略模型（Heuristic Test Strategy Model，簡稱HTSM，以下使用HTSM），是JamesBach提出的（JamesBach曾經做過開發，后來轉測試，是探索式測試、語境驅動測試學派的主要提出者、支持者，是測試領域的思想先驅），而HTSM自然也帶有這位前輩的思想印記。本文分別翻譯了JamesBach的啟發式測試策略模型各模塊的內容。
3）推送怎么玩
- 作者：網易杭州QA
- 摘要：推送和移動互聯的關系，已經密不可分。每天你收到的推送是各大app的強有力的吸引用戶黏住用戶的工具。那我們來具體了解下推送吧。目前的兩大平臺ios和安卓的推送的實現是有很大差異的。本文分別介紹了兩大平臺的推送機制。
- 作者：孫遠 @ infoQ
- 摘要：隨著容器時代的到來，開源社區中誕生了以Docker、Rocket為代表的優秀的容器引擎方案。本文旨在介紹通過容器技術對不同測試類型（應用層測試、中間層測試、內核測試、硬件驅動測試、編譯測試）進行容器化改造的方案和收益，并通過具體實例的方式來展示容器化時代為軟件測試帶來的機遇。
三、自動化與專項實施
- 作者：fenfenzhong @ TesterHome
- 摘要：相信經常看文檔（尤其是官方文檔）的同學一定會有一個體會，文檔總是由某一個topic出發，然后在介紹這個topic的時候包含了各種各樣的引用、鏈接，如果有某一個工具可以一次性打開所有這些深層嵌套的鏈接，那它們的樣子一定會像是一個圖（因為還有循環的嵌套），每個節點都有多條有向邊。那如果想要搞清楚這個主題說的是什么，我們是要對這個圖進行怎樣的遍歷呢？深度優先還是廣度優先？我建議先廣度，再深度。
- 作者：裴興蕊 @ ThoughtWorks
- 摘要：在組件化出現之前，我們不談UI的單元測試，哪怕是對于UI頁面進行測試都是一件非常困難的事情。其實組件化并不完全是為了復用，很多情況下也恰恰是為了分治，使得我們可以分組件對UI頁面進行開發，然后分別對其進行單元測試。
- 作者：劉先寧 @ ThoughtWorks
- 摘要：在PhoneGap、RubyMotion、Xamarin、Ionic一眾跨平臺開發工具中，React Native能夠殺出一條血路，獲得目前這么大的影響力，除了React社區生態圈的加持和Facebook的大力推廣以外，另外一個最主要的原因就是其在開發效率和應用性能方面取得了一個比較好的平衡。不過，雖說框架提供了這個平衡能力，平衡點的選擇卻掌握在開發者手中，本文將從React Native的性能角度來看看應該如何掌握這個平衡點。
- 作者：appetizerio @ 泡在網上的日子
- 摘要：測試人員在找到一個問題之后從上報到修復通常是一個比較漫長而且需要大量交流的過程。很多時候開發人員常常會有以下抱怨： “你怎么弄崩潰的？”，“我這里好好的啊”，“你從什么狀態開始操作的？”，諸如此類。 大量的問來問去的語言交流使得修復的時間變長，影響進度（測試是個漂亮妹妹除外）。 雖然不同公司可能存在不同的上報流程（github上的開源項目有些不厭其擾也搞了模板），但歸根結底修復的人只希望得到一個測試人員提供的可以重現的測試流程，跑一遍，重現問題。這里我們向大家分享一下如何結合多設備控制以及屏幕操作的錄制重放，在多設備上實現可重現的測試流程。鑒于公司的制度和流程不同，并不一定完全適用，大家挑有用的用就是了。
四、平臺與工具建設
- 作者：robbenli @ 騰訊WeTest
- 摘要：互聯網產品中的檢索功能隨處可見。當你的項目規模是百度大搜|商搜或者微信公眾號搜索這種體量的時候，自己開發一個搜索引擎，加入各種定制的需求和優化，是非常自然的事情。但如果只是普通的中小型項目甚至創業團隊|創業項目，直接拿輪子則是更合理的選擇。 ElasticSearch就是這樣一個搜索引擎的輪子。更重要的是，除去常規的全文檢索功能之外，它還具有基礎的統計分析功能（最常見的就是聚合），這也讓他變得更加強大和實用。 還在用數據庫的like來實現產品的全文檢索嗎？拋棄她，用ElasticSearch吧~
2）走向持續交付
- 作者：mike knepper @ 8thlight
- 摘要：持續交付是當今軟件行業的一個熱門概念，但它往往似乎是一個不可能的目標。 “我們的系統怎么能做到這一點”。在克服幾個常見的技術障礙的同時，實踐持續交付可能也需要重大的文化變革。在這篇文章中，我將介紹一些我們一個客戶使用的關鍵經歷和過程來展現持續交付文化。
- 作者：Nemocdz @ 簡書
- 摘要：上周接到了個需求，老大要我們把項目代碼里某個庫覆蓋上單元測試。而那個庫沒有Demo，平時都是集成在工程里開發的。為啥沒有Demo，因為那個庫依賴很重，說是個庫，實際只是把代碼用cocoapods拆分罷了……平時開發的時候，大家都是把庫集成在主工程里運行。我想，單測寫在主工程的target里，這樣會顯得很雜，給人感覺是給整個工程做單元測試。本文作者探索通過Pod來管理單測代碼的過程，以及踩坑填坑的過程。
- 作者：軍慧 @ 美團點評技術團隊
- 摘要：在Android（Java）開發中，基本都會遇到java.lang.OutOfMemoryError（本文簡稱OOM），這種錯誤解決起來相對于一般的Exception或者Error都要難一些，主要是由于錯誤產生的root cause不是很顯而易見。由于沒有辦法能夠直接拿到用戶的內存dump文件，如果錯誤發生在線上的版本，分析起來就會更加困難。本文從一個具體的案例切入，介紹OOM分析的思路及相關工具的使用。
五、測試雜談
1）ThoughtWorks金融科技雷達——金融科技趨勢前瞻
- 作者：裴興蕊 @ ThoughtWorks
- 摘要：2015年是互聯網金融監管元年，自此政策猛然收緊，風口關閉。正當互聯網金融這股洪荒之力無處宣泄之時，FinTech這個泊來的詞匯，似乎來的恰逢其時，給互聯網金融一個繼續發展的新契機。然而，FinTech是什么？它真的是互聯網金融升級版嗎？本文將分享ThoughtWorks對FinTech的理解、定義和趨勢前瞻。
- 作者：Ben Linders @ infoQ
- 摘要：測試人員應該分享故事，談論他們所關心的內容，讓人們對他們所做的事情產生興趣。Rosie Sherry主張“未來的測試需要測試人員像營銷人員一樣思考”。他們可以從制作和分享一些東西開始，譬如博客、文章、報告或視頻。人們認為測試已死，或者已經變得不重要了，為此我們有很多話要說。但是作為測試人員我們又做了些什么呢？測試人員應該找到精力和時間走出去，向別人談論他們所關心的東西。
