Pour dessiner les aspects de quelques réponses ensemble et ajouter mon 2p ...
Remarque: mes commentaires concernent les tests de base de données en particulier , et non les tests d'interface utilisateur (bien que de toute évidence similaire s'applique).
Les bases de données ont tout autant besoin de tests que les applications frontales, mais ont tendance à être testées sur la base de "cela fonctionne-t-il avec le front-end?" ou "les rapports produisent-ils le résultat correct?", qui à mon avis est testé très tard dans le processus de développement de la base de données et pas très robuste.
Nous avons un certain nombre de clients qui utilisent des tests unitaires / d'intégration / système pour leur base de données d'entrepôt de données en plus de l'UAT / performance / et al. tests. Ils constatent qu'avec une intégration continue et des tests automatisés, ils détectent de nombreux problèmes avant de passer à l'UAT traditionnel, économisant ainsi du temps dans l'UAT et augmentant les chances de succès de l'UAT.
Je suis sûr que la plupart conviendraient qu'une rigueur similaire devrait être appliquée aux tests de base de données comme aux tests frontaux ou de rapport.
L'essentiel avec les tests est de tester de petites entités simples, en s'assurant de leur exactitude, avant de procéder à des combinaisons complexes d'entités, en garantissant leur exactitude avant de s'étendre au système plus large.
Pour donner un peu de contexte à ma réponse ...
Tests unitaires
- a un objectif de test pour prouver que l'unité fonctionne, par exemple une table, une vue, une fonction, une procédure stockée
- devrait 'stub' les interfaces pour supprimer les dépendances externes
- fournira ses propres données. Vous avez besoin d'un état de départ connu des données, donc s'il y a une chance de pré-test des données existantes, alors des troncatures / suppressions devraient se produire avant le remplissage
- fonctionnera idéalement dans son propre contexte d'exécution
- s'effacera après lui-même et supprimera les données qu'il a utilisées; ceci n'est important que lorsque les talons ne sont pas utilisés.
Les avantages de cette opération sont que vous supprimez toutes les dépendances externes sur le test et effectuez la plus petite quantité de tests pour prouver l'exactitude. De toute évidence, ces tests ne peuvent pas être exécutés sur la base de données de production. Il se peut qu'il existe un certain nombre de types de tests que vous ferez, selon le type d'unité, notamment:
- vérification du schéma, certains pourraient appeler cela un test de «contrat de données»
- valeurs de colonne passant
- l'exercice de chemins logiques avec différentes valeurs de données pour les fonctions, procédures, vues, colonnes calculées
- test de cas de bord - NULL, mauvaises données, nombres négatifs, valeurs trop grandes
(Unité) Test d'intégration
J'ai trouvé ce post SE utile pour parler de différents types de tests.
- a pour objectif de tester pour prouver que les unités s'intègrent ensemble
- effectué sur un certain nombre d'unités ensemble
- devrait 'stub' les interfaces pour supprimer les dépendances externes
- fournira ses propres données, pour supprimer les effets des influences des données externes
- fonctionnera idéalement dans son propre contexte d'exécution
- disparaîtra après lui-même et supprimera les données créées; ceci n'est important que lorsque les talons ne sont pas utilisés.
En passant des tests unitaires à ces tests d'intégration, il y aura souvent un peu plus de données, afin de tester une plus grande variété de cas de test. De toute évidence, ces tests ne peuvent pas être exécutés sur la base de données de production.
Ce procède ensuite sur système de test , tests d' intégration système (aka tests de bout en bout 2), avec l' augmentation des volumes de données et l' augmentation de la portée. Tous ces tests devraient faire partie d'un cadre de tests de régression. Certains de ces tests peuvent être choisis par les utilisateurs pour être exécutés dans le cadre de l'UAT, mais UAT est les tests définis par les utilisateurs , pas tels que définis par l'informatique - un problème courant!
Alors maintenant que j'ai donné un certain contexte, pour répondre à vos vraies questions
- le préremplissage des données pour les tests unitaires et d'intégration peut provoquer de fausses erreurs de test et doit être évité.
- La seule façon d'assurer des tests cohérents est de ne faire aucune hypothèse sur les données source et de les contrôler rigoureusement.
- un contexte d'exécution de test distinct est important, pour garantir qu'un testeur n'entre pas en conflit avec un autre testeur effectuant les mêmes tests sur une branche différente du code de base de données contrôlé par la source.