前言
最近在做項目里的自動化測試工作，使用的是TestNG測試框架，主要涉及的測試類型有接口測試以及基于業(yè)務實際場景的場景化測試。由于涉及的場景大多都是大數據的作業(yè)開發(fā)及執(zhí)行（如MapReduce、Spark、Hql等任務的執(zhí)行），而這些任務的執(zhí)行都需要耗費較多的時間。舉一個普遍的例子，其中一條場景測試用例是：
執(zhí)行一個MapReduce作業(yè)，校驗作業(yè)的執(zhí)行結果和執(zhí)行日志。
對于一個最簡單的MR任務，如果YARN集群資源充足，它的執(zhí)行時間也要花上將近一分鐘的時間。更不用說當YARN集群計算資源飽和時，任務還需要持續(xù)等待資源分配等。當測試回歸用例集里包含了大量此類的用例時，如果還用傳統(tǒng)的單線程執(zhí)行方式，則一次自動化回歸將會耗費大量的時間。
多線程并行執(zhí)行
基于上述場景，我們可以考慮將自動化用例中相互之間沒有耦合關系，相對獨立的用例進行并行執(zhí)行。如，我可以通過起不同的線程同時去執(zhí)行不同的MR任務、Spark任務，每個線程各自負責跟蹤任務的執(zhí)行情況。
此外，即使是單純的接口自動化測試，如果測試集里包含了大量的用例時，我們也可以借助于TestNG的多線程方式提高執(zhí)行速度。
必須要指出的是，通過多線程執(zhí)行用例時雖然可以大大提升用例的執(zhí)行效率，但是我們在設計用例時也要考慮到這些用例是否適合并發(fā)執(zhí)行，以及要注意多線程方式的通?。壕€程安全與共享變量的問題。建議是在測試代碼中，盡可能地避免使用共享變量。如果真的用到了，要慎用synchronized關鍵字來對共享變量進行加鎖同步。否則，難免你的用例執(zhí)行時可能會出現不穩(wěn)定的情景（經常聽到有人提到用例執(zhí)行地不穩(wěn)定，有時100%通過，有時只有90%通過，猜測可能有一部分原因也是這個導致的）。
