Assertion.ru

desarrollo de Conformidad prueba consiste en la identificación de las afirmaciones en un pliego, pruebas de conformidad por escrito que compruebe las afirmaciones identificados y la vinculación de la prueba de la afirmación de que lo pone a prueba.
Vamos a empezar desde los siguientes puntos:
- Afirmación está marcado
- La afirmación real es difícil ver en la especificación (en la actualidad sólo hay pequeñas gif afirmación al final de cada afirmación)
- Completa afirmaciones sólo son vistos por la lectura del código HTML directamente o buscando en cada prueba individual
- Inicio de las afirmaciones son difíciles de ver en el código html
- Proporcionar una forma visual para ver fácilmente la afirmación es el problema que estamos tratando de resolver.

El punto principal es que las afirmaciones de color (texto propio pliego de condiciones) con etiquetas HTML. La investigación que se hizo etiquetas html de usar. Div, span, mesa con etiquetas de fuente se miró. La mejor solución es la etiqueta de fuente. Así que el texto está rodeado con las etiquetas de la fuente. El atributo de clase de la etiqueta de fuente se corresponde con el tipo de afirmación. Fe si el asserion es nuevo es de color de rojo, para indicar, que las pruebas deben ser por escrito, las afirmaciones de edad se colorean con verde para indicar que las pruebas ya existentes. Debe haber una utilidad (java script o programa) para explorar marcado pliego de condiciones y automáticamente se añaden las etiquetas necesarias para colorear. El color de fondo del texto será determinado por el color atributo de título de la afirmación. Este método fue implementado y funciona correctamente. A efectos de la usabilidad, debe haber un mecanismo para ocultar la coloración, una fe Javascript.

Una desventaja de esta solución es que el color es estático ya que se basa en el atributo de título. Una segunda solución sería que el instrumento de verificación para una existencia de una prueba (basado en el ID de la afirmación o enlace en la afirmación). Si una prueba de que existe, queremos hacer algo para establecer el color de esta afirmación. Podría ser tan simple como el establecimiento de un atributo de título. Una desventaja de esta solución sería la afirmación de que la coloración se sigue estático, pero en base a cuando el usuario ejecute los scripts.

Una variante de la solución dada es que se generan de forma dinámica los datos de cobertura cuando la especificación es visto en un navegador. Queremos determinar si existe una prueba en el directorio de prueba para una afirmación y el color de la afirmación en consecuencia. Esto podría hacerse a través de un JavaScript / VBScript utilizando objetos, que permiten el acceso a sistema de archivos. Este método podría ser dinámica y siempre debe tener la condición última afirmación de la cobertura.

Éstos son algunos ejemplos de JLS3 capítulos "Conversiones y Promociones" y "Interfaces":

Las afirmaciones conv063, conv047, conv065, conv48, conv66 y conv049 son de la version anterior de las especificaciones, no se modificaron y actualizar las pruebas no es necesario - de color aguamarina es (verde neurtal). Conv155 y conv156 son nuevos, nuevas pruebas deben elaborarse, en las afirmaciones que están en el origen de color rojo. Conv064 fue modificada, es necesario actualizar la prueba - de color naranja. Annot019 es nuevo, las pruebas existen, pero son necesarias para cambiar - color salmón. Annot020 es nuevo, pero existen pruebas кудумфте - de color verde claro.

La principal ventaja de coloración en especifico es que la especificación se visualiza. El usuario puede ver la afirmación de todo y su título. Uno puede decir mirando a la especulación, donde hay áreas con baja cobertura, en algunos o muchos de los ensayos debe ser agregado o cambiado. Hay, básicamente, la posibilidad de ver qué tan bien una especificación es marcado y lo bien que se prueba.

• edad:
  texto no cambia, las pruebas no es necesario ningún cambio;
• oldToBeChanged:
  ha cambiado el texto, las pruebas tienen que ser cambiado;
• nuevo:
  totalmente nuevo texto, nuevas pruebas necesarias;
• newWritten:
  nuevo texto, pero las pruebas ya existentes (ya que el proceso de desarrollo de la prueba comenzó tan pronto como la especificación del proyecto está disponible);
• newWrittenToBeChanged:
  nuevo texto, las pruebas existentes, el proyecto de especificaciones cambiado, así que las pruebas hay que cambiar o pruebas existentes no son suficientes.

Sugerencia 2: algoritmo debe comprobar que la segunda ancla debe colocarse después de la primera y no muy lejos de eso.

1. Lee el texto antes y después de la etiqueta en las especificaciones de edad. Búsqueda en la nueva especificación. Si uno de ellos no se cambió - la respuesta se encuentra. por lo general la duración debe ser 1-2 sentances, al menos 60 caracteres de longitud. Si ninguno o varios sentances encontrados - omitir este paso.
2. Trate de hacer lo mismo que en (1), pero quitar todas las etiquetas HTML del texto cerca que rodea a la etiqueta. Si no encuentran - omitir este paso.
3. Pruebe el algoritmo de adoptar, que trata de encontrar un texto similar en la nueva especificación.
   una. Siga los pasos de (1) y (2), pero desrease la longitud de la búsqueda de texto en un bucle hasta que la Sentance se encuentra o la longitud es muy corta. El trabajo práctico demostró que este número no debe ser inferior a 20.
   b. Si los pasos (1) y (2), o (3 bis) encontraron varias sentances aumentar la longitud del texto a buscar hasta que el texto se encuentra en la nueva especificación o el límite superior (Fe 140 caracteres) que se llegó. Utilice pistas para encontrar el mejor texto coincidente.