Tester les comptes et les produits dans un système de production

Question

Est-il utile de concevoir un système permettant d’attendre que les comptes et produits de test soient présents et actifs dans la production, ou si les bases de données de production ne sont pas contaminées par des entités de test, même si votre équipe d’expédition sait ne pas expédier de boîte adressée à " ; Test Client "?

J'ai mis en œuvre des protocoles de messagerie qui ont la propriété test = " True " attribut dans la spécification, et se demandait si un schéma moderne devrait inclure des métadonnées pour le balisage des ordres, comptes, transactions, etc. en tant qu’entités de test traitées comme toutes les autres entités, mais juste au-dessous du point où l’argent est dépensé. C'est-à-dire qu'il fait payer une carte de crédit imaginaire et l'envoi d'un colis.

Cela ne devrait pas remplacer une base de données de tests, de développement et d'assurance qualité entièrement séparée, mais même avec celles-ci, nous avons toujours eu la référence Test SKU et Test Client dans le système de production. Inoffensif?

Answer 1

Avoir des comptes de test en production est une chose sur laquelle je crains généralement, car cela ouvre une faille de sécurité potentielle. Il faut s’efforcer de dupliquer le plus possible l’environnement de production lors des tests, mais il est évident que cela n’est pas possible. Un matériel de production onéreuse est un excellent exemple. Je dirais qu'en règle générale, cela devrait être découragé, mais comme pour toute chose, si vous pouvez fournir une raison qui vous semble logique, vous risquez de passer à côté d'une règle absolue.

Answer 2

J'imagine que la police des meilleures pratiques énoncerait le mantra "jamais de test en prod". et peut-être même jeter "les développeurs ne devraient pas avoir accès à prod".

Cependant, je travaille sur un système mainframe où il existe de grandes différences entre production et test / qa / qc; plus le système est large, plus une telle situation est probable. En outre, plus le nombre de groupes concernés par l’application est grand, plus il est probable.

J'ai besoin de plus de deux mains pour compter combien de fois nous ne pouvions que dupliquer un problème dans l'environnement de production. L’option devient alors la création de tables de test / utilisateurs / données ou l’utilisation de données clients réelles.

Parfois, nous créons également des enregistrements de test dans des tables de production, car certains utilisateurs / clients aiment avoir quelque chose qui peut toujours être recherché / extrait et qui est toujours là.

Mon conseil est donc qu'il est correct de mettre des produits / comptes tests en production si cela peut aider à résoudre les problèmes après la mise en production.

Answer 3

Si votre base de données est créée à partir de scripts de manière automatisée, cela ne pose plus de problème.

Dans mon environnement, nous utilisons le régulateur de vitesse pour les constructions continues. Les scripts SQL pour générer la base de données sont archivés dans CVS avec tout le reste, et la base de données est reconstruite quotidiennement à partir de ces scripts.

Nos données de test sont un deuxième ensemble de scripts SQL, qui sont exécutés pour la base de données de test et non pour la base de données de production.

Étant donné notre environnement, les données de test ne touchent jamais la base de données de production.

Cette solution fonctionne vraiment très bien pour nous.

Answer 4

Je ne voudrais pas mettre de données de test dans un système de production et je ne voudrais pas non plus avoir accès à ce système en tant que développeur.

Je travaille dans un secteur avec des informations médicales et financières très sensibles, ce qui rendrait impossible la distinction entre les données productives et les données extraites du système de test.

À mon humble avis, la meilleure pratique consiste à séparer complètement ces deux mondes et à investir dans la mise en place d’une procédure de préparation d’un environnement de test complet.

Answer 5

Dans nos systèmes ERP (accessibles en interne uniquement), nous disposons de données de test qui permettent de tester le processus dans son intégralité lorsque des modifications sont apportées aux environnements de test. Je considère ces données comme un mal nécessaire, car de subtiles différences de configuration entre systèmes peuvent entraîner des résultats catastrophiques. Ainsi, une fois qu'un changement est intervenu dans la production, nous testons intégralement avant de "publier". aux utilisateurs.

Comme je l’ai dit cependant, il s’agit uniquement d’applications internes. Les risques de sécurité sont donc quelque peu atténués - c’est une préoccupation très valable.

Answer 6

Ne jamais tester en prod, même si c'est là que tout le revenu est généré / les statistiques sont collectées / que la magie se produit ...?

Ayez toujours un plan de test de production. Il va y avoir des problèmes avec prod, ou, si vous êtes malchanceux, seulement avec Prod. Si vous n'avez rien mis en place, la première fois que vous devez tester des prod (qui sont généralement des cas de stress élevé), vous serez dans le ruisseau sans pagaie.

Il n’est pas inoffensif d’avoir des données de test sur prod, vous devez être prudent.