## 6 Discussion  
The experimental results demonstrate the effectiveness of our task allocation-based ensemble fuzzing method in enhancing the overall testing effectiveness across the majority of tested programs. This indicates that our proposed method is genuinely effective in enhancing the efficiency of fuzzy testing. However, during the experiment, we did observe some limitations in the division method based on the callgraph of the tested program. Our  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Target** & **AFLTeam** & **OEF** & **TAEF** & **TAEF vs. AFLTeam** & \multicolumn{2}{c}{**TAEF vs. OEF**} \\ \hline  & & & & **Improvement** & **Significance** & **Improvement** & **Significance** \\ \hline
**pngimage** & 4624 & 4604 & **4636** & **0.26\%\(\uparrow\)** & ns & **0.70\%\(\uparrow\)** & *** \\
**djpeg** & 2563 & 2905 & **3015** & **17.64\%\(\uparrow\)** &  
task division method may be ineffective or even have negative effects for certain specially tested programs. Specifically, our method may encounter the following challenges:  
Firstly, before dividing the callgraph, we transform it into a minimum spanning tree, which eliminates any possible cyclic calls in the callgraph. It means that, in programs that commonly use cyclic calls, the results of task division deviate from the original structure of the program being tested and therefore may not effectively guide fuzzing. In such cases, our task division method may be considered invalid.  
Furthermore, we assume that the callgraph of the program being tested, when converted into a minimum spanning tree, is a fairly balanced tree (which is indeed the case in most situations). However, if a tested program has a single and deep function call relationship, where most nodes in the resulting minimum spanning tree only have one child node, it becomes necessary to cover previous functions to test the generated functions of that program. In such cases, the task division itself loses its purpose and may result in the ineffectiveness of our method. Moreover, there is a risk of wasting some of the fuzzing instances that are intended for testing deep-level functions, which can lead to counterproductive outcomes.  
Finally, we calculate the expected effort for each function based on the number of branches it contains and the number of branches that have not been covered yet to balance the workload among subtasks. In theory, the more uncovered branches in a function, the more exploration time should be allocated for exploring this function, hoping to cover these remaining branches. Therefore, the expected workload for exploring this function should be greater. However, in reality, some entry conditions for certain branches in the tested program are too difficult for fuzzers and are almost impossible to reach. Spending significant amounts of time attempting to cover these branches is unlikely to yield any benefits and will only hinder the overall efficiency of fuzzing. In exceptional circumstances, if a function contains a large number of branches that are virtually impossible to enter, the calculated expected effort (i.e., weight) for that function will be high. If a subtask consists entirely of such functions, no effective new seeds will likely be found for that subtask, resulting in wasting precious fuzzing time.