Using Evolutionary Computation to Improve Mutation Testing

主要講變異測試中使用遺傳演算法。

Motivation:遺傳演算法可以減少變異體子集而不會丟失重要資訊。分析了突變測試的最新進展，這有助於降低與此技術相關的成本，並提出應用它們來解決進化突變測試（EMT）中的當前缺陷.

將重點放在突變測試中提出的方法應用於進化突變測試，這是一種基於遺傳演算法選擇減少的突變體集的技術,並且整合以下方法：

1.基於質量度量的選擇性變異。

​ 我們可以選擇丟棄一部分突變操作符（基於操作符的選擇性突變）或優先選擇最有價值的操作符（基於秩的突變體選擇）的突變體。

進化變異測試的提出：

Dom´ınguez-Jim´enez, J.J., Estero-Botaro, A., Garc´ıa-Dom´ınguez, A., Medina-Bulo, I.: Evolutionary mutation testing. Inf. Softw. Technol. 53(10), 1108–1123 (2011). http://dx.doi.org/10.1016/j.infsof.2011.03.008

潛在等效變異體：測試套件未檢測到的變異體

難以殺死的變異體:僅通過特異性測試案例殺死的變異體，不會殺死其他變異體

EMT可以找到強突變體。

EMT降低變異測試成本的兩個途徑：

• EMT不是從所有變異運算元生成突變體，而是僅根據質量度量在排名後從最佳值運算子生成突變體。
• 不是以相同的概率產生突變體，而是以基於秩的方式選擇突變體：從最佳值運算元中選擇突變體的概率更高。 該標準應用於在每一代遺傳演算法中隨機產生的突變體子集。

應用於C ++中的類級別的變異運算元時，基於突變的選擇產生比基於變異運算元的選擇更好的結果。

EMT的優點：

通過刪除分類底部的變異運算元，EMT的效率得到提高，因為它將避免遺傳演算法產生低質量的突變體。遺傳演算法可以更快地找到可以導致測試套件增強的那些突變體。 這些突變體可以標記為抗性突變體。

非等價變異體存活的原因是：1.測試套件不覆蓋突變體。2.測試套件覆蓋突變體但是卻不能揭示其突變。

而第二點可以通過基於質量度量的突變體生成方式來改進。

2.多目標進化突變測試

在遺傳演算法的適應度函式方面應該考慮：

• 最大化覆蓋範圍的影響：EMT不能區分等價變異體和抗性變異體，這樣可以選擇具有最高概率的非等價變異體。
• 最大化程式碼的覆蓋範圍：最好在整個程式的程式碼中傳播突變。
• 最大化變異運算元集中的散射

3.TCE (Trivial Compiler Equivalence)

TCE可以自動的檢測一些等價變異體。顯示出能夠在C編碼的程式中平均減少30％的等效突變體集.

TCE結合使用編譯器gcc和實用程式diff：gcc用於編譯程式碼並生成優化的可執行檔案，而diff允許比較這些可執行檔案以搜尋程式的不同版本之間的等價。

該機制可以檢測兩種型別的變異體：

• 等價突變體的一個子集：原始程式的二元檔案與突變體之間沒有差異時，突變體被識別為等價。
• 重複突變體的子集：當從突變體衍生的二元檔案等於從另一個突變體衍生的二元檔案時，突變體被識別為重複的。

TCE中最昂貴的任務就是編譯時間。

將EMT和TCE結合使用：

• 在執行EMT之前應用TCE，在這種情況下，編譯所有突變體以建立可執行檔案，TCE將它們與原始程式的可執行檔案進行比較。然後標記由TCE檢測為等價的那些突變體以避免它們可以在EMT的執行期間使用。
• 在執行EMT期間應用TCE。 在這種情況下，使用TCE分析在每一代中選擇的突變體。 那些被認定為等價的突變體通過分配給它們的適應值來懲罰。

注意：

TCE僅適用於C程式。

在等價突變體和抗性突變體稍微不同的前提下，一些等價的突變體可能可以指導遺傳演算法選擇新一代的抗性突變體。 因此，去除等價的突變體可能會影響對潛在等價突變體的搜尋。

future:

嘗試找到一種方法避免執行所有的測試用例來計算適應度函式，特別是在執行時間較長的時候。

CUT:Automatic Unit Testing in the Cloud

ISSTA’17-DEMOS, July 2017, Santa Barbara, CA, USA

Alessio Gambi, Sebastian Kappler, Johannes Lampel, and Andreas Zeller

通過分散式環境並行執行單元測試。

本文提出了一種雲單元測試。一種在分散式執行環境中自動執行單元測試的工具。CUT為虛擬機器或者容器分配適當的計算資源，並安排對它們執行測試，開發人員不需要更改現有的單元測試程式碼，並且可以輕鬆控制測試執行的資源分配和測試排程。執行期間，CUT監視器釋出有關正在執行的測試的事件，這些事件啟用了流分析。

在本文中，我們通過利用雲等分散式執行環境的強大功能來解決加速測試執行的問題。

CUT的優勢：

完全自動化和透明度，CUT採用面向切面程式設計（AOP）來隱藏訪問雲的低階機制，並且將測試執行分佈在開發人員的遠端資源上。包括在多個單一測試方法級別自動並行化測試執行的能力。

高效的資源分配和靈活性。大多數基於雲的測試解決方案。開發人員無法輕鬆控制測試執行的位置和每個測試的資源數量。CUT開發人員可以決定單元測試是在本地還是遠端，以及需要多少資源。CUT允許測試執行共享計算資源，從而提高測試的成本和效率。

測試依賴性，當前用於並行化測試的解決方案假設完全依賴於單元測試。但是，測試並不總是獨立的，這導致了非確定性的測試執行和誤報。CUT可以採取考慮到測試依賴性資訊以實現確定性執行。

步驟：

set up:

config

test runners

準備好虛擬機器後，根據叢集策略將測試集中到獨立的執行單元。根據部署策略將叢集部署到本地或遠端的測試執行器。根據排程策略命令測試執行。

這些策略都由開發者定義。

Execution：

每個測試執行器從其佇列中檢視要執行的下一個測試（物件）的引用。然後，自定義類載入器嘗試延遲載入正確執行單元測試所需的類和資料。如果測試執行器已經可以使用它們，則執行繼續。否則，自定義類載入器從類中提取類的位元組碼和資料。同時，測試執行器快取類和資料，使得這些可以在後續測試執行中重用，可能最小化總體執行開銷。

Monitoring and Reporting：

所有CUT元件都連線到共享事件序列以釋出和接收監聽事件。

雲管理器釋出事件，如虛擬機器的啟動或關閉。

測試執行器釋出有關單元測試生命週期的事件：測試開始，完成和失敗。

分析和報告元件將所有事件儲存為pository以進行進一步資料分析。

porter元件面向開發人員並提供兩種型別的報告：1.alive-report它捕獲有關開發人員單元測試狀態和上下文的事件流。2.測試執行的最終摘要，其中包括基本統計資訊和有關失敗測試的詳細資訊，即堆疊跟蹤。

訊息中介軟體採用Apache ActiveMQ

技術實現：

採用Java實現。測試開源工具Junit。採用maven自動化構建。雲的中介軟體選用 JCloud-Scale 。

實驗環境：

使用Tachyon（加州大學伯克利分校AMPLab開發的高效虛擬分散式儲存，附帶一個廣泛的測試套件）作為測試主題使我們有機會評估CUT在具有大型測試套件的系統環境中並行化測試執行的能力。

使用Crystal評估CUT是否能正確處理測試的依賴性。

對於此評估，我們選擇使用輕量級容器而不是標準虛擬機器，因為它們可以在邏輯上隔離測試執行，因為容器啟動時間比VM要長。 但是，我們必須注意到CUT不僅限於容器;事實上，它可以在容器，虛擬機器和虛擬機器內的容器上分配單元測試。此外，CUT可以跨測試執行重複使用虛擬機器，從而它們啟動造成的開銷。

CUT構建測試依賴圖，將屬於同一弱連線的測試叢集在一起，並根據拓撲排序在同一VM上的每個叢集中執行測試。

最近工作：

將軟體測試移植到雲端。

與HadoopUnit相比，CUT不需要廣泛而繁瑣的設定，允許開發人員控制資源分配，並且可以處理測試依賴性。

future:

Improved Strategies

Continuous Integration in the Cloud

Continuous Testing in the Cloud

Concolic testing導向性隨機測試

Distributed software testing

測試例項還可以配置被測軟體和能夠對軟體執行測試的測試執行器。 軟體測試服務可以將測試放在佇列上，例如佇列服務提供的佇列。 在測試例項上執行的測試執行程式可以使測試出列並對軟體執行測試。 一旦完成了測試軟體的測試，就可以取消配置測試例項。

背景：

如果軟體開發團隊利用此類測試來批准對軟體的更改，則執行測試所需的大量時間可能會限制團隊進行程式碼更改的能力，並使更改能夠及時部署到生產環境中。

由於執行軟體測試有時需要很長時間，因此一些軟體開發團隊最終會減少對軟體執行的測試數量。 這意味著程式碼更改可以更快地到達生產環境。 但是，這也意味著軟體包含錯誤的風險大於執行更徹底的測試的風險。 在許多環境中，部署包含錯誤的軟體的風險較高是不可接受的。

上述問題的一種解決方案是利用允許多執行緒執行測試的測試平臺。 使用這樣的平臺，可以在同一過程中同時執行多個測試。 但是，這種解決方案通常有其自身的侷限性。 例如，為了執行多執行緒測試執行，測試開發人員必須以確保測試對多執行緒執行安全的方式編寫測試。 因此，為多執行緒執行建立測試可能需要軟體開發人員進行大量額外的工作。 另外，多執行緒執行僅擴充套件到執行它們的計算機的計算資源（例如CPU和儲存器）的限制。 因此，多執行緒執行測試的好處可能會受到限制。

分散式軟體測試的技術。通過這些技術的實現，開發人員建立的軟體測試可以分發到多個測試例項，以便並行執行。通過以這種方式並行執行軟體測試，與非並行執行相比，可以減少執行測試所需的時間量。此外，通過並行執行軟體測試，可以執行確保高質量軟體所需的大量測試，同時允許軟體及時部署到生產環境中。這些技術使得能夠並行執行軟體測試，而不需要軟體開發者以任何方式修改他們現有的測試。

這裡公開的軟體測試服務被配置為接收對軟體執行測試的請求（這裡可以稱為“被測軟體”）。 該請求可以包括軟體或對軟體的引用，測試或對測試的引用，以及可能的一個或多個測試偏好。 例如，該請求可以由被測軟體的軟體開發者生成並提交給軟體測試服務。

開發人員指定的測試首選項可以定義關於如何將測試分發到測試例項以便並行執行的各種首選項。例如但不限於，測試首選項可以明確指定用於對軟體執行測試的測試例項的數量。作為另一個示例，測試首選項可以指定測試的最大執行時間。在這種情況下，可以基於測試的歷史測試執行時間資料來確定用於在大約最大執行時間內完成測試的測試例項的數量。或者，如果歷史測試執行時間資料不可用於測試，則可以基於與測試類似的其他測試的歷史測試執行時間資料來確定用於在大約最大執行時間內完成測試的測試例項的數量。要進行。測試偏好還可以指定關於執行測試的方式的其他或替代偏好。

一旦確定了用於測試的測試例項的數量，軟體測試服務就可以使測試例項被供應。 例如，在一種配置中，軟體測試服務可以利用在服務提供商網路中執行的按需計算服務來提供測試例項。 測試例項可以是VM例項，軟體容器，專用伺服器計算機或適合於對被測軟體執行測試的其他型別的軟體執行環境。 一旦配置了測試例項，就可以將測試中的軟體和測試執行器部署到測試例項。 測試執行器是可執行軟體，配置為獲得測試，對被測軟體執行測試，並提供測試結果。

在一個特定配置中，軟體測試服務被配置為利用由在服務提供商網路中執行的佇列服務提供的佇列來向在測試例項上執行的測試執行器提供測試。 例如，軟體測試服務可以在這樣的佇列上放置測試或包括對測試的引用的訊息。 在測試例項上執行的測試執行器可以使測試從佇列中出列，並對測試中的軟體執行測試。 測試執行器將繼續出列測試並執行測試，直到佇列中沒有進一步的測試。

軟體測試服務還可以確定是否所有測試都已完成。 如果已完成測試軟體的所有測試，則可以取消配置測試例項。 例如但不限於，可以指示在服務提供商網路中執行的按需計算服務來取消供應測試例項。 通過這種方式，測試例項僅在測試期間使用，並且一旦測試完成就可以銷燬。

Cloud-Based Parallel Concolic Execution

解決路徑爆炸（Path explosion）問題，本文提出了一種名為PACCI的方法，通過利用雲基礎設施來並行化執行並適應計算資源的劇烈變化。PACCI為MapReduce程式設計模型量身定製了執行，並考慮了雲基礎架構的功能。

主要解決了幾個挑戰性的問題：

獨立探索不同的程式路徑。

構建可擴充套件的路徑探索模組，以支援從全域性角度確定測試輸入的優先順序。

初步實驗結果表明，PACCI是可擴充套件的（例如，使用24個節點獲得大約20倍的加速），並且其效率分別在資源波動和節點故障下略微下降約5％和6.1％。

具體而言，PACCI通過將程式的複雜執行視為任務來定製對MapReduce程式設計模型的執行，並動態地將任務劃分為對映子任務並減少子任務。一個map子任務收集一個路徑條件並生成一個測試輸入組，而一個reduce子任務優先生成測試輸入。

設計PACCI時面臨的挑戰：

• 首先，由於具有執行性的迭代性，因此獨立探索每條路徑並非易事。我們通過仔細設計並行的concolic執行來解決這個問題，包括由子任務完成的工作，子任務的連線和介面，子任務的維護和排程等。
• 其次，設計可擴充套件的並不簡單。
• 路徑探索模組，用於支援測試輸入的全域性優先順序。

PACCI將路徑探索演算法放在減少子任務中，以便它具有由對映子任務產生的所有資料的全域性檢視，並允許使用者包括更多路徑探索演算法。

我們已經在Spark和Mesos之上實現了PACCI。 初步評估結果表明，PACCI與計算節點的數量呈線性關係，在資源波動和節點故障下的效率方面表現良好。

主要貢獻：

•我們提出了PACCI，這是一種新穎的並行執行器，可以加速執行，並通過利用雲來適應計算資源的變化。 •我們實現了PACCI，初步結果表明PACCI具有可擴充套件性，即使存在資源波動和節點故障也能很好地執行。 PACCI是https://github.com/SymSecGroup/PACCI的開源軟體。

如何確保每個程式路徑的探索獨立於其他路徑？

遵循MapReduce程式設計模型，PACCI使用對映子任務來探索單個路徑。 每個map子任務都使用一個測試輸入執行程式，收集路徑條件，並生成新的測試輸入（如果有的話）。 我們使用驅動程式來維護和分派map subtasks，以便map subtasks不需要相互協調。

如何實現可擴充套件的globalaware路徑探索模組？

我們在減少例程中實現路徑探索演算法，以便PACCI可以處理所有未執行的測試輸入，即使它們位於不同的從站中。 此外，我們在單獨的模組中包含路徑探索的程式碼，因此分析人員可以通過簡單地擴充套件reduce子任務例程來新增自己的路徑探索演算法。

Test-Driven Development for Parallel Applications

2017 Second International Conference on Information Systems Engineering

John W. Burris

本文將介紹一種使用TDD程序進行並行請求開發的方法，介紹TestDriven開發過程，一個用於並行程式設計的示例API，以及由xUnit單元測試框架促進的單元測試。

MPI

The MPI standard is widely used in the high-performance computing industry and has multiple cross-platform implementations.

MPI規範允許特定於並行應用程式的邏輯錯誤，這些錯誤不容易使用TDD捕獲。

死鎖和競爭條件是兩個這樣的邏輯錯誤

競爭條件是執行結果可以根據從其他非同步執行執行緒接收的訊息順序而改變的條件。

用於確定這些錯誤中任何一個錯誤的可能性的用例的有效性是未來研究的一個領域。

將TDD應用到並行應用的步驟：

識別將在單個執行執行緒中執行的應用程式的部分（在需求中給出）以及將並行執行的軟體部分。

在單個執行執行緒中執行的部分採用傳統的TDD方法，並且可以和並行部分獨立開來。

並行軟體設計的四部分：

partition(分割槽), communication(通訊), agglomeration(集聚), and mapping(對映).

分割槽涉及將系統分解為較小的任務。 通訊是為了實現並行性而建立如何傳遞訊息的計劃。 集聚將流程組合在一起以提高表現。 對映將特定任務分配給特定程序。

Designing and Building Parallel Programs: Concepts and Tools for Parallel Software Engineering. Reading,

COMPI:Concolic Testing for MPI Applications

Concolic Testing：concrete and symbolic混合實際執行和符號執行的測試

Concolic執行維護一個實際狀態和一個符號化狀態：實際狀態將所有變數對映到實際值，符號狀態只對映那些有非實際值的變數。Concolic執行首先用一些給定的或者隨機的輸入來執行程式，收集執行過程中條件語句對輸入的符號化約束，然後使用約束求解器去推理輸入的變化，從而將下一次程式的執行導向另一條執行路徑。

**就是在已有實際輸入得到的路徑上，對分支路徑條件進行取反，就可以讓執行走向另外一條路徑。**這個過程會不斷地重複，加上系統化或啟發式的路徑選擇演算法，直到所有的路徑都被探索，或者使用者定義的覆蓋目標達到，或者時間開銷超過預計。

COMPI:

MPI應用程式的第一個實用的concolic測試工具。

對MPI程式檢測的要求：

• 檢測MPI語義相關的錯誤
• 大規模檢測或診斷複雜的錯誤
• 最終複製並表現出非確定性錯誤

MPI程式的特點：

• 只測試一個程序的標準的concolic測試對於執行多個程序的MPI應用程式來說是不夠的。
• 測試不能發現只能在使用一定數量的程序後才能執行的分支，因為它忽略了MPI語義使得它無法改變程序的數量。

開銷：

• 首先，太大的輸入會使測試變得非常慢，有時甚至會因為所需的記憶體超出計算平臺的記憶體限制而失敗。
• 其次，使用相同的重量級儀器執行所有程序會產生不必要的高開銷，因為並非所有程序都需要執行符號執行。
• 第三，在存在表徵MPI應用程式的迴圈時浪費了太多的努力，因為迴圈導致生成太多冗餘約束並且解決以及使用它們進行測試無助於提高分支覆蓋率。

COMPI降低開銷的策略:

輸入上限、雙向控制、減少約束集

COMPI的工作流程:

Instrumentation

Testing

由於其對MPI語義的瞭解，它通過改變程序數量和焦點過程自動驅動測試。 記錄所有流程的覆蓋範圍可確保準確記錄整體覆蓋範圍。

選用的搜尋策略：

BoundedDFS

Parallel mutation testing

並行執行突變體以提高變異測試的效率

變異測試的開銷：

the number of mutants generated

on the number of test cases

Nm:number of mutants(變異體的數量)

Gt:generation time of one mutant一個變異體的產生時間

Ntc:number of test cases測試用例的數量

Et:execution time of one test case一個測試用例的執行時間

M$_t$=G$_t$*N$_m$+max{Et$_i$ * N$_{tci}$ * (N$_{mi}$+1)}

因此，研究並行變異測試技術是減少突變體執行時間而不失去有效性的必要任務。

本論文主要關注測試執行階段的執行時間

降低執行階段的計算成本。

文章結構：

第2節描述了並行變異測試的一些工作，並證明了對該技術的新研究的必要性。

第3節描述了研究中使用的分佈演算法。

第4節用於執行實驗的工具。

第5節顯示了實驗的設計。

第6節描述了獲得的結果。

第7節給出了一些結論和未來的工作。

作者提出了三種分佈演算法：

按原始順序分發變異體，隨機均勻的分發變異體，突變型變異體的均勻分佈。

關於靜態分佈演算法，作者確定最有效的演算法通過突變型別分配突變體，因為它實現了最高的加速。

突變體分佈的動靜態策略以及測試用例分佈的動靜態策略。

優化計算資源的使用：

通常，使用比處理器更多的塊並且具有相對小的塊來獲得最佳結果。chunk是一組傳送到處理器的任務。

動態策略：

‘Guided Self-Scheduling’ 引導式自我排程

Factoring Self-Scheduling保理自我排程

‘Trapezoid Self-Scheduling’ 梯形自我排程

‘Quadratic Self-Scheduling’ 二次自我排程

實現了兩種靜態和三種動態演算法

• DMBO(Distribute Mutants Between Operators )在運算元之間分配突變體。根據變異體集合劃分。這是一種靜態演算法，將給定變異運算元生成的突變體分佈在與處理器一樣多的塊中。每個塊包含m$_{op}$/p個變異體。這種演算法減少了節點之間通訊的時間，並且網路流量是最小的。因為每個處理器僅在突變過程中接收一次塊。但是每個處理器的處理時間不同。 然而，由於突變體和測試用例的性質，並非所有的執行都需要相同的時間，因此可能和Offutt等人的工作一樣。 [16]顯示，某些處理器將先於其他處理器完成，總處理時間將是最慢處理器所用的時間。
• DTC(Distribute Test Cases )適應負載均衡策略的變異測試。靜態演算法，**根據測試用例的數量劃分。**每個塊包含t/p個測試用例。缺點是處理器之間不通訊。
• GMOD(Give Mutants On Demand )按需提供突變體演算法。是一個動態演算法。將執行分成僅包含一個具有所有測試用例的突變體的塊。因此，分幾次將塊傳送到並行處理器，直到所有塊都被傳送出去。增加了節點之間的通訊，因為許多塊被髮送到每個處理器並且網路流量也增加了。因此網路特性可能對總時間有很大影響。由於演算法的動態特性，所有並行處理器幾乎可以同時完成。
• GTCOD(Give Test Cases On Demand )適應負載均衡分配策略的。動態演算法，將執行分成塊，每個塊只包含一個測試用例和所有突變體。增加了節點之間的通訊，因為許多快被髮送到每個處理器並且網路流量增加，這個演算法增加了傳輸GOD的演算法，因為突變體的數量通常遠高於測試用例的數量。處理器之間沒有通訊。
• PEDRO( Dynamic Ranking and Ordering )動態排序演算法。包含倆個階段：**1，排名階段類似於DMBO演算法。2，排序階段與GMOD演算法類似。**第一個階段不會增加網路流量，第二個階段可以防止某些並行處理器在其他處理器之前完成。可以配置的兩個引數：1，使用者確定的整數用於確定每個階段中要執行的塊的數量。2，並行處理器的數量，提供使演算法適應並行系統所需的資訊。排名階段向每個處理器傳送相同數量的工作。這個階段對於後續訂購階段的節點排名很有用。 在此第一階段，執行僅傳送到處理器節點一次，從而減少了網路流量。

工具介紹：

Bacterio：

local node;remote executor node;facade node

每一個節點都可以放在不同的計算機上。

local node:

create mutants, execute mutants and view results

執行過程：

突變體建立和結果計算在本地節點中執行，並且只有測試用例的執行在遠端執行器節點上並行執行。這些節點接收測試和突變體，執行突變體併發送回 檢測結果。 外觀節點負責根據所選擇的分發演算法從本地節點接收所有突變體和測試以及它們在遠端執行器節點之間的分佈。

本地節點：

它生成突變體並使用從其他節點獲得的測試結果計算測試實現的突變分數。

遠端節點：

充當執行程式伺服器，當突變過程開始時，該節點未被通知並詢問塊（由突變體和測試集組成）。當接收到儲存空間時，遠端執行程式會執行測試，以獲得包含塊的重要資訊，並將測試結果傳送回去。 然後它要求更多的執行。 如果沒有更多的執行要執行，它會再次等待另一個突變過

外觀節點:

實驗在四個應用程式上進行。 其中三個用於比較第3節中描述的五種演算法。然後將兩種最相似的演算法與第四種應用進行比較。 所有應用程式都是用Java編寫的。

這四種應用程式分別使:

Monopoly:用程式模擬Monopoly棋盤遊戲。

Cinema：電影院管理系統。

Chess：線上國際象棋遊戲，實驗中僅使用伺服器部分。

Analysis package of Commons Math:包含數學和統計功能的類庫。

每個應用都有一個Junit的測試套件。

實驗結果及分析：

PEDRO and GMOD 演算法獲得了較好的結果。 DMBO是第三個比較好的演算法。

主要原因在於等待時間。另一個原因是通訊時間的影響。因此，等待時間對總時間幾乎沒有影響，這意味著以等待時間為代價減少總時間的演算法（GMOD和PEDRO演算法）優於反向演算法（DMBO演算法）。

remoteExecutor節點無法知道被其他remoteExecutor節點殺死的突變體，因此，它可能執行已經被另一個節點殺死的突變體。

the DTC and GTCOD algorithms ran more executions than the others, with GTCOD algorithm being worse than DTC algorithm

(i)研究並行執行技術在增加並行節點數量時的行為，以及（ii）研究該技術在同構和異構環境中的行為。

當計算機數量顯著增長時，就會達到一個點，效率不會增加而是會降低。

並行執行技術可以快速有效地降低突變的計算成本。 由於它是第一個快速降低計算成本的部分，因此只需要少量計算機即可。 例如，在實驗中使用具有八個平行計算機的環境，即8C1異構環境。 在Analysis包的情況下，總時間將執行時間減少了86.55％（從6131減少到825秒）。