A Survey on Unit Testing Practices and Problems
來自2015年的一篇論文，研究者通過網絡在線平臺對單元測試相關的問題進行了調查 。主要問了五個問題- RQ1：是什么促使開發人員編寫單元測試？
- RQ2：單元測試中的最主要的活動是什么？
- RQ3：開發人員如何編寫單元測試？
- RQ4：開發人員如何使用自動化單元測試生成？
- RQ5：單元測試的難點是什么？如何改進單元測試流程？
樣本情況
圖 2
這一次調查涉及到了全球的225位軟件工程師 ， 使用不同的語言，分布在29個國家 。
圖3
圖2和圖3顯示了這一次調查樣本的人口統計數據 。
- 受訪者的年齡范圍從14歲（AYTM受訪者的最低年齡）到72歲 ， 其中37%的受訪者年齡在25至35歲之間 。
- 盡管也有其他領域的受訪者但是大多數受訪者在IT領域工作（55.5％） 。
- 最多的受訪者（59.06％）來自美國，其次是印度 ?？偟膩碚f，樣本具有一定的全球性來自歐洲（32），北美（143）和南美（13） ， 非洲（1），澳大利亞（1）和亞洲（35） 。大多數受訪者擁有4年制學位或專業學位 。
樣本過濾
在進行調查時，從受訪者中獲得良好的響應樣本可能是一項具有挑戰性的任務 。為了更好的得到真實的結果 ， 我們對調查者設置了三個資格測試的問題，以確保是他們是真正的軟件工程師，并且有開發經驗，接觸過單元測試 。資格測試的目的不是為了篩選出單元測試專家 。相反 ， 我們的調查應該針對所有軟件開發人員 ， 無論好壞 。然而，我們希望忽略試圖欺騙測試系統以收取報酬的潛在受訪者 。為此，我們的假設是，任何誠實回答問題的軟件開發人員應該能夠至少正確分類三個陳述中的兩個 。
不到四分之一的受訪者（22％）全部正確分類了所有三個陳述；76％至少有兩個問題是正確的 ， 88％至少有一個問題是正確的 。當然 ， 一些給出錯誤答案的人可能受訪者只是不那么有能力；
例如，超過10年編程經驗的受訪者中有32％全部正確回答，而對于經驗不足三年的受訪者，這個數字僅為14％ 。但是，假設一個真正的軟件開發人員閱讀問題并正確回答資格測試題而不是隨機回答，應該能夠至少獲得兩個正確答案，因此沒有或只有一個正確答案的24％的響應是“可疑的” 。雖然看起來資格測試問題（“您是否是軟件開發人員？”）在過濾不可靠的響應方面做得相對不錯，但我們的結論是這個問題還不夠，至少需要回答對兩個問題 。因此，我們僅使用76％的數據（即225名受訪者中的171名）的數據 。
為了分析受訪者的可靠性，我們計算了有序數據的組內相關性（ICC ， 使用雙向模型和平均值單位以及一致性類型ICC測量） ， 以及在調查中使用無名類型問題的Fleiss Kappa（僅針對171個合格的回答） 。對數據進行了數據分析，證明結果是相對比較客觀的 。
RQ1: 是什么促使開發人員編寫單元測試？
對于第一類問題，調查問卷一共涉及了五個方面的因素，每一個因素分為七個等級，從影響非常大，到幾乎沒有影響 。
圖 4
從結果來看開發人員寫單元測試的動機主要來源于管理要求和研發人員自己覺得有用兩個重要因素 。
RQ2: 單元測試中的主要活動是什么？
針對第二個問題，怎么評估單元測試在整個開發過程中花了多少時間其實是一個非常難的話題，我們沒有什么直接的辦法，所以將問題拆分成為兩部分來綜合分析在軟件開發過程中，您是如何分配時間的
圖5
上圖2演示了統計樣本中的概率分布圖 。這個圖顯示了結果的最小值、最大值以及四分數數據 。
- 33.04的平均時間用于寫新的代碼
- 25.32%的時間用于調試
- 17.4%的時間用于寫單元測試
盡管從所列出的活動中，編寫測試被認為是花費時間最少的，但花費在編寫新測試上的時間仍然相當可觀，花費在編寫新測試上的時間幾乎是編寫新代碼所花費時間的一半 。這讓人想起經常引用的估計值 ， 即50%的軟件開發時間用于測試 。
在編寫代碼和測試方面 ， 這可能并不是真的 ， 可以推測需要花更多的時間編寫測試 。另一方面，更廣泛的術語“測試”將包括處理失敗的測試，即調試和修復，從這個意義上說，開發人員認為他們花費了接近一半（42.72%）的時間用于與測試相關的活動 。
值得注意的是，有些人在編寫新測試方面花費的時間非常極端；例如，有些受訪者花費了更多的時間來進行測試 。這些可能包括那些“測試依賴”的開發人員 。更有趣的是，有21個受訪者聲稱根本不進行測試—占所有（合格）受訪者的12％！
我們調查了比較不同開發人員之間是否存在任何趨勢，并通過計算中位數和95％置信區間來檢查組之間的統計差異 。置信區間是使用1,000次重采樣引導計算的[6] 。如果兩組的置信區間不重疊，則這兩組之間的差異具有統計學意義 。
在編程經驗方面，似乎存在一種輕微的趨勢 ， 隨著經驗的增加，編寫測試的時間減少，但沒有顯著差異 。然而也可以合理地假設：隨著經驗的增加，開發人員在編寫其測試方面變得更加高效或者更加隨意 ?？紤]到團隊規模，似乎存在一種輕微趨勢，即在較大的團隊中花費更多時間編寫測試 。
當一個測試失敗了之后，您一般會做什么？
接上一個調查的數據當使用單元測試時，調試和修復所花費的時間（平均開發時間的25.32%+17.40%）受每個失敗測試的影響，每個失敗測試都需要檢查和糾正操作 。
per
Fix the code until the test passes
47.2%
Repair the test to reflect changed behaviour
25.9%
Delete or comment out the failing test or assertion
15.6%
Ignore the failure
11.2%
為了研究這個問題，我們要求受訪者估計他們在不同情況下對失敗的測試做出反應的頻率 ， 再以百分比的形式表示 。
圖6
上圖總結了回答結果:幾乎一半的情況下（平均為47.2%） ， 開發人員認為單元測試實現了其目的并檢測出需要修復的錯誤 。然而，在52.8%的情況下，他們認為這不是這樣，他們要么修復測試，要么根本不處理失?。ㄍㄟ^刪除或忽略測試） 。這是合理的——在開發過程中 ， 功能可能會發生變化，測試需要更新 。根據使用場景不同，單元測試工具并不是“開箱即用”的工具——它們產生需要維護的單元測試 。因此，不同方面的重要性，如可讀性和針對代碼變更的魯棒性，非常重要 。
同樣，結果在不同人之間是相當一致的 。有超過10年經驗的開發人員聲稱比其他人更經常修復代碼，并聲稱比其他人更不經常忽略或刪除失敗的測試 。另一方面，經驗不足的開發人員聲稱在修復測試方面比其他經驗組花費更多的時間 。值得注意的是 ， 經驗不足的開發人員（1-3年的經驗）比擁有超過10年經驗的開發人員更經常刪除測試 。
RQ3: 開發人員如何編寫單元測試？
前面的研發已經提到，研發人員使用了大約17.4%的時候來寫單元測試 。我們現在來確定研發人員是怎么寫單元測試的，我們將通過兩個問題來確定這個問題研發人員什么情況下會優化單元測試？
將問題分為七個維度，同樣以七個等級讓受訪者回答這個問題 。最贊同的原因是“因為真實場景需求” 。從結果來看 ， 并沒有體現出明顯的差異 。
圖 7
單元測試的執行速度和單元測試代碼重構是開發人員似乎認為不太重要的方面，但總體而言，很難辨別真正的趨勢 ， 開發人員至少在某種程度上聲稱他們正在優化他們的測試以滿足一切使測試良好的東西 。
當研發人員寫測試的時候一般會應用什么技術？
很多人都會說自己使用了系統分析的技術來寫單元測試，單元測試覆蓋率是在寫單元測試過程中也比較重要的技術指標 。這兩個看起來是有相關性的，如果使用單元測試覆蓋率的工具 ， 就意味著有系統性的去提高單元測試覆蓋率 。測試驅動開發是第三個研發人員使用得比較多的技術 。
圖 8
有些令人驚訝的是，近54%的開發人員回答說至少“經?！笔褂米詣踊瘻y試生成 。需要注意的是，正如我們從前期研究中看到的 ， 自動化測試生成的概念并不是開發人員特別熟悉的，因此，與更常見的技術如代碼覆蓋率相比 ， 開發人員對自動化測試生成的解釋不夠一致 。顯然，這表明從業者需要更好地了解自動化單元測試研究的進展 。然而，在與開發人員的討論中，有時可以觀察到一種對自動化測試生成的不滿意 。這個問題的回答似乎表明這并不是普遍的意見 ， 開發人員可能比常常被認為的更加開放，愿意接受自動化測試生成 。
變體分析（Mutation Analysis）比其他技術應用得少，但我們認為變體分析是一項高級技術 ， 研究人員喜歡并支持它，但不會在實踐中被普及使用 。因此，69%的受訪者聲稱至少偶爾使用變體分析的結果令人驚訝：例如 ， 變體測試社區的最近研討會上討論了為什么實踐者沒有采用變體分析 。盡管調查結果證實了變體分析并不像代碼覆蓋率那么常見，但似乎變體分析在實踐中比人們所認為的更為常見 。實際上，我們主觀地感覺到近年來各種語言的新變體分析工具的增加 ， 這可以證實這一趨勢 。
RQ3:研發人員聲稱系統性的寫單元測試，同時通過代碼覆蓋率 。但是并沒有統一的標準來定義怎么讓一個測試更好
RQ4: 開發人員如何使用自動化單元測試生成？
前面的問題提到研發人員經常使用自動化單元測試工具，這個問題是關于怎么使用自動化單元測試工具的問題 。
圖 9
上圖的統計得出了基本的信息
- 第一，自動化單元測試主要是用來補全手工的單元測試能力 。但是這里面就引出了一些問題 ， 自動化單元測試需要被維護，如果錯了需要去Debug看是什么原因？自動生成的單元測試代碼也需要維護 。自動生成的單元測試可能可讀性和可維護性非常低 ， 這是一個巨大的挑戰 。
- 第二，自動化單元測試一般用來發現崩潰的問題 ， 這也是自動化單元測試效果最好的地方 。
然而，隨著更先進（和可用）的自動化測試生成工具的出現，這種情況可能會發生變化：自動化測試生成可以作為更好的方法來編寫斷言或代碼 。回歸測試也排名較低，這似乎也是有問題的，因為在回歸測試中，以前的程序版本通?？梢源嬉幏?nbsp;， 從而在原則上允許全自動化 。
RQ5: 單元測試的難點是什么？如何改進單元測試流程
最后一個問題是要弄明白寫單元測試主要的困難和急需提高的關鍵點是什么 。編寫新的單元測試最困難的是什么
圖 10
上圖展示了編寫新單元測試的困難點是什么，下表總結了Borda排名 。與前面的問題相比，這里的評價者之間的一致性具有更大的置信區間，這表明大家之間的意見不太一致 。
表 2
通過這個統計結果可以發現 。
- 寫單元測試最困難的部分在于確定哪些代碼是需要進行測試的 。考慮到大部分人寫單元測試都會參考單元覆蓋率，所以這里面最重要的指導意見就是通過是否覆蓋代碼來決定哪些代碼需要寫單元測試 。但是實際上 ， 有一些很重要的代碼即使覆蓋率看起來很好 ， 但也需要做更多，更深入的測試 。
- 排名第二的選擇是測試中要檢查什么 。即使自動化測試生成工具可以解決生成實際測試的問題，但開發者仍然會遇到單元測試需要檢查什么的問題 ， 開發者也將此問題排名較高 。
- 第三個選擇是隔離待測試單元 。確實，這也是自動化單元測試生成的主要挑戰之一[7] ， 但這個任務很少有工具支持（例如[1]，[5]） 。測試生成文獻通常忽略了這個方面，因此在這方面有改進軟件測試的機會 。這也引發了一個問題 ， 即這個問題在多大程度上是由于開發人員編寫的代碼的可測試性較低（即不良設計）引起的，是否通過改進自動化工具來處理不良代碼的方法是正確的？這是值得商榷的 。有趣的是，來自美國的受訪者將這個問題排名較低（第4位；排名的差異是顯著的），而來自全球的受訪者將這個問題排名較高（第2位） 。但是，對于美國受訪者，排名前四位的項目總體上更接近 。
如何對報錯的測試最難的地方在哪里？
圖 11
- 排名第一選項是如果測試容易出現古怪的問題（flaky），即有時失敗，有時不失敗 。例如，依賴于非確定性代碼、環境屬性或多線程代碼的測試本質上很難調試，因此很難修復 。在某種程度上，古怪測試的問題在于代碼，而不是測試，因此與之相關的排名第二的選擇是：如果測試代碼難以理解，則測試很難修復 。這并不出人意料 ， 但從測試生成的角度來看，代碼通常必須被視為已知的，只能通過生成的測試實現改進 。但是，確保生成的測試不會出現古怪的問題是一個重要的問題，我們不知道這方面有任何研究工作 。
對單元測試的總體映像
調查的最后一個問題要求受訪者指明他們對單元測試的不同說法的認同程度 。圖12顯示了這些陳述和回答 。對于是否需要更多的工具支持來編寫測試，開發人員似乎非常愿意，并渴望看到更多工具 。
圖 12
有趣的是，人們普遍認為開發人員已經有足夠多的測試，盡管仍有相當多的開發人員表示希望擁有更多測試 。
另一方面，認可度最低的是關于開發人員是否真正喜歡編寫這些單元測試的問題 。只有大約一半的開發人員感覺寫單元測試的體驗還行，但這個地方明顯需要更多的提高；
提供幫助開發人員的高級工具可能是使測試更加愉快和有成效的一種方式，例如提供自動生成測試的工具 。另一方面 ， 前面調查一致，開發人員更認同維護單元測試比編寫單元測試更具挑戰性 。這對于自動化測試生成工具構成了一個挑戰 ， 研究仍然非常專注于解決后者的問題，只有少數例外（例如[23]） 。
RQ5: Developers do not seem to enjoy writing tests, and want more tool support—in particular to identify what to test, and how to produce robust tests.
RELATED WORK
雖然有一些針對單元測試的實證結果[17] ， 但在軟件工程領域，相關的調查頻率相對較低，與其他學科如市場營銷和心理學相比[16] 。最接近我們調查的是Runeson對單元測試實踐的調查[24] 。這項調查提出了50個與單元測試相關的問題，分別是1）什么是單元測試？2）單元測試的優點和缺點 。我們對單元測試的解釋與這項調查中得出的解釋一致；Runeson的調查中發現的一些弱點也在我們的調查中出現了 。例如，難以確定要測試的單元 ， 以及測試維護的難度 。總的來說，我們的調查與Runeson的調查不同之處在于更專注于確定自動單元測試生成可以改進測試的潛在領域 。Torkar和Mankefors[27]對軟件重用和測試進行了調查 。這項調查與我們的調查分享了一些見解；例如 ， 邊界值分析通常由開發人員應用，并且他們的調查還顯示，開發人員渴望在編寫單元測試時獲得更好的工具 。
Geras等人[12]在阿爾伯塔省進行了一項關于測試實踐的調查，發現單元測試是最受歡迎的測試方法，但只有30%的測試人員使用了單元測試 。在整個加拿大進行的一項更大的調查[11]證實了單元測試的相對流行 ， 并且有越來越多的人對變體分析產生了興趣，與我們的結果類似 。
Ng等人[21]在他們對澳大利亞軟件測試實踐的調查中也發現了高度愿意使用自動化工具的意愿，與我們的結果一致 。Lee等人的調查[19]也觀察到了支持自動化所需的工具需求 。Causevic等人[2]發現，相對于其他領域（如嵌入式系統），單元測試在Web應用程序中更受歡迎 。與我們的研究相關的是，他們發現開源工具主要用于單元測試，而商業測試工具更多用于更高級別的測試 。Zhao和Elbaum[28]調查了開源項目，發現盡管測試消耗了大量資源，但只有大約一半的項目有基線測試套件 ， 只有少數項目使用覆蓋分析工具來支持他們的測試 。
總的來說，這些回答指出了自動單元測試生成可以支持開發人員的領域 ， 以及需要進一步研究的領域：
CONCLUSIONS
改善軟件質量的必要性是被廣泛接受的，但問題在于如何實現這一目標 。改進單元測試是其中一種可能性，軟件工程研究正在為從業者提供可以提高其測試活動質量和生產力的新技術 。我們的目標是更好地了解單元測試的常規實踐 ， 以便識別改進的可能性，特別是自動化單元測試生成 。【一個關于單元測試實踐的在線調查報告】我們在29個國家共收到了171位參與者的在線調查結果，結果證實單元測試在軟件開發過程中扮演了重要角色：開發人員花費了大量時間來編寫測試 。顯然，還有更多的測試空間：12%的開發人員根本不進行測試，73%的人表示強烈希望擁有更多的測試 。為了加強我們的發現，我們正在探索使用受控實驗（例如 ， [9]），并計劃在未來的工作中使用調查復制和觀察方法（例如，工業案例研究） 。
- 開發人員需要幫助來決定要測試什么 ， 而不是選擇具體的輸入值 。自動單元測試的大多數研究都回避了這個問題（例如，通過隨機選擇或由代碼覆蓋率驅動選擇） 。
- 單元測試需要是現實的：開發人員在編寫新測試時，以及在處理失敗的測試時 ， 最關心的是它們是否是現實的 。一個不現實的情景會使修復測試變得更加困難，開發人員可能不會相信基于不現實的測試修復代碼 。
- 單元測試需要是可維護的：即使是自動生成的單元測試，也可能被集成到常規代碼庫中，在那里它需要像任何其他代碼一樣手動維護 。如果測試不再反映更新的行為，需要輕松檢測到并輕松修復 。
- 單元測試生成最有效的是確定輸入值，但未解決的挑戰是確定要檢查什么 。最終，這意味著長期存在的測試預言問題會像任何其他測試生成方法一樣困擾單元測試 ， 對此方面的進展將使測試生成工具對從業者更有價值 。
