Khi viết phần mềm, bạn có thể xác nhận rằng phần mềm hoạt động đúng cách thông qua kiểm thử. Kiểm thử có thể được định nghĩa rộng là quá trình chạy phần mềm trong một để đảm bảo ứng dụng hoạt động như dự kiến.
Quá trình thử nghiệm thành công có thể giúp bạn tự tin rằng khi thêm mã, tính năng hoặc thậm chí nâng cấp các phần phụ thuộc, phần mềm bạn đã viết sẽ tiếp tục hoạt động theo cách bạn mong đợi. Việc xét nghiệm cũng có thể giúp bảo vệ chống lại các tình huống không mong muốn hoặc thông tin đầu vào không mong muốn.
Một số ví dụ về hành vi trên web mà bạn có thể muốn kiểm tra bao gồm:
- Đảm bảo rằng tính năng của trang web hoạt động chính xác khi người dùng nhấp vào nút.
- Xác nhận rằng một hàm phức tạp tạo ra kết quả chính xác.
- Hoàn tất một thao tác yêu cầu người dùng phải đăng nhập.
- Kiểm tra xem biểu mẫu có báo cáo lỗi chính xác khi nhập dữ liệu không đúng định dạng hay không.
- Đảm bảo một ứng dụng web phức tạp tiếp tục hoạt động khi người dùng băng thông thấp hoặc mất kết nối mạng.
Kiểm thử tự động so với kiểm thử thủ công
Bạn có thể kiểm thử phần mềm theo hai cách chung: kiểm thử tự động và kiểm thử thủ công kiểm thử.
Quy trình kiểm thử thủ công bao gồm việc con người chạy phần mềm trực tiếp, chẳng hạn như tải trên trình duyệt của họ và xác nhận rằng trang web hoạt động như dự kiến. Thủ công thử nghiệm rất đơn giản để tạo hoặc xác định, ví dụ: trang web của bạn có tải được không? Bạn có thể thực hiện những hành động này không?—nhưng mỗi lần chạy thử lại tốn rất nhiều chi phí thời gian của con người. Mặc dù con người rất sáng tạo nhưng điều đó có thể tạo điều kiện cho loại hình thử nghiệm còn gọi là thử nghiệm thăm dò, chúng tôi vẫn có thể không phát hiện được thất bại hoặc sự không thống nhất, đặc biệt là khi thực hiện cùng một tác vụ nhiều lần.
Kiểm thử tự động là quy trình cho phép hệ thống mã hoá và chạy hoạt động kiểm thử liên tục bằng máy tính để xác nhận hành vi mong muốn của phần mềm mà không cần nhờ người thực hiện bất kỳ bước lặp lại nào, chẳng hạn như thiết lập hoặc kiểm tra kết quả. Điều quan trọng là khi đã định cấu hình kiểm thử tự động, nó có thể chạy thường xuyên. Đây vẫn là một định nghĩa rất rộng và xin lưu ý rằng các bài kiểm thử có đủ mọi loại hình dạng và hình thức. Phần lớn nội dung của khoá học này liên quan đến bằng quy trình kiểm thử tự động.
Kiểm thử thủ công có vai trò riêng, thường là tiền tố để viết bài kiểm thử tự động mà còn khi kiểm thử tự động trở nên quá không đáng tin cậy, có phạm vi rộng, hoặc khó viết.
Kiến thức cơ bản thông qua ví dụ
Đối với chúng tôi, là nhà phát triển web viết JavaScript hoặc ngôn ngữ có liên quan, thử nghiệm tự động có thể là một tập lệnh giống như tập lệnh này mà bạn chạy mỗi ngày, thông qua Nút hoặc bằng cách tải nút trong trình duyệt:
import { fibonacci } from "../src/math.js";
if (fibonacci(0) !== 0) {
throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}
Đây là ví dụ đơn giản cung cấp những thông tin chi tiết sau:
Đây là kiểm thử vì nó chạy một số phần mềm (Fibonacci ) và đảm bảo dữ liệu hành vi hoạt động theo cách dự kiến bằng cách kiểm tra kết quả so với giá trị dự kiến. Nếu hành vi không chính xác, nó sẽ gây ra lỗi JavaScript thể hiện bằng cách gửi một
Error
.Mặc dù bạn có thể đang chạy tập lệnh này theo cách thủ công trong cửa sổ dòng lệnh hoặc trình duyệt, đây vẫn là một kiểm thử tự động vì có thể chạy nhiều lần mà không cần thực hiện bất kỳ bước riêng lẻ nào. Trang tiếp theo, nơi thử nghiệm, sẽ được giải thích thêm.
Mặc dù quy trình kiểm thử này không sử dụng bất kỳ thư viện nào, nhưng JavaScript có thể chạy ở bất cứ đâu—đây vẫn là một thử nghiệm. Có nhiều công cụ có thể giúp bạn viết mã kiểm thử, bao gồm cả những bài kiểm thử sẽ được đề cập sau trong khoá học này, nhưng chúng vẫn hoạt động theo nguyên tắc cơ bản là gây ra lỗi nếu đã xảy ra sự cố nào đó.
Kiểm thử thư viện trong thực tế
Hầu hết các thư viện hoặc khung kiểm thử tích hợp đều cung cấp hai dữ liệu gốc chính giúp cho việc viết chương trình kiểm thử trở nên dễ dàng hơn: xác nhận và cách xác định chương trình kiểm thử độc lập. Các vấn đề này sẽ được đề cập chi tiết trong phần tiếp theo, nhận định và các dữ liệu gốc khác. Tuy nhiên, ở mức độ cao, điều quan trọng cần nhớ là gần như tất cả các thử nghiệm bạn thấy hoặc viết sẽ kết thúc bằng cách sử dụng các loại dữ liệu gốc này.
Xác nhận là một cách kết hợp việc kiểm tra kết quả và gây ra lỗi nếu
đã xảy ra sự cố nào đó. Ví dụ: bạn có thể làm cho chương trình kiểm thử trước ngắn gọn hơn
bằng cách giới thiệu assert
:
import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";
assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
Bạn có thể cải thiện kiểm thử này hơn nữa bằng cách xác định các kiểm thử độc lập, nếu muốn được nhóm thành các tập hợp. Bộ công cụ sau đây kiểm thử Fibonacci một cách độc lập và hàm Catalan:
import { fibonacci, catalan } from "../src/math.js";
import { assert, test, suite } from "a-made-up-testing-library";
suite("math tests", () => {
test("fibonacci function", () => {
assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
});
test("relationship between sequences", () => {
const numberToCheck = 4;
const fib = fibonacci(numberToCheck);
const cat = catalan(numberToCheck);
assert.isAbove(fib, cat);
});
});
Trong bối cảnh kiểm thử phần mềm, test (kiểm thử) như một danh từ đề cập đến test case (trường hợp kiểm thử): tình huống đơn lẻ, độc lập, có thể giải quyết được, ví dụ như "mối quan hệ giữa trình tự" trường hợp kiểm thử trong ví dụ trước.
Các chương trình kiểm thử được đặt tên riêng lẻ rất hữu ích cho các tác vụ sau, cùng với nhiều tác vụ khác:
- Xác định quá trình kiểm thử thành công hay không thành công theo thời gian.
- Nêu bật lỗi hoặc tình huống theo tên để bạn có thể dễ dàng kiểm thử trường hợp này đã được giải quyết.
- Chạy một số thử nghiệm một cách độc lập với các thử nghiệm khác, chẳng hạn như thông qua bộ lọc cầu vồng.
Có một cách để liên tưởng đến trường hợp kiểm thử, đó là sử dụng "ba chữ A" của kiểm thử đơn vị: sắp xếp, hành động và xác nhận. Về cơ bản, mỗi trường hợp kiểm thử sẽ:
- Sắp xếp một số giá trị hoặc trạng thái (có thể chỉ là dữ liệu đầu vào được cố định giá trị trong mã).
- Thực hiện một thao tác, chẳng hạn như gọi một phương thức.
- Xác nhận các giá trị đầu ra hoặc trạng thái đã cập nhật (sử dụng
assert
).
Quy mô kiểm thử
Các mã mẫu trong phần trước mô tả kiểm thử đơn vị, bởi vì kiểm thử các phần nhỏ của phần mềm, thường tập trung vào một tệp duy nhất và trong trường hợp, chỉ kết quả đầu ra từ một hàm duy nhất. Độ phức tạp của quá trình kiểm thử tăng lên khi bạn xem xét mã từ nhiều tệp, thành phần hoặc thậm chí các mã được kết nối với nhau hệ thống (đôi khi nằm ngoài tầm kiểm soát của bạn, chẳng hạn như dịch vụ mạng hoặc của phần phụ thuộc bên ngoài). Do đó, các loại kiểm thử thường được đặt tên là dựa trên phạm vi hoặc quy mô của chúng.
Cùng với kiểm thử đơn vị, một số ví dụ về các loại kiểm thử khác bao gồm thành phần kiểm thử, kiểm thử trực quan và kiểm thử tích hợp. Không có tên nào trong số này có định nghĩa nghiêm ngặt và chúng có thể có ý nghĩa khác nhau tuỳ thuộc vào cơ sở mã, nên hãy nhớ sử dụng chúng làm hướng dẫn và đưa ra các định nghĩa phù hợp với bạn. Ví dụ: thành phần đang được kiểm thử trong hệ thống của bạn là gì? Cho Phản ứng với các nhà phát triển, theo đúng nghĩa đen thì thành phần này có thể ánh xạ đến một "Thành phần phản ứng", nhưng cũng có thể có ý nghĩa khác đối với nhà phát triển trong các ngữ cảnh khác.
Thang đo của một thử nghiệm riêng lẻ có thể đặt nó bên trong một khái niệm thường được đề cập đến " kim tự tháp kiểm thử", đây có thể là quy tắc chung cho quy trình kiểm thử và cách thức kiểm tra.
Ý tưởng này đã được lặp lại và nhiều hình dạng khác hiện đã được phổ biến, chẳng hạn như thử nghiệm kim cương hoặc đang thử nghiệm hình nón băng. Những ưu tiên khi viết bài kiểm thử có thể sẽ khác nhau cơ sở mã. Tuy nhiên, một tính năng phổ biến là các phép kiểm thử đơn giản hơn, chẳng hạn như kiểm thử đơn vị, có xu hướng chạy nhanh hơn, dễ viết hơn (vì vậy bạn sẽ có nhiều quảng cáo hơn) và thử nghiệm trong phạm vi có giới hạn, trong khi các thử nghiệm phức tạp như thử nghiệm toàn diện khó viết nhưng có thể thử nghiệm ở phạm vi rộng hơn. Trên thực tế, lớp trên cùng của nhiều đang kiểm tra 'hình dạng' có xu hướng được thử nghiệm thủ công, vì một số tương tác của người dùng quá phức tạp nên không thể hệ thống hoá thành một kiểm thử tự động.
Những loại báo cáo này sẽ được mở rộng trong các loại báo cáo tự động kiểm thử.
Kiểm tra kiến thức
Hầu hết các thư viện và khung kiểm thử cung cấp dữ liệu gốc nào?