Quality Control of the software using
automated testing of integration and unit tests.
Santiago Viteri Arias.[1], Tatiana Mayorga Soria.
Recibido: 13-03-2017 =
/ Revisado: 10-05-2017 Aceptado: 11-06-2018/
Publicado: 01-07-2018
Currently test=
ing
to control the quality of software development is the most important proces=
s,
if the goal is to automate institutional processes, so it requires more care
and dedication in this phase. In the field of tests there are several manual
ways to perform tests on a software product, although when running automated
tests this process is done more efficiently and quickly. In the present
investigation a comparative analysis of Automated Tests of Integration and =
Unit
Tests will be carried out to investigate and analyze the best quality
management, time and resources that are used at the time of testing a softw=
are
product, to be able to apply the automated tests. has many tools, however o=
ne
of the most used is the construction of test cases where we can define
conditions on the different methods and thus assess whether they are correc=
t or
not, so that corrections can be established in time, for this we will have =
the
Visual Studio tool In Mvc, TestAgent
Management and a Management application in MVC to which the corresponding t=
ests
will be made
Keywords: Automated Te=
sts,
Unit Tests, Software, Quality.
En la actualidad=
las
pruebas para controlar la calidad en el desarrollo de software es el=
proceso más importan=
te,
si el objetivo es automatizar procesos institucionales, por lo que requiere=
más
cuidado y dedicación en esta fase. En el campo de pruebas existen varias fo=
rmas
manuales de realizar ensayos a un producto software, aunque al ejecutar pru=
ebas
automatizadas este proceso se realiza más eficiente y rápidamente. En la
presente investigación se realizará un análisis comparativo de Pruebas
Automatizadas de Integración y Pruebas Unitarias para investigar y analizar=
la
mejor administración de calidad, tiempo y recursos que se utilizan al momen=
to
de realizar pruebas de un producto software, para poder aplicar las pruebas automatizadas se tiene m=
uchas
herramientas, sin embargo una de las más utilizadas es la construcción de c=
asos
de prueba donde podremos definir condiciones sobre los diferentes métodos y=
así
evaluar si son correctos o no, de forma que se pueda establecer correccione=
s a
tiempo, para esto se contará con la herramienta Visual Studio En Mvc, TestAgent Management=
y una
aplicación de Gestión en MVC a la cual se le harán las pruebas
correspondientes.
Palabras
Claves: Pruebas
Automatizadas, Pruebas Unitarias, Software, Calidad.
Introducción.
La intervención humana =
para
realizar pruebas a los productos software, antes de entrar a producción,
verifican si las interfaces son amigables, que tan intuitiva es la aplicaci=
ón,
que tan placentera es la experiencia de usuario. Sin embargo, en las pruebas
manuales son más propensas a constantes errores, por ello se deben hacer má=
s de
una vez las pruebas, y, si es un sistema de varios módulos se consumen mucho
tiempo y recursos. Las pruebas automatizadas es un elemento clave para
garantizar la calidad, descartar inconsistencias y errores humanos de un
producto software. Son realizadas por una computadora [1].
Las pruebas unitarias se ejecutan
para comprobar el funcionamiento de los elementos de más bajo nivel de nues=
tro
programa, puede ir desde probar el funcionamiento de una clase, hasta el
funcionamiento de un método en particular[2].Las pruebas de integración son más complejas que las unitarias, es=
tás
están destinadas a comprobar el funcionamiento de dos o más componentes en =
el
sistema y la forma en la cual funcionan en conjunto, de ahí su nombre, ya q=
ue
si bien una clase puede funcionar adecuadamente por sí sola, luego al unirl=
a a
otra clase se pueden generar diversos problemas que debemos tener bajo cont=
rol
antes de pasar a producción. [3]
La calidad del software es el conjunto de cualidades que lo
caracterizan y que determinan su utilidad y existencia. La calidad es sinón=
imo
de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,
portabilidad, usabilidad, seguridad e integridad. [4]
Pruebas
manuales son muy complejas y poco eficientes en el uso =
del
tiempo y los recursos, desde hace un tiempo se maneja el esquema de pruebas automatizadas, esto se
presenta de forma muy útil ya que en vez de pasar horas y horas pantalla tr=
as
pantalla, con solo correr un comando podremos obtener resultados de forma
inmediata y sin errores.
Las pruebas desde sus inicios han requerido el factor humano, sin
embargo, esto conlleva mucho tiempo y esfuerzo ya que debemos en primer lug=
ar
hace los diferentes casos que vamos a probar, establecer un listado de
parámetros y mantenerlos por si ocurre un error poder detectarlo.
Pero no solo eso al mom=
ento
de estar haciendo una prueba de forma manual podemos equivocarnos sin
darnos cuenta, ya que como seres humanos estamos propensos a errores
constantemente, aparte que si debemos probar un sistema de 20 o 30 módulos
probablemente un día no sea suficiente.
Ahora aunque todo parez=
ca
desventajas, las pruebas manuales=
son muy buenas para detectar otro tipo de situaciones, por ejemplo podemos
evaluar de forma personal si las interfaces son amigables, que tan intuitiv=
a es
la aplicación, que tan placentera es la experiencia de usuario, estos casos=
si
son ideales para hacerlos de forma manual ya que es casi imposible que un
programa de computadora nos pueda dar este tipo de información, sin embargo=
con
algunas aplicaciones estadísticas se pueden obtener indicadores sobre el te=
ma.
Se hará a un proyecto ya
elaborado en el cual se va utilizar las pruebas automatizadas para investig=
ar y
optimizar las pruebas en un proyecto.
Para realizarlo, se
utilizará visual studio y un proyecto en mvc realizado en el programa antes dicho.
Las
pruebas desde sus inicios han requerido el factor humano, esto conlleva muc=
ho
tiempo y esfuerzo ya que debemos en primer lugar hace los diferentes casos =
que
vamos a probar, establecer un listado de parámetros y mantenerlos por si oc=
urre
un error poder detectarlo [5]. Ahora aunque todo parezca desventajas, las
pruebas manuales son muy buenas para detectar otro tipo de situaciones, por
ejemplo podemos evaluar de forma personal si las interfaces son amigables, =
que
tan intuitiva es la aplicación, que tan placentera es la experiencia de
usuario, estos casos si son ideales para hacerlos de forma manual ya que es
casi imposible que un programa de computadora nos pueda dar este tipo de
información, sin embargo con algunas aplicaciones estadísticas se pueden
obtener indicadores sobre el tema.
Son
las que se ejecutan sin la necesidad de la ayuda del hombre, cuando alguna
prueba falla debe enviar una alarma para poder tomar las medidas necesarias,
jamás se debe proseguir en el desarrollo si se tiene alguna alerta hasta la
entrega o peor aún si entraría en producción dentro de estas podemos encont=
rar
muchas pruebas pero principalmente se tiene las unitarias y las de integrac=
ión.
[6]
Pruebas Automatizadas de Integrac=
ión.
Son las pruebas más inteligentes ya que ayudan a
determinar si la integración de los datos es correcta y segura. Tener
automatizadas estas pruebas son la forma más segura de de
mejorar la calidad y sobre todo acelerar el desarrollo.
Es como se comprueba el normal funcionamiento del código dentro de un programa, para la detección inmediata de defectos en métodos, mejor diseńo detallado = de la arquitectura. Código estructurado y menos complejo, documentación acorde= a la realidad del aplicativo el tiempo invertido en el mantenimiento de la evolución. Dentro de este proceso el costo de las actividades influye en el resultado final ya que las pruebas unitarias sugieren que se debe probar lu= ego de codificar mediante un debug del código. [2]<= o:p>
Pruebas manual=
es
son muy complejas y poco eficientes en el uso del tiempo y los recursos, de=
sde
hace un tiempo se maneja el esquema de pruebas automatizadas, esto se prese=
nta
de forma muy útil ya que en vez de pasar horas y horas pantalla tras pantal=
la,
con solo correr un comando podremos obtener resultados de forma inmediata y=
sin
errores, En lo que difieren estas dos pruebas es en tiempo de realización. =
Pero no solo eso al momento de estar haciendo una
prueba de forma manual podemos equivocarnos sin darnos cuenta, ya que como
seres humanos estamos propensos a errores constantemente, aparte que si deb=
emos
probar un sistema de 20 o 30 módulos probablemente un día no sea suficiente=
.
Se
procede a detallar los resultados de las pruebas de rendimiento entre las
Pruebas Automatizadas de integración, pruebas unitarias y humanas.
Para
realizar estas pruebas se empleó la versión 14.0.25431.01 Update
3 del Visual Studio Enterprise, ASP.NET Framework versión 14.1.11107.0 para=
el
modelo de desarrollo web MVC y una base de datos SQL en Microsoft SQL server
2012 instalados en un equipo con Windows 10 de 64 bits con 4 GB de memoria =
RAM.
Las
pruebas se utilizaron el Marco de pruebas MSTest con
sus respectivas clases y métodos.
Las
pruebas se hicieron para las cuatro operaciones: inserción, actualización y
borrado.
Para comparar la eficiencia de los diferentes ti=
pos
de pruebas automatizadas se empleó 4 modelos con sus respectivos controlado=
res
y vistas.
Para
las operaciones CRUD se usaron los siguientes módulos:
En la primera prueba se insertó datos mediante el
controlador de cada modelo, a una base de datos vacía y se tomó el tiempo q=
ue
se demoró en realizar la operación.
Para la ejecución de las pruebas del CreateTest se
utilizó el siguiente código.
|
public void CreateCliente() { CLIENTEController
controller =3D new CLIENTEController(); using (var { Assert.IsNotNull(controller.Cr=
eate(new
Models.CLIENTE() { CLI_NOM=
BRE =3D
"Santiago", CLI_TEL=
EFONO
=3D "0999999999", CLI_COR=
REO =3D
"csviteri1@espe.edu.ec", })); } } |
Para crear las pruebas unitarias se usa el siguien=
te
código
El
tiempo resultante en segundos de las pruebas unitarias, incluyendo el prome=
dio
final de la operación de inserción mediante el método =
CreateTest()
Tabla 1=
. Resultados de la operación inserción mediante el
método CreateTest
|
|
Tiempo en Segundos |
||
|
Registros |
Prueba 1 |
Prueba 2 |
Promedio |
|
Cliente |
0,082 |
0,040 |
0,061 |
|
Editorial |
0,033 |
0,018 |
0,025 |
|
Compra |
0,099 |
0,064 |
0,082 |
|
Libro |
0,019 |
0,07 |
0,045 |
Elaborado por: Grupo de
investigación.
Para realizar las pruebas de integración se realiz=
ó las
operaciones CRUD.
En la primera prueba se insertó datos mediante
interfaz gráfica UI Test, a una base de datos local vacía y se tomó el tiem=
po
que se demoró en realizar la operación.
Para la
ejecución de las pruebas del CreateTest se util=
izó el
siguiente código.
|
[TestMethod=
]
[DataSource("Microsoft.VisualStud=
io.TestTools.DataSource.CSV",
"|DataDirectory|\\Users.csv", "=
;Users#csv", DataAccessMet=
hod.Sequential),
DeploymentItem("Users.csv")]
public void
{ =
this=
.UIMap.RecordedMethodCreateNew(); =
this.UIMap.AssertMethodCreateViewOpened(); =
var uiCreate =3D
this.UIMap.UIIndexCodedUItestautoWindow.UICreateCodedUItestautDocument; =
this.UIMap.RecordedMethodCreateParams.UIFirst=
NameEditText
=3D TestContext.DataRow[Nombre"].ToString(); =
this.UIMap.RecordedMethodCreateParams.UILastN=
ameEditText
=3D TestContext.DataRow["Apellido"].ToString(); =
this.UIMap.RecordedMethodCreateParams.UIEmail=
EditText
=3D TestContext.DataRow["Email"]. =
this.UIMap.RecordedMethodCreateParams.UIDateO=
fBirthEditText
=3D TestContext.DataRow["telefono"].ToString(); =
this.UIMap.RecordedMethodCreate(); =
var uiIndex =3D
this.UIMap.UIIndexCodedUItestautoWindow.UIIndexCodedUItestautoDocument; |
Tabla
2. Resultados de la operación inserción en los Test =
de
Integración.
|
|
Tiempo en Segundos |
||
|
Registros |
Prueba 1 |
Prueba 2 |
Promedio |
|
Cliente |
0,41 |
0,38 |
0,395 |
|
Editorial |
0,46 |
0,37 |
0,415 |
|
Compra |
0,42 |
0.36 |
0.39 |
|
Libro |
0,38 |
0.39 |
0,385 |
Elaborado por: Grupo de investigación.
Para las operaciones de inserción los resultados=
se
muestran en la Figura 1.
Figura 1.
Resultados de las pruebas de inserción
Elaborado por: Grupo de investigación.
En la segunda prueba se actualizo datos mediante el
controlador de cada modelo, a una base de datos y se tomó el tiempo que se demoró en
realizar la operación.
Para la ejecución de las pruebas del EditTest se utilizó el siguiente código.<= o:p>
|
[TestMethod=
()]
public void EditTestCliente()
{ =
CLIENTEController controller =3D new <=
span
class=3DSpellE>CLIENTEController(); =
using (var ts =3D new TransactionScope()) =
{ As=
sert.IsNotNull(controller.Edit(new Models.CLI=
ENTE() { CLI_ID=3D4, CLI_NOMBRE =3D
"Santiago", CLI_TELEFONO =3D
"0999999999", CLI_CORREO =3D
"csviteri1@espe.edu.ec", })); =
}
} |
El
tiempo resultante en segundos de las pruebas unitarias, incluyendo el prome=
dio
final de la operación de actualizar datos mediante el método EditTest()
Tabla 3, Resultados de la operación de actualización de d=
atos
mediante el método EditTest
|
|
Tiempo en Segundos |
||
|
Registros |
Prueba 1 |
Prueba 2 |
Promedio |
|
Cliente |
0,08 |
0,19 |
0,135 |
|
Editorial |
0,03 |
0,55 |
0,29 |
|
Compra |
0,041 |
0,1 |
0,07 |
|
Libro |
0,012 |
0,07 |
0,04 |
Elaborado por: Grupo de investigación.
Para las pruebas de integración del editar se
utilizó el siguiente código.
|
var<=
/b> uiIndex =3D
this.UIMap.UIIndexCodedUItestautoWindow.UIIndexCodedUItestautoDocument; =
uiIndex.UIItemTable.UIBobCell.SearchProperties[HtmlHyperlink.Prope=
rtyNames.InnerText]
=3D TestContext.DataRow["FirstName"].ToString(); =
uiIndex.UIItemTable.UIBobCell.SearchProperties[HtmlHyperlink.Prope=
rtyNames.InnerText]
=3D TestContext.DataRow["LastName"].ToString(); =
uiIndex.UIItemTable.UIBobCell.SearchProperties[HtmlHyperlink.Prope=
rtyNames.InnerText]
=3D TestContext.DataRow["Email"]. =
uiIndex.UIBobsm=
ithsomedomaincoHyperlink.SearchProperties[HtmlHyperlink.PropertyNames.Inner=
Text]
=3D TestContext.DataRow["DateOfBirth"].ToString(); this.UIMap.Asse=
rtMethodUserModificar |
Tabla 4=
.
Resultados de la operación de actualización de datos en los Test de Integra=
ción
|
|
Tiempo en Segundos |
||
|
Registros |
Prueba 1 |
Prueba 2 |
Promedio |
|
Cliente |
0,43 |
0,39 |
0,41 |
|
Editorial |
0,43 |
0.36 |
0.395 |
|
Compra |
0,45 |
0.40 |
0.425 |
|
Libro |
0,40 |
0.37 |
0,385 |
Elaborado por: Grupo de investigación.
Para las operaciones de actualización de datos, =
los
resultados se muestran en la Figura 2.
Figura 2=
.
Resultados de las pruebas de inserción.
Elaborado por: Grupo de investigación.
En la tercera prueba se eliminó datos mediante el
controlador de cada modelo, a una base de datos y se tomó el tiempo que se demoró en
realizar las operaciones respectivas.
Para la ejecución de las pruebas del DeleteTest se utilizó el siguiente código.
|
[TestMethod()] public void DeleteTest() { bibliotecaEntities
db =3D new bibliotecaEnt=
ities(); CLIENTE c =3D =
new
CLIENTE(); try { CLIENTEController controller =3D new CLIENTEController(); ActionResult result =3D contro=
ller.Delete(1)
as ActionResult; db.Entry(c).State =3D EntitySt=
ate.Deleted; db.SaveChanges(); Assert.IsNotNull(result); } catch (Exception e) { } } |
El tiempo resultante en segundos de las pruebas
unitarias, incluyendo el promedio final de la operación de eliminar datos
mediante el método DeleteTest()
Tabla 5=
. Resultados de la operación de la eliminación de
datos mediante el método DeleteTes=
t()
|
|
Tiempo en Segundos |
||
|
Registros |
Prueba 1 |
Prueba 2 |
Promedio |
|
Cliente |
0,010 |
0,014 |
0,012 |
|
Editorial |
0,062 |
0,021 |
0,042 |
|
Compra |
0,021 |
0,015 |
0,018 |
|
Libro |
0,044 |
0,061 |
0,053 |
Elaborado por=
: Grupo de investigación.
Resultados de =
las
pruebas de integración.
Tabla 6=
. Resultados de la operación de eliminación de dat=
os
en los Test de Integración.
|
|
Tiempo en Segundos |
||
|
Registros |
Prueba 1 |
Prueba 2 |
Promedio |
|
Cliente |
0,29 |
0,28 |
0,285 |
|
Editorial=
|
0,31 |
0,33 |
0,32 |
|
Compra |
0,26 |
0,24 |
0,25 |
|
Libro |
0,28 |
0,25 |
0,265 |
Elaborado por: Grupo de investigación.
Para las
operaciones de eliminación de datos, los resultados se muestran en la Figur=
a 3.
Elaborado por: Grupo de investigación.
Para la realización de pruebas unitarias se recurr=
ió a
la utilización del Unitest que mide las consult=
as y
como fueron desarrolladas de acuerdo a los niveles de calidad de la informa=
ción
Figura 4.
Pruebas Unitarias con Unitest.
Elaborado por: Grupo de investigación.
En la figura anterior se puede ver como se realizan
las consultas y el tiempo que debió transcurrir para crear, almacenar,
actualizar y eliminar la respectiva información.
La secu=
encia
de acciones desde el punto de vista de código, el RecordedMethodIndex abre
la aplicación de la URL indicada, e inmediatamente después, el AssertMethodIndexPageLoaded comprueba que
existe el control "Crear nuevo". Esta comprobación puede suc=
eder
demasiado pronto si la página web no se cargue por completo todavía, para
solucionar este error y que la aplicación espere a que cargue la página se
pondrá el siguiente código en el UIMap Test.
|
públicos vacíos { uICreateNewHyperlink.WaitForControlReady (); =
Assert.AreEqual
(...); } |
Conclusiones.<= o:p>
ˇ
En el ciclo de desarrollo softwar=
e en
la etapa de pruebas, aplicar un método eficiente para detectar errores y
resolverlos a tiempo antes de unir los diferentes módulos desarrollados del
proyecto, permite un ahorro del tiempo y evita tener errores a futuro, en sí
todas las pruebas automatizadas tienen confiabilidad para realizarlas, pero
todas tienen sus ventajas y desventajas como se ve en este artículo.
ˇ
Los diferentes tipos de pruebas
empleados en el presente trabajo fueron los que más se utilizaban en un
ambiente de desarrollo software y por ende fueron parte de este estudio de
eficiencia y fiabilidad, las pruebas utilizadas fueron Unitarias y Pruebas =
de
Integración.
ˇ
Se destacó las pruebas Untarías en
tiempos de ejecución y evaluación de las operaciones de inserción,
actualización y eliminación de datos.
ˇ
Para la detección de errores se u=
sa
el método Assert que devuelve un valor verdader=
o o
falso para cada prueba realizada a las operaciones antes dichas de los dato=
s y
muestra si la prueba se realizó con éxito o no. El mejor en responder a este
método fueron las pruebas Unitarias que permitieron detectar errores de for=
ma
más eficiente y con un mayor grado de exactitud, es decir, ahorra recursos,
costos, evita redundancia de software y
tiempo a comparación con las pruebas de integración con UI ya que el hecho =
de
utilizar una interfaz gráfica hace que la ejecución de las pruebas se demor=
en
más tiempo, estas pruebas tienen la misma fiabilidad de calidad que las
unitarias pero ocupan más tiempo y recursos como se ven en los gráficos
estadísticos (Figura 1, Figura 2, Figura 3).
Referencias
bibliográficas.
Ano=
n,
(2017). [online] Available at: Article title: Pruebas<=
/span>
automatizadas con ASP.NET MVC - Solvetic
- Página 2 Website title: Solvetic.com URL:
https://www.solvetic.com/tutoriales/article/1318-pruebas-automatizadas-con-=
aspnet-mvc/?_st=3D1
[Accessed 24 Feb. 2017].
=
Para
citar el artículo indexado.
=
Viteri S., May=
orga
T., Navas P. & Molina P. . (2018).
control de calidad del software mediante pruebas automatizadas de
integración y pruebas unitarias. Re=
vista electrónica
Ciencia Digital 2(3), 101-115. Recuperado desde: http://cienciadigital.org/revistacienciadigita=
l2/index.php/CienciaDigital/article/view/140/125
El
artículo que se publica es de exclusiva responsabilidad de los autores y no
necesariamente reflejan el pensamiento de la Revista Ciencia Digital.
El
articulo queda en propiedad de la revista y, por tanto, su publicación parc=
ial
y/o total en otro medio tiene que ser autorizado por el director de la Revista Ciencia Digital.
[1]
Universidad de las Fuerzas Armadas ESPE, Cotopaxi, Ecuador,
[2] Unive=
rsidad
de las Fuerzas Armadas ESPE, Cotopaxi, Ecuador, =
ptmayorga@espe.edu.ec
[3]
Universidad de las Fuerzas Armadas ESPE, Cotopaxi , Ecuador, mpnavas@espe=
.edu.ec
[4] Unive= rsidad de las Fuerzas Armadas ESPE, Cotopaxi, Ecuador, pamol= ina6@espe.edu.ec
www.cienciadigital.org
Vol. 2, N°3, p. 10=
1-115,
Julio - Septiembre, 2018