¿Qué incluye la gestión de proyectos ERP?
Las pruebas de aceptación son una prueba de validez o prueba de calificación. Está orientado al usuario e involucra a desarrolladores, implementadores y personal de control de calidad de software. ERP (Enterprise Resource Planning) es una poderosa herramienta para mejorar las capacidades de innovación de la gestión empresarial. Sus procesos de definición, diseño, desarrollo, implementación y aplicación siguen ciertas reglas. Estas leyes se reflejan en el control de procesos de software, el aseguramiento de la calidad y las pruebas de software. Las pruebas de aceptación están relacionadas con si el ERP puede aceptarse con éxito, si puede ingresar al período de mantenimiento sin problemas y si puede obtener beneficios rápidamente. La amplitud, eficiencia, cientificidad, estandarización y minuciosidad de las pruebas de aceptación de ERP siguen siendo un tema completamente nuevo para las empresas manufactureras y los proveedores de software ERP.
Actualmente, muchas personas tienen algunos malentendidos sobre las pruebas de aceptación de ERP:
(1) Debido a la complejidad y escala del software ERP, las personas pueden prestar más atención a su definición cambiante de requisitos. Soluciones personalizadas y procesos de desarrollo personalizados, ignorando la aceptación del proyecto. La consecuencia más directa de estas prácticas de "centrarse sólo en el inicio y el proceso, pero no en el final y el mantenimiento" es la formación de proyectos retrasados o proyectos "inconclusos".
(2) Se completa la implementación del ERP, la empresa usuaria puede ejecutar el sistema, se entregan los documentos y el cliente ha firmado. ¿Cuáles son los requisitos para las pruebas de aceptación? Este malentendido surge de una falta de comprensión del propósito, el proceso, los métodos y la importancia de las pruebas de aceptación.
(3) Las pruebas de aceptación son asunto de la empresa usuaria y no tienen nada que ver con el proveedor del servicio de software. De hecho, sólo si los dos trabajan en estrecha colaboración se puede mejorar la eficiencia de las pruebas.
(4) Entender las pruebas de aceptación como una demostración a los usuarios. Las pruebas de aceptación deben prestar atención a la estrategia y no pueden seguir los movimientos. Deben llevar a cabo actividades de manera planificada y paso a paso y llevar a cabo un diseño de casos de uso científico.
(5) Las pruebas de aceptación sirven para verificar la corrección del software. Las pruebas de aceptación, al igual que otras pruebas, no sólo verifican la corrección del software, sino que también encuentran errores de software. Pero las pruebas de aceptación sirven principalmente para confirmar si las funciones del software cumplen con los requisitos.
2. Principios del método y proceso de prueba de aceptación de ERP
El software incluye programas, datos y documentos. Los objetivos de las pruebas de aceptación de ERP deben cubrir estos tres aspectos. El sujeto de las pruebas de aceptación debe ser la empresa usuaria, y el proveedor de servicios de software ERP debe cooperar activamente y aún debe basarse en pruebas de terceros, con usuarios y proveedores de software * * * cooperando entre sí;
El proceso básico de las pruebas de aceptación de ERP se muestra en la siguiente figura. Los implementadores de software deben cooperar con los usuarios e instarlos a prepararse para las pruebas de aceptación de manera oportuna, realizar las pruebas de aceptación paso a paso según lo planeado, formar documentos de prueba estandarizados, analizar y evaluar objetivamente los resultados de las pruebas y rastrear fenómenos no calificados. Los problemas de software deben gestionarse en categorías jerárquicas y se deben realizar pruebas de regresión cuando sea necesario para garantizar que todos los problemas puedan cerrarse y finalmente pasar la aceptación.
En cuanto a los métodos de prueba, debido a la particularidad de la fase de aceptación, las pruebas de caja negra y la revisión de la configuración son generalmente las principales, complementadas con pruebas automáticas y pruebas especiales de rendimiento, con la participación de los usuarios, el software desarrolladores y personal de control de calidad.
Las pruebas de aceptación de ERP deben prestar atención a los siguientes principios:
(1) Las pruebas de aceptación siempre deben basarse en las especificaciones de requisitos de ERP y los contratos técnicos confirmados por ambas partes para confirmar si todos Se cumplen los requisitos y si se ejecutan todos los términos del contrato.
(2) Las pruebas de aceptación son diferentes de las pruebas unitarias y de las pruebas de integración. Se centra en verificar la corrección del software en lugar de encontrar errores de software.
(3) Clasifique los errores de software encontrados durante la prueba de aceptación hasta que se pase la prueba de aceptación.
(4) El diseño de casos de uso en las pruebas de aceptación debe ser integral, multidimensional y eficiente, y puede confirmar si las funciones y el rendimiento del software cumplen con los requisitos en el menor tiempo posible.
3. Diseño de contenidos y casos de uso de pruebas de aceptación de ERP.
El propósito de las pruebas de aceptación de ERP es confirmar si el sistema cumple con los requisitos del producto, las especificaciones y los contratos técnicos. Confirme los requisitos funcionales, los requisitos de rendimiento y los requisitos de documentación del software mediante la implementación de planes de prueba predeterminados y actividades de ejecución de pruebas. ERP es un software complejo a gran escala y sus pruebas de aceptación deben cubrir dos aspectos: pruebas de confirmación y pruebas del sistema. En concreto, incluye los siguientes contenidos de prueba: prueba de instalación, prueba funcional, prueba de interfaz, prueba de rendimiento, prueba de documentos, prueba de estrés de carga, prueba de recuperación, prueba de seguridad, prueba de compatibilidad, etc. Hablemos de las precauciones para el diseño de casos de uso basadas en el contenido específico de las pruebas de aceptación de ERP.
(1) Prueba de instalación
El propósito de la prueba de instalación es verificar si el software se puede instalar en diferentes configuraciones y confirmar si puede funcionar normalmente. Se deben tener en cuenta los siguientes puntos al diseñar casos de prueba de instalación de ERP:
Primero, elija diferentes sistemas operativos según la portabilidad del ERP.
En segundo lugar, seleccione diferentes niveles de configuración de hardware y configuración de software. Generalmente, se seleccionan las tres configuraciones más baja, media y más alta para realizar pruebas para verificar la inercia del sistema con el entorno de software y hardware.
En tercer lugar, observe si el programa de instalación de ERP se puede instalar normalmente cuando los recursos de software y hardware son suficientes, si se dan suficientes indicaciones durante el proceso de instalación, si existen desventajas del software fraudulento y si puede funcionar normalmente una vez completada la instalación Ejecute para ver si se puede eliminar por completo.
En cuarto lugar, en el caso de recursos insuficientes, como espacio en disco insuficiente, contenido insuficiente, etc. , si el sistema se puede instalar y si se pueden dar varias indicaciones.
(2) Pruebas funcionales
Las pruebas funcionales son el contenido principal de las pruebas de aceptación. Las pruebas funcionales de ERP deben incluir los siguientes elementos: consultar, agregar, eliminar, modificar, guardar y otras operaciones de un solo módulo; operaciones de procesamiento de datos de entrada y salida, como la precisión de la importación y la transferencia de datos; cálculo, como si el inventario histórico del almacén, el inventario actual y el inventario de ubicación de carga son precisos; capacidad de datos * * * para disfrutar de los parámetros de interfaz de autenticación y control del estado del archivo; el sistema está ejecutando la descomposición de MRP, órdenes de trabajo. Si el estado del MPS se identifica antes y después de operaciones como la liberación y la programación de tareas del taller, y si los cambios de estado son correctos en las impresiones de los informes que definen el proceso de aprobación y diversas aprobaciones y contra-; operaciones de aprobación; envío y gestión de SMS de puestos y negocios departamentales, como gestión de adquisiciones, planificación de adquisiciones, gestión de órdenes de compra y luego gestión de llegada de adquisiciones, desde órdenes de venta hasta planes maestros de producción, desde talleres hasta almacenes, etc.
Se debe prestar atención a los siguientes puntos al diseñar casos de uso para pruebas funcionales de ERP:
En primer lugar, los campos de entrada de los elementos de prueba deben ser completos. Debe haber entrada de datos legal e entrada de datos ilegal. Por ejemplo, al probar la definición de datos básicos, si se especifican números, debe ingresar números y letras, espacios y otros elementos que no sean números al mismo tiempo para realizar la prueba. Los números incluyen números enteros, negativos y decimales, por lo que debes ingresar estos números diferentes para verificar la exactitud del número.
En segundo lugar, divida las clases de equivalencia para mejorar la eficiencia de las pruebas. Teniendo en cuenta la amplitud del campo de las pruebas, divida las clases de equivalencia y seleccione algunos casos de uso representativos de las pruebas para mejorar la eficiencia de las pruebas. Por ejemplo, si el registro MRP tiene cuatro estados: "Recién formado", "Programado", "En ejecución" y "Completado", el sistema solo permite la modificación o eliminación parcial del registro MRP recién formado. Luego, durante el proceso de prueba, Los registros MRP se dividen en cuatro categorías, una para cada estado y se puede seleccionar uno de cada categoría como caso de prueba.
En tercer lugar, se deben utilizar valores límite para una inspección oportuna. Por ejemplo, en "programación previa de pedidos", generalmente se requiere que el número de programación previa sea mayor que 0, entonces los datos de prueba pueden ser 0, -1, 1, 1000000 (un número positivo grande) respectivamente.
En cuarto lugar, envíe la misma transacción repetidamente.
En quinto lugar, las operaciones funcionales no se realizan en el orden normal.
Sexto, verificar la relación entre entidades. Hay tres tipos de relaciones entre entidades: uno a uno, uno a muchos y muchos a muchos. Por ejemplo, un MPS corresponde a múltiples MRP y un MRP corresponde a múltiples tareas de taller.
En séptimo lugar, realice operaciones normales y observe anomalías en los resultados de salida. Por ejemplo, el impacto de eliminar un registro en la clasificación; si el estado del documento cambia después de la aprobación.
(3) Pruebas de interfaz
La interfaz del ERP debe cumplir con los estándares y hábitos de usuario actuales. Las empresas de software pueden crear sus propias características, pero deben asegurarse de que todo el estilo del software sea coherente. Las pruebas de interfaz deben comenzar con la facilidad de uso, la operatividad, la belleza, el diseño razonable, la clasificación científica y la descripción precisa del título. El diseño de casos de prueba debe centrarse en los siguientes puntos:
Primero, si los colores de fondo y primer plano están coordinados y si el contraste de color se utiliza de forma adecuada.
En segundo lugar, si el estilo de apariencia de los iconos, botones, cuadros de diálogo, etc. es correcto. El software es acorde con la estética requerida por la resolución de la pantalla.
En tercer lugar, si el diseño de los elementos de la ventana es razonable y coherente.
En cuarto lugar, si la descripción de la información de varios títulos de campos es precisa.
En quinto lugar, si las teclas de acceso directo, los botones, el mouse y otras operaciones en el software son consistentes.
En sexto lugar, si la proporción de visualización y el formato de las ventanas y los informes pueden satisfacer las necesidades esperadas de los usuarios.
Séptimo, si las indicaciones de error causadas por un mal funcionamiento son amigables.
Octavo, si la ventana activa y el registro seleccionado están resaltados.
Noveno, ¿hay alguna información útil y si la navegación por el menú puede continuar normalmente?
Décimo, verifique si se pueden ejecutar algunos campos y controles especiales.
(4) Pruebas de rendimiento
Las pruebas de rendimiento prueban principalmente la velocidad de ejecución y el consumo de recursos del software. Pruebe la portabilidad, velocidad de ejecución, estabilidad y confiabilidad del software ajustando la configuración de software y hardware, la estructura de expansión de la red, la cantidad de estaciones de trabajo, el volumen de datos y las solicitudes de servicio en las que se basa el ERP. Generalmente, las herramientas de prueba automatizadas a nivel empresarial, como WinRunner, se utilizan para analizar y evaluar el rendimiento del software mediante pruebas extremas.
(5) Prueba de documentos
La documentación es una parte importante del software y una parte importante del control de calidad del software y la gestión de la configuración del software. Las pruebas de documentos verifican principalmente la integridad, precisión, coherencia, trazabilidad y comprensibilidad de los documentos mediante su revisión. Como software a gran escala, ERP cubre varios negocios de la empresa. Debe tener al menos cinco tipos de documentación: definición de requisitos, desarrollo y diseño, pruebas y evaluación, gestión de proyectos y aplicación de usuario. Específicamente, debe incluir los 14 archivos de software especificados en GB8567-88.
Al revisar documentos, preste especial atención a los siguientes puntos:
En primer lugar, se deben aclarar los estándares para la aceptación de documentos, y la empresa de software y la empresa usuaria deben alcanzar un acuerdo.
En segundo lugar, determine la importancia del documento y los requisitos para la documentación del proyecto. Por ejemplo, durante la etapa de aceptación, los documentos del usuario (manuales de usuario, manuales de operación, manuales de mantenimiento, archivos de ayuda en línea) son particularmente importantes y deben revisarse cuidadosamente.
En tercer lugar, verifique la integridad del documento, principalmente el tipo y la integridad del contenido del documento.
En cuarto lugar, verifique la coherencia y trazabilidad del documento, principalmente: si la descripción del diseño del software cumple con la definición de requisitos, si la aplicación es consistente con la descripción en el archivo de diseño; describe objetivamente la aplicación El funcionamiento real del programa si existen opiniones diferentes sobre la descripción del mismo problema;
En quinto lugar, comprobar la exactitud del documento, principalmente si la descripción del documento es precisa, si hay alguna ambigüedad y si hay errores en la expresión textual.
En sexto lugar, comprobar la comprensibilidad del documento, comprobando principalmente si el documento está dirigido a un grupo de lectores específico y si la expresión es detallada. Por ejemplo, el manual de operación de ERP no solo debe describir el funcionamiento de cada módulo, sino también proporcionar instrucciones operativas para negocios de trabajo relevantes, negocios departamentales y negocios entre departamentos.
(6) Otras pruebas
Además de las pruebas anteriores, es necesario probar otras características y requisitos del sistema. Por ejemplo, detectar la capacidad del software para recuperar datos tras un fallo repentino, la seguridad y confidencialidad del software, la compatibilidad del hardware, software y datos, el volumen máximo de datos y la robustez que puede soportar el sistema, etc.
Otras pruebas suelen incluir lo siguiente:
Primero, pruebas de estrés de carga. Incluye principalmente pruebas de rendimiento simultáneas, pruebas de resistencia a la fatiga, pruebas de gran volumen de datos y pruebas de velocidad. La tecnología de automatización se utiliza generalmente para realizar pruebas en el lado del cliente, el lado del servidor y el lado de la red, respectivamente. Al diseñar casos de uso, es necesario seleccionar operaciones comerciales representativas y clave como objetos de prueba basados en negocios reales.
En segundo lugar, reanude las pruebas. Detecte el grado de corrupción de datos y la capacidad de recuperación del sistema simulando fallas de hardware o provocando errores de software deliberadamente.
En tercer lugar, pruebas de seguridad. La solidez de las estrategias de protección de seguridad del sistema, como el mecanismo de autenticación, el mecanismo de cifrado y la función antivirus, se probó mediante inicios de sesión ilegales, escaneo de vulnerabilidades y ataques simulados.
Cuarto, pruebas de compatibilidad. A través de pruebas de compatibilidad de hardware, pruebas de compatibilidad de software y pruebas de compatibilidad de datos, se examinaron la multiplataforma y la portabilidad del software.
4. Conclusión
Los usuarios de ERP y los desarrolladores de software deben tener clara la verdadera intención de las pruebas de aceptación. Los desarrolladores e implementadores no deben ocultar errores de software ni preocuparse por elementos de prueba con los que los usuarios no están familiarizados. Los usuarios no pueden dejar de lado el trabajo de aceptación porque algunos requisitos no se pueden cumplir en este momento. Al contrario, ambos deberían cooperar sinceramente, confiar el uno en el otro y dejar las cosas claras. Para aquellos requisitos inviables o poco claros, ambas partes deben negociar y llegar a un acuerdo para cambiar los requisitos. Sólo estas pruebas de aceptación pueden promover la aceptación rápida y exitosa de proyectos ERP.