20 Câu Hỏi Về Kiểm Thử Phần Mềm Không Phải Ai Cũng Biết

Chúng ta sống trong một thế giới ngày càng trở nên trực tuyến. Do đó, nhu cầu về phần mềm và ứng dụng mới ngày càng tăng để đáp ứng số lượng người tiêu dùng ngày càng tăng. Tuy nhiên, sự thay đổi này đòi hỏi một cơ chế kiểm soát chất lượng, vì vậy, nhu cầu kiểm thử phần mềm của các doanh nghiệp và tổ chức cũng đang ngày càng phát triển. 

Bài viết này đã tổng hợp 20 câu hỏi về kiểm thử phần mềm để giúp bạn hiểu rõ hơn về quy trình này, từ khái niệm cho tới các quy trình thực hiện, các công cụ kiểm thử, v.v.

20 câu hỏi về kiểm thử phần mềm

1. Kiểm thử phần mềm là gì?

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à đầy đủ 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 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 đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm.

Đây cũng được xem là quá trình xác định xem nó có đáp ứng nhu cầu của các cổ đông hay không cũng như phát hiện các lỗi và xác định chất lượng tổng thể của mặt hàng đó bằng cách đo lường hiệu suất, tính năng, chất lượng, tiện ích và tính đầy đủ của nó. Điểm mấu chốt, đó là kiểm soát chất lượng.

2. Tại sao cần kiểm thử phần mềm?

Sau đây là những lý do quan trọng tại sao các kỹ thuật kiểm thử phần mềm nên được đưa vào phát triển ứng dụng:

• Xác định lỗi sớm
• Nâng cao chất lượng sản phẩm
• Tăng sự tin tưởng và hài lòng của khách hàng
• Phát hiện lỗ hổng bảo mật
• Hỗ trợ khả năng mở rộng
• Tiết kiệm chi phí

3. Kiểm thử phần mềm bao gồm những bước nào?

Quá trình kiểm thử phần mềm sẽ bao gồm những bước sau đây:

• Thực hiện chạy dự án theo yêu cầu của công ty để kiểm thử ứng dụng, phần mềm, web.
• Chuẩn bị thử nghiệm dựa trên các thông tin nghiên cứu và kịch bản thử nghiệm trước đó.
• Dựa vào công cụ hỗ trợ và các dữ liệu sử dụng để kiểm thử, tiến hành làm các bào kiểm tra thử nghiệm.
• Hậu kiểm thử, đảm bảo tiêu chuẩn và chất lượng cho các sản phẩm được kiểm thử bằng cách phối hợp với các bộ phận liên quan để làm việc.

Sau cùng, báo cáo lại kết quả thử nghiệm với cấp trên sau khi đã tiến hành phân tích, theo dõi kết quả thành phẩm nghiêm ngặt.

4. Các kỹ năng cần thiết của một chuyên gia kiểm thử (Tester)?

Người kiểm thử phần mềm cần các kỹ năng như:

• Kỹ năng giải quyết vấn đề
• Khả năng giao tiếp bằng văn bản và bằng lời nói tốt
• Định hướng một cách chi tiết
• Có khả năng xử lý áp lực
• Có thể làm việc một mình hoặc với tư cách là thành viên nhóm tốt như nhau
• Kỹ năng tổ chức
• Chuyên môn kỹ thuật liên quan

5. Kế hoạch kiểm thử (test plan) sẽ bao gồm những gì?

Kế hoạch kiểm tra (test plan) là một tài liệu chính thức chỉ định phạm vi kiểm tra, phương pháp được sử dụng, các tài nguyên cần thiết và thời gian ước tính để hoàn thành quy trình kiểm tra. Nó được bắt nguồn từ các đặc tả kỹ thuật (Software Requirement Specification).

* Lập Test Plan có các lợi ích như:

• Test Plan giúp xác định effort cần thiết để xác nhận chất lượng của ứng dụng đang kiểm thử
• Giúp những người ngoài nhóm kiểm thử như nhà phát triển, quản lý doanh nghiệp, khách hàng hiểu chi tiết về kiểm thử.
• Test Plan hướng dẫn suy nghĩ của chúng ta. Nó giống như một cuốn sách quy tắc, cần phải được tuân theo.
• Các khía cạnh quan trọng như Test Estimation, Test Scope, Chiến lược test được ghi lại trong Test Plan, do đó, nhóm quản lý có thể xem xét và sử dụng lại cho các dự án khác.

* Làm thế nào để lập Test Plan

Vì lập Test Plan là nhiệm vụ quan trọng nhất của Quy trình quản lý kiểm thử. Thực hiện theo 7 bước dưới đây để tạo một kế hoạch kiểm tra theo IEEE 829
Analyze the product – Phân tích sản phẩm

• Design the Test Strategy – Lập chiến lược kiểm thử
• Define the Test Objectives – Xác định mục tiêu kiểm thử
• Define Test Criteria – Xác định tiêu chí kiểm thử
• Resource Planning – Hoạch định nguồn lực
• Plan Test Environment – Kế hoạch môi trường kiểm thử
• Schedule & Estimation – Lịch trình & Dự toán
• Determine Test Deliverables – Quyết định deliver sản phẩn

6. Sự khác biệt giữa các test scenario, test cases, và test script là gì?

Sự khác biệt giữa test scenarios, test cases, và test script là:

• Test Scenario: Kịch bản kiểm thử là bất kỳ chức năng nào có thể được kiểm thử. Nó cũng được gọi là Điều kiện kiểm thử hoặc Khả năng kiểm thử. Scenario testing – kịch bản thử nghiệm cho phép chúng ta chắc chắn rằng chức năng của một ứng dụng được kiểm thử từ đầu đến cuối được đảm bảo là sẽ chạy đúng như dự kiến.

Và cũng để kiểm tra xem tất cả các luồng kinh doanh có làm việc đúng như mong đợi hay không. Trong scenario testing, tester cần phải đặt bản thân vào vị trí của người dùng cuối để kiểm tra và chạy các chức năng của sản phẩm. Việc chuẩn bị các scenario – kịch bản là phần quan trọng nhất đối với các tester, để làm được thì tester sẽ cần tới sự tư vấn hoặc giúp đỡ từ phía khách hàng và các lập trình viên.

• Test case: là một tập hợp các điều kiện hoặc các biến mà tester sẽ xác định xem liệu một ứng dụng, một hệ thống phần mềm hay một trong những chức năng của nó có chạy đúng như nó được thiết lập theo mục đích vốn có hay không.
• Test Script: là bản hướng dẫn chi tiết, viết bằng code (mã) để thực hiện automation testing (kiểm thử tự động). Ngoài ra, bạn cũng cần dùng phần mềm automation testing để thực thi test script. Một số phần mềm được sử dụng phổ biến hiện nay gồm có Selenium, UTF One (Micro Focus Unified Functional Testing), TestComplete, Cucumber,…

7. Có những phương pháp kiểm thử phần mềm nào?

Có 3 phương pháp kiểm thử phần mềm hiện được áp dụng phổ biển:

• Kiểm thử hộp đen (black box testing): phương pháp kiểm thử phần mềm trong đó các chức năng của phần mềm được kiểm tra mà không cần biết về cấu trúc mã nội bộ, chi tiết phát triển khai thác và đường dẫn nội bộ.
• Kiểm thử hộp trắng (white box testing): phương phá kiểm thử trong đó cấu trúc bên trong, thiết kế và mã hóa của phần mềm được kiểm tra để xác minh luồng đầu vào-đầu ra và cải thiện thiết kế, khả năng sử dụng và bảo mật.
• Kiểm thử hộp xám (grey box testing): kiểm thử bảo mật ứng dụng kết hợp giữa kiểm thử hộp trắng và hộp đen.

8. Các cấp độ của kiểm thử phần mềm?

Có bốn cấp độ :

• Unit Test – Kiểm tra mức đơn vị
• Component Test – Kiểm tra thành phần
• Integration Test – Kiểm tra tích hợp
• Regression Test – Kiểm thử hồi 
• System Test – Kiểm tra mức hệ thống
• Acceptance test – Kiểm tra chấp nhận

9. Các mô hình kiểm thử phần mềm được sử dụng hiện nay?

Dưới đây là 6 mô hình kiểm thử phổ biến nhất hiện nay:

• Mô hình thác nước
• Mô hình chữ V
• Mô hình Agile
• Mô hình xoắn ốc
• Phát triển hợp nhất
• Mô hình phát triển ứng dụng nhanh chóng

10. Tester cần nắm được những nguyên tắc kiểm thử phần mềm nào?

Có 7 nguyên tắc quan trọng mà tester cần phải nhớ trong quá trình kiểm thử:

#1:Kiểm thử chứng mình sự hiện diện của lỗi.
#2: Kiểm thử toàn bộ là không thể.
#3: Kiểm thử càng sớm càng tốt.
#4: Lỗi thường được phân bố tập trung.
#5: Nghịch lý thuốc trừ sâu.
#6: Kiểm thử phụ thuộc vào ngữ cảnh.
#7: Quan niệm sai lầm về việc “hết lỗi”.

11. Xác minh (verification) và xác thực(validation) là gì?

Xác minh (Verification) là một quá trình đánh giá các sản phẩm làm việc trung gian của một vòng đời phát triển phần mềm để kiểm tra xem liệu rằng chúng ta có đi đúng hướng để tạo ra sản phẩm cuối cùng.

Các sản phẩm trung gian có thể bao gồm các tài liệu được tạo ra trong các giai đoạn phát triển như, đặc tả requirement, tài liệu thiết kế, thiết kế database, sơ đồ ER, các test case, traceability matrix …Đôi khi chúng ta có khuynh hướng bỏ qua tầm quan trọng của việc xem xét các tài liệu này nhưng chúng ta nên hiểu rằng tự mình rà soát lại có thể tìm ra nhiều điểm bất thường tiềm ẩn mà khi phát hiện hoặc sửa trong giai đoạn phát triển sau đó có thể rất tốn kém.

Mặt khác, xác nhận (Validation) là quá trình đánh giá sản phẩm cuối cùng để kiểm tra xem phần mềm có đáp ứng được yêu cầu nghiệp vụ không? Hoạt động validation bao gồm smoke testing, functional testing, regression testing, systems testing etc…

Sự khác nhau giữa Verification và Validation:

12. Giải thích quy trình kiểm thử thủ công?

Quy trình kiểm tra thủ công như sau:

• Xác định phạm vi kiểm thử: Bước đầu tiên của kiểm thử thủ công là xác định phạm vi kiểm thử. Phạm vi có thể là một mô-đun cụ thể, chức năng, tính năng hoặc hệ thống đầu cuối.
• Thiết kế các trường hợp kiểm thử: Bước tiếp theo là thiết kế các trường hợp kiểm thử dựa trên phạm vi đã xác định. Các trường hợp này nên bao gồm các kịch bản thử nghiệm, dữ liệu, kết quả mong đợi và tất cả các chi tiết cần thiết khác để thực hiện các thử nghiệm.
• Tiến hành: Sau khi thiết kế các trường hợp kiểm thử, tester sẽ thực hiện chúng để tìm ra bất kỳ sự khác biệt nào giữa kết quả mong đợi và kết quả thực tế.
• Ghi lại kết quả: Trong khi thực hiện các thử nghiệm, tester nên ghi lại kết quả để phân tích thêm.

13. Kiểm thử thủ công khác với kiểm thử tự động ra sao?

Kiểm thử thủ công là quá trình kiểm tra lỗi phần mềm theo cách thủ công. Nó yêu cầu người kiểm tra thực hiện các bước kiểm tra theo cách thủ công và so sánh kết quả thực tế và kết quả mong đợi.

Kiểm thử tự động sử dụng phần mềm đặc biệt để kiểm soát việc thực hiện kiểm thử và so sánh kết quả với kết quả mong muốn. Do đó, kiểm thử tự động nhanh hơn nhiều so với kiểm thử thủ công và có thể giảm thời gian cần thiết để hoàn thành chu trình kiểm thử.

14. Một số ưu điểm của kiểm thử tự động?

Đây là một số ưu điểm chính của kiểm thử tự động:

• Thực hiện kiểm tra tự động nhanh chóng và tiết kiệm thời gian đáng kể.
• Lỗi của con người được loại bỏ trong quá trình thử nghiệm khi kịch bản thử nghiệm được chuẩn bị cẩn thận.
• Các công cụ CI như Jenkins, cũng có thể được thiết lập để phân phối kết quả kiểm tra hàng ngày cho các bên liên quan chính, có thể được sử dụng để lên lịch thực hiện kiểm tra chạy hàng đêm.
• Kiểm thử tự động sử dụng ít tài nguyên hơn rất nhiều. Việc thực hiện kiểm thử gần như không yêu cầu QA mất thời gian sau khi các kiểm thử đã được tự động hóa. Băng thông QA có thể được sử dụng cho công việc thăm dò khác.

15. Sự khác biệt giữa thử nghiệm hệ thống và thử nghiệm tích hợp là gì?

Kiểm thử hệ thống là một loại kiểm thử phần mềm nhằm đánh giá một sản phẩm phần mềm hoàn chỉnh và được tích hợp đầy đủ. Nó xác minh rằng phần mềm đáp ứng các yêu cầu được chỉ định trong thiết kế và các thông số kỹ thuật cấp hệ thống. Kiểm tra hệ thống cũng xác định bất kỳ điểm yếu, lỗi hoặc lỗi nào.

Kiểm thử tích hợp là kiểm thử phần mềm xác minh sự tương tác giữa hai hoặc nhiều thành phần hệ thống. Nó được thực hiện sau khi kiểm tra đơn vị và trước khi kiểm tra hệ thống. Nó kiểm tra cách các thành phần tương tác với nhau và cách chúng khớp với nhau. Kiểm thử tích hợp là cần thiết để đảm bảo rằng các thành phần của hệ thống hoạt động cùng nhau như mong đợi.

16. Sự khác biệt giữa smoke testing và sanity testing là gì?

Smoke testing là một thử nghiệm cấp cao được sử dụng để đảm bảo các chức năng quan trọng nhất của hệ thống phần mềm đang hoạt động chính xác. Đây là một bài kiểm tra nhanh có thể được sử dụng để xác định xem có đáng để đầu tư thời gian và năng lượng vào các bài kiểm tra sâu rộng hơn hay không.

Sanity testing là một thử nghiệm cụ thể hơn được sử dụng để kiểm tra xem những thay đổi gần đây đối với hệ thống có gây ra bất kỳ hành vi mới, không mong muốn nào không. Nó đảm bảo rằng các tính năng cơ bản vẫn hoạt động như mong đợi sau khi thực hiện các thay đổi nhỏ.

17. Sự khác biệt giữa thử nghiệm tĩnh và thử nghiệm động là gì?

Kiểm thử tĩnh là một loại kiểm thử được thực hiện mà không thực thi mã của ứng dụng phần mềm. Thay vào đó, nó bao gồm các bài đánh giá, kiểm tra và hướng dẫn.

Kiểm thử động là một loại kiểm thử liên quan đến việc thực thi mã của ứng dụng phần mềm để xác định kết quả của các chức năng và hoạt động nhất định. Nó bao gồm thử nghiệm đơn vị, thử nghiệm tích hợp và thử nghiệm chấp nhận.

18. Làm thế nào để bạn kiểm tra một sản phẩm nếu các yêu cầu vẫn chưa ổn định?

Khi các yêu cầu vẫn chưa đóng băng, cách tiếp cận tốt nhất là sử dụng một phương pháp phát triển nhanh, chẳng hạn như Scrum.

Bước đầu tiên sẽ là tổ chức các cuộc họp thu thập yêu cầu với tất cả các bên liên quan để hiểu mục đích của sản phẩm và kết quả mong muốn.

Bước tiếp theo sẽ là chia dự án thành các câu chuyện người dùng riêng lẻ, có thể quản lý được.

Từ đó, ưu tiên các câu chuyện của người dùng và chỉ định họ chạy nước rút để phát triển.

Khi dự án tiến triển, chúng tôi liên tục kiểm tra sản phẩm bằng các kỹ thuật như kiểm tra đơn vị, kiểm tra tích hợp, kiểm tra mức độ chấp nhận của người dùng và kiểm tra hệ thống. Ngoài ra, khi các yêu cầu thay đổi, chúng tôi sẽ cập nhật các thử nghiệm của mình để đảm bảo sản phẩm đáp ứng các kết quả mong muốn.

19. Khi nào thì nên dừng quá trình kiểm thử?

Dựa vào điều kiện dừng của dự án để biết chính xác lúc nào tester nên dừng kiểm thử. Tùy vào từng dự án mà điều kiện dừng sẽ có sự khác nhau, tuy nhiên thường sẽ bao gồm các điều như:

• Quá thời gian kiểm thử
• Hết ngân sách chi trả
• Đã đạt được yêu cầu về test case và tỷ lệ bug
• Các lỗi phát hiện khi kiểm thử đã được fix
• Sản phẩm ít bug, hoạt động ổn định, tốt
• Kiểm thử đã hoàn thiện, tài liệu đã được cập nhật đầy đủ
• Quản lý dự án quyết định dừng kiểm thử

20. Một số tips khi viết các trường hợp thử nghiệm là gì?

Dưới đây là 10 tips mà các tester có thể sử dụng:

• Phát triển các trường hợp thử nghiệm rõ ràng, ngắn gọn và đi thẳng vào vấn đề.
• Đảm bảo rằng các trường hợp thử nghiệm thách thức chức năng của phần mềm ở mọi khía cạnh.
• Đảm bảo rằng các trường hợp thử nghiệm bao gồm tất cả các yêu cầu.
• Phát triển các trường hợp thử nghiệm lặp lại có thể được tự động hóa khi cần thiết.
• Phát triển các trường hợp thử nghiệm độc lập với nhau.
• Sử dụng tên có ý nghĩa và mô tả cho các trường hợp thử nghiệm.
• Ghi lại kết quả của các trường hợp thử nghiệm để tham khảo trong tương lai.
• Đảm bảo rằng các trường hợp thử nghiệm là mô-đun và có thể được sử dụng lại.
• Thực hiện đánh giá các trường hợp thử nghiệm để đảm bảo tính chính xác và đầy đủ.
• Tài liệu các trường hợp thử nghiệm trong một định dạng tiêu chuẩn.