Tests d'intégration. Développement d'un produit logiciel pour réussir les tests

Annotation: La conférence est la deuxième d'une série de trois couvrant les niveaux du processus de vérification. Le sujet de cette conférence est le processus de test d'intégration, ses tâches et ses objectifs. Les aspects organisationnels des tests d'intégration sont pris en compte - classifications structurelles et temporelles des méthodes de tests d'intégration, planification des tests d'intégration. Le but de ce cours : donner une idée du processus de test d'intégration, de ses composantes techniques et organisationnelles

20.1. Objectifs et buts des tests d'intégration

Le résultat des tests et de la vérification des modules individuels qui composent le système logiciel doit permettre de conclure que ces modules sont cohérents en interne et sont conformes aux exigences. Cependant, les modules individuels fonctionnent rarement seuls, c'est pourquoi la tâche suivante après le test des modules individuels consiste à tester l'interaction correcte de plusieurs modules combinés en un seul tout. Ce type de test est appelé l'intégration. Son objectif est de garantir l'exactitude collaboration composant du système.

Tests d'intégration aussi appelé tests d'architecture système. D'une part, ce nom est dû au fait que les tests d'intégration incluent des vérifications de tous les types possibles d'interactions entre les modules logiciels et les éléments définis dans l'architecture du système - ainsi, les tests d'intégration vérifient exhaustivité interactions dans la mise en œuvre du système testé. D'autre part, les résultats des tests d'intégration sont l'une des principales sources d'informations pour le processus d'amélioration et de clarification de l'architecture du système, des interfaces intermodules et intercomposants. Autrement dit, de ce point de vue, les tests d'intégration vérifient exactitude interaction des composants du système.

Un exemple de vérification de l'exactitude de l'interaction peut être deux modules, dont l'un accumule les messages de protocole sur les fichiers reçus et le second affiche ce protocole à l'écran. Les exigences fonctionnelles du système stipulent que les messages doivent être affichés dans l'ordre chronologique inverse. Cependant, le module de stockage des messages les stocke dans un ordre direct et le module de sortie utilise la pile pour les envoyer vers ordre inverse. Les tests unitaires qui touchent chaque module individuellement n'auront aucun effet ici - la situation inverse est tout à fait possible, dans laquelle les messages sont stockés dans l'ordre inverse et sortis à l'aide d'une file d'attente. Un problème potentiel ne peut être détecté qu'en vérifiant l'interaction des modules à l'aide de tests d'intégration. Le point clé voici que le système dans son ensemble génère des messages dans l'ordre chronologique inverse, c'est-à-dire qu'en vérifiant le module de sortie et en constatant qu'il émet des messages dans l'ordre direct, nous ne pouvons pas garantir que nous avons détecté un défaut.

Grâce aux tests d'intégration et à l'élimination de tous les défauts identifiés, une architecture cohérente et holistique du système logiciel est obtenue, c'est-à-dire nous pouvons supposer que tests d'intégration teste l’architecture et les exigences fonctionnelles de bas niveau.

Tests d'intégration, en règle générale, est un processus itératif dans lequel la fonctionnalité d'un ensemble de modules de plus en plus croissant est testée.

20.2. Organisation des tests d'intégration

20.2.1. Classification structurelle des méthodes de tests d'intégration

En règle générale, les tests d'intégration sont effectués une fois les tests unitaires terminés pour tous les modules intégrés. Cependant, ce n'est pas toujours le cas. Il existe plusieurs méthodes pour effectuer des tests d'intégration :

• tests ascendants;
• test monolithique;
• tests descendants.

Toutes ces techniques reposent sur la connaissance de l'architecture du système, qui est souvent représentée sous forme de diagrammes de structure ou de diagrammes d'appels de fonctions. Chaque nœud d'un tel diagramme représente un module logiciel et les flèches entre eux représentent les dépendances d'appel entre les modules. La principale différence entre les techniques de test d'intégration réside dans la direction du mouvement le long de ces diagrammes et dans l'étendue de la couverture par itération.

Tests ascendants. Lors de l'utilisation de cette méthode, il est implicite que tous les modules logiciels inclus dans le système sont d'abord testés et ensuite seulement ils sont combinés pour les tests d'intégration. Avec cette approche, la localisation des erreurs est grandement simplifiée : si les modules sont testés séparément, alors une erreur lorsqu'ils fonctionnent ensemble est un problème avec leur interface. Avec cette approche, la zone de recherche des problèmes du testeur est assez étroite et, par conséquent, la probabilité d'identifier correctement un défaut est beaucoup plus élevée.

Riz. 20.1.

Cependant, méthode ascendante les tests présentent un inconvénient important - la nécessité de développer un pilote et des stubs pour les tests unitaires avant d'effectuer les tests d'intégration et la nécessité de développer un pilote et des stubs lors des tests d'intégration d'une partie des modules du système (Fig. 20.1)

D'un côté il y a des pilotes et des fiches - outil puissant les tests, en revanche, leur développement nécessite des ressources importantes, notamment lorsque la composition des modules intégrés change, en d'autres termes, un ensemble de pilotes peut être nécessaire pour les tests unitaires de chaque module, un pilote séparé et des stubs pour tester l'intégration de deux modules de l'ensemble, un séparé pour tester l'intégration de trois modules, etc. Cela est principalement dû au fait que l'intégration des modules élimine le besoin de certains stubs et nécessite également un changement de pilote prenant en charge de nouveaux tests affectant plusieurs modules.

Tests monolithiques suggère que les composants individuels du système n'ont pas subi de tests sérieux. Principal avantage cette méthode- pas besoin de développer un environnement de test, des pilotes et des stubs. Une fois tous les modules développés, leur intégration est réalisée, puis le système dans son ensemble est testé. Cette approche ne doit pas être confondue avec les tests système, qui font l'objet du prochain cours. Malgré le fait que les tests monolithiques vérifieront le fonctionnement de l'ensemble du système, la tâche principale de ces tests est d'identifier les problèmes d'interaction des modules individuels du système. La tâche des tests du système est d'évaluer la qualité et caractéristiques quantitatives systèmes en termes de leur acceptabilité par l’utilisateur final.

Tests monolithiques présente un certain nombre d'inconvénients sérieux.

• Il est très difficile d'identifier la source de l'erreur (identifier le bout de code erroné). La plupart des modules devraient supposer qu'il y a une erreur. Le problème consiste à déterminer laquelle des erreurs dans tous les modules impliqués a conduit au résultat. Cela peut introduire des effets d’erreur. De plus, un bug dans un module peut bloquer le test d'un autre.
• Il est difficile d'organiser des corrections de bugs. À la suite des tests, le testeur enregistre le problème détecté. Le défaut du système à l'origine de ce problème sera corrigé par le développeur. Puisque, en règle générale, les modules testés sont écrits personnes différentes, un problème se pose : lequel d'entre eux est responsable de la recherche et de l'élimination du défaut ? Avec une telle « irresponsabilité collective », la vitesse d'élimination des défauts peut chuter fortement.
• Le processus de test est mal automatisé. Avantage (pas de supplément logiciel accompagnant le processus de test) s'avère être un inconvénient. Chaque modification apportée nécessite de répéter tous les tests.

Tests descendants suppose que le processus de test d’intégration suit le développement. Tout d'abord, seul le niveau de contrôle le plus élevé du système est testé, sans modules supplémentaires. niveau faible. Puis, progressivement, les modules de niveau inférieur sont intégrés aux modules de niveau supérieur. Grâce à cette méthode, il n'est pas nécessaire de recourir à des pilotes (le rôle de pilote est assuré par un module système de niveau supérieur), mais le besoin de stubs demeure (Fig. 20.2).

Différents experts en tests ont des opinions différentes sur la méthode la plus pratique pour tester réellement les systèmes logiciels. Jordan affirme que tests descendants le plus acceptable dans situations réelles, et Myers estime que chaque approche a ses propres avantages et inconvénients, mais en général, la méthode ascendante est meilleure.

La littérature mentionne souvent une méthode de test d'intégration de systèmes logiciels orientés objet, basée sur l'identification de groupes de classes possédant ensemble des fonctionnalités fermées et complètes. À la base, cette approche n’est pas un nouveau type de test d’intégration ; elle modifie simplement l’élément minimum résultant de l’intégration. Lors de l'intégration de modules dans des langages de programmation procédurale, vous pouvez intégrer n'importe quel nombre de modules, à condition que des stubs soient développés. Lors de l'intégration de classes dans des clusters, il existe une restriction assez lâche sur l'exhaustivité des fonctionnalités du cluster. Cependant, même dans le cas de systèmes orientés objet, il est possible d'intégrer n'importe quel nombre de classes à l'aide de classes stub.

Quelle que soit la méthode de test d'intégration utilisée, il est nécessaire de prendre en compte le degré de couverture des fonctionnalités du système par les tests d'intégration. Le document propose une méthode pour évaluer le degré de couverture basée sur des appels de contrôle entre les fonctions et les flux de données. Avec cette évaluation, le code de tous les modules du diagramme de structure du système doit être exécuté (tous les nœuds doivent être couverts), tous les appels doivent être exécutés au moins une fois (toutes les connexions entre les nœuds du diagramme de structure doivent être couverts), toutes les séquences d'appels doit être exécuté au moins une fois (tous les chemins du schéma de structure doivent être parcourus).

Aucun développement logiciel n'est complet sans tester le code exécutable. En fait, cela prend la moitié du temps total de développement et plus de la moitié du coût du projet. Cependant, cela fait partie intégrante du processus de création de nouvelles applications, programmes et systèmes.

Tests d'intégration dans le cadre d'un gros travail

L'un des moyens de contrôler la qualité des logiciels consiste à tester l'intégration, dont les données proviennent de modules individuels testés à l'étape précédente.

Contrairement à l'option modulaire, qui identifie les erreurs localisées dans chaque fonction ou classe individuelle, les tests d'intégration sont la recherche de défauts associés à la mise en œuvre de l'interaction entre en parties séparées produit créé. Les tests fonctionnels d'intégration utilisent la méthode de la « boîte blanche », c'est-à-dire que l'ingénieur qualité a accès et connaît les textes de chaque module individuel, ainsi que les principes d'interaction entre eux.

Méthodes d'assemblage des modules

La méthode monolithique signifie que tous les modules qui seront soumis à des tests d'intégration à l'avenir sont assemblés en même temps. Des situations surviennent presque certainement lorsqu'une partie du complexe testé n'est pas encore prête.

Dans ce cas, il est remplacé par des « stubs » ou pilotes développés en plus.

A côté de la méthode monolithique, il existe une méthode incrémentale (on l'appelle aussi pas à pas), puisque le volume du code testé augmente progressivement, permettant de localiser les zones présentant des défauts dans les relations entre les différentes parties.

La méthode incrémentielle comprend deux manières d'ajouter des modules :

• descendant ou ascendant,
• de bas en haut - descendant.

Caractéristiques des tests monolithiques et incrémentiels

Le principal inconvénient du type d'assemblage monolithique est un grand nombre de du temps et des coûts de main-d'œuvre sont consacrés à la simulation des parties manquantes du complexe testé. Il semblerait que les stubs soient un outil de test assez pratique, mais des situations surviennent lorsque, au cours du processus, il est nécessaire de recréer des parties simulées du programme. Par exemple, si la composition des modules testés change. De plus, l'efficacité de la détection des défauts n'est pas si élevée lorsque le travail ne porte pas sur un produit réel, mais uniquement sur un composant fictif. Le même inconvénient accompagne également les tests incrémentiels avec une méthode de construction ascendante.

En même temps, l'un des inconvénients méthode étape par étape est la nécessité d'organiser et de créer un environnement pour exécuter les modules dans un ordre donné. Il est également pratiquement impossible de développer en parallèle les niveaux supérieur et inférieur.

Bien entendu, les deux méthodes d'assemblage, monolithique et incrémentale, présentent non seulement des inconvénients, mais aussi des avantages. Dans le premier cas, il existe d'excellentes opportunités de développement parallèle de toutes les classes et fonctions impliquées dans les tests, comme dans stade initial, et après modification. La méthode étape par étape demande moins de travail : les modules sont ajoutés progressivement et les erreurs et défauts sont également progressivement découverts. Ceci est connu pour réduire le temps passé à les rechercher.

Avantages des tests d'intégration

À ce stade, un travail colossal est effectué pour vérifier les relations à tous les niveaux, sans lequel, bien entendu, des tests plus approfondis sont impossibles.

Les tests d'intégration logicielle présentent de nombreux avantages :

• vérifier l'interface d'interaction entre les modules de programme individuels ;
• contrôle des relations entre les solutions logicielles complexes testées et tierces ;
• tester le fonctionnement des composants externes de la solution ;
• contrôle de la conformité de la documentation du projet concernant l'interaction des modules individuels.

Correction des défauts

Les tests d'intégration sont terminés, mais ce n'est pas tout. Les erreurs trouvées sont enregistrées et envoyées au développeur pour correction, après quoi le processus recommence.

Tout d'abord, il est nécessaire de vérifier si les défauts identifiés ont été éliminés. Deuxièmement, lorsque le code source était modifié, de nouvelles erreurs pouvaient survenir dans le fonctionnement du programme et dans l'interaction avec des logiciels tiers.

Bien qu'il existe aujourd'hui un grand nombre de méthodes de contrôle qualité, il en existe encore de nombreuses rôle important les tests d’intégration jouent un rôle. Un exemple de ce type de vérification peut clairement démontrer les goulots d'étranglement dans le développement de logiciels et la documentation.

Automatisation des tests

En fonction du volume complexe original les données et le domaine de développement, le problème du temps de test et de la complexité de l'événement dans son ensemble peut se poser.

Pour la plupart vérification efficace le développement doit être utilisé grande quantité saisir des données et des conditions impossibles à gérer « manuellement ». L'automatisation des tests est utilisée pour résoudre ce problème. Comme d’autres types, les tests d’intégration peuvent également être automatisés. Cela réduira le temps de développement global et augmentera également l’efficacité du processus de détection des erreurs.

Cependant, l’automatisation des tests ne peut pas remplacer complètement le travail d’un ingénieur qualité, mais seulement le compléter.

Ainsi, les tests d'intégration font partie intégrante du développement de tout logiciel et l'une des étapes de l'ensemble du processus de vérification de la qualité du produit. Comme toute méthode, elle présente un certain nombre d’avantages et d’inconvénients, mais sans son utilisation, le développement de logiciels de haute qualité devient impossible.

Traduction: Anna Radionova

Il existe de nombreux types de tests logiciels. Les pratiques BDD peuvent être appliquées à n’importe quel aspect des tests, mais les frameworks BDD ne sont pas utilisés dans tous les types de tests. Les scripts comportementaux sont essentiellement fonctionnel tests - ils vérifient que le produit testé fonctionne correctement. Les outils peuvent être utilisés pour tester les performances, alors que les frameworks BDD ne sont pas conçus à cet effet. Le but de cet article est principalement de décrire le rôle de l’automatisation BDD dans la pyramide des tests. Lisez l'article BDD 101 : Tests manuels pour comprendre comment BDD est utilisé dans les tests manuels. (Toutes les informations sur BDD peuvent être trouvées sur la page Automation Panda BDD)

Pyramide de tests

Néanmoins, Les pratiques BDD peuvent être appliquées aux tests unitaires. Chaque test unitaire doit se concentrer sur le composant principal : un appel, une seule variation, une certaine combinaison d'entrées ; sur comportement.Dans un développement ultérieur, la spécification du comportement des fonctionnalités sépare clairement les tests unitaires des tests de plus haut niveau. Le développeur de fonctionnalités est également responsable de l’écriture des tests unitaires, tandis qu’un autre ingénieur est responsable de l’intégration et des tests de bout en bout. La spécification du comportement est une sorte d'accord gentleman selon lequel les tests unitaires seront une entité distincte.

Intégration et tests de bout en bout

Les frameworks de tests BDD se manifestent le plus clairement aux niveaux d'intégration et de tests de bout en bout.

Les spécifications comportementales décrivent de manière claire et concise l’objectif exact du scénario de test. Les étapes peuvent être écrites au niveau de l’intégration ou de bout en bout. Les tests de service peuvent être rédigés à l’aide de spécifications comportementales, comme en Karaté. Les tests de bout en bout sont en fait des tests d'intégration en plusieurs étapes. faire attention à exemple suivant, ce qui, à première vue, semble modèle de base interaction avec l'utilisateur, mais, en fait, il s'agit d'un vaste test de bout en bout :

Donné un utilisateur est connecté au site de réseau social
Quand l'utilisateur écrit un nouveau message
Alors le flux d'accueil de l'utilisateur affiche le nouveau message
Et les flux d'accueil de tous les amis affichent le nouveau message

Publication facile sur réseau social comprend les processus d'interaction avec l'interface, les appels aux services backend et la modification de la base de données en temps réel. Décrit chemin complet passant par le système. Les étapes automatisées peuvent couvrir ces niveaux explicitement ou implicitement, mais elles sont définitivement couvertes par le test.

Tests longs de bout en bout

Les termes sont souvent compris différemment selon les personnes. Lorsque les gens parlent de « tests de bout en bout », ils entendent des tests longs et séquentiels : des tests qui couvrent comportement différent produits les uns après les autres. Cette affirmation fait frémir les adeptes du BDD, car elle contredit la règle de base du BDD : un scénario, un comportement. Bien sûr, en utilisant les frameworks BDD, vous pouvez créer de longs tests de bout en bout, mais vous devez bien réfléchir à l'opportunité et à la manière de le faire.

Il existe cinq principes de base pour écrire des scripts de bout en bout de longue durée dans BDD :

1. Pas besoin de s'inquiéter pour ça. Si le processus BDD est correctement configuré, chaque comportement individuel est déjà entièrement couvert par des scénarios de test. Chaque script doit couvrir toutes les classes d'équivalence des données d'entrée et de sortie. Ainsi, les longs scripts de bout en bout seront principalement une duplication de la couverture des tests. Au lieu de perdre du temps en développement, il est préférable d'abandonner l'automatisation des longs scripts de bout en bout comme ceux qui n'apportent pas beaucoup de valeur et de consacrer plus de temps aux tests manuels et exploratoires.
2. Fusionner les scripts existants avec de nouveaux. Chaque paire Quand-Alors représente comportement individuel. Les étapes des scripts existants peuvent être redéfinies dans d'autres scripts et ne nécessitent qu'une refactorisation mineure. Cela enfreint les bonnes pratiques de Gherkin et peut entraîner des scripts de longue durée, mais c'est le moyen le plus pratique de réutiliser les étapes pour des scripts de bout en bout étendus. La plupart des frameworks BDD ne prennent pas en charge ordre étape par étape, et si elles sont prises en charge, les étapes doivent être réécrites pour que le code fonctionne. (Cette approche est la plus pratique, mais la moins traditionnelle.)
3. Intégrez des contrôles dans les étapes Donné et Quand. Cette stratégie évite la duplication des paires When-Then et garantit que les vérifications sont effectuées. L'exactitude de chaque étape est vérifiée tout au long du processus à l'aide du texte Gherkin. Toutefois, un certain nombre de nouvelles mesures pourraient être nécessaires.
4. Traitez une séquence de comportements comme des comportements uniques et individuels.. Ce meilleur moyen réfléchir à des scénarios de bout en bout à long terme, car cela améliore la pensée comportementale. Un scénario à long terme n’a de valeur que s’il est considéré comme un comportement unique. Le scénario doit être écrit pour mettre en valeur cette unicité. Sinon, ce n’est pas un script qui vaut la peine d’être utilisé. Ces scripts sont souvent déclaratifs et de haut niveau.
5. N'utilisez pas de frameworks BDD et écrivez des tests exclusivement à l'aide d'outils d'automatisation. Gherkin est conçu pour permettre une collaboration comportementale, tandis que de longs tests de bout en bout résolvent les problèmes d'intensité du travail d'assurance qualité. Une entreprise peut fournir des spécifications comportementales, mais n’écrira jamais de tests de bout en bout. La réécriture des spécifications comportementales dans de longs scripts de bout en bout peut bloquer le développement. Beaucoup la meilleure solution est la coexistence : les tests d'acceptation peuvent être écrits à l'aide de Gherkin, et les tests de bout en bout de longue durée peuvent être écrits à l'aide d'outils de programmation. Les deux ensembles de tests peuvent être automatisés en utilisant la même base de code, ils peuvent avoir les mêmes modules de support et même les mêmes méthodes de définition des étapes.

Choisissez l'approche qui convient le mieux à votre équipe.

D'un point de vue technologique, les tests d'intégration sont un développement quantitatif des tests unitaires, puisque, tout comme les tests unitaires, ils opèrent sur les interfaces des modules et sous-systèmes et nécessitent la création d'un environnement de test, comprenant des stubs à la place des modules manquants. La principale différence entre modulaire et tests d'intégration se compose d'objectifs, c'est-à-dire les types de défauts à détecter, qui, à leur tour, déterminent la stratégie de sélection des données d'entrée et des méthodes d'analyse. En particulier, au niveau des tests d'intégration, les techniques liées à la couverture des interfaces, telles que les appels de fonctions ou de méthodes, ou à l'analyse de l'utilisation des objets d'interface, tels que ressources mondiales, moyens de communication fournis système opérateur.

Le problème résolu par la méthode tests d'intégration, - les tests de connexions intermodulaires mis en œuvre lors de l'exécution des logiciels du complexe K. Les tests d'intégration utilisent un modèle « boîte blanche » au niveau modulaire. Le testeur connaissant en détail le texte du programme avant d'appeler tous les modules inclus dans le complexe testé, l'utilisation de critères structurels à ce stade est possible et justifiée.

Les tests d'intégration sont utilisés au stade de l'assemblage de modules testés unitairement en un seul complexe. Il existe deux méthodes connues pour assembler des modules :
Monolithique, caractérisé par l'intégration simultanée de tous les modules dans un complexe testé
Incrémentale, caractérisé par une construction étape par étape (module par module) d'un ensemble de programmes avec des tests étape par étape du complexe assemblé. Dans la méthode incrémentale, il existe deux stratégies pour ajouter des modules :
o Tests descendants et ascendants correspondants.
o Tests « ascendants » et, par conséquent, descendants.

Particularités test monolithique sont les suivants : pour remplacer les modules qui n'étaient pas développés au moment des tests, à l'exception de celui du haut, il est nécessaire de développer en plus des pilotes (pilotes de test) et/ou des stubs (stubs), en remplaçant les modules de niveaux inférieurs qui manquaient au moment de la séance de tests.

Une comparaison des approches monolithiques et intégrales donne ce qui suit :
Tests monolithiques nécessite beaucoup de travail associé au développement supplémentaire des pilotes et des stubs et à la difficulté d'identifier les erreurs qui apparaissent dans l'espace du code assemblé.
Tests étape par étape est associé à moins de pénibilité dans l'identification des erreurs en raison d'une augmentation progressive du volume de code testé et, par conséquent, de la localisation de la zone ajoutée du code testé.
Tests monolithiques fournit de belles opportunités parallélisation du travail, en particulier dans la phase initiale de test.

Particularités tests descendants sont les suivants : organisation d'un environnement pour la file d'attente exécutable des appels par modules testés des modules testés, développement et utilisation constants de stubs, organisation de tests prioritaires des modules contenant des opérations d'échange avec l'environnement, ou des modules critiques pour l'algorithme testé .

Défauts tests descendants:
Le problème de développer des stubs suffisamment « intelligents », c’est-à-dire stubs pouvant être utilisés pour simuler divers modes de fonctionnement du complexe requis pour les tests
La complexité d'organiser et de développer un environnement pour mettre en œuvre l'exécution des modules dans l'ordre requis
Le développement parallèle de modules de niveaux supérieurs et inférieurs conduit à une mise en œuvre pas toujours efficace des modules en raison de l'ajustement (spécialisation) de modules de niveaux inférieurs non encore testés à des modules de niveaux supérieurs déjà testés

Défauts tests ascendants:
Retard dans la vérification des caractéristiques conceptuelles du complexe testé
La nécessité de développer et d'utiliser des pilotes

Caractéristiques des tests d'intégration pour la programmation procédurale

Le processus de construction d'un ensemble de tests lors des tests structurels est déterminé par le principe sur lequel est basée la construction du Program Model Graph (GMP). Ceci détermine l'ensemble des chemins de test et la génération de tests correspondant aux chemins de test.

La première approche du développement logiciel est la programmation procédurale (modulaire). La programmation procédurale traditionnelle implique l'écriture du code source dans un style impératif, qui prescrit une certaine séquence d'exécution des commandes, ainsi que la description d'un projet logiciel à l'aide de la décomposition fonctionnelle. Les langages comme Pascal et C sont impératifs. Dans ceux-ci, l'ordre des lignes de code source détermine l'ordre dans lequel le contrôle est transféré, y compris l'exécution séquentielle, la sélection des conditions et l'exécution répétée des sections du programme. Chaque module possède plusieurs points d'entrée (si le code est strictement écrit - un) et plusieurs points de sortie (si le code est strictement écrit - un). Les projets logiciels complexes ont une structure hiérarchique modulaire et le test des modules constitue la première étape du processus de test logiciel. Construire un modèle graphique d'un module est une tâche triviale, et les tests sont presque toujours effectués selon le critère de couverture des branches C1, c'est-à-dire chaque arc et chaque sommet du graphe du module doivent être contenus dans au moins un des chemins de test.

Classes et types de tests.

Il existe deux grandes classes de tests : traditionnel Et non traditionnel.

Le test a composition, intégrité Et structure. Cela consiste en:

• missions;
• les règles de leur application ;
• notes pour avoir accompli chaque tâche ;
• recommandations pour l’interprétation des résultats des tests.

Intégrité des tests désigne la relation des tâches, leur appartenance à un facteur commun mesuré. Chaque tâche de test remplit le rôle qui lui est assigné et aucune d'entre elles ne peut donc être supprimée du test sans perte de qualité de mesure.

Structure des tests constitue un moyen de relier les tâches les unes aux autres. Fondamentalement, c'est ce qu'on appelle structure factorielle, dans lequel chaque tâche est connectée aux autres via contenu général et la variation globale des résultats du test.

Un test traditionnel est une unité d'au moins trois systèmes :

• un système de connaissances significatif décrit dans la langue de la discipline académique testée ;
• un système formel de tâches de difficulté croissante ;
• caractéristiques statistiques tâches et résultats des tests.

Le test pédagogique traditionnel doit être envisagé de deux manières significatives : comme méthode de mesure pédagogique et à la suite de l'application de tests.

ceux st est un système de tâches qui forment la meilleure intégrité méthodologique. L'intégrité du test est l'interaction stable des tâches qui forment le test en tant que système en développement.

Tests homogènes

Les tests traditionnels incluent des tests homogène Et hétérogène.

Test homogène représente un système de tâches de difficulté croissante, de forme spécifique et de contenu spécifique - un système créé dans un but objectif, qualitatif et méthode efficaceévaluer la structure et mesurer le niveau de préparation des étudiants dans une discipline académique.

Les tests homogènes sont plus courants que les autres. En pédagogie, ils sont créés pour contrôler les connaissances dans une discipline académique ou dans une section d'une discipline académique volumineuse comme la physique, par exemple. Dans un test pédagogique homogène, l'utilisation de tâches révélant d'autres propriétés n'est pas autorisée. La présence de ce dernier viole l'exigence de pureté disciplinaire de l'épreuve pédagogique. Après tout, chaque test mesure quelque chose de prédéterminé.

Tests hétérogènes

Test hétérogène représente un système de tâches de difficulté croissante, de forme spécifique et de contenu spécifique - un système créé dans le but d'une méthode objective, de haute qualité et efficace pour évaluer la structure et mesurer le niveau de préparation des étudiants dans plusieurs disciplines académiques.

Souvent, ces tests incluent également tâches psychologiques pour évaluer le niveau de développement intellectuel.

En règle générale, des tests hétérogènes sont utilisés pour une évaluation complète des diplômés de l'école, une évaluation de la personnalité lors de la candidature à un emploi et pour sélectionner les candidats les plus préparés à l'admission dans les universités. Chaque test hétérogène étant constitué de tests homogènes, l'interprétation des résultats des tests s'effectue en fonction des réponses aux tâches de chaque test (on les appelle ici échelles) et, en plus, à travers diverses méthodes des tentatives d'agrégation de scores sont faites pour donner note globale préparation du sujet de test.

L'interprétation des résultats des tests s'effectue principalement dans le langage de la testologie, sur la base de la moyenne arithmétique, du mode ou de la médiane et des normes dites centiles, indiquant quel pourcentage des candidats ont résultat du test pire que n'importe quel sujet analysé avec ses résultats au test. Cette interprétation est appelée orienté normatif.

Tests intégratifs

Intégratif peut être appelé un test composé de systèmes de tâches qui répondent aux exigences de contenu intégratif, formulaire de test, difficulté croissante des tâches visant à un diagnostic final généralisé de l'état de préparation d'un diplômé d'un établissement d'enseignement.

Le diagnostic est réalisé en présentant de telles tâches, dont les réponses correctes nécessitent des connaissances intégrées (généralisées, clairement interdépendantes) dans le domaine de deux et plus disciplines académiques. La création de tels tests est réservée aux enseignants qui connaissent un certain nombre de disciplines académiques, comprennent le rôle important des liens interdisciplinaires dans l'apprentissage et sont capables de créer des tâches dont les réponses correctes nécessitent que les étudiants aient une connaissance de divers disciplines et la capacité d’appliquer ces connaissances.

Les tests intégratifs sont précédés par l'organisation apprentissage intégratif. Malheureusement, la forme actuelle de direction des cours, combinée à une fragmentation excessive des disciplines académiques, ainsi qu'à la tradition d'enseignement disciplines individuelles(et non des cours généralisés) entraveront pendant longtemps la mise en œuvre d'une approche intégrative dans les processus de formation et de suivi de la préparation.

L'avantage des tests intégratifs par rapport aux tests hétérogènes réside dans le contenu informatif plus important de chaque tâche et dans le plus petit nombre de tâches elles-mêmes.

Tests adaptatifs

La faisabilité du contrôle adaptatif découle de la nécessité de rationaliser les tests traditionnels.

Chaque enseignant comprend qu'il n'est pas nécessaire de confier à un élève bien préparé des tâches faciles ou très faciles, car la probabilité de la bonne décision. De plus, les matériaux légers n'ont pas de potentiel de développement notable. Symétriquement, en raison de la forte probabilité d'une mauvaise décision, il ne sert à rien de confier des tâches difficiles à un élève faible. On sait que les tâches difficiles et très difficiles réduisent motivation à apprendre beaucoup d'étudiants.

Le plus caractéristique principale les tâches d'un test adaptatif sont leur niveau de difficulté, obtenu empiriquement, ce qui signifie : avant d'arriver à la banque, chaque tâche est soumise à des tests empiriques pendant une durée suffisante grand nombreétudiants typiques de la population d’intérêt. Les mots « contingent d’intérêt » visent à représenter ici le sens du concept plus rigoureux connu en science de « population générale ».

Les tests présentent les avantages suivants par rapport aux autres méthodes contrôle pédagogique:

· augmenter la rapidité de contrôle de la qualité des connaissances et des compétences acquises par les étudiants ;

· mise en œuvre d'une couverture bien superficielle mais complète de tout Matériel pédagogique;

· réduction des impacts influence négative sur les résultats des tests de facteurs tels que l'humeur, le niveau de qualification et d'autres caractéristiques d'un enseignant particulier, c'est-à-dire minimisation facteur subjectif lors de l'évaluation des réponses ;

· une grande objectivité et, par conséquent, un plus grand impact positif et stimulant sur activité cognitiveétudiant;

· se concentrer sur le moderne moyens techniques, pour utilisation dans l'environnement de systèmes de formation et de surveillance informatiques ;

· la possibilité d'un traitement mathématique et statistique des résultats du contrôle, et par conséquent, d'augmenter l'objectivité du contrôle pédagogique ;

· mise en œuvre du principe d'individualisation et de différenciation des formations grâce à l'utilisation de tests adaptatifs ;

· la capacité d'augmenter la fréquence et la régularité des contrôles en réduisant le temps nécessaire à l'exécution des tâches et en automatisant l'inspection ;

· faciliter le processus d’intégration du système éducatif du pays dans le système européen.

Les tests peuvent être classés sur la base suivante :

1. Domaine application des tests: mono-sujet, multi-sujet, intégratif.
Intégratif peut être appelé un test composé de telles tâches, dont les réponses correctes nécessitent une connaissance intégrée (interdépendante, généralisée) de deux ou plusieurs disciplines académiques. L'utilisation de tels tests à l'école, tant de contrôle que pédagogiques, est un excellent moyen de mettre en œuvre des liens interdisciplinaires dans l'enseignement.

2. Orientation générale de la conception du test: orienté normatif ou orienté critère (orienté sujet).
À orienté normatif approche, des tests sont développés pour comparer les matières par niveau résultats scolaires.
Principal poinçonner spécifique à un sujet le test est l'interprétation de la performance d'un test du point de vue de son contenu sémantique. L'accent est mis sur un domaine de contenu strictement défini (ce que les candidats peuvent et savent), et non sur leur apparence par rapport aux autres.

3.Didactique-psychologique orientation du test : test de réussite pour contrôler la connaissance de la théorie ; un test de réussite pour contrôler des capacités et des compétences plus ou moins complexes dans une matière donnée, un test de capacité d'apprentissage (diagnostic des capacités réelles d'apprentissage dans une gamme donnée de matières ou de connaissances cycliques - mathématiques, linguistiques, etc.).

4.Orientation vers une étape spécifique du contrôle: essais de contrôle préliminaire, tests contrôle actuel, tests de contrôle final.

5. Activité dominante du sujet lors de la réalisation des tests– oral, écrit, informatique.

6. Nombre d'objets de contrôle: tests qui ont un objet de contrôle (par exemple, le nombre d'opérations effectuées au bon niveau) ou plusieurs (qualité, quantité, rapidité, séquence stricte, connaissance des mêmes opérations).

7. Degré d'homogénéité tâches de test : tests avec des formes homogènes ou hétérogènes de tâches de construction.

8. Facteur de vitesse: rapide (avec enregistrement obligatoire du temps d'exécution) et non rapide.

9. Formulaire d'organisation de tests: masse, individuel, groupe.

Séparément, il y a ce qu'on appelle adaptatif tests basés sur le principe d’individualisation des apprentissages. Chaque enseignant comprend qu'il ne sert à rien de confier à un bon élève des tâches faciles et très faciles, tout comme il ne sert à rien de confier des tâches difficiles à un élève faible. En théorie dimensions pédagogiques une mesure de la difficulté de la tâche et une mesure du niveau de connaissances se sont révélées comparables sur une échelle. Après l’avènement des ordinateurs, cette mesure a constitué la base de la méthode de contrôle adaptatif des connaissances, où la difficulté et le nombre de tâches présentées sont régulés en fonction des réponses des élèves.