Te damos la bienvenida a nuestro espacio, aquí vas a hallar la solucíon que buscas.
Solución:
Visión general
Piense en una palabra clave como un único paso de prueba. Así como una prueba se compone conceptualmente de muchos pasos, una prueba de robot se compone de muchas palabras clave. Las palabras clave son la base sobre la que se basan todas las pruebas de robots.
Hay palabras clave genéricas proporcionadas por robot, y hay palabras clave de propósito especial que puede crear usted mismo. El verdadero poder del marco del robot es cuando crea sus propias palabras clave para que las pruebas se puedan centrar en la lógica de la prueba en lugar de en la implementación subyacente.
Por ejemplo, consideremos lo que podría ser una prueba de aceptación para iniciar sesión en su servidor. Desde la perspectiva de un propietario de producto ágil o diseñador líder, podría verse así:
- ¡Abra un navegador en Super Website 2000!
- Ingrese un nombre de usuario válido
- Ingrese una contraseña válida
- Haga clic en el botón “Ir”
- Deberías estar en la página del panel
Esto podría ser literalmente lo que el propietario del producto agrega como criterio de aceptación en una tarjeta de historia o en un sistema de seguimiento de tickets. ¿No sería bueno si esa fuera una prueba real que alguien pudiera ejecutar?
Caso de prueba de ejemplo
Cada uno de esos pasos podría considerarse una palabra clave. Una de las mejores cosas del robot es que puede escribir una prueba que parezca casi idéntica a la especificación original:
*** Test Cases ***
Login of an existing customer
[Setup] Open a browser to Super Website 2000!
[Teardown] close all browser windows
Enter a valid username
Enter a valid password
Click the GO button
You should be on the dashboard page
Ejemplo de implementación de palabras clave
Para que se ejecute este caso de prueba, deberá definir estas palabras clave, ya que el robot no sabe qué es “¡Abrir un navegador en Super Website 2000!” medio. Puede escribirlos en Python o en varios otros lenguajes, o puede escribirlos combinando palabras clave existentes.
Por ejemplo, las primeras palabras clave podrían implementarse usando palabras clave de Selenium2Library como esta:
*** Settings ***
Library Selenium2Library
*** Variables ***
$ROOT http://super.website2000.com
$BROWSER chrome
*** Keywords ***
Open a browser to Super Website 2000!
# this is a pre-defined Selenium2Library keyword
Open browser $ROOT $BROWSER
Enter a valid username
# these are pre-defined Selenium2Library keywords
wait until element is visible id=username_input
input text id=username_input Test User #1
Enter a valid password
# these are pre-defined Selenium2Library keywords
wait until element is visible id=password_input
input text id=password_input LetMeIn!
Como puede ver, puede usar palabras clave para crear casos de prueba muy legibles. Las palabras clave se pueden diseñar utilizando otras palabras clave, o puede escribir palabras clave en un lenguaje de programación.
Ejemplo alternativo sin palabras clave personalizadas
Por supuesto, no tiene que escribir palabras clave como esta. Puede usar las palabras clave de Selenium2Library directamente en su prueba, lo que haría que su prueba se viera así:
*** Test Cases ***
Login of an existing customer
[Setup] Open browser $ROOT $BROWSER
[Teardown] close all browsers
wait until element is visible id=username_input
input text id=username_input Test User #1
wait until element is visible id=password_input
input text id=password_input LetMeIn!
wait until element is enabled id=submit_button
click button id=submit_button
wait until element is visible id=//div[@class='dashboard']
location should be $ROOT/dashboard
Personalmente creo que la primera versión de la prueba es mucho más legible, a costa de tener que mantener algunas palabras clave personalizadas.
Ventajas de las palabras clave personalizadas
Al usar palabras clave, puede ocultar los detalles de la implementación de la página web para que pueda concentrarse en la lógica de la prueba. Además, varias pruebas pueden reutilizar las mismas palabras clave.
Los detalles reales de la implementación (ID de elementos, URL, etc.) se pueden incrustar en las palabras clave. Si estos detalles cambian, no es necesario que cambie ninguno de sus casos de prueba. En su lugar, cambia las palabras clave y sus pruebas continuarán ejecutándose. Imagínese si los desarrolladores cambiaran los identificadores de la entrada a username_form_field y password_form_field – ¿Desea editar todos los casos de prueba que deben iniciar sesión o desea editar una o dos palabras clave que comparten todas las pruebas?
Variables
Las variables en el marco del robot son muy poderosas. Por ejemplo, puede definir la URL raíz de su sitio en un solo lugar en lugar de codificarla en cada prueba. Para la mayoría de los sitios de producción, debe ejecutar pruebas con dos, tres o incluso más URL. Por ejemplo, puede tener una caja de desarrollo local, una caja qa, una caja de preparación y una caja de producción.
Robot le permite anular variables en la línea de comandos o en archivos de argumentos. Eso significa que puede crear un conjunto de pruebas que funcionen en varios sistemas. Por ejemplo, para ejecutar sus pruebas usando firefox en la puesta en escena, puede hacer esto (dividir en varias líneas para mayor claridad):
$ pybot
--variable ROOT:http://staging.example.com
--variable BROWSER:firefox
/path/to/tests
Para ejecutar exactamente las mismas pruebas en QA1 con Chrome, puede hacer esto:
$ pybot
--variable ROOT:http://qa1.example.com
--variable BROWSER:chrome
/path/to/tests
Bibliotecas
En pocas palabras, las palabras clave se organizan en bibliotecas. Robot viene con muchas bibliotecas y hay muchas más disponibles en Internet.
Las bibliotecas se pueden escribir en la sintaxis de robot como en estos ejemplos, pero las bibliotecas también se pueden escribir en lenguajes de programación como Python y Java. el uso de un lenguaje de programación hace posible realizar una lógica compleja, el uso del lenguaje del robot le permite combinar más fácilmente las palabras clave existentes en nuevas palabras clave.
Palabras clave en un entorno ágil
Si está trabajando en un equipo de scrum, el enfoque basado en palabras clave puede ayudar al equipo a volverse muy eficiente. Por ejemplo, si sus evaluadores no son muy hábiles, los desarrolladores pueden crear una biblioteca de palabras clave para interactuar con la prueba, de modo que los evaluadores no tengan que preocuparse por los detalles de la página.
Por otro lado, si tiene probadores altamente técnicos, pueden asumir la tarea de escribir las palabras clave ellos mismos para que los desarrolladores puedan dedicar más tiempo a trabajar en el producto real.
En ambos escenarios, el enfoque basado en palabras clave permite que los equipos de control de calidad y de desarrollo trabajen juntos para crear un producto de alta calidad.
La otra respuesta es muy buena y precisa para el cuerpo de la pregunta: para las pruebas de aceptación del usuario, las pruebas basadas en el comportamiento, eso es absolutamente cierto.
Me gustaría dar un ángulo ligeramente diferente: las palabras clave son análogas a las funciones / métodos en la programación de software.
Cuando hablo con desarrolladores u otras personas técnicas, siempre me ha ayudado decir que “las palabras clave son solo funciones” y eso establecería el contexto correcto para charlas en profundidad. Para aprovechar uno de los ejemplos anteriores, esta palabra clave de Robotframwork:
Enter a valid username
# these are pre-defined Selenium2Library keywords
wait until element is visible id=username_input
input text id=username_input Test User #1
se vería casi igual que un método de Python en POM (o java, o c #, o lo que sea):
def enter_a_valid_username(self):
self.driver_instance.wait_until_element_is_visible('id=username')
self.driver_instance.input_text('id=username_input', 'Test User #1')
Pasar valores a una palabra clave es llamar a una función con argumentos, y también recuperar un valor:
Attempt to login with user and password
[Documentation] Enters the provided user and password, clicks the "Login" button, and returns boolean True/False is the user logged in.
[Arguments] $user $pass
wait until element is visible id=username_input
input text id=username_input $user
input text id=password_input $pass
click button id=submit_button
$success= Run Keyword And Return Status Dashboard Page Should Be Opened
[Return] $success
El análogo como método:
def attempt_login(self, user, pass):
self.driver_instance.wait_until_element_is_visible('id=username')
self.driver_instance.input_text('id=username_input', user)
self.driver_instance.input_text('id=password_input', pass)
self.driver_instance.click_button('id=submit_button')
try:
self.dashboard_is_opened()
return True
except IncorrectPageException:
return False
Es necesario enfatizar que las palabras clave creadas en la sintaxis de Robotframework son funciones, no métodos; no son parte de un objeto que almacena el estado, por lo que su comunicación cruzada es a través de variables compartidas en el alcance actual; esto empuja a la programación procedimental, no orientada a objetos.
La belleza de Robotframework realmente brilla cuando las palabras clave van a abstracciones de nivel superior, por ejemplo, la palabra clave de nivel superior. The account is terminated tiene en su implementación llamadas a las palabras clave The account is not present in the Users page y No DB record for the account, cada uno de ellos con llamadas de palabras clave de nivel inferior y inferior.
The account is terminated
|
--> | The account is not present in the Users page
| --> | Go to the Users page
| --> | $location= Get Location
| | | Run Keyword If '$location' != '$url users page' Go To '$url users page'
| | | The Users Page Is Opened
| | --> | # checks the currently opened page is Users
| | | ...
| | $users= Get All Users
| | ...
|
--> | No DB record for the account
| $users= Get All DB Accounts
| --> | Connect To The DB
| | $DB data= Execute Query SELECT * FROM users; # etc
| | ...
| Should Not Contain $users $the user msg=The user is still present!
Esto ayuda enormemente a la mantenibilidad, los cambios de implementación y la depuración, mientras que al mismo tiempo el uso de nivel superior permanece sin cambios; Este enfoque también es una propiedad de un buen diseño de software, lo que ayuda a transmitir la analogía de las palabras clave son funciones a los desarrolladores de software.
Te mostramos las reseñas y valoraciones de los lectores
Si guardas alguna desconfianza o disposición de prosperar nuestro artículo puedes ejecutar una apostilla y con mucho gusto lo ojearemos.