Pruebas y Validación de Software

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Pruebas y Validación de Software por Mind Map: Pruebas y Validación de Software

1. PRUEBAS EN METODOLOGÍAS ÁGILES

1.1. Pruebas relacionadas:

1.1.1. TDD

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

1.1.2. ATDD

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

1.1.3. STDD

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

2. Diferencia entre las pruebas para la calidad

2.1. Pruebas para el aseguramiento de calidad

2.2. Pruebas de mejoramiento de calidad

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

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

3.2. Riesgos relacionados con versiones anteriores.

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

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

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

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

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

6. OSWALDO RODRÍGUEZ

7. Ángel Guillermo Hernández Zambrano

8. Pre-condiciones

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

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

9.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.

9.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.

9.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.

9.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.

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

9.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.

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

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

9.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.

9.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.

9.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.

9.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.

9.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.

9.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.

10. Diseño de alto nivel

11. Diseño de bajo nivel

12. Código

13. Software ejecutable

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

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

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

17. Pruebas de caja negra

18. 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

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

19. 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

20. Pruebas de caja blanca

21. Programas de Pruebas automatizadas

22. 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

23. Casos de prueba

24. BASE DE PRUEBA

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

24.1.1. REQUISITO

24.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)

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

24.1.2. INCIDENCIA

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

24.1.3. POLÍTICAS DE PRUEBAS

24.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)

24.1.4. DATOS DE PRUEBA

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

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

24.1.5. OBJETIVO DE PRUEBA

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

25. Plan de pruebas de aceptación

26. 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

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

28. Prueba fallida

29. 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

30. Test frameworks

31. 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

32. Equipo de pruebas

33. 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

34. Prueba exitosa

35. 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

36. Equipo de aseguramiento de calidad

37. 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

38. Regulaciones - Gustavo García Sánchez

38.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)

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

39.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)

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

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

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

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

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

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

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

40.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)

41. Defectos - Gustavo García Sánchez

41.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)

42. Arquitectura Open-HMI Tester

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

43. Generación automática de test

43.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.

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

44.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.

45. 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

46. 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.

47. 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

48. 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.

48.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

49. Pruebas a GUIs Alexis Herrera Ramirez

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

51. Pruebas en el Software Ricardo Ascencio F

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

51.2. Pruebas en las GUI

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

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

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

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

52.1. Requisitos ->

52.1.1. Análisis y diseño ->

52.1.1.1. Implementación ->

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

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

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

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

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

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

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

57. Existen infinitas formas de probar un sistema terminado

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

59. 3 .Implementacion de las Pruebas

60. 4. Evaluación de Pruebas

61. 5. Cierre de las Pruebas

62. 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.

63. Condiciones

64. 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.

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

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

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

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

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

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

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

67. 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

68. 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.

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

69.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.

69.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.

69.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

69.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

69.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

69.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

69.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

70. 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.

71. Pruebas de Software Miguel Kevin Rodriguez M.

71.1. Prueba de Estabilidad

71.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.

71.2. Prueba de Carga

71.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.

71.3. Pruebas de regresion

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

71.4. Prueba de Estres

71.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

71.5. Prueba de Portabilidad

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

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

72.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.

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

73.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.

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

73.2. uUNA

73.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.

73.3. Data Model Manager. Alejandro García Barajas

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

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

74.1.1. Elementos

74.1.1.1. Casos de uso

74.1.1.1.1. Describe el comportamiento de la GUI.

74.1.1.2. Anotaciones

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

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

74.1.2. Fases

74.1.2.1. Anotación de la GUI

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

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

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

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

74.1.2.3. Ejecución y validación

74.1.2.3.1. Ejecuta los casos de prueba del paso anterior.

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

75. 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.

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

75.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.

76. 2 . Análisis y diseño

77. Interfaces Gráficas de Usuario (GUI)

78. Arquitectura OHT. Alejandro García Barjas

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

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

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

82. 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

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

83.1. Sentencias

83.2. Desiciones

83.3. Condiciones

83.4. Desición/Condición

83.5. Multiple desición

83.6. Toda p

84. Pruebas de ALTO NIVEL Berenice Villafuerte Zavala

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

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

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

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

85. 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

85.1. Pru

86. PRUEBAS EN ENFOQUES CONVENCIONALES Oscar Vallejo T.

86.1. Metodologias Convencionales

86.2. Enfoque de las Pruebas en Metodologias Convencionales

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

86.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

86.3. Objetivo de las Pruebas Convencionales

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

86.4. Porcentaje de Pruebas Convencionales en Proyectos

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

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

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