Tipos de Pruebas

PRUEBAS DE RENDIMIENTO
Nombres: Suriel Hernndez Matas Laura Elena Leyva Martnez Aurora Cruz Cruz Alejandro Jess Arce Ramrez Jorge Eduardo Jimnez Castillo Itzel Trujillo Morales Profesor: Erik Guerrero Bravo Grupo: 5TIC-G3 Asignatura: INTEGRADORA II
UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Organismo pblico descentralizado Del gobierno del estado de hidalgo
NDICE
INTRODUCCION ................................................................................................................................... 2 OBJETIVO ............................................................................................................................................. 3 PRUEBAS UNITARIAS ........................................................................................................................... 4 PRUEBAS DE CAJA NEGRA .................................................................................................................. 6 PRUEBAS DE PERFORMANCE ............................................................................................................ 11 PRUEBAS ESTRUCTURALES O DE CAJA BLANCA ............................................................................... 16 De cobertura Lgica ....................................................................................................................... 16 De cobertura de Condicin ........................................................................................................... 16 De cobertura de Mltiple ............................................................................................................... 17 ANLISIS ESTTICO .................................................................................................................... 19 ANALISIS DINAMICO .................................................................................................................... 20 Para este anlisis se cuenta con diferentes tipos de herramientas ....................................... 20 PRUEBAS DE CAJA GRIS ..................................................................................................................... 21 PRUEBAS DE STRESS DE SOFTWARE.................................................................................................. 23 Bibliografa ........................................................................................................................................ 27

INTRODUCCION
En este documento mostraremos y explicaremos todas las diferentes pruebas como lo son: Pruebas unitarias Prueba de caja negra Pruebas de performance Pruebas estructurales o de caja blanca Pruebas de caja gris Pruebas de stress de software
Explicaremos el contenido de cada una de ellas para poder tener informacin de que es cada mdulo de pruebas de software Explicaremos sus caractersticas sus ventajas, desventajas y para que sirve y en que nos podran servir este tipo de pruebas

OBJETIVO
El objetivo de las pruebas no es asegurar la ausencia de defectos en un software, nicamente puede demostrar que existen defectos en el software. Nuestro objetivo es pues, disear pruebas que sistemticamente saquen a la luz diferentes clases de errores, hacindolo con la menor cantidad de tiempo y esfuerzo. Para ser ms eficaces (es decir, con ms alta probabilidad de encontrar errores), las pruebas deberan ser realizadas por un equipo independiente al que realiz el software. El ingeniero de software que cre el sistema no es el ms adecuado para llevar a cabo las pruebas de dicho software, ya que inconscientemente tratar de demostrar que el software funciona, y no que no lo hace, por lo que la prueba puede tener menos xito. Una prueba de software, comparando los resultados obtenidos con los esperados. A continuacin se presentan algunas caractersticas de una buena prueba: Una buena prueba ha de tener una alta probabilidad de encontrar un fallo. Para alcanzar este objetivo el responsable de la prueba debe entender el software e intentar desarrollar una imagen mental de cmo podra fallar. Una buena prueba debe centrarse en dos objetivos: 1) probar si el software no hace lo que debe hacer, y 2) probar si el software hace lo que no debe hacer. Una buena prueba no debe ser redundante. El tiempo y los recursos son limitados, as que todas las pruebas deberan tener un propsito diferente. Una buena prueba debera ser la mejor de la cosecha. Esto es, se debera emplear la prueba que tenga la ms alta probabilidad de descubrir una clase entera de errores. Una buena prueba no debera ser ni demasiado sencilla ni demasiado compleja, pero si se quieren combinar varias pruebas a la vez se pueden enmascarar errores, por lo que en general, cada prueba debera realizarse separadamente.

PRUEBAS UNITARIAS
Es un procedimiento usado para validar que un mdulo o mtodo de un objeto fuente funciona apropiadamente y en forma independiente. A travs de ellas se verifica que cierto mdulo o mtodo se ejecuta dentro de los parmetros y especificaciones concretadas en documentos tales como los casos de uso y el diseo detallado. Permiten detectar efectivamente la inyeccin de defectos durante fases sucesivas de desarrollo o mantenimiento. Las pruebas unitarias tpicamente son automatizadas, pero pueden llevarse a cabo de forma manual. Cuando son automatizadas es buena prctica que forme parte del repositorio que contiene al cdigo probado. Se dice que una prueba unitaria es completa o es buena si cumple con los siguientes elementos: o o o o Automtica Cobertura Repetibles Independiente
Frameworks
Para llevar a cabo pruebas unitarias, cada organizacin se apoya en frameworks que ofrecen un conjunto completo de utilidades, motores de ejecucin y reportes. Entre los frameworks ms empleados destacan: o o o o XUnit: JUnit, NUnit, RUnit, PHPUnit TestNG CPPUnit Visual Studio UnitTesting
Ventajas
Dependiendo del framework empleado podemos encontrar las siguientes ventajas: Automatizadas, por lo cual se hacen repetibles. 4

Fomentan el cambio: ya que permiten probar cambios en el cdigo y asegurar que en stos no se hayan introducido errores funcionales; habilitan el refactoring del cdigo. Simplifican la integracin: permiten llegar a la fase de integracin con un grado alto de seguridad sobre el cdigo. Documenta el cdigo. Separa la interfaz y la implementacin. Los defectos estn acotados y fciles de localizar. Permiten al desarrollador pensar como el consumidor del cdigo y no como el productor.
Desventajas y Limitaciones
No descubrirn todos los defectos del cdigo. No permite determinar problemas de integracin o desempeo. No es trivial anticipar todos los casos especiales de entradas. Las pruebas unitarias determinan la presencia de defectos, no la ausencia de stos. Son efectivas al combinarse con otras actividades de pruebas.
Los datos de entrada son conocidos por el Tester o Analista de Pruebas y estos deben ser preparados con minuciosidad. Se debe conocer de antemano que resultados debe devolver el componente segn los datos de entrada utilizados en la prueba. Se deben comparar los datos obtenidos en la prueba con los datos esperados, si son idnticos podemos decir que el modulo supero la prueba y empezamos con la siguiente.
Herramientas
JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent Beck. Se encuentra basado en SUnit creado originalmente para realizar pruebas unitarias para el lenguaje Smalltalk.
TestNG: Creado para suplir algunas deficiencias en JUnit. JTiger: Basado en anotaciones, como TestNG. SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP. PHPUnit: Sistema para la realizacin pruebas unitarias en PHP. CPPUnit: Versin del framework para lenguajes C/C++. NUnit: Versin del framework para la plataforma.NET. FoxUnit: Entorno OpenSource de pruebas unitarias para Microsoft Visual FoxPro MOQ: Entorno para la creacin dinmica de objetos simuladores (mocks).

QUnit: Librera de Javascript de pruebas unitarias para jQuery, jQueryUI y jQuery Mobile.
PRUEBAS DE CAJA NEGRA

Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento. Un sistema formado por mdulos que cumplan las caractersticas de caja negra ser ms fcil de entender ya que permitir dar una visin ms clara del conjunto. El sistema tambin ser ms robusto y fcil de mantener, en caso de ocurrir un fallo, ste podr ser aislado y abordado ms gilmente. El mtodo de la caja negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa. Con este equipo de pruebas se intenta encontrar: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a las bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin. Con la aplicacin de esa tcnica se obtiene un conjunto de pruebas que: Reduce el nmero de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores. a. Particin equivalente: Una particin equivalente es un mtodo de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos. El diseo de casos de prueba para la particin equivalente se basa en la evaluacin de las clases de equivalencia. Anlisis de valores lmite: Nos lleva a elegir las pruebas que nos ejecuten los valores lmite, con esta tcnica se complementa la particin equivalente. b. Prueba de comparacin: Esta tcnica consiste en la comparacin de salidas de un mismo software pero de sus diferentes versiones. 6

Esta prueba implica una variada seleccin de los datos de prueba as como una buena interpretacin de los resultados para determinar el nivel de optimizacin de la funcionalidad del sistema. Se ha determinado con diferentes estudios estadsticos, que el software no debe ser probado por el creador o grupo de creadores del sistema ya que el extenso conocimiento de la estructura interna del programa limita la variedad de datos probados o el encaminamiento de las pruebas es hacia ciertos rasgos del programa olvidando otras partes del software poco valoradas por su simpleza en la creacin. Segn C. Kaner en su libro Testing Computer Software de 1993, el aspecto humano es esencial en la prueba de caja negra aplicando factibles sucesos de la vida real a la prueba, errores de tipo, trabajar en aplicaciones equivocadas creyendo trabajar en la aplicacin deseada, etc., pero sucede que los programadores han pasado tanto tiempo en la creacin del sistema y al ser la prueba de caja negra una de las ms tempranas sus hechos factibles de la vida real estn entre el Begin y el end de cada aplicacin. La prueba de caja negra ha hecho que cada organizacin dedicada al desarrollo de software contemple dentro de ella un departamento especial dedicado a las pruebas. El principal objetivo es determinar la funcionalidad del software y parte de tratar al programa como si fuera una funcin matemtica, estudiando si las respuestas o salidas son co-dominio de los datos entrantes (dominio). La prueba de caja negra tiene otras metas, determinar la eficiencia del programa desde el desempeo en el equipo, el tiempo de retardo de las salidas hasta el nivel de recuperacin del sistema luego de fallas o cadas sean estas producidas por manejo incorrecto de datos, equipo, o producidas externamente como cortes de energa. La prueba de caja negra debe cubrir el espectro entero de sucesos factibles, de esto se debe ocupar el departamento de prueba, pero nunca se sabe si se han cubierto todos los casos o gran parte de ellos, no olvidemos que los testers pertenecen a la organizacin por lo que la prueba de caja negra no termina una vez que sali del laboratorio. La prueba con intervencin del usuario es un pequeo periodo de tiempo en el cual el usuario bajo el asesoramiento de testers, se desenvuelve en el software y examina la operatividad de los datos que el maneja. El usuario dar la puntada final en la cuestin de datos de prueba. Esta parte de la prueba no podra hacerse sin que el usuario haya tenido previo contacto con los prototipos del sistema, y para los testers una efectiva interaccin con Herramientas case. Algunos de los mtodos empleados en las pruebas de caja negra son los siguientes: Mtodos de prueba basados en grafos: en este mtodo se debe entender los objetos (objetos de datos, objetos de programa tales como mdulos o colecciones de sentencias del lenguaje de programacin) que se modelan en el software y las relaciones que 7

conectan a estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas. En este mtodo: Se crea un grafo de objetos importantes y sus relaciones. Se disea una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir errores.
Segn Boris Bzier existe un nmero de modelados para pruebas de comportamiento que pueden hacer uso de los grafos: Modelado del flujo de transaccin. Los nodos representan los pasos de alguna transaccin (por ejemplo, los pasos necesarios para una reserva en una lnea area usando un servicio en lnea), y los enlaces representan las conexiones lgicas entre los pasos (por ejemplo, vuelo.informacin.entrada es seguida de validacin /disponibilidad.procesamiento). Modelado de estado finito. Los nodos representan diferentes estados del software observables por el usuario (por ejemplo, cada una de las pantallas que aparecen cuando un telefonista coge una peticin por telfono), y los enlaces representan las transiciones que ocurren para moverse de estado a estado (por ejemplo, peticin-informacin se verifica durante inventario-disponibilidad-bsqueda y es seguido por cliente-facturainformacin-entrada). Modelado de flujo de datos. Los nodos objetos de datos y los enlaces son las transformaciones que ocurren para convertir un objeto de datos en otro. Modelado de planificacin. Los nodos son objetos de programa y los enlaces son las conexiones secuenciales entre esos objetos. Los pesos de enlace se usan para especificar los tiempos de ejecucin requeridos al ejecutarse el programa. Grfica Causa-efecto. La grfica Causa-efecto representa una ayuda grfica en seleccionar, de una manera sistemtica, un gran conjunto de casos de prueba. Tiene un efecto secundario beneficioso en precisar estados incompletos y ambigedades en la especificacin. Un grfico de causa-efecto es un lenguaje formal al cual se traduce una especificacin. El grfico es realmente un circuito de lgica digital (una red combinatoria de lgica), pero en vez de la notacin estndar de la electrnica, se utiliza una notacin algo ms simple. No hay necesidad de tener conocimiento de electrnica con excepcin de una comprensin de los operadores lgicos. Particin equivalente: Pressman presenta la particin equivalente como un mtodo de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores que, de otro modo, requeriran la ejecucin de 8

muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar. Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos para condiciones de entrada. Tpicamente, una condicin de entrada es un valor numrico especfico, un rango de valores, un conjunto de valores relacionados o una condicin lgica. El objetivo de particin equivalente es reducir el posible conjunto de casos de prueba en uno ms pequeo, un conjunto manejable que evale bien el software. Se toma un riesgo porque se escoge no probar todo. As que se necesita tener mucho cuidado al escoger las clases. La particin equivalente es subjetiva. Dos probadores quienes prueban un programa complejo pueden llegar a diferentes conjuntos de particiones. En el diseo de casos de prueba para particin equivalente se procede en dos pasos: Se identifican las clases de equivalencia. Las clases de equivalencia son identificadas tomando cada condicin de entrada (generalmente una oracin o una frase en la especificacin) y repartindola en dos o ms grupos. Es de notar que dos tipos de clases de equivalencia estn identificados: las clases de equivalencia vlidas representan entradas vlidas al programa, y las clases de equivalencia invlidas que representan el resto de los estados posibles de la condicin (es decir, valores errneos de la entrada). Se define los casos de prueba. El segundo paso es el uso de las clases de equivalencia para identificar los casos de prueba. El proceso es como sigue: se asigna un nmero nico a cada clase de equivalencia. Hasta que todas las clases de equivalencia vlidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia vlida. Y por ltimo hasta que los casos de prueba hallan cubierto todas las clases de equivalencia invlidas, se escribe un caso de la prueba que cubra una, y solamente una, de las clases de equivalencia invlidas descubiertas. Anlisis de valores lmite: los errores tienden a darse ms en los lmites del campo de entrada que en el centro. Por ello, se ha desarrollado el anlisis de valores lmites (AVL) como tcnica de prueba. El anlisis de valores lmite lleva a una eleccin de casos de prueba que ejerciten los valores lmite. El anlisis de valores lmite es una tcnica de diseo de casos de prueba que completa a la particin equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la eleccin de casos de prueba en los extremos de la clase.

En lugar de centrarse solamente en las condiciones de entrada, el AVL obtiene casos de prueba tambin para el campo de salida. Condiciones sublmite. Las condiciones limite normales son las ms obvias de descubrir. Estas son definidas en la especificacin o son evidentes al momento de utilizar el software. Algunos lmites, sin embargo, son internos al software, no son necesariamente aparentes al usuario final pero aun as deben ser probadas por el probador. Estas son conocidas como condiciones sublmites o condiciones lmite internas. Una condicin sublmite comn es la tabla de caracteres ASCII, por ejemplo, si se est evaluando una caja de texto que acepta solamente los caracteres AZ y az, se debe incluir los valores en la particin invlida justo debajo de y encima de esos caracteres de la tabla ASCII, [", y {. Prueba de la tabla ortogonal: hay aplicaciones donde el nmero de parmetros de entrada es pequeo y los valores de cada uno de los parmetros est claramente delimitado. Cuando estos nmeros son muy pequeos (por ejemplo, 3 parmetros de entrada tomando 3 valores diferentes), es posible considerar cada permutacin de entrada y comprobar exhaustivamente el proceso del dominio de entrada. En cualquier caso, cuando el nmero de valores de entrada crece y el nmero de valores diferentes para cada elemento de dato se incrementa, la prueba exhaustiva se hace impracticable. La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio de entrada es relativamente pequeo pero demasiado grande para posibilitar pruebas exhaustivas. El mtodo de prueba de la tabla ortogonal es particularmente til al encontrar errores asociados con fallos localizados -una categora de error asociada con defectos de la lgica dentro de un componente software. La prueba de tabla ortogonal permite proporcionar una buena cobertura de pruebas con bastantes menos casos de prueba que en la estrategia exhaustiva. Adivinando el error: dado un programa particular, se conjetura, por la intuicin y la experiencia, ciertos tipos probables de errores y entonces se escriben casos de prueba para exponer esos errores. Es difcil dar un procedimiento para esta tcnica puesto que es en gran parte un proceso intuitivo y ad hoc. La idea bsica es enumerar una lista de errores posibles o de situaciones propensas a error y despus escribir los casos de prueba basados en la lista. Por ejemplo, la presencia del valor 0 en la entrada de un programa es una situacin con tendencia a error. Por lo tanto, puede ser que se escriba los casos de prueba para los cuales los valores particulares de la entrada tienen valor 0 y para qu valores particulares de la salida se colocan de manera forzada a 0.
10

PRUEBAS DE PERFORMANCE
Pruebas de carga
Las pruebas de carga es la forma ms simple de las pruebas de rendimiento. Una prueba de carga se realiza normalmente a comprender el comportamiento del sistema bajo una carga especfica espera. Esta carga puede ser el nmero esperado de usuarios concurrentes en la aplicacin que realiza un nmero determinado de transacciones dentro del perodo de tiempo establecido. Esta prueba le dar a los tiempos de respuesta de todas las operaciones crticas de negocio importantes. Si la base de datos, servidor de aplicaciones, etc. tambin son monitoreados, esta sencilla prueba puede apuntar hacia s mismo los puntos conflictivos en el software de aplicacin.
Pruebas de tensin
Las pruebas de estrs se utilizan normalmente para entender los lmites superiores de la capacidad dentro del sistema. Este tipo de examen se hace para determinar la robustez del sistema en trminos de carga extrema y ayuda a los administradores de aplicacin para determinar si el sistema funcionar suficientemente si la corriente de carga va muy por encima de la mxima prevista.
Espiga de pruebas
Pruebas de espiga se hace repentinamente aumentar el nmero de o la carga generada por los usuarios por una cantidad muy grande y observando el comportamiento del sistema. El objetivo es determinar si el rendimiento se ver afectada, el sistema fallar, o ser capaz de manejar grandes cambios en la carga.
Configuracin de las pruebas

En lugar de las pruebas de rendimiento a partir de la perspectiva de la carga, las pruebas se crearon para determinar los efectos de los cambios de configuracin de los componentes del sistema en el rendimiento del sistema y el comportamiento. Un ejemplo comn sera experimentar con diferentes mtodos de equilibrio de carga.
11

Aislamiento pruebas
Pruebas de aislamiento no es exclusiva de las pruebas de rendimiento pero consiste en repetir una ejecucin de prueba que dio lugar a un problema del sistema. A menudo se utiliza para aislar y confirmar el fallo de dominio.
Establecer metas de desempeo

Las pruebas de rendimiento pueden servir diferentes propsitos. Se puede demostrar que el sistema cumple con los criterios de desempeo. Se pueden comparar dos sistemas para saber que funciona mejor. O puede medir qu partes del sistema o carga de trabajo hace que el sistema realice mal.
Muchas pruebas de rendimiento se llevan a cabo sin la debida consideracin a la fijacin de metas de desempeo realistas. La primera pregunta desde una perspectiva de negocio siempre debe ser "por qu estamos haciendo pruebas de rendimiento?". Estas consideraciones forman parte del modelo de negocio de la prueba. Los objetivos de rendimiento sern diferente dependiendo de la tecnologa del sistema y el propsito, sin embargo siempre deben incluir algunas de las siguientes: Concurrencia / rendimiento
Si un sistema identifica a los usuarios finales por alguna forma de log-in entonces un objetivo de concurrencia es altamente deseable. Por definicin, este es el mayor nmero de usuarios del sistema simultneas que el sistema est previsto para apoyar en cualquier momento dado. El flujo de trabajo de una transaccin puede afectar a la concurrencia con guion especialmente cierto si la parte iterativo contiene el registro de entrada y registro de actividad-auto. Si el sistema no tiene ningn concepto de los usuarios finales a continuacin, objetivo de rendimiento es probable que se basa en un rendimiento mximo o la tasa de transaccin. Un ejemplo comn sera una navegacin rpida de un sitio web como Wikipedia.
Servidor de tiempo de respuesta

Esto se refiere al tiempo necesario para que el nodo de sistema a responder a la peticin de otro. Un ejemplo sencillo sera un HTTP 'GET' solicitar a cliente del explorador al servidor web. En trminos de tiempo de respuesta es lo que todas las herramientas de prueba de carga realmente medir. Puede ser relevante para establecer objetivos de tiempo de respuesta del servidor entre todos los nodos del sistema. 12

Rendir tiempo de respuesta

Una cosa difcil para las herramientas de prueba de carga a tratar, ya que generalmente no tienen el concepto de lo que ocurre dentro de un nodo aparte de reconocer un periodo de tiempo donde no hay actividad "en el alambre". Para medir el tiempo de rendir respuesta generalmente es necesario incluir scripts de prueba funcional como parte del escenario de prueba de rendimiento que es una caracterstica que no ofrece muchas herramientas de pruebas de carga.
Las especificaciones de rendimiento

Es fundamental para las especificaciones de rendimiento detallados (requisitos) y documentarlas en cualquier plan de prueba de rendimiento. Idealmente, esto se hace durante la fase de desarrollo de los requisitos de cualquier proyecto de desarrollo del sistema, antes de cualquier esfuerzo de diseo. Sin embargo, las pruebas de rendimiento con frecuencia no se realiza contra una especificacin es decir, nadie se han expresado lo que el tiempo de respuesta mximo aceptable para una poblacin dada de usuarios deberan ser. Las pruebas de rendimiento se utilizan con frecuencia como parte del proceso de ajuste de rendimiento perfil. La idea es identificar el "eslabn ms dbil" - existe inevitablemente una parte del sistema que, si se hace para responder ms rpidamente, se traducir en el sistema de funcionamiento global ms rpido. A veces es una tarea difcil identificar qu parte del sistema representa la ruta crtica, y algunas herramientas de prueba son (o pueden tener los complementos que proporcionan) instrumentacin que se ejecuta en el servidor (agentes) y los tiempos de reporte de transacciones de bases de datos, los tiempos de acceso, sobrecarga de la red, y otros monitores de servidor, que puede ser analizado junto con las estadsticas de rendimiento bruto. Sin instrumentacin tal que uno podra tener a alguien inclinado sobre el Administrador de tareas de Windows en el servidor para ver la cantidad de carga de la CPU las pruebas de rendimiento estn generando (suponiendo un sistema Windows se encuentra bajo prueba). Las pruebas de rendimiento se pueden realizar a travs de la web, y hacer incluso en diferentes partes del pas, ya que se sabe que los tiempos de respuesta de la propia Internet varan segn la regin. Tambin puede ser hecho en casa, aunque Reuters entonces tendra que ser configurado para introducir el retardo de lo que normalmente se producira en redes pblicas. Las cargas deben ser introducidas en el sistema de puntos realistas. Por ejemplo, si el 50% de la base de usuarios de un sistema vaya a acceder al sistema a travs de una conexin de mdem de 56 K y la otra mitad sobre un T1, entonces los inyectores de carga (ordenadores que simulan los usuarios reales por ejemplo) debe inyectar la carga a travs de la misma mezcla de conexiones (ideal) o simular la latencia de la red de conexiones de este tipo, siguiendo el mismo perfil de usuario.
13

Siempre es til tener una relacin de los nmeros mximos probables de los usuarios que se podra esperar para utilizar el sistema en las horas punta. Si hay tambin puede ser una declaracin de lo que constituye el mximo permisible 95 percentil tiempo de respuesta, a continuacin, una configuracin de inyector podra ser usado para probar si el sistema propuesto reuni esa especificacin.
Preguntas que debe hacer Pre-requisitos para pruebas de rendimiento

Una compilacin estable del sistema que debe ser similar al entorno de produccin tan cerca cmo es posible. El entorno de pruebas de rendimiento no debe ser golpeado con las pruebas de aceptacin del usuario (UAT) o entorno de desarrollo. Esto es peligroso ya que si una prueba UAT o Integracin u otras pruebas estn llevando a cabo en el mismo entorno, los resultados obtenidos de las pruebas de rendimiento puede no ser fiable. Como prctica recomendada siempre es aconsejable disponer de un entorno de pruebas de rendimiento independientes se asemeja al entorno de produccin tanto como sea posible.
Condiciones de ensayo
En pruebas de rendimiento, a menudo es crucial (y muchas veces difciles de organizar) para las condiciones de prueba que es similar al uso real esperado. Esto es, sin embargo, no es del todo posible en la prctica real. La razn es que las cargas de trabajo de los sistemas de produccin tienen un carcter aleatorio, y mientras que las cargas de trabajo de prueba todo lo posible para imitar lo que puede suceder en el entorno de produccin, es imposible reproducir exactamente esta variabilidad carga de trabajo - excepto en el sistema ms simple. Dbilmente acoplados implementaciones de arquitectura (por ejemplo: SOA) han creado dificultades adicionales con las pruebas de rendimiento. Servicios para empresas o activos (que comparten una infraestructura comn o plataforma) exigir pruebas de desempeo coordinado (con todos los consumidores creando como la produccin de los volmenes de transaccin y la carga en infraestructuras compartidas o plataformas) para replicar verdaderamente de produccin similares a los estados. Debido a la complejidad y los requerimientos financieros y de tiempo en torno a esta actividad, algunas organizaciones ahora utilizan herramientas que pueden monitorizar y crear las condiciones como la produccin (tambin conocidos como "ruido") en sus entornos de pruebas de rendimiento (PTE) para entender la capacidad y los recursos necesarios y verificar / validar los atributos de calidad.
14

Sincronizacin
Es fundamental para el funcionamiento de coste de un nuevo sistema, que los esfuerzos de comenzar las pruebas de rendimiento en el inicio del proyecto de desarrollo y se extienden a travs de la implementacin. El rendimiento despus de un defecto es detectado, mayor es el coste de la recuperacin. Esto es cierto en el caso de las pruebas funcionales, pero ms an con pruebas de rendimiento, debido a la naturaleza de extremo a extremo de su alcance. Siempre es crucial para el equipo de prueba de rendimiento de participar lo antes posible. Como requisitos de rendimiento clave, por ejemplo, prueba de rendimiento de adquisicin ambiente y la preparacin es a menudo un proceso largo y el tiempo. Instrumentos En el caso de diagnstico, los ingenieros de software utilizan herramientas tales como perfiles de medir qu partes de un dispositivo o software que ms contribuye a los malos resultados o establecer niveles de rendimiento (y umbrales) para el tiempo de mantenimiento respuesta aceptable.
Tecnologa
Pruebas de rendimiento tecnologa emplea a uno o ms ordenadores o servidores Unix para actuar como inyectores - cada emulando la presencia de un nmero de usuarios y cada uno ejecutando una secuencia automtica de interacciones (registrado como un guion, o como una serie de secuencias de comandos para emular diferentes tipos de usuarios interaccin) con el anfitrin cuyo desempeo est siendo probado. Por lo general, un PC independiente acta como un conductor de la prueba, coordinacin y recopilacin de mtricas de cada uno de los inyectores y el cotejo de los datos de rendimiento para los informes. La secuencia habitual es que la rampa hasta la carga - a partir de un pequeo nmero de usuarios virtuales y aumentar el nmero durante un perodo hasta cierto mximo. El resultado de la prueba se muestra cmo el rendimiento vara con la carga, dado el nmero de usuarios vs tiempo de respuesta. Diversas herramientas, estn disponibles para realizar dichas pruebas. Herramientas de esta categora suelen ejecutar una serie de pruebas que emulan a los usuarios reales contra el sistema. A veces los resultados pueden revelar rarezas, por ejemplo, que mientras que el tiempo medio de respuesta sea agradable, hay valores atpicos de algunas transacciones claves que toman mucho ms tiempo para completar - algo que podra ser causado por las consultas de base de datos ineficientes, fotos, etc. Las pruebas de rendimiento se pueden combinar con las pruebas de estrs, con el fin de ver lo que sucede cuando una carga admisible se supera, hace el fallo del sistema Cunto tiempo se tarda en recuperarse si una gran carga se reduce? Se fallar de una manera que causa un dao colateral?
15

Modelado de rendimiento analtico es un mtodo para modelar el comportamiento de un sistema en una hoja de clculo. El modelo se alimenta con las mediciones de la demanda de recursos de transaccin (CPU, disco I / O, LAN, WAN), ponderados por la transaccinmix (las transacciones comerciales por hora). Las demandas de transaccin ponderados de recursos son aadidos en marcha para obtener las demandas de recursos por hora y dividido por la capacidad de recursos por hora de obtener las cargas de los recursos. Por tanto, es mucho ms rpido y ms barato que las pruebas de rendimiento, aunque se requiere una comprensin completa de las plataformas de hardware.
PRUEBAS ESTRUCTURALES O DE CAJA BLANCA

Este tipo de pruebas se centran en los detalles procedimentales del software por lo que su diseo est fuertemente ligado al cdigo fuente, el tester escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecucin del programa y cerciorarse de que se devuelven los valores de salida adecuados. La funcin principal de esta prueba es comprobar los flujos de ejecucin dentro de cada unidad (funcin, clase, modulo). Objetivo principal: es probar la lgica del programa desde el punto de vista algortmico.
Tipos de prueba
De Estructura de Datos Locales Se centran en el estudio de las variables del programa, busca que toda variable este declarada y que no existan con el mismo nombre, ni declaradas local y globalmente, que haya referencia a todas las variables y para cada variable analiza su comportamiento en comparaciones.
De cobertura Lgica o Cobertura de sentencias: comprueba que todas las sentencias se ejecuten al menos una vez o Cobertura de decisin: ejecuta casos de prueba de modo que cada decisin se pruebe al menos una vez a verdadero (true) y otra a falso (false).
De cobertura de Condicin o Ejecuta un caso de prueba a true y otra a false por cada decisin, teniendo en cuenta que una decisin puede estar formada por varias condiciones 16

De cobertura de Mltiple o Cada decisin multicondicin de traduce a una condicin simple, aplicando posteriormente la cobertura de decisin
Prueba del camino Bsico Buscando una mejor comprensin de los contenidos, se hace importante definir primeramente algunos conceptos fundamentales: Camino: secuencia de todas las instrucciones de un programa de principio a fin, se puede definir como la ruta de secuencias que se siguen dentro del cdigo fuente de un programa, un ejemplo: o Camino bsico: es una prueba de tcnica que permite obtener una medida de complejidad lgica para generar un conjunto bsico de caminos que se ejecutan por lo menos una vez durante la ejecucin del programa
Pruebas de Caminos
Son una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de ejecucin independiente en un componente o programa, si cada camino independiente, entonces todas las sentencias en el componente deben haberse ejecutado al menos una vez, adems todas las sentencias condicionales comprueban para los casos verdadero y falso. El nmero de caminos en un programa es normalmente proporcional a su tamao puesto que los mdulos se integran en sistemas. El punto de partida de una prueba de camino es un grafo de flujo del programa, este es un modelo del esqueleto de todos los caminos en el programa. Un grafo de flujo consiste en nodos que representan decisiones y aristas que muestran el flujo de control. El grafo de control se construye reemplazando las sentencias de control del programa por diagramas equivalentes. Si no hay una sentencia goto en un programa, es un procesos sencillo de derivar su grado de flujo.
Complejidad ciclo matica

Es la medida de la complejidad lgica de un modelo y el esfuerzo mnimo para codificarlo, ya que el nmero mnimo requerido de pruebas se sabe por adelantado y por tanto el proceso de prueba Los pasos a seguir para aplicar esta tcnica son: 1) 2) Representar el programa en un grafo de flujo. Calcular la complejidad ciclomtica. 17

3) 4)
Determinar el conjunto bsico de caminos independientes. Derivar los casos de prueba que fuerzan la ejecucin de cada camino.
Representacin de un grafo de flujo: El grafo de flujo se utiliza para representar el flujo de control lgico de un programa. Este emplea los tres elementos siguientes: Nodos Representan cero, una o varias sentencias en secuencia. Cada uno comprende como mximo una sentencia de decisin (bifurcacin). Aristas Lneas que unen dos nodos Regiones reas delimitadas por aristas y nodos. Cuando se contabilizan las regiones de un programa debe incluirse el rea externa como una regin ms.
As, cada construccin lgica de un programa tiene una representacin. La Figura muestra un grafo de flujo del diagrama de mdulos correspondiente. Ntese cmo la estructura principal corresponde a un while y dentro del bucle se encuentran anidados dos constructores if.
Calcular la complejidad ciclomtica: La complejidad ciclomtica es una mtrica del software que proporciona una medida cuantitativa de la complejidad lgica de un programa. Se basa en la representacin 18

grfica del flujo de control del programa, el anlisis desprende una medida cuantitativa de la dificultad de prueba y una indicacin de la fiabilidad final. Cuando se utiliza en el contexto del mtodo de prueba del camino bsico, el valor calculado como complejidad ciclomtica define el nmero de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez.
Mtrica: Medida estadstica que se aplica a todos los aspectos de calidad de software, los cuales deben ser medidos desde diferentes puntos de vista. [13] La mtrica se define como trmino para valorar en una medida la calidad de software considerando diferentes puntos necesario a evaluar.
Las pruebas de caja blanca intentan garantizar: Se ejecuten al menos una vez todos los caminos independientes de cada mdulo. Se ejecuten todos los bucles en sus lmites. Se utilizan todas las estructuras de datos internas.
Para este tipo de prueba se toman en cuenta 3 puntos fundamentales: Conocer el desarrollo interno del programa determinante en el anlisis de coherencia y consistencia del cdigo. Considerar las reglas predefinidas por cada algoritmo. Comparar el desarrollo del programa en su cdigo con la documentacin pertinente.
Se divide en dos partes: 1. ANLISIS ESTTICO Anlisis esttico manual Inspeccin: Determina si el cdigo est completo y correcto as como las especificaciones. Walkthrough: Interrelacin informal entre testers, creadores y usuarios del sistema.
19

Anlisis esttico automtico Verificacin esttica: Compara los valores generados por el programa con los rangos de valores predefinidos haciendo una descripcin del funcionamiento de los procedimientos en trminos booleanos determinando los puntos de falla. Ejecucin Simblica: Seguimiento de la comunicacin entre funciones, mdulos, aplicaciones, luego de que todas las partes hayan sido verificadas por separado.
2. ANALISIS DINAMICO Para este anlisis se cuenta con diferentes tipos de herramientas Anlisis de cobertura: Examina las extensiones del cdigo, haciendo una caja blanca por modulo. Trafico: Sigue todos los caminos de comunicacin entre mdulos guardando los valores de las variables en cada uno de ellos. Simulador: Simula partes del sistema para el cual el hardware no est habilitado. Sintona: Teste los recursos utilizados durante la ejecucin del programa. Prueba de Certeza: Examina las construcciones lgicas del programa.
Herramientas para las pruebas JTest

Es el primer sistema automtico de bsqueda de errores en el cdigo de programacin para programadores de Java. Esta nueva tecnologa desarrollada por la empresa ParaSoft, utiliza la Test Generation Technolgy para analizar programas en Java. Se trata de una herramienta que permite realizar anlisis de cdigo, pruebas unitarias automticas y cobertura de cdigo, as como generacin dinmica de pruebas funcionales. Es capaz de generar automticamente todas las pruebas unitarias que sean necesarias, teniendo en cuenta los parmetros de cobertura de cdigo e intentando encontrar pruebas que deriven en errores de ejecucin. Genera pruebas funcionales filtradas por las acciones y los datos, incluyendo peticiones HTTP2 y JDBC3. 20

Logiscope TestChecker
Aplicacin para la representacin grfica de cobertura del cdigo fuente. Evala el nivel de cobertura del cdigo, el usuario debe de comprar la licencia por perodo de tiempos, no realiza evaluaciones al cdigo de C Sharp y no cuenta con la verificacin de estndares.
PRUEBAS DE CAJA GRIS

Con el crecimiento acelerado de las tecnologas y la informtica la produccin de software desempea un papel importante, provocando a su vez una competencia en los sistemas, donde la calidad es fundamental para conseguir la rentabilidad en la produccin. La necesidad de Realizar pruebas de calidad converge hacia el aseguramiento de la eficiencia del producto antes de salir al mercado
Mdulo de pruebas de Caja Gris Testing Caja Gris

El test de caja gris combina los tests de caja negra y caja blanca. Este test hace pruebas con mtodos similares a los de la caja negra, simulando ataques reales. Sin embargo, a diferencia del test de caja negra, el atacante dispone de la informacin tcnica pertinente del sistema, y adems se le permite pedir informacin adicional sealada con comentarios como con los del test de caja blanca.
Este test es muy efectivo para identificar el mayor nmero real de amenazas como sea posible en el menor tiempo disponible, y por eso es la manera ms efectiva para efectuar evaluaciones de seguridad cuando los valores ms absolutos de las cajas blanca y negra no son necesarios. Pruebas realizadas con esta metodologa: Aplicacin de pruebas de penetracin (con la revisin de cdigo parcial). Test de la infraestructura y la red de penetracin (con revisin de la red y la configuracin del servidor.) Examen de alto nivel de diseo y construccin.
21

Las pruebas de caja negra (Black-Box Testing) son pruebas funcionales. Se parte de los requisitos funcionales, a muy alto nivel, para disear pruebas que se aplican sobre el sistema sin necesidad de conocer como est construido por dentro (Caja negra). Las pruebas se aplican sobre el sistema empleando un determinado conjunto de datos de entrada y observando las salidas que se producen para determinar si la funcin se est desempeando correctamente por el sistema bajo prueba. Las herramientas bsicas son observar la funcionalidad y contrastar con la especificacin
Tcnicas de caja negra:

Vulnerabilidades de tipo 'deface'; Vulnerabilidades de tipo 'cross-site scripting'; Vulnerabilidades de tipo 'spoofing'; Vulnerabilidades de tipo inyeccin de SQL; Vulnerabilidades de tipo inyeccin de cdigo; Vulnerabilidades derivadas de la validacin de entrada / salida; Vulnerabilidades derivadas del anlisis de tiempos; Vulnerabilidades de sincronizacin; Vulnerabilidades de tipo desbordamiento de memoria; Vulnerabilidades basadas en secuestro de sesiones; Vulnerabilidades en los equipos de la red local; Vulnerabilidades basadas en 'sniffing' de la red; Vulnerabilidades basadas en escaladas de privilegio; Vulnerabilidades en la gestin de contraseas. Inyeccin de cdigo; Autentificacin incompleta y gestin de sesiones; Referencias directas a objetos inseguros; Configuracin incorrecta de la seguridad de aplicaciones; Almacenamiento criptogrfico inseguro; Problemas de acceso a URLs restringidas; Proteccin del nivel de transporte insuficiente; Redirecciones no validadas.
Pruebas de caja blanca (White-Box Testing). Son pruebas estructurales. Conociendo el cdigo y siguiendo su estructura lgica, se pueden disear pruebas destinadas a comprobar que el cdigo hace correctamente lo que el diseo de bajo nivel indica y otras que demuestren que no se comporta adecuadamente ante determinadas situaciones.
Tcnicas de caja blanca
Ataques con conocimientos de la arquitectura del sistema; 22

Ataques con acceso a los detalles de las aplicaciones implantadas en la organizacin; Vulnerabilidades de abuso contra interfaces de programacin de aplicaciones; Vulnerabilidades de calidad de cdigo; Vulnerabilidades derivadas de la configuracin del sistema; Vulnerabilidades de los protocolos; Vulnerabilidades criptogrficas; Vulnerabilidades en la gestin de contraseas.
PRUEBAS DE STRESS DE SOFTWARE

Las pruebas de estrs prueba el software con un enfoque para comprobar que el software no se bloquea si los recursos de hardware (como memoria, CPU, espacio en disco) no son suficientes. Las pruebas de tensin ponen los recursos de hardware bajo extensos niveles de estrs con el fin de asegurar que el software es estable en un entorno normal. En las pruebas de estrs que cargar el software con un gran nmero de usuarios simultneos / procesos que no pueden ser manejados por los recursos de hardware de los sistemas. Prueba de estrs es un tipo de pruebas de rendimiento y es una prueba no funcional. Ejemplos: 1. Prueba de tensin de la CPU se llevar a cabo mediante la ejecucin de aplicaciones de software con 100% de carga durante algunos das, que aseguren que el software funciona correctamente en condiciones de uso normales. 2. Supongamos que usted tiene algn tipo de software que tiene requisito mnimo de memoria de 512 MB RAM la aplicacin de software ha sido probado en una mquina que tiene una memoria de 512 MB con cargas extensas para averiguar el sistema / el comportamiento del software. Las pruebas de estrs tienen un significado diferente para diferentes industrias donde se usa. Para un sector de la industria financiera /, que significa un proceso de prueba de los instrumentos financieros para determinar su robustez y nivel de precisin que pueden mantener en condiciones extremas, tales como la cada de la bolsa repentino o continuo a un cierto nivel, el cambio repentino o extremo en varios parmetros, por ejemplo, las tasas 23

de inters, repo y repo inversa utilizado en el sector financiero, la subida repentina o disminucin del precio de las materias que pueden afectar las proyecciones financieras, etc. para la industria manufacturera, puede incluir diferentes parmetros y procedimientos de operacin para las pruebas de los diferentes sistemas.
Para la industria mdica, las pruebas de estrs, un proceso que puede ayudar a entender la condicin del paciente, etc. Pruebas de Estrs en la industria de TI pruebas de estrs en la industria de TI (hardware, as como los sectores de software) la comprobacin de medios de software / hardware para su eficacia en dar consistente o rendimiento satisfactorio en condiciones extremas y desfavorables como el trfico pesado red, la carga procesos de pesada, debajo o por encima de reloj de hardware subyacente, que trabaja bajo peticiones mximos de utilizacin de los recursos de la periferia o en el sistema, etc. En otras palabras, ayuda a averiguar la nivel de robustez y rendimiento consistente y satisfactoria, incluso cuando los lmites establecidos para el funcionamiento normal del sistema (software / hardware) se cruza. Uso ms importante de las pruebas de tensin se encuentra en pruebas de software y hardware que se supone que deben estar operando en estado crtico o real tiempo situacin. Por ejemplo, un sitio web siempre estar en lnea y el servidor que aloja el sitio web debe ser capaz de manejar el trfico en todas las formas posibles (incluso si el trfico aumenta colector), un software de misin crtica o hardware que funciona en las pruebas de estrs verdadero escenario de tiempo, etc. en relacin con los sitios web o software determinado se considera como un proceso eficaz de determinar el lmite, en el que el sistema / software / hardware / sitio web robustez shows, est siempre disponible para realizar su funcin, administra de manera eficaz la carga que el escenario normal e Incluso muestra la gestin de errores eficaz en condiciones extremas. Necesidad de pruebas de estrs Se considera importante debido a razones siguientes: 1. Casi el 90% del software / sistemas son desarrollados con la suposicin de que estarn operando en el escenario normal. E incluso si se considera que el lmite de las condiciones normales de funcionamiento ser cruzada, que no es considerablemente tan alto como podra ser realmente. 2. El costo o efecto de una muy importante (crtico) de software / sistema / sitio web falla bajo condiciones extremas en tiempo real puede ser enorme (o puede ser catastrfico para la organizacin o entidad propietaria del software / sistema). 3. Siempre es mejor estar preparado para condiciones extremas en lugar de dejar que el sistema / software / sitio web choque, cuando el lmite de funcionamiento normal se cruza. 4. Pruebas llevadas a cabo por el desarrollador del sistema / software / sitio web puede no ser suficiente para ayudar a develar las condiciones que conducen a la cada del sistema / software cuando se presenta efectivamente al sistema operativo. 24

5. No siempre es posible dar a conocer los posibles problemas o errores en un sistema / software, a menos que se somete a este tipo de pruebas.
El servicio de pruebas de rendimiento de software se centra en determinar la velocidad con la que el sistema bajo pruebas realiza una tarea en las condiciones particulares del escenario de pruebas. Este servicio ayuda a su organizacin a detectar los cuellos de botella de su aplicacin, antes de que, sus usuarios sufran un mal rendimiento, con la consecuente prdida econmica y frustracin de sus clientes o empleados.
Pruebas de estrs: Conocidas como stress testing, muchas veces engloban de forma errnea al resto de pruebas mencionadas anteriormente. El objetivo de estas pruebas es obtener datos, sobre la carga del sistema, que ayuden a realizar el dimensionamiento del sistema o capacity planning. Esta prueba genera carga en el sistema hasta hacerlo inutilizable. Una vez que la aplicacin ha dejado de funcionar, nuestros consultores se centran en distintos objetivos, como por ejemplo: verificar la calidad de los mensajes de error del sistema o establecer alertas para poder anticipar un fallo total del sistema. Las pruebas de estrs son uno de los ltimos tipos de pruebas que se deben ejecutar, ya que, por su carcter poco realista, podra darse el caso de que la situacin de carga simulada nunca se diera en la vida real.
En el mundo de las pruebas de software es comn escuchar hablar errneamente de pruebas de prestaciones, para referirse a las pruebas de rendimiento. Estas ltimas son una categora que engloba el conjunto de pruebas mencionadas anteriormente. Las pruebas de rendimiento son ejecutadas por medio de scripts automatizados, stos se encargan de emular las acciones que realizara un usuario final sobre la aplicacin bajo pruebas. Los scripts se ejecutan en paralelo, cada uno de ellos emulando un usuario virtual, de esta forma, anticipando la carga esperada cuando el sistem a pase a produccin. Durante la ejecucin de las pruebas, nuestros consultores se encargan de vigilar el sistema, que recibe la carga por medio de indicadores de rendimiento, esta accin es comnmente llamada monitorizacin del sistema. En base a las mtricas obtenidas, Globe Testing sugiere mejoras para optimizar el rendimiento del sistema y, de esta forma, mejorar los tiempos de respuesta de la aplicacin.
25

26

Bibliografa
http://www.informaticajuridica.com/trabajos/Propuesta_Procedimiento_para_realizar_prue bas_Caja_Blanca_aplicaciones_desarrollan_lenguaje_Python.asp http://www.a2secure.com/auditorias/test-de-intrusion http://ingenierogestion.blogspot.mx/2009/06/pruebas-de-caja-negra-y-caja-blanca.html http://es.wikipedia.org/wiki/Caja_negra_(sistemas) http://herrorsoft.zxq.net/pruebacajanegra.html http://www.kybele.etsii.urjc.es/docencia/IS_LADE/20112012/Material/Pruebas%20de%20SoftwareHerraminetas.pdf http://es.wikipedia.org/wiki/Prueba_unitaria
27

Tipos de Pruebas

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tipos de Pruebas

Cargado por

Copyright:

Formatos disponibles

PRUEBAS DE RENDIMIENTO

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

PRUEBAS DE CAJA NEGRA

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Configuracin de las pruebas

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Establecer metas de desempeo

Servidor de tiempo de respuesta

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Rendir tiempo de respuesta

Las especificaciones de rendimiento

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Preguntas que debe hacer Pre-requisitos para pruebas de rendimiento

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

PRUEBAS ESTRUCTURALES O DE CAJA BLANCA

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Complejidad ciclo matica

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Herramientas para las pruebas JTest

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

PRUEBAS DE CAJA GRIS

Mdulo de pruebas de Caja Gris Testing Caja Gris

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

Tcnicas de caja negra:

Tcnicas de caja blanca

Ataques con conocimientos de la arquitectura del sistema; 22

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

PRUEBAS DE STRESS DE SOFTWARE

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

UNIVERSIDAD TECNOLOGICA DE TULA-TEPEJI

También podría gustarte