一、測試大數(shù)據(jù)應(yīng)用現(xiàn)狀分析
軟件測試積累了大量數(shù)據(jù)，直覺上，應(yīng)該有可能把這些數(shù)據(jù)存在的規(guī)律、知識(shí)、模式發(fā)掘出來，反過來指導(dǎo)軟件測試工程實(shí)踐。這已經(jīng)成為業(yè)界共識(shí)，而且不少人也從多年前就開始了相關(guān)研究工作，建立了不少測試樣例庫、故障庫，甚至還有更全的庫。但是到底從這些數(shù)據(jù)中發(fā)現(xiàn)了哪些有意思（我們以前沒有意識(shí)到的）的知識(shí)、模式、規(guī)律，這些課題組總是閃爍其辭，我的理解，就是沒有值得一提的東西。我見到的所謂大數(shù)據(jù)應(yīng)用結(jié)果，大多都是些宏觀的分類統(tǒng)計(jì)，確切地說，連決策支持（DSS）的水平都算不上，與人們對大數(shù)據(jù)應(yīng)用的期望相差甚遠(yuǎn)，對具體的新的軟件測試項(xiàng)目設(shè)計(jì)的作用不大。
我想出現(xiàn)這種狀況一定是有地方出了問題，我想嘗試梳理一下。
首先，軟件測試大數(shù)據(jù)應(yīng)用必須提出工程應(yīng)用需求，第二，工程需求抽象、轉(zhuǎn)換為科學(xué)問題，第三，通過科學(xué)工具，包括數(shù)學(xué)工具，建模工具等解決科學(xué)問題。
比如機(jī)器人、通信協(xié)議的測試，可以把應(yīng)用抽象為米莉機(jī)，就是輸入、輸出和狀態(tài)都是有限的自動(dòng)機(jī)，且任意時(shí)刻只處于一種狀態(tài)中，狀態(tài)的遷移只取決于當(dāng)前狀態(tài)和輸入。另一些應(yīng)用的測試則可以抽象為摩爾機(jī)，即狀態(tài)轉(zhuǎn)換只依賴于輸入。接下來，通過算法尋找米莉機(jī)的同步序列或歸位序列，作為測試用例，驗(yàn)證系統(tǒng)可以進(jìn)入的最終狀態(tài)，或是其他預(yù)期行為。
類似地，我們期望通過軟件測試數(shù)據(jù)的處理得到什么呢？我聽得最多的就是測試用例推薦，當(dāng)然這也是其他領(lǐng)域大數(shù)據(jù)應(yīng)用的目前熱點(diǎn)之一，互聯(lián)網(wǎng)上已經(jīng)有很多了，主要是各種商品和服務(wù)的針對性推薦。
那我們不妨想一想，我們自己學(xué)習(xí)軟件測試的過程，是不是僅僅觀察很多以前的測試用例或是軟件問題報(bào)告呢？顯然不是。對于我們這種基于需求測試模式為主的測評實(shí)驗(yàn)室來說，從需求映射為測試用例的技巧才是學(xué)習(xí)的關(guān)鍵，也是評價(jià)一個(gè)測試員能力水平的重要方面。好的測試員為什么優(yōu)秀？主要體現(xiàn)在對具體需求的理解，能夠結(jié)合自己的經(jīng)驗(yàn)、常識(shí)甚至直覺，提出滿足測試目標(biāo)的合理的測試用例。當(dāng)然，不同的測試級(jí)別對知識(shí)的要求層次差別還是很大的。根據(jù)一般的測試模型，測試級(jí)別越高，測試目標(biāo)越具體。比如級(jí)別低的單元測試，只需要理解要完成的具體功能，與具體的應(yīng)用沒有很大的關(guān)系，因而比較容易抽象出通用的測試經(jīng)驗(yàn)，甚至自動(dòng)化。相反，系統(tǒng)測試強(qiáng)烈依賴特定的軟件應(yīng)用場景，類似的軟件用在不同的場景中，會(huì)要求差別很大的測試設(shè)計(jì)。
軟件在人們的生活中發(fā)揮著這樣重要的作用，因此保證軟件質(zhì)量是至關(guān)重要的。測試是驗(yàn)證任何產(chǎn)品質(zhì)量的過程。舉一個(gè)紡織工業(yè)的例子：購買布匹時(shí)，我們期望布匹禁用，尺寸合適，不易掉色。在銷售布匹之前，銷售者有責(zé)任測試布匹的這些基本性質(zhì)，換句話說，銷售者要對布匹的質(zhì)量負(fù)責(zé)。
二、測試大數(shù)據(jù)應(yīng)用推進(jìn)難點(diǎn)
我認(rèn)為更為抽象的單元測試對于測試用例推薦，一般來說更容易。但是單元測試主要還是由軟件研制單位完成，因此單元測試的用例推薦對軟件測評實(shí)驗(yàn)室價(jià)值不高。對于大數(shù)據(jù)應(yīng)用來說，單元測試用例推薦可能是比較好的起點(diǎn)，關(guān)注服務(wù)對象主要是軟件研發(fā)單位。
同時(shí)，軟件單元測試與其他測試級(jí)別相比也是最成熟的，目前唯一有效的軟件測試國際標(biāo)準(zhǔn)就是單元測試標(biāo)準(zhǔn)，針對單元測試的自動(dòng)化、半自動(dòng)化工具也是最豐富的，在軟件測試目前已有的四種主要方法中，包括基于規(guī)則的動(dòng)態(tài)分析、基于測試數(shù)據(jù)輸入的動(dòng)態(tài)測試、基于符號(hào)運(yùn)算的運(yùn)行時(shí)檢查、基于模型的軟件邏輯正確性驗(yàn)證等，也是運(yùn)用最成功的，因此大數(shù)據(jù)要想給出一些更具啟發(fā)性的推薦也是比較困難的，但是如果大數(shù)據(jù)能夠更深入地結(jié)合被測軟件單元的結(jié)構(gòu)信息，換句話說，大數(shù)據(jù)不僅要使用從單元測試數(shù)據(jù)中提取的模式信息，還要使用具體被測軟件的結(jié)構(gòu)或設(shè)計(jì)信息，推薦有價(jià)值測試用例的可能性更大。特別地，針對某些單元測試難度比較大的子問題，比如中斷處理、變量定義/使用路徑驗(yàn)證等的測試，獲得突破的可能性更大一些?？傊?，面向的問題域越寬，給出高價(jià)值測試用例的可能性越低。我想大數(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ù)才算足夠。我對這個(gè)想法深表懷疑。舉個(gè)例子，大數(shù)據(jù)也好、數(shù)據(jù)庫知識(shí)發(fā)現(xiàn)也好、人工智能、機(jī)器學(xué)習(xí)、模式識(shí)別等也好，當(dāng)取得了一些重要突破后，無一例外地都把應(yīng)用目標(biāo)轉(zhuǎn)向股市和類似的領(lǐng)域。直覺上這些技術(shù)應(yīng)該在股市上有所作為，因?yàn)楣墒袛?shù)據(jù)量不可謂不大，數(shù)據(jù)中的模式不可謂不多，已有的傳統(tǒng)分析方法運(yùn)用也幾乎到了極致。但是事實(shí)是，即使是紅得發(fā)紫的阿爾法狗也在中國股市潛水多時(shí)后黯然離開。從地球奔向月球是美好愿望，但是必須得有合適方法，你對自行車再挖空心思地改造，也永遠(yuǎn)不會(huì)把你帶到月球。我想大數(shù)據(jù)也是一樣。如果軟件測試領(lǐng)域的復(fù)雜度可以與股市比較，再對著自行車費(fèi)心思就大可不必了。關(guān)鍵是降低問題域的寬度和難度，大而化之的所謂軟件測試大數(shù)據(jù)應(yīng)用，我認(rèn)為目前是不可行的。
三、測試大數(shù)據(jù)應(yīng)用解決方向
軟件測試的主要工作，是把軟件需求映射為軟件測試。大數(shù)據(jù)應(yīng)用也可以表述為輔助測試人員，直至自動(dòng)完成這個(gè)映射，大數(shù)據(jù)能力的表征也體現(xiàn)在對測試人員的輔助、啟發(fā)效果。如果給出的推薦是測試人員沒有想到，而且對測試具有重要性，則得正分；如果推薦是重復(fù)性的，比如被其他測試用例包含，則得零分；如果推薦沒有可行性或必要性，甚至對測試人員的設(shè)計(jì)產(chǎn)生干擾，則得負(fù)分。這種獎(jiǎng)勵(lì)/懲罰機(jī)制可以構(gòu)成大數(shù)據(jù)自我學(xué)習(xí)、進(jìn)化的基礎(chǔ)。
這個(gè)機(jī)制與測試人員的成長類似。測試大綱寫好后經(jīng)過內(nèi)部評審和外部評審，經(jīng)過幾輪迭代不斷完善。在理想情況下，測試人員會(huì)汲取教訓(xùn)和經(jīng)驗(yàn)，同類問題出現(xiàn)概率越來越小。把這個(gè)測試設(shè)計(jì)進(jìn)化過程送給大數(shù)據(jù)，即同一個(gè)項(xiàng)目的多個(gè)測試設(shè)計(jì)，以版本高低順序排序輸入給大數(shù)據(jù)，呈現(xiàn)出完整進(jìn)化過程，可以是大數(shù)據(jù)的一個(gè)起點(diǎn)。因?yàn)闇y試設(shè)計(jì)在評審中被提出修改意見的落實(shí)結(jié)果，本質(zhì)上就是一種推薦，而且是正分推薦。
不過問題遠(yuǎn)沒有這么簡單。測試設(shè)計(jì)評審，實(shí)際上也是評審?fù)斜硨Ρ车剡M(jìn)行從測試需求到測試設(shè)計(jì)的映射，并把自己的映射與被評審的測試設(shè)計(jì)產(chǎn)品進(jìn)行比對，發(fā)現(xiàn)產(chǎn)品不足的過程，僅僅了解測試設(shè)計(jì)改進(jìn)情況，而不知道為什么需要進(jìn)行這些改進(jìn)，很難獲得實(shí)質(zhì)性的經(jīng)驗(yàn)。因此大數(shù)據(jù)了解測試需求等依據(jù)，理解測試設(shè)計(jì)多個(gè)版本的映射差異，對于大數(shù)據(jù)的模式發(fā)現(xiàn)來說可能是不可避免的。
于是下面的問題就變成大數(shù)據(jù)如何對測試需求進(jìn)行理解。我聽到不少人說，測試需求的理解通過自然語言處理解決，因?yàn)楝F(xiàn)實(shí)世界的測試需求主要以自然語言描述的形式給出。實(shí)際上，對測試需求的理解本身對測試人員的能力要求就是很高的，很少有測試人員僅僅根據(jù)測試需求文檔就能很好理解被測軟件的，與軟件研發(fā)人員的溝通是很難避免的。這意味著大數(shù)據(jù)還要理解不同階段的軟件設(shè)計(jì)文檔、甚至系統(tǒng)設(shè)計(jì)文檔、項(xiàng)目技術(shù)方案、立項(xiàng)論證報(bào)告等等相關(guān)文件。即使這些條件都具備，通用的測試需求大數(shù)據(jù)理解也是非常困難的，可能降低難度的方向，應(yīng)該是限定軟件類型、使用領(lǐng)域等，達(dá)到一般測試人員的平均理解水平還是有可能的。
在測試需求大數(shù)據(jù)理解上，我覺得還有兩個(gè)問題很難回避，一個(gè)是需求文檔中的圖表，一個(gè)是預(yù)期的測試環(huán)境初步想定。
圖表對于測試人員對測試需求的理解至關(guān)重要，大數(shù)據(jù)直接理解圖表中給出的豐富語義信息、結(jié)構(gòu)信息、拓?fù)湫畔?，我想還是有很大困難的。如果需要人工把圖表進(jìn)行自然語言轉(zhuǎn)換，即使是能夠做到，對大數(shù)據(jù)的實(shí)際使用也會(huì)是個(gè)很大制約。如果這個(gè)問題沒有一個(gè)足夠滿意的解決方案，我想大數(shù)據(jù)對于軟件測試可能弄不好就是那個(gè)自行車了。
測試需求到測試設(shè)計(jì)的映射還有一個(gè)重要條件，就是測試環(huán)境的初步想定，而測試環(huán)境又是在映射過程中逐步確定的。一般來說，測試需求決定測試環(huán)境，測試環(huán)境影響測試需求。但是測試環(huán)境的確定還受到很多技術(shù)、管理、成本、進(jìn)度、可用資源等多方面的制約，可能需要比較復(fù)雜的綜合考慮，既要考慮測試的充分性、有效性，還要考慮測試工程的可行性。而且測試環(huán)境的確定常常是一個(gè)逐步迭代的過程，測試任務(wù)的不同，使得通常不存在一個(gè)具體的理想目標(biāo)測試環(huán)境模型。而如果要把測試環(huán)境作為測試設(shè)計(jì)大數(shù)據(jù)推薦的一部分，可能難度很大，因?yàn)闇y試大綱不同版本本身可能就包含測試環(huán)境的演化。可能的解決辦法是優(yōu)先確定測試環(huán)境，雖然這對測試人員來說也不是完全不能接受，但畢竟是對大數(shù)據(jù)的一個(gè)重要制約。
歡迎各位大佬提出意見見解，留言區(qū)等你哦！
