This site uses cookies own and third. If you continue to browse consider to accept the use of cookies. OK More Info.

Estrategias de Negocios y pruebas de performance en Salesforce con JMeter

  • 1 Replies
  • 390 Views

0 Members and 1 Guest are viewing this topic.

Offline SKS3001

  • *
  • Underc0der
  • Posts: 11
  • Actividad:
    6.67%
  • Reputación 2
    • View Profile
    • Email


Hola, buenas tardes a todos! En este post hablaremos sobre qué es el sandbox en Salesforce y las estrategias de diseño sandbox para implementaciones empresariales. Es inevitable evitar sandboxes en la mayoría de las implementaciones empresariales. A medida que los diferentes equipos trabajan en diferentes procesos como pruebas, desarrollo, prelanzamiento y despliegue final, ¿es esencial tener una estrategia sólida de Sandbox por varias razones?. Desarrollo paralelo (los equipos pueden trabajar simultáneamente, sin detener ninguno de sus procesos), acortar los tiempos de ciclo, reducir los riesgos operativos, aumentar la productividad, la eficiencia y, en última instancia, mejorar la entrega.

¿Qué es Sandbox?
Es un espacio aislado es una copia aislada del entorno de producción de su organización que se utiliza con fines de desarrollo y pruebas. Su entorno de producción tiene sus datos en vivo y usuarios activos que inician sesión. Un espacio aislado siempre incluirá una copia de los metadatos de su organización de producción (objetos, campos, diseños de página, etc.), pero puede o no incluir una copia de los datos de su organización de producción (registros de cuentas, registros de contactos, archivos, etc.).

  • Copia de su organización/producción de Salesforce como un entorno independiente
  • Desarrollo, pruebas y capacitación

Tipos de Sandbox

Hay 4 tipos de entornos sandbox de Salesforce:



Sandbox para desarrolladores
Los sandboxes para desarrolladores son sandboxes de configuración especiales destinados a la codificación y las pruebas por parte de un solo desarrollador. Al igual que los sandboxes developer Pro, los sandboxes developer copian toda la información de la aplicación y la configuración en el sandbox. Los espacios aislados para desarrolladores están limitados a 200 MB de datos de prueba o de muestra, lo que es suficiente para muchas tareas de desarrollo y prueba. Puede actualizar un espacio aislado para desarrolladores una vez al día.

Desarrollador Pro Sandbox
La principal diferencia entre esto y Developer es la cantidad de datos que se pueden almacenar. También toma algunos datos de productos de la producción. Si esas dos cosas son importantes, use esta. Los espacios aislados de Developer Pro copian todos los informes, paneles, libros de precios, productos, aplicaciones y personalizaciones de su organización de producción en Configuración, pero excluyen todos los registros, documentos y archivos adjuntos de objetos estándar y personalizados de su organización. Solo puede incluir hasta 1 GB de datos. Puede actualizar un espacio aislado de Developer Pro una vez al día

Copia parcial
Los espacios aislados de datos parciales incluyen todos los metadatos de su organización y agregan una cantidad seleccionada de datos de su organización de producción que define mediante una plantilla de espacio aislado. Un espacio aislado de datos parciales es un espacio aislado para desarrolladores más los datos que defina en una plantilla de espacio aislado. Incluye los informes, paneles, libros de precios, productos, aplicaciones y personalizaciones en Configuración (incluidos todos los metadatos). Además, según lo definido por la plantilla de espacio aislado, los espacios aislados de datos parciales pueden incluir los registros, documentos y datos adjuntos de objetos estándar y personalizados de su organización de hasta 5 GB de datos y un máximo de 10.000 registros por objeto seleccionado. Un espacio aislado de datos parciales es más pequeño que un espacio aislado completo y tiene un intervalo de actualización más corto. Puede actualizar un espacio aislado de datos parciales cada 5 días.

Sandbox completo
Los espacios aislados completos copian toda la organización de producción y todos sus datos, incluidos los registros de objetos estándar y personalizados, los documentos y los datos adjuntos. Puede actualizar un espacio aislado completo cada 29 días. Las plantillas de espacio aislado le permiten elegir objetos y datos específicos para copiar en su espacio aislado, de modo que pueda controlar el tamaño y el contenido de cada espacio aislado. Las plantillas de espacio aislado solo están disponibles para los espacios aislados de datos parciales o completos.

Sandbox – Características clave
Plantillas de espacio aislado: elija un objeto y datos específicos para copiar en su espacio aislado de copia completa o parcial.
Clonación de sandbox(Todos los metadatos): copiado en un nuevo espacio aislado, mismo tipo de licencia, Preferentemente actualizar un espacio aislado clonado desde su origen.

Asignaciones de sandbox

Cada tipo tiene diferentes características para apoyar las actividades para las que está diseñado.



Casos de uso de Sandbox

Echemos un vistazo cuando deberíamos qué sandbox's utilizar.



Hay dos enfoques principales, el desarrollo impulsado por la organización y el desarrollo impulsado por la fuente, pero están ampliamente alineados cuando se trata de pruebas.

Si está siguiendo un enfoque basado en la fuente, entonces debe completar todas sus pruebas unitarias para un cambio / historia en una organización de Scratch antes de enviar cambios y realizar una solicitud de extracción y confirmación en su repositorio de origen. Puede continuar usando una organización de Scratch para ejecutar todas las pruebas unitarias, o incluso para probar el sistema de varias historias como parte de una validación épica o de sprint.

Del mismo modo, si está siguiendo un modelo de desarrollo impulsado por la organización más tradicional, usará uno o más sandboxes de dev para crear sus cambios y luego los empujará a través de, sugeriría, un sandbox de Dev Pro que tiene un subconjunto de datos de prueba ya aprovisionados. Dependiendo de la cantidad de datos que necesite, es posible que deba usar un espacio aislado más grande para completar las pruebas del sistema. Después de completar las pruebas de su sistema, sus cambios deben estar listos para ser parte de un candidato de lanzamiento, y aquí nuestros enfoques se unen, aunque la forma en que implementamos puede ser diferente.

Independientemente de las herramientas que utilice para implementar, en última instancia, tiene un artefacto de lanzamiento que implementa y en el que desea realizar pruebas de regresión. El entorno de regresión debe ser lo más completo posible, idealmente utilizando un conjunto conectado de sistemas de ensayo para proporcionar un entorno de prueba de extremo a extremo. La regresión puede descubrir problemas con el propio artefacto de lanzamiento en términos de cambios faltantes, cambios no implementados en sistemas auxiliares o cambios que son incompatibles o que rompen la funcionalidad existente. Por lo general, pasaría por más de 1 artefacto de lanzamiento y múltiples iteraciones de prueba antes de estar listo para involucrar a los usuarios finales para UAT.

Para fines de UAT, le recomiendo que use un Sandbox completo, o al menos una copia parcial con datos representativos copiados de Producción, idealmente con datos redactados utilizando Data Mask, por ejemplo.

Después de las correcciones finales (que pasan por las mismas etapas iterativas que las anteriores) y después de haber enviado el artefacto de la versión final al entorno de producción, es posible que también desee probar que los cambios se implementaron correctamente. Esto puede incluir comprobaciones específicas, como la validación de sus nuevos flujos y lightning Flexipages se activan, cosas que a menudo se dejan para publicar los pasos manuales de implementación. Normalmente no queremos realizar acciones sobre datos en vivo que serían destructivos o usar registros de datos reales, por lo que es posible que se utilicen algunos datos de prueba específicos para este propósito que eviten las interacciones salientes con usuarios reales o con sistemas reales.

¿Qué probar?



Qué probar en Salesforce depende de una serie de factores, como el apetito de riesgo de su empresa, el cumplimiento normativo, la calidad de las soluciones que se entregan en las pruebas y, sobre todo, las fases de prueba que destaqué anteriormente. El valor que obtiene de las pruebas, y el valor que obtiene de automatizar algunas de esas pruebas, se puede medir fácilmente.

He dividido lo siguiente en una tabla para indicar una prioridad sugerida de cada categoría de cambio que puede ocurrir en comparación con los métodos de prueba anteriores para resumir mis recomendaciones. He agrupado los cambios en los que se aplica el mismo conjunto de recomendaciones.



¿Qué NO probar?

Tan importante como saber qué probar, me gustaría llamar a algunos elementos para los que no debería crear pruebas en mi opinión. Ahora vemos que los clientes agregan pruebas para estos artículos, y para los clientes en industrias reguladas esto es obligatorio, pero en la mayoría de los casos ha comprado una suscripción para una aplicación que ya está probada y no necesita probar lo siguiente:

  • Navegación entre pestañas y subpestañas de la consola, a menos que desee afirmar que los objetos relacionados se implementan como subpestañas o pestañas principales
  • Lista relacionada con Salesforce Ver todos los enlaces
  • Cambiar entre aplicaciones y pestañas a través del iniciador de aplicaciones. Herramientas como Provar hacen que esta aplicación cambie por usted, probándola como una entrega de interfaz de usuario ya está realizada por Salesforce.
  • Filtrado y ordenación de vistas de lista, de nuevo a menos que esté usando esto para un escenario de prueba específico.
  • Barra de utilidades de elementos recientes, historial, notas, etc., simplemente apéguese a cualquier acción rápida que cree.
  • Interacción de mensajeria: a menos que tenga una personalización específica para publicar, dar me gusta o comentar una publicación.
Esta lista está lejos de ser exhaustiva, pero espero que te hagas a la idea. Enfoca tus esfuerzos primero en las áreas que estás personalizando. No tiene ningún valor probar que una organización de Salesforce, ya que Salesforce ya ha invertido millones en eso.

Flujo de implementación

Estrategia de entorno estándar que se utiliza en los flujos de implementación.



¿Cómo probar?

La siguiente tabla son las formas y herramientas sugeridas para probar en diferentes fases del ciclo de vida:



En caso de hacer pruebas de performance existen las siguientes recomendaciones:

  • Nunca realice pruebas de carga de ningún servicio o función de Salesforce.com sin el consentimiento formal del soporte de Salesforce. Pueden revocar su acceso y / o cobrarle tarifas de servicio por el aumento del uso.
  • Envíe un caso si desea realizar pruebas de carga para probar la velocidad de su aplicación utilizando una herramienta automatizada. Lea las preguntas frecuentes sobre las pruebas de rendimiento de Salesforce antes de comenzar. You are not allowed to view links. Register or Login
  • Si tiene problemas de rendimiento, intente ejecutar una prueba de simulación de ancho de banda en sus firewalls, enrutadores y otra infraestructura corporativa para asegurarse de que pueda manejar la carga.

Bien!, Comencemos con las Pruebas de Performance a traves de JMeter, dejo en recomendación la instalación y conceptos teoricos a tráves de post de Antrax:
You are not allowed to view links. Register or Login

En caso de utilizar el modo oscuro se recomienda usar el versionado 5.5-SNAPSHOT de la siguiente url:
You are not allowed to view links. Register or Login

Procedamos una vez ya terminadas las configuraciones, seguir los siguientes pasos:

Creación del plan de prueba:

En este plan de prueba, vamos a ejecutar la prueba de rendimiento para la página de inicio de sesión y la página de inicio de salesforce. Para eso, abriremos el archivo por lotes JMeter desde la carpeta bin respetada y crearemos el Plan de prueba para las páginas de inicio de sesión y inicio de Salesforce.

Paso 1: Vaya a Jmeter Test Plan y haga clic con el botón derecho y Agregar grupo de subprocesos mediante Agregar > subprocesos (usuarios) >Proceso de subprocesos. E introduzca los valores en los campos siguientes.
Los campos son Número de subprocesos (usuarios), Período de aceleración (Segundos) y Recuento de bucles.

You are not allowed to view links. Register or Login

Paso 2: Aquí definimos las variables como URL, Nombre de usuario, Contraseña.. etc. Agregar variable definida por el usuario mediante Agregar > elemento de configuración > variables definidas por el usuario.



Paso 3: En este paso, agregaremos los valores predeterminados de solicitud HTTP para evitar la duplicación de datos en las pruebas y hacer que los scripts de prueba sean más (fácilmente) mantenibles. Agregar valores predeterminados de solicitud HTTP mediante Agregar > elemento de configuración > valores predeterminados de solicitud HTTP.



Paso 4: En la solicitud HTTP, ingresamos el nombre del servidor, Method(GET, POST, DELETE..),Path value.. etc para enviar solicitudes al servidor y también recuperar la respuesta del servidor. Aquí obtenemos la URL de Salesforce como You are not allowed to view links. Register or Login utilizando el método GET. Agregar solicitud HTTP mediante Agregar > muestreador > solicitud HTTP.



Paso 5: Aquí estamos dando los valores de entrada como nombre de usuario y contraseña en la página de inicio de sesión utilizando el método POST. Y también obtener el token OAuth y dar la autorización para iniciar sesión en la aplicación Salesforce.



Ejecución y Resultados

Después de ejecutar el Jmeter haciendo clic en el botón verde de la barra de herramientas, obtendremos los siguientes resultados. Al ver estos informes, si obtenemos el código de respuesta:200 y el mensaje de respuesta: OK, entonces nos aseguramos de que la prueba se supere, de lo contrario, la prueba falla. 1.
Ver resultados en árbol:



Ver resultados en el gráfico



Ver resultados en la tabla



Esto es todo por ahora! Pueden probar y comentar como les va con sus tests automatizados de performance en Salesforce.
Espero que el post sea de ayuda!

Online ANTRAX

  • *
  • Administrator
  • Posts: 5801
  • Actividad:
    100%
  • Country: ar
  • Reputación 42
  • ANTRAX
  • Twitter: @Underc0de
    • View Profile
    • Underc0de
    • Email
Uffff tremendo aporte! Mil gracias!! Me sirve muchismo