jeudi 8 novembre 2012
Prendre la décision de Automatisez votre Software Testing
Pas tous les tests de logiciels de projet peut ou doit être automatisé. Avant votre département accepte un nouveau projet de test d'automatisation, vous devez établir un processus par lequel les projets sont examinés et acceptés ou rejetés. Cela peut être fait avec une liste de contrôle d'essai d'acceptation Automation simple.
Cas de test reproductibles avec des données statiques
L'avantage coût réel de l'automatisation des tests sont obtenus que lorsque les mêmes scripts sont exécutés plusieurs fois. La première exécution est très coûteuse, car elle inclut le coût d'un moment de les outils d'automatisation et 100% du temps de l'ingénieur en automatisation des tests de. Lorsque les scripts sont exécutés à nouveau, le coût de l'automatisation des tests diminue fortement. L'outil a déjà été acheté et les scripts ont déjà été codés. S'il ya eu des changements dans l'application, les scripts peuvent nécessiter un entretien avant d'être exécuté. Entretien des mises à jour logicielles mineures devraient être minimes.
Parce que l'automatisation des tests n'est efficace que lorsque les scripts peuvent être exécutés à plusieurs reprises, que l'application qui exigent les mêmes cas de test doit être exécuté avec les mêmes données sont de bons candidats pour l'automatisation. Par exemple, une demande de prêt hypothécaire qui doit être tests de régression sur une base hebdomadaire pourrait être un bon candidat pour l'automatisation des tests. L'entretien de script est minime et les scripts peuvent entrer dans une demande de prêt hypothécaire en utilisant le même groupe de données de test en une fraction du temps qu'il faudrait un testeur manuel pour tester la même fonctionnalité.
D'autre part, un système de montage de prêts hypothécaires, qui ne peuvent pas utiliser les mêmes données de test pour chaque itération ne serait pas un candidat automatisation bonne. En raison de la nature des systèmes de prêts hypothécaires, les données pourraient être mis en scène dans divers états de l'approbation ou le rejet, sur la base des données actuelles et les départements qui ont déjà transformé leur partie de la demande de prêt hypothécaire. Si le script ne peut pas facilement déterminer quelles sont les données à entrer dans le logiciel, il n'est pas un candidat automatisation bonne.
Un autre problème avec l'automatisation de ce type de système complexe, c'est que l'environnement de test contient souvent un échantillonnage des données de production qui est actualisé sur une base périodique. Parfois, cela peut être surmonté par la reconstruction des données de test lorsque l'environnement de test est actualisé. La faisabilité de la reconstruction de données d'essai sur une base régulière dépend de la complexité de l'application. Vous aurez à prendre cette décision au cas par cas.
Application ou la stabilité de l'environnement
La stabilité de l'environnement est crucial pour un succès d'automatiser un projet de tests de logiciels. Les scripts peuvent pas être codées en temps opportun si l'environnement de l'application n'est pas disponible, l'expérience fréquente les temps d'arrêt, ou des défauts et des erreurs excessives.
Demande peu ou pas de temps d'arrêt pour l'environnement
Il prend plus de temps pour écrire des scripts qu'il n'en faut pour tester manuellement la même fonctionnalité. La plupart des outils d'automatisation sont édulcoré version de C ou Visual Basic, ce qui signifie que l'écriture de scripts automatisés est essentiellement la programmation et prend du temps et des compétences spécialisées. Contrairement aux cas de test manuel, ce qui peut parfois être écrite sur la base des exigences hors et maquettes, des outils automatisés exigent l'application effective. Quand un environnement de test n'est pas disponible, les ingénieurs d'automatisation ne peut pas créer des scripts, ce qui prolonge le projet et finit par coûter plus cher.
Les temps d'arrêt excessive peut consister en un des éléments suivants:
Environnement instable
Manque de soutien de l'infrastructure
Mises à jour des applications fréquentes
Code de Buggy
Effets de l'instabilité de l'environnement sur le développement de script et d'exécution
Quand une application ou l'environnement est instable, les progrès de script est considérablement ralentie ou arrêtée complètement. Dans certains cas, il est possible de continuer le script, mais cela peut provoque plus de travail à une date ultérieure. Par exemple, si vous êtes dans les scripts du code bogué, vous devrez peut-être un script autour de messages d'erreur et les scripts ne doivent être révisées à une date ultérieure. Ou, vous ne pouvez être en mesure de créer des scripts à un certain point et les terminer à une date ultérieure. Pour aider à éviter et à diminuer l'instabilité environnement, lire le chapitre sur les accords de niveau de service.
Corrections en temps opportun
Défauts d'application ne doit pas être préjudiciable à un projet de test logiciel automatisé. Lorsque des défauts sont fixés en temps opportun, les scripts peuvent continuer sans interruption de service importante. Lors de l'estimation d'un projet de test automatisé, il est toujours préférable d'ajouter un peu de temps tampon qui va accueillir pour la notification des défauts et des révisions.
Lorsque certaines corrections prendre une quantité excessive de temps à résoudre et sont à l'origine le projet de logiciel de test automatisé d'être retardée, il est temps de rassembler une réunion. Inviter tous les principaux acteurs et de discuter de la racine du problème et ce que chacun peut améliorer la situation. Peut-être que le développement est passer trop de temps en essayant de reproduire le problème et d'avoir votre équipe d'automatisation entrer meilleure description serait de les aider à transformer le défaut fixe déplacer plus rapidement. Peut-être que vous pouvez travailler ensemble pour classer les défauts et établir des délais raisonnables fix pour chaque classification. Par exemple, un défaut critique doit être fixé ce jour-là tout en haut d'un défaut qui doit être corrigé avec en 24 heures.
Personne de contact réactif
Lorsque votre équipe prend un projet de test automatisé, vous aurez besoin d'un interlocuteur. Cette personne est responsable de s'assurer que vous avez des besoins de l'entreprise et répondre aux questions sur la façon dont l'application fonctionne. Ce ne sera pas son emploi principal, de sorte que vous devrez faire en sorte qu'il ou elle est sensible. Si vous ne pouvez pas obtenir les exigences opérationnelles adéquates, données d'essais, ou répond aux questions, votre projet d'automatisation ne sera pas couronnée de succès.
. Danna Henderson. ....
Inscription à :
Publier les commentaires (Atom)
Aucun commentaire:
Enregistrer un commentaire