Par Jeff Tickner<\/h3>\n<\/div><\/div><\/div>Chaque organisation informatique effectue des tests, qu’il s’agisse de tests unitaires effectu\u00e9s par les d\u00e9veloppeurs, de tests d’Assurance Qualit\u00e9 (AQ) effectu\u00e9s par le personnel AQ ou de tests de r\u00e9gression enti\u00e8rement automatis\u00e9s. Dans chacune de ces techniques, un aspect largement sous-estim\u00e9 est le r\u00f4le des donn\u00e9es de test<\/strong>. Pourtant, l\u2019efficacit\u00e9 avec laquelle ces donn\u00e9es sont g\u00e9r\u00e9es a un impact direct sur le temps consacr\u00e9 aux tests et sur la qualit\u00e9 des r\u00e9sultats. Nous allons voir pourquoi les donn\u00e9es de test peuvent \u00eatre difficiles \u00e0 g\u00e9rer, quelles sont les meilleures pratiques bas\u00e9es sur notre exp\u00e9rience et quels avantages tangibles vous pouvez tirer d\u2019un ensemble coh\u00e9rent de donn\u00e9es de test.<\/p>\n<\/div>Sommaire<\/h2>\n\n- Pourquoi les donn\u00e9es de test sont-elles importantes ? <\/a><\/li>\n
- Les donn\u00e9es de test sont importantes, m\u00eame pour les tests unitaires !<\/a><\/li>\n
- La coh\u00e9rence des donn\u00e9es est la base des tests de r\u00e9gression fonctionnels<\/a><\/li>\n
- Comment garantir la confidentialit\u00e9 des donn\u00e9es de test – et les actualiser en cas de besoin ?<\/a><\/li>\n
- Pour conclure : le test continu (CT) a besoin de donn\u00e9es coh\u00e9rentes !<\/a><\/li>\n<\/ol>\n<\/div><\/div>\n
1. Pourquoi les donn\u00e9es de test sont-elles importantes ?<\/h2>\n
Parlons d\u2019abord de la fondation des tests, l’ensemble des donn\u00e9es de test. Tout le monde comprend qu\u2019il est indispensable de disposer de donn\u00e9es \u00e0 tester, mais comment g\u00e9rer ces donn\u00e9es ? Trop souvent, je vois des employ\u00e9s tester des donn\u00e9es qui deviennent de plus en plus alt\u00e9r\u00e9es au fur et \u00e0 mesure que les tests progressent, ce qui entra\u00eene des frictions dans le processus de test. Lorsqu\u2019un test \u00e9choue ou ne produit pas les r\u00e9sultats escompt\u00e9s, les utilisateurs doivent d\u00e9terminer si ces r\u00e9sultats erron\u00e9s ont \u00e9t\u00e9 caus\u00e9s par les modifications du programme qu\u2019ils testent ou au contraire par des donn\u00e9es qui sont mauvaises ou qui se modifient pendant le test. Le plus souvent, ils signalent un d\u00e9faut \u00e0 un d\u00e9veloppeur, qui doit ensuite essayer de reproduire l\u2019erreur, ce qui est impossible s\u2019il utilise un \u201cmeilleur\u201d ensemble de donn\u00e9es. Vous pouvez facilement voir comment de mauvaises donn\u00e9es peuvent avoir un effet boule de neige et faire perdre du temps aux tests. Alors comment g\u00e9rer les donn\u00e9es pour que les tests restent efficaces ?<\/p>\n
Avant de nous pencher sur les donn\u00e9es, examinons de plus pr\u00e8s les tests eux-m\u00eames. Il convient de distinguer deux grands types de tests, les tests unitaires et les tests fonctionnels (couramment utilis\u00e9s pour les tests de r\u00e9gression). ARCAD a de l\u2019exp\u00e9rience avec les deux types (puisque nous avons des outils pour les deux) mais nous ne sommes pas ici pour parler de nos outils mais de l\u2019un des aspects les plus critiques d\u2019un bon test : de bonnes donn\u00e9es<\/strong>. Nos outils ont la m\u00eame d\u00e9pendance que tout autre test : mauvaises donn\u00e9es = mauvais tests.<\/p>\n<\/div>\n2. Les donn\u00e9es de test sont importantes, m\u00eame pour les tests unitaires !<\/h2>\n
Les tests unitaires sont normalement tr\u00e8s granulaires et consistent \u00e0 appeler un programme ou une proc\u00e9dure avec un ensemble de valeurs de param\u00e8tres et \u00e0 v\u00e9rifier les valeurs correctes des param\u00e8tres de retour. Cependant, certains programmes peuvent encha\u00eener sur des fichiers pour valider ou lire des donn\u00e9es suppl\u00e9mentaires avant de renvoyer des valeurs. Ainsi, alors que les tests unitaires ne sont normalement pas consid\u00e9r\u00e9s comme d\u00e9pendant des donn\u00e9es, dans certain cas (et notamment avec les applications legacy d\u00e9velopp\u00e9es sur la plateforme IBM i), nous rencontrons des programmes monolithiques qui ont de nombreuses fonctions business derri\u00e8re les param\u00e8tres d\u2019entr\u00e9e et de sortie. Si vos programmes ne disposent pas de donn\u00e9es coh\u00e9rentes \u00e0 consommer pendant les tests unitaires, vous risquez de ne pas obtenir de r\u00e9sultats coh\u00e9rents. Les outils de test unitaire ont souvent une disposition pour que les donn\u00e9es qui seront consomm\u00e9es par le programme puissent \u00eatre mises \u00e0 jour avant l\u2019ex\u00e9cution du test unitaire. Si ce n\u2019est pas le cas, ils peuvent \u00eatre script\u00e9s pour prendre en charge ces donn\u00e9es. Cependant, la mise en place d\u2019une telle disposition prend du temps et peut n\u00e9cessiter des comp\u00e9tences techniques pour la mise \u00e0 jour d\u2019un fichier pour le test unitaire.<\/p>\n<\/div><\/div><\/div>
Vos tests unitaires sont fastidieux ou incomplets ?Automatisez-les avec ARCAD iUnit !<\/strong><\/p>\n<\/div>T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\n3. La coh\u00e9rence des donn\u00e9es est la base des tests de r\u00e9gression fonctionnels<\/h2>\n
Les tests fonctionnels sont bas\u00e9s sur l\u2019ex\u00e9cution de fonctions business au niveau de l\u2019utilisateur, tout comme les cas de test qui sont d\u00e9velopp\u00e9s pour tester et v\u00e9rifier qu\u2019une fonction sp\u00e9cifique fonctionne correctement. Les tests fonctionnels sont souvent script\u00e9s ou ex\u00e9cut\u00e9s et enregistr\u00e9s dans un outil<\/b> (comme Arcad Verifier<\/strong><\/a>) et les r\u00e9sultats sont v\u00e9rifi\u00e9s pour s\u2019assurer de la coh\u00e9rence des valeurs. Une fois ces tests fonctionnels d\u00e9velopp\u00e9s, ils peuvent \u00eatre r\u00e9utilis\u00e9s \u00e0 l\u2019infini pour les tests de non-r\u00e9gression<\/b>, dans lesquels un ou plusieurs tests fonctionnels sont ex\u00e9cut\u00e9s afin de valider le fonctionnement normal de l\u2019application apr\u00e8s une mise \u00e0 jour dans l’environnement de test. Cette technique est tr\u00e8s d\u00e9pendante de la coh\u00e9rence des donn\u00e9es afin que les tests fonctionnels renvoient des r\u00e9sultats coh\u00e9rents et r\u00e9ussissent.<\/p>\nSi les donn\u00e9es changent en raison de l\u2019ex\u00e9cution d\u2019autres processus pendant l\u2019ex\u00e9cution des tests script\u00e9s, un faux positif peut se produire et \u00eatre interpr\u00e9t\u00e9 comme un \u00e9chec. Donc, ici encore, des donn\u00e9es coh\u00e9rentes = des r\u00e9sultats coh\u00e9rents et permettent un niveau d\u2019automatisation beaucoup plus \u00e9lev\u00e9. L\u2019importance de disposer d\u2019un ensemble d\u00e9di\u00e9 de donn\u00e9es de test devient encore plus \u00e9vidente.<\/p>\n<\/div><\/div><\/div>
Automatisation des tests orient\u00e9s donn\u00e9es pour IBM i. ARCAD Verifier isole les d\u00e9fauts au fur et \u00e0 mesure qu’ils apparaissent, au coeur de vos donn\u00e9es – pour les services interactifs, batch & Web.<\/strong><\/p>\n<\/div>T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div>\n4. Comment garantir la confidentialit\u00e9 des donn\u00e9es de test – et les actualiser en cas de besoin ?<\/h2>\n
La raison la plus courante pour laquelle les entreprises ne disposent pas de plusieurs ensembles de donn\u00e9es de test est que le point de d\u00e9part est constitu\u00e9 par les donn\u00e9es de production qui peuvent contenir des millions d\u2019enregistrements et\/ou des donn\u00e9es sensibles.<\/b> ARCAD dispose d\u2019un outil permettant de g\u00e9rer ce cas de figure (DOT Anonymizer<\/strong><\/a>), mais il s\u2019agit l\u00e0 d\u2019un autre sujet et nous sommes ici pour parler de la gestion de ces donn\u00e9es \u00e0 votre avantage. Si vous construisez un bon ensemble de donn\u00e9es de test suffisamment volumineux pour prendre en charge tous vos cas de test, mais pas plus, il peut contenir des donn\u00e9es sensibles qui ont une grande valeur pour votre organisation et qui n\u00e9cessitent d\u2019\u00eatre masqu\u00e9es ou trait\u00e9es avec pr\u00e9caution. <\/b>Il est recommand\u00e9 de disposer d\u2019une copie de ces donn\u00e9es pour actualiser les environnements d\u2019AQ, id\u00e9alement dans un SAVF, afin qu\u2019elles ne puissent pas \u00eatre mises \u00e0 jour par inadvertance. Il est \u00e9galement possible de cr\u00e9er une fonction pour actualiser ces donn\u00e9es \u00e0 partir de la production (ou d\u2019utiliser un outil ARCAD), ce qui permettra \u00e9galement d\u2019actualiser les donn\u00e9es de test avec des donn\u00e9es de production plus r\u00e9centes. Quelle que soit la m\u00e9thode utilis\u00e9e, lorsqu\u2019un ensemble de donn\u00e9es de test est corrompu, il est facile de l\u2019actualiser avec de bonnes donn\u00e9es et, dans le cas de l\u2019automatisation, avec des valeurs coh\u00e9rentes.<\/p>\nCette capacit\u00e9 \u00e0 actualiser automatiquement les donn\u00e9es est pr\u00e9cieuse pour tous les tests que vous effectuez, m\u00eame les tests unitaires pilot\u00e9s par les d\u00e9veloppeurs qui peuvent d\u00e9pendre de donn\u00e9es lues dans des fichiers. Il est certain que les tests fonctionnels effectu\u00e9s par le service d\u2019AQ doivent pouvoir actualiser facilement leurs donn\u00e9es, car ils essaient de d\u00e9couvrir des bugs qui pourraient corrompre leurs donn\u00e9es de test pendant la phase de test. M\u00eame l’utilisation d’outils de test qui g\u00e8rent les mises \u00e0 jour de donn\u00e9es par le biais d’un processus de retour en arri\u00e8re peut laisser des donn\u00e9es erron\u00e9es si le personnel d’AQ rencontre une erreur importante et que le processus de script de test est interrompu.<\/p>\n
Chaque organisation informatique effectue des tests, qu’il s’agisse de tests unitaires effectu\u00e9s par les d\u00e9veloppeurs, de tests d’Assurance Qualit\u00e9 (AQ) effectu\u00e9s par le personnel AQ ou de tests de r\u00e9gression enti\u00e8rement automatis\u00e9s. Dans chacune de ces techniques, un aspect largement sous-estim\u00e9 est le r\u00f4le des donn\u00e9es de test<\/strong>. Pourtant, l\u2019efficacit\u00e9 avec laquelle ces donn\u00e9es sont g\u00e9r\u00e9es a un impact direct sur le temps consacr\u00e9 aux tests et sur la qualit\u00e9 des r\u00e9sultats. Nous allons voir pourquoi les donn\u00e9es de test peuvent \u00eatre difficiles \u00e0 g\u00e9rer, quelles sont les meilleures pratiques bas\u00e9es sur notre exp\u00e9rience et quels avantages tangibles vous pouvez tirer d\u2019un ensemble coh\u00e9rent de donn\u00e9es de test.<\/p>\n<\/div> Parlons d\u2019abord de la fondation des tests, l’ensemble des donn\u00e9es de test. Tout le monde comprend qu\u2019il est indispensable de disposer de donn\u00e9es \u00e0 tester, mais comment g\u00e9rer ces donn\u00e9es ? Trop souvent, je vois des employ\u00e9s tester des donn\u00e9es qui deviennent de plus en plus alt\u00e9r\u00e9es au fur et \u00e0 mesure que les tests progressent, ce qui entra\u00eene des frictions dans le processus de test. Lorsqu\u2019un test \u00e9choue ou ne produit pas les r\u00e9sultats escompt\u00e9s, les utilisateurs doivent d\u00e9terminer si ces r\u00e9sultats erron\u00e9s ont \u00e9t\u00e9 caus\u00e9s par les modifications du programme qu\u2019ils testent ou au contraire par des donn\u00e9es qui sont mauvaises ou qui se modifient pendant le test. Le plus souvent, ils signalent un d\u00e9faut \u00e0 un d\u00e9veloppeur, qui doit ensuite essayer de reproduire l\u2019erreur, ce qui est impossible s\u2019il utilise un \u201cmeilleur\u201d ensemble de donn\u00e9es. Vous pouvez facilement voir comment de mauvaises donn\u00e9es peuvent avoir un effet boule de neige et faire perdre du temps aux tests. Alors comment g\u00e9rer les donn\u00e9es pour que les tests restent efficaces ?<\/p>\n Avant de nous pencher sur les donn\u00e9es, examinons de plus pr\u00e8s les tests eux-m\u00eames. Il convient de distinguer deux grands types de tests, les tests unitaires et les tests fonctionnels (couramment utilis\u00e9s pour les tests de r\u00e9gression). ARCAD a de l\u2019exp\u00e9rience avec les deux types (puisque nous avons des outils pour les deux) mais nous ne sommes pas ici pour parler de nos outils mais de l\u2019un des aspects les plus critiques d\u2019un bon test : de bonnes donn\u00e9es<\/strong>. Nos outils ont la m\u00eame d\u00e9pendance que tout autre test : mauvaises donn\u00e9es = mauvais tests.<\/p>\n Les tests unitaires sont normalement tr\u00e8s granulaires et consistent \u00e0 appeler un programme ou une proc\u00e9dure avec un ensemble de valeurs de param\u00e8tres et \u00e0 v\u00e9rifier les valeurs correctes des param\u00e8tres de retour. Cependant, certains programmes peuvent encha\u00eener sur des fichiers pour valider ou lire des donn\u00e9es suppl\u00e9mentaires avant de renvoyer des valeurs. Ainsi, alors que les tests unitaires ne sont normalement pas consid\u00e9r\u00e9s comme d\u00e9pendant des donn\u00e9es, dans certain cas (et notamment avec les applications legacy d\u00e9velopp\u00e9es sur la plateforme IBM i), nous rencontrons des programmes monolithiques qui ont de nombreuses fonctions business derri\u00e8re les param\u00e8tres d\u2019entr\u00e9e et de sortie. Si vos programmes ne disposent pas de donn\u00e9es coh\u00e9rentes \u00e0 consommer pendant les tests unitaires, vous risquez de ne pas obtenir de r\u00e9sultats coh\u00e9rents. Les outils de test unitaire ont souvent une disposition pour que les donn\u00e9es qui seront consomm\u00e9es par le programme puissent \u00eatre mises \u00e0 jour avant l\u2019ex\u00e9cution du test unitaire. Si ce n\u2019est pas le cas, ils peuvent \u00eatre script\u00e9s pour prendre en charge ces donn\u00e9es. Cependant, la mise en place d\u2019une telle disposition prend du temps et peut n\u00e9cessiter des comp\u00e9tences techniques pour la mise \u00e0 jour d\u2019un fichier pour le test unitaire.<\/p>\n<\/div><\/div><\/div> Vos tests unitaires sont fastidieux ou incomplets ?Automatisez-les avec ARCAD iUnit !<\/strong><\/p>\n<\/div> Les tests fonctionnels sont bas\u00e9s sur l\u2019ex\u00e9cution de fonctions business au niveau de l\u2019utilisateur, tout comme les cas de test qui sont d\u00e9velopp\u00e9s pour tester et v\u00e9rifier qu\u2019une fonction sp\u00e9cifique fonctionne correctement. Les tests fonctionnels sont souvent script\u00e9s ou ex\u00e9cut\u00e9s et enregistr\u00e9s dans un outil<\/b> (comme Arcad Verifier<\/strong><\/a>) et les r\u00e9sultats sont v\u00e9rifi\u00e9s pour s\u2019assurer de la coh\u00e9rence des valeurs. Une fois ces tests fonctionnels d\u00e9velopp\u00e9s, ils peuvent \u00eatre r\u00e9utilis\u00e9s \u00e0 l\u2019infini pour les tests de non-r\u00e9gression<\/b>, dans lesquels un ou plusieurs tests fonctionnels sont ex\u00e9cut\u00e9s afin de valider le fonctionnement normal de l\u2019application apr\u00e8s une mise \u00e0 jour dans l’environnement de test. Cette technique est tr\u00e8s d\u00e9pendante de la coh\u00e9rence des donn\u00e9es afin que les tests fonctionnels renvoient des r\u00e9sultats coh\u00e9rents et r\u00e9ussissent.<\/p>\n Si les donn\u00e9es changent en raison de l\u2019ex\u00e9cution d\u2019autres processus pendant l\u2019ex\u00e9cution des tests script\u00e9s, un faux positif peut se produire et \u00eatre interpr\u00e9t\u00e9 comme un \u00e9chec. Donc, ici encore, des donn\u00e9es coh\u00e9rentes = des r\u00e9sultats coh\u00e9rents et permettent un niveau d\u2019automatisation beaucoup plus \u00e9lev\u00e9. L\u2019importance de disposer d\u2019un ensemble d\u00e9di\u00e9 de donn\u00e9es de test devient encore plus \u00e9vidente.<\/p>\n<\/div><\/div><\/div> Automatisation des tests orient\u00e9s donn\u00e9es pour IBM i. ARCAD Verifier isole les d\u00e9fauts au fur et \u00e0 mesure qu’ils apparaissent, au coeur de vos donn\u00e9es – pour les services interactifs, batch & Web.<\/strong><\/p>\n<\/div> La raison la plus courante pour laquelle les entreprises ne disposent pas de plusieurs ensembles de donn\u00e9es de test est que le point de d\u00e9part est constitu\u00e9 par les donn\u00e9es de production qui peuvent contenir des millions d\u2019enregistrements et\/ou des donn\u00e9es sensibles.<\/b> ARCAD dispose d\u2019un outil permettant de g\u00e9rer ce cas de figure (DOT Anonymizer<\/strong><\/a>), mais il s\u2019agit l\u00e0 d\u2019un autre sujet et nous sommes ici pour parler de la gestion de ces donn\u00e9es \u00e0 votre avantage. Si vous construisez un bon ensemble de donn\u00e9es de test suffisamment volumineux pour prendre en charge tous vos cas de test, mais pas plus, il peut contenir des donn\u00e9es sensibles qui ont une grande valeur pour votre organisation et qui n\u00e9cessitent d\u2019\u00eatre masqu\u00e9es ou trait\u00e9es avec pr\u00e9caution. <\/b>Il est recommand\u00e9 de disposer d\u2019une copie de ces donn\u00e9es pour actualiser les environnements d\u2019AQ, id\u00e9alement dans un SAVF, afin qu\u2019elles ne puissent pas \u00eatre mises \u00e0 jour par inadvertance. Il est \u00e9galement possible de cr\u00e9er une fonction pour actualiser ces donn\u00e9es \u00e0 partir de la production (ou d\u2019utiliser un outil ARCAD), ce qui permettra \u00e9galement d\u2019actualiser les donn\u00e9es de test avec des donn\u00e9es de production plus r\u00e9centes. Quelle que soit la m\u00e9thode utilis\u00e9e, lorsqu\u2019un ensemble de donn\u00e9es de test est corrompu, il est facile de l\u2019actualiser avec de bonnes donn\u00e9es et, dans le cas de l\u2019automatisation, avec des valeurs coh\u00e9rentes.<\/p>\n Cette capacit\u00e9 \u00e0 actualiser automatiquement les donn\u00e9es est pr\u00e9cieuse pour tous les tests que vous effectuez, m\u00eame les tests unitaires pilot\u00e9s par les d\u00e9veloppeurs qui peuvent d\u00e9pendre de donn\u00e9es lues dans des fichiers. Il est certain que les tests fonctionnels effectu\u00e9s par le service d\u2019AQ doivent pouvoir actualiser facilement leurs donn\u00e9es, car ils essaient de d\u00e9couvrir des bugs qui pourraient corrompre leurs donn\u00e9es de test pendant la phase de test. M\u00eame l’utilisation d’outils de test qui g\u00e8rent les mises \u00e0 jour de donn\u00e9es par le biais d’un processus de retour en arri\u00e8re peut laisser des donn\u00e9es erron\u00e9es si le personnel d’AQ rencontre une erreur importante et que le processus de script de test est interrompu.<\/p>\nSommaire<\/h2>\n
\n
1. Pourquoi les donn\u00e9es de test sont-elles importantes ?<\/h2>\n
2. Les donn\u00e9es de test sont importantes, m\u00eame pour les tests unitaires !<\/h2>\n
3. La coh\u00e9rence des donn\u00e9es est la base des tests de r\u00e9gression fonctionnels<\/h2>\n
4. Comment garantir la confidentialit\u00e9 des donn\u00e9es de test – et les actualiser en cas de besoin ?<\/h2>\n
![\"Philippe](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2020\/05\/jeff-tickner.jpg\" "\\"Jeff")
<\/span><\/div><\/div><\/div>