[發明專利]測試方法和裝置

有效

• 申請號: 201611020206.6
• 申請日: 2016-11-17
• 公開（公告）號: CN108073506B
• 公開（公告）日: 2021-04-30
• 發明（設計）人: 郭昭;楊艷;彭云鵬;史磊
• 申請（專利權）人: 百度在線網絡技術（北京）有限公司
• 主分類號: G06F11/36
• 分類號: G06F11/36
• 代理公司: 北京英賽嘉華知識產權代理有限責任公司 11204
• 代理人: 王達佐;馬曉亞

本申請公開了測試方法和裝置。該方法的一具體實施方式包括：獲取預設的測試類型集合，其中，測試類型集合中的每個測試類型具有相應權重；接收測試用例集合，其中，測試用例集合中的每個測試用例對應于測試類型集合中的一種測試類型；執行如下測試用例驗證步驟：將每個測試類型對應的測試用例個數與每個測試類型對應的權重的乘積作為每個測試類型的統計結果；將各個測試類型的統計結果之和作為測試類型集合的統計結果；確定測試類型集合的統計結果是否大于或等于預設的閾值；若測試類型集合的統計結果大于或等于預設的閾值，則使用每個測試用例進行測試并輸出測試結果。該實施方式能夠提高測試效率從而增大測試覆蓋范圍。

技術領域

本申請涉及計算機技術領域，具體涉及互聯網技術領域，尤其涉及測試方法和裝置。

背景技術

如何衡量測試的完備性，現有技術提供了如下兩種解決方法：第一種方法是當前最主要的衡量測試方法，其根據需求文檔對需求列表逐項驗證；第二種方法是根據回歸測試中問題的收斂情況來判斷，如果問題下降的曲線符合某種下降的趨勢，則可以認為是版本質量趨于穩定，可以用于實際運營。然而上述現有的兩種測試方法均存在比較明顯的缺陷，很難對業務測試的充分性與完備性進行評估。第一種方法中測試的完備性是否充分很大程度上依賴于需求文檔的完備程度，而且往往需要測試人員有較豐富的測試經驗。由于需求文檔中的設計、實現之間隔開了幾個階段，事實上很難保證需求文檔與業務邏輯之間的完全一致性。因此在需求文檔不詳細或需求文檔不能完全反映版本的現狀時，根據需求文檔事實上很難得知版本測試的完備程度。第二種方法的使用有一個前提，就是事先假定測試人員開始測試時就覆蓋到了所有特性，如果測試人員一直都忽略了某個特性，即使問題曲線收斂非?？?，版本測試也是不充分的。

當前在軟件測試項目中，無論是個人計算機、移動還是網頁端測試，都引入了發散測試的概念，對軟件質量保證起到了一定作用。但對于發散測試本身，由于沒有統一的指導原則和衡量標準，因此存在著盲目設計測試用例、隨意設計測試用例導致測試效率低下等問題。

發明內容

本申請的目的在于提出一種測試方法和裝置，來解決以上背景技術部分提到的技術問題。

第一方面，本申請提供了一種測試方法，該方法包括：獲取預設的測試類型集合，其中，測試類型集合中的每個測試類型具有相應權重；接收測試用例集合，其中，測試用例集合中的每個測試用例對應于測試類型集合中的一種測試類型；執行如下測試用例驗證步驟：將每個測試類型對應的測試用例個數與每個測試類型對應的權重的乘積作為每個測試類型的統計結果；將各個測試類型的統計結果之和作為測試類型集合的統計結果；確定測試類型集合的統計結果是否大于或等于預設的閾值；若測試類型集合的統計結果大于或等于預設的閾值，則使用每個測試用例進行測試并輸出測試結果。

在一些實施例中，該方法還包括：若測試類型集合的統計結果小于預設的閾值，則接收新增的測試用例，并將新增的測試用例添加到測試用例集合中繼續執行上述測試用例驗證步驟。

在一些實施例中，該方法還包括：確定測試類型集合中的各個測試類型對應的測試用例的測試通過率是否大于預設的通過率閾值；若大于預設的通過率閾值，則接收新增的測試用例并繼續執行上述測試用例驗證步驟。

在一些實施例中，該方法還包括預設測試類型集合的步驟，包括：響應于接收到包括用戶身份標識的登錄請求，根據用戶身份標識確定用戶是否具有設置測試類型集合的權限；響應于確定出用戶具有設置測試類型集合的權限，則按照用戶輸入的設置命令設置以下至少一項：測試類型、權重、測試用例。

在一些實施例中，接收測試用例集合包括：響應于接收到包括用戶身份標識的登錄請求，根據用戶身份標識確定用戶是否具有增加測試用例的權限；響應于確定出用戶具有增加測試用例的權限，則接收用戶輸入的測試用例，并記錄用戶身份標識。