Trataré de ser lo más detallado posible, pero tengan paciencia conmigo aquí, escribo esta respuesta mientras estoy en la oficina 🙂
Si tuviera que dividir su problema en tareas más pequeñas, esto es lo que veo:
1. ¿autenticación a un servicio para obtener un token de acceso para un usuario, supongo?
- ¿Cuál es la mejor manera de crear un sitio web para mi canal de YouTube por menos de $ 40, sin pagar tarifas mensuales o anuales, y sin tener ningún conocimiento de programación?
- ¿Sigue siendo una buena idea aprender desarrollo web en 2017?
- ¿Cuánto gana un desarrollador frontend en una startup en Berlín?
- ¿Qué es un software o sitio web de correo electrónico receptivo que me permite enviar a destinatarios individuales?
- ¿Por qué algunas grandes empresas usan WordPress? Vi que muchos de ellos usan WordPress y quiero preguntar, ¿construyen todo el sitio web con él o solo una página o más?
2. crear usuarios (aquí 10) usando alguna información.
3. recupere “esa” información para validar si los usuarios se crean correctamente.
4. Haga uso de un IDE aquí que desea probar en Eclipse.
Okay. Dejemos de lado a 10 usuarios por ahora, y nos enfocamos en crear un solo usuario y validar si un usuario se creó o no. Si somos capaces de realizar esta tarea con éxito, será más simple hacerlo para los 9 restantes. Además, antes de comenzar a escribir código, diseñar cómo escribir clases, qué herramienta de compilación crear, sugeriría tomarse un tiempo para realizar los pasos anteriores en un cliente REST (en el caso de las extensiones de Google Chrome, obtendrá 2 opciones, “Avanzado REST Client “y” POSTMAN “), hacerlo tiene las siguientes ventajas, dado que por ahora lleva mucho tiempo.
1. Esto le dará una idea clara de cómo será el flujo de su plan de prueba. Esto lo ayudará en la apariencia de su plan de prueba.
2. Si alguno de los servicios “explota”, arroja un error interno del servidor 500, o si realizó una solicitud incorrecta / incorrecta / incorrecta, sabrá qué esperar cuando. Eso también significa qué detalles se requieren y no se requieren para cada servicio.
3. A veces, aunque tenemos suficiente información, o los “documentos API” están “actualizados”, puede terminar usando una API antigua, esto le permitirá confirmar con otros equipos que sus documentos están actualizados y no hay cambios en el contrato. . Confía en mí, esto te ahorrará mucho tiempo.
4. Una vez que sepa cómo se comporta cada API, puede resultarle muy fácil escribir el plan de prueba o, como máximo, ahora sabe qué escenarios es probable que se cubran, que se descarten y cuáles se asuman.
5. Habiendo hecho su tarea, escribir el plan de prueba, será menos doloroso.
6. Tendrás una “prueba” de lo que hiciste, si alguien te pregunta “Oye, ¿cuál es tu proceso de pensamiento para hacer un plan de prueba?” Luego, en ese momento, en lugar de guiarlo por el código, puede mostrarles el flujo en el cliente REST y explicarles su proceso. Puede resultar que les guste, o podrían sugerirle que agregue / elimine llamadas de API no deseadas en ese momento.
7. Siempre puede guardar sus solicitudes y respuestas (creo que en el caso de POSTMAN), para que sea útil encontrarlas / buscarlas en el futuro
Ahora, digamos que ha hecho su parte para trabajar en todas las API en un cliente REST, ahora pasamos a la siguiente sección, en la que intentamos ir en detalle y hablar sobre cómo realizar cada una de las tareas Lo mencioné anteriormente.
Mi primera pregunta es, ¿qué tipo de autenticación está tratando de hacer?
Me refiero a que no ha proporcionado ningún detalle de ese servicio.
- ¿Cómo se ve la API de autenticación?
- ¿Cuál es el verbo HTTP que se usa? será POST, OBTENER?
- ¿Siempre va a ser un caso que primero autentiques y luego pases al siguiente? ¿Qué pasa si primero creo un usuario? ¿Qué pasa entonces? Puede ser una pregunta incorrecta, pero quería plantearla.
- Además, cuando diga autenticar, ¿qué usará para autenticar? ¿hay algún tipo de token para hablar con ese servicio? No entraré en detalles sobre qué tipos de tokens hay disponibles, pero para nombrar algunos hay: JWT (Json Web Token: JWT.IO, token BÁSICO: autenticación de acceso básico, token de portador que también es (corríjame si Estoy equivocado) similar a un JWT, finalmente un token de acceso: token de acceso que requiere una información de inicio de sesión como nombre de usuario / correo electrónico y contraseña)
- ¿Hay algún tipo de combinación de teclas CLIENT_ID o CLIENT_SECRET que se utilizará para autenticar?
- ¿Qué entorno vas a probar esto? ¿Asumo inicialmente una “prueba” y luego una “prueba”?
- ¿Cómo va a responder el servicio? Quiero decir, ¿cuál es el formato de la solicitud y la respuesta es XML? o JSON? Esto determinará qué tipo de analizadores necesitaría usar.
Entonces, esto es lo que voy a hacer, ya que no tengo / tengo realmente menos información, permítame asumir algunas cosas que le explicaré a continuación.
Mirando las preguntas anteriores y las tareas que he mencionado, las siguientes son las cosas que voy a asumir.
1. La API será una llamada POST para autenticar a un usuario o a usted en este caso. Proporcionará un nombre de usuario y contraseña, junto con un SECRETO DEL CLIENTE, y el servicio responderá / deberá responder con una carga que contenga alguna otra información. y la ficha que estás buscando. Yo creo que
No estoy seguro de si lo que escribo después de esto será cierto, ya que estoy haciendo muchas suposiciones. Dado que estamos creando un usuario, esto nuevamente sería una llamada POST a su API de usuario creado. Usando ese token y el cuerpo de la carga útil, que serían detalles del usuario que desea crear, podrá crear el usuario. Si está haciendo esto en un cliente REST, ¿su validación será un código de respuesta correcto (201, 200, etc.) y un cuerpo de respuesta en forma de JSON? que contendrá algunos detalles adicionales del usuario que acaba de crear. Esta sería una verificación mínima que puede realizar para validar que su usuario se haya creado correctamente. Esta es realmente una breve descripción del trabajo real que debe realizar.
Al llegar a la parte de un plan de prueba, no tengo mucha experiencia en escribir un plan de prueba, pero aquí tienes:
Objetivos: validar que el “sistema” pueda autenticarse y luego crear usuarios en entornos de prueba y producción.
Características a probar : servicio de autenticación, crear servicio de usuario
Características que no se probarán :
Enfoque de prueba :
1. autenticar y recuperar un token / una respuesta después de proporcionar detalles válidos (como se mencionó anteriormente).
2. Obtenga el token (si se generó) y luego úselo para proporcionar información / carga útil para crear un servicio de usuario, recuperar una respuesta válida y un código de respuesta.
3. validar la creación del usuario después de verificar si recibió algún campo “obligatorio” en la respuesta, como nombre, correo electrónico, nombre de usuario, token, etc.
El enfoque anterior se puede elaborar, lo mantengo breve. ¿Quizás algo en este sentido puede ayudar? Cómo escribir un plan de prueba
En cuanto a su pregunta sobre Eclipse / uso de un IDE. No “implementa” en Eclipse, usa Eclipse o un IDE con un lenguaje como Java, para implementar su problema. Esto dependería de su equipo, o de sus preferencias personales también. Yo uso IntelliJ, y nuestra base de código está en Scala. Hacemos uso de ScalaTest, Scala para escribir código. No me sumergiré en “simulacros” por ahora por burlarnos del comportamiento de los servicios dependientes / posteriores que utilizamos. Si le preocupa cómo “estructurar” su código, ¿IntelliJ o Eclipse crearán algunas carpetas automáticamente para usted? esto se decidirá una vez que esté configurando su IDE.
Por lo general, la forma de mantener su código y sus pruebas se realizan de la siguiente manera, realmente en términos simples:
src / main / java <: contiene la clase "main" y otras clases para su aplicación, incluidos sus DAO.
src / test / java <: aquí es donde entrará todo el código de prueba.
Aquí hay una instantánea de cómo se ve mi IntelliJ en este momento. Tenga en cuenta que este es un proyecto SBT.
Por lo tanto, para resumir y comenzar, si desea conocer un alto nivel de lo que deberá hacerse. Si es la primera vez que prueba una API REST, sugeriría la siguiente “pila”.
Lenguaje de programación : Java
El conjunto de pruebas que se escribirá usando TestNg (TestNG), para pruebas más descriptivas, también busque SPOCK (Spock Framework Reference Documentation). La ventaja de SPOCK en lo que puedo pensar es que después de escribir un montón de UAT, puede ser tan detallado como sea posible, enumerando cada fase de la prueba.
La herramienta de compilación puede ser Maven (Integración Apache Maven IDE), Gradle (Guía del usuario de Gradle) o SBT. Sugeriría probar con Maven, y luego si quieres probar con SBT, y finalmente Gradle. También me gustaría sugerir que dado que no estoy usando Eclipse, no estoy seguro de cómo funciona cada uno de ellos en el IDE de Eclipse, pero estoy usando los 3 y funcionan bien con IntelliJ.
Necesitará un cliente REST para realizar sus llamadas API REST reales, sugeriría ir con Rest Assured, realmente fácil de usar y escribir pruebas, especialmente las que se le given, when,then formato ayuda a leer la prueba y saber qué está pasando. Además, con el apoyo de Maven y Gradle. Encuentre la documentación aquí: Jayway / Descanse tranquilo
Archivos de configuración para almacenar diferentes tipos de configuraciones según su entorno. Puede consultar: typesafehub / config
Esperemos que el IDE ayude a administrar la estructura de su directorio. Y está listo para escribir algún código. Iré por una ruta más larga y le explicaré qué se puede hacer, puede haber formas mucho mejores de hacerlo.
Tengamos algunos ejemplos de apis enumerados junto con sus solicitudes y respuestas en JSON. Lo sé, esta es una respuesta bastante larga, por favor tengan paciencia conmigo, confíen en mí, esta es la última parte 🙂
1. API para autenticar:
punto final: POST / some / initial / text / authenticate? client_id = & client_secret =
Encabezados de solicitud : Content-Type: application/json, Accept: application/json, add extra headers
Carga útil o cuerpo de solicitud: "{"username":" [email protected] ", "password":"YouG0tMe!"}"
Código de respuesta : 201
Cuerpo de respuesta: {"access_token":"BFGOIWEURWO", "refresh_token":"BHBEUIHr", "some_other_info"}
2. API para crear un usuario
punto final : POST /some/initial/text/createuser?access_token=
Encabezados de solicitud : Content-Type:application/json, Accept: application/json, and some extra headers
Cuerpo de la solicitud : {"name":"foo", "username":" [email protected] ", "address":"foobar", "password":"1234", "details":{"salary":12222, "employer":"abcdxyzx"}}
Código de respuesta : 201
Cuerpo de respuesta : {"id":"", "name":"foo", "username":" [email protected] ", "address":"foobar", "password":"1234", "details":{"salary":12222, "employer":"abcdxyzx"}}
Ahora, la forma de hacerlo en Java, o para decirlo de una manera que hubiera seguido, es utilizar mi experiencia en Java, TestNg y Tenga la seguridad de que intentaré escribir un caso de prueba de muestra usando Java, y Está seguro.
Crearía clases para almacenar las solicitudes y respuestas de cada API. Algunas personas fruncen el ceño al hacer tales clases “serializadas” y deserializadas, creo que se reduce a una preferencia personal, en cuanto a cómo todos quieren usarla.
entonces, en nuestra ruta src / main / java / requestobjects tenemos 2 clases, 1 para el servicio de autenticación y la segunda para el servicio de creación de usuarios. Esos se verán así. Tenga en cuenta que estos pueden cambiar según sus requisitos, estos son solo para fines ilustres.
import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;
class AuthenticationRequest {
String final privado nombre de usuario;
contraseña de cadena final privada;
@JsonCreator
Solicitud de autenticación pública (
@JsonProperty (“userName”) String userName, @JsonProperty (“contraseña”) String password) {
this.userName = userName;
this.password = contraseña;
}
}
clase para createUser
clase UserInfo {
nombre de cadena final privado;
String final privado nombre de usuario;
dirección de cadena final privada;
contraseña de cadena privada final;
Detalles de detalles finales privados
// el constructor va aquí …
}
Detalles de la clase {
// rellena los campos. tienes la idea?
}
Ahora, de manera similar, tendremos en nuestro camino un directorio para almacenar las respuestas.
src / main / java / responseobjects.
continuarás y crearás clases para almacenar las respuestas. Espero que puedas.
Por ejemplo, puede terminar con clases como:
AuthenticateServiceResponse.java
CreateUserResponse.java
Ahora, digamos que se siente cómodo con tener sus propias clases para almacenar solicitudes y respuestas, y ahora, quiere probar el flujo que tiene la intención de hacer, ¡un simple camino feliz que decimos en términos de SWE! es decir, reiterar
1. autenticar
2. crear usuario.
3. verifique si ese usuario está creado.
Tendrás un archivo de prueba. digamos UserCreationFlowTest.java, no te preocupes por las importaciones.
Sí, si observa el nombre de la prueba, le doy a mis pruebas nombres realmente largos. Puedes elegir lo que más te convenga.
import static com.jayway.restassured.RestAssured. *;
import com.jayway.restassured.response.Header;
import com.jayway.restassured.response.Headers;
importar http estático: //com.google.common.net.HttpHeaders.ACCEPT;
importar http estático: //com.google.common.net.HttpHeaders.CONTENT_TYPE;
importar org.testng.Assert;
importar org.testng.annotations.Test;
clase UserCreationFlowTest {
@Prueba
public void GivenCorrectUserDetailsAfterAuthenticationUserShouldBeCreatedTest {
// 1. Configure la solicitud, para hacer para autenticar
// construir uri
String uri = “https://www.testdomain.com/some/initial/text/authenticate?client_id=qwqweewrwerr&client_secret=3445656”;
// configurar encabezados
Private final Map headers = new HashMap ();
headers.put (CONTENT_TYPE, nuevo encabezado (CONTENT_TYPE, “application / json”));
headers.put (ACCEPT, nuevo encabezado (ACCEPT, “application / json”));
// configurar el cuerpo para publicar
AuthenticationRequest authenticate = new AuthenticationRequest (“nombre-usuario-va-aquí”, “contraseña-va-aquí”)
Autenticación AuthenticateResponse = dado ()
.cuando()
encabezados (encabezados)
.body (autenticar)
.post (uri) .then (). log (). all ()
.assertThat ()
.statusCode (201)
.extraer()
.respuesta()
.as (AuthenticateResponse.class, JACKSON_2);
// 2. validar si el autenticado correctamente.
Assert.assertNotNull (autenticar)
Assert.assertNotNull (authenticate.getAccessToken)
// 3. ahora de manera similar, haga la llamada para crear un usuario.
String uri = “https://www.testdomain.com/some/initial/text/createuser?access-token= “;
Encabezados de mapa finales privados = nuevo HashMap ();
headers.put (CONTENT_TYPE, nuevo encabezado (CONTENT_TYPE, “application / json”));
headers.put (ACCEPT, nuevo encabezado (ACCEPT, “application / json”));
UserInfo user = new UserInfo (
“prueba1”,
” [correo electrónico protegido] “,
“contraseña”,
“mi dirección”,
nuevos detalles (“bla”));
CreateUserResponse myUser = given ()
.cuando()
encabezados (encabezados)
.body (usuario)
.post (uri)
.then (). log (). all (). afirmar que (). statusCode (201)
.extract (). response ()
.as (CreateUserResponse.class, JACKSON_2);
// validar usuario creado, si hay un campo dinámico // entrando, como un “id”, valide si está vacío / inválido como:
Assert.assertNotNull (myUser);
Assert.assertNotNull (myUser.getId ());
}
}
Además, por último pero no menos importante:
Es posible que deba configurar los ajustes de proxy en su código antes de llamar al servicio REST. Compruebe si su navegador requiere configurar un proxy para que pueda navegar a cualquiera de los servicios. Si es así, deberá agregar líneas similares a estas en su configuración de prueba:
System.setProperty (“http.proxyHost”, “yourproxyhost”);
System.setProperty (“http.proxyPort”, “yourproxyport”);
donde yourproxyhost y yourproxyport deben reemplazarse con los valores correctos. Si su proxy requiere autenticación, entonces también necesita estos:
System.setProperty (“http.proxyUser”, su usuario proxy);
System.setProperty (“http.proxyPassword”, su contraseñaproxy);
Lo sé, una respuesta realmente muy larga, lo siento mucho por estos lectores, pero espero que te ayude a comenzar 🙂
