Tìm hiểu về kiểm thử (Tesing) trong phát triển phần mềm

Trong bài viết này, chúng ta sẽ cùng tìm hiểu về kiểm thử phần mềm (testing). Một công việc không thể thiếu trong việc xây dựng bất kỳ chương trình nào, để đảm bảo chương trình hoạt động đúng với những yêu cầu thực tế đề ra.

Kiểm thử (testing) là gì?

Kiểm thử (tesing) là một quá trình đánh giá một hệ thống hay là các thành phần của nó với mục đích là xác định xem nó có thỏa mãn những yêu cầu được đưa ra hay không, có sự khác biệt nào giữa phần mềm thực tế đang tồn tại và những điều kiện được yêu cầu (requirement). Hiểu một cách đơn giản, kiểm thử – test là chạy một quá trình để xác nhận bất kì thiếu sót (defect), lỗi (bug), sai sót (error) hay những yêu cầu bị bỏ quên, những yêu cầu không đúng so với yêu cầu thực tế đề ra.

Ai sẽ là người test?

Điều này phụ thuộc vào quy trình và các bên liên quan đến dự án. Trong những công ty lớn có một team chuyên chịu trách nhiệm việc đánh giá phần mềm đã phát triển với những yêu cầu được chỉ định từ trước. Ngoài ra, nhân viên phát triển phần mềm (deverloper) cũng tiến hành kiểm thử – test sản phẩm, và việc đó được gọi là unit testing. Trong hầu hết các trường hợp, người kiểm thử (tester) có thể là :

• Software Tester : Nhân viên kiểm thử phần mềm.
• Software Deverloper : Nhân viên phát triển phần mềm.
• Leader hoặc Manager của dự án.
• User : Người sử dụng cuối cùng.

Các công ty khác nhau sẽ có các quy định về tên gọi của nhân viên kiểm thử dựa trên kinh nghiệm và kiến thức về kiểm thử phần mềm, như là: software tester – nhân viên kiểm thử phần mềm, software quality assurance engineer – kĩ sư đảm bảo chất lượng phần, QA analyst – nhân viên phân tích chất lượng phần mềm …

Thời điểm bắt đầu test

Việc kiểm thử – test sớm sẽ giúp giảm chi phí và thời gian để xây dựng lại và sửa lỗi để bàn giao sản phẩm phần mềm. Trong một vòng đời của phần mềm, việc test nên được bắt đầu từ khi có những yêu cầu từ phía khách hàng và được kéo dài đến cho đến khi triển khai phầm mềm. Thời điểm bắt đầu kiểm thử còn phụ thuộc vào mô hình phát triển phần mềm đang được sử dụng. Ví dụ như: trong mô hình thách nước – waterfall model, test chính thức được thực hiện ở giai đoạn kiểm thử – testing phase. Nhưng ở trong mô hình gia tăng – incremental model, kiểm thử được thực hiện ở cuối mỗi chu kỳ con và kiểm thử cho toàn bộ sản phẩm được thực hiện ở giai đoạn cuối khi hoàn thiện sản phẩm.

Việc test được thể hiện theo nhiều dạng công việc khác nhau ở các giai đoạn khác trong suốt vòng đời phát triển phần mềm:

• Trong quá trình tập hơp yêu cầu (requirement gathering phase) : phân tích và xác minh yêu cầu cũng được coi là kiểm thử – test requirement.
• Trong giai đoạn thiết kế (design phase) : kiểm tra lại thiết kế với mục đích cải thiện thiết kế cũng được tính là kiểm thử.
• Trong giai đoạn phát triển phần mềm (implement phase) : kiểm thử được thực hiện bởi lập trình viên – unit testing cũng được tính là kiểm thử.

Khi nào thì dừng việc test

Rất khó để xác định khi nào thì dừng kiểm thử – test, vì test là quá trình ko bao giờ kết thúc và không ai có thể yêu cầu phần mềm được test 100%. Các khía cạnh dưới đây có thể được cân nhắc cho việc dừng lai quy trình test:

• Hạn chót phát triển phần mềm (deadline).
• Đã thực hiện hết các test-case được đề ra.
• Hoàn thiện các chức năng và toàn bộ code đã đảm bảo được các yêu cầu đề ra.
• Tỷ lệ bug phải trong giới hạn mong muốn.
• Không có những bug nghiêm trọng.
• Quyết định của quản lý dự án.

Phân loại Tesing

Theo phương thức tiếp cận có thể chia làm 2 loại testing: phương thức kiểm thử hộp đen (black-box testing) và phương thức kiểm thử hộp trắng (white-box testing).

• Black-box testing : chúng ta không cần quan tâm những gì xử lý trong cái hộp đen đó làm, chỉ cần cho đầu vào và xác nhận đầu ra. Đây chính là những gì bộ phận QA độc lập thực hiện.
• White-box testing : chúng ta cần quan tâm những gì xử lý trong hộp trắng đó làm, tức là code được viết như thế nào, kiến trúc, logic xử lý ra sao. Đây chính là một phần mà developer cần làm.

Thông thường, Black-box testing sẽ là Acceptance Testing do bộ phận QA thực hiện, White-box testing sẽ là Unit Testing/ Integration Testing/ Functional Testing do Developer thực hiện .

Unit Testing (kiểm thử đơn vị)

Định nghĩa

Unit Testing (UT) là một mức kiểm thử phần mềm với mục đích để xác nhận từng unit của phần mềm được phát triển đúng như được thiết kế. UT là mức test nhỏ nhất trong bất kỳ phần mềm nào. UT bản thân nó là cái gì đó khá trừu tượng vì tùy dự án, chúng ta có thể quy định “unit” ở mức độ nào. Thông thường, “unit” sẽ được quy định giới hạn trong một hàm (method) hay một class. Trong thực tế, tùy vào kinh nghiệm và kĩ năng, developer sẽ đưa ra quyết định viết các UT như thế nào cho phù hợp, có thể test đầu vào đầu ra của hàm, hay kiểm tra một phần hoặc toàn bộ class.

Tại sao phải unit test?

• Đôi khi do tính chủ quan của developer, họ thường không kiểm tra lại đoạn code mình đã phát triển dẫn đến lỗi hệ thống hoặc trả ra kết quả không mong đợi. Những ảnh hưởng trên dẫn đến việc tốn kém thời gian và tiền bạc để sửa lỗi.
• UT còn giúp developer tăng khả năng tối ưu hóa code của mình hơn, nâng cao khả năng tư duy về code.
• Việc xử lý những vấn đề sớm khi UT có thể xử lý rất nhiều vấn đề khác có thể xảy ra sau này trong quá trình development và testing.
• Chi phí cho UT thì ít hơn nhiều so với các phase testing sau như là system testing, acceptance testing và nhất là chi phí khi issues/bus qua đến bên khách hàng.
• Đo lường được những đoạn code nào đã pass, những đoạn code nào chưa pass. Và developer có thể cover ngay đoạn code đó sau khi chạy UT.
• Giảm lượng bugs phát sinh ở các giai đoạn testing tiếp theo (system testing, acceptance testing, …).
• Phát hiện sớm các vấn đề về thiết kế, xử lý hệ thống, thậm chí các mô hình thiết kế.
• Tiết kiệm thời gian development. Việc viết UT và execute có thể sẽ tốn nhiều thời gian nhưng nó làm cho code đầy đủ hơn và phát sinh ít issues/bugs hơn. Thay vì coding nhanh và phát sinh rất nhiều issues thì hay coding song song với viết UT và execute, có thể sẽ tốn nhiều thời gian hơn bình thường nhưng sẽ hạn chế những phát sinh sau này.
• Tạo hàng rào an toàn cho các đoạn code: bất kỳ sự thay đổi nào cũng có thể tác động đến hàng rào này và thông báo những nguy hiểm tiềm tàng.

Khi nào thực hiện?

UT là mức kiểm thử đầu tiên trong các mức kiểm thử phần mềm, nó được thực hiện trước khi Integration Testing.

Ai thực hiện?

UT thường do lập trình viên thực hiện. UT nên được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt quá trình phát triển phần mềm.

Mục đích

• 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.
• Tăng sự đảm bảo khi có sự thay đổi mã.
• Code dễ sử dụng, dễ hiểu, có thể tái sử dụng nhiều hơn, debug dễ dàng.
• Chi phí sửa lỗi thấp hơn so với các mức kiểm thử giai đoạn sau.

Integration Testing (kiểm thử tích hợp)

Định nghĩa

Integration Testing (IT) là một mức của kiểm thử phần mềm với mục đích kiểm tra một nhóm các module nhỏ liên quan đến nhau xem chúng có hoạt động được với nhau đúng chức năng như trong thiết kế hay không. Theo ISTQB ( International Software Testing Qualifications Board):

• Kiểm thử tích hợp được thực hiện để phát hiện các lỗi về giao diện hoặc trong tương tác giữa các thành phần hoặc hệ thống tích hợp
• Kiểm thử tích hợp thành phần: kiểm tra sự tương tác giữa các thành phần với điều kiện các thành phần đã pass ở phần kiểm thử thành phần trước đó
• Kiểm thử tích hợp hệ thống: kiểm tra sự tương tác giữa các hệ thống con khác nhau và các hệ thống này đã pass ở lần kiểm thử trước đó.

Tại sao phải Integration Testing?

Mặc dù mỗi module đều được unit test nhưng các lỗi vẫn còn tồn tại với các lý do khác nhau:

• Một Module nói chung được thiết kế bởi một developer có kiến thức và logic lập trình có thể khác với các lập trình viên khác. Kiểm thử tích hợp là cần thiết để đảm bảo tính hợp nhất của phần mềm.
• Tại thời điểm phát triển module vẫn có thể có thay đổi trong đặc tả yêu cầu của khách hàng, những thay đổi này có thể không được kiểm tra ở giai đoạn unit test trước đó.
• Giao diện và cơ sở dữ liệu của các module có thể chưa hoàn chỉnh khi được tíc hợp lại.
• Khi tích hợp hệ thống các module có thể không tương thích với cấu hình chugn của hệ thống.
• Thiếu các xử lý ngoại lệ có thể xảy ra.

Khi nào thực hiện?

IT là mức thứ 2 trong các mức kiểm thử phần mềm. Nó được thực hiện sau Unit Test và trước System Test.

Ai thực hiện?

IT có thể được thực hiện bởi developer, một test team chuyên biệt hay một nhóm chuyên developer/kiểm thử viên tích hợp bao gồm cả kiểm thử phi chức năng.

Mục đích

• Kiểm tra sự tích hợp 1 nhóm các thành phần riêng lẻ có liên quan xem chúng có hoạt động đúng như mong đợi hay không.
• Nhằm phát hiện lỗi giao tiếp xảy ra giữa các thành phần cũng như lỗi của bản thân từng thành phần (nếu có). 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 hệ thống nhỏ (sub-system) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test).
• Thành phần có thể là:  các module,  các ứng dụng riêng lẻ, các ứng dụng Client/ Server.

Phân loại

Có 4 loại kiểm tra trong Integration Test.

• Kiểm tra cấu trúc (structure): Tương tự White Box Testing (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.
• Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.
• Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.
• Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.

Một số chiến lược kiểm tra tích hợp (Integration Testing Strategy)

Big bang integration (Non-incremental) : là phương pháp test tích hợp mà tất cả hoặc hầu hết các unit được kết hợp với nhau và cùng được kiểm thử. Phương pháp này được thực hiện khi team kiểm thử nhận được toàn bộ phần mềm. Như vậy Bigbang testing là kiểm tra sự tương tác giữa các unit, còn system test là sự tương tác của cả hệ thống.

• Ưu điểm: Thuận tiện với các dự án nhỏ.
• Nhược điểm: Khó khăn trong việc phát hiện bug. Có thể bỏ qua các bug giao diện nhỏ trong quá trình test. Mất thời gian dành cho tích hợp hệ thống nên làm giảm thời gian dành cho test. Vì các module được kiểm thử cùng 1 lúc nên các module có nguy cơ bị cô lập trong quá trình kiểm thử.

Phương pháp tiếp cận Incremental: trong phương pháp này, kiểm tra được thực hiện bằng cách kết hợp hai hay nhiều module có liên quan một cách hợp lý. Sau đó, các phân hệ liên quan khác được thêm vào và kiểm tra sự hoạt động đúng đắn. Quá trình tiếp tục cho đến khi tất cả các module được tham gia và thử nghiệm thành công. Quá trình này được thực hiện bằng cách sử dụng các chương trình giả gọi là Stub and Driver. Sơ khai và trình điều khiển không thực hiện toàn bộ logic lập trình các module nhưng chỉ mô phỏng giao tiếp dữ liệu với các module được gọi.

• Stub: Được gọi bởi Module dưới Test.
• Driver: Gọi Module để được kiểm tra.

Phương pháp Incremental được thực hiện bởi hai phương pháp khác nhau:

• Bottom up integration : đơn vị cao nhất được kiểm thử đầu tiền, đơn vị thấp hơn được kiểm thử sau đó một các tuần tự.
  • Ưu điểm: Thu gọn phạm vi bug dễ dàng hơn. Không mất thời gian chờ tất cả các module được tích hợp.
  • Nhược điểm: Module quan trọng của hệ thống có thể dễ bị lỗi. Không giữ được nguyên mẫu đầu tiên của hệ thống
• Top down integration : đơn vị dưới cùng được kiểm thử đầu tiên, đơn vị cao hơn được kiểm thử tuần tự sau đó.
  • Ưu điểm: Thu gọn phạm vi bug dễ dàng hơn. Khả năng để có được một nguyên mẫu ban đầu.
    Modules quan trọng đang được thử nghiệm trên mức ưu tiên; lỗi trong thiết kế lớn có thể được tìm thấy và cố định đầu tiên.
  • Nhược điểm: Cần nhiều Stub. Module ở mức độ thấp hơn sẽ được kiểm tra không đầy đủ.
• Sandwich/ Hybrid integration : là sự kết hợp của các phương pháp Top Down và Bottom Up.

System Testing (kiểm thử hệ thống)

Định nghĩa

System Testing là một mức của kiểm thử phần mềm. Giai đoạn này sẽ hoàn thiện và hợp nhất phần mềm để kiểm thử. Theo ISTQB định nghĩa: quy trình của kiểm thử tích hợp hệ thống để xác nhận xem hệt hống phần mềm có đáp ứng đúng theo đặc tả yêu cầu.

Tại sao cần system test?

• Sau khi hoàn thành quá trình test tích hợp chúng ta cần phải kiểm tra thêm về độ tương thích và tương tác với các thiết bị ngoại vi bên ngoài của ứng dụng để kiểm tra tính khả dụng của nó.
• System test là việc xác minh kiểm tra kỹ lưỡng của mỗi đầu vào trong các ứng dụng để kiểm tra các kết quả mong muốn.
• Thử nghiệm các kinh nghiệm của người dùng với các ứng dụng.

Khi nào thực hiện?

Kiểm thử hệ thống là mức kiểm thử thứ 3 trong các mức kiểm thử phần mềm được thực hiện sau kiểm thử tích hợp (Integration Testing) và trước kiểm thử chấp nhận (Acceptance Testing).

Ai thực hiện?

Thông thường, các tester thực hiện kiểm thử hệ thống. Các tester này thường hoàn toàn độc lập với nhóm phát triển dự án.

Mục đích

Mục đích của giai đoạn này là để đánh giá sự hoạt động của hệ thống có đúng theo như tài liệu đặc tả.

Phân loại System Testing

• Basic testing : để chứng tỏ hệ thống có thể cài đặt được, cấu hình được và hoạt động được.
• Functional Testing : kiểm thử chức năng nhằm đảm bảo chức năng phần mềm được vận hành theo đúng mục đích (requirements) đưa ra.
• Scalability testing : xác định giới hạn quy mô của hệ thống, như quy mô người dùng, quy mô địa lý, quy mô nguồn lực.
• Reliability testing : đánh giá khả năng hệ thống giữ hoạt động trong thời gian dài mà không gây ra failures.
• Documentation testing : đảm bảo system’s user guides là chính xác và khả dụng.
• Usability Testing : kiểm tra tính khả dụng của ứng dụng, chủ yếu tập trung kiểm tra sự dễ sử dụng, tính linh hoạt, tính thân thiện của sản phẩm.
• Load and Stability Testing :kiểm tra khả năng ổn định của hệ thống trong thời gian dài với toàn tải.
• Performance testing : đánh giá hiệu năng của hệ thống chẳng hạn băng thông, phản hồi dưới các điều kiện khác nhau.
• Regression Testing : kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra một thay đổi mã chính. Đảm bảo hệ thống vẫn ổn định khi tích hợp thêm các hệ thống con khác và khi bảo trì.
• Recovery Testing : kiểm thử phục hồi là kiểm thử được thực hiện sau khi có các sự cố hệ thống dẫn đến chương trình lỗi, không hoạt động được. Kiểm thử phục hồi được thực hiện để đảm bảo chương trình sau khi khắc phục lỗi trên không xảy ra bug
• Migration Testing : kiểm thử di động được thực hiện để đảm bảo tính linh động của phần mềm, phần mềm có thể di chuyển được chuyển từ cơ sở hạ tầng hệ thống cơ sở hạ tầng hệ thống cũ để hiện tại không có bất kỳ vấn đề.
• Hardware/Software Testing : đây là khi các thử nghiệm tập trung chú ý về sự tương tác giữa các phần cứng và phần mềm trong quá trình thử nghiệm hệ thống.
• Robustness testing : xác định xem khả năng phục hồi của hệ thống từ input errors và các tình huống failure khác.
• Inter-operability testing : xác định xem hệ thống có thể tương thích (inter-operate) với các sản phẩm của bên thứ 3.

Sự khác nhau giữa Integration Test và System Testing

Testing Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Testing chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Testing.

Acceptance Test (kiểm thử chấp nhận)

Định nghĩa

Acceptance Testing về cơ bản là mô phỏng các thao tác của người dùng sử dụng sản phẩm để xem kết quả người dùng nhận được có đúng như mong muốn không.

Khi nào thực hiện?

Acceptance Testing là mức thứ 4 được thực hiện sau khi hoàn thành kiểm thử hệ thống và trước khi đưa sản phẩm vào sử dụng chính thức.

Ai thực hiện?

Kiểm thử chấp nhận được chia thành 2 mức khác nhau:

• Kiểm thử alpha: được thực hiện bởi những người trong tổ chức nhưng không tham gia phát triển phần mềm.
• Kiểm thử beta: được thực hiện bởi khách hàng/ người dùng cuối tại địa điểm của người dùng cuối (hoặc ủy quyền cho một nhóm thứ ba thực hiện).

Lưu ý: không nhất thiết phải thực hiện tất cả các loại kiểm tra nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.

Mục đích

Đảm bảo phần mềm đáp ứng đúng yêu cầu nghiệp vụ của khách hàng. Sản phẩm nhận được sự chấp nhận từ khách hàng/ người dùng cuối.

Manual Testing và Automation Testing

Manual Testing và Automation Testing là gì?

• Manual Testing : là việc thử nghiệm một phầm mềm hoàn toàn được làm bằng tay bởi người tester. Nó được thực hiện nhằm phát hiện lỗi trong phầm mềm đang được phát triển. Trong manual testing, tester sẽ thực hiện các trường hợp kiểm thử và tạo báo cáo kiểm thử hoàn toàn thủ công mà không có bất kỳ sự trợ giúp của công cụ tự động nào.
• Automation Testing : là phương pháp kiểm thử tự động. Người tester sẽ phải viết các kịch bản kiểm thử sau đó sử dụng các tool hỗ trợ để thực hiện kiểm thử, phương pháp này sẽ giúp việc kiểm thử hiệu quả và tốn ít thời gian hơn. Automation testing giúp chạy các kịch bản kiểm thử lặp lại nhiều lần và các task kiểm thử khác khó thực hiện bằng tay như performance testing và stress testing.

Ưu, nhược điểm Manual Testing

Ưu điểm:

• Dễ dàng cho việc test giao diện, người tester sẽ có phản hồi nhanh và trực quan về giao diện ứng dụng.
• Mất ít chi phí cho các tool tự động và quy trình.
• Khi có thay đổi nhỏ manual testing manual testing không bị mất nhiều thời gian để thay đổi các trường hợp kiểm thử.

Nhược điểm:

• Kết quả kiểm thử ít tin cậy hơn vì có thể sai xót do yếu tố con người.
• Qúa trình thực hiện các ca kiểm thử không được ghi lại, do vậy nó không có tính tái sử dụng.
• Với một số task khó thực hiện thủ công như performance testing và stress testing thì manual testing rất khó để thực hiện.

Ưu, nhược điểm Automation Testing

Ưu điểm

• Sử dụng tool tự động giúp tìm kiếm được nhiều lỗi hơn.
• Automation testing nhanh và hiệu quả.
• Qúa trình kiểm thử được ghi lại, điều đó giúp chạy lại kịch bản kiểm thử nhiều lần và thực hiện trên nhiều nền tảng khác nhau.
• Automation testing được thực hiện bằng các công cụ phầm mềm, do đó nó hoạt động không mệt mỏi không giống như người kiểm thử tester.
• Automation testing năng suất và chính xác.
• Phạm vi kiểm thử rộng vì kiểm tra tự động không quên kiểm tra ngay cả đơn vị nhỏ nhất.

Nhược điểm

• Rất khó có cái nhìn đúng và trực quan về giao diện người dùng như màu sắc, font chữ, vị trí, kích thước các button nếu như không có yếu tố con người.
• Chi phí cho các tool kiểm thử có thể tốn kém, có thể làm tăng chi phí trong khâu kiểm thử của dự án.
• Nếu có một thay đổi nhỏ cũng sẽ mất thời gian để update kịch bản kiểm thử.

Sự khác nhau giữa Manual Testing và Automation Testing

Verification và Validation

Verification là quy trình đánh giá một hệ thống hoặc một thành phần để xác định xem liệu các sản phẩm của một giai đoạn phát triển nhất định có đáp ứng được những yêu cầu được định tại thời điểm bắt đầu của giai đoạn đó không.

Validation là qui trình đánh giá một hệ thống hoặc một thành phần trong suốt quá trình phát triển hoặc lúc kết thúc của quá trình phát triển để xác định xem liệu nó có được làm ra đúng như những yêu cầu cụ thể như những yêu cầu lúc đầu đưa ra không.

Verification là tĩnh (Static) trong khi Validation là động (Dynamic). Chẳng hạn Verification phần mềm là kiểm thử từng dòng mã, từng hàm. Với Validation, chạy phần mềm và tìm lỗi. Vị trí lỗi có thể tìm thấy với Verification, mà không thể với Validation.

Trên đây là những kiến thức cơ bản về kiểm thử phần mềm (testing). Testing là một công việc không thể thiếu trong việc xây dựng bất kỳ chương trình nào, cho là dù lớn hay nhỏ. Hầu hết nội dung trong bài viết này do tôi tìm hiểu từ các blog khác, sau đó tổng hợp lại và bổ sung thêm một vài kinh nghiệm mà tôi đã từng làm việc như là một tester trong dự án. Tôi không phải là một tester nên có thể không đảm bảo chính xác toàn bộ nội dung dưới. Rất mong nhận được sự đóng góp và phản hồi từ các bạn :).

Tài liệu tham khảo:

• https://www.tutorialspoint.com/software_testing/software_testing_overview.htm
• https://viblo.asia/p/cac-muc-do-kiem-thu-L4x5xQV1KBM
• https://viblo.asia/p/types-of-testing-wznVGLoQMZOe
• https://viblo.asia/p/su-khac-nhau-giua-manual-testing-va-automation-testing-1VgZvoRmlAw

Chuyên mục: Unit Test Được gắn thẻ: Unit Test

Bình luận

bình luận