On Extracting Tests from a Testable Model in the Context of Domain Engineering
Notice bibliographique
Résumé
Software testing is the traditional way to verify the functionality of a given software system against its requirements. In domain engineering, these requirements consist of variabilities and commonalities observed in a domain and captured in a domain model [5]. We remark that the latter may be used to obtain an elaborate design; however tests cannot be derived from it. This observation proceeds from the fact that testing techniques relevant to single-system engineering cannot deal with the variability intrinsic to a domain. Therefore, in the context of domain engineering, we claim that there is a need for a new modeling approach enabling domain testing. We have proposed elsewhere [1, 3, 4] a testable [2] domain model (based on the domain requirements) that takes the form of generative contracts. In this paper, we present a test extraction technique applicable to this testable model. This technique generates tests for validating behavioural aspects of an implemented member of the domain against that member's requirements. That is, upon selecting a specific member to test, the variability of domain tests is eliminated, resulting in member- specific tests, which are to be bound to artefacts of that member's corresponding implementation in order to obtain executable tests for this member. A case study on a domain-specific testable model will illustrate the steps of our proposed test extraction technique.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,003 | 0,029 |
| Méta-épidémiologie (sens strict) | 0,002 | 0,001 |
| Méta-épidémiologie (sens large) | 0,001 | 0,002 |
| Bibliométrie | 0,003 | 0,002 |
| Études des sciences et des technologies | 0,001 | 0,003 |
| Communication savante | 0,002 | 0,003 |
| Science ouverte | 0,002 | 0,002 |
| Intégrité de la recherche | 0,002 | 0,002 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,002 | 0,001 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».