軟體測試實踐：測試web MSN - 內容整理

測試用例是軟體測試的最小單位，是測試工程師的子彈。對軟體測試入門者來說，測試用例是第一位的，有了好的測試用例你就能發現別人沒有發現的bug。只有當你具有良好的、開放型的測試思維，你才能得到優秀的測試用例。

1. 我們要熟悉產品的需求規格說明書(軟件需求是測試的標準與範圍)。若需求不具體或者需求文檔過於簡略，這時測試應該去推動需求的制定。

a. 測試以需求規格說明書為基礎，但同時也要去發現它裡面的錯誤，推動需求的完善。

b. 測試工作是貫穿於整個軟體開發過程的，越早發現錯誤，修正這個錯誤的成本就越小。

2. 測試工程師要瞭解專案的整體安排(即專案的時程)

a. 測試是無窮盡的vs.實際測試是有限的 <= 測試的經濟面(時間、成本等限制)

3.預備好測試環境

a. 工作環境與測試環境要分開

b. 功能測試環境和性能測試環境要分開

c. 提前準備好硬體(伺服器、客戶端、網路設備)和軟體(作業系統、瀏覽器)

d. 測試支援平台也是測試環境的一部分。測試支援平台：一套測試的自動化辦功系統，例如測試用例管理系統、bug管理系統、測試報告產生系統等。

e. 把搭建測試環境時遇到的問題和相應的解決辦法記錄下來，形成文字，以備之後查詢。

<<測試常用專有名詞>>

黑盒測試：只知道功能的測試。 <= 功能測試

白盒測試：只知道程式碼結構的測試。 <= 單元測試

灰盒測試：知道功能也知道程式碼結構。 <= 執行某個功能中所有的單元測試??

功能測試：對產品的功能做測試。

性能測試：一般是檢驗在普通場景下產品的性能。

壓力測試：檢驗產品在極端條件下的性能(極端條件下的性能測試)。

回歸測試：

1. 在開發人員修復一個bug後，去驗證這個修改是否正確所做的測試。

2. 在軟體開發後期，選擇否依部分重要的測試用例去驗證產品的某一個版本工作是否正常。

單元測試：函數級別的測試，一般都由開發人員來完成。

整合測試：將各模組代碼整合到一起，實現一個或一些功能。驗證代碼的整合是否正確。

系統測試：針對子系統做測試，也就是大一點的整合測試。

邊界值：是確定合法輸入與非法輸入的判斷條件(通常會在邊界值的左右在各選一個值來測試，也就是每一個邊界值得測試會有邊界左值、邊界值、邊界右值，三種值)。

等價類：將涵意或影響相似的值分在同一類中，並為每一個類選一個代表即可。例如，在0~100中，如果以偶數奇數來分類的話，就是兩類，各選一個奇數和偶數來測試就可以了。

里程碑：軟體專案一般可分為多個階段，每做完一個階段，我們就說實現了或達到一個里程碑。

評審(Review)：

bug重現(再現)：不能重現的bug，它的嚴重性一般都不會很高。

BVT(Build Verification Testing)測試：在一個新版本出來後，先要做一個最簡單的測試，保證這個版本的基本功能工作正常。亦稱冒煙(煙霧)測試。

自動化測試：透過測試工具來實現自動運行的測試。

UI測試的關注點：

1.      界面元素要符合通用規範

2.      窗口能在不同的尺寸下顯示正常

3.      支持用戶不同的作業系統的設置

4.      支持用戶使用不同的解析度

5.      處理好焦點問題

6.      作語法檢查，避免文字錯誤

7.      對不方便人群的支持

8.      支持快捷建

測試計劃的關注點：

1.      測試時間的安排

2.      測試人員的安排及任務分配

3.      測試資源的安排，包括需要的軟體、硬體

4.      自動化測試的安排

5.      測試風險的分析以及對策

                                                                                                          

<<設計測試用例的一些思維>>

1. 一個測試用例只負責一個細小的使用場景，越細越好。

2. 軟體的基本數據也在測試範圍之內。

3. 檢查默認值是一種很好的測試思想和習慣。

4. 使用"排列組合"的方式編寫測試用例(測試是無窮盡的vs.實際測試是有限的)。

5. 輸入框為空是一種特殊值。

6. 做軟體測試時，總有一些"附屬項"需要驗證。

7. 測試用例要有覆蓋到極限值(邊界值測試)的情況。

8. 登入驗證在安全性方面要多多考慮。

9. 懷疑一切，驗證一切。

10. 網頁得標題欄也是需要測試的。

11. 考慮一個測試點時，需更多的從動態的角度出發。

12. 快捷鍵的驗證。

13. 下拉式表單的每一個子項都要測試。

14. 即便功能類似，用例還是要分開寫。

15. 幫助文件的內容也是需要測試的。

16. 在測試一項複雜的功能時，可嘗試使用Bottom-Up的測試邏輯。

17. 不要忽視功能點，他們也需要被測試。

18. 所有不正確的需求、設計和程序錯誤都可以報告為bug，讓相關人員去修正。

19. 測試員的眼界要越過被測試的對象，可以考慮與之相互通信的”兄弟軟體”之間的協作。

20. 工具攔中的每項設置都需要遍歷；設置之間的組合可以隨機來做，不必遍歷。

21. 測試人員應站在最終用戶的角度上看問題(UX)。例如，輸入框得到默認的輸入焦點；快捷鍵等。

22. 在每一個軟體的需求之外，還存在著一些”公理”，不言自明的。需求規格書不可能面面俱到，測試員可以根據這些”公理”來擴展需求。

23. 不以機率小而不為。

24. 有些功能可能是界面上沒有入口、看似沒有的，但是在某些條件下卻會出現。

25. 盡量對可能交互或產生影響的產品都有所了解，這樣在考慮問題的時候思路會更開闊。

26. 再考慮複雜場景前，可先以基本場景為切入點，接著列一些提綱，然後再根據一個個的提綱去思考、去突破。

27. 數據不是靜止的，我們需要使用動態的思維方式來考慮問題。

28. 瞭解同事的工作，就能夠做一些跨模組的思考，把測試做得更深入。並避免報告重複的bug。

29. 面對一個窗口的時候，從”變量”入手做測試是一個好的思路。既然它是變量，變成什麼就都有可能。

30. 除了琢磨模組自身內部包含的功能外，我們還要把它和其他相關模組放在一起測試。

31. 有效數據和無效數據都是需要驗證的(有時候他們被稱為合法的和非合法的數據)，測試中需要正反兩方面的用例。

32. 拆解功能的流程，然後逐一分析測試，用以避免遺漏掉很多問題。

33. 狹義上的UI測試：專指對操作介面的非功能性的測試。

34. 文檔保持更新，測試保持更新，保持一種在動態前進的心理預期。任何文檔不可能是一勞永逸的。

活著~~

活著是由大陸的作家 余華 所著。
本書主要在講述主人翁福貴的一生。他如何從田僑仔，然後敗光家產，接著被抓去當兵，
後來又怎樣回到家中，直到最後剩下的孤單一人。

在敗光家產後，他想著如何養活自己母親和妻兒，於是向地主租了五畝田地來耕作。
在被抓去打國共戰爭時，他想著如何活著回家，於是在槍林彈雨中搶著小米及大餅。
在中國解放後，回到家的他，想著如何在超英趕美的大躍進中取得食物養活一家人。
在家人一個一個經他手落土於西村後，最後想著的只是如何單純的讓自己不會餓死。

這樣簡單、深刻的描述了福貴這一個小人物的一生，雖沒有引人入勝的精采情節，
但卻讓人愈讀愈無法釋手。

花了幾天時間看完後，在看完的當下讓我想起了雷洛探長最後在劇末問家僕的問題。
｢人這麼辛苦是為了什麼？｣
｢為了吃飯。｣

粗心可以殺死一條狗~~

這幾天發生一個事件，因為我的不細心及不夠完整的思維，讓我所屬的開發團隊，遭到二線人員的質疑，說我們的程式沒有quality。這讓我對我的團隊感到很抱歉，尤其是我的leader，因為他是首先第一個被質詢的人。

這件事情是這樣的，我們從B系統移植一個X功能到A系統中，負責人就是我。我在移植的過程中犯了一些過失：

1. 系統中提示文字的顯示迷思

因為A系統和B系統處理顯示的文字是使用不同的動態連結檔，剛好A系統的某個設定有問題，使得A系統會連結到錯誤資料夾中的檔案，也連帶讓X功能可能存在顯示不正常的機會。只是剛好我的電腦在那個錯誤的資料夾中，存在了對的檔案，所以移植到A系統的X功能，在我的電腦可以顯示正常，但測試人員的電腦就出現問題了。

è 我應該更細心的檢查程式碼，發現他們是使用不同的DLL，並檢查出A系統呼叫到錯誤資料夾中的檔案。這樣我就可以修改它，使其可以永遠顯示正常的文字。

2. 忽視一個重要錯誤的不應該

因為我的開發環境是Win7，而使用的開發語言是VB6，所以常常在發生由Win7建構出的程式，在執行時會造成一些錯誤。而我卻把這次的一個錯誤，誤認為是由於Win7所建構造成的，結果最後被發現其實是程式的bug。

è 我應該要用另一台XP電腦來建構這個程式，然後再加以測試。這樣就會發現到這個問題並不是由於win7的建構環境所造成，而是我乎叫某個函式的先後順序有誤所產生。

3. 忽視測試過程中每個數值變化的情況

在執行我想得到的測試案例時，我沒有注意到所有使用到的數值的變化，使得我沒有發現到，在寫入歷史紀錄時會誤用到預設的帳號，而不是真正當時在操作的使用者帳號。

è 我應該要更細心的查看每個數值得記錄與更動，只要稍微把每個資料都看過一遍，就一定會發現這個錯誤，但我沒有。

4. 思考到的使用案例不夠全面的後果

在測試的過程中我只著重在X功能本身的測試，沒有思考到與這個X功能有相關的其他功能。根據原本的設定，在X功能中設定某些資料後，啟動Y功能時，Y功能應該要讀取在X功能中設定的資料，並用這些資料來更新資料庫的數值。但因為我不夠全面的思維，沒有發現到Y功能這樣的行為沒有被啟動。

è 我應該更主動去瞭解X功能及與X功能相關的其他功能，並盡可能的找出這些功能的所有使用案例，如果可以依循使用案例來測試，這樣就可以避免掉產出半殘的X功能。

總結：

雖然大部分的問題，很多是由於我對於整個系統的架構和機制還不是很了解所造成，但這不應該作為藉口，因為現在負責的人是我。我應該要想辦法去瞭解，不過我卻沒有做到，只有簡單的測試一下，然後覺得看起來很OK應該沒問題了，這真的是要不得的想法。這些天來我也看了許多測試的書籍，發現上面我犯的許多錯誤，其實書中都有提到，也註明了這是許多測試人員會犯的通病，沒想到就真的發生在我身上了(雖然我是開發人員)。最後，這次的事件對我來說真的是一個很好的教訓，但也是一次很好的學習機會。希望這次的學習，可以讓我更加的成長，並在下次或將來開發時都能更加注意、更加細心地去思考及處理。

曾遇到的DB問題 (一)

三個跟DB相關的問題，兩個是我還在寫android時遇到的；一個則是在我開始寫VB6以後看到的。

(一)

當時是有一個ANR(Application Not Responding)的issue，後來根據log發現是因為發生DB lock，結果造成等待DB等到發生了ANR。那為什麼會發生DB lock呢？我記得當時我跟一位同事看code看了很久，看起來好像都沒有問題，直到一直查到源頭，另一個同事寫的存取DB的library，終於讓我們發現了一個問題。原本library的設計概念是把存取DB的類別使用singleton模式來實作，但是卻沒有將建構子的存取權限設為private，使得在開發Provider時誤用new來實體化DBHelper。

所以當多執行緒操作DB時，就可能發生new兩次實體的狀況。也就是說當A物件先使用DBHelper，然後B物件又使用DBHelper，接著就會發生DB lock。使得B物件無法使用DBHelper，於是他只好等待到天荒地老到發生ANR。發現了這個root cause後，我們便將建構子的存取權限設為private，並把要使用到DBHelper物件的程式碼，改為以getInstance來獲取實體，這個issue也就這樣解了。

(二)

第二個也是DB的問題，這個問題是在第一次使用該AP時才會發生的issue，而且還必須依照某一特定的步驟才會發生。問題是這樣的，有一個應用程式A，還有一個應用程式A的外掛程式B。當使用者還沒第一次執行過A之前，先使用了B就會發生B無法外掛到A的問題。這個問題很特殊，而且可能跟上面DB lock問題一起發生。我試了很久才終於找到這個issue的重覆產生步驟，因為它只會發生在A從來沒有執行過的情況下，而這個情況通常只會發生在剛刷完新ROM的機子中。

主要的原因是這樣的：

1. 在第一次執行A之前，A所需要用到的資料庫是完全不存在的(我想這應該只會發生在Android吧)。

2. 目前實作的機制是將可以外掛到A的來源資料儲存在DB中。因此，資料庫在創建時必須自動加入A可以接受外掛的來源，否則外掛程式皆無法外掛到A之中。

當A從沒被執行過，DB還沒產生出來時。在執行B的時候，B會透過一些機制來使用A的Provider，接著A會發現沒有DB存在，然後開始create一個DB。當DB建好後，再透過一些機制將外掛來源寫進DB中。也就是說，這是一個兩步驟的動作，所以當A只做到第一個動作時，B便開始想外掛進A，然後就會出現A發現DB中並沒有B可作為外掛來源的資料，於是拒絕B的外掛，並造成B外掛失敗。這個問題簡單來說，其實是因為多執行緒的時間差造成的問題。最後的解法是，當A確定DB建好且外掛來源也已經寫進資料庫中時，再發送一個訊息給B，讓B再做一次外掛即可解決。

我的成功可以複製 － 唐駿

Today, I read a book "My success can be replicated".
It is a biography for Jun Tang(唐駿), one of the best CEOs in China.
I think it is a good book for everybody, whatever you are students, engineers or managers.
I summarized some contents as follows:


1.成功的秘訣是什麼？做人簡單，做是勤奮。成功4+1：4分別代表智慧、勤奮、激情和機遇；1代表性格。

2.能考入重點大學固然很好，但是並非進到重點大學就可以解決你的問題，也不意味著到了非重點大學你的人生就缺少機會。

3.只有勤奮才能真正引領以實現人生的目標。其實每個人的智商都差不多，每天我比你多工作20%，也許就意味著我成功的機率多了50%。

4.大學裡的學習絕不只是簡單地把書本讀會。讀什麼專業固然重要，但是比這更重要的是培養自己學習的能力。

5.當周圍人沉迷於溫飽時，你應該去發現新的機會所在。如果你在一家公司裡感覺工作很安逸，你就需要尋找新的發展空間。

6.在一個人具備相當的經濟基礎、管理經驗、對未來方展的預見能力、對公司業務模式的深入理解和對市場的全面了解之前，個人創業並不是一種可取和可行的選擇。

7.每一個看似低的起點，都是通往更高峰的必經之路。任何時候都沒不能放下的成就。這種心態可以使人無往而不利。

8.第一份工作不是選一份好職業、不是選一份好薪水，而是一定要選一家好公司。因為一家好公司可以在各方面奠定你的職業基礎。

9.每個人的職業生涯一定要有良好的規劃，不能盲目努力。沒有目標地工作，在勤奮也沒有用，而且5年、10年以後，你會發現你還在原地踏步。

10.一個成就事業的人，最重要的素質是對工作的激情，而不是能力、責任心或者其他東西，雖然他們也不可或缺。

11.我們在企業裡要做得不是抱怨、不是提意見和建議，而是真正的對公司做一些實質性的改進。能提出問題，又能提出解決方案，且還能論證出方案可行性的人才會真正的被重用。

12.不僅做好自己的本職工作，還要替公司考慮哪些做的不合理或者不夠完善的地方。與上級長官溝通的規範，應該先和直屬長官溝通，在一級級地向上匯報。

13.真正的創新必然是基於對市場的了解，對客戶反饋的觀察，開發出來的產品一定要適應市場，提出的模式一定要能解決實現的問題。

14.一定要做自己最內行的東西，一定要在自己本身的職位上來提升自己。從技術做到管理，角色的轉變首先是一個學習的過程，其次是一個潛移默化、循序漸進的實踐過程。

15.許多了不起的成功，其實都靠點點滴滴的細小努力積累而成，作人就是這些細小努力中最重要的部分。向上、感恩、關心－這三種性格是做人最需要的。如果一個人能力不錯、性格又好，想不成功都很難。

如果我看得比別人遠，是因為我站在巨人的肩膀上~~

在｢上帝是數學家？｣的書中，有這樣一個可能的真相。
希望不會破壞大家對牛頓的尊敬(不過說不定大家已經因為微積分而恨透他了)。


在牛頓那個年代，有一個被牛頓視為頭號死敵的對手：多產的物理及生物學家羅伯特‧胡克。胡克曾指控牛頓數度剽竊他的構想（先是光的理論，後又加上萬有引力）。

一六七六年一月二十日，胡克在寫給牛頓的私人信件上宣稱：｢我想你和我（在光的理論方面）的構想都是針對同一個目標，亦即事實的發掘，我想我們也都可以忍受別人的反對。｣

而牛頓在一六七六年二月五日回給胡克的信中寫道：｢笛卡兒的成就是很大的一步（指笛卡兒對光的概念）。你已經增添了多種方法，特別是將薄板的顏色納入哲學考量。如果我看得比別人遠，是因為我站在巨人的肩膀上。｣

然而，胡克不但不是什麼巨人，還是個嚴重駝背的矮個子。
由此可見，牛頓這句流芳百世的名言可能只是想要嘲諷胡克，
並說明他覺得對胡克毫無虧欠的一句話而已！

一周七書 - 楔子

一周七書的連載終於開始了，希望不會在楔子以後就斷尾了~~


楔子

為什麼會有這次一周七書的計劃呢？這一切都是出自某一天的一個巧合，請聽我娓娓的道來。某個周末（其實也就前幾周而已），我從PPT上的一個板連到了Youtube上的一個影片：｢王道還：百年千書的科普與武俠｣，這是因應百年千書計畫的推廣所分享的影片。不過重點不是這個影片，而是Youtube會在正在撥放的影片旁邊列出相關的、你可能有興趣的影片。當時正好有一個相關影片吸引了我的注意，於是我在看完科普與武俠這個議題前就轉台了，真有點對不起王道還老師。雖然我也不清楚王道還老師的生平，但在幾天後的一個機會，我在書櫃中發現了一本書：槍炮、病菌與鋼鐵，正巧這本書就是由王道還老師所譯著。好，廣告結束，回到那個關鍵的影片上。

究竟是什麼影片的呢？就是｢台灣啟示錄 謝哲青｣。我想看過關鍵時刻節目的人應該都不陌生這個看起來斯文、講話謙虛有條理的文史工作者：謝哲青。我花了點時間看完了這個影片，也讓我更瞭解了一些關於謝哲青的生平，影片中他寫出了一句我很喜歡的語句：

每個人心中都有一方沃土　一畝荒蕪
唯有透過不斷地探索與追逐
我　才能填補內心那份巨大的虛空 － 謝哲青

除了這些內容外，哲青還介紹了他的書房，因此讓我有機會一窺他所收藏的千萬(元)書籍。此外，他也很大方的分享他寶貴的藏書與他看過的一些印象深刻的書籍。其中他提到一本書：｢在自己房間裡的旅行｣，而這本書也正是我這整個一周七書計畫的根源所在。由於對這本書內容的好奇心，我上了博客來網路書店查詢打算購買。有瀏覽過博客來網站的人應該都會發現，它常常會有很多促銷、折價活動、書展與贈品。剛好當時再送一個贈品【繆思十年‧經典再現】A4文件夾（一組四款），結果我完全被吸引了，於是很用力的湊出了｢陰陽師 瀧夜叉姬（上、下）｣及｢星塵｣。陰陽師，我想大家都很瞭解夢枕模老師的說故事能力；而星塵，則是在幾年前有改編成電影｢星塵傳奇｣，就這樣我的購物車裡有三本書（實際上是四本）。

一般來說，除了這些新加入到購物車的書外，通常我都會有幾本上一次沒有購買卻想看的書放在購物車中，打算下次購買。結果，想當然爾的結帳價格超過了兩千塊以上，於是｢零與無限大：許文龍幸福學｣、｢建築家安藤忠雄｣和｢蒼蠅王｣就默默的被我下放到｢下次再買清單｣。最後就剩下：｢國姓爺的寶藏｣、｢鬼太郎之妻｣和｢從謊言開始的旅程｣，但還是超過一千塊很多。於是我便在｢鬼太郎之妻｣和｢從謊言開始的旅程｣之中開始猶豫，但兩本真的都很想看，突然我豁出去了，我不管三七二十一就猛然的按下國內訂購按鈕，直接訂購了。很快的，一天後我拿到了我朝思暮想的【繆思十年‧經典再現】A4文件夾（一組四款），喔！不是，是六本書（其實是七本書）。

在自己房間裡的旅行　　　　　　－ 薩米耶‧德梅斯特
從謊言開始的旅程　　　　　　　－ 喜多川太
國姓爺的寶藏　　　　　　　　　－ 蘇上豪
星塵　　　　　　　　　　　　　－ 尼爾‧蓋曼
鬼太郎之妻　　　　　　　　　　－ 武良布枝
陰陽師　瀧夜叉姬（上）、（下）－ 夢枕模

我看的第一本書是，在自己房間裡的旅行。當時還沒有一周七書的計劃，不過當這本書看到三分之一左右的時候，我突然覺得，作者因為被禁足在自己家裡四十二天，所以有了這本書的出現，那我為什麼不能一口氣看完這七本書，然後寫出一本書來分享呢？就這樣我那從星期日到星期六，一周七天，漫遊於七本書中的旅程便如火如荼的展開了。