Pruebas y Validación de Software

Get Started. It's Free
or sign up with your email address
Pruebas y Validación de Software by Mind Map: Pruebas y Validación de Software

1. Gracias a las historias de usuario se puede realizar pruebas en XP

2. Pruebas en el Software Ricardo Ascencio F

2.1. Actividades que se realizan para detectar posibles fallas en un programa o aplicación

2.2. Pruebas en las GUI

2.2.1. Sub conjunto de las pruebas en el Software que aseguran el correcto funcionamiento en las GUI

2.2.2. GUI (Graphic User Interface) Es el intermediario entre el usuario y un Programa/ Aplicación

2.2.3. Son un paso crítico antes de aceptar un producto final

3. Enfoque tradicional de pruebas: Carlos A Galván

3.1. Requisitos ->

3.1.1. Análisis y diseño ->

3.1.1.1. Implementación ->

3.1.1.1.1. Pruebas: unitaria, integración, sistema y aceptación ->

4. PRUEBAS EN METODOLOGÍAS ÁGILES

4.1. Pruebas relacionadas:

4.1.1. TDD

4.1.1.1. Tiene como objetivo que la aplicación funcione bien. (Luis Alejandro Barreto Quintana)

4.1.2. ATDD

4.1.2.1. Se basa en pruebas de aceptación, tomas como referencia al usuario. (Luis Alejandro Barreto Quintana)

4.1.3. STDD

4.1.3.1. Es una extensión de TDD pero enfocado a pruebas de aceptación de nivel superior. (Luis Alejandro Barreto Quintana)

5. El testing exhaustivo es imposible. Probar absolutamente todas las permutaciones posibles de un sistema no es factible, excepto para casos muy triviales.

6. BERENICE VILLAFUERTE ZAVALA "PRUEBA" ÁGIL VS TRADICIONAL.

6.1. Convencional --> Deja las pruebas hasta el final.

6.2. Ágil --> Prueba cada sprint para poder continuar, minimizando el costo de fallas y errores.

7. Diferencia entre las pruebas para la calidad

7.1. Pruebas para el aseguramiento de calidad

7.2. Pruebas de mejoramiento de calidad

8. Riesgo: Un factor que podría resultar en futuras consecuencias negativas. -J Denisse Huerta Cortes

8.1. Riesgos relacionados con el fracaso de implementar todas las características necesarias.

8.2. Riesgos relacionados con versiones anteriores.

8.3. Riesgos relacionados con el presupuesto y con las restricciones de los recursos.

9. • Depuración: El proceso de encontrar, analizar y retirar las causas de las fallas en el software.

10. • Falla: Desviación del componente o el sistema de su prevista entrega, servicio o resultado.

11. • Calidad: El grado en el cual un componente, un sistema o un proceso cumple los requisitos

11.1. Calidad desde el enfoque de pruebas puede ser la conformidad con el uso

11.1.1. Desde el enfoque de pruebas calidad tambien puede ser la conformidad con los requisitos

12. OSWALDO RODRÍGUEZ

13. Proceso Básico de Pruebas en el Software. -Miguel Kevin Rodriguez M.

14. Ángel Guillermo Hernández Zambrano

15. Existen infinitas formas de probar un sistema terminado

16. Pre-condiciones

17. Ejemplos de Pruebas en el software. -J. Denisse Huerta Cortes

17.1. Objetivo de la prueba: Una Rozon o propósito para el diseño y la ejecución de una prueba.

17.1.1. Pruebas unitarias: se podrían encontrar defectos en las partes individuales del sistema sometidos a pruebas antes de que las partes estén totalmente integradas al mismo.

17.1.2. Pruebas de aceptación: usualmente es un problema si encontramos defectos, mas bien se quiere demostrar que el producto esta casi listo para su despliegue.

17.1.3. Pruebas de sistema: es posible que se quiera encontrar defectos en los comportamientos, funciones y respuestas generales y particulares del sistema sometido a pruebas en su totalidad.

17.1.4. Pruebas de integración: defectos en las relaciones e interfaces entre los pares y grupos de componentes en el sistema sometido a pruebas a medida que las partes se juntan.

17.1.5. Pruebas de mantenimiento: se podrían estar buscando especialmente un tipo particular de defecto, aquellos introducidos durante el desarrollo de los cambios.

17.1.6. Pruebas operativas: se busca un tipo particular de defecto, especialmente aquellos relacionados con las características no funcionales del sistema como la fiabilidad o la disponibilidad, usualmente en el entorno en funcionamiento.

17.2. Ejemplos de Pruebas en el software. -J. Denisse Huerta Cortes

17.2.1. Objetivo de la prueba: Una Rozon o propósito para el diseño y la ejecución de una prueba.

17.2.1.1. Pruebas unitarias: se podrían encontrar defectos en las partes individuales del sistema sometidos a pruebas antes de que las partes estén totalmente integradas al mismo.

17.2.1.2. Pruebas de aceptación: usualmente es un problema si encontramos defectos, mas bien se quiere demostrar que el producto esta casi listo para su despliegue.

17.2.1.3. Pruebas de sistema: es posible que se quiera encontrar defectos en los comportamientos, funciones y respuestas generales y particulares del sistema sometido a pruebas en su totalidad.

17.2.1.4. Pruebas de integración: defectos en las relaciones e interfaces entre los pares y grupos de componentes en el sistema sometido a pruebas a medida que las partes se juntan.

17.2.1.5. Pruebas de mantenimiento: se podrían estar buscando especialmente un tipo particular de defecto, aquellos introducidos durante el desarrollo de los cambios.

17.2.1.6. Pruebas operativas: se busca un tipo particular de defecto, especialmente aquellos relacionados con las características no funcionales del sistema como la fiabilidad o la disponibilidad, usualmente en el entorno en funcionamiento.

18. 1 .Planificación y Control de Pruebas.

19. 3 .Implementacion de las Pruebas

20. 4. Evaluación de Pruebas

21. 5. Cierre de las Pruebas

22. Diseño de alto nivel

23. Diseño de bajo nivel

24. Código

25. Software ejecutable

26. Es el proceso en el cual se definen los objetivos, alcance, herramientas, riesgos, de cada set de pruebas que se desea implementar, así como su priorizacion y monitorizacion de estas, como implementarlas y ejecutarlas en un software.

27. Condiciones

28. Proceso en donde se contempla los escenarios funcionales, no funcionales y críticos de cada requerimiento en un documento de set de pruebas obteniendo los datos que serán utilizados para ejecutar las pruebas.

29. Estos deben tomarse en consideración a las necesidades del cliente(Empresa) a desarrolla el sistema o aplicación

30. Principios de las pruebas Juan José Martínez Paniagua

30.1. Las pruebas demuestran la presencia de defectos (pero no demuestran su ausencia)

30.2. Las pruebas tempranas ayudan a prevenir defectos y ahorrar dinero

30.3. La falacia de la ausencia de errores (es decir, el intento de probar la calidad del sistema al final).

30.4. El agrupamiento de defectos ocurre ya sea si sabe acerca de ello o no

30.5. La paradoja del pesticida. Imaginar que ejecutamos los mismos tests una y otra vez sobre una parte ciertamente estable de nuestro sistema

31. Tomando en cuenta se toman el modelado de lo que desea el cliente, desarrollando cada uno de los esquemas(Diagramas, Casos de Uso etc).

32. Desarrollo y pruebas durante la codificación de Back/FrontEnd del software

33. Producto terminado(Proceso posterior) Mantenimiento y escalabilidad del software

34. Es el proceso en el cual se realiza la ejecución de los set de prueba funcionales, no funcionales y los desarrollados por los analistas en el orden de prioridad establecido verificando que el entorno de pruebas a sido instalado correctamente

35. Proceso en el que se analizan y verifican que los resultados de las pruebas se encuentren dentro de los objetivos y alcance definidos durante la etapa de planeacion y control de las pruebas del software.

36. Pruebas En metodologías ágiles Juan José Martínez Paniagua

36.1. XP(Extreme Programing): Se hacen lo que se llaman historias de usuario y cada historia de usuario, entre otras cosas, lleva asociada una lista de criterios de aceptación y, para cada criterio de aceptación, se define el conjunto de casos de prueba necesarios para validar el criterio de aceptación.

36.2. TDD: cada requisito se representa como un artefacto denominado historia de usuario al que se le asocian sus correspondientes pruebas unitarias. Cuando se aplica TDD, en primer lugar define el repositorio de historias de usuario, conocido como “Product backlog”, que representa los requisitos del sistema.

36.3. ATDD: Cada historia de usuario tiene asociados un conjunto de criterios de aceptación. Posteriormente, para cada criterio de aceptación se definen las pruebas de aceptación que se deben superar. Una vez que las pruebas de aceptación están claramente definidas, el equipo de desarrollo comienza a escribir el código fuente que es necesario para superar los criterios de aceptación

36.4. Las metodologías ágiles y particularmente Extreme Programming (XP), son de alguna manera los responsables del aumento de popularidad de las pruebas de software. Carlos A Galván

36.5. Aunque en las metodologías convencionales las pruebas son importantes, estás dependen directamente del resto de actividades del proceso de desarrollo. Carlos A Galván

36.6. En los enfoques ágiles las pruebas son el centro de la metodología y, por lo tanto son ellas las que dirigen el proceso de desarrollo. Carlos A Galván

36.7. Las metodologías ágiles plantean que el desarrollo no es un conjunto de fases en las que las pruebas son una fase más, sino que abogan porque las prácticasny el desarrollo est+en completamente integradas. Carlos A Galván

37. Proceso en donde se identifican si los productos de software pueden ser puestos en producción, cerrando informes y definiendo planes de acción en caso de futuras incidencias en el producto de software.

38. Pruebas de Software Miguel Kevin Rodriguez M.

38.1. Prueba de Estabilidad

38.1.1. Es una prueba que se ejecuta durante mas de 24 horas para determinar si la aplicación puede aguantar una carga esperada continua.

38.2. Prueba de Carga

38.2.1. Es el tipo de prueba relacionado con la medida del comportamiento de un componente o sistema con una carga creciente ya sea el numero de usuarios o un numero de transacciones.

38.3. Pruebas de regresion

38.3.1. Tipo de Pruebas de un programa previamente probado a raíz de sus modificaciones para garantizar la calidad del software

38.4. Prueba de Estres

38.4.1. Esta tipo de prueba evalúa la robustez y confiabilidad del software sometiéndolo a condiciones de uso extremas saturando el programa hasta llegar a un punto de quiebre

38.5. Prueba de Portabilidad

38.5.1. Es un tipo de prueba que verifica que el software pueda ser ejecutado en diferentes plataformas y/o sistemas operativos

39. Pruebas en metodologías tradicionales Juan José Martínez Paniagua

39.1. Las pruebas en las metodologías convencionales se basa en la definición de los casos de prueba en función de unos requisitos previamente establecidos, mediante los lenguajes adecuados, por ejmeplo XUnit, FIT, o similares. Por lo tanto, el objetivo principal es comprobar que el desarrollo realizado cumple los requisitos definidos.

40. Aplicación de la arquitectura Open - HMI Tester. Adrian Lopez Valdes

40.1. Herramienta de captura y reproducción para pruebas de interfaz grafica. La cual se centra en capturar la interacción del usuario con la aplicación.

40.1.1. El desarrollo de las GUI acaparan el 60% de la codificación de un sistema

40.2. uUNA

40.2.1. De igual forma se esta trabajando en la generación automática del Test y procesos de validación de las interfaces de usuario.

40.3. Data Model Manager. Alejandro García Barajas

41. OHT: Generación automática de test y procesos de validación. -Samuel Alejandro López

41.1. Es una de las aplicaciones principales para OHT. Aplicar pruebas a las GUI generadas automáticamente.

41.1.1. Elementos

41.1.1.1. Casos de uso

41.1.1.1.1. Describe el comportamiento de la GUI.

41.1.1.2. Anotaciones

41.1.1.2.1. Describe las posibles variaciones que afectarían o influirían en el funcionamiento de la GUI.

41.1.1.2.2. Contiene una serie de reglas que comprobarán propiedades de los elementos.

41.1.2. Fases

41.1.2.1. Anotación de la GUI

41.1.2.1.1. Es la creación del elemento 'anotaciones' mencionado previamente.

41.1.2.2. Generación automática de los casos de pruebas

41.1.2.2.1. Se genera un caso de prueba para cada posible combinación de valores.

41.1.2.2.2. Crea validaciones para satisfacer las reglas establecidas en las anotaciones.

41.1.2.3. Ejecución y validación

41.1.2.3.1. Ejecuta los casos de prueba del paso anterior.

41.1.2.3.2. Se basa en implementar test oracles. Principalmente los siguientes tres tipos.

42. Representan un elemento fundamental y crítico de las aplicaciones de hoy en día, llegando a acaparar incluso hasta el 60 % del código. Alejandro García Barajas.

42.1. Tiene como principal objetivo, controlar los procesos de grabación y de reproducción. Alejandro García Barajas.

42.1.1. Estos módulos permiten integrar en la arquitectura Open-HMI Tester la implementación de cualquier representación del modelo de datos. Alejandro García Barajas.

43. 2 . Análisis y diseño

44. Interfaces Gráficas de Usuario (GUI)

45. Arquitectura OHT. Alejandro García Barjas

46. HMI Tester, encargado del control de procesos. Alejandro García Barajas.

47. Modulo Preload Modulo inyectado en la aplicación testada. Alejandro Garcia Barajas

48. Preloading Action Module. Alejandro García Barajas.

49. El principal objetivo de este módulo es llevar a cabo el proceso de precarga, permitiendo la inyección del Módulo Preload al lanzar la aplicación a testar. Alejandro García Barajas

50. Pruebas de caja negra

51. Es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software.Luis Antonio Bautista Rendón

51.1. Tomando en cuenta estos dos caso debe solidarse con el siguiente flujo de pruebas del ciclo de vida del Sw

52. se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. Luis Antonio Bautista Rendón

53. Pruebas de caja blanca

54. Programas de Pruebas automatizadas

55. Son programas que permiten ejecutar cadenas de acciones como clicks e inserción de datos de forma automatica despues de configurarlas una vez sirven para ahorrar tiempo pues se pueden añadir eventos a las pruebas ya guardadas. Luis Antonio Bautista Rendon

56. BASE DE PRUEBA

56.1. Documentación en la que se basan los casos de prueba. (Luis Alejandro Barreto Quintana)

56.1.1. REQUISITO

56.1.1.1. Codición o capacidad necesitada por un cliente o usuario para lograr un objetivo que debe poseer un sistema o componente (Luis Alejandro Barreto Quintana)

56.1.1.2. Necesarios para cumplir con un contrato, estándar, especificación u otro documento formal escrito. (Luis Alejandro Barreto Quintana)

56.1.2. INCIDENCIA

56.1.2.1. Cualquier evento que sucede y se necesita de su investigación. (Luis Alejandro Barreto Quintana)

56.1.3. POLÍTICAS DE PRUEBAS

56.1.3.1. Documento de alto nivel que describen los principios, métodos y objetivos principales de la organización respecto a las pruebas. (Luis Alejandro Barreto Quintana)

56.1.4. DATOS DE PRUEBA

56.1.4.1. Datos que existen antes que una prueba sea ejecutada. (Luis Alejandro Barreto Quintana)

56.1.4.1.1. Afectan al sistema o al componente sometido a las pruebas o son afectados por estos. (Luis Alejandro Barreto Quintana)

56.1.5. OBJETIVO DE PRUEBA

56.1.5.1. Razón o propósito para el diseño y la ejecución de una prueba. (Luis Alejandro Barreto Quintana)

57. Casos de prueba

58. Plan de pruebas de aceptación

59. un conjunto de condiciones o variables bajo las cuales un analista determinará si una aplicación, un sistema software (software system), o una característica de éstos es parcial o completamente satisfactoria Luis Antonio Bautista Rendón

60. Técnica de Prueba Blanca "Cobertura lógica" Berenice Villafuerte Zavala

60.1. Sentencias

60.2. Desiciones

60.3. Condiciones

60.4. Desición/Condición

60.5. Multiple desición

60.6. Toda p

61. Documento importante que contempla todas las pruebas necesarias para el sistema se basa en los requerimientos del sistema. Luis Antonio Bautista Rendón

62. Prueba fallida

63. Si en la ejecución de una prueba no se cumple el requisito para completar la prueba se considera que es una prueba fallida Luis Antonio Bautista Rendón

64. Test frameworks

65. Los test frameworks son parecidos a los anteriores automatizan las pruebas pero con la diferencia que es una herramienta en las que las pruebas se programan en vez de seguir el proceso mediante el uso del sistema.Por ejemplo jest Luis Antonio Bautista Rendón

66. Equipo de pruebas

67. Es el personal a cargo de realizar la documentación del plan de pruebas y de ejecutarlas a veces suele confundirse con el equipo de aseguramiento de calidad. Luis Antonio Bautista Rendón

68. Prueba exitosa

69. Pruebas de ALTO NIVEL Berenice Villafuerte Zavala

69.1. Pruebas alfa :Conducidas por cliente en lugar de desarrollo El equipo registra las anomalías.

69.2. Pruebas beta: Se distribuye el producto a potenciales usuarios Estos prueban el producto e informan de los fallos detectados.

69.3. Pruebas de aceptación: El cliente certifica que el sistema es válido para él Utilizar el plan de aceptación existente.

69.4. Pruebas de instalación: Buscar fallos en la instalación del sistema en un entorno concreto.

70. Si la ejecución de una prueba cumple con los requisitos de éxito de la misma esta se considera como una prueba exitosa .Luis Antonio Bautista Rendón

71. Equipo de aseguramiento de calidad

72. Es el personal que se encarga de verificar que todos los equipos sigan las normas al redactar la documentación y hagan buenas practicas para asegurar la calidad a menudo confundido con el equipo de pruebas. Luis Antonio Bautista Rendón

73. Regulaciones - Gustavo García Sánchez

73.1. Sarbanes-Oxley es una regulación que se promulgó en Estados Unidos con el propósito de monitorizar las empresas que cotizan en la bolsa de valores. (Gustavo García Sánchez)

74. Caso de Prueba - Gustavo García Sánchez

74.1. Es un conjunto de valores de entrada, pre-condiciones de ejecución, resultados esperados y pos-condiciones de ejecución. (Gustavo García Sánchez)

75. Herramientas de Testing - Gustavo García Sánchez

75.1. JMeter: Es una herramienta para intentar realizar pruebas de rendimiento. (Gustavo García Sánchez)

75.2. Selenium: Es una herramienta para hacer pruebas automatizadas. (Gustavo García Sánchez)

75.3. JUnit 5: Herramienta para hacer pruebas unitarias. (Gustavo García Sánchez)

75.4. TestNG: Este sirve como ejecutor de pruebas del Selenium. (Gustavo García Sánchez)

75.5. Bugzilla: Es una herramienta basada en Web desarrollada y usada por Mozilla. (Gustavo García Sánchez)

75.6. HP Quality Center: Es una herramienta de Micro Focus, desarrollado por Mercury Interactive y adquirido por HP posteriormente. (Gustavo García Sánchez)

75.7. Silik Central: Integra un Framework para mejorar la productividad, trazabilidad y visibilidad de todos los tipos de prueba de software. (Gustavo García Sánchez)

76. Defectos - Gustavo García Sánchez

76.1. Los defectos son carencias o falta de cualidades, en el software se encuentran debido a que alguien los colocó ahí, debido a una equivocación. (Gustavo García Sánchez)

77. En SWEBOOK, las pruebas se presentan como una actividad que se desarrolla para evaluar la calidad de un producto y mejorarlo mediante la identificación de los defectos y problemas. Carlos A Galván

77.1. Pru

78. Arquitectura Open-HMI Tester

78.1. Tiene como principal cometido el controlar los procesos de grabación y de reproducción,y el mantenimiento de los casos de pruebas.

79. PRUEBAS EN ENFOQUES CONVENCIONALES Oscar Vallejo T.

79.1. Metodologias Convencionales

79.2. Enfoque de las Pruebas en Metodologias Convencionales

79.2.1. En estas metodologías se presta especial atención a la elaboración de la especificación de requisitos software

79.2.2. Se basa en la definición de los casos de prueba en función de unos requisitos previamente establecidos, mediante los lenguajes adecuados, por ejmeplo XUnit, FIT o similares

79.3. Objetivo de las Pruebas Convencionales

79.3.1. Comprobar que el desarrollo realizado cumple los requisitos definidos.

79.4. Porcentaje de Pruebas Convencionales en Proyectos

79.4.1. 70% de los proyectos desarrollados, disponen de procesos de pruebas documentados

79.4.2. 80% de los proyectos disponen de planes de pruebas detallados, casos de prueba, etc

80. Generación automática de test

80.1. Una ves identificadas las entradas del programa y los tipos de datos entrantes podemos generar tests ligados a dichos valores de forma automática, se presentarán tantos casos de prueba como tipos de entrada halla.

81. Funciona como macros que graba procesos de testeo que pueden varearse para obtener diferentes resultados

81.1. Si lo que varea es el ambiente de pruebas se tiene que volver a grabar un proceso de testeo, esto funge como una debilidad de la arquitectura.

82. Generación a tres pasos (Descritas por Alejandro López) *Anotación de la GUI *Generación Automática de Casos de Prueba *Ejecución y Validación

83. VENTAJAS Se ahorran gastos de manufactura de pruebas por cada módulo ya que con la definición de valores de entrada podemos generar tantos casos como sean necesarios para las pruebas.

84. DESVENTAJAS El elemento puede ahorrarnos tiempo, pero si persisten cambios en los planes de prueba, se tienen que modificar las variables de entrada, esto provoca pequeños retrasos en la implementación del test

85. UNA DEBILIDAD de esta arquitectura es el sistema de ventanas de una aplicación, en caso de ser demasiadas, se torna complicado definir tantos entornos de pruebas como variables a testear en la aplicación.

85.1. Una arquitectura definida para probar GUIs pretende solucionar dicho problema definiendo un conjunto de entradas y funcionando como librería de la cual dispondremos de sus herramientas

86. Pruebas a GUIs Alexis Herrera Ramirez

87. Ejemplo Pruebas Jonathan Alejandro Colin Medina

87.1. Un programa acepta tres enteros que representan las longitudes de los lados de un triángulo. Éste da como resultado “escaleno” (lados no iguales), “isósceles” (dos lados iguales), o “equilátero” (tres lados iguales).

87.1.1. Acciones y datos a probar

87.1.1.1. UN CASO DE PRUEBA CON A,B,C NO NUMERICOS

87.1.1.1.1. UN MENSAJE DE ERROR

87.1.1.2. PARTICIÓN DEL TRIANGULO ESCALENO

87.1.1.3. 2.3.4

87.1.1.3.1. ESCALENO

87.1.1.4. 0,1,2

87.1.1.4.1. UN MENSAJE DE ERROR

87.1.1.5. PARTICION DEL TRIANGULO ISOCELES

87.1.1.6. 2,2,1

87.1.1.6.1. ISOSCELES

87.1.1.7. 2,2,0

87.1.1.7.1. UN MENSAJE DE ERROR

87.1.1.8. 1,1,1

87.1.1.8.1. EQUILATERO

87.1.1.9. 0,0,0

87.1.1.9.1. UN MENSAJE DE ERROR

88. LAS PRUEBAS EN LAS METODOLOGIAS AGILES Oscar Vallejo T.

88.1. Historias de Usuario

88.1.1. Representan de una forma particular los requisitos del sistema

88.2. Metodologías

88.2.1. ATDD

88.2.1.1. Se basa en las pruebas de aceptación. Este enfoque toma como punto de referencia al usuario.

88.2.2. TDD

88.2.2.1. Cada requisito se representa como un artefacto denominado historia de usuario al que se le asocian sus correspondientes pruebas unitarias

88.3. Entornos de Integración Continua

88.3.1. Es necesario disponer de una mínima infraestructura que permita automatizar la ejecución del elevado número de pruebas que se diseñan y la toma de medidas que permitan conocer el nivel de calidad que está alcanzando el desarrollo

88.4. Enfoques Agíles

88.4.1. Las pruebas son el centro de la metodología y, por lo tanto son ellas las dirigen el proceso de desarrollo

88.4.2. Pruebas de Regresion

88.4.2.1. Se realizan despues de anexar una nueva funcionalidad con el fin asegurar que no se ha introducido ningún error nuevo en el sistema

88.5. Responsables de su Aplicación

88.5.1. Los ingenieros de desarrollo los encargados de ejecutar este tipo de pruebas mediante pruebas unitarias

89. Ejemplo de pruebas Mario Valentin Ochoa Mota

89.1. En base al siguiente código en Golang

89.1.1. func Reverse(s string) string { r := []rune(s) for i, j := 0, len(r)-1; i < len(r)/2; i, j = i+1, j-1 { r[i], r[j] = r[j], r[i] } return string(r) }

89.1.1.1. func TestReverse(t *testing.T) { for _, c := range []struct { in, want string }{ {"Hello, world", "dlrow ,olleH"}, {"Hello, 世界", "界世 ,olleH"}, {"", ""}, } { got := Reverse(c.in) if got != c.want { t.Errorf("Reverse(%q) == %q, want %q", c.in, got, c.want) } } }

89.1.1.2. La prueba que es necesaria es comprobar que la cadena que se ingresa se tranformada a su inverso. Gracias a que es un lenguaje tipado no es necesario comprobar el valor de entrada ya que siempre va a ser una cadena

90. Jesús Almaraz