Màn hình chi tiết của một Task (đại diện cho một chức năng lớn) hiển thị các thông tin của “Task” và liệt kê tất cả các “Sub-task” (đại diện cho một chức năng nhỏ) mà nó thuộc vào.
Hình 3.11. Hiển thị thông tin của một “Task”
Có thể quản lý tất cả các Task và Sub-task đƣợc tao ra trong màn hình “All issues”
Jira hỗ trợ rất mạnh các màn hình báo cáo
- Chúng ta có quan sát lịch làm việc (schedule) tổng thể của dự án bao gồm những việc cần phải đƣợc làm trong dự án là gì? và đƣợc làm khi nào? thông qua lƣợc đồ WBS Gantt
Hình 3.13. Lược đồ WBS Gantt hiển thị lịch làm việc của dự án
- "Srum board" giúp quan sát công việc của các thành viên hàng ngày, hàng tuần. Với các trạng thái:
+ To Do: Những việc cần làm
+ Inprogress: Những việc đang đƣợc làm
+ Resolve: Những việc đã đƣợc làm xong và cần đƣợc xác nhận lại
+ Done: Những việc đã làm xong và đã đƣợc xác nhận
o Một "Scrum board" đƣợc tạo có thể nhìn thấy nhiệm vụ của từng thành viên trong các "Component" hoặc "Version" khác nhau bằng cách sử dụng tính năng "Filter"
Hình 3.14. Màn hình “Scrum board” hiển thị công việc của các thành viên
- "Dashboard" là màn hình hiển thị tất cả những báo cáo dƣới dạng bảng, đồ thị, ... mà bạn chọn. Để hiện thị những báo cáo này ngƣời dùng phải tạo "Gadget" và chọn loại “Gadget” để hiển thị trên màn hình "Dashboard", và để hiển thị những thông tin cần thiết, ngƣời dùng có thể cấu hình tùy ý bằng cách sử dụng các bộ lọc. Ngƣời dùng có thể tạo ra có bộ lọc nhƣ lọc theo dự án, chức năng, sprint, nhiệm vụ, thành viên, thời gian, … Chúng ta chọn kiểu hiển thị là các “Gadget”, mỗi loại "Gadget" mang một ý nghĩa khác nhau, tùy vào từng vai trò của các thành viên trong dự án mà chọn loại "Gadget" cho phù hợp. Ví dụ nhƣ:
Issue Statistics: Hiển thị thống kê các vấn đề đƣợc trả về từ một bộ lọc (Filter) và đƣợc phân chia theo lĩnh vực cụ thể nhƣ tổng số lỗi gây ra bởi mỗi lập trình viên, tổng số lỗi đƣợc tìm thấy của mỗi kiểm thử viên, Số lỗi xảy ra theo loại...
Pie Chart: Hiên thị thống kê các vấn đề của một dự án hoặc trả về từ bộ lọc (Filter) và cũng đƣợc nhóm theo bất kỳ loại thống kê nào nhƣ Issue Statistics
Two Dimensional Filter Statistics: Tiện ích thống kê hai chiều dựa trên dữ liệu trả về từ một bộ lọc (Filter)
Hình 3.15. Chọn loại “Gadget” (lược đồ, bảng, đồ thị, ….)
Hình 3.17. Hiển thị các báo cáo trên màn hình Dashboard (2)
Kết luận: Sử dụng công cụ quản lý dự án Jira, chúng ta có thể quản lý đƣợc tất cả các
dự án đƣợc phát triển, quản lý đƣợc tất cả các thành viên của một tổ chức. Quản lý đƣợc công việc của mỗi thành viên/nhóm, trạng thái công việc của mỗi thành viên/nhóm và tiến độ công việc của họ hàng ngày, hàng tuần, hoặc theo một lịch làm việc cụ thể trong các dự án khác nhau. Jira cho thấy sự phù hợp của nó với mô hình Scrum từ việc quản lý các sprint, các hạng mục trong Sprint backlog và Product backlog. Hơn thế nữa, Jira hỗ trợ các màn hình theo dõi Schedule nhƣ WBS Gantt, Scrum board rất hữu ích. Và đặc biệt là màn hình hiển thị các báo cáo “Dashboard” rất dễ nhìn và dễ dàng phân tích những thông tin hữu ích, cần thiết để cung cấp hỗ trợ cho việc quản lý dự án, quản lý công việc trở nên dễ dàng hơn.
3.3. MỘT SỐ CÔNG CỤ HỖ TRỢ KIỂM THỬ TỰ ĐỘNG
3.3.1. Selenium
3.3.1.1. Giới thiệu
Sử dụng công cụ Selenium để thực hiện kiểm thử chức năng của trang web:
http://bagasse.vn/
Do giới hạn của luận văn, nên luận văn sẽ chỉ đề cập đến việc kiểm thử cho 3 chức năng của trang web này là: đăng ký ngƣời dùng, đăng nhập hệ thống và đăng xuất. Và đề tài cũng chỉ chọn 1 ca kiểm thử cho mỗi chức năng nhƣ sau: Ca kiểm thử 1: Ngƣời dùng đăng ký tài khoản ngƣời dùng thành công
Sau khi hoàn thành việc tạo ra các ca kiểm thử, Selenium sẽ lƣu lại tất cả các ca kiểm thử này dƣới dạng một bộ kiểm thử gọi là test-suite.
Tiếp theo sẽ tiến hành thực hiện kiểm thử bằng cách chạy các bộ kiểm thử (test suite) đã tạo. Luận văn sẽ demo hai trƣờng hợp: kết quả kiểm thử thành công và kết quả kiểm thử thất bại. Và đánh giá kết quả kiểm thử.
3.3.1.2. Tạo kịch bản kiểm thử
Sử dụng chức năng [Record] trên thanh công cụ để ghi lại các bƣớc của một ca kiểm thử
Sau khi đã có các bƣớc của một ca kiểm thử, cần xác nhận kết quả đầu ra mong đợi sau khi các bƣớc kiểm thử đƣợc thực hiện
Selenium hỗ trợ các câu lệnh xác nhận kết quả đầu ra: + verifyTitle/assertTitle + verifyTextPresent + verifyElementPresent + verifyText + verifyTable … Chức năng đăng ký
Khi chƣa có tài khoản hệ thống, ngƣời dùng nhấn vào nút [Đăng ký]. Màn hình sẽ hiển thị form đăng ký, ngƣời dùng nhập các thông tin nhƣ hình 3.18. Sau khi đăng nhập ngƣời dùng nhấn vào nút [Đăng ký] trong form để hoàn tất thủ tục đăng ký ngƣời dùng. Sau khi đăng ký thành công, hệ thống tự động đăng nhập và chuyển đến trang chủ (hình 3.10) với trạng thái tài khoản ngƣời dùng đã đƣợc đăng nhập. Cần tìm đặc điểm khi hệ thống đƣợc đăng nhập để xác nhận ca kiểm thử của chức năng đăng ký. Một đặc điểm khi hệ thống đăng nhập thành công là “Họ và tên” của ngƣời đăng nhập đƣợc hiển thị trên góc của trang web.
Hình 3.18. Form “Đăng ký người dùng”
Kết hợp chức năng record và câu lệnh xác nhận “verify text” của
Selenium, ta xây dựng đƣợc một ca kiểm thử cho chức năng đăng ký ngƣời dùng nhƣ sau:
Command Target Value
clickAndWait link=Đăng ký type id=ctl00_ContentPlaceHolder1_txt RegUserName Cao Hang type id=ctl00_ContentPlaceHolder1_txt RegPassword 123456 type 123456 type id=ctl00_ContentPlaceHolder1_txt Name
Cao Thi Hang type id=ctl00_ContentPlaceHolder1_txt
Address1
310 Nghi Tam - Ha Noi type id=ctl00_ContentPlaceHolder1_txt 976381935
type id=ctl00_ContentPlaceHolder1_txt Email
hangctbk@gmail.com clickAndWait id=ctl00_ContentPlaceHolder1_btn
Registry
verifyText css=p Cao Thi Hang | Đăng xuất |
Bảng 3.1. Ca kiểm thử đăng ký người dùng thành công bằng selenium
Chức năng đăng nhập
Ngƣời dùng nhấn nút [Đăng nhập] để hiển thị form đăng nhập. Ngƣời dùng nhập các thông tin nhƣ hình 3.19 sau khi tài khoản này đã đƣợc đăng ký thành công. Sau đó nhấn vào nút [Đăng nhập]. Ta cũng thu đƣợc ca kiểm thử cho chức năng đăng nhập.
Hình 3.19. Form “Đăng nhập hệ thống”
Kết hợp chức năng record và câu lệnh xác nhận của Selenium ta thu đƣợc ca kiểm thử cho chức năng đăng nhập nhƣ sau:
Command Target Value
open /trang-chu.aspx clickAndWait link=Đăng nhập type id=ctl00_ContentPlaceHolder1_txt UserName Cao Hang type id=ctl00_ContentPlaceHolder1_txt 123456
clickAndWai id=ctl00_ContentPlaceHolder1_bt nLogin
verifyText css=p Cao Thi Hang | Đăng xuất |
Bảng 3.2. Ca kiểm thử người dùng đăng nhập thành công bằng selenium
Chức năng đăng xuất
Kiểm thử chức năng đăng xuất: Khi hệ thống ở trạng thái đăng nhập thành công. Ngƣời dùng có thể nhấn vào nút [Đăng xuất] để đăng xuất hệ thống.
Kết hợp chức năng record và câu lệnh xác nhận “assertElementPresent” của Selenium ta thu đƣợc ca kiểm thử cho chức năng đăng xuất nhƣ sau:
Command Target Value
open /trang-chu.aspx clickAndWait link=Đăng xuất assertElementPresent link=Đăng nhập
Bảng 3.3. Ca kiểm thử người dùng đằng xuất thành công bằng selenium 3.3.1.3. Thực hiện kiểm thử
Lƣu tất cả các ca kiểm thử đã tạo cho các chức năng đăng ký ngƣời dùng, đăng nhập và đăng xuất thành bộ kiểm thử “test-suite”. Bấm vào nút “Run All” trên thanh công cụ để thực hiện kiểm thử cho bộ kiểm thử này.
Thực hiện kiểm thử thành công
Kết thúc quá trình kiểm thử, nhƣ hình 3.20 tất cả các ca kiểm thử đƣợc thực hiện, và tất cả các ca kiểm thử đều vƣợt qua kiểm thử. Tức là, tổng số ca kiểm thử thành công “pass” = 3, tổng số ca kiểm thử thất bại “fail” = 0. Tất cả các ca kiểm thử đều có màu xanh
Hình 3.20. Thực hiện kiểm thử thành công
Thực hiện kiểm thử thất bại
Để có một ca kiểm thử thất bại từ bộ kiểm thử đã tạo, thay đổi một nội dung của nó. Ví du: thay đổi giá trị cần xác nhận trong ca kiểm thử của chức năng đăng nhập từ “Cao Thi Hang | Đăng xuất |” thành “Cao Thi Hang |”
Kết thúc quá trình kiểm thử, nhƣ hình 3.21 tất cả các ca kiểm thử đƣợc thực hiện, và tồn tại ca kiểm thử không vƣợt qua kiểm thử. Với tổng số ca kiểm thử thành công “pass” = 2, tổng số ca kiểm thử thất bại “fail” = 1. Hai ca kiểm thử vƣợt qua có màu xanh, ca kiểm thử thất bại có màu đỏ.
Để có thể biết đƣợc nguyên nhân lỗi của ca kiểm thử thất bại, chúng ta có thể xem trong Log tại dòng có chữ màu đỏ.
Hình 3.21. Thực hiện ca kiểm thử thất bại 3.3.1.4. Kết luận 3.3.1.4. Kết luận
Selenium IDE giúp chúng ta có thể tạo ra những kịch bản kiểm thử một cách nhanh chóng bằng cách sử dụng chức năng Record của Selenium. Sử dụng Selenium dễ dàng cho chúng ta biết đƣợc số ca kiểm thử thành công, thất bại (tức là có lỗi) và nguyên nhân xảy ra lỗi. Selenium rất phù hợp với mô hình phát triển dự án Scrum, khi một số chức năng đã hoàn thành ở sprint trƣớc, sang đến sprint tiếp theo sẽ phát triển một số chức năng mới. Tuy nhiên, các kiểm thử viên vẫn phải kiểm thử cả những chức năng cũ ở sprint trƣớc xem nó có bị ảnh hƣởng không. Nhƣ vậy, sẽ rất mất thời gian để kiểm tra lại. Nếu chúng ta tạo các ca kiểm thử bằng Selenium cho những chức năng cũ ở sprint trƣớc và thiết lập chúng một cách tự động, thì việc kiểm thử sẽ trở nên dễ dàng và hiệu quả hơn.
3.3.2. Apache Jmeter
3.3.2.1. Giới thiệu
Là một ứng dụng web, nên cũng khó tránh khỏi cùng một lúc số lƣợng ngƣời truy cập quá nhiều. Chính vì vậy với ứng dụng web, kiểm thử hiệu năng là rất cần thiết. Để kiểm thử hiệu năng ứng dụng web, nhƣ đã giới thiệu ở chƣơng 2, Apache Jmeter là một công cụ rất phù hợp và hữu ích để kiểm thử hiệu nặng cho ứng dụng web.
Do giới hạn trình bày của luận văn, nên nội dung đƣợc demo sẽ chọn một ca kiểm thử cụ thể trong kiểm thử hiệu năng web sử dụng công cụ Jmeter là “200 ngƣời cùng cùng truy cập vào trang chủ http://bagasse.vn/trang-chu.aspx để đọc thông tin”
3.3.2.2. Xây dựng kịch bản kiểm thử
Cấu hình cho Thread Group (Nhóm tiến trình)
Đại diện cho ngƣời sử dụng ảo (virtual user)
Với kịch bản 200 ngƣời dùng ảo cùng truy cập vào trang web, cần thiết lập các thông số sau cho Jmeter
Number of Threads (users): Số thread để giả lập là 200.
Mỗi ngƣời dùng độc lập đƣợc đại diện bởi mỗi thread vì vậy bạn muốn giả lập 200 ngƣời dùng đồng thời bạn cần nhập giá trị 200 cho thuộc tính này.
Ramp-Up Period (in seconds): Thời gian đƣa ra bởi Jmeter để tạo tất cả những thread cần thiết.
Nếu bạn thiết lập Ramp-Up Period (in seconds) là 1 cho 200 thread thì Jmeter sẽ thực hiện trong 1 giây để tạo ra 200 thread. Ngoài ra bằng cách thiết lập giá trị 0 tất cả thread có thể đƣợc tạo 1 lần.
Forever : Nếu bạn chọn nó thì Jmeter sẽ quyết định gửi yêu cầu liên tục vì vậy trƣờng hợp này Forever sẽ không đƣợc chọn
Loop Count : Bằng cách chỉ rõ giá trị của nó, Jmeter cho biết rằng có bao nhiều lần kiểm thử đƣợc lặp. Trong trƣờng hợp này chúng ta gọi tất cả yêu cầu cùng một lúc vì vậy đặt Loop Count = 1
Cấu hình HTTP Request cho một Sampler
Trong trƣờng hợp này chúng ta sẽ sử dụng Sampler là HTTP Request để thiết lập 200 ngƣời dùng gửi yêu cầu đến trang web cùng một lúc. Để thiết lập đƣợc những thông tìn này chúng ta cần biết thông tin của máy chủ là gì? Và yêu cầu gửi đến máy chủ là gì?
Hình 3.23. Cấu hình HTTP Request
Thêm vào các báo cáo: Một số báo cáo cần thiết để xem kết quả kiểm thử cần đƣợc
thêm vào
- Summary Report - View Results Tree - View Results in Table - Graph Results
3.3.2.3. Thực hiện kiểm thử và xem kết quả
Summary Report: Xem kết quả tổng hợp của tất cả các thread
Nhìn vào kết quả ta có thể thấy rằng 200 yêu cầu đƣợc gửi một lúc với:
Average: Thời gian trung bình xử lý yêu cầu là 3162 ms
Min: Thời gian nhỏ nhất để xử lý yêu cầu là 1019 ms
Max: Thời gian lớn nhất để xử lý yêu cầu là 9282 ms
Throughput: Thông lƣợng máy chủ là số lƣợng yêu cầu gửi đến máy chủ trên một đơn vị thời gian là 19.0/sec
Hình 3.24. Hiển thị kết quả trên màn hình Summary Report
View Results Tree: Xem kết quả của từng request trong kịch bản.
Nhìn vào kết quả ta có thể thấy rằng 200 yêu cầu đƣợc gửi thành công. Màn hình [View Results Tree] dễ dàng để nhìn thấy nội dung của mỗi yêu cầu, kết quả phản hồi từ máy chủ trả về cho mỗi yêu cầu, nội dung nào đƣợc gửi thành công, nội dung nào gửi không thành công, ...
Hình 3.25. Hiển thị kết quả trên màn hình View Results Tree
View Results in Table: Xem thông tin của từng request dƣới dạng bảng
Results in Table] cho thấy các mẫu đƣợc gửi đi vẫn theo một thứ tự. Chúng ta có thể biết đƣợc các mẫu đƣợc gửi đi vào thời gian nào và thời gian xử lý mỗi mẫu mất bao nhiêu. Nhìn vào kết quả ta có thể thấy đƣợc mẫu 1 đƣợc gửi đi vào lúc 14:50:39.591 và thời gian xử lý mẫu này mất 1326ms
Hình 3.26. Hiển thị kết quả trên màn hình View Results in Table
Graph Results: Xem kết quả dƣới dạng đồ thị
Nhìn vào kết quả ta có thể thấy rằng 200 yêu cầu đƣợc gửi thành công với:
- Average: Thời gian phản hồi trung bình hay thời gian trung bình xử lý một yêu cầu, đƣợc tính toán nhƣ tổng thời gian chạy đƣợc chia cho số yêu cầu đƣợc gởi đến máy chủ là 3162 ms
- Median: Thời gian xử lý đến yêu cầu thứ “giữa” là 2703 ms
Hình 3.27. Hiển thị kết quả trên màn hình Graph Results3.3.2.4. Kết luận 3.3.2.4. Kết luận
Với giả lập 200 ngƣời dùng cùng thực hiện hành động đọc thông tin trên trang web, Apache đã đƣa ra đƣợc những thông tin cần thiết cho kiểm thử hiệu năng. Với kết quả nhƣ trên có thể thấy rằng 200 ngƣời dùng, hệ thống vẫn có những phản hồi tốt. Để có đƣợc nhiều thông tin về mức chịu tải của hệ thống, cần thực hiện thêm các ca kiểm thử nữa bằng cách tăng số giả lập ngƣời dùng lên, đến khi nào nhận thấy rằng thời gian phản hồi (Average) của hệ thống tăng lên đáng kể nhƣng thông lƣợng (Throughput) của hệ thống không tăng thì đó là chính là mức chịu tải của hệ thống tức là số lƣợng ngƣời dùng lớn nhất mà hệ thống đáp ứng đƣợc.
3.3.3. Sinh dữ liệu kiểm thử tự động dựa trên giải thuật di truyền
3.3.3.1. Giới thiệu
Giải thuật di truyền sẽ đƣợc áp dụng để sinh dữ liệu kiểm thử cho tất cả các màn hình cần nhập dữ liệu đầu vào. Tuy nhiên do giới hạn trình bày của luận văn, nên chúng tôi sẽ chọn một màn hình cụ thể để thực hiện demo. Chúng tôi sẽ tạo dữ liệu kiểm thử cho màn hình [Đăng nhập] gồm 2 trƣờng cần nhập dữ liệu là: [Tên đăng nhập] và [Mật khẩu]. Sẽ có 3 trƣờng hợp xảy ra của hệ thống khi đăng nhập nhƣ sau: - Trƣờng hợp 1: Khi nhập dữ liệu vào [Tên đăng nhập] và [Mật khẩu], sau đó nhấn vào