Yêu cầu về kiến thức và kĩ năng Để thực hiện được công việc kiểm thử phần mềm, đòi hỏi người kiểm thử phải có những kiến thức và kinh nghiệm sau: - Có kiến thức về kiểm thử phần mềm - B
Trang 1TRƯỜNG ĐẠI HỌC KINH TẾ KHOA THỐNG KÊ – TIN HỌC
BÁO CÁO THỰC TẬP NGHỀ NGHIỆP NGÀNH HỆ THỐNG THÔNG TIN QUẢN LÝ
CHUYÊN NGÀNH QUẢN TRỊ HỆ THỐNG THÔNG TIN
THỰC HIỆN KIỂM THỬ HỆ THỐNG BÁN HÀNG
NOPCOMMERCE
Giảng viên hướng dẫn : ThS Cao Thị Nhâm
Trang 21
LỜI CẢM ƠN
Lời đầu tiên, tụi em xin chân thành cảm ơn quý thầy cô giáo trong trường ĐH Kinh Tế nói chung và quý Thầy Cô Khoa Thống kê Tin học nói riêng đã dạy dỗ cho em kiến thức về các môn đại cương cũng như các môn chuyên ngành, giúp em có được cơ sở lý thuyết vững vàng và tạo điều kiện cho em trong suốt quá trình học tập Đặc biệt là cô Cao Thị Nhâm
đã hỗ trợ hết mình, chỉ bảo nhiệt tình và cho em những lời khuyên cũng như những góp ý rất quan trọng để em có thể hoàn thành tốt kì thực tập hè này
Ngoài ra, em xin chân thành gửi lời cảm ơn đến Mentor Nguyễn Thanh Tú đã hướng dẫn trực tiếp, chỉ đạo và tạo mọi điều kiện giúp đỡ em trong suốt quá trình học cũng như thực tập tại đây
Ngoài ra, em cũng xin gửi lời cảm ơn đến các anh chị nhân viên, quản lý của công ty TMA Bình Định đã hỗ trợ em tìm hiểu tại công ty và tạo mọi điều kiện để em có thể hoàn thành tốt Trong suốt quá trình làm đề tài cũng như quá trình tìm hiểu, sẽ không thể tránh khỏi những sự thiếu sót và hạn chế Em rất mong nhận được những ý kiến đóng góp và phản hồi từ quý thầy cô để em có thể khắc phục được những sai sót cũng như rút ra được những bài học cho mình và trau dồi thêm những kiến thức mới Em xin chân thành cảm ơn!
Trang 3
2
LỜI CAM ĐOAN
Em xin cam đoan đây là bài cáo thực tập nghề nghiệp của em và dưới sự hướng dẫn của giáo viên hướng dẫn của ThS Cao Thị Nhâm và Mentor Nguyễn Thanh Tú Ngoài ra không
có bất cứ sự sao chép của người khác Nội dung báo cáo thực tập là sản phẩm mà em đã nỗ lực nghiên cứu trong quá trình cô hướng dẫn cũng như tham gia thực tập tại Công ty TMA Solutions tại Bình Định Các số liệu, kết quả trình bày trong báo cáo là hoàn toàn trung thực, em xin chịu hoàn toàn trách nhiệm, kỷ luật của bộ môn và nhà trường đề ra nếu như
có vấn đề xảy ra
Trang 43
MỤC LỤC
LỜI MỞ ĐẦU………1
CHƯƠNG 1: TỔNG QUAN VỀ VỊ TRỊ THỰC TẬP VÀ ĐƠN VỊ THỰC TẬP 2
1.1 Giới thiệu tổng quát về doanh nghiệp thực tập 2
1.1.1 Thông tin chung 2
1.1.2 Lĩnh vực hoạt động 3
1.1.3 Cơ cấu tổ chức 3
1.1.4 Chính sách đãi ngộ 4
1.2 Tổng quan về vị trí kiểm thử phần mềm - Tester 5
1.2.1 Yêu cầu về kiến thức và kĩ năng 5
1.2.2 Mô tả công việc 5
1.2.3 Mức lương tại thị trường Việt Nam 5
1.2.4 Con đường phát triển 6
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT……….8
2.1 Tổng quan về kiểm thử phần mềm 8
2.1.1 Giới thiệu về kiểm thử phần mềm 8
2.1.2 Mục tiêu của kiểm thử phần mềm 8
2.1.3 Nguyên tắc kiểm thử 8
2.1.4 Phân biệt Error / Fault / Failure 8
2.1.5 Phân biệt giữa Xác minh và Xác thực 9
2.1.6 Phân biệt QA và QC: 9
2.2 Vòng đời phát triển phần mềm (SDLC) 9
2.2.1 Định nghĩa 9
2.2.2 Các mô hình phổ biến của SDLC 10
2.2.2.1 WaterFall Model 10
2.2.2.2 V Model 10
2.2.2.3 Agile Model 11
2.2.2.4 Scrum Methodology 12
2.3 Các loại kiểm thử phần mềm 13
2.3.1 Kiểm thử thủ công (Manual Testing) 13
2.3.2 Kiểm thử tự động (Automation Testing) 13
Trang 54
2.4 Các phương pháp kiểm thử phần mềm 14
2.4.1 Static Testing (Kiểm thử tĩnh) 14
2.4.2 Dynamic Testing (Kiểm thử động) 14
2.4.3 White box Testing (Kiểm thử hộp trắng) 14
2.4.4 Black box Testing (Kiểm thử hộp đen) 15
2.5 Các cấp độ kiểm thử phần mềm 16
2.5.1 Unit Testing (Kiểm thử đơn vị) 16
2.5.2 Integration Testing (Kiểm thử tích hợp) 16
2.5.3 System Testing (Kiểm thử hệ thống) 17
2.5.4 Acceptance Testing (Kiểm thử chấp nhận) 17
2.6 Các kỹ thuật kiểm thử 17
2.6.1 Specification-based techniques (Kỹ thuật dựa trên đặc điểm kỹ thuật) 17
2.6.2 Experience - based techniques (Kỹ thuật dựa trên kinh nghiệm) 18
CHƯƠNG 3: ĐẶC TẢ WEBSITE NOPCOMMERCE………19
3.1 Giới thiệu Tổng quát về Website NopCommerce demo 19
3.2 Sơ đồ Usecase tổng quát của hệ thống 20
3.2.1 Sơ đồ Usecase tổng quát 20
3.2.2 Vai trò của tác nhân 20
3.3 Workflow của hệ thống 22
3.4 Phân tích Use case “Đăng ký” 22
3.4.1 Sơ đồ Use case tổng quát cho chức năng “Đăng ký” 22
3.4.2 Đặc tả yêu cầu cho chức năng “Đăng ký” 22
3.5 Phân tích Use case “Đăng nhập” 26
3.5.1 Sơ đồ Use case tổng quát cho chức năng “Đăng nhập” 26
3.5.2 Đặc tả yêu cầu cho chức năng “Đăng nhập” 26
3.5.3 Sơ đồ Use case tổng quát cho chức năng “Quên mật khẩu” 28
3.5.4 Đặc tả yêu cầu cho chức năng “Quên mật khẩu” 28
3.5.5 Đặc tả yêu cầu cho chức năng “Đăng xuất” 29
3.6 Phân tích Use case “Quản lý giỏ hàng” 30
3.6.1 Sơ đồ usecase tổng quát cho chức năng “Quản lý giỏ hàng” 30
3.6.2 Đặc tả yêu cầu cho use case “Thêm sản phẩm vào giỏ hàng” 30
3.6.3 Đặc tả yêu cầu cho use case “Xem sản phẩm trong giỏ hàng” 31
Trang 65
3.6.4 Đặc tả yêu cầu cho use case “Sửa số lượng sản phẩm trong giỏ hàng” 33
3.6.5 Đặc tả yêu cầu cho use case “Xóa sản phẩm vào giỏ hàng” 35
CHƯƠNG 4: THỰC HIỆN KIỂM THỬ HỆ THỐNG NOPCOMMERCE 37
4.1 Quy trình kiểm thử phần mềm bằng Manual Testing 37
4.1.1 Lập kế hoạch 37
4.1.2 Phân tích và thiết kế 38
4.1.2.1 Phân tích 38
4.1.2.2 Thiết kế testcase 39
4.1.2.3 Tạo test case 40
4.1.3 Thực hiện kiểm thử 40
4.1.4 Đánh giá và báo cáo 41
4.1.4.1 Kết quả thực hiện kiểm thử từng chức năng 41
4.1.4.2 Kết quả thực hiện kiểm thử toàn bộ 42
4.2 Quy trình kiểm thử phần mềm bằng Selenium Framework 42
4.2.1 Giới thiệu công cụ kiểm thử tự động Selenium 42
4.2.2 Môi trường Selenium 43
4.2.3 Cài đặt Selenium 43
4.2.4 Test case automation: 46
4.2.4.1 Xác minh người dùng đăng ký tài khoản thành công Error! Bookmark not defined 4.2.4.2 Xác minh người dùng đăng nhập vào hệ thống thành công Error! Bookmark not defined 4.2.4.3 Xác minh người dùng có thể thêm sản phẩm vào giỏ hàng Error! Bookmark not defined 4.2.4.4.Xác minh người dùng xem và sửa số lượng sản phẩm trong giỏ hàngError! Bookmark not defined 4.2.4.5 Xác minh người dùng có thể xóa sản phẩm trong giỏ hàng Error! Bookmark not defined KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 47
TÀI LIỆU THAM KHẢO 48
CHECK LIST CỦA BÁO CÁO 49
PHỤ LỤC 50
Trang 76
DANH MỤC HÌNH ẢNH
Hình 1.1 Công ty TMA Solution Bình Định……… 2
Hình 1.2 Cơ cấu tổ chức của TMA……… … 3
Hình 2.1 Mô hình Scrum………12
Hình 3.1 Giao diện homepage của trang web NopCommerce………19
Hình 3.2 Use Case của trang web NopCommerce………20
Hình 3.3 Workflow của trang web NopCommerce……… 22
Hình 3.4 Click vào Textbox “Register”……….22
Hình 3.5 Click vào button “Register”………25
Hình 3.6 Màn hình đăng ký thành công………25
Hình 3.7 Click vào Textbox “Log In”………26
Hình 3.8 Màn hình nhập thông tin đăng nhập……….……….27
Hình 3.9 Click vào button “LOG IN”………27
Hình 3.10 Click vào textbox “Forgot password”……… 29
Hình 3.11 Màn hình trang giỏ hàng………32
Hình 3.12 Màn hình trang giỏ hàng trống……… 33
Hình 3.13 Màn hình thông báo lỗi khi SL > 1000 SP………34
Hình 3.14 Màn hình thông báo lỗi khi SL < 0 SP……… 34
Hình 3.15 Màn hình khi thay đổi số lượng……….34
Hình 3.16 Màn hình xoá sản phẩm khỏi giỏ hàng……….36
Hình 3.17 Màn hình khi sản phẩm được xóa khỏi giỏ hàng……….…….36
Hình 4.1 Template test case……… 39
Hình 4.2 Màn hình download Chrome Driver……….… 43
Hình 4.3 Tải Version 115.x.xxxx.xx của Chrome……….… 43
Hình 4.4.Tập tin chromedriver.exe……….…… 44
Hình 4.5 Selenium Webdriver……… 44
Hình 4 6 Màn hình tạo Project mới……… 44
Hình 4.7 Đặt tên cho project……….…45
Hình 4.8 Màn hình thêm thư viện……… 45
Hình 4.9 Referenced Library……… 46
Trang 87
DANH MỤC BẢNG BIỂU
Bảng 1.1 Mức lương của Tester theo từng cấp bậc………6
Bảng 1.2 Mức lương của Tester theo khu vực………6
Bảng 3.1 Vai trò của các tác nhân trong trang web NopCommerce………… 21
Bảng 3.2 Đặc tả chức năng Đăng ký……… 24
Bảng 4.1 Kế hoạch viết testcase……… 37
Bảng 4.2 Thông tin về dữ liệu thực hiện kiểm thử……….…38
Bảng 4.3 Thống kê số lượng test cases được thiết kế……….…40
Trang 98
DANH MỤC CÁC TỪ VIẾT TẮT
QA : Quality Assurance
QC : Quality Control
SDLC : Software Development Life Cycle
CNTT : Công nghệ thông tin
Trang 101
LỜI MỞ ĐẦU
1 Mục tiêu nghiên cứu của đề tài
- Thực hiện kiểm thử manual testing và automation testing trên hệ thống bán hàng trực tuyến Nopcommerce
2 Đối tượng và phạm vi nghiên cứu
- Đối tượng: Hệ thống bán hàng trực tuyến Nopcommerce
- Phạm vi: Các kiến thức tổng quan về kiểm thử phần mềm
3 Kết cấu của đề tài
Đề tài được tổ chức gồm phần mở đầu, 4 chương nội dung và phần kết luận
- Mở đầu
- Chương 1: Tổng quan về vị trí thực tập và đơn vị thực tập
- Chương 2: Cơ sở lý thuyết
- Chương 3: Đặc tả website Nopcommerce
- Chương 4: Thực hiện kiểm thử hệ thống Nopcommerce
- Kết luận và hướng phát triển
Trang 112
CHƯƠNG 1: TỔNG QUAN VỀ VỊ TRỊ THỰC TẬP VÀ ĐƠN VỊ
THỰC TẬP 1.1 Giới thiệu tổng quát về doanh nghiệp thực tập
1.1.1 Thông tin chung
- TMA Solutions là công ty thuộc Tập đoàn Công nghệ TMA (tiếng Anh: TMA Tech Group hoặc TMA Technology Group, tiếng Việt: Công ty TNHH Giải Pháp Phần Mềm Tường Minh, gọi tắt TMA) là một tập đoàn Việt Nam, kinh doanh các dịch vụ liên quan đến phát triển phần mềm
● Loại hình: Doanh nghiệp Tư Nhân
● Ngành nghề: Dịch vụ CNTT
● Thành lập: Tháng 3 năm 1997
● Người sáng lập: Bà Bùi Ngọc Anh, CEO: Ông Nguyễn Hữu Lệ
● Trụ sở chính: 111 Đường Nguyễn Đình Chính, Quận Phú Nhuận, Thành phố Hồ Chí Minh, Việt Nam
● Dịch vụ: Gia Công Xuất khẩu Phần Mềm
● Số nhân viên: 4000 (4/2023)
● Công ty mẹ: Tập đoàn Công nghệ TMA (TMA Tech Group)
(Hình 1.1 Công ty TMA Solution Bình Định)
- Được thành lập năm 1997, TMA là tập đoàn công nghệ hàng đầu Việt Nam với
4000 kỹ sư và khách hàng là những tập đoàn công nghệ cao hàng đầu thế giới từ 30 quốc gia TMA hiện có 7 chi nhánh tại Việt Nam (6 tại Tp.HCM và 1 ở Tp Quy Nhơn) cùng 6 chi nhánh ở nước ngoài (Mỹ, Úc, Canada, Đức, Nhật, Singapore)
- Tháng 6 năm 2018, TMA đã mở chi nhánh tại Bình Định Sau 4 năm, TMA Bình Định đã phát triển nhanh chóng với hơn 400 kỹ sư, trong đó có nhiều kỹ sư đang làm việc tại TP.HCM đã trở về làm việc tại quê hương
Trang 123
- Tháng 8 năm 2018, TMA đã khởi công xây dựng Công viên Sáng tạo TMA Bình Định (TMA Innovation Park – TIP) trên 10 hecta tại Thung lũng Sáng tạo Quy Nhơn (Quy Nhon Innovation Park) với vốn đầu tư hàng trăm tỷ đồng
- Với sự phát triển vững mạnh 25 năm qua, TMA tự hào nhận được sự tin tưởng của khách hàng là những tập đoàn lớn đến từ 30 quốc gia trên thế giới TMA nhiều năm liền vinh dự được bình chọn trong top doanh nghiệp CNTT Việt Nam, liên tục được vinh danh trong top 10 doanh nghiệp xuất khẩu phần mềm, Top 10 doanh nghiệp Fintech, Top 10 doanh nghiệp AI – IoT…
- TMA với môi trường làm việc chuyên nghiệp và thân thiện, luôn nỗ lực tạo ra đời sống văn hóa phong phú, sôi động, để nhân viên TMA luôn cảm thấy thoải mái, xem công ty không chỉ là nơi làm việc, mà còn là nơi có các hoạt động vui chơi, giải trí đầy thú vị, hấp dẫn
1.1.2 Lĩnh vực hoạt động
● Tài chính, Ngân hàng & Bảo hiểm
● Thương mại điện tử & Phân phối
● Sức khỏe / Y tế
● Giáo dục, viễn thông
● Nông nghiệp & Chế biến thực phẩm
● Vận tải & Logistic
● Khách sạn & Du lịch
1.1.3 Cơ cấu tổ chức
(Hình 1.2 Cơ cấu tổ chức của TMA)
Trang 134
TMA Bình Định đang được dẫn dắt và lãnh đạo bởi đội ngũ giàu kinh nghiệm:
- Chủ tịch: TS Nguyễn Hữu Lệ
- Giám đốc điều hành: Bà Ánh Bùi
- Phó giám đốc, giám đốc tài chính: Bà Dương Phạm
- Phó giám đốc nhân sự và hành chính: Bà Uyên Phạm
- Phó giám đốc phát triển kinh doanh: Ông Hồng Trần
- Giám đốc cấp cao, phát triển doanh nghiệp: Tiến sĩ Quang D.Bùi
- Phó giám đốc giao hàng: Ông Lạc Bùi
- Giám đốc, hoạt động Bắc Mỹ: Ông Alex Newcombe
- Giám đốc phát triển kinh doanh Bắc Mỹ: Ông Minh Nguyễn
- Giám đốc điều hành, TMA Australia: Ông Tuấn Nguyễn
- Giám đốc điều hành, TMA Japan: Ông Sata Nobuo
- Nhà khoa học dữ liệu trưởng: Tiến sĩ David Levett
1.1.4 Chính sách đãi ngộ
TMA luôn chủ động điều chỉnh thu nhập và khen thưởng kịp thời đối với các cá
nhân xuất sắc, những phúc lợi kèm theo cũng luôn được đảm bảo như:
- Cung cấp cho nhân viên đầy đủ các gói BHYT, BHXH
- Chương trình Bảo hiểm chăm sóc sức khỏe toàn diện với mức bảo hiểm
cao, tạo điều kiện cho nhân viên được khám, điều trị và sử dụng các dịch
vụ chăm sóc y tế lớn tại các bệnh viện uy tín
- Chính sách cho vay tiền không lãi suất, không thế chấp để chia sẻ với
nhân viên nỗi lo về tài chính
- Thành lập Quỹ từ thiện “Khát vọng TMA” với số quỹ ban đầu 1 tỷ đồng,
kịp thời hỗ trợ tài chính cho các nhân viên, người có hoàn cảnh khó khăn khắp mọi miền đất nước
- Quỹ Team building hỗ trợ các hoạt động ngoại khóa hàng năm cho nhân
viên
- Quỹ khen thưởng hàng Quý (TMA Quarterly Star Performer) cho nhân
viên xuất sắc lên đến 1 tỷ đồng/năm
- Lương thưởng cạnh tranh
- Nhiều cơ hội thăng tiến
- Hệ thống đào tạo nội bộ với hàng trăm khóa học mỗi năm
Trang 145
1.2 Tổng quan về vị trí kiểm thử phần mềm - Tester
1.2.1 Yêu cầu về kiến thức và kĩ năng
Để thực hiện được công việc kiểm thử phần mềm, đòi hỏi người kiểm thử phải có những kiến thức và kinh nghiệm sau:
- Có kiến thức về kiểm thử phần mềm
- Biết ít nhất một ngôn ngữ lập trình phổ biến như Java, Python…
- Có kinh nghiệm làm việc trên các hệ điều hành (Windows, iOS, Android)
- Kiến thức chuyên môn thực tế với các Framework Robot/Selenium/Appium
- Có kinh nghiệm với Selenium hoặc Katalon hoặc các framework tương đương
- Hiểu biết tốt về quy trình kiểm thử, vòng đời kiểm thử
- Có các kiến thức sau là một lợi thế:
o Khung người máy
o Jenkins
o Làm quen với mô hình Agile/Scrum
o Biết sử dụng các công cụ cộng tác như JIRA, Confluence
- Có khả năng giao tiếp trực tiếp với khách hàng bằng tiếng Anh
- Thái độ giải quyết vấn đề
- Tinh thần đồng đội
1.2.2 Mô tả công việc
Tester thực hiện các công việc sau:
- Phân tích yêu cầu, đặc tả phần mềm để xây dựng test plan, test case tương ứng
- Tự động hóa test plan, test case thông qua các framework hỗ trợ (vd: Selenium, Robot, Katalon )
- Xử lý kế hoạch kiểm tra thủ công, trường hợp kiểm tra nếu được yêu cầu
- Tối ưu hóa kịch bản thử nghiệm tự động hóa
- Phối hợp với các nhà phát triển để cải thiện khả năng sử dụng của sản phẩm
- Luôn cập nhật các công nghệ tự động hóa mới nổi
1.2.3 Mức lương tại thị trường Việt Nam
- Hiện nay ở Việt Nam mức lương nghề tester dao động từ 8 – 25 triệu đồng/tháng
Tuy nhiên, mức lương của tester phụ thuộc vào nhiều yếu tố như kinh nghiệm, trình
độ chuyên môn, cấp bậc và khu vực làm việc Theo đó dưới đây là bảng khảo sát mức lương nghề tester theo cấp bậc
Trang 156
Senior Tester 12-20 triệu đồng/tháng
Tester Leader 20-30 triệu đồng/tháng
Tester Manager 30-50 triệu đồng/tháng
(Bảng 1.1 Bảng mức lương của Tester theo từng cấp bậc)
- Đi theo những quy luật chung của mọi ngành, mức lương của người kiểm thử
cũng phụ thuộc một phần vào địa điểm họ làm việc Cụ thể thì thành phố lớn có mức thu nhập bình quân đầu người cao hơn vùng nông thôn
Hà Nội khoảng 15-20 triệu đồng/tháng
Hồ Chí Minh tối thiểu khoảng 14 triệu đồng/tháng Các tỉnh thành khác trung bình từ 8-25 triệu/tháng
(Bảng 1.2 Bảng mức lương của Tester theo khu vực)
1.2.4 Con đường phát triển
- Tester có thể phát triển sự nghiệp của mình trong nhiều lĩnh vực liên quan đến công nghệ thông tin Dưới đây là một số nghề nghiệp liên quan đến con đường phát triển của tester:
+ Test Automation Engineer: Tester có thể trở thành một Test Automation
Engineer, người có trách nhiệm tạo ra các kịch bản tự động hóa để kiểm thử phần
Trang 167
mềm Test Automation Engineer cần có kiến thức về lập trình và các công cụ tự động hóa kiểm thử phần mềm
+ Quality Assurance Manager: Tester có thể trở thành một Quality Assurance
Manager, người quản lý hoạt động kiểm thử phần mềm và đảm bảo chất lượng sản phẩm Quality Assurance Manager cần có các kỹ năng quản lý dự án và kinh nghiệm trong việc đào tạo và lãnh đạo các nhân viên kiểm thử phần mềm
+ Technical Support Engineer: Tester có thể trở thành một Technical Support
Engineer, người hỗ trợ khách hàng trong việc sử dụng sản phẩm phần mềm Technical Support Engineer cần có kiến thức về phần mềm và kỹ năng giao tiếp tốt
để giải quyết các vấn đề của khách hàng
+ Software Developer: Tester có thể học thêm về lập trình và trở thành một
Software Developer, người phát triển phần mềm Tester có kiến thức về kiểm thử phần mềm và có thể áp dụng kiến thức này trong việc phát triển phần mềm
+ Business Analyst: Tester có thể trở thành một Business Analyst, người phân tích
yêu cầu khách hàng và đưa ra giải pháp kỹ thuật để giải quyết các vấn đề kinh doanh Business Analyst cần có các kỹ năng phân tích và giao tiếp tốt
Trang 178
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT 2.1 Tổng quan về kiểm thử phần mềm
2.1.1 Giới thiệu về kiểm thử phần mềm
Kiểm thử phần mềm là một phương pháp để kiểm tra xem sản phẩm phần mềm thực
tế có phù hợp với yêu cầu mong đợi hay không và để đảm bảo rằng sản phẩm phần mềm không có lỗi Nó liên quan đến việc thực thi các thành phần phần mềm/hệ thống bằng cách sử dụng các công cụ thủ công hoặc tự động để đánh giá một hoặc nhiều thuộc tính quan tâm
2.1.2 Mục tiêu của kiểm thử phần mềm
- Tìm các bug phát sinh do dev tạo ra khi code, để ngăn ngừa lỗi
- Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng
- Đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu kinh doanh và người sử dụng
- Để đạt được sự tín nhiệm của khách hàng bằng cách cung cấp cho họ một sản phẩm chất lượng
2.1.3 Nguyên tắc kiểm thử
+ Kiểm thử càng sớm càng tốt
+ Lỗi thường phân bổ tập trung
+ Nghịch lý thuốc trừ sâu
+ Kiểm thử phụ thuộc vào ngữ cảnh
+ Quan niệm sai lầm về việc “hết lỗi”
+ Kiểm thử chứng minh sự hiện diện của lỗi
2.1.4 Phân biệt Error / Fault / Failure
- Error: Là hành động của con người dẫn đến kết quả sai
- Fault: Trạng thái không mong muốn của phần mềm, kết quả của nhiều defect tạo thành
- Failure: Thất bại là sự sai lệch của toàn bộ phần mềm so với kết quả mong đợi của
nó
Trang 182.1.6 Phân biệt QA và QC:
a Quality Assurance – (Đảm bảo chất lượng): là một tập hợp các hoạt động cần thiết
có kế hoạch và có hệ thống để mang lại sự tin cậy đầy đủ rằng các sản phẩm và dịch
vụ sẽ phù hợp với các yêu cầu cụ thể và đáp ứng nhu cầu của người dùng
b Quality Control – (Kiểm soát chất lượng): là quá trình so sánh chất lượng sản phẩm với các tiêu chuẩn hiện hành và hành động được thực hiện khi không đạt tiêu chuẩn
2.2 Vòng đời phát triển phần mềm (SDLC)
2.2.1 Định nghĩa
- Software Development Life Cycle – Vòng đời phát triển phần mềm là một chuỗi các hoạt động được thực hiện để tạo ra 1 sản phẩm hoặc phần mềm SDLC có 6 giai đoạn:
+ Lập kế hoạch, phân tích yêu cầu: BA thực hiện khảo sát chi tiết yêu cầu của khách hàng để tạo ra tài liệu đặc tả yêu cầu
+ Thiết kế: Designer thực hiện thiết kế và tổng hợp vào các tài liệu thiết kế như: thiết
kế tổng thể, thiết kế module, thiết kế CSDL
+ Phát triển: Developer thực hiện lập trình dựa theo tài liệu giải pháp và thiết kế đã được duyệt Kết quả đầu ra là Source Code
+ Kiểm thử: Tester tạo nên kịch bản kiểm thử (viết test case) theo tài liệu đặc tả yêu cầu, thực hiện kiểm thử và cập nhật kết quả vào kịch bản kiểm thử, log lỗi trên các tool quản lý lỗi Kết quả đầu ra là test case, lỗi trên quản lý lỗi hệ thống
+ Triển khai: Triển khai sản phẩm cho khách hàng Kết quả đầu ra là biên bản triển khai với khách hàng
Trang 1910
+ Bảo trì: Khi khách hàng bắt đầu sử dụng hệ thống đã phát triển thì các vấn đề thực tế sẽ xuất hiện, cần được giải quyết theo thời gian Quá trình này trong đó việc chăm sóc được thực hiện đối với sản phẩm đã phát triển được gọi là bảo trì
2.2.2 Các mô hình phổ biến của SDLC
2.2.2.1 WaterFall Model
a Định nghĩa: Mô hình Waterfall hay còn gọi là mô hình thác nước Đây là mô
hình đầu tiên của SDLC – mô hình Waterfall là một phương pháp quản lý dự án dựa trên quy trình thiết kế tuần tự và liên tiếp
b Các giai đoạn: gồm 6 giai đoạn sau
+ Giai đoạn yêu cầu: Nhóm thực hiện tìm kiếm các yêu cầu liên quan đến dự án để nắm được tất cả các yêu cầu
+ Giai đoạn thiết kế: Nhóm tạo ra thiết kế cho sản phẩm để giải quyết mọi yêu cầu, ràng buộc và mục tiêu thiết kế Một bản thiết kế điển hình sẽ được hoàn thành một cách càng cụ thể càng tốt
+ Giai đoạn thực hiện: Dựa theo thiết kế để code tạo ra các chương trình Bên cạnh
đó ở giai đoạn này các DEV sẽ tiến hành tích hợp code để hoàn thiện sản phẩm Trong giai đoạn này sẽ tạo ra các chương trình
+ Giai đoạn kiểm thử: Các bộ phận của sản phẩm được kiểm tra và tích hợp lại với nhau để thử nghiệm Toàn bộ hệ thống được kiểm tra để tìm ra lỗi và đảm bảo các mục tiêu thiết kế
+ Giai đoạn triển khai: Sản phẩm được chuyển giao đến cho KH
+ Giai đoạn bảo trì: Là một khoảng thời gian giám sát ngắn Trong đó nhóm dự án giải quyết các vấn đề của khách hàng Đối với các dự án phần mềm, điều này thường
có nghĩa phát hành các bản vá và cập nhật để sửa vấn đề
2.2.2.2 V Model:
a Định nghĩa: V Model – Mô hình chữ V hay còn gọi là mô hình xác minh và xác
thực, đây là sự mở rộng của mô hình thác nước Không giống như mô hình thác nước, ở mô hình chữ V, tương ứng với một giai đoạn kiểm thử là một giai đoạn phát triển phần mềm, thử nghiệm trong mô hình chữ V được thực hiện song song với chu
kỳ phát triển phần mềm
b Các giai đoạn: V Model bao gồm 2 giai đoạn song hành với nhau bao gồm
+ Giai đoạn xác thực
• Phân tích yêu cầu: Trong giai đoạn này, tất cả các thông tin cần thiết được thu thập
và phân tích Các hoạt động xác minh bao gồm xem xét các yêu cầu
Trang 20• Viết mã: Quá trình phát triển mã được thực hiện trong giai đoạn này
+ Giai đoạn xác minh
• Kiểm thử đơn vị: được thực hiện bằng cách sử dụng các trường hợp kiểm thử đơn
vị được thiết kế và được thực hiện trong giai đoạn thiết kế mức thấp Kiểm thử đơn
vị được thực hiện bởi chính nhà phát triển
• Kiểm thử tích hợp: Kiểm thử tích hợp là kiểm thử được thực hiện trên các mô-đun tích hợp Nó được thực hiện bởi những người thử nghiệm
• Kiểm thử hệ thống: Trong giai đoạn này, toàn bộ hệ thống được kiểm tra, toàn bộ chức năng của hệ thống được kiểm tra
• Kiểm tra chấp nhận: được liên kết với giai đoạn Phân tích yêu cầu và được thực hiện trong môi trường của khách hàng
2.2.2.3 Agile Model:
- Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển
lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt và được xem như là sự cải tiến so với những mô hình cũ như mô hình “Thác nước (waterfall)” hay “CMMI” Trong Agile Model có nhiều frameworks nhưng nổi tiếng nhất là Frameworks Scrum được trình bày ngay mục dưới đây
Trang 2112
2.2.2.4 Scrum Methodology:
(Hình 2.1 Mô hình Scrum)
a Định nghĩa: Scrum là một phương pháp Agile để phát triển sản phẩm, đặc biệt là
phát triển phần mềm, quy trình này cho phép đội dự án phát triển phần mềm tập trung vào việc cung cấp các giá trị/ phần mềm chuyển giao đến cho khách hàng
trong thời gian ngắn nhất
b Các vai trò trong Scrum:
+ Product Owner: là người chịu trách nhiệm về thành công của dự án hoặc của sản phẩm Họ sẽ tập trung vào khía cạnh kinh doanh, khía cạnh khách hàng và nhu cầu của thị trường, sau đó thiết lập các ưu tiên cho công việc để đội phát triển tiến hành + Scrum master: là người đảm bảo các Sprint được thực hiện đúng mục đích, bảo
vệ nhóm và loại bỏ các chướng ngại vật Họ sẽ làm việc với các team, PO và các bên liên quan khi những người này tham gia vào quy trình Scrum
+ Development team: Đội phát triển chính là những người thực hiện xây dựng sản phẩm, hoàn thành những thứ cần được chuyển giao tới khách hàng
c Các cuộc họp trong Scrum:
- Sprint Planning Meeting: Một Sprint bắt đầu bằng cuộc họp Sprint planning
meeting để xác định mục tiêu Sprint và lên kế hoạch cho công việc cần hoàn thành
- Daily scrum: diễn ra mỗi ngày trong 15 phút Trong cuộc họp này, mỗi thành viên
của sự phát triển đã trả lời ba câu hỏi:
+ Hôm qua mình đã làm gì?
+ Hôm nay tôi làm gì?
+ Có trở ngại nào ngăn cản tôi hoàn thành công việc không?
Trang 2213
- Sprint Review: Cuộc họp diễn ra khi Sprint sắp kết thúc Đây là cơ hội để nhóm
thể hiện công việc đã hoàn thành, thu thập phản hồi và điều chỉnh kế hoạch tương lai của họ Cuộc họp được giới hạn thời gian trong bốn giờ cho 1 Sprint
- Sprint retrospective: nhóm thảo luận về những gì diễn ra tốt đẹp và những gì
không Dựa trên phản hồi và phản ánh này, nhóm tìm cách cải thiện hoặc sửa đổi trong lần chạy nước rút tiếp theo để nâng cao hiệu quả Giúp thúc đẩy học tập và
phát triển không liên tục
2.3 Các loại kiểm thử phần mềm:
2.3.1 Kiểm thử thủ công (Manual Testing):
- Manual testing là một loại kiểm thử phần mềm trong đó người kiểm tra thực hiện chạy test case một cách thủ công mà không dùng bất cứ một công cụ tự động nào
- Là kiểu test nguyên thủy nhất trong các loại kiểm tra giúp tìm ra lỗi trong hệ thống phần mềm
- Ưu điểm:
+ Nhận phản hồi trực quan nhanh chóng và chính xác
+ Ít tốn kém vì không cần tốn chi phí cho các công cụ và quy trình tự động
+ Khi thực nghiệm có sự thay đổi nhỏ thì Manual Testing có thể kiểm tra lại nhanh chóng hơn
2.3.2 Kiểm thử tự động (Automation Testing):
- Là một kỹ thuật kiểm thử phần mềm thực hiện bằng cách sử dụng các công cụ phần mềm kiểm thử tự động đặc biệt để thực hiện bộ trường hợp kiểm thử Người kiểm thử sử dụng các công cụ, script và phần mềm để thực hiện những trường hợp kiểm thử
- Ưu điểm:
+ Độ tin cậy cao hơn, có khả năng tái sử dụng tốt hơn và có khả năng lặp
+ Tốc độ test nhanh hơn nhiều so với Manual vì được hỗ trợ bởi công cụ
+ Chi phí cho nhân sự thấp
Trang 2314
2.4 Các phương pháp kiểm thử phần mềm
2.4.1 Static Testing (Kiểm thử tĩnh)
a Định nghĩa: là một kỹ thuật kiểm thử phần mềm được sử dụng để kiểm tra các
lỗi trong ứng dụng phần mềm mà không cần thực thi mã Kiểm thử tĩnh được thực hiện để tránh lỗi ở giai đoạn phát triển ban đầu vì việc xác định lỗi và giải quyết lỗi
sẽ dễ dàng hơn
b Lợi ích của kiểm thử tĩnh:
- Khi áp dụng sớm vào vòng đời, có khả năng xác định sớm những defect trước khi thực hiện thử động Ngăn chặn được những lỗi trong những giai đoạn sau từ đó tiết kiệm được chi phí cho dự án
- Phát hiện ra những lỗi mà kiểm thử tự động không tìm ra được Giúp giảm thời gian và chi phí cho những giai đoạn test sau này, tăng hiệu suất phát triển
2.4.2 Dynamic Testing (Kiểm thử động)
a Định nghĩa: là một phương pháp kiểm thử phần mềm được sử dụng để kiểm tra
hành vi động của mã phần mềm
b Lợi ích của kiểm thử động:
- Phát hiện ra những lỗi phức tạp, khó khăn mà kiểm thử tĩnh chưa phát hiện ra được
- Trong quá trình kiểm tra, kiểm thử động thực thi phần mềm từ đầu đến cuối, chắc chắn rằng phần mềm không có lỗi, do đó làm tăng chất lượng của sản phẩm và dự
án
- Kiểm tra khả năng trở thành một công cụ cần thiết để phát hiện ra bất kỳ mối đe dọa tấn công bảo mật nào
2.4.3 White box Testing (Kiểm thử hộp trắng)
a Định nghĩa: Là một phương pháp kiểm thử phần mềm trong đó tester sẽ kiểm tra
về mặt cấu trúc nội bộ/ thiết kế bên trong của phần mềm Chính vì vậy, đòi hỏi người tester phải có kiến thức về lập trình và kiến thức thực thi code
Trang 24+ Các lập trình viên có thể tự kiểm tra nên giúp tối ưu việc mã hoá
+ Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối
đa nhất
- Nhược điểm của kiểm thử hộp trắng:
+ Đòi hỏi người kiểm định phải có kiến thức chuyên môn cao và nhiều năm kinh nghiệm Bên cạnh đó, phải nắm vững kiến thức về phần mềm để có thể thực hiện các bài kiểm tra phức tạp
+ Vì phương pháp thử nghiệm này liên quan chặt chẽ với ứng dụng đang được test,
nên các công cụ để phục vụ cho mọi loại triển khai có thể không sẵn có
2.4.4 Black box Testing (Kiểm thử hộp đen)
a Định nghĩa: Là một phương pháp kiểm thử phần mềm được thực hiện mà không
biết được cấu tạo bên trong của phần mềm, là cách mà các tester kiểm tra xem hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong của cái hộp Chỉ dựa vào các yêu cầu và thông tin đặc tả chức năng của thành phần phần mềm tương ứng
b Ưu và nhược điểm:
- Nhược điểm:
+ Nhiều dự án không có thông số rõ ràng thì việc thiết kế test case rất khó và do đó khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào, và thiếu cả thời gian cho việc tập hợp này
Trang 2516
2.5 Các cấp độ kiểm thử phần mềm
2.5.1 Unit Testing (Kiểm thử đơn vị)
a Định nghĩa: Là cấp độ đầu tiên trong 4 cấp độ kiểm thử phần mềm Ở cấp độ
này, mỗi đơn vị là 1 dòng code, 1 chức năng hay 1 quy trình riêng lẻ Kiểm thử đơn
vị được thực hiện trong quá trình phát triển ứng dụng Lỗi ở level này thường được sửa ngay sau khi phát hiện mà không cần phải lưu lại và quản lý như các cấp độ kiểm thử khác Sử dụng phương pháp kiểm thử hộp trắng để kiểm tra
b Mục đích:
- Để cải thiện chất lượng mã, Unit Test tập trung vào nhiều khía cạnh của chức năng
- Xác định bất kỳ hạn nào thiếu có thể xảy ra, giúp giảm lỗi và cải thiện chất lượng
- Có tác dụng lớn đến năng suất làm việc như đảm bảo tốc độ, chất lượng, tăng sự
tự tin khi hoàn thành công việc
2.5.2 Integration Testing (Kiểm thử tích hợp)
a Định nghĩa: Là loại kiểm thử trong đó các module phần mềm được tích hợp một
cách logic và kiểm thử theo nhóm Một dự án phần mềm điển hình bao gồm nhiều module phần mềm, được mã hóa bởi các lập trình viên khác nhau
b Mục đích:
- Các module được thiết kế bởi một nhà phát triển phần mềm riêng lẻ mà sự hiểu biết và logic lập trình của họ có thể khác với các lập trình viên khác Vì vậy, kiểm tra tích hợp trở nên cần thiết để kiểm tra tính thống nhất giữa các module trong phần mềm
Trang 2617
- Tại thời điểm phát triển module, có nhiều cơ hội thay đổi yêu cầu của khách hàng Các yêu cầu mới này có thể không được kiểm tra đơn vị Do đó Kiểm tra tích hợp
hệ thống trở nên cần thiết
2.5.3 System Testing (Kiểm thử hệ thống)
a Định nghĩa: Là kiểm thử toàn bộ chức năng và giao diện của hệ thống Được thực hiện sau kiểm thử đơn vị và kiểm thử tích hợp
2.5.4 Acceptance Testing (Kiểm thử chấp nhận)
a Định nghĩa: Là kiểm thử được thực hiện để xác định xem hệ thống phần mềm có
đáp ứng các đặc tả hay không Bằng cách kiểm tra hành vi của hệ thống đối với dữ liệu thực tế, thử nghiệm chấp nhận giúp xác định xem hệ thống có đáp ứng các tiêu chí và yêu cầu của khách hàng hay không
b Mục đích: Đây là bước cuối cùng trước khi sản phẩm được giao đến tay khách
hàng nên việc kiểm tra lại lần cuối cùng là rất quan trọng
2.6 Các kỹ thuật kiểm thử
2.6.1 Specification-based techniques (Kỹ thuật dựa trên đặc điểm kỹ thuật)
a Định nghĩa: Nhóm kỹ thuật cơ sở mô tả đặc tả sử dụng thông tin từ các tài liệu
yêu cầu, Thiết kế và thông số kỹ thuật để đưa ra các kỹ thuật kiểm tra tính toán thủ thuật
b Phân loại:
- Phân vùng tương đương (Equivalence Partitioning): là kỹ thuật sẽ phân loại các đầu vào, vào các phân vùng đó theo một logic nhất định Từ đó, người kiểm tra sẽ chọn một đầu vào từ mỗi phân vùng để thiết kế và thực hiện trường hợp kiểm tra này Nếu đầu vào hợp lệ hoặc không hợp lệ, phân vùng hợp lệ hoặc không hợp lệ
- Phân tích giá trị biên (Boundary Value Analysis): được sử dụng để phát hiện lỗi trong các giá trị biên Nếu đầu vào nằm trong giá trị biên thì trường hợp thử nghiệm
Trang 27- Chuyển đổi trạng thái (State transition): người kiểm tra bắt buộc phải phân tích phần mềm theo một trình tự định sẵn nhất Trình tự này chính là thứ tự chuyển trạng thái của phần mềm trong sơ đồ chuyển trạng thái Bảo đảm phần mềm chạy đúng các bước, đúng theo như nhiệm vụ của doanh nghiệp ra
2.6.2 Experience - based techniques (Kỹ thuật dựa trên kinh nghiệm)
a Định nghĩa:
- Nhóm kỹ thuật kiểm thử này phụ thuộc vào kiến thức và năng lực của người kiểm thử Kiến thức và kinh nghiệm của tester sẽ là cơ sở để thiết kế test case Do đó, chất lượng của các trường hợp thử nghiệm dựa trên kinh nghiệm sẽ hoàn toàn phụ thuộc vào người thử nghiệm
b Phân loại: Nhóm kỹ thuật này được chia thành 2 loại:
- Thử nghiệm thăm dò (Exploratory testing): Đây là kỹ thuật kiểm tra không cần chuẩn bị hay lịch trình cụ thể Khi thực hiện kiểm thử thăm dò, người kiểm thử sẽ vừa phân tích phần mềm, vừa thiết kế và thực hiện kiểm thử Ngoài ra, việc lập kế hoạch và lưu kết quả cũng linh hoạt trong quá trình thử nghiệm
- Đoán lỗi sai (Error Guessing): Đoán lỗi được sử dụng để dự đoán các lỗi tiềm ẩn dựa trên kiến thức của người kiểm tra Kiến thức này thường là về hoạt động trước
đó của phần mềm, các lỗi có khả năng xuất hiện, các lỗi mà người kiểm thử đã phát hiện ra
Trang 2819
CHƯƠNG 3: ĐẶC TẢ WEBSITE NOPCOMMERCE
3.1 Giới thiệu Tổng quát về Website NopCommerce demo
- NopCommerce là một trang web thương mại điện tử minh họa cho phần mềm quản
lý cửa hàng trực tuyến nopCommerce Trang web này cung cấp các sản phẩm và dịch vụ khác nhau cho người dùng mua sắm trực tuyến, bao gồm các sản phẩm điện
tử, phần mềm, điện thoại di động và quà tặng Ngoài ra, trang web cũng có các tính năng như đăng ký, đăng nhập, lưu giỏ hàng và danh sách mong muốn, và cung cấp các thông tin hữu ích như hướng dẫn sử dụng và chính sách bảo mật Trang web được thiết kế đơn giản, dễ sử dụng và có thể tùy chỉnh để phù hợp với nhu cầu của người dùng
- Link website: https://demo.nopcommerce.com/
(Hình 3.1 Giao diện homepage của trang web NopCommerce)
Trang 2920
3.2 Sơ đồ Usecase tổng quát của hệ thống
3.2.1 Sơ đồ Usecase tổng quát
(Hình 3.2 Use Case của trang web NopCommerce)
3.2.2 Vai trò của tác nhân
User + Khi có nhu cầu mua sắm, tìm hiểu thông tin về các sản phẩm phục vụ
nhu cầu của người dùng
+ User có những chức năng sau:
- Đăng nhập
- Quản lý thông tin cá nhân
- Đặt hàng
- Quản lý đơn hàng
Trang 3021
Guest + Khi có nhu cầu mua sắm, tìm hiểu thông tin về các sản phẩm phục vụ
nhu cầu của người dùng
+ Guest có những chức năng sau:
- Đăng ký
- Tìm kiếm sản phẩm
- Quản lý danh sách sản phẩm yêu thích
- Quản lý giỏ hàng
Admin + Là người quản trị hệ thống, có quyền truy cập và quản lý các chức
năng quan trọng của trang web
+ Admin có những chức năng sau:
- Đăng nhập
- Quản lý sản phẩm
- Quản lý đơn hàng
- Quản lý tài khoản người dùng
(Bảng 3.1 Vai trò của các tác nhân trong trang web NopCommerce)
Trong phạm vi bài báo cáo này em sẽ tiến hành phân tích và thực hiện kiểm thử cho các use case sau:
- Use case “Đăng ký” cho actor Guest
- Use case “Đăng nhập” cho actor User
- Use case “Quản lý giỏ hàng” cho actor Guest
⇨ Dưới đây là nội dung phân tích nghiệp vụ chi tiết cho các use case đã hoàn thành kiểm thử
Trang 3122
3.3 Workflow của hệ thống
3.4 Phân tích Use case “Đăng ký”
3.4.1 Sơ đồ Use case tổng quát cho chức năng “Đăng ký”
3.4.2 Đặc tả yêu cầu cho chức năng “Đăng ký”
+ Tác nhân: Guest
+ Điều kiện tiên quyết: Người dùng truy cập vào website nopcommerce, tại màn
hình đăng ký
+ Mô tả khái quát: Use case này được thực hiện khi người dùng chưa có tài khoản,
người dùng sẽ tiến hàng click vào “Register” để tiến hành đăng ký tài khoản người dùng
+ Mô tả chi tiết luồng xử lý chính:
- Bước 1: Người dùng click vào “Register”
(Hình 3.4 Click vào Textbox “Register”) (Hình 3.3 Workflow của trang web NopCommerce)
Trang 32- Nếu người dùng bỏ trống hệ thống sẽ hiển thị thông báo “First name is required”
Last name X - Người dùng phải điền dữ liệu vào ô
Textbox
- Last name không được quá 25 ký tự Nếu nhập vượt quá 25 ký tự, hệ thống đưa ra thông báo "The length of field 'Last name' must be from 1 to 25 characters"
- Nếu người dùng bỏ trống hệ thống sẽ hiển thị thông báo “Last name is required”
Date of birth
Email X - Email phải đúng format string@domain
- Nếu Email không đúng format hệ thống hiển thị thông báo “Wrong email”
- Nếu Email bỏ trống, hệ thống hiển thị thông báo “Email is required”
- Nếu nhập Email đã đăng ký thì hệ thống hiển thị thông báo “The specified email already exists”
Trang 3324
Company
name
Password X - Password phải có ít nhất 6 ký tự
- Nếu Password ít hơn 6 ký tự hệ thống sẽ hiển thị thông báo “Password must meet
the following rules: must have at least 6 characters “
- Nếu Password bỏ trống hệ thống sẽ hiển thị thông báo“Password is required”
Confirm
password
X - Confirm password phải có ít nhất 6 ký tự
- Confirm password phải đặt giống với Password
- Nếu Confirm password không giống với password thì hệ thống hiển thị thông báo
“The password and confirmation password do not match”
- Nếu Confirm password ít hơn 6 ký tự hệ thống sẽ hiển thị thông báo “Password must meet the following rules: must have at least 6 characters”
- Nếu Confirm password bỏ trống hệ thống
sẽ hiển thị thông báo “Password is
required”
(Bảng 3.2 Bảng đặc tả chức năng Đăng ký)
- Bước 3: Sau khi nhập đủ các trường của hệ thống thì người dùng tiến hành click vào button “REGISTER” để tiến hành đăng ký tài khoản người dùng Và hoàn tất đăng ký
Trang 3425
(Hình 3.5 Click vào button “Register”)
- Sau khi đăng ký thành công hệ thống sẽ hiển thị màn hình đăng ký thành công
(Hình 3.6 Màn hình đăng ký thành công)
+ Mô tả luồng ngoại lệ:
- Người dùng có thể đăng ký nếu chỉ nhập thông tin vào các trường bắt buộc
- Nếu đăng ký không thành công thì hệ thống sẽ hiển thị thông báo lỗi và yêu cầu người dùng nhập lại thông tin
- Nếu người dùng nhập email trùng với email đã đăng ký trước đó thì hệ thống sẽ báo lỗi và yêu cầu nhập lại
- Lỗi kết nối: Nếu trang web gặp sự cố kết nối, người dùng không thể đăng ký
Trang 3526
3.5 Phân tích Use case “Đăng nhập”
3.5.1 Sơ đồ Use case tổng quát cho chức năng “Đăng nhập”
3.5.2 Đặc tả yêu cầu cho chức năng “Đăng nhập”
+ Tác nhân: User
+ Điều kiện tiên quyết: Người dùng truy cập vào website nopcommerce, tại màn
hình Login
+ Mô tả khái quát: Use case này được thực hiện khi người dùng đã có tài khoản
Người dùng tiến hành nhập Email và Password đã đăng ký trước đó
+ Mô tả chi tiết luồng xử lý chính:
- Bước 1: Khi người dùng đã đăng ký thành công hoặc đã có tài khoản, người dùng tiến hành click vào “Log in” để đăng nhập
(Hình 3.7 Click vào Textbox “Log In”)
- Bước 2: Người dùng tiến hành click vào ô textbox Email và Textbox Password để điền thông tin đã đăng ký trước đó Sau đó tiến hành nhập Email và password đúng như đã đăng ký trước đó