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

Chia sẻ: Phạm Huy | Ngày: | Loại File: PDF | Số trang:18

Thêm vào BST

Báo xấu

167
lượt xem 26
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Báo cáo "Vai trò của kiểm thử tự động trong quy trình kiểm thử phần mềm "

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ử cho hệ thống phần mềm. Chương 4: Tự động hóa trong kiểm thử phần mềm. Chương này trình bày về khái niệm, mô hình chung của tự động hóa kiểm thử, lợi ích và cách thức thực hiện tự động hóa trong
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 trình phát triể n phầ n mề m hay cò n go ̣i là vòng đời phát triể n phầ n mề m là mô ̣t cấ u trúc được dù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 phá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ô hinh mô tả cách tiế p ̀ câ ̣n với mô ̣t loa ̣t các nhiê ̣m vu ̣ hay hoa ̣t đô ̣ng diễn ra trong suố t quy trì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: 2
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 phá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. Hình 3.1: Mô hình chung của tự động hóa kiểm thử 3
Trong đó, các công cụ được dù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 linh vực phát triể n phầ n mề m là công cu ̣ ) ̃ giúp thực hiện viê ̣c phát triể n phầ n mề m mô ̣t cách tự đô ̣ng . Tuy nhiên không phải mo ̣i viê ̣c kiể m thử đề u có thể tự đô ̣ng hóa , câu hỏi đă ̣t ra là trong điề u kiê ̣n hay tình huố ng nào dù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 dùng công cụ kiểm thử đươ ̣c xem xét trong mô ̣t số tinh huố ng sau: ̀ Không đủ tài nguyên: Kiể m tra hồ i quy: Kiể m tra khả năng vâ ̣n hà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ư phá 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 các bước cơ bả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. 4
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 dù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. 5
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 6
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ơ ̣ các loa ̣i kiể m thử 4.3 Các thành phần quan trọng trong TestComplete 9 4.4 Ngôn ngữ sử du ̣ng viế t Script 4.5 Sử du ̣ng TestComplete 9 Chọ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 và 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 sách các bê ̣nh nhân và có các tí nh năng đă ̣c biê ̣t như là thêm , sửa, xóa và xem thông tin chi tiết của bê ̣nh nhân . 7
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 dù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ử 8
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ố khái niêm ̣ Kiể m chưng thiế t kế (Design checking) ́ Mô hinh 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 2: Chuyển thiết kế sang mô hình trừu tượng (chẳng hạn dưới dạng máy hữu hạn trạng thái) 9
- 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 họ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 dùng đơn giản giúp ta có thể yêu cầu bổ sung thêm thông tin từ người dù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 dù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, … 10
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. Hình 4.35: Tổng quan về hệ thống Khi những tín hiệu ECG được gửi đến PDA, chúng sẽ được phân tích bởi thuật toán kiểm tra nhịp ECG. Sau khi một nhịp được kiểm tra, chúng ta coi đó như là 1 tín hiệu đầu vào 11
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 dù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 dùng (do người dùng nhập vào) bao gồm: ID của bệnh nhân. Nếu kết quả phân tích được trùng với thông tin 12
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 13
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 Chúng ta cũng tạo thêm một chương trình client để mô phỏng việc thu nhận và gửi dữ liệu đến server. 14
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 Phân tích kết quả Có 01 ca kiểm thử của trường hợp 3 thất bại có tập trạng thái như sau: 15
- Mã bệnh nhân đúng - Tần suất cực tiểu - Tập dữ liệu gồm 3 mẫu ở 3 trạng thái (thấp nhất, trung bình, cao nhất) Hình 4.46: Kết quả mong đợi xây dựng trước Hình 4.47: Kết quả chạy thực tế bằng TestComplete 9 16
Hình 4.48: Kết quả chạy kiểm thử của TestComplete 9 Có tập trạng thái, chúng ta tiến hành lần ngược (debug) trên giả chương trình và phát hiện lỗi hệ thống tại thời điểm kiểm tra và lưu trữ dữ liệu. ́ Chương 5 – KÊT LUẬN Kiểm thử phần mềm, một nội dung nghiên cứu được triển khai từ rất sớm và không phải là mới mẻ đối với thế giới, nhưng luôn là vấn đề cấp thiết cho việc nâng cao chất lượng phần mềm. Trong luận văn này, tác giả đã trình bày tổng quan về quy trình kiểm thử phần mềm, đi sâu vào nghiên cứu tự động hóa kiểm thử phần mềm và nghiên cứu công cụ kiểm thử TestComplete 9 – một công cụ kiểm thử khá phổ biến hiện nay. Luận văn cũng trình bày cách tiếp cận áp dụng công cụ kiểm thử vào việc iểm thử thiết kế mà cụ thể ở đây là công cụ kiểm thử TestComplete 9. Dùng kỹ thuật trừu tượng hóa, biến đổi thiết kế thành mô hình có thể tiến hành để kiểm thử bằng công cụ kiểm thử nhằm phát hiện lỗi ở giai đoạn sớm hơn. Hướng phát triển tiếp theo của luận văn là nghiên cứu một ngôn ngữ mô hình phù hợp, từ đó kết hợp với nghiên cứu về công cụ sinh giả chương trình tự động và thực hiện kiểm thử vét cạn bằng công cụ TestComplete cho giả chương trình đó. References Tiếng Việt 17
1. Nguyễn Xuân Huy (1994), Công nghệ phần mềm, Đại học Tổng hợp Tp. Hồ Chí Minh. Tiếng Anh 2. Kanglin Li and Menqi Wu (2004), Effective Software Test Automation: Developing an Automated Software Testing Tool, Sybex, San Francisco. 3. Mark Fewster and Dorothy Graham (1994), Software Test Automation Effective use of test execution tools, Copyright @ by ACM Press, Great Britain. 4. Myers and Glenford (1979), The Art of Software Testing, Willey, New York. 5. Pettichord and Bret (1996), Success with test automation, in Proceedings of the Ninth International Quality Week, Sofware Research, San Francisco, California, Available at http://www.io.com/~waznio/succpap.htm. 6. Ron Patton (2005), Software Testing, Sams Publishing, the United States of America. 7. http://smartbear.com/support. 18