Les tests logiciels : les processus fondamentaux Analyse et conception des tests

 1.4.3. Analyse et conception des tests

La phase d'analyse et de conception est celle où les objectifs de tests généraux – définis par l'entreprise et au niveau du plan de tests* – sont utilisés pour concevoir les conditions de tests de l'application logicielle. Les objectifs généraux identifiés lors de la planification seront utilisés pour construire les dossiers, conditions et procédures de tests. Ces activités sont décrites dans le chapitre 5 et comprennent l'analyse de la base de test* et la conception des conditions de tests.


le niveau d'intégrité indique la criticité du logiciel pour les parties
Le niveau d'intégrité indique la criticité du logiciel pour les parties prenantes. © senicphoto - Fotolia.com

1.4.3.1. Analyse de la base de tests


L'analyse de la base de tests est l'étude des documents permettant de concevoir l'application et définir les objectifs de tests. Cette base de test comprend (liste non limitative) :

 les documents contractuels, tels le contrat et les avenants à celui-ci, les cahiers des clauses techniques particulières (CCTP), cahiers d'appels d'offre, etc. ;

les spécifications de l'application, les spécifications générales et détaillées, l'architecture des composants, l'organisation de la base de données ou des systèmes de fichiers ;

 les documentations des utilisateurs, de maintenance, d'installation, etc. ;

 les risques identifiés ou associés à l'utilisation ou au développement de l'application ;

 les standards applicables, qu'ils soient spécifiques à l'entreprise, applicables à la profession ou spécifiés contractuellement


Une base de test nécessitant un processus formel particulier (négociation,
rédaction et signature d'avenant ou de contrat, etc.) avant de pouvoir être modifiées est appelée une base de test gelée.

L'analyse de la base de tests permet de déterminer les objectifs de tests, leur priorisation et la testabilité de la base de tests et des objectifs de test. Pendant cette phase nous effectuerons l'identification des risques et des priorités de test (niveau d'intégrité) et des environnements de tests (y compris des données de tests) à envisager. Nous effectuerons aussi la sélection des mesures et métriques* qui nous serviront à mesurer l'avancement des tests.

Le niveau d'intégrité indique la criticité du logiciel pour les parties prenantes, et s'établit sur base d'attributs comme les risques ou le niveau de sécurité et de sûreté du logiciel, etc. Le niveau d'intégrité influence la profondeur et l'étendue des tests à exécuter, le type et le niveau de détails de la documentation de tests, et les tâches de tests minimales à effectuer.


Quatre niveaux d'intégrité définis par l'IEEE : catastrophique, critique, marginal, négligeable.

Les niveaux d'intégrité, définis dans le standard IEEE 829:2008 7 sont :

 niveau 4 : catastrophique : le logiciel doit s'exécuter correctement ou des conséquences graves (perte de vie humaine, perte du système, dommages environnementaux, pertes économiques ou sociales) auront lieu. Il n'y a pas de possibilité de mitigation ;

 niveau 3 : critique : le logiciel doit s'exécuter correctement ou l'objet (mission) du logiciel ou du système ne sera pas réalisé, causant des conséquences sérieuses (blessures permanentes, dégradations majeures du système, dommages environnementaux, impact social ou économique). Une limitation partielle ou complète de ces impacts est possible ;

 niveau 2 : marginal : le logiciel doit s'exécuter correctement ou une fonction attendue ne sera pas réalisée, causant des conséquences mineures. Une limitation complète des impacts est possible ;

 niveau 1 : négligeable : le logiciel doit s'exécuter correctement ou une fonction attendue ne sera pas réalisée, causant des conséquences négligeables. Une mitigation n'est pas nécessaire.


Les niveaux d'intégrité de l'IEEE829:2008 peuvent être mis en rapport avec les catégories de pannes décrites dans D0178B/ED12B 8 :

 catastrophique (catégorie A) : condition de panne susceptible d'empêcher la poursuite en toute sécurité d'un vol et d'un atterrissage ;

 dangereuse (catégorie B) : condition de panne susceptible de réduire les possibilités de l'aéronef ou la capacité de l'équipage à faire face à des conditions hostiles pouvant aller jusqu'à :

    1. une réduction importante des marges de sécurité ou des capacités
fonctionnelles,
    2. des problèmes physiques ou un accroissement de charge de travail tels que l'équipage ne soit plus en mesure d'accomplir sa tâche de manière précise ou complète,
    3. des effets négatifs sur les occupants telles que des blessures graves ou potentiellement mortelles pour un petit nombre d'entre eux ;

 majeure (catégorie C) : condition de panne susceptible de réduire les
possibilités de l'aéronef ou la capacité de l'équipage à faire face à des conditions hostiles d'une gravité se traduisant, par exemple , par une réduction significative des marges de sécurité ou des capacités fonctionnelles, un accroissement significatif de la charge de travail de l'équipage ou des conditions affectant son efficacité, ou un inconfort pour les occupants, comportant éventuellement des blessures ;

  mineure (catégorie D) : condition de panne n'engendrant pas de réduction significative de la sécurité de l'aéronef, et susceptible d'entraîner pour l'équipage des actions se situant tout à fait dans le domaine de leurs capacités ;

 sans effet (catégorie E) : condition de panne n'affectant pas la capacité
opérationnelle de l'aéronef ou n'entraînant pas une augmentation de la charge de travail de l'équipage.

L'analyse de la base de tests permet d'identifier les points à tester (objectifs de tests) et de déterminer comment ils seront testés. Une traçabilité depuis la base de tests jusqu'aux objectifs de tests et aux conditions de tests, pour permettre une modification des tests en cas d'avenant ou de modification de la base de tests doit être garantie.

7. [IEEE829:2008], p. 13-14.
8. [DO178B/ED12B], p. 7-8.

Tests applicatifs