¿Puedo evitar más fallos si utilizo diferentes paradigmas para la implementación y las especificaciones / pruebas?

7

Como es conveniente para el desarrollador, el mismo paradigma se usa a menudo para implementaciones y especificaciones, por ejemplo,

  • para pruebas (por ejemplo, Java para la implementación y pruebas unitarias, Scala para la implementación y pruebas de propiedad)
  • para pruebas basadas en modelos (por ejemplo, C # para la implementación y las especificaciones que utilizan Spec Explorer, o Java para la implementación y las especificaciones que usan Conformiq)
  • para verificación (por ejemplo, C para algunas aplicaciones y especificaciones integradas en el lenguaje C-like Promela para la verificación de modelos, o Dafny, que integra la implementación y la especificación).

Incluso parece haber una tendencia en esta dirección.

Siempre pensé que usar diferentes paradigmas ayudaría a pensar en diferentes niveles de abstracción y más generalmente en diferentes estructuras, y que las fallas podrían detectarse mucho mejor de esa manera, al comparar la implementación con las pruebas / especificación (similar a usar diversidad de diseño para sistemas tolerantes a fallas).

¿Entonces es cierto que los diferentes paradigmas para la implementación y especificación pueden evitar más fallas? ¿Tienes una referencia citable?

    
pregunta DaveFar 11.07.2015 - 16:09

3 respuestas

1

Esto no está completamente relacionado, pero si incluye lenguajes de especificación formal, tiene beneficios al anotar su código con invariantes y contratos formales.

Consulte, por ejemplo, el manual de referencia de ACSL , para C. Lo mismo ocurre con Ada, que permite forall Expresiones que no son parte del lenguaje, pero están disponibles para especificaciones: enlace . Además, puede consultar ACL2 .

Cuando se trata de pruebas, puede consultar Basado en el modelo Pruebas : define un modelo que es útil solo para pruebas.

A menudo es más fácil describir la prueba de una manera funcional que transmite claramente lo que debe hacer la implementación, en lugar de cómo .

    
respondido por el coredump 13.07.2015 - 19:34
1

Creo que lo que quieres es cierto nivel de formalismo, consulta Métodos formales . Esta es la única forma garantizada de obtener menos fallos mediante el uso de diferentes paradigmas, ya que el uso de algo diferente también tiene el potencial de dar fallas diferentes (incluso las correcciones producen errores).

Hacer la implementación en un nivel más cercano a las matemáticas le dará la posibilidad de tener algún nivel de prueba matemática, lo que significa que no tendrá fallas y posiblemente eliminará la necesidad de las pruebas.

Este enlace De HOL a Haskell y Fundamentos de software debe ilustrar ideas de cómo utilizar la especificación en desarrollo en el probador de teoremas y luego traducirla al lenguaje de programación. Un artículo habla sobre el uso de Isabelle / HOL y haskell, el otro trata sobre el uso de Coq, que luego puedes traducir a scala usando alguna herramienta.

Debido a que toma más tiempo hacerlo formalmente, solo una pequeña cantidad de código se desarrolla de esta manera.

    
respondido por el imel96 31.07.2015 - 06:45
0

En mi opinión, como persona de control de calidad, uno no necesita realmente diferentes paradigmas de prueba. Muchos no estarán de acuerdo con esta afirmación, pero solo hay un método necesario que es simplemente probar todos los casos de borde conocidos de lo que sea. La teoría es simplemente Min, Min-1, Min + 1, Max, Max-1 y Max + 1, Null y / o Cadena vacía. Si se prueba cada uno de esos bordes, tienes un código a prueba de balas.

La gente dirá tonterías y usará términos sofisticados como extremo a extremo, caja negra, caja blanca, caja gris, prueba unitaria, prueba de aceptación del usuario, prueba unitaria, integración, pruebas de componentes y sistemas, hablarán sobre aleatoriedad , enfoques estadísticos. Todo lo anterior se reduce a los casos de Edge como el método a utilizar. Las pruebas de casos perimetrales se pueden ejecutar manualmente, automatizadas, etc.

Finalmente, los estudios muestran que > el 70% de todos los errores se introducen antes de que el desarrollador entregue el código al control de calidad. ¿Qué significa esto? ¡Significa que el mejor esfuerzo para la automatización es la prueba unitaria! Ahora considere esto, el 90% de todos los desarrolladores dicen que "Las pruebas unitarias no están integradas en mi programa" ... El resultado es que el código a prueba de balas se entrega continuamente al control de calidad, pero el control de calidad solo puede alcanzar 20-50 % de todos los errores ya que normalmente no pueden ver el código ...

Escribir casos de prueba en el lenguaje que usan los desarrolladores es bueno porque ahora los desarrolladores pueden contribuir y mantener la biblioteca de pruebas de unidad. La gente de control de calidad debe integrarse con los desarrolladores y escribir pruebas a medida que se crea el código. Los talones de prueba se pueden escribir solo a partir de una especificación y hacen que la prueba esté casi lista para cuando el código esté allí.

Es cierto que los desarrolladores simplemente no tienen el tiempo adecuado para desarrollar buenas Pruebas de unidad dados los rápidos horarios de hoy.

    
respondido por el John Peters 31.07.2015 - 00:40

Lea otras preguntas en las etiquetas