Dans les tests fonctionnels, dois-je comparer toutes les données tabulaires rendus dans le navigateur avec celui qui vient de la DB?

Question

Je travaille sur un plan de test pour un site Web où certains tests prennent le chemin suivant:

1. Hit l'URI demandé et obtenir les données rendues dans une table (20 lignes par page).
2. une requête de base de données pour obtenir les données qui est censé être rendu dans ce tableau.
3. Comparer les 2 données ligne par ligne, ils doivent correspondre.

Est-ce une bonne façon de faire des tests fonctionnels? Si cette demande était une requête Ajax, ce sera la réponse aussi? Est-ce que la réponse différente pour les tests d'intégration?

J'ai une raison qui me fait croire que cela est faux en quelque sorte .... encore besoin de vos avis les gars!

Answer 1

Oui, cela pourrait être un test productif. Soit vous avez une donnée fixe set ou non.

Si vous disposez d'un ensemble de données fixes, cela est beaucoup plus facile à tester, parce que tout ce que vous faites est à comparer contre une sortie fixe.

Si vous ne disposez pas d'un jeu de données fixes, alors vous devez dupliquer la logique métier, dupliquer efficacement le travail déjà accompli par le développeur. Ensuite, vous avez deux ensembles de logique pour maintenir.

La seconde est la meilleure approche parce que vous obtenez deux façons de faire la même chose, en fait un examen par les pairs de la spécification et le code. Il est également très coûteux en termes de temps et de ressources, ce qui explique pourquoi la plupart des gens choisissent d'avoir un ensemble de données fixe.

Pour répondre à votre question, si votre logique métier dans la requête est simple, vous pouvez obtenir un test très facilement. Cependant, la valeur que le test apporte est pas grande, parce que vous ne testez pas beaucoup.

Si la logique métier est complexe, vous obtenez plus de valeur à partir du test, mais il va être plus difficile à maintenir à long terme.

Pour moi, ce que votre test n'apporte est un simple test d'intégration qui prouve que le système lit correctement à partir de la base de données et affiche les données correctement. Ceci est un bon test, encore mieux s'il est automatisé.

Answer 2

Cela semble bien pour les tests fonctionnels. Les tests d'intégration dans mon esprit a à voir avec les tests des différentes technologies ou composants qui sont censés travailler ensemble, ce qui est généralement plus large que les tests fonctionnels. Mais bien sûr, ce genre de test pourrait aussi envisager des essais d'intégration, selon la façon dont votre application est mis en place et où les tests se passe dans le cycle de vie de votre développement. Par exemple, il se peut que vous devez travailler mis en place quelques composants qui ont été développés indépendamment pour que ce site; cela pourrait être l'un des tests pour vérifier que l'intégration fonctionne.

Ne vois pas comment cet être Ajax ou non n'a rien à voir avec la réponse différente faire.

Answer 3

Je probablement une opinion dissidente, mais je ne pense pas que ce soit un test productif. Ce que vous faites est tout simplement le code dédouble qui produit la page. Et chaque fois que vous introduisez le code dupliquée (même dans tous les ministères), vous regarderez les défauts de culture à long terme.

Il est préférable de charger le DB avec des données connues (soit par l'application, ou directement), puis vérifiez que la sortie correspond à ce que vous attendez. Cela garantit également que votre couche de DB ou lui-même, n'a pas modifié les données d'une manière que vous ne vous attendez pas.

C'est:

1. Charger les données connues (de préférence par le biais de l'application elle-même)
2. Charger l'URI demandé
3. Vérifiez que les données affichées correspondent à vos données connues

Answer 4

Ce genre de test pourrait être bon pour tester un grand ensemble de données avec relativement peu d'effort de tester s'il n'y a pas beaucoup de logique de développement entre la base de données et l'affichage à l'utilisateur final. Notre équipe a fait cela à plusieurs reprises, et il est particulièrement utile pour l'exécution de grandes quantités de données réelles de production grâce à nos tests pour être sûr que les scénarios réels sont traités comme prévu. N'assurez-vous faire au moins un peu d'entrée fixe pour tester des scénarios rares qui pourraient être particulièrement susceptibles d'être traitées différemment dans la base de données et sur la page Web - valeurs nulles, des caractères spéciaux et autres bizarreries.

Personnellement, je qualifierais ce « test d'intégration », puisque vous testez l'intégration de la base de données et le site Web, et non « tests fonctionnels ». Pour « tests fonctionnels », je veux probablement faire une maquette de la source de données (par exemple, la base de données) qui fournira des ensembles pré-écrit des données dans le format que vous attendez.

Cela dit, si j'avais une grande confiance dans la validité des données DB et si la logique entre la requête DB et l'affichage de la page Web était très petite et faible risque, je ne serais probablement pas pris la peine avec la maquette et serait laissez le test d'intégration couvre la fonctionnalité ainsi. Je ne sais pas tester la fonctionnalité et l'intégration séparément serait une grande victoire de la qualité dans ce cas, et il y a probablement de meilleures choses que vous pourriez faire avec le temps de test disponibles. S'il y a beaucoup de logique autour de ces données, vous devriez probablement tester séparément l'intégration de la fonctionnalité. les tests d'intégration supplémentaire comprendrait probablement des choses comme: « Et si la base de données ne peut pas être atteint? » et « si la base de données est lent? ».

Bien que cette technique fonctionne avec l'Ajax, assurez-vous que vos outils de test travailleront avec l'Ajax. Plus précisément, pensez à la façon dont vous allez capturer les résultats de la requête de base de données et comment vous recueillerez les résultats affichés sur la page Web.

Je suppose que la validité des données contenues dans la requête est en cours de test ailleurs, puisque vous avez mentionné que cela était juste un type de test dans le plan de test. Je suis aussi juste de discuter l'intégration avec la base de données et ce rapport et non d'autres caractéristiques ou composants, et non d'autres aspects des tests (performance, sécurité. Etc.), depuis qui a été la portée de votre question.