Screen Scraper
Screen ScraperScreenScrapers ignore the underlying structure of an interface or application to just parse the human oriented display. They are often the simplest method of interfacing to a legacy application and can be very useful.
Screen Scraping often lives atop legacy systems that assume an 80x24 (or 80x25) display. Display type and fonts aren't an issue, because the scrapers deal with characters, not glyphs. Geometry is a non-issue if the legacy system in the "life support" phase of its lifecycle, with a never-again-to-be-changed UserInterface.
This sort of communication with legacy systems is often the domain of technologies like LU 2.0 HllApi? (an API for reading 3270 and 5250 screens called the HighLevelLanguage API -- meaning CeeLanguage) and was extremely common between 1990 and 1999 when client-server systems were in vogue. Since then other options for communication with legacy CobolLanguage systems have come into play, such as TCP Sockets, MQSeries and even EnterpriseJavaBeans.
The phrase is also used for some GuiTesting tools which attempt to run at the ScreenScraper level. E.g they watch a test developer click, remember (x,y) locations and characters typed, and then record the actions in a script for later replay to provide a test.
This does not work (see GuiTesting).
First, any variation in geometry, display type, fonts, etc invalidates the replay and at least requires editing the recorded script.
Secondly, any redesign of the GUI screen to have different functionality, layout, etc will require redoing the test creation effort. Hence this technology can not provide a useful level of RegressionTesting across releases.
Much moved to TestingGraphicsSystems
The term is also applied to HTML, XHTML, et. al., for extracting information from websites. -- thoran
EditText of this page
(last edited February 13, 2005)
or FindPage with title or text search