Testcase Là Gì

     

Test Case được định nghĩa là 1 nhóm các điều khiếu nại mà từ đó người kiểm thử xác minh liệu một ứng dụng ứng dụng có chuyển động theo yêu thương cầu của khách hàng hay không. Kiến thiết Test Case bao gồm các đk tiên quyết, thương hiệu trường hợp, đk đầu vào và tác dụng mong đợi. Một test Case là một hành vi cấp độ thứ nhất và bắt nguồn từ những kịch bản thử nghiệm.

Bạn đang xem: Testcase là gì

*

Đây là một tài liệu cụ thể chứa tất cả các đầu vào hoàn toàn có thể có (tích cực cũng tương tự tiêu cực) và các bước điều hướng, được thực hiện cho quy trình thực hiện kiểm tra. Câu hỏi viết các Test Case là 1 lần thử một lần có thể được sử dụng trong tương lai tại thời điểm kiểm tra hồi quy.

Test Case tin báo chi tiết về chiến lược thử nghiệm, tiến trình thử nghiệm, các điều kiện tiên quyết và áp ra output dự kiến. Bọn chúng được thực hiện trong quá trình thử nghiệm để soát sổ xem ứng dụng phần mềm có đang tiến hành nhiệm vụ nhưng nó đã được cải tiến và phát triển hay không.

Test Case giúp người kiểm tra báo cáo lỗi bằng phương pháp liên kết lỗi cùng với ID demo Case. Tài liệu test Case chi tiết hoạt động như một biện pháp đảm bảo an toàn bằng chứng khá đầy đủ cho team thử nghiệm bởi nếu nhà phát triển bỏ sót điều gì đó, thì nó rất có thể bị bắt trong quy trình thực hiện các Test Case khá đầy đủ này.

Để viết demo Case, họ phải có những yêu cầu để đưa các đầu vào và những kịch bạn dạng thử nghiệm buộc phải được viết sao cho họ không quăng quật sót bất kỳ tính năng nào để thử nghiệm. Sau đó, chúng ta nên có mẫu thử nghiệm Case để duy trì tính đồng hóa hoặc rất nhiều kỹ sư phân tích theo cùng một giải pháp tiếp cận để sẵn sàng tài liệu demo nghiệm.

Nói chung, chúng tôi sẽ viết test Case bất cứ lúc nào nhà phát triển bận viết mã.


Tóm tắt nội dung


Khi nào chúng ta viết một chạy thử Case?

Chúng tôi đang viết kiểm tra Case khi shop chúng tôi nhận được hầu như điều sau:

Sau đó, khi người tiêu dùng đưa ra yêu cầu của doanh nghiệp, đơn vị phát triển ban đầu phát triển và nói rằng họ cần 3,5 tháng để xây dựng thành phầm này.Và trong những khi chờ đợi, đội kiểm test sẽ bắt đầu viết những Test Case.Sau khi hoàn thành, nó đã gửi đến Trưởng nhóm kiểm tra để thực hiện xem xét.Và khi các nhà phát triển chấm dứt việc phát triển sản phẩm, nó sẽ tiến hành giao đến nhóm kiểm thử.Các kỹ sư kiểm tra không bao giờ nhìn vào yêu thương cầu trong khi kiểm tra tài liệu sản phẩm cũng chính vì kiểm tra là liên tục và không phụ thuộc vào vào trung khu trạng của người đó rộng là unique của kỹ sư kiểm tra.

Lưu ý: lúc viết thử nghiệm Case, không bao giờ nên viết tác dụng thực tế vì thành phầm vẫn đã trong quy trình phát triển. Đó là tại sao tại sao công dụng thực tế chỉ nên được ghi sau khi thực hiện các Test Case.

Tại sao cửa hàng chúng tôi viết những Test Case?

Chúng tôi vẫn viết bài kiểm tra vì những tại sao sau:

Để yêu ước tính đồng hóa trong việc xúc tiến Test CaseĐể đảm bảo phạm vi kiểm tra tốt hơnNó nhờ vào vào quá trình hơn là vào một trong những ngườiĐể kị đào tạo cho mọi kỹ sư test nghiệm new về sản phẩm

Để yêu ước tính nhất quán trong việc tiến hành Test Case: công ty chúng tôi sẽ xem test Case và ban đầu thử nghiệm ứng dụng.

Để bảo vệ phạm vi kiểm tra xuất sắc hơn: đối với điều này, họ nên bao hàm tất cả các tình huống hoàn toàn có thể xảy ra và đánh dấu nó, để chúng ta không cần được nhớ lại toàn bộ các tình huống.

Nó dựa vào vào tiến trình hơn là vào nhỏ người: Một kỹ sư demo nghiệm đã làm nghiệm một ứng dụng trong đợt phát hành đầu tiên, lần xây cất thứ hai với rời doanh nghiệp vào thời điểm phát hành lần vật dụng ba. Lúc kỹ sư test nghiệm hiểu một mô-đun cùng thử nghiệm vận dụng kỹ lưỡng bằng phương pháp lấy ra nhiều giá trị. Nếu người đó không ở đó trong lượt phát hành đồ vật ba, thì điều này sẽ trở bắt buộc khó khăn đối với người mới. Vị đó, toàn bộ các giá trị dẫn xuất được khắc ghi để nó hoàn toàn có thể được sử dụng trong tương lai.

Để né đào tạo nên mọi kỹ sư test nghiệm new về sản phẩm: khi kỹ sư thí điểm rời đi, anh ta / cô ta rời đi với không ít kiến ​​thức và kịch bản. Các kịch bản đó đề nghị được ghi lại để kỹ sư kiểm demo mới có thể kiểm tra với các trường hợp đã cho và cũng hoàn toàn có thể viết các kịch bản mới.

Lưu ý: khi các nhà trở nên tân tiến đang cải cách và phát triển sản phẩm đầu tiên cho bạn dạng phát hành đầu tiên, kỹ sư demo nghiệm đang viết các Test Case. Với trong phiên bản phát hành trang bị hai, lúc các tính năng lạ được thêm vào, kỹ sư thí điểm cũng viết các Test Case cho điều đó và trong phiên bản phát hành tiếp theo, lúc các thành phần được sửa đổi, kỹ sư xem sét sẽ chuyển đổi các chạy thử Case hoặc viết những Test Case mới. Cũng.

Test case template

Mục đích chính của việc viết một thử nghiệm Case là để đạt được tác dụng của ứng dụng.

*

Như chúng ta đã biết, tác dụng thực tế được ghi sau khi thực thi thử nghiệm Case và phần lớn thời gian, nó đã giống như hiệu quả mong đợi. Mà lại nếu đến bước kiểm tra sẽ bị lỗi thì lại khác. Do vậy, trường hiệu quả thực tế rất có thể được bỏ qua mất và trong phần nhấn xét, chúng ta có thể viết về những lỗi.

Ngoài ra, trường Đầu vào rất có thể bị xóa và tin tức này hoàn toàn có thể được cung ứng trường mô tả.

Mẫu bên trên mà chúng ta thảo luận ở trên chưa phải là chủng loại tiêu chuẩn vì nó rất có thể khác nhau đối với từng công ty và cũng với từng ứng dụng, dựa vào kỹ sư khám nghiệm và trưởng nhóm kiểm tra. Mặc dù nhiên, nhằm thử nghiệm một ứng dụng, tất cả các kỹ sư thử nghiệm phải tuân theo một mẫu mã thông thường, được thành lập theo công thức.

Test Case cần được viết bằng ngôn ngữ đơn giản và dễ dàng để một kỹ sư thử nghiệm bắt đầu cũng hoàn toàn có thể hiểu và tiến hành tương tự.

Trong mẫu mã mẫu sống trên, tiêu đề chứa đều nội dung sau:

Step number

Nó cũng rất quan trọng vì nếu cách số đôi mươi không thành công, chúng tôi có thể ghi lại báo cáo lỗi và vì vậy ưu tiên làm việc và cũng ra quyết định xem đó liệu có phải là lỗi cực kỳ nghiêm trọng hay không.

Test case type

Nó rất có thể là các Test Case chức năng, tích đúng theo hoặc khối hệ thống hoặc những Test Case tích cực và lành mạnh hoặc xấu đi hoặc lành mạnh và tích cực và tiêu cực.

Release

Một phiên bản phát hành gồm thể đựng nhiều phiên phiên bản của bản phát hành.

Pre-condition

Đây là mọi điều kiện quan trọng mà những kỹ sư kiểm thử nên phải vừa lòng trước khi ban đầu quá trình thực hiện kiểm thử. Hoặc kia là thông số kỹ thuật dữ liệu hoặc tùy chỉnh cấu hình dữ liệu rất cần phải tạo để thử nghiệm.

Xem thêm: Sửa Lỗi Máy Chiếu Không Nhận Máy Tính Phổ Biến Nhất Hiện Nay 2022

Ví dụ: trong một ứng dụng, shop chúng tôi đang viết các Test Case để thêm bạn dùng, chỉnh sửa người tiêu dùng và xóa tín đồ dùng. Điều kiện cho từng điều kiện sẽ tiến hành nhìn thấy nếu người dùng A được thêm vào trước khi chỉnh sửa và xóa nó.

Test data

Đây là các giá trị hoặc đầu vào mà họ cần tạo thành theo từng điều kiện.

Ví dụ: Tên người dùng, Mật khẩu và số tài khoản của người dùng.

Trưởng team kiểm tra hoàn toàn có thể được cung ứng dữ liệu chất vấn như tên người tiêu dùng hoặc mật khẩu để kiểm tra ứng dụng hoặc kỹ sư kiểm tra có thể tự tạo ra tên người tiêu dùng và mật khẩu.

Severity

Mức độ nghiêm trọng có thể là lớn, bé dại và quan liêu trọng, nấc độ nghiêm trọng trong kiểm tra Case nói đến tầm quan trọng của những Test Case ví dụ đó. Vớ cả quy trình thực thi văn phiên bản luôn dựa vào vào mức độ nghiêm trọng của những Test Case.

Chúng tôi có thể chọn mức độ nghiêm trọng dựa trên mô-đun. Có rất nhiều tính năng bao gồm trong một mô-đun, ngay cả khi một trong những phần tử là quan liêu trọng, shop chúng tôi khẳng định rằng test Case là quan liêu trọng. Nó phụ thuộc vào các chức năng mà bọn họ đang viết demo case.

Ví dụ: chúng tôi sẽ thực hiện ứng dụng Gmail cùng cho công ty chúng tôi xem nấc độ nghiêm trọng dựa trên các mô-đun:

*
*

Kỹ sư thử nghiệm sẽ viết một demo Case mang lại một anh tài cụ thể. Trường hợp anh ấy / cô ấy cho và đọc những Test Case ngay trong lúc này, anh ấy / cô ấy sẽ không biết bản lĩnh nào đang viết nó. Vày vậy, bộc lộ ngắn gọn sẽ giúp đỡ họ viết demo Case chức năng nào.

Ví dụ về mẫu kiểm tra Case

Ở đây, chúng tôi đang viết một demo Case đến mô-đun Đăng nhập của vận dụng ICICI:

*

Các một số loại Test Case

Chúng tôi tất cả một nhiều loại Test Case khác, như sau:

Function test casesIntegration demo casesSystem kiểm tra cases

Function chạy thử cases

Đầu tiên, công ty chúng tôi kiểm tra nghành nghề nào công ty chúng tôi sẽ viết các Test Case và sau đó mô tả mang lại phù hợp.

Trong test nghiệm tác dụng hoặc trường hợp ứng dụng theo hướng dữ liệu, công ty chúng tôi yêu cầu cột nguồn vào khác; nó khá tốn thời gian.

Quy tắc viết các Test Case chức năng:

Trong cột công dụng mong đợi, nỗ lực sử dụng should be hoặc must be.Đánh dấu tên Đối tượng.Chúng tôi chỉ phải mô tả những cách mà công ty chúng tôi yêu cầu nhất; ví như không, họ không cần xác minh tất cả các bước.Để giảm thời hạn thực hiện nay dư thừa, công ty chúng tôi sẽ viết công việc một cách chủ yếu xác.Viết một demo Case chung; đừng cố gắng mã hóa nó.

Giả sử nó là mô-đun dịch số tiền, vì chưng vậy công ty chúng tôi đang viết các trường hòa hợp kiểm tra tính năng cho nó và tiếp đến cũng chỉ định rằng nó không phải là 1 trong tính năng đăng nhập.

*

Trường hợp kiểm tra tính năng cho mô-đun chuyển số tiền phía trong tệp Excel bên dưới:

*

Integration kiểm tra cases

Trong điều này, bọn họ không nên viết một cái gì đó mà bọn họ đã đề cập trong số Test Case tính năng và một cái gì đó bọn họ đã viết trong thử nghiệm Case tích hợp tránh việc viết lại trong thử nghiệm Case hệ thống.

Quy tắc viết những Test Case tích hợp

Thứ nhất, gọi sản phẩmXác định các tình huống rất có thể xảy raViết demo Case dựa vào mức độ ưu tiên

Khi kỹ sư kiểm test viết những Test Case, họ có thể cần coi xét những khía cạnh sau:

Nếu những trường hợp khám nghiệm là bỏ ra tiết:

Họ sẽ cố gắng đạt được độ bao phủ thử nghiệm buổi tối đa.Tất cả những giá trị hoặc kịch bạn dạng test case những được mô tả chính xác.Họ sẽ gắng gắng suy xét về ý kiến thực hiện.Mẫu được sử dụng để viết test Case phải là duy nhất.

Lưu ý: khi bọn họ liên quan lại đến số lượng bước thấp hơn hoặc phạm vi bảo đảm nhiều hơn, nó đề nghị là chạy thử Case tốt nhất có thể và khi những Test Case này được đưa cho bất kỳ ai, họ sẽ hiểu dễ dàng.

System test cases

Chúng tôi sẽ viết những test case hệ thống cho các luồng ghê doanh.

Quy trình viết các Test Case

Phương pháp viết một kiểm tra Case hoàn toàn có thể được hoàn thành theo quá trình sau:

*

Nghiên cứu vớt hệ thống

Trong đó, cửa hàng chúng tôi sẽ hiểu ứng dụng bằng phương pháp xem xét những yêu mong hoặc SRS, được gửi ra vì chưng khách hàng.

Xác định tất cả các tình huống:

Khi thành phầm được tung ra, người tiêu dùng cuối hoàn toàn có thể sử dụng phần mềm theo những phương pháp nào để xác định tất cả các cách bao gồm thể.tôi đã đánh dấu tất cả những tình huống rất có thể xảy ra vào một tài liệu, được hotline là xây dựng thử nghiệm / thiết kế cấp cao.Thiết kế xem sét là một bạn dạng ghi có tất cả các tình huống hoàn toàn có thể xảy ra.

Viết các Test Case

Chuyển đổi tất cả các kịch phiên bản đã xác minh để kiểm soát các chứng thực quyền mua và nhóm những kịch bản liên quan liêu đến những tính năng của chúng, ưu tiên mô-đun và viết những Test Case bằng phương pháp áp dụng các kỹ thuật kiến tạo Test Case và sử dụng mẫu demo Case tiêu chuẩn, tức là mẫu được ra quyết định cho dự án công trình .

Xem lại những Test Case

Xem xét thử nghiệm Case bằng cách đưa nó cho trưởng nhóm với sau đó, sửa chữa các bội nghịch hồi đánh giá do người đánh giá đưa ra.

Phê duyệt demo Case

Sau lúc sửa test Case dựa vào phản hồi, hãy gởi lại nhằm phê duyệt.

Xem thêm: Spontaneously Là Gì Trong Tiếng Việt? Spontaneously Là Gì, Nghĩa Của Từ Spontaneously

Lưu trữ vào kho tàng trữ Test Case

Sau khi phê duyệt kiểm tra Case chũm thể, hãy tàng trữ ở nơi thân thuộc được điện thoại tư vấn là kho tàng trữ Test Case.