Ưu điểm của kiểm thử chức năng: Hình thức kiểm thử này mô phỏng việc sử dụng hệ thống thực tế Được thực hiện trong các điều kiện gần với điều kiện của khách hàng Không có giả định n
Kiểm thử phần mềm là gì ?
Kiểm thử phần mềm là quá trình quan trọng nhằm phát hiện lỗi và đảm bảo phần mềm hoạt động chính xác theo yêu cầu của khách hàng Hoạt động này không chỉ giúp xác định các vấn đề tiềm ẩn mà còn cung cấp cái nhìn độc lập về phần mềm, từ đó đánh giá và hiểu rõ hơn về các rủi ro khi triển khai.
Kiểm thử phần mềm đóng vai trò rất quan trọng :
Kiểm thử phần mềm là một hoạt động thiết yếu để đảm bảo chất lượng trong các dự án phát triển phần mềm Do đó, nó đã trở thành quy trình bắt buộc trong mọi dự án phần mềm hiện nay.
Kiểm thử phần mềm để tránh những rủi ro, lỗi phát sinh trong suốt quá trình tạo ra sản phẩm.
Lỗi càng phát hiện ra sớm càng giúp tránh được rủi ro và chi phí.
Mục đích của kiểm thử phần mềm:
Kiểm thử phần mềm để đánh giá phần mềm có đạt yêu cầu mong đợi hay có sai sót nào không?
Phần mềm có làm việc như mong muốn không?
Phần mềm có giải quyết được yêu cầu của khách hàng không?Nó làm được gì mà người dùng mong đợi?
Người dùng có thích nó không?
Nó có tương thích với các hệ thống khác của chúng ta hay không?
Phân loại kiểm thử phần mềm
Kiểm thử chức năng
Kiểm thử chức năng là quá trình xác minh rằng hệ thống hoạt động đúng theo các yêu cầu nghiệp vụ đã đề ra Hình thức kiểm thử này có thể được thực hiện từ hai khía cạnh chính: dựa trên các yêu cầu cụ thể và dựa trên quy trình nghiệp vụ.
Trong kiểm thử dựa trên yêu cầu, các yêu cầu được ưu tiên theo tiêu chí rủi ro, đảm bảo rằng những phần quan trọng nhất được kiểm tra đầy đủ Ngược lại, kiểm thử dựa trên quy trình nghiệp vụ sử dụng kiến thức liên quan đến các hoạt động hàng ngày của hệ thống, giúp mô tả rõ ràng các công việc trong nghiệp vụ.
Kiểm thử chức năng bao gồm 5 bước:
Xác định các chức năng mà 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 chức năng.
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 chức năng.
Thực hiện các trường hợp kiêm thử.
So sánh kết quả thực tế và kết quả mong muốn.
Trong đó, kiểm thử chức năng còn được chia nhỏ ra thành các loại:
Kiểm thử đơn vị (Unit testing)
Kiểm thử giao diện (Interface testing)
Kiểm thử tích hợp (Integration testing)
Kiểm thử hệ thống (System testing)
Kiểm thử hồi quy (Regression testing)
Kiểm thử chấp nhận (Acceptance testing) Ưu điểm của kiểm thử chức năng:
Hình thức kiểm thử này mô phỏng việc sử dụng hệ thống thực tế
Được thực hiện trong các điều kiện gần với điều kiện của khách hàng
Không có giả định nào về cấu trúc hệ thống được đưa ra trong khi kiểm thử chức năng
Rất dễ dàng để thực hiện test thủ công
Ngược lại, kiểm thử chức năng có những giới hạn sau:
Khả năng cao xảy ra tình trạng test dư thừa
Các lỗi logic trong phần mềm có thể bị bỏ sót trong khi kiểm thử chức năng
Kiểm thử phi chức năng
Kiểm thử phi chức năng là kiểm tra các đặc tính chất lượng của hệ thống.
Kiểm tra số lượng người dùng có thể đăng nhập đồng thời vào phần mềm là một ví dụ điển hình cho việc kiểm tra phi chức năng Loại kiểm tra này không kém phần quan trọng so với kiểm tra chức năng, vì nó ảnh hưởng trực tiếp đến sự hài lòng của khách hàng.
Tương tự, kiểm thử phi chức năng cũng được chia thành các loại:
Kiểm thử độ ổn định là quá trình đánh giá khả năng phần mềm duy trì hiệu suất hoạt động liên tục trong khoảng thời gian nhất định Mục tiêu của kiểm thử này là đảm bảo phần mềm có thể hoạt động tốt mà không gặp phải sự cố trong suốt thời gian sử dụng.
Kiểm thử khả năng chịu tải (Load testing): đánh giá hoạt động của hệ thống khi khối lượng công việc ngày càng tăng
Kiểm thử áp lực (Stress testing): ước tính hoạt động của hệ thống ở trong hoặc vượt quá giới hạn khối lượng công việc dự kiến
Kiểm thử tính khả dụng (Usability testing): sản phẩm được test về tính thân thiện với người dùng
Kiểm thử bảo trì (Maintainability testing): kiểm tra mức độ đánh giá, thay đổi và test sản phẩm
Kiểm thử độ tin cậy (Reliability testing): sử dụng công cụ để tìm, ngăn chặn và loại bỏ lỗi trước khi hệ thống được triển khai
Kiểm thử tính tương thích (Portability testing) là quá trình đánh giá khả năng di chuyển của phần mềm giữa các môi trường khác nhau Mục tiêu của kiểm thử này là xác định mức độ dễ dàng hoặc khó khăn trong việc chuyển giao và triển khai phần mềm, từ đó đảm bảo rằng nó hoạt động hiệu quả và ổn định trên nhiều nền tảng khác nhau.
Kiểm thử cấu trúc (Structural testing)
Kiểm thử cấu trúc, hay còn gọi là “hộp trắng” hoặc “hộp thủy tinh”, tập trung vào việc phân tích và kiểm tra các yếu tố bên trong của thành phần hoặc hệ thống Phương pháp này thường được sử dụng để đo lường hiệu quả kiểm thử thông qua độ bao phủ của các yếu tố cấu trúc Kiểm thử cấu trúc chủ yếu được áp dụng trong kiểm thử thành phần và kiểm thử tích hợp.
Các mục tiêu chính của kiểm thử cấu trúc bao gồm:
Nhận ra những điểm bất cập
Test chức năng bổ sung
Xác định những phần bị thiếu trong bộ kiểm thử Ưu điểm của kiểm thử cấu trúc:
Có khả năng tìm ra lỗi ở giai đoạn đầu
Đảm bảo kiểm tra phần mềm kỹ lưỡng hơn
Bên cạnh đó, nhược điểm của kiểm thử cấu trúc:
Kiểm tra kết cấu khá tốn kém
Yêu cầu kiến thức về code
Đòi hỏi kiến thức vững chắc về công cụ được sử dụng để test
Kiểm thử liên quan đến các thay đổi (Change related testing)
Kiểm thử xác nhận (Confirmation testing)
Khi kiểm thử phát hiện lỗi, Tester cần xác định nguyên nhân do phần mềm Sau khi thông báo cho Developer để sửa chữa, phần mềm sẽ được cập nhật phiên bản vá lỗi Cuối cùng, Tester phải thực hiện kiểm tra lại để đảm bảo rằng lỗi đã được khắc phục hoàn toàn.
Khi thực hiện kiểm tra xác nhận, điều quan trọng là đảm bảo các trường hợp kiểm thử được thực hiện chính xác như lần đầu, sử dụng cùng đầu vào, dữ liệu và môi trường kiểm thử để xác nhận lỗi đã được sửa Tester cần nhận thức rằng sau khi vá lỗi, khả năng xuất hiện lỗi mới là hoàn toàn có thể Do đó, việc kiểm thử chính xác ở phiên bản hiện tại của phần mềm là chưa đủ; việc phát hiện các vấn đề ngoài ý muốn thông qua kiểm thử hồi quy là cần thiết.
Kiểm thử hồi quy (Regression testing)
Kiểm thử hồi quy, giống như kiểm thử xác nhận, bao gồm việc lặp lại các trường hợp kiểm thử đã được thực hiện trước đó Quy trình này được thực hiện khi có sự thay đổi trong phần mềm, chẳng hạn như sửa lỗi hoặc thêm chức năng mới.
Kiểm thử hồi quy nhằm đảm bảo rằng các thay đổi trong phần mềm hoặc môi trường không gây ra tác động tiêu cực, ảnh hưởng đến chức năng và hệ thống, đồng thời vẫn đáp ứng đầy đủ các yêu cầu của phần mềm Mọi trường hợp kiểm thử hồi quy sẽ được thực hiện mỗi khi có phiên bản vá lỗi mới được phát hành, điều này làm cho quy trình này trở nên lý tưởng cho việc tự động hóa.
Quy trình kiểm thử phần mềm
Quy trình Đầu vào Các hoạt động Đầu ra
Tài liệu SRS và tài liệu thiết kế là những nguồn quan trọng giúp phân tích và hiểu rõ các yêu cầu phần mềm Việc nghiên cứu và đọc hiểu các bản prototype sẽ hỗ trợ trong việc xác định những yêu cầu cụ thể Để làm rõ hơn về sản phẩm, cần đặt ra các câu hỏi cho BA, team leader và khách hàng nhằm giải quyết những thắc mắc liên quan đến yêu cầu phần mềm.
Lập kế hoạch Các tài liệu đã được cập nhật thông qua file Q
& A trong giai đoạn phân tích yêu cầu
Xác định phạm vi kiểm thử: thời gian, lịch trình cho các công việc.
Xác định phương pháp tiếp cận.
Xác định nguồn lực: con người và thiết bị.
Lên kế hoạch thiết kế công việc test: các chức năng cần kiểm thử, cái nào cần thực hiện trước, sau, ai là người thực hiện
Test plan, checklist và các tài liệu đặc tả đã được cập nhật
Review tài liệu: xác định công việc cần làm.
Chuẩn bị dữ liệu kiểm thử: test data, test script.
Review test case/checklist: tránh rủi ro trong thiết kế test case
Test design, test case, check list, test data, test automation script
Test plan, smoke test case, test data
Thực thi các smoke test case để kiểm tra môi trường kiểm thử đã sẵn sàng cho việc test chưa
Môi trường đã được chuẩn bị sẵn sàng cho việc test và các kết quả của smoke test case
Test design, test case, check list, test data, test automation script
Thực hiện test theo kịch bản kiểm thử.
So sánh kết quả thực tế với mong đợi và log bug lên tool quản lý lỗi, theo dõi quá trình xử lý lỗi.
Kết thúc Tất cả các tài liệu được tổng hợp từ giai đoạn đầu tiên
Báo cáo tổng kết kết quả thực thi test cho thấy các chức năng đã hoàn thành và chưa hoàn thành, đồng thời chỉ ra những chức năng còn nhiều lỗi Ngoài ra, báo cáo cũng nêu rõ các nhà phát triển có nhiều lỗi nhất và mức độ nghiêm trọng của các lỗi này.
Test report, test results final
Các phương pháp kiểm thử phần mềm
Kiểm thử hộp trắng (White Box Testing)
Phương pháp kiểm thử phần mềm White Box Testing, hay còn gọi là kiểm thử hộp trắng, cho phép các tester kiểm tra cấu trúc bên trong của phần mềm Trong quá trình này, tester sẽ sử dụng dữ liệu thử nghiệm được lấy trực tiếp từ mã chương trình để đảm bảo tính chính xác và hiệu quả của phần mềm.
Kiểm thử phần mềm, còn được gọi là kiểm thử hộp trắng, thử nghiệm điều hướng đường dẫn, thử nghiệm cấu trúc hay kiểm tra theo hướng logic, là phương pháp mà các tester chuyên nghiệp tập trung vào dữ liệu đầu vào và đầu ra, đồng thời truy cập trực tiếp vào mã nguồn.
White box testing is categorized into various types, including API Testing, code coverage, Fault Injection Methods, Mutation Testing Methods, and Static Testing API Testing involves evaluating applications by utilizing both private and public API functions.
Code Coverage là quá trình tạo ra các trường hợp kiểm thử để đảm bảo rằng tất cả các phần của mã nguồn đều được kiểm tra Phương pháp Fault Injection sẽ đưa vào một số lỗi nhằm kiểm tra các đường dẫn trong mã, từ đó cải thiện độ bao phủ code.
Mutation Testing Methods là một phương pháp kiểm thử hộp trắng, trong đó các câu lệnh trong mã nguồn được thay đổi để đánh giá khả năng phát hiện lỗi của các test case Trong khi đó, đối với kiểm thử tĩnh, các kiểm thử viên không cần phải nắm rõ mã lệnh mà chỉ dựa vào tài liệu đặc tả để thực hiện kiểm tra các chức năng.
Giúp hệ thống tối ưu hóa các dòng lệnh một cách đơn giản
Giúp các tester phát hiện lỗi dễ dàng trong mỗi dòng lệnh
Loại bỏ nhanh chóng dòng lệnh có lỗi tiềm ẩn hoặc không quan trọng
Sau khi áp dụng phương pháp kiểm thử phần mềm này, người kiểm thử sẽ dễ dàng đạt được độ bao phủ tối đa trong các trường hợp kiểm thử tiếp theo.
Khi tìm lỗi tiềm ẩn của hệ thống, có nhiều luồng không thể kiểm tra được bằng cách kiểm tra chi tiết từng dòng lệnh
Cần có rất nhiều tool chuyên biệt, ví dụ như tool phát hiện/sửa lỗi, phân tích code để có thể duy trì phương pháp kiểm thử hộp trắng
Tester thực hiện phương pháp kiểm thử phần mềm White Box Testing cần có chuyên môn cao và dày dặn kinh nghiệm
Giá thành phần mềm sẽ tăng lên đáng kể nếu sử dụng các tester có chuyên môn cao, giàu kinh nghiệm
Kiểm thử hộp đen (Black Box Testing)
Phương pháp kiểm thử này cho phép các tester kiểm tra phần mềm mà không cần biết cấu trúc bên trong, tương tự như việc kiểm tra một chiếc hộp đen mà không thể nhìn thấy nội dung bên trong.
Kiểm thử hộp đen là phương pháp thử nghiệm dựa trên các thông số kỹ thuật, chủ yếu được thực hiện trong kiểm thử hệ thống và kiểm thử chức năng Phương pháp này bao gồm nhiều loại hình kiểm thử phần mềm khác nhau.
Kiểm thử tất cả các cặp (All-pairs testing)
Kiểm thử dựa trên Model (Model-based testing)
Phân tích giá trị biên (Boundary value analysis)
Phân vùng tương đương (Equivalence partitioning)
Kiểm thử dựa vào chức năng (Specification-based testing)
Kết hợp các cột hoặc dòng có liên quan (Traceability matrix)
Kiểm thử dựa vào khả năng và kinh nghiệm của tester (Exploratory testing)
Tester không cần phải truy cập vào từng dòng lệnh
Hiệu quả và phù hợp với hệ thống có số lượng lớn dòng lệnh
Phân biệt một cách rõ ràng quan điểm của nhà phát triển và người dùng
Không đòi hỏi tester phải có kiến thức về ngôn ngữ lập trình khi kiểm thử phần mềm
Bị giới hạn bởi độ bao phủ của các trường hợp kiểm thử
Khó khăn trong việc thiết kế đầy đủ mọi trường hợp kiểm thử
Thực tế không mang lại hiệu quả cao bởi các tester bị giới hạn kiến thức về hệ thống
Các tester chỉ tập trung vào dòng lệnh dễ xảy ra lỗi, khó có thể kiểm tra tất cả đoạn lệnh của hệ thống
Kiểm thử hộp xám (Gray Box Testing)
Kiểm thử hộp xám (Gray Box Testing) hiện đang trở thành phương pháp kiểm thử phần mềm phổ biến nhất, kết hợp ưu điểm của cả kiểm thử hộp trắng và hộp đen Phương pháp này đặc biệt hữu ích trong việc thực hiện kiểm tra thâm nhập và kiểm thử tích hợp, giúp nâng cao chất lượng sản phẩm phần mềm.
Các tester cần có kiến thức vững về các luồng hoạt động trong hệ thống để áp dụng phương pháp kiểm thử hộp xám Phương pháp này giúp tester truy cập vào thuật toán và cấu trúc dữ liệu của chương trình, từ đó thiết kế các test case hiệu quả.
Kiểm thử hộp xám khác với kiểm thử hộp đen ở chỗ tester chú trọng vào việc kiểm tra qua giao diện người dùng Phương pháp này bao gồm các kỹ thuật như kiểm tra mảng trực giao, kiểm tra mẫu, kiểm tra ma trận và kiểm tra hồi quy.
Phương pháp kiểm thử phần mềm tối ưu bởi nó là sự kết hợp giữa 2 phương pháp còn lại
Các tester chỉ cần dựa vào các tài liệu đặc tả chức năng, định nghĩa giao diện mà không cần dựa vào các dòng lệnh
Với phương pháp này, kịch bản thử nghiệm có thể được thiết kế phức tạp, thông minh và hiệu quả hơn
Không phải góc nhìn từ nhà thiết kế, việc kiểm thử sẽ được hoàn thiện từ góc nhìn của người sử dụng
Kiểm thử hộp xám cho một ứng dụng có hệ thống phân tán thường gặp khó khăn khi liên kết lỗi
Độ bao phủ của các trường hợp kiểm thử bị giới hạn do kiểm thử hộp xám không dựa trên việc truy cập code
Hệ thống gặp phải giới hạn về thời gian kiểm thử, dẫn đến nhiều luồng hoạt động không được kiểm tra đầy đủ.
So sánh các phương pháp kiểm thử phần mềm
White box testing, also known as code-based testing or clear-box testing, focuses on the internal structures or workings of an application It contrasts with functional testing, data-driven testing, and closed-box testing, which evaluate the software's functionality without considering its internal logic Additionally, this testing approach is sometimes referred to as translucent testing, emphasizing its transparency in assessing code performance and behavior.
Phù hợp để kiểm tra các thuật toán trong hệ thống
Không phù hợp nếu dùng để kiểm tra các thuật toán trong hệ thống
Không phù hợp để kiểm tra các thuật toán trong hệ thống
Các giới hạn và miền dữ liệu sẽ được test
Hoàn thiện bởi cơ chế phát hiện lỗi
Nếu tester có kiến thức về các giới hạn, miền dữ liệu được thì chúng sẽ được test Tester phải nắm được các luồng hoạt động trong hệ thống
Tester không phải quan tâm đến các luồng hoạt động bên trong hệ thống
Tester cần có kiến thức nhất định về các luồng hoạt động bên trong hệ thống
Kiểm thử viên tự thiết kế dựa trên bộ dữ liệu kiểm thử phù hợp và kiến thức về những luồng hoạt động bên trong hệ thống
Việc kiểm thử được thực hiện dựa trên kết quả thực tế hệ thống trả về và kết quả mong muốn
Việc kiểm thử dựa vào sơ đồ các luồng dữ liệu và cơ sở dữ liệu Đầy đủ và tiêu tốn nhiều thời gian nhất
Tốn ít thời gian nhất nhưng độ bao phủ các trường hợp không đầy đủ nhất
Tiêu tốn thời gian và độ bao phủ các trường hợp ở mức độ vừa phải, quá trình hoàn thiện sản phẩm bao gồm sự hợp tác giữa lập trình viên, kiểm thử viên và người dùng cuối.
Các cấp độ hay giai đoạn kiểm thử phần mềm
Kiểm thử đơn vị
6.1.1 Khái niệm kiểm thử đơn vị
Kiểm thử đơn vị là một loại kiểm thử phần mềm tập trung vào việc kiểm tra từng đơn vị hoặc thành phần riêng lẻ của mã code Mục đích chính của kiểm thử đơn vị là xác nhận rằng mỗi đơn vị thực hiện chức năng đúng như mong đợi Hoạt động này diễn ra trong giai đoạn phát triển, cụ thể là khi thực hiện code, và thường được thực hiện bởi các kỹ sư phần mềm Kiểm thử đơn vị giúp kiểm tra độc lập từng phần code và xác minh tính chính xác của nó, với một đơn vị có thể là một chức năng, phương thức, thủ tục, mô-đun hoặc đối tượng riêng lẻ.
Trong vòng đời phát triển phần mềm (SDLC), quy trình kiểm thử phần mềm (STLC) và mô hình chữ V, kiểm thử đơn vị là cấp độ kiểm thử đầu tiên được thực hiện trước khi tiến hành kiểm thử tích hợp Kiểm thử đơn vị, một kỹ thuật kiểm tra WhiteBox, thường do kỹ sư phần mềm thực hiện Tuy nhiên, do hạn chế về thời gian, các kỹ sư phần mềm thường gặp khó khăn trong việc thực hiện kiểm thử đơn vị, vì vậy nhiệm vụ này thường được chuyển giao cho các QA (Quality Assurance/Tester).
6.1.2 Cách thực hiện kiểm thử đơn vị
Kiểm thử đơn vị có hai loại:
Kiểm thử đơn vị thường được thực hiện tự động, nhưng cũng có thể thực hiện thủ công Tự động hóa kiểm thử đơn vị thường được ưa chuộng hơn, giúp tiết kiệm thời gian và tăng độ chính xác Trong trường hợp kiểm thử thủ công, người thực hiện có thể dựa vào các tài liệu hướng dẫn chi tiết để thực hiện các bước cần thiết.
6.1.3 Kỹ thuật kiểm thử đơn vị
Các kỹ thuật bao gồm kiểm thử các đoạn mã code được tổng hợp ở dưới đây:
Statement Coverage (Bao phủ dòng lệnh)
Decision Coverage (Bao phủ quyết định)
Branch Coverage (Bao phủ các nhánh)
Condition Coverage (Bao phủ điều kiện)
Finite State Machine Coverage (Bao phủ trạng thái hữu hạn)
6.1.4 Công cụ kiểm thử đơn vị
Hiện nay, có nhiều công cụ tự động hỗ trợ kiểm thử đơn vị, bài viết này sẽ giới thiệu một số công cụ tiêu biểu trong lĩnh vực này.
JUnit là một công cụ kiểm tra miễn phí dành cho ngôn ngữ lập trình Java, giúp xác định các phương pháp kiểm thử thông qua các xác nhận Công cụ này thực hiện kiểm tra dữ liệu trước và sau đó chèn vào các đoạn mã, đảm bảo tính chính xác và hiệu quả trong quá trình phát triển phần mềm.
NUnit là một công cụ mã nguồn mở phổ biến trong kiểm thử đơn vị cho tất cả các ngôn ngữ NET, cho phép viết kịch bản kiểm thử một cách thủ công Nó hỗ trợ kiểm thử dựa trên dữ liệu và có khả năng chạy song song, giúp nâng cao hiệu quả trong quá trình kiểm thử phần mềm.
PHPUnit: PHPUnit là một công cụ kiểm thử đơn vị cho lập trình viên PHP.
Công cụ này phân tích các đơn vị mã code nhỏ và kiểm tra từng mã một cách riêng biệt Nó cũng hỗ trợ các nhà phát triển phần mềm trong việc áp dụng các phương thức xác nhận đã được xác định trước, đảm bảo rằng hệ thống hoạt động theo cách mong muốn.
Kiểm thử tích hợp
6.2.1 Khái niệm kiểm thử tích hợp
Kiểm thử tích hợp (Integration testing), còn được gọi là tích hợp và kiểm thử (I&T), là một giai đoạn quan trọng trong quy trình kiểm thử phần mềm Trong giai đoạn này, các mô-đun phần mềm riêng lẻ được kết hợp lại và thực hiện kiểm thử theo nhóm để đảm bảo tính tương thích và hoạt động chính xác của toàn bộ hệ thống.
Kiểm thử tích hợp diễn ra sau kiểm thử đơn vị và trước kiểm thử xác nhận Quá trình này nhận các mô-đun đã qua kiểm thử đơn vị, kết hợp chúng thành các tập hợp lớn hơn Các ca kiểm thử được xác định trong kế hoạch kiểm thử tích hợp sẽ được áp dụng vào các tập hợp này, nhằm cung cấp đầu ra cho hệ thống tích hợp.
6.2.2 Mục đích của kiểm thử tích hợp
Mặc dù mỗi module đều được kiểm thử đơn vị (Unit test) nhưng các lỗi vẫn còn tồn tại với các nguyên nhân sau:
Một module phần mềm thường được thiết kế bởi lập trình viên có kiến thức và tư duy logic riêng, dẫn đến sự khác biệt giữa các lập trình viên Do đó, kiểm thử tích hợp là rất quan trọng để đảm bảo tính đồng nhất và hoạt động hiệu quả của phần mềm.
Trong quá trình phát triển module, có thể xảy ra những thay đổi trong thông số kỹ thuật của khách hàng, và những thay đổi này có thể không được kiểm tra trong giai đoạn kiểm tra đơn vị trước đó.
Giao diện và cơ sở dữ liệu của các module có thể chưa hoàn chỉnh khi được ghép lại.
Khi tích hợp hệ thống các module có thể không tương thích với cấu hình chung của hệ thống.
Thiếu các xử lý ngoại lệ có thể xảy ra.
6.2.3 Cách tiếp cận, phương pháp, chiến lược của kiểm thử tích hợp
Có nhiều phương pháp kiểm thử tích hợp khác nhau, bao gồm Kiểm thử tích hợp Big Bang, Top-down, Bottom-up và từ dưới lên Lựa chọn phương pháp phù hợp phụ thuộc vào các yếu tố như chi phí, độ phức tạp và mức độ quan trọng của ứng dụng Bên cạnh đó, còn tồn tại nhiều loại kiểm thử tích hợp ít phổ biến hơn như tích hợp dịch vụ phân tán, kiểm thử tích hợp sandwich, tích hợp đường trục, tích hợp tần số cao và tích hợp lớp.
6.2.3.1 Kiểm thử tích hợp Big Bang
Trong kiểm tra tích hợp Big Bang, tất cả các mô-đun được tích hợp đồng thời và sau đó thực hiện kiểm tra tổng thể Cụ thể, các mô-đun từ Mô-đun 1 đến Mô-đun 6 được tích hợp cùng lúc trước khi tiến hành thử nghiệm.
Thuận tiện với các dự án nhỏ.
Mọi thứ đã kết thúc trước khi kiểm thử tích hợp bắt đầu.
Khó khăn trong việc phát hiện bug.
Có thể bỏ qua các bug giao diện nhỏ trong quá trình tìm bug.
Mât thời gian dành cho tích hợp hệ thống nên làm giảm thời gian dành cho test.
Do các module được kiểm thử cùng 1 lúc nên các module có nguy cơ bị cô lập trong quá trình kiểm thử.
Khó theo dõi nguyên nhân thất bại vì tích hợp muộn.
6.2.3.2 Kiểm thử tích hợp Top-down
Kiểm tra được thực hiện theo hướng từ trên xuống dưới, dựa trên dòng điều khiển hoặc cấu trúc kiến trúc, bắt đầu từ giao diện người dùng (GUI) hoặc menu chính Phương pháp này thường được áp dụng trong kiểm thử stub.
Sản phẩm được kiểm thử rất phù hợp vì kiểm thử tích hợp về cơ bản được thực hiện trong một môi trường gần giống với thực tế
Cơ bản có thể được thực hiện với thời gian ít hơn bởi vì đơn giản hơn.
Thu gọn phạm vi bug dễ dàng hơn
Modules quan trọng đang được thử nghiệm trên mức ưu tiên; lỗi trong thiết kế lớn có thể được tìm thấy và cố định đầu tiên.
Chức năng cơ bản được kiểm tra vào cuối chu kỳ.
Module ở mức độ thấp hơn sẽ được kiểm tra không đầy đủ.
6.2.3.3 Kiểm thử tích hợp Bottom-Up
Mỗi module ở cấp độ thấp hơn sẽ được thử nghiệm với các module ở cấp độ cao hơn cho đến khi tất cả các module đều hoàn thành quá trình kiểm tra Phương pháp này thường được áp dụng trong kiểm tra Driver.
Thu gọn phạm vi bug dễ dàng hơn
Không mất thời gian chờ tất cả các module được tích hợp
Module quan trọng của hệ thống có thể dễ bị lỗi
Không giữ được nguyên mẫu đầu tiên của hệ thống
6.2.3.4 Kiểm thử tích hợp gia tăng
Phương pháp kiểm tra này kết hợp hai hoặc nhiều module liên quan một cách hợp lý để đảm bảo hoạt động đúng đắn Sau đó, các phân hệ liên quan khác sẽ được thêm vào và kiểm tra Quá trình này tiếp tục cho đến khi tất cả các module được tham gia và thử nghiệm thành công Để thực hiện, các chương trình giả được sử dụng, gọi là Stub và Driver.
Sơ khai và trình điều khiển không thực hiện toàn bộ logic lập trình các module nhưng chỉ mô phỏng giao tiếp dữ liệu với các module được gọi.
Stub: Được gọi bởi Module dưới Test.
Driver: Gọi Module để được kiểm tra.
Các khiếm khuyết được tìm thấy sớm, dễ dàng phát hiện nguyên nhân.
Tốn thời gian vì Stubs và Driver phải được phát triển và sử dụng trong thử nghiệm.
6.2.3.5 Kiểm thử tích hợp Sandwich
Kiểm thử tích hợp Sandwich là phương pháp kết hợp cả hai cách tiếp cận từ trên xuống và từ dưới lên, thường được gọi là kiểm thử tích hợp lai hoặc kiểm thử tích hợp hỗn hợp Trong phương pháp này, hệ thống được cấu thành từ ba lớp, giúp tối ưu hóa quá trình kiểm thử và đảm bảo tính toàn diện trong việc phát hiện lỗi.
Một lớp ở giữa sẽ là mục tiêu của thử nghiệm
Một lớp bên trên lớp đích và một lớp bên dưới lớp đích Thử nghiệm bắt đầu từ lớp ngoài và hội tụ ở lớp giữa
Các lớp trên cùng và dưới cùng có thể được kiểm tra song song.
Việc kiểm tra mở rộng các hệ thống con không được thực hiện trước khi tích hợp.
6.2.4 Các bước thực hiện kiểm thử tích hợp
Chọn mô-đun hoặc thành phần sẽ được kiểm tra
Thiết kế các kịch bản thử nghiệm, trường hợp, và Script (Test Scenarios, Cases, and Scripts ).
Thực hiện kiểm tra theo test case đã viết
Theo dõi & tái kiểm tra các lỗi ở trên.
Lặp lại các bước trên cho đến khi hệ thống hoàn chỉnh được kiểm tra đầy đủ
Kiểm thử hồi quy
6.3.1 Khái niệm kiểm thử hồi quy
Kiểm thử hồi quy là một phương pháp kiểm tra phần mềm nhằm đảm bảo rằng các thay đổi trong mã nguồn hoặc các thành phần của phần mềm không gây ảnh hưởng tiêu cực đến các tính năng đã có.
Thử nghiệm hồi quy là một biện pháp kiểm soát chất lượng nhằm đảm bảo hai điều kiện sau đây:
Code mới đổi đạt yêu cầu quy định.
Code Unmodified đã không bị ảnh hưởng bởi sự thay đổi như trên.
Phương pháp kiểm thử này nhằm đảm bảo rằng các thay đổi trong mã nguồn mới không ảnh hưởng đến các chức năng hiện có, đồng thời xác nhận rằng toàn bộ mã cũ vẫn hoạt động bình thường sau khi cập nhật mã mới vào phần mềm.
Những trường hợp cần phải được kiểm thử hồi quy:
Thay đổi trong yêu cầu và mã code được sửa đổi theo yêu cầu
Tính năng mới được thêm vào phần mềm
Khắc phục sự cố về hiệu suất
6.3.2 Đặc điểm và tính chất của kiểm thử hồi quy
Kiểm thử hồi quy không chỉ là một mức kiểm tra mà là quy trình kiểm tra phần mềm sau khi có sự thay đổi, nhằm đảm bảo rằng phiên bản mới vẫn thực hiện tốt các chức năng như phiên bản cũ và không phát sinh lỗi mới Kiểm thử hồi quy có thể được thực hiện ở mọi cấp độ kiểm tra.
Kiểm tra hồi quy là một bước quan trọng trong quy trình phát triển phần mềm, mặc dù tốn nhiều thời gian và công sức Việc bỏ qua kiểm tra hồi quy có thể dẫn đến việc phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, ngay cả khi chúng ta nghĩ rằng những lỗi đó đã được khắc phục Do đó, việc thực hiện kiểm tra hồi quy là cần thiết để đảm bảo chất lượng sản phẩm.
6.3.3 Làm thế nào để thực hiện kiểm thử hồi quy?
Bảo trì phần mềm là quá trình bao gồm cải tiến, sửa lỗi, tối ưu hóa và loại bỏ các tính năng không cần thiết, tuy nhiên, những thay đổi này có thể gây ra sự cố cho hệ thống Do đó, việc thực hiện kiểm tra hồi quy là rất quan trọng Kiểm tra hồi quy có thể được thực hiện thông qua nhiều kỹ thuật khác nhau.
6.3.3.1 Kiểm thử lại tất cả Đây là một trong những phương pháp để Kiểm thử hồi quy trong đó tất cả các kiểm thử trong nhóm kiểm thử hoặc bộ kiểm thư hiện có sẽ được thực hiện lại Điều này rất tốn kém vì nó đòi hỏi thời gian và nguồn lực rất lớn.
6.3.3.2 Lựa chọn kiểm thử hồi quy
Thay vì tiến hành kiểm thử toàn bộ, việc chỉ thực hiện một phần các trường hợp kiểm thử là hợp lý hơn Các trường hợp kiểm thử được lựa chọn có thể được chia thành hai loại.
Các trường hợp kiểm thử có thể tái sử dụng là những trường hợp có khả năng áp dụng trong các chu kỳ kiểm thử hồi quy một cách hiệu quả Việc sử dụng lại các trường hợp này không chỉ giúp tiết kiệm thời gian mà còn nâng cao chất lượng kiểm thử.
Các trường hợp thử nghiệm lỗi thời: Là các trường hợp không thể sử dụng trong các vòng đời kiểm thử hồi quy thành công.
6.3.3.3.Độ ưu tiên của các trường hợp kiểm thử
Các trường hợp kiểm thử được phân loại theo mức độ ưu tiên dựa trên tác động đến kinh doanh và các chức năng quan trọng thường xuyên sử dụng Việc lựa chọn các trường hợp kiểm thử theo mức độ ưu tiên này giúp giảm thiểu đáng kể quy mô của bộ kiểm tra hồi quy.
6.3.3.4 Chọn các trường hợp kiểm thử để kiểm thử hồi quy
Kiểm thử hồi quy hiệu quả có thể được thực hiện bằng cách chọn các trường hợp kiểm tra sau:
Các trường hợp kiểm thử thường xuyên xẩy ra lỗi
Các chức năng dễ thấy hơn đối với người dùng
Các trường hợp kiểm thử xác minh các tính năng cốt lõi của sản phẩm
Các trường hợp kiểm thử của chức năng đã trải qua nhiều thay đổi gần đây
Tất cả các trường hợp kiểm thử tích hợp
Tất cả các trường hợp kiểm thử phức tạp
Trường hợp kiểm thử giá trị biên
Một vài các trường hợp kiểm thử mẫu đã thành công
Một vài các trường hợp kiểm thử mẫu đã thất bại
6.3.4 Một số Công cụ dùng trong kiểm thử hồi quy
Nếu một phần mềm trải qua những thay đổi thường xuyên, chi phí kiểm thử hồi quy sẽ leo thang.
Trong các trường hợp như vậy, việc thực hiện thủ công các trường hợp kiểm thử làm tăng thời gian thực hiện kiểm thử cũng như chi phí.
Tự động hóa các trường hợp kiểm thử hồi quy là sự lựa chọn thông minh trong các trường hợp như vậy.
Phạm vi tự động hóa phụ thuộc vào số lượng các trường hợp kiểm thử vẫn có thể sử dụng lại cho các chu kỳ hồi quy kế tiếp.
Sau đây là các công cụ quan trọng nhất được sử dụng cho cả kiểm thử chức năng và hồi quy trong công nghệ phần mềm:
KHẢO SÁT HIỆN TRẠNG VÀ XÁC LẬP DỰ ÁN
Khảo sát hiện trạng
1.1.1 Giới thiệu về cửa hàng đồ gỗ HH Để thỏa mãn đam mê với đồ gỗ nhiều đơn vị đã xây dựng nên những chuỗi hệ thống cửa hàng đỗ gỗ để đáp ứng nhu cầu của mọi người Một trong số đồ gỗ tốt thì không thể nhắc đến cửa hàng đỗ gỗ HH Cửa hàng vừa mới được đâu tư trong thời gian gần đây Cộng thêm việc đầu tư đầy đủ hệ thống đồ gỗ chất lượng nên thu hút được đông đảo khách hàng đến cửa hàng.
Tên cửa hàng: Cửa hàng đồ gỗ HH
Địa chỉ: Chân Cầu Vượt Trịnh Văn Bô, Trần Hữu Dực, Xuân Phương, Nam
Từ Liêm, Hà Nội, Việt Nam.
Liên hệ: Mr Hoàng - Điện thoại: 0824.796.881
Có chỗ gửi xe máy, ô tô
Phục vụ Wifi miễn phí
Camera an ninh đảm bảo
1.1.4.1 Chức năng và nhiệm vụ của các bộ phận
Quản lý cửa hàng là bộ phận cao nhất, có nhiệm vụ tổ chức và phát triển các dịch vụ tốt nhất cho cửa hàng Họ cũng chịu trách nhiệm xử lý và đưa ra quyết định cho các tình huống phát sinh trong cửa hàng.
Quản lý nhân sự bao gồm việc điều chỉnh và tuyển dụng nhân viên, phân công công việc, sắp xếp ca làm việc, chấm công và thực hiện việc trả lương cho nhân viên theo chỉ đạo của quản lý cửa hàng.
Nhân viên là bộ phận chịu trách nhiệm phục vụ khách hàng tại cửa hàng, cung cấp dịch vụ tốt nhất để đảm bảo sự hài lòng của khách Họ cũng đảm bảo an toàn cho khách hàng và thực hiện quy trình thanh toán hóa đơn khi khách hàng mua sắm.
Nhân viên bảo vệ: Là bộ phận bảo vệ trật tự cho cửa hàng và trông cất xe cho khách.
1.1.4.2 Giới thiệu mặt hàng và dich vụ.
Giá sản phẩm: Giao động từ 500k-100tr
Quy trình đặt hàng tại cửa hàng yêu cầu khách hàng gọi điện trực tiếp để thông báo khung giờ đến và xem mặt hàng Nhân viên sẽ kiểm tra lịch đặt và hẹn lịch cho khách Để giữ hàng, khách cần chuyển khoản 20% tổng giá trị đơn hàng Sau khi hoàn tất đặt hàng, nhân viên sẽ ghi chú thông tin khách hàng và lập đơn hàng.
Quy trình phục vụ khách hàng khi đến cửa hàng:
Khi khách hàng đến cửa hàng, xe của họ sẽ được bảo quản cẩn thận bởi nhân viên, đảm bảo an toàn tuyệt đối Tại cửa hàng, khách sẽ được kiểm tra thông tin đặt hàng; nếu thông tin khớp với hệ thống, họ sẽ nhận hàng ngay lập tức Trong trường hợp có vấn đề về tình trạng hoặc chất lượng sản phẩm, nhân viên sẽ nhanh chóng xử lý và có các biện pháp bồi thường hợp lý cho khách hàng về thời gian và tài sản.
Quy trình quản lí nhân viên:
Cửa hàng có đội ngũ nhân viên gồm một quản lý, một quản lý nhân sự, một nhân viên trông xe, một nhân viên thu ngân và một quản lý thông tin máy tính Thông tin của các nhân viên được lưu trữ trên máy tính để phục vụ cho việc chấm công và phát lương.
Công của nhân viên được tính theo ca làm việc:
Part time : + Ca sáng: 5h-11h: 120.000đ/ 1 ca
Ngoài tiền lương nhân viên còn được thưởng theo doanh thu của cửa hàng trong 1 tháng.
+ Đối với nhân viên part time: 1 tháng chỉ được phép nghĩ 4 ngày/tháng. + Đối với nhân viên full time: 1 tháng được phép nghĩ 6 ngày/ tháng.
Yêu cầu nghĩ phải báo trước 1 tuần để quản lí nhân sư sắp xếp lịch phù hợp.
1.1.5 Ưu nhược điểm của hệ thống hiên tại
Đơn giản, dễ sử dụng không yêu cầu cao về trình độ tin học.
Giá cả hợp lý phù hợp cho mọi người.
Hệ thống quản lý hiện tại dựa vào sổ sách và Excel vẫn còn thủ công và đơn giản, dẫn đến khó khăn trong việc xử lý dữ liệu lớn, dễ gây ra thất thoát và nhầm lẫn Việc sao lưu và phục hồi dữ liệu trở nên phức tạp và không hiệu quả.
Chưa thực sự có một hệ thống đánh giá của khách hàng về cửa hàng.
Mức độ chuyên môn hóa với công việc của nhân viên chưa cao.
Hệ thống quản lý hiện tại đang gặp khó khăn trong việc quản lý thông tin, điều này đặt ra thách thức cho cửa hàng trong việc nâng cao năng suất làm việc và cải thiện sự hài lòng của khách hàng Do đó, việc nâng cấp hệ thống quản lý là cần thiết và cấp bách, đặc biệt trong bối cảnh số lượng khách hàng ngày càng tăng và nhu cầu của họ ngày càng cao.
Xác lập dự án
1.2.1 Mục tiêu của dự án mới
Hệ thống nhân viên có nghiệp vụ cao giúp hỗ trợ khách hàng nhanh chóng và hiệu quả, đáp ứng mọi yêu cầu của họ Đồng thời, hệ thống cũng hỗ trợ quản lý, cung cấp báo cáo thống kê để nắm bắt tình hình hoạt động của cửa hàng, từ đó đưa ra các phương hướng phát triển hợp lý trong tương lai.
Giảm bớt chi phí, thời gian, sức lực nhằm nâng cao hiệu quả làm việc, thúc đẩy phát triển hoạt động của cửa hàng.
1.2.2 Yêu cầu của hệ thộng mới
Thực hiện tốt các chức năng chính hiện tại.
Tuân thủ các quy tắc của cửa hàng.
Bảo mật tốt, chỉ làm việc với người có quyền sử dụng.
Hệ thống phải có chế sao lưu phục hồi dữ liệu, nhằm đảm bảo an toàn về mặt dữ liệu.
Có thêm chức năng đánh giá nhân viên và ghi nhận phản hồi của khách hàng.
1.2.3.Phạm vi thực hiện dự án
Các chức năng chính của dự án:
Quản lý thông tin nhân viên
Xây dựng hệ thống quản lý cơ sở dữ liệu quản trị SQL server (SQL server 2019).
Trình biên dịch: Visual studio 2019.
Chi phí hệ thống máy tính: 15.000.000 đồng
Chi phí dự trù bảo trì và nâng cấp: 5.000.000 đồng
Chi phí đào tạo tin học cho nhân viên: 3.000.000 đồng
Chi phí đường truyền mạng: 400.000đ/1 tháng
Chi phí cho người viết phần mềm: 10.000.000 đồng
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG
ác định các chức năng
1.Quản lý Thông Tin Sản Phẩm
Quản lý sản phẩm hiệu quả bao gồm việc thêm mới, cập nhật hoặc xóa thông tin sản phẩm như tên, đơn vị, giá bán và số lượng tồn kho Ngoài ra, người dùng có thể tìm kiếm nhanh chóng thông tin sản phẩm dựa trên các tiêu chí như tên sản phẩm, mã sản phẩm hoặc nhà cung cấp.
2.Quản lý Nhà Cung Cấp
-Thêm, Sửa, Xóa Nhà Cung Cấp: Quản lý thông tin về các nhà cung cấp, bao gồm tên nhà cung cấp, địa chỉ, và số điện thoại.
-Liệt Kê Các Nhà Cung Cấp: Hiển thị danh sách các nhà cung cấp và thông tin liên quan.
3.Quản lý Hóa Đơn Nhập
Nhập Hóa Đơn Mới là quy trình quan trọng trong việc ghi lại thông tin về các hóa đơn nhập hàng mới Quy trình này bao gồm việc ghi chú ngày nhập, nhà cung cấp, và các chi tiết liên quan đến sản phẩm được nhập kho Việc thực hiện chính xác các bước này giúp quản lý hàng tồn kho hiệu quả hơn.
-Xem Lịch Sử Hóa Đơn Nhập: Hiển thị lịch sử các hóa đơn nhập, chi tiết số lượng, và tổng tiền.
4.Quản lý Hóa Đơn Bán
-Tạo Hóa Đơn Bán Hàng: Ghi lại thông tin về các hóa đơn bán hàng, bao gồm ngày bán, khách hàng, và chi tiết về sản phẩm bán ra.
-In Hóa Đơn Bán: Tính năng in hóa đơn để cung cấp cho khách hàng hoặc lưu trữ nội dung.
-Thêm, Sửa, Xóa Thông Tin Khách Hàng: Quản lý thông tin về khách hàng,bao gồm tên, địa chỉ, và số điện thoại.
-Liệt Kê Danh Sách Khách Hàng: Hiển thị danh sách khách hàng và thông tin liên quan.
6.Quản lý Số Lượng Tồn Kho
-Xem Tình Trạng Tồn Kho: Hiển thị thông tin về số lượng tồn kho của từng loại sản phẩm để quản lý việc tái tồn kho và đặt hàng.
-Thông Báo Khi Số Lượng Tồn Kho Thấp: Gửi thông báo hoặc cảnh báo khi số lượng tồn kho của một loại sản phẩm giảm xuống mức đặt trước.
7.Báo Cáo và Thống Kê
-Tạo Báo Cáo Doanh Thu: Tổng hợp và hiển thị báo cáo doanh thu theo khoảng thời gian, loại sản phẩm, hoặc khách hàng.
-Thống Kê Bán Hàng và Nhập Kho: Hiển thị thông tin thống kê về số lượng sản phẩm đã bán, nhập vào, và doanh thu.
* Mô hình phân rã chức năng của hệ thống
*Xác định mô hình luồng dữ liệu mức khung cảnh
*Xác định mô hình luồng dữ liệu mức đỉnh
*Xác định mô hình luồng dữ liệu mức dưới đỉnh-Quản lý sản phẩm
Xác định các thực thể và mô hình thực thể liên kết
+ Thuộc tính: Mã sản phẩm (PK), Tên sản phẩm, Đơn vị, Giá bán, Số lượng tồn kho.
-Thực thể "Nhà Cung Cấp":
+ Thuộc tính: Mã nhà cung cấp (PK), Tên nhà cung cấp, Địa chỉ, Số điện thoại.
+ Thuộc tính: Mã hóa đơn (PK), Ngày nhập, Tổng tiền, Mã nhà cung cấp Mỗi hóa đơn nhập liên kết với một nhà cung cấp.
-Thực thể "Chi Tiết Nhập Kho":
Mỗi chi tiết nhập kho bao gồm các thuộc tính như mã chi tiết (PK), số lượng nhập, đơn giá, mã sản phẩm và mã hóa đơn nhập Những thông tin này giúp liên kết từng sản phẩm cụ thể với hóa đơn nhập tương ứng.
+ Thuộc tính: Mã hóa đơn (PK), Ngày bán, Tổng tiền, Mã khách hàng.Mỗi hóa đơn bán liên kết với một khách hàng.
-Thực thể "Chi Tiết Bán Hàng":
+ Thuộc tính: Mã chi tiết (PK), Số lượng bán, Đơn giá, Mã sản phẩm, Mã hóa đơn.
Mỗi chi tiết bán hàng liên kết với một sản phẩm cụ thể và một hóa đơn bán cụ thể.
+ Thuộc tính: Mã khách hàng (PK), Tên khách hàng, Địa chỉ, Số điện thoại.
*Mô hình liên kết thực thể
Mô tả chi tiết các bảng dữ liệu
+ Masp (Khóa chính): Mã sản phẩm.
+ DonVi: Đơn vị đo lường của sản phẩm.
+ GiaBan: Giá bán của sản phẩm.
+ SoLuongTonKho: Số lượng tồn kho của sản phẩm.
+ MaNCC (Khóa chính): Mã nhà cung cấp. + TenNCC: Tên nhà cung cấp.
+ DiaChi: Địa chỉ của nhà cung cấp.
+ SDT: Số điện thoại của nhà cung cấp.
+ MaHoaDonNhap (Khóa chính): Mã hóa đơn nhập.
+ TongTien: Tổng tiền của hóa đơn nhập.
+ MaNCC (Khóa ngoại): Mã nhà cung cấp (liên kết với bảng NhaCungCap).
+ MaChiTietNhap (Khóa chính): Mã chi tiết nhập kho.
+ SoLuongNhap: Số lượng sản phẩm nhập vào.
+ DonGia: Đơn giá của sản phẩm.
+ Masp (Khóa ngoại): Mã sản phẩm (liên kết với bảng Dogo).
+ MaHoaDonNhap (Khóa ngoại): Mã hóa đơn nhập (liên kết với bảng NhapKho).
+ MaHoaDon (Khóa chính): Mã hóa đơn bán.
+ TongTien: Tổng tiền của hóa đơn bán.
+ Makh (Khóa ngoại): Mã khách hàng (liên kết với bảng KhachHang).
+ MaChiTiet (Khóa chính): Mã chi tiết bán hàng.
+ SoLuongBan: Số lượng sản phẩm bán ra.
+ DonGia: Đơn giá của sản phẩm.
+ Masp (Khóa ngoại): Mã sản phẩm (liên kết với bảng Dogo).
+ MaHoaDonBan (Khóa ngoại): Mã hóa đơn bán (liên kết với bảng BanHang).
+ Makh (Khóa chính): Mã khách hàng.
+ DiaChi: Địa chỉ của khách hàng.
+ SDT: Số điện thoại của khách hàng.