La diferencia entre probar software de código abierto y software tradicional
Las personas en la industria de Internet, intencionalmente o no, se refieren al software que no es de Internet como software tradicional, lo que significa que todos somos transferidos de las industrias tradicionales, bueno, de las industrias de software tradicionales. Tal vez a los ojos de algunas personas, esto tenga algunos elementos pretenciosos, pero, por supuesto, más personas quieren distinguirlo. Al igual que nosotros, los informáticos, nos referimos a otras industrias más importantes como industrias tradicionales, parece tener un cierto sentido de superioridad. Aquí no hay debate sobre estos títulos, ya que tienen poca importancia. Dejemos que el mercado decida si tienen valor. Si describe algo como misterioso, existen dos posibilidades principales: no lo comprende o está fingiendo ser sofisticado. Ninguno de los dos es muy bueno, así que será mejor ver cuál es la diferencia.
Si realmente queremos utilizar el término industria de software tradicional, entonces esto se refiere al tipo de software que requiere que los usuarios instalen el cliente, o que requiere que el administrador del cliente lo implemente en la sala de computadoras y lo coloque. en un CD, o se coloca en el hardware y se vende en conjunto, o es un sistema hecho a medida para un determinado cliente.
El cambio y la inmutabilidad son siempre temas eternos. Permítanme hablar primero sobre las diferencias que vi. La diferencia entre la industria de Internet y el software tradicional:
1. La mayor diferencia es que muchos productos de Internet se implementan y operan por sí mismos, y los usuarios solo necesitan usar un cliente ligero para usarlos.
El cliente ligero aquí es un navegador, una aplicación o un cliente que debe instalarse, pero los datos centrales y la lógica empresarial se encuentran principalmente en la sala de computadoras de la empresa de Internet, en el IDC y en la nube. La principal diferencia entre este y los sistemas empresariales de arquitectura C/S y B/S anteriores radica en la variedad de personas a las que sirve y que operarán y mantendrán dicho sistema. Naturalmente, hay mucho más trabajo en esta área.
Reducir el alcance a las pruebas requiere considerar el entorno de producción. Por ejemplo, existen los siguientes aspectos:
a. Cómo monitorear la disponibilidad de las funciones del entorno de producción.
Esto debe hacerse junto con la operación y el mantenimiento, pero la operación y el mantenimiento están dirigidos a partes más generales, como el uso de recursos de la máquina, el tráfico y el ancho de banda, pero se centra más en la Nivel de negocio del producto, como qué funciones y si está disponible puede requerir que los evaluadores de negocios diseñen y desarrollen sistemas automatizados para el monitoreo.
b. Cómo lanzar la función al entorno operativo formal (entorno de producción)
Por lo general, se lanza directamente después de la prueba, por lo que no tiene un ciclo de prueba tan largo como el tradicional. software, incluida la beta interna, la beta externa y otros procesos, y lo que sé es que muchos productos de Internet basados en él tienen múltiples lanzamientos al día en promedio
que pueden ser grandes o pequeños. Por lo tanto, la publicación puede convertirse en trabajo de los evaluadores, por supuesto con el apoyo de los sistemas relevantes. Otro tema que debe considerarse aquí es la publicación común en escala de grises según diversas condiciones, deje que algunos usuarios la usen primero.
Una vez completado el lanzamiento, es necesario verificar el entorno de producción.
c.Cómo garantizar o verificar que el entorno de prueba y el entorno de producción estén sincronizados
Una vez que Internet esté en este modo, el problema del entorno de prueba se volverá más prominente. porque a menudo hay muchos sistemas involucrados y algunas interfaces con sistemas externos pueden ser difíciles de construir usted mismo o usar simulaciones. Por otro lado, si se asegura de que el entorno de prueba sea bueno, también lo será en el entorno de producción. Se necesitan mecanismos y herramientas correspondientes para la verificación y sincronización.
Limítate al aspecto de desarrollo. Se deben tener en cuenta algunas características de Internet, como los siguientes aspectos:
a Cómo localizar rápidamente el problema, en qué módulo radica el problema o qué módulos hay que diseñar y dar soluciones.
En términos generales, para funciones o módulos recién agregados, es más fácil hacer planes, diseñar, desarrollar y probar software como un proyecto tradicional. Sin embargo, si el problema ocurre en el entorno de producción, debe estar muy familiarizado con la arquitectura comercial y de software original y poder ubicar rápidamente la página donde se encuentra el problema y las páginas involucradas. Desde la perspectiva de un ingeniero de Internet que ha abandonado el software tradicional, los programas web son en realidad una colección de software.
Cada página web es un subprograma independiente. Son muy independientes y simplemente saltan a través de un enlace, o un grupo de páginas forman una colección de programas para implementar una función específica. Después de todo, existen varios archivos DLL de forma independiente. Por lo tanto, desde la perspectiva de un ingeniero de software tradicional, un programa web debe gestionarse utilizando el concepto de una colección de programas de gestión. ¿Cómo hacerlo específicamente? En primer lugar, el personal técnico responsable del desarrollo se divide en tres categorías. Una categoría son los codificadores senior, preferiblemente desarrolladores de módulos originales. Tienen un muy buen conocimiento de los requisitos del módulo y de la arquitectura de diseño e implementación, pero solo realizan análisis de requisitos basándose en los comentarios de CR. Proteger algunas opiniones de modificación irrazonables, realizar análisis de posicionamiento sobre las necesidades de modificación, diseñar el método de modificación y determinar el alcance de la modificación. La segunda categoría es el codificador intermedio. El codificador intermedio solo se comunica con el codificador senior, implementa las ideas del codificador senior y realiza sus ideas de diseño. La tercera categoría son los codificadores junior, que son responsables de comunicar las necesidades con los codificadores senior y comprender el alcance del juicio y la modificación. Las modificaciones realizadas por codificadores intermedios están sujetas a una autoprueba del desarrollador, se completan los documentos relevantes y son revisadas por codificadores superiores.
b Cómo juzgar si la función desarrollada está bien.
En la revisión de codificadores de alto nivel, los documentos del codificador de tercera categoría se utilizan para confirmar si la implementación del codificador se ajusta al diseño original. Por supuesto, al diseñar, es mejor comunicarse con ellos. el codificador de segunda categoría de antemano. Con la comprensión tácita continua del equipo, los codificadores junior pueden dominar rápidamente la lógica empresarial y los métodos de autoprueba y, al mismo tiempo, familiarizarse con las herramientas utilizadas por los desarrolladores. Continúe creciendo y conviértase en un codificador intermedio. Los colegas, codificadores intermedios, continuarán creciendo mientras implementan diseños constantemente y se volverán competentes en el análisis de requisitos y el diseño de software, y se convertirán en codificadores senior. De esta manera, todo el pequeño equipo se volverá muy poderoso. Este método es similar al Yuanyang. Formación del famoso general antijaponés Qi Jiguang, que se especializa en lidiar con piratas japoneses que son relativamente fuertes individualmente y tienen altas habilidades en artes marciales.
c Cómo garantizar la estabilidad del programa web en el entorno de producción
Reducir el número de lanzamientos es la medida más eficaz para garantizar la estabilidad del programa web, pero si Es un problema urgente, se puede liberar el mismo día. Por ejemplo, brindamos soporte técnico a los Estados Unidos. El mediodía se puede utilizar como fecha límite para la prueba. Si la prueba se aprueba a las 2 del mediodía, se lanzará a las 5 en punto del mismo día después de salir del trabajo. Si la prueba no pasa a las 2 horas, se pospondrá para el día siguiente.
2. El ritmo de los productos de Internet es muy rápido
A diferencia de los productos de software de cliente o servidor tradicionales, el ciclo puede ser de medio año, un año o incluso más. De esta manera, hay tiempo más que suficiente para planificar el proyecto, revisar los requisitos y luego delinear/diseñar en detalle, y luego probar los casos de prueba del diseño, y luego tener diferentes ciclos de prueba. tiempo para preparar el entorno de prueba y las pruebas automatizadas.
En la actualidad, no es realista hacer esto con los productos de Internet. Este también es un gran desafío para los evaluadores. Es posible que vean requisitos que se probarán en unos días. Los casos de uso se desarrollan temporalmente y no hay mucho tiempo para automatizarlos y hacer el diseño de pruebas. luego pruébelo durante dos días. La función ahora está en línea. Es difícil apreciar la diferencia que aporta esta velocidad sin experiencia personal. Entonces, ¿cómo garantizar la cobertura y la calidad de las pruebas en un período de tiempo tan corto y cómo reducir las omisiones? Este es un problema práctico o un requisito. Hay algunas medidas, pero en realidad no hay una buena respuesta.
3. Más personas participan en las pruebas
En las empresas de Internet, la relación entre pruebas y desarrollo es muy baja, 1:6 y 1:7 son muy comunes, o incluso superiores. . Con tal proporción, si se quiere garantizar la calidad, ¿debe haber más métodos? Por ejemplo
a.
Las pruebas suelen llevar más tiempo porque la calidad del código no es lo suficientemente buena. Hay muchas, muchas discusiones y muchas ocasiones en las que se extrae el código. Por tanto, mejorar la calidad del código enviado por desarrollo es un aspecto muy importante. Algunas empresas garantizan esto mediante pruebas unitarias obligatorias por parte de los desarrolladores, y otras lo garantizan mediante autopruebas a nivel funcional.
Estos se pueden reflejar con la ayuda de algunos datos, como la cantidad de veces que se extrae la misma versión o la tasa de aprobación de casos de prueba, etc.
b. Experiencia del producto o del operador.
Muchos productos de Internet no son como los productos de software tradicionales en el sentido de que no tienen un gerente de producto que cumpla con todos los requisitos. Los gerentes de producto, o gerentes de producto, son un equipo, cada uno de los cuales es responsable de una pieza del rompecabezas para generar los requisitos. Además, muchas demandas pueden provenir del equipo de operación, relacionadas con el negocio o para conectar diferentes sistemas. Cada gerente de producto u operación debe ir al entorno de experiencia para probar el producto después de que los desarrolladores hayan implementado las funciones correspondientes, que es la llamada experiencia, para ver si estas funciones son lo que quieren. De esta manera, se puede garantizar que no haya problemas obvios en la comprensión de los requisitos antes de que el evaluador pruebe y evitar perder tiempo y mano de obra en las pruebas.
c.
Entran diferentes roles para ver si hay algún problema con un trabajo que ha sido probado, así como problemas a los que se debe prestar atención al publicar, problemas ambientales, problemas de configuración, problemas de datos, etc. . Algunas de las prácticas anteriores pueden ser útiles, pero cómo promoverlas y cómo probarlas requieren el apoyo de procesos y herramientas.
4. Algunos están exentos de pruebas.
No es necesario probar todo lo que se lanza al entorno de producción y algunos cambios no requieren pruebas. No existe un estándar determinado para esto y depende de factores como la situación de lanzamiento específica y la madurez del producto y el equipo. Por ejemplo, algunas páginas temporalmente activas, algunos pequeños cambios de imagen o estilo, algunas pequeñas reparaciones, etc. Simplemente vaya a la red externa para verificarlo después de publicarlo.
¿Qué se puede eximir de las pruebas? En realidad, este es un tema muy complejo. Por supuesto, existen riesgos, pero la mejora en la eficiencia que esto conlleva también es obvia.
5. Desafíos planteados por una gran cantidad de usuarios
De hecho, hay muchos, aquí hay algunos:
Cómo asegurar o verificar. rendimiento
Las pruebas de rendimiento del software tradicional son relativamente simples. Es más fácil crear un entorno y simular el tráfico. Un producto de Internet puede tener cientos, miles o incluso más servidores, implementados en múltiples ubicaciones y en múltiples niveles. Afectado por diversos factores, como publicidad y promociones, el tráfico puede alcanzar repentinamente un nivel alto. Por lo tanto, el enfoque a este respecto será diferente. La simulación completa no es realista y, como se mencionó anteriormente, el lanzamiento es muy rápido y no hay mucho tiempo para realizar pruebas de rendimiento repetidamente. Entonces, cómo realizar pruebas de rendimiento relativamente ligeras también es un tema importante.
b.Compatibilidad del navegador.
Puede haber muchos tipos de navegadores utilizados por los usuarios, incluido el IE6 que todos critican, así como n modos de IE9, Chrome y Firefox cuyas actualizaciones de versión son tan rápidas como cohetes, y muchos navegadores domésticos. . Es un gran desafío cubrirlos uno por uno. En realidad, es imposible, pero el equipo de producto definitivamente espera que las pruebas puedan cubrir más. Algunos productos de nivel empresarial pueden afirmar que solo admiten unos pocos tipos, pero es difícil hacerlo para los productos de Internet, lo que significa renunciar a algunos usuarios. ¿Cómo diseñar una estrategia? ¿Existen medios técnicos?
c. Las cosas mejoradas no tienen restricciones de entrada y pueden operarse a voluntad.
Un problema provocado por un pequeño cambio puede afectar a infinidad de usuarios, y muchas veces se descubrirá inmediatamente, lo que no deja de ser muy estresante. Todo el proceso de reparación también es una operación en vivo. No hay tanto ambiente ni tiempo para adaptarse lentamente internamente. ¿Cómo garantizar la calidad de la reparación?
6. Productos de Internet Una ventaja o característica en comparación con los productos tradicionales es que los problemas se pueden solucionar rápidamente, porque los usuarios pueden verse afectados rápidamente sin tener que esperar a que apliquen revisiones o parches uno por uno, o incluso instalen nuevas versiones. En muchos casos, el tiempo desde que ocurre hasta que se repara este tipo de problema es tan corto que la mayoría de los usuarios no se dan cuenta. A veces esto se convertirá en una excusa para actuar rápido y sucio, pero generalmente los problemas con el entorno de producción se incluirán como un indicador de evaluación.
Y algunos problemas no son menores y pueden constituir accidentes. De hecho, para este tipo de productos, los evaluadores están bajo una mayor presión para faltar a las pruebas.
7. Diferencias en la selección de herramientas y tecnologías de prueba
Probablemente debido a algunas características de los propios productos de Internet, las principales empresas están utilizando una gran cantidad de plataformas de código abierto y desarrolladas internamente. y sistema. En consecuencia, las plataformas y herramientas utilizadas en las pruebas se dividen principalmente en estas dos categorías, ya sean herramientas de código abierto (que también pueden sufrir algunas modificaciones) o herramientas desarrolladas internamente. En comparación, la industria del software tradicional comprará algunas herramientas de prueba comerciales, como herramientas para pruebas de rendimiento, cobertura o inspección de código, así como plataformas de gestión de defectos y casos de prueba.
Por lo que he aprendido hasta ahora, las principales empresas nacionales de Internet han realizado muchas transformaciones y autoinvestigaciones, por lo que incluir experiencia en el uso de un montón de herramientas importantes en su currículum puede no ser necesariamente de gran ayuda. ventaja. A los recién llegados les lleva mucho tiempo aprender y familiarizarse con estas plataformas.
Lo anterior enumera algunas diferencias en comparación con la industria del software tradicional, pero para los evaluadores, las similitudes entre la industria de Internet y el software tradicional son:
1. Mismas necesidades Conocer el producto y el negocio. muy bien
Para los evaluadores, si no comprenden el producto y el negocio, será difícil realizar el trabajo de prueba, porque incluso el bien y el mal más básico (ya sea un error) es difícil para juzgar, excepto, por supuesto, algunos errores obvios, como los mensajes de error js, pueden descubrirse durante la experiencia del producto o hasta que sean descubiertos por los usuarios. Por lo tanto, todavía necesitamos dedicar mucho tiempo y energía para familiarizarnos con el negocio del producto. Desde esta perspectiva, no hay un gran cambio, es simplemente un cambio a un campo diferente. Esta diferencia se debe a diferentes productos, no a diferencias en el software tradicional o Internet.
2. La misma necesidad de comprender la tecnología del producto.
Esto es en realidad algo similar a lo anterior. Los evaluadores necesitan comprender la tecnología utilizada en el desarrollo del producto. importante para pruebas en profundidad La aplicación de muchas tecnologías y herramientas de prueba es de gran relevancia, como análisis de rendimiento, descubrimiento de pérdidas de memoria, análisis de cobertura, etc. Sin aprenderlos y comprenderlos, no se puede realizar mucho trabajo. No hay cambio de dirección. Tenemos que aprender y practicar estas cosas para comprenderlas mejor. Pero las tecnologías específicas pueden ser diferentes. Por ejemplo, los productos web de Internet pueden utilizar comúnmente JS, PHP, Java, C y otros lenguajes, así como varios servidores web, cachés, servidores proxy, etc.
3. Tecnología de prueba específica
Las tecnologías de desarrollo de productos mencionadas anteriormente, de hecho, existe otra tecnología de prueba, que de hecho es diferente del software tradicional. en detalle. El desarrollo tiene muchas similitudes o incluso similitudes. Por ejemplo, si desea realizar un escaneo de código estático, métodos y herramientas de prueba de rendimiento local, herramientas de cobertura, algunas herramientas y marcos automatizados, algunas herramientas de monitoreo, etc.
Desde esta perspectiva, la diferencia en tecnología no es muy grande. Por supuesto, Internet tiene algunas características especiales, por ejemplo, muchos sistemas basados en web, distribuidos y multicapa presentarán algunos requisitos. para herramientas Esta diferencia en realidad no es muy grande, porque lo mismo ocurre con muchos software de servidor tradicionales.
4. Método de diseño de prueba
Como se mencionó anteriormente, debido a la diferencia en el ritmo de lanzamiento del producto, todo el proceso debe ser más liviano y rápido, pero al probar una función específica, surgen los problemas. que deben considerarse en el diseño y ejecución de casos de uso en realidad no son muy diferentes de los tradicionales. Debido a que el problema que todos enfrentan en este momento es el mismo: cómo probar esta función de este software. Por tanto, todavía se pueden utilizar algunas ideas y métodos.
Con base en lo anterior, las diferencias locales son relativamente pequeñas, pero las diferencias cuando se trata de formas y procesos a gran escala serán relativamente grandes.
También puede ser por esta razón que muchas personas que pasaron del software tradicional a Internet pudieron integrarse rápidamente y comenzar a desempeñar un papel hace unos años, la mayoría de las personas en las principales. Las empresas de Internet ahora provienen todas de las llamadas empresas de software tradicionales.
Creo que la velocidad de desarrollo y las oportunidades en diferentes campos son diferentes. Esta es una de las razones por las que muchas personas se han unido a la industria de Internet en los últimos años. Esto es como la llamada asignación de recursos del mercado. En economía, la fuerza motriz es la misma, lo cual es normal. Pero, por otro lado, la gente tendrá la ilusión de que se volverá más fuerte inmediatamente si se cambia a una industria en rápido desarrollo. De hecho, desde un punto de vista tranquilo, no es así. Es solo una ola que debe lograrse con tal mejora. porque de más Se obtiene gradualmente a través del estudio, la práctica y el pensamiento, así como de la comunicación con los demás.
Los productos de Internet se mencionaron anteriormente. De hecho, a veces esta es una propuesta falsa, porque todas las principales empresas de Internet tienen software tradicional. Por ejemplo, Tencent, Baidu y Alibaba tienen productos para clientes, y hay bastantes. muchos de ellos también tienen arquitectura C/S. En el extranjero, Google también tiene productos de escritorio como Chrome y Picasa, y Facebook también tiene un cliente de mensajería instantánea. Por lo tanto, en gran medida, todavía existe una gran necesidad de tecnologías de desarrollo y prueba, como productos GUI, y métodos y capacidades de servidor similares a los productos de nivel empresarial. Por supuesto, estos productos están conectados a Internet, por lo que existen diferencias, pero no son tan grandes como se imagina.
Otra pregunta, a veces la gente usa el nombre de un software de Internet para escapar de algunas cosas, como alguna imprecisión o confusión. Todo se reduce a las características de Internet. Este es un "grado" que tienes. para distinguirlo usted mismo.
Otra pregunta, ¿qué consejo le darías a las personas que son nuevas en las pruebas en Internet? Los siguientes también son de autoestímulo.
1. Enfrentar los cambios provocados por esta diferencia. Algunas de las cosas mencionadas anteriormente son realmente muy diferentes, por lo que debemos aprenderlas y comprenderlas activamente.
2. Trabaje duro para aprender conocimientos relacionados con el producto, incluidas las tecnologías de desarrollo relacionadas, para que pueda realizar mejor su trabajo.
3. Reflexiona siempre sobre el hecho de que has estudiado algo muy claramente en un entorno antes, pero después de cambiar el entorno, es posible que la experiencia y el conocimiento antiguos no sean completamente aplicables. Así que hablemos menos sobre cómo éramos en el pasado. Nunca lo aplicaremos mecánicamente, pero después de comprender la situación y el problema, veremos qué prácticas pueden usarse como referencia parcial y pueden ser más confiables.