Consignation de rapports de test

test, ainsi que le résultat final de celui-ci (réussite ou échec). (Nous verrons comment déterminer un résultat escompté dans la section suivante.)

Pour générer un rapport de test, vous pouvez créer une table qui stocke les résultats d’un test de configuration, comme l’illustre le code TSQL du listing 3. Les deux rapports de test présentés dans le tableau 1 contiennent des exemples de résultats similaires à ce que vous obtiendriez après l’exécution des scripts de test de configuration présentés plus haut. (Nous verrons plus loin les techniques de codage pour transférer les résultats des tests dans une table et pour automatiser d’autres parties du processus de test abordées ici.)

La consignation des résultats des tests permet de gagner du temps, favorise la cohérence et réduit les tests en double. Les développeurs peuvent exploiter ces résultats pour reproduire des bogues apparents. Les testeurs peuvent les employer pour vérifier les corrections de bogues apportées. La consignation des résultats joue un rôle dissuasif concernant les tests non planifiés et non documentés. Comme nous allons le voir un peu plus loin, il est possible d’automatiser les rapports de test, tout comme les contrôles de sécurité.

Vous devez également consigner un rapport de bogue à chaque détection d’une violation de la sécurité ou d’une vulnérabilité. Ce rapport doit contenir les mêmes informations que le rapport de test, avec un ID de bogue, la date de consignation du rapport, une description de la violation de sécurité ou de la vulnérabilité et un indicateur d’état (par ex., Testing, Debugging, Awaiting Clarification, Fixed) qui indique l’état du bogue dans le flux de développement. Certaines entreprises exigent également l’identificateur de la spécification ou stratégie de sécurité parent.

Pour consigner des rapports de bogue, il faut d’abord créer une autre table destinée aux données du rapport, au moyen d’une instruction similaire à celle du listing 4. Pour voir l’aspect possible d’un rapport de bogue, prenons un autre exemple : un contrôle de sécurité détecte un serveur s’exécutant sous le compte LocalSystem (une approche à prohiber dans pratiquement tous les environnements de production), comme le montre le listing 5. Le rapport de bogue correspondant à ce contrôle de sécurité pourra avoir l’aspect du tableau 2. Notez que la colonne Current Status a été définie à Debugging, afin de signifier l’arrêt du test jusqu’à la résolution du problème. Une fois le bogue éliminé, l’administrateur ou le développeur réinitialise l’état à Testing (à savoir, un paramètre défectueux, ici LocalSystem, est trouvé et corrigé) ou à Closed (autrement dit, le problème est résolu).