¿Qué miden las pruebas de interfaz de usuario?

Pruebe la combinación de colores, el diseño general, el interlineado, la alineación, la unidad de estilo, etc. de la interfaz de usuario. También hay que determinar si algunos controles son razonables, si las indicaciones y la información de la página tienen errores gramaticales, etc. Específicamente, las pruebas generalmente apuntan a lograr los siguientes objetivos:

1. Garantizar que el producto haya completado las funciones prometidas o anunciadas y que tenga instrucciones escritas claras para todas las funciones a las que los usuarios pueden acceder --- --- , en cierto sentido es la misma idea que iso9001.

La falta de documentación escrita clara del producto es una manifestación del comportamiento coyuntural del proveedor y también es una manifestación de irresponsabilidad. El llamado comportamiento a corto plazo se refiere a la falta de documentos escritos claros que no favorecen la entrega final sin problemas del producto, pueden entrar fácilmente en conflicto con los usuarios y afectan la reputación del fabricante y las relaciones futuras con los usuarios; Tampoco es propicio para el mantenimiento del producto y hará que el fabricante gaste cantidades excesivas en capacitación del usuario y costos de soporte técnico. Desde una perspectiva a largo plazo, esto es muy antieconómico. La evaluación del líder cree que las personas que han estado expuestas a productos de software rara vez están interesadas en productos grandes y archivos delgados como Zhengzheng.

Por supuesto, la redacción y el mantenimiento de documentos escritos es lo más importante y difícil para los proyectos desarrollados utilizando prototipos rápidos (RAD), pero también es lo más fácil de pasar por alto.

Finalmente, la documentación escrita imperfecta o incluso incorrecta es el problema más problemático y grave que se encuentra en las pruebas. Sus consecuencias directas son una baja eficiencia de las pruebas, objetivos de prueba poco claros y un alcance de prueba insuficiente, lo que hace que la prueba final esté infrautilizada. e ineficaz.

2. Asegúrese de que el producto cumpla con los requisitos de rendimiento y eficiencia.

El sistema utilizado para ejecutarlo es ineficiente (bajo rendimiento), o la interfaz de usuario no es amigable y la operación del usuario es inconveniente ( baja eficiencia) No se puede decir que el producto sea un producto competitivo.

Lo que más les importa a los usuarios no es qué tan avanzada es su tecnología o qué tan poderosas son sus funciones, sino cuánto beneficio pueden obtener de estas tecnologías y funciones. En otras palabras, al usuario le importa cuánto beneficio puede obtener de ello, no cuánto ha invertido.

3. Garantizar la robustez del producto y su adaptabilidad al entorno del usuario.

La robustez, es decir, la estabilidad, es un requisito básico para la calidad del producto, especialmente para transacciones clave o de tiempo. -Ambiente de trabajo crítico.

Además, es importante no hacer suposiciones sobre el entorno del usuario (con la posible excepción de algunos proyectos); por ejemplo, muchos usuarios de periódicos tienen configuraciones relativamente bajas y se utilizan junto con ciertos terceros. productos.

Principio de prueba: suficientemente bueno

Para productos o sistemas relativamente complejos, cero errores es el estado ideal y nuestro principio es lo suficientemente bueno.

El principio de "suficientemente bueno" es una compensación entre la relación entrada/salida: no realizar pruebas suficientes es irresponsable; realizar pruebas excesivas es un desperdicio de recursos e igualmente irresponsable. Nuestra dificultad operativa es cómo definir qué tipo de prueba es insuficiente y qué tipo de prueba es excesiva. En respuesta a la situación actual, la única respuesta disponible es: establecer un estándar mínimo de calificación de prueba y un contenido de prueba, y luego analizar cuestiones específicas en detalle. El ejemplo más obvio es la prueba del producto de la versión del periódico chino fit3.0.

Las reglas de prueba----el principio del barril de madera y el principio 80-20

1. El principio del barril de madera.

En lo que respecta a la producción de productos de software, existe el concepto de gestión de calidad total (tqm). Los factores clave de la calidad del producto son el análisis, el diseño y la implementación. Las pruebas deben integrarse en los medios auxiliares de inspección. Otros factores de gestión, soporte e incluso culturales también afectarán la calidad del producto final. Cabe decir que la inspección es una condición necesaria para mejorar la calidad del producto, y también es el medio más directo y rápido para mejorar la calidad del producto, pero de ninguna manera es el medio fundamental. Por el contrario, si todo el peso de mejorar la calidad del producto se pone en las pruebas, será un desastre terrible y prolongado.

2. Principio ERROR 80-20.

En términos generales, la revisión y prueba en las fases de análisis, diseño e implementación pueden encontrar y evitar el 80% de los errores, mientras que las pruebas del sistema pueden encontrar el 80% de los errores restantes y el último 5% de los errores. Puede que solo quede expuesto después de que los usuarios lo usen durante mucho tiempo. Porque las pruebas solo pueden garantizar que se encuentren tantos errores como sea posible, pero no todos los errores.

2. Dividido según si se debe ejecutar el programa:

(1) Prueba estática (prueba estática): se refiere a no ejecutar realmente el software bajo prueba, sino solo verificar estáticamente. código del programa, interfaz o posibles errores en el proceso de documentación.

Las pruebas estáticas incluyen:

Para las pruebas de código, prueba principalmente si el código cumple con los estándares y especificaciones correspondientes.

Para las pruebas de interfaz, se prueba principalmente si la interfaz real del software coincide con la descripción de los requisitos.

Para las pruebas de documentos, prueba principalmente si el manual del usuario y la descripción de la demanda realmente satisfacen las necesidades reales de los usuarios.

(5) La prueba dinámica se refiere al proceso de ejecutar realmente el programa bajo prueba, ingresar los datos de prueba correspondientes y verificar si los resultados de salida coinciden con los resultados esperados.

3 Presione. División de etapas:

(1) Las pruebas unitarias se refieren a la inspección y verificación de la unidad comprobable más pequeña del software.

El módulo de extracción (stu) se refiere al módulo llamado simulando el módulo bajo prueba. El módulo controlador (controlador) se refiere al módulo principal que simula el módulo bajo prueba. El módulo controlador se utiliza para recibir. datos de prueba e iniciar el módulo bajo prueba y generar el resultado.

(2) Las pruebas de integración son la siguiente etapa de las pruebas unitarias. Ensambla los módulos unitarios probados en un sistema o subsistema y luego los prueba, centrándose en probar las interfaces de los diferentes departamentos de módulos.

Las pruebas de integración se utilizan para comprobar si los módulos de unidades individuales combinados pueden funcionar juntos y ejecutarse normalmente.

(3) Las pruebas del sistema se refieren a probar todo el sistema de software en su conjunto, incluidas las pruebas de funciones, rendimiento y el entorno de hardware y software en el que se ejecuta el software.

La base principal para las pruebas del sistema es el documento "Especificación de requisitos del sistema".

(4) Las pruebas de aceptación (pruebas de aceptación) se refieren a las pruebas en las que participan las pruebas de usuario o los evaluadores y otro personal de control de calidad en la etapa posterior de las pruebas del sistema. También es la entrega oficial del software a. el usuario. El último proceso utilizado.

Las pruebas de aceptación se dividen en pruebas primarias y pruebas internas. Las pruebas primarias se refieren a una prueba en la que participan usuarios, evaluadores, desarrolladores, etc. Pruebas internas con la participación de ***, mientras que las pruebas beta se refieren a las pruebas públicas después de las pruebas internas, que es una prueba que se entrega completamente a los usuarios finales.

4. Las pruebas de caja negra se dividen en pruebas funcionales y pruebas de rendimiento:

1) Las pruebas de función (pruebas de función) son un aspecto de las pruebas de caja negra, que verifican la función real de el software si satisface las necesidades de los usuarios.

Incluye pruebas de funciones lógicas

Pruebas de UI ui=interfaz de usuario

Pruebas de usabilidad: Sí Se refiere a verificar y descubrir las deficiencias en el software desde la perspectiva de la racionalidad y conveniencia de usar el sistema de software, y verificar y descubrir los lugares en el software que son inconvenientes para los usuarios.

Pruebas de compatibilidad (pruebas de compatibilidad): incluidas pruebas de compatibilidad de hardware y pruebas de compatibilidad de software

2) Pruebas de rendimiento (pruebas de rendimiento)

Rendimiento del software Hay dos principales tipos: rendimiento temporal y rendimiento espacial

Rendimiento temporal: se refiere principalmente al tiempo de respuesta de una transacción específica.

Rendimiento del espacio: se refiere principalmente a los recursos del sistema consumidos por el software en ejecución.

Las pruebas de rendimiento del software se dividen en:

Pruebas de rendimiento generales: se refiere a las pruebas de rendimiento del sistema bajo prueba en un entorno normal de software y hardware sin ninguna presión.

Pruebas de estabilidad, también conocidas como pruebas de confiabilidad: se refiere a ejecutar continuamente el sistema bajo prueba para verificar la estabilidad del sistema durante la operación.

Prueba de carga: Funcionamiento continuo dentro del rango de presión que el sistema bajo prueba puede soportar para probar la estabilidad del sistema.

Prueba de tensión: se refiere al aumento continuo de la presión sobre el sistema bajo prueba hasta que el sistema bajo prueba sea aplastado. Se utiliza para probar la presión máxima que el sistema puede soportar. (Verifique si el sistema o el software puede tolerar el estrés máximo).

5. Otros tipos de pruebas:

Las pruebas de regresión se refieren a probar nuevas versiones de software. Al realizar la prueba, repita la prueba. casos de la versión anterior. (Al implementar una nueva compilación o versión, repita todos los casos de prueba que se ejecutaron en la última compilación o versión).

La prueba de humo se refiere a la prueba antes de la prueba a gran escala, el proceso de probar una nueva versión. versión con el fin de verificar si las funciones básicas del software han sido implementadas y comprobables. (

La prueba aleatoria es una prueba en la que todos los datos de entrada se generan aleatoriamente. Su propósito es simular la operación real del usuario y encontrar algunos errores marginales. (Lo que significa que todos los datos de prueba son aleatorios para verificar algunos errores marginales). errores)

Las pruebas de software incluyen los siguientes pasos:

1. Desarrollar un plan de prueba

2. 3. Implementar la prueba (primero construir el entorno de prueba);

4. Administrar los errores encontrados durante la prueba

5. Después de la prueba (fin de la prueba). terminadas las pruebas, corrija los errores encontrados)

6. Haga un informe de prueba (de esta manera finaliza el proceso de prueba, cada tipo de prueba (prueba unitaria, prueba de integración, prueba del sistema, prueba de verificación) Las pruebas son todos iguales);