Contents
- 1 Test Automation là gì
- 2 Kiểm thử thủ công và kiểm thử tự động.
- 3 Các loại kiểm thử.
- 3.1 Kiểm thử kim tự tháp.
- 3.2 Kiểm thử chức năng.
- 3.3 Kiểm thử hồi quy.
- 3.4 Kiểm thử thăm dò
- 3.5 Kiểm thử tải.
- 3.6 Kiểm thử hiệu suất.
- 3.7 Kiểm thử thâm nhập.
- 3.8 Kiểm thử khả năng sử dụng.
- 3.9 Kiểm thử chấp nhận người dùng – User acceptance testing (UAT).
- 3.10 Kiểm thử giao diện người dùng.
- 3.11 Kiểm thử API.
- 4 Những loại kiểm thử nào có thể được tự động hóa?
Test Automation là gì
Test Automation – Tự động hóa kiểm thử hay kiểm thử tự động là phần mềm ( tách biệt với phần mềm đang được kiểm thử) được sử dụng để kiểm soát việc thực hiện các kiểm thử.
Kiểm thử tự động trái ngược với kiểm thử thủ công ( manual testing), cho phép giải phóng thời gian và tài nguyên trong quá trình kiểm thử, để kiểm thử có thể được thực hiện ở tốc độ cao hơn, độ chính xác cao hơn và chi phí thấp hơn.
Kiểm thử tự động áp dụng cho phần mềm hoặc dịch vụ được phát triển nội bộ hoặc thương mại để hỗ trợ quá trình kiểm thử, bao gồm việc kiểm thử chức năng và tải. Các bài kiểm thử tự động cung cấp kết quả và điểm dữ liệu nhất quán.
Các lợi ích là dễ bảo trì, khả năng sử dụng hiệu quả tài nguyên và khả năng báo cáo dựa trên các kiểm thử đã thực hiện. Các công cụ quản lý chất lượng liên quan bao gồm chức năng lập kế hoạch kiểm thử, quản lý trường hợp kiểm thử và quản lý sai sót.
Kiểm thử thủ công và kiểm thử tự động.
Việc sử dụng kiểm thử tự động không loại trừ kiểm thử thủ công. Trên thực tế, nó hỗ trợ nhau rất tốt.
Tự động hóa là hỗ trợ mọi người đạt được mục tiêu của họ một cách thông minh, không phải để thay thế công việc.
Ôtô, dây chuyền lắp ráp và máy tính chỉ là vài ví dụ về các công nghệ đã được giới thiệu vì chúng cho phép mọi người làm việc thông minh hơn chứ không phải không chăm chỉ hơn.
Bằng cách giới thiệu tính năng kiểm thử tự động, người Tester sẽ không bị thay thế, nhưng giảm bớt được một vài công việc tẻ nhạt, lặp đi lặp lại, thay vào đó họ có thể tập trung vào việc quan trọng hơn, nơi họ sử dụng bộ kỹ năng của mình để thiết kế các trường hợp kiểm thử đảm bảo chất lượng và tăng phạm vi kiểm thử – cả về mặt định lượng lẫn chất lượng.
Các loại kiểm thử.
Có nhiều loại kiểm thử khác nhau. Một số phù hợp với tự động hóa hơn là những cái khác.
Có hai cách tiếp cận chính để kiểm thử:
- Kiểm thử hộp đen – Black box testing: có nghĩa là kiểm thử một ứng dụng mà không cần biết hoạt động nội bộ và chi tiết triển khai (mã, cấu hình…). Dựa trên kiến thức này, người kiểm thử sẽ kiểm tra các đường dẫn nhất định thông qua code.
- Kiểm thử hộp trắng – White box testing: thì ngược lại. Người kiểm thử biết các hoạt động nội bộ và các chi tiết triển khai. Dựa trên kiến thức này , người kiểm thử sẽ kiểm tra các đường dẫn nhất định thông qua code.
Sử dụng một hoặc cả hai phương pháp, kiểm thử được thực hiện ở các giai đoạn khác nhau của vòng đời phát triển phần mềm để tìm lỗi. Một cách khác là thông qua kiểm thử kim tự tháp.
Kiểm thử kim tự tháp.
Kiểm thử kim tự tháp được thiết kế để cung cấp một cái nhìn tổng quan về các cấp độ kiểm thử khác nhau, từ đơn vị nhỏ nhất đến các quy trình được kết nối tổng thể. Cấp độ 1 nằm ở chân của kim tự tháp, nơi diễn ra kiểm thử hộp trắng. Cấp độ 2 và 3 thường được tiếp cận bằng các kiểm thử hộp đen.
- Cấp độ 1: Kiểm thử đơn vị có nghĩa là kiểm tra các đơn vị code riêng lẻ hoặc các nhóm đơn vị trong phần mềm. Kiểm thử đơn vị chỉ có thể sử dụng phương pháp hộp trắng vì kiểm thử đơn vị được viết bằng code và gắn chặt với phát triển phần mềm. Các thử nghiệm này do đó cũng được phát triển bởi các nhà phát triển.
- Cấp độ 2: Kiểm thử tích hợp có nghĩa là kiểm tra cách các đơn vị code tương tác với nhau. Điều này liên quan đến việc kiểm tra một chuỗi các thành phần, đôi khi cả các thành phần bên ngoài, cùng xử lý một quy trình hoặc giao dịch kinh doanh. Kiểm thử tích hợp thường bao gồm kiểm tra các tương tác giữa phần cứng và phần mềm cũng như các thành phần cơ sở hạ tầng khác.
- Cấp độ 3: Kiểm thử từ đầu cuối, và tên của nó ngụ ý về việc kiểm tra một quy trình từ đầu đến cuối. Phạm vi kiểm thử end – to end phụ thuộc vào quy trình , nhưng các kiểm thử end-to-end thường trải dài trên nhiều công nghệ. Mục đích của các bài kiểm thử đầu cuối là để đảm bảo rằng một lường hoạt động như dự định từ quan điểm của người dùng. Vì lý do này, kiểm thử hộp đen thường được sử dụng.
Ngoài các loại kiểm thử có trong kiểm thử kim tự tháp, bạn cũng sẽ bắt gặp các thuật ngữ khác thường được sử dụng để kiểm thử. Dưới đây là danh sách và ý nghĩa của chúng:
Kiểm thử chức năng.
Được sử dụng để đảm bảo rằng chức năng được chỉ định như một phần của yêu cầu của phần mềm hoạt động như dự định từ quan điểm của người dùng cuối
Kiểm thử hồi quy.
Có thể được mô tả là “ kiểm thử chức năng lặp lại” nhưng không nền nhầm lẫn với kiểm thử lại. Khi các tính năng mới được xây dựng, kiểm thử hồi quy đảm bảo rằng các tính năng cũ của phần mềm tiếp tục hoạt động như dự kiến. Khi phát triển sản phẩm, số lượng kiểm thử hồi quy cũng tăng lên, khiến nó trở thành một trong những kiểm thử tốn nhiều thời gian nhất đối với các doanh nghiệp lớn. Nó cũng là một trong những ứng viên tốt nhất cho tự động hóa.
Kiểm thử thăm dò
Là một phương pháp tiếp cận thực hành và đặc biệt nhằm kiểm tra một phần mềm mà không có kế hoạch ngoài phạ vi . Người kiểm thử dựa vào kinh nghiệm và kiến thức của mình về các lỗi điển hình và các yêu cầu kinh doanh. Kiểm thử thăm dò thường được coi là nền tảng tuyệt vời để tạo ra các nhiệm vụ kiểm thử lặp đi lặp lại sẽ được thực hiện sau này. Nó sử dụng phương pháp hộp đen. Do tính chất không thể đoán trước của phương pháp này, nó không thể được tự động hóa.
Kiểm thử tải.
Có nghĩa là kiểm thử cách phần mềm hoạt động trong các điều kiện ngày càng bất lợi, chẳng hạn như luồng người dùng lớn được đo bằng thông tin đăng nhập mỗi giây hoặc mức tăng đột biến trong các giao dịch kinh doanh chẳng hạn như hoạt động thêm vào giỏ hàng. Mặc dù kiểm thử tải thuộc kiểm thử hộp đen, việc phân tích và hiểu kết quả của kiểm thử tải rất phức tạp và yêu cầu kiến thức sâu về code và cơ sở hạ tầng.
Kiểm thử hiệu suất.
Có nghĩa là kiểm thử xem các phần khác nhau của phần mềm hoạt động như thế nào về tốc độ và hiệu quả trong việc xử lý các giao dịch kinh doanh bắt buộc. Các ngưỡng cho số giây tối đa mà một tính năng nhất định phải thực thi trong điều kiện sử dụng bình thường thường là một phần của các yêu cầu phi chức năng của phần mềm và được kiểm thử bằng phương pháp hộp đen.
Kiểm thử thâm nhập.
Được sử dụng để mô phỏng các cuộc tấn công của các bên thù địch nhằm đánh giá tính bảo mật của phần mềm. Ví dụ: một nền tảng thương mại điện tử có thể sử dụng phương pháp này để đảm bảo rằng tin tặc không thể truy cập số thẻ tín dụng hoặc dữ liệu bí mật khác. Nó thường được thực hiện bằng phương pháp hộp đen, nhưng được thực hiện bởi các chuyên gia có tay nghề cao với kỹ năng mã hóa chuyên sâu cố gắng “mở hộp đen” để khai thác những gì bên trong.
Kiểm thử khả năng sử dụng.
Có nghĩa là kiểm tra một phần mềm từ quan điểm của người dùng cuối với trọng tâm là tính thân thiện với người dùng, tính thẩm mỹ và hiệu quả điều hướng. Nó sử dụng phương pháp hộp đen.
Kiểm thử chấp nhận người dùng – User acceptance testing (UAT).
Là một trong số ít các loại kiểm thử không được thực hiện bởi nhà cung cấp hoặc nhà sản xuất phần mềm đang được kiểm tra, mà là do khách hàng nhận phần mềm hoặc đại sứ khách hàng thực hiện. Loại kiểm thử này được thực hiện để đảm bảo rằng phần mềm đáp ứng các yêu cầu và hoạt động như mong đợi từ quan điểm của khách hàng. Nó thường được sử dụng như là cổng cuối cùng trước khi thanh toán các sản phẩm được giao. UAT được thực hiện bằng phương pháp kiểm tra hộp đen.
Kiểm thử giao diện người dùng.
Có nghĩa là kiểm tra giao diện người dùng. Giao diện người dùng là những gì người dùng nhìn thấy khi sử dụng một ứng dụng. Các công cụ tự động hóa kiểm thử giao diện người dùng thường là các công cụ ghi lại các tương tác của người dùng với giao diện và tự động bắt chước các tương tác đó.
Kiểm thử API.
Có nghĩa là kiểm tra các giao diện lập trình ứng dụng (API) được các nhà phát triển tiếp xúc với các nhà phát triển bên thứ ba. Nó được thực hiện để xác định xem các API có đáp ứng các mong đợi về chức năng, độ tin cậy, hiệu suất và bảo mật hay không. Mặc dù kiểm tra API yêu cầu kỹ năng code, nó thường được thực hiện bằng cách sử dụng kiểm thử hộp đen vì chỉ cần có kiến thức về các tham số đầu vào và đầu ra của API.
Những loại kiểm thử nào có thể được tự động hóa?
Một điểm khởi đầu tốt để tìm hiểu xem một quy trình có đủ điều kiện để tự động hóa hay không là xem liệu quy trình đó có phù hợp với các tiêu chí sau đây không:
- Kiểm thử có tính lặp lại cao và mất nhiều thời gian để thực hiện nếu nó được thực hiện theo cách thủ công (ví dụ: kiểm thử hồi quy)
- Đường dẫn kiểm thử có thể dự đoán được , có nghĩa là nó đã được chứng minh để xác minh một quy trình trước đó thông qua kiểm thử thủ công
- Kiểm thử dễ xảy ra lỗi do con người , có khả năng là do nó có tính lặp lại cao và liên quan đến việc di chuyển một lượng lớn dữ liệu
- Nếu quy trình phù hợp với tất cả các tiêu chí này, trong hầu hết các trường hợp, nó sẽ là một ứng cử viên sáng giá cho tự động hóa.