System funcional de software o hardware está Pruebas realizadas en un sistema completo e integrado para evaluar el cumplimiento del sistema. Cae dentro del alcance de las pruebas de caja Negro, y debe requerir ningún conocimiento del diseño interno del código o logic.System pruebas de tomas, como entrada, todos los componentes de software "integrados" que han pasado con éxito las pruebas de integración y el propio sistema de software integrado con cualquier sistema (s) de hardware aplicable .El propósito de las pruebas de integración es detectar cualquier inconsistencia entre las unidades de software que se integran entre sí o entre cualquiera de las pruebas assemblages.System es un tipo más limitante de la prueba; se busca detectar defectos tanto dentro de los "inter-conjuntos" y también dentro del sistema en su conjunto. pruebas de software basado en sus necesidades funcionales. Asegura que el programa funciona físicamente la manera que se esperaba y todas las opciones de menú necesarios están presentes. También asegura que el programa se ajusta a los estándares de la industria correspondientes a ese entorno; por ejemplo, en un programa de Windows, pulsando F1 trae ayuda. Prueba de funcionamiento es generalmente la primera fase de pruebas de que una organización de pruebas es responsable de cualquier liberación durante dado. Requisitos de prueba de función basados es una aproximación a la función de prueba - se trata de un enfoque de pruebas potente y eficaz, lo que reducirá significativamente el número de defectos no detectados (fallos) que se liberan en la producción. La premisa es que un conjunto bien formulada de requisitos funcionales dar la prueba a los diseñadores bases definitivas de caso de prueba se design.What prueba de función? El objetivo de las pruebas de función es medir la calidad de los componentes funcionales del sistema. Pruebas verifican comporta correctamente por parte del usuario /punto de vista de negocio y funciones de acuerdo a los requisitos, modelos, guiones gráficos, o cualquier otro paradigma de diseño utilizado para especificar la aplicación. La prueba de funcionamiento debe determinar componente o evento de negocios: lleva a cabo de conformidad con las especificaciones, responde correctamente a todas las condiciones que pueden presentar los eventos /datos de entrada, se mueve correctamente los datos de un evento de negocios a la siguiente (incluidos los almacenes de datos), y que eventos de negocios se inician en el orden necesario para cumplir los objetivos de negocio de la system.What es un requisito? un requisito es una capacidad o función que debe ser entregado por un componente o componentes del sistema. Una necesidad de negocio específica o comportamiento visto por un usuario externo del sistema. Un ciclo de pruebas eficaz debe tener un conjunto definido de procesos y resultados. Los procesos primarios entregables para los requisitos de Prueba de funcionamiento basados son: Planificación de prueba, Partición /Funcional de descomposición, RequirementsDefinition /Verificación, caso de prueba de diseño, rastreabilidad (trazabilidad Matrix), caso de prueba ejecución, gestión de defectos y análisis de cobertura. ¿Qué procesos y los resultados se aplican a cualquier situación de prueba dada dependen de los recursos disponibles (personas, materiales básicos, el tiempo, etc.) y el mandato de la organización del ensayo. planificación de las pruebas durante la planificación de la punta de prueba con la asistencia del equipo de pruebas define el alcance, cronograma, y los resultados finales para el ciclo de prueba de funcionamiento. El cable de prueba ofrece un plan de pruebas (documentos) y un programa de ensayo - éstas a menudo se someten a varias revisiones durante el ciclo de prueba. Partitioning - descomposición funcional de un sistema es la descomposición de un sistema en sus componentes funcionales o zonas funcionales. Otro grupo en la organización puede asumir la responsabilidad de la descomposición funcional (o modelo) del sistema, pero la organización de pruebas todavía debe revisar esta entrega esté completo antes de aceptarlo en la prueba organization.If no se han definido la descomposición funcional o particiones o están consideradas insuficientes entonces la organización de pruebas tendrá que asumir la responsabilidad de crear y mantener las particiones. Hay varios comerciales, shareware y productos gratuitos disponibles que ayudan en la descomposición funcional de un sistema y la entrega formal de la definición partitions.RequirementsVerificationRequirements funcional es a menudo el más débil se puede entregar en el proceso de desarrollo de software. Muchas tiendas de desarrollo van directamente del concepto de software con las especificaciones funcionales o peor desde el concepto de software de código sin ningún entregables preliminares de diseño de software. La organización de pruebas necesita estos requisitos para proceder con la prueba de la función, por lo que si el equipo de desarrollo no va a entregar los requisitos para la verificación por parte del equipo de pruebas a continuación, el equipo de pruebas debe crear su propio conjunto de requisitos comprobables. Estos requisitos deben ser detallados en los diseños funcionales apropiados prueba Diseñador /Tester partition.Test Caso design.The e implementa los casos de prueba para validar los productos lleva a cabo de conformidad con los requisitos (ver .Testing y el papel de un probador Diseñador de pruebas.) . Estos casos de prueba deben ser detallados en la partición funcional apropiado y cartografiado /remontado a los requisitos que son tested.Traceability (matriz de seguimiento) casos de prueba deben ser rastreado /asignada de nuevo a los requisitos correspondientes. Una vez que todos los aspectos de un requisito han sido probados por uno o más casos de prueba a continuación, la actividad de diseño de prueba para que ese requisito se puede considerar complete.A error común realizado durante este proceso es que todos los casos de prueba que ejercen un requisito particular se debe asignar a ese requerimiento - sólo los casos de prueba que se crean específicamente para probar un requisito debe ser rastreado a ese requisito. Este enfoque da una imagen mucho más precisa de la aplicación cuando se realiza el análisis de la cobertura - fallo de un caso de prueba no significa el fracaso de todos los requisitos ejercidas (en contraposición a prueba por) la prueba case.Test Caso ExecutionAs en todas las fases de las pruebas el conjunto apropiado de casos de prueba necesita ser ejecutado y los resultados de esos casos de prueba registra. ¿Qué casos de prueba deben ser ejecutadas deben ser definidos en el contexto del plan de pruebas y el estado actual de la aplicación que se está probando. Si el estado actual de la aplicación no es compatible con la prueba de uno o más requisitos a continuación, esta prueba debe aplazarse hasta que lo haga justificar el gasto de los recursos de las pruebas. gestión de defectos en todas las fases de pruebas de los defectos detectados durante la ejecución de la prueba tiene que ser inscrito y gestionado por la organización de pruebas. Durante la prueba de función cada defecto debe atribuirse a un requisito o requisitos específicos que no están funcionando según las especificaciones. Análisis de cobertura durante la función de prueba de un informe periódico debe ser entregado por la organización de prueba para el equipo del proyecto. Las bases de este informe será un análisis de la cobertura de los requisitos contra los casos de prueba y excelente objetivo defects.The es determinar el porcentaje de los requisitos que se: considerados como no probada, la realización de la especificación (ejecutado con éxito), y que no cumpla las especificación (defectos) .Hay varias comercial, shareware y productos gratuitos disponibles que se pueden utilizar para acelerar la creación de todas estas prestaciones al tiempo que agiliza las pruebas de función de prueba process.Managing puede ser una tarea abrumadora para las pruebas de una asociación sin experiencia. Para asegurar el éxito en la organización de pruebas y de proyecto alcance del esfuerzo de prueba necesita ser cuidadosamente definido y seguido. Definición del objeto necesita ser entendido por la organización de la prueba y el equipo del proyecto - si el alcance del esfuerzo de prueba necesita ser redefinido entonces esto debe ser communicated.A plan de trabajo realista con resultados claros y dependencias debe ser redactado y actualizado cuando cualquier caso se produce impactos que el plan de trabajo de una manera positiva o negativa. La clave del éxito es la gestión de las expectativas del equipo de pruebas y el equipo del proyecto, mientras que la comunicación clara de la situación actual del esfuerzo de pruebas en las bases en curso.