認清探索性測試
原本想把探索性測試（ET）和敏捷測試（Scrum）放在一起談論，后來想想，兩者需要注意的點還是很不同的，所以先談論下探索性測試吧。
現在可能越來越多的測試開始談論ET，也就是所謂的探索性測試。但是這里我想說的是，不要盲目依賴ET，也不要不清晰的去認知ET。需要了解其真正的意義然后根據自己的實際情況做相應的改變才是上策。
首先不要理解ET就是Free Style，就是所謂的隨機測試。所謂探索和自由的測試，隨機測試還是有差別的。探索是有很多方法支持，并不是漫無目的的隨便針對軟件測試。這里舉兩個例子，比如A心中想著一個數字讓B猜測，B每猜一個數字，A會告訴B是比心中想的數字大了還是小了。最終B會準確的猜出A心中所想的數字。再比如你去超市shopping，除了你直接有目的性的之外，大部分情況都是會先進行物品的挑選，無論是種類，還是價格的比較，最終挑選出符合你想要的那個商品。這個兩個例子雖然在我們生活中一直發(fā)生，但是卻就是最原始的一種探索性測試。這里不得不提的就是聯系上下文的測試，兩個例子都是根據上下文進行一種探索，最終達到了自己的一個目的。
再來我想談一下怎么施行ET，或者說怎么權衡ST和ET。經過ChinaTest以及之后的幾場沙龍，我發(fā)現很多測試的問題都是圍繞在這樣幾個點上面。
我想在談論這些問題前先理清楚幾個概念：
1.ST和ET絕對沒有哪個是通用工具，都不可能一條路走到底
2.計劃永遠趕不上變化，我們的測試必須根據實際情況靈活改變
3.任何的測試都應該基于風險評估
4.任何的測試都應該根據上下文來實施
5.ST中的所有的步驟在ET中都是需要去做到，唯一不同的只是我們可能會簡化某些步驟，而達到更高的效率。
6.測試活動是一個長期的活動，是一個循序漸進的過程。
那么接下來我先來說一下怎么實施ET。個人認為ET本身的方法很多，其實就實施而言，我們根據自己產品項目的具體情況然后有針對性的進行ET。這里可能在執(zhí)行的過程中大部分會碰見的一些問題如下：
1.公司或者測試團隊如何先踏出***步
我覺得首先如果你是一個leader或者manager，你想推ET自己先得想清楚推的過程中的一些框架，如何推，如何考評，如何引導大家去做等。然后再走，否則可能會造成一團亂的局面。你可以選擇和公司上層直接進行溝通表達測試團隊可能接下來會引入一種新的測試方法。如果你的上層并不能那么容易就能夠說服的話，那么你可以先抽幾個骨干在有空的時候進行一些ET，將結論總結好然后再去和上層交涉，那么我相信絕對更加有說服力。而對于測試團隊來講，應該進行相應的概念和方法的培訓，讓測試團隊充分的了解ET和ST的區(qū)別，ET的優(yōu)缺點分別是什么，我們?yōu)槭裁匆脒@樣的方法等。至少以上這些是你要進行ET前必須要做的事情。
2.每個測試人員的經驗能力各不相同，ET之后就自由了好多，如何在風險可控范圍內有效的進行ET，如何考評呢？
這里我有一個初步的原創(chuàng)的方案。確實，這個問題幾乎在每個公司都會存在。而我主張在初期ET必須被引導。而這種引導又必須是老測試人員或者資深的測試來做。我在一個月前使用過如下的方法。我將每次ET的活動都定成一個Test Task，其中高風險的全部由測試leader主動分配給測試人員，低風險的由測試人員自己去認領。每個Task中都會寫明ET的目的，范圍，時間等。最終根據每個測試人員對于高低風險Task的完成量，完成時間，完成質量進行相對應的考評。這樣也很有說服性。
另外，如果時間充裕，那么進行交叉的ET也是非常有效率的一種方式。無論是新測試還是老測試，每個人都會有測試盲點。那么交叉測試既能夠保證ET的覆蓋面的同時也會給測試帶來更多的想法，靈感。
在每個項目發(fā)布前的一段時間***能夠組織全公司或者全team進行bug bash。每次bash時間一般在3個小時。我以前公司每次都會做。這種活動可以看作為全員在做測試，相信這樣一輪下來肯定會發(fā)現很多之前沒有發(fā)現的問題。對于實施ET之后的項目也很有幫助。
3.ET要寫測試用例么？怎么寫？回歸測試怎么做？發(fā)現了bug之后應該做什么處理。
這個我覺得ET的測試用例更加像一種思維導圖，或者思維引導。并沒有具體的形態(tài)，每家公司情況都不同。但是我們需要記錄的是一種思維，并非一種特定的現象（如果測試步驟和測試結果一直不變，比如數據庫的測試，比如一些對話框的測試，那么可以將他們列入ST，也可以在ET的思維導圖中標注一下）ET所需要的其實就是一種經驗，一種思維，告訴測試引導測試應該從什么測試點入手，可能會在某些情況下發(fā)生問題。在2中我提到的Task中測試leader就必須寫清楚測試切入點，可能出現的問題點，這樣一來降低了因為測試人員能力不同 而導致的風險，二來同時也引導了新的測試人員，將經驗很好的傳達給了他們。
回歸測試的話，我覺得可以通過回歸bug來達到相應的目的?；蛘咭部梢詫⒏唢L險的功能歸類總結出ST的TC，然后作為回歸測試來執(zhí)行。
ET發(fā)現bug之后我認為首先你需要報這個問題，其次就是要記錄到你或者整個團隊的思維導圖這樣一個庫中。它是一種思路，以便于引導下次測試該模塊的測試人員。
那么***我來談一下怎么權衡ST和ET，正如我之前提到的幾點需要清楚的地方。那么下面舉幾個例子，我相信你就會明白。
假設你對于你的團隊信心不是很大，并且對于產品本身的質量抱有一定的質疑。那么你需要將高風險的功能點總結出來，然后進行測試用例的編寫。那么這部分的功能就是主要以ST為主，ET為輔的方式進行確保。而其余的功能你可以一半時間使用ST，一半時間使用ET。其思路就是ST保證高風險功能點以及產品的各個基本功能點，至少產品經過ST之后不會產生P1的問題。同時結合ET，讓產品從UE、UI等各個ST可能無法覆蓋到得方面進一步進行保證。
假設你對于你的團隊和產品的態(tài)度還是有那么點信心的。那么你就可以使用ET為主，ST為輔的方式。同樣的這樣會加快團隊使用ET的經驗。ST同樣是為了保證基本功能點以及一些固定數據的測試點，而更多時間的ET是能夠在短時間內更多的發(fā)現產品的缺陷，從而達到測試的目的。
當然，你不用問我到底在項目中什么時候進行ET，進行ET之后效果貌似不明顯等問題。為什么？因為以上所有的策略都是基于風險能夠評估之后制定出來的。而風險如何評估，需要測試團隊長期對于產品的一種了解，一種數據的積累分析而得出。而風險的高低在項目中又是不斷變化的，所以我們必須在項目中靈活的進行ST和ET的安排 ，而不是說我們定好怎么樣就是怎么樣的。ET也需要經驗的積累，思維的積累，流程的改善等過程，只有經過幾個項目的考驗那么才會看得更加清楚，效果才會顯著。
***希望大家能夠更加理解ET，更好的運用ET，總結出來適合自己公司的ET方法。
