La stratégie d'essai identifie les niveaux multiples d'essai, qui vont être exécutés pour le projet. Des activités à chaque niveau doivent être bien à l'avance projetées et il doit être formellement documenté. Basé sur les différents plans seulement, les niveaux d'essai individuel sont effectués.
L'entrée signifie le point d'entrée à cette phase. Par exemple, pour l'unité examinant, le codage doit être complet et alors seulement un peut commencer l'essai d'unité. Charger est l'activité qui est exécutée. La validation est la manière dont le progrès et l'exactitude et la conformité sont vérifiés pour assurer cette phase. La sortie indique les critères d'accomplissement de cette phase, après que la validation soit faite. Par exemple, le critère de sortie pour l'essai d'unité est tous les cas d'espèce d'unité doit passer.
Plan d'essai d'unité {UTP}
Le plan d'essai d'unité est le plan global pour effectuer les activités d'essai d'unité. L'appareil de contrôle de fil le prépare et il sera distribué aux différents appareils de contrôle, qui contient les sections suivantes.
Que doit être examiné ?
Le plan d'essai d'unité doit clairement indiquer la portée de l'essai d'unité. En cela, normalement l'entrée-sortie de base des unités avec leur fonctionnalité de base sera examinée. Dans ce cas-ci la plupart du temps les unités d'entrée seront examinées pour le format, l'alignement, l'exactitude et les totaux. L'UTP donnera clairement les règles de quels types de données sont présents dans le système, leur format et leurs états de frontière. Cette liste peut ne pas être approfondie ; mais il vaut mieux d'avoir une liste complète de ces détails.
Ordre de l'essai
Les ordres des activités d'essai qui doivent être effectuées dans cette phase doivent être énumérés dans cette section. Ceci inclut, si exécuter des cas d'espèce positifs d'abord ou les cas d'espèce négatifs d'abord, pour exécuter des cas d'espèce basés sur la priorité, pour exécuter des cas d'espèce basés sur des cas d'espèce positifs des groupes etc. d'essai montrent que le système exécute ce qui est censé faire ; les cas d'espèce négatifs montrent que le système n'exécute pas ce qui n'est pas censé faire. En examinant les écrans, les dossiers, la base de données etc., être d'être donné dans l'ordre approprié.
Fonctionnalité de base des unités
Comment on examine les fonctionnalités indépendantes des unités qui exclut n'importe quelle communication entre l'unité et d'autres unités. La pièce d'interface est hors de portée de ce niveau d'essai. Indépendamment des sections ci-dessus, les sections suivantes sont adressées, très détail à l'essai d'unité.
Outils de essai d'unité
Priorité des unités de programme
Nommer la convention pour des cas d'espèce
Statut rapportant le mécanisme
Approche d'essai de régression
Critères d'ETVX
Plan d'essai d'intégration
Le plan d'essai d'intégration est le plan global pour effectuer les activités au niveau d'essai d'intégration, qui contient les sections suivantes.
Que doit être examiné ?
Cette section indique clairement les genres d'interfaces tombent sous la portée d'examiner interne, interfaces externes, avec la demande et la réponse doit être expliquée. Ce besoin aller profondément en termes de détails techniques mais approche générale comment les interfaces sont déclenchées n'est expliqué.
Ordre de l'intégration
Quand il y a multiple des modules actuels dans une application, l'ordre dans lequel ils doivent être intégrés seront indiqués dans cette section. En cela, les dépendances entre les modules jouent un rôle essentiel. Si une unité B doit être exécutée, elle peut avoir besoin des données qui sont alimentées par l'unité A et l'unité X. dans ce cas-ci, les unités A et X doivent être intégrés et alors en utilisant ces données, l'unité B doit être examinée. Ceci doit être énoncé à l'ensemble de totalité d'unités dans le programme. Donné ceci correctement, les activités de essai mèneront au produit, construisant lentement le produit, unité par l'unité et les intégrant alors.
Plan d'essai de système {STP}
Le plan d'essai de système est le plan global effectuant les activités de niveau d'essai de système. Dans l'essai de système, indépendamment d'examiner les aspects fonctionnels du système, il y a quelques activités de essai spéciales effectuées, comme l'essai d'effort etc. Ce qui suit sont les sections normalement actuelles dans le plan d'essai de système.
Que doit être examiné ?
Cette section définit la portée du système examinant, très détail au projet. Normalement, l'essai de système est basé sur les conditions. Toutes les conditions doivent être vérifiées dans la portée de l'essai de système. Ceci couvre la fonctionnalité du produit. Indépendamment du ce quel essai spécial est réalisé sont également énoncés ici.
Groupes fonctionnels et l'ordre
Les conditions peuvent être groupées en termes de fonctionnalité. Basé sur ceci, il peut y avoir des priorités également parmi les groupes fonctionnels. Par exemple, dans une application d'opérations bancaires, quelque chose lié aux comptes de client peut être groupé dans un secteur, quelque chose lié aux transactions d'inter-branche peut être groupé dans un secteur etc. la même manière pour le produit étant examiné, ces secteurs doivent être mentionnés ici et les ordres suggérés de l'essai de ces secteurs, basé sur les priorités doivent être décrits.
Plan de contrôle de réception {triphosphate d'adénosine}
Le client à leur endroit exécute l'essai d'homologation. Il sera très semblable à l'essai de système réalisé par l'unité de développement de logiciel. Puisque le client est celui qui décide le format et les méthodes d'essai en tant qu'élément de l'essai d'homologation, il n'y a aucun indice spécifique sur le chemin qu'ils effectueront l'essai. Mais il ne différera pas beaucoup de l'essai de système. Supposer que toutes règles, qui sont applicables à l'essai de système, peuvent être mises en application au contrôle de réception également.
Puisque c'est juste un niveau de déterminer fait par le client le produit global, il peut inclure des cas d'espèce comprenant les détails de niveau d'unité et d'essai d'intégration.
Un contour de plan d'essai témoin avec leur description est comme montré ci-dessous :
Contour de plan d'essai
1. FOND - cet article récapitule les fonctions du système d'application et des essais à exécuter.
2. INTRODUCTION
3. Des PRÉTENTIONS - indique toutes les prétentions prévues qui seront faites tout en examinant l'application.
4. Des ARTICLES d'ESSAI - énumérer chacun des articles (programmes) à examiner.
5. Des DISPOSITIFS À EXAMINER - énumérer chacun des dispositifs (des fonctions ou des conditions) qui seront examinés ou démontrés par l'essai.
6. DISPOSITIFS À NE PAS EXAMINER - énumère explicitement chaque dispositif, fonction, ou condition qui ne sera pas examinée et pourquoi pas. 7. APPROCHE - décrire les flux de données et la philosophie d'essai.
Simulation ou exécution de phase, etc. Cette section mentionne également toutes approches qui seront suivies aux diverses étapes de l'exécution d'essai.
8. CRITÈRES de rapport couvrant de l'ARTICLE PASS/FAIL - liste spécifiée de compté produire et tolérances
9. Des CRITÈRES de SUSPENSION/RESUMPTION - doit-il l'essai du début à l'accomplissement ?
Dans quelles circonstances peut-il être repris au milieu ?
Établir les points de contrôle dans de longs essais.
10. ESSAI DELIVERABLES - Que, sans compter que le logiciel, sera livré ?
Rapport des essais
Examiner le logiciel
11. L'ESSAI CHARGE fonctionnel charge (par exemple, l'équipement réglé vers le haut de)
Administratif charge
12. LES BESOINS ENVIRONNEMENTAUX
Habilitation
L'espace et équipement d'Office
Conditions de matériel/logiciel
13. RESPONSABILITÉS
Qui fait charge dans la section 10 ?
Que l'utilisateur fait-il ?
14. FOURNIR ET FORMER DE PERSONNEL
15. PROGRAMME
16. RESSOURCES
17. RISQUES ET ÉVENTUALITÉS
18. APPROBATIONS
Les détails de programme du divers essai passent comme des essais d'unité, essais d'intégration, essais de système devraient être clairement mentionnés avec les efforts estimés.
Test Plan - Software Test Plan - Test Plan Template Example - Unit Test Plan - Writing Test Plan
