Fase de Construccion
El objetivo de la fase de Construcción consiste en desarrollar el
sistema hasta el punto en que está listo para la pre-producción de
pruebas. En las etapas anteriores, la mayoría de los requisitos han
sido identificados y la arquitectura del sistema se ha establecido. El
énfasis es priorizar y comprender los requerimientos, modelado que ataca una solución y, a luego, la codificación y las pruebas del software. Si es necesario, las primeras versiones del sistema se desarrollan, ya sea interna o externamente, para obtener los comentarios de los usuarios.
Flujos de Trabajo (RUP)
Un
flujo de trabajo es una secuencia de actividades que producen un
resultado de valor observable. Los flujos RUP tienen nombres parecidos a
los de las etapas del desarrollo de cascada, pero pueden usarse tanto
en procesos de cascada como en procesos iterativos.
En esencia, un flujo de trabajo es un algoritmo, y por lo tanto se puede representar de muchas formas, desde diagramas de flujo hasta diagramas de secuencia o de actividades UML. Es común usar diagramas de actividades.
No todas las actividades deben o pueden ser diagramadas, pero de acuerdo a la metodología RUP hay flujos de trabajo particularmente importantes que deben representarse siempre que sea posible. Estos se llaman "flujos de trabajo de procesos núcleo" y se dividen en seis flujos de "ingeniería" y tres flujos de "apoyo":
En esencia, un flujo de trabajo es un algoritmo, y por lo tanto se puede representar de muchas formas, desde diagramas de flujo hasta diagramas de secuencia o de actividades UML. Es común usar diagramas de actividades.
No todas las actividades deben o pueden ser diagramadas, pero de acuerdo a la metodología RUP hay flujos de trabajo particularmente importantes que deben representarse siempre que sea posible. Estos se llaman "flujos de trabajo de procesos núcleo" y se dividen en seis flujos de "ingeniería" y tres flujos de "apoyo":
WebML: Web Modeling Language
― Modelado orientado a aplicaciones con un uso intensivo de
datos, donde hay gran cantidad de datos, con estructura
compleja y las aplicaciones tienen que acceder a ellos
● Modelado de aplicación Web en 4 fases:
― Modelo de datos
― Modelo de hipertexto
― Modelo de gestión de contenido
― Modelo de presentación
Modelo de hipertexto
Un modelo por cada hipertexto
● Cada hipertexto describe una vista del sitio
― Modelo de composición. Representa las páginas de un hipertexto
y cada página que elementos de contenido tiene
― Modelo de navegación. Representa los enlaces entre las
diferentes páginas y sus elementos de contenido
Elementos de contenido de cada página
― Unidades de datos. Dan la información de un solo objeto de
datos. Ejemplo: de una actividad
― Multi-datos. Dan información de varios objetos de datos
― Indice. Da la lista de varios objetos, pero sin mostrar la
información de dichos objetos
― Filtro. Da una página de búsqueda donde se pueden poner
diferentes parámetros para buscar según unos criterios
― Scroller. Da un conjunto de elementos que se puede avanzar
entre ellos con scroll
Computacion de una paguina
La verdad esto se Clasifica en 2 casos una llamada configuracion estatica y otra dinamica
Estatica Significa que es un portal directo del servidor que solo es mostrado y amenos que sea modificado no podra agregar o quitar nada de este.
Dinamico viene a ser una constante iteraccion fijense en el caso de este blog seria una web dinamica cada vez que yo suba una nueva entrada o nuevo contenido esta sera modificada por su efecto y mostrara nueva informacion en cada nueva carga.
Codificacion de Caracter
Es de hecho quiza una de las caracteristicas mas comunes actualmente en web los mas conocidos son Html y Xhtml el código fuente de un documento XHTML contiene el código XHTML necesario para que el navegador interprete y renderize la estructura del documento. La fuente del documento es texto plano y ese texto, se lo haya planteado alguna vez o no, sigue una determinada codificación de caracteres,
que no tiene porqué ser la misma (y lo mas seguro es que no lo sea) que
la codificación de caracteres que utilizan aquellos que utilizan
lenguajes como el chino, el hebreo o el árabe.
Pruebas de interacción
(caja blanca y caja negra).
(caja blanca y caja negra).
Caja Blanca de sistemas
Es un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo.
Es un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo.
Esta prueba se dirige especificamente a reparar los requisitos internos o necesarios para el funcionamiento se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados.
Al estar basadas en una implementación concreta, si esta se modifica, por regla general las pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles —unidad, integración y sistema—, habitualmente se aplican a las unidades de software.
Su cometido es comprobar los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden probar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema.
A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.
Caja negra
Las pruebas de caja negra, también denominadas por el ISTQB como técnicas basadas en especificación, son una forma de derivar y seleccionar condiciones, datos y casos de prueba a partir de la documentación de requerimientos del sistema.
Las pruebas de caja negra no utilizan ninguna información interna de los componentes de software o sistemas que se van a probar, sino que consideran el comportamiento del software desde el punto de vista de un observador externo (.Como los usuarios del sistema).
En este articulo, te presentamos información sobre que son las pruebas de caja negra, las pruebas funcionales y sus principales técnicas, como son las particiones de equivalencias, análisis de valores borde, tablas de decisión, transición entre estados, pruebas de casos de uso e historias de usuario.
También comentamos sobre las pruebas de caja negra en Agile Testing y los conocimientos que se necesitan para poderlas ejecutar.
Pruebas de caja negra y pruebas funcionales
En los estándares para Software Testing definidos por ISTQB, las técnicas de pruebas de caja negra son utilizadas para realizar pruebas funcionales, basadas en las funciones o características del sistema y su interacción con otros sistemas o componentes.Las funciones del software son descritas en los documentos de especificación funcional. Se pueden utilizar técnicas basadas en especificación para identificar las condiciones y casos de prueba a partir de la funcionalidad del software.