為什麼放棄精準測試平臺？

看了不少精準測試的文章,我收集如下，這些主要是大廠出品，內容也比較精彩和全面,是瞭解精準測試比較全面的文章.

• 網易嚴選的精準測試實踐
• 位元組跳動精準測試實踐，SmartEye 背後的設計邏輯
• 精準測試之過程與實踐 | 京東雲技術團隊
• 走出迴歸測試困境，愛奇藝精準測試體系建設
• 關於智慧化、精準化測試的一切，這 50 個問題我們幫你整理好了！

我摘錄一些這些文章中關於精準測試的概念目標的說明：

網易文章的說明:

• 精準測試的概念: 藉助一定的技術手段、透過輔助演算法對傳統軟體測試過程進行視覺化、 分析及最佳化的過程，使得測試過程更加視覺化、智慧、可信和精準
• 精準測試的目標: 非常精確和智慧的軟體來解決傳統軟體測試過程中存在的問題,在測試資源有限的前提下，將用例精簡到更加有針對性，提高測試效率，有效的減少漏測風險
• 精準測試的核心：雙向追溯,程式碼和用例可以做到匹配和關聯，從而實現測試用例的精準覆蓋

或者用位元組文章中的說明:

在日常的研發活動中，我們經常會遇到下列場景：

• 這次需要研發自測保障了， 我的用例集是不是全都有效覆蓋了？
• 這次技術重構改動挺大的，會影響哪些已有功能？
• 基礎工具 SDK 有重大升級，我是涉及到的業務方，哪些功能需要測試驗證？
• 版本要上線了，大家都走一下全量回歸 Case，測試重點在哪裡？迴歸測試用例集全量執行是不是必要的？
• 在專案研發團隊中的每個同學質量標準是不是都統一了？

京東雲：

精準測試是中國自己有智慧財產權的完全的理論體系，它同時關注功能點和程式碼相關邏輯這樣一個方法論，是一種灰盒的測試模式。
最開始在 2014 年的國際軟體測試大會上釋出精準測試的時候，它叫穿線測試，英文名字叫 Threading Test，
表達了精準測試的本質，Threading 這個英文單詞本身有兩個含義，一個是穿線一個是執行緒，
建立用例和程式碼的關係，相當於把黑盒和白盒關聯起來，做黑盒測試也能看到白盒資料，同時把開發和測試能夠關聯起來，測試一做完，
開發的邏輯馬上就能自動生成。另一個層面，精準測試最本質就是執行緒測試，因為精準測試基於覆蓋率白盒理論產生，
它跟白盒最大的區別是它的覆蓋率是執行緒級的，也就是說要追溯到用例這個級別。

京東雲文章中 Thread testing 的疑問

對於京東雲文章中說到精準測試一開始是 threading testing,由於提到是精準測試的起源，想來一開始的目的是比較有意義的，
所以特意查了一下：

1. thread testing 這個術語 (terminology/glossary) 令人驚訝的在istqb-Standard Glossary of Terms Used in Software Testing
   這個網站上查不到,那這個從哪裡來？哪個 2014 年的國際軟體測試大會上釋出？再一查，還是沒有查到，可能是我的搜尋能力有限

2. 再查了一些外閘道器於這個 thread testing:

Thread Testing is one such type of software testing that is usually 
conducted during the early stages of System Integration Testing. 
A thread is the smallest unit of work that can be carried out by the system and 
it is mainly used to verify the functional capabilities of a specific task or thread. 
In thread testing, testers focus on testing individual logical execution paths 
in context of the entire system.

幾個搜尋出處:

• professionalqa-thread-testing
• geeksforgeeks-thread-testing

綜合以上，個人認為 thread testing 不是精準測試的起源，而是如何儘可能儘早的進行主要功能的整合測試，用一個測試 (thread test) 儘可能
覆蓋足夠好獨立的功能. 你說他精準吧，可能也說的通，但是他的定義是整合測試的一種，所以還是整合測試.

關於精準測試解決的問題的疑問

總結以上幾個文章我總結的一些我自己認為精準測試要解決的問題:

1. 沒有辦法精確定義改動需要跑哪些 Case，如果每次都全跑太浪費時間成本高
2. 對改動進行測試之後，沒有辦法進行評估，評估所做的測試是否已經全部覆蓋了變化

看了這些文章之後，這些精準測試系統主要實現的思路都是:

1. 收集程式碼變化，確定程式碼對哪些介面有影響
2. 收集執行測試用例之後的程式碼覆蓋率資料，確定哪些程式碼覆蓋沒有做到
3. 使用視覺化的方式展示哪些程式碼變化，哪些介面可能有影響，推薦哪些用例

以上我覺得都很好，但是在小公司，自己的疑問就是:

1. 做一個這個精準測試的平臺成本是多少，收益是什麼？
2. 關於程式碼變化，有哪些影響，人工溝通和檢查是否可以確認？
3. 如果都是透過系統推送出來，然後人工確認，那麼和直接人工對著程式碼確認相差的成本和收益是什麼？
4. 如果單獨到一個介面的變化，如果有全量的介面自動化，那麼這個介面變化，是否可以自動觸發全量介面的迴歸測試？成本在哪裡？ 為什麼還需要額外進行精準測試？
5. 精準測試平臺對於有漏側可以承擔責任嗎？如果每一個測試只是負責自己熟悉的一小塊，程式碼 review 可以替代這些精準測試嗎？
6. 還有透過程式碼分析的方式去了解呼叫鏈路可以現在已經有日誌追蹤系統了或者類似的 skywallking 這種可以追蹤呼叫鏈的工具， 為什麼還要自己寫一套從程式碼開始的實現？不應該生產的呼叫鏈路更能表示實際使用情況，從而從實用和準確

考慮以上的一些問題不能得到回答，還是覺得放棄精準測試平臺這個路，可能做好一下幾點就足夠了:

1. 介面變化： 透過追蹤介面定義檔案就可以瞭解，無論是 swagger 還是 openapi 格式，這個追蹤變化的實現要比程式碼層的實現成本低很多
2. 介面有變化，全量介面迴歸測試，這個是無腦操作，沒有成本
3. 新的測試用例的新加和影響範圍的評估，透過和開發溝通，檢視程式碼也可以達到，畢竟自己負責系統，也挺熟悉的，分析出來的結果可能也會進行再加工和討論 並不能減少多少成本
4. 用例管理起來，可以知道哪些是高優先順序用例，如果需要全面重構，精準測試和全量回歸工作量預計相差不會太大，而如果只是 1，2 個介面的改動， 選擇高優先順序用例和 review 之後的結果需要的用例也能滿足，或許精準測試會再提供一些提示，但是這些提示從文章中我沒有看到哪些特殊情況特殊的點容易 遺忘的，所以我判斷其實可能也不會太多這樣的 Case，因為可能特殊點再測試用例庫裡面就沒有，如果測試用例庫裡面有，那麼在選高優先順序用例的時候也能包含
5. 針對迴歸測試的程式碼覆蓋率或許有用，但是文章中還是沒有實際的例子來說服我程式碼覆蓋率可以發現的 Case 不在高優先順序用例場景覆蓋中的

所以最後還是放棄精準測試平臺這個路，管好測試用例，做好介面自動化，做好程式碼 review 和開發溝通或許是目前最合適的方法。

題外話

既然查了一下相關內容，然後一時對於程式碼插樁這個描述，是在不知道是個什麼東西，最後查了一下，英文是: code instrumentation 這個
不確定為什麼要翻譯成程式碼插樁，但是我也不知道翻譯成什麼好， 就是叫成程式碼插樁感覺哪裡不對,不能叫程式碼測量嗎？

In software engineering the need for secure and high quality software has spurred intense 
research activity in the areas on software debugging, testing and constraint analysis. 
Code instrumentation is a common technique used to track application behaviour. 
The most popular usages for code instrumentation are software debugging, 
performance analysis, monitoring, distributed computing and aspect oriented programming. 
Typical instrumentation techniques provide information about code coverage during software testing activities. 
Current approaches make use of instrumentation by inserting additional code that monitors the behavior of a specific component. 
This thesis presents and applies two novel approaches that use an instrumentation technique: 
(1) A Runtime Debugging approach is aimed at detecting and resolving runtime faults in object-oriented code. 
The approach relies on bytecode instrumentation in order to provide code coverage for predefined unit tests. 
The results are analysed using Reverse Engineered techniques. The approach consists in merging both succesfull and
 faulty code execution traces and detecting the faults by analysing the differences in the output traces. 

(2) A Security Constraint Checking approach uses the notion of security consistency in designs. Byte code instrumentation techniques are used to provide code coverage for selected unit tests. Direct acyclic graphs are constructed from the output traces using reverse engineered techniques. The graphs contain object method calls in a similar manner to UML Sequence Diagrams. This approach uses the results of the instrumentation to check for consistency with design generated security constraints. Furthermore this approach analyzes these views for
security inconsistencies, and generates a set of recommendations.