Dùng thử của phần mềm được tạo ra thế nào năm 2024

✓ Kiểm thử phần mềm (software testing) là một quá trình bao gồm nhiều hoạt động nhằm đánh giá chất lượng các sản phẩm phần mềm và giảm thiểu rủi ro do lỗi gây ra trong quá trình vận hành khi đưa vào sử dụng thực tế. Các hoạt động kiểm thử này bao gồm các hoạt động xem xét đánh giá (review) tài liệu, các bản thiết kế, và bao gồm mã nguồn (source code), các hoạt động này trong thực tế hay gọi là “review” (rà soát). Và các hoạt động kiểm thử được thực hiện trên sản phẩm (nếu bạn gặp từ “dynamic testing”).

Trên đây là khái niệm chuẩn về kiểm thử phần mềm, tuy nhiên trên thực tế có nhiều quan niệm sai lầm về kiểm thử phần mềm, và một trong số đó là mọi người hay cho rằng kiểm thử chỉ là công việc thực thi (chạy) các trường hợp kiểm thử (test cases) trên một ứng dụng phần mềm (web application, desktop application, hay mobile application).

Dưới đây là một số hoạt động kiểm thử cơ bản:

1. Lập kế hoạch kiểm thử (test planning)
2. Phân tích kiểm thử (test analysis)
3. Thiết kế các trường hợp kiểm thử (test design)
4. Thực thi kiểm thử (test execution)
5. Báo cáo kết quả kiểm thử (test reporting)

Mục tiêu kiểm thử thường gặp

Tuỳ vào quy mô của dự án hay loại hình của công ty và giai đoạn phát triển phần mềm mà mục tiêu kiểm thử sẽ khác nhau, tuy nhiên đây là một số mục tiêu kiểm thử thường gặp (danh sách này không mang tính thứ tự và không phải là giới hạn):

1. Kiểm tra xem phần mềm (sản phẩm) đã đáp ứng tất cả yêu cầu đã mô tả chưa hoặc xác nhận xem phần mềm đã hoàn thiện và hoạt động đúng như mong đợi của người dùng và các bên liên quan khác chưa.
2. Kiểm thử để ngăn ngừa lỗi bằng cách review tài liệu mô tả yêu cầu hay thiết kế hệ thống, bao gồm mã nguồn (source code) để phát hiện lỗi sớm.
3. Kiểm thử nhằm nâng cao chất lượng phần mềm, tăng sự tin tưởng của khách hàng đối với phần mềm thông qua việc phát hiện lỗi và sửa lỗi (và dĩ nhiên là phải kiểm thử lại sau khi được sửa).
4. Cung cấp thông tin cho các bên liên quan (bao gồm quản lý dự án hay khách hàng tùy dự án) để họ có thể đưa ra quyết định về việc phát hành (release) một phần mềm nào đó hay không
5. Giảm thiểu rủi ro do lỗi của phần mềm gây ra trong quá trình sử dụng thực tế

Ngoài ra còn nhiều mục tiêu khác như kiểm thử để đánh giá xem hệ thống có đáp ứng các tiêu chuẩn của các tổ chức quốc tế như ISO, CMMI hay quy định của khu vực như GDPR (General Data Protection Regulation).

Các mức kiểm thử (test levels)

Các mức kiểm thử là tập hợp các hoạt động test được thực hiện ở một giai đoạn phát triển cụ thể của sản phẩm, ví dụ từ lúc vài chức năng nhỏ được lập trình, cho đến lúc sản phẩm hoàn thiện, và có thể tích hợp với các hệ thống khác. Dưới đây là một số mức kiểm thử cơ bản:

Kiểm thử (mức) đơn vị (unit testing)

Đây là mức kiểm thử thấp nhất. Ở mức kiểm thử này, các thành phần nhỏ nhất của một hệ thống phần mềm như class, function, hay module sẽ được kiểm thử riêng lẻ. Phần lớn test case (các trường hợp kiểm thử) ở mức này sẽ gọi trực tiếp đối tượng được kiểm thử (như class, function… nào đó) trong code (mã nguồn) nên cần phải có sự hỗ trợ của các thư viện (unit test framework phổ biến như XUnit, JUnit, Nunit, Jest,… đa phần ngôn ngữ lập trình nào cũng có nhiều thư viện hỗ trợ cho unit testing) để giả lập các cụm chức năng (class, function,…) liên quan nhằm tách riêng phần cần kiểm thử.

Khi phát hiện lỗi ở mức kiểm thử này thường sẽ giúp tiết kiệm thời gian và chi phí nhiều vì nếu không được phát hiện lỗi này sớm, có thể nó sẽ gây ra các lỗi tích hợp, hoặc gây ra sự cố khi đưa vào sử dụng thực tế. Lúc này chúng ta phải đi sửa lỗi ở 1 đơn vị code nào đó, và phải test lại (confirmation testing) để xem lỗi này đã được sửa đúng hay chưa, ngoài ra còn phải kiểm thử các khu vực khác để bảo đảm quá trình sửa lỗi không gây ra lỗi mới khác (regression testing).

Ví dụ, như hình bên dưới, để kiểm thử đơn vị code màu vàng, chúng ta phải giả lập các đơn vị có liên quan trực tiếp đến nó (màu xanh tím).

Nguồn hình: https://www.telerik.com/

Trong thực tế, lập trình viên (developer – hay gọi tắt là dev) sẽ phụ trách thực hiện kiểm thử đơn vị. Để xác định trường hợp cần kiểm thử, dev sẽ dựa vào mã nguồn (source code) và tài liệu mô tả yêu cầu chi tiết (SRS – System Requirement Specification) của chức năng đang được kiểm thử là nguồn thông tin bổ sung, giúp xác định kết quả mong đợi cho các test case đó.

Trong ví dụ trong hình dưới, chương trình kiểm tra số nguyên tố đơn giản, không cần phải giả lập gì. Và 2 test case cơ bản để kiểm tra 1 số là số nguyên tố và 1 số không phải là số nguyên tố.

Kiểm thử tích hợp (integration testing)

Ở giai đoạn này, các chức năng (hoặc class, function,…) đã được phát triển và kiểm thử xong, đã đến lúc tích hợp chúng lại với nhau. Và phải kiểm thử sự tương tác qua lại giữa các thành phần này. Tương tự như vậy, chúng ta cũng cần kiểm thử sự tích hợp giữa các hệ thống khác nhau. Hai mức kiểm thử tích hợp thường gặp sau:

Component integration testing

Kiểm thử tích hợp (các) thành phần (trong một hệ thống) là tích hợp các chức năng hoặc module trong cùng một hệ thống (ví dụ, giữa các api của một ứng dụng web hoặc mobile app).

Thường thì lập trình viên (dev) sẽ phụ trách thực hiện mức kiểm thử tích hợp này, hay gọi chung là integration testing.

Ví dụ kiểm thử tích hợp các thành phần trong một hệ thống

Nguồn: https://sceweb.sce.uhcl.edu/

System integration testing

Kiểm thử tích hợp (các) hệ thống là khi các hệ thống độc lập có liên quan đến nhau thì chúng ta cần phải thực hiện kiểm thử tích hợp giữa chúng để đảm bảo rằng chúng đáp ứng các luồng nghiệp vụ mong muốn.

Ví dụ như một hệ thống bán hàng thương mại điện tử bất kỳ thường sẽ sử dụng dịch vụ thanh toán trực tuyến được cung cấp bởi một bên thứ 3 (3rd party) hoặc hệ thống thanh toán trực tuyến do công ty mình phát triển (bởi một nhóm khác). Chúng ta phải kiểm thử các luồng thanh toán cơ bản như thanh toán thành công, không thành công, v.v… Tương tự như chúng ta cần phải kiểm thử tích hợp giữa 1 sàn thương mại điện tử (tiki, lazada) và bên giao hàng như Giao hàng nhanh, giao hàng tiết kiệm.

Thường thì Tester (QC/QA) là người thực hiện việc kiểm thử ở mức tích hợp các hệ thống này.

Phương pháp tích hợp

Một số phương pháp tiếp cận thường gặp để kiểm kiểm thử tích hợp:

• Big-Bang integration testing: tích hợp tất cả các thành phần (cần kiểm thử) cùng một lúc và tiến hành kiểm thử theo các kịch bản, trường hợp cần thiết. Cách tiếp cận này thường gặp, và được áp dụng cho các hệ thống đơn giản, nhỏ, ít thành phần. Khi áp dụng cho các hệ thống lớn thì sẽ gặp nhiều khó khăn trong việc xác định vị trí nơi gây ra lỗi để sửa.
• Top-Down integration testing: Việc kiểm thử được thực hiện từ các đơn vị (module/function) ở cấp trên xuống theo luồng điều khiển của hệ thống. Các đơn vị cao nhất được kiểm tra trước và các cấp đơn vị thấp hơn được kiểm tra từng bước sau đó.
• Bottom-Up integration testing: Ngược lại với Top-Down integration testing, ở phương pháp tiếp cận này các đơn vị cấp thấp được kiểm tra trước và các đơn vị cấp cao hơn sẽ được kiểm tra sau đó.
• Sandwich/Hybrid integration testing: Là sự kết hợp của hai phương pháp Top-Down integration testing và Bottom-Up integration testing. Ở đây, các đơn vị ở cấp cao được kiểm tra với các đơn vị thấp hơn đồng thời các đơn vị thấp hơn được tích hợp với các đơn vị cấp trên cao để kiểm thử.

Trên đây là phương pháp tiếp cận dựa vào cấu trúc/kiến trúc của mã nguồn. Ngoài ra chúng ta có thể tích hợp dựa vào luồng chức năng.

Ví dụ phương pháp tiếp cận kiểm thử tích hợp top-down (nguồn guru99)

Kiểm thử hệ thống (system testing)

Một khi hệ thống đã được phát triển (lập trình) hoàn thiện, chúng ta cần kiểm thử các luồng xử lý chức năng, và một số khía cạnh phi chức năng như hiệu năng (trong đó có load testing – kiểm thử tải) và đánh giá tính khả dụng của hệ thống (usability – xem dễ sử dụng dễ hiểu cho mọi đối tượng người dùng hay không).

Thường sẽ dựa vào tài liệu mô tả chức năng và áp dụng các kỹ thuật kiểm thử hộp đen để viết test case (là end-to-end test case) cho mức kiểm thử này. Cũng có thể dựa vào kinh nghiệm của tester và các vai trò khác trong dự án như PM/PO, khách hàng.

Tester là người thực hiện kiểm thử ở mức này.

Kiểm thử chấp nhận (acceptance testing)

Một khi tester đã thực hiện xong quá trình kiểm thử ở mức hệ thống, thì nhóm nhân viên khác trong công ty đến từ nhóm Chăm sóc khách hàng, Bán hàng,… hoặc khách hàng sẽ thực hiện đánh giá tổng thể hệ thống dựa trên tài liệu mô tả yêu cầu của hệ thống. Hoặc kiểm thử chấp nhận có thể được thực hiện song song với quá trình kiểm thử mức hệ thống.

Quá trình kiểm thử chấp nhận sẽ trả lời cho các câu hỏi như:

• Hệ thống đã sẵn sàng đưa vào sử dụng thực tế chưa?
• Hệ thống chạy đã đáp ứng như mong đợi của người dùng chưa?
• Có thể chấp nhận và thanh toán tiền cho sản phẩm này không?
• Vân vân…

Vậy ta có thể thấy, system testing là kiểm thử xem hệ thống có đúng yêu cầu không, với mục đích là tìm lỗi. Còn kiểm thử chấp nhận ở đây là xem phần mềm có chạy đúng như người dùng và các bên liên quan mong đợi hay chưa.

Riêng các công ty phát triển phần mềm theo dạng đóng gói hoặc sản phẩm cung cấp cho một nhóm khách hàng người dùng đặc thù (COTS software) thì có 2 dạng kiểm thử chấp nhận thường gặp như:

• Alpha testing: Được thực hiện tại nơi phát triển phần mềm bởi những người không tham gia trực tiếp vào quá trình phát triển chúng (như các nhân viên đến từ nhóm chăm sóc khách hàng, bán hàng, hay các nhóm phát triển phần mềm khác). Thường được thực hiện trước khi thực hiện beta testing.
• Beta testing: Có thể được thực hiện sau hoặc song song với alpha testing. Được thực hiện bởi người dùng (thường là khách hàng). Beta testing thường được diễn ra ở phía khách hàng và người dùng sản phẩm trên môi trường thực tế của họ (như máy tính hoặc điện thoại của khách hàng).

Tuy nhiên, tester cũng thường phối hợp với khách hàng trong giai đoạn kiểm thử chấp nhận này (tùy theo yêu cầu của dự án).

Các loại kiểm thử (test types)

Loại kiểm thử là các nhóm các hoạt động kiểm thử được thực hiện để nhắm đến một mục đích cụ thể nào đó, ví dụ như để đánh giá chức năng, hiệu năng, hay các khía cạnh khác. Sau đây là một số loại kiểm thử thường gặp:

Kiểm thử chức năng (functional testing)

Các hoạt động kiểm thử chức năng sẽ tập trung vào việc kiểm tra xem hệ thống có hoạt động theo đúng theo yêu cầu nghiệp vụ đã mô tả hay chưa. Tập trung đánh giá tính đúng đắn, mức độ chính xác, và tính phù hợp của hệ thống với người dùng, và một số khía cạnh khác. Kiểm thử chức năng có thể được thực hiện ở tất cả các mức kiểm thử.

Dưới đây là 2 cách tiếp cận để kiểm thử chức năng:

Requirements-based testing: quan điểm này dựa vào tài liệu mô tả yêu cầu của hệ thống (như SRS – software requirement specification) để viết test case và thực hiện kiểm thử.

Cách tốt để bắt đầu là:

1. Sử dụng nội dung của đặc tả yêu cầu để xác định phạm vi kiểm thử (danh sách các hạng mục cần kiểm thử và sẽ không kiểm thử)
2. Chúng ta nên xét độ ưu tiên của các yêu cầu này dựa trên mức độ rủi ro và độ ưu tiên để kiểm thử. Điều này sẽ đảm bảo những chức năng quan trọng nhất sẽ được kiểm thử trước.

Business-process-based testing: sẽ sử dụng các kiến thức/hiểu biết về quy trình nghiệp vụ để viết test case và thực hiện kiểm thử. Dựa vào quy trình nghiệp vụ chúng ta có thể xác định được các kịch bản có thể xảy ra trong thực tế, giúp phát hiện sớm các lỗi liên quan đến xử lý nghiệp vụ.

Ví dụ khi kiểm thử chức năng chuyển tiền liên ngân hàng có thể chúng ta phát hiện lỗi liên quan đến trường hợp ngân hàng của người nhận đang bảo trì (khi đó server sẽ không liên lạc được) hoặc xử lý chậm (do quá tải hệ thống). Và đây là trường hợp rất có thể sẽ gặp phải trong thực tế, nhất là cuối tuần.

Kiểm thử phi chức năng (non-functional testing)

Là các hoạt động kiểm thử nhằm đánh giá các đặc điểm chất lượng, hoặc thuộc tính phi chức năng như hiệu năng, bảo mật, và tính dễ sử dụng.

Việc kiểm thử này cũng giống như kiểm thử chức năng, được thực hiện ở mọi mức kiểm thử (test level). Ví dụ khi áp dụng kiểm thử hiệu năng ở mức hệ thống thì thường sẽ:

• Thực hiện các hoạt động kiểm thử để đánh giá mức chịu tải của hệ thống (đánh giá xem hệ thống có thể xử lý được bao nhiêu yêu cầu cùng lúc) thì đó là kiểm thử tải (load testing). Các công cụ (tool) hữu ích trong kiểm thử hiệu năng gồm: JMeter, K6
• Hoặc kiểm thử tính khả dụng (usability testing) là các hoạt động đánh giá xem hệ thống dễ sử dụng như thế nào.

Kiểm thử bảo trì (maintenance testing)

“Kiểm thử bảo trì” mô tả các hoạt động kiểm thử được thực hiện trên một hệ thống đang vận hành và sử dụng thực tế. Các kỹ thuật và phương pháp tiếp cận để kiểm thử cũng không có gì đặc biệt lắm so với việc kiểm thử được thực hiện trong quá phát triển phần mềm. Tuy nhiên có 2 khái niệm kiểm thử quan trọng cần lưu ý như sau:

Kiểm thử xác nhận (Confirmation testing): là quá trình kiểm thử xem một lỗi (bug/defect) đã được sửa (fix) đúng, hay một thay đổi yêu cầu đã được thực hiện đúng như mong đợi hay chưa. Nơi thực hiện kiểm thử là vị trí những chỗ được thực hiện thay đổi (nơi được thực hiện thay đổi).

Kiểm thử hồi quy (Regression testing): là quá trình kiểm thử đánh giá các khu vực không bị thay đổi để xem chúng có bị ảnh hưởng do quá trình thực hiện thay đổi hay sửa lỗi (fix bug) gây ra. “Regression” là những tác dụng phụ không mong muốn khi thực hiện thay đổi trong hệ thống (khi sửa đổi mã nguồn/source code) nên regression testing là kiểm thử để tìm kiếm những tác dụng phụ không mong muốn này. Thường các test case cho loại kiểm thử này sẽ được tự động hoá (gọi là automated test case) vì chúng thường xuyên được thực thi (sử dụng) nhiều lần trong suốt quãng đời phát triển và bảo trì phần mềm (thêm tính năng mới, xoá hoặc sửa các tính năng hiện có).

Các khái niệm trên cũng đồng thời áp dụng cho các hoạt động kiểm thử trong quá trình phát triển phần mềm, khi bạn kiểm thử trên các phần chức năng (hay module) đã được phát triển (lập trình) xong trước đó rồi (ví dụ trong các Sprint trước). Và bây giờ có một vài thay đổi liên quan đến các phần code/chức năng này thì chúng ta cũng phải “test lại” để bảo đảm “mọi thứ vẫn ổn” (nghĩa là các chức năng cũ vẫn còn hoạt động như cũ – regression testing), bên cạnh việc kiểm thử để xác nhận các yêu cầu mới hay fix bug đã được thực hiện đúng (confirmation testing).

Ví dụ về phạm vi kiểm thử của confirmation testing và regression testing.

Nguồn: https://www.softwaretestinggenius.com)

Các kỹ thuật kiểm thử hộp đen (black-box testing)

Kiểm thử hộp đen (black-box testing) là các kỹ thuật giúp bạn xác định test case (các trường hợp kiểm thử) dựa vào các loại tài liệu như tài liệu mô tả yêu cầu (requirement specification), user story (thường thấy trong mô hình Scrum), tài liệu thiết kế (design document) và nhiều loại tài liệu khác.

Trong quá trình kiểm thử (ở mọi mức từ unit testing đến kiểm thử hệ thống), khi áp dụng kỹ thuật kiểm thử hộp đen thì bạn chỉ tập trung vào “bề ngoài của phần mềm” mà không cần quan tâm nó được lập trình bằng ngôn ngữ gì hay cách nó hoạt động như thế nào. Vì thế, điểm yếu của kỹ thuật này là cho dù bạn có số lượng test case khổng lồ thì bạn cũng sẽ rất mơ hồ và không tự tin rằng mình đã kiểm thử đủ hay chưa. Dẫn đến trường hợp, khi PM hay khách hàng nói “bạn cần kiểm thử nhiều hơn” thì bạn cũng không thể thuyết phục họ rằng bạn đã test “quá đủ” hay “chưa đủ” theo yêu cầu.

Một số kỹ thuật hộp đen phổ biến bao gồm: phân vùng tương đương, phân tích giá trị biên, kiểm thử dựa vào bảng quyết định, và kiểm thử dựa vào chuyển đổi trạng thái,…. sẽ được mô tả sơ lược như sau:

Phân vùng tương đương (equivalence testing)

Khi áp dụng kỹ thuật kiểm thử này, chúng ta sẽ dựa vào các giá trị đầu vào hoặc kết quả đầu ra được mô tả trong tài liệu để chia chúng ra thành các nhóm có giá trị tương đồng nhau. Mong muốn các giá trị trong nhóm được xử lý theo một cách giống nhau (bên trong phần mềm).

Sau khi áp dụng xong, kết quả chúng ta sẽ có được các phân vùng tương đương (equivalence partition) thường sẽ bao gồm 2 loại:

• Vùng tương đương hợp lệ (chứa các giá trị hợp lệ)
• Vùng tương đương không hợp lệ (chứa các giá trị không hợp lệ)

Trong đó

• Các giá trị hợp lệ (valid value) là các giá trị được hệ thống chấp nhận
• Các giá trị không hợp lệ (invalid value) là các giá trị không được hệ thống chấp nhận

Ví dụ: hình bên dưới là yêu cầu về độ dài “Tên người dùng” khi bạn tạo tài khoản Gmail mới

Với yêu cầu trên thì các vùng tương đương sẽ là

Test case tối thiểu cần phải có là:

• TC1: Kiểm thử với Tên người dùng nằm trong khoảng từ 6 đến 30 ký tự
• TC2: Kiểm thử với Tên người dùng ít hơn 6 ký tự
• TC3: Kiểm thử với Tên người dùng nhiều hơn 30 ký tự

Phân tích giá trị biên (boundary value analysis)

Sau khi bạn đã áp dụng kỹ thuật phân vùng tương đương xong, nếu các vùng tương đương là các dãy số liên tục (kỹ thuật này chỉ áp dụng được cho các loại dữ liệu kiểu số, ngày tháng,… và có tính liên tục theo chiều tăng hoặc giảm) thì bạn nên áp dụng tiếp kỹ thuật phân tích giá trị biên này. Vì vậy, mọi người xem đây là một kỹ thuật mở rộng của kỹ thuật phân vùng tương đương.

Kỹ thuật này hướng dẫn chúng ta tập trung kiểm thử các giá trị lân cận (xung quanh) của mọi cạnh của các vùng tương đương. Có nhiều cách để xác định giá trị biên, nhưng đây là một cách đơn giản nhất và dễ áp dụng mà hiệu quả phát hiện bug lại cao.

Dựa vào ví dụ trên, thì chúng ta sẽ ghi thêm các giá trị biên vào

• Giá trị biên hợp lệ: 6 và 30
• Giá trị biên không hợp lệ: 5 và 31 (Tên người dùng quá ngắn hoặc quá dài)

Test case tối thiểu cần phải có là:

• TC1: Kiểm thử với Tên người dùng có độ dài 6 ký tự (mong muốn: cho phép)
• TC2: Kiểm thử với Tên người dùng có độ dài 30 ký tự (mong muốn: cho phép)
• TC3: Kiểm thử với Tên người dùng có độ dài 5 ký tự (mong muốn: không cho phép vì quá ngắn)
• TC4: Kiểm thử với Tên người dùng có độ dài 31 ký tự (mong muốn: không cho phép vì quá dài)

Bảng quyết định (decision table testing)

Kỹ thuật này giúp bạn viết test case dựa vào tổ hợp có thể có của các điều kiện đầu vào. Thường thì mỗi kết hợp các điều kiện này sẽ tương ứng với một yêu cầu nghiệp vụ được mô tả trong tài liệu.

Kỹ thuật này thường được áp dụng cho các yêu cầu có nhiều điều kiện phức tạp, phụ thuộc lẫn nhau.

Nguồn: https://www.testingvn.com

Trong ví dụ trên, mỗi cột là một tổ hợp duy nhất của các điều kiện (số tiền đang nợ, lịch sử tín dụng, số tiền mua nợ) và kết quả (action/hành động) tương ứng của tổ hợp này (cũng là kết quả mong đợi). Mỗi cột này sẽ tương ứng với một mô tả trong tài liệu yêu cầu. Tuy nhiên, chúng ta cũng nên gộp các cột tương đồng để giảm số lượng test case dư thừa trùng lặp, ví dụ cột 3 và cột 4 có thể gộp lại thành test case như sau:

Kiểm tra trường hợp khách mua hàng không thành công khi số tiền nợ hiện có đã đạt giới hạn, và quá trình chi trả không tốt. (Trong trường hợp này không quan tâm số tiền mua hiện tại là bao nhiêu).

Kiểm thử chuyển đổi trạng thái (state transition testing)

Kỹ thuật này giúp bạn viết test case dựa vào các lược đồ mô tả trạng thái (state) và các chuyển đổi qua lại giữa các trạng thái (transition). Trong hình ví dụ bên dưới có 6 trạng thái (state) và 10 chuyển đổi (transition).

Với kỹ thuật này, để bao phủ tốt, bạn sẽ viết test case theo tiêu chí:

1. đi qua (bao phủ) mọi trạng thái
2. đi qua mọi chuyển đổi (1 lần, 2 lần,… n lần)

Vui lòng xem thêm state transition testing ở video ngắn này (tiếng Việt).

Ngoài ra còn có pairwise testing, là kỹ thuật kiểm thử giúp bạn xác định số lượng tối thiểu các kết hợp của điều kiện nhập đầu vào. Giúp bạn xác định được số lượng test case tối thiểu tuy nhiên vẫn bao phủ mọi kết hợp theo cặp (pair) các giá trị đầu vào (thường là các hạng mục trên màn hình hoặc “parameter” – tham số đầu vào – của các API).

Trên đây là một số thông tin cơ bản về kiểm thử phần mềm. Nhưng nếu bạn không học công nghệ thông tin như mình, để hiểu nhiều hơn và có thể làm được tester thì bạn cần phải học nhiều kiến thức và kỹ năng khác nữa như cách phân tích tài liệu, viết test case. Các kiến thức cơ bản cần thiết như cách hoạt động của một ứng dụng web để có thể kiểm thử web hiệu quả. Hoặc các kiến thức liên quan đến kỹ thuật như API testing hay SQL cơ bản.

Đây là bài “luận cuối khóa Fresher Tester khoá FK54” của em, cám ơn anh Sơn, chị An, và các anh chị Mentor đã xem và đề xuất chỉnh sửa qua lại hơn chục lần.

Anh, chị và các bạn có bổ sung gì vui lòng để lại bình luận bên dưới bài viết, em sẽ cập nhật bài viết sau.