{"id":4663,"date":"2019-12-10T16:01:11","date_gmt":"2019-12-10T19:01:11","guid":{"rendered":"http:\/\/cl.abstracta.us\/blog\/?p=4663"},"modified":"2024-02-15T17:37:22","modified_gmt":"2024-02-15T20:37:22","slug":"mejor-momento-comenzar-pruebas-performance","status":"publish","type":"post","link":"https:\/\/es.abstracta.us\/blog\/mejor-momento-comenzar-pruebas-performance\/","title":{"rendered":"Testing de performance: \u00bfcon qu\u00e9 tipo de enfoque comenzar?"},"content":{"rendered":"\n

\u00bfHay que probar el rendimiento durante todo el desarrollo o al final del proyecto? \u00bfQu\u00e9 enfoque es recomendable elegir? \u00bf\u00c1gil o en cascada?<\/strong><\/h3>\n\n\n
\n
\"\u00bfCu\u00e1ndo
Imagen tomada de Pixabay<\/em><\/figcaption><\/figure><\/div>\n\n\n

Cuando se tiene en cuenta la performance de los sistemas existentes o los creados desde cero, los equipos deben determinar en qu\u00e9 punto del proceso de desarrollo se beneficiar\u00e1n m\u00e1s de la ejecuci\u00f3n de las pruebas de performance.<\/p>\n\n\n\n

Habl\u00e9 sobre este tema en un par de conferencias, incluida la CMG imPACt Conference en La Jolla junto a Sof\u00eda Palamarchuk, y pens\u00e9 \u00bfpor qu\u00e9 no resumir la charla en un post publicaci\u00f3n? Entonces, el prop\u00f3sito de este post es responder a la pregunta:<\/p>\n\n\n\n

\u00bfDeber\u00edamos comenzar las pruebas de performance al inicio, junto con el desarrollo (adoptando el enfoque \u00e1gil), o al final (adoptando el enfoque en cascada)?<\/p>\n\n\n\n

Pruebas de Performance: Concepto y generalidades<\/strong><\/h2>\n\n\n\n

La performance de un computador se caracteriza por la cantidad de trabajo \u00fatil realizado por un sistema inform\u00e1tico en comparaci\u00f3n con el tiempo empleado y los recursos utilizados. Recuerda, la performance no solo se refiere a la velocidad. Por ejemplo, un sistema que es muy r\u00e1pido y usa el 100% de la CPU no funciona. Por tanto, es importante que comprobemos tanto la experiencia del usuario (el tiempo de respuesta percibido, o la velocidad) como el nivel de estr\u00e9s de los servidores.<\/p>\n\n\n\n

Adem\u00e1s, si solamente prestamos atenci\u00f3n a los tiempos de respuesta, solo podr\u00edamos ver indicios cuando lo que realmente queremos encontrar son las causas subyacentes para identificar esos cuellos de botella y las formas en las que podr\u00edamos mejorar.<\/p>\n\n\n\n

Entonces, volviendo a la pregunta en cuesti\u00f3n: \u00bfDeber\u00edamos adoptar el enfoque de cascada o el enfoque \u00e1gil, para las pruebas de performance?<\/strong><\/p>\n\n\n\n

Ahora, vale aclarar lo que queremos decir con ambos enfoques dos. El enfoque \u00e1gil es cuando comenzamos las pruebas de performance al inicio del proceso de desarrollo y continuamos con este enfoque durante toda la evoluci\u00f3n de la aplicaci\u00f3n<\/strong>.<\/p>\n\n\n\n

Mientras que, el enfoque en cascada es cuando dejamos todas las actividades de pruebas de performance para el final del desarrollo, tales como las pruebas de aceptaci\u00f3n<\/strong>, verificando que el sistema funciona seg\u00fan sea necesario.<\/p>\n\n\n\n

Demos un vistazo a lo que implican y luego a las ventajas y desventajas del enfoque \u00e1gil y de cascada.<\/p>\n\n\n\n

Enfoque en Cascada<\/strong><\/h2>\n\n\n
\n
\"Enfoque
Imagen de pasja1000 en Pixabay<\/em> <\/figcaption><\/figure><\/div>\n\n\n

En el enfoque en cascada para las pruebas de performance<\/strong> generalmente esperamos hasta el final del desarrollo para comenzar a probar. Los tests de rendimiento toman la forma de pruebas de aceptaci\u00f3n<\/strong> y, si se cumplen los criterios, el sistema est\u00e1 listo para entrar en producci\u00f3n. Esto implica simular el escenario de carga esperado.<\/p>\n\n\n\n

Pros<\/h3>\n\n\n\n