6761 Validation de la conformité 21.03.2007 Peter DAEHNE 1
Tests de stress Les tests de stress permettent d étudier le comportement du logiciel lorsque celui-ci est mis dans des situations extrêmes, aux limites de ses capacités. Exemples: À la fin de la journée, lorsque l heure passe de 23:59:59 à 00:00:00, le système doit reconnaître que 00:00:00 est plus tard que 23:59:59 ou encore problème de l an 2000. Si le système est prévu pour traiter au maximum n transactions simultanées, que se passe-t-il si on lui en soumet n+1 ou n+2? Que se passe-t-il si le système est en fonction pendant une grande période de temps sans redémarrage? Peter DAEHNE -2-2
Tests de redémarrage Les tests de redémarrage permettent de vérifier le comportement du système après une fin anormale telle que le crash du système après une panne de courant par exemple. Ils comprennent également la vérification du fonctionnement correct de la procédure de backup-restore. On vérifie que le système continue de fonctionner correctement après une procédure de restauration des informations. Ces tests peuvent la plupart du temps être effectués au moyen de la procédure de test de non régression ou encore de celle du test d acceptance. Peter DAEHNE -3-3
Qui effectue les tests? Type de test Debugging du code Tests unitaires Tests des modules fonctionnels Tests d intégration des modules Tests d intégration des ss-systèmes Tests du système complet Tests d acceptation Autres tests Testeur Développeur Développeur Développeur Tierce personne (Qualité) Tierce personne (Qualité) Groupe de test développement Groupe de test utilisateurs Groupe de test développement Peter DAEHNE -4-4
Conduite des tests Comme tout projet, les tests doivent être planifiés, conçus, documentés audités et réalisés. La planification s effectue simultanément et en parallèle avec la planification du développement.. Cas de test sont définis à partir des spécifications et conçus en fonction du niveau de test considéré (unitaire, des modules fonctionnels, d intégration, d acceptation). La procédure de test définit pas à pas les diverses actions à entreprendre (quel bouton appuyer, quelles données fournir, ) et les résultats attendus exemple de document. Peter DAEHNE -5-5
Stratégie de test Peter DAEHNE -6-6
Stratégie de test Peter DAEHNE -7-7
Stratégie de test Peter DAEHNE -8-8
Stratégie de test Peter DAEHNE -9-9
Stratégie de test Peter DAEHNE -10-10
Stratégie de test Peter DAEHNE -11-11
Revue des procédures de test Le responsable qualité doit non seulement s assurer que des procédures de test soient définies à chaque étape, mais il doit encore s assurer que celles-ci sont documentées et menées conformément au planning. En l absence de documentation, les tests ont tendance à être effectués de manière non disciplinée, lorsque les développeurs ont le temps. Les tests sont relégués au second plan principalement lorsque les budgets ou le planning sont dépassés. Une procédure de test bien planifiée et bien documentée, couvrant la totalité du cycle de vie réduit ces risques. Peter DAEHNE -12-12
Tests automatisés L intégration des différents outils de développement (conception, réalisation, déploiement, ) a conduit les éditeurs de logiciel à concevoir des outils permettant de concevoir des procédures de test automatisées. Nécessitent un investissement non négligeable en temps de configuration du logiciel de test automatique. La configuration du logiciel de test automatique doit être tenue à jour en parallèle avec l évolution du logiciel en cours de développement. Permet d obtenir des rapports standardisés et exploitables électroniquement. Peter DAEHNE -13-13
Types de tests automatisés (1) Audit de code: Vérification de la conformité du code aux standards de codage. Taille des unités. Détection des instructions inatteignables. Niveaux d imbrication des boucles, des appels de sous-programmes. Commentaires et documentation. Vérification de la couverture: À partir d un cas de test donné, les instructions du code effectivement exécutées par le cas de test sont répertoriées. On calcule alors la liste des instructions non testées ainsi qu un pourcentage de couverture. Peter DAEHNE -14-14
Types de tests automatisés (2) Tests fonctionnels: Tests unitaires. Tests des modules fonctionnels. Tests de non régression. Les cas de tests sont répertoriés dans une base de données. Des rapports standardisés sont émis. Tests de charge: Cas typique d un type de test qu il est difficile d effectuer à la main. Définition de scénarios représentant les cas de charge maximale. Les résultats obtenus comprennent en général des mesures de performance en termes de temps de réaction du système à certaines situations, de ressources (processeur / mémoire / réseau) employées, etc. Peter DAEHNE -15-15
Avantages des tests automatisés (1) Tous les tests prévus dans le plan de test sont exécutés complètement et avec des résultats probants. Durant une phase de test manuelle, le développeur est en général moins concentré. Il est facilement amené a omettre certaines parties du test, à oublier certaines saisies, etc. Toutes les erreurs détectées sont répertoriées dans un rapport standardisé. Le développeur qui effectue son test de façon manuelle peut omettre de noter certaines erreurs ou en répertorier d autres de façon erronée dans ses rapports. Les informations sont complètes et exploitables électroniquement. Les résultats étant stockés dans une base de données, celle-ci peut être exploitée pour en extraire diverses informations (to-do list, statistiques, etc.) Peter DAEHNE -16-16
Avantages des tests automatisés (2) Économie de main d oeuvre. Une automatisation des tests nécessite très peu de ressources en main d œuvre, contrairement à l exécution manuelle de ceux-ci. Le temps nécessaire aux tests est plus court. Les tests automatiques peuvent être lancés durant la nuit. Aucun temps n est consacré à la saisie. Les tests de régression sont effectués complètement. Pour des raisons de coûts en main d oeuvre, les tests de régression ne sont en général effectués que sur les modules ayant effectivement changé. Une procédure automatique permet de les repasser tous, augmentant ainsi les chances de détection d erreurs. Peter DAEHNE -17-17
Inconvénients des tests automatisés Investissements plus lourds en logiciel et formation. Les logiciels de tests automatiques doivent être achetés et les développeurs formés à leur configuration et exploitation. Investissement en main d œuvre. La préparation initiale du plan de test et la configuration du logiciel prend en général plus de temps que les mêmes tâches effectuées dans le cadre d un plan de test manuel. De nombreux aspects du test ne sont en général pas couverts par les outils de test automatiques. Les aspects non couverts devront continuer à faire l objet de procédures manuelles. Peter DAEHNE -18-18
Résultats expérimentaux En 1999, sur mandat de l European Systems and Software Institute, une dizaine de grands logiciels avec interface graphique ont été testés en parallèle de façon manuelle et automatique. Voici les résultats obtenus: Peter DAEHNE -19-19