Live-Project Test-Plan SoftwareTestingHelp

Kế hoạch kiểm tra mẫu – Đào tạo dự án trực tiếp OrangeHRM © www.SoftwareTestingHelp.
com
© www.SoftwareTestingHelp.com
Test Plan (a Real Sample)

SoftwareTestingHelp.com Live Project Training - OrangeHRM
1/2/2014
SoftwareTestingHelp.com
Name of the tester
Lưu ý: Đây là kế hoạch kiểm tra mẫu được tạo trong dự án trực tiếp kiểm thử phần
mềm theo thời gian thực - dành cho đào tạo do softwaretestinghelp.com thực hiện
trên trang sau:
=> Nhấp vào đây để đào tạo miễn phí về kiểm thử phần mềm trên một dự án trực tiếp
Phiên bản: 1.0

tạo: 02/05/2014
Cập nhật lần cuối: 02/05/2014
Trạng thái: BẢN DỰ THẢO (Trạng thái sẽ thay đổi thành hoàn tất đăng bài đánh giá và phê duyệt của BA, PM và
nhà phát triển)
Kế hoạch kiểm tra mẫu – Đào tạo dự án trực tiếp OrangeHRM © www.SoftwareTestingHelp.com
Bảng sửa đổi và phê duyệt

Lịch sử tài liệu - Để duy trì danh sách các thay đổi đang được thực hiện
Phiên
Ngày Tác giả Chi tiết thay đổi
bản
1 14/02/2014 Swati Seela Bản nháp
2 14/02/2014 Vijay Shinde Bản nháp - Đã xem xét
Danh sách người phê duyệt - Để theo dõi ai đã xem xét và phê duyệt Kế hoạch kiểm tra
Người phê Ngày phê
Tên Vai trò duyệt / Người duyệt / xem
đánh giá xét
Tài liệu tham khảo - Đánh dấu rõ ràng tài liệu được sử dụng làm đầu vào để lập kế hoạch kiểm tra
Phiên bản Ngày Tên tài liệu
1. PHIÊN BẢN ORANGEHRM 3.0 – MODULE THÔNG TIN

0 CỦA TÔI -FSD
Bí mật công ty Trang 1

Mục lục
1. GIỚI THIỆU .............................................................................................................................5

1.1. Mục đích .....................................................................................................................5
1.2. Tổng quan dự án .........................................................................................................5
1.3. Khán giả ......................................................................................................................5
2. CHIẾN LƯỢC THỬ NGHIỆM ....................................................................................................5
2.1. Mục tiêu kiểm tra .......................................................................................................5
2.2. Kiểm tra giả định .........................................................................................................6
2.3. Nguyên tắc kiểm tra ....................................................................................................7
2.4. Phương pháp tiếp cận dữ liệu ....................................................................................7
2.5. Phạm vi và cấp độ kiểm tra .........................................................................................7
2.5.1. Khám phá .......................................................................................................7
2.5.2. Kiểm tra chức năng ........................................................................................8
TIÊU CHÍ CHẤP NHẬN THI ..............................................................................8
SẢN PHẨM THỬ NGHIỆM ..............................................................................8
DANH SÁCH MỤC TIÊU ..................................................................................9
2.5.3. Kiểm tra chấp nhận của người dùng (UAT) ....................................................9
SẢN PHẨM THỬ NGHIỆM ..............................................................................9
2.6. Ước tính nỗ lực kiểm tra ...........................................................................................10
3. CHIẾN LƯỢC THỰC HIỆN ......................................................................................................10
3.1. Tiêu chí vào và ra ......................................................................................................10
3.2. Chu kỳ thử nghiệm ...................................................................................................11
3.3. Xác nhận và quản lý lỗi .............................................................................................11
3.4. Chỉ số kiểm tra ..........................................................................................................12
3.5. Theo dõi và báo cáo lỗi .............................................................................................13
4. QUY TRÌNH QUẢN LÝ KIỂM TRA ...........................................................................................13
4.1. Công cụ quản lý kiểm tra ..........................................................................................13
4.2. Quy trình thiết kế thử nghiệm ..................................................................................14
4.3. Quy trình thực hiện kiểm thử ...................................................................................15
4.4. Kiểm tra rủi ro và các yếu tố giảm thiểu ...................................................................16
4.1. Kế hoạch Truyền thông và Danh sách Nhóm ............................................................17

4.2. Kỳ vọng về vai trò .....................................................................................................17

4.2.1. Quản lý dự án ..............................................................................................18
4.2.2. Lập kế hoạch kiểm thử (Test Lead) ..............................................................18
4.2.3. Đội kiểm tra .................................................................................................18
4.2.4. Trưởng nhóm kiểm tra .................................................................................18
4.2.5. Nhóm phát triển ..........................................................................................18
5. MÔI TRƯỜNG THI ................................................................................................................19

1. GIỚI THIỆU
1.1. Mục đích
Kế hoạch thử nghiệm này mô tả phương pháp thử nghiệm và khuôn khổ tổng thể sẽ thúc đẩy thử
nghiệm trang web OrangeHRM Phiên bản 3.0 – My Info Module.com. Tài liệu giới thiệu:
 Chiến lược kiểm thử: các quy tắc mà bài kiểm tra sẽ dựa trên, bao gồm các thông tin đưa ra của
dự án (ví dụ: ngày bắt đầu/kết thúc, mục tiêu, giả định); mô tả quy trình để thiết lập một thử
nghiệm hợp lệ (ví dụ: tiêu chí vào/ra, tạo trường hợp thử nghiệm, nhiệm vụ cụ thể cần thực hiện,
lập kế hoạch, chiến lược dữ liệu).
 Chiến lược thực hiện: mô tả cách kiểm thử sẽ được thực hiện và xử lý để xác định và báo cáo lỗi
cũng như sửa chữa và thực hiện các bản sửa lỗi.
 Quản lý kiểm thử: quy trình xử lý hậu cần của kiểm thử và tất cả các sự kiện xảy ra trong quá
trình thực hiện (ví dụ: thông tin liên lạc, quy trình leo thang, rủi ro và giảm thiểu, phân công
nhóm)
1.2. Tổng quan dự án
Mô-đun thông tin của tôi là một công cụ mạnh mẽ cung cấp cho nhân viên của công ty khả năng xem
thông tin liên quan như thông tin cá nhân và cập nhật thông tin cá nhân bằng PC có kết nối internet
mà không cần phải nhờ đến bộ phận nhân sự.
Chức năng của mô-đun này trải rộng trên toàn bộ hệ thống, giúp thông tin có sẵn ở mọi nơi, mọi lúc.
Tất cả thông tin đều phải tuân theo chính sách bảo mật do công ty xác định, trong đó người đó chỉ có
thể xem thông tin mà người đó được phép. Người dùng ESS chỉ có thể chỉnh sửa một số trường nhất
định trong Mô-đun ESS, duy trì tính bảo mật và bảo mật thông tin của nhân viên
1.3. Khán giả
 Các thành viên trong nhóm dự án thực hiện các nhiệm vụ được chỉ định trong tài liệu này, đồng
thời cung cấp thông tin đầu vào và đề xuất về tài liệu này.
 Người quản lý dự án Lập kế hoạch cho các hoạt động thử nghiệm trong lịch trình tổng thể của dự
án, xem xét tài liệu, theo dõi việc thực hiện thử nghiệm theo nhiệm vụ được chỉ định trong tài
liệu này, phê duyệt tài liệu và chịu trách nhiệm về kết quả.
 Đại diện và người tham gia của các bên liên quan (các cá nhân được xác định bởi Trưởng nhóm
PMO) có thể tham gia bài kiểm tra UAT để đảm bảo hoạt động kinh doanh phù hợp với kết quả
của bài kiểm tra.
 Nhóm kỹ thuật đảm bảo rằng kế hoạch kiểm tra và sản phẩm bàn giao phù hợp với thiết kế, cung
cấp môi trường để kiểm tra và tuân theo các quy trình liên quan đến việc sửa lỗi.
 Các nhà phân tích kinh doanh sẽ cung cấp đầu vào của họ về những thay đổi chức năng.

2. CHIẾN LƯỢC THỬ NGHIỆM
2.1. Mục tiêu thử nghiệm
Mục tiêu của thử nghiệm là để xác minh rằng chức năng của ORANGEHRM VERSION 3.0 – MY INFO
MODULE hoạt động theo các thông số kỹ thuật.
Quá trình kiểm thử sẽ thực thi và xác minh các tập lệnh kiểm thử, xác định, sửa chữa và kiểm tra lại
tất cả các lỗi có mức độ nghiêm trọng cao và trung bình theo tiêu chí đầu vào, ưu tiên các lỗi có mức
độ nghiêm trọng thấp hơn để sửa trong tương lai thông qua CR.
Sản phẩm cuối cùng của thử nghiệm có hai phần:
 Một phần mềm sẵn sàng sản xuất;

 Một tập hợp các tập lệnh kiểm thử ổn định có thể được sử dụng lại để thực hiện kiểm thử Chức
năng và UAT.
2.2. Kiểm tra giả định
Các giả định chính
 Sản xuất dữ liệu giống như yêu cầu và có sẵn trong hệ thống trước khi bắt đầu Kiểm tra chức
năng
 Trong mỗi giai đoạn thử nghiệm, Chu kỳ 3 sẽ được bắt đầu nếu tỷ lệ lỗi ở Chu kỳ 2 cao.
Tổng quan
 Thử nghiệm thăm dò sẽ được thực hiện khi bản dựng đã sẵn sàng để thử nghiệm
 Kiểm tra hiệu suất không được xem xét cho ước tính này.
 Tất cả các lỗi sẽ đi kèm với một ảnh chụp nhanh định dạng JPEG
 Nhóm Kiểm tra sẽ được cấp quyền truy cập vào môi trường Kiểm tra thông qua kết nối VPN
 Nhóm Kiểm thử giả định rằng tất cả các thông tin đầu vào cần thiết được yêu cầu trong quá trình
thiết kế và thực hiện Kiểm thử sẽ được các Nhà phân tích Phát triển/Kinh doanh hỗ trợ một cách
thích hợp.
 Hoạt động thiết kế test case sẽ do QA Group thực hiện
 Môi trường thử nghiệm và các hoạt động chuẩn bị sẽ do Dev Team làm chủ
 Nhóm phát triển sẽ cung cấp các kế hoạch sửa lỗi dựa trên các cuộc họp về lỗi trong mỗi chu kỳ
để lập kế hoạch. Điều tương tự sẽ được thông báo cho nhóm Kiểm thử trước khi bắt đầu chu kỳ
sửa lỗi
 NHÀ PHÂN TÍCH KINH DOANH sẽ xem xét và phê duyệt tất cả các trường hợp Kiểm thử do Nhóm
kiểm thử chuẩn bị trước khi bắt đầu thực hiện Kiểm thử
 Các khiếm khuyết sẽ chỉ được theo dõi thông qua HP ALM. Mọi bản sửa lỗi được lên kế hoạch sẽ
được chia sẻ với Nhóm kiểm tra trước khi áp dụng các bản sửa lỗi trên môi trường Kiểm tra
 Giám đốc Dự án/NHÀ PHÂN TÍCH KINH DOANH sẽ xem xét và phê duyệt tất cả các sản phẩm thử
nghiệm
 Dự án sẽ cung cấp kế hoạch kiểm thử, thiết kế kiểm thử và hỗ trợ thực hiện kiểm thử

 Nhóm kiểm thử sẽ quản lý nỗ lực kiểm thử với sự phối hợp chặt chẽ với PM dự án/NHÀ PHÂN
TÍCH KINH DOANH
 Nhóm dự án có kiến thức và kinh nghiệm cần thiết hoặc đã được đào tạo đầy đủ về hệ thống, dự
án và quy trình thử nghiệm.
 Không có thời gian ngừng hoạt động của môi trường trong quá trình thử nghiệm do ngừng hoạt
động hoặc sửa lỗi.
 Hệ thống sẽ được coi như một hộp đen; nếu thông tin hiển thị chính xác trực tuyến và trong các
báo cáo, thì cơ sở dữ liệu sẽ được coi là hoạt động bình thường.
 Chu kỳ 3 sẽ được bắt đầu nếu có nhiều lỗi hơn trong Chu kỳ 2.
Thử nghiệm chức năng

 Trong quá trình kiểm thử chức năng, nhóm kiểm thử sẽ sử dụng dữ liệu được tải sẵn có sẵn trên
hệ thống tại thời điểm thực hiện.
 Nhóm kiểm tra sẽ chỉ thực hiện kiểm tra chức năng trên ORANGEHRM PHIÊN BẢN 3.0 – MODULE
THÔNG TIN CỦA TÔI
UAT
 Việc thực hiện kiểm tra UAT sẽ được thực hiện bởi người dùng cuối (L1, L2 và L3) và Nhóm QA sẽ
hỗ trợ họ trong việc tạo tập lệnh UAT.
2.3. Nguyên tắc kiểm tra
 Thử nghiệm sẽ tập trung vào việc đáp ứng các mục tiêu kinh doanh, hiệu quả chi phí và chất
lượng.
 Sẽ có các quy trình chung, nhất quán cho tất cả các nhóm hỗ trợ hoạt động thử nghiệm.
 Các quy trình thử nghiệm sẽ được xác định rõ ràng nhưng vẫn linh hoạt và có khả năng thay đổi
khi cần thiết.
 Các hoạt động thử nghiệm sẽ được xây dựng dựa trên các giai đoạn trước để tránh sự dư thừa
hoặc trùng lặp nỗ lực.
 Môi trường và dữ liệu thử nghiệm sẽ mô phỏng môi trường sản xuất nhiều nhất có thể.
 Thử nghiệm sẽ là một hoạt động có thể lặp lại, định lượng và đo lường được.
 Thử nghiệm sẽ được chia thành các giai đoạn riêng biệt, mỗi giai đoạn có mục tiêu và mục tiêu
được xác định rõ ràng.
 Sẽ có tiêu chí vào và ra.
2.4. Phương pháp tiếp cận dữ liệu
 Trong thử nghiệm chức năng, ORANGEHRM PHIÊN BẢN 3.0 – MODULE THÔNG TIN CỦA TÔI sẽ chứa
dữ liệu thử nghiệm được tải sẵn và được sử dụng cho các hoạt động thử nghiệm.

2.5. Phạm vi và cấp độ kiểm tra
2.5.1. Khám phá
MỤC ĐÍCH : mục đích của thử nghiệm này là để đảm bảo các lỗi nghiêm trọng được loại bỏ
trước khi các cấp độ thử nghiệm tiếp theo có thể bắt đầu.
PHẠM VI : Các mô-đun điều hướng, đại lý và quản trị viên cấp độ đầu tiên
NGƯỜI KIỂM TRA : Nhóm kiểm tra.
PHƯƠNG PHÁP : thử nghiệm thăm dò này được thực hiện trong ứng dụng mà không có bất
kỳ tập lệnh và tài liệu thử nghiệm nào
THỜI GIAN : vào đầu mỗi chu kỳ.
2.5.2. Kiểm tra chức năng
MỤC ĐÍCH: Kiểm tra chức năng sẽ được thực hiện để kiểm tra các chức năng của ứng dụng.
Việc kiểm tra chức năng được thực hiện bằng cách cung cấp đầu vào và xác thực đầu ra từ
ứng dụng.
Phạm vi: Bảng excel bên dưới nêu chi tiết về phạm vi của Kiểm tra chức năng. Lưu ý: Phạm vi
ở mức cao do có những thay đổi trong yêu cầu.
Để giữ cho tài liệu dễ dàng được phân mảnh và phân loại, phạm vi đã được nhúng dưới dạng
tài liệu riêng biệt. Nếu muốn, bạn có thể chèn một bảng vào đây. Phạm vi được tạo dựa trên
các kịch bản Kiểm thử đã được xác định trong bài viết trước.
NGƯỜI KIỂM TRA : Nhóm kiểm tra.
PHƯƠNG PHÁP : Việc kiểm tra sẽ được thực hiện theo các tập lệnh Chức năng được lưu trữ
trong HP ALM.
THỜI GIAN : sau khi hoàn thành bài kiểm tra thăm dò.
THI C
1. Tài liệu đặc tả chức năng đã được phê duyệt, tài liệu ca sử dụng phải có sẵn trước khi
bắt đầu giai đoạn thiết kế thử nghiệm.
2. Các trường hợp kiểm thử đã được phê duyệt và phê duyệt trước khi bắt đầu thực hiện
kiểm thử
3. Quá trình phát triển đã hoàn tất, đơn vị đã được kiểm thử với trạng thái đạt và kết quả
được chia sẻ cho nhóm Kiểm thử để tránh các lỗi trùng lặp

4. Môi trường thử nghiệm với trạng thái ứng dụng đã được cài đặt, định cấu hình và sẵn
sàng sử dụng
Đăng xuất Sẵn sàng
Tài liệu đặc tả chức năng đã được phê duyệt Quá trình phát triển đã hoàn tất và thử nghiệm
Các trường hợp sử dụng được phê duyệt đơn vị
Các trường hợp thử nghiệm đã được phê duyệt Ứng dụng đã được triển khai và hệ thống sẵn
sàng để thử nghiệm trên m ôi trường Thử
nghiệm
Dữ liệu giống như sản xuất có sẵn để kiểm tra
tất cả các chức năng.
Các bản sửa lỗi được lên kế hoạch dựa trên việc
phân loại lỗi (Kiểm tra đơn vị) và tiêu chí đánh
giá
SẢN PHẨM THỬ NGHIỆM
S.Kh Tên có thể giao được Tác giả Người đánh giá
ông .
1. Kế hoạch kiểm tra Trưởng nhóm kiểm Giám đốc dự án/
tra Chuyên viên phân tích
kinh doanh
2. Các trường hợp kiểm thử chức Đội kiểm tra Nhà phân tích kinh
năng doanh đăng xuất
3. Lỗi ghi nhật ký trong HP ALM Đội kiểm tra Trưởng nhóm kiểm
tra/ Trưởng nhóm lập
trình(Vijay)
(4. Báo cáo tình trạng hàng ngày/hàng Nhóm kiểm tra/ Trưởng nhóm kiểm
tuần Trưởng nhóm kiểm thử/Quản lý dự án
tra
5. Báo cáo kết thúc thử nghiệm Trưởng nhóm kiểm Quản lý dự án
tra
DANH SÁCH MỤC TIÊU

Danh sách các mốc quan trọng chỉ là dự kiến và có thể thay đổi vì những lý do dưới đây
a) Mọi vấn đề về mức độ sẵn sàng của môi trường Hệ thống

b) Bất kỳ thay đổi nào về phạm vi/bổ sung phạm vi
c) Bất kỳ sự phụ thuộc nào khác ảnh hưởng đến nỗ lực và thời gian
Việc kiểm tra thường không được thực hiện trong một chu kỳ. Dựa trên phạm vi thử
nghiệm, chúng tôi có thể ước tính lượng thời gian cần thiết và thiết lập các mốc thời gian
như bạn có thể thấy trong bảng excel được nhúng bên dưới.

2.5.3. Kiểm tra chấp nhận của người dùng (UAT)
MỤC ĐÍCH : bài kiểm tra này tập trung vào việc xác nhận logic nghiệp vụ. Nó cho phép người
dùng cuối hoàn thành đánh giá cuối cùng về hệ thống trước khi triển khai.
KIỂM TRA : UAT được thực hiện bởi người dùng cuối (L1, L2 và L3).
PHƯƠNG PHÁP : Vì người dùng doanh nghiệp được chỉ định nhiều nhất là cung cấp thông tin
đầu vào xoay quanh nhu cầu kinh doanh và cách hệ thống thích ứng với chúng, nên có thể
xảy ra trường hợp người dùng thực hiện một số xác thực không có trong tập lệnh. Nhóm
kiểm thử viết các trường hợp kiểm thử UAT dựa trên đầu vào từ Người dùng cuối (người
dùng L1 , L2 và L3) và Nhà phân tích nghiệp vụ.
THỜI GIAN : Sau khi tất cả các cấp độ thử nghiệm khác (Thăm dò và Chức năng) được thực
hiện. Chỉ sau khi quá trình thử nghiệm này hoàn tất, sản phẩm mới có thể được đưa vào sản
xuất.
SẢN PHẨM THỬ NGHIỆM
S.Kh Tên có thể giao được Tác giả Người đánh giá
ông .
1. Các trường hợp kiểm thử UAT Đội kiểm tra Nhà phân tích kinh
doanh đăng xuất
2.6. Ước tính nỗ lực kiểm tra
Tài liệu này liệt kê tất cả các hoạt động mà nhóm QA phải thực hiện và ước tính mỗi hoạt động sẽ
mất bao nhiêu giờ công.
3.
nhóm TCOE

4. CHIẾN LƯỢC THỰC HIỆN
4.1. Tiêu chí vào và ra
 Tiêu chí đầu vào đề cập đến các điều kiện mong muốn để bắt đầu thực hiện kiểm thử; chỉ cần
đánh giá việc di chuyển mã và sửa lỗi vào cuối mỗi chu kỳ.
 Tiêu chí đầu ra là những điều kiện mong muốn cần được đáp ứng để tiến hành triển khai.
 Tiêu chí đầu vào và đầu ra là điểm chuẩn linh hoạt. Nếu chúng không được đáp ứng, nhóm kiểm
thử sẽ đánh giá rủi ro, xác định các hành động giảm thiểu và đưa ra đề xuất. Tất cả những điều
này là thông tin đầu vào cho người quản lý dự án để đưa ra quyết định cuối cùng “không được
làm nữa”.
 Tiêu chí đầu vào để bắt đầu giai đoạn thực hiện thử nghiệm: các hoạt động được liệt kê trong
phần Lập kế hoạch thử nghiệm của lịch trình đã được hoàn thành 100%.
 Tiêu chí đầu vào để bắt đầu mỗi chu kỳ: các hoạt động được liệt kê trong phần Thực hiện kiểm
thử của lịch trình được hoàn thành 100% ở mỗi chu kỳ.
Đội kiểm Đội kỹ

Tiêu chí thoát Ghi chú
tra thuật
100% tập lệnh kiểm tra được thực thi
Tỷ lệ vượt qua 95% của Tập lệnh kiểm tra

Không có lỗi mở nào có mức độ nghiêm trọng
nghiêm trọng và cao
95% lỗi ở mức độ nghiêm trọng trung bình đã được
khắc phục
Tất cả các lỗi còn lại đều bị hủy bỏ hoặc được ghi lại
dưới dạng Yêu cầu Thay đổi cho bản phát hành trong
tương lai
Tất cả các kết quả mong đợi và thực tế đều được ghi
lại và ghi lại bằng tập lệnh thử nghiệm
Tất cả số liệu kiểm tra được thu thập dựa trên báo
cáo từ HP ALM
Tất cả các lỗi được ghi vào HP ALM
Bản ghi nhớ kết thúc thử nghiệm đã hoàn thành và
được ký tắt
Việc dọn dẹp môi trường thử nghiệm đã hoàn tất và
một bản sao lưu mới của môi trường
4.2. Chu kỳ kiểm tra
o Sẽ có hai chu kỳ để kiểm tra chức năng. Mỗi chu kỳ sẽ thực thi tất cả các tập lệnh.

o Mục tiêu của chu trình đầu tiên là xác định bất kỳ lỗi cản trở, lỗi nghiêm trọng nào và hầu
hết các lỗi nghiêm trọng. Người ta dự kiến sẽ sử dụng một số cách giải quyết khác để có
được tất cả các tập lệnh.
o Mục tiêu của chu kỳ thứ hai là xác định các lỗi ở mức độ cao và trung bình còn lại, loại bỏ
cách giải quyết khỏi chu kỳ đầu tiên, sửa các lỗ hổng trong tập lệnh và thu được kết quả về
hiệu suất.
 Bài kiểm tra UAT sẽ bao gồm một chu kỳ.
4.3. Xác nhận và quản lý lỗi
 Người kiểm tra dự kiến sẽ thực thi tất cả các tập lệnh trong mỗi chu trình được mô tả ở trên. Tuy
nhiên, người ta nhận thấy rằng người kiểm tra cũng có thể thực hiện kiểm tra bổ sung nếu họ xác
định được lỗ hổng có thể có trong tập lệnh. Điều này đặc biệt có liên quan trong chu kỳ thứ hai,
khi Nhà phân tích kinh doanh tham gia TCOE để thực hiện thử nghiệm, vì NHÀ PHÂN TÍCH KINH
DOANH có kiến thức sâu hơn về các quy trình kinh doanh. Nếu xác định được lỗ hổng, tập lệnh và
ma trận truy xuất nguồn gốc sẽ được cập nhật và sau đó lỗi sẽ được ghi lại vào tập lệnh.
 Các khiếm khuyết sẽ chỉ được theo dõi thông qua HP ALM. Nhóm kỹ thuật sẽ thu thập thông tin
hàng ngày từ HP ALM và yêu cầu thêm thông tin chi tiết từ Điều phối viên về Lỗi. Đội ngũ kỹ thuật
sẽ tiến hành khắc phục.
 Người kiểm tra có trách nhiệm mở các lỗi, liên kết chúng với tập lệnh tương ứng, chỉ định mức độ
nghiêm trọng và trạng thái ban đầu, kiểm tra lại và đóng lỗi; Người quản lý lỗi có trách nhiệm
xem xét mức độ nghiêm trọng của lỗi và tạo điều kiện cho nhóm kỹ thuật khắc phục và triển khai
nó, liên lạc với người kiểm tra khi quá trình kiểm tra có thể tiếp tục hoặc nên tạm dừng, yêu cầu
người kiểm tra kiểm tra lại và sửa đổi trạng thái như khiếm khuyết tiến triển theo chu kỳ; Nhóm
kỹ thuật có trách nhiệm xem xét HP ALM hàng ngày, hỏi chi tiết nếu cần, khắc phục lỗi, thông báo
cho Người quản lý lỗi về việc khắc phục đã được thực hiện, triển khai giải pháp theo yêu cầu của
Trình quản lý lỗi.
Các lỗi được tìm thấy trong quá trình Kiểm tra sẽ được phân loại theo công cụ báo cáo lỗi “Mercury
HP ALM” và các loại là:
Mức độ nghiêm trọng Sự va chạm

1 (Quan trọng)  Lỗi này đủ nghiêm trọng để làm hỏng hệ thống, gây hỏng tệp hoặc có
thể gây mất dữ liệu
 Nó gây ra sự trở lại bất thường của hệ điều hành (xuất hiện sự cố hoặc
thông báo lỗi hệ thống).
 Nó khiến ứng dụng bị treo và yêu cầu khởi động lại hệ thống.
2 (Cao)  Nó gây ra sự thiếu hụt chức năng quan trọng của chương trình với
cách giải quyết.
3 (Trung bình)  Lỗi này sẽ làm giảm chất lượng của Hệ thống. Tuy nhiên, có một giải
pháp thông minh để đạt được chức năng mong muốn - ví dụ như
thông qua một màn hình khác.
 Lỗi này ngăn không cho các khu vực khác của sản phẩm được thử
nghiệm. Tuy nhiên, các lĩnh vực khác có thể được kiểm tra độc lập.
4 (Thấp)  Có thông báo lỗi không đầy đủ hoặc không rõ ràng, điều này ít ảnh
hưởng đến việc sử dụng sản phẩm.

5(Mỹ phẩm)  Có thông báo lỗi không đầy đủ hoặc không rõ ràng, không ảnh hưởng
đến việc sử dụng sản phẩm.
4.4. Số liệu kiểm tra
Các thước đo kiểm thử để đo lường tiến độ và mức độ thành công của quá trình kiểm thử sẽ được
phát triển và chia sẻ với người quản lý dự án để phê duyệt. Dưới đây là một số chỉ số
Báo cáo Sự miêu tả Tính thường xuyên
Chuẩn bị Để báo cáo về % hoàn thành, %WIP, % Đạt, % Thất bại Hàng tuần / Hàng
kiểm tra & ngày (tùy chọn)
Trạng thái Mức độ nghiêm trọng của khiếm khuyết Trạng thái –
thực hiện Mở, đóng, bất kỳ Trạng thái nào khác
Thực hiện Để báo cáo Đạt, Không đạt, Tổng số lỗi, đánh dấu Hằng ngày
hàng ngày Showstopper/Các lỗi nghiêm trọng
trạng thái
Báo cáo Báo cáo định hướng dự án (Theo yêu cầu của Thủ Hàng tuần – Nếu
tình trạng tướng) nhóm dự án cần cập
hàng tuần nhật hàng tuần ngoài
của dự án hàng ngày và có sẵn
mẫu để nhóm dự án
sử dụng.
4.5. Theo dõi và báo cáo lỗi
Sơ đồ sau mô tả quá trình theo dõi lỗi:

Start
Tester:
Tester: Test Dev Develo
Lead Retests
Lead per: the
Report
Validate product
defects Assign Fixes
defects defects defects
N
o Appr
oved?
ClosY
e e
defs
ect
Stop
5. QUY TRÌNH QUẢN LÝ KIỂM TRA
5.1. Công cụ quản lý kiểm tra

Quản lý vòng đời ứng dụng HP là công cụ được sử dụng để Quản lý kiểm tra. Tất cả các tạo
phẩm thử nghiệm như Trường hợp thử nghiệm, kết quả thử nghiệm đều được cập nhật trong
công cụ Quản lý vòng đời ứng dụng (ALM) của HP.
 Cấu trúc thư mục cụ thể của dự án sẽ được tạo trong HP ALM để quản lý trạng thái của dự
án DFRT này.
 Mỗi tài nguyên trong nhóm Kiểm tra sẽ được cung cấp quyền truy cập Đọc/Ghi để thêm/sửa
đổi các Trường hợp kiểm tra trong HP ALM.
 Trong giai đoạn Thiết kế thử nghiệm, tất cả các trường hợp thử nghiệm đều được ghi trực
tiếp vào HP ALM. Mọi thay đổi đối với trường hợp thử nghiệm sẽ được cập nhật trực tiếp
trong HP ALM.
 Mỗi Người kiểm tra sẽ truy cập trực tiếp vào các trường hợp kiểm thử được chỉ định tương
ứng của họ và cập nhật trực tiếp trạng thái của từng bước đã thực hiện trong HP ALM.
 Bất kỳ lỗi nào gặp phải sẽ được nêu ra trong liên kết HP ALM với trường hợp Kiểm tra/bước
kiểm tra cụ thể.
 Trong quá trình kiểm tra sửa lỗi, các lỗi sẽ được gán lại cho người kiểm tra để xác minh việc
sửa lỗi. Người kiểm tra xác minh việc sửa lỗi và cập nhật trạng thái trực tiếp trong HP ALM.
 Nhiều báo cáo khác nhau có thể được tạo từ HP ALM để cung cấp trạng thái thực hiện Kiểm
tra. Ví dụ: Báo cáo trạng thái của các trường hợp kiểm thử đã thực hiện, Đạt, Thất bại, Số lỗi
mở, Lỗi nghiêm trọng, v.v.

5.2. Quy trình thiết kế thử nghiệm
SME /Đánh giá Kết hợp các

Thiết lập Ma
Chuẩn bị các ngang hàng nhận xét đánh
trận truy xuất
Hiểu yêu cầu trường hợp các trường giá trong các
nguồn gốc
thử nghiệm hợp thử trường hợp
trong HP ALM
nghiệm thử nghiệm
 Người kiểm tra sẽ hiểu từng yêu cầu và chuẩn bị các trường hợp kiểm thử tương ứng để
đảm bảo tất cả các yêu cầu đều được đáp ứng.
 Mỗi trường hợp kiểm thử sẽ được ánh xạ từ Trường hợp sử dụng đến Yêu cầu như một
phần của ma trận Truy xuất nguồn gốc.
 Mỗi trường hợp Kiểm thử sẽ được NHÀ PHÂN TÍCH KINH DOANH xem xét và các lỗi
đánh giá sẽ được ghi lại và chia sẻ cho nhóm Kiểm thử. Những người kiểm tra sẽ làm lại
các lỗi đánh giá và cuối cùng nhận được sự chấp thuận và phê duyệt.
 Trong giai đoạn chuẩn bị, người kiểm thử sẽ sử dụng nguyên mẫu, trường hợp sử dụng
và đặc tả chức năng để viết các trường hợp kiểm thử từng bước.
 Người kiểm thử sẽ duy trì một bảng Theo dõi làm rõ và bảng này sẽ được chia sẻ định kỳ
với nhóm Yêu cầu và theo đó trường hợp kiểm thử sẽ được cập nhật. Việc làm rõ đôi khi
có thể dẫn đến Yêu cầu Thay đổi hoặc không nằm trong phạm vi hoặc nêu chi tiết các
yêu cầu tiềm ẩn.
 Việc đăng ký các trường hợp thử nghiệm sẽ được Nhà phân tích nghiệp vụ thông báo
qua thư.
 Mọi thay đổi tiếp theo đối với trường hợp thử nghiệm nếu có sẽ được cập nhật trực tiếp
trong HP ALM.
5.3. Quy trình thực hiện kiểm thử
Tăng các lỗi cho

Hoàn thành việc
Thực hiện từng Đánh dấu trạng các trường hợp Gửi báo cáo Tham gia vào
thực hiện kiểm
bước kiểm thử thái là thử nghiệm trạng thái hàng chu trình Phân
thử của tất cả
trong trường Đạt/Không đạt không thành ngày cho Trưởng loại lỗi và giải
các trường hợp
hợp kiểm thử trong HP ALM công trong HP nhóm kiểm tra thích các lỗi
kiểm thử
ALM
 Sau khi tất cả các trường hợp thử nghiệm được phê duyệt và môi trường thử nghiệm đã
sẵn sàng để thử nghiệm, người thử nghiệm sẽ bắt đầu thử nghiệm thăm dò ứng dụng
để đảm bảo ứng dụng ổn định để thử nghiệm.

 Mỗi Người kiểm thử được chỉ định các trường hợp Kiểm thử trực tiếp trong HP ALM.
 Người kiểm tra đảm bảo quyền truy cập cần thiết vào môi trường kiểm tra, HP ALM để
cập nhật trạng thái kiểm tra và phát hiện lỗi. Nếu có bất kỳ vấn đề nào, sẽ được chuyển
đến Trưởng nhóm kiểm tra và lần lượt đến Người quản lý dự án dưới dạng báo cáo.
 Nếu có bất kỳ showstopper nào trong quá trình thử nghiệm thăm dò sẽ được chuyển
đến SPOC phát triển tương ứng để sửa lỗi.
 Mỗi người kiểm tra thực hiện thực hiện từng bước và cập nhật trạng thái thực thi.
Người kiểm tra nhập Trạng thái Đạt hoặc Không đạt cho từng bước trực tiếp trong HP
ALM.
 Người kiểm tra sẽ chuẩn bị biểu đồ Chạy với các chi tiết thực hiện theo ngày
 Nếu có bất kỳ lỗi nào, lỗi sẽ được nêu ra theo hướng dẫn về mức độ nghiêm trọng trong
công cụ HP ALM nêu chi tiết các bước mô phỏng cùng với ảnh chụp màn hình nếu thích
hợp.
 Trạng thái thực hiện Kiểm tra hàng ngày cũng như trạng thái Lỗi sẽ được báo cáo cho tất
cả các bên liên quan.
 Nhóm kiểm thử sẽ tham gia vào các cuộc họp phân loại lỗi để đảm bảo tất cả các trường
hợp kiểm thử được thực hiện với loại đạt/không đạt.
 Nếu có bất kỳ lỗi nào không nằm trong các bước nhưng có thể nằm ngoài các bước kiểm
tra, thì những lỗi đó cần được ghi lại trong HP ALM và ánh xạ lỗi đó theo cấp độ trường
hợp kiểm thử hoặc ở bước cụ thể mà sự cố gặp phải sau khi xác nhận với Trưởng nhóm
kiểm thử .
 Quá trình này được lặp lại cho đến khi tất cả các trường hợp kiểm thử được thực hiện
đầy đủ với trạng thái Đạt/Không đạt.
 Trong chu kỳ tiếp theo, mọi lỗi đã được khắc phục sẽ được kiểm tra và kết quả sẽ được
cập nhật trong HP ALM trong chu kỳ.
Theo Quy trình, quy trình phê duyệt cuối cùng hoặc hoàn thành dự án sẽ được tuân theo
5.4. Kiểm tra rủi ro và các yếu tố giảm thiểu
Có vấn Sự va
Rủi ro Kế hoạch giảm thiểu
đề. chạm
LỊCH TRÌNH  Nhóm kiểm thử có thể kiểm soát

Lịch kiểm tra chặt chẽ. Nếu việc bắt các công việc chuẩn bị (trước) và
đầu thử nghiệm bị trì hoãn do việc trao đổi sớm với các bên
nhiệm vụ thiết kế, thì thử nghiệm liên quan.
không thể kéo dài quá ngày bắt đầu Cao Cao  Một số khoảng đệm đã được
theo lịch trình của UAT. thêm vào lịch trình dự phòng,
mặc dù không nhiều như lời
khuyên về các phương pháp
thực hành tốt nhất.
TÀI NGUYÊN Các ngày nghỉ lễ, nghỉ phép đã được
Không đủ nguồn lực, nguồn lực lên Trung ước tính và xây dựng thành lịch
Cao
máy bay quá muộn (quá trình này bình trình; những sai lệch so với ước tính
mất khoảng 15 ngày. có thể dẫn đến sự chậm trễ trong

Có vấn Sự va
Rủi ro Kế hoạch giảm thiểu
đề. chạm
quá trình thử nghiệm.

KHIẾM KHUYẾT Kế hoạch quản lý lỗi được áp dụng
Các khiếm khuyết được phát hiện ở để đảm bảo liên lạc nhanh chóng và
giai đoạn cuối của chu kỳ hoặc ở giai khắc phục sự cố.
đoạn muộn của chu kỳ; những
khiếm khuyết được phát hiện muộn Trung
Cao
rất có thể là do thông số kỹ thuật bình
không rõ ràng và tốn nhiều thời gian
để giải quyết.
PHẠM VI Phạm vi được xác định rõ ràng

Phạm vi được xác định hoàn toàn Trung Trung nhưng những thay đổi về chức năng
bình bình vẫn chưa được hoàn thiện hoặc vẫn
tiếp tục thay đổi.
Thảm họa thiên nhiên Các nhóm và trách nhiệm đã được
trải rộng đến hai khu vực địa lý khác
nhau. Trong một sự kiện thảm khốc
Trung ở một trong các khu vực, sẽ có
Thấp
bình nguồn lực ở các khu vực khác cần
thiết để tiếp tục các hoạt động thử
nghiệm (mặc dù với tốc độ chậm
hơn).
Không có sẵn môi trường Kiểm thử Do không có sẵn môi trường, lịch
độc lập và khả năng tiếp cận Trung trình sẽ bị ảnh hưởng và sẽ dẫn đến
Cao
bình việc bắt đầu thực hiện Kiểm thử bị
trì hoãn.
Kiểm tra bị trì hoãn do các vấn đề Trong quá trình thử nghiệm, rất có
mới thể một số lỗi “mới” có thể được xác
định và có thể trở thành vấn đề cần
thời gian để giải quyết.
Có những lỗi có thể phát sinh trong
quá trình thử nghiệm do tài liệu đặc
tả không rõ ràng. Những khiếm
Trung khuyết này có thể dẫn đến một vấn
Cao
bình đề cần thời gian để giải quyết.
Nếu những vấn đề này trở thành vấn
đề gây cản trở, nó sẽ ảnh hưởng lớn
đến tiến độ tổng thể của dự án.
Nếu phát hiện ra lỗi mới, quy trình
quản lý lỗi và quản lý vấn đề sẽ được
áp dụng để đưa ra giải pháp ngay lập
tức.

5.1. Kế hoạch truyền thông và danh sách nhóm
5.2. Kỳ vọng về vai trò
Danh sách sau đây xác định một cách chung chung những kỳ vọng liên quan đến các vai trò liên quan
trực tiếp đến việc quản lý, lập kế hoạch hoặc thực hiện thử nghiệm cho dự án.
Vai trò Tên Thông tin liên lạc
1. Quản lý dự án
2. Trưởng nhóm kiểm tra

3. Phân tích kinh doanh
4. Trưởng nhóm phát triển
5. Đội thử nghiệm
6. Nhóm phát triển
7. Lãnh đạo kỹ thuật
5.2.1. Quản lý dự án
 Người quản lý dự án: xem xét nội dung của Kế hoạch kiểm thử, Chiến lược kiểm thử và
Ước tính kiểm thử ký trên đó.
5.2.2. Lập kế hoạch kiểm thử (Trưởng nhóm kiểm thử)
 Đảm bảo tiêu chí đầu vào được sử dụng làm đầu vào trước khi bắt đầu thực hiện.
 Phát triển kế hoạch kiểm thử và các hướng dẫn để tạo điều kiện kiểm thử, trường hợp
kiểm thử, kết quả mong đợi và kịch bản thực thi.
 Cung cấp hướng dẫn về cách quản lý lỗi.
 Tham dự các cuộc họp trạng thái trực tiếp hoặc thông qua đường dây cuộc gọi hội nghị.
 Thông báo cho nhóm kiểm tra bất kỳ thay đổi nào cần được thực hiện đối với sản phẩm
hoặc ứng dụng kiểm tra và thời điểm chúng sẽ được hoàn thành.
 Cung cấp hỗ trợ tại chỗ hoặc từ xa.
 Cung cấp đội ngũ chức năng (Chuyên viên phân tích kinh doanh) và kỹ thuật để kiểm tra
nhân sự của nhóm (nếu cần).
5.2.3. Đội kiểm tra
 Phát triển các điều kiện kiểm thử, trường hợp kiểm thử, kết quả mong đợi và tập lệnh
thực thi.
 Thực hiện thực hiện và xác nhận.
 Xác định, ghi lại và ưu tiên các lỗi theo hướng dẫn do Trưởng nhóm kiểm tra cung cấp.
 Kiểm tra lại sau khi sửa đổi phần mềm theo đúng kế hoạch.
 Chuẩn bị số liệu kiểm tra và cung cấp trạng thái thường xuyên.

5.2.4. Trưởng nhóm kiểm tra
 Xác nhận việc hoàn thành một phần trong một chu kỳ.
 Đồng ý để bắt đầu cấp độ thử nghiệm tiếp theo.
 Tạo điều kiện thuận lợi cho việc liên lạc về các khiếm khuyết giữa nhóm kiểm thử và
nhóm kỹ thuật/phát triển.
5.2.5. Nhóm phát triển
 Xem xét các sản phẩm thử nghiệm (kế hoạch thử nghiệm, trường hợp, tập lệnh, kết quả
mong đợi, v.v.) và cung cấp phản hồi kịp thời.
 Hỗ trợ xác nhận kết quả (nếu được yêu cầu).
 Hỗ trợ các quá trình phát triển và thử nghiệm đang được sử dụng để hỗ trợ dự án.
 Chứng nhận các thành phần chính xác đã được chuyển đến môi trường thử nghiệm tại
các điểm được chỉ định trong lịch trình thử nghiệm.
 Thông báo cho nhóm dự án và lãnh đạo về phiếu ngày giao phần mềm tiềm năng dựa
trên lịch trình hiện tại.
 Xác định các quy trình/công cụ để tạo điều kiện thuận lợi cho việc di chuyển ban đầu và
liên tục của các thành phần.
 Tiến hành điều tra bước đầu về những khác biệt trong quá trình thực thi và hỗ trợ người
thực hiện kiểm tra trong việc tạo ra các lỗi chính xác.
 Thực hiện sửa chữa các lỗi theo lịch trình.
6. MÔI TRƯỜNG THI NGHIỆP
PHIÊN BẢN ORANGEHRM 3.0 – Máy chủ của MODULE THÔNG TIN CỦA TÔI sẽ được lưu trữ tại
trang web của công ty X.
PHIÊN BẢN RANGEHRM 3.0 – MÔ-ĐUN THÔNG TIN CỦA TÔI sẽ được lưu trữ trên hai máy chủ:
Một để lưu trữ trang web thực tế và mã (ngôn ngữ), còn lại để lưu trữ cơ sở dữ liệu (tên cơ sở dữ
liệu).
môi trường Windows với Internet Explorer 8, 9 và 10 cũng như Firefox 27.0 cũng như Google Chrome
32.0 trở lên.
7. PHÊ DUYỆT
Tên và chức danh của tất cả những người phải phê duyệt kế hoạch này.
Chữ ký:
Tên:

Vai trò:
Ngày:
Chữ ký:
Tên:
Vai trò:
Ngày:
Lưu ý: Đây là kế hoạch kiểm thử mẫu được tạo trong dự án trực tiếp kiểm
thử phần mềm theo thời gian thực - chương trình đào tạo do
softwaretestinghelp.com thực hiện trên trang sau:
=> Nhấp vào đây để đào tạo miễn phí về kiểm thử phần mềm trên một dự án
trực tiếp

Live-Project Test-Plan SoftwareTestingHelp

Uploaded by

Copyright:

Available Formats

You might also like

Live-Project Test-Plan SoftwareTestingHelp

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Live-Project Test-Plan SoftwareTestingHelp

Uploaded by

Copyright:

Available Formats

Kế hoạch kiểm tra mẫu – Đào tạo dự án trực tiếp OrangeHRM © www.SoftwareTestingHelp.

Test Plan (a Real Sample)

Phiên bản: 1.0

Bảng sửa đổi và phê duyệt

1 14/02/2014 Swati Seela Bản nháp

2 14/02/2014 Vijay Shinde Bản nháp - Đã xem xét

1. PHIÊN BẢN ORANGEHRM 3.0 – MODULE THÔNG TIN

Bí mật công ty Trang 1

1. GIỚI THIỆU .............................................................................................................................5

Bí mật công ty Trang 2

4.2. Kỳ vọng về vai trò .....................................................................................................17

Bí mật công ty Trang 3

1.1. Mục đích

1.2. Tổng quan dự án

1.3. Khán giả

Bí mật công ty Trang 4

2. CHIẾN LƯỢC THỬ NGHIỆM

2.1. Mục tiêu thử nghiệm

Sản phẩm cuối cùng của thử nghiệm có hai phần:

 Một phần mềm sẵn sàng sản xuất;

2.2. Kiểm tra giả định

Các giả định chính

Bí mật công ty Trang 5

Thử nghiệm chức năng

2.3. Nguyên tắc kiểm tra

2.4. Phương pháp tiếp cận dữ liệu

Bí mật công ty Trang 6

2.5. Phạm vi và cấp độ kiểm tra

2.5.1. Khám phá

NGƯỜI KIỂM TRA : Nhóm kiểm tra.

THỜI GIAN : vào đầu mỗi chu kỳ.

2.5.2. Kiểm tra chức năng

NGƯỜI KIỂM TRA : Nhóm kiểm tra.

Bí mật công ty Trang 7

Đăng xuất Sẵn sàng

SẢN PHẨM THỬ NGHIỆM

DANH SÁCH MỤC TIÊU

a) Mọi vấn đề về mức độ sẵn sàng của môi trường Hệ thống

Bí mật công ty Trang 8

2.5.3. Kiểm tra chấp nhận của người dùng (UAT)

SẢN PHẨM THỬ NGHIỆM

2.6. Ước tính nỗ lực kiểm tra

Bí mật công ty Trang 9

4. CHIẾN LƯỢC THỰC HIỆN

4.1. Tiêu chí vào và ra

Đội kiểm Đội kỹ

Tỷ lệ vượt qua 95% của Tập lệnh kiểm tra

4.2. Chu kỳ kiểm tra

Bí mật công ty Trang 10

4.3. Xác nhận và quản lý lỗi

Mức độ nghiêm trọng Sự va chạm

Bí mật công ty Trang 11

4.4. Số liệu kiểm tra

Báo cáo Sự miêu tả Tính thường xuyên

4.5. Theo dõi và báo cáo lỗi

Sơ đồ sau mô tả quá trình theo dõi lỗi:

Bí mật công ty Trang 12

5. QUY TRÌNH QUẢN LÝ KIỂM TRA