CHƢƠNG 2 KỸ THUẬT LÀM TĂNG TÍNH KHẢ KIỂM THỬ
2.1 Tính khả kiểm thử của tài liệu đặc tả
Một trong những giai đoạn đầu của thiết kế phần mềm là mô tả yêu cầu kỹ thuật. Yêu cầu kỹ thuật mô tả các chức năng hệ thống phải thực hiện, các đặc điểm đáng chú ý về và cần thiết của hệ thống, các ràng buộc về hoạt động của hệ thống và quy trình phát triển phần mềm.
Chú ý là có hai mức độ yêu cầu là yêu cầu ngƣời dùng (user requirements) và yêu cầu hệ thống (system requirements). Yêu cầu ngƣời dùng mô tả rõ ràng về những gì hệ thống nên làm. Còn yêu cầu hệ thống mở rộng yêu cầu ngƣời dùng, mô tả chức năng hệ thống một cách chi tiết và súc tích hơn, kỹ
thuật hơn. Tuy nhiên, nó vẫn chỉ mô tả chức năng và các ràng buộc nhìn từ phía ngoài của hệ thống chứ chƣa nêu chi tiết cần cài đặt nhƣ thế nào.
Các yêu cầu hệ thống này có thể đƣợc viết bằng các đặc tả ngôn ngữ có cấu trúc, sử dụng các biểu mẫu với các trƣờng dữ liệu chuẩn. Ngoài ra, tài liệu yêu cầu hệ thống còn thƣờng mô tả các trƣờng hợp/ca sử dụng (use case) và biểu đồ tuần tự. Tài liệu này là đặc tả yêu cầu phần mềm (SRS - Software Requirements Specification).
Các yêu cầu hệ thống thƣờng không đƣợc sử dụng để thiết kế và cài đặt phần mềm ngay, mà trƣớc khi đó chúng ta cần kiểm tra/kiểm thử tính đúng đắn và chất lƣợng của chúng, để các việc phát triển sau đó đƣợc thuận lợi hơn. Do đó để tăng tính khả kiểm thử, các tài liệu yêu cầu cần được viết rõ ràng, không mơ hồ để tránh bị ngƣời lập trình và ngƣời thiết kế hiểu sai hay hiểu không giống nhau.
Nghiên cứu cũng khuyến cáo kiểm thử viên nên đƣợc tham gia ở pha thu thập tài liệu yêu cầu để giúp cho việc đặc tả các yêu cầu đƣợc rõ ràng hơn vì ở giai đoạn này. Các kỹ sƣ kiểm thử thƣờng giúp phát hiện các thiếu sót trong yêu cầu mà có thể ảnh hƣởng đến việc kiểm thử ở giai đoạn sau.
Với các qui trình phát triển hiện đại ngày nay ngƣời ta thƣờng lấy các ví dụ trong qua trình thu thập yêu cầu để sử dụng chúng làm ca kiểm thử. Các ví dụ này cũng giúp cả ngƣời khách hàng và đội phát triển cùng hiểu đúng yêu cầu cần đạt của các chức năng phần mềm. Theo phƣơng pháp phát triển hƣớng hành vi [8] (BDD -behaviour driven development) ngƣời ta còn sử dụng một ngôn ngữ chuyên dụng là gherkin3 để viết các kịch bản làm ví dụ cho các tính năng của sản phẩm nhƣ ví dụ sau.
Ở ví dụ này tính năng quản lý tài khoản (Password mangement) có một kịch bản (ví dụ) khi ngƣời sử dụng có email cukes@cukes.info quên mật khẩu và chọn chức năng reset thì hệ thống sẽ gửi email với link để đặt lại mật khẩu mới cho ngƣời dùng.
Thông thƣờng một tính năng (feature) này có thể có nhiều kịch bản (scenario) chính là các ví dụ hay tƣơng đƣơng một ca kiểm thử. Theo cách này chúng ta vừa sử dụng mô tả này làm tài liệu yêu cầu, đồng thời cũng sử dụng nó để viết kiểm thử chấp nhận hay kiểm thử chức năng ở mức ngƣời sử dụng và chúng sẽ đƣợc chạy tự động.
Lỗi về giao diện phần mềm (không phải giao diện ngƣời dùng) là một trong những vấn đề phổ biến nhất trong quá trình xây dựng phần mềm. Do đó chúng ta cần tập trung đặc biệt vào đặc tả giao diện khi xây dựng đặc tả yêu cầu kỹ thuật. Đặc tả giao diện phải đƣợc mô tả rõ ràng trong tài liệu đặc tả yêu cầu. Đặc tả giao diện bao gồm: các đặc tả thủ tục/hàm (giao diện lập trình ứng dụng, API) và các cấu trúc dữ liệu. Giao diện phải đƣợc đặc tả cho cả hệ thống đang thiết kế và các hệ thống đã có mà sẽ tƣơng tác với hệ thống này.
Các yêu cầu đƣợc sử dụng để tạo ra các artifact nhƣ thiết kế, cài đặt, các ca kiểm thử, v.v. Nếu chúng ta lƣu giữ thông tin yêu cầu nào đƣợc thể hiện ở trong artifact nào thì việc này giúp chúng lần xuôi, và lần ngƣợc lại giữa các artifact để kiểm tra xem thiết kế có phù hợp với yêu cầu. Tƣơng tự, chúng ta có thể biết mô-đun nào cài đặt yêu cầu nào theo thiết kế nào. Khái niệm này gọi là khả năng truy vết (traceability). Khả năng truy vết là cơ sở để kiểm tra chất lƣợng sản phẩm và là phƣơng tiện để chứng minh rằng các yêu cầu đã đƣợc
Feature: Password management Scenario: Forgot password
Given a user with email "cukes@cukes.info" exists When I ask for a password reset
hiểu rõ, tuân thủ và không có các tính năng/chức năng thừa, không cần thiết. Khả năng truy vết cho biết các ca kiểm thử đã đƣợc tạo ra ở giai đoạn mô tả yêu cầu có thể đƣợc thực hiện trên phần mềm. Nói cách khác, khả năng truy vết hỗ trợ đắc lực cho việc tăng tính khả kiểm thử của hệ thống.
2.2 Tính khả kiểm thử của thiết kế kiến trúc
Kiến trúc phần mềm của một hệ thống tính toán là cấu trúc tổng thể của hệ thống, bao gồm các thành phần của hệ thống, các quan hệ/liên kết giữa các thành phần đó và các thuộc tính có thể quan sát từ bên ngoài của các thành phần và các liên kết đó [9]. Kiến trúc tập trung giải quyết các yêu cầu chất lƣợng nhƣ hiệu năng (performance), tính dễ dùng (usability), độ an toàn (security), của hệ thống. Tính khả kiểm thử cũng là một trong các thuộc tính chất lƣợng của hệ thống phần mềm.
Thông thƣờng ngƣời khách hàng không đƣa ra đƣợc các yêu cầu thuộc tính chất lƣợng cụ thể chính xác. Việc này sẽ gây khó khăn khi bàn giao, nghiệm thu sản phẩm. Do đó khi xác định yêu cầu chất lƣợng ngƣời ta sử dụng các kịch bản thuộc tính chất lƣợng. Một kịch bản thuộc tính chất lƣợng là một yêu cầu chất lƣợng cụ thể, nó thƣờng gồm sáu yếu tố sau đây: tác động, nguồn tác động, môi trƣờng, thành phần của hệ thống (artifact), phán ứng cần có, lƣợng hóa phản ứng bằng giá trị cụ thể. Ví dụ về một kịch bản thuộc tính chất lƣợng khả năng kiểm thử nhƣ trong Bảng 1 hay tƣơng đƣơng là Hình 4 [9].
Ví dụ này nói rằng trong giai đoạn phát triển (development), khi ngƣời thực hiện kiểm thử đơn vị (unit tester) hoàn thành mã (code unit completed) và thực hiện việc chạy kiểm thử thì kết quả kiểm thử phải chạy xong trong 3 giờ và bao phủ 85% số đƣờng đi trong chƣơng trình.
Môi trƣờng Môi trƣờng phát triển Nguồn kích thích Ngƣời làm kiểm thử đơn vị Kích thích Hoàn thành mã kiểm thử Sản phẩm (artifact) Đơn vị chƣơng trình Phản ứng Ghi lại kết quả kiểm thử
Đo phản ứng Chạy trong 3 giờ và bao phủ 85% đƣờng đi.
Bảng 1 Kịch bản thuộc tính chất lượng dạng bảng
Đạt đƣợc các thuộc tính chất lƣợng phụ thuộc vào việc áp dụng các chiến thuật thiết kế. Hình 5 liệt kê các chiến thuật giúp làm tăng tính khả kiểm thử [9]. Các chiến thuật khả kiểm đƣợc chia thành hai loại: kiểm soát và quan sát trạng thái hệ thống và giảm độ phức tạp hệ thống.
Hình 5 Các chiến thuật khả kiểm thử
Chiến thuật giao diện đặc biệt (specialized interfaces): Việc sử dụng các giao diện đặc biệt cho phép tách biệt giao diện và chi tiết cài đặt của thành phần, giúp kiểm thử dựa trên giao diện sẽ ổn định và độc lập với thay đổi bên trong của thành phần. Giao diện kiểm thử có thể đƣợc khai báo và dùng lại ở nhiều thành phần khác nhau giúp việc tƣơng tác với giao diện khi kiểm thử cũng có thể sử dụng lại đƣợc.
Chiến thuật ghi và lặp lại (capture/playback): ghi lại thông tin đƣợc truyền vào qua giao diện. Thông tin đƣợc ghi, lƣu trữ và sử dụng với hai mục đích: để so sánh với đầu ra của thành phần ở giai đoạn sau và để cung cấp đầu vào cho thành phần khác.
Chiến thuật cục bộ hóa lưu trữ: lƣu các dữ liệu phân tán vào ổ cứng của máy chạy kiểm thử để dễ kiểm soát, xem xét thông tin đƣợc dễ dàng.
Chiến thuật trừu tượng nguồn dữ liệu: cho phép thay đổi cơ sở dữ liệu dễ dàng để có thể sử dụng cơ sở dữ liệu kiểm thử riêng thay vì phải sử dụng cơ sở dữ liệu thật.
Chiến thuật hộp cát: cho hệ thống chạy trong một hệ thống cô lập mô phỏng đúng hệ thống trên thực tế. Ví dụ sử dụng máy ảo trong lập trình trên điện thoại di động Android là đã áp dụng chiến thuật này.
Chiến thuật chèn mã kiểm tra: đây là cách chèn thêm các đoạn mã khẳng định tính chất của các biến trong chƣơng trình thông qua các công thức logic. Ví dụ khi tính toán một biến xong ta biết nó phải là số dƣơng, thì ta có thể chèn lệnh (ví dụ assert trong Java) để khẳng định công thức logic đó phải đúng. Khi chƣơng trình chạy sẽ kiểm tra giá trị của công thức này và nếu sai thì dừng chƣơng trình hoặc in các thông báo cho ngƣời sử dụng hoặc ghi vào file log lỗi.
Chiến thuật hạn chế phức tạp cấu trúc: là kỹ thuật chia nhỏ các cấu trúc phức tạp thành các cấu trúc con để giảm độ phức tạp của từng phần. Ví dụ một lớp có quá nhiều trƣờng cần tách thành các lớp nhỏ hơn, một bảng có quá nhiều trƣờng cũng có thể chia thành các bảng nhỏ hơn, một mô-đun quá lớn cũng cần chia nhỏ hơn, hay mức độ lồng nhau của các thành phần trong một hệ thống quá lớn thì cần chia thành các hệ thống nhỏ hơn để hạn chế độ phức tạp về chiều sâu.
Chiến thuật hạn chế tính không đơn định (non-deterministic): Khi hệ thống có thể chạy theo nhiều cách khác nhau không phụ thuộc vào ngữ cảnh, ví dụ khi hai luồng chạy độc lập thì có nhiều khả năng chạy xen kẽ nhau nên ví dụ chúng cùng in kết quả ra màn hình thì mỗi lần chạy có thể cho ra các kết quả khác nhau. Việc này gây khó khăn khi có lỗi cũng khó lặp lại (reproduce) lỗi đó để điều tra.
Cuối cùng, ngoài việc áp dụng các chiến thuật, khi xây dựng một phần mềm, ngƣời ta thƣờng sử dụng một số mẫu kiến trúc có sẵn và chỉnh sửa thêm cho phù hợp với yêu cầu bài toán hoặc kết hợp với một số mẫu kiến trúc khác.
Khi này ngƣời thiết kế phải cân nhắc thêm tính khả kiểm thử của thiết kế kiến trúc để đảm bảo hệ thống dễ dàng kiểm thử về sau.
2.3 Tính khả kiểm thử của thiết kế chi tiết
Thiết kế chi tiết cũng mô tả các thành phần của hệ thống và tƣơng tác giữa các thành phần đó, tƣơng tự thiết kế kiến trúc. Tuy nhiên, thiết kế chi tiết ở mức độ thấp hơn, mức độ thành phần hoặc mô-đun của hệ thống. Ví dụ, các sơ đồ lớp hay các biểu đồ cộng tác (collaboration diagram) trong phân tích và thiết kế hƣớng đối tƣợng sẽ đƣợc sử dụng để mô tả thiết kế chi tiết.
Tƣơng tự thiết kế kiến trúc, khi thiết kế chi thiết ngƣời ta thƣờng sử dụng các mẫu thiết kế [10] có sẵn và chỉnh sửa hoặc kết hợp các mẫu thiết kế cho phù hợp để giải quyết yêu cầu bài toán. Khi đó ngƣời thiết kế cũng phải xem xét việc thay đổi, kết hợp này có ảnh hƣởng đến tính khả kiểm thử của thiết kế không.
Baudry [11] đề xuất bổ sung thông tin ràng buộc vào các thiết kế để trong quá trình cài đặt các quan hệ giữa các lớp đƣợc thực hiện đúng đắn. Với UML ta có thể tận dụng lợi thế của cơ chế mở rộng stereotype để chứa các thông tin ràng buộc trong thiết kế. Các ràng buộc này làm rõ hơn quan hệ giữa các lớp, giảm mơ hồ khi ngƣời lập trình đọc thiết kế. Ví dụ quan hệ giữa hai lớp có thể chỉ rõ là quan hệ sử dụng (use) hay quan hệ tạo mới (create). Điều này sẽ tránh đƣợc việc cài đặt cho phép đa đƣờng đi, qua đó các trạng thái lớp có thể bị thay
đổi.
2.4 Kiểm thử xây dựng sẵn
Kiểm thử xây dựng sẵn [12] (built-in test - BIT) là việc viết mã kiểm thử (test code) kèm theo mô-đun (thành phần, lớp, hệ thống con) nhƣ là một phần không tách rời của mô-đun đó. Mã kiểm thử đƣợc xây dựng sẵn kèm này, mặc dù nằm trong mô-đun, nhƣng nó nằm riêng biệt với mã chức năng chính của mô-đun. Có thể hình dung kiểm thử xây dựng sẵn nhƣ các chức năng tự kiểm
tra có trong nhiều hệ thống, nhƣ chức năng self-test của rất nhiều máy in hay chức năng tự kiểm tra (diagnostic) có trong nhiều máy tính PC.
Hình 6 Kiến trúc của mô-đun với mã tự kiểm tra [13]
Các mô-đun với BIT này thƣờng có một giao diện kiểm thử riêng để phục vụ cho việc kiểm thử. Các lỗi có thể xảy ra từ bên trong mô-đun, hoặc do tƣơng tác với mô-đun khác. Các giao diện kiểm thử trong BIT giúp phát hiện cả hai loại lỗi bằng cách hỗ trợ kiểm thử nội bộ các hệ thống, hoặc bằng cách cho phép công cụ kiểm thử bên ngoài truy cập vào bên trong hệ thống. Hình 6 mô tả cấu trúc của một thành phần với mã tự kiểm tra [13].
Kiểm thử xây dựng sẵn với các hệ thống hƣớng đối tƣợng có thể là các hàm thành viên của lớp. Ở mức độ cao hơn nhƣ mức hệ thống, chúng ta có thể xây phần kiểm thử này nhƣ một hệ thống con và hệ thống con này sử dụng mã tự kiểm tra của các đơn vị dƣới nó, nhƣ ở mức lớp. Ƣu điểm của cách làm này với các hệ thống hƣớng đối tƣợng là mã tự kiểm tra này có thể đƣợc kế thừa và do đó có thể tái sử dụng trong các lớp con.
2.5 Khung và công cụ hỗ trợ kiểm thử
Tính khả kiểm thử của hệ thống có thể đƣợc triển khai dễ dàng hơn nếu có khung hỗ trợ kiểm thử (test framework). Khung hỗ trợ kiểm thử sẽ cung cấp
các chức năng nền tảng hỗ trợ việc viết và thực hiện (chạy) kiểm thử. Một khung hỗ trợ kiểm thử thƣờng là một ứng dụng tách biệt với ứng dụng ta đang kiểm thử.
Hình 7 Công cụ hỗ trợ lấy thông tin về ứng dụng
Khung ứng dụng là (application framework) là khung phần mềm với một số mã nguồn cung cấp sẵn làm sƣờn cho ứng dụng để ngƣời phát triển chỉ cần cài đặt thêm một số mã nguồn là có thể tạo thành ứng dụng hoàn chỉnh. Ví dụ để phát triển ứng dụng cho hệ điều hành Android ngƣời phát triển có thể sử dụng Android Application Framework 4, hay để phát triển ứng dụng web, ngƣời phát triển có thể sử dụng Ruby on Rails 5, khi đó kiến trúc của ứng dụng đƣợc tạo sẵn cùng một loạt các thành phần chuẩn, ngƣời phát triển chỉ cần thêm một số hàm xử lý ở mỗi thành phẩn để tạo thành ứng dụng.
4 http://developer.android.com/guide/faq/framework.html
Các khung kiểm thử là một loại khung ứng dụng chuyên dụng thiết kế sẵn để phục vụ cho việc phát triển mã kiểm thử. Có thể hiểu nó là một phần mềm kiểm thử bán hoàn chỉnh, có thể tái sử dụng và chuyên dùng để tạo ra các ứng dụng kiểm thử hoàn thiện. Với hai ví dụ về Android và Ruby on Rails nêu trên chúng có sẵn khung kiểm thử hỗ trợ viết mã kiểm thử từ mức đơn vị, tích hợp và đến mức chức năng ngƣời dùng (functional) 6. Bên cạnh các chức năng chạy mã kiểm thử, kiểm tra kết quả, các khung kiểm thử còn có thể có các công cụ hỗ trợ đi kèm giúp ngƣời kiểm thử lấy đƣợc nhiều thông tin về ứng dụng để viết mã kiểm thử. Ví dụ nhƣ Hình 7 là công cụ cho phép lấy thông tin về các phần tử trên màn hình giao diện của Android, giúp ngƣời kiểm thử gửi hoặc lấy các thông tin về các phần tử giao diện, hỗ trợ việc kiểm thử ngay cả khi không có mã nguồn của các ứng dụng này.
Bên cạnh một số khung kiểm thử đi kèm các khung ứng dụng nhƣ hai ví dụ trên còn có nhiều khung kiểm thử độc lập, cho phép sử dụng với nhiều loại ứng dụng khác nhau. Một ví dụ khá phổ biến là JUnit 7. Khung kiểm thử này tuy