Đề tài Kiểm thử tích hợp

Bài tập lớn môn NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Đề tài số 22: KIỂM THỬ TÍCH HỢP ( Integration testing ) Giáo viên bộ môn :Vũ Thị Dương Lớp : KHMT 1 K2 Nhóm số 3 : Đào Đức Anh Nguyễn Thị Lệ Chi Trần Trung Hiếu Lê Thái Hoàng Lời mở đầu Trong ngành kỹ nghệ phần mềm, năm 1979, có một quy tắc nổi tiếng là: “Trong một dự án lập trình điển hình, thì xấp xỉ 50% thời gian và hơn 50% tổng chi phí được sử dụng trong kiểm thử các chương trình hay hệ thống đã được phát triển”. Và cho đến nay, sau gần một phần 3 thế kỷ, quy tắc đó vẫn còn đúng. Đã có rất nhiều ngôn ngữ, hệ thống phát triển mới với các công cụ tích hợp cho các lập trình viên sử dụng phát triển ngày càng linh động. Nhưng kiểm thử vẫn đóng vai trò hết sức quan trọng trong bất kỳ dự án phát triển phần mềm nào. Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “ Sinh viên của chúng ta tốt nghiệp và đi làm mà không có được những kiến thực thực tế cần thiết về cách để kiểm thử một chương trình. Hơn nữa, chúng ta hiếm khi có được những lời khuyên bổ ích để cung cấp trong các khóa học mở đầu về cách một sinh viên nên làm về kiểm thử và gỡ lỗi các bài tập của họ”. Các tác giả của cuốn sách nổi tiếng “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm, Glenford J. Myers, Tom Badgett, Todd M. Thomas, Corey Sandler đã khẳng định trong cuốn sách của mình rằng: “ Hầu hết các thành phần quan trọng trong các thủ thuật của một nhà kiểm thử chương trình là kiến thức về cách để viết các ca kiểm thử có hiệu quả”. Việc kiểm thử phần mềm thật sự quan trọng trong “dây chuyền” sản xuất phần mềm. Đây cũng chính là lý do để nhóm em nghiên cứu về đề tài này, và chính xác hơn là về kiểm thử tích hợp mà chúng em sẽ trình bày dưới đây. Do còn nhiều khó khăn trong việc thu thập và dịch tài liệu nên chúng em sẽ còn nhiều thiếu sót trong khi trình bày, vậy kính mong cô giáo xem xét và giúp đỡ thêm cho chúng em. Chúng em xin chân thành cảm ơn !Mục lục Giới thiệu chung về kiểm thử tích hợp Một nhân viên mới chập chững bước vào giới phần mềm có thể sẽ đặt ra một câu hỏi sau khi tất cả các Mô đun đã được kiểm thử “Nếu tất cả các Mô đun đều để riêng lẻ, tại sao bạn lại nghi ngờ rằng chúng sẽ phát huy tác dụng khi được đặt cùng nhau?”. Tất nhiên, vấn đề là ở chỗ đưa chúng vào một giao diện “cùng nhau”. Bạn có thể bị mất dữ liệu trong giao diện; mô đun này vô ý có những ảnh hưởng tiêu cực tới mô đun khác; các chức năng con khi kết hợp cùng với nhau có thể không tạo ra được chức năng mong muốn; sự sai lệch ở mức có thể chấp nhận được bị phóng lên thành mức không thể chấp nhận được; cấu trúc dữ liệu toàn cầu có thể gặp phải nhiều vấn đề. Thật không may là danh sách này còn rất là dài. Có một phương pháp kiểm thử có hệ thống để xây dựng cấu trúc chương trình trong khi đó tiến hành các bài kiểm thử để phát hiện ra lỗi liên quan đến lập giao diện. Mục tiêu là để kiểm thử các bộ phận và xây dựng một cấu trúc chương trình đã được kiểm thử chính tả khi thiết kế. Thường có xu hướng cố gắng thực hiện tích hợp không theo trình tự từng bước; có nghĩa là để xây dựng một chương trình sử dụng phương pháp tiếp cận “tức thời/đột ngột”. Tất cả các bộ phận được kết hợp trước với nhau. Toàn bộ chương trình được kiểm thử dưới dạng tổng thể. Kết quả là thường xảy ra sự lộn xộn! Bạn gặp phải hàng loạt lỗi. Việc sửa lỗi là rất khó vì việc cô lập các nguyên nhân rất phức tạp do chương trình quá rộng. Một khi đã sửa được các lỗi này, các lỗi khác sẽ lại xuất hiện và quá trình cứ tiếp diễn liên tục như thế. Tích hợp theo trình tự từng bước mâu thuẫn với phương pháp tiếp cận “tức thời”. Chương trình được thiết lập và kiểm thử trong các gia lượng nhỏ, nơi dễ tách và sửa lỗi hơn; giao diện có khả năng được kiểm thử toàn bộ hơn; và có thể áp dụng một phương pháp kiểm thử có hệ thống. Phương pháp kiểm thử được nói đến ở đây là phương pháp kiểm thử tích hợp. Đặc điểm của kiểm thử tích hợp: Là một kiểu kiểm thử cao cấp hơn kiểm thử đơn vị (Unit testing) nhưng lại được xếp thấp hơn kiểm thử hệ thống (System testing) và kiểm thử người dùng (User Acceptance Testing) Được thực hiện sau kiểm thử đơn vị nhưng trước kiểm thử hệ thống Thường xuyên phát hiện được lỗ hổng cũng như các lỗi của hệ thống Có thể áp dụng cho việc phát triển tự do Hình 1. Sơ đồ các cấp độ kiểm thử Khi nào thì sử dụng kiểm thử tích hợp? Khi hệ thống là rất lớn (“500K + LOC”) Khi hệ thống là cả phần mềm và phần cứng Khi có quá nhiều lỗi trong giai đoạn kiểm thử hệ thống và kiểm thử người dùng Khi bạn có quá nhiều các tương tác giữa các phần mềm Khi hệ thống thiết kế là một hệ thống thời gian thực Khi ban có yêu cầu cao hơn về hệ thống của mình … Mục tiêu của kiểm thử tích hợp: Phát hiện lỗi xảy ra giữa các Unit Tích hợp các Unit thành các hệ thống nhỏ (subsyetem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm thử ở múc hệ thống (system testing) Trong kiểm thử đơn vị các lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự kiểm tra đầy dủ khi các Unit kết hợp với nhau trong khi thực hiện kiểm thử tích hợp. Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thự hiện trên các Unit đã được kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức Unit đã được sửa chữa Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể. Có 4 loại kiểm thử trong Integration Test: Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thử cấu trúc nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các câu lệnh và nhánh bên trong. Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm thử chức năng chỉ chú trọng đến chức năng của chương trình, mà không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật. Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ thống. Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống. Các bước kiểm thử tích hợp Kiểm tra tích hợp gồm các bước sau: Bước 1: Thiết lập kế hoạch kiểm thử Bước 2: Thiết lập các bài và dữ liệu kiểm thử Bước 3: Tạo các tập lệnh để thực hiện các bài kiểm thử nếu có thể. Bước 4: Một khi tất cả các bộ phận đã được tích hợp, thực hiện các bài kiểm thử Bước 5: Vá lỗi nếu có và kiểm thử mã Bước 6: Lặp lại quy trình kiểm thử cho đến khi tất cả các bộ phận đã được tích hợp thành công Kế hoạch kiểm tra Phần mềm đã được tích hợp Báo cáo chấp thuận Kế hoạch phát triển Tích hợp và kiểm tra Phần mềm đã được phát triển Sơ đồ phát triển Các tiêu chuẩn để được người dùng chấp nhận Kế hoạch kiểm tra Nó mô tả một trong các yếu tố sau: Các bài kiểm tra sẽ được tiến hành như thế nào Danh sách các đối tượng cần được kiểm tra Vai trò và trách nhiệm Yêu cầu tiên quyết để bắt đầu kiểm tra Kiểm tra môi trường Giả thuyết Làm gì sau khi kiểm tra thành công Làm gì khi kiểm tra không thành công Làm thế nào để viết một bài kiểm tra tích hợp? Một bài kiểm thử đơn giản miêu tả chính xác bài kiểm tra sẽ được thực hiện như thế nào. Các bài kiểm thử tích hợp tập trung vào dòng lưu chuyển dữ liệu/thông tin/kiểm soát từ một bộ phận sang một bộ phận khác. Vì thế các bài kiểm thử tích hợp phải tập trung vào những tình huống trong đó một bộ phận được gọi ra từ một bộ phận khác. Tương tự toàn bộ chức năng áp dụng phải được kiểm thử để đảm bảo rằng các áp dụng phát huy tác dụng khi các bộ phận khác nhau được đặt cùng nhau. Các bài kiểm thử tích hợp được đưa vào thành một nhóm từ một bộ các bài kiểm thử tích hợp. Mỗi bộ có thể tập trung vào một đối tượng khác nhau. Nói cách khác, các bộ kiểm thử khác nhau có thể được tạo ra để tập trung vào các lĩnh vực áp dụng khác nhau. Như đã nêu phía trước, một nhóm kiểm thử có thể được tạo ra để thực hiện các bài kiểm tra. Vì thế các bài kiểm thử phải càng chi tiết càng tốt. Bảng ví dụ bài kiểm thử: ID bài kiểm thử Mô tả bài kiểm thử Dữ liệu đầu vào Kết quả mong đợi Kết quả thực Thành công/không thành công Ghi chú Ngoài ra có thể bao gồm cả: Tên bộ kiểm thử Kiểm thử bằng Ngày tháng Kiểm thử lặp (Có thể thực hiện kiểm thử tích hợp lặp lại một hoặc nhiều lần) Làm việc để hướng tới một bài kiểm tra tích hợp hiệu quả: Có rất nhiều yếu tố ảnh hưởng đến kiểm tra tích hợp phần mềm và kiểm tra phần mềm: 1) Quản lý cấu trúc phần mềm: Do kiểm thử tích hợp tập trung vào việc tích hợp các bộ phận và các bộ phận có thể được xây dụng bằng những người phát triển khác nhau và thậm chí bởi những nhóm phát triển khác nhau, điều quan trọng là phiên bản các bộ phận được kiểm tra. Điều này nghe có vẻ rất là cơ bản, nhưng vấn đề lớn nhất gặp phải là tích hợp phiên phản các bộ phận chính xác. Kiểm tra tích hợp có thể thực hiện sau vài lần lặp lại và vá lỗi mà các bộ phận có thể thay đổi. Vì thế, điều quan trọng là một chính sách quản lý cấu trúc phần mềm (SCM) phải có sẵn. Chúng ta phải có khả năng tìm các bộ phận và các phiên bản của chúng. Vì thế mỗi khi ta tích hợp các bộ phận ứng dụng, chúng ta biết chính xác phiên bản này sẽ đi vào quá trình xây dựng. 2)Qúa trình xây dựng tự động nếu cần thiết: sẽ có rất nhiều lỗi do phiên bản không chính xác các bộ phận được gửi cho quá trình xây dựng hoặc thiếu một số bộ phận. Nếu có thể, viết một tập lệnh để tích hợp và triển khai các bộ phận. Điều này sẽ giảm các lỗi thủ công. 3) Tài liệu: xắp xếp tài liệu quá trình tích hợp/xây dựng để loại bỏ các lỗi do bỏ qua hoặc không nhìn thấy. Người chịu trách nhiệm tích hợp các phần mềm có thể quên chạy tập lệnh yêu cầu và quá trình kiểm thử tích hợp sẽ không cho kết quả chính xác. 4) Tìm kiếm lỗi: Kiểm thử tích hợp sẽ mất hướng nếu không phát hiện chính xác lỗi. Mỗi lỗi phải được ghi lại và tìm kiếm. Thông tin phải chỉ rõ cách vá lỗi. Đây là thông tin vô giá. Nó có thể giúp hỗ trợ quá trình tích hợp và thực hiện trong tương lai. Trong các phần sau đây trình bày một số bước tích hợp khác nhau. Một số phương pháp kiểm thử tích hợp Top-down Intergration (Kiểm thử tích hợp từ trên xuống dưới) Kiểm thử tích hợp từ trên xuống dưới là một phương pháp gia lượng áp dụng cho việc xây dựng cấu trúc chương trình. Các mô đun được tích hợp bằng cách di chuyển theo chiều hướng xuống theo trình tự kiểm soát cấp bậc, bắt đầu bằng mô đun điều khiển chính (chương trình chính). Các mô đun phụ (và các mô đun sau cùng) đến mô đun điều khiển chính được ghép lại thành một cấu trúc hoặc là theo lối nhanh nhất hoặc lâu nhất (depth-first or bread-first manner). Hình 2 Kiểm thử tích hợp từ trên xuống Xem hình 2, tích hợp depth-first sẽ tích hợp tất cả các bộ phận vào một đường điều khiển của cấu trúc. Việc lựa chọn con đường là rất mơ hồ và phụ thuộc vào đặc điểm ứng dụng cụ thể. Ví dụ, lựa chọn đường theo chiều tay trái, các bộ phận M1, M2 , M5 sẽ được tích hợp trước. tiếp đó M8 hoặc (nếu cần chức năng phù hợp của M2) M6 sẽ được tích hợp. Sau đó, phương pháp điều khiển bàn tay phải và trung tâm sẽ được xây dựng. Breadth-first integration kết hợp tất cả các bộ phận bổ sung trực tiếp ở mỗi mức độ, chuyển qua cấu trúc theo phương ngang. Từ hình vẽ, các bộ phận M2, M3, và M4 (thay cho S4) sẽ được tích hợp trước . Mức điều khiển tiếp theo, và cứ tiếp tục như thế Quá trình tích hợp được thực hiện trong 5 bước: Mô đun điều khiển chính được sử dụng làm bộ điều khiển kiểm thử và các mô đun tiếp theo bổ sung cho tất cả các bộ phận bổ sung trực tiếp cho mô đun điều khiển chính. Tùy thuộc vào phương pháp tích hợp được chọn (ví dụ depth or breadth first), các mô đun bổ sung tiếp theo được thay thế theo trình tự với các bộ phận thực. Các bài kiểm thử sẽ được tiến hành khi mỗi mô đun được tích hợp Khi hoàn thành từng bài kiểm thử một, các bộ phận tiếp theo sẽ được thay thế bởi bộ phận thực. Kiểm thử hồi quy (phần V) có thể được tiến hành để đảm bảo không xảy ra lỗi mới. Quá trình tiếp tục từ bước thứ hai cho đến khi toàn bộ cấu trúc chương trình được xây dựng. Các bước tích hợp theo hướng từ trên xuống kiểm thử các điểm điều khiển hoặc quyết định chính ở phần đầu quá trình kiểm thử. trong một cấu trúc chương trình được với hệ số rõ ràng, việc đưa ra quyết định sẽ diễn ra ở các bậc cao hơn theo trình tự và vì thế được bắt gặp đầu tiên. Nếu tồn tại các vấn đề điều khiển chính, việc phát hiện ra sớm là vô cùng cần thiết. Nếu chọn phương pháp tích hợp depthfirst, có thể tiến hành và trình bày một chức năng hoàn chỉnh của phần mềm. Ví dụ, giả sử một cấu trúc chuyển giao trong đó có một chuỗi các đầu vào tương tác với nhau được yêu cầu, thực hiện và hợp thức hóa qua một đường đến. Đường đến có thể được tích hợp theo cách từ trên xuống dưới. Tất cả các đầu vào xử lý (để chuyển đi sau này) có thể được thể hiện trước khi các yếu tố khác của cấu trúc đã được tích hợp. Việc thể hiện ngay từ đầu khả năng mang chức năng là rất có ích đối với người phát triển và khách hàng. Phương pháp từ trên xuống có vẻ không phức tạp, nhưng trên thực tế, có thể nảy sinh các vấn đề logic. Một trong những vấn đề thường gặp xảy ra khi xử lý ở mức thấp theo thứ tự được yêu cầu để kiểm thử ở các mức cao hơn. Các mô đun phụ thay thế các mô đun mức thấp ở giai đoạn đầu của quá trình kiểm thử từ trên xuống. Vì thế, không có bất kì dữ liệu đáng kể nào có thể chuyển lên trên trong cấu trúc chương trình. Người kiểm thử sẽ đứng giữa 3 lựa chọn: Hoãn các bài kiểm thử lại cho đến khi các mô đun phụ được thay thế bằng mô đun thực Phát triển các mô đun phụ thực hiện các chức năng hạn chế thức đẩy mô đun thực Tích hợp phần mềm từ dưới lên trên. Phương pháp đầu tiên (hoãn các bài kiểm thử lại cho đến khi các mô đun phụ được thay thế bằng mô đun thực) làm cho chúng ta mất điều khiển giữa các bài kiểm thử cụ thể và sự kết hợp các mô đun cụ thể. Việc này có thể dẫn tới khó khăn trong việc xác định nguyên nhân gây lỗi và có xu hướng vi phạm bản chất giới hạn của phương pháp từ trên xuống. Phương pháp thứ 2 có thể phát huy tác dụng nhưng có thể dẫn đến tình trạng phải thực hiện thêm nhiều bước nữa, vì các mô đun phụ trở nên ngày càng phức tạp. Phương pháp thứ 3, gọi là kiểm thử từ dưới lên, được trình bày trong phần tiếp theo. Ví dụ Khi cần xây dựng một hệ thống quản lý bán hàng điện tử có mô hình như hình dưới đây: Quản lý mua, bán và bảo hành thiết bị máy tính Báo Cáo Thống Kê Lập báo cáo doanh thu QL Bán Hàng QL Nhập Hàng QL Bảo Hành Kiểm tra hàng trong kho Lập phiếu đặt hàng Kiểm tra phiếu bảo hành Lập hoá đơn Giao hàng Thanh toán Báo cáo TB đã bán Kiểm tra chất lượng hàng Lập phiếu nhập Thông báo từ chối nhập Lập phiếu bảo hành Lập hoá đơn Báo cáo TB tồn kho Báo cáo TB bảo hành Thông báo từ chối xuất Đầu tiên khi muốn xây dựng hệ thống ta phải xây dựng các chức năng chính của hệ thống như chức năng quản lý bán hàng, quản lý nhập hàng, quản lý bảo hành, báo cáo thống kê. Sau đó mới có thể xây dựng tiếp các chức năng con khác sau Ta có lập một sơ đồ tích hợp các chức năng của hệ thống quản lý bán hàng như sau: QL Bán Hàng Kiểm tra hàng trong kho Lập hoá đơn Giao hàng Thanh toán Thông báo từ chối xuất Thanh toán bằng tiền mặt Thanh toán bằng thẻ Giao hàng tận nhà Tùy theo yêu cầu của từng công ty mà ta có thể tích hợp hay loại bỏ bớt các thành phần của hệ thống Bottom-up Intergration (Kiểm thử tích hợp từ dưới lên) Kiểm thử tích hợp từ dưới lên, như tên gọi của nó, bắt đầu xây dựng và kiểm thử bằng các mô đun nguyên tử (có nghĩa là các bộ phận ở mức thấp nhất trong cấu trúc chương trình). Do các bộ phận được tích hợp từ dưới lên, việc xử lý yêu cầu đối với các bộ phận bổ sung cho một mức cho trước luôn có sẵn và loại bỏ yêu cầu cần các mô đun bổ sung. Phương pháp tích hợp từ dưới lên có thể được tiến hành theo các bước sau: Các bộ phận ở mức thấp được kết hợp với nhau thành một nhóm thực hiện chức năng phần mềm cụ thể. Một driver (chương trình điều khiển để kiểm thử) được viết để kết hợp các đầu vào và đầu ra kiểm thử. Nhóm được kiểm thử Các Driver được loại bỏ và nhóm được kết hợp di chuyển lên trên trong cấu trúc chương trình. Tích hợp tiến hành theo các bước trình bày trong hình 3. Các bộ phận được kết hợp để hình thành nhóm 1, 2 và 3. Mỗi nhóm được kiểm thử bằng driver (trình bày dưới dạng block nét đứt). Các bộ phận trong nhóm 1 và 2 bổ sung cho Ma. Drivers D1 và D2 được loại bỏ và nhóm được lập giao diện trực tiếp cho Ma. Tương tự, driver D3 cho nhóm 3 được loại bỏ trước khi tích hợp bằng mô đun Mb. Cả Ma và Mb sẽ được tích hợp bằng bộ phận Mc, và cứ như thế. Hình 3: Kiểm thử tích hợp từ dưới lên Khi tích hợp di chuyển lên phía trên, yêu cầu tách các driver kiểm thử giảm dần. Thực tế, nếu 2 mức trên cùng của cấu trúc chương trình được tích hợp từ trên xuống, số lượng driver có thể giảm đi và quá trình tích hợp của nhóm sẽ đơn giản hơn nhiều. Ví dụ Xây dựng hệ thống quản lý thư viện Khi thư viên của nhà trường có phòng lưu trữ sách thì sẽ có nhu cầu có một phòng ban quản lý các đầu sách, số lượng cùng loại, tình trạng của sách trong thư viện thì sẽ phải thành lập một phòng quản lý sách. Sách của nhà trường lại có khả năng cho sinh viên trong trường mượn để có thể học tập và ngiên cứu nên cùng với phòng quản lý sách các yêu cầu mượn sách tạo lên một phòng mượn sách. Sau khi nghiên cứu xong sách sinh viên lại có nhu cầu trả sách để có thể mượn sách khác và bộ phận quản lý trả sách được thành lập. Dựa vào các thành phần đã nêu trên nhà trường có thể thành lập một thư viện sách với các chức năng quản lý sách, cho mượn sách…tùy vào yêu cầu của mỗi trường một khác nhau thì sẽ có cách cấu thành các thành phần khác nhau. Dưới đây là một sơ đồ đơn giản về hệ thống quản lý thử viện được xây dựng theo phương pháp tích hợp từ dưới lên: Quản lý thư viện Quản lý mượn sách Yêu cầu mượn sách Quản lý trả sách Quản lý sách Quản lý số lượng sách Quản lý tình trạng sách Regression Testing (Kiểm thử hồi quy) Mỗi khi một mô đun mới được bổ sung dưới dạng một bộ phận của kiểm thử tích hợp, phần mềm sẽ thay đổi. Các đường dữ liệu mới được thiết lập, có thể xảy ra I/O mới, và gọi ra logic điều khiển mới. Trong bước kiểm thử tích hợp tiếp theo, kiểm thử hồi quy là sự thực hiện lại của một số chuỗi nhỏ trong các bài kiểm thử đã được thực hiện để đảm bảo không sinh ra các hiệu ứng phụ. Ở phạm vi rộng hơn, các bài kiểm thử thành công (bất kì loại nào) dẫn đến sự phát hiện ra lỗi, và lỗi phải được sửa. Bất cứ khi nào một phần mềm được sửa lỗi, một số khía cạnh của cấu trúc phần mềm (chương trình, tài liệu hoặc dữ liệu hỗ trợ nó) bị thay đổi. Kiểm thử hồi quy hỗ trợ để đảm bảo rằng các thay đổi (do kiểm thử hoặc do các lý do khác) không dẫn đến các lỗi khác. Kiểm thử hồi quy có thể được thực hiện thủ công, bằng cách thực hiện lại các bài kiểm thử hoặc sử dụng công cụ capture/playback. Công cụ Capture/playback cho phép kĩ sư phần mềm thực hiện bài kiểm thử và lấy kết quả cho những lần chạy lại và so sánh. Kiểm thử hồi quy bao gồm 3 lớp kiểm thử khác nhau: Mẫu đại diện sẽ thực hiện chức năng của phần mềm Các bài kiểm thử bổ sung tập trung vào chức năng phần mềm có thể bọ ảnh hưởng bởi các thay đổi. Các bài kiểm thử tập trung vào các bộ phận của phần mềm đã bị thay đổi. Hình 4: Sơ đồ luồng kiểm thử tích hợp (Source base77.com) Do quá trình kiểm thử tích hợp được tiếp diễn, số bài kiểm thử tích hợp có thể tăng lên khá nhiều. Vì thế, bộ kiểm thử hồi quy phải được thiết kế để chỉ bao gồm những bài kiểm thử dùng để xử lý một hoặc nhiều lớp lỗi trong mỗi chức năng của chương trình. việc thực hiện lại mỗi bài kiểm thử cho mỗi chức năng chương trình là không thực tế và không hiệu quả một khi xảy ra sự thay đổi. Smoke Testing Smoke testing là một phương pháp kiểm thử thường được sử dụng khi sản phẩm phần mềm có bản quyền được phát triển. Nó được thiết kế dưới dạng một cơ cấu dùng cho các dự án có giới hạn về thời gian chặt chẽ, cho phép nhóm phần mềm tiếp cận với dự án trên một nền tảng thường xuyên. Phương pháp kiểm thử này xoay quanh các hoạt động sau: Các bộ phận của phần mềm đã được đưa thành dạng code được tích hợp vào một nhóm. Một nhóm có thể bao gồm các file dữ liệu, thư viện, các mô đun có thể tái sử dụng, các bộ phận cần phải thực hiện một hoặc nhiều chức năng của sản phẩm. Một chuỗi các bài kiểm ta được thiết kế để tìm ra lỗi để giúp nhóm có thể thực hiện tốt chức năng của nó. Mục đích là tìm ra lỗi có nhiều khả năng làm chậm tiến trình phát triển phần mềm nhất. Nhóm được tích hợp với các nhóm khác và toàn bộ sản phẩm được tiến hành smoke test hàng ngày. Phương pháp tích hợp có thể là từ trên xuống hoặc từ dưới lên. Tần số kiểm thử hằng ngày toàn bộ sản phẩm có thể làm một số người ngạc nhiên. Tuy nhiên, tần số kiểm thử cho phép cả người quản lý và người thực tập một đánh giá thực tế về quá trình kiểm thử tích hợp. McConnell [MCO96*] mô tả smoke test theo cách sau đây: Smoke test được tiến hành trên cả hệ thống từ đầu này đến đầu khác. Nó phải có khả năng phát hiện được các vấn đề chính. Smoke test phải đủ toàn diện để nếu nhóm được thông qua, bạn có thể giả sử rằng đủ ổn định để kiểm thử toàn diện hơn. Smoke testing mang lại rất nhiều lợi ích khi được áp dụng vào các dự án phức tạp, kĩ thuật phần mềm có quy định về thời gian nghiêm ngặt: Nguy cơ tích hợp được giảm thiểu. do smoke tests được thực hiện hàng ngày, những hiện tượng không tương thích và các lỗi khác thường được phát hiện sớm, giảm khả năng tác động đến kế hoạch thực hiện khi lỗi không được phát hiện. Chất lượng sản phẩm cuối cùng được nâng cao. Do phương pháp thực hiện là hướng xây dựng (tích hợp), smoke testing có khả năng phát hiện lỗi chức năng và các khuyết tật thiết kế ở mức bộ phận. Nếu các khuyết tật này được sửa sớm, ta sẽ có chất lượng sản phẩm tốt hơn. Chuẩn đoán lỗi và sửa được đơn giản hóa. tương tự như phương pháp kiểm thử tích hợp, lỗi lộ ra trong quá trình smoke testing thường gắn liền với “gia số phần mềm mới” – điều này có nghĩa là, phần mềm vừa được bổ sung vào nhóm có khả năng là nguyên nhân của lỗi mới xuất hiện. Tiến độ rất dễ tiếp cận. từng ngày một, các bộ phận của phần mềm càng được tích hợp thêm và được đưa ra hoạt động. Điều này cải thiện không khí của nhóm và cho phép người quản lý biết được rằng tiến độ đang được đẩy nhanh. * [MCO96] McConnell, S., “Best Practices: Daily Build and Smoke Test”, IEEE Software, vol. 13, no. 4, July 1996, 143–144. Big Bang Người ta xây dựng mối liên hệ giữa các đơn thể để tạo thành một phiên bản hệ thống hoàn chỉnh, sau đó thử nghiệm phiên bản này. Như vậy người ta cần đến nhiều trình điều khiển (Driver) mỗi trình điều khiển cho một đơn thể, một trình stub cho tất cả các đơn thể của hệ thống, trừ đơn thể chính phải được kiểm thử bằng phương pháp kiểm thử đơn vị Phương pháp kiểm thử Big Bang có 2 đặc điểm chinh là: Kết hợp tất cả các modul đã kiểm thử thành 1 chương trình Tiến hành kiểm thử toàn bộ chương trình Phương pháp Bing Bang không an toàn cho việc kiểm thử ở chỗ tất cả các sai sót có thể xuất hiện cùng lúc, khi đó việc xác đinh từng lỗi sai sẽ gặp nhiều khó khăn. Hơn nữa phương pháp kiểm thử này đòi hỏi một lượng tối đa các trình điều khiển và các stub. Vì vậy thương thì người ta hay dùng các phương pháp kiểm thử từ trên xuống hay kiểm thử từ dưới lên Thảo luận xung quanh kiểm thử tích hợp (Comments on Intergration Testing) Đã có rất nhiều bài thảo luận (ví dụ [BEI84]*) về ưu điểm và nhược điểm của phương pháp kiểm thử từ trên xuống và từ dưới lên. Nói chung, ưu điểm của phương pháp này lại trở thành nhược điểm của phương pháp khác. nhược điểm chủ yếu của phương pháp từ trên xuống là cần phải có các mô đun phụ và các khó khăn kiểm thử gặp phải có thể theo kèm. Các vấn đề gắn liền với các mô đun phụ có thể nhanh chóng được bù lại bởi các ưu điểm của các chức năng điều khiển kiểm thử chính. Nhược điểm chủ yếu của phương pháp tích hợp từ dưới lên là “chương trình dưới dạng tổng thể không tồn tại cho đến khi bổ sung mô đun cuối cùng” [MYE79*]. Nhược điểm này được giảm bớt đi bằng cách thiết kế kiểm thử dễ dàng hơn và không có các mô đun phụ. Việc lựa chọn phương pháp tích hợp phụ thuộc vào đặc điểm phần mềm và đôi khi phụ thuộc vào kế hoạch dự án. Nói chung, một phương pháp kết hợp sử dụng kiểm thử từ trên xuống cho các mức cao hơn của cấu trúc chương trình, kết hợp với kiểm thử từ dưới lên cho các mức bổ sung có thể là một giải pháp tốt nhất. Khi thực hiện kiểm thử tích hợp, người kiểm thử phải chỉ rõ mô đun quan trọng. Một mô đun quan trọng có một hoặc các tính chất sau: (1) Giải quyết một số yêu cầu phần mềm (2) Có mức độ điều khiển cao (cao cả trong cấu trúc chương trình) (3) Phức tạp và không có lỗi (sự phức tạp có thể được dùng làm bộ chỉ báo) (4) Có các yêu cầu hoạt động tốt. Các mô đun quan trọng phải được kiểm thử càng sớm càng tốt. Thêm vào đó, kiểm thử hồi quy phải tập trung vào chức năng của mô đun quan trọng. * [BEI84] Beizer, B., Software System Testing and Quality Assurance, Van Nostrand- Reinhold, 1984. * [MYE79] Myers, G., The Art of Software Testing, Wiley, 1979. Tư liệu về kiểm thử tích hợp (Intergration Test Documentation) Một kế hoạch tổng thể cho sự tích hợp phần mềm và một mô tả về các bài kiểm tra cụ thể được đưa ra trong phần Mô tả kiểm tra. trong đó gồm một kế hoạch kiểm tra, một quy trình kiểm tra, là một sản phẩm của quá trình phần mềm và trở thành một phần trong cấu trúc phần mềm. Kế hoạch kiểm tra miêu tả toàn bộ quy trình tích hợp. Kiểm tra được chia thành các giai đoạn và các nhóm đề cập đến các đặc điểm chức năng và hoạt động của phần mềm. Ví dụ, kiểm tra tích hợp hệ thống CAD có thể chia ra thành các giai đoạn kiểm tra như sau: Giao tiếp với người dùng (lựa chọn điều khiển, tạo hình vẽ, biểu diễn minh họa, xử lý lỗi và biểu diễn) Thao tác và phân tích dữ liệu (tạo ký hiệu, xác định kích thước, quay, tính toán và tính chất vật lý) Xử lý và tạo hiển thị (hiển thị 2 chiều, hiển thị 3 chiều, biểu đồ) Quản lý dữ liệu (truy cập, update, nhất quán và làm việc) Mỗi giai đoạn và các giai đoạn nhỏ (trong ngoặc đơn) miêu tả nhóm chức năng rộng hơn trong phần mềm và có thể liên quan tới phân vùng cụ thể của cấu trúc chương trình. Vì thế, nhóm chương trình (nhóm mô đun) được tạo ra tương đương với từng giai đoạn. Các tiêu chí sau đây và các bài kiểm tra tương ứng với chúng được áp dụng cho tất cả các giai đoạn kiểm tra: Thống nhất về giao diện. Các giao diện bên trong và bên ngoài được kiểm tra dưới dạng từng mô đun một và được tích hợp với cấu trúc. Tính phù hợp về chức năng. Các bài kiểm tra được thiết kế để phát hiện ra lỗi được tiến hành. Nội dung thông tin. Các bài kiểm tra được thiết kế để phát hiện lỗi có liên quan đến cấu trúc khu vực và toàn bộ được thực hiện. Khả năng làm việc. Các bài kiểm tra được thiết kế để xác nhận các mức hoạt động được thiết lập trong quá trình thiết kế phần mềm được thực hiện. Kế hoạch tiến hành tích hợp, phát triển các phần mềm phía trên, và các chủ đề liên quan được thảo luận riêng một phần trong kế hoạch kiểm tra. Bắt đầu và ngừng ngày tháng từng giai đoạn được thực hiện và các “cửa sổ có sẵn” cho từng mô đun được kiểm tra được xác định. Mô tả ngắn về phần mềm (nhóm và driver) tập trung vào các đặc điểm có thể yêu cầu nỗ lực lớn. Cuối cùng, môi trường và nguồn kiểm tra được miêu tả. Các cấu trúc phần cứng bất thường, chương trình mô phỏng không chính xác, và các công cụ kiểm tra hoặc kĩ thuật kiểm tra đặc biệt chỉ là một số ít trong số những chủ đề có thể được thảo luận. Quy trình kiểm tra chi tiết cần thiết để đạt được kế hoạch kiểm tra được mô tả sau. Thứ tự tích hợp và các bài kiểm tra tương ứng tại mỗi bước tích hợp được miêu tả. Một danh sách các bài kiểm tra (để sau này có thể xem lại) và kết quả mong muốn cũng được bao gồm trong đó. Một bản ghi kết quả kiểm tra, các vấn đề hoặc những khó khăn được ghi lại trong phần miêu tả kiểm tra. Thông tin có trong phần này có thể rất quan trọng trong quá trình duy trì phần mềm. Mẫu tham khảo phù hợp và phụ lục cũng được trình bày kèm theo. Tương tự như các phẩn tử của cấu trúc phần mềm khác, định dạng miêu tả kiểm tra có thể đi kèm trong nhu cầu cục bộ của việc tổ chức kĩ thuật phần mềm. Tuy nhiên, điều quan trọng là phải chú ý rằng quy trình tích hợp (có trong kế hoạch kiểm tra) và chi tiết kiểm tra ( miêu tả trong quy trình kiểm tra) là những yếu tố quan trọng. Ví dụ Chương trình đọc vào 3 giá trị nguyên từ hộp thoại vào. Ba giá trị này tương ứng với chiều dài 3 cạnh của 1 tam giác. Chương trình hiển thị 1 thông điệp cho biết tam giác đó là tam giác thường, cân, hay đều. Ba giá trị nhập vào thỏa mãn là 3 cạnh của một tam giác khi và chỉ khi cả 3 số đều là số nguyên dương, và tổng của 2 số bất kỳ trong 3 số phải lớn hơn số thứ 3. Khi đó, một tam giác đều là tam giác có 3 cạnh bằng nhau, tam giác cân là tam giác có 2 trong 3 cạnh bằng nhau, và tam giác thường thì có 3 cạnh khác nhau. Mã lệnh của chương trình: Do đặc tả có sự kết hợp đầu vào nên trước tiên, áp dụng phương pháp vẽ đồ thị nguyên nhân – kết quả. Nguyên nhân là: Cả 3 giá trị nhập vào đều là số nguyên dương. Tổng 2 số bất kỳ trong 3 số lớn hơn số còn lại. Hai trong 3 số có giá trị bằng nhau. Ba số có giá trị bằng nhau. Kết quả là: R1. Thông báo ba giá trị nhập vào lập thành tam giác thường. R2. Thông báo ba giá trị nhập vào lập thành tam giác cân. R3. Thông báo ba giá trị nhập vào lập thành tam giác đều. R4. Thông báo ba giá trị nhập vào không lập thành một tam giác. R5. Thông báo lỗi nhập dữ liệu. Hình 5: Đồ thị nguyên nhân – kết quả Bước tiếp theo là tạo bảng quyết định mục vào giới hạn. Chọn kết quả R1 là đầu tiên. R1 có mặt nếu nút các nút 12 và 3 = 1,0. Nút 12 = 1 khi 1 và 2 = 1,1. Áp dụng lần lượt cho sự có mặt của từng kết quả đầu vào, ta được bảng quyết định như sau: Bảng quyết định 1 2 3 4 5 1 1 1 1 1 0 2 1 1 0 3 0 1 4 1 R1 1 0 0 0 0 R2 0 1 0 0 0 R3 0 0 1 0 0 R4 0 0 0 1 0 R5 0 0 0 0 1 Bước cuối cùng là chuyển đổi bảng quyết định thành các ca kiểm thử. Các ca kiểm thử thu được như sau: STT Các điều kiện Ca kiểm thử Hành động 1 Cả 3 giá trị nhập vào đều là số nguyên dương, và tổng của 2 số bất kỳ trong 3 số luôn lớn hơn số thứ 3, và không có cặp 2 số bất kỳ nào trong 3 số đó là = nhau. 2,3,4 2,4,3 3,2,4 3,4,2 4,2,3 4,3,2 R1 2 Cả 3 giá trị nhập vào đều là số nguyên dương, và tổng cảu 2 số bất kỳ trong 3 số luôn lớn hơn số thứ 3, và tồn tại một cặp 2 số trong 3 số đó là = nhau. 3,3,4 3,4,3 4,3,3 R2 3 Cả 3 giá trị nhập vào đều là số nguyên dương, và cả 3 số có giá trị bằng nhau. 3,3,3 R3 4 Cả 3 giá trị nhập vào đều là số nguyên dương, và tồn tại 2 số trong 3 số có tổng nhỏ hơn hoặc bằng số còn lại. 1,2,4 Và 5 hoán vị của nó R4 5 Tồn tại một giá trị nhập vào không phải là số nguyên dương. A,2,2 -1,1,1 1.1,1,1 Và 2 hoán vị của mỗi trường hợp R5 Tài liệu tham khảo Software Engineering 5th edition – Pressman Unit& integration Testing Cong nghe phan mem_PhanHuyKhanh The_Art_Of_Software_Testing_Glenford J Myer_John Wiley & Sons Inc Software testing.pdf Foundations of software testing istqb-certification www.vietnamesetestingboard.org