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. Các phương pháp kiểm thử phần mềm cơ bản
Có ba phương pháp kiểm thử phần mềm:
- Kiểm thử hộp trắng (White box testing)
- Kiểm thử hộp đen (Black box testing)
- Kiểm thử hộp xám (Gray box testing)
3. Kiểm thử hộp trắng (White box testing)
Trong kiểm thử hộp trắng, cấu trúc mã hoặc thuật toán của chương trình được đưa vào xem xét. Các trường hợp kiểm thử được thiết kế dựa vào cấu trúc mã hoặc cách thức công tác của chương trình. Người kiểm thử truy cập vào mã nguồn của chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử.
4.Kiểm thử hộp đen (Black box testing)
Trong khi đó kiểm thử hộp đen không yêu cầu người kiểm thử cần phải có bất kỳ kiến thức về mã hoặc thuật toán của chương trình. Nó kiểm tra các chức năng của hệ thống tức là những gì hệ thống được cho là cần phải làm dựa trên các ” Đặc tả yêu cầu”. Các trường hợp kiểm thử thường được xây dựng xung quanh nó.
Hay nói cách khác, kiểm thử hộp đen là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết thế nào. Tester xem phần mềm như là một hộp đen.
5. Kiểm thử hộp xám (Gray box testing)
Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp giữa phương pháp kiểm thử hộp đen và phương pháp kiểm thử hộp trắng.
Trong kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc là ở mức hộp đen.
6. Nguyên lý kiểm thử phần mềm
Có bảy nguyên lý khi kiểm thử phần mềm:
- Kiểm thử đưa ra lỗi
- Kiểm thử cạn kiệt là không thể
- Kiểm thử càng sớm càng tốt
- Sự tập trung của lỗi
- Nghịch lý thuốc trừ sâu
- Kiểm thử phụ thuộc vào ngữ cảnh
- Không có lỗi – Sai lầm
6.1 Kiểm thử đưa ra lỗi
Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử được thực hiện bằng những kĩ thuật khác nhau. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi. Vì vậy chúng ta phải tìm được càng nhiều lỗi càng tốt.
6.2 Kiểm thử cạn kiệt là không thể
Nguyên lý này nói rằng, kiểm tra mọi thứ trong phần mềm một cách trọn vẹn là không thể. Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ phi nó chỉ bao gồm ít trường hợp thì có thể kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn.
6.3 Kiểm thử càng sớm càng tốt
Nguyên lý này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn. Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng dự kiến.
6.4 Sự tập trung của lỗi
Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả.
6.5 Nghịch lý thuốc trừ sâu
Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới. Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thường xuyên.
6.6 Kiểm thử phụ thuộc vào ngữ cảnh
Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau.
Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android.
6.7 Không có lỗi – Sai lầm
Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.