Luận văn kiểm thử phần mềm nhúng

Vai trỏ của kiểm thứ viên trong chụ bình phát triển phần mềm 2.5.3 Vai trò cửa kiểm thử viên rong chải lượng phản mrêtu Chương TĨ: Ấp dụng các phương pháp kiểm thử trong phát triển p

Trang 1

„ BỘ GIÁO DỤC VÀ ĐÀO TAO |

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

NGUYEN VAN TRONG

KIEM THU PHAN MEM NHUNG

LUAN VAN THAC SI KHOA HQC

CHUYEN NGANH: CONG NGHE THONG TIN

NGUOI HUGNG DAN KHOA HOC:

Hà Nội - 2009

Trang 2

BỘ GIÁO DỤC VÀ ĐÀO TẠO |

TRUONG DAI HOC BACH KHOA HA NOI

NGUYEN VAN TRONG

KIEM THU PHAN MEM NHUNG

LUẬN VĂN THẠC SĨ KHOA HỌC CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC

PGS.TS HUỲNH QUYẾT THẮNG

Hà Nội - 2009

Trang 3

Đồ án tốt nghiệp cao học: Äfế đưi phần mÈM những

LỚI CAM DOAN

Tôi — Nguyễn Văn Trọng Học viên lớp Cao học CNTT 2006-2008 Trường Đại học Bach Khoa Hà Nội - cam kết L.VTN là công trình nghiên cửu của băn thân tôi dưới sự tướng dẫn của PGs.T8 Huỳnh Quyết Thắng Bộ môn Công nghệ Phần mềm — Khoa CNTT - Trường Đại học Bách Khoa Hà Nội

ác kết quả nêu trong T.VTN là trung thực, không sao chép toàn văn của bài kỳ công,

Giảng viên hướng dẫn: PGS.TS Huỳnh Quyết Thăng

Hoe viên: NguyỄn Văn Trạng Trang 1/78

Trang 4

TOM TAT LUAN VAN

Luận văn tốt nghiệp đã nghiên cứu khá dây đủ cơ sở lý thuyết về kiểm thử, vai tro

của kiếm thử trong dự án phân mềm Tác giả đã đi sâu vào thực tế phát triển phản mềm

của cổng †y FPT đê đưa ra mô hình làm việc của kiểm thứ viên

Đưa ra quy trình kiểm thứ dịch vụ trực tuyển OSIRTS cho mấy in tem thư lại công

ty FPT Đưa ra kiến nghị thay đôi biểu mẫu bảo cáo cho dịch vụ trực tuyến OSIRL3,

Kiểm xoái vòng, đời của lỗi là một van đề đặc biệt quan trọng đối vơi dự ám phát

triển phân mềm Dụa vào quy trình phát triển sản phẩm, mỗi công ty xây dựng chu trình thay dỗi trang thái của lỗi Tác giã dựa vào mô hình phát triển phân mềm tai cong

ty FPT dé dua ra chu trình thay đổi trạng thái lỗi Trong chu trình nảy, vai trò của

những người liên quan, trạng thái hiện tại, và trạng thái tiệp theo của lỗi được trình by TẤI rõ rằng

Trang 5

MỤC LỤC

LO] CAM DOAN

TOM TAT LUJAN VAN

DANH MỤC CÁC THUẬT NGU VA TU VIET TAT

Câu trúc huận văn

CHƯƠNG 1: TONG QUAN VE KIFM THU TRONG PHAT TRI

11 Tarn quan trọng trong phat idm phn mém

LLL M6t sé dinh nghia hén quan dén kiém thir

LL2 Mục tiêu của kiém thir

12 Các hoạt dòng của nhân viên kiểm thử

12.1 Mêtã công việc của kiểm thử viên tạ công ty FP -

12.2 _ Luỗng công việc mã nhân viên kiểm thử phải thực hiện trong dự án 16 12.3 Quy Irinh Tim việc của nhần viên kiểm thử phân tmễm - - 7

13 Các đặc lưng của kiếm thi phan mdm - 7

14.1 Phạmvikiểmthử coecsceeoceoseeee LB

134 id 19

12 Các hoạt động và tài liệu trong quá trình kiểm thứ - 24

ẳ các tải liệu trong kiểm thứ à sicceiecerrreo TỔ nức độ kiểm thử ((heo mô hình chữ V} - 26

Trang 6

Kiếm thr pin ned rưưing

25 'Vai trò của người thực Hiện kiểm Thử

2.5.1 Vai trò của kiểm thứviên đối với tổ chức công ty FPT,

2.5.2 Vai trỏ của kiểm thứ viên trong chụ bình phát triển phần mềm

2.5.3 Vai trò cửa kiểm thử viên rong chải lượng phản mrêtu

Chương TĨ: Ấp dụng các phương pháp kiểm thử trong phát triển phân mềm nhúng

Kiễm thử các xảy in tem thư

Diuvao Đẩnra

Môi trường quân ly tài

Câu trúc hệ thông ca kiếm thử của mày KEOPS

Các hoạt déng trong qua trình kiểm thử

Các công cụ hỗ trợ kiểu thứ

Tuyệt khối trước khí kiểm thứ tích hợp

Tao cao kết quả thir Kiểm thử hệ thông địch vụ b

Phân loại lỗi trong OSIRIS

‘Vong đời của lỗi trên Dimension

Thực hiện kiểm thứ rrức lch hợp Bao cao kết quả kiểm thủ

L Các nhiệm vụ đã hoàn thành

ác đồng gón khoa học

3 Hướng phải triển của luận vẫn

TẢI LIỆU THAM KHẢO

Giảng viên hướng dẫn: PGS.TS Huỳnh Quyết Thang

Hoe viên: NguyỄn Văn Trạng

Trang 7

Đỗ án tốt nghiệp cao học: Kiém thit phan mém ning

SIT "viết tắt Thuật ngữ và từ đầy đủ 'Ý nghĩa

American National Standards) yo je pe ý g

3 IEEE stitute ‘of Electrical Electronies | viên ky thuat ign & điện từ Engineers

4 | 180 International Organization Tổ chức Tiêu chuẩn hóa quốc

10 STP Kế hoạch kiểm thử Kiểm thử theo hộp trắng,

11 SEI Software Engineering Institute Viện công nghệ phần mềm

13 | sv Software Validation _ phần mềm Kaen “thn ante! pap eaten

14 | UT Unit Test _Kiểm thử mức khôi

Giang viên hướng dẫn: PGS.TS Huỳnh Quyết Thắng

Trang 8

Tang 2.3: Quyén thay đối trang thái của lỗi - - - 30

: Vai trò của kim thử viên về mặt quản ly

: Vai trò của kiểm thứ viên về mặt kỹ thuật Bang 2.6: Vai tro cia kiém thứ viên tại công ty FPT

Bang 3.1: Cae module kiểm thử của đồng tuảy KEOPS và các dòng máy khác

Bằng 3.2: Báo cáo kết quả duyệt khói

Bảng 3.3: Báo cáo kiểm thử cho máy in tem thụ

Bang 3.4: Các pha trong quá trình kiểm thứ hệ thẳng OSIIIS

Tăng 3.5: Phân loại lỗi

Thăng 3.6: Một số lỗi đã được lưu lại trong dự ân kiểm thử OSTRIS phiên bản 2.4

Bảng 3.7: Các modulc trong quá trình kiểm thứ tích hợp hệ thông OSIRIS

Bang 3.8: Bao cdo két qua kiém thir cho module CM

Bang 3.9: Béo cáo kết quả kiếm thử theo mức độ quan trọng

Tiảng 3.10: Báo cáo tông hợp vệ Lý lệ rác ca thành công hoặc thải bại

Bằng 3.11: Báo cáo tổng hợp về tỷ lệ các ca thành công hoặc thẬt bại cho nước Anh

Bang 3.12: Báo cáo tổng hợp và tỷ lệ các ca thành oông hoặc that bai cho nước Pháp

Bing 3.13: Báo cáo tổng hợp vệ tỷ lê oá ảnh công hoặc thất bại cho nước Đức

Tiẳng 3.14: Báo cáo tổng hợp về tỷ lệ các ca thành công hoặc thất bai cho nước Treland 75

Trang 9

Luỗng công việc mà kiếm thử viên phải thực hiện tại công ty FPT

Quy trinh làm viêc của nhân viên kiệm thứ tại công ty FPT

Các đặc trưng của kiểm thứ phần mèm M LT

Sự tham gia của kiêm thử viên về mặt kỳ nghệ

Nguyên lý vòng đời quản lý chất lượng

Vong đời chất hương tại cing ty PT

Sơ đồ hoại động kiểm thử rên nay int tern thir tai công, gly FPT 42

Mỗi trường quản lý tải liệu tại công ty FPT - - 4

Các module can kiém thứ cho máy in tem thu - - - 44 Cây phân cấp của các ca kiểm thử máy in tem thư - 44

Cây phân cần của các ca kiểm thir Base va Meter - Cây phân câp của các cá kiểm thử Base và MctcL ào sc si Các hoạt động của nhân viên kiểm thử máy in tem thu - - 50

Trang 10

Trước hết, em xin được chân thành gửi lời cằm ơn sâu sẵo tới các

thay cô giáo trong trường Dại học Bách Khoa là Nội nói chung và các thấp cô trong khoa Công nghệ Thông tin, bộ môn Công nghệ phẩn mẫm nói riêng đã tận tình giảng day, nuyền đạt cho em những kiến thức và

những kinh nghiệm quý bảu trong suất 2 năm học lập và nghiên cứu tại

trường Dai hoe Bach Khoa H

Lim xin được gửi lời cảm on dén PGS TS Uujnh Quyét Thing -

khoa Công nghệ Thông tin, tường Đại học Bách Khoa Hà Nội dã hết

lòng guúp đã, hướng dẫn và chỉ day tận tình trong qua trình em làm luận

- Trường Đại học Bách Khoa Hà Nội

fing 8/78

Trang 11

MỞ ĐẦU

1 Tinh cấp thiết của dé tai

Chất lượng phần mẻm là thành phản quan trọng nhất trong phát triển phần rẻm vỉ phân mềm chất hượng cao có thể làm giảm giá thành bão trì, kiểm tra, bão mật và có

thể sử dụng lại Trong thục tế, để đâm bão chất lượng của phần mnêm, khâu kiếm thử

dong vai trỏ chính trong việc số các nhà phát triển và phần lớn người sử dụng phan mềm nghiêm túc yêu cầu một cách đánh giá chất hượng nào đó cho các hệ thông phân mềm mã họ có liên quan

Trong các ngôn ngữ lập trình hướng đổi rượng và các phương pháp phát triển chất lượng phan uẻm trước đây, nhiều nghiên cửu quan trọng đã nỗ lực định nghĩa các độ

do chất lượng và xây đựng các mô hình chất lượng dựa trên các độ do này Các độ do

nghiên cửu mã nguồn hướng đổi tượng hoặc các chỉ tiết thiết kế, bao gềm thao tác

phân tích câu trúc cáo chỉ tiết phụ thuộc của các lớp vá các thánh phan bên trong, (chẳng lạm, cáo lớp bên trong, các dữ liệu thành viên, gáo phương thúc), Giá thuyết là

Thuộc tính chất ing han tinh bao

ti, độ tin ch Sau đó các mô hinh du đoán như vậy được ding dé hỗ trợ việc tạo

quyết dịnh trong quá trình phát triển

Trong các tải liệu đã định nghĩa một số lượng lớn các phép đo chất lượng Hầu hét các phép đo đều dựa trên các giá thiết hợp lý nhưng tốn tại một câu hỏi quan trọng là

những độ đo nảo thal sự hữu ích, có liên quan đến bất kỳ các thuộc tính chát lượng

ngoại Chúng ta cũng cân kiểm tra cách áp dụng các độ đo trong thực tế, chúng có dẫn đến mô hình chỉ phí - liệu quả trong ứng dụng eụ thể hay không, Với mục đích thực hiện các câu hỏi trên đã có rất nhiễu nghiên cứu thực nghiệm được thực hiện và báo

cảo nhưng, chúng ta rất khỏ tổng hợp kiến thức và xác định các hướng nghiên cửu tương lai Một trong các lý do chính để là các nghiên cứu rải đa dạng và thiểu ôn định trong kết quá

9 Tim hiểu quy trình phát triển phản mềm, quy trình kiểm thứ phản mềm nói

chung va quy trình kiểm thử phân tiềm những nói riêng

©_ Tìm hiếu, để xuất các mô hình kiểm thữ phản mẻm nhúng

9 Thử nghiệm mô hình kiêm thứ phần mềm nhúng

Trang 12

3 Nhiệm vụ nghiên cứu

©_ Tìm hiểu tế chức hệ thông ca kiểm thử phân mêm của máy in tem thư

9 Xây dựng quy trình kiểm thử phản mềm cho các máy ¡n tem thu

$_ Xây dựng quy trình kiểm thử phản mềm OSIBIS cho các máy mì tem thư

4 Pham ví nghiên cửu

Néu phan mém được phát triển theo rnô hình c ä bến giai đoạn kiếm thử Trong phạm vi của đề tải, dựa váo thục tế phát triển hệ thông máy ¡n tem thư tại công

†y FPT, tác giả để xuất kiếm thử múc khôi phải được thực hiện bởi nhân viên lấp trình

Kiểm thứ viên sẽ thực hiện Duyệt khối vã sau đó thực biện tích hợp phần cứng và phần xểm Ngoài ra, dịch vụ trực tuyển OSIRTS có giao tiếp với khách hàng, vì vậy tác giả tập trung vào pha kiếm thử xác nhận để làm nồi bật mức kiếm thử này

5 Cầu trúc luận văn

Bồ cục của luận văn bao gồm 3 chương:

1 Chương l: Tổng quan về liếm thử trong phát triển phần mềm

Chương này nêu lên tằm quan trọng của kiểm thử phân mềm Các hoạt động của

nhân viên kiểm thử, cac đặc trưng của kiểm thử phẫn mềm

chương nảy

3 Chương II: Ấp dụng các phương pháp kiểm thử trong phát triển phân

mễm nhúng

Chương 3 trình bảy các nội dưng về việc áp đụng mô hình kiểm thử vào kí

thử phân mềm nhúng trên các máy in tem ta va dich vu true tuyén OSIRTS của

công ty FPT

Hoe viên: NguyỄn Văn Trạng “Trang 10/78

Trang 13

Cuỗi cùng là các đánh giá kết huận clưang về các kết quả của luận vẫn, các hạn chế

và các phương hướng phát triển cho luận văn trong tương lai

6 Phương pháp nghiên cứu

+Để đám báo chất lượng phản mềm, chủng ta nhất thiết phải tiến bánh kiểm thứ cho cde

sản phẩm lạo ra trong quá trình phát triển Mỗi giai đoạn phải triển sẽ có một cần độ và

phương pháp kiểm thử riêng

Nghiên cứu này lựa chọn mỏ hình chữ V dễ đi sâu phân tích các cấp độ, các tai liệu,

các thao Tác liên quan đên kiếm thử phân mềm Nghiên cứu này đựa trên thục tế tiến

hành dự án kiếm thứ phản mềm tại công ty LPT để đề xuất, chính sửa quy trình kiếm

thử phản mềm nhúng,

Trang 14

CHUONG I: TONG QUAN VE KIEM THU TRONG PHAT

TRIEN PHAN MEM

1.1 Tim quan trong trung phát triển phần mềm

1.1.1 Một số định nghĩa lên quan đến kiểm thử

“Định nghĩa Kiếm thử

Kiểm thứ là quy trình thực thi hoặc đánh giá một hệ thông hcặc một thành phần

tự động hoặc bằng tay với mục đích xác nhận rằng hệ thẳng đó (hoán mãn các yêu cầu

nhất định [IEEE 83a]

Một định nghĩa khác: Kiểm thử là một quy trình chạy sản phẩm theo xu huớng, tim ra các lỗi

* Dinh nghia quy trình

- Quy trình là c hành động câu thực hiện để đạt được một mục đích nào đó

- Quy trình phân mềm (Software Process) lã tập các hành động, phương pháp, thủ tục và biển đổi mà người ta sử dụng đẻ phát triển hoặc duy trì phần mềm và các sân phẩm liên quan

"_ Dịmh nghĩa vẻ chất lượng

- Từ góc nhìn khách bàng thì chất lượng của sản phẩm nghĩa là “đùng được”

hoặc là đáp ứng yêu cầu của họ

- Đảm bão rằng sản phẩm thỏa mmãn yêu cầu và mơng muốn cửa người dùng

1.1.2 Mục tiêu của kiểm thử

*_ Mục tiêu dâu tiên: Chạy chương chỉnh với xu hướng tìm ra lỗi dễ

- Xác định xem hệ thông có đáp ứng được các đặc điểm kỹ thuật hay không

- Xác định xem hệ thống có đáp ứng được mong muốn hay không

- Tạo sự tin tưởng: Một sản phân đã được kiếm thử tốt luôn luồn tạo cho khách

hàng sự tin tưỡng vào chất lượng,

- Liên tục cãi tiền quy trình kiểm thử

1.1.3 Một số cách hiểu không dùng về kiểm thử

“ Kiểm thủ nghĩa là gỡ lỗi Kiểm thủ chỉ cỏ nghĩa vụ tìm ra lỗi cử không cỏ ý

định gờ lỗi cho chương trình Trong phương pháp kiếm thử hệp trắng, nhân viên

Hoe viên: NguyỄn Văn Trạng "Trang 12/78

Trang 15

kiểm thử lần theo cầu trúc của modul để đưa ra các rường hợp kiểm thử, nhưng,

họ không có ý định sửa lỗi cho chương trình nên thấy lỗi tại một điểm nào đẻ Neu he lam như vậy sẽ dành mất tỉnh khách quan của kiếm thứ hơn nữa dánh

sự lẬp trưng Œ can thiết của hoạt động kiểm thử Họ sẽ bị “sa đả” vào các chi

*_ Nếu lập trình viên má cần thận hơn nữa thì việc kiểm thứ la không, cân thiết

"- Kiểm thử tlủ không bao giờ kết thúc

= Kiém thử chỉ bắt đầu sau khi lập trình xong Trong mô hình lặp, kiểm thử được

thực hiện song song với lắp trình Ngay cả với mô hình chữ V dơn giãn thì cũng, không ai đại gì mà lại đợi đến khi lập trình xong mới tiến hanh kiém thir Néu dé như vậy thì phí tổ nguồn lực trong dự an là rất lớn vi thông thường kiểm thứ viên và lập trình viên là hai người khác nhau Ngoài re giá phâi Irả cho các l

cảng về sau cảng cao, ảnh hướng của lỗi phát hiện muộn sẽ nặng nẻ hơn so với phải hiện từ đầu

"_ Kiểm thủ không phải là một công việc sáng †ạo Diễu này có thế đúng Nếu

nói sảng tạo tức là tạo ra sản phan thi kiểm thứ có tạo ra sản phẩm đó là báo cảo

kiểm thữ, ngoài ra họ cũng sáng tạo ra lỗi Dù sao đi nữa thì kiểm thủ vẫn chưa

thật sự được chú trọng nhất là phát triển phần mềm ở Viết Nam

—_ Phải có dũ thời gian

—_ Ưác lượng lỗi theo điều kiện biên

~_ Kế hoạch hỏa, theo dõi kiểm soát vả thí hành

—_ Xúc định điểm eơ sở và cỗ định yên câu

— Ước lượng vả lựa chiến lược kiểm thử

—_ Kiểm thử Lự động

—_ Phải đảo tạo cho nhân viên kiểm thử khác như là một kế hoạch dự phòng

" Thựctiến

—_ Ấp lực về mặt thời gian: Ngay ban giao săn phẩm

— Không kiểm thử mã nguồn: nguồn lực có lạn

—_ Liên tụe thay đối và cập nhật yêu câu

— Không biết khi nào thì dừng lại: Cập nhật và cập nhật liên tục yêu cầu vi vậy nhân viên kiểm thử phải cập nhật lại da kiếm thử và thục hiện kiểm

thử lại

Trang 16

~ Kiém thirbang tay —_ -

— Thiéu méi trường đề kiểm thử: phải chia sẻ môi trường với phát triển

— Không đủ kinh nghiệm và không được đảo tạo

1.2 Các hoạt động của nhân viên kiểm thử

1.2.1 Mô tả công việc của kiểm thử viên tại công ty FPT

Bang 1.1 m6 ta các hoạt động mà một nhân viên kiểm thử phải thực hiện khi đứng trong một tô chức phát triển phân mềm cũng như khi tham gia vào một dự án phát triển phân mềm

Phát trin kế hoạch kiêm thừ theo yêu câu người đùng, rủi đo, tân

suât sử dụng của chức năng

“Thực hiện kiêm thử dựa vào ca kiểm thử, kịch bản kiểm thứ, lưu lại

lỗi vả tạo bảo cáo kiểm thứ

Trang 17

17 _ | Xem xét kịch bản, đuyệt công cụ kiểm thử để đảm bảo việc kiểm thử

được thuận tiện

33 | Tuân thủ quy định bảo mật thông tin của công ty

Bảng 1.1: Các công việc của nhân viên kiểm thử tại công ty FPT

Giảng viên hướng dẫn: PGS.TS Huỳnh Quyết Thắng

Trang 18

1.2.2 Luông công việc mà nhân viên kiểm thử phải thực hiện trong dự án

G

Thực hiện kiểm thử

TÔ tire kang

IØ sắn TEUTðIV26DMS:

cập nhật ca KT,-—

Tế [Bann ga ker que

kiểm thử | Tha

Hình 1.1: Luông công việc mà kiểm thử viên phải thực hiện tại công ty FPT

Giang viên hướng đẫn: PGS.TS Huỳnh Quyết Thăng

Trang 19

"Đội kiểm thủ

chuẩn bị kế

Hình 1.2: Quy trình làm việc của nhân viên kiểm thử tại công ty FPT

1.3 Các đặc trưng của kiểm thử phần mềm

Các đặc trưng của kiểm thử được biểu diễn như sau

Phương thức Kiêu kiêm thử \¿ (các pha kiểm thử trong vòng đời phát triển)

kiểm thử (kỹ thuật kiểm thử) \ |

(cach thức tiến \ \— „-† Kiểm thử mức khôi

"ảnh kiểm thử) | Vi dụ: TT] ` ích hợp các khôi của phân mêm

KT đữ liệu, m thử mức phê chuân

Trang 20

Mục tiêu: đảm bảo rằng từng khói của phân mềm không chứa bắt kỷ lỗi nào cho

dù đó là lỗi lập trình hay lỗi thiết kế

“Người thực hiện: cáo nhân viên lập trình

- Kiểm thủ mức tích hựp phan mém (Software Integration Test): Xac nhan thiết kế tổng thể, định nghĩa kỹ thuật và tích hợp Kiểm thử đẻ kiểm tra xem cách thức mả các thành phân của phân mềm làm việc với nhau, đặc biệt lá ở giao tiếp,

để đâm bảo răng, thiết kế tông thé được tuân thủ

Muc tiêu: kiểm thử khả năng tổn tại chung (cô giao tiếp) của một ập các khỏi (ofiwie uruts: CSU) hoặc thành phẩn (components: CSC) có thế cùng tổn tại, gọi lẫn nhau, tiền hành mót chu trình hoàn chỉnh, trao đổi và lưu trữ đữ liệu chính xác,

Người thực hiện: đội phât triên phần mêm

Tại những bước cuồi củng của tích hợp (toàn bộ các thánh : phần dược tich hợp Jai) thi khéng cần phải kiểm tra chức nắng theo đặc lä yêu cảu, việc kiểm tra này

sẽ được “để dành” cho kiểm thử mứcphê chuẩn (đó là mức kiểm thử ngay tiếp

Moc tiêu: nàng cao độ tin tudng va st “kết dinh” phản mẻm

Người thục hiện: Nhân viên R&D thực hiện mức kiếm thử này, hoặc một phan

súa đội dự án néu cần thiết cũng sẽ tham gia váo giai đoạn kiểm thứ nảy

1.3.2 Mục tiêu kiểm thử

Kiểm thử nhằm chứng mình rằng chất hượng của phần mẻm được đảm bảo Chất lượng của phần mắm được nhi nhận ở các yêu tó sau ('FURPK” [1SO 9126-1]) Chức năng (FuncHonal capzbility) (thích hợp, chính xác, khả năng thao tác,

thao tác, an toàn),

Tiện lei (Usability) (dé big khả năng nắm bắt, khả nang thao tac, d6 hap din),

Trang 21

Một số đặc trưng khác về chất hượng phản mẻm (như tích hợp dữ liệu cũng nht

chức năng, ) có thể sẽ là mục tiêu kiểm thử nếu no dong vai trở quan trọng, trong quá trình kiểm thủ thành phần phần mềm Khả năng tải sử dụng, không

phải là mục tiêu của kiểm thử trong suốt vòng đời phát triển phần mêm (mặc đủ

nó là một đặc trưng quan trọng của phát triển phản mém)

mã nguồn về mặt vật lý Kiểm kiểm thử này còn có tên gọi là kiếm tra

(inspection) hoặc xem xót mã nguồn (code review) Nó có thể được thực hiện bởi 1uột lấp trình viên khác bằng cách đọc mã nguồn, cũng có thế thực hiện trong một

buổi hợp (nhằm chia sẽ kinh nghiệm cũng như cách thức xem xét mã nguồn cứa

đội đự án), nó cũng có thế được thực hiện bởi công cụ hỗ trợ để đấy

nhanh tiên độ Thông thường, trong một dự án lớn, người ta thưởng kết hợp các cách vừa dược chỉ ra

Kiểm thứ theo hộp trắng (hoặc tiếp cận theo câu trúc): Kiểm thử để xáo nhận chất lượng về mặt kỹ thuật của phần mềm bằng cách phân tích sấu vào cấu trúc bên trong các thành phần ở các khứa cạnh: Đường đi, đỏ phức tạp, dữ liệu, bồng

đã liệu, tiêu chmẩn lập trình

Kiểm thử theo hộp đên (hoặc tiếp cận [heo chúc năng): Kiểm thử để chỉ ra các

ứng xử về mặt chức năng hoặc kỹ thuật của thành phân được kiểm thử là đúng

như tài liệu tham khảo Phương pháp này chủ ý dến các ứng xử của thành phân

khi nhận đầu vào và cho ra kết quả như thể nào chử không quan tâm đến cách

thức xứ lý dữ liệu bên trong thành phần

Kiểm tra dữ liệu: xác nhận sự đa dạng về kích thước và khuẩn dang của dữ liệu

dựa vào dặc tính kỹ thuật cũng như phương thức sứ dụng hệ thống

Kiểm thủ nhủ: Chay nhánh đài lớn nhất của phân mềm

Trang 22

Kiém thử nhỉ hồi quy: Lặp dì lập lại một số ca kiểm thử nảo đó để xác nhận một

sai sót hoặc một sô sai sót (đã biết trước) không xãy ra sau khi thay đối thành phần dỏ (một thánh phản sau khi sửa dỗi có thẻ sẽ sinh ra sai sót mới, hoặc làm nhiều loạn phẩn đã được kiểm thử, hoặc kich hoạt sai sót khác mà nó chỉ hoạt động khi thục hiện hành động chính sửa đó

Kiểm thử chức năng: Kiểm thử dễ chỉ ra mỗi chúc năng của môi thành phân thực hiên đúng theo yêu cầu hoặc đặc tả chức năng Nó côn được gọi là kiếm thử

danh ngbia (nomial)

Kiểm thử giới hạn: Kiểm thử để xác định ứng xử của thánh phân khi đặt vào các

giới hạn (rât cao, rồng hoặc các giá trị âm) Còn được gợi là kiểm thứ áp lực

Khi thành phần bị đây quá giới hạn tì nó được gọi là kiểm thử kháng cự hoặc

“sức mạnh”

Kiểm thử hiệu năng: Kiểm thử dễ chỉ ra rằng thành phần dỏ có dáp ứng dược các ràng buộc về hiệu năng hay không (thời gian, kích cỡ, tải trọng) Với một tải trọng nhất định (tăng dân) thì trong khoảng thời gian bao lâu hệ thông sé khéng

thể đáp ứng được (reo máy hoặc ngừng hoại động)

Kiểm thử an toàn: Kiểm thứ đẻ chí ra khá năng báo toàn đữ liệu vả tiền trình sau Khi có lệnh khối động lại hệ thống hoặc khi gặp hở ngại

Kiểm thử an ninh (Security TesÐ : Kiểm thử để chỉ ra khả năng phát hiện và ngăn chặn các cuộc xảm nhập, tân công, gian lận và sử dụng sai mục dich

Trang 23

tinh Xem Xét mã nguồn

Ðo đạc, lượng hóa

mm Kiểm tra dữ liêu v

Kiém thử hồi quy Viv Ỷ Ỷ

Kiểm thử chức năng V VIN tiếp đen Kiểm thử tới hạn Ỷ Ỷ

Kiểm thử bảo mat Viv Liv

Bảng 1.2: Các đặc trưng của kiêm thử phân mêm UT: Kiểm thử mức khôi; IT: Kiểm thứ mức tích hợp; SV: Kiểm thử mức phê chuẩn

Trang 24

CHUONG I: CAC MO HINH PHAT TRIEN PHAN MEM NHUNG

2.1 Giới thiệu các mô hình phát triển phần mềm nhúng

Chúng ta đưa ra ba mô hình phát triển phân mềm: mô hình thác nước, mô hình

lặp, mô hinh thích ửng đẻ so sánh vả phân tích

'Waterfall

RUP

Thời bian phát hành sản phẩm

Đôbbhức tạp về môi trường

Hướng tới mã nguồn Hướng tới module

Mức cổ định yêu cầu

Hình 2.1: Các mô hình phát triển phân mêm

Học viên: Nguyễn Văn Trọng ‘Trang 22/78

Trang 25

vạt Tice SE E00 anne vi lim syy ono

Serta ert

‘Se UPI dite te in pis che ong + n6 cặn ip ating ng ‘roa dg ng dã vì phế it

hr neh yh ahi Ha quen se

SU garmin hong Mất tộc Dh dc dưng

Tiến mắc Đáng me Cents ty ‘Hote ts het ty SD Borers

EF hh ih tin {vee eda phn ain ah nes tng cst bn 1 hn gh ngất s) ứng ‘hae Hint co tư làm

‘ebhonh hla sgh

+ Us mc high sn 3 BÍ kế tực hn

TP vi) đáy SỐ ide Bensimon ta gen rb đơn he eect —

1 Flog ig cu nn hur si,

«Finn bie au vic 1 bei kn cw E TCC4 Bg ng Điểm yếu Sigil aati ein ne

TQ hd da de i rin Barb ian enn lân, đồ psp a

Mô hình thác nước côn có một tên gọi khác đó là mô hình chữ V, sau đây ta tập

trung làm rõ các pha trong quy trình này

Trang 26

Các pha của mô hình chữ V

2.2 Các hoạt động và tải liệu trong quá trình kiểm thử

2.2.1 Các hoạt động trong kiểm thử

Kế hoạch kiểm thử (STP)

Bau vao: Ké hoạch phát trién phan mém (SDP)

Mô tả: kế hoạch hỏa chiến lược kiểm thử Những thành phẩn nào của phần mềm sẽ

được kiểm thủ, mục phạm vị của kiểm thử là gì Lắm thể nào để đạt được

tiêu đề ra, loại hình kiểm thử não sẽ được sử dụng (phương thức, kiểu kiểm thử), cùng,

với đỏ là mô tả về môi trường, công cụ, tài liệu, tổ chức, của kiểm thử

Tài liệu đầu ra: Kế hoạch kiểm thử Với các dự án nhỏ, STP có thẻ là một phân của kế

hoạch phát triển phan mém (SDP) Kế hoạch kiểm dược xây dựng ngay khi bắt dâu dự

an và cập nhật trong suốt quá trình hoạt động của dự an

Trang 27

'Đặc tá quả trình kiểm thir

Đầm vào 0 Input: Ké hoach kiém thứ (SIP) va dic ta i yeu cầu phản mém (SR§) hoặc tải

mỗi en kiểm thử Tài liện nảy cũng có thế được gợi là bản mô lâ kiểm thứ hoặc định

nghữa kiếm thử hoặc kịch bản kiểm thử: Ngoài ra, các công cụ hỗ trợ kiếm thử cũng

được lựa chọn bước này thấy cần thiết

Tài liệu đầu ra: Tài liêu mô tả quả trinh kiếm thử (STD) STD có thế là một tài liệu

nhưng thông thường nó lá tập hợp nhiều tải liệu và bảng biểu Có thể, đặc tá cho các công cụ hỗ trợ kiểm thữ cổng được dưa ra

Mô tả: Đây là giai doạn chuẩn bị, và thiết kẻ kiểm thử (vi đụ viết kịch băn kkiểm thứ,

viết chương trình kiểm thử, phát triển Ì cong cụ hỗ trợ kiểm thử, .)

Đầu ra: Dầu ra của buớc nảy không phải là các tài liệu Nếu cỏ thể phải đưa ra ví đụ

tà đó là công cụ kiểm thử và tải liệu hưởng đẫn sử dụng, kịch bản kiểm thử cho mỗi điễn tiến của STD

Kiểm thử và làm bảo cáo

vị kiểm thử ) nên kết quả mang muốn Teng 2 được mô tà trong STD, đầu ra của bước

phát triển phản mềm (các thành phân phản mềm: component),

m kịch bẵn kiểm thử để đảm bão rằng yêu cầu hoặc đặc tả yêu cần đã

„ lưu lại kết quả thử, phân tích sụ khác nhan giữa kết quả thục và kết quả mong muốn ,, báo cảo lại kết quả phân tích này nhằm đáp ứng xây dựng kết quả

tống thể của quá trình kiểm thủ

Đầu ra: Báo cáo kết quả kiểm thi (STR)

Bao cáo kết qua kiểm thử được tạo ra sau khi thục hiện kiếm thử (đặc biệt khi kiếm

thứ cho ra lỗi và một phân của phần mém đã được kiêm thứ phãi thay đổi)

Trang 28

Đỗ án tốt nghiệp cao học: Xiểm tuừ phẩn mềm nhúng

2.2.2 Tổng hợp về các tải liệu trong kiểm thử

Có ba loại tải liệu liên quan đền kiểm thử:

Bang 2.2: Cac tai liệu trong kiêm thử phân mềm

Ma trận này chỉ ra rằng nhiều nhất là cỏ 9 loại tải liệu được tạo ra Nhưng các

tai liêu nảy có thê được gộp với nhau đẻ đề quản lý

Ví dụ có thể sử dụng một kế hoạch kiêm thử cho tất cả các mức kiêm thử

Phom mồ tả kiểm thử mức khỏi có thê bao gôm mô tả kiêm thử, kết quả kiểm thử

Dù gì đi chăng nữa các tải liệu 3 loại tải liệu này phải được xác định rõ trong kẻ hoạc

phát triển phân mềm với các thông tin sau tên tải liệu, vị trí lưu trữ tài liệu

2.3 Các mức độ kiểm thử (theo mô hình chữ V)

Metrics: Độ phủ của kiêm thứ

Trang 29

—- Đảm bảo rằng mã nguồn được triển khải đúng theo thiết kế

— Sử đựng các khổimodule đã được kiếm thử đế đụng

chương trình, chương trình này dã dược chỉ ra bởi thiết kế

TT phải thực hiện sau UT

Kết nổi các thành phân lại nhằm phát hiện ra các lỗi liên quan đến quả trình giao tiếp giữa chúng

Phương thức: Liệp đen

Người thục hiện: nhỏn kiểm thử độc lập

Tim ra su vénh giữa hệ thông và yêu câu của lọ

Cho phép khách hàng xác định được chính xác những gi họ muến, đủ là

có hay không được chỉ ra trong tái liệu

Trang 30

Đỗ án tốt nghiệp cao học: Xiểm tuừ phẩn mềm nhúng

= Tircae sản phẩm: Yếu câu phan mem, Thiet ke chi tiết, Mã nguồn, Ca kiểm thứ,

= Tir qua trinh kiểm soát chất lượng: Xem xét, kiêm thử, đảnh giá độc lập và xét duyệt

«_ Từ quy trình: Làm yêu cu, thiết kế

= Turcac nguon khác: Yêu cau thay

hoach,

, hiệu lâm, không can than, lap ke âp trình kiêm thử -

2.4.2 Chu trình thay đổi trạng thái của lỗi

Hình 2.3 mô tả vòng đời của lỗi từ khi được phát hiện cho đến lúc được sửa chữa và dong lại

TEUiðJvốI trong thải = ACCEPTED

trang thal = ERROR

aie

trang thải = ASS|G! ‡ tên trang thal = CANCELLED

'Cê tài hiện)Št

8 qua sg) > ——x| Ge trang thai = CLOSED ng J+ Kat tite

Hình 2.3: Chu trình thay đổi trang thai của lỗi tại công ty FPT

Các thành viên của đội dự án, tủy theo vai trỏ (role) của minh cỏ thẻ tác động vào làm thay đổi trạng thái của lỗi như bảng 2.3:

Trang 31

Đỗ án tốt nghiệp cao học: Kiém tĩiứ phân mềm nhúng

Người tạo lỗi Accepted

Trang thai tiep theo

phân công sửa | Cancslled

lỗi (A ssignee) ‘Accepted

Trang 32

Dé An tit nghiép cao hoc: Kiém tir phan mém niuing

QA (nhân viên [Cancelled

quản lý quy trình) | Accepted

Trạng thái tiếp theo

Trang 33

Các trạng thái của lỗi:

—_ Emor: Nhân viên kiểm thử thực hiện kiểm tra chức năng và phát hiện ra lỗi, lưu lỗi nảy vào DMS

—_ Assigned: Quản trị dự án xem xét lỗi đó, rồi giao cho lập trinh viên thích

hợp

~ Confirmed: Lap trình viên được giao phụ trách lỗi thây chưa hiểu rõ nội

dung lỗi và cân phải trao đôi lại những thông tin đẻ

— Fixing: Lập trình viên thực hiện sửa lỗi, nhưng chưa kết thúc quá trình sửa

— Correeted: Lập trình viên đã sửa lỗi xong, nhưng chưa được nhân viên kiểm thử kiểm tra lại

- Closed: Nhân viên kiêm thử thực hiện kiếm tra lại lỗi mả Lập trình viên

đã sửa va thấy lỗi đã sửa như mong muồn

—_ Caneelled: Quản lý dự án xem xét đó không phải là lỗi nên sẽ hủy bỏ lỗi

- Accepted: Loi phat sinh nay không, thẻ hoặc chưa có kiêu kiên đẻ sửa nhưng được khách hàng chấp nhận khi bản giao sản pham

Lưu lai lối Phản tích lỗi Khắc phục lõi Kiểm tựa lại

Nếu lỗi vẫn tổn tai trong sin pham thi chuyén sang ERROR

Hình 2.4: Các pha của lỗi

Trang 34

2.4.3 Chỉ phí lỗi

Thông thường, phân lớn lỗi được phát hiện ở các pha ban đầu của dự án như

phân tich va thiết kê Số lượng lỗi bắt được cảng vẻ sau cảng giảm Tuy nhiên “giả”

phải trả cho các lỗi cảng vẻ sau cảng cao Lý do là chỉ phí về nguồn lực phải trả cho

môi lỗi cảng vẻ sau cảng cao bởi vì khi gặp lồi sẽ phải quay lại buớc phân tích đề thực

hiện sửa lôi, ngoài ra phạm v1 ảnh hưởng của lỗi cảng về sau càng rộng Hơn nữa các

lỗi nều được phát hiện muộn thông thường rất tràm trọng, néu phat hiện ở bước cuỗi

cung tức là bàn giao cho khách hảng thì sẽ ảnh hưởng lớn đên hình ảnh của sản

phẩm cũng như đội dự án Hinh sau cho thay gia phai trả cho lỗi theo các pha của dự

Hình 2.5: Chi phí lỗi theo pha

2.4.4 Phân loại lỗi

—_ 8ai logic nghiệp vụ

—_ Giao diện người dùng: bỏ trí sai, nhãn, sai thông điệp, vị trikích thước

sai

Trang 35

= Mute độ nghiêm trọng của lỗi: Mức độ trâm trọng của vấn

sự thông nhất giữa nhân viên phá triển và kiếm thử viên Việc phâu loại có tính

tương đối, mặc đủ đã đưa ra một số tham khảo đề phân loại mức độ lỗi

—_ ADD (ái liệu phí

- DDD (tai liệu thiết kế chỉ tiết)

—_ Ca kiểm thử (UT/TT/ST)

" _ Các hoạt động kiếm soát chất lượng

—_ Xem xéLinš nguồn

- Quan ly edu hinh

- Kiém soát tải hiệu

= Uutién: Mite độ cấp thiết của vấn để

Trang 36

2.5 Vai trò của người thực hiện kiểm thử

2.5.1 Vai trò của kiểm thử viên đỗi với tổ chức công ty FPT

Hình 3.6 mô tả quy trình phát hành sản phẩm ra thị trường của công †y FPT, một công,

ty hàng đầu thế giới vé may in tem thu, cho thấy hoạt động kiểm thứ như là những chot

quyết định chất lượng của sản phẩm Ngoài ra nó cũng là thao tác quyết định sẵn

phẩm có được đưa ra thị thường hay không,

Trang 37

`

Phát triển hệ thống _~ ——————=———————=———t—=

2 Xác thực & chuẩn hóa hệ thống

Nhập lậu tham knảo và Đực hônxắcthực [EM “Xác thực tại8agnaur Xdetvetar Seton

Xác thực & chuẩn hóa hệ thống

Cài đặt máy sản xuất & Đồng bộ hóa

Memphis Phan,

‘Opces

Hinh 2.6: Quy trinh phat hanh san pham tai cong ty FPT

Trang 38

Đồ án tốt nghiệp cao học: Ñiểm tuừ phần mm nhưng

"Mở dự án và tìm Quyết định mo dy an va chỉ

trưởng dự án định người đứng đầu 5 | |e |B | R8 |1

Xây dụng bản Yeu R tàn nai

Kê hoạch phát triển — | Kêhoạch dự án A [D|R |RIR R R R R

Kiểm soát & kiếm tra

Sửa lại những hành

trình

Bảo cáo kết qua a

mỗi nhà của _ ng Bảo cáo kết thục giai đoạn A|D|R I I I R|R

Chuẩn bị môi trường : “Thứ mục dự án và môi trường TA

Pos lưu trữ tái liệu

ng Mio tao trong | io cao kết quả đào tạo 1 |pa| R 1 I 1 rir

“Xác định và chỉ đạo _

| ngủa lỗi

Conduct Quality gate ,

Thue hiện kiểm duyệt

Giảng viên hướng dân: PGS.TS Huỳnh Quyết Thăng

Học viên: Nguyễn Văn Trọng Trang 36/78

Trang 39

Đồ án tốt nghiệp cao học: Ñiểm tuừ phần mm nhưng

Archive project asset _ | Archived project's WPs & records r}o] 1 1 D A |R

Conduct project Post mortem report, meeting r|& „1% R R 1 = |

postmortem minutes, -

Bang 2.4: Vai trò của kiếm thử viên vẻ mặt quản lý

Bảng 2.4 nêu lên vai trò của kiểm thử viên vẻ mặt kỹ thuật

khách hàng Khach hing, Q&A R 3ỊĐ|Đ |®S|Đ|M |5 : +

Tháp Hc Hy câu 'Yêu cẩu phân mềm R RA |Dp|A|pl|lmmlR |1 R

phan mềm

tú đụng kêhoạc KIÊN | cá hoạch kiệm tho A | D I p|R I R

"Xem lại thiết Kế, mã : : "Thiết kế kiến trúc, thiết MEE „

cùng cập)

Giảng viên hướng dẫn: PGS:TS Huỳnh Quyết Thắng

Học viên: Nguyễn Văn Trọng ‘Trang 37/78

Trang 40

Đỗ án tốt nghiện cao học: Kiếm đ#uừ ghẵn mầu nhúng

Tao tai liệu yêu cần thay đổi «pai Tải liệu yêu câu (hay đối Ken van ech a ÁN a R ek |RIR

“Tao ca kiém thứ tích: Ca kiên thứ và dữ liệu

an kiểm thì “Module phan mém,

Thức khối finclude CR document)

Mà khai gói đê kiến _ Í cà nói triển khai A R 1 R T D R

"Thục hiện kiểm thử Giồi phân mềm, báo cáo

mite tich hop kiêm thir tich hep aR 1 RD? 1 R

Khắc phục lỗi rong, quấy tình phát viện — | ModMlephinriem 3 A oD D R exe | RJR

"Bản giao phân mâm chơ | Gói Biển Klin va bien bat | a oR 1 R I pie

khách hang ban giao

Khắc phục lỗi cho Gói phần mễm, báo cáo

khách hàng kiếm thữ khách hang ^_P 5 T R k R

Bang 2.5: Vai trỏ của kiểm thử viên vẻ mặt kỹ thuật

CUä- Khách hàng; DIR - Giám dóc, GL- Trưởng trung tâm; LUM- Truởng phỏng; PM — Trưởng dự án, FTL - Phụ trách kỹ thuật, KTV: Kiểm thứ viền

TT, Trưởng nhóm kiểm thử; BA _ Phân tích nghiệp vụ; DEV T.ập hình vién, FT- Final inspector; QA MNT Quén fy chat lmeug; TRS QI Cơ sởhạ tầng Ð~ Làm, R — Xem xét; A — Phê duyệt, 1— Thông báo; <Trắng>- bó qua

Giảng viên tnỏng dẫn: PGS.TS Huỳnh Quyết Thang

Hoc viên: Nguyễn Văn Trọng Trang 38/78

Tiêu đề	Kiểm thử phần mềm nhúng
Tác giả	Nguyễn Văn Trọng
Người hướng dẫn	PGS.TS. Huỳnh Quyết Thắng
Trường học	Trường Đại Học Bách Khoa Hà Nội
Chuyên ngành	Công Nghệ Thông Tin
Thể loại	Luận văn thạc sĩ
Năm xuất bản	2009
Thành phố	Hà Nội

Định dạng
Số trang	80
Dung lượng	2,85 MB