WorksheetsED EVA2
Total questions: 99
Worksheet time: 55mins
tipo de prueba enfocada en verificar una sección específica dentro del código de un programa.
Prueba unitaria
Prueba de usabilidad
Prueba de integración
consisten en seleccionar a un grupo de usuarios de una aplicación y solicitarles que lleven a cabo las
tareas para las cuales fue diseñada.
Prueba de usabilidad
Prueba unitaria
Prueba de integración
combina distintos módulos de un programa y se comprueba cómo trabajan de forma conjunta.
Prueba de integración
Prueba de usabilidad
Prueba unitaria
conjunto de actividades que tratan de comprobar si un producto se está construyendo correctamente.
Verificación
Validación
conjunto de actividades que tratan de comprobar si un producto es correcto.
Validación
Verificación
Si queremos probar que un personaje de un videojuego hace un salto mortal cuando salta...
El objeto de prueba será asegurarnos que cuando el personaje salta, hace el salto mortal
El caso de prueba será pulsar el botón de salto para comprobar que hace el salto mortal
Verdadero
Falso
¿cuál de las siguientes afirmaciones es cierta?
Las pruebas de usabilidad se implementan con software
Para realizar pruebas de usabilidad es necesario que el software esté finalizado, si no, los usuarios no podrán probarlo
Las pruebas de integración se realizan después de las pruebas unitarias
Normalmente suele haber una única prueba unitaria por cada método del programa
Las fixtures (test fixture) siempre son necesarias antes o después de realizar una prueba
Verdadero
Falso
¿cuál de las siguientes no es un principio a seguir cuando implementamos pruebas con JUnit?
No debe ser repetido (debe ser único)
Probar una sola cosa
Tener un propósito claro
Estar escrito de la forma más clara posible
Todas las opciones son correctas
Método de prueba y caso de prueba son sinónimos y nos referimos al mismo concepto
Verdadero
Falso
¿cuál es el framework de java enfocado en al realización de pruebas unitarias?
(a)
¿Dentro de qué metodología se encuentra el desarrollo dirigido por pruebas? (TDD)
(a)
¿Qué nombre reciben los objetos que imitan el comportamiento de un tipo real de objetos?
(a)
¿cuál de las siguientes afirmaciones es falsa?
En las pruebas de caja blanca, se analiza, entre otras cosas, si ante unos valores de entrada de un método, el flujo del
programa ejecuta los if, o los else, o entra en un bucle, o sale de él.
Los casos de prueba son situaciones o contextos bajo los que se comprueba una funcionalidad de un programa es adecuada
Las pruebas de software consisten en verificar y validar un producto de software
Las pruebas de caja negra solo pueden aplicarse a las pruebas unitarias
Una prueba de tipo caja blanca se centra en evaluar el valor de las salidas de un sistema a partir de unas entradas concretas, pero no
tiene en cuenta el funcionamiento interno del sistema.
Verdadero
Falso
¿cuál de las siguientes definiciones corresponde mejor con la refactorización
Grado con el que un software cumple con los requisitos especificados por el cliente o usuario
Establecer y usar una serie de principios de ingeniería para obtener software económico, fiable, y eficiente
Es una técnica de ingeniería del software que permite optimizar un código ya escrito sin cambiar su comportamiento.
Uso de objetos y métodos que proveen de una serie de utilidades para trabajar optimizar el código
¿Qué patrón de refactorización utilizaremos si queremos hacer que una variable local se vuelva un atributo de clase?
Extract Constant
Extract Local Variable
Member Type to Top Level
Convert Local Variable to Field
¿cuál de las siguientes representaciones de enumerado en un diagrama de clases es correcta?
¿Cuál de los siguientes procesos consiste en el conjunto de actividades que tratan de comprobar que un producto se está
construyendo correctamente?
Pruebas de software
Verificación
Calidad del software
Validación
¿Cuál es la utilidad de Java para extraer y generar documentación directamente del código en formato HTML?
(a)
¿cuál de los siguientes tags nos permite indicar si un método está obsoleto?
@deprecated_since
@see
@deprecated
@version
Ninguna de las opciones indicadas es correcta
¿cuál de los siguientes bad smells se corresponde con la siguiente descripción "Las funciones deben tener
el mínimo número de
parámetros posible, siendo 0 lo perfecto"?
Cambio divergente
Clases muy grandes
Lista de parámetros extensa
Cirugía a tiros
¿cuál de los siguientes aspectos no es necesario documentar en el código?
Qué se debería revisar y modificar si hubiese tiempo para ello
De qué se encarga una clase, paquete, método, variable...
c. Todos los aspectos considerados deberían documentarse
Cuál es el uso esperado de una variable o de ese método
¿Qué comando usaremos para regresar al estado inicial de un commit un archivo llamado CameraPlayer.java?
(a)
¿Con qué se corresponde la siguiente definición?
Situación, contexto, o escenario bajo el que se comprueba una funcionalidad de un programa para ver si se comporta de la forma
esperada.
Caso de prueba
Planificación y Diseño de la prueba
Objeto de la prueba
Prueba unitaria
¿Cuál de los siguientes símbolos nos sirve para hacer referencia a los paquetes en un diagrama de clases?
-
#
+
~
Utilizar el una "bóveda" para guardar nuestros cambios desde el último commit:
(a)
Listar el stash:
(a)
Recuperar los últimos cambios guardados en nuestra bóveda:
(a)
Recuperar los cambios del stash 4 que tenemos en nuestra bóveda:
(a)
Borrar todas nuestros stash:
(a)
¿Cuál de las siguientes características no corresponde con TDD?
Es necesario diseñar todas las especificaciones antes de implementar cada una
Se codifica lo mínimo necesario para cumplir los test
En las primeras fases, lo importante es que el código pase las pruebas, y en siguientes iteraciones aplicar técnicas de
refactorización
Para escribir los test, tenemos que pensar primero qué métodos queremos que tenga el programa y cómo funcionarán
Cuando una subclase extiende de otra pero utiliza pocas características de la superclase, nos encontramos ante un bad smell de
Feature Envy
Verdadero
Falso
El IEEE 830 define una serie de recomendaciones para la elaboración de documentación de requerimientos de software.
¿Cuál de las siguientes no corresponde con una recomendación del IEEE 830?
Descripción del comportamiento
Descripción de la información
Descripción funcional
Criterios de verificación
¿cuál de los siguientes tipos de rebase nos sirve para unir dos commits?
Edit
Squash
Reword
Fixup
¿cuál de los siguientes tipos de documentaciones no tiene que ser escrita necesariamente por alguien involucrado en un proyecto?
Documentación del diseño
Documentación de código fuente
Documentación de usuario final
Todas las documentaciones planteadas deben ser escritas por un miembro involucrado en el proyecto
Documentación de las especificaciones
¿Cuál de los siguientes tipos de prueba nos permite evaluar el flujo de ejecución de un programa ante unos valores de entrada
concretos?
Pruebas de caja blanca
Pruebas de usabilidad
Pruebas de caja negra
Pruebas de integración
Permite crear una superclase (clase padre) con los métodos y atributos que seleccionemos
de una clase concreta.
Extract Superclass
Extract constant
Inline
Rename
Convierte un número o cadena literal en una constante.
Extract constant
Inline
Extract Superclass
Rename
Nos permite ajustar una referencia a una variable o método en una sola línea de código.
Inline
Extract constant
Rename
Member Type to Top Level
Es la opción empleada para cambiar el identificador a cualquier elemento (nombre de
variable, clase, método, paquete, directorio, etc).
Rename
Inline
Member Type to Top Level
Extract Method
Convierte una clase anidada en una clase de nivel superior con su propio archivo de java.
Member Type to Top Level
Extract Method
Convert Anonymous Class to Nested
Change Method Signature
Convierte un bloque de código en un método, a partir de un bloque cerrado por llaves { }.
Extract Method
Convert Anonymous Class to Nested
Change Method Signature
Rename
Este patrón de refactorización permite convertir una clase anónima a una clase anidada de
la clase que la contiene.
Convert Anonymous Class to Nested
Change Method Signature
Extract Method
Member Type to Top Level
Permite cambiar el nombre del método y los parámetros que recibe.
Change Method Signature
Convert Anonymous Class to Nested
Extract Method
Member Type to Top Level
Convierte una variable local en un atributo privado de la clase.
Convert Local Variable to Field
Move
Extract Interface
Extract Local Variable
Mueve una clase (fichero .java)de un paquete a otro y se cambian todas las referencias.
Move
Extract Interface
Extract Local Variable
Convert Local Variable to Field
Este patrón de refactorización nos permite seleccionar los métodos de una clase para crear
una Interface.
Extract Interface
Extract Local Variable
Move
Convert Local Variable to Field
Convierte un número o cadena literal en una variable de ámbito local.
Extract Local Variable
Move
Extract Interface
Convert Local Variable to Field
Si queremos concatenar muchos strings en bucles cuando usamos java, es buena opción utilizar el operador '+'
Verdadero
Falso
¿Cuál de los siguientes problemas no se asocia al síntoma de clases muy grandes?
Si se devuelve más de un valor, se debería crear un nuevo método
Si una clase se usa para distintos problemas tendremos clases con demasiados métodos, atributos, e incluso instancias
Las clases deben tener el menor número de responsabilidades y que estar bien delimitadas
Una clase debe tener solo una finalidad
¿cuál de las siguientes no es una buena práctica de programación en java?
Crear una variable local e inicializarla lo más cerca posible de su uso
Reutilizar variables (suponen menos coste computacional)
Evitar comparar objetos con ==
No declarar campos de una clase estándar como public o no indicarles modificadores de visibilidad
En java, es adecuado no escribir las llaves cuando en las condicionales expresamos únicamente una sentencia de código.
Verdadero
Falso
¿Con qué nombre se conoce en general a los síntomas que suelen indicar la necesidad de refactorizar?
refuse bequest
shotgun surgery
feature envy
bad smells
Las clases de muchas líneas o muchos propósitos dificultan su comprensión.
Clases muy grandes
Métodos muy largos
Código duplicado
Legado rechazado
Los método de muchas líneas dificultan su comprensión.
Métodos muy largos
Clases muy grandes
Código duplicado
Legado rechazado
Si se detectan bloques de código iguales o muy parecidos en distintas partes del programa
Código duplicado
Legado rechazado
Lista de parámetros extensa
Cirugía a tiros
Cuando una subclase extiende (hereda) de otra clase, y utiliza pocas características de la superclase,
puede que haya un error en la jerarquía de clases.
Legado rechazado
Código duplicado
Métodos muy largos
Cirugía a tiros
Las funciones deben tener el mínimo número de parámetros posible, siendo 0 lo perfecto.
Lista de parámetros extensa
Cirugía a tiros
Envidia de funcionalidad
Métodos muy largos
Si al modificar una clase, se necesitan modificar otras clases o elementos ajenos a ella para
compatibilizar el cambio.
Cirugía a tiros
Envidia de funcionalidad
Cambio divergente
Lista de parámetros extensa
Ocurre cuando una clase usa más métodos de otra clase, o un método usa más datos de otra clase,
que de la propia.
Envidia de funcionalidad
Cambio divergente
Lista de parámetros extensa
Legado rechazado
Si una clase necesita ser modificada a menudo y por razones muy distintas, puede que la clase esté
realizando demasiadas tareas.
Cambio divergente
Envidia de funcionalidad
Lista de parámetros extensa
Legado rechazado
Una buena convención a la hora de escribir código java es utilizar identificadores de un solo carácter, ya que requieren de menos
memoria. Por ejemplo:
w = true;
Verdadero
Falso
Genera más carga utilizar tipos primitivos que clases wrapper de Java
Verdadero
Falso
¿cuál de las siguientes es una buena práctica de programación en java?
En los switchm no utilizar break en el caso default para ahorrar líneas de código
Utilizar el copiado defensivo
No declarar como constantes los valores inmutables, dado que nos limitan su uso
utilizar do-while frente a otros tipos de bucles, dado que el coste computacional es menor
Entre operadores es adecuado colocar espacios para mejorar la legibilidad
Verdadero
Falso
¿Cuál de las siguientes afirmaciones acerca de los patrones de refactorización es falsa?
También se les llama métodos de refactorización o catálogos de refactorización
Un patrón de refactorización es Extract Constant
Un patrón de refactorización es el uso de clases anónimas
Son las prácticas para refactorizar el código, utilizando las herramientas podremos plantear casos para refactorizar y se
mostrarán las posibles soluciones en las que podremos ver el antes y el después de refactorizar.
Las convenciones de escritura en java existen para facilitar su mantenimiento posterior.
Verdadero
Falso
¿cuál de las siguientes formas de inicializar o declarar arrays sería incorrecta de acuerdo a las convenciones tratadas en clase?
String nombres[];
int[] array = { 0, 1, 2, 3 };
String[] nombres;
int[] array =
{
0, 1, 2, 3
};
es una técnica de la ingeniería del software que permite la optimización de un código previamente
escrito, por medio de cambios en su estructura interna, sin que esto suponga alteraciones en su
comportamiento externo.
refactorización
calidad del software
ingeniería del software
Grado
con el que un sistema, componente, o proceso cumple los requisitos
especificados y las
necesidades o expectativas del cliente o usuario
calidad del software
ingeniería del software
refactorización
establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que
sea fiable, y que funcione de manera eficiente en máquinas reales.
ingeniería del software
calidad del software
refactorización
La refactorización se asocia con la calidad funcional del software
Verdadero
Falso
Un número que represente el IVA de un producto en una operación es un Magic Number si no se está almacenando en una variable o
constante definida previamente que lo identifique.
Verdadero
Falso
¿cuál de las siguientes afirmaciones acerca de cómo declarar variables en java no se corresponde con convención de escritura de las
tratadas en clase?
Inicializar las variables locales en el momento de declararlas o justo después
Todas las opciones proporcionadas son correctas (no hay opciones incorrectas)
Declarar variables de instancia cuando se necesiten, en lugar de al comienzo de la clase
Declarar una sola variable por línea
En un sistema de control de versiones...
¿Quién tiene la última versión del código en un sistema (a) centralizado, (b) distribuido (sin servidor central)?
en (a) cualquier usuario, en (b) no se puede determinar con esa información.
en (a) el servidor, en (b) no se puede determinar con esa información.
en (a) cualquier usuario, En (b) todos los usuarios.
En (a) el servidor, En (b) todos los usuarios
En (a) el servidor, En (b) todos los usuarios
Las modificaciones son realizadas en el cliente y se actualiza en el servidor.
Las modificaciones de un fichero se realizan directamente en el servidor.
No soportan el control de versiones multiusuario.
El trabajo se realiza en el cliente y no existen servidores VCS.
El repositorio o repository:
Es la línea principal del proyecto.
Es la base de datos donde se almacenan los ficheros.
Es la copia local de los usuarios.
Un capítulo de una serie de televisión que ya han transmitido.
El tronco o Trunk o main de un cvs:
La última revisión en el repositorio.
La última revisión de un fichero.
La línea principal de código en el repositorio.
Lista de todos los cambios realizados en el fichero.
El VCS Git:
Utiliza una filosofía distribuida.
Utiliza una filosofía centralizada.
Ha sido desarrollado por Microsoft.
Ha sido desarrollado para manejar sólo pequeños proyectos con pocos usuarios.
En el funcionamiento general de un VCS, un conflicto:
Un conflicto significa que un usuario no están conforme con lo que ha modificado otro usuario.
El vcs no es capaz de resolver conflictos de modificación de dos usuarios en un mismo fichero.
El conflicto de modificación de un fichero por parte de dos usuarios es siempre resuelto por el vcs.
Si dos usuario modifican las mismas líneas el sistema avisa al último usuario para que resuelva el conflicto de forma
manual.
En los VCS distribuidos:
Existen varios servidores con partes del repositorio. La suma de todas las partes de los servidores es el reposistorio completo
Tenemos un servidor principal que tiene el repositorio completo y los usuarios realizan copias del repositorio.
Cada usuario tiene su propio repositorio local que podrá compartir o no con el resto de usuarios
Siempre hay un usuario principal con el repositorio mandatory
La acción de Enviar o commit:
Envía un fichero por primera vez al repositorio.
Aplica los cambios de un fichero a otro para ponerlo al día.
Sube un fichero al repositorio si ha sido cambiado y se le asigna un número de versión.
Actualiza todos los ficheros con la última versión existente en repositorio.
La acción de Fusionar o Merge:
Sube un fichero al repositorio si ha cambiado
Trae un fichero para mezclarlo con mi parte del proyecto
Añade al repositorio por primera vez y lo mezcla con el resto del proyecto
Todos los anteriores son falsos.
Las dos funciones fundamentales de un VCS son:
Guardar el proyecto de forma centralizada y recuperar el proyecto para el que lo necesite
Guardar un historico del proyecto y poder recuperar dicha historia del proyecto.
Permitir trabajar sobre un mismo proyecto por parte de varios desarrolladores y realizar comentarios por parte del que lo
desee.
Almacenamiento de un histórico de la evolución del desarrollo y el control de conflictos cuando haya más de una persona
trabajando sobre el mismo fichero.
Si el usuario desea juntar una rama con el principal o final
Siempre desaparece la rama.
Se ejecuta el comando diff.
Se ejecuta el comando branch.
Todas son falsas.
Si el usuario quiere experimentar nuevos algoritmos sobre el fichero principal.java sin afectar al proyecto. ejecutará:
push
branch
check out for edit
main
Si el usuario quiere ver las modificaciones entre dos versiones ejecutará:
tags
revert
diff
deff
Si un usuario realiza modificaciones y quiere actualizar el servidor ejecutará
Add
commit
revert
check out for edit
Si un usuario trabaja con una rama:
Puede trabajar con otras ramas al mismo tiempo.
Puede cambiar de rama aunque tenga ficheros pendientes de check in.
Sólo puede trabajar en una única rama, ya que el directorio de trabajo es único
Ha ejecutado el comando diff para ello.
Si un usuario va a realizar modificaciones sobre un fichero realizará la acción:
Add
commit
revert
check out for edit
Si voy a realizar control de versiones sobre un fichero nuevo "principal.java" la primera acción será:
Add
commit
revert
Check out
Un VCS:
Va a ser la copia de seguridad de nuestro proyecto.
El sistema de copias de seguridad del proyecto debería incluir también el sistema de ficheros contenido en el VCS.
Como programador individual no me es necesario ya que no voy a tener conflictos de modificación.
No es útil para un programador individual ya que es fácil realizar copias de mis ficheros con otras herramientas especificas
para ello.
Un VCS(Version Control System)
No es una herramenta CASE para el desarrollo del software.
Es una herramienta para el control de versiones que sólo es útil en proyectos donde participan más de un programador.
Es una herramienta fundamental para cualquier desarrollador que permite recuperar versiones anteriores que funcionen
correctamente.
Los VCS sólo me permiten llevar el control de versiones de código y no de otro tipo de documentos. Para otros documentos
utilizaré otras herramientas.
Una rama o Branch:
Es la útima revisión en el repositorio.
Mantiene el historico del fichero.
Me permite mantener una línea separada del fichero principal para realizar modificaciones y pruebas sin afectar al
principal.
Todos son correctos.
En el VCS Git el comando clone permite:
Traer un repositorio entero al nuestro local.
Enviar a otro repositorio nuestros cambios.
Permite traer los cambios de otro repositorio a nuestro repositorio local.
Todos son falsos.
En el VSC Git, los documentos Commited:
Son los documentos que se encuentran en alguna rama del repositorio.
Son los documentos que han sido modificados y están listos para realizar el commit
Son los documentos que han sido modificados pero no han sido aceptados por el momento para el commit.
Son los documentos que no se encuentran en el repositorio.
En el VSC Git, los documentos Modified:
Son los documentos que se encuentran en alguna rama del repositorio.
Son los documentos que han sido modificados y están listos para realizar el commit
Son los documentos que han sido modificados pero no han sido aceptados por el momento para el commit.
Son los documentos que no se encuentran en el repositorio.
En el VSC Git, los documentos Stage:
Son los documentos que se encuentran en alguna rama del repositorio.
Son los documentos que han sido modificados y están listos para realizar el commit
Son los documentos que han sido modificados pero no han sido aceptados por el momento para el commit.
Son los documentos que no se encuentran en el repositorio.
