Bài giảng Kiểm thử phần mềm - Chương 4: Các quá trình kiểm thử - Nguyễn Thanh Hùng

h nhiệm kiểm thử 
 đơn vị do mình phát triển để đảm bảo thực 
 hiện đúng thiết kế (một yêu cầu của xác minh)
 . Người phát triển có thể tham gia kiểm thử tích 
 hợp
 . Nhóm kiểm thử độc lập bắt đầu làm việc khi 
 các khoản mục cấu trúc phần mềm đã đầy đủ
 7
 Vai trò của người kiểm thử
 Nhóm kiểm thử độc lập giúp gỡ bỏ những thành 
 kiến cố hữu: “người xây dựng không thể kiểm thử 
 sản phẩm tốt”
 . Gỡ bỏ mâu thuẫn giữa những người tham gia
 . Đánh giá công sức phát triển bỏ ra tìm lỗi
 Nhóm kiểm thử độc lập tạo ra báo cáo đầy đủ 
 cho tổ chức đảm bảo chất lượng phần mềm
 Người phát triển
 . Không đẩy chương trình cho người kiểm thử rồi 
 bỏ đi
 . Cùng làm việc với người kiểm thử xuyên suốt 
 một dự án (bảo đảm việc kiểm thử được tiến 
 hành triệt để)
 8
 Tiến trình thực hiện kiểm thử
Tiến trình thực hiện kiểm thử tương ứng 
 với tiến trình phát triển (theo từng mô 
 hình)
Tiến trình kiểm thử thông thường (mô 
 hình chữ V)
 9
 Kiểm thử đơn vị
Nội dung kiểm thử:
 . Giao diện
 . Cấu trúc dữ liệu sử dụng cục bộ
 . Đường điều khiển
 . Điều kiện logic
 . Phép toán xử lý
 10
 Kiểm thử đơn vị
Câu hỏi
 . Định lượng/dạng gì (biến, module qua giao 
 diện)
 . Yếu tố nào cần (vào/ra dữ liệu)?
 . Sai xử lý, logic (phép toán, biểu thức)?
 . Sai điều khiển (vòng lặp, giá trị biên)?
 . Sai tiềm ẩn (ghi chép, mô tả)?
 11
 Kiểm thử dữ liệu qua giao diện
 Kiểm thử dòng dữ liệu 
 qua một giao diện của 
 module liên quan đến 
 định lượng và định 
 dạng của các biến và 
 các module sử dụng 
 trên giao diện.
 Đặc trưng cụ thể:
 . Số lượng?
 . Định dạng?
 12
 Đặc trưng dữ liệu qua giao diện
 Các đặc trưng qua giao diện là:
 . Số tham số = số đối số?
 . Tính chất của tham số = tính chất của 
 đối số?
 . Đơn vị của tham số = đơn vị của đối 
 số?
 . Số đối được truyền gọi module = số các 
 tham số đầu vào của module?
 . Thuộc tính các đối được truyền gọi 
 module = thuộc tính của tham số?
 . Đơn vị của đối được truyền để gọi 
 module = đơn vị các tham số module
 13
 Kiểm thử liên quan đến vào ra
Khi thực hiện I/O cần tiến hành thêm:
 . Tính chất của file có đúng đắn hay không?
 . Các câu lệnh OPEN/CLOSE có đúng đắn
 không?
 . Đặc tả hình thức có đúng với các câu lệnh I/O
 . Cỡ của buffer có đúng với cỡ của bản ghi
 không?
 . Các file có mở trước khi sử dụng không?
 . Các điều kiện end-of-file có được xử lý?
 . Các sai lầm I/O có được xử lý?
 văn. Cóbản nào trong thôngra? tin
 Kiểm thử cấu trúc dữ liệu cục bộ
Cấu trúc dữ liệu cục bộ cho module có thể sai. 
 Vì thế thiết kế các kiểm thử cần làm lộ ra các 
 loại lỗi sau:
 . Giá trị ngầm định hoặc giá trị khởi tạo sai
 . Tên các biến không đúng
 . Kiểu dữ liệu không nhất quán
 . Ngoại lệ về địa chỉ, overflow, 
 Kiểm thử về các xử lý
Các sai về trình tự, độ chính xác là:
 . Thứ tự ưu tiên các phép tính số học
 . Sự nhất quán của các phép toán
 trộn
 . Khởi tạo/kết thúc không đúng đắn
 . Sự chính xác của kết quả
 Kiểm thử các điều kiện logic
 Các sai kiểu, toán tử, ngữ nghĩa:
 . So sánh các kiểu dữ liệu khác nhau
 . Ưu tiên hoặc toán tử logic không đúng đắn
 . Dự đoán một biểu thức so sánh, trong khi sai số làm cho
 đẳng thức không chắc có thực
 . Các giá trị so sánh không đúng đắn
 Kiểm thử dòng điều khiển/biên
Các sai biến lặp, số vòng lặp
 . Vòng lặp không kết thúc hoặc kết 
 thúc không chính xác
 . Sự lặp phân kỳ khó thoát được
 . Các biến lặp bị cải biên không chính 
 xác
Sai ở các biên
 . Kiểm thử biên là nhiệm vụ cuối cùng 
 của bước kiểm thử đơn vị. Phần 
 mềm thường thất bại tại các biên của 
 chúng
 18
 Kiểm thử sai tiềm ẩn
Các sai tiềm ẩn cần được đánh giá là:
 . Mô tả sai (khó hiểu)
 . Dữ liệu ghi không tương ứng với sai đã gặp
 . Điều kiện sai có trước khi xử lý sai
 . Xử lý điều kiện ngoại lệ là không đúng đắn
 . Mô tả sai không cung cấp đủ thông tin để trợ 
 giúp định vị nguyên nhân sai
 19
 Thủ tục kiểm thử đơn vị
Sau khi mã nguồn được phát triển, rà soát 
 và kiểm tra tính đúng đắn cú pháp (thanh 
 tra), thiết kế ca kiểm thử đơn vị bắt đầu
Kiểm thử đơn vị là phần phụ thêm của mã 
 hoá
Kết quả rà soát thiết kế cung cấp các chỉ 
 dẫn để thiết lập các ca kiểm thử nhằm bộc 
 lộ sai trong mỗi loại đã nêu
Mỗi ca kiểm thử phải gắn với một tập các 
 kết quả mong đợi.
 20
 Kỹ thuật kiểm thử đơn vị
Module không phải là chương trình cô lập, 
 nên cần phát triển các phần mềm bộ lái 
 và/hoặc cuống cho kiểm thử đơn vị
Bộ lái (driver) là một hàm “main” điều 
 khiển việc đưa dữ liệu vào và nhận kết 
 quả ra của module
Cuống (stub) dùng để thay cho các 
 module là thứ cấp của nó
 21
Kỹ thuật kiểm thử đơn vị
 22
 Kỹ thuật kiểm thử đơn vị
Một cuống (stub) hoặc “dummy program”
 dùng các giao diện của module thứ cấp: 
 làm được các thao tác tối thiểu, kiểm 
 chứng đầu vào và giá trị trả về.
Bô lái và cuống cần chi phí hành chính. 
 Chúng cần viết ra nhưng không được phân 
 phối kèm với sản phẩm cuối cùng
Chi phí hành chính thấp nếu đơn giản, 
 nhưng không may đa số là cao, khi đó 
 người ta hoãn kiểm thử đầy đủ cho tới 
 bước kiểm thử tích hợp
 23
 JUnit
JUnit:
 . Framework mã nguồn mở Unit Test cho Java 
 (
 • Cung cấp các test drivers cho kiểm thử đơn vị
 • Cung cấp kiểm thử tử động
 • Cung cấp kiểm tra kết quả tự động
 . Các bước sử dụng Junit
 • Viết trường hợp kiểm thử
 • Chạy kiểm thử
 • Kiểm tra kết quả
 24
 JUnit
Viết một trường hợp kiểm thử
 . Tạo một trường hợp kiểm thử là subclass của 
 Junit TestCase
 . Override phương thức setUp() để khởi tạo 
 các đối tượng kiểm thử
 . Override hàm tearDown() để giải phóng các 
 đối tượng cần kiểm thử
Chạy kiểm thử
 . Định nghĩa hàm test để kiểm tra các đối 
 tượng
 25
 JUnit
Kiểm tra kết quả
 . Xác nhận kết quả đúng của kiểm thử bằng 
 hàm assertEqual()
Error vs Failure
 . Error: vấn đề nảy sinh, ví dụ 
 ArrayIndexOutOfBoundsException
 . Failure: được đoán trước và có thể kiểm tra 
 với việc xác nhận (assertions) 
 26
 Ví dụ Junit - binarySearch
 JUnit Example for binarySearch
 public void test_case1() {
import junit.framework.TestCase;
public class TestBinarySearch extends assertEquals(search.binarySearch(sortedArray,
 TestCase { 2),-1); 
 BinarySearch search; }
 int sortedArray[]; public void test_case2() {
 int sortedArray2[]={2,4,6};
 int sortedArray3[]={2,4,6,8,10}; assertEquals(search.binarySearch(sortedArray2
 ,8),-1); 
 public TestBinarySearch(String name) { }
 super(name); public void test_case3() {
 } assertEquals(search.binarySearch(sortedArray3
 public static void main(String[] args) { ,6),2); 
 junit.swingui.TestRunner.run(TestBinar }
 ySearch.class); public void test_case4() {
 }
 void setUp() throws Exception { assertEquals(search.binarySearch(sortedArray3
 super.setUp(); ,4),1); 
 search=new BinarySearch(); }
 sortedArray=new int[0]; public void test_case5() {
 }
 protected void tearDown() throws assertEquals(search.binarySearch(sortedArray3
 Exception { ,10),4); 
 super.tearDown(); }
 } // test case for showing the JUnit failure
 public void test_case6() {
 assertEquals(search.binarySearch(sortedArray3
 ,7),4); 85
 }
 }
 27
 JUnit Example for binarySearch
 86
 43
 JUnit Example for binarySearch
 public void test_case1() {
import junit.framework.TestCase;
public class TestBinarySearch extends assertEquals(search.binarySearch(sortedArray,
 TestCase { 2),-1); 
 BinarySearch search; }
 int sortedArray[]; public void test_case2() {
 int sortedArray2[]={2,4,6};
 int sortedArray3[]={2,4,6,8,10}; assertEquals(search.binarySearch(sortedArray2
 ,8),-1); 
 public TestBinarySearch(String name) { }
 super(name); public void test_case3() {
 } assertEquals(search.binarySearch(sortedArray3
 public static void main(String[] args) { ,6),2); 
 junit.swingui.TestRunner.run(TestBinar }
 ySearch.class); public void test_case4() {
 }
 void setUp() throws Exception { assertEquals(search.binarySearch(sortedArray3
 super.setUp(); ,4),1); 
 search=new BinarySearch(); }
 sortedArray=new int[0]; public void test_case5() {
 }
 protected void tearDown() throws assertEquals(search.binarySearch(sortedArray3
 Exception { ,10),4); 
 super.tearDown(); }
 } // test case for showing the JUnit failure
 public void test_case6() {
 assertEquals(search.binarySearch(sortedArray3
 ,7),4); 85
 }
 }
 JVíU ndụit JunitExa -mbinarySearchple for binarySearch
 86
 28
 43
Kiểm thử tích hợp
 29
 Kiểm thử tích hợp
Khái niệm
 . Kiểm thử tích hợp (integration testing) nhằm 
 nhận được một bộ phận chức năng hay một hệ 
 con hoạt động tốt.
 . Là một kỹ thuật có tính hệ thống để xây dựng 
 cấu trúc chương trình
 . Từ các module đã kiểm thử đơn vị, xây dựng 
 cấu trúc chương trình đảm bảo tuân theo thiết 
 kế.
 . Có hai cách tích hợp:
 • Tích hợp dần: từ trên xuống, dưới lên, kẹp
 • Tích hợp đồng thời một lúc: “”big bang 30
 Các sai gặp khi tích hợp
Các sai có thể gặp khi tích hợp:
 . Dữ liệu bị mất khi đi qua một giao diện
 . Hiệu ứng bất lợi một module vô tình gây ra 
 đối với các module khác
 . Sự kết hợp chức năng phụ có thể không 
 sinh ra chức năng chính mong muốn
 . Sự phóng đại các sai sót riêng rẽ có thể bị 
 đến mức không chấp nhận được
 . Vấn đề của cấu trúc dữ liệu toàn cục có thể 
 để lộ ra.
 31
 Chiến lược “Big-Bang” và hậu quả
 Kết hợp tất cả các module đã kiểm thử đơn vị
 thành chương trình
 Tiến hành kiểm thử toàn bộ chương trình
 Kết quả: một mớ hỗn độn
 Với một tập các sai, chỉnh sửa chúng là khó khăn
 vì cô lập các nguyên nhân là phức tạp: sai này
 được sửa, có thể xuất hiện nhiều sai khác, cứ thế
 triền miên
 Chiến lược tích hợp từ trên xuống
 Là một cách tiện lợi để xây dựng và kiểm soát cấu trúc 
 chương trình
 Gộp dần các module từ trên xuống theo trật tự dòng điều 
 khiển, bắt đầu từ module điều khiển “main”, gắn từng 
 module phụ trợ vào module điều khiển thượng cấp.
 Có thể theo hai cách:
 . Theo chiều “sâu trước”
 . Theo chiều “rộng trước”
 . Hỗn hợp (theo cả hai cách trên)
 33
 Tiến trình tích hợp trên xuống
Tích hợp từ trên xuống thực hiện theo 5 
 bước:
 .
 ng (stub).
 .
 ng.
 .
 ng.
 34
 Tiến hình tích hợp trên xuống

 c 2).

 –
 c sinh ra.

 ng
 35
Sơ đồ - tích hợp từ trên xuống
 36
 Tích hợp trên xuống – nhận xét

 c cao.

 n lên trên.
 37
 Giải pháp tích hợp từ trên xuống
 n:
 .
 . 
 .
 c hiện. 
 .
 i lên) 
 38
 Chiến lược tích hợp từ dưới lên
 c môđun 
 cơ bản (Các modules ở mức thấp nhất của 
 hệ thống). 
 39
 Tiến trình tích hợp từ dưới lên
 c: 
 .
 m) 
 .
 . 
 . .
 .
 nh
 40
Sơ đồ tích hợp dưới lên
 41
 Bình luận phương pháp tích hợp
 - ng:
 . ng
 . ng.
 . ng. 
 i –lên:
 .
 . ng. 
 42
 p 

 n. 

 -
 -
 . 
 Kiểm thử tích hợp hỗn hợp
Các module quyết định (logic modules) 
 được tích hợp và kiểm thử top-down để 
 phát hiện sớm các lỗi về thiết kế
Các module chức năng (operational 
 modules) được tích hợp và kiểm thử 
 bottom-up để kiểm tra các modules có thể 
 tái sử dụng và giảm các stubs
Tận dụng được lợi thế của cả top-down và 
 bottom-up
 44
 Kiểm thử hồi quy
Mỗi lần 1 module mới được tích hợp, hoặc 
 1 bug được sửa, phần mềm bị thay đổi
Thay đổi có thể tạo ra lỗi trong các chức 
 năng đã hoạt động trước đó
Kiểm thử hồi quy là việc chạy lại một số 
 kiểm thử để đảm bảo thay đổi không tạo 
 ra hiệu ứng phụ
 45
 Kiểm thử hồi quy
Có thể được tiến hành:
 . Chạy lại một phần của các test-cases
 . Sử dụng công cụ tự động
Bao gồm 3 lớp test-cases:
 . Một lớp sẽ kiểm tra lại toàn bộ chức năng hệ 
 thống
 . Một lớp phụ sẽ tập trung vào chức năng phần 
 mềm bị ảnh hưởng bởi thay đổi
 . Một lớp tập trung vào các thành phần bị thay 
 đổi
 46
 Kiểm thử hồi quy
Khi tiến hành kiểm thử hồi quy, số 
 lượng kiểm thử có thể tăng nhanh
 . Chỉ nên được thiết kế để bao gồm các test-
 cases cho một số lỗi trong mỗi chương trình
 . Không khả thi và hiệu quả nếu mỗi lần có 
 thay đổi lại chạy lại kiểm thử cho tất cả các 
 chức năng
 47
 p 

 nh sau: 
 . m. 
 .
 nh). 
 .
 n). 
 . .

 m càng tốt
 48
Kiểm thử hệ thống
 49
 Kiểm thử hệ thống
 Kiểm thử hệ thống
 . Phần mềm được kiểm thử tổng thể. Kiểm tra tất cả để đảm bảo mọi 
 chức năng hoạt động tốt trong môi trường định trước.
 Các vùng tập trung
 . Các chức năng hệ thống và hiệu suất
 . Độ tin cậy và khả năng phục hồi (recovery test)
 . Cài đặt hệ thống (installation test)
 . Hoạt động hệ thống trong các điều kiện đặc biệt (stress and load 
 test)
 . Hoạt động người dùng trên hệ thống (acceptance test/alpha test)
 . Tích hợp phần cứng và phần mềm và tương tác
 . Tích hợp các phần mềm ngoài với hệ thống
 50
 Kiểm thử hệ thống
 Kiểm thử hồi phục
 . Kiểm tra hệ thống có thể phục hồi khi gặp lỗi
 . Khôi phục dữ liệu đặc biệt quan trọng
 . Đo thời gian khôi phục nếu cần tác động của con người
 Kiểm thử khả năng chịu đựng
 . Kiểm tra hệ thống có thể hoạt động khi có rất nhiều yêu cầu 
 đồng thời
 . Vận hành hệ thống với yêu cầu về tài nguyên bất thường (về tần 
 số, khối lượng)
 . Quá nhiều gián đoạn, tốc độ dữ liệu đầu vào cao, bộ nhớ tối đa
 . Kiểm tra mức giới hạn
 . Kiểm tra độ nhạy
 . TÌm ra kết hợ dữ liệu đầu vào hợp lệ mà gây ra bất ổn hoặc xử 
 lý không đúng cách
 51
 Kiểm thử hệ thống
 Kiểm thử độ an toàn
 . Kiểm tra cơ chế bảo vệ chống truy cập
 . Khả năng chống đỡ khi bị tấn công
 . Kiểm tra chi phí thâm nhập cao hơn thông tin đo được (thời gian 
 để phá vỡ)
 Kiểm thử hiệu suất
 . Kiểm tra hiệu năng thời gian chạy của phần mềm (hệ thống thời 
 gian thực và nhúng)
 . Đo tốc độ, sử dụng nguồn lực trong các hoàn cảnh khác nhau
 . Thường được kết hợp với kiểm thử khả năng chịu đựng và đòi 
 hỏi cả phần cứng và phần mềm 
 . Xuất hiện trong tất cả các bước trong quá trình thử nghiệm
 52
 Kiểm thử Alpha và Beta
Kiểm thử alpha và beta
 . Khi hệ thống được sử dụng bởi nhiều khách 
 hàng
 . Được sử dụng để phát hiện các lỗi mà chỉ có 
 người dùng cuối dường như có thể tìm thấy
Kiểm thử Alpha
 . Thực hiện từ phía nhà phát triển
 . Thực hiện bởi khách hàng
 . Nhà phát triển theo dõi các lỗi và vấn đề
 . Thực hiện trong một môi trường kiểm soát
 53
 Kiểm thử Alpha và Beta
Kiểm thử Beta
 . Thực hiện tại phía một hay nhiều người dùng
 . Thực hiện bởi người dùng cuối
 . Không có mặt người phát triển
 . Trong môi trường không kiểm soát
 . Lỗi có thể là thật hoặc tưởng tượng
 . Khách hàng báo cáo lỗi
 54
 Kiểm thử chấp nhận
Thực hiện sau kiểm thử hệ thống nếu 
 phần mềm được phát triển cho khách 
 hàng cụ thể
Thường được thực hiện bởi khách hàng 
 hoặc người dùng cuối
Được thực hiện dựa trên yêu cầu:
 . Hướng dẫn sử dụng được dùng để hỗ trợ
 . Kiểm thử hệ thống có thể được sử dụng
 55
 Kiểm thử chấp nhận
Phần mềm phải chạy dưới điều kiện thực 
 với điều kiện hoạt động phần cứng/phần 
 mềm
Khách hàng xác định phần mềm đáp ứng 
 yêu cầu của họ
 56