<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          復雜測試用例設計案例剖析,一起來燒腦

          • 發布:軟件測試培訓
          • 來源:軟件測試教程
          • 時間:2017-10-27 16:47

          雖說設計用例是每個測試人員的必備技能,但總有一些用例設計讓你不知所措,來個跟錢相關的案例給你提提神吧!

          提問

          這個是我們已經測試過的一個活動,測試過程很痛苦,由于只知道這個規則,設計用例時雖然覺得覆蓋了業務組合的所有情況,但由于不知道開發的代碼邏輯,導致上線后反復出了與代碼邏輯相關的兩個bug,就是說我們的用例沒有覆蓋開發的所有邏輯分支,如果我們做了白盒測試,就可以避免了;另外流程上不規范,復雜業務沒有做代碼 review;而業務測試時的用例設計,這個我還是很頭疼,沒有理出完整的思路。

          系不系感覺很暈菜?!

          直接看討論結果吧!

          北京-楠葉兒

          我覺得這樣的需求功能測試的邊界值和等價類劃分幾乎就可以覆蓋了,除了保證單次充值每一個分支的獎勵值有效外,還要設計向下包含每個層級的獎勵有效等。我習慣寫測試用例的時候就是小力度的劃分,這樣在復雜的業務也都變成點的組成了。

          北京-sky

          最初我也這么考慮,但測試時發現有些坑,和程序邏輯相關的,也許不屬于業務測試范疇?我們后來增加了多用戶購買一個標的,一個用戶在一個標的中下單多次的情況。

          北京-樓

          有一些邏輯還是通過代碼走查或者白盒測試比較能檢查出來,單純的業務測試案例可能不容易發現,比如一個標的重復下單你是肯定會測試的;獎勵按等級發放你也會測試的;但是,按等級方法獎勵的時候,這種奇葩的方法方式,不按人頭發放,按投標次數去發放,導致重復發放這種情況,說實話,業務案例可能就會疏漏。比如程序里有一個惡意的代碼邏輯:如果今天是2017年12月31日,則頁面彈出一個固定的消息。這個bug,你不去檢查代碼邏輯,業務測試基本沒戲了。

          北京-sky

          所以還存在流程不規范的問題

          北京-樓

          我反正是沒想到會有這種邏輯的bug出現,所以我去設計也可能覆蓋不到,因為完全不符合邏輯,用例的設計也是根據邏輯去設計,而不是隨機覆蓋一些奇葩邏輯。那只能期待隨機測試區發現,或者通過大量數據去發現

          北京-楠葉兒@北京-樓

          我還是覺得不管白盒測試還是黑盒測試都是測試方法,您說的這種情況,如果黑盒測試用例沒有考慮到的話,這個測試用例編寫人用白盒我覺得也是很難想到相關的反例,不過還是和樓管家學習到了,我第一反應確實沒考慮那么細,謝謝啦!

          北京-樓

          此類奇葩邏輯 代碼走查效果顯著

          我個人覺得測試還是以業務為主,只不過懂代碼邏輯的話,相對來說想到的測試用例覆蓋率更高一些,您說的這些情況測試用例設計者不管是白盒還是黑盒我們都要考慮,就是我一下沒想那么多。

          感覺還是挺復雜的!

          大神建議:

          這個案例看起來就是典型的邊界值的問題,復雜點可能在取“累計充值和投標的最小值”這個隱藏規則:

          第一個情況是:比如我可能只充值了5000塊,投標了5000,這5000到期后,會有利息產生,比如利息100快,這5100本息我再去投標5100,這樣累計充值還是5000,累計投標是10100,這樣就不滿足累計充值并投標10000這個檔位的要求了。

          第二個情況是:再就是充值了10000塊,但是只投標了5000塊,剩下5000塊閑著,這個也拿不到10000檔位的獎勵;

          第三個情況是:充值了10000,再投標的情況下贖回了5000(有的平臺可能限制贖回),然后剩余的5000,反復投標2次,能達到累計投標10000,此類情況是否認定為累計充值了10000還是認定為累計充值了5000.這個是需求層面需要明確的規則。

          總結:

          1、對于功能測試而言根據業務需求設計出來的測試用例就算是我們遍歷了所用的情況,只是說明我們覆蓋了業務層面的所有情況,并不代理我們遍歷了所有的代碼邏輯情況

          2、這種復雜的業務一個可以按設計好的測試用例去測試,還應該多測試異常的情況,在線上充值各種奇葩的情況都可能會遇到,就算是我們測試用例寫的再全面,畢竟是幾個人想到的情況,還有很多異常情況可能是我們想不到的

          3、做好交互測試,一個功能尤其是比較復雜的功能,最好是由兩個人或者更多的人去測試,盡量不要一個人去測試,一個人的思路是比較有局限性的,測試本來就是一個集思廣益的工作

          4、業務邏輯復雜的功能在代碼層面開發或者測試應該做一下白盒測試,排除代碼中的一些不合理或者錯誤的邏輯,從代碼層面和功能層面兩個方面測試。

          希望當你遇到此類問題時今天的文章可以幫到你哦!

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:測試設計方法:容量測試用例設計方法(干貨)
          下一篇:達內軟件測試四大測試用例編寫思路分析

          軟件測試培訓都包含哪些基礎知識?

          軟件測試培訓學什么

          UI自動化到底是難是易?

          軟件測試原則的6個基本原則

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>