Kiểm thử tĩnh vs kiểm thử động (Static vs Dynamic testing)

Bài viết được sự cho phép của tác giả Vân Anh

Lại một năm nữa đã đi qua, và một năm mới lại đến, hôm nay đã là tuần thứ hai của năm mới rồi mà chưa có thời gian nhìn lại một năm đã qua. Nói là “không có thời gian” thì mọi người nghe thấy cũng hơi ngờ vực, nên mình cũng sẽ phải xem lại các kế hoạch và công việc của mình, tại sao mà không có lấy nổi ít nhất hai tiếng liền mạch để viết một bài, một chủ đề cho nghiêm túc?! Lý do thì ai cũng có lý do chính đáng của mình cả, cơ bản là mình có thực sự muốn dành thời gian cho nó hay không thôi!

  10 bước để bắt đầu áp dụng kiểm thử tự động vào dự án
  7 lãng phí trong kiểm thử phần mềm

Hehe, trên lý thuyết là như thế, nhưng mà tất nhiên là mình muốn dành thời gian cho nó, vậy nên để khắc phục (có thể là tạm thời thôi, lâu dài thì chưa biết :)) ) mình tranh thủ thời gian đi làm (khá) sớm, lúc mà công ty còn chưa có mấy người đến và cộng với thời gian đứng chờ thang máy, mới nghĩ là khoảng thời gian này khá là phù hợp để suy nghĩ và viết về những kiến thức cơ bản. Trước đó thì thời gian đến sớm mình hay ngồi đọc sách (đọc khoảng nửa tiếng thì mọi người trong công ty bắt đầu đến nhiều, ồn ào hơn thì mình cất sách đi và chuẩn bị các thứ để bắt đầu làm việc, thế nhưng cũng có những hôm đọc được tầm nửa tiếng thì mình lại buồn ngủ, trong lúc ồn ào đó mình cũng tranh thủ được 10 -15 phút haha).

Thôi lan man quá, vào chủ đề thôi, thời gian tranh thủ này thì mình đọc và ôn lại các lý thuyết về kiểm thử phần mềm, dù có thể là nó không được sử dụng trực tiếp nhiều trong công việc hàng ngày mình vẫn làm, nhưng mình nghĩ ít nhiều nó cũng có ích cho sau này, thứ nhất là kiến thức không bị mai một, tiếp nữa là khi nào cần đến thì bỏ ra xem lại sẽ nhanh hơn, và nhất là có thể sẽ giúp ích cho ai đó đang cần tìm thì sao! 😀

Hôm nay chúng ta sẽ cùng thảo luận về Static testing và Dynamic testing (Kiểm thử tĩnh và kiểm thử động). Để cho dễ hiểu và dễ hình dung hơn, mình sẽ kết hợp lý thuyết với một ví dụ cụ thể, như phía dưới đây.

Ví dụ: Ta có một mô tả yêu cầu – khá là đơn giản như sau:

Cửa sổ sẽ thực hiện mở khi người dùng bấm vào nút Mở và sẽ thực hiện đóng lại khi ấn vào nút Đóng.

1. Static testing

1.1. Static testing – Được thực hiện mà không phải thực thi code

Từ yêu cầu phía bên trên, thì các coder của chúng ta sẽ phải viết code để làm sao đáp ứng được yêu cầu của người dùng là bấm vào nút mở thì cửa mở và bấm vào nút đóng thì cửa đóng, ví dụ một giả lập như sau:

buttonPressed(){
  if ( Button ==up)
     UpMovement
  else
     DownMovement
}

Static testing sẽ làm gì ở đây, thì đó chính là kiểm tra xem đoạn code mà các coder viết có đúng, có đáp ứng được yêu cầu đó hay không, hoặc có bao phủ được một số các trường hợp cơ bản cần phải có hay không… Static testing sẽ kiểm tra đến từng dòng code, kiểm tra tính logic cũng như việc thực thi được yêu cầu đặt ra. Ở ví dụ trên là ví dụ đơn giản và dòng code mô phỏng thì khá là dễ hình dung cũng như kiểm tra, còn đối với các bài toán thực tế thì nó sẽ rắc rối hơn, yêu cầu kết hợp rất nhiều các điều kiện và các cách xử lý khác nhau, có những hàm, function dài đến cả mấy chục dòng thì việc kiểm tra không phải là đơn giản như ví dụ trên nữa :))

1.2.  Static testing – Được thực hiện ở giai đoạn Verification (Giai đoạn xác minh)

Giả sử một quy trình sơ bộ để xây dựng sản phẩm như sau:

Từ User Requirement >> System requirement >> Global design >> Detail design >> Implementation

Ở giai đoạn đầu, khi mà ta mới chỉ có các tài liệu yêu cầu, thiết kế mà chưa tiến hành viết code hay thực thi thì việc kiểm thử động là chưa khả thi, vì vậy mà việc sử dụng Static testing trên các tài liệu yêu cầu, hay các bản thiết kế ở giai đoạn này sẽ là phương án phù hợp và hiệu quả.

1.3. Góp phần tiết kiệm chi phí cho sản phẩm

Nói Static testing góp phần tiết kiệm chi phí cho sản phẩm là như thế nào? Có nghĩa là những lỗi được tìm ra ở static testing sẽ mất ít chi phí và sửa chữa hơn. Ví dụ như ở trên, tại giai đoạn Verification, từ tài liệu mô tả yêu cầu người dùng, ta có tài liệu mô tả hệ thống, rồi đến các bản thiết kế tổng thể, chi tiết nếu thực hiện tốt static testing sẽ tìm ra được những vấn đề, lỗi (nếu có) được mô tả hoặc thiết kế chưa đúng với yêu cầu của người dùng thì việc sửa chữa cập nhật tài liệu ngay từ những bước đầu này sẽ mất ít chi phí hơn là việc mãi đến giai đoạn Validation mới tìm được ra vấn đề thì sẽ tốn nhiều chi phí không đáng có hơn. Do đó giúp tiết kiệm chi phí cho sản phẩm.

1.4. Static testing thực hiện trên các luồng nghiệp vụ, và hoạt động review code.

2. Dynamic tesing:

2.1. Được thực hiện khi thực thi code

Cũng đối với ví dụ trên, static testing ngắn gọn là sẽ soi vào code còn dynamic testing thì sẽ thực hiện dựng code đó lên rồi thực thi việc test trên môi trường và thiết bị tương tự như môi trường thực tế mà phần mềm/hệ thống sẽ được sử dụng. Ta sẽ thực hiện kiểm tra hoạt động của hệ thống đúng theo luồng hoạt động và mô tả của yêu cầu, đó là nhấn vào nút mở, kiểm tra xem có đúng là cửa sổ được mở hay không? Và nhấn lại vào nút đóng thì có đúng là nó được đóng hay không? Đảm bảo việc hoạt động của các nút và chức năng tương ứng đáp ứng được yêu cầu đưa ra là được, ta sẽ không quan tâm phía dưới nó được xây dựng và chạy như thế nào, hay coder code nó như thế nào….

2.2. Được thực hiện ở giai đoạn Validation

Validation được thực hiện sau khi hệ thống đã được code dựa trên các tài liệu yêu cầu, thiết kế, vì dynamic testing được thực hiện khi run code. Tức là lúc này phải có một bản build rồi thì mới thực hiện được.

2.3. Tốn nhiều chi phí để sửa chữa cập nhật hơn

Với dynamic testing, việc kiểm thử được thực hiện sau khi đã có code, và đã được build, với những lỗi phát sinh trong quá trình code thì nó là điều không tránh khỏi thì sẽ không nói đến ở đây. Tuy nhiên những vấn đề liên quan đến lỗi tài liệu mô tả, hay lỗi thiết kế từ giai đoạn trước đó để lọt, thì sẽ mất nhiều thời gian và chi phí để sửa chữa hơn. Đối với những chức năng đơn lẻ độc lập thì chi phí đôi khi có thể là chấp nhận được, rất là hiếm khi nhưng nếu vì sơ suất trong lúc phân tích yêu cầu, ở những phần chức năng có liên quan, phụ thuộc nhau (Ví dụ như: sửa cái này thì ảnh hưởng đến hoạt động của nhiều phần khác) thì chi phí lúc này có thể tăng lên rất nhiều lần.

2.4. Dynamic testing thực hiện kiểm thử chức năng và phi chức năng.

Tạm kết

Kiến thức cơ bản liên quan đến Static và Dynamic mình tạm dừng ở đây đã, tài liệu tiếng Việt cũng có khá nhiều rồi, chi tiết cụ thể của từng cái khi mà tìm cũng không hề ít, nên mình không nói thêm, nói lại nữa :))) Lẽ ra để cột so sánh thì sẽ trực quan hơn nhưng mà vì nội dung từng mục hơi dài, và phần hiển thị của theme wordpress này cũng nhỏ nên cứ viết tràn kiểu này vậy. Hi vọng bài viết đã cung cấp một lượng thông tin hữu ích cho các bạn. Nếu có chỗ nào còn thắc mắc hay chưa rõ ý, muốn trao đổi và góp ý các bạn thoải mái để lại bình luận phía dưới nhé!

Bài viết gốc được đăng tải tại vananhtooo.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm Developer hấp dẫn trên TopDev