.Cài đặt, triển khai hệ thống

3.2 .Phân tích và đánh giá hệ thống

3.2.3 .Cài đặt, triển khai hệ thống

3.2.3.2. Mô hình triển khai hệ thống

Sử dụng chung SQL server để cấu hình testcase và Web service. Mỗi tester có kết nối để test đồng thời nhiều Web service.

Hình 3.15. Mô hình triển khai

3.2.3.3. Phần mềm

- Cài đặt SQL Server trên máy chủ dữ liệu

- Cài đặt .NET và phần mềm test trên máy cá nhân

3.2.3.4. Phần cứng

1 máy chủ để lưu cơ sở dữ liệu testcase và Web service. - Các máy cá nhân dành cho tester

- Các máy chủ cài đặt Web service cần test.

3.2.4. Phân tích kết quả

Dựa vào bước phân tích và xây dựng công cụ ở trên tôi đã thử nghiệm với một số Web service như: Web service cộng trừ, Web service view thông tin… và cho kết quả chính xác. Hiện tại tôi đã áp dụng thực tế ở Trung tâm phần mềm viễn thông Viettel với các Web service đơn giản như: Kiểm tra thông tin thuê bao, Lấy danh sách các gói dịch vụ thuê bao được hưởng khuyến mãi. Dưới đây sẽ trình bày chi tiết về bài toán Kiểm tra thông tin thuê bao.

3.2.4.1. Yêu cầu bài toán

Hiện tại ở Viettel đầu vào của các hệ thống là số điện thoại của khách hàng. Tuy nhiên thì hệ thống chỉ đáp ứng cho các số thuê bao đang hoạt động của Viettel hoặc là chỉ đáp ứng với một số thuê bao có thỏa mãn các điều kiện đặc biệt về gói cước, thời gian kích hoạt... Hiện tại ở Viettel thì hầu hết các thông tin được kiểm tra đều được giao tiếp qua Web service. Để đảm bảo các hệ thống có đầu vào chính xác thì yêu cầu websevie phải trả về kết quả chính xác và tin cậy. Việc kiểm thử Web service trên được thực hiện qua công cụ Soap UI với đầu vào là kịch bản kiểm thử được tạo bởi nhân viên kiểm thử dựa trên tài liệu giải pháp và link Web service do đội phát triển cung cấp. Chính vì vậy bài toán khi xây dựng sẽ phải đáp ứng cho phép nhân viên kiểm thử tạo kịch bản kiểm thử dựa vào tài liệu giải pháp cho sẵn và các tham số WS được lấy ra để thực hiện kiểm thử với WS đó. Trong quá trình kiểm thử có thể thay đổi được các case trong kịch bản cũng như là link Web service. Sau khi thực hiện xong hệ thống sẽ phải đáp ứng cho phép nhân viên kiểm thử kết xuất kết quả.

3.2.4.2. Giải pháp thực hiện

Từ những yêu cầu trên của bài toán và để thống nhất việc thực hiện thì hệ thống xây dựng định dạng mẫu cho bộ testcase, bộ testcase sẽ được nhập theo file chuẩn.

Người dùng có thể lấy file testcase mẫu sau khi nhập link Web service, mỗi Web service có một file mẫu riêng. Sau khi thực hiện gọi Web service, kết quả đầu ra thực tế sẽ được so sánh với đầu ra mong muốn trong kịch bản và hiển thị kết test trên màn hình. Các luồng xử lý chính:

 Luồng export file mẫu testcase Web service  Luồng import và xử lý gọi Web service  Luồng export kết quả ra file excel

 Luồng tạo testcase tự động theo cấu hình Chi tiết về giải pháp thực hiện như sau:

Đầu vào:

Link ws

File kịch bản kiểm thử cần test: File kịch bản bao gồm các trường: Tên hàm Web service, Tham số đầu vào, cách nhau bởi dấu |, User, Password, Msisdn

Tham số đầu ra mong muốn, cách nhau bởi dấu |:  Error_code: Mã lỗi web service trả về

 Status: Trạng thái hoạt động của thuê bao (1- chưa active, 2 – đang hoạt động, 3- hủy)

 Act_status: Trạng thái (00- hoạt động 2 chiều, 01,10- chặn 1 chiều, 11 chặn 2 chiều)

 Product_code: Mã gói cước của thuê bao  Description: Mô tả

Mức độ quan trọng của Testcase:  Important

 Not important  Mô tả về testcase

Đầu ra: Kịch bản sau khi test xong toàn bộ các case, có thêm các trường so với

file đầu vào:

Tham số đầu ra thực tế

 Luồng export file testcase mẫu

Từ link Web service nhập vào, nếu link hợp lệ, hệ thống lấy thông tin mô tả về Web service bao gồm:

- Danh sách hàm của Web service - Tham số đầu vào: tên, kiểu dữ liệu - Tham số đầu ra: tên, kiểu dữ liệu

Sau đó xuất ra file excel gồm các trường: - ID: tự động tăng

- Method: tên hàm xử lý

- Input: tham số đầu vào, định dạng: tên_tham_số=kiểu_dữ_liệu. Nếu có nhiều tham số cách nhau bởi ký tự |

- Output_results: để trống

- Output_desirable: kết quả tham số ra, định dạng: tên_tham_số=kiểu_dữ_liệu. Nếu có nhiều tham số cách nhau bởi ký tự |

- Results: để trống

- Level: để trống (người dùng nhập) - Description: để trống (người dùng nhập)  Luồng tạo testcase tự động theo cấu hình

Từ cấu hình kiểu dữ liệu các tham số đầu vào của web service, hệ thống thực hiện tạo testcase bằng cách: thay đổi giá trị từng tham số, giữ nguyên các tham số còn lại, sau đó truyền các bộ giá trị tham số vào testcase mẫu.

 Luồng import và xử lý

Bước 1: Nhập link WS Chọn link Web service trong danh sách. Các Web service cấu hình trong bảng WEBSERVICE của database.

Bước 2: Import file kịch bản tương ứng Đúng lưu vào bảng Information_input với các thông tin tương ứng trong file excel và Webservice_id tương ứng với id Web service được chọn

Sai thông báo sai định dạng file import Bước 3: Chọn các testcase cần thực hiện

test, duyệt các hàng theo id websevice đươc chọn. Thực hiện map các tham số đầu vào của Web service ở trường input và thực hiện gọi Web service

Chuyển bước 4

Bước 4: Lấy kết quả trả về của Web service tương ứng với các output trả về ở trường Output_Results và cập nhật vào trường Output_Results

Chuyển bước 5

Bước 5: So sánh tham số tương ứng ở cột Output_Results và kết quả mong muốn định nghĩa ở cột Output_Desirable

Nếu kết quả khớp nhau tất cả các trường trả về kết quả ở 2 cột thì cập nhật cột Results là PASS

Nếu kết quả khác 1 giá trị trả về ở 2 cột thì cập nhật cột Results là NOT PASS

Hệ thống thông báo thực hiện test thành công và hiển thị kết quả trên màn hình.

Kết thúc.

Bảng 3.2. Các bước xử lý

 Luồng export kết quả:

Hệ thống query dữ liệu bảng INFORMATION_INPUT theo Webservice_id để lấy thông tin và xuất kết quả ra file excel cho tester. Thứ tự testcase trong file import và file export phải giống nhau. Có thể dùng file kết quả export để làm đầu vào cho luồng import (hệ thống hỗ trợ xóa kết quả đã test trong cột result và output_desirable)

3.2.4.3. Triển khai thực hiện

3.2.4.3.1. Xây dựng Web service.

Trước tiên ta cần xây dựng Web service lấy thông tin thuê bao để thực hiện kiểm thử trên Web service này.

Thiết kế cơ sở dữ liệu của database CM (thông tin thuê bao): gồm database trả trước, database trả sau, database lưu thông tin đăng nhập. Cấu trúc hai database trả trước và

trả sau giống nhau, gồm hai bảng SUB_MB và SUB_HP. Database lưu thông tin đăng nhập gồm bảng WS_USER.

Bảng 3.3. Bảng thiết kế CSDL cho WS

Bảng lưu thông tin thuê bao di động - Tên bảng: SUB_MB

STT Tên cột Kiểu Mô tả

1 Sub_id Number(18,0) Mã thuê bao

2 Msisdn Nvarchar(50) Bắt buộc, lưu số thuê bao 3 Product_code Narchar(50) Mã gói cước của thuê bao 4 Status Number(2,0) Trạng thái thuê bao

5 Act_status Nvarchar(50) Trạng thái hoạt động của thuê bao 6 Fullname Nvarchar(50) Tên đầy đủ của thuê bao

7 Address Nvarchar(50) Địa chỉ của thuê bao Bảng lưu thông tin thuê bao homephone- Tên bảng: SUB_HP

STT Tên cột Kiểu Mô tả

1 Sub_id Number(18,0) Mã thuê bao

2 Msisdn Nvarchar(50) Bắt buộc, lưu số thuê bao 3 Product_code Narchar(50) Mã gói cước của thuê bao 4 Status Number(2,0) Trạng thái thuê bao

5 Act_status Nvarchar(50) Trạng thái hoạt động của thuê bao 6 Fullname Nvarchar(50) Tên đầy đủ của thuê bao

7 Address Nvarchar(50) Địa chỉ của thuê bao Bảng lưu thông tin đăng nhập - Tên bảng: WS_USER

STT Tên cột Kiểu Mô tả

1 Id Number(10,0) Khóa chính của bảng, tăng tự động

2 user Nvarchar(50) Tên đăng nhập

3 pass Nvarchar(50) Mật khẩu đăng nhập Xây dựng Web service lấy thông tin thuê bao:

Bước 1: kiểm tra thông tin đăng nhập trong bảng WS_USER: Câu lệnh:

SELECT * FROM ws_user where [user] = @user and [pass] = @pass

Nếu có dữ liệu  Bước 2

Nếu không: trả về error_code = -1, description = Loi dang nhap  kết thúc Bước 2: kiểm tra thông tin lần lượt trong sub_mb trả trước. Câu lệnh:

SELECT sub_id,msisdn,product_code,status,act_status FROM sub_mb where

msisdn = @msisdn

Nếu có dữ liệu  trả về thông tin: - error_code = 0 - sub_id - msisdn - product_code - status - act_status - sub_type = 1

- description = Tra truoc  kết thúc

Nếu không  Bước 3

Bước 3: kiểm tra thông tin lần lượt trong sub_hp trả trước. Câu lệnh:

SELECT sub_id,msisdn,product_code,status,act_status FROM sub_hp where

msisdn = @msisdn

Nếu có dữ liệu  trả về thông tin: - error_code = 0 - sub_id - msisdn - product_code - status - act_status

- sub_type = 0

- description = homephone  kết thúc

Nếu không  Bước 4

Bước 4: kiểm tra thông tin lần lượt trong sub_mb trả sau. Câu lệnh:

SELECT sub_id,msisdn,product_code,status,act_status FROM sub_mb where

msisdn = @msisdn

Nếu có dữ liệu  trả về thông tin: - error_code = 0 - sub_id - msisdn - product_code - status - act_status - sub_type = 2

- description = Tra sau  kết thúc

Nếu không  Bước5

SELECT sub_id,msisdn,product_code,status,act_status FROM sub_hp where

msisdn = @msisdn

Nếu có dữ liệu  trả về thông tin: - error_code = 0 - sub_id - msisdn - product_code - status - act_status - sub_type = 0 - description = homephone  kết thúc

Nếu không  trả về thông tin:

- Description = So khong ton tai - Error_code = -2  kết thúc Request: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getSubInfo xmlns="http://tempuri.org/"> <msisdn>string</msisdn>

<user>string</user> <pass>string</pass> </getSubInfo> </soap:Body> </soap:Envelope> Response: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body>

<error_code>string</error_code> <status>string</status>

<act_status>string</act_status> <product_code>string</product_code> <sub_type>string</sub_type>

<description>string</description> <msisdn>string</msisdn>

<sub_id>string</sub_id> </getSubInfoResult>

</getSubInfoResponse> </soap:Body>

</soap:Envelope>

3.2.4.3.2. Lập kịch bản test

Sử dụng công cụ và mô tả yêu cầu webservice, ta tạo testcase tự động như sau: - Msisdn: định dạng đúng là chuỗi số 10 hặc 11 ký tự, bắt đầu bằng 84. Như vậy

mẫu (regular expression) có dạng 84\d{9,10}, các giá trị gán lần lượt: giá trị mặc định (là số điện thoại hợp lệ, ví dụ 84979348036), giá trị thiếu độ dài (tạo ngẫu nhiên và cắt đi số ký tự min_value - 1), giá trị thừa độ dài (tạo ngẫu nhiên, ghép thêm ký tự ngẫu nhiên đến khi độ dài bằng max_value + 1), giá trị sai định dạng (chứa ký tự không phải số, ví dụ 84979348xxx), và các giá trị ngẫu nhiên đúng định dạng để test từng số thuê bao thuộc mỗi loại.

- User: định dạng đúng là kiểu chuỗi ký tự bất kỳ, độ dài lớn hơn 0, không có ký tự đặc biệt, mẫu regular expression có dạng [A-Za-z0-9!@#$]+, chỉ nhận giá trị trong default_value (ví dụ: nhung) và một giá trị ngẫu nhiên

- Pass: định dạng đúng là chuỗi gồm chữ cái hoa và thường, chữ số, ký tự đặc biệt, độ dài tối thiểu 8 ký tự. Tuy nhiên ta lấy mẫu regular expression đơn giản là [A-Za-z][A-Za-z0-9]+, chỉ nhận giá trị trong default_value (ví dụ: 123456a@) và một giá trị ngẫu nhiên

Sau khi loại bỏ các testcase dư thừa, ta xây dựng được kịch bản test như sau:

I D ME TH OD INPUT OUTPUT_ RESULTS OUTPUT_DESIRABLE RES UL TS LE VE L 1. getS ubIn fo user=dfW2y|pass= 123456a@|msisdn =84979348036 Error_code=-1|Description=loi xac thuc Imp orta nt

Bảng 3.4. Bảng thiết kế các trường hợp kiểm thử 3.2.4.3.3. Thực hiện test

Import file kịch bản vào công cụ và thực hiện test. Kết quả test sẽ hiển thị lên màn hình.

3.2.4.4. Kết quả đạt được

Hiện tại tôi đã xây dựng thành công công cụ thực hiện với mô tả trên của bài toán và thực hiện với Web service đã nêu cũng như một số Web service khác tương tự. Triển khai thành công công cụ ở công ty cho một số nhân viên kiểm thử thực hiện thử nghiệm thành công và đánh giá tốt.

3.2.4.5. Đánh giá kết quả

3.2.4.5.1. Đánh giá theo thực nghiệm:

Sau khi hoàn thành công cụ kiểm thử websevice trên tôi đã thực hiện triển khai tại Trung tâm phần mềm viễn thông Viettel để thực hiện một số Web service cơ bản.

Về đánh giá ban đầu là khá tốt so với việc kiểm thử thủ công bằng tay như hiện tại. Dưới đây là kết quả triển khai thực nghiệm và thực hiện so sánh về thời gian tạo kịch bản kiểm thử, thời gian thực hiện kiểm thử và kiểm thử lại với Web service lấy thông tin thuê bao tại Ban kiểm thử service thuộc BU BSS – Trung tâm phần mềm viễn thông Viettel.

TT Ngƣời thực hiện Số lƣợng testcase thực hiện Thời gian thực hiện thực tế Thời gian khi sử dụng công cụ Đánh giá 1 Đỗ Thị Tuyết 6 1MD 0.5MD Công cụ hỗ trợ khá tốt, tuy nhiên kết quả thực hiện còn phụ thuộc vào việc nhân viên phát triển fix lỗi 2 Nguyễn Thị Ngoan 6 2MD 0.8MD Tốt, dễ sử dụng 3 Lê Thị Huế 6 1.5MD 0.5MD Khá tốt 4 Lê Thị Hiền 6 1MD 0.5MD Khá tốt 5 Bùi Thị Khanh 6 1.2MD 0.5MD Khá tốt

Như vậy so với cách test hiện tại, công cụ rút ngắn thời gian kiểm thử xuống khoảng một nửa đối với trường hợp số lượng testcase được giữ nguyên. Nếu phát triển công cụ có khả năng hỗ trợ tạo testcase tự động thì số lượng testcase sẽ tăng lên, vì một số testcase khi thực hiện thủ công sẽ bỏ qua, ví dụ như trường hợp user sai nhưng chứa user đúng trong đó. Trường hợp này nhằm kiểm tra lỗi tiềm ẩn, nhất là với các nhân viên phát triển mới tuyển dụng.

3.2.4.5.2. Đánh giá theo bộ tiêu chí tại Viettel:

Tại Trung tâm Phần mềm viễn thông Viettel đang áp dụng bộ 21 tiêu chí để đánh giá sản phẩm phần mềm. Sau đây là một số tiêu chí cơ bản:

Về tính hiệu quả sử dụng: Công cụ được xây dựng dựa trên bài toán thực tế nên có

hiệu quả cao về mặt sử dụng. Công cụ có thể giúp giảm bớt thời gian thực hiện kiểm thử mà vẫn cho kết quả đúng đắn như kiểm thử thủ công thông thường.

Về tính đúng đắn, tin cậy: Một trong những yếu tố quyết định đến chất lượng của

Web service là tính tin cậy. Với công cụ trên sẽ thực hiện dựa trên bộ testcase được định lượng hóa nên đảm bảo sẽ phủ được hết các trường hợp cần kiểm thử. Chính vì vậy hệ thống đáp ứng được tính đúng đắn, tin cậy với đầu vào tin cậy.

Về tính đơn giản, dễ sử dụng: Hệ thống được xây dựng dựa trên mô phỏng công việc

của một nhân viên kiểm thử nên rất gần với các thao tác kiểm thử hiện tại đang thực hiện. Vì thế hệ thống rất dễ tiếp cận và dễ sử dụng.

Về tính dễ bảo trì, sửa chữa: Hệ thống được xây dựng trên mã nguồn mở. Cho phép

người vận hành có thể cập nhật, bổ sung các cấu hình cũng như mã nguồn để đảm bảo phục vụ người sử dụng một cách hoàn chỉnh nhất.

Về tính dễ vận hành, giám sát: Hệ thống được phân tích, thiết kế dựa trên nhu cầu

kiểm thử hiện tại nên dễ kiểm soát, vận hành và giám sát.

3.2.4.5.3. Đánh giá theo thời gian đáp ứng so với SoapUI [14][15]

.Bảo mật dịch vụ web

.Triển khai và tích hợp dịch vụ web