2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE)
VRExplorer: A Model-based Approach for Semi-Automated Testing of Virtual Reality Scenes Zhengyang Zhu∗‡ , Hong-Ning Dai† , Hanyang Guo∗ , Zeqin Liao∗ , Zibin Zheng∗ ∗ School of Software Engineering, Sun Yat-sen University, Zhuhai, China
{zhuzhy57, guohy36, liaozq8}@mail2.sysu.edu.cn, [email protected] † Department of Computer Science, Hong Kong Baptist University, Hong Kong SAR, [email protected]
arXiv:2607.10174v1 [cs.SE] 11 Jul 2026
‡ Peng Cheng Laboratory, Shenzhen, China
Abstract—With the proliferation of Virtual Reality (VR) markets, VR applications are rapidly expanding in scale and complexity, thereby driving an urgent need for assuring VR software quality. Different from traditional mobile applications and computer software, VR testing faces unique challenges due to diverse interactions with virtual objects, complex 3D virtual environments, and intricate sequences to complete tasks. All of these emerging challenges hinder existing VR testing tools from effectively and systematically testing VR applications. In this paper, we present VRExplorer, a novel model-based testing tool to effectively interact with diverse virtual objects and explore complex VR scenes. Particularly, we design the Entity, Action, and Task (EAT) framework for modeling diverse VR interactions in a generic way. Built upon the EAT framework, we then present the VRExplorer agent, which can achieve effective scene exploration by incorporating meticulously designed path-finding algorithms into Unity’s NavMesh. Moreover, the VRExplorer agent can also systematically execute interaction decisions on top of the Probabilistic Finite State Machine (PFSM). Experimental evaluation on 11 representative VR projects shows that VRExplorer consistently outperforms the state-of-the-art (SOTA) approach VRGuide by achieving significantly higher coverage and better efficiency. Specifically, VRExplorer yields up to 122.8% and 52.8% improvements over VRGuide in terms of executable lines of code (ELOC) coverage and method (function) coverage, respectively. Furthermore, ablation results also verify the essential contributions of each designed module. More importantly, our VRExplorer has successfully detected two functional bugs and one non-functional bug from real-world projects. Index Terms—Software Testing, Virtual Reality, Model-based Testing, Scene Exploration © 2025 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
I. I NTRODUCTION Virtual reality (VR), working together with other relevant technologies, such as Augmented Reality (AR) and Extended Reality (XR), aims to provide users with an immersive mixed reality (MR) experience [1]. Current VR applications have proliferated in diverse fields, such as medical treatment, education, audiovisual entertainment, training simulations, manufacturing, and gaming [1–6]. According to Fortune’s market report [7], the global VR market is projected to grow from $44.4 billion in 2025 to $244.84 billion in 2032. With the proliferation of VR markets, VR applications are also rapidly expanding in terms of scale and complexity. Ensuring the software quality of such complex VR applications
AUTHOR ACCEPTED M ANUSCRIPT
becomes an urgent need. As a critical procedure of software development, testing can thoroughly evaluate a software to check whether both requirements and functional needs are fulfilled without defects. To cater to this growing demand in VR applications, extensive efforts have been made in VR testing, while many of them still largely rely on manual testing, which remains highly labor-intensive and inefficient [8, 9]. Most recently, several studies have aimed to test VR applications automatically. As an early attempt, VRTest [10] explores VR scenes by controlling the orientation of the camera to interact with virtual objects. VRGuide [11] has further improved VRTest by optimizing exploration routes to circumvent occluded objects. Besides VRTest and VRGuide, other researchers also explore using other techniques, such as computer vision (CV) and generative artificial intelligence (GenAI) to achieve scene exploration [12] or understanding [13]. However, these testing tools are still struggling to test VR applications with increased complexity. The challenges in VR testing stem from the unique features of VR applications, sharply different from conventional mobile applications and computer software. First, enabled by diverse peripheral devices (e.g., VR headsets, controllers, joysticks, wands, and haptic gloves), VR systems can support a larger diversity of interactions (such as grabbing, pressing, touching, pulling, climbing, and shooting) than conventional mobile systems and PCs [14, 15]. Unfortunately, current VR testing tools cannot properly characterize and represent the diverse interaction behaviors. For example, the state-of-theart (SOTA) VR testing tool, VRGuide, can only test virtual objects with the “click” interaction. Second, VR applications contain complex 3D virtual environments with interactions with virtual objects, thereby introducing a vast exploration state space. Take EscapeGameVR, a popular open-source VR gaming application, as an example, which contains 44 scenes, 8,256 GameObjects, and 1,377 C# script files. Third, VR testing often requires completing a sequence of tasks, e.g., finding a key, then using the key to open a door, next turning a handle, and finally pressing a button to escape. It is nontrivial to accomplish these complex tasks since they involve diverse interactions and trigger either events or actions in a specific order. In summary, the diverse and intricate nature of the VR interactions, coupled with large-scale virtual spaces and complex task-completion sequences, makes it difficult
DOI: 10.1109/ASE63991.2025.00047
1
2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE)
to comprehensively and efficiently test VR applications in a systematic and repeatable manner. Our Approach. To address the above challenges, we present VRExplorer to thoroughly test Unity-based VR applications by conducting in-depth scene exploration and comprehensive interactions with virtual objects. Notably, we consider Unity-based VR applications mainly due to Unity’s dominant role in VR/MR markets [16]. To tackle the first challenge mentioned above, we design the Entity, Action, and Task (EAT) framework for modeling VR interaction behaviors in a generic way. This hierarchical framework enables a reusable modeling process across VR applications developed by diverse Unity versions and interaction plugins, such as XRIT [17, 18], S TEAM VR [19–21], and MRTK [22, 23], thereby enhancing cross-project generalizability. To address the second challenge, we present the VRExplorer agent built upon the EAT framework. Incorporating meticulously designed path-finding algorithms into Unity’s NavMesh, the VRExplorer agent can achieve autonomous navigation in 3D virtual environments. Moreover, the VRExplorer agent can also systematically execute diverse interaction decisions on top of the Probabilistic Finite State Machine (PFSM). To address the third challenge, the proposed model-based approach transforms intricate VR task execution sequences into structured task models to enable systematic testing and automated execution. Evaluation. To comprehensively evaluate the proposed VRExplorer, we conduct extensive experiments on 11 representative VR projects. The experimental results demonstrate that the proposed VRExplorer outperforms the SOTA approach VRGuide with average performance gains of 122.8% and 52.8% in terms of executable lines of code (ELOC) coverage and method (function) coverage, respectively. Moreover, the ablation study on the five ablated variants of VRExplorer also validates the necessity of all modules of the EAT framework. More importantly, VRExplorer has successfully detected two previously unknown real-world bugs (i.e., one functional bug and one non-functional bug), which can nevertheless be detected by the baseline. Further, VRExplorer has also successfully detected one previously-confirmed bug. Main Contributions are summarized as follows: We design the EAT framework for modeling complex interaction behaviors and tasks in VR applications. To the best of our knowledge, EAT is the first generic three-layer abstraction framework for VR testing based on the objectoriented programming (OOP) paradigm. 1 • We present VRExplorer , a novel model-based testing tool to achieve effective interactions with diverse virtual objects and the exploration of complex VR scenes. • We evaluate VRExplorer extensively on 11 representative VR projects and demonstrate its consistent performance superior to the SOTA approach in terms of ELOC coverage, method coverage, and interactable object coverage while preserving high efficiency. Moreover, our VRExplorer can also successfully detect real-world bugs in VR projects. •
1 https://github.com/TsingPig/VRExplorer Release
AUTHOR ACCEPTED M ANUSCRIPT
II. BACKGROUND Interactions in Unity-based VR Applications. A Unitybased VR application typically consists of multiple Scenes, each of which is structurally represented by a hierarchy of GameObjects. These GameObjects represent all visible and interactive elements in the 3D virtual environment and can be composed of various components, such as meshes, scripts, and colliders. Unity provides VR application developers with a rich set of tools for implementing immersive interactions. As Unity’s official framework, XRIT [17] can support common VR input modalities such as ray-based selection, direct grabbing, teleportation, and gesture recognition. These interactions are typically implemented using component-based scripts attached to objects, while often relying on trigger colliders or physics events. However, the implementation logic varies significantly across projects, especially when thirdparty packages are used, thereby increasing the complexity of generalizing automated testing across different VR projects. Mono Scripts in Unity-based Application Development. In Unity-based VR application development, Mono scripts constitute the fundamental building blocks for implementing interactive behaviors. These C# classes inherit properties from Unity’s core MonoBehaviour [24] base class, enabling them to leverage Unity’s component-based architecture. Through the Unity Inspector, developers attach these scripts to GameObjects to create diverse objects. For example, a gun can be attached with a XRGun class inherited from MonoBehaviour, with properties referencing the bullet prefab2 , Shoot(), etc. NavMesh-Based Navigation in Unity. Unity’s NavMesh system [25–27] provides a mechanism to traverse 3D environments using navigation meshes generated from static scene geometry. It supports obstacle avoidance, pathfinding, and dynamic updates, making it suitable for simulating players’ movement. In VR testing, NavMesh can be leveraged to automate scene exploration by guiding a virtual agent through reachable areas. However, it only supports locomotion and requires external control logic to handle task-specific actions, such as interacting with objects or triggering events. III. A PPROACH As shown in Fig. 1, the proposed VRExplorer works by first collecting and analyzing open-source VR projects in § III-A. Then, it implements the EAT framework in § III-C after model extraction in § III-B. Next, it conducts testing by VRExplorer in § III-D based on the EAT framework, NavMesh, and PFSM. A. Project Collection and Analysis To comprehensively investigate interaction behaviors in VR, we collect open-source Unity VR projects with diverse applications, interactions, and scene types (details in § V-A). Based on this dataset, we perform a two-pass semiautomated analysis — static pass and dynamic pass—and then consolidate the results to construct Model Abstraction, including Object and Action abstractions (§ III-B). These 2 Prefab is a reusable template encapsulating GameObjects and components.
DOI: 10.1109/ASE63991.2025.00047
2
2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE)
S1. Scene/prefab scan
S2. Script binding extraction
Parallel and serial combinations
1 Preliminary Scene
Configuration
2
Implement Implement XR Joystick XR Button Entity Layer
Camera Hand Controller Collider
Full Project
Bake NavMesh
VRExplorer Agent Interaction & Scene Analysis
Customizing Entity
Decision Making
Interface Configuration
PFSM
Input Next Interactable
Unity Scene
NavMesh Data
Third Plugins
Decision Making
Autonomous Event Invocation
Task Execution
Scripts Implemented Entity Interface
Output
Task Generator Mono Scripts
Abstract Models
Behavior Execution and Scene Exploration
Core Scripts
Scene with NavMesh (for navigation)
Extract abstraction models
Entity Interface
Task Execution
Trigger Base Entity Inherit Inherit Grabbable Entity Triggerable Entity
Heuristic rules & experiences
Implementation Interface
Original Scene
Grab
3
B Model Abstraction (§III-B)
Autonomous Event Invocation
Base Action Inherit Inherit Grab Action Trigger Action
Action Layer
D3. Heuristic validation of task logic
D VRExplorer Testing (§III-D)
Task Generator & Customized Task Model
Task Layer
D2. Interaction flow tracing
S3. Interaction pattern identification
C EAT Framework (§III-C)
Implement XR Box
D1. Runtime state observation
Heuristic rules & experiences
Unity-based VR Projects
Open Source Repositories
Environment Interactables Box
Dynamic Analysis
Collect by Tags
Static Analysis
A Project Collection & Analysis (§III-A)
Task Model C# Scripts File
GameObjects
Fig. 1: Overview of VRExplorer abstractions are subsequently fed into the EAT framework (§ III-C) and the PFSM-based testing workflow (§ III-D). Static pass (S1–S3). S1: Scene/prefab scan. We parse scene hierarchies and prefabs to enumerate GameObjects with attached components, and prune non-interactable infrastructure (e.g., static walls) that are not connected to core interactions. S2: Script binding extraction. We inspect MonoBehaviourbased scripts and their serialized fields to recover object– script bindings (e.g., references to targets). S3: Interaction pattern identification. We analyze interaction-related APIs and callback signatures to fingerprint typical behaviors. The interaction distribution will be detailed in § IV-A. Dynamic pass (D1–D3). Static inspection cannot observe runtime object creation, dynamic component attachment, or goal-oriented task logic. To complement this effect, we conduct a lightweight but human-guided runtime analysis guided by gameplay flows and task objectives: D1: Runtime state observation. At each frame t, we record snapshots of active GameObjects Gt and their component sets Ct . Comparing consecutive states (∆Gt , ∆Ct ), we identify dynamically instantiated objects and runtime-added components. D2: Interaction flow tracing. Following execution evidence such as console outputs, function call stacks, and Unity event dispatches during gameplay, we trace when and how scripts are actually triggered (e.g., input events, collision handlers, and task-specific event chains). D3: Heuristic validation of task logic. Four experienced engineers heuristically reconstruct event sequences observed during gameplay to approximate these flows and validate whether each interaction contributes essentially to task progression or it is only incidental. B. Model Abstraction Heuristic Model Abstraction. We summarize the heuristic experiences and rules extracted from the project analysis in order to test the framework’s effectiveness and get a preliminary model abstraction. Specifically, during the project analysis process, we merge static and dynamic findings into abstraction models heuristically and classify common VR interaction behaviors into abstract actions based on OOP principles, as
AUTHOR ACCEPTED M ANUSCRIPT
shown in Part B in Fig. 1. When testing a real-world project, engineers can absolutely use the model we had constructed, while also experiencing core gameplay and performing the two-pass manual analysis as described in § III-A if they have customized testing demands. New interaction patterns are either matched with existing types or newly defined via new Action interfaces automatically. While execution is fully automated, abstraction still requires human-in-the-loop analysis due to the complexity of VR interactions and the limited domain-specific knowledge of existing tools. Objects are annotated with interactable features (e.g., Grabbable, Triggerable, and Transformable); interactions are lifted into abstract actions. This consolidated model (i) seeds the Entity Interface Layer in EAT by proposing interface candidates (e.g., IGrabbable and ITriggerable), (ii) provides action-level semantics to the Action Class Layer, and (iii) surfaces callable functions and UnityEvents to populate the task (§ III-D). TABLE I: Example of Generalizing VR Interactable Objects VR Interactable Objects Box, Coin, etc. Button Joystick Gun, Cigarette Lighter, etc.
Interactable Features Grabbable Triggerable Transformable Grabbable and Triggerable
Abstraction of Interactable Objects. We first generalize VR interactable objects into abstract objects containing interactable features. Table I gives an example of VR interactable objects with interactable features, which can determine interaction properties. For instance, objects like boxes and coins can be typically classified as Grabbable, meaning that they can be picked up, while objects like buttons and joysticks are considered Triggerable with two attributes triggering and triggered. Notably, some objects may possess multiple interactable features. For instance, a gun or a cigarette lighter possesses both Grabbable and Triggerable attributes, representing complex interactions to support not only grabbing but also acting on its function, such as shooting or turning on a button. Abstraction of Actions. We then classify VR interaction behaviors into abstract actions. Table II shows an example of a VR interactive scene, in which pressing a button, closing or
DOI: 10.1109/ASE63991.2025.00047
3
2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE)
TABLE II: Generalizing Interactions into Abstract Actions
to Approcach 1 Move Move to
1
The Gun Approach The Gun
Abstract Actions Move Action Trigger Action Grab Action Transform Action
The Grab-And-Shoot-Gun Task Move Action
2 Try to Grab theTry Gun to Grab the Gun
Grab Action Move Action
2
Trigger Action
Move Around Around Randomly; 3 Move 3 Randomly; Try to Try to Fire the Gun Fire the Gun
Move Action
Trigger Action
Trigger Action
Parallel Action
VR Interaction Behaviors Move Around, Jump, Fly, etc. Press, Pull, Open/Close, Turn On/Off, etc. Grab, Throw Move/Scale/Rotate Objects
(a) Doors Closed (NavMesh separated)
(b) Doors Opened (NavMesh connected) Fig. 3: Dynamic doors with NavMesh Obstacle (Carve enabled)
Asynchronous Action
(a) GASG Process
(b) Action Model of GASG task
private List<BaseAction> GrabAndShootGunTask( IGrabbableEntity grabbableEntity, ITriggerableEntity triggerableEntity) { List<BaseAction> task = new List<BaseAction>(){ new MoveAction(_navMeshAgent, moveSpeed, grabbableEntity.transform.position), new GrabAction(leftHandController, grabbableEntity, new List<BaseAction>(){ new ParallelAction(new List<BaseAction>(){ new MoveAction(_navMeshAgent, moveSpeed, GetRandomTwitchTarget(transform.position)), new TriggerAction(2.5f, triggerableEntity) }) }) }; return task; }
(c) C# Code Snippet of GASG task
Fig. 2: Task Instance of Grab-And-Shoot-Gun opening a door, turning on or off a lamp, and pulling a joystick, can be conceptualized as compositions of a continuous process with a following event. Specifically, the player’s action, pulling a joystick, can be classified into a continuous pulling process and an event triggered after pulling is over. We classify a behavior with such characteristics into Trigger Action. C. EAT Framework Based on the model abstraction in § III-B, we propose a three-layer framework called EAT, as shown in Part C in Fig. 1. Entity Interface Layer. Based on the interactable objects’ abstraction, we define specific interfaces to encapsulate their corresponding attributes. Particularly, we define a base interface, called BaseEntity, which includes the Transform property to represent the object’s position, rotation, and scale, as well as the Name property. Thereafter, all other entity interfaces inherit this base interface. For example, an interface Triggerable includes two attributes triggering and triggered with the Enum property. The Entity Interface layer provides customized interfaces tailored to specific features required by the Action layer. Notably, complex interactable features can be efficiently represented through multi-inheritance by multiple interfaces, thereby allowing for higher flexibility and modularity in defining VR interactions. Action Class Layer. We then extract behaviors with identical characteristics into the same action. We first define an abstract base class, namely BaseAction with a virtual asynchronous Execute() method. All other action classes inherit this base class. The Action layer can interact with the Entity Interface Layer and provide functional APIs for VRExplorer to simulate real players’ interactive actions. For example, Trigger Action can be concreted into the TriggerAction class, which
AUTHOR ACCEPTED M ANUSCRIPT
consists of an asynchronous method Triggering() and a synchronous method Triggered(). Task Model Layer. A composition task consists of multiple parallel and sequential actions. Parallel action executes asynchronous methods simultaneously, while sequential actions follow a strict order to complete the previous action before proceeding to the next. The Task Model layer includes a task generator and multiple predefined VR interaction tasks. The task generator creates tasks by accepting either a MonoBehaviour instance or an array of entities (BaseEntity[]). We derive the predefined tasks from commonly used task models. Fig. 2 depicts an example of the Grab-And-Shoot-Gun (GASG) task, which consists of three steps: approaching the table, picking up the gun, and shooting while walking in Fig. 2(a). Fig. 2(b) elaborates on the corresponding action model, where the horizontal axis represents the timeline of asynchronous actions starting with Move Action, followed by Parallel Action, within which three actions execute concurrently. The corresponding code is also shown in Fig. 2(c). D. VRExplorer Testing As shown in Part D in Fig. 1, VRExplorer’s testing process works in three sequential steps: 1 Preliminary Scene Configuration, before scene exploration, we facilitate the agent’s navigation capability based on Unity’s NavMeshAgent [26] via NavMesh baking. We first configure terrain objects, such as floors and walls, to be static. Regarding those objects that may dynamically move, such as doors, we attach the NavMesh Obstacle [27] component with the enabled Carve option, thereby allowing them to dynamically modify the NavMesh. Fig. 3 depicts an example of opening and closing dynamic doors. 2 Implementation Interface, on top of the EAT framework, implementing interactable interfaces is the core to tackle two challenges: (1) lack of generalizability caused by diverse Unity versions and the fragmentation of the VR development ecosystem; and (2) intricate scene exploration and VR interactions. Using interfaces to encapsulate implementation details can enable testing for a diversity of VR applications. To ensure coverage and verify the reliability of interaction methods, test engineers need to select and customize the appropriate Entity layer interfaces for the Mono scripts related to the core VR interaction logic in the target project with the corresponding interface functions implemented. Take Procedure 1 as an example3 , in which a gun class XRGun possessing 3 The implementation of the entity interface’s code lines is marked blue.
DOI: 10.1109/ASE63991.2025.00047
4
2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE)
TABLE III: State Transition Table of PFSM
Procedure 1 Entity Interface Layer Implementation Example. 1: class XRGun implements ITriggerable, IGrabbable: 2: property TriggeringTime ← 1.5 3: property Name ← “Gun” 4: property Grabbable: 5: if component exists then return it 6: else add new Grabbable component 7: method Triggerring() do nothing 8: method Triggerred() calls Fire() 9: method OnGrabbed() do nothing 10: field projectilePrefab: GameObject 11: field startPoint: Transform 12: field launchSpeed: float 13: method Fire(): 14: Instantiate projectile and apply forces 15: method ApplyForce(rigidbody): 16: Calculate and apply physics forces
both Grabbable and Triggerable features, can be implemented by inheriting MonoBehaviour while simultaneously implementing the IGrabbable and ITriggerable interfaces. This design allows the gun object to be both grabbed and triggered during VR interactions without additional script components. This approach allows XRGun to seamlessly integrate multiple interaction capabilities (i.e., grabbable and triggerable). Leveraging interface composition, we can flexibly define and extend object behaviors without modifying the base class hierarchy, thereby promoting code reusability and achieving modular design in the VR interaction system. 3 Scene Exploration with Behavior Execution. after completing the scene configuration and implementing interactable interfaces, VRExplorer automatically performs scene exploration and VR interactions by executing the corresponding behaviors. We design two types of behaviors: task execution and autonomous event invocation. When executing tasks, VRExplorer perceives the scene and inputs MonoBehaviour instances or an array of entities (BaseEntity[]) into the task generator to obtain and execute the corresponding tasks. Notably, players in VR environments not only interact with objects but also invoke autonomous events, such as casting skills to gain acceleration buffs. PFSM. To comprehensively cover such testing cases, VRExplorer maintains a configurable list of UnityEvents, allowing test engineers to easily customize the functions to be covered by configuring them in the Inspector before testing. These two types of behaviors constitute the behavior space, where each behavior can be regarded as a node. The behavior space itself forms a directed graph composed of these nodes. For behavior decision-making, VRExplorer employs PFSM to determine transitions between nodes, thereby defining the topology of the …… 1
𝑇𝑖 : Grab-and-Shoot-Gun
𝒑
𝐸𝑗 : Release Speed-Up Skills 2
𝑇𝑖+1 : Press-Button …… Actual Transition
𝟏−𝒑
Next State
Condition
Probability
Ti Ti Ej Ej Ti Ej
Ti+1 Ej Ej+1 Ti+1 Ti+1 Ej+1
Default Default Default Default E exhausted T exhausted
1−p p p 1−p 1.0 1.0
directed graph. We use T = {T1 , T2 , . . . , TN } to denote the set of all task states, where Ti represents the i-th task state in the execution sequence, with i ∈ {1, 2, . . . , N }. Similarly, we use E = {E1 , E2 , . . . , EM } to denote the set of exploration states, where Ej represents the j-th exploration state in the execution sequence, with j ∈ {1, 2, . . . , M }. At each decision point in PFSM, a variable determines the transition direction. The probability of transitioning to an exploration state (Ej ) is denoted by p while the probability of transitioning to a task state (Ti ) is (1 − p). Fig. 4 depicts an example of state transition in a VR scene, where Speed-Up Skills node and Slow-Time Skills node are two example nodes of an autonomous event adding buffs to the player, while GASG node and Press-Button (PB) node are two example nodes of the task. Those four nodes are independent of each other, while the PFSM is responsible for decision-making and state transitions among them. Table III lists all the state transitions. Path-finding for Navigation. We implement two algorithms: (i) a Greedy algorithm, which follows a local optimization strategy based on the shortest path principle, and (ii) a Backtracking algorithm with Pruning, which searches for globally optimal solutions. Since the Greedy algorithm significantly reduces time complexity, fulfilling the real-time requirements of VR testing, we mainly adopt it in our experiments (§ VI presenting a comparison of the two algorithms). In summary, VRExplorer continuously obtains scene information, decides the current behavior to execute, and receives feedback after performing the behavior. This process is repeated until all interactable objects and events are covered. IV. E VALUATION OF VRExplorer A. Implementation Project Collection and Analysis. We implemented a crawler to collect Unity-based VR GitHub projects with keywords like “VR”, “AR”, “unity”, and “xr”. From 971 initially filtered projects, we manually performed quality checks (e.g., compilation errors and version conflicts), consequently retaining 102 high-quality projects. We then analyze the structural and interaction characteristics of all projects in the dataset to assess their representativeness and complexity. Table IV shows varied project sizes. While most projects are relatively small (medians containing 71.5 scripts, 6,129 LOC, 620 files, and 8 scenes), a few of them with large sizes markedly raise the
𝒑
𝐸𝑗+1 : Release Slow3
Current State
TABLE IV: Statistical Metrics of Collected 102 Projects.
Time Skills
Metric
Mean
Variance
Min
Q1
Median
Q3
Max
……
Scripts LOC Files Scenes
166.45 19,910.85 902.07 18.12
110,953.52 1,851,165,810.13 902,718.22 455.06
2 256 21 1
26.25 2,707.25 301.25 4.00
71.50 6,129.00 620.50 8.00
130.25 13,762.75 1,090.00 30.25
2,004 237,725 5,303 128
Probable Transition
Fig. 4: Example of PFSM State Transition in a VR Scene.
AUTHOR ACCEPTED M ANUSCRIPT
DOI: 10.1109/ASE63991.2025.00047
5