Proceso de prueba de software

Prueba de unidad

Prueba de integración

Prueba de sistema

Los pasos generales del programa, pero en el proceso real de producción de software, estos pasos están lejos de ser posibles. Sujeto a disponibilidad.

¿Por qué no puedo hacerlo?

Esto se relaciona con muchos factores, como el tamaño y la naturaleza de la empresa, el tamaño y la naturaleza del software, el tipo de desarrollo de software (algunos son solo versiones de demostración), y una razón se deriva de lo anterior, el equipo Sistema de gestión (¿Hay alguna fuerza para hacer algunos pasos amistosos, como pruebas de unidad, todo el mundo sabe, ¿por qué no hacerlo?);

Prueba de unidad:

Departamento de I + D general Todos los líderes están pidiendo a los desarrolladores que escriban un código de prueba de unidad, porque los líderes pueden darse cuenta de la importancia de la prueba de unidad según su propia experiencia y, básicamente, escribir pruebas de unidad para cada función pequeña. Aunque es una prueba, no tiene que escribirse después de escribir el código, ya que las pruebas unitarias tienen su propia particularidad, antes de desarrollar una función, no hay duda de que el ingeniero ha pensado detalladamente en la implementación de cada función pequeña en el módulo. Y la planificación, cómo se debe implementar una función, el corazón lo sabe todo, en esta premisa, puede escribir de antemano los casos de prueba unitaria y escribir pruebas de unidad, pero también un análisis completo de cualquier error que pueda ocurrir en una función (esto es muy importante). Analice el proceso, que evitará en gran medida algunos errores. En realidad, este tipo de problema parece demasiado. Da la impresión de que el programador simplemente implementa la función a ciegas, sin considerar la integridad de la función. Tan robusto que, mientras se escriba el programa, Lima puede conocer la calidad del código. Otra ventaja es que la prueba de la unidad puede "escuchar" los cambios de código y la conexión del módulo en el futuro desarrollo. La mayoría de los errores que se han cometido, con el fin de evitar los nuevos errores en la mayor medida, este es el cuchillo que no se cortará por error.

Pruebas de integración:

Solía ​​pensar que la teoría del libro no es tan buena como la experiencia de la aplicación real. Después de un tiempo, descubrí que no lo es; mi resumen es que Cuando su crecimiento encuentra un cuello de botella, la teoría entra en juego. Lo que quiero decir es el concepto de cohesión y acoplamiento que se dice en Ingeniería de Software. No entendí su verdadero significado cuando era un principiante, y ahora siento su importancia cuando lo uso. Para el desarrollador del módulo, al igual que construir un avión, el trabajo del programador es producir un ala de avión o hacer una rueda de avión. Si la realización principal de la rueda que hizo aún depende de la estructura principal del propio fuselaje, y el módulo en sí no tiene muchas cosas nuevas, solo cambie el color y aumente el patrón, puede ver que esta rueda no puede ser desde el plano. Retirarlo o quitarlo es muy laborioso y no se puede usar, pierde su significado, su núcleo es el fuselaje, no la rueda en sí, y si hace la rueda, todo el tema de la función está en la rueda, la aeronave usa Cuando solo tiene que colgar, si la aeronave no quiere usarlo, puede levantarlo y cambiarlo, es como el concepto de cohesión y acoplamiento visto por el módulo del programa, para que cada módulo pueda tratar de no afectar el uso. Mejore la cohesión y reduzca el acoplamiento entre los módulos. Esto tiene la ventaja de facilitar la reutilización de los módulos, facilitar el posicionamiento de los problemas y facilitar la limpieza de la estructura general del programa (personalmente, creo que la idea de clase también tiene tales ventajas y otras clases). Una función es la reutilización, la reutilización para reducir la cantidad de código): en las pruebas de software, la prueba de integración es la más larga, la más repetitiva, la más importante La mayoría de los errores se descubren en esta etapa. Lo más común que siento durante la prueba es que el acoplamiento entre los módulos no se maneja bien, lo que hace que la función de cambiar un módulo desencadene indirectamente la función de otros módulos. Los requisitos completos del programa y el diseño detallado son factores importantes para generar dichos errores, y siempre es difícil para los programadores tener en cuenta estos problemas cuando se modifican, lo que también dificulta la ubicación de los errores.

La prueba de regresión en esta etapa es un proceso repetitivo y agotador. Después de cada cambio de programa, para evitar el error del módulo asociado, la prueba de regresión relevante se debe realizar después del cambio. La profundidad de la regresión es básicamente Diseñe todos los módulos relevantes en él, por lo que este tipo de prueba, utilizando prueba automatizada con prueba manual, es más práctico.

Prueba del sistema:

La última ronda de prueba antes de que se envíe el programa, en realidad esta ronda Se puede pensar en la prueba como un "vehículo de prueba" industrial, que es la puesta en servicio in situ. Implica todos los aspectos del programa, ya que se prueba en el entorno en el sitio, por lo que los errores probados en esta etapa son más prácticos; en general, este paso es realizar pasos de prueba de integración más complejos en el entorno real, para evitar El motivo principal del error es la precisión de la demanda, ya que los errores en esta etapa son generalmente, el aspecto de la red, generalmente involucra el fondo de la red, la estabilidad de la red, y esto a menudo se ignora en la prueba de integración.

Sin embargo, la realidad hace llorar a la gente;

¿Por qué dices esto? (Usuario)

1, es la eficiencia de la compañía, prueba de luz

2, el tamaño del programa es pequeño, no necesita pruebas del sistema

3, el programador básicamente no se convirtió en una unidad Hábitos de prueba

4, la administración del equipo no tiene principios duros

5, algunos programas no tienen especificaciones de requisitos, qué hablar, análisis de demanda

procedimientos generales de subcontratación, ambos Es una prueba simple, incluso la necesidad de enviar un error no lo es, mientras se realiza la prueba y la corrección (al final, un programa de este tipo debe realizar la gestión de errores, no lo sé), no hay una especificación de requisitos ni un análisis de la demanda; estoy pensando en el ciclo de desarrollo Si un programa relativamente pequeño realiza un proceso de prueba de desarrollo completo, no valdrá la pena, ya que el pequeño error del programa es aún relativamente pequeño. La formulación de las reglas de cualquier proceso parece ser la mejor basada en la realidad. No es necesario seguir los principios inherentes y utilizar ¡Larga vida! Los programas grandes aún deben realizar un proceso completo;

¿Cuál es el estándar para decidir si necesita realizar la administración de errores?

Una compensación entre costo y calidad