Comment le personnel d'assurance qualité peut-il tester une logique de mise en cache qu'il ne peut pas voir?


33

Je viens d'implémenter une couche de mise en cache dans mon application Web et je me demande maintenant comment le contrôle qualité est censé la tester, car la mise en cache est transparente pour l'utilisateur.

Une de mes idées est de consigner les méthodes qui appellent le code qui remplit le cache et d’enregistrer quand un objet est extrait du cache et qu’il nécessite une reconstitution à partir de la base de données. Les testeurs pourraient alors consulter les journaux pour voir si, Par exemple, un certain objet est rechargé à partir de la base de données toutes les 10 minutes, au lieu de chaque affichage de page.

Mais peut-on suggérer de meilleures pratiques pour cette situation?




5
Je travaille sur les performances toute la journée et "comment l’Assurance Qualité peut-elle tester votre changement?" est une question que je me pose constamment.
Brandon

1
De manière générale, un cache est censé accélérer une opération en stockant des résultats en mémoire qui proviendraient d’une autre source (base de données, serveur distant, méthode coûteuse en calcul, etc.). Par conséquent, mesurer le temps qu'il faut pour prendre le cache semble être la méthode la plus simple. Recherchez également les problèmes de cache obsolètes (les mises à jour des données réelles n'apparaissent pas car la version précédente est toujours en cache)
GordonM

Réponses:


37

Une question est de savoir si le cache lui-même est vraiment une exigence qui devrait être testée par QA. La mise en cache améliore les performances, ce qui leur permet de tester la différence de performances pour s'assurer qu'elles répondent à certaines exigences.

Mais bonne idée de faire des tests sur la mise en cache, quel que soit le responsable. Nous avons utilisé des compteurs de performance. Si votre système de cache en profite, ils sont simples. S'il existe un moyen d'obtenir un nombre à partir du cache lui-même, c'est une autre option.

Utiliser votre approche est bien aussi. Si l'un d'entre eux est encapsulé dans des tests automatisés qui vérifient les résultats, personne ne doit consulter les journaux pour trouver des réponses.


+1 pour tester les performances au lieu de la mise en cache. Quelle est la valeur commerciale de la mise en cache seule? (Aucun.) Vous travaillez sûrement pour avoir un impact notable sur quelque chose - pourquoi autrement perdriez-vous du temps à le mettre en œuvre? Testez pour cet impact.
alexanderbird

74

Vous avez implémenté un cache (je suppose) car le système ne fonctionnait pas assez bien. C'est quelque chose qui est pertinent pour l'utilisateur. Voici les points que QA peut vérifier:

  • Le système, après l’introduction du cache, est toujours correct. Cela signifie qu'ils doivent essayer de piéger le cache en fournissant des données obsolètes, ce que QA peut vérifier, et s'assurer que rien d'autre n'a été cassé.
  • Le système répond maintenant à des seuils de performances qu'il ne rencontrait pas lorsque vous avez décidé d'améliorer les performances. Ils peuvent comparer les anciennes mesures et les comparer aux nouvelles.

N'oubliez pas que les utilisateurs (et, par extension, le contrôle qualité) ne se soucient pas de la façon dont vous avez résolu un problème. Ils se soucient seulement que le problème a été résolu et n'a pas créé de nouveaux problèmes. Cela est vrai que vous ayez implémenté la mise en cache, amélioré l'analyse de chaîne, effectué une mise à niveau matérielle ou saupoudré de poussière de fée magique sur le serveur.


1
Affirmer que l’assurance qualité ne tient pas compte de la façon dont vous résolvez le problème est une vue très simpliste de ce qui l’intéresse. Ils veulent savoir si vous avez réellement amélioré les performances, introduit une dette technique, un risque ou des défauts supplémentaires, etc.
Eric

4
@Eric Dans le développement logiciel, "QA" en tant que groupe ne fait généralement pas référence à des développeurs / ingénieurs. La dette technique est une préoccupation des développeurs / ingénieurs (et une préoccupation de la direction car elle peut avoir un impact sur les délais, les coûts, etc.). La même chose est vraie du risque. Le travail de QA consiste à s'assurer que le logiciel répond aux exigences (et éventuellement accessoirement au processus d'élimination des exigences qui n'étaient pas claires). S'ils se soucient de la mise en œuvre, ce ne devrait être qu'un moyen de trouver des moyens créatifs de casser le système.
jpmc26

3
@ Eric je ne confond rien. "QA" fait référence aux testeurs dans le logiciel. Vous interprétez le terme de manière si large qu'il devrait inclure toute la société qui développe le logiciel et même le client s'il s'agit d'un système construit sur mesure pour eux, puisque tout le monde a un rôle à jouer dans la qualité.
jpmc26

1
@ Eric S'il vous plaît, ne me demandez pas comment la langue et la sémantique fonctionnent avec vous. Je vous mets au défi de trouver 5 instances sur ce StackExchange où le terme est utilisé de cette manière en moins de 30 minutes. En outre, même selon cette définition, le mieux qu’un groupe d’assurance qualité puisse faire pour traiter des problèmes dépassant le produit lui-même est d’imposer des règles aux développeurs. Lorsque les règles et les processus sont plus importants que la fabrication de bons produits, vous obtenez généralement de mauvais produits. De plus, je peux vous assurer que les personnes "QA" avec lesquelles je travaille sont très certainement des testeurs et ont peu à dire sur mon processus de développement.
jpmc26

4
@ Eric: rien n'empêche une entreprise ou un groupe de personnes définissant le "contrôle de la qualité" à adopter une vision plus holistique. Cependant, selon mon expérience (dans 5 entreprises très différentes), l’étape de l’assurance qualité telle qu’elle est nommée - et ceux qui s’y spécialisent - dans le développement de logiciels est généralement centrée sur le test du comportement du système au moyen d’une boîte noire. Nous pouvons également avoir "Contrôle de la qualité", "Kwalitee" et des noms plus inventés afin de couvrir les angles spécialisés des problèmes de qualité plus larges.
Neil Slater

3

Enfouir une logique métier ou un état système important dans une boîte noire rend difficile la vérification du comportement correct du système. Il est plus facile de tester de manière exhaustive le comportement d'un seul composant du système que de l'ensemble du système. Je préfère exposer de telles choses explicitement par un mécanisme afin que les tests d'unité / de régression / d'intégration / d'assurance de la qualité soient testés de manière significative.

Une option avec un cache serait d'exposer une page spéciale donnant des détails sur le cache (contenu, état, etc.). Cela peut aider au débogage en développement et potentiellement en production. Le contrôle qualité peut également utiliser cette page pour créer des scénarios de test pour le cache s'ils reçoivent des détails sur le comportement attendu du cache. L'utilisation de compteurs de performance et / ou de fichiers journaux pour documenter explicitement le comportement du cache est une autre approche moins visible mais viable.

Notez que cette approche ne remplace pas les tests de performances de bout en bout. Il s'agit d'un mécanisme permettant de s'assurer que le cache se comporte correctement. Les tests de performances doivent être utilisés pour déterminer si la mise en cache a l'effet escompté sur les performances.

Notez également que l'échange de composants du système avec de nouveaux composants mettant en œuvre la même interface, comme l'introduction d'un cache, peut constituer un changement déstabilisant et complexe. Avec l'exemple de cache, vous introduisez state dans ce qui était auparavant sans état, ce qui peut créer des bogues plus difficiles à trouver ou à reproduire. Un tel changement doit toujours être accompagné d'un test de régression complet pour vérifier le comportement attendu du système.


3

Les performances du test, comme indiqué dans la réponse d'Andy.

J'ai constaté que le plus gros obstacle à la mise en œuvre de la mise en cache (et des performances) dans de nombreuses organisations est de disposer d'un environnement dans lequel vous pouvez effectuer de bons tests de performances et effectuer des tests pour différents tests de charge et de performances dans le monde réel.

Pour cela, vous devez mettre en place un environnement de test de performance qui reflète le plus fidèlement possible la production, tout en tenant compte des coûts. Ce ne sera probablement pas votre environnement de développement actuel, qui devrait être plus petit et plus autonome pour permettre un développement rapide des applications. Les environnements de développement ont également tendance à utiliser moins la mise en cache et ne représentent donc pas bien la production pour les tests de performances.

Dans l'environnement de test des performances, l'application devrait être exécutée en «mode» de production. Si vous êtes en production, vous devez avoir plusieurs serveurs. Le pool de connexion à la base de données et la mise en cache doivent être définis pour un environnement de production, etc.

Vous voudrez également envisager un outil pour aider aux tests de charge.
Jmeter est très populaire bien que je le trouve assez hostile et primitif à utiliser.
Une autre voie que j’ai utilisée est celle d’URL curlavec un script ruby.

Pour être clair

  • Les tests de performances de base servent à tester le temps requis par UNE requête.
  • Le test de charge est similaire au test de performance, mais il examine la réponse lorsque le système est également sollicité par d'autres requêtes.

Vous pouvez également trouver les liens suivants utiles:


2

N'oubliez pas de demander aux testeurs de redémarrer les serveurs et de vérifier que les données qu'ils ont entrées sont toujours présents. J'ai vu un système qui a eu plusieurs mois de tests, échoue lorsque cela a été fait!

La partie la plus difficile à tester est que cependant les données sont mises à jour, il n'y a jamais aucun résultat hors-date de retour du cache.

Cela peut être partiellement aidé en utilisant toujours les données dans le cache pour remplir la page de confirmation qu'un utilisateur voit après avoir apporté une modification. Par exemple, n'utilisez pas l'objet que vous avez utilisé pour mettre à jour la base de données, mais demandez les données à partir du cache, qui les demande ensuite à la base de données. Un peu plus lent, mais beaucoup plus susceptible de présenter des bugs plus rapidement.


1

Celui-ci a en fait une réponse très simple et elle est liée au niveau de mise en cache. Ce que vous allez observer lorsque la mise en cache est correcte, c'est l'absence de demandes à la cible des demandes. Donc, cela revient à la phrase QA usée de «résultats escomptés».

Si vous implémentez un cache au niveau Web, alors je m'attendrais à ce que les éléments soumis à la mise en cache n'apparaissent qu'une fois pour chaque session d'utilisateur testée (si vous implémentez le cache client) ou une fois pour plusieurs utilisateurs (si vous implémentez un cache de style CDN). Si vous implémentez un cache au niveau des données pour des résultats communs, je m'attendrais à voir un taux de réussite élevé dans le cache avec une absence de requêtes dans le journal de profil du niveau de données.

etc...


0

Certaines choses sont mieux testées par un programmeur, peut-être celui qui a écrit le code, en utilisant des tests unitaires. Tester l'exactitude de votre code de cache est l'une de ces choses. (De la manière dont vous posez cette question, je présume que vos agents d'assurance qualité traitent l'application comme une "boîte noire" et la testent via son interface externe.)


0

La logique de mise en cache doit faire l’objet d’un test unitaire par le développeur, car l’Assurance qualité effectue principalement des tests en boîte noire.

L’assurance qualité ne se préoccuperait que des aspects de performance ou du correctif que vous avez mis en œuvre. Vous pouvez donc fournir à l’assurance qualité un mécanisme permettant d’activer / désactiver la mise en cache ou tout autre mécanisme utilisé pour améliorer les performances. Ils peuvent ensuite vérifier la différence de performances. Bien entendu, le contrôle qualité pourrait également simplement vérifier une ancienne version par rapport à votre version à performances améliorées.


-4

Lorsque j'ai testé la solution de mise en cache, nous avons implémenté ce que nous avons essentiellement testé les performances. Nous avons fait cette solution de mise en cache pour les résultats XML et après le cache, la réponse prend très peu de temps. Nous avons également vérifié avec le journal du serveur en vérifiant les entrées du journal.


3
Je ne suis pas tout à fait sûr de comprendre ce que vous dites ou ce que votre réponse dit qui ne figure pas dans les sept réponses précédentes.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.