Comment identifiez-vous les cas «marginaux» sur les algorithmes?

Fondamentalement, comment déterminez-vous quel pourrait être votre pire ou votre meilleur cas et tous les autres cas "marginaux" que vous pourriez avoir AVANT de les avoir et ainsi, comment préparez-vous votre code pour eux?

Sur la base du contenu de l'algorithme, vous pouvez identifier les structures / types / constructions de données utilisées. Ensuite, vous essayez de comprendre les points faibles (possibles) de ceux-ci et essayez de trouver un plan d'exécution qui le fera fonctionner dans ces cas.

Par exemple, l'algorithme prend une chaîne et un entier en entrée et effectue un tri des caractères de la chaîne.

Ici nous avons:

Chaîne avec quelques cas spéciaux connus:

• Chaîne vide
• Longue chaîne
• Chaîne Unicode (caractères spéciaux)
• S'il est limité à un ensemble spécifique de caractères, que se passe-t-il lorsque certains ne sont pas dans la plage
• Chaîne de longueur paire / impaire
• Null (comme argument)
• Terminé non nul

Entier avec des cas spéciaux connus:

• 0
• Min / MaxInt
• Négatif positif

Algorithme de tri pouvant échouer dans les cas limites suivants:

• Entrée vide
• 1 entrée d'élément
• Entrée très longue (peut-être de longueur max (type de données utilisé pour l'index))
• Ordures dans la collection qui seront triées
• Entrée nulle
• Éléments en double
• Collection avec tous les éléments égaux
• Entrée de longueur paire / impaire

Ensuite, prenez tous ces cas et créez une longue liste en essayant de comprendre comment ils se chevauchent. Ex:

• Le cas de chaîne vide couvre le cas de collection vide
• Chaîne nulle == collection null
• etc.

Créez maintenant des cas de test pour eux :)

Bref résumé : divisez l'algorithme en blocs de base pour lesquels vous connaissez les cas limites, puis réassemblez-les, créant des cas limites globaux

Je ne pense pas qu'il existe un algorithme pour déterminer les conditions de bord ... juste l'expérience.

Exemple: pour un paramètre d'octet, vous souhaitez tester des nombres comme 0, 127, 128, 255, 256, -1, tout ce qui peut causer des problèmes.

Un «bord» a deux significations, et les deux sont pertinentes lorsqu'il s'agit de cas de bord. Un bord est soit une zone où un petit changement dans l'entrée conduit à un grand changement dans la sortie, soit la fin d'une plage.

Donc, pour identifier les cas limites d'un algorithme, je regarde d'abord le domaine d'entrée. Ses valeurs de bord pourraient conduire à des cas de bord de l'algorithme.

Deuxièmement, je regarde le domaine de sortie et regarde en arrière les valeurs d'entrée qui pourraient les créer. C'est moins souvent un problème avec les algorithmes, mais cela aide à trouver des problèmes dans les algorithmes conçus pour générer une sortie qui s'étend sur un domaine de sortie donné. Par exemple, un générateur de nombres aléatoires devrait être capable de générer toutes les valeurs de sortie prévues.

Enfin, je vérifie l'algorithme pour voir s'il existe des cas d'entrée similaires, mais conduisant à des sorties différentes. Trouver ces cas limites est le plus difficile, car il implique à la fois des domaines et une paire d'entrées.

C'est une question très générale donc tout ce que je peux faire est de jeter des idées générales et vagues :)

-Examinez les cas limites. Ex. si vous analysez une chaîne, que se passe-t-il si la chaîne est vide ou nulle? Si vous comptez de x à y, que se passe-t-il en x et y?
-Code qui pourrait être simplifié ou séché. Toute complexité inutile pourrait ajouter des choses qui pourraient mal tourner.

Une partie de l'habileté d'utiliser des algorithmes est de connaître leurs faiblesses et leurs cas pathologiques. La réponse de Victor donne quelques bons conseils, mais en général, je vous conseillerais d'étudier le sujet plus en profondeur pour avoir une idée de cela, je ne pense pas que vous puissiez suivre les règles de base pour répondre pleinement à cette question. Par exemple, voir Cormen ou Skiena (Skiena en particulier a une très bonne section sur où utiliser les algorithmes et ce qui fonctionne bien dans certains cas, Cormen va vers plus de théorie je pense).