<sub id="l9qyp"><listing id="l9qyp"></listing></sub>

    <form id="l9qyp"><legend id="l9qyp"></legend></form>
      1. <wbr id="l9qyp"></wbr>
        1. 更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          出現bug,你該如何應對?

          • 發布:軟件測試培訓
          • 來源:網絡
          • 時間:2017-05-24 11:00

          Bug,一種傳說中的昆蟲類動物。形狀多變,往往根據生存環境隨意變化其外形特征。常常和一類叫做 “程序猿” 的靈長類動物共存。而猿在工作之余,往往以抓殺自己的 bug 作為消遣。當某些 bug 演變成具有較大破壞性的時候,集體捕殺,或是替別的猿抓殺其 bug 的情況,在猿族內也常有發生。

          Bug 的繁殖環境

          Bug 的繁殖速度,總的來說,和三個條件有密切關系。一是猿自身的清潔衛生的保持情況;二是他們的工作強度有密切的關系;三是工作環境中各種防蟲措施的有效程度。

          一個項目的推進,通常有四種情況:

          · 負責的程序員,緊張的進度:這種情況,往往也是一個快速試錯、快速迭代的開發流程。在開發的過程中,可能會出現一些 bug。但是因為程序員還是很負責任,所以在項目收尾后,會有自發的 bug 清理。因此,雖然過程中很多代碼不夠理想,但是開發速度極快,最后狀態也比較優質。缺點是中間某些階段代碼質量(即使是沒有上線的)可能被質疑。

          · 不負責的程序員,緊張的進度:和上面類似,但是最后系統中會埋下很多沒有妥善處理的坑和 bug 蛹。給后面維護的程序員帶來很多不便和負擔。

          · 負責的程序員,不那么緊張的進度:這種時候自然可以不緊不慢,三思而后行。Bug 生的少,但是開發的速度也會稍有延緩。

          · 不負責任的程序員,進度是不是緊張,他們也不管:做得越少,錯的越少。這種情況下,bug free 都是有可能的,反正項目能不能按期,不關他的事。

          所以呢,如果上層的管理者真的了解情況,或是對你有信任,那么只要你負責,交付的是好的實現,那么上面的第一種和第三種都是比較理想的結果。如果又有很緊張的進度,那幾乎所有有開發經驗的人都知道,快速迭代是最有效的開發模式。尤其多個工程師同時改相關的代碼,在開發的過程中,不可避免因為相關、依賴等原因,有些中間狀態的代碼會有瑕疵。

          如果上層的態度不明確,或者有盯著你要給你小鞋穿的人,那么做不到第三種,就不妨做第四種。而最吃力不討好的,就是第一種。

          如果根本沒有人在乎代碼質量,只在乎進度,那么就是第二種了,也是最糟糕的一種情況。

          Bug 的遏制

          如果系統里已經有很多 bug,而且有些因為寄生太久,已經搞不清是從哪里冒出來的了,又要怎么盡量達到一個 bug free 的環境呢?

          當團隊很小的時候,很多靠自發自覺的潛規則都可以很好的運轉,大家都比較自覺的維護代碼的質量,bug 抓一個修一個。而當團隊大到一定程度的時候,這種自發自覺便逐漸失效。靠一些人的努力,bug 似乎根本修不完。

          舉個例子。在一個組里,往往會出現這樣一種情況:小 J 經常主動幫助修理一些 bug,所以她了解的業務邏輯越來越多。一方面,她的成長很快,但這種快一定會達到一個瓶頸。另一方面,出現 bug,很容易別人就找她,她修 bug 也會越來越多。

          而一些平時因為種種情況(懶、滑、太忙、不太懂……)從來對 bug 連推帶拖的人,找他的人也會越來越少。對這種人而言,系統了解的少,但是也省出一些時間。

          所以,從某種意義上來說,這種不公平很容易產生。而且產生的特別自然,并進入一個良性還是惡性的循環。而最終,小 J 也會對太多的 bug,或是因為自己太忙,而無能為力。

          另一個現象,就是大部分所有權明確的 bug 很容易得到處理,而一些三不管地帶的 bug,往往可以被一再忽視,成為千年老 bug。比如,一個項目遺留的 bug,但是整個項目組都已經拆了;比如,一個前員工留下的 bug,但是這個人已經離開很久了;比如,很難界定這個 bug 屬于哪個組,或者需要動的代碼涉及到外組等等……

          而這樣的 bug,如果沒有從上層發起的重視和方案,或是幾個真正把公司的事看成自己的事的能人,往往不論影響多少用戶,也很難被重視。

          和一個高層的管理人員討論過相關的話題。高管說:可以通過一定的獎勵機制來鼓勵修 bug。但我不禁提出幾個質疑:

          1、如果獎勵修理 bug,那么必然 bug 多的組更有可能修理更多的 bug。這會不會從某個意義上,又傷害到代碼質量?

          2、有一些人修理的是自己的 bug,這種該不該獎?

          3、會不會有人過于耽于找 bug,修 bug,而影響到正常的開發工作?

          4、高管說了這樣一段話。

          很多 bug 的道路,就好像在沒有告訴公路上行駛的很多車輛。不論怎樣,你都快不了。當有這樣一個機制來鼓勵清理 bug 時,就好像是修了一條高速公路。這雖然不能保證所有的時候所有的車都可以暢通無阻,也不可避免有的人開始飆車,引起別的問題。但至少,在這條路上,除非出了事故,否則你就有了最低限速,確保大部分時候,還是比沒有這條路時,交通要好的多。

          想來似乎也很有道理。

          預約申請免費試聽課

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

          上一篇:app測試員究竟在測些什么?
          下一篇:開發隨筆之處理非功能需求

          軟件測試之業務測試如何做?

          分享數據分析思路的4點心得

          大數據測試分類與階段

          LoadRunner檢查點

          • 掃碼領取資料

            回復關鍵字:視頻資料

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

          • 視頻學習QQ群

            添加QQ群:1143617948

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

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

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          奇米影视奇米色777欧美欧美一级高清片在线观看876av电影高清 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>