Pruebas de Software Unidad 1-PS

Competencia: Reconocer la importancia de las pruebas para lograr la calidad del software identificando los conceptos claves de pruebas de software.

UNIDAD 1. FUNDAMENTOS DE PRUEBAS

1.1. Introduccin.

1.2. Las pruebas como un proceso.

1.3. Definiciones bsicas.

1.4. Principios para las pruebas del software.

1.5. El rol del ingeniero de pruebas.

1.6. Origen de los defectos.

1.6.1. Defectos en los requerimientos y la especificacin.

1.6.2. Defectos en el diseo.

1.6.3. Defectos en el cdigo.

1.7. Defectos en las pruebas

1.1. Introduccin El software es cada vez ms difcil de construir.

El software est jugando un papel importante en la sociedad, por lo que las personas con habilidades de desarrollo de software estn en demanda.

Existen nuevos mtodos, tcnicas y herramientas que estn disponibles para apoyar las tareas de desarrollo y mantenimiento del software.

Actualmente se exige a los desarrolladores un software de alta calidad.

1.1. Introduccin El desarrollador altamente calificado asegura que

sus productos de software se basan en el , dentro del , y son de la mejor

calidad con respecto a los atributos tales como la , , , y la capacidad

de con todos los requisitos de los usuarios.

1.1. Introduccin La ingeniera de software es una nueva disciplina

que se relaciona con otras disciplinas de la ingeniera , y tiene asociado un cuerpo definido de conocimientos , un cdigo de tica , y un proceso de certificacin.

1.1. Introduccin

Elementos de las disciplinas de ingeniera

1.1. Introduccin La IEEE y la ACM han unido fuerzas para definir un

cuerpo de conocimientos que debe adquirir la ingeniera de software y un cdigo de tica para el ingeniero de software.

1.1. Introduccin Un especialista de pruebas: Es quien tiene una educacin basada en

principios, prcticas y procesos que constituyen la ingeniera de software.

Se enfoca especficamente en las pruebas de software.

Est entrenado como un ingeniero que tiene los conocimientos de principios relacionados con las pruebas, procesos, mtricas, normas, planes, herramientas y mtodos.

1.1. Introduccin La necesidad en los productos de software de tener alta

calidad, por lo que presiona a los desarrolladores a identificar y cuantificar los factores de calidad tales como la usabilidad, capacidad de pruebas, mantenimiento y fiabilidad, y para identificar las prcticas de ingeniera que apoyan la produccin de software de calidad que tienen estos atributos.

1.1. Introduccin Proceso, en el dominio de la ingeniera de software, es

el conjunto de mtodos, prcticas, normas, documentos, actividades, polticas y procedimientos que los ingenieros de software utilizan para desarrollar y mantener un sistema y sus artefactos asociados, tales como los proyectos y planes de prueba, diseo documentos, cdigo, y manuales.

Componentes de un proceso de ingeniera

La mayora de los ingenieros de software estaran de acuerdo en que las pruebas son un componente vital de un proceso de software de calidad, y es una de las actividades ms difciles y costosas realizadas durante el desarrollo y mantenimiento de software.

A pesar de papel vital de las pruebas en la produccin de software de calidad, los modelos de evaluacin y mejora de procesos existentes, como el CMM, Bootstrap, e ISO-9000 no han abordado adecuadamente los problemas del proceso de pruebas.

El Modelo de Madurez de Pruebas (TMM), se ha desarrollado en el Instituto de Tecnologa Illinois por un grupo de investigacin, para subsanar las deficiencias de estas reas.

1.1 INTRODUCCIN Que es una prueba?

Que es un Software?

Es el conjunto de los programas de cmputo, procedimientos, reglas, documentacin y datos asociados que forman parte de las operaciones de un sistema de computacin.

http://search.babylon.com/imageres.php?iu=http://www.baluart.net/images/Introduccin-a-las-pruebas-unitarias-en-P_F7ED/pruebas-unitarias-php_thumb.jpg&ir=http://www.baluart.net/articulo/introduccion-a-las-pruebas-unitarias-en-php-con-phpunit&ig=http://t3.gstatic.com/images?q=tbn:ANd9GcRPzvA-n6wkFBzmEkkqb4ygCbYOuij3nPDZHOcEa7DJLinT4m5Bj85N3A&h=260&w=230&q=introduccion+a++las+pruebas+de+software&babsrc=HP_sshttp://search.babylon.com/imageres.php?iu=http://www.baluart.net/images/Introduccin-a-las-pruebas-unitarias-en-P_F7ED/pruebas-unitarias-php_thumb.jpg&ir=http://www.baluart.net/articulo/introduccion-a-las-pruebas-unitarias-en-php-con-phpunit&ig=http://t3.gstatic.com/images?q=tbn:ANd9GcRPzvA-n6wkFBzmEkkqb4ygCbYOuij3nPDZHOcEa7DJLinT4m5Bj85N3A&h=260&w=230&q=introduccion+a++las+pruebas+de+software&babsrc=HP_sshttp://search.babylon.com/imageres.php?iu=http://www.baluart.net/images/Introduccin-a-las-pruebas-unitarias-en-P_F7ED/pruebas-unitarias-php_thumb.jpg&ir=http://www.baluart.net/articulo/introduccion-a-las-pruebas-unitarias-en-php-con-phpunit&ig=http://t3.gstatic.com/images?q=tbn:ANd9GcRPzvA-n6wkFBzmEkkqb4ygCbYOuij3nPDZHOcEa7DJLinT4m5Bj85N3A&h=260&w=230&q=introduccion+a++las+pruebas+de+software&babsrc=HP_sshttp://search.babylon.com/imageres.php?iu=http://www.baluart.net/images/Introduccin-a-las-pruebas-unitarias-en-P_F7ED/pruebas-unitarias-php_thumb.jpg&ir=http://www.baluart.net/articulo/introduccion-a-las-pruebas-unitarias-en-php-con-phpunit&ig=http://t3.gstatic.com/images?q=tbn:ANd9GcRPzvA-n6wkFBzmEkkqb4ygCbYOuij3nPDZHOcEa7DJLinT4m5Bj85N3A&h=260&w=230&q=introduccion+a++las+pruebas+de+software&babsrc=HP_sshttp://search.babylon.com/imageres.php?iu=http://4.bp.blogspot.com/-U8lYLA7ZTag/T1YYiZ4C9UI/AAAAAAAADWg/tOKWHlZP_QU/s1600/evaluar.jpg&ir=http://crishopsicopedagogo.blogspot.com/&ig=http://t2.gstatic.com/images?q=tbn:ANd9GcT8vkaE0Wd3PDehYLEgczIhfg62TyZsQE9zf4Pm4PnwFC2spLPDyNdYjKQQ&h=480&w=425&q=pruebas&babsrc=HP_sshttp://search.babylon.com/imageres.php?iu=http://www.sinologic.net/blog/wp-content/uploads/2010/04/sino31.jpg&ir=http://www.sinologic.net/blog/2010-04/%C2%BFsoftware-libre-o-software-comercial/&ig=http://t2.gstatic.com/images?q=tbn:ANd9GcRwtm9FoGIUw7dUWOgvTNO2JhpQNNAywgVzGRL6MDTIL_zGzDNdlNyP36A&h=390&w=640&q=que+es+un+software&babsrc=HP_ss

El software como producto puede

tener defectos o fallas, desde el

momento de concebirlo y

modelarlo, durante su desarrollo y

despus de la puesta en

produccin de la aplicacin del

software

Las pruebas de software

corresponde a la necesidad de

garantizar un producto de calidad

Por qu es importante hacer pruebas de

software:

Sistema libre de errores

Eficiencia de la aplicacin

Aseguramiento de la calidad del software

Evaluacin de la flexibilidad del software construido

Misiones fallidas

Impacto inesperado en la ejecucin operacional

Falta de confiabilidad en casos de que no se ejecute acertadamente

1.2 Las pruebas como un proceso Las pruebas son parte esencial del proceso de

desarrollo del software. Esta parte del proceso tiene la funcin de detectar los errores de software lo antes posible.

Proceso de pruebas en el ciclo de vida de desarrollo de software

1.2 Las pruebas como un proceso Dentro del proceso de desarrollo de software se tienen

algunos procesos como las pruebas.

1.2 Las pruebas como un proceso

1

1

Validacin: Proceso de evaluar un sistema o

componente durante o al final del proceso de

desarrollo para determinar si satisface los

requisitos especificados.

Verificacin: Proceso de evaluar un sistema o

componente para determinar si los productos

de una determinada fase satisfacen las

condiciones impuestas al comienzo de la fase.

Se basa en la ejecucin de cdigo

Se basa en revisar los entregables del software

Procesos de validacin y verificacin

Estamos construyendo

el producto correcto?

Estamos construyendo el

producto correctamente?

Se ajusta a los

requisitos del cliente?

implementa correctamente

una funcin especfica?


Como un conjunto de procedimientos que se llevan a cabo para evaluar algn aspecto de un componente de software.

Como un proceso utilizado para revelar defectos en el software, y para establecer que el software ha alcanzado un grado especfico de calidad con respecto a los atributos seleccionados.

Definicin de pruebas:

Estas definiciones comprenden tanto actividades de validacin como de verificacin.


Estas definiciones:

Incluyen: revisiones tcnicas, planificacin de pruebas, seguimiento de pruebas, diseo de casos de prueba, pruebas unitarias, pruebas de integracin, pruebas del sistema, pruebas de aceptacin y las pruebas de usabilidad.

Describen las pruebas como un proceso de doble propsito, uno que revela los defectos, as como uno que se utiliza para evaluar los atributos de calidad del software como la fiabilidad, seguridad, facilidad de uso, y la correccin.


Tambin tenga en cuenta que las pruebas y depuracin son dos actividades muy diferentes.

El proceso de depuracin se inicia despus de la prueba se ha realizado y el probador ha sealado que el software no se est comportando como se especifica.

1.2 Las pruebas como un proceso Las Pruebas como un proceso tiene aspectos:

Econmicos

Tcnicos

Gestin.

1.2 Las pruebas como un proceso Aspectos Econmicos:

Estn relacionados con los recursos y tiempo disponibles para el grupo de pruebas.

En muchos casos las pruebas no se completan debido a estas limitaciones econmicas.

Una organizacin debe estructurar su proceso de

prueba para que pueda ofrecer software a tiempo y dentro del presupuesto, y tambin satisfacer las necesidades del cliente.

1.2 Las pruebas como un proceso Aspectos Tcnicos:

Estn relacionadas con las tcnicas, mtodos, mtricas y herramientas que se utilizan para asegurar que el software est libre de defectos y es fiable para las condiciones y limitaciones bajo las que debe funcionar.

1.2 Las pruebas como un proceso Aspectos de Gestin:

La prueba es un proceso, y como un proceso que debe administrado.

Significa que una poltica organizacional para la prueba debe ser definida y documentada.

Los procedimientos y fases de las pruebas deben ser definidos y documentados.

1.2 Las pruebas como un proceso Las pruebas deben ser planificadas, los Testers deben

ser entrenado, el proceso debera haber asociado metas cuantificables que pueden ser medidos y controlados.

Las pruebas como un proceso debe ser capaz de evolucionar a un nivel donde no se dispone de mecanismos para hacer mejoras continuas.

PRUEBAS DE SOFTWARE Las pruebas de software (testing en ingls) son los procesos que

permiten verificar y revelar la calidad de un producto software

antes de su puesta en marcha. Bsicamente, es una fase en el

desarrollo de software que consiste en probar las aplicaciones

construidas.

Las pruebas de software se integran dentro de las diferentes fases

del ciclo de vida del software dentro de la Ingeniera de software. En

este sentido, se ejecuta el aplicativo a probar y mediante tcnicas

experimentales se trata de descubrir qu errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas

o pruebas que permitan comprobar el grado de cumplimiento

respecto de las especificaciones iniciales del sistema

1.3. DEFINICIONES BSICAS

1.3. DEFINICIONES BSICAS Errors (errors)

Un error es un equivocacin, confusin o malentendido por parte de un desarrollador de software.

Desarrollador (Ingenieros de software, programadores, analistas y Testers).

Una accin del ser humano que produce un resultado

incorrecto.

Ejemplos: Notacin de diseo Tipo de variable asignado incorrectamente


Defectos (Faults)

Un defecto en el software es originado como el resultado de un error.

Es una anomala en el software que puede causar un comportamiento incorrecto, y no de acuerdo a su especificacin.


Defectos (Faults)

Son tambin llamados Bugs. Aunque este trmino trivializa el impacto de los defectos en la calidad de software.

El trmino de Defectos es tambin asociado con los artefactos del software como requerimientos y documentos de diseo.

1.3. DEFINICIONES BSICAS Fallas (Failures)

La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

Ejemplo:

Durante la ejecucin del sistema o componente se observa que produce los resultados esperados.


Fallas (Failures)

Cuando se tiene una falla en un sistema, indica que algn tipo de defecto est presente.

Un desarrollador con experiencia/Tester debe tener una base de conocimientos de los casos de defectos/sntomas/fallas.

1.3. DEFINICIONES BSICAS Fallas (Failures) El comportamiento incorrecto puede incluir:

La produccin de valores incorrectos en las variables de salida,

Una respuesta incorrecta por parte de un dispositivo,

Una imagen incorrecta en una pantalla.

NOTA: Las fallas se identifican por los Testers, y los defectos se localizan y se reparan por los desarrolladores.

Cuando el software est en operacin, los usuarios son quienes identifican las fallas.

Un fallo en el cdigo no siempre produce un fracaso.

Sin embargo, cuando se producen las condiciones adecuadas el fallo se manifestar como un fracaso: (Voas)

1. La entrada al software debe causar la declaracin defectuosa al ejecutarse.

2.El estado defectuoso debe producir un resultado diferente al correcto.

3.El estado interno incorrecta debe propagar a la salida, de modo que el resultado de la falla es observable.

La siguiente figura muestra la relacin entre error, defecto y fallo:

Figura 1.1: Relacin entre error, defecto y fallo

Caso de prueba (test case) Se define como: Un conjunto de entradas, condiciones de ejecucin y resultados esperados, diseados para un objetivo particular.

Tester y Aseguramiento de la calidad

El tester que prueba el software tiene como principal

funcin encontrar bugs, lo ms temprano posible, y

asegurarse de que sean arreglados.

La persona encargada del aseguramiento de la

calidad del software tiene como responsabilidad

principal crear y hacer cumplir los estndares y los

mtodos para mejorar el proceso de desarrollo y

prevenir que los bugs aparezcan.

Defecto (defect, fault, bug) Un defecto puede ser definido como:

Un paso, proceso o definicin de dato incorrecto en un programa de

computadora. El resultado de una equivocacin.

Una variacin de una caracterstica deseada del producto.

Un defecto puede dividirse en dos categoras:

Defectos en la especificacin del producto: el producto construido vara del producto especificado.

Variaciones en las expectativas del cliente/usuario: estas

variaciones son algo que el usuario quiere que no est en el producto final, pero stas adems no fueron especificadas para ser incluidas en el producto.

1.4. PRINCIPIOS PARA LAS PRUEBAS DEL SOFTWARE

1.4. PRINCIPIOS PARA LAS PRUEBAS DEL SOFTWARE Los principios proporcionan la base para el desarrollo

del conocimiento y la adquisicin de habilidades de las pruebas.

Proporcionan una gua para definir las actividades de pruebas.

1.4. PRINCIPIOS PARA LAS PRUEBAS DEL SOFTWARE Un principio se puede definir como:

1. Un general o fundamental, el derecho, la doctrina, o la presuncin;

2. Una regla o cdigo de conducta;

3. Las leyes o hechos de la naturaleza que se basa el funcionamiento de un dispositivo artificial.

1.4. PRINCIPIOS PARA LAS PRUEBAS DEL SOFTWARE En la ingeniera de software, los principios se refieren a

las leyes reglas o doctrinas que se relacionan con el software, cmo construirlos y cmo se comportan.

Pueden referirse a normas o cdigos de conducta relativos a los profesionales que disean, desarrollan, prueban y mantienen los sistemas.

Las pruebas como un componente de la ingeniera de software tambin tiene un conjunto de principios que sirven de gua para el Tester.

1.4. PRINCIPIOS PARA LAS PRUEBAS DEL SOFTWARE Glenford Myers fue el primero que seal una serie de principios de las pruebas de software en su libro El Arte de pruebas de software

Estos principios son mencionados con modificaciones realizadas para reflejar la evolucin de las pruebas.

Se refieren a las pruebas basadas en ejecucin.

1.4 Principios para las pruebas de software.

Principio 1: Las pruebas son el proceso de ejecutar un componente de

software usando un conjunto

seleccionado de casos de prueba, con

la intencin de:

(i) revelar defectos, y

(ii) evaluar la calidad.

Este principio apoya la prueba como una actividad basada en la ejecucin para detectar defectos.

El trmino "componente de software" se utiliza en este contexto para representar cualquier unidad de software.


Principio 2: Cuando el objetivo de la prueba es detectar defectos,

entonces un buen caso de prueba es

aquel que tiene una alta probabilidad

de revelar defecto(s) todava no

detectado(s).

Soporta el diseo cuidadoso de casos de pruebas El objetivo es detectar defectos.


Principio 3: Los resultados de la prueba deben ser examinados

minuciosamente.

Pueden producirse varios escenarios errneos y costosos si no se tiene cuidado. Un fallo puede ser pasado por alto. Un fallo puede sospecharse cuando en realidad no existe. El resultado de una prueba de calidad puede ser mal entendido.


Principio 4: Lo

El resto se trabajo en clase, lo encontrars en la plataforma.

1.5. El Rol del ingeniero de pruebas

El trabajo del Tester es:

Revelar defectos,

Encontrar puntos dbiles,

Encontrar comportamiento incoherente, y

Encontrar circunstancias en las que el software no funciona como se esperaba.

El Tester necesita para ser eficaz:

Una amplia experiencia en programacin con el fin de entender cmo se construye el cdigo, y dnde, y qu tipo de defectos es probable que se produzca.

Trabajar con los desarrolladores para producir software de alta calidad que cumple con los requisitos de los clientes.

Tienen que trabajar con ingenieros de requisitos para garantizar que los requisitos son comprobables, y planificar para el sistema y prueba de aceptacin.

El Tester necesita para ser eficaz: Probadores tambin tienen que trabajar con los

diseadores para planificar la integracin y la unidad de prueba.

Los administradores de las pruebas tendrn que cooperar con los administradores de proyectos con el fin de desarrollar planes de pruebas razonables, y con la alta gestin para proporcionar informacin para el desarrollo y mantenimiento de las normas de organizacin de pruebas, polticas y metas.

Tienen que cooperar con el personal de aseguramiento de la calidad del software y de los miembros de grupos de procesos de ingeniera de software.

Ejemplo: Si usted es empleado de una organizacin que se evala en los

niveles 1 o 2 del TMM, es posible que no existe una funcin de prueba de software independiente en su organizacin.

Los Testers, en este caso pueden ser parte del grupo de desarrollo, pero con una misin especial de pruebas, o pueden ser parte del grupo de calidad del software.

De hecho, incluso en los niveles 3 y superiores de la TMM los probadores no necesariamente pertenecen a una entidad organizativa independiente, a pesar de que es el caso ideal.

Sin embargo, los Testers siempre deben tener autonoma de gestin de los desarrolladores como se describe en el Principio 8, y en el TMM a nivel 3.

Los Testers son especialistas, su funcin principal es:

Planificar, ejecutar, registrar y analizar las pruebas.

No depurar software. Se asegura que lo haga el software.

Los Testers necesitan el apoyo de la direccin Los desarrolladores, analistas y personal de marketing

tienen que darse cuenta de que los Testers agregan valor a un producto de software en que se detectan defectos y evalan la calidad tan pronto como sea posible en el ciclo de vida del software.

Esto asegura que los desarrolladores liberan cdigo con pocos o sin defectos, y que los vendedores pueden ofrecer software que satisfaga los requisitos de los clientes, y es fiable, til y correcto.

Los Testers necesitan el apoyo de la direccin

Software con bajos o sin defectos tambin tiene la ventaja de reducir los costos, tales como las llamadas de soporte, reparacin de software operativo y la mala voluntad que puede derivar en acciones legales debido a la insatisfaccin de los clientes. En vista de su papel esencial, probadores necesita tener una visin positiva de su trabajo. La gerencia debe apoyarlos en sus esfuerzos y reconocer sus contribuciones a la organizacin.

Metafricamente, el tester es los ojos del cliente.

Habilidades del tester Un tester se caracteriza por los siguientes rasgos:

Buen juicio

Discreto y diplomtico

Persuasivo

Contar con el respeto de sus compaeros

Explorador

Implacable

Creativo

Perfeccionista

Buen nivel de conocimiento tcnico

Por qu probar lo ms temprano posible

Permite encontrar y resolver defectos tan pronto

como sea posible

Ayuda a reducir el riesgo de fracaso del proyecto

Ayuda a reducir los costos globales de desarrollo

Provee datos valiosos en la evaluacin de viabilidad

del proyecto

1.6. Origen de los defectos Defectos en los requerimientos y la especificacin.

Defectos en el diseo.

Defectos en el cdigo.

Defectos en las pruebas.

1.6 Origen de los defectos

Un defecto, en su sentido ms amplio, es una anomala en la especificacin, diseo o implementacin de un producto.

Introduccin

Es un defecto en la definicin de las necesidades del usuario para el sistema o componente.

Defectos en Especificaciones/Requerimientos

Defectos en Especificaciones/Requerimi

entos

El comienzo del ciclo de vida del software es crtico para garantizar un alta calidad en el software que esta siendo desarrollado. Los defectos incluidos en las primeras faces pueden persistir y ser muy difciles de eliminar en faces posteriores.

Desde que los documentos de requerimiento han sido escritos usando un lenguaje natural de representacin ha habido bastantes ocurrencias de ambigedad, contradiccin, redundancia y requerimientos imprecisos.

En muchas organizaciones, las especificaciones son tambin desarrolladas usando un lenguaje natural de representacin y esto tambin ha sido causa de los mismos problemas mencionados anteriormente.

A lo largo de los aos muchas organizaciones han introducido el uso de lenguajes de especificacin formales que, cuando son acompaados por herramientas, ayudan a prevenir descripciones incorrectas del comportamiento del sistema.

Descripcin mala de los requisitos del usuario

Requisitos o especificaciones

Caractersticas del sistema incorrectas o incompatibles

Funcionalidad

Especificaciones incorrectas sobre como el producto interacciona con el entorno

Interfaz de usuario, software y hardware

La total descripcin de lo que el producto hace y como debera comportarse, es incorrecta, ambigua, y/o incompleta.

Descripcin Funcional

Defectos de caractersticas:

Las caractersticas deberan ser descritas como caractersticas distintivas de un componente de software o sistema. Las caractersticas hacen referencia a los aspectos funcionales del software que asignan requerimientos funcionales como descritos por los usuarios y clientes. Las caractersticas tambin asignan requerimientos de calidad como desempeo y confiabilidad. Los defectos de caractersticas suceden debido a descripciones de caractersticas que son olvidadas, incorrectas, incompletas o superfluas.

Defectos en interaccin de las caractersticas:

Estos son debido a una incorrecta descripcin de como las caractersticas deberan interactuar. Por ejemplo, supongamos que una caracterstica de un sistema de software apoya la adicin de un nuevo cliente a una base de datos de clientes. Esta caracterstica interacta con otra que clasifica al nuevo cliente. La caracterstica de clasificacin impacta sobre donde coloca al nuevo cliente el algoritmo de almacenamiento y tambin afecta a otra caracterstica que peridicamente est enviando publicidad a una categora especifica de clientes. Cuando probemos, ciertamente queremos enfocarnos en la interaccin entre estas dos caractersticas.

Es muy importante detectar los defectos en los requisitos lo mas prontamente posible, ya que estos se acarrearn durante todo el proceso de desarrollo de software, lo cual puede conllevar grandes costos pues el proyecto tendr que ser reestructurado desde el comienzo y prcticamente tendr que iniciarse otra vez.

Por esto es muy necesario tener una buena comunicacin con el cliente y ser lo mas meticuloso posible para evitar que las necesidades del usuario no sean cumplidas o se haga trabajo de mas.

Conclusiones

1.6.1 DEFECTO DE DISEO

Introduccin Los defectos del diseo ocurren en los componentes

del sistema y sus interacciones con otros componentes del sistema y componentes de hardware/software de fuera. Estos defectos estan en el diseo de algoritmos, control, logica, etc

Causas Defectos de algoritmo y procesamiento

Defectos de control, lgica y secuencia

Defectos de datos

Defectos en la descripcin de mdulos de interfaz

Defectos de descripcin funcional

Defectos de descripcin para interfaces externas

Defectos de algoritmo y procesamiento Ocurre cuando los pasos de procesamiento en el

algoritmo son descritos de forma incorrecta

Defectos de control, lgica y secuencia

Ocurre cuando el flujo del seudocdigo es incorrecto dando paso a cdigo inalcanzable

Defectos de datos

Estn asociados a un mal diseo de la estructura de datos

Defectos en la descripcin de mdulos de interfaz

Se da por el uso de tipos inconsistentes de parmetros

Defectos de descripcin funcional

La descripcin del funcionamiento de los mdulos es errnea o incompleta

Defectos de descripcin para interfaces externas

La descripcin de componentes de sistemas externos a bases de datos es incorrecta

Conclusin Este tipo de defectos ocurren cuando los

componentes del sistema, la interaccin de los componentes entre ellos, con otros software, con el usuario estn mal diseados.

Estos defectos recaen en el diseo de algoritmos, lgica, control, datos y la descripcin del software/hardware/interfaz de usuario

1.6.2. Defectos en el cdigo

Defectos en el cdigo Introduccin

Qu es un defecto de cdigo?

Es la derivacin de un error en la implementacin del cdigo, los cuales estn estrechamente relacionados con el diseo de las clases sobre todo si se utiliza pseudocdigo para el diseo.

Principalmente los defectos de cdigo provienen de una mala comprensin del lenguaje de programacin y la falta de comunicacin entre los diseadores, tambin se da por transcripcin u omisin.

Defectos en el cdigo

Tipos de defectos en el cdigo 1.- Defectos algortmicos y de procesamiento.

Se incluyen desbordamiento sin control, comparacin de tipos de datos inadecuados, la conversin de un tipo de dato a otro, orden incorrecto de los operadores aritmticos, mal uso u omisin de parntesis y el uso incorrecto de signos.

Tipos de defectos en el cdigo 2.- Defectos de control, lgica y secuencia.

A nivel de cdigo pueden incluir expresiones incorrectas a causa de las declaraciones, iteraciones errneas de ciclos y rutas desaparecidas.

3.- Errores tipogrficos

Son principalmente errores de sintaxis, por ejemplo faltas de ortografa en los nombres de variables, usualmente detectados por el compilador y autorevisiones.

Tipos de defectos en el cdigo 4.- Defectos de inicializacin

Ocurren cuando se omiten declaraciones o son incorrectas. Puede ocurrir por malentendidos o falta de comunicacin entre programadores y/o programadores y diseadores, confusin en el entorno de programacin.

Tipos de defectos en el cdigo 5.- Defectos de flujo de datos

Hay ciertas secuencias operativas por las cuales los datos deben fluir. Por ejemplo, una variable debe ser inicializada antes de ser usada en un clculo o una condicin. No debe ser inicializada dos veces antes de que haya un uso intermedio. Por lo tanto, en el sentido ms estricto de la definicin del trmino defecto, no pueden considerarse como verdaderos casos defectos.

Tipos de defectos en el cdigo 6.- Defectos de datos

Estos surgen con una implementacin incorrecta de estructura de datos. Por ejemplo, el programador puede omitir un campo de un registro, o si el acceso se asigna a un archivo, una matriz, no se asignaron el nmero adecuado de elementos, etc. Otros defectos de datos incluyen indicadores, ndices y constantes configuradas incorrectamente.

1.6.3 Tipos de defectos en el cdigo Defectos de interfaz de mdulo

En el caso del diseo de los elementos del mdulo, los defectos de interface en el cdigo se deben al uso incorrecto o inconsistente del tipo de parmetro, un nmero incorrecto de parmetros . Adems de defectos debido a un diseo inadecuado, la aplicacin indebida del diseo. Los programadores pueden implementar una secuencia incorrecta de las llamadas o las llamadas a mdulos no existentes.

Tipos de defectos en el cdigo Defectos en la documentacin de cdigo

Cuando la documentacin del cdigo no refleja lo que el programa hace actualmente, o est incompleto o ambiguo. Los testers pueden ser engaados por los defectos en la documentacin y as reutilizar pruebas inadecuadas o diseo de nuevas pruebas que no son apropiadas para el cdigo. Las revisiones de cdigo son las mejores herramientas para detectar este tipo de defectos.

Tipos de defectos en el cdigo Defectos de hardware e interfaces de software

Estos defectos se deben a problemas relacionados con ajustes del sistema, enlaces a bases de datos, secuencias de entrada/salida, uso de memoria, uso de recursos etc.

Documents

Pruebas de Software Unidad 1-PS