Lista de Verificacion Software
August 12, 2022 | Author: Anonymous | Category: N/A
Short Description
Download Lista de Verificacion Software...
Description
LISTA DE SOFTWARE:
VERIFICACION
1.- Introducción: Verifcación es el conjunto acvidades aseguran el soware implemente correctamente una unciónde específca y la que Validación es que un conjunto dierente de acvidades que aseguran que el soware construido corresponde y sasace los requisitos del cliente. La verifcación y la validación abarcan una amplia lista de acvidades de aseguramiento de la calidad del soware, estas incluyen: Revisiones técnicas ormales, auditorias de calidad, simulación, acbilidad, revisión de documentación, y pruebas de diversos pos. Verifcación y Validación:
Verifcación: El papel de la verifcación comprende comprobar que el soware está de
acuerdo con su especifcación. Se comprueba que el sistema cumple los requerimientos uncionales y no uncionales que se le han especifcado. Validación: La validación es un proceso más general. Se debe asegurar que el Soware cumple las expectavas del cliente. Va más allá de comprobar si el sistema está acorde con su especifcación, para probar que el soware hace lo que el usuario espera a dierencia de lo que se ha especifcado. Importante: Nunca se va a poder demostrar que el soware está completamente libre de deectos.
El objevo de este tema es introducir la verifcación y validación del soware con énasis en las técnicas de verifcación estáca y en la prueba dinámica de código. Objevo de este tema son: -
Compre Comprende nderr la diere dierenci nciaa entre entre verifc verifcaci ación ón y validac validación ión del del soware soware.. Valorar Valorar la inspección inspección del soware soware y el análisis análisis estáco estáco como como métodos métodos de descub descubrir rir allos y mejorar la calidad del soware. Conoce Conocerr las técn técnica icass de prue pruebas bas para para desc descubr ubrir ir allo alloss en el código código.. Analizar Analizar las las técnica técnicass eespecí specífcas fcas para las pruebas pruebas de componente componentess y pruebas pruebas de de sistemas orientados a objetos. Importanci Importanciaa de las herramient herramientas as CASE CASE para para la la verifcaci verifcación ón de de sowar sowaree y apoyar apoyar el desarrollo de las pruebas.
2.- Técnicas de Verificación y Validación:
-
Inspecciones del Soware: Se analiza analizan n las dierente dierentess represe representacio ntaciones nes del del sistem sistemaa (diagram (diagramas as de requerimi requerimientos entos,, diagramas de diseño y código uente) en búsqueda de deectos. Son técnicas técnicas de de validaci validación ón estác estácas as => => No No requier requieren en que que el el código código se ejecu ejecute te De Debe be realiz realizars arsee duran durante te todo todo el el ciclo ciclo de desarr desarroll ollo. o. Pruebas del Soware:
Se contras contrasta ta dinámica dinámicament mentee la respue respuesta sta de de protopo protoposs ejecuta ejecutables bles del sistem sistemaa con el comportamiento operacional esperado.
-
Técnic Técnicas as de de valida validación ción dinámi dinámicas cas => El El si siste stema ma se se ejecu ejecuta. ta. Requiere Requiere disponer disponer de proto protopo po ejecut ejecutable ables, s, por por lo que sólo pueden pueden ulizarse ulizarse en ciertas ases del proceso.
3.- Verificación y validación estática y dinámica: Las inspecciones de soware se pueden ulizar en todas las etapas del proceso, mientras que las técnicas de prueba sólo se pueden cuando está disponible un protopo o código ejecutable. Las técnicas de inspección incluyen inspección de programas, análisis automazado de código uente y verifcación ormal. Sin embargo, las técnicas estácas sólo pueden comprobar la correspondencia entre un programa y su especifcación (verifcación) y no puede probar que el soware es de ulidad operacional, y mucho menos que las caracteríscas no uncionales del soware son las correctas. Por lo tanto, para validar un sistema de soware, siempre se requieren llevar a cabo ciertas pruebas. Aunque en la actualidad las inspecciones se ulizan ampliamente, las pruebas de los programas es aún la técnica de verifcación y validación predominante.
4.- Proceso de depuración:
-
Proceso que localiza y corrige los errores descubiertos durante la verifcación y validación. Es un un proceso proceso complicado complicado pues no siempr siempree los errores errores se se detectan detectan cerca del punto punto en que se generaron. Se uliz ulizan an herra herramie mienta ntass de depu depurac ración ión,, que acili acilitan tan el el proces proceso. o. Después de reparar el error, hay que volver a probar el sistema (pruebas de regresión). La solu solución ción del prim primer er all allo o puede puede dar luga lugarr a nuevo nuevoss allo allos. s.
5.- Inspecciones del software:
-
Consisten en revisiones sistemácas tanto de los documentos generados como de los códigos uentes con el único objevo de detectar allos. Las inspeccion inspecciones es se se puede pueden n aplicar aplicar a la detección detección de allos allos en cualquiera cualquiera de los documentos generados. Permiten Permiten detectar detectar entre entre un 60 y un 90% de de los allos allos a unos unos costes costes mucho más bajos que las pruebas dinámicas. Permiten Permiten detectar detectar múlples múlples deect deectos os en en una una simple simple inspección, inspección, mientras mientras que las pruebas solo suelen detectar un allo por prueba. Permiten Permiten ulizar ulizar el conocimient conocimiento o del dominio dominio y del lenguaje, lenguaje, que determina determinan n los principales pos de allos que se suelen cometer. Las inspe inspeccione ccioness son úles para detectar detectar los los allos allos de módulos, módulos, pero no detecta detectan n allos allos a nivel de sistema, que ha de hacerse con pruebas. Las inspe inspeccione ccioness no son úles úles para la detección detección de nivele niveless de fabilidad fabilidad y evaluación evaluación de de allos no uncionales.
6.- Lista de fallos: El proceso de inspección siempre se realiza ulizando una lista de los errores comunes de los programadores. Esta se somete a discusión por el personal con experiencia y se actualiza recuentemente según se vaya teniendo experiencia. La lista de errores debe ser unción del lenguaje de programación que se ulice. Por ejemplo, un compilador Ada comprueba que las unciones enen el número correcto de argumentos, mientras que C no. Muchos de los allos en C enen relación con los punteros, estos no se pueden producir en Java. La candad de código que se puede inspeccionar debe estar limitado, ya que a parr de un empo de
inspección se baja la atención y se hace inefcaz. Existen estudios que establecen que no deberían examinarse más de 125 líneas de código por sesión, y no más de 2 horas.
7.- Inspección del código fuente: Análisis estático automatizado:
-
-
Los analizadores estácos de programas son herramientas de soware que rastrean el texto uente de un programa, en busca de errores no detectados por el compilador. En algunos lenguajes de programación no son muy úles pues el compilador orece una gran inormación acerca de posibles errores (incluso en ejecución). Aspectos habitualmente analizados son: Análisis Análisis de de ujo ujo de control: control: Idenfca Idenfca y señala señala los bucles bucles con múlples múlples puntos puntos de salida salida y las secciones de código no alcanzable. Análisis Análisis de uliza ulización ción de datos: Señala Señala como como se ulizan ulizan las variables variables del programa: programa: Variables sin ulización previa, que se declaran dos veces, declaradas y nunca ulizadas. Condiciones lógicas con valor invariante, etc. Análisis Análisis de de interac interaces: es: Verifca Verifca la declarac declaración ión de las operac operaciones iones y su invocación. invocación. Esto es inúl en lenguajes con pado uerte (Java, Ada) pero si en los restantes (C no comprueba los parámetros de una operación). Análisis Análisis de la la trayecto trayectoria: ria: Idenf Idenfca ca todas todas las posibles posibles trayectoria trayectoriass del del program programaa y presenta las sentencias ejecutadas en cada trayectoria. Debe ulizarse siempre junto a inspecciones directas del código, pues existen errores que no pueden detectar, por ejemplo, la inicialización de una variable a un valor incorrecto.
Los analizadores estácos de programas son herramientas de soware que rastrean el texto uente de un programa y detecta los allos y anomalías. No requieren que el programa se ejecute, más bien, analizan sintáccamente el código uente e idenfca las dierentes sentencias que conene. Después puede detectar si las sentencias están bien ormadas, hacer inerencias sobre los ujos de control, y de los valores que se asignan a las variables.
8.- Pruebas del software: Las pruebas se realizan en cuatro etapas:
Prueba de unidades (prueba de métodos y clases) c lases) se prueba prueba cada cada métod método o y clas clasee de de orma orma indepe independi ndient ente. e. Prueba de integración o de subsistemas. se pru prueb eban an agru agrupa pacio cione ness de clas clases es rela relaci cion onad adas as Prueba de sistema. se pr prue ueba ba el sist sistem emaa ccom omo o un un ttod odo. o. Prueba de validación (o de aceptación) prueba prueba del del sistema sistema en el entorno entorno real real de trabajo trabajo con con interven intervención ción del del usuari usuario o fnal. fnal. El descubrimiento de un deecto en una etapa requerirá la repeción de las etapas de prueba anteriores.
A excepción de programas pequeños, los sistemas no se prueban como una unidad monolíca. Los sistemas se construyen a parr de subsistemas, que a su vez están se construyen a parr de módulos que están compuestos de operaciones y unciones. Por tanto, el proceso de prueba se lleva a cabo en etapas en las que las pruebas se aplican de orma incremental, en conjunto con la implementación del sistema.
9.- Tipos de pruebas del software: Existen dos pos dierentes de pruebas:
Las pruebas de deectos: - Bu Busca scan n las inco inconsi nsiste stenci ncias as entr entree un prog program ramaa y su espe especifc cifcación ación.. - Las prueba pruebass se diseñan diseñan para para busca buscarr lo loss error errores es en en el códi código. go. - De Demue muestr stran an la la prese presenci ncia, a, y no la la ause ausenci ncia, a, de de deec deectos tos.. Las pruebas estadíscas: - Bu Busca scan n demost demostrar rar que que sas sasace ace la espec especifc ifcación ación op opera eracion cional al y su fabili fabilidad dad.. - Se diseña diseñan n para para reeja reejarr la carga carga de tr traba abajo jo habi habitua tual. l. - Sus resultados resultados se proces procesan an estadís estadíscame camente nte para esmar esmar ssu u fabilida fabilidad d (contand (contando o el número de caídas del sistema) y sus empos de respuesta. Las pruebas de deectos: Pretenden encontrar las inconsistencias entre un programa y su especifcación. Estas inconsistencias se deben habitualmente a los allos o deectos en el código del programa. Las pruebas se diseñan para revelar la presencia de deectos en el sistema, más que para evaluar su capacidad operacional. Las pruebas estadíscas: se ulizan para probar el desempeño y la fabilidad del programa y comprobar cómo trabaja bajo condiciones operacionales. Las pruebas se diseñan para reejar las entradas de los usuarios y su recuencia. Después de llevar a cabo las pruebas, se puede hacer una esmación de la fabilidad operacional del sistema contando el número de caídas observadas en el sistema. La capacidad del programa se valora midiendo el empo de ejecución y el empo de respuesta del sistema cuando procesa los datos estadíscos de la prueba. No existe una separación clara entre estos dos pos de pruebas. Durante las pruebas de deectos los desarrolladores obenen una visión intuiva de la fabilidad, y durante las pruebas estadíscas, se descubren obviamente muchos allos.
10.- Pruebas funcionales (“Caja negra”)
Las pruebas uncionales o de caja negras es una políca de selección de casos de pruebas basado en la especifcación del componente o programa. Las pruebas se seleccionan en unción de la especifcación y no de la estructura interna del soware.
Las pruebas uncionales o de caja negra son una estrategia para seleccionar las pruebas de allos basándose en las especifcaciones de los componentes y programas, y no del conocimiento de su implementación. El sistema se considera como una caja negra cuyo comportamiento sólo se puede determinar estudiando las entradas y de contrastarlas con las respuestas que proporciona el sistema. Este enoque se puede aplicar de igual orma a los sistemas que están organizados como librerías de unciones, o como objetos. El probador introduce las entradas en los componentes del sistema y examina las salidas correspondientes. Si las salidas no son las previstas, entonces la prueba ha detectado exitosamente un allo en el soware.
11.- Particiones de equivalencia:
En general es imposible probar un método con todas las combinaciones posibles de entradas Clasifcar los datos de entrada en grupos que enen un comportamiento similar respecto de la lógica de programa.
Una parción de equivalencia es cada grupo de datos de entrada que generan igual respuesta cualitava. Los casos de pruebas se eligen en unción de las parciones: - Se eli elige ge un caso caso cent central ral por parció parción: n: Caso Caso ttípi ípico. co. - Se elige elige casos correspond correspondient ientes es a las ront ronteras eras con otras otras parciones parciones:: casos casos atípicos. atípicos. Las parciones se idenfcan ulizando la especifcación del programa o la documentación del usuario.
Los datos de entrada a un programa se pueden clasifcar en dierentes clases, de acuerdo con la uncionalidad del programa. Los datos de un mismo grupo enen un tratamiento similar por parte del programa. Un enoque sistemáco para las pruebas de deectos se basa en idenfcar todas las parciones de equivalencia y basar en ellas las pruebas de allos. Una vez idenfcado un conjunto de parciones, se eligen los casos de prueba de cada una de estas parciones. Un buen criterio de selección de los casos de prueba es elegir dichos casos de los límites de las parciones junto con casos cercanos al punto medio de la parción. Con ello, se consideran los casos picos para los programadores que son los que enen un tratamiento lejano a las decisiones de control crícas, c rícas, y valores apicos que son los que enen un tratamiento próximo a los casos en que se cambian de tratamiento.
12.- Pruebas estructurales (“Caja blanca”)
En las pruebas estructurales las pruebas se seleccionan en unción del conocimiento que se ene de la implementación del módulo. Se suelen aplicar a módulos pequeños. El probador analiza el código y deduce cuántos y qué conjuntos de valores de entrada han de probarse para que al menos se ejecute una vez cada sentencia del código. Se pueden refnar los casos de prueba que se idenfcan con pruebas de caja negra.
13.- Pruebas de integración:
Se prueban la respuesta de grupos de módulos interconectados a fn de detectar allos resultantes de la interacción entre los componentes. Las pruebas de integración se realizan con reerencia a las especifcaciones del programa. La principal difcultad de las pruebas de integración es la localización de los allos. Para acilitar la detección de los errores se ulizan técnicas incrementales.
CONCLUSIONES • Las acciones correspondientes a la calidad de soware que se estaban llevando a cabo eran acciones aisladas no contempladas en un plan ormal. Esto se daba, principalmente, por el tamaño del departamento de Desarrollo de Sistemas, pues no se trata de una compañía c ompañía desarrolladora de soware. • El aseguramiento de calidad de soware se podía trabajar, dentro de cada una de las acvidades de desarrollo, de la siguiente manera: — Realizando una revisión por pares para cada c ada proyecto. — Haciendo seguimiento ormal a los proyectos, no sólo en empos y costos, sino en cumplimiento con estándares y metodología de desarrollo de soware. — Consolidando la metodología de desarrollo de soware en busca de alcanzar niveles superiores de madurez. — Involucrando puntos de chequeo y pruebas de soware. — Desarrollando estándares muy concretos para programación e interase de usuario. • Los objevos básicos de las inspecciones son: — Encontrar errores lo más temprano posible en el ciclo de desarrollo. — Asegurar que todos los parcipantes están de acuerdo en la parte técnica del trabajo. — Verifcar que el trabajo cumple con los criterios preestablecidos. — Completar ormalmente una tarea técnica.
— Suministrar inormación sobre el producto y el proceso de inspección. • Como benefcios secundarios de las inspecciones se destacan: — Asegurar que las personas asociadas estén amiliarizadas técnicamente con el producto. — Ayudar a crear un equipo técnico eecvo. — Ayudar a ulizar los mejores talentos de la organización. — Ayudar a los parcipantes a desarrollar sus habilidades como revisores. • Vale la pena hacer una disnción entre los dierentes pos de revisiones que se pueden llevar a cabo durante el proceso de desarrollo, teniendo en cuenta que las inspecciones son tan sólo un po: — Revisiones gerenciales: Buscan asegurar el progreso, recomendar acciones correcvas y asegurar el suministro adecuado de recursos. — Revisiones técnicas: Evalúan el cumplimiento de especifcaciones y planes y aseguran la integridad de los cambios. — Inspecciones de soware: Buscan detectar e idenfcar deectos y verifcar resoluciones. — “Walkthrough”: Buscan detectar deectos, examinar alternavas y ser un oro para el aprendizaje • Para toda prueba debe haber un plan que incluye: — Objevos para cada ase de prueba. — Cronograma y responsabilidades para cada acvidad de prueba. — Disponibilidad de herramientas, documentación y librerías de prueba. — Procedimientos y estándares a ser ulizados para planear y llevar a cabo las pruebas y reportar los resultados. — Criterios para determinar si la prueba está completa, como también el éxito de cada prueba. • Después de tener el plan de pruebas, se deben generar los casos de prueba, siguiendo cualquier técnica de prueba. • Cada caso de prueba se debe ejecutar y al fnal debe quedar un reporte de las pruebas con la siguiente inormación: — Proyecto y programas que se están probando, objevo de la prueba y el plan de pruebas. — Responsables y parcipantes de las pruebas. — Casos de prueba. — Herramientas especiales ulizadas. — Confguraciones de hardware y soware ulizadas.
— Resultados de las pruebas. — Idenfcación de los elementos que quedan en la librería de pruebas. — Firma de los responsables de las pruebas y cerfcación de Etapa Inspecciones Revisiones técnicas Requerimientos detallados iniciales Planeación Planes de desarrollo Desarrollo Diseño detallado Diseño del sistema Codifcación Diseño de alto nivel Publicaciones Publicaciones en borrador Publicaciones fnales Pruebas Implementación de pruebas 128 SISTEMAS & TELEMÁTICA que se siguió el procedimiento apropiado. • Como parte del reporte del proceso de pruebas, es deseable clasifcar los errores encontrados, con el fn de tomar correcvos en el proceso de prueba o retroalimentación para los desarrolladores. • Las pruebas deben ser analizadas teniendo en cuenta: — Los errores graves encontrados deben ser analizados en grupo, para hallar soluciones y maneras de que no vuelvan a ocurrir. — Analizar el po de error más recuente y revisar qué ocurren y cómo se pueden mejorar las inspecciones. — Revisar la eecvidad de las pruebas y reorzar aquellas que más errores detectan. — Los métodos y herramientas de prueba a emplear pueden ser cualquiera, siempre y cuando se ulicen dentro de un plan de pruebas. • Uno de los benefcios de las autoevaluaciones es que los analistas/programadores pueden sugerir mejoras dentro de todo el proceso de desarrollo de soware, para así incrementar su calidad y producvidad en el trabajo
View more...
Comments
