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

Kiểm thử phần mềm TS. Nguyễn Thanh Hùng Bộ Môn Công Nghệ Phần Mềm Email: hungnt@soict.hust.edu.vn Website: Các quá trình kiểm thử Trường Đại Học Bách Khoa Hà Nội Viện Công Nghệ Thông Tin &Truyền Thông CuuDuongThanCong.com https://fb.com/tailieudientucntt  Bắt đầu từ module level cho đến lúc tích hợp thành hệ thống trọn vẹn  Các kỹ thuật kiểm thử khác nhau thích hợp tạo các thời điểm khác nhau  Kiểm thử được kiểm soát bởi các developers và các nhóm kiểm thử độc lập  Kiểm thử và gỡ lỗi là các hoạt động khác nhau, nhưng gỡ lỗi phải được thích ứng trong chiến lược kiểm thử Chiến lược kiểm thử CuuDuongThanCong.com https://fb.com/tailieudientucntt Chiến lược cần thích ứng với từng mức kiểm thử:  Kiểm thử mức thấp: xác minh từng đoạn mã nguồn có tương ứng và thực thi đúng đắn không?  Kiểm thử mức cao: xác minh và thẩm định các chức năng hệ thống chủ yếu có đúng đặc tả và đáp ứng yêu cầu của khách hàng không? 3 Sự thích ứng của chiến lược kiểm thử CuuDuongThanCong.com https://fb.com/tailieudientucntt Mỗi chiến lược đáp ứng được yêu cầu người quan tâm:  Có các hướng dẫn cho người thực hiện tiến hành kiểm thử  Có các cột mốc cho các nhà quản lý kiểm soát hoạt động đảm bảo chất lượng  Có thước đo để có thể nhận ra các vấn đề càng sớm càng tốt và khách hàng nhận biết được quá trình kiểm thử 4 Sự đáp ứng của chiến lược kiểm thử CuuDuongThanCong.com https://fb.com/tailieudientucntt Tổ chức kiểm thử Kiểm thử phần mềm là một phần của hoạt động “Xác minh và thẩm định”  Xác minh là một tập các hoạt động để đảm bảo rằng: phần mềm thực hiện đúng chức năng đã được đặc tả  Thẩm định là một tập hợp các hoạt động để đảm bảo rằng: phần mềm đã đáp ứng đúng các yêu cầu của khách hàng  Câu hỏi: Ai làm? Làm cái gì? Khi nào? Và mối quan hệ 5 CuuDuongThanCong.com https://fb.com/tailieudientucntt Các kỹ sư phần mềm làm ra phần mềm. Một cách tự nhiên họ cần tiến hành các kiểm thử ban đầu. Về nguyên tắc, người làm sản phẩm, kiểm tra sản phẩm là không hợp lý. Có một số hiểu lầm:  Người phát triển không tham gia kiểm thử  Cho phép người lạ kiểm thử một cách tàn nhẫn  Người kiểm thử chỉ quan tâm khi kiểm thử bắt đầu 6 Trách nhiệm kiểm thử phần mềm CuuDuongThanCong.com https://fb.com/tailieudientucntt Phân công trách nhiệm kiểm thử Từ thực tiễn dẫn đến sự phân công:  Người phát triển chỉ trách 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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ử đơn vị CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt Đặ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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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ý?  Có văn bản nào trong thông tin ra? CuuDuongThanCong.com https://fb.com/tailieudientucntt 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ử cấu trúc dữ liệu cục bộ CuuDuongThanCong.com https://fb.com/tailieudientucntt 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ử về các xử lý CuuDuongThanCong.com https://fb.com/tailieudientucntt  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ử các điều kiện logic CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 Thủ tục kiểm thử đơn vị CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt Kỹ thuật kiểm thử đơn vị 22 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt Ví dụ Junit - binarySearch 27 43 85 JUnit Example for binarySearch import junit.framework.TestCase; public class TestBinarySearch extends TestCase { BinarySearch search; int sortedArray[]; int sortedArray2[]={2,4,6}; int sortedArray3[]={2,4,6,8,10}; public TestBinarySearch(String name) { super(name); } public static void main(String[] args) { junit.swingui.TestRunner.run(TestBinar ySearch.class); } void setUp() throws Exception { super.setUp(); search=new BinarySearch(); sortedArray=new int[0]; } protected void tearDown() throws Exception { super.tearDown(); } public void test_case1() { assertEquals(search.binarySearch(sortedArray, 2),-1); } public void test_case2() { assertEquals(search.binarySearch(sortedArray2 ,8),-1); } public void test_case3() { assertEquals(search.binarySearch(sortedArray3 ,6),2); } public void test_case4() { assertEquals(search.binarySearch(sortedArray3 ,4),1); } public void test_case5() { assertEquals(search.binarySearch(sortedArray3 ,10),4); } // test case for showing the JUnit failure public void test_case6() { assertEquals(search.binarySearch(sortedArray3 ,7),4); } } 86 JUnit Example for binarySearch CuuDuongThanCong.com https://fb.com/tailieudientucntt Ví dụ Junit - binarySearch 28 43 85 JUnit Example for binarySearch import junit.framework.TestCase; public class TestBinarySearch extends TestCase { BinarySearch search; int sortedArray[]; int sortedArray2[]={2,4,6}; int sortedArray3[]={2,4,6,8,10}; public TestBinarySearch(String name) { super(name); } public static void main(String[] args) { junit.swingui.TestRunner.run(TestBinar ySearch.class); } void setUp() throws Exception { super.setUp(); search=new BinarySearch(); sortedArray=new int[0]; } protected void tearDown() throws Exception { super.tearDown(); } public void test_case1() { assertEquals(search.binarySearch(sortedArray, 2),-1); } public void test_case2() { assertEquals(search.binarySearch(sortedArray2 ,8),-1); } public void test_case3() { assertEquals(search.binarySearch(sortedArray3 ,6),2); } public void test_case4() { assertEquals(search.binarySearch(sortedArray3 ,4),1); } public void test_case5() { assertEquals(search.binarySearch(sortedArray3 ,10),4); } // test case for showing the JUnit failure public void test_case6() { assertEquals(search.binarySearch(sortedArray3 ,7),4); } } 86 JUnit Example for binarySearch CuuDuongThanCong.com https://fb.com/tailieudientucntt 29 Kiểm thử tích hợp CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 Kiểm thử tích hợp CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt  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 “Big-Bang” và hậu quả CuuDuongThanCong.com https://fb.com/tailieudientucntt  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 Chiến lược tích hợp từ trên xuống CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt Tiến hình tích hợp trên xuống  c 2).  – c sinh ra.  ng 35 CuuDuongThanCong.com https://fb.com/tailieudientucntt Sơ đồ - tích hợp từ trên xuống 36 CuuDuongThanCong.com https://fb.com/tailieudientucntt Tích hợp trên xuống – nhận xét  c cao.  n lên trên. 37 CuuDuongThanCong.com https://fb.com/tailieudientucntt  n:  .  c hiẹ ̂n.  i le ̂n) 38 Giải pháp tích hợp từ trên xuống CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt  c:  m)  .  .  nh 40 Tiến trình tích hợp từ dưới lên CuuDuongThanCong.com https://fb.com/tailieudientucntt 41 Sơ đồ tích hợp dưới lên CuuDuongThanCong.com https://fb.com/tailieudientucntt  - ng:  ng  ng.  ng.  i –lên:   ng. 42 Bình luận phương pháp tích hợp CuuDuongThanCong.com https://fb.com/tailieudientucntt p  n.  - - . CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt p  nh sau:  m.  nh).  n).  .  m càng tốt 48 CuuDuongThanCong.com https://fb.com/tailieudientucntt 49 Kiểm thử hệ thống CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt 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 CuuDuongThanCong.com https://fb.com/tailieudientucntt