不測的祕密：精準測試之路

精準測試 要義整理： 第一式：差異化。 目的：破全面迴歸。在保證質量的前提下，少測試一些內容，從而提升效率。 要旨：需求差異要明瞭，技術實現差異更要明瞭。 第二式：技術治理 目的：破耦合。耦合影響內容不能漏測，也不能多測。能夠快速準確的分析出耦合影響，人工精準就基本達成了。 要旨：快速準確的分析耦合影響。 第三式：度量及分析閉環 目的：破差異化後的度量。代碼覆蓋率不僅僅可作爲質量的一個度量緯度，更可以作爲測試分析精準與否的一個度量手段。 要旨：代碼覆蓋率分析結果，是精準測試質量的重要依據。 第四式：知識庫 目的：破函數和用例映射。精準測分核心是分析變更函數及影響到的用例（含新增），如有一庫在手，任何變更來了，都可以分析的又快又準。 要旨：函數和用例關係庫建設。 第五式：用例預分析 目的：破人工分析變更影響用例。變更函數有了，知識庫也有了，自動分析影響用例還遠嗎？ 要旨：函數變更自動分析出影響用例。 第六式：知識庫優化 目的：破函數用例關聯冗餘。同一個函數內覆蓋相同分支路徑的用例去重。 要旨：函數和用例關聯，細化到函數內分支級別。 第七式：用例預分析消振 目的：破推薦影響用例冗餘。變更分析也細化到分支級別。 要旨：差異化分析細化到函數分支級別。 第八式：精準測試執行手段 目的：破系統應用。精準測分系統完成之後，人工和自動化的配合。 要旨：人工和自動的取捨。 第九式：質量評估 目的：破精準之後的質量評估。從“你來決策發不發”角度，來全面闡述質量評估緯度。 要旨：決策側重。

看這本書我的最深的感受是我自身的專業基礎太差，代碼能力太弱，獨孤九劍確實很有難度，但並不是作者的問題，而是讀者自身基礎太弱的問題，比如我🌝作者的精準測試的思路很棒，文字的風格也很特別，對精準測試的整體思路做了較詳細的介紹，差異化，技術治理，度量及分析閉環，知識庫，用例預分析，知識庫優化，用例預分析消振，精準測試執行手段，質量評估，很棒呀~待我提高專業基礎知識和代碼能力後，再來拜讀一遍💫

從畢業開始就知道TDD，而讀到的所有牛人的書裏都說測試驅動開發，但一直持懷疑態度，也總實踐不起來，但後補的單體測試的重要性倒越來越能感覺。感覺書中的精準測試對開發而言就是代碼review加單體測試。書中講的根據代碼提交記錄自動關聯受影響的測試用例，來減少迴歸測試用例數，感覺很有意思

乾貨不多，幾篇文章的量擴寫成了一本書。不過還是有收穫，感謝作者團隊把經驗分享出來。

只看完還不行，得配合大量的實踐，才能體會到作者的獨孤九劍

從TMQ公衆號收到推薦的消息，迅速入手該書，主要想了解騰訊的同行們在怎麼做事。 1、該書以將故事的形式介紹騰小宇的成長過程，對於技術類書籍，以這樣文風行文實屬少見； 2、根據故事介紹，主人公工作過程中項目開發語言主要是C/C++，過去接觸的項目開發過程中主要使用Java、PHP，不同語言使用不同的工具去做相似的事情，如果書中主要介紹Java相關項目的實踐，受益的同行應該更多。 3、用例預分析、知識庫在現在的工作過程中還沒有很好的實踐，根據過去項目經驗，知識庫的建設可以在後續工作過程推動團隊技術成長髮揮巨大作用。

這本書和我預想的不一樣，有很多幹貨，讀到獨孤九劍還是很艱澀，但是整體思路是理解了。其實在閱讀此書之前，我對於測試就一直有疑問，現在都講究敏捷開發快速迭代，還不時有緊急需求，其實從市場推廣從產品角度來說，這是對的這應該是個趨勢，但是對於測試來說該怎麼做，還有沒有必要每次都要進行全量回歸，或者要怎麼做減少迴歸工作量。以前老是說做自動化，後來發現需求增加太快，自動化遠遠跟不上，我在以前公司時候，每次發緊急版本，就跑去看看代碼diff，研究改動多不多該回歸多少。其實也是這本書的思想，通過代碼變更分析到其所涉及的模塊，進行精準測試，我以前做的還是比較淺的層面，這本書算是將其系統規範化，於我而言，開拓了思路，也知道還需要努力

一羣人拼湊成的一本書，這水平是我們10年前的水平（雖然搞了點知識庫）。 書裏的方案都是基於假設測試人員都是編碼高手，無推廣性可言。

走讀代碼，分析差異，給出結論。 丟給機器，機器學習，機器出結論，機器迴歸。 ​人爲最後看覆蓋率結果可能就能很大程度有說服力，前提是知識庫足夠充分，機器學習的範圍足夠多，這樣誤差也會越小，那麼迴歸的也會更精確。

本文構思較巧妙，擺脫了技術書籍的枯燥乏味。對於精準測試的介紹，給我們測試創新提供了思路，但是對於個人來講指導性不是很強，需要向開發借力協作完成。產品研發質量優先，要麼保證質量提高效率，要麼雙管齊下，故步自封就是等死。