¿Detalles de cómo realizar pruebas de aceptación de proyectos de subcontratación?0?3Cómo realizar pruebas de aceptación de proyectos de subcontratación Con los cambios en la tecnología y el entorno del mercado actual, cada vez más empresas optan por subcontratar. proyectos de software, y empresas de software a gran escala más maduras se han sumado a las filas de la contratación de proyectos de software. Cada vez hay más proyectos de software subcontratados, y cómo realizar pruebas de aceptación en estos proyectos subcontratados se está convirtiendo cada vez más en un problema clave al que se enfrentan las empresas. La idea general de las pruebas de aceptación del usuario Las pruebas de aceptación del usuario son la última actividad de inspección de calidad después de que se completa el desarrollo del software y antes de que el usuario ingrese a la aplicación real del producto de software. Lo que quiere responder es si el producto de software desarrollado cumple con los requisitos esperados y si puede ser aceptado por los usuarios. Debido a que no se trata solo de una inspección de la calidad de un determinado aspecto del software, sino de una inspección de calidad integral y la determinación de si el software está calificado, las pruebas de aceptación son una actividad de prueba formal estricta. Debe probarse en función de planes prediseñados, revisiones de configuración de software, pruebas funcionales, pruebas de rendimiento, etc. Las pruebas de aceptación del usuario se pueden dividir en dos partes: revisión de la configuración del software y prueba del programa ejecutable. La secuencia general se puede dividir en: revisión del documento, revisión del código fuente, revisión del script de configuración, revisión del programa de prueba o script y prueba del programa ejecutable. Cabe señalar que antes de que los desarrolladores envíen el software a los usuarios para las pruebas de aceptación, deben asegurarse de que los propios desarrolladores hayan realizado suficientes pruebas formales de todos los aspectos del software (por supuesto, "adecuado" en sí mismo es difícil de cuantificar con precisión). De acuerdo con el contrato, el usuario recibe y cuenta la información enviada por el desarrollador (incluidas las enviadas previamente), verifica si los diversos informes de auditoría y de prueba proporcionados por el desarrollador están completos y, junto con la comprensión habitual del desarrollo del desarrollador. trabajo, básicamente se puede hacer una evaluación preliminar para determinar si el desarrollador ha realizado suficientes pruebas formales. Cada parte relativamente independiente de la prueba de aceptación del usuario debe tener objetivos (el propósito de este paso), criterios de inicio (las condiciones que deben cumplirse para iniciar este paso), actividades (las actividades específicas que constituyen este paso) y criterios de finalización ( cumplir con los requisitos para completar este paso, condiciones de los pasos) y métricas (datos de productos y procesos que deben recopilarse). Recopilar datos de métricas durante las pruebas de aceptación reales no es una tarea fácil. Revisión de la configuración del software Para proyectos de software subcontratados, los contratistas de software generalmente deben proporcionar el siguiente contenido de configuración de software relacionado: Programas ejecutables, programas fuente, scripts de configuración, programas de prueba o scripts. .Principales documentos de desarrollo: instrucciones de análisis de requisitos, instrucciones de diseño general, instrucciones de diseño detalladas, instrucciones de diseño de bases de datos, planes de prueba, informes de prueba, manuales de mantenimiento de programas, manuales de desarrollo de programadores, manuales de operación del usuario e informes resumidos del proyecto. .Principales documentos de gestión: plan de proyecto, plan de control de calidad, plan de gestión de configuración, plan de formación de usuarios, informe resumen de calidad, informe de revisión, actas de reuniones, informe mensual de progreso de desarrollo. Entre los documentos de desarrollo, los documentos que se pasan por alto fácilmente son el "Manual de mantenimiento del programa" y el "Manual de desarrollo del programador". El contenido principal del Manual de mantenimiento del programa incluye: descripción del sistema (incluida la descripción del programa), entorno operativo, proceso de mantenimiento, lista de códigos fuente, etc. Este manual ha sido escrito para proporcionar información técnica útil para futuros trabajos de mantenimiento, modificación y redesarrollo. Los contenidos principales del "Manual de desarrollo del programador" incluyen: objetivos del sistema, instrucciones para usar el entorno de desarrollo, instrucciones para usar el entorno de prueba, estándares de codificación y procesos correspondientes, etc. En realidad, es un manual de formación para programadores. Los proyectos de diferentes tamaños deben tener el contenido de los documentos anteriores, pero pueden reorganizarse según las condiciones reales. Para los documentos presentados anteriormente, es mejor estipular claramente el tiempo de la etapa de presentación en el contrato para evitar disputas. Normalmente, el proceso de auditoría formal se divide en cinco pasos: planificación, reunión preliminar (opcional), fase de preparación, reunión de revisión y seguimiento de problemas. Se utiliza una reunión preparatoria para presentar y discutir el contenido de la revisión. La fase de preparación es donde la parte responsable revisa y documenta los problemas identificados de antemano. Las reuniones de revisión se utilizan para finalizar errores y defectos en el producto del trabajo. El objetivo básico de la auditoría es descubrir tantos problemas como sea posible en el contenido que se está auditando y finalmente resolver estos problemas de acuerdo con el *** y el formulario de auditoría establecido. Al realizar la revisión de documentos y la revisión del código fuente de acuerdo con el formulario de revisión correspondiente, también debe prestar atención a la coherencia del documento y el código fuente. En la implementación real de las pruebas de aceptación, a menudo se encuentra que la revisión de documentos es la tarea más difícil. Por un lado, debido a la presión de diversos aspectos, como la demanda del mercado, este trabajo a menudo se debilita o retrasa, lo que resulta en un documento más largo. tiempo de revisión y mayor Esto reduce la dificultad de la revisión de documentos, por otro lado, hay muchas cosas que son difíciles de comprender en la revisión de documentos. Cada proyecto tiene algunas características especiales y también es difícil encontrar materiales de referencia disponibles.
Una vez completadas con éxito la revisión del documento, la revisión del código fuente, la revisión del script de configuración, el programa de prueba o la revisión del script, se puede llevar a cabo el paso final de la prueba de aceptación: la prueba del programa ejecutable, incluida la funcionalidad, el rendimiento, etc. También incluye cinco partes: objetivos, estándares de inicio, actividades, estándares de finalización y mediciones. Cada prueba también incluye cinco partes: objetivos, criterios de inicio, actividades, criterios de finalización y métricas. Vale la pena señalar que el programa ejecutable proporcionado por el desarrollador no se puede utilizar directamente para realizar pruebas, sino que debe regenerarse a partir del código fuente siguiendo los pasos de compilación proporcionados por el desarrollador. Antes de realizar realmente las pruebas de aceptación del usuario, generalmente se debe completar el siguiente trabajo (también se puede adoptar o agregar selectivamente según la situación real): Se completó el desarrollo del software y se resolvieron todos los defectos de software conocidos. .El plan de pruebas de aceptación ha sido revisado, aprobado y puesto bajo control documental. .Se ha completado la revisión de las especificaciones de requisitos de software. .Se ha completado la revisión del diseño general y del diseño detallado. .Revisión completa del código de todos los módulos críticos. .Revisión completa de planes e informes de pruebas de unidad, integración y sistema. .Todos los scripts de prueba se completan, ejecutan y revisan al menos una vez. .Con las herramientas de gestión de configuración, el código está bajo control de configuración. .Existen procedimientos de manejo de problemas de software. Se han desarrollado, revisado y aprobado criterios de finalización de la prueba de aceptación. Las pruebas específicas generalmente incluyen: instalación (actualización), inicio y apagado, pruebas funcionales (ejemplos positivos, algoritmos clave, límites, sincronización, contraejemplos, manejo de errores), pruebas de rendimiento (carga normal, cambios de capacidad), pruebas de estrés (carga crítica, capacidad). cambios), pruebas de configuración, pruebas de plataforma, pruebas de seguridad, pruebas de recuperación (si el sistema puede funcionar normalmente en caso de cortes de energía, fallas o cambios de hardware, fallas de red, etc.), pruebas de confiabilidad, etc. (Si el sistema puede funcionar normalmente en caso de corte de energía, falla o conmutación de hardware, falla de red, etc.), pruebas de confiabilidad, etc. Las pruebas de rendimiento y las pruebas de estrés suelen realizarse juntas, a menudo con el apoyo de herramientas auxiliares. Al realizar pruebas de rendimiento y estrés, el alcance de las pruebas debe limitarse a un subconjunto de funcionalidades de software de uso frecuente y en el que el tiempo es crítico. Dado que los desarrolladores ya han realizado pruebas de rendimiento y estrés, las herramientas del desarrollador se pueden utilizar directamente. También puedes comprar o desarrollar tus propias herramientas. Para conocer métodos de prueba específicos, consulte los libros de ingeniería de software relevantes.