Commit 6ec3782e authored by Cecilia Alvarado's avatar Cecilia Alvarado

Ajustes de forma. (Ortografía)

parent d0ca33e2
This diff is collapsed.
......@@ -46,14 +46,14 @@ En todos los casos es necesario que se coordine con un miembro del equipo de des
Como se explicó anteriormente, dependiendo de los requerimientos del grupo de desarrollo, podrían adicionarse los siguientes documentos:
* Diagrama de Casos de uso
* Diagrama de secuencia
* Modelo de procesos del Negocio
* Diagrama de Componentes
* Diagrama de Despliegue
* Diagrama de Estados
* Diagrama de Actividad
* Diagrama de Colaboración
* Diagrama de Casos de uso.
* Diagrama de secuencia.
* Modelo de procesos del Negocio.
* Diagrama de Componentes.
* Diagrama de Despliegue.
* Diagrama de Estados.
* Diagrama de Actividad.
* Diagrama de Colaboración.
Toda esta documentación deberá estar detallada lo más claramente posible y en la carpeta docs del proyecto.
......
......@@ -6,7 +6,6 @@ Establecer pautas relativas al proceso de Aseguramiento de la Calidad
del software, (Software Quality Assurance, SQA).
## II. Alcance
El presente documento comprende los procesos y tareas a llevar a cabo
......@@ -33,8 +32,8 @@ y bajo ningún concepto debe perderse de vista esta premisa.
La tarea fundamental de SQA es exigir que se cumplan todas las normas y
estándares establecidos para asegurar el buen fin del proyecto.
El equipo que realiza SQA debe ser independiente del equipo de
desarrollo.
** El equipo que realiza SQA debe ser independiente del equipo de
desarrollo. **
......@@ -53,19 +52,19 @@ tareas, asociadas con las actividades principales:
>a) SQA deberá definir los estándares y políticas a cumplirse en las
diferentes etapas y procesos, tales como:
* Metodologías de desarrollo de software
* Metodologías de desarrollo de software.
* Gestión de proyectos
* Gestión de proyectos.
* Gestión de la configuración
* Gestión de la configuración.
* Desarrollo de Requisitos / Gestión
* Desarrollo de Requisitos / Gestión.
* Estimación
* Estimación.
* Diseño de software
* Diseño de software.
* Pruebas
* Pruebas.
* Etc.
......@@ -73,7 +72,7 @@ diferentes etapas y procesos, tales como:
proceso de forma correcta.
>c) SQA debe garantizar el cumplimiento de los estándares formales
definidos en la unidad de investigación innovación y desarrollo de la
definidos en la Unidad de Investigación, Innovación y Desarrollo de la
AGETIC.
>d) SQA debe asegurar que el control de cambios se realice correctamente.
......@@ -128,7 +127,9 @@ continuación:
>c) Inspecciones de análisis y diseño.
>d) Inspecciones de código.
>>- Ejecución de Test unitario.
>>- Ejecución de Test de integración.
>e) Briefings de prevención.
......@@ -203,7 +204,7 @@ con los estándares definidos. Se revisará que no haya incongruencias.
>a) Verificación del modelo de análisis
>a) Verificación del Modelo de Análisis
Se verifica que los productos del análisis sean correctos y que tanto
ellos como la documentación producida cumplan con los estándares
......@@ -224,7 +225,6 @@ relaciones y operaciones definidas, verificar que se cumple con el
objetivo especificado y analizar la presentación.
En este punto existen tareas realizadas por un SQA en el rol de SQC
(Software Quality Control), mismas que serán detalladas en otra sección
de este documento.
......@@ -255,7 +255,6 @@ dentro. Cada grupo deberá adaptar este plan a sus necesidades. Habrá que
tener en cuenta que el Plan Genérico de SQA especifica todos los
requerimientos mínimos de SQA.
SQA deberá tener presente al elaborar el plan de SQA, los objetivos de
calidad tanto de la AGETIC como de su proyecto. Deberá interactuar con
el Administrador del proyecto y acordar la inserción de las actividades
......@@ -275,7 +274,6 @@ producto desarrollado, así como del grado de efectividad del proceso.
### B. Control de Calidad del Software (Software Quality Control)
El responsable de Software Quality Control, SQC, no es más que una
faceta o rol de un SQA que debe cumplir en ciertas etapas.
......@@ -372,8 +370,7 @@ firmen.
##### 3.2 Implementar el Plan de Control de calidad realizado,
Se deberá implementar el Plan de Control de calidad realizado, teniendo como producto
de ésta tarea un documento denominado “Reporte de Test”.
Se deberá implementar el Plan de Control de calidad realizado, teniendo como producto de esta tarea, un documento denominado “Reporte de Test”.
-------
......
......@@ -19,9 +19,9 @@ En el siguiente gráfico se describe el flujo de la integración y entrega conti
![alt tag](imagen/ci_cd_flujo.png)
1.- La integración continua inicia cuando el equipo de desarrollo realiza 'Push events/Merge Request events' al repositorio de versiones, en este caso GitLab. Automáticamente debería compilarse el proyecto, ejecutarse las pruebas unitarias, ejecutarse el análisis estático de código y desplegarse la aplicación en un entorno de test.
**1.-** La integración continua inicia cuando el equipo de desarrollo realiza 'Push events/Merge Request events' al repositorio de versiones, en este caso GitLab. Automáticamente, debería compilarse el proyecto, ejecutarse las pruebas unitarias, ejecutarse el análisis estático de código y desplegarse la aplicación en un entorno de test.
2.- Cuando se suben cambios al GitLab, éste le hace una solicitud a Jenkins para que este último, ejecute un Job ([ver documento de creación de Jobs](herramientas/jenkins/crear_job.md)).
**2.-** Cuando se suben cambios al GitLab, éste le hace una solicitud a Jenkins para que este último, ejecute un Job ([ver documento de creación de Jobs](herramientas/jenkins/crear_job.md)).
El Job creado en Jenkins ejecuta las siguientes tareas:
* Clona el proyecto.
......@@ -35,14 +35,14 @@ Para que el GitLab pueda notificar a Jenkins que hubo cambios y debe ejecutar el
* Si se tiene GitLab CE 8.x se debe crear un Webhook para realizar la notificación a Jenkins, de que hubo cambios y debe ejecutar el build.
* Para versiones inferiores utilizar el plugin de Jenkins.
3.- Para realizar el despliegue automático de las aplicaciones utilizaremos Docker. Luego que Jenkins compile y ejecute test unitarios del proyeto se hará el despliegue de aplicación.
**3.-** Para realizar el despliegue automático de las aplicaciones utilizaremos Docker. Luego que Jenkins compile y ejecute test unitarios del proyeto se hará el despliegue de aplicación.
Para ésto, en la raíz del proyecto se tiene un archivo [Dockerfile](herramientas/docker/Dockerfile.md) con las configuraciones necesarias para que se cree la imagen Docker. Una vez creada la imagen, se debe lanzar un contenedor de la misma (un contenedor es una instancia de una imagen), el contenedor lanzado viene a ser la aplicación desplegada.
4.- En el despliegue de las aplicaciones de debe tomar en cuenta si la aplicación depende de otros servicios; estos pueden ser back-end, microservicio, etc. En el archivo deployment.properties se indica con qué servicios tiene dependencias la aplicación.
**4.-** En el despliegue de las aplicaciones de debe tomar en cuenta si la aplicación depende de otros servicios; estos pueden ser backend, microservicio, etc. En el archivo deployment.properties se indica con qué servicios tiene dependencias la aplicación.
Para el despliegue de la aplicación también se debe tener en cuenta el orden de despliegue, como se muestra en el gráfico. Primero se deben desplegar los servicios sin dependencia, a continuación los que tienen menor dependencia y así progresivamente según la dependencia.
Para realizar el despliegue de microservicios también se puede utilizar [docker-compose](https://docs.docker.com/compose/).
5.- Una vez desplegada la aplicación el equipo QA realizará las pruebas correspondientes a la versión del proyecto.
**5.-** Una vez desplegada la aplicación el equipo QA realizará las pruebas correspondientes a la versión del proyecto.
This diff is collapsed.
......@@ -8,36 +8,36 @@ El presente documento pretende demostrar el flujo que cumple un proyecto de soft
El flujo contempla los siguientes pasos:
1 **Inicio del Proyecto**, el proyecto inicia con la solicitud del cliente y su necesidad de automatizar, controlar y administrar procesos y tareas.
2 **Análisis y Diseño**, el equipo de gobierno electrónico interactúa directamente con el cliente, se encarga de concertar reuniones, obtener insumos, elaborar el listado de requerimientos y en base a estos, desarrollar historias de usuarios.
En esta etapa el equipo de QA realizara las siguientes tareas:
>>a) Verificación de Procesos del Negocio
>>b) Validación de la Especificación de Procesos del Negocio
>>c) Verificación de requerimientos
3 **Desarrollo**, el equipo de desarrollo recibe los documentos generados en el paso anterior y a partir de estos elabora documentación técnica para el inicio del proyecto de software. El proyecto de software emplea las siguientes herramientas: Node.js, Express, Sequelize, PostgreSQL y GitLab. El equipo de desarrollo genera versiones entregables semanales del proyecto los cuales son gestionados en GitLab. El equipo de desarrollo utiliza programación orientada a pruebas (TDD) lo cual obliga a desarrollar test unitarios y test de integración.
En esta etapa el equipo de QA realizara las siguientes tareas:
>>a) Verificación del modelo de análisis
>>b) Verificación del Diseño.
>>c) Revisión de los entregables semanales (Ejecución de pruebas de funcionalidad segun los planes y las tareas programadas para el entregable)
>>En esta etapa el equipo de QA tambien se apoyara en la integración continua para poder ejecutar los test y realizar el análisis estatico de código.
>> **Integración continua**, con el fin de tener software de calidad se implementara la integración continua, este permitira minimizar los bugs en el producto final, calidad desde el incicio y adaptación al cambio. Este proceso tendra el siguiente fujo:
>> ![alt tag](imagen/flujo-ci.png)
4 **Puesta en producción**, La puesta en producción del proyecto de software es obtenida de un tag de GitLab, el pase a producción no es automático y debe ser autorizado por el personal encargado de esta tarea.
5 **Test de Aceptación**, Cuando el proyecto de software pasa a producción, se otorga al cliente un test de aceptación, con el cual el cliente registra observaciones o indica su conformidad con el producto elaborado.
**1. Inicio del Proyecto**, el proyecto inicia con la solicitud del cliente y su necesidad de automatizar, controlar y administrar procesos y tareas.
**2. Análisis y Diseño**, el equipo de gobierno electrónico interactúa directamente con el cliente, se encarga de concertar reuniones, obtener insumos, elaborar el listado de requerimientos y en base a estos, desarrollar historias de usuarios.
En esta etapa el equipo de QA realizará las siguientes tareas:
a) Verificación de Procesos del Negocio.
b) Validación de la Especificación de Procesos del Negocio.
c) Verificación de requerimientos.
**3. Desarrollo**, el equipo de desarrollo recibe los documentos generados en el paso anterior y a partir de estos, elabora documentación técnica para el inicio del proyecto de software. El proyecto de software emplea las siguientes herramientas: Node.js, Express, Sequelize, PostgreSQL y GitLab. El equipo de desarrollo genera versiones entregables semanales del proyecto, los cuales son gestionados en GitLab. El equipo de desarrollo utiliza programación orientada a pruebas (TDD) lo cual obliga a desarrollar test unitarios y test de integración.
En esta etapa el equipo de QA realizará las siguientes tareas:
a) Verificación del Modelo de análisis.
b) Verificación del Diseño.
c) Revisión de los entregables semanales (Ejecución de pruebas de funcionalidad según los planes y las tareas programadas para el entregable).
En esta etapa el equipo de QA también se apoyara en la integración continua para poder ejecutar los test y realizar el análisis estático de código.
**Integración continua**, con el fin de tener software de calidad se implementará la integración continua, esto permitirá minimizar los bugs en el producto final, calidad desde el incicio y adaptación al cambio. Este proceso tendrá el siguiente fujo:
![alt tag](imagen/flujo-ci.png)
**4. Puesta en producción**, la puesta en producción del proyecto de software es obtenida de un tag de GitLab, el pase a producción no es automático y debe ser autorizado por el personal encargado de esta tarea.
**5. Test de Aceptación**, cuando el proyecto de software pasa a producción, se otorga al cliente un test de aceptación, con el cual el cliente registra observaciones o indica su conformidad con el producto elaborado.
El flujo presentado es cíclico y puede repetirse hasta obtener un producto de calidad.
......
......@@ -6,15 +6,15 @@ El presente documento tiene por finalidad establecer estándares de codificació
## Alcance
Aplicable a los sistemas desarrollados por las siguientes unidades:
1. [nombre de las unidades que desarrollan proyectos de software]
1. Unidad de Innovación, Investigación y Desarrollo.
## Extensión de responsabilidad
Si bien la finalidad del documentos es definir lineamientos para el desarrollo de productos de software la aplicación de los mismos esta sujeto al criterio de los administradores de proyectos y desarrolladores.
Si bien la finalidad del documentos es definir lineamientos para el desarrollo de productos de software, la aplicación de los mismos está sujeta al criterio de los administradores de proyectos y desarrolladores.
## Desarrollo
Los siguientes estándares pretenden alcanzar código mantenible, se considera mantenible cuando el código es: legible, consistente, predictivo y documentado.
La corrección de errores y modificación del código desarrollado de un producto de software toma tiempo considerable, este factor puede incrementarse si el personal que realizar esta actividad no es la misma que realizó el desarrollo o si el espacio temporal entre estas actividades es amplia.
La corrección de errores y modificación del código desarrollado de un producto de software toma tiempo considerable, este factor puede incrementarse si el personal que realiza esta actividad no es el misma que realizó el desarrollo o si el espacio temporal entre estas actividades es amplio.
Otra actividad que se ve afectada por el poco cuidado en la codificación es el mantenimiento, esta actividad generalmente se realiza en la post entrega del producto de software y considerando los cambios en el equipo de desarrollo y el tiempo transcurrido puede superar el 50% del tiempo empleado en el desarrollo del producto inicial.
1. **Convenciones de nombres**
......@@ -63,7 +63,7 @@ Otra actividad que se ve afectada por el poco cuidado en la codificación es el
var logFileName setBodyParser()
private pathRootFolder public getProductInfo()
```
* El estilo para los nombres de clases e interfaces es UpperCamelCase la cual establece que la letra inicial debe ser mayúscula y las palabras siguientes deben tener la inicial en mayúsculas y el resto en minúsculas.
* El estilo para los nombres de clases e interfaces es UpperCamelCase lo cual establece que la letra inicial debe ser mayúscula y las palabras siguientes deben tener la inicial en mayúsculas y el resto en minúsculas.
```javascript
// Ejemplos UpperCamelCase
......
......@@ -9,7 +9,7 @@ Aplicable a los proyectos de software desarrollados por AGETIC.
## Pruebas unitarias
Son las pruebas de más bajo nivel. Una prueba unitaria consiste en probar las unidades de un proyecto de software como ser: clases y métodos.
El desarrollo y aplicación de las pruebas unitarias es imprescindible cuando se desarrolla bajo el proceso TDD (Test Driven Development). El proceso de desarrollo TDD se basa en la escritura de casos de pruebas previa al código a ser evaluado.
El desarrollo y aplicación de las pruebas unitarias es imprescindible cuando se desarrolla bajo el proceso TDD (Test Driven Development). El proceso de desarrollo TDD se basa en la escritura de casos de pruebas previa al código a ser evaluado.
Los casos de prueba reflejan el comportamiento deseado de una clase o un método, posterior a la especificación del caso de prueba se procede a desarrollar el código que cumple el mencionado comportamiento.
......@@ -18,12 +18,12 @@ Las pruebas unitarias no deben incluir a otros módulos o componentes del proyec
## Pruebas de integración
Las pruebas de integración consisten en comprobar la interacción entre 2 o más módulos de un proyecto de software.
La complejidad en la elaboración de este tipo de pruebas es mayor al de las pruebas unitarias razón por la cual se desarrolla pruebas para los módulos mas importantes del proyecto.
La complejidad en la elaboración de este tipo de pruebas es mayor al de las pruebas unitarias razón por la cual se desarrolla pruebas para los módulos más importantes del proyecto.
Si una prueba de integración falla la causa puede estar atribuida al entorno y no necesariamente al código.
### Persistencia en base de datos
Para pruebas sobre módulos que realizan persistencia en base de datos se debe considerar la posibilidad de utilizar una base de datos alterna, la base de datos alterna debe contener la misma estructura, codificación y datos que la base de datos original.
Para pruebas sobre módulos que realizan persistencia en base de datos se debe considerar la posibilidad de utilizar una base de datos alterna, la base de datos alterna debe contener la misma estructura, codificación y datos que la base de datos original.
Para la ejecución de estas pruebas es importante que el código (clases y métodos) pueda identificar el entorno de ejecución sea este original o de pruebas en base a parámetros o configuraciones.
......@@ -42,7 +42,7 @@ Las pruebas deben contener las siguientes actividades:
* Evaluar los datos obtenidos o registrados en los archivos de prueba.
### Interacción con sistemas externos
Cuando se desea realizar pruebas de integración donde se interactúa con sistemas externos, se debe considerar que estos sistemas probablemente no dispongan de un entorno de pruebas y que las pruebas de integración pueden causar envío y/o recepción de información ficticia.
Cuando se desea realizar pruebas de integración donde se interactúa con sistemas externos, se debe considerar que estos sistemas probablemente no dispongan de un entorno de pruebas y que las pruebas de integración pueden causar envío y/o recepción de información ficticia.
Por esta razón es recomendable crear segmentos de código que en base a parámetros puedan identificar al entorno de pruebas y que en lugar de interactuar con sistemas externos, simulen estas interacciones.
Este tipo de pruebas requiere implementar los siguientes pasos:
......@@ -53,7 +53,7 @@ Este tipo de pruebas requiere implementar los siguientes pasos:
## Pruebas funcionales
Se basan fundamentalmente en comprobar que el producto de software cumple con los requerimientos especificados por el cliente o usuario.
Este tipo de pruebas no evalúa cada uno de los módulos de manera individual mas al contrario solamente evalúa el comportamiento del proyecto a nivel funcional, es por eso que estas pruebas son también conocidas como pruebas de caja negra.
Este tipo de pruebas no evalúa cada uno de los módulos de manera individual, mas al contrario solamente evalúa el comportamiento del proyecto a nivel funcional; es por eso, que estas pruebas son también conocidas como pruebas de caja negra.
Este tipo de pruebas pueden ser ejecutadas con herramientas automatizadas o de forma manual, dependiendo de la funcionalidad a ser evaluada.
......@@ -62,4 +62,4 @@ Están orientadas a probar el rendimiento bajo situaciones extremas como ser: al
## Pruebas de aceptación
Las pruebas de aceptación son las pruebas realizadas en entornos reales y con usuarios reales quienes indican si el proyecto de software cumple con las expectativas.
\ No newline at end of file
Las pruebas de aceptación son las pruebas realizadas en entornos reales y con usuarios reales quienes indican si el proyecto de software cumple con las expectativas.
# Flujo de Trabajo Desarrollo - SQA
1) Llegado el día establecido por el administrador de proyectos para la entrega de la versión, el team líder deberá verificar la correcta funcionalidad del entregable.
1) Llegado el día establecido por el administrador de proyectos para la entrega de la versión, el líder de cada equipo deberá verificar la correcta funcionalidad del entregable.
2) El día establecido por el administrador de proyectos para la entrega de la versión el team líder deberá enviar un email al grupo de QA con la siguiente información:
2) El día establecido por el administrador de proyectos para la entrega de la versión, el líder de equipo deberá enviar un correo electrónico al grupo de QA con la siguiente información:
> - El asunto del correo debe tener el siguiente formato: **Versión Entregable [proyecto] v[X.Y.Z] [para revisión/demorada]** ejm. "Versión entregable IOP v1.5.0 demorada"
> - El archivo adjunto con el formulario definido correctamente llenado.[Plantilla del archivo.](/doc/sigla-version.odt/).
> - El archivo adjunto con el formulario definido correctamente llenado. [Plantilla del archivo](/doc/sigla-version.odt/).
Se recomienda utilizar la plantilla de correo: [Plantilla de informe para revisión de proyectos](/doc/herramientas/thunderbird/qa-informe-proyecto-rev.eml/)).
Solo se revisarán los proyectos, si éstos cuentas con pruebas unitarias y de integración, mismas que deben ejecutarse satisfactoriamente al 100%. En otro caso, el proyeto será rechazado, y no se le hará ninguna prueba más. Por otro lado, también será aplicable el rechazo a aquellos proyectos cuyo archivo o manual de instalación presente un error, omisión o factor que no permita levantar el sistema satisfactoriamente. Así como, los proyectos cuya documentación acerca del flujo del sistema no esté detallada lo más clara posible y en la carpeta docs, al igual que las tareas correspondientes a la versión que se revisará, en el OpenProject.
Sólo se revisarán los proyectos, si éstos cuentas con pruebas unitarias y de integración, mismas que deben ejecutarse satisfactoriamente al 100%. En otro caso, el proyeto será rechazado, y no se le hará ninguna prueba más. Por otro lado, también será aplicable el rechazo a aquellos proyectos cuyo archivo o manual de instalación presente un error, omisión o factor que no permita levantar el sistema satisfactoriamente. Así como, los proyectos cuya documentación acerca del flujo del sistema no esté detallada lo más clara posible y en la carpeta docs, al igual que las tareas correspondientes a la versión que se revisará, en el OpenProject.
Si por algún motivo el equipo de desarrollo tuviesen un inconveniente el plazo vence al medio día del día siguiente, dada esta situación, el team leader deberá notificar este retraso con un correo.
Si por algún motivo el equipo de desarrollo tuviesen un inconveniente el plazo vence al medio día del día siguiente, dada esta situación, el líder de equipo deberá notificar este retraso con un correo.
3) El equipo de QA subirá un reporte de las pruebas realizadas al owncloud. Comunicará mediante un email al team lider y jefes de unidad
De los proyectos que deben subir a producción los jefes de unidad decidirán si efectivamente serán puestas en producción a pesar de las observaciones que se pudieron notificar en el reporte del equipo QA. O si la versión debe ser corregida para una nueva evaluación del equipo QA.
3) El equipo de QA subirá un reporte de las pruebas realizadas a una carpeta compartida en ownCloud. Comunicará mediante un email al líder de equipo y jefes de unidad.
Acerca de los proyectos que deben subir a producción, los jefes de unidad decidirán si efectivamente serán puestos en producción a pesar de las observaciones que se pudieran notificar en el reporte del equipo QA. O si la versión debe ser corregida para una nueva evaluación por el equipo QA.
4) Los equipos deberán programar los bugs en una nueva versión entregable y marcarlos como 'Error'. Las coordinaciones se debe realizar mediante el administrador de proyectos.
......@@ -21,8 +21,8 @@ Para instalar en CentOS
```
## Pruebas
Se recomienda:
* Dejar un intervalo de 4 minutos entre cada prueba.
Se recomienda:
* Dejar un intervalo de 4 minutos entre cada prueba.
* Seleccionar parámetros máximos y mínimos en solicitudes (requests) y concurrencias.
* Realizar mediciones entre los parámetros máximos y mínimos.
......@@ -35,13 +35,13 @@ Para realizar una prueba inicial utilizar el comando
Donde:
n Indica el número de solicitudes(requests) que se realizarán al servidor
c Indica la cantidad de solicitudes simultaneas
c Indica la cantidad de solicitudes simultáneas
En el anterior ejemplo se realizarán 500 solicitudes en total considerando que se realizarán 100 solicitudes simultaneas apache benchmark realizará 5 bloques de solicitudes.
Con el anterior ejemplo se realizarán 500 solicitudes en total, considerando que se realizarán 100 solicitudes simultaneas apache benchmark realizará 5 bloques de solicitudes.
## Gnuplot
Con la finalidad de obtener una mejor lectura o diagnostico del estado del servidor se puede utilizar la herramienta gnuplot para graficar y comparar los resultados de AB.
Con la finalidad de obtener una mejor lectura o diagnóstico del estado del servidor se puede utilizar la herramienta gnuplot para graficar y comparar los resultados de AB.
Para instalar en Debian
......@@ -59,4 +59,4 @@ Para combinar gnuplot con AB se debe dirigir el resultado a un archivo de texto,
```sh
ab -n 5000 -c 500 -g result-n5000-c500.tsv "http://tusitio.com/"
```
\ No newline at end of file
```
# Apache Benchmark AB - ejemplo
## Descripción del Documento
El presente documento contiene un ejemplos básicos para el uso de apache benchmark.
El presente documento contiene un ejemplos básicos para el uso de Apache Benchmark.
## Ejemplos
......@@ -14,9 +14,9 @@ Ejemplo 1:
Donde:
n Indica el número de solicitudes(requests) que se realizarán al servidor
c Indica la cantidad de solicitudes simultaneas
c Indica la cantidad de solicitudes simultáneas
En el anterior ejemplo se realizarán 500 solicitudes en total considerando que se realizarán 100 solicitudes simultaneas apache benchmark realizará 5 bloques de solicitudes.
En el anterior ejemplo se realizarán 500 solicitudes en total, considerando que se realizarán 100 solicitudes simultáneas, Apache Benchmark realizará 5 bloques de solicitudes.
El resultado del anterior comando será similar a:
......@@ -71,13 +71,13 @@ El resultado del anterior comando será similar a:
Los datos más relevantes del resultado de AB son:
* Requests per second, indica la cantidad de solicitudes por segundo que atiende el servidor.
* Time per request, indica el valor promedio que le toma al servidor procesar las solicitudes simultaneas.
* Time per request, indica el valor promedio que le toma al servidor procesar las solicitudes simultáneas.
* Time per request (across all concurrent request), indica el valor promedio que le toma al servidor procesar cada solicitud.
* Failed requests, indica la cantidad de solicitudes que no obtuvieron respuesta por parte del servidor, este valor permite identificar cual es el número máximo de solicitudes y concurrencia que soporta el servidor antes de dejar de enviar respuestas.
* Total transferred, este número indica la cantidad de bytes transferida durante las solictudes. Dividiendo este valor entre la cantidad de solicitudes da un valor aproximado de bytes por solicitud.
* Failed requests, indica la cantidad de solicitudes que no obtuvieron respuesta por parte del servidor, este valor permite identificar cuál es el número máximo de solicitudes y concurrencia que soporta el servidor antes de dejar de enviar respuestas.
* Total transferred, este número indica la cantidad de bytes transferidos durante las solictudes. Dividiendo este valor entre la cantidad de solicitudes, da un valor aproximado de bytes por solicitud.
## Ejemplo con Gnuplot
Para combinar gnuplot con AB primero se debe dirigir la salida aun archivo de texto, esto se realiza mediante el parámetro -g del comando ab.
Para combinar gnuplot con AB, primero se debe dirigir la salida a un archivo de texto, esto se realiza mediante el parámetro -g del comando ab.
```sh
ab -n 5000 -c 500 -g result-n5000-c500.tsv "http://tusitio.com/"
......@@ -85,30 +85,30 @@ Para combinar gnuplot con AB primero se debe dirigir la salida aun archivo de te
Esta operación puede repetirse cambiando el número de solicitudes y concurrencia, de esta manera se puede ver el comportamiento del servidor en distintas circunstancias. Para obtener mejores resultados se sugiere mantener la cantidad de solicitudes y variar el número de concurrencias.
Para generar un gráfico con gnuplot se requiere de un archivo template, el cual contiene leyendas dimensiones y configuraciones del gráfico, a continuación un un ejemplo de template de gnuplot.
Para generar un gráfico con gnuplot se requiere de un archivo template, el cual contiene leyendas dimensiones y configuraciones del gráfico, a continuación un ejemplo de template de gnuplot.
```sh
# indica que la salida será una imagen png
set terminal png
# guarda el archivo imagen con el nombre "benchmark.png"
set output "benchmark.png"
# indica el título del gráfico
set title "Resultados AB Sol: 5000 Conc. 100-5000"
# indica la relación de aspecto del gráfico
set size 1,0.7
# y-axis grid
set grid y
# leyenda para el eje X
set xlabel "solicitudes (request)"
# Leyenda para el eje Y
set ylabel "tiempo de respuesta (ms)"
# genera un gráfico utilizando archivos generado con Apache Benchmark
plot "result-n5000-c100.tsv" using 9 smooth sbezier with lines title "server 5000,100:", \
"result-n5000-c500.tsv" using 9 smooth sbezier with lines title "server 5000,500:", \
......@@ -117,12 +117,12 @@ Para generar un gráfico con gnuplot se requiere de un archivo template, el cual
Se recomienda utilizar la extensión .p para los archivos de template de gnuplot.
Para ejecutar el template se utiliza el siguiente comando
Para ejecutar el template se utiliza el siguiente comando:
```sh
gnuplot template.p
```
En el archivo de ejemplo de template el comando ```plot``` agrupa el resultado de 3 mediciones y les asigna una leyenda, de esta manera se puede comparar mas de 1 resultado como se ve en el siguiente ejemplo
En el archivo de ejemplo de template, el comando ```plot``` agrupa el resultado de 3 mediciones y les asigna una leyenda, de esta manera se puede comparar más de 1 resultado, como se ve en el siguiente ejemplo:
![alt tag](/doc/herramientas/apache-benchmark/archivos/benchmark.png)
\ No newline at end of file
![alt tag](/doc/herramientas/apache-benchmark/archivos/benchmark.png)
......@@ -7,7 +7,7 @@ Para instalar docker en debian, ejecutar:
$ curl -sSL https://get.docker.com/ | sh
```
Esto instalará el servidor y el cliente de Docker, luego se debe adicionar los usuarios que se conectarán al demonio de docker, estos usuarios deben tener su directorio home.
Esto instalará el servidor y el cliente de Docker, luego se debe adicionar los usuarios que se conectarán al demonio de Docker, estos usuarios deben tener su directorio home.
Ejemplo :
......@@ -15,9 +15,9 @@ Esto instalará el servidor y el cliente de Docker, luego se debe adicionar los
$ sudo usermod -aG docker jenkins
```
donde 'jenkins' es el usuario que se conectará con el demonio de docker.
donde 'jenkins' es el usuario que se conectará con el demonio de Docker.
Para verificar que la instalación se realizó correctamente, cambiar de usuario con los usuarios que se agregaron al grupo de docker y ejecutar 'docker versión'. Ésto, debería desplegar la versión del cliente y el servidor de docker.
Para verificar que la instalación se realizó correctamente, cambiar de usuario con los usuarios que se agregaron al grupo de Docker y ejecutar 'docker versión'. Ésto, debería desplegar la versión del cliente y el servidor de docker.
![](/doc/herramientas/docker/archivos/docker_version.png)
......@@ -41,7 +41,7 @@ $ apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118
3.- Abrir el archivo /etc/apt/sources.list.d/docker.list con su editor favorito. Si el archivo no existe, crearlo.
4 En el archivo anterior eliminar las entradas existentes.
4.- En el archivo anterior eliminar las entradas existentes.
5.- Adicionar la siguiente entrada.
......@@ -67,13 +67,13 @@ $ apt-cache policy docker-engine
$ sudo apt-get update
```
9.- Instalar docker.
9.- Instalar Docker.
```sh
sudo apt-get install docker-engine
```
10.- Iniciar el demonio de docker.
10.- Iniciar el demonio de Docker.
```sh
$ sudo service docker start
......@@ -85,6 +85,6 @@ $ sudo service docker start
$ sudo usermod -aG docker usuario_a_agregar
```
Para verificar que la instalación se realizó correctamente, cambiar de usuario con los usuarios que se agregaron al grupo de docker y ejecutar 'docker versión'. Ésto, debería desplegar la versión del cliente y el servidor de docker.
Para verificar que la instalación se realizó correctamente, cambiar de usuario con los usuarios que se agregaron al grupo de docker y ejecutar 'docker versión'. Ésto, debería desplegar la versión del cliente y el servidor de Docker.
![](/doc/herramientas/docker/archivos/docker_version.png)
......@@ -45,7 +45,7 @@ Luego de la instalación del plugin debemos configurar las versiones de NodeJs q
![](/doc/herramientas/jenkins/archivos/node_configuration.png)
en la siguinte pantalla ir a la sección 'NodeJs' y hacer click en 'NodeJs Installations...' a continuación completar la información del formulario.
en la siguiente pantalla ir a la sección 'NodeJs' y hacer click en 'NodeJs Installations...' a continuación completar la información del formulario.
![](/doc/herramientas/jenkins/archivos/node_add.png)
......@@ -64,7 +64,7 @@ En la siguiente pantalla tenemos las secciones
* General
En esta sección elegimos la conexión al GitLab (esta conexión ya la configuramos anteriormente en configuraciones iniciales).
En esta sección, elegimos la conexión al GitLab (esta conexión ya la configuramos anteriormente en configuraciones iniciales).
![](/doc/herramientas/jenkins/archivos/gitlab_conn_job.png)
......@@ -167,19 +167,19 @@ fi
```
Del código tomar en cuenta lo siguiente:
Del código, tomar en cuenta lo siguiente:
![](/doc/herramientas/jenkins/archivos/code_job_.png)
> 1. Instalar dependencias según el proyecto.
> 2. los proyectos deben tener un archivo 'deployment/deployment.properties' con la versión del proyecto y los links con los proyectos que se conectan.
> 2. Los proyectos deben tener un archivo 'deployment/deployment.properties' con la versión del proyecto y los links con los proyectos que se conectan.
> ![](/doc/herramientas/jenkins/archivos/deployment_job.png)
> 3. El nombre de la imagen como del contenedor se obtendrá de la primera línea del archivo deployment.properties.
> 4. Los links del proyecto (backend, servicios, etc) estan desde la segunda línea en adelante del archivo deployment.properties. estos links ya deberían estar desplegados para que el nuevo contenedor pueda conectarse con ellos.
> 5. Para poder desplegar la aplicación en un puerto debemos verificar que el puerto no este ocupado, generalmente tendremos dos versiones del proyecto corriendo, estos dos puertos ya estan definidos en el caso del ejemplo del codigo 3000 y 3001, entonces si se lanza una nueva versión de la aplicación una versión anterior el eliminada liberando un puerto para que se pueda desplegar en ese puerto la nueva versión de la aplicación.
> 5. Para poder desplegar la aplicación en un puerto debemos verificar que el puerto no este ocupado, generalmente tendremos dos versiones del proyecto corriendo, estos dos puertos ya estan definidos en el caso del ejemplo del código 3000 y 3001, entonces si se lanza una nueva versión de la aplicación una versión anterior es eliminada liberando un puerto para que se pueda desplegar en ese puerto la nueva versión de la aplicación.
> 6. Desplegar primero los modulos independientes y se debe enviar los parámetros de todos los servicios que utilice.
> ![](/doc/herramientas/jenkins/archivos/orden_despliegue.png)
* Post-build Actions
En esta sección se configura las acciones posteriores al build, en esta sección elegiremos 'Publish build status to GitLab commit', para retornar el resultado del build al GitLab.
En esta sección, se configura las acciones posteriores al build, elegiremos 'Publish build status to GitLab commit', para retornar el resultado del build al GitLab.
......@@ -6,22 +6,22 @@ El presente documento contiene procedimientos básicos para la instalación de S
## Versión y tipo de aplicación
Selenium se divide en 2 partes:Selenium WebDriver y Selenium IDE, recomendado para realizar pruebas rápidas mediante un IDE integrado al navegador Mozilla Firefox.
Selenium se divide en 2 partes: Selenium WebDriver y Selenium IDE, recomendado para realizar pruebas rápidas mediante un IDE integrado al navegador Mozilla Firefox.
Selenium IDE será la herramienta descrita en el presente documento.
Si bien el sitio oficial [Selenium IDE](http://www.seleniumhq.org), provee de un complemento (addon) para el navegador Firefox, es recomendable utilizar el complemento que se encuentra en
Si bien el sitio oficial [Selenium IDE](http://www.seleniumhq.org), provee de un complemento (addon) para el navegador Firefox, es recomendable utilizar el complemento que se encuentra en
el sitio [Firefox Addons](https://addons.mozilla.org/es/firefox/search/?q=selenium&appver=46.0&platform=linux), debido a las variaciones entre versiones del navegador y el complemento.
## Instalación
## Instalación
* Para instalar el complemento se debe insgresar a la página de complementos de [Mozilla Firefox](https://addons.mozilla.org/es/firefox/).
* En el listado de complementos de firefox, se debe ubicar el complemento con el nombre "Selenium IDE", puede usar este [enlace](https://addons.mozilla.org/en-US/firefox/addon/selenium-ide/?src=userprofile).
* Posterior a la instalación el navegador debe mostrar el icono ![alt tag](/doc/herramientas/selenium-ide/archivos/selection_002.png)
* Al presionar el boton se abrirá el IDE se Selenium
* Para instalar el complemento se debe ingresar a la página de complementos de [Mozilla Firefox](https://addons.mozilla.org/es/firefox/).
* En el listado de complementos de Firefox, se debe ubicar el complemento con el nombre "Selenium IDE", puede usar este [enlace](https://addons.mozilla.org/en-US/firefox/addon/selenium-ide/?src=userprofile).
* Posterior a la instalación el navegador debe mostrar el ícono ![alt tag](/doc/herramientas/selenium-ide/archivos/selection_002.png)
* Al presionar el botón se abrirá el IDE se Selenium
## Elementos del IDE
A continuación se detallan las caracteristicas más importantes e la herramienta.
A continuación se detallan las caracteristicas más importantes en la herramienta.
![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-ide-numbered.png)
......@@ -30,21 +30,21 @@ A continuación se detallan las caracteristicas más importantes e la herramient
3. Ejecuta la prueba seleccionada en el panel de Casos de prueba.
4. Pausar / Continuar, pausa o reanuda la ejecución de pruebas, mediante esta opción se puede hacer inspección a detalle de las pruebas en ejecución.
5. Ejecución por pasos, permite ejecutar uno por uno los comando que componen un Caso de Prueba.
6. Programador de ejecución de Casos de prueba y Grabador de acciones.
* Programador de Ejecución, permite especificar que caso o casos de pruebas serán ejecutados, tambien permite indicar las horas y los dias que se ejecutarán los casos de pruebas.
6. Programador de ejecución de Casos de prueba y Grabador de acciones.
* Programador de Ejecución, permite especificar que caso o casos de pruebas serán ejecutados, también permite indicar las horas y los días que se ejecutarán los casos de pruebas.
* Grabador de acciones, permite grabar las acciones realizadas en el navegador, en algunos casos estas pruebas requieren ser modificadas.
7. Panel de Casos de Prueba (Test Case), en este Panel se muestran los Casos de pruebas disponibles, pueden cargarse tantos casos de pruebas se requieran.
8. Listado de Comandos, El listado de comandos indica el orden (de arriba abajo) de los comandos que se ejecutan a partir de la URL base.
9. Listado de Comandos disponibles, esta lista de selección contiene los comandos disponibles y que pueden ser agregados al listado de comandos.
10. Objetivo (Target), Herramientas para la selección del elemento que evaluará el Comando.
* Ingreso de elementos a ser evaluado y listado de elementos utilizados, indica el elemento del DOM sobre el cual se ejecutara el Comando previamente seleccionado. Para la selección de un elemento se pueden utilizar los siguientes selectores:
* Ingreso de elementos a ser evaluado y listado de elementos utilizados, indica el elemento del DOM sobre el cual se ejecutará el Comando previamente seleccionado. Para la selección de un elemento se pueden utilizar los siguientes selectores:
* Selector de Id, se obtiene a través del atributo id de un elemento del DOM, Ej. *id=my_id*
* Selector de Nombre, se obtiene a través del atributo name de un elemento del DOM. Ej. *name=my_name*. Adicionalmente se puede especificar el índice de los elementos que comparten el mismo nombre mediante el parámetro index, Ej. *name=my_name index=2*
* Selector de enlace (link), se obtiene un elemento del DOM en base al texto del enlace. Ej. *link=Enlace a mi sitio*
* DOM, se puede seleccionar un elemento del documento mediante la notación de JavaScript *document*. Ej. document.div['elements'].button[0].
* XPath, es una herramienta diseñada para navegar a través de documentos XML, mediante esta herramienta se puede navegar entre elementos individuales, atributos o algún otro elemento de un documento XML. Ej. //div[@id="my_item"]/button[0].
* Seleccionar (Select), sirve para seleccionar un elemento de la página, una vez presionado y con la ayuda del ratón se puede seleccionar un elemento simplemente haciendo clic.
* Buscar (Find), sirve para comprobar que el Objetivo (Target) ha sido definido correctamente, al presionar este boton, el elemento de la página que coincide con el valor del Objetivo se resalta momentaneamente.
* Buscar (Find), sirve para comprobar que el Objetivo (Target) ha sido definido correctamente, al presionar este botón, el elemento de la página que coincide con el valor del Objetivo se resalta momentaneamente.
12. Indicador de comandos ejecutados satisfactoriamente.
13. Indicador de comandos ejecutados con errores.
14. Panel de Registro de acciones (Log), este panel brinda información detallada de la ejecución de comandos de prueba de un Caso de Prueba.
......@@ -53,8 +53,8 @@ A continuación se detallan las caracteristicas más importantes e la herramient
Por defecto Selenium IDE tiene la opción de grabado de acciones activada, mientras esta opción este activada las acciones realizadas sobre el navegador serán registradas en el panel de comandos, conjuntamente con los Objetivos y los valores.
La opción de grabado agiliza el registro de pruebas sin embargo se debe revisar los comandos generados para adecuarlos al caso de prueba.
La opción de grabado agiliza el registro de pruebas; sin embargo, se debe revisar los comandos generados para adecuarlos al caso de prueba.
A continuación la captura de Selenium IDE con el grabador de acciones habilitado.
![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-sample.png),
\ No newline at end of file
![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-sample.png)
......@@ -9,42 +9,42 @@ El presente documento contiene un ejemplo de uso de Selenium IDE para automatiza
La versión utilizada para el ejemplo es 2.9.1.
## Caso de Prueba
En el presente ejemplo se generá un caso de prueba sobre el sitio Web [http://www.agetic.gob.bo](http://www.agetic.gob.bo), las pruebas consisten en verificar el acceso a todas las opciones de menú del sitio.
En el presente ejemplo se genera un caso de prueba sobre el sitio Web [http://www.agetic.gob.bo](http://www.agetic.gob.bo), las pruebas consisten en verificar el acceso a todas las opciones de menú del sitio.
A continuación se detallan los pasos a seguir para el caso de prueba.
1. Abrir el navegador Mozilla Firefox.
2. Iniciar Selenium IDE presionando el boton ![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-button.png). ubicado en la parte derecha de la barra de direcciones del Navegador.
2. Iniciar Selenium IDE presionando el botón ![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-button.png). ubicado en la parte derecha de la barra de direcciones del Navegador.
3. Verificar o iniciar que la opción Grabado de opciones este activo ![alt tag](/doc/herramientas/selenium-ide/archivos/record-button.png).
4. Ingresar al sitio [http://www.agetic.gob.bo](http://www.agetic.gob.bo).
![alt tag](/doc/herramientas/selenium-ide/archivos/agetic-browser.png)
5. Verificar que esta misma dirección este en la URL base de Selenium IDE.
5. Verificar que esta misma dirección esté en la URL base de Selenium IDE.
![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-browser.png).
6. Ingresar a cada una de las opciones de menú (Las acciones se guardarán en el panel de Acciones).
6. Ingresar a cada una de las opciones del menú (Las acciones se guardarán en el panel de Acciones).
7. Verificar que en panel de comandos se crean las pruebas de verificación.
![alt tag](/doc/herramientas/selenium-ide/archivos/selenium-command.png).
8. En este punto se puede ejecutar el caso de prueba presioando el boton.
8. En este punto, se puede ejecutar el caso de prueba presionando el botón.
![alt tag](/doc/herramientas/selenium-ide/archivos/test-case-button.png).
9. Cuando se ejecuta el caso de prueba, el valor del indicador de comandos ejecutados satisfactoriamente es 1 y el indicador de comandos ejecutados con errores es 0.
10. Detener el Grabador de acciones ![alt tag](/doc/herramientas/selenium-ide/archivos/grabador-acciones-off.png).
11. Se añadirá una verificación manual en la opción de menú 'Transparencia' donde se verificará el título del documento para la cual se registrará un comando, un objetivo y un valor.
* El comando utilizar es *assertText*.
11. Se añadirá una verificación manual en la opción del menú 'Transparencia', donde se verificará el título del documento para el cual se registrará un comando, un objetivo y un valor.
* El comando a utilizar es *assertText*.
* El objetivo será el título del documento, para este ejemplo se obtendrá el objetivo mediante la opción CSS, para este caso se hace clic izquierdo en el título del documento y selecciona la opción 'Inspeccionar Elemento / Inspect Element'.
![alt tag](/doc/herramientas/selenium-ide/archivos/agetic-transparencia-cmenu.png)
Se muestra el panel de Inspección de código con el elemento HTML seleccionado.
![alt tag](/doc/herramientas/selenium-ide/archivos/web-develop-inspect.png)
En este caso es ```<h1>Transparencia</h1>```. Con este identificador se puede indicar el objetivo con la siguiente regla **css=h1**.
* El valor corresponde al valor esperado del objetivo, en este caso como el comando es **assertText** se compara el texto que contiene el objetivo, en este caso el valor es 'Transparencia'.
* El valor corresponde al valor esperado del objetivo, en este caso como el comando es **assertText** se compara el texto que contiene el objetivo, y el valor es 'Transparencia'.
A continuación se presenta el listado de Comandos generados.
| Comando | Objetivo | Valor | Descripción |
| ------------- |:-------------:| ------:| ----------- |
| open | / | | Realiza la navegación hasta la raíz del sitio. |
| Comando | Objetivo | Valor | Descripción |
| :-----------: |:-------------:| :-----:| :--------------------------------------------- |
| open | / | | Realiza la navegación hasta la raíz del sitio. |
| clickAndWait | link=exact:¿Quiénes Somos? | | Busca un elemento del documento que tenga el título '¿Quiénes Somos?', posteriormente navega hasta la dirección indicada en el elemento encontrado y espera a que termina la carga. |
| clickAndWait | link=Gobierno Electrónico | | Busca un elemento del documento que tenga el título 'Gobierno Electrónico', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
| clickAndWait | link=Simplificación de Trámites | | Busca un elemento del documento que tenga el título 'Simplificación de Trámites', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
| clickAndWait | link=TIC | | Busca un elemento del documento que tenga el título 'TIC', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
| clickAndWait | link=Transparencia | | Busca un elemento del documento que tenga el título 'Transparencia', posteriormente navega hasta la dirección indicada en el elemento encontrado, accede a la dirección y espera a que termina la carga. |
| assertText | css=h1 | Transparencia | Verifica que en el documento actual existe un elemento que cumple con la regla de CSS "css=h1" tenga el valor Transparencia. |
12. Una vez probado y revisado se puede guardar el caso de prueba, para esto se utiliza la opción de menú File > Save Test Case As..., posteriormente seleccionar una ubicación dentro del equipo local y nombrar el caso de prueba para ser utilizado cuando sea necesario. Se debe considerar que el archivo generado con Selenium IDE no tiene extensión.
\ No newline at end of file
12. Una vez probado y revisado se puede guardar el caso de prueba, para esto se utiliza la opción de menú File > Save Test Case As..., posteriormente seleccionar una ubicación dentro del equipo local y nombrar el caso de prueba para ser utilizado cuando sea necesario. Se debe considerar que el archivo generado con Selenium IDE no tiene extensión.
# SonarQube
Para este manual utilizaremos la version 5.5 de SonarQube que es la ultima.
Para este manual utilizaremos la versión 5.5 de SonarQube que es la última.
## Prerequisitos
......@@ -92,7 +92,7 @@ sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncodi
```
Opciones del Servidor Web
Los siguientes ajustes le permiten ejecutar el servidor en la pagina http://192.168.27.211:9000/sonar
Los siguientes ajustes le permiten ejecutar el servidor en la página http://192.168.27.211:9000/sonar
```sh
sonar.web.host=192.168.27.211
......@@ -127,7 +127,7 @@ Abrir el archivo /opt/sonar-runner/conf/sonar-runner.properties
```sh
$ vim /opt/sonar-runner/conf/sonar-runner.properties
```
Modificar las siguientes lineas:
Modificar las siguientes líneas:
```sh
sonar.host.url=http://192.168.27.21:9000/sonar
......@@ -137,7 +137,7 @@ sonar.jdbc.username=sonar
sonar.jdbc.password=secret
```
El valor de sonar.host.url depende de la configuracion de SonarQube localizada en /opt/sonar/conf/sonar.properties
El valor de sonar.host.url depende de la configuración de SonarQube localizada en /opt/sonar/conf/sonar.properties
3) Crear la variable de entorno SONAR_RUNNER_HOME que apunte al directorio de sonar-runner
......@@ -161,7 +161,7 @@ Actualizar las variables de entorno
source /etc/profile.d/sonar.sh
```
## Configuracion Ldap
## Configuración LDAP
1) Instalar el plugin LDAP.
......@@ -179,7 +179,7 @@ Una vez instalado el plugin, reiniciar.
$ vim /opt/sonar/conf/sonar.properties
```
Adicionar las siguientes lineas al final del archivo:
Adicionar las siguientes líneas al final del archivo:
```sh
# LDAP Configuration
......@@ -195,7 +195,7 @@ ldap.url=ldap://192.168.27.61:389
ldap.bindDn=cn=admin,dc=agetic,dc=gob,dc=bo
ldap.bindPassword=adminadmin
#Configuracion de usuarios.
#Configuración de usuarios.
ldap.user.baseDn=ou=usuarios,dc=agetic,dc=gob,dc=bo
ldap.user.request=(&(uid={login}))
ldap.user.realNameAttribute=cn
......
......@@ -10,7 +10,7 @@ La versión del framework a la fecha es 4.2.1.
Zombie es un framework que permite ejecutar pruebas funcionales sobre aplicaciones NodeJs, sus principales características son:
* Hace uso de [Mocha](https://mochajs.org/).
* No esta enlazado directamente a ningún navegador.
* No está enlazado directamente a ningún navegador.
* El lenguaje de programación empleado es JavaScript.