Vai trò của kiểm thử tự động trong quy trình kiểm thử phần mềm

Nguyễn Thị Huệ Trường Đại học Công nghệ Luận văn Thạc sĩ ngành: Công nghệ phần mềm; Mã số: 60 48 10 Người hướng dẫn: TS. Đặng Văn Hưng

Vai trò của kiểm thử tự động trong quy trình

kiểm thử phần mềm

Nguyễn Thị Huệ

Trường Đại học Công nghệ Luận văn Thạc sĩ ngành: Công nghệ phần mềm; Mã số: 60 48 10

Người hướng dẫn: TS Đặng Văn Hưng

Năm bảo vệ: 2012

Abstract: Nghiên cứu về sự tự động hóa trong kiểm thử phần mềm gồm khái niệm,

lợi ích và cách thức thực hiện tự động hóa, chỉ ra một số công cụ kiểm thử phần mềm

và tập trung vào việc tìm hiểu công cụ kiểm thử TestComplete 9 - công cụ đang được

sử dụng khá phổ biến hiện nay Trình bày một phương pháp sử dụng công cụ kiểm thử

TestComplete trong kiểm chứng thiết kế phần mềm

Keywords: Công nghệ thông tin; Công nghệ phần mềm; Thiết kế phần mềm; Kiểm

thử phần mềm

Content

Chương 1 – GIỚI THIỆU 1.1 Đặt vấn đề

1.2 Nô ̣i dung nghiên cứu

Luận văn tập trung nghiên cứu về sự tự động hóa trong kiểm thử phần mềm gồm khái niệm, lợi ích và cách thức thực hiện tự động hóa, chỉ ra một số công cụ kiểm thử phần mềm

và tập trung vào việc tìm hiểu công cụ kiểm thử TestComplete 9 – công cụ đang được sử dụng khá phổ biến hiện nay Ngoài ra, luận văn có trình bày một phương pháp sử dụng công cụ kiểm thử TestComplete trong kiểm chứng thiết kế phần mềm

1.3 Cấu tru ́ c luâ ̣n văn

Phần còn lại của luận văn có cấu trúc như sau:

Chương 2: Quy trình kiểm thử phần mềm Chương này trình bày về mô hình phát triển phần mềm và quy trình kiểm thử trong các mô hình phát triển phần mềm

Chương 3: Các kỹ thuật kiểm thử phần mềm Chương này trình bày sơ qua về hai kỹ thuật kiểm thử: Hộp đen (Black box), Hộp trắng (White box) và việc lựa chọn kiểu kiểm thử

kiểm thử phần mềm Giới thiệu một số công cụ kiểm thử tự động và đi sâu vào việc tìm hiểu công cụ kiểm thử TestComplete 9 Trình bày phương pháp sử dụng công cụ kiểm thử này trong kiểm chứng thiết kế

Chương 2 – QUY TRÌNH KIỂM THỬ PHẦN MỀM

2.1 Quy trình phát triển phần mềm:

Quy trình phát triển phần mềm hay cò n go ̣i là vòng đời phát triển phần mềm là mô ̣t cấu trúc được dùng để phát triển một sản phẩm phần mềm Các thuật ngữ tương tự gồm vòng đời của phần mềm và quy trình phần mềm Nó được coi như một tập con của vòng đờ i phát triển

hê ̣ thống Có nhiều mô hình về quy trình phát triển phần mềm Mỗi mô hình mô tả cách tiếp

câ ̣n với mô ̣t loa ̣t các nhiê ̣m vu ̣ hay hoa ̣t đô ̣ng diễn ra trong suốt quy trình phần mềm

2.2 Quy trình kiểm thử phần mềm

Quy trình kiểm thử gồm các hoạt động sau:

− Kế hoạch kiểm thử (test planning)

− Thiết kế kiểm thử (test design)

− Triển khai kiểm thử (test implementation)

− Thực thi kiểm thử (test execution)

− Đánh giá kiểm thử (test evaluation)

Quy trình kiểm thử được mô tả trong hình vẽ dưới đây:

Hình 2.1: Quy trình kiểm thử phần mềm 2.3 Giai đoạn kiểm thư ̉ phần mềm trong vòng đời phát triển phần mềm

2.4 Các kỹ thuật kiểm thử phần mềm

2.4.1 Kiểm thử hộp trắng

2.4.2 Kiểm thư ̉ hô ̣p đen

2.4.3 Lư ̣a cho ̣n kiểu kiểm thử cho hê ̣ thống phần mềm

Chương 3 –TỰ ĐỘNG HÓA KIỂM THỬ PHẦN MỀM

3.1 Định nghĩa:

Tự động hóa kiểm thử phần mềm là thực hiện kiểm thử phần mềm bằng một chương trình đặc biệt với rất ít hoặc không có sự tương tác của con người.Việc thực hiện tự động phải đảm bảo được rằng không có hoạt động kiểm thử nào bị bỏ qua Nó giúp các kỹ sư kiểm thử (tester) không phải lặp đi lặp lại các bước nhàm chán

3.2 Mô hình chung của tự động hóa kiểm thử phần mềm

Tự động hóa kiểm thử phần mềm bao gồm một chuỗi các quá trình, các hoạt động, thao tác được quy tụ với nhau để thực hiện phần mềm cần kiểm thử và ghi lại kết quả kiểm thử Phần lớn các kiến trúc kiểm thử thường là những hệ thống mở bởi yêu cầu kiểm thử là một tổ chức xác định

Trong đó, các công cụ được dùng để tự động hóa quy trình kiểm thử trong mô hình kiểm thử thực hiện các chức năng:

Test Manager: quản lý việc thực hiện các kiểm thử của chương trình, theo dõi dữ liệu

kiểm thử, kết quả mong đợi và các chức năng, tiện ích của chương trình được kiểm thử

Test data generator: sinh dữ liệu kiểm thử cho chương trình

Oracle: tạo các phán đoán của kết quả mong đợi Nó có thể là các phiên bản chương

trình trước đó hoặc các hệ thống prototype Chú ý, ở đây không phải là cơ sở dư liệu Oracle

File comparator: Đối chiếu kết quả kiểm thử chương trình với kết quả kiểm thử trước

đó và ghi lại sự khác nhau vào tài liệu

Report generator: cung cấp các mẫu báo cáo và các tiện ích cho kết quả kiểm thử Dynamic analyzer: thêm mã cho chương trình để tính lượng thời gian mỗi lệnh được

thực hiện

Simulator: mô phỏng môi trường kiểm thử cho sản phẩm phần mềm

3.3 Công cụ kiểm thử tự động

Công cu ̣ kiểm thử phần mềm (Test Tool) trong lĩnh vực phát triển phần mềm là công cu ̣ giúp thực hiện viê ̣c phát triển phần mềm mô ̣t cách tự đô ̣ng Tuy nhiên không phải mo ̣i viê ̣c kiểm thử đều có thể tự đô ̣ng hóa , câu hỏi đă ̣t ra là trong điều kiê ̣n hay tình huống nào dùng công cụ kiểm thử là thích hợp ?

3.3.1 Lý do sử dụng công cụ kiểm thử

Viê ̣c dùng công cụ kiểm thử được xem xét trong mô ̣t số tình huống sau:

Không đủ tài nguyên:

Kiểm tra hồi quy:

Kiểm tra khả năng vâ ̣n hành phần mềm trong môi trường đă ̣c biê ̣t

3.3.2 Các bước thực hiện kiểm thử tự động

Giống như phá t triển phần mềm , để thành công trong kiểm thử tự động chúng ta nên thực hiê ̣n các bước cơ bản sau :

− Thu thập các đặc tả yêu cầu hoặc test case; lựa chọn những phần cần thực hiện kiểm thử

tự động

− Phân tích và thiết kế mô hình phát triển kiểm thử tự động

− Phát triển lệnh đặc tả cho kiểm thử tự động

− Kiểm tra và theo dõi lỗi trong đặc tả của kiểm thử tự động

3.3.3 Công cụ hỗ trợ trong quy trình kiểm thử phần mềm

Công cụ kiểm thử tự động phần mềm rất đa dạng và được sử dụng trong nhiều giai đoạn kiểm thử khác nhau Hình vẽ 3.2 chỉ ra các loại công cụ khác nhau và việc sử dụng chúng trong vòng đời phát triển phần mềm

Hình 3.2: Công cụ hỗ trợ trong quy trình kiểm thử phần mềm

3.4 Chuyên môn hóa con người

3.5 Chi phí trong kiểm thử tự động phần mềm

So với kiểm thử thủ công thì chi phí kiểm thử tự động là cao hơn, đặc biệt ở thời điểm bắt đầu của quy trình tự động hóa Từ công cụ kiểm thử cho đến các trang thiết bị cần thiết đều rất đắt đỏ Tuy nhiên, vốn đầu tư sẽ được hoàn lại sau khoảng thời gian dùng kiểm thử tự động

Không có sự so sánh rõ ràng giữa chi phí thực hiện các kiểm thử tự động và kiểm thử thủ công, ở đây ngụ ý về chi phí cho mỗi lần một ca kiểm thử được thực hiện

Tổng chi phí kiểm thử được xác định bằng tổng chi phí kiểm thử thủ công và tự động:

ở đây bao gồm các phí phát sinh khác

3.6 Một số hạn chế trong tự động hóa kiểm thử

Không thể thay thế kiểm thử thủ công

Kiểm thử thủ công có khả năng phát hiện lỗi tốt hơn kiểm thử tự động

Tự động hóa kiểm thử không cải thiện nhiều về tính hiệu quả

Tự động hóa kiểm thử có thể làm hạn chế sự phát triển phần mềm Các công cụ không có trí tưởng tượng

Chương 4 – TÌM HIỂU CÔNG CỤ TESTCOMPLETE 9

4.1 Loại phần mềm hỗ trợ

4.2 Hỗ trơ ̣ các loa ̣i kiểm thử

4.3 Các thành phần quan trọng trong TestComplete 9

4.4 Ngôn ngư ̃ sử du ̣ng viết Script

4.5 Sư ̉ du ̣ng TestComplete 9

Chọn loại kiểm thử

Dự án và các thành phần trong dự án kiểm thử

Giao diện người dùng (TestComplete User Interface)

Mô hình đối tượng kiểm thử (TestComplete Test Object Model)

Đặt điểm kiểm tra và lưu giữ liệu kiểm tra (Checkpoints and Stores)

4.6 Các bước tạo một dự án kiểm thử với TestComplete 9

Bao gồm các bước sau:

1 Tạo một dự án kiểm thử

2 Xác định ứng dụng cần kiểm thử

3 Hoàn thành việc tạo dự án kiểm thử

4 Tạo ca kiểm thử

5 Phân tích ca kiểm thử đã được ghi

6 Chạy ca kiểm thử được ghi

7 Phân tích kết quả kiểm thử

4.7 Ví dụ

Ứng dụng cần kiểm thử : Ứng dụng Patients Management hiển thi ̣ mô ̣t danh sách các

bê ̣nh nhân và có các tí nh năng đă ̣c biê ̣t như là thêm , sửa, xóa và xem thông tin chi tiết của

bê ̣nh nhân

Hình 4.7: Giao diện Patients Management

4.8 Đánh giá công cụ kiểm thử TestComplete 9

4.8.1 So với mô hình chung của kiểm thử tự động

TestComplete 9 cung cấp các tính năng đặc biệt để tự động hóa các thao tác kiểm thử, tạo ca kiểm thử, xác định dữ liệu kiểm thử, thực hiện kiểm thử và ghi lại kết quả Nó thuộc một trong các công cụ thực thi và đối chiếu kiểm thử (Test execution and comparison) cho phép các kiểm thử được thực thi tự động và kết quả kiểm thử được đối chiếu với kết quả mong đợi Công cụ này có thể sử dụng ở bất kỳ mức: kiểm thử đơn vị, tích hợp, hệ thống hoặc chấp nhận và thường được dùng trong kiểm thử hồi quy

Là công cụ Capture and Replay với yêu cầu kiểm thử trên chương trình đã hoạt động

Công cụ này được sử dụng ở giai đoạn Program being tested trong mô hình kiến trúc chung

của tự động hóa kiểm thử

Hình 4.33: TestComplete 9 trong mô hình chung của tự động hóa kiểm thử

4.8.2 So với công cụ kiểm thử khác

4.9.1 Mô ̣t số khái niê ̣m

Kiểm chứng thiết kế (Design checking)

Mô hình trừu tượng

4.9.2 Kiểm chư ́ ng thiết kế với TestComplete 9

Cơ sở của việc sử dụng kỹ thuật này

Việc thực hiện kiểm chứng thiết kế trong quá trình tạo ra sản phẩm phần mềm đặc biệt

là những phần mềm phức tạp sẽ giúp làm tăng hiệu quả kinh tế nhờ việc phát hiện lỗi sớm –

ngay từ bước thiết kế phần mềm sẽ rút ngắn thời gian và chi phí hoàn thành sản phẩm, đảm

bảo tính tin cậy, an toàn của hệ thống được làm ra Tuy nhiên, thiết kế thường không ở dạng

chương trình có thể cài đăt và chạy được Chính vì vậy, để có thể kiểm chứng thiết kế bằng

công cụ TestComplete 9 ta sẽ thực hiện việc chuyển thiết kế thành mô hình /chương trình

chạy được, sau đó sử dụng công cụ kiểm thử này để kiểm thử vét cạn chương trình đó

Các bước thực hiện:

- Bước 1: Chọn nhánh thiết kế cần kiểm chứng

- Bước 3: Tạo giả chương trình mô phỏng hoạt động của máy hữu hạn trạng thái trong bước 2 gồm:

o Tập hữu hạn trạng thái

o Các hàm chuyển trạng thái

- Bước 4: Vét cạn các kịch bản kiểm thử giả chương trình bằng ngôn ngữ script của TestComplete 9

- Bước 5: Sử dụng TestComplete 9 để kiểm thử tìm lỗi thiết kế

4.9.3 Ví dụ minh họa:

Mô tả bài toán

Mong muốn phát triển một hệ thống theo dõi điện tim đồ (ECG) thông qua thiết bị điện thoại thông minh để chúng ta có thể yêu cầu và ghi lại những thông tin liên quan về nhịp tim

và biết được nguyên nhân tại sao khi ta thấy có dấu hiệu loạn nhịp tim xảy ra

Các thành phần cơ bản của hệ thống:

- Một thiết bị không dây, một mô đun để lưu trữ và thu thập thông tin

- Một thuật toán kiểm tra nhịp tim theo thời gian thực hiệu quả

- Một hệ thống tương tác có qui tắc (Sự kiện – Điều kiện – Giải pháp)

- Một hệ thống giao diện người dùng đơn giản giúp ta có thể yêu cầu bổ sung thêm thông tin từ người dùng

Phân tích bài toán

Các thành phần của hệ thống

- Hệ thống này sử dụng Bluetooth như một kênh không dây để nhận tín hiệu ECG

và chuyển thành tín hiệu nhịp tim đập ghi nhận được đồng thời ghi lại các thông tin liên quan để giúp cho việc phân tích sau này tốt hơn

- Hệ thống cũng sẽ theo dõi biến thiên của nhịp tim từ tín hiệu ECG và dựa vào đó

để tìm ra những thay đổi trong tần số nhịp tim liên quan đến hoạt động hàng ngày của người dùng Những tần số khác nhau phụ thuộc vào các hoạt động khác nhau

sẽ được ghi lại dưới những nhãn (label, subject)như: Làm việc, chơi thể thao, đọc

báo, xem phim, …

Hình 4.34: Nền tảng kiến trúc của hệ thống

Hình 4.36 chỉ ra những thành phần cơ bản của hệ thống trên thực tế Ta có thể chia hệ

thống thành 3 phần chính là: Truyền dữ liệu, thu nhận tín hiệu và xử lý tín hiệu (dựa trên

thông tin ngữ cảnh sử dụng quy tắc E-C-A)

Trong phạm vi nghiên cứu chúng ta sẽ không sử dụng một thiết bị đo ECG thực, thay vào đó là một thiết bị mô phỏng để đọc dữ liệu ECG từ tệp tin và gửi đến thiết bị cầm tay (PDA) thông qua thiết bị thu phát Bluetooth của máy tính cá nhân (PC) Tổng quan của hệ thống như hình 4.37

cho mức tiếp theo (tương tác sự kiện nhịp sinh bởi thuật toán kiểm tra nhịp), trong đó chúng

ta sẽ làm một chuỗi các phân tích của các sự kiện, và qua đó đánh giá các điều kiện và yêu

cầu thông tin ngữ cảnh tương ứng với hoạt động hiện tại của người dùng (ADL: Active Daily

Living), sau khi có đầy đủ thông tin hệ thống lưu trữ ngữ cảnh sẽ thực thi những hành động

tương ứng với tình trạng hiện tại của nhịp tim bệnh nhân

Thiết kế hệ thống

Với mục đích là một ví dụ phục vụ cho việc kiểm thử tự động, chúng ta sẽ chỉ xét đến giao thức lý thuyết của hệ thống SAECA viết tắt của Tín hiệu (Signal) – Thuật toán (Algorithm) – ECA

Khi một tín hiệu thu nhận được, thuật toán tương ứng sẽ xử lý dữ liệu đến và truyền kết quả tính toán được vào cho ECA để đưa ra quyết định hoặc nhận những hành động tương ứng với tình huống hiện tại

− Pha 1: Gửi thông tin

Trước khi dữ liệu ECG được truyền đi, nó sẽ được chia ra và chuyển thành dạng

“số nguyên” Để tăng cường độ chính xác của dữ liệu, hệ thống sẽ kết hợp ID của bệnh nhân, tần suất lấy mẫu và số mẫu với dữ liệu ECG như sau:

Hình 4.37: Phân tích dữ liệu ECG và chèn thêm thông tin của mẫu

− Pha 2: Nhận và xử lý dữ liệu:

Khi nhận được dữ liệu ECG đến hệ thống sẽ tạo ra một mẫu rỗng để lưu trữ thông tin đến Hệ thống luôn biết trước thông tin người dùng (do người dùng nhập vào)

bệnh nhân, hệ thống sẽ phân tích để lấy ra mã số của mẫu và dữ liệu ECG Dữ liệu ECG sẽ được lưu trữ trong tệp tin và sẽ được phân tích bởi thuật toán

Hình 4.38: Sơ đồ xử lý dữ liệu ECG

Chú ý: Sai lầm của mô hình này nằm ở chỗ: nó đã không tính đến tần suất lấy mẫu mà

chỉ sử dụng ID của bệnh nhân, do đó có thể xảy ra trường hợp tràn bộ nhớ của hệ thống! Bởi rất có thể, trong trường hợp lỗi, bộ phận thu nhận sẽ gửi lặp hoặc gửi liên tục các mẫu! Đây

cũng chính là lỗi mô hình chúng ta cần tìm ra thông qua vét cạn và thực hiện stress test bằng TestComplete 9!

Hình 4.39: Mô hình trạng thái của hệ thống

Hình 4.40: Mô hình trạng thái của module lưu trữ dữ liệu

Xây dựng giả chương trình

Giả chương trình được mô phỏng bằng ứng dụng web viết trên nền ASP NET MVC 4.0

ngôn ngữ C# chạy trên máy chủ ứng dụng web IIS 8.0

Hình 4.41: Ứng dụng mô phỏng trên máy chủ IIS

Hình 4.45: Giao diện chương trình khách Kiểm thử vét cạn bằng TestComplete 9

Dựa trên bộ thông tin đầu vào (PatientID, SampleRate, ECGData) vả các trạng thái có

thể ta xây dựng vét cạn được tập ca kiểm thử sau (được chia thành 3 nhóm chính):

− Trường hợp 1: Mã bệnh nhân đúng, tần suất chuẩn, dữ liệu thay đổi (từ thấp nhất

(40) đến cao nhất (200)) gồm 4 ca kiểm thử

− Trường hợp 2: Mã bệnh nhân không chính xác, tần suất chuẩn, dữ liệu thay đổi (từ

thấp nhất (40) đến cao nhất (200)) gồm 4 ca kiểm thử

− Trường hợp 3: Mã bệnh nhân đúng, tần suất cực tiểu (0), dữ liệu thay đổi (từ thấp

nhất (40) đến cao nhất (200)) gồm 4 ca kiểm thử

Với mỗi ca kiểm thử, ta sử dụng TestComplete để nhập trước kết quả mong đợi

(expected result) sau đó tiến hành chạy tự động