DI ĐỘNG VÀ PHƯƠNG PHÁP PHÁT TRIỂN LINH HOẠT
3.2. Kỹ thuật sinh ca kiểm thử và dữ liệu dựa trên yêu cầu người dùng và điều kiện chấp
3.2.2.3. Phân tích dữ liệu thực nghiệm so sánh hiệu quả giải pháp AgileUATM
Dự án ACM App được thực hiện bởi hai nhóm độc lập, mỗi nhóm gồm 4 kỹ sư dưới 1 năm kinh nghiệm. Nhóm A áp dụng phương pháp được đề xuất trong nghiên cứu này và nhóm B thực hiện theo phương pháp truyền thống. Dự án được phát triển theo qui trình Scrum trong 14 tuần (4 sprints). Ngồi ra, tác giả luận án cũng gửi yêu cầu (Product backlog, user stories và acceptance criteria) cho 05 kỹ sư có ít hơn một năm kinh nghiệm, 04 kỹ sư với hơn 3 năm kinh nghiệm và 03 kỹ sư có hơn 5 năm kinh nghiệm trong lĩnh vực kiểm thử thuộc hai công ty phần mềm khác nhau thực hiện xây dựng các trường hợp kiểm thử và dữ liệu kiểm thử theo phương pháp truyền thống, kết quả được thể hiện trong Bảng 3.9 như sau:
Bảng 3.9. Kết quả thực hiện theo phương pháp kiểm thử truyền thống
1) (2) (3) (4) (5) (6) (7) (8) (9)
5+ Tùy 24
3 15 12 phút 1 giờ 97% Cao thuộc
năm giờ
kỹ sư
3+ 4 16 32 phút 1.2 94% Cao Không 35 giờ
năm giờ
< 1 5 11 67 phút 1.8 87% Cần thêm Không 49 giờ
năm giờ thông tin
< 1 2 10 75 phút 2 giờ 85% Cần thêm Không 51 giờ
năm thông tin
(1) Số năm kinh nghiệm của kỹ sư kiểm thử (2) Số lượng kỹ sư kiểm thử
(3) Số test cases trung bình cho mỗi user story
(4) Thời gian trung bình để viết tất cả các test cases cho một user story (5) Thời gian trung bình để chuẩn bị dữ liệu kiểm thử cho mỗi US (6) Tỷ lệ bao phủ yêu cầu
(7) Mức độ thu nhận thông tin cho kiểm thử
(8) Các developer sử dụng kết quả cho giai đoạn Unit test
(9) Tổng thời gian cho việc chuẩn bị toàn bộ test case, test data cho tất cả các user stories.
Bảng 3.10. Kết quả thực hiện áp dụng giải pháp AgileUATM
(1) (2) (3) (4) (5) (6) (7) (8)
< 1 5 60 phút 2.3s 250 (khơng dùng 92% Có 19 giờ
năm heuristics)
< 1 5 60 phút 1.2s 122 (có heuristics) 90% Cả hai 19 giờ năm
(1) Số năm kinh nghiệm của tester (2) Số lượng tester
(3) Thời gian trung bình để đặc tả sang myDSL từ US và AC
(4) Thời gian trung bình để sinh test case và test data bởi cơng cụ AgileUATM (5) Trung bình số lượng test cases, test data được sinh ra cho mỗi US
(6) Mức độ bao phủ yêu cầu
(7) Developer sử dụng cho Unit test với Cucumber (BDD)
(8) Tổng thời gian cho việc chuẩn bị test case, test data cho tất cả các user stories
Nghiên cứu này tập trung vào yêu cầu sinh trường hợp kiểm thử và dữ liệu thử nghiệm cho kiểm thử chức năng. Lưu ý rằng cột (3) trong Bảng 3.10 cho thấy các kỹ sư đã được đào tạo để viết đặc tả myDSL như đề xuất trong nghiên cứu này. Giá trị “Có” trong cột (7) chỉ ra rằng kết quả sinh dữ liệu kiểm thử chỉ được sử dụng cho kiểm thử mức đơn vị trong khi đó “Cả hai” nghĩa là được sử dụng cho cả kiểm thử đơn vị, kiểm thử hướng dữ liệu và kiểm thử hồi qui.
Ngoài ra, trong luận án cũng tiến hành một thực nghiệm khác bằng cách mời bốn nhóm dự án khác nhau của sinh viên ngành kỹ thuật phần mềm năm cuối. Có hai đội
khơng có kinh nghiệm sử dụng AgileUATM (đội A1, A2 trong Bảng 3.11). Hai đội khác có bốn tháng kinh nghiệm quản lý dự án và sử dụng AgileUATM trong dự án của họ (nhóm B1, B2 trong Bảng 3.11). Tất cả bốn đội được đào tạo về khóa học phát triển phần mềm Agile Scrum. Kinh nghiệm và khả năng của từng thành viên ở cùng cấp độ (về kỹ năng lập trình, sử dụng kiểm thử đơn vị, kiểm thử thủ công, quen thuộc với môi trường phát triển IDE / IntelliJ / Android Studio). Bảng 3.11 là danh sách 4 dự án được mời thử nghiệm phương pháp nghiên cứu đề xuất, các dự án được thực hiện trong 12 tuần. Tác giả luận án trực tiếp cố vấn các dự án này để đảm bảo các đội tn theo quy trình.
Bảng 3.11. Danh sách các nhóm dự án được mời tham gia thực nghiệm giải pháp đề xuất của luận án
Đội Tên dự án Mô tả Số US.
A1 Swim Tracker Swim Tracker là ứng dụng adroid/ iOS trợ giúp các 19 App huấn luyện viên và học viên bơi lội có thể theo dõi
được thơng tin về thể lực, tim mạch và theo dõi quá trình bơi lội của mỗi học viên nhằm giúp cho người huấn luyện có được số liệu của từng người mà có phương pháp luyện tập phù hợp cũng như hỗ trợ lịch trình huấn luyện.
A2 SPORT TIME Sport Time là một ứng dụng dành cho người chơi thể 15 thao, giúp tìm kiếm người chơi thể thao, tìm địa điểm
luyện tập, thuê sân chơi hoặc phòng tập thể dục, và luyện tập, tạo sự kiện, trận đấu, nhà tổ chức giải đấu, ...
B1 Face Phần mềm hỗ trợ điểm danh qua nhận diện khuôn 17 Recognition mặt giúp tiết kiệm thời gian điểm danh theo cách
App for truyền thống, và hỗ trợ việc phát hiện đi học hộ, thi Attendance hộ. FRAM bao gồm ba ứng dụng di động khác nhau System cho giáo viên, học sinh và phụ huynh được cài đặt (FRAMS) trên điện thoại thông minh của họ để quản lý và thực
hiện quy trình tham dự theo thời gian thực.
B2 Location-based LBA cho phép các doanh nghiệp nhỏ thay đổi thông 16 Advertising điệp tiếp thị của họ dựa trên vị trí của người tiêu dùng
Apps for Smart mục tiêu. Bằng cách biết khách hàng mục tiêu ở đâu phone (LBA) và họ thường cư xử như thế nào, LBA có thể tập
trung vào thói quen của họ và cũng khuyến khích họ bằng những lời đề nghị và thơng điệp có ý nghĩa với họ, liên quan đến vị trí của họ. Nó sẽ là hình thức quảng cáo di động cá nhân tiện ích nhất.
Bảng 3.12. Kết quả thực nghiệm của phương pháp đề xuất AgileUATM(1) (2) (3) (4) (5) (6) (7) (8) (9) (1) (2) (3) (4) (5) (6) (7) (8) (9) A1 0 19 18 giờ 60 4275 92% Cao A2 0 15 15 giờ 45 3370 91% Cao B1 4 17 9 giờ 45 1505 94% X Rất cao B2 4 16 8 giờ 45 1250 88% X Rất cao
(1) Tên đội dự án thực hiện thử nghiệm
(2) Kinh nghiệm của kỹ sư kiểm thử và về qui trình Agile Scrum (months) (3) Số lượng User stories
(4) Tổng thời gian để đặc tả myDSL
(5) Tổng trung bình thời gian cho việc sinh test case và test data cho tất cả US (second) (6) Tổng số test case và test input được sinh ra
(7) Mức độ bao phủ yêu cầu của test case được sinh ra (8) Có sử dụng Unit test bằng BDD script
(9) Mức độ phát hiện lỗi
Dựa trên kết quả thực nghiệm cho tất cả các US của dự án cho thấy rằng với phương pháp đề xuất trong luận án, sự kết hợp của các cơng cụ hỗ trợ có thể giảm thời gian và nỗ lực tạo trường hợp thử nghiệm và tạo dữ liệu thử nghiệm của các kỹ sư kiểm thử (19 giờ so với 24 hoặc 35 giờ hoặc 51 giờ cho phương pháp truyền thống và giá trị trong cột 4 của Bảng 3.12). Trong Bảng 3.10, mặc dù các kỹ sư khơng có nhiều kinh nghiệm nhưng thực hiện theo phương pháp đề xuất, thời gian để tạo ra một trường hợp thử nghiệm và dữ liệu thử nghiệm ít hơn nhiều so với các kỹ sư có kinh nghiệm. Việc xây dựng các trường hợp thử nghiệm tốt với độ bao phủ cao sẽ phụ thuộc vào kinh nghiệm của kỹ sư kiểm thử. Những thách thức của phương pháp đề xuất là đặc tả myDSL. Đối với các kỹ sư có kinh nghiệm, sẽ mất ít thời gian hơn để đặc tả và áp dụng các phương pháp heuristics, điều này sẽ giúp tạo ra các trường hợp kiểm thử và dữ liệu kiểm thử chất lượng cao, phạm vi kiểm thử được bao phủ và giảm đáng kể cơng sức nỗ lực kiểm thử. Bên cạnh đó, các trường hợp thử nghiệm có thể bảo trì một cách hiệu quả.
Hai kỹ sư có ít hơn 1 năm kinh nghiệm trong đội B, những người có cùng trình độ với đội A (Bảng 3.10), nhưng kết quả khác nhau. Thời gian và nỗ lực để chuẩn bị các trường hợp kiểm thử và dữ liệu của đội B đã dành hơn 51 giờ trong khi đội A chỉ dành 19 giờ; độ bao phủ của trường hợp kiểm thử của đội A là hơn 90% so với 85% của đội B. Chất lượng của trường hợp kiểm thử của đội A tốt hơn so với đội B và tiến độ của đội B qua từng lần chạy nước rút là đúng thời gian ( thời gian của nhóm B tăng 15% trong tồn bộ thời gian của dự án) và tỷ lệ phát hiện khuyết tật cao hơn 20% so với nhóm B. Ngồi ra, kết quả thử nghiệm của bốn nhóm dự án trong Bảng 3.12
cũng phản ánh những lợi thế của phương pháp được đề xuất trong điều khoản về thời gian, nỗ lực và khả năng phát hiện lỗi. Trong Bảng 3.12, nhóm B1 và B2 có kinh nghiệm về AgileUATM, vì vậy họ thực hiện hiệu quả hơn trong việc đặc tả myDSL, cũng như khả năng sử dụng heuristic, thêm nhiều ràng buộc hơn để tối ưu hóa đầu dữ liệu sinh ra và sử dụng tính năng sinh mã kịch bản kiểm thử đơn vị BDD giúp phát hiện lỗi tốt hơn nhóm A1, A2. Đặc biệt, dự án của nhóm B2 có độ bao phủ thấp là do một số US khơng có dữ liệu đầu vào mà là một dãy các sự kiện và hành động, vì vậy phương pháp đề xuất đã khơng được đáp ứng. Một điểm mạnh khác của phương pháp đề xuất là dữ liệu ngẫu nhiên sẽ tăng xác suất phát hiện lỗi. Phương pháp này không chỉ để kiểm tra tự động mà cịn để kiểm tra thủ cơng một cách hiệu quả.
Hạn chế của phương pháp được đề xuất là nếu các câu chuyện của người dùng (US) khơng có giá trị đầu vào hoặc khơng có điều kiện đầu vào như US09, US10 sẽ không được đặc tả điều kiện vào cho AgileUATM. Ngoài ra, kiểm thử mức đơn vị là rất cần thiết; hầu hết các công việc phụ thuộc chủ yếu vào khả năng và kinh nghiệm của kỹ sư phát triển. Tuy nhiên, công cụ AgileUATM và phương pháp BDD là những cách hiệu quả cho các kỹ sư phát triển và kỹ sư kiểm thử có ít kinh nghiệm.
Dữ liệu kiểm thử được tạo ra tập trung vào cả giá trị hợp lệ và không hợp lệ để phát hiện lỗi và kiểm thử khả năng chịu lỗi. Việc xác định các điều kiện khơng hợp lệ và chẩn đốn có liên quan đến kết quả tạo dữ liệu. Phạm vi của yêu cầu phụ thuộc vào các tính năng của US và tính thỏa đáng của AC bị ảnh hưởng bởi kinh nghiệm và khả năng PO, kỹ sư kiểm thử. Do đó, việc lựa chọn các kỹ sư thực nghiệm trong nghiên cứu này ảnh hưởng đến kết quả nghiên cứu. Đặc tả myDSL khơng chính xác dẫn đến việc tạo dữ liệu khơng nhất qn (tính chính xác và phù hợp của ngơn ngữ được chỉ định với AC và câu chuyện người dùng chưa được kiểm tra). Kiểu dữ liệu chuỗi là một thách thức để tạo đầu vào kiểm tra và vấn đề dữ liệu có ý nghĩa cũng là một hạn chế của phương thức. Hiệu quả của phương pháp này hỗ trợ cho các ứng dụng có nhiều trường nhập dữ liệu. Giải pháp bị giới hạn khi các ứng dụng nhận các sự kiện thông qua một loạt các sự kiện để thực hiện một tác vụ cụ thể. Kiểu dữ liệu được thực nghiệm và nghiên cứu trong luận án này là kiểu số (int, real), kiểu luận lý Boolean, kiểu chuỗi (string), các kiểu dữ liệu khác sẽ được phát triển ở phiên bản