¿Cómo validar correctamente su código?

Tengo alrededor de 4000 líneas de código para una aplicación web en JavaScript / PHP / CSS / HTML. ¿Cómo puedo probarlo correctamente?

Solo soporto la última versión de IE y Safari. He resuelto todos los errores. ¿Hay una buena manera de probarlo para poder llegar a llamar robusto al código?

He considerado usar Perl Mechanize para rellenar automáticamente formularios o hacer algo similar.

También tengo una clase de prueba de PHP para probar el funcionamiento interno de mis clases de PHP. Sin embargo, ¿hay algún tipo de norma o pautas de conformidad que se cumplan? ¿Hay alguna manera de decir que este código pasa los estándares IEEE xxx foo para robsustness de código, etc.?

He validado mi HTML usando validadores W3 y he validado mi JavaScript usando jslint.com.

Aquí está la lista de artículos de diligencia:

1. HTML / CSS pasa la validación W3
2. JavaScript pasa jslint
3. PHP pasa la clase de prueba PHP interna

Pruebas de usuario

1. Cree un conjunto de acciones de usuario e implemente usando Perl Mechanize o similar.

¿Existen estándares o procedimientos para publicar código en la web?

La validación de software es un área enorme, no hay una respuesta definitiva a su pregunta. Además, el ingeniero de validación de software suele ser un puesto especial que requiere mucho más conocimiento que desarrollo y muchas habilidades (como, por ejemplo, "especificación de depuración" que realmente no es trivial) que ahora son comunes en la comunidad de desarrolladores.

En segundo lugar, la validación de software (y la validación de código como parte esencial de la misma) no es una prueba. Hay una famosa cita de Dijkstra:

Las pruebas muestran la presencia, no la ausencia de errores.

Por lo tanto, esta es la principal diferencia con la validación del software (es decir, declarar que su software es válido, no contiene errores) y las pruebas (para errores o errores potenciales).

Si reducimos su pregunta a "¿cómo validar adecuadamente una aplicación web basada en PHP?" Puedo dar la siguiente respuesta:

Análisis de manchas.

Hay algunas herramientas ordenadas ( 1 , 2 ) para realizar análisis de manchas en PHP. Este es un análisis estático (que significa que se realiza sin ejecutar su código) que identifica posibles sumideros (fugas) de información confidencial.

He usado algunas de estas herramientas ( Pixy ) en mi propia práctica y descubrí que, como todas las otras herramientas en el análisis estático, parecen sobreestimar el peligro potencial. No obstante, pueden ayudarlo a identificar algunos problemas de seguridad que quizás no conozca. Esto es especialmente importante para las aplicaciones web que manejan algunos datos confidenciales.

Esto no excluirá todas las vulnerabilidades posibles, como XSS, pero cubrirá muchas comunes, como código PHP e inyecciones SQL, etc.

Validación de conformidad.

Este paso ya lo hizo al ejecutar validadores JSLint y CSS / HTML en su sitio web completo.

Pruebas de carga.

Si la disponibilidad de su aplicación web es un problema (o incluso una parte de su SLA), entonces también realizaría algunas pruebas de carga. Estos pueden ser generados por algunos IDEs, como Visual Studio, o también puede usar el marco JMeter de código abierto para estos fines.

Los estándares son tan buenos como las personas que los hacen cumplir. (especialmente cierto con los estándares de calidad ISO ...)

Si desea probar completamente su software, necesita una buena especificación de requisitos que pueda usarse para verificar el hecho de que ha logrado / implementado todas las tareas / características / etc. tal como deberían implementarse. También ayuda tener a alguien más para mirar el proyecto desde una perspectiva de control de calidad / prueba de software (desde revisiones de código hasta pruebas exploratorias de usuarios).

Otra nota que es posible que desee considerar es el hecho de que sin una especificación de requisitos clara como desarrollador, lo más probable es que asuma cosas como 'características' en lugar de 'errores' :)

Existen estándares IEEE para especificaciones de requisitos (IEEE 830) y planes de prueba (IEEE 829). Sin embargo, creo que son un poco OTT para muchos proyectos.

(También estoy un poco sorprendido de que no tenga una base de datos)

La respuesta no es popular.

Debes hacer que los usuarios lo superen. Después de haber agotado la lista de errores reportados después de muchas iteraciones de prueba, solo puede llamar a su código robusto.

Probarlo solo será de poca utilidad porque está en la codificación de los árboles y no puede ver el bosque.

¿No sabes que los desarrolladores son los peores probadores? Soy desarrollador y sé esto solo después de muchos años de caer de bruces después de decir con orgullo, "esto funciona perfectamente en mi computadora portátil".