Ciclo de vida del software (prdctrm)
Etapa de planificación (planificación)->análisis de requisitos (requisito)->etapa de diseño (diseño)->codificación (codificación)->prueba (prueba)->operación y mantenimiento (ejecución de maintrnacne)
caso de prueba
Número de caso de uso Elemento de prueba Título de prueba Nivel de gravedad Condición previa Datos de entrada Paso de ejecución Resultado esperado
1. Pregunta: Encontraste un error en la prueba, pero el gerente de desarrollo cree que no es un error, ¿cómo deberías solucionarlo?
En primer lugar, envíe el problema a la biblioteca de gestión de defectos para su archivo.
Luego, para obtener la base y los criterios de juicio:
De acuerdo con la especificación de requisitos, la descripción del producto, los documentos de diseño, etc., confirme si los resultados reales son inconsistentes con el plan y proporcione una base directa para confirmar los defectos;
Si no hay base documental, se puede confirmar si hay un defecto basado en las características generales de un software similar para explicar si hay alguna inconsistencia;
De acuerdo con los hábitos generales de uso del usuario, para confirmar si se trata de un defecto;
Hable con el personal pertinente, como diseñadores, desarrolladores y representantes de clientes, para confirmar si se trata de un defecto;
Haga una discusión razonable, explique las razones de su juicio al administrador de la prueba, preste atención a la objetividad, al rigor y no mezcle emociones personales.
Espere a que el gerente de pruebas tome una decisión final. Si aún hay disputas, puede informar al superior a través de los canales provistos por la política de la empresa, y el superior tomará una decisión.
2. Pregunta: Dado un sitio web, ¿cómo lo prueba?
Primero, busque documentos relevantes, como la descripción de los requisitos y el diseño del sitio web, y analice los requisitos de prueba.
Haga un plan de prueba, determine el alcance de la prueba y la estrategia de prueba, que generalmente incluye las siguientes partes: prueba funcional, prueba de interfaz, prueba de rendimiento, prueba de base de datos, prueba de seguridad, prueba de compatibilidad
Diseño de casos de prueba:
Las pruebas funcionales pueden incluir, entre otros, los siguientes aspectos:
prueba de enlace Si el enlace salta correctamente, si hay páginas vacías y páginas no válidas, y si se devuelve un mensaje de error incorrecto.
Envíe una prueba de la función.
Si los elementos multimedia se pueden cargar y mostrar correctamente.
Si el soporte multilingüe puede mostrar correctamente el idioma seleccionado, etc.
Las pruebas de interfaz pueden incluir, entre otros, los siguientes aspectos:
Si el estilo de la página es uniforme y hermoso.
Si el diseño de la página es razonable, si el contenido clave y el contenido atractivo son prominentes.
Si el control funciona normalmente
Para los controles que se requieren pero no se instalan, ya sea para proporcionar la función de descarga e instalación automática
verificación de palabras
Las pruebas de rendimiento generalmente consideran los siguientes dos aspectos:
prueba de esfuerzo; prueba de carga; prueba de fuerza
La prueba de la base de datos debe determinarse específicamente si es necesario llevarla a cabo. Las bases de datos generalmente deben considerar la conectividad, las operaciones de acceso a los datos y la verificación del contenido de los datos.
Pruebas de seguridad:
Comprueba la funcionalidad básica de inicio de sesión
Si hay un error de desbordamiento, lo que provoca un bloqueo del sistema o una fuga de permisos
Verificaciones de problemas de seguridad comunes para lenguajes de desarrollo relacionados, como inyección SQL, etc.
Si se requieren pruebas de seguridad avanzadas, asegúrese de obtener ayuda de una empresa de seguridad profesional, externalice las pruebas u obtenga soporte.
Las pruebas de compatibilidad, de acuerdo con el contenido de la descripción del requisito, determinan las combinaciones de plataformas soportadas:
compatibilidad del navegador;
compatibilidad del sistema operativo;
Compatibilidad de plataformas de software;
Compatibilidad de base de datos
Se realizan pruebas y se registran los defectos. Organice y ajuste razonablemente el cronograma de pruebas, obtenga los recursos necesarios para las pruebas con anticipación y establezca un sistema de gestión (por ejemplo, cambios de requisitos, riesgos, configuraciones, documentos de prueba, informes de defectos, recursos humanos, etc.).
Revise, evalúe y resuma regularmente la prueba, y ajuste el contenido de la prueba.
3. Ingresar caracteres chinos en el motor de búsqueda puede resolver el nombre de dominio correspondiente, cómo usar LoadRunner para probar.
Establecer un plan de prueba, determinar el estándar de prueba y el alcance de la prueba
Diseñe casos de prueba para escenarios típicos, cubriendo procesos comerciales comunes y procesos comerciales poco comunes, etc.
De acuerdo con los casos de prueba, desarrolle scripts y escenarios de prueba automáticos:
Grabar secuencia de comandos de prueba: cree una nueva secuencia de comandos (protocolo Web/HTML); haga clic en el botón de grabación, ingrese "acerca de: en blanco" en la URL del cuadro de diálogo emergente; después del proceso de operación normal en el navegador abierto, finalice la grabación; depure la secuencia de comandos y guárdela, es posible que deba prestar atención a la asociación del conjunto de caracteres.
Configure escenarios de prueba: configure escenarios de prueba para el rendimiento, principalmente para determinar si el tiempo de respuesta de transacción promedio del sistema cumple con el estándar en circunstancias normales; configure escenarios de prueba para cargas de estrés, principalmente para determinar si el sistema colapsará en condiciones de carga completa o si excede la capacidad de carga del sistema durante mucho tiempo; realice pruebas, obtenga resultados de pruebas y analice resultados de pruebas
4. Pregunta: ¿Cuál es la diferencia entre un cliente con 300 clientes y 300 clientes con 300 clientes ejerciendo presión sobre el servidor?
300 usuarios en un cliente ocuparán más recursos del cliente y afectarán los resultados de la prueba. Pueden producirse interferencias entre subprocesos, lo que da lugar a algunas excepciones.
300 usuarios en un cliente requieren más ancho de banda.
Para problemas de dirección IP, es posible que deba usar IP Spoof para evitar el límite del servidor en la cantidad máxima de conexiones a una sola dirección IP.
Todos los usuarios están en un cliente, por lo que no es necesario considerar el tema de la administración distribuida; mientras que los usuarios están distribuidos en diferentes clientes, es necesario considerar el uso del controlador para implementar usuarios en diferentes clientes como un todo. Al mismo tiempo, también debe dar la configuración de permisos correspondiente y la configuración del firewall.
5. Describe el concepto y las características del software, el significado de reutilización de software, ¿qué componentes incluye?
El software es otra parte del sistema informático que es interdependiente con el hardware, los programas informáticos, los procedimientos, las reglas y los posibles archivos, documentos y datos relacionados con el funcionamiento del sistema informático.
La reutilización de software (reutilización de software) consiste en utilizar todo tipo de conocimiento relevante del software existente para crear software nuevo, a fin de reducir el costo de desarrollo y mantenimiento del software. La reutilización de software es una tecnología importante para mejorar la productividad y la calidad del software. La reutilización temprana de software fue principalmente reutilización a nivel de código, y el conocimiento reutilizado se refiere a programas, y luego se amplió para incluir todos los aspectos relevantes, como el conocimiento del dominio, la experiencia de desarrollo, las decisiones de diseño, la arquitectura, los requisitos, el diseño, el código y la documentación.
Los componentes de software que se pueden reutilizar generalmente se denominan componentes reutilizables.
6. ¿Qué es el ciclo de vida del software y su modelo?
El ciclo de vida del software (Software life cycle) también se denomina ciclo de vida del software, período de supervivencia. Se refiere a todo el proceso desde la formación del concepto de desarrollo de software hasta el uso del software desarrollado hasta que pierde su valor de uso y muere. En términos generales, el ciclo de vida completo incluye tres períodos: planificación (definición), desarrollo y operación (mantenimiento), y cada período se divide en varias etapas. Cada etapa tiene tareas claras.
Modelos periódicos (tipos típicos):
modelo de cascada
Modelo de creación rápida de prototipos: El modelo de creación rápida de prototipos permite el análisis y la definición preliminares pero no completos de los requisitos del software en la etapa de análisis de requisitos, y el diseño y desarrollo rápidos de un prototipo del sistema de software, que muestra a los usuarios todas o parte de las funciones y el rendimiento del software que se va a desarrollar; los usuarios prueban y evalúan el prototipo, y brindan sugerencias de mejora específicas para enriquecer y refinar los requisitos del software; los desarrolladores modifican y mejoran el software en consecuencia.
Modelo de iteración: una iteración incluye todas las actividades de desarrollo que dan como resultado una versión del producto (versión estable y ejecutable del producto) y todos los demás elementos periféricos necesarios para usar esa versión. En cierto modo, una iteración de desarrollo es un proceso que pasa por todos los flujos de trabajo de una sola vez: análisis de requisitos, diseño, implementación y flujos de trabajo de prueba. En esencia, es como un pequeño proyecto Waterfall. RUP cree que todas las etapas se pueden subdividir en iteraciones. Cada iteración produce un producto liberable que es un subconjunto del producto final.
Fases del ciclo de vida:
Análisis de viabilidad y planificación de software
análisis de la demanda
diseño de software
codificación
prueba de software
Operación y mantenimiento
7. ¿Qué son las pruebas de software? El propósito y los principios de las pruebas de software
El proceso de operar un programa bajo condiciones específicas para encontrar errores de programa, medir la calidad del software y evaluar si cumple con los requisitos de diseño.
Propósito de las pruebas de software:
La prueba es la ejecución de un programa para encontrar errores.
Un caso de prueba exitoso consiste en encontrar errores no descubiertos hasta ahora
Una prueba exitosa es aquella que encuentra un error no descubierto hasta ahora.
Asegúrese de que el producto haga lo que promete o anuncia, y que las funciones a las que pueden acceder los usuarios estén claramente documentadas.
Asegúrese de que los productos cumplan con los requisitos de rendimiento y eficiencia.
Asegúrese de que el producto sea robusto y adaptable al entorno del usuario
Principios de las pruebas de software:
Una parte obligatoria de un caso de prueba es la definición del resultado esperado o
Los programadores deben evitar probar los programas que escriben
Las organizaciones que escriben software no deben probar el software que escriben
Los resultados de ejecución de cada prueba deben verificarse minuciosamente.
Los casos de prueba deben escribirse no solo para entradas válidas y esperadas, sino también para entradas no válidas e inesperadas.
Comprobar que el programa "no hace lo que se supone que debe hacer" es solo la mitad de la prueba, la otra mitad de la prueba es comprobar que el programa "hace lo que se supone que no debe hacer"
Se deben evitar los casos de prueba desechables a menos que el software en sí sea un software de un solo uso
Al planificar un esfuerzo de prueba, no se debe suponer tácitamente que no se encontrarán errores
La probabilidad de que una parte de un programa tenga más errores, proporcional al número de errores ya encontrados en esa parte
La prueba de software es un trabajo extremadamente creativo e intelectualmente desafiante.
8. ¿Cuál es el papel de la gestión de la configuración del software?¿Qué incluye la configuración del software?
La gestión de configuración de software (SCM) es una técnica para identificar, organizar y controlar cambios. La gestión de configuración de software se aplica a todo el proceso de ingeniería de software. El cambio es inevitable cuando se construye software, y el cambio exacerba la confusión entre los desarrolladores de software en un proyecto. Los objetivos de las actividades de SCM son identificar cambios, controlar cambios, garantizar que los cambios se implementen correctamente e informar cambios a otras partes interesadas. En cierto sentido, SCM es una técnica para identificar, organizar y controlar cambios para minimizar errores y maximizar la productividad.
La configuración del software incluye lo siguiente: identificación de elementos de configuración, gestión del espacio de trabajo, control de versiones, control de cambios, informes de estado, auditoría de configuración
9. ¿Qué es la calidad del software?
En pocas palabras, la calidad del software es "el grado en que el software se ajusta a los requisitos definidos explícita e implícitamente". Específicamente, la calidad del software es el grado en que el software se ajusta a los requisitos funcionales y de rendimiento establecidos explícitamente, los estándares de desarrollo descritos explícitamente en la documentación y las características implícitas que debe tener todo el software desarrollado profesionalmente. Los principales factores que afectan la calidad del software, estos factores son la medición de la calidad del software desde el punto de vista de la gestión. Se puede dividir en tres grupos, que reflejan respectivamente los tres puntos de vista de los usuarios cuando utilizan productos de software. Corrección, robustez, eficiencia, integridad, facilidad de uso, riesgo (operación del producto); comprensibilidad, mantenibilidad, flexibilidad, capacidad de prueba (modificación del producto); portabilidad, reutilización, interoperabilidad (transferencia del producto).
10. ¿Cuál es el método de diseño de caso de prueba principal actual?
Pruebas de caja blanca: cobertura lógica, cobertura de bucle, cobertura de ruta básica
Pruebas de caja negra: análisis de valor límite, división de clase de equivalencia, adivinación de errores, diagrama de causa y efecto, diagrama de estado, esquema de prueba, prueba aleatoria, escenario
11. ¿Desde qué aspectos se debe probar la seguridad del software?
Las pruebas de seguridad del software incluyen pruebas de seguridad de programas y bases de datos. De acuerdo con los diferentes indicadores de seguridad del sistema, las estrategias de prueba también son diferentes.
Cuestiones a tener en cuenta en la prueba de seguridad de autenticación de usuario: distinguir claramente entre diferentes derechos de usuario en el sistema, si habrá conflictos de usuario en el sistema, si el sistema causará confusión debido a cambios en los derechos de usuario, si la contraseña de inicio de sesión del usuario es visible y reproducible, si es posible iniciar sesión en el sistema a través de un método absoluto (copie el enlace después de que el usuario inicie sesión e ingrese directamente al sistema), si todas las marcas de autenticación se eliminan después de que el usuario cierra sesión en el sistema, si es posible usar el botón Atrás para ingresar al sistema sin ingresar una contraseña, el sistema la prueba de seguridad de la red debe considerar los problemas, si las medidas de protección tomadas por la prueba están instaladas correctamente, si se aplican los parches del sistema relevantes, ataques no autorizados simulados, verificar si el sistema de protección es sólido, usar herramientas de inspección de vulnerabilidades de red maduras para verificar las vulnerabilidades relacionadas con el sistema (es decir, usar las herramientas de piratería más profesionales para atacar, las más utilizadas son la serie NBSI e IPhacker IP), usar varias herramientas de inspección de caballos de Troya para verificar los caballos de Troya del sistema, usar varias herramientas anti-complementos para verificar las vulnerabilidades de los complementos de varios grupos de programas en el sistema
Consideraciones de seguridad de la base de datos: si los datos del sistema son confidenciales (por ejemplo, para el sistema bancario, esto es particularmente importante y los sitios web generales no tienen requisitos demasiado altos), la integridad de los datos del sistema (el sistema de servicio de verificación de nombre real de la empresa que acabo de completar tenía datos incompletos, lo que dificultó la realización de funciones de este sistema), la capacidad de administración de los datos del sistema, la independencia de los datos del sistema, las capacidades de copia de seguridad y recuperación de los datos del sistema (si la copia de seguridad de datos está completa, si se puede restaurar, si se puede completar la restauración)
12. ¿Qué es un caso de prueba, qué es un script de prueba y cuál es la relación entre los dos?
Un conjunto específico de datos de entrada, operación o varias configuraciones ambientales y resultados esperados proporcionados al sistema bajo prueba para la implementación de la prueba.
Los scripts de prueba son scripts escritos para pruebas automatizadas.
La redacción de scripts de prueba debe corresponder a los casos de prueba correspondientes
13. Describa brevemente qué es la prueba estática, la prueba dinámica, la prueba de caja negra, la prueba de caja blanca, la prueba alfa y la prueba beta.
La prueba estática es el proceso de encontrar posibles errores en el código del programa o evaluar el código del programa sin ejecutar el programa en sí.
La prueba dinámica consiste en ejecutar realmente el programa bajo prueba, ingresar la instancia de prueba correspondiente, verificar la diferencia entre el resultado de la ejecución y el resultado esperado, y determinar si el resultado de la ejecución cumple con los requisitos, para verificar la corrección, confiabilidad y efectividad del programa, y analizar el rendimiento de la eficiencia operativa y la solidez del sistema.
Las pruebas de caja negra generalmente se utilizan para confirmar la corrección y la operabilidad de las funciones del software. El propósito es detectar si cada función del software se puede realizar. El programa probado se considera como una caja negra, independientemente de su estructura interna. En el caso de conocer la relación entre la entrada y la salida del programa o la función del programa, confíe en la especificación del software para determinar la corrección de los casos de prueba e inferir los resultados de la prueba.
La prueba de caja blanca se realiza en función del análisis de la estructura lógica del software. Es una prueba basada en código. Los probadores juzgan la calidad del software leyendo el código del programa o usando la depuración de un solo paso en la herramienta de desarrollo. Generalmente, el gerente del proyecto implementa la prueba de caja negra durante el desarrollo del programador.
La prueba alfa es una prueba realizada por un usuario en un entorno de desarrollo, o puede ser una prueba controlada realizada por usuarios dentro de la empresa en un entorno operativo real simulado. La prueba alfa no puede ser realizada por programadores o evaluadores.
La prueba beta es una prueba realizada por múltiples usuarios del software en el entorno de uso real de uno o más usuarios. Los desarrolladores generalmente no están presentes en el sitio de prueba, y los programadores o evaluadores no pueden realizar pruebas beta.
14. ¿Qué es el sistema de aseguramiento de la calidad del software?, ¿cuáles son los estándares nacionales relacionados con la gestión del aseguramiento de la calidad?, ¿cuáles son sus números de serie y nombres completos?
SQA consiste en un conjunto de procesos y métodos de ingeniería de software para asegurar la calidad (del software). SQA se ejecuta a través de todo el proceso de desarrollo de software, (debe) incluir la revisión de documentos de requisitos, control de código, revisión de código, gestión de cambios, gestión de configuración, gestión de versiones y pruebas de software.
Software Quality Assurance (SQA-Software Quality Assurance) es establecer un método planificado y sistemático para asegurar a la gerencia que los estándares, procedimientos, prácticas y métodos propuestos pueden ser adoptados correctamente por todos los proyectos. El propósito del aseguramiento de la calidad del software es hacer que el proceso del software sea visible para la gerencia. Verifica que el software cumpla con los estándares mediante la realización de revisiones y auditorías de productos y actividades de software. El grupo de aseguramiento de la calidad del software está involucrado en el establecimiento de planes, estándares y procesos al comienzo del proyecto. Esto permitirá que el proyecto de software cumpla con los requisitos de la política de la agencia.
15. ¿Cuáles son las características de calidad de los productos de software?
Funcionalidad: adaptabilidad, precisión, interoperabilidad, cumplimiento, seguridad.
Confiabilidad: madurez, tolerancia a fallas, fácil recuperación.
Usabilidad: fácil de entender, fácil de aprender, fácil de operar.
Eficiencia: características del tiempo, características del recurso.
Mantenibilidad: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.
Portabilidad: adaptabilidad, facilidad de instalación, cumplimiento, facilidad de reemplazo
16. ¿Cuál es la estrategia de pruebas de software?
Estrategia de prueba de software: bajo la guía de ciertos estándares de prueba de software y especificaciones de prueba, la colección de principios, métodos y métodos de prueba de software estipulados de acuerdo con las restricciones ambientales específicas del proyecto de prueba.
17. Las pruebas de software se dividen en varias etapas y ¿cuáles son las estrategias y requisitos de prueba para cada etapa?
En correspondencia con el proceso de desarrollo, el proceso de prueba pasará por cuatro etapas principales: prueba unitaria, prueba de integración, prueba del sistema y prueba de aceptación:
Prueba unitaria: la prueba unitaria es el trabajo de prueba para la unidad más pequeña de diseño de software: módulo de programa o incluso segmento de código para verificar la corrección, generalmente realizado por desarrolladores.
Prueba de integración: la prueba de integración es ensamblar los módulos de acuerdo con los requisitos de diseño para la prueba, el objetivo principal es encontrar problemas relacionados con la interfaz. Dado que el equipo de desarrollo del producto debe realizar una depuración conjunta antes de enviar el producto al departamento de pruebas, los desarrolladores de la mayoría de las empresas realizan las pruebas de integración.
Prueba del sistema: la prueba del sistema se lleva a cabo después de pasar la prueba de integración, el propósito es ejecutar completamente el sistema, verificar si cada subsistema puede funcionar normalmente y cumplir con los requisitos de diseño. La lleva a cabo principalmente el departamento de pruebas, es la prueba más grande e importante en el departamento de pruebas y tiene un impacto significativo en la calidad del producto.
Prueba de aceptación: la prueba de aceptación toma la "Especificación de requisitos" en la fase de requisitos como estándar de aceptación, y la prueba requiere simular el entorno operativo real del usuario. Para proyectos reales, se puede realizar junto con los clientes, y para productos, es la última prueba del sistema. El contenido de la prueba es una prueba completa de los módulos funcionales, especialmente la prueba del documento.
Estrategia de prueba de prueba unitaria:
Estrategia de pruebas unitarias de arriba hacia abajo: Mucho más costosa que las pruebas unitarias aisladas, no es una buena opción para las pruebas unitarias.
Estrategia de prueba unitaria ascendente: una estrategia de prueba unitaria más razonable, pero el ciclo de prueba es más largo.
Estrategias para pruebas unitarias de forma aislada: Las mejores estrategias de pruebas unitarias.
Estrategia de prueba para pruebas de integración:
Big Bang Integration: adecuado para un proyecto de mantenimiento o el sistema bajo prueba es pequeño
Integración de arriba hacia abajo: es adecuada para que la estructura de control del producto sea clara y estable; la interfaz de alto nivel cambia poco; la interfaz de bajo nivel no está definida o puede modificarse con frecuencia; los componentes de control de producción y puerto tienen grandes riesgos técnicos y deben verificarse lo antes posible; espero ver el comportamiento funcional del sistema del producto lo antes posible.
Integración ascendente: la interfaz de nivel inferior es relativamente estable; la interfaz de nivel superior cambia con frecuencia; los componentes de nivel inferior se completan antes.
Integración basada en el progreso
Ventajas: Tiene un alto grado de paralelismo, puede acortar efectivamente el progreso de desarrollo del proyecto.
Desventajas: los pilotes y los hincadores tienen una gran carga de trabajo; algunas pruebas de interfaz son insuficientes; algunas pruebas se repiten y son inútiles.
Estrategia de prueba para la prueba del sistema:
Pruebas de integridad de datos y bases de datos; pruebas funcionales; pruebas de interfaz de usuario; pruebas de rendimiento; pruebas de carga; pruebas de fuerza; pruebas de capacidad; pruebas de seguridad y control de acceso; pruebas de conmutación por error y recuperación; pruebas de configuración; pruebas de instalación; pruebas de cifrado; pruebas de usabilidad; pruebas de verificación de versión; pruebas de documentación
18. ¿Qué trabajo se suele realizar en cada fase de pruebas de software?, ¿cuál es el archivo de resultados de cada fase?, ¿qué se incluye?
Etapa de prueba de unidad: cada módulo de unidad independiente se prueba de forma aislada de otras partes del sistema.La prueba de unidad verifica la corrección de cada módulo de programa para verificar si cada módulo de programa ha implementado correctamente las funciones especificadas. Genere informes de prueba de unidad y envíe informes de defectos.
Fase de prueba de integración: la prueba de integración se basa en la prueba unitaria y comprueba si todas las unidades de software se ensamblan en módulos, subsistemas o sistemas de acuerdo con los requisitos de la especificación de diseño general para ver si el trabajo de cada parte cumple o realiza los indicadores y requisitos técnicos correspondientes. En esta fase, se genera un informe de prueba de integración y se envía un informe de defectos.
Fase de prueba del sistema: el software que ha pasado la prueba de confirmación se utiliza como un elemento de todo el sistema informático, combinado con otros elementos del sistema, como hardware, periféricos, algún software de soporte, datos y personal, para cubrir completamente las funciones del sistema informático en el entorno operativo real. En esta etapa, se debe enviar el resumen de la prueba y el informe de defectos.
19. ¿Cuál es la tarea de un probador en el proceso de desarrollo de software?
1. Descubra los errores en el sistema lo antes posible;
2. Evitar defectos en el proceso de desarrollo de software;
3. Medir la calidad del software y asegurar la calidad del sistema;
4. Preste atención a las necesidades de los usuarios y asegúrese de que el sistema satisfaga las necesidades de los usuarios.
El objetivo general es: garantizar la calidad del software.
20. En su trabajo anterior, ¿qué se incluía en un registro de defectos (o errores) de software?¿Cómo enviar un registro de defectos (errores) de software de alta calidad?
Un registro de error debe incluir básicamente:
Número de error; nivel de gravedad del error, prioridad; el módulo donde se generó el error; en primer lugar, debe haber un resumen del error que explique el contenido general del error; la versión correspondiente del error; una descripción detallada del error, incluidas algunas capturas de pantalla, videos, etc.; el entorno de prueba cuando ocurre el error y las condiciones que se generan son los pasos de operación correspondientes; registros de errores de alta calidad:
1) La interfaz de usuario general debe ser unificada y precisa. La interfaz de usuario del informe de defectos debe ser coherente con la interfaz de usuario del software probado, de modo que sea fácil de encontrar y localizar. 2) Trate de usar los términos y métodos comúnmente usados en la industria Use los términos y métodos comúnmente usados en la industria para asegurar una expresión precisa y profesional. 3) Cada informe de defectos incluye solo un defecto Cada informe de defectos solo incluye un defecto, lo que permite que el solucionador de defectos localice rápidamente un defecto y se concentre en corregir solo un defecto a la vez. El verificador solo verifica si un defecto ha sido corregido correctamente a la vez. 4) También se deben informar los defectos no reproducibles. En primer lugar, el informe del defecto debe demostrar la capacidad de reproducir el defecto. Los defectos no reproducibles deben reproducirse tanto como sea posible. Si el defecto no se puede reproducir después de todos los esfuerzos, el defecto aún debe informarse, pero el informe debe indicar la frecuencia de ocurrencia del defecto que no se puede reproducir. 5) Especificar claramente el tipo de defecto Basándose en el fenómeno del defecto, se resume y juzga el tipo de defecto. Por ejemplo, es decir, defectos funcionales, defectos de interfaz, defectos de datos, la racionalización sugiere que este es el defecto o tipo de defecto más común, y otras formas de defectos o defectos también están subordinados a una de las formas. 6) Indique claramente la gravedad y la prioridad del defecto Aclare siempre la diferencia entre gravedad y prioridad. Es posible que no valga la pena solucionar los problemas de alta gravedad, y los problemas cosméticos pequeños pueden considerarse de alta prioridad. 7) Descripción, concisa, precisa y completa, que revele la esencia del defecto, registre el defecto o la ubicación donde ocurre el defecto. La descripción debe reflejar con precisión la esencia del defecto, ser breve y clara. Para facilitar la búsqueda de defectos de prueba formulados en la base de datos de gestión de defectos de software, es un buen hábito incluir la interfaz de usuario (IU) cuando se produce el defecto. Por ejemplo, el título del cuadro de diálogo de registro, el nombre del menú, botón y otros controles. 8) Use números de serie numéricos automáticos entre líneas cortas, use la misma fuente, tamaño de fuente y espacio entre líneas Use números de serie numéricos automáticos entre líneas cortas, use la misma fuente, tamaño de fuente y espacio entre líneas, para garantizar que el formato de cada registro sea consistente y para lograr la estandarización y el profesionalismo. 9) Trate de registrar solo una operación para cada paso para garantizar la concisión, el orden y la fácil repetición de los pasos de la operación. 10) Confirme que los pasos sean completos, precisos y breves para garantizar una repetición rápida y precisa de los defectos. "Completo" significa que no hay omisiones, "preciso" significa que los pasos son correctos y "breve" significa que no hay pasos redundantes. 11) Según el defecto, puede elegir si desea realizar una captura de imagen. Para observar visualmente el defecto o el fenómeno del defecto, generalmente es necesario adjuntar el defecto o la interfaz donde aparece el defecto, y adjuntarlo a la parte "adjunto" del registro como un archivo adjunto en forma de imagen. Para ahorrar espacio y reflejar verdaderamente el defecto o la esencia del defecto, puede capturar la pantalla completa, la ventana activa y el área local cuando ocurre el defecto o defecto. Para localizar y corregir defectos o ubicaciones de defectos rápidamente, generalmente se requiere adjuntar un mapa de control chino. Adjunte los documentos especiales necesarios y las sugerencias y comentarios personales. Si se produce un defecto o defecto cuando se abre un documento en particular, se debe adjuntar el documento para que el defecto o defecto se pueda reproducir rápidamente. A veces, para que el defecto o el corrector de defectos aclare aún más el defecto o la realización del defecto, se pueden adjuntar sugerencias o comentarios de modificación personal. 12) Verificar errores ortográficos y gramaticales Antes de enviar cada defecto o defecto, verifique la ortografía y la gramática para asegurarse de que el contenido sea correcto y describa el defecto correctamente. 13) Use frases y oraciones cortas tanto como sea posible para evitar patrones de oraciones complejos. El propósito de la base de datos de gestión de defectos de software es facilitar la localización de defectos. Por lo tanto, se requiere describir los pasos de la operación de manera objetiva, sin modificar el vocabulario y los patrones de oraciones complejos, para mejorar la legibilidad. Lo anterior resume los requisitos estándar para informar defectos de prueba.Con diferentes requisitos de prueba de software, los evaluadores desarrollarán gradualmente buenos hábitos profesionales después de pruebas a largo plazo y acumularán la experiencia de prueba correspondiente, y agregarán constantemente nuevos requisitos de escritura de especificaciones. Además, puede mejorar constantemente sus habilidades leyendo y estudiando los informes de defectos de prueba de otros ingenieros de pruebas, y comparando y pensando con sus propios informes de defectos de prueba anteriores. 14) Contenido de la descripción del defecto El contenido de la descripción del defecto puede incluir pasos de la operación del defecto, resultados reales y resultados esperados. Los pasos de operación pueden hacer que sea más fácil para los desarrolladores reproducir defectos y corregirlos. Algunos desarrolladores tienen poca capacidad para reproducir defectos. Aunque entienden los defectos a los que se refiere, simplemente no pueden reproducirlos. Especialmente para los nuevos desarrolladores que no están familiarizados con el sistema, los pasos de introducción pueden facilitar su reproducción. Los resultados reales les permiten a los desarrolladores saber qué estaba mal y los resultados esperados les permiten saber cuál debería ser el resultado correcto. Use frases y oraciones cortas tanto como sea posible para evitar patrones de oraciones complejos. El propósito de la base de datos de gestión de defectos de software es facilitar la localización de defectos. Por lo tanto, se requiere describir los pasos de la operación de manera objetiva, sin modificar el vocabulario y los patrones de oraciones complejos, para mejorar la legibilidad. Lo anterior resume los requisitos estándar para informar defectos de prueba.Con diferentes requisitos de prueba de software, los evaluadores desarrollarán gradualmente buenos hábitos profesionales después de pruebas a largo plazo y acumularán la experiencia de prueba correspondiente, y agregarán constantemente nuevos requisitos de escritura de especificaciones. Además, puede mejorar constantemente sus habilidades leyendo y estudiando los informes de defectos de prueba de otros ingenieros de pruebas, y comparando y pensando con sus propios informes de defectos de prueba anteriores. 14) Contenido de la descripción del defecto El contenido de la descripción del defecto puede incluir pasos de la operación del defecto, resultados reales y resultados esperados. Los pasos de operación pueden hacer que sea más fácil para los desarrolladores reproducir defectos y corregirlos. Algunos desarrolladores tienen poca capacidad para reproducir defectos. Aunque entienden los defectos a los que se refiere, simplemente no pueden reproducirlos. Especialmente para los nuevos desarrolladores que no están familiarizados con el sistema, los pasos de introducción pueden facilitar su reproducción. Los resultados reales les permiten a los desarrolladores saber qué estaba mal y los resultados esperados les permiten saber cuál debería ser el resultado correcto. Use frases y oraciones cortas tanto como sea posible para evitar patrones de oraciones complejos. El propósito de la base de datos de gestión de defectos de software es facilitar la localización de defectos. Por lo tanto, se requiere describir los pasos de la operación de manera objetiva, sin modificar el vocabulario y los patrones de oraciones complejos, para mejorar la legibilidad. Lo anterior resume los requisitos estándar para informar defectos de prueba.Con diferentes requisitos de prueba de software, los evaluadores desarrollarán gradualmente buenos hábitos profesionales después de pruebas a largo plazo y acumularán la experiencia de prueba correspondiente, y agregarán constantemente nuevos requisitos de escritura de especificaciones. Además, puede mejorar constantemente sus habilidades leyendo y estudiando los informes de defectos de prueba de otros ingenieros de pruebas, y comparando y pensando con sus propios informes de defectos de prueba anteriores. 14) Contenido de la descripción del defecto El contenido de la descripción del defecto puede incluir pasos de la operación del defecto, resultados reales y resultados esperados. Los pasos de operación pueden hacer que sea más fácil para los desarrolladores reproducir defectos y corregirlos. Algunos desarrolladores tienen poca capacidad para reproducir defectos. Aunque entienden los defectos a los que se refiere, simplemente no pueden reproducirlos. Especialmente para los nuevos desarrolladores que no están familiarizados con el sistema, los pasos de introducción pueden facilitar su reproducción. Los resultados reales les permiten a los desarrolladores saber qué estaba mal y los resultados esperados les permiten saber cuál debería ser el resultado correcto.
21. Las pruebas de caja negra y las pruebas de caja blanca son dos métodos básicos de prueba de software. ¡Explique sus respectivas ventajas y desventajas!
Las ventajas de las pruebas de caja negra son: relativamente simple, no es necesario comprender el código interno y la implementación del programa; no tiene nada que ver con la implementación interna del software; desde el punto de vista del usuario, es fácil saber qué funciones usará el usuario y qué problemas encontrará; según el documento de desarrollo de software, también es posible saber qué funciones implementa el software en el documento; es más conveniente cuando se realizan pruebas de automatización de software.
Las desventajas de las pruebas de caja negra son: es imposible cubrir todo el código y la tasa de cobertura es baja, que solo puede alcanzar el 30% del volumen total del código; la reutilización de las pruebas automatizadas es baja.
Las ventajas de las pruebas de caja blanca son: ayudar a los evaluadores de software a aumentar la cobertura del código, mejorar la calidad del código y descubrir problemas ocultos en el código.
Las desventajas de las pruebas de caja blanca son: habrá muchas rutas diferentes en la ejecución del programa y es imposible probar todas las rutas en ejecución; la prueba se basa en el código y solo puede probar si el desarrollador tiene razón, pero no puede saber si el diseño es correcto o no, y se pueden pasar por alto algunos requisitos funcionales; cuando el sistema es enorme, la sobrecarga de la prueba será muy grande.
22. ¿Cómo probar un vaso de papel?
Funcionalidad: llene agua en una taza de agua para ver si tiene fugas; si el agua se puede beber
Seguridad: ¿Hay algún veneno o bacteria en la taza?
Fiabilidad: el grado de daño de la taza caída desde diferentes alturas
Portabilidad: si la copa se puede usar normalmente en diferentes lugares, temperaturas y otros entornos
Compatibilidad: si la copa puede contener jugo, agua blanca, alcohol, gasolina, etc.
Facilidad de uso: si la taza está caliente, si tiene medidas antideslizantes y si es conveniente beber
Documentación del usuario: ¿El manual del usuario describe en detalle el uso, las restricciones y las condiciones de uso de la copa?
Prueba de fatiga: Llene el vaso con agua (caso 1) y déjelo durante 24 horas para comprobar el tiempo y la situación de la fuga; llénelo con gasolina (caso 2) y déjelo durante 24 horas para comprobar el tiempo y la situación de la fuga, etc.
Prueba de estrés: use una aguja y siga agregando peso sobre ella para ver cuánta presión penetrará
22. ¿Cuál es el propósito del trabajo del plan de prueba? ¿Qué debe incluirse en el documento del plan de prueba? ¿Cuál de ellos es el más importante?
Un plan de prueba de software es un documento programático que guía el proceso de prueba:
Los líderes pueden llevar a cabo un macrocontrol de acuerdo con el plan de prueba y llevar a cabo la asignación de recursos correspondiente, etc.
Los evaluadores pueden comprender toda la situación de prueba del proyecto y el trabajo a realizar en las diferentes etapas de la prueba del proyecto, etc.
Es conveniente que otro personal comprenda el contenido del trabajo del probador y lleve a cabo un trabajo de cooperación relevante
Incluye descripción general del producto, estrategia de prueba, método de prueba, área de prueba, configuración de prueba, ciclo de prueba, recurso de prueba, comunicación de prueba, análisis de riesgos, etc. Con la ayuda del plan de prueba de software, los miembros del proyecto involucrados en la prueba, especialmente los gerentes de prueba, pueden aclarar las tareas y los métodos de prueba, mantener una comunicación fluida en el proceso de implementación de la prueba, rastrear y controlar el progreso de la prueba y lidiar con varios cambios en el proceso de prueba.
Plan de prueba escribiendo 6 elementos (5W1H):
por qué - por qué se realizan estas pruebas;
qué: qué aspectos probar, el contenido del trabajo en diferentes etapas;
cuándo—prueba los tiempos de inicio y finalización de las diferentes etapas;
dónde: documentos correspondientes, lugar de almacenamiento de defectos, entorno de prueba, etc.;
quién: la composición del personal relevante del proyecto, qué probadores están dispuestos a probar;
cómo—cómo hacerlo, qué herramientas de prueba y métodos de prueba usar para probar
Existe una relación estratégica y táctica entre el plan de prueba y la especificación de prueba y los casos de prueba. El plan de prueba planifica principalmente el alcance, el método y la asignación de recursos de la actividad de prueba desde una perspectiva macro, mientras que la especificación de prueba y los casos de prueba son las tácticas específicas para completar la tarea de prueba. Entonces, lo más importante es probar la estrategia de prueba y el método de prueba (lo mejor es poder revisar primero).
23. ¿Cuáles son los métodos comunes de diseño de casos de prueba para pruebas de caja negra? Utilice ejemplos específicos para ilustrar la aplicación de estos métodos en el diseño de casos de prueba.
1) División de clase de equivalencia: La clase de equivalencia se refiere a un subconjunto de un campo de entrada. En este subconjunto, cada dato de entrada equivale a revelar el error en el programa. Es razonable suponer que: probar un valor representativo de una cierta clase de equivalencia es igual a probar otros valores de esta clase. Por lo tanto, todos los datos de entrada se pueden dividir razonablemente en varias clases de equivalencia, y se puede usar una pequeña cantidad de datos de prueba representativos para obtener mejores resultados. La división de clase de equivalencia puede tener dos situaciones diferentes: clases de equivalencia efectivas y clases de equivalencia nulas.
2) Método de análisis de valor límite: es un complemento del método de división de clases de equivalencia. La experiencia del trabajo de prueba me dice que una gran cantidad de errores ocurren en el límite del rango de entrada o salida, en lugar de dentro del rango de entrada y salida. Por lo tanto, diseñar casos de prueba para varias condiciones de límite puede detectar más errores.
Cuando se utiliza el método de análisis de valor límite para diseñar casos de prueba, las condiciones límite deben determinarse primero. Por lo general, los límites de las clases de equivalencia de entrada y salida son las condiciones límite que deben centrarse en las pruebas. Los valores que son exactamente iguales, apenas mayores o menores que el límite deben seleccionarse como datos de prueba, en lugar de valores típicos o valores arbitrarios en la clase de equivalencia que se seleccionan como datos de prueba.
3) Método de adivinación de errores: basado en la experiencia y la intuición para especular todos los posibles errores en el programa, a fin de diseñar casos de prueba de manera específica.
La idea básica del método de adivinación de errores: enumere todos los errores posibles en el programa y los casos especiales en los que es probable que ocurran errores, y seleccione los casos de prueba de acuerdo con ellos. Por ejemplo, se enumeraron muchos errores comunes en los módulos durante las pruebas unitarias. Errores encontrados en pruebas de productos anteriores, etc. Estos son el resumen de la experiencia. Además, los datos de entrada y los datos de salida son 0. El formulario de entrada está en blanco o el formulario de entrada tiene solo una línea.
4) Método de diagrama de causa y efecto: el método de división de clase de equivalencia y el método de análisis de valor límite presentados anteriormente se centran en la consideración de las condiciones de entrada, pero no consideran la relación entre las condiciones de entrada, la combinación mutua, etc. Teniendo en cuenta la combinación mutua de las condiciones de entrada, pueden surgir algunas situaciones nuevas. Pero no es una tarea fácil verificar la combinación de las condiciones de entrada. Incluso si todas las condiciones de entrada se dividen en clases de equivalencia, hay muchas combinaciones entre ellas. Es necesario usar un diagrama causal (modelo lógico). El resultado final del método de diagrama causal es una tabla de decisión Es adecuada para verificar varias combinaciones de condiciones de entrada del programa.
5) Método de análisis de tabla ortogonal: la cantidad de casos de prueba puede aumentar considerablemente debido a la combinación de una gran cantidad de parámetros. Al mismo tiempo, estos casos de prueba no tienen una brecha obvia en la prioridad y los probadores no pueden completar una cantidad tan grande de pruebas. Algunos casos de uso se pueden reducir a través de la tabla ortogonal, para lograr la posibilidad de cubrir el mayor rango posible con la menor cantidad de casos de prueba posible.
6) Método de análisis de escenarios: se refiere a simular los pasos de operación del usuario de acuerdo con el escenario del usuario, es similar al diagrama de causa y efecto, pero puede tener una mayor profundidad de ejecución y factibilidad.
7) Método de diagrama de estado: obtenga todos los estados del sistema bajo prueba a través de las condiciones de entrada y la descripción de los requisitos del sistema, obtenga las condiciones de salida a través de las condiciones y estados de entrada; obtenga los casos de prueba del sistema bajo prueba a través de las condiciones de entrada, las condiciones de salida y los estados.
8) Método de esquema: El método de esquema es un método que se enfoca en los requisitos Para enumerar varias condiciones de prueba, los requisitos se convierten en un esquema. El contorno se representa como una estructura de árbol con una ruta única entre la raíz y cada nodo hoja. Cada ruta en el esquema define un conjunto específico de condiciones de entrada utilizadas para definir casos de prueba. El número de hojas en el árbol o caminos en el esquema da el número aproximado de casos de prueba necesarios para probar toda la funcionalidad.
24. Describir en detalle el proceso completo de una actividad de prueba. (Para referencia, esta respuesta es principalmente la práctica del modelo de cascada)
El director del proyecto se comunica con el cliente para completar el documento de requisitos, y los desarrolladores y evaluadores completan conjuntamente la revisión del documento de requisitos.El contenido de la revisión incluye: lugares donde la descripción de los requisitos no es clara y lugares que pueden tener conflictos obvios o funciones irrealizables. El director del proyecto completa el plan del proyecto integrando las opiniones de los desarrolladores, probadores y clientes. Luego, SQA ingresa al proyecto y comienza a hacer estadísticas y seguimiento.
El desarrollador completa el documento de análisis de requisitos de acuerdo con el documento de requisitos, y el probador realiza una revisión.El contenido principal de la revisión incluye si hay omisiones o diferencias en el entendimiento entre las dos partes. El probador completa el documento del plan de prueba y el contenido incluido en el plan de prueba se describe arriba.
Los probadores comienzan a escribir casos de prueba de acuerdo con el documento de análisis de requisitos modificado, y los desarrolladores completan el documento de diseño de esquema y el documento de diseño detallado. Estos dos documentos se convierten en materiales complementarios para que los probadores escriban casos de prueba.
Una vez que se completan los casos de prueba, es necesario revisar las pruebas y el desarrollo.
El probador construye el entorno.
El desarrollador envía la primera versión y puede haber funciones sin terminar que necesitan ser explicadas. Los evaluadores realizan pruebas y las envían a BugZilla después de encontrar errores.
El desarrollo envía la segunda versión, incluida la corrección de errores y algunas funciones agregadas, y los evaluadores realizan pruebas.
Repita el trabajo anterior, generalmente después de 3-4 versiones, la cantidad de BUG disminuirá y se cumplirán los requisitos para el envío.
Si hay problemas informados por los clientes, se requiere que los probadores ayuden a reproducir y volver a probar.
26. El proceso de seguimiento de las herramientas de gestión de BUG (utilizando BugZilla como ejemplo)
El evaluador encuentra el ERROR, lo envía a Bugzilla, el estado es nuevo y el receptor del ERROR es el personal de la interfaz de desarrollo.
La interfaz de desarrollo asigna el BUG al desarrollador del módulo relevante, y el estado cambia a asignado. El desarrollador y el probador confirman el BUG. Si es su propio BUG, se configura para recibir; si es el problema de otro desarrollador, se reenvía al siguiente desarrollador.
Si el desarrollador acepta el BUG y lo modifica, cambie el estado del BUG a arreglado e informe la versión en la que se puede probar la prueba.
Los probadores prueban en la nueva versión, y si se encuentra que el problema aún existe, se rechazará la verificación; si se solucionó, se cerrará el BUG.
27. En tu opinión, en el proceso de comunicación entre testers y desarrolladores, ¿cómo mejorar la eficiencia y el efecto de la comunicación?¿Cuál es la clave para mantener una buena relación interpersonal entre testers y otros miembros del equipo de desarrollo?
Trate de comunicarse cara a cara y, en segundo lugar, comuníquese directamente por teléfono, si solo puede comunicarse a través de herramientas de comunicación no oportunas como el correo electrónico, enfatice la necesidad de tener una comprensión profunda de las características y poder expresarse claramente.
También es más eficaz utilizar algunas herramientas de gestión de pruebas como TestDirector para la gestión Al mismo tiempo, cabe señalar que hay una descripción precisa de BUG en TestDirector.
Preste atención a los siguientes puntos para establecer una buena comunicación entre evaluadores y desarrolladores en el equipo:
Uno es la sinceridad, el otro es el espíritu de equipo, el tercero es tener un lenguaje común en la profesión, y el cuarto es tener razón en las cosas y no en las personas, trabajar primero
Por supuesto, también puede aumentar el favor de la otra parte señalando directamente algunos problemas menores en lugar de ingresar al Sistema de seguimiento de errores.
28. ¿Dónde está su mayor interés en las pruebas?¿Por qué?
No existe una respuesta fija y unificada para esta pregunta de la entrevista, pero muchas empresas pueden preguntarla. Proporcione las siguientes respuestas para su consideración:
El mayor interés, sintiendo que este es un trabajo desafiante;
Las pruebas son una industria de experiencia. Cuanto más tiempo trabaje, más difícil y divertido será hacer un buen trabajo en las pruebas.
A través de su propio trabajo, puede hacer que los productos de software sean cada vez más perfectos y experimentar la diversión de ello.
Preste atención a los siguientes puntos al responder estas preguntas:
Exprese su interés haciendo coincidir la ruta técnica de la empresa contratante tanto como sea posible. Por ejemplo, si la empresa es una empresa de aplicaciones de bases de datos, exprese su interés en la prueba de la base de datos y espere mejorar su dominio de la base de datos a través de la prueba.
Indique que el propósito de sus pruebas es mejorar su capacidad y hacer un mejor trabajo de prueba; mejorar su capacidad no es para el desarrollo futuro u otras cosas, a menos que el empleador tenga tal arreglo.
No exprese su interés demasiado fuera del alcance de la empresa de contratación. Por ejemplo, la empresa de contratación está desarrollando software financiero, pero usted ha mostrado interés en el software de juegos, o la empresa de contratación está desarrollando JAVA, y su interés está en el desarrollo de programas en lenguaje C.
29. ¿Cuáles crees que son las ventajas de las pruebas?
No hay una respuesta fija para esta entrevista, pero puedes referirte a los siguientes puntos y combinar tus propias características:
Resiliente, paciente, organizado, le gusta enfrentar los desafíos, tiene la confianza para hacer todo bien, fuertes habilidades de comunicación, ha recibido buenos comentarios de gerentes anteriores, lo que indica que lo estoy haciendo bien 33. Describa brevemente lo que ha hecho en trabajos anteriores y con lo que está familiarizado
. La respuesta de referencia es la siguiente.
Mi trabajo principal en el pasado era la prueba de sistemas y la prueba de automatización. En la prueba del sistema, se prueban principalmente la función de lógica comercial del sistema BOSS y las características de Clase 5 del sistema softswitch. En la prueba de rendimiento se realiza principalmente la prueba de estrés, y se obtiene el tiempo de respuesta del sistema y el consumo de recursos del sistema en el caso de diferente número de solicitudes. Las pruebas automatizadas son principalmente para probar las características del softswitch a través de la combinación de scripts escritos por ellos mismos y algunas herramientas de terceros.
En las pruebas, creo que una comprensión completamente precisa de las necesidades del usuario es muy importante. Además, la gestión de BUG debe basarse en los requisitos, no es necesario modificar todos los BUG.
El trabajo de prueba requiere paciencia y meticulosidad, porque en la nueva versión, aunque la mayoría de los BUG descubiertos originalmente se han solucionado, las funciones originales correctas también pueden volverse incorrectas. Así que preste atención a las pruebas iterativas y las pruebas de regresión.
34. ¿Cuál es el propósito de la estática en C/C++? (Explique al menos dos)
1) En el cuerpo de la función, una variable declarada como estática mantiene su valor mientras se llama a la función.
2) En el módulo (pero fuera del cuerpo de la función), las funciones utilizadas en el módulo pueden acceder a una variable declarada como estática, pero otras funciones fuera del módulo no pueden acceder a ella. Es una variable global local.
3) En un módulo, una función declarada como estática solo puede ser llamada por otras funciones en este módulo. Es decir, la función está restringida al ámbito local del módulo en el que se declara
35. ¿Cuál es la diferencia entre una referencia y un puntero?
1) Las referencias deben inicializarse, los punteros no.
2) Después de inicializar la referencia, no se puede cambiar y el puntero puede cambiar el objeto señalado.
3) No hay referencia a nulo, pero hay un puntero a nulo.
36. ¿Qué protocolo de red utiliza Internet? ¿La principal estructura jerárquica del protocolo? ¿Qué protocolo se utiliza para la traducción de direcciones IP y direcciones físicas de Internet?
La principal estructura jerárquica del protocolo TCP/IP es: capa de aplicación/capa de transporte/capa de red/capa de enlace de datos.
ARP (Protocolo de resolución de direcciones)
37. Cuénteme sobre su comprensión de las dos estrategias de integración de arriba hacia abajo y de integración de abajo hacia arriba en las pruebas de integración, y hable sobre sus respectivas ventajas y desventajas y para qué tipo de prueba son principalmente adecuadas;
integración de arriba hacia abajo
Ventajas: los principales puntos de control y juicio se verifican antes; una función de software completa se puede realizar y verificar primero de acuerdo con la profundidad primero; la función se verifica antes, lo que brinda confianza; solo se necesita un controlador, lo que reduce el costo del desarrollo del controlador; apoya el aislamiento de fallas.
Desventajas: gran desarrollo de los pilares; se retrasa la verificación de bajo nivel; los componentes de bajo nivel no se prueban bien.
La estructura de control del producto es relativamente clara y estable; la interfaz de alto nivel cambia poco; la interfaz inferior no está definida o puede modificarse con frecuencia; los componentes de control de producción y puerto tienen riesgos técnicos relativamente altos y deben verificarse lo antes posible; se espera que el comportamiento de la función del sistema del producto pueda verse lo antes posible.
2. Integración ascendente
Ventajas: verificación temprana del comportamiento de los componentes subyacentes; el trabajo se puede integrar inicialmente en paralelo, lo que es más eficiente que de arriba hacia abajo; la carga de trabajo del stub se reduce; y se admite el aislamiento de fallas.
Desventajas: la carga de trabajo de desarrollo del controlador es pesada, la verificación del alto nivel se retrasa y los errores de diseño no se pueden encontrar a tiempo.
Adaptarse a la interfaz de bajo nivel es relativamente estable; la interfaz de alto nivel cambia con frecuencia; los componentes de bajo nivel se completan antes.
38. Las pruebas de aceptación del software incluyen pruebas de aceptación formales, pruebas alfa y pruebas beta.
39. Existen muchas estrategias para la prueba del sistema, incluidas las pruebas de rendimiento, las pruebas de carga, las pruebas de fuerza, las pruebas de usabilidad, las pruebas de seguridad, las pruebas de configuración, las pruebas de instalación, las pruebas de documentos, las pruebas de recuperación de fallas, las pruebas de interfaz de usuario, las pruebas de recuperación, las pruebas de distribución y las pruebas de usabilidad.
40. Los documentos del proyecto a los que se debe hacer referencia al diseñar un plan de prueba del sistema incluyen el plan de prueba de software, el artefacto de requisitos de software y el plan de iteración
. Los pasos básicos para generar casos de prueba utilizando diagramas de causa y efecto son:
§ Analizar descripciones de especificaciones de software, cuáles son causas (es decir, condiciones de entrada o clases equivalentes de condiciones de entrada) y cuáles son resultados (es decir, condiciones de salida), y asignar un identificador a cada causa y resultado.
§ Analizar la semántica en la descripción de la especificación del software, averiguar cuál es la relación correspondiente entre la causa y el efecto, y entre la causa y la causa Según estas relaciones, dibujar un diagrama de causa y efecto.
§ Debido a restricciones gramaticales o ambientales, algunas combinaciones de causas y causas y entre causas y efectos son imposibles. Para indicar estos casos especiales, las restricciones o restricciones se marcan en el diagrama causal con símbolos. § Convertir diagramas de causa y efecto en tablas de decisión.
§ Tomar como base cada columna de la tabla de juicio y diseñar casos de prueba.
43. Por favor, dígame quién es el mejor para hacer estas pruebas y para qué se prueban.
Las pruebas de código y nivel de función generalmente las realizan probadores de caja blanca, que verifican la corrección de cada pieza de código o función para verificar si implementa correctamente las funciones especificadas.
La base principal para las pruebas a nivel de módulo y componente es la relación de integración y llamada entre el diseño de la estructura del programa y los módulos de prueba, que generalmente es completada por los probadores.
Las pruebas del sistema se realizan sobre la base de pruebas de módulos y pruebas unitarias. Comprenda las funciones y el rendimiento del sistema, y realice pruebas exhaustivas basadas en casos de prueba.
44. ¿Qué aspectos se deben considerar al diseñar casos de prueba, es decir, qué aspectos son probados por diferentes casos de prueba?
Al diseñar casos de prueba, es necesario prestar atención no solo al proceso y las funciones generales, sino también a las pruebas de resistencia, de rendimiento, de estrés, de valor límite, de estabilidad, de seguridad y otros aspectos. (Los cuatro elementos básicos que debe considerar un caso de prueba son la entrada, la salida, la operación y el entorno de prueba; además, el caso de prueba debe considerar el tipo de prueba (función, rendimiento, seguridad...), esta parte se puede responder refiriéndose a TP. Además, también se debe considerar la importancia y prioridad del caso de uso) 45. Al guardar un archivo de texto en Windows, aparecerá un cuadro de diálogo para guardar. Si crea un caso de prueba para el nombre del archivo, ¿cómo se debe dividir la clase de equivalencia
?
Byte único, como A; byte doble, AA, I I; caracteres especiales /'. ';, =-, etc.; palabras reservadas, como com; el formato de archivo está en formato 8.3; el formato de nombre de archivo no está en formato 8.3; nueve caracteres especiales como /, \, *.
46. Suponiendo que hay un cuadro de texto que requiere el ingreso de un código postal de 10 caracteres, ¿cómo se debe dividir el cuadro de texto en clases de equivalencia?
Caracteres especiales, como 10 * o ¥, letras inglesas, como ABCDefghik, menos de diez caracteres, como 123, más de diez caracteres, como 11111111111, números y otros mixtos, como 123AAAAAAAA, caracteres vacíos, caracteres reservados 47. ¿Cuándo comenzó el proyecto de prueba de software?¿Por qué
?
Las pruebas de software deben participar en la etapa de análisis de requisitos, porque el objeto de las pruebas no es solo la codificación del programa, sino que todos los productos producidos durante el proceso de desarrollo del software deben probarse, y existe una tendencia a que los defectos del software se amplifiquen. Cuanto más tarde se encuentre un defecto, mayor será el costo de repararlo. 48. ¿Qué es una prueba de regresión
?
Pruebas de regresión: (pruebas de regresión): Hay dos tipos de pruebas de regresión: regresión de caso de uso y regresión de error; la regresión de caso de uso consiste en volver atrás y volver a probar los casos de uso utilizados anteriormente después de un período de tiempo para ver si se volverá a encontrar el problema. La regresión de errores es un método para volver a verificar los defectos que aparecieron y repararon en la versión anterior en la nueva versión, y probar las partes modificadas relevantes con los defectos como núcleo.
49. ¿Cuál es el enfoque de las pruebas unitarias, las pruebas de integración y las pruebas del sistema?
Las pruebas unitarias están dirigidas a la unidad más pequeña de diseño de software: módulos de programa (funciones y procedimientos en orientado a procesos; clases en orientado a objetos). El trabajo de prueba para la inspección de corrección es encontrar posibles errores en cada módulo de programa. Generalmente, hay dos pasos: inspección estática manual \ seguimiento de ejecución dinámica
La prueba de integración tiene como objetivo probar los componentes integrados por cada módulo que ha pasado la prueba unitaria, su contenido principal es la interfaz entre cada módulo de la unidad y las funciones realizadas por cada módulo después de la integración.
La prueba del sistema está dirigida al sistema de software integrado. Como elemento de todo el sistema informático, se combina con otros elementos del sistema, como el hardware, los periféricos, algún software de soporte, datos y personal. Es necesario realizar una serie de pruebas de integración y pruebas de confirmación en el sistema informático en el entorno operativo real. 51. ¿Qué cualidades debe poseer un ingeniero de pruebas
?
1. Responsabilidad 2. Habilidades de comunicación 3. Espíritu de trabajo en equipo 4. Paciencia, cuidado, confianza 5. Mantener siempre una actitud escéptica y ser consciente de la prevención de defectos 6. Tener cierta experiencia en programación 53: ¿Qué tipos de pruebas de software conoce, presente brevemente
?
Clasificados por estrategia de prueba: 1. Pruebas estáticas y dinámicas 2. Pruebas de caja negra y caja blanca 3. Pruebas manuales y automáticas 4. Pruebas de humo 5. Pruebas de regresión;
Clasificados por fase de prueba: prueba unitaria, prueba de integración, prueba del sistema;
Otros métodos de prueba comunes: 1. Pruebas funcionales 2. Pruebas de rendimiento 3. Pruebas de estrés 4. Pruebas de carga 5. Pruebas de usabilidad 6. Pruebas de instalación 7. Pruebas de interfaz 8. Pruebas de configuración 9. Pruebas de documentación 10. Pruebas de compatibilidad 11. Pruebas de seguridad 12. Pruebas de recuperación 54: ¿Cuál cree que es la clave para un buen plan de prueba
?
Aclarar el objetivo de la prueba y mejorar la viabilidad del plan de prueba.
El propósito importante de escribir un plan de prueba de software es permitir que el proceso de prueba encuentre más defectos de software, por lo que el valor de un plan de prueba de software depende de su capacidad para ayudar a administrar proyectos de prueba y descubrir posibles defectos de software. Por lo tanto, el alcance de la prueba en el plan de prueba del software debe cubrir en gran medida los requisitos funcionales, los métodos de prueba deben ser prácticos, las herramientas de prueba deben ser muy prácticas, fáciles de usar y los resultados de prueba generados son intuitivos y precisos.
Adhiérase a las reglas "5W", aclare el contenido y el proceso
La regla de las "5W" se refiere a "Qué (qué hacer)", "Por qué (por qué hacerlo)", "Cuándo (cuándo hacerlo)", "Dónde (dónde)", "Cómo (cómo hacerlo)". El uso de la regla "5W" para crear un plan de prueba de software puede ayudar al equipo de prueba a comprender el propósito de la prueba (por qué), aclarar el alcance y el contenido de la prueba (qué), determinar la fecha de inicio y finalización de la prueba (cuándo), señalar el método y la herramienta de la prueba (cómo) y brindar la ubicación de almacenamiento de los documentos y el software de la prueba (dónde).
Adoptar un mecanismo de revisión y actualización para garantizar que el plan de prueba satisfaga las necesidades reales
Después de redactar el plan de prueba, si no se ha revisado, se enviará directamente al equipo de prueba. El contenido del plan de prueba puede ser inexacto u omitir el contenido de la prueba, o el alcance de la prueba puede aumentar o disminuir debido a cambios en los requisitos del software, pero el contenido del plan de prueba no se actualiza a tiempo, lo que induce a error a los ejecutivos de prueba.
Crear plan de prueba y especificación detallada de prueba, caso de prueba respectivamente
Los indicadores técnicos de prueba detallados deben incluirse en el documento de especificación detallada de prueba creado de forma independiente, y los casos de prueba utilizados para guiar al equipo de prueba para ejecutar el proceso de prueba deben colocarse en el documento de caso de prueba creado de forma independiente o en la base de datos de gestión de casos de prueba. Existe una relación estratégica y táctica entre el plan de prueba y la especificación de prueba y los casos de prueba. El plan de prueba planifica principalmente el alcance, el método y la asignación de recursos de la actividad de prueba desde una perspectiva macro, mientras que la especificación de prueba y los casos de prueba son las tácticas específicas para completar la tarea de prueba.
55: ¿Cuál cree que es la clave para hacer un buen trabajo en el diseño de casos de prueba?
La clave para el diseño de casos de prueba de caja blanca es cubrir tantos resultados lógicos internos del programa como sea posible con menos casos de prueba.
La clave para el diseño de casos de uso de caja negra también es cubrir las interfaces de entrada y salida del módulo con menos casos de uso. Es imposible hacer pruebas completas, encontrar la mayoría de los problemas en un tiempo razonable con la menor cantidad de casos de uso
56: ¿Cuáles son sus objetivos de desarrollo profesional en pruebas?
Cuanta más experiencia en pruebas, mayor será la capacidad de prueba. Así que mi desarrollo profesional necesita tiempo para acumularse, paso a paso hacia un ingeniero de pruebas senior. Y también tengo un plan de carrera preliminar, acumulando experiencia en testing en los primeros 3 años, actualizándome y corrigiéndome constantemente, y haciendo un buen trabajo en las tareas de testing.
57: ¿Cuáles son los criterios para el final de la prueba?
Desde un punto de vista microscópico, se define en el plan de prueba. Por ejemplo, el sistema funciona sin problemas durante 72 horas con un determinado rendimiento. Actualmente, en el Sistema de seguimiento de errores, no hay errores graves generales en esta versión, la cantidad de errores comunes es inferior a 3 y la tasa de reparación de errores es superior al 90%. Luego, el administrador de desarrollo, el administrador de pruebas y el administrador de proyectos firman conjuntamente para aprobar el lanzamiento de la versión.
Si hablamos de la macro, la prueba terminará cuando el software desaparezca por completo.
59. ¿En qué etapas debe consistir un conjunto completo de pruebas?
Análisis de factibilidad, análisis de demanda, diseño del esquema, diseño detallado, codificación, prueba unitaria, prueba de integración, prueba del sistema, prueba de aceptación 61. ¿Conoce
el proceso de desarrollo de software de la empresa en la que trabajó en el pasado? Si es así, describa qué tareas deben completarse en un proceso de desarrollo completo? ¿Qué roles se utilizan para completar estas tareas? ¿Qué tareas específicas ha realizado en trabajos de prueba anteriores?
Proceso de desarrollo: investigación de requisitos (personal de requisitos), análisis de demanda (personal de requisitos), diseño de esquema (diseñadores), diseño detallado (diseñadores), codificación (desarrolladores)
Proceso de prueba---revisión de requisitos, diseño de prueba de sistema, revisión de diseño de resumen, diseño de prueba de integración, revisión de diseño detallado, diseño de prueba de unidad, ejecución de prueba
Haber realizado todo el proceso de trabajo de prueba, bueno en el diseño de prueba
El proceso determina la calidad, y la mejora del proceso de software es solo para mejorar la calidad del software y acumular varias experiencias y lecciones pasadas.
62. ¿Cuáles son los principios del diseño de casos de prueba?¿Cuáles son los principales métodos de diseño de casos de prueba en la actualidad?
Representatividad: Ser capaz de representar y cubrir todo tipo de datos de entrada, operaciones y configuraciones ambientales que sean razonables e irrazonables, legales e ilegales, fronterizos y transfronterizos, y límites.
Decidibilidad: es decir, la corrección de los resultados de ejecución de la prueba es decidible, y cada caso de prueba debe tener un resultado esperado correspondiente.
Reproducibilidad: Es decir, para un mismo caso de prueba, los resultados de ejecución del sistema deben ser los mismos.
Los métodos incluyen clases de equivalencia, valores límite, diagramas causales, diagramas de estado, métodos ortogonales y métodos de esquema
63. ¿Cuántos métodos hay en el diseño de casos de prueba orientados a objetos?¿Cómo implementarlos?
Diseñe un conjunto de casos de prueba para cada constructor de la clase
Variables de clase, variables de instancia en clases compuestas
Varios métodos en clases compuestas
Diseñe casos de prueba basados en condiciones previas y posteriores
Diseñe casos de prueba basados en el código
64. ¿En qué tres módulos se divide LoadRunner? Describa brevemente las funciones principales de cada módulo.
Generador de usuarios virtuales: para grabar pasos
Controlador Mercury LoadRunner: utilizado para crear, ejecutar y monitorear escenarios
Análisis de Mercury LoadRunner: se utiliza para analizar los resultados de las pruebas
65. ¿Cuál es su mayor interés en las pruebas?
¡El mayor interés es que la prueba es difícil y desafiante! Cuanto más tiempo hagas la prueba, más difícil será hacerlo bien. Una vez vi un artículo en la red de pruebas sin preocupaciones sobre cómo ser un buen ingeniero de pruebas. Se enumeran un total de 11 y 12 puntos, algunos de los cuales están relacionados con la personalidad humana y otros requieren esfuerzos adquiridos. Pero aparte de 1 y 2 puntos relacionados con la personalidad, no estoy seguro, y confío mucho en hacerlo bien en otros puntos.
Cuando entré por primera vez en la industria de las pruebas, mi comprensión de las pruebas se basaba en cierta información que aprendí del sitio web de Wuyou Test. En ese momento, era porque las pruebas requerían muchas habilidades para hacerlo bien. Aunque era fácil comenzar, era difícil hacerlo bien e incluso era más difícil que el desarrollo. Aunque en ese momento realmente quería hacer desarrollo (básicamente no me perdí los cursos profesionales en la escuela, porque me gusta mi especialización), pero al ver que las pruebas eran más difíciles y desafiantes que el desarrollo, mi voluntad de hacer un buen trabajo en las pruebas se hizo más fuerte.
Creo que hay dos puntos en todo el proceso de testing que me hacen sentir muy difícil (a mí me interesan mucho las cosas difíciles). El primero es el diseño de casos de prueba, porque la esencia del testing está en el diseño de casos de prueba. Antes de lanzar la versión, se deben escribir bien los casos de uso. ¿Qué método de prueba se debe usar? (Es decir, plan de prueba o estrategia de prueba). Lo básico no es tan simple, lo que requiere su capacidad de aprendizaje consciente, como el sitio web, los conocimientos técnicos más básicos que necesita saber cómo funciona el sitio web internamente, cómo funciona el antecedentes responder a las solicitudes de los usuarios?¿Cómo construir un entorno de prueba?Todos estos deben aprenderse lo antes posible. Al menos se pueden hacer los preparativos básicos antes de comenzar la prueba. ¿Qué dificultades se pueden encontrar? ¿No se determinan los detalles de los requisitos? Estos problemas se pueden encontrar al diseñar casos de uso.
El segundo es el momento de encontrar errores. Esta debería ser la tarea más básica para los evaluadores. Generalmente, la mayoría de los errores se pueden encontrar iniciando la prueba de acuerdo con los casos de prueba. Todavía hay algunos errores que deben probarse para obtener más información sobre la versión bajo prueba, complementar los casos de prueba y probar los errores. ¿Y cómo encontrar errores? Esto requiere cuidado y paciencia para encontrar errores cuando los casos de prueba son válidos. Se pueden encontrar errores en cada caso de uso y pueden ocurrir errores en cada lugar, por lo que el pensamiento debe ser claro durante el proceso de prueba (el flujo de datos y los resultados del proceso de prueba deben leerse cuidadosamente, y los errores se encuentran en él). La forma de describir el error también es muy particular. ¿Bajo qué circunstancias ocurre el error? Si las condiciones cambian un poco, el error no existirá. ¿Cuáles son los pasos mínimos para reproducir el error? ¿Cuál es la ley del error? Si eres lo suficientemente bueno, puedes ayudar al desarrollador a localizar inicialmente el problema.
66. ¿Con qué tipos de pruebas de software está familiarizado? Intente comparar las diferencias y conexiones de estos diferentes tipos de pruebas (como pruebas funcionales, pruebas de rendimiento...)
Los tipos de prueba son: prueba funcional, prueba de rendimiento, prueba de interfaz.
Las pruebas funcionales representan la mayor parte del trabajo de prueba, y las pruebas funcionales también se denominan pruebas de caja negra. es tratar el objeto de prueba como una caja negra. Cuando se utiliza el método de prueba de caja negra para pruebas dinámicas, es necesario probar la función del producto de software, sin probar la estructura interna y el proceso de procesamiento del producto de software. Los métodos para diseñar casos de prueba utilizando la tecnología de caja negra incluyen: división de clases de equivalencia, análisis de valor límite, suposición de errores, diagrama de causa y efecto y estrategia integral.
La prueba de rendimiento consiste en probar varios indicadores de rendimiento del sistema mediante la simulación de varias condiciones de carga normales, máximas y anormales a través de herramientas de prueba automatizadas. Tanto las pruebas de carga como las pruebas de estrés son pruebas de rendimiento y se pueden combinar. A través de pruebas de carga, determine el rendimiento del sistema bajo varias cargas de trabajo. El objetivo es probar los cambios en varios indicadores de rendimiento del sistema cuando la carga aumenta gradualmente. La prueba de estrés es una prueba para obtener el máximo nivel de servicio que el sistema puede proporcionar al determinar el cuello de botella o el punto de rendimiento inaceptable de un sistema.
Pruebas de interfaz, la interfaz es la capa de interacción más directa entre el software y el usuario, y la calidad de la interfaz determina la primera impresión que el usuario tiene del software. Además, una interfaz bien diseñada puede guiar a los usuarios para que completen las operaciones correspondientes por sí mismos, desempeñando el papel de guía. Al mismo tiempo, la interfaz es como un rostro humano, lo que tiene la ventaja directa de atraer a los usuarios. Una interfaz bien diseñada puede brindar a los usuarios una sensación de tranquilidad, alegría y éxito. Por el contrario, debido a la falla del diseño de la interfaz, los usuarios se sentirán frustrados. No importa cuán práctica y poderosa sea la función, puede desperdiciarse en el miedo y el abandono de los usuarios.
La diferencia es que las pruebas funcionales se centran en todas las funciones del producto, teniendo en cuenta cada función detallada y cada posible problema funcional. Las pruebas de rendimiento se centran principalmente en la estabilidad y solidez del producto bajo la concurrencia de múltiples usuarios en su conjunto. Las pruebas de interfaz se enfocan más en la experiencia del usuario. ¿Es el producto fácil de usar, fácil de entender, estandarizado (como las teclas de acceso directo), hermoso (si puede atraer la atención del usuario) y seguro (trate de evitar que los usuarios ingresen datos no válidos sin querer en primer plano. Por supuesto, considerando la experiencia, no debería ser demasiado grosero mostrar advertencias emergentes)?, prueba unitaria, prueba de integración, prueba del sistema, diferencia de prueba de aceptación y conexión
.
Pruebas de caja negra: conociendo las especificaciones de diseño funcional del producto, se pueden realizar pruebas para comprobar si cada función implementada cumple con los requisitos.
Prueba de caja blanca: conociendo el proceso de trabajo interno del producto, se puede probar para comprobar si cada operación interna cumple con las especificaciones de diseño y si se han verificado todos los componentes internos.
La prueba de caja negra del software significa que la prueba se realiza en la interfaz del software. Este método considera el objeto de prueba como una caja negra, y el evaluador no considera en absoluto la estructura lógica y las características internas del programa, sino que solo verifica si la función del programa se ajusta a su descripción de función de acuerdo con la especificación de requisitos del programa. Por lo tanto, las pruebas de caja negra también se denominan pruebas funcionales o pruebas basadas en datos. La prueba de caja negra es principalmente para encontrar los siguientes tipos de errores:
1. ¿Hay funciones incorrectas o que faltan? 2. En la interfaz, ¿se puede aceptar correctamente la entrada? ¿Se puede generar el resultado correcto? 3. ¿Hay errores de estructura de datos o errores de acceso a información externa (como archivos de datos)? 4. ¿Puede el rendimiento cumplir con los requisitos? 5. ¿Hay errores de inicialización o terminación?
La prueba de caja blanca del software es una inspección detallada de los detalles de procedimiento del software. Este método considera el objeto de prueba como una caja abierta, lo que permite a los probadores usar la estructura lógica interna y la información relacionada del programa para diseñar o seleccionar casos de prueba y probar todas las rutas lógicas del programa. Determine si el estado real es consistente con el estado esperado examinando el estado del programa en varios puntos. Por lo tanto, las pruebas de caja blanca también se denominan pruebas estructurales o pruebas basadas en la lógica. La prueba de caja blanca principalmente quiere verificar los módulos del programa de la siguiente manera:
1. Pruebe todas las rutas de ejecución independientes de los módulos del programa al menos una vez.
2. Para todos los juicios lógicos, las dos situaciones de tomar "verdadero" y tomar "falso" se pueden probar al menos una vez.
3. Ejecute el cuerpo del ciclo dentro de los límites del ciclo y dentro de los límites de la ejecución.
4. Probar la validez de las estructuras de datos internas, etc.
Una prueba unitaria (prueba de módulo) es una pequeña pieza de código escrita por un desarrollador para verificar que una función pequeña y muy específica del código bajo prueba es correcta. En términos generales, una prueba unitaria se usa para juzgar el comportamiento de una función específica bajo una condición (o escenario) específica.
Las pruebas unitarias las realizan los propios programadores, y son los programadores quienes finalmente se benefician de ellas. Se puede decir que los programadores son responsables de escribir código funcional y, al mismo tiempo, también son responsables de escribir pruebas unitarias para su propio código. Se realizan pruebas unitarias para demostrar que el comportamiento de este código es consistente con nuestras expectativas.
Las pruebas de integración (también llamadas pruebas de ensamblaje, pruebas conjuntas) son una extensión lógica de las pruebas unitarias. En su forma más simple, dos unidades probadas se combinan en un componente y se prueba la interfaz entre ellas. En este sentido, un componente se refiere a la agregación integrada de múltiples unidades. En un programa del mundo real, muchas unidades se combinan en componentes y estos componentes se agregan en partes más grandes del programa. El enfoque es probar combinaciones de fragmentos y eventualmente extender el proceso para probar su módulo con otros grupos de módulos. Finalmente, todos los módulos que componen el proceso se prueban en conjunto.
La prueba del sistema es ensamblar los subsistemas probados en un sistema completo para la prueba. Es un método efectivo para verificar si el sistema realmente puede proporcionar las funciones especificadas en la especificación del esquema del sistema. (Prueba de depuración conjunta común)
El propósito de las pruebas del sistema es realizar una prueba integral en el sistema de software final para garantizar que el sistema de software final cumpla con los requisitos del producto y siga el diseño del sistema.
La prueba de aceptación es la última operación de prueba antes de implementar el software. El propósito de las pruebas de aceptación es garantizar que el software esté listo y que los usuarios finales puedan utilizarlo para realizar las funciones y tareas previstas del software.
Las pruebas de aceptación demuestran a los futuros usuarios que el sistema funciona según lo previsto. Después de la prueba de integración, todos los módulos se ensamblaron en un sistema de software completo de acuerdo con el diseño, y los errores de la interfaz se eliminaron básicamente. Luego, la validez del software debe verificarse aún más. Esta es la tarea de la prueba de aceptación, es decir, el rendimiento funcional del software es el esperado por el usuario.
68. ¿Cómo te las arreglas cuando el desarrollador dice que no es un error?
El desarrollador dijo que no era un error. Hay dos situaciones. Una es que los requisitos no están determinados, así que puedo hacer esto. En este momento, puedo encontrar al gerente de producto para confirmar si es necesario cambiarlo. La segunda es que este tipo de situación no puede ocurrir, por lo que no hay necesidad de modificarlo. En este momento, primero puedo decir cuál es la base del BUG tanto como sea posible. Si el usuario lo descubre o algo sale mal, ¿cuál será el mal resultado? El programador puede darte muchas razones y puedes refutar su explicación. Si aún no funciona, puedo plantear este problema y confirmarlo con el administrador de desarrollo y el administrador de pruebas. Si desea modificarlo, cámbielo, si no desea modificarlo, no lo cambie. De hecho, algunos realmente no son errores, y simplemente los escribo en TD de la manera sugerida.Si los desarrolladores no los modifican, no habrá mayores problemas. Si se determina que es un error, debe atenerse a su posición y dejar que el problema se confirme finalmente.
69. ¿Por qué el trabajo de testing de software debe realizarse en equipo?
Debido a que el software no probado es difícil saber la calidad del software antes de su lanzamiento, al igual que la certificación de calidad ISO, las pruebas también requieren garantía de calidad.En este momento, es necesario realizar pruebas de software en el equipo. En el proceso de prueba, se encuentran los problemas en el software, y los desarrolladores son notificados y corregidos a tiempo, y la calidad del software se puede obtener del informe de prueba cuando está a punto de ser lanzado.
71. ¿Qué debe incluir un plan de pruebas?
Antecedentes, resumen del proyecto, propósito, alcance de la prueba, estrategia de prueba, división del trabajo, requisitos de recursos, cronograma, documentos de referencia, términos comunes, documentos de presentación, análisis de riesgos.
72. Con base en los antecedentes de la industria del software, ¿cómo entiende el negocio del software?
Lea el manual del usuario para comprender la función y el proceso de operación del software; lea algunos libros profesionales de negocios para complementar el conocimiento del negocio; si tiene datos reales del usuario, puede usarlos como referencia; consulte casos de uso anteriores e informes de ERRORES; piense más en el proceso de uso del software; comuníquese más con los gerentes de producto.
74. ¿Cómo ubicar el rol de los casos de prueba?
Organización: redacción, organización, cobertura funcional, repetibilidad, seguimiento, confirmación de la prueba
76. ¿Qué es una prueba de compatibilidad? Dé un ejemplo de cómo utilizar la lista de pruebas de compatibilidad para las pruebas.
Principalmente verificar la compatibilidad de productos de software entre diferentes versiones. Incluyendo la compatibilidad con versiones anteriores y la compatibilidad cruzada, la compatibilidad con versiones anteriores es el caso en el que una nueva versión del software de prueba conserva las funciones de su versión anterior, y la compatibilidad cruzada es para verificar la compatibilidad entre dos productos relacionados pero no idénticos que coexisten.
77. Después de probar cierto software, se encuentra que funciona muy lentamente en WIN 98. ¿Cómo distinguir si hay un problema con el software o un problema con el entorno operativo del software y el hardware?
Compruebe los requisitos del entorno operativo del software. Si cumple con los requisitos, hay un problema con el programa Si no cumple con los requisitos, hay un problema con el sistema de hardware 78. ¿
Cuáles son las precauciones para la prueba de requisitos?
是否使用了公司的模板、文档内容是否符合规范、所有的需求是分级是否清析适当、所有的需求是否具有一致性、需求是否可行(即，该需求组合有解决方案)、需求可否用己知的约束来实现、需求是否足够(即，可以把它送到一个规范的开发组织，并有一个生产出所需要产品的合理的可能性)、所有的其它需求是交叉引用是否正确、用户描述是否清楚、是否用客户的语言来描述需求、每个需求描述是否清楚没有岐义，可以移交给一个独立的组去实现时也能理解、是否所有的需求都是可验证的、是否每条需求都具有独立性，即使发生了变化也不会影响其它需求、性能指标是否明确、非功能性需求是否得到充分表现、是否完整列出适用的标准或协议、标准和协议之间是否存在冲突
81、主键、外键的作用，索引的优点与不足?
Respuesta: Clave primaria: Es la clave de identificación única en la tabla. Función: para garantizar la integridad de la entidad; para acelerar el funcionamiento de la base de datos; al agregar un nuevo registro de tabla, la base de datos recuperará automáticamente el valor de la clave principal del nuevo registro, y no se permite que el valor se repita con la clave principal registrada en otras tablas; la base de datos mostrará los registros en el orden de los valores de la clave principal; si no se establece una clave principal, los registros se mostrarán en el orden ingresado.
Clave foránea: Está subordinada a la clave primaria y representa la conexión entre las dos tablas. Rol: El uso de claves foráneas puede evitar la redundancia.
Ventajas del índice: 1. Al crear un índice único, se puede garantizar la unicidad de los datos en la tabla 2. Acelerar la velocidad de recuperación de datos 3. Acelerar la conexión entre tablas 4. Al usar la recuperación de datos de agrupación y clasificación, el tiempo de agrupación y clasificación puede recuperarse significativamente
Desventajas: 1. Lleva tiempo crear un índice y aumenta con el aumento del volumen de datos 2. El índice necesita ocupar espacio físico;
3. Al modificar los datos en la tabla, el índice también debe mantenerse dinámicamente, lo que reduce la velocidad del mantenimiento de datos.
84. ¿Cuál es el proceso de prueba de desempeño?
1. Análisis de requisitos de prueba 2. Formulación y revisión de planes de prueba 3. Diseño y desarrollo de casos de prueba 4. Ejecución y seguimiento de prueba 5. Análisis de resultados de prueba 6. Redacción de informes de prueba de rendimiento 7. Resumen de experiencia de prueba 88. Describa brevemente el ciclo de vida de los errores
.
1. Registrar BUG de manera efectiva 2. Usar plantilla de BUG 3. Evaluar la prioridad y severidad de BUG 4. Vida útil de BUG 5. Mantener la base de datos de BUG
89. ¿Qué deben contener los registros de defectos?
Identificación del defecto, tipo de defecto, gravedad del defecto, posibilidad del defecto, prioridad del defecto, estado del defecto, origen del defecto, origen del defecto, causa del defecto; 91 ¿Con qué tipos de pruebas de software está familiarizado? Intente comparar las diferencias y conexiones de estos diferentes tipos de pruebas (como pruebas funcionales, pruebas de rendimiento...
)
Prueba de usabilidad: facilidad de uso de la interfaz, facilidad de uso, etc.
Pruebas funcionales: el cumplimiento de los requisitos funcionales en el sistema.
Pruebas de seguridad: si existen riesgos de seguridad y vulnerabilidades en el sistema
Pruebas de rendimiento: velocidad de respuesta y robustez del sistema bajo gran concurrencia
93. ¿Cuál cree que es la clave para hacer un buen trabajo en la planificación de pruebas?
Comprender los requisitos comerciales del proyecto o sistema.
Coordine con el gerente del proyecto y comprenda el cronograma y el arreglo del proyecto
95. ¿Cuál cree que es la clave para hacer un buen trabajo en el diseño de casos de prueba?
Tiene muy claros los requisitos comerciales y de software, y puede elegir diferentes diseños de casos de prueba de acuerdo con los diferentes requisitos.
96. ¿Alguna vez ha realizado un trabajo de revisión de casos de prueba en su trabajo anterior? En caso afirmativo, describa el proceso y el contenido de la revisión de casos de prueba.
Revisar plan->pre-revisión->revisión;
El contenido de la revisión es principalmente la cobertura de los casos de prueba a los requisitos de software, ya sea para considerar los límites relevantes, ya sea para preparar múltiples conjuntos de datos de prueba para procesos complejos y si hay pruebas específicas para requisitos no funcionales.
98. ¿Cuál cree que es el propósito de las pruebas de rendimiento?¿Cuál es la clave para hacer un buen trabajo en las pruebas de rendimiento?
La clave es grabar el script de prueba y mantener limpio el entorno de prueba durante la prueba.
100. ¿Usó alguna herramienta para administrar defectos de software (Bugs) en su trabajo anterior de prueba de software? En caso afirmativo, describa el proceso de administración de seguimiento de defectos de software (Bugs) en combinación con las herramientas.
CQ, también puede utilizar herramientas gratuitas como BugFree.
101. ¿Qué opina sobre la mejora de los procesos de software? ¿Hay algo que deba mejorarse en las empresas en las que ha trabajado? ¿Qué tipo de entorno de trabajo espera para un probador ideal?
Consolide la experiencia o las ideas avanzadas en el proceso y mejore la calidad del software a través de la mejora del proceso y la mejora de la capacidad.
Protocolo de cinco capas TCP/IP: capa de aplicación, capa de transporte, capa de red, capa de enlace de datos, capa de hardware
Gracias a todos los que han leído mi artículo detenidamente. Al ver el crecimiento y la atención de los fanáticos en todo momento, siempre existe la necesidad de reciprocidad. Aunque no es algo muy valioso, puede quitárselo si lo necesita:
① Más de 2000 libros electrónicos de pruebas de software (deberían estar disponibles libros convencionales y clásicos)
② Información de la biblioteca estándar de pruebas de software/pruebas automatizadas (la versión china más completa)
③ Código fuente del proyecto (cuarenta o cincuenta proyectos interesantes y clásicos de práctica manual y código fuente)
④ Lenguaje de programación Python, pruebas automatizadas de interfaz API, pruebas automatizadas web, pruebas automatizadas de aplicaciones (adecuadas para principiantes)
⑤ Hoja de ruta de aprendizaje de Python (Adiós al aprendizaje influyente)
En mi grupo de intercambio de tecnología QQ (intercambio técnico e intercambio de recursos, los anuncios entran y te rompen las piernas)
Te lo puedes llevar tú mismo.La información gratuita en el número de grupo 953306497 (nota "csdn111") es la esencia de los más de diez años de carrera testadora del autor. También hay compañeros maestros para intercambiar tecnología juntos.
