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

✓ Kiểm demo ứng dụng (software testing) là một trong quy trình bao hàm nhiều hoạt động và sinh hoạt nhằm mục tiêu Reviews unique những thành phầm ứng dụng và cắt giảm khủng hoảng rủi ro tự lỗi tạo ra vô quy trình vận hành Khi đi vào dùng thực tiễn. Các hoạt động và sinh hoạt kiểm demo này bao hàm những hoạt động và sinh hoạt kiểm tra Reviews (review) tư liệu, những phiên bản kiến thiết, và bao hàm mã mối cung cấp (source code), những hoạt động và sinh hoạt này vô thực tiễn hoặc gọi là “review” (rà soát). Và những hoạt động và sinh hoạt kiểm demo được triển khai bên trên thành phầm (nếu các bạn bắt gặp kể từ “dynamic testing”).

Bạn đang xem: testing là gì

Trên đấy là khái niệm chuẩn chỉnh về kiểm demo phần mềm, song bên trên thực tiễn có không ít ý niệm sai lầm đáng tiếc về kiểm demo ứng dụng, và 1 trong những số này là người xem hoặc nhận định rằng kiểm demo đơn giản việc làm thực ganh đua (chạy) những tình huống kiểm demo (test cases) bên trên một phần mềm ứng dụng (web application, desktop application, hoặc mobile application).

Dưới đấy là một vài hoạt động và sinh hoạt kiểm demo cơ bản:

Lập plan kiểm demo (test planning)
Phân tích kiểm demo (test analysis)
Thiết kế tiếp những tình huống kiểm demo (test design)
Thực ganh đua kiểm demo (test execution)
Báo cáo thành phẩm kiểm demo (test reporting)

Mục chi kiểm demo thông thường gặp

Tuỳ vô quy tế bào của dự án công trình hoặc mô hình của doanh nghiệp lớn và quy trình cách tân và phát triển ứng dụng nhưng mà tiềm năng kiểm demo tiếp tục không giống nhau, song đấy là một vài tiềm năng kiểm demo thông thường bắt gặp (danh sách này sẽ không mang tính chất trật tự và ko nên là giới hạn):

Kiểm tra coi ứng dụng (sản phẩm) đang được đáp ứng nhu cầu toàn bộ đòi hỏi đang được tế bào miêu tả ko hoặc xác nhận coi ứng dụng đang được hoàn mỹ và hoạt động và sinh hoạt quả như mong ngóng của người tiêu dùng và những mặt mày tương quan không giống ko.
Kiểm demo nhằm phòng tránh lỗi bằng phương pháp review tư liệu tế bào miêu tả đòi hỏi hoặc kiến thiết khối hệ thống, bao hàm mã mối cung cấp (source code) nhằm vạc hiện tại lỗi sớm.
Kiểm demo nhằm mục tiêu nâng lên unique ứng dụng, tăng thêm sự tin tưởng tưởng của người sử dụng so với ứng dụng trải qua việc vạc hiện tại lỗi và sửa lỗi (và đương nhiên là nên kiểm demo lại sau thời điểm được sửa).
Cung cấp cho vấn đề cho những mặt mày tương quan (bao bao gồm vận hành dự án công trình hoặc người sử dụng tùy dự án) nhằm chúng ta rất có thể thể hiện đưa ra quyết định về sự việc phát triển (release) một ứng dụng nào là ê hoặc không
Giảm thiểu khủng hoảng rủi ro tự lỗi của ứng dụng tạo ra vô quy trình dùng thực tế

Ngoài rời khỏi còn nhiều tiềm năng khác ví như kiểm demo nhằm Reviews coi khối hệ thống với đáp ứng nhu cầu những chi chuẩn chỉnh của những tổ chức triển khai quốc tế như ISO, CMMI hoặc quy toan của chống như GDPR (General Data Protection Regulation).

Các nấc kiểm demo (test levels)

Các nấc kiểm demo là giao hội những hoạt động và sinh hoạt test được triển khai ở một quy trình cách tân và phát triển rõ ràng của thành phầm, ví dụ kể từ khi vài ba tính năng nhỏ được xây dựng, cho tới khi thành phầm hoàn mỹ, và rất có thể tích phù hợp với những khối hệ thống không giống. Dưới đấy là một vài nấc kiểm demo cơ bản:

Kiểm demo (mức) đơn vị chức năng (unit testing)

Đây là nấc kiểm demo thấp nhất. Tại nấc kiểm demo này, những bộ phận nhỏ nhất của một khối hệ thống ứng dụng như class, function, hoặc module sẽ tiến hành kiểm demo riêng biệt lẻ. Phần rộng lớn test case (các tình huống kiểm thử) ở tầm mức này tiếp tục gọi thẳng đối tượng người dùng được kiểm demo (như class, function… nào là đó) vô code (mã nguồn) nên rất cần phải với sự tương hỗ của những tủ sách (unit test framework thông dụng như XUnit, JUnit, Nunit, Jest,… nhiều phần ngữ điệu xây dựng nào là cũng có thể có nhiều tủ sách tương hỗ mang đến unit testing) nhằm mô phỏng những cụm tính năng (class, function,…) tương quan nhằm mục tiêu tách riêng biệt phần cần thiết kiểm demo.

Khi vạc hiện tại lỗi ở tầm mức kiểm demo này thông thường sẽ hỗ trợ tiết kiệm chi phí thời hạn và ngân sách nhiều vì như thế nếu như không được vạc hiện tại lỗi này sớm, rất có thể nó sẽ gây ra rời khỏi những lỗi tích phù hợp, hoặc tạo ra trường hợp hi hữu Khi đi vào dùng thực tiễn. Lúc này tất cả chúng ta nên chuồn sửa lỗi tại 1 đơn vị chức năng code nào là ê, và nên test lại (confirmation testing) nhằm coi lỗi này đang được sửa chính hoặc ko, ngoại giả còn nên kiểm demo những chống không giống nhằm bảo đảm an toàn quy trình sửa lỗi không khiến rời khỏi lỗi mới mẻ không giống (regression testing).

Ví dụ, như hình bên dưới, nhằm kiểm demo đơn vị chức năng code gold color, tất cả chúng ta nên mô phỏng những đơn vị chức năng với tương quan thẳng cho tới nó (màu xanh rớt tím).

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

Trong thực tiễn, xây dựng viên (developer – hoặc gọi tắt là dev) tiếp tục phụ trách móc triển khai kiểm demo đơn vị chức năng. Để xác lập tình huống cần thiết kiểm demo, dev tiếp tục nhờ vào mã mối cung cấp (source code) và tư liệu tế bào miêu tả đòi hỏi cụ thể (SRS – System Requirement Specification) của tính năng đang rất được kiểm demo là mối cung cấp vấn đề bổ sung cập nhật, canh ty xác lập thành phẩm mong ngóng cho những test case ê.

Trong ví dụ vô hình bên dưới, lịch trình đánh giá số nhân tố đơn giản và giản dị, không nhất thiết phải mô phỏng gì. Và 2 test case cơ phiên bản nhằm đánh giá một số là số nhân tố và một số ko nên là số nhân tố.

Kiểm demo tích phù hợp (integration testing)

Ở quy trình này, những tính năng (hoặc class, function,…) đang được cách tân và phát triển và kiểm demo kết thúc, đã đi vào khi tích phù hợp bọn chúng lại cùng nhau. Và nên kiểm demo sự tương tác tương hỗ Một trong những bộ phận này. Tương tự động như thế, tất cả chúng ta cũng cần phải kiểm demo sự tích phù hợp Một trong những khối hệ thống không giống nhau. Hai nấc kiểm demo tích phù hợp thông thường bắt gặp sau:

Component integration testing

Kiểm demo tích phù hợp (các) bộ phận (trong một hệ thống) là tích phù hợp những tính năng hoặc module vô và một khối hệ thống (ví dụ, Một trong những api của một phần mềm trang web hoặc mobile app).

Thường thì xây dựng viên (dev) tiếp tục phụ trách móc triển khai nấc kiểm demo tích phù hợp này, hoặc gọi công cộng là integration testing.

Ví dụ kiểm demo tích phù hợp những bộ phận vô một hệ thống

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

System integration testing

Kiểm demo tích phù hợp (các) khối hệ thống là lúc những khối hệ thống song lập với tương quan cho tới nhau thì tất cả chúng ta rất cần phải triển khai kiểm demo tích phù hợp thân thích bọn chúng nhằm đảm nói rằng bọn chúng đáp ứng nhu cầu những luồng nhiệm vụ mong ước.

Ví dụ như 1 khối hệ thống bán sản phẩm thương nghiệp năng lượng điện tử ngẫu nhiên thông thường tiếp tục dùng cty giao dịch thanh toán trực tuyến được hỗ trợ vì chưng một phía loại 3 (3rd party) hoặc khối hệ thống giao dịch thanh toán trực tuyến tự doanh nghiệp lớn bản thân cách tân và phát triển (bởi một group khác). Chúng tớ nên kiểm demo những luồng giao dịch thanh toán cơ phiên bản như giao dịch thanh toán thành công xuất sắc, ko thành công xuất sắc, v.v… Tương tự động như tất cả chúng ta rất cần phải kiểm demo tích phù hợp thân thích 1 sàn thương nghiệp năng lượng điện tử (tiki, lazada) và mặt mày ship hàng như Giao sản phẩm thời gian nhanh, ship hàng tiết kiệm chi phí.

Thường thì Tester (QC/QA) là kẻ triển khai việc kiểm demo ở tầm mức tích phù hợp những khối hệ thống này.

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

Một số cách thức tiếp cận thông thường bắt gặp nhằm kiểm kiểm demo tích hợp:

Big-Bang integration testing: tích phù hợp toàn bộ những bộ phận (cần kiểm thử) và một khi và tổ chức kiểm demo theo đuổi những kịch phiên bản, tình huống quan trọng. Cách tiếp cận này thông thường bắt gặp, và được vận dụng cho những khối hệ thống đơn giản và giản dị, nhỏ, không nhiều bộ phận. Khi vận dụng cho những khối hệ thống rộng lớn thì tiếp tục bắt gặp nhiều trở ngại trong những việc xác xác định trí điểm tạo ra lỗi nhằm sửa.
Top-Down integration testing: Việc kiểm demo được triển khai kể từ những đơn vị chức năng (module/function) ở cấp cho bên trên xuống theo đuổi luồng tinh chỉnh và điều khiển của khối hệ thống. Các đơn vị chức năng tối đa được đánh giá trước và những cấp cho đơn vị chức năng thấp rộng lớn được đánh giá từng bước tiếp sau đó.
Bottom-Up integration testing: trái lại với Top-Down integration testing, ở cách thức tiếp cận này những đơn vị chức năng thấp cấp được đánh giá trước và những đơn vị chức năng cấp cho cao hơn nữa sẽ tiến hành đánh giá tiếp sau đó.
Sandwich/Hybrid integration testing: Là sự phối hợp của nhị cách thức Top-Down integration testing và Bottom-Up integration testing. Tại trên đây, những đơn vị chức năng ở cấp cho cao được đánh giá với những đơn vị chức năng thấp rộng lớn mặt khác những đơn vị chức năng thấp rộng lớn được tích phù hợp với những đơn vị chức năng cấp cho bên trên cao nhằm kiểm demo.

Trên đấy là cách thức tiếp cận nhờ vào cấu trúc/kiến trúc của mã mối cung cấp. Trong khi tất cả chúng ta rất có thể tích phù hợp nhờ vào luồng tính năng.

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

Kiểm demo khối hệ thống (system testing)

Một Khi khối hệ thống đang được cách tân và phát triển (lập trình) hoàn mỹ, tất cả chúng ta cần thiết kiểm demo những luồng xử lý tính năng, và một vài góc nhìn phi tính năng như tính năng (trong ê với load testing – kiểm demo tải) và Reviews tính khả dụng của khối hệ thống (usability – coi dễ dàng dùng dễ dàng nắm bắt mang đến từng đối tượng người dùng người tiêu dùng hoặc không).

Thường tiếp tục nhờ vào tư liệu tế bào miêu tả tính năng và vận dụng những chuyên môn kiểm demo vỏ hộp đen sì nhằm ghi chép test case (là end-to-end test case) mang đến nấc kiểm demo này. Cũng rất có thể nhờ vào tay nghề của tester và những tầm quan trọng không giống vô dự án công trình như PM/PO, người sử dụng.

Tester là kẻ triển khai kiểm demo ở tầm mức này.

Kiểm demo gật đầu (acceptance testing)

Một Khi tester đang được triển khai kết thúc quy trình kiểm demo ở tầm mức khối hệ thống, thì group nhân viên cấp dưới không giống vô doanh nghiệp lớn tới từ group Chăm sóc người sử dụng, Bán sản phẩm,… hoặc người sử dụng tiếp tục triển khai Reviews tổng thể khối hệ thống dựa vào tư liệu tế bào miêu tả đòi hỏi của khối hệ thống. Hoặc kiểm demo gật đầu rất có thể được triển khai tuy nhiên song với quy trình kiểm demo nấc khối hệ thống.

Quá trình kiểm demo gật đầu tiếp tục vấn đáp cho những thắc mắc như:

Hệ thống đang được sẵn sàng đi vào dùng thực tiễn chưa?
Hệ thống chạy đang được đáp ứng nhu cầu như mong ngóng của người tiêu dùng chưa?
Có thể gật đầu và giao dịch thanh toán chi phí mang đến thành phầm này không?
Vân vân…

Vậy tớ rất có thể thấy, system testing là kiểm demo coi khối hệ thống với chính đòi hỏi ko, với mục tiêu là thám thính lỗi. Còn kiểm demo gật đầu ở đấy là coi ứng dụng với chạy quả như người tiêu dùng và những mặt mày tương quan mong ngóng hoặc ko.

Riêng những doanh nghiệp lớn cách tân và phát triển ứng dụng theo phương thức gói gọn hoặc thành phầm hỗ trợ cho 1 group người sử dụng người tiêu dùng đặc trưng (COTS software) thì với 2 dạng kiểm demo gật đầu thông thường bắt gặp như:

Alpha testing: Được triển khai bên trên điểm cách tân và phát triển ứng dụng vì chưng những người dân ko nhập cuộc thẳng vô quy trình cách tân và phát triển bọn chúng (như những nhân viên cấp dưới tới từ group đỡ đần người sử dụng, bán sản phẩm, hoặc những group cách tân và phát triển ứng dụng khác). Thường được triển khai trước lúc triển khai beta testing.
Beta testing: cũng có thể được triển khai sau hoặc tuy nhiên song với alpha testing. Được triển khai vì chưng người tiêu dùng (thường là khách hàng hàng). Beta testing thông thường được ra mắt ở phía người sử dụng và người tiêu dùng thành phầm bên trên môi trường thiên nhiên thực tiễn của mình (như PC hoặc điện thoại cảm ứng của khách hàng hàng).

Tuy nhiên, tester cũng thông thường phối phù hợp với người sử dụng vô quy trình kiểm demo gật đầu này (tùy theo đuổi đòi hỏi của dự án).

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

Loại kiểm demo là những nhóm những hoạt động và sinh hoạt kiểm thử được triển khai nhằm nhắm cho tới một mục tiêu rõ ràng nào là ê, ví như nhằm Reviews tính năng, tính năng, hoặc những góc nhìn không giống. Sau đấy là một vài loại kiểm demo thông thường gặp:

Kiểm demo tính năng (functional testing)

Các hoạt động và sinh hoạt kiểm demo tính năng tiếp tục triệu tập vô việc đánh giá coi khối hệ thống với hoạt động và sinh hoạt theo như đúng theo đuổi đòi hỏi nhiệm vụ đang được tế bào miêu tả hoặc ko. Tập trung Reviews tính chính đắn, cường độ đúng mực, và tính thích hợp của khối hệ thống với người tiêu dùng, và một vài góc nhìn không giống. Kiểm demo tính năng rất có thể được triển khai ở toàn bộ những nấc kiểm demo.

Dưới đấy là 2 cơ hội tiếp cận nhằm kiểm demo chức năng:

Requirements-based testing: quan liêu điểm đó nhờ vào tư liệu tế bào miêu tả đòi hỏi của khối hệ thống (như SRS – software requirement specification) nhằm ghi chép test case và triển khai kiểm demo.

Cách chất lượng nhằm chính thức là:

Sử dụng nội dung của quánh miêu tả đòi hỏi nhằm xác lập phạm vi kiểm thử (danh sách những khuôn khổ cần thiết kiểm demo và sẽ không còn kiểm thử)
Chúng tớ nên xét phỏng ưu tiên của những đòi hỏi này dựa vào mức phỏng rủi ro và độ ưu tiên nhằm kiểm demo. Vấn đề này tiếp tục đáp ứng những tính năng cần thiết nhất sẽ tiến hành kiểm demo trước.

Business-process-based testing: tiếp tục dùng những con kiến thức/hiểu biết về tiến độ nhiệm vụ nhằm ghi chép test case và triển khai kiểm demo. Dựa vô quy trình nghiệp vụ tất cả chúng ta rất có thể xác lập được những kịch phiên bản rất có thể xẩy ra vô thực tiễn, canh ty vạc hiện tại sớm những lỗi tương quan cho tới xử lý nhiệm vụ.

Xem thêm: lý tinh vân là ai

Ví dụ Khi kiểm demo tính năng gửi chi phí liên ngân hàng rất có thể tất cả chúng ta vạc hiện tại lỗi tương quan cho tới tình huống ngân hàng của những người nhận đang được gia hạn (khi ê server sẽ không còn liên hệ được) hoặc xử lý lờ đờ (do vượt lên trên vận chuyển hệ thống). Và đấy là tình huống đặc biệt rất có thể tiếp tục bắt gặp nên vô thực tiễn, nhất là vào cuối tuần.

Kiểm demo phi tính năng (non-functional testing)

Là những hoạt động và sinh hoạt kiểm demo nhằm mục tiêu Reviews những Điểm sáng unique, hoặc tính chất phi tính năng như tính năng, bảo mật thông tin, và tính dễ dàng dùng.

Việc kiểm demo này cũng như kiểm demo tính năng, được triển khai ở từng nấc kiểm demo (test level). Ví dụ Khi vận dụng kiểm demo tính năng ở tầm mức khối hệ thống thì thông thường sẽ:

Thực hiện tại những hoạt động và sinh hoạt kiểm demo nhằm Reviews nấc Chịu đựng vận chuyển của khối hệ thống (đánh giá bán coi khối hệ thống rất có thể xử lý được từng nào đòi hỏi nằm trong lúc) thì này là kiểm demo vận chuyển (load testing). Các dụng cụ (tool) hữu ích vô kiểm demo tính năng gồm: JMeter, K6
Hoặc kiểm demo tính khả dụng (usability testing) là những hoạt động và sinh hoạt Reviews coi khối hệ thống dễ dàng dùng ra làm sao.

Kiểm demo gia hạn (maintenance testing)

“Kiểm demo bảo trì” tế bào miêu tả những hoạt động và sinh hoạt kiểm demo được triển khai bên trên một khối hệ thống đang được vận hành và dùng thực tiễn. Các chuyên môn và cách thức tiếp cận nhằm kiểm demo cũng không tồn tại gì đặc biệt quan trọng lắm đối với việc kiểm demo được triển khai vô vượt lên trên cách tân và phát triển ứng dụng. Tuy nhiên với 2 định nghĩa kiểm demo cần thiết cần thiết Note như sau:

Kiểm demo xác nhận (Confirmation testing): là quy trình kiểm demo coi một lỗi (bug/defect) đang được sửa (fix) chính, hay như là một thay cho thay đổi đòi hỏi đang được triển khai quả như mong ngóng hoặc ko. Nơi triển khai kiểm demo là địa điểm những địa điểm được triển khai thay cho thay đổi (nơi được triển khai thay cho đổi).

Kiểm demo hồi quy (Regression testing): là quy trình kiểm demo Reviews những chống không xẩy ra thay cho thay đổi nhằm coi bọn chúng với bị tác động tự quy trình triển khai thay cho thay đổi hoặc sửa lỗi (fix bug) tạo ra. “Regression” là những tính năng phụ ko mong ước Khi triển khai thay cho thay đổi vô khối hệ thống (khi sửa thay đổi mã nguồn/source code) nên regression testing là kiểm demo nhằm thám thính tìm tòi những tính năng phụ ko mong ước này. Thường những test case mang đến loại kiểm demo này sẽ tiến hành tự động hóa hoá (gọi là automated test case) vì như thế bọn chúng thông thường xuyên được thực ganh đua (sử dụng) rất nhiều lần vô trong cả quãng đời cách tân và phát triển và gia hạn ứng dụng (thêm tác dụng mới mẻ, xoá hoặc sửa những tác dụng hiện tại có).

Các định nghĩa bên trên cũng mặt khác vận dụng cho những hoạt động và sinh hoạt kiểm demo vô quy trình cách tân và phát triển ứng dụng, khi chúng ta kiểm demo bên trên những phần tính năng (hay module) đang được cách tân và phát triển (lập trình) kết thúc trước ê rồi (ví dụ trong những Sprint trước). Và lúc này với 1 vài ba thay cho thay đổi tương quan cho tới những phần code/chức năng này thì tất cả chúng ta cũng nên “test lại” nhằm bảo đảm an toàn “mọi loại vẫn ổn” (nghĩa là những tính năng cũ vẫn còn đó hoạt động và sinh hoạt như cũ – regression testing), kề bên việc kiểm demo nhằm xác nhận những đòi hỏi mới mẻ hoặc fix bug đang được triển khai chính (confirmation testing).

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

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

Các chuyên môn kiểm demo vỏ hộp đen sì (black-box testing)

Kiểm demo vỏ hộp đen sì (black-box testing) là những chuyên môn khiến cho bạn xác lập test case (các tình huống kiểm thử) nhờ vào những loại tư liệu như tư liệu tế bào miêu tả đòi hỏi (requirement specification), user story (thường thấy vô quy mô Scrum), tư liệu kiến thiết (design document) và nhiều loại tư liệu không giống.

Trong quy trình kiểm demo (ở từng nấc kể từ unit testing cho tới kiểm demo hệ thống), Khi vận dụng chuyên môn kiểm demo vỏ hộp đen sì thì các bạn chỉ triệu tập vô “bề ngoài của phần mềm” nhưng mà ko cần thiết quan hoài nó được xây dựng vì chưng ngữ điệu gì hoặc cơ hội nó hoạt động và sinh hoạt ra làm sao. Vì thế, nhược điểm của chuyên môn này là mặc dầu các bạn với con số test case to đùng thì các bạn cũng tiếp tục đặc biệt mơ hồ nước và ko mạnh mẽ và tự tin rằng tôi đã kiểm demo đầy đủ hoặc ko. Dẫn cho tới tình huống, Khi PM hoặc người sử dụng phát biểu “bạn cần thiết kiểm demo nhiều hơn” thì các bạn cũng ko thể thuyết phục chúng ta rằng các bạn đang được test “quá đủ” hoặc “chưa đủ” theo đuổi đòi hỏi.

Một số chuyên môn vỏ hộp đen sì thông dụng gồm những: phân vùng tương tự, phân tách độ quý hiếm biên, kiểm demo nhờ vào bảng đưa ra quyết định, và kiểm demo nhờ vào quy đổi tình trạng,…. sẽ tiến hành tế bào miêu tả sơ lược như sau:

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

Khi vận dụng chuyên môn kiểm demo này, tất cả chúng ta tiếp tục nhờ vào những độ quý hiếm nguồn vào hoặc thành phẩm Output đầu ra được tế bào miêu tả vô tư liệu nhằm phân tách bọn chúng rời khỏi trở nên những group có mức giá trị tương đương nhau. Mong ham muốn những độ quý hiếm vô group được xử lý theo đuổi một cơ hội giống như nhau (bên vô phần mềm).

Sau Khi vận dụng kết thúc, thành phẩm tất cả chúng ta sẽ có được được những phân vùng tương đương (equivalence partition) thông thường tiếp tục bao hàm 2 loại:

Vùng tương tự hợp thức (chứa những độ quý hiếm phù hợp lệ)
Vùng tương tự ko hợp thức (chứa những độ quý hiếm không phù hợp lệ)

Trong đó

Các độ quý hiếm hợp thức (valid value) là những độ quý hiếm được khối hệ thống chấp nhận
Các độ quý hiếm ko hợp thức (invalid value) là những độ quý hiếm không được khối hệ thống chấp nhận

Ví dụ: hình bên dưới là đòi hỏi về phỏng lâu năm “Tên người dùng” khi chúng ta tạo nên thông tin tài khoản Gmail mới

Với đòi hỏi bên trên thì những vùng tương tự tiếp tục là

Test case ít nhất rất cần phải với là:

TC1: Kiểm demo với Tên người dùng ở trong vòng kể từ 6 cho tới 30 ký tự
TC2: Kiểm demo với Tên người tiêu dùng ít rộng lớn 6 ký tự
TC3: Kiểm demo với Tên người tiêu dùng nhiều rộng lớn 30 ký tự

Phân tích độ quý hiếm biên (boundary value analysis)

Sau khi chúng ta đang được vận dụng chuyên môn phân vùng tương tự kết thúc, nếu như những vùng tương tự là những sản phẩm số liên tiếp (kỹ thuật này chỉ vận dụng được cho những loại tài liệu loại số, tháng ngày,… và với tính liên tiếp theo hướng tăng hoặc giảm) thì chúng ta nên vận dụng tiếp kỹ thuật phân tách độ quý hiếm biên này. Vì vậy, người xem coi đấy là một kỹ thuật banh rộng của chuyên môn phân vùng tương tự.

Kỹ thuật này chỉ dẫn tất cả chúng ta triệu tập kiểm demo những độ quý hiếm phụ cận (xung quanh) của từng cạnh của những vùng tương tự. Có nhiều phương pháp để xác lập độ quý hiếm biên, tuy nhiên đấy là một cơ hội đơn giản và giản dị nhất và dễ dàng vận dụng nhưng mà hiệu suất cao vạc hiện tại bug lại cao.

Dựa vô ví dụ bên trên, thì tất cả chúng ta tiếp tục ghi thêm thắt những độ quý hiếm biên vào

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

Test case ít nhất rất cần phải với là:

TC1: Kiểm demo với Tên người dùng có phỏng lâu năm 6 ký tự động (mong muốn: mang đến phép)
TC2: Kiểm demo với Tên người tiêu dùng với độ lâu năm 30 ký tự động (mong muốn: mang đến phép)
TC3: Kiểm demo với Tên người tiêu dùng với độ lâu năm 5 ký tự động (mong muốn: ko được chấp nhận vì như thế vượt lên trên ngắn)
TC4: Kiểm demo với Tên người tiêu dùng với độ lâu năm 31 ký tự động (mong muốn: ko được chấp nhận vì như thế vượt lên trên dài)

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

Kỹ thuật này khiến cho bạn ghi chép test case nhờ vào tổng hợp rất có thể với của những ĐK nguồn vào. Thông thường từng phối hợp những ĐK này tiếp tục ứng với 1 đòi hỏi nhiệm vụ được tế bào miêu tả vô tư liệu.

Kỹ thuật này thông thường được vận dụng cho những đòi hỏi có không ít ĐK phức tạp, dựa vào cho nhau.

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

Trong ví dụ bên trên, từng cột là một trong tổng hợp độc nhất của những ĐK (số chi phí đang được nợ, lịch sử vẻ vang tín dụng thanh toán, số chi phí mua sắm nợ) và thành phẩm (action/hành động) ứng của tổng hợp này (cũng là thành phẩm ước đợi). Mỗi cột này tiếp tục ứng với 1 tế bào miêu tả vô tư liệu đòi hỏi. Tuy nhiên, tất cả chúng ta cũng nên gộp những cột tương đương nhằm rời con số test case dư quá trùng lặp, ví dụ cột 3 và cột 4 rất có thể gộp lại trở nên test case như sau:

Kiểm tra tình huống khách hàng mua sản phẩm ko trở nên công Khi số chi phí nợ hiện tại với đang được đạt giới hạn, và quá trình chi trả ko chất lượng. (Trong tình huống này sẽ không quan hoài số chi phí mua sắm lúc này là bao nhiêu).

Kiểm demo quy đổi tình trạng (state transition testing)

Kỹ thuật này khiến cho bạn ghi chép test case nhờ vào những lược đồ dùng tế bào miêu tả tình trạng (state) và những quy đổi tương hỗ Một trong những tình trạng (transition). Trong hình ví dụ bên dưới với 6 tình trạng (state) và 10 quy đổi (transition).

Với chuyên môn này, nhằm chứa đựng chất lượng, các bạn sẽ ghi chép test case theo đuổi chi chí:

đi qua loa (bao phủ) từng trạng thái
đi qua loa từng quy đổi (1 phen, gấp đôi,… n lần)

Vui lòng coi thêm thắt state transition testing ở đoạn Clip cộc này (tiếng Việt).

Ngoài rời khỏi còn tồn tại pairwise testing, là chuyên môn kiểm demo khiến cho bạn xác lập con số ít nhất những phối hợp của ĐK nhập nguồn vào. Giúp các bạn xác lập được con số test case ít nhất song vẫn chứa đựng từng phối hợp theo đuổi cặp (pair) những độ quý hiếm nguồn vào (thường là những khuôn khổ bên trên screen hoặc “parameter” – thông số nguồn vào – của những API).

Trên đấy là một vài vấn đề cơ phiên bản về kiểm demo ứng dụng. Nhưng nếu khách hàng ko học tập technology vấn đề như bản thân, nhằm hiểu nhiều hơn thế nữa và rất có thể thực hiện được tester thì bạn phải học tập nhiều kỹ năng và kiến thức và tài năng không giống nữa như cơ hội phân tách tư liệu, ghi chép test case. Các kỹ năng và kiến thức cơ phiên bản quan trọng như cơ hội hoạt động và sinh hoạt của một phần mềm trang web nhằm rất có thể kiểm demo trang web hiệu suất cao. Hoặc những kỹ năng và kiến thức tương quan cho tới chuyên môn như API testing hoặc SQL cơ phiên bản.

Đây là bài bác “luận cuối khóa Fresher Tester khoá FK54” của em, cám ơn anh Sơn, chị An, và những anh chị Mentor đang được coi và khuyến nghị sửa đổi tương hỗ rộng lớn chục phen.

Anh, chị và chúng ta với bổ sung cập nhật gì sướng lòng nhằm lại phản hồi bên dưới nội dung bài viết, em tiếp tục update nội dung bài viết sau.

Cố gắng với việc tester sớm!

Xem thêm: trung anh siêu nhân là ai