Codigo 200 HTTP

¿Es normal que marque el código 200 de HTTP en un test para una aplicacion Web?
Lo inquietante es que en una herramienta me lo marca como error.

2 Respuestas

Respuesta
1
La que estas utilizando, funciona exactamente asi, sacando el 200 de OK para tests. Lo que tienes que visualizar es el log que te genera la aplicación, no la página en si.
Gracias, por la aclarición, pero surgió la duda debido a que leí el siguiente artículo
The difference between HTTP success/failure codes and your Web applications success
This is probably the single most misunderstood area for inexperienced Web testers - although it is more related to functional testing it definitely comes into play when load/stress testing dynamic Web applications and so effects OpenSTA.
The misunderstanding is that the Web servers HTTP return codes somehow represent whether your dynamic Web application is successful. They don't, HTTP return codes represent only the Web servers idea of success or failure and this has very little to do with your Web application running on the Web server.
The usual complaints are my replay is successful, but my database has not been updated or I get no errors but I don't think my users are really logging in. The point here is that from the Web servers point of view it has done its job successfully; it accepted a HTTP request, used some dynamic page creation technique, and then returned the created page to the client - SUCCESS = HTTP 200 OK. It may be that the dynamic page creation (your Web application) was not happy with the contents of the HTTP request (bad login, sessionid, etc.) but this will not usually change the HTTP return code to failure - usually the Web application will just return page content describing the error or failure of the request.
Understanding this is important to be able to create load tests of dynamic Web applications with behaviour validation. If you solely rely on the HTTP return code you may miss errors such as failed logins, session failures, database connection errors, etc. etc. The only way to be sure your Web application is working properly is to check both HTTP status returns AND the content returned. Obviously the more checking you are doing in your scripts the less capacity your load generating machine will have (checks use resources) so you must decide how careful you want to be about this.
The OpenSTA recording process does not create any SCL in your scripts to check content. You must create these checks through SCL scripting techniques and capabilities.
Gracias
Lo que me indicas se refiere un poco mas al tema de la devolucion de páginas OK por parte del Sever, a través de scripts.
Para comprobar esto, tu servidor debe de almacenar cuantas páginas se han dado por OK y cuantas falladas. Esto lo tienen ultimamente muchos hospedajes y se actualiza diariamente, quizás te puedas descargar algo similar si tienes un IIS instalado o un Apache funcionando.
Siento no ser mas explicito en el tema, pues como habrás visto, no lo domino plenamente, aun asi.
Respuesta

Code 200 is a typical Windows mistake. Code 200 is typically brought about by missing framework documents, wrong framework settings or an adulterated vault record. Run a vault output to check for library blunders and other framework issues. buy an assignment online - assignmentsquare. Co. Uk.

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas