MỤC LỤC
Luồng chương trình từ input đến output có các cách đi khác nhau chủ yếu được dựa vào các câu lệnh điều khiển trong mã nguồn, chúng tôi sẽ tiến hành cài đặt một chương trình tìm kiếm câu lệnh điều khiển trong file mã nguồn java và xuất ra giá trị biên trong câu lệnh điều khiển có chứa toán tử so sánh. Giải quyết bài toán này chúng tôi sẽ phân tích kỹ thuật bao phủ code và kỹ thuật phân tích giá trị biên, sau cùng là cài đặt chương trình tìm kiếm câu lệnh điều khiển của mã file mã nguồn java, xuất ra giá trị biên trong đó.
Đưa ra các giá trị biên đề xuất cần phải được kiểm tra để đảm bảo phần mềm vẫn hoạt động tốt và ổn định trên các giá trị đó. Tóm lại bài toán đưa ra ở đây là làm sao xây dựng được ca kiểm thử tốt, các lỗi lập trình thường xảy ra ở các điểm biên của dải giá trị đầu vào, vậy thì ca kiểm thử thiết kế để kiểm tra giá trị biên là gì?.
Từ những đặc điểm về kỹ thuật kiểm thử hộp đen và kiểm thử hộp trắng như trên ta có thế nói bao phủ code là một phương pháp kiểm thử hộp trắng, bao phủ code cần phải hiểu về mã nguồn, có thể truy cập vào mã nguồn hơn là đơn giản sử dụng các giao diện được cung cấp. Có thế nói bao phủ code là phương pháp hữu ích nhất trong suốt giai đoạn kiểm thử mô đun (module), tuy nhiên nó cũng có những lợi ích trong kiểm thử tích hợp và trong các lần kiểm thử khác nữa, phụ thuộc vào chúng ta kiểm tra cái gì và kiểm tra như thế nào.
Một đường đi thể hiện một luồng việc thực thi từ khi bắt đầu đến khi kết thúc một chương trình, một phương thức có N quyết định sẽ có 2N cách đi, và nếu phương thức có vòng lặp thì có thể sẽ có vô số cách đi. Bao phủ đường đi cũng là một trong số các cách đo trong kiểm thử hộp trắng, nó sẽ kiểm tra trong từng hàm xem các đường đi có được kiểm tra hay không.
Kỹ thuật chính ở đây là phân tích mã nguồn, xác định các luồng điều khiển hay đường đi của chương trình từ input đến output. Dựa trên việc xác định các đường đi người ta đưa ra các ca kiểm thử nhằm kiểm tra tất cả các đường đi có thể.
Việc xác định các đường đi dựa trên việc phân tích các cấu trúc rẽ nhánh và các vòng lặp.
Kết quả kết xuất ở trên thông báo có số gói được tìm thấy là một, tổng số lớp có trong chương trình là một, tổng số phương thức trong lớp là ba, tổng số file thực thi là một và tổng số dòng đã thực thi là sáu. Tuy nhiên bao phủ dòng lệnh có nhược điểm là không thể nhận ra các lỗi xảy ra từ cấu trúc luồng điểu khiển trong mã nguồn như là khi ghép các điều kiện hay các nhãn switch liên tiếp. Điều này có nghĩa là báo cáo bao phủ của ta vẫn sẽ kết suất ra kết quả báo cáo là 100% code đã được bao phủ nhưng thực tế thì các lỗi đã không được bắt.
Như vậy có thể nói bao phủ dòng lệnh không báo cáo về các vòng lặp tới các điều kiện lặp, nó chỉ báo cáo phần thân của vòng lặp có được thực thi hay không.
Lỗi này thật nguy hiểm, nếu người quản lý xem kết quả bao phủ 100%, quyết định việc test đã hoàn thành thì sản phẩm phát hành sẽ có lỗi. Đối với vòng lặp “do- while” khối lệnh sau “do” được thực hiện ít nhất một lần, bao phủ dòng lệnh xem chúng giống với các câu lệnh không rẽ nhánh. Trong ví dụ vừa đề cập, ta đã không kiểm tra các trường hợp : TRUE-FALSE-TRUE hay FALSE-TRUE-TRUE…Với 3 quyết định trong một phương thức như trên ta sẽ có 2^3=8 quyết định.
Kiểm tra 8 cách đi là một điều dễ dàng, nhưng có những phương thức có rất nhiều quyết định thì số đường đi sẽ tăng theo hàm mũ.
Để thực hiện công việc này ta sẽ chọn bất kỳ đường đầu tiên làm đường cơ sở và sau đó sẽ lật các quyết định một lần cho tới khi ta có các đường thiết lập cơ sở. Tổng số đường cơ sở sẽ tăng theo số quyết định nhưng lúc này đã không tăng theo hàm mũ mà vẫn đảm bảo được yêu cầu bao phủ đầy đủ các nhánh. Ta có thể xây dựng các đường đi hoàn toàn khác nữa, nếu ta bắt đầu với đường cơ sở FFF sau đó tiến hành “flips” như đã làm ở trên ta sẽ thiết lập được 4 đường cơ sở hoàn toàn khác là : FFF, TFF, FTF,FFT.
Qua đây dễ dàng nhận thấy với Cyclomatic complexity (số đường độc lập tuyến tính đi qua mã nguồn) giúp ta giảm một nửa số test case cần tiến hành.
Giá trị bên trong một vùng dữ liệu được xem là “tương đương” do đó số ca kiểm thử sẽ giảm xuống. Trong ví dụ này ta có các dải giá trị hợp lệ và không hợp lệ như sau: Dải giá trị hợp lệ cho tháng là từ 1 đến 12 tương ứng từ tháng 1 đến tháng 12, có hai dải giá trị không hợp lệ đó là nhỏ hơn hoặc bằng 0 và lớn hơn hoặc bằng 13. Phân hoạch tương đương không đơn thuần là phương pháp xác định các ca kiểm thử một các đầy đủ.
Kết hợp với phân tích các giá trị biên giới giữa các vùng, ta sẽ thêm vào các ca kiểm thử ở giá trị biên, từ đó tìm ra các ca kiểm thử hiệu quả nhất cho từng vùng[12].
Các giá trị gần giá trị biên phải có trong các ca kiểm thử để kiểm tra các loại lỗi này [4].Trong các ca kiểm thử thêm vào đường biên các giá trị gần biên, quá trình phân tích giá trị biên baseline sẽ gồm một vài giá trị đầu vào tồn tại trên danh nghĩa. Quá trình phân tích giá trị biên multiple-fault sẽ được bắt đầu với tập hợp giá trị trong Mbaseline và Nbaseline trong trường hợp các đường biên không được kiểm tra, còn trong trường hợp việc kiểm tra các đường biên được ưu tiên cao thì ta sẽ sử dụng với tập giá trị Mrubust và Nrubust. Tương ứng với hai trường hợp vừa nêu ta có ước lượng tích đề-các (cartesian) Mbaselien x Nbaselien xác định số ca kiểm thử cho baseline multiple-fault, và tích đề các Mrubust x Nrubust xác định số ca kiểm thử cho rubust multiple-fault.
Từ những phõn tớch đó trỡnh bày rừ ràng phõn tớch giỏ trị điểm biờn cú nhiều ưu điểm quá trình phân tích giá trị điểm biên để chỉ ra các kiểm tra là một việc dễ sử dụng, thậm chớ cú cỏc giỏ trị biờn đầu vào cũn được mụ tả một cỏch rừ ràng trong tài liệu yờu cầu.
Dựa vào cấu trúc của chương trình nguồn như trên đề xuất các ca kiểm thử kiểm tra code trong từng nhánh có được thực thi hay không. Test case 1 :Công việc A được thực hiện khi điều kiện một “true” do đó để kiểm tra việc thực thi công việc A chúng ta cần gán sao cho điều kiện một “true”. Nếu xem như các biểu thức trong các điều kiện của ta là các biểu thức boolean nguyên tử (tức là không chứa các phép toán logic như and, or, xor) thì lúc này ta nhận thấy là toàn bộ nhánh và toàn bộ điều kiện đã được bao phủ.
Như vậy dựa vào việc phân tích từng mức bao phủ : bao phủ dòng lệnh, bao phủ nhánh, bao phủ đường đi ta đã thiết kế được một bộ test case hoàn chỉnh, đảm bảo tất cả các câu lệnh đã được kiểm tra, các nhánh, các đường đi có thể đều đã được bao phủ.
Biều đồ trình tự dưới đây thể hiện tương tác giữa người dùng và hệ thống khi người dùng muốn thao tác trên từng câu lệnh if để chỉ ra giá trị biên của chính câu lệnh đó. Để làm được điều này chúng tôi sử dụng hàm charAt(i) để chuyển phần tử thứ (i) thành kiểu char, dùng đối tượng thuộc lớp BufferedWriter để ghi ra file lưu trữ.Việc tìm kiếm câu lệnh while và for cũng tương tự như thực hiện với câu lệnh if. Khai báo các biến đếm count_if, count_while, count_for, mỗi lần một câu lệnh điều khiển được tìm thấy các biến đếm này sẽ được tăng lên một theo đúng loại câu if hay while hay for.
<= do đó thuật toán để lấy ra các giá trị biên trong các câu lệnh điều khiển sẽ là tiến hành đọc qua file, đọc từng dòng một, xét câu lệnh đó có phải là câu lệnh điều khiển hay không, nếu là câu lệnh điều khiển sẽ lấy ra xâu đằng sau các toán tử so sánh trên.