Comment écrire un scénario de test ? --- elle a fait ça

Contexte : Les exigences du cahier des charges du projet à l'œuvre : Pour les projets avec un planning de test supérieur à la 3D, un plan de test doit être rédigé. Après avoir étudié la situation de certains étudiants, sur la base des exigences de cette spécification de processus, un plan de test sera également préparé pour des situations telles que la logique complexe des exigences ou la mise en œuvre technique complexe.

Je (l'auteur) suis principalement responsable des tests du système OMS. Il s'agit d'un nœud important dans l'ensemble du flux d'exécution des contrats. Le positionnement du système consiste à gérer les données de commande dans l'exécution des contrats. Le cœur du flux entre les contrats. Étant donné que le système a un impact important sur le processus commercial global, la structure de processus du système doit être très claire et la qualité doit être strictement garantie. Je veux partager brièvement ma petite habitude d'écrire des plans de test en fonction de mon point de vue personnel et de la situation du système.

0 1 Comment écrire

La méthode de rédaction des plans de test est différente pour chacun. Après quelques statistiques sur le personnel, la plupart des plans de test des étudiants ont commencé après la fin de l'examen du plan technique. En raison des caractéristiques du système, de la compréhension du système et des habitudes d'écriture personnelles, etc., le nœud temporel pour moi d'écrire le plan de test est après la fin de l'examen des exigences, puis dans la conception technique, l'examen technique et d'autres étapes d'optimisation continue et amélioration.

Phase 1 : Avant le début de l'examen des exigences

Quelle est la compréhension préliminaire de cette demande?

Le produit enverra les exigences à l'avance, et il est nécessaire de vérifier le contexte des exigences, les objectifs et la conception des exigences à l'avance. Vérifiez s'il y a un endroit flou en fonction de la demande, par exemple : Y a-t-il une deuxième phase ? Est-ce une solution temporaire ? Polyvalence? Manque-t-il des processus métier ? Les limites des exigences sont-elles claires ? La fonction est-elle conforme au positionnement du système ? Le processus est-il parfait et raisonnable ? etc. L'examen des exigences avec ces questions aide à analyser les exigences et anticipe certains détails commerciaux vagues. Essayez de confirmer tout ce qui peut être confirmé en un seul examen.

La deuxième étape : après le début de l'examen de la demande, la solution technique est en cours de conception

Après examen des besoins :

1. Remplissez le plan de test : remplissez les informations claires sur le niveau de la demande telles que le contexte du projet et les objectifs dans le plan de test.

2. Communication préliminaire : préciser si ce changement de demande implique plusieurs systèmes d'entreprise, et pré-communiquer pour clarifier la limite de la demande et la personne en charge du système associé. Les problèmes connexes permettent de localiser rapidement la personne responsable.

3. Effacez le processus de la demande et dessinez la première version de l'organigramme : utilisez la perspective QA pour dessiner l'organigramme de la demande. Il est préférable de le redessiner lorsqu'il implique le processus. Le développement de ce nœud commence à concevoir la solution technique. Vous pouvez d'abord dessiner l'organigramme du point de vue de la demande et de la pensée du processus métier pur, et enregistrer les doutes.

Il y a encore quelque chose à dire sur l'organigramme : D'une manière générale, le produit aura un organigramme dans la demande. Ce que je pensais au début, c'est que s'il y a un produit, il suffit d'utiliser le produit. Jusqu'à ce qu'il y ait une révision du plan de test, le produit disait : "Cet organigramme 'm'a copié'". C'est aussi un "bon visage" temporaire, peut-être que c'est juste une photo ! Je le dessine moi-même. Lorsque je l'ai dessiné pour la première fois, j'ai constaté que l'organigramme du produit d'origine comportait des "angles morts" pour l'assurance qualité, tels que : le flux d'état n'était pas assez clair et le traitement logique n'était pas assez détaillé. Lors du processus de dessin de l'organigramme, utilisez la perspective des tests d'assurance qualité pour comprendre en détail le processus de flux métier, le traitement logique et les résultats dans différents scénarios.

Dans la conception du schéma technique :

1. Améliorez l'organigramme pour la première fois :

Une fois le dessin de l'organigramme préliminaire terminé, il y a une forte probabilité qu'il y ait des problèmes de processus, tels que des différences de compréhension des méthodes de mise en œuvre du flux d'état, du traitement logique, etc., ou des écarts de mise en œuvre. Nous devons discuter avec le développement et continuer à nous améliorer. C'est le processus de combinaison de la demande et du développement, ainsi que le processus de supervision des liens. Affecter la mise en œuvre de la technologie d'un point de vue commercial pour empêcher la conception aveugle du développement, entraînant des "reprises" causées par un manque de logique de demande ou des écarts de compréhension.

 2. Communication ultérieure et clarification préliminaire des informations :

 (1) Confirmation des limites des exigences, des jalons, etc. : dans le processus d'exigences impliquant l'intégration de plusieurs systèmes, des limites claires des exigences doivent avoir un sentiment d'appartenance. Si le responsable des tests d'exigences n'est pas lui-même, il doit également prendre l'initiative de comprendre le rythme du système associé, le responsable des tests multi-systèmes, le fractionnement des fonctions d'exigences, etc. Des informations claires telles que les limites de chaque système. Il n'y aura pas de "mouches sans tête" pendant le test.

 (2) Confirmation simultanée des demandes et analyse préliminaire. S'il s'appuie sur d'autres systèmes pour assurer la coopération ou s'il doit fournir certaines fonctionnalités à d'autres systèmes, telles que : la préparation des données, la structure des données, la configuration des informations, etc.

(3) Communication rythmique : une compréhension préliminaire du rythme de test d'autres systèmes permet de mieux planifier les plans de test et les stratégies de test.

Par exemple:

• Le service dépendant est lancé plus tard, et les tâches de test liées à cette fonction seront mises en file d'attente plus tard ;

• Si la couche supérieure s'appuie sur cette fonction de service, si le rythme est unifié, la couche supérieure peut initier la couverture de scène, si la couche supérieure est en retard pour tester, elle peut tester l'interface par elle-même ;

• S'il est utilisé par plusieurs systèmes, des tests internes doivent être effectués à l'avance afin de ne pas affecter le rythme des autres systèmes, etc. La connaissance de ceux-ci peut augmenter les conditions préalables à risque telles qu'une forte dépendance et des différences de rythme excessives.

La troisième étape : après la conception des solutions techniques

Il est nécessaire de clarifier la configuration impliquée, la conception de la table de bibliothèque et la mise en œuvre du processus. La correction secondaire du plan de mise en œuvre de la fonction, met à jour le contenu correspondant du plan de test.

1. Confirmation de la logique de processus :

•  Vérifier si l'organigramme est cohérent avec la mise en œuvre après l'examen de la solution technique ;

• Dépendance fonctionnelle de l'interaction multipartite, dépendance séquentielle

2. Confirmation de configuration :

Par exemple, Apollo, la configuration des pages et certains processus en ligne doivent être confirmés avec le produit et le développement de la configuration des données en ligne, et des vérifications de bac à sable doivent être effectuées. 

3. Conception de table de bibliothèque :  

•  La conception de la table de bibliothèque se concentre sur son incidence sur le processus et les données en ligne ;

• Qu'il y ait des changements de champ dans les tables de données à grande échelle, un tel SQL ne peut être exécuté que la nuit. Avant le bac à sable, il est nécessaire de rappeler au développeur d'exécuter l'instruction SQL la veille, afin d'éviter que la progression de la vérification ne soit affecté en raison de la non-exécution ;

• Que la machine d'état change, si la machine d'état OMS change, la ligne ne peut pas être redémarrée après le déploiement du bac à sable, sinon le service ne peut pas être démarré et le frontal O&M doit être communiqué. Les demandes simultanées ne peuvent pas être fusionnées en ligne.

4. Changements d'interface :

S'il y a une augmentation ou une diminution du traitement des champs pour l'interface d'origine, et s'il est nécessaire de clarifier l'appelant de l'interface, si le package jar sera mis à niveau en conséquence. Prenons l'exemple de l'ajout d'un champ. Lorsque le champ est ajouté et qu'il existe une logique de vérification, l'appelant n'a pas mis à jour le fichier jar. Si le champ est nul et qu'il existe une logique, un pointeur nul apparaîtra. Dans ce cas, une régression compatible doit être effectuée.

La quatrième étape : avant la revue du plan de test

Pour ce nœud, s'il existe d'autres systèmes connexes, chaque direction doit avoir clairement défini la conception des exigences et la conception technique. À ce stade, il est nécessaire de prendre une décision finale avec la personne responsable de l'assurance qualité en charge de chaque système et d'améliorer le contenu vague de la première ébauche du plan de test.

1. Existe-t-il une dépendance à la structure des données

2. La scène de l'interaction de la fonction système, la partie principale et la partie concernée des cas d'utilisation de scène liés de manière synchrone ;

3. Pour la situation de s'appuyer sur d'autres systèmes, selon le rythme de test d'autres systèmes, évaluer l'impact et analyser s'il est nécessaire d'ajuster son propre plan de test et sa stratégie de test ;

4. Que dois-je fournir pour les autres systèmes, le nœud de temps prévu, etc.

Cinquième étape : Examen du plan de test

Je termine généralement la révision du plan de test le même jour que le plan technique.Tant que la "chaleur" de la demande est toujours là, il vaut mieux aligner les perspectives, unifier le rythme et les différences. Tout le monde est plus clair sur ce qu'il faut faire ensuite, et le rythme du projet est plus clair.

02 Changements d'orientation

Après avoir bien compris le contenu du plan de test, nous avons constaté que le modèle de plan de test utilisé par notre société contient les caractéristiques de chaque système. Le contenu auquel il faut prêter attention dans le test du projet est comme un plan détaillé, nous rappelant de prêter attention à certains contenus qui n'ont pas été pris en compte. Remplir consciencieusement chaque item peut nous aider à affiner la méthode et le rythme du test. Il existe également un certain processus permettant aux individus de changer leur mentalité entre le moment où ils sont entrés en contact avec le plan de test et le moment où ils ont compris le plan de test.

Agir selon la réglementation :      

Au début, selon les exigences du cahier des charges du projet, le plan de test a été rédigé pour le projet plus large que la 3D. Le processus d'écriture d'un plan de test est aussi un "remplir le blanc" de "ne pas savoir pourquoi". Dans le processus d'écriture de plusieurs plans de test, j'ai trouvé que le module de plan de test dans le plan de test peut affiner le calendrier et faciliter le rythme clair des exigences. Des jalons de rythme clairs se trouvent dans le plan de test, ce qui aide à planifier raisonnablement le rythme du test.

Focus sur : jalons du projet, plan de projet

Recherche multipartite, connaissance de soi et de l'ennemi :      

Après un certain temps, OMS a commencé à recueillir l'accès des entreprises au cours de cette période.Avec l'accès continu de plusieurs entreprises telles que les snacks et les magasins, l'accumulation du processus lui-même a commencé à prêter attention à la limite de test du système, la fonction de connexion nœuds dans la livraison multi-système, et le système Dans le processus de coopération multi-système, ces informations sont très importantes. Il est possible de localiser plus rapidement le problème, son système et ses contacts système, et de résoudre les problèmes plus rapidement. Clarifiez votre propre entreprise, réduisez les angles morts des autres systèmes et améliorez votre façon de penser.

Principaux points d'attention : limites de la demande, répartition de la demande, personnel d'amarrage du système multipartite, préparations préliminaires, etc.

Les tactiques sont claires :

La disposition des moyens de test est aussi importante que la formulation des tactiques sur le champ de bataille. Accroître l'importance de ce module dans une demande d'optimisation de la technologie interne OMS. Après que l'entreprise ait été impliquée à grande échelle dans le système OMS, l'optimisation interne du système a commencé au sein de l'OMS, et le changement le plus important a été l'ajustement du modèle d'inventaire. Cette exigence n'est pas consciente de l'activité externe, mais la structure interne change considérablement. Le contenu de ce plan de test a également été optimisé à plusieurs reprises au cours du processus demandé par le responsable. Il est nécessaire d'avoir une compréhension approfondie de la solution technique, et d'améliorer le contenu du plan de test, tel que : stratégie en niveaux de gris, lié à la configuration, stratégie de test et méthodes de test, etc. Confirmez et pré-communiquez également l'étendue du retour, le système concerné et la personne chargée d'assister le retour. Minimisez le risque, continuez à corriger la direction qui doit être confirmée et assurez-vous de la qualité.

Principaux points d'attention : processus de solution technique, stratégie de test, moyens de test, éléments de configuration et d'inspection, etc.

A proximité des commerces :

Avec l'accumulation des heures de travail, j'ai réalisé que si je veux vraiment comprendre le système, je dois me rapprocher de l'entreprise. Il est très important de comprendre le positionnement du système, la direction du développement et le prochain plan. De cette manière, dans certaines exigences importantes, la conception des exigences peut être analysée en fonction de la direction commerciale, des objectifs à long terme, du positionnement du système, et s'il s'agit d'un développement à long terme, et si la direction de conception technique est adaptée à long terme. itérations à terme. Ce n'est qu'en prêtant attention aux objectifs, au contexte et à la réalisation des exigences que nous pourrons mieux contrôler la qualité.La prémisse du projet doit être commerciale.

Focus sur : le contexte du projet, les objectifs du projet, etc.

0 3 Résumé

J'espère que je ne suis pas seulement un QA, mais aussi un linker qui peut relier les produits et les technologies, rendant la technologie et moi-même plus proches des affaires, et j'espère que les produits peuvent comprendre le système dans de multiples dimensions. J'espère que tout en protégeant la qualité du système, c'est aussi un gardien de rythme de projet qualifié. 

Ci-dessus, quelques-unes de mes petites habitudes, un peu de partage !

Enfin : le didacticiel complet d'apprentissage vidéo sur les tests de logiciels ci-dessous a été trié et téléchargé, et les amis peuvent l'obtenir gratuitement s'ils en ont besoin.【保证100%免费】

 Ces matériaux devraient être l'entrepôt de préparation le plus complet et le plus complet pour les amis [testeurs de logiciels]. Cet entrepôt a également accompagné des dizaines de milliers d'ingénieurs de test tout au long du voyage le plus difficile, et j'espère qu'il pourra vous aider aussi !