在軟件開發的生命周期中，自動生成單元測試成為提高代碼質量和開發效率的關鍵技術。在不久前舉辦的 QCon 全球軟件開發大會（上海站）上，字節跳動質量效能專家趙亮作了《基于 LLM 的單元測試用例自動生成》的精彩演講。針對字節研發內部需求，基于大模型技術結合深度程序分析，實現存量及增量單元測試的自動生成。本文為 InfoQ 整理的演講實錄。

我將與大家分享我們團隊在大模型自動生成單元測試方面的研發經歷，這個議題涵蓋了我們從問題識別到解決方案的全過程。我將這個議題分為六個部分。

1. 痛點與現狀。這部分涉及到我們為何要著手解決這個問題，以及我們與業務團隊合作時收集到的問題和痛點。這些痛點和現狀是我們行動的出發點。

2. 目標與挑戰?；谇捌谑占膯栴}，我們設定了一系列目標，并在實現這些目標的過程中遇到了一系列的挑戰。

3. 數據質量提升。分享我們為了提升單測生成效果所做的工作，以及我們如何通過這些措施來提高整體效果。

4. 代碼生成效果提升。介紹我們采用的一些方法，以提升模型在生成單元測試方面的性能。

5. 效果演示。展示我們所取得的一些成果，讓大家更直觀地了解我們的工作效果。

6. 總結與規劃。總結我們在整個過程中的不足之處，并分享我們的一些思考和未來的規劃。

現狀痛點

許多有編寫單元測試經驗的人普遍面臨一個問題： 業務代碼的單元測試覆蓋率普遍不高。 這并非因為開發人員不愿意編寫測試，而是因為他們沒有足夠的時間。 許多業務的上線時間緊迫，留給開發代碼的時間本就不多，更不用說編寫單元測試了。 在這種情況下，開發人員往往將質量保障工作交給測試團隊，但測試團隊的主要精力在于驗證需求和功能的正確性，而不是逐行審查代碼。

我將這些問題歸納為三個主要部分：

首先，編寫單元測試耗時較長。 在與業務團隊的研發人員溝通時，我們發現編寫單元測試的時間可能比編寫業務代碼還要長，這取決于被測方法的數據復雜度和代碼復雜度。平均而言，編寫單元測試的時間大約需要 5 到 15 分鐘，取決于目標被測函數的邏輯復雜度和數據構造的困難程度。

其次，由于業務上線時間緊迫，研發人員可能同時處理多個需求，導致他們沒有精力保證單元測試的編寫，這使得存量問題愈發嚴重。 例如，我們內部許多業務團隊由于快速迭代導致大量未編寫單元測試的代碼，許多倉庫的代碼行覆蓋率小于 10%，這使得暴露給線上的風險非常大。

最后，現有工具的效果不足。 盡管許多公司和團隊嘗試通過工程化方法或基于搜索、遺傳算法的單元測試生成方式，以及近年來隨著大模型的興起，嘗試使用模型生成單元測試，但普遍存在幾個問題：生成數據的可讀性低，用例多樣性不穩定，以及編譯通過率低。這些問題導致生成的單元測試存在許多編譯或運行問題，增加了研發人員修正的成本。

目標及挑戰

目標

對單元測試的現狀和痛點，我們設定了明確的目標，并將其拆解為幾個關鍵部分，以期通過這些目標來解決我們面臨的問題。

首先，盡管模型和插件如 Copilot 在代碼生成方面取得了一定的進展，但它們還不能完全理解業務需求，也不能保證 100% 的編譯通過率。因此，我們基于工程分析建立了精準的數據分析基礎，以此為我們的單元測試生成產品提供支撐。我們的目標是提高工程化分析的準確性，通過將控制分析、數據分析和約束求解的方案相結合提升前期單測數據語料分析的精確性。

其次，我們對模型本身也設定了目標。我們正在嘗試并將持續引入偏好對齊和強化學習算法，以及已經在使用的思維鏈方式和微調技術，以持續提高模型在生成單元測試方面的效果。

最后，我們希望提升單元測試生成產品的用戶體驗。我們的目標是打造一個開箱即用、快速且輕量化的單元測試工具，以降低業務研發人員的使用成本。

在目標設定上明確了四個具體的目標： 覆蓋率目標、有效性目標（包括斷言、mock 和流量）、目標倉庫覆蓋目標，以及研發投入產出比目標。

在代碼質量與研發效能之間，我們面臨著一個場景權衡。我們希望在保證代碼質量的同時，又不會犧牲較多的需求迭代時長。業務的快速上線對于市場份額的占領至關重要，因此我們希望通過這套工具打破原有的平衡，既保障代碼質量，又提升業務研發的效率。

挑戰

在研發過程中，我們遇到了不少挑戰，其中兩個尤為關鍵： 數據質量和代碼生成效果。

首先，數據質量是我們面臨的一個重大挑戰，它可以分為三個部分。第一部分是模型訓練，眾所周知，訓練數據集的質量直接影響模型的最終效果，這比選擇哪種模型基座或訓練方式更為重要。第二部分是提示詞的目標性，即使模型訓練效果再好，如果提示詞不明確，模型生成的內容也可能出現幻覺或達不到預期的問題。第三部分是業務研發側關注的數據準確性、有效性和真實性。生成的單元測試所構造的數據必須與業務高度匹配或近似，因為模型有時會生成一些不符合業務邏輯的數據，比如電話號碼，模型可能將其理解為基礎變量而生成不真實的數字，這對于業務來說是不可接受的。

其次，代碼生成效果也是我們關注的重點。我們希望通過工程化的方式，結合現有模型的能力，使代碼生成在風格和業務語義上具有更好的包容性。這對于業務是否采納單元測試至關重要。我們期望生成的代碼不僅在技術上無誤，而且在風格和語義上與業務需求相匹配，以便業務研發團隊能夠輕松地采納和集成這些單元測試。

數據質量提升：工程化分析解決數據難題

數據充分度提升

在提升數據質量方面，我們采取了一系列工程化的分析方法來協助模型解決數據難題。我們主要關注兩個問題：數據的真實性和充分度如何提升，以及如何確保模型的提示詞數據能夠被準確理解。以下是我們面臨的幾個具體問題和相應的解決方案。

首先，被測方法的入參構造非常復雜，不僅僅是基礎變量，還包括復雜的結構體或嵌套結構體，這使得在編寫單元測試時構造數據的難度大大增加。其次，脫離業務理解生成的數據價值不高，這是我們與業務團隊溝通后得出的結論。第三，出入參的相關性不足，有些函數依賴大量數據庫、外部 RPC 或三方組件，這些依賴數據的變化會導致目標函數的條件路徑發生變化，這是一個關鍵環節。最后，斷言的目標性是否準確將決定生成的單元測試是否具備一定的有效性和通過率。

針對這些問題，我們提出了一個三部分的解決方案。 第一部分是基于流量來源的收集和采納。 首先，我們與業務團隊溝通后發現，真實的流量主要來自真實的手工測試或線上業務流量，這是一部分來源。其次是接口自動化，其維護成本和時間成本相比編寫單元測試要低一些，通過業務真實定義的接口自動化能夠實現函數鏈路間的調用，從而實現函數級數據的采集。最后是測試技術服務，包括模糊測試和端到端全流量回放技術，結合代碼插樁技術，攔截代碼中的出入參和依賴參數。從而獲取數據流量中具體參數值信息作為單測生成的數據來源。

第二部分是流量蒸餾。 這些數據不僅用于單元測試生成對應的出入參構造，還有一部分數據將作為模型訓練和提示詞工程的數據語料。因此，我們需要對數據進行基本類型策略的管理和拆解，包括數據的分析、路徑推導、導入導出類型的拆解，以及后期的數據加工和合規隱私處理。由于我們獲取的線上流量中包含真實用戶數據，我們需要對這些數據進行脫敏，確保數據的真實性不被泄露。

第三部分是流量分發。 經過流量蒸餾后的數據將分發給幾個場景，包括存量生成、面向 IDE 的數據生成，以及面向 MR 流水線的單元測試生成過程。

通過實施我們的數據充分度提升方案，我們取得了一些顯著的數據結果。例如，在沒有使用流量構造方法之前，生成的單元測試中包含了一個 mock 構造函數，這個函數雖然具備了基本的框架，但是其內部的數據結構字段缺失嚴重，模型并沒有完全理解它。當我們引入流量構造方案后，情況有了顯著的改善。新的數據結構中包含了大量豐富的數據語料，這些數據更加貼近真實業務場景，因此業務團隊對這些單元測試的接受度和采納率大大提高。與以往僅依賴模型或工程方法相比，我們在數據利用率和用例真實性占比上都有了明顯的提升。首先，我們看到了用例的可信度得到了顯著提升。其次，用戶的采納率也有所增加。最后，問題的發現率也有所提高。

等價類提升思想

在進行單元測試時，我們不僅關注于發現問題，還致力于提升測試覆蓋率。為此，我們采用了等價類設計等方法，并在前期對現狀問題進行了梳理。以下是我們關注的幾個關鍵部分：

1. 被測方法中存在許多復雜路徑，我們需要識別這些路徑，并確保模型在生成過程中能夠覆蓋到這些路徑。這是一個挑戰，因為路徑的復雜性可能會導致測試用例無法覆蓋到所有可能的情況。

2. 模型推理過程中非常依賴于提示詞的準確性和完整度。如果提示詞不準確或不完整，模型生成的測試用例可能無法達到預期的效果。

3. 路徑條件的差異可能導致斷言失敗。例如，如果預期是通過路徑 1 或 2 到達斷言點，但實際生成的測試用例卻通過路徑 2 或 4 到達，那么斷言可能會失敗，導致業務團隊需要修復大量的失敗案例。

4. 異常路徑的考慮。在時間緊張的情況下，開發人員可能只會編寫主要路徑的單元測試，而忽視了異常路徑，如異常捕獲或難以到達的小模塊路徑。這些路徑的參數構造復雜度高，且難以覆蓋。

5. 對于已有的單元測試，我們的目標是提升那些測試覆蓋率較低的存量代碼。我們需要確保新生成的單元測試與業務代碼風格保持一致，并且避免重復已有測試用例已經覆蓋的類目。

我們目前的解決方案是將模型和工程方法相結合，以解決單元測試中的路徑覆蓋問題。以一個具體的函數為例，該函數包含多個調用分支路徑。我們的目標是讓測試能夠覆蓋到特定的路徑，比如 ACD 或 ACE 路徑。在拿到原始的被測方法后，我們會通過工程化的方式將其調用路徑拆解出來。拆解后，模型會對 mock 層和依賴返回數據做出決策并生成測試用例。生成測試用例后，我們會在閉環迭代中持續優化矯正，直到測試路徑達到預期條件。在這個過程中，我們會結合靜態代碼分析的能力，識別未覆蓋的路徑和條件是否真正達到了我們的生成預期。如果達到了，那么這個測試用例就可以被認為是符合預期的。

在整個拆解過程中，我們分為三個部分： 被測函數的要素分析、邏輯分析和路徑分析。 我們會利用 AST 和 IR 等程序分析技術，對代碼中的控制流和數據流進行條件組合關系的前期拆解。具體來說，我們首先將被測方法中的入參、出參和中間變量參數拆解為可控變量。通過對這些可控變量的分析，我們能夠完成數據流的前期分析工作，為后續的測試用例生成打下基礎。然后，在邏輯分析階段，我們關注于代碼中的分支類型控制組合以及變量溯源過程。這一步驟涉及到理解代碼中的邏輯結構，包括條件語句、循環語句等，以及變量是如何在這些邏輯結構中被操作和傳遞的。最終，我們將這些分析結果綜合起來，進行路徑分析。路徑分析的目的是識別代碼中所有可能的執行路徑，包括路徑 X、路徑 Y 和路徑 Z 等。這些路徑的前期拆解條件對于模型來說至關重要，因為它們為模型提供了在生成不同路徑的單元測試時所需的詳細信息和依據。

數據的效果和模塊的價值在這個過程中非常重要，它們不僅為模型推理提供了語料補充，還為斷言生成提供了支持依據。此外，這些數據對于我們后續計劃中的存量單元測試的保鮮也是一個重要的環節。

模型與程序分析的融合

在我們的工作中，模型與程序分析的融合是一個關鍵的發展方向。在這一過程中，工程化的方法和模型各自承擔著不同的角色。這個過程可以分為三個階段：首先，在程序分析的前期，我們需要對目標函數的語料進行拆解和解析。這一步驟是基礎，為后續的模型生成框架補充和路徑提升提供必要的數據。接著，模型會利用這些解析后的數據進行生成框架的補充和路徑的提升。在單元測試生成過程中，由于不能保證所有生成的測試都能一次性通過，因此還需要進行語法修正。最后，對于斷言部分，我們也有相應的修正策略。

總結這一融合過程，我們可以從兩個方面來看其優勢。首先，工程化方法的優勢在于其對代碼分析的準確率和穩定性。程序分析技術在國內已經應用多年，因此在分析的準確性和穩定性上具有很高的水平。由于單元測試需要實際運行來驗證效果，工程化方法具備檢測運行的能力。其次，模型的優勢在于其靈活性和泛化效果。模型在靈活決策和泛化效果上比工程化的固定策略要好，這也是現在很多智能代理所做的事情。

這里我總結了兩個關鍵點以及模型生成和模型修復所需的語料條件：

首先，當模型生成時，它需要一些特定的條件數據，包括路徑數據、函數簽名以及依賴結構體的定義。這些數據對于模型來說是至關重要的，因為它們構成了模型生成所需語料的基礎。

其次，在模型修復方面，我們需要修復在編譯或運行過程中遇到的問題。例如，如果在運行過程中出現了錯誤堆棧，我們需要將這些具體的報錯信息提供給模型，以便它能夠更好地理解并進行修復。這包括錯誤相關的數據結構和錯誤類型。簡而言之，當我們希望模型進行修復時，提供給它的信息和語料越詳細，模型的準確性就越高，同時它需要考慮的約束范圍也就越小。

代碼生成效果提升：模型化建設提升代碼效果

這一部分重點介紹我們在單元測試生成過程中，通過模型實現的一些關鍵進展，可以分 為四個主要部分：

1. 模型泛化效果如何提升。這是至關重要的，因為它決定了模型在面對未知代碼時是否能夠生成有效的測試用例。

2. 模型提示詞選擇策劃。在生成過程中，選擇合適的提示詞對于引導模型生成高質量的測試代碼非常關鍵。

3. 無流量單側方法如何生成有效的單測數據。盡管我們嘗試使用真實的業務流量來生成單元測試，但在這個過程中，我們遇到了一些挑戰。例如，一些業務的流量非常有限，或者某些方法根本沒有被執行到。此外，由于工程的不穩定性，我們收集到的數據往往是不完整的。因此，我們研究了如何利用模型來補全這些無流量的數據，以便對未被測試的方法進行測試。

4. 模型效果生成評價。對模型的評測是能夠持續不斷的矯正和確認效果是否提升的主要方式，將輔助我們持續調整正確的方向。

模型工程整體架構

模型工程的整體架構。最底層是數據環節，包括數據的收集和訓練評估工作，其中有些工作仍在進行中。

我們的數據訓練策略分為三個步驟：

STEP1 訓練樣本構建。我們選擇了內部大量的代碼庫作為數據來源，這是因為不同公司在編寫單元測試時會使用自己的測試框架和標準，這有助于模型更好地理解公司內部的標準和組件使用策略。其次，我們選擇了 GitHub 上星標高的項目作為訓練目標，以確保數據的質量和多樣性。第三，對于數據量有限的小場景或特殊組件使用情況，我們會借助市面上效果較好的模型，如 GPT，來擴充我們的模型。第四，我們正在進行基于反饋的優化，但這部分的優化工作尚未完全啟動。

STEP2 模型的選用。經過前期的嘗試，我們最終選取了一款適用于本項目的模型作為后期持續訓練基座。在提示詞的選取上，我們從單純的 one-shot 或 few-shot 方案轉變為結合思維鏈的方案，這在路徑提升、語法修正和斷言生成方面取得了顯著的效果。

STEP3 模型的評測及優化。我們采用人工主觀評測和機器評測相結合的方式，通過評測結果進行偏好打分，并將優質數據反饋給模型進行多輪迭代，以持續提升模型效果。

數據工程建設

在數據工程建設方面，我們需要確保數據集的可信度和純凈度。我們希望數據集中包含多種編程語言，以覆蓋不同的編程階段。同時，我們將其細分為六個關鍵環節，以確保數據的質量和有效性，從而提升大模型的理解能力和泛化效果。

1. 樣本打標，是至關重要的一步。通過為樣本打標，我們幫助大模型更好地理解數據，同時，打標數據的多樣性也有助于進行多樣化評估。這種評估能夠使模型在更廣泛的模式中學習，進而提高模型的泛化能力。

2. 樣本篩選，采用業界標準做法，排除低質量數據。

3. 隱私過濾，處理隱私相關問題，確保數據的合規性和安全性。

4. 格式處理，數據風格的統一和特殊字符的處理。我們進行一系列的數據優化工作，以確保數據的一致性和可讀性。

5. 數據簡化，是我們特別關注的一個環節，尤其是在代碼簡化方面。這不僅有助于單元測試的生成，也提升了模型訓練的效果。通過簡化數據，我們能夠更有效地訓練模型，使其能夠更快地學習和適應。

6. 數據配比打亂，確保數據來源多樣性的關鍵步驟。由于數據往往是分塊收集的，我們需要混合這些數據，以實現多元學習的效果。這種混合數據能夠提供更全面的學習場景，進一步增強模型的性能。

在代碼簡化方面，我們面臨的一個主要挑戰是業務代碼中的業務語義非常多。這些代碼在字段命名、方法體命名以及變量命名上都具有很強的業務特定性，這對于模型來說增加了額外的學習成本。為了解決這個問題，我們采用了一些來自業界和學術界的優秀思路，制定了一個簡化方案。

我們的方案主要包括兩個部分。首先，我們嘗試從代碼中抽取關鍵數據，保留函數聲明、函數調用語句、控制流和變量信息，以及 return 信息。這樣，我們可以剔除那些復雜的日志處理和不影響路徑的無關內容，從而簡化代碼。其次，我們對那些業務語義重的字段進行轉譯。例如，將“中國建設銀行”這樣的字段轉譯為 Y0、Y1、Y2 等，這樣做既保留了代碼的原貌，又不會影響代碼邏輯。通過這種方式，我們可以減輕模型訓練的負擔。

此外，我們還注意到不同編程語言中，如 Python、Go、Java 或 C++，這些語言對應的 print 函數的實現方式各不相同。因此，我們對這些不同編程語言的差異進行了簡化，統一為模型可識別的 print 操作。在模型完成代碼生成后，我們再根據之前的轉譯規則將代碼轉換回原始形式，以獲得更準確的結果。在代碼簡化之前，我們觀察到 loss 的下降和收斂效果非常慢。但在實施代碼簡化后，與之前未簡化的代碼訓練過程相比，loss 的下降趨勢明顯改善。這表明代碼簡化對于模型訓練的效率和效果都有積極的影響。

PE 工程及模型微調

PE 工程路徑規劃覆蓋了多個方面，包括對被測代碼的理解、路徑識別、入參理解，以及 mock 規劃，這些都是為了確定哪些 mock 會導致不同路徑的執行。最終，我們讓模型學習并生成求解。在這個過程中，我們將工作細分為四個主要部分：路徑提升、參數補全、語法修正和斷言修正。實驗結果表明，不同的提示詞方式對效果有顯著差異。例如，在參數補全方面，如果提供樣本，模型可能會模仿這些樣本來構造輸出，這會影響其在真實業務語義上的泛化效果。相反，使用 zero-shot 的方式，即不給模型任何樣本，有時會得到比預期更好的結果。

我們目前主要處于模型微調階段，我們還希望通過結合微調和獎勵模型來進一步提升效果，未來可能會涉及到 PPO，但鑒于資源和成本的考慮，我們尚未開始這一階段。我們的目標是生成一個策略模型實現持續的強化學習反饋和單測生成的動態決策。

評測工程建設及效果

我們針對評測集設計了不同階段的專項評測集，以便模型進行更精確的評測。

在評測工程建設方面，目前已經實施了一系列基礎評估工作，這包括了之前提到的人工評估，以及我們針對業務和產品制定的五個評測指標：編譯通過率、覆蓋率、斷言成功率、運行通過率，以及路徑提升效果，我們通過這些指標來進行綜合評估。

目前，我們正處于基于 DPO 的多輪偏好學習提升階段，這是我們期望通過持續優化來改善的效果。在訓練效果方面，與原始模型相比，我們在斷言修復、語法修復和路徑提升方面取得了更好的成果。盡管在語法修正方面，我們的效果仍然略遜于 GPT 模型，但我們正在不斷優化數據和訓練方案，以期提升這一方面的表現。

效果度量及演示

我們對度量工作進行了細致的拆分，主要關注兩個方面的提升：覆蓋率和場景支持。

目前，我們在倉庫級的覆蓋率上已經取得了顯著的成績，平均覆蓋率達到了 40%。通過采用基于 DPO 的偏好方案進行重訓后，部分倉庫的覆蓋率甚至提升到了 60%。這是在我們已經生成過的倉庫基礎上，通過重新生成得到的成果。在斷言通過率上，我們也達到了一個較高的水平，單個方法的覆蓋率提升到了 83.09%。

在場景支持方面，我們結合工程實踐來輔助模型，包括在指標統計和數據優化策略上，都提供了策略上的支持。我們的目標是向業務研發交付一個無需二次介入修正的單測生成產品。這意味著提供的單元測試在編譯、運行、語法和斷言上都不存在問題，業務研發只需審查生成的單元測試是否符合預期即可。

最關鍵的是，我們需要確保每個測試用例對真實路徑的提升都是有價值的。我們模擬了整個單元測試的生成流程。這包括流量獲取、路徑選擇、單元測試生成、語法修正、檢測、斷言修復以及路徑提升識別。如果一個測試用例已經提升了路徑，我們就認為這個案例是成功的，并繼續下一個路徑的提升。在斷言檢測過程中，我們發現有些斷言并不符合預期，例如，預期為 false 但實際上生成的結果是 true，這也是需要我們持續優化和矯正的場景 case。

而對于業務的訴求而言，例如，我們向業務交付的倉庫之前沒有任何單元測試，這也是他們的一個痛點。通過我們的生成，目前效果達到了 63.92%，生成了 2,627 個測試用例。面對生成的 2,627 個單元測試用例，我們深知業務后續的維護工作將面臨挑戰，因為維護這些測試的成本相對較高，而且逐個檢查每個測試用例的難度也較大，不如自己編寫的代碼容易理解。為了解決這一問題，我們已經規劃并實施了一系列措施，將在可維護性和可讀性上為用戶持續提升便利。

總結及規劃

總結目前我們已經完成的工作。 首先在 基礎層 上我們完成的工作包括能力分析、數據構建，以及環境問題的解決。 這些基礎工作 為后續的測試維護提供了堅實的支撐。 第二層 生成層 ，這涉及到整個單元測試框架的生成、路徑提升以及數據轉換過程。 通過這些優化，我們提高了測試生成的效率和質量。 第三層 修正層 ，這里我們實施了一些修正方案，包括語法修正、運行修正以及斷言修正。 這些方案有助于確保生成的測試用例在語法和邏輯上的正確性，減少后續的維護工作。 最上層是統計 & 應用層，提供業務產品化體驗能力，360°可視化度量體系，提升可觀測性。

在規劃方面，我們目前的工作重點包括模型的持續優化、用例召回分析、用例保鮮機制以及產品多元化。這些是我們持續進行的工作，其中用例召回分析和用例保鮮機制是我們目前特別關注的兩個方面。其中，

用例召回分析是指我們生成了許多測試用例后，如何檢測這些用例的召回有效性是否具有價值。這些用例會在業務的日常迭代的持續集成（CI）環節中運行。如果運行后出現失敗的用例，我們需要分析失敗的原因。目前，我們的初步思路是結合模型來識別關鍵日志和平臺性數據中的異常，進行問題的深入分析。這個過程中，我們會進行降噪，因為 CI 中的用例失敗可能不僅僅是問題的發現，還可能因為環境因素或平臺因素導致，這些都需要我們進行降噪處理。

用例保鮮則是指如何在日常業務研發中持續保證上述示例介紹的 2,000 多個用例的有效性和正常通過率。這是一個我們正在努力的目標，目的是確保這些用例能夠適應業務的變化，保持其準確性和相關性。

演講嘉賓介紹

趙亮，13 年工作經驗，先后在螞蟻集團余額寶質量技術和研發效能任職，現就職于字節跳動質量技術團隊，擔任質量內建智能化場景技術負責人，曾發表 4 篇國家技術專利。在質量技術、程序分析以及智能化相關場景的應用上有豐富的項目經驗和落地成效。

資料來源：火山引擎-開發者社區

Alexa排名趨勢

• 網站綜合信息查詢
• 百度權重查詢
• 360權重查詢
• 搜狗權重查詢
• 神馬權重查詢
• whois信息查詢
• Alexa排名查詢
• 友情鏈接檢測
• 網站IP查詢
• 網站備案查詢