CHAPTER 9 SOFTWARE TESTING

󾠶

CHAPTER 9: SOFTWARE
TESTING
Testing level
Component/unit testing
Kiểm tra từng component của ứng dụng.
Thường được thực hiện bởi component developer.
Các bài kiểm tra được lấy ra từ kinh nghiệm của các developer.

System testing
Kiểm tra một nhóm những component.
Từng phần sẽ được thực hiện bởi nhiều nhóm độc lập khác nhau.
Bài kiểm tra được dự trên các yêu cầu và các thông số của hệ thống.

Acceptance testing
Thực hiện bởi khách hàng
Kiểm tra toàn bộ hệ thống xem hệ thống chúng ta thiết kế có được chấp nhận
hay không.

CHAPTER 9: SOFTWARE TESTING

1


Types of testing
Functional testing: Login, Logout, Remove user out of the system,…
Performance testing: How fast the system can performance?
Load testing: Give a whole punch of user and data to test.
Stress testing: Test if the system can work over the limits.
Security testing: Check if the application can

Usability/interface testing: If the application is easy to use or not.
API and service testing:
Privacy testing: User data privacy can be protected or not.

Testing phases

Testing goals
Validation testing
Thể hiện cho các lập trình viên và khác hàng của hệ thống rằng phần mềm này đáp
ứng được các yêu cầu đề ra.

CHAPTER 9: SOFTWARE TESTING

2


Các bài kiểm tra được thực hiện thành công cho thấy được hệ thống đã vận hành
đúng như dự định ban đầu.

Defect testing
Tìm kiếm ra các lỗi của phần mềm, chỗ nào chưa chạy đúng, chưa phù hợp với các
thông số đề ra.
Một bài test thành công là một bài test khiến cho hệ thống chạy sai.
Các bài test cho thấy sự hiện diện của các lỗi.

💡

Trong các dự án lớn cần những người tester độc lập, mục tiêu của họ là
thiết kế ra những test case nào mà làm xuất hiện lỗi càng nhiều càng tốt.

The software testing process

Sơ đồ quá trình kiểm tra phần mềm.

Sau khi thiết kế ra bộ test case, tester sẽ thực hiện nó trên chương trình và đối
chiếu với kết quả trong requirment nếu có lỗi thì phải cap màn hình và viết report lại.

Testing policies
Chỉ có hình thức exhaustive testing là đảm bảo một phần mềm sẽ khơng có lỗi.

⇒ Điều này là khơng thể chúng ta khơng thể nào có đủ thời gian để test hết các lỗi.

CHAPTER 9: SOFTWARE TESTING

3


❓

Làm sao để kiểm tra trong thời gian ngắn mà vẫn cho ra được nhiều lỗi.

Đưa ra những chính sách thực hiện trên menu cần để kiểm thử.
Kết hợp các hàm chức năng được truy cập thông qua cùng một menu nên được
kiểm tra.
Khi được yêu cầu nhập thông tin thì mọi chức năng nên được kiểm thử bằng
thơng tin chính xác và khơng chính xác.

System testing
Liên quan đến việc tích hợp các thành phần để tạo ra một hệ thống hoặc một hệ
thống con của nó.

Có thể liên quan đến việc kiểm thử gia tăng để có thể giao cho khách hàng.
Bao gồm 2 giai đoạn:
Integration testing.
Release testing.

Intergration testing
Bao gồm việc xây dựng một hệ thống từ các component của nó và kiểm tra các lỗi
xuất hiện trong quá trình tương tác giữa các thành phần.

Top-down integration
Tích hợp các gói phần mềm nhỏ và test.
Dùng cho các ứng dụng nhỏ.

Bottom-up integration
Gom nhiều thành phần lại và kiểm thử.
Áp dụng cho những dự án lớn có nhiều thành phần.

💡

Các hệ thống nên được tích hợp thường xuyên và từng bước 1 để tránh
tình trạng “big bang” integration.

CHAPTER 9: SOFTWARE TESTING

4


Incremental integration testing

Testing approaches

Architectural validation: Top-down integration testing (Kiểm thử tích hợp từ trên
xuống) tốt hơn trong việc phát hiện ra các lỗi trong kiến trúc hệ thống.
System demonstration: Top-down integration testing cho phép giới hạn các
Test implementation: Thường sẽ dễ hơn với buttom-up integration testing.
Test observation:
Đều gặp vấn đề với hai cách tiếp cận.
Extra code đôi khi cần cho việc quan sát các test.

Release testing
Là các quy trình kiểm thử các bản phát hành hệ thống để phân phối cho khách
hàng.
Mục tiêu chính: mang lại độ tin cậy cho nhà cung cấp rằng phần mềm đáp ứng các
yêu cầu của họ.

CHAPTER 9: SOFTWARE TESTING

5


Thường phải làm thêm black-box testing để đánh giá xem phần mềm có chạy theo
đúng u cầu hay khơng.

Some testing guidelines
Một số chiến lược:
Tạo test-case sinh ra error messages (cố tình nhập sai để báo lỗi, xem báo lỗi
đúng hay khơng, có báo lỗi hay khơng).
Thiết kế đâu vào tạo ra buffers để bị overflow.
Lặp đi lặp lại đầu vào nhiều lần.
Cố tình tạo đầu ra sai.
Cố tình nhập số quá nhỏ hoặc quá lớn.

Black-box testing

Some testing guidelines
Chọn những input nào mà khiến hệ thống tạo ra tất của những thông báo lỗi.

CHAPTER 9: SOFTWARE TESTING

6


Thiết kế các input khiến các buffer bị tràn.
Lặp lại cùng một input hoặc input một chuỗi nhiều lần.
Cố tình làm cho các output không hợp lệ hiện ra.
Khiến cho các kết quả tính tốn rất nhỏ hoặc rất lớn.

From use cases to test cases
Test case có thể được tạo ra từ các use case đã có.
Test case thiết kế như là một cơ sở cho hệ thống thử nghiệm.
Sử dụng test case như là một luồng các sự kiện, các hoạt động, inputs và
outputs.

Component Testing
Là một quá trình kiểm thử từng components một cách riêng biệt với nhau.
Component có thể là:
Các chức năng hoặc phương thức riêng lẻ trong một đối tượng.
Các lớp đối tượng với nhiều thuộc tính và phương thức.
Các composite components các giao diện xác định được được sử dụng để truy
cập chức năng của chúng.

Interface testing

CHAPTER 9: SOFTWARE TESTING

7


Some interface types
Parameter interfaces
Shared memory interfaces
Procedural interfaces
Message passing interfaces

Test-case design
Thiết kế để thi hành lại test case đó nhiều lần.
Các cách tiếp cận:
Requirements-based testing
Partition testing
Structural testing

CHAPTER 9: SOFTWARE TESTING

8


Requirements based testing
Ảnh hưởng đến thời gian và quá trình kiểm thử.
Tạo test-case có nhiều khác biệt thì sẽ phát sinh ra nhiều lỗi.

Partition testing

Data nhập và xuất được chia thành các class khác nhau.
Các lớp trên là các phân vùng tương đương, chương trình hoạt động một cách
tương đương cho những phần tử trong class đó.
Test case được lựa chọn từ những phân vùng trên.

Equivalence partitioning
Chia thành các phân vùng để trị

Ví dụ:
Chức năng login: (4 phân vùng password)

CHAPTER 9: SOFTWARE TESTING

9


Valid username(available)/password
Invalid username/password
Valid username/Invalid password
Invalid username/Valid password
Invalid username/Invalid password

Testing guidelines (sequences)
Test software with sequences which have only a single value
Use sequences of different sizes
Chia test mà phần đầu, giữa, cuối của sequences liên kết với nhau
Test with sequences of zero length

Structural testing
Đôi khi được gọi là kiểm thử white-box.

Xuất phát từ những trường hợp kiểm thử theo cấu trúc chương trình.

CHAPTER 9: SOFTWARE TESTING

10


Path testing
Mục tiêu là đảm bảo mỗi path trong suốt chương trình được thực hiện ít nhất 1 lần.
Nó bao gồm:
Starting point.
Node thể hiện quyết định của chương trình.
Các đường đi (Arc) thể hiện các luồng điều khiển (flow of control).
Các câu lệnh có điều kiện là các node trong biểu đồ luồng (flow graph).

Test automation
Đa số quá trình kiểm thử được thực hiện một cách thủ cơng nhưng nó rất tốn kém
Quá trình kiểm thử được thực hiện một các tự động thông qua các công cụ.

CHAPTER 9: SOFTWARE TESTING

11


Gợi ý test chức năng login. (Sử dụng Katalon Studio để kiểm thử tự động)

CHAPTER 9: SOFTWARE TESTING

12