Control de Versiones Pruebas y Metodologias Flashcards
1
Q
Control de versiones centralizado
A
- CVS
- Subversión (SVN) –> TortoiseSVN
- TFS / SourceSafe
2
Q
Control de versiones Distribuido
A
- Git
- Mercurial
- Bazaar
- Dares
- BtKeeper
3
Q
Caracteristicas de GIT
A
- Tiene dos repositorios, uno central y uno local. La mayor parte del trabajo se realiza en local.
- Soporte avanzado de ramas y mezclas
- main/master
- fix-1079 –> creado por Jira para resolver una incidencia. Correctivo
- feature-5588 –> creado para agregar una caracteristica nueva. Evolutivo
- develop –> rama de desarrollo para todos los desarrolladores.
- release –> versiones entregables
- Compatible con HTTP(S) y SSH
- Uso de criptografía (SHA) sobre los objects–>
- tree
- blob
- commit
- tag
4
Q
Arquitectura de GIT
A
- Working tree –> Local tuyo
- Staging Area –> Local git
- Local repository –> Local git
- Remote repository –> Remoto git
Iremos pasando por cada una de las áreas hasta llegar a subirlo definitivamente en
5
Q
Crear repositorio en Git
A
git init
nos crea el directorio oculto ‘.git’ y nuestros working tree y staging area en local.
6
Q
git status
A
- git status
Nos muestra el estado actual del repositorio, si tenemos cosas nuevas que no han subido al staging o a local repository
7
Q
git add < fichero >
A
- git add < fichero >
Añade los ficheros al Staging Area
8
Q
git commit
A
- git commit -m “mensaje”
Añade los ficheros que están en Staging Area con cambios al Local Repository
9
Q
Para que sirve el fichero .gitignore
A
Fichero donde metemos los patrones de los ficheros que queremos excluir de las subidas al repositorio.
Ej.: *.class
10
Q
git log
A
- git log [–all –decorate –oneline –graph –pretty]
Muestra el historial de commits
11
Q
git branch
A
- git branch < nombre_rama >
Crea una nueva rama dentro del proyecto.
NOTA: para crear rama y moverte a ella directamente git checkout -b < nombre_rama >
12
Q
git checkout
A
- git chechout < nombre_rama >
Se mueve a la rama que indiquemos.
NOTA: para crear rama y moverte a ella directamente git checkout -b < nombre_rama >
13
Q
git tag
A
- git tag -a < nombre del tag > –> Crea un tag
- git tag –> Lista las etiquetas creadas
Etiqueta la versión de la rama en ese momento de lanzar el comando.
14
Q
git merge
A
- git merge –> Para fusionar ramas
15
Q
git rebase
A
- git rebase
Alinea los commit de las ramas
16
Q
git reset
A
- git reset [–hard][–soft][–mixed]
- Hard –> Se elimina el commit de la historia TOTALMENTE
- Mixed –> Se elimina el commit de la historia pero los cambios se llevan al Working Area
- Soft –> Se elimina el commit de la historia pero los cambios se llevan a Staging Area
Origen siempre los commit
17
Q
git clone
A
- git clone < url remota >
Clona un proyecto en un Repo Remoto en tu Repo Local / Working Area
18
Q
git pull
A
- git pull
Descarga los cambios la Repo Local y al Working Area
19
Q
git push
A
- git push .
Sube al Repositorio Remoto los cambios que hay en Repositorio Local
20
Q
git fetch
A
- git fetch
Te baja a tu Local Repository pero no a tu Working area
21
Q
Productos GIT
A
- GitHub
- GitLab
- Bitbucket
22
Q
En cuanto al producto GitHub
A
- Fork –> flujo colaborativo de GitHub
- Pull Request –> De algo que ya has modificado, pides que se valide y se integre pero no lo hace directamente
23
Q
Herramientas de integración continua
A
- Jenkins
- Travis CI
- Circle CI
- TeamCity
- CodeShip
- Bamboo
NOTA: concepto de pipelines
NOTA: La integración continua (CI) se refiere a la práctica de integrar de forma automática y frecuente los cambios de código en un repositorio de código fuente compartido. La entrega y/o implementación continua (CD) es un proceso de dos partes que se refiere a la integración, prueba y entrega de los cambios de código.
24
Q
Plataformas de despliegue
A
- Heroku (PaaS)
- Digital Ocean (IaaS)
- AWS
25
Metodología Unify Process
* Metodología incremental
* Metodología iterativa
* Centrada en arquitectura
* Dirigida por los casos de uso
* Productos
* RUP --> Rational Unify Process
* AUP --> Agile Unify Process
* OpenUP
26
Metodología de Metrica 3 para el Desarrollo
* **PROCESOS**
* EVS --> Estudio Viabilidad del Sistema
* ASI --> Analisis del Sistema de Información
* DSI --> Diseño del Sistema de Información
* CSI --> Construcción del Sistema de Información
* IAS -->Implantación y Aceptación del Sistema de información
* Tangenciales
* PSI --> Planificación del Sistema de Información
* MSI --> Mantenimiento del Sistema de Información
* **INTERFACES** --> Grupos de tareas transversales a todos los procesos.
* Calidad
* Gestion Proyecto
* Gestión de configuracion
* Seguridad
27
Scrum
* Iterativo e Incremental
* Roles
* Cerdo
* Product Owner --> Voz del cliente / Director de proyecto
* Scrum Master --> Facilitador. Hace que Scrum se cumpla
* Scrum Team --> Desarroladores [5-10] con habilidades transversales
* Gallina --> Stakeholders --> Revisiones del spring / Usuarios
* Practicas
* Product Backlog --> Catalogo de requisitos priorizados
* Spring --> Iteración [15-30 dias]
* Reuniones
* Daily --> Reunión diaria. **15 min**
* Spring Planning --> Perparar el Spring. **2 h/semana**. Spring Backlog (subconjunto de Product Backlog)
* Sping Review --> Al final del Spring. Demo. **1h**
* Spring Retrospective --> Al final del Spring. Revisión y mejora. **1h**
* Burn Down Chart --> Gráficas que muestra el trabajo realizado-restante en el momento.
28
Metodología XP (eXtreme Programming)
* Metodologia Agil
* Historias de Usuario --> se agrupan en Epicas. Analisis funcional
* Roles
* Programador
* Cliente
* Encargado de pruebas (tester)
* Encargado de seguimiento (tracker)
* Entrenador (Coach)
* Consultor
* Gestor (Big Boss)
* Practicas
* Programación en parejas
* Refactoring
* Tecnicas de Estimación --> Clientes priorizan
* Integración continua
* CD --> Continous Deployment. Hasta Deploy
* CI --> Continous Integration. Hasta los test
* Cliente in-situ
* 40h/semana
* Pruebas unitarias primero --> TDD (Test Driven Development)
* Entregas pequeñas
29
Pruebas Caja Blanca VS Caja Negra
* Caja Blanca --> Se conoce el detalle del algoritmo
* Prueba de flujo de control
* Prueba de bifurcacion
* Caminos básicos.
* Caja Negra --> Solo nos interesan las entradas y las salidas
30
Pruebas Funcionales
* Prueba la funcionalidad de la aplicación
* Unitarias --> Componentes aislados
* Integración --> Componentes en conjunto
* Aceptación --> Usuario desde pto. vista funcional
* Regresión --> Conjunto de pruebas que prueban el 'producto minimo viable' va bien. Eliminar efecto onda.
* Alpha --> Con el user con el desarrollador como observador
* Beta --> Usuario sin observadores
* Herramientas:
* JUnit --> Unitarias. Mokito para generar los datos.
* NUnit --> Unitarias
* testNG --> Unitarias
* SoapUI --> Funcionales. (PostMan)
* WatiR --> Funcionales. Ruby
* WatiN --> Funcionales. .Net
* JMeter --> Carga
* Selenium --> Funcionales. Aceptación, automatizar sobre interfaz html
* Cypres --> Funcionales
* Cucumber --> Funcionales
31
Pruebas No Funcionales
* No se prueba 'lo que hace' la aplicación sino 'como lo hace'
* Compatibilidad
* Rendimiento
* Seguridad
* Usabilidad
* Herramientas:
* JMeter --> Carga
* HP LoadRunner --> Carga
* LoadUI --> Carga
* SonarQube --> Analisis de código
* PMD --> Analisis de código
* CheckStyle --> Analisis de código
* FindBugs --> Analisis de código
32
Metrica 3. Pruebas de Rendimiento, Volumnen y Sobrecarga
* Pruebas de rendimiento. Consisten en determinar que los **tiempos de respuesta** están dentro de los intervalos establecidos en las especificaciones del sistema.
* Pruebas de volumen. Consisten en examinar el funcionamiento del sistema cuando está trabajando con **grandes volúmenes de datos**, simulando las cargas de trabajo esperadas.
* Pruebas de sobrecarga. Consisten en comprobar el funcionamiento del sistema en el **umbral límite de los recursos**, sometiéndole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos.
33
Herramienta Cucumber
* Define pruebas funcionales
* Gherking --> lenguaje que soporta Cucumber
* Lenguaje de alto nivel que escribimos y genera las pruebas.
34
Según METRICA v3, ¿qué tipo de pruebas son las que tienen como objetivo verificar el correcto ensamblaje entre los distintos componentes para comprobar que interactúan correctamente a través de sus interfaces, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados?
a) Pruebas del sistema.
b) Pruebas de implantación.
c) Pruebas de regresión.
d) Pruebas de integración.
d) Pruebas de integración.
35
¿Cuál de las siguientes herramientas NO es un software para el control de versiones?
a) JMeter
b) Subversion
c) Mercurial
d) GIT
a) JMeter
36
En el equipo de desarrollo se ha decidido usar Selenium WebDriver para:
a) Mejorar la accesibilidad de las páginas web facilitando audios a partir del texto.
b) Automatizar la ejecución de pruebas en el navegador.
c) Minimizar el tiempo de carga de la página web.
d) Diseñar páginas web adaptables.
b) Automatizar la ejecución de pruebas en el navegador.
37
¿Cuál es una herramienta de análisis de seguridad y calidad de código?
a) SonarQube
b) SonarCode
c) SonarCuality
d) SonarSrc
a) SonarQube
38
Señale el software que permite automatizar la construcción y despliegue de un proyecto utilizando el concepto de pipelines:
a) Jenkins
b) RabbitMa
e) Apache Kafka
d) Subversion
a) Jenkins
39
Según Métrica v3, ¿qué tipo de pruebas consiste en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema?
a) Pruebas de respuesta.
b) Pruebas de sobrecarga.
c) Pruebas de rendimiento.
d) Pruebas de tiempo.
c) Pruebas de rendimiento.
40
En el software para control de versiones GIT, hacer un 'commit' es:
a) La acción de introducir comentarios iterativos entre versiones.
b) La acción de establecer un compromiso de uso (commitment) entre ambas partes.
c) La acción de descargar la rama de trabajo del repositorio central.
d) La acción de almacenar una nueva instantánea (snapshot) del estado del proyecto en el historial de GIT.
d) La acción de almacenar una nueva instantánea (snapshot) del estado del proyecto en el historial de GIT.
41
Señale cual de las siguientes herramientas de software libre se utiliza para realizar pruebas de carga y de estrés, permitiendo simular escenarios de concurrencia de usuarios:
a) Cactus
b) Mockito
c) JMeter
d) Foglight
c) JMeter
42
Como repositorio de código en su unidad se utiliza Git, y le preguntan, ¿qué comando, de entre los siguientes, muestra una lista de los commits anteriores?
a) git commit
b) git fetch
c) git status
d) git log
d) git log
43
El equipo de proyecto está estudiando varios framework para valorar su utilización. ¿Cuál es el propósito principal del framework de javascript Jest?
a) Testeado de código.
b) Machine learning.
c) Animacion y efectos gráficos.
d) Funciones matemáticas y tratamiento de cadenas.
a) Testeado de código.
NOTA: Jest, Jasmine, MochaJS, Karma
44
Las pruebas cuya finalidad es verificar que los distintos componentes del sistema interactúan correctamente a través
de sus interfaces se denominan:
a) Pruebas de artefactos.
b) Pruebas de integración.
e) Pruebas de interacción.
d) Pruebas de implantación.
b) Pruebas de integración.
45
Dado un proyecto git, ¿con qué comando puedo listar las etiquetas?
a) git tag
b) git list-tag
c) git rebase
d) git -t
a) git tag
46
La plataforma de control de versiones de Microsoft es:
a) cvs
b) Trello
c) Team Foundation Server
d) ClearCase
c) Team Foundation Server
47
Con respecto a SonarQube, señale la INCORRECTA:
a) Solución diseñada para realizar análisis dinámico del código fuente de manera automática.
b) Entre las verificaciones que puede realizar está la detección de código duplicado.
c) Obtiene diversas métricas sobre el código.
d) Permite definir "Quality Gates" con las condiciones mínimas que el proyecto debe cumplir para subir a producción.
a) Solución diseñada para realizar análisis dinámico del código fuente de manera automática.
48
Tiene ya el sistema preparado. Según Metrica v3, ¿qué tipo de pruebas son las que permiten verificar correcto funcionamiento integrado de hardware y software en el entorno de operación y permitr al usuario que, desde el punto de vista de operación, realice la aceptación del sistema una vez instalado en su entorno real?
a) Pruebas de integración.
b) Pruebas de implantación.
c) Pruebas de aceptación.
d) Pruebas de regresión.
c) Pruebas de aceptación.
49
Señale cuál de las siguientes herramientas sirve para realizar pruebas de estrés en Java:
a) Jmeter
b) SonarQube
c) Junt
d) Piwik
a) Jmeter
50
Siendo el nombre remoto “origin”, y la rama “master”, para subir los commits de una rama local a un repositorio remoto, ¿cuál sería el comando en Git?
a) git push origin master
b) git pull origin master
c) git init origin master
d) git start origin master
a) git push origin master
51
En un Sistema CI/CD, ¿En que consiste un pipeline?
Una configuración de tareas/estados orientados a la construcción, pruebas y despliegue
Generalmente configuramos unos pipeline por --> proyecto y/o entorno
52
Enumera los procesos principales de Metrica3
* EVS -> Estudio de Viabilidad del Sistema
* ASI --> Analisis
* DSI --> Diseño
* IAS (Bloque de desarrollo) --> Implantacion/Aceptacion del Sistema
* Otros menos core --> PSI y MSI (Planificación/Mantenimiento)
53
Enumera alguna tecnica de estimación de proyectos de software
* Modelo o tecnica COCOMO --> Tamaño del proyecto en líneas de código
* Técnica de Punto Función o Punto Casos de Uso
54
¿En que consiste el Spring Backlog?
Subconjunto del Product Backlog que hemos seleccionado para la siguiente iteración
55
Utilidad JMeter y Selenium
1. JMeter --> Pruebas de rendimiento, carga, ...
2. Selenium --> Pruebas funcionales de interfaz de usuario (IDEA: Es el componente WebDriver --> simular navegador)
56
Diferencias entre git pull y git fetch
Los dos comandos bajan los cambios y los integran en el repositorio
* git pull --> Baja los cambios y los integra en el repositorio. Actualiza el working directory (workspace)
* git fetch --> Baja los cambios y los integra en el Repositorio Local
57
¿En que consisten las pruebas de regresión y las unitarias?
* Unitarias --> Comprobar un componente de forma aislada (por eso necesitamos herramientas como Mockito o EasyMock) Ej.: JUnit, NUnit
* Regresión --> Pruebas orientadas a comprobar que no hemos 'roto' nada frente a una nueva versión que hemos liberado
58
Utilidad de SonarQube
Analisis de calidad de código ESTATICO!! (sobre tu codigo fuente sin ejecutar)
NOTA: SonarLint seria la versión en local y no en server (para desarrolladores)
59
¿Cómo se llaman los elementos en los que se agrupan las historias de usuario?
Epicas, pero ponemos la secuencia de menor concreción a mayor concreción
Temas --> Iniciativas --> **Epicas** --> Historias de usuario
60
Indique dos formas de crear una rama en Git
* git branch [nombreRama]
* git checkout -b [nombreRama] (crea la rama y te mueve a ella)
61
Que es un Lint o Linter
Analisis de código ESTATICO en LOCAL
