Resumen del trabajo del ingeniero de pruebas de software

La calidad del software ha atraído cada vez más atención. Como industria emergente, las pruebas de software tienen muchas imperfecciones. A continuación he recopilado un resumen del trabajo de un ingeniero de pruebas de software, espero que le resulte útil.

Resumen del trabajo de los ingenieros de pruebas de software, Parte 1

Hoy en día, el trabajo de pruebas de software ha recibido cada vez más atención por parte de las empresas y muchas personas también han invertido en las filas de las pruebas de software. El papel de los ingenieros de pruebas de software El equipo es cada vez más grande. Pero, ¿cómo convertirse en un excelente ingeniero de pruebas de software? Esta es una pregunta que preocupa más a todos, especialmente Lainiao, que es nuevo en esta industria, quiere saber la respuesta a esta pregunta. Este artículo resume algunas cosas para que todos compartan según mis muchos años de experiencia en pruebas de software en empresas de TI. También espero que todos puedan brindar opiniones y sugerencias valiosas.

Pasos/métodos

Tener al menos tres años de experiencia en desarrollo de software

Muchas empresas de software ahora contratan a algunos estudiantes universitarios recién graduados o con carreras no relacionadas con la informática como sus propio ingeniero de pruebas de software de la empresa, esto está muy mal y muestra irresponsabilidad en las pruebas de software. Aunque pueden encontrar algunos errores en el software, les resulta difícil encontrar algunos errores críticos, fatales y peligrosos en el software. Como todos sabemos, existe un modelo en ingeniería de software llamado modelo en cascada, que es el modelo de software más básico. Este modelo también se llama modelo de cuenco, porque el desarrollo se encuentra en la parte inferior del cuenco y la parte superior izquierda. modelado, análisis de requisitos y diseño en orden. La esquina superior derecha es prueba, implementación y mantenimiento. Esto significa que el desarrollo de software es la base de todas las actividades de software y también es la base de las pruebas de software. Sólo cuando una persona ha experimentado el trabajo de desarrollo de software durante un cierto número de años puede acumular una rica experiencia y saber dónde es fácil cometer errores en el software y dónde es difícil. Esto aportará una experiencia muy valiosa para futuros trabajos de prueba de software.

Tener la capacidad de pensar al revés

Conocí a algunos ingenieros de pruebas de software. Después de realizar pruebas de software durante un período de tiempo, volvieron al trabajo de desarrollo. ¿Qué? La respuesta es que las pruebas de software son demasiado difíciles. El desarrollo es un pensamiento avanzado, mientras que las pruebas son un pensamiento inverso. Siempre hay que encontrar algunas ideas extrañas para operar el software. Los usuarios de software varían ampliamente y los diversos fenómenos encontrados durante el uso del software también varían mucho. Por lo tanto, los ingenieros de pruebas de software deben tener algunas habilidades de pensamiento inverso, pensar lo que otros no piensan y probar lo que otros no. prueba, para que puedan encontrar más errores en el software. Esta es la cualidad más básica de ser un excelente ingeniero de pruebas de software.

Sea bueno comunicándose con los desarrolladores de software

La comunicación es una de las habilidades más críticas que deben dominarse en los proyectos de software actuales. Los probadores de software deben ser buenos para comunicarse con los desarrolladores de software. Los probadores de software deben tener una buena relación con los desarrolladores para que no se conviertan en monstruosidades para los desarrolladores. Esto es muy importante para mejorar la calidad de todo el proyecto de software. La comunicación incluye principalmente:

Discutir los requisitos y el diseño del software: a través de dicha comunicación, puede comprender mejor el sistema de software que se está probando, de modo que pueda probar la menor cantidad de errores posible en el software, reduciendo así el. presión sobre los desarrolladores de software.

Informar buenos resultados de las pruebas: como evaluador, encontrar errores suele ser el resultado del que los evaluadores están más dispuestos y orgullosos, pero informar ciegamente de errores de software a los desarrolladores hará que se sientan disgustados. Progreso del desarrollo de todo el software. Entonces, como ingeniero de pruebas de software, cuando el módulo que prueba no tiene errores graves o tiene muy pocos errores, también puede acudir a los desarrolladores y contarles las buenas noticias, lo que le brindará resultados inesperados.

Discutir algunas cosas no relacionadas con el trabajo: como evaluador, a menudo hablo sobre algunas cosas no relacionadas con el trabajo con los desarrolladores, por ejemplo, podemos hablar sobre noticias, cosas interesantes y familia. Fortalecer el entendimiento mutuo, muchas estadísticas muestran que esto puede mejorar mejor la calidad del trabajo del software.

Bueno para comunicarse con los líderes

Los evaluadores suelen ser los ojos y oídos del líder. Según los resultados de las pruebas de los evaluadores, el líder puede comprender la calidad del producto de la empresa y ajustar otros. trabajar.

Los líderes generalmente están ocupados en el trabajo, por lo que, como excelente evaluador, debe aprender a resumir los resultados de la prueba y es mejor mostrárselos al líder en forma de gráfico.

Dominar algunas herramientas de prueba automatizadas

El trabajo de prueba suele ser tedioso y aburrido. Los evaluadores tienen que realizar un trabajo manual repetitivo durante mucho tiempo, lo que reducirá la eficiencia de las pruebas y, a menudo, afectará la calidad de las mismas. Es una desventaja; además, muchas pruebas no se pueden realizar sin utilizar herramientas de prueba, como pruebas de rendimiento, pruebas de estrés, etc. Hay muchas herramientas de prueba en el mercado que puede utilizar. Puede elegir algunas herramientas de prueba que le ayuden en sus pruebas según sus propias necesidades. Pero una cosa que debe recordar es que si tiene herramientas de prueba, no necesita pruebas manuales. Las herramientas de prueba no son omnipotentes.

Capacidad para aprender bien

La tecnología de prueba de software también se ha mejorado y mejorado con el tiempo. Como excelente evaluador, debes ser bueno en el uso de libros, sitios web y foros. Nivel de pruebas de software a través de diversos canales como la comunicación.

7

Mejore sus habilidades expresivas

Cuando los evaluadores de software encuentran defectos en el software, a menudo tienen que escribir informes de defectos, y los informes de defectos deben escribirse Ser detallado y claro permite a los desarrolladores localizar y corregir errores lo antes posible, por lo que es muy necesario que un excelente evaluador mejore sus habilidades de escritura.

　8

Comprender el conocimiento empresarial

Es muy importante comprender mejor el conocimiento empresarial que dijo sobre las pruebas de software. Cuanto más comprenda el conocimiento empresarial, mejor. mejor Capaz de encontrar errores de software más profundos, críticos y ocultos. Por lo tanto, como excelente ingeniero de pruebas de software, debe aprender más de expertos y pares en el campo para mejorar su conocimiento comercial.

Lo anterior es solo una experiencia personal. Espero que todos puedan convertirse en excelentes ingenieros de pruebas de software.

Resumen del trabajo del ingeniero de pruebas de software, parte 2

1. Comparta la primera experiencia: la educación representa el pasado, la capacidad representa el presente y la capacidad de aprendizaje representa el futuro. ?En realidad, este es el resultado de una investigación en el campo de la educación extranjera. Creo que amigos que han trabajado durante varios o más de diez años tienen alguna experiencia con este principio. Pero creo que este punto también es muy importante: si comprendes la verdad importante demasiado tarde, te arrepentirás por el resto de tu vida. ¡Ponla en cada artículo para que tus amigos recién graduados puedan verla temprano! /p>

2. Asegúrese de determinar su propia dirección de desarrollo y desarrolle un plan factible para este propósito. No digas nada, "Me acabo de graduar y todavía no sé qué podría hacer en el futuro", "Sólo sigue tus sentimientos y pruébalo primero". Porque tal visión implicará a través de tu subconsciente que tu comportamiento es ocioso y mediocre. ¿Trabaja siempre en tecnología y se convierte en un experto en el futuro? ¿Avanza en la dirección de la gestión y se convierte en un gerente profesional? ¿Primero se familiariza con la industria y el campo y se mantiene independiente en el futuro? y cambiar de carrera para hacer otra cosa en unos años? Esto es muy importante. Determinará lo que harás en los próximos años o diez años, ¿¡qué es lo correcto!?. -

3. En un equipo de desarrollo de software, la tecnología no es omnipotente, pero sin tecnología nada es imposible. En un equipo técnico, la tecnología y el carácter son igualmente importantes y, por supuesto, la apariencia también es más importante, ¡sobre todo! En un equipo con más mm. En un equipo de proyecto de software, el nivel técnico es un peso importante a valorar y respetar. Ya sea que esté realizando gestión, análisis de sistemas, diseño, codificación o gestión de productos, pruebas, documentación, implementación y mantenimiento, debe tener una base técnica. Incluso si soy ignorante, nunca he visto a un profano liderar un equipo de desarrollo de software para completar con éxito un proyecto de desarrollo de software, ni siquiera uno. Una vez vi a una persona altamente educada (no técnica) liderar a un grupo de personas para completar un proyecto. El segundo día después de la entrega del proyecto, los miembros del equipo del proyecto dijeron: "¡No puedo soportarlo más!". destrozados. Sigan caminos separados. Todos pueden imaginar el éxito de ese proyecto. -

4. Desarrolle en detalle su propio plan de aprendizaje de conocimientos profesionales de desarrollo de software y preste atención a las revisiones y ajustes oportunos (la tecnología de desarrollo de software cambia demasiado rápido). Tenga en cuenta: si un desarrollador de software no ha actualizado sus conocimientos en 1 o 2 años, entonces ya no pertenece a esta industria. ?No te digas que no tienes tiempo.

El famoso "Principio 38" del campo de la gestión del tiempo nos advierte: ¡La forma en que uses las otras 8 horas determinará el éxito o el fracaso de tu vida! Desde que me gradué, mi tiempo promedio de estudio por día ha sido de más de 2 horas. -

5. Los libros son la escalera del progreso humano, especialmente para los desarrolladores de software. Los libros son la forma más eficaz de adquirir conocimientos. No espere demasiado encontrarse con "expertos extraordinarios" en el trabajo que se tomarán la molestia de enseñarle. Cuando se trata de gastar dinero para comprar libros, mi experiencia personal es: ¡Nunca compres libros de esas personas en China! ¡Me arrepiento del 100% de los libros que les compré, sin excepción! Lo que es aún más molesto es que estos libros son difíciles de vender en los puestos del mercado de segunda mano. ?Poseer libros no significa poseer conocimientos; poseer conocimientos no significa poseer habilidades no significa poseer cultura no significa poseer sabiduría; ?Sólo cuando conviertes los libros en tu propia sabiduría podrás verdaderamente poseerla. -

6. No te limites al uso superficial de una determinada tecnología, aunque sólo la utilices una o dos veces de forma ocasional. ?Tener cuidado con todo es una cualidad que los ingenieros de cualquier industria no deberían poseer. Desarrolle aplicaciones de Windows, observe los principios de diseño, carga y ejecución de los programas de Windows, analice el formato de archivo pe e intente utilizar el desarrollo SDK para desarrollar una aplicación de Windows desde cero; utilice vc ++, delphi, java, etc. NET, tómese el tiempo para estudiar mfc, vcl, j2ee,. net y su diseño de marco o código fuente; además de usar j2ee, jboss, spring, hibernate y otros excelentes productos o marcos de código abierto, tómese el tiempo para ver cómo los maestros abstraen, analizan, diseñan e implementan soluciones generales a problemas similares. Intente hacer esto y encontrará menos problemas que lo dejen confuso y confuso en su trabajo futuro, porque sabe muchas cosas y ¿por qué? -

7. Programe en un idioma, pero no deja que limite tu pensamiento. "Code Encyclopedia" dice: "Profundiza en la programación en un lenguaje y no superficialmente". El desarrollo profundo de un lenguaje está lejos de ser suficiente. La existencia de cualquier lenguaje de programación tiene sus propias razones, por lo que ningún lenguaje es una "panacea" que pueda curar todas las enfermedades. Existen numerosos ejemplos del impacto y las limitaciones que tienen los lenguajes de programación en las ideas de los desarrolladores y en las formas de resolver problemas específicos. Mi experiencia es: cuando usamos herramientas orientadas a objetos para desarrollar ciertos módulos clave, ¿por qué no podemos aprender de los métodos de empaquetado modular de c, c51 y ensamblador? ¿Utiliza herramientas de desarrollo de escritorio tradicionales (actualmente principalmente vc ++, Delphi) para estructurar? system Al diseñar, ¿por qué no podemos consultar las ideas de diseño de IOC y AOP de la comunidad Java, o incluso aprender de excelentes marcos de código abierto como spring, hibernate, jboss, etc. al diseñar e implementar funciones como real? comunicación en tiempo y recopilación de datos, ¿por qué no podemos citar excelentes marcos y patrones de sistemas de sistemas en tiempo real y sistemas integrados? -

8. Desarrollar el hábito de resumir y reflexionar, y refinar conscientemente los resultados del trabajo diario para formar su propia biblioteca de código fuente personal, una arquitectura general del sistema para resolver ciertos tipos de problemas, e incluso evolucionar hacia un marco. Como todos sabemos, para los desarrolladores de software, una diferencia significativa entre aquellos con y sin experiencia es que las personas sin experiencia comienzan desde cero al completar cualquier tarea, mientras que las personas con experiencia a menudo la resuelven reorganizando sus propios módulos reutilizables y bibliotecas de clases (de hecho. , esta conclusión no debe limitarse al campo del desarrollo de software, sino que puede extenderse a muchos aspectos). Esto no significa que usted mismo deba implementar todas las cosas reutilizables. Los resultados maduros y probados de otros también pueden recopilarse, organizarse e integrarse en su propia base de conocimientos. Sin embargo, es mejor implementarlo usted mismo, para que no haya problemas con los derechos de propiedad intelectual, derechos de autor, etc. La clave es poder dominar verdaderamente este punto de conocimiento y poseer esta habilidad después de implementarlo usted mismo. -

9. Prestar igual atención a la teoría y a la práctica, y cultivar tanto los aspectos internos como los externos. La connotación de un ingeniero es: observar y analizar las cosas y el mundo desde la perspectiva de un ingeniero. Un ingeniero de software calificado es una persona que realmente comprende la esencia de los productos de software y la esencia del desarrollo de productos de software (opiniones personales, bienvenido a discutir).

Dominar los lenguajes de desarrollo de software, aplicar herramientas lingüísticas para resolver problemas específicos en el trabajo y completar tareas específicas son las tareas principales de los ingenieros de software. Sin embargo, desde la perspectiva de los ingenieros de software, estas son solo cosas externas, no trabajos importantes y esenciales. El trabajo de un verdadero ingeniero de software es aprender y dominar el conocimiento teórico del desarrollo de productos de software y las metodologías de desarrollo de software, y comprender y aplicar ideas de análisis, diseño e implementación de productos de software en la práctica para resolver problemas específicos de desarrollo de productos de software. Piense, analice y resuelva problemas desde la perspectiva de teorías maduras y metodologías confiables, verifique y revise estas ideas y métodos en la práctica específica y, en última instancia, forme su propio sistema teórico y metodología práctica.

Resumen del trabajo del ingeniero de pruebas de software, parte 3

Permítanme presentarles primero mis antecedentes: me gradué de una universidad de comunicaciones en 2005 con una licenciatura en informática. Después de graduarme, trabajé para. un gran fabricante de equipos de comunicaciones, que trabaja como ingeniero de pruebas de software.

1. Ejecución del Proyecto T

Me uní al departamento el 13 de julio de 2005 y solo entonces supe que estaba asignado al departamento de pruebas. Después de que el jefe del departamento me llevó, me entregó a mi instructor.

Durante los primeros días después de unirme al departamento, principalmente me familiarizo con el entorno de trabajo de la empresa, conozco a los compañeros del departamento y comprendo el conocimiento del producto. Dado que nos dedicamos a equipos de transmisión, el conocimiento del producto que aprendimos en ese momento se basaba principalmente en los principios SDH, incluida la estructura de trama SDH, protección y conmutación de redes, etc.

La siguiente es una introducción a los proyectos que he realizado.

Nombre del proyecto: T Software

Descripción general del proyecto: este proyecto es un software desarrollado en PC y estaciones de trabajo Sun y pertenece a la estructura CS. El cliente está desarrollado en Java (inicialmente usando JDK1.3 y luego cambiado a JDK1.4) para lograr multiplataforma; el servidor está desarrollado en C ++ y usa ACE para lograr multiplataforma (Windows y Unix).

Inversión en mano de obra: Parece que hay 9 personas en desarrollo y 3 personas en pruebas. (Cuando llegué aquí, era la segunda versión del producto y la inversión humana era aproximadamente la misma)

Unos días después de unirme al departamento, el Proyecto T entró en la fase de prueba. Mi trabajo es ejecutar los casos de prueba que me asignaron. En ese momento, solo sabía hacer clic con el mouse de acuerdo con el contenido descrito en el caso de prueba, y si encontraba un error o excepción en el programa, completaba un ticket de problema. Simplemente hice clic con el mouse en el caso de prueba durante 3 meses sin pensar: )

Ahora que pienso en el trabajo de prueba original, realmente hay demasiadas deficiencias y áreas de mejora.

1www.wjrdkj.com|www.512jjw.com|www.512zx.net|www.ntzlwj.com, casos de prueba. Para las pruebas de software, los casos de prueba son cruciales. Los casos de prueba deben cubrir todas las especificaciones de prueba y los casos de prueba deben ser fáciles de entender y ejecutar. En pocas palabras, son las especificaciones que se describirán. En ese momento, nuestros casos de prueba eran un desastre. Lo peor era que la calidad de los casos de prueba era muy pobre y no había garantía de calidad del producto. Las descripciones de las condiciones preestablecidas, los pasos operativos y los resultados esperados de los casos de prueba también son confusas, y la tabla de Excel utilizada para almacenar los casos de prueba está mal diseñada y tiene una interfaz poco amigable, lo que reduce la eficiencia de las pruebas hasta cierto punto.

2. Conocimiento del producto. Aunque el software T se ejecuta en PC y estaciones de trabajo, el propósito de desarrollar software T es servir productos, por lo que debemos tener conocimiento del producto para poder probar mejor el software T. Sucedió que tres personas, incluido mi mentor, no sabían mucho sobre el producto en ese momento, por lo que no pudimos juzgar si ciertos casos de prueba pasaron la verificación. Esto dio lugar a muchas discusiones con los desarrolladores.

3. El enfoque de las pruebas de software no está claro. Las pruebas de software son una actividad importante en la ingeniería de software. Intenta encontrar defectos en el programa y garantizar la calidad del programa. Pero como producto comercial, el software tiene su límite de tiempo de lanzamiento. El jefe dijo que el software se lanzará en enero, por lo que no puedes probarlo hasta diciembre y luego entregárselo. En ese momento, luchamos demasiado con los desarrolladores sobre algunos problemas menores, pero no se prestó atención a muchos puntos clave. Algunos problemas graves se expusieron relativamente tarde, lo que provocó que el tiempo de prueba se retrasara una y otra vez, y probamos una versión. tras otro. Pensando en esos días, simplemente se puede describir como: "Cansado y doloroso". : (

4. Domina el proceso de prueba.

A mediados de julio, el proyecto T fue transferido del departamento de desarrollo al departamento de pruebas y entró en la etapa de prueba. De hecho, la calidad del producto en ese momento no cumplía con los estándares para las pruebas de transferencia, pero les permitimos pasar la transferencia. pruebas, y los resultados nos trajeron un dolor enorme. Y lo mismo ocurre con las versiones posteriores. Lo probamos ronda tras ronda y estábamos casi desesperados. Pensando en retrospectiva, el software T fue realmente probado por nosotros, no desarrollado ni escrito : )