Sự khác biệt giữa kiểm tra đơn vị và kiểm tra chức năng là gì? Một bài kiểm tra đơn vị cũng có thể kiểm tra một chức năng?
Câu trả lời:
Kiểm thử đơn vị - kiểm tra một đơn vị riêng lẻ, chẳng hạn như một phương thức (hàm) trong một lớp, với tất cả các phụ thuộc được mô phỏng.
Kiểm tra chức năng - Kiểm tra tích hợp AKA, kiểm tra một lát chức năng trong hệ thống. Điều này sẽ kiểm tra nhiều phương thức và có thể tương tác với các phụ thuộc như Cơ sở dữ liệu hoặc Dịch vụ web.
Các bài kiểm tra đơn vị cho nhà phát triển biết rằng mã đang làm đúng; kiểm tra chức năng nói với một nhà phát triển rằng mã đang làm đúng .
Bạn có thể đọc thêm tại Kiểm tra đơn vị so với Kiểm tra chức năng
Một sự tương tự trong cuộc sống thực của giải pháp đơn vị và kiểm tra chức năng có thể được mô tả như sau,
Nhiều lần sự phát triển của một hệ thống được ví như việc xây dựng một ngôi nhà. Mặc dù sự tương tự này không hoàn toàn chính xác, chúng ta có thể mở rộng nó nhằm mục đích tìm hiểu sự khác biệt giữa các bài kiểm tra đơn vị và chức năng.
Kiểm tra đơn vị tương tự như một thanh tra xây dựng đến thăm công trường xây dựng của một ngôi nhà. Ông tập trung vào các hệ thống nội bộ khác nhau của ngôi nhà, nền tảng, khung, điện, hệ thống ống nước, v.v. Ông đảm bảo (kiểm tra) rằng các bộ phận của ngôi nhà sẽ hoạt động chính xác và an toàn, nghĩa là đáp ứng mã xây dựng.
Các thử nghiệm chức năng trong kịch bản này tương tự như chủ nhà đến thăm cùng công trường xây dựng này. Ông cho rằng các hệ thống nội bộ sẽ hành xử phù hợp, rằng thanh tra tòa nhà đang thực hiện nhiệm vụ của mình. Chủ nhà tập trung vào những gì nó sẽ được sống trong ngôi nhà này. Anh ấy quan tâm đến diện mạo của ngôi nhà, các phòng khác nhau có kích thước thoải mái, ngôi nhà có phù hợp với nhu cầu của gia đình không, là cửa sổ ở một vị trí tốt để đón ánh nắng mặt trời buổi sáng.
Chủ nhà đang thực hiện các bài kiểm tra chức năng trên ngôi nhà. Anh ấy có quan điểm của người dùng.
Thanh tra tòa nhà đang thực hiện các bài kiểm tra đơn vị trên ngôi nhà. Ông có quan điểm của người xây dựng.
Như một bản tóm tắt,
Bài kiểm tra đơn vị được viết từ góc độ lập trình viên . Chúng được tạo ra để đảm bảo rằng một phương thức cụ thể (hoặc một đơn vị ) của một lớp thực hiện một tập hợp các nhiệm vụ cụ thể.
Kiểm tra chức năng được viết từ quan điểm của người dùng . Họ đảm bảo rằng hệ thống đang hoạt động như người dùng đang mong đợi.
Một bài kiểm tra đơn vị kiểm tra một đơn vị hành vi độc lập . Một đơn vị hành vi là gì? Đây là phần nhỏ nhất của hệ thống có thể được kiểm tra đơn vị độc lập. (Định nghĩa này thực sự là hình tròn, IOW nó thực sự không phải là một định nghĩa nào cả , nhưng nó dường như làm việc khá tốt trong thực tế, bởi vì bạn có thể sắp xếp của hiểu nó bằng trực giác.)
Một bài kiểm tra chức năng kiểm tra một phần độc lập của chức năng.
Một đơn vị hành vi rất nhỏ: trong khi tôi hoàn toàn không thích câu thần chú "một bài kiểm tra đơn vị cho mỗi phương pháp" ngu ngốc này, từ góc độ kích thước thì nó đúng. Một đơn vị hành vi là một cái gì đó giữa một phần của một phương thức và có thể là một vài phương thức. Nhiều nhất là một đối tượng, nhưng không nhiều hơn một.
Một phần chức năng thường bao gồm nhiều phương thức và cắt ngang qua một số đối tượng và thường thông qua nhiều lớp kiến trúc.
Một bài kiểm tra đơn vị sẽ giống như: khi tôi gọi validate_country_code()hàm và truyền cho nó mã quốc gia 'ZZ'thì nó sẽ trả về false.
Một thử nghiệm chức năng sẽ là: khi tôi điền vào biểu mẫu giao hàng với mã quốc gia ZZ, tôi sẽ được chuyển hướng đến một trang trợ giúp cho phép tôi chọn mã quốc gia của mình ra khỏi menu.
Các bài kiểm tra đơn vị được viết bởi các nhà phát triển, cho các nhà phát triển, từ quan điểm của nhà phát triển.
Các thử nghiệm chức năng có thể phải đối mặt với người dùng, trong trường hợp đó, chúng được viết bởi các nhà phát triển cùng với người dùng (hoặc có thể với các công cụ phù hợp và đúng người dùng ngay cả bởi chính người dùng), từ quan điểm của người dùng. Hoặc họ có thể là nhà phát triển phải đối mặt (ví dụ: khi họ mô tả một số chức năng nội bộ mà người dùng không quan tâm), trong trường hợp đó, họ được viết bởi nhà phát triển, cho nhà phát triển, nhưng vẫn theo quan điểm của người dùng.
Trong trường hợp trước, các kiểm tra chức năng cũng có thể đóng vai trò kiểm tra chấp nhận và dưới dạng mã hóa thực thi các yêu cầu chức năng hoặc đặc tả chức năng, trong trường hợp sau, chúng cũng có thể đóng vai trò kiểm tra tích hợp.
Kiểm tra đơn vị thay đổi thường xuyên, kiểm tra chức năng không bao giờ nên thay đổi trong một bản phát hành chính.
TLDR:
Để trả lời câu hỏi: Kiểm thử đơn vị là một kiểu con của Kiểm tra chức năng.
Có hai nhóm lớn: Kiểm tra chức năng và phi chức năng . Hình minh họa tốt nhất (không đầy đủ) mà tôi tìm thấy là bức này (nguồn: www.inflectra.com ):
(1) Kiểm thử đơn vị: kiểm tra các đoạn mã nhỏ (hàm / phương thức). Nó có thể được coi là thử nghiệm chức năng (hộp trắng).
Khi các chức năng được đặt cùng nhau, bạn tạo một mô-đun = một phần độc lập, có thể bằng Giao diện người dùng có thể được kiểm tra (Kiểm tra mô-đun). Khi bạn có ít nhất hai mô-đun riêng biệt, sau đó bạn dán chúng lại với nhau và sau đó đến:
(2) Kiểm tra tích hợp: khi bạn đặt hai hoặc nhiều phần của mô-đun (phụ) hoặc hệ thống (phụ) lại với nhau và xem liệu chúng có chơi tốt với nhau không.
Sau đó, bạn tích hợp mô-đun thứ 3, rồi thứ 4 và thứ 5 theo bất kỳ thứ tự nào mà bạn hoặc nhóm của bạn thấy phù hợp và một khi tất cả các mảnh ghép được đặt cùng nhau, sẽ xuất hiện
(3) Kiểm tra hệ thống: kiểm tra toàn bộ SW. Đây là khá nhiều "Kiểm tra tích hợp của tất cả các phần với nhau".
Nếu điều đó ổn, thì hãy đến
(4) Kiểm tra chấp nhận: chúng tôi đã xây dựng những gì khách hàng yêu cầu thực sự chưa? Tất nhiên, Kiểm tra chấp nhận nên được thực hiện trong suốt vòng đời , không chỉ ở giai đoạn cuối, nơi bạn nhận ra rằng khách hàng muốn một chiếc xe thể thao và bạn đã chế tạo một chiếc xe tải.
Functional Testkhông phải là một thuật ngữ được tiêu chuẩn hóa và có ý nghĩa khác nhau đối với những người khác nhau.
"Kiểm tra chức năng" không có nghĩa là bạn đang kiểm tra một chức năng (phương thức) trong mã của mình. Điều đó có nghĩa là, nói chung, bạn đang kiểm tra chức năng hệ thống - khi tôi chạy foo file.txtở dòng lệnh file.txt, có lẽ các dòng trong đó bị đảo ngược. Ngược lại, một thử nghiệm đơn vị thường bao gồm một trường hợp duy nhất của một phương thức - length("hello")nên trả về 5 và length("hi")sẽ trả về 2.
Xem thêm IBM đảm nhận ranh giới giữa thử nghiệm đơn vị và thử nghiệm chức năng .
Tuy nhiên, điểm khác biệt cơ bản là các thử nghiệm chức năng kiểm tra ứng dụng từ bên ngoài, từ quan điểm của người dùng. Kiểm thử đơn vị kiểm tra ứng dụng từ bên trong, từ quan điểm của lập trình viên. Kiểm tra chức năng sẽ giúp bạn xây dựng một ứng dụng có chức năng phù hợp và đảm bảo bạn không bao giờ vô tình phá vỡ nó. Các bài kiểm tra đơn vị sẽ giúp bạn viết mã sạch và không có lỗi.
Lấy từ cuốn sách "Python TDD" của Harry Percival
Theo ISTQB hai cái đó không thể so sánh được. Kiểm thử chức năng không phải là kiểm thử tích hợp.
Kiểm thử đơn vị là một trong các cấp độ kiểm tra và kiểm tra chức năng là loại kiểm tra.
Về cơ bản:
Chức năng của một hệ thống (hoặc thành phần) là 'những gì nó làm'. Điều này thường được mô tả trong một đặc tả yêu cầu, đặc tả chức năng hoặc trong các trường hợp sử dụng.
trong khi
Kiểm tra thành phần, còn được gọi là kiểm tra đơn vị, mô-đun và chương trình, tìm kiếm các khiếm khuyết và xác minh chức năng của phần mềm (ví dụ: mô-đun, chương trình, đối tượng, lớp, v.v.) có thể kiểm tra riêng.
Theo thử nghiệm thành phần / đơn vị ISTQB có thể là chức năng hoặc không hoạt động:
Kiểm tra thành phần có thể bao gồm kiểm tra chức năng và các đặc điểm phi chức năng cụ thể như hành vi tài nguyên (ví dụ rò rỉ bộ nhớ), kiểm tra hiệu năng hoặc độ bền, cũng như kiểm tra cấu trúc (ví dụ: bảo hiểm quyết định).
Báo giá từ Cơ sở kiểm thử phần mềm - Chứng nhận ISTQB
Trong Rails, thư mục đơn vị có nghĩa là giữ các bài kiểm tra cho các mô hình của bạn, thư mục chức năng có nghĩa là giữ các bài kiểm tra cho bộ điều khiển của bạn và thư mục tích hợp có nghĩa là giữ các bài kiểm tra liên quan đến bất kỳ số lượng bộ điều khiển nào tương tác. Lịch thi đấu là một cách tổ chức dữ liệu thử nghiệm; họ cư trú trong thư mục đồ đạc. Tệp test_helper.rb giữ cấu hình mặc định cho các thử nghiệm của bạn. bạn có thể truy cập này .
Cách tôi nghĩ về nó là như thế này: Một bài kiểm tra đơn vị xác định rằng mã thực hiện những gì bạn dự định làm mã (ví dụ: bạn muốn thêm tham số a và b, thực tế bạn thêm chúng và không trừ chúng), kiểm tra chức năng kiểm tra rằng tất cả các mã làm việc cùng nhau để có được kết quả chính xác, do đó, những gì bạn dự định mã thực hiện sẽ có kết quả đúng trong hệ thống.
AFAIK, kiểm tra đơn vị KHÔNG phải là kiểm tra chức năng. Hãy để tôi giải thích với một ví dụ nhỏ. Bạn muốn kiểm tra xem chức năng đăng nhập của ứng dụng web email có hoạt động hay không, giống như người dùng sẽ làm. Đối với điều đó, các bài kiểm tra chức năng của bạn nên như thế này.
1- existing email, wrong password -> login page should show error "wrong password"!
2- non-existing email, any password -> login page should show error "no such email".
3- existing email, right password -> user should be taken to his inbox page.
4- no @symbol in email, right password -> login page should say "errors in form, please fix them!"
Các kiểm tra chức năng của chúng tôi có nên kiểm tra xem chúng tôi có thể đăng nhập với đầu vào không hợp lệ không? Ví dụ. Email không có ký hiệu @, tên người dùng có nhiều hơn một dấu chấm (chỉ cho phép một dấu chấm), .com xuất hiện trước @ vv? Nói chung là không! Đó là loại thử nghiệm đi vào kiểm tra đơn vị của bạn.
Bạn có thể kiểm tra xem đầu vào không hợp lệ có bị từ chối bên trong các thử nghiệm đơn vị như trong các thử nghiệm bên dưới không.
class LoginInputsValidator
method validate_inputs_values(email, password)
1-If email is not like string.string@myapp.com, then throw error.
2-If email contains abusive words, then throw error.
3-If password is less than 10 chars, throw error.
Lưu ý rằng kiểm tra chức năng 4 thực sự đang làm những gì đơn vị kiểm tra 1 đang làm. Đôi khi, các kiểm tra chức năng có thể lặp lại một số (không phải tất cả) các thử nghiệm được thực hiện bằng các thử nghiệm đơn vị, vì những lý do khác nhau. Trong ví dụ của chúng tôi, chúng tôi sử dụng kiểm tra chức năng 4 để kiểm tra xem một thông báo lỗi cụ thể có xuất hiện khi nhập dữ liệu không hợp lệ hay không. Chúng tôi không muốn kiểm tra xem tất cả các đầu vào xấu có bị từ chối hay không. Đó là công việc của các bài kiểm tra đơn vị.
KIỂM TRA ĐƠN VỊ
Kiểm thử đơn vị bao gồm kiểm tra đơn vị mã nhỏ nhất thường là các hàm hoặc phương thức. Kiểm thử đơn vị chủ yếu được thực hiện bởi nhà phát triển của đơn vị / phương thức / chức năng, bởi vì họ hiểu cốt lõi của một chức năng. Mục tiêu chính của nhà phát triển là bao gồm mã bằng các bài kiểm tra đơn vị.
Nó có một hạn chế là một số chức năng không thể được kiểm tra thông qua các bài kiểm tra đơn vị. Ngay cả sau khi hoàn thành tất cả các bài kiểm tra đơn vị; nó không đảm bảo hoạt động chính xác của sản phẩm. Chức năng tương tự có thể được sử dụng trong một số phần của hệ thống trong khi kiểm tra đơn vị chỉ được viết cho một lần sử dụng.
THỬ NGHIỆM CHỨC NĂNG
Đây là một loại thử nghiệm Hộp đen trong đó thử nghiệm sẽ được thực hiện trên các khía cạnh chức năng của sản phẩm mà không cần xem mã. Kiểm thử chức năng chủ yếu được thực hiện bởi một người kiểm thử phần mềm chuyên dụng. Nó sẽ bao gồm các kỹ thuật tích cực, tiêu cực và BVA sử dụng dữ liệu chưa được chuẩn hóa để kiểm tra chức năng được chỉ định của sản phẩm. Phạm vi kiểm tra được tiến hành theo cách cải tiến bằng các kiểm tra chức năng so với kiểm tra đơn vị. Nó sử dụng GUI ứng dụng để kiểm tra, do đó dễ dàng hơn để xác định chính xác một phần cụ thể của giao diện chịu trách nhiệm thay vì xác định mã nào là chức năng chịu trách nhiệm.
rất đơn giản chúng ta có thể nói:
đọc thêm ở đây .
Kiểm tra đơn vị : - Kiểm tra đơn vị được sử dụng đặc biệt để kiểm tra thành phần sản phẩm theo thành phần đặc biệt trong khi sản phẩm đang được phát triển. Loại công cụ Junit và Nunit cũng sẽ giúp bạn kiểm tra sản phẩm theo Đơn vị. ** Thay vì giải quyết các vấn đề sau khi tích hợp, luôn luôn thoải mái để giải quyết sớm trong quá trình phát triển.
Kiểm tra chức năng: - Đối với Kiểm tra có liên quan, có hai loại Kiểm tra chính là 1. Kiểm tra chức năng 2. Kiểm tra chức năng.
Kiểm tra phi chức năng là một thử nghiệm trong đó Người kiểm tra sẽ kiểm tra rằng Sản phẩm sẽ thực hiện tất cả các thuộc tính chất lượng mà khách hàng không đề cập nhưng các thuộc tính chất lượng đó phải có. Giống như: -Hình thức, Tính khả dụng, Bảo mật, Tải trọng, Căng thẳng, v.v. nhưng trong Kiểm tra chức năng : - Khách hàng đã có mặt với các yêu cầu của mình và những tài liệu đó được ghi lại đúng cách, Nhiệm vụ của người kiểm tra là kiểm tra xem liệu Chức năng ứng dụng có hoạt động theo đến Hệ thống đề xuất hay không. Vì mục đích đó, Tester nên kiểm tra chức năng Đã triển khai với Hệ thống được đề xuất.
Kiểm thử đơn vị thường được thực hiện bởi các nhà phát triển. Mục tiêu của việc làm tương tự là đảm bảo mã của họ hoạt động đúng. Nguyên tắc chung là bao gồm tất cả các đường dẫn trong mã bằng cách sử dụng thử nghiệm đơn vị.
Kiểm tra chức năng : Đây là một tài liệu tham khảo tốt. Giải thích chức năng kiểm tra