Đảm bảo và kiểm soát chất lượng - Chương 3: Các kỹ thuật cơ bản về kiểm soát chất lượng phần mềm

ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG HCM – 10/2012 Chương 3: Các kỹ thuật cơ bản về kiểm soát chất lượng phần mềm 1 3/26/2015 Nội dung Các pha trong qui trình Những mô hình phát triển phần mềm  Mô hình tháp nước  Mô hình chữ V  Mô hình phát triển lặp gia tăng Các mức kiểm thử Triết lý của việc Testing Những định nghĩa cơ bản 3/26/2015 Trang 2 Quy trình phát triển phần mềm 3/26/2015 Trang 3 Phần mềm Yêu cầu phần mềm Lập trình Thiết kế Lập trình Phân tích Thiết kế Lập trình Phân tích Thiết kế Lập trình Kiểm tra 1 2 3 4 Các pha trong qui trình Pha của qui trình là gì?  Chuỗi hoạt động liên quan Mỗi pha định nghĩa  WHAT? (Làm gì)  WHO? (Ai tham gia)  INPUT? (Đầu vào)  OUTPUT? (Đầu ra) 3/26/2015 Trang 4 Các pha trong qui trình Các pha chính yếu trong một qui trình phần mềm:  Phân tích yêu cầu  Thiết kế phần mềm  Lập trình  Kiểm nghiệm phần mềm  Triển khai và bảo trì 3/26/2015 Trang 5 Các pha trong qui trình Phân tích yêu cầu Phân tích yêu cầu:  Trả lời câu hỏi “Làm những gì?”  Xác định có những gì cần làm: • Thu thập yêu cầu khách hàng • Đặc tả yêu cầu • Kiểm nghiệm yêu cầu • Mô hình hóa phần mềm  Đầu vào: • Yêu cầu người dùng  Sản phẩm: • Tài liệu đặc tả yêu cầu 3/26/2015 Trang 6 Các pha trong qui trình Phân tích yêu cầu Yêu cầu chức năng:  Lưu trữ những thông tin gì ?  Xử lý tính toán theo công thức nào ? Yêu cầu phi chức năng:  Cài đặt trên môi trường nào ? Windows ? Web ?  Sử dụng hệ quản trị cơ sở dữ liệu nào ? Access/SQLServer/Oracle/DB2  Sử dụng công nghệ gì ? Java/.NET/Delphi/PHP/ 3/26/2015 Trang 7 Các pha trong qui trình Thiết kế phần mềm Thiết kế phần mềm:  Trả lời câu hỏi “Làm như thế nào?”  Với những gì cần làm, xác định làm như thế nào: • Thiết kế kiến trúc • Thiết kế dữ liệu • Thiết kế giao diện • Thiết kế xử lý  Đầu vào: • Tài liệu đặc tả yêu cầu  Sản phẩm: • Tài liệu thiết kế 3/26/2015 Trang 8 Các pha trong qui trình Thiết kế phần mềm 3/26/2015 Trang 9 Các pha trong qui trình Thiết kế phần mềm 3/26/2015 Trang 10 Các pha trong qui trình Thiết kế phần mềm 3/26/2015 Trang 11 Các pha trong qui trình Lập trình phần mềm Lập trình phần mềm:  Hiện thực hóa bản thiết kế: • Cài đặt mã nguồn • Cài đặt cơ sở dữ liệu Đầu vào:  Tài liệu phân tích, thiết kế Sản phẩm:  Chương trình 3/26/2015 Trang 12 Các pha trong qui trình Kiểm nghiệm phần mềm  Kiểm nghiệm phần mềm:  Kiểm nghiệm bởi đội ngũ phát triển: • Thanh tra mã nguồn (Code Inspection) • Kiểm thử đơn vị (Unit Test) • Kiểm thử tích hợp (Intergration Test) • Kiểm thử hệ thống (System Test)  Kiểm nghiệm bởi khách hàng: • Phần mềm chuyên dụng: Acceptance Test • Phần mềm đại chúng: Beta Test, Release Candidate Test  Đầu vào:  Tài liệu phân tích – thiết kế, chương trình  Sản phẩm:  Báo cáo kiểm nghiệm 3/26/2015 Trang 13 Các pha trong qui trình Triển khai và bảo trì Triển khai và bảo trì:  Cài đặt phần cứng: máy móc, thiết bị mạng, ...  Vận hành phần mềm  Giải quyết sự cố  Sửa chữa lỗi phần mềm  Nâng cấp phần mềm Đầu vào:  Chương trình Sản phẩm:  Chương trình  Sưu liệu 3/26/2015 Trang 14 Nội dung Các pha trong qui trình Những mô hình phát triển phần mềm  Mô hình tháp nước  Mô hình chữ V  Mô hình phát triển lặp gia tăng Các mức kiểm thử Triết lý của việc Testing Những định nghĩa cơ bản 3/26/2015 Trang 15 Testing và Mô hình chu kỳ phát triển phần mềm Testing:  Không tồn tại độc lập  Liên quan đến những hoạt động trong quá trình phát triển phần mềm Đối với những mô hình phát triển phần mềm khác nhau => những giải pháp Testing khác nhau 3/26/2015 Trang 16 Mô hình tháp nước 3/26/2015 Trang 17 Giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có Giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS Giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế” Giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực Giai đoạn cài đặt, cấu hình và huấn luyện khách hàng Mô hình tháp nước Đặc trưng:  Các pha diễn ra tuần tự và độc lập  Tách rời quá trình đặc tả và hiện thực hóa  Chú trọng kiểm nghiệm sau khi làm Ưu điểm:  Thực hiện có hệ thống và bài bản  Tiên liệu chặt chẽ trước khi làm Nhược điểm:  Khó khăn khi có thay đổi xảy ra  Chỉ thích hợp với dự án có yêu cầu rõ ràng và ổn định  Cải tiến cho phép quay lui 3/26/2015 Trang 18 Mô hình chữ V  ƒCó thể coi đây là mô hình mở rộng của mô hình thác nước  Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển  Chữ V minh họa các khía cạnh của hoạt động Verification và Validation. 3/26/2015 Trang 19 Kiểm chứng (Verification) và chứng thực (Validation)  Kiểm chứng (Verification)  Tìm các lỗi trong từng giai đoạn  Các hành động để đảm bảo cho phần mềm được hiện thực đúng theo một chức năng cụ thể nào đó  “Are we building the system right?”  Chứng thực (Validation)  ‰Tìm lỗi trong toàn hệ thống  Các hành động để đảm bảo cho phần mềm được xây dựng theo đúng yêu cầu của khách hàng  “Are we building the right system?  V&V = Verification and Validation  Mục tiêu là phát hiện và sửa lỗi PM, đánh giá tính dùng được của PM  Thứ tự thực hiện: Verification -> Validation 3/26/2015 Trang 20 Mô hình chữ V Có rất nhiều biến thể của mô hình chữ V, nhưng điểm chung là nó gồm có 4 cấp độ Test  Kiểm nghiệm bộ phận (Module testing): kiểm nhiệm một bộ phận riêng rẽ.  Kiểm nghiệm tích hợp (Itegration testing): tích hợp các bộ phận và hệ thống con.  Kiểm nghiệm hệ thống (System testing): kiểm nghiệm toàn bộ hệ thống.  Kiểm nghiệm chấp nhận (Acceptance testing): thực hiện bởi khách hàng. 3/26/2015 Trang 21 Mô hình chữ V Ưu điểm  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àm song 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ợ cho nhau.  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ế 3/26/2015 Trang 22 Mô hình chữ V Điểm yếu:  Rất là cứng rắn và ít uyển chuyển • Tất cả những yêu cầu phải được xác định rõ ràng ngay từ bắt đầu dự án • Không dễ dàng để xử lý việc thay đổi của yêu cầu – Nếu có bắt kỳ thay đổi trong giai đoạn giữa, không chỉ tài liệu về yêu cầu mà cả những tài liệu về Testing cũng cần được cập nhật  Không thể thực hiện nhiều vòng lặp cho các giai đoạn  Người sử dụng không có cơ hội tham gia trong giai đoạn giữa từ thiết kế đển Testing • Có thể làm sản phẩm cuối cùng không thỏa yêu cầu của khách hàng 3/26/2015 Trang 23 Mô hình phát triển lặp gia tăng 3/26/2015 Trang 24  Trở thành cách tiếp cận phổ biến  Việc chuyển giao sản phẩm được chia làm nhiều giai đoạn, giai đoạn sau sẽ nhiều chức năng hơn giai đoạn trước  Trong mỗi giai đoạn chuyển giao sau cần 3 loại Test:  Test chức năng mới  Test hồi quy (regression test) chức năng cũ  Test tích hợp (integration test) chức năng mới và cũ  Sản phẩm sẽ được sớm đưa vào thị trường  Prototype, Extreme Programming , RAD (Rapid Application Development ) , RUP (Rational Unified Process) Kiểm tra trong mô hình vòng đời phần mềm Đặc tính chung của một quy trình kiểm thử tốt:  ‰Kiểm thử cho mỗi giai đọan/phần phát triển  ‰Các mức kiểm tra nhấn mạnh vào mục tiêu phối hợp liên tục, không trùng lắp  Phân tích, thiết kế bắt đầu sớm, ngăn ngừa lỗi 3/26/2015 Trang 25 Phân loại kiểm nghiệm 3/26/2015 Trang 26 Nội dung Các pha trong qui trình Những mô hình phát triển phần mềm  Mô hình tháp nước  Mô hình chữ V  Mô hình phát triển lặp gia tăng Các mức kiểm thử Triết lý của việc Testing Những định nghĩa cơ bản 3/26/2015 Trang 27 Kiểm tra thành phần/đơn vị Component (Unit) Test Kiểm thử đơn vị tập trung vào việc xác minh trên đơn vị nhỏ nhất của thiết kế phần mềm – thành phần phần mềm, module hoặc lớp Người tiến hành: lập trình viên Sử dụng các stubs và drivers Thường hướng hộp trắng, và các bước có thể được thực hiện song song trên nhiều module. 3/26/2015 Trang 28 Kiểm tra thành phần/đơn vị Component (Unit) Test  Giao diện (Interface):  Đảm bảo thông tin vào, ra hợp lệ của đơn vị chương trình  Cấu trúc dữ liệu:  Là nguồn lỗi phổ biến  Được kiểm tra để đảm bảo rằng dữ liệu được lưu trữ tạm thời đảm bảo tính nguyên vẹn trong tất cả các bước thực hiện của thuật toán 3/26/2015 Trang 29  Điều kiện biên  Đường đi độc lập:  Đảm bảo rằng tất cả các câu lệnh trong module đã được thực hiện ít nhất một lần  Xử lý lỗi  Một thiết kế tốt sẽ cho biết các điều kiện lỗi được biết trước  Và các đường dẫn xử lý lỗi được thiết lập để gửi lại hoặc kết thúc xử lý dễ dàng khi một lỗi xuất hiện Stubs & Drivers  Driver là module gọi thực thi làm cho module cần kiểm tra hoạt động, nó giả lập các module khác sẽ sử dụng module này. Các tập dữ liệu chia sẻ mà các module khác thiết lập trong thực tế cũng được thiết lập ở drive  Stub là module giả lập các module được module đang kiểm tra sử dụng 3/26/2015 Trang 30 Demo 3/26/2015 Trang 31 Kiểm tra tích hợp Intergration Test Kiểm thử tích hợp các Module Người tiến hành: lập trình viên, người thiết kế... Mục đích:  Kiểm tra giao diện giữa các Module  Kiểm tra tính đúng đắn so với đặc tả  Kiểm tra tính hiệu quả  Thường sử dụng kiểm thử chức năng 3/26/2015 Trang 32 Kiểm tra tích hợp Intergration Test Câu hỏi được đặt ra  Nên kiểm thử chương trình bằng cách kiểm thử từng module độc lập rồi kết hợp các module thành chương trình • ‰ Cách tiếp cận này gọi là kiểm thử/tích hợp không gia tăng hoặc còn gọi là big-bang;  Hay kết hợp thêm các module “mới” với các module đã được kiểm thử trước đó. • „ Cách tiếp cận sau được biết như là kiểm thử/tích hợp gia tăng 3/26/2015 Trang 33 Kiểm thử trên xuống Các mô đun mức trên được kiểm thử trước Các mô đun mức thấp được tạm thời phát triển với các chức năng hạn chế và được thay bằng bằng các mô đun tạm thời(stub function) 3/26/2015 Trang 34 a b c d e f g h i j k l m n o Kiểm thử trên xuống 3/26/2015 Trang 35 A B C D G F E Layer I Layer II Layer III Test A Layer I Test A, B, C, D Layer I + II Test A, B, C, D, E, F, G All Layers Kiểm thử trên xuống Ưu điểm:  Phát hiện sớm các lỗi thiết kế (lỗi cấu trúc) • Kiểm thử trên xuống kết hợp với phát triển trên xuống sẽ giúp phát hiện sớm các lỗi thiết kế và làm giảm giá thành sửa đổi  Có sớm phiên bản thực hiện được • Phiên bản thực hiện với các chức năng chính có sớm • Có thể thẩm định tính dùng được của sản phẩm sớm Nhược điểm:  Nhiều mô đun cấp thấp rất khó mô phỏng  Không kiểm thử đầy đủ các chức năng 3/26/2015 Trang 36 Kiểm thử dưới lên  Các mô đun cấp thấp được kiểm thử trước  Mô đun mức trên được thay thế bằng mô đun điều khiển (test driver), có chức năng  Gọi mô đun cần thử nghiệm  Truyền dữ liệu  Hiển thị kết quả  Thay thế dần các driver  Thông thường người ta không thuần túy kiểm thử tất cả các mô đun ở tầng dưới cùng mà nhóm các mô đun này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm 3/26/2015 Trang 37 a b c e f g k l m d i n o h j Kiểm thử dưới lên 3/26/2015 Trang 38 A B C D G F E Layer I Layer II Layer III Test F Test E Test G Test C Test D,G Test B, E, F Test A, B, C, D, E, F, G Bottom Up Testing Ưu điểm  Tránh xây dựng các mô đun tạm thời(stub) phức tạp  Thuận tiện cho phát triển các mô đun thứ cấp dùng lại được Nhược điểm  Phát hiện chậm các lỗi thiết kế  Chậm có phiên bản thực hiện được của hệ thống 3/26/2015 Trang 39 Top down vs. Bottom up Mỗi chiến lược đều có ưu nhược điểm riêng Chiến lược kiểm thử phải phù hợp với chiến lược phát triển  Phát triển top-down = top-down testing  Phát triển bottom-up = bottom-up testing Có thể phối hợp các chiến lược:  Sandwich testing 3/26/2015 Trang 40 Chiến lược Sandwich 3/26/2015 Trang 41 A B C D G F E Layer I Layer II Layer III Test F Test E Test B Test G Test D Test A Test C Test B, E, F Triple Test I Triple Test I Test D,G Double Test II Double Test II Double Test I Double Test I Test A,C Test A, B, C, D, E, F, G Kiểm tra tích hợp Intergration Test Có thể có nhiều hơn 1 mức kiểm tra tích hợp trong dự án  ‰Tích hợp thành phần: • ‰Tìm lỗi tương tác các thành phần  ‰Tích hợp hệ thống: • ‰Tìm lỗi tương tác trên toàn hệ thống Phức tạp  ‰Nhiều tổ chức  Tiến trình nghiệp vụ  Độ tương thích Hardware/system Kiểm tra tích hợp nên có kế hoạch rõ ràng trong giai đoạn thiết kế hệ thống Thứ tự tích hợp sẽ xác định thứ tự Build 3/26/2015 Trang 42 Kiểm tra hệ thống System Test Bao gồm một loạt các kiểm nghiệm nhằm xác minh toàn bộ các thành phần của hệ thống được tích hợp một cách đúng đắn. Mục đích của kiểm nghiệm hệ thống là để đảm bảo toàn bộ hệ thống hoạt động như ý mà khách hàng mong muốn. Môi trường Test càng giống môi trường thực càng nhiều càng tốt để giảm thiếu những rủi ro hay hay những lỗi do sự khác biệt môi trường gây ra 3/26/2015 Trang 43 Kiểm tra hệ thống System Test Bao gồm các loại kiểm nghiệm sau:  Kiểm nghiệm chức năng (Function testing)  Kiểm nghiệm phi chức năng (Non-Function testing) • Kiểm nghiệm hiệu suất (Perfomance testing) • Kiểm nghiệm mức độ đáp ứng (stress testing) • Kiểm nghiệm hồi phục (recovery testing) • Kiểm nghiệm quá tải (overload testing) • Kiểm nghiệm cài đặt (Installation testing) • Người tiến hành: QC hay 1 người độc lập 3/26/2015 Trang 44 Kiểm tra chấp nhận Acceptance Test Khách hàng/người sử dụng sẽ thực hiện kiểm thử này Dùng loại kiểm thử chức năng Mục đích: thẩm định (validation) phần mềm để xác định các sai sót, thiếu sót so với yêu cầu người dùng Sử dụng các dữ liệu thực do user cung cấp 3/26/2015 Trang 45 Kiểm tra chấp nhận Acceptance Test  Kiểm tra chấp nhận với người sử dụng:  ‰Người sử dụng nghiệp vụ xác nhận mức phù hợp cho chức năng  „Kiểm tra tác vụ (Operational testing):  Chấp nhận bởi người quản trị  „Hợp đồng và kiểm tra quy tắc (regulation testing):  Kiểm chứng xác nhận hợp lệ theo hợp đồng.  Kiểm tra Alpha  Khách hàng kiểm ngay tại nơi viết phần mềm.  Lập trình viên sẵn sàng fix bugs khi tìm thấy.  Kiểm thử Beta  ‰Khách hàng xài thử  Phần mềm đang ở trong môi trường thực  Khách hàng tiềm năng có thể không hài lòng 3/26/2015 Trang 46 Nội dung Các pha trong qui trình Những mô hình phát triển phần mềm  Mô hình tháp nước  Mô hình chữ V  Mô hình phát triển lặp gia tăng Các mức kiểm thử Triết lý của việc Testing Những định nghĩa cơ bản 3/26/2015 Trang 47 Triết lý của việc Testing  Ai sẽ thực hiện testing chương trình:  Chương trình nên được Testing từ nhiều phía: • Developers, QC, users, PM  Rất khó nhìn thấy được khuyết điểm của chình mình: • Chỉ có thể tìm thấy được khoảng 30%-50% lỗi của chình mình  Việc Testing đòi hỏi tính độc lập : lập trình viên nên tránh việc kiểm thử các chương trình do mình viết:  Các mức độ độc lập  Thiết kế Testing bởi người viết mã  Thiết kế Testing bởi người khác trong cùng dự án  Thiết kế Testing bởi người từ nhóm khác  Thiết kế Testing bởi người từ tổ chức khác  Thiết kế được tạo bằng công cụ (tool) 3/26/2015 Trang 48 Triết lý của việc Testing Khi có xảy ra lỗi, khiếm khuyết hay những hoạt động không mong đợi  Giao tiếp (communicate) theo cách tích cực– xây dựng „Cần kỹ năng giao tiếp, quan hệ tốt  ‰Bắt đầu với sự cộng tác hơn là đối đầu  Truyền đạt những kết quả lỗi theo ý trung lập, tập trung sự kiện, không chỉ trích  ‰Cố gắng hiểu người khác cảm nhận ra sao và tại sao họ phản ứng lại  Xác nhận lại những gì đã hiểu và chưa hiểu 3/26/2015 Trang 49 Nội dung Các pha trong qui trình Những mô hình phát triển phần mềm  Mô hình tháp nước  Mô hình chữ V  Mô hình phát triển lặp gia tăng Các mức kiểm tra Các kiểu kiểm tra Triết lý của việc Testing Những định nghĩa cơ bản 3/26/2015 Trang 50 Những định nghĩa cơ bản Defect Density (mật độ lỗi)  Tổng số lỗi / Kích thước của một thành phần Coverage (độ bao phủ):  Phép đo xác định nỗ lực của tester trong việc phát các hiện lỗi tiềm tàng. Test script  Hướng dẫn từng bước (step-by-step) mô tả thế nào một test case được thực thi. 3/26/2015 Trang 51  Test suite  Một tập hợp các test script hoặc test case  Để đánh giá các bản vá lỗi  Hoặc tìm lỗi mới Các thành phần chính của Testing 3/26/2015 Trang 52 ĐẢM BẢO VÀ KIỂM SOÁT CHẤT LƯỢNG 53 3/26/2015 Chương tiếp theo Kỹ thuật tĩnh - Rà soát và quá trình kiểm tra „Quy trình rà soát chương trình Các kỹ thuật kiểm thử tĩnh Phân tích tĩnh 3/26/2015 Trang 54