KIỂM THỬ HỆ THỐNG

D) CÁC CÁCH BIỂU DIỄN CỦA MÔ HÌNH PHÂN TÍCH

f. Đặc tả giao diện đối tượng

7.2. KIỂM THỬ HỆ THỐNG

Kiểm thử hệ thống liên quan tới việc tích hợp hai hoặc nhiều thành phần để thực thi các chức năng của hệ thống, sau đó kiểm thử toàn bộ hệ thống đã được tích hợp.

Trong tiến trình phát triển lặp, kiểm thử hệ thống liên quan tới việc kiểm thử một thành phần (increment) được bàn giao cho khách hàng; trong mô hình thác nước, kiểm thử hệ thống liên quan tới kiểm thử hệ thống hoàn chỉnh.

Với hầu hết các hệ thống phức tạp, kiểm thử hệ thống được chia thành 2 giai đoạn:

1. Kiểm thử tích hợp: Hệ thống được kiểm thử khi các thành phần được tích hợp vào hệ

thống. Nhóm kiểm thử có thể truy cập vào mã nguồn chương trình. Khi một vấn đề được phát hiện, nhóm sẽ cố gắng để tìm ra nguồn gốc của vấn đề và xác định những thành phần có thể gây lỗi. Kiểm thử tích hợp hầu hết đều liên quan đến việc tìm ra những khiếm khuyết của hệ thống.

2. Kiểm thử phát hành: là giai đoạn một phiên bản của hệ thống hoàn thành và được bàn giao cho khách hàng dùng thử. Giai đoạn này liên quan tới việc thẩm định xem hệ thống có đáp ứng đúng các yêu cầu và chắc chắn rằng hệ thống là đáng tin cậy. Kiểu kiểm thử này thường gọi là kiểm thử hộp đen, nghĩa là nhóm làm kiểm thử chỉ ra cho nhóm phát triển thấy phần mềm này làm việc hợp lý hay không hợp lý. Khi khách hàng có liên quan tới giai đoạn kiểm thử này thì người ta gọi là kiểm thử chấp nhận. Nếu phiên bản đủ tốt, người sử dụng có thể chấp nhận sử dụng nó.

Về cơ bản, có thể cho rằng việc kiểm thử tích hợp là kiểm thử một nhóm các thành phần của hệ thống một cách không đầy đủ. Kiểm thử phát hành liên quan tới việc kiểm thử một hệ thống được bàn giao cho khách hàng. Hiển nhiên, hai kiểu kiểm thử này có những điểm trùng lặp, đặc biệt là khi phát triển hệ thống theo kiểu gia tăng và hệ thống được chuyển giao là chưa hoàn thiện. Nói chung, kiểm thử tích hợp ưu tiên việc khám phá ra những khiếm khuyết của hệ thống, còn kiểm thử hệ thống liên quan tới việc đáp ứng những yêu cầu. Tuy nhiên, trong thực tế, có một số kiểm thử thẩm định và kiểm thử khiếm khuyết được tiến hành trong cả hai tiến trình này.

7.2.1. Kiểm thử tích hợp

Tiến trình kiểm thử tích hợp liên quan tới việc xây dựng một hệ thống từ các thành phần,

sau đó kiểm tra hệ thống đối với những vấn đề nảy sinh từ việc tương tác giữa các thành phần. Các thành phần được tích hợp có thể là các gói phần mềm thương mại, các thành phần tái sử dụng đã được phát triển cho một hệ thống cụ thể hoặc một thành phần mới được phát triển. Với

các hệ thống lớn, cả ba kiểu thành phần này đều có thể được sử dụng. Kiểm thử tích hợp kiểm tra xem các thành phần này làm việc với nhau như thế nào, gọi và biến đổi dữ liệu đúng, tại những

Ngược lại, ta có thể lựa chọn phương pháp tích hợp các thành phần cơ sở của hệ thống cung cấp các chức năng chung, chẳng hạn như mạng hoặc truy nhập CSDL, sau đó thêm các thành phần chức năng. Đây được gọi là phương pháp tích hợp dưới lên.

Trong thực tế, với nhiều hệ thống, các chiến lược tích hợp thường kết hợp cả hai phương pháp này, cả những thành phần cơ sở hạ tầng và các thành phần chức năng được thêm vào một cách gia tăng. Với cả hai phương pháp này, thường phải phát triển thêm mã nguồn để mô phỏng các thành phần khác và cho phép hệ thống thực thi.

Vấn đề chính nảy sinh trong quá trình tích hợp là việc xác định vị trí lỗi. Việc tương tác phức tạp giữa các thành phần hệ thống và khi một đầu ra bất thường được khám phá, có thể rất khó để xác định nơi xảy ra lỗi. Để dễ dàng hơn, người ta thường sử dụng cách tiếp cận gia tăng để tích hợp và thử nghiệm. Đầu tiên, tích hợp một cấu hình hệ thống tối thiểu và kiểm thử hệ thống này, sau đó lần lượt thêm các thành phần và kiểm thử sau từng bước tích hợp.

Ví dụ trong hình 7.3, A, B, C, D là các thành phần và T1-T5 là tập hợp các kịch bản kiểm thử của các chức năng được kết hợp trong hệ thống. T1, T2, T3 đầu tiên được thực thi trên một hệ thống bao gồm 2 thành phần A, B. nếu phát hiện ra khiếm khuyết, chúng sẽ được sửa. Thành phần C được tích hợp thêm vào và T1-T3 được lặp lại để nó không có sự bất thường với A và B. Nếu có vấn đề nảy sinh trong các trường hợp kiểm thử này, có nghĩa là lỗi sinh ra khi tích hợp thành phần mới. Nguồn gốc của vấn đề sẽ được xác định, việc phát hiện và sửa lỗi đơn giản hơn. Trường hợp kiểm thử T4 cũng được thực thi với hệ thống mới. Và cuối cùng, thành phần D được tích hợp vào hệ thống và sử dụng các kiểm thử đã có, cộng với một trường hợp kiểm thử mới

(T5).

Hình 7.3. Một trường hợp tích hợp tăng dần

Khi lập kế hoạch tích hợp, ta phải quyết định thứ tự của việc tích hợp các thành phần. Chẳng hạn như trong phương pháp phát triển cực đại XP, khách hàng liên quan tới tiến trình phát triển và là người quyết định thành phần nào sẽ được ưu tiên tích hợp trước. Trong cách tiếp cập tích hợp các thành phần thương mại, khách hàng có thể không liên quan và nhóm tích hợp sẽ quyết định thứ tự ưu tiên.

Trong trường hợp đó, thông thường người ta sẽ chọn những thành phần có các chức năng được sử dụng thường xuyên nhất. Ví dụ: trong hệ thống thư viện LIBSYS, bạn nên bắt đầu bằng

T3 T2 T1 T4 T5 A B C D T2 T1 T3 T4 A B C T1 T2 T3 A B

Test sequence 1 Test sequence 2 Test sequence 3 Lượt kiểm

việc tích hợp chức năng tìm kiếm. Và sau đó có thể thêm chức năng cho phép người sử dụng download tài liệu, cuối cùng là thêm các thành phần để thực hiện các chức năng khác.

Tất nhiên, trong thực tế, việc tích hợp không đơn giản như mô hình gợi ý. Thực thi các tính năng của hệ thống có thể được tiến hành bởi nhiều thành phần khác nhau. Để kiểm tra một tính năng mới, bạn có thể phải tích hợp vài thành phần khác nhau. Việc kiểm thử có thể phát hiện ra những lỗi trong tích hợp các thành phần độc lập này. Việc sửa lỗi sẽ khó hơn vì có thể phải thay đổi một nhóm các thành phần liên quan tới việc thực thi chức năng này. Hơn nữa, việc tích hợp và kiểm thử một thành phần mới có thể thay đổi framework của những thành phần tích hợp đã được kiểm thử. Những lỗi có thể không bộc lộ trong những kiểm thửđối với cấu hình hệ thống đơn giản hơn.

Điều này có nghĩa là khi một thành phần mới được tích hợp, điều quan trọng là phải chạy lại các kịch bản kiểm thử đã được thực thi trước đó như một kịch bản mới, đây là điều bắt buộc để xác nhận một chức năng mới của hệ thống. Việc chạy lại các kịch bản trước được gọi là kiểm thử ngược. Nếu kiểm thử ngược phát hiện ra vấn đề, ta phải kiểm tra xem vấn đề phát sinh từ đâu trong các thành phần trước mà việc tích hợp thêm thành phần mới làm xuất hiện lỗi.

Việc kiểm thử ngược là một công việc tốn kém và thường là không thể thực thi được nếu không có các công cụ kiểm thử tự động hỗ trợ. Trong phương pháp lập trình cực đại (XP), tất cả các kịch bản kiểm thử được viết trước khi thực thi mã nguồn. Khi đó dữ liệu kiểm thử và kết quả mong đợi được đặc tả và có thể sử dụng phương pháp kiểm thử tự động. Khi sử dụng một framework kiểm thử tự động, chẳng hạn như JUnit, các kịch bản kiểm thử có thể chạy lại một cách tự động. Phương pháp này là một đặc trưng của phương pháp lập trình cực đại, một tập hợp kịch bản kiểm thử hoàn thiện được tiến hành ngay khi có mã nguồn mới được tích hợp và mã nguồn mới này không được chấp nhận cho tới khi tất cả các kịch bản kiểm thử thực thi thành

công.

7.2.2. Kiểm thử phát hành

Kiểm thử phát hành là một tiến trình kiểm thử việc phát hành của hệ thống sẽ được chuyển giao cho khách hàng. Mục tiêu chính của tiến trình kiểm thử này là làm tăng độ tin cậy của nhà cung cấp, chứng tỏ rằng hệ thống đáp ứng được những yêu cầu khách hàng đặt ra. Nếu đúng, nhóm phát triển có thể phát hành sản phẩm hoặc chuyển giao cho khách hàng. Để chỉ ra rằng hệ thống đáp ứng đúng những yêu cầu đặt ra, ta phải chỉ ra rằng nó thực hiện theo đúng chức năng đã đặc tả, hiệu quả, tin cậy và không có lỗi khi sử dụng bình thường.

Kiểm thử phát hành thường là tiến trình kiểm thử hộp đen, các kịch bản kiểm thử được bắt nguồn từ đặc tả hệ thống. Hệ thống được xem như một hộp đen, các hoạt động của nó chỉ được xác định bởi việc nghiên cứu dữ liệu đầu vào và đầu ra có liên quan. Một tên khác của kiểu

Trong quá trình kiểm thử hệ thống phát hành, người kiểm thử nên cố gắng “phá hủy” hệ thống bằng cách lựa chọn các kịch bản kiểm thử nằm trong tập Ie trong hình 7.4. Điều đó có nghĩa là mục tiêu của kiểm thử là lựa chọn dữ liệu đầu vào sao cho có nhiều khả năng hệ thống sinh ra lỗi (đầu ra nằm trong tập Oe).

Hình 7.4. Mô hình kiểm thử hộp đen

Nhìn chung, quá trình kiểm thử hộp đen thường tuân theo các hướng dẫn sau:

1. Lựa chọn dữ liệu đầu vào để hệ thống sinh ra tất cả các thông báo lỗi.

2. Thiết kế dữ liệu đầu vào sao cho nó là nguyên nhân gây ra lỗi tràn bộ đệm đầu vào.

3. Lặp lại với cùng dữ liệu đầu vào hoặc một loạt các dữ liệu đầu vào ở nhiều thời điểm khác nhau.

4. Lựa chọn dữ liệu đầu vào để sinh ra các kết quả sai. 5. Kiểm thử đối với dữ liệu tính toán từ lớn đến nhỏ.

7.2.3. Xây dựng kịch bản kiểm thử hệ thống

Để xác minh hệ thống đáp ứng được những yêu cầu, cách kiểm thử tốt nhất là kiểm thử dựa trên các kịch bản, khi đưa ra một số kịch bản và phát triển các trường hợp kiểm thử từ những kịch bản này, ví dụ một kịch bản kiểm thử trong hệ thống phần mềm quản lý thư viện:

Hình 7.5. Một kịch bản mô tả một chức năng của hệ thống thư viện LIBSYS

Từ kịch bản này, nó có thể sinh ra một số trường hợp kiểm thử có thể được ứng dụng cho mục đích kiểm thử phát hành của LIBSYS:

Dữ liệu kiểm thử đầu vào

Hệ thống

Kết quả kiểm thử

Dữ liệu vào dẫn đến những tình huống bất thường

Kết quả đầu ra phát hiện lỗi còn

tồn tại

Một sinh viên ở Scotlan theo học ngành lịch sử Hoa Kỳ cần viết một báo cáo về chiến tranh biên giới ở miền tây nước Mỹ từ năm 1840 – 1880. Để làm báo cáo này, anh ta cần tìm tài liệu ở các thư viện. Anh ta truy cập vào hệ thống thư viện LIBSYS và sử dụng tiện ích tìm kiếm để tìm ra những tài liệu cần thiết.Anh ta tìm được một số tài liệu trong các thư viện khác nhau ở Mỹ và tải về. Tuy nhiên, với một tài liệu, anh ta cần phải xác minh từ phía trường học của mình rằng tài liệu này được sử dụng vào mục đích phi thương mại. Sinh viên này sau đó sử dụng tiện ích trong hệthống để xác minh thông tin. Nếu việc xác minh thành công, tài liệu sẽ được tải xuống máy chủ của thư viện đã được đăng ký và được in ra. Anh ta sẽ nhận được một tin nhắn từ hệ thống LIBSYS rằng anh ta sẽ nhận được một thông báokhi tài liệu được in xong.

1. Kiểm thử việc đăng nhập với cả 2 trường hợp: đăng nhập đúng và đăng nhập sai để chứng minh rằng, người đăng nhập đúng sẽ được chấp nhận, còn người đăng nhập sai sẽ bị từ chối.

2. Kiểm thử chức năng tìm kiếm sử dụng một truy vấn vào các nguồn tài nguyên để kiểm tra xem chức năng tìm kiếm này có tìm ra được tài liệu cần dùng hay không.

3. Kiểm thử chức năng hiển thị để kiểm tra thông tin về tài liệu được hiển thị chính xác.

4. Kiểm thử chức năng tải tài liệu sử dụng một truy vấn cho phép người dùng tải tài liệu về.

5. Kiểm thử email trả lời để chỉ ra rằng tài liệu đã tải xuống đãsẵn sàng sử dụng.

Với mỗi trường hợp kiểm thử, ta nên thiết kế một tập các dữ liệu kiểm thử, bao gồm cả trường hợp dữ liệu đúng và sai. Ta cũng nên tổ chức việc kiểm thử dựa trên các kịch bản, do đó những trường hợp thích hợp sẽ được kiểm thử trước, sau đó những trường hợp bất thường hoặc ngoại lệ sẽ được xem xét sau, khi đó những thành phần được sử dụng thường xuyên sẽ được kiểm thử nhiều lần nhất.

Trong trường hợpđặc tả phần mềm có sử dụng mô hình trường hợp sử dụng (use-case) thì

những use-case này được kết hợp với các lược đồ tuần tự có thể là cơ sở cho việc kiểm thử. Hai loại sơ đồ này có thể được sử dụng trong cả kiểm thử tích hợp và kiểm thử phát hành.

7.2.4. Kiểm thử hiệu năng

Khi một hệ thống được tích hợp hoàn chỉnh, có thể kiểm tra hệ thống với các thuộc tính nổi bật như hiệu năng và độ tin cậy. Kiểm thử hiệu năng được thiết kế để đảm bảo rằng hệ thống có thể xử lý việc tải dữ liệu có dụng ý. Loại kiểm thử này thường liên quan tới việc lập kế hoạch cho một loạt các trường hợp kiểm thử mà việc tải dữ liệu sẽ tăng dần cho tới khi hệ thống không chấp nhận nổi.

Như các kiểu kiểm thử khác, kiểm thử hiệu năng liên quan tới việc chứng minh rằng hệ thống đáp ứng được các yêu cầu của nó và khám phá ra các vấn đề và các khiếm khuyết trong hệ thống. Để kiểm thử yêu cầu hiệu năng của hệ thống đã hoàn thành, ta cần phải xây dựng một tập hợp các kịch bản kiểm thử phản ánh công việc hỗn hợp sẽ được thực hiện bởi hệ thống. Tuy nhiên, nếu 90% giao dịch trong hệ thống là kiểu A, 5% là kiểu B và phần còn lại là kiểu C, D, E, thì ta phải thiết kế tập các trường hợp kiểm thử mà phần lớn các trường hợp thuộc kiểu A. Mặt khác, sẽ không có một trường hợp kiểm thử chính xác về tính hiệu năng của hệ thống. Tuy nhiên,

ta có thể kiểm thử trường hợp thực hiện hệ thống vượt ra ngoài giới hạn thiết kế của hệ thống. Ví dụ: một hệ thống được thiết kế để xử lý 300 giao dịch trong một giây, một trường hợp kiểm thử có thể được thiết kế để xử lý trên 1000 giao dịch. Kiểm thử áp lực tiếp tục thực thi các

Kiểm thử áp lực thường liên quan tới các hệ thống phân tán trong môi trường mạng. Những hệ thống này thường xảy ra hiện tượng giảm hiệu suất khi bị quá tải. Mạng trở nên mất tác dụng khi phối hợp dữ liệu từ các bộ xử lý khác nhau. Vì thế tiến trình ngày càng chậm hơn khi phải chờ dữ liệu từ bộ xử lý khác.

7.3. KIỂM THỬ THÀNH PHẦN

Kiểm thử thành phần (đôi khi còn được gọi là kiểm thử đơn vị) là một tiến trình kiểm thử các thành phần độc lập trong hệ thống. Như đã thảo luận trong phần giới thiệu, đối với hầu hết các hệ thống, người phát triển thành phần chịu trách nhiệm kiểm thử thành phần do mình tạo ra. Các kiểu kiểm thử khác nhau được kiểm tra trong giai đoạn này là: