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.

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 | Có |
| 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.
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 đó.
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 định và kiể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.


