Kiểm thử phần mềm nhúng

Trong phạm vi của đề tài, dựa vào thực tế phát triển hệ thống máy in tem thư tại công ty 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.. Trang 14 CHƯ

NGUYỄN VĂN TRỌNG

LUẬN VĂN THẠC SĨ KHOA HỌC

LỜI CAM ĐOAN

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 Bách Khoa Hà Nội cam kết LVTN là công trình nghiên cứu của bản thân tôi dưới sự – hướng dẫn của PGs.TS 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ác kết quả nêu trong LVTN là trung thực, không sao chép toàn văn của bất kỳ công trình nào khác

Hà Nội, ngày 24 tháng 04 năm 2009 Tác giả LVTN

Nguyễn Văn Trọng

TÓM TẮT LUẬN VĂN

Luận văn tốt nghiệp đã nghiên cứu khá đầy đủ cơ sở lý thuyết về kiểm thử, vai trò 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 ty 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 OSIRIS cho máy in tem thư tạ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 OSIRIS Kiểm xoát vòng đời của lỗi là một vấn đề đặc biệt quan trọng đối vơi dự án 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 đổi trạng thái của lỗi Tác giả dựa vào mô hình phát triển phần mềm tại công

ty FPT để đưa 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 bầy rất rõ ràng

MỤC LỤC

LỜI CAM ĐOAN 1

TÓM TẮT LUẬN VĂN 2

DANH MỤC CÁC THUẬT NGỮ VÀ TỪ VIẾT TẮT 5

DANH MỤC CÁC BẢNG 6

LỜI CẢM ƠN 8

MỞ ĐẦU 9

1 Tính cấp thiết của đề tài 9

2 Mục đích nghiên cứu 9

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

4 Phạm vi nghiên cứu 10

5 Cấu trúc luận văn 10

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

CHƯƠNG I: TỔNG QUAN VỀ KIỂM THỬ TRONG PHÁT TRIỂN PHẦN MỀM 12 1.1 Tầm quan trọng trong phát triển phần mềm 12

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

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

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

1.1.4 Lý luận và thực tiễn 13

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

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

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 16

1.2.3 Quy trình làm việc của nhân viên kiểm thử phần mềm 17

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

1.3.1 Phạm vi kiểm thử 18

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

1.3.3 Các phương thức kiểm thử 19

1.3.4 Các kiểu kiểm thử 19

1.3.5 Tổng kết 21

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

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

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

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

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

2.3.1 Kiểm thử mức khối 26

2.3.2 Kiểm thử mức tích hợp 26

2.3.3 Kiểm thử mức hệ thống 27

2.3.4 Kiểm thử tiếp nhận 27

2.4 Lỗi và các công cụ quản lý lỗi tại công ty FPT 27

2.4.1 Lỗi 27

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

2.4.3 Chi phí lỗi 32

2.4.4 Phân loại lỗi 32

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

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

2.5.2 Vai trò của kiểm thử viên trong chu trình phát triển phần mềm 39

2.5.3 Vai trò của kiểm thử viên trong chất lượng phần mềm 40

Chương III: Áp dụng các phương pháp kiểm thử trong phát triển phần mềm nhúng 42

3.1 Kiểm thử các máy in tem thư 42

3.1.1 Đầu vào Đầu ra– 42

3.1.2 Môi trường quản ly tài liệu trong quá trình phát triển phần mềm 42

3.1.3 Cấu trúc hệ thống ca kiểm thử của máy KEOPS 43

3.1.4 Các hoạt động trong quá trình kiểm thử 49

3.1.5 Các công cụ hỗ trợ kiểm thử 50

3.1.6 Duyệt khối trước khi kiểm thử tích hợp 52

3.1.7 Báo cáo kết quả kiểm thử 54

3.2 Kiểm thử hệ thống dịch vụ trực tuyến OSIRIS 57

3.2.1 Các pha của dự án kiểm thử OSIRIS 57

3.2.2 Phân loại lỗi trong OSIRIS 59

3.2.3 Vòng đời của lỗi trên Dimension 62

3.2.4 Thực hiện kiểm thử mức tích hợp 63

3.2.5 Báo cáo kết quả kiểm thử 65

KẾT LUẬN 76

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

2 Các đóng góp khoa học: 76

3 Hướng phát triển của luận văn 77

TÀI LIỆU THAM KHẢO 78

DANH MỤC CÁC THUẬT NGỮ VÀ TỪ VIẾT TẮT

1 ANSI AInstitutemerican National Standards Viện tiêu chuẩn quốc gia Mỹ

2 CMM Capability Maturity Model

3 IEEE IEngineers nstitute of lectrical lectronics E E Viện k thuỹ ật điện & điệ ửn t

Standardization Tổ chức Tiêu chuẩn hóa quốc tế

5 Kiểm thử mức tích hợp phần cứng/phần

mềm

Hard ware/software integration test Kiểm thử mức tích hợp phần cứng/phần mềm

7 Kiểm thử theo hộp đen Black box test Kiểm thử theo hộp đên

8 Kiểm thử theo hộp

Là kết quả của một phép đo lường

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

12 ST Software Integration T est Kiểm thử mức tích hợp phần mềm

13 SV Software alidation V Kiểm thử mức phê chuẩn phần mềm

DANH MỤC CÁC BẢNG

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 15

Bảng 1.2: Các đặc trưng của kiểm thử phần mềm 21

Bảng 2.1: So sánh các mô hình phát triển phần mềm 23

Bảng 2.2: Các tài liệu trong kiểm thử phần mềm 26

Bảng 2.3: Quyền thay dổi trang thái của lỗi 30

Bảng 2.4: Vai trò của kiểm thử viên về mặt quản lý 37

Bảng 2.5: Vai trò của kiểm thử viên về mặt kỹ thuật 38

Bảng 2.6: Vai trò của kiểm thử viên tại công ty FPT 40

Bảng 3.1: Các module kiểm thử của dòng máy KEOPS và các dòng máy khác 49

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

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

Bảng 3.4: Các pha trong quá trình kiểm thử hệ thống OSIRIS 59

Bảng 3.5: Phân loại lỗi 59

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

Bảng 3.7: Các module trong quá trình kiểm thử tích hợp hệ thống OSIRIS 65

Bảng 3.8: Báo cáo kết quả kiểm thử cho module CM 73

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

Bảng 3.10: Báo cáo tổng hợp về tỷ lệ các ca thành công hoặc thất bại 74

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 75

Bảng 3.12: 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 Pháp 75

Bảng 3.13: 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 Đức 75

Bả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 bại cho nước Ireland 75

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

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 16

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 17

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

Hình 2.1: Các mô hình phát triển phần mềm 22

Hình 2.2: Các pha của mô hình chữ V 24

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

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

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

Hình 2.6: Quy trình phát hành sản phẩm tại công ty FPT 35

Hình 2.7: Sự tham gia của kiểm thử viên về mặt kỹ nghệ 39

Hình 2.8: Nguyên lý vòng đời quản lý chất lượng 40

Hình 2.9: Vòng đời chất lượng tại công ty FPT 41

Hình 3.1: Sơ đồ hoạt động kiểm thử trên máy in tem thư tại công ty FPT 42

Hình 3.2: Môi trường quản lý tài liệu tại công ty FPT 42

Hình 3.3: Cấu trúc của máy in tem thư 43

Hình 3.4: Các module cần kiểm thử cho máy in tem thư 44

Hình 3.5: Cây phân cấp của các ca kiểm thử máy in tem thư 44

Hình 3.6: Cây phân cấp của các ca kiểm thử Base và Meter 45

Hình 3.7: Cây phân cấp của các ca kiểm thử Base và Meter 46

Hình 3.8: Các hoạt động của nhân viên kiểm thử máy in tem thư 50

Hình 3.9: Chu trình lỗi trên Dimension 62

LỜI CẢM ƠN

Trước hết, em xin được chân thành gửi lời cảm ơn sâu sắc tới các thầy cô giáo trong trường Đại học Bách Khoa Hà Nội nói chung và các thầy 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 dạy, truyề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 tập và nghiên cứu tại trường Đại học Bách Khoa Hà Nội

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

lòng giúp đỡ, hướng dẫn và chỉ dạy tận tình trong quá trình em làm luận văn tốt nghiệp

Cuối cùng, em xin được gửi lời cảm ơn chân thành tới gia đình, bạn bè đã quan tâm, động viên, đóng góp ý kiến và giúp đỡ trong quá trình học tập, nghiên cứu và hoàn thành đồ án tốt nghiệp

Hà Nội, ngày 24 tháng 04 năm 2007

Nguyễn Văn Trọng

Lớp Cao học Công nghệ Thông tin 2006-2008

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

MỞ ĐẦU

1 Tính cấp thiết của đề tài

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 mềm vì phần mềm chất lượ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 mềm, khâu kiểm thử đóng 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 phần mềm nghiêm túc yêu cầu một cách đánh giá chất lượ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 tượng và các phương pháp phát triển chất lượng phần mềm trước đây, nhiều nghiên cứu quan trọng đã nỗ lực định nghĩa các độ

đo chất lượng và xây dựng các mô hình chất lượng dựa trên các độ đo này Các độ đo này nghiên cứu mã nguồn hướng đối tượng hoặc các chi tiết thiết kế, bao gồm thao tác phân tích cấu trúc các chi tiết phụ thuộc của các lớp và các thành phần bên trong (chẳng hạn, các lớp bên trong, các dữ liệu thành viên, các phương thức) Giả thuyết là các độ đo này được dùng như các độ đo đối tượng để dự đoán nhiều thuộc tính chất lượng ngoài có liên quan đến mã nguồn hoặc các chi tiết thiết kế (chẳng hạn tính bảo trì, độ tin cậy) Sau đó các mô hình dự đoán như vậy được dùng để hỗ trợ việc tạo quyết đị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 thật 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 chi phí hiệu quả trong ứng dụng cụ 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ất đa dạng và thiếu ổn định trong kết quả

2 Mục đích nghiên cứu

◊ Tìm 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 và quy trình kiểm thử phần mề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

◊ Thử nghiệm mô hình kiểm thử phần mềm nhúng

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ư

◊ Xây dựng quy trình kiểm thử phần mềm cho các máy in tem thư

◊ Xây dựng quy trình kiểm thử phần mềm OSIRIS cho các máy in tem thư

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 I: Tổng quan về kiể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

2 Chương II: Các mô hình phát triển phần mềm nhúng và quy trình kiểm thử

Trong chương này trình bày các Phân tích, đánh giá các mô hình kiểm thử phần mềm Chỉ ra chu trình thay đổi và kiểm soát lỗi trong dự án phát triển phần mềm Các công việc mà một kiểm thử viên phải thực hiện cũng được chỉ ra Tầm quan trọng,các đặc trưng của kiểm thử phần mềm cũng được đề cập trong chương này

3 Chương III: Á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 dung về việc áp dụng mô hình kiểm thử vào kiểm thử phần mềm nhúng trên các máy in tem thư và dịch vụ trực tuyến OSIRIS của công ty FPT

Cuối cùng là các đánh giá kết luận chung 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 hành kiểm thử cho các sản phẩm tạo ra trong quá trình phát triển Mỗi giai đoạn phát triển sẽ có một cấp độ 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 để đi sâu phân tích các cấp độ, các tài liệu, các thao tác liên quan đến kiểm thử phần mềm Nghiên cứu này dựa trên thực tế tiến hành dự án kiểm thử phần mềm tại công ty FPT để đề xuất, chỉnh sửa quy trình kiểm thử phần mềm nhúng

CHƯƠNG I: TỔNG QUAN VỀ KIỂM THỬ TRONG PHÁT

TRIỂN PHẦN MỀM

1.1 Tầm quan trọng trong phát triển phần mềm

1.1.1 Một số định nghĩa liê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 hoặ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 đó thoả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 hướng tìm ra các lỗi

 Định nghĩa quy trình

- Quy trình là tập các hành động cần 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

 Định nghĩa về chất lượng

- Từ góc nhìn khách hàng thì chất lượng của sản phẩm nghĩa là “dù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 mãn yêu cầu và mong muốn của người dùng

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

 Mục tiêu đầu tiên: Chạy chương chình với xu hướng tìm ra lỗi để

- 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

 Mục tiêu thứ cấp

- 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ác hiểu không đúng về kiểm thửh

 Kiểm thử nghĩa là gỡ lỗi Kiểm thử chỉ có nghĩa vụ tìm ra lỗi chứ 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

kiểm thử lần theo cấu trúc của modul để đưa ra các trườ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 đó Nếu họ làm như vậy sẽ đánh mất tính khách quan của kiểm thử hơn nữa đánh mất sự tập trung cần thiết của hoạt động kiểm thử Họ sẽ bị “sa đà” vào các chi tiết của chương trình

 Kiểm thử không phải là công việc của người lập trình Trong thực tế tại công ty FPT, lập trình viên bắt buộc phải thực hiện test cho chương trình mà họ viết ra ở mức thấp nhất, đó là kiểm thử mức khối Họ là người hiểu rõ nhất chương trình

mà mình viết ra đến “từng dòng lệnh”

 Nếu lập trình viên mà cẩn thận hơn nữa thì việc kiểm thử là không cần thiết

 Kiểm thử thì 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 đơn giản thì cũng không ai dại gì mà lại đợi đến khi lập trình xong mới tiến hành kiểm thử Nếu để như vậy thì phí tổ nguồn lực trong dự án là rất lớn vì 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 ra giá phải trả cho các lỗi 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át hiện từ đầu

 Kiểm thử không phải là một công việc sáng tạo Điều này có thể đúng… Nếu nói sáng tạo tức là tạo ra sản phẩn thì 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

1.1.4 Lý luận và thực tiễn

 Lý luận

− Phải có đủ 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 cơ sở và cố định yêu cầu

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

− Kiểm thử tự độ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ực tiễn

− Áp lực về mặt thời gian: Ngày bàn giao sản phẩm

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

− Liên tục 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 vì vậy nhân viên kiểm thử phải cập nhật lại ca kiểm thử và thực hiện kiểm thử lại

− Kiểm thử bằng 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

Bảng 1.1 mô tả 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

1 Nghiên cứu yêu cầu khách hàng, điều kiện chấp nhận, đặc tả yêu cầu phần mềm, thiết kế

2 Phát triển kế hoạch kiểm thử theo yêu cầu người dùng, rủi do, tần suất sử dụng của chức năng

3 Xác định phương pháp kiểm thử, điều kiện thoát, đo đạc kết quả test, nguồn lực và điều kiện của hiệu năng test

4 Tạo ca kiểm thử ( điều kiện kiểm thử, kịch bản kiểm thử, kết quả

test)

5 Xem xét kế hoạch kiểm thử và ca kiểm thử

6 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ử

7 Phân tích các yêu cầu thay đổi và cập nhật tài liệu kiểm thử

8 Tạo ca kiểm thử mức khối

9 Thực hiện kiểm thử mức khối và đánh giá kết quả

10 Tạo bản liệt kê các mục cần kiểm tra lần cuối

11 Xem xét bản liệt kê các mục cần kiểm tra lần cuối

13 Quản lý đội dự án có hạng B, C, D

14 Quản lý đội dự án có hạng A

15 Giới thiệu quy trình kiểm thử của F

16 Nghiên cứu công cụ kiểm thử, tạo kịch bản kiểm thử tự động

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

17 Xem xét kịch bản, duyệt công cụ kiểm thử để đảm bảo việc kiểm thử được thuận tiện

18 Nghiên cứu các kỹ thuật kiểm thử và công cụ mới được áp dụng trong F

19 Tính toán và phân tích ma trận kiểm thử

20 Khởi tạo luồng công việc, quy trình, hướng dẫn

21 Xem xét các đề xuất cải tiến liên quan đến việc kiểm thử phần mềm

22 Điều hành quy trình cải tiến và hiệu quả chi phí được đưa về các nhóm

23 Phát triển tài liệu quản lý chất lượng

24 Quản lý các hoạt động cải tiến kỹ năng của nhân viên kiểm thử và chất lượng kiểm thử

25 Xác định quy trình kiểm thử, mẫu kiểm thử

26 Quản lý công cụ kiểm thử

27 Đào tạo nhân viên kiểm thử mới

28 Xác định chương trình đào tạo chuẩn cho nhân viên kiểm thử

29 Quản lý nguồn nhân lực kiểm thử ở các nhóm

30 Quản lý nguồn nhân lực kiểm thử ở FPT

31 Quản lý việc đào tạo nhân viên kiểm thử ở các nhóm

32 Quản lý việc đào tạo nhân viên kiểm thử ở công ty FPT

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

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

Tạo kế hoạch kiểm

Tạo ca kiểm thử

Có đạt kiểm tra không

Có đạt kiểm tra không

Thiết lập môi trường Kiểm thử

Bản liệt kê kết quả kiểm tra

Bản liệt kê kết quả kiểm tra

Bản liệt kê kết quả kiểm tra

Bản liệt kê kết quả kiểm tra

Kiểm thử viên

QTDA, Trưởng nhóm KT

Trưởng DA Trưởng ,

KT, QA, đội dự án

Kiểm thử viên

khách hàng

Người xem xét cuối

Thực hiện xem xét cuối cùng Bản ghi XX

Lỗi

Kiểm thử viên

Kiểm thử viên

Kiểm thử viên

Kiểm thử viên

1.2.3 Quy trình làm việc của nhân viên kiểm thử phần mềm

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

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

Ví dụ:

KT dữ liệu,

KT phủ, Phi hồi quy, Chức năng, Giới hạn,

…

Phạm vi kiểm thử (các pha kiểm thử trong vòng đời phát triển) Kiểm thử mức khối

Tích hợp các khối của phần mềm Kiểm thử mức phê chuẩn

Mục tiêu kiểm thử (mục tiêu của kiểm thử) Quan tâm đến các đặc trưng về chất lượng của phần mềm

Phân tích dữ ệ li u

Phân tích,

sửa và đánh giá nguồn

gốc của lỗi

Thực hiện kiểm thử

Kiểm tra

hiệu năng Báo cáo lỗi

Tạo thiết kế Kiểm thử

Xem xét

và phê duy t ệ

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ác nhân viên lập trình

- Kiểm thử mức tích hợp phần mềm (Software Integration Test): Xác nhận

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ủ

Mục tiêu: kiểm thử khả năng tồn tại chung (có giao tiếp) của một tập các khối

(software units: 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ữ dữ 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 được tích hợp lại) thì không cần phải kiểm tra chức năng theo đặc tả 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 sau đó)

- Kiểm thử mức tích hợp phần cứng/phần mềm: Đây là kiểm thử đặc thủ của

Mục tiêu: nâng cao độ tin tưởng và sự “kết dính” 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 phần

củ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

Tin cậy (Reliability (độ tin cậy, khả năng chịu lỗi, khả năng khôi phục (dữ

liệu)),

Hiệu quả (Efficiency), còn được gọi là hiệu năng (ứng xử về mặt thời gian, tận

dụng tài nguyên),

Bảo dưỡng (Maintainability) nâng cao khả năng hỗ trợ (khả năng phân tích, khả

năng thay đổi, sự ổn định, khả năng kiểm thử),

Khả chuyển (Portability (khả năng tháo lắp, khả năng cài đặt, khả năng tồn tại )chung, khả năng thay thế)

Một số đặc trưng khác về chất lượng phần mềm (như tích hợp dữ liệu cũng như chức năng, ….) có thể sẽ là mục tiêu kiểm thử nếu nó đóng 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 dù

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

1.3.3 Các phương thức kiểm thử

Kiểm thử tĩnh: Kiểm thử để chỉ ra các thành phần phần mềm được được thực thi

đầy đủ, tiêu chuẩn lập trình được tuân thủ Nó là một phần của quá trình xem xét

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 em xét mã nguồn (code review) Nó có thể được thực hiện bởi xmộ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 toàn bộ đội dự á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 đượ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ác 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, luồng

dữ liệu, tiêu chuẩn lập trình…

Kiểm thử theo hộp đên (hoặc tiếp cận theo 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ú ý đế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

1.3.4 Các kiểu kiểm thử

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

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

Kiểm thử phủ: Chạy nhánh dài lớn nhất của phần mềm

Kiểm thử phi hồi quy: Lặp đi 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 đó (một thành phần sau khi sửa đổ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 kích 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ử để chỉ ra mỗi chức năng của một 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 nghĩa (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) òn được gọi là kiểm thử áp lực CKhi thành phần bị đẩy quá giới hạn thì 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ử để chỉ ra rằng thành phần đó có đáp ứng đượ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 (treo máy hoặc ngừng hoạt động)

Kiểm thử an toàn: Kiểm thử để chỉ ra khả năng bảo toàn dữ 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 trở ngại

Kiểm thử an ninh (Security Test) : 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 đích

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

CHUƠNG II: CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM NHÚNG

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ô hình thích ứng để so sánh và phân tích.,

Bảng 2.1: So sánh các mô hình phát triển phần mềm

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

Nhấn mạnh tới phương thức giao dịch thực, người với người trong phát triển phần mềm Nó cung cấp một cách tiếp cận chặt chẽgiao việc và phân chia trách nhiệm trong để

một nhóm phát triển phần mềm Mục tiêu của RUP là đảm bảo tạo sản phẩm chất lượng

Các pha của quá trình phát triển phần mềm nối tiếp nhau theo kiểm chữ V

• Đáp ứng được yêu cầu của khách hàng bởi vì liên tục và nhanh chóng bàn giao sản phẩm

• Thay đổi yêu cầu cũng vẫn được hoan nghênh

• Tạo ra sản phẩm chất lượng cao với thời gian ngắn

• Không có công cụ nào tỏ rõ ưu điểm để khuyến cáo

• Có sẵn nhều công cụ hỗ trợ cho 1 pha

• Lệ thuộc nhiều vào nhân viên lập trình

• Phải thay đổi để làm việc đúng đắn

• Là một công cụ mới và khó chứng mình bằng con số

• Thực hiện kiểm thử càng sớm càng tốt

• Mô hình làm việc

• Liên tục bàn giao

• Có quy tắc đánh giá tiến độ

• Đóng issue, và trao đổi hàng ngày

• Liên tục chú ý đến Continuous attention to

• Không có công cụ nào để khuyến nghị

• Không thể bắt đầu với một cái bảng trắng

• Mở rộng sử dụng công cụ nếu có thể

• Thường phải thay để phù hợp với tổ chức

• Khung quy trình phát triển phần mềm

• Không phải là một quy trình phần mềm thuần túy

• Hướng đến ca sử dụng một cách tự nhiên

• Đòi hỏi yêu cầu phần mềm phải được trừu tượng hóa

• Tiếp cận lặp và tăng trưởng

• Đội dự án liên tục tích lũy kinh nghiệm

• Là quy trình hướng kiến trúc

• Kiểm soát thông minh

• Cơ hội tái sử dụng

• Có vẻ như là quy trình quản lý

• Hướng ca sử dụng

• Đi theo góc nhìn người sử dụng

• Mức độ “lần tìm” cao

• Kế hoạch hóa theo phép lặp

• Lỗi được phất hiện từ rất sớm

• Dễ quản lý thay đổi

• Dễ tái sử dụng

• Chất lượng tổng thể được nâng cao

• Được sử dụng rộng rãi và phổ biến

• Dễ tạo thành thói quen tốt

• Định hình trước khi thiết kế

• Thiết kế trước khi kiểm thử

• Hướng theo các tài liệu URD, SRD, ….

• Làm việc tốt với các sản phẩm hoàn chỉnh mặc dù team non kém

• Không có lặp một cách tự nhiên để thăm dò nhân viên lập trình

• Không thực tế

• Mong muốn có yêu cầu phải chính xác từ đầu

• Phần mềm được bàn giao rất muộn

• Khi phải thay đổi, giá phải trả sẽ cao

• Chi phí quản trị quá lớn

Hình 2.2: 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)

Đầu vào: Kế hoạch phát triển phần 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 đích, phạm vi của kiểm thử là Làm thế nào để đạt được mục gì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 phần mềm (SDP) Kế hoạch kiểm được xây dựng ngay khi bắt đầu dự

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

Thực hiện kiểm tra

hệ thống

Thực hiện kiểm thử chấp thuận

Yêu cầu của người

dùng

Chuẩn bị kiểm thử tích hơp

Chuẩn bị kiểm thử

hệ thống

Chuẩn bị kiểm thử chấp thuận

Thao tác hệ thống Mong muốn, chính

sách, hợp pháp

Đặc tả quá trình kiểm thử

Đầu vào Input: Kế hoạch kiểm thử (STP) và đặc tả yêu cầu phần mềm (SRS) hoặc tài

liệu thiết kế phần mềm (SDD) hoặc tài liệu thiết kế chi tiết (DDD)

Mô tả Description: Xác định kịch bản và kết quả mà phần mềm có thể sẽ trả về trongmỗi ca kiểm thử Tài liệu này cũng có thể được gọi là bản mô tả 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 nếu thấy cần thiết

Tài liệu đầu ra: Tài liêu mô tả quá trình 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 đưa ra

Thiết lập kiểm thử

Đầu vào: Kế hoạc kiểm thử (STP), Tài liệu mô tả kiểm thử (STD), có thể là cả công

cụ kiểm thử

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

viết chương trình kiểm thử, phát triển hoặc cài đặt công cụ hỗ trợ kiểm thử, …)

Đầu ra: Đầ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í dụ

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

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

Đầu vào: Kế hoạc kiểm thử (STP), Tài liệu mô tả kiểm thử (STD), đâu ra của bước

thiết lập kiểm thử, đặc tả phần mềm (SRS, hoặc SDD, hoặc DDD tùy thuộc vào phạm

vi kiểm thử ) nếu kết quả mong muốn không đượ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ô tả: Thực hiện kịch bản kiểm thử để đảm bảo rằng yêu cầu hoặc đặc tả yêu cần đã

được giải quyết, lưu lại kết quả kiểm thử, phân tích sự khác nhau 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 thử (STR)

Báo cáo kết quả 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)

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ử:

Mức kiểm thử

Bảng 2 : Các tài liệu trong kiểm thử phần mềm2

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 tài liệu này có thể được gộp với nhau để dễ 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)

 Người thực hiện: Nhóm phát triển

 Metrics: Độ phủ của kiểm thử:

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

− Sử dụng các khối/module đã được kiểm thử để dựng chương trình, chương trình này đã được chỉ ra bởi thiết kế

 IT 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

 Tìm ra sự vênh giữa hệ thống và yêu cầu của họ

 Cho phép khách hàng xác định được chính xác những gì họ muốn, dù là

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

 Những vấn đề mới có thể phát sinh

 Khách hàng có thể quyết định thay đổi vấn đề và có cần giải pháp hay không

 Phương thức Hộp đen:

 Người thực hiện Khách hàng hoặc nhóm kiểm thử độc lập:

2.4 Lỗi và các công cụ quản lý lỗi tại công ty FPT

2.4.1 Lỗi

Định nghĩa: L i là sai sót đư c phát hi n trong quá trình kiểm thử, xem xét ỗ ợ ệ

Lỗ ếi đ n từ đâu?

 T ừ các sản phẩ : Yêu cầu phần mề , Thiết kế hi tiế , Mã nguôn, Ca kiểm thử, m m c t

 T ừ quá trình 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 cầu, thiết kế, lập trình, kiểm thử,

 T ừ các nguồn khác: Yêu cầu thay đ i, hiểu lầm, không cẩn th n, lổ ậ ập kế

hoạch,…

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à đóng lại

Bắt đầu

Kết thúc

Đã được khắc phục?

Hủy lỗi trạng thái = CANCELLED

Đóng lỗi trạng thái = CLOSED

Xác nhận lỗi Với người liên quan trạng thái = CONFIRMED

Không

Có

Không Có

Có Không

Có

Là lỗi nhưng tam thời chưa sửa

Hình 2.3: Chu trình thay đổi trạng thái 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 mình có thể tác động vào làm thay đổi trạng thái của lỗi như bảng 2.3:

Người tạo lỗi

Trạng thái tiếp theo

Current Status

Current Status

Người sở hữu lỗi

Trạng thái tiếp theo

Current Status

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

− Error: 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 trình viên thích

hợp

− Confirmed: Lập 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

− Corrected: 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 và thấy lỗi đã sửa như mong muốn

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

− Accepted: Lỗi phát sinh này 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 phẩm

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

Cái gì: log lỗ i vào DMS v i ớ

- Ch ấp na ận có lỗi (nế h u đư c ợ khách hàng cho phép)

Ai: Trưở ng d án ự

Tr ạng thái: ASSIGNED / ACCEPTED

Cái gì: Kiểm thử ại các chức năng l

có chứ ỗ ể đả a l i đ m b o r ng l i đã ả ằ ỗ đượ c kh c ph c hoàn toàn ắ ụ Ai: Kiể m th viên ử

Tr ạng thái: TESTED

Cái gì: Thực hiện kiểm thử

mứ c kh i đ m b o r ng l i ố ể đả ả ằ ỗ

đã đượ c kh c ph c ắ ụ Ai: L ập trình viên

Tr ạng th ái: CORRECTED

Bước 4

Nếu lỗi vẫn tồn tại trong sản phẩm thì chuyển sang ERROR

2.4.3 Chi 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 tích và 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à chi phí vả ỗ ề ề ngu n lực phải trả cho ồ

mỗi lỗi càng về sau càng cao ởi vì khi gặp lỗi sẽ phải quay lạ b i bư c phân tích đ thực ớ ểhiện sửa l , ngoài ra phỗi ạm vi ả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 phát hiện ở bước cuối ờcung tức là bàn giao cho khách hàng thì sẽ ả nh hư ng rất lớở n đến hình ảnh của sản phẩm cũng như đ i dộ ự án Hình sau cho thấy giá phải trả cho lỗi theo các pha c a dủ ự

Chi phí sửa lỗi theo pha

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

− Sai logic nghiệp vụ

− Giao diện người dùng: bố trí sai nhãn, sai thông điệp, vị trí/kích thước ,

Ví dụ: bố trí sai so với màn hình thiết kế, sai màu sắc…

− Hiệu năng

− Thiết kế có vấn đề

− Lập trình không chuẩn

 Mức độ nghiêm trọng của lỗi: Mức độ trầm trọng của vấn đề, đôi khi không có

sự thống nhất giữa nhân viên phát triển và kiểm thử viên Việc phân loại có tính tương đối, mặc dù đã đưa ra một số tham khảo để phân loại mức độ lỗi

− ADD (tài liệu phân tích chi tiết)

− DDD (tài liệu thiết kế chi tiết)

− Kiểm soát tài liệu

 Ưu tiên: Mức độ cấp thiết của vấn đề

− Ngay lập tức

− C ao

− Bình thường

− Thấp

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 2.6 mô tả quy trình phát hành sản phẩm ra thị trường của công ty FPT, một công

ty hàng đầu thế giới về máy in tem thư, cho thấy hoạt động kiểm thử như là những chốt chặn 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

Đầu vào dữ liệu tham khảo

Nhập dữ liệu tham khảo

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

Phê chuẩn thiết bị

Smarteam entry

( Device Software and

Release Notes distribution )

Server R& D release notes

Kiểm thử tích hợp với OSIRIS

Xác thực và phê chuẩn hệ thống

Phát triển hệ thống

t

Quản lý phần mềm của thiết bị

Biên bản phát hành thiết bị - Quản lý phần mềm của thiết bịVới thay đổi phần mềm:

Quản lý đội phát triển OSIRIS ( Phát triển servers ) Serve của trung trâm R& D

Đạt chuẩn

Đưa lên môi trường

“giả” thật

Kiểm thử thiết bị hệ thống tại ,

công ty bán hàng ,

Cập nhật vào hệ thống sản xuất thiết bị

Đưa lên môi thật?

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

MSI Memphis Production OpCos

Thay đổi trên

thiết bị

Phát triển thiết bị

Dữ liệu tham khảo về phê chuẩn

Dữ liệu tham khảo Chị trách nhiệm

Xác thực tại Shelton

Bao gồm dữ liệu tham khảo về phê chuẩn

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

Nếu là dạng có thể tải xuống thì phải đóng gói theo định dạng NDF

Bao gồm dữ liệu tham khảo về phê chuẩn và cách lấy

(Servers tham khảo hoặc phát triển )

- Với thay đổi phần cứng : Quản lý phần cứng của thiết bị

Hình 2.6: Quy trình phát hành sản phẩm tại công ty FPT

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

Bảng 2.4 nêu lên vai trò của kiểm thử viên về mặt quản lý

M d ở ự án và tìm

trưở ng d ự án Quyế ịđị nh ngư i đ ng đ u t đ nh mở ựờ ứ d án và ch ầ ỉ I A A D R Xậy dựng bản Yêu

c ầu công việ c Bản yêu cầu công việc nội bộ A A R D R R R R

K ế hoạch phát triể n K ế hoạch dự án A D R R R R R

m ỗi pha của dự án Báo cáo kết thuc giai đo n ạ A D R I I I Chuẩn bị môi trường

và lựa chọn tài liệu cơ

s ở

Thư mục dự án và môi trư ng ờ lưu trữ tài li u ệ A I I I D Chỉ đạ o đào t o trong ạ

d ự án Báo cáo kết quả đào t o ạ I D/A R I I I Xác đị nh và ch o ỉ đạ

thực hiện việc ngăn

ngừa lỗi

K ế hoạc ngăn ngừ ỗ a l i A D/R D D D Đưa ra và kiểm tra

các vấ n đ ề Issues/risk/problems/CC lists I I A D R I I Conduct Quality gate

controlling Quality gate checklist A R R I I I

Th ực hiệ kiểm duyệt n

hoặc kiểm thử ứ m c

khối Unit Test Inspection Checklist A R I D

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

Conduct Inspection

controlling for Final

Inspection Final Inspection checklist R R I R I D Conduct CM

activities

Controlled CIs & baseline

Define and handle

change requirements CR & updated associated WPs A I R D R A I I I Nhận bàn giao Biên bản bàn giao I A D Lấy ý kiến khách

hàng Bản ý kiến khách hàng khi kết thúc dự án I I R R I I I I Archive project asset Archived project's WPs & records I D I I I D Conduct project

postmortem Post mortem report, meeting minutes I A R D R R R R Đóng dự án B ản ghi nhận nội bộ A A R D I I I

Bảng 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

Nghiên cứu yêu cầu

khách hàng Bản đánh giá vềkhách hàng, Q&A yêu c u ầ R D D D R D D D I Phát đặ ả c t yêu c u ầ

Thi ết kế kiến trúc, thiết

k ế chi tiết, gói phần mèm A D D I I I

T ạo thiết kế chi tiế t Tài li ệu thiế ế t k chi ti ết A D D R I I Lập trình cho các Module phần mềm A R D I I I

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

module

Tạo tài liệu yêu cầu

thay đổi Tài liệu yêu cầu thay đổi A R D R R R

Triển khai gói để kiển

khách hàng Gói phần mềm, báo cáo kiểm thử khách hàng A D D I R I

Bảng 2.5: Vai trò của kiểm thử viên về mặt kỹ thuậtCUS - Khách hàng; DIR – Giám đốc; GL- Trưởng trung tâm; LM- Trưởng phóng; PM – Trưởng dự án; PTL Phụ trách kỹ thuật; KTV: Kiể – TL- Trưởng nhóm kiểm thử; BA – Phân tích nghiệp vụ ; DEV- Lập trình viên; FI- Final inspector; QA MNT Quản lý chất lượng; IFS – QL -

D - Làm; – Xem xét; – R A Phê duyệt; I Thông báo; <Trắng> – - bỏ qua