Pouvons-nous supposer, lors du test d'un logiciel, qu'un utilisateur ne réaliserait pas de telles actions stupides sur un logiciel?

Par exemple: lors du test fonctionnel d'un formulaire dans une application Web, nous allons tester les champs en entrant différents types de valeurs d'entrée aléatoires.

En général, en tant qu'utilisateurs de l'application Web, nous n'entrons pas de valeur aléatoire dans les champs.

Alors, à quoi sert-il d’incorporer tous ces cas de test qui peuvent / peuvent ne pas conduire à des bugs, quand la probabilité d’apparaître ce genre de problèmes dans la production est beaucoup moins importante?

Remarque: l'exemple ci-dessus n'est qu'un exemple de cas. de tels problèmes peuvent survenir dans tout type de fonctionnalité / module.

Je pose cette question uniquement pour savoir si des pratiques standard sont à suivre ou si cela dépend totalement du produit, du domaine et de tous les autres facteurs.

Vous ne pouvez pas entrer des valeurs aléatoires dans les champs d'une application Web, mais il y a certainement des gens qui le font.

Certaines personnes entrent au hasard par accident et d'autres le font intentionnellement pour tenter de casser l'application. Dans les deux cas, vous ne voulez pas que l'application se bloque ou présente un autre comportement indésirable.
Pour le premier type d’utilisateur, vous ne le souhaitez pas car cela leur donne une mauvaise expérience et risque de les détourner.
Pour le second type d'utilisateurs, ils n'ont généralement pas d'intention honorable et vous ne souhaitez pas leur permettre d'accéder à des informations auxquelles ils ne devraient pas pouvoir accéder ou leur permettre de refuser l'accès à vos services aux utilisateurs authentiques.

La pratique standard en matière de test consiste à vérifier non seulement le bon fonctionnement des conditions météorologiques, mais également à explorer les cas extrêmes afin de détecter les problèmes potentiels et de s’assurer que les pirates ne peuvent pas facilement accéder à votre système. Si votre application plante déjà avec une entrée aléatoire, vous ne voulez pas savoir ce qu'un attaquant peut faire avec une entrée spécialement conçue.

Ne présumez jamais rien

Vous ne pouvez pas supposer qu'un utilisateur ne fera pas quelque chose de "stupide" avec votre logiciel par accident ou à dessein. Les utilisateurs peuvent appuyer accidentellement sur le mauvais bouton, le chat peut marcher sur le clavier, le système peut mal fonctionner, son ordinateur peut être piraté par un logiciel malveillant, etc.

En outre, l'utilisateur peut être malveillant, cherchant intentionnellement des moyens de casser votre logiciel dans l'espoir de trouver le moyen de l'exploiter à son avantage. Même s'ils trouvent un bogue qu'ils ne peuvent pas exploiter, tout ce qu'ils trouvent peut les inciter à sonder votre système à la recherche de quelque chose qu'ils peuvent attaquer, sachant que vos procédures d'assurance qualité manquent.

En ce qui concerne les tests, il est utile de se prémunir contre les entrées aléatoires. Cependant, choisir des entrées de test de manière totalement aléatoire (c'est-à-dire sans aucune considération particulière pour un cas d'utilisation ou un cas d'extrémité) est presque inutile. Le but du test est de valider votre solution par rapport aux exigences et aux attentes de votre employeur / client / utilisateur. Cela signifie que vous devez vous concentrer sur tous les cas limites et toutes les conditions limites, ainsi que sur tous les cas «dégénérés» qui ne correspondent pas au flux de travail attendu de l'utilisateur.

Bien sûr, vous pouvez exécuter des tests qui révèlent des bogues que vous ne jugerez pas utiles de corriger; cela peut être dû à toutes sortes de raisons - le bogue peut être trop coûteux à corriger par rapport à son impact sur l'utilisateur, ou vous pouvez découvrir des bogues dans des fonctionnalités que personne n'utilise, ou le bogue peut être si bien ancré dans le système que certains les utilisateurs le traitent comme une fonctionnalité.

Alternativement, vous pouvez être en train d’écrire des logiciels sur mesure qui ont un public très restreint d’utilisateurs «experts» pour lesquels il n’ya aucun avantage commercial à perdre du temps à corriger des bugs, car ces utilisateurs sont capables de faire leur travail avec un logiciel buggy (par exemple, un outil de diagnostic). utilisé par l'équipe informatique interne ne génère pas de revenus. Par conséquent, si une panne se produit occasionnellement, personne ne voudra probablement payer pour le temps nécessaire à la réparation - il demandera simplement à l'équipe informatique de gérer les bugs à la place) .

Cependant, vous ne pouvez prendre ces décisions que si vous connaissez ces bugs. Par exemple, un utilisateur peut entrer une entrée malveillante qui efface toute la base de données. Si vous n'avez pas explicitement protégé et testé ce scénario, vous ne pouvez absolument pas savoir si cela peut se produire ou non. Le risque de laisser des bogues non découverts dans le système signifie que vous vous exposez potentiellement à de vrais problèmes si l'un de ces bogues se révélait dans le monde réel et avait un impact majeur sur vos utilisateurs.

Ainsi, bien que la décision de réparer les bogues puisse nécessiter l'intervention du propriétaire du logiciel (généralement celui qui paye votre salaire), la décision de tester les bogues et les cas à tester est une préoccupation technique qui doit être prise en compte. pris en compte dans les estimations et la planification du projet, l'objectif étant de couvrir le plus possible une couverture aussi complète que raisonnablement possible compte tenu des contraintes de temps, d'argent et de ressources.

Il y a plusieurs facteurs à prendre en compte. Pour illustrer ces points, je vais utiliser un exemple de champ dans lequel un utilisateur doit entrer un pourcentage dans le contexte d'un quota défini pour une tâche spécifique en termes de quantité d'espace disque que la tâche peut utiliser. 0% signifie que la tâche ne pourra rien écrire sur le disque. 100% signifie que la tâche peut occuper tout l'espace disque. Les valeurs intermédiaires signifient ce qu'elles signifient.

En tant que développeur, vous estimez probablement que les valeurs acceptables sont [0, 1, 2, 3, 99, 100], et tout le reste est idiot. Voyons pourquoi les utilisateurs pourraient toujours entrer ces valeurs «stupides».

Les typos

%^

L'utilisateur saisissait la valeur 56 mais avait appuyé par erreur Shiften le saisissant (par exemple, sur le clavier français, vous devez appuyer sur Shiftpour saisir les chiffres et l'utilisateur basculait constamment entre un clavier français et un QWERTY).

De la même manière, vous pouvez obtenir un numéro, avec quelque chose après ou avant, ou entre les deux:

56q

Ici, l'utilisateur était probablement en train d'entrer les chiffres, suivis d'un onglet pour passer au champ suivant. Au lieu d'appuyer sur   ⇆  , l'utilisateur a appuyé sur la touche du voisin.

Malentendus et interprétations erronées

Une entrée vide est probablement la plus courante. L'utilisateur a imaginé que le champ était optionnel ou ne savait pas quoi mettre dans ce champ.

56.5

L'utilisateur pensait que les valeurs en virgule flottante étaient acceptables. Soit l'utilisateur se trompe, et l'application doit expliquer poliment pourquoi seules les valeurs entières sont acceptées, ou les exigences initiales sont fausses et il est logique de laisser les utilisateurs entrer des valeurs en virgule flottante.

none

L'utilisateur a mal compris que lorsqu'on lui demandait l'espace que la tâche pourrait occuper, l'application s'attendait à un numéro. Cela pourrait indiquer une mauvaise interface utilisateur. Par exemple, demander à l'utilisateur "Combien d'espace disque la tâche devrait-il occuper?" Invite à ce type d'entrée, alors qu'un champ suivi du signe de pourcentage recevrait moins de ce type d'entrée, car "aucun%" ne génère pas beaucoup de sens.

150

L'utilisateur a mal compris ce que le pourcentage signifie dans ce cas. Peut-être que l'utilisateur voulait dire que la tâche peut occuper 150% de l'espace actuellement utilisé. Si un disque de 2 To, 100 Go sont utilisés, la tâche peut utiliser 150 Go. Encore une fois, une meilleure interface utilisateur pourrait aider. Par exemple, au lieu d’avoir un champ de saisie nu auquel est ajouté un signe de pourcentage, on pourrait avoir ceci:

[____] % of disk space (2 TB)

Lorsque l'utilisateur commence à taper, le texte à la volée change pour devenir ceci:

[5___] % of disk space (102.4 GB of 2 TB)

Représentations

Les grands nombres ou les nombres avec une virgule flottante peuvent être représentés différemment. Par exemple, un certain nombre 1234,56 pourrait être écrit comme ça: 1,234.56. Selon la culture, la représentation textuelle du même nombre serait différente. En français, le même nombre sera écrit comme ceci: 1 234,56. Vous voyez, une virgule où vous ne vous attendez pas, et un espace.

Attendre toujours qu'un format spécifique en utilisant des paramètres régionaux spécifiques vous cause des problèmes tôt ou tard, car les utilisateurs de différents pays auront des habitudes différentes d'écriture des chiffres, des dates et des heures, etc.

Les humains contre les ordinateurs

Twenty-four

Les humains ordinaires ne pensent pas de la même manière que les ordinateurs. "Vingt-quatre" est un nombre réel, indépendamment de ce qu'un PC vous dirait.

Bien que (1) la plupart des systèmes ne gèrent pas du tout ce type d'entrée et (2) presque tous les utilisateurs n'imaginent pas entrer un nombre écrit en lettres entières, cela ne veut pas dire qu'une telle entrée est stupide. Dans À propos de Face 3 , Alan Cooper souligne que le fait de ne pas manipuler de telles entrées est révélateur de l'incapacité des ordinateurs à s'adapter aux humains. Idéalement, l'interface devrait pouvoir gérer ces entrées correctement.

La seule chose que je dois ajouter au livre d'Alan Cooper est que, dans de nombreux cas, les nombres sont écrits en chiffres par erreur . Le fait que les ordinateurs s’attendent à ce que leurs utilisateurs fassent des erreurs (et ne tolèrent pas un utilisateur qui écrit correctement) est agaçant.

Unicode

5𝟨

Unicode réserve ses propres surprises: des personnages qui pourraient se ressembler ne sont pas les mêmes. Pas convaincu? Copiez-collez "5𝟨" === "56"dans les outils de développement de votre navigateur et appuyez sur Enter.

La raison pour laquelle ces chaînes ne sont pas égales, c'est que le caractère Unicode 𝟨n'est pas identique au caractère 6. Cela créerait une situation dans laquelle un client en colère appellerait, disant que votre application ne fonctionnait pas, fournissant une capture d'écran d'une entrée qui semblait légitime, et votre application prétendant que l'entrée était invalide.

Pourquoi quelqu'un voudrait-il entrer un caractère Unicode qui ressemble à un chiffre, demandez-vous? Bien que je ne m'attende pas à ce qu'un utilisateur en saisisse un par inadvertance, un copier-coller provenant d'une source différente peut le provoquer, et j'ai eu le cas où l'utilisateur a réellement fait un tel copier-coller d'une chaîne contenant un caractère Unicode qui ne le ferait pas. apparaissent à l'écran.

Conclusion

Ce sont les cas que vous obtenez pour un champ de saisie de numéro élémentaire. Je vous laisse imaginer ce que vous pouvez avoir à manipuler pour des formulaires plus complexes, tels qu'une date ou une adresse.

Ma réponse est axée sur ce que vous avez appelé une entrée «stupide». Les tests ne consistent pas à vérifier les chemins heureux; Il s'agit également de vérifier que votre application ne se casse pas lorsqu'un utilisateur malveillant entre intentionnellement des choses étranges, en essayant de le casser. Cela signifie que lorsque vous demandez un pourcentage, vous devez également tester ce qui se passe lorsque l'utilisateur répond avec une chaîne contenant 1 000 000 caractères, un nombre négatif ou une table de Bobby .

Il y a beaucoup de bonnes réponses ici qui décrivent pourquoi c'est important, mais pas beaucoup de conseils sur la façon de protéger de manière raisonnable votre application. La "pratique standard" consiste à utiliser une validation d’entrée robuste, à la fois sur le client et sur le serveur. Il est facile de se défendre contre les intrants non sensibles. vous refusez simplement tout ce qui n'a pas de sens dans ce contexte spécifique. Par exemple, un numéro de sécurité sociale se compose uniquement de tirets et de chiffres; vous pouvez en toute sécurité refuser quoi que ce soit que l'utilisateur tape dans un champ de numéro de sécurité sociale.

Il existe deux types de tests qui devraient avoir lieu sur chaque application que vous écrivez, et ils ont chacun des objectifs différents. Les tests que vous faites sur votre propre application sont des tests positifs; son but est de prouver que le programme fonctionne. Les tests que les testeurs font en outre sur votre application sont des tests négatifs; son but est de prouver que votre programme ne fonctionne pas. Pourquoi avez-vous besoin de cela? Parce que vous n'êtes pas la meilleure personne pour tester votre propre logiciel. Après tout, vous avez écrit la chose, alors évidemment, cela fonctionne déjà, non?

Lorsque vous écrivez la validation d'entrée, vous utiliserez des tests positifs pour prouver que votre validation fonctionne. Les testeurs utiliseront des entrées aléatoires pour tenter de prouver que cela ne fonctionne pas. Notez que l’espace problématique pour les entrées aléatoires est essentiellement sans limite; votre objectif n'est pas de tester toutes les permutations possibles, mais de limiter l'espace du problème en rejetant les entrées non valides.

Notez également que l'utilisateur final n'est pas le seul à fournir des informations pour votre programme. Chaque classe que vous écrivez a sa propre API et ses propres contraintes sur ce qui est considéré comme une entrée valide. Par conséquent, une validation robuste (c'est-à-dire "contrats de code") est également importante pour vos classes. L'idée est de durcir votre logiciel afin que le comportement inattendu soit rare ou inexistant dans la mesure du possible.

Enfin, le flux de travail est important. J'ai vu des applications s'effondrer, non pas parce que l'utilisateur avait entré quelque chose de non sensuel, mais parce qu'il avait fait les choses dans l'application dans un ordre inattendu. Votre application doit être consciente de cette possibilité et gérer les workflows inattendus avec élégance ou demander à l'utilisateur d'effectuer des opérations dans l'ordre que vous avez défini.

Habituellement, les valeurs «aléatoires» ne sont pas aléatoires. Vous essayez de capturer les cas extrêmes, "l'inconnu inconnu".

Disons par exemple que le caractère # va planter votre application. Vous ne le savez pas à l'avance et il serait impossible d'écrire des scénarios de test pour chaque entrée possible. Mais nous pouvons écrire un test "¬!"£$%^&*()_+-=[]{};'#:@~,./<>?|\"et voir s'il se casse

J'ai déjà écrit un programme que j'ai testé en direct dans un laboratoire avec 60 étudiants. Je me tenais derrière les 60 écrans d’ordinateur et je les ai vus les utiliser. La quantité de choses ridicules qu'ils ont faites était époustouflant. J'étais trempé de sueur en regardant leur "créativité". Ils ont fait beaucoup plus que ce qu'un individu ne peut imaginer au cours de sa vie. Bien sûr, l'un d'entre eux l'a cassé.

Après cela, je suis une approche: if "a very specific use case" do, else show error

Si j’ai plusieurs cas d’utilisation, je les définit strictement et enchaîne ce qui précède.

Ce que vous décrivez est Fuzzing ou Fuzz Testing : jetez une entrée aléatoire et non valide sur un système et voyez ce qui se passe. Vous ne le faites pas parce que vous vous attendez à ce que l'utilisateur le fasse. Vous le faites pour exposer vos propres suppositions et vos propres préjugés afin de souligner les contours de votre système pour voir ce qui se passe.

Une entrée de test normale écrite par un humain avec viendra avec des hypothèses et des biais. Ces biais peuvent être que certaines classes de bugs ne sont jamais détectées via des tests.

Par exemple, si l'essentiel de votre saisie se situe dans la plage Unicode conforme à la norme ASCII, les hypothèses concernant le codage des caractères dans le code ne sont pas appliquées. Ou peut-être est-il toujours inférieur à une certaine taille, de sorte qu'un champ ou un tampon de taille fixe ne soit pas touché. Ou peut-être y a-t-il des caractères spéciaux qui sont interprétés de manière surprenante, révélant que les entrées de l'utilisateur sont transmises à un shell ou utilisées pour créer des requêtes de manière non sécurisée. Ou peut-être y a-t-il trop de tests de "bonne voie" et pas assez de tentatives pour gérer le traitement des erreurs.

Fuzzing n'a pas de telles idées préconçues sur l'entrée. Il exercera brutalement votre système avec toute combinaison possible d’entrées «valides». Unicode, ASCII, grand, petit et beaucoup d’erreurs. Votre système devrait répondre gracieusement à tous. Il ne devrait jamais planter. L'utilisateur doit toujours recevoir une sorte de message raisonnable sur ce qui n'a pas fonctionné et sur la façon de le réparer. Ce n'est pas Garbage In / Garbage Out, c'est Garbage In / Error Out .

Bien que l'on puisse rejeter les explosions résultantes car "aucun utilisateur réel ne le fera", cela manque le but de l'exercice. Le fuzzing est un moyen peu coûteux d’éliminer vos partis pris au sujet d’entrées possibles. C'est un moyen peu coûteux de lancer toutes les choses étranges que les utilisateurs tenteront de faire sur votre système. En tant qu’ingénieur, votre travail consiste à vous assurer que votre système tombe en panne correctement.

De plus, le fuzzing "input" ne concerne pas que les utilisateurs. Cela pourrait représenter le résultat d'une requête d'API auprès d'un service tiers. Que faire si cela commence à envoyer des résultats erronés? Comment votre système gère-t-il cela? Un système approprié doit alerter un administrateur qu'un composant a mal fonctionné. Un système inapproprié rejettera discrètement la mauvaise requête ou, pire encore, l'acceptera comme une bonne donnée.

Enfin, certains utilisateurs sont malveillants. Si vous ne testez pas votre système avec fuzz, quelqu'un d'autre le fera. Ils rechercheront les erreurs courantes sur les bords de votre système et tenteront de les utiliser comme failles de sécurité. Les tests Fuzz peuvent simuler cela, dans une certaine mesure, et vous pouvez gérer les éventuelles failles de sécurité découvertes avant qu’elles ne deviennent un problème.

Si votre objectif est de créer un produit de qualité, testez tous les types d'entrée qu'un utilisateur sera physiquement en mesure de soumettre. Sinon, vous n'attendez que le jour où quelqu'un soumettra un type de contribution qui, à votre avis, n'aurait pas été nécessaire.

Au cours d'une grande démonstration d'un nouveau logiciel de vente aux enchères en ligne dans une autorité locale où je travaillais, mon responsable a décidé (avec certitude un tort) qu'il ressentait le besoin de voir ce qui se passerait s'il mettait une enchère avec une valeur négative. À ma grande surprise, le logiciel de vente aux enchères a permis cette offre absurde et le processus de vente aux enchères dans son ensemble. Le type d'enchère démontrée n'aurait jamais dû permettre la soumission de montants négatifs.

Certains membres du groupe important de responsables des achats et des finances ont été contrariés par mon directeur, qui leur a soumis une valeur absurde. Mais d'autres, y compris moi-même, ont été contrariés par les développeurs de logiciels pour avoir omis de tester et de rejeter un type aussi évident d'entrées non valides. Je ne peux qu'imaginer à quel point le logiciel doit avoir été faible pour dévier d'autres types d'entrées non valides (tentatives d'injection de code, caractères exotiques non représentables dans la table de base de données, etc.).

Si cela ne tenait qu'à moi, j'aurais rendu le logiciel et je l'aurais jugé inutilisable. La différence entre un logiciel faible et puissant est le niveau de test auquel il a été soumis.

Par exemple: lors du test fonctionnel d'un formulaire dans une application Web, nous allons tester les champs en entrant différents types de valeurs d'entrée aléatoires.

Oui. C'est une sorte de test mais ce n'est pas un test fonctionnel . C'est ce qu'on appelle les tests de stress . Il s’agit de faire pression sur un système pour voir s’il peut le gérer.

Alors, à quoi sert-il d’incorporer tous ces cas de test qui peuvent / peuvent ne pas conduire à des bugs, quand la probabilité d’apparaître ce genre de problèmes dans la production est beaucoup moins importante?

Lorsque vous testez un logiciel de test d' effort , vous essayez de découvrir les limites de ce que sont les logiciels.

Les tests sont par nature exhaustifs. Vous devez découvrir les limites d'utilisation, les points de rupture, vérifier toutes les branches logiques ou voir comment des défaillances partielles affectent l'ensemble du système.

Vous pouvez faire passer tous vos tests fonctionnels mais échouer quand même aux tests de stress .

Je pose cette question uniquement pour savoir si des pratiques standard sont à suivre ou si cela dépend totalement du produit, du domaine et de tous les autres facteurs.

Oui, c'est une pratique standard.

Le logiciel de test consiste à poser une question sur le comportement attendu . Lorsque tous les tests réussissent, cela indique que le logiciel fonctionne comme prévu. C'est pourquoi les tests constituent de bonnes conditions préalables au déploiement des mises à jour.

Les tests de résistance ne fournissent pas d'indicateurs clairs de réussite ou d'échec. Les résultats sont plus informatifs. Il vous indique ce que votre système peut gérer et vous prenez des décisions à partir de ces informations.

Vous pouvez définir des objectifs spécifiques pour les tests de résistance, qui doivent être passés afin de pouvoir passer à l'étape suivante du développement. Ceux-ci peuvent être inclus dans le cadre de votre processus d'assurance qualité, mais des modifications de l'environnement peuvent également modifier les résultats d'un test de résistance. Les gens font donc des tests de résistance à différents moments pour voir comment le système gère les conditions changeantes.

Ce que je veux dire, c'est que vous ne pouvez pas simplement exécuter des tests de contrainte à chaque fois que vous déployez une nouvelle version de votre logiciel, en supposant que tout se passera bien plus tard.