Phenquestions
Tests unitaires
Les tests unitaires sont des tests effectués sur une fonction, une classe ou un module individuel indépendamment du test d'un logiciel entièrement fonctionnel. En utilisant un cadre pour les tests unitaires, le programmeur peut créer des cas de test avec entrée et sortie attendue. Lorsque vous avez des centaines, des milliers ou des dizaines de milliers de cas de test unitaires pour un grand projet logiciel, assurez-vous que toutes les unités individuelles fonctionnent comme prévu alors que vous continuez à modifier le code. Lors de la modification d'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, la sortie a changé ou les cas de test actuels peuvent être supprimés car ils ne sont 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 garantit 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 logiciels sans trop de détails, ils signifient souvent des tests fonctionnels. Les tests fonctionnels vérifieront les fonctions principales du logiciel comme prévu. Un plan de test pourrait être rédigé pour décrire tous les cas de test fonctionnels qui seront testés, ce qui correspond aux principales fonctionnalités et capacités du logiciel. Les tests de fonctionnalité principale seront "chemin heureux" test, qui n'essaie pas de casser le logiciel ou de l'utiliser dans des scénarios difficiles. Cela devrait être le strict minimum absolu de tests pour tout projet logiciel.
Test d'intégration
Après les tests unitaires et les tests fonctionnels, il peut y avoir plusieurs modules ou l'ensemble du système qui n'a pas encore été testé dans son ensemble. Ou il peut y avoir des composants qui sont largement indépendants mais parfois utilisés ensemble. Chaque fois que des composants ou des modules sont testés indépendamment mais pas comme un système dans son ensemble, des tests d'intégration doivent être effectués pour valider que les composants fonctionnent ensemble en tant que système de travail selon les exigences et les attentes des utilisateurs.
Tests de résistance
Pensez aux tests de stress comme si vous testiez une navette spatiale ou un avion. Que signifie mettre votre logiciel ou système sous « STRESS »? Le stress n'est rien de plus qu'une charge intense d'un type spécifique qui est le plus susceptible de briser votre système. Cela pourrait être similaire au « test de charge » dans le sens où vous placez votre système sous haute concurrence avec de nombreux utilisateurs accédant au système. Mais stresser un système peut également se produire sur d'autres vecteurs. Par exemple, exécuter un micrologiciel sur un composant matériel lorsque le matériel a subi une détérioration physique et fonctionne en mode dégradé. Le stress est unique à tous les types de logiciels, et les systèmes et la conception des tests de résistance doivent tenir compte des causes naturelles ou non naturelles qui sont les plus susceptibles de stresser votre logiciel ou système.
Test de charge
Le test de charge est un type spécifique de test de résistance, comme indiqué ci-dessus, dans lequel un grand nombre de connexions et d'accès d'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. L'objectif est de savoir combien d'utilisateurs peuvent accéder à votre système en même temps sans que votre système logiciel ne casse. Si votre système peut facilement gérer un trafic normal de 10 000 utilisateurs, que se passera-t-il si votre site Web ou votre logiciel devient viral et obtient 1 million d'utilisateurs? Est-ce que cet inattendu "CHARGE" casser votre site Web ou votre système? Les tests de charge simuleront cela, vous êtes donc à l'aise avec l'augmentation future du nombre d'utilisateurs car vous savez que votre système peut gérer l'augmentation de la charge.
Test de performance
Les gens peuvent devenir totalement frustrés et désespérés lorsque le logiciel ne répond pas à leurs exigences de performance. La performance, en général, signifie la rapidité avec laquelle les fonctions importantes peuvent être exécutées. Plus les fonctions disponibles dans un système sont complexes et dynamiques, plus il devient important et non évident de tester ses performances, prenons un exemple basique, système d'exploitation Windows ou Linux. Un système d'exploitation est un produit logiciel très complexe, et effectuer des tests de performances sur son système peut impliquer la vitesse et la synchronisation de 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 les millions d'actions réalisables. Des précautions doivent être prises lors de la sélection des cas de test de performance, pour garantir les caractéristiques de performance importantes et susceptibles de dysfonctionnement.
Tests d'évolutivité
Les tests sur votre ordinateur portable sont bons, mais pas vraiment suffisants lorsque vous créez un réseau social, un système de messagerie ou un logiciel de superordinateur. Lorsque votre logiciel est destiné à être déployé sur 1 000 serveurs, fonctionnant tous à l'unisson, 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 d'instances. En réalité, vos tests ne pourront probablement jamais être exécutés à grande échelle avant de passer en production, car il serait beaucoup trop coûteux et peu pratique de créer un système de test avec 1 000 serveurs coûtant des millions de dollars. Par conséquent, les tests d'évolutivité sont effectués sur plusieurs serveurs, mais généralement pas sur le nombre total de serveurs de production pour essayer de découvrir certains des défauts qui pourraient être détectés lorsque vos systèmes sont utilisés sur une infrastructure plus importante.
Test d'analyse statique
L'analyse statique est un test effectué en inspectant le code du logiciel sans l'exécuter réellement. Pour faire une analyse statique, généralement, vous utiliseriez un outil, il y en a beaucoup, un outil célèbre est Coverity. 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 résolus avant la publication. Des erreurs de mémoire, des erreurs de gestion de type de données, des déréférencements de pointeur nul, des variables non initialisées et bien d'autres défauts peuvent être trouvés. Les langages comme C et C++ bénéficient grandement de l'analyse statique car les langages offrent une grande liberté aux programmeurs en échange d'une grande puissance, mais cela peut également créer de grands bogues et erreurs qui peuvent être trouvés en utilisant les 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 que le défaut ne se produise naturellement. Le but des tests d'injection de fautes est de voir comment le logiciel gère ces fautes inattendues. Répond-il gracieusement à la situation, se bloque-t-il ou produit-il des résultats problématiques inattendus et imprévisibles? Par exemple, disons que nous avons un système bancaire et qu'il existe un module pour transférer des fonds en interne du COMPTE A vers le 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 d'échec où un compte cible ou source n'existe pas, et qu'il peut générer une erreur. Parce que dans des circonstances normales, nous n'obtenons jamais cette erreur en raison du 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éagit dans ce cas. Il est très important que le code d'injection de panne ne soit disponible que dans les scénarios de test et ne soit pas mis en production, où il pourrait faire des ravages.
Test de dépassement de mémoire
Lors de l'utilisation de langages comme C ou C++, le programmeur a la grande responsabilité d'adresser directement la mémoire, ce qui peut provoquer des bogues fatals dans le logiciel si des erreurs sont commises. Par exemple, si un pointeur est nul et déréférencé, le logiciel plantera. Si de la mémoire est allouée à un objet et qu'une chaîne est copiée sur l'espace mémoire de l'objet, le référencement de l'objet peut provoquer un plantage ou même un mauvais comportement non spécifié. Par conséquent, il est essentiel d'utiliser un outil pour essayer de détecter les erreurs d'accès à la mémoire dans les logiciels utilisant des langages tels que C ou C++, qui pourraient présenter ces problèmes potentiels. Les outils pouvant effectuer ce type de test incluent Open Source Valgrind ou des outils propriétaires tels que PurifyPlus. Ces outils peuvent sauver la journée lorsqu'il n'est pas clair pourquoi le logiciel se bloque ou se comporte mal et pointent directement vers l'emplacement dans le code qui a le bogue. Génial, d'accord?
Test de cas limite
Il est facile de faire des erreurs de codage quand on est sur ce qu'on appelle une frontière. Par exemple, un guichet automatique bancaire dit que vous pouvez retirer un maximum de 300 $. Alors, imaginez que le codeur a écrit le code suivant naturellement lors de la création de cette exigence :
Si (amt < 300)startRetrait()
autre
error("Vous pouvez retirer %s", amt);
Pouvez-vous repérer l'erreur? L'utilisateur qui essaie de retirer 300 $ recevra une erreur car ce n'est pas moins de 300 $. C'est un bug. Par conséquent, les tests aux limites se font naturellement. Les limites d'exigence s'assurent ensuite que des deux côtés de la limite et de la limite, le logiciel fonctionne correctement.
Test de duvet
La génération à grande vitesse d'entrées dans le logiciel peut produire autant de combinaisons d'entrées possibles, même si ces combinaisons d'entrées sont totalement absurdes et ne seraient jamais fournies par un utilisateur réel. Ce type de test 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'entrées et de scénarios testés rapidement sans génération manuelle de cas de test.
Tests exploratoires
Fermez les yeux et visualisez ce que signifie le mot « Explorer ». Vous observez et sondez un système afin de découvrir comment il fonctionne réellement. Imaginez que vous recevez une nouvelle chaise de bureau par correspondance et qu'elle contient 28 pièces, toutes dans des sacs en plastique séparés sans instructions. Vous devez explorer votre nouveau venu pour comprendre comment il fonctionne et comment il est composé. Avec cet esprit, vous pouvez devenir un testeur exploratoire. Vous n'aurez pas un 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 mot merveilleux : « INTERESSANT!". Après avoir appris, vous approfondissez et trouvez des moyens de casser le logiciel auxquels les concepteurs n'ont jamais pensé, puis fournissez un rapport qui détaille de nombreuses mauvaises hypothèses, défauts et risques dans le logiciel. Apprenez-en plus à ce sujet dans le livre intitulé Explore It.
Tests de pénétration
Dans le monde de la sécurité logicielle, les tests d'intrusion sont l'un des principaux moyens de tester. Tous les systèmes, qu'ils soient biologiques, physiques ou logiciels ont des frontières et des limites. Ces limites sont destinées à autoriser uniquement des messages, des personnes ou des composants spécifiques à entrer dans le système. Plus concrètement, considérons un système bancaire en ligne qui utilise l'authentification de l'utilisateur pour entrer sur 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 d'intrusion est d'utiliser des techniques connues et expérimentales pour contourner la limite de sécurité normale d'un système logiciel ou d'un site Web. Les tests de pénétration impliquent souvent de vérifier tous les ports qui écoutent et tentent d'entrer dans un système via un port ouvert. D'autres techniques courantes incluent l'injection SQL ou le craquage de mot de passe.
Les tests de régression
Une fois que vous disposez d'un logiciel fonctionnel déployé sur le terrain, il est essentiel d'éviter d'introduire des bogues dans des fonctionnalités qui fonctionnaient déjà. L'objectif du développement logiciel est d'augmenter la capacité de votre produit, d'introduire des bogues ou d'empêcher l'ancienne fonctionnalité de fonctionner, ce qu'on appelle une RÉGRESSION. La régression est un bogue ou un défaut qui a été introduit alors qu'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 que de vrais utilisateurs trouvent ces bogues après une version.
Les cas de tests de régression et les plans de test doivent être construits autour de la fonctionnalité de base qui doit continuer à fonctionner pour garantir que les utilisateurs ont une bonne expérience avec votre application. Toutes les fonctions de base de votre logiciel que les utilisateurs s'attendent à ce qu'elles fonctionnent d'une certaine manière doivent avoir un cas de test de régression qui peut être exécuté pour empêcher la fonctionnalité de s'arrêter sur une nouvelle version. Cela peut aller 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 de savoir quelle version de la version a introduit le nouveau bogue. Imaginez qu'il y ait eu 50 commits de logiciels depuis la dernière fois où le logiciel fonctionnait sans le bogue, jusqu'à maintenant quand…
Tests de localisation
Imaginez une application météo qui montre la météo actuelle et projetée 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, en fonction de la géolocalisation de l'utilisateur. L'application au Royaume-Uni doit être affichée en anglais avec des caractères latins ; la même application en Chine doit être affichée en caractères chinois dans la langue chinoise. Des tests de localisation plus élaborés effectués, le plus large éventail de personnes de différentes géolocalisations s'interfacera avec l'application.
Test d'accessibilité
Certains citoyens de notre communauté sont handicapés et peuvent donc avoir des difficultés à utiliser le logiciel en cours de création. Des tests d'accessibilité sont donc effectués pour s'assurer 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 daltonien et que notre interface logicielle suppose que les utilisateurs peuvent distinguer le rouge du vert mais que ces individus daltoniens NE PEUVENT PAS faire la différence. Par conséquent, une interface bien logicielle aura des indices supplémentaires au-delà de la couleur pour indiquer la signification. D'autres scénarios que les tests de daltonisme 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 à 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 des logiciels qui exécutent des sous-marins nucléaires nécessitent des mises à niveau fréquentes. Le processus de mise à niveau lui-même pourrait introduire des bogues et des défauts qui n'existeraient pas sur une nouvelle installation car l'état de l'environnement était différent et le processus d'introduction du nouveau logiciel en plus de l'ancien aurait pu introduire des bogues. Prenons un exemple simple, nous avons un ordinateur portable sous 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 le nettoyage direct du disque dur et l'installation d'Ubuntu 20.04. Par conséquent, une fois le logiciel installé ou l'une de ses fonctions dérivées, il se peut qu'il ne fonctionne pas à 100% comme prévu ou de la même manière que lorsque le logiciel a été fraîchement installé. Nous devons donc d'abord envisager de tester la mise à niveau elle-même dans de nombreux cas et scénarios différents pour nous assurer que la mise à niveau fonctionne jusqu'à son terme. Et puis, nous devons également envisager de tester le système réel après la mise à niveau pour nous assurer que le logiciel a été défini et fonctionne comme prévu. Nous ne répéterions 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 soigneusement avec notre connaissance du système à ce qui POURRAIT casser lors d'une mise à niveau et ajouter stratégiquement des cas de test pour ces fonctions.
Test de la boîte noire et de la boîte blanche
La boîte noire et la boîte blanche sont des méthodologies de test moins spécifiques et davantage de types de catégorisations de tests. Essentiellement, des tests en boîte noire, qui supposent que le testeur ne sait rien du fonctionnement interne du logiciel et construit un plan de test et des cas de test qui ne font que regarder le système de l'extérieur pour vérifier sa fonction. Les tests en boîte blanche sont effectués par des architectes logiciels qui comprennent le fonctionnement interne d'un système logiciel et conçoivent les cas en sachant ce qui pourrait, devrait, devrait et serait susceptible de casser. Les tests en boîte noire et en boîte blanche sont susceptibles de trouver différents types de défauts.
Blogs et articles sur les tests de logiciels
Les tests logiciels sont un domaine dynamique, et de nombreuses publications et articles intéressants qui mettent à jour la communauté sur la réflexion de pointe sur les tests logiciels. Nous pouvons tous bénéficier de cette connaissance. Voici un échantillon d'articles intéressants provenant de différentes sources de blogs que vous voudrez peut-être suivre :
- 7 conseils à suivre avant de tester sans exigences ; http://www.revues de test.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.magazine de test de logiciels.com/
- Une couverture de test unitaire à 100 % n'est pas suffisante ; https://www.les esprits collants.com/
- Tests floconneux chez Google et comment nous les atténuons ; https://test.googleblog.com/
- Qu'est-ce que les tests de régression? ; https://test.io/blog/
- 27 meilleures extensions Chrome pour les développeurs en 2020; https://www.lambdate.com/
- 5 étapes de test logiciel clés que chaque ingénieur doit effectuer ; https://techbeacon.com/
Produits pour les tests de logiciels
La majorité des tâches de test utiles 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érerons quelques outils logiciels importants et très précieux pour les tests logiciels que vous pouvez explorer et voir s'ils peuvent vous aider.
JUnité
Pour tester les logiciels basés sur Java, JUnit fournit une suite de tests complète pour les tests unitaires et fonctionnels du code qui est convivial pour 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 navigateurs. Il s'agit d'une infrastructure de test de premier ordre 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 des cas de test. Cela rend les cas de test plus lisibles et un mappage clair avec les fonctionnalités utilisateur attendues.
Purifier
Trouvez les fuites de mémoire et les 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 signale les erreurs dans votre code qui ne sont pas faciles à trouver sans instrumentation.
Valgrind
Des outils open source qui exécuteront votre logiciel et vous permettront d'interagir avec lui tout en signalant un rapport d'erreur d'erreurs de codage telles que des fuites de mémoire et des 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 l'instrumentation de manière transparente pour trouver les erreurs de codage et vous aider à améliorer votre code.
Couverture
Outil d'analyse statique qui trouvera les erreurs de codage dans votre logiciel avant même de compiler et d'exécuter votre code. Coverity peut trouver des failles de sécurité, des violations des conventions de codage, ainsi que des bogues et des défauts que votre compilateur ne trouvera pas. Du 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 le publier en production.
Jmètre
Un framework open source pour les tests de performances orienté vers les développeurs Java, d'où le J dans le nom. Les tests de sites Web sont l'un des principaux cas d'utilisation de JMeter, en plus des tests de performances des bases de données, des systèmes de messagerie et de nombreuses autres applications basées sur des serveurs.
Metasploit
Pour les tests de sécurité et de pénétration, Metasploit est un framework 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 sur les tests de l'Université de Sheffield
- Laboratoire de vérification et de validation de logiciels de l'Université du Kentucky
- Groupe de recherche sur les tests de logiciels de l'Université d'État du Dakota du Nord
- Laboratoire intelligent de test du système ; Université technique tchèque de Prague
- NASA : Jon McBride Software Testing and Research (JSTAR)
- Université McMaster; Laboratoire de recherche sur la qualité des logiciels
- Université de technologie de l'Ontario; Laboratoire de recherche sur la qualité logicielle
- 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 du monde 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 exécutant les fonctions qu'il est destiné à exécuter. 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 à mesure qu'ils continuent de s'améliorer et de fournir sa fonction.
