Bài giảng Công nghệ phần mềm - Bài 4: Quản lý chất lượng phần mềm - Lê Nguyễn Tuấn Thành

Nội dung text: Bài giảng Công nghệ phần mềm - Bài 4: Quản lý chất lượng phần mềm - Lê Nguyễn Tuấn Thành

1. Công nghệ Phần mềm Quản lý chất lượng phần mềm Giảng viên: Lê Nguyễn Tu ấn Thành Email: thanhlnt@tlu.edu.vn Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT Trường Đại Học Thủy Lợi
2. Nội dung } Quản lý chất lượng } Chất lượng phần mềm } Các hoạt động đảm bảo chất lượng phần mềm } Kiểm thử phần mềm } Bảo trì phần mềm 2
3. 1. Quản lý Chất lượng Quality Management 3
4. Mục tiêu } Giới thiệu quy trình quản lý chất lượng và các hoạt động quản lý chất lượng chính. } Giải thích vai trò của các tiêu chuẩn trong quản lý chất lượng } Giải thích các khái niệm về thước đo phần mềm, thước đo dự báo và thước đo kiểm soát } Giải thích cách đo lường có thể được sử dụng trong đánh giá chất lượng phần mềm và những hạn chế của các phép đo phần mềm 4
5. Chủ đề đề cập (Topics covered) } Quy trình và chất lượng sản phẩm } Đảm bảo chất lượng và tiêu chuẩn } Lập kế hoạch chất lượng } Kiểm soát chất lượng 5
6. Quản lý Chất lượng Phần mềm (Software quality management) } Liên quan đến việc đảm bảo đạt được mức độ yêu cầu về chất lượng trong một sản phẩm phần mềm. } Liên quan đến việc định nghĩa các tiêu chuẩn chất lượng phù hợp và các thủ tục và đảm bảo rằng những điều này được tuân thủ. } Hướng tới xây dựng một ‘văn hóa chất lượng’, nơi chất lượng được coi là trách nhiệm của mọi người. 6
7. Chất lượng là gì? } Chất lượng, theo cách đơn giản, có nghĩa là một sản phẩm phải đáp ứng các đặc tả của nó. } Một số vấn đề đối với các hệ thống phần mềm: } Có sự khác biệt giữa yêu cầu chất lượng của khách hàng (hiệu quả, độ tin cậy, v.v.) và yêu cầu về chất lượng của nhà phát triển (khả năng bảo trì, khả năng sử dụng lại, v.v.) } Một số yêu cầu về chất lượng rất khó xác định một cách rõ ràng } Đặc tả phần mềm thường không đầy đủ và thường không nhất quán. 7
8. Hoạt động Quản lý Chất lượng (Quality management activities) } Đảm bảo chất lượng (Quality assurance) } Thiết lập quy trình và tiêu chuẩn tổ chức cho chất lượng. } Lập kế hoạch chất lượng (Quality planning) } Chọn các thủ tục và tiêu chuẩn có thể áp dụng cho một dự án cụ thể và thay đổi chúng khi có yêu cầu. } Kiểm soát chất lượng (Quality control) } Đảm bảo rằng các quy trình và tiêu chuẩn được tuân sau bởi nhóm phát triển phần mềm. Quản lý chất lượng nên tách biệt với quản lý dự án để đảm bảo sự độc lập. 8
9. Quản lý Chất lượng và Phát triển Phần mềm (Quality management and software development) 9
10. Quy trình và Chất lượng Sản phẩm (Process and product quality) } Chất lượng của một sản phẩm được phát triển bị ảnh hưởng bởi chất lượng của quá trình sản xuất. 10
11. Chất lượng dựa trên Quy trình (1/2) (Process-based quality) } Có một liên kết minh bạch (straightforward) giữa quy trình và sản phẩm trong hàng hoá sản xuất. } Điều này phức tạp hơn với phần mềm bởi vì: } Việc áp dụng các kỹ năng và kinh nghiệm cá nhân đặc biệt quan trọng trong phát triển phần mềm; } Các yếu tố bên ngoài như tính mới của ứng dụng hoặc sự cần thiết của lịch trình phát triển nhanh có thể làm giảm chất lượng sản phẩm. } Cần phải chú ý không áp đặt các tiêu chuẩn quy trình không phù hợp - điều này có thể làm giảm chứ không phải cải thiện chất lượng sản phẩm. 11
12. Chất lượng dựa trên Quy trình (2/2) (Process-based quality) 12
13. Đảm bảo Chất lượng và Tiêu chuẩn (Quality assurance and standards) } Tiêu chuẩn là chìa khóa để quản lý chất lượng có hiệu quả. } Đóng gói các kinh nghiệm thực tiễn tốt nhất - tránh lặp lại những sai lầm trong quá khứ. } Là một khung làm việc cho các quy trình đảm bảo chất lượng - bao gồm việc kiểm tra sự tuân thủ các tiêu chuẩn. } Cung cấp sự liên tục - nhân viên mới có thể hiểu được tổ chức bằng cách hiểu các tiêu chuẩn đang được sử dụng. } Đó có thể là tiêu chuẩn quốc tế, quốc gia, tổ chức hoặc dự án. } Tiêu chuẩn sản phẩm định nghĩa các đặc tính mà tất cả các thành phần nên biểu thị } VD: một phong cách lập trình phổ biến. } Tiêu chuẩn quy trình định nghĩa cách thức ban hành quy trình phần mềm. 13
14. Tiêu chuẩn Sản phẩm và Quy trình (Product and process standards) Tiêu chuẩn sản phẩm Tiêu chuẩn quy trình Mẫu duyệt lại thiết kế Hướng dẫn duyệt lại thiết kế (Design review form) (Design review conduct) Cấu trúc tài liệu yêu cầu Nộp hồ sơ lên CM Định dạng tiêu đề phương Quy trình phát hành phiên bản thức Phong cách lập trình Java Quy trình phê duyệt kế hoạch dự án Định dạng kế hoạch dự án Quá trình kiểm soát thay đổi Mẫu yêu cầu thay đổi Quy trình ghi chép kiểm thử 14
15. ISO 9000 } Một bộ tiêu chuẩn quốc tế về quản lý chất lượng. } Có thể áp dụng cho một khoảng các tổ chức từ sản xuất đến ngành công nghiệp dịch vụ. } ISO 9001 có thể áp dụng cho các tổ chức thiết kế, phát triển và duy trì sản phẩm. } Một mô hình chung của quy trình chất lượng phải được khởi tạo cho mỗi tổ chức sử dụng tiêu chuẩn. 15
16. ISO 9001 Trách nhiệm quản lý Hệ thống chất lương Kiểm soát các sản phẩm không phù hợp Kiểm soát thiết kế (Design control) Xử lý, lưu trữ, đóng gói và phân phối Thu mua (Purchasing) Các sản phẩm do người mua cung cấp Xác định và truy xuất nguồn gốc sản phẩm Kiểm soát quy trình Kiểm tra và kiểm thử (Process control) (Inspection and testing) Thiết bị kiểm tra và kiểm thử Trạng thái kiểm tra và kiểm thử Xem xét hợp đồng Hành động khắc phục (Contract review) (Corrective action) Kiểm soát tài liệu Hồ sơ chất lượng (Document control) (Quality records) Kiểm toán chất lượng nội bộ Đào tạo (Training) Phục vụ (Servicing) Kỹ thuật thống kê 16
17. Chứng nhận ISO 9000 (ISO 9000 certification) } Các tiêu chuẩn và quy trình chất lượng phải được ghi chép trong một cuốn cẩm nang chất lượng tổ chức. } Một cơ quan bên ngoài có thể chứng nhận rằng tài liệu hướng dẫn chất lượng của tổ chức tuân theo tiêu chuẩn ISO 9000. } Một số khách hàng yêu cầu các nhà cung cấp được chứng nhận ISO 9000 mặc dù sự cần thiết phải linh hoạt ở đây ngày càng được công nhận. 17
18. ISO 9000 và Quản lý Chất lượng (ISO 9000 and Quality management) 18
19. Tiêu chuẩn Tài liệu hóa (Documentation standards) } Đặc biệt quan trọng - tài liệu là sự biểu hiện hữu hình của phần mềm. } Tiêu chuẩn quy trình tài liệu } Liên quan đến cách thức phát triển, xác thực và duy trì các tài liệu. } Tiêu chuẩn tài liệu } Liên quan đến nội dung, cấu trúc, và sự xuất hiện tài liệu } Tiêu chuẩn trao đổi tài liệu } Liên quan đến tính tương thích của tài liệu điện tử. 19
20. Quy trình Tài liệu hóa (Documentation process) 20
21. Lập kế hoạch Chất lượng (Quality planning) } Kế hoạch chất lượng đưa ra các chất lượng sản phẩm mong muốn và cách chúng được đánh giá và định nghĩa các thuộc tính chất lượng quan trọng nhất. } Nên định nghĩa quá trình đánh giá chất lượng. } Nên đặt ra các tiêu chuẩn tổ chức nên được áp dụng và, nơi cần thiết, xác định các tiêu chuẩn mới được sử dụng. 21
22. Kế hoạch Chất lượng (Quality plans) } Cấu trúc kế hoạch chất lượng: } Giới thiệu sản phẩm } Các kế hoạch sản phẩm } Miêu tả quy trình } Các mục tiêu chất lượng } Rủi ro và quản lý rủi ro 22
23. Các thuộc tính Chất lượng Phần mềm (Software quality attributes) An toàn Có thể hiểu được Tính di động (Safety) (Understandability) (Portability) Bảo mật Khả năng kiểm tra Tính khả dụng (Security) (Testability) (Usability) Độ tin cậy Tính tương thích Khả năng tái sử (Reliability) (Adaptability) dụng (Reusability) Khả năng phục hồi Tính mô-đun Hiệu quả (Resilience) (Modularity) (Efficiency) Độ bền Độ phức tạp Khả năng học (Robustness) (Complexity) (Learnability) 23
24. Kiểm soát Chất lượng (Quality control) } Liên quan việc kiểm tra quy trình phát triển phần mềm để đảm bảo rằng các quy trình và tiêu chuẩn đang được tuân thủ. } Có hai phương pháp để kiểm soát chất lượng } Duyệt/Rà soát lại chất lượng (Quality reviews); } Đánh giá phần mềm và đo lường phần mềm tự động 24
25. Soát lại Chất lượng (1/2) (Quality reviews) } Là phương pháp chính để xác thực chất lượng của một quy trình hoặc một sản phẩm. } Một nhóm sẽ kiểm tra một phần hoặc toàn bộ quy trình (mã chương trình, thiết kế, đặc tả, kế hoạch kiểm thử, tiêu chuẩn, v.v.) hoặc hệ thống và tài liệu của nó để tìm ra các vấn đề tiềm ẩn. 25
26. Soát lại Chất lượng (2/2) (Quality reviews) } Có nhiều kiểu soát lại khác nhau với các mục tiêu khác nhau: } Kiểm tra để loại bỏ khiếm khuyết (sản phẩm): Để phát hiện các lỗi chi tiết trong các yêu cầu, thiết kế hoặc mã chương trình. Một danh sách kiểm tra các lỗi có thể có sẽ điều khiển việc soát lại này. } Soát lại về đánh giá tiến độ (sản phẩm và quy trình): Cung cấp thông tin để quản lý về tiến độ chung của dự án. Đây là việc soát lại cả quy trình và sản phẩm và liên quan đến chi phí, kế hoạch và lịch trình. } Soát lại chất lượng (sản phẩm và tiêu chuẩn): Thực hiện phân tích kỹ thuật các thành phần hoặc tài liệu sản phẩm để tìm ra sự không khớp giữa đặc tả và thiết kế thành phần, đoạn mã hoặc tài liệu và đảm bảo rằng các tiêu chuẩn chất lượng đã định nghĩa được tuân thủ. 26
27. Kết quả của việc soát lại (Review results) } Nhận xét trong quá trình soát lại được phân loại thành: } Không cần có hành động gì thêm. Không yêu cầu thay đổi phần mềm hoặc tài liệu; } Tham khảo để sửa chữa. Người thiết kế hoặc lập trình nên sửa các lỗi đã xác định; } Xem lại thiết kế tổng thể. Vấn đề được xác định trong việc soát lại ảnh hưởng đến các bộ phận khác của thiết kế. Một vài phán quyết tổng thể phải được đưa ra về cách hiệu quả nhất về chi phí để giải quyết vấn đề; } Các lỗi yêu cầu và đặc tả có thể phải được chuyển tới khách hàng. 27
28. Thước đo và Đo lường Phần mềm (Software measurement and metrics) } Đo lường phần mềm liên quan đến việc tìm ra một giá trị bằng số cho một thuộc tính của sản phẩm phần mềm hoặc quy trình. } Cho phép so sánh khách quan giữa các kỹ thuật và quy trình khác nhau. 28
29. Thước đo Phần mềm (Software metric) } Là bất kỳ loại phép đo nào liên quan đến hệ thống phần mềm, quy trình hoặc tài liệu liên quan } Số dòng mã trong chương trình, chỉ số Fog, số ngày người/ngày cần thiết để phát triển một thành phần. } Cho phép lượng hóa phần mềm và quy trình phần mềm. } Có thể được sử dụng để dự đoán các thuộc tính của sản phẩm hoặc để kiểm soát quy trình phần mềm. } Thước đo sản phẩm có thể được sử dụng cho các dự đoán chung hoặc để xác định các thành phần bất thường. 29
30. Thước đo Dự báo và Kiểm soát (Predictor and control metrics) 30
31. Thuộc tính Bên trong và Bên ngoài (Internal and external attributes) 31
32. Quy trình Đo lường (Measurement process) } Một quy trình đo lường phần mềm có thể là một phần của quá trình kiểm soát chất lượng. } Dữ liệu thu thập được trong quá trình này cần được duy trì như là một nguồn lực tổ chức. } Một khi cơ sở dữ liệu đo lường đã được thiết lập, sự so sánh giữa các dự án trở nên khả thi. 32
33. Quy trình Đo lường Sản phẩm (Product measurement process) 33
34. Thước đo Sản phẩm (Product metrics) } Một thước đo chất lượng nên là chỉ số dự báo về chất lượng sản phẩm. } Phân loại thước đo sản phẩm: } Thước đo động được thu thập bằng các phép đo được thực hiện với một chương trình đang chạy: giúp đánh giá hiệu quả và độ tin cậy. } Thước đo tĩnh được thu thập bằng các phép đo được tạo ra từ các biểu diễn của hệ thống: giúp đánh giá mức độ phức tạp, tính dễ hiểu và khả năng bảo trì. 34
35. Thước đo Sản phẩm Phần mềm (Software product metrics) TĐ phần mềm Miêu tả (Software metric) Fan-in/Fan-out Fan-in là thước đo số chức năng hoặc phương thức gọi một hàm hoặc phương thức khác (X). Fan-out là số chức năng được gọi bởi hàm X. Một giá trị cao của fan-in có nghĩa là X liên kết chặt chẽ với phần còn lại của thiết kế và sự thay đổi với X sẽ có ảnh hưởng rộng. Một giá trị cao của fan- out gợi ý rằng độ phức tạp tổng thể của X có thể cao bởi vì sự phức tạp của logic kiểm soát cần thiết để phối hợp các thành phần được gọi. Chiều dài đoạn mã Đây là thước đo về kích thước của một chương trình. Nói chung, kích (Length of code) thước đoạn mã của một thành phần càng lớn thì thành phần đó càng phức tạp và dễ bị lỗi. Độ dài đoạn mã đã được chứng minh là một trong những thước đo đáng tin cậy nhất để dự đoán sai sót trong các thành phần. Độ phức tạp chu kỳ Đây là một thước đo của độ phức tạp kiểm soát của một chương trình. Độ (Cyclomatic complexity) phức tạp kiểm soát này có thể liên quan đến tính dễ hiểu của chương trình. Chiều dài của định danh Đây là thước đo độ dài trung bình của các định danh khác biệt trong một (Length of identifiers) chương trình. Định danh càng dài thì chúng càng có ý nghĩa và do đó chương trình càng dễ hiểu hơn. Độ sâu của các lệnh Đây là thước đo độ sâu của việc lồng các mệnh đề if trong một chương lồng có điều kiện trình. Mệnh đề if lồng nhau sâu thì sẽ khó hiểu và dễ tiềm ẩn lỗi. Chỉ số Fog Đây là thước đo độ dài trung bình của các từ và câu trong tài liệu. Giá trị (Fog index) của chỉ số Fog càng cao, tài liệu đó càng khó hiểu. 35
36. Thước đo Hướng đối tượng (Object-oriented metrics) TĐ hướng đối tượng Miêu tả (Software metric) Độ sâu của cây thừa kế Điều này thể hiện số lượng các mức rời rạc trong cây thừa kế nơi lớp con kế thừa các thuộc tính và hành động (phương pháp) từ lớp cha. Cây kế thừa càng sâu, thiết kế càng phức tạp. Phương thức fan-in / Điều này liên quan trực tiếp đến fan-in và fan-out như được mô tả ở trên và fan-out có ý nghĩa cơ bản giống nhau. Tuy nhiên, có thể phân biệt giữa các lời gọi từ các phương thức khác bên trong đối tượng và các lời gọi từ các phương thức bên ngoài. Phương thức trọng số Đây là số lượng phương thức bao gồm trong một lớp, được tính trọng số bởi cho lớp độ phức tạp của mỗi phương thức. Do đó, một phương thức đơn giản có thể có độ phức tạp là 1 và một phương pháp lớn và phức tạp có giá trị cao hơn. Giá trị thước đo càng lớn, lớp đối tượng càng phức tạp. Các đối tượng phức tạp nhiều khả năng sẽ khó hiểu hơn. Chúng có thể không liên kết hợp lý nên không thể sử dụng lại hiệu quả như các lớp cha trong một cây thừa kế. Số lượng thao tác ghi Đây là số lượng các thao tác trong một lớp cha được ghi đè trong một lớp đè con. Một giá trị cao cho thấy lớp cha được sử dụng có thể không phải là lớp (Overriding operations) cha thích hợp cho lớp con. 36
37. Tóm tắt những điểm chính (Key points) } Quản lý chất lượng phần mềm liên quan đến việc đảm bảo rằng phần mềm đáp ứng các tiêu chuẩn được yêu cầu. } Các thủ tục đảm bảo chất lượng cần được ghi lại trong sổ tay chất lượng tổ chức. } Tiêu chuẩn phần mềm là một đóng gói của những thực hành tốt nhất. } Soát lại là cách tiếp cận được sử dụng rộng rãi nhất để đánh giá chất lượng phần mềm. } Đo lường phần mềm thu thập thông tin về cả quy trình phần mềm và sản phẩm phần mềm. } Thước đo chất lượng sản phẩm nên được sử dụng để xác định các thành phần có khả năng gây ra vấn đề. } Không có thước đo phần mềm được chuẩn hóa và áp dụng phổ quát. 37
38. 2. Kie" m thử Pha& n me& m Software Testing 38
39. Mục tiêu } Miêu tả các nguyên tắc của kiểm thử thành phần và kiểm thử hệ thống } Thảo luận về sự khác biệt giữa kiểm thử xác thực và kiểm thử khiếm khuyết } Miêu tả chiến lược tạo ra các trường hợp kiểm thử hệ thống } Hiểu được các đặc tính cơ bản của công cụ được sử dụng cho tự động hóa kiểm thử 39
40. Chủ đề Đề cập (Topics covered) } Kiểm thử thành phần (component testing) } Kiểm thử hệ thống (system testing) } Thiết kế các trường hợp kiểm thử (test cases) } Tự động hóa kiểm thử (test automation) 40
41. 2.1. Quy trình Kiểm thử (Testing process) } Kiểm thử thành phần } Kiểm tra từng thành phần của chương trình; } Thông thường là trách nhiệm của người phát triển thành phần (ngoại trừ các hệ thống quan trọng); } Các bài kiểm thử bắt nguồn từ kinh nghiệm của người phát triển. } Kiểm thử hệ thống } Kiểm tra các nhóm thành phần được tích hợp để tạo ra một hệ thống hoặc một hệ thống con; } Là trách nhiệm của một nhóm kiểm thử độc lập; } Các bài kiểm thử được dựa trên đặc tả hệ thống. 41
42. Các Giai đoạn Kiểm thử (Testing phases) 42
43. Mục tiêu của Quy trình Kiểm thử (Testing process goals) } Kiểm tra xác thực (validation testing) } Để chứng minh cho người phát triển và khách hàng hệ thống rằng phần mềm đáp ứng các yêu cầu của nó; } Một kiểm thử xác thực thành công cho thấy hệ thống hoạt động như dự định. } Kiểm tra khiếm khuyết (defect testing) } Để phát hiện lỗi hoặc khuyết tật trong phần mềm có hành xử không đúng hoặc không phù hợp với đặc tả của nó; } Một kiểm thử khiếm khuyết thành công là một thử nghiệm làm cho hệ thống thực hiện không đúng và do đó bộc lộ một khiếm khuyết trong hệ thống. 43
44. Quy trình Kiểm thử Phần mềm (Software Testing Process) 44
45. 2.2. Kiểm thử Hệ thống (System testing) } Liên quan đến việc tích hợp các thành phần để tạo ra một hệ thống hoặc một hệ thống con. } Hai giai đoạn: } Kiểm thử tích hợp - đội kiểm thử có quyền truy cập vào mã nguồn của hệ thống. } Kiểm thử phát hành - nhóm kiểm thử kiểm tra toàn bộ hệ thống sẽ được phân phối dưới dạng hộp đen (black-box). 45
46. Kiểm thử Tích hợp (Integration testing) } Liên quan đến việc xây dựng một hệ thống từ các thành phần của nó và kiểm thử hệ thống này với các vấn đề phát sinh từ sự tương tác giữa các thành phần. } Tích hợp từ trên xuống dưới (Top-down integration) } Phát triển bộ khung của hệ thống và mở rộng nó với các thành phần. } Tích hợp từ dưới lên trên (Bottom-up integration) } Tích hợp các thành phần cơ sở hạ tầng sau đó thêm các thành phần chức năng. 46
47. Kiểm thử Phát hành (Release testing) } Là quy trình kiểm tra việc phát hành của một hệ thống sẽ được phân phối cho khách hàng. } Mục tiêu chính là tăng sự tin tưởng của nhà cung cấp rằng hệ thống đáp ứng các yêu cầu của nó. } Kiểm thử phát hành thường là hộp đen (black-box) hoặc kiểm thử chức năng } Chỉ dựa trên đặc tả hệ thống; } Người kiểm thử (tester) không có kiến thức về việc cài đặt hệ thống. 47
48. Kiểm thử Hộp đen (Black-box testing) 48
49. Hướng dẫn Kiểm thử (Testing guidelines) } Là những gợi ý cho nhóm kiểm thử để giúp họ chọn các bài kiểm tra sẽ phát hiện ra các khiếm khuyết trong hệ thống } Chọn đầu vào để buộc hệ thống tạo ra tất cả các thông báo lỗi; } Thiết kế đầu vào gây ra tràn bộ đệm; } Lặp lại các đầu vào tương tự hay một loạt đầu vào nhiều lần; } Buộc các đầu ra không hợp lệ được tạo ra; } Buộc các kết quả tính toán sẽ quá lớn hoặc quá nhỏ. 49
50. Kịch bản Kiểm thử (Testing scenario) “ Một sinh viên ở Scotland đang học Lịch sử Hoa Kỳ và đã được yêu cầu viết một bài báo về "Tâm lý biên giới ở Miền Tây Hoa Kỳ từ năm 1840 đến năm 1880". Để làm điều này, cô ấy cần phải tìm các nguồn từ một loạt các thư viện. Cô đăng nhập vào hệ thống LIBSYS và sử dụng chức năng tìm kiếm để khám phá xem liệu cô có thể truy cập các tài liệu gốc vào thời điểm đó hay không. Cô phát hiện ra các nguồn trong thư viện các trường đại học Hoa Kỳ khác nhau và tải xuống các bản sao của một vài trong số này. Tuy nhiên, có một tài liệu, cô ấy cần phải có xác nhận từ trường đại học của mình rằng cô ấy là một sinh viên thực sự và việc sử dụng tài liệu này là vì mục đích phi thương mại. Sinh viên này sau đó sử dụng một chức năng trong LIBSYS để có thể yêu cầu sự cho phép đó và đăng ký yêu cầu của mình. Nếu được cấp, tài liệu sẽ được tải xuống máy chủ của thư viện đã đăng ký và được in cho cô ấy. Cô nhận được một tin nhắn từ LIBSYS nói với cô rằng cô sẽ nhận được một bức thư điện tử khi tài liệu in sẵn có. ” 50
51. Kiểm thử Hệ thống cho Kịch bản này (System tests) } Kiểm tra cơ chế đăng nhập sử dụng đăng nhập chính xác và không chính xác để kiểm tra xem liệu người dùng hợp lệ có được chấp nhận và người dùng không hợp lệ có bị bị từ chối không. } Kiểm tra tính năng tìm kiếm bằng cách sử dụng các truy vấn khác nhau đối với các nguồn đã biết để kiểm tra xem liệu cơ chế tìm kiếm có đang thực sự tìm tài liệu không. } Kiểm tra chức năng biểu diễn hệ thống để kiểm tra xem liệu thông tin về tài liệu được hiển thị đúng. } Kiểm tra cơ chế yêu cầu cho phép tải xuống. } Kiểm tra phản hồi bằng thư điện tử cho biết tài liệu đã tải xuống có sẵn. 51
52. Kiểm thử Hiệu suất (Performance testing) } Là một phần của kiểm thử phát hành liên quan đến việc kiểm tra các đặc tính nổi bật của một hệ thống, chẳng hạn như hiệu suất và độ tin cậy. } Các bài kiểm thử về hiệu suất thường liên quan đến việc lập kế hoạch một loạt các bài kiểm tra, với tải được tăng lên đều đặn cho đến khi hiệu suất của hệ thống trở nên không thể chấp nhận được. 52
53. Kiểm thử Áp lực (Stress testing) } Tập luyện hệ thống với tải vượt quá thiết kế tối đa. Tạo áp lực hệ thống thường giúp phát hiện những khiếm khuyết. } Tạo áp lực hệ thống kiểm tra hành vi thất bại. Kiểm thử áp lực kiểm tra sự mất mát không thể chấp nhận được của dịch vụ hoặc dữ liệu. } Kiểm thử áp lực đặc biệt có liên quan đến các hệ thống phân tán có thể có sự xuống cấp nghiêm trọng khi hệ thống mạng trở nên quá tải. 53
54. 2.3. Kiểm thử Thành phần (Component testing) } Kiểm thử thành phần hoặc đơn vị là quá trình kiểm tra những thành phần riêng lẻ theo cách cô lập. } Đó là một quy trình kiểm thử khiếm khuyết. } Thành phần có thể là: } Các chức năng hoặc phương thức riêng lẻ trong một đối tượng; } Các lớp đối tượng với một số thuộc tính và phương thức; } Các thành phần phức hợp với các giao diện được định nghĩa được sử dụng để truy cập các chức năng của chúng. 54
55. Kiểm thử Lớp đối tượng (Object class testing) } Kiểm thử hoàn toàn phạm vi bao trùm của một lớp liên quan: } Kiểm tra tất cả các hoạt động liên quan đến một đối tượng; } Thiết lập và thẩm tra tất cả các thuộc tính của đối tượng; } Thử nghiệm các đối tượng trong tất cả các trạng thái có thể. } Kế thừa làm cho việc thiết kế kiểm thử lớp đối tượng trở nên khó khăn hơn vì thông tin được kiểm tra không được khoanh vùng. 55
56. Giao diện Đối tượng Trạm thời tiết (Weather station object interface) 56
57. Kiểm thử Trạm thời tiết (Weather station testing) } Cần định nghĩa các trường hợp thử nghiệm cho các hàm thành viên: reportWeather(), calibrate(), test(), startup() và shutdown(). } Sử dụng một mô hình trạng thái, xác định trình tự của quá trình chuyển đổi trạng thái để được kiểm tra và trình tự sự kiện gây ra những chuyển tiếp này. } Ví dụ: Waiting -> Calibrating ->Testing ->Transmitting ->Waiting 57
58. Kie" m thử Giao diện (Interface testing) } Mục đích là để phát hiện lỗi giao diện hoặc những giả định không hợp lệ về giao diện. } Đặc biệt quan trọng đối với sự phát triển hướng đối tượng khi các đối tượng được định nghĩa bởi các giao diện của chúng. 58
59. Các kiểu Giao diện (Interface types) } Giao diện tham số (Parameter interfaces) } Dữ liệu được truyền từ thủ tục này sang thủ tục khác. } Giao diện bộ nhớ chia sẻ (Shared memory interfaces) } Khối bộ nhớ được chia sẻ giữa các thủ tục hoặc các hàm. } Giao diện thủ tục (Procedural interfaces) } Hệ thống con đóng gói một tập hợp các thủ tục được gọi bởi các hệ thống con khác. } Giao diện truyền thông điệp (Message passing interfaces) } Các hệ thống con yêu cầu dịch vụ từ các hệ thống con khác 59
60. Lỗi giao diện (Interface errors) } Sử dụng sai giao diện (Interface misuse) } Một thành phần gọi một thành phần khác và gây ra lỗi trong việc sử dụng giao diện của nó, ví dụ: các thông số được đặt sai thứ tự. } Hiểu sai giao diện (Interface misunderstanding) } Một thành phần gọi các giả định được gắn về hành vi của thành phần được gọi mà không chính xác. } Lỗi thời gian (Timing errors) } Thành phần được gọi và thành phần gọi hoạt động với tốc độ khác nhau và thông tin không cập nhật được truy cập. 60
61. Hướng dẫn Kiểm thử Giao diện (Interface testing guidelines) } Kiểm thử thiết kế sao cho các tham số của một thủ tục được gọi ở các đầu cực trong các khoảng của chúng. } Luôn luôn kiểm tra các tham số con trỏ với các con trỏ null. } Kiểm thử thiết kế để khiến các thành phần thực thi thất bại. } Sử dụng kiểm thử áp lứcj trong các hệ thống truyền thông điệp. } Trong các hệ thống bộ nhớ chia sẻ, thay đổi thứ tự các thành phần được kích hoạt. 61
62. 2.4. Thiết kế Testcase } Liên quan đến thiết kế các trường hợp thử nghiệm (đầu vào và đầu ra) được sử dụng để kiểm tra hệ thống. } Mục tiêu của thiết kế trường hợp thử nghiệm là tạo ra một bộ các bài kiểm tra có hiệu quả trong việc kiểm tra xác thực và khiếm khuyết. } Các hướng thiết kế: } Kiểm thử dựa trên yêu cầu; } Kiểm thử phân vùng (Partition testing); } Kiểm thử cấu trúc (Structural testing). 62
63. Kiểm thử dựa trên Yêu cầu (Requirements based testing) } Một nguyên tắc chung của kỹ thuật yêu cầu là các yêu cầu nên có thể kiểm thử. } Kiểm thử dựa trên yêu cầu là một kỹ thuật kiểm thử xác thực khi bạn xem xét từng yêu cầu và lấy ra một bộ kiểm thử cho yêu cầu đó. 63
64. VD: Các Yêu cầu của LIBSYS (LIBSYS requirements) } Người dùng có thể tìm kiếm hoặc tất cả các bộ cơ sở dữ liệu ban đầu hoặc một tập hợp con. } Hệ thống sẽ cung cấp những góc nhìn thích hợp cho người dùng để đọc các tài liệu trong kho tài liệu. } Mọi đơn hàng sẽ được cấp một số nhận dạng duy nhất (ORDER_ID) mà người dùng có thể sao chép vào khu vực lưu trữ vĩnh viễn của tài khoản. 64
65. VD: Các Kiểm thử của LIBSYS (LIBSYS tests) } Khởi tạo tìm kiếm người dùng để tìm kiếm các mục được biết trước là có sẵn và không có sẵn, với bộ cơ sở dữ liệu bao gồm 1 cơ sở dữ liệu. } Khởi tạo tìm kiếm người dùng để tìm kiếm các mục được biết trước là có sẵn và không có sẵn, với bộ cơ sở dữ liệu bao gồm 2 cơ sở dữ liệu. } Khởi tạo tìm kiếm người dùng để tìm kiếm các mục được biết trước là có sẵn và không có sẵn, với bộ cơ sở dữ liệu bao gồm nhiều hơn 2 cơ sở dữ liệu. } Chọn 1 cơ sở dữ liệu từ bộ cơ sở dữ liệu và khởi tạo tìm kiếm người dùng cho các mục được biết trước là có sẵn và không có sẵn. } Chọn nhiều hơn 1 cơ sở dữ liệu từ bộ cơ sở dữ liệu và khởi tạo tìm kiếm các mục được biết trước là có mặt và không có mặt. 65
66. Kie" m thử Phân vùng (Partition testing) } Dữ liệu đầu vào và kết quả đầu ra thường rơi vào các lớp khác nhau, trong đó tất cả các thành viên của một lớp có liên quan với nhau. } Mỗi lớp này là một phân vùng hoặc miền tương đương mà chương trình ứng xử theo cách tương đương cho mỗi thành viên của lớp. } Các trường hợp kiểm tra nên được chọn từ mỗi phân vùng. 66
67. Phân vùng Tương đương (Equivalence partitioning) 67
68. Những Phân vùng Tương đương (Equivalence partitions) 68
69. Kiểm thử Cấu trúc (1/2) (Structural testing) } Đôi khi được gọi là kiểm thử hộp trắng (white-box testing) } Phát sinh các trường hợp kiểm tra theo cấu trúc chương trình. } Kiến thức về chương trình được sử dụng để xác định các trường hợp thử nghiệm bổ sung. } Mục tiêu là thực hiện tất cả các câu lệnh chương trình (không phải là kết hợp của tất cả các đường đi). 69
70. Kiểm thử Cấu trúc (2/2) (Structural testing) 70
71. 2.5. Tự động hóa Kiểm thử (Test automation) } Kiểm thử là một giai đoạn quy trình tốn kém. } Các khung kiểm thử (testing workbenches) cung cấp một loạt các công cụ để giảm thời gian cần thiết và tổng chi phí kiểm thử. } Các hệ thống như JUnit hỗ trợ thực hiện tự động các bài kiểm thử. } Hầu hết các workbench kiểm thử là các hệ thống mở vì nhu cầu kiểm thử là đặc thù của tổ chức. } Đôi khi rất khó để tích hợp với thiết kế khép kín và phân tích các workbench . 71
72. Workbench Kiểm thử 72
73. Thích ứng Workbench Kiểm thử } Các kịch bản có thể được phát triển cho các trình mô phỏng giao diện người dùng và các mẫu cho bộ tạo dữ liệu kiểm thử. } Kết quả kiểm thử có thể phải được chuẩn bị bằng tay để so sánh. } Các bộ so sánh tập tin mục đích đặc biệt có thể được phát triển. 73
74. Tóm tắt những điểm chính (Key points) } Kiểm thử có thể cho thấy sự hiện diện của lỗi trong một hệ thống; nó không thể chứng minh rằng không tồn tại các lỗi khác. } Các nhà phát triển thành phần chịu trách nhiệm kiểm thử thành phần; Kiểm thử hệ thống là trách nhiệm của một nhóm riêng biệt. } Kiểm thử tích hợp là kiểm tra gia số của hệ thống; Kiểm thử phát hành liên quan đến việc kiểm thử một hệ thống được phát hành cho khách hàng. } Sử dụng kinh nghiệm và các hướng dẫn để thiết kế trường hợp thử nghiệm trong kiểm tra khiếm khuyết. } Kiểm thử giao diện được thiết kế để phát hiện các khiếm khuyết trong giao diện của các thành phần phức hợp. } Phân vùng tương đương là một cách để khám phá các trường hợp thử nghiệm - tất cả các trường hợp trong một phân vùng sẽ hành xử theo cùng một cách. } Phân tích cấu trúc dựa vào phân tích một chương trình và sinh ra các bài kiểm tra từ phân tích này. } Kiểm thử tự động giảm chi phí kiểm thử bằng cách hỗ trợ quá trình kiểm thử với một loạt các công cụ phần mềm. 74
75. 3. Bảo trì Phần mềm Software maintenance 75
76. Mục tiêu } Giải thích tại sao sự thay đổi là điều không tránh khỏi nếu các hệ thống phần mềm vẫn còn muốn hữu ích } Thảo luận về các yếu tố chi phí bảo trì và duy trì phần mềm } Miêu tả các quá trình liên quan đến sự tiến hóa phần mềm } Thảo luận cách tiếp cận để đánh giá các chiến lược tiến hóa cho các hệ thống kế thừa (legacy systems) 76
77. Chủ đề đề cập (Topics covered) } Động lực tiến hóa của chương trình } Bảo trì phần mềm } Các quá trình tiến hóa } Tiến hóa hệ thống kế thừa 77
78. Sự thay đo$ i củ a pha( n me( m (Software change) } Thay đổi phần mềm là không thể tránh khỏi } Các yêu cầu mới xuất hiện khi sử dụng phần mềm; } Môi trường kinh doanh thay đổi; } Nhiều lỗi phải được sửa chữa; } Máy tính và thiết bị mới được thêm vào hệ thống; } Hiệu suất hoặc độ tin cậy của hệ thống có thể phải được cải thiện. } Một vấn đề quan trọng đối với các tổ chức là thực hiện và quản lý sự thay đổi đối với các hệ thống phần mềm hiện có của họ. 78
79. Tầm quan trọng của sự tiến hóa (Importance of evolution) } Các tổ chức đầu tư rất lớn vào hệ thống phần mềm của họ - chúng là những tài sản kinh doanh quan trọng. } Để duy trì giá trị của các tài sản này cho doanh nghiệp, chúng phải được thay đổi và cập nhật. } Phần lớn ngân sách phần mềm trong các công ty lớn được dành cho việc tiến hóa phần mềm hiện tại thay vì phát triển phần mềm mới. 79
80. Mô hình xoắn ốc của sự tiến hóa (Spiral model of evolution) 80
81. Động lực tiến hóa của chương trình (Program evolution dynamics) } Động lực tiến hoá của chương trình là nghiên cứu về những quá trình thay đổi của hệ thống. } Sau nhiều nghiên cứu thực nghiệm, Lehman và Belady đã đề xuất một số "luật" áp dụng cho tất cả các hệ thống khi chúng tiến hóa. } Những luật của Lehman dường như thường áp dụng cho các hệ thống lớn được thiết kế riêng bởi các tổ chức lớn. 81
82. Những luật của Lehman (Lehman’s laws) Luật Miêu tả Thay đổi liên tục Một chương trình được sử dụng trong một môi trường thực tế nhất thiết phải (Continuing change) thay đổi hoặc trở nên dần dần ít hữu ích trong môi trường đó. Tăng độ phức tạp Khi một chương trình tiến hóa thay đổi, cấu trúc của nó có xu hướng trở nên (Increasing complexity) phức tạp hơn. Các nguồn lực bổ sung phải được dành cho việc bảo tồn và đơn giản hóa cấu trúc. Tiến hóa của chương Tiến hóa của chương trình là một quá trình tự điều chỉnh. Các thuộc tính hệ trình lớn thống như kích thước, thời gian giữa các bản phát hành và số lượng lỗi được báo cáo là xấp xỉ bất biến cho mỗi lần phát hành hệ thống. Ổn định tổ chức Trong suốt vòng đời của chương trình, tốc độ phát triển của nó là xấp xỉ (Organisational stability) không đổi và không phụ thuộc vào các nguồn lực dành cho việc phát triển hệ thống. Bảo tồn sự quen thuộc Trong suốt vòng đời của một hệ thống, sự thay đổi gia tăng trong mỗi bản phát hành là xấp xỉ không đổi. Tăng trưởng liên tục Các chức năng được cung cấp bởi các hệ thống phải liên tục tăng để duy trì (Continuing growth) sự hài lòng của người dùng. Suy giảm chất lượng Chất lượng của các hệ thống dường như sẽ bị suy giảm trừ khi chúng thích (Declining quality) nghi với những thay đổi trong môi trường hoạt động của chúng. Hệ thống phản hồi Các quy trình tiến hóa kết hợp nhiều hệ thống phản hồi đa vòng, đa tác tử, (Feedback system) và bạn phải quan tâm đến chúng để đạt được cải tiến đáng kể về sản phẩm. 82
83. Bảo trì phần mềm (Software maintenance) } Sửa đổi một chương trình sau khi nó đã được đưa vào sử dụng. } Việc bảo trì thường không liên quan đến những thay đổi lớn đối với kiến trúc của hệ thống. } Thay đổi được thực hiện bằng cách sửa đổi các thành phần hiện có và thêm các thành phần mới vào hệ thống. 83
84. Bả o trì là không the$ tránh khỏ i (Maintenance is inevitable) } Các yêu cầu của hệ thống có thể sẽ thay đổi trong khi hệ thống đang được phát triển vì môi trường thay đổi. Do đó, một hệ thống phân phối sẽ không đáp ứng các yêu cầu của nó! } Các hệ thống được kết hợp chặt chẽ với môi trường của chúng. Khi một hệ thống được cài đặt trong môi trường, nó sẽ thay đổi môi trường đó và do đó thay đổi các yêu cầu của hệ thống. } Hệ thống PHẢI được bảo trì nếu chúng muốn vẫn còn hữu ích trong một môi trường. 84
85. Các loại bảo trì (Types of maintenance) } Bảo trì sửa chữa lỗi phần mềm } Thay đổi một hệ thống để sửa chữa thiếu sót trong cách đáp ứng các yêu cầu của nó. } Bảo trì để thích nghi phần mềm với một môi trường hoạt động khác } Thay đổi một hệ thống để nó hoạt động trong một môi trường khác (máy tính, hệ điều hành, v.v.) với môi trường triển khai ban đầu. } Bảo trì để bổ sung hoặc sửa đổi chức năng của hệ thống } Sửa đổi hệ thống để đáp ứng các yêu cầu mới. 85
86. Phân phối nỗ lực 3 loại bảo trì (Distribution of maintenance effort) 86
87. Chi phí bả o trì (Maintenance costs) } Thông thường lớn hơn chi phí phát triển (2 * đến 100 * tùy thuộc vào ứng dụng). } Bị ảnh hưởng bởi cả yếu tố kỹ thuật và phi kỹ thuật. } Tăng khi phần mềm được bảo trì. Bảo trì làm hỏng cấu trúc phần mềm nên lần bảo trì sau này sẽ càng khó khăn hơn. } Phần mềm có tuổi thọ cao có thể có chi phí hỗ trợ cao (ví dụ: ngôn ngữ, trình biên dịch cũ v.v.). 87
88. Chi phí phát triển / bảo trì (Development/maintenance costs) 88
89. Các yếu tố chi phí bảo trì (Maintenance cost factors) } Sự ổn định của nhóm (Team stability) } Chi phí bảo trì sẽ giảm xuống nếu cùng nhân viên liên quan đến chúng trong một khoảng thời gian. } Trách nhiệm hợp đồng (Contractual responsibility) } Các nhà phát triển của một hệ thống có thể không có trách nhiệm hợp đồng để bảo trì nên không có động lực để thiết kế cho sự thay đổi trong tương lai. } Kỹ năng nhân viên (Staff skills) } Nhân viên bảo trì thường thiếu kinh nghiệm và có kiến thức miền giới hạn. } Tuổi thọ và cấu trúc chương trình (Program age and structure) } Khi các chương trình có tuổi thọ cao, cấu trúc của chúng bị suy thoái và chúng trở nên khó hiểu và thay đổi. 89
90. Dự báo bả o trì (1/2) (Maintenance prediction) } Dự báo bảo trì liên quan đến việc đánh giá những phần nào của hệ thống có thể gây ra vấn đề và có chi phí bảo trì cao } Thay đổi chấp nhận phụ thuộc vào khả năng bảo trì của các thành phần bị ảnh hưởng bởi sự thay đổi; } Thực hiện thay đổi làm suy giảm hệ thống và giảm khả năng bảo trì; } Chi phí bảo trì phụ thuộc vào số lượng thay đổi và chi phí thay đổi phụ thuộc vào khả năng bảo trì. 90
91. Dự báo bảo trì (2/2) (Maintenance prediction) 91
92. Tóm tắt những điểm chính (Key points) } Phát triển và tiến hóa phần mềm phải là một quá trình lặp. } Luật Lehman mô tả một số hiểu biết sâu sắc trong sự tiến hóa của hệ thống. } Ba loại bảo trì là sửa lỗi, thay đổi phần mềm với một môi trường mới và thực hiện các yêu cầu mới. } Đối với các hệ thống tùy chỉnh, chi phí bảo trì thường vượt quá chi phí phát triển. 92
93. Tài liệu Tham khả o } Giáo trình chính: Software Engineering, Ian Sommerville, 8th Edition, 2007 } Tham khảo: } Object-Oriented Software Engineering Practical Software Development using UML and Java, Lloseng.com, Lethbridge/Laganièr, 2001 } Kỹ nghệ Phần mềm, TS Lê Văn Phùng, Nhà xuất bản thông tin và truyền thông, 2014 } Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm, Phạm Thị Quỳnh 93