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

Kiểm thử phần mềm nhúng Kiểm thử phần mềm nhúng Kiểm thử phần mềm nhúng luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

NGUYỄN VĂN TRỌNG

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

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

Hà Nội - 2009

NGUYỄN VĂN TRỌNG

KIỂM THỬ PHẦN MỀM NHÚ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

STT Thuật ngữ và từ

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

1 ANSI American National Standards

Institute Viện tiêu chuẩn quốc gia Mỹ

2 CMM Capability Maturity Model

3 IEEE Institute of Electrical Electronics

Engineers Viện kỹ thuật điện & điện tử

4 ISO International Organization for

7 Kiểm thử theo hộp

8 Kiểm thử theo hộp

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

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

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

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

Em xin được gửi lời cảm ơn đến PGs.TS Huỳnh Quyết Thắng

-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

C HƯƠ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ách hiểu không đú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 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

I Các hoạt động hàng ngày (Công việc chính)

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

12 Thực hiện kiểm tra lần cuối và đánh giá kết quả

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ử

II Cải tiến chất lượng

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ử

III Phát triển nguồn lực

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

IV Bảo mật thông tin

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ử Thực hiện kiểm thử

Tạo báo cáo 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

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

Khắc phục lỗi

Giám sát vấn đề

Họp và báo cáo tiến độ

Chuẩn bị kiểm thử

Nghiên cứu yêu

ầ

Tạo thiết kế Kiểm thử Xem xét và phê

duyệt Tạo dữ liệu, thủ

tục và kịch bản kiểm thử

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

phát triển phần mềm nhúng

- Kiểm thử mức phê chuẩn phần mềm (Software Validation): Xác nhận rằng

phần mềm thực hiện đúng như yêu cầu

Thực hiện kiểm thử trên toàn bộ hệ thống để chứng thực rằng đặc trưng và chức năng của phần mềm đã đáp ứng được yêu cầu và các thủ tục

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

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

Kiểm thử nhằm chứng mình rằng chất lượng của phần mềm được đảm bảo Chất

lượng của phần mềm được nhìn nhận ở các yếu tố sau (‘FURPS’ [ISO 9126-1]): Chức năng (Functional capability) (thích hợp, chính xác, khả năng thao tác,

thao tác, an toàn),

Tiện lợi (Usability) (dễ hiểu, khả năng nắm bắt, khả năng thao tác, độ hấp dẫn),

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 xem xét mã nguồn (code review) Nó có thể được thực hiện bởi mộ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) Còn được gọi là kiểm thử áp lực Khi 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,…

Hộp trắng Kiểm tra dữ liệuKiểm thử phủ √ √ √ √

C HUƠ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

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

• 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à gì Làm thế nào để đạt được mụ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 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ề trong

mỗ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.2: Các tài 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 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ẩm: Yêu cầu phần mềm, Thiết kế chi tiết, Mã nguôn, Ca kiểm thử,

 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

Người tạo lỗi

Trạng thái tiếp theo Current

Kiểm thử viên Next Status

Current Status

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

Trạng thái tiếp theo Current

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

đầy đủ thông tin: dự án,

module, pha, hoạt động QC, cấp

độ, kiểu, kiểm thử viên, ngày

log lỗi

Ai: Ki ểm thử viên

Tr ạng thái lỗi: ERROR

Cái gì: - Phân tích và tìm nguyên

nhân của lỗi, tỉm giải pháp giải quyết, phân công người sửa lỗi

- Chấp nahận có lỗi (nế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ử lại các chức năng

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

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 bởi vì khi gặp lỗi sẽ phải quay lại bước phân tích để thực hiện sửa lỗi, ngoài ra phạ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

2.4.4 Phân lo ại lỗi

− 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

− Cao

− 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

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ị

Quản lý đội phát triển OSIRIS

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 trương 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

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ết định mở dự án và chỉ định người đứng đầu I A A D R R I 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 R R

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

Tập hợp kết quả Dữ liệu dự án D R R/A

Báo cáo kết quả sau

mỗi pha của dự án Báo cáo kết thuc giai đoạn A D R I I I R R 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

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 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 R R Đưa ra và kiểm tra

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

controlling Quality gate checklist A R R I I I R D Thực hiện kiểm duyệt

hoặc kiểm thử mức Unit Test Inspection Checklist A R I D R R

Define and handle

change requirements CR & updated associated WPs A I R D R A I I I R R I Nhận bàn giao Biên bản bàn giao I A D R

Nghiên cứu 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 R Tạo thiết kế chi tiết Tài liệu thiết kế chi tiết A D D R I I R

module

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

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

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

CUS- 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ểm thử viên

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 Cơ sở hạ tầng

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