作者TonyQ (自立而後立人。)
看板Soft_Job
標題[閒聊] 笑談軟體測試的幾個階段（二）
時間Sat Mar 24 23:12:46 2012
前情提要，這是寫給軟體開發者的測試歷程，
在笑談軟體測試的幾個階段（一）中我們提到測試的基本形式，
主要是以我自己進入測試的經驗說明如何進入測試門檻，
以及我身為軟體開發者進行軟體測試時需要知道的事情跟可能的心路歷程。
所有的內容都只是個人經驗僅供參考，歡迎提供意見分享跟挑戰。
-----------------------------------
另外這裡所指的軟體測試都只是主要針對者自己對軟體的測試，
而與專案測試（目的為增加專案品質）的目的並不直接相關。
也就是說，這裡講的主要目的，是開發者如何可以在開發過程，
快速驗證自己的修改是否有誤跟常見的一些問題。
-----------------------------------
本文開始
-----------------------------------
就像先前的停車場計費程式，我們慢慢寫了很多程式，
慢慢的會發現修改程式碼是我們常做的，不論是修 bug 也好、做新功能也好，
我們每次修改完之後都需要進行測試程序。
-----------------------------------
假設現在我們在做一個部落格系統好了，
我今天已經寫好後台可以發文，
發文時我需要提供編輯器給使用者輸入，
還要讓使用者可以做一些刪除或修改的操作。
-----------------------------------
我們一開始開始會一直用測試的『完整環境』做測試，
（重點一）
測試程式碼的運作，然後我開始發現，測試有點麻煩。
某些重複的程式片段我會發現我測試很多次，
有時是它很重要跟複雜，像發文的編輯器特別容易出問題或修改；
有時則是它很重要大家都要用，像是很多功能相依於會員登入。
這些片段改程式碼特別容易測到，
就每次都在測一樣的程式，感覺就很瑣碎而無聊，
特別是登入，我可能根本就沒有改那段code，為什麼我要測他？
-----------------------------------
然後很重要的是，我也不總記得上次的測資，應該說，我很有可能會忘記。
（重點二）
---------我的現況是這樣，看起來是個困境，那我怎麼辦??---------
你可能還是會期待我會說拆 method 跟 unit test ，
然後補一句視狀況採用跟引入這種我自己也覺得有講等於沒講的廢話。
好像這樣事情就結束了，這些話我很常說，它是政治正確的，
但問題是，聽的人在這些話的訊息中收到什麼。
平常講話是真的沒辦法，因為三言兩句我也講不出個屁，
要講經驗我後面有一票的前提論述要講，
還要先看看對方用的語言我有沒有經驗，像講 C++ 的測試我就囧很大。
要講故事沒個五六小時是講不完的，不過寫文章就不一樣了。
我寫文章很重視實戰，就是因為這種東西只有實戰體驗過，
你才會有點體悟那些心法在幹嘛。
特別是這種心法是可以各自表述。
舉個例子，今天有人說『你寫的 java 程式不 OOP』，
你真的能從『不 OOP』這四個字知道他想表達什麼，要怎麼修正嗎？
你可能會因為這樣賭氣跑去讀 OOP 的書，
然後試著把學到的東西用到你專案，多用了幾個模式跟切分類別，
然後很開心的說我程式更 OO 了。（事實上是不是就另外一回事。）
結果你可能一輩子不會知道，
人家只是在嫌棄你寫類別時沒有寫 Getter/Setter 。
(註：這曾經是 OOP 議題中很重要(無聊)的爭論之一)
http://0rz.tw/3T9d0
拿心法等級的名詞互相 PK ，
大概也是趕雲端流行的一種做法，我是覺得作事不用這麼複雜啦，
有時你必須承認我們真的很難明白別人的明白。
因為他們的經驗跟心法，不是你的經驗，而且測試是一體成形的。（後述）
-----------------------------------
-----------------------------------
扯遠了，拉回主題。
-----------------------------------
-----------------------------------
我們剛剛有個困境，那我們現在要來試著改善他了。
註：改善的過程不見得每個方法都是好的，
但我的信念是有嘗試就是好事，有嘗試就會有收穫跟所得。
-----------------------------------
我是懶惰的人，我痛恨無聊、重複而且不必要的事情。
我寧願花五倍的時間寫個有趣的 template ，
我就是不想乖乖好好一行一行 cp 當 code gen。
我寫程式的心法就是上面這句話。
（覺得這樣是好是壞是個人自由啦，
有時候它真的可以省事，有時候它又會誤事。XD）
-----------------------------------
首先我是想辦法設計成，我自己測試時可以跳過登入頁面，
我嘗試設定，「測試環境」啟動時在session 先塞測試帳號假裝登入，
以 java 來講就是寫 filter ，
以 php 來講就是先 include 一隻php。
(從這裡我們可以看出語言支持度跟特性會影響開發習慣很多。)
這樣的確很有效，我瞬間省了好多測試時間，
但問題來了，如果我上線時忘記把測試程式拿掉就完蛋了。
所以我要想辦法建出 debug 環境，
正式一點的會有設定檔，或是利用版本控制系統設 ignore 。
不正式一點的就是放檔案弄髒 workspace 自己小心不要弄錯。
但是即使是最蠢的方案都可以幫我每天開發，
省下幾分鐘到一兩小時的測試過程登入的時間。
Ok , it works.
但是這樣也有別的缺點，
1.它跟真實的環境有出入
2.要是登入真的壞掉了你也不會發現
3.你要小心不要弄錯環境XD
4.如果登入的程式碼有變的話，你可能也要跟著修改。
-----------------------------------
測試資料的管理的部份，我會在程式碼中留下測試資料的註解，
特別是 regular expression ，
沒留下測資我大概過個兩天大概就不知道我自己在寫殺小。
還有就是善用 issue tracker 跟版本控制系統留下紀錄。
所以當這些紀錄薄弱時，
我們也會特別倚賴團隊中資深成員進行「觀落陰」，
從無邊地獄中用力回想當初的測試情境。
最後真的不行就是走逆向工程，他會用到什麼，
你就想辦法整他惡搞他自己想辦法丟東西測。
-----------------------------------
我們第二篇的案例先講到這，
至於那些異動頻繁的程式區塊，我們留到第三篇談。
-----------------------------------
-----------------------------------
ok，
第一篇我們講的是一個簡單的範例，
第二篇我們講的是複雜的範例，
從第二篇我們談到的事情裡面，有哪些測試的要素？
1.測資的問題
我們第一篇強調過，測資是一切的根本，
而這篇我們開始提到，測資是需要被管理的，
測資的有效/可靠程度就跟你程式的穩定程度跟開發效率成正比。
2.測試路徑問題
每個測試的過程中你需要作的操作，我稱之為測試路徑。
測試路徑決定你的測試效率。
最佳化你的測試路徑是開發過程中很重要的事情。
（像是想辦法把登入這個過程跳過）
這其實不只是程式碼的問題，比方說你 server 啟動要十分鐘，
那你就應該挑一個 server 啟動快一點跟方便一點的設計。
3.文章中有特別對「完整環境」這件事情下重點
在測試的範疇裡面，我們把最接近使用者的環境測試，
也就是 dev server 或 dev environment ，
稱之為
整合測試。 (Integration test)
這種狀況下，你有可能被其他的因素干擾，
舉例， db 如果掛了你登入可能就就整個沒辦法測試。
整合測試的重點在於他是盡量要達到測試最接近真實的情境。
當然這裡我們還沒有要對 unit test 跟 integration test 多著墨，
但是我想說的是，通常我們一開始進行的測試都是整合測試為主。
為什麼會這樣，我們之後的章節會繼續探討。
-----------------------------------
下一篇，我們將延伸這篇的主旨，
繼續探討其他案例下，測試路徑跟測資的問題。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.81.205.78
※ 編輯: TonyQ 來自: 111.81.205.78 (03/24 23:16)
※ 編輯: TonyQ 來自: 111.81.205.78 (03/24 23:16)
※ 編輯: TonyQ 來自: 111.81.205.78 (03/24 23:17)
※ 編輯: TonyQ 來自: 111.81.205.78 (03/24 23:21)
推 thinkniht:我覺得軟體開發是有很多方法可以使用的... 03/24 23:43
→ thinkniht:但我非常不認同為了使用這些方法而使用這些方法 03/24 23:44
推 codemonkey:測試的前提是測試案例與接受標準到結案仍有效力 03/24 23:53
→ codemonkey:...我在說什麼啊，抱歉沒想清楚就推文了 03/24 23:54
→ TonyQ:沒關係啊 我寫文章很隨性的 XD 03/25 00:14
※ 編輯: TonyQ 來自: 111.81.205.78 (03/25 01:06)
※ 編輯: TonyQ 來自: 111.81.205.78 (03/25 01:08)
推 vvppqqvv:一+二都是經驗的累積(起碼我覺得辣.......) 03/25 01:25
推 vvppqqvv:也許在軟體業單純是一種幸福 03/25 01:28
推 clairehuei:看到"觀落陰"三個字 狂笑不已 整個說進我心坎了 哈 03/25 21:44
→ petershih67:能維護Linux GPL open source code的工程師，幾乎每個 03/25 22:29
→ petershih67:都有觀落陰的本領。 相信我，只要用正常的語法邏輯寫 03/25 22:30
→ petershih67:CODE，是不太需要註解別人也可以維護的。 03/25 22:30
→ petershih67:我英文很爛,你看不懂中文. 但我們卻可以用程式溝通?! 03/25 22:32
→ TonyQ:看什麼程式碼，你有興趣的話我丟段 regex麻煩你猜猜我想表達 03/25 22:36
→ TonyQ:什麼。 03/25 22:36
→ TonyQ:有測試的「測資」方便測試跟「讀懂」是兩回事。 03/25 22:37
→ TonyQ:讀懂可能很簡單，但是知道哪些環境下會有問題，為什麼會有 03/25 22:37
→ TonyQ:這些測資，是很重要的。 03/25 22:37
→ petershih67:regex的確是需要一點說明。 03/25 22:37
→ TonyQ:我自己的經驗啦，有幾個點需要作註解 03/25 22:40
→ TonyQ:regex 是一種，再來就是 performance tunning 相關的， 03/25 22:40
→ TonyQ:比方說打 cache 或者是哪邊有偷吃步之類的。 03/25 22:40
→ TonyQ:不過測試跟讀懂程式碼不見得是同樣的事情就是了，之所以程式 03/25 22:41
→ TonyQ:碼中，其實不真的常會看到測資，很簡單就是因為有更好的方式 03/25 22:41
→ petershih67:還有就是系統或是某些關鍵的地方用了很怪的方法避開. 03/25 22:41
→ TonyQ:把測資記錄下來。（之後會慢慢談到。） 03/25 22:41
→ petershih67:T大很專業。不過大專案通常有專業的QA。 小專案就等 03/25 22:42
→ petershih67:客戶抱怨再改了。 大多CODING的很討厭做 QC。 03/25 22:43
→ andymai:所謂的觀落陰其實就是思路相近或有辦法融入原著的思路，如 03/25 22:43
→ andymai:果沒辦法抓到原著思考的方向~那看起來是很浪費時間的... 03/25 22:44
→ TonyQ:不，觀落陰通常就是叫他想當時誰幹得，想辦法找源頭說明... 03/25 22:48
→ TonyQ:你說的那個是被我歸類在逆向工程區（戲稱）的.. 03/25 22:48
→ andymai:@@沒有svn或註解能找到源頭嗎?能找到源頭當然是最好囉~可 03/25 22:49
→ TonyQ:逆向工程十次有九次時間都是浪費掉的，如果沒留註解的話， 03/25 22:49
→ TonyQ:多年以後還能再來一次.. 03/25 22:49
→ TonyQ:找不到源頭的話就只好作逆向工程了... 03/25 22:49
→ andymai:是太多時候是找不到的~尤其是寫的人已離職... 03/25 22:50
→ TonyQ:當然，所以現實生活是作逆向工程的多，都在浪費時間。 03/25 22:50
→ TonyQ:所以才要宣導盡量保留測資，測資有時比程式還有價值。 03/25 22:50
※ 編輯: TonyQ 來自: 223.143.225.151 (03/25 22:51)
→ petershih67:一般講的逆向工程是反編譯那種，T大是不是有點講錯了 03/25 22:51
→ andymai:我倒是有碰過註解是錯的，或寫的人懂，其它人看不懂的XD 03/25 22:51
→ TonyQ:@petershih67 只是戲稱啦 :D 03/25 22:51
→ petershih67:我以前也很愛寫註解，現在都不寫了，一方面是註解寫 03/25 22:52
→ TonyQ:@andymai 那也就沒辦法啦XD 03/25 22:52
→ petershih67:一堆，還不如直接看CODE (難如REGEX也是看Code較快) 03/25 22:53
→ TonyQ:這些事情要看開發習慣跟團隊共識啦，不是所有專案都能放在 03/25 22:54
→ TonyQ:同一個天平上看的。 03/25 22:54
→ petershih67:二方面，坦白講寫再多後面接手的人也不見得看的懂. 03/25 22:54
→ petershih67:不過，若專案經理比較嚴格規定這些細節，其實是好事. 03/25 22:55
→ TonyQ:我只關心一件事情，這專案我一年以後再回來看，要多少時間能 03/25 22:55
→ TonyQ:進入狀況，如果寫註解可以幫助這件事情，我就寫。 03/25 22:56
→ TonyQ:寫註解有時候只是個 index ，方便你從片段想起全貌， 03/25 22:58
→ TonyQ:但是有時我們也會下錯 index，也會忘記 update index， 03/25 22:58
→ TonyQ:不重要或者容易記得的東西也不需要 index 03/25 22:58
→ TonyQ:所以我都是以我有多少機會記得這東西會這樣設計進行註解。 03/25 22:59
→ TonyQ:不過話說回來，測試跟開發的註解應該要分開說就是了... 03/25 22:59
→ TonyQ:以測資的話，我還是覺得多多益善。 03/25 22:59
→ petershih67:測試的領域真的很專業，可惜真的很容易被忽略。 03/25 23:03
→ petershih67:我自己也完全沒受過訓練，還插嘴這麼多.請T大海涵啊 03/25 23:05
→ TonyQ:不會啊 只是討論 XD 03/25 23:08
→ TonyQ:我也沒受過訓練 只是有在作 所以歡迎一起討論囉 03/25 23:09
→ petershih67:小聲的說，我只概略的品管我的CODE之後，就交給測試 03/25 23:12
→ petershih67:的人去測。出包再修。測試計劃那種，真的是能閃就閃 03/25 23:13
推 thinkniht:我想很多人對很多事情應該都是沒有受過訓練... 03/26 00:12
→ thinkniht:靠自己摸索或看書之類的方式來學習的吧... 03/26 00:12
→ thinkniht:@petershih67：我覺得你那樣很正常 畢竟對PM或主管而言 03/26 00:13
→ thinkniht:你的開發時間是越快越好，趕上時程進度最重要... 03/26 00:15
→ thinkniht:被發現問題要修改是之後的事情 03/26 00:16
→ thinkniht:我認為單元測是很重要 但是有的人會覺得只是浪費時間 03/26 00:17