Test Case được định nghĩa là một nhóm các điều kiện mà theo đó người kiểm thử xác định liệu một ứng dụng phần mềm có hoạt động theo yêu cầu của khách hàng hay không. Thiết kế Test Case bao gồm các điều kiện tiên quyết, tên trường hợp, điều kiện đầu vào và kết quả mong đợi. Một Test Case là một hành động cấp độ đầu tiên và bắt nguồn từ các kịch bản thử nghiệm.
Đây là một tài liệu chi tiết chứa tất cả các đầu vào có thể có (tích cực cũng như tiêu cực) và các bước điều hướng, được sử dụng cho quá trình thực hiện kiểm tra. Việc viết các Test Case là một 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.
Các bài viết liên quan:
Test Case cung cấp thông tin chi tiết về chiến lược thử nghiệm, quy trình thử nghiệm, các điều kiện tiên quyết và đầu ra dự kiến. Chúng được thực hiện trong quá trình thử nghiệm để kiểm tra xem ứng dụng phần mềm có đang thực hiện nhiệm vụ mà nó đã được phát triển hay không.
Test Case giúp người kiểm tra báo cáo lỗi bằng cách liên kết lỗi với ID Test Case. Tài liệu Test Case chi tiết hoạt động như một biện pháp bảo vệ bằng chứng đầy đủ cho nhóm thử nghiệm vì nếu nhà phát triển bỏ sót điều gì đó, thì nó có thể bị bắt trong quá trình thực hiện các Test Case đầy đủ này.
Để viết Test Case, chúng ta phải có các yêu cầu để lấy các đầu vào và các kịch bản thử nghiệm phải được viết sao cho chúng ta không bỏ sót bất kỳ tính năng nào để thử nghiệm. Sau đó, chúng ta nên có mẫu Test Case để duy trì tính đồng nhất hoặc mọi kỹ sư thử nghiệm theo cùng một cách tiếp cận để chuẩn bị tài liệu thử nghiệm.
Nói chung, chúng tôi sẽ viết Test Case bất cứ khi nào nhà phát triển bận viết mã.
Khi nào chúng ta viết một Test Case?
Chúng tôi sẽ viết Test Case khi chúng tôi nhận được những điều sau:
- Sau đó, khi khách hàng đưa ra nhu cầu của doanh nghiệp, nhà phát triển bắt đầu phát triển và nói rằng họ cần 3,5 tháng để xây dựng sản phẩm này.
- Và trong khi chờ đợi, nhóm kiểm thử sẽ bắt đầu viết các Test Case.
- Sau khi hoàn thành, nó sẽ gửi đến Trưởng nhóm kiểm tra để tiến hành xem xét.
- Và khi các nhà phát triển hoàn thành việc phát triển sản phẩm, nó sẽ được giao cho nhóm kiểm thử.
- Các kỹ sư kiểm tra không bao giờ nhìn vào yêu cầu trong khi kiểm tra tài liệu sản phẩm bởi vì kiểm tra là liên tục và không phụ thuộc vào tâm trạng của người đó hơn là chất lượng của kỹ sư kiểm tra.
Lưu ý: Khi viết Test Case, không bao giờ nên viết kết quả thực tế vì sản phẩm vẫn đang trong quá trình phát triển. Đó là lý do tại sao kết quả thực tế chỉ nên được ghi sau khi thực hiện các Test Case.
Tại sao chúng tôi viết các Test Case?
Chúng tôi sẽ viết bài kiểm tra vì những lý do sau:
- Để yêu cầu tính nhất quán trong việc thực thi Test Case
- Để đảm bảo phạm vi kiểm tra tốt hơn
- Nó phụ thuộc vào quá trình hơn là vào một người
- Để tránh đào tạo cho mọi kỹ sư thử nghiệm mới về sản phẩm
Để yêu cầu tính nhất quán trong việc thực thi Test Case: chúng tôi sẽ xem Test Case và bắt đầu thử nghiệm ứng dụng.
Để đảm bảo phạm vi kiểm tra tốt hơn: đối với điều này, chúng ta nên bao gồm tất cả các tình huống có thể xảy ra và ghi lại nó, để chúng ta không cần phải nhớ lại tất cả các tình huống.
Nó phụ thuộc vào quy trình hơn là vào con người: Một kỹ sư thử nghiệm đã thử nghiệm một ứng dụng trong lần phát hành đầu tiên, lần phát hành thứ hai và rời công ty vào thời điểm phát hành lần thứ ba. Khi kỹ sư thử nghiệm hiểu một mô-đun và thử nghiệm ứng dụng kỹ lưỡng bằng cách lấy ra nhiều giá trị. Nếu người đó không ở đó trong lần phát hành thứ ba, thì điều đó sẽ trở nên khó khăn đối với người mới. Do đó, tất cả các giá trị dẫn xuất được ghi lại để nó có thể được sử dụng trong tương lai.
Xem thêm Test Maturity Model ? tại sao cần Test Maturity Model
Để tránh đào tạo cho mọi kỹ sư thử nghiệm mới về sản phẩm: Khi kỹ sư thử nghiệm rời đi, anh ta / cô ta rời đi với rất nhiều kiến thức và kịch bản. Các kịch bản đó nên được ghi lại để kỹ sư kiểm thử mới có thể kiểm tra với các tình huống đã cho và cũng có thể viết các kịch bản mới.
Lưu ý: khi các nhà phát triển đang phát triển sản phẩm đầu tiên cho Bản phát hành đầu tiên, kỹ sư thử nghiệm sẽ viết các Test Case. Và trong bản phát hành thứ hai, khi các tính năng mới được thêm vào, kỹ sư thử nghiệm cũng viết các Test Case cho điều đó và trong bản phát hành tiếp theo, khi các phần tử được sửa đổi, kỹ sư thử nghiệm sẽ thay đổi các Test Case hoặc viết các Test Case mới. cũng.
Test case template
Mục đích chính của việc viết một Test Case là để đạt được hiệu quả của ứng dụng.
Như chúng ta đã biết, kết quả thực tế được ghi sau khi thực thi Test Case và hầu hết thời gian, nó sẽ giống như kết quả mong đợi. Nhưng nếu đến bước kiểm tra sẽ bị lỗi thì lại khác. Vì vậy, trường kết quả thực tế có thể được bỏ qua và trong phần Nhận xét, chúng ta có thể viết về các lỗi.
Ngoài ra, trường Đầu vào có thể bị xóa và thông tin này có thể được thêm vào trường Mô tả.
Mẫu trên mà chúng ta thảo luận ở trên không phải là mẫu tiêu chuẩn vì nó 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 trên kỹ sư kiểm tra và trưởng nhóm kiểm tra. Tuy nhiên, để 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 thông thường, được xây dựng theo công thức.
Test Case nên được viết bằng ngôn ngữ đơn giản để một kỹ sư thử nghiệm mới cũng có thể hiểu và thực thi tương tự.
Trong mẫu mẫu ở trên, tiêu đề chứa những nội dung sau:
Step number
Nó cũng rất cần thiết vì nếu bước số 20 không thành công, chúng tôi có thể ghi lại báo cáo lỗi và do đó ưu tiên làm việc và cũng quyết định xem đó có phải là lỗi nghiêm trọng hay không.
Test case type
Nó có thể là các Test Case chức năng, tích hợp hoặc hệ thống hoặc các Test Case tích cực hoặc tiêu cực hoặc tích cực và tiêu cực.
Release
Một bản phát hành có thể chứa nhiều phiên bản của bản phát hành.
Pre-condition
Đây là những điều kiện cần thiết mà mọi kỹ sư kiểm thử cần phải thỏa mãn trước khi bắt đầu quá trình thực hiện kiểm thử. Hoặc đó là cấu hình dữ liệu hoặc thiết lập dữ liệu cần được tạo để thử nghiệm.
Ví dụ: Trong một ứng dụng, chúng tôi đang viết các Test Case để thêm người dùng, chỉnh sửa người dùng và xóa người dùng. Điều kiện cho mỗi điều kiện sẽ được 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à chúng ta cần tạo 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 nhóm kiểm tra có thể được cung cấp dữ liệu kiểm tra như tên người 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 tên người dùng và mật khẩu.
Severity
Mức độ nghiêm trọng có thể là lớn, nhỏ và quan trọng, mức độ nghiêm trọng trong Test Case nói về tầm quan trọng của các Test Case cụ thể đó. Tất cả quá trình thực thi văn bản luôn phụ thuộc vào mức độ nghiêm trọng của các Test Case.
Chúng tôi có thể chọn mức độ nghiêm trọng dựa trên mô-đun. Có nhiều tính năng bao gồm trong một mô-đun, ngay cả khi một phần tử là quan trọng, chúng tôi khẳng định rằng Test Case là quan trọng. Nó phụ thuộc vào các chức năng mà chúng ta đang viết test case.
Ví dụ: chúng tôi sẽ sử dụng ứng dụng Gmail và cho chúng tôi xem mức độ nghiêm trọng dựa trên các mô-đun:
Kỹ sư thử nghiệm đã viết một Test Case cho một tính năng cụ thể. Nếu anh ấy / cô ấy đến và đọc các Test Case ngay lúc này, anh ấy / cô ấy sẽ không biết tính năng nào đã viết nó. Vì vậy, mô tả ngắn gọn sẽ giúp họ viết Test Case tính năng nào.
Ví dụ về mẫu Test Case
Ở đây, chúng tôi đang viết một Test Case cho mô-đun Đăng nhập của ứng dụng ICICI:
Các loại Test Case
Chúng tôi có một loại Test Case khác, như sau:
- Function test cases
- Integration test cases
- System test cases
Function test cases
Đầu tiên, chúng tôi kiểm tra lĩnh vực nào chúng tôi sẽ viết các Test Case và sau đó mô tả cho phù hợp.
Trong thử nghiệm chức năng hoặc nếu ứng dụng theo hướng dữ liệu, chúng tôi yêu cầu cột đầu vào khác; nó hơi tốn thời gian.
Quy tắc viết các Test Case chức năng:
- Trong cột kết quả mong đợi, cố gắng 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 bước mà chúng tôi yêu cầu nhất; nếu không, chúng ta không cần xác định tất cả các bước.
- Để giảm thời gian thực hiện dư thừa, chúng tôi sẽ viết các bước một cách chính xác.
- Viết một Test Case chung; đừng cố gắng mã hóa nó.
Giả sử nó là mô-đun chuyển số tiền, vì vậy chúng tôi đang viết các trường hợp kiểm tra chức năng cho nó và sau đó cũng chỉ định rằng nó không phải là một tính năng đăng nhập.
Trường hợp kiểm tra chức năng cho mô-đun chuyển số tiền nằm trong tệp Excel bên dưới:
Integration test cases
Trong điều này, chúng ta không nên viết một cái gì đó mà chúng ta đã đề cập trong các Test Case chức năng và một cái gì đó chúng ta đã viết trong Test Case tích hợp không nên viết lại trong Test Case hệ thống.
Quy tắc viết các Test Case tích hợp
- Thứ nhất, hiểu sản phẩm
- Xác định các tình huống có thể xảy ra
- Viết Test Case dựa trên mức độ ưu tiên
Khi kỹ sư kiểm thử viết các Test Case, họ có thể cần xem xét các khía cạnh sau:
Nếu các trường hợp kiểm tra là chi tiết:
- Họ sẽ cố gắng đạt được độ bao phủ thử nghiệm tối đa.
- Tất cả các giá trị hoặc kịch bản test case đều được mô tả chính xác.
- Họ sẽ cố gắng suy nghĩ về quan điểm thực hiện.
- Mẫu được sử dụng để viết Test Case phải là duy nhất.
Lưu ý: khi chúng ta liên quan đến số lượng bước ít hơn hoặc phạm vi bảo hiểm nhiều hơn, nó phải là Test Case tốt nhất 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 các test case hệ thống cho các luồng kinh doanh.
Quy trình viết các Test Case
Phương pháp viết một Test Case có thể được hoàn thành theo các bước sau:
Nghiên cứu hệ thống
Trong đó, chúng tôi sẽ hiểu ứng dụng bằng cách xem xét các yêu cầu hoặc SRS, được đưa ra bởi khách hàng.
Xác định tất cả các tình huống:
- Khi sản phẩm được tung ra, người dùng cuối có thể sử dụng phần mềm theo những cách nào để xác định tất cả các cách có thể.
- tôi đã ghi lại tất cả các tình huống có thể xảy ra trong một tài liệu, được gọi là thiết kế thử nghiệm / thiết kế cấp cao.
- Thiết kế thử nghiệm là một bản ghi có tất cả các tình huống có thể xảy ra.
Viết các Test Case
Chuyển đổi tất cả các kịch bản đã xác định để kiểm tra các xác nhận quyền sở hữu và nhóm các kịch bản liên quan đến các tính năng của chúng, ưu tiên mô-đun và viết các Test Case bằng cách áp dụng các kỹ thuật thiết kế Test Case và sử dụng mẫu Test Case tiêu chuẩn, có nghĩa là mẫu được quyết định cho dự án .
Xem lại các Test Case
Xem xét Test Case bằng cách đưa nó cho trưởng nhóm và sau đó, sửa chữa các phản hồi đánh giá do người đánh giá đưa ra.
Phê duyệt Test Case
Sau khi sửa Test Case dựa trên phản hồi, hãy gửi lại để phê duyệt.
Lưu trữ trong kho lưu trữ Test Case
Sau khi phê duyệt Test Case cụ thể, hãy lưu trữ ở nơi quen thuộc được gọi là kho lưu trữ Test Case.
