Những nhược điểm của kiểm tra tự động là gì?

Có một số câu hỏi trên trang web này cung cấp nhiều thông tin về lợi ích có thể thu được từ thử nghiệm tự động. Nhưng tôi đã không thấy bất cứ điều gì đại diện cho mặt khác của đồng tiền: những bất lợi là gì? Mọi thứ trong cuộc sống là một sự đánh đổi và không có viên đạn bạc, vì vậy chắc chắn phải có một số lý do hợp lệ để không thực hiện kiểm tra tự động. Họ là ai?

Đây là một vài cái mà tôi nghĩ ra:

• Yêu cầu thêm thời gian dành cho nhà phát triển ban đầu cho một tính năng nhất định
• Yêu cầu trình độ kỹ năng cao hơn của các thành viên trong nhóm
• Tăng nhu cầu dụng cụ (người chạy thử, khung, v.v.)
• Phân tích phức tạp cần thiết khi một bài kiểm tra thất bại gặp phải - bài kiểm tra này đã lỗi thời do sự thay đổi của tôi hay nó nói với tôi rằng tôi đã phạm sai lầm?

Chỉnh sửa
Tôi nên nói rằng tôi là một người ủng hộ thử nghiệm tự động rất lớn và tôi không muốn bị thuyết phục để làm điều đó. Tôi đang tìm hiểu những bất lợi là gì khi tôi đến công ty của mình để tạo ra một vụ án cho nó Tôi không giống như tôi đang ném xung quanh viên đạn bạc tưởng tượng tiếp theo.

Ngoài ra, tôi tự hào không tìm kiếm ai đó để tranh luận về các ví dụ của tôi ở trên. Tôi đang nói đúng rằng phải có một số nhược điểm (mọi thứ đều có sự đánh đổi) và tôi muốn hiểu những gì chúng là.

Bạn đóng đinh khá nhiều những cái quan trọng nhất. Tôi có một vài bổ sung nhỏ, cộng với nhược điểm của các thử nghiệm thực sự thành công - khi bạn không thực sự muốn chúng (xem bên dưới).

• Thời gian phát triển: Với sự phát triển dựa trên thử nghiệm, điều này đã được tính toán cho các thử nghiệm đơn vị, nhưng bạn vẫn cần thử nghiệm tích hợp và hệ thống, có thể cũng cần mã tự động hóa. Mã được viết một lần thường được thử nghiệm trên một số giai đoạn sau.

• Cấp độ kỹ năng: tất nhiên, các công cụ phải được hỗ trợ. Nhưng đó không chỉ là đội của riêng bạn. Trong dự án lớn hơn, bạn có thể có một nhóm thử nghiệm riêng biệt viết các bài kiểm tra để kiểm tra các giao diện giữa sản phẩm của nhóm bạn và các sản phẩm khác. Vì vậy, nhiều người phải có thêm kiến ​​thức.

• Nhu cầu dụng cụ: bạn đang ở đó. Không có nhiều để thêm vào điều này.

• Thử nghiệm thất bại: Đây là bugger thực sự (đối với tôi dù sao). Có một loạt các lý do khác nhau, mỗi lý do có thể được coi là một bất lợi. Và nhược điểm lớn nhất là thời gian cần thiết để quyết định lý do nào trong số những lý do này thực sự áp dụng cho bài kiểm tra thất bại của bạn.

  • thất bại, vì một lỗi thực tế. (chỉ để hoàn thiện, vì điều này tất nhiên là thuận lợi)
  • không thành công, vì mã kiểm tra của bạn đã được viết với một lỗi truyền thống.
  • không thành công, vì mã kiểm tra của bạn đã được viết cho phiên bản cũ hơn của sản phẩm và không còn tương thích
  • không thành công, vì các yêu cầu đã thay đổi và hành vi được kiểm tra hiện được coi là 'chính xác'

• Các xét nghiệm không thất bại: Đây cũng là một bất lợi và có thể khá tệ. Nó xảy ra chủ yếu, khi bạn thay đổi mọi thứ và đến gần với những gì Adam trả lời. Nếu bạn thay đổi một cái gì đó trong mã sản phẩm của mình, nhưng thử nghiệm hoàn toàn không tính đến nó, thì nó sẽ mang lại cho bạn "cảm giác an toàn sai lầm" này.

  Một khía cạnh quan trọng của các thử nghiệm không thất bại là việc thay đổi các yêu cầu có thể khiến hành vi trước đó trở nên không hợp lệ. Nếu bạn có khả năng truy tìm nguồn gốc tốt, thay đổi yêu cầu sẽ có thể được khớp với mã kiểm tra của bạn và bạn biết rằng bạn không còn có thể tin tưởng vào bài kiểm tra đó nữa. Tất nhiên, việc duy trì khả năng truy tìm nguồn gốc này vẫn là một nhược điểm khác. Và nếu bạn không, bạn sẽ kết thúc bằng một bài kiểm tra không thất bại, nhưng thực sự xác minh rằng sản phẩm của bạn hoạt động sai . Một nơi nào đó trên con đường này sẽ đánh bạn .. thường là khi / nơi bạn ít mong đợi nhất.

• Chi phí triển khai bổ sung: Bạn không chỉ chạy thử nghiệm đơn vị với tư cách là nhà phát triển trên máy của riêng mình. Với các bài kiểm tra tự động, bạn muốn thực hiện chúng trên các cam kết từ những người khác tại một địa điểm trung tâm để tìm hiểu khi ai đó phá vỡ công việc của bạn. Điều này là tốt đẹp, nhưng cũng cần phải được thiết lập và duy trì.

Mới bắt đầu thử các bài kiểm tra tự động trong nhóm của chúng tôi, nhược điểm lớn nhất tôi thấy là rất khó áp dụng cho mã kế thừa không được thiết kế với kiểm tra tự động. Nó chắc chắn sẽ cải thiện mã của chúng tôi trong dài hạn, nhưng mức độ tái cấu trúc cần thiết để kiểm tra tự động trong khi vẫn giữ được sự tỉnh táo của chúng tôi là một rào cản rất cao để gia nhập trong ngắn hạn, có nghĩa là chúng tôi sẽ phải rất chọn lọc trong việc giới thiệu tự động thử nghiệm đơn vị để đáp ứng các cam kết ngắn hạn của chúng tôi. Nói cách khác, việc thanh toán thẻ tín dụng khó hơn rất nhiều khi bạn đang chìm sâu trong nợ kỹ thuật.

Có lẽ nhược điểm quan trọng nhất là ... các bài kiểm tra là mã sản xuất . Mỗi bài kiểm tra bạn viết đều thêm mã vào cơ sở mã của bạn cần được duy trì và hỗ trợ. Không làm như vậy dẫn đến các bài kiểm tra mà bạn không tin vào kết quả, vì vậy bạn không có lựa chọn nào khác. Đừng hiểu lầm tôi - Tôi là một người ủng hộ lớn cho thử nghiệm tự động. Nhưng mọi thứ đều có chi phí, và đây là một vấn đề lớn.

Tôi sẽ không nói đây là những nhược điểm hoàn toàn có thể áp dụng, nhưng số ít tôi gặp phải nhiều nhất là:

• Thời gian thực hiện để thiết lập thử nghiệm trong một ứng dụng doanh nghiệp phức tạp.
• Xử lý các thử nghiệm cũ không chính xác, nói cách khác, hệ thống đã phát triển và bây giờ các thử nghiệm đã sai.
• Tự tin sai từ bảo hiểm thử nghiệm chắp vá hoặc không rõ.

Kiểm tra phạm vi bảo hiểm là chắp vá có thể dẫn đến một cảm giác an toàn sai lầm. Nếu bạn thực hiện tái cấu trúc và sử dụng các thử nghiệm để chứng minh tính hợp lệ của nó, điều gì đã chứng minh các thử nghiệm của bạn có thể chứng minh điều này?

Thời gian để tạo ra bài kiểm tra đôi khi là một vấn đề đối với chúng tôi. Kiểm tra tự động của chúng tôi không chỉ bao gồm kiểm tra đơn vị, mà còn sử dụng kiểm tra trường hợp. Những xu hướng rộng hơn và đòi hỏi bối cảnh.

Tất nhiên, quan điểm của tôi là từ một ứng dụng cũ hơn các bài kiểm tra đơn vị.

Tôi muốn nói rằng vấn đề chính với họ là họ có thể cung cấp một cảm giác an toàn sai lầm . Chỉ vì bạn có các bài kiểm tra đơn vị, điều đó không có nghĩa là họ thực sự đang làm bất cứ điều gì và bao gồm kiểm tra đúng các yêu cầu.

Ngoài ra, các bài kiểm tra tự động cũng có thể bao gồm các lỗi , do đó sẽ đưa ra câu hỏi về việc liệu các bài kiểm tra đơn vị có cần tự kiểm tra hay không để đạt được bất cứ điều gì.

Mặc dù thử nghiệm tự động hóa có nhiều ưu điểm, nhưng nó cũng có nhược điểm riêng. Một số nhược điểm là:

• Thành thạo là cần thiết để viết các kịch bản thử nghiệm tự động hóa.
• Gỡ lỗi kịch bản kiểm tra là vấn đề lớn. Nếu có bất kỳ lỗi nào trong tập lệnh thử nghiệm, đôi khi nó có thể dẫn đến hậu quả chết người.
• Kiểm tra bảo trì là tốn kém trong trường hợp phương pháp phát lại. Mặc dù có một thay đổi nhỏ xảy ra trong GUI, tập lệnh kiểm tra phải được điều chỉnh lại hoặc thay thế bằng tập lệnh kiểm tra mới.
• Bảo trì các tệp dữ liệu kiểm tra là khó khăn, nếu tập lệnh kiểm tra kiểm tra nhiều màn hình hơn.

Một số nhược điểm trên thường trừ đi lợi ích thu được từ các tập lệnh tự động. Mặc dù thử nghiệm tự động hóa có những ưu và nhược điểm, nhưng nó được điều chỉnh rộng rãi trên toàn thế giới.

Gần đây tôi đã hỏi một câu hỏi về các bài kiểm tra trong phát triển trò chơi - đây là BTW làm thế nào tôi biết về bài kiểm tra này. Các câu trả lời chỉ ra một số nhược điểm tò mò, cụ thể:

1. Nó là tốn kém để làm khi mã của bạn nên được kết hợp cao .
2. Thật khó để làm khi bạn phải nhận thức được các nền tảng phần cứng khác nhau, khi bạn nên phân tích đầu ra cho người dùng và kết quả mã chỉ có ý nghĩa trong bối cảnh rộng hơn .
3. Kiểm tra UI và UX là rất khó .
4. Và đáng chú ý, các thử nghiệm tự động có thể tốn kém hơn và kém hiệu quả hơn so với một loạt các thử nghiệm beta chi phí rất thấp (hoặc miễn phí) .

Điểm thứ 4 khiến tôi nhớ về một số kinh nghiệm của tôi. Tôi đã làm việc cho một công ty được quản lý Scrum rất định hướng, XP, nơi các bài kiểm tra đơn vị rất được khuyến khích. Tuy nhiên, trên con đường đi đến một phong cách gọn gàng, ít quan liêu hơn, công ty chỉ bỏ qua việc xây dựng một nhóm QA - chúng tôi không có người thử nghiệm. Vì vậy, thường xuyên khách hàng tìm thấy các lỗi nhỏ khi sử dụng một số hệ thống, ngay cả với phạm vi kiểm tra> 95%. Vì vậy, tôi sẽ thêm một điểm khác:

• Kiểm tra tự động có thể khiến bạn cảm thấy rằng QA và kiểm tra không quan trọng.

Ngoài ra, tôi đã suy nghĩ những ngày đó về tài liệu và đưa ra một giả thuyết có thể hợp lệ (với một phần mở rộng ít hơn) để kiểm tra hai. Tôi chỉ cảm thấy rằng mã phát triển quá nhanh đến nỗi khá khó để tạo ra tài liệu tuân theo vận tốc như vậy, vì vậy sẽ có giá trị hơn khi dành thời gian để làm cho mã dễ đọc hơn là viết tài liệu nặng, dễ lỗi thời. (Tất nhiên, điều này không áp dụng cho API, mà chỉ áp dụng cho việc triển khai nội bộ.) Bài kiểm tra chịu một chút vấn đề tương tự: có thể quá chậm để viết khi so sánh với mã được kiểm tra. OTOH, đó là một vấn đề ít hơn bởi vì các bài kiểm tra cảnh báo chúng đã lỗi thời, trong khi tài liệu của bạn sẽ giữ im lặng miễn là bạn không đọc lại nó rất, rất cẩn thận .

Cuối cùng, một vấn đề đôi khi tôi thấy: kiểm tra tự động có thể phụ thuộc vào các công cụ và những công cụ đó có thể được viết kém. Tôi đã bắt đầu một dự án bằng XUL một thời gian trước đây và, thật khó để viết các bài kiểm tra đơn vị cho nền tảng như vậy. Tôi đã bắt đầu một ứng dụng khác bằng Objective-C, Ca cao và Xcode 3 và mô hình thử nghiệm trên đó về cơ bản là một loạt các cách giải quyết.

Tôi có kinh nghiệm khác về những bất lợi của kiểm tra tự động, nhưng hầu hết chúng được liệt kê trong các câu trả lời khác. Tuy nhiên, tôi là một người ủng hộ kịch liệt của thử nghiệm tự động. Điều này đã tiết kiệm rất nhiều công việc và đau đầu và tôi luôn đề xuất nó theo mặc định. Tôi đánh giá những nhược điểm đó chỉ là chi tiết khi so sánh với lợi ích của kiểm tra tự động. (Điều quan trọng là luôn luôn tuyên bố đức tin của bạn sau khi bạn nhận xét những điều dị giáo để tránh tự động.)

Hai cái không được đề cập là:

• Thời gian của đồng hồ có thể mất để chạy một bộ thử nghiệm lớn

Tôi đã từng là một phần của các nỗ lực QA tự động khi phải mất nửa ngày để chạy thử nghiệm, vì các thử nghiệm rất chậm. Nếu bạn không cẩn thận với việc viết bài kiểm tra của mình, bộ kiểm tra của bạn cũng có thể diễn ra theo cách này. Điều này có vẻ không phải là một vấn đề lớn cho đến khi bạn quản lý thời gian đó, "Ồ, tôi vừa mới sửa lỗi, nhưng sẽ mất 4 giờ để chứng minh sự đúng đắn".

• Lỗi một số phương pháp viết bài kiểm tra

Một số phương pháp kiểm tra (như tự động hóa giao diện người dùng) dường như bị hỏng mỗi khi bạn quay lại. Đặc biệt đau đớn nếu tập lệnh của bạn bị treo quá trình thử nghiệm vì nó đang chờ một nút xuất hiện - nhưng nút đã được đổi tên.

Đây là cả hai điều bạn có thể làm việc xung quanh, với thực hành kiểm tra tốt: tìm cách giữ cho bộ kiểm tra của bạn nhanh (ngay cả khi bạn phải thực hiện các thủ thuật như phân phối chạy thử trên các máy / CPU). Tương tự như vậy, một số chăm sóc có thể được thực hiện để cố gắng tránh các phương pháp viết bài kiểm tra yếu.

Tôi muốn thêm một, một cảm giác an toàn sai lầm.

Ngoài các bộ vấn đề được xác định rất nhỏ, không thể tạo ra các bài kiểm tra toàn diện. Có thể và thường sẽ vẫn có lỗi trong phần mềm của chúng tôi mà các bài kiểm tra tự động đơn giản là không kiểm tra. Khi các bài kiểm tra tự động vượt qua tất cả chúng ta thường cho rằng không có lỗi trong mã.

Thật khó để thuyết phục nhà quản lý / đầu tư mạo hiểm

• testautomation làm tăng chi phí trả trước.
• testautomation tăng thời gian để thị trường.
• lợi ích của testautomation đến giữa và logterm. cạnh tranh khốc liệt tập trung nhiều hơn vào lợi ích ngắn hạn.

xem Kiểm tra đơn vị hướng thị trường để biết chi tiết.

Một trong những nhược điểm chính có thể được khắc phục bằng cách sử dụng các bài kiểm tra tự học. Trong tình huống này, tất cả các kết quả dự kiến ​​sẽ được lưu trữ dưới dạng dữ liệu và có thể cập nhật với sự xem xét tối thiểu của người dùng bộ thử nghiệm ở chế độ tự học (hiển thị khác nhau giữa kết quả dự kiến ​​cũ và kết quả thực tế mới - cập nhật dự kiến ​​nếu nhấn y). Chế độ học tập testsuite này cần được sử dụng một cách thận trọng để hành vi lỗi không được học là có thể chấp nhận được.