Chào các bạn, hôm nay mình muốn san sớt với những bạn – những người dân vừa mới bước tiến vào nghề kiểm thử như mình hoặc ai đó muốn tìm hiểu qua đôi chút về nghành này một số khái niệm cơ bản về kiểm thử phần mềm. Mở màn thôi nào .

Bạn Đang Xem: Các khái niệm cơ bản về kiểm thử phần mềm

1. Kiểm thử phần mềm ( Software Testing)

Kiểm thử phần mềm là quá trình thực thi 1 lớp học với mục tiêu 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 chuẩn 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 đề đã đề 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 được chấp nhận việc định hình và nắm rõ các rủi ro khi thực thi phần mềm.

Kiểm thử phần mềm tạo xét tuyển cho bạn tận dụng tối đa tư duy định hình và sáng tạo để bạn cũng có thể phát hiện ra những điểm mà người khác chưa nhìn thấy.

2. Kiểm thử hộp đen( Black box testing)

Kiểm thử hộp đen là 1 trong những phương pháp kiểm thử mà tester sẽ chỉ xem xét đến nguồn vào và đầu ra của lớp học 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 tiêu 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ẽ tiến hành xây dựng xung quanh đó.

3. Kiểm thử hộp trắng( White box testing)

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 lớp học đượ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 thao tác của lớp học. Người kiểm thử truy cập vào mã nguồn của lớp học để kiểm tra nó.

4. Kiểm thử đơn vị( Unit test)

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 trong những 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ề lớp học, các hàm, …Nếu như bạn đang lo lắng vì bạn không có nhiều tri thức về code thì không sao cả, vì các 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 lúc giao cho bạn .

Mục tiêu 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 lớp học và chứng minh các phòng ban riêng lẻ chuẩn xác về các yêu cầu chức năng.

5. Kiểm thử tích hợp( Intergration test)

Như tất cả chúng ta đã biết, một phần mềm được tạo ra sẽ gồm có rất nhiều module trong đó, để kiên cố rằng phần mềm hoạt động tốt thì tất cả 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 gồm có 2 mục tiêu đó chính là :

• Phát hiện lỗi giao tiếp xẩy ra giữa các Unit

• Tích hợp các Unit đơn lẻ thành các khối hệ thống nhỏ và cuối cùng là 1 trong những khối hệ thống hoàn chỉnh để sẵn sàng chuẩn bị cho bước kiểm thử khối hệ thống.

6. Kiểm thử khối hệ thống( System test)

Xem Thêm : Ayahuasca loài thuộc gây ảo giác giúp cải thiện bệnh trầm cảm

Kiểm thử 1 khối 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ử khối hệ thống thuộc loại kiểm thử hộp đen . Kiểm thử khối hệ thống tập trung nhiều hơn vào các chức năng của khối hệ thống . Kiểm tra cả chức năng và giao diện , các hành vi của khối hệ thống một cách hoàn chỉnh, đáp ứng với yêu cầu.

7. Kiểm thử đồng ý chấp thuận( Acceptance test)

Trong kiểu kiểm thử này, phần mềm sẽ tiến hành thực hiện kiểm tra từ người dùng để làm tìm ra nếu phần mềm phù phù hợp với sự mong đợi của người dùng và thực hiện đúng như mong đợi. Trong thời đoạn test này, tester có thể cũng thực hiện hoặc khách hàng có những tester của riêng họ để thực hiện.

Có 2 loại kiểm thử đồng ý chấp thuận đó là kiểm thử Alpha và kiểm thử Beta:

• Kiểm thử Alpha: là loại kiểm thử nội bộ . Tức là phần mềm sẽ được một đội kiểm thử độc lập hoặc do khách hàng thực ngày nay nơi sinh sản phần mềm.

• Kiểm thử Beta: là loại kiểm thử mà khách hàng thực hiện kiểm thử ở chính môi trường xung quanh của họ. Loại kiểm thử này được thực hiện sau kiểm thử Alpha.

8. Kiểm thử chức năng ( Functional testing)

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 phương pháp 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 phải như kiểm thử hộp trắng – white-box testing).

Có thể hiểu một cách đơn giản, kiểm thử chức năng là xác nhận tất cả những chức năng của khối hệ thống. Nó định hình ứng dụng và xác nhận liệu ứng dụng có đang hoạt động theo yêu cầu hay là không.

9. Kiểm thử phi chức năng( Non Functional testing)

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 tới những chức năng của ứng dụng là gì? Tôi nghĩ nó sẽ gồm có:

• Kiểm thử chịu tải
• Kiểm thử bảo mật thông tin
• Kiểm tra tính tương thích trên từng môi trường xung quanh,…

10. Test cấu hình (Shakeout testing)

Kiểu kiểm thử này cơ bản là kiểu kiểm thử về khả năng của khối hệ thống mạng, kết nối tài liệu và sự tương tác của không ít module. Thông thường thì kiểu test này là vì nhóm quản lý cấu hình sẵn sàng chuẩn bị thiết lập các môi trường xung quanh 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 thất thường không. Kiểu kiểm thử này thực hiện trước lúc tiến hành thực hiện trong môi trường xung quanh test. Sau thời điểm test shakeout, bước kế tiếp là test smoke (kiểu test được thực hiện bởi tester sau thời điểm biên dịch, được tiến hành trong môi trường xung quanh test).

11. Smoke testing

Smoke Testing là 1 trong những quá trình để kiểm tra liệu bản build có ổn định hay là không? Để xem bản build có đủ ổn định để thực hiện test cụ thể chi tiết hay là 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 là không . Nó là 1 trong những bài test hồi quy nhỏ đơn giản và nhanh của không ít chức năng chính, cho thấy sản phẩm đã sẵn sàng cho việc test hay chưa.

12. Ad hoc testing

Thuật ngữ Adhoc testing là phương pháp kiểm thử dạng Black box test mà không Theo phong cách thông thường. Với quy trình test 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 sẽ không theo bất kỳ loại kỹ thuật test nào để tạo testcase.

13. Monkey testing

Monkey testing được khái niệm rất ngắn gọn: là một phương pháp kiểm thử với nguồn vào tình cờ, 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ảng giải nó ngay đây

Trong Monkey testing thì những tester ( thỉnh thoảng cả developer nữa ) được coi như như là 1 trong những 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 khối 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ẽ vận dụng các kịch bản kiểm thử tình cờ trên khối hệ thống để tìm ra lỗi mà không cần xác định trước. Trong một số trường hợp, Monkey testing chỉ dành riêng cho Unit Testing hoặc GUI Testing( Kiểm thử giao diện người dùng)

14. Kiểm thử hiệu suất (Performance testing)

Xem Thêm : Kỹ thuật Chroma Key là gì – Kỹ xảo điện ảnh kinh điển nhất mọi thời đại

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 nguồn vào, độ dài của không ít 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 thêm.

15. Kiểm thử hồi quy (Regression testing)

Test hồi quy là test lại 1 chức năng đã được code và test xong rồi, đã không còn lỗi nhưng do có sự sửa đổi 1 chức năng khác mà lại sở hữu tác động ảnh hưởng đến chức năng đã test xong đó, thì việc phải test 1 chức năng này được gọi là kiểm thử 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 phải sở hữu liên quan đến 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 tác động ảnh hưởng đến chức năng B, C . Lúc này, ngoài việc retest chức năng A, tất cả chúng ta cần test lại cả chức năng B và C nữa, việc phải test lại chức năng B và C này được gọi là test hồi quy .

Hoặc ngay cả những lúc re- test để đóng bug, mà thấy chức năng Developer sửa có thể làm tác động ả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 tàng mà ko biết.

Tùy vào từng thời đoạn test cũng như mức độ tác động ảnh hưởng của việc sửa code thì tất cả chúng ta sẽ xác định được phạm vi của test hồi quy là test lại một phần chức năng hay cần test lại cả khối hệ thống.

16. Re-test

Re-test là thực hiện test để đóng bug/ defect / lỗi sau thời điểm 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

17. Bug

Là một khuyết thiếu trong một thành phần hoặc khối hệ thống mà nó có thể làm cho thành phần hoặc khối hệ thống này sẽ không thực hiện đúng chức năng yêu cầu của nó, ví dụ như thông tin sai hoặc khái niệm tài liệu không đúng. Một bug, nếu gặp phải trong quá trình khối hệ thống hoạt động, có thể gây ra failure trong thành phần hoặc khối hệ thống đó.

18. Testcase

Test case là mô tả một tài liệu nguồn 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 là không.

Test case thường được viết trên excel. Một file Testcase cơ bản cần có những 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 tồn tại thể có thêm xét tuyển tiên quyết và tài liệu test.

Để viết được testcases có hiệu quả rải rộng hết các trường hợp cần test thì testcases phải có một cách đầy đủ hết các Nghiệp vụ mà khối 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ó độ rải rộng tối đa.

19. Testplan

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 phương tiện và môi trường xung quanh test cần có.

Gồm có cả kế hoạch ai test chức năng nào, khi nào khai mạc thực hiện viết và hoàn thành testcases, khi nào khai mạc 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 văn bản báo cáo lại test leader hoặc Quản trị dự án sớm.

Như vậy, trên đây là những khái niệm mà tôi đã tìm hiểu khi mình khai mạc nghe biết từ khóa kiểm thử phần mềm. Mình viết nội dung bài viết này khi mà tôi cũng đang tìm hiểu về kiểm thử nên không thể tránh khỏi những sơ sót, nếu có phần nào không được đúng lắm thì mong mọi người góp ý để tri thức của tất cả chúng ta ngày càng tiến bộ hơn nhé ! Cảm ơn các bạn