Što je testiranje komponenti? Tehnike, primjeri testnih slučajeva

By: Thomas Hamilton Thomas Hamilton
Hours Ažurirano

⚡ Pametni sažetak

Component Testing checks each individual part of an application on its own, without integrating it with the rest, so that defects are found and fixed inside a single module before assembly begins.

  • 🧩 Opseg: One component at a time, isolated from the components around it.
  • 👥 Vlasnik: Testers run it, after developers complete unit testing.
  • 🔬 CTIS: Component Testing in Small isolates the component completely.
  • 🔗 CTIL: Component Testing in Large keeps the dependencies, real or simulated.
  • 🧱 Doubles: A driver calls the component; a stub is called by it.
  • ✅ Izlaz: No Critical, High or Medium defect stays open in the log.
Pročitaj više

Component Testing techniques and example test cases

Što je testiranje komponenti?

Ispitivanje komponenti is a software testing type in which testing is performed on each individual component separately, without integrating it with other components. Viewed from an architecture perspective it is also called testiranje modula, and some references call it program testing.

Any software as a whole is made of several components, and component level testing deals with testing those components individually. It is one of the most frequent testiranje crne kutije types performed by the QA team.

A note on naming is worth making early. The ISTQB glossary treats component testing and ispitivanje jedinice as synonyms for the same test level. Many delivery teams, and this article, keep the two apart in practice: developers run unit tests on their own code, and testers then run component tests on the delivered build. The comparison table at the end of this article sets out that practical distinction.

As the diagram below shows, component testing has its own test strategy and test plan, in which each part of the software or application is considered individually. For each component a testni scenarij is defined, which is then broken down into high level test cases and finally into low level detailed test slučajevi with prerequisites.

Component testing hierarchy from test strategy down to low level test cases

The way the term “component testing” is used varies from domain to domain and from organisation to organisation. The most common reasons for that difference in perception are the three below.

  1. The type of development life cycle model chosen
  2. The complexity of the software or application under test
  3. Whether testing is done with or without isolation from the other components in the application

The software test life cycle produces many test artifacts, meaning the documents created and used during testing activities. Among them it is the test policy and the test strategy that define which types of testing are used and how deep the testing goes in a given project.

Tko radi testiranje komponenti

Component testing is performed by testers. Unit testing is performed by the developers, who test an individual function or procedure. Once unit testing is complete, component testing follows, and the testers take ownership of it.

Kada izvršiti testiranje komponente

Component testing is performed soon after unit testing is done by the developers and the build is released to the testing team. That build is referred to as the UT build, or Unit Testing build. The major functionality of every component is tested in this phase.

Ulazni kriteriji za testiranje komponenti

  • The minimum set of components to be included in the UT build has been developed and unit tested.

Izlazni kriteriji za testiranje komponenti

  • The functionality of every component works as specified.
  • No Critical, High or Medium severity or priority defect remains open in the defect log.

Tehnike ispitivanja komponenti

Based on the depth of the testing level, component testing is categorised in two ways.

  1. CTIS — Component Testing in Small
  2. CTIL — Component Testing in Large

CTIS — Component Testing in Small

Component testing may be done with or without isolation from the other components in the application under test. When it is performed with the other components isolated, it is referred to as component testing in small.

Primjer 1: On a website with five different web pages, testing each web page separately and in isolation from the other components is component testing in small.

Primjer 2: The guru99.com home page shown below carries many components, such as Home, Testing, SAP, Web, Must Learn!, Big Data, Live Projects and Blog.

Guru99 home page navigation menu treated as separate testable components

Any software is made of many components in the same way, and every component has its own subcomponents. Testing each module listed in Example 2 separately, without considering its integration with the other components, is component testing in small.

Opening the Testing drop-down menu reveals the subcomponents of the Testing component: Ručno ispitivanje, SOAPUI, QTP, JUnit, Selenium, Test Management and Mobilno testiranje. In the snapshot below those subcomponents are highlighted in red.

Testing drop-down menu with its subcomponents highlighted in red

POVEZANI ČLANCI

CTIL — Component Testing in Large

Component testing done without isolation from the other components in the application under test is referred to as component testing in large.

An example makes the difference clearer. Suppose an application consists of three components: Component A, Component B and Component C.

The developer has built Component B and wants it tested. To test Component B completely, some of its functionality depends on Component A and some on Component C, as the diagram below illustrates.

Component B tested with a driver replacing Component A and a stub replacing Component C

The functionality flow is A → B → C, which means Component B depends on both A and C. In that flow the stub is the called function and the driver is the calling function.

Component A and Component C have not been developed yet. To test Component B completely, A and C are replaced by a driver and a stub as required, so the two missing pieces act as dummy objects until the real ones exist.

  • Završetak: a stub is called by the component under test. Component C is not ready, so a stub stands in for it and returns the responses B expects.
  • Vozač: a driver calls the component under test. Component A is not ready, so a driver stands in for it and invokes B with the required inputs.

Primjeri testnih slučajeva za testiranje komponenti

The two web pages below are interrelated from a functionality point of view, which makes them a useful pair of components to test.

Web page 1 is the login page of the demo banking site.

Login page component with user id and password fields

When the user enters a valid user id and password and clicks the submit button, the page navigates to the home page of the demo bank website, shown next.

Manager home page component with navigation links and images

Here the login page is one component and the home page is another. Testing the functionality of each page separately is component testing.

Component testing scenarios on web page 1:

  • Enter an invalid user id and verify that a user-friendly warning is shown to the end user.
  • Enter an invalid user id and password, click Reset, and verify that the user id and password fields are cleared.
  • Enter a valid user name and password and click the Login button.

Component testing scenarios on web page 2:

  • Verify that the welcome message for the manager page is displayed on the home page.
  • Verify that all the links on the left side of the web page are clickable.
  • Verify that the manager id is displayed in the centre of the home page.
  • Verify the presence of the three different images on the home page, as per the diagram.

Jedinično testiranje nasuprot testiranju komponenti

The table below summarises how the two levels differ in everyday practice.

Ispitivanje jedinice Ispitivanje komponenti
Testing individual programs and modules to demonstrate that the program executes as per the specification. Testing each object or part of the software separately, with or without isolation from other objects.
Validated against design documents. Validated against test requirements and use cases.
Izradili programeri. Izvršeno od strane testera.
Done first. Done after unit testing is complete at the developers’ end.
Defects are usually fixed on the spot and not formally logged. Defects are logged and tracked through the defect management process.

Pitanja i odgovori

Reducing risk, verifying functional and non-functional behaviour of the component, building confidence in its quality, finding defects, and preventing those defects from escaping into higher test levels.

Models read a component contract and propose the invalid inputs, boundary values and error paths a manual pass tends to miss. A tester still confirms every expected result before execution.

Yes. A stub returning canned responses and a driver feeding fixed inputs are formulaic code an assistant writes quickly. Deciding which responses are realistic remains a human call.

Component testing examines one component on its own. Component integracijsko testiranje examines the interfaces and interactions between components, and runs after component testing.

Code-level frameworks such as JUnit, TestNG, NUnit and pytest, plus UI component runners such as Cypress Component Testing, Storybook and Jest. All of them slot into an automatizacija cjevovod.

Building and maintaining the doubles. A stub that drifts away from the real component hides defects until integration, so every simulated response needs revisiting once the real dependency ships.

It reverses the order. Cases are written and automated before the component exists, then code is added until they pass. The component arrives with its test suite already in place.

Both, depending on who runs it. Testers work black box against the component specification, while developers with code access apply bijela kutija coverage inside the same component.

Sažmite ovu objavu uz: