Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi.
Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra.
Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm.
Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư duy đánh giá và sáng tạo để bạn có thể phát hiện ra những điểm mà người khác chưa nhìn thấy.
Kiểm thử hộp đen là 1 phương pháp kiểm thử mà tester sẽ chỉ xem xét đến đầu vào và đầu ra của chương trình mà không quan tâm code bên trong được viết ra sao. Tester thực hiện kiểm thử dựa hoàn toàn vào đặc tả yêu cầu . Mục đích của kiểm thử hộp đen là tìm ra các lỗi ở giao diện , chức năng của phần mềm. Các trường hợp kiểm thử sẽ được xây dựng xung quanh đó.
Kiểm thử hộp trắng là phương pháp kiểm thử mà cấu trú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 làm việ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 để kiểm tra nó.
Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất. Kiểm thử thực hiện trên các hàm hay thành phần riêng lẻ.
Đây là 1 công việc mà để thực hiện được nó thì người kiểm thử sẽ phải hiểu biết về code, về chương trình, các hàm, …Nếu bạn đang lo lắng vì bạn không có nhiều kiến thức về code thì không sao cả, vì bạn sẽ không phải thực hiện bước kiểm thử này, lập trình viên sẽ làm nó trước khi giao cho bạn.
Mục đích của việc thực hiện kiểm thử đơn vị là cô lập từng thành phần của chương trình và chứng minh các bộ phận riêng lẻ chính xác về các yêu cầu chức năng.
Như chúng ta đã biết, một phần mềm được tạo ra sẽ bao gồm rất nhiều module trong đó, để chắc chắn rằng phần mềm hoạt động tốt thì chúng ta cần phải gom các module lại với nhau để kiểm tra sự giao tiếp giữa các module cũng như bản thân từng thành phần từng module.. Kiểm thử tích hợp bao gồm 2 mục tiêu chính là :
Kiểm thử 1 hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu Kiểm thử hệ thống thuộc loại kiểm thử hộp đen . Kiểm thử hệ thống tập trung nhiều hơn vào các chức năng của hệ thống . Kiểm tra cả chức năng và giao diện , các hành vi của hệ thống 1 cách hoàn chỉnh, đáp ứng với yêu cầu.
Trong kiểu kiểm thử này, phần mềm sẽ được thực hiện kiểm tra từ người dùng để tìm ra nếu phần mềm phù hợp với sự mong đợi của người dùng và thực hiện đúng như mong đợi. Trong giai đoạn test này, tester có thể cũng thực hiện hoặc khách hàng có các tester của riêng họ để thực hiện.
Có 2 loại kiểm thử chấp nhận đó là kiểm thử Alpha và kiểm thử Beta:
Kiểm thử chức năng là một loại kiểm thử hộp đen (black box) và các trường hợp kiểm thử của nó được dựa trên đặc tả của ứng dụng phần mềm/thành phần đang test. Các chức năng được test bằng cách nhập vào các giá trị nhập và kiểm tra kết quả đầu ra, và ít quan tâm đến cấu trúc bên trong của ứng dụng (không giống như kiểm thử hộp trắng – white-box testing).
Có thể hiểu 1 cách đơn giản, kiểm thử chức năng là xác nhận tất cả các chức năng của hệ thống. Nó đánh giá ứng dụng và xác nhận liệu ứng dụng có đang hoạt động theo yêu cầu hay không.
Loại kiểm thử này tập trung vào các khía cạnh phi chức năng của ứng dụng. Vậy những khía cạnh phi chức năng là những gì? Hay tôi nên nói những tính năng mà không liên quan đến các chức năng của ứng dụng là gì? Tôi nghĩ nó sẽ bao gồm:
Kiểu kiểm thử này cơ bản là kiểu kiểm thử về khả năng của hệ thống mạng, kết nối dữ liệu và sự tương tác của các module. Thông thường thì kiểu test này là do nhóm quản lý cấu hình chuẩn bị thiết lập các môi trường test thực sự. Họ cũng kiểm tra xem liệu các thành phần chính của phần mềm có hoạt động bất thường không. Kiểu kiểm thử này thực hiện trước khi tiến hành thực hiện trong môi trường test. Sau khi test shakeout, bước kế tiếp là test smoke (kiểu test được thực hiện bởi tester sau khi biên dịch, được tiến hành trong môi trường test).
Smoke Testing là 1 quá trình để kiểm tra liệu bản build có ổn định hay không? Để xem bản build có đủ ổn định để thực hiện test chi tiết hay không (trong trường hợp bản build ko ổn định, lỗi luôn chức năng chính hoặc build bị lỗi thì trả lại Dev, yêu cầu sửa luôn). Hay kiểm tra các tính năng quan trọng có đang hoạt động hay không . Nó là 1 bài test hồi quy nhỏ đơn giản và nhanh của các chức năng chính, cho thấy sản phẩm đã sẵn sàng cho việc test hay chưa.
Thuật ngữ Adhoc testing là phương pháp kiểm thử dạng Black box test mà không theo cách thông thường. Với quy trình test thông thường là phải có tài liệu yêu cầu, kế hoạch test ( test plan), kịch bản kiểm thử. Kiểu test này không theo bất cứ loại kỹ thuật test nào để tạo testcase.
Monkey testing được định nghĩa rất ngắn gọn: là một phương pháp kiểm thử với đầu vào ngẫu nhiên, không theo testcase hay một chiến lược test nào.
Chắc hẳn bạn rất tò mò về cái tên Monkey testing này phải không? Tôi sẽ giải thích nó ngay đây
Trong Monkey testing thì các tester ( đôi khi cả developer nữa ) được coi như là 1 con khỉ vậy Bạn thử nghĩ mà xem, nếu 1 con khỉ mà sử dụng máy tính thì nó sẽ làm những gì nhỉ? Tuy loài khỉ rất thông minh nhưng khi cho nó sử dụng máy tính, nó sẽ thực hiện những hành động bất kỳ trên hệ thống , điều mà chính nó cũng không thể hiểu được. Nó cũng giống như khi tester thực hiện monkey testing, họ sẽ áp dụng các kịch bản kiểm thử ngẫu nhiên trên hệ thống để tìm ra lỗi mà không cần xác định trước. Trong 1 số trường hợp, Monkey testing chỉ dành cho Unit Testing hoặc GUI Testing( Kiểm thử giao diện người dùng)
Trong loại test này, ứng dụng được test dựa vào sức nặng như sự phức tạp của giá trị, độ dài của đầu vào, độ dài của các câu truy vấn…Loại test này kiểm tra bớt phần tải (stress/load) của ứng dụng có thể được chắc chắn hơn.
Test hồi quy là test lại 1 chức năng đã được làm xong, đã được test xong rồi, đã hết lỗi nhưng do có sự sửa đổi 1 chức năng khác mà lại có ảnh hưởng đến nó, thì phải test 1 chức năng đã xong rồi thì gọi là test hồi quy .
Ví dụ tôi có 3 chức năng A B C đã hoàn thành, 3 chức năng này đều có mối quan hệ với nhau và chức năng A cần phải sửa đổi thêm về nghiệp vụ, việc sửa chức năng A này sẽ làm ảnh hưởng đến chức năng B, C và việc phải test lại chức năng B và C thì gọi là test hồi quy . Hoặc khi Dev sửa 1 chức năng mà chức năng này có làm ảnh hưởng đến chức năng đã xong rồi thì cũng phải thực hiện test lại chức năng đã xong rồi kia thì gọi là test hồi quy
Hoặc ngay cả khi re- test để đóng bug, mà thấy chức năng Developer sửa có thể làm ảnh hưởng đến 1 chức năng khác đã xong rồi thì tester cũng nên test hồi quy lại chức năng đó để tránh có lỗi tiềm ẩn mà ko biết.
Re-test là thực hiện test để đóng bug/ defect / lỗi sau khi lập trình viên đã được sửa hoặc sửa 1 chức năng nào đó rồi test lại chức năng sửa đó thì gọi là test lại hoặc 1 chức năng cần re -test vài lần cho hết bug
Là một khiếm khuyết trong một thành phần hoặc hệ thống mà nó có thể làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó, ví dụ như thông báo sai hoặc định nghĩa dữ liệu không đúng. Một bug, nếu gặp phải trong quá trình hệ thống hoạt động, có thể gây ra failure trong thành phần hoặc hệ thống đó.
Test case là mô tả một dữ liệu đầu vào, hành động và một kết quả mong đợi (expected result) để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không.
Test case thường được viết trên excel. Một file Testcase cơ bản cần có các trường sau: TestcaseID, mục tiêu test, các bước thực hiện test, và kết quả trả về (expected result) có đúng với yêu cầu test không.Ngoài ra còn có thể có thêm điều kiện tiên quyết và dữ liệu test.
Để viết được testcases có hiệu quả bao phủ hết các trường hợp cần test thì testcases phải có đầy đủ hết các Nghiệp vụ mà hệ thống yêu cầu (các yêu cầu trong tài liệu Đặc tả ko được bỏ sót, sử dụng các kỹ thuật thiết kế test case (các kỹ thuật test hộp đen) để viết được test case có độ bao phủ tối đa.
Test plan chính là tài liệu tổng quan về việc kiểm thử 1 project: phạm vi kiểm thử, hướng tiếp cận, quy trình kiểm thử, tài nguyên và nhân lực test cần có, các chức năng/ module cần được test, các công cụ và môi trường test cần có.
Bao gồm cả kế hoạch ai test chức năng nào, khi nào bắt đầu thực hiện viết và hoàn thành testcases, khi nào bắt đầu thực hiện test và kế hoạch hoàn thành test
Dựa vào kế hoạch chung của dự án để lên kế hoạch cho bên kiểm thử. Trong trường hợp khi làm thực tế thấy có khả năng không đúng như kế hoạch đã lên thì phải báo cáo lại test leader hoặc Quản trị dự án sớm.
Nguồn: https://viblo.asia/p/cac-khai-niem-co-ban-ve-kiem-thu-phan-mem-63vKjR7dK2R
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
