單元測試的藝術-單元測試基礎

單元測試

一個單元代表的是系統中的工作單元或是一個使用案例
被測試的系統(System Under Test)我們稱做SUT或者Class Unit Test(CUT)
一個單元測試是一段程式呼叫一個工作單元,並驗證工作單元的一個具體最終結果。如果對這個最終結果的假設是錯誤的,那單元測試就失敗了。一個單元測試的範圍,可以小到一個方法,大到多個類別。

優秀單元測試的特質

  • 自動化,可被重覆執行的
  • 很容易被實現
  • 非臨時性的
  • 任何人都可以按鈕執行他
  • 執行速度快
  • 執行結果每次都是一致的
  • 能完全掌控被測試的單元
  • 完全被隔離的
  • 若執行失敗會有清楚的原因

整合測試

整合測試是一個有順序的測試過程,將軟硬體相結合並進行測試直到整個系統被整合在一起。也就是這個測試對被測試的單元並沒有完全的控制,而是使用該單元一個或多個真實依賴的相依物件,例如:時間,網路,資料庫,執行緒,亂數產生器等等。

一個單元測試通常包含了三個行為

  • 準備(Arrange):物件,建立物件,進行必要的設定
  • 操作(Act): 物件
  • 驗證(Asset): 某件事符合預期

Assert類別

  • Assert.True: 驗證一個布林條件,見Assert.False
  • Assert.AreEqual: 驗證傳回的值應相同
  • Assert.AreSame: 驗證兩個參數應指向同一個物件

使用參數來測試


使用TestCase標籤

Setup和tesrdown

系統思考Full Version

這篇文章為筆者參加這門課程的課後心得:Systems Thinking: Full Version

Albert Einstein曾說過:『We can’t solve problems by using the same kind of thinking we used when we created them.
意思就是,不要想用相同的方式,去解決過去解決不了的問題。

有一個研究指出,老鼠平時會喜歡走固定的路去找食物,但如果他發現走這條路無法再取得食物,就會很快的改變找食物的路徑。
但很奇怪的是,人在遇到解決不了的問題時,卻時常會下意識的,使用他最熟悉最擅長的方式去試圖解決問題。
而系統思考就是在幫助我們在尋找問題根源時,能夠用更系統性的方式去思考,避免使用下意識的習慣去解決問題。

何為系統

系統思考實用手冊的定義是:各個組成部份彼此發生互動,而以整體的形式存在,並發揮功能的個體
第五項修練:系統是你所感覺到的整體,系統中的元素彼此糾結,因為元素會長時間不斷的相互影響,並且朝著共同的目標運作

系統的結構包括:

  • 元素:有形或無形的事物,如城市的房價、成交量、餘屋量等…
  • 連結:把元素整合在一起的關係,如房屋成交量上升導致庫存量下降。
  • 目標:人類系統的目標或者非人類系統的功能。如控制房價在合理的水準而維持社會穩定與經濟繁榮


從上圖可了解,系統思考絕非一個人能夠做到,一定要有非常多的角色參與在其中,要有共同的了解(share understanding)
系統思考有助於我們發現問題的根本原因,看到多種可能性,從而讓我們更好的管理、適應複雜性的挑戰,把握新的機會。

什麼時候適合使用系統思考

  • 重覆發生的事情:如果是單次的事件較不適合用來做系統思考,主要目的是解決現有存在的問題
  • 複雜且動態變化的事
  • 需要策略性思考,去找到一個槓桿點來改善問題
  • 可以做假設分析,會有什麼副作用,可能發生什麼事,未來什麼可能會出錯

通常一件事情我們可以看到的是事件的表象,而隱藏在表象下的還有行為型態(patterns)、結構(structure)、心智模式(memtal model),而系統思考主要是針對system structure的部份。
(一)事件:冰山露出水面的部份通常讓人關心注目:「發生什麼狀況?」,明顯而具體的事件會引人注意,因而忽視了更宏觀的圖像。
(二)型態/趨勢:當我們心想「繼續如此,會怎麼樣?」時,就開始要看到更大的圖像了。為了找到答案,因此必須更深入水中,往深層探測。
(三)系統結構:往下探尋:「造成這些型態或趨勢背後的因素是什麼?有何關聯?」改變結構就會影響型態的變化,進而產生不同的行為,因此結構會影響行為。=>這邊就是我們系統思考主要要探討的部份
(四)心智模式:即「我們習以為常的思考方式」,人類系統結構尚包括許多影響我們做決定的因素,不同的決定會產生不同的系統結構。

心智階梯理論

相關介紹請見這篇文章:TED-Ed:重新認識「思考」— 推論階梯

這邊是在探討我們在思考問題時的流程,首先我們會先看到些什麼,然後過濾資料、解碼資料、假設問題原因、用這個原因來解釋問題、並做出解決問題的解決方案並採取行動。並且人們會在每一次的思考的第六個階段建立起信念,影響著下次我們在第二階段挑選資料的偏好,逐漸建立起每個人獨有的價值觀及思考路徑。因此會有一個箭頭再次的指向過濾資料的地方。

系統思考工具

  • BOT: 行為趨勢圖,隨時間變化=>一個現象
  • CLD:循環圖
  • SFD:存貨圖

參考資料

鳳凰專案:看IT部門如何讓公司從谷底翻身的傳奇故事

這本書算是一本故事書,也因為是以故事的型態去描述一間公司如何從谷底翻身,讀者會更能夠明白『管理』對於一間公司有多麼重要。
也能從故事裡面直接理解書中所闡述的管理方式在實際情況是怎樣的去運用,在運用時也不會是直接的一帆風順,而是有重重的考驗並且需要高層的全力支持與理解。
我覺得此本書是管理相關書籍中相當值得一看的書。

因為故事情節用簡述的,就沒辦法讓讀者感受書中情境,因此本文主要為筆者自己讀後的筆記
主要紀錄我認為書中很重要的管理方法和管理思維,書內的附錄也有此書管理思維的整理。

有關故事內容,想了解的話建議自己去買書來看。

Work in process控制

在這邊他們使用工廠管理來比喻我們在開發專案的狀況。

對工廠管理而言,在生產線會盡量的去避免讓工廠內同時有過多的在製品,也就是所謂庫存。
對開發專案來說,在製品指的是開發中但是尚未開發完成的功能,還無法帶給公司收益,也是要極力去減少的。

在生產線上,一定會有處理效率最差的點,我們稱為瓶頸點(或稱約束點),創造約束理論的艾利高德拉特告訴我們,在瓶頸以外任何地方做的改進都是假像
的確,在瓶頸點之後做的任何改進都是徒勞無功的,因為只能乾等瓶頸把工作送過來,而在瓶頸點之前做的任何改進只會導致瓶頸處堆積更多庫存。

因此,在開發專案時,要了解公司的瓶頸點在那,是什麼地方讓最多的專案在等待這個資源而讓需求被卡住無法繼續進行。
以鳳凰專案而言,因為過多的核心資訊被掌握在一個天才員工布倫特手中,只有他知道怎麼處理,導至這個員工每天都必須處理非常多的事也有非常多的事在等待這一個資源。

下圖表示當一個越忙錄的資源,其他資源想等待這個資源的時間會越來越高

因此改善這個狀況,第一步就是要先釐清約束點所在,第二步就是充分利用約束點

以此書案例來說,約束點是天才員工布倫特,那他們首先做的就是保護這個約束點,不讓大家直接指使這個約束點去做他們認為重要的事,他們安排了一位專門的人員來安排這位約束點的工作內容,避免大家一直想私自去使喚他做事。接著他們要讓約束點的時間不被浪費,確認約束點永遠不會因為要遷就其他資源而枯等。再來他們將布倫特的工作標準化,讓更多其他的人也可以去接手做布倫特正在做的事,也就是提升約束點的產出。

總之,我們要記得任何對非約束點的改善都只是鏡花水月

三步工作法

  • 第一步工作法

    幫助我們理解如何建立快速的工作流,讓工作順暢地從開發部移動到IT運維部,因為那正是公司與客戶之間的銜接。

    這邊需要去了解公司的價值點,相較於把更多的工作投入系統,將不需要的工作從系統中剃除甚至更為重要,讓資訊部門能夠很快速的產出最精簡可用的有價值的系統,並且獲得反饋。為此,我們需要知道,與達成企業目標息息相關的東西是什麼,不論是專案,運營,戰略,合規,安全性等,通通有可能(請見下方的訂定組織目標)。

  • 第二步工作法

    告訴我們如何縮短及增強回饋循環,因而能夠從源頭開始解決品質問題,並且避免重工。在這邊我們也必須設法去根除計劃外工作的最大來源。

    所有計劃中的工作,在執行工作前,必須要分門別類地列出完成工作所需的一切先決條件:例如說,筆電型號,使用者資訊的規格,軟體及需要的授權,以及他們的組態,版本資訊,資安要求,處理能力和連續性需求等。

    也就是建構資源清單,亦是物料清單,以及需要的工作中心與生產途程,一旦備妥,加上工單和你的資源,就可以釐清產能及需求為何,並弄清楚可否接受為新的工作,並實際為它進行排程。

    第二步工作法的關鍵部份是以視覺化的方式呈現等待時間,那樣就能知道你的工作正在某人的佇列中排隊好幾天,或者是工作必須往後退,因為未備妥完整的零件。藉由需求清單被列出,也可以讓接受需求的人在接受訂單時,可以先確認每一個必須參與的資源都能夠有需要的投入,讓需求,銷售,開發能夠一起擬定生產計劃。

  • 第三步工作法
    告訴我們如何建立一種文化,既能鼓勵大家探索,從失敗中汲取教訓,又能理解反覆與練習是精通工作的先決條件。

    提升預防性工作是全面生產維護(Productive Maintenance, TPM)這類計劃的核心,精實社群(Lean Community)信奉全面生產維護的精神,主張我們應不惜一切代價提升維護水準。『改善日常工作甚至比進行日常工作更重要』。持續給系統施加壓力,從而不斷強化習慣並且改善某件事情。

    也就是所謂『改善型(Improvement Kata)』,書中是使用為期兩周的改善循環,每個改善循環都要實施一個小型的計畫》執行》查核》行動的專案,持續朝目標邁進。

    在此必要的實務作為包括:建立創新,勇於冒險及高度信任的團隊文化。把至少20%的開發和IT運維週期分配給非功能性需求,並持續強化及鼓勵大家進行改善活動

四種工作類型

在這邊這本書將工作份為四種類型:

  • 業務專案:公司所有的正式專案
  • 內部IT專案:由業務專案衍生出來的基礎架構或IT運維專案,以及內部生成的改善專案(如建立新環境和部署自動化)。這些專案經常未被集中管理,而是隸屬於預算所有者。
  • 變更:包括需求變更或BUG等
  • 計劃外工作或救火工作:包括production issue,通常由上面三類工作導致,而且往往以犧牲其他計畫內工作為代價。在書中說這類型的工作是最具有破壞性的,它並非實質的工作,其他三種工作都是基於需求而事先計劃好的。計劃外的工作會阻止我們進行其他三類的工作,就像物質和反物質,在計畫外的工作面前,所有計劃內的工作都會被延後。
    另外一點則是未被償還的技術債,源自於走捷徑,短時間內,那樣或許行的通,但是就像金融債一樣,久而久之,利息越滾越多。如果一個組織沒有還清它的技術債,那麼,就必須一點一滴,耗費心力,以計劃外的工作的形式來償還那些技術債的衍生利息

訂定組織目標

在這本書有列出了CFO的營收目標:

  • 公司體質健全
  • 營收
  • 市占率
  • 平均訂單規模
  • 盈利能力
  • 資產收益率
  • 財務狀況
  • 訂單轉化成現金的周期
  • 應收帳款
  • 準確且及時的財務報告
  • 借貸成本

在本書他們針對每一個營收目標列出『倚賴IT的區域』及『IT導致的業務風險』以及『倚賴的IT控制』來列出IT在這些目標項目中的角色。倚賴的IT控制指的是防範這些錯誤發生的反制措施,或者至少能夠偵測到問題及做出回應。

在這本書很戲劇化的是SOX-404的稽核專案,資安部門原本一直要求開發部門開發一個安全控制的系統來應付發生錯誤時的資安問題,最後才發現檢測重大錯誤所倚靠的控制手段是人工對帳步驟,而不是上游的IT系統。其實財務部門早已用人工的方式來達到這個資安的要求了,不需額外再開發相關的系統。

因此,不同部門間的資訊透明度真的是一件很重要的事。

遠程目標則包括:

  • 我們具競爭力嗎?
  • 了解客戶的需求和期望:我們知道要創造什麼嗎?
  • 產品組合:我們有正確的產品嗎?
  • 研發效能:我們能夠有效地建立產品嗎?
  • 產品上市時間:我們能夠盡快把產品推向市場,應且搶占一席之地嗎?
  • 銷售管道:我們的產品能夠觸及感興趣的潛在客戶嗎?
  • 我們的作法有效嗎?
  • 按時交貨:我們有尊守對客戶的承諾嗎?
  • 顧客維繫:我們正在增加客戶還是流失客戶?
  • 銷售預測準確率:我們可以把銷售預測準確率納入銷售計畫流程嗎?

相關連結