【敏捷迭代式開發中的測試】第一篇：有關測試的真實劇本序章。

定義測試 & 測試人員特質

軟體測試的目的，是找出其實際行為及期待結果之間的差異。 

(定義來源：Auerbach Publications, 2008, 《Software Testing and Continuous Quality Improvement, Third Edition》)

一般來說，所謂的「差異」指的是較負面的「缺陷」；不過若積極一點想，也應該包括較正面的「驚喜」。以這個定義來看，可以想像測試就像是在比對兩張重疊的描圖紙上的同一幅圖畫上的線條般，透著光、瞄著眼，指出這裡有出入、那邊要修正…之類細瑣繁複的工作。

畫有同一幅圖畫、重疊在一起的兩張描圖紙，其中一張是所謂的「原稿」；另一張就是「描稿」。假設原稿上的圖畫，其線條清晰俐落、運筆傳神，在工具足夠的情形下，例如：有舒適的座位、燈線充足的透寫台、粗細相同的繪筆，那麼理論上可以讓描稿趨近於原稿的難易度應該不會太高。這樣的工作也相對顯得單調、不需要創造性思維，只需要足夠的耐心及細心。

但是，現實世界裡會發生的事，真的有那麼簡單嗎？或說，有那麼單調嗎？

在軟體的世界裡，原稿從來都不會太清晰，甚至原稿大多還不是作者畫的！作者只提供異常抽象的概念、世界大同般的期望。如果作者是台灣風的，還可能加上想殺人滅口的成本要求。所謂成本，可能是時間、金錢或品質。

那麼誰來畫原稿呢？應該是畫家吧？很不幸，通常也不是。通常原作者就是最不懂得畫畫方法的那個人。而畫原稿的人，可能很懂得藝術史、對於名畫的歷史背景如數家珍、對於名畫的價值也很瞭解。但是，就像古典音樂聽再多次、再熟的人也無法進行任何一種樂器的演奏般，那負責畫原稿的人，通常畫技水平可能和他最後一次交中學時代美術作業的程度差不了多少。但是他長大了，經過多年看畫的經驗，他可能以為自己能以炭筆畫出噴畫效果了？或是認為灰階鉛筆畫就能充分呈現色彩氛圍？

所以實際產出的原稿到底和原作者想像的原稿，是否一致？很不幸的，通常就算可以審核，也經常性地被忽略。因為，真正的產出是「描稿」。沒人想在「原稿」上浪費時間。

在軟體的世界裡這並沒有任何值得大驚小怪的地方，因為就軟體而言，若「原稿」畫得是飛機，那麼「描稿」就是一架應該真的可以飛的飛機。

所以，現實世界裡的軟體測試，沒那麼簡單、沒那麼單調。因為「原稿」可能和作者的期望非常不一致，畫「原稿」的人的技法可能非常粗略、粗略到無法真實反應原作者的期望：即使那期望已經說的夠明白了。

「描稿」的人，一般來說，是真的畫匠。有些畫匠會自行想像原稿不清楚、不合理的部分，有些畫匠會把模糊、無法想像的部分當作什麼都沒畫上去，就直接留白下來。哪種風格比較好呢？答案在原作者身上：剛好符合的就好，不符合及根本沒畫上去的，一定不好。

所以應該自行想像，然後外加運氣是比較好的組合方式嗎？不是，當然不是。如果蓋的是一棟101大樓或是大型客機，誰敢賭這種運氣呢？沒有，我想幾乎沒有。

以往，我們會在「描稿」出圖後，找一位「審稿」的人，由對方來挑三揀四、說明哪邊的線條曲度不足、哪裡的勾勤又不夠有力。這樣的「審稿者」通常和「描稿者」不會交情太好。因為兩者經常會主觀地自行詮釋某些線條該有的樣子，而忘記去問原作者到底要什麼樣的線條？或者，「審稿者」無法具體描述某線條到底哪裡不好？只反應：怪怪的、我想不是這樣、就是缺少了點什麼。「描稿者」無所適所，可能覺得對方只是在找麻煩。

到了敏捷迭代式開發的流程裡，「審稿者」在心理上、工作內容上都應該變得幾乎完全不同。原作者的期望是什麼？和「原稿」符合程度能多少？如果提出疑問，讓該問題的答案能引導「原稿」更接近原作者的期望，變成「審稿者」的工作之一。

「原稿」和「描稿」之間的差異有哪些？該如何追查出？差異量是否能被作者所接受？這也是「審稿者」的工作了。所以「審稿者」的工作，並不是「描稿」出現後才被啟動，而是打從作者開始描述「原稿」時就開始了。「審稿者」要能輔助讓「原稿」更接近「期望」、讓「描稿」與「原稿」之間的差異在壞的方面降至最少、在好的方面被突顯。

為了達成上面的目的，「審稿者」必須參與至整個圖畫描製的整個流程、與作者、原稿畫者、描稿畫者都充份合作才行！非常不簡單！非常不單調！

回到軟體開發的故事，審稿者就是測試人員。他負責與作者(客戶)、原稿畫者(PM、分析師、架構師)、描畫者(開發單位)進行協作，其工作內容就是最終產出物與客戶期待結果之間的品質管理。

測試人員要做好以上事項，很明顯地：必須善長思考、溝通、對高質量的挑剔、善於學習並懂得團隊合作的務實者。工作內容絕對不比任何角色來得輕、人格特性更是得要有點難能可貴才行。

測試人員是專案成員中最關注品質的成員之一 (另一者為架構師)，他們是專案要順利進行的有力盟軍，絕對不是以往那種在交付前負責找麻煩就可以的角色。

Effective Objective-C 讀書會 第3篇

範圍

主題33：使用弱式參考避免保留循環
主題34：利用自動釋放緩衝池區塊來減少高記憶體耗用水位
主題30：使用 ARC 讓參考計數更加容易處理

整理

主題33

承繼主題01及其他記憶體相關的主題，我們已經知道：物件的存在與否在於它是否被其他物件所擁有。筆者個人喜歡用「需要」來形容。在語言的設計方面，Objective-C 採用計數的方式。假設有物件A需要使用到物件B，就程式碼來看，物件B會透過物件A所擁有的建構子、靜態工廠方法或 setter method 被注入到物件A，那麼對物件B就會在自己的計數器上加1，而只要物件的計數器不小於等於0，則代表該物件有存在的價值，而 Runtime library 就不會對該物件的記憶體位址進行「標註可利用/標註原物件無效」。

上面的解釋大抵上是對的，但是其實還有一個條件要滿足。

Objective-C 支援 multi-threads，其中有一個和應用程式生命週期相等的 thread ：main thread。(並不代表所有和應用程式生命週期一樣的都是 main thread，main thread 是一定有而且唯一的)

任何與 main thread 掛勾不到的物件，也就是說，以樹狀觀念來看，main thread 若是主幹，我們先把其他 thread 視為分支。試想，若有二個物件，它們擁有/需要彼此，因為其計數值都大於0，但是它們卻不在任何 main thread 可觸及到的任何分支上，那是什麼樣的情形。

簡單講，那代表應該程式已經喪失該物件的操作能力，而且即使它們永遠不會被應用程式所利用，也不會因此而消失：因為它們需要彼此。它們(至少需要有二個以上的物件才會形成這個結構，重提主題01：就是孤島物件(群)。

要對付這樣的孤島物件群，有個直覺的作法：引入垃圾收集機制(Garbage Collection, GC)。這項技術是 Java 以往被強調的長項。不過 Mac OS X 10.8 已宣佈不在維護這個環境，而 iOS 本來就沒有支援，又是為什麼呢？

道理很簡單，GC機制本身是一個 daemon thread，它本身也會長期佔用資源。試想，當執行環境因突發狀況的發生，而導致連這個 daemon thread 都要不到記憶體來執行時，GC 就會變得完全發揮不了功效，甚至成為系統「卡還會再卡」的幫兇。

對於原本記憶體環境就相對不優沃的行動裝置而言，iOS 不支援 GC 是項明智的選擇。而 Mac OS X 進一步地捨棄這個機制，就代表 Apple 認為總有更好的作法：那就是將在主題30進行討論的 ARC 機制。

回到孤島群的解決方法：利用在 property attribute 或一般/區域變數宣告時，加入「unsafe_unretained」或「weak」的宣告即可。

以上面提及物件A及物件B的例子來說明：假設物件A需要物件B，物件B對物件A的關係是 unsafe_unretained 或 weak 的話，代表：物件B並不擁有物件A，換個語意說來有點悲傷，今天當物件A計數歸零時，物件B也不會強求，覺得物件A消失就消失吧。一旦物件A消失，對於物件B來說，也不過就是需要它的物件少了一個。若物件B因為物件A的消失而同時也不再為任何物件需要，那麼物件B也就得消失。

unsafe_unretained 和 weak 的不同是：假設物件A的計數歸零，物件B原此指向物件A的 reference 會不會設定成 nil ？ weak 會那麼做。由 Objective-C 有著：對 nil 發送訊息也不會出錯的特性，所以使用 weak 相對地比 unsafe_unretained 安全。(unsafe_unretained 自己都這麼命名了) 那麼，進一步的疑問題是：那為何需要 unsafe_unretained ？都使用 weak 不是比較安全？答案是：這是給程式設計者更靈活的選擇。有時，我們希望物件A的計數歸零時，我們的程式會得到感知，這個感知因應著一項重要邏輯，而這個邏輯不成立時，應不惜癱瘓讓整個應用程式。

最後加註個名詞解釋：unsafe_unretained 與 weak 是由 Runtime 中被實作，其中 weak 提供的功能叫「Autonilling」。

主題34

大家都有存發票的經驗嗎？從店家取得發票後，它會被放在你的皮夾、皮包或口袋裡，然後可能被放置在桌上，總之最後可能找個袋子或盒子裝起來。然後等到對獎的時間到了(最長二個月)，終於可以決定那一張張小片小片的紙到底是黃金？還是垃圾？(講到這個，筆者的人生經驗一向很沒故事可以講…就是不會中的那種…)

發票有這種特性：不到開獎的號碼列出來之前，我們沒辦法判定它是否還需要被保留。有些物件也有類似的特性：不到某個周期結束之前，我們沒辦法決定是否還需要保留它。

從 Objective-C 的記憶體管理方式我們知道了有保存該物件的方式：發送 retain 訊息；或是反過來發送 release 訊息，明確我們對某物件的需求中止。但是，試想：如果我們在某方法內創建了某物件，而該物件做為該方法的回傳值，我們不就無法在該方法的執行範圍內自行決定該回傳值是否該被 release 了嗎？這種時候，就無法做到「自己創的物件自己要負責放」的原則，難道只能經由文件或其他可能的方式將物件釋放的任務轉稼給持有該回傳值的外部物件嗎？

答案是否定的。「自己創的物件要自己負責放」的原則不可以違反，但是釋放的時機點可以被延遲！這個就是 autorelease pool 的概念原型。

我們可以建一個 autorelease pool，語法如下：

@autoreleasepool {

        //範圍A

}

在「範圍A」中任何被傳遞 autorelease 的物件，都會在脫離自己的生命週期範圍後，被佔時地丟到 autoreleasepool 中，直到「範圍A」的執行周期結束，Runtime 會對被放在 autoreleasepool 中的物件進行檢核及清除。就像發票在二個月的開獎時間到之後，才知道它們該被丟掉還是保留。

autoreleasepool 在 main.m 中可以看到系統已經預設加上了一個，儘管因為它和 main function 的生命週期一致，所以在技術上是不必要的，但是它可以讓有使用 autorelease 訊息的程式碼不會在 console 上出現「xx autoreleased with no pool in place - just leaking -..」的訊息。所以這個預設加上的 autoreleasepool 被稱為「catch-all pool」。

autoreleasepool 可以巢狀。雖然，在足夠好的設計下，我們可能很少有機會用到。但是假設我們有個需要在記憶體中暫時積存很多物件物件的演算法，我們就可以用這種套疊式的 autoreleasepool 來限縮 pool 的複檢範圍、減短物件被回收所需等待的時間。這在技術上是可以達到，但是應該盡量避免的，因為它至少會讓程式碼的意圖被分散：商業邏輯和最佳化語法的混雜，會使程式碼的可閱讀性大幅下降。

取而代之的，就是盡可能讓商業邏輯有明確的限制、讓記憶體的佔用空間事件化、可重複利用他。若真的不得不使用較複雜的記憶體管理邏輯，那就使用物件導向的最基本原則吧：封裝它！可能模式被導入，或是機制被導入。總之，盡可能在高層次隱藏和商業邏輯無關的程式碼，讓原來的邏輯意圖更明確，也讓複雜的管控機。


主題30

是什麼新的記憶體管理機制奠基於手動記數(MRC)，甚至最後讓 Apple 決定在 Mac OS X 中明定終止對 GC 機制的維護的呢？答案就是 ARC (Automatic Reference Counting)。

ARC 的出現，是意圖讓程式員可以別把心力放在 retain、release 的精細微調上，而更能極中精神於「你要做的是什麼」，而非「你要如何做」。

ARC 機制同時實作在「編譯期」及「執行期」。編譯期方面，以「靜態分析器」找出原程式碼參數計數上需要補齊的地方，然後在編譯後幫程式員加上原本該自己加上的「retain、release、autorelease」。所以程式員就不用自己寫了；更正確地說：程式員也不能自己寫了，不然會造成靜態分析器的困擾。

此外，以往 MRC 的寫作定律中有一條：應該在 dealloc method 中將使用到的變數參考進行釋放及設值為 nil 的規定，也一併被靜態分析器做掉了，所以程式員也不該呼叫、實作 dealloc method。

ARC 在執行期能更進一步地替靜態分析器無法做到的最佳化做出更好的處理：不但必需與非 ARC 的程式碼兼容，又能協助靜態分析器難以最佳化的自動釋放機制。Runtime library 提供了一些特殊函式，例如：objc_autoreleaseReturnValue 、objc_retainAutoreleasedReturnValue。

ARC 對於 property attribute 的支援上，在之前的主題已經提過的，包括：strong, weak, unsafe_unretained，而 ARC 進一步地對區域變數及實體變數也提供了：__strong、__weak、__unsafe_unretained及 __autoreleasing 這幾個限定詞，置於型別與 reference 名稱中間。(均以兩個底線做為前置符號)

其中， __weak 經常用於某個在 block 中會使用到、但是宣告處外於該 block 的變數。這是為了打破 block 引進的保留循環：區塊會自動保留它所獲得的全部物件。在主題 40會討論如何避免 block 引進的保留循環，但是並沒有仔細說明為什麼區塊會自動保留物件。

不過若仔細考量 block 的行為，就可以留意到其非線性執行時機的特性，的確是需要有個保留機制，讓它能操作約定好要使用的物件。一般書上會說：block 內無法改變宣告在該 block 外的變數，這個說法雖然在表達行為結果上沒有錯，不過實作上的內容不如說 block 內取得的物件往往是複本要來得正確。至少有不少語言是這樣實作的。

ARC 使用了特定的方法命規則：若方法名稱以「alloc, new, copy, mutableCopy」為首，則方法的呼叫者就「擁有」該方法回傳的物件。這個命名規則會讓不知道此規則的人在使用 retainCount method  帶來困擾。由於 ARC 會自動維護這些規則，所以其實 API 的使用者並不太需要進一步的了解；不過若為 API 的開發者，則要多留意方法的命名，並始終了解內部動作的實際執行方法如何比較好。