什么是组件测试？技术、测试用例示例

由： 托马斯·汉密尔顿 托马斯·汉密尔顿
Hours 更新

⚡ 智能摘要

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.

  • 🧩 范围： One component at a time, isolated from the components around it.
  • 👥 所有人： 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.
  • ✅ 退出： No Critical, High or Medium defect stays open in the log.
阅读更多

Component Testing techniques and example test cases

什么是组件测试？

组件测试 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 模块测试, 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 黑盒测试 types performed by the QA team.

A note on naming is worth making early. The ISTQB glossary treats component testing and 单元测试 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 测试场景 is defined, which is then broken down into high level test cases and finally into low level detailed 测试用例 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.

谁做组件测试

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.

何时进行组件测试

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.

组件测试的准入标准

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

组件测试的退出标准

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

组件测试技术

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.

例如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.

例如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: 手动测试SOAPUI， QTP, JUnit, Selenium, Test Management and 移动测试. In the snapshot below those subcomponents are highlighted in red.

Testing drop-down menu with its subcomponents highlighted in red

相关文章

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.

  • 存根： 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.
  • 司机： 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.

组件测试的示例测试用例

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.

单元测试与组件测试

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

单元测试 组件测试
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.
由开发人员完成。 由测试人员完成。
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.

常见问题

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 集成测试 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 自动化 管道。

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 白盒 coverage inside the same component.

总结一下这篇文章：