¿Cómo aprenden Java los principiantes sin conocimientos básicos, o qué deberían aprender primero?
El flujo de trabajo básico de las pruebas de software se resolverá a grandes rasgos.
En primer lugar, como tester, debes aprender y comprender el negocio y analizar los puntos de demanda.
¿Por qué los testers deberían participar en el análisis de la demanda? Es decir, ¿cuál es el propósito de realizar un análisis de requisitos de prueba?
Primero, convierta las necesidades del usuario en requisitos funcionales: 1) Mida el progreso del alcance de la prueba 2) Mida la rama de procesamiento 3) Mida el escenario del negocio requerido 4) Aclare la entrada correspondiente a la función, Procesamiento y salida 5) Convertir requisitos implícitos en explícitos.
En segundo lugar, aclare los cinco elementos de las actividades de prueba: cuáles son los requisitos de prueba, decida cómo realizar la prueba, aclare el tiempo de prueba, determine los evaluadores, determine el entorno de prueba: las habilidades, herramientas y la experiencia correspondiente requerida. en las pruebas Conocimiento, riesgos que se pueden encontrar durante las pruebas, etc. Los requisitos de las pruebas deben ser lo más detallados y claros posible para evitar omisiones y malentendidos en las pruebas.
¿Cómo realizar el análisis de requisitos de prueba?
Primero, confirme las funciones (funciones comerciales, funciones auxiliares, restricciones de datos, requisitos de usabilidad, restricciones de edición, requisitos de parámetros, requisitos de permisos, restricciones de rendimiento):
1. Funciones o detalles directamente relacionados con el negocio real del usuario
2. Funciones auxiliares: algunas funciones o detalles que ayudan a completar funciones comerciales, como: establecer condiciones de filtro
3. : Detalles de funciones, utilizados principalmente para controlar el rango de visualización de datos, la relación entre datos, etc. al ejecutar funciones.
4. Los detalles de funciones deben proporcionarse en el producto para facilitar algunos detalles. el uso de operaciones de funciones, como: teclas de método abreviado, etc.
5. Restricciones de edición: detalles de la función, algunas restricciones en los elementos de datos de entrada cuando se ejecuta la función, como: solo los números pueden ser ingresado, etc.
6. Requisitos de parámetros: los detalles de la función cuando se ejecuta la función, se deben llevar a cabo diferentes detalles de procesamiento de acuerdo con diferentes configuraciones de parámetros.
7. Requisitos de permiso: los detalles de la función Cuando se ejecuta la función, el proceso se procesa de manera diferente según los diferentes permisos, excluyendo los permisos que restringen directamente una determinada función.
8. la función, los requisitos de rendimiento que se deben cumplir al ejecutar la función
Segundo, análisis del escenario
1 Considere las personas que llaman al escenario: considere qué módulos o sistemas externos llaman a los servicios. proporcionado por cada escenario, y descubrir todas las personas que llaman. Se deben considerar la premisa y las restricciones de la llamada. Cada llamada puede considerarse como un gran proceso empresarial (generalmente, las empresas que interactúan con el exterior tienen una mayor tasa de error y necesitan centrarse en ellas)
2 Considere las relaciones entre varios escenarios dentro del sistema: formar Para un proceso de negocio interno, es necesario analizar las relaciones de restricción y las condiciones de ejecución entre cada escenario y organizar varios diagramas de flujo de negocio.
En tercer lugar, explorar los requisitos implícitos
Esto requiere acumulación de experiencia. de ingenieros de pruebas: 1) Procesos de negocios comúnmente utilizados o prescritos 2) Recorrido de cada rama de proceso de negocios 3) Procesos de negocios que están claramente estipulados como inutilizables 4) Procesos de negocios que no están claramente estipulados pero que no deben usarse 5) Otros anormales o no -operaciones compatibles
Lo anterior es una explicación aproximada de cómo realizar el análisis de requisitos de prueba. Durante el proceso de análisis de requisitos, se escribe todo el plan de prueba. En este proceso, debe consultar la especificación de requisitos. Esta etapa suele ser escrita por el supervisor de la prueba. Incluyendo probadores, tiempo de prueba, herramientas de prueba y métodos de prueba.
El siguiente paso es el diseño del caso de prueba:
El caso de prueba es el módulo central del trabajo de prueba. Antes de ejecutar cualquier prueba, primero se debe completar la redacción del caso de prueba. Un caso de prueba es una instrucción que lo guía en la realización de una prueba y lo ayuda a probar la funcionalidad del software o descubrir defectos del software. Revise los casos de uso una vez diseñados. Hay mucho de qué hablar aquí, como cómo diseñar casos de prueba, métodos para diseñar pruebas, cómo revisar casos de prueba, etc.
Primero, cómo diseñar casos de prueba
Antes de escribir casos de prueba, debemos tener una comprensión clara de los requisitos del proyecto, qué probar, en qué orden probar y qué Los requisitos deben comprenderse bien. Como redactor de casos de prueba, no solo debe comprender los métodos comunes de redacción de casos de prueba, sino que también debe comprender el diseño, las especificaciones funcionales, los escenarios de prueba del usuario y la estructura del programa/módulo. software bajo prueba.
Pasos:
1. Análisis de requisitos de prueba: después de obtener la especificación de requisitos de software del departamento de proyectos, comience a analizar los requisitos del proyecto y organícelos a través de su propio análisis y comprensión. un requisito de prueba y analizar claramente qué funciones tiene el objeto bajo prueba. Aclare la relación entre los casos del conjunto de pruebas y los requisitos en los casos de prueba, es decir, uno o más conjuntos de casos de prueba corresponden a un requisito de prueba.
2. Análisis de procesos de negocio: después de analizar los requisitos, aclare el proceso de procesamiento de negocios de cada función, la combinación de negocios de diferentes puntos funcionales y los requisitos implícitos del proyecto. Si encuentra un diseño de caso de prueba complejo, primero dibuje el proceso comercial del software. Del proceso de negocio se debe obtener la siguiente información:
A. ¿Cuál es el proceso principal?
B. ¿Cuál es el proceso alternativo condicional?
C. Datos ¿Cuál es la dirección del flujo?
D. ¿Cuáles son las condiciones clave de juicio?
Diseño de casos de prueba
Después de completar los dos pasos anteriores. , se puede llevar a cabo el diseño de casos de prueba. Los casos de prueba funcionales deben intentar considerar límites, excepciones y situaciones de rendimiento para descubrir más problemas ocultos. Métodos comunes para diseñar casos de prueba: 1) Clase de equivalencia 2) Valor límite 3) Diagrama de causa y efecto 4) Tabla de decisión 5) Transición de estado 6) Experimento ortogonal 7) Método de escenario 8) Inferencia de errores (Nota: al escribir casos de prueba, En la medida de lo posible, no debe ser una clase de equivalencia válida sino una clase de equivalencia inválida)
4) Autoinspección y revisión interna del departamento después de completar la redacción:
1) El caso de prueba en sí Si la descripción es clara y el lenguaje es preciso;
2) Si el contenido del caso de prueba está completo, si contiene claramente los resultados de entrada y salida esperados; los pasos son claros;
3) Si los datos de prueba utilizados en los casos de prueba son apropiados y precisos;
4) Si los casos de prueba son instructivos y pueden guiar de manera flexible a los ingenieros de pruebas de software a encontrar más defectos a través de casos de prueba y no limitar su pensamiento;
5) Si se tiene en cuenta la eficiencia de la ejecución de los casos de prueba. Para pasos repetidos, ¿se garantiza que los puntos de verificación sean los mismos o existe redundancia en el diseño de los casos de prueba? Esto puede conducir a una baja eficiencia en la ejecución de los casos de prueba;
6) Dibujar una matriz de seguimiento de requisitos de software para verificar si los casos de prueba cubren completamente los requisitos y verificar la cobertura de los casos de prueba;
7 ) Si los casos de prueba cumplen plenamente con los requisitos del software. En realidad, esto es algo difícil de hacer. Considerando la relación tiempo/costo, se debe decidir caso por caso.
Para obtener detalles específicos, consulte "Cómo realizar revisiones de casos de prueba de manera efectiva".
5. Los casos de prueba se actualizan y mejoran.
Después de que se completan los casos de prueba. escritos, deben mejorarse continuamente. Si los requisitos cambian o se agregan nuevas funciones, los casos de prueba deben modificarse y actualizarse en consecuencia, si se descubre durante el proceso de prueba que los casos de prueba no se diseñaron bien. Los casos de prueba deben modificarse y mejorarse; los defectos de software informados por los clientes después de que el software se entrega para su uso son causados por lagunas en los casos de prueba y los casos de prueba también deben mejorarse.
El siguiente paso es el proceso de ejecución del caso de prueba, que representa una gran parte del proceso de prueba.
Primero configure el entorno de prueba, prepare los datos de prueba y haga predicciones. Una vez pasada la predicción, siga la prueba. Los casos de uso ingresan a las pruebas formales y la ejecución efectiva de la prueba puede maximizar el valor de los casos de prueba. Por lo tanto, la ejecución de especificaciones de casos de prueba ayuda a detectar mejor defectos en el código. Según la experiencia laboral personal en pruebas, una buena ejecución de la prueba debe incluir el siguiente contenido:
1. Durante la ejecución de la prueba, evalúe que el tiempo de ejecución de la prueba es insuficiente y que los riesgos deben informarse de manera oportuna. Cumplir con el principio de calidad primero, progreso segundo.
2. Los casos de prueba se ejecutan en orden de prioridad, generalmente orden básico, detallado y de excepción.
3. Para los casos de uso que no se ejecutan, se marcan para su eliminación o no son válidos, se deben indicar los motivos.
4. Los casos de prueba cuestionables (escenarios, pasos operativos, puntos de control, etc.) durante la ejecución deben ser aclarados por el diseñador de la prueba.
5. La ejecución de la prueba requiere verificar los puntos de control descritos en el caso de uso uno por uno para evitar omisiones.
6. Preste atención a los escenarios defectuosos que sean difíciles de reproducir, ya que puede tratarse de un error.
7. Durante el proceso de ejecución, se descubre que faltan casos de uso en el diseño inicial que deben agregarse al documento de casos de uso y verificarse.
8. Se recomienda que los evaluadores realicen casos de prueba repetidos. La ejecución de casos de prueba es inmune a los mismos evaluadores. Evite que posibles defectos pasen desapercibidos en la red activa.
9. Si es necesario, se recomienda conservar los resultados de las pruebas para poder visualizarlos. También facilita la comparación de los resultados de las pruebas entre diferentes versiones.
10. Los problemas confirmados deben presentarse con prontitud de acuerdo con los requisitos del conocimiento de embarque (especificaciones y clasificación de defectos) de la hoja de problemas.
11. Realice un seguimiento del estado de reparación de los tickets problemáticos y regrese para verificar los tickets problemáticos.
12. Al final de cada ronda de pruebas, averigüe si se ha generado un archivo principal.
13. Una vez completada la prueba, cargue el documento del caso de prueba final en el directorio de archivo para realizar la reutilización del caso de uso.
Lo anterior es un proceso de prueba de software general. Si se trata de pruebas automatizadas, se deben escribir y ejecutar scripts basados en casos de prueba.
El proceso de ejecución del caso de prueba incluye: fase de prueba funcional, fase de seguimiento de defectos (bugtracking), fase de prueba de regresión, fase de prueba del sistema, fase de prueba de aceptación, etc. (el sistema ha cumplido las condiciones de prueba (el desarrollo está completado), ejecutar en secuencia de acuerdo con los casos de prueba revisados, registrar los problemas de manera oportuna durante el proceso de ejecución, enviar los problemas al control de calidad de manera oportuna, rastrear los defectos después del desarrollo y reparación, y luego cerrar los defectos después de confirmar el reparaciones Si es necesario actualizar el problema, si no hay verificación en producción, el estado del defecto se cambiará a no verificado en producción. La Parte A, las partes de desarrollo y pruebas discutirán los defectos objetables y la Parte A finalmente determinará el problema. Si hay alguna objeción a los requisitos, se comunicará al gerente, quien se comunicará con la Parte A para presentar algunas sugerencias factibles para los requisitos. Al final, corresponde a la Parte A determinar el. Requisitos específicos (que varían según los procesos de negocio de cada empresa).
Al final, si se han cumplido los requisitos de precisión, se redacta un informe de prueba basado en la situación de la prueba y se realiza una evaluación de todo el proceso de prueba y la calidad de la versión.
p>
El informe de prueba se refiere a escribir el proceso de prueba y los resultados como Documentos, analizar los problemas y defectos descubiertos, proporcionar una base para corregir los problemas de calidad existentes del software y sentar las bases para la aceptación y entrega del software. El informe de prueba es el documento final de la fase de prueba. Un excelente administrador o evaluador de pruebas debe tener buenas habilidades de redacción de documentación. Un informe de prueba detallado contiene información suficiente, incluida la evaluación de la calidad del producto y el proceso de prueba. El informe de prueba se basa en la recopilación de datos durante la prueba y el análisis de los resultados finales.