2 Kết cấu luận văn
3.3 Thử nghiệm
Thử nghiệm hệ thống được tiến hành cả về mặt tính năng và mặt hoạt động. Việc thử nghiệm chức năng tất nhiên sẽ tập trung vào xác minh độ chính xác của hệ thống. Việc thử nghiệm được xây dựng theo các thông số. Mục đích của thử nghiệm hoạt động là để xác minh thông lượng thích hợp của hệ thống và nhận biết các điểm có khả năng vướng mắc và kém hiệu quả của hệ thống.
3.3.1 Thử nghiệm chức năng
Mục đích của thử nghiệm chức năng hệ thống là để chắc chắn rằng hệ thống hoạt động chính xác. Do đó, các phép thử nghiệm hệ thống được tiến hành tập trung vào thử nghiệm xuất phát từ quan điểm của người sử dụng. Các tiêu chí cho
việc thử nghiệm chức năng được nêu cụ thể tại phần 2.1 Các tiêu chí Thiết kếlà cơ
sở cho việc thử nghiệm chức năng.
Môi trường thử nghiệm chức năng được mô tả tại Hình 13. Để thực hiện mục tiêu thử nghiệm chức năng của hệ thống, một web dịch vụ thương mại được thiết lập. Việc thiết lập này cũng phục vụ mục đích thử nghiệm việc tích hợp hệ thống với một hệ thống mua bán qua web thực sự. Dịch vụ thương mại được xây dựng bằng cách lập trình một cặp Java servlet có khả năng giúp người sử dụng lựa chọn sản phẩn vào giỏ mua sắm và yêu cầu thanh toán. Khi người sử dụng thực hiện lệnh này, hệ thống thương mại sẽ đệ trình thanh toán tới Hệ thống Thanh toán Di động, người sử dụng ủy quyền thanh toán thông qua thiết bị đầu cuối WAP của mình. Sau khi ủy quyền, người sử dụng cho hệ thống thương mại biết về việc thanh toán đã được ủy quyền và hệ thống thương mại cam kết thực hiện thanh toán.
Hình 13 – Môi trường thử nghiệm chức năng.
Các tình huống thử nghiệm và kết quả
Phần dưới đây mô tả các tình huống thử nghiệm chức năng. Mô tả chỉ có tính bao quát – các phép thử nghiệm được giải thích cặn kẽ trong phần kết quả. Trong ba tình huống thử nghiệm dưới đây, mỗi tình huống dẫn tới một số tình huống thực tế được coi là các giá trị đầu vào khác nhau và các kết cấu đều được kiểm nghiệm. Các phép thử nghiệm và kết quả thử nghiệm được tóm tắt trong các bảng phía dưới mỗi tình huống.
Tình huống #1: Tạo một yêu cầu thanh toán
Hệ thống thương mại có thể tạo ra yêu cầu thành toán với tất cả các dữ liệu liên quan đến thanh toán, như mô tả tại phần 4.3.4.
Phép thử nghiệm Kết quả
Xuất trình một yêu cầu thanh toán theo Yêu cầu thanh toán được chấp nhận
Trạm duyệt Web và thiết bị đầu cuối WAP
The Oracle 8i Server
Hệ thống thanh toán di động Server bán hàng Môi trường
đúng format
Xuất trình một yêu cầu thanh toán với một nhận dạng đã tồn tại trong kho hồ sơ thanh toán
Yêu cầu thanh toán không được chấp nhận. Hệ thống báo có hai nhận dạng thanh toán đúp.
Xuất trình một yêu cầu thanh toán với dữ liệu thiếu
Nếu bất kỳ dữ liệu then chốt nào hoặc sự kết hợp nào do vậy mà bị thiếu, yêu cầu sẽ không được chấp nhận
Xuất trình một thanh toán mà tổng của các hạng mục không khớp với tổng thanh toán
Yêu cầu thanh toán không được chấp nhận. Hệ thống báo một yêu cầu thanh toán không đủ chất lượng.
Tình huống #2: Ủy quyền thanh toán
Người chi trả có thể kết nối với Hệ thống thanh toán di động để thực hiện ủy quyền thanh toán. Hệ thống thanh toán di động chấp nhận một chữ ký đúng định dạng và công nhận tính hợp lệ của nó.
Phép thử nghiệm Kết quả
Xuất trình một chữ ký thích hợp Ủy quyền được chấp nhận
Xuất trình một dữ liệu ngẫu nhiên được coi là chữ ký
Ủy quyền không được chấp nhận. Hệ thống báo chữ ký không hợp lệ, chứng nhận không hợp lệ và nội dung không hợp lệ.
Xuất trình một chữ ký dựa trên nội dung không phải hợp đồng thanh toán gốc
Ủy quyền không được chấp nhận. Hệ thống báo nội dung không hợp lệ. Xuất trình một chữ ký thích hợp.
(chứng nhận của người chi trả bị xóa khỏi phạm vi tin cậy)
Ủy quyền không được chấp nhận. Hệ thống báo chứng nhận không hợp lệ. Xuất trình một chữ ký có kết nối tới thư Ủy quyền được chấp nhận
mục LDAP, tại đó chứng nhận của người chi trả có thể được khôi phục Xuất trình một chứ ký với đường dẫn tới thư mục LDAP không hoạt động
Ủy quyền không được chấp nhận. Hệ thống báo chứng nhận không hợp lệ Xuất trình một chữ ký hợp lệ. (chứng
nhận của người chi trả được thêm vào CRL)
Ủy quyền không được chấp nhận. Hệ thống báo chứng nhận không hợp lệ Xuất trình một chữ ký cho một chỉ danh
thanh toán không tồn tại trong kho hồ sơ thanh toán
Ủy quyền không được chấp nhận. Hệ thống báo không tìm thấy hồ sơ thanh toán
Xuất trình một chữ ký hợp lệ sau khi hệ thống đang ở trạng thái tạm nghỉ trong 24h
Ủy quyền không được chấp nhận.
Tình huống #3 : Cam kết thực hiện thanh toán
Chỉ khi người chi trả ủy quyền giao dịch, hệ thống thương mại mới có thể cam kết thực hiện giao dịch. Cam kết thực hiện giao dịch sẽ dẫn đến việc đăng ký giao dịch thanh toán vào biên lai hoặc hệ thống quản lý tài khoản.
Phép thử nghiệm Kết quả
Cam kết một thanh toán đã được ủy quyền hợp lệ
Cam kết thanh toán thành công Cam kết một thanh toán không được ủy
quyền
Thanh toán không được cam kết. Hệ thống thanh toán di động thông báo trạng thái thanh toán không hợp lệ.
3.3.2 Thử nghiệm hoạt động
Các phép thử nghiệm hoạt động được chạy trong hệ thống để tạo nên một bức tranh về thông lượng có thể đạt được. Mục tiêu cuối cùng là đo kiểm thông lượng của hệ thống trên một môi trường phần cứng cụ thể. Phép đo này rất hữu ích khi lập kế hoạch triển khai hệ thống vào sử dụng.
Các phép thử nghiệm hoạt động được tiến hành tự động. Một tải trọng hợp lý và có thể điều chỉnh được của các giao dịch diễn ra đồng thời không thể thực hiện bằng tay. Và cũng không thể thiết lập một phép thử nghiệm ở những nơi mà các thiết bị WAP hiện tại tạo ra các giao dịch một cách tự động vào Hệ thống thanh toán di động, đoạn cuối WAP bị loại ra khỏi chuỗi. Bài thử nghiệm được tiến hành sử dụng một HTTP-khách hàng tùy chọn để tạo ra yêu cầu với hệ thống. Để đảm bảo độ chính xác, các phép thử nghiệm khách hàng được dùng để mô phỏng chức năng cổng WAP. Việc loại bỏ đầu cuối WAP và Cổng WAP không làm ảnh hưởng đến độ chính xác của các phép thử nghiệm – mục tiêu là thử nghiệm thông lượng của Hệ thống thanh toán di động, không phải là thử nghiệm đầu cuối WAP hay cổng WAP. Hơn nữa, không một xác minh tín dụng hoặc đăng ký giao dịch vào hệ thống biên lai thực tế nào được thực hiện trong phép thử nghiệm. Các bước thử nghiệm này bị loại bỏ, tạo điều kiện để chỉ thử nghiệm hoạt động của các yếu tố then chốt trong Hệ thống thanh toán di động. Đương nhiên, các phép thử nghiệm có thể được lặp lại với các giao diện đã sẵn sàng – từ đó người sử dụng có thể có một cái nhìn tổng quát tới tất cả hoạt động chung của hệ thống trong lắp đặt tại hiện trường. Tuy nhiên, đây không phải mục tiêu của chúng ta.
Việc thiết lập các bài thử nghiệm được minh họa ở hình 14. Trong môi trường hoạt động, các servlet engine có thể chạy trên nhiều máy khác nhau thay vì duy nhất PayerServer để tách biệt tốt hơn các dãy nguyên lý kinh doanh ra khỏi môi trường internet. Bằng cách này, tải trọng của máy chủ có thể được phân bổ
tới hai máy chủ thay vì một máy chủ chạy cả hai servlet và JSP và một máy chủ. Kết quả của việc sắp xếp được minh họa tại Hình 14, phép thử nghiệm sẽ cho thấy sự hoạt động kém hiệu quả so với môi trường sản xuất thật. Tuy nhiên, điều này không làm suy yếu đáng kể kết quả của các phép thử nghiệm. Kết quả của hoạt động thực tế chỉ tốt hơn một chút so với kết quả đo được trong phép thử.
Hình 14. Môi trường thử nghiệm hoạt động
Thay đổi tỷ lệ là một trong những nhân tố quan trọng nhất của một hệ thống khi số lượng người sử dụng và mật độ sử dụng không thể được xác định và ấn định từ trước. Việc tiếp cận đánh giá thay đổi tỷ lệ trong thực thi hệ thống được tiến hành để đánh giá hai nhân tố:
1. Hoạt động của thời gian phản hồi trung bình của hệ thống với tư cách là
một hàm của số lượng khách hàng đồng thời.
2. Hoạt động của thông lượng hệ thống với tư cách là một hàm của số lượng
khách hàng đồng thời.
Môi trường mạng
The Oracle 8i Server Nhập kiểm tra phát sinh từ
khách hàng
Vì mục đích của các phép thử là thiết lập sự am hiểu về hoạt động của hệ thống và giúp xác định tỷ lệ, số lượng người sử dụng đồng thời hoặc số lượng giao dịch được đặt làm phương sai. Tương đương như vậy, số lượng lần thử nghiệm được điều chỉnh theo mỗi tình huống thử nghiệm để thu được lỗi tương ứng chấp nhận được.
Các phép thử nghiệm được tiến hành với 1, 2, 5, 10, 20, 30, 40 và 50 khách hàng liên tiếp phát sinh yêu cầu đối với hệ thống. Số lượng tối đa 50 khách hàng đồng thời sử dụng hệ thống được chọn là trường hợp xấu nhất, với 100 000 người sử dụng hằng ngày và giả rằng việc phân bổ sử dụng trong ngày là không đồng đều. Mỗi một khách hàng thử nghiệm được đưa vào vòng quan sát số lượng lần yêu cầu hệ thống mỗi lượt. Yêu cầu đầu tiên là lấy ra hợp đồng thanh toán để ký kết và yêu cầu thứ hai là để xuất trình xác nhận chữ ký. Thời gian phản hồi của hệ thống được đo đạc và báo cáo riêng biệt đối với mỗi yêu cầu.
Phân tích thống kê được tiến hành trên kết quả thử nghiệm để xác định ưu điểm của hệ thống. Nếu không thể đạt được khoảng tin cậy 95% đối với mẫu chọn đầu tiên thì tập hợp mẫu sẽ được tăng lên. Phân phối Student T [15] được lựa chọn để đánh giá việc thực hiện khoảng tin cậy, bởi phương sai và phân phối của tập hợp là ẩn số. Kết quả ban đầu cho thấy phân phối không lệch. Dựa trên định lý giới hạn trung tâm, với một số lượng mẫu lớn thì trung bình của phân phối mẫu là phân phối chuẩn với trung bình bằng trung bình của tập hợp và độ lệch chuẩn bằng với độ lệch chuẩn của tập hợp chia cho căn bậc hai của số lượng mẫu [15]. Định lý giới hạn trung tâm cho phép can thiệp vào trung bình của bất kỳ phân phối nào khi kích thước mẫu đủ lớn. Bảng 9 minh hoạ quá trình lựa chọn phương sai và kích thước mẫu cuối cùng cho việc thử nghiệm.
Phép thử nghiệm Số lượng khách hàng liên tiếp Số lượng lần/khách hàng Kết quả mẫu tập hợp 1. 1 1000 1000 2. 2 1000 2000 3. 5 1000 5000 4. 10 1000 10000 5. 20 100 2000 6. 30 100 3000 7. 40 100 4000 8. 50 100 5000
Bảng 9- Việc lựa chọn phương sai cho thử nghiệm
Tóm tắt kết quả thử nghiệm được trình bày tại Bảng 10 Phép thử nghiệm Thời gian phản hồi trung bình (Mili giây?) Độ lệch chuẩn (Mili giây) Lỗi tương đương Yêu cầu thông lượng/giây 1 276 54 1.2% 3.6 2 297 60 0.9% 6.7 3 404 91 0.6% 12.4 4 564 144 0.5% 17.7 5 1077 262 1.1% 18.6
7 1988 362 0.6% 20.1
8 2613 616 0.7% 19.1
Bảng 10- Tóm tắt kết quả thử nghiệm
Dựa trên kết quả thử nghiệm được minh họa tại Bảng 10, ta có thể vẽ ra biểu đồ trong Hình 15 và Hình 16
Mối tƣơng quan giữa thời gian phản hồi và tải trọng
Trục hoành: Số lượng khách hàng đồng thời Trục tung: Thời gian phản hồi trung bình (Mili giây)
Hình 15 – Kết quả thử nghiệm – thời gian phản hồi
Trên dải số lượng khách hàng đồng thời từ 1 đến 50, hệ thống dường như biểu hiện một thời gian phản hồi trung bình có tính chất tuyến tính tăng dần. Độ dốc của đường cong trở nên dốc hơn trong khoảng 40 và 50 khách hàng đồng thời. Tuy nhiên, điều này là hoàn toàn tự nhiên – mọi hệ thống đều đạt được mức tải
trọng khi mà hoạt động được quan sát bởi một người sử dụng duy nhất bắt đầu giảm đột ngột. Trong hệ thống này, đặc điểm này dường như tồn tại ở đâu đó phía trên nhưng gần với mức 50 người sử dụng đồng thời.
Thông lƣợng của Hệ thống thanh toán di động
Trục hoành: Số lượng khách hàng đồng thời Trục tung: Số lượng yêu cầu/Giây
Hình 16 – Kết quả thử nghiệm – Thông lượng
Thông lượng của hệ thống cho thấy hoạt động có tính thay đổi tỷ lệ rất rõ rệt – thông lượng tăng nhanh cho tới mức 10 người sử dụng đồng thời và tiếp tục tăng cho tới mức 40 người. Ở mức 50 người sử dụng đồng thời, hệ thống đã đạt tới trạng thái bão hòa và thông lượng bắt đầu giảm dần. Rõ ràng là quan sát này phù hợp với quan sát được thực hiện trước đó – hệ thống bắt đầu tắc nghẽn tại đâu đó
lớn hơn mức 50 người sử dụng đồng thời một chút. Trước khoảng đó, sự gia tăng thời gian phản hồi cảm nhận bởi một người sử dụng duy nhất là hợp lý và tuyến tính với tư cách là một hàm tải trọng.
Cùng với việc tiến hành thử nghiệm hoạt động thực tế, một số thử nghiệm khác cũng được thực hiện để tạo lập một ý tưởng về cấu hình hợp lý cho hệ thống và các vướng mắc có thể gặp phải khi hoạt động. Tuy nhiên, các thử nghiệm này không được nghiên cứu kỹ lưỡng theo phương pháp thống kê như mô tả trên đây nên chúng chỉ có tính chất tham khảo. Dưới đây là một số nhận xét và các quan sát ghi nhận được.
Nhận xét về các thử nghiệm hoạt động của hệ thống
Trong quá trình thử nghiệm, việc giám sát hoạt động vận hành hệ thống được quan sát. Quan sát chung cho thấy, với một số lượng nhỏ khách hàng sử dụng đồng thời thì tải trọng đối với hệ thống CPU máy chủ là thấp. Với một khách hàng đồng thời tải trọng giữ ổn định ở mức 15%, với 5 khách hàng đồng thời, tải trọng tăng lên khoảng 65% và với 10 hoặc hơn khách hàng đồng thời thì tải trọng liên tục ở mức vượt quá 95%.
Thử nghiệm tại các kết nối cơ sở dữ liệu chung với các kích thước khác nhau cũng được tiến hành. Với 50 khách hàng đồng thời, khi kích thước liên kết cơ sở dữ liệu chung không bị khống chế, kết quả cho thấy rất rõ ràng rằng hệ thống chỉ có thể sử dụng tối đa 25 kết nối một lúc. Số lượng trung bình các kết nối đồng thời được sử dụng gần tới 10. Mặt khác, kết quả cũng cho thấy khi kích thước của cơ sở dữ liệu chung bị khống chế ở mức 5 liên kết với 10 khách hàng đồng thời thì tải trọng của hệ thống giảm từ (khoảng 90% trong trường hợp không bị khống chế) xuống còn 35%.
Ảnh hƣởng của việc truy cập cơ sở dữ liệu tới tổng thời gian phản hồi
Một giả thuyết cho rằng việc truy cập cơ sở dữ liệu có ảnh hưởng tiềm tàng tới thời gian phản hồi. Với mục đích thử nghiệm, một lớp giao diện cơ sở dữ liệu có chức năng giữ hồ sơ thanh toán trong bộ nhớ được thực hiện. Thử nghiệm với hệ thống được chạy với chỉ một khách hàng đồng thời. Kết quả cho thấy, thời gian phản hồi trung bình là 40Mili giây, là một bước cải tiến đột phá so với thời gian phản hồi 276 Mili giây thu được với việc thực hiện một cơ sở dữ liệu hợp lý.