Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và phát hiện ra các lỗi của phần mềm, đảm bảo phần mềm chính xác, đúng và trọn vẹn theo yêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra. Software testing cũng gửi tới mục tiêu, cái nhìn độc lập về phần mềm điều này cho phép đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Căn cứ là gì? Hãy cùng LVN Group nghiên cứu thông qua nội dung trình bày dưới đây
1. Kiểm thử là gì?
Đây là một trong những loại kiểm thử phần mềm cần thiết để xác nhận xem hệ thống có hoạt động đúng yêu cầu được không. Ở tất cả các mức độ kiểm thử đều được kiểm thử chức năng.
Testing of function là một trong những loại kiểm thử phần mềm cần thiết
Testing of function có thể thực hiện theo 2 quan điểm: business – process – based và requirements-based. Với business – process – based, kiểm thử viên sẽ sử dụng các kiến thức về quy trình nghiệp vụ (mô tả các kịch bản liên quan đến nghiệp vụ của hệ thống mỗi ngày).
Trong khi đó, requirements-based sử dụng các đặc tả yêu cầu của hệ thống làm cơ sở để design test. Để đảm bảo những thành phần cần thiết nhất đều được kiểm thử, hãy xem xét độ ưu tiên của yêu cầu dựa trên tiêu chí rủi ro, theo đó, chúng ta sẽ sử dụng độ ưu tiên để kiểm thử.
Các bước kiểm thử chức năng gồm:
Bước 1: Xác định phần mềm sẽ kiểm thử và chức năng của nó
Bước 2: Dựa trên tài liệu đặc tả chức năng để tạo dữ liệu đầu vào
Bước 3: Dựa vào tài liệu đặc tả chức năng để xác định đầu ra
Bước 4: Thực hiện các trường hợp kiểm thử phần mềm
Bước 5: So sánh kết quả thực tiễn với mong muốn đạt được
2. Kỹ thuật kiểm thử phần mềm là gì?
Kỹ thuật kiểm thử phần mềm giúp bạn thiết kế các trường hợp kiểm thử tốt hơn. Vì kiểm thử toàn diện là không thể nên kỹ thuật kiểm tra thủ công sẽ giúp giảm số lượng các trường hợp kiểm thử được thực thi trong khi tăng phạm vi kiểm thử. Chúng giúp xác định các điều kiện kiểm tra khó nhận biết.
3. Kiểm thử hộp trắng là gì?
Kiểm thử hộp trắng (White box testing) là phương pháp kiểm thử phần mềm nhằm kiểm tra thuật toán, cấu trúc code bên trong của sản phẩm. Hộp trắng tượng trưng cho khả năng nhìn xuyên qua lớp vỏ bên ngoài của phần mềm để thấy được hoạt động bên trong của chúng.
Mục đích của White box testing là đảm bảo tất cả các câu lệnh và điều kiện sẽ được thực hiện đúng, kết quả đầu ra như mong đợi. Tester sẽ xác minh luồng hoạt động cho ứng dụng bằng cách kiểm tra một loạt đầu vào (Input) đã được xác định từ trước có dẫn đến đầu ra (Output) như dự kiến không? Nếu Output không khớp với kỳ vọng, có nghĩa là sản phẩm đang bị lỗi.
Am hiểu về lập trình, có kiến thức về công nghệ thông tin là điều kiện tiên quyết để tester có thể tiến hành kiểm thử hộp trắng. Thông thường, nhiệm vụ thực thi White box Testing sẽ do chính các Developers đảm nhiệm.
4. Các loại kiểm thử hộp trắng
White box testing có 2 loại kiểm thử chính: Kiểm thử đơn vị (Unit Testing) và Kiểm tra rò rỉ bộ nhớ (Testing for Memory Leaks)
4.1. Kiểm thử đơn vị (Unit Testing)
Kiểm thử đơn vị là quá trình test từng module nhỏ trong hệ thống để xác nhận rằng mỗi thành phần của phần mềm thực hiện đúng với thiết kế. Unit Testing được coi là loại kiểm thử đầu tiên được thực hiện trên một ứng dụng. Các lỗi được tìm thấy trong giai đoạn này sẽ dễ dàng sửa chữa cũng như không làm phát sinh chi phí cho dự án. Người thực hiện kiểm thử đơn vị phần lớn là developers hoặc tester có kinh nghiệm về lập trình. Developers tiến hành code, phát triển các chức năng đơn lẻ và tiến hành kiểm tra lại nhằm đảm bảo lập trình hoạt động được trước khi sang giai đoạn khác.
4.2. Kiểm tra rò rỉ bộ nhớ (Testing for Memory Leaks)
Rò rỉ bộ nhớ là nguyên nhân hàng đầu khiến các ứng dụng chạy chậm hơn. Developers sẽ phải cần đến một chuyên gia QA (Quality Assurance – Đảm bảo chất lượng) có kinh nghiệm trong việc phát hiện rò rỉ bộ nhớ tư vấn về trường hợp kiểm thử. Đây là điều cần thiết để tránh ứng dụng phần mềm chạy chậm gây ảnh hưởng đến chất lượng sản phẩm cũng như trải nghiệm người dùng.
5. Ưu & nhược điểm kiểm thử hộp trắng
Ngoài những ưu điểm nổi bật, White box testing vẫn có những nhược điểm cần được cải thiện trong tương lai.
5.1. Ưu điểm của White box testing
Tối ưu hóa mã bằng cách tìm lỗi ẩn.
Tự động hóa dễ dàng các trường hợp kiểm thử
Kiểm tra kỹ lưỡng hơn vì tất cả các đường dẫn mã thường được bao phủ.
Kiểm thử có thể được thực hiện sớm trong quy trình phát triển phần mềm ngay cả khi GUI (Graphical User Interface – Giao diện đồ họa người dùng) không khả dụng.
5.2. Nhược điểm của White box testing
Đòi hỏi nguồn lực chuyên nghiệp có kiến thức và tay nghề cao về lập trình.
Tốn khá nhiều thời gian để kiểm tra được chi tiết cấu trúc, thuật toán bên trong sản phẩm. Các ứng dụng có cấu trúc hệ thống càng lớn càng cần rất nhiều thời gian để kiểm tra trọn vẹn.
Kiểm thử diễn ra khi sản phẩm chưa được hoàn thiện nên các công cụ phục vụ cho mọi loại triển khai/nền tảng thường không sẵn có.
Kiểm tra hộp trắng được đánh giá khá phức tạp và tốn kém. Developers không kiểm tra hộp trắng chi tiết có thể dẫn đến lỗi sản xuất.
6. Kỹ thuật kiểm thử hộp trắng
Trong kiểm thử hộp trắng, làm sao để bạn biết rằng bộ Test Case đã bao phủ tất cả các trường hợp hay chưa? Khi này, ta sẽ dùng đến kỹ thuật Coverage Testing để đo đạc kết quả test khi thực thi bộ kiểm thử. Coverage Testing là kỹ thuật phân tích độ phủ mã giúp loại bỏ các lỗ hổng trong bộ Test Case từ đó tăng chất lượng của sản phẩm phần mềm. Khi các lỗ hổng được xác định, tester tạo các trường hợp thử nghiệm để xác minh các phần chưa được kiểm tra của mã.
Coverage Testing là kỹ thuật giúp loại bỏ các lỗ hổng trong bộ Test Case
Một số kỹ thuật Coverage Testing mà người kiểm thử có thể sử dụng:
Bao phủ câu lệnh (Statement Coverage): Kỹ thuật này yêu cầu mọi câu lệnh phải được thực thi ít nhất 1 lần trong quá trình kiểm tra kỹ thuật phần mềm. Statement Coverage gửi tới các chi tiết của cả hai khối mã được thực thi và thất bại trong tổng số các khối mã.
Phạm vi chi nhánh (Branch Coverage): Kỹ thuật này kiểm tra mọi đường dẫn if-else và các vòng điều kiện khác của một ứng dụng phần mềm. Branch coverage có thể được tính bằng cách tìm số đường dẫn tối thiểu để đảm bảo rằng tất cả các cạnh đã được che phủ.
Bao phủ nhánh (Path Coverage): Bao phủ nhánh là một phương pháp kiểm tra cấu trúc liên quan đến việc sử dụng mã nguồn của chương trình để tìm mọi đường dẫn thực thi có thể. Path Coverage đảm bảo phạm vi của tất cả các đường dẫn từ đầu đến cuối.
7. Các kỹ thuật kiểm thử hộp trắng phổ biến
7.1. Kiểm thử đường cơ bản – Đồ thị dòng
Là một kỹ thuật dùng trong kiểm thử hộp trắng được Tom McCabe đưa ra đầu tiên. Đồ thị dòng gần giống đồ thị luồng điều khiển của chương trình.
Là một trong nhiều phương pháp miêu tả thuật giải. Đây là phương pháp trực quan cho chúng ta thấy dễ dàng các thành phần của thuật giải và mối quan
hệ trong việc thực hiện các thành phần này.
Kỹ thuật đường cơ bản – đồ thị dòng có thể giúp những người thiết kế ca kiểm thử nhận được một độ phức tạp của 1 logic thủ tục.
Gồm 2 loại thành phần : các nút và các cung nối kết giữa chúng.
Các loại nút trong đồ thị dòng điều khiển :
Các kiểu cấu trúc thành phần đồ thị dòng :
Thí dụ : Nếu đồ thị dòng điều khiển chỉ chứa các nút quyết định nhị phân thì ta gọi nó là đồ thị dòng điều khiển nhị phân. Ta luôn có thể chi tiết hóa 1 đồ thị dòng điều khiển bất kỳ thành đồ thị dòng điều khiển nhị phân.
Độ phức tạp Cyclomatic C Độ phức tạp Cyclomatic C = V(G) của đồ thị dòng ₫điều khiển được tính bởi 1 trong các công thức sau : V(G) = E – N + 2, trong đó E là số cung, N là số nút của đồ thị. V(G) = P + 1, nếu là ₫ồ thị dòng ₫điều khiển nhị phân (chỉ chứa các nút quyết ₫định luận lý – chỉ có 2 cung xuất True/False) và P số nút quyết ₫định. Độ phức tạp Cyclomatic C chính là số ₫ường thi hành tuyến tính ₫độc lập của TPPM cần kiểm thử.
7.2 Kiểm thử dựa trên luồng điều khiển
Đường thi hành (Execution path) : là 1 kịch bản thi hành đơn vị phần mềm tương ứng, cụ thể nó là danh sách có thứ tự các lệnh được thi hành ứng với 1 lần chạy cụ thể của đơn vị phần mềm, bắt đầu từ điểm nhập của đơn vị phần mềm đến điểm kết thúc của đơn vị phần mềm.
Mỗi TPPM có từ 1 đến n (có thể rất lớn) đường thi hành khác nhau.
Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọi đường thi hành của ₫ơn vị phần mềm cần kiểm thử đều chạy đúng. Rất tiếc trong thực tiễn, công sức và thời gian để đạt mục tiêu trên đây là rất lớn, ngay cả trên những đơn vị phần mềm nhỏ.
Thí dụ ₫đoạn code sau : for (i=1; i<=1000; i++) for (j=1; j<=1000; j++) for (k=1; k<=1000; k++) doSomethingWith(i,j,k); chỉ có 1 đường thi hành, nhưng rất dài : dài 100010001000 = 1 tỉ lệnh gọi hàm doSomething(i,j,k) khác nhau.
Còn đoạn code gồm 32 lệnh if else độc lập sau : if (c1) s11 else s12; if (c2) s21 else s22; if (c3) s31 else s32; … if (c32) s321 else s322; có 2^32 = 4 tỉ đường thi hành khác nhau.
Mà cho dù có kiểm thử hết được toàn bộ các đường thi hành thì vẫn không thể phát hiện những đường thi hành cần có nhưng không (chưa) được hiện thực : if (a>0) doIsGreater(); if (a==0) dolsEqual(); // thiếu việc xử lý trường hợp a < 0 – if (a<0) dolsLess();
Một ₫ường thi hành đã kiểm tra là đúng nhưng vẫn có thể bị lỗi khi dùng thật (trong 1 vài trường hợp đặc biệt) : int phanso (int a, int b) { return a/b; } khi kiểm tra, ta chọn b <> 0 thì chạy đúng, nhưng khi dùng thật trong trường hợp b = 0 thì hàm phân số bị lỗi.
→ Ngoài 2 kỹ thuật kiểm thử trên thì còn có : Kiểm thử dựa trên luồng dữ liệu ( Data – flow Testing) và Kiểm thử đột biến ( Mutation Testing).