Báo cáo giữa kỳ Kiểm thử phần mềm nhúng (KMA)

Tổng hợp những câu hỏi cần thiết và quan trọng của môn Kiểm thử phần mềm nhúng (KMA). Tài liệu này giúp các bạn sinh viên có thể vượt qua các bài kiểm tra giữa kỳ, cuối kỳ và đạt kết quả cao nhất. Xin cảm ơn các bạn đã xem và tải tài liệu.

TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

Tổng quan về kiểm thử phần mềm

1.1.1 Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi Có thể xem kiểm thử phần mềm là việc “chạy thử” phần mềm hay một chức năng phần mềm xem nó “chạy” đúng như mong muốn hay không.

1.1.2 Nguyên tắc kiểm thử phần mềm (7 nguyên tắc vàng)

Kiểm thử đưa ra lỗi: Việc của tester là chứng minh phần mềm có lỗi chứ không kết luận được là hoàn toàn không có lỗi.

Kiểm thử toàn diện là không thể: Chấp nhận có phần trăm rủi ro thấp.

Kiểm thử càng sớm càng tốt: Nên bắt đầu sớm nhất có thể trong chu kỳ phát triển.

Sự tập trung của lỗi: Các lỗi thường nằm trong một số module nhất định nào đó chứ không phải trong tất cả các module.

 Nguyên tắc vàng (Nguyên lý Pareto): 80% lỗi có nguyên nhân từ 20% các module.

 Cô lập và kiểm thử những module khả nghi nhất.

“Hiệu ứng thuốc trừ sâu”:

 Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ có một số trường hợp kiểm thử (test case) sẽ không còn tìm thấy bất kỳ lỗi nào mới.

 Các kịch bản cần rà soát và xem xét lại đều đặn.

 Kịch bản kiểm thử lại cần bổ sung hoặc viết lại để tìm thêm khiếm khuyết.

Kiểm thử phụ thuộc vào ngữ cảnh: Kiểm thử cần được thực hiện trong những ngữ cảnh khác nhau. Ảo tưởng “không lỗi”:

 Sẽ rất sai lầm nếu “ảo tưởng” rằng cứ tìm và sửa chữa một số lượng lớn các lỗi sẽ đảm bảo sự thành công của một hệ thống.

 Bởi vì, một hệ thống “không lỗi” là vô nghĩa nếu: Khó sử dụng, không đáp ứng yêu cầu cần thiết, không đáp ứng kỳ vọng của người sử dụng, …

Quy trình kiểm thử phần mềm

1.2.1 Kế hoạch kiểm thử (Test plan)

Kế hoạch kiểm thử là một tài liệu mô tả mục tiêu, phạm vi, phương pháp, công cụ để thực hiện công việc kiểm thử.

Tầm quan trọng của việc lập kế hoạch kiểm thử:

 Xác định các vấn đề cần thiết để xác nhận chất lượng của ứng dụng đang kiểm thử.

 Giúp người ngoài nhóm kiểm thử (developers, manager, customer) hiểu chi tiết về kiểm thử.

 Có thể được tái sử dụng trong dự án khác.

Các bước xây dựng kế hoạch kiểm thử:

 Bước 1: Phân tích sản phẩm cần kiểm thử để hiểu chi tiết về sản phẩm.

 Bước 2: Thiết kế chiến lược kiểm thử để xác định mục tiêu kiểm thử của dự án và các phương tiện để đạt được mục tiêu Cần phải xác định chi phí cần để kiểm thử một cách rõ ràng và thường được phát triển bởi Test Manager.

 Bước 3: Xác định mục tiêu kiểm thử: Liệt kê các tính năng phần mềm (chức năng, hiệu suất, GUI,…) có thể cần kiểm thử, xác định mục tiêu kiểm thử dựa trên các tính năng phần mềm, xác định tiêu chí dừng kiểm thử.

 Bước 4: Hoạch định nguồn nhân lực để lập lên bản tóm tắt chi tiết các loại tài nguyên (con người, thiết bị, vật liệu, …) cần để hoàn thành dự án.

 Bước 5: Kế hoạch môi trường kiểm thử để tạo nên thiết lập giữa phần mềm và phần cứng mà nhóm kiểm thử sẽ thực hiện các test case bao gồm: môi trường và người dùng thực tế, môi trường vật lý như máy chủ, …

 Bước 6: Lịch trình và ước lượng: Cần thiết kế lịch trình thực hiện kiểm thử và đảm bảo rằng các hoạt động kiểm thử được thực hiện đúng thời gian và theo đúng kế hoạch đã đề ra Ước lượng chi phí kiểm thử một cách rõ ràng và trực quan để đảm bảo không bị thiếu hụt trong quá trình kiểm thử.

 Bước 7: Bàn giao sản phẩm kiểm thử: Sau khi hoàn thành các hoạt động kiểm thử, cần đánh giá kết quả kiểm thử và báo cáo lại cho các bên liên quan về mức độ hoàn thành, các lỗi được tìm tháy, các khiểm khuyết và các đề xuất cải tiến Chuẩn bị sẵn tài liệu hướng dẫn quy trình kiểm thử và những ghi chú cần thiết.

1.2.2 Đặc tả tình huống kiểm thử Đặc tả tình huống kiểm thử là quá trình kỹ thuật viên thực hiện lên kế hoạch chi tiết về kịch bản kiểm thử (test scenario), trên cơ sở đó sẽ xây dựng các bộ kiểm thử (test case/ test script).

1.2.2.1 Kịch bản kiểm thử (Test scenario)

Test Scenario bao gồm tất cả các chức năng có thể được kiểm thử và còn được gọi là Test Condition hoặc Test Possibility.

Mục đích của Test Scenario:

 Cung cấp cái nhìn tổng thể cho các tester, nhà phân tích, nhà phát triển, khách hàng,…

 Tạo đề xuất về tổ chức hoặc nguồn nhân lực.

 Các Tester sẽ dựa trên Test Scenario để xây dựng các Test Case/Test Script.

Các bước tạo kịch bản kiểm thử từ bản đặc tả:

 Bước 1: Đọc các tài liệu đặc tả, các sách hướng dẫn, tài liệu thiết kế,… của ứng dụng cần kiểm thử.

 Bước 2: Đối với mỗi yêu cầu, hãy xác định các hành động và mục tiêu có thể của người dùng.

 Bước 3: Mỗi kịch bản thử nghiệm có thể gắn với một hoặc nhiều yêu cầu. Chú ý, kịch bản thử nghiệm nhiều yêu cầu cùng lúc cần có kịch bản kiểm thử riêng từng yêu cầu.

1.2.2.2 Ca kiểm thử (Test Case)

Ca kiểm thử (Test Case) là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thoả mãn yêu cầu đặt ra hay không.

Một Test Case mô tả dữ liệu đầu vào (input), hành động (action) và kết quả mong đợi (expected respone), để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không.

Mô tả Test Case chi tiết hay ngắn gọn phụ thuộc vào quy mô của dự án hay quy mô của công ty sản xuất phần mềm.

Một số chú ý khi thiết kế Test Case:

 Quy ước đặt tên: ngắn gọn, dễ hiểu, có đánh số thứ tự, thường gắn với tên dự án và tên của module kiểm thử.

 Phần miêu tả cần đưa ra nhiều thông tin cần thiết nhất có thể.

 Điều kiện tiên quyết và các giả định: liệt kê tất cả các thông tin về các điều kiện và giả định cần trước khi test

 Chia các test case thành các nhóm nhỏ theo các trình tự đặc biệt.

Là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hoá một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi.

Test Script giống Test Case, chỉ khác về hình thức sử dụng: Test Script được viết để chạy trong quá trình kiểm thử tự động.

Mục đích: Thực hiện các bước kiểm thử đã thiết kế (hoặc thực thi các Test Script nếu tiến hành tự động) và ghi nhận các kết quả.

 Cài đặt môi trường kiểm thử, thực hiện kiểm thử theo kịch bản và ca kiểm thử.

 Đánh giá quá trình kiểm thử: Nếu có lỗi thì phân tích để tìm nguyên nhân, mô tả để khắc phục lỗi và lặp lại quá trình kiểm thử.

 Thẩm định kết quả kiểm thử: Mục đích để đảm bảo kết quả nhận được là đáng tin cậy cũng như nhận biết được chi tiết lỗi xảy ra.

1.2.4 Đánh giá và lập báo cáo

Mục đích: Đánh giá toàn bộ quá trình kiểm thử bao gồm xem xét và đánh giá kết quả kiểm thử, liệt kê lỗi, chỉ định các yêu cầu thay đổi và tính toán các số liệu có liên quan đến quá trình kiểm thử. Đánh giá khác với thẩm định kiểm thử: Mang tính toàn cục và nhằm hướng đến bản thân giá trị của các kết quả kiểm thử.

 Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa.

 Đánh giá độ bao phủ

 Xác định quá trình kiểm thử có đạt yêu cầu không

Các mức kiểm thử phần mềm

1.3.1 Kiểm thử đơn vị (Unit Testing)

Là hoạt động kiểm thử nhỏ nhất, nó được thực hiện trên các hàm hay các thành phần riêng lẻ Người thực hiện là developers.

Mục đích chính: Cô lập từng thành phần trong chương trình và chứng minh các bộ phận riêng lẻ, chính xác về các yêu cầu chức năng. Ưu điểm:

 Phát hiện và sửa lỗi sớm (giai đoạn lập trình).

 Tài liệu kiểm thử có thể tái sử dụng lại.

 Độc lập với các thành phần khác của hệ thống.

 Không thể phát hiện mọi lỗi của chương trình.

 Khi thay đổi interface của module thì phải sửa lại nhiều testcase

Kỹ thuật sử dụng: Kỹ thuật bao phủ code (code coverage) – thống kê dựa vào số lượng code được kiểm tra.

 Bao phủ dòng lệnh (Statement Coverage)

 Bao phủ nhánh (Branch/Decision Coverage)

 Bao phủ điều kiện (Condition Coverage)

 Bao phủ Finite State Machine Coverage

Các công cụ kiểm thử đơn vị tự động hay dùng:

1.3.2 Kiểm thử tích hợp (Intergation Testing)

Kiểm thử tích hợp là loại kiểm thử trong đó các module của phần mềm được tích hợp logic, được kiểm thử theo nhóm và thực hiện sau khi kiểm thử đơn vị.

Mục tiêu: Phát hiện lỗi giao tiếp xảy ra giữa các Unit, tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsytem) và cuối cùng là hệ thống hoàn chỉnh để chuẩn bị cho kiểm thử mức System.

Dữ liệu của kiểm thử là tài liệu Đặc tả thiết kế Kiểm thử tập trung vào các giao diện và luồng xử lý thông tin giữa các module.

Có hai cách tiếp cận là Bigbang và tiếp cận tăng dần Bigbang là các thành phần được tích hợp cùng lúc, sau đó tiến hành kiểm thử Tiếp cận tăng dần là ghép hai hoặc nhiều module có liên quan đến logic, quá trình tiếp tục cho đến khi tất cả các module được thêm vào và hoàn thành quá trình kiểm thử.

1.3.3 Kiểm thử hệ thống (System Testing)

Kiểm thử hệ thống là phương pháp theo dõi, đánh giá hành vi của sản phẩm hoặc hệ thống phần mềm hoàn chỉnh và đã được tích hợp đầy đủ dựa trên bản đặc tả yêu cầu Được thực hiện sau Intergation Testing và Unit Testing.

Các điều kiện tiên quyết của kiểm thử hệ thống:

 Phải đảm bảo phần mềm được thống nhất kiểm tra.

 Kiểm thử tích hợp được thực hiện.

 Đảm bảo môi trường kiểm thử đã sẵn sàng.

Một số loại kiểm thử được thực hiện bởi kiểm thử hệ thống: Kiểm thử cài đặt, kiểm thử chức năng, kiểm thử khả năng phục hồi, kiểm thử độ tin cậy, kiểm thử hồi quy, kiểm thử bảo mật, …

1.3.4 Kiểm thử chấp nhận người dùng (User Acceptance Testing)

Kiểm thử chấp nhận người dùng là loại kiểm thử thực hiện bởi khách hàng để xác nhận hệ thống đã làm việc đúng như mong đợi và thoả mãn yêu cầu người dùng Được thực hiện vào giai đoạn kiểm thử cuối cùng trước khi phần mềm được đưa vào hoạt động chính thức. Điều kiện tiên quyết của kiểm thử chấp nhận người dùng:

 Phải đảm bảo các yêu cầu nghiệp vụ chính của ứng dụng.

 Phần mềm đã được hoàn thiện ở mức cao nhất.

 Các khâu kiểm thử: Kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống đã được hoành thành.

 Các lỗi quan trọng không còn tồn tại,

 Môi trường kiểm thử chấp nhận người dùng phải được chuẩn bị sẵn sàng

1.4 Các phương pháp kiểm thử

1.4.1 Kiểm thử hộp đen (Black – box Testing)

Hình 1.1 Kiểm thử hộp đen

Kiểm thử hộp đen (Black Box Testing) là một phương pháp kiểm thử phần mềm mà trong đó người thử nghiệm không biết về cấu trúc bên trong của phần mềm Họ chỉ kiểm tra và kiểm soát chức năng của phần mềm dựa trên đầu vào và đầu ra mà họ cung cấp Trong kiểm thử hộp đen, người thử nghiệm xem phần mềm như một “hộp đen” mà họ không biết được nội dung bên trong.

Một số ưu điểm của kiểm thử hộp đen:

 Khả năng tương quan với góc nhìn của người dùng cuối: Với kiểm thử hộp đen, người thử nghiệm không cần biết cách hoạt động bên trong của phần mềm, giống như người dùng cuối Điều này giúp họ có thể tập trung vào việc kiểm tra các chức năng và giao diện người dùng một cách chính xác.

 Khả năng phát hiện lỗi không mong đợi: Do người thử nghiệm không biết được cấu trúc bên trong của phần mềm, họ có thể tạo ra các ca kiểm thử mà những lập trình viên không nghĩ đến Điều này giúp tăng khả năng phát hiện các lỗi không mong đợi hoặc các tình huống bất thường.

 Được áp dụng một cách linh hoạt và đa dạng: Kiểm thử hộp đen có thể được áp dụng một cách linh hoạt và đa dạng cho nhiều loại phần mềm và dự án khác nhau, từ ứng dụng di động đến phần mềm máy tính lớn.

 Giảm thiểu sự phụ thuộc vào mã nguồn: Vì người thử nghiệm không cần biết về mã nguồn hoặc cấu trúc bên trong của phần mềm, kiểm thử hộp đen giảm thiểu sự phụ thuộc vào lập trình viên và giúp tạo ra các ca kiểm thử độc lập.

 Thích hợp cho giai đoạn cuối cùng của kiểm thử: Kiểm thử hộp đen thường được sử dụng trong giai đoạn cuối cùng của quy trình kiểm thử để kiểm tra tính đầy đủ và tính toàn diện của phần mềm trước khi phát hành. Một số nhược điểm của kiểm thử hộp đen:

 Giới hạn trong việc phát hiện lỗi phức tạp: Vì người thử nghiệm không biết về cấu trúc bên trong của phần mềm, họ có thể gặp khó khăn trong việc phát hiện các lỗi phức tạp liên quan đến logic hoặc cấu trúc nội bộ của phần mềm.

 Khả năng kiểm thử không toàn diện: Do kiểm thử hộp đen tập trung vào việc kiểm tra chức năng từ góc nhìn của người dùng, nó có thể bỏ qua một số khía cạnh khác như hiệu suất, bảo mật hoặc tính mở rộng của phần mềm.

 Yêu cầu ca kiểm thử chi tiết: Để đạt được mức độ kiểm thử chính xác và đầy đủ, các ca kiểm thử cần phải được thiết kế một cách chi tiết và toàn diện Điều này đòi hỏi nhiều thời gian và công sức từ phía người thử nghiệm.

KẾ HOẠCH KIỂM THỬ

Tổng quan về hệ thống cho thuê nhà

Hệ thống cho thuê nhà là một công cụ giúp chủ nhà và người thuê nhà đơn giản hóa quá trình cho thuê nhà Hoạt động nghiệp vụ của một hệ thống cho thuê nhà có thể được tóm tắt như sau:

 Chủ nhà sẽ đăng thông tin về nhà cho thuê với các thông tin sau: Vị trí, giá cho thuê phòng, đối tượng cho thuê phòng, số điện thoại, thông tin chi tiết về phòng, các tiện nghi và dịch vụ.

 Người thuê nhà cần phải có tài khoản nếu muốn thuê nhà Khi đăng ký thuê nhà người thuê cần cung cấp đầy đủ thông tin cá nhân: tên, tuổi, địa chỉ, năm sinh, giới tính, số điện thoại, email, căn cước công dân.

 Sau khi kiểm tra thông tin cá nhân, chủ nhà có thể liên lạc lại với người thuê nhà để hẹn gặp mặt trao đổi Nếu hai bên đồng ý thì chủ nhà có thể cập nhập người thuê nhà mới lên trên ứng dụng, một số thông tin về người thuê nhà sẽ được lưu lại để chủ nhà có thể quản lý Người thuê nhà sẽ nhận được thông báo về việc đã được thêm vào nhà cho thuê và có thể xem thông tin thuê nhà tại trang cá nhân của mình.

 Khi người thuê nhà ngừng thuê nhà: Chủ nhà trọ dựa theo thông tin đã được lưu để quản lý để xóa người thuê nhà ra khỏi danh sách người thuê nhà, đồng thời liên hệ gặp mặt nếu cần.

 Người thuê nhà trong quá trình thuê nếu trả tiền muộn sẽ nhận thông báo cảnh báo, nếu quá mức hẹn trong hợp đồng hai bên thỏa thuận sẽ chịu phạt theo hợp đồng.

 Trong quá trình cho thuê, người thuê nhà có thể yêu cầu sửa chữa đối với nhà cho thuê, tiền sửa chữa được thỏa thuận giữa người thuê nhà và chủ nhà.

Mục tiêu kiểm thử

Mục tiêu chính là đảm bảo rằng ứng dụng di động cho thuê nhà hoạt động một cách đáng tin cậy và cung cấp trải nghiệm người dùng tốt Xác định thông tin cơ bản về dự án và các thành phần chức năng được kiểm thử và những thành phần chức năng không được kiểm thử.

Mục tiêu cụ thể bao gồm kiểm tra tính bảo mật, tính đúng đắn và hiệu suất của các chức năng quan trọng như đăng nhập, đăng ký, đổi mật khẩu và thêm phòng.

Phạm vi kiểm thử

Kiểm thử chức năng đăng nhập: Xác định tính bảo mật và đúng đắn của quá trình đăng nhập với các tài khoản đã đăng ký.

 Kiểm tra việc đăng nhập bằng tên người dùng và mật khẩu chính xác.

 Kiểm tra việc đăng nhập thành công và chuyển hướng người dùng đến giao diện người dùng chính sau khi đăng nhập.

 Kiểm tra việc hiển thị thông báo lỗi hoặc cảnh báo nếu người dùng nhập sai tên người dùng hoặc mật khẩu.

Kiểm thử chức năng đăng ký: Đảm bảo rằng quá trình đăng ký hoạt động đúng đắn và an toàn, xác thực các thông tin cần thiết từ người dùng sao cho đúng với khuôn mẫu mà các trường nhập thông tin yêu cầu.

 Kiểm tra quy trình đăng ký mới bằng cách điền đầy đủ thông tin yêu cầu như tên, địa chỉ email, mật khẩu, v.v.

 Kiểm tra việc hiển thị thông báo xác nhận khi đăng ký thành công.

 Kiểm tra việc hạn chế đăng ký với thông tin trùng lặp hoặc không hợp lệ.

Kiểm thử chức năng đổi mật khẩu: Xác định tính bảo mật và đúng đắn của quá trình đổi mật khẩu, bao gồm việc xác thực mật khẩu hiện tại và xác nhận mật khẩu mới.

 Kiểm tra quy trình thay đổi mật khẩu bằng cách nhập mật khẩu hiện tại và mật khẩu mới.

 Kiểm tra việc hiển thị thông báo xác nhận khi mật khẩu được thay đổi thành công.

 Kiểm tra việc hạn chế việc thay đổi mật khẩu bằng cách yêu cầu xác nhận thông tin đăng nhập.

Kiểm thử chức năng thêm phòng: Kiểm tra tính chính xác và hoạt động của quá trình thêm phòng mới, bao gồm nhập dữ liệu và tải lên hình ảnh Các dữ liệu phải đúng đắn và xác thực.

 Kiểm tra quy trình thêm nhà mới bằng cách nhập thông tin như địa chỉ, mô tả, hình ảnh, giá, v.v.

 Kiểm tra việc hiển thị thông báo xác nhận khi nhà được thêm thành công.

 Kiểm tra việc hạn chế việc thêm nhà bằng cách xác nhận thông tin đăng nhập và quyền truy cập.

Nhiệm vụ thành viên

STT Thành viên Nhiệm vụ

1 Ninh Thị Thu Phương Viết các test case cho chức năng đăng ký, đăng nhập, thực hiện đánh giá và viết lại kết quả kiểm thử.

2 Mai Trung Kiên Viết các test case cho chức năng đổi mật khẩu, thực hiện đánh giá và viết lại kết quả kiểm thử.

3 Cao Văn Văn Viết các test case cho chức năng thêm nhà, thực hiện đánh giá và viết lại kết quả kiểm thử

Bảng 2.1 Bảng phân công nhiệm vụ của từng thành viên

Chiến lược kiểm thử

Kiểm thử chính xác của thông tin đăng nhập: Tạo các ca kiểm thử để nhập tên người dùng và mật khẩu chính xác và kiểm tra xem người dùng có thể đăng nhập thành công không.

Kiểm thử xử lý lỗi: Tạo các ca kiểm thử để nhập thông tin đăng nhập không hợp lệ (ví dụ: tên người dùng không tồn tại, mật khẩu sai) và kiểm tra xem ứng dụng xử lý lỗi như thế nào (hiển thị thông báo lỗi, hướng dẫn người dùng, v.v.) sau đó đưa ra nhận xét.

Kiểm thử quy trình đăng ký mới: Tạo các ca kiểm thử để điền thông tin đăng ký hợp lệ và kiểm tra xem người dùng có thể đăng ký thành công không.

Kiểm thử xử lý lỗi: Tạo các ca kiểm thử để điền thông tin đăng ký không hợp lệ (ví dụ: email đã tồn tại, mật khẩu quá ngắn) và kiểm tra xem ứng dụng xử lý lỗi như thế nào sau đó đưa ra nhận xét.

2.5.3 Chức năng Đổi mật khẩu

Kiểm thử quy trình thay đổi mật khẩu: Tạo các ca kiểm thử để nhập mật khẩu hiện tại và mật khẩu mới hợp lệ và kiểm tra xem người dùng có thể thay đổi mật khẩu thành công không.

Kiểm thử xử lý lỗi: Tạo các ca kiểm thử để nhập mật khẩu hiện tại hoặc mật khẩu mới không hợp lệ và kiểm tra xem ứng dụng xử lý lỗi như thế nào sau đó đưa ra nhận xét.

Kiểm thử quy trình thêm nhà mới: Tạo các ca kiểm thử để nhập thông tin nhà mới hợp lệ và kiểm tra xem nhà có được thêm vào hệ thống không.

Kiểm thử xử lý lỗi: Tạo các ca kiểm thử để nhập thông tin nhà không hợp lệ và kiểm tra xem ứng dụng xử lý lỗi như thế nào sau đó đưa ra nhận xét.

Kiểm thử tính hợp lệ của thông tin nhập vào: Kiểm tra tính hợp lệ của thông tin nhập vào (ví dụ: giá thuê phải là số dương, diện tích không thể âm) để đảm bảo tính chính xác của dữ liệu.

Điều kiện chấp nhận

Việc xác định và thiết lập các điều kiện chấp nhận rõ ràng sẽ giúp đảm bảo rằng các ca kiểm thử được thực hiện một cách đúng đắn và hiệu quả.

 Các thao tác được thực hiện theo đúng yêu cầu của ứng dụng.

 Hệ thống phản hồi đúng và kịp thời với hành động của người dùng.

 Dữ liệu được xử lý và lưu trữ một cách an toàn và chính xác.

Defect Tracking

Bảng phân loại lỗi theo mức độ nghiêm trọng được sử dụng để đánh giá và ưu tiên xử lý các lỗi trong quá trình phát triển phần mềm.

Mức độ nghiêm trọng Đặc tả lỗi

- Là những lỗi nghiêm trọng, gây ra sự cố hoặc ảnh hưởng lớn đến chức năng hoặc hiệu suất của hệ thống.

- Có thể gây ra mất dữ liệu quan trọng hoặc tổn thất lớn về tiền bạc hoặc uy tín.

- Yêu cầu phải được khắc phục ngay lập tức hoặc trong thời gian ngắn để tránh những hậu quả nghiêm trọng.Medium (M) - Là những lỗi ảnh hưởng đến tính năng hoặc hiệu suất của hệ thống, nhưng không gây ra sự cố nghiêm trọng.

- Có thể gây ra mất dữ liệu nhỏ hoặc làm gián đoạn quá trình làm việc của người dùng.

- Yêu cầu phải được xử lý trong thời gian ngắn để không ảnh hưởng đến trải nghiệm người dùng hoặc tiến độ dự án.

- Là những lỗi nhỏ, không ảnh hưởng nghiêm trọng đến chức năng hoặc hiệu suất của hệ thống.

- Thường là các vấn đề trực quan hoặc tính năng không quan trọng.

- Không gây ra mất dữ liệu hoặc sự cố lớn.

- Thường được ưu tiên xử lý sau các lỗi mức medium và high.

Bảng 2.2 Bảng phân loại mức độ lỗi

2.7.2 Quy trình xử lý lỗi

Mức độ nghiêm trọng Mô tả

High (H) Ghi nhận và phân loại lỗi, ưu tiên cao hơn so với các loại lỗi khác, gán người phụ trách và xử lý lỗi, kiểm tra và xác nhận sửa lỗi, cập nhật với người dùng hoặc bên liên quan.

Medium (M) Ghi nhận và phân loại lỗi, ưu tiên sau lỗi high và trước lỗi low, gán người phụ trách và xử lý lỗi, kiểm tra và xác nhận sửa lỗi, cập nhật với người dùng hoặc bên liên quan.

Low (L) Ghi nhận và phân loại lỗi, ưu tiên thấp nhất, gán người phụ trách và xử lý lỗi, kiểm tra và xác nhận sửa lỗi, cập nhật với người dùng hoặc bên liên quan (nếu cần).

Bảng 2.3 Bảng quy trình xử lý theo từng mức độ lỗi

Thiết kế các Test Case

2.8.1 Chức năng Đăng ký (ký hiệu DK)

ID Test Cases Test Step Expected Result Pass/

Tên không để trống - Không nhập giá trị vào trường tên.

- Di chuyển sang trường tiếp theo.

Thông báo: “Vui lòng nhập tên”

Tên không có ký tự đặc biệt

Nhập các ký tự đặc biệt vào trường tên

“Không được phép nhập ký tự đặc biệt”

Tên không được có chữ số

Nhập các số vào trường tên

“Không được phép sử dụng số phải sử dụng chữ”

Tên không được có khoảng trắng ở ký tự đầu tiên

Nhập dấu cách ở ký tự đầu tiên trong trường tên

Thông báo: “Ký tự đầu tiên không được sử dụng dấu cách”

Email không được để trống

- Không nhập giá trị vào trường Email

- Di chuyển sang trường tiếp theo

Thông báo: “Email không để trống, vui lòng nhập email” Pass

Email định dạng không hợp lệ

Nhập định dạng không hợp lệ trong trường Email

Thông báo: “Email không hợp lệ, vui lòng nhập lại” Pass

Email không được có ký tự đầu tiên là ký tự đặc biệt hoặc số

Nhập các ký tự đầu tiên là ký tự đặc biệt trong trường email

“Không được phép sử dụng các ký tự đặc biệt”

PassDK_0 Nhập đúng các Nhập giá trị Thông báo: “Email Fail

8 trường còn lại nhưng để trống email cho các trường còn lại nhưng để trống email không được để trống, vui lòng nhập email”

Email đã tồn tại trong hệ thống

Nhập địa chỉ email vào trường email

Thông báo: “Email đã tồn tại, vui lòng nhập lại địa chỉ email”

Mật khẩu không được để trống

- Không nhập giá trị vào trường mật khẩu

Thông báo: “Vui lòng nhập mật khẩu”

Nhập mật khẩu quá ngắn so với độ dài đưa ra

Thông báo: “Mật khẩu quá ngắn, vui lòng nhập lại mật khẩu”

Mật khẩu không đủ mạnh (không chứa các ký tự đặc biệt, chữ hoa, chữ thường, số)

Nhập mật khẩu đơn giản dễ đoán

Thông báo: “Mật khẩu phải chứa ít nhất một ký tự đặc biệt”

Mật khẩu chứa ký tự đặc biệt nhưng không đủ dài

Nhập mật khẩu Thông báo: “Mật khẩu quá ngắn, vui lòng nhập lại mật khẩu”

Mật khẩu nhập lại không khớp với mật khẩu ban đầu

Thông báo: “Mật khẩu không khớp, vui lòng nhập lại”

Mật khẩu nhập lại khớp với mật khẩu ban đầu

Thông báo: “Đăng ký thành công” Pass

Mật khẩu nhập lại không được để trống

- Không nhập giá trị vào trường nhập lại mật khẩu

Thông báo: “Mật khẩu nhập lại không được để trống, vui lòng nhập mật khẩu”

Số điện thoại không được để trống

- Không nhập giá trị vào trường số điện thoại

Thông báo: “Số điện thoại không được bỏ trống, vui lòng nhập số điện thoại”

Số điện thoại không được có ký tự đặc biệt

Nhập các ký tự đặc biệt vào trường số điện thoại

Thông báo: “Số điện thoại không được có các ký tự đặc biệt, vui lòng nhập lại”

Số điện thoại không được có các ký tự chữ

Nhập các chữ cái vào số điện thoại

Thông báo: “Số điện thoại không được có ký tự chữ cái, vui lòng nhập lại”

Số điện thoại không được để cách ký tự đầu tiên

Nhập dấu cách ở ký tự đầu tiên trong trường số điện thoại

Thông báo: “Số điện thoại không được để cách ký tự đầu tiên, vui lòng nhập lại”

1 Điền đầy đủ thông tin đăng ký

- Điền đầy đủ các thông tin vào các trường

Thông báo: “Đăng ký thành công”

Bảng 2.4 Bảng Test Case cho chức năng Đăng ký

2.8.2 Chức năng Đăng nhập (ký hiệu DN)

- Không nhập giá trị vào 2 trường username, password

Thông báo: “Mật khẩu không đúng, vui lòng nhập lại mật khẩu” Pass

- Nhập username đúng, password sai

Thông báo: “Mật khẩu không đúng, vui lòng nhập lại”

- Nhập username sai, password đúng

Thông báo: “Tên đăng nhập không đúng vui lòng nhập lại”

- Nhập username đúng, password đúng

Thông báo: “Đăng nhập thành công”

- Không nhập giá trị vào trường username, nhập password

Thông báo: “Vui lòng nhập tên đăng nhập” Pass

- Điền username, không nhập giá trị vào trường password

Thông báo: “Vui lòng nhập mật khẩu” Pass

Nhấn phím login nhiều lần khi chưa nhập username, password

- Không nhập giá trị vào 2 trường username, password

- Click nút đăng nhập nhiều lần

Thông báo chỉ hiển thị một lần duy nhất, mỗi lần tồn tại 5s, hết 5s thì sẽ hiển thị thông báo mới

Nhấn phím login nhiều lần khi chưa nhập password

- Điền username, không nhập giá trị vào trường password

Nhấn phím login nhiều lần khi chưa nhập username

- Không nhập giá trị vào trường username, nhập password

DN_1 Nhấn phím login - Nhập username Thông báo chỉ hiển Fail

0 nhiều lần khi nhập sai username, password sai, password sai

- Click nút đăng nhập nhiều lần thị một lần duy nhất, mỗi lần tồn tại 5s, hết 5s thì sẽ hiển thị thông báo mới

Bảng 2.5 Bảng Test Case cho chức năng Đăng nhập

2.8.3 Chức năng Thay đổi mật khẩu (ký hiệu MK)

MK_01 Xác minh rằng người dùng có thể thực hiện chức năng thay đổi mật khẩu thành công và đi đến một thông báo hoặc đường dẫn sau đó rõ ràng đúng quy trình

- Click vào biểu tượng thay đổi mật khẩu và thực hiện các yêu cầu

- Click vào biểu tượng xác nhận thay đổi

Thông báo: “Cập nhật mật khẩu thành công”

MK_02 Mật khẩu mới phải có ít nhất 1 chữ số

Thông báo: “Mật khẩu mới phải chứa ít nhất một số”

MK_03 Mật khẩu mới phải có ít nhất 1 ký tự

Thông báo: “Mật khẩu mới phải chứa ít nhất một ký tự”

MK_04 Mật khẩu mới phải có ít nhất 1 ký tự in hoa

- Click vào biểu tượng thay đổi mật khẩu và thực

Thông báo: “Mật khẩu mới phải chứa ít nhất một ký tự in hoa”

Pass hiện các yêu cầu

- Click vào biểu tượng xác nhận thay đổi MK_05 Mật khẩu mới phải có ít nhất một ký tự đặc biệt

Thông báo: “Mật khẩu mới phải chứa ít nhất một ký tự đặc biệt”

MK_06 Mật khẩu mới phải có ít nhất 8 ký tự

Thông báo: “Mật khẩu mới phải có ít nhất 8 ký tự”

MK_07 Mật khẩu cũ không trùng khớp với mật khẩu hiện tại

Thông báo: “Mật khẩu cũ không đúng”

MK_08 Mật khẩu cũ không trùng khớp với mật khẩu hiện tại và ấn cập nhật mật khẩu nhiều lần

- Click vào biểu tượng thay đổi mật khẩu và thực hiện Thông báo: “Mật khẩu không đúng định dạng vui lòng

Thông báo: “Mật khẩu không đúng định dạng vui lòng nhập lại” Hiển thị

1 lần duy nhất và tồn tại trong khoảng 5s, hết 5s mới hiển thị tiếp

Fail nhập lại”các yêu cầu

Bảng 2.6 Bảng Test Case cho chức năng Thay đổi mật khẩu

2.8.4 Chức năng Thêm phòng (ký hiệu TP)

ID Test Cases Test Step Expected

1 Ảnh (PNG hợp lệ), Giá

(đủ độ dài và định dạng), Địa chỉ (đủ độ dài và định dạng), Mô tả (đủ độ dài và định dạng), Tên nhà (không vượt quá độ dài)

- Điền đầy đủ thông tin phòng

- Click xác nhận thêm phòng

Một trong số các trường giá, số phòng, địa chỉ, giá thuê phòng, mô tả, tên nhà để trống

“Trường giá/ tên nhà/ số phòng/ giá thuê phòng/ mô tả không được để trống”

3 Địa chỉ dài hơn 400 ký tự

“Địa chỉ nhà chỉ chứa ít nhất hơn 400 ký tự”

Số phòng có chứa ký tự khác ngoài số

“Số phòng phải là số và

- Click xác nhận thêm phòng nhỏ hơn

“Số phòng phải là số và nhỏ hơn

Giá phòng có chứa ký tự khác ngoài số

“Giá thuê mỗi phòng phải là số và nhỏ hơn 20.000.000”

Mô tả phòng vượt quá

“Mô tả nhà phải ít hơn

Tên nhà vượt quá 30 ký tự

“Tên nhà phải ít hơn 30 ký tự”

Không cung cấp ảnh phòng, Giá (nằm trong khoảng 0 –

(đủ độ dài và định dạng), Mô tả (đủ độ dài và định dạng), Tên nhà (không vượt quá độ dài)

“Yêu cầu nhập ảnh minh hoạ về nhà” Fail

0 – 20.000.000), Số phòng (đủ độ dài và định dạng), Mô tả (đủ

Chờ đến khi ảnh nhà được tải lên thành công thì mới thực hiện

Fail độ dài và định dạng),

Tên nhà (không vượt quá độ dài) nhưng trong lúc ảnh nhà đang được tải lên lại ấn thêm nhà ngay lập tức thêm nhà

Bảng 2.7 Bảng Test Case cho chức năng Thêm phòng

THỰC HIỆN VÀ ĐÁNH GIÁ KẾT QUẢ KIỂM THỬ

Thực thi kiểm thử

3.1.1 Kết quả kiểm thử chức năng Đăng ký

Tên chức năng kiểm thử Đăng ký

Người kiểm thử Ninh Thị Thu Phương

Số trường hợp kiểm thử đạt (P) 18

Số trường hợp kiểm thử không đạt (F) 3

Số trường hợp kiểm thử chưa được thực hiện 0

Tổng số trường hợp kiểm thử 21

Tỉ lệ kiểm thử đạt (%) 86%

Bảng 3.1 Bảng Kết quả kiểm thử chức năng Đăng ký

Hình 3.1 Hình Kiểm thử chức năng Đăng ký

3.1.2 Kết quả kiểm thử chức năng Đăng nhập

Tên chức năng kiểm thử Đăng nhập

Người kiểm thử Ninh Thị Thu Phương

Tỉ lệ kiểm thử đạt (%) 60%

Bảng 3.2 Bảng kiểm thử chức năng Đăng nhập

Hình 3.2 Hình kiểm thử chức năng Đăng nhập

3.1.3 Kết quả kiểm thử chức năng Thay đổi mật khẩu

Tên chức năng kiểm thử Thay đổi mật khẩu

Người kiểm thử Mai Trung Kiên

Tỉ lệ kiểm thử đạt (%) 87.5%

Bảng 3.3 Bảng kiểm thử chức năng Thay đổi mật khẩu

3.1.4 Kết quả kiểm thử chức năng Thêm phòng

Tên chức năng kiểm thử Thêm phòng

Người kiểm thử Cao Văn Văn

Tỉ lệ kiểm thử đạt (%) 81.81%

Bảng 3.4 Bảng kiểm thử chức năng Thêm phòng

Đánh giá kết quả kiểm thử

 Tất cả các test case đã được thực thi.

 Tỷ lệ Test Case đạt khá cao : 80%.

 Tất cả các lỗi tìm thấy đều được rà soát lại nhiều lần và ghi nhận lý do rõ ràng.

Bảng 3.5 Bảng đánh giá kết quả kiểm thử

Kết luận

 Thiết kế và thực thi các testcase.

 Quan sát và tìm ra lỗi, đánh giá được lỗi theo mức độ

 Viết ra được tài liệu kiểm thử testcase.

 Giúp áp dụng được vào các dự án thực tế.

Định dạng
Số trang	36
Dung lượng	536,58 KB