Je suis un étudiant qui travaille sur mon BE (CS) et ma question est la suivante:

1. Des tests dans le domaine du logiciel sont-ils nécessaires?
2. Si nous créons un logiciel avec beaucoup de soin, alors pourquoi devrions-nous tester?
3. Après les tests, pouvons-nous être sûrs que nous avons atteint cet objectif (le produit / logiciel fonctionne comme prévu) car nous en avons fait les tests ? C'est possible?

Ma question: Des tests de logiciels sont-ils nécessaires ?

Oui. Parce que peu importe à quel point tu es bon, tu ne peux pas penser à tout.

• Il vous sera également demandé de faire en sorte que votre logiciel fasse des choses que vous n’avez jamais destinées à faire.
• En outre, vous ne rencontrerez jamais d'exigences aussi claires que vous pourrez imaginer toutes les possibilités pour vous assurer que le code ne casse pas.
• Vous travaillerez également avec des logiciels et des API d'autres personnes qui ne fonctionneront pas toujours comme prévu, mais vous supposerez que cela fonctionne ou devrait entraîner des défauts dans votre cas "parfait".

Oui

Pour la même raison, un chef goûte ses plats en les faisant cuire.

Je travaille avec quelqu'un qui pense comme ça, il pense que, parce qu'il est programmeur principal, il n'a plus besoin de tester son code. La société ne comprend pas à quel point cette attitude est dangereuse et au lieu de le limoger catégoriquement, elle a embauché davantage de programmeurs pour s'attaquer à l'arriéré de bogues. Ne sachant pas d'où provient cet arriéré, ils pensent que cela fait partie de la programmation. Fondamentalement, nous avons 3 programmeurs qui travaillent sous ce mode et une équipe de 20 personnes qui ne font que tester et corriger les bogues créés par ces trois logiciels.

ABSENCE DE BON TEST KILLS .

Donc, à moins que vous ne soyez DIEU ou quelle que soit la version de ce que vous savez parfaitement (maintenant que j'aimerais voir) ou à moins que vous ne vouliez être viré rapidement, je vous suggère fortement de commencer à tester.

Le logiciel est écrit par des personnes.

Les gens sont imparfaits et font des erreurs.

À mesure que la complexité d'une entreprise augmente, le nombre potentiel (et l'impact) d'erreurs, d'omissions ou de choses oubliées augmente, généralement de manière exponentielle.

Alors oui, des tests sont nécessaires. Cela apporte équilibre et perspective.

Voulez-vous prendre un vol qui exécute un système d'exploitation que vous savez utiliser sur votre ordinateur portable et vous donner un écran de la mort dans votre couleur préférée? Penses-y.

Aucun codeur n'est parfait. Loin, loin, loin de là vraiment. Vous avez besoin de tests, et les testeurs apportent souvent une perspective (également appelée cas d'utilisation) qui manquait aux développeurs.

Faites une recherche sur les bogues logiciels les plus célèbres sur Google pour savoir ce que je veux dire.

Et au niveau collégial, renseignez-vous sur le développement basé sur les tests, les tests unitaires et les pratiques agiles pour savoir où en sont les choses.

Le test est un impératif absolu pour toute application non triviale (en taille ou en fonction) devant être réellement utilisée. Vous ne trouverez pas un seul développeur qui se soucie de son métier (comme en témoigne sa visite de ce site) qui répondra et dira que les tests ne sont pas nécessaires.

Outre ce qui a déjà été publié, le fait de disposer d'une suite complète de tests unitaires automatisés sur une application donnée vous donnera plus de confiance pour les modifications futures du code. Cette confiance accrue (car les tests unitaires fournissent un filet de sécurité BIG) se traduira par des modifications de code plus rapides pour les applications existantes (en raison du nombre réduit de retours en arrière et de doubles vérifications).

Errare humanum est

Il n'y a pas de logiciel sans bug.

Le développeur le plus qualifié écrit du code avec des bogues. Même s'il existait un développeur parfait, il resterait des bugs dus aux différences entre:

• besoins des utilisateurs et documents de spécification
• spécification et conception
• environnements matériels et logiciels attendus et réels
• vérité d'hier et d'aujourd'hui: tout ce qui est énuméré ci-dessus est sujet à des changements qui ne sont pas parfaitement signalés à chaque étape du processus de développement.

Le développeur parfait n'est qu'une partie de la chose. Et les développeurs parfaits n'existent pas.

La plupart des programmes de la vie réelle:

a) contiennent des centaines de lignes de code ou plus, dispersées dans de nombreux fichiers;
b) sont développés par plus d'un programmeur;
c) utilisé dans des environnements différents de ceux du développeur

Ainsi, si vous ne vérifiez pas le fonctionnement du programme en situation réelle, les chances qu'il ne fonctionne pas du tout seraient proches de 100%.

En plus de toutes les autres bonnes réponses, même si vous savez que c'est parfait et sans bug, pensez aux autres programmeurs qui devront gérer votre code à l'avenir. Ils ne le sauront pas comme vous et voudront se fier à vos tests pour s’assurer qu’ils n’ont rien cassé après un changement. Bien entendu, cela s’applique également à vous-même après que vous n’ayez pas vu votre code depuis un an!

OUI.

Voici une autre perspective légèrement plus subtile qui n'a pas encore été couverte:

Ne sous-estimez jamais la nécessité d'une "vérification indépendante" . C’est la même raison pour laquelle il est utile de faire réviser votre travail par quelques rédacteurs indépendants avant de soumettre un texte volumineux à la publication. Quel que soit votre talent d'écrivain, vous ferez parfois un brainfart - et écrirez quelque chose comme "à" à la place de "ça", ou quelque chose du genre. Si vous le relisez vous-même, même avec beaucoup d'attention, vous le manquerez généralement, car votre cerveau accepte automatiquement votre flux de processus de pensée comme étant correct et dissimule l'erreur. Pour une nouvelle paire d'yeux, ce type d'erreur est généralement assez flagrant.

Vous obtenez la même chose en programmation: il est assez facile d'entrer dans un flux où soit votre code, soit votre "test de développement" de base de votre propre code - semble correct parce que vous le testez et l'utilisez d'une certaine manière. Mais ensuite, lorsqu'une autre paire de mains se présente et clique sur les choses d'une manière ou d'un ordre légèrement différents, tout s'écroule.

Maintenant, bien sûr, vous pouvez théoriquement procéder à la vérification formelle de chaque possibilité et branche logique de votre code vous-même, mais pour un logiciel non trivial, cela coûtera beaucoup plus cher et prendra beaucoup de temps que d'avoir quelqu'un d'autre à cogner. code pour vous. Et vous manquerez probablement encore des choses auxquelles vous n'aviez jamais pensé.

Ce qui n'a pas encore été touché: même si votre code est parfait, vous n'êtes toujours pas en sécurité. Les compilateurs ont des bogues qui peuvent entraîner un comportement incorrect du code, même parfait, après la compilation. Les systèmes d'exploitation ont des bogues qui peuvent provoquer un comportement binaire parfait lorsqu’ils sont exécutés. Le matériel contient des bogues pouvant causer des problèmes.

C'est aussi pourquoi les tests sur une seule machine ne suffisent pas pour les produits commerciaux. Ils doivent être testés avec le plus grand nombre possible de combinaisons matérielles et logicielles possibles.

Le responsable de l'équipe qui a conçu le logiciel pour la navette spatiale est parti avant chaque lancement pour prouver que le logiciel ne nuirait pas à la navette.

Selon vous, qu'est-ce qui lui a donné la confiance pour le faire?

Vous testez constamment du code simplement en le compilant et en l’utilisant. Dans certains IDE, vous obtenez des contrôles de cohérence lorsque vous tapez. Sauf si vous n'exécutez jamais votre code, vous effectuez des tests.

Ce que vous testez est vraiment la racine de ce type de question et la réponse à cette question se résume à un risque. Vous testez autant qu'il est logique de tester du point de vue de la gestion des risques. Tout tester ou rien n'est généralement impossible. Tester presque rien est généralement une mauvaise chose. Tout ce qui est intermédiaire est équitable, en fonction du niveau de risque et de l'exposition de votre produit livrable.

Ça sent la question des devoirs.

Des tests dans le domaine du logiciel sont-ils nécessaires?

Oui. Absolument. À tous les niveaux. En dehors de quelques domaines spécialisés, nous ne sommes pas encore à un stade où nous pouvons prouver mathématiquement que notre code est correct face à des bugs spécifiques (du moins pas dans un délai raisonnable). où ça casse.

Si nous créons un logiciel avec beaucoup de soin, alors pourquoi devrions-nous tester?

Les tests ne consistent pas uniquement à rechercher des erreurs de codage. Vous devez également vous assurer que vous répondez à toutes vos exigences et que l'ensemble du système fonctionne comme prévu. Si j'ai l'obligation de renvoyer un code d'erreur spécifique à une transaction ayant échoué, je dois alors écrire un test pour vérifier à la fois que la fonctionnalité existe et qu'elle fonctionne correctement.

Et tout cela suppose que la spécification et la conception sont complètes, correctes et cohérentes en interne, ce qui n’est souvent pas le cas. Même si vous respectez les spécifications à la lettre et suivez la conception jusqu'au dernier point et point-virgule, si la spécification ou la conception est incorrecte, des problèmes se poseront au moment de l'intégration. Souvent, les tests de système ou d'intégration consistent à découvrir que la spécification elle-même est erronée et doit être révisée (voir récit de guerre ci-dessous).

Après les tests, pouvons-nous être sûrs que nous avons atteint cet objectif (le produit / logiciel fonctionne comme prévu) car nous en avons fait les tests? C'est possible?

Non, pas à 100%. Nous ne pouvons pas tester toutes les combinaisons possibles d'entrées ou de chemins d'exécution dans un code autre que le plus simple. Nous ne pouvons pas prendre en compte tous les facteurs environnementaux. Nous ne pouvons pas imaginer tous les modes de défaillance possibles.

Nous pouvons tester à un point où nous sommes raisonnablement sûrs qu'il n'y a pas de gros problème. Encore une fois, c’est pourquoi nous devons tester à tous les niveaux. Ecrivez une suite de tests pour vous assurer que votre code gère correctement les conditions de bord (mauvaise entrée, résultats inattendus, exceptions, etc.). Test unitaire pour vérifier que votre code répond à ses exigences. Test du système pour vérifier le traitement de bout en bout. Test d'intégration pour vérifier que tous les composants se parlent correctement. Faites des tests d'utilisabilité pour vous assurer que tout fonctionne de manière à ce que les clients ne veuillent pas vous tirer dessus.

Scénario réaliste: je travaillais sur un système dorsal qui envoyait parfois des mises à jour à un service d'interface graphique pour les afficher dans un tableau à l'écran. Au cours du projet, un filtre a été ajouté à l'affichage (par exemple, l'opérateur peut choisir d'afficher un sous-ensemble des entrées de la table). Erreur de conception n ° 1 - le filtrage aurait dû être effectué par le service d'interface graphique (j'ai cette notion pittoresque et antiquaire selon laquelle les fonctions de gestion d'affichage devraient être la responsabilité du logiciel de gestion d'affichage), mais en raison de la politique et de mon incapacité à reconnaître les problèmes avant qu'ils ne deviennent problèmes , cette exigence a été mis sur le service de back-end. Bon, d'accord, pas de problème, je peux le faire. Si l'état du filtre change, je reçois un message, puis j'envoie un message de création ou de suppression pourchaque ligne du tableau , car c’est ainsi que fonctionne l’interface (erreur de conception n ° 2 - il n’ya aucun moyen d’envoyer des mises à jour à plusieurs lignes dans un seul message; nous ne pouvions même pas envoyer un seul message "effacer" ou "supprimer" pour effacer la table entière).

Eh bien, tout fonctionne bien pendant le développement; Les tests d'unité, de système et d'intégration montrent que j'envoie les bonnes informations et que je gère correctement les modifications du filtre. Ensuite , nous arrivons à des tests d'utilisation, et la chose tombe dur , car le volume de données a été écrasante. La latence du réseau entre mon service principal et l'interface graphique était de l'ordre de 0,15 à 0,25 seconde. Pas mal si vous devez seulement envoyer des mises à jour pour une douzaine de lignes ou plus. Mortel lorsque vous devez envoyer des mises à jour pour plusieurs centaines. Nous avons commencé à recevoir des rapports de bugs indiquant que l'interface graphique se figeait après la modification de l'état du filtre. eh bien, non, ce qui se passait, c’était que cela prenait de l’ordre de plusieurs minutes mettre à jour l’affichage, car le protocole de message mis au point avec une logique à la fois ne pouvait pas gérer un scénario réel.

Notez que tout cela aurait pu et aurait dû être anticipé par tout le monde, du contractant principal au plus vieux, si nous avions pris la peine de faire l’analyse la plus élémentaire à l’avance. La seule défense que je puisse offrir est que nous clôturions la deuxième année d'un projet de six mois qui devait être mis en pièces presque immédiatement après l'accouchement, et nous étions tous désespérés de le voir.

Ce qui nous amène à la dernière raison de tester - CYA. Les projets du monde réel échouent pour diverses raisons, notamment politiques, et tout le monde n'agit pas de bonne foi lorsque les choses tournent mal. Les doigts sont pointés, les accusations sont portées et, à la fin de la journée, vous devez être capable de pointer sur un enregistrement montrant qu'au moins vos données fonctionnent comme prévu .

Les tests seront toujours effectués et les bugs seront toujours trouvés. C'est simplement que le test sera effectué en interne par votre équipe ou que l'utilisateur final sera le testeur. Le coût d'un bogue détecté par l'utilisateur final est considérablement plus élevé que s'il avait été détecté par des tests.

Je suggérerais de suivre un bon cours d'informatique tolérant aux pannes. La conception minutieuse des logiciels n’est que l’un des piliers de la robustesse de votre produit logiciel. Les deux autres piliers sont des tests suffisants et une conception redondante. L'intention de base est de prendre en charge un nombre exponentiel de conditions de défaillance inconnues et de traiter en priorité certaines de celles connues:

1.) éliminer autant de défaillances possibles grâce à la conception et à une mise en œuvre appropriée 2.) éliminer les défaillances imprévues dès la phase de conception et une mise en œuvre incorrecte par diverses formes de test (unité, intégration, aléatoire) 3.) gérer toute défaillance laissée par redondance ( temporal => recalculer, réessayer ou spatial => conserver les copies, parité)

Si vous éliminez la phase de test, vous ne vous retrouverez qu'avec les phases de conception et de redondance pour traiter les défaillances.

En outre, d’un point de vue produit, vos parties prenantes (par exemple, la direction, les utilisateurs, les investisseurs) voudront avoir l’assurance que votre produit répond à certaines spécifications, critères, etc. relatifs à la qualité et à la sécurité, etc. En outre, n’avez-vous pas testé le logiciel vous avez construit juste pour avoir un «contrôle de santé mentale»? Toutes ces raisons rendent les tests de logiciels plus convaincants.

Tous les programmes ont des bogues, au moins pour commencer.

Certaines études convergent sur environ un bogue toutes les cinq lignes de code non testé.

Une leçon d'histoire:

Dans les années 1960, IBM avait besoin d'un programme "NOP" pour pouvoir exécuter certaines fonctionnalités du JCL sans exécuter de programme. Les développeurs ont mis au point un programme d'assemblage d'une ligne dans lequel le code entier était contenu dans son nom "IEFBR14", le code réel étant:

       BR 14 * brach to return address in register 14

Pendant sa longue période de temps, ce programme d’une ligne a fait l’objet de 2 rapports de bogues et de cinq amendements.

Le refactoring de code est vraiment plus rapide lorsque vous avez des tests unitaires. Un test unitaire vous montre également une utilisation simple des fonctions concrètes. Vous disposez donc d'un petit "howto" qui peut s'avérer très utile dans les grands projets où les programmeurs ne connaissent pas exactement le code complet.

Lorsque vous développez avec TDD (développement piloté par les tests), vous n'avez pas de getter / setters inutiles, etc. Vous créez simplement ce dont vous avez besoin.

Pour répondre au n ° 3 de votre question:

En tant que programmeur et testeur de logiciels, vous pouvez certes répondre aux exigences du logiciel lors des tests.

{mettre le chapeau QA}

Comment? Vous pouvez le faire en traçant vos tests du code de test aux critères d'acceptation, des critères d'acceptation aux fonctionnalités et des fonctionnalités aux exigences. Si vous tracez chaque test tout au long de la chaîne de conception et qu’il correspond à une ou plusieurs exigences, vous pouvez être sûr que vos tests sont utilisés pour garantir que le code répond à ses exigences (bien que cela soulève la notion de couverture de test adéquate, qui est une un autre sujet). Si vous ne pouvez pas suivre un test tout au long de la chaîne de conception, il est probable que vous testez des éléments inutiles, ce qui représente une perte de temps. Les critères d'acceptation peuvent également inclure la recherche de comportements indésirables - vous pouvez également les tester, ce qui vous rapproche encore plus d'une version de qualité.

{QA hat off}

Aucun code n'est jamais sans bug, mais moins coûteux au fil du temps lorsque plus d'efforts sont consacrés à l'évaluation de sa qualité au cours du développement.

Je suis testeur de logiciels depuis 3 ans maintenant. Au départ, j’étais moi-même sceptique quant à la nécessité de tester, car je pensais que si le département de développement et la gestion de projet faisaient leur travail, aucune erreur de logiciel ne devrait se produire.

MAIS ce n’est pas le cas. ++++++++

Les erreurs se produisent souvent, certaines d'entre elles critiques pour le fonctionnement d'un projet. Il existe également des tests inter-navigateurs (test sur différents navigateurs existants tels que SAFARI, FIREFOX, CHROME et Internet Explorer) et j'ai travaillé sur le projet où de simples boutons d'interface tels que YES et NO sur une fenêtre d'enquête ne fonctionnaient pas dans tous les navigateurs uniquement. certains d'entre eux.

J'ai travaillé sur des tests de pages Internet, des tests de modification de texte simples et je me suis dit qu'il n'y avait aucun problème avec ce travail simple, mais que cela ne se produise pas.

J'ai également constaté que de nouveaux développeurs rejoignaient l'équipe et recevaient un élément de mise à jour d'un formulaire d'application Internet complexe existant avec plusieurs liens / appels vers des pages externes. Une erreur s'est produite par manque de communication entre les anciens et les nouveaux développeurs. pour diverses raisons (pas le temps d'éduquer, pas la volonté d'éduquer, etc.).

OUI

Imaginez que votre logiciel ne soit qu'une fonction logique ET (b1, b2) où b1 et b2 ne sont que des bits. Avec cela, vous avez besoin de 4 cas de test pour vous assurer que votre logiciel est exempt d’erreurs, si votre environnement ambiant fournit exactement ce pour quoi ils ont été spécifiés.

Maintenant, votre système est composé de nombreuses fonctions dont la plus simple est bien plus compliquée que cette fonction logique. Comment vous assurer que c'est sans erreur?

(à suivre)