Thử nghiệm động là gì? Các loại, kỹ thuật và ví dụ

⚡ Tóm tắt thông minh

Kiểm thử động (Dynamic Testing) thực thi ứng dụng và quan sát cách mã đang chạy hoạt động với các dữ liệu đầu vào thực tế, nhờ đó người kiểm thử có thể xác nhận chức năng, hiệu suất và tính ổn định mà không một phương pháp xem xét tài liệu nào có thể tiết lộ được.

  • 🎯 Mục đích: Hãy xác thực hành vi thực tế khi chạy chương trình, chứ không phải các tài liệu mô tả về nó.
  • 🔀 Hai nhánh: Phân tích hộp trắng kiểm tra mã nguồn, phân tích hộp đen kiểm tra hành vi.
  • 🧱 Bốn cấp độ: Kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử nghiệm thu đều thực thi mã.
  • ⚙️ Không có chức năng: Các bước kiểm tra hiệu năng, khả năng phục hồi, tính tương thích, bảo mật và khả năng sử dụng được thực hiện tại đây.
  • 🔄 Quá trình: Chiến lược, thiết kế kiểm thử, thiết lập môi trường, thực thi và báo cáo lỗi.
  • 💰 Sự đánh đổi: Phát hiện lỗi chuyên sâu hơn đổi lại là thời gian, môi trường và chi phí.

Kiểm thử động: Các loại, kỹ thuật và ví dụ

Thử nghiệm động là gì?

Kiểm thử động Kiểm thử động là một phương pháp kiểm thử phần mềm được sử dụng để kiểm tra hành vi động của mã phần mềm. Mục đích chính của kiểm thử động là kiểm tra hành vi của phần mềm với các biến động — các biến không cố định — và tìm ra các điểm yếu trong môi trường thực thi của phần mềm. Mã phải được thực thi để kiểm tra hành vi động.

Kiểm tra là xác minh và xác nhậnVà cần cả hai bước (kiểm chứng, xác nhận và kiểm định) để hoàn thiện quá trình kiểm thử. Kiểm chứng được thực hiện bằng kiểm thử tĩnh, xem xét các yêu cầu, tài liệu thiết kế và mã nguồn mà không cần chạy chúng. Kiểm định được thực hiện bằng kiểm thử động, chạy bản dựng và so sánh những gì ứng dụng thực sự làm với những gì nó được cho là phải làm.

Bảng dưới đây giúp bạn dễ dàng phân biệt hai loại này.

Yếu tố Kiểm thử tĩnh (xác minh) Kiểm thử động (xác thực)
Code Thực thi Không
Hoạt động tiêu biểu Revquan sát, khảo sát thực địa, kiểm tra, phân tích tĩnh Thực thi trường hợp kiểm thử trên tất cả các cấp độ kiểm thử.
Câu hỏi đã được trả lời Chúng ta có đang xây dựng sản phẩm đúng cách không? Chúng ta có đang xây dựng đúng sản phẩm không?
Đã tìm thấy lỗi Yêu cầu không rõ ràng, vi phạm tiêu chuẩn lập trình, mã chết. Lỗi xuất dữ liệu, rò rỉ bộ nhớ, lỗi thời gian, lỗi tích hợp.
Bắt đầu Ngay khi một hiện vật tồn tại Khi đã có bản dựng có thể thực thi được
Chi phí tương đối của một giải pháp Thấp hơn, vì các lỗi được phát hiện sớm hơn. Cao hơn, vì các khuyết tật xuất hiện muộn hơn.

Ví dụ kiểm thử động

Một ví dụ minh họa ngắn gọn cho thấy cách thức hoạt động của kiểm thử động trong thực tế.

Giả sử trang Đăng nhập đang được kiểm thử. Trang này có hai trường, Tên người dùng và Mật khẩu, và Tên người dùng chỉ được phép chứa các ký tự chữ và số.

Khi người dùng nhập Tên người dùng là “Guru99”, hệ thống chấp nhận. Khi người dùng nhập “GuruKhi nhập lệnh “99@123”, ứng dụng sẽ hiển thị thông báo lỗi. Kết quả này cho thấy mã đang hoạt động một cách linh hoạt dựa trên dữ liệu nhập vào của người dùng.

Do đó, kiểm thử động có nghĩa là làm việc với hệ thống thực tế, cung cấp dữ liệu đầu vào và so sánh hành vi thực tế của ứng dụng với hành vi mong đợi — nói cách khác, làm việc với hệ thống với mục đích tìm ra lỗi.

Do đó, kiểm thử động là quá trình xác thực một ứng dụng phần mềm như thể người dùng cuối sẽ làm vậy, trong các môi trường khác nhau, để xây dựng phần mềm phù hợp.

Thử nghiệm động làm gì?

Mục đích chính của các bài kiểm thử động là đảm bảo phần mềm hoạt động đúng cách trong và sau khi cài đặt, cung cấp một ứng dụng ổn định mà không có lỗi nghiêm trọng. Không có phần mềm nào hoàn toàn không có lỗi, và việc kiểm thử có thể cho thấy sự hiện diện của các khiếm khuyết nhưng không bao giờ có thể cho thấy sự vắng mặt của chúng.

Các bài kiểm tra động cũng đảm bảo tính nhất quán trên toàn bộ phần mềm, như ví dụ này cho thấy.

Trong một ứng dụng ngân hàng có một số màn hình, chẳng hạn như Tài khoản của tôi, Chuyển khoản và... Bill Thanh toán. Tất cả đều có trường số tiền.

Giả sử trường Tài khoản của tôi hiển thị số tiền là 25,000, Chuyển khoản hiển thị 25,000 đô la và... Bill Màn hình thanh toán hiển thị 25000 đô la. Số tiền thì giống nhau, nhưng cách hiển thị lại khác nhau, điều này khiến phần mềm không nhất quán.

Tính nhất quán không chỉ giới hạn ở chức năng. Nó còn bao gồm các tiêu chuẩn như hiệu năng, khả năng sử dụng và tính tương thích, đó là lý do tại sao kiểm thử động lại quan trọng đến vậy.

Các loại thử nghiệm động

Kiểm thử động được phân loại thành hai loại.

  • trắng Box Kiểm tra
  • Da Đen Box Kiểm tra

Sơ đồ bên dưới thể hiện sự tương ứng giữa hai loại hình kiểm tra này với các cấp độ kiểm tra nằm bên dưới chúng.

Kiểm thử động được chia thành kiểm thử hộp trắng và hộp đen với các cấp độ chức năng và phi chức năng.

Mỗi loại và mục đích sử dụng của nó được mô tả bên dưới.

trắng Box Kiểm tra — Một phương pháp kiểm thử phần mềm trong đó cấu trúc và thiết kế bên trong được người kiểm thử biết rõ. Mục đích chính là kiểm tra hiệu suất của hệ thống dựa trên mã nguồn. Phương pháp này chủ yếu được thực hiện bởi các nhà phát triển hoặc các chuyên gia kiểm thử hộp trắng có kiến ​​thức lập trình.

Da Đen Box Kiểm tra — Một phương pháp kiểm thử trong đó cấu trúc bên trong, mã nguồn và thiết kế KHÔNG được người kiểm thử biết đến. Mục đích chính của nó là để xác minh chức năng của hệ thống cần kiểm thử. Loại kiểm thử này yêu cầu phải thực hiện toàn bộ bộ kiểm thử, chủ yếu được thực hiện bởi người kiểm thử và không cần kiến ​​thức lập trình.

Kiểm thử hộp đen lại được phân loại thành hai loại.

  • Thử nghiệm chức năng
  • Kiểm tra phi chức năng

Thử nghiệm chức năng

Thử nghiệm chức năng Việc này được thực hiện để xác minh rằng tất cả các tính năng được phát triển đều phù hợp với các thông số kỹ thuật chức năng. Nó được thực hiện bằng cách chạy chức năng đó. trường hợp thử nghiệm Được viết bởi nhóm QA. Trong giai đoạn này, hệ thống được kiểm thử bằng cách cung cấp dữ liệu đầu vào, xác minh dữ liệu đầu ra và so sánh kết quả thực tế với kết quả mong đợi.

Có nhiều cấp độ kiểm thử chức năng khác nhau, trong đó bốn cấp độ dưới đây là quan trọng nhất.

  • Kiểm tra đơn vị — Một unit là một đoạn mã nhỏ, có thể kiểm thử được. Kiểm thử unit được thực hiện trên từng unit phần mềm riêng lẻ và do các nhà phát triển thực hiện.
  • Thử nghiệm hội nhập — được thực hiện sau khi kiểm thử đơn vị, bằng cách kết hợp các đơn vị có thể kiểm thử riêng lẻ. Việc này có thể do lập trình viên hoặc người kiểm thử thực hiện.
  • Thử nghiệm hệ thống — được thực hiện để đảm bảo hệ thống hoạt động đúng theo yêu cầu. Việc này thường được thực hiện bởi các chuyên viên kiểm thử khi hệ thống hoàn chỉnh đã sẵn sàng, sau khi bản dựng được chuyển giao cho nhóm QA.
  • Kiểm tra chấp nhận — được thực hiện để xác minh xem hệ thống đã đáp ứng các yêu cầu kinh doanh và sẵn sàng để sử dụng hoặc triển khai hay chưa. Việc này thường được thực hiện bởi người dùng cuối.

Kiểm tra phi chức năng

Kiểm tra phi chức năng Kiểm thử phi chức năng là một kỹ thuật kiểm thử không tập trung vào các khía cạnh chức năng mà thay vào đó tập trung vào các thuộc tính phi chức năng của hệ thống, chẳng hạn như rò rỉ bộ nhớ, hiệu năng hoặc độ bền vững. Kiểm thử phi chức năng được thực hiện ở tất cả các cấp độ kiểm thử.

Có rất nhiều kỹ thuật kiểm thử phi chức năng, trong đó năm kỹ thuật dưới đây là quan trọng nhất.

  • Kiểm tra năng suất — Kiểm tra xem thời gian phản hồi của hệ thống có bình thường, đáp ứng yêu cầu hay không, dưới tải mạng mong muốn.
  • Kiểm tra phục hồi — Kiểm tra khả năng phục hồi của hệ thống sau sự cố và lỗi phần cứng.
  • Kiểm tra khả năng tương thích — Kiểm tra xem hệ thống hoạt động như thế nào trong các môi trường khác nhau.
  • Kiểm tra bảo mật — Xác minh tính ổn định của ứng dụng, đảm bảo rằng chỉ những người dùng và vai trò được ủy quyền mới có thể truy cập hệ thống.
  • Kiểm tra khả năng sử dụng — Xác minh tính khả dụng của hệ thống đối với người dùng cuối và mức độ thoải mái của họ khi sử dụng hệ thống.

Kỹ thuật kiểm thử động

Sau khi đã xác định được các loại kiểm thử, câu hỏi tiếp theo là chu kỳ kiểm thử động được thực hiện như thế nào trên thực tế.

Các kỹ thuật kiểm thử động trong STLC Quá trình kiểm thử động bao gồm các nhiệm vụ như phân tích yêu cầu kiểm thử, lập kế hoạch kiểm thử, thiết kế và triển khai trường hợp kiểm thử, thiết lập môi trường kiểm thử, thực thi trường hợp kiểm thử, báo cáo lỗi và cuối cùng là kết thúc kiểm thử. Mỗi nhiệm vụ trong kiểm thử động đều phụ thuộc vào việc hoàn thành nhiệm vụ trước đó trong quy trình kiểm thử.

Trong chu trình STLC, quá trình kiểm thử động thực tế bắt đầu từ thiết kế trường hợp kiểm thử. Sơ đồ bên dưới thể hiện trình tự các hoạt động, mỗi hoạt động được mô tả sau đó.

Quy trình kiểm thử động bao gồm từ thiết kế kiểm thử, thực thi cho đến báo cáo lỗi.

Trước khi bắt đầu quy trình, cần phải thống nhất chiến lược thực hiện kiểm thử động.

Chiến lược kiểm thử nên tập trung chủ yếu vào các nguồn lực sẵn có và thời gian thực hiện. Dựa trên hai yếu tố đó, mục tiêu của việc kiểm thử, phạm vi kiểm thử, các giai đoạn hoặc chu kỳ kiểm thử, loại môi trường, các giả định hoặc thách thức có thể gặp phải và các rủi ro đều phải được ghi lại.

Sau khi chiến lược được xác định và được ban quản lý chấp thuận, quá trình thiết kế trường hợp thử nghiệm thực tế sẽ bắt đầu.

Thiết kế và triển khai thử nghiệm

Trong giai đoạn này, nhóm sẽ xác định những điều sau đây.

  • Các tính năng cần kiểm tra
  • Các điều kiện thử nghiệm được suy ra từ những đặc điểm đó.
  • Các mục phạm vi bao phủ được suy ra từ các điều kiện thử nghiệm
  • Các trường hợp kiểm thử được tạo ra từ các mục kiểm thử độ phủ.

Hộp đen kỹ thuật thiết kế thử nghiệm chẳng hạn như phân vùng tương đương, phân tích giá trị biên, kiểm tra bảng quyết địnhkiểm tra chuyển trạng thái Đó là những gì biến điều kiện kiểm thử thành một tập hợp các trường hợp có thể thực thi cụ thể.

Thiết lập môi trường thử nghiệm

môi trường thử nghiệm Môi trường thử nghiệm luôn phải tương tự như môi trường sản xuất. Trong giai đoạn này, bản dựng được cài đặt và các máy thử nghiệm được quản lý và cấu hình.

Thực hiện kiểm tra

Trong giai đoạn này, các trường hợp kiểm thử thực sự được thực thi, bằng tay hoặc thông qua hệ thống tự động. tự động hóavà kết quả thực tế được ghi nhận so với kết quả dự kiến.

Đã ghi lại báo cáo lỗi

Dựa trên quá trình thực thi, nếu kết quả mong đợi và kết quả thực tế không giống nhau, trường hợp kiểm thử phải được đánh dấu là Thất bại và lỗi phải được ghi lại. quản lý lỗi quá trình.

Ưu điểm của thử nghiệm động

  • Kiểm tra động giúp phát hiện những khuyết tật mà trước đây được coi là quá khó hoặc quá phức tạp để tìm ra, và phân tích tĩnh hoàn toàn không thể bao quát được.
  • Phần mềm được thực thi từ đầu đến cuối, điều này nâng cao chất lượng của cả sản phẩm và dự án.
  • Kiểm thử động là một phương pháp thiết yếu để phát hiện các mối đe dọa an ninh trong một hệ thống đang hoạt động.
  • Các lỗi chỉ xảy ra trong quá trình thực thi, chẳng hạn như rò rỉ bộ nhớ, sự cố về thời gian và lỗi tích hợp, chỉ xuất hiện ở đây và không ở nơi nào khác.

Nhược điểm của thử nghiệm động

  • Kiểm thử động tốn nhiều thời gian vì việc thực thi ứng dụng hoặc mã lệnh đòi hỏi một lượng lớn tài nguyên.
  • Điều này làm tăng chi phí của dự án vì nó không được bắt đầu sớm trong vòng đời phần mềm và các vấn đề được khắc phục ở giai đoạn sau sẽ tốn nhiều chi phí hơn.
  • Môi trường giống như môi trường sản xuất và dữ liệu thử nghiệm thực tế là những điều kiện tiên quyết, và việc xây dựng cũng như duy trì cả hai đều đòi hỏi nhiều công sức.

Câu Hỏi Thường Gặp

Các nhà phát triển chịu trách nhiệm về phía "hộp trắng", thực hiện kiểm tra đơn vị và thành phần. Các chuyên viên kiểm thử chất lượng chịu trách nhiệm về phía "hộp đen", từ kiểm thử hệ thống trở đi. Người dùng cuối kết thúc chu trình bằng kiểm thử chấp nhận.

Mô hình đọc các yêu cầu và các trường hợp hiện có, sau đó đề xuất các giá trị giới hạn, đầu vào không hợp lệ và chuỗi trạng thái mà quá trình kiểm thử thủ công thường bỏ qua. Người kiểm thử vẫn xác nhận từng kết quả mong đợi trước khi thực thi.

Đúng vậy. Việc xây dựng cấu trúc khẳng định, các đối tượng trang và thiết lập fixture là những đoạn mã lặp đi lặp lại mà một trợ lý có thể xử lý tốt. Việc quyết định hành vi nào là đúng vẫn là một phán đoán của con người dựa trên các yêu cầu.

Các khung đơn vị như JUnit, TestNG và pytest, cùng với các trình chạy giao diện người dùng và API như... Selenium, Cypress và PostmanTải các công cụ như... JMeter bao gồm khía cạnh phi chức năng của tự động hóa.

Báo cáo kiểm thử hộp trắng cho thấy độ bao phủ câu lệnh, nhánh và đường dẫn từ các lần chạy có tích hợp công cụ. Báo cáo kiểm thử hộp đen cho thấy độ bao phủ yêu cầu và điều kiện kiểm thử. Không một con số nào tự chứng minh được bản dựng đã được kiểm thử đầy đủ.

Không. Kiểm thử động mô tả việc thực thi mã, bất kể ai hoặc cái gì điều khiển nó. Một kịch bản được viết sẵn nhãn hiệu Việc chạy thử và bộ kiểm thử hồi quy tự động đều là các hình thức kiểm thử động.

Đúng vậy. Kiểm thử bảo mật ứng dụng động (Dynamic Application Security Testing) thăm dò một ứng dụng đang chạy từ bên ngoài, giống hệt như kiểm thử hộp đen. kiểm tra bảo mật Nó làm vậy và báo cáo các lỗ hổng chỉ xuất hiện trong quá trình thực thi.

Nó là xương sống của toàn bộ hệ thống. Bộ kiểm thử đơn vị và API kiểm soát mọi cam kết, trong khi thời gian dài hơn hồi quy và các bài kiểm tra hiệu năng được thực hiện hàng đêm dựa trên bản dựng đã được triển khai.

Tóm tắt bài viết này với: