CÔNG NGHỆ PHẦN MÈM CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM

Các khái niệm cơ bản về kiểm thử phần mềm Quy trình kiểm thử phần mềm Nguyên tắc kiểm thử phần mềm Kế hoạch kiểm thử phần mềm 5. Chiến thuật kiểm thử phần mềm Các phương pháp kiểm thử phần mềm Chiến lược kiểm thử phần mềm.

Nhóm 4

Nguyễn Hồng Liễu Trần Diệu Linh

Trần Thị Linh

Phạm Thị Như Quỳnh Nguyễn Minh Thư

Nguyễn Thị Thu Dịu

1 Các khái niệm cơ bản về kiểm

b Khái niệm

- Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường như mong đợi không.

- Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một cách sớm nhất và đảm bảo rằng lỗi đã được sửa mà kiểm thử phần mềm không làm công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi

- Mục tiêu của KTPM là thiết kế tài liệu kiểm thử một cách có hệ thống và thực hiện nó sao cho có hiệu quả nhưng tiết kiệm được thời gian, công sức và chi phí.

c Chất lượng phần mềm

- Đặc tả định hướng theo những yêu cầu của khách hàng( như tính hiệu quả, tính bảo mật,…) và những yêu cầu của chính tổ chức phát triển phần mềm

- Một số yêu cầu về chất lượng rất khó chỉ ra

rõ ràng

- Những đặc tả phần mềm thường không đầy

đủ và hay mâu thuẫn

2 Quy trình kiểm thử phần mềm

Quy trình kiểm thử phần mềm là chuỗi các hoạt động được tiến hành để thực hiện việc kiểm thử

- Có rất nhiều quy trình kiểm thử phần mềm khác nhau như: mô hình chữ V, mô hình thác nước, mô hình xoắn ốc…hoặc có thể là mô hình kết hợp những mô hình trên

Quy trình kiểm thử phần mềm gồm

8 bước:

B1: Chuẩn bị chiến lược kiểm tra (Preparing

the test Strategy):

Xác định chiến lược kiểm thử

Giai đoạn này thường phải đặt câu hỏi: Kiểm thử cái gì và kiểm thử như thế nào?

B2: Chuẩn bị kế hoạch kiểm tra (Preparing

the test plan)

- Lập kế hoạch kiểm thử

- Xác định và phân chia một cách hợp lý thời gian, nhân sự, các công cụ được sử dụng cho từng chức năng

B3: Tạo môi trường thử nghiệm (Creating

the test environment):

- Chuẩn bị môi trường, nền tảng cho công việc kiểm thử phần mềm của mình gồm: Hệ điều hành (win 7, win 8, linux, IOS…), Trình duyệt (IE, Safari, Opera…), thiết bị (Moblie, tablet, deskop…)

B4: Viết các trường hợp thử nghiệm / tập

lệnh kiểm tra (Write test cases/Test script)

- Viết testcase cho các trường hợp sẽ test bao gồm cả 3 trường hợp: True, Fail và không xác định kết quả.

B5: Thực hiện các tập lệnh kiểm tra / các

trường hợp thử nghiệm (Executing the test scripts/ test cases):

- Tiến hành thực thi các Case trong testcase/test scrips để thực hiện việc kiểm thử, quá trình này có thể update thêm một

số case còn thiết hoặc những case phát sinh thêm.

B6: Phân tích kết quả báo cáo lỗi (Analyzing the results ad reporting the bugs)

- Phân tích kết quả đã test để tìm hiểu

nguyên nhân gây lỗi, định hướng cách khắc phục

B7: Thực hiện kiểm tra hồi quy (Doing

regression testing):

- Test quy hồi sau khi lỗi đã được sửa.

B8: Thử nghiệm thoát (Test exiting):

- Kết thúc công việc kiểm thử chúng ta cần báo cáo hoặc ghi lại các kinh nghiệm đã gặp phải trong quá trình kiểm thử của mình.

là gì? Tại sao?

QUY TRÌNH KIỂM THỬ

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

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

Chúng sẽ được lập thành tài liệu cho hoạt động kiểm thử

=> Quy

trình kiểm thử phần mềm

1.2 LÍ DO THỰC HIỆN QUY 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ại 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)

1.3 AI LIÊN QUAN ĐẾN VIỆC KIỂM

THỬ PHẦN MỀM?

ch kiể

m thử

Phá

t triển kiể

m thử

Thự

c thi kiể

m thử

Báo cáo kiể

m thử

Phâ

n tích kết quả kiể

m thử

Kiể

m thử lại lỗi

Kết thúc kiể

m thử

sẽ được sửa và lỗi nào sẽ không sửa

Viết test procedure, test scenario, test case, test data và

test script

Tester thực thi phần mềm dựa trên test plan và

test case

Sau khi một lỗi (defect) được DEV sửa xong, chuyển phần mềm cho tester

test lại

Tester điền kết quả test vào test case và tạo báo cáo kết quả test

Khi test đã đáp ứng

được điều kiện dừng Từ đó rút ra các bài học kinh

nghiệm

KHI NÀO NÊN DỪNG KIỂM THỬ

Một vài yếu tố để xác định việc dừng kiểm thử:

•Đáp ứng yêu cầu của khách hàng

•Hoàn thành toàn bộ kịch bản kiểm thử và đóng hết lỗi

•Hoàn thành kiểm thử các chức năng và đạt được mức độ, tiêu chí hoàn thành kiểm thử

•Tỉ lệ lỗi giảm và không còn các lỗi có độ ưu tiên cao

•Hết ngân sách dành cho kiểm thử

•Quyết định của quản lý

1 Định nghĩa 3 Kế hoạch

kiểm thử

3 Kế hoạch kiểm thử

5 Các hoạt động chính trong việc xây dựng kế hoạch kiểm thử

5 Các hoạt động chính trong việc xây dựng kế hoạch kiểm thử

4 Quy trình xây dựng 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à các 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ử.

• 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ề quy 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

2 Nhu cầu cần phải có kế hoạch

kiểm thử

2 Nhu cầu cần phải có kế hoạch

kiểm thử

3 Kế hoạch kiểm

thử

3 Kế hoạch kiểm

thử

• 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

• Môi trường kiểm thử

• Tiêu chí đầu vào và tiêu chí dừng kiểm thử

• Các kết quả phân phối

4 Quy trình xây dựng kế hoạch kiểm

thử

4 Quy trình 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ử

 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 trong project kiểm thử

6 Các hoạt động chính kế hoạch

kiểm thử

6 Các hoạt động chính kế hoạch

kiểm thử

 Cách tiếp cận và các chiến lược

được dùng

• Đặc tả về phương pháp luận kiểm thử

sẽ được dùng để thực hiện kiểm thử

• Ví dụ: Tổng quan về Testing Process Approach cho Project ABC

Đề 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 (Acceptant Testing)

•Kiểm thử chức năng của người dùng (Functionality Testing)

•Kiểm thử hồi quy (Regresstion 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 ninh 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

•Kiểm thử hiệu xuất (Performance Testing)

 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à catalog chưa tất cả các testcase (bao gồm chỉ số testcase, tiêu đề testcase) cũng như tất cả các trạng thái cơ bản.

 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ử.

 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.

 Tiêu chí đình chỉ và 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 thỏa 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ử đã được ngừng trước đó.

 Môi trường kiểm thử

• Đặc tả đầy đủ về các môi trường kiểm thử, bao gồm đặc tả phần cứng, phần mềm, mạng, database, 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ử.

 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

 Tiêu chí dừng kiểm thử và chấp nhậ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 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ác định

• Số lỗi tối thiểu ở các cấp an ninh và ưu tiên khác nhau, số phủ kiểm thử tối thiểu

• Ký kết và đồng thuận của các bên liên quan

 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

 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.

3 NGUYÊN TẮC KIỂM THỬ PHẦN MỀM

Nguyên tắc 1: Kiểm thử chỉ ra sự hiện

diện của lỗi

Kiểm thử có thể chỉ ra có mặt của lỗi, nhưng không thể chứng minh rằng sản phẩm không có lỗi.

Nghĩa là sản phẩm luôn có lỗi cho dù có kiểm thử nhiều bao nhiêu.

Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt

Nguyên tắc 2: Kiểm thử toàn bộ, đầy

đủ là không thể

Kiểm thử toàn bộ (kết hợp tất cả các yếu

tố đầu vào và điều kiện tiên quyết) là không khả thi trừ những trường hợp nhỏ

và đơn giản Thay vì kiểm thử đầy đủ, nên

sử dụng những đánh giá rủi ro và nỗ lực

để ưu tiên tập trung kiểm thử.

Nguyên tắc 3: Cần bắt đầu giai đoạn

kiểm thử càng sớm càng tốt

Hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong chu trình phát triển mềm và cần được tập trung vào các mục tiêu xác định.

Nguyên tắc 4: Sự tập trung của lỗi

 Nguyên tắc tổ gián: chỗ nào có 1 vài

con gián => xung quanh sẽ có cả tổ gián  chỗ nào có một vài bug thì xung quanh chỗ đó sẽ có nhiều bug

 Nguyên tắc 80/20: 20% chức năng

quan trọng trong một chương trình có thể gây ra đến 80% tổng số bug phát hiện được trong chương trình đó

 Kiểm thử đầy đủ là không thể: cần phải

phân tích + tính toán mức độ ưu tiên để quyết định tập trung vào test chỗ nào

Nguyên tắc 5: Nghịch lý thuốc trừ

sâu

Khi sử dụng một loại thuốc trừ sâu mãi thì sâu sẽ bị nhờn thuốc nên phải thay đổi loại thuốc khác

 Dùng đi dùng lại một bộ kịch bản kiểm thử thì sẽ đến lúc không thể tìm ra lỗi mới nữa.

 Các bộ kịch bản kiểm thử phải được thường xuyên xem xét và cập nhật, phù hợp với từng thành phần khác nhau của phần mềm, mang lại khả năng tìm thấy lỗi lớn nhất.

Nguyên tắc 6: Kiểm thử theo các ngữ

cảnh độc lập

Tuy vào loại cũng như bản chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật, cũng như loại kiểm thử khác nhau.

Nguyên tắc 7: Sự sai lầm về việc

không có lỗi

Việc tìm và sửa lỗi là không có ý nghĩa nếu hệ thống được xây dựng xong nhưng không thể dùng được hoặc không đáp ứng được nhu cầu và sự mong đợi của người dùng.

5 Chiến thuật kiểm nghiệm phần

- Kiểm nghiệm có thể được tiến hành bởi người phát triển

phần mềm, nhưng đối với các dự án lớn thì việc kiểm nghiệm phải được tiến hành bởi một nhóm độc lập.

- Kiểm nghiệm và sửa lỗi là các hoạt động độc lập nhưng việc sửa lỗi phải phù hợp với các chiến thuật kiểm nghiệm.

Thiết kế kiến trúc

Thiết kế chi tiết

Thiết kế chi tiết

Lập trình Rà soát Rà soát mãmã

Test đơn vị

Test đơn vị

Test tích hợp

Test tích hợp

Test chấp nhận

6 CÁC PHƯƠNG PHÁP VÀ CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM

Thường thì nó không kiểm thử chi tiết mà chủ yếu

kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu.

• Chủ yếu là kiểm tra cú pháp của code và hoặc

review code hoặc tài liệu để tìm lỗi bằng cách thủ công Đây là loại kiểm thử được thực hiện bởi

DEV, làm việc một cách độc lập

• Lỗi được phát hiện ở giai đoạn phát triển này là ít

tốn kém để sửa chữa hơn so với lỗi phát hiện

được ở các giai đoạn sau này trong các quy trình phát triển phần mềm

6.1.2 Kiểm thử động

• Khái niệm:

Kiểm thử động là phương pháp kiểm thử

phần mềm thông qua việc dùng máy chạy

chương trình để điều tra trạng thái từng động

tác của chương trình.

• Kiểm thử động bao gồm 2 kỹ thuật:

+ Kiểm thử hộp đen

+ Kiểm thử hộp trắng

6.1.6.1 Kiểm thử hộp đen

• Định nghĩa:

Là phương pháp test dựa trên đầu vào và đầu

ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao

Tester xem phần mềm như là một hộp đen.

• Người kiểm thử không quan tâm đến cấu trúc

bên trong của chương trình.

• Chỉ quan tâm đến dữ liệu đầu vào (Input) và

DL đầu ra (Output) sau khi được xử lý.

• Chỉ tập trung vào kiểm tra chức năng của

phần mềm.

• Kiểm thử viên không hiểu về mã lệnh nhưng

có thể tìm ra lỗi mà DEV không phát hiện ra.

• Dựa theo các tài liệu đặc tả, tài liệu phân tích thiết kế để thực hiện test.

• Kiểm thử hộp đen thường do các Tester thực

hiện.

Hoạt động kiểm thử hộp đen

6.1.6.2 Kiểm thử hộp trắng

• Định nghĩa:

Kiểm thử hộp trắng dựa vào thuật toán, cấu

trúc code bên trong của chương trình với

mục đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần.

Hoạt động kiểm thử hộp đen

• Khi thiết kế test case và test, các tester truy cập

thẳng vào bên trong source code, cấu trúc và

thuật toán của chương trình để xác định xem đơn

vị phần mềm thực hiện như thế nào

• Người kiểm thử hộp trắng phải có kỹ năng nhất

định để thông hiểu chi tiết về đoạn code cần kiểm

thử

• Kỹ thuật này chủ yếu dược dùng để kiểm thử

mức đơn vị

• Có những lỗi xảy ra trong quá trình gõ bàn phím, hiểu sai cú pháp của ngôn ngữ lập trình chưa đúng nên bắt buộc phải kiểm thử hộp trắng.

• Kỹ thuật kiểm thử hộp trắng thường được các

DEV thực hiện trong quá trình viết code ở

giai đoạn kiểm thử mức đơn vị luôn.