NGHIÊN cứu về KIỂM THỬ và một CÔNG cụ KIỂM THỬ tự ĐỘNG

MỤC LỤC LỜI CẢM ƠN 4 PHẦN I .MỞ ĐẦU 5 PHẦN II: NỘI DUNG 7 CHƯƠNG I. TỔNG QUAN 7 1.1. LỊCH SỬ HÌNH THÀNH 7 1.2. TÌNH HÌNH SẢN XUẤT MÍA TRONG NƯỚC HIỆN NAY 8 CHƯƠNG II :CÔNG NGHỆ SẢN XUẤT ĐƯỜNG MÍA 13 2.1. Quy trình sản xuất mía của nhà máy 13 2.2. NGUYÊN LIỆU MÍA 14 2.2.1. Phân loại 14 2.2.2. Hình thái 15 2.2.3. Thu hoạch và bảo quản 15 2.2.4. Tính chất và thành phần nước mía 16 2.2.5. Quản lý nguyên liệu mía 24 2.3. THU NHẬN VÀ XỬ LÍ DỊCH NƯỚC MÍA 25 2.3.1. Xử lý sơ bộ mía – xé tơi mía 25 2.3.1.1. Mục đích 25 2.3.1.2. Thiết bị xử lý mía Quá trình xử lí mía trước khi ép bao gồm: 25 2.3.2. Phương pháp lấy nước mía 26 2.3.2.1. Thu nhận nước mía bằng phương pháp ép 26 2.3.2.2. Thu nhận nước mía bằng phương pháp khuếch tán 29 2.2.2.3. So sánh phương pháp ép và phương pháp khuyếch tán 32 2.3.2.4. Tác dụng của hóa học và vi sinh vật trong quá trình thu nhận nước mía. 33 2.4. Làm sạch nước mía 34 2.4.1. Các phương pháp làm sạch nước mía 35 2.4.1.1. Phương pháp vôi hóa 35 2.4.1.2. Phương pháp sunfit hóa 38 2.4.1.3. Phương pháp cacbonat hóa 41 2.4.1.4. Phương pháp BlancoDirecto: sản xuất đường trắng trực tiếp 44 2.4.1.5. So sánh các phương pháp làm sạch nước mía 45 2.4.2. Lắng nước mía 45 2.4.2.1. Mục đích 45 2.4.2.2. Nguyên lý 45 2.4.2.3. Quá trình lắng 46 2.4.2.4. Các yếu tố ảnh hưởng đến quá trình lắng 47 2.4.3. Lọc nước mía: 48 2.4.3.1. Mục đích 48 2.4.3.2. Nguyên lý 48 2.4.3.2. Quá trình lọc 48 2.4.3.2. Các yếu tố ảnh hưởng đến lọc 50 2.5. BỐC HƠI NƯỚC MÍA 50 2.5.1. Nguyên lý 50 2.5.2.1. Phương án bốc hơi áp lực: hơi làm việc trong điều kiện áp lực 51 2.5.2.2. Phương án bốc hơi chân không: 52 2.5.2.3. Phương án bốc hơi áp lực chân không: 52 2.5.3. Đánh giá các phương án nhiệt 57 2.5.4. Thiết bị gia nhiệt và bốc hơi 58 2.5.4.1. Thiết bị gia nhiệt 58 2.5.4.2. Thiết bị bốc hơi: yêu cầu đối với thiết bị bốc hơi bao gồm: 58 2.5.5. Biến đổi hóa học trong quá trình bốc hơi 59 2.5.5.1. Sự chuyển hóa đường sacaroza 59 2.5.5.2. Sự phân hủy sacaroza và tăng cường độ màu 59 2.5.5.3. Sự biến đổi độ kiềm 59 2.5.5.4. Sự biến đổi độ tinh khiết 60 2.5.5.5. Sự tạo cặn 60 2.6. NẤU ĐƯỜNG 63 2.6.1. Nguyên lý chung 63 2.6.1.1. Độ hòa tan của đường và dung dịch bão hòa 63 2.6.1.2. Hệ số bão hòa 64 2.6.1.3. Hệ số quá bão hòa 64 2.6.2. Động học của quá trình kết tinh đường 65 2.6.2.1. Sự hình thành nhân tinh thể 65 2.6.2.2. Sự lớn lên của tinh thể 66 2.6.2.2. Cơ chế của quá trình kết tinh 67 2.6.3. Các yếu tố chủ yếu ảnh hưởng đến nấu đường 68 2.6.3.1. Công nghệ nấu đường 69 2.6.3.2. Yêu cầu công nghệ 69 2.6.3.3. Quá trình nấu đường 70 2.6.3.4. Kỹ thuật nấu đường 72 2.6.3.5. Hiện tượng không bình thường trong công đoạn nấu đường 73 2.6.4. Trợ tinh và sự tạo thành mật cuối 77 2.6.4.1. Kết tinh làm lạnh (trợ tinh) đường non 77 2.6.4.2. Sự tạo thành mật cuối 79 2.7. Hoàn tất 81 2.7.1. Phân ly đường non 81 2.7.2. Sấy đường 84 2.7.3. Đóng bao và bảo quản đường 86 CHƯƠNG III : AN TOÀN LAO ĐỘNG VÀ VỆ SINH XÍ NGHIỆP 88 3.1: An toàn lao động 88 3.2: Những an toàn cụ thể trong nhà máy: 88 CHƯƠNG IV. MỘT SỐ KIẾN NGHỊ VÀ ĐỀ XUẤT 91 PHẦN III. KẾT LUẬN 92 LỜI CẢM ƠN Thực tập chính là chiếc cầu nối giữa lý thuyết và thực tế. Nó tạo điều kiện cho sinh viên tiếp cận với sản xuất thực tế, đồng thời thực hiện hoá những lý thuyết đã học tại trường. Quả như vậy, trong đợt thực tập vừa qua tuy là ngắn ngủi, nhưng chúng em đã nhận được một lượng kiến thức khá bổ ích và lý thú. Lời đầu tiên Đoàn thực tập chúng em xin chân thành cảm ơn trường đại học công nghiệp thành phố Hồ Chí Minh cùng các thầy cô bên tổ hóa đã đưa ra đề tài và hướng dẫn chúng em trong đợt thực tập vừa rồi .Đặc biệt đoàn thực tập chúng em xin gửi lời cảm ơn sâu sắc đến cô giáo Trần Thị Tuyết Nhung . ( giảng viên hướng dẫn thực tập) đã tận tình giúp đỡ chúng em trong thời gian qua để chúng em hoàn thành tốt bài báo cáo này. Đoàn thực tập chúng em cũng xin chân thành cảm ơn công ty cổ phần nhà máy Đường Nông Cống đã tạo điều kiện tốt nhất cho chúng em khi đoàn thực tập tại nhà máy. Do thời gian thực tập cũng như kiến thức thực tế không nhiều, bài báo cáo còn nhiều điểm chưa đề cập đến và còn những thiếu sót nhất định, em rất mong được sự góp ý của các Thầy, Cô giáo để bài báo cáo của chúng em được hoàn thiện hơn .Một lần nữa chúng em xin chân thành cảm ơn.   PHẦN I .MỞ ĐẦU Như chúng ta đã biết trong thời buổi nền kinh tế thị trường hiện nay trên thế giới Nền kinh tế thế giới hội nhập và phát triển theo xu thế toàn cầu hóa. Nó thúc đẩy nền kinh tế của nhiều nước trên thế giới phát triển tạo cơ hội thuận lợi cho nền kinh tế nhiều nước có cơ hội canh tranh và phát triển lớn mạnh. Không những thế nó còn giúp cho nền kinh tế và dân trí cùng với khoa học kỹ thuật của nhiều nước nghèo, một số nước đang phát triển trên thế giới có cơ hội hội nhập và phát triển trong đó có Việt Nam. Cùng với sự phát triển của đất nước Thanh Hoá là một tỉnh đông dân trong những năm gần đây nền kinh tế đang rất phát triển Qua 15 năm thu mua và chế biến kể từ năm 1999 đến nay Công ty cổ phần mía đường Thanh Hóa đã qua bao khó khăn có lúc tưởng chừng như không thể vượt qua. Tình hình thực tế Công ty đứng bên bờ vực phá sản nhưng rồi lại phát triển đi lên đem lại những thành quả tốt đẹp. Tất cả những thăng trầm ấy do nhiều nguyên nhân đem lại, xong suy cho cùng một trong số những nguyên nhân cơ bản quan trọng bậc nhất đó là vấn đề nguyên liệu cho nhà máy sản xuất. Đủ nguyên liệu nhà máy chạy hết công suất, khai thác được tiềm năng sẵn có của thiết bị, sản xuất kinh doanh có hiệu quả, giá thành hạ, đem lại lợi nhuận cao, nộp ngân sách Nhà nước tăng, công nhân có công ăn việc làm, đời sống ổn định và ngày càng được nâng cao, công nhân gắn bó với nhà máy. Thiếu nguyên liệu nhà máy hoạt động kém hiệu quả, lãng phí thiết bị máy móc, khấu hao trên đầu sản phẩm tăng, sản xuất bị thua lỗ, công nhân không có công ăn việc làm, đời sống ngày càng khó khăn. Từ những vấn đề trên trong những năm gần đây, đặc biệt là từ khi có chủ trương đường lối đổi mới của Đảng và các chính sách của Nhà nước về giao quyền tự chủ cho sản xuất kinh doanh cho các doanh nghiệp. Công ty cổ phần mía đường Thanh Hóa đã chủ động đầu tư giải quyết tốt vấn đề nguyên liệu cung cấp cho nhà máy sản xuất ổn định và phát triển. Hiện nay trong xu thế phát triển mở rộng sản xuất kinh doanh, Công ty cổ phần mía đường Thanh Hóa đã mở rộng nâng cao công suất nhà máy . Do đó việc xây dựng và phát triển vùng nguyên liệu đảm bảo đầy đủ cho nhà máy sản xuất ngày càng trở nên quan trọng và cấp bách hơn. Từ những vấn đề nêu trên, việc đặt ra những chương trình nghiên cứu về vùng nguyên liệu mía đường Thanh Hóa, thực trạng vùng nguyên liệu và quá trình hoạt động sản xuất kinh doanh của Công ty cổ phần mía đường Thanh Hóa trong những năm vừa qua và đề ra những giải pháp nhằm xây dựng, phát triển vùng nguyên liệu để cung cấp đầy đủ và ổn định cho nhà máy sản xuất là việc làm có ý thiết thực đối với sự tồn tại và phát triển của Công ty.Bên cạnh đó việc lựa chọn đúng về dây chuyền sản xuất cũng là yếu tố quyết định đến thành quả của nhà máy như hiện nay sau đây nhóm chúng em xin trình bày về quy trình và công nghệ sản xuất mía đường.  

BỘ CÔNG THƯƠNGTRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP HỒ CHÍ MINH

CƠ SỞ THANH HÓA

CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN

Nhóm Sinh Viên Thực HiệnLớp : DHTH5TH Khóa : 2009-2013

GV hướng dẫn : G.V Lê Thị Ánh Tuyết

Thanh Hóa, tháng 07 năm 2013

TRƯỜNG ĐH CÔNG NGHIỆP TP HCM

CƠ SỞ THANH HÓA

KHOA CÔNG NGHỆ

( NHIỆM VỤ ĐỒ ÁN CHUYÊN NGÀNH

-Họ và tên sinh viên: Lê Nam Phong MSSV: 09013053

Trần Văn Tuấn MSSV: 09013043Ngành: Công Nghệ Thông Tin Lớp: DHTH5TH

Tên đồ án chuyên ngành:

Nghiên cứu về kiểm thử và một công cụ kiểm thử tự động

Nhiệm vụ : Trình bày về khái niệm kiểm thử,các kiểu kiểm thử.Trình bày hiểu biết

về một công cụ kiểm thử và vận dụng vào một phần mềm bất kì

1 Ngày giao: ngày 23 tháng 04 năm 2013

2 Ngày hoàn thành: ngày08 tháng 07năm 2013

3 Họ tên giáo viên hướng dẫn: Lê Thị Ánh Tuyết

Thanh Hóa, ngày 08 tháng 07 năm 2013

TRƯỞNG BỘ MÔN GIÁO VIÊN HƯỚNG DẪN (Ký và ghi rõ họ tên)

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

(Giáo viên ghi nhận xét của mình, bằng tay, vào phần này)

………

………

………

………

………

Phần đánh giá:  Ý thức thực hiện: ………

………

 Nội dụng thực hiện: ………

………

 Hình thức trình bày: ………

………

 Tổng hợp kết quả: […] Được bảo vệ […] Được bảo vệ có chỉnh sửa bổ sung

[…] Không được bảo vệ

Thanh Hóa, ngày tháng năm 2013

GIÁO VIÊN HƯỚNG DẪN

(Ghi rõ họ, tên)

NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN

(Giáo viên ghi nhận xét của mình, bằng tay, vào phần này)

………

………

………

………

………

Phần đánh giá:  Ý thức thực hiện: ………

………

 Nội dụng thực hiện: ………

………

 Hình thức trình bày: ………

………

 Tổng hợp kết quả: […] Được bảo vệ […] Được bảo vệ có chỉnh sửa bổ sung

[…] Không được bảo vệ

Thanh Hóa, ngày tháng năm 2013

GIÁO VIÊN HƯỚNG DẪN

(Ghi rõ họ, tên)

LỜI CẢM ƠN

Với sự xuất hiện của mạng internet toàn cầu và việc tăng cường các ứng dụng công nghệ thông tin trong mọi lĩnh vực kinh tế-xã hội, nhiều phần mềm ra đời đòi hỏi cần

kiểm soát chặt chẽ chất lượng của chúng Vì vậy nhóm em đã chọn đề tài:”Nghiên cứu

về kiểm thử và một công cụ kiểm thử tự động” làm đề tài nghiên cứu của nhóm trong

đồ án học phần 2 Để tự động hóa khâu kiểm thử chất lượng phần mềm nhiều công cụ

hỗ trợ đã được viết ra như CSunit,Jfunc,NUnit… Trong đồ án này chúng em sẽ đi sâu vào nghiên cứu công cụ kiểm thử NUnit.

Trong quá trình thực hiện nghiên cứu đề tài, chúng em nhận được sự hướng

dẫn tận tình của cô giáo Lê Thị Ánh Tuyêt – giáo viên trực tiếp hướng dẫn

Chúng em hy vọng sẽ nhận được sự góp ý của các thầy cô và các bạn để chúng

em có thể hoàn thành tốt đề tài này Những đóng góp của mọi người sẽ là nhữngkinh nghiệm quý báu giúp em và các bạn trong nhóm có những dự định sau nàytrong khi làm đồ án tiếp theo

Một lần nữa em xin chân thành cảm ơn cô giáo Lê Thị Ánh Tuyêt đã hướng dẫn

em và các bạn hoàn thành đề tài nghiên cứu.

Em xin chân thành cảm ơn!

DANH MỤC HÌNH

µµHình 1.1: Sơ đồ các cấp độ kiểm thử µ7§§ µHình 1.2: Mô hình chữ V µ13§§ µHình 3.1 : Hướng dẫn cài đặt Nunit µ29§§ µHình 3.2 : Hướng dẫn cài đặt Nunit µ30§§ µHình 3.3 : Hướng dẫn cài đặt Nunit µ30§§ µHình 3.4 : Hướng dẫn cài đặt Nunit µ31§§ µHình 3.6 : Hướng dẫn cài đặt Nunit µ31§§ µHình 3.7: Hướng dẫn tạo test case trong visual 2010 µ32§§ µHình 3.8: Hướng dẫn tạo test case trong visual 2010 µ33§§ µHình 3.9: Hướng dẫn tạo test case trong visual 2010 µ34§§ µHình 3.10: Hướng dẫn tạo test case trong visual 2010 µ34§§ µHình 3.11: Hướng dẫn tạo test case trong visual 2010 µ35§§ µHình 3.12: Giao diện NUnit µ37§§ µHình 3.13: Open Project µ37§§ µHình 3.14: Gao diện Nunit µ38§§ µHình 3.15: Kết quả kiểm thử đúng µ38§§ µHình 3.16: Kết quả kiểm thử sai µ39§§ µHình 4.1: Giao diện chương trình kiểm tra tam giác µ43§§ µHình 6.1: Kết quả test tam giác là đúng µ55§§ µHình 6.2: Kết quả test là đúng µ56§§ µHình 6.3: Kết quả test là sai µ56§§ µHình 6.4: Kết quả test là đúng µ57§§

µHình 6.5: Kết quả test là đúng µ57§§

MỤC LỤC

µµLỜI NÓI ĐẦU µ1§§ µPHẦN I: TỔNG QUAN µ2§§ µPHẦN II: NỘI DUNG NGHIÊN CỨU VÀ KẾT QUẢ µ3§§ µCHƯƠNG 1: KHÁI QUÁT KIỂM THỬ PHẦN MỀM µ3§§

µ1.1 CÁC KHÁI NIỆM CƠ BẢN TRONG KIỂM THỬ PHẦN MỀM.µ3§§ µ1.1.1 Khái niệm về kiểm thử phần mềm µ3§§ µ1.1.2 Mục đích của kiểm thử phần mềm µ3§§ µ1.1.3 Các phương pháp kiểm thử µ4§§ µ1.1.4 Các chiến lược kiểm thử µ4§§

µ1.1.4.1 Kiểm thử hộp đen – Black box µ4§§µ1.1.4.2 Kiểm thử hộp trắng – White box µ6§§µ1.1.4.3 Kiểm thử hộp xám – Gray box testing µ6§§

µ1.1.5 Các cấp độ kiểm thử trong kiểm thử phần mềm µ7§§

µ1.1.5.1 Kiểm thử đơn vị - Unit test µ7§§µ1.1.5.2 Kiểm thử tích hợp – Intergration test µ8§§µ1.1.5.3 Kiểm thử hệ thống – System test µ10§§µ1.1.5.4 Kiểm thử chấp nhận – Acceptance test µ11§§µ1.1.5.5 Mô hình chữ V trong kiểm thử phần mềm µ13§§

µ1.1.6 Một số cấp độ kiểm thử khác µ14§§ µ1.2 NGUYÊN TẮC TRONG KIỂM THỬ PHẦN MỀM µ15§§

µCHƯƠNG 2:UNIT TESTING µ16§§

µ2.1 µ16§§ µTỔNG QUAN VỀ UNIT TEST µ16§§ µ2.1.1 Định nghĩa về Unit testing µ16§§ µ2.1.2 Mục đích µ16§§ µ2.1.3 Yêu cầu µ17§§

µ2.1.4 Người thực hiện Unit test µ17§§ µ2.1.5 Vòng đời của một Unit test µ17§§ µ2.1.6 Lợi ích của Unit test µ17§§ µ2.1.7 Tác dụng của Unit test µ18§§ µ2.1.8 Chiến lược viết mã hiệu quả với Unit test µ18§§ µ2.2 SỬ DỤNG UNIT TEST VỚI MÔ HÌNH ĐỐI TƯỢNG ẢO (MOCK OBJECT) µ19§§ µ2.2.1 Định nghĩa µ20§§ µ2.2.2 Đặc điểm µ20§§ µ2.2.3 Lợi ích µ20§§ µ2.2.4 Phạm vi sử dụng µ20§§ µ2.2.5 Các đối tượng được mô phỏng µ21§§ µ2.2.6 Thiết kế MO µ22§§

µCHƯƠNG 3: TÌM HIỂU VỀ NUNIT µ23§§

µ3.1 CÁC CÔNG CỤ KIỂM THỬ CỦA TỪNG NGÔN NGỮ KIỂM THỬ µ23§§ µ3.1.1 Junit và J2ME Unit trong Java µ23§§ µ3.1.2 Cpp Unit trong C/C++ µ24§§ µ3.1.3 Vb Unit trong Visual Basic µ25§§ µ3.2 NUNIT TRONG C# µ25§§ µ3.2.1 Định nghĩa µ25§§ µ3.2.2 Đặc điểm của NUnit µ25§§ µ3.2.3 Thuộc tính hay dùng trong thư viện Nunit.Framework µ26§§ µ3.2.4 Phương thức tĩnh hay dùng trong Nunit.Framework.Assertµ28§§ µ3.2.5 Cài đặt Nunit µ29§§ µ3.2.6 Cách sử dụng Nunit µ32§§

µ3.2.6.1 Hướng dẫn tạo test case trong Visual studio 2010 µ32§§

µ3.2.6.2 Sử dụng Nunit µ37§§

µCHƯƠNG 4: TỔNG QUAN CHƯƠNG TRÌNH KIỂM THỬ µ41§§

µ4.1 MÔ TẢ BÀI TOÁN µ41§§ µ4.1.1 Mục đích µ41§§ µ4.1.2 Phạm vi µ41§§ µ4.2 MÔ TẢ CHƯƠNG TRÌNH µ41§§ µ4 2.1 Tổng quan chương trình µ41§§ µ4 2.2 Các hệ thống liên quan µ41§§ µ4.3 CÁC YÊU CẦU CHUNG µ41§§ µ4 3.1 Yêu cầu về kiến trúc chương trình µ41§§ µ4.3.2 Các yêu cầu về thẩm mỹ µ42§§ µ4.3.3 Các yêu cầu về sử dụng µ42§§ µ4.4 CHƯƠNG TRÌNH µ42§§ µ4.4.1 Giao diện chương trình µ42§§ µ4.4.2 Mô tả các đối tượng µ43§§ µ4.4.3 Mã code của chương trình µ43§§

µ4.4.3.1 Mã code của giao diện µ43§§µ4.4.3.2 Mã Code của lớp kiểm tra tam giác µ46§§

µCHƯƠNG 5 : THIẾT KẾ KIỂM THỬ µ49§§

µ5.1 Kiểm thử hộp đen µ49§§ µ5.1.1 Yêu cầu giao diện µ49§§ µ5.1.2 Mô tả các tình huống test µ50§§ µ5.2 KIỂM THỬ HỘP TRẮNG µ50§§

µCHƯƠNG 6: TIẾN HÀNH KIỂM THỬ µ52§§

µ6.1 KIỂM THỬ HỘP ĐEN µ52§§ µ6.1.1 Kết quả kiểm thử giao diện µ52§§ µ6.1.2 Kết quả kiểm thử chức năng µ53§§

µ6.2 KIỂM THỬ HỘP TRẮNG µ53§§

µPHẦN III: KẾT LUẬN µ58§§

µTÀI LIỆU THAM KHẢO µ59§§

LỜI NÓI ĐẦU

Với sự xuất hiện của mạng internet toàn cầu và việc tăng cường các ứngdụng công nghệ thông tin trong mọi lĩnh vực kinh tế-xã hội, nhiều phần mềm rađời đòi hỏi cần kiểm soát chặt chẽ chất lượng của chúng Vì vậy nhóm em đã

chọn đề tài:”Nghiên cứu về kiểm thử và một công cụ kiểm thử tự động” làm đề

tài nghiên cứu của nhóm trong đồ án học phần 2 Để tự động hóa khâu kiểm thửchất lượng phần mềm nhiều công cụ hỗ trợ đã được viết ra nhưCSunit,Jfunc,NUnit… Trong đồ án này chúng em sẽ đi sâu vào nghiên cứu công

cụ kiểm thử NUnit

Trên cơ sở nghiên cứu các tư liệu và kết quả thực nghiệm cho thấy kiểm thửphần mềm là rất quan trọng, việc thực hiện kiểm thử tốt sẽ làm tăng chất lượngcủa sản phẩm Tuy nhiên, để vận dụng và thực hiện một cách hiệu quả các quitrình, phương pháp và công cụ kiểm thử thì vẫn còn nhiều vấn đề đặt ra cần tiếptục giải quyết Có thể đề xuất những hướng nghiên cứu và triển khai tiếp theo của

PHẦN I: TỔNG QUAN

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới

những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khíacạnh nào đó của hệ thống hay thành phần đó

Mục đích của kiểm thử phần mềm

Tìm ra nhiều lỗi bằng việc đưa ra các dòng thời gian

Chứng minh được sản phẩm hoàn thành có những chức năng hay ứng dụnggiống với bản đặc tả yêu cầu

Tạo ra các test case có chất lượng cao, thực thi hiệu quả…

Một số lỗi cơ bản trong kiểm thử phần mềm như: lỗi ngay từ khi phân tíchyêu cầu, lỗi từ bản đặc tả hệ thống, lỗi trong code, lỗi hệ thống và nguồn tàinguyên hệ thống, lỗi trong vấn đề phần mềm, phần cứng…

PHẦN II: NỘI DUNG NGHIÊN CỨU VÀ KẾT QUẢ

CHƯƠNG 1: KHÁI QUÁT KIỂM THỬ PHẦN MỀM

1.1 CÁC KHÁI NIỆM CƠ BẢN TRONG KIỂM THỬ PHẦN MỀM.

1.1.1 Khái niệm về kiểm thử phần mềm.

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới

những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khíacạnh nào đó của hệ thống hay thành phần đó (Theo Bảng chú giải thuật ngữchuẩn IEEE của Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary ofSoftware Engineering Terminology)

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ

phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cungcấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩmhay dịch vụ phần mềm ấy Mục đích của kiểm thử phần mềm là tìm ra các lỗi haykhiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm

trong nhiều ngành khác nhau (Theo Bách khoa toàn thư mở Wikipedia).

Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một

tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máytính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất

cứ thứ gì không mong muốn Đây là một pha quan trọng trong quá trình phát triển

hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thốngmới đã đáp ứng yêu cầu đặt ra hay chưa

1.1.2 Mục đích của kiểm thử phần mềm.

Tìm ra nhiều lỗi bằng việc đưa ra các dòng thời gian

Chứng minh được sản phẩm hoàn thành có những chức năng hay ứng dụnggiống với bản đặc tả yêu cầu

Tạo ra các test case có chất lượng cao, thực thi hiệu quả…

Một số lỗi cơ bản trong kiểm thử phần mềm như: lỗi ngay từ khi phân tíchyêu cầu, lỗi từ bản đặc tả hệ thống, lỗi trong code, lỗi hệ thống và nguồn tàinguyên hệ thống, lỗi trong vấn đề phần mềm, phần cứng…

1.1.3 Các phương pháp kiểm thử.

Kiểm thử tĩnh( Static testing): Là phương pháp thử phần mềm đòi hỏi phải

duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút đểkiểm tra logic, lần từng chi tiết mà không cần chạy chương trình Kiểu kiểm thửnày thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh mộtmình

Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn

bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biêndịch mà xác nhận tính hợp lệ về cú pháp của chương trình

Kiểm thử động(Dynamic testing): Là phương pháp kiểm thử thông qua việc

dùng máy chạy chương trình để điều tra trạng thái tác động của chương trình Đó

là kiểm thử dựa trê các ca kiểm thử xác định bằng sự thực hiện của đối tượngkiểm thử hay chạy các chương trình Kiểm thử động là kiểm tra cách thức hoạtđộng của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luônthay đổi theo thời gian Trong kiểm thử động, phần mềm phải thực sự được biêndịch và chạy Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập cácgiá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không

Các phương pháp kiểm thử động gồm có kiểm thử mức đơn vị – Unit Tests,kiểm thử tích hợp – Intergration Tests, kiểm thử hệ thống – System Tests, và kiểmthử chấp nhận sản phẩm – Acceptance Tests

1.1.4 Các chiến lược kiểm thử.

Trong chiến lược kiểm thử, chúng ta có ba chiến lược kiểm thử hay dùngnhất là: kiểm thử hộp đen, kiểm thử hộp trắng, và kiểm thử hộp xám

1.1.4.1 Kiểm thử hộp đen – Black box.

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen,hướng dữ liệu, hay hướng vào ra Kiểm thử hộp đen xem chương trình như là một

“hộp đen” Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấutrúc bên trong của chương trình Thay vào đó, tập trung vào tìm cac trường hợp

mà chương trình không thực hiện theo các đặc tả của nó

Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy từ các đặc tả

Các phương pháp kiểm thử hộp đen

Phân lớp tương đương – Equivalence partitioning.

Phân tích giá trị biên – Boundary values analysis.

Kiểm thử mọi cặp – All pairs testing.

Kiểm thử dựa trên mô hinh – Model based testing.

Kiểm thử thăm dò – Exploratory testing

Kiểm thử dựa trên đặc tả - Specification base testing.

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phầnmềm theo những yêu cầu thích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉthấy dữ liệu ra từ đối tượng kiểm thử Mức kiểm thử này thường xuyên yêu cầucác ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xácminh là đối với dữ liệu đầu vào đã cho giá trị đầu ra(hay cách thức hoạt động) cógiống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không.Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để ngăn chặn những rủi rochắc chắn

Ưu, nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh và kiểm thử viênchỉ rất đơn giản tam niệm là: một mã lệnh phải có lỗi Sử dụng nguyên tắc “Hãyđòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lõi mà nhữnglập trình viên không tìm ra Nhưng, người ta nói kiểm thử hộp đen “giống như là

đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phầnmềm được kiểm tra thực sự được xây dựng như thế nào Đó là lý do mà có nhiềutrường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tramột thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, vàhoặc một số phần của chương trình không được kiểm tra chút nào.

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”,mặt khác nó lại có nhược điểm của “thăm dò mù”

1.1.4.2 Kiểm thử hộp trắng – White box.

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộpđen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúcbên trong của chương trình Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sựkiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữliệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng)

Các phương pháp kiểm thử hộp trắng.

Kiểm thử giao diện lậ trình ứng dụng – API testing(applicationprogramming interface): là phương pháp kiểm thử của ứng dụng sử dụng các APIcông khai và riêng tư

Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiểuchuẩn về bao phủ mã lệnh

Các phương pháp gán lỗi – Fault injection

Các phương pháp kiểm thử hoán chuyển – Mutation testing methods

Kiểm thử tĩnh - Static testing: kiểm thử hợp trắng bao gồm mọi kiểm thửtĩnh

Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sựhoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thửhộp đen Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ

thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọngnhất đã được kiểm tra.

1.1.4.3 Kiểm thử hộp xám – Gray box testing

Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giảithuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ởmức người sử dụng hay mức hộp đen Việc thao tác tới dữ liệu đầu vào và định

dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống

được kiểm tra Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp– Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kếkhác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử Kiểm thử hộp xám

có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên haythông báo lỗi

1.1.5 Các cấp độ kiểm thử trong kiểm thử phần mềm.

Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích

hợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm.

Hình 1.1: Sơ đồ các cấp độ kiểm thử.

1.1.5.1 Kiểm thử đơn vị - Unit test.

và phân tích kết quả kiểm thử Nếu phát hiện lỗi, việc xác định nguyên nhân vàkhắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unitđang kiểm tra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽđược đền bù bằng việc tiết kiệm rất nhiều thời gian, chi phí cho việc kiểm thử vàsửa lỗi ở các mức kiểm thử sau đó.

Unit Test thường do lập trình viên thực hiện Công đoạn này cần được thựchiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triểnphần mềm Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết

kế và code của chương trình

b Mục đích.

Đảm bảo thông tin được xử lý và xuất ra là chính xác

Trong mối tương quan với dữ liệu nhập và chứa năng của Unit

Đòi hỏi tất cả các nhánh bên trong phải được kiểm tra phát hiện nhánh sinhlỗi (nhánh đó thường là câu lệnh được thực thi trong một Unit) Ví dụ: chuỗi saucâu lệnh if … then …else là một nhánh, đòi hỏi có kỹ thuật, đôi khi dùng thuậttoán để chọn lựa

Phát hiện ra các vấn đề tiềm ẩn hoặc các lỗi ký thuật

c Yêu cầu.

Muốn làm được Unit testing thì phải chuẩn bị trước các ca kiểm thử (Test case) hoặc các kịch bản kiểm thử (Test Script) trong đó phải ghi rõ dữ liệu nhập

vào, các bước thực hiện và dữ liệu mong chờ đầu ra của từng testcase

Các testcase hay script phải được giữ lại để tái sử dung

1.1.5.2 Kiểm thử tích hợp – Intergration test.

Integration test là kết hợp các thành phần của một ứng dụng và kiểm thử nhưmột ứng dụng đã hoàn thành Trong khi Unit Test kiểm tra các thành phần và Unitriêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếpgiữa chúng

Hai mục tiêu chính của Integration Test:

Phát hiện lỗi giao tiếp giữa các Unit

Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng

là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chứcnăng và cấu trúc nội tại của Unit Có một số phép kiểm thử đơn giản trên giao tiếpgiữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quanđến Unit chỉ thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khithực hiện Integration Test

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đãđược kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đãđược sửa chữa Một số người hiểu sai rằng Unit một khi đã qua giai đoạn UnitTest với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa.Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit.Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tíchhợp trước đó và đã hoàn tất các đợt Integration Test trước đó Lúc này, ta chỉ cầnkiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước

đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽgiảm đáng kể

Có 4 loại kiểm thử trong Integration Test:

Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thử

cấu trúc nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng

và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trìnhchẳng hạn các câu lệnh và nhánh bên trong

Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm

thử chức năng chỉ chú trọng đến chức năng của chương trình, mà không quan tâmđến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹthuật.

Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ

thống

Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ

thống

1.1.5.3 Kiểm thử hệ thống – System test.

Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tíchhợp) có thỏa mãn yêu cầu đặt ra hay không

System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợpthành công Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian.Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềmhoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân

bố, hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm cáclỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầukhác liên quan đến chất lượng của toàn hệ thống

Điểm khác nhau then chốt giữa Integration Test và System Test là SystemTest chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chútrọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau.Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọiUnit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện SystemTest

Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hìnhthành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lậptrình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn

chỉnh Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành vàphân tích các yêu cầu

System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêucầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phầnmềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặcchiếm dụng bộ nhớ Sau giai đoạn System Test, phần mềm thường đã sẵn sàngcho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm

(Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, SystemTest thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập vớinhóm phát triển dự án Bản thân System Test lại gồm nhiều loại kiểm thử khácnhau, phổ biến nhất gồm:

Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống

thỏa mãn đúng yêu cầu thiết kế

Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổ tài

nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đápứng câu truy vấn

Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống

vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc) Stress Testtập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thườngnhư đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị nhưPOS, ATM )

Kiểm thử cấu hình (Configuration Test).

Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ

liệu và của hệ thống

Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả

năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc

dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trựctuyến

Kết luận: Không nhất thiết phải thực hiện tất cả các kiểm thử trên mà phụ

thuộc vào yêu cầu hệ thống, tùy vào khả năng và thời gian của dự án, khi lập kếhoạch thì người quản lý sẽ quy định kiểm thử theo những loại nào

1.1.5.4 Kiểm thử chấp nhận – Acceptance test.

Thông thường, sau giai đoạn System Test là Acceptance Test, được kháchhàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện) Mục đích củaAcceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của kháchhàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng)

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọitrường hợp, các phép kiểm thử của System Test và Acceptance Test gần nhưtương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người

sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha –

Alpha Test và kiểm thử Beta – Beta Test Với Alpha Test, người dùng kiểm thử

phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗihoặc phản hồi, và lên kế hoạch sửa chữa Với Beta Test, phần mềm sẽ được gửitới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồicũng sẽ gửi ngược lại cho lập trình viên để sửa chữa

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vàoquá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc

dù phần mềm đã trải qua tất cả các kiểm thử trước đó Sự sai lệch này liên quanđến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng Ví dụ đôi khimột phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởinhóm thực hiện dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì

bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sửdụng của khách hàng v.v

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ

và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v Tất cả tài liệu đikèm phải được cập nhật và kiểm thử chặt chẽ

1.1.5.5 Mô hình chữ V trong kiểm thử phần mềm

Hình 1.2: Mô hình chữ V

Các bước tiến hành của mô hình chữ V

Sau khi đã có yêu cầu của khách hàng ta thực hiện đồng thời việc thiết kế hệthống và bản kiểm thử cho người dùng (user acceptance testing) dựa trên các yêucầu đó

Khi hoàn thành được bản thiết kế hệ thống, ta vừa thực hiện bảng kiểm thử

hệ thống (system testing) và vừa làm thiết kế kiến trúc phần mềm

Sau khi có được thiết kế kiến trúc ta chuyển sang thiết kế các module Từcác thiết kế module ta vừa làm bản thiết kế các unit test đồng thời bắt đầu coding

Sau giai đoạn coding thì các công đoạn sau bao gồm unit test, integration test, system test và acceptance testing được thực hiện lần lượt dựa trên các thiết kế

đã thực hiện sẵn trước đó trong giai đoạn phát triển phần mềm ban đầu

Ưu điểm trong mô hình chữ V

Có thể làm 1 số việc song song Ví dụ : Nếu làm yêu cầu đúng thì có thể làmsong song với việc thiết kế test

Đạt được phần mềm chất lượng, các pha tương thích với nhau, hỗ trợ chonhau

Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạtđộng liên quan đến đặc tả yêu cầu và thiết kế Hay nói cách khác, mô hình nàykhuyến khích các hoạt động liên quan đến kế hoạch kiểm thử được tiến hành sớmtrong chu kỳ phát triển, không phải đợi đến lúc kết thúc giai đoạn hiện thực

Nhược điểm trong mô hình chữ V

Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự

án

Pha sau thực chỉ được thực hiện khi pha trước kết thúc, không thể quay

ngược trở lại pha trước.

Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giaiđoạn trung gian từ thiết kế cho đến kiểm thử

1.1.6 Một số cấp độ kiểm thử khác.

Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác như:

Kiểm thử hồi quy – Regression Testing:

Theo chuẩn IEEE610.12-90, kiểm thử hồi quy là “sự kiểm tra lại có lựa chọncủa một hệ thống hay thành phần để xác minh là những sự thay đổi không gây ranhững hậu quả không mong muốn…” Trên thực tế, quan niệm này là chỉ ra rằngphần mềm mà đã qua được các kiểm tra trước đó vẫn có thể được kiểm tra lại.Beizer định nghĩa đó là sự lặp lại các kiểm tra để chỉ ra rằng cách hoạt động củaphần mềm không bị thay đổi, ngoại trừ tới mức như yêu cầu Hiển nhiên là sựthỏa hiệp phải được thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quymỗi lần thực hiện một sự thay đổi và những tài nguyên được yêu cầu thực hiệnđiều đó

Kiểm thử tính đúng – Correctness testing:

Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu củakiểm thử Kiểm thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ racách hoạt động đúng đắn từ cách hoạt động sai lầm Kiểm thử viên có thể biếthoặc không biết các chi tiết bên trong của các modun phần mềm được kiểm thử,

ví dụ luồng điều khiển, luông dữ liệu,… Do đó, hoặc là quan điểm hộp trắng,hoặc là quan điểm hộp đen có thể được thực hiện trong kiểm thử phần mềm

1.2 NGUYÊN TẮC TRONG KIỂM THỬ PHẦN MỀM.

Để kiểm thử đạt hiệu quả thì khi tiến hành kiểm thử phần mềm cần phải tuânthủ một số quy tắc sau:

Quy tắc 1: Một phần quan trọng của 1 ca kiểm thử là định nghĩa của đầu ra

hay kết quả mong muốn

Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình.

Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra

Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không

hợp lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn

Quy tắc 6: Khảo sát 1 chương trình để xem liệu chương trình có thực hiện

cái mà nó cần thực hiện chỉ là 1 phần, phần còn lại là xem liệu chương trình cóthực hiện cái mà nó không cần phải thực hiện hay không

Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là 1

chương trình bâng quơ

Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không

tìm thấy lỗi

Quy tắc 9: Xác suất tồn tại lỗi trong 1 đoạn chương trình là tương ứng với số

lỗi đã tìm thấy trong đoạn đó

Quy tắc 10: Kiểm thử là 1 nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí

tuệ

CHƯƠNG 2:UNIT TESTING

2.1

TỔNG QUAN VỀ UNIT TEST

2.1.1 Định nghĩa về Unit testing.

Một Unit là một thành phần nhỏ nhất mà ta có thể kiểm tra được Vì vậy, các

hàm(function), thủ tục (Proceduce), các lớp (Class) hoặc các phương thức (Method) đều có thể coi là một Unit Vì Unit được chọn để kiểm thử thường có

kích thước nhỏ và đơn giản

Kiểm thử đơn vị sẽ được thực hiện đối với một hệ thống được kiểmthử(SUT)

SUT( System Under Test) là hệ thống được kiểm thử và một số người thích

sử dụng CUT (class under test – lớp theo kiểm thử; code under test – mã theokiểm thử) Khi kiểm thử một cái gì đó thì có thể sử dụng một cái như SUT

Đặc điểm của một Unit test: đóng vai trò như người sử dụng đầu tiên của hệthống Chỉ có giá trị khi chúng có thể phát hiện các vấn đề tiềm ẩn hay lỗi kỹthuật

Ứng dụng của Unit test: kiểm tra được tất cả các hàm, thủ tục, sự kiện,thuộc tính; kiểm tra các trạng thái và ràng buộc của đối tượng ở mức sâu hơn, nơi

mà không thể truy cập được; kiểm tra được các quá trình và các khung làmviệc(work flow)

2.1.2 Mục đích

Đảm bảo thông tin xử lý và xuất ra là chính xác

Trong mối tương quan với dữ liệu nhập và chức năng của một Unit

Đòi hỏi tất cả các nhánh bên trong phải được kiểm tra phát hiện nhánh sinhlỗi(nhánh đó thường là câu lệnh để thực thi trong một Unit) Ví dụ: Chuỗi câulệnh If …then …else là một nhánh Đòi hỏi có kỹ thuật, đôi khi dùng thuật toán

Các Test case, Test script được giữ lại để tái sử dung

2.1.4 Người thực hiện Unit test.

Khi thực hiện kiểm thử mức đơn vị thì công đoạn này là do người lập trình

viên (Deverloper) hay kỹ sư kiểm thử(Test Enginieer) Vì khi xây dựng được một

test case để có thể tìm ra được lỗi là nhiều nhất thì người thực hiện phải biết vềngôn ngữ lập trình, có khả năng đọc và hiểu các đoạn code

2.1.5 Vòng đời của một Unit test.

Có ba trạng thái cơ bản:

Trạng thái lỗi (Fail status)

Trạng thái tạm ngừng thực hiện (Ignore status)

Trạng thái làm việc(Pass Status)

Chú ý: Mỗi trạng thái của Unit test được thể hiện bằng một màu khác nhau:

Fail: màu đỏ

Ignore: màu vàng

Pass: màu xanh

Như vậy: Unit test chỉ thực sự mang lại hiệu quả khi:

Được vận hành nhiều lần

Tự động hoàn toàn

Độc lập với các Unit khác

2.1.6 Lợi ích của Unit test.

Tạo ra môi trường lý tưởng để kiểm tra bất cứ đoạn mã nào, có khả năngthăm dò và phát hiện lỗi chính xác, duy trì sự ổn định của toàn bộ phần mềm vàgiúp tiết kiệm thời gian so với công việc gỡ rối truyền thống

Phát hiện thuật toán thực thi không hiệu quả, các thủ tục chạy vượt quá giớihạn thời gian

Phát hiện các vấn đề thiết kế, xử lý hệ thống, các mô hình thiết kế

Tạo hàng rào an toàn cho các khối mã Bất cứ sự thay đổi nào cũng có thểtác động tới hàng rào này và thông báo những nguy hiểm tiềm tàng

Phát hiện lỗi nghiêm trọng có thể xảy ra trong những tình huống hẹp

Như vậy: Unit test là một môi trường lý tưởng để tiếp cận API bên ngoài

một cách tốt nhất Sẽ rất nguy hiểm nếu chúng ta ứng dụng ngay các thư viện này

mà không kiểm tra kỹ lưỡng công dụng của các thủ tục trong thư viện Dành thờigian viết các Unit test kiểm tra từng thủ tục là phương pháp tốt nhất khẳng định sựhiểu đúng đắn về cách sử dụng thư viện đó Ngoài ra, Unit test cũng được sử dụng

để phát hiện sự khác biệt giữa phiên bản mới và phiên bản cũ của cùng một thưviện

2.1.7 Tác dụng của Unit test.

Giải phóng chuyên viên QA (Quality Assurance) khỏi các công việc phức

tạp

Tăng sự tự tin khi hoàn thành một công việc Chúng ta thường có cảm giáckhông chắc chắn về các đoạn mã của mình như liệu các lỗi có quay lại không,hoạt động của module hiện hành có bị tác động không hoặc liệu công việc hiệuchỉnh mã có gây hư hỏng không…

Là công cụ để đánh giá năng lực của bạn Số lượng các tình huống kiểm

tra(test case) chuyển trạng thái “pass” sẽ thể hiện tốc độ làm việc, năng suất của

bạn

2.1.8 Chiến lược viết mã hiệu quả với Unit test.

Phân tích các tình huống có thể xảy ra đối với mã Đừng bỏ qua các tìnhhuống tồi tệ nhất có thể xảy ra, thí dụ dữ liệu nhập làm một kết nối cơ sở dữ liệuthất bại, ứng dụng bị treo vì một phép toán chia cho không, các thủ tục đưa ra lỗingoại lệ sai có thể phá hỏng ứng dụng một cách bí ẩn…

Mọi Unit test phải bắt đầu với trạng thái “fail” và chuyển trạng thái “pass”sau một số thay đổi hợp lý đối với mã chính

Mỗi khi viết một đoạn mã quan trọng, hãy viết các Unit test tương ứng chođến khi bạn không thể nghĩ thêm tình huống nào nữa

Nhập số lượng đủ lớn các giá trị đầu vào để phát hiện các điểm sau:

Nhập giá trị hợp lệ (kết quả trả về cũng hợp lệ

Nhập giá trị không hợp lệ ( kết quả trả về cũng không hợp lệ.

Sớm nhận biết các đoạn mã không ổn định và có nguy cơ gây lỗi cao, viếtUnit test tương ứng để khống chế

Ứng với mỗi đối tượng nghiệp vụ (business object) hoặc đối tượng truy cập

dữ liệu (data access object), nên tạo ra một lớp kiểm tra riêng vì những lỗi nghiêmtrọng có thể phát sinh từ các đối tượng này

-Để ngăn chặn các lỗi có thể phát sinh trở lại thực thi tự động tất cả Unit testmỗi khi có một sự thay đổi quan trọng, hãy làm công việc này mỗi ngày Các Unittest lỗi cho chúng ta biết thay đổi nào là nguyên nhân gây lỗi

Để tăng hiệu quả và giảm rủi ro khi viết các Unit test, cần sử dụng nhiềuphương thức kiểm tra khác nhau Hãy viết càng đơn giản càng tốt

Cuối cùng, viết Unit test cũng đòi hỏi sự nỗ lực, kinh nghiệm và sự sáng tạonhư viết phần mềm

Unit test chỉ thực sự mang lại lợi ích nếu chúng ta đặt vấn đề chất lượng phần mềm lên hàng đầu hơn là chỉ nhằm kết thúc công việc đúng thời hạn

2.2 SỬ DỤNG UNIT TEST VỚI MÔ HÌNH ĐỐI TƯỢNG ẢO (MOCK OBJECT)

Trong Unit Test, mỗi một đối tượng hay một phương thức riêng lẻ đượckiểm tra tại một thời điểm và chúng ta chỉ quan tâm đến các trách nhiệm củachúng có được thực hiện đúng hay không Tuy nhiên trong các dự án phần mềmphức tạp thì Unit Test không còn là quy trình riêng lẻ, nhiều đối tượng (đơn vịchương trình) không làm việc độc lập mà tương tác với các đối tượng khác nhưkết nối mạng, cơ sở dữ liệu hay dịch vụ web Như vậy công việc kiểm nghiệm cóthể bị trì hoãn gây tác động xấu đến quy trình phát triển chung Để giải quyết cácvấn đề này người ta đưa ra mô hình “Mock Object” hay đối tượng ảo (hoặc đốitượng giả)

2.2.1 Định nghĩa