Sự cốlà triệu chứng liên kết với một thất bại và thể hiện cho người dùng hoặc ngườikiểm thử về sự xuất hiện của thất bại này.Test case ca kiểm thử: gồm một tập các dữ liệu đầu vào và một
Kiểm thử phần mềm và một số khái niệm liên quan
Kiểm thử phần mềm
Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử Nó cung cấp các nguyên lý, phương pháp, kỹ thuật, tiêu chuẩn và các quy trình để kiểm tra và đánh giá tính đúng đắn của phần mềm.
Các nguyên lý của kiểm thử phần mềm bao gồm:
• Kiểm thử phần mềm không thể đảm bảo tất cả các lỗi sẽ được phát hiện, mà chỉ có thể cố gắng giảm thiểu số lượng lỗi.
• Kiểm thử phần mềm phải được thực hiện bởi những người khác với những người phát triển phần mềm để đảm bảo tính khách quan và độc lập.
• Kiểm thử phần mềm phải được thực hiện theo các phương pháp, kỹ thuật, tiêu chuẩn và quy trình được định nghĩa trước để đảm bảo tính nhất quán và tối ưu hiệu quả.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm Theo truyền thống thì các nỗ lực kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành trong suốt quá trình xây dựng phần mềm Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định.
Một số khái niệm liên quan
Software quality(chất lượng phần mềm): là mức độ mà một hệ thống, thành phần hay quy trình đáp ứng các yêu cầu của đặc tả phần mềm, các nhu cầu mong đợi của khách hàng hoặc người sử dụng.
SQA (Software Quality Assurance): bộ phận giám sát, quản lý và đảm bảo chất lượng phần mềm Đây là bộ phận có quyền và có trách nhiệm quy định sẽ đặt khâu kiểm tra chất lượng sản phẩm theo phương pháp nào, tiêu chuẩn nào và dùng phương án gì để kiểm tra sản phẩm đạt chất lượng tốt nhất và đúng theo yêu cầu.
Validation(thẩm định): là xác định xem một hệ thống có phù hợp vowisi yêu cầy và thực hiện các chức năng mà nó dự định và đáp ứng các mục tiêu của tổ chức và người dùng hay không.
Verification(kiểm định): là để chắc chắn rằng sản phẩm được thiết kế để cung cấp tất cả các chức năng cho khách hàng Hoạt động này được thực hiện từ lúc bắt đầu phát triển phần mềm, bao gồm các đánh giá, các cuộc họp, rà soát và kiểm tra để đánh giá tài liệu, kế hoạch, việc lập trình, các yêu cầu và các thông số kỹ thuật.
Error(lỗi): là những vấn đề mà mắc phải trong quá trình phát triển các sản phẩm phần mềm
Fault(sai): là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai.
Failure(thất bại): xuất hiện khi một lỗi được thực thi.
Incident(sự cố): khi thất bại xuất hiện, nó có thể hiển thị hoặc không, tức là rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử Sự cố là triệu chứng liên kết với một thất bại và thể hiện cho người dùng hoặc người kiểm thử về sự xuất hiện của thất bại này.
Test case(ca kiểm thử): gồm một tập các dữ liệu đầu vào và một xâu các giá trị đầu ra mong đợi đối với phần mềm, mục đích là dựa vào đó để kiểm tra xem phần mềm có thỏa các yêu cầu đặt ra hay không.
Test script(Kịch bản kiểm thử): là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một quy trình hay một ca 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.
Quy trình kiểm thử
Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà có khả năng phát hiện lỗi cao Để 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 Đây chính là đầu vào cho giai đoạn kiểm thử Và sản phẩm công việc của giai đoạn kiểm thử chính là “báo cáo kiểm thử” mà tài liệu hóa tất cả các trường hợp kiểm thử đã chạy, dữ liệu đầu vào, đầu ra mong đợi, đầu ra thực tế và mục đích của kiểm thử.
Hình 1.1: Quy trình kiểm thử phần mềm
• Lập kế hoạch kiểm thử: Bước đầu tiên là lập kế hoạch cho tất cả các hoạt động sẽ được thực hiện và các phương pháp được sử dụng Các chuẩn IEEE bao gồm các thông tin về tác giả chuẩn bị kế hoạch, danh sách liệt kê của kế hoạch kiểm thử Vấn đề quan trọng nhất đối với kế hoạch kiểm thử:
–Mục đích: Quy định về phạm vi, phương pháp, tài nguyên và lịch biểu của các hoạt động kiểm thử.
–Các tài liệu tham khảo.
–Khái quát về kiểm định và thẩm định (V&V): tổ chức, tài nguyên, trách nhiệm, các công cụ, kỹ thuật và các phương pháp luận.
–Vòng đời của V&V: các nhiệm vụ, các dữ liệu vào và các kết quả trên một giai đoạn vòng đời.
–Báo cáo V&V phần mềm: mô tả nội dung, định dạng và thời gian cho tất cả các báo cáo V&V.
–Các thủ tục quản lý V&V bao gồm các chính sách, thủ tục, các chuẩn,thực nghiệm và các quy ước.
• 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ử. Thiết kế các trường hợp kiểm thử là các đặc tả đầu vào cho kiểm thử và đầu ra mong đợi của hệ thống:
–Các kỹ thuật kiểm thử hộp đen để kiểm thử dựa trên chức năng.
–Các kỹ thuật kiểm thử hộp trắng để kiểm thử dựa vào cấu trúc bên trong.
• Đánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng phát hành được chưa?
Các cấp độ kiểm thử
Kiểm thử mức đơn vị
Một đơn vị kiểm thử là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được Theo định nghĩa này, các hàm (Function), thủ tục (Procedure),lớp (Class), hoặc các phương thức (Method) đều có thể được xem là đơn vị kiểm thử Vì đơn vị kiểm thử được chọn để kiểm thử thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức,kiểm thử, ghi nhận và phân tích kết quả kiểm thử Nếu phát hiện lỗi,việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn vị đang kiểm thử Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho kiểm thử đơn vị sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó.
Kiểm thử đơn vị thường do lập trình viên thực hiện Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Thông thường, Kiểm thử đơn vị đòi hỏi kiểm thử viên có kiến thức về thiết kế và mã nguồn của chương trình Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và xuất ra là chính xác,trong mối tương quan với dữ liệu nhập và chức năng của đơn vị kiểm thử Điều này thường đòi hỏi tất cả các nhánh bên trong đơn vị kiểm thử đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh được thực thi trong một đơn vị kiểm thử Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết các đơn vị kiểm thử đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.
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 Các ca kiểm thử và kịch bản này nên được giữ lại để tái sử dụng Kiểm thử đơn vị thường sử dụng cácUnit Test Framework, đó là các khung chương trình được viết sẵn để hộ trợ cho việc test các mô đun, các đơn vị phần mềm.
Kiểm thử mức tích hợp
Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành Trong khi kiểm thử đơn vị kiểm thử các thành phần và đơn vị phần mềm riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm thử sự giao tiếp giữa chúng.
Kiểm thử tích hợp có 2 mục tiêu chính:
•Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị kiểm thử.
• Tích hợp các đơn vị kiểm thử đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm thử ở mức hệ thống.
Kiểm thử hồi quy
Kiểm thử hồi quy là kiểm thử được thực hiện sau khi thực hiện các thay đổi đối với sản phẩm phần mềm và kiểm tra lại các phần của sản phẩm có thể đã bị ảnh hưởng bởi lỗi.
Ví dụ:một ứng dụng phần mềm có thể cho phép giáo viên thêm, lưu, xóa và làm mới trong một công cụ học tập trực tuyến Sau đó, các Developer deploy 1 version mới với chức năng bổ sung để cập nhật Chức năng mới được kiểm tra để xác nhận rằng bản cập nhật hoạt động như mong đợi Trong trường hợp này,kiểm tra hồi quy có thể cải thiện chất lượng tổng thể của sản phẩm.
Kiểm thử chấp nhận sản phẩm
Thông thường, sau giai đoạn kiểm thử hệ thống là kiểm thử chấp nhận, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện) Mục đích của kiểm thử chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).
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.
Kiểm thử mức hệ thống
Mục đích kiểm thử mức hệ thống là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không. Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là:
•Kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống.
• Kiểm thử tích hợp chú trọng sự giao tiếp giữa các đơn vị hoặc đối tượng khi chúng làm việc cùng nhau.
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 Kiểm thử hệ thống kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật 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ớ.
Các kĩ thuật kiểm thử
Các nguyên tắc cơ bản của kiểm thử
Kiểm thử là một bước trong quy trình phần mềm mà có thể được xem xét bởi đội ngũ phát triển bằng cách phá vỡ thay vì xây dựng Các kỹ sư phần mềm chính là những người xây dựng và kiểm thử yêu cầu họ vượt qua các khái niệm cho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi được xác định.
Các nguyên tắc được xem như mục tiêu kiểm thử là:
–Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi.
–Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng cao việc tìm thấy các lỗi chưa từng được phát hiện.
–Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được phát hiện.
•Luồng thông tin kiểm thử
Luồng thông tin cho kiểm thử được biểu diễn bởi mô hình trong hình dưới đây Hai kiểu của đầu vào được truyền cho quá trình kiểm thử:
–Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã nguồn.
–Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường hợp kiểm thử, và các công cụ kiểm thử.
Hình 1.2: Luồng thông tin kiểm thử
•Thiết kế trường hợp kiểm thử
–Thiết kế kiểm thử phần mềm có thể là một quá trình thu thập, phân tích và thực hiện yêu cầu Mục tiêu của kiểm thử là phải thiết kế các trường hợp kiểm thử có khả năng cao nhất trong việc phát hiện nhiều lỗi nhất với thời gian và công sức tối thiểu Như vậy, vấn đề quan trọng nhất trong kiểm thử phần mềm là thiết kế và tạo ra các trường hợp kiểm thử có hiệu quả Lý do về tầm quan trọng của việc thiết kế các trường hợp kiểm thử xuất phát từ thực tế: Kiểm thử “vét cạn” là điều không thể, và như vậy, kiểm thử một chương trình phải luôn xác định là không thể vét cạn Vấn đề quan trọng là cố gắng làm giảm sự
“không thể vét cạn” nhiều nhất có thể.
–Kiểm thử phần mềm còn có các ràng buộc về thời gian, chi phí, v.v.
–Bất kỳ sản phẩm công nghệ nào có thể được kiểm thử trong hai cách:
∗Biết về các chức năng cụ thể mà sản phẩm đã được thiết kế để thực hiện.
∗Biết cách hoạt động bên trong của sản phẩm, kiểm thử có thể được thực hiện để đảm bảo rằng “tất cả các thành phần ăn khớp nhau”.
Cách tiếp cận kiểm thử đầu tiên được gọi là kiểm thử hộp đen và cách thứ hai là kiểm thử hộp trắng.
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 chương trình, dựa vào mã nguồn, cấu trúc chương trình Kiểm thử hộp trắng thường phát hiện các lỗi lập trình Loại kiểm thử này khá khó thực hiện và chi phí cao Với các module quan trọng, thực thi việc tính toán chính của hệ thống, phương pháp này là cần thiết Có 2 kỹ thuật kiểm thử hộp trắng phổ biến:
•Kiểm thử luồng dữ liệu
Phương pháp kiểm thử luồng dữ liệu lựa chọn các đường dẫn kiểm thử của chương trình dựa vào vị trí khai báo và sử dụng các biến trong chương trình Với kiểm thử luồng dữ liệu mỗi câu lệnh trong chương trình được gán số hiệu lệnh duy nhất và mỗi hàm không thay đổi tham số của nó và biến toàn cục Cho một lệnh với là số hiệu câu lệnh Ta định nghĩa,S
DEF (S) =là tập các biến được khai báo trongS.
U SE(S) =là tập các biến được sử dụng trongS.
Một chiến lược kiểm thử luồng dữ liệu cơ bản là chiến lược mà mỗi chuỗi
DU được phủ ít nhất một lần Chiến lược này được gọi là chiến lược kiểm thử DU Kiểm thử DU không đảm bảo phủ hết tất cả các nhánh của một chương trình 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) Trong tình huống đó, nhánh else của lệnh if là không cần thiết phải phủ bằng kiểm thử DU.
Chiến lược kiểm thử luồng dữ liệu là rất hữu ích cho việc lựa chọn các đường dẫn kiểm thử của chương trình có chứa các lệnh if hoặc vòng lặp lồng nhau.
•Kiểm thử luồng điều khiển Đườ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.
Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọi đường thi hành của đơn vị phần mềm cần kiểm thử đều chạy đúng Rất tiếc trong thực tế, công sức và thời gian để đạt mục tiêu trên đây là rất lớn, ngay cả trên những đơn vị phần mềm nhỏ Mà cho dù có kiểm thử hết được toàn bộ các đường thi hành thì vẫn không thể phát hiện những đường thi hành cần có nhưng không (chưa) được hiện thực Do đó, ta nên kiểm thử số ca kiểm thử tối thiểu mà kết quả độ tin cậy tối đa.
Phủ kiểm thử (Test Coverage): là một kỹ thuật xác định xem các trường hợp thử nghiệm có thực sự bao trùm mã ứng dụng hay không và bao nhiêu mã được thực hiện khi chạy các trường hợp thử nghiệm đó Nếu có 10 yêu cầu và 100 thử nghiệm được tạo và nếu 90 thử nghiệm được thực hiện thì phạm vi thử nghiệm là 90% 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. Dưới đây là một số lợi thế của test coverage.
–Có thể xác định các lỗ hổng trong yêu cầu, trường hợp kiểm tra và lỗi ở cấp độ sớm và cấp mã.
–Có thể ngăn ngừa rò rỉ lỗi không mong muốn bằng cách sử dụng phân tích test coverage.
–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ử.
–Kiểm tra được toàn bộ chương trình nguồn.
–Phát hiện lỗi tại chỗ.
–Tự động hóa kiểm thử.
–Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình.
Do đó đòi hỏi tài nguyên nhân lực và máy tốn kém.
–Có khả năng tồn tại có tổ hợp lệnh khác nhau gây lỗi.
–Không kiểm thử hết đường đi, vòng lặp lớn, phức tạp.
–Khó thực hiện và chi phí thực hiện cao.
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 mà không biết được cấu tạo bên trong của phần mềm, là cách mà các tester kiểm tra xem hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong của cái hộp.
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 Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:
•Chức năng không chính xác hoặc thiếu.
•Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài.
•Hành vi hoặc hiệu suất lỗi.
•Khởi tạo và chấm dứt các lỗi.
Hình 1.3: Minh họa kiểm thử hộp đen
–Kỹ sư kiểm thử có thể không phải IT chuyên nghiệp.
–Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác.
–Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năng được xác định.
–Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn.
–Khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào, và thiếu cả thời gian cho việc tập hợp này.
–Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao.
Mọi kỹ thuật nào cũng có ưu điểm và nhược điểm của nó 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
Cấu trúc của test case
Dưới đây là cấu trúc của test case:
– Case ID: giá trị cần để xác định số lượng trường hợp cần để kiểm thử. – Suite: Tên một chức năng, đối tượng hoặc tập hợp các trường hợp kiểm thử có liên quan tới nhau.
– Subsuite: tương tự như Suite, nhưng được chia nhỏ hơn.
– Title: tiêu đề, tên của case, đảm bảo rõ ràng và mô tả đầy đủ nội dung của case.
– Summary: mô tả sơ lược về mục đích của case đó.
– Priority: mức độ ưu tiên của case, gồm có 3 mức độ là High, Normal, và Low
– Step: mô tả các bước để thực hiện case đó.
– Expected results: kết quả mong đợi từ các bước thực hiện trên. – Results: kết quả thực tế khi chạy chương trình.
– Note: cột này dùng để ghi chú những thông tin liên quan khi thực hiện test case.
Các bước xác định test case:
–Bước 1: Xác định mục đích kiểm thử, cần hiểu rõ đặc tả yêu cầu của khách hàng.
–Bước 2: Xác định chức năng cần kiểm tra: cần phải biết làm thế nào phần mềm được sử dụng bao gồm các hoạt động, tổ chức chức năng khác nhau.
Các bước thực hiện chỉ mô tả các bước thực hiện đứng từ phía người dùng cuối bao gồm nhập dữ liệu, nhấn button, v.v.
–Bước 3: Xác định các yêu cầu phi chức năng, yêu cầu phần cứng, hệ điều hành, các khía cạnh an ninh.
–Bước 4: Xác định biểu mẫu cho test case: bao gồm giao diện UI, chức năng, khả năng tương thích và hiệu suất.
–Bước 5: Xác định tính ảnh hưởng giữa các nguyên tắc module, mỗi một ca kiểm thử nên được thiết kế để có thể che phủ được sự ảnh hưởng của các module với nhau ở mức độ cao nhất.
Ta sẽ minh họa một vài ca kiểm thử:
Hình 1.4: Minh họa một một số test case
Phân vùng tương đương
Phân vùng tương đương là phương pháp chia các điều kiện đầu vào thành những vùng tương đương nhau Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống nhau Vì vậy chúng ta có thể test một giá trị đại diện trong vùng tương đương.
Mục đích: Giảm đáng kể số lượng ca kiểm thử cần phải thiết kế vì với mỗi lớp tương đương ta chỉ cần test trên các phần tử đại diện Thiết kế ca kiểm thử bằng kỹ thuật phân vùng tương đương tiến hành theo 2 bước:
Bước 1: Xác định các lớp tương đương.
Ta chia miền dữ liệu kiểm thử thành các miền con sao cho dữ liệu trong mỗi miền con có cùng tính chất đối với chương trình Sau khi chia miền dữ liệu của chương trình thành các miền con tương đương, ta chỉ cần chọn một phần tử đại diện của mỗi miền con này làm bộ dữ liệu kiểm thử Các miền con này chính là các lớp tương đương.
Bước 2: Xây dựng test case tương ứng với mỗi lớp tương đương.
Ví dụ về một Form đăng nhập:
Hình 1.5: Minh họa một form đăng nhập
–Thiết kế ca kiểm thử sao cho người dùng nhập vào ô text-box username chỉ cho nhập ký tự chữ với độ dài trong khoảng 6-20.
–Nếu nhập giá trị với số ký tự không nằm trong khoảng 6-20.
⇒Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.
–Nếu để trống ô hoặc nhập ký tự khác ký tự chữ.
⇒Hiển thị lỗi “Tên người dùng chưa hợp lệ! Vui lòng nhập ký tự chữ”.
Dựa vào yêu cầu bài toán ta có thể có các lớp tương đương (phân vùng) sau:
–Phân vùng 1: Nhập giá trị hợp lệ từ 6-20.
–Phân vùng 2: Nhập giá trị không hợp lệ < 6 ký tự.
–Phân vùng 3: Nhập giá trị không hợp lệ > 20 ký tự.
–Phân vùng 4: Trường hợp để trống không nhập gì hay nhập ký tự không phải dạng chữ.
Sau khi áp dụng phân vùng tương đương có thể chọn được các case sau:
–Case 1: Nhập giá trị từ 6–20⇒Pass.
–Case 2: Nhập giá trị < 6 ký tự (có thể chọn nhập 1, 2, 3, 4 hoặc 5 ký tự)⇒Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.
–Case 3: Nhập giá trị > 20 ký tự (có thể chọn nhập 21, 22, 23, ký tự)⇒Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.
–Case 4: Để trống không nhập gì hay nhập ký tự không phải dạng chữ.
⇒Hiển thị lỗi “Tên người dùng chưa hợp lệ! Vui lòng nhập ký tự chữ”.
Vì mỗi vùng tương đương ta chỉ cần kiểm tra trên các phần tử đại diện nên số lượng test case được giảm đi khá nhiều nhờ đó mà thời gian thực hiện kiểm thử cũng giảm đáng kể.
Không phải với bất kỳ bài toán nào đều có thể áp dụng kỹ thuật này Có thể bị thiếu sót lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tương đương.
Phân tích giá trị biên
Hầu hết các lỗi được tìm thấy khi kiểm tra ở các giá trị biên Vì vậy phương pháp này tập trung vào việc kiểm thử các giá trị biên này Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra.
Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ liệu.Thay vì chọn nhiều giá trị trong lớp đương tương để làm đại diện, phân tích giá trị biên yêu cầu chọn một hoặc vài giá trị là các cạnh của lớp tương đương để làm điều kiện test.
Phân tích giá trị biên là trường hợp đặc biệt của phân vùng tương đương, dựa trên những phân vùng tương đương kiểm thử viên sẽ xác định giá trị biên giữa những phân vùng này và lựa chọn ca kiểm thử phù hợp. Mục tiêu là lựa chọn các ca kiểm thử để thực thi giá trị biên:
∗Giá trị biên nhỏ nhất – 1
∗Giá trị biên nhỏ nhất
∗Giá trị biên lớn nhất
∗Giá trị biên lớn nhất + 1
Nhưng nếu bạn muốn kiểm tra sâu hơn thì bạn cũng có thể lựa chọn theo quy tắc:
∗Giá trị biên nhỏ nhất - 1
∗Giá trị biên nhỏ nhất
∗Giá trị biên nhỏ nhất + 1
∗Giá trị biên lớn nhất - 1
∗Giá trị biên lớn nhất
∗Giá trị biên lớn nhất + 1
•Ví dụ:Vẫn lấy form đăng nhập hình 1-5.
Theo phương pháp phân vùng tương đương ở trên ta xây dựng được các miền tương đương:
–Phân vùng 1: Nhập giá trị hợp lệ từ 6-20.
–Phân vùng 2: Nhập giá trị không hợp lệ < 6 ký tự.
–Phân vùng 3: Nhập giá trị không hợp lệ > 20 ký tự.
–Phân vùng 4: Trường hợp để trống không nhập gì hay nhập ký tự không phải dạng chữ. Áp dụng kỹ thuật phân tích giá trị biên ta chọn được các case sau:
∗Case 1: Nhập giá trị với 5 ký tự.
⇒Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.
∗Case 2: Nhập giá trị với 6 ký tự⇒pass.
∗Case 3: Nhập giá trị với 20 ký tự⇒pass.
∗Case 4: Nhập giá trị với 21 ký tự.
⇒Hiển thị lỗi "Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự".
∗Case 5: Để trống không nhập gì hay nhập ký tự không phải dạng chữ.
⇒ Hiển thị lỗi "Tên người dùng chưa hợp lệ! Vui lòng nhập ký tự chữ".
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ử.
Phương pháp phân tích giá trị biên chỉ hiệu quả trong trường hợp các đối số đầu vào độc lập với nhau và mỗi đối số đều có một miền giá trị hữu hạn.
Đoán lỗi
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.
Các lỗi điển hình như chia cho không, null pointer, hoặc các biến không hợp lệ, v.v.
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ử Phương pháp này chỉ phù hợp với những kiểm thử viên có kinh nghiệm Khi một kiểm thử viên được đưa cho một chương trình, họ phỏng đoán dựa vào trực giác, dựa vào kinh nghiệm, dữ liệu lịch sử về các lỗi đã từng xảy ra với chương trình trước đó, v.v và sau đó viết các ca kiểm thử để đưa ra các lỗi đó.
Sử dụng phương pháp đoán lỗi có thể giúp kiểm thử viên tìm ra những lỗi điển hình thường xảy ra trong phần mềm hoặc những lỗi không thể tìm thấy khi thiết kế ca kiểm thử theo hình thức thông thường.
Phương pháp đoán lỗi thường được thực hiện bởi các kiểm thử viên có kinh nghiệm và không theo một quy tắc nhất định, thiết kế ca kiểm thử dựa nhiều vào cảm tính.
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 đó Các phần mềm quản lý task như Redmine, Jira, 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
Một Bug report sẽ bao gồm những thông tin cơ bản sau:
– Project: tên của dự án phần mềm.
– Reported by: kiểm thử viên tạo Bug report.
– Bug name, Bug IDvàDate: tên của bug, ID, và thời gian tạo report.
– Assigned to: cá nhân hoặc tổ chức chịu trách nhiệm phần đó. – Status: trạng thái thực hiện của report.
– Summary/Description:mô tả ngắn gọn về bug.
– Step to reproduce: mô tả lại các bước thực hiện gây ra bug. – Actual results: kết quả thực tế.
– Expected result:kết quả mong đợi.
– Severity: mức độ nghiêm trọng của bug.
– Priority:mức độ ưu tiên của bug.
– Affects Version/s: phiên bản mà tìm thấy bug ở trong đó. – Fix Version/s: phiên bản sẽ thực hiện fix bug.
– Attachment:đính kèm với bug (ảnh, video, đường dẫn URL, v.v.)
Ví dụ minh họa về một Bug report:
Hình 1.6: Minh họa một Bug report
Một số yêu cầu khi tạo 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 Nó cũng là phần được đọc nhiều nhất, không phải là Description 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.
Kiểm thử chức năng Compare function trong dịch vụ đám mây Azure Cloud Backup 27
Giới thiệu
AvePoint Cloud Backup for Azure là một ứng dụng sao lưu đám mây dành cho Microsoft Azure, cho phép tổ chức sao lưu và phục hồi các tài nguyên trong Azure như máy chủ ảo, máy chủ SQL và lưu trữ đối tượng Với AvePoint Cloud Backup for Azure, bạn có thể dễ dàng cấu hình chính sách sao lưu, theo dõi quá trình sao lưu và phục hồi, và khôi phục dữ liệu chỉ trong vài cú nhấp chuột Azure Portal là một ứng dụng web quản lý tài nguyên Azure, cho phép bạn quản lý các tài nguyên đám mây của mình, bao gồm cả các dịch vụ như Azure Cloud Backup Vì vậy, để sử dụng Azure Cloud Backup, bạn có thể truy cập vào Azure Portal thông qua trình duyệt web để thực hiện các tác vụ liên quan đến sao lưu và phục hồi dữ liệu.
AvePoint Cloud Backup for Azure cung cấp các tính năng sau:
1 Sao lưu định kỳ và liên tục: AvePoint Cloud Backup for Azure cho phép bạn tạo chính sách sao lưu định kỳ hoặc liên tục để bảo vệ dữ liệu của bạn.
2 Phục hồi nhanh chóng và linh hoạt: Bạn có thể khôi phục các tài nguyên
Azure chỉ trong vài cú nhấp chuột, bao gồm phục hồi các phiên bản cũ của máy chủ ảo, máy chủ SQL và lưu trữ đối tượng.
3 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.
4 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ể.
5 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ác module chính trong Azure Cloud Backup cho tới thời điểm hiện tại bao gồm:
• Azure Active Directory: Là module sao lưu và phục hồi dữ liệu người dùng và ứng dụng trong các dịch vụ đám mây của Microsoft Azure Riêng module này có hai tính năng khôi phục dữ liệu là Recovery point và Compare.
• Azure Virtual Machine:Là module cũng cấp khả năng sao lưu và khôi phục dữ liệu cho các máy ảo (VM) và đĩa (disk).
• Azure Storage: Là module lưu trữ dữ liệu đám mây của Microsoft, bao gồm các dịch vụ lưu trữ như Azure Blob Storage, Azure Files.
• Admin Portal Settings: Là module mà một phần của giao diện quản trị trực tuyến của dịch vụ sao lưu đám mây Azure Backup Nó cho phép quản trị viên cấu hình và quản lý các thiết lập toàn cục cho toàn bộ tổ chức.
Vai trò
Trong Azure Cloud Backup, chức năng so sánh (Compare function) được sử dụng để sắp xếp và quản lý các bản sao lưu dữ liệu của tổ chức trên đám mây Azure Cụ thể, các hàm so sánh các điểm khôi phục hoặc so sánh dữ liệu sao lưu với dữ liệu sản xuất để tìm dữ liệu để khôi phục Từ đó có thể đưa ra lựa chọn dễ dàng cho việc khôi phục dữ liệu.
Chức năng Compare cũng được sử dụng để quản lý các bản sao lưu dữ liệu trên đám mây Azure Khi bạn phục hồi dữ liệu từ bản sao lưu, các chức năng so sánh được sử dụng để xác định phiên bản của dữ liệu cần phục hồi và giúp cho quá trình phục hồi được thực hiện chính xác và hiệu quả hơn.
Vì vậy, chức năng Compare trong Azure Cloud Backup đóng vai trò quan trọng trong quá trình sao lưu và phục hồi dữ liệu, giúp quản lý và xác định thứ tự ưu tiên dữ liệu, đảm bảo tính toàn vẹn của dữ liệu và tối ưu hóa quá trình phục hồi.
Thực nghiệm và kết quả kiểm thử 38
Thiết kế test case cho Compare function
3.1.1 Thiết kế test case cho giao diện người dùng
Dựa vào tài liệu đặc tả, và bản thiết kế giao diện sản phẩm, ta tiến hàng xây dựng các trường hợp kiểm thử Đây là một phần quan trọng trong quá trình phát triển phần mềm để đảm bảo rằng ứng dụng của bạn hoạt động như mong đợi và cung cấp trải nghiệm người dùng tốt nhất. Để có thể thiết kế một bản test case cho UI ( giao diện người dùng) thì em đã thực hiện theo các bước sau:
• Hiểu rõ yêu cầu chức năng: Từ những tài liệu đặc tả được cung cấp, em đã tìm hiểu nó một cách chi tiết để từ đó xây dựng bản test case phù hợp. Bên cạnh tính năng "Compare", thì sản phẩm đã đưa vào sử dụng tính năng "Recovery point" Vì tính năng Compare được phát triển cũng có một vài chức năng nhỏ tương tự nên khi đã hiểu rõ tính năng "Recovery Point" trước đó thì em có thể hiểu rõ các tính năng này, cách mà nó hoạt động một cách nhanh chóng.
• Xác định các trường hợp sử dụng chính: Với "Compare function" thì bao gồm các trường hợp sử dụng chính như là:
–Các trường hợp Compare, có 2 kiểu Compare là Production Environ- ment và Recovery Points Cả 2 kiểu Compare đều áp dụng cho User và Groups Riêng Groups thì trong đó có 4 loại group.
–Các trường hợp Restore: Đối tượng restore sẽ là User và Groups Và theo 3 phương thức Restore là Merge, Overwrite và Skip.
• Sử dụng ngôn ngữ và cấu trúc dễ hiểu: Vì đây là một dự án sử dụng ngôn ngữ chính là tiếng Anh và hỗ trợ công cụ dịch là tiếng Nhật nên loại ngôn ngữ em sử dụng trong các hoạt động tham gia dự án là đều bằng Tiếng Anh Về cấu trúc thì em sử dụng cấu trúc câu đơn giản dễ hiểu và trực quan, để khi người khác đọc cũng cảm thấy dễ hiểu và kiểm tra.
• Sử dụng bộ dữ liệu thích hợp: Em đã sử dụng những bộ dữ liệu thích hợp thể để kiểm tra một số tính năng Khi xây dựng test case em sẽ phân làm hai loại chính là Valid (hợp lệ) và Invalid (không hợp lệ).
• Thiết kế test case độc lập: Với bộ test case em xây dựng thì các test case độc lập nhau, tức là với mỗi test case ta có thể kiểm tra một tính năng cụ thể và nó sẽ không bị phụ thuộc và bất kỳ test case nào khác.
• 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 Sau đó sẽ đi viết Step của từng case Như vậy sẽ nhanh chóng hơn và có thể phủ được kha khá case.
• Đảm bảo tính lặp lại: Khi viết test case em đã luôn phải nhớ rằng là cần đảm bảo các test case có thể được lặp lại nhiều lần để đảm bảo tính ổn định của sản phẩm.
• Kiểm tra kết quả: Sau khi viết test case xong, em đã cần phải kiểm tra kết quả của các test case để đảm bảo rằng sản phẩm đáp ứng được các yêu cầu chức năng và chất lượng được đưa ra.
Kết quả thiết kế test case cho giao diện người dùng là 352 case Dưới đây là một trong số test case được xây dựng để kiểm thử giao diện người dùng.
Hình 3.1: Một số test case viết cho UI
3.1.2 Thiết kế test case cho chức năng Compare Để có thể thực hiện chức năng Compare, người dùng bắt buộc thực hiện sao lưu dữ liệu thành công trong Azure Active Directory. Để đưa ra đầy đủ các test case bao phủ cho các trường hợp của chức năng Compare, không bỏ sót bất cứ trường hợp nào thì em đã tiến hành phân tích các trường hợp kiểm thử như sau :
•Compare dữ liệu với kiểu so sánh Production Environment cho Users. Dựa vào 4 trạng thái được áp dụng, ta đưa ra 4 trạng thái cho trường hợp này để tạo test case:
–Added: Users mới được thêm vào so với dữ liệu điểm khôi phục.
–Modified: Dữ liệu của User được chỉnh sửa so với dữ liệu điểm khôi phục Chi tiết sẽ là 4 trường hợp chỉnh sửa, thêm dữ liệu, sửa dữ liệu, xóa dữ liệu, và không thay đổi dữ liệu.
–Deleted: User đã bị xóa so với dữ liệu điểm khôi phục.
–Unchanged: Dữ liệu của Users không có gì thay đổi Với trường hợp này em đã xây dựng
Số test case được thiết kế cho trường hợp này là case.7
•Compare dữ liệu với kiểu so sánh Production Environment cho Groups. Với đối tượng so sánh là Groups, ta hỗ trợ cho 4 loại groups là Microsoft
365, Security, Distribution, Mail-enable security Với mỗi loại Group, ta đều thực hiện test với 4 trạng thái cho từng group.
–Added: group mới được thêm vào so với dữ liệu điểm khôi phục.
–Modified: dữ liệu của group được chỉnh sửa so với điểm khôi phục.
–Deleted: group đã bị xóa tại thời điểm hiện tại.
–Unchanged: dữ liệu của group không có gì thay đổi so với điểm khôi phục.
Số test case được thiết kế cho trường hợp này là28case.
•Compare dữ liệu với kiểu so sánh Recovery Points cho Users.
Với kiểu so sánh này, ta phải chạy thành công ít nhất 2 lần sao lưu dữ liệu của Azure Active Directory Ta thực hiện so sánh dữ liệu với các trường hợp kết quả so sánh tương tự cho 4 trạng thái:
–Added: User mới được thêm vào tại New recovery point.
–Modified: Dữ liệu tại New recovery point được chỉnh sửa so với Old recovery point.
–Deleted: Tại New recovery point, User đã bị xóa.
–Unchanged: Dữ liệu không có gì thay đổi Số test case được thiết kế cho trường hợp này là 7 case.
•Compare dữ liệu với kiểu so sánh Recovery Points cho Groups.
Với trường hợp này, ta thực hiện so sánh dữ liệu tại hai điểm khôi phục cho
Group Tương tự, ta sẽ xây dựng các trường hợp test cho từng loại Group, với từng trạng thái.
–Added: Group mới được thêm vào tại New recovery point.
–Modified: Dữ liệu của Group tại New recovery point được chỉnh sửa so với Old recovery point.
–Deleted: Tại New recovery point, Group đã bị xóa.
–Unchanged: Dữ liệu không có gì thay đổi.
Số test case được thiết kế cho trường hợp này là 28 case.
Với hướng phân tích như trên, em đã thiết kế được 70 case cho chức năng Compare.
3.1.3 Thiết kế test case cho chức năng Restore
Từ các trường hợp kiểm thử được xây dựng trong chức năng Compare, ta xây dựng các trường hợp Restore dữ liệu dựa trên hướng phân tích sau:
Ta xây dựng các trường hợp Restore User theo thứ tự:
Trạng thái dữ liệu so sánh của User (4 trạng thái),
> Điểm khôi phục (dựa theo Production Environment/ Recovery Point),
> Phương thức khôi phục dữ liệu (Merge/ Overwrite/ Skip).
Một số test case được xây dựng từ hướng phân tích này được thể hiện trong hình 3-2 đưới đây:
Hình 3.2: Một số test case viết cho chức năng Restore Users
Ta tiến hành xây dựng các trường hợp kiểm thử cho chức năng này theo thứ tự như sau:
Từng trạng thái dữ liệu so sánh của Group,
> Điểm khôi phục (dựa theo Production Environment/ Recovery Point),
> Từng loại group (4 loại group),
> Phương thức khôi phục (Merge/ Overwrite/ Skip).
Một số test case được thiết kế cho Restore Group từ hướng phân tích này được thể hiện trong hình 3-3 dưới đây:
Với chức năng Restore trong Compare function, em đã thiết kế được tất cả198 case.
Hình 3.3: Một số test case viết cho chức năng Restore Groups
Thực nghiệm kiểm thử
Vận dụng cơ sở lý thuyết về kiểm thử, đọc và tìm hiểu chi tiết về các chức năng Compare để thực hiển kiểm thử các chức năng chính trong Compare function của dịch vụ Azure Cloud Backup 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.
Trong quá trình kiểm thử này, em đã áp dụng được chủ yếu hai kỹ năng:
• 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 phân tích: Em đã sử dụng kỹ năng này để có thể chia nhỏ các chức năng thành các đơn vị nhỏ hơn để có thể hiểu rõ hơn.
–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 Hay là khi cần chuyển tiếp thông tin, cung cấp các báo cáo kiểm thử mà em đã thực hiện.
• Một điều cần nhớ khi thực hiện kiểm thử là Bug cần phải được "Reproducee" hay còn gọi là tái hiện bug Điều đó giúp cho đội phát triển có thể tìm ra nguyên nhân và sửa chữa lỗi một cách chính xác và hiệu quả Nếu một lỗi không thể tái hiện được, việc sữa chữa lỗi sẽ trở nên khó khăn hơn vì đội phát triển không thể xác định được lỗi gì và không thể thực hiện các bước để khắc phục Nếu một bug tái hiện được sẽ cung cấp thông tin cần thiết cho đội phát triển để tìm ra nguyên nhân của lỗi và cải thiện sản phẩm. Điều này giúp tiết kiệm thời gian và công sức trong việc tìm lỗi, nâng cao hiệu quả quá trình phát triển sản phẩm và đảm bảo sản phẩm đạt chất lượng tốt.
• Vì số lượng case là không nhỏ nên nếu test từng test case một sẽ rất tốn kém thời gian, đặc biệt là test chức năng, xét từng trường hợp 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 Nên việc kết hợp như vậy sẽ tiết kiệm thời gian, và cải thiện hiệu suất kiểm thử.
•Kết quả kiểm thử giao diện
Số test case chưa thực hiện 0
Nhận xét:Nhìn chung giao diện hệ thống được xây dựng dựa trên bản thiết kế Các tính năng và chức năng hiển thị đúng đắn Tuy nhiên có một số lỗi như là:
–Khi Compare Group, nút Filter hiển thị sai khi cài đặt ngôn ngữ là Japanese.
–Tiêu đề của Recovery Point thì không hiển thị.
Hình 3.4: Một Bug report về UI
•Kết quả kiểm thử chức năng Compare
Số test case chưa thực hiện 0
–Tính khả dụng: Giao diện đơn giản, dễ sử dụng, chức năng của phím tab, enter hoạt động tốt Không có lỗi chính tả, không khó để đọc chữ, bố cục gọn gàng hợp lý.
–Về chức năng: Trong quá trình thực thi kiểm thử chức năng Compare, đã xảy ra lỗi ở một số trường hợp:
∗Trường hợp xóa Mail-enable group thì không xuất hiện ở bảng Compare results.
∗Dấu câu dùng để phân tách các dữ liệu trong một trường thì không giống nhau.
Hình 3.5: Một bug report về chức năng Compare
•Kết quả kiểm thử chức năng Restore
Số test case chưa thực hiện 0
–Tính khả dụng: Giao diện đơn giản, dễ sử dụng, chức năng của phím tab, enter hoạt động tốt Không có lỗi chính tả, không khó để đọc chữ, bố cục gọn gàng hợp lý.
–Về chức năng: Trong quá trình thực thi kiểm thử chức năng Restore, đã xảy ra lỗi ở một số trường hợp: Các trường hợp Restore users đã bị xóa đều failed. Đối với những bug sau khi được log, cần phải theo dõi trạng thái bug Sẵn sàng verify bug (xác minh lỗi) khi bug ở trạng thái "Ready for QA" Tiến hành test lại bug đó để đảm bảo bug đã được sửa chữa thành công.
Đánh giá kết quả kiểm thử
Đánh giá toàn bộ quá trình kiểm thử trong số 610 case của Compare function trong ứng dụng Azure Cloud Backup:
Số case Failed Tỉ lệ thành công Giao diện
Restore 198 192 6 97.47 % Đóng góp cho dự án:
Là một QA, có vai trò quan trọng trong dự án bằng cách đảm bảo chất lượng sản phẩm, cụ thể em đã có những đóng góp cho dự án như là:
• Phát hiện và báo cáo lỗi: kiểm tra sản phẩm để phát hiện các lỗi và báo cáo các lỗi đó cho đội lập trình viên Điều này giúp đảm bảo rằng các lỗi được sửa chữa trước khi sản phẩm được đưa tới khách hàng, giảm thiểu rủi ro cho người dùng và đảm bảo rằng sản phẩm đáp ứng được yêu cầu chất lượng.
• Xác định và phân tích yêu cầu của khách hàng: hiểu và phân tích yêu cầu của khách hàng để đảm bảo rằng sản phẩm đáp ứng yêu cầu đó.
• Xây dựng kế hoạch kiểm thử: xây dựng một bản kế hoạch kiểm thử chi tiết, bao gồm các trường hợp kiểm thử, phương pháp kiểm thử để đảm bảo rằng sản phẩm đáp ứng yêu cầu chất lượng cần thiết.
• Cải thiện quy trình kiểm thử: góp ý để cải thiện quy trình kiểm thử và đảm bảo quy trình kiểm thử được thực hiện đúng cách.
• Tương tác với các thành viên khác trong nhóm: tương tác, trao đổi trong quá trình làm việc để đảm bảo rằng sản phẩm đạt chất lượng tốt nhất.
Nhận xét kết quả kiểm thử
• Kỹ thuật được áp dụng trong quá trình thực nghiệm kiểm thử là kiểm thử hộp đen (Black Box Testing).
• Trong quá trình kiểm thử Compare function, với mỗi chức năng con trong đó đều xảy ra một vài lỗi Với các tính năng như: tính khả dụng, khả năng tương thích thì sản phẩm đều đã đáp ứng tốt.
• Cần phải linh hoạt khi kiểm thử giao diện người dùng (UI) và kiểm thử chức năng, kết hợp chúng để đảm bảo sản phẩm đang hoạt động đúng chức năng của nó.
Nhận xét sau quá trình thực hiện:
Sau khi thực hiện kiểm thử chức năng Compare, Mentor (cố vấn) trong dự án đã đưa ra cho em một số nhận xét như sau:
•Kĩ năng viết test case được cải thiện khá nhiều.
• Test case có khả năng bao phủ các chức năng, mặc dù vẫn còn thiếu một vài case nhỏ, tuy nhiên vẫn ở mức tốt.
Kết luận chương
Em đã vận dụng các cơ sở lý thuyết về kiểm thử và dựa trên các kịch bản kiểm thử do em thiết kế để có thể đánh giá kết quả của từng ca kiểm thử Tuy nhiên, đây là kiểu kiểm thử thủ công có nhược điểm là tốn nhiều thời gian Đặc biệt trong quá trình thực hiện, cần hiểu thật sự rõ luồng dữ liệu đầu vào đầu ra để đảm bảo hệ thống đang hoạt động đúng chức năng của mình 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 Và từ những nhận xét, góp ý của mọi người trong dự án, em đã có những bổ sung,chỉnh sửa để đạt được hiệu suất kiểm thử tốt nhất.
Kiểm thử phần mềm là một quá trình quan trọng để đảm bảo tính chính xác, đáng tin cậy và hiệu quả của phần mềm Kiểm thử phần mềm có nhiều phương pháp và kỹ thuật khác nhau, tùy thuộc vào yêu cầu của dự án và tính chất của phần mềm Một kế hoạch kiểm thử phù hợp và chi tiết là rất quan trọng để đảm bảo rằng kiểm thử được thực hiện một cách hợp lý và đầy đủ Hiện nay, phần lớn các tổ chức, các công ty phần mềm, hoặc các nhóm làm phần mềm đều thực hiện kiểm thử thủ công là chủ yếu Việc tự động hóa kiểm thử là một xu hướng quan trọng hiện nay để cải thiện hiệu quả và độ chính xác của kiểm thử phần mềm Phần mềm kiểm thử tự động có nhiều lợi ích như giảm thời gian và chi phí, tăng tính đồng nhất, đảm bảo tính lặp lại và độ chính xác Để đạt được hiệu quả tốt nhất trong kiểm thử phần mềm, cần có sự hợp tác giữa các thành viên trong nhóm phát triển, kiểm thử và quản lý dự án Sau thời gian thực hiện đồ án dưới sự hướng dẫn của TS Đoàn Duy Trung, kết quả mà em thu được cụ thể như sau:
•Trình bày được các kiến thức cơ bản về kiểm thử phần mềm.
• Hiểu rõ logic hoạt động của chức năng Compare trong ứng dụng, áp dụng lý thuyết vào thực hành kiểm thử.
• Phát triển kỹ năng kiểm thử phần mềm bao gồm viết test case, xác định lỗi và báo cáo chúng.
•Tăng cường kỹ năng giải quyết vấn đề.
•Tăng cường khả năng làm việc nhóm khi tham gia làm việc trong dự án.
Do trình độ, khả năng và thời gian còn hạn chế nên báo cáo còn một số sai sót:
• Không thể ghi lại quá trình test thủ công, vì vậy không thể sử dụng lại quá trình test thủ công.
• Do chưa có nhiều kinh nghiệm nên quá trình thực hiện chưa thực sự tối ưu.
• Do sự hạn chế về quyền truy cập dữ liệu trong quá trình thực hiện test, nên thời gian để thực hiện sẽ lâu hơn.
• Do nguồn tài liệu và sản phẩm thực hiện đều sử dụng tiếng Anh nên việc thể hiện lại một vài thuật ngữ bằng tiếng Việt còn nhiều bối rối khi chưa truyền tải chính xác các thuật ngữ chuyên ngành.
Sau khi nghiên cứu về kiểm thử và áp dụng vào thực hành, em đã hiểu được kiểm thử là công việc rất quan trọng Sự áp dụng với kiến thức tìm hiểu được mới chỉ dừng lại ở một bài toán nhỏ Hướng phát triển tiếp theo đó là:
• Thực hiện kiểm thử trên module khác, lớn hơn, rộng hơn, phức tạp hơn của dự án.
• Tìm hiểu và nghiên cứu thêm về các công cụ kiểm thử tự động, kiểm thử website, kiểm thử tải, kiểm thử cơ sở dữ liệu
