Esta tabla permite al usuario filtrar los casos de prueba antes de verlos. Si los datos están seleccionados se mostrarán. Para cambiar los datos presentados, marcar o desmarcar, haga clic en el Filtro, y seleccione el nivel de datos que desee en el árbol.
Cabecera del documento: Los usuarios pueden filtrar la información de cabecera del documento. La información de cabecera del documento incluye: Introducción, alcance, referencias, Metodología de prueba y limitaciones de prueba.
Cuerpo del caso de prueba: Los usuarios pueden filtrar la información del cuerpo del caso de prueba. La información del cuerpo del caso de prueba incluye: resumen, pasos, resultados esperados y keywords.
Resumen del caso de prueba: Los usuarios pueden filtrar la información del resumen desde el titulo del caso de prueba, sin embargo, no pueden filtrar la información del resumen desde el cuerpo del caso de prueba. El resumen ha sido solo parcialmente separado del cuerpo del caso de prueba Body a fin de apoyar los títulos de visión con un breve resumen y la ausencia de Pasos, resultados esperados, y las keywords. Si el usuario decide ver el cuerpo del caso de prueba, el resumen también se incluirá.
Tabla de contenido: Testlink inserta una lista con todos los titulos con enlaces internos.
Formato de salida: Hay dos posibilidades: HTML y MS Word. El explorador llama al MS Word en segundo caso.
"; // testPlan.html $TLS_hlp_testPlan = "Un plan de pruebas es una aproximación sistemática a testear el sistema como un software. Puede organizar las actividades de testeo para una build en particular de un producto en timpo y con resultados de seguimiento.
Esta sección es donde los usuarios pueden ejecutar los casos de prueba (escribir los resultados) e imprimir la Suite de pruebas del plan de pruebas. Aquí es donde los usuarios pueden seguir el resultado de la ejecución de sus casos de prueba.
Esta sección, a la cual solo un líder puede acceder, permite administrar lo planes de pruebas.
Administrar planes de pruebas involucra crear/editar/borrar planes, agregar/editar/borrar/actualizar
casos de prueba en planes, crear builds así como definir quien puede ver cada plan.
Los lideres (usuarios con permisos de lider) también pueden establecer la prioridad/riesgo
y la propiedad de las suites de pruebas (categorías) y crear hitos de prueba.
Nota: Es posible que los usuarios no puedan ver un desplegable con todos los planes de pruebas. En esta situación todos los vínculos (excepto los habilitados por un lider) serán desvinculados. Si está en esta situación debe contactar a un lider o administrador lead or admin para concederle los derechos adecuados del proyecto o crear un plan de pruebas para usted.
"; // custom_fields.html $TLS_hlp_customFields = "Los siguientes son algunos hechos acerca de la implementación de campos personalizados:
La definición de un campo personalizado incluye los siguientes atributos lógicos:
Permite a los usuario a 'ejecutar' los casos de prueba. La ejecución en sí no es más que la asignación a un caso de prueba de un resultado (pasa, falla, bloqueado) contra una build seleccionada.
El acceso a un BTS puede ser configurado.Los usuarios pueden agregar un bug nuevo directamente o navegar por los existentes.
"; //bug_add.html $TLS_hlp_btsIntegration = "(Sólo si está configurado) Testlink tiene una integración muy simple con un BTS,no es capaz de enviar ni la solicitud de creación de bug de BTS, ni recuperar el ID del bug.La integración se realiza mediante enlaces a las páginas de BTS, que llama a las siguientes características:
El panel izquierdo consta de: un navegador por los casos de prueba asignados al plan de pruebas actual " . "y una tabla con configuraciones y filtros.Estos filtros permiten al usuario " . "refinar el conjunto ofrecido de casos de prueba antes de ser ejecutados." . "establezca su filtro, presione el botón \"Aplicar\" y seleccione el caso de prueba apropiado en el árbol.
Los usuarios pueden elegir una build que se conectará con el resultado de la prueba. " .
"Las Builds son el componente básico para el plan de pruebas actual.Cada caso de prueba " .
"puede ser corrido mas veces por build.Sin embargo, sólo el último resultado es tomado en cuenta.
Las builds pueden ser creadas por lideres usando la página de creacion de build.
Los usuarios pueden filtrar los casos de prueba por un identificador único. Este ID es creado automáticamente durante el tiempo de creación.La caja vacía significa que el filtro no se aplica.
Los usuarios pueden filtrar los casos de prueba por la prioridad. Cada importancia del" . "caso de prueba es combinada con la urgencia del mismo dentro del plan de pruebas actual." . "Por ejemplo la prioridad 'ALTA' en el caso de prueba se muetra si la importancia" . "o urgencia es alto y su segundo atributo es por lo menos 'MEDIA'.
Los usuarios pueden filtrar los casos de prueba por los resultados.Los resultados son lo que pasó con ese caso de prueba durante una build en particular.Los casos de prueba pueden pasar, fallar, ser bloqueados o no ejecutados.Este filtro está desactivado por defecto.
Los usuarios pueden filtrar los casos de prueba por su asignado.El recuadro permite incluír también " . "casos de prueba \"sin asignar\" dentro del resultado.
"; /*Por defecto o si el recuadro de 'Más reciente' está desmarcado, el árbol se ordenará por la build que se elija en menú desplegable. Es esta condición el árbol mostrará el estado de los casos de prueba.
*/ // newest_tcversions.html $TLS_hlp_planTcModified = "El conjunto de casos de prueba vinculados al plan de pruebas es analizado, y se muestra una lista de casos de prueba que tienen una versión más reciente (en contra de la serie actual del plan de pruebas).
"; // requirementsCoverage.html $TLS_hlp_requirementsCoverage = "Esta característica permite asignar cobertura de usuario o requerimientos de sistema por caso de prueba. Navegar a través de \"Especificación de requerimientos\" en la pantalla principal.
Los requerimientos estan agrupados por el documento'Especificación de requerimientos', el cual está relacionado
al proyecto.
Un usuario puede añadir una descripción simple o una nota al campo 'Alcance'.
Por ejemplo SRS incluye 200 requerimientos pero solo 50 son añadidos a Testlink. La cobertura de Test es del 25% (si todos estos requerimientos añadidos se testearan).
Haga click en el titulo de la Especificación de requerimientos creada,si no hay nada existente haga click en el proyecto para crear uno. Puede crear, editar, eliminar o importar requerimientos de un documento. Cada requerimiento tiene un titulo, un alcance y un estado. El estado debe ser 'Normal' o 'No testeable'. Los requerimientos no testeables no tienen contador para las métricas. Este parámetro debe ser usado tanto para características que no se han implementado como para requerimientos mal diseñados.
Puede crear nuevos casos de prueba para requerimientos usando la multi acción con requerimientos marcados dentro de la pantalla de especificación. Estos casos de prueba son creados dentro de la Suite de pruebas con nombre definido en la configuración. El título y alcance son copiados de estos casos de prueba.
"; $TLS_hlp_req_coverage_table = "