nhiều hàm hoặc đối tượng khác nhau. Những thành phần kết hợp này có giao thức được định nghĩa để sử dụng truy cập tất cả các chức năng của từng thành phần.
_Những hàm riêng hoặc phương thức được xem đơn giản nhất trong mỗi thành phần và thử nghiệm của bạn sẽ là tập hợp các cuộc gọi đến những hàm này với các thông số đầu vào khác nhau. Bạn có thể sử dụng những phương pháp tiếp cận để thiết kế những phép kiểm thử để thiết kế phép kiểm tra các hàm chức năng hoặc phương thức.
_ Khi bạn đang thử nghiệm các lớp đối tượng, bạn nên thiết kế phép kiểm tra của mình phải bảo đảm kiểm tra đầy đủ tất cả các chức năng của đối tượng đó. Theo đó, việc kiểm tra lớp đối tượng bao gồm:
1/ Các phép kiểm thử diễn ra trong sự độc lập với toàn bộ hoạt động liên kết với đối tượng.
2/ Kiểm thử các thiết lập và truy vấn của toàn bộ thuộc tính liên kết với đối tượng.
3/ Tất cả các sự kiện có thể làm thay đổi giá trị của đối tượng đều phải được mô phỏng.
Xem xét cho ví dụ ở chương 14 có hình minh họa 23.6. Nó chỉ có 1 thuộc tính đơn để nhận dạng. Nó là 1 hằng số được thiết lập khi trạm thời tiết được cài đặt. Vì vậy bạn chỉ cần kiểm tra xem hằng số đó đã được thiết lập hay chưa. Bạn cần phải xác định những ca kiểm thử cho những bài báo cáo, hiệu chỉnh, khởi động và tắt. Thông thường các bài kiểm thử sẽ diễn ra độc lập giữa các phương thức, nhưng trong một số trường hợp thì khác. Ví dụ như khi muốn kiểm tra chức năng tắt thì trước hết ta phải khởi động mới kiểm tra tiếp được.
Để kiểm tra trạng thái của trạm khí tượng, bạn sử dụng mô hình 14.14. Sử dụng mô hình này, bạn có thể xác định được trình tự thay đổi của các trạng thái đã được đưa vào kiểm tra và xác định được chuỗi sự kiện để khiến chúng có sự thay đổi trên. Về nguyên tắc, bạn nên kiểm tra từng quá trình thay đổi của từng trạng thái, nhưng trong thực tế kinh phí sẽ rất tốn kém. Một số ví dụ về các trình tự kiểm thử trong ví dụ trạm khí tượng :
Tắt → Đợi xử lý → Tắt.
Đợi → Hiệu chỉnh → Kiểm tra → Chuyển trạng thái → Đợi
Đợi → Thu thập thông tin → Đợi → sơ lược → Chuyển trạng thái → Đợi
• Nếu sử dụng tính thừa kế, thì điều này sẽ làm cho việc thiết kế các bài kiểm tra lớp đối tượng trở nên khó khăn hơn. Nơi mà một lớp được cung cấp các hoạt động được thừa kế bởi một số các lớp con khác, thì khi kiểm tra đến lớp đó ta phải kiểm tra toàn bộ các lớp mà nó đã thừa kế. Nguyên nhân của việc kiểm tra tất cả các lớp mà nó thừa kế là vì khi di truyền các phương thức thì trong một số trường hợp giả định nó sẽ làm thay đổi các họat động cũng như phương thức của các lớp khác.
Tương tự khi một lớp thừa kế bị ghi đè bởi một phương thức hay thuộc tính khác thì nó phải được kiểm tra lại.
_ Khái niệm về lớp tương đương, được đề cập trong phần 23.3.2, cũng có thể áp dụng cập trong phần 23.3.2, cũng có thể áp dụng trong các lớp đối tượng. Các bài kiểm thử rơi trúng vào cùng lớp tương đương có thể sử dụng cùng một thuộc tính của đối tượng. Vì vậy, các lớp tương đương phải được xác định từ những bước khởi tạo, truy nhập, và câp nhật trong tất cả các thuộc tính của lớp đối tượng.
_ Nhiều phần trong hệ thống có những phương thức rất phức tạp hoặc những đối tượng kết hợp với nhau tạo ra nhiều mối ảnh hưởng liên tiếp. Như đã được đề cập ở chương 19, những chức năng được bao bọc bởi những kỹ thuật lập trình, và mình chỉ tiếp cận với những chức năng đó hoàn toàn thông qua những giao diện đã được xác định trước. Việc kiểm tra những thành phần kết hợp này liên quan chính thống với việc kiểm tra thành phần giao diện ứng xử theo đặc điểm kỹ thuật của chúng.
_ Bước kiểm tra giao diện này là đặc biệt quan trọng trong hướng đối tượng và trong các bước thiết kế các thành phần cơ bản khác. Những thành phần và đối tượng được định nghĩa trước trong giao diện của chúng và có thể sử dụng lại để kết hợp tạo nên các thành phần khác trong hệ thống. Lỗi giao diện trong những thành phần kết hợp thì không thể phát hiện bằng cách kiểm thử các đối tượng riêng biệt hoặc các thành phần riêng biệt. Những lỗi có trong những thành phần kết hợp có thể sẽ phát sinh do tính thừa kế giữa các phần đã kết hợp với nhau.
_ Có nhiều loại giao diện trong các thành phần chương trình nên kết quả sẽ tạo ra nhiều loại lỗi giao diện phát sinh, một số loại giao diện:
1/ Giao diện hằng số
2/ Giao diện chia sẻ bộ nhớ 3/ Giao diện thủ tục
4/ Giao diện gửi thông điệp.
_ Những lỗi giao diện thường được coi như là những lỗi phức tạp nhất của hệ thống. Thường rơi vào 3 trường hợp: 1/ Lạm dụng giao diện( interface misuse)
2/ Gọi sai giao diện( interface misunderstanding). 3/ Timing errors.
_ Việc kiểm thử những thiếu sót trong giao diện là khó vì những lỗi giao diện này thường lộ ra trong những điều kiện khác thường. Ví dụ, một đối tượng sử dụng hàng đợi queue với cấu trúc dữ liệu đã thiết kế sẵn. Mà một đối tượng khác gọi đến và sử dụng queue này nhưng không kiểm tra xem queue có rỗng không mà đưa dữ liệu vào sẽ dẫn đến lỗi. Lỗi này chỉ được phát hiện khi ta đem so kết quả kiểm thử với kết quả chứa trong queue.
_Những sự cố khác sẽ nảy sinh bởi sự ảnh hưởng lẫn nhau giữa các bộ phận và đối tượng. Những lỗi của một đối tượng có thể phát hiện khi một đối tượng khác xử lý sai. Ví dụ như khi một đối tượng cần xử lý thông tin và gọi cho một đối tượng khác có chức năng xử lý thông tin đó và trả về kết quả sai.
Mục đích của quy trình thiết kế kiểm thử là tạo ra 1 bộ các ca kiểm thử hiệu quả trong việc phê chuẩn và kiểm thử sai sót.
Những phương pháp tiếp cận để thiết kế kiểm thử: 1.Kiểm thử dựa trên yêu cầu-Requirements-based
testing
2.Kiểm thử phân vùng-Patition testing. 3.Kiểm thử cấu trúc-Structural testing.
_ Nguyên tắc kiểm thử chung của các yêu cầu kĩ thuật là yêu cầu đó phải khả thi trong việc kiểm thử.
_ Kiểm thử dựa trên yêu cầu là một kỹ thuật kiểm thử phê chuẩn. Xem xét mỗi yêu cầu và tạo ra kiểm thử cho yêu cầu đó.
_ Xem xét yêu cầu trong ví dụ LIBSYS.
LIBSYS requirements
+ Người dùng có thể tìm thấy các thiết lập gốc trong database và chọn một phần nhỏ trong đó.
+ Hệ thống sẽ cung cấp góc nhìn thích hợp cho người dùng để đọc những tài liệu trong kho dữ liệu
+ Mỗi yêu cầu sẽ được cấp một định dạng (Order_ID) mà người dùng có thể sao chép vào khu dữ liệu.
LIBSYS Test
_ Khởi đầu việc tìm kiếm của người dùng là xác định xem phần đó có tồn tại hay không trong tập hợp cơ sở dữ liệu bao gồm một cơ sở dữ liệu.
_ Khởi nguồn việc tìm kiếm của người dùng là xác định xem phần đó có tồn tại hay không trong tập hợp cơ sở dữ liệu bao gồm hai cơ sở dữ liệu.
_ Bắt đầu việc tìm kiếm của người dùng là xác định xem phần đó có tồn tại hay không trong tập hợp cơ sở dữ liệu bao gồm hơn hai cơ sở dữ liệu.
_ Chọn một cơ sở dữ liệu và một cuộc tìm kiếm của người dùng và xác định chúng có tồn tại hay không.
_ Chọn nhiều hơn một cơ sở dữ liệu và nhiều cuộc tìm kiếm hơn của người dùng và xác định chúng có tồn tại hay không.
_ Bạn có thể thấy việc kiểm thử yêu cầu không có nghĩa là chỉ viết một ca kiểm thử cho yêu cầu đó mà bạn phải nhiều ca kiểm thử cho một yêu cầu mới có thể khái quát được yêu cầu đó.
_ Kiểm thử yêu cầu trong hệ thống LIBSYS có thể được phát triển bằng phương pháp như vậy. Ở yêu cầu thứ 2, bạn sẽ viết kiểm thử để phân phối tài liệu cho hết các kiểu mà hệ thống xử lý và bảo đảm chúng phải được hiển thị. Yêu cầu thứ ba thì đơn giản hơn. Để kiểm thử yêu cầu này, bạn có thể mô phỏng đặt yêu cầu và xem chúng có được hệ thống nhận dạng và có hiện diện trong bản xác nhận của người dùng và có tồn tại duy nhất không.
Còn được gọi là kiểm thử hộp trắng.
Nguồn gốc của các ca kiểm thử là dựa theo cấu trúc của chương trình. Hiểu biết chương trình thì có thể xác định được các ca kiểm thử.
Mục đích là kiểm thử tất cả các câu lệnh của chương trình.
D li u ữ ệki m thể ử