Hệ thống thông tin quản lý chất lượng cho một công tay thiết kế vi mạch viễn thông theo chuẩn iso 9001 2015

Tổng hợp các kiên thức đã học được, tác giả đã xây dựng một hệ thống đơn giản nhưng vẫn đáp ứng được đầy đủ các chức năng cơ bản mà quy trình kiểm thử yêu cầu đó là: quản lý các đối tượn

ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA

………

TRẦN THANH LINH

HỆ THỐNG THÔNG TIN QUẢN LÝ CHẤT LƯỢNG CHO MỘT CÔNG TY THIẾT KẾ VI MẠCH VIỄN

THÔNG THEO CHUẨN ISO 9001:2015

NGÀNH: HỆ THỐNG THÔNG TIN QUẢN LÝ

MÃ SỐ: 60.34.04.05

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, tháng 12 năm 2016

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA –ĐHQG -HCM

Cán bộ hướng dẫn khoa học: TS Trương Tuấn Anh

Cán bộ chấm nhận xét 1: TS Trần Minh Quang

Cán bộ chấm nhận xét 2: TS Nguyễn Tuấn Đăng

Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp HCM ngày

Xác nhận của Chủ tịch Hội đồng đánh giá LV và Trưởng Khoa quản lý chuyên ngành

sau khi luận văn đã được sửa chữa (nếu có)

CHỦ TỊCH HỘI ĐỒNG TRƯỞNG KHOA KH & KTMT

(Ký tên) (Ký tên)

ĐẠI HỌC QUỐC GIA TP.HCM

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

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập - Tự do - Hạnh phúc

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ tên học viên: Trần Thanh Linh MSHV:7140652

Ngày, tháng, năm sinh: 15/06/1986 Nơi sinh: Quảng Nam Chuyên ngành: Hệ thống thông tin quản lý Mã số : 60.34.48

I TÊN ĐỀ TÀI:

Hệ thống thông tin quản lý chất lượng cho một công ty thiết kế vi mạch viễn

thông theo chuẩn ISO 9001:2015

II NHIỆM VỤ VÀ NỘI DUNG:

- Tìm hiểu, đánh giá quy trình hiện tại trong một công ty thiết kế vi mạch viễn thông tại TP Hồ Chí Minh

- Xây dựng một hệ thống thông tin quản lý dựa trên tiêu chuẩn ISO 9001:2015

nhằm quản lý và tối ưu các quy trình hiện tại

- Đánh giá hệ thống mới so với hệ thống các quy trình cũ và đánh giá mức độ thỏa

mãn của người sử dụng đối với hệ thống mới

III NGÀY GIAO NHIỆM VỤ : 4/7/2016

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 4/12/2016

V CÁN BỘ HƯỚNG DẪN : TS Trương Tuấn Anh

Chân thành cảm ơn

TP.HCM, ngày 04 tháng 12 năm 2016 Trần Thanh Linh

ii

TÓM TẮT NỘI DUNG LUẬN VĂN

Trong bối cảnh các quy trình kiểm thử trong công ty thiết kế vi mạch viễn thông vẫn còn khá thủ công, nhu cầu về việc áp dụng một hệ thống thông tin quản lý nhằm đáp ứng các nhu cầu về tổ chức, quản lý cũng như lưu trữ, truy vết là một nhu cầu thiết yếu

Do đó, tác giả đã tiến hành phân tích, thiết kế nên một hệ thống thông tin dựa trên các gợi ý từ tiêu chuẩn ISO 9001:2015, phù hợp với các yêu cầu hiện tại của tổ chức Tổng hợp các kiên thức đã học được, tác giả đã xây dựng một hệ thống đơn giản nhưng vẫn đáp ứng được đầy đủ các chức năng cơ bản mà quy trình kiểm thử yêu cầu đó là: quản lý các đối tượng người sử dụng trong hệ thống, quản lý các kiểm thử, quản lý các kế hoạch kiểm thử, và quản lý các sản phẩm cần kiểm thử Hệ thống trong quá trình chạy thử nghiệm đã nhận được sự chấp thuận và hưởng ứng khá tích cực từ phía các thành viên của nhóm kiểm thử sản phẩm Thông qua các kết quả thu được, tác giả đưa ra những hướng mở rộng nhằm hoàn thiện hệ thống trong tương lai

Từ đó giúp công ty nâng cao chất lượng sản phẩm, đáp ứng tốt hơn các yêu cầu về chất lượng từ khách hàng

iii

ABSTRACT

Quality management information systems are becoming more important for bussiness oragnizations in general and telecommunication IC design companies in particular With such systems, the quality control process is now consistent and becomes automatic Moreover, data/information is well organized, stored, and managed in such systems and thus system users can retrieve system data more quickly, accurately, and informatively

In this Thesis, we have developed a quality management information system based on the intructions from ISO 9001: 2015 standard as well as internal requirements from a telecommunication IC design company This system, though quite simple in comparison with commercial products developed by professional IT companies, fully provides the basic functionalities for testing process and quality control in the company such as user management, testcase management, testplan management, and product management We have also done an evaluation and the results show positive responses from most members of the Testing department at the company Additionally, this system also gets an approval for deploying as a main system for testing management in the company by the management board From responses in the evaluation, we also indentify possible expansions for the system to improve product quality management as well as to meet the customers’ quality requirements better

iv

LỜI CAM ĐOAN

Tôi xin cam đoan toàn bộ nội dung trong luận văn do tôi tự nghiên cứu, lập trình và thực hiện Những thông tin về phần đánh giá hệ thống được khảo sát một cách khách quan và trung thực

v

MỤC LỤC

CHƯƠNG I: GIỚI THIỆU ĐỀ TÀI 1

I.1 Giới thiệu 1

I.2 Ý nghĩa khoa học 2

I.3 Ý nghĩa thực tiễn 2

I.4 Các công trình nghiên cứu liên quan 2

I.5 Cấu trúc luận văn 3

CHƯƠNG II: MỤC TIÊU, GIỚI HẠN VÀ ĐỐI TƯỢNG NGHIÊN CỨU 4

II.1 Mục tiêu nghiên cứu 4

II.2 Phạm vi nghiên cứu 4

II.3 Bối cảnh hiện tại của tổ chức 4

II.4 Đánh giá thực trạng của hệ thống hiện tại 12

CHƯƠNG III: CƠ SỞ LÝ THUYẾT 13

III.1 Tiêu chuẩn ISO 9001:2015 13

III.2 Mô hình cơ sở dữ liệu NoSQL 13

III.3 Các tiêu chuẩn đánh giá sản phẩm viễn thông 14

CHƯƠNG IV: PHƯƠNG PHÁP NGHIÊN CỨU 15

IV.1 Phương pháp nghiên cứu thực tiễn 15

IV.2 Phương pháp đánh giá 15

IV.3 Tất cả các quy trình tuân theo tiêu chuẩn ISO 9001:2015 18

CHƯƠNG V: THIẾT KẾ HỆ THỐNG 20

V.1 Thiết kế logic 20

V.2 Thiết kế vật lý 37

CHƯƠNG VI: KẾT QUẢ ĐÁNH GIÁ 52

VI.1 Thử nghiệm hệ thống với dữ liệu thực tiễn 52

vi

VI.2 Đánh giá mức độ thỏa mãn của người sử dụng đối với hệ thống 52

CHƯƠNG VII: KẾT QUẢ LUẬN VĂN 59

VII.1 Kết quả đạt được 59

VII.2 Ưu điểm và hạn chế của hệ thống 60

VII.3 Hướng mở rộng 61

VII.4 Đóng góp của luận văn 61

DANH MỤC CÁC TÀI LIỆU THAM KHẢO 62

PHỤ LỤC 64

PHỤ LỤC A: BẢNG CÂU HỎI KHẢO SÁT 64

PHỤ LỤC B: NỘI DUNG PHỎNG VẤN 67

vii

DANH MỤC TỪ VIẾT TẮT

ISO International Organization

for Standardization

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

B2B Business To Business Mô hình kinh doanh giữa các

doanh nghiệp với nhau SVT System Verification Testing Bộ phận kiểm thử sản phẩm

viii

DANH MỤC HÌNH ẢNH

Hình 1: Quy trình kiểm thử sản phẩm 5

Hình 2: Xác nhận các yêu cầu 6

Hình 3: Cấu trúc một kế hoạch kiểm thử 7

Hình 4: Cấu trúc một phép kiểm thử 8

Hình 5: Quy trình tiến hành kiểm thử 9

Hình 6: Quy trình báo cáo vấn đề xảy ra trong khi kiểm thử 10

Hình 7: Quy trình phân phối và giải quyết vấn đề 11

Hình 8: Một phần của dòng sản phẩm AF6 test plan 16

Hình 9: Mô hình đánh giá sự thỏa mãn của người dùng 18

Hình 10: Tổng quan về hệ thống 20

Hình 11: Quan hệ giữa các đối tượng dữ liệu 21

Hình 12: Cấu trúc của một đối tượng người sử dụng 22

Hình 13: Cấu trúc của một phép kiểm thử 25

Hình 14: Cấu trúc của một kế hoạch kiểm thử 26

Hình 15: Cấu trúc của một sản phẩm cần kiểm thử 27

Hình 16: Cơ sở dữ liệu bên trong MongoDb 28

Hình 17: Kịch bản của hệ thống 30

Hình 18: Quy trình thêm đối tượng người sử dụng vào hệ thống 31

Hình 19: Quy trình định nghĩa các phép kiểm thử 32

Hình 20: Quy trình định nghĩa các kế hoạch kiểm thử 32

Hình 21: Quy trình thêm các phép kiểm thử và kế hoạch kiểm thử 33

Hình 22: Thực thi các kế hoạch kiểm thử 34

Hình 23: Quy trình báo cáo kết quả từng phép kiểm thử 35

Hình 24: Quản lý dựa trên rủi ro 35

Hình 25: Quy trình định nghĩa các sản phẩm 36

Hình 26: Quản lý hiệu suất của quy trình kiểm thử 37

Hình 27: Giao diện đăng nhập 38

Hình 28: Giao diện thêm mới người sử dụng 39

Hình 29: Giao diện quản lý các đối tượng người sử dụng 39

Hình 30: Giao diện quản lý thông tin người sử dụng 40

Hình 31: Các chức năng chính của hệ thống 41

Hình 32: Giao diện người sử dụng thông thường 42

Hình 33: Giao diện nhà quản lý cấp cao 42

Hình 34: Giao diện thêm vào một phép kiểm thử 43

Hình 35: Qiao diện phép kiểm thử với các tag 45

Hình 36: Giao diện quản lý các phép kiểm thử 46

Hình 37: Giao diện chỉnh sửa thông tin phép kiểm thử 47

ix

Hình 38: Giao diện thêm một kế hoạch kiểm thử 48

Hình 39: Giao diện quản lý các kế hoạch kiểm thử 48

Hình 40: Giao diện thêm một sản phẩm vào hệ thống 49

Hình 41: Giao diện quản lý các sản phẩm trong hệ thống 49

Hình 42: Giao diện các thực thi phép kiểm thử 50

Hình 43: Giao diện một kế hoạch kiểm thử chưa thực thi 51

x

DANH MỤC BẢNG BIỂU

Bảng 1: Thống kê kết quả cung cấp chính xác thông tin cho người dùng 53

Bảng 2: Thống kê kết quả cung cấp báo cáo chính xác 53

Bảng 3: Thống kê kết quả cung cấp chính xác quy trình của hệ thống 54

Bảng 4: Thống kê kết quả sự thỏa mãn của người dùng 54

Bảng 5: Thống kê kết quả tính quy chuẩn của hệ thống 55

Bảng 6: Thống kê kết quả tính rõ ràng của thông tin 56

Bảng 7: Thống kê kết quả tính thân thiện đối với người dùng 56

Bảng 8: Thống kê kết quả cung cấp tính dễ dàng tiếp cận đối với người dùng 57

Bảng 9: Thống kê kết quả tính khả thi của hệ thống 57

1

CHƯƠNG I: GIỚI THIỆU ĐỀ TÀI

Trong chương này, tác giả trình bày tổng quan về đề tài nghiên cứu, sơ lược về

tình hình, bối cảnh của tổ chức nơi tác giả tiến hành nghiên cứu Tác giả cũng đưa ra mục tiêu nghiên cứu, cấu trúc luận văn, ý nghĩa khoa học và thực tiễn của đề tài

I.1 Giới thiệu

Trải qua hơn mười năm thành lập và phát triển, công ty thiết kế vi mạch ở thành phố

Hồ Chí Minh đã cho ra đời nhiều dòng sản phẩm vi mạch viễn thông cung cấp cho các khách hàng ở nhiều thị trường như: Trung Quốc, Đài Loan, Hàn Quốc, Đức, Canada và Mỹ (ở đây tác giả xin không nêu tên công ty vì lý do chính sách của công

ty, các thông tin dữ liệu liên quan được phép sử dụng với mục đích học tập, nghiên cứu) Trong các quy trình sản xuất các sản phẩm vi mạch viễn thông thì quy trình kiểm định kiểm định sản phẩm đóng một vai trò hết sức quan trọng đến việc quyết định thành công của sản phẩm Hơn nữa, do đặc thù ngành vi mạch viễn thông là một ngành sản xuất ra các sản phẩm công nghệ cao hết sức phức tạp, với đặc điểm là chi phí của toàn bộ quá trình tạo nên sản phẩm chủ yếu nằm ở khâu nghiên cứu và phát triển nhiều hơn là khâu sản xuất thành phẩm Điều đó đồng nghĩa với việc kiểm định sản phẩm phải được tiến hành hết sức nghiêm túc, tuân thủ rất nhiều các tiêu chuẩn

về viễn thông, về thiết bị điện tử,… Hệ thống các tiêu chuẩn về viễn thông cũng rất phức tạp, do tính chất lịch sử, địa lý, chính trị mà có khi tồn tại cùng một lúc hai tiêu chuẩn cho cùng một vấn đề kỹ thuật (như tiêu chuẩn SONET ban hành bởi tổ chức ANSI năm 1985 và SDH ban hành bởi tổ chức ITU năm 1988 hiện nay vẫn được sử dụng song song [9]) Bên cạnh các tiêu chuẩn về viễn thông thì các tiêu chuẩn về quản lý chất lượng như tiêu chuẩn ISO 9001 cũng được xem như là một lợi thế cho công ty, đạt được chứng chỉ này không chỉ giúp các quy trình trong công ty được kiểm soát chặt chẽ hơn mà còn giúp tăng thêm mức độ hài lòng của khách hàng đối với sản phẩm của công ty [1]

Là một công ty hoạt động kinh doanh theo mô hình B2B (business to business), các dòng sản phẩm vi mạch viễn thông của công ty sẽ không trực tiếp đến tay người sử dụng cuối cùng mà sẽ được cung cấp như một phần tích hợp trong một hệ thống lớn hơn của các công ty khác Một vấn đề xảy ra đối với sản phẩm của công ty sẽ làm cho một chuỗi các bên có liên quan chịu ảnh hưởng rất lớn

Quy trình quản lý chất lượng sản phẩm hiện tại của công ty được tiến hành với khá nhiều bước còn thực hiện một cách thủ công và bị động Do đó tác giả quyết định chọn đề tài “xây dựng hệ thống thông tin quản lý chất lượng cho một công ty thiết kế

vi mạch viễn thông theo chuẩn ISO 9001:2015” làm đề tài nghiên cứu và thực hiện nghiên cứu tại TP.Hồ Chí Minh

2

I.2 Ý nghĩa khoa học

Áp dụng hệ thống thông tin quản lý vào quản lý chất lượng đã và đang trở thành xu hướng phổ biến trên toàn thế giới Mặc dù đã có nhiều nghiên cứu về các hệ thống thông tin quản lý, cũng như các tiêu chuẩn hóa về các hệ quản trị chất lượng, nhưng đối với lĩnh vực đặc thù như ngành thiết kế vi mạch viễn thông thì theo tìm hiểu của tác giả tới thời điểm 2016 vẫn chưa có nhiều nghiên cứu về vấn đề này

Do đó, mong muốn của tác giả là có một nghiên cứu kế thừa có chọn lọc các kiến thức, nghiên cứu trước đây về phân tích, thiết kế một hệ thống thông tin quản lý Từ

đó áp dụng vào lĩnh vực cụ thể là quản lý chất lượng các sản phẩm vi mạch viễn thông

để xây dựng nên một hệ thống thông tin quản lý phù hợp với những đặc thù của ngành này

I.3 Ý nghĩa thực tiễn

Phân tích, thiết kế hệ thống quản lý chất lượng sản phẩm cho công ty tại nơi tác giả đang làm việc, mục đích cuối cùng là giúp nâng cao chất lượng sản phẩm, dẫn đến nâng cao sự hài lòng của khách hàng, từ đó đem lại doanh thu nhiều hơn cho công ty

I.4 Các công trình nghiên cứu liên quan

Nghiên cứu, khảo sát về các lợi ích của việc áp dụng tiêu chuẩn ISO 9001 đối với các

tổ chức và doanh nghiệp, do tổ chức kiểm định Vinacontrol Cert thực hiện Nghiên cứu đã chỉ ra 14 lợi ích to lớn của việc áp dụng tiêu chuẩn ISO 9001, trong đó quan trọng nhất vẫn là thỏa mãn các nhu cầu của khách hàng Từ đó khuyến khích việc áp dụng tiêu chuẩn này vào các doanh nghiệp, tổ chức [1]

Các công trình nghiên cứu về việc áp dụng tiêu chuẩn ISO 9001 vào quy trình kiểm soát chất lượng của tổ chức Như nghiên cứu về việc hiện thực và cải tiến thông qua việc áp dụng tiêu chuẩn ISO 9001 của tác giả Antero Olliola [10] đã chỉ ra những điểm quan trọng đó là:

 Ưu điểm của việc áp dụng rõ ràng nhất đó là gia tăng sự hài lòng của khách hàng

 Nhược điểm là nhiều công việc liên quan tới giấy tờ hơn sẽ làm tiêu tốn một nguồn tài nguyên lao động không nhỏ của tổ chức

 Sự thật là tiêu chuẩn ISO 9001 không có định nghĩa về khái niệm “chất lượng của sản phẩm”, mà mỗi tổ chức phải tự định nghĩa khái niệm này tùy theo bối cảnh của mình

3

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

Luận văn được chia thành 7 chương với kết cấu lần lượt như sau:

CHƯƠNG I: GIỚI THIỆU ĐỀ TÀI

Trong chương này, tác giả trình bày tổng quan về đề tài nghiên cứu Sơ lược về tình

hình, bối cảnh của tổ chức

CHƯƠNG II: MỤC TIÊU, GIỚI HẠN VÀ ĐỐI TƯỢNG NGHIÊN CỨU

Trong chương này, tác giả mô tả rõ hơn về mục tiêu, giới hạn, và đối tượng nghiên cứu của đề tài

CHƯƠNG III: CƠ SỞ LÝ THUYẾT

Trong chương này, tác giả khái quát những lý thuyết liên quan đến đề tài nghiên cứu CHƯƠNG IV: PHƯƠNG PHÁP NGHIÊN CỨU

Trong chương này, tác giả trình bày về phương pháp nghiên cứu và đánh giá hệ thống sau khi xây dựng

CHƯƠNG V: THIẾT KẾ HỆ THỐNG

Trong chương này, tác giả mô tả chi tiết về hệ thống mà tác giả đã xây dựng Từ cơ

sở dữ liệu đến giao diện người sử dụng đầu cuối

CHƯƠNG VI: KẾT QUẢ ĐÁNH GIÁ

Trong chương này, tác giả trình bày những kết quả đánh giá hệ thống

CHƯƠNG VII: KẾT QUẢ LUẬN VĂN

Trong chương này, tác giả tóm tắt lại kết quả đạt được, ưu nhược điểm của hệ thống

mà tác giả đã xây dựng

4

CHƯƠNG II: MỤC TIÊU, GIỚI HẠN VÀ ĐỐI TƯỢNG NGHIÊN CỨU

Trong chương này, tác giả trình bày rõ hơn về mục tiêu, giới hạn, và đối tượng nghiên cứu của đề tài Tác giả cũng tiến hành tìm hiểu và đánh giá các quy trình hiện tại của tổ chức, nêu ra những điểm yếu mà đề tài cần phải khắc phục

II.1 Mục tiêu nghiên cứu

Xây dựng một hệ thống thông tin quản lý chất lượng của các dòng sản phẩm vi mạch (QMIS) nhằm giúp cho việc kiểm soát chất lượng được tiến hành một cách chủ động

và đảm bảo sự hài lòng tối đa từ phía khách hàng Đầu ra của đề tài là các thiết kế của

hệ thống và các tài liệu về hệ thống

II.2 Phạm vi nghiên cứu

Đề tài “xây dựng hệ thống thông tin quản lý chất lượng cho một công ty thiết kế vi mạch viễn thông theo chuẩn ISO 9001:2015” được áp dụng tại một công ty thiết kế

vi mạch với quy mô hơn 150 nhân viên ở thành phố Hồ Chí Minh Bài nghiên cứu chủ yếu tập trung vào quy trình kiểm thử sản phẩm của công ty nhằm xây dựng các quy trình kiểm định vừa đáp ứng các yêu cầu từ phía khách hàng, vừa đảm bảo tuân theo các yêu cầu của tiêu chuẩn ISO 9001:2015

II.3 Bối cảnh hiện tại của tổ chức

1 Quy trì nh kiểm thử sản phẩm tổng quát

Mô tả quy trình: quy trình kiểm thử sản phẩm trong công ty bao gồm các bước chính như sau

 Xác định các yêu cầu cần kiểm thử

 Định nghĩa lên các kế hoạch kiểm thử

 Tiến hành đánh giá các kế hoạch kiểm thử

 Tiến hành kiểm thử

 Tổng hợp các kết quả

 Tiến hành đánh giá kết quả

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

5

Hình 1: Quy trình kiểm thử sản phẩm

6

Hình 1 mô tả quy trình kiểm thử sản phẩm hiện tại trong công ty, quy trình này do bộ phận SVT (System Verification Testing) đảm nhiệm Đầu tiên, các yêu cầu chi tiết liên quan đến vấn đề cần kiểm thử sẽ được đưa đến, các yêu cầu này sẽ do quy trình xác định các yêu cầu kiểm thử đảm nhận Từ các yêu cầu này, các kế hoạch kiểm thử

sẽ được định nghĩa, trải qua các cuộc họp để đánh giá tính đầy đủ, chính xác của các

kế hoạch kiểm thử Nếu trong quá trình đánh giá phát hiện kế hoạch kiểm thử còn

“thiếu/sai” thì sẽ quay lại bước định nghĩa để xem xét bổ sung, sau đó lại lặp lại quá trình đánh giá Tiếp theo lần lượt từng phép kiểm thử trong kế hoạch kiểm thử sẽ được tiến hành và tổng hợp lại trong bảng kết quả, các cuộc họp để đánh giá tính đầy

đủ, chính xác của bảng kết quả sẽ được tiến hành, nếu các kết quả vẫn chưa đầy đủ (thiếu/sai), thì sẽ quay lại bước kiểm thử để rà soát lại và bổ sung cho đầy đủ Cuối cùng sẽ tổng hợp ra bảng kết quả sau cùng

2 Quy trình xác định các yêu cầu kiểm thử

Các yêu cầu này đa số sẽ được trích xuất từ các tiêu chuẩn đã được định nghĩa và phổ biến trên toàn thế giới bởi các tổ chức chuyên về viễn thông như: IEEE, ISO, … Đôi khi các khách hàng trực tiếp của công ty cũng có những yêu cầu riêng không hoặc chưa được quy định trong chuẩn nhưng cần thiết cho nhu cầu ở một thị trường cục bộ

 Kỹ sư kiểm thử hệ thống: tham gia để xác nhận các yêu cầu, sử dụng nó làm đầu vào cho quy trình xây dựng các kế hoạch kiểm thử

3 Quy trình định nghĩa lên các kế hoạch kiểm thử

Một kế hoạch kiểm thử (Testplan) là một tài liệu tổng quan về việc kiểm thử một sản phẩm Tài liệu này bao gồm: phạm vi của dự án, hướng tiếp cận, các nguồn lực cần

sử dụng để kiểm thử, các chức năng cần kiểm thử và không cần kiểm thử

Hình 3: Cấu trúc một kế hoạch kiểm thử

Hình 3 mô tả cấu trúc của một kế hoạch kiểm thử Trong đó mỗi kế hoạch kiểm thử gồm nhiều “Test Suite” nhỏ hơn: mỗi “Test Suite” là một tập hợp các test case cho một mục đích nhất định

“Test case” là đơn vị nhỏ nhất của một kế hoạch kiểm thử, một test case cần phải nêu lên được chi tiết các thành phần sau:

 Các điều kiện cần tiên quyết trước khi có thể tiến hành kiểm thử test case này

 Mô hình kiểm thử: cách kết nối các thành phần liên quan trong việc kiểm thử bao gồm: thiết bị cần kiểm thử, các máy test, cách nối dây cáp, …

 Mục đích của phép kiểm thử

Hình 4 mô tả cấu trúc của một “Test Case”

Các đối tượng tham gia vào quy trình định nghĩa lên các kế hoạch kiểm thử:

 Kỹ sư kiểm thử hệ thống: định nghĩa, liệt kê đầy đủ các phép thử cần tiến hành

và báo cáo cho nhà quản lý sản phẩm

4 Quy trình đánh giá các kế hoạch kiểm thử

Một hoặc nhiều cuộc họp sẽ được tiến hành để xem xét, đánh giá tính đầy đủ, đúng đắn của kế hoạch kiểm thử

Các đối tượng tham gia vào quy trình đánh giá các kế hoạch kiểm thử:

 Kỹ sư kiểm thử hệ thống: liệt kê chi tiết các phép kiểm thử

 Nhà quản lý sản phẩm: xem xét và đánh giá phản hồi

5 Quy trì nh tiến hành kiểm thử

Mô tả quy trình: kỹ sư kiểm thử hệ thống tiến hành các phép thử theo các bước cụ thể

đã được liệt kê trong bản kế hoạch kiểm thử, ở mỗi bước, đối chiếu với các yêu cầu

từ phép thử để đưa ra kết luận về kết quả của phép kiểm thử, và xem xét có cần tiến hành các bước kiểm thử kế tiếp hay không Quy trình diễn ra như hình mô tả bên dưới:

9

Hình 5: Quy trình tiến hành kiểm thử

Hình 5 mô tả quy trình chi tiết quy trình tiến hành kiểm thử hiện tại trong công ty Đối tượng tham gia trong quy trình tiến hành kiểm thử này là kỹ sư kiểm thử hệ thống Tuy nhiên, trong quá trình tiến hành kiểm thử, nếu kết quả của phép thử là “không đạt”, kỹ sư kiểm thử hệ thống cần báo cáo kết quả này ngay lập tức đến các đối tượng sau đây:

 Kỹ sư phần mềm: nếu kết quả sai được dự đoán do khối phần mềm gây nên

 Kỹ sư luận lý: nếu kết quả sai được dự đoán do khối luận lý gây nên

 Kỹ sư phần cứng: nếu kết quả sai được dự đoán do khối phần cứng gây nên

10

Hình 6: Quy trình báo cáo vấn đề xảy ra trong khi kiểm thử

Hình 6 mô tả các đối tượng liên quan trực tiếp đến quy trình báo cáo kết quả kiểm thử

Quá trình báo cáo vấn đề này diễn ra dưới sự giám sát của nhà quản lý sản phẩm Quy trình phân tích và giải quyết vấn đề sẽ được tiến hành như sau:

11

Hình 7: Quy trình phân phối và giải quyết vấn đề

Hình 7 mô tả quy trình mà một vấn đề khi phát sinh sẽ được giải quyết như thế nào

 Phân tích vấn đề: vấn đề cần được phân tích là xảy ra ở khối nào, dự đoán là

do phần mềm, phần cứng hay phần luận lý gây ra

 Phân phối vấn đề: sau khi có được kết quả phân tích, vấn đề được chuyển giao đến cho đúng kỹ sư có liên quan thông qua email

 Giải quyết vấn đề: người kỹ sư nhận được thông tin sẽ tiến hành xử lý vấn đề

 Kiểm tra lại: sau khi tiến hành các bước khắc phục, kỹ sư kiểm thử hệ thống

sẽ tiến hành lại phép kiểm tra này

 Báo cáo kết quả: kết quả về phép kiểm thử sẽ được cập nhật vào kết quả chung của kế hoạch kiểm thử

6 Quy trì nh tổng hợp kết quả kiểm thử

Các kết quả của quy trình kiểm thử sẽ được thu thập và tổng kết bằng tài liệu Excel

12

7 Quy trì nh đánh giá kết quả kiểm thử

Một hoặc nhiều cuộc họp sẽ được tiến hành để đánh giá kết quả kiểm thử, nếu vẫn còn phép kiểm thử nào cần phải được đánh giá lại thì phép kiểm thử đó cần phải tiến hành lại và sẽ có cuộc họp tiếp theo để đánh giá lại phép thử này

8 Quy trì nh Báo cáo kết quả sau cùng

Sẽ có thống kê về tỷ lệ phần trăm số phép kiểm thử đã được tiến hành, chưa được được tiến hành

Thống kê về tỷ lệ phần trăm số phép thử có kết quả lần lượt là Đạt, Không đạt

II.4 Đánh giá thực trạng của hệ thống hiện tại

Thông qua phân tích các quy trình, ta nhận thấy các vấn đề cần phải khắc phục như sau:

 Quy trình từ thu nhận yêu cầu tới đưa ra kết quả kiểm thử là một quy trình lâu dài, trải qua rất nhiều bước, mà các kết nối giữa các bước này vẫn còn khá mơ

hồ Từ kết quả kiểm thử khó có thể truy vết ngược về lại các yêu cầu ban đầu được

 Quy trình tiến hành kiểm thử có thể bị gián đoạn vì quy trình giải quyết các vấn đề phát sinh trong khi kiểm thử dẫn đến việc không kiểm soát được thời gian sẽ hoàn thành việc kiểm thử

 Chưa có một hệ thống thông tin quản lý để quản lý, lưu trữ và thống kê hỗ trợ trong quá trình kiểm thử mà vẫn tiến hành các bước tuần tự thủ công

13

CHƯƠNG III: CƠ SỞ LÝ THUYẾT

Trong chương này, tác giả trình bày những lý thuyết liên quan đến đề tài nghiên cứu bao gồm tổng quan về tiêu chuẩn ISO 9001:2015, mô hình cơ sở dữ liệu NoSQL

và các tiêu chuẩn để đánh giá chất lượng một sản phẩm vi mạch viễn thông

III.1 Tiêu chuẩn ISO 9001:2015

Phiên bản mới ISO 9001:2015 chính thức được ban hành và áp dụng từ ngày 15/09/2015 (thay thế cho phiên bản ISO 9001:2008) với những thay đổi đột phá, giúp doanh nghiệp đi vào quản lý thực chất trong bối cảnh cạnh tranh toàn cầu đang ngày càng phát triển Phiên bản mới ISO 9001:2015 được tổ chức ISO kỳ vọng có thể duy trì đến 25 năm [6]

Tiêu chuẩn ISO là tiêu chuẩn được áp dụng khi tổ chức cần chứng tỏ khả năng cung cấp ổn định các sản phẩm đồng thời muốn nâng cao sự hài lòng của khách hàng Khi

áp dụng tiêu chuẩn này, tổ chức cần xác định các vấn đề nội bộ và bên ngoài có liên quan đến mục đích của tổ chức Xác định các bên liên quan của hệ thống quản lý chất lượng Từ đó tiến hành hoạch định nhằm thiết lập các mục tiêu chất lượng có thể đo lường được bao gồm đánh giá rủi ro và xử lý rủi ro Đảm bảo các nguồn lực, con người và cơ sở hạ tầng để đáp ứng các mục tiêu của tổ chức Cuối cùng là quá trình cải tiến không ngừng để nâng cao sự hài lòng của khách hàng, đặc biệt là với các yêu cầu của các khách hàng tương lai [6]

III.2 Mô hình cơ sở dữ liệu NoSQL

NoSQL (Not only SQL) là mô hình cơ sở dữ liệu không quan hệ, nhằm làm giảm các phép tính toán, các kiểm tra ràng buộc trên dữ liệu… do đó tốc độ đọc ghi nhanh hơn Các ưu điểm của NoSQL: là mã nguồn mở, dễ dàng mở rộng quy mô và hỗ trợ nhiều

mô hình lưu trữ dữ liệu khác nhau như lưu kiểu key-value, bigtable, document hay lưu thông tin đồ thị [2] Trong đề tài này, tác giả sử dụng hệ quản trị cơ sở dữ liệu MongoDB để thiết kế cơ sở dữ liệu cho hệ thống MongoDB là một cơ sở dữ liệu hướng document, do công ty 10gen phát triển Với NoSQL chúng ta có thể mở rộng

dữ liệu mà không lo tới những việc như tạo khóa ngoại, khóa chính, kiểm tra ràng buộc,…[2] Vì NoSQL không hạn chế việc mở rộng dữ liệu nên tồn tại nhiều nhược điểm như: sự phụ thuộc của từng bản ghi, tính nhất quán, toàn vẹn dữ liệu,…nhưng chúng ta có thể chấp nhận những nhược điểm đó để khiến ứng dụng cải thiện hiệu suất cao hơn khi giải quyết những bài toàn lớn về hệ thống thông tin, phân tán hay lưu trữ dữ liệu [16] Lý do là đối với hệ thống kiểm định sản phẩm viễn thông, đặc điểm của hệ thống chủ yếu là lượng dữ liệu phát sinh ngày càng lớn và cập nhật liên tục, các dữ liệu chủ yếu được ghi vào, quá trình đọc ra chỉ xuất hiện khi cần lập các báo cáo

14

III.3 Các tiêu chuẩn đánh giá sản phẩm viễn thông

MEF (Metro Ethernet Forum) là một liên minh công nghiệp toàn cầu với gần 220 tổ chức bao gồm các nhà cung cấp dịch vụ viễn thông, các nhà sản xuất thiết bị mạng, các nhà cung cấp chất bán dẫn và các tổ chức thử nghiệm MEF định nghĩa nên các tài liệu mô tả về cách kết nối, thử nghiệm và kiểm định các sản phẩm viễn thông nhằm tiêu chuẩn hóa và tạo sự đồng thuận giữa các nhà cung cấp và các nhà sản xuất thiết bị [8] Các tài liệu của MEF sẽ được tham khảo trong đề tài bao gồm:

 MEF 8: Implementation Agreement for the Emulation of PDH, 2004 [7]

 MEF 18: Abtract Test Suite for Circuit Emulation Services over Ethernet base

on MEF 8, 2007

 MEF 22: Mobile Backhaul Implementation Agreement Phase 1, 2009

15

CHƯƠNG IV: PHƯƠNG PHÁP NGHIÊN CỨU

Trong chương này, tác giả trình bày về phương pháp nghiên cứu và đánh giá hệ thống sau khi xây dựng Các phương pháp nghiên cứu bao gồm phân tích tổng kết kinh nghiệm thực tiễn, xây dựng và chạy thử hệ thống Các phương pháp đánh giá bao gồm đánh giá định tính – phỏng vấn những nhân vật quan trọng và đánh giá định lượng – lập bảng khảo sát thu thập ý kiến của các người dùng cuối của hệ thống Ngoài ra, tác giả còn đánh giá hệ thống dựa vào những chỉ dẫn từ tiêu chuẩn ISO 9001:2015

IV.1 Phương pháp nghiên cứu thực tiễn

Phương pháp phân tích tổng kết kinh nghiệm: dựa trên các quy trình của hệ thống đang tồn tại, phân tích và đánh giá ưu nhược điểm, từ đó đề nghị ra một mô hình hệ thống thông tin nhằm quản lý và cải tiến các quy trình hiện tại Hệ thống thông tin sau khi được xây dựng phiên bản đầu tiên, có đầy đủ cơ sở dữ liệu, các quy trình, giao diện người sử dụng, sẽ được đem vào áp dụng thử nghiệm Bước đầu sẽ tiến hành chạy song song với các quy trình hiện tại nhằm khảo sát, đánh giá so sánh hệ thống

cũ và hệ thống mới Từ đó rút ra các ưu nhược điểm cũng như các điểm chính yếu cần phải cải thiện thêm cho hệ thống được hoàn thiện hơn

IV.2 Phương pháp đánh giá

1 Đánh giá tính chính xác của hệ thống so với các quy trì nh hiện tại của tổ chức

Dựa trên các tập dữ liệu sẵn có (dữ liệu về các dòng sản phẩm vi mạch của công ty,

dữ liệu về các quy trình test, các báo cáo chất lượng, …) tiến hành so sánh, đánh giá tương quan giữa hệ thống mới và quy trình hiện tại

Trong đó, dữ liệu để tiến hành đánh giá sẽ sử dụng các kết quả kiểm soát chất lượng trước đây của công ty, bao gồm các dòng sản phẩm chính của công ty là:

AT4848 Multiservice Add/Drop

16

Multiplexer

2008-now

back-haul solutions

2008-now

Trong đó chủ yếu sử dụng dữ liệu của dòng sản phẩm AF6 thu thập trong khoảng thời gian từ năm 2013 đến nay, do tác giả có kinh nghiệm làm việc nhiều liên quan trực tiếp tới dòng sản phẩm này

Hình 8: Một phần của dòng sản phẩm AF6 test plan

Hình 8 mô tả một ví dụ kế hoạch kiểm thử của một dòng sản phẩm trong công ty

2 Đánh giá mức độ thỏa mãn của người sử dụng đối với hệ thống

Để đánh giá hiệu quả của việc sử dụng hệ thống đối với công ty, tác giả sử dụng mô hình “Management Information Systems Success Evaluation Model” của các tác giả Mariette Visser, Judy van Biljon, Marlien Herselman (2013) [15]

17

Trong đó tập trung làm rõ các mục tiêu chính của hệ thống thông qua các câu hỏi: Nội dung:

 Hệ thống có cung cấp đủ thông tin cần thiết?

 Nội dung thông tin có thỏa mãn nhu cầu?

 Các báo cáo của hệ thống có chính xác những gì người dùng cần?

 Hệ thống có cung cấp đủ thông tin?

Sự chính xác:

 Hệ thống có hoạt động chính xác không?

 Người dùng có thỏa mãn với sự chính xác của hệ thống không?

Định dạng:

 Đầu ra của hệ thống có thể hiện sự hữu ích không?

 Thông tin có rõ ràng không?

Mức độ dễ sử dụng:

 Hệ thống có thân thiện không?

 Hệ thống có dễ sử dụng không?

Tính đúng thời điểm:

 Hệ thống có cung cấp thông tin cần thiết đúng thời điểm không?

 Hệ thống có cung cấp những thông tin mới nhất không?

18

Hình 9: Mô hình đánh giá sự thỏa mãn của người dùng

Hình 9 mô tả mô hình đánh giá sự thỏa mãn của người dùng đầu cuối, từ mô hình này tác giả tham khảo để phỏng vấn và khảo sát các đối tượng có liên quan nhằm thu thập ý kiến đánh giá, cải thiện hệ thống ngày càng hoàn thiện hơn

IV.3 Tất cả các quy trình tuân theo tiêu chuẩn ISO 9001:2015

Tất cả các quy trình của hệ thống được thiết kế nhằm giúp công ty đạt được chứng chỉ ISO 9001:2015 Để đạt được điều đó, các quy trình kiểm thử cũng cần tuân theo các yêu cầu của tiêu chuẩn ISO 9001:2015

Các điều khoản:

 Khoản 0 – 3 – Giới thiệu và phạm vi của tiêu chuẩn

o Khi tổ chức cần chứng tỏ khả năng cung cấp ổn định các sản phẩm

o Muốn nâng cao sự hài lòng của khách hàng

 Khoản 4 – Bối cảnh của tổ chức

o Cần xác định các vấn đề nội bộ và bên ngoài có liên quan đến mục đích của tổ chức

19

o Xác định phạm vi của hệ thống quản lý chất lượng

 Khoản 5 – Lãnh đạo

o Người quản lý phải đảm bảo các yêu cầu được kết hợp vào các quá

trình, các mục tiêu phù hợp với chiến lược của tổ chức

o Người quản lý hướng vào khách hàng để nâng cao sự hài lòng

 Khoản 6 – Kế hoạch

o Bao gồm đánh giá rủi ro và xử lý rủi ro

o Phải thiết lập các mục tiêu chất lượng có thể đo lường được

 Khoản 7 – Hỗ trợ

o Đảm bảo các nguồn lực, con người và cơ sở hạ tầng

 Khoản 8 – Hoạt động

o Lập kế hoạch, thực hiện và kiểm soát các quá trình cần thiết

o Xác định các yêu cầu liên quan đến sản phẩm

 Khoản 9 – Đánh giá hiệu suất

o Cần giám sát, đo lường, phân tích, và đánh giá

 Khoản 10 – Cải thiện

o Xác định các cơ hội cải tiến

Trong quá trình xây dựng hệ thống thông tin quản lý, tác giả đã thiết kế để các quy

trình đảm bảo được các điều khoản này Cụ thể, các quy trình trong hệ thống tuân

theo 4 bước chính đó là: lên kế hoạch, thực hiện, kiểm tra và cải thiện Từ việc định

nghĩa nên các kế hoạch kiểm thử, tới việc tiến hành thực hiện lần lượt từng phép kiểm

thử, cho đến việc các nhà quản lý cấp cao sẽ xem xét lại kết quả kiểm thử một lần

nữa để có thể điều chỉnh kịp thời các dữ liệu đầu vào của hệ thống Thông qua đó,

giúp cho hệ thống hoạt động ngày càng hiệu quả và công ty có thể chứng minh quy

trình kiểm thử của mình để đạt được chứng chỉ ISO 9001:2015

20

CHƯƠNG V: THIẾT KẾ HỆ THỐNG

Trong chương này, tác giả trình bày chi tiết về hệ thống mà tác giả đã xây dựng bao gồm thiết kế cơ sở dữ liệu, thiết kế các xử lý và quản lý các dữ liệu vào, ra hệ thống Ngoài ra, tác giả cũng trình bày những giao diện mà hệ thống cung cấp cho những người sử dụng đầu cuối

V.1 Thiết kế logic

1 Tổng quan về hệ thống

Để thiết kế hệ thống vừa cung cấp đầy đủ các chức năng cần thiết, vừa đảm bảo tính linh hoạt, mở rộng dễ dàng khi cần thiết, tác giả đã thiết kế hệ thống với các thành phần cơ bản như sau:

 Cơ sở dữ liệu chạy trên nền tảng MongoDB phiên bản 3.2.8

 Khối kết nối trực tiếp đến cơ sở dữ liệu hiện thực dựa trên phần mở rộng Pymongo phiên bản 3.3.0

 Các mô tả, thực thi quy trình hiện thực bằng ngôn ngữ Python phiên bản 3.4.4

 Các giao diện người sử dụng thiết kế bằng công cụ hỗ trợ PyQt phiên bản 4.8.7 Các thành phần này được thiết kế, hiện thực độc lập với nhau, đảm bảo tính dễ dàng khi muốn thay đổi một thành phần mà không muốn ảnh hưởng nhiều đến các thành phần khác

Hình 10: Tổng quan về hệ thống

21

Hình 10 là mô tả tổng quan về hệ thống mà tác giả đã thiết kế và xây dựng trong bài luận này

2 Thiết kế cơ sở dữ liệu

Hệ thống thông tin quản lý do tác giả thiết kế dựa trên mối quan hệ giữa các đối tượng

cơ sở dữ liệu Các đối tượng cơ sở dữ liệu chính trong hệ thống là: người sử dụng, các testcase, testplan và các dự án, sản phẩm Do đặc điểm của mô hình cơ sở dữ liệu NoSQL, mỗi đơn vị thông tin dữ liệu về một đối tượng được lưu trữ trong một đơn

vị gọi là document, tập hợp nhiều document có chung một đặc điểm tạo nên một collection Như vậy, cơ sở dữ liệu của hệ thống sẽ được tổ chức thành 4 collection tương ứng với 4 đối tượng chính mà hệ thống phải quản lý đó là: User, TestPlan, Testcase, và Project

Hình 11: Quan hệ giữa các đối tượng dữ liệu

Hình 11 mô tả tổng quan về mối quan hệ giữa các đối tượng trong cơ sở dữ liệu của

hệ thống, theo đó mỗi đối tượng người sử dụng có thể tạo ra nhiều phép kiểm thử và

kế hoạch kiểm thử (1:N), mỗi kế hoạch kiểm thử được tạo ra dành riêng cho một sản phẩm cần kiểm thử duy nhất (1:1), và mỗi kế hoạch kiểm thử có thể bao gồm nhiều phép kiểm thử bên trong (1:N) Phần nội dung tiếp theo sẽ giải thích chi tiết từng đối tượng cơ sở dữ liệu cụ thể

a) Các đối tượng người sử dụng hệ thống:

Các thuộc tính cấu tạo nên 1 người sử dụng (User) trong hệ thống:

22

• Identifier: mỗi đối tượng người sử dụng có một số định danh duy nhất

Thuộc tính này được hổ trợ tạo ra và quản lý tự động bởi NoSQL

• Username: tên truy cập của người sử dụng, được tạo ra và cung cấp bởi

nhà quản trị hệ thống

• Password: mật khẩu truy cập, được tạo ra và cung cấp bởi nhà quản trị hệ

thống, mỗi người sử dụng có thể thay đổi mật khẩu của mình nhưng không thể thay đổi tên truy cập

• Department: phòng ban nơi người sử dụng này đang làm việc, bao gồm các

phòng ban trong công ty: Software, Hardware, System verification, IT

• Role: thể hiện vai trò cũng như các quyền hạncủa người sử dụng trong hệ

thống thông tin, gồm có: Member, Manager, Project manager, Director, Admin

Hiện tại, hệ thống chỉ lưu trữ những thông tin trên là cơ bản và cần thiết nhất để cấu tạo nên một đơn vị người sử dụng trong hệ thống, các thông tin khác khi cần có thể được thêm vào sau

Hình 12: Cấu trúc của một đối tượng người sử dụng

23

Hình 12 mô tả các đối tượng người sử dụng dưới góc nhìn cấu trúc cơ sở dữ liệu Ở đây mỗi đối tượng là một document được lưu trữ với các trường thông tin chi tiết kèm theo

có thể chứa nhiều testcase

Các thuộc tính cấu tạo nên 1 phép kiểm thử (TestCase) trong hệ thống:

• Identifier: kiểu dữ liệu (Object ID), được gán tự động bởi MongoDB mỗi

khi người dùng thêm một phép kiểm thử mới vào hệ thống Thuộc tính này

là duy nhất cho mỗi testcase

• Title: kiểu dữ liệu (String), tiêu đề của phép kiểm thử, nói lên nội dung

chính yếu mà phép kiểm thử cần phản ánh

• Summary: kiểu dữ liệu (String), mô tả ngắn về mục đích của phép kiểm

thử, thông tin nhiều và rõ ràng hơn sơ với phần tiêu đề

• Procedure: kiểu dữ liệu (Arrays of String), mô tả các bước thực hiện phép

kiểm thử Một phép thử phải trải qua nhiều bước từ cấu hình cho tới thực thi và ghi nhận kết quả, đây chính là nội dung của phần dữ liệu này

• Require: kiểu dữ liệu (String), phép kiểm thử này là bắt buộc hay tùy chọn:

mandatory/optional Đặc điểm của ngành kiểm thử sản phẩm vi mạch viễn thông là các phép kiểm thử có hai mức độ ưu tiên chính, trong đó nếu độ

ưu tiên là bắt buộc thì phép thử này đặc biệt đã được quy định rõ ràng trong các tiêu chuẩn và bắt buộc các tổ chức muốn hiện thực phải đặc biệt tuân thủ đúng như vậy Ngược lại, các tiêu chuẩn viễn thông vẫn còn định nghĩa nhiều vùng thông tin sẽ được dành riêng để sử dụng trong tương lai mà hiện tại chưa có nhu cầu, dó đó các phép kiểm thử cũng không cần đặt mức

độ ưu tiên quá cao đối với các loại thông tin này

24

• Assigned to: kiểu dữ liệu (String), thông tin thành viên hệ thống được gán

cho việc thưc hiện phép kiểm thử này

• Moderator: kiểu dữ liệu (String), thông tin thành viên được chỉ định cho

việc giám sát phép kiểm thử này

• Tags: kiểu dữ liệu (Arrays of String), phục vụ cho việc sắp xếp, gom cụm

các phép kiểm thử được dễ dàng hơn

• Result: kiểu dữ liệu (String), thông tin về kết quả của việc đánh giá phép

kiểm thử

• Feature: kiểu dữ liệu (String), thông tin liên quan đến chức năng mà phép

kiểm thử này hướng đến Do một sản phẩm vi mạch viễn thông bản thân

đã là một hệ thống phức tạp gồm rất nhiều chức năng bên trong, nên các phép kiểm thử thông thường không thể bao gồm toàn bộ sản phẩm mà chỉ đánh giá một phần chức năng cụ thể trong hệ thống mà thôi

Ví dụ phép kiểm thử khi được mô tả ở dạng dữ liệu BSON:

25

}

Hình 13: Cấu trúc của một phép kiểm thử

Hình 13 mô tả các đối tượng phép kiểm thử dưới góc nhìn cấu trúc cơ sở dữ liệu Ở đây mỗi đối tượng là một document được lưu trữ với các trường thông tin chi tiết kèm theo

c) Quản lý các kế hoạch kiểm thử

Các thuộc tính cấu tạo nên 1 kế hoạch kiểm thử (Test Plan) trong hệ thống:

• Identifier: kiểu dữ liệu (Object ID), được gán tự động bởi MongoDB mỗi

khi người dùng thêm một kế hoạch kiểm thử mới vào hệ thống Thuộc tính này là duy nhất cho mỗi testplan

• Title: kiểu dữ liệu (String), tiêu đề của một kế hoạch kiểm thử, nói lên nội

dung chính yếu mà kế hoạch kiểm thử cần phản ánh

• Summary/Scope: tóm tắt về mục tiêu, phạm vi và chức năng của kế hoạch

kiểm thử này, thông tin nhiều và rõ ràng hơn sơ với phần tiêu đề

• Risks: liệt kê tất cả các rủi ro có thể gặp phải khi thực thi kế hoạch kiểm

thử này Với mong muốn thiết kế hệ thống bám sát tư duy quản lý dựa trên rủi ro của tiêu chuẩn ISO 9001:2015, tác giả thiết kế thuộc tính này để nhà

26

quản lý có thể dễ dàng theo dõi và hạn chế các rủi ro có thể làm ảnh hưởng đến các kế hoạch, mục tiêu của dự án

• SDK version: phiên bản hạ tầng software, có khả năng thay đổi tùy theo

việc thực thi testplan

• RTL version: phiên bản hạ tầng hardware, có khả năng thay đổi tùy theo

việc thực thi testplan

• Testcases: danh sách các phép kiểm thử được gán vào kế hoạch kiểm thử

này, một kế hoạch kiểm thử chỉ được xem là đạt được mục tiêu khi toàn bộ tất cả các phép kiểm thử đều được tiến hành kiểm thử và đạt được kết quả cho phép

Hình 14: Cấu trúc của một kế hoạch kiểm thử

Hình 14 mô tả các đối tượng kế hoạch kiểm thử dưới góc nhìn cấu trúc cơ sở dữ liệu Ở đây mỗi đối tượng là một document được lưu trữ với các trường thông tin chi tiết kèm theo Đồng thời hình này cũng thể hiện mối quan hệ 1:N trong đó một

kế hoạch kiểm thử có thể bao gồm 1 hoặc nhiều phép kiểm thử

d) Quản lý các dự án, sản phẩm

Các thuộc tính cấu tạo nên một sản phẩm (Project/Product) trong hệ thống:

 Identifier: kiểu dữ liệu (Object ID), được gán tự động bởi MongoDB mỗi khi người dùng thêm một sản phẩm cần kiểm thử mới vào hệ thống Thuộc tính này là duy nhất cho mỗi product

 StartTime: thời điểm bắt đầu dự án

 EndTime: thời điểm kết thúc dự án

 Code: mã sản phẩm, mã sản phẩm được ban lãnh đạo công ty chọn và đặt khi bắt đầu một sản phẩm mới, mã này là duy nhất đối với mỗi sản phẩm

 Features: danh sách tất cả các chức năng mà sản phẩm có liên quan

Hình 15: Cấu trúc của một sản phẩm cần kiểm thử

Hình 15 mô tả các đối tượng sản phẩm cần kiểm thử dưới góc nhìn cấu trúc cơ sở

dữ liệu Ở đây mỗi đối tượng là một document được lưu trữ với các trường thông tin chi tiết kèm theo