Lựa chọn loại dự án

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Nghiên cứu các phương pháp đảm bảo chất lượng phần mềm (Trang 53)

Jira có thể quản lý các hạng mục của Product backlog

Trong mô hình Scrum, Product backlog là danh sách các yêu cầu cần phải làm để hoàn thành sản phẩm. Các hạng mục trong Product backlog sẻ đƣợc quản lý trên Jira dƣới dạng "Components".

Hình 3.6. Màn hình quản lý các “Component” của dự án

- Jira có thể quản lý các hạng mục của Sprint backlog

Trong mô hình Scrum, dự án sẽ đƣợc phát triển theo từng giai đoạn, mỗi giai đoạn đƣợc gọi là một Sprint. Thông thƣờng, mỗi Sprint kéo dài khoảng 2 tuần đến 1 tháng. Jira sẽ quản lý các Sprint trong mô hình Scrum dƣới dạng"Version". Tạo một Sprint chúng ta phải chọn một khoảng thời gian “Start date” và “Release date” chính là khoảng thời gian bắt đầu và kết thúc của một Sprint.

Hình 3.7. Màn hình quản lý các “Version” của dự án

Trong mô hình Scrum, Sprint backlog hiện thực hóa môt cách chi tiêt các mục tiêu lấy từ các hạng mục trong Product backlog sao cho có thể thấy đƣợc những thay đổi về tiến độ hàng ngày. Các công việc trong Sprint sẽ đƣợc quản lý trên Jira dƣới

ta sẽ tạo nó dƣới dạng "Task”. Những chức năng chi tiết hơn của sprint chúng ta sẽ chọn là "Sub-task"

Hình 3.8. Ví dụ về một Sprint backlog cơ bản

 Khi tạo một yêu cầu, nhiệm vụ, ... trong một Sprint trên Jira chúng ta phải chọn: Project: Dự án mà chức năng này thuộc nó

 Issue Type: Loại của chức năng chúng ta có thể tự thiết lập nó trong Jira nhƣ yêu cầu mới, sửa, cải thiện, ....

 Summary: Tên chức năng

 Priority: Mức độ ƣu tiên của chức năng

 Due Date: Ngày hoàn thành chức năng

 Components: Nó thuộc hạng mục nào của Product Backlog

 Affects Version/s: Nó thuộc các Sprint nào

 Fix Version/s: Nó cần đƣợc làm ở các Sprint nào

 Assignee: Ngƣời đƣợc giao nhiệm vụ này

 Reporter: Ngƣời tạo ra nhiệm vụ này

 Evironment: Môi trƣờng thực hiện nhiệm vụ này

 Start date: Ngày bắt đầu thực hiện chức năng

 End date: Ngày hoàn thiện chức năng

Hình 3.9. Tạo một “Task” trên Jira

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

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Nghiên cứu các phương pháp đảm bảo chất lượng phần mềm (Trang 53)

Tải bản đầy đủ (PDF)

(85 trang)