Test plan - Kế hoạch kiểm thử (Phần 1)
Testing
30
QA
7
test
8
White

Thiên Hoàng Minh Vũ viết ngày 28/02/2018

1. Định nghĩa

Một kế hoạch kiểm thử dự án phần mềm (test plan) là một tài liệu mô tả các mục tiêu, phạm vi, phương pháp tiếp cận, và tập trung vào nỗ lực kiểm thử phần mềm. Quá trình chuẩn bị test plan là một cách hữu ích để suy nghĩ tới những nỗ lực cần thiết để xác nhận khả năng chấp nhận một sản phẩm phần mềm. Các tài liệu đã hoàn thành sẽ giúp mọi người bên ngoài nhóm test hiểu được 'tại sao''như thế nào' chấp nhận sản phẩm. Nó cần phải hoàn hảo đủ để dùng được nhưng không đủ hoàn hảo vì không ai bên ngoài nhóm test sẽ đọc nó.

Nói một cách khác cho dễ hiểu thì Test Plan là tài liệu tổng quan về việc test 1 project. Scope của project, hướng tiếp cận, STLC(Software Testing Life Cycle), resource và nhân lực cần có, các features cần được test và không phải test, các tool test và môi trường test cần có. Có thể ví test plan là 1 cái xương sống của 1 testing project và là cái được chuẩn bị đầu tiên khi có 1 project.
alt text
Sau đây là một số hạng mục có thể được bao gồm trong một test plan, tùy thuộc vào từng dự án cụ thể:

  • Tiêu đề
  • Định nghĩa version của phần mềm (version release)
  • Lưu lại quá trình hiệu chỉnh tài liệu như tác giả, ngày cập nhật, duyệt
  • Mục lục
  • Mục đích của tài liệu, ý kiến chung
  • Mục tiêu của chi phí kiểm thử (test)
  • Giới thiệu tổng quan về sản phẩm
  • Danh sách tài liệu liên quan như spec, tài liệu thiết kế, các kế hoạch test khác,...
  • Các tiêu chuẩn thích hợp, các yêu cầu hợp lệ
  • Nguồn gốc của các sự thay đổi
  • Relevant naming conventions and identifier conventions
  • Overall software project organization and personnel/contact-info/responsibilties
  • Test organization and personnel/contact-info/responsibilities
  • Assumptions and dependencies
  • Phân tích rủi ro của dự án
  • Các vấn đề ưu tiên và tập trung test
  • Phạm vi và giới hạn test

-Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable

  • Outline of data input equivalence classes, boundary value analysis, error classes
  • Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
  • Test environment validity analysis - differences between the test and production systems and their impact on test validity.
  • Test environment setup and configuration issues
  • Software migration processes
  • Software CM processes
  • Test data setup requirements
  • Database setup requirements
  • Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
  • Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
  • Test tự động - giải thích và tổng quan
  • Các công cụ test được sử sụng, bao gồm các version, bản vá lỗi,...v.v
  • Các qui trình bảo trì và quản lý version của test script/test code
  • Theo dõi và giải quyết vấn đề - Các công cụ và qui trình
  • Các thước đo về test sản phẩm được sử dụng
  • Báo cáo các yêu cầu và khả năng giao test
  • Điều kiện đầu vào và đầu ra của phần mềm
  • Giai đoạn và điều kiện test ban đầu
  • Điều kiện dừng test và test lại
  • Sự bố trí nhân sự
  • Những người cần training trước khi tham gia
  • Nơi test
  • Các tổ chức test bên ngoài sẽ sử dụng và mục đích, trách nhiệm, khả năng hoàn thành, người liên hệ và các vấn đề hợp tác của họ
  • Các vấn đề độc quyền thích hợp, phân loại, bảo mật và bản quyền.
  • Các vấn đề mở
  • Phụ lục - bảng chú giải, các từ viết tắt, ...v.v... ###2. Các bước cơ bản để lập test plan
  • Xác định yêu cầu kiểm tra.
  • Khảo sát rủi ro.
  • Xác định chiến lược kiểm tra.
  • Xác định nhân lực, vật lực cần thiết.
  • Lập kế hoạch chi tiết.
  • Tổng hợp và đưa ra kế hoạch kiểm tra.
  • Xem xét các kế hoạch kiểm tra.

3. Nội dung cơ bản của một test plan

3.1. Chiến lược kiểm tra

  • Chiến lược kiểm tra đưa ra phương pháp tiếp cận để kiểm tra mục tiêu.
  • Chiến lược kiểm tra bao gồm các kỹ thuật được áp dụng và điều kiện để biết khi nào việc kiểm tra hoàn thành.
  • Mô tả các kiểu kiểm tra dùng trong dự án.
  • Có thể liệt kê với mỗi kiểu kiểm tra tương ứng kiểm tra cho chức năng nào.
  • Việc kiểm có thể dừng khi nào.

3.2. Các kỹ thuật kiểm tra:

Mỗi kiểu kiểm tra phải bao gồm các đìều kiện:

  • Kỹ thuật: Mô tả việc kiểm tra như thế nào, những gì sẽ được kiểm tra, các hoạt động chính được thực hiện trong quá trình kiểm tra và các phương pháp đánh giá kết quả.
  • Điều kiện hoàn thành: Xác định chất lượng chương trình được chấp nhận và Thời điểm kiểm tra hoàn tất.

Các vấn đề đặc biệt:
Các vấn đề gây ảnh hưởng đến việc kiểm tra

3.2.1. Functional testing - kiểm tra chức năng
  • Function testing - kiểm tra chức năng
  • User interface testing - kiểm tra giao diện người sử dụng
  • Data & database integrity testing - kiểm tra DL & tích hợp DL
  • Business cycle testing - kiểm tra chu trình nghiệp vụ

    3.2.2. Performance testing - kiểm tra hiệu xuất
  • Performance profiling

  • Load testing

  • Stress testing

  • Volume testing

3.2.3. Security & Access control testing - kiểm tra bảo mật & kiểm soát truy cập
3.2.4. Regression testing – kiểm tra hồi quy

3.3. Môi trường kiểm tra:

Tuỳ vào mỗi giai đoạn Unit test, Intergration test, System test, acceptance test sẽ ứng với môi trường kiểm tra nhất định. Từ đó xác định các yếu tố để xây dựng môi trường kiểm tra, sử dụng như môi trường thật hay tạo môi trường giả lập gần giống với môi trường chạy thật của chương trình.

  • Khi test chạy chương trình bằng bản dịch hay chạy trên code. Thông thường, các giai đoạn System test, Acceptance test phải chạy trên bản dịch

  • Với CSDL thì thông thường, từ Intergration test, ta phải thiết lập CSDL riêng và thiết lập các thông số cho CSDL gần giống hoặc giống hệt như khi chương trình sẽ chạy thật.

  • Điều kiện về mạng: sẽ sử dụng mạng LAN hay Dial up… Thông thường, khi Unit test, có thể sử dụng mạng LAN nhưng khi System test trở đi thì nên sử dụng hệ thống đường truyền giống như hoặc gần giống như môi trường chạy thật.

  • Mô hình sẽ cài đặt chương trình test: số lượng máy chủ, máy trạm; việc chia tách các server, các máy trạm, việc cài đặt các domain … Thông thường, trong Unit test có thể sử dụng viếc thiết lập như khi lập trình, nhưng khi System test trở đi, phải chú ý thiết lập sao cho gần giống mô hình sẽ chạy trong thực tế nhất.

Nguồn: Tổng hợp + kinh nghiệm xác nhận

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Thiên Hoàng Minh Vũ

24 bài viết.
61 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
38 3
(Ảnh) Người dẫn lại bài này cũng được phen lao đao khi lục lọi lại mớ kiến thức cơ bản cũ. Đối với sự nghiệp của một coder thì phải được thực hiện...
Thiên Hoàng Minh Vũ viết 5 tháng trước
38 3
White
13 0
Xưa, giang hồ đồn đại rằng: "Tin học và ngoại ngữ, trong thiên hạ ai nắm được 1 trong 2 thì có thể có được thiên hạ" :v Ấy mà nay, tiểu mỗ đang có ...
Thiên Hoàng Minh Vũ viết 9 tháng trước
13 0
White
13 0
vietnamxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.vn Em, em, xem cho chị cái tên đặt thế này đủ hay chưa? =)) Bần mỗ nghẹn cmn lời luôn với vấ...
Thiên Hoàng Minh Vũ viết 9 tháng trước
13 0
Bài viết liên quan
Male avatar
0 0
Swift TestDriven Development (TDD) Chapter 1 Part 2 Understanding TDD ===== Updated ngày 30/06 Updated một chút: Vì những bất tiện và không rõ r...
Bùi Khánh Duy viết 3 tháng trước
0 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
24 bài viết.
61 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!