Para empezar, esta informacion no es inventada, me la dieron en un curso para la certificacion MCAD (Microsoft Certified Application Developer) , pero el curso es en ingles asi que la traduje. Estos son los tipos:
Especificación: Este tipo de prueba incluye probar la aplicación en contra de la documentación que se hizo antes, por ejemplo, que los procesos concuerden con los algoritmos hechos a papel, o que la aplicación tenga todas las funciones que se habían planeado.
Usabilidad: Este tipo de prueba se refiere a asegurar de que la interfaz de usuario (o GUI) sea intuitiva, amigable y funcione correctamente.
Unidad: Este tipo de prueba solo aplica a proyectos grandes. Se divide el proyecto a unidades y cada unidad es sometida a prueba individualmente.
Integración: Prueba varias unidades juntas para asegurar que funcionen bien. También se asegura de que las nuevas aplicaciones se integren con aplicaciones antiguas o aplicaciones complementarias.
Regresión: Esta prueba incluye todas las pruebas anteriores en caso de que se le haga algún cambio a algún modulo después de haber sido puesto en ambiente de producción.
Related posts:
{ 21 comments… read them below or add one }
donde quedan las pruebas de estres, caja negra, rendimiento, diseño informacional, referencia cruzada?
de que se trata este tema
deceo saber de que se trata esete tema
como exponerlo
gracias por tu informacion, es muy util, y de un gran apoyo para los estudiantes como yo!! grax!!
hola esto que pones si esta muy bien me gusto, pero si tienes un poco mas de informacion que puedas pasarme mucho mejor. porque estoy buscando sobre pruebas de carga, estres, Smoke etc lo que pasa es que estoy aprendiendo espero me puedas ayudar gracias.
hola esto que pones si esta muy bien me gusto, pero si tienes un poco mas de informacion que puedas pasarme mucho mejor. porque estoy buscando sobre pruebas de carga, estres, Smoke etc lo que pasa es que estoy aprendiendo espero me puedas ayudar gracias.
mmm psss nuzeee!!xD jojojoj =)
hahahahah hehehehhe hihihihih hohohoho huuhuh
waah ia me voii .
ah todo chiido ezthoo !xD
trados todos ustedes ok
a mi me gusta mucho luis alejandro yo lo amo
no entendi el tema
fnfjnjfngfkjngfkngfdkbjkdjngfjdnfdjfhjwiwpñs sd d d d dsdadvagddddddddddddddddddddabcvczx <xxxxxxxxxxxxxxxxxxxb lisnnd dffff
esta bueno, pero recién estoy aprendiendo y quiero mayor información
De mucha utilidad tu informacion graxias te FELICITO BYE CUIDATE
Hay muchísima información importante en este sentido. Quizá sean las 5 que microsoft utiliza, pero existen otras, así como otras clasificaciones (como lo mencionado arriba sobre caja blanca y caja negra, pruebas que se aplican sobre todo a módulos funcionales integrados o a unidades). Es, de todos modos, un tema muy interesante en el área de Ingeniería de Software al que todo desarrollador le tiene que poner mucha atención.
Desafortunadamente no cuento con una buena referencia en este instante, pero una búsqueda en google sobre “pruebas de software” seguro podrá ampliar el tema.
Infórmense, vale la pena…
esta buena la info, pero hace falata mas creo ke hay otrras pruebas importantes para evaluar la calidad del software
cuidenc bye…
n m gust nda
sta materia es aburrida
Hola, les aporto el tipo de pruebas que uso yo en los proyectos:
Pruebas unitarias: estas las corre el desarrollador, cada vez que va probando pedazos de codigo o scripts para ver si todo funciona como el desea. Estas pruebas son muy tecnicas. PE: probar una consulta, probar que un pedazo de codigo me envie algo a imprimir, probar que una funcion me devuelva un flag…
Pruebas de Sistema: si la aplicacion se compone de varios modulos, hago la prueba de toda la aplicacion aun cuando solo haya modificado una parte de el, solo para ver si en conjunto todo funciona bien, esta las hace el desarrollador pero tambien debe correrlas un tester. PE: modifique un modulo para generar un reporte de imagen a pdf, pruebo la funcionalidad en varios modulos diferentes para ver si se integro bien al funcion con todo el sistema.
Pruebas de Integracion: esta se usa si tu sistema usa otros servicios o sistemas externos a el, la corre el desarrollador y tambien un tester. PE: Mi aplicacion ademas de generar un pdf lo envia por email, encolandolo en un servidor de correo, pruebo que el server de correo encole bien el mensaje y que agregue toda la informacion y el adjunto.
Prueba de aceptacion: esta prueba debe ser hecha asi con dibujos y todo detallando cada paso ya que el que la realiza es el tester y el usuario final y de ahi el dice si cumple con la funcion que requeria o si hay que manejarlo, a esta altura no debe haber ningun error si el tester hizo pruebas de integracion y de sistema… PE: el usuario hace una tarea cotidiana con datos reales en un ambiente de prueba y hace otras pruebas con datos raros para poner al sistema en jaque esperando que el sistema funcione correctamente y el de la aprobacion para implementarlo en un ambiente de pruebas.
Para mi estas son basicas, cualquier duda pueden consultarme, soy analista de calidad de software…
Exitos.
Es cierto que esos son tipos de pruebas muy usadas pero como dicen ahi los demas se necesita tener un conocimiento de todos los tipos de pruebas que se ven hoy en dia en la realizacion de testeo de software, ahi les dejo el link de mi pagina donde hablo de los tipos de prueba de software y de las herramientas que se usan hoy en dia
http://herrorsoft.zxq.net
Algo que se utiliza ultimamente mucho (en mi caso a diario) es el “Automated Regression Testing” que consta en utilizar una herramienta para crear “Scripts de Prueba” y correrlos contra la aplicacion que se esta probando.
Estos “Scripts de Prueba” simulan a un usuario y ejecutan los pasos de el procedimiento de prueba y valida que la aplicacion se comporte de acuerdo a los requerimientos.
Estos es muy util cuando introduces un release con cambios o mejoras a tu aplicacion y necesitas saber si esos cambios no hecharon a perder algo mas en la aplicacion.
Basicamente asegurarnos de que lo nuevo no heche a perder lo que ya funciona. Este es el principal beneficio de las “pruebas de regresion”
Ahora el beneficio de tener “Automated Regression Testing” es que puedes correr tus scripts de prueba cuantas veces quieras ya que no necesitas de “testers” para que ejecuten las pasos del procedimiento de prueba.
Imaginense tener 1000 procedimientos de prueba para una aplicacion que recibe mejoras o cambios 5 veces al mes. Tendriamos que tener un equipo de testers que manualmente pruebe los 1000 procedimientos de prueba cada vez que hay un cambio, esto serian 5000 pruebas. Necesitarias bastantes recursos para poder probar tu aplicacion. Pero con “automated regression testing” puedes correr los scritps y checar resultados cuando terminen de ejecutarse. No hay comparacion en lo que se puede ahorrar un empresa en tiempo y dinero con esta tecnica.
Mencione solo lo basico de este metodo de prueba, si alguien necesita mas informacion puede buscar en Google o mandarme un Email con su pregunta: george_pip@hotmail.com
Espero y esto le sirva alguien. Saludos