OOAD - Kiểm tra & Đảm bảo Chất lượng

Một khi mã chương trình được viết, nó phải được kiểm tra để phát hiện và sau đó xử lý tất cả các lỗi trong đó. Một số chương trình được sử dụng cho mục đích thử nghiệm.

Một khía cạnh quan trọng khác là tính phù hợp về mục đích của chương trình xác định liệu chương trình có phục vụ mục đích mà nó hướng tới hay không. Sự phù hợp xác định chất lượng phần mềm.

Kiểm tra hệ thống hướng đối tượng

Kiểm thử là một hoạt động liên tục trong quá trình phát triển phần mềm. Trong các hệ thống hướng đối tượng, kiểm thử bao gồm ba cấp độ, đó là kiểm thử đơn vị, kiểm thử hệ thống con và kiểm thử hệ thống.

Kiểm tra đơn vị

Trong kiểm tra đơn vị, các lớp riêng lẻ được kiểm tra. Nó được xem liệu các thuộc tính lớp có được triển khai theo thiết kế hay không và liệu các phương thức và giao diện có không bị lỗi hay không. Kiểm thử đơn vị là trách nhiệm của kỹ sư ứng dụng, người triển khai cấu trúc.

Kiểm tra hệ thống con

Điều này liên quan đến việc kiểm tra một mô-đun cụ thể hoặc một hệ thống con và là trách nhiệm của người dẫn đầu hệ thống con. Nó liên quan đến việc kiểm tra các liên kết bên trong hệ thống con cũng như sự tương tác của hệ thống con với bên ngoài. Kiểm tra hệ thống con có thể được sử dụng như kiểm tra hồi quy cho mỗi phiên bản mới được phát hành của hệ thống con.

Thử nghiệm hệ thống

Kiểm thử hệ thống bao gồm việc kiểm tra toàn bộ hệ thống và là trách nhiệm của nhóm đảm bảo chất lượng. Nhóm thường sử dụng các bài kiểm tra hệ thống làm bài kiểm tra hồi quy khi lắp ráp các bản phát hành mới.

Kỹ thuật kiểm tra hướng đối tượng

Kiểm tra hộp xám

Các loại trường hợp kiểm thử khác nhau có thể được thiết kế để kiểm thử các chương trình hướng đối tượng được gọi là trường hợp kiểm thử hộp xám. Một số loại kiểm tra hộp xám quan trọng là:

State model based testing - Điều này bao gồm phạm vi bao phủ trạng thái, phạm vi chuyển đổi trạng thái và bao phủ đường chuyển đổi trạng thái.
Use case based testing - Mỗi kịch bản trong mỗi ca sử dụng đều được kiểm tra.
Class diagram based testing - Mỗi lớp, lớp dẫn xuất, các liên kết và tập hợp được kiểm tra.
Sequence diagram based testing - Các phương pháp trong thông báo trong biểu đồ trình tự được kiểm tra.

Kỹ thuật kiểm tra hệ thống con

Hai cách tiếp cận chính của kiểm tra hệ thống con là:

Thread based testing - Tất cả các lớp cần thiết để thực hiện một ca sử dụng duy nhất trong hệ thống con đều được tích hợp và thử nghiệm.
Use based testing- Các giao diện và dịch vụ của các mô-đun ở mỗi mức phân cấp được kiểm tra. Kiểm tra bắt đầu từ các lớp riêng lẻ đến các mô-đun nhỏ bao gồm các lớp, dần dần đến các mô-đun lớn hơn, và cuối cùng là tất cả các hệ thống con chính.

Hạng mục Kiểm tra hệ thống

Alpha testing - Điều này được thực hiện bởi nhóm kiểm thử trong tổ chức phát triển phần mềm.
Beta testing - Việc này được thực hiện bởi một số nhóm khách hàng hợp tác được chọn.
Acceptance testing - Việc này được khách hàng thực hiện trước khi nhận hàng.

Đảm bảo chất lượng phần mềm

Chất lượng phần mềm

Schulmeyer và McManus đã định nghĩa chất lượng phần mềm là “sự phù hợp để sử dụng toàn bộ sản phẩm phần mềm”. Một phần mềm chất lượng tốt thực hiện chính xác những gì nó được cho là phải làm và được giải thích theo nghĩa sự thỏa mãn của đặc tả yêu cầu do người dùng đặt ra.

Đảm bảo chất lượng

Đảm bảo chất lượng phần mềm là một phương pháp xác định mức độ phù hợp để sử dụng một sản phẩm phần mềm. Các hoạt động được bao gồm để xác định chất lượng phần mềm là:

Auditing
Phát triển các tiêu chuẩn và hướng dẫn
Sản xuất báo cáo
Xem xét hệ thống chất lượng

Yếu tố chất lượng

Correctness - Tính đúng đắn xác định liệu các yêu cầu phần mềm có được đáp ứng một cách thích hợp hay không.
Usability - Khả năng sử dụng xác định liệu phần mềm có thể được sử dụng bởi các nhóm người dùng khác nhau (người mới bắt đầu, không chuyên về kỹ thuật và chuyên gia) hay không.
Portability - Tính di động xác định liệu phần mềm có thể hoạt động trên các nền tảng khác nhau với các thiết bị phần cứng khác nhau hay không.
Maintainability - Khả năng bảo trì xác định mức độ dễ dàng mà các lỗi có thể được sửa chữa và các mô-đun có thể được cập nhật.
Reusability - Khả năng tái sử dụng xác định liệu các mô-đun và lớp có thể được sử dụng lại để phát triển các sản phẩm phần mềm khác hay không.

Chỉ số hướng đối tượng

Số liệu có thể được phân loại rộng rãi thành ba loại: số liệu dự án, số liệu sản phẩm và số liệu quy trình.

Số liệu dự án

Project Metrics cho phép người quản lý dự án phần mềm đánh giá trạng thái và hiệu suất của một dự án đang thực hiện. Các số liệu sau thích hợp cho các dự án phần mềm hướng đối tượng:

Số lượng kịch bản kịch bản
Số lớp chính
Số lớp hỗ trợ
Số lượng hệ thống con

Chỉ số sản phẩm

Số liệu sản phẩm đo lường các đặc điểm của sản phẩm phần mềm đã được phát triển. Các chỉ số sản phẩm phù hợp với hệ thống hướng đối tượng là:

Methods per Class- Nó quyết định độ phức tạp của một lớp. Nếu tất cả các phương thức của một lớp được giả định là phức tạp như nhau, thì một lớp có nhiều phương thức sẽ phức tạp hơn và do đó dễ bị lỗi hơn.
Inheritance Structure- Hệ thống có một số mạng kế thừa nhỏ có cấu trúc tốt hơn hệ thống có một mạng kế thừa lớn. Theo quy tắc ngón tay cái, cây thừa kế không được có nhiều hơn 7 (± 2) số cấp và cây phải cân bằng.
Coupling and Cohesion - Các mô-đun có khớp nối thấp và tính liên kết cao được coi là thiết kế tốt hơn, vì chúng cho phép khả năng tái sử dụng và khả năng bảo trì cao hơn.
Response for a Class - Nó đo lường hiệu quả của các phương thức được gọi bởi các thể hiện của lớp.

Số liệu quy trình

Chỉ số quy trình giúp đo lường hiệu suất của một quy trình. Chúng được thu thập trên tất cả các dự án trong thời gian dài. Chúng được sử dụng làm chỉ báo cho các cải tiến quy trình phần mềm dài hạn. Một số chỉ số quy trình là -