DI ĐỘNG VÀ PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT
3.4. Giải pháp AgileScrum tích hợp các kỹ thuật và phương pháp PMDLint, UniTest, +
3.4.2.4. Kết quả thực nghiệm và đánh giá
Thực nghiệm thứ nhất: thực hiện thực nghiệm ở 2 kỹ thuật được trình bày ở mục PMDlint và UniTest cho 7 ứng dụng mã nguồn từ kho ứng dụng FOSS (https://fossdroid.com/) Android và 2 ứng dụng (được đánh dấu * ở Bảng 3.15) nhóm nghiên cứu tự phát triển bởi các kỹ sư mới ra trường chưa có kinh nghiệm. Cách tiếp cận tương tự là (1) thu thập lỗi của từng ứng dụng trong khoảng thời gian 30 giờ liên tục đối với phiên bản ứng dụng gốc; (2) thu thập lỗi của từng ứng dụng trong khoảng thời gian 30 giờ chạy ứng dụng liên tục đối với phiên bản đã được chúng tôi chỉnh sửa thông qua việc áp dụng kỹ thuật PMDlint và UniTest, sử dụng lệnh logcat để xuất lỗi của ứng dụng. Kết quả cuối cùng thu được như Bảng 3.15 dưới đây, giá trị độ tin cậy ở giờ thứ 30:
Bảng 3.15. Kết quả thực hiện áp dụng kỹ thuật PMDlint và UniTest cho các dự án mã nguồn FOSS và dự án do nhóm nghiên cứu thực hiện.
Tên ứng Mô tả Độ tin Độ tin
dụng cậy (1) cậy (2)
Là một game ghi nhớ thứ tự các hình ảnh. Khi
Memory người chơi lật trúng 2 ơ có hình ảnh giống nhau sẽ 0.923 0.948 được tính điểm. Game có nhiều chế độ lựa chọn
Game
kích thước ma trận hình ảnh: 4x4, 5x5, 6x6 Student Là ứng dụng đơn giản tương tác với SQLite
Có khả năng thêm, xóa, sửa, xem danh sách các 0.907 0.926 Details
dòng dữ liệu nhập vào.
Ứng dụng hỗ trợ người bệnh với các chức năng:
Faster Ghi lại lịch sử bệnh tật, ghi lại lịch sử các toa thuốc, 0.944 0.951 hỗ trợ hẹn giờ uống thuốc.
Ứng dụng giúp người dùng note lại tất cả những
Shopping thứ mình cần mua trong quá trình đi mua sắm. Quản 0.933 0.961 List lý được số lượng cần mua và chia sẻ những mục
cần mua lên social network.
Ứng dụng nghe nhạc tiện dụng, có các danh mục
Music App bài hát, thay đổi theme ứng dụng phù hợp với sở 0.942 0.955 thích, tạo được album riêng cho người dùng.
Ứng dụng giúp người dùng hẹn giờ tập thể dục. Có
Healthily những động tác có sẵn để người dùng tập theo, 0.932 0.960 người dùng có thể cài đặt những động tác mình
mong muốn theo các khung giờ.
Note Ứng dụng Note giúp ghi chú những công việc cần 0.912 0.968 làm, hẹn giờ báo ghi chú, thông báo ghi chú đã đặt.
Tên ứng Mô tả Độ tin Độ tin
dụng cậy (1) cậy (2)
Location Ứng dụng quảng cáo theo vị trí, sử dụng bản đồ Google và định vị để bật các quảng cáo về các cửa based
hàng mua sắm, ăn uống khi người dùng đi vào gần 0.810 0.937 Advertising
khu vực đó; sử dụng cho các tuyến đường, khu vực System (*)
du lịch, mua sắm.
SOS Ứng dụng hỗ trợ gọi điện cấp cứu, tìm kiếm và xác
Application định vị trí khi gặp sự cố, gửi thơng tin cho người 0.783 0.952 (*) thân trong tình huống khẩn cấp
( là hai dự án do kỹ sư Việt nam mới ra trường thực hiện chưa có kinh nghiệm phát triển ứng
dụng thương mại.
Qua dữ liệu ở Bảng 3.15 cho thấy hiệu quả của việc thực hiện các kỹ thuật tối ưu mã nguồn, tái cấu trúc mã nguồn, phân tích mã nguồn, kiểm thử hộp trắng theo 2 kỹ thuật PMDlint và UniTest. Đối với 02 ứng dụng được đánh dấu (*) trong Bảng 3.15 cho thấy hiệu quả rõ rệt bởi các kỹ sư phần mềm chưa có kinh nghiệm thường mắc các lỗi về chuẩn viết mã (tăng từ 0.810 lên 0.937 đối với dự án Location based Advertising, từ 0.783 lên 0.952 đối với dự án SOS), về vấn đề tối ưu hóa mã nguồn cũng như kinh nghiệm thực hiện kiểm thử hộp trắng còn hạn chế.
Thực nghiệm thứ hai: áp dụng cho dự án đang phát triển ACMapp – ứng dụng quản lý sự kiện hội nghị khoa học. Trong thực nghiệm này, sau khi kết quả thử nghiệm của nhóm dự án, chúng tơi thực hiện quan sát và thu thập lỗi trong 59 giờ (tổng time interval), dữ liệu lỗi quan sát được như ở Bảng 3.16 đối với đội dự án A (bảng bên trái) đối với đội dự án B.
Bảng 3.16. Dữ liệu lỗi thu thập của dự án đội A và đội B
Khoảng thời Số lỗi được gian đo (time
phát hiện (faults) interval) -đội A 10 15 8 4 6 9 5 4 10 3 7 1 3 2 2 0 4 1 4 0
Khoảng thời Số lỗi được gian đo (time
phát hiện (faults) interval) -đội B 10 20 8 10 6 9 5 6 10 7 7 4 3 3 2 3 4 1 4 2
Trong đó, cột Time Interval là thời gian (giờ) quan sát và thu thập lỗi, cột faults là số lỗi quan sát được trong thời khoảng thời gian (time interval). Cụ thể, trong thời gian 10 giờ đầu tiên, đội A phát hiện được 15 lỗi, đội B là 20 lỗi; các lỗi này được loại bỏ và theo giả định đã được nêu ở mục 3, lỗi phát hiện được loại bỏ và khơng có lỗi mới được đưa vào; các lỗi là độc lập. Sử dụng SRATS2010 để tính tốn và ước lượng ra kết quả như sau:
Bảng 3.17 – Kết quả tính tốn và ước lượng độ tin cậy của dự án đội A so với đội B
Kết quả của
Kết quả của dự án đội
Các tham số/ giá trị đo dự án đội A B
Tổng số lỗi được phát hiện (Total Experienced Failures) 39 65 Thời gian phát hiện lỗi tối thiểu (Minimum Failure Time) 10 10 Thời gian phát hiện lỗi tối đa (Maximum Failure Time) 59 59 Thời gian phát hiện lỗi trung bình (Mean Failure Time) 22.6165 26.5018
Số lượng tham số (No. of Parameters) 2 2
Tham số 1 (Parameter 1 - MLE) 42.3471 82.9286
Tham số 2 (Parameter 2 – MLE) 0.0430 0.0260
Tổng số lỗi được kỳ vọng (Expected Total Faults) 42.3471 82.9286 Số lỗi chưa phát hiện được kỳ vọng (Expected Residual Faults) 3.3471 17.9286 Xác suất khơng có lỗi (Fault-Free Probability) 0.0352 1.6356E-8 Thời gian trung bình để thất bại có điều kiện (Conditional MTTF) 9.1060 2.2807 Thời gian trung bình tích tích lỹ cho thất bại (Cumulative MTTF) 1.5129 0.9077
Giá trị trung bình (Median) 5.0925 1.5187
Trong đó:
- Total Experienced Failures: tổng số lỗi khám phá được trong tổng thời gian tích lũy (maximum failure time)
- Minimum Failure Time: ở đây được xem là thời gian khởi tạo ban đầu để khám phá lỗi (time interval đầu tiên)
- Maximum Failure Time: là tổng thời gian khám phá lỗi được thu thập để đo lường (tổng time interval).
- Parameter 1 và 2: là tham số a, b ở cơng thức (7) và (8) được tính tốn theo phương pháp ước lượng hợp lý cực đại MLE, tham số 2 là tỷ lệ lỗi (failure) cho mỗi khoảng thời gian time interval.
- Tham số 1: là tổng số lỗi được phát hiện theo kỳ vọng (Expected Total Faults) theo tổng thời gian tích lũy.
- Expected Residual Faults: là số lỗi được ước tính cịn tồn tại trong sản phẩm - Fault-Free Probability: xác suất khơng xảy ra lỗi dược dự tính trong một khoảng
thời gian
- Conditional MTTF: là thời gian trung bình giữa hai thất bại có điều kiện
- Cumulative MTTF: là thời gian trung bình tích lũy giữa hai thất bại có điều kiện
Các đồ thị thể hiện kết quả tính tốn, đội dự án A và đội dự án B.
Hình 3.22. (a) Độ tin cậy của sản phẩm -đội A (b) Độ tin cậy của sản phẩm -đội B
Hình 3.23. (a) Số lượng lỗi tích lũy phát hiện theo thời gian -đội A và (b) đội B
Hình 3.23 (a) Tỷ lệ lỗi -đội A (b) Tỷ lệ lỗi -đội B
Qua số liệu ở Bảng 4 cho thấy xác suất khơng có lỗi (Fault-Free Probability ) của sản phẩm đội dự án A cao hơn sản phẩm của đội dự án B ( 0.0352 của sản phẩm đội dự án A so với 1.6356E-08 của đội dự án B), hay tỷ lệ lỗi của dự án A thấp hơn so với dự án đội B ở Hình 9 (a) và (b). Trong Bảng 4, các giá trị đo được đều cho thấy
kết quả của đội A tốt hơn so với đội B như số lỗi còn tồn tại trong sản phẩm (Expected Residual Faults), thời gian trung bình để thất bại có điều kiện ở sản phẩm đội A lớn hơn so với đội B. Dữ liệu được tính tốn theo mơ hình NHPP hàm mũ ở mục 3.1; hai tham số được ước tính theo phương pháp ước lượng hợp lý cực đại (MLE - Maximum Likelihood Estimation).
Đánh giá kết quả thực nghiệm: Từ những lý thuyết và kết quả thực nghiệm được trình bày trong phần 4 và 5, chúng tôi rút ra các nhận xét sau:
1) Các kĩ thuật lập trình tối ưu mã nguồn ảnh hưởng nhất định đến độ tin cậy của hệ thống.
2) Có thể mở rộng các tập luật cho việc tối ưu mã nguồn, tìm lỗi của mã nguồn cho nhiều mục đích khác nhau của dự án.
3) Việc đánh giá mức độ bao phủ mã nguồn và xác định lỗi cấu trúc, logic cũng như đánh giá khả năng chịu lỗi của một chương trình, của một phương thức (hay một hàm) khi kiểm thử hộp trắng là hoạt động rất quan trọng để đảm bảo chương trình hoạt động đúng và tin cậy.
4) Việc thực hiện các hoạt động kiểm thử sớm, phân tích và sinh kịch bản kiểm thử, trường hợp kiểm thử sớm giúp cho người phát triển định hướng việc lập trình, tạo ra mã nguồn chất lượng hơn. Đồng thời giúp cho các kỹ sư phát triển có dữ liệu thực hiện kiểm thử tự động từ khâu kiểm thử đơn vị và các khâu kiểm thử hệ thống, kiểm thử chấp nhận được nhanh chóng, hiệu quả; tăng mức độ bao phủ kiểm thử và đương nhiên giúp nâng cao chất lượng và độ tin cậy cho dự án.
3.5. Kết chương
Trong Chương 3, luận án đã trình bày (1) kỹ thuật sinh trường hợp kiểm thử và dữ liệu kiểm thử tự động dựa trên User story và Acceptance criteria-AgileUATM; (2) Phương pháp đồ thị hóa kỹ thuật kiểm thử thăm dò trong CDT-One2Explore và phương pháp ứng dụng học máy trong kiểm thử hướng ngữ cảnh cho ứng dụng web di động- Shinobi và (3) đề xuất giải pháp tích hợp các kỹ thuật và phương pháp PMDLint, UniTest, AgileUATM, One2Explore và Shinobi vào qui trình Agile Scrum trong phát triển ứng dụng di động. Các nội dung trình bày trong chương 3 thể hiện
đóng góp khoa học thứ hai của luận án: Xây dựng và thử nghiệm các kỹ thuật kiểm thử cho phát triển ứng dụng di động: sinh ca kiểm thử và dữ liệu kiểm thử tự động dựa trên câu chuyện người dùng và tiêu chí chấp nhận; sử dụng phương pháp đồ hóa hoạt động kiểm thử thăm dị (Graph exploratory), phương pháp heuristics và học máy trong kiểm thử hướng ngữ cảnh. Đề xuất giải pháp AgileScrum+ tích hợp các kỹ thuật trong mơi trường phát triển Agile Scrum.
Trình bày trong Chương 3 có 4 bài báo liên quan: CT4, CT5, CT6, CT7, trong đó có 02 cơng trình Hội nghị Scopus và 01 Tạp chí ISI (Q3).
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN