001. 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
0002. Pregunta: Encontraste un error en la prueba, pero el gerente de desarrollo piensa 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.
003. 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 la combinación de plataformas admitidas:
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.
004. Ingresar caracteres chinos en el motor de búsqueda puede resolver el nombre de dominio correspondiente Cómo usar LoadRunner para realizar pruebas.
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 el script y guarde, 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 juzgar si el tiempo promedio de respuesta de la transacción del sistema cumple con el estándar en circunstancias normales; ¿Se bloqueará el sistema? Ejecute pruebas, obtenga resultados de pruebas, analice resultados de pruebas.
005. Pregunta: ¿Cuál es la diferencia entre un cliente con 300 clientes y 300 clientes con 300 clientes presionando 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.
006. Explicar el concepto y 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.
007. ¿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 preliminar pero no completa 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 al usuario todas o parte de las funciones y el rendimiento. del software que se va a desarrollar; el usuario prueba y evalúa el prototipo, y ofrece sugerencias de mejora específicas para enriquecer y refinar los requisitos del software; el desarrollador modifica y mejora el software en consecuencia, y completa la implementación, prueba y mantenimiento del software hasta que el usuario está satisfecho y aprobado.
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
008. ¿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.
009. ¿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
010. ¿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).
011. ¿Cuál es el método de diseño de casos 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
012. ¿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 las pruebas de seguridad de autenticación de usuarios: Distinguir claramente los diferentes permisos de usuario en el sistema, si habrá conflictos de usuarios en el sistema, si el sistema causará confusión debido a cambios en los permisos de usuario, si las contraseñas de inicio de sesión de usuario son visibles, reproducibles y Es posible iniciar sesión en el sistema de forma absoluta (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 para usar el botón Atrás para ingresar al sistema sin ingresar una contraseña, y se debe considerar la prueba de seguridad de la red del sistema. el sistema de protección es sólido, use herramientas de inspección de vulnerabilidades de red maduras para verificar las vulnerabilidades relacionadas con el sistema (es decir, use las herramientas de ataque de piratas informáticos más profesionales) herramientas de inspección para verificar la situación del caballo de Troya del sistema, use varias herramientas anti-complementos para verificar las vulnerabilidades de los complementos de cada grupo 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 (acabo de completar el nombre real de la empresa sistema de servicio de verificación La incompletitud de los datos ha obstaculizado la realización de la función de este sistema), la capacidad de administración de los datos del sistema, la independencia de los datos del sistema, la capacidad de copia de seguridad y restauración de datos del sistema (si la copia de seguridad de datos está completa, si puede ser restaurado, si la restauración puede ser completa)
013. ¿Qué es un caso de prueba, qué es un script de prueba y cuál es la relación entre ambos?
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
014. 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, a fin de verificar la exactitud, confiabilidad y efectividad de el programa, y analizar la eficiencia operativa del sistema y el rendimiento, como la robustez.
Las pruebas de caja negra generalmente se utilizan para confirmar la corrección y operabilidad de las funciones del software. En el caso de las relaciones entre entradas y salidas o funciones del programa, se confía en las especificaciones del software para determinar los casos de prueba e inferir la exactitud de los resultados de la prueba.
La prueba de caja blanca se realiza en base al análisis de la estructura lógica del software. Es una prueba basada en código. El probador juzga 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, la prueba de la caja negra la realiza el director del proyecto.Los programadores desarrollan para lograrlo.
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.
015. ¿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.
016. ¿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
017. ¿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.
018. ¿Cuáles son las estrategias y requisitos de prueba para las pruebas de software divididas en varias etapas?
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: Adáptese a la estructura de control de productos 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 ser verificado lo antes posible; espero ser verificado lo antes posible Puede ver el comportamiento funcional del sistema del producto.
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 disponibilidad; verificación de versión prueba; prueba de documentación
019. ¿Qué trabajo se suele realizar en cada etapa de las pruebas de software?, ¿cuál es el archivo de resultados de cada etapa?, ¿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.
Etapa de prueba de integración: la prueba de integración se basa en la prueba unitaria, probando si todas las unidades de software cumplen o realizan los indicadores técnicos correspondientes y la actividad requerida. 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 verificación se utiliza como un elemento de todo el sistema informático dado, combinado con otros elementos del sistema, como hardware informático, periféricos, algún software de soporte, datos y personal, y se prueba en el entorno operativo real. Cobertura funcional integral de los sistemas informáticos. En esta etapa, se debe enviar el resumen de la prueba y el informe de defectos.
020. ¿Cuál es la tarea del tester 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.
021. 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 genera el error; en primer lugar, debe haber un resumen del error, explicando el contenido general del error; la versión correspondiente al error; descripción detallada del error, incluyendo algunas capturas de pantalla, videos, etc.; cuando ocurre el error El entorno de prueba, las condiciones generadas son los pasos de operación correspondientes; Registros de errores de alta calidad:
- La interfaz de usuario general debe ser unificada y precisa, y la interfaz de usuario del informe de defectos debe ser coherente con la interfaz de usuario del software probado, para que sea fácil de encontrar y ubicar.
- Trate de utilizar los términos y métodos comúnmente utilizados en la industria para garantizar una expresión precisa y profesional.
- Cada informe de defectos incluye solo un defecto Cada informe de defectos incluye solo un defecto, lo que permite que el solucionador de defectos ubique 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.
- 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.
- Indicar claramente el tipo de defecto De acuerdo con 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.
- Indique claramente la gravedad y prioridad del defecto Aclare siempre la diferencia entre gravedad y prioridad. Es posible que no valga la pena solucionar los problemas de alta gravedad, los problemas cosméticos pequeños pueden considerarse de alta prioridad
- La descripción, sucinta, precisa y completa, revela la esencia del defecto, registra 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, los nombres de controles como títulos, menús, botones, etc. de cuadros de diálogo de registro
- Use números de serie digitales automáticos entre líneas cortas, use la misma fuente, tamaño de fuente y espacio entre líneas Use números de serie digitales 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 lograr la estandarización y la profesionalidad.
- 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.
- Los pasos de confirmación son 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 .
- Dependiendo del defecto, puede elegir si desea realizar la captura de imágenes. 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 "adjunta". del registro como 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.
- Verifique los defectos 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 que el defecto se describa correctamente.
- 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.
- 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 la operación pueden ayudar a los desarrolladores a 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.
022. La prueba de caja negra y la prueba 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 de saber qué funciones usará el usuario y qué problemas encontrará; con base en el documento de desarrollo de software, también es posible saber qué funciones en el documento implementa el software; 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 para que se ejecute el 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 lo está haciendo correcto, pero no puede saber si el diseño es correcto o no, y puede pasar por alto algunos requisitos funcionales; cuando el sistema es enorme, la sobrecarga de prueba será muy grande.
023. ¿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 presión: use una aguja y siga agregando peso en la aguja para ver cuánta presión penetrará
024. ¿Cuál es el objetivo del trabajo del plan de pruebas?, ¿cuáles deben ser los contenidos del documento del plan de pruebas?, ¿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 de prueba 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 tratar 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 los específicos. tácticas 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).
025. ¿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: Una clase de equivalencia se refiere a un subconjunto de un campo de entrada. En este subconjunto, cada dato de entrada es equivalente a revelar errores en el programa. Es razonable suponer que: para probar una cierta equivalencia El valor representativo de una clase es igual a la prueba de otros valores de esta clase. Por lo tanto, todos los datos de entrada se pueden dividir razonablemente en varias clases de equivalencia, y un dato en cada clase de equivalencia se toma como la condición de entrada de la prueba, y un pequeño cantidad de datos de prueba representativos Obtenga buenos resultados de prueba La división de clase de equivalencia puede tener dos situaciones diferentes: clase de equivalencia válida y clase de equivalencia no válida.
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.
Para diseñar casos de prueba utilizando el método de análisis de valor límite, 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 enfocarse en las pruebas. Valores que son exactamente iguales a, Se debe seleccionar como datos de prueba un poco más o un poco menos que el límite, en lugar de seleccionar valores típicos o valores arbitrarios en la clase de equivalencia 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 especulación de errores: enumere todos los posibles errores y casos especiales que son propensos a errores en el programa, y seleccione casos de prueba en función de ellos. Por ejemplo, muchos errores comunes en los módulos se han enumerado durante las pruebas unitarias. Productos anteriores Los errores encontrados en la prueba, 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 una sola línea. Estas son las situaciones que son propensos a errores Puede elegir estas situaciones El siguiente ejemplo se utiliza como caso de prueba.
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 enfocan en considerar las condiciones de entrada, pero no consideran la relación entre las condiciones de entrada, combinación mutua, etc. Consideración de la combinación mutua de las condiciones de entrada, se pueden generar 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. Por lo tanto, es necesario considerar la adopción de un adecuado Para describir la combinación de varias condiciones, en consecuencia generar múltiples acciones para considerar el diseño de casos de prueba. Esto requiere el uso de diagramas causales (modelos lógicos). El resultado final del método de diagrama causal es el tabla de decisión Es adecuado para verificar las condiciones de entrada del programa de varias combinaciones.
5) Método de análisis de tabla ortogonal: puede causar un aumento en la cantidad de casos de prueba 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 prioridad, y los probadores no pueden completar tal gran número de pruebas, algunos casos de uso se pueden reducir a través de la tabla ortogonal, para lograr la posibilidad de cubrir un rango tan grande como sea posible con la menor cantidad de casos de uso 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.
026. Describir detalladamente el proceso completo de una actividad de prueba. (Para referencia, esta respuesta es principalmente la práctica del modelo de cascada)
El gerente del proyecto se comunica con el cliente para completar el documento de requisitos, y los desarrolladores y probadores 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 irrealizables. funciones El director del proyecto completa el plan del proyecto integrando las opiniones de los desarrolladores, evaluadores 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.
027. El proceso de seguimiento de las herramientas de gestión de BUG (utilizando Zen Tao 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 cambia el estado a asignado. El desarrollador y la prueba confirman el BUG. Si el BUG es propio, se configura para recibir; si es el problema de otro desarrollador, es reenviado Depende del siguiente desarrollador llevar a cabo este comportamiento, si no es un problema, debe discutirlo y confirmarlo, rechazar este BUG y luego el probador cierra este problema.
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.
028. 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.
029. ¿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.
030. ¿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, organizada, le gusta enfrentar desafíos, tiene la confianza para hacer todo bien, fuertes habilidades de comunicación, buenos comentarios de gerentes anteriores muestran que lo estoy haciendo bien
031. Describa brevemente lo que ha hecho en su trabajo anterior 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.
032. ¿Cuál es el uso de la estática en C/C++? (Por favor explique al menos dos)
En el cuerpo de una función, una variable declarada estática mantiene su valor a través de las llamadas a la función.
Dentro de un módulo (pero fuera de una función), las funciones utilizadas dentro del módulo pueden acceder a una variable declarada estática, pero no otras funciones fuera del módulo. Es una variable global local.
Dentro de un módulo, una función declarada estática solo puede ser llamada por otras funciones dentro de ese módulo. Es decir, esta función está restringida al ámbito local del módulo en el que se declara
033 ¿Cuál es la diferencia entre una referencia y un puntero?
Las referencias deben inicializarse, los punteros no.
La referencia no se puede cambiar después de la inicialización y el puntero puede cambiar el objeto al que apunta.
No hay referencias a valores nulos, pero hay punteros a valores nulos.
034. ¿Qué protocolo de red utiliza Internet? ¿La estructura jerárquica principal 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) (Protocolo de resolución de direcciones)
035. Hable 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: verifique antes los principales puntos de control y juicio; según la profundidad primero, se puede realizar y verificar primero una función de software completa; la función se confirma antes, lo que brinda confianza; solo se necesita un controlador, lo que reduce el costo del desarrollo del controlador , soporte de 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.
Adaptarse a la estructura de control del producto es relativamente claro 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 altos riesgos técnicos y deben verificarse lo antes posible ; espero ver el sistema del producto tan pronto como sea posible comportamiento funcional.
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.
036. Las pruebas de aceptación de software incluyen pruebas de aceptación formales, pruebas alfa y pruebas beta.
037. Hay muchas estrategias para las pruebas 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, las pruebas de usabilidad. pruebas.
038. 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.
039. Los pasos para escribir un caso de prueba dibujando un diagrama de causa y efecto son ___, ___, ___, ___ y convertir el diagrama de causa y efecto en un diagrama de estado Hay cinco pasos. 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 decisiones.
§ Tomar como base cada columna de la tabla de juicio y diseñar casos de prueba.
040. Por favor, dígame quién es la mejor persona para completar estas pruebas y cuál es la prueba.
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 evaluadores.
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.
041. ¿Qué aspectos se deben considerar al diseñar casos de prueba, es decir, qué aspectos se prueban mediante 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 deben considerar los casos de prueba son entrada, salida, operación y entorno de prueba; además, los casos de prueba deben considerar el tipo de prueba (función, rendimiento, seguridad...), esta parte se puede responder refiriéndose a TP. Además, también debe considerar la importancia y la prioridad de los casos de uso)
042. Al guardar un archivo de texto en Windows, aparecerá un cuadro de diálogo para guardar.Si se 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 /,, *.
043. 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
044. ¿Cuándo comenzó el proyecto de pruebas de software?, ¿por qué?
Las pruebas de software deben estar involucradas 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 generados durante el proceso de desarrollo de software deben probarse, y los defectos del software tienden a amplificarse. más costará arreglarlo, mayor será el costo.
045. ¿Qué son las pruebas 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 encuentra el problema de nuevo. 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.
046. ¿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 orientados a procesos; clases en orientados a objetos). El trabajo de prueba para verificar la corrección es encontrar posibles errores que puedan existir dentro de cada módulo de programa. son generalmente 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 hardware, periféricos, software de soporte, datos y personal. En el entorno operativo real, realice una serie de pruebas de integración y validación sobre el sistema informático.
047. ¿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 tener conciencia de prevención de defectos 6. Tener cierta experiencia en programación
048: ¿Qué tipos de pruebas de software conoces? Permíteme presentarlas 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 esfuerzo 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 , prueba de recuperación
049: ¿Cuál crees que es la clave para hacer un buen trabajo en la planificación de pruebas?
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 "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 las fechas de inicio y finalización de la prueba (cuándo). ), y señalar los métodos y herramientas de la prueba (Cómo), proporcionando 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 escribir 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 los cambios. en los requisitos de software, y el contenido del plan de prueba no se actualiza a tiempo, lo que es engañoso.Ejecutivo 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 los específicos. tácticas para completar la tarea de prueba.
050: ¿Cuál crees 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. Imposible de probar completamente para encontrar la mayoría de los problemas en un tiempo razonable con la menor cantidad de casos de uso
051: ¿Cuál es su objetivo 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.
052: ¿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 bajo un determinado rendimiento. Actualmente, en el Sistema de seguimiento de errores, no hay errores graves generales en esta versión. El número de errores comunes es inferior a 3, y la tasa de reparación de errores es del 90%.Los parámetros anteriores y así sucesivamente, y luego el administrador de desarrollo, el administrador de pruebas y el administrador de proyectos firmarán para aceptar la versión.
Si hablamos de la macro, la prueba terminará cuando el software desaparezca por completo.
053. ¿En qué etapas debe constar un conjunto completo de pruebas?
Análisis de viabilidad, análisis de requisitos, diseño general, diseño detallado, codificación, pruebas unitarias, pruebas de integración, pruebas de sistemas, pruebas de aceptación
054. ¿Conoce el proceso de desarrollo de software de la empresa en la que trabajó anteriormente? Si es así, describa qué tareas deben completarse en un proceso de desarrollo completo? ¿Cuáles son los diferentes roles para completar estas tareas? En su trabajo de prueba anterior, usted ¿En qué trabajos específicos ha estado involucrado?, ¿en qué parte del trabajo es mejor?
Proceso de desarrollo: investigación de requisitos (requisitores), análisis de requisitos (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 del sistema, revisión de diseño de resumen, diseño de prueba de integración, revisión de diseño detallada, 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.
055. ¿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, métodos de esquema
056. ¿Cuántos métodos existen para el diseño de casos de prueba orientados a objetos?, ¿cómo realizarlo?
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ño de casos de prueba basados en código
057. ¿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
Mercury LoadRunner Analysis: para analizar los resultados de las pruebas
058. ¿Dónde está tu mayor interés en las pruebas?¿Por qué?
¡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 basó en cierta información que aprendí del sitio web de pruebas de Wuyou. En ese momento, apuntaba al hecho de que las pruebas requieren muchas habilidades para hacerlo bien. Aunque es fácil para empezar, es difícil hacerlo bien. Difícil, aunque en ese momento tenía muchas ganas de hacer desarrollo (básicamente no me perdía los cursos profesionales en la escuela, porque me gusta mi carrera), pero viendo que las pruebas son más difíciles y desafiante que el desarrollo, mi voluntad de hacerlo bien 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 del caso de prueba, porque la esencia de la prueba radica en la caso de prueba. En términos de diseño, los casos de uso deben escribirse mucho antes de que salga la versión. ¿Qué método de prueba debe usarse para escribir? (es decir, plan de prueba o estrategia de prueba). Si solo prueba una nueva tarea, tiene dedicar una cierta cantidad de tiempo a digerir los requisitos comerciales y la base técnica, las necesidades comerciales se entienden bien (comunicarse más con los gerentes y desarrolladores de productos puede lograr el objetivo), pero la base técnica no es tan simple, lo que requiere su capacidad de aprendizaje consciente , como el sitio web, el más básico Para el conocimiento técnico, necesita saber cómo funciona internamente el sitio web, cómo responde el fondo a las solicitudes de los usuarios, cómo construir un entorno de prueba, 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. En general, la mayoría de los errores se pueden encontrar al iniciar la prueba de acuerdo con los casos de prueba. Todavía hay algunos errores que deben comprenderse mejor durante el proceso de prueba Obtenga más información, agregue casos de prueba y pruebe errores. ¿Y cómo encontrar errores? Esto requiere cuidado y paciencia para encontrar errores cuando los casos de prueba son válidos. Cada caso de uso puede encontrar errores, y cada lugar puede cometer errores, 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 se encuentran errores 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 a los desarrolladores a localizar inicialmente el problema.
59. ¿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 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 prestan más atención a la experiencia del usuario, si es fácil de usar, fácil de entender, estandarizada (teclas de acceso directo y similares), hermosa (si puede atraer la atención del usuario) y segura (en la medida de lo posible) cuando se usa el producto. La recepción evita que los usuarios ingresen accidentalmente datos no válidos. Por supuesto, teniendo en cuenta la experiencia, no es demasiado grosero mostrar una advertencia)? Al realizar una determinada prueba de rendimiento, en primer lugar, puede ser una punto de función, en primer lugar para asegurarse de que su función no sea un problema, y luego considere la prueba de rendimiento de este punto de función
060. Intente comparar las diferencias y conexiones entre las pruebas de caja negra, las pruebas de caja blanca, las pruebas unitarias, las pruebas de integración, las pruebas del sistema y las pruebas de aceptació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 la descripción de su función de acuerdo con la especificación de requisitos del programa. 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 faltantes? 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 algún error 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 evaluadores 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 interfaz se eliminaron básicamente. Luego, se debe verificar más la validez del software. Esta es la tarea de la prueba de aceptación. , es decir, el rendimiento funcional del software, como los usuarios esperarían razonablemente.
061. Cuando el desarrollador dice que no es un error, ¿cómo lo solucionas?
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 es descubierto por el usuario o si algo sale mal. incorrecto, ¿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.
062. ¿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.
063. ¿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.
064. 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 sobre negocios para complementar el conocimiento comercial; si hay datos reales del usuario, puede usar los datos reales como referencia; consulte casos de uso anteriores e informes de errores ; en el proceso de uso del software Piense más; comuníquese más con los gerentes de producto.
065. ¿Cómo ubicar el rol de los casos de prueba?
Organización: redacción, organización, cobertura funcional, repetibilidad, seguimiento, validación de pruebas
066. ¿Qué es una prueba de compatibilidad? Dé un ejemplo de cómo usar la lista de pruebas de compatibilidad para realizar 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.
067. 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
068. ¿Cuáles son las precauciones para las pruebas de requisitos?
Si se utiliza la plantilla de la empresa, si el contenido del documento se ajusta a la especificación, si todos los requisitos se clasifican y analizan correctamente, si todos los requisitos son consistentes, si los requisitos son factibles (es decir, la combinación de requisitos tiene un solución), si los requisitos se pueden usar como restricciones para implementarlos, si los requisitos son adecuados (es decir, si se pueden enviar a una organización de desarrollo formal con una probabilidad razonable de producir el producto deseado), si todos los demás requisitos tienen referencias cruzadas correctamente y si las descripciones de los usuarios son claras, si los requisitos se describen en el idioma del cliente, si la descripción de cada requisito es clara e inequívoca, y se puede entender cuando se entrega a un grupo independiente para su implementación, si todos los requisitos son verificables, si cada requisito tiene independencia, incluso si hay un cambio, no afectará a otros requisitos, si los indicadores de desempeño son claros, si los requisitos no funcionales están completamente representados, si los estándares o protocolos aplicables están completamente enumerados y si hay conflictos entre estándares y protocolos.
069. El papel de la clave principal y la clave externa, las ventajas y desventajas del índice?
Respuesta: Clave primaria: Es la clave de identificación única en la tabla. Rol: 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 presionará la clave principal Los registros se muestran en el orden de los valores, o en el orden ingresado si no se especifica una clave principal.
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.
Las ventajas del índice: 1. Al crear un índice único, se puede garantizar la unicidad de los datos en la tabla, 2. Acelerar la recuperación de datos, 3. Acelerar la conexión entre tablas, 4. Al utilizar la recuperación de datos de agrupación y clasificación, puede recuperar significativamente el tiempo de agrupación y clasificación 5. Utilice el ocultador de optimización en el proceso de consulta para mejorar el rendimiento del sistema.
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.
070. ¿Cuál es el proceso de prueba de desempeño?
1. Análisis de requisitos de prueba 2. Formulación y revisión del plan 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 la experiencia de prueba
071. ¿Describa brevemente el ciclo de vida de los insectos?
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
072. ¿Qué deben contener los registros de defectos?
Identificación del defecto, tipo de defecto, gravedad del defecto, posibilidad de ocurrencia del defecto, prioridad del defecto, estado del defecto, origen del defecto, fuente del defecto, causa del defecto;
073. ¿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
Prueba de rendimiento - velocidad de respuesta y robustez del sistema bajo gran concurrencia
074. ¿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.
Coordinar con el gerente del proyecto para comprender el cronograma y el arreglo del proyecto.
075. ¿Cuál crees que es la clave para hacer un buen trabajo en el diseño de casos de prueba?
Muy claro sobre los requisitos comerciales y de software, y puede elegir diferentes diseños de casos de prueba de acuerdo con diferentes requisitos
076. ¿Ha realizado alguna vez una 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.
077. ¿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.
078. En su trabajo anterior de prueba de software, ¿ha utilizado alguna herramienta para administrar defectos de software (errores)? En caso afirmativo, describa el proceso de seguimiento y administración de defectos de software (errores) en combinación con las herramientas.
CQ, también puede utilizar herramientas gratuitas como BugFree.
079. ¿Qué piensa 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
Si el artículo es útil para usted, comuníquese para hacer una fortuna y darle un me gusta. Gracias por su apoyo. Sus me gusta son la motivación para mis actualizaciones continuas.
Resumir:
Por último, me gustaría agradecer a todos los que han leído detenidamente mi artículo. La reciprocidad siempre es necesaria. Aunque no es algo muy valioso, puedes quitártelo si lo necesitas:
Estos materiales deben ser el almacén de preparación más amplio y completo para los amigos [de pruebas de software]. Este almacén también ha acompañado a decenas de miles de ingenieros de pruebas a través del viaje más difícil, ¡y espero que pueda ayudarlos!