User Tools

Site Tools


en:problems:dsearch:testing
Testing 
 Testing

Testing

Adopt-ability means fully distributed (crawling, indexing and search front-end) at high speed, with fault tolerance and cost effective for users (and us). Possibly interested parties will expect it. Meanwhile, optimal resource allocation is the most challenging task in distributed systems. Hardship, hardship, …

  • Generating test data to cover the test criteria for testing a single node in its neighbourhood is more difficult than testing a stand-alone node because the number of possible paths increases significantly. Test cases must at a minimum cover the low level elements.
  • Testing certain components on distributed nodes can require the services of other components on other nodes. ⇒ Deadlocks and race conditions can occur. At least we do not have shared memory!
  • The order in which components of nodes are tested can also matter ⇒ Cycles among the components can occur.
  • We use several different languages, and different hardware and software platforms.
  • Reproducibility of events is hard because of concurrent processing and asynchronous communication.
  • Fault recovery, single point of failure and gracefully dealing with permanent and transient failures hardly ever gets tested. These must have explicit test cases.

(Future) performance analysis of a complex distributed systems is already essential during design time (to reduce development cost and risk). As with security, it can't be glued on later. We need a back-to-the-future and forward-to-the-past, or, an agile development approach on a test-bed, starting with one functional node. Controllability and observability of the test-bed is a must.


en/problems/dsearch/testing.txt · Last modified: 2020/03/10 14:42 by 66.249.79.113