1. Trang chủ
  2. » Luận Văn - Báo Cáo

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

31 666 1

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 31
Dung lượng 3,2 MB

Nội dung

Giới thiệu chung về kiểm thử tích hợpMộ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 đề

Trang 2

Mục lục

Bài tập lớn môn 1

NHẬP MÔN CÔNG NGHỆ PHẦN MỀM 1

Đề tài số 22: 1

KIỂM THỬ TÍCH HỢP 1

( Integration testing ) 1

Bài tập lớn môn 3

NHẬP MÔN CÔNG NGHỆ PHẦN MỀM 3

Đề tài số 22: 3

KIỂM THỬ TÍCH HỢP 3

( Integration testing ) 3

Trang 3

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

Nguyễn Thị Lệ Chi Trần Trung Hiếu

Lê Thái Hoàng

Trang 4

I 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 !

Trang 5

II 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”

Trang 6

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

1 Đặ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

Trang 7

• 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

Trang 8

3 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

Trang 9

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

4 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

Các tiêu chuẩn để được người dùng chấp nhận

Trang 10

5 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

6 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ử:

Trang 11

Kết quả mong đợi Kết quả thực

Thành công/không thành công

Trang 12

7 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

Trang 13

III Một số phương pháp kiểm thử tích hợp

1 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ế

Trang 14

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

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

Trang 15

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

Trang 16

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:

Đầ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

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

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

Trang 17

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:

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

2 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ử

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à

Ngày đăng: 29/07/2014, 23:20

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w