[Curso intensivo de entrevistas sobre pruebas de software] Cómo obligarte a terminar el tutorial de ensayo de ocho partes sobre pruebas de software en una semana. Después de terminar la entrevista, estarás estable. También puedes ser un ingeniero de pruebas de software bien remunerado (pruebas automatizadas)
Involución es un término muy popular hoy en día y, a medida que su popularidad sigue aumentando, se le conoce vagamente como “todo se puede enrollar”. Investigando su origen, el surgimiento de la palabra involución comenzó con la discusión del 996. Desafortunadamente, la industria de la informática/Internet es el área más afectada y la fuente de palabras como 996, bendiciones, etc. Entonces, como rama muy importante de la industria, ¿cuál es la situación del círculo de pruebas?
¿Cuál es la involución del círculo de pruebas de software?
Antes de hablar de la involución del círculo de prueba, primero debemos entender lo que a menudo llamamos involución.
Involución, una palabra de moda en Internet, originalmente se refiere al fenómeno de que después de que la sociedad humana alcanza una cierta forma definida en una etapa de desarrollo, se estanca o es incapaz de transformarse en otro modelo avanzado. Cuando los recursos sociales no pueden satisfacer las necesidades de todos, la gente compite para obtener más recursos.
Posteriormente difundido en Internet, se utilizó para referirse a la competencia interna irracional o competencia "voluntaria", ahora se refiere al fenómeno en el que los pares compiten por mayores esfuerzos para competir por recursos limitados, lo que resulta en una disminución en el "beneficio" del individuo. relación-esfuerzo." Piense en ello como una "inflación" del esfuerzo.
En el círculo de las pruebas, con arquitecturas basadas en ágiles o incluso Devops, la automatización, una parte importante de estas arquitecturas, se ha vuelto popular, y la industria de las pruebas también ha entrado en una "carrera armamentista" para promover la automatización. En los últimos años, ya sea ingeniero de pruebas, control de calidad ágil o incluso en otros roles, es posible que haya oído hablar de la creciente tendencia de las pruebas automatizadas. Desde una perspectiva empresarial, en muchas empresas, las pruebas automatizadas han aprovechado la transformación ágil. "Los requisitos casi se han convertido en estándar para el trabajo de pruebas. Los requisitos de contratación de las principales empresas para las pruebas también se han actualizado a pruebas automatizadas. Parece que mientras existan pruebas automatizadas, todos los problemas se resolverán". ¿Es este realmente el caso?
Hay un "dilema del cine" que ilustra vívidamente la representación de "involución" y los sentimientos de las personas que participan en ella: se proyecta una película en un cine y el auditorio está oscuro y lleno de espectadores. En ese momento, alguien al frente quiere Viendo con mayor claridad, me levanté para ver la película, así que la gente detrás de mí también se puso de pie para no ser bloqueados... Finalmente, todos en el cine terminaron de ver la película de pie. Pero podrían haber visto la película cómodamente.
En este entorno todo el mundo ha invertido mucho tiempo y energía, pero los beneficios obtenidos son muy limitados. Del mismo modo, en el campo de las pruebas, la arquitectura compuesta según la pirámide jerárquica de pruebas ha sufrido cierto impacto y destrucción. El fenómeno de 35 años provocado por el "equilibrio de Nash" en la industria provocado por la involución se ha convertido en una cicatriz y un cáncer adheridos a esta industria. Este tema se mencionará específicamente más adelante, esta vez solo hablaré sobre la involución de la tecnología de prueba en sí.
Involución de la propia tecnología de pruebas.
En las pruebas ágiles, existe una estrategia de prueba en capas. Generalmente, las pruebas se dividen en tres niveles, a saber, capa de interfaz de usuario, capa de servicio y capa de unidad. La estructura específica es la siguiente:
La capa UI es la capa responsable de la visualización de la interfaz y la interacción del usuario. También es la parte a la que los ingenieros de pruebas están expuestos con mayor frecuencia. Se completan una gran cantidad de pruebas en esta capa y también es la capa de prueba con el rango más amplio. de aspectos. La capa de Servicio proporciona interfaces y servicios. La capa UI puede obtener datos de la capa de Servicio y también puede guardar datos en una base de datos u otro espacio de almacenamiento a través de la capa de Servicio. Los objetos de prueba de la capa Unidad son funciones o métodos; los objetos de prueba de la capa Servicio son módulos e interfaces; los principales objetos de prueba de la capa UI son la visualización y la interacción.
Este es un mecanismo jerárquico muy completo y altamente eficiente que clasifica el contenido de diferentes funciones y categorías, de modo que existen medios y formas correspondientes para realizar las pruebas correspondientes para cada capa de prueba. Este es un cambio basado en el marco o modelo ágil, con las pruebas como base para adaptar el modelo. Para diferentes niveles, los ingenieros de pruebas utilizan herramientas de prueba o métodos de prueba con diferentes enfoques para combinarlos y obtener las pruebas más eficientes y completas.
En la actualidad, las pruebas automatizadas se han convertido en un punto candente y todo el trabajo de pruebas ha comenzado a transformarse hacia la automatización. Las pruebas automatizadas, que son solo una parte importante del trabajo de pruebas, parecen haberse convertido instantáneamente en el único contenido de la actualización, actualización y La transformación del trabajo de pruebas y sus métodos de medición simples y eficientes también hacen de las pruebas automatizadas un objetivo favorecido para los KPI y OKR.
Lo más obvio es que, de acuerdo con la teoría de la pirámide de pruebas automatizadas, una gran cantidad de trabajo básico se lleva a cabo en la etapa de prueba unitaria, mientras que las pruebas de interfaz se completan en base a las pruebas unitarias, y luego finalmente se lleva a cabo la verificación de la interfaz mediante pruebas de UI. . Este triángulo es la estructura estratégica de las pruebas automatizadas.
prueba de unidad
Las pruebas unitarias requieren probar cada módulo funcional (función, método de clase) durante el desarrollo, como detectar si una determinada función funciona normalmente como se esperaba. Las pruebas de caja blanca se utilizan generalmente en pruebas unitarias, que prueban principalmente la estructura lógica interna del código.
Pruebas de interfaz
Las pruebas de interfaz requieren pruebas de la transmisión de datos, el rendimiento de la base de datos, etc. para garantizar la integridad de la transmisión y el procesamiento de datos. El funcionamiento completo de la función de la interfaz juega un papel importante en la expansión, actualización y mantenimiento de la función de todo el proyecto. Las pruebas de la interfaz generalmente se llevan a cabo mediante una combinación de pruebas de caja negra y pruebas de caja blanca.
pruebas de interfaz de usuario
Las pruebas de UI se centran en la experiencia del usuario. Todas las funciones del software se muestran a los usuarios a través de esta capa, por lo que las pruebas de UI también son muy importantes.
Dado que las pruebas unitarias implican muchas pruebas de caja blanca, los aspectos más básicos los completa el personal que realiza recorridos o revisiones de código, mientras que el Servicio se realiza parcialmente de forma manual y la interfaz de usuario se centra en la experiencia del usuario final, por lo que en la interfaz de usuario automatizada. Las pruebas no se utilizan al 100% en las pruebas y se requiere operación manual para determinar la facilidad de uso de la interfaz de usuario. Se puede ver que tal estrategia piramidal todavía no puede abandonar por completo el importante papel de las pruebas manuales en todo el trabajo de pruebas.
Cabe señalar que muchos gerentes que abogan por la automatización integral de pruebas ni siquiera distinguen en detalle las diferencias entre las dos leyendas, sino que simplemente combinan las dos en una, confundiendo las estrategias de prueba automatizadas y las estrategias de prueba jerárquicas.
A medida que los desarrolladores están atrapados en la búsqueda interminable de actualizaciones del marco y los mecanismos de front-end, la involución se ha expandido gradualmente al círculo de pruebas, pero es ligeramente diferente de la pura búsqueda de novedad y velocidad en el desarrollo. Cuando el gran éxito de la capa de toma de decisiones se combinó con las características de las pruebas automatizadas, trabajar duro y rápidamente de manera simple y cruda se convirtió en la única opción, por lo que la involución de la tecnología de pruebas comenzó vigorosamente.
¿Cómo sobreviven los evaluadores a la involución?
Los ingenieros de pruebas tienen que gastar mucha energía en la transformación y construcción del marco de las pruebas automatizadas, y este "empezar a hacerlo rápidamente" ignora algunos requisitos de las pruebas automatizadas en sí. Por ejemplo: la demanda es relativamente estable, hay suficiente biblioteca de casos de uso, el tiempo de entrega permite automatizar el proyecto, etc. Un resultado importante es que una gran cantidad de ingenieros de pruebas en la industria se han convertido en personal cuyo trabajo principal es escribir código de prueba, e incluso se confunden con los desarrolladores, intencionalmente o no, en términos de cognición profesional.
Estos resultados tienen un impacto significativo en la industria de pruebas y en las carreras de los ingenieros de pruebas:
·En primer lugar, como base de toda la industria de las pruebas, el estado y la importancia de las pruebas manuales se han debilitado enormemente, y las capacidades básicas de muchos evaluadores se han debilitado enormemente. Muchas mejoras y ampliaciones de capacidades posteriores requieren análisis y operaciones basadas en pruebas manuales. .comenzó.
·En segundo lugar, muchos proyectos de prueba no son adecuados para la transformación automatizada. El resultado final de cortar las piezas para adaptarlas a las necesidades es limitar en gran medida la eficiencia de las pruebas del proyecto, poniendo el carro delante del caballo.
·Finalmente, cuando todas las pruebas se centren en la automatización, recaerán en la actualización e iteración de la propia pila de tecnología. Para mejorar las capacidades de codificación, obviamente es un camino relativamente más fácil para lograr resultados. Esto no se centra en el negocio en sí, lo que es extremadamente perjudicial para el desarrollo de las propias capacidades de los evaluadores.
En el trabajo de prueba, la arquitectura ágil que originalmente sirvió como especificación y marco se verá inevitablemente afectada por la involución, entre ellas, los casos de prueba con fuertes especificaciones y capacidades de restricción para la calidad y cobertura de las pruebas se verán muy debilitados. se transformarán activa o pasivamente en ingenieros de desarrollo de pruebas, pasando de centrarse en casos de prueba basados en negocios a pulir e iterar arquitecturas y scripts de pruebas automatizadas. Cuando el enfoque se aleja del negocio, el lastre del esfuerzo de prueba en sí (la calidad) inevitablemente se ve afectado.
Además, los requisitos profesionales de los ingenieros de pruebas se reflejan en muchos aspectos, pero tal involución hará que los profesionales de toda la industria se concentren en las capacidades de codificación, cayendo así en la búsqueda ciega de las capacidades de codificación sin prestar atención a los conceptos básicos para mejorar las capacidades de prueba. ... En un extraño círculo. Cuando se forma un círculo vicioso de este tipo, el desarrollo del círculo de pruebas se verá muy afectado y, para los ingenieros de pruebas del círculo, la actualización de las habilidades y conceptos de prueba se verá enormemente perturbada.
Sólo si no olvidas tu intención original podrás lograr el éxito. Hoy en día, a medida que la ola tecnológica continúa actualizándose e iterando, los ingenieros de pruebas también deben "nunca olvidar la intención original", la llamada metafísica se llama "Tao". En términos de conciencia, siempre considere las necesidades comerciales como el punto de referencia del trabajo. captar el núcleo de la calidad y exigir puntos de referencia.; Lo físico se llama "herramienta", ya sean pruebas manuales, pruebas automatizadas o pruebas exploratorias, debe basarse en la intención original del "Tao" y servir al trabajo de prueba. Sólo así los ingenieros de pruebas podrán encontrar su propio camino profesional en la constante involución interna o externa del círculo de pruebas.
El trabajo de TI es ciertamente un trabajo duro y las pruebas de software no son una excepción. Ejecuto casos de uso todos los días, rastreo errores y peleo con compañeros de desarrollo y productos. Es infinitamente divertido pelear con otros. Pero es precisamente gracias a estos esfuerzos silenciosos que un desastre que debería haber ocurrido frente a los usuarios ha ocurrido frente a de mí de antemano ¿Sucedió, hubo un sentimiento mesiánico?
Salvamos al usuario y al software del abandono y desinstalación. Ya que ha elegido la profesión de prueba, es mejor seguirla sin olvidar su intención original ~~
Los siguientes son materiales de apoyo para el aprendizaje. Para aquellos que están haciendo [pruebas de software], debería ser el almacén de preparación más completo y completo. Este almacén también me ha acompañado en el viaje más difícil. ¡Espero que también pueda ayudarlos a ustedes!
Subprograma de entrevista de prueba de software
¡Un banco de preguntas de prueba de software que ha sido utilizado por millones de personas! ! ! ¡Quién es quién lo sabe! ! ! El miniprograma de prueba de entrevistas más completo de Internet. Puede usar su teléfono móvil para responder preguntas, tomar el metro, el autobús y enrollarlo.
Cubre las siguientes secciones de preguntas de la entrevista:
1. Teoría básica de pruebas de software, 2. web, aplicaciones, pruebas de función de interfaz, 3. red, 4. base de datos, 5. linux
6. Web, aplicaciones, automatización de interfaces, 7. Pruebas de rendimiento, 8. Conceptos básicos de programación, 9. Preguntas de la entrevista de recursos humanos, 10. Preguntas de prueba abiertas, 11. Pruebas de seguridad, 12. Conceptos básicos de informática
Cómo obtener documentos:
Este documento debería ser el almacén de preparación más completo y completo para los amigos que quieran participar en [pruebas de software]. Este almacén también me ha acompañado en el viaje más difícil. ¡Espero que también pueda ayudarlo a usted!
Todo lo anterior se puede compartir, solo necesitas buscar en la cuenta oficial de vx: Programmer Hugo para obtenerlo gratis.