一、測試大數(shù)據(jù)應(yīng)用現(xiàn)狀分析

軟件測試積累了大量數(shù)據(jù)，直覺上，應(yīng)該有可能把這些數(shù)據(jù)存在的規(guī)律、知識、模式發(fā)掘出來，反過來指導(dǎo)軟件測試工程實踐。這已經(jīng)成為業(yè)界共識，而且不少人也從多年前就開始了相關(guān)研究工作，建立了不少測試樣例庫、故障庫，甚至還有更全的庫。但是到底從這些數(shù)據(jù)中發(fā)現(xiàn)了哪些有意思（我們以前沒有意識到的）的知識、模式、規(guī)律，這些課題組總是閃爍其辭，我的理解，就是沒有值得一提的東西。我見到的所謂大數(shù)據(jù)應(yīng)用結(jié)果，大多都是些宏觀的分類統(tǒng)計，確切地說，連決策支持（DSS）的水平都算不上，與人們對大數(shù)據(jù)應(yīng)用的期望相差甚遠，對具體的新的軟件測試項目設(shè)計的作用不大。

我想出現(xiàn)這種狀況一定是有地方出了問題，我想嘗試梳理一下。

首先，軟件測試大數(shù)據(jù)應(yīng)用必須提出工程應(yīng)用需求，第二，工程需求抽象、轉(zhuǎn)換為科學(xué)問題，第三，通過科學(xué)工具，包括數(shù)學(xué)工具，建模工具等解決科學(xué)問題。

比如機器人、通信協(xié)議的測試，可以把應(yīng)用抽象為米莉機，就是輸入、輸出和狀態(tài)都是有限的自動機，且任意時刻只處于一種狀態(tài)中，狀態(tài)的遷移只取決于當前狀態(tài)和輸入。另一些應(yīng)用的測試則可以抽象為摩爾機，即狀態(tài)轉(zhuǎn)換只依賴于輸入。接下來，通過算法尋找米莉機的同步序列或歸位序列，作為測試用例，驗證系統(tǒng)可以進入的最終狀態(tài)，或是其他預(yù)期行為。

類似地，我們期望通過軟件測試數(shù)據(jù)的處理得到什么呢？我聽得最多的就是測試用例推薦，當然這也是其他領(lǐng)域大數(shù)據(jù)應(yīng)用的目前熱點之一，互聯(lián)網(wǎng)上已經(jīng)有很多了，主要是各種商品和服務(wù)的針對性推薦。

那我們不妨想一想，我們自己學(xué)習(xí)軟件測試的過程，是不是僅僅觀察很多以前的測試用例或是軟件問題報告呢？顯然不是。對于我們這種基于需求測試模式為主的測評實驗室來說，從需求映射為測試用例的技巧才是學(xué)習(xí)的關(guān)鍵，也是評價一個測試員能力水平的重要方面。好的測試員為什么優(yōu)秀？主要體現(xiàn)在對具體需求的理解，能夠結(jié)合自己的經(jīng)驗、常識甚至直覺，提出滿足測試目標的合理的測試用例。當然，不同的測試級別對知識的要求層次差別還是很大的。根據(jù)一般的測試模型，測試級別越高，測試目標越具體。比如級別低的單元測試，只需要理解要完成的具體功能，與具體的應(yīng)用沒有很大的關(guān)系，因而比較容易抽象出通用的測試經(jīng)驗，甚至自動化。相反，系統(tǒng)測試強烈依賴特定的軟件應(yīng)用場景，類似的軟件用在不同的場景中，會要求差別很大的測試設(shè)計。

軟件在人們的生活中發(fā)揮著這樣重要的作用，因此保證軟件質(zhì)量是至關(guān)重要的。測試是驗證任何產(chǎn)品質(zhì)量的過程。舉一個紡織工業(yè)的例子：購買布匹時，我們期望布匹禁用，尺寸合適，不易掉色。在銷售布匹之前，銷售者有責(zé)任測試布匹的這些基本性質(zhì)，換句話說，銷售者要對布匹的質(zhì)量負責(zé)。

二、測試大數(shù)據(jù)應(yīng)用推進難點

我認為更為抽象的單元測試對于測試用例推薦，一般來說更容易。但是單元測試主要還是由軟件研制單位完成，因此單元測試的用例推薦對軟件測評實驗室價值不高。對于大數(shù)據(jù)應(yīng)用來說，單元測試用例推薦可能是比較好的起點，關(guān)注服務(wù)對象主要是軟件研發(fā)單位。

同時，軟件單元測試與其他測試級別相比也是最成熟的，目前唯一有效的軟件測試國際標準就是單元測試標準，針對單元測試的自動化、半自動化工具也是最豐富的，在軟件測試目前已有的四種主要方法中，包括基于規(guī)則的動態(tài)分析、基于測試數(shù)據(jù)輸入的動態(tài)測試、基于符號運算的運行時檢查、基于模型的軟件邏輯正確性驗證等，也是運用最成功的，因此大數(shù)據(jù)要想給出一些更具啟發(fā)性的推薦也是比較困難的，但是如果大數(shù)據(jù)能夠更深入地結(jié)合被測軟件單元的結(jié)構(gòu)信息，換句話說，大數(shù)據(jù)不僅要使用從單元測試數(shù)據(jù)中提取的模式信息，還要使用具體被測軟件的結(jié)構(gòu)或設(shè)計信息，推薦有價值測試用例的可能性更大。特別地，針對某些單元測試難度比較大的子問題，比如中斷處理、變量定義/使用路徑驗證等的測試，獲得突破的可能性更大一些?？傊嫦虻膯栴}域越寬，給出高價值測試用例的可能性越低。我想大數(shù)據(jù)的發(fā)展策略應(yīng)該是從特殊到一般。以往軟件測試大數(shù)據(jù)應(yīng)用效果不佳，我覺得很可能與開發(fā)策略有關(guān)。

不少人對我說，軟件測試大數(shù)據(jù)應(yīng)用效果不佳的主要原因是數(shù)據(jù)不夠多，暗示只要測試數(shù)據(jù)足夠多大數(shù)據(jù)應(yīng)用的效果必然改善，盡管誰也說不清多少數(shù)據(jù)才算足夠。我對這個想法深表懷疑。舉個例子，大數(shù)據(jù)也好、數(shù)據(jù)庫知識發(fā)現(xiàn)也好、人工智能、機器學(xué)習(xí)、模式識別等也好，當取得了一些重要突破后，無一例外地都把應(yīng)用目標轉(zhuǎn)向股市和類似的領(lǐng)域。直覺上這些技術(shù)應(yīng)該在股市上有所作為，因為股市數(shù)據(jù)量不可謂不大，數(shù)據(jù)中的模式不可謂不多，已有的傳統(tǒng)分析方法運用也幾乎到了極致。但是事實是，即使是紅得發(fā)紫的阿爾法狗也在中國股市潛水多時后黯然離開。從地球奔向月球是美好愿望，但是必須得有合適方法，你對自行車再挖空心思地改造，也永遠不會把你帶到月球。我想大數(shù)據(jù)也是一樣。如果軟件測試領(lǐng)域的復(fù)雜度可以與股市比較，再對著自行車費心思就大可不必了。關(guān)鍵是降低問題域的寬度和難度，大而化之的所謂軟件測試大數(shù)據(jù)應(yīng)用，我認為目前是不可行的。

三、測試大數(shù)據(jù)應(yīng)用解決方向

軟件測試的主要工作，是把軟件需求映射為軟件測試。大數(shù)據(jù)應(yīng)用也可以表述為輔助測試人員，直至自動完成這個映射，大數(shù)據(jù)能力的表征也體現(xiàn)在對測試人員的輔助、啟發(fā)效果。如果給出的推薦是測試人員沒有想到，而且對測試具有重要性，則得正分；如果推薦是重復(fù)性的，比如被其他測試用例包含，則得零分；如果推薦沒有可行性或必要性，甚至對測試人員的設(shè)計產(chǎn)生干擾，則得負分。這種獎勵/懲罰機制可以構(gòu)成大數(shù)據(jù)自我學(xué)習(xí)、進化的基礎(chǔ)。

這個機制與測試人員的成長類似。測試大綱寫好后經(jīng)過內(nèi)部評審和外部評審，經(jīng)過幾輪迭代不斷完善。在理想情況下，測試人員會汲取教訓(xùn)和經(jīng)驗，同類問題出現(xiàn)概率越來越小。把這個測試設(shè)計進化過程送給大數(shù)據(jù)，即同一個項目的多個測試設(shè)計，以版本高低順序排序輸入給大數(shù)據(jù)，呈現(xiàn)出完整進化過程，可以是大數(shù)據(jù)的一個起點。因為測試設(shè)計在評審中被提出修改意見的落實結(jié)果，本質(zhì)上就是一種推薦，而且是正分推薦。

不過問題遠沒有這么簡單。測試設(shè)計評審，實際上也是評審?fù)斜硨Ρ车剡M行從測試需求到測試設(shè)計的映射，并把自己的映射與被評審的測試設(shè)計產(chǎn)品進行比對，發(fā)現(xiàn)產(chǎn)品不足的過程，僅僅了解測試設(shè)計改進情況，而不知道為什么需要進行這些改進，很難獲得實質(zhì)性的經(jīng)驗。因此大數(shù)據(jù)了解測試需求等依據(jù)，理解測試設(shè)計多個版本的映射差異，對于大數(shù)據(jù)的模式發(fā)現(xiàn)來說可能是不可避免的。

于是下面的問題就變成大數(shù)據(jù)如何對測試需求進行理解。我聽到不少人說，測試需求的理解通過自然語言處理解決，因為現(xiàn)實世界的測試需求主要以自然語言描述的形式給出。實際上，對測試需求的理解本身對測試人員的能力要求就是很高的，很少有測試人員僅僅根據(jù)測試需求文檔就能很好理解被測軟件的，與軟件研發(fā)人員的溝通是很難避免的。這意味著大數(shù)據(jù)還要理解不同階段的軟件設(shè)計文檔、甚至系統(tǒng)設(shè)計文檔、項目技術(shù)方案、立項論證報告等等相關(guān)文件。即使這些條件都具備，通用的測試需求大數(shù)據(jù)理解也是非常困難的，可能降低難度的方向，應(yīng)該是限定軟件類型、使用領(lǐng)域等，達到一般測試人員的平均理解水平還是有可能的。

在測試需求大數(shù)據(jù)理解上，我覺得還有兩個問題很難回避，一個是需求文檔中的圖表，一個是預(yù)期的測試環(huán)境初步想定。

圖表對于測試人員對測試需求的理解至關(guān)重要，大數(shù)據(jù)直接理解圖表中給出的豐富語義信息、結(jié)構(gòu)信息、拓撲信息，我想還是有很大困難的。如果需要人工把圖表進行自然語言轉(zhuǎn)換，即使是能夠做到，對大數(shù)據(jù)的實際使用也會是個很大制約。如果這個問題沒有一個足夠滿意的解決方案，我想大數(shù)據(jù)對于軟件測試可能弄不好就是那個自行車了。

測試需求到測試設(shè)計的映射還有一個重要條件，就是測試環(huán)境的初步想定，而測試環(huán)境又是在映射過程中逐步確定的。一般來說，測試需求決定測試環(huán)境，測試環(huán)境影響測試需求。但是測試環(huán)境的確定還受到很多技術(shù)、管理、成本、進度、可用資源等多方面的制約，可能需要比較復(fù)雜的綜合考慮，既要考慮測試的充分性、有效性，還要考慮測試工程的可行性。而且測試環(huán)境的確定常常是一個逐步迭代的過程，測試任務(wù)的不同，使得通常不存在一個具體的理想目標測試環(huán)境模型。而如果要把測試環(huán)境作為測試設(shè)計大數(shù)據(jù)推薦的一部分，可能難度很大，因為測試大綱不同版本本身可能就包含測試環(huán)境的演化?？赡艿慕鉀Q辦法是優(yōu)先確定測試環(huán)境，雖然這對測試人員來說也不是完全不能接受，但畢竟是對大數(shù)據(jù)的一個重要制約。

歡迎各位大佬提出意見見解，留言區(qū)等你哦！