Types de tests logiciels
Tests unitaires
Les tests unitaires sont des tests effectués sur une fonction, une classe ou un module individuel indépendamment que de tester un logiciel entièrement fonctionnel. À l'aide d'un framework pour les tests unitaires, le programmeur peut créer des cas de test avec une entrée et une sortie attendue. Lorsque vous avez des centaines, des milliers ou des dizaines de milliers de cas de test unitaire pour un grand projet logiciel garantit que toutes les unités individuelles fonctionnent comme prévu alors que vous continuez à modifier le code. Lorsque vous modifiez une unité qui a des cas de test, les cas de test pour ce module doivent être étudiés et déterminer si de nouveaux cas de test sont nécessaires, que la sortie a changé ou si les cas de test actuels peuvent être supprimés comme n'étant plus pertinents. La création d'un grand volume de tests unitaires est le moyen le plus simple d'obtenir une couverture de cas de test élevée pour une base de code logiciel, mais ne garantira pas que le produit final fonctionne comme un système comme prévu.
Test fonctionel
Les tests fonctionnels sont la forme de test la plus courante. Lorsque les gens se réfèrent aux tests de logiciels sans beaucoup de détails, ils signifient souvent des tests fonctionnels. Les tests fonctionnels vérifieront les fonctions principales du travail logiciel comme prévu. Un plan de test pourrait être écrit pour décrire tous les cas de test fonctionnels qui seront testés, ce qui correspond aux principales caractéristiques et capacités du logiciel. Les tests de fonctionnalité primaire seront «Happy Path » Test, qui n'essaie pas de casser le logiciel ou de l'utiliser dans des scénarios difficiles. Cela devrait être le strict absolu de tests pour tout projet logiciel.
Tests d'intégration
Après les tests unitaires et les tests fonctionnels, il peut y avoir plusieurs modules ou le système entier qui n'a pas encore été testé dans son ensemble. Ou il peut y avoir des composants largement indépendants mais parfois utilisés ensemble. Chaque fois que les composants ou modules sont testés indépendamment mais pas en tant que système entier, les tests d'intégration doivent être effectués pour valider la fonction des composants ensemble comme un système de travail en fonction des exigences et des attentes des utilisateurs.
Tests de stress
Pensez aux tests de stress comme vous testez une navette spatiale ou un avion. Que signifie mettre votre logiciel ou système sous «stress»? La contrainte n'est rien d'autre qu'une charge intense d'un type spécifique qui est le plus susceptible de briser votre système. Cela pourrait être similaire aux «tests de charge» dans le sens de mettre votre système à haute concurrence avec de nombreux utilisateurs qui accédaient au système. Mais le stress d'un système pourrait également se produire sur d'autres vecteurs. Par exemple, l'exécution du firmware sur un composant matériel lorsque le matériel a été détérioré physique et fonctionne en mode dégradé. Le stress est unique à tous les types de logiciels, et les systèmes et la conception de tests de stress devraient être à l'étude de ce que les causes naturelles ou non naturelles sont les plus susceptibles de souligner votre logiciel ou votre système.
Tests de charge
Le test de charge est un type spécifique de tests de contrainte, comme indiqué ci-dessus, dans lequel un grand nombre de connexions et d'accès utilisateurs simultanés sont automatisés pour générer la simulation de l'effet d'un grand nombre d'utilisateurs authentiques accédant à votre système logiciel en même temps en même temps. L'objectif est de savoir combien d'utilisateurs peuvent accéder à votre système en même temps sans la rupture de votre système logiciel. Si votre système peut facilement gérer un trafic normal de 10 000 utilisateurs, ce qui se passera si votre site Web ou votre logiciel devient viral et obtient 1 million d'utilisateurs? Est-ce que cette inattendue "CHARGER" Brisez votre site Web ou votre système? Les tests de charge simulent cela, vous êtes donc à l'aise avec l'augmentation future des utilisateurs car vous savez que votre système peut gérer l'augmentation de la charge.
Test de performance
Les gens peuvent devenir complètement frustrés et désespérés lorsque le logiciel ne répond pas à leurs exigences de performance. La performance, généralement, signifie à quelle vitesse les fonctions importantes peuvent être remplies. Plus les fonctions sont complexes et dynamiques disponibles dans un système, plus elle devient importante et non évidente pour tester ses performances, prenons un exemple de base, Windows ou Linux Système d'exploitation. Un système d'exploitation est un produit logiciel très complexe, et effectuer des tests de performances sur son système pourrait impliquer la vitesse et le calendrier des fonctions telles que le démarrage, l'installation d'une application, la recherche d'un fichier, l'exécution de calculs sur un GPU et / ou tout autre de les millions d'actions qui peuvent être effectuées. Des précautions doivent être prises lors de la sélection des cas de test de performance, pour garantir les fonctions de performance importantes et susceptibles testées.
Tests d'évolutivité
Tester sur votre ordinateur portable est bon, mais pas vraiment bon lorsque vous construisez un réseau social, un système de messagerie ou un logiciel de supercalculateur. Lorsque votre logiciel doit être déployé sur 1000 serveurs, tous fonctionnant à l'unisson, puis les tests que vous effectuez localement sur un système ne découvriront pas les bogues qui se produisent lorsque le logiciel est déployé «à grande échelle» sur des centaines de milliers de cas. En réalité, vos tests ne seront probablement jamais en mesure de fonctionner à grande échelle avant de remettre à la production, car il serait beaucoup trop cher et pas pratique de construire un système de test avec 1000 serveurs qui coûtent des millions de dollars. Par conséquent, les tests d'évolutivité se font sur plusieurs serveurs, mais généralement pas le nombre complet de serveurs de production pour essayer de découvrir certains des défauts qui pourraient être trouvés car vos systèmes sont utilisés sur une infrastructure plus grande.
Test d'analyse statique
L'analyse statique est un test qui est effectué en inspectant le code logiciel sans l'exécuter réellement. Pour faire une analyse statique, généralement, vous utiliseriez un outil, il y a beaucoup, un outil célèbre est la couverture. L'analyse statique est facile à exécuter avant de publier votre logiciel et peut trouver de nombreux problèmes de qualité dans votre code qui peuvent être corrigées avant de publier. Les erreurs de mémoire, les erreurs de traitement des types de données, les déréférences du pointeur nul, les variables non initialisées et de nombreux autres défauts peuvent être trouvés. Des langages comme C et C ++ bénéficient considérablement d'une analyse statique car les langues offrent une grande liberté aux programmeurs en échange d'une grande puissance, mais cela peut également créer de grands bugs et erreurs qui peuvent être trouvés en utilisant des tests d'analyse statique.
Test d'injection de défaut
Certaines conditions d'erreur sont très difficiles à simuler ou à déclencher, par conséquent, le logiciel peut être conçu pour injecter artificiellement un problème ou un défaut dans le système sans le défaut naturel. Le but des tests d'injection de défauts est de voir comment le logiciel gère ces défauts inattendus. Cela répond-il gracieusement à la situation, est-ce qu'il s'écrase ou produit-il des résultats problématiques inattendus et imprévisibles? Par exemple, disons que nous avons un système bancaire, et il y a un module pour transférer des fonds en interne du compte A au compte B. Cependant, cette opération de transfert n'est appelée qu'après que le système a déjà vérifié que ces comptes existaient avant d'appeler l'opération de transfert. Même si nous supposons que les deux comptes existent, l'opération de transfert a un cas de défaillance où une cible ou un compte source n'existe pas et qu'il peut lancer une erreur. Parce que dans des circonstances normales, nous n'obtenons jamais cette erreur en raison de la pré-test des entrées, donc pour vérifier le comportement du système lorsque le transfert échoue en raison d'un compte inexistant, nous injectons une fausse erreur dans le système qui renvoie un compte inexistant pour un transfert et tester comment le reste du système répond dans ce cas. Il est très important que le code d'injection de défauts ne soit disponible que dans les scénarios de test et non publié en production, où il pourrait créer des ravages.
Test de dépassement de mémoire
Lorsque vous utilisez des langages comme C ou C ++, le programmeur a une grande responsabilité d'aborder directement la mémoire, ce qui peut provoquer des bogues mortels dans les logiciels si des erreurs sont commises. Par exemple, si un pointeur est nul et déréférencé, le logiciel se bloquera. Si la mémoire est allouée à un objet, puis une chaîne est copiée sur l'espace mémoire de l'objet, la référence à l'objet peut provoquer un crash ou même un mauvais comportement non spécifié. Par conséquent, il est essentiel d'utiliser un outil pour essayer d'attraper des erreurs d'accès à la mémoire dans des logiciels qui utilisent des langages comme C ou C ++, ce qui pourrait avoir ces problèmes potentiels. Les outils qui peuvent effectuer ce type de test comprennent la valgrind open source ou les outils propriétaires comme PurifyPlus. Ces outils peuvent sauver le jour où il n'est pas clair pourquoi le logiciel se bloque ou se comporte mal et pointe directement vers l'emplacement dans le code qui a le bogue. Génial, droit?
Test de cas aux limites
Il est facile de faire des erreurs de codage lorsque vous êtes sur ce qu'on appelle une limite. Par exemple, une machine à dire automatisée bancaire dit que vous pouvez retirer un maximum de 300 $. Alors, imaginez que le codeur a écrit le code suivant naturellement lors de la construction de cette exigence:
Si (amt < 300)
startWithDrawl ()
autre
erreur («vous pouvez retirer% s», amt);
Pouvez-vous repérer l'erreur? L'utilisateur qui essaie de retirer 300 $ recevra une erreur car elle ne coûte pas moins de 300 $. C'est un bug. Par conséquent, les tests limites sont effectués naturellement. Les limites des exigences garantissent alors que des deux côtés de la frontière et de la frontière, le logiciel fonctionne correctement.
Tests de fuzz
La génération à grande vitesse de saisie du logiciel peut produire autant de combinaisons d'entrée possibles, même si ces combinaisons d'entrée sont totales et ne seraient jamais fournies par un véritable utilisateur. Ce type de test de fuzz peut trouver des bogues et des vulnérabilités de sécurité non trouvés par d'autres moyens en raison du volume élevé d'intrants et de scénarios testés rapidement sans génération de cas de test manuel.
Tests exploratoires
Fermez les yeux et visualisez ce que signifie le mot «explorer». Vous observez et sondez un système afin de savoir comment il fonctionne vraiment. Imaginez que vous recevez une nouvelle chaise de bureau par correspondance, et il a 28 pièces dans des sacs en plastique séparés sans instructions. Vous devez explorer votre nouvelle arrivée pour comprendre comment elle fonctionne et comment elle est assemblée. Avec cet esprit, vous pouvez devenir un testeur exploratoire. Vous n'aurez pas de plan de test bien défini des cas de test. Vous explorerez et sonderez votre logiciel à la recherche de choses qui vous font dire le merveilleux mot: «Intéressant!". Lors de l'apprentissage, vous sondez plus loin et trouvez des moyens de briser le logiciel auquel les concepteurs n'ont jamais pensé, puis de livrer un rapport qui détaille de nombreuses mauvaises hypothèses, défauts et risques dans le logiciel. En savoir plus à ce sujet dans le livre intitulé Explore It.
Tests de pénétration
Dans le monde de la sécurité des logiciels, les tests de pénétration sont l'un des principaux moyens de test. Tous les systèmes, qu'ils soient biologiques, physiques ou logiciels ont des frontières et des limites. Ces limites sont destinées à permettre uniquement aux messages, des personnes ou des composants spécifiques pour entrer le système. Plus concrètement, considérons un système bancaire en ligne qui utilise l'authentification des utilisateurs pour entrer le site. Si le site peut être piraté et entré dans le backend sans authentification appropriée, ce serait une pénétration, qui doit être protégée contre. L'objectif des tests de pénétration est d'utiliser des techniques connues et expérimentales pour contourner la limite de sécurité normale d'un système ou d'un site Web logiciel. Les tests de pénétration impliquent souvent de vérifier tous les ports qui écoutent et essaient de saisir un système via un port ouvert. Les autres techniques courantes incluent l'injection SQL ou la fissuration du mot de passe.
Les tests de régression
Une fois que vous avez un logiciel de travail déployé dans le domaine, il est essentiel d'empêcher l'introduction de bogues dans des fonctionnalités qui fonctionnaient déjà. Le développement de logiciels est d'augmenter la capacité de votre produit, d'introduire des bogues ou de provoquer la fin de fonctionnalité, ce qui est appelé une régression. La régression est un bogue ou un défaut qui a été introduit lorsque, auparavant, la capacité fonctionnait comme prévu. Rien ne peut ruiner la réputation de votre logiciel ou de votre marque plus rapidement que d'introduire des bogues de régression dans votre logiciel et d'avoir de vrais utilisateurs à trouver ces bogues après une version.
Les cas de test de régression et les plans de test doivent être construits autour des fonctionnalités de base qui doivent continuer à travailler pour garantir que les utilisateurs ont une bonne expérience avec votre application. Toutes les fonctions principales de votre logiciel que les utilisateurs s'attendent à travailler d'une certaine manière devraient avoir un cas de test de régression qui peut être exécuté pour empêcher que les fonctionnalités ne se brisent d'une nouvelle version. Cela pourrait être de 50 à 50 000 cas de test qui couvrent les fonctionnalités de base de votre logiciel ou application.
Test de bissection du code source
Un bogue a été introduit dans le logiciel, mais il n'est pas évident quelle version de la version a introduit le nouveau bogue. Imaginez qu'il y avait 50 engagements de logiciels de la dernière fois que le logiciel fonctionnait sans le bogue, jusqu'à présent quand…
Tests de localisation
Imaginez une application météo qui montre le temps actuel et projeté dans votre emplacement, ainsi qu'une description des conditions météorologiques. La première partie des tests de localisation consiste à s'assurer que la langue, l'alphabet et les caractères corrects sont affichés correctement, selon la géolocalisation de l'utilisateur. L'application au Royaume-Uni doit être affichée en anglais avec des personnages latins; La même application en Chine doit être affichée en caractères chinois en langue chinoise. Des tests de localisation plus élaborés effectués, la gamme plus large de personnes de différentes géolocations interfacera avec l'application.
Test d'accessibilité
Certains des citoyens de notre communauté ont un handicap et peuvent donc avoir du mal à utiliser le logiciel créé, de sorte que les tests d'accessibilité sont effectués pour garantir que les populations handicapées peuvent toujours accéder aux fonctionnalités du système. Par exemple, si nous supposons que 1% de la population est aveugle et notre interface logicielle suppose que les utilisateurs peuvent faire la distinction entre le rouge et le vert, mais ces individus aveugles ne peuvent pas faire la différence. Par conséquent, une interface bien-douce aura des indices supplémentaires au-delà de la couleur pour indiquer un sens. D'autres scénarios en plus des tests de cécité des couleurs seraient également inclus dans les tests d'accessibilité des logiciels, tels que la cécité visuelle complète, la surdité et de nombreux autres scénarios. Un bon produit logiciel doit être accessible par un pourcentage maximum d'utilisateurs potentiels.
Test de mise à niveau
Des applications simples sur un téléphone, des systèmes d'exploitation comme Ubuntu, Windows ou Linux Mint, et les logiciels qui exécutent des sous-marins nucléaires ont besoin de mises à niveau fréquentes. Le processus de la mise à niveau lui-même pourrait introduire des bogues et des défauts qui n'existeraient pas sur une nouvelle installation parce que l'état de l'environnement était différent et le processus d'introduction du nouveau logiciel au-dessus de l'ancien aurait pu introduire des bogues. Prenons un exemple simple, nous avons un ordinateur portable exécutant Ubuntu 18.04, et nous voulons passer à Ubuntu 20.04. Il s'agit d'un processus différent d'installation du système d'exploitation que de nettoyer directement le disque dur et d'installer Ubuntu 20.04. Par conséquent, une fois le logiciel installé ou l'une de ses fonctions dérivées, elle pourrait ne pas fonctionner à 100% comme prévu ou la même chose que lorsque le logiciel a été fraîchement installé. Nous devrions donc d'abord envisager de tester la mise à niveau elle-même dans de nombreux cas et scénarios différents pour garantir que la mise à niveau fonctionne à l'achèvement. Et puis, nous devons également envisager de tester la mise à niveau réelle du Système pour nous assurer que le logiciel a été établi et fonctionne comme prévu. Nous ne répétions pas tous les cas de test d'un système fraîchement installé, ce qui serait une perte de temps, mais nous réfléchirons attentivement à notre connaissance du système de ce qui pourrait se casser pendant une mise à niveau et ajouter stratégiquement les cas de test pour ces fonctions.
Test de boîte noire et de boîte blanche
La boîte noire et la boîte blanche sont des méthodologies de test moins spécifiques et plus de catégorisations types de test. Essentiellement, des tests de boîte noire, qui suppose que le testeur ne sait rien du fonctionnement interne du logiciel et construit un plan de test et des cas de test qui regardent simplement le système de l'extérieur pour vérifier sa fonction. Les tests de boîte blanche sont effectués par des architectes de logiciels qui comprennent le fonctionnement interne d'un système logiciel et conçoivent les cas avec une connaissance de ce qui pourrait, devrait, devrait, devrait et être susceptible de se casser. Les tests de boîte en noir et blanc sont susceptibles de trouver différents types de défauts.
Blogs et articles sur les tests de logiciels
Les tests de logiciels sont un domaine dynamique, et de nombreuses publications et articles intéressants qui mettent à jour la communauté sur la réflexion à la pointe de la technologie. Nous pouvons tous bénéficier de ces connaissances. Voici un échantillon d'articles intéressants de différentes sources de blog que vous voudrez peut-être suivre:
- 7 conseils à suivre avant les tests sans exigences; http: // www.TestingJournals.com /
- 60 meilleurs outils de test d'automatisation: le guide de liste ultime; https: // testguild.com /
- Outils de test de base de données open source; https: // www.softwaretestingmagazine.com /
- La couverture des tests unitaires à 100% ne suffit pas; https: // www.stickyminds.com /
- Tests feuilletés chez Google et comment nous les atténuons; https: // test.googleblog.com /
- Qu'est-ce que les tests de régression? ; https: // tester.io / blog /
- 5 étapes de test de logiciels clés que chaque ingénieur doit effectuer; https: // Techbeacon.com /
Produits pour les tests de logiciels
La majorité des tâches de test précieuses peuvent être automatisées, il n'est donc pas surprenant que l'utilisation d'outils et de produits pour effectuer la myriade de tâches d'assurance qualité logicielle soit une bonne idée. Ci-dessous, nous énumérons certains outils logiciels importants et très précieux pour les tests logiciels que vous pouvez explorer et voir s'ils peuvent aider.
Junite
Pour tester les logiciels basés sur Java, Junit fournit une suite de test complète pour les tests unitaires et fonctionnels du code qui est convivial avec l'environnement Java.
Sélénium
Pour tester les applications Web, Selenium offre la possibilité d'automatiser les interactions avec les navigateurs Web, y compris les tests de compatibilité entre les navigateurs. Il s'agit d'une infrastructure de test de premier plan pour l'automatisation des tests Web.
Concombre
Un cadre de test axé sur le comportement permet aux utilisateurs professionnels, aux chefs de produit et aux développeurs d'expliquer les fonctionnalités attendues en langage naturel, puis de définir ce comportement dans les cas de test. Cela rend les cas de test plus lisibles et la cartographie claire des fonctionnalités de l'utilisateur attendues.
Purifier
Trouver des fuites de mémoire et des corruptions de mémoire au moment de l'exécution en exécutant votre logiciel avec l'instrumentation Purify Plus intégrée qui suit votre utilisation de la mémoire et souligne les erreurs dans votre code qui ne sont pas faciles à trouver sans instrumentation.
Valgrine
Outils open source qui exécuteront votre logiciel et vous permettra d'interagir avec lui tout en soulignant un rapport d'erreur d'erreurs de codage telles que les fuites de mémoire et les corruptions. Pas besoin de recompiler ou d'ajouter de l'instrumentation dans le processus de compilation car Valgrind a l'intelligence pour comprendre dynamiquement votre code machine et injecter une instrumentation de manière transparente pour trouver des erreurs de codage et vous aider à améliorer votre code.
Couverture
Outil d'analyse statique qui trouvera des erreurs de codage dans votre logiciel avant même de compiler et d'exécuter votre code. La couverture peut trouver des vulnérabilités de sécurité, des violations des conventions de codage, ainsi que des bogues et des défauts que votre compilateur ne trouvera pas. Le code mort peut être trouvé, des variables non initialisées et des milliers d'autres types de défauts. Il est essentiel de nettoyer votre code avec une analyse statique avant de la remettre à la production.
Jmètre
Un cadre open source pour les tests de performance orientés vers les développeurs basés sur Java, d'où le j dans le nom. Les tests de site Web sont l'un des principaux cas d'utilisation pour JMeter en plus des tests de performances des bases de données, des systèmes de messagerie et de nombreuses autres applications de serveur.
Métasploit
Pour les tests de sécurité et de pénétration, Metasploit est un cadre générique avec des milliers de fonctionnalités et de capacités. Utilisez la console d'interaction pour accéder aux exploits pré-codés et essayez de vérifier la sécurité de votre application.
Recherche académique sur les tests de logiciels
- Groupe de recherche des tests de l'Université de Sheffield
- Laboratoire de vérification et de validation des logiciels de l'Université du Kentucky
- North Dakota State University Software Testing Research Group
- Test de système Intelligent Lab; Université technique tchèque Prague
- NASA: Jon McBride Software Testing and Research (JSTAR)
- Université McMaster; Laboratoire de recherche sur la qualité du logiciel
- Université de l'Ontario Tech; Laboratoire de recherche sur la qualité du logiciel
- L'Université du Texas @ Dallas; STQA
Conclusion
Le rôle du logiciel dans la société continue de croître, et en même temps, le logiciel mondial devient plus complexe. Pour que le monde fonctionne, nous devons avoir des méthodes et des stratégies pour tester et valider le logiciel que nous créons en effectuant les fonctions qu'elle est destinées à effectuer. Pour chaque système logiciel complexe, une stratégie de test et un plan de test doivent être en place pour continuer à valider la fonctionnalité du logiciel alors qu'ils continuent de s'améliorer et de fournir sa fonction.