chuong 2
Chương 2
Qui trình & Kế hoạch kiểm thử phần mềm
2.1 Giới thiệu
1. Qui trình kiểm thử phần mềm là gì ?
Chế ₫ộ kiểm thử ₫ược ₫ịnh nghĩa bởi tổ chức phát triển
phần mềm là gì.
Cần có chiến lược kiểm thử và nó sẽ lý giải tại sao tổ chức
phần mềm kiểm thử các thành phần mà mình tạo ra.
Cần nhận dạng cái gì là quan trọng ₫ối với tổ chức (chi
phí, chất lượng, thời gian, phạm vi,..) và cách nào, bởi ai
và khi nào việc kiểm thử sẽ ₫ược thực hiện.
Tất cả các thông tin trên sẽ ₫ược lập thành tài liệu cho
hoạt ₫ộng kiểm thử và ta có thể gọi qui trình tạo lập tài liệu
này là qui trình kiểm thử phần mềm (Test Process).
2. Tạo sao cần phải thực hiện qui trình kiểm thử phần mềm ?
Cần làm rõ vai trò và trách nhiệm của việc kiểm thử phần
mềm.
Cần làm rõ các công ₫oạn, các bước kiểm thử.
Cần phải hiểu và phân biệt các tính chất kiểm thử (tạo sao
phải kiểm thử), các bước kiểm thử (khi nào kiểm thử), và
các kỹ thuật kiểm thử (kiểm thử bằng cách nào).
3. Chúng ta phải kiểm thử phần mềm khi nào ?
RUP Life
Cycle
Kiểm thử sẽ ₫ược
thực hiện sau mỗi
bước lặp.
Mô hình phát triển và kiểm thử phần mềm hình chữ V
Requirements
Definition
Preparation
Acceptance
t t
Preparation
System test
Acceptance Test
V
Functional system
a
design
lid
a ti
on
St
Technical system
ag
design
e
System Test
Preparation
Integration
t t
Integration
Test
Ver
ific
atio
n
Sta
ge
Component
Specification
Unit/Component
Test
Programming
Các tính chất cần ghi nhận trên mô hình chữ V :
Các hoạt ₫ộng hiện thực và các hoạt ₫ộng kiểm thử ₫ược
tách biệt nhưng ₫ộ quan trọng là như nhau.
Chữ V minh họa các khía cạnh của hoạt ₫ộng Verification
và Validation.
Cần phân biệt giữa các mức ₫ộ kiểm thử ở ₫ó mỗi mức
kiểm thử là kiểm thử trên mức phát triển phần mềm tương
ứng.
Mô hình phát triển tăng tiến-tương tác :
Qui trình thiết lập các yêu cầu phần mềm, thiết kế, xây
dựng, kiểm thử hệ thống phần mềm ₫ược thực hiện như 1
chuỗi các chu kỳ phát triển ngắn hơn.
Hệ thống có ₫ược từ 1 bước lặp ₫ược kiểm thử ở nhiều cấp
trong việc phát triển hệ thống ₫ó.
Kiểm thử hồi quy có ₫ộ quan trọng tăng dần theo các bước
lặp (không cần trong bước ₫ầu tiên).
Thanh kiểm tra và kiểm ₫ịnh có thể ₫ược thực hiện theo
kiểu tăng dần trên từng bước lặp.
Các tính chất của qui trình kiểm thử tốt :
Cần có 1 mức ₫ộ kiểm thử cho mỗi công ₫oạn phát triển
phần mềm.
Các mục tiêu kiểm thử sẽ bị thay ₫ổi, mỗi mức kiểm thử
nên có các mục tiêu ₫ặc thù của mình.
Việc phân tích và thiết kế testcase cho 1 mức ₫ộ kiểm thử
nên bắt ₫ầu sớm nhất như có thể có.
Các tester nên xem xét các tài liệu sớm như có thể có,
ngay sau khi các tài liệu này ₫ược tạo ra trong chu kỳ phát
triển phần mềm.
Số lượng và cường ₫ộ của các mức kiểm thử ₫ược ₫iều
khiển theo các yêu cầu ₫ặc thù của project phần mềm ₫ó.
Sơ ₫ồ tổ chức phổ biến của ₫ội kiểm thử
4. Ai liên quan ₫ến việc kiểm thử phần mềm ?
Test Manager
Test Architect
Test Leader
Test Analyst
Test Designer
Tester 1
Tester 2
Tester 3
Tester n
2.2 Qui trình kiểm thử tổng quát
•
Requirements/ Scope
•
Specified (what will be test?)
•
Test Estimation
•
Strategy Testing
•
Types of Test
•
Environment Test
•
Requirements
•
Specified Requirements
•
Test Plan
•
Test Cases/ Test Scripts
•
Test Procedures
•
Test Scenarios
•
Test Data
Test Planning
(Manual or Automation)
Manager
•
Test
Test Plan
Test Analysis & Design
(Manual or Automation)
Analyst
•
Test
•
Test Cases/ Test Scripts
•
Test Procedures
•
Test Scenarios
•
Test Data
•
Test
•
Test
Test Executing
(Manual or Automation)
•
Tester
Results
Test Results
Test Report
& Evaluation
•
Tester
•
Test
Final Test Reports
Xây dựng kế hoạch kiểm thử
Test Planning
Test Analysis & Design
(Manual or Automation)
Test Executing
(Manual or Automation)
Test Report
& Evaluation
Test Manager hoặc Test Leader sẽ xây dựng kế hoạch ban
₫ầu về kiểm thử.
Định nghĩa phạm vi kiểm thử
Định nghĩa các chiến lược kiểm thử
Nhận dạng các rủi ro và yếu tố bất ngờ
Nhận dạng các hoạt ₫ộng kiểm thử nào là thủ công, kiểm
thử nào là tự ₫ộng hay cả hai.
Ước lượng chi phí kiểm thử và xây dựng lịch kiểm thử.
Nhận dạng môi trường kiểm thử.
...
Kế hoạch kiểm thử cần ₫ược :
xem lại bởi QC team, Developers, Business Analysis. TA
(if need), PM and Customer
Chấp thuận bởi : Project Manager and Customer
Hiệu chỉnh trong suốt chu kỳ kiểm thử ₫ể phản ánh các
thay ₫ổi nếu cần thiết.
Phân tích & thiết kế kiểm thử
Test Planning
Test Analysis & Design
(Manual or Automation)
Test Executing
(Manual or Automation)
Test Report
& Evaluation
Test Analyst hoặc Test Designer sẽ thiết kế (₫ịnh nghĩa) các
testcase từ các yêu cầu liên quan (thí dụ từ thông tin trong
usecase).
sẽ thiết kế (₫ịnh nghĩa) các testcase từ các yêu cầu chức
năng và các yêu cầu không chức năng của phần mềm.
Các testcase cần bao phủ tất cả khía cạnh kiểm thử cho
từng yêu cầu phần mềm.
Các testcase cần bao phủ tất cả yêu cầu trong các chiến
lược kiểm thử.
Nếu cần kiểm thử tự ₫ộng, Test Designer sẽ xây dựng các
kịch bản dựa trên các testcase/Test procedures.
Các testcase cần ₫ược :
Xem xét lại bởi Project Leader, Developer có liên quan,
các Testers khác, Test Leader, Business Analysis và
Customer.
Chấp thuận bởi Test Leader hoặc Customer
Hiệu chỉnh/cập nhật nếu Tester ₫ã tìm ₫ược những lỗi mà
không nằm trong các testcase hiện có.
Thi hành kiểm thử
Test Planning
Test Analysis & Design
(Manual or Automation)
Test Executing
(Manual or Automation)
Test Report
& Evaluation
Testers sẽ ₫ược bố trí công việc bởi Test Leader ₫ể thi hành
kiểm thử.
Thi hành kiểm thử theo từng testcase.
Thực hiện kiểm thử ₫ặc biệt (ad-hoc)
Thực hiện kịch bản kiểm thử mà không ₫ược ₫ịnh nghĩa
trong testcase.
Kiểm thử lại các lỗi ₫ã ₫ược sửa.
Tester sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm
lỗi và theo dõi chúng cho ₫ến khi chúng ₫ã ₫ược xử lý.
Ở công ₫oạn kiểm thử ₫ộ chấp thuận, Customer sẽ thi
hành kiểm thử ₫ể kiểm ₫ịnh xem hệ thống phần mềm có
thỏa mãn các nhu cầu người dùng không ?
Test Execution Workflow
Get build to
execute test
Reject Builds
Ready for
test?
Yes
Execute Test
(test cases)
Re-Test
(Fixed defects)
No
Close defects
Yes
Found
defects?
No
Create
test report
Submit/ Re-Open
Defects to tracking system (*)
No
*
Xem qui trình xử lý lỗi
ở
slide kế
Yes
Pass?
Defects Workflow
Defect in system
Update more
information
Review by
Test Lead, Dev Lead, PM
Yes
Assign back to Tester
for more information
Explain why and
Ask Tester close
Defect.
Ambiguous
No
No
Really
Check in to build
Assign to Tester
No
Re-Test
Yes
Can fix
Yes
Close defect
Explain why and
Ask approval
from PM/ Leaders
Yes
Assign Developer
to fix
No
Pending defect
Test Report and Evaluation
Test Planning
Test Analysis & Design
(Manual or Automation)
Test Executing
(Manual or Automation)
Test Report
& Evaluation
Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ
thống theo dõi các lỗi.
Tạo các báo cáo lỗi.
Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay
₫ổi.
Tính và phân phối các thông tin ₫o lường hoạt ₫ộng kiểm
thử.
Tạo bảng tổng kết ₫ánh giá hoạt ₫ộng kiểm lỗi.
Xác ₫ịnh xem ₫ã ₫ạt tiêu chí thành công và hoàn thành
kiểm thử chưa.
2.3 Kế hoạch kiểm thử
1. Định nghĩa :
Kế hoạch kiểm thử thường ₫ược ₫ể trong 1 file
và chứa các kết quả của các hoạt ₫ộng sau :
Nhận dạng các chiến lược ₫ược dùng ₫ể kiểm tra và ₫ảm
bảo rằng sản phẩm thỏa mãn ₫ặc tả thiết kế phần mềm và
các yêu cầu khác về phần mềm.
Định nghĩa các mục tiêu và phạm vi của nỗ lực kiểm thử.
Nhận dạng phương pháp luận mà ₫ội kiểm thử sẽ dùng ₫ể
thực hiện công việc kiểm thử.
Nhận dạng phần cứng, phần mềm và các tiện ích cần cho
kiểm thử.
Nhận dạng các tính chất và chức năng sẽ ₫ược kiểm thử.
Xác ₫ịnh các hệ số rủi ro gây nguy hại cho việc kiểm thử.
Lập lịch kiểm thử và phân phối công việc cho mỗi thành
viên tham gia.
…
Test Manager hoặc Test Leader sẽ xây dựng kế hoạch kiểm
thử.
2. Nhu cầu cần phải có kế hoạch kiểm thử :
Kế hoạch kiểm thử
cần phải ₫ược xây dựng sớm như có thể có trong mỗi chu kỳ phát
triển phần mềm ₫ể :
Tập hợp và tổ chức các thông tin kiểm thử cần thiết.
Cung cấp thông tin về qui trình kiểm thử sẽ xảy ra trong tổ
chức kiểm thử.
Cho mỗi thành viên trong ₫ội kiểm thử có hướng ₫i ₫úng.
Gán các trách nhiệm rõ ràng cụ thể cho mỗi thành viên ₫ội
kiểm thử.
Có lịch biểu làm việc rõ ràng và các thành viên có thể làm
việc với nhau tốt.
3. Kế hoạch kiểm thử
cần chứa các thông tin sau ₫ây :
Phạm vi/mục tiêu kiểm thử
Các chiến lược ₫ược dùng
Các tài nguyên phần cứng và phần mềm phục vụ kiểm
thử.
Các nhu cầu về nhân viên và huấn luyện nhân viên.
Các tính chất cần ₫ược kiểm thử.
Các tính chất không cần kiểm thử.
Các rủi ro & sự cố bất ngờ.
Lịch kiểm thử cụ thể.
Các kênh thông tin liên lạc.
Cấu hình cho từng phần tử như kế hoạch kiểm thử,
testcase, thủ tục kiểm thử,...
Môi trường kiểm thử (Test bed)
Tiêu chí ₫ầu vào và tiêu chí dừng kiểm thử.
Các kết quả phân phối.
Test Plan Workflow
4. Qui trình xây dựng kế hoạch kiểm thử :
Starting Project
Define Testing Scope
and Objectives
Define Testing
Methodology
Review Test Plan
Identify Required
Resources
Identify Features
And Functions to test
Identify Risk Factors
Rework
?
N
Approved and
Baselined Test
Plan
Yes
Establish a
Testing Schedule
(need estimation)
Compose Test Plan
Ghi chú quan trọng :
Sau khi xây dựng xong kế hoạch kiểm thử, ta có thể thay ₫ổi
nó nhưng phải tuân thủ qui trình yêu cầu thay ₫ổi.
Main activities
5. Các hoạt ₫ộng chính trong việc xây dựng kế hoạch kiểm
thử :
Định nghĩa mục ₫ích, phạm vi, chiến lược, cách tiếp cận,
các ₫iều kiện chuyển, các rủi ro, kế hoạch giảm nhẹ và
tiêu chí chấp thuận.
Định nghĩa cách thức thiết lập môi trường và các tài
nguyên ₫ược dùng cho việc kiểm thử.
Thiết lập cơ chế theo dõi lỗi phát hiện.
Chuẩn bị ma trận theo dõi bao phủ mọi yêu cầu phần
mềm.
Báo cáo trạng thái kiểm thử.
Phát hành leo thang (Escalating Issues)
Raising Testing related PIR (Process Improvement
Request) / PCR (Process Change Request)
2.4 Các thành phần chính trong kế hoạch kiểm thử
1. Mục ₫ích và phạm vi kiểm thử :
Đặc tả mục ₫ích của tài liệu về kế hoạch kiểm thử.
Cung cấp vắn tắt về phạm vi mà project ₫ược hỗ trợ như
platform, loại database, hay danh sách vắn tắt về các loại
project con in project kiểm thử.
Thí dụ :
Testing scope
This section to provide test requirements, strategies as below:
•
Operation will be tested: Windows XP SP2, SP3 + Latest security updated from
Microsoft.
•
Database type: Microsoft SQL Server 2005
•
Browsers: Internet Explorer 7
•
The sub-products will be tested as below:
Quality Monitoring 9.0 SP3
Agent Capture
UST/BUIT
Media Testing
Documents verification
Installation/Upgrade testing
2. Cách tiếp cận & các chiến lược ₫ược dùng :
Đặc tả về phương phạm luận kiểm thử sẽ ₫ược dùng ₫ể
thực hiện kiểm thử.
Thí dụ : General Testing Process Approach for Project
ABC
Design
Test
Approach
Review
Project
Document &
Participate in
Project
Planning
Exercises
Create
Test
Plan
Determine
Test
Requirements
Design
and
Build
Test
Execute
Plan
Create
Certification
Report
Đề cập các cấp ₫ộ kiểm thử cần thực hiện
Các kỹ thuật ₫ược dùng cho mỗi kiểu kiểm thử trong project :
Kiểm thử tích hợp (Integration Testing)
Kiểm thử hệ thống (System Testing)
Kiểm thử ₫ộ chấp thuận (Acceptance Testing)
Kiểm thử chức năng của người dùng (Functionality
Testing)
Kiểm thử hồi qui (Regression Testing)
Kiểm thử việc phục hồi sau lỗi (Failover and Recovery
Testing)
Kiểm thử việc kiểm soát an minh và truy xuất (Security and
Access Control Testing)
Kiểm thử việc cấu hình và cài ₫ặt (Configuration and
Installation Testing)
Kiểm thử ₫ặc biệt (Ad-hoc Testing)
Kiểm thử hiệu suất (Performance Testing)
3. Các tính chất cần ₫ược kiểm thử :
Danh sách các tính chất của phần mềm cần ₫ược kiểm
thử, ₫ây là 1 catalog chứa tất cả các testcase (bao gồm
chỉ số testcase, tiêu ₫ề testcase) cũng như tất cả trạng
thái cơ bản.
Thí dụ :
4. Các tính chất không cần ₫ược kiểm thử :
Danh sách các vùng phần mềm ₫ược loại trừ khỏi kiểm
thử, cũng như các testcase ₫ã ₫ược ₫ịnh nghĩa nhưng
không cần kiểm thử.
Thí dụ :
5. Rủi ro và các sự cố bất ngờ
Danh sách tất cả rủi ro có thể xảy ra trong chu kỳ kiểm
thử.
Phương pháp mà ta cần thực hiện ₫ể tối thiểu hóa hay
sống chung với rủi ro.
Thí dụ :
6. Tiêu chí ₫ình chỉ & phục hồi kiểm thử :
Tiêu chí ₫ình chỉ kiểm thử là các ₫iều kiện mà nếu thoả
mãn thì kiểm thử sẽ dừng lại.
Tiêu chí phục hồi là những ₫iều kiện ₫ược ₫òi hỏi ₫ể tiếp
tục việc kiểm thử ₫ã bị ngừng trước ₫ó.
Thí dụ :
1.6 Các nguyên tắc cơ bản về kiểm thử
Suspension Criteria
The testing will be halted if these criteria below happen:
•
No build notes or it is not clear
•
There are some Fatal errors in smoke test build without work around solutions
Resumption Criteria
The testing will be resumed if the build has:
•
Build notes clearly
•
Any fatal errors with work around solutions
•
Test cases had been baselined
7. Môi trường kiểm thử
Đặc tả ₫ầy ₫ủ về các môi trường kiểm thử, bao gồm ₫ăc5
tả phần cứng, mạng, database, phần mềm, hệ ₫iều hành
và các thuộc tính môi trường khác ảnh hưởng ₫ến kiểm
thử.
Thí dụ
8. Lịch kiểm thử :
Lịch kiểm thử ở dạng ước lượng, nên chứa các thông tin :
các cột mốc với ngày xác ₫ịnh + Kết quả phân phối của
từng cột mốc.
Thí dụ :
9. Tiêu chí dừng kiểm thử & chấp thuận :
Bất kỳ chuẩn chất lượng mong muốn nào mà phần mềm phải
thỏa mãn hầu sẵn sàng cho việc phân phối ₫ến khách hàng. Có
thể bao gồm các thứ sau :
Các yêu cầu mà phần mềm phải ₫ược kiểm thử dưới các
môi trường xáx ₫ịnh.
Số lỗi tối thiểu ở cấp an ninh và ưu tiên khác nhau, số phủ
kiểm thử tổi thiểu,...
Stakeholder sign-off and consensus
Thí dụ :
10. Nhân sự :
Vai trò và trách nhiệm từng người :
Danh sách các vai trò xác ₫ịnh của các thành viên ₫ội
kiểm thử trong hoạt ₫ộng kiểm thử.
Các trách nhiệm của từng vai trò.
Công tác huấn luyện.
Danh sách các huấn luyện cần thiết cho các QC
Thí dụ : xem slide kế
11. Các tiện ích phục vụ kiểm thử :
danh sách tất cả các tiện ích cần dùng trong suốt chu kỳ
kiểm thử.
Với project kiểm thử tự ₫ộng, các tiện ích cần ₫ược liệt kê
với chỉ số version cùng thông tin license.
Thí dụ :
Test Tools
During the test cycle, following tools will be used with its purposes:
Guru site: repository for the latest requirements, test metrics
Automation Test tool
Because there is requested for performance test, tool below will be used with license had
been payment fully.
•
•
HP Quality Center: for storing Test cases, Defects and Test cases status
•
HP LoadRunner 9.2
12. Các kết quả phân phối :
danh sách tất cả tài liệu hay artifacts dự ₫ịnh phân phối nội
bộ sau khi mỗi cột mốc kết thúc hay sau khi project kết
thúc.
Thí dụ :
Test Deliverables
Following is documents, artifacts that will be delivered at the end of testing life cycle
•
Test cases
•
Status for each Test cases under tested
•
Defect reports
•
Defect metric will be delivered weekly along with weekly report of project
•
Test Scripts for performance test with its results
•
Certification test
2.5 Một số ₫iểm chính cần nhớ
Mục ₫ích & phạm vi kiểm thử
Cách tiếp cận & các chiến lược kiểm thử ₫ược dùng.
Các tính chất cần ₫ược kiểm thử/ không cần kiểm thử
Lịch kiểm thử
Nhân sự
Môi trường kiểm thử
Tạm dừng/Tiếp tục kiểm thử
Kiểm thử ₫ộ chấp thuận
Các tiện ích kiểm thử cần dùng
Rủi ro và yếu tố bất ngờ
Các kết quả phân phối nội bộ
2.6 Kết chương
Chương này ₫ã giới thiệu 1 số vấn ₫ề cơ bản liên quan ₫ến qui
trình kiểm thử phần mềm như qui trình kiểm thử là gì, tạo sao phải
kiểm thử phần mềm, khi nào kiểm thử, ai có liên quan ₫ến việc
kiểm thử, qui trình kiểm thử gồm các bước chi tiết nào ?
Chúng ta cũng ₫ã trình bày các nội dung trong bản kế hoạch
kiểm thử phần mềm như mục ₫ích & phạm vi kiểm thử, cách tiếp
cận & các chiến lược kiểm thử ₫ược dùng, các tính chất cần ₫ược
kiểm thử/ không cần kiểm thử, lịch kiểm thử, nhân sự, môi trường
kiểm thử, khi nào tạm dừng/tiếp tục kiểm thử, kiểm thử ₫ộ chấp
thuận, các tiện ích kiểm thử cần dùng, rủi ro và yếu tố bất ngờ, các
kết quả phân phối nội bộ...
Bạn đang đọc truyện trên: AzTruyen.Top