La ingeniería de software es, de hecho, un campo imprescindible para todas las personas que aspiran a hacer una carrera exitosa como ingeniero de software, desarrollador de software, etc. en la industria de TI. En palabras simples, se ocupa del estudio sistemático y completo del diseño, desarrollo, operaciones y mantenimiento de un sistema de software. En entrevistas tecnológicas de casi todas las empresas tecnológicas de renombre, los reclutadores hicieron varias preguntas sobre conceptos de ingeniería de software, como modelos y arquitectura de desarrollo de software, gestión de proyectos de software (SPM), pruebas y depuración, etc. para evaluar a los candidatos. Por lo tanto, debe estar preparado para todas las preguntas de la entrevista de ingeniería de software para obtener la entrevista.
Sabemos que la ingeniería de software es un campo amplio en sí mismo y descubrir y prepararse para todos los conceptos o preguntas importantes para las entrevistas no es un trabajo fácil. Por lo tanto, para que sea más fácil y conveniente para usted, aquí le proporcionamos una extensa lista de Preguntas frecuentes de entrevistas de ingeniería de software que a menudo hacen los reclutadores. Echa un vistazo a todas estas preguntas a continuación:
1. ¿Qué es la reingeniería de software?
La reingeniería de software es el proceso de escanear, modificar y reconfigurar un sistema de una manera nueva. El principio de reingeniería aplicado al proceso de desarrollo de software se denomina reingeniería de software. Tiene un impacto positivo en el costo del software, la calidad, el servicio al cliente y la velocidad de envío. La reingeniería de software mejora el software para crearlo de manera más eficiente y efectiva.
Para obtener más detalles, consulte ¿Qué es la reingeniería de software?.
2. ¿Cuáles son las características del Software?
Hay varias características del software:
- El software se desarrolla o diseña; no se fabrica en el sentido clásico:
- Aunque existen algunas similitudes entre el desarrollo de software y la fabricación de hardware, pocas actividades son fundamentalmente diferentes.
- En ambas actividades, la alta calidad se logra a través de un buen diseño, pero la fase de fabricación del hardware puede presentar problemas de calidad que el software.
- El software no se “desgasta”:
- Los componentes de hardware sufren los efectos crecientes de muchos otros factores ambientales. En pocas palabras, el hardware comienza a desgastarse.
- El software no es susceptible a las enfermedades ambientales que causan el desgaste del hardware.
- Cuando un componente de hardware se desgasta, se reemplaza por una pieza de repuesto.
- No hay repuestos de software.
- Cada falla de software indica un error en el diseño o en el proceso a través del cual el diseño se tradujo en un código ejecutable por máquina. Por lo tanto, las tareas de mantenimiento de software que se adaptan a las requests de cambio implican una complejidad considerablemente mayor que el mantenimiento de hardware. Sin embargo, la implicación es clara: el software no se desgasta. Pero se deteriora.
- El software sigue siendo personalizado:
- Una parte del software debe planificarse y ejecutarse con el objetivo de que tienda a ser reutilizada en varios proyectos.
- Los segmentos reutilizables actuales encapsulan los dos datos y la preparación que se aplica a los datos, lo que permite al programador crear nuevas aplicaciones a partir de piezas reutilizables.
- En el mundo del hardware, la reutilización de componentes es una parte natural del proceso de ingeniería.
Para obtener más detalles, consulte el siguiente artículo Características de la ingeniería de software .
3. ¿Qué actividades se incluyen bajo el paraguas de actividades?
Las actividades del marco del proceso de ingeniería de software se complementan con una variedad de actividades de nivel superior. Las actividades generales generalmente se aplican a todo el proyecto de software y ayudan al equipo de software a administrar y controlar el progreso, la calidad, los cambios y los riesgos. Las principales actividades comunes incluyen seguimiento y control de proyectos de software, gestión de riesgos, control de calidad de software, revisión técnica, medición, gestión de configuración de software, gestión de reutilización, preparación y producción de productos de trabajo, etc.
4. ¿Qué es Cohesión y Acoplamiento?
La cohesión indica la capacidad funcional relativa del módulo. Los módulos de agregación necesitan interactuar menos con otras secciones de otras partes del programa para realizar una sola tarea. Se puede decir que solo se necesita ejecutar un módulo de coagulación (idealmente). La cohesión es una medida de la fuerza funcional de un módulo. Un módulo con alta cohesión y bajo acoplamiento es funcionalmente independiente de otros módulos. Aquí, la independencia funcional significa que un módulo cohesivo realiza una sola operación o función. El acoplamiento significa la asociación global entre los módulos.
El acoplamiento se basa en la información entregada a través de la interfaz con la complejidad de la interfaz entre los módulos en los que se creó la referencia a la sección o módulo. Soporte de acoplamiento alto Los módulos de acoplamiento bajo suponen que prácticamente no hay otros módulos. Es excepcionalmente relevante cuando ambos módulos intercambian mucha información. El nivel de acoplamiento entre dos módulos depende de la complejidad de la interfaz.
Para obtener más detalles, consulte el siguiente artículo Acoplamiento y cohesión.
5. ¿Cuáles son las diversas fases de SDLC?
Fases SDLC:
- Recopilación y análisis de requisitos
- Diseño
- Implementación y codificación
- Pruebas
- Despliegue
- Mantenimiento
Para obtener más detalles, consulte el siguiente artículo Ciclo de vida del desarrollo de software.
6. ¿Cuál es el nombre de varias herramientas CASE?
- Herramienta de análisis de requisitos
- Herramienta de análisis de estructuras
- Herramienta de diseño de software
- Herramienta de generación de código
- Herramienta de generación de casos de prueba
- Herramienta de producción de documentos
- Herramienta de ingeniería inversa
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software asistida por computadora (CASE).
7. ¿Qué son las pruebas de caja negra?
La prueba de caja negra (también conocida como prueba conducida prueba de caja cerrada prueba de caja opaca) se centra en los requisitos previos útiles del software. En otras palabras, es posible adivinar un conjunto de condiciones de información que ayudan al programa a través de un intento de descubrir y cumplir todas las necesidades a la perfección. No hay elección de procedimientos de caja blanca de prueba de caja negra. Tal vez sea una metodología complementaria, tal vez el método de la caja blanca revele los errores de otras clases.
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: pruebas de caja negra.
8. ¿Qué es la prueba de caja blanca?
La prueba de caja blanca es un método para analizar la estructura interna, las estructuras de datos utilizadas, el diseño interno, la estructura del código y el comportamiento del software, así como funciones como la prueba de caja negra. También se llama prueba de caja de vidrio o prueba de caja transparente o prueba estructural.
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: pruebas de caja blanca.
9. ¿Qué es un estudio de factibilidad?
El Estudio de Viabilidad en Ingeniería de Software es un estudio para evaluar la adecuación de los proyectos y sistemas propuestos. Un estudio de viabilidad es una medida de un producto de software sobre cómo el desarrollo del producto puede beneficiar a una organización desde un análisis de validez o un punto de vista práctico. Los estudios de factibilidad se llevan a cabo con múltiples propósitos para analizar la corrección de un producto de software en términos de desarrollo, portabilidad, la contribución de los proyectos de una organización, etc.
Para obtener más detalles, consulte el siguiente artículo Tipos de estudio de viabilidad en el desarrollo de proyectos de software.
10. ¿Cuál es la diferencia entre garantía de calidad y control de calidad?
|
Garantía de calidad (QA) |
Control de calidad (CC) |
|---|---|
| Se enfoca en brindar seguridad de que se logrará la calidad solicitada. | Se enfoca en cumplir con la calidad solicitada. |
| Es la técnica de gestión de la calidad. | Es la técnica para verificar la calidad. |
| No incluye la ejecución del programa. | Siempre incluye la ejecución del programa. |
| Es una herramienta de gestión. | Es una herramienta correctiva. |
| Está orientado a procesos. | Está orientado al producto. |
| El objetivo del aseguramiento de la calidad es prevenir defectos. | El objetivo del control de calidad es identificar y mejorar los defectos. |
| Es una técnica preventiva. | Es una técnica correctiva. |
| Es una medida proactiva. | Es una medida reactiva. |
| Es responsable del ciclo de vida completo del desarrollo de software. | Es responsable del ciclo de vida de las pruebas de software. |
| Ejemplo: Verificación | Ejemplo: Validación |
11. ¿Cuál es la diferencia entre Verificación y Validación?
|
Verificación |
Validación |
|---|---|
| La verificación es una práctica estática de verificación de documentos, diseño, código, caja negra y programas basados en humanos. | La validación es un mecanismo dinámico de validación y prueba del producto real. |
| No implica ejecutar el código. | Siempre implica ejecutar el código. |
| Es una verificación humana de documentos y archivos. | Es la ejecución del programa basada en computadora. |
| La verificación utiliza métodos como inspecciones, revisiones, recorridos y verificación de escritorio, etc. | La validación utiliza métodos como pruebas de caja negra (funcionales), pruebas de caja gris y pruebas de caja blanca (estructurales), etc. |
| La verificación consiste en comprobar si el software se ajusta a las especificaciones. | La validación consiste en verificar si el software cumple con las expectativas y los requisitos del cliente. |
| Puede detectar errores que la validación no puede detectar. | Puede detectar errores que la verificación no puede detectar. |
| El objetivo es la especificación de requisitos, la arquitectura de la aplicación y el software, el diseño completo de alto nivel y el diseño de la base de datos, etc. | El objetivo es un producto real: una unidad, un módulo, una serie de módulos integrados y un producto final eficaz. |
| El equipo de control de calidad realiza la verificación para garantizar que el software cumpla con las especificaciones del documento SRS. | La validación se lleva a cabo con la participación del equipo de pruebas. |
| Por lo general, se realiza primero antes de la validación. | Generalmente sigue después de la verificación. |
| Es un ejercicio de bajo nivel. | Es un ejercicio de alto nivel. |
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: verificación y validación.
12. ¿Qué es la ingeniería inversa?
La ingeniería inversa de software es un proceso de recuperación del diseño, las especificaciones de requisitos y las funciones de un producto a partir de un análisis de su código. Construye una base de datos del programa y genera información a partir de esto. El propósito de la ingeniería inversa es facilitar el trabajo de mantenimiento mejorando la comprensión de un sistema y produciendo los documentos necesarios para un sistema heredado.
Objetivos de ingeniería inversa:
- Hacer frente a la complejidad.
- Recuperar información perdida.
- Detectar efectos secundarios.
- Sintetizar mayor abstracción.
- Facilitar la reutilización.
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: ingeniería inversa.
13. ¿Qué es SRS?
El formato de especificación de requisitos de software (SRS) es una especificación y descripción completa de los requisitos del software que debe cumplirse para el desarrollo exitoso del sistema de software. Estos requisitos pueden ser tanto funcionales como no necesarios según el tipo de requisito. La interacción entre diferentes clientes y contratistas se realiza porque es necesaria para comprender completamente las necesidades de los clientes. Para obtener más detalles, consulte el artículo de formato de especificación de requisitos de software.
14. Distinguir entre pruebas Alfa y Beta.
|
Prueba alfa |
Pruebas beta |
|---|---|
| Las pruebas alfa implican pruebas de caja blanca y caja negra. | Las pruebas beta comúnmente usan pruebas de caja negra. |
| Las pruebas alfa son realizadas por evaluadores que generalmente son empleados internos de la organización. | Las pruebas beta las realizan clientes que no forman parte de la organización. |
| Las pruebas alfa se realizan en el sitio del desarrollador. | La prueba beta se realiza en el usuario final, al final del producto. |
| Las pruebas de confiabilidad y seguridad no se verifican en las pruebas alfa. | La confiabilidad, la seguridad y la solidez se verifican durante las pruebas beta. |
| Las pruebas alfa garantizan la calidad del producto antes de enviarlo a las pruebas beta. | Las pruebas beta también se concentran en la calidad del producto, pero recopilan los comentarios del usuario sobre el producto durante mucho tiempo y garantizan que el producto esté listo para los usuarios en tiempo real. |
| Las pruebas alfa requieren un entorno de prueba o un laboratorio. | Las pruebas beta no requieren un entorno o laboratorio de pruebas. |
| Las pruebas alfa pueden requerir un largo ciclo de ejecución en tiempo real. | La prueba beta requiere solo unas pocas semanas de ejecución. |
| Los desarrolladores pueden abordar de inmediato los problemas críticos o las correcciones en las pruebas alfa. | La mayoría de los problemas o comentarios recopilados de las pruebas beta se implementarán en futuras versiones del producto. |
Para obtener más detalles, consulte el siguiente artículo Pruebas alfa y pruebas beta .
15. ¿Cuáles son los elementos a considerar en la Construcción del Modelo del Sistema?
16. ¿Qué son las herramientas CASE?
CASE significa ingeniería de software asistida por computadora. Las herramientas CASE son un conjunto de programas de aplicación de software automatizados que se utilizan para respaldar, acelerar y suavizar las actividades de SDLC.
17. ¿Cuál es la limitación del Modelo RAD?
- Para proyectos grandes pero escalables, RAD requiere suficientes recursos humanos.
- Los proyectos fracasan si los desarrolladores y los clientes no se comprometen en un marco de tiempo muy reducido.
- Problemático si un sistema no se puede modularizar
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: modelo de desarrollo rápido de aplicaciones (RAD) .
18. ¿Cuál es la desventaja del modelo en espiral?
- Puede ser un modelo costoso de usar.
- El análisis de riesgos requiere una experiencia muy específica.
- El éxito del proyecto depende en gran medida de la fase de análisis de riesgos.
- No funciona bien para proyectos más pequeños.
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: modelo en espiral .
19. ¿Qué es el modelo COCOMO?
Un modelo COCOMO significa Modelo de Costo Constructivo. Como con todos los modelos de estimación, requiere información de dimensionamiento y la acepta en tres formas:
- puntos de objeto
- Puntos de función
- Líneas de código fuente
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: modelo COCOMO .
20. ¿Define una estimación del esfuerzo de desarrollo de software para software orgánico en el modelo COCOMO básico?
La estimación del esfuerzo de desarrollo de software para software orgánico en el modelo COCOMO básico se define como
Organic: Effort = 2.4(KLOC) 1.05 PM
21. ¿Qué es el modelo de desarrollo de software Agile?
El modelo SDLC ágil es una combinación de modelos de procesos iterativos e incrementales con un enfoque en la adaptabilidad del proceso y la satisfacción del cliente mediante la entrega rápida de productos de software que funcionan. Los métodos ágiles dividen el producto en pequeñas versiones incrementales. Cada iteración involucra equipos multifuncionales que trabajan simultáneamente en varias áreas como planificación, análisis de requisitos, diseño, codificación, pruebas unitarias y pruebas de aceptación.
ventajas:
- Satisfacción del cliente mediante la entrega rápida y continua de software útil.
- Los clientes, desarrolladores y evaluadores interactúan constantemente entre sí.
- Cooperación estrecha y diaria entre empresarios y desarrolladores.
- Atención continua a la excelencia técnica y al buen diseño.
- Adaptación regular a las circunstancias cambiantes.
- Incluso los cambios tardíos en los requisitos son bienvenidos.
Para obtener más detalles, consulte el siguiente artículo Ingeniería de software: modelos de desarrollo ágil .
22. ¿Qué modelo se puede seleccionar si el usuario está involucrado en todas las fases de SDLC?
El modelo RAD se puede seleccionar si el usuario está involucrado en todas las fases de SDLC.
23. ¿Cuáles son las técnicas de estimación de proyectos de software disponibles?
Hay algunas técnicas de estimación de proyectos de software disponibles:
- IMPERTINENTE
- EDT
- método Delfos
- Punto de caso de usuario
24. ¿Qué es DFD de nivel 0?
El nivel de abstracción más alto se denomina Nivel 0 de DFD. También se llama DFD a nivel de contexto. Representa todo el sistema de información como un diagrama.
Para obtener más detalles, consulte el siguiente artículo DFD .
25. ¿Qué es DFD físico?
El DFD físico se centra en cómo se implementa el sistema. El siguiente diagrama a dibujar después de crear un DFD lógico es el DFD físico. Explica el mejor método para implementar las actividades comerciales del sistema. Además, implica la implementación física de dispositivos y archivos necesarios para los procesos de negocio. En otras palabras, el DFD físico contiene los detalles relacionados con la implantación, como el hardware, las personas y otros componentes externos necesarios para ejecutar los procesos comerciales.
26. ¿Cuál es el concepto de agujero negro en DFD?
Un concepto de agujero de bloque en el diagrama de flujo de datos se puede definir como «Un paso de procesamiento puede tener flujos de entrada pero no flujos de salida». En un agujero negro, los datos solo pueden almacenar flujos de entrada.
27. ¿Menciona la fórmula para calcular la complejidad ciclomática de un programa?
La fórmula para calcular la complejidad ciclomática de un programa es:
e = number of edges n = number of vertices p = predicates
Para obtener más detalles, consulte el siguiente artículo Complejidad ciclomática .
28. ¿Qué es la reingeniería de software?
Es un proceso de desarrollo de software que se realiza para mejorar la mantenibilidad de un sistema de software.
29. ¿Cómo encontrar el tamaño de un producto de software?
La estimación del tamaño del software es una parte esencial de la Gestión de Proyectos de Software. Ayuda al gerente del proyecto a predecir aún más el esfuerzo y el tiempo que se necesitarán para construir el proyecto. Varias medidas se utilizan en la estimación del tamaño del proyecto. Algunos de estos son:
- Líneas de código
- Número de entidades en el diagrama ER
- Número total de procesos en el diagrama de flujo de datos detallado
- Puntos de función
30. ¿Menciona algunas herramientas de diseño y análisis de software?
- Diagramas de flujo de datos
- Gráficos estructurados
- Inglés estructurado
- Diccionario de datos
- Diagramas jerárquicos de proceso de entrada y salida
- Diagramas de relación de entidad y tablas de decisión
31. ¿Cuál es la diferencia entre Bug y Error?
Error: un error encontrado en el entorno de desarrollo antes de que el producto se envíe al cliente.
Error: Desviación del valor real y esperado/teórico.
32. ¿Cuál es la diferencia entre Riesgo e Incertidumbre?
- El riesgo se puede medir mientras que la incertidumbre no se puede medir.
- El riesgo se puede calcular mientras que la incertidumbre nunca se puede contar.
- Eres capaz de hacer planes más temprano para evitar riesgos. Es imposible hacer planes previos por la incertidumbre.
- Ciertos tipos de observaciones empíricas pueden ayudar a comprender el riesgo pero, por otro lado, la incertidumbre nunca puede basarse en observaciones empíricas.
- Después de hacer esfuerzos, el riesgo es capaz de convertirse en certeza. Por el contrario, no se puede convertir la incertidumbre en certeza.
- Después de realizar una estimación del factor de riesgo, se puede tomar una decisión, pero como no es posible calcular la incertidumbre, no se puede tomar ninguna decisión.
33. ¿Qué es un diagrama de casos de uso?
Un diagrama de casos de uso es un diagrama de comportamiento y visualiza las interacciones observables entre los actores y el sistema en desarrollo. El diagrama consta del sistema, los casos de uso relacionados y los actores y los relaciona entre sí:
- Sistema : ¿Qué se está describiendo?
- Actor : ¿Quién está usando el sistema?
- Caso de uso : ¿Qué están haciendo los actores?
34. ¿Qué modelo se utiliza para comprobar la fiabilidad del software?
Se utiliza un modelo de Rayleigh para comprobar la fiabilidad del software. El modelo de Rayleigh es un modelo paramétrico en el sentido de que se basa en una distribución estadística específica. Cuando los parámetros de la distribución estadística se estiman en base a los datos de un proyecto de software, se pueden hacer proyecciones sobre la tasa de defectos del proyecto en base al modelo.
35. ¿Qué es CMM?
Para determinar el estado actual de madurez del proceso de una organización, el SEI utiliza una evaluación que da como resultado un esquema de calificación de cinco puntos. El esquema de calificación determina el cumplimiento de un modelo de madurez de la capacidad (CMM) que define las actividades clave requeridas en diferentes niveles de madurez del proceso. El enfoque SEI proporciona una medida de la efectividad global de las prácticas de ingeniería de software de una empresa y establece cinco niveles de madurez del proceso que se definen de la siguiente manera:
- Nivel 1: Inicial
- Nivel 2: Repetible
- Nivel 3: Definido
- Nivel 4: Administrado
- Nivel 5: Optimización
36. ¿Defina mantenimiento adaptativo?
El mantenimiento adaptativo se define como modificaciones y actualizaciones cuando los clientes necesitan que el producto se ejecute en nuevas plataformas, en nuevos sistemas operativos o cuando necesitan que el producto interactúe con nuevo hardware y software.
37. En el contexto del diseño de software modular, ¿ cuál de las combinaciones se considera para la cohesión y el acoplamiento?
En el contexto del diseño de software modular, se considera alta cohesión y bajo acoplamiento.
38. ¿Qué son las pruebas de regresión?
La prueba de regresión se define como un tipo de prueba de software que se utiliza para confirmar que los cambios recientes en el programa o código no han afectado negativamente la funcionalidad existente. Las pruebas de regresión son solo una selección de todos o parte de los casos de prueba que se han ejecutado. Estos casos de prueba se vuelven a ejecutar para garantizar que las funciones existentes funcionen correctamente. Esta prueba se realiza para garantizar que los nuevos cambios de código no tengan efectos secundarios en las funciones existentes. Asegura que después de que se completen los últimos cambios de código, el código anterior sigue siendo válido.
39. ¿Las pruebas de caja negra siempre se enfocan en qué requisito del software?
Las pruebas de caja negra siempre se centran en los requisitos funcionales del software.
40. ¿Cuál de las pruebas se utiliza para la simulación de fallas?
Con mayores expectativas para la calidad de los componentes de software y la complejidad de los componentes, se espera que los desarrolladores de software realicen pruebas efectivas. En el escenario actual, las pruebas de mutación se han utilizado como una técnica de inyección de fallas para medir la idoneidad de las pruebas. La prueba de mutación adopta el «modo de simulación de fallas».
41. ¿Qué es un punto de función?
Las métricas de puntos de función proporcionan un método estandarizado para medir las diversas funciones de una aplicación de software. Métricas de puntos de función, miden la funcionalidad desde el punto de vista del usuario, es decir, en base a lo que el usuario solicita y recibe a cambio.
42. ¿Qué es una línea base?
Una línea de base es una medida que define la integridad de una fase. Una vez que se completan todas las actividades asociadas con una fase en particular, la fase se completa y actúa como una línea de base para la siguiente fase.
43. ¿Cuál es la complejidad ciclomática de un módulo que tiene 17 aristas y 13 Nodes?
La complejidad ciclomática de un módulo que tiene diecisiete aristas y trece Nodes = E – N + 2
E = Number of edges, N = Number of nodes Cyclometic complexity = 17 – 13 + 2 = 6
44. Un software no se desgasta en el sentido tradicional del término, pero el software tiende a deteriorarse a medida que evoluciona, ¿por qué?
El software no se desgasta en el sentido tradicional del término, pero tiende a deteriorarse a medida que evoluciona porque las múltiples requests de cambio introducen errores en las interacciones de los componentes.
45. ¿Una cohesión es una extensión de qué concepto?
Cohesión se refiere al grado en que Cohesión los elementos dentro de un módulo pertenecen juntos. es una extensión del concepto de ocultación de información.
46. ¿Cuáles son los tres componentes esenciales de un plan de proyecto de software?
- Estructura de equipo,
- planes de aseguramiento de la calidad,
- Estimación de costos.
47. La prueba de software contra SRS se conoce como….?
La prueba de software contra SRS se conoce como prueba de aceptación.
48. ¿Cómo medir la complejidad del software?
Para medir la complejidad del software existen algunos métodos en ingeniería de software:
- linea de codigos
- Complejidad ciclomática
- Acoplamiento de clases
- Profundidad de la herencia
49. ¿Defina el término EDT?
La forma completa de WBS es Estructura de Desglose de Trabajo. Su Estructura de Desglose del Trabajo incluye dividir un proyecto grande y complejo en tareas más simples, manejables e independientes. Para construir una estructura de desglose del trabajo, cada Node se descompone recursivamente en subactividades más pequeñas, hasta que, a nivel de hoja, las actividades se vuelven indivisibles e independientes. Una WBS funciona con un enfoque de arriba hacia abajo. Para obtener más detalles, consulte el artículo Estructura de desglose del trabajo .
50. ¿Una prueba de regresión relacionada principalmente con qué prueba?
Las pruebas de regresión están relacionadas principalmente con las pruebas de mantenimiento.
Publicación traducida automáticamente
Artículo escrito por varshachoudhary y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA