• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
  • 左右搖擺——線上測試的成敗案例

    發表于:2013-01-30來源:一淘測試作者:惠如點擊數: 標簽:線上測試
    左右搖擺——線上測試的成敗案例. Tip(Testing in Production),即線上測試(或稱為生產環境上的測試,為了簡化,后面所有地方都使用“線上測試”)是我在博客中多次希望提及的一個主題。關于它的一個非常好的介紹可以看下Ken Johnston’的文章:《線上服務測試博客之章

      Tip(Testing in Production),即線上測試(或稱為生產環境上的測試,為了簡化,后面所有地方都使用“線上測試”)是我在博客中多次希望提及的一個主題。關于它的一個非常好的介紹可以看下Ken Johnston’的文章:《線上服務測試博客之章節1:摘要》,這是我和Ken、Ravi Vedula一起合作的關于“線上服務測試”文章摘要的最新版,曾發表在ThinkWeek上。如果你不想花時間閱讀那篇文章,那么我用一句話來總結下:

      盡可能地利用線上環境,即數據中心和真實的用戶,來測試我們的產品與服務,因為我們的系統總是如此復雜,以致于很難在測試環境中測試(試想一下那各種的分層,各種依賴和各種集成),同時我們幾乎不可能在測試環境中為系統的運行環境建立測試模型(試想一下軟件的規模、用戶的多樣性和場景的多樣性)

      當然,遠遠不止這些內容,所以去好好看看Ken那篇出色的博文吧,不過,假如你很著急,我也希望我的簡單總結能幫到你,不讓你因為不了解背景而感到困惑。

      當不可抗力遭遇不動體

      我曾經為鋼鐵廠寫過一個自動化熱軋機的軟件。一種熱軋機有多個(通常說是4個)連續的臺子,每個臺子由一組幾噸重的像洗衣店的絞擰機一樣的鋼軋輥組成。一個燒得通紅的,溫度高達2400華氏的,10噸重的鋼板,朝著輥間距離小于鋼板厚度的第一組鋼軋輥快速前進,接著進入距離更小的鋼軋輥,就這樣一直到從另一頭出來的鋼要比原來薄的多,寬得多(記得質量守恒),可以用來做罐頭、汽車門或者各種管子。

      我寫代碼來確定輥間距離,以達到產品原本要求的厚度和屬性(亦稱為二級體系),但機器的實際運動是由更多基礎的我們稱之為一級體系的邏輯編程完成的。所有人——無論采用一級,二級,用戶界面還是其他體系,都曾用相同的方式開發軟件。我們拿到說明書,編寫代碼,用內部的模擬器檢驗,然后聚到一起用模擬器檢驗集成的產品,最后實地試驗。

      你可能已經注意到我們不是一個軟件公司,和這樣一群工程師一起測試我們的代碼,他們中的大部分人從來沒有聽說過專業軟件測試,幾乎完全不懂瀑布模型,敏捷開發,統一軟件過程(RUP)或其他軟件過程。我說到我們曾直接在現場試驗,那些程序毫無知覺地開始演練,簡單地驅動那些設備并作出調整,但是大部分軟件的變動是在整個系統已經開始運作并已經在生產實際產品的過程中。我曾看見(恩,我的確看見)軟件的變動發生在一個燒得通紅的鋼板從火爐脫落,然后撞擊第一個熱軋機的瞬間,這是這個故事中最讓我心驚肉跳的部分。Gus(化名),一個初級工程師不小心制造了一個離一誤差(注:就是大小差一),導致第一個臺子設置了第二個臺子的輥間距離,第二個臺子設置了第三個臺子的輥間距離,以此類推。這就意味著第一下“咬”得非常的狠,但最糟糕的是第4個臺子,一直在尋找第5個臺子的輥間距但卻沒有找到,然后直接被設置為0。被第3個臺子幾噸重的鋼軋輥穩穩抓牢并推進的10噸重的鋼板,朝著牢牢關閉的第4個臺子猛沖,發出巨大的撞擊聲,然后在我高架操縱臺的座位上就看到一幕鋼鐵碎片橫飛,火花四濺的壯烈場景。美國鋼鐵公司很不高興。

      教訓:這不是TiP,這是一團糟。TiP不是放棄測試需求或是軟件過程需求(一種你可能聽到的比較普遍的錯誤是,一個開發經理或其他人問:如果我們直接在生產中測試,那我們還需要QA做什么?)。TiP需要運用我們一貫擁有的謹慎細微的質量敏感性,但采用一些新的(甚至有些冒險的)策略。我們仍需要成為專業人士,我們仍然是QA。

      僅限VIP進入:曝光控制

      由于被測系統的復雜性,即使你有一個標準的測試預發流程,你仍然需要在交付給最終用戶使用前,保證系統的正確運行?;蛘哂袝r候系統如此復雜,導致生產環境是它將運行的唯一場所(我知道我會因為這個挨罵,但即使這種情況能被技術性地克服,也不一定總是可行的),并且你們(測試和開發團隊)需要看到系統部署到生產環境,而又不希望其它人看見。

      如果你可以控制你的前端,你就能控制這些。比如,其中一個最有力的實現是在亞馬遜,線上測試被植入網站描述框架。開發們只要使用一個簡單的if語句就能顯示或者說使用它,假如用戶是在亞馬遜公司的內部網站的話……非常簡便!有助于新特征的開發,比如亞馬遜視頻點播網站(前身是Unbox)的預訂系統,外部的用戶就沒有辦法看見或者進入。當然,這個系統的缺點是當它準備公開上線的時候,它需要修改一些代碼。關于這個我看到兩個問題:1、代碼本身發生改動的成本。2、代碼改動的風險和是否真正在更改線上代碼之前完成了所有測試的風險(它確實可能只是一個簡單的if語句,但是QA是懷疑一切的,不是嗎?)

      亞馬遜也能開啟或關閉那些沒有代碼改變的“秘密”站點的公共入口,但這種方法的一個問題是它明顯缺乏有力的保護,比如亞馬遜新Unbox服務發布前恥辱的泄密事件就是一個很好的證據。注意那個泄密者曾經在亞馬遜工作過,不要假定你的朋友們會一直友善。

      教訓:在內部和外部之間有分界線的曝光控制是一個非常有用的工具,只是不要指望它能保護高級商業機密材料,除非你原本就想這么做。

      堪薩斯州話機消失的日子

      如果你沒有聽到前面的部分,你可以看這里(當然,在你完成這篇博客的閱讀之后)

      我的公司曾為昂貴的“詢問式”電信設備寫過軟件,做過大量的數據填充材料。使用的一種協議是TL1,這種協議規定為個人輸入/可讀的,但非常有規律,能有程序與它交互。電信設備是非常昂貴的裝置,所以我們希望有權使用實驗裝置甚至偶爾是現場裝置,收集我們查詢的各種反饋,建立模擬器便于我們開發對應的代碼。這就意味著最后的測試必須是線上測試,因為那通常是真正的電信交換機所在的地方。

    原文轉自:http://blogs.msdn.com/b/seliot/archive/2009/12/14/feeling-tipsy-testing-in-production-success-and-horror-stories.aspx

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>