認清探索性測試

　　原本想把探索性測試(ET)和敏捷測試(Scrum)放在一起談?wù)?，后?lái)想想，兩者需要注意的點(diǎn)還是很不同的，所以先談?wù)撓绿剿餍詼y試吧。

　　現在可能越來(lái)越多的測試開(kāi)始談?wù)揈T，也就是所謂的探索性測試。但是這里我想說(shuō)的是，不要盲目依賴(lài)ET，也不要不清晰的去認知ET。需要了解其真正的意義然后根據自己的實(shí)際情況做相應的改變才是上策。

　　首先不要理解ET就是Free Style，就是所謂的隨機測試。所謂探索和自由的測試，隨機測試還是有差別的。探索是有很多方法支持，并不是漫無(wú)目的的隨便針對軟件測試。這里舉兩個(gè)例子，比如A心中想著(zhù)一個(gè)數字讓B猜測，B每猜一個(gè)數字，A會(huì )告訴B是比心中想的數字大了還是小了。最終B會(huì )準確的猜出A心中所想的數字。再比如你去超市shopping，除了你直接有目的性的之外，大部分情況都是會(huì )先進(jìn)行物品的挑選，無(wú)論是種類(lèi)，還是價(jià)格的比較，最終挑選出符合你想要的那個(gè)商品。這個(gè)兩個(gè)例子雖然在我們生活中一直發(fā)生，但是卻就是最原始的一種探索性測試。這里不得不提的就是聯(lián)系上下文的測試，兩個(gè)例子都是根據上下文進(jìn)行一種探索，最終達到了自己的一個(gè)目的。

　　再來(lái)我想談一下怎么施行ET，或者說(shuō)怎么權衡ST和ET。經(jīng)過(guò)ChinaTest以及之后的幾場(chǎng)沙龍，我發(fā)現很多測試的問(wèn)題都是圍繞在這樣幾個(gè)點(diǎn)上面。

　　我想在談?wù)撨@些問(wèn)題前先理清楚幾個(gè)概念：

　　1.ST和ET絕對沒(méi)有哪個(gè)是通用工具，都不可能一條路走到底

　　2.計劃永遠趕不上變化，我們的測試必須根據實(shí)際情況靈活改變

　　3.任何的測試都應該基于風(fēng)險評估

　　4.任何的測試都應該根據上下文來(lái)實(shí)施

　　5.ST中的所有的步驟在ET中都是需要去做到，唯一不同的只是我們可能會(huì )簡(jiǎn)化某些步驟，而達到更高的效率。

　　6.測試活動(dòng)是一個(gè)長(cháng)期的活動(dòng)，是一個(gè)循序漸進(jìn)的過(guò)程。

　　那么接下來(lái)我先來(lái)說(shuō)一下怎么實(shí)施ET。個(gè)人認為ET本身的方法很多，其實(shí)就實(shí)施而言，我們根據自己產(chǎn)品項目的具體情況然后有針對性的進(jìn)行ET。這里可能在執行的過(guò)程中大部分會(huì )碰見(jiàn)的一些問(wèn)題如下：

　　1.公司或者測試團隊如何先踏出第一步

　　我覺(jué)得首先如果你是一個(gè)leader或者manager，你想推ET自己先得想清楚推的過(guò)程中的一些框架，如何推，如何考評，如何引導大家去做等。然后再走，否則可能會(huì )造成一團亂的局面。你可以選擇和公司上層直接進(jìn)行溝通表達測試團隊可能接下來(lái)會(huì )引入一種新的測試方法。如果你的上層并不能那么容易就能夠說(shuō)服的話(huà)，那么你可以先抽幾個(gè)骨干在有空的時(shí)候進(jìn)行一些ET，將結論總結好然后再去和上層交涉，那么我相信絕對更加有說(shuō)服力。而對于測試團隊來(lái)講，應該進(jìn)行相應的概念和方法的培訓，讓測試團隊充分的了解ET和ST的區別，ET的優(yōu)缺點(diǎn)分別是什么，我們?yōu)槭裁匆脒@樣的方法等。至少以上這些是你要進(jìn)行ET前必須要做的事情。

　　2.每個(gè)測試人員的經(jīng)驗能力各不相同，ET之后就自由了好多，如何在風(fēng)險可控范圍內有效的進(jìn)行ET，如何考評呢?

　　這里我有一個(gè)初步的原創(chuàng )的方案。確實(shí)，這個(gè)問(wèn)題幾乎在每個(gè)公司都會(huì )存在。而我主張在初期ET必須被引導。而這種引導又必須是老測試人員或者資深的測試來(lái)做。我在一個(gè)月前使用過(guò)如下的方法。我將每次ET的活動(dòng)都定成一個(gè)Test Task，其中高風(fēng)險的全部由測試leader主動(dòng)分配給測試人員，低風(fēng)險的由測試人員自己去認領(lǐng)。每個(gè)Task中都會(huì )寫(xiě)明ET的目的，范圍，時(shí)間等。最終根據每個(gè)測試人員對于高低風(fēng)險Task的完成量，完成時(shí)間，完成質(zhì)量進(jìn)行相對應的考評。這樣也很有說(shuō)服性。

　　另外，如果時(shí)間充裕，那么進(jìn)行交叉的ET也是非常有效率的一種方式。無(wú)論是新測試還是老測試，每個(gè)人都會(huì )有測試盲點(diǎn)。那么交叉測試既能夠保證ET的覆蓋面的同時(shí)也會(huì )給測試帶來(lái)更多的想法，靈感。

　　在每個(gè)項目發(fā)布前的一段時(shí)間最好能夠組織全公司或者全team進(jìn)行bug bash。每次bash時(shí)間一般在3個(gè)小時(shí)。我以前公司每次都會(huì )做。這種活動(dòng)可以看作為全員在做測試，相信這樣一輪下來(lái)肯定會(huì )發(fā)現很多之前沒(méi)有發(fā)現的問(wèn)題。對于實(shí)施ET之后的項目也很有幫助。

　　3.ET要寫(xiě)測試用例么?怎么寫(xiě)?回歸測試怎么做?發(fā)現了bug之后應該做什么處理。

　　這個(gè)我覺(jué)得ET的測試用例更加像一種思維導圖，或者思維引導。并沒(méi)有具體的形態(tài)，每家公司情況都不同。但是我們需要記錄的是一種思維，并非一種特定的現象(如果測試步驟和測試結果一直不變，比如數據庫的測試，比如一些對話(huà)框的測試，那么可以將他們列入ST，也可以在ET的思維導圖中標注一下)ET所需要的其實(shí)就是一種經(jīng)驗，一種思維，告訴測試引導測試應該從什么測試點(diǎn)入手，可能會(huì )在某些情況下發(fā)生問(wèn)題。在2中我提到的Task中測試leader就必須寫(xiě)清楚測試切入點(diǎn)，可能出現的問(wèn)題點(diǎn)，這樣一來(lái)降低了因為測試人員能力不同 而導致的風(fēng)險，二來(lái)同時(shí)也引導了新的測試人員，將經(jīng)驗很好的傳達給了他們。

　　回歸測試的話(huà)，我覺(jué)得可以通過(guò)回歸bug來(lái)達到相應的目的?；蛘咭部梢詫⒏唢L(fēng)險的功能歸類(lèi)總結出ST的TC，然后作為回歸測試來(lái)執行。

　　ET發(fā)現bug之后我認為首先你需要報這個(gè)問(wèn)題，其次就是要記錄到你或者整個(gè)團隊的思維導圖這樣一個(gè)庫中。它是一種思路，以便于引導下次測試該模塊的測試人員。

　　那么最后我來(lái)談一下怎么權衡ST和ET，正如我之前提到的幾點(diǎn)需要清楚的地方。那么下面舉幾個(gè)例子，我相信你就會(huì )明白。

　　假設你對于你的團隊信心不是很大，并且對于產(chǎn)品本身的質(zhì)量抱有一定的質(zhì)疑。那么你需要將高風(fēng)險的功能點(diǎn)總結出來(lái)，然后進(jìn)行測試用例的編寫(xiě)。那么這部分的功能就是主要以ST為主，ET為輔的方式進(jìn)行確保。而其余的功能你可以一半時(shí)間使用ST，一半時(shí)間使用ET。其思路就是ST保證高風(fēng)險功能點(diǎn)以及產(chǎn)品的各個(gè)基本功能點(diǎn)，至少產(chǎn)品經(jīng)過(guò)ST之后不會(huì )產(chǎn)生P1的問(wèn)題。同時(shí)結合ET，讓產(chǎn)品從UE、UI等各個(gè)ST可能無(wú)法覆蓋到得方面進(jìn)一步進(jìn)行保證。

　　假設你對于你的團隊和產(chǎn)品的態(tài)度還是有那么點(diǎn)信心的。那么你就可以使用ET為主，ST為輔的方式。同樣的這樣會(huì )加快團隊使用ET的經(jīng)驗。ST同樣是為了保證基本功能點(diǎn)以及一些固定數據的測試點(diǎn)，而更多時(shí)間的ET是能夠在短時(shí)間內更多的發(fā)現產(chǎn)品的缺陷，從而達到測試的目的。

原文轉自：http://www.testdao.com/article-320-1.html