Sự khác biệt giữa 2 kỹ thuật: Static Testing và Dynamic Teting
Bài đăng này đã không được cập nhật trong 2 năm
Testing là xác minh (verification) và xác nhận (validation). Chúng ta biết rằng phải mất cả 2 quá trình này để hoàn tất quá trình kiểm thử.
Trong bài viết ngày hôm nay chúng ta sẽ làm sáng tỏ về Static Testing. Nó cũng được gọi là xác minh (Verification). Chúng ta sẽ tìm hiểu về nó và nhấn trọng tâm vào điều này, bởi vì Dynamic Testing thường nhận được nhiều sự quan tâm và có vô số bài viết về nó.
Tuy nhiên, không có cuộc thảo luận nào về Static Testing sẽ được hoàn thành mà không có 1 vài giải thích về Dynamic Testing. Dynamic Testing là xác nhận (Validation), chữ V còn lại. Dynamic Testing là khi bạn đang làm việc với hệ thống thật (Không phải 1 số hiện vật hoặc mô hình đại diện cho hệ thống), cung cấp 1 đầu vào, nhận 1 đầu ra và so sánh đầu ra với hành vi mong đợi. Nó làm việc thực tế với hệ thống với mục đích tìm kiếm các lỗi.
Trong quá trình này, bạn sẽ hiểu 2 quan niệm sai lầm phổ biến sau về testing là không đúng:
- Testing là 1 hoạt động mà thực hiện cuối cùng.
- Testing chỉ được thực hiện bởi các tester và những người còn lại không làm gì cả.
Chúng ta bắt đầu với V-model:
- Ở phía bên tay trái của V-model chúng ta có các hoạt động mà không được thực hiện bởi QA team.
- Ở phía bên tay phải chúng ta có 1 số hoạt động mà được take care bởi Dev team, các tester và 1 vài user.
Hãy bắt đầu với – thu thập các requirement. Nó được thực hiện bởi Business Analyst và các quản lý cấp cao khác – tài liệu đầu ra cho giai đoạn này là Business requirement document– BRD.
Giai đoạn tiếp theo là system design. System design là 1 giai đoạn mà các Business requirement được chuyển thể thành các Functional Requirement Document– FRD. Khi quá trình chuyển thể diễn ra, dev team (người thực hiện chính cho bước này) sẽ xem tài liệu BRD từng bước, từng trang, từng dòng. Mục đính chính là sử dụng các Business requirement vì lợi ích của bản chuyển thể, các tài liệu BRD sẽ được nhận xét lần lượt.
Ví dụ: Nói về BRD cho 1 web site ngân hàng mà cần bảo mật cao. Có 1 phần trong BRD mà nói về các quy định mật khẩu cho nhiều user khác nhau đang tạo tài khoản với web site online của ngân hàng. 1 trong những quy định là: 1 user không thể sử dụng mật khẩu mà họ đã sử dụng cho tài khoản khác. Điều này là không thể. Bởi vì 1 web site chỉ có thể gợi ý làm thế nào user có thể thiết lập thông tin đăng nhập nhưng không có cách nào thực hiện hạn chế đó. Bởi vậy, yêu cầu này không khả thi, nói cách khác, không thể thực hiện qua phầm mềm.
Bây giờ chúng ra sẽ xem xét các điểm sau dựa trên ví dụ này:
- Làm thế nào xác định được rằng yêu cầu này là không thể xây dựng và do đó không thể được test (hay nói cách khác là không khả thi)? Chúng ta có 1 web site của ngân hàng và sau đó chúng ta làm thiết lập login/password – và sau đó nhận ra rằng điều này là không thể? Không, chúng ta chỉ đơn giản dựa trên các review của BRD của chúng ta và 1 vài ý nghĩa kinh doanh chung.
- Chúng ta đang test yêu cầu này phải không? Chắc chắn, nhưng hoàn toàn dựa vào lý thuyết, không phải thực tế (trong việc test ứng dụng).
- Hình thức vật lý của việc test này là gì? Đơn giản là đọc hay 1 review chính thức của BRD hay 1 phân tích có tính khả thi của các Business requirement.
Trở lại với quan niệm sai lầm của chúng ta: 4. Người mà thực hiện các review này của BRD là ai? Chủ yếu là dev team và các team kỹ thuật khác mà có trách nhiệm tạo ra sản phẩm. Không phải các tester. 5. Các review này diễn ra ở cuối của việc tạo ra sản phẩm? Không, ở giai đoạn bắt đầu phát triển dự án. Không phải chỉ ở cuối dự án.
Các kỹ thuật Static Testing: Tóm tắt, Static Testing là việc kiểm tra từng phần của software theo các phương thức sau:
- Document reviews: các review về tài liệu.
- Walkthroughs: Kiểm tra từ đầu đến cuối.
- Inspection: kiểm duyệt.
- Feasibility analysis or any other form of analysis to determine if the software is what it should be or not: Phân tích tính khả thi hay bất kỳ các phân tích khác để chỉ ra software cần cái gì hay không cần cái gì.
- Code review
Để trích dẫn CSTE CBOK “Verification answers the question, “Did we build the right system?” while validations addresses, “Did we build the system right?” Theo dõi toàn bộ các hoạt động của Static Testing xảy ra phía bên tay trái của V-model.
| SDLC stage | Output | Verifies | Actors |
|---|---|---|---|
| Business requirement gathering | BRD (Business Requirement document) | Scope document (if any) | |
| System requirement design | Reviews/verifies the BRD | Scope document (if any) | Dev, Technical teams |
| Technical requirements design | TDD (Technical Design Document) | Reviews/verifies the FRD | Dev, Technical teams |
| Design (code) | Code | Reviews/verifies the TDD. Code review by the dev team for completeness, format etc. | Dev, Technical teams |
|
Lưu ý: Thông tin này có thể được khái quát cho các dự án theo bất kỳ phương phát phát triển nào bởi vì các bước sẽ giống nhau ít hoặc nhiều.
Bên phía tay phải của V-model là validation.
Các kỹ thuật Dynamic Testing:
- Unit Testing
- Integration Testing
- System Testing
Các giai đoạn Unit Testing, Itergration Testing, System Testing và UAT là tạo ra các ca kiểm thử được thực hiện trên UAT trong suốt các giai đoạn phát triển khác nhau của nó. Mặc dù mục đích là để xác minh các loại yêu cầu khác nhau, nhưng tất cả các ca kiểm thử là giống nhau.
Bởi vậy bất kỳ ca kiểm thử nào mà chúng ta cần thực hiện trên UAT và đầu ra của nó được yêu cầu chỉ ra kết quả của ca kiểm thử (thành công hay không) – nó là validation. Bây giờ chúng ta sẽ chấp nhận để kết luận rằng ở phía bên tay phải (right hand side -RHS) của V-model không có verification? Câu trả lời là KHÔNG.
Tất cả các ca kiểm thử mà được tạo ra ở mỗi giai đoạn của RHS đã được xem xét vài lần trong suốt các giai đoạn tạo/hoàn thiện các ca kiểm thử. Chi tiết quá trình review các tài liệu kiểm thử tham khảo ở: http://www.softwaretestinghelp.com/test-documentation-reviews/
Trên RHS:
- Các ca kiểm thử và code là đã được review trong các giai đoạn Unit/Intergration Testing bởi các developer.
- Các hệ thống test được review như nhau trong suốt tài liệu của họ và sau khi hoàn thành 1 review bởi dev team và Business analyst.
- Các ca kiểm thử UAT được review bởi QA team cũng như các user trước khi bắt đầu UAT.
Kết luận:
Cuối cùng, Static Testing là 1 kỹ thuật quan trọng mà có dạng Business requirement review, Functional requirement review, design reviews, code walkthroughs và test documentation review. Nó là 1 chuỗi các hoạt động và không chỉ được làm bởi các tester.
Validation, phần Dynamic Testing là thực tế và xảy ra trên chính sản phẩm và không phải trên 1 vật hoặc 1 đại diện của sản phẩm. Một quá trình chính thống của việc nhận diện các test case/condition, các coverage consideration, execution sẽ đánh đấu tất cả các phương thức của Dynamic Testing.
Tham khảo: http://www.softwaretestinghelp.com/static-testing-and-dynamic-testing-difference/
All rights reserved
