1. ¿Qué son las pruebas de software y el propósito de las pruebas de software?
Respuesta de referencia:
¿Qué es la prueba de software?
·La prueba de software es el proceso de operar un sistema o un programa de aplicación bajo condiciones controladas y evaluar los resultados de la operación.Las llamadas condiciones de control deben incluir condiciones normales y condiciones anormales.
·El proceso de pruebas de software debe promover deliberadamente la ocurrencia de errores, es decir, las cosas no deben aparecer cuando deben aparecer o no deben aparecer cuando deben aparecer. En esencia, las pruebas de software son "detección" y los defectos de software se encuentran en "detección".
·Las pruebas de software se ejecutan a lo largo de todo el ciclo de definición y desarrollo de software.Las especificaciones de requisitos de software, el diseño estructural y la programación* son objetos de las pruebas de software.
·Las pruebas de software incluyen pruebas de caja blanca y pruebas de caja negra. Las pruebas de caja blanca son una prueba de la corrección del código del programa. Las pruebas de caja negra son independientes del código del programa. Desde la perspectiva de los usuarios, ciertos pasos de prueba y casos de prueba se pasan, para verificar si la función del software, el rendimiento y otros indicadores pueden cumplir con los requisitos reales de la aplicación.
Propósito de las pruebas de software:
El propósito de las pruebas de software es asegurar la calidad final de los productos de software y controlar la calidad de los productos de software durante el proceso de desarrollo de software. En términos generales, las pruebas de software deben ser realizadas por un centro de evaluación de productos independiente. En estricta conformidad con el proceso de prueba de software, se formulan los planes de prueba, los esquemas de prueba y las especificaciones de prueba, se implementan las pruebas, se analizan los registros de prueba y se elaboran los informes de prueba. escrito de acuerdo con la situación de la prueba de regresión. El propósito de la prueba es probar que el programa es incorrecto, pero no puede garantizar que el programa esté libre de errores.
2. ¿Dónde están los principales riesgos de las pruebas de software?
Respuesta de referencia:
Al no probar completamente el software, en realidad estamos eligiendo el riesgo, porque es muy probable que existan defectos en partes que no han sido probadas. Por ejemplo, para comodidad del programador, aparecerán algunos cuadros de información emergentes al depurar el programa, y estos avisos solo aparecerán bajo ciertas condiciones. Sucede que algunos de estos códigos no se han comentado antes de que se publique el programa. . Al probar, el ingeniero de pruebas no lo probó. Si el cliente lo encuentra, sería un defecto costoso porque el cliente no lo descubrió hasta después de la entrega.
Por lo tanto, debemos hacer todo lo posible para elegir el volumen de prueba más apropiado para minimizar el riesgo.
Serie de pruebas de terminales móviles para expertos senior en pruebas de software
3. ¿Cuál es el estado de las herramientas de prueba en el trabajo de prueba?
Respuesta de referencia:
Muchos ingenieros de pruebas en China están bastante obsesionados con las herramientas de prueba, especialmente algunos novatos, e incluso esperan que las herramientas de prueba puedan reemplazar las pruebas manuales. Las herramientas de prueba juegan un papel auxiliar en el trabajo de prueba y generalmente se utilizan para mejorar la eficiencia de la prueba. Las pruebas automatizadas compensan las deficiencias de las pruebas manuales y reducen una cierta cantidad de trabajo. De hecho, las herramientas de prueba no pueden reemplazar la mayoría de las pruebas manuales, y algunas pruebas automatizadas, como las pruebas de rendimiento, no se pueden realizar manualmente.
Para la tecnología de prueba automática, debe tratarse por separado de acuerdo con las diferentes situaciones del software. Generalmente, la tecnología automática se aplicará a lugares que causan mucho trabajo repetitivo, puntos de presión del sistema y cualquier lugar que sea adecuado para usar programas. para resolver grandes cantidades de datos de entrada. Luego busque una herramienta de prueba automática adecuada o desarrolle un programa de prueba usted mismo. No debe utilizarse con fines de prueba.
4. Cuantos más defectos se encuentren, ¿significa que hay más defectos de software?
Respuesta de referencia:
Este es un fenómeno relativamente común. Los ingenieros de pruebas se estrujarán los sesos antes de encontrar un defecto, pero después de encontrar uno, encontrarán muchos defectos uno tras otro, lo que les da una sensación de logro personal. Las razones principales son las siguientes:
-Generación* reutilización, copia de generación* hace que los programadores sean propensos a cometer los mismos errores. La herencia de clase hace que todas las subclases contengan errores de la clase base, y la copia repetida de la misma generación* significa que también se pueden copiar errores.
-Los programadores están más cansados, lo que puede dar lugar a más defectos funcionales en alguna programación continua. Es un fenómeno común que los programadores trabajen horas extras, por lo que es fácil escribir programas con más defectos cuando la fuerza física no es suficiente. Y estos defectos latentes continuos son exactamente donde entra en juego el ingeniero de pruebas.
"Defectos uno tras otro" no es una ley objetiva, sino un fenómeno común. Si el software está mejor escrito, este fenómeno es menos común. Los evaluadores solo necesitan probar seriamente el programa.
5. ¿Se pueden reparar todos los defectos del software?¿Se repararán todos los defectos del software?
Respuesta de referencia:
Técnicamente, todos los defectos del software pueden repararse, pero no es necesario reparar todos los defectos del software. Lo que tienen que hacer los probadores es poder juzgar correctamente cuando no pueden perseguir la perfección del software. Para todo el equipo del proyecto, lo que debe hacerse es hacer concesiones para cada defecto de software y decidir qué defectos deben repararse de acuerdo con el riesgo. Las principales razones de este fenómeno son las siguientes:
- Recursos de tiempo insuficientes. En cualquier proyecto, generalmente no hay suficientes desarrolladores y probadores, y no hay suficiente tiempo de prueba de regresión presupuestado en el proyecto.Además, la modificación de defectos puede introducir nuevos defectos, por lo que la fuerte presión sobre los plazos de entrega En este caso, ciertas deficiencias deben ser renunciado
- Algunos errores solo aparecen en casos especiales. Este tipo de error se considera de interés comercial y puede repararse en futuras actualizaciones.
-No es un defecto de un defecto. A menudo nos encontramos con algunos problemas funcionales que se tratan como defectos, que pueden ser considerados y tratados más adelante cuando haya tiempo.
Lo último que hay que decir es que los probadores de software, los gerentes de proyectos y los programadores deben discutir si corregir el defecto o no. Las personas con diferentes roles piensan desde diferentes ángulos para tomar la decisión correcta.
6. ¿Los probadores de software son QA?
Respuesta de referencia:
La responsabilidad de los probadores de software es encontrar los defectos del software lo antes posible y asegurarse de que puedan repararse. La principal responsabilidad del personal de control de calidad (QA) es crear o formular estándares y métodos, mejorar la capacidad de promover el desarrollo de software y reducir los defectos del software. El trabajo principal de los evaluadores es la prueba, y el contenido importante del trabajo diario del personal de garantía de calidad es la inspección y revisión, y el trabajo de prueba también es el objeto de trabajo del personal de garantía de prueba.
Las pruebas y la calidad del software son complementarias entre sí, y ambas funcionan para mejorar la calidad del software.
7. ¿Cómo reducir las pérdidas causadas por los saltos de trabajo de los evaluadores?
Respuesta de referencia:
El cambio de trabajo en la industria de TI ya es un fenómeno común, y el cambio de trabajo traerá ciertas pérdidas tanto para la empresa como para el individuo. El equipo de prueba sin duda se enfrentará a la amenaza de saltos de trabajo. Como gerente de prueba, solo comenzar desde el trabajo diario puede minimizar la pérdida en la mayor medida. Se sugiere partir de los siguientes dos aspectos:
-Fortalecer el aprendizaje mutuo entre los empleados del departamento.El aprendizaje mutuo es el requisito básico para establecer una organización de aprendizaje y un proceso de transferencia de conocimiento. Sobre esta base, la tecnología propiedad de los individuos puede depositarse en forma de conocimiento y puede completarse la transformación del conocimiento tácito al conocimiento explícito.
-Por lo general, cuando una empresa puede brindar a los empleados suficiente espacio para el desarrollo, los empleados no abandonarán voluntariamente la empresa si el salario no es particularmente bajo. Por lo tanto, si queremos retener a los empleados, los gerentes deben vincular el crecimiento personal de los empleados con el desarrollo de la empresa, establecer planes de desarrollo razonables para los empleados e implementarlos. Sin embargo, este requisito debe compararse con una cultura corporativa relativamente buena.
8. ¿Cuál es la diferencia entre producto de prueba y proyecto de prueba?
Respuesta de referencia:
Es habitual comercializar el software después de su desarrollo y venderlo a los usuarios casi sin modificaciones * como un producto de software, es decir, un software que se puede comprar y "vender copias", como Windows2000. Por lo general, el software desarrollado para uno o varios usuarios específicos se denomina proyecto de software.Un proyecto de software es un producto personalizado, que se puede volver a desarrollar completamente de acuerdo con los requisitos del usuario, o los productos de software existentes se pueden modificar para satisfacer requisitos específicos.Necesidades del usuario. Las diferentes características de los proyectos y productos determinan que aún existan muchas diferencias entre nuestros productos de prueba y proyectos de prueba:
- Distintos requisitos de calidad. Por lo general, la calidad del producto es mayor y el costo de reparar los defectos del producto liberado es mayor e incluso trae muchos efectos negativos. Sin embargo, los proyectos suelen estar dirigidos a un determinado usuario, aunque a mayor calidad mejor, por lo general es suficiente para cumplir con los requerimientos del usuario.
- Cuántos recursos de prueba diferentes se invierten. Los productos de software generalmente son desarrollados por el centro de I + D, y la presión del cronograma es menor. Al mismo tiempo, debido a los requisitos de alta calidad, se invertirán más mano de obra y recursos materiales.
-Al final del proyecto, es necesario aceptar conjuntamente con el usuario la prueba de aceptación, que es una característica que no tiene la prueba del producto.
Además, los productos de prueba y los proyectos de prueba serán muy diferentes en términos de gestión de defectos y formulación de estrategias de prueba.Los gerentes de prueba deben combinar el entorno específico para completar el trabajo de manera adecuada.
9. ¿Cuáles son los puntos de atención en las pruebas conjuntas con los usuarios (pruebas UAT)?
Respuesta de referencia:
Antes de que los productos de software se pongan en producción, generalmente se llevan a cabo pruebas de aceptación del usuario. Si la prueba de aceptación del usuario falla, el resultado directo es que no será "Dinero", y el efecto indirecto es el daño a la imagen de la empresa, que suele ser más grave. De acuerdo con la experiencia del autor, las pruebas de aceptación del usuario deben hacer felices a los usuarios.
De hecho, las pruebas de campo del usuario tienden a ser más una demostración. Con la premisa de no engañar a los usuarios, mostramos a los usuarios las ventajas de nuestro software y, finalmente, nuestro objetivo es satisfacer a "Dios" y sacar "dinero" voluntariamente. Por lo tanto, las pruebas de usuario deben prestar atención a los siguientes elementos:
(1) Es imposible probar todas las funciones en la prueba del sitio del usuario, por lo que se deben probar las funciones principales. Esto debe prepararse con anticipación. Estas funciones básicas deben probarse con anticipación para demostrar que no hay problemas antes de que puedan probarse junto con los usuarios. El propósito de probar los módulos principales es aumentar la confianza del usuario en el software. Por supuesto, si estos módulos tienen muchos problemas, no deben demostrarse.
(2) Si algunos módulos tienen problemas, podemos demostrar otros módulos de funciones comerciales importantes y dar explicaciones razonables a los usuarios cuando sea necesario. Después de ganar tiempo, modifique los defectos a tiempo para compensarlos.
(3) Los usuarios nunca pueden ser engañados y salirse con la suya. La razón es simple, porque el software es para usuarios, y el problema saldrá a la luz tarde o temprano, a menos que pueda modificarlo de inmediato.
Al probar con los usuarios, también debemos prestar atención a varias habilidades de comunicación, para no solo satisfacer los intereses a corto plazo, sino también para sentar una base sólida para la cooperación futura.
10. ¿Cómo escribir el informe de prueba enviado al usuario?
Respuesta de referencia:
A medida que las pruebas reciben más y más atención, es inevitable que el equipo de desarrollo proporcione documentos de prueba a los clientes. Mucha gente preguntará: "¿Podemos proporcionar el informe de prueba en el trabajo al cliente?" La respuesta es no. Porque proporcionar informes de pruebas internas puede hacer que los clientes pierdan la confianza e incluso nieguen el proyecto.
Los informes de prueba generalmente se dividen en informes de prueba internos e informes de prueba externos. El informe interno es nuestro documento de proyecto en el trabajo de prueba, que refleja la implementación del trabajo de prueba. No se discutirá aquí. Los lectores pueden consultar los libros de texto relevantes. Aquí discutimos principalmente cómo escribir informes de pruebas externas Generalmente, los informes de pruebas externas deben cumplir con los siguientes requisitos:
- Preparado sobre la base de informes de pruebas internas, que generalmente se pueden extraer;
- No es posible informar defectos graves a los clientes. Incluso si los defectos se han modificado, no hay necesidad de informar a los clientes sobre los defectos en desarrollo;
- Algunos defectos pueden enumerarse en el informe, pero deben ser defectos de nivel medio, y estos defectos deben repararse;
- El contenido del informe debe ser lo más veraz y fiable posible;
- Todo el informe de prueba debe revisarse cuidadosamente y esforzarse por no traer efectos negativos al proyecto, especialmente el informe de prueba de rendimiento.
Serie de pruebas de terminales móviles para expertos senior en pruebas de software