La actividad de construcción abarca una serie de tareas de codificación y realización de pruebas que conducen al software operativo que está listo para entregarlo al cliente o usuario final. En el trabajo de la ingeniería del software moderna la codificación puede ser
 
En un libro clásico sobre las pruebas realizadas al software, Glen Myers [MYE79] establece una serie de reglas que bien pueden servir como objetivos de las pruebas: Las pruebas consisten en un proceso en el que se ejecuta un programa con la intención de encontrar un error que aún no se descubre. Un buen caso de prueba es aquel en el que hay una gran probabilidad de encontrar un error que aún no se descubre. Una prueba exitosa es aquella que encuentra un error que aún no se descubría. En un libro clásico sobre las pruebas realizadas al software, Glen Myers [MYE79] establece una serie de reglas que bien pueden servir como objetivos de las pruebas:
Principio  #1: Todas las pruebas deben ser rastreables hasta los requisitos del cliente.  El objetivo de las pruebas realizadas al software es descubrir errores.  Principio  #1: Todas las pruebas deben ser rastreables hasta los requisitos del cliente.   El objetivo de las pruebas realizadas al software es descubrir errores.  Principio #2: Las pruebas se deben planear mucho antes de que comience el proceso de prueba.  La planeación de las pruebas puede comenzar tan pronto como el modelo de análisis esté completo. La definición detallada de los casos de prueba puede comenzar en cuanto el modeló de diseño haya sido solidificado.  Principio #3: El principio de Pareto es aplicable para las pruebas de software.  Para establecerlo de manera simple, el principio de Pareto implica que 80 por ciento de los errores descubiertos durante las pruebas con probabilidad serán rastreables hasta 20 por ciento de todos los programas. Principio #4: Las pruebas deben comenzar "en lo pequeño" y progresar hacia "lo grande".  Las primeras pruebas que se planean y ejecutan, por lo general, se enfocan en los componentes individuales. Principio #5: Las pruebas exhaustivas no son posibles.  El número de permutaciones entre las rutas, incluso de un programa con un tamaño moderado, es excepcionalmente grande. Por esta razón es imposible ejecutar cada combinación de rutas para las pruebas.

Más contenido relacionado

PPTX
Pruebas de documentacion
PPTX
Dllo proy software
PPTX
Neirobis arreaza ing. sotfware 2013
PPTX
Diseno de casos_de_prueba_erick_silva_p
PPTX
PPTX
Cap5 l1
PPTX
PPTX
las fases del proceso de programacion
Pruebas de documentacion
Dllo proy software
Neirobis arreaza ing. sotfware 2013
Diseno de casos_de_prueba_erick_silva_p
Cap5 l1
las fases del proceso de programacion

La actualidad más candente (20)

PPTX
SQM Verification and Validation
PPTX
Herramientasde oficio(clase3.1)
PPTX
Pi3 2
DOCX
Mapa conceptual fases en el desarrollo de un programa
PPTX
PI3 - segundo entregable
DOCX
modelos de ciclos de vidas "fases"
PPT
057 Testing Y Pensar Que Me Habian Dicho
PPTX
Nachihernandez mapamental
DOCX
PPT
Continuos Delivery Commit stage
PDF
Testing automatizado de aplicaciones web
ODP
Metodologia XP fases y subfases
PDF
Prueba
PPTX
Desarrollo de proyectos de software
PDF
Liquid Day - DevOps y Xamarin
PDF
#HablemosDeTestingDay - José Castillo: Estrategia de QA en un contexto de DevOps
DOCX
Técnicas de programación
PPTX
Pruebas y Mantenimiento de Sistemas Archivo
SQM Verification and Validation
Herramientasde oficio(clase3.1)
Pi3 2
Mapa conceptual fases en el desarrollo de un programa
PI3 - segundo entregable
modelos de ciclos de vidas "fases"
057 Testing Y Pensar Que Me Habian Dicho
Nachihernandez mapamental
Continuos Delivery Commit stage
Testing automatizado de aplicaciones web
Metodologia XP fases y subfases
Prueba
Desarrollo de proyectos de software
Liquid Day - DevOps y Xamarin
#HablemosDeTestingDay - José Castillo: Estrategia de QA en un contexto de DevOps
Técnicas de programación
Pruebas y Mantenimiento de Sistemas Archivo
Publicidad

Similar a Practica de construccion (20)

PDF
Material de lectura QA Program----------
PPTX
PPTX
PDF
Fundamentos Rational Tester
PDF
Capitulo 17 estrategias_de_prueba_de_software
PPT
Pruebas De Software
PPTX
Practicas de construccioin
PPTX
3. practicas de construccioin jessi roc
PPTX
Pruebas
DOCX
Resumen QA----------------------------------------------
PDF
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
PDF
6.redes pruebas de software
PPT
Estrategias prueba de software
PPTX
INDUCCION A QA TESTER.pptx
PPT
Pracicas de Ingenieria de Software
PPT
La Práctica : Una visión general
PPT
La Práctica : Una visión general
PPTX
Exposición software.pptx
PPTX
Exposición software.pptx
PPTX
Desarrollo de Software Guiado por Pruebas
Material de lectura QA Program----------
Fundamentos Rational Tester
Capitulo 17 estrategias_de_prueba_de_software
Pruebas De Software
Practicas de construccioin
3. practicas de construccioin jessi roc
Pruebas
Resumen QA----------------------------------------------
PRINCIPIOS BÁSICOS DE CONSTRUCCIÓN DE SOFTWARE Y TRATAMIENTO DE EXCEPCIONES
6.redes pruebas de software
Estrategias prueba de software
INDUCCION A QA TESTER.pptx
Pracicas de Ingenieria de Software
La Práctica : Una visión general
La Práctica : Una visión general
Exposición software.pptx
Exposición software.pptx
Desarrollo de Software Guiado por Pruebas
Publicidad

Practica de construccion

  • 1.  
  • 2. La actividad de construcción abarca una serie de tareas de codificación y realización de pruebas que conducen al software operativo que está listo para entregarlo al cliente o usuario final. En el trabajo de la ingeniería del software moderna la codificación puede ser
  • 3.  
  • 4. En un libro clásico sobre las pruebas realizadas al software, Glen Myers [MYE79] establece una serie de reglas que bien pueden servir como objetivos de las pruebas: Las pruebas consisten en un proceso en el que se ejecuta un programa con la intención de encontrar un error que aún no se descubre. Un buen caso de prueba es aquel en el que hay una gran probabilidad de encontrar un error que aún no se descubre. Una prueba exitosa es aquella que encuentra un error que aún no se descubría. En un libro clásico sobre las pruebas realizadas al software, Glen Myers [MYE79] establece una serie de reglas que bien pueden servir como objetivos de las pruebas:
  • 5. Principio #1: Todas las pruebas deben ser rastreables hasta los requisitos del cliente. El objetivo de las pruebas realizadas al software es descubrir errores. Principio #1: Todas las pruebas deben ser rastreables hasta los requisitos del cliente. El objetivo de las pruebas realizadas al software es descubrir errores. Principio #2: Las pruebas se deben planear mucho antes de que comience el proceso de prueba. La planeación de las pruebas puede comenzar tan pronto como el modelo de análisis esté completo. La definición detallada de los casos de prueba puede comenzar en cuanto el modeló de diseño haya sido solidificado. Principio #3: El principio de Pareto es aplicable para las pruebas de software. Para establecerlo de manera simple, el principio de Pareto implica que 80 por ciento de los errores descubiertos durante las pruebas con probabilidad serán rastreables hasta 20 por ciento de todos los programas. Principio #4: Las pruebas deben comenzar "en lo pequeño" y progresar hacia "lo grande". Las primeras pruebas que se planean y ejecutan, por lo general, se enfocan en los componentes individuales. Principio #5: Las pruebas exhaustivas no son posibles. El número de permutaciones entre las rutas, incluso de un programa con un tamaño moderado, es excepcionalmente grande. Por esta razón es imposible ejecutar cada combinación de rutas para las pruebas.