Comment le personnel d'AQ peut-il tester la logique de mise en cache qu'il ne peut pas voir?
Je viens d'implémenter une couche de mise en cache dans mon application Web, et maintenant je me demande comment QA est censé la tester, car la mise en cache est transparente pour l'utilisateur.
Une idée que j'ai est de mettre la journalisation dans les méthodes qui invoquent le code qui remplit le cache, et d'enregistrer quand un objet est extrait du cache et quand il nécessite une recréation de la base de données, puis les testeurs pourraient afficher 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 quelqu'un peut-il suggérer de meilleures pratiques pour cette situation?
Une question est de savoir si le cache lui-même est vraiment une exigence qui doit être testée par le contrôle qualité. La mise en cache améliore les performances, afin qu'ils puissent tester la différence de performances pour s'assurer qu'elle répond à certaines exigences.
Mais bonne idée d'avoir des tests autour de la mise en cache, quel qu'en 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 compte à partir du cache lui-même, c'est une autre option.
Utiliser votre approche est également agréable. Si certains d'entre eux sont enveloppés dans des tests automatisés qui vérifient les résultats, personne n'a à parcourir les journaux pour trouver des réponses.
Vous avez implémenté un cache (je suppose) parce que le système ne fonctionnait pas assez bien. C'est quelque chose qui est pertinent pour l'utilisateur. Voici des éléments que QA peut vérifier:
- Que le système, après l'introduction du cache, est toujours correct. Cela signifie qu'ils doivent essayer de tromper le cache pour fournir des données périmées, ce que QA peut vérifier, et s'assurer que rien d'autre n'a été cassé.
- Que le système respecte désormais les seuils de performances qu'il ne respectait 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, l'assurance qualité) ne se soucient pas de la manière dont vous avez résolu un problème. Ils se soucient seulement que le problème a été résol 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înes, effectué une mise à niveau matérielle ou aspergé de poussière de fée magique sur le serveur.
Testez les performances, comme indiqué dans la réponse d'Andy.
J'ai constaté que le plus grand obstacle à la mise en œuvre de la mise en cache (et des performances) dans de nombreuses organisations est en fait d'avoir un environnement où vous pouvez effectuer de bons tests de performances et exécuter des tests pour divers tests de charge et de performances dans le monde réel.
Pour cela, vous devez configurer un environnement de test de performances qui, le plus fidèlement possible et en tenant compte des coûts, reflète la production. 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 de performances, l'application doit s'exécuter en "mode" de production. Vous devez avoir plus d'un serveur si la production le fait, le pool de connexions à 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 vous aider avec les 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 de simplement url curl avec un script Ruby.
Pour être clair
- le test de performance de la ligne de base est destiné à tester le temps passé par UNE demande.
- le test de charge est similaire au test de performance mais examine la réponse lorsque le système est également sous charge à partir d'autres demandes.
Vous pouvez également trouver les liens suivants utiles:
L'enfouissement de la logique métier ou de l'état du système 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 l'ensemble du système. Je préfère exposer de telles choses explicitement à travers un mécanisme afin que cela puisse être testé de manière/régression/intégration/QA de manière significative.
Une option avec un cache serait d'exposer une page spéciale qui donne quelques 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 cas de test pour le cache s'ils reçoivent des détails sur le comportement attendu du cache. L'utilisation de compteurs de performances 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 performance de bout en bout. Il s'agit d'un mécanisme permettant de garantir que le cache lui-même 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 implémentant la même interface comme l'introduction d'un cache peut être un changement déstabilisateur et trompeusement complexe. Avec l'exemple de cache, vous introduisez l'état 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é de tests de régression complets pour vérifier le comportement attendu du système.
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 là. J'ai vu un système qui avait plusieurs mois-homme de tests, échouer quand cela a été fait!
La partie la plus difficile à tester est que, quelle que soit la mise à jour des données, il y a jamais tout résultat obsolète renvoyé par le 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 effectué 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 au cache, qui les demandera ensuite à la base de données. Un peu plus lent, mais beaucoup plus susceptible d'afficher les bogues plus rapidement.
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 observerez lorsque la mise en cache est correcte, c'est l'absence de requêtes sur la cible des requêtes. Donc, cela se résume à l'expression de QA galvaudée de "résultats attendus".
Si vous implémentez un cache au niveau Web, je m'attendrais à ce que les éléments soumis à la mise en cache n'apparaissent qu'une fois pour chaque session 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 courants, je m'attendrais à voir un taux d'accès au cache élevé dans votre niveau de mise en cache ainsi qu'une absence de requêtes dans le journal de profil pour le niveau des données.
etc...
La logique de mise en cache est quelque chose qui devrait être testé par le développeur car QA fait principalement des tests en boîte noire.
Le contrôle qualité ne se soucie que des aspects de performances ou de tout correctif que vous avez implémenté, vous pouvez fournir au contrôle qualité un mécanisme pour activer/désactiver la mise en cache ou tout autre mécanisme que vous avez utilisé pour améliorer les performances, puis ils peuvent vérifier la différence de performances. Bien sûr, QA pourrait également vérifier une ancienne version par rapport à votre version améliorée.
Certaines choses sont mieux testées par un programmeur, peut-être celui qui a écrit le code, à l'aide de tests unitaires. Tester l'exactitude de votre code de mise en cache est l'une de ces choses. (D'après la façon dont vous posez cette question, je suppose que votre personnel d'assurance qualité traite l'application comme une "boîte noire" et la teste via son interface externe.)