Chuong 3 DBCLKTPM Noi Dung 3 - NCDanh

Chương 3
CÁC THÀNH PHẦN ĐẢM BẢO CHẤT

LƯỢNG PHẦN MỀM TRONG VÒNG
ĐỜI DỰ ÁN
Nội dung 3: Các giai đoạn và chiến lược kiểm thử
phần mềm
TS. Nguyễn Công Danh
(ncdanh@cit.ctu.edu.vn)
Khoa Công nghệ phần mềm
Trường CNTT&TT – Trường Đại học Cần Thơ
Năm 2023
Đảm bào chất lượng và Kiểm thử phần mềm 1

Nội dung Chương 3
• Tích hợp các hoạt động SQA vào vòng đời dự án
• Xét duyệt (Review)
• Các gian đoạn và chiến lược kiểm thử phần mềm
• Các phương pháp kiểm thử phần mềm (Testing Methods)
• Kiểm thử hộp đen (black-box testing)
• Kiểm thử hộp trắng (white-box testing)
• Các vấn đề khác

Các giai đoạn và chiến lược kiểm thử phần
mềm
• Định nghĩa kiểm thử phần mềm
• Các giai đoạn kiểm thử phần mềm (Testing Levels)
• Các chiến lược kiểm thử phần mềm (Testing Strategy)

Định nghĩa kiểm thử phần mềm
• “Kiểm thử phần mềm là một quy trình hình thức được
thực hiện bởi một nhóm kiểm thử chuyên nghiệp,
trong đó một đơn vị phần mềm (software unit), một
tích hợp của nhiều đơn vị phần mềm, hoặc toàn bộ gói
phần mềm được kiểm tra bằng cách chạy các chương
trình trên máy tính. Tất cả các kiểm thử được thực
hiện dựa theo các thủ tục kiểm thử đã được phê
duyệt cho các ca kiểm thử đã được phê duyệt.”
Các giai đoạn (cấp độ) kiểm thử phần mềm
(Testing levels) (1)
Test system as a whole
Requirement Preparation of acceptance User Acceptance - customer
Analysis test cases Testing requirements
(by end user/customer)
Software
requirement Systems System Test system as a whole
specification test cases Testing (by tester)
Architectural Integration Integration Test component groups

design test cases Testing (by developer or tester)
Unit test Unit Testing Test individual component

Module design
• Unit Testing cases (by developer)
• Integration Testing
• System Testing
Coding
• User Acceptance Testing (UAT)
Các giai đoạn kiểm thử phần mềm (2)
• Unit Testing
• Một đơn vị (unit) là phần nhỏ nhất của phần mềm mà ta có thể kiểm thử được. Nó thường có một
hoặc một vài đầu vào và thường có một đầu ra duy nhất.
• Ví dụ: một chức năng (function), phương thức (method), thủ tục (procedure), mô-đun hoặc đối tượng
(object) riêng lẻ.
• Mục đích: để xác nhận (validate) rằng mỗi đơn vị của mã phần mềm (unit of the software code) hoạt
động như mong đợi (performs as expected); nói cách khác để xác nhận rằng mỗi đơn vị của phần
mềm thực hiện đúng với thiết kế.
• Kiểm thử đơn vị cách ly một phần mã (isolate a section of code) và xác minh tính (verify) đúng đắn
của nó (correctness). Nó đảm bảo thông tin được xử lý và kết xuất (khỏi unit) chính xác, trong mối
tương quan với dữ liệu nhập (input) và chức năng xử lý của unit. Điều này đòi hỏi tất cả các nhánh bên
trong unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi.
• Kiểm thử đơn vị là kỹ thuật kiểm thử hộp trắng (white-box testing).
• Kiểm thử đơn vị thường được thực hiện bởi các nhà phát triển (developer).
• Kỹ thuật kiểm thử đơn vị:
✓ Kiểm tra đường dẫn cơ sở (Basis path testing)
✓ Kiểm tra cấu trúc điều khiển (Control structure testing)
✓ Bao phủ điều kiện (Conditional coverage)
✓ Bao phủ vòng lặp (Loops coverage) (Nguồn: https://www.guru99.com/unit-testing-guide.html)
✓ Kiểm thử đột biến (Mutation testing)
Ví dụ về kiểm thử đơn vị trong C# dùng MS Unit Test
(Nguồn: https://www.c-sharpcorner.com/article/a-basic-introduction-of-unit-test-for-beginners/)
• Integration Testing
• Trong Kiểm thử tích hợp, các mô-đun phần mềm riêng lẻ được tích hợp một cách hợp lý
và được kiểm thử theo nhóm.
• Mục đích: để tìm ra lỗi trong quá trình tích hợp các thành phần, mô-đun lại với nhau;
kiểm thử tích hợp tập trung vào kiểm tra giao tiếp dữ liệu giữa các mô-đun này.
• Kiểm thử tích hợp có thể thực hiện bằng kiểm thử hộp trắng hoặc hộp đen.
• Kiểm thử tích hợp được thực hiện bởi các nhà phát triển hoặc nhóm kiểm thử
(developer/tester).
• Chiến lược (tiếp cận):
✓ Big bang
✓ Tăng trưởng (Incremental Approach)
✓ Tiếp cận từ trên xuống (Top Down Approach)
✓ Tiếp cận từ dưới lên (Bottom Up Approach)
✓ Tiếp cận bánh sandwich (Sandwich Approach)
(Nguồn: https://www.guru99.com/integration-testing.html)
Ví dụ về kiểm thử tích hợp cho ứng dụng web (1)
• “Tôi là chủ sở hữu của một công ty quảng cáo và tôi đăng
quảng cáo trên các trang web khác nhau. Vào cuối tháng,
tôi muốn xem có bao nhiêu người đã xem quảng cáo của
tôi và có bao nhiêu người nhấp vào quảng cáo của tôi. Tôi
cần một báo cáo cho quảng cáo của mình được hiển thị và
tôi tính phí cho khách hàng của mình.”
• “Phần mềm GenNext đã phát triển sản phẩm này cho tôi.”
• Slide kế tiếp là kiến trúc.
(Nguồn: https://www.softwaretestinghelp.com/what-is-integration-testing/)
UI - Mô-đun UI (Giao diện người dùng), hiển thị cho người
dùng cuối, nơi tất cả các đầu vào được cung cấp.
BL
BL - Là mô-đun Business Logic, có tất cả các tính toán và
phương thức (hàm) tính toán kinh doanh cụ thể.
VAL - Là mô-đun Validation (Xác thực), làm tất cả các xác
UI thực về tính chính xác của đầu vào.
EN-Engine
CNT - Là mô-đun Content (Nội dung) có tất cả các nội dung
VAL DB tĩnh, dành riêng cho các đầu vào được nhập bởi người dùng.
Những nội dung này được hiển thị trong các báo cáo.
Front Layer EN - Là mô-đun Engine (Động cơ), mô-đun này đọc tất cả
CNT dữ liệu đến từ mô-đun BL, VAL và CNT và trích xuất truy vấn
SQL và kích hoạt nó vào cơ sở dữ liệu.
Scheduler- Là mô-đun xếp lịch tất cả các báo cáo dựa trên
Scheduler lựa chọn của người dùng (hàng tháng, hàng quý, nửa năm và
hàng năm)
Middle Layer Back Layer DB - Là cơ sở dữ liệu.
Ví dụ về kiểm thử tích hợp cho
ứng dụng web (3)
• Các câu hỏi được đặt ra là:
1. Làm thế nào các mô-đun BL, VAL và CNT đọc và hiểu được
dữ liệu được nhập trong mô-đun UI?
2. Các mô-đun BL, VAL và CNT có nhận được dữ liệu chính xác từ UI không?
3. Định dạng nào dữ liệu từ BL, VAL và CNT được chuyển đến mô-đun EN?
4. EN sẽ đọc dữ liệu và trích kết quả của các câu truy vấn (query) như thế nào?
5. Các câu truy vấn có trích ra dữ liệu (kết quả) chính xác?
6. Scheduler có nhận dữ liệu chính xác cho các báo cáo?
7. Tập kết quả mà EN nhận được, từ cơ sở dữ liệu, có đúng và như mong đợi
không?
8. EN có khả năng gửi phản hồi trở lại mô-đun BL, VAL và CNT không?
9. Là mô-đun UI có thể đọc dữ liệu và hiển thị nó phù hợp với giao diện?
• Thực tế, việc truyền dữ liệu được thực hiện theo
BL
định dạng XML. Vì vậy, bất kỳ dữ liệu nào người XML XML
dùng nhập vào UI, nó sẽ được chuyển đổi thành UI XML

XML
XML EN-Engine
định dạng XML. VAL
DB
XML
• Trong kịch bản của chúng ta, dữ liệu được nhập Front Layer
CNT
XML
XML
trong mô-đun UI được chuyển đổi thành tập tin
Scheduler
XML, được diễn giải bởi 3 mô-đun BL, VAL và
CNT. Mô-đun EN đọc tệp XML kết quả được tạo Middle Layer Back Layer
bởi 3 mô-đun và trích xuất SQL từ nó và truy vấn

vào cơ sở dữ liệu. Mô-đun EN cũng nhận được tập
kết quả và chuyển đổi nó thành tệp XML và đưa nó
trở lại mô-đun UI để chuyển đổi kết quả ở dạng
người dùng có thể đọc được và hiển thị nó.
• Do đó, kiểm thử tích hợp sẽ kiểm tra: XML
BL
XML
• xem thông tin/dữ liệu có lưu chuyển chính UI

XML
XML
xác hay không? (trong trường hợp này sẽ
XML EN-Engine
VAL
XML DB
kiểm tra các tập tin XML) Front Layer XML
CNT XML
• xem các tập tin XML có được tạo chính
Scheduler
xác không? chúng có dữ liệu chính xác
Middle Layer Back Layer
không?
• xem dữ liệu có được chuyển đổi đúng đắn
từ một mô-đun này sang mô-đun khác?
• System Testing
• Test ở mức hệ thống (tích hợp toàn bộ các chức năng thành một phần mềm) kiểm
tra tất cả chức năng của ứng dụng tương ứng với các yêu cầu khách hàng.
• Mục đích: để đánh giá hệ thống tuân thủ đúng với đặc tả yêu cầu khách hàng.
• Đây là kỹ thuật kiểm thử hộp đen (black-box testing).
• Kiểm thử này được thực hiện bởi nhóm kiểm thử (tester).
• Trước khi kiểm thử hệ thống, chúng ta nên biết các yêu cầu của khách hàng.
• Kiểm thử hệ thống tập trung vào các khía cạnh dưới đây:
✓ Kiểm thử giao diện người dùng (GUI) (User Interface Testing)
✓ Kiểm thử chức năng (Functional Testing)
✓ Kiểm thử phi chức năng (Non-Functional Testing)
✓ Kiểm thử khả năng sử dụng (Usability Testing)
• User Acceptance Testing (UAT)
• Mức test này giống như system test nhưng thường được khách hàng
thực hiện test.
• Mục đích: để đánh giá hệ thống tuân thủ đúng với yêu cầu của khách
hàng và có thể chấp nhận hay không chấp nhận để bàn giao sản
phẩm.
• Kiểm thử này chia làm 2 loại (dùng cho phần mềm đóng gói sẵn để
bán):
✓Alpha
✓Beta

Kiểm thử này được thực hiện:
- bởi ai (who)?
• Alpha Testing -
-
ở đâu (where)?
như thế nào (how)?
• Apha testing là kiểm thử sự hoạt động chức năng thực tế
hoặc giả lập do người dùng/khách hàng tiềm năng hoặc
một nhóm test độc lập thực hiện tại nơi sản xuất phần
mềm.
• Alpha testing thường dùng cho phần mềm đóng gói sẵn để
bán (ví dụ như MS Office, Windows, chương trình diệt
virus) là một hình thức kiểm thử chấp nhận nội bộ, trước khi
phần mềm được tiến hành kiểm thử beta.
• Beta Testing
• Beta testing được thực hiện sau Alpha testing.
• Các phiên bản của phần mềm - được biết như là các phiên bản beta –
chúng được phát hành tới một số lượng giới hạn khán giả bên ngoài
nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một số
nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm
có một số bug.
• Thỉnh thoảng, các phiên bản beta được phát hành rộng rãi để
tăng phạm vi phản hồi từ một lượng người sử dụng tương lai lớn
nhất.
Các chiến lược kiểm thử phần mềm
• Toàn hệ thống được xem như là tập
các mô-đun/thành phần được xác định
trong suốt quy trình phát triển hệ
thống.
• Chiến lược kiểm thử là thứ tự mà các
mô-đun/thành phần được chọn để tích
hợp lại và kiểm thử với nhau
✓Kiểm thử Big Bang (Non-incremental
testing)
✓Kiểm thử Tăng trưởng (Incremental testing)
Kiểm thử Big Bang (1)
• Kiểm thử Big Bang là một loại kiểm
thử tích hợp (integration testing) mà
tại đó tất cả các mô-đun/thành phần
được tích hợp cùng một lúc và sau đó
được kiểm thử tổng thể.
• Như được minh họa trong sơ đồ bên
cạnh, tất cả các mô-đun từ Mô-đun 1
đến Mô-đun 6 được tích hợp đồng thời
và sau đó kiểm thử được tiến hành.
• Ví dụ
✓Sản phẩm đang được phát triển đã
được chia thành 6 mô-đun để tối đa
hóa tài nguyên của nhà phát triển.
✓Phương pháp này đợi cho đến khi
TẤT CẢ các mô-đun của sản phẩm
được hoàn thành trước khi thực hiện
bất kỳ kiểm thử tích hợp nào.
✓Để kiểm thử Big Bang, bạn sẽ phải
đợi tất cả 6 mô-đun được hoàn thành
trước khi bắt đầu kiểm thử tích hợp.
Nguồn: https://www.quora.com/What-is-the-Big-Bang-testing-in-software-engineering
• Ưu điểm
✓Ưu điểm chính là mọi thứ đã được hoàn thành trước khi kiểm thử tích hợp bắt đầu.
✓là một cách tiếp cận (chiến lược) tốt cho các hệ thống nhỏ.
• Nhược điểm
✓Rất khó để phát hiện mô-đun gây ra lỗi (sự cố) (trong số nhiều Mô-đun).
✓Cách tiếp cận Big Bang yêu cầu tất cả các mô-đun cùng nhau được kiểm thử, do đó,
dẫn đến có ít thời gian hơn để kiểm thử bởi vì việc thiết kế, phát triển, tích hợp chiếm
phần lớn thời gian.
✓Kiểm thử Big Bang có thể tốn nhiều chi phí và tài nguyên, vì thực tế là một số mô-đun
có thể được hoàn thành lâu trước các mô-đun khác. Vì vậy, một số nhà phát triển của
bạn sẽ không làm gì trong khi chờ đợi mô-đun cuối cùng được hoàn thành.
✓Việc kiểm tra chỉ diễn ra cùng một lúc, do đó không có thời gian để kiểm thử riêng các
mô-đun quan trọng.
Kiểm thử tăng trưởng (Incremental testing)
• Tiếp cận từ trên xuống (Top-down Testing)

• Tiếp cận từ dưới lên (Bottom-Up Testing)
• Tiếp cận sandwich (lai) (Hybrid/Sandwich Testing)

Tiếp cận từ dưới lên (Bottom-Up Testing) (1)
Bottom-up testing Thực hiện kiểm thử bottom-up (Stage 2)
• Trong chiến lược từ dưới lên, mỗi mô-đun ở mức thấp hơn được kiểm thử với
các mô-đun ở mức cao hơn cho đến khi tất cả các mô-đun đều được kiểm thử.
• Nó cần sự giúp đỡ của Trình điều khiển/bộ lái (Driver) để kiểm thử.
Tiếp cận từ dưới lên (Bottom-up Testing) (2)
• Ưu điểm:
• Được thực hiện tương đối dễ dàng.
• Định vị lỗi trong các mô-đun dễ dàng hơn (so với tiếp cập Big-bang).
• Không có thời gian bị lãng phí do phải chờ đợi tất cả các mô-đun được
phát triển (không giống như tiếp cận Big-bang)
• Nhược điểm:
• Các mô-đun quan trọng (ở mức cao nhất của kiến trúc phần mềm) kiểm
soát luồng ứng dụng sẽ được kiểm thử sau cùng và dễ bị lỗi.
• Chậm trễ trong việc quan sát được toàn bộ chương trình (tức là, ở giai
đoạn sau khi kiểm thử mô-đun cuối cùng); xây dựng một bản mẫu
(prototype) vào lúc bắt đầu là không thể.
Tiếp cận từ
trên xuống
(Top-down
Integration)
(1)
Thực hiện kiểm thử

Top-down testing top-down (Stage 3)
• Trong chiến lược từ trên xuống, việc kiểm thử diễn ra từ trên xuống dưới theo
luồng điều khiển của hệ thống phần mềm.
• Nó cần sự giúp đỡ của các Cuống(stubs) để kiểm thử.
Tiếp cận từ trên xuống (Top-down Testing) (2)
• Ưu điểm:
• Có thể xây dựng một bản mẫu (prototype) vào lúc bắt đầu.
• Khả năng cung cấp để trình bày toàn bộ các chức năng của chương trình ngay
sau khi kích hoạt của các mô-đun ở mức trên vừa được hoàn thành; trong nhiều
trường hợp, đặc tính này giúp nhận dạng các lỗi phân tích và lỗi thiết kế có liên
quan đến các thuật toán, các yêu cầu chức năng, v.v…
• Các mô-đun quan trọng (ở mức cao) được kiểm thử trước; lỗi thiết kế chính có
thể được tìm thấy và sửa chữa trước.
• Nhược điểm:
• Khó khăn khi chuẩn bị các stub cần thiết – các sub này thường đòi hỏi phải lập
trình rất phức tạp.
• Định vị lỗi dễ dàng hơn (so với tiếp cập Big-bang). Tuy nhiên, vẫn tồn tại khó
khăn (so với tiếp cận từ dưới lên) trong phân tích kết quả kiểm thử để định vị
lỗi nằm ở đâu trong các mô-đun.
Dùng tiếp cận Bottom-up hay Top-down xuống?
• Các chuyên gia kiểm thử vẫn đang tiếp tục tranh luận xem chiến lược
nào được yêu thích hơn - từ dưới lên hay từ trên xuống.
• Tuy nhiên, trong hầu hết các trường hợp, có vẻ như chiến lược kiểm
thử được lựa chọn thực sự sẽ phụ thuộc vào chiến lược phát triển mà
nhà phát triển đã chọn.

Tiếp cận lai (Hybrid/Sandwich Testing)
• Kết hợp tiếp cận Top-down và
Bottom-up.
• Các mô-đun trên đỉnh (top) được kiểm
thử với các mô-đun ở mức thấp hơn;
đồng thời, các mô-đun ở mức thấp
hơn được tích hợp và được kiểm thử
với các mô-đun trên đỉnh.
• Chiến lược này sử dụng các stubs và
driver.

Kiểm thử Big-bang vs. Kiểm thử tăng trưởng
Ưu điểm Nhược điểm
Kiểm - Thích hợp cho dự án nhỏ. - Khi dự án lớn, việc xác định lỗi trở nên cồng
thử kềnh. Mặc dù các nguồn lực được dùng cho
Big- kiểm thử lớn, hiệu quả của phương pháp này
bang là khá ít ỏi. Phải xem xét các tác động có thể
có của việc sửa chữa trên nhiều mô-đun ở
cùng một thời điểm.
Kiểm - Kiểm thử tăng trưởng thường được thực hiện cho các mô-đun - Cần nhiều nguồn lực hơn cho việc lập trình
thử phần mềm nhỏ, như kiểm thử đơn vị và kiểm thử tích hợp. để chuẩn bị các stub và các driver cho các
tăng Điều này giúp nó dễ dàng xác định được nhiều lỗi hơn so với kiểm thử đơn vị và kiểm thử tích hợp.
trưởng kiểm thử toàn bộ gói phần mềm (Big-bang). - Cần phải thực hiện nhiều thao tác kiểm thử
- Việc xác định và sửa chữa lỗi thì đơn giản hơn nhiều và cần ít cho cùng một chương trình.
nguồn lực hơn, bởi vì nó được thực hiện trên một phần mềm
có kích thước nhỏ.
- Một số lượng lớn lỗi sẽ được xác định và sửa chữa ở giai đoạn
đầu của phát triển và kiểm thử, điều này giúp ngăn chặn
chúng "di chuyển" sang các giai đoạn sau đó, tại đây việc phát
triển sẽ phức tạp hơn nên việc sửa chữa chúng sẽ cần nguồn
lực nhiều hơn đáng kể.
Kiểm thử Big Bang vs. Kiểm thử tăng trưởng
Xét về tổng thể thì kiểm thử tăng trưởng được ưa

chuộng nhiều hơn kiểm thử Big-bang.

Tài liệu tham khảo
1. Trần Cao Đệ và Nguyễn Công Danh, Giáo trình Đảm bảo
chất lượng phần mềm, Nxb. Đại học Cần Thơ, 2014.

Chuong 3 DBCLKTPM Noi Dung 3 - NCDanh

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chuong 3 DBCLKTPM Noi Dung 3 - NCDanh

Uploaded by

Copyright:

Available Formats

Chương 3

CÁC THÀNH PHẦN ĐẢM BẢO CHẤT

Đảm bào chất lượng và Kiểm thử phần mềm 1

Đảm bào chất lượng và Kiểm thử phần mềm 2

Đảm bào chất lượng và Kiểm thử phần mềm 3

Architectural Integration Integration Test component groups

Unit test Unit Testing Test individual component

dùng nhập vào UI, nó sẽ được chuyển đổi thành UI XML

bởi 3 mô-đun và trích xuất SQL từ nó và truy vấn

• xem thông tin/dữ liệu có lưu chuyển chính UI

Đảm bào chất lượng và Kiểm thử phần mềm 15

• Tiếp cận từ trên xuống (Top-down Testing)

Đảm bào chất lượng và Kiểm thử phần mềm 22

Bottom-up testing Thực hiện kiểm thử bottom-up (Stage 2)

Thực hiện kiểm thử

Đảm bào chất lượng và Kiểm thử phần mềm 27

Đảm bào chất lượng và Kiểm thử phần mềm 28

Xét về tổng thể thì kiểm thử tăng trưởng được ưa

Đảm bào chất lượng và Kiểm thử phần mềm 30

Đảm bào chất lượng và Kiểm thử phần mềm 31

You might also like