* Une inspection est plus formalisée qu'un « walkthrough », typiquement avec 3-8 personnes comprenant un président, le lecteur, et un enregistreur pour prendre des notes. Le sujet de l'inspection est typiquement un document tel que Spéc. de conditions ou un plan d'essai, et le but est trouver des problèmes et de voir ce qui est absent, pour ne pas fixer n'importe quoi. Les participants devraient se préparer à ce type de se réunir par la lecture par le document ; la plupart des problèmes seront trouvés pendant cette préparation. Le résultat de la réunion d'inspection devrait être un rapport écrit.
les genres 10.What d'essai devraient être considérés ?
* Boîte noire examinant - non basé sur toute connaissance de conception ou de code interne. Des essais sont basés sur des conditions et la fonctionnalité.
* Boîte blanche examinant - basé sur la connaissance de la logique interne du code d'une application. Des essais sont basés sur l'assurance des rapports de code, branches, chemins, conditions.
* Essai d'unité - la balance « la plus micro » de l'essai ; pour examiner des fonctions particulières ou des modules de code. Typiquement fait par le programmeur et pas par des appareils de contrôle, comme il exige la connaissance détaillée de la conception et du code internes de programme. Pas toujours facilement fait à moins que l'application ait une architecture bien projetée avec le code serré ; peut exiger les modules de conducteur d'essai ou les harnais se développer d'essai.
* Intégration par accroissement examinant - l'essai continu d'une application en tant que nouvelle fonctionnalité est ajouté ; exige que les divers aspects de la fonctionnalité d'une application soient assez indépendants fonctionner séparément avant que toutes les parties du programme soient accomplies, ou que des conducteurs d'essai soient développés comme nécessaires ; fait par des programmeurs ou par des appareils de contrôle.
* Essai d'intégration - essai des parties combinées d'une application pour déterminer s'ils fonctionnent ensemble correctement. Les « pièces » peuvent être des modules de code, de différentes applications, des applications de client et de serveur sur un réseau, etc. Ce type d'essai est particulièrement approprié au client/au serveur et aux systèmes répartis.
* Essai fonctionnel - le type essai de noir-boîte a adapté aux conditions fonctionnelles d'une application ; ce type d'essai devrait être fait par des appareils de contrôle. Ceci ne signifie pas que les programmeurs ne devraient pas vérifier que leur code fonctionne avant de le libérer (qui naturellement s'applique à n'importe quelle étape de l'essai.)
* Essai de système - type essai de noir-boîte qui est basé sur des caractéristiques de conditions globales ; couvre toutes les parties combinées d'un système.
* Essai bout à bout - semblable à l'essai de système ; la « macro » extrémité de la balance d'essai ; comporte l'essai d'un environnement complet d'application dans une situation qui imite l'utilisation réelle, telle qu'agir l'un sur l'autre avec une base de données, en utilisant des communications de réseau, ou agir l'un sur l'autre avec d'autres matériel, applications, ou systèmes si approprié.
* Santé d'esprit examinant ou essai de fumée - typiquement un premier effort de essai de déterminer si une nouvelle version de logiciel exécute assez bien pour l'accepter pour un effort de essai important. Par exemple, si le nouveau logiciel se brise des systèmes toutes les 5 minutes, s'embourbe des systèmes à un rampement, ou corrompt des bases de données, le logiciel peut ne pas être dans un « raisonnable » assez de condition pour justifier plus loin l'essai dans son état actuel.
* Essai de régression - essayant de nouveau après des difficultés ou des modifications du logiciel ou de son environnement. Il peut être difficile de déterminer combien essayer de nouveau coûte nécessaire, particulièrement près de la fin du cycle de développement. Les outils de essai automatisés peuvent être particulièrement utiles pour ce type d'essai.
* Essai d'homologation - essai final basé sur des caractéristiques de l'utilisateur ou du client, ou basé sur l'utilisation par des utilisateurs/clients au-dessus d'une certaine période limitée.
* Essai de charge - examinant une application sous les charges lourdes, telles que l'essai d'un site Web sous une gamme des charges pour déterminer à quel point le temps de la réaction du système dégrade ou échoue.
* Essai d'effort - limite employée souvent l'un pour l'autre avec la « charge » et la « exécution » examinant. En outre décrivaient des essais tels que l'essai fonctionnel de système tandis que sous les charges exceptionnellement lourdes, la répétition lourde de certaines actions ou entrées, l'entrée de grandes valeurs numériques, les grandes questions de complexe à un système de base de données, etc.
* Essai de performance - nommer employé souvent l'un pour l'autre avec le « effort » et la « charge » examinant. Dans le meilleur des cas la « exécution » essai (et tout autre « type » d'essai) est définie dans la documentation de conditions ou la QA ou les plans d'essai.
* Essai de rentabilité - déterminant la « facilité d'emploi ». Clairement c'est subjectif, et dépendra de l'utilisateur ou du client visé. Des entrevues d'utilisateur, les aperçus, l'enregistrement visuel des sessions d'utilisateur, et d'autres techniques peuvent être employés. Les programmeurs et les essayeurs ne sont habituellement pas appropriés comme appareils de contrôle de rentabilité.
* Installer/examiner d'uninstall - l'essai de complètement, partiel, ou la mise à niveau installent/processus d'uninstall.
* Essai de rétablissement - examinant à quel point un système récupère des accidents, des échecs de matériel, ou d'autres problèmes catastrophiques.
* Essai de Failover - typiquement utilisé l'un pour l'autre avec le « essai de rétablissement »
* Essai de sécurité - examinant à quel point le système se protège contre l'accès interne ou externe non autorisé, les dommages obstinés, etc. ; peut exiger des méthodes d'essai sophistiquées.
* Essai de compatibilité - examinant à quel point le logiciel exécute dans un environnement particulier de matériel/logiciel/logiciel d'exploitation/réseau/etc.
* Essai exploratoire - souvent pris pour signifier un essai créateur et sans cérémonie de logiciel qui n'est pas basé sur des plans d'essai ou des cas d'espèce formels ; les essayeurs peuvent apprendre le logiciel comme ils l'examinent.
* Essai ad-hoc - semblable à l'essai exploratoire, mais souvent pris pour signifier que les appareils de contrôle ont l'arrangement significatif du logiciel avant de l'examiner.
* essai Contexte-conduit - essai conduit par un arrangement de l'environnement, de la culture, et de l'utilisation prévue du logiciel. Par exemple, l'approche de essai pour le logiciel médical vie-critique d'équipement serait complètement différente que celle pour un jeu d'ordinateur peu coûteux.
* Essai d'acceptation par les utilisateurs - déterminant si le logiciel est satisfaisant à un utilisateur ou à un client.
* Essai de comparaison - comparer des faiblesses et des forces de logiciel aux produits de concurrence.
* Essai d'alpha - essai d'une application quand le développement est en voie d'achèvement ; des changements mineurs de conception peuvent encore être faits en raison d'un tel essai. Typiquement fait par des utilisateurs ou d'autres, pas par des programmeurs ou des essayeurs.
* Le bêta essai - examinant quand le développement et l'essai sont essentiellement accomplis et les bogues et les problèmes finals doit être trouvé avant dégagement final. Typiquement fait par des utilisateurs ou d'autres, pas par des programmeurs ou des essayeurs.
* Essai de mutation - une méthode pour déterminer si un ensemble d'essais ou de cas d'espèce est utile, en présentant délibérément de divers changements de code (« bogues ») et en les essayant de nouveau avec les essais/cas originaux pour déterminer si les « bogues » sont détectés. L'exécution appropriée exige de grandes ressources informatiques.
11.What 5 problèmes sont-ils communs dans le procédé de développement de logiciel ?
* Conditions pleines - claires, conditions complètes, détaillées, cohésives, possibles, testables qui sont convenues par tous les joueurs. Employer les prototypes pour aider à clouer en bas des conditions. « Agile » - introduire au clavier les environnements, coordination continue avec des clients/utilisateurs est nécessaire.
* Des programmes réalistes - accorder à heure proportionnée pour la planification, la conception, l'essai, le bogue fixant, essayer de nouveau, les changements, et la documentation ; le personnel devrait pouvoir accomplir le projet sans grillage.
* À essai proportionné - commencer à examiner dès l'abord, essayer de nouveau après que des difficultés ou des changements, plan pendant à heure proportionnée pour examiner et bogue-réparation. « Tôt » l'essai idéalement inclut l'unité examinant par des réalisateurs et essai de fonction intégrée et des possibilités diagnostiques.
* Coller aux conditions initiales autant que possible - être préparé pour défendre contre les changements et les additions excessifs une fois que le développement a commencé, et pour être préparé pour expliquer des conséquences. Si les changements sont nécessaires, ils devraient être en juste proportion reflétés dans les changements relatifs de programme. Si possible, travailler étroitement avec des clients/utilisateurs pour contrôler des espérances. Ceci leur fournira à un niveau plus élevé de confort leurs décisions de conditions et réduira au minimum les changements excessifs plus tard.
* communication - exiger les walkthroughs et les inspections si approprié ; faire l'utilisation étendue des outils de communication de groupe - E-mail, groupware, outils de bogue-cheminement gérés en réseau et outils de gestion de changement, possibilités d'Intranet, etc. ; s'assurer que l'information/documentation est disponible et à jour - de préférence électronique, pas papier ; encourager le travail d'équipe et la coopération ; employer les protoypes si possible pour clarifier les espérances des clients.
12.What est logiciel « qualité » ?
* Le logiciel de qualité est raisonnablement exempt d'erreurs, livré à l'heure et dans le budget, les conditions de rassemblements et/ou les espérances, et est maintenable. Cependant, la qualité est évidemment une limite subjective. Elle dépendra de qui le « client » est et leur influence globale dans l'arrangement des choses. Une vue grande-angulaire des « clients » d'un projet de développement de logiciel pourrait inclure des utilisateurs, essayeurs d'acceptation de client, dirigeants de contrat de client, gestion de client, l'organisation de développement.
* Gestion/comptables/essayeurs/vendeurs, futurs ingénieurs d'entretien de logiciel, actionnaires, chroniqueurs de magasin, etc. Chaque type de « client » aura leur propre pente sur la « qualité » - le service comptable pourrait définir la qualité en termes de bénéfices tandis qu'un utilisateur pourrait définir la qualité comme facile à utiliser et exempte d'erreurs.
13.What est « bon code » ?
* * le « bon code » est le code qui fonctionne, est exempt d'erreurs, et est lisible et maintenable. Quelques organismes ont un codage « normes » au lequel tous les réalisateurs sont censés adhérer, mais chacun a différentes idées au sujet de ce qui est le meilleur, ou de ce qui est un trop grand nombre ou trop peu de règles. Il y a également de diverses théories et métrique, telle que des mesures de complexité de McCabe. Elles devraient être maintenues dans l'esprit que l'utilisation excessive des normes et des règles peut suffoquer la productivité et la créativité. Les « examens par les pairs », « copain vérifie » des outils d'analyse de code, etc. peut être employé pour vérifier les problèmes et pour imposer des normes. Pour le codage de C et de C++, voici quelques idées typiques de considérer en fixant des règles/normes ; celles-ci peuvent ou peuvent ne pas s'appliquer à une situation particulière :
* Réduire au minimum ou éliminer l'utilisation des variables globales.
* Employer les noms descriptifs de fonction et de méthode - employer les deux la majuscule et minuscule, éviter les abréviations, employer autant de caractères selon les besoins pour être en juste proportion descriptif (l'utilisation de plus de 20 caractères n'est pas hors de ligne) ; être conformé en appelant des conventions.
* Employer les noms variables descriptifs - employer les deux la majuscule et minuscule, éviter les abréviations, employer autant de caractères selon les besoins pour être en juste proportion descriptif (l'utilisation de plus de 20 caractères n'est pas hors de ligne) ; être conformé en appelant des conventions.
* Des tailles de fonction et de méthode devraient être réduites au minimum ; moins de 100 lignes de code est bonne, moins de 50 lignes est préférable.
* Des descriptions de fonction devraient être clairement définies dans les commentaires précédant le code d'une fonction.
* Organiser le code pour la lisibilité.
* Employer le whitespace généreusement - verticalement et horizontalement.
* Chaque ligne de code devrait contenir 70 caractères maximaux.
* Un rapport de code par la ligne.
* Le modèle de codage devrait être à throught conformé par programme (par exemple, l'utilisation des parenthèses, des impressions, appelant des conventions, etc.)
* En ajoutant des commentaires, errer sur le côté d'un trop grand nombre plutôt que trop peu de commentaires ; un principe de base commun est qu'il devrait y avoir au moins autant de lignes des commentaires (blocs y compris d'en-tête) comme lignes de code.
* N'importe comment petite, une application devrait inclure documentaion de la fonction globale de programme et couler (même quelques paragraphes est meilleur que rien) ; ou si possible un organigramme séparé et une documentation détaillée de programme.
* Faire l'utilisation étendue des procédures de gestion d'erreur et de l'enregistrement de statut et d'erreurs.
* Pour C++, pour réduire au minimum la complexité et augmenter l'entretien, éviter trop de niveaux de la transmission dans des heirarchies de classe (relativement à la taille et à la complexité de l'application). Réduire au minimum l'utilisation de la transmission multiple, et réduire au minimum l'utilisation de la surcharge d'opérateur (note que le langage de programmation de Java élimine la transmission multiple et la surcharge d'opérateur.)
* Pour C++, les méthodes de classe de subsistance petites, moins de 50 lignes de code par méthode est préférable.
* Pour C++, faire l'utilisation libérale des traiteurs d'exception.
14.What est « bonne conception » ?
* * la « conception » pourrait se rapporter à beaucoup de choses, mais se rapporte souvent « à la conception fonctionnelle » ou « à la conception interne ». La bonne conception interne est indiquée près intègrent dans le logiciel dont la structure globale est claire, compréhensible, facilement modifiable, et maintenable ; est robuste avec des possibilités la notation suffisantes d'erreur-manipulation et de statut ; et travaux correctement une fois mis en application. La bonne conception fonctionnelle est indiquée par une application dont la fonctionnalité peut être tracée de nouveau aux exigences de client et d'utilisateur. Pour les programmes qui ont une interface utilisateur, c'est souvent une bonne idée de supposer que l'utilisateur aura peu de connaissance d'ordinateur et peut ne pas lire un manuel d'utilisateur ou même l'aide en ligne ; un certain règle-de-pouce commun incluent :
* Le programme devrait agir d'une manière cette moindres surprises l'utilisateur
* Il devrait toujours être évident à l'utilisateur ce qui peut être fait après et comment sortir
* Le programme ne devrait pas laisser les utilisateurs font quelque chose de stupide sans avertissement ils.
15.What est SEI ? CMM ? CMMI ? OIN ? IEEE ? Norme ANSI ? Aidera-t-elle ?
* SEI = « institut de technologie de la programmation » à l'université de carnegie-mellon ; lancé par le département de la défense des États-Unis pour aider à améliorer des procédés de développement de logiciel.
* CMM = « modèle de maturité de possibilités », maintenant appelé le CMMI (« intégration de modèle de maturité de possibilités »), développé par le SEI. C'est un modèle de 5 niveaux de « maturité » de processus qui déterminent l'efficacité en fournissant le logiciel de qualité. Il est adapté à de grands organismes tels que de grands entrepreneurs de département de la défense des États-Unis. Cependant, plusieurs des processus de QA impliqués sont appropriés à n'importe quelle organisation, et si raisonnablement appliqué peuvent être utiles. Les organismes peuvent recevoir les estimations CMMI en subissant des évaluations par les auditeurs qualifiés.
* Niveau 1 - caractérisé par chaos, périodique panique, et les efforts héroïques exigés par des individus pour accomplir avec succès des projets. Peu si tous processus en place ; les succès peuvent ne pas être qu'on peut répéter.
* Niveau 2 - le cheminement de projet de logiciel, la gestion de conditions, la planification réaliste, et les processus de gestion de configuration sont en place ; des pratiques réussies peuvent être répétées.
* Niveau 3 - des procédés de développement et d'entretien de logiciel standard sont intégrés dans toute une organisation ; un IS-IS de groupe de processus de technologie de la programmation en place pour surveiller des processus de logiciel, et des programmes de formation sont employés pour assurer l'arrangement et la conformité.
* Niveau 4 - la métrique est employée pour dépister la productivité, les processus, et les produits. L'exécution de projet est prévisible, et la qualité est uniformément haute.
* Niveau 5 - le foyer est sur l'amélioration de processus continouous. L'impact de nouveaux processus et technologies peut être prévu et efficacement mis en application une fois requis.
* Perspective sur CMM des estimations : Pendant 1997-2001, 1018 organismes ont été évalués. De ceux, 27% étaient évalués au niveau 1, 39% à 2, à 23% à 3, à 6% à 4, et à 5% à 5. (Pour des estimations pendant la période 1992-96, 62% étaient au niveau 1, 23% à 2, à 13% à 3, à 2% à 4, et à 0.4% à 5.) La taille médiane des organismes était 100 personnels de technologie/entretien de la programmation ; 32% d'organismes étaient les entrepreneurs fédéraux ou les agences des États-Unis. Pour ceux évalués au niveau 1, le secteur de processus principal le plus problématique était dans la garantie de la qualité de logiciel.
* OIN = « organisation internationale pour l'étalonnage » - la norme d'OIN 9001:2000 (qui remplace le niveau précédent de 1994) concerne les systèmes de qualité qui sont évalués par les auditeurs extérieurs, et eux s'applique à beaucoup de genres d'organismes de production et de fabrication, logiciel non simplement. Elle couvre des processus de documentation, de conception, de développement, de production, d'essai, d'installation, d'entretien, et autre. L'ensemble complet des normes se compose : (a) Q9001-2000 - Systèmes de gestion de qualité : Conditions ; (b) Q9000-2000 - Systèmes de gestion de qualité : Principes fondamentaux et vocabulaire ; (c) Q9004-2000 - Systèmes de gestion de qualité : Directives pour des améliorations d'exécution. Pour être OIN 9001 certifiée, un tiers auditeur évalue une organisation, et la certification est en général bonne pendant environ 3 années, après quoi une réévaluation complète est exigée. Noter que la certification d'OIN n'indique pas nécessairement des produits de qualité - elle indique seulement que des processus documentés sont suivis. Voir également le http://www.iso.ch/ pour la dernière information. Aux États-Unis les normes peuvent être achetées par l'intermédiaire du site Web d'ASQ chez http://e-standards.asq.org/
* IEEE = « institut des ingénieurs électroniciens électriques et » - entre autres, crée des normes telles que la « norme d'IEEE pour la documentation d'essai de logiciel » (norme 829 d'IEEE/ANSI), le 'niveau d'IEEE de l'essai d'unité de logiciel (norme 1008 d'IEEE/ANSI), la « norme d'IEEE pour des plans de garantie de la qualité de logiciel » (norme 730 d'IEEE/ANSI), et d'autres.
* Norme ANSI = « American National Standards Institute », l'organisme de normalisation industriels primaire aux États-Unis ; édite quelques normes logiciel-connexes en même temps que l'IEEE et l'ASQ (société américaine pour la qualité).
* D'autres méthodes d'évaluation de processus de gestion du logiciel development/IT sans compter que CMMI et OIN 9000 incluent l'ÉPICE, le Trillium, le TickIT, le circuit fermé, l'ITIL, le MOF, et le CobiT.
16.What le « logiciel est-il cycle de vie » ?
* Le cycle de vie commence quand une application est d'abord conçue et finit quand il n'est plus en service. Il inclut des aspects tels que le concept initial, analyse de conditions, conception fonctionnelle, conception interne, planification de documentation, planification d'essai, codage, préparation de documents, intégration, examinant, entretien, mises à jour, essayant de nouveau, les élimine, et d'autres aspects.
les outils de essai automatisés par 17.Will facilitent l'essai ?
* Probablement pour de petits projets, le temps nécessaire pour les apprendre et mettre en application peut ne pas le valoir la peine. Pour de plus grands projets, ou des projets à long terme en cours ils peuvent être valeur.
* Un type commun d'outil automatisé est le type de « disque/playback ». Par exemple, un appareil de contrôle a pu cliquer par toutes les combinaisons des choix de menu, des choix de zone de dialogue, des boutons, etc. dans un GUI d'application et faire « enregistrer » eux et les résultats être noté par un outil. Le « enregistrement » est typiquement sous forme de texte basé sur une langue scripting qui est interprétable par l'outil de essai. Si de nouveaux boutons sont ajoutés, ou un certain code fondamental dans l'application est changé, etc. l'application pourrait alors être essayé de nouveau juste « en jouant en arrière » les actions « enregistrées », et en comparant les résultats de notation aux effets de contrôle des changements. Le problème avec de tels outils est que s'il y a les changements continuels au système étant examiné, les « enregistrements » peuvent devoir être changés tellement qu'il devient très long pour mettre à jour sans interruption les manuscrits. En plus, l'interprétation et l'analyse des résultats (écrans, données, notations, etc.) peuvent être des difficiles chargent. Noter qu'il y a les outils record/playback pour les interfaces basées par texte également, et pour tous les types de plateformes.
* Un autre type commun d'approche pour l'automation de l'essai fonctionnel est l'essai automatisé « data-driven » ou « mot--conduit », dans lequel les conducteurs d'essai sont séparés des données et/ou des actions utilisées dans l'essai (une « action » serait quelque chose comme « écrivent une valeur dans une boîte des textes »). Les conducteurs d'essai peuvent être sous forme d'outils automatisés d'essai ou de logiciel de essai écrit sur demande. Les données et les actions peuvent plus facilement être maintenues - comme par l'intermédiaire d'un bilan - puisqu'elles sont séparé des conducteurs d'essai. Les conducteurs d'essai « ont lu » les données/information d'action pour réaliser les essais indiqués. Cette approche peut permettre une commande, un développement, une documentation, et un entretien plus efficaces des essais/des cas d'espèce automatisés.
* D'autres outils automatisés peuvent inclure :
* Des analyseurs de code - surveiller la complexité de code, l'adhérence aux normes, etc.
* Analyseurs d'assurance - ces outils vérifient quelles parties du code ont été exercées par un essai, et peuvent être orientés à l'assurance de rapport de code, à l'assurance de condition, à l'assurance de chemin, etc.
* Analyseurs de mémoire - tels que des bondir-contrôleurs et des détecteurs de fuite.
* Outils d'essai de charge/performance - pour des applications de essai de client/serveur et de Web sous de divers niveaux de charge.
* Outils d'essai de Web - pour vérifier que les liens sont valides, l'utilisation de code de HTML est correcte, client-côté et les programmes de serveur-côté fonctionnent, les interactions d'un site Web sont bloqués.
* D'autres outils - pour la gestion de cas d'espèce, la gestion de documentation, le reportage de bogue, et la gestion de configuration.
