我的面試經歷及思考

現在很多人都已經養成了一個習慣，就是面試前都在網上搜索一些對應公司的基本信息及面試內容，如果有筆試題，一定會第一時間內把那些題都做一遍，然后胸有成竹的去參加面試。我也不例外！既然我都已經查閱過別人的面經，處于禮尚往來考慮，我也需要提供些有用的信息給大家，說說我的這許多次面試經歷～不過我已經不記得別人都問了我哪些問題，這也不是我這次分享的重點，我主要是想結合每家公司面試官的出題思路及與求職者互動過程中做的好的和不好的拿出來跟大家曬一曬，吐槽吐槽。

　　阿里

　　BAT在我心里是高大上的形象，不少求職者趨之若鶩，能進入這樣的名企工作的確是很多人的夢想。這次求職經歷，我也有過幾次與阿里正面交鋒。

　　小微金服

　　14年1月春節前時候，有獵頭幫我推薦了阿里小微金服的高級測試工程師一職。其實當時對于自己的定位就是兩個路線，一個是去BAT這種技術很強的公司做技術，深耕一下自己的技能，另外一個就是去技術不是很強的公司帶團隊。阿里在我眼里就是屬于有很多技術大牛的公司，有一群的優秀且聰明的工程師在構筑著無比復雜的架構。到了那里，一個女同胞面試我，最開始她擔心我最近2年都是在帶團隊，怕我介意高級測試工程師這個崗位，當然我誠心解釋排除了她的顧慮，同時她還擔心我以前多是做頁面功能測試的，對于APP這樣服務端測試比較多的工作不能應付過來，當然我也極力排解她的顧慮。接下來的面試多是問了一些實際測試工作中的場景及設計用例技能，還有就是一些linux命令，以及自動化過程中遇到的困難以及如何解決的，當然這些都是我工作中經常使用到的，自然不在話下，另外還問了一些JAVA的基礎，如繼承，重寫，并當場設計一個student類。而我栽在了JAVA的考察上，細細說來主要原因就是太大意了，我只是直接說了繼承就是類的extend，重寫就是方法的override，并沒有介紹詳細的用法，對于student類只是大概設計了ID，name，class三個成員變量，和成員方法名及參數getId(), setId(int ID),getName(),setName(String name)，方法體并沒有寫出來，構造方法也沒有寫，我覺得太簡單沒有必要再寫了，我跟她講可以直接考察下具體要實現什么樣的student類，她回答我自己想就好。這類開放題目，讓我倒是有些措手不及，畢竟工作中都是為了解決具體某個問題而寫代碼的。后來讓我回去了，連二面機會都沒有給，跟獵頭再三詢問結果，結論是JAVA基礎太差。對于這次面試我的總結就是準備不充分導致了這個結果，如果想順利過關就需要多方面準備才行，不管我們工作中能夠解決多少的實際問題，面試官都只是關心這短短30～60分鐘我們的表現，而且不能大意，要謙虛不能自傲。

　　淘寶

　　年后電話打過來聊了大概半個小時，問了很多我工作中的事情以及自動化測試及性能測試相關的，并且讓我介紹了很多我自認為是亮點的內容，自我感覺聊的還不錯，但是最終結果還是未通過，再次與獵頭溝通沒通過的原因，說是HR系統里寫的就是不合適，未詳細標注，獵頭提示很大可能參考了年前那次的結果，因為兩次面試時間間隔很短，JAVA基礎太差的備注害苦了我。這次面試我的想法是企業方應該多給求職者一點機會，多個角度也許才更能全面的考察一個人，對于一個較長時間沒有面試過的人來說可能真的沒有準備好，也許這次再問我JAVA的問題，我已經準備的不錯了，即便是中間這段時間準備的，至少也能看出一個人善于總結之前的錯誤積極改進，也不失為一個優點，工作中何嘗不是做很多類似的事，遇到不會的不懂的要善于通過學習實踐來提高自己。

　　中麥通信

　　很多人應該都不了解這家公司，那我先簡單介紹下，它是第一批拿到虛擬運營商的公司中其中一家巴士在線的全資子公司，成立于2013年，主要負責虛擬運營商相關業務，一家創業型公司。公司也是想找一個能幫他們帶領好測試團隊確保產品質量的測試經理，因為不是專業的測試人員面試我，而是開發總監跟我聊了很多一些工作中的場景如何來測試的問題，還聊到了一些他們單元測試中的一些難題，如果自動化測試的話如何解決等，還有大數據量如何構造數據及測試等，我的回答應該還如他意，整個面試過程還算比較輕松，然后是VP面試，我主要介紹了我過往的工作內容及業績，對測試相關的問題問的不是很多，然后介紹了很多公司的規劃，特別希望我能加入他們。這不是最讓我印象深刻的，讓我驚訝的是HR面試談薪資時還問了很多測試相關的問題，比如自動化測試，性能測試相關的等等，頓時好生敬仰，從沒有見過如此懂技術的HR，她居然還說她自己不懂這塊的，我當場就說你對這些好了解啊～心想難道是創業型公司在招人時HR也需要先對候選人簡單做個技術溝通？后來因為薪資沒談攏，沒有去這家公司，不過我只能說給的待遇也還不錯，應該比一般的創業公司豐厚些，只不過不符合我的預期。我也非常期望能見到他們的產品，沒準以后買他們的SIM卡和服務呢。

　　亞馬遜

　　也是一家高大上的外企，在網上看到他們能提供的薪酬就讓人無比動心，正好也有一位獵頭聯系我，但是我實在對自己的口語沒有信心，已經4年多沒有講過英語了，不過獵頭說的一句話倒是又勾起了我的極大興趣，只需要能簡單的口語溝通即可，主要是能寫和讀懂英文郵件和資料，這個我當然還是沒有問題的，好吧，欣然接受他的推薦。過了2天，他回復我說亞馬遜那邊的人嫌我們公司的人技術不達標，真心是還沒有開始就被打回原形，也不知道是誰何年何月去面試給亞馬遜留下了這么個印象，但是在我看來，最近兩年我所在的部門人員技能都相對有極大的提高，對此我極力要求獵頭再次與亞馬遜那邊溝通，應該用發展變化的眼光來看待，再者是針對不同的人應該有不同的考核結果，可惜無果。好吧！就算與它沒緣，不過我仍然要討伐一下亞馬遜那邊負責招聘的人，這的確是一個比較極端的做法，哪怕電話面試簡單聊聊也多少對求職者有更客觀的了解，也不至于一竿子打死。

　　京東金融

　　因為招聘的是這個事業部測試負責人，是測試總監/經理崗位，而幫我內推的也是這個崗位。所以面試官都是從別的事業部找來的，也就是說并不是我的直屬上司。一面是個女的，自我介紹之后就問了很多技術上的問題，具體哪些問題我也記不太清楚了，但是唯一讓我記憶深刻的一點，就是她在問我自動化實現上，也許是我并沒有按照她的意思直接寫出自動化代碼，而是把如何設計這個自動化測試的框架說了一遍，然后在闡述過程中她也不停的打斷我，來表達對我的不滿意，說過不止兩三次不管以前你干過什么有多么牛，主要看做現在這個崗位是否適合，我的確承認很多公司都很想找一個有同樣經驗的人不用多少培訓就可以立馬上手，我詢問她們現在有沒有使用什么自動化框架（即便是自己實現的）來輔助測試時，得到的答案竟然是自己寫了兩段代碼來做自動化的并沒有什么框架，我心里暗自想是否只有她一個人在做自動化，也只有她一個人能運行自動化呢？我覺得能寫出幾段代碼并不能判定這個人適合做測試總監/經理，而更適合是對工程師的考察，對測試更宏觀的方面的考察可能顯得更重要。二面是個男的，也聊了大概一個小時，問了很多項目及管理中的問題，還針對某個項目整個測試流程都闡述了一遍，基本上算是把我工作中處理的很多事情都聊了一通，當然中間也夾雜一些技術上的考察，整體感覺還不錯，面試官也非常nice，中途還問我是否需要休息下，他說畢竟面試是非常累的，不過的確我頭都有些暈，這段時間精力是絕對集中。當時面試完時間是差不多5點多了，從第二個面試官透露出來的信息是還需要見一下事業部負責人，我也自己感覺雖然第一面不是很理解，但是二面應該可以扳回一局，就這樣回去等通知了。可遺憾的是，居然面試沒通過，原因是編程能力不行，好吧～我這次是真的無語了。公司我們部門整個自動化工作都是我來主導的，包括框架的設計實現及case的編寫我都有參與，應該寫過的代碼行數不低于1萬行吧～居然落得這個結果！都怪我沒有直接在紙上把代碼寫出來，不過說實話，沒有在eclipse這樣的工具里而是在紙上直接寫代碼倒真的沒有啥感覺不知道如何下手，平時也很少這么干。

　中體彩

　　一家國企，我去面試其實也是想見識見識搞IT的國企特別是搞體育彩票的到底是個什么情況。工作環境很一般，辦公地點裝修的也比較普通，并沒有想象中那么豪華大氣，整個面試過程感覺里面的人還是比較不錯的，因為當時獵頭推薦的是高級測試工程師的崗位，面試前其實我也擔心給不了我期望的薪酬，但是獵頭說薪水應該是沒有問題的，所以不妨一試。在跟HR溝通過程中了解到國企倒還真不錯，有很多福利，過年過節禮品卡自然少不了，高溫補貼啥的都有，只不過自習主席上臺，福利也有所縮水，但相對于其他民營企業還是有優勢的。他們那叫一部二部什么的，跟當時那個部的技術老大聊的時候也談到離職原因，我說是職業發展瓶頸，他提到這里已經有一個測試經理，負責所有測試人員的管理，當然我也可以輔助他，但是如果他在這里的話，我還是沒有機會的，然后我就說一個企業要收攬人才的話，事業/待遇/環境/感情幾個方面都可以下功夫，我并不是特別在乎title什么的，如果待遇上能如我意，也是沒有問題的。不過他提示應該達不到我的要求，然后讓HR跟我談，談的時候我也說了自己最低可以接受的范圍，然后讓我回來2周后需要跟這個部負責人面試，當時這個人在出差不在，就回來等通知了，目前為止都沒有消息，我想是因為待遇問題吧。

　　京東廣告

　　招聘的也是事業部測試負責人，第一面倒是面試官不少，共3個，應該也是其他部門的測試負責人吧。在面試過程中，多是一個人在問，另外2個人問了兩三個問題吧，多是功能測試方面的，自動化測試及其他技能涉及較少，與他們聊的也還挺開心，還有說有笑的，更像是在討論。二面是技術總監，只問了3個問題，具體內容也不再說了，我想說的是三面。前兩輪面完后也回來等HR再約三面，即與事業部VP面談。在HR通知我說三面時還強調了下主要是面試管理方面的技能，讓我準備一下，其實我下來還花了不少時間在總結最近2年來如何進行項目及人員管理的，還專門在紙上列出一個思維導圖，從各個方面分析我是如何來做的，但是到了那里卻沒怎么用上。話說這位VP也是技術出身而且還獲得過多項廣告相關的技術專利，問了自動化框架，不過的確他先只是問的框架，然后工作中如何分工，還讓我自己現場寫代碼設計一個hashtable的接口，我自己寫了3個方法get,put,,containsKey，的確不太理想，自己之前工作中用過三五次hashtable，理解也不是特別深刻，不過好在沒有留白。接下來回去后惡補了一下JAVA集合的知識，為接下來的小米面試做了下鋪墊。幸運的是得到了京東廣告的offer。所以，我想說的是，如果可以的話面試前最好通過各種途徑充分了解下面試官，對于做技術出身的千萬不能大意，沒準就會考考技術水平。

　　小米

　　據說小米今年要擴大規模，從五千人擴到一萬人左右，而我面試的是小米電視。從JD上看不出來職位具體職責，跟其他公司軟件測試經理一樣的要求和工作內容。在小米面試了好幾個人，如果按輪次的話有五輪吧，2輪測試，1輪業務，1輪HR，1輪VP。一二面跟其他公司面試一樣，各個方面都有考察，包括linux命令，JAVA基礎，用例設計及功能測試等等，還現場讓編寫登錄的用例，還好我從各個方面著手考慮的比較全面，并沒有難倒我，但是聊到工作內容時倒是讓我有一點顧慮，主要是招聘一個電視AppStore上App審核組leader，因為有大量第三方App提交給小米，需要人工審核他們的功能，類似于驗收一樣，但是人工工作量巨大想通過自動化方法來替代手工勞動，還比較奇怪的是這個組需要report給產品運營的人。接下來的3次面試都還不錯，然后讓回來等待，還需要跟VP面談。與VP面試時其實更多在考察對于一個我從來沒有做過的工作是否滿懷信心，是否能接受挑戰，能在較強負荷的工作壓力下迎難而上，當然我結合現在工作的實例來說明我一直都在進行新的嘗試和挑戰，并且善于解決沒有遇到過的問題，最終獲得了他的肯定。最近兩年小米的爆發式的發展速度的確讓很多人刮目相看，這里沒有KPI，沒有title，進來的人都是工程師，大家都是干實事的，扁平化的管理和滿懷激情的工作氛圍的確是很多人來小米的原因，只可惜主要還是工作內容原因讓我回絕了他們，如果是公司內純軟件產品的測試可能我能接受，畢竟這是我的職業方向。

　　通過這段時間的面試經歷，也有一些自己的想法：

　　1. 并不是每個面試官都懂得如何進行成功的面試，也許面試經驗豐富的人才懂得如何全方位的考察一個人，否則可能會誤判，或許只招了會面試的人進來，而不是會工作懂得如何解決問題的人。畢竟還是‘千里馬常有，而伯樂不常有’，做一個好伯樂本身就是一大挑戰。所以對于比較高級資深的職位的話，企業真的需要選好面試官方能找到真正的人才。

　　2. 在面試中凡是有女的面試我，都會掛，當然首先也有我自身的原因，除此之外，我要解釋一下我遇到的女面試官的不足：1）她們更注重細節，可能稍不合她們意就會PASS掉；2）她們相對缺乏宏觀管理和分析能力；3）更希望尋找一個來了就能干活的，對于潛力和學習能力等等不會太注重。當然，并不是所有的女面試官都這樣，社會上同樣有很多優秀的女性絲毫不比男性差，這點我毫不否認。

　　3. 準備面試是一件非常不劃算的事情，傷神費時費力，在工作中實踐提高進步會非常的快，可能很多企業都沒有培養一個人的耐心，但是如果一個人只會做做過的事情，對從來沒有做過的事情缺乏分析和解決能力的話，也只能解決當務之急，不能委以重任。一個人的能力不是體現在能處理好以前做過的事情，而是更多的體現在能處理好以前從來沒有遇到過的問題上。如果把面試當成考試一樣來對待，我覺得是一大悲哀！

posted @ 2014-05-08 16:40 順其自然EVO 閱讀(370) | 評論 (0) | 編輯收藏

敏捷方法是怎樣優化設計驗收測試

  正在縮小的世界中的測試軟件　　
      當“上市時間”從幾個月縮短到幾天（甚至幾個小時）的時候，提供軟件的整個方式就會受到影響，測試也同樣會受影響。在采用了敏捷方法的項目中，傳統功能測試鏈正被打亂。這對正在做持續部署的團隊更具挑戰。
　　在敏捷項目中，迭代很短（通常介于1和4周間），帶有小改進和持續集成。因此，每次迭代，我們都需要確保這些改進按照他們預期的方式進行，并執行一些回歸測試。要達到敏捷性測試這個水平需要大量的自動化。項目將其測試100 ％自動化并不罕見。谷歌每分鐘做20+個代碼變化，每天運行約50百萬次測試！
　　但測試執行只是硬幣的一面。現在的問題是，如何以相同的速度和規模去設計和維護這些測試？換句話說，一個有許多小幅增長的迭代的項目如何能夠在整個測試過程保持精簡？

　　早期測試設計

　　如果一個項目團隊必須非常快速地迭代，就很難維護和同步三個傳統存儲庫：需求，代碼和測試。我們過去用來管理他們的需求消失了！測試變得更加重要，流程（迭代或計劃會議期間）中，很早就開始了測試設計。測試是“完成”的定義，同時確定需求及驗收標準的方式。因此，所有利益相關者關于一個成功實施意味著什么達成了共識。這些驗收測試也被用來驅動和聚焦代碼編寫 - 我應該先執行哪個測試？這些原則是驗收測試驅動開發實踐的基礎。

　　所以驗收測試在生產前不再是開發過程的最后一步。反之 - 驗收試驗設計在項目早期就開始了。而且，到目前為止，它已被證明能夠給質量和生產力帶來巨大的好處。
　　業務領域語言設計驗收測試的需要
　　為了按需求規定的速度和規模給早期測試設計提供有效支持并同時增強項目利益相關者之間的溝通，測試人員應該可以構建能被開發人員和業務專家理解的資產。自動化，甚至手工測試用例，通常過于復雜或過于詳細而被錯誤理解。
　　還有就是要保持與測試用例相關的文件，并且毫無疑問，這將引起矛盾。因此，要定義測試場景，測試人員應該使用一種業務領域語言，它：
　　▪可以被（定義業務術語的）業務專家理解
　　▪便于測試編寫和維護（基于語義而不僅僅是文字）
　　▪可被自動轉化用于測試執行
　　這樣一個業務領域的語言一點好處是：它使開發人員所謂的“重構”成為可能。測試不再是純文本，它有了語義，只用一個動作就可以管理和修改大量測試。這意味著使用利于團隊內部交流的業務語言時升級了一百或更多的測試步驟。因此，使用早期測試設計并通過創建一種業務領域語言所寫的測試，你可以將整個項目組和驗收標準的定義對其，并高速度、大規模地進行迭代。

　　測試的執行也是要么用手動執行要么用自動化被簡化了。因為驗收測試基于一種業務領域語言，所以測試步驟是同類的且更容易理解和執行。對于那些想要做自動化的人，將業務領域語言轉化為將被實現的關鍵字也很簡單。有一些工具支持TADD且為設計測試提供一個特定領域語言（DSL）。

     舉例：測試一個閱讀應用
　　
   在這個例子中，我們將使用Zest平臺及其語言來設計測試。我們將同時顯示代碼和編輯器。該編輯器是一種定義業務理念和場景的圖形化方式。
　　現在，讓我們定義一個簡單的場景：“買很多書”。首先，該場景將使用一個要么是“行動”要么是“結果”的步驟的傳統觀念。這是人們通常使用的方式。

編輯器中“買很多書”場景的視圖
　　該場景可以通過引入一個名為“選擇書”的動作詞進行重構。這個概念定義了一個業務動作/術語，確保了分解。就像一個功能，它提供了一個維護單一點，并且可以有一些參數。

所以，現在，該場景可以調用動作詞了。
　　現在，我們要把一個新場景添加到測試功能“取消購物車”中。首先，我們創建一個動作詞來檢查購物車中書的數量。這個動作在新方案中將被使用兩次。
　　然后，我們創建“可被取消的一選項”場景：
　　在此，該平臺已經注意到，下面的步驟序列被用在幾個場景中，即：“買很多書”和“可被取消的一選項。”
　　因此建議創建一個新的動作詞并在2場景中重構以優化你的維護！當被執行（即行動詞“登錄”創建及場景重構）時， “可取消的一選項”場景就變成了：
編輯器中“可撤銷的一選項”場景的視圖
　　這個例子中，我們已經看到了使用一種語言來設計測試的價值。使用動作詞（類似于開發人員的功能）使得設計和維護更加容易，并提供了重構能力。它有助于定義不同項目利益相關者之間的業務術語。
　　我們也看到了，這種業務術語的定義可以在設計，優化和重構場景時通過一個非常先進的方式實現。

posted @ 2014-05-08 16:37 順其自然EVO 閱讀(166) | 評論 (0) | 編輯收藏

一大波平臺來襲，可用性測試怎么破

　手機、PC、網頁、平板……一個產品擁有多個終端/平臺的情況已經非常普遍，面臨大版本時更是所有平臺要同期發布，并且各個平臺之間的連貫體驗也越來越重要，單平臺的可用性測試已經漸漸不能滿足當前的需求，這里就跟大家探討下面對多平臺的可用性測試需要注意的內容。

　　（以下故事純屬為了奠定全文喜劇色彩和夸張手法，和真實產品沒有半毛錢關系。）

　　用戶研究員老王最近遇到了一件煩心事，TA負責的某產品過倆月要發個大版本，瞅了眼項目經理發的周報，六個平臺還要同步發！（領導再也不擔心老王的工作不飽和了）看來各平臺的可用性測試跑不掉了，老王掐指一算：

　　我們這個狂霸酷拽的產品共有6個平臺；

　　這個新版本共有3個新特性和5個基本特性需要測試；

　　各平臺是分開研發的，所以每個特性完成的時間點不一樣；

　　那么項目進度表有可能是以下這樣喪盡天良的：（以下表格純屬虛構）

　　所以：

　　等單一平臺的所有特性開發完成后按平臺測試是來不及的！

　　等單一特性在所有平臺開發完成后按特性測試也是不可能的！

　　這可把老王愁壞了，碩果僅存的幾縷頭發也要被薅（hao一聲）光了。

　　老王不用怕！小天使偷偷告訴你一個秘訣——

　　已經翻了白眼的稍安勿躁，這樣放蕩不羈的前提條件是：

　　1. 平臺多；

　　2. 發布時間集中；

　　3. 特性在不同平臺同質性高。

　　至于好處則是：

　　1. 減少可用性測試的次數；

　　2. 增加驗證解決方案的輪數；

　　3. 預測并避免同類問題在不同平臺重復出現。

　　那么具體執行與常規的可用性測試有什么不同呢：

　　接需求前切記保持底線

　　首先給大家講個小故事：

　　其實只是多問一句的事兒：

上面提到的這種情況也不是不可能發生，接需求前記得保持自己的底線：

　　不能在當前版本落地的緩一緩（下個版本還是未知數，也許整個特性都會被干掉，那么這次的測試就是白費功夫）

　　沒有明顯變化或改進的等一等（如果這個版本只是修復了上個版本的一些細節內容，而大的交互流程和圖標體系沒有變化，并且和上個版本測試出來的可用性問題無關，那么建議不要接，或者利用其他平臺測試的資源順便測試。）

　　對界面完全沒有影響的就算了（有時會和其他產品甚至是硬件合作，如果我們無法影響到其中的界面那么就算有問題也沒法改，這種情況不如不做）

　　保證一個主平臺的基本特性不測漏，其他合理補充

　　雖說這奧義是哪里做完測哪里，但是也不能胡來對吧。

　　通常來說會放到可用性測試里去測試的特性有這么4種：

　　在多平臺的可用性測試中，首先要選定一個主平臺，保證該平臺所有的基本特性不測漏，對于其他平臺，有全新特性做完的平臺優先測，其次是有改進后特性的，但一次測試不要超過3個平臺。這樣是為了讓新特性有更多的試錯驗證機會。

　　重場景、輕任務，同平臺放一起，跨平臺看場景

　　場景，是對角色如何使用基于軟件的產品達到自己目標的簡明描述。任務，在我看來更像是對特性的包裝，而這些都需要在“場景”這個大劇本下才可執行。

　　實際測試時我通常會讓用戶明白TA是誰（通常就是TA本人）現在在哪里（比如家里）要干什么（把手機里的照片存到電腦上），然后看TA如何操作就好。至于TA是不是按照理想的任務順序來操作其實并不重要，重點是TA的目的（或者說是我們設定的目標）是否達到。如果沒有達到目標，觀察TA是在哪些環節出了問題導致失敗即可。

　　至于用戶通過捷徑跳過設定的任務直接達成目標（或者說沒有測到需要測試的特性）的情況，可以在用戶達到目標后再邀請TA通過其他方式嘗試。

　　另外值得注意的是，雖然讓用戶自然地操作很好，但是當平臺較多的時候很可能出現手忙腳亂的情況，所以為了用戶方便還是盡量要把同平臺的任務編排到一起，需要跨平臺的話（比如在電腦上下載了電子書傳到手機上看）那就把它放在使用電腦的任務和使用手機的任務之間作為過渡，如下圖示意。

　　瘋狂鞭笞小伙伴修改問題，反復驗證解決方案

　　測出了好多可用性問題怎么辦？催著改啊！改完才能在下一輪驗證解決方案對不對啊！iOS的特性A這輪出錯了，下輪Android就能測改過以后的特性A啦！還有問題？那繼續改啊！之后還有iPad那輪吶！（見下圖）

　　這里需要重申一下最前面提到的一個大前提——特性在不同平臺同質性高。也就是說當特性A在iOS和Android的界面基本類似的情況下為了節約時間可以用另一個平臺來驗證這個平臺的問題，當然最好還是能在原平臺進行驗證啦。

　　把報告寫給要看的人，及時跟蹤落地結果

　　報告出來以后要讓同事能看懂并且立即消化對吧，所以給不同角色看報告大概是這樣的：

　　給老板看核心問題和主要結論；

　　給產品經理看問題的嚴重性，提供需求優先級的參考；

　　給設計師看具體問題發生的原因，這樣設計師就可以去思考更好的解決方案，而不是粗暴地通過增加功能特性的方式來解決；

　　給開發看哪些問題是屬于bug，可以立即修復；

　　另外，不同平臺的負責人可能是不同的，所以最好把同一個平臺的內容聚合到一起呈現。

　　最后來說說自己維護一個可用性問題追蹤表（如下圖示意）的好：

　　從跟蹤情況看哪些問題是歷史遺留并且還沒有解決的，再發生類似問題就多跟相關同事聊一聊；

　　從特性名稱看哪些任務總是完成得很差，哪些是改了以后越來越差，嗯，還是要找同事聊一聊；

　　從其中一個平臺的問題也可以預估其他平臺在做類似任務的時候可能出錯的地方；

　　方便統計自己的落地率，總結一下經驗教訓；

　　最最好用的一點是——別人問起某平臺某版本的問題時你可以瞬間把同版本不同平臺/不同版本該平臺的所有問題全截給TA看，如果順便能把其他平臺的同樣問題或者該平臺的歷史遺留問題一并解決就太棒了。

　　唔說了這么多不知道對大家有用么~

posted @ 2014-05-08 16:36 順其自然EVO 閱讀(122) | 評論 (0) | 編輯收藏

大話敏捷測試

　敏捷這個話題似乎熱了好多年，隨之也就自然地有了敏捷測試這個術語。

　　說到敏捷，大家一定聽過不少相關的演講，看到不少相關的書籍，不過不管有什么新的技術，新的流程，歸根結底都是遵循著敏捷宣言并以敏捷原則作為根本。就像Scrum開拓了一套敏捷項目管理的框架，XP指導著敏捷開發中的工程實踐一樣，敏捷測試也就是一組指引測試工作在敏捷團隊中的一些最佳實踐。

　　首先，敏捷測試非常強調和多方的合作。在瀑布開發模式下，測試人員一般是根據需求文檔和設計文檔來設計測試用例，然后等功能開發完成，軟件交付到測試人員手上才開始正式的測試工作，這樣對于測試的所有輸入就都是文檔。而敏捷測試讓測試人員在軟件開發的最初就加入團隊，為的就是使測試人員更加地靠近產品本身，對于產品經理的需求和開發人員的設計有深入的理解，甚至能和后續的部署和運維團隊盡早地接觸，了解到產品的全方位。

　　再次，盡早地使產品可以測試起來，越早越好。測試工作不再是軟件開發中的某一個環節，而是時時刻刻貫穿于軟件開發中。實現這一點的基礎就是軟件的可測性，而可測性又包括至少兩點

　　有較為明確的需求指標（這里使用了“較為”兩個字是因為有些非功能上的指標前期可能的確不太明了，但是隨著產品開發的進行，最終還是會慢慢清晰的），這樣才能對測試結果進行判定

　　有適合測試的接口，這樣才能方便的設計和執行測試用例，并能最大規模地發揮測試自動化的優勢

　　之后，使團隊一起加入測試。千萬不要孤軍奮斗，軟件測試是一件極其需要團隊力量的過程，讓策劃/開發/運維甚至是產品經理一起加入。

　　開發需要為自己的代碼負責，單元測試是必不可少的

　　編寫用戶驗收測試用例的時候要邀請策劃和產品經理，避免對于需求的理解錯誤

　　請運維一起加入產品的部署測試，他們有著更多的生產環境的實際操作經驗

　　當然每個角色對于加入的方式可能會不太相同，但是重要的一點就是把所有的測試環節都對團隊成員透明，讓他們知道產品會進行哪些測試，已經進行了哪些測試，當前的測試結果怎么樣。

　　在測試可以跑起來之后，盡量頻繁地測試。說到這個，測試自動化很自然地被提上了日程。注意，這里用的是“測試自動化”，而不是“自動化測試”。個人認為測試自動化不僅僅是把測試用例通過編寫代碼腳本化并通過機器運行起來，而是包含了一套對于測試過程的自動化，包括測試環境的自動部署，測試數據的自動生成，測試腳本的自動執行和測試結果的自動報告等等。好了，回到“頻繁地測試”這個話題，我們需要多頻繁呢？越頻繁越好！

　　每一次的代碼（產品代碼或是測試代碼）提交或是每一次的配置更新都有潛在破壞軟件的可能性，都是需要測試的

　　產品在不同部署環境中的表現往往是不可預料的，盡可能多的對可能的部署環境進行驗證

　　即使部署環境和產品都沒有變化，也需要重復測試。這個可能會有些疑問，既然什么都沒變，已經跑過通過的測試還有必要重復執行嗎？答案是“有必要”

　　· 產品在剛啟動時和運行了一段時間之后的表現是完全不同的，看似重復執行的測試其實已經是運行在不同狀態下的

　　· 測試的執行往往是按照一定順序的，依據“殺蟲劑”原理，系統是會有一定“抵抗力”的，這時可以不采取簡單的重復測試，而是打亂測試順序（雖然測試用例的設計在原則上是獨立的，但是在實際中對于軟件產品的內部狀態變化是不可預知的）

　　上面這些只是敏捷測試個人的一些理解，其中并沒有涉及到具體技術層面的東西，更多的是一種思想層面對于軟件測試的轉變

　　· 軟件測試是軟件開發的一部分

　　· 軟件測試是團隊成員的職責

　　· 軟件測試需要盡早，自動，頻繁的執行

　　也正是因為有了這些需求，TDD/ATDD/CI才會被團隊所接受，慢慢變成了一種標配

posted @ 2014-05-08 16:34 順其自然EVO 閱讀(157) | 評論 (0) | 編輯收藏

如何攻破軟件

　《How to break software》是James A.Whittaker 2000年的一篇有關如何組織帶有明確目標的測試策略的文獻。文章將軟件測試的過程比喻為“攻擊”軟件以發現bug的狩獵過程。目的在于使測試用例的設計變得有章可循，迅速提高軟件測試效率。

　　James A.Whittaker，測試界的權威人物，先后在IBM、Google、Microsoft擔任過顧問、工程總監、架構師等職位，在測試領域著有《How google test software》等著作。

　　文章將“攻擊”軟件的策略分為三個大類：

　　輸入/輸出攻擊

　　數據攻擊

　　運算攻擊

　　每個類型又分為多個小類型，導致特定的有趣的bug。然后以Microsoft Office系列產品為主要對象，以其中真實的

　　bug為例，具體說明每一種攻擊策略是怎樣導致缺陷呈現的。

　　輸入/輸出攻擊

　　所謂的“黑盒測試”，又可以分為以下具體的類型和施行策略。

　　數據攻擊

　　首先要理解數據是如何、在何處建立是必要的。

　　從本質上講，數據的存儲是通過讀取輸入，然后將其存儲在內部或者存儲一些內部計算的結果來實現的。因此，測試正是通過提供輸入和執行計算來實現數據在應用程序中的傳遞。

　　具體分為以下具體的類型和施行策略：

　　運算攻擊

　　總的來說，找bug不外乎幾種大概的思路：1.遍歷一遍輸入，把能出現的結果都覆蓋到；2.通過構造錯誤的輸出來設計輸入并執行輸入，驗證是否bug；3.有相互作用的事務組合測試，包括相互作用的數據、功能等行為。

　　另外，作者提出了兩個更重要的測試思想：

　　1.永遠不要低估了測試時懷揣一個具體目標的作用。太多的測試人員把時間浪費在毫無目的地輸入或者隨機地調用API試圖導致軟件出錯。實行測試意味著制定明確的目標——基于會出錯的點——然后設計測試用例來實踐該目標。這樣，每個測試用例都有目的性并且進度可以被隨時控制。

　　2.測試應該是有趣的。

posted @ 2014-05-08 16:34 順其自然EVO 閱讀(194) | 評論 (0) | 編輯收藏

軟件測試的語境驅動方法

我們屬于有時叫做軟件測試語境驅動學派的一幫人。經過多年（斷斷續續），我們最后開發出一種原則描述，我們相信這種描述反映了這些松散地聚合在一起充當這一派思想領導的人們的共同觀點。

　　本書給出了語境驅動思維的大量例子，并解釋了我們在團建開發中的體會。隨著本書的出版，我們也創建了一個網站，即context-driven-testing.com，以進一步發展這個學派。

　　如果讀者閱讀了以下給出的原則和說明，決定也親自加入這個學派，可訪問context-driven-testing.com并加入這個集體。

　　語境驅動學派的七個基本原則

　　1. 任何實踐的價值都取決于其語境。

　　2. 在特定語境下有好的實踐，但是沒有最佳實踐。

　　3. 在一起工作的人，是所有項目語境的最重要的組成部分。

　　4. 項目以常常不能預測的方式逐漸展開。

　　5. 產品是一種解決方案。如果產品不是解決方案，他就不能發揮作用。

　　6. 好的軟件測試是一種具有挑戰性的智力過程。

　　7. 只有通過判斷和技能，在整個項目團隊中始終進行協作，才能在合適的時間做合適的事，以有效地測試自己的產品。

　　貫徹基本原則的說明

　　●成立測試小組是為了提供與測試有關的服務。測試小組并不開發項目，而是為項目提供服務。

　　●在為開發、質量管理、調試、調查或產品銷售提供服務時，測試是代表項目相關人員實施的。完全不同的測試策略對于這些不同的目標是合適的。

　　●不同的測試小組有不同的任務是很正常的。服務一種任務的核心實踐可能與另一種核心實踐無關或生產率相反。

　　●采用無效的指標是危險的。

　　●任何測試用例的基本價值，在于它提供信息的能力（即減少不確定性的能力）。

　　●所有征兆都會有欺騙性。即使產品看起來通過了測試，但是也很有可能以測試員（或自動化測試程序）沒有監視到的方式失效。

　　●自動化測試并不是自動化的手工測試，把自動化測試作為自動化的人工測試來討論是沒有意義的。

　　●不同類型的測試會暴露不同類型的缺陷——隨著程序變得更穩定，測試應該更具進取性，或應該關注不同的風險。

　　●測試工作產品應該達到滿足項目相關人員有關需求的程度。

　　舉例

　　請考慮兩個項目團隊。一個團隊開發用于飛機的控制軟件。“正確行為”具有高度技術和數學含義，必須遵循FAA制定的規范。團隊成員所做的一切或沒有做的一切，都是從現在起20年時間內的法律訴訟證據。開發團隊成員都遵循崇尚小心、準確、可重復性和反復檢查每個人的工作的工程文化。

　　另一個團隊開發的是在Web上使用的字處理程序。“正確行為”就是把大量Microsoft Word用戶吸引到自己的軟件上。沒有必要遵循的規范要求（只有控制公共棧的要求）。投放市場的時間很重要——從現在起20個月，到時候無論好壞必須拿出產品。開發團隊成員肯定沒有很好的工程文化，如果讀者試圖以第一種文化的普遍方式討論問題，就會使他們認為那是”應該避免出現的損失。“

　　適合第一個項目團隊的測試時間會在第二個項目中失敗。適合第二個項目團隊的實踐對第一個項目團隊就是會受到起訴的失職。

　語境驅動學派的成員

　　如果讀者贊同這些原則，并想加入這個學派，可通過context@satisfice.com與我們聯系。

　　以下一些專著的作者，都贊同這些原則：

　　Cem Kaner

　　James Bach

　　Bret Pettichord

　　Anna S. W. Allison

　　Stale Amland

　　Bernie Berger

　　Jaya R. Carl

　　Ross Collard

　　Christopher Denardis

　　Marge Farrell

　　Erick Griffin

　　Sam Guckenheimer

　　Elisabeth Hendrickson

　　Kathy Iberle

　　Bob Johnson

　　Karen Johnson

　　Mark Johnson

　　Alan A. Jorgensen博士

　　Brian Marick

　　Patrica A. McQuaid博士

　　Alan Myrvold

　　Noel Nyman

　　Pat McGee

　　Johanna Rothman

　　Jane Stepak

　　Paul Szymkowiak

　　Andy Tinkham

　　Steve Tolman

　　--------------------------------------------------------------------------------------------------------------------

　　時勢造英雄，環境的影響不可忽視。語境驅動測試，也是基于這樣的思想。人不是一個線性的器件，不同的人組合在一起，會發生不同的化學反應。不同的團隊，使用的方法也不會完全相同。

posted @ 2014-05-08 16:33 順其自然EVO 閱讀(176) | 評論 (0) | 編輯收藏

易于測試的代碼

軟件IC是人們在討論可復用性和基于組件的開發時最喜歡使用的比喻。意思是軟件組件應該就像集成電路一樣進行組合，這只有在你使用的組件已知是可靠地時候才能行之有效。

　　芯片在設計時就考慮了測試——不只是在工廠，在安裝時，而且也是在部署現場進行測試。更加復雜的芯片和系統可能還擁有完整的Built-In-SelfTest（BIST）特性，用于在內部運行某種基礎級的診斷；或是擁有Test Access Mechanism（TAM），用以提供一種測試裝備，允許外部環境提供激勵，并收集來自芯片的響應。

　　我們可以在軟件中做同樣的事情，與我們的硬件同事一樣，我們也需要從一開始就把可測試性（testability）構建進軟件中，并且在把各個部分連接在一起之前對每個部分進行徹底的測試。

　　單元測試

　　硬件的芯片級測試大致等價于軟件中的單元測試（unit testing）——在隔離狀態下對每個模塊進行測試，目的是檢驗其行為。一旦我們在受控的（甚至是人為的）條件下對模塊進行了徹底的測試，我們就能夠更好地了解模塊在廣闊的世界上將怎樣起反應。

　　軟件的單元測試時對模塊進行演練的代碼。在典型情況下，單元測試將建立某種人工環境，然后調用被測試模塊中的例程。然后，它根據已知的值，或是同一測試先前返回的結果（回歸測試），對返回的結果進行檢查。

　　隨后，當我們把我們的“軟件IC”裝配進完整系統中時，我們將有信心，各個部分都能夠如預期的那樣工作，然后我們可以使用同樣的單元測試設施把系統當做整體進行測試。

　　但是，在我們走那么遠之前，我們需要決定在單元級測試什么，在典型情況下，程序員會隨便把一些數據扔給代碼，就說已經測試過了，應用“按合約設計”后面的思想，我們可以做得好得多。

　　針對合約進行測試

　　我們喜歡把單元測試視為針對合約的測試。我們想要編寫測試用例，確保給定的單元遵守其合約。這將告訴我們兩件事情：代碼是否符合合約，以及合約的含義是否與我們所認為的一樣。我們想要通過廣泛的測試用例與邊界條件，測試模塊是否實現了它允諾的功能。

　　我們為什么要這么費事？最重要的是，我們不想制造“定時炸彈”——呆在周圍不被人注意，卻在項目最后的尷尬時刻爆炸的東西。通過強調針對合約進行測試，我們可以設法盡可能多的避免那些“下游的災難”（downstream disaster）。

　　提示

　　Design to Test 為測試而設計

　　當你設計模塊，或是單個例程時，你應該既設計其合約，也設計測試改合約的代碼。通過設計能夠通過測試，并履行其合約的代碼，你可以仔細地考慮邊界條件和其他非如此不會發現的問題。沒有什么修正錯誤的方法比一開始就避免發生錯誤更好。事實上，通過在你實現代碼之前構建測試，你必須在你確定采用某個接口之前先對它就行試驗。

　　編寫單元測試

　　模塊的單元測試不應被扔在源碼樹的某個遙遠的角落里。他們須放置在方便的地方。對于小型項目，你可以把模塊的單元測試嵌入在模塊自身里。對于更大的項目，我們建議你把每個測試都放進一個子目錄。不管是哪種方法，要記住，如果你不容易找到它，也就不會使用它。

　　通過使測試代碼易于找到，你是在給使用你代碼的開發者提供兩樣無價的資源：

　　1. 一些例子，說明怎樣使用你的模塊的所有功能。

　　2. 用以構建回歸測試，以驗證未來對代碼的任何改動是否正確的一種手段。

　　讓各個類或模塊包含自己的單元測試很方便（但卻并非總是可行）。例如，在Java中，每個類都有自己的main，除了在應用的主類文件里，所有的main例程都可用于運行單元測試，當應用者自身運行時它將被忽略。這樣做的好處是，你交付的代碼仍然含有測試，可用于在現場對問題進行診斷。

　　在C++中，通過使用#ifdef有選擇的編譯單元測試，你可以（在編譯時）獲得同樣的效果。

　　但是只提供單元測試還不夠，你還必須運行它們，并且經常運行它們，如果類偶爾通過了測試，那也是有幫助的。

　使用測試設備

　　因為我們通常會編寫大量測試代碼，并進行大量測試，我們要讓自己的生活容易一點，為項目開發標準的測試設備（testing harness）。前一節給出的main函數是非常簡單的測試裝備，與之相比，我們通常需要更多的功能。

　　測試裝備可以處理一些常用操作，比如記錄狀態，分析輸出是否符合預期的結果，以及選擇和運行測試，裝備可以由GUI驅動，可以用項目的其他部分所用的語言編寫，也可以實現為makefile或Perl腳本的組合。

　　在面向對象語言和環境中，你可以創建一個提供這些常用操作的基類。各個測試可以對其進行繼承，并增加專用的測試代碼。你可以使用Java中的標準名稱約定和反射，動態的創建測試列表。這一技術是遵循DRY原則的好方法——你無需維護可用測試的列表。但是你出發前編寫自己的裝備前，你可以研究一下Kent Beck和Erich Gamma的xUnit。他們已經完成了這項艱苦的工作。

　　不管你決定采用的技術是什么，測試裝備都應該具有以下功能：

　　●用以指定設置與清理（setup and cleanup）的標準途徑。

　　●用以選擇個別或所有可用測試的方法。

　　●分析輸出是否是預期（或意外）結果的手段。

　　●標準化的故障報告形式。

　　測試應該是可以組合的，也就是說，測試可以由子組件的子測試組合到任意深度。通過這一特性，我們可以使用同樣的工具，同樣輕松地測試系統的選定部分或整個系統。

　　構建測試窗口

　　即使是最好的測試集也不大可能找出所有的bug；工作環境的潮濕、溫暖的狀況似乎能把它們從木制品中帶出來。

　　這就意味著，一旦某個軟件部署之后，你常常需要對其進行測試——在現實世界的數據正流過它的血脈時。與電路板或芯片不同，在軟件中我們沒有測試管腳（test pin），但我們可以提供模塊的內部狀態的各種視圖，而又不使用調試器（在產品應用中這可能不方便，或是不可能）。

　　含有跟蹤消息的日志文件就是這樣一種機制。日志消息的格式應該正規、一致，你也許想要自動解析它們，以推斷程序所用的處理時間或邏輯路徑。格式糟糕或不一致的診斷信息就像是一堆“嘔吐物”——它們既難以閱讀，也無法解析。

　　了解運行中的代碼內部狀況的另一種機制是“ 熱鍵”序列。按下特定的鍵組合，就會彈出一個診斷控制窗口，顯示狀態消息等信息。你通常不會想把這樣的熱鍵透露給最終用戶，但這對于客戶服務人員卻非常方便。

　　對于更大、更復雜的服務器代碼，提供其操作的內部視圖的一種漂亮技術是使用內建的web服務器，任何人都可以讓Web瀏覽器指向應用的HTTP端口（通常使用的是非標準端口號，比如8080），并看到內部狀態、日志條目、甚至可能是某種調試控制面板，這聽起來也許難以實現，其實并非如此。你可以找到各種現代語言編寫，可自由獲取、可嵌入的HTTP Web服務器。

　　測試文化

　　你編寫的所有軟件都將進行測試——如果不是由你和你們團隊測試，那就要由最終用戶測試——所以你最好計劃好對其進行徹底的測試，一點預先的準備可以大大降低維護費用、減少客戶服務電話。

　　盡管有著黑客的名稱，Perl社區對單元測試和回歸測試非常認真，Perl的標準模塊安裝過程支持回歸測試（%make test）。在這方面Perl自身并無任何神奇之處，Perl使得比較和分析測試結果都變得更為容易，以確保順應性（compliance）——測試被放在指定的地方，并且有著某種預期的輸出。測試是技術，但更是文化；不管所用語言是什么，我們都可以讓這樣的測試文化慢慢滲入項目中。

posted @ 2014-05-08 16:08 順其自然EVO 閱讀(259) | 評論 (0) | 編輯收藏

Xcode 5 使用 XCTest 做單元測試

　什么是單元測試，請看百度百科單元測試

　　一：在xcode5 之前，我們新建項目時，可以選擇是否集成單元測試；如今在xcode5，我們新建立的項目默認就已經集成了單元測試和ARC；

　　xcode5 之后集成的單元測試框架 XCTest.framework

　　如圖，我們用xcode5 新建立一個名為 StudengManager 的空項目

　　項目新增加框架 XCTest.framework

　　項目新增加組 XXXX項目名Test組

　　新增加 xxxxxTest.m

　　Test.m測試文件沒有 .h文件，并且繼承 XCTestCase 類；

　　項目新建立好之后，我可以用快捷鍵 com + u （或是導航條 --> product --> test）來啟動測試；

　　如圖：出錯了，那是默認的，需要開發者自己實現相應的 - (void)test開關的方法；

　　二：有興趣的可以打開 XCTest.framework 先看一下該框架為我們提供的測試用的api;

　　如下一些基本的api的使用；

　　1:如圖，我們在項目里添加一個Student類，里面包含姓名，年齡、是否是男孩三個屬性

　2：把 Studen引入到 Test.m文件中使用；

- (void)testExample

{

//創建兩個學生對象，并初始化一些屬性；

Student *stu1 = [Student new];

Student *stu2 = [Student new];

Student *stu3 = [Student new];

stu3.isBoy = YES;

//當姓名為nil時，錯誤會提示，并顯示后面的log

XCTAssertNotNil(stu3.name, @"學生3的姓名不應該為空");

}

　　3：XCTAssertTrue和XCTAssertFalse

　　4：XCTAssertEqual使用

　　5：你可以建立自己的測試類，但要繼承 XCTestCase; 并且里面測試方法要是 - (void)test 且以 test開頭的；當沒有錯誤的時候，就會全部變成綠色；

　　6:還有關于 TDD 測試驅動開發，請谷歌之！

posted @ 2014-05-08 16:08 順其自然EVO 閱讀(337) | 評論 (0) | 編輯收藏

輕巧的線程堆棧查看工具Hot Threads

　定位性能問題，尤其是cpu使用率過高時，經常需要查找cpu消耗較高的線程，然后查看其堆棧，從而進入代碼定位問題。

　　該場景下， jstack+top是一種非常經典的方式。

　　jstack+top

　　jstack+top的一般套路：

　　1、top -H 查看cpu占用較高的線程，記錄十進制的線程id

　　2、jstack 將線程信息dump到文件中，在文件中根據線程id查找該線程的堆棧。注意，jstack輸出中線程id是16進制的，這里要做一次進制轉換。

　　3、研究這個線程的堆棧

　　jstack+top方法的不足：

　　1、麻煩。由于top工具輸出是實時變化的，一般需要抓多次，重復下來，上述過程更顯繁瑣。

　　2、線程狀態時刻變動，top -H時看到一個線程的cpu占用率較高，等到jstack 時可能已經處于sleep狀態，因此上述操作需要較高的APM

　　有什么辦法能省卻這些麻煩 —— 能在看到線程堆棧的時候，直接看到他們各自的cpu占用率呢？ —— Hot Threads 可以！

　　Hot Threads

　　Hot Threads是一個小巧的開源工具，使用十分容易：

　　1、下載jar包，扔到服務器上

　　2、執行java -jar HotThread.jar [pid] 即可，pid是被測的進程號。使用中注意填對路徑即可。

　　Hot Threads的輸出：

　　執行完上述指令后，Hot Threads會在很短時間內，重復查詢10次線程堆棧信息（調用sun.management.ThreadImpl.getThreadInfo方法），統計平均cpu占用最高的3個線程，打印線程堆棧，并顯示cpu占用率。

106.3% CPU Usage by Thread 'Swing-Shell'

10/10 snapshots sharing following 10 elements

sun.awt.shell.Win32ShellFolder2.getAttributes0(Native Method)

sun.awt.shell.Win32ShellFolder2.access$600(Unknown Source)

sun.awt.shell.Win32ShellFolder2$6.call(Unknown Source)

java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

java.util.concurrent.FutureTask.run(Unknown Source)

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Unknown Source)

java.lang.Thread.run(Unknown Source)

1.6% CPU Usage by Thread 'RMI TCP Connection(9)-172.30.41.210'

10/10 snapshots sharing following 32 elements

sun.management.ThreadImpl.getThreadInfo0(Native Method)

sun.management.ThreadImpl.getThreadInfo(Unknown Source)

sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)

sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

java.lang.reflect.Method.invoke(Unknown Source)

com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(Unknown Source)

com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(Unknown Source)

com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)

com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source)

com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source)

javax.management.StandardMBean.invoke(Unknown Source)

com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source)

com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)

javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)

javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source)

javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source)

javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source)

javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source)

sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)

sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

java.lang.reflect.Method.invoke(Unknown Source)

sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)

sun.rmi.transport.Transport$1.run(Unknown Source)

java.security.AccessController.doPrivileged(Native Method)

sun.rmi.transport.Transport.serviceCall(Unknown Source)

sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)

sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)

sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

java.lang.Thread.run(Unknown Source)

0.0% CPU Usage by Thread 'Reference Handler'

10/10 snapshots sharing following 3 elements

java.lang.Object.wait(Native Method)

java.lang.Object.wait(Object.java:485)

java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)

　　上圖中，每個線程的能看到 10/10 標記。 n / m 意味著m次統計中，有n次都是該排名。

　　Hot Threads使用中的問題和解決方法：

　　直接執行java -jar HotThread.jar [pid]可能會報錯，此時可以換一種啟動方式：

　　java -classpath "/opt/jdk1.6/lib/tools.jar:HotThread.jar" hotthread.Main [pid]

　　其中 /opt/jdk1.6/lib/tools.jar 是服務器上jdk tools包的完整路徑，hotthread.Main 是Hot Threads程序的入口。

　　Hot Threads的不足：

　　使用中發現，Hot Threads自身的cpu開銷比較高，有時候統計顯示cpu使用率第一的線程，在執行的是獲取線程信息的操作，該條堆棧對分析問題無效。

　　2723.0% CPU Usage by Thread 'RMI TCP Connection(4)-192.168.164.87'

　　6/10 snapshots sharing following 33 elements

　　sun.management.ThreadImpl.getThreadInfo1(Native Method)

　　sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:154)

　　sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

　　sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

　　總結：

　　Hot Threads使用快速輕巧，在需要使用jstack + top的場合，都可以嘗試代替比較繁瑣的jstack + top。

posted @ 2014-05-08 16:07 順其自然EVO 閱讀(1261) | 評論 (0) | 編輯收藏

基于模型的測試用例設計（1）

介紹
　　測試設計是測試過程中最重要的部分之一。一個好的測試用例不僅要為被測系統（ SUT ）提供一些輸入，還要驗證系統是否如預期進行。也就是說，它有助于確認利益相關者要求得以實現。但測試設計可以做的遠不止這些。理想情況下，測試設計有助于溝通兩方對這些需求的理解，驗證他們能被正確實施，并引發對利益相關者可能增加的更大價值的討論。
　　基于模型的測試（MBT）（下文都簡稱為：基模測試）是一種技術，有時被標榜為“自動化測試設計”。雖然一定程度上這并沒有錯，但它或許會給人以錯誤的印象。基模測試工具從一個由用戶指定的測試模型生成測試用例。沒有測試模型，該工具就無法生成任何測試用例。沒有好的測試模型，該工具就無法生成好的測試用例。因此，基模測試里，任務從測試設計變成了測試模型設計。不是設計單個測試集，我們設計了一個用于生成任何數量的測試用例的測試模型。
　　例子
　　為了給這個概念提供一個具體的理解，首先我們舉一個簡單的例子。這里所說的例子使用OSMO Tester MBT生成器的符號，它基于Java編程語言。這種情況下，測試模型是使用標準的Java編程語言結構編寫的，但卻被設計成被另一個稱作測試生成器的程序以不同的方式執行，以生成測試用例。有時候，這種模型被稱為模型程序。
　　圖1舉了一個簡化電信系統（其中多個移動終端被連接（注冊）到潛在多個服務器之一上，彼此相互調用）的這種符號的例子。
　　其他類似工具用于各種其他平臺，比如Python （PyModel）和．NET （Spec Explorer， NModel）。其他基于Java的工具和符號，包括ModelJUnit和Conformiq Designer。許多工具也定義了自己的建模語言，并提供一種方法將模型以不同的方式進行可視化。
　　根據用戶的喜好，可以選擇不同的工具提供一個熟悉的工作環境以及不同的算法和不同的特征等。
　　[BINDER]中可找到一個MBT工具列表。　

圖1.模型程序示例

　　注意，圖1中的試驗模型被稍微簡化以提供一個測試模型中的一些核心要素的例子。測試這樣一個系統的真實模型將包含更多步驟，動作和檢查，以及更多的規定。例如，我們需要來啟動和終止調動的步驟，注銷終端步驟，移動它們的網絡的步驟，啟動數據傳輸不同類型的步驟，等等更多。
　　至于這種模型中的規定，我們應該保持終端列能有效調用，消息列可以發送和接收，并保證一切有效數據傳輸。并且應在測試先知中用類似于圖1中檢查注冊終端的方式去再次堅持這項新規定。本文的其余部分將把示例模型引用為一個擴展版本。一個測試生成器可采取不同的方法從一個測試模型生成測試用例。對于OSMO Tester生成器及圖1所示測試模型，該模型可能如[ ACM ]所述那樣被最直觀地描述為一系列規則和動作。該模型定義了一組可以在被測系統上進行的動作（在OSMO Tester標記中用作@TestStep的一部分）。當這些動作中的每一個都被允許時，一組規則（OSMO Tester標記中的@Guard）就定義了。規則允許的話，生成器就以不同的方式組合這些動作以生成測試用例。整個測試模型可以被視作用來描述大量的可能測試用例集。隨后測試生成器從（使用一些由用戶定義的覆蓋準則的）這個模型去生成測試用例。可用標準的變化取決于所使用的工具，但一些例子包含了在模型中覆蓋用戶指定要求（手動標記的特定部分或路徑），覆蓋動作組合，并覆蓋不同動作的各種數據值。(可能已被用來為我們的示例模型指導生成器的)覆蓋準則的一些例子包括：注冊終端的數量，調用終端的數量，注冊卻自由（不處于調用狀態）的終端的數量，及動作結果配對。例如，它可以被定義為對將“零”，“一”和“多”類別都覆蓋到終端類型數中的每一個很感興趣。動作覆蓋可以與這些數值中的一些進一步配對，以激勵生成器來生成步驟，諸如注銷一個調用終端和注銷一個不同配置下的非調用終端。有了更嚴格/松散的覆蓋目標，以及從自由度變為在測試用例中添加隨機性，那么生成機就可以被用來生成一組更小/更大的測試用例。
　　圖2是一個（含有圖1模型中的一個測試生成流程的四個不同點的）例子。在點一（ 1 ）中，模型程序被5個未注冊終端初始化了。在點二（2 ）中，生成由幾個步驟推進，且三個終端已被注冊。在點三（ 3 ）中，幾個步驟再次被通過且兩個注冊終端有了有效調用（兩者間的單獨調用）。在點四（ 4 ）中，兩個以前未注冊的終端已經被注冊了，前面調用的一部分已經退出，已用兩個終端建了一個新的調用。

圖2.測試生成流程示例

　　它真正測試哪些東西呢？
　　測試生成的一個常見問題是：它真正測試什么呢？如果我們只是無休止地生成測試數據或測試步驟卻對結果的正確性一無所知，那還有什么意義呢？在基模測試中，測試模型也可以用來檢查測試用例。圖1中這是由模型中@Post注釋的方法舉例說明的。生成器在所有的測試步驟兩兩間（后）執行這個過程，以證明被測系統的情況與測試模型的情況一致。例如，在圖2的點二（ 2 ）中，它會檢查是否測試模型中被標記為注冊的三個終端在被測系統中也都處于相同情況。它還要檢查其他兩個沒有被注冊，而且他們都沒有正在進行有效調用。
　　類似地，更具體的檢查可以嵌入到任何可在其中獲得一些具體結果的行動中去。
　　如果需要的話，這些檢查可以是不同粒度的，且可以在按量進行，因為不像手工腳本，他們不需要手工編寫每個測試用例的每一步，卻可以由測試生成器進行，時間間隔與時間長短都不限。
　　當已經創建了一個測試模型，測試生成器就用來從這些模型生成測試用例。除了用指定的覆蓋準則為指導從整體模型生成測試，很多MBT工具還提供了一種手段來指導生成器用各種形式的用戶定義場景去關注特定部分。例如，有了（有調用等的）擴展示例模型，我們或許還想從某個角度專注分析管理終端注冊的網絡服務器。要做到這一點，用戶可以創建一個場景，確保只有測試步驟與該場景（如注冊和注銷）相關聯。
　　工具的具體場景定義語言，可以用來建立這樣的場景。要建一個特定測試配置，測試模式可用指定終端實例被參數化。
　　圖3說明了為我們只允許注冊和注銷步驟的示例模型建立一個場景，且每個步驟都必須在每個生成的測試用例中出現至少兩次。
　　更真實的例子會包括更多步驟，更多部分，并且可能還包括用以驅動SUT到場景起點的啟動腳本。
　　這樣一個場景甚至可以用來定義一個特定動作序列，該序列將被用作一個啟動腳本以生成一個類似于手工編寫測試用例的純手工特定測試用例，而不是當模型和其他生成的測試用例一樣變化時將被更新。

　　MBT的優點
　　基模測試的優點很多。相對于手動設計（編寫）單個測試用例，建立測試模型意味著有必要考慮和確定被測系統的整體行為。根據我們的經驗，反之這促使了組織間的交流以便把要求建立這樣一個模型的各方都匯集起來，既有利于協作又促進共同理解。
　　當從一個單一的模型生成大量測試用例時，維護也被簡化了，而且更新模型一次并重新運行生成器會可以立刻更新所有測試用例，而不要單獨重新運行幾百個測試用例。
　　一個精心設計的測試模型表現出了作為一個整體的被測系統的被選方面。被允許和支持的測試值而不是單個測試值的范圍應該在測試模型中被發現并表示。不利用測試（模型）設計師把開發人員和領域專家聚到一起是不可能。也許基模測試應用中通常觀察到的最大的好處是：建設和共享對系統的限制和功能的明確理解，并把所有的假設都列到表格中。
　　當這種理解被記錄到一個測試模型中，某種程度上它就成了一個可執行的規范，因為它可以被用來生成測試用例以實施。然后，不斷的測試用例將驗證被記錄的理解也與實施一致。如果不是這樣，就有待達成一個新的共同的理解，細化的模型，或不變的實施。
　　當然，該測試模型不能充分地描述該被測系統的所有可能的行為，或者它會變得和實現本身一樣復雜甚至更復雜。因此，需要為建模內容選擇一個合適的范圍，為測試模型選擇一個相當高的抽象級別。測試模型的設計需要把重點放在系統的核心部分，該核心部分被視為對嚴格的測試和驗證最重要。這個變化要跨幾個系統，例如，安全關鍵系統可能比不太重要的應用包含了更詳細的內容。因為基模測試過程不僅提供了所生成的測試用例，而且還有對系統規范和功能的嚴格審查，這個審查被要求用來生成測試模型。我們發現這對一個高層次的系統概述和核心關鍵要素的詳細研究特別有用。
　　從測試生成的角度來看，基模測試的主要好處在于它的自動模型探索能力且在探索測試模型中不挑測試生成器。根據我們的經驗，一個領域（測試）專家要查看系統并對它是如何工作的做出某些內在假設很簡單，凸顯一些東西，在手動設計測試用例中重復這些假設。手工操作也很昂貴，在各種不同的開發迭代中很少有時間或資源來廣泛測試一大組不同的選項，或者保證一個大堆測試得以審查和更新。
　　使用測試模型為基礎的測試生成器的限制較少。有一個好的測試模型，該工具就可以結合不同的模型覆蓋準則探索不同場景并把隨機模型覆蓋融合進去，就避免了一些專業偏差還擴大了探索選項集合。自然，該工具無法避免模型內的偏差，但是當幾位專家一起進行模型工作（甚至部分，如審查）時，模型具有巨大偏差的可能性就小了，工具將更加不知疲倦更徹底地探索模型。在現有計算能力和測試執行時間內，它可以生成并執行大量測試用例而不會厭倦，并在每次迭代中重復同樣的過程，只需更新單個測試模型就行。
　　許多關于使用基模測試的案例研究已經發表，也許這其中最廣泛的就是微軟協議文檔工作[ ACM ] 。微軟研究表明：把所有元素（包括學習曲線等）考慮在內時使用基模測試對比手工腳本有42％的利益。它還強調了許多我們所觀察到的接下來將要討論的問題。
　　采用需求及潛在問題
　　如果基模測試這么棒，為什么我們不一直用它呢？因為基模測試的初始成本較高，需要多樣化的技能，它的利益卻難以衡量。初始成本用于獲取技能，學習測試建模的思維模式，并創建測試模型。無法證明自己的系統和域的好處的話，這樣的初始成本很難被接受，如果所有人至今為止都一直手寫測試，就很容易安于現狀而不會為組織去嘗試不同的和未知的事物。
　　創建良好的測試模型需要良好的編程技巧（及一般的軟件工程技能），測試專業知識，建模專業知識和領域專業知識。這是一個多樣化的技能組合，很難靠單個專家獲得。而當有這樣的專家時，管理層往往快速將他們分配定位成為一個開發而不是測試。同樣，管理層基本不會提供各種昂貴的資源（如領域專家，軟件開發人員）用于和軟件測試的筒倉相關的活動，即使他們需要成功的測試活動。從模型設計角度來看，測試模型也并不是一個傳統的順序計算機程序，而是指導測試生成器的一個規則和行動的集合，它本身與傳統的順序程序設計有點不同。
　　一般情況下，當開始進行評估，（可能的話）采用基模測試方法的時候，或許最大的障礙就是需要采用一個完全不同類型的思維模式。有必要把重點放在考慮SUT的整體功能和目的或者它所選擇的一部分上，而不要獨自想著單用場景和單個測試用例。這需要與組織中的其他專家密切合作，這就可能需要對一般的工作實踐稍作改變。
　　這也強調了關于計算優點的問題。如果管理被用來測量如被寫測試用例的數量之類的東西，他們要么就看不到測試用例（只有一個測試模型）要么就是一大堆測試用例（所有生成的）。 [ GRAHAM ]中已對該問題及其可能結果做了詳細說明，[ GRAHAM ]中測試人員最初惡評如潮，后來因為已觀察到的影響而被承認。還有，最初獲得用該工具生成測試用例的啟動成本會顯得使用這種規格沒有任何價值。然而，它可以是建立共同理解并將之記錄在一個可執行的規范（測試模型）中的過程中最有用的部分。正如在任何自動化測試工作（或任何其他工作）中，管理支持，溝通和理解都是非常重要的。
　　該方法和測試生成結果的有效性取決于設計的測試模型的質量。沒有一個高質量的模型，就沒有測試生成可以生產好測試。因此，投入足夠精力去產生好模型并和其他專家一起檢驗它很重要。
　　生成一大組測試用例也能生出一大組需要進行分析的結果。根據我們的經驗，當考慮實施基模測試時，許多人通常認為這就是一個潛在的問題。然而，實踐中，我們已經觀察到：這問題不大，因為測試生成基本是使用某種形式的場景或（對系統具體部分分析關注的）專注模式指導的。然而，模型設計仍應仔細考慮諸如有趣元素有哪些以及它們從所有可能輸入到測試的組合，所以測試生成的重點應放在最有用的方面。至于結果分析，積極地說，當更多的精力可以從手動復制測試腳本中被轉移到分析結果時，這就可以使工作更有趣而不那么單調乏味。總之，測試自動化應該一層層往上建。
　　有效實施基模測試需要將之建于一個好的基礎的測試自動化平臺之上。如果它無法寫出可以自動化執行的測試腳本，那么繼續進行基模測試去產生這樣的腳本就毫無意義。建立基礎的測試自動化需要良好的水平，這個水平上，基模測試過程可作為一個額外工具來提高總體質量。例如，如自動控制SUT的GUI進行測試一類的事，應該在測試一個基于GUI的應用程序時就得到解決。
　　過程
　　使用基模測試的過程可以用四個簡單的步驟描述為一個迭代過程，圖3所示。開始時，我們通常為系統所選的小一部分創建一個最初的測試模型。這使我們能夠學習基本工具和框架，并看看他們是如何連接以形成整個測試環境并在該環境中定位基模測試工具。

圖4.過程模型設計

　　一旦擁有了測試模型的工作版本，我們就用它來生成并執行測試用例。生成的測試用例的執行可以在所謂的“在線基模測試”中與他們的生成進行交錯，或在所謂的“離線基模測試”中的一個單獨的階段中完成。這就很快地給我們提供了對模型情況和對當前模型設計中被測系統的那些部分的反饋。
　　當我們已經生成并執行測試用例時，我們分析出被測系統上及測試模型中錯誤的結果。
　　在令人滿意的水平上，我們開始一步步地擴展模型并添加更多功能。這意味著我們要從頭重復這些步驟及這個過程，直到在我們覺得我們已得到了一個描述有趣元素的合適水平上的測試模型。
　　一些測試模型可以用來設計系統的不同部分。測試場景被用來指導測試生成，或者它可以使用不同的模型和生成器配置去重點關注不同的區域和觀點。
　　我們采用的一種做法是幫助合作伙伴開始使用開源工具理解這個概念，看到好處，并學習技術。開源工具也有適應特定需求和環境的優點。一旦基本技術，及其實施和效益被更好的理解了，就可以選取不同的前進道路，包括轉用（從廣泛付費支持和大規模開發先進算法的資源獲益的，如Spec Explorer和Conformiq Designer的）商業工具這個選擇。然而，在許多情況下，我們早已經看到了開源選項提供的不錯利益。
　　可以運用基模測試的一個好地方是有很多變量和很多（需要進行測試的）交互的地方。一旦我們意識到把這個手動縮放到要求的復雜度和質量水平很昂貴的時候，基模測試就是一個值得考慮的好技術。另一個不錯的地方是安全性軟件，在這種軟件中必須完全相信一個好的幾乎無錯的解決方案已被建成。
　　結論
　　基模測試可能聽起來像一個很酷但卻嚇人的技術，很難上手。然而，經過一些初步學習之后，它并不比常規測試和測試自動化更復雜。我們一般采取的做法是建議一開始（最好是在熟悉這個概念的人的幫助下讓對該方法及其潛力超振奮的人）把它用在一個較小的試點項目中。我們通常以現有的測試自動化和測試腳本為出發點，以這些為基礎一次一小部分地開始建立測試模型。至于抽象層，一個好的起點可以是：（通過利用現有的SUT的API去定義可能采取的行動或關注可以觀察到很多變化且很難測量手動測試的地方，在該系統復雜／易出故障的部分或在核心關鍵功能上，構建一個促進共同理解的高層次的總體模型中的）任何東西。
作者介紹：
　　TeemuKanstrén是一名資深科學家，目前在芬蘭VTT技術研究中心工作，他還是多倫多大學的一名客座博士后。他的工作涉及：以改進行業現狀，和生產實際有用的解決方案并幫助行業伙伴接受采納它們為目的的自動化測試領域的研究和開發。他軟件行業工作了好幾年，已幫助眾多合作伙伴開發和采用以基于模型的測試技術為基礎的測試自動化解決方案。他是開源的基于模型的測試工具OSMO Tester的主要創造者。2010年他獲得了芬蘭大學測試自動化和基于模型的測試的博士學位。

posted @ 2014-05-08 16:02 順其自然EVO 閱讀(704) | 評論 (0) | 編輯收藏

僅列出標題

qileilove

我的面試經歷及思考

敏捷方法是怎樣優化設計驗收測試

一大波平臺來襲，可用性測試怎么破

大話敏捷測試

如何攻破軟件

軟件測試的語境驅動方法

易于測試的代碼

Xcode 5 使用 XCTest 做單元測試

輕巧的線程堆棧查看工具Hot Threads

基于模型的測試用例設計（1）

導航

統計

常用鏈接

留言簿(55)

隨筆分類

隨筆檔案

文章分類

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜