Chƣơng 4– Tìm hiểu công cụ TestComplete
4.9.3 Ví dụ minh họa:
Mô tả bài toán
Một trong những mục tiêu quan trọng nhất trong quy trình chăm sóc sức khỏe đó là người bệnh luôn được biết về tình trạng sức khỏe của mình và được tư vấn bởi các chuyên gia y tế bất cứ khi nào họ cần và ở bất cứ nơi đâu. Một thiết bị cầm tay tích hợp là sự khởi đầu cho một hệ thống như thế. Một điểm nhấn quan trọng liên quan đến mục tiêu này là thu nhận thông tin sức khỏe sớm để đưa ra được những biện pháp phòng ngừa.
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ư:
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.
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 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. Hình 4.37 minh họa luồng làm việc của hệ thống SAECA:
Hình 4.36: Lược đồ tuần tự trong UML của giao thức thiết kế - SAECA
− 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) bao gồm: ID của bệnh nhân. Nếu kết quả phân tích được trùng với thông tin 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.
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.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.42: Giao diện chạy thử ứng dụng
Hình 4.43: Mã nguồn ứng dụng mô phỏng
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.
Hình 4.44: Mã nguồ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:
- 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.47: Kết quả chạy thực tế bằng TestComplete 9
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.
–
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. Dù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 phù 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 đó.
Tiếng Việt
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.