RSVP for your your local TensorFlow Everywhere event today!
Trang này được dịch bởi Cloud Translation API.
Switch to English

Các phương pháp hay nhất về thử nghiệm TensorFlow

Đây là các phương pháp được khuyến nghị để kiểm tra mã trong kho lưu trữ TensorFlow .

Trước khi bạn bắt đầu

Trước khi bạn đóng góp mã nguồn cho dự án TensorFlow, vui lòng xem lại tệp CONTRIBUTING.md trong repo GitHub của dự án. (Ví dụ: xem tệp CONTRIBUTING.md cho đại diện TensorFlow cốt lõi .) Tất cả những người đóng góp mã phải ký Thỏa thuận cấp phép cộng tác viên (CLA).

Nguyên tắc chung

Chỉ phụ thuộc vào những gì bạn sử dụng trong quy tắc BUILD của mình

TensorFlow là một thư viện lớn và phụ thuộc vào gói đầy đủ khi viết một bài kiểm tra đơn vị cho các mô-đun con của nó là một thực tế phổ biến. Tuy nhiên, điều này vô hiệu hóa phân tích dựa trên sự phụ thuộc bazel . Điều này có nghĩa là các hệ thống tích hợp liên tục không thể loại bỏ một cách thông minh các bài kiểm tra không liên quan cho các lần gửi trước / gửi sau. Nếu bạn chỉ phụ thuộc vào các mô-đun con mà bạn đang thử nghiệm trong tệp BUILD của mình, bạn sẽ tiết kiệm thời gian cho tất cả các nhà phát triển TensorFlow và rất nhiều sức mạnh tính toán có giá trị.

Tuy nhiên, việc sửa đổi sự phụ thuộc vào bản dựng của bạn để bỏ qua các mục tiêu TF đầy đủ sẽ mang lại một số hạn chế cho những gì bạn có thể nhập trong mã Python của mình. Bạn sẽ không thể sử dụng lệnh import tensorflow as tf trong các bài kiểm tra đơn vị của bạn nữa. Nhưng đây là một sự đánh đổi đáng giá vì nó giúp tất cả các nhà phát triển không phải chạy hàng nghìn bài kiểm tra không cần thiết.

Tất cả mã phải có kiểm tra đơn vị

Đối với bất kỳ mã nào bạn viết, bạn cũng nên viết các bài kiểm tra đơn vị của nó. Nếu bạn viết một tệp mới foo.py , bạn nên đặt các bài kiểm tra đơn vị của nó trong foo_test.py và gửi nó trong cùng một thay đổi. Nhắm đến mức độ bao phủ thử nghiệm gia tăng> 90% cho tất cả mã của bạn.

Tránh sử dụng các quy tắc kiểm tra bazel gốc trong TF

TF có rất nhiều sự tinh tế khi chạy thử nghiệm. Chúng tôi đã làm việc để ẩn tất cả những phức tạp đó trong các macro bazel của chúng tôi. Để tránh phải đối phó với những điều đó, hãy sử dụng các quy tắc sau thay vì các quy tắc kiểm tra gốc. Lưu ý rằng tất cả những điều này được định nghĩa trong tensorflow/tensorflow.bzl Đối với các bài kiểm tra CC, hãy sử dụng tf_cc_test , tf_gpu_cc_test , tf_gpu_only_cc_test . Để kiểm tra python, hãy sử dụng tf_py_test hoặc gpu_py_test . Nếu bạn cần thứ gì đó thực sự gần với quy tắc py_test gốc, hãy sử dụng quy tắc được xác định trong tensorflow.bzl để thay thế. Bạn chỉ cần thêm dòng sau vào đầu tệp BUILD: load(“tensorflow/tensorflow.bzl”, “py_test”)

Nhận biết nơi thực hiện kiểm tra

Khi bạn viết một bài kiểm tra, cơ sở hạ tầng kiểm tra của chúng tôi có thể đảm nhận việc chạy các bài kiểm tra của bạn trên CPU, GPU và bộ tăng tốc nếu bạn viết chúng phù hợp. Chúng tôi có các bài kiểm tra tự động chạy trên Linux, macos, windows, những hệ thống có hoặc không có GPU. Bạn chỉ cần chọn một trong các macro được liệt kê ở trên, sau đó sử dụng các thẻ để giới hạn nơi chúng được thực thi.

  • manual thẻ sẽ loại trừ thử nghiệm của bạn từ bất cứ nơi nào chạy. Điều này bao gồm thực hiện kiểm tra thủ công sử dụng các mẫu như bazel test tensorflow/…

  • no_oss sẽ loại trừ thử nghiệm của bạn chạy trong cơ sở hạ tầng thử nghiệm TF OSS chính thức.

  • no_mac hoặc no_windows có thể được sử dụng để loại trừ thử nghiệm của bạn khỏi các bộ thử nghiệm hệ điều hành có liên quan.

  • Thẻ no_gpu có thể được sử dụng để loại trừ thử nghiệm của bạn chạy trong bộ thử nghiệm GPU.

Xác minh các thử nghiệm chạy trong các bộ thử nghiệm dự kiến

TF có khá nhiều dãy phòng thử nghiệm. Đôi khi, chúng có thể gây nhầm lẫn khi thiết lập. Có thể có các vấn đề khác nhau khiến các thử nghiệm của bạn bị bỏ qua khỏi các bản dựng liên tục. Do đó, bạn nên xác minh rằng các thử nghiệm của bạn đang thực hiện như mong đợi. Để làm điều này:

  • Chờ các bản gửi trước trong Yêu cầu kéo (PR) của bạn chạy đến khi hoàn thành.
  • Cuộn xuống cuối PR của bạn để xem các kiểm tra trạng thái.
  • Nhấp vào liên kết "Chi tiết" ở phía bên phải của bất kỳ kiểm tra Kokoro nào.
  • Kiểm tra danh sách "Mục tiêu" để tìm các mục tiêu mới được thêm vào của bạn.

Mỗi lớp / đơn vị phải có tệp kiểm tra đơn vị riêng của nó

Các lớp kiểm tra riêng biệt giúp chúng tôi cô lập tốt hơn các lỗi và tài nguyên. Chúng dẫn đến các tệp thử nghiệm ngắn hơn và dễ đọc hơn nhiều. Do đó, tất cả các tệp Python của bạn phải có ít nhất một tệp thử nghiệm tương ứng (Đối với mỗi foo.py , nó phải có foo_test.py ). Đối với các bài kiểm tra phức tạp hơn, chẳng hạn như các bài kiểm tra tích hợp yêu cầu các thiết lập khác nhau, bạn có thể thêm nhiều tệp kiểm tra hơn.

Tốc độ và thời gian chạy

Sharding nên được sử dụng càng ít càng tốt

Thay vì sharding, vui lòng xem xét:

  • Làm cho các thử nghiệm của bạn nhỏ hơn
  • Nếu những điều trên không thực hiện được, hãy chia nhỏ các bài kiểm tra ra

Sharding giúp giảm độ trễ tổng thể của một bài kiểm tra, nhưng điều tương tự cũng có thể đạt được bằng cách chia nhỏ các bài kiểm tra thành các mục tiêu nhỏ hơn. Việc phân tách các bài kiểm tra mang lại cho chúng tôi mức độ kiểm soát tốt hơn trên mỗi bài kiểm tra, giảm thiểu các lần chạy gửi trước không cần thiết và giảm tổn thất vùng phủ sóng từ việc bản dựng làm vô hiệu hóa toàn bộ mục tiêu do hộp kiểm hoạt động sai. Hơn nữa, sharding phải chịu các chi phí ẩn không quá rõ ràng, chẳng hạn như chạy tất cả mã khởi tạo thử nghiệm cho tất cả các phân đoạn. Vấn đề này đã được chúng tôi báo cáo bởi các nhóm hạ tầng như một nguồn tạo ra tải thêm.

Thử nghiệm nhỏ hơn sẽ tốt hơn

Các thử nghiệm của bạn chạy càng nhanh, thì càng có nhiều khả năng mọi người chạy thử nghiệm của bạn. Thêm một giây cho bài kiểm tra của bạn có thể tích lũy thêm hàng giờ dành cho việc chạy thử nghiệm của các nhà phát triển và cơ sở hạ tầng của chúng tôi. Cố gắng làm cho các bài kiểm tra của bạn chạy dưới 30 giây (ở chế độ không chọn!) Và thu nhỏ chúng. Chỉ đánh dấu các bài kiểm tra của bạn là phương tiện cuối cùng. Cơ sở hạ tầng không chạy bất kỳ thử nghiệm lớn nào dưới dạng gửi trước hoặc gửi sau! Do đó, chỉ nên viết một bài kiểm tra lớn nếu bạn sắp xếp nơi nó sẽ chạy. Một số mẹo giúp kiểm tra chạy nhanh hơn:

  • Chạy ít lần lặp lại đào tạo hơn trong thử nghiệm của bạn
  • Cân nhắc sử dụng phương pháp chèn phụ thuộc để thay thế các phần phụ thuộc nặng của hệ thống đang thử nghiệm bằng các lỗi đơn giản.
  • Cân nhắc sử dụng dữ liệu đầu vào nhỏ hơn trong các bài kiểm tra đơn vị
  • Nếu không có gì khác hoạt động, hãy thử chia nhỏ tệp thử nghiệm của bạn.

Thời gian thử nghiệm nên dành cho một nửa thời gian chờ của kích thước thử nghiệm để tránh bong tróc

Với các mục tiêu kiểm tra bazel , các bài kiểm tra nhỏ có thời gian chờ 1 phút. Thời gian chờ của bài kiểm tra trung bình là 5 phút. Các thử nghiệm lớn không được thực hiện bởi cơ sở hạ tầng thử nghiệm TensorFlow. Tuy nhiên, nhiều bài kiểm tra không xác định được lượng thời gian chúng thực hiện. Vì nhiều lý do khác nhau, thỉnh thoảng các bài kiểm tra của bạn có thể mất nhiều thời gian hơn. Và, nếu bạn đánh dấu một bài kiểm tra chạy trung bình trong 50 giây là nhỏ, thì bài kiểm tra của bạn sẽ bị lỗi nếu nó lên lịch trên một máy có CPU cũ. Do đó, hãy đặt mục tiêu thời gian chạy trung bình 30 giây cho các bài kiểm tra nhỏ. Đặt mục tiêu thời gian chạy trung bình là 2 phút 30 giây cho các bài kiểm tra trung bình.

Giảm số lượng mẫu và tăng dung sai cho đào tạo

Kiểm tra chạy chậm ngăn cản những người đóng góp. Chạy huấn luyện trong các bài kiểm tra có thể rất chậm. Thích dung sai cao hơn để có thể sử dụng ít mẫu hơn trong các thử nghiệm của bạn để giữ cho các thử nghiệm của bạn đủ nhanh (tối đa 2,5 phút).

Loại bỏ thuyết không xác định và mảnh

Viết các bài kiểm tra xác định

Các bài kiểm tra đơn vị phải luôn mang tính xác định. Tất cả các bài kiểm tra chạy trên TAP và guitar phải chạy theo cùng một cách mỗi lần, nếu không có thay đổi mã nào ảnh hưởng đến chúng. Để đảm bảo điều này, dưới đây là một số điểm cần xem xét.

Luôn gieo rắc bất kỳ nguồn ngẫu nhiên nào

Bất kỳ trình tạo số ngẫu nhiên nào hoặc bất kỳ nguồn ngẫu nhiên nào khác đều có thể gây ra hiện tượng không ổn định. Vì vậy, mỗi cái này phải được gieo hạt. Ngoài việc làm cho các bài kiểm tra ít bong tróc hơn, điều này làm cho tất cả các bài kiểm tra có thể tái tạo. Các cách khác nhau để đặt một số hạt giống mà bạn có thể cần đặt trong thử nghiệm TF là:

# Python RNG
import random
random.seed(42)

# Numpy RNG
import numpy as np
np.random.seed(42)

# TF RNG
from tensorflow.python.framework import random_seed
random_seed.set_seed(42)

Tránh sử dụng sleep trong các bài kiểm tra đa luồng

Sử dụng chức năng sleep trong các bài kiểm tra có thể là nguyên nhân chính gây ra tình trạng bong tróc da. Đặc biệt khi sử dụng nhiều luồng, việc sử dụng chế độ ngủ để chờ một luồng khác sẽ không bao giờ có tính xác định. Điều này là do hệ thống không thể đảm bảo bất kỳ thứ tự thực hiện các luồng hoặc quy trình khác nhau. Do đó, hãy ưu tiên các cấu trúc đồng bộ hóa xác định như mutexes.

Kiểm tra xem bài kiểm tra có bị bong không

Các mảnh gây ra lỗi xây dựng và các nhà phát triển mất nhiều giờ. Chúng khó phát hiện và khó gỡ lỗi. Mặc dù có các hệ thống tự động để phát hiện lỗi, chúng cần phải tích lũy hàng trăm lần chạy thử trước khi có thể từ chối chính xác các bài kiểm tra trong danh sách. Ngay cả khi họ phát hiện, họ từ chối danh sách các thử nghiệm của bạn và phạm vi kiểm tra bị mất. Do đó, các tác giả bài kiểm tra nên kiểm tra xem bài kiểm tra của họ có bị bong tróc khi viết bài kiểm tra hay không. Điều này có thể dễ dàng thực hiện bằng cách chạy thử nghiệm của bạn với cờ: --runs_per_test=1000

Sử dụng TensorFlowTestCase

TensorFlowTestCase thực hiện các biện pháp phòng ngừa cần thiết, chẳng hạn như gieo hạt tất cả các trình tạo số ngẫu nhiên được sử dụng để giảm hiện tượng bong tróc nhiều nhất có thể. Khi chúng tôi phát hiện và khắc phục nhiều nguồn rung hơn, tất cả những nguồn này sẽ được thêm vào TensorFlowTestCase. Do đó, bạn nên sử dụng TensorFlowTestCase khi viết các bài kiểm tra cho tensorflow. TensorFlowTestCase được định nghĩa tại đây: tensorflow/python/framework/test_util.py

Viết các bài kiểm tra kín

Kiểm tra Hermetic không cần bất kỳ nguồn lực bên ngoài nào. Họ được đóng gói với mọi thứ họ cần và họ chỉ bắt đầu bất kỳ dịch vụ giả mạo nào mà họ có thể cần. Bất kỳ dịch vụ nào ngoài các thử nghiệm của bạn đều là nguồn không xác định. Ngay cả với 99% tính khả dụng của các dịch vụ khác, mạng có thể bong tróc, phản hồi rpc có thể bị trì hoãn và bạn có thể nhận được thông báo lỗi không thể giải thích được. Các dịch vụ bên ngoài có thể là, nhưng không giới hạn, GCS, S3 hoặc bất kỳ trang web nào.