Introducción a la planificación de juegos (9) - Generación de planes de prueba

Generación de plan de prueba

El plan de prueba pertenece a la categoría de ingeniería de software y es la fuerza principal para probar juegos para planificadores. Parece que nunca he oído hablar de ningún planificador que describiera el proceso de prueba como agradable, porque la prueba en sí es algo muy aburrido y doloroso. (Si juegas el mismo juego una y otra vez día y noche, docenas o cientos de veces con contenido repetitivo o incluso poco interesante, nadie pensará que este proceso es interesante). Un plan de prueba razonable puede reducir la carga de trabajo de los evaluadores y También permite que los problemas de prueba se resuelvan lo antes posible. Esto requiere que los desarrolladores del plan de prueba tengan una comprensión integral del desarrollo del juego y puedan controlar el progreso de la prueba.

Las pruebas son una parte extremadamente importante del desarrollo de un juego y el tiempo que requiere generalmente ocupa aproximadamente 1/3 de todo el ciclo de desarrollo. Las pruebas se ejecutan durante todo el proceso de desarrollo. Las pruebas de módulos a pequeña escala las completan los propios programadores. Para la planificación, lo que realmente debe preocupar es cómo completar la prueba del producto final. Según la teoría de la ingeniería de software, existen dos métodos de prueba principales: pruebas de caja negra y pruebas de caja blanca. La llamada prueba de caja negra consiste en tratar el objeto que se va a probar como una caja negra y no es necesario saber cómo se procesa en su interior, siempre que se prueben los datos de entrada y salida, mientras que la prueba de caja blanca es solo; por el contrario, el evaluador debe comprender el objeto de prueba. El proceso de procesamiento interno es muy familiar y todas las ramas y bucles internos se pueden experimentar con fines de prueba. Las pruebas de caja negra y las pruebas de caja blanca son los métodos de prueba más básicos y son teorías de prueba de bajo nivel. Los planes de prueba reales se basan en estos dos métodos de prueba.

Para las pruebas de juegos, no existen más que estos dos métodos de prueba. El plan de prueba basado en pruebas de caja negra es una prueba de alto nivel, que prueba principalmente el juego a nivel operativo; el plan de prueba basado en pruebas de caja blanca es una prueba de nivel bajo, que prueba varios detalles de diseño. En las pruebas de caja negra, no necesitas saber cómo se ejecuta, ni cómo está diseñado el algoritmo interno. Sólo necesitas ver si el combate o el desarrollo de la trama en el juego se lleva a cabo según lo requerido. Este tipo de prueba puede ser realizada por algunos jugadores que no saben mucho sobre el juego, siempre y cuando escriban claramente lo que quieren hacer, qué efecto lograrán al final y registren los problemas que surjan durante el proceso. el juego. La prueba de caja blanca requiere conocimiento de los métodos de cálculo internos. Por ejemplo, si A golpea a B, la cantidad de sangre que A y B deberían perder en función de su estado actual debería incluirse en este tipo de prueba. Las pruebas de caja blanca deben ser completadas por los propios planificadores, porque el algoritmo interno solo lo conocen los propios desarrolladores, y el planificador que descubre el problema es la persona a la que le resulta más fácil saber cómo resolverlo. Debido a la enorme carga de trabajo de las pruebas, es muy importante organizar razonablemente la proporción de tiempo entre las pruebas y la corrección de errores. De lo contrario, es fácil encontrar problemas pero no tener tiempo para corregirlos, o los problemas se acumulan y no se pueden resolver. El diseño de la prueba debe completarse durante la etapa de diseño del desarrollo. Si no se establece un tiempo razonable en la etapa inicial del desarrollo, el resultado final definitivamente será un retraso continuo.

En el plan de prueba, los diseñadores deben combinar de manera efectiva las pruebas de caja negra y las pruebas de caja blanca según sea necesario, y dividir el período de tiempo de la prueba según los pasos. Según el proceso de desarrollo del juego, las pruebas se pueden dividir a grandes rasgos en pruebas unitarias, pruebas de módulos, pruebas generales y pruebas de productos. Las pruebas unitarias generalmente se centran en los detalles, principalmente probando las capacidades estructurales y la integridad del motor durante la etapa de desarrollo del motor del juego. Esta parte del trabajo requiere una meticulosidad estricta, porque cualquier pequeño error puede provocar una gran cantidad de ERRORES en la etapa posterior. En este momento, los desarrolladores y planificadores de programas deben comunicarse sin barreras. Los planificadores deben tener claro el uso y los efectos de cualquier unidad funcional del motor, para garantizar que los problemas puedan descubrirse y señalarse inmediatamente durante las pruebas. Las pruebas del módulo se llevan a cabo según las etapas durante el proceso de desarrollo del juego. Cada vez que se produce un modelo, esta parte debe probarse intensivamente para garantizar la solidez y perfección del sistema.

Las pruebas de interfaz entre módulos también pertenecen a esta parte del trabajo, lo que significa que se debe probar estrictamente cómo cada módulo del juego implementa las transiciones y cómo se intercambian los datos. A menudo, todo es normal durante la prueba interna del módulo, pero surgen problemas después de ensamblar los módulos. ¡Esto debe resolverse a tiempo durante la prueba del módulo por fases! La prueba general es una prueba de nivel relativamente alto. Una vez completada básicamente la DEMO del juego, todo el juego debe sintetizarse desde una perspectiva macro. Esto requiere la capacidad de controlar completamente el progreso. Las pruebas del producto final son el último nivel de garantía de calidad del juego, lo que requiere que una gran cantidad de personas que no son desarrolladores intervengan para bombardear las alfombras. Las pruebas de productos suelen ir acompañadas de algunas actividades de marketing, que no son el alcance de lo que vamos a comentar ahora.

Ya sabemos que el proceso de prueba se divide en varias etapas, echemos un vistazo a los contenidos específicos:

Asignación del tiempo de prueba: la forma en que se asigne el tiempo de prueba afectará directamente al desarrollo. progreso, que incluye el tiempo de prueba, el tiempo de resumen de resultados de la prueba y el tiempo de corrección de errores. En términos generales, los desarrolladores solo piensan que lo que se debe asignar es tiempo de prueba. De hecho, los arreglos razonables para el resumen de pruebas y la modificación de errores y otros trabajos toman más tiempo. Si la situación de prueba no se resume, el director del proyecto no podrá determinar qué partes tienen el problema; si los problemas descubiertos no se modifican inmediatamente, ocurrirán más problemas; Por lo tanto, las pruebas periódicas, el descubrimiento y la resolución de problemas son lo más razonable. Dividir todo el ciclo de desarrollo en varias etapas y las pruebas periódicas son la garantía fundamental para la calidad del producto. Organizar científicamente el tiempo de las pruebas puede resolver la mayoría de los problemas al menor costo; de lo contrario, acumular pruebas al final solo resultará en un desastre.

Disposición de los probadores: la selección y el despliegue de los probadores es muy importante para la calidad del juego. Los evaluadores deben intentar no elegir desarrolladores de juegos. Sólo alguien que no tiene conocimiento del juego puede realmente descubrir problemas en el programa o el diseño, aunque es posible que no comprenda el programa o el diseño del juego en absoluto. Por supuesto, sería mejor tener un equipo de pruebas dedicado. Cuando los fondos y el personal son muy escasos, sería una buena idea contratar personas de otros departamentos que no sean de desarrollo.

Lista de contenido de prueba: esta parte requiere que los diseñadores del plan de prueba consideren cuidadosamente los cálculos y traten de que el contenido de la prueba sea lo más preciso posible al nivel operativo. Esto significa que es mejor refinarlo al nivel de un probador que hace clic con el mouse cientos de veces, porque el probador no conoce el contenido de su juego en absoluto, y solo después de aclarar todas las tareas podrá lograr los resultados esperados. . Es irresponsable exigir que alguien juegue y dé su opinión. ¡Este tipo de plan de prueba solo se puede tirar a la basura! Es necesario aclarar el trabajo de cada evaluador, completar el informe de prueba en forma de formulario de prueba y firmar claramente el tiempo de prueba, para que pueda considerarse un plan de prueba calificado.

Informe de resultados de la prueba: una vez compilado el informe de prueba final, los planificadores deben evaluar y clasificar todas las soluciones, priorizar las soluciones a los problemas descubiertos durante la prueba y luego enviarlas a los departamentos pertinentes. Si el problema es particularmente grave, debe atreverse a solicitar una reelaboración. Solo mediante pruebas estrictas podemos ofrecer productos de juegos de alta calidad. Esta regla se aplica a cualquier industria, ¡y los juegos no son una excepción!

Ajustar el progreso del desarrollo: el impacto en el progreso causado por los problemas descubiertos en la prueba debe informarse a los superiores de manera oportuna, y el cronograma del proyecto debe actualizarse de inmediato y se deben anotar las razones de los cambios. Debido a que el ajuste del cronograma de desarrollo está relacionado con el trabajo de muchos departamentos, es mejor presupuestar el tiempo de prueba en el cronograma de diseño inicial, pero de hecho, en la mayoría de los casos, el cronograma de desarrollo cambia con mucha frecuencia. ¡Cómo detener el progreso sin afectar el tiempo final para completar el juego es un desafío para cualquier gerente de proyecto!

Una vez establecido el plan de pruebas, el resto es tedioso y aburrido trabajo mecánico. Las pruebas son las más dolorosas, pero sin pruebas es imposible que un juego se convierta en un producto. Este es también el problema con la mayoría de los juegos nacionales que cumplen con el cronograma y están plagados de errores.

La formulación científica de planes de prueba y la coordinación del progreso entre varios departamentos son cruciales para cualquier proyecto. Para los nuevos planificadores, aprender a escribir planes de prueba es uno de los cursos obligatorios.

La finalización completa del trabajo de prueba marca el final del desarrollo del proyecto. Pero para la planificación, su trabajo aún no ha terminado. A continuación, debe comenzar a enseñar a los jugadores cómo jugar el juego. ¡Se les explicará lentamente a todos en el futuro cómo completar un tutorial!