Kiểm thử phát hành

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.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à:

1. Kiểm thử các chức năng hoặc các phương thức độc lậpcủa lớp đối tượng.

2. Kiểm thử các lớp đối tượng có một số thuộc tính và phương thức.

3. Kiểm thử các thành phần hợp thành từ các đối tượng hoặc chức năng khác nhau. Những

thành phần hợp thành này có giao diện xác định được sử dụng để truy cập vào các chức năng của chúng.

7.3.1. Kiểm thử lớp đối tượng

Các chức năng hoặc phương thức độc lập là kiểu đơn giản nhất của thành phần và được kiểm thử như một tập những lời gọi các phương thức này từ các tham số đầu vào khác nhau. Ta có thể sử dụng cách tiếp cận này để thiết kế các trường hợp kiểm thử. Khi đang kiểm thử các lớp đối tượng, nên thiết kế các kịch bản kiểm thử bao trùm được tất cả các tính năng của đối tượng. Tuy nhiên, lớp đối tượng kiểm thử thường bao gồm:

1. Kiểm thử cách ly tất cả các chức năng của đối tượng.

2. Thiết lập và truy vấn tất cả các thuộc tính của đối tượng.

3. Kiểm tra đối tượng với tất cả các trạng thái có thể. Điều này có nghĩa là tất cả các sự kiện dẫn đến sự thay đổi trạng thái của đối tượng đều phải mô phỏng.

Ví dụ, hình 7.6 là giao diện của hệ thống trạm khí tượng được nêu ra ở chương trước. Đối tượng này chỉ có một thuộc tính xác định số hiệu của trạm, đây là một hằng số được đặt khi trạm được thiết lập. Tuy nhiên, thuộc tính này chỉ cần kiểm tra khi nó được thiết lập. Nhưng ta cần xây dựng các trường hợp kiểm thử các phương thức của đối tượng như: reportWeather, calibrate…

Một cách lý tưởng, các phương thức phải kiểm tra một cách độc lập, nhưng trong một số trường hợp, kiểm thử tuần tự là cần thiết. Ví dụ, khi kiểm tra phương thức shutdown, cần phải thực thi phương thức Start.

Hình 7.6. Giao diện của đối tượng WeatherStation

Để kiểm tra trạng thái của trạm thời tiết, ta sử dụng mô hình trạng thái chỉ ra trong hình 7.7. Qua mô hình này ta có thể xác định thứ tự các biến đổi trạng thái, do đó phải kiểm tra và xác

WeatherStation identifier reportWeather() celibrate (instruments) test() startup(instruments) shutdown(instruments)

định thứ tự các sự kiện gây ra sự biến đổi trạng thái. Về cơ bản, ta cần phải kiểm thử tất cả các trạng thái biến đổi có thể, mặc dù trên thực tế nó rất tốn kém.

Hình 7.7. Mô hình trạng thái của đối tượng Weather Station trong hệ thống trạm thời tiết

Ví dụ về thứ tự các trạng thái biến đổi nên được kiểm thử trong trạm thời tiết bao gồm:

Shutdown -> waiting -> Shutdown

Waiting ->calibrationg -> Testing -> transmiting – Waiting

Waiting -> Collecting -> Waiting -> Summarising -> Transmitting -> Waiting

Nếu trong hệ thống có các lớp kế thừa thì sẽ khó thiết kế các trường hợp kiểm thử cho các lớp đối tượng. Khi một lớp cha cung cấp các phương thức được kế thừa cho các lớp con khác nhau, tất cả các lớp con phải được kiểm thử các phương thức kế thừa này. Lý do phải kiểm thử lại là những thuộc tính hoặc phương thức kế thừa này đã thay đổi trong các lớp con.

7.3.2. Kiểm thử giao diện

Nhiều thành phần trong hệ thống không phải là những chức năng hoặc đối tượng đơn giản mà nó được tích hợp từ một số đối tượng khác nhau. Khi đó ta cần truy nhập vào những chức năng của các thành phần sau đó kiểm tra xem giao diện của các thành phần này có tương hợp với đặc tả hay không.

Hình 7.8 minh họa tiến trình kiểm tra giao diện. Giả sử rằng các thành phần A, B, C được tích hợp để tạo ra những thành phần lớn hoặc các hệ thống con. Các trường hợp kiểm thử không được xây dựng cho từng thành phần độc lập nhưng giao diện của thành phần hợp thành được tạo ra bằng việc kết hợp các thành phần này.

Hình 7.8. Tiến trình kiểm thử giao diện

Kiểm thử giao diện đặc biệt quan trọng trong phát triển phần mềm theo phương pháp hướng đối tượng hoặc hướng thành phần. Các đối tượng và các thành phần được xác định bởi giao diện của nó và có thể được tái sử dụng bằng việc kết hợp với các thành phần khác trong các hệ thống khác nhau. Những lỗi giao diện trong thành phần hợp thành không thể phát hiện khi kiểm thử các đối tượng hoặc thành phần độc lập. Những lỗi trong các thành phần hợp thành có thể phát sinh bởi sự tương tác giữa các thành phần trong nó.

Có các kiểu giao diện khác nhau giữa các thành phần chương trình, kết quả là có những lỗi giao diện khác nhau có thể xảy ra:

1. Giao diện dạng tham số: giao diện là dữ liệu hoặc đôi khi là chức năng được chuyển từ thành phần này sang thành phần khác.

2. Giao diện bộ nhớ được chia sẻ: là những giao diện mà các khối bộ nhớ được chia sẻ giữa các thành phần. Dữ liệu được đặt trong bộ nhớ bởi một hệ thống con và được đưa ra từ những hệ thống con khác.

3. Giao diện thủ tục: là những giao diện mà một thành phần ẩn trong nó một tập hợp các thủ tục có thể được gọi từ những thành phần khác. Các đối tượng và các thành phần có thể tái sử dụng có dạng giao diện này.

4. Giao diện chuyển thông điệp: những giao diện này thực hiện việc chuyển các thông điệp

từ thành phần này sang thành phần khác. Một thông điệp trả về sẽ bao gồm kết quả của việc thực thi dịch vụ. Một số hệ thống hướng đối tượng có giao diện dạng này, chẳng hạn như hệ thống client-server.

Lỗi trong giao diện thường rơi vào 3 loại sau:

1. Sử dụng sai giao diện: một thành phần gọi thành phần khác qua giao diện và gặp lỗi trong sử dụng giao diện. Kiểu lỗi này thường gặp khi truyền các tham số sai kiểu, sai thứ tự.

2. Hiểu sai giao diện: một thành phần gọi một thành phần khác thông qua giao diện nhưng lại hiểu sai về hoạt động của thành phần đó, gọi thành phần không có những hoạt động mong đợi. Ví dụ: khi tìm kiếm nhị phân có thể được gọi trong một mảng không được sắp xếp, do đó việc tìm kiếm sẽ thực hiện sai.

Các trường hợp kiểm thử

3. Lỗi thời gian: lỗi này xảy ra trong các hệ thống thời gian thực có sử dụng việc chia sẻ bộ nhớ hoặc giao diện truyền thông điệp. Việc sinh ra và xử lý dữ liệu đôi khi không đồng bộ (tốc độ xử lý khác nhau).

Kiểm thử để phát hiện những khiếm khuyết của giao diện là khó vì đôi khi những lỗi giao diện này chỉ sinh ra trong các trường hợp sử dụng bất thường. Một vấn đề nữa nảy sinh do sự tương tác giữa các lỗi trong các module hoặc các đối tượng khác nhau. Lỗi trong một đối tượng có thể chỉ được phát hiện khi một đối tượng khác hoạt động không đúng.

Các kỹ thuật kiểm thử tĩnh thường hiệu quả hơn về mặt chi phí trong việc khám phá ra các lỗi giao diện. Một kiểu ngôn ngữ lập trình mạnh như Java cho phép nhiều lỗi giao diện được phát hiện khi biên dịch. Trong khi đó các ngôn ngữ yếu hơn, chẳng hạn như C, sử dụng phân tích tĩnh có thể giúp phát hiện các lỗi giao diện. Kiểm tra chương trình có thể tập trung vào các giao diện thành phần và những câu hỏi về giao diện thực hiện trong quá trình thẩm tra.

7.4. THIẾT KẾ TRƯỜNG HỢP KIỂM THỬ (TEST CASE DESIGN)

Mục tiêu của tiến trình thiết kế các trường hợp kiểm thử là tạo ra một tập các trường hợp kiểm thử hiệu quả trong việc phát hiện ra những lỗi của chương trình và chỉ ra rằng hệ thống đáp ứng được yêu cầu.

Để thiết kế một trường hợp kiểm thử, ta cần lựa chọn một tính năng của hệ thống hoặc một thành phần đang kiểm thử, sau đó chọn một tập dữ liệu đầu vào để thực thi tính năng này.

Dưới đây là một số cách tiếp cận khác nhau được dùng để thiết kế các trường hợp kiểm thử:

1. Kiểm thử dựa trên yêu cầu: các trường hợp kiểm thử được thiết kế để kiểm tra các yêu

cầu của hệ thống. Kỹ thuật này thường được sử dụng trong các giai đoạn kiểm thử hệ thống. Với mỗi yêu cầu cần xác định các trường hợp kiểm thử để có thể chứng minh rằng các yêu cầu của hệ thống được đáp ứng.