Wikipedia on test de charge (gras c'est le mien):
[...] Un test de charge est généralement effectué pour comprendre le comportement du système sous une charge spécifique attendue. Cette charge peut être le nombre attendu d'utilisateurs simultanés sur l'application effectuant un nombre spécifique de transactions dans la durée définie. Ce test donnera les temps de réponse de toutes les transactions critiques importantes pour l'entreprise. [...]
et sur tests de stress :
comprendre les limites supérieures de capacité dans le système. Ce type de test sert à déterminer la robustesse du système en termes de charge extrême et aide les administrateurs d'applications à déterminer si le système fonctionnera suffisamment si la charge actuelle dépasse bien au-dessus du maximum attendu.
Le résultat est donc le suivant: si vous testez la charge normale attendue (vous savez que le système sera utilisé par 100 utilisateurs à la fois), il s’agit de test de charge. Mais lorsque vous voulez déterminer comment le système se comporte sous une charge extrême (DoS, Effet Slashdot ) et quand il se casse, c’est stress test _.
Les termes "tests de résistance" et "tests de charge" sont souvent utilisés de manière interchangeable par les ingénieurs de test de logiciels, mais ils sont vraiment très différents.
Tests de stress
Dans les tests de résistance, nous essayons de casser le système testé en surchargeant ses ressources ou en lui retirant des ressources (dans ce cas, on parle parfois de test négatif). Le but principal de cette folie est de s’assurer que le système échoue et récupère gracieusement - cette qualité est appelée recouvrabilité. OU Les tests de résistance consistent à soumettre votre programme/système testé (SEU) à une réduction de ressources, puis à examiner son comportement en exécutant des tests fonctionnels standard. L’idée est d’exposer des problèmes qui n’apparaissent pas dans des conditions normales. Par exemple, un programme multithread peut fonctionner correctement dans des conditions normales, mais dans des conditions de disponibilité réduite de l’UC, les problèmes de minutage seront différents et le SUT se bloque. Les types les plus courants de ressources système réduites lors des tests de contrainte sont l'UC, la mémoire interne et l'espace disque externe. Lors des tests de contrainte, il est courant d'appeler les outils permettant de réduire ces trois ressources respectivement EatCPU, EatMem et EatDisk.
Tandis que d'autre part Test de charge
Dans le cas de Load test Load test est le processus consistant à soumettre votre système sous test à de lourdes charges, généralement en simulant plusieurs utilisateurs (Using Load Runner), où "utilisateurs" peut signifier des utilisateurs humains ou des utilisateurs virtuels/programmatiques. L'exemple le plus courant de test de charge consiste à soumettre une application Web ou réseau à des hits simultanés de milliers d'utilisateurs. Ceci est généralement accompli par un programme qui simule les utilisateurs. Les tests de charge ont deux objectifs principaux: déterminer les caractéristiques de performance du SUT et déterminer si le SUT "se casse" gracieusement ou non.
Dans le cas d’un site Web, vous devez utiliser le test de charge pour déterminer le nombre d’utilisateurs que votre système peut gérer tout en conservant des performances suffisantes, ainsi que pour déterminer le résultat d’une charge extrême. Le site Web générera-t-il un message "Trop occupé" pour utilisateurs, ou le serveur Web va-t-il tomber en flammes?
Test de charge: Le test de charge est destiné à tester le système en augmentant constamment et régulièrement la charge sur le système jusqu'au moment où il atteint la limite de seuil.
Exemple .__ Par exemple, pour vérifier la fonctionnalité de messagerie d'une application, celle-ci pourrait être inondée de 1 000 utilisateurs à la fois. Désormais, 1 000 utilisateurs peuvent déclencher les transactions par courrier électronique (lire, envoyer, supprimer, transférer, répondre) de différentes manières. Si nous prenons une transaction par utilisateur et par heure, il s'agirait de 1000 transactions par heure. En simulant 10 transactions/utilisateur, nous pourrions charger le serveur de messagerie en l’occupant avec 10000 transactions/heure.
Tests de résistance: .__ Dans le cadre de tests de résistance, diverses activités visant à surcharger les ressources existantes avec des tâches excessives sont effectuées dans le but de décomposer le système.
Exemple: Par exemple, un traitement de texte tel que Writer1.1.0 d’OpenOffice.org est utilisé pour l’élaboration de lettres, de présentations, de tableurs, etc. Le but de nos tests de résistance est de le charger avec un excès de personnages.
Pour ce faire, nous allons coller plusieurs fois une ligne de données jusqu'à ce qu'elle atteigne sa limite de traitement de gros volumes de texte. Dès que la taille de caractère atteint 65 535 caractères, il refuse simplement d'accepter plus de données. Le résultat des tests de contrainte sur Writer 1.1.0 donne le résultat suivant: il ne tombe pas en panne et gère correctement la situation, garantissant ainsi le bon fonctionnement de l'application, même dans des conditions de contrainte rigoureuses.
-> Tester l'application avec le nombre maximal d'utilisateurs et le nombre d'entrées est défini comme test de charge . Lors du test de l'application avec un nombre d'utilisateurs supérieur au maximum, l'entrée est définie comme test de stress .
-> Lors des tests de charge, nous mesurons les performances du système en fonction du nombre d'utilisateurs. Pendant le test de stress, nous mesurons le point d'arrêt d'un système.
-> Le test de charge teste l'application pour une charge donnée qui peut inclure l'un des critères suivants:
.Total number of users.
.Response Time
.Through Put
Quelques paramètres à vérifier Etat des serveurs/applications.
-> Tandis que le test de contrainte teste l'application pour une charge inattendue. Il comprend
.Vusers
.Think-Time
Exemple:
Si une application est conçue pour 500 utilisateurs, nous testons jusqu'à 500 utilisateurs pour les tests de charge, et plus de 500 pour les tests de contrainte.
Test de charge = mettre une charge spécifique sur le serveur pendant un certain temps. 100 utilisateurs simultanés pendant 10 minutes. Assurer la stabilité du logiciel . Tests de résistance = augmentation constante de la charge jusqu'à ce que le logiciel plante. 10 utilisateurs simultanés augmentant toutes les 2 minutes jusqu'à ce que le serveur se bloque.
Pour faire une comparaison avec la musculation: Vous "max" votre poids pour voir ce que vous pouvez faire pendant 1 répétition (test de résistance), puis effectuez des séances d'entraînement régulières à 85% de votre valeur maximale pour 3 séries de 10 répétitions (test de charge)
Test de charge: - Le test de charge a pour but de tester le système en augmentant constamment la charge sur le système jusqu'au moment où il atteint la limite de seuil.
Stress Testing: - Dans le cadre de tests de stress, diverses activités visant à surcharger les ressources existantes avec des tâches en excès sont effectuées dans le but de décomposer le système.
La différence fondamentale est comme sous
Test de charge: Grand nombre d'utilisateurs Stress Testing: Trop d'utilisateurs, trop de données, trop peu de temps et pas assez de place