Test Plan là một tài liệu chi tiết mô tả các khu vực và hoạt động kiểm thử phần mềm. Nó phác thảo chiến lược thử nghiệm, mục tiêu, lịch trình thử nghiệm, các nguồn lực cần thiết (nhân lực, phần mềm và phần cứng), ước tính thử nghiệm và phân phối thử nghiệm.
Kế hoạch thử nghiệm là cơ sở của mọi thử nghiệm phần mềm. Đây là hoạt động quan trọng nhất đảm bảo sự sẵn có của tất cả các danh sách các hoạt động đã được lên kế hoạch theo một trình tự thích hợp.
Các bài viết liên quan:
Test Plan là một khuôn mẫu để tiến hành các hoạt động kiểm thử phần mềm như một quá trình xác định được giám sát và kiểm soát hoàn toàn bởi người quản lý kiểm thử. Test Plan được chuẩn bị bởi Trưởng nhóm kiểm tra (60%), Giám đốc kiểm tra (20%) và kỹ sư kiểm tra (20%).
Các loại Test Plan
Có ba loại Test Plan
- Master Test Plan
- Phase Test Plan
- Testing Type Specific Test Plans
Master Test Plan
Test Plan tổng thể là một loại Test Plan có nhiều cấp độ kiểm tra. Nó bao gồm một chiến lược thử nghiệm hoàn chỉnh.
Phase Test Plan
Test Plan giai đoạn là một loại Test Plan đề cập đến bất kỳ một giai đoạn nào của chiến lược kiểm tra. Ví dụ: danh sách các công cụ, danh sách các trường hợp thử nghiệm, v.v.
Testing Type Specific Test Plans
Kế hoạch thử nghiệm cụ thể được thiết kế cho các loại thử nghiệm chính như thử nghiệm bảo mật, thử nghiệm tải, thử nghiệm hiệu suất, v.v. Nói cách khác, một kế hoạch thử nghiệm cụ thể được thiết kế cho thử nghiệm phi chức năng.
Xem thêm Marketing Plan (Kế hoạch marketing)
Cách viết Test Plan
Lập Test Plan là nhiệm vụ quan trọng nhất của quá trình quản lý kiểm tra. Theo IEEE 829, hãy làm theo bảy bước sau để chuẩn bị Test Plan.
- Đầu tiên, hãy phân tích cấu trúc và kiến trúc của sản phẩm.
- Bây giờ hãy thiết kế chiến lược kiểm tra.
- Xác định tất cả các mục tiêu kiểm tra.
- Xác định khu vực thử nghiệm.
- Xác định tất cả các tài nguyên có thể sử dụng được.
- Lên lịch cho tất cả các hoạt động một cách thích hợp.
- Xác định tất cả các Sản phẩm Thử nghiệm.
- Kiểm tra các thành phần hoặc thuộc tính của kế hoạch
- Kế hoạch thử nghiệm bao gồm các phần khác nhau, giúp chúng tôi thu được toàn bộ hoạt động thử nghiệm.
Mục tiêu: Nó bao gồm thông tin về các mô-đun, tính năng, dữ liệu thử nghiệm, v.v., cho biết mục tiêu của ứng dụng có nghĩa là hành vi ứng dụng, mục tiêu, v.v.
Phạm vi: Nó chứa thông tin cần được kiểm tra tương ứng với một ứng dụng. Phạm vi có thể được chia thành hai phần:
- In scope:: Đây là những mô-đun cần được kiểm tra một cách nghiêm ngặt (chi tiết).
- Out scope: Đây là những mô-đun, không cần phải kiểm tra nghiêm ngặt.
Ví dụ: Giả sử chúng ta có một ứng dụng Gmail để kiểm tra, trong đó các tính năng sẽ được kiểm tra như Soạn thư, Mục đã gửi, Hộp thư đến, Thư nháp và các tính năng không được kiểm tra như Trợ giúp, v.v. Điều đó có nghĩa là trong giai đoạn lập kế hoạch, chúng tôi sẽ quyết định rằng chức năng nào phải được kiểm tra hay không dựa trên thời hạn đưa ra trong sản phẩm.
Bây giờ chúng ta quyết định tính năng nào không được thử nghiệm như thế nào?
Chúng tôi có các khía cạnh sau đây để chúng tôi có thể quyết định tính năng nào không được thử nghiệm:
- Như chúng ta thấy ở trên, các tính năng Trợ giúp sẽ không được thử nghiệm, vì nó được viết và phát triển bởi người viết kỹ thuật và được đánh giá bởi một người viết chuyên nghiệp khác.
- Giả sử rằng chúng ta có một ứng dụng có các tính năng P, Q, R và S, các tính năng này cần được phát triển dựa trên các yêu cầu. Nhưng ở đây, tính năng S đã được một số công ty khác thiết kế và sử dụng. Vì vậy, nhóm phát triển sẽ mua S từ công ty đó và tích hợp với các tính năng bổ sung như P, Q và R.
Bây giờ, chúng tôi sẽ không thực hiện kiểm tra chức năng trên tính năng S vì nó đã được sử dụng trong thời gian thực. Nhưng chúng tôi sẽ thực hiện kiểm tra tích hợp và kiểm tra hệ thống giữa các tính năng P, Q, R và S vì các tính năng mới có thể không hoạt động chính xác với tính năng S như chúng ta có thể thấy trong hình ảnh bên dưới:
Giả sử trong lần phát hành đầu tiên của sản phẩm, các yếu tố đã được phát triển, chẳng hạn như P, Q, R, S, T, U, V, W… ..X, Y, Z. Bây giờ khách hàng sẽ cung cấp các yêu cầu cho các tính năng mới cải tiến sản phẩm trong bản phát hành thứ hai và các tính năng mới là A1, B2, C3, D4 và E5.
Sau đó, chúng tôi sẽ viết phạm vi trong kế hoạch thử nghiệm như
Scope
Các tính năng được kiểm tra
A1, B2, C3, D4, E5 (tính năng mới)
P, Q, R, S, T
Các tính năng không được thử nghiệm
W… ..X, Y, Z
Do đó, chúng tôi sẽ kiểm tra các tính năng mới trước và sau đó tiếp tục với các tính năng cũ vì điều đó có thể bị ảnh hưởng sau khi thêm các tính năng mới, có nghĩa là nó cũng sẽ ảnh hưởng đến các khu vực tác động, vì vậy chúng tôi sẽ thực hiện một vòng kiểm tra hồi quy cho P, Q , Các tính năng R…, T.
Xem thêm Quy trình Test case review trong kiểm thử phần mềm
Phương pháp kiểm tra:
Nó chứa thông tin về việc thực hiện một loại thử nghiệm khác như thử nghiệm chức năng, thử nghiệm tích hợp và thử nghiệm hệ thống, v.v. trên ứng dụng. Trong phần này, chúng tôi sẽ quyết định loại thử nghiệm nào; chúng tôi sẽ thực hiện trên các tính năng khác nhau dựa trên yêu cầu của ứng dụng. Và ở đây, chúng ta cũng nên xác định rằng chúng ta sẽ sử dụng loại thử nghiệm nào trong các phương pháp thử nghiệm để mọi người, như ban quản lý, nhóm phát triển và nhóm thử nghiệm có thể hiểu dễ dàng vì các điều khoản thử nghiệm không phải là tiêu chuẩn.
Ví dụ: đối với ứng dụng độc lập
chẳng hạn như Adobe Photoshop, chúng tôi sẽ thực hiện các loại kiểm tra sau:
Smoke testing → Functional testing → Integration testing →System testing →Adhoc testing → Compatibility testing → Regression testing→ Globalization testing → Accessibility testing → Usability testing → Reliability testing → Recovery testing → Installation or Uninstallation testing
Và giả sử chúng tôi phải kiểm tra ứng dụng https://www.jeevansathi.com/, vì vậy chúng tôi sẽ thực hiện các loại kiểm tra sau:
Cách tiếp cận
Thuộc tính này được sử dụng để mô tả luồng của ứng dụng trong khi thực hiện thử nghiệm và để tham khảo trong tương lai.
Chúng tôi có thể hiểu quy trình của ứng dụng với sự trợ giúp của các khía cạnh dưới đây:
- Bằng cách viết các kịch bản cấp cao
- Bằng cách viết biểu đồ luồng
- Bằng cách viết các kịch bản cấp cao
Ví dụ: giả sử chúng tôi đang thử nghiệm ứng dụng Gmail:
Đăng nhập vào Gmail- gửi email và kiểm tra xem nó có ở trang Các mục đã gửi hay không
Đăng nhập vào …….
……
…….
Chúng tôi viết bài này để mô tả các phương pháp tiếp cận phải được thực hiện để thử nghiệm sản phẩm và chỉ dành cho các tính năng quan trọng mà chúng tôi sẽ viết các tình huống cấp cao. Ở đây, chúng tôi sẽ không tập trung vào việc đề cập đến tất cả các tình huống vì nó có thể được quyết định bởi kỹ sư thử nghiệm cụ thể rằng tính năng nào phải được thử nghiệm hay không.
Biểu đồ luồng được viết bởi vì việc viết các kịch bản cấp cao là quá trình tốn thời gian, như chúng ta có thể thấy trong hình ảnh dưới đây:
Chúng tôi đang tạo biểu đồ luồng để tạo ra những lợi ích sau đây, chẳng hạn như:
- Bảo hiểm dễ dàng
- Hợp nhất rất dễ dàng
Cách tiếp cận có thể được phân thành hai phần như sau:
- Cách tiếp cận từ trên xuống dưới
- Phương pháp tiếp cận từ dưới lên trên
Giả thiết
Nó chứa thông tin về một vấn đề hoặc sự cố có thể xảy ra trong quá trình thử nghiệm và khi chúng tôi viết kế hoạch thử nghiệm, các giả định được đảm bảo sẽ được đưa ra như tài nguyên và công nghệ, v.v.
Rủi ro
Đây là những thách thức mà chúng ta cần phải đối mặt để kiểm tra ứng dụng trong bản phát hành hiện tại và nếu các giả định sẽ thất bại thì rủi ro sẽ đi kèm.
Ví dụ, hiệu ứng cho một ứng dụng, ngày phát hành bị hoãn lại.
Xem thêm Cách tạo test case thủ công sử dụng Selenium IDE
Kế hoạch giảm thiểu hoặc Kế hoạch dự phòng
Nó là một kế hoạch dự phòng được chuẩn bị để khắc phục những rủi ro hoặc vấn đề.
Chúng ta hãy xem một ví dụ về giả định, rủi ro và kế hoạch dự phòng cùng với nhau vì chúng có liên quan đến nhau.
Trong bất kỳ sản phẩm nào, giả định chúng tôi sẽ đưa ra là cả 3 kỹ sư kiểm tra sẽ ở đó cho đến khi hoàn thành sản phẩm và mỗi người trong số họ được giao các mô-đun khác nhau như P, Q và R. Trong trường hợp cụ thể này, rủi ro có thể là nếu kỹ sư thử nghiệm rời khỏi dự án giữa chừng.
Do đó, kế hoạch dự phòng sẽ được chỉ định một chủ sở hữu chính và cấp dưới cho mỗi đối tượng địa lý. Vì vậy, nếu một kỹ sư thử nghiệm rời đi, chủ sở hữu cấp dưới sẽ tiếp quản tính năng cụ thể đó và cũng giúp kỹ sư thử nghiệm mới, để họ có thể hiểu các mô-đun được giao của họ.
Các giả định, rủi ro và kế hoạch giảm thiểu hoặc dự phòng luôn chính xác đối với sản phẩm. Các loại rủi ro như sau:
- Quan điểm khách hàng
- Phương pháp tiếp cận nguồn lực
- Ý kiến kỹ thuật
Vai trò & Trách nhiệm
Nó xác định nhiệm vụ hoàn chỉnh cần được thực hiện bởi toàn bộ nhóm thử nghiệm. Khi một dự án lớn đến, thì Người quản lý kiểm thử là người viết Test Plan. Nếu có 3-4 dự án nhỏ, thì người quản lý kiểm thử sẽ chỉ định từng dự án cho mỗi Trưởng nhóm kiểm tra. Và sau đó, trưởng nhóm kiểm tra viết Test Plan cho dự án mà anh ta / cô ta được giao.
Hãy xem một ví dụ mà chúng ta sẽ hiểu vai trò và trách nhiệm của Người quản lý thử nghiệm, trưởng nhóm thử nghiệm và các kỹ sư thử nghiệm.
Vai trò: Quản lý thử nghiệm
Tên: Ryan
Nhiệm vụ:
- Chuẩn bị (viết và xem lại) Test Plan
- Tiến hành cuộc họp với nhóm phát triển
- Tiến hành cuộc họp với nhóm thử nghiệm
- Tiến hành cuộc họp với khách hàng
- Tiến hành một cuộc họp đứng hàng tháng
- Ký tên vào ghi chú phát hành
- Xử lý các vấn đề và báo cáo
Vai trò: Trưởng nhóm kiểm tra
Tên: Harvey
Nhiệm vụ:
- Chuẩn bị (viết và xem lại) Test Plan
- Tiến hành cuộc họp đứng lên hàng ngày
- Xem xét và phê duyệt trường hợp thử nghiệm
- Chuẩn bị RTM và Báo cáo
- Chỉ định mô-đun
- Lịch xử lý
Vai trò: Kỹ sư thử nghiệm 1, Kỹ sư thử nghiệm 2 và Kỹ sư thử nghiệm 3
Tên: Louis, Jessica, Donna
Chỉ định các mô-đun: M1, M2 và M3
Nhiệm vụ:
- Viết, Xem lại và Thực thi các tài liệu thử nghiệm bao gồm trường hợp thử nghiệm và các kịch bản thử nghiệm
- Đọc, xem xét, hiểu và phân tích yêu cầu
- Viết quy trình của ứng dụng
- Thực hiện test case
- RTM cho các mô-đun tương ứng
- Theo dõi khiếm khuyết
- Chuẩn bị báo cáo thực hiện kiểm tra và thông báo cho Trưởng nhóm kiểm tra.
Lịch trình
Nó được sử dụng để giải thích thời gian để làm việc, cần phải thực hiện hoặc thuộc tính này bao gồm thời điểm chính xác mỗi hành động thử nghiệm
ivity nên bắt đầu và kết thúc? Và dữ liệu chính xác cũng được đề cập cho mọi hoạt động thử nghiệm cho một ngày cụ thể.
Vì vậy, như chúng ta có thể thấy trong hình ảnh dưới đây rằng đối với hoạt động cụ thể, sẽ có ngày bắt đầu và ngày kết thúc; đối với mỗi thử nghiệm đối với một bản dựng cụ thể, sẽ có ngày được chỉ định.
Ví dụ
- Viết các trường hợp thử nghiệm
- Quy trình thực thi
Theo dõi khiếm khuyết
Nó thường được thực hiện với sự trợ giúp của các công cụ vì chúng tôi không thể theo dõi trạng thái của từng lỗi theo cách thủ công. Và chúng tôi cũng nhận xét về cách chúng tôi giao tiếp các lỗi được xác định trong quá trình thử nghiệm và gửi lại cho nhóm phát triển và cách nhóm phát triển sẽ trả lời. Ở đây chúng tôi cũng đề cập đến mức độ ưu tiên của các lỗi như cao, trung bình và thấp.
Sau đây là các khía cạnh khác nhau của việc theo dõi lỗi:
- Các kỹ thuật để theo dõi lỗi
… ..
……
……
……
- Công cụ theo dõi lỗi
Chúng tôi có thể nhận xét về tên của công cụ mà chúng tôi sẽ sử dụng để theo dõi lỗi. Một số công cụ theo dõi lỗi được sử dụng phổ biến nhất là Jira, Bugzilla, Mantis và Trac, v.v. <
- Mức độ nghiêm trọng
Mức độ nghiêm trọng có thể như sau:
Trình chặn hoặc trình chiếu
… ..
… .. (Giải thích nó bằng một ví dụ trong kế hoạch thử nghiệm)
Ví dụ, sẽ có một khiếm khuyết trong mô-đun; chúng tôi không thể tiến xa hơn để kiểm tra các mô-đun khác vì nếu lỗi bị chặn, chúng tôi có thể tiến hành kiểm tra các mô-đun khác.
Phê bình
……
… .. (Giải thích nó bằng một ví dụ trong kế hoạch thử nghiệm)
Trong tình huống này, các khuyết tật sẽ ảnh hưởng đến việc kinh doanh.
Chính
….
…. (Giải thích nó bằng một ví dụ trong kế hoạch thử nghiệm)
Diễn viên phụ
… ..
… .. (Giải thích nó bằng một ví dụ trong kế hoạch thử nghiệm)
Những khiếm khuyết này ảnh hưởng đến giao diện của ứng dụng.
- Sự ưu tiên
P1 cao
… ..
Trung bình-P2
… ..
P3 thấp
… ..
… ..
P4
Do đó, dựa trên mức độ ưu tiên của các lỗi như cao, trung bình và thấp, chúng tôi sẽ phân loại nó thành P1, P2, P3 và P4.
Môi trường thử nghiệm
Đây là những môi trường mà chúng tôi sẽ kiểm tra ứng dụng và ở đây chúng tôi có hai loại môi trường, đó là cấu hình phần mềm và phần cứng.
Cấu hình phần mềm có nghĩa là thông tin chi tiết về các Hệ điều hành khác nhau như Windows, Linux, UNIX và Mac và các Trình duyệt khác nhau như Google Chrome, Firefox, Opera, Internet Explorer, v.v.
Và cấu hình phần cứng có nghĩa là thông tin về các kích thước khác nhau của RAM, ROM và Bộ xử lý.
Ví dụ
Phần mềm bao gồm những điều sau:
Server
Lưu ý: Các máy chủ trên là các lần phục vụ được nhóm thử nghiệm sử dụng để kiểm tra ứng dụng.
Khách hàng
Lưu ý: Các chi tiết trên cung cấp các hệ điều hành và trình duyệt khác nhau mà nhóm thử nghiệm sẽ kiểm tra ứng dụng.
Phần cứng bao gồm những thứ sau:
Nhóm thử nghiệm có thể sử dụng máy chủ cụ thể này để kiểm tra ứng dụng của họ.
Khách hàng:
Nó có cấu hình như sau:
- Bộ xử lý Intal2GHz
- RAM 2GB
…. ….
Lưu ý: Nó sẽ cung cấp cấu hình của hệ thống của các kỹ sư thử nghiệm là nhóm thử nghiệm.
Quy trình cài đặt phần mềm
……
… ..
… ..
Nhóm phát triển sẽ cung cấp cấu hình cách cài đặt phần mềm. Nếu nhóm phát triển vẫn chưa cung cấp quy trình, thì chúng tôi sẽ viết nó là Phát triển dựa trên nhiệm vụ (TBD) trong kế hoạch thử nghiệm.
Tiêu chí vào và ra
Đây là điều kiện cần, cần được thỏa mãn trước khi bắt đầu và dừng quá trình thử nghiệm.
- Tiêu chí đầu vào
Tiêu chí đầu vào bao gồm các điều kiện sau:
- Kiểm tra white box sẽ được kết thúc.
- Hiểu và phân tích yêu cầu và chuẩn bị các tài liệu kiểm tra hoặc khi các tài liệu kiểm tra đã sẵn sàng.
- Dữ liệu thử nghiệm phải sẵn sàng.
- Xây dựng hoặc ứng dụng phải được chuẩn bị
- Các mô-đun hoặc tính năng cần được chỉ định cho các kỹ sư thử nghiệm khác nhau.
- Nguồn lực cần thiết phải sẵn sàng.
- Tiêu chí đầu ra
Tiêu chí đầu ra bao gồm các điều kiện sau:
- Khi tất cả các trường hợp thử nghiệm được thực thi.
- Hầu hết các trường hợp thử nghiệm phải được thông qua.
- Phụ thuộc vào mức độ nghiêm trọng của các lỗi, có nghĩa là không được có bất kỳ trình chặn hoặc lỗi lớn nào, trong khi một số lỗi nhỏ tồn tại.
Trước khi chúng tôi bắt đầu thực hiện kiểm tra chức năng, tất cả các Tiêu chí đầu vào ở trên phải được tuân thủ. Sau khi chúng tôi thực hiện kiểm tra chức năng và trước khi chúng tôi thực hiện kiểm tra tích hợp, thì tiêu chí Thoát của kiểm tra chức năng nên được tuân theo vì% tiêu chí thoát được quyết định bởi cuộc họp với cả người quản lý phát triển và kiểm thử vì sự cộng tác của họ có thể đạt được tỷ lệ phần trăm. Nhưng nếu các tiêu chí thoát của kiểm thử chức năng không được tuân thủ, thì chúng tôi không thể tiếp tục kiểm tra tích hợp.
Ở đây dựa trên mức độ nghiêm trọng của lỗi có nghĩa là nhóm thử nghiệm sẽ quyết định điều đó để tiến hành thêm cho các giai đoạn tiếp theo.
Tự động hóa kiểm tra
Trong việc này, chúng tôi sẽ quyết định những điều sau:
Tính năng nào phải tự động và không được tự động hóa?
Chúng tôi sẽ sử dụng công cụ tự động hóa thử nghiệm nào trên khuôn khổ tự động hóa nào?
Chúng tôi tự động hóa trường hợp thử nghiệm chỉ sau bản phát hành đầu tiên.
Đến đây câu hỏi đặt ra là chúng ta sẽ quyết định kiểm tra tính năng nào trên cơ sở nào?
Trong hình ảnh trên, như chúng ta có thể thấy rằng các tính năng thường được sử dụng nhất cần phải kiểm tra lại nhiều lần. Giả sử chúng ta phải kiểm tra ứng dụng Gmail trong đó các tính năng cần thiết là Soạn thư, Mục đã gửi và Hộp thư đến. Vì vậy, chúng tôi sẽ kiểm tra các tính năng này bởi vì trong khi thực hiện kiểm tra thủ công, nó sẽ mất nhiều thời gian hơn, và nó cũng trở thành một công việc đơn điệu.
Bây giờ, làm thế nào để chúng tôi quyết định tính năng nào sẽ không được thử nghiệm?
Giả sử tính năng Trợ giúp của ứng dụng Gmail không được kiểm tra lại vì các tính năng này không được sử dụng thường xuyên nên chúng ta không cần kiểm tra thường xuyên.
Nhưng nếu một số tính năng không ổn định và có nhiều lỗi, có nghĩa là chúng tôi sẽ không kiểm tra các tính năng đó vì nó phải được kiểm tra lại nhiều lần trong khi kiểm tra thủ công.
Nếu có một tính năng nào đó phải được kiểm tra thường xuyên, nhưng chúng tôi đang mong đợi sự thay đổi yêu cầu cho tính năng đó, vì vậy chúng tôi không kiểm tra nó vì việc thay đổi các trường hợp kiểm tra thủ công sẽ thoải mái hơn so với thay đổi trong tập lệnh kiểm tra tự động hóa.
Ước tính nỗ lực
Trong điều này, chúng tôi sẽ lập kế hoạch nỗ lực cần được áp dụng bởi mọi thành viên trong nhóm.
Có thể phân phối thử nghiệm
Đây là những tài liệu là kết quả đầu ra từ nhóm thử nghiệm, chúng tôi đã bàn giao cho khách hàng cùng với sản phẩm. Nó bao gồm những điều sau:
- Test Plan
- Các trường hợp kiểm tra
- Tập lệnh thử nghiệm
- RTM (Ma trận xác định nguồn gốc yêu cầu)
- Báo cáo khiếm khuyết
- Báo cáo thực thi kiểm tra
- Đồ thị và số liệu
- Ghi chú phát hành
Đồ thị và Chỉ số
Đồ thị
Trong phần này, chúng tôi sẽ thảo luận về các loại biểu đồ mà chúng tôi sẽ gửi, đồng thời chúng tôi cũng sẽ cung cấp mẫu của mỗi biểu đồ.
Như chúng ta có thể thấy, chúng ta có năm biểu đồ khác nhau thể hiện các khía cạnh khác nhau của quá trình thử nghiệm.
Biểu đồ 1: Trong phần này, chúng tôi sẽ chỉ ra có bao nhiêu lỗi đã được xác định và bao nhiêu lỗi đã được sửa trong mỗi mô-đun.
Đồ thị 2: Hình một cho thấy có bao nhiêu lỗi nghiêm trọng, lớn và nhỏ đã được xác định cho mọi mô-đun và bao nhiêu lỗi đã được sửa cho các mô-đun tương ứng của chúng.
Biểu đồ 3: Trong biểu đồ cụ thể này, chúng tôi biểu thị biểu đồ xây dựng khôn ngoan, có nghĩa là trong mỗi bản dựng, có bao nhiêu lỗi đã được xác định và sửa cho mọi mô-đun. Dựa trên mô-đun, chúng tôi đã xác định được các lỗi. Chúng tôi sẽ thêm R để hiển thị số lượng khuyết tật trong P và Q, và chúng tôi cũng thêm S để hiển thị các khuyết tật trong P, Q và R.
Đồ thị 4: Người dẫn đầu thử nghiệm sẽ thiết kế đồ thị phân tích Xu hướng lỗi được tạo hàng tháng và gửi cho Ban quản lý. Và nó giống như dự đoán được thực hiện ở cuối sản phẩm. Và tại đây, chúng tôi cũng có thể đánh giá các bản sửa lỗi khi chúng tôi có thể quan sát thấy vòng cung có xu hướng đi lên trong hình ảnh bên dưới.
Graph5: Test Manager đã thiết kế loại đồ thị này. Biểu đồ này nhằm mục đích hiểu được khoảng cách trong việc đánh giá các lỗi và các lỗi thực tế đã xảy ra và biểu đồ này cũng giúp cải thiện việc đánh giá các lỗi trong tương lai.
Số liệu
Như ở trên, chúng tôi tạo biểu đồ phân bố lỗi, trong hình 1 và với sự trợ giúp của dữ liệu đề cập ở trên, chúng tôi cũng sẽ thiết kế các số liệu.
Ví dụ
Trong hình trên, chúng tôi giữ lại hồ sơ của tất cả các kỹ sư thử nghiệm trong một dự án cụ thể và có bao nhiêu lỗi đã được xác định và sửa chữa. Chúng tôi cũng có thể sử dụng dữ liệu này để phân tích trong tương lai. Khi có yêu cầu mới, chúng tôi có thể quyết định ai sẽ cung cấp tính năng thử thách để kiểm tra dựa trên số lượng lỗi mà họ đã tìm thấy trước đó theo các chỉ số ở trên. Và chúng tôi sẽ ở trong một tình huống tốt hơn để biết ai có thể xử lý rất tốt các tính năng có vấn đề và tìm ra số lượng lỗi tối đa.
Ghi chú phát hành: Đây là một tài liệu được chuẩn bị trong quá trình phát hành sản phẩm và được ký bởi Người quản lý thử nghiệm.
Trong hình ảnh dưới đây, chúng ta có thể thấy rằng sản phẩm cuối cùng được phát triển và triển khai cho khách hàng, và tên bản phát hành mới nhất là Beta.
Ghi chú phát hành bao gồm những nội dung sau:
- Hướng dẫn sử dụng.
- Danh sách các khuyết tật đang chờ xử lý và mở.
- Danh sách các tính năng được thêm, sửa đổi và xóa.
- Danh sách nền tảng (Hệ điều hành, Phần cứng, Trình duyệt) mà sản phẩm được thử nghiệm.
- Nền tảng mà sản phẩm không được thử nghiệm.
- Danh sách các lỗi đã được sửa trong bản phát hành hiện tại và danh sách các lỗi đã sửa trong bản phát hành trước.
- Quá trình cài đặt
- Các phiên bản của phần mềm
Ví dụ
Giả sử rằng Beta là bản phát hành thứ hai của ứng dụng sau khi bản Alpha đầu tiên được phát hành. Một số lỗi được xác định trong bản phát hành đầu tiên và đã được sửa trong bản phát hành sau. Và ở đây, chúng tôi cũng sẽ chỉ ra danh sách các tính năng mới được thêm, sửa đổi và xóa từ bản phát hành alpha đến bản phát hành beta.
Mẫu
Phần này chứa tất cả các mẫu cho các tài liệu sẽ được sử dụng trong sản phẩm,
và tất cả các kỹ sư thử nghiệm sẽ chỉ sử dụng các mẫu này trong dự án để duy trì tính nhất quán của sản phẩm. Ở đây, chúng tôi có các loại mẫu khác nhau được sử dụng trong toàn bộ quá trình thử nghiệm, chẳng hạn như:
- Mẫu trường hợp thử nghiệm
- Mẫu đánh giá trường hợp thử nghiệm
- Mẫu RTM
- Mẫu báo cáo lỗi
- Báo cáo thực hiện kiểm tra
Hãy cho chúng tôi xem một mẫu tài liệu kế hoạch thử nghiệm
Trang-1
Trang3-trang18
Trang-20
Trong Trang 1, chúng tôi chủ yếu chỉ điền vào các trường Phiên bản, Tác giả, Nhận xét và Được Người đánh giá, và sau khi người quản lý phê duyệt, chúng tôi sẽ đề cập đến chi tiết trong các trường Người được Phê duyệt và Ngày Phê duyệt.
Phần lớn kế hoạch thử nghiệm được Người quản lý thử nghiệm phê duyệt và các kỹ sư thử nghiệm chỉ xem xét nó. Và khi các tính năng mới xuất hiện, chúng tôi sẽ sửa đổi kế hoạch thử nghiệm và thực hiện các sửa đổi cần thiết trong trường Phiên bản, sau đó nó sẽ được gửi lại để người quản lý xem xét, cập nhật và phê duyệt thêm. Test Plan phải được cập nhật bất cứ khi nào có bất kỳ thay đổi nào xảy ra. Ở trang 20, Tài liệu tham khảo nêu rõ các chi tiết về tất cả các tài liệu mà chúng tôi sẽ sử dụng để viết tài liệu Test Plan.
Ghi chú:
Ai viết Test Plan?
- Test Lead→60%
- Test Manager→20%
- Test Engineer→20%
Do đó, như chúng ta có thể thấy ở trên rằng trong 60% sản phẩm, Test Plan được viết bởi Trưởng nhóm kiểm tra.
Ai là người đánh giá Test Plan?
- Khách hàng tiềm năng kiểm tra
- Người quản lý thử nghiệm
- Kỹ sư thử nghiệm
- Khách hàng
- Nhóm phát triển
Kỹ sư kiểm tra xem xét Test Plan theo quan điểm mô-đun của họ và người quản lý kiểm tra xem xét Test Plan dựa trên ý kiến của khách hàng.
Ai phê duyệt Kế hoạch thử nghiệm?
- Khách hàng
- Người quản lý thử nghiệm
Ai viết test case?
- Khách hàng tiềm năng kiểm tra
- Kỹ sư thử nghiệm
Ai xem xét trường hợp thử nghiệm?
- Kỹ sư thử nghiệm
- Khách hàng tiềm năng kiểm tra
- Khách hàng
- Nhóm phát triển
Ai phê duyệt các trường hợp Kiểm thử?
- Người quản lý thử nghiệm
- Khách hàng tiềm năng kiểm tra
- Khách hàng
Nguyên tắc Test Plan
- Thu gọn kế hoạch thử nghiệm của bạn.
- Tránh chồng chéo và dư thừa.
- Nếu bạn nghĩ rằng bạn không cần một phần đã được đề cập ở trên, hãy xóa phần đó và tiếp tục.
- Hãy cụ thể. Ví dụ: khi bạn chỉ định một hệ thống phần mềm là một phần của môi trường thử nghiệm, thì hãy đề cập đến phiên bản phần mềm thay vì chỉ tên.
- Tránh các đoạn văn dài dòng.
- Sử dụng danh sách và bảng nếu có thể.
- Cập nhật kế hoạch khi cần thiết.
- Không sử dụng một tài liệu lỗi thời và không sử dụng.
Tầm quan trọng của Test Plan
- Test Plan đưa ra định hướng cho suy nghĩ của chúng tôi. Đây giống như một cuốn sách quy tắc, cần phải tuân theo.
- Test Plan giúp xác định những nỗ lực cần thiết để xác nhận chất lượng của ứng dụng phần mềm được kiểm tra.
- Test Plan giúp những người đó hiểu các chi tiết kiểm tra có liên quan đến bên ngoài như nhà phát triển, người quản lý doanh nghiệp, khách hàng, v.v.
- Các khía cạnh quan trọng như lịch trình kiểm tra, chiến lược kiểm tra, phạm vi kiểm tra, v.v. được ghi lại trong Test Plan để nhóm quản lý có thể xem xét chúng và sử dụng lại chúng cho các dự án tương tự khác.
Các câu hỏi phổ biến về test plan
Dưới đây là một số câu hỏi phổ biến về test plan trong quá trình kiểm thử phần mềm:
- Test plan là gì?
- Test plan là tài liệu quy định kế hoạch, phạm vi, tiêu chí và kế hoạch kiểm thử cho một dự án phần mềm.
- Mục đích của test plan là gì?
- Mục đích của test plan là đảm bảo rằng việc kiểm thử được thực hiện một cách toàn diện và đáp ứng được các yêu cầu chất lượng của phần mềm.
- Test plan bao gồm những phần nào?
- Test plan bao gồm các phần như mô tả về dự án, mục tiêu kiểm thử, kế hoạch kiểm thử, phạm vi kiểm thử, tài nguyên kiểm thử, tiêu chuẩn kiểm thử, danh sách ca kiểm thử, danh sách các trường hợp kiểm thử, tiến độ kiểm thử và kế hoạch quản lý rủi ro.
- Ai thường là người viết test plan?
- Người viết test plan thường là nhà kiểm thử hoặc người phụ trách kiểm thử trong dự án.
- Test plan được viết khi nào trong quá trình phát triển phần mềm?
- Test plan được viết trong giai đoạn lập kế hoạch của quá trình phát triển phần mềm, thường là sau khi kế hoạch dự án được phê duyệt và trước khi bắt đầu thực hiện kiểm thử.
- Test plan cần được cập nhật như thế nào?
- Test plan cần được cập nhật liên tục trong quá trình thực hiện kiểm thử để đảm bảo rằng nó vẫn phù hợp với tình hình thực tế của dự án và các yêu cầu chất lượng của phần mềm.
- Test plan khác với test case như thế nào?
- Test plan và test case là hai tài liệu khác nhau trong quá trình kiểm thử phần mềm. Test plan quy định kế hoạch kiểm thử cho toàn bộ dự án, trong khi test case là các tài liệu mô tả chi tiết về từng ca kiểm thử và các bước thực hiện kiểm thử.
nói tiếp đi
- Làm thế nào để đánh giá hiệu quả của một test plan?
Để đánh giá hiệu quả của một test plan, ta có thể xem xét một số yếu tố sau đây:
- Sự hoàn thiện: Test plan có đầy đủ các thông tin về scope, test strategy, test schedule, test deliverables, test environment,… hay không?
- Độ phủ: Test plan đã đảm bảo rằng tất cả các kịch bản, tình huống và chức năng quan trọng của phần mềm đều được kiểm thử và đảm bảo độ phủ của các test case đạt yêu cầu?
- Độ tin cậy: Test plan đã sử dụng đủ các kỹ thuật và tiêu chuẩn kiểm thử để đảm bảo độ tin cậy của phần mềm được kiểm thử?
- Độ tương thích: Test plan đã đảm bảo độ tương thích của phần mềm được kiểm thử với các nền tảng và môi trường khác nhau?
- Thời gian và kinh phí: Test plan đã đảm bảo sử dụng thời gian và kinh phí một cách hợp lý và hiệu quả?
- Làm thế nào để viết một test plan?
Để viết một test plan, ta có thể thực hiện các bước sau:
- Xác định yêu cầu kiểm thử: Tìm hiểu yêu cầu, mục tiêu và phạm vi kiểm thử từ phần mềm được xây dựng.
- Xác định phạm vi kiểm thử: Xác định các tính năng, chức năng và các kịch bản kiểm thử cần được thực hiện.
- Xác định kế hoạch kiểm thử: Xác định chiến lược, phương pháp và kế hoạch kiểm thử để đảm bảo rằng phần mềm được kiểm thử đầy đủ và hiệu quả.
- Xác định nguồn lực: Xác định nguồn lực (nhân lực, thiết bị và phần mềm) cần thiết để thực hiện các kế hoạch kiểm thử.
- Đánh giá kết quả: Đánh giá kết quả kiểm thử, bao gồm báo cáo lỗi và tài liệu kiểm thử.
- Phê duyệt và phân phối: Phê duyệt và phân phối test plan cho các bên liên quan, bao gồm các nhà phát triển, các nhà thiết kế và các quản lý sản phẩm.
