> Tech > Plus de techniques d’automatisation

Plus de techniques d’automatisation

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Nous venons de voir des exemples de code qui automatisent des zones spécifiques des tests de la sécurité, à savoir la réalisation d’un test de configuration et la création des tables servant à stocker les rapports de test et de bogue. Vous pouvez écrire du code pour automatiser d’autres activités

de test, notamment les étapes du processus concernant le reporting et la consignation de bogues.

Comment automatiser la création de rapports de test ? Vous avez vu précédemment un exemple de code créant une table de rapport, nommée tabConfigSettings. Vous avez maintenant besoin du code permettant de transférer les résultats de test dans cette table. Pour cela, vous pouvez employer la simple instruction INSERT suivante, laquelle place dans tabConfigSettings les résultats du test de Service Pack effectué antérieurement :

INSERT tabConfigSettings (ConfigItem, ExpectedSetting) VALUES (‘Version#’, ‘8.00.2039’)

(La valeur Version# utilisée dépend de votre configuration particulière.)
Mieux encore, au lieu de créer des instructions INSERT distinctes pour déplacer chaque ensemble de résultats de test dans la table, vous pouvez faire appel à une procédure stockée, comme celle du listing 6, afin d’automatiser cette tâche pour tous les résultats de test.

Ensuite, il vous faut un moyen de consigner automatiquement les résultats de test. Pour cela, vous pouvez recourir à une instruction UPDATE, similaire à celle du listing Web 1 (Club Abonnés, SQL Server Magazine). Comme chaque paramètre de sécurité reprend la même logique de base que cette instruction UPDATE, il suffit d’encapsuler l’instruction dans une autre procédure stockée, comme l’illustre la procédure upUpdateTestCase du listing Web 2 (Club Abonnés). Cette dernière accepte trois valeurs en entrée : un élément de configuration, un résultat de test et le paramètre réel de l’élément.

Il est possible d’automatiser les rapports de bogue au moyen de techniques de codage similaires à ce que je viens de présenter. La méthode de base pour cela consiste à employer une instruction INSERT similaire à celle du listing Web 3 (Club Abonnés), laquelle attribue à chaque rapport de bogue un TestID unique et spécifie le paramètre de configuration testé, ainsi que d’autres informations connexes. Vous pouvez tout aussi bien écrire une procédure distincte qui insère un rapport après l’exécution d’un test, évidemment en fonction du résultat du test en question, car les bogues sont consignés uniquement si un paramètre de configuration échoue lors du test. Qu’en est-il si une personne souhaite consigner un rapport de bogue manuellement ou au moyen d’un autre outil de test ? Pour gérer ces cas de figure, vous pouvez créer simplement un déclencheur sur la table tabConfigSettings et lui permettre de consigner automatiquement des rapports de bogue.

Comme le montre le code du listing Web 4 (Club abonnés), le déclencheur trgLogBug commence par vérifier si la colonne testresult (qui se trouve dans la table temporaire inserted créée automatiquement par le déclencheur) est définie à Fail. Si ce n’est pas le cas, (autrement dit, le test a réussi), le déclencheur s’arrête et aucun rapport de bogue n’est consigné. Si testresult est définie à Fail, trgLogBug insère un nouveau rapport de bogue dans la table tabBugReports, en récupérant ses valeurs de la table mise à jour tabConfig- Settings.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010