Cách viết test case

     
Phân tích yêu ước phần mềm

Để mang về một sản phẩm phần mềm chất lượng an toàn thì vấn đề phân tích yêu cầu là khâu vô cùng đặc biệt quan trọng trong quá trình xây dựng phần mềm. Vận động này đòi hỏi sự phối hợp rất chặt chẽ giữa người sử dụng và người phân tích nhằm vạch ra được xem họ phải cải tiến và phát triển cái gì.

Bạn đang xem: Cách viết test case

Yêu ước của ứng dụng là tất cả các yêu mong về phần mềm do người tiêu dùng nêu ra bao gồm các công dụng của phần mềm, hiệu năng của phần mềm, đồ họa của phần mềm và một số các yêu ước khác.

Thông thường các yêu cầu phần mềm được phân loại dựa vào 4 yếu tắc của ứng dụng như sau:

Các yêu cầu về phần mềmCác yêu ước về phần cứngCác yêu ước về dữ liệuCác yêu cầu về con người

Mục tiêu đặc biệt nhất đối với chất lượng phần mềm là phần mềm phải thỏa mãn nhu cầu được những yêu mong và mong ước của bạn dùng.

Người dùng thường chỉ gửi ra đầy đủ ý tưởng, đôi lúc rất mơ hồ về phần mềm mà họ mong ý muốn xây dựng. Với việc của các kỹ sư phạt triển phần mềm đó là đề xuất giúp họ chuyển những phát minh mơ hồ đó thành hiện thực và tạo được 1 phần mềm có tương đối đầy đủ các tính năng quan trọng thỏa mãn yêu cầu của tín đồ dùng.Hơn cầm cố nữa, ý tưởng của người tiêu dùng thường xuyên biến đổi và việc của nhà phát triển là phải nắm bắt và đáp ứng được những yêu cầu chuyển đổi đó một biện pháp hợp lý.

Đọc và cố gắng hiểu mục tiêu của vận dụng đang ước muốn là gì?Vừa đọc cùng hình dung, tưởng tượng xem phần mềm /màn hình này sẽ chạy như vậy nào.Thẩm định từng yêu thương cầu ứng dụng để xác định xem chúng có công dụng thực hiện được xuất xắc không.Xác định các rủi ro rất có thể xảy ra cùng với từng yêu cầu cố kỉnh thể.Thảo luận với tía về đông đảo băn khoăn, vướng mắc, bất vừa lòng lý, chưa rõ ràng trong tài liệu đặc tả yêu thương cầuViết Q và A gửi đến Khách HàngHướng dẫn viết TESTCASES

Testcase là gì?

Quá trình cải tiến và phát triển test case rất có thể giúp tìm ra lỗi trong những yêu ước hoặc xây dựng của ứng dụng, vì nó yên cầu phải bốn duy hoàn toàn thông qua các hoạt động vui chơi của ứng dụng. Vì nguyên nhân này, việc sẵn sàng test case nhanh chóng nhất hoàn toàn có thể trong qui trình phát triển phần mềm là khôn cùng hữu íchCác trường hợp kiểm demo phải che phủ được tổng thể luồng xử lý tính năng mô tả trong tài liệu phân tích và thiết kế; các yêu mong về bảo mật an ninh thông tin, yêu mong hiệu năng của hệ thống.
*

Mục đích kiểm thử ( diễn đạt testcase-Testcase description ): + diễn tả của test case là phần các bạn sẽ đề cập một cách chi tiết những gì mà các bạn sẽ test và bí quyết xử lý lẻ tẻ được kiểm tra bởi test.

Xem thêm: Bài 4 Trang 10 Sgk Giải Bài Tập 4 Toán 12 Trang 10 Sgk Giải Tích 12

“Miêu tả” của một demo case đề nghị đưa ra được “Mình đang test hầu như gì”? (Ví dụ: chạy thử nhập vượt max length mang lại username)Các bước triển khai / Testcase Procedure:Dữ liệu nguồn vào của test: định nhập đồ vật gi để ra được tác dụng mong muốnViệc xác định dữ liệu nguồn vào của chạy thử thực sự là hoạt động tốn nhiều thời gian.Dữ liệu test đó là phần Input dữ liệu đầu vào, để hệ thống xử lý và trả ra tác dụng mong đợiMột test case được viết giỏi cần phải đề cập một biện pháp rõ ràng tác dụng mong ngóng của ứng dụng hoặc hệ thống.Mỗi bước kiến tạo test nên chỉ có thể ra rõ ràng những gì bạn ý muốn đợiPhần mềm sẽ đề xuất chạy đúng như công dụng mong đợi, nếu ko như là thì vẫn là Lỗi ( bug/ defect) và kiểm tra case sẽ là Fail

Cột công dụng test/Test result:Thông thường vẫn là pass, fail, với pending. Đây là công dụng thực tế khi triển khai test theo demo case trên môi trường của hệ thống

Xác định trường hợp kiểm tra.Với 1 giá chỉ trị yêu cầu kiểm tra luôn luôn bao gồm 3 trường thích hợp lớn cần kiểm tra rất có thể xảy ra.Normal case: những trường đúng theo kiểm thử thông thườngAbnormal case: những trường vừa lòng kiểm test bất bình thườngBoundary case: các trường hợp kiểm soát boundary ( phân tích cực hiếm biên).

*
Đối cùng với testcase chức năng:

Các bước thực hiện chỉ mô tả công việc thực hiện tại đứng trường đoản cú phía người dùng cuối bao hàm nhập dữ liệu, dìm button.Việc kiểm tra tài liệu trong DB so với hiện thị lên trên màn hình nằm ở hiệu quả mong muốn. Thường được dùng cho những trường hợp kiểm thử đánh giá lưu, cập nhật, xóa DB SELECT * FROM … WHERE…Ví dụ: tạo thành 1 email đk thành công :Test sản xuất 1 email đk thành công. Đã singin thành vô tư email bắt đầu trên giao diệnVào DB kiểm tra xem e-mail đó đã có được lưu vào DB hay không? ( mặc dù nhiều nơi ko yêu ước tester vào database để check)

Ví dụ : tiến hành viết TCs cho tính năng đăng nhập facebook

*
Xác định yêu cầu: size login bao gồm: 2 text box email/điện thoại với mật khẩu, 1 button đăng nhập, 1 link quên mật khẩu.

Xây dựng TCs:

Xác định các case UI: bao hàm UI chung của tất cả form: color sắc, font, size, màu sắc của label, chiều dài, rộng, cao, loại của các textbox, button, địa điểm của form, textbox, button, links trên trangXác định case kiểm tra chức năng: Ở đây tác dụng là đăng nhập có 2 text box email/điện thoại và mật khẩu, 1 button đăng nhập, 1 link quên mật khẩu. đến nên sẽ có được những case như sau.

Đối cùng với email/ điện thoại cảm ứng textbox:

Normal case đã gồm: đăng nhập với đúng sdt, showroom email đã đk với hệ thống facebook trước đó với đăng nhập cùng với blank, không nên sdt, add email đã đk với hệ thống facebook trước đó.Abnormal case đang gồm: Đăng nhập với số điện thoại mà thêm mã vùng, mã nước vào trước đó (ví dụ: +849....) hoặc thư điện tử mà ko nhập
mang lại nó. Ngoại trừ ra, còn có các cases: offline mode ( ko tất cả internet), đang đăng nhập mà có điện thoại thông minh gọi đến nếu là mobile…Boundary case đang gồm: Text số lương ký kết tự về tối thiểu và tối đa nhưng ô text đến nhập. Rất có thể tạo ra 1 email với tương đối nhiều ký tự để test, hoặc 1 e-mail ngắn nhất có thể để test.( với trường hòa hợp này tôi ko đánh giá tính chính xác của follow đăng nhập nhưng mà chỉ kiểm tra kĩ năng cho nhập buổi tối thiểu và tối đa của ô text.)

Tương từ với ô mật khẩu:

Tương trường đoản cú với ô mật khẩu: nhưng cung ứng nữa nghỉ ngơi ô mật khẩu cần kiểm tra thêm tính mã hóa password nữa.Đối cùng với button đăng nhập:Normal case vẫn gồm: Nhập quý giá vào text, click button đăng nhập, bấm phím enter trường đoản cú bàn phím.Abnormal case đang gồm: Click liên tiếp or enter liên tiếp vào buttonBoundary case vẫn gồm: ko cần kiểm tra trường phù hợp này

Lưu ý lúc viết testcases:

File testcase cần có những step test 1-1 giản, minh bạch, dễ dàng hiểu:Step test đề xuất viết cụ thể rõ ràng để ngay cả khi tester không giống đọc rất có thể thực hiện tại đượcMục đích cùng phạm vi của testcase cũng khá được mô tả chi tiết.Điều kiện tiền đề, data test cũng đề nghị được ghi sinh hoạt từng testcase giả dụ cần.Testcase đề nghị được review chéo bởi thành viên trong team.Không phải gộp quá nhiều công dụng confirm vào 1 case mà nên bóc mỗi kết quả confirm ra từng case.Khi chế tạo testcase yêu cầu đứng ở vị trí End user.Testcase phải cover các trường đúng theo kiểm thử như: Phân lớp tương đương, giá trị biên, điều kiện normal cùng abnormal. Cả các trường hợp free test không có trong sệt tả yêu cầu.

Xem thêm: Bài Soạn Văn Lớp 9 Miêu Tả Trong Văn Tự Sự Ngắn Nhất, Soạn Bài Miêu Tả Trong Văn Tự Sự

Mục đích tạo thành testcase:

Mục tiêu cơ bản của bài toán tạo tescase là để chứng thực độ bao phủ kiểm demo của ứng dụng, là bởi chứng đặc trưng để xác nhận phần mềm gồm đủ tiêu chuẩn chỉnh để triển khai hay không?Testcase được tạo là 1 trong những tài liệu thừa nhận bắt buộc của dự án công trình để kiểm soát chất lượng phần mềm.Tái áp dụng khi cố kỉnh đổi, upgrade hệ thốngTestcase hiệu quảTestcase tốt/hiệu quả là testcase có công dụng tìm ra lỗi cao.

Một testcase hiệu quả cần phải có các điểm sáng sau:

Chính xác, rất đầy đủ nghiệp vụ hệ thốngĐộc lập (có thể tiến hành mà không nhờ vào vào các testcase khác, tiện lợi chia cho đa số người cùng kiểm thử)Nội dung solo giản, bao gồm mục đích ví dụ và ai đọc cũng đọc theo một giải pháp duy nhất. (đầu vào, đầu ra, công việc thực biểu hiện rõ ràng)Trình bày mạch lạc thống độc nhất cho toàn thể tài liệu.Có kỹ năng tái sử dụng (có thể dễ dàng cập nhật và sửa đổi)