<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    小螞蟻  
    風雨過后才見彩虹
    公告

    • —————————————
      李麗君
      軟件測試工作者
      廣東籍貫的海南人
      北京生活12年
      目前在深圳

      郵箱:
      llj2003hbdd@163.com
      —————————————
      說明:本Blog中的內容均為本人原創或轉載,本人依法保留Blog內原創文章的所有權利,如需轉載,請注明作者及出處。未經許可,不得將本Blog內文章用于任何盈利性用途。
      —————————————
    日歷
    <2012年6月>
    272829303112
    3456789
    10111213141516
    17181920212223
    24252627282930
    1234567

    導航

    常用鏈接

    留言簿(174)

    隨筆分類(189)

    0--感興趣的網站

    1--國內測試網站

    2--測試同行的blog

    3--開發好友的blog

    最新評論

     

    編寫背景:

    最近親自在跟兩個重要項目,感受很多,明天準備寫其中一個項目的項目測試總結在組內分享,有一個還在背后默默關注。

    在深圳工作1年了,每當組內的測試人員出現一些很常識的問題和面試過的測試人員回答的一些問題;非常明顯的感覺到南北測試人員工作水平和對測試工作理
    解的差異,在深圳想找到有共鳴的人好難啊。

    今天寫這個文章,只是把工作中的一些片段和場景與大家分享,希望測試新人在做測試工作中多一些執著、多一些思考和多問為什么?

     

    故事1:搜索列表頁的一個神奇bug

    問題現象:一個已經測試通過并上線的商品搜索列表頁,頁面功能很簡單、有搜索的篩選項、商品展示、商品翻頁功能。通常大家在測試翻頁功能時,基本測
    試點都是測試上一頁、下一頁、具體頁數、頁數輸入框(正常、異常);有意思的是這個搜索列表結果有
    500多個商品1百頁,我就一直點擊下一頁、一頁一頁的瀏
    覽商品,當瀏覽到第
    24頁時,發現瀏覽器訪問報錯提示連接不上;訪問其它網站或該網站的其它功能就正常。

    問題分析:此處的點擊下一頁的翻頁程序代碼,每翻一頁,URL請求就會多加一串字符“swIFRPIDUwMH0gcHJpY2VfQ05ZOjUwMDxKaW1pPnByaWNlX0NOWTp7MCBUTyA1MDB9IHByaWNlX0NOWTo1MDA8SmltaT5wcmljZV9DTlk6ez
    AgVE8gNTAwfSBwcmljZV9DTlk6NTAwPEppbWk+cHJpY2VfQ05ZOn”;這串字符出現6次以上后,url訪問長度超過2k瀏覽器請求就會參數丟失,導致頁面訪
    問報錯

    5個思考點:

    思考1:為什么測試的時候沒有發現呢?其中一個測試人員說,這個場景很少有人想到。

    思考2:測試人員如何能測試出這種問題呢?我在想,聰明的辦法那就是對設計實現熟悉了解,了解開發是如何實現的,應該可以想出來這個地方會有問題。另
    一個辦法就是增加這樣的測試點,用自動化測試腳本來測試這種大數據量的功能極限測試。

    思考3:對比其它網站,為什么別的網站沒有這種問題呢?開發在設計上沒有考慮這種情況?

    思考4:為什么開發沒有自測發現這個問題?我在想,開發沒有考慮到URL會有問題

    思考5:我們如何改進和提高呢?我在想,測試除了要補充測試用例;開發要整理出搜索結果列表頁的一些設計規范,同時要參考和同行對比;開發要對系統的
    實現邏輯加強極限測試。

    最后我想,還好這個場景不常見,影響范圍沒有很大的殺傷力。

     

    故事2:兩個bug還是1bug

    現象:一個問題是:商品買滿打XX折,從購物車進入到訂單提交頁中,商品總結算金額顯示不正確;另一個問題是:商品買滿減XX元,從購物車進入到訂單提
    交頁中,商品總結算金額顯示不正確。開發認為這是
    1bug,因為都是商品總結算金額顯示不正確;我認為是2bug,因為是兩個不同的測試用例場景得出的問
    題,不能因為現象一樣就認為是一個
    bug,同時懷疑代碼里面的處理邏輯是不一樣的。

    分析:為什么這種問題在我過去工作8年的公司和開發團隊,沒有開發管理人員認為這類bug1個,而認為是2個;而這位開發管理人員認為是1個;我在
    想:原因是這位開發管理人員很害怕
    bug?還是這位開發管理人員很不喜歡看到很多的bug,因為今天我們測試兩個頁面,4小時報了35bug讓人心情很不爽?答
    案不知道,只要解決就好。

    5個思考點?

    思考1:站在用戶角度,如果是用戶發現的,我們告訴用戶是1個問題?用戶能明白嗎?

    思考2:站在開發設計角度,需要知道那個地方的實現邏輯都是一個類或方法嗎?即使是一個類或方法,當參數不一樣時內部處理邏輯一樣嗎?找個時間問具體
    寫代碼的開發人員問問就知道了?

    思考3:下次碰到此類開發管理人員該如何相處?我在想:只要改了就行,不能和這類人去糾結1個還是2個,因為道不同不能理解;但是測試工作總結時要算成
    2個。

    思考4:為什么不能報成1bug,因為當把多個bug放到1bug里報時,如何有效跟蹤?(比如:開發修改轉測后,測試驗證有一部分沒有修改好,這個bug
    來回修復、打開);如何有效做
    bug分析?(測試任務結束后,如何分類分析bug的錯誤類型及開發工作改進建議數據分析)。

    思考5:為什么這么明顯的bug開發沒有自測出來?開發做自測了嗎?這樣的開發管理人員管理的開發團隊,轉測出現這樣低級的bug,消耗了多少不必要的測試
    成本(測試環境部署
    +bug報告跟蹤和驗證時間)和開發修復版本成本?降低了多少工作效率?這類bug有多少?

    最后我想:我要通過什么方法來改變?

        生活還在繼續、工作也在繼續,世界之大、無奇不有,每天都有不同的見聞和收獲,活著真好!

     
    Copyright © lijun Powered by: 博客園 模板提供:滬江博客
    主站蜘蛛池模板: 91香蕉视频免费| 亚洲VA中文字幕不卡无码| 免费精品视频在线| 国产亚洲精品资源在线26u| 久草视频免费在线观看| 国产亚洲精品美女久久久久 | 亚洲成av人在线视| 欧洲黑大粗无码免费| 日本一区二区在线免费观看| 亚洲视频在线视频| 四虎成人精品在永久免费| 一级毛片免费观看不卡视频| 久久水蜜桃亚洲AV无码精品| 亚洲第一成年男人的天堂| 国产又粗又长又硬免费视频| 99久久国产免费中文无字幕| 一级做a爰黑人又硬又粗免费看51社区国产精品视 | 亚洲成在人线电影天堂色| 亚洲国产成人精品女人久久久| 97在线视频免费| 久青草视频在线观看免费| 亚洲熟妇成人精品一区| 亚洲国产天堂久久综合网站 | 日日噜噜噜噜夜夜爽亚洲精品| 我的小后妈韩剧在线看免费高清版 | 亚洲乱码一二三四五六区| 中文字幕亚洲不卡在线亚瑟| 野花高清在线观看免费3中文| 成全高清在线观看免费| 精品久久久久久亚洲中文字幕| 亚洲综合无码一区二区三区| 亚洲人成网77777色在线播放| 浮力影院第一页小视频国产在线观看免费| 少妇太爽了在线观看免费视频| 黄色毛片免费在线观看| 国产亚洲玖玖玖在线观看| 亚洲高清日韩精品第一区| 中文字幕亚洲无线码a| 又爽又黄无遮挡高清免费视频| 在线永久看片免费的视频| 久久免费国产精品一区二区|