Kiểm thử chức năng Compare trong dịch vụ đám mây Azure Cloud Backup
MỤC LỤC
Quy trình kiểm thử
Để cho việc kiểm thử đạt được kết quả tốt cần có sự chuẩn bị về kế hoạch kiểm thử, thiết kế các trường hợp kiểm thử và các dữ liệu kiểm thử cho các trường hợp. • Phân tích và thiết kế: Việc kiểm thử thường phải tiến hành một cách độc lập và các nhóm độc lập có trách nhiệm tiến hành các họat động kiểm thử.
Các cấp độ kiểm thử
Cũng như các mức kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước cỏc ca kiểm thử hoặc kịch bản kiểm thử, trong đú chỉ định rừ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Kiểm thử chấp nhận có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của kiểm thử hệ thống và kiểm thử chấp nhận gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.
Các kĩ thuật kiểm thử
Các nguyên tắc cơ bản của kiểm thử
Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để bảo đảm mọi đơn vị phần mềm và sự tương tác giữa chúng hoạt độngchính xác trước khi thực hiện kiểm thử hệ thống. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi “bế tắc” (deadlock) hoặc chiếm dụng bộ nhớ.
Kỹ thuật kiểm thử hộp trắng (White - Box Testing) Kiểm thử hộp trắng: Là kỹ thuật kiểm thử dựa trên đặc tả bên trong của
Tuy nhiên, một nhánh không đảm bảo được phủ bởi kiểm thử DU chỉ trong rất ít tình huống như cấu trúc if-then-else mà trong đó phần then không có một khai báo biến nào và có dạng khuyết (không tồn tại phần else). Đường thi hành (Execution path): là 1 kịch bản thi hành đơn vị phần mềm tương ứng: danh sách có thứ tự các lệnh được thi hành ứng với một lần chạy cụ thể của đơn vị phần mềm, bắt đầu từ điểm nhập của đơn vị phần mềm đến điểm kết thúc của đơn vị phần mềm.
Kỹ thuật kiểm thử hộp đen (Black - Box Testing) Kiểm thử hộp đen: là một phương pháp kiểm thử phần mềm được thực hiện
Bây giờ, dựa trên số liệu này, người kiểm tra có thể tạo các trường hợp kiểm tra bổ sung cho các kiểm tra còn lại. –Test coverage cũng giúp kiểm tra hồi quy, ưu tiên trường hợp kiểm thử, tăng cường bộ kiểm thử và tối thiểu hóa bộ kiểm thử. Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm, trong con mắt của các tester, giống như một hộp đen; bên trong mà người ta không thể nhìn thấy.
Các hệ thống thường phải được sử dụng nhiều phương pháp kiểm thử khác nhau để đảm bảo được chất lượng của hệ thống khi đến tay người dùng.
Kỹ thuật thiết kế Test case
Thay vì phải kiểm tra hết toàn bộ các giá trị trong từng vùng tương đương, kỹ thuật phân tích giá trị biên tập trung vào việc kiểm thử các giá trị biên của miền giá trị đầu vào để thiết kế ca kiểm thử do “lỗi thường tiềm ẩn tại cỏc ngừ ngỏch và tập hợp tại biờn” nờn sẽ tiết kiệm thời gian thiết kế ca kiểm thử và thực hiện kiểm thử. Trong kiểm thử phần mềm, đoán lỗi là một phương pháp kiểm thử, trong đó các trường hợp kiểm thử được sử dụng để tìm lỗi trong các chương trình đã được phát triển dựa vào kinh nghiệm trong các lần kiểm thử trước. Phạm vi của các trường hợp kiểm thử thường được dựa vào các kiểm thử viên có kiến thức liên quan, là những người đã có kinh nghiệm sử dụng và trực giác để xác định những tình huống thường gây ra lỗi trong phần mềm.
Phương phỏp đoỏn lỗi khụng cú quy tắc rừ ràng, ca kiểm thử cú thể được thiết kế tùy thuộc vào tình hình, hoặc hoặc luồng công việc trong các tài liệu mô tả chức năng hoặc khi một lỗi không mong muốn/ không được mô tả trong tài liệu được tìm thấy trong khi hoạt động kiểm thử.
Tạo Bug report
Bug và Bug report
• Bug: lỗi lập trình làm cho một chương trình hoặc một hệ máy tính chạy bị lỗi, cho kết quả sai, hoặc đổ vỡ. • Bug report: được hiểu là những mô tả lỗi phần mềm thực thi test phần mềm đó. Thông thường dân IT hay gọi bug report dưới cái tên vui tai là log Bug.
Cấu trúc một Bug report
• Tiờu đề phải rừ ràng: khi lập trỡnh viờn đọc bug, thứ đầu tiờn đập vào mắt là Summary. Một Summary tốt phải ngắn gọn và diễn tả được bug một cách tối giản, dễ hiểu. • Phải mô phỏng lại được quá trình gây ra bug: nếu không mô phỏng lại được, bug sẽ không thể được khắc phục.
Severity và Priority
–Critical: Bug khiến cho tiến trình hoạt động của toàn phần mềm bị ngưng hoàn toàn, không còn phần nào có thể chạy được. –Major: Bug nghiêm trọng, có thể là sập hệ thống nhưng có một số phần khác vẫn hoạt động được. –Low: Bug không gây ra bất kì sự cố lớn nào cho hệ thống, như là lỗi chính tả/ lỗi ngữ pháp.
Thông thường, những bug ảnh hưởng đến hoạt động của cả hệ thống sẽ được ưu tiên cao hơn những bug của các chức năng nhỏ.
Kiểm thử chức năng Compare function trong dịch vụ đám mây
Giới thiệu
Tích hợp với Microsoft Azure: AvePoint Cloud Backup for Azure được tích hợp trực tiếp với Azure Portal, cho phép bạn dễ dàng quản lý chính sách sao lưu và theo dừi quỏ trỡnh sao lưu và phục hồi. Khôi phục toàn bộ và phục hồi nhỏ gọn: Bạn có thể khôi phục toàn bộ máy chủ ảo, máy chủ SQL hoặc lưu trữ đối tượng, hoặc chỉ khôi phục các tập tin hoặc thư mục cụ thể. Bảo mật dữ liệu: AvePoint Cloud Backup for Azure bảo vệ dữ liệu của bạn bằng cách mã hóa dữ liệu trong quá trình truyền tải và lưu trữ.
Azure Cloud Backup cung cấp nhiều module để quản lý và bảo vệ dữ liệu của khách hàng trên các hạ tầng điện toán đám mây của Microsoft.
Đặc điểm
• Với trạng thái “Deleted”, chúng ta sẽ hiển thị các thuộc tính đối tượng trong Recovery point và khách hàng không thể chuyển Recovery point sang Azure AD Production vì đối tượng này đã bị xóa và không tồn tại trong môi trường Production thực. • Với trạng thái “Added”, chúng ta sẽ hiển thị các thuộc tính đối tượng trong Azure AD Production và khách hàng không thể chuyển sang Recovery Point vì đối tượng này mới được thêm vào Production và không tồn tại trong Recovery point. –Đối với đối tượng có trạng thái "Deleted", trong bảng kết quả so sánh, chúng ta sẽ xóa các tùy chọn "Only show difference fields between old point and new point", vì các thuộc tính sẽ trống trong điểm khôi phục mới.
–Đối với đối tượng có trạng thái "Unchanged", trong bảng kết quả so sánh, chúng ta sẽ xóa các tùy chọn "Only show difference fields between old point and new point", vì tất cả các thuộc tính sẽ giống nhau giữa điểm khôi phục cũ và điểm mới.
Thực nghiệm và kết quả kiểm thử
- Thiết kế test case cho Compare function .1 Thiết kế test case cho giao diện người dùng
• Kiểm tra tính phủ: Để đảm bảo rằng các test case kiểm tra đầy đủ các tính năng hay chức năng của sản phẩm thì khi viết test case em thực hiện viết những tính năng to trước, kiểu như là từ Suit đến subsuit, title, step. Với phương pháp sử dụng là kiểm thử thủ công (Manual testing) là làm mọi công việc hoàn toàn bằng tay, từ viết test case đến thực hiện test, mọi thao tác như nhập điều kiện đầu vào, thực hiện một số sự kiện khác như click nút và quan sát kết quả thực tế, sau đó so sánh kết quả thực tế với kết quả mong muốn trong test case, điền kết quả test. • Kỹ năng công nghệ: Em đã áp dụng một số công cụ cho quá trình kiểm thử cho Compare function này như là: Sử dụng công cụ quản lý hệ thống Jira, sử dụng phần mềm lưu trữ Microsoft Azure Azure Explorer để kiểm tra nhật ký hoạt động của ứng dụng khi sản phẩm hoạt động có vấn đề, và sử dụng một số ứng dụng như Azure Portal, Microsoft Admin 365 Center.
–Kỹ năng giao tiếp: Trong quá trình thực hiện kiểm thử, có những trường hợp ta phát hiện ra lỗi, sản phẩm đang không hoạt động đúng chức năng thì ta cần phải linh hoạt trao đổi với Developers hay còn gọi lập trỡnh viờn để cú thể xỏc minh nguyờn nhõn lỗi một cỏc rừ ràng để sau đó tạo ra Bug report một cách chính xác. Vì vậy, trong quá trình test, để có thể tiết kiệm thời gian em đã xem những case có trường hợp tương tự nhau, cách test gần giống nhau, kết hợp với nhau để thực hiện test, vì với ở Compare function ta sẽ phải thực hiện Backup job, Compare job hay là Restore Job, tất cả đều tốn thời gian chờ đợi. Thêm vào đó, kiểm thử chức năng và kiểm thử giao diện người dùng là hai loại khác nhau, tuy nhiên trong quá trình thực hiện chúng ta cần phải kết hợp với nhau để hệ thống hoạt động đúng, đồng nhất, thẩm mỹ và đáp ứng được yêu cầu người dùng.
