Client-Server Architecture for QA Engineers

Web applications make a large share of the software market. It’s likely that you’ll get to work with such apps, so let’s start preparing. In this article, you’ll find the basic theory of client-server software architecture.

A client-server model is a distributed application structure that partitions tasks and/or workloads between a resource provider (server) and its requester (client). Web apps are good examples of client-server architecture.

A server is a computer that accepts HTTP requests from clients and issues HTTP responses to them.

A client is a computing device that sends requests to a server to perform specific tasks or provide specific information. Most often, a client is a browser. A response received in the form of site markup and other information allows the browser to display the elements of the user interface so that a person can interact with the software.

A web application is a client-server software, where a browser is a client, and a web server is a server. As a rule, the main part of the application is located on the web server side. The server processes the received requests following the product’s business logic and generates a response that is sent to a user. A browser converts the received response from the server into a graphical interface understandable to an ordinary user.

A database is a repository of information, an ordered model for the structured storage of information.

A data transfer protocol is a set of logic-level agreements that define the process of data exchange between the different programs, in particular:

  • what data will be transmitted;
  • what part of the system should act;
  • how it should act;
  • how the incoming information should be processed, etc.

Data Transfer Protocols

HTTP is a protocol that allows transmitting various hypermedia resources, such as HTML documents. The HTTP protocol was designed for communication between browsers and servers. It is the foundation of any data exchange on the internet.

HTTPS is the same protocol as HTTP. The letter S that appears stands for security. In other words, this protocol has encryption that prevents unauthorized access to user data. Data goes to a server via the HTTP protocol in the same form as a user sends it. Therefore, it is easy for an attacker to intercept this data and access the user’s personal information. In the HTTPS protocol, this data is encrypted and isn’t that easy to access.

FTP is one of the basic protocols for transferring files over a network between computers.

POP3 is the most common protocol for receiving emails. It allows us to download emails to a device (for example, a computer or smartphone) and delete them from the server.

Request and Response

As you’ve just learned, a client communicates with a server by sending requests to it. A server, in turn, provides responses to these requests. Every time a server receives a request, it answers with a specific code. Some of the most frequent codes users encounter are below:

  • 100 to 105 are information codes.
    100 – Continue: the server is satisfied with the request details, the client can continue to send information.
    102 – Processing: the request is accepted, but it takes a long time to process it. The server uses this error to prevent the client from dropping the connection due to the timeout.
  • 200 to 226 are success codes.
    200 – OK: the request has been successful.
    203 – Unauthorized information: the request has been successful, but the information comes from a secondary source and thus has been modified by a transforming proxy.
    204 – No content: the server successfully processed the request, but there is no additional content to send in response.
  • 300 to 307 report about redirecting.
    301 – Moved permanently: the requested document has been moved to a new URL address.
  • 400 to 499 are client errors.
    400 – Bad request: a syntax error occurred when receiving the client’s request.
    401 – Unauthorized: authentication is required to access the requested resource.
    403 – Forbidden: the server understands the request but refuses to fulfill it due to restrictions on the client’s access to the specified resource.
    404 – Not Found: the most common mistake, usually occurs when a web page address is misspelled.
  • 500 to 510 are server errors.
    500 – Internal server error: something has gone wrong on the website server’s side, but it cannot be more specific. In other words, it encompasses all the internal server errors outside the scope of other class errors.
    502 – Bad gateway: the server acting as a gateway or proxy server received an invalid reply message from an upstream server.
    503 – Service unavailable: the server is temporarily unable to process the requests for technical reasons (maintenance, overload, etc.).
    504 – Gateway timeout: the server’s waiting time exceeded the time given to receive a response.

Basic Principle and Models of Customer Interaction

The term client-server architecture outlines only the general principles of interaction between computers and general details of various protocols. This concept classifies the machines in the network as a client (send requests) and server ones (provide responses). The client always starts the interaction. The models of interaction between these machines, however, can vary. Thus, different types of client-server architecture can be employed.
For example, a two-tier architecture enables the interaction and data exchange between two participants – a client and a server. This type of architecture is suitable for business card sites that have a small amount of incoming and stored information.
More complex websites with larger amounts of data require three-tier architecture to ensure proper performance. In this case, there are three separate participants in the process: a client, a server, and a database. To return the response to the client, the server needs to access the information in the database first.

In Conclusion

Client-server architecture is a complex and interesting subject. If you start testing web applications, you will need to dive deeper into the details. Hopefully, the basic theory explained above will make it easier to understand more complicated things that come later on.

qaadmin

Recent Posts

Testing iOS Apps? Try These 11 Tools for Mobile QA

The saturated mobile app market makes businesses constantly reimagine the definition of quality. This never-ending…

12 months ago

Test Automation with Java: Why It’s Worth the Effort & How to Do It

Over half of the software companies use test automation. And almost all testing pros rely…

1 year ago

The One Swagger API Walk-Through to Answer All Your Questions

Imagine studying a language without dictionaries or manuals. Could you learn what each word means…

1 year ago

16 Interactive Platforms to Practice Your Software Testing Skills

For QA engineers, learning is a never-ending journey. While you can always expand and refresh…

1 year ago

How to Create Functional Tests with Extensive Coverage

Everyone can write decent functional test cases. Writing documentation for functional testing services that have…

1 year ago

How to Write Automation Scripts. The Basics AQA Engineers Should Know

Automation is now a priority. Nearly all QA specialists write automation scripts for their projects.…

1 year ago