qileilove

          blog已經(jīng)轉(zhuǎn)移至github,大家請訪問 http://qaseven.github.io/

          你為什么沒找到那個bug?

           作為一名測試人員我知道我不可能找到每一個錯誤。但即便如此,當一個問題從你眼前溜過,跑向生產(chǎn)這一本壘時,我經(jīng)常會問自己,我怎么就漏過了這個問題呢?有什么是我可以做得更好的?我能做些什么來防止未來這種情況的再次發(fā)生?
            這些都是很好的問題,但更實際的來說,我們需要認識到一點,錯誤往往會偷偷溜過而未被我們發(fā)現(xiàn)。有一些方法可以幫助我們減少這些未被發(fā)現(xiàn)的bug數(shù)量,但我明白沒有任何辦法能夠保證產(chǎn)品完全無缺陷。
            當我剛開始做測試時我總是對別人在我測試過的產(chǎn)品的部分發(fā)現(xiàn)bug非常敏感。我常聽到辦公室回響著可怕的句子——“誰測試過這個?為什么沒有發(fā)現(xiàn)這個錯誤?”那時我還沒有足夠的經(jīng)驗可以通過合理的方式來爭論,為什么不是任何產(chǎn)品在任意給定時間段中都可以找到所有的bug。
            雖然在某些方面,這些經(jīng)歷幫助我使我的測試方法更完備。
            所以,我列出了一些你可以嘗試一下的事情,以限制未被檢測到的bug的數(shù)量,我有幾個故事分享給大家,關(guān)于那些像夜晚的忍者那樣悄悄溜過而未被我發(fā)現(xiàn)的錯誤。這些故事表明,即使最明顯的錯誤(一旦知道就覺得很明顯),可能發(fā)生也將發(fā)生。
            我們怎么會錯過呢?
            在一個項目中,一個網(wǎng)站,正在一些關(guān)鍵部分,如注冊和產(chǎn)品選擇進行了重新設(shè)計并添加了一些額外的功能,我花了大約兩個月進行各種測試活動。在這段時間內(nèi)熟悉設(shè)置的各種變化和改進,我們都知道危險,并試圖減少它們,我們找了一些人來進行用戶支持測試以幫助測試。不幸的是,這些主要覆蓋在驗證bug修復(fù)或者專門針對測試網(wǎng)站的某些部分。
            在產(chǎn)品環(huán)境中啟動網(wǎng)站的第一分鐘,一個問題被確定。這是非常明顯的bug,也產(chǎn)生了一些相當大的混亂,它是怎么能夠被錯過的。這個問題并不是說需要任何除了會拼寫之外的特殊的技能才能找到的。在該網(wǎng)站的首頁(它通常被稱為商店櫥窗),客戶登陸后看到的你的網(wǎng)站的第一頁,在屏幕中間非常大的字體,寫著“BRAODBAND“而不是“BROADBAND”。 “這是一個非常明顯的錯誤拼寫,但不知何故,每個人都錯過了發(fā)現(xiàn)它,直到這個網(wǎng)站開始使用,然后由于某種原因,這個錯誤立即被所有人發(fā)現(xiàn)了。
            它是活的!
            我現(xiàn)在受到了“它還活著”,在1931年的老電影科學怪人中那句臺詞的啟發(fā)。當產(chǎn)品處于成熟狀態(tài),我用這句話來慢慢的推進我的想法,為了能夠看到那些可能被我錯過的東西。在這種情況下,問題是那么明顯它造成了混亂的奇怪的氛圍,而且可能因為修補程序過于簡單而無從指責。然而,這很清楚地表明了,即使是最公然明顯的錯誤也很容易被很多人錯過。
            本應(yīng)該,早該,早可以。
            這些錯誤不一定在測試過程中由于沒有找到他們而被錯過,而是因為測試者沒有考慮如果X事件發(fā)生了,在整個開發(fā)周期中將會或者可能會發(fā)生什么錯誤。當在當天晚些時候發(fā)現(xiàn)或者當產(chǎn)品在生產(chǎn)過程中發(fā)現(xiàn)這些bug時,常常招來了一句“是啊,我就覺得這可能會發(fā)生”或“我就知道會發(fā)生這個問題。”
            這些方案有時被稱為邊緣情況(極限測試情況下)或邊角情況(非常具體的,很少發(fā)生的情況下)。后者常常使我感到驚訝,因為它們可能很早就在項目中被定義為邊角情況,可是后來發(fā)現(xiàn)實際上是一些經(jīng)常發(fā)生的情況。這主要是由于不理解系統(tǒng)以及其相互作用夠好才能夠使得最初做出這樣的判斷。
            我曾有過此類的經(jīng)歷,測試一個新的需要處理成千上萬的客戶記錄的應(yīng)用程序。在測試過程中,我問了一個問題:“是否進行過負載測試?”對此的答復(fù)是“哦,這不是問題,它可以輕松地處理高達一百萬條記錄的負載。”然而,當推出了這個改變后,在前幾分鐘有顯著的負載,經(jīng)過觀察其證明之后會導(dǎo)致嚴重的問題并且對應(yīng)的代碼會被還原。在那段時間,我并沒有完全理解所涉及的技術(shù),并假定了開發(fā)人員比我知道得更清楚,可能已經(jīng)考慮過這個潛在的問題。從那天起我才知道,當我有直覺某處可能有問題,我不應(yīng)該認為別人快速而簡單的答案就是真理。我應(yīng)該從別處尋求可以支持的資料以證實或反駁我的假設(shè)。
            我的第六感正在提醒!
            我把這稱為我的“第六感”啟發(fā),當我對某些東西有一種感覺,比如我不能完全的理解或我所得到的信息看來可疑的情況下,我不愿意就此忽略它并繼續(xù)下一步除非我對其有一個合理的認識。在這種情況下,我會讓參與該項目的每個人都知道,我對這部分有所顧慮。這通常會有所幫助因為其他人會開始質(zhì)疑為什么我會有顧慮;無論是由于我缺乏相關(guān)知識使得我的假設(shè)是錯誤的,或我的假設(shè)是正確的,對我而言都沒關(guān)系。重要的是,我明白如果我忽視自己的直覺進行測試,我不認為自己能有效地做好工作
            容易復(fù)制。不容易找到。
            通常如果測試需要涵蓋產(chǎn)品或系統(tǒng)的各個方面,其場景數(shù)量會高得難以負擔。即使對于看來可以相對簡單的進行測試的系統(tǒng)也可以有數(shù)以百萬計的排列。有些辦法可以處理這樣的問題,其中之一被稱為成對(或組合)的測試,我不會在這里來詳述這個方法,但如果你想了解更多,可以看看Michael Bolton所著的對于這個方法的優(yōu)秀的處理方式。
            我對于這一類的問題的經(jīng)歷是個標準的負面答案,當發(fā)現(xiàn)一個問題時,這是100%可復(fù)制的。由于只要通過5個簡單的步驟,就次次都可復(fù)制,并最終導(dǎo)致“怎么又沒發(fā)現(xiàn)這個bug?”的指責。
            問題是這樣,基于一個復(fù)制系統(tǒng),該系統(tǒng)有多個文件夾,每一個文件都具有三個不同的使用權(quán)限,僅讀取,讀或?qū)懸约熬芙^。在每個文件夾中,每個文件都可以有相同的三個文件權(quán)限。 我現(xiàn)在更有經(jīng)驗并愿意挑戰(zhàn)回復(fù)其他人提出的意見,如“你為什么沒有發(fā)現(xiàn)錯誤?”因此,我設(shè)計了一個簡單的場景,說明給定變量的數(shù)量有限的測試,測試所有排列所需的時間是巨大的。該方案是這樣的:
            三個文件夾的層次結(jié)構(gòu)
            每個文件夾包含四個文件
            文件夾和文件都可以有不同的權(quán)限
            覆蓋這個相對簡單情況下所有排列的測試次數(shù)為14348907。這是3^15(15個實體與3種狀態(tài))。很明顯,這么大的數(shù)字顯示了你是無法在可行的時間內(nèi)測試完所有排列的。當然,你可以創(chuàng)建一個自動化的測試,以更迅速地完成,但這里的問題是,這種情況甚至不是一個現(xiàn)實世界中真正存在的情況。我僅僅是創(chuàng)建了一個簡單的練習,以顯示要測試這個看似簡單的可復(fù)制問題是有多么困難。要知道在現(xiàn)實世界中的客戶會有幾百個文件夾,包含數(shù)百或上千個文件的大層次結(jié)構(gòu)。通過交流關(guān)于這個簡單的場景很快使我能夠說明為何測試無法發(fā)現(xiàn)每一個漏洞,無論在事后它是多么的明顯。
            還有什么?
            正如已經(jīng)敘述的這三個真實世界的故事,即使你認為你已經(jīng)完成了測試而實際你還沒有。有許多原因可以停止測試,但其中并沒有你已完成了所有測試這一理由。我覺得思考我是否錯過了什么是非常寶貴的。有什么是我沒有想到的?有什么是我覺得太明顯了,就對其忽視或認為是不值得考慮?我一般盡量記錄這些問題。有些會得到答案,有些則沒有;但是這并不會阻止我思考具有啟發(fā)性的“還有什么?”。
            避免令人尷尬的錯誤!
            命名您的啟發(fā)式方法,讓你可以在未來輕松地回憶起來。
            如果你要問如何做,你才可以進行測試,當心——無論是與你的理解還是所給的答案都可能有問題。
            創(chuàng)建許多測試的想法。你真的不應(yīng)該有沒有想法的時候。
            想想“假設(shè)?”
            請注意你的情緒。他們會告訴你一些事情
            有新的眼光來看待變化,而不要指示它們要測試的內(nèi)容。
            意識到“沒有人會這么做”的聲明。
            與其他測試人員,開發(fā)人員,產(chǎn)品經(jīng)理,市場營銷——所有可用的并有意愿的人合作測試!
            在測試中,我們需要大量的實用主義。不管我們使用什么樣的方法來幫助防止檢測失誤,bug總會被漏過。使用啟發(fā)方式可以幫助減少總數(shù)。
            給啟發(fā)方式命名或助記符可以幫助您同時記住并利用它們來幫助你早期識別錯誤和防止明顯的錯誤。命名您的啟發(fā)方式可以根據(jù)自己的個人喜好來完成,因此,如果以上任何一個方法對你有用,請隨意命名并利用它們來幫助你找到那些所謂明顯的錯誤。
            作者簡介
            Stephen Blower 已經(jīng)作為測試員在不同的機構(gòu)工作了18年。目前,身為Ffrees家庭財務(wù)的測試經(jīng)理,他有令人羨慕的位置,能夠從頭開始創(chuàng)建一個測試團隊。他職位的重要部分是激發(fā)測試者,而不僅僅是創(chuàng)建流程。Stephen大力鼓勵互動和反饋,并讓測試者獲得控制權(quán),使他們成為發(fā)展具有價值的發(fā)展團隊的成員。
            譯者簡介:大頭,在讀日本九州大學修士,計算機專業(yè),主研究方向為文本挖掘,及自然語言處理。

          posted on 2014-10-30 10:47 順其自然EVO 閱讀(200) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2014年10月>
          2829301234
          567891011
          12131415161718
          19202122232425
          2627282930311
          2345678

          導(dǎo)航

          統(tǒng)計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 临武县| 石城县| 油尖旺区| 龙泉市| 澎湖县| 凌云县| 高阳县| 临高县| 永善县| 鲜城| 凭祥市| 阿克苏市| 怀远县| 勐海县| 丰宁| 息烽县| 昂仁县| 铁岭市| 溆浦县| 邻水| 射洪县| 资阳市| 依安县| 邳州市| 朔州市| 乳源| 承德市| 土默特左旗| 凤台县| 威远县| 杂多县| 陕西省| 长沙县| 关岭| 安宁市| 平谷区| 金乡县| 河西区| 宽城| 旬邑县| 梁山县|