Những loại kiểm thử phần mềm hiện có và lưu ý khi sử dụng (Part 1)


Một sản phẩm, để đến tay người sử dụng, không biết đã phải tham gia bao nhiêu lần kiểm thử mới thành công? Để cung cấp cho khách hàng những sản phẩm tối ưu, hiệu quả cao, thì kiểm thử là một bước vô cùng quan trọng không thể thiếu. Sau đây là những review và cảm nhận về các cách kiểm thử phần mềm đang được sử dụng.

1. Phân tích chương trình tĩnh (static testing)

Phân tích chương trình tĩnh hay còn được gọi là code review, là một phuơng pháp kiểm thử giúp kiểm tra các đoạn mã xử lý đúng logic hay không, kiểm tra cách dùng dữ liệu và biến số, kiểm tra code có theo đúng chuẩn hay không.
Khi review code, sẽ có 2 kiểu: review trước nhiều người gọi là walkthrough và một người review gọi là desk check. Với walkthrough, ưu điểm của nó là có thể tìm ra được nhiểu lỗi hơn do tập hợp được nhiều ý kiến khác nhau, thế nhưng lại không tránh khỏi sự đánh giá của mỗi người đối với cá nhân người thực hiện.
Code review cũng là một phương thức tự học khá hay ho thông qua việc review code cho người khác.
Ngoài code review, trong phân tích chương trình tĩnh còn có test cấu trúc của website.



2. Phân tích chương trình động: (dynamic testing)

Đây là phương pháp kiểm thử dùng để tìm ra các thiếu sót khó tái hiện lại như rò rỉ bộ nhớ hay sử dụng con trỏ không đúng. Trong thực tế việc khó tái hiện xảy ra khá nhiều nên người ta hay dùng các tool để thực hiện test kiểu này.

3. Phân vùng tương đương (equivalence partitioning)


Phương pháp kiểm thử này nhận dạng input,output là không hợp lệ hay hơp lệ và tuơng đuơng rồi thực hiện input,output đó. Các giá trị tuơng đuơng có thể là số,là thời gian, hoặc là byte. Nó cũng xác định điểm tốt điểm xấu của test case bằng cách nhận dạng input/output của test case có tuơng đương hay không.

4.Phân tích giá trị biên (Boundary value analysis)



Đối với mỗi input và output,chúng sẽ nhận dạng giới hạn trên và dưới, thực hiện input (output) cho giá trị biên đó.
Giá trị biên trong trường hợp này không phải là giới hạn thực tế của input(output), mà là giá trị tối đa/ tối thiểu của input/output tính theo đơn vị lưu trữ trên máy tính hoặc đơn vị hiển thị trên màn hình.
VD: khi sử dụng phương pháp test này thì có thể tìm ra bug "không thể lưu được dữ liệu của hơn 255 trò chơi"

5. Bảng quyết định (decision table)


Đây là một trong những kĩ thuật trong combination test, trình bày dưới dạng bảng,được thể hiện thông qua các kí hiệu giống bảng mạch điện tử.
Khi chức năng có nhiều giá trị mặc định, ta phải viết các test case cover hết các giá trị đó. Về cơ bản, việc viết test case cover nhiều giá trị như vậy giúp chúng ta tăng khả năng lọc tìm các thiếu sót . Ngoài ra, việc tạo bảng cũng có thể giúp ta tìm ra các thiếu sót ngay cả trong bản thông số kĩ thuật.
Vì phải cover nhiều giá trị kết hợp như vậy nên chúng ta cần tối giản chúng bằng các phương thức như bảng trực giao (orthogonal table) hoặc kĩ thuật all pair. Những phương thức như vậy chỉ là tối giản theo cách vật lý, có khả năng sẽ bỏ sót loại combination được sử dụng với tần suất nhiều nhất nên chúng ta luôn phải review các combination mà chúng ta đã tạo ra.

6. Test chuyển đổi trạng thái (state transition testing)

Đây là phương thức giúp ta xác nhận sự chuyển đổi trạng thái của chương trình, xem các trạng thái trong từng trường hợp có chuyển đổi chính xác hay không ví dụ như:
Ví dụ sự thay đổi trạng thái khi rút tiền trong thẻ tín dụng như hình ảnh dưới đây:


Khi chương trình có càng nhiều trạng thái (state) thì có càng nhiều truờng hợp thay đổi trạng thái cần test. Chính vì thế  khi thực hiện phuơng pháp này thì cần phải tính đến số lượng kết hợp các trạng thái vô cùng lớn, và cũng như trên, chúng ta cũng nên dùng các biện pháp như bảng trực giao (orthogonal table) hoặc kĩ thuật all pair để đơn giản,rút gọn chúng.

7. Test thăm dò/khám phá (exploratory testing)

Đây là phương pháp thực hiện đồng thời: tìm hiểu về sản phẩm, kế hoạch test ,vận hành.


Không giống như random test được thực hiện một cách ngẫu nhiên,  test thăm dò phải thực hiện đồng thời những thao tác cần thiết như đã nêu trên. Test sẽ kiểm tra cả những phần đang chạy trên thực tế, giá trị biên của input value cũng như default combination nên hiệu suất của phương pháp này khá cao. Dĩ nhiên, test này cũng đòi hỏi những kiến thức,kinh nghiệm phù hợp liên quan đến quá trình test. Đây được cho là phương pháp thích hợp nhất cùng với sự phát triển nhanh chóng của các phần mềm như agile development process (phần mềm phát triển linh hoạt) . Tuy nhiên việc tập hợp các tài liệu chi tiết trong các thao tác hay metrics (quản lý dữ liệu theo cách phân tích) không phải là một điều đơn giản.

8. Đoán lỗi (error guessing)



Đây là phương pháp của kinh nghiệm và cảm giác.
Chúng ta không nên xem nhẹ kinh nghiệm và cảm quan.  Những kinh nghiệm được tích lũy đó không chỉ giúp ta về mặt kĩ thuật của test mà còn là tri thức về cách sử dụng sản phẩm hàng hóa, sẽ tạo ra những test case hữu ích. Kinh nghiệm sẽ giúp chúng ta tạo ra những mẫu test case phù hợp với bản thông số kĩ thuật, nhưng việc làm sao để sử dụng kinh nghiệm đó một cách khéo léo không phải là điều đơn giản. Chúng ta nên nhờ những người có kinh nghiệm review cho để có thể hoàn thành phần test đó.

                                                              ---(Còn tiếp)---

Nguồn tham khảo:  http://shanon-tech.blogspot.com/2011/05/blog-post.html











If you liked this article

Let's subscribe the updates of Scuti!
Share on Google Plus

About Ruby Stone

This is a short description in the author block about the author. You edit it by entering text in the "Biographical Info" field in the user admin panel.
    Blogger Comment
    Facebook Comment

0 Comments:

Post a Comment