1. 前言

1.1. 軟件質(zhì)量

眾所周知，軟件質(zhì)量好壞是軟件成功的必要條件，一款漏洞百出的軟件，是不可能獲得成功的，沒有任何人會喜歡這樣的軟件。

在軟件的開發(fā)過程中，有兩類人是決定軟件開發(fā)質(zhì)量的，這兩類人是開發(fā)人員和測試人員。這兩類人必須緊密配合，充分合作，才能一起開發(fā)出完美的軟件。兩者之間在一個軟件開發(fā)過程中，按照如下的關(guān)系緊密結(jié)合在一起：

開發(fā)人員提交軟件 --> 測試人員發(fā)現(xiàn)問題 --> 開發(fā)人員修改 --> 又發(fā)現(xiàn)新的問題 --> 繼續(xù)修改 --> …… --> 所有發(fā)現(xiàn)的問題都解決掉 -->發(fā)布。

上面這個過程，從某種意義上也可以這么理解：創(chuàng)造BUG --> 發(fā)現(xiàn)BUG --> 解決BUG。

從上面的流程可以看到，任何BUG都是因為開發(fā)人員代碼有缺陷造成的。只有沒找到重現(xiàn)方法的BUG，絕對沒有所謂的“靈異”BUG。開發(fā)人員代碼質(zhì)量越高，BUG就會越少，即使有BUG也容易找到；反之代碼質(zhì)量越低，BUG就會越多，也會越“靈異”。因此當發(fā)現(xiàn)一個所謂的“靈異”BUG的時候，測試人員可以要求開發(fā)人員仔細檢查自己的代碼是否有缺陷；當然開發(fā)人員也應(yīng)該主動去看自己的代碼是否有缺陷。

1.2. 測試人員的職責

測試人員是軟件的守護者，是保證軟件質(zhì)量的最后一道防線。

測試人員的職責，不但要發(fā)現(xiàn)BUG，更重要的發(fā)現(xiàn)這個BUG的重現(xiàn)方法，不能重現(xiàn)的BUG，對開發(fā)人員來說價值是不大的。事實證明，絕大多數(shù)所謂的“靈異”BUG，最終都能找到重現(xiàn)的方法。對于一個BUG來說，只要找到重現(xiàn)的方法，意味著這個BUG已經(jīng)得到解決了。

發(fā)現(xiàn)一個“靈異”BUG，并找到可重現(xiàn)的路徑，是一件極具挑戰(zhàn)的工作，也是一件相當有技術(shù)含量的事。你沒有看錯，是相當?shù)挠屑夹g(shù)含量，甚至比做開發(fā)更需要專業(yè)知識和技巧。從某些角度看，測試的工作和破案有點類似，都是在蛛絲馬跡中找到某些必然的因素，然后讓看似雜亂無章的東西變得清晰、有序，最終找到解決辦法。然而目前的現(xiàn)狀是，整個行業(yè)中大多數(shù)的軟件企業(yè)，并沒有意識到這一點，項目的負責人乃至測試工程師自己都往往認為測試是一件體力活，他們認為只要時間、人手投入進去，就一定能達到預(yù)期效果，其實不然。沒有正確的價值觀引導(dǎo)和測試方法的提升，本來有技術(shù)含量的測試工作就會做成體力活，吃力不討好。

在一個項目過程中，測試人員相當于一款產(chǎn)品最后把關(guān)的人員，是非常重要的。因此一個好的測試人員，一定要自信，要據(jù)理力爭。

BUG雖然靈異，但找BUG的過程仍然有一些規(guī)律可循，總有一些方法可以借鑒，因此本文將討論一下測試的方法論。

1.3. 測試和開發(fā)的關(guān)系

正如一個優(yōu)秀的開發(fā)人員，應(yīng)該具備一些測試方面的知識和能力；一個優(yōu)秀的測試人員，同樣需要了解一些開發(fā)方面的知識。

沒有測試方面知識和能力的開發(fā)人員，開發(fā)出來的軟件一定會有比較多的BUG，甚至會有很嚴重的BUG，這些BUG可能需要很長時間才能修復(fù)；反之有一定測試知識和能力的開發(fā)人員，開發(fā)出來的軟件就不會有很多BUG，更不會有嚴重的BUG，即使有了BUG也一定能很快地修復(fù)掉。

沒有開發(fā)方面知識的測試人員，在測試的時候同樣不能找出太多的BUG，即使找到BUG也往往無法重現(xiàn)；反之有一定開發(fā)能力的測試人員，在測試過程中就能找到比較多的BUG，而且能找到BUG的重現(xiàn)方法。

開發(fā)人員在學習測試知識，提升測試能力的時候，同時開發(fā)能力也一起得到提升；測試人員在學習開發(fā)知識，提升開發(fā)能力的時候，同樣測試能力也會得到提高。開發(fā)人員和測試人員應(yīng)該經(jīng)常在一起溝通，互相學習，一起提高。

1.4. 測試的方法論

前文說過，找BUG是有規(guī)律可循的，掌握了正確的方法，就能比較容易地找到BUG和BUG產(chǎn)生的原因。

測試從方法論上講，最根本的就是兩個方法：開，暴露問題；合，分析問題?！豆砉茸印氛J為，一開一合是宇宙萬物變化發(fā)展的普遍規(guī)律，任何事情，都可以通過這兩個方法來分析，解決。用在測試上，可以理解為通過各種各樣的操作、猜測，使軟件的各種缺陷暴露出來；通過歸納總結(jié)，發(fā)現(xiàn)BUG的規(guī)律，找到BUG產(chǎn)生的明確原因，當一個BUG產(chǎn)生的明確原因找到了，BUG也就能解決了。

在接下來的章節(jié)里，將重點講述這兩個方法，只要能充分理解開合的道理，發(fā)現(xiàn)和解決BUG將會變得輕松起來。

2. 開，暴露問題

開的主要目的是使用一切手段發(fā)現(xiàn)問題，只有先發(fā)現(xiàn)了問題，才能找到問題的所在，最終解決問題。開，主要有以下事情要做，那就是：

◆ 懷疑一切

◆ 換位思考（模擬用戶行為）

◆ 創(chuàng)造條件，把問題放大

2.1. 懷疑一切

開講得是廣度，在這里沒有什么是不可能的，本著懷疑一切的態(tài)度去列出任何可能的甚至是不可能的情況。在此時，要假設(shè)拿到手的軟件就是一個垃圾，一無是處，而你的任務(wù)就是去蹂躪這個軟件，用所有想得到的手段暴露出這個軟件的所有弱點?；旧蟻碚f，懷疑的越多，越容易發(fā)現(xiàn)軟件的缺陷。有些BUG之所以很難重現(xiàn)，很大程度上就是因為沒有懷疑足夠多的東西，有些路徑?jīng)]有走到。

測試之前，肯定都會先寫測試用例。對于每一種類型的軟件，總有和這種類型相匹配的一些重點嫌疑對象，這些重點嫌疑的東西，要重點測試。Windows上的所有帶有用戶界面的軟件，都是事件驅(qū)動的。大多數(shù)軟件，驅(qū)動者就是操作軟件的用戶；但對于一些網(wǎng)絡(luò)的軟件，例如IM軟件，驅(qū)動者除了用戶的操作之外，還有一個更重要，也是比較容易被忽視的就是網(wǎng)絡(luò)數(shù)據(jù)的驅(qū)動。有些問題，雖然是在通過鼠標操作時候發(fā)生了某些異常，但實際上可能是這段時間內(nèi)收到了某些網(wǎng)絡(luò)數(shù)據(jù)，出發(fā)某個流程，出了異常。所以這個時候就要盡可能多懷疑一些情況，然后分別進行有針對性的測試。懷疑的對象越多，離真正的結(jié)果就越近。

懷疑一切，要敢于去懷疑，大膽地懷疑，只有想不到因素，沒有測不出來的BUG，更沒有重現(xiàn)不出來的BUG。

2.2. 模擬用戶的行為

測試歸根到底是模擬用戶的行為，替用戶把各種可能的操作都做了，把各種問題都提前暴露出來，然后反饋到開發(fā)人員手里，修改掉。

在模擬用戶行為的時候，不但要模擬用戶正常的行為，更要模擬用戶不正常的行為，因為用戶完全可能做出一些意想不到的動作。某些流程在開發(fā)的時候已經(jīng)設(shè)定好，只要按照這個流程操作，絕對不會出問題。然而到了用戶手中，用戶的某些操作，完全可能改變流程的方向，從而導(dǎo)致軟件產(chǎn)生異常。因此模擬用戶的操作是極其重要的。

模擬用戶操作，需要做到覆蓋全面。例如一個窗口在正常狀態(tài)沒有問題，但如果在窗口最小化的時候，或者正在拖動的時候，有某些事情發(fā)生，是否可能會出問題？類似這種情況，都是應(yīng)該考慮在內(nèi)的。

模擬用戶操作，還需要模擬用戶端個各種條件，包括軟件條件和硬件條件。

用戶行為的各種可能性，可以按照不同種類列出來，然后互相組合，一一進行測試。下圖是一個IM產(chǎn)品聊天窗口的用戶行為示意圖：

上圖看似復(fù)雜，而且是一個乘法的關(guān)系，很容易被嚇到，但實際上即使全部條件算上，基本上也還是一個可控制的范圍，全部走一遍是可以做到的。

當然，實際的應(yīng)用中，可能比這個要更復(fù)雜一些，這時候可以使用表格列出各種條件，互相組合起來測試，問題總會暴露出來。

曾經(jīng)有過一個BUG，是關(guān)于聊天窗口布局錯亂的問題，現(xiàn)象是在某些情況下，聊天窗口里的部分窗口看不見了，或者只顯示半個。測試人員和開發(fā)人員一起做了無數(shù)的嘗試，結(jié)果仍然是絕大多數(shù)情況下沒問題，只是偶爾能出現(xiàn)布局錯亂的問題。最終問題是一次偶然的操作中找到的，當聊天窗口最小化的時候，收到了對方文件傳輸?shù)恼埱螅@時窗口布局必然錯亂。這個BUG原來是可以必現(xiàn)的。

通過這個BUG，我們可以看出，雖然大家合力做了無數(shù)的嘗試，卻唯獨沒有考慮到當窗口最小化時候，收到文件傳輸請求的情況，真是百密一疏。舉一反三，我們可以看到，在別的某些情況下，仍然可能出現(xiàn)考慮不全面的現(xiàn)象。因此可以按照聊天窗口用戶行為示意圖中的方法，把各環(huán)節(jié)抽象出來，一一搭配組合去構(gòu)思測試用例，進行測試。只要把各環(huán)節(jié)可能出現(xiàn)的操作都列全了，基本上能覆蓋用戶的所有操作，從而也能發(fā)現(xiàn)更多的問題。

2.3. 創(chuàng)造條件，把問題放大

很多BUG，只有在一些極端的情況下才會出現(xiàn)，因此就需要主動創(chuàng)造一些條件，是BUG暴露出來。也有一些BUG，只有在滿足合適的條件下才會出現(xiàn)，也需要認為創(chuàng)造這些條件，才可以把問題放大，從而使問題比較容易暴露出來。

簡單的說，本小節(jié)可以這樣描述：

◆ 電腦速度慢？讓它更慢

◆ 數(shù)據(jù)庫太大，導(dǎo)致速度變慢？讓數(shù)據(jù)庫更大

◆ 網(wǎng)絡(luò)速度太慢？不穩(wěn)定？讓它更慢，更不穩(wěn)定

◆ ……

總之，可以千方百計創(chuàng)造條件，讓問題都暴露出來。

有時候可以通過使用一些工具，或自己開發(fā)一些工具，來幫助創(chuàng)造條件。

有時候，如果能通過閱讀代碼，有針對性地創(chuàng)造條件，會達到事半功倍的效果，這是后話，在今后的白盒測試篇另行描述。

3. 合，分析問題

運用了開的方法，很多問題已經(jīng)暴露出來了并且找到問題所在了，但總有一些BUG雖然出現(xiàn)過，但卻找不到重現(xiàn)的方法，這種問題一般被稱為靈異現(xiàn)象，因此需要用合的方法，找出這些問題產(chǎn)生的規(guī)律，以便解決問題。

在測試中，合的目的，是在已經(jīng)找到了BUG的情況下，再找到重現(xiàn)BUG的方法，幫助開發(fā)人員解決問題。從某種意義上講，合有時候比開更為重要，如果只有開沒有合，就會產(chǎn)生一些所謂的“靈異”BUG，只知道有問題，而不知道為什么會有問題。開需要有嚴密的思維，而合則需要有冷靜的頭腦和敏銳的眼光。一個優(yōu)秀的測試人員，必須掌握這個技能。

3.1. 沒有“靈異”BUG

這一條沒有任何技巧，只是需要大家堅持一個觀點，就是沒有什么BUG是靈異的，只有沒找到重現(xiàn)方法的BUG，沒有靈異BUG。無論是測試人員還是開發(fā)人員都必須相信這一點。

BUG之所以靈異，只是因為這個BUG產(chǎn)生的條件比較深，不容易被人發(fā)現(xiàn)。所以“合”的目的，就是要總結(jié)出這些“靈異”BUG的產(chǎn)生條件，變復(fù)雜為簡單，使靈異事件消失，成為一個可以必現(xiàn)的BUG。

3.2. 使用工具，事半功倍

一般情況下，除了測試工程師常用的工具之外，還有一些開發(fā)常用的工具，也可以在測試的時候使用。下面列出一些常見的，必備的工具。

3.2.1. Spy++

Spy++是微軟在Visual Studio中提供的一個工具。通過Spy++，可以看到Windows里所有的窗口，以及這些窗口的信息。通過這個工具，可以找到一些BUG的真相，例如有這樣一個BUG：

13091. 短信平臺：斷線重連后，任務(wù)欄中出現(xiàn)兩個莫名的旺旺圖標

這個BUG似乎比較奇怪，而且可能是和短信平臺有關(guān)。但實際上，我們知道，如果任務(wù)欄上出現(xiàn)一個圖標，那一定是會有一個窗口存在的，因此就可以用Spy++看一下，究竟是什么窗口。使用Spy++看過之后，會發(fā)現(xiàn)真實情況是，天氣預(yù)報窗口由于某些原因跑到桌面上去了，其實這個BUG和短信是沒有關(guān)系的，只是正好在操作短信的時候發(fā)生了。

3.2.2. Depends

Depends也是微軟在Visual Studio中提供的一個工具，用來查看EXE，DLL等的依賴關(guān)系，最新版的Depends還可以動態(tài)地查看程序啟動時候用到了什么DLL，以及每個DLL在什么地方。

3.2.3. 遠程調(diào)試服務(wù)工具

經(jīng)常有一些BUG，在測試人員的電腦上能重現(xiàn)，但在開發(fā)的電腦上卻無法重現(xiàn)，這時候就需要用到遠程調(diào)試。因此測試人員最好能準備一個遠程調(diào)試服務(wù)的工具，方便開發(fā)人員調(diào)試。

當然，如果能裝個VC，就更好了，^_。

裝了VC，有好處也有壞處。好處是調(diào)試方便，壞處是裝了VC，或許會破壞系統(tǒng)的一些條件，使電腦和用戶的電腦差異加大，反而可能有些BUG會測不出來。

3.2.4. 關(guān)于工具

除了上面列出的工具，還有其他很多工具都可以提高效率。平常工作中可以多留意，多收集一些工具。

一般當你認為某件事情干起來很麻煩，很費力的時候，就應(yīng)該去找一下有沒有類似的工具。因為這件事情如果你認為干起來很麻煩，別人一定也會覺得很麻煩，如果覺得麻煩的人多了，就一定會有解決這種問題的工具出現(xiàn)，所以一般情況都是可以找到工具的。

如果實在找不到，可以請開發(fā)的同事在有時間的時候幫忙做一個，如果不是很難的話，一般開發(fā)的同事都會樂于做這樣的工具的。

3.3. 排除絕不可能的因素

“除去不可能的剩下的即使再不可能，那也是真相。”

---- 夏洛克.福爾摩斯

這是福爾摩斯經(jīng)常說的一句話，這句話用在測試上非常具有指導(dǎo)意義。

線索太多的時候，會產(chǎn)生干擾，因此必須要適當?shù)膾仐壱恍┮蛩亍０岩恍╋@然不可能的和因素過濾掉，再把可以證明是不可能的因素也過濾掉，那么真相一定會在剩下的線索中。只要著重對剩下的線索進行分析、研究，一定可以找到真相。

在軟件中，一般很少會出現(xiàn)兩條以上線索共同起作用的情況，如果真的是兩條線索都起作用，那說明這個軟件寫的實在是有點問題。所以當排除掉一些絕不可能的因素和被證明不可能的因素之后，對于剩下的線索，一條一條地去試。每試一條線索的時候，可以假設(shè)剩下的線索沒有問題。一條不行再換另一條再試，所有線索都試過，BUG的產(chǎn)生原因基本上也找出來了。

當然，所謂絕對不可能這個說法是不準確的，在軟件里面，完全絕對是不可能的。所以這里的絕對不可能，應(yīng)該是說在某些條件下相對的不可能。

這里列出一些常見的“絕對”不可能的因素，僅供參考

3.3.1. 進程之間的相互影響

絕大多數(shù)情況下，除非特別設(shè)計，否則兩個進程之間是不會互相影響的（當然有極個別情況也還是可能會有影響的）。因此在測試過程中，很多兩個進程之間互相切換，或者窗口互相遮蓋時候出現(xiàn)的問題，基本上是可以排除兩個進程之間的影響。有的BUG發(fā)生的時候，正好兩個進程的窗口互相遮蓋，這時候基本上不用懷疑兩個進程互相影響，真相九成九是因為在窗口互相遮蓋的時候，正好發(fā)生了別的事情。

3.3.2. 正常拖動窗口（包括移動窗口位置，改變窗口大?。?/strong>