Modelo de competencia en conocimiento para arquitectos de pruebas de software.

Lo que hace el arquitecto de pruebas no es un trabajo de tecnología de prueba pura, sino un arte integral que requiere una combinación de productos, comunicación y coordinación, expresión escrita, etc., como se muestra en la Figura 1.

Figura 1 Competencias requeridas por los arquitectos de pruebas de software

En términos de tecnología de prueba, los arquitectos de pruebas de software deben tener las siguientes capacidades tecnológicas de prueba:

Modelo de calidad del producto software

Tipo de prueba

Métodos de prueba

prueba exploratoria

prueba automatizada

1 Seis atributos de la calidad del producto de software

Figura 2 Seis atributos de la calidad del producto de software

1.1 Funcionalidad

Tabla 1 Subatributos funcionales

Idoneidad: para las calculadoras de Windows, todas las funciones relacionadas con el "cálculo" proporcionadas por el producto de software a los usuarios son adecuadas.

Precisión: para las calculadoras de Windows, la exactitud de los resultados de los cálculos de la propia calculadora es una expresión de la precisión del software de la calculadora.

Interoperabilidad: Para las calculadoras de Windows, si las diferentes funciones y características de la calculadora pueden cooperar correctamente entre sí es una expresión de la interoperabilidad de la calculadora; además, la compatibilidad con diferentes sistemas operativos, como la compatibilidad con diferentes versiones de Windows 7 (incluidos diferentes parches versiones) y la compatibilidad con diferentes modos de trabajo (como modo seguro, modo seguro con conexión de red) también son manifestaciones de interoperabilidad.

Seguridad: para las calculadoras de Windows, la calculadora no debe contener agujeros de seguridad explotables ni contenido relacionado con "permisos de usuario", como "tanto los administradores como los invitados deben tener los mismos permisos de uso", etc.

Cumplimiento funcional: para las calculadoras de Windows, el cumplimiento funcional puede entenderse como que, como calculadora, las reglas de cálculo (como operaciones cuadradas, operaciones estadísticas, etc.) deben ser consistentes con las reglas relevantes en matemáticas.

1.2 Fiabilidad

Las siguientes tres oraciones progresivas pueden ayudarnos a comprender los requisitos de confiabilidad del usuario:

Nivel 1: Es mejor no dañar el equipo;

Capa 2: Si el equipo falla, las funciones y servicios principales no deberían verse afectados;

Nivel 3: Si las funciones y servicios principales se ven afectados, el sistema se puede localizar y restaurar lo antes posible.

Tabla 2 Subatributos de confiabilidad

Madurez: para las calculadoras de Windows, la madurez puede entenderse como la probabilidad de que falle la función del producto. Por ejemplo, si la calculadora continúa funcionando durante un período de tiempo, se producirán errores de cálculo. En términos generales, este tipo de error se puede recuperar reiniciando el software, reiniciando el dispositivo, etc.

Tolerancia a fallos: para las calculadoras de Windows, la tolerancia a fallos puede entenderse como la capacidad del producto para manejar la "entrada de error" del usuario.

Recuperabilidad: para las calculadoras de Windows, la recuperabilidad puede entenderse como la capacidad de la calculadora para recuperarse una vez que ocurre una anomalía que el producto en sí no puede anticipar (como no responder, reiniciar).

Cumplimiento de confiabilidad: para las calculadoras de Windows, no existen estándares estrictos y claros para el cumplimiento de confiabilidad, pero existen algunas convenciones potenciales. Por ejemplo, la calculadora debe poder identificar entradas anormales para todas las operaciones matemáticas y dar una pista sobre el causa del error. Los productos de comunicación tienen estándares relativamente estrictos en términos de confiabilidad y cumplimiento, como que la tasa de falla del sistema no puede ser mayor que un valor determinado y el tiempo de recuperación de fallas no puede ser mayor que un valor determinado, etc.

1.3 Portabilidad

Adaptabilidad: para las calculadoras de Windows, la adaptabilidad puede entenderse como si el diseño, el tamaño, la claridad, la disposición de las teclas, etc. de la calculadora se pueden mostrar normalmente en pantallas de diferentes tamaños.

Instalabilidad: para las calculadoras de Windows, la instalabilidad puede entenderse como si la calculadora se puede instalar correctamente en diferentes sistemas operativos de Windows y ejecutarse normalmente.

Coexistencia: para las calculadoras de Windows, la coexistencia puede entenderse como que la calculadora y otro software pueden coexistir en Windows al mismo tiempo, y no habrá competencia por los recursos (como CPU, memoria, etc.).

Facilidad de reemplazo: Para las calculadoras de Windows, la facilidad de reemplazo puede entenderse como asumir que se desarrolla una nueva calculadora y que la nueva calculadora puede reemplazar con éxito a la antigua. (Tenga en cuenta que esto no se refiere a "actualización del producto", pero puede haber situaciones en las que coexistan calculadoras "nuevas" y "antiguas" al mismo tiempo).

Cumplimiento de la portabilidad: para las calculadoras de Windows, el cumplimiento de la portabilidad puede entenderse como algunas convenciones sobre la portabilidad de los productos de Windows. Por ejemplo, una calculadora no está desarrollada para un sistema operativo específico y debe ser compatible con todos los sistemas operativos Windows.

2 tipos de prueba

Los tipos de prueba se refieren a las diferentes perspectivas que deben considerarse para las pruebas. Podemos utilizar el modelo de calidad del producto de software (en lo sucesivo, "modelo de calidad") para definir y comprender rápidamente los tipos de pruebas.

Figura 3 Relación entre atributos de calidad y tipos de pruebas

Tabla 5 Tipos de pruebas comunes y su relación con los atributos de calidad

3 métodos de prueba

3.1 Diagrama de rueda de prueba del producto

El tipo de prueba, es decir, el ángulo desde el cual se realiza la prueba para probar el producto, determina la idea de la prueba. Lo que queremos discutir a continuación es cómo hacerlo, es decir, el método de prueba específico.

Figura 4 Diagrama de rueda de prueba del producto

La relación entre las seis categorías de atributos de calidad y tipos de pruebas que se muestran en la Figura 4 no entra en cada subatributo de calidad ni en el tipo de prueba correspondiente a cada subatributo (es posible que desee dibujar la rueda de "subatributo de calidad" por ti mismo foto).

A partir del "diagrama de ruedas" se pueden analizar dos cuestiones clave en las pruebas de productos:

La primera es la cuestión de cómo garantizar la "integralidad" de la verificación de las pruebas. Obviamente, siempre que el método de prueba que utilicemos pueda cubrir los seis atributos de calidad, no habrá omisiones direccionales generales en nuestras pruebas.

La segunda es la cuestión de cómo determinar la "profundidad" de las pruebas. En términos generales, cuantos más métodos de prueba utilice un equipo de pruebas, más profundamente se probará el producto.

Estos afectarán el efecto de la prueba y la evaluación de la calidad del producto mediante la prueba. Además, el "diagrama de ruedas" también puede ayudarnos a evaluar las capacidades del equipo de pruebas. Cuantos más métodos de prueba pueda dominar un probador de software, más sólidas serán sus capacidades de prueba.

3.2 Método de prueba funcional

Los métodos de prueba funcionales incluyen:

Método de entrada de valor normal de ejecución única.

Método de entrada de valor límite de ejecución única.

Método de ejecución de secuencia de ejecución múltiple.

Método de interacción de ejecución múltiple.

definición:

Ejecutar: en pruebas de software, la "operación" o "comportamiento" del usuario simulado por el evaluador.

Ejecución única: en las pruebas de software, el probador simula "una operación" o "un comportamiento" del usuario.

Ejecución múltiple: en las pruebas de software, el probador simula "múltiples operaciones" o "múltiples comportamientos" del usuario.

Es decir, "ejecutar" se refiere a una operación o comportamiento que tiene sentido desde la perspectiva del usuario. Desde un nivel funcional, una "ejecución" determina una posible situación de "entrada" y "salida", como se muestra en la Figura 5.

Figura 5 Diagrama esquemático de funcionamiento a nivel funcional

A veces, dividimos funciones desde una perspectiva de diseño y no logramos brindar a los usuarios un comportamiento completo y significativo, como "el usuario estableció una nueva conexión con el servidor de correo" y "el servidor de correo eliminó la conexión con el usuario". Este tipo de función detallada no cuenta como una "ejecución" incluso si se determinan la entrada y la salida. En este momento, se pueden combinar múltiples funciones hasta que esta función pueda proporcionar un comportamiento completo y significativo para los usuarios, como se muestra en la Figura 6.

Figura 6 Relación entre función y operación

3.2.1 Método de entrada del valor normal de una sola serie 

Es un método de prueba en el que "A1" y "A2" ingresados ​​durante la prueba son los "valores normales" permitidos por el sistema.

3.2.2 Método de entrada del valor límite de una sola ejecución

Este es el método de prueba en el que "A1" y "A2" ingresados ​​durante la prueba son los "valores límite" del sistema.

3.2.3 Método de ejecución de secuencia de ejecución múltiple

Considere varias operaciones de "ejecución única" juntas y el resultado será una operación de "ejecución múltiple". Cuando se utiliza el método de ejecución secuencial de múltiples ejecuciones para realizar pruebas, analizar la secuencia entre cada ejecución es la clave para utilizar este método.

El método de ejecución de secuencia de ejecución múltiple es muy eficaz en lugares relacionados con los hábitos operativos del usuario.

Además, el método de ejecución secuencial de ejecución múltiple también es más adecuado para su uso en pruebas de configuración funcional.

Tabla 6 Escenarios de secuencia de ejecución múltiple

Múltiples escenarios de ejecución con números de serie están asociados con múltiples secuencias de ejecución.

1 El usuario primero envía un correo electrónico y luego recibe un correo electrónico No No

2 Después de que el usuario recibe un correo electrónico y luego envía el correo electrónico recibido, ¿es

3 Después de que el usuario reciba un correo electrónico, envíe otro correo electrónico arbitrario No No

3.2.4 Método de interacción de ejecución múltiple

El método de interacción de ejecución múltiple se refiere a un método de combinar múltiples ejecuciones interrelacionadas para realizar pruebas durante las pruebas funcionales, como se muestra en la Figura 7.

Figura 7 Método de interacción de ejecución múltiple

A diferencia del método de ejecución secuencial de múltiples ejecuciones que enfatiza la secuencia entre múltiples ejecuciones, el método de interacción de múltiples ejecuciones enfatiza la relación entre múltiples ejecuciones. Esta relación puede ser una relación externa, como el buen progreso de un determinado negocio. colaboran entre sí; también puede ser una relación intrínseca, como que estas se ejecuten usando los mismos recursos (como memoria u otros recursos de hardware).

Lo que hay que señalar en particular es que todos estos son escenarios de operación "para un usuario", en lugar de escenarios de "dos usuarios diferentes envían correos electrónicos al mismo tiempo" o "un usuario envía correos electrónicos y un usuario recibe correos electrónicos". De hecho, el primero pertenece a la categoría de pruebas funcionales, mientras que el segundo pertenece a la categoría de pruebas de confiabilidad.

3.3 Método de prueba de confiabilidad

3.3.1 Método de entrada de valores atípicos

El método de entrada de valores atípicos es un método de prueba de confiabilidad que utiliza valores que el sistema no permite que los usuarios ingresen (es decir, valores atípicos) como entradas de prueba.

3.3.2 Método de implantación de fallas

El método de implantación de fallas es un método de prueba de confiabilidad que coloca el sistema en un entorno problemático para realizar pruebas. Los principales atributos de calidad que se pueden probar son la tolerancia a fallas y la madurez.

A diferencia del método de entrada de valores atípicos, el método de entrada de valores atípicos ingresa directamente un valor que el sistema considera incorrecto y no compatible; mientras que el método de implantación de fallas coloca al sistema en un entorno problemático, pero la entrada sigue siendo un valor normal.

¿Qué fallos, errores o problemas existen en el entorno empresarial del usuario? Enumere estos escenarios, coloque el sistema en estos escenarios, ejecute el negocio normalmente y analice si la respuesta del sistema en este momento es razonable.

Si el sistema se implementa en el entorno de hardware del usuario, considere los recursos de hardware requeridos por el sistema, como CPU, memoria, espacio de almacenamiento, etc., y si la respuesta del sistema es razonable cuando es insuficiente. Tomemos el ejemplo de "El usuario envía un correo electrónico". La falla de la red es una falla común para los usuarios, como desconexión, red intermitente y pérdida de paquetes.

Si el sistema está instalado en el sistema del usuario, considere si la respuesta del sistema es razonable en caso de conflictos de software, controladores incorrectos, etc.

Si el sistema es un dispositivo independiente, considere si la respuesta del sistema es razonable cuando ocurren problemas con sus componentes clave (como chasis, placas individuales, tarjetas enchufables, discos duros, chips, etc.).

3.3.3 Método de prueba de estabilidad

El método de prueba de estabilidad es un método de prueba de confiabilidad que ejecuta un determinado negocio a gran capacidad durante un período de tiempo prolongado. Puede probar de manera muy efectiva la "madurez" del sistema y es un método de prueba de confiabilidad muy importante.

Cabe señalar en particular que existe una cierta relación entre el método de prueba de estabilidad, el método de prueba de estrés y el método de prueba de rendimiento, y esta relación es la especificación del producto.

Especificaciones del producto: La capacidad máxima que un producto promete manejar. Por ejemplo, el sistema admite que hasta 100 usuarios inicien sesión simultáneamente y el sistema admite el establecimiento de hasta 100 políticas de seguridad, que son especificaciones del producto.

El propósito de las pruebas de rendimiento es comprobar si las especificaciones reales del producto son consistentes con las especificaciones requeridas prometidas en el manual. Obviamente, el valor de rendimiento final que medimos es la capacidad máxima que el sistema realmente puede manejar.

Las pruebas de estabilidad se realizan por debajo de los valores de rendimiento. De hecho, cuando los usuarios usan el sistema, no siempre dejarán que el sistema se ejecute en el estado extremo. Durante la prueba, podemos controlar la carga en la prueba para que sea lo más cercana posible al uso real del usuario, de modo que la prueba Puede ser más preciso y más valioso.

Las pruebas de estrés se realizan a valores superiores a los de rendimiento. Aunque la carga durante la prueba excedió la capacidad máxima del sistema, eso no significa que las funciones del sistema fallarán en este caso, debemos analizar si el rendimiento del sistema es razonable en función de la situación real. Por ejemplo, el sistema admite que hasta 100 usuarios inicien sesión simultáneamente, pero en este momento 110 usuarios inician operaciones de inicio de sesión al mismo tiempo, entonces el sistema debe garantizar que 100 de estos 110 usuarios puedan iniciar sesión normalmente, y es razonable que 10 usuarios no podrán iniciar sesión, en lugar de que todos los usuarios no puedan iniciar sesión.

Ahora volvamos al tema de esta sección: las pruebas de estabilidad (en los siguientes artículos se le presentarán los métodos de prueba de rendimiento y los métodos de prueba de estrés). Desde una perspectiva metodológica, el método de prueba de estabilidad es el más interesante de todos los métodos de prueba y puede resumirse como una "fórmula de cuatro caracteres": múltiple, unión, compleja y diferencia.

La esencia de "varias palabras" es probar la estabilidad del sistema aumentando el número de operaciones del usuario en funciones durante la prueba.

La esencia de "Ming Zi Jue" es permitir que varios usuarios operen esta función al mismo tiempo durante la prueba para comprobar si el sistema aún está estable. A veces también llamamos a esta prueba prueba de concurrencia.

La esencia de "Fu Zi Jue" es permitir que uno o más usuarios realicen repetidamente operaciones como crear, actualizar, eliminar, sincronizar y realizar copias de seguridad durante la prueba para comprobar si el sistema es estable.

La esencia de las "palabras diferentes" es permitir que uno o más usuarios realicen operaciones anormales repetidamente durante la prueba para verificar si el sistema puede continuar respondiendo razonablemente. En comparación con el método de entrada anormal y el método de implantación de fallas, "Yi Zi Jue" enfatiza la "continuación" y la "acumulación". De hecho, a menudo es más eficaz utilizar "palabras diferentes" para realizar las pruebas, porque al desarrollar código, es fácil considerar la aplicación y recuperación de recursos en circunstancias correctas e ignorar la recuperación de recursos en circunstancias anormales.

3.3.4 Método de prueba de estrés

Las pruebas de estrés son un método de prueba de confiabilidad que utiliza continuamente cargas que exceden las especificaciones del sistema durante un período de tiempo.

Aunque el producto ha declarado especificaciones y solo promete proporcionar funciones estables y confiables dentro del rango de especificaciones, y no promete proporcionar funciones correctas cuando excede las especificaciones del sistema, las pruebas de estrés siguen siendo significativas. Una razón importante es que, en caso de emergencia empresarial, la carga empresarial del usuario no es promedio, puede exceder la carga en un período de tiempo muy corto, pero en promedio no excede la especificación, como se muestra en la Figura 9.

Figura 8 Emergencias empresariales

Esperamos que el sistema no sea tan frágil como un castillo de naipes en caso de emergencia, pero tenga contramedidas prácticas, como no manejar cargas que excedan las especificaciones del sistema, registrar registros para que los usuarios analicen las causas de las emergencias, etc. . Problemas fatales como fallas y reinicios repetidos no ocurrirán debido a emergencias. Este es el verdadero propósito de nuestra prueba de estrés. Para lograr este objetivo de prueba, necesitamos utilizar un modelo de carga de ráfaga al realizar pruebas de estrés, como se muestra en la Figura 9.

Figura 9 Modelo de carga de ráfaga

No se recomienda utilizar métodos de prueba que excedan continuamente las cargas de las especificaciones del sistema para detectar problemas en el producto. Pero para las pruebas, no tiene ningún sentido utilizar pruebas de modelos de carga que superen continuamente las especificaciones, ya que es una parte integral de nuestro otro método de prueba de confiabilidad: el método de prueba de recuperación.

3.3.5 Método de prueba de recuperación

El método de prueba de recuperación se refiere a un método de prueba que utiliza una carga que continúa excediendo la especificación para la prueba y luego reduce la carga a dentro de la especificación, como se muestra en la Figura 10.

Figura 10 Método de prueba de recuperación

Al realizar continuamente pruebas de carga que exceden las especificaciones, el negocio dentro de las especificaciones permitidas no es 100% correcto. Cuando la carga cae dentro del valor de especificación, la empresa debe poder recuperarse con una precisión del 100%.

Para profundizar la comprensión de todos sobre el método de prueba de estrés y el método de prueba de recuperación, también podríamos comparar las expectativas de los dos modelos para los resultados "comerciales" bajo diferentes cargas, como se muestra en la Figura 11.

Figura 11 Expectativas de resultados comerciales del modo de carga en ráfaga y del modo de carga continua

Se puede ver que la mayor diferencia entre los dos métodos de prueba radica en la parte "negra" de la imagen. Cuando se utiliza el modo de carga en ráfaga para pruebas de estrés, la parte negra en la figura no permite fallas comerciales. Cuando se usa el modo de carga continua para pruebas de recuperación, la parte negra permite fallas comerciales.

3.4 Métodos de prueba de rendimiento

El propósito de las pruebas de rendimiento es probar si las especificaciones reales del producto son consistentes con las especificaciones requeridas prometidas en el manual. El valor de rendimiento que realmente medimos es la capacidad máxima o capacidad que el sistema realmente puede manejar.

En términos generales, las especificaciones requeridas del producto darán las expectativas de rendimiento y el evaluador solo necesita confirmar si el producto puede cumplir con las especificaciones. Si las especificaciones de rendimiento del producto en las especificaciones de requisitos son muy simples y aproximadas, podemos realizar pruebas de rendimiento de acuerdo con la Figura 12.

Figura 12 Proceso de prueba

El primer paso es probar el mejor valor de rendimiento del sistema.

Al realizar pruebas de rendimiento, primero podemos intentar probar el mejor valor de rendimiento del sistema. Podemos utilizar los valores de rendimiento requeridos en las especificaciones de rendimiento como elementos de prueba para probar los límites de estos indicadores en el sistema.

Las especificaciones de rendimiento de diferentes productos pueden variar ampliamente, pero en general se pueden dividir en las dos categorías siguientes.

1) La máxima capacidad del sistema para manejar correctamente nuevos negocios.

La máxima capacidad del sistema para manejar correctamente nuevos negocios, también lo llamamos "nuevo". Por ejemplo, ¿cuántos usuarios nuevos puede permitir el sistema iniciar sesión por segundo, cuántas conexiones nuevas puede iniciar activamente el sistema por segundo, etc.?

Se realizan pruebas de rendimiento de las nuevas capacidades del sistema. La prueba es la velocidad a la que el sistema asigna recursos para completar el proceso de procesamiento de un nuevo negocio. La cantidad total de procesos y recursos de procesamiento empresarial afectará la nueva capacidad del sistema. Cabe señalar que el sistema no se puede "construir" sin "derribarlo": los servicios completados o anormales deben desmantelarse a tiempo, y los recursos ocupados deben reciclarse y utilizarse para nuevos servicios.

2) La capacidad comercial máxima que el sistema puede manejar correctamente al mismo tiempo.

La capacidad empresarial máxima que el sistema puede manejar correctamente al mismo tiempo también se denomina "concurrencia". Por ejemplo, la cantidad máxima de usuarios en línea simultáneos que el sistema puede admitir, la cantidad máxima de conexiones que el sistema puede iniciar simultáneamente, etc.

Cabe señalar en particular que existe una relación entre "nuevo" y "concurrencia", como se muestra en la Figura 13.

Figura 13 Situación de nueva creación y prueba simultánea

Nota: Los dos indicadores de nueva creación y concurrencia se afectarán entre sí. Por ejemplo, la capacidad máxima de concurrencia es 4000. Durante la prueba, solo "construye" y no "derriba". Cuando se crean 150 nuevos elementos por segundo , en 24 segundos, el número de paralelos es mayor que la capacidad máxima de concurrencia: 4000, lo que conduce a una disminución en el número de nuevas creaciones.

Por lo tanto, cuando probamos el mejor valor de rendimiento del sistema, debemos prestar atención a la relación interna entre los indicadores de prueba. Cuando probamos un indicador, otros indicadores no pueden afectar este indicador.

El segundo paso es analizar varios factores que afectarán el valor del desempeño y probar su impacto en el desempeño.

Tanto "Configuración" como "Negocio" tendrán un impacto en los indicadores de rendimiento. Imagínese, el rendimiento de configurar 1 política de usuario y configurar 1000 políticas de usuario debería ser diferente; el sistema recibe correo de 1 byte y recibe 10 millones de correo. Los valores de rendimiento Las pruebas también son diferentes. En este paso, debemos analizar qué factores en el sistema tienen un impacto en el rendimiento (degradación del rendimiento) y luego realizar pruebas para analizar si la degradación del rendimiento está en línea con las expectativas y si el peor de los casos. El escenario sigue siendo aceptable y razonable.

Tabla 7 Número máximo de correos electrónicos que se pueden procesar correctamente en el punto de muestra

Tabla 8 La cantidad máxima de correos electrónicos que se pueden procesar correctamente bajo diferentes estrategias de filtrado

Al probar estos valores de rendimiento, podemos obtener fácilmente:

Qué factores tienen un mayor impacto en el rendimiento del sistema y qué factores tienen menos impacto en el rendimiento del sistema.

Tendencias en el impacto de diversos factores en el desempeño. Al seleccionar muestras de prueba y utilizar la tecnología de "ajuste de curvas" en matemáticas, podemos obtener la curva de influencia de los factores y utilizarla para analizar si esta tendencia a la baja es razonable.

El peor valor de desempeño bajo cada factor. Analice si este peor valor es razonable y si se convertirá en un "cuello de botella" en el rendimiento del sistema.

Muchas veces, no existe un solo factor que afecte un indicador de desempeño, sino que pueden existir múltiples factores. En este paso, solo se puede probar el impacto de un único factor en el rendimiento. El impacto de múltiples factores en el rendimiento se puede ubicar en escenarios típicos y se pueden seleccionar configuraciones y servicios típicos para las pruebas de rendimiento.

El tercer paso es probar el rendimiento basándose en escenarios.

Finalmente, utilizamos "escenario" como unidad para probar los valores de rendimiento de configuraciones y servicios típicos en este escenario.

Tome "El usuario envía correo electrónico" como ejemplo. Supongamos que en este escenario, la configuración típica es "200 políticas de filtrado", y el tamaño del correo electrónico es 1 KB, 10 KB, 2 MB mezclados en 1:2:1, el sistema de correo electrónico puede recibirlo. cada segundo y manejar correctamente el número máximo de mensajes.

3.5 Método de prueba de facilidad de uso

3.5.1 Método de prueba de conformidad

El método de prueba de conformidad se centra en la interfaz de usuario del producto durante la prueba:

Si el estilo, el diseño y los elementos son consistentes y unificados.

Si la racionalidad del diseño, la racionalidad de las operaciones, las indicaciones, etc. cumplen con las especificaciones de diseño de la interfaz de usuario.

El método de prueba de conformidad puede probar la capacidad del producto en términos de facilidad de comprensión y facilidad de uso, pero no le importa si la función del producto es correcta, por lo que puede probar directamente el prototipo de diseño de interfaz de usuario del producto.

3.5.2 Método de prueba de usabilidad

El objeto de prueba del método de prueba de usabilidad también es la interfaz de usuario, pero en las pruebas de usabilidad, nos centramos en si las funciones proporcionadas por el producto son fáciles de aprender, comprender y usar para los usuarios, por lo que las pruebas de usabilidad deben combinarse con funciones. pruebas, utilizando escenarios como Granularidad de prueba, pruebas desde la perspectiva del usuario.

Tabla 9 Enfoque y estándares para las pruebas de usabilidad

4 técnicas de diseño de pruebas

Tabla 9 Puntos de prueba para "El usuario envía correo electrónico"

4.1 Los puntos de prueba no son iguales a los casos de prueba

Si tomamos puntos de prueba para probar, encontraremos muchos problemas que nos harán sentir infelices y confundidos:

Problema 1: Estos puntos de prueba tienen contenido duplicado y son redundantes.

Por ejemplo, tanto el punto de prueba 1 como el punto de prueba 4 probarán "enviar correos electrónicos correctamente".

Problema 2: la entrada de prueba de algunos puntos de prueba no está clara y no sé qué probar durante la prueba.

Por ejemplo, cuando probamos el punto de prueba 1, no sabemos qué "datos de entrada normales" queremos probar. Existen problemas similares en el punto de prueba 5.

Problema 3: Operar siempre en entornos similares y realizar operaciones similares.

Existe una determinada secuencia de ejecución entre algunos puntos de prueba y estos puntos de prueba deben probarse juntos. Por ejemplo, ejecutar el punto de prueba 6 primero y luego ejecutar el punto de prueba 11 puede maximizar el uso del entorno de prueba anterior y los resultados de la prueba.

Pregunta 4: La descripción de los puntos de la prueba es demasiado aproximada, no sé si la prueba es correcta.

Algunos puntos de la prueba están escritos con mucha audacia y no sabemos cuáles son los objetivos de la prueba ni dónde enfocarnos. Por ejemplo, en el punto de prueba 4, no sabemos si juntamos las dos operaciones "el usuario envía un correo electrónico" y "el usuario recibe un correo electrónico", ¿dónde están sus "puntos de interacción"?

4.2 Método de diseño de pruebas de cuatro pasos

El procesamiento de puntos de prueba en casos de prueba se denomina diseño de prueba y el método utilizado en este proceso se denomina método de diseño de prueba. El análisis de ruta, las tablas de decisión, el análisis ortogonal, las clases de equivalencia, los valores límite, etc. son métodos comunes de diseño de pruebas.

En el análisis de prueba, podemos obtener puntos de prueba pensando en el objeto bajo prueba de acuerdo con el método de prueba, por lo que el análisis de prueba es un proceso de "descubrimiento", como se muestra en la Figura 14, pero el diseño de la prueba es diferente.

Figura 14 El análisis de pruebas es un proceso de “descubrimiento”

Puede hacer un experimento de este tipo y dejar que dos probadores analicen el mismo objeto de prueba según el "diagrama de rueda". Los puntos de prueba que obtengan no serán muy diferentes, pero los casos de prueba generados al final serán muy diferentes. Esto se debe a que, desde los puntos de prueba hasta el diseño de la prueba, procesaremos los puntos de prueba, los combinaremos y dividiremos, seleccionaremos datos de prueba, etc. Este es un proceso "creativo".

Figura 15 Los cuatro pasos clave del método de diseño de pruebas de cuatro pasos

Paso 1: Modelado

De hecho, en este paso, no les pedimos a todos que creen algunos modelos de prueba originales para cada punto de prueba, sino que seleccionen un modelo adecuado para el diseño de prueba posterior del punto de prueba de acuerdo con las características del punto de prueba. Quizás llamemos más apropiadamente a este paso "selección del modelo".

Dado que la "selección del modelo" requiere referencia a las características de los puntos de prueba, es esencial estudiar los puntos de prueba, analizar las características y clasificarlos. Actualmente los dividimos en cuatro categorías:

Tipo 1: "Proceso";

Tipo 2: "parámetro";

Tipo 3: "datos";

Tipo 4: "Combinado".

Para cada tipo de punto de prueba, hemos proporcionado algunos de los métodos de "modelado" más adecuados:

Para la clase "proceso", puede crear un modelo de prueba dibujando un "diagrama de flujo".

Para la clase "Parámetro", el modelo de prueba se puede establecer a través de la "Tabla de entradas y salidas".

Para la clase "datos", el modelo de prueba se puede establecer mediante la "tabla de análisis de clases de equivalencia".

Para la clase "combinada", el modelo de prueba se puede establecer mediante la "tabla de factores".

Paso 2: Diseñar casos de prueba básicos.

En este paso, diseñaremos algunos casos de prueba básicos para el modelo de prueba ya establecido para cubrir este modelo de prueba.

La mayor diferencia entre los casos de prueba y los casos de prueba básicos es que el caso de prueba determina las condiciones de la prueba (una descripción similar a "bajo las circunstancias de XX, realizar la prueba XX") y los datos de la prueba (es decir, el "valor del parámetro" de entrada o "valor numérico"), mientras que el caso de prueba básico solo determina las condiciones de prueba.

Paso 3: complementar los datos de la prueba.

En este paso, determinamos la entrada de prueba para el caso de prueba básico y complementamos los datos de prueba. En este momento, el caso de prueba básico se actualiza a un caso de prueba real.

Paso 4: expandir.

Los modelos no son soluciones mágicas y no pueden resolver todos los problemas al probar un diseño. También necesitamos agregar algunos casos de prueba basados ​​en la experiencia, especialmente la comprensión de dónde es probable que ocurran defectos en el sistema, para aumentar la efectividad del sistema.

Clasificar puntos de prueba

Antes de utilizar el método de prueba de cuatro pasos, primero debemos clasificar los puntos de prueba. La base para la clasificación es ver si los puntos de prueba tienen características del tipo "proceso", características del tipo "parámetro", características del tipo "datos" y características del tipo "combinación".

Supongo que te gusta

Origin blog.csdn.net/MXB_1220/article/details/132834581
Recomendado
Clasificación