lOMoAR cPSD| 46836766
TRƯỜNG ĐẠI HỌC KINH DOANH VÀ CÔNG NGHỆ HÀ NỘI
VIỆN SAU ĐẠI HỌC
BÁO CÁO BÀI TẬP LỚN
Môn: Kiểm thử và chất lượng phần mềm Đề tài:
KIỂMTHỬPHẦNMỀMBÁNHÀNG Giảng viên hướng dẫn : Nguyễn Như Sơn Sinh viên thực hiện : Nguyễn Thái Lai Trần Đức Hiếu Nguyễn Văn Bình Nhóm: 1 Lớp : K17.14 lOMoAR cPSD| 46836766 MỞ ĐẦU
Lý do chọn ề tài:
Trong thời ại số hóa và công nghệ thông tin phát triển mạnh mẽ như hiện nay,
việc sử dụng phần mềm quản lý bán hàng ã trở thành một phần không thể thiếu
trong hoạt ộng kinh doanh của nhiều doanh nghiệp. Phần mềm bán hàng không
chỉ giúp quản lý quy trình bán hàng hiệu quả mà còn tối ưu hóa việc tương tác
với khách hàng, theo dõi hàng tồn kho, và nắm bắt thông tin quan trọng ể ưa ra
quyết ịnh kinh doanh hợp lý. Điều này làm cho việc kiểm thử phần mềm bán
hàng trở nên vô cùng quan trọng.
Lý do chọn ề tài "Kiểm thử phần mềm bán hàng" xuất phát từ sự nhận thấy về
tầm quan trọng của phần mềm bán hàng trong việc ảm bảo hoạt ộng kinh doanh
hiệu quả và cung cấp dịch vụ tốt cho khách hàng. Chúng ta không thể bỏ qua sự
phụ thuộc vào phần mềm trong kinh doanh hiện ại, và bất kỳ sự cố hay lỗi phát
sinh trong phần mềm bán hàng có thể gây thiệt hại nghiêm trọng ến doanh
nghiệp và danh tiếng của họ.
Trong bài viết này, chúng ta sẽ khám phá các khía cạnh quan trọng của việc
kiểm thử phần mềm bán hàng. Chúng ta sẽ tìm hiểu về các phương pháp và quy
trình kiểm thử, những thách thức phổ biến trong quá trình này, và tại sao nó là
một phần quan trọng trong việc ảm bảo chất lượng của phần mềm bán hàng. 2 lOMoAR cPSD| 46836766
Bài viết sẽ không chỉ giúp bạn hiểu rõ hơn về tầm quan trọng của kiểm thử phần
mềm bán hàng mà còn cung cấp thông tin hữu ích ể thực hiện quy trình kiểm
thử một cách hiệu quả, ảm bảo rằng phần mềm bán hàng của bạn hoạt ộng ổn
ịnh và áp ứng úng nhu cầu kinh doanh.
Đối tượng và phạm vi nghiên cứu:
Đối tượng chính của nghiên cứu này là phần mềm Winta Sales. Winta Sales là
một ứng dụng phần mềm ược thiết kế ể quản lý quá trình bán hàng và các hoạt
ộng liên quan tới doanh nghiệp. Nghiên cứu sẽ tập trung vào việc kiểm thử, ánh
giá và cải tiến phần mềm này. Đối tượng nghiên cứu bao gồm cả phiên bản hiện
tại của Winta Sales và bất kỳ phiên bản cập nhật hoặc mở rộng nào của nó.
Phương pháp nghiên cứu:
Phương pháp nghiên cứu kiểm thử hộp en (Black-box Testing) là một trong
những phương pháp quan trọng ể ảm bảo tính chức năng và hiệu năng của phần
mềm Winta Sales mà không yêu cầu kiến thức về cấu trúc bên trong của phần mềm
Kiểm thử hộp en giúp ảm bảo tính chức năng và hiệu năng của Winta Sales.
Điều này bao gồm kiểm tra các kịch bản sử dụng thông qua giao diện người
dùng và kiểm tra tương tác với hệ thống.
Trong quá trình thực hiện ồ án, do thời gian cũng như trình ộ của em còn có
những hạn chế nhất ịnh nên không thể tránh khỏi những sai sót. Rất mong nhận 3 lOMoAR cPSD| 46836766
ược sự góp ý của thầy và các bạn ể ồ án hoàn thiện hơn. Nhóm em xin chân
thành cảm ơn sự hướng dẫn, và giúp ỡ tận tình của thầy giáo TS. Nguyễn Như
Sơn ã giúp ỡ nhóm em trong quá trình học tập cũng như trong quá trình làm bài tập lớn.
CHƯƠNG 1:CÁC KIẾN THỨC CƠ BẢN
1. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm (software testing) là một quá trình bao gồm nhiều hoạt ộng
nhằm ánh giá chất lượng các sản phẩm phần mềm và giảm thiểu rủi ro do lỗi
gây ra trong quá trình vận hành khi ưa vào sử dụng thực tế. Các hoạt ộng kiểm
thử này bao gồm các hoạt ộng xem xét ánh giá (review) tài liệu, các bản thiết
kế, và bao gồm mã nguồn (source code), các hoạt ộng này trong thực tế hay gọi
là “review” (rà soát). Và các hoạt ộng kiểm thử ược thực hiện trên sản phẩm
(nếu bạn gặp từ “dynamic testing”).
Dưới ây là một số hoạt ộng kiểm thử cơ bản:
● Lập kế hoạch kiểm thử (test planning)
● Phân tích kiểm thử (test analysis)
● Thiết kế các trường hợp kiểm thử (test design)
● Thực thi kiểm thử (test execution)
● Báo cáo kết quả kiểm thử (test reporting)
2. Loại hình kiểm thử
2.1. Functional Testing (Kiểm thử chức năng) 4 lOMoAR cPSD| 46836766
Functional Testing có thể bao gồm nhiều hình thức kiểm thử khác nhau, như:
Unit Testing (Kiểm thử ơn vị), Integration Testing (Kiểm thử tích hợp), System
Testing (Kiểm thử hệ thống) và một vài hình thức kiểm thử khác nữa.
Kiểm thử chức năng có thể ược hiểu là một bài test xem phần mềm có thực hiện
úng chức năng hay không và ược thực hiện trong mọi mức kiểm thử.
Functional Testing có thể ược thực hiện bằng hai phương pháp sau:
● Kiểm thử dựa trên yêu cầu: Đây là cách tiếp cận sử dụng chính
yêu cầu (requirement) ể thiết kế bài kiểm thử. Đồng thời, các
tester có thể sử dụng nội dung của yêu cầu ể phân chia những
phần cần hay không cần kiểm thử.
● Kiểm thử dựa trên bối cảnh thực tế: Có thể hiểu ây là cách tiếp
cận dựa trên các bước thực tế khách hàng sử dụng phần mềm.
Các use case sẽ trở nên hữu dụng trong quá trình kiểm thử phần mềm.
Functional Testing thường có 5 bước sau ây:
● Xác ịnh các function mà bạn muốn phần mềm sẽ thực hiện.
● Tạo các dữ liệu ầu vào dựa trên các tài liệu ặc tả kỹ thuật của các function.
● Xác ịnh các kết quả ầu ra dựa trên các tài liệu ặc tả kỹ thuật của các function.
● Thực hiện các trường hợp kiểm thử (Test Case) ● So sánh kết
quả thực tế và kết quả mong muốn. 5 lOMoAR cPSD| 46836766
2.2. Non-functional Testing (Kiểm thử phi chức năng)
Kiểm thử phi chức năng giống kiểm thử chức năng ở chỗ cả hai ều xuất hiện
trong mọi mức ộ kiểm thử.
Nếu như Functional Testing hướng tới việc test toàn thể chức năng hoặc một
chức năng cụ thể thì Non-functional Testing ược thực hiện nhằm trả lời câu hỏi:
“Phần mềm có hoạt ộng tốt không?”. Kiểm thử phi chức năng chú trọng nhiều
hơn vào những khía cạnh khác của phần mềm, như là ộ bảo mật và khả năng tải
của phần mềm ó, ví dụ như bao nhiêu người có thể ăng nhập cùng 1 lúc.
Kiểm thử phi chức năng bao gồm:
● Performance Testing (Kiểm thử hiệu năng)
● Load Testing (Kiểm thử khả năng chịu tải)
● Stress Testing (Kiểm thử áp lực)
● Usability Testing (Kiểm thử khả năng sử dụng)
● Maintainability Testing (Kiểm thử khả năng bảo trì)
● Reliability Testing (Kiểm thử ộ tin cậy)
● Portability Testing (Kiểm thử khả năng thích ứng)
2.3. Structural Testing (Kiểm thử cấu trúc)
Kiểm thử cấu trúc thường ược coi là một loại white box testing. Quá trình này
tập trung vào việc kiểm thử những gì ang diễn ra ở bên trong phần mềm hơn là
về chức năng của phần mềm ó. 6 lOMoAR cPSD| 46836766
Khi kiểm thử cấu trúc, các tester cần có hiểu biết về quá trình xây dựng và phát
triển của phần mềm này. Họ sẽ tập trung vào việc phần mềm thực hiện tác vụ
như thế nào, hơn là chỉ tập trung vào chức năng của phần mềm.
Cũng giống như hai Test Type trên, Structural Testing cũng có thể ược áp dụng
trong mọi mức ộ kiểm thử. Các Developer cũng có thể ứng dụng kiểm thử cấu
trúc trong quá trình kiểm thử thành phần hoặc các mức ộ thấp hơn trong kiểm thử thành phần.
2.4. Change-related Testing (Kiểm thử thay ổi)
Mục ích của kiểm thử thay ổi là ể kiểm tra xem phần mềm có vận hành trơn tru
sau những lần sửa lỗi hay không. Kiểm thử thay ổi gồm 2 loại chính: ●
Confirmation Testing (Kiểm thử xác nhận): Thường Confirmation Testing sẽ
diễn ra sau khi lỗi trong phần mềm ã ược xác nhận và ược sửa. Lúc này, vai trò
của Kiểm thử xác nhận là ể xem lỗi ã thực sự ược sửa hay chưa. Các tester sẽ
tiến hành bằng cách cho một input giống hệt ban ầu và test xem output có ra ược như mong muốn hay không.
● Regression Testing (Kiểm thử hồi quy): Mục ích của kiểm thử hồi quy ể
xác nhận rằng các thay ổi trong phần mềm hoặc môi trường không gây ra
bất lợi ngoài mong muốn và hệ thống vẫn áp ứng các yêu cầu. Kiểm thử
hồi quy ược thực hiện khi phần mềm thay ổi, do sửa lỗi hoặc do chức
năng mới. Việc thực thi Regression Testing cũng nên ược cân nhắc khi
môi trường xung quanh phần mềm có sự thay ổi.
3. Quy trình kiểm thử phần mềm 7 lOMoAR cPSD| 46836766
Về cơ bản, quy trình kiểm thử phần mềm gồm 6 giai oạn: Requirement Analysis
(Phân tích yêu cầu), Test Planning (Lập kế hoạch kiểm thử), Test Case
Development (Phát triển kịch bản kiểm thử), Environment Setup ( Thiết lập môi
trường kiểm thử), Test Execution (Thực hiện kiểm thử), Test Cycle Closure (Kết thúc chu kỳ kiểm thử).
3.1. Requirement Analysis (Phân tích yêu cầu)
Giai oạn ầu tiên của quy trình kiểm thử phần mềm là Requirement Analysis
(Phân tích yêu cầu). Trong giai oạn này, các tester sẽ phân tích tài liệu
Prototype (Tài liệu ặc tả yêu cầu) ược tạo trong Software Development Life
Cycle (Vòng ời phát triển phần mềm) ể kiểm tra các yêu cầu do khách hàng ưa ra.
Yêu cầu ược chia làm 2 dạng: Functional (Chức năng) và Non-Functional (Phi
chức năng). Yêu cầu về Functional sẽ mô tả tính năng còn Non-Functional sẽ
mô tả hiệu năng, tính bảo mật, tính hữu dụng của phần mềm. Trong quá trình
phân tích, nếu yêu cầu còn mơ hồ sẽ ược xem xét lại, tester ồng thời làm việc
với các bên liên quan ể làm rõ vấn ề. Cuối cùng, tester sẽ xác ịnh loại kiểm thử
sẽ dùng và ộ ưu tiên của các hoạt ộng kiểm thử, xác ịnh môi trường test cần chuẩn bị.
3.2. Test Planning (Lập kế hoạch kiểm thử)
Sau giai oạn một, tester tiến hành Lập kế hoạch kiểm thử ể kiểm tra xem phần
mềm có áp ứng các yêu cầu hay không. Kế hoạch kiểm thử là một tài liệu tổng
quan về việc kiểm thử dự án bao gồm những thông tin sau: 8 lOMoAR cPSD| 46836766
Phạm vi kiểm thử, hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực test.
Các chức năng/module cần ược kiểm tra; các công cụ và môi trường kiểm thử cần có.
Ai test chức năng nào? - Khi nào bắt ầu thực hiện viết và hoàn thành test case?
- Khi nào bắt ầu thực hiện và hoàn thành test?
3.3. Test Case Development (Phát triển kịch bản kiểm thử)
Sau khi có ược Test Plan, Tester bắt ầu xây dựng bộ Test Case dựa trên yêu cầu
của phần mềm. Test Case cần mô tả ược chi tiết dữ liệu ầu vào, hành ộng, kết
quả mong ợi ể xác ịnh một chức năng của ứng dụng phần mềm có hoạt ộng úng
hay không. Template của Test Case có nhiều trường hợp nhưng bắt buộc phải
có 5 mục chính: ID, mục ích kiểm thử, các bước thực hiện, kết quả mong ợi & kết quả thực tế.
Nếu sử dụng tool ể thực hiện test tự ộng (Automation testing) chức năng và giao
diện của sản phẩm, tester sẽ tạo thêm một kịch bản kiểm thử gọi là Test Script.
Test Script là bản hướng dẫn chi tiết ược viết bằng mã code nhằm hỗ trợ kiểm
thử những trường hợp nếu test thủ công bằng tay sẽ rất khó khăn.Xem thêm:
cách gửi hàng từ nhật về việt nam
Các Tester trong cùng một team sẽ review chéo Test Case của nhau tránh bỏ sót
những trường hợp test quan trọng. Một bộ Test Case chất lượng sẽ giúp ảm bảo
chất lượng sản phẩm, hạn chế lỗi và rủi ro nhất cho khách hàng. 9 lOMoAR cPSD| 46836766
3.4. Environment Setup (Thiết lập môi trường kiểm thử)
Thiết lập môi trường thử nghiệm là một hoạt ộng ộc lập và có thể ược bắt ầu
cùng với giai oạn phát triển kịch bản kiểm thử. Môi trường kiểm thử sẽ do
developers tạo ra ể deploy sản phẩm ã ược hoàn thiện về phần lập trình.
Sau khi thiết lập môi trường thử nghiệm, tester thực hiện nhanh Smoke Testing
(Kiểm thử khói) ể kiểm tra tính sẵn sàng của môi trường thử nghiệm ồng thời
tính ổn ịnh của bản build sản phẩm. Trường hợp xuất hiện lỗi như môi trường
không ổn ịnh hay bản build lỗi chức năng chính, tester sẽ báo lại developers sửa
ngay. Nếu môi trường và bản build ã ủ ổn ịnh ể tiến hành test chi tiết, tester sẽ
tiến hành giai oạn tiếp theo - Thực hiện kiểm thử.
3.5. Test Execution (Thực hiện kiểm thử)
Khi developers ã code và ưa sản phẩm lên môi trường kiểm thử, tester sẽ thực
thi dựa trên Test Case ã viết. Trong quá trình test, nếu phát hiện ra bug (lỗi) thì
tester sẽ log (viết) lên các tool quản lý lỗi. Bug của lập trình viên nào sẽ giao lại
cho người ấy xử lý. Khi nào developers fix bug xong, tester sẽ nhận lại và tiến hành kiểm thử.
Nếu lỗi ã ược sửa, tính năng hoạt ộng ổn ịnh, tester sẽ ổi trạng thái thành Close
Bug. Trường hợp lỗi vẫn chưa ược fix thành công, trạng thái sẽ ược ổi thành Re-
open ể developers thực hiện fix lại. Khi nào bug ược fix thành công mới ược
óng lại việc test tính năng ấy.
Trong cả quá trình kiểm thử phần mềm, tester ưu tiên kiểm tra chức năng chính
trước, chức năng phụ và giao diện sẽ thực hiện test sau. Quá trình kiểm thử phần
mềm bắt buộc phải tuân thủ thời gian ã ề ra, mọi người trong team ôn ốc nhau ể 10 lOMoAR cPSD| 46836766
kịp tiến ộ bàn giao sản phẩm. Cuối cùng, tester thực hiện làm báo cáo tùy theo
yêu cầu của dự án ể ánh giá việc kết thúc quy trình kiểm thử phần mềm.
3.6. Test Cycle Closure (Kết thúc chu kỳ kiểm thử)
Ở giai oạn cuối cùng, tester chuẩn bị báo cáo kết thúc kiểm thử, tổng hợp lại các
chỉ số trong quá trình test. Cả team phát triển sẽ ngồi họp ể ánh giá toàn bộ các
tiêu chí xác ịnh kiểm thử ã ủ hay chưa. Những tiêu chí này khác nhau tùy theo
từng dự án, thông thường bao gồm:
● Số lượng test case tối a ược thực thi Passed.
● Tỷ lệ lỗi giảm xuống dưới mức nhất ịnh.
● Deadline ược chốt từ giai oạn làm kế hoạch kiểm thử.
Quy trình kiểm thử phần mềm thường chỉ ược kết thúc khi sản phẩm ược bàn
giao cho khách hàng. Ngoài ra, hoạt ộng kiểm thử có thể kết thúc trong các trường hợp sau:
● Khi 1 dự án bị hủy bỏ.
● Khi các mục tiêu chính ã hoàn thành.
● Khi việc bảo trì hoặc cập nhật ã hoàn thành.
4. Nguyên tắc kiểm thử
4.1. Kiểm thử phần mềm chứng minh sự hiện diện của lỗi
Bằng việc kiểm thử, chúng ta có thể làm giảm lượng bugs khi áp dụng nhiều
phương pháp kiểm thử lên phần mềm. Tuy nhiên khi ược ưa lên môi trường thật,
người dùng cuối hoàn toàn có thể thấy nhiều lỗi khác không tìm thấy trong quá
trình kiểm thử. Kiểm thử chứng minh ược sản phẩm có lỗi nhưng không thể 11 lOMoAR cPSD| 46836766
chứng minh rằng sản phẩm không còn lỗi. Điều này có nghĩa là, sẽ luôn có lỗi
không ược phát hiện trong phần mềm, ngay cả khi không tìm thấy lỗi, cũng
không ồng nghĩa rằng phần mềm úng hoàn toàn.
4.2. Kiểm thử toàn bộ là không khả thi
Đúng vậy, rất khó ể kiểm tra toàn bộ các module cũng như các tính năng, kết
hợp với ầu vào và ầu ra trong suốt quá trình kiểm tra. Các sản phẩm phần mềm
hiện nay cực kỳ a dạng và phức tạp, ược phát triển trên nhiều nền tảng, thêm
vào ó, ngày càng có nhiều công nghệ mới, khả năng kết nối dữ liệu lớn…
khiến việc kiểm thử toàn bộ gần như là không thể. Thay vì cố gắng kiểm thử
toàn bộ, hãy xác ịnh mức ộ quan trọng và ộ ưu tiên của các module ể kiểm thử
những phần cần thiết hoặc gặp nhiều nguy cơ hơn.
4.3. Kiểm thử càng sớm càng tốt
Nguyên tắc kiểm thử sớm có nghĩa là việc kiểm thử cần ược thực hiện càng sớm
càng tốt trong vòng ời phát triển phần mềm. Vậy ở bước nào thì ược coi là sớm?
Nguyên tắc này cho thấy ta cần phát hiện bug ngay từ các bước ầu tiên như
nghiên cứu yêu cầu (requirement) hay design. Phát hiện lỗi càng muộn, chi phí
bỏ ra ể xử lý càng cao. Vì vậy, việc thay ổi yêu cầu không úng từ sớm sẽ khiến
tốn ít chi phí ể thay ổi tính năng hơn.
4.4. Lỗi thường ược phân bố tập trung
Nguyên lý về phân bố lỗi chỉ ra rằng, chỉ một số ít module chứa phần lớn số lỗi
phát hiện ược. Những module này thường là những thành phần, chức năng chính
của hệ thống. Điều này cũng úng theo nguyên lý Pareto: 80 – 20: 80% số lỗi tìm
thấy ở chỉ 20% module. Bằng kinh nghiệm, các QA/ Tester có thể xác ịnh ược
những module có tính rủi ro và nhiều lỗi như vậy, giúp tập trung tìm kiếm lỗi
nhanh và hiệu quả hơn. Tuy nhiên, cách tiếp cận này cũng ẩn chứa vấn ề: nếu 12 lOMoAR cPSD| 46836766
thực hiện kiểm thử tương tự lặp i lặp lại, dễ thấy rằng những test case cũ sẽ khó tìm thêm ược bug mới.
4.5. Nghịch lý thuốc trừ sâu
Trong trồng trọt, nếu người nông dân sử dụng lặp lại một liều trừ sâu, các loại
sâu bệnh sẽ dần dần thích nghi và trở nên “nhờn” với loại thuốc trừ sâu ó. Tương
tự với kiểm thử phần mềm, khi lặp i lặp lại một test case, thì xác suất tìm ược
lỗi là rất thấp. Nguyên nhân là hệ thống hoàn thiện hơn, lỗi tìm thấy ã ược sửa
theo test case cũ. Để xử lý hiệu ứng “thuốc trừ sâu” này, test case cần ược thường
xuyên xem lại và chỉnh sửa, thêm nhiều test case mới ể tìm lỗi mới (regression test).
Thêm vào ó, QA/ Tester cũng không nên phụ thuộc quá nhiều vào các kỹ thuật
test sẵn có. Bạn cần liên tục cải tiến các phương pháp có sẵn ể làm việc kiểm thử hiệu quả hơn.
4.6. Kiểm thử phụ thuộc vào ngữ cảnh
Kiểm thử phụ thuộc vào ngữ cảnh, nói một cách ơn giản, là việc kiểm thử một
trang thương mại iện tử sẽ phải khác cách test một ứng dụng ọc tin tức. Tất cả
các phần mềm ều ược phát triển theo cách khác nhau. Và việc áp dụng chung
một “cách giải” là sai lầm. Bạn cần sử dụng cách tiếp cận khác nhau, phương
thức, kỹ thuật test khác nhau, loại test phụ thuộc vào loại phần mềm/ ứng dụng/ website.
4.7. Quan niệm sai lầm về việc hết lỗi
Một phần mềm sạch bug 99% vẫn có thể không sử dụng ược. Đây là trường hợp
phần mềm ược kiểm thử bằng một requirement sai. Kiểm thử không chỉ ể tìm ra 13 lOMoAR cPSD| 46836766
lỗi, mà còn ể kiểm tra xem phần mềm có áp ứng ược úng nhu cầu hay không.
Chính vì vậy, việc Không còn lỗi hay Hết lỗi là quan niệm sai lầm.
Quan iểm: “Nguyên tắc kiểm thử chỉ là ể tham khảo, không có tính ứng dụng thực tế”?
Đây là quan iểm cực kỳ sai lầm. Các nguyên tắc kiểm thử giúp tạo ra một chiến
lược kiểm thử rõ ràng và tạo ra những trường hợp kiểm thử sát sao, dễ bắt ược
bug. Những tester dày dạn kinh nghiệm áp dụng những nguyên tắc kiểm thử
nhuần nhuyễn ến ộ họ không nghĩ rằng họ ang áp dụng chúng.
Vì vậy, việc nguyên tắc kiểm thử không có tính ứng dụng thực tế là sai lầm. 14 lOMoAR cPSD| 46836766
CHƯƠNG 2: PHÂN TÍCH YÊU CẦU VÀ THIẾT KẾ HỆ THỐNG
1. Tính năng cơ bản của hệ thống bán hàng
Hệ thống bán hàng là một phần quan trọng trong quản lý và thúc ẩy doanh số
bán hàng của một doanh nghiệp. Để ảm bảo hiệu quả trong việc quản lý bán
hàng và tạo trải nghiệm tích hợp cho khách hàng, hệ thống bán hàng cần có các tính năng cơ bản sau:
Quản lý sản phẩm và dịch vụ:
● Thêm, chỉnh sửa, và xóa sản phẩm và dịch vụ.
● Quản lý danh mục sản phẩm và dịch vụ.
● Xác ịnh thông tin chi tiết của sản phẩm (tên, mô tả, giá cả, số lượng tồn, v.v.).
● Kết nối sản phẩm với các danh mục, thuộc tính và hình ảnh.
Quản lý ơn hàng: ● Tạo ơn hàng mới.
● Xem và chỉnh sửa ơn hàng ang tồn tại.
● Xác nhận ơn hàng và lập hóa ơn cho khách hàng.
● Theo dõi trạng thái ơn hàng (ã xác nhận, ang giao, ã thanh toán, v.v.).
Quản lý khách hàng:
● Tạo và quản lý thông tin cá nhân của khách hàng.
● Xem và sửa thông tin cá nhân của khách hàng.
● Lưu trữ lịch sử mua hàng của khách hàng. 15 lOMoAR cPSD| 46836766
● Gửi thông báo và cập nhật sản phẩm và khuyến mãi cho khách hàng.
Quản lý thanh toán và giao hàng:
● Cung cấp nhiều phương thức thanh toán (thanh toán trực tuyến, thanh
toán khi nhận hàng, v.v.).
● Cho phép chọn vùng giao hàng và tính phí giao hàng.
● Xác nhận ịa chỉ giao hàng và thông tin thanh toán.
● Lập lịch và theo dõi quá trình giao hàng.
Bảo mật và quản lý người dùng:
● Quản lý người dùng (quản trị viên, nhân viên, và khách hàng).
● Quản lý quyền truy cập cho từng loại người dùng.
● Bảo mật thông tin cá nhân và thanh toán của khách hàng.
● Đăng nhập và xác thực người dùng.
Báo cáo và thống kê:
● Tạo và xem báo cáo về doanh số bán hàng.
● Thống kê hàng tồn kho và doanh số.
● Xem thông tin khách hàng và ơn hàng theo thời gian.
Giao diện người dùng ( UI/UX ):
● Thiết kế giao diện người dùng thân thiện và dễ sử dụng.
● Đảm bảo tính thẩm mỹ và dễ tương tác.
● Đáp ứng trên nhiều nền tảng (máy tính, iện thoại di ộng, máy tính bảng).
Tự ộng hóa quy trình: 16 lOMoAR cPSD| 46836766
● Tự ộng hóa quy trình ặt hàng và thanh toán.
● Tự ộng hóa thông báo cho khách hàng.
● Tự ộng hóa quản lý tồn kho.
2. Yêu cầu về ộ bảo mật
Độ bảo mật là một trong những khía cạnh quan trọng nhất của hệ thống bán hàng
ể ảm bảo an toàn cho thông tin cá nhân của khách hàng và quản lý dữ liệu kinh
doanh. Dưới ây là các yêu cầu cơ bản về ộ bảo mật trong hệ thống bán hàng:
Xác thực người dùng:
● Yêu cầu xác thực người dùng trước khi truy cập vào hệ thống. Người
dùng phải cung cấp thông tin ăng nhập và mật khẩu ể truy cập tài khoản.
Quản lý quyền truy cập:
● Xác ịnh và quản lý các cấp quyền truy cập cho từng loại người dùng (quản
trị viên, nhân viên, và khách hàng).
● Đảm bảo người dùng chỉ có quyền truy cập vào các tính năng và dữ liệu
cần thiết cho công việc của họ.
Bảo vệ thông tin cá nhân:
● Bảo vệ thông tin cá nhân của khách hàng, bao gồm thông tin liên hệ, tài
khoản ngân hàng, và thông tin thanh toán.
● Sử dụng mã hóa dữ liệu ể bảo vệ dữ liệu cá nhân khi lưu trữ và truyền tải.
Phòng ngừa tấn công: 17 lOMoAR cPSD| 46836766
● Thực hiện các biện pháp ể ngăn chặn tấn công từ phía bên ngoài, bao gồm
tấn công DDoS (Tấn công từ chối dịch vụ) và tấn công SQL Injection.
● Cập nhật và duyệt kỹ thuật bảo mật thường xuyên ể phát hiện và khắc
phục lỗ hổng bảo mật.
Theo dõi và ghi nhật ký ( Logging ):
● Theo dõi hoạt ộng của hệ thống và ghi nhật ký ể theo dõi các hoạt ộng
của người dùng và phát hiện các hành vi bất thường.
● Lưu trữ nhật ký trong một nơi an toàn và duyệt kỹ thuật ảm bảo tính toàn vẹn của dữ liệu.
Khôi phục dự phòng (Backup and Recovery):
● Thực hiện quá trình sao lưu dự phòng ịnh kỳ của dữ liệu quan trọng, bao
gồm thông tin ặt hàng, thông tin khách hàng, và thông tin thanh toán.
● Đảm bảo tính sẵn sàng và khả năng phục hồi sau sự cố.
3. Yêu cầu về hiệu suất và tải trọng
Để ảm bảo hệ thống bán hàng hoạt ộng một cách hiệu quả và không gặp trục
trặc trong quá trình sử dụng, các yêu cầu về hiệu suất và tải trọng sau ây cần ược xác ịnh:
- Thời gian tải trang (Load Time): Hệ thống cần có thời gian tải trang nhanh
chóng ể cung cấp trải nghiệm người dùng tốt. Thời gian tải trang không nên vượt quá 3 giây. 18 lOMoAR cPSD| 46836766
- Tải trọng ồng thời (Concurrent Load): Hệ thống phải áp ứng ược tải trọng ồng
thời từ người dùng. Phải có khả năng xử lý và phản hồi cho hàng trăm người dùng cùng một lúc.
- Khả năng mở rộng (Scalability): Hệ thống cần có khả năng mở rộng dễ dàng
ể áp ứng với tải trọng gia tăng. Các tài nguyên hệ thống (máy chủ, cơ sở dữ liệu,
v.v.) phải có khả năng mở rộng theo nhu cầu.
- Thời gian áp ứng yêu cầu (Response Time): Hệ thống phải có thời gian áp ứng
nhanh chóng ối với các yêu cầu từ người dùng, bao gồm việc ặt hàng, tìm kiếm
sản phẩm, và thanh toán.
- Kiểm thử hiệu suất (Performance Testing): Thực hiện kiểm thử hiệu suất ể ảm
bảo rằng hệ thống có thể hoạt ộng một cách ổn ịnh và áp ứng ược tải trọng cao
mà không gặp lỗi hoặc sự cố.
- Giới hạn tải trọng cực ại (Maximum Load Limit): Định rõ giới hạn tải trọng
mà hệ thống có thể xử lý mà không gây ra sự cố hoặc giảm hiệu suất áng kể.
- Dự phòng và phục hồi (Redundancy and Recovery): Hệ thống cần có giải pháp
dự phòng ể ảm bảo tính sẵn sàng và khả năng phục hồi sau sự cố.
Điều này bao gồm sao lưu dự phòng và khôi phục dự phòng.
4. Yêu cầu về hiệu suất và tải trọng
Giao diện người dùng là yếu tố quan trọng trong hệ thống bán hàng, ảnh hưởng
ến trải nghiệm người dùng và khả năng sử dụng của hệ thống. Dưới ây là các
yêu cầu về giao diện người dùng: 19 lOMoAR cPSD| 46836766
- Thân thiện và Dễ sử dụng: Giao diện phải thân thiện với người dùng, ảm bảo
tính dễ sử dụng và tương tác trơn tru. Người dùng cần có thể tìm hiểu và sử dụng
hệ thống một cách nhanh chóng.
- Tương thích Đa Nền Tảng: Giao diện cần phải tương thích trên nhiều nền tảng,
bao gồm máy tính, iện thoại di ộng, máy tính bảng, và trình duyệt web khác nhau.
- Tính Thẩm Mỹ: Giao diện cần phải có thiết kế thẩm mỹ và hấp dẫn. Phải sử
dụng các yếu tố thiết kế như màu sắc, hình ảnh, và biểu ồ một cách hợp lý ể tạo ra giao diện ẹp mắt.
- Dễ Tùy Biến: Hệ thống cần hỗ trợ tùy chỉnh giao diện cho phù hợp với những
doanh nghiệp khác nhau. Quản trị viên cần có khả năng thay ổi giao diện, bố trí, màu sắc, và logo.
- Hiển Thị Thông Tin Sản Phẩm Chi Tiết: Trang sản phẩm cần hiển thị thông
tin chi tiết về sản phẩm, bao gồm mô tả, hình ảnh, giá, và thông tin khuyến mãi.
- Quá Trình Đặt Hàng Dễ Dàng: Giao diện phải giúp người dùng dễ dàng thêm
sản phẩm vào giỏ hàng, xem giỏ hàng, và tiến hành ặt hàng một cách thuận tiện.
- Thanh Toán An Toàn: Giao diện thanh toán cần ảm bảo tính an toàn trong việc
xử lý thông tin thanh toán và cung cấp các phương thức thanh toán áng tin cậy.
- Chức Năng Tìm Kiếm: Hệ thống cần có chức năng tìm kiếm sản phẩm và dịch
vụ dựa trên từ khóa, danh mục, và thuộc tính. 20