Gens assimilent souvent avec des tests de performance de test de charge. Tests de charge est considérée comme un moyen de répondre à la question « à quelle vitesse le système réagit-il? » Ce point de vue tend à signifier que tests de charge est considérée comme une fin de l'activité de projet. Nous aurons la mise en œuvre finale pour tester les performances qu'à la fin du développement, et donc nous pouvons confirmer qu'alors qu'il effectue assez rapidement dans le monde réel et en douceur la transition en service direct.
Mauvaise approche ! C'est extrêmement risqué et ne manque pas à côté des nombreux avantages de commencer dès le début des tests de charge et de l'appliquer tout au long du projet. Avec cette approche est le système naviguer par le biais de tests de charge et de la transition en douceur en service ? Parfois Oui. Mais le plus souvent le système démarre à l'échec comme charge commence à s'appliquer, même avec petites augmentations de volume... Pour la première fois il y a des demandes concurrentes sur le système et l'arbitrage sur les ressources est nécessaire. Chemins à travers le code qui n'ont jamais été exécutées sont déclenchées, que personne n'a vraiment pensé à travers des situations. Les transactions échouent. Systèmes de tomber en panne. Après que ces problèmes sont corrigés et plus de force appliquée dans une épreuve, nous rencontrons ensuite des problèmes comme l'épuisement des ressources, les débordements de tampon, les délais d'attente et le comportement incohérent. Le véritable travail nécessaire pour transformer un système fonctionnel de pré-production dans une solution robuste ne fait que commencer.
Les exemples abondent de produits qui ont échoué quand essai commencé de chargement et, après beaucoup d'effort, de stress et de dépenses, ont été mis en veilleuse. Pire encore sont ceux qui manquait au total de test de charge et n'a pas considérablement au cours de l'exploitation en direct. Un développeur de portail internet arrêté récemment mise au point d'un nouveau service, qui avait terminé le développement fonctionnel, lors de tests de charge ont révélé des problèmes structurels fondamentaux et inefficace de codage qui a conduit à une exécution mal et le système instable.
Alors que faire pour éviter ces risques ? Nous le savons tous qu'il est préférable de trouver des défauts au début quand ils coûtent beaucoup moins de Difficulté encore de tests de charge reste jusqu'à aussi tard que possible. Les types d'erreurs qu'il trouve fréquemment besoin de modifications architecturales et réécritures majeurs qui sont par puis sont extrêmement coûteux à mettre en œuvre. La réponse est que vous devriez commencer tôt. Différentes formes de tests de charge doivent être appliquées à plusieurs reprises tout au long du projet pour l'identification précoce des problèmes et pour vérifier que le système n'est pas en hors piste.
Il s'agit d'un prolongement naturel de la pratique du développement de l'essai mené. Développement de led, où des tests automatisés sont rédigés en premier lieu et code doit passer ces tests d'essai telle qu'elle est développée, offre des avantages majeurs. Toutefois, dans sa forme actuelle, la mise au point de ce test est sur la fonctionnalité. Son évolution l'état fonctionnel du logiciel est toujours connue et donc gérables failles fonctionnelles sont tuées dans le œuf en évitant le coût élevé de bugs, le risque est considérablement réduit. Pas tellement d'autres risques. Si un projet effectue précoce et continu charge tester que cela devient beaucoup plus large et la réduction globale des risques. Pour faire cela est efficace :
1. Étudier le système et effectuer une analyse des risques pour aider à commander les menaces pesant sur le système, cela vous aidera à privilégier les activités de test de charge.
2. Collecte de données pour permettre une comparaison de l'efficacité de différentes générations. Cela permet une surveillance de l'évolution à long terme, « le système utilise plus et plus de temps processeur pour le même travail? » Ces données peuvent servir à prévoir les ressources nécessaires à différents niveaux de la demande et donc soutenir les prédictions de l'évolutivité.
3. Exécuter des tests visant à évaluer le comportement du système et aux failles de la gâchette sous charge. Utiliser des charges de travail qui simulent les tendances attendues de la demande d'observer le comportement global du système. Utilisez des charges extrêmes spécialement ciblés pour sonder les vulnérabilités du système.
4. Inclure la gamme complète de tests de charge dans la suite de tests. Cela signifie la performance des tests avec des charges de travail période typique et occupé ; les impacts des essais de contrainte pour vérifier les crampons demande atypique et épuisement des ressources ; essais d'endurance qui utilise la période opérationnelle tant l'opération cumulative teste ; fiabilité test qui s'exécute beaucoup de transactions et vérifie ensuite si des opérations occasionnelles échouent ; simultanéité à l'essai des deux utilisateurs travaillant sur le même compte en même temps.
5. Conception mesure activités comme scientifiques concevraient une expérience, conçoivent qu'ils fournissent des données qui peuvent être analysées. Le système sous charges de travail différentes stabilisées pour fournir plusieurs jeux de données à l'appui d'interpolation de l'échantillon. A choisi les charges de travail à permettent d'estimer les coûts pour chaque type de transaction.
6. Cibler le middleware d'abord avec les activités de nature générique et évoluer la suite telle que la fonctionnalité est développée. Commencer tôt et puis de tester chaque version incrémentale du système, d'abord avec la suite précédente, puis avec une suite modifiée qui traite des nouvelles fonctionnalités.
7. Investir du temps et des ressources pour travailler à l'échelle représentante. Peut-être que le banc d'essai ne peut pas être pleine échelle mais il n'est pas deux ordres de grandeur plus petites que le système prévu. Soyez intelligent et novateur d'utiliser efficacement les ressources pour fournir un banc d'essai une échelle appropriée. Les frais qui seront engagés si ce n'est pas fait dépassera de loin le coût de fourniture du banc d'essai.
8. Ne tardez pas ; tester un incrément dès que possible. Ne sautez pas une, ou vous finirez tous sauter. Comparer les mesures et les comportements avec la précédente, est-ce mieux ou pire ?
9. Fournir une charge de fond pour le test fonctionnel. Des fonctionnalités qui fonctionnent le déchargement peuvent échouer lorsque le système a d'autres choses à penser.
10. Tenir compte des événements occasionnels tels que les pannes de serveur et de la reconfiguration du système. Ceux-ci doivent-ils être mis à l'essai sous charge ?
En conclusion, vous devez incorporer des tests de charge pendant tout le processus de développement. Laissant les tests de charge jusqu'à ce que la dernière descente en service direct est une recette pour un désastre. Si cela est devenu une pratique courante puis des applications et des systèmes qui fonctionnent beaucoup plus seraient remis à temps et au budget.
No comments:
Post a Comment