Tabla de contenido
Prefacio:
Un marco de prueba automatizado es un enfoque estructurado para organizar y administrar el proceso y los recursos para las pruebas automatizadas. Proporciona un conjunto de especificaciones y herramientas para ayudar a los equipos de prueba a escribir, ejecutar y mantener scripts de prueba automatizados de manera más eficiente.
Capas de marcos de prueba
¿Cómo es un marco de prueba completo?
Por ejemplo, si escribimos casos de prueba de appium, si solo hacemos Demo, usaremos directamente la API de WebDriver para escribir. En este momento, un caso de uso se ve así:
import os
from time import sleep
from appium import webdriver
if __name__ == '__main__':
# Returns abs path relative to this file and not cwd
PATH = lambda p: os.path.abspath(
os.path.join(os.path.dirname(__file__), p)
)
# init driver, open session
desired_caps = {}
desired_caps['platformName'] = 'Android'
desired_caps['platformVersion'] = '4.2'
desired_caps['deviceName'] = 'Android Emulator'
desired_caps['app'] = PATH(
'../../../sample-code/apps/ApiDemos/bin/ApiDemos-debug.apk'
)
driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)
# execute some action
els = driver.find_elements_by_android_uiautomator("new UiSelector().clickable(true)")
# check if result is as expected
if len(els) != 12:
print "Case Failed. There should be 12 elements but only {} elements exist".format(len(els))
else:
print "Case Passed."
# end the session
driver.quit()
Luego, la cantidad de casos de uso es relativamente grande, es demasiado problemático iniciar appium en cada caso y los resultados de las pruebas no son lo suficientemente buenos, por lo que comenzamos a usar algunos marcos de pruebas unitarias, usando sus informes de configuración, desmontaje o prueba. En este punto, el caso de uso se verá así:
import os
from time import sleep
import unittest
from appium import webdriver
# Returns abs path relative to this file and not cwd
PATH = lambda p: os.path.abspath(
os.path.join(os.path.dirname(__file__), p)
)
class SimpleAndroidTests(unittest.TestCase):
def setUp(self):
desired_caps = {}
desired_caps['platformName'] = 'Android'
desired_caps['platformVersion'] = '4.2'
desired_caps['deviceName'] = 'Android Emulator'
desired_caps['app'] = PATH(
'../../../sample-code/apps/ApiDemos/bin/ApiDemos-debug.apk'
)
self.driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps)
def tearDown(self):
# end the session
self.driver.quit()
def test_check_clickable_element_count(self):
els = self.driver.find_elements_by_android_uiautomator("new UiSelector().clickable(true)")
self.assertEqual(12, len(els))
if __name__ == '__main__':
suite = unittest.TestLoader().loadTestsFromTestCase(SimpleAndroidTests)
unittest.TextTestRunner(verbosity=2).run(suite)
Más adelante, escribiremos más casos de uso, y las pocas personas que realizan pruebas automatizadas por sí solas no pueden soportarlo. Necesitamos dejar que algunas personas que no son tan fuertes en tecnología lo hagan. Para que sean fáciles de usar sin estropear nuestro marco, volveremos a empaquetar los casos de uso y los convertiremos en tablas o BDD, que las personas que no saben codificar pueden escribir y leer más fácilmente. En este punto, el caso de uso se verá así (Pepino):
Feature: Simple android test
Do some sample operations with android application
Scenario: Check clickable element count
When I opened the application
Then 12 clickable buttons should occur
Estos tres pasos en realidad corresponden a los tres niveles del marco de prueba: la capa de herramienta (como appium), la capa central (como el marco de prueba unitaria) y la capa de adaptación (como el marco BDD)
capa de herramientas
La capa de herramientas es la principal responsable de la activación de la acción de la ejecución de la prueba en el lado correspondiente. (Texto original en el libro)
En primer lugar, si queremos controlar algunos programas probados a través de programas, debemos tener las herramientas correspondientes. Estas herramientas hacen posibles controles que de otro modo serían difíciles o incluso imposibles de lograr, al mismo tiempo que los hacen más fáciles de lograr. Por ejemplo, UIAutomation para iOS. Si no existe, debemos agregar algunos agentes (como MonkeyTalk) a la aplicación, o agregar directamente código de prueba (como KIF) a la aplicación, o incluso crear un conjunto de herramientas de prueba que puedan controlar el programa a través de la interfaz. . Estas herramientas nos permiten ahorrar mucho tiempo y facilitan la separación de la parte de prueba de la parte funcional.
Hay muchos marcos para la capa de herramientas, como Appium, robotium, espresso, etc. para pruebas móviles y Selenium para pruebas web.
capa central
La capa central es responsable de impulsar la ejecución de la prueba y el seguimiento y la retroalimentación de los resultados. (Texto original en el libro)
Los programas de prueba automatizados en realidad tienen algunas cosas en común, por ejemplo, todos necesitan un soporte rico en funciones de aserción, de lo contrario, solo pueden escribir varios If..else.., y luego los pasos de verificación y ejecución se combinan. Esto es lo que hace el marco en la capa central: extrae las características más comunes de los programas, como los programas de prueba automatizados (por ejemplo, las excepciones especiales deben corresponder a fallas, deben crearse varias aserciones flexibles y convenientes, y deben establecerse condiciones previas). funciones especiales), y luego encapsularlas en una forma de escritura relativamente fija.
Por ejemplo, la mayoría de los casos de uso tendrán condiciones previas (por ejemplo, los casos de uso web requerirán que el navegador esté abierto), serán muy repetitivos y tendrán las características de bloques (si no se abre el navegador, los pasos posteriores no se ejecutarán). ser ejecutado). Luego, el marco de trabajo de la capa central proporcionará un método especial (el método general se llama configuración), permita que este método se ejecute antes de ejecutar el contenido del caso de uso para crear una condición previa adecuada, y colocará automáticamente todo el caso de uso cuando este método falle o falla Marcar como falla o bloqueo.
También hay muchos marcos en la capa central, como varios marcos de pruebas unitarias (JUnit, OCUnit, etc.), Testng, etc. En términos generales, después de seleccionar el marco utilizado por la capa de herramientas, se determinará el idioma utilizado, por lo que la capa de herramientas generalmente se determina primero y luego se selecciona el marco utilizado por la capa central. Si los idiomas son inconsistentes, se requiere un desarrollo secundario apropiado para facilitar la llamada. Por supuesto, los marcos de la capa de herramientas como appium/selenium que admiten varios idiomas pueden elegir los marcos de la capa central de manera más flexible, lo que también es una razón importante de su popularidad.
capa de adaptación
La capa de adaptación es responsable de la adaptación del paquete de métodos de prueba reutilizables. (Texto original en el libro)
Cuando los casos de uso alcanzan un cierto orden de magnitud (decenas o centenas), si las partes repetidas no se extraen bien o no se escriben mejor, aparecerá una cierta cantidad de código redundante. En este momento, el papel de la capa de adaptación es encapsular mejor estos métodos repetidos, para que aquellos que escriben casos de uso puedan escribir/leer casos de uso más rápidamente.
La mayoría de los datos, las palabras clave y el comportamiento (BDD) que solemos escuchar pertenecen a esta capa. Porque no importa qué controlador se use, no tiene nada que ver con el programa de prueba/dominio de prueba específico. No diría que BDD solo se puede usar para probar aplicaciones de Android, ni que los controladores de datos solo se pueden escribir en Java. Estos controladores xx son principalmente una idea, una idea de escritura de casos de uso que es fácil de usar en la práctica, práctica y tiene muchas herramientas para elegir. Por supuesto, debido a las diferentes herramientas utilizadas, el lenguaje utilizado también tendrá ciertas restricciones, pero las ideas son las mismas.
La capa de adaptación también tiene varios marcos, como Cucumber de BDD, un marco de robot basado en palabras clave (también tiene una capa central y una capa de herramientas, que es un marco de prueba completo y práctico, y su capa de herramientas tiene la forma de un extenso Biblioteca proporcionada, muy fácil de expandir para adaptarse a diferentes campos de software, vale la pena aprender). Dado que el método de escritura de la capa de adaptación probablemente no pertenezca a un lenguaje de programación específico (como el basado en palabras clave utilizando la forma de una tabla, que está separada del lenguaje), la mayoría de los marcos de la capa de adaptación tendrán un lenguaje de programación correspondiente. capa central/capa de herramientas El marco proporciona soporte integrado.
un ejemplo sencillo
Creo que muchas personas han usado el marco de robot. Es un marco de prueba completo con estas tres capas:
Capa de adaptación : los casos de uso se escriben en formato tsv, que se basa principalmente en palabras clave.
Capa central : proporciona métodos de configuración y desmontaje, y tiene funciones de aserción adecuadas y suficientes y funciones de captura de excepciones.
Capa de herramientas : hay muchas bibliotecas para elegir, que se pueden combinar con diferentes herramientas para probar el software en varios campos.
Otro ejemplo sencillo
Otro ejemplo es una implementación de un marco basado en palabras clave:
Capa de adaptación : casos de uso presentados en forma tabular y convertidores que convierten casos de uso en código ejecutable:
hoja:
| acción | parámetros |
|---|---|
| navegador abierto | browserName="Cromo" |
Código convertido:
class TestCase(ActionBase, unittest.TestCase):
# a test case
def open_browser(self):
# step of test case
self.action_call("openBrowser", {"browserName":"Chrome"})
Luego, la implementación de esta action_call llama al método de acción correspondiente para realizar la acción real:
class ActionBase:
...
def action_call(action_name, params):
# get action function in this class
action_fun = getattr(self, action_name)
# execute action
action_fun(**kwargs)
...
def openBrowser(browserName=None):
if browserName == 'Chrome':
self.driver = webdriver.Chrome()
...
Capa central : el código convertido utiliza el marco unittest para gestionar la ejecución de casos de uso
Capa de herramientas : el marco de selenio se usa cuando la acción se ejecuta realmente
Como alguien que ha estado aquí, también espero que todos eviten algunos desvíos.
Aquí compartiré contigo algunas necesidades del camino a seguir en las pruebas automatizadas, con la esperanza de ayudarte.
(materiales relacionados con pruebas de software, materiales relacionados con pruebas automatizadas, preguntas y respuestas técnicas, etc.)
¡Creo que puede hacerte progresar mejor!
Haga clic en la pequeña tarjeta de abajo
