# Attention Transfer Reinforcement Learning for Test Case Prioritization in Continuous Integration
## 4 ATRL-TCP: Attention Transfer Reinforcement Learning for TCP  
RETECS excels in prioritizing test cases with rich historical execution information but performs poorly when such information is insufficient. PRM, on the other hand, mitigates the impact of limited historical information by focusing on the relative relationships among test cases, but it fails to fully utilize individual test case features. Existing methods lack the ability to automatically adjust their strategies based on the characteristics of test cases, resulting in weak generalization capabilities. Therefore, this study proposes an approach that evaluates the test case set from the perspective of execution information richness. We quantify the richness of historical information using metrics such as the number of executions across historical cycles and defect detection rate. If an individual test case has extensive historical execution data and a high defect detection rate, the model should prioritize its fault detection capability. Conversely, when historical information is sparse, the model should consider the relative order among test cases from a global perspective, enabling a \"shift in model attention\". This approach allows the model to adaptively adjust its optimization strategy based on the characteristics of the test case set, thereby enhancing its generalization capability. We divided the observation space into two components:  
\[\text{State}=[\text{Duration, Lastrun, results, Length, Error rate}]\]  
The first part includes \(Duration\), representing the execution time of the test case; \(Lastrun\), indicating the time since the last execution; and \(results\), denoting historical execution outcomes. These constitute the primary features of the test case. This information represents the fundamental characteristics of test cases and serves as the primary input for \begin{table}
\begin{tabular}{p{56.9 pt} p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Method** & **Model Input** & **Advantage Application Scenarios** & **Limitations** \\ \hline RETECS & Input a test case each time and sort it based on its own characteristics. & A single test case has a high cumulative execution frequency and rich features. & When there are a large number of test cases and the average execution frequency is low, the sorting effect is poor. \\ PRM & Input test cases at once and sort them based on their relative relationships. & A large number of test cases and multiple executions. & When the number of test cases is small, it is difficult to effectively utilize the characteristic information of the test cases themselves. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Summary of RETECS and PRM methods. prioritization. Regardless of whether the model focuses on individual test cases or their relative relationships, these fundamental features are essential as input. The second part consists of _Length_ and _Errorrate_. _Length_ represents the length of historical information, which measures its richness. _Errorrate_ indicates the error rate during execution, which measures its fault-detection capability. If the feature information of a test case is sufficiently rich, the model should prioritize these test cases. If the historical information is limited, the model can focus on the relative relationships among test cases and generate a prioritization sequence from a global perspective. If so, the model should focus more on the attributes of the individual test case, enhancing its exploration of single test cases. If not, the model should prioritize the interrelationships within the test case subset, designing prioritization strategies from a global perspective. Due to the presence of the two focal points, we need to design a targeted reward function. For individual test cases, the primary focus should be on their fault-detection capability, with the corresponding reward function being the Test Case Failure Reward:  
\[\text{reward}_{i}^{\text{fault}}(t)= \begin{cases}1-\text{t.verdict}_{i},& \text{if }t\in TS_{i}\\ 0,&\text{otherwise}\end{cases}