Tại sao lập trình viên cần kiểm thử?
Một vài cấp độ tiếp theo sẽ dành cho việc thử nghiệm theo cách mà các lập trình viên cần . Nhưng trước tiên, hãy tìm hiểu thử nghiệm là gì và tại sao nó lại cần thiết.
Đối với phần mềm, chúng ta có thể nói rằng nhiệm vụ của kiểm thử là kiểm tra xem chương trình đó có:
- làm những gì cô ấy phải làm
- không làm những gì cô ấy không nên làm
Nhân tiện, điểm thứ hai không kém phần quan trọng hơn điểm đầu tiên, nhưng nhiều hơn về điều đó sau.
Hãy bắt đầu với điểm đầu tiên. "Chương trình làm những gì nó phải làm" nghĩa là gì?
Đầu tiên, ai đó cần lập danh sách tất cả các trường hợp sử dụng cho chương trình. Thứ hai, họ cần mô tả chương trình sẽ hoạt động như thế nào, hành vi của người dùng như thế nào và kết quả mong đợi là gì. Bạn không thể tiếp tục hơn nữa.
Ngay khi chúng tôi viết “người dùng nên cư xử như thế nào”, toàn bộ ý tưởng viết tài liệu tốt đã sụp đổ. Con người không phải là máy móc, hơn nữa, con người thường cư xử với phần mềm theo ý họ muốn . Không ai bắt đầu làm quen với công nghệ bằng cách nghiên cứu hướng dẫn. Đó là một thực tế.
Do đó, chúng tôi nhận được một thực tế mới: điểm đặc biệt của phần mềm là nó có rất nhiều kịch bản công việc khác nhau. Một số trong số chúng là rõ ràng, một số khác có thể được ghi lại, một số khác có thể được giả định, một số khác có thể đoán được và 50% còn lại thậm chí sẽ không xảy ra với bạn.
Theo quan điểm của một lập trình viên, hầu hết các lỗi không phải là lỗi. Lỗi là khi một chương trình không hoạt động như bình thường hoặc như mong đợi. Và có rất nhiều tình huống không rõ chương trình nên hoạt động như thế nào, hoặc các kịch bản mâu thuẫn với nhau ...
Có vô số tình huống và sẽ luôn có những trường hợp trong sản phẩm khi chương trình không hoạt động như mong đợi (lập trình viên chỉ viết mã cho vài chục tình huống). Do đó, có thể lập luận rằng luôn có lỗi trong bất kỳ chương trình nào và bất kỳ sản phẩm nào cũng có thể được cải thiện không ngừng .
Sau đó, tất cả đi xuống để có lợi. Đầu tiên, lập trình viên sửa các lỗi lớn nhất, sau đó là các lỗi nhỏ hơn, v.v. Và cuối cùng, đến một giai đoạn khi chủ sở hữu của sản phẩm tin rằng việc tiếp tục làm việc với nó là không khả thi về mặt kinh tế.
Nhưng quay lại với những lỗi mà mọi người đều nhận ra là lỗi: chương trình rõ ràng làm sai điều gì đó, bị rơi, hỏng thứ gì đó, v.v. Những lỗi như vậy có thể được chia thành 3 loại: lớn, trung bình và nhỏ.
Và điều rất thường xảy ra là một lập trình viên đang làm việc để sửa các lỗi trung bình hoặc thậm chí nhỏ, mặc dù vẫn còn rất nhiều vấn đề nghiêm trọng hơn trong dự án. Anh ấy chỉ không tìm thấy chúng , vì vậy anh ấy đang nghiên cứu những cái lớn nhất mà anh ấy biết.
Do đó, trong bất kỳ dự án nào cũng nên có người kiểm thử. Những người này đặc biệt học cách nhìn sản phẩm từ các góc độ khác nhau. Để bạn có thể xem thêm các kịch bản của chương trình. Nhiệm vụ của họ là tìm lỗi và viết chúng ra (để không tìm thấy cùng một lỗi nhiều lần).
Kiểm thử là một quá trình nhằm tìm ra lỗi. Những lỗi này nên được tìm thấy, mô tả và ưu tiên. Chỉ sau khi sắp xếp thứ tự ưu tiên các lỗi, chúng ta mới có thể nói về một quy trình cải tiến phần mềm hiệu quả.
Hãy nhớ rằng, bước đầu tiên để giải quyết vấn đề là thừa nhận rằng có vấn đề . Bạn không thể sửa chữa một sai lầm mà bạn không biết về nó.
Kiểm thử tự động
Tôi nghĩ rằng tất cả chúng ta đều đồng ý rằng kiểm thử là quan trọng, vì vậy hãy xem xét kiểm thử giống như các lập trình viên. Làm thế nào để các lập trình viên xem thử nghiệm? Lập trình viên tự động hóa công việc của người khác. Nghề cuối cùng biến mất sẽ là nghề lập trình.
Chúng tôi tự động hóa bất kỳ quy trình nào chúng tôi gặp phải. Vì vậy, thử nghiệm cần phải được tự động hóa. Và làm cách nào để tự động tìm lỗi? Câu trả lời ngắn gọn: không. Nhưng ở đây một lần nữa, thực tế là chúng tôi là những lập trình viên lại hỗ trợ chúng tôi.
Quá trình phát triển phần mềm bao gồm những thay đổi liên tục đối với nó. chỉ trong quá trình liên tục thực hiện các thay đổi, các lập trình viên thường làm hỏng một số thứ vẫn hoạt động tốt cho đến gần đây.
Và những người kiểm tra, thay vì tìm kiếm những lỗi mới, buộc phải liên tục kiểm tra xem chúng ta có làm hỏng thứ gì đó đã hoạt động tốt trong một thời gian dài hay không. Cái gọi là thử nghiệm hồi quy. Đây là loại thử nghiệm có thể và nên được tự động hóa.
Ở đây tất cả các phần mềm có thể được chia thành hai phần:
- chương trình tương tác với người
- chương trình tương tác với chương trình khác
Tùy chọn đầu tiên khó tự động hóa hơn, nó yêu cầu những người kiểm tra trình tự động hóa đặc biệt, họ còn được gọi là Kỹ sư kiểm tra phần mềm hoặc tự động hóa QA.
Nhưng tùy chọn thứ hai có thể và nên được tự động hóa một cách độc lập. Nếu bạn có một phần mềm:
- hoạt động tốt
- đã được thử nghiệm
- được triển khai dưới dạng một mô-đun hoặc khối logic riêng biệt
- không có ý định thay đổi
- các mô-đun hoặc chương trình khác phụ thuộc vào nó
- thất bại chức năng là tốn kém
Tôi khuyên bạn nên dành thời gian để viết các bài kiểm tra để nắm bắt các khía cạnh chính của chức năng hiện tại của nó. Sẽ là hợp lý nếu bạn dành 5% thời gian làm việc cho việc này , hoặc 1 ngày mỗi tháng.
Không cần phải viết bài kiểm tra vì lợi ích của bài kiểm tra.
Không ai sẽ hỗ trợ các bài kiểm tra của bạn. Không phải các lập trình viên khác, không phải chính bạn. Chả ai làm điều đó. 99% tất cả các bài kiểm tra viết đều bị bỏ và/hoặc bị vô hiệu hóa. Nếu bạn không thể viết bài kiểm tra - đừng viết. Chỉ viết nếu bạn hoàn toàn không thể làm gì nếu không có chúng.
Các loại thử nghiệm
Mỗi lập trình viên, nếu anh ta chưa trải qua khóa đào tạo đặc biệt, sẽ có thể nói theo cách riêng của mình kiểm tra là gì: kiểm tra xem chương trình có hoạt động như bình thường hay không. Tuy nhiên, các chuyên gia trong lĩnh vực này phân biệt toàn bộ các lĩnh vực (loại) thử nghiệm.
Tất cả các thử nghiệm thực sự xoay quanh độ tin cậy và tính khả dụng của phần mềm, nhưng để hiểu rõ hơn về hướng thử nghiệm, hãy xem xét một vài ví dụ.
Giả sử bạn đang thử nghiệm một cửa hàng trực tuyến điển hình. Sau đó, các lĩnh vực kiểm thử có thể được chia thành các loại sau: kiểm thử hiệu năng, kiểm thử chức năng, kiểm thử tích hợp và kiểm thử đơn vị.
Nếu chủ sở hữu trang web quyết định khởi chạy một chiến dịch quảng cáo nghiêm túc, thì rất nhiều người dùng sẽ truy cập trang web cùng một lúc. Rất có thể trang web sẽ không bị sập, nhưng một số phần của nó có thể bị chậm hoặc thậm chí ngừng hoạt động.
Để ngăn điều này xảy ra, bạn cần xác định trước những vấn đề như vậy và thực hiện các bước để loại bỏ chúng. Điều này được thực hiện bằng cách sử dụng thử nghiệm tải , hay còn được gọi là thử nghiệm hiệu suất.
Bạn cũng có thể muốn kiểm tra cách hoạt động của API phụ trợ và kiểm tra mọi chức năng của nó: đăng ký, đăng nhập, thêm vào giỏ hàng, xử lý thanh toán, ghi cơ sở dữ liệu, v.v. Mọi thứ phải hoạt động theo TOR. Trong trường hợp này, bạn cần thực hiện kiểm tra chức năng .
Cửa hàng trực tuyến của bạn rất có thể được tích hợp với các dịch vụ của bên thứ ba: gửi thư và SMS, hệ thống thanh toán, trò chuyện hỗ trợ trực tuyến, thu thập phản hồi từ người dùng, hệ thống quảng cáo, v.v. Để đảm bảo rằng tất cả những điều này hoạt động như mong muốn, bạn cần thử nghiệm tích hợp .
Cuối cùng, các sản phẩm phức tạp thường được chia nhỏ thành các mô-đun độc lập. Từ các mô-đun như vậy, bạn có thể lắp ráp sản phẩm cuối cùng, như từ một hàm tạo. Nếu bạn đang phát triển một mô-đun như vậy hoặc tương tác với các mô-đun đó, thì bạn sẽ cần thực hiện kiểm thử đơn vị .
Tóm lại, chúng ta có thể nói rằng kiểm thử chức năng là cần thiết để kiểm tra từng chức năng riêng lẻ của trang web. Tích hợp - để kiểm tra sự tương tác của các mô-đun và hệ thống lớn của sản phẩm của bạn. Mô-đun - để kiểm tra một mô-đun riêng biệt, tốt, kiểm tra hiệu suất - để kiểm tra hoạt động của trang web của bạn khi tải.
Thậm chí có thể có nhiều loại thử nghiệm hơn: sản phẩm càng phức tạp thì càng cần kiểm soát nhiều khía cạnh phát triển của nó.