C / S

C se refiere al cliente (Cliente), S se refiere al servidor (Servidor), este software se basa en la red de área local o en Internet, requiere un servidor para instalar el software del lado del servidor, cada cliente necesita instalar el software del cliente . Por ejemplo, QQ, que usamos a menudo, y varios juegos en línea pertenecen al software estructurado C / S.

B / S

B se refiere al navegador (Navegador), S se refiere al servidor (Servidor), este software también se basa en la red de área local o Internet, la diferencia entre este y el software de estructura C / S es que no es necesario instalar el cliente (cliente ), Siempre que tenga un navegador, puede usarlo directamente. Por ejemplo, los sitios web de portal como Sohu, Sina y 163 buzones son todos software estructurado B / S. El software estructurado B / S es la corriente principal del software actual. En comparación con el software estructurado C / S, es fácil de actualizar y mantener y es el foco de las pruebas.

Defecto [Error / Defecto]

Los errores de software se refieren a problemas en el software (incluidos programas y documentos) que no satisfacen las necesidades del usuario

Entorno de prueba

Un entorno de prueba de software es una plataforma en la que se ejecuta el software, que incluye una colección de software, hardware y redes. Use
una ecuación para expresar: entorno de prueba = software + hardware + red

Caso de prueba [Caso de prueba]

Un plan de prueba detallado diseñado antes de la ejecución de la prueba, que incluye el entorno de prueba, los pasos de prueba, los datos de prueba y los resultados esperados.
Utilice una ecuación para expresar simplemente: caso de prueba = entrada + salida + entorno de prueba
donde
"entrada" incluye datos de prueba y pasos de operación
"salida" se refiere al resultado esperado
"entorno de prueba" se refiere a la configuración del entorno del sistema

Prueba de humo [Prueba de humo]

Antes de realizar una prueba del sistema a gran escala en una nueva versión, primero verifique si se realizan las funciones básicas del software y si son comprobables
Inserte la descripción de la imagen aquí

Prueba de regresión

Compruebe si los problemas encontrados anteriormente se han modificado y si se generan nuevos errores. Las
pruebas de regresión significan que después de modificar el código anterior, vuelva a probar para confirmar que la modificación no introduce nuevos errores o causa errores en otro código. Las pruebas de regresión automática reducirán en gran medida el costo de las etapas de prueba, mantenimiento y actualización del sistema.
En todo el proceso de prueba de software, ocupa una gran proporción de la carga de trabajo, y se llevarán a cabo pruebas de regresión múltiple en cada etapa del desarrollo del software. Es significativo mejorar la eficiencia y la eficacia de las pruebas de regresión eligiendo la estrategia de prueba de regresión correcta.

Beta interna y pública

Prueba
interna : una vez realizado el software, se lo entregará a los usuarios reales, habrá problemas que no haya encontrado cuando lo usó, así que busque personal interno para usarlo en conjunto y ver si hay algún problema.
Beta pública:
igual que la beta interna, solo busca usuarios externos

Prueba alfa y prueba beta

€ Prueba alfa // La
prueba alfa importante es una prueba realizada por un usuario en el entorno de desarrollo, o puede ser una prueba realizada por un usuario dentro de la empresa en un entorno operativo real simulado. El propósito de la prueba alfa es evaluar los FLURPS de los productos de software (es decir, función, localización, usabilidad, confiabilidad, rendimiento y soporte).
Un tipo de prueba de aceptación se refiere a las pruebas internas de
software de propósito general a gran escala, participadas conjuntamente por usuarios, evaluadores, desarrolladores, etc. Antes del lanzamiento oficial, generalmente es necesario realizar pruebas Alfa y Beta. La prueba alfa no puede ser realizada por programadores o probadores.

€ Prueba beta (prueba beta) //
La prueba beta importante es una prueba de aceptación. Los usuarios finales del software llevan a cabo pruebas beta en una o más ubicaciones de las habitaciones.
La diferencia entre la prueba alfa y la prueba Beta:

Diferentes sitios de prueba: la prueba alfa se refiere a pedirles a los usuarios que realicen pruebas en las instalaciones del desarrollador, y las pruebas beta se refieren a las pruebas realizadas en una o más instalaciones del usuario.

El desarrollador controla el entorno de las pruebas Alpha, el número de usuarios es relativamente pequeño y el tiempo está relativamente concentrado. El desarrollador no controla el entorno de prueba beta, el número de usuarios es relativamente grande y el tiempo no está concentrado.

La prueba alfa se ejecuta antes de la prueba beta. Los productos de software generales requieren pruebas beta a gran escala, y el período de prueba es relativamente largo.

Prueba de cobertura

La cobertura es un medio para medir la integridad de la prueba, y también es una medida de la efectividad de la tecnología de prueba
Cobertura = (el número de elementos ejecutados al menos una vez) / el número total de elementos
(Alipay tiene 10,000 puntos de función, esta vez Se probaron 9,000 pruebas, es decir, 90% de cobertura)
Características:
1. A través de los datos de cobertura, podemos verificar si nuestra prueba es suficiente
2. Analizar las debilidades de la prueba
3. Guiarnos para diseñar pruebas que puedan aumentar la cobertura Los casos de uso mejoran efectivamente la calidad de las pruebas, pero el diseño de los casos de prueba no puede buscar cobertura, porque el costo de las pruebas aumenta al aumentar la cobertura.

La cobertura de prueba para pruebas de caja negra se refiere principalmente a dos aspectos:
Cobertura de requisitos y cobertura de casos de uso
Cobertura de la demanda
1. Definición: Indica qué funciones se probaron durante la prueba y con qué frecuencia se probaron, y qué porcentaje de estas funciones representaron en el sistema. Al diseñar ciertos casos de prueba, se requiere cada uno Los puntos de demanda han sido probados.
2. Fórmula de cálculo:需求覆盖= (被验证到的需求数量) / (总的需求总数)

Cobertura de casos de uso (elemento de medición muy crítico)
1. Definición: reflejada principalmente en la proporción del número de casos de uso que pasamos en cada ronda de verificación de prueba en el total de casos de uso
2. Fórmula de cálculo:用例覆盖= (验证通过的用例数量) / (总的用例总数)

Uso de cobertura de prueba

Cobertura de prueba simple : las 本次测试执行的用例数/所有用例数
estadísticas de cobertura anteriores se basan en la opinión de que el número total de casos de uso está escrito de forma exhaustiva y, por lo general, requiere una cobertura del 100% para las pruebas del sistema a gran escala

Principalmente pruebe los probadores para controlar la versión actual de la estrategia para asegurarse de que la tasa de cobertura cumpla con la estrategia de prueba.
覆盖率的审核:抽样验收

Cobertura de prueba basada en el producto: en función de las已测试需求点/设计所有需求数
dimensiones del producto y la demanda, no importa si los proyectos a gran escala o las iteraciones de pequeña demanda requieren una cobertura del 100%
, es mejor enviar este resultado al lado del producto, y el lado del producto juzgará si hay alguna omisión De
覆盖率的审核:抽样验收

Cobertura de prueba basada en recuadro blanco: la mayoría de las herramientas juzgan la cobertura de oraciones, es decir单元测试代码覆盖代码行/总代码行

Más personal de investigación y desarrollo; más a menudo requieren una tasa de cobertura del 80% +

缺陷:覆盖率数据只能代表测试过哪些代码，No se puede representar si el código se prueba bien; es fácil pasar por alto la lógica, el juicio y otros escenarios

Cobertura de prueba basada en automatización: escenarios de prueba (casos de prueba) cubiertos por automatización / todos los escenarios de prueba (casos de uso)

80/20原则.Por ejemplo, los usuarios utilizan el 20% de sus funciones el 80% del tiempo, y el 20% de las funciones pueden soportar sus escenarios empresariales más críticos. La selección de casos de uso de pruebas automatizadas se centra más en este 20% de las funciones principales.

Usos: no es 自动化测试更着重于回归验证，necesario buscar una cobertura excesiva, sino considerar el diseño del caso de uso (la prueba de regresión es el negocio principal del proceso)

El significado final de la cobertura de prueba

El lugar más utilizado es 测试停止标准，以及考核测试人员的标准
simplemente discutir la cobertura de la prueba, que no es importante en el modelo de desarrollo en cascada, sino en el modelo de desarrollo en espiral y ágil, debido a la iteración y acumulación continuas,很难确定哪些模块在开发过程中没有给予足够的测试

En 短迭代、DevOpsél, se pone más énfasis en usar la cobertura de prueba unitaria para evaluar la cantidad creciente de código