Sử dụng mô hình hóa trong quá trình sản xuất phần mềm giúp cho việc xác định các yêu cầu tốt hơn, thiết kế rõ ràng và khả năng bảo trì hệ thống cao hơn. Lược đồ UML cũng được sử dụng ở nhiều dạng khác nhau hỗ trợ từng giai đoạn của quy trình kiểm thử bao gồm đơn vị, chức năng, hệ thống, hồi quy và giải pháp kiểm thử. Bảng dưới đây mô tả sự hỗ trợ của UML trong các giai đoạn kiểm thử phần mềm[11]:
Bảng 3: UML hỗ trợ các loại kiểm thử
Loại kiểm thử Điều kiện áp dụng Loại lỗi Lược đồ UML
Đơn vị Code
Sự đúng đắn, các điều kiện xử lý lỗi trước/ sau, tính bất biến. Lược đồ lớp và trạng thái Chức năng Chức năng hệ thống Hành vi thuộc về chức năng và API, các vấn đề về tích hợp. Lược đồ tương tác và lớp. Hệ thống Các chuỗi vận hành Khả năng làm
việc, giải quyết xung đột, đồng bộ, khôi phục.
Các lược đồ use case, hoạt động và tương tác.
Hồi quy Các chức năng hệ
thống
Hành vi không giống với mong đợi do sự thay đổi
hoặc cập nhật
chức năng mới.
Giống với kiểm thử chức năng
Giải pháp Giao tiếp bên trong hệ thống Các vấn đề vận hành bên trong. Các lược đồ use case và lươc đồ triển khai.
Tuy nhiên, sử dụng UMLvào quy trình kiểm thử cũng gặp phải một số rủi ro. Việc sử dụng lược đồ chỉ trở nên hữu ích trong một số giai đoạn. Có một số vấn đề cần được xem xét trước khi áp dụng UML vào quy trình kiểm thử đó là:
Mô hình hóa thu được trong thiết kế và triển khai có thể được chuyển tới các kiểm thử viên để họ “làm theo”. Điều này là không khả thi bởi vì nó đòi hỏi kiểm thử viên phải có kiến thức sâu rộng để có thể xây dựng, hoặc sửa đổi các mô hình sẽ sử dụng trong quy trình kiểm thử. Các mô hình xây dựng trong bước thiết kế đôi khi là chưa đầy đủ thông tin để tiến hành bước xây dựng kiểm thử tiếp theo.
Thứ hai, các mô hình phát triển thiếu tính chi tiết và các đặc trưng cần có để xây dựng tình huống áp dụng vào kiểm thử.
Có 4 mức kiểm thử ta cần quan tâm đến khi thực hiện quy trình kiểm thử, đó là[12]:
Kiểm thử mức đơn vị
Kiểm thử mức đơn vị liên quan đến việc kiểm thử được thực hiện để kiểm tra tính đúng đắn của từng đơn vị chức năng riêng lẻ. Trong trường hợp này các ngôn ngữ, chức năng hoặc thủ tục có thể thực hiện kiểm thử là ở mức nhỏ nhất. Các dạng kiểm thử đơn vị là cơ sở cho các hoạt động kiểm thử ở mức cao hơn chẳng hạn như việc vận hành các đơn vị tích hợp để đáp ứng yêu cầu thực thi chức năng cụ thể.
Kiểm thử mức tích hợp
Kiểm thử tích hợp phần mềm hướng đối tượng liên quan đến kiểm thử tích hợp các đơn vị với nhau. Kiểm thử tích hợp các cấu phần phần mềm liên quan tới kiểm thử các cấu phần gắn kết với nhau. Công việc tập trung ở mức này chủ yếu là kiểm thử tương tác giữa các đơn vị hoặc cấu phần với nhau trên cơ sở dữ liệu hoặc phần cứng. Kiểm thử mức đơn vị tuyệt đối chỉ liên quan đến cấu phần riêng rẽ hoặc cá nhân đơn vị đó. Chính vì thế mà khi thực hiện kiểm thử mức đơn vị vẫn có khả năng để lọt các lỗi ngớ ngẩn, chẳng hạn như các message pop- up chỉ xuất hiện sau khi tích hợp các đơn vị, hoặc cấu phần với nhau. Do đó, kiểm thử tích hợp là khâu không thể thiếu trong quy trình kiểm thử.
Một số cách tiếp cận kiểm thử cũng được xét đến khi kiểm thử mức hệ thống. Briand và Labiche đề xuất ra cách tiếp cận nhằm sinh các tình huống kiểm thử mức hệ thống. Cách tiếp cận này sử dụng đến các lược đồ use case, lược đồ hoạt động, lược đồ tuần tự để sinh các tình huống kiểm thử.
Kiểm thử mức độ phù hợp
Kiểm thử phần mềm nhằm để thiết lập đầy đủ các yêu cầu đặc tả, xem xét mức độ phù hợp của phần mềm.
Chính vì vai trò của mô hình hóa trong từng giai đoạn của quy trình kiểm thử, tại từng mức kiểm thử là rất quan trọng nên việc áp dụng mô hình vào xây dựng các tình huống kiểm thử là rất hữu ích. Việc mô hình hóa cung cấp ý tưởng cơ bản về kiểm thử và phát triển môi trường kiểm thử. Mỗi ca kiểm thử luôn đòi hỏi một sự xác định nào đó, hoặc ít nhất một sự mô tả hoặc tài liệu minh chứng của những gì đối tượng kiểm thử cần làm. Kiểm thử không dựa trên một sự xác định là hoàn toàn vô nghĩa. Thậm chí kiểm thử hộp trắng, ban đầu nó chỉ tập trung vào cấu trúc code, dựa trên một số sự xác định.
Kiểm thử được tiến hành với một vector đầu vào hệ thống, các sự kiện được kích hoạt kết hợp với các tham số[15]. Tham số bản thân nó cũng là một phần của các tình huống xây dựng kiểm thử. Với mỗi yếu tố đầu vào, chúng ta thực hiện lược đồ tương tác trong mô hình thiết kế để mô tả phản ứng của hệ thống với sự kiện cụ thể.
Bất cứ khi nào thao tác sửa lỗi làm thay đổi hoặc có sự thay đổi ảnh huổng đến luồng kiểm thử hoặc cấu phần đang tiến hành kiểm thử, các hoạt động sau sẽ được lặp đi lặp lại [14]:
Hình 6.Quy trình kiểm thử cấu phần trong hệ thống Bắt đầu Lập kế hoạch kiểm thử cấu phần Đặc tả tình huống kiểm thử cấu phần
Thực hiện kiểm thử trên cấu phần
Ghi nhận kết quả kiểm thử cấu phần (adsbygoogle = window.adsbygoogle || []).push({});
Kiểm tra toàn diện cấu phần
Kết thúc
Trong hoạt đông kiểm thử sử dụng UML ta cần có sự phân biệt như sau:
Kiểm thử dựa trên mô hình - Điều này liên quan đến việc lấy thông tin từ mô hình UML.
Mô hình kiểm thử - Tập trung vào cách để mô hình hóa cấu trúc kiểm thử và hành vi kiểm thử với UML.
a. Kiểm thử dựa trên mô hình [4]
UML thể hiện là một ngôn ngữ ký hiệu đặc tả và kiểm thử là một sự áp dụng hoặc sử dụng các khái niệm của đặc tả. Một tình huống kiểm thử cho một cấu phần bao gồm một hoặc một số phép toán sẽ được gọi trên đối tượng kiểm thử, một điều kiện trước - định nghĩa các ràng buộc trên tham số đầu vào cho đối tượng kiểm thử và trạng thái khởi tạo đối tượng, điều kiện sau - để ràng buộc phép toán đầu ra, định nghĩa trạng thái cuối của đối tượng sau thực thi kiểm thử. Chúng ta có thể ánh xạ các cấu phần tới các tình huống kiểm thử cấu phần một
cách chính xác. Trong kiểm thử, hoạt động xác thực được thực hiện nhằm xác định xem tình huống kiểm thử đó là thành công hay thất bại, từ đó đưa ra kết luận kiểm thử. Khái niệm tình huống kiểm thử có một chút phức tạp hơn, nhưng hồ sơ kiểm thử UML định nghĩa chúng một cách đầy đủ. Như vậy UML cung cấp mọi thứ cần thiết để thực hiện kiểm thử và xây dựng tình huống kiểm thử,
thậm chí nó cung cấp đầy đủ thông tin để định nghĩa các tập kiểm thử ứng dụng:
Hình 7. Lược đồ biểu diễn cấu trúc một ca kiểm thử
Tình huống kiểm thử
Điều kiện trước Thao tác Điều kiện sau
Tham số đầu vào Tham số Tham số đầu ra
Trạng thái Ràng buộc Ràng buộc Định nghĩa Định nghĩa 1 1 1 * 1 * 1 1
Ví dụ: Trong hệ thống quản lý giao dịch thẻ ATM sẽ có các use case tham gia như sau:
Hình 8. Lược đồ biểu diễn các use case quản lý giao dịch ATM
Khách hàng Hệ thống
Rút tiền từ tài khoản
Gửi tiền vào tài khoản
Kiểm tra tài khoản khách hàng
Kiểm tra loại thẻ giao dịch
Kiểm tra số dư tài khoản Cập nhật tài khoản khách hàng «uses» «uses» «uses» Đăng nhập hệ thống «extends»
Với từng tình huống cụ thể (tình huống rút tiền từ tài khoản ATM của khách hàng), cấu trúc mỗi tình huống được thể hiện như bảng dưới đây:
Tình huống Mô tả
Mô tả Người dùng thực hiện giao dịch rút tiền từ tài khoản cá nhân.
Thao tác Người dùng nhập số tiền cần rút khỏi tài khoản.
Điều kiện trước Hệ thống chấp nhận thẻ giao dịch của khách. Tài khoản đăng nhập của người dùng là hợp lệ.
Điều kiện sau Nếu thành công: Giao dịch rút tiền thành công. Hệ thống trừ tiền tài khoản của khách.
Nếu không thành công: Hệ thống thông báo tới khách hàng nguyên nhân thực hiện giao dịch không thành công.
Tham số đầu vào Tài khoản chủ thẻ ATM. (adsbygoogle = window.adsbygoogle || []).push({});
Tham số thực hiện giao dịch
Số tiền khách tực hiện giao dịch.
Tham số đầu ra Số tiền giao dịch cập nhật hệ thống sau giao dịch.
b. Mô hình kiểm thử: Tập các tình huống kiểm thử biểu diễn phần mềm thực thi. Bất cứ phần mềm nào, khi nó thực hiện một “chức năng thông thường”, hoặc
theo cách nào đó nó đánh giá được phần mềm khác đều phải dựa trên đặc tả. UML là một ngôn ngữ ký hiệu đặc tả đồ họa, và như thế nó cũng tập trung cho đặc tả của phần mềm kiểm thử trong ứng dụng. Tại sao chúng ta phải áp dụng ngôn ngữ ký hiệu đặc tả vào kiểm thử? Câu trả lời cho câu hỏi này chính là: sử dụng ngôn ngữ kí hiệu đặc tả để thấy được sự khác biệt của phát triển phần mềm thông qua mô hình hóa với việc phát triển phần mềm tự do.
UML cung cấp mọi thứ cần thiết để nhận được khung kiểm thử cho các cấu phần hoặc cho các đối tượng trong ứng dụng. Tuy nhiên, có một số khái niệm đặc biệt quan trọng với kiểm thử. Các khái niệm này được cung cấp bởi hồ sơ kiểm thử UML. Hồ sơ kiểm thử mở rộng mô hình siêu dữ liệu UML với cách thức kiểm thử và khái niệm kiểm thử. Thực chất, các lược đồ UML đặc tả cách thực thi hệ thống, cách hoạt động của hệ thống, và cách thức nhận dạng hệ thống. Mô hình UML đặc tả đủ và đúng hệ thống đó. Hồ sơ kiểm thử mở rộng siêu mô hình UML với các khung kiểm thử và khái niệm kiểm thử.
UML có thể được sử dụng để đặc tả bất kỳ khía cạnh nào của một hệ thống máy tính, và kiểm thử được dựa trên các tài liệu đặc tả mô tả chức năng đó. Kiểm thử xác thực xem việc cài đặt hệ thống có tuân theo một cách chính xác những gì đặc tả đã đưa ra. Bởi vì, các mô hình thể hiện ở mức trừu tượng, bất cứ những gì mà ta áp dụng đều ở mức cụ thể hóa (bằng code) đều có thể được thể hiện ở mức trừu tượng, dạng mô hình. Sự khác nhau chủ yếu ở các mô hình đó là nó thể hiện cụ thể hơn một đặc tả, từ đó đưa ra được các tình huống kiểm thử cụ thể, và các thể hiện trừu tượng của đặc tả cũng sẽ đưa đến mức độ kiểm thử một cách bao quát hơn.
Điều kiện kiểm thử trên cơ sở mô hình và các ca kiểm thử cụ thể mà chúng ta có, thu được từ một lược đồ UML. Các lược đồ thể hiện ở mức cao dẫn tới tình huống kiểm thử xây dựng ở mức cao - mô hình use case ánh xạ tới các mục tiêu kiểm thử, với các lược đồ mức thấp dẫn đến các tình huống cụ thể kiểm thử ở mức thấp - mô hình hành vi hướng đến các tình huống kiểm thử. Trong tương lai, chúng ta sẽ có thể mở rộng việc tự động hóa mức kiểm thử từ các mô hình dựa vào các công cụ tích hợp. Kiểm thử trên cơ sở mô hình và việc mô hình hóa kiểm thử thực tế là các hoạt động trực giao, hỗ trợ cho nhau. Kiểm thử thực chất chỉ là công việc phát triển và thực thi phần mềm.
Một cách lý tưởng, kiểm thử nên chỉ ra tất cả những điểm làm hệ thống thất bại, nhưng nhìn chung điều đó là không thể. Trên thực tế, ta không bao giờ có thể chờ để triển khai một ứng dụng không còn lỗi, thập chí nếu kỹ thuật đảm bảo chất lượng được nâng cao, được áp dụng trong suốt quá trình phát triển và tích
hợp. Nguyên tắc của kiểm thử chất lượng dịch vụ là đưa ra ứng dụng trên cơ sở cấu phần chấp nhận được.
Trọng tâm của mô hình cấu phần chính là lược đồ tương tác cấu phần. Các chiến lược kiểm thử được rút ra từ việc sử dụng các lược đồ đó. Để xây dựng lược đồ tương tác cấu phần (CIG - Component Interaction graph) cho một hệ thống phần mềm trên cơ sở cấu phần, các phần tử của mô hình cần được định nghĩa trong hệ thống. Sự thách thức lớn nhất trong hoạt động này chứa thông tin cần thiết về thành phần thứ ba cung cấp mã nguồn. Trong khi xây dựng lược đồ tích hợp cấu phần cho phần mềm trên cơ sở cấu phần được đưa ra, một số phần tử có thể được định nghĩa theo cách sử dụng thông tin đã tồn tại trước, trong khi các phần tử khác có thể chỉ đạt được dựa trên các quy trình xử lý trước. Các phần tử đó được định nghĩa là các nút giao diện, và sự kiện, hay thành phần điều khiển giữa các nút sự kiện và các phụ thuộc nội dung giữa các giao diện. CORBA, EJB/J2EE, và COM/DCOM/.NET là các kỹ thuật phổ biến nhất trong việc phát triển phần mềm trên cơ sở cấu phần hiện nay. Mỗi kỹ thuật đều có các đặc trưng nhất định. Như vậy, các cách tiếp cận khác nhau là cần thiết khi xây dựng các CGI khác nhau. Ở đây, chúng ta đề cập đến cách để tạo ra một CGI
cho mỗi phần tử kiểm thử.