Lập kế hoạch Test
Dưới đây là bài viết về việc lập kế hoạch test của một tác giả người Nhật. Mình thấy khá dễ hiểu dành cho các bạn Dev. Bài viết khá dài nên mình sẽ chia làm 2 phần. Cá nhân tôi nghĩ rằng: Việc lập kế hoạch kiểm thử phần mềm được coi là thành công nếu các developer bình thường cũng có thể dễ dàng ...
Dưới đây là bài viết về việc lập kế hoạch test của một tác giả người Nhật. Mình thấy khá dễ hiểu dành cho các bạn Dev. Bài viết khá dài nên mình sẽ chia làm 2 phần.
Cá nhân tôi nghĩ rằng: Việc lập kế hoạch kiểm thử phần mềm được coi là thành công nếu các developer bình thường cũng có thể dễ dàng hiểu, nắm bắt được kế hoạch đó. Test Schedule thông thường được chia thành các loại cơ bản nhất: Unit test, test tổng hợp, System test.
Schedule test này theo flow: Từ đầu tới cuối sẽ thực hiện test theo Model hình chữ V, test những phần đã làm xong ở công đoạn trước. Trên thực tế, tùy theo dự án, việc test theo hướng nào, theo trình tự nào sẽ có sự khác nhau. Do đó, việc lên kế hoạch test là rất quan trọng Tuy nhiên, nếu các bạn không hiểu được sự khác nhau giữa 2 phạm trù: Câu chuyện về công đoạn test và “Nội dung test được thực hiện trong thực tế” thì sẽ dẫn đến tình trạng: ủa, mình đang làm gì với kế hoạch test vậy? => Dẫn tới việc: Việc test không thể được thực hiện một cách triệt để. Trên thực tế, có khá nhiều dự án đã để xảy ra tình trạng này.
Hiện tại, đã có tiêu chuẩn ISO/IEC/IEEE 29119- Tiêu chuẩn toàn cầu dành cho Test. Nhìn vào tiêu chuẩn này, ta có thể thấy: Đây là Test process được xây dựng bằng cách kết hợp giữa Công đoạn Test (Test Level/Phase) với Loại Test (Test Types), đồng thời hai yếu tố này vẫn được phân chia rạch ròi. Tuy nhiên việc này cũng chỉ diễn ra trong môi trường dự án lý tưởng mà thôi.
Các loại Test
Từ các lý do trên, khi lập kế hoạch test, điều đầu tiên và cũng là đơn giản nhất, chính là: Chúng ta nên bắt đầu kế hoạch Test bằng việc “Thiết kế loại test” Đối với cá nhân tôi, những loại test mà tôi thường dùng là những loại test được liệt kê dưới đây. Tùy theo trường hợp cần thiết, sẽ có hoặc không thực hiện Security test.
| Loại test | Loại Test | Mục đích | Input |
|---|---|---|---|
| Check cú pháp | Check cú pháp của Source | Phân tích tĩnh source code, phát hiện chỗ nào vi phạm coding convention, chỗ nào có khả năng gây ra bug | Quy ước code (coding convention) |
| heck cú pháp | Check cấu pháp SQL | Chạy SQL đơn lẻ; Confirm không có error ngữ pháp | |
| Unit Test | Test các action bằng các class, tham số riêng lẻ. Thường test bằng cách: sử dụng các tools có chức năng test hồi quy, như xUnit…v.v, viết code …v.v | Tài liệu thiết kế chi tiết | |
| Test Chức năng | Test chức năng trên màn hình | Confirm trên từng màn hình xem: màn hình đó đã thỏa mãn các yêu cầu được định nghĩa trong Spec hay chưa? | Tài liệu thiết kế màn hình |
| Test chức năng | Test chức năng batch | Confirm từng batch 1 xem đã thỏa mãn Spec được định nghĩa trên Tài liệu thiết kế batch | Tài liệu thiết kế batch |
| Test Format | Test Layout | Confirm xem phần được output ra có layout như trong thiết kế như form, interface không. | Tài liệu thiết kế form, thiết kế interface |
| Test Format | Test so sánh giữa bản hiện tại – bản mới | Nếu là dự án migration, không thay đổi chức năng, thì sẽ phải confirm xem: Màn hình, batch được output ra có layout giống với hệ thống hiện tại hay không? | Hệ thống hiện tại |
| Security Test | Test quyền access | Test: chỉ những người được cấp quyền truy cập mới có thể truy cập vào Resource. | |
| Security Test | Test CSRF | Test đảm bảo: Dữ liệu sẽ không bị update khi gọi giá trị của Method POST/PUT/DELETE/PATCH. | - |
| Security Test | Test XSS | Test đảm bảo: các giá trị như <>"& …v.v do người dùng nhập vào sẽ không được output nguyên xi ra HTML | |
| Test cross browser | PC Browser | Tùy theo sự khác nhau của Rendering Engine trên browser, sẽ kiểm tra cái nào có action OK – NG tùy theo Javascript Engine, hoặc bị lệch design | Browser bảo đảm các action |
| Test Cross Browser | Chức năng mobile | Kiểm tra xem các action trên version , vender khác nhau, trên các thiết bị di động đang chayu đúng không | Thiết bị bảo đảm chạy đúng các action |
| Scenario Test | - | Kiểm tra các action tương ứng với từng Scenario thao tác người dùng đã được set trên thực tế. Nếu có xử lý batch ở giữa thì phải viết scenario chứa những scenario đó | User case: Sơ đồ chuyển màn hình |
| Job Flow Test | - | Kiểm tra xem job flow có gặp vấn đề gì khi cài đặt không | Job Flow |
| Test vận hành | - | Kiểm tra vận hành của app, web có chịu được các điều kiện khi dùng trong thực tế không (đặc biệt, phần này gồm cả các phần liên quan tới con người) | Tài liệu ghi trình tự khi vận hành |
| Test xem có tổn hại nào không | - | Kiểm tra : khi xảy ra tổn hại thì việc switch hệ thống, covery/ Degration có xảy các action theo như thiết kế hay không | Tài liệu thiết kế recover |
| Test chức năng | Test tính năng SQL | Đối với các dữ liệu tương ứng trên production: Tiến hành đo thời gian chạy SQL riêng; confirm xem đã thỏa mãn các điều kiện, yêu cầu cần thiết cho tính năng hay chưa. Tiếp nhận kế hoạch chạy, và confirm xem Index đã chuẩn bị có đang được sử dụng hay không? | Các điều kiện cần thiết trong chức năng |
| Test tính năng | Test chức năng riêng lẻ trên từng màn hình | Confirm turn around time trên 1 màn hình có nhỏ hơn giá trị quy định hay không | Các điều kiện cần thiết với tính năng |
| Test tính năng | Test tính năng của từng batch riêng | Confirm turn around time trên 1 màn hình có nhỏ hơn giá trị quy định hay không | Các yêu cầu, điều kiện cần thiết của tính năng |
| Test tính năng | Test Load | Confirm: khi vận hành trên hệ thống, sẽ loading mất bao lâu, có giống với dự toán khi vận hành không? Thời gian turn around có nằm trong phạm vi yêu cầu cho phép không? | Các yêu cầu, điều kiện cần thiết của tính năng |
| Test tính năng | Test Through Put | Check xem khi system thực hiện đồng thời transaction thì việc xử lý sẽ mất bao nhiêu thời gian. | Các yêu cầu, điều kiện cần thiết của tính năng |
| Test tính năng | Test Long-run | Check xem có xảy ra hiện tượng bất thường nào trên hệ thống không khi lượng load lớn trong thời gian dài, leak memory...v.v | Các yêu cầu, điều kiện cần thiết của tính năng |
| Test Migration | - | Thực hiện check action của chương trình Migration. Nếu có kế hoạch back lại thì phải thực hiện theo scenario | Kế hoạch migration |
| Test Scenario Nghiệp vụ | - | Check xem toàn bộ Flow nghiệp vụ đã chạy đúng theo thiết kế trên các hệ thống khác - được liên kết với hệ thống chính hay chưa. | Flow nghiệp vụ |
Còn tiếp...
Link bài gốc:
http://qiita.com/kawasima/items/1fed574e7456edbad727?utm_source=Qiitaニュース&utm_campaign=67034b9192-Qiita_newsletter_237_12_07_2016&utm_medium=email&utm_term=0_e44feaa081-67034b9192-32962049
Người dịch: Thanh Thảo
