【正文】 這項研究有助于選擇測試用例生成基于測試 要求 的技術(shù) ，它還有助于選擇基于開放源碼軟件、工業(yè)軟件和簽入更加快速、持續(xù)的軟件應(yīng)用程序類型的圖形用戶界面來執(zhí)行的測試類型。 圖 結(jié)論 在此文中，一些測試用例生成的方法和各種類型 GUI 測試，適應(yīng)不同的 GUI 應(yīng)用程序和技術(shù)的研究。 優(yōu)點是：合并上下文，相比以前使用的技術(shù)，可以納入、檢測更多的故障。測試用例生成并執(zhí)行。最初使用 GUI 開膛手，GUI 應(yīng)用程序轉(zhuǎn)換為事件圖，然后事件的分組取決于功能，同時標(biāo)識約束。使用圖形模型和覆蓋陣列用于生成測試用例，這些都是組合相互作用的測試基礎(chǔ)。他們用一種組合交互的測試技術(shù)。 缺點是代碼的一些部分被冒 煙測試 丟失， DART 報告的 一些缺陷是錯誤肯定的， 整體的 DART 有效性取決 GUI 開膛手功能，不能基于工業(yè)應(yīng)用程序測試運用，不在 GUI 中 顯現(xiàn)的故障將不能被 檢測到 。故障播種用于評估使用的故障檢測技術(shù)。在 DART 所有的進程，如分析 AUT 的 GUI 結(jié)構(gòu)使用 GUI 開膛手、測試用例生成、 預(yù)言 測試生成 、測試用例的執(zhí)行人、 檢查 報告和不成功的測試案例、 提交 缺陷報告 被自動化。 DART 自動啟動應(yīng)用程序下測試（ AUT） 在 夜間、它構(gòu)建和運行的 GUI 冒 煙測試和開發(fā)人員在日間 的 工作代碼。 圖 生成事件交互圖 生成碰撞測試用例 執(zhí)行測試用例 測試報告 軟件應(yīng)用程序 、 快速發(fā)展的軟件 Atif M. Memon 在 GUI 冒煙測試的領(lǐng)域中涉及到的 GUI 冒煙測試套件、 大小、故障檢測能力和預(yù)言測試 做出貢獻 。 碰撞試驗技術(shù)用于保證 GUI 應(yīng)用程序的質(zhì)量，這也有助于快速測試應(yīng)用程序。碰撞測試的有效性被認為是測試用例的總數(shù)用于檢測最大值的故障。執(zhí)行的測試用例和測試執(zhí)行過程中的崩潰用來識別軟件中的嚴重問題。在碰撞測試中，一次生成測試用例，涵蓋該特定的邊緣，然后設(shè)置此標(biāo)志。生成的測試用例，可以生成和快速執(zhí)行，并涵蓋所有的 GUI 功能。碰撞測試的兩個層次是：即時基于反饋的碰撞測試的開發(fā)人員表明 GUI 漏洞固定在響應(yīng)以前報告的崩潰； 回應(yīng)僅選擇碰撞測試用例是重新運行并將結(jié)果通知開發(fā)人員。三環(huán)之間的交互未定義的是限度?；? GUI 的開放源碼軟件的多個版本在繼續(xù)存在的缺陷是完全自動檢測這種方法。問題報告所有的開發(fā)者是發(fā)展特定版本的一部分。冒煙測試是第二種技術(shù)運作的每一天對 GUI 生 成操作和執(zhí)行功能的參考的整合版本的 GUI 測試，利用使用過測試的版本作為基線。碰撞測試是對每個簽入代碼的 GUI 軟件進行操作的最內(nèi)層的技術(shù)和它頻繁執(zhí)行與自動化的GUI 測試干預(yù)和快速地執(zhí)行。許多開發(fā)人員參與和通過 WWW進行代碼更改，它容易產(chǎn)生更多的缺陷。局限性是 GUI 系統(tǒng)的特點是只基于系統(tǒng)事件，不包含用戶的交互。 運用目標(biāo)問題公制（ GQM）范式?？梢孕薷姆诸?，并根據(jù)需要添加類別。在此方法中，缺陷是基于 beizer 的缺陷 來分類的。 各種應(yīng)用程序的 GUI 測試 4． 工業(yè)圖形用戶界面系統(tǒng) Penelope Brooks 開發(fā) GUI 測試方法發(fā)展相關(guān)的工業(yè)應(yīng)用程序，提高測試系統(tǒng)整體素質(zhì)，它通過描述 GUI 界面，使用收集的數(shù)據(jù)檢測缺陷，是測試人員和研究人員協(xié)助發(fā)展中更有效的測試策略。但 對于長時間執(zhí)行大型應(yīng)用程序不是高可擴展。 優(yōu)點是，它會在更長時間的測試序列上更好地生成覆蓋范圍較小的測試套件。該算法將最生成 GUI 事件交互的初始模型 生成初始序列 生成測試用例 移動不可執(zhí)行的序列和更新模型 決定代碼覆蓋和確定不可執(zhí)行的序列 執(zhí)行測試 GUI 應(yīng)用程序 佳測試用例添加到最終的測試套件。如果存在不可行的測試用例，然后開始修復(fù)階段。 遺傳算法用于修復(fù)算法。這些傳遞回控制器和測試套件修復(fù)階段開始。此覆蓋陣列發(fā)生器生成一組初始事件序 列。圖模型用于作為輸入，如 EFG、 EIG、 ESIG 和翻錄的 GUI 結(jié)構(gòu)。生成是可行的新測試用例和遺傳算法用于開發(fā)測試用例，提供額外的測試套件，通過刪除不可行的測試用例并插入新可行的測試用例。 缺點是事件的上下文不合為一體，需要覆蓋和測試充分，判斷這些是如 何影GUI 應(yīng)用程序 生成事件交互模型 區(qū)分 GUI 事件 確定約束條件 由覆蓋陣列生成最大序列 生成可執(zhí)行的事件序列 執(zhí)行測試用例 事件交互缺失？ 測試報告 響故障檢測。這些測試用例自動的生成過程如圖 3 所示。決定代碼覆蓋和標(biāo)識不被執(zhí)行的測試用例。生成 GUI 事件交互的初始模型和一組初始的基于模型的測試序列。由 ESI 生成事件語義的交互圖。推薦框架使用從組合的交互測試生成測試技術(shù)和測試組合互動的基礎(chǔ)是覆蓋陣列。 生成事件交互圖和種子測試套件 執(zhí)行種子測試套件，記錄 GUI 運行時間 生成 事件語義交互圖 執(zhí)行測試用例 測試報告 GUI 應(yīng)用程序 圖 、 動態(tài)適應(yīng)測試自動生成 Xun Yuan 建議一種生成測試套件不太可行的測試用例和更高的事件交互覆蓋算法。如果任何事件交互錯過了，然后重新生成測試用例，并重復(fù)步驟。長 時間的生成測試用例使用覆蓋陣列抽樣。覆蓋陣列 CA (N； t， k， v)是一個以 v 標(biāo)識的 N k 數(shù)組，每個 N t 子數(shù)組至少包含所有有序的子集的 v 標(biāo)識的至少一個屬性。使用這種技術(shù)生成測試序列，在特定范圍的強度下系統(tǒng)的采樣。因為隨著一個序列中的事件數(shù)的增加，測試套件不斷變大，阻止使用序列長度超過 3 或 4。 圖 GUI運行時間生成測試用例作為反饋 、使用覆蓋陣列技術(shù) Xun Yuan 提出一種新的 GUI 測試使用覆蓋陣列 (CA) 的測試用例生成 自動化技術(shù)。由于生成多路交互測試用例，將會生成大量的測試用例。此方法被設(shè)計的重點在 GUI 應(yīng)用程序。故障檢測效率高于兩種方式的相互作用，這是因為，生成測試用例并以不同的決策執(zhí)行不同的事件組合。新生成的測試案例都經(jīng)過測試，并附加故障檢測。此 GUI 運行時狀態(tài)記錄用于獲取應(yīng)用程序的事件語義交互(ESI)關(guān)系，這些 ESI 用于獲取事件語義互動圖 (ESIG)。為進行測試的應(yīng)用程序生成事件交互圖 (EIG) 和雙向交互的 GUI 事件生成的種子測試套件。 測試用例生成 、 使用 GUI 運行時狀態(tài)反饋 Xun Yuan 和 Atif M Menmon 使用 GUI 測試用例生成的反饋和從執(zhí)行種子測試套件 對應(yīng)用程序下測試（ AUT）獲得的反饋。 EIG 包含與 GUI 應(yīng)用程序的業(yè)務(wù)邏輯進行交互的事件。基于模型的測試使用 GUI 稱為事件交互圖 (EIG) 和事件語義的交互圖 （ ESIG） 的有向的圖模型。測試套件包含詳細的指引或測試用例的每個集合的目標(biāo)。多個測試用例是被需要的，用來測試 GUI 應(yīng)用程序的全部功能。自動化 GUI 測試高效、精確、可靠和低成本。它是非常耗時的。 GUI 測試可以由人類手動或通過自動化的方法自動執(zhí)行。 GUI 測試涉及執(zhí)行一些任務(wù)，并比較結(jié)果與預(yù)期的輸出。即使圖形用戶界面提供了用戶使用軟件的簡單方法，但是它們會使開發(fā)過程的軟件復(fù)雜化。圖形用戶界面 (GUI) 為用戶提供了交互軟件非常好的途徑。 關(guān)鍵字 GUI 測試，基于模型的測試，測試用例，自動化測試，事件測試。涵蓋所有用例，并提供所有可能的（成功 /失?。┣闆r都測試的測試長度序列被認為是重要的。隨著時間的推移，測試 GUI 的復(fù)雜性不斷增加。由于軟件開發(fā)生命周期中的測試階段的重要性，測試劃分為圖形用戶界面 (GUI) 基于測試、 邏輯測試、集成測試等。 only the select crash test cases are re run and the developer is notified of the results in a matter of seconds. If any code changes occur, new crash test cases are generated and executed on the GUI. Test cases are generated that can be generated and executed quickly and cover all GUI functionalities. Once EIG is obtained, a boolean flag is associated with each edge in the graph. During crash testing, once test cases that cover that particular edge are generated, then the flag is set. If any changes occur, boolean flag for each edge is retained. Test cases are executed and crashes during test execution are used to identify serious problems in the software. The crash testing process is shown in Figure 4. The effectiveness of crash test is known by the total number of test cases used to detect maximum faults. Significantly, test suite size has no impact on number of bugs revealed. This crash testing technique is used to maintain the quality of the GUI application and it also helps in rapidly testing the application. The drawbacks are, this technique is used for only testing GUI application and cannot used in web applications, Fault injection or seeding technique, which is used to evaluate the efficiency of the method used is not applied here. Figure 4. Crash Testing Process . Rapidly Evolving Software Atif M. Memon et al [10], made several contributions in the area of GUI smoke testing in terms of GUI smoke test suites, their size, fault detection ability and test oracle. Daily Automated Regression Tester (DART) framework is used to automate GUI smoke testing. Developers work on the code during day time and DART automatically launches the Application Under Test (AUT) during night time, builds it and runs GUI smoke tests. Coverage and error report are mailed to developer. In DART all the process such as Analyzing the AUT’s GUI structure using GUI ripper, Test case generation, Test oracle generation, Test case executor,