test case là gì

Với những người dân mới mẻ dò la hiểu có lẽ rằng còn rất rất xa lạ với thuật ngữ test case vô tiến độ design ứng dụng. Vậy Test case là gì? Làm thế này nhằm tạo nên những biểu kiểu mẫu test case hóa học lượng? Tất cả sẽ tiến hành Vietnix share cụ thể cho tới độc giả vô nội dung bài viết sau đây!

Test case là gì?

Test case hoặc kịch phiên bản kiểm thử được dùng làm đánh giá những trường hợp hoàn toàn có thể xẩy ra, kể từ cơ xác lập coi phần mềm ứng dụng hay như là một tác dụng phần mềm với sinh hoạt đích thị hay là không.

Bạn đang xem: test case là gì

Test case tế bào miêu tả những nhân tố sau:

• Dữ liệu nguồn vào (Input).
• Hành động (Active) – Sự khiếu nại (Event).
• Kết ngược mong ngóng (Expected response).

Bộ test case với cường độ cụ thể không giống nhau tùy nằm trong vô văn cảnh của dự án công trình và quy tế bào doanh nghiệp lớn phát hành ứng dụng.

Testcase được cải tiến và phát triển bên trên Excel, World. Quy trình cải tiến và phát triển test case hoàn toàn có thể chung dò la lỗi vô quy trình design phần mềm. Do cơ, việc sẵn sàng test case càng nhanh chung vạc hiện tại lỗi càng nhanh chóng và chung tinh giảm thời hạn design ứng dụng.

Vai trò của Test case

Vai trò chủ yếu của test case là đáp ứng tác dụng phần mềm hoặc phần mềm được design sinh hoạt với thành quả quả thật mong ngóng. Đây là bước trước tiên vô quy trình test nhưng mà bất kể Tester nào thì cũng cần tiến hành. Nếu kiến tạo test case ko unique hoàn toàn có thể làm cho sơ sót, tác động cho tới quá trình tiếp theo sau.

Ngoài tầm quan trọng chủ yếu này, test case còn tồn tại tầm quan trọng cần thiết vô việc:

• Đảm bảo phạm vi kiểm demo.
• Phát hiện tại những lỗi, bug, thiếu hụt sót vô tác dụng và chung nâng cấp unique ứng dụng. Quá trình vận hành, duy trì và update cũng trở thành dễ dàng và đơn giản rộng lớn.
• Giúp xác lập liệu ứng dụng tiếp tục đáp ứng đủ mong ước người tiêu dùng ko. Nếu ko thì lập trình sẵn viên cần thiết đánh giá và sửa lại trước lúc tung ứng dụng đi ra thị ngôi trường.
• Tester hoàn toàn có thể tiến hành nhiều test case đồng thời để xem nhận ứng dụng ở nhiều góc nhìn không giống nhau.
• Test case hoàn toàn có thể được tái mét dùng vô hạn vô sau này, miễn sao tester cảm nhận thấy tương thích.

Cấu trúc của một Test case là gì?

Để hiểu và thực hành thực tế thành thục phần test case, bạn phải nắm chắc cấu tạo của một phiên bản kiểm demo bao hàm những bộ phận này. Thực tế, cấu tạo của test case tiếp tục không giống nhau ở từng dự án công trình, từng doanh nghiệp lớn.

Sau đó là những bộ phận chủ yếu chúng ta cũng có thể phát hiện Khi kiến tạo test case:

• Mã test case (ID test case): Giá trị cần thiết nhằm xác lập trật tự của test case. ID hoàn toàn có thể bao hàm chữ và số được ghi lại theo đuổi trật tự tăng dần dần.
• Mục đích kiểm demo (Test case Description): Mô miêu tả mục tiêu của test case là đánh giá tác dụng này. Tại mục này, Tester tiếp tục tế bào miêu tả việc làm tiến hành.
• Dữ liệu kiểm demo (Test Data): Dữ liệu cần thiết sẵn sàng nhằm tiến hành việc kiểm demo, hoàn toàn có thể với hoặc ko tùy theo quy tế bào dự án công trình. Tester hoàn toàn có thể nhằm ở dạng thương hiệu data hoặc đường đi cho tới tệp tin.
• Các bước tiến hành (Test Steps): Mô miêu tả cụ thể những bước tiến hành test. Tuy nhiên, Tester nên tế bào miêu tả một cơ hội ngắn ngủn gọn gàng và thiệt rõ nét. Đồng thời tránh việc bỏ lỡ những sự khiếu nại quan trọng nhất nhằm hoàn toàn có thể dễ dàng và đơn giản tiến hành lại Khi với lỗi.
• Kết ngược mong ước (Expected Results): Hiển thị thành quả mong ngóng kể từ những bước kiểm demo. Kết ngược mong ước thông thường dựa vào đòi hỏi của quý khách hàng hoặc Reviews theo đuổi tư liệu trình độ.
• Kết ngược thực tiễn (Test Results): Hiển thị thành quả thực tiễn kể từ những bước tiến hành bên trên môi trường xung quanh của khối hệ thống, thông thường được xem là pass, fail hoặc pending.

Ngoài đi ra vô test case hoàn toàn có thể với một trong những nhân tố không giống như:

• Tester (Người thực hiện).
• Pre-condition (Điều khiếu nại chi phí đề).
• Date excute test (Ngày thực hiện).
• Comments (Thông tin tưởng bổ sung cập nhật thêm),…

Các group chủ yếu của Test case là gì?

Hiện ni, những loại test case được tạo thành 4 group chủ yếu tại đây. quý khách hàng cần thiết nắm vững những group này nhằm phân loại đích thị test case vô quy trình kiểm thử:

1. GUI test case: Bao bao gồm toàn bộ những test case được kiến tạo nhằm đánh giá hình mẫu người tiêu dùng hình đồ họa.
2. Positive test case: Bao bao gồm những test case tích rất rất, hợp thức, nhập tài liệu đích thị.
3. Negative test case: Bao bao gồm những test case xấu đi, ko hợp thức, nhập tài liệu sai.
4. Combination test case: Bao bao gồm những test case nằm trong lòng 2 loại positive và negative. Những test case này còn có nhiều bước đích thị, sai xen kẹt tuy nhiên bước sau cùng luôn luôn đích thị.

Các loại Test case thịnh hành hiện tại nay

Có nhiều loại testcase không giống nhau đáp ứng theo đuổi yêu cầu kiểm demo của Tester. Tùy vào cụ thể từng tiến độ cải tiến và phát triển ứng dụng nhưng mà bạn phải lựa lựa chọn loại test case cho tới tương thích.

Functionality Test Case

Functionality Test Case (Test case chức năng) chung xác lập thành công xuất sắc hoặc thất bại của một tác dụng ứng dụng cũng đó là độ quý hiếm kỳ vọng. Những case này đòi hỏi ứng dụng được chấp nhận test nhưng mà không cần thiết phải truy vấn vô cấu tạo bên dưới của ứng dụng.

Chúng hoàn toàn có thể được ghi chép và chạy sớm vô tiến độ development ngay trong khi những tác dụng trước tiên hoàn thiện. Chúng hoàn toàn có thể được ghi chép vì chưng mã code, nếu như được đòi hỏi. Functionality Test Case nên được tái diễn bất kể lúc nào với thay cho thay đổi trong những tác dụng của ứng dụng.

User Interface Test Case

User Interface Test Case (Test case hình mẫu người dùng) được dùng nhằm xác minh những bộ phận của GUI (giao diện người tiêu dùng đồ gia dụng họa) với đang được sinh hoạt đích thị mong ngóng ko. Loại test case này chung kiểm lăm le về ngữ pháp, thẩm mỹ và làm đẹp và lỗi dịch thuật, links hoặc bất kể bộ phận này nhưng mà người tiêu dùng hoàn toàn có thể thấy bên trên hình mẫu.

Những case này thông thường được kết hợp kiến tạo vì chưng group Designer và group Tester. Những test case này tiếp tục chạy bên trên tiến độ hoàn mỹ ứng dụng, Khi nhưng mà GUI và được liên kết với hạ tầng tài liệu nhằm đánh giá coi ứng dụng với tương quí và sinh hoạt chất lượng trên rất nhiều trình duyệt ko.

Performance Test Case

Performance Test Case (Test case hiệu suất) được dùng nhằm đánh giá tính năng ứng dụng, ví dụ là thời hạn phản hồi và hiệu suất sinh hoạt của phần mềm. Test case này tiếp tục được chấp nhận đánh giá thời hạn quan trọng nhằm khối hệ thống phản hồi một sinh hoạt theo đuổi cỗ tiêu chuẩn rõ nét.

Performance Test Case thông thường được Tester ghi chép và được chấp nhận chạy tự động hóa liên tiếp vô xuyên suốt quy trình design ứng dụng. Chúng sẽ hỗ trợ xác lập coi phần mềm sinh hoạt thực tiễn thế nào, cũng tựa như các tình huống ví dụ nhưng mà phần mềm sinh hoạt ko hiệu suất cao. Từ cơ lập trình sẵn viên hoàn toàn có thể đánh giá nhằm nâng cấp hiệu suất phần mềm tối ưu rộng lớn.

Integration Test Case

Integration Test Case (Test case tích hợp) được dùng nhằm đánh giá sự tương tác trong số những module cùng nhau. Mục đích chủ yếu của test case này là đáp ứng hình mẫu trong số những module tương quí và sinh hoạt rất tốt vào cụ thể từng ĐK.

Integration Test Case thông thường được kết hợp kiến tạo vì chưng group Tester và group Development. Tester tiếp tục xác lập chống cần thiết tổ chức test. Trong Khi cơ, developer hỗ trợ những tài liệu nguồn vào cho tới từng tình huống kiểm demo. Cuối nằm trong, 1 trong các 2 group tiếp tục tiến hành xác lập coi những module sinh hoạt song lập hoàn toàn có thể kết hợp thao tác bên cạnh nhau ko.

Usability Test Case

Usability Test Case (Test case tính khả dụng) hoặc Task (nhiệm vụ) hoặc Scenarios (Kịch bản) hỗ trợ trọng trách hoặc kịch phiên bản đòi hỏi Tester cần hoàn thiện. Test case này chung Tester thưởng thức và xác lập phương phía tiếp cận, dùng thành phầm, công ty của người tiêu dùng Theo phong cách ngẫu nhiên nhất. Các tình huống demo nghiệm được sẵn sàng vì chưng cả hai group Designer – Tester và cần được tổ chức thực hiện trước lúc tổ chức User Acceptance Test Cases (Kiểm demo gật đầu người dùng).

Xem thêm: hd là gì

Database Test Case

Database Test Case (Test case hạ tầng dữ liệu) được dùng nhằm đánh giá những luồng xử lý, phía chuồn vô hạ tầng tài liệu của phần mềm. Test case này được tiến hành nhằm đảm nói rằng lập trình sẵn viên xử lý và tàng trữ tài liệu vô database một cơ hội nhất quán, đáng tin cậy.

Để kiến tạo Database Test Case, Tester cần thiết làm rõ về phần mềm, hạ tầng tài liệu phần mềm cũng tựa như các giấy tờ thủ tục quan trọng cho tới tàng trữ, quản ngại trị tài liệu. Thông thông thường, Tester tiếp tục dùng truy vấn SQL nhằm kiến tạo những test case này.

Security Test Case (Test case bảo mật)

Security Test Case (Test case bảo mật) được dùng nhằm đáp ứng phần mềm được phân quyền tài liệu và giới hạn đột nhập ở những điểm quan trọng. Từ cơ chung bảo đảm tài liệu ở những chống quan trọng. Security Test Case sẽ tiến hành kiến tạo nhằm đánh giá xâm nhập và cường độ xác thực, mã hóa tài liệu của phần mềm. Nhóm Security tiếp tục là kẻ phụ trách chủ yếu cho tới loại test case này.

User Acceptance Test Case

User Acceptance Test Cases (Test case gật đầu người dùng) được dùng nhằm đánh giá môi trường xung quanh dùng của người tiêu dùng. Mục đích của những test case là xác minh rằng phần mềm hoàn toàn có thể đáp ứng nhu cầu được yêu cầu người tiêu dùng ở toàn bộ những nghành nghề dịch vụ. Chính chính vì vậy, test case này rất cần phải kiến tạo nhiều mẫu mã nghành nghề dịch vụ, ngành nghề nghiệp và bám sát vô thực tiễn nhất.

Những người kiến tạo User Acceptance Test Cases hầu hết là vận hành dự án công trình hoặc group Tester. Đây là bước kiểm demo sau cùng và cần thiết nhất trước lúc công thân phụ thành phầm và đi vào phát hành thực tiễn.

Những chuyên môn Test case điển hình

Để hoàn toàn có thể tạo ra một test cases điển hình nổi bật đáp ứng unique của ứng dụng, chúng ta cũng có thể vận dụng những chuyên môn tại đây :

Kỹ thuật Test case tĩnh

Kỹ thuật test case tĩnh hoặc Static Testing Technique là cách thức kiểm demo tay chân trải qua giấy tờ cây viết nhưng mà ko cần thiết chạy ứng dụng thẳng. Kiểm demo tĩnh thông thường được tiến hành thủ công bằng tay hoặc những ứng dụng, dụng cụ kiểm demo. Quá trình này tiếp tục tự lập trình sẵn viên hoặc người review code tiến hành nhằm mục đích đánh giá code, đòi hỏi chuyên môn, tư liệu design, mã mối cung cấp, kịch phiên bản demo nghiệm,… với đúng chuẩn và khả ganh đua ko.

Các loại kiểm demo tĩnh thông thường bao gồm:

• Informal Review: Là quy trình kiểm demo ko đầu tiên, vô cơ những tư liệu chuyên môn sẽ tiến hành đánh giá và phán xét.
• Walk-throught: Là cách thức share vấn đề, chỉ dẫn, phân tích và lý giải, fake giao thông vận tải tin tưởng sẽ giúp những người dân nhập cuộc kiểm demo làm rõ về ứng dụng, phần mềm. Từ cơ chúng ta hoàn toàn có thể phân biệt và vạc hiện tại những lỗi tồn bên trên vô ứng dụng. Test case này thông thường được tổ chức triển khai trở nên một cuộc họp và được biên chép, tàng trữ vấn đề lại.
• Technical review: Là cách thức kiểm demo triệu tập vô việc Reviews và thảo luận về phần chuyên môn của phần mềm, ứng dụng. Từ cơ thể hiện phương phía xử lý, thay cho thế chuyên môn, sửa thay đổi lỗi,… nhằm tối ưu phần mềm.
• Inspection: Là cách thức kiểm demo chung xác lập những khuyết thiếu còn tồn bên trên. Người phê duyệt tiếp tục tiến hành đánh giá coi những tư liệu việc làm và được hoàn thiện cho tới đâu.

Kỹ thuật Test case động

Kỹ thuật test case động hoặc Dynamic Testing Technique là cách thức kiểm demo trải qua việc dùng máy chạy lịch trình. Lúc này, code và được vận hành, nguồn vào và được hỗ trợ độ quý hiếm và cho tới thành quả (đầu ra). Kiểm demo động tiếp tục đối chiếu thành quả thực tiễn này với thành quả mong ngóng thuở đầu nhằm xác lập rằng ứng dụng tiếp tục đáp ứng nhu cầu yêu cầu hoặc ko.

Các chuyên môn test case động bao hàm 3 group chủ yếu sau:

1. Kỹ thuật Specification-based

Đây là group chuyên môn kiểm demo triệu tập vô những nhân tố bên phía ngoài như: cơ hội design, cơ hội vận hành bên phía ngoài,… Tester hoàn toàn có thể đánh giá nhưng mà ko tác dụng thực hiện thay cho thay đổi cấu tạo phía bên trong ứng dụng.

Các chuyên môn ví dụ nằm trong group này gồm những:

• Phân vùng tương tự (Equivalence Partitioning): Đầu vô sẽ tiến hành phân tạo thành những lớp tài liệu với ĐK tương tự nhằm tiến hành những ca kiểm demo.
• Phân tích độ quý hiếm biên (Boundary Value Analysis): Tester tiếp tục tiến hành kiểm demo độ quý hiếm biên của tài liệu vô và đi ra theo đuổi 2 cơ hội chủ yếu là: Kiểm tra 2 độ quý hiếm (với 4 test case là nhỏ nhất, sát bên dưới nút nhỏ nhất, lớn số 1, sát bên trên nút rộng lớn nhất) và Kiểm tra 3 độ quý hiếm (với 6 test case là nhỏ nhất, sát bên dưới nút nhỏ nhất, sát bên trên nút nhỏ nhất, lớn số 1, sát bên dưới nút lớn số 1, sát bên trên nút rộng lớn nhất).
• Bảng đưa ra quyết định (Decision Table Testing): Được tiến hành Khi nguồn vào chứa đựng nhiều ĐK và Output đầu ra chứa đựng nhiều hành vi. Kỹ thuật này chung tiết kiệm ngân sách và chi phí thời hạn chạy demo lịch trình vẫn khái quát toàn cỗ Output đầu ra và nguồn vào.
• Chuyển thay đổi hiện trạng (State Transition Testing): Là cách thức kiểm demo bằng phương pháp thay cho thay đổi ĐK nguồn vào dẫn cho tới sự thay cho thay đổi hiện trạng của ứng dụng, phần mềm. Cụ thể, Tester tiếp tục hỗ trợ tài liệu nguồn vào hợp thức và ko hợp thức nhằm đánh giá phương thức phản hồi của khối hệ thống cho tới từng tình huống.
• Trường phù hợp dùng (Use cases Testing): Là cách thức kiểm demo chung xác lập toàn cỗ test case đang rất được tiến hành bên trên toàn cỗ khối hệ thống. Từ cơ chung dò la tìm tòi và xử lý những lỗi kể từ kiểm demo tích phù hợp.

2. Kỹ thuật Structure-based

Đây là group chuyên môn được dùng nhằm kiểm demo cấu tạo và cơ hội vận hành của ứng dụng, phần mềm. Để tiến hành được chuyên môn này, Tester cần tiếp liền về lập trình sẵn thì mới có thể hoàn toàn có thể hấp thụ input và kiểm demo output đúng chuẩn.

Những chuyên môn ví dụ nằm trong group này gồm những:

• Kiểm demo câu mệnh lệnh (Statement testing): Tester đánh giá cơ hội vận hành của mã mối cung cấp bằng phương pháp thực ganh đua từng câu mệnh lệnh tối thiểu một phiên theo đuổi những ĐK đích thị.
• Kiểm demo quyết định (Decision testing): Được dùng nhằm đánh giá coi vô lịch trình với câu mệnh lệnh này ko thể truy vấn hoặc làm cho không bình thường ko. Trong số đó, Tester tiếp tục chính thức kể từ điểm đưa ra quyết định (decision point) và theo đuổi control flow nhằm đánh giá thành quả đưa ra quyết định (decision resuilt).
• Kiểm demo điều kiện (Condition testing): Được dùng nhằm đánh giá những biểu thức Boolean bằng phương pháp thực ganh đua bọn chúng tối thiểu một phiên vì chưng cả độ quý hiếm đích thị và sai.
• Kiểm demo nhiều điều kiện (Multiple condition testing): Được dùng nhằm kiểm demo toàn cỗ tổng hợp ĐK hoàn toàn có thể của đưa ra quyết định. Trong số đó, con số tổng hợp đó là số test case cần tiến hành và vì chưng 2 lũy quá bậc N (N là số điều kiện).

3. Kỹ thuật Experience-based

Nhóm chuyên môn experience-based được design dựa vào kiến thức và kỹ năng, tay nghề, năng lượng trình độ của Tester.

Những chuyên môn ví dụ của group này bao gồm:

• Kiểm demo thăm hỏi dò la (Exploratory testing): Tester tiếp tục vừa vặn thăm hỏi dò la ứng dụng, vừa vặn design và thiện hiện tại quy trình kiểm demo. Quá trình này sẽ không ra mắt theo đuổi chương trình hoặc quá trình ví dụ nhưng mà thay cho thay đổi hoạt bát theo đuổi tay nghề của từng Tester.
• Phỏng đoán lỗi (Error guessing): Tester tiếp tục phỏng đoán những lỗi ẩn chứa hoàn toàn có thể tồn bên trên vô ứng dụng dựa vào vốn liếng tay nghề đã có sẵn.

Hướng dẫn cơ hội ghi chép Test case hóa học lượng

Nếu chúng ta vẫn không biết cơ hội ghi chép test case unique thì hoàn toàn có thể tiến hành theo đuổi 5 bước cụ thể bên dưới đây:

1. Xác lăm le mục đích: Tại đoạn này, Tester cần thiết dò la hiểu yêu cầu và mong ước của quý khách hàng. Sau cơ đưa ra những tiềm năng, tiêu xài chuẩn chỉnh ví dụ cho tới test case sẽ giúp ứng dụng, phần mềm hoàn toàn có thể đáp ứng nhu cầu những yêu cầu này.
2. Xác lăm le hiệu suất: Bước này đòi hỏi Tester cần tiếp liền về lập trình sẵn. Trong số đó, các bạn sẽ cần xác lập coi module đang được test với tác dụng gì, tài liệu, bộ phận vô module tiếp tục tương tác cùng nhau thế nào,… kể từ cơ đo lường và tính toán được hiệu suất kiểm demo.
3. Xác lăm le đòi hỏi phi chức năng: Cạnh cạnh đòi hỏi về Hartware, cấu tạo khối hệ thống hoặc bảo mật thông tin tài liệu thì những đòi hỏi phi tác dụng cũng khá cần thiết với 1 phần mềm, ứng dụng. Vì vậy ở đoạn này, Tester cần thiết liệt kê toàn cỗ những đòi hỏi phi tác dụng hoàn toàn có thể xuất hiện tại và tổ chức kiểm demo.
4. Xác lăm le biểu mẫu: Mỗi ứng dụng, phần mềm sẽ sở hữu những biểu kiểu mẫu testing không giống nhau. Tuy nhiên, nhìn tổng thể vô quy trình ghi chép test case, Tester cần thiết đảm biểu kiểu mẫu chứa chấp những nhân tố bao gồm hình mẫu người tiêu dùng (UI), tác dụng, năng lực tương quí, hiệu suất ứng dụng.
5. Xác lăm le tương tác thân thích module: Cuối nằm trong nhằm ghi chép test case unique, Tester cần thiết làm rõ cơ hội những module đang được tương tác cùng nhau. Vấn đề này chung tối ưu quy trình test tương tự đáp ứng test case chứa đựng toàn cỗ những module với link.

Những thắc mắc thông thường gặp gỡ về Test case là gì?

Lời kết

Test case đóng tầm quan trọng cần thiết vô quy trình kiểm demo và yên cầu Tester cần vâng lệnh theo như đúng những nguyên lý nhằm tiết kiệm ngân sách và chi phí thời hạn, sức lực lao động. Khi tiếp tục dùng nhuần nhuyễn thì test case là 1 trong những dụng cụ vô nằm trong hiệu quả giúp cho bạn cải tiến và phát triển ứng dụng. Nếu còn bất kể vướng mắc hoặc share tay nghề trong những công việc ghi chép test case hiệu suất cao, chúng ta cũng có thể nhằm lại phản hồi ở bên dưới nhằm quý khách nằm trong thảo luận.