Viết test case cho phần mềm, hướng dẫn cách viết và sắp xếp test case

✓ demo case là một trong trường hợp cần kiểm thử, nó bao hàm các thao tác/hành đụng trên hệ thống, đk cần (tiên quyết), các giá trị đầu vào, và công dụng mong đợi. Một thử nghiệm case thì nên chỉ kiểm tra một ngôi trường hợp, một khía cạnh cụ thể nào đó chứ chớ lan man – xem thêm định nghĩa của ISTQB Glossary.

Bạn đang xem: Viết test case cho phần mềm

Test case là giờ Anh, dịch lịch sự tiếng Việt là “trường vừa lòng kiểm thử” hoặc “ca kiểm thử.” demo case thường sẽ có 2 các loại chính: demo case cụ thể và demo case cơ bản. Sẽ tiến hành trình bày chi tiết bên dưới. Bài viết này đã hướng dẫn bạn cách viết và sắp xếp test case hiệu quả bảo đảm độ bao trùm yêu ước tốt.

Nguyên văn định nghĩa trên trang https://glossary.istqb.org

A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.

Test case gồm những gì

Trong thực tế test case được trình bày theo nhiều định dạng không giống nhau, hoàn toàn có thể sử dụng MS Excel hoặc quy định nào đó để làm chủ test case như Test
Link hoặc Test
Rail. Dù test case được trình diễn theo dạng nào, thì thành phần thiết yếu của chạy thử case cũng bao gồm các thông tin sau:

Test case ID: Để thuận lợi xác định và rõ ràng test case cùng với nhau
Test summary: Để biểu đạt tóm tắt ngôi trường hợp đề nghị kiểm thử. Có cách gọi khác là test objective.Test precondition: Điều kiện tiên quyết, điều kiện cần để demo case này chạy được
Test steps: công việc thực hiện test case
Expected result: công dụng mong đợi, điều bạn muốn chương trình/màn hình/API/… kia thực hiện, thường dựa vào tài liệu biểu lộ để xác định kết quả mong chờ này.Test result: Ghi tác dụng của thử nghiệm case, thường xuyên là OK (đạt), và NG (không đạt)

Ngoài ra còn có các thông tin khác góp mình làm chủ test case giỏi hơn, giúp mình hiểu rằng test case này là viết đến yêu mong nào, user story nào,… thì mình đang thêm cột test requirement,… nhằm quản lý.

Test case mẫu

Một ví dụ thử nghiệm case mẫu trình bày bằng MS Excel

Quy trình viết chạy thử case

Tuỳ vào nhiều loại test case, mức kiểm thử, hoặc chương trình nhiều người đang viết kiểm tra case thì sẽ có các bước, trình tự khác nhau để viết demo case, nhưng nhìn tổng thể thì tiến trình viết test case sẽ gồm công việc cơ phiên bản sau:

Tìm hiểu khối hệ thống cần kiểm thử
Viết thử nghiệm case
Sắp xếp test case

Tìm hiểu khối hệ thống đang được kiểm thử

Bạn buộc phải đọc tài liệu SRS (software requirement specification) tốt spec (specification) với những nhiều loại tài liệu khác, bao gồm user story (hay viết tắt là US) để hiểu về hệ thống. Thậm chí là bạn phải thực hiện thử những phiên bạn dạng hiện có, hoặc phiên phiên bản khác như web (trong lúc chúng ta viết test case cho phiên bản mobile – đang được phát triển). Có khi bạn phải mày mò các ứng dụng tương tự trên thị trường, sản phẩm của đối thủ cạnh tranh,… ví như dự án của doanh nghiệp không có tài năng liệu biểu lộ yêu cầu.

Phân tích tài liệu thường gặp như user story, SRS giỏi use case (không phải là user case nha) là quan trọng khi bạn áp dụng kỹ thuật kiến thiết test case hộp đen (black-box chạy thử techniques) để viết demo case. Còn nếu như khách hàng đang áp dụng kỹ thuật vỏ hộp trắng (white-box khosoft.com) thì phải cần phải có source code, tài liệu diễn tả thiết kế cụ thể như ERD, sequence diagram, v.v…

Viết chạy thử case

Áp dụng những kỹ thuật kiến tạo test case như phân vùng tương đương, phân tích giá trị biên, bảng quyết định, v.v… để khẳng định các trường hợp phải kiểm thử với viết nó ra. đặc biệt quan trọng là các bạn phải nghĩ ra được đông đảo trường hợp nên kiểm thử, còn việc trình diễn thì theo mẫu (format) của dự án công trình bạn sẽ tham gia thôi. Mỗi dự án, công ty, hay khách hàng khác nhau họ sẽ sử dụng những định dạng (format) chạy thử case và chế độ (tool) làm chủ test không giống nhau.

Xem thêm: Dollar Soft Dollar Là Gì ? Sự Khác Biệt Giữa Phí Đô La Mạnh Và Phí Đô La Yếu

“Viết thử nghiệm case sao cho bao phủ đủ?” là một câu hỏi thường chạm chán nhưng cạnh tranh trả lời. Để xác định “như ráng nào là đủ” đã còn phụ thuộc vào mong ước của khách hàng, mục tiêu kiểm thử của chúng ta là gì? (mục tiêu của doanh nghiệp test để làm gì), và bạn có bao nhiêu tester tham gia, bao nhiêu thời hạn để viết và xúc tiến test case? nếu như viết nhiều mà không tồn tại thời gian nhằm chạy hết thì viết nhiều để làm gì? Viết những mà che phủ các trường hòa hợp ở trong thuộc 1 vùng tương tự thì liệu có công dụng không?

Sắp xếp demo case

Sau khi chúng ta viết case kết thúc thì phải xem lại và bố trí test case trước sau theo một trình tự nhằm khi xúc tiến cho hiệu quả. Thường chạy thử case sẽ được sắp xếp dựa vào độ ưu tiên, một số loại test case, và sự phụ thuộc lẫn nhau.

Độ ưu tiên: demo case mang lại các tác dụng ưu tiên cao (P1 – priority 1) thì được bỏ lên trên (để thực hiện/chạy trước) và chạy thử case của màn hình có ưu tiên thấp hơn (P2, P3) thì để sau.Loại thử nghiệm case: test case để bình chọn UI thường để sau kiểm tra case nhằm kiểm tra công dụng hoặc UI ở trước tuỳ dự án công trình ưu tiên UI hay chức năng. Positive thử nghiệm case (happy case) thì cần nằm trước negative kiểm tra case (unhappy case). Kiểm tra case cho mục tiêu regression khosoft.com (kiểm demo hồi quy thì cần để sau cùng).Sự phụ thuộc: test case cho các màn hình/chức năng dựa vào vào chức năng/màn hình không giống thì phải để sau. Ví dụ, test cases để kiểm thử trường vừa lòng hiển thị cùng phân trang (pagination) thì nên cần để sau những test case cho tác dụng (nút) tìm kiếm kiếm trong cùng màn hình.

Mức chi tiết của demo case

Thường thử nghiệm case có khá nhiều mức, nhưng bài này mình nói đến 2 mức chi tiết chính là high-level test case (test case cơ bản), và detailed demo case (test case đưa ra tiết).

High-level thử nghiệm case

Nhiều người cho rằng test case cơ phiên bản này là checklist, nhưng thực tế nó không phải. Checklist là danh sách những trường hợp nên kiểm test chung dành cho mọi chương trình, hệ thống. Nói giải pháp khác, cùng với checklist thì nó là “dùng chung” mang đến mọi thành phầm cùng nhiều loại hoặc gồm chứng năng tương tự, ví dụ: lúc kiểm thử web thì:

Nên kiểm test trên những trình chú tâm khác nhau
Nên khám nghiệm UI cùng UXNên kiểm tra tính năng chính
Nên kiểm tra việc phân quyền cho những loại user không giống nhau
Nên khám nghiệm hiệu năng (vì có thể sẽ có rất nhiều người truy vấn cùng lúc)Nên kiểm tra review khả năng bảo mật (security khosoft.com) của hệ thống

Nhưng tuỳ vào khối hệ thống mà nhiều người đang test, thì các bạn sẽ phải biết (thường là dựa vào tài liệu thể hiện yêu ước chức năng, phi chức năng) để hiểu rằng UI cầm nào là đúng và bao gồm bao nhiêu nhiều loại user trong khối hệ thống đó, và user nào hoàn toàn có thể làm được gì (authorization).

High-level thử nghiệm case là khi bạn liệt kê list những ngôi trường hợp phải kiểm test đó, tuy vậy không biểu lộ chi tiết các bước thực hiện tương tự như dữ liệu, giá chỉ trị nên nhập vào, và kết quả mong muốn như vậy nào.

Test case chi tiết

Ngược lại với high-level demo case, demo case chi tiết phải bao gồm thông tin đưa ra tiết công việc thực hiện tương tự như dữ liệu, giá trị đề xuất nhập vào, và công dụng mong muốn như vậy nào. Tuỳ vào các loại test case (UI, chức năng, phi chức năng,…) mà công việc thực hiện hoặc hiệu quả mong ngóng sẽ không giống nhau. Nhưng, điểm phổ biến của chạy thử case chi tiết là đề xuất mô tả dữ liệu đầu vào và hiệu quả mong đợi, thường xuyên được hotline là thử nghiệm data (dữ liệu test).