Có phải là một ý tưởng tốt để đo hiệu suất của một phương pháp bằng cách sử dụng thời gian chờ kiểm tra đơn vị?

Trong dự án có các yêu cầu phi chức năng chỉ định thời gian thực hiện tối đa cho một hành động cụ thể, QA phải kiểm tra hiệu suất của hành động này trên máy chuyên dụng sử dụng phần cứng chính xác dưới tải chính xác, cả phần cứng và tải được chỉ định trong yêu cầu.

Mặt khác, một số thay đổi sai đối với mã nguồn có thể ảnh hưởng nghiêm trọng đến hiệu suất. Nhận thấy tác động tiêu cực này sớm , trước khi mã nguồn đạt đến sự kiểm soát nguồn và được bộ phận QA xác minh, có thể có lợi về mặt thời gian bị mất bởi bộ phận QA báo cáo vấn đề và do nhà phát triển sửa nó vài lần cam kết sau đó.

Để làm điều này, nó là một ý tưởng tốt:

• Để sử dụng các bài kiểm tra đơn vị để có ý tưởng về thời gian thực hiện cùng một hành động² n lần,

• Để sử dụng thời gian chờ cho mỗi bài kiểm tra thông qua [TestMethod, Timeout(200)]thuộc tính trong C #?

Tôi mong đợi một số vấn đề với phương pháp này:

• Về mặt khái niệm , các bài kiểm tra đơn vị không thực sự cho điều đó: chúng được dự kiến ​​sẽ kiểm tra một phần nhỏ của mã, không có gì nữa: không phải kiểm tra yêu cầu chức năng, cũng không phải kiểm thử tích hợp, cũng không phải kiểm tra hiệu năng.

• Thời gian chờ kiểm tra đơn vị trong Visual Studio có thực sự đo được những gì dự kiến ​​sẽ được đo, có tính đến việc khởi tạo và dọn dẹp không tồn tại cho các thử nghiệm đó hoặc quá ngắn để ảnh hưởng đến kết quả không?

• Đo lường hiệu suất theo cách này là xấu xí. Chạy một điểm chuẩn trên bất kỳ máy nào, độc lập với phần cứng, tải, v.v. cũng giống như thực hiện một điểm chuẩn cho thấy một sản phẩm cơ sở dữ liệu luôn nhanh hơn một sản phẩm khác. Mặt khác, tôi không mong đợi các bài kiểm tra đơn vị đó là kết quả cuối cùng, cũng không phải là thứ được sử dụng bởi bộ phận QA . Các thử nghiệm đơn vị đó sẽ được sử dụng chỉ để đưa ra ý tưởng chung về hiệu suất dự kiến ​​và về cơ bản để cảnh báo cho nhà phát triển rằng sửa đổi cuối cùng của anh ta đã phá vỡ thứ gì đó, ảnh hưởng nghiêm trọng đến hiệu suất .

• Kiểm tra hướng phát triển (TDD) là không thể đối với các thử nghiệm đó. Làm thế nào nó sẽ thất bại, ở nơi đầu tiên, trước khi bắt đầu thực hiện mã?

• Quá nhiều bài kiểm tra hiệu suất sẽ ảnh hưởng đến thời gian cần thiết để chạy các bài kiểm tra, vì vậy phương pháp này chỉ giới hạn ở các hành động ngắn.

Khi tính đến những vấn đề đó, tôi vẫn thấy thú vị khi sử dụng các bài kiểm tra đơn vị như vậy nếu được kết hợp với các số liệu hiệu suất thực tế của bộ phận QA.

Tôi có lầm không? Có những vấn đề khác khiến cho việc sử dụng các bài kiểm tra đơn vị cho việc này hoàn toàn không được chấp nhận?

Nếu tôi sai, cách chính xác để cảnh báo cho nhà phát triển rằng sự thay đổi trong mã nguồn ảnh hưởng nghiêm trọng đến hiệu suất, trước khi mã nguồn đạt được kiểm soát nguồn và được bộ phận QA xác minh?

^{Trên thực tế, các bài kiểm tra đơn vị dự kiến ​​sẽ chỉ chạy trên các PC của nhà phát triển có hiệu năng phần cứng tương đương, giúp giảm khoảng cách giữa các máy nhanh nhất sẽ không bao giờ có thể thất bại trong bài kiểm tra hiệu năng và các máy chậm nhất sẽ không bao giờ thành công khi vượt qua.}

^{² Theo hành động, ý tôi là một đoạn mã khá ngắn dành vài mili giây để chạy.}

Chúng tôi cũng đang sử dụng phương pháp này, tức là chúng tôi có các bài kiểm tra đo thời gian chạy theo một số kịch bản tải được xác định trên một máy nhất định. Điều quan trọng có thể chỉ ra rằng, chúng tôi không bao gồm những điều này trong các bài kiểm tra đơn vị bình thường. Các thử nghiệm đơn vị về cơ bản được thực hiện bởi mỗi nhà phát triển trên máy của nhà phát triển trước khi thực hiện các thay đổi. Xem bên dưới để biết lý do tại sao điều này không có ý nghĩa gì đối với các bài kiểm tra hiệu suất (ít nhất là trong trường hợp của chúng tôi). Thay vào đó, chúng tôi chạy thử nghiệm hiệu suất như là một phần của thử nghiệm tích hợp.

Bạn đã chỉ ra một cách chính xác, rằng điều này không nên loại trừ xác minh. Chúng tôi không cho rằng thử nghiệm của chúng tôi là thử nghiệm của yêu cầu phi chức năng. Thay vào đó, chúng tôi coi đó là một chỉ báo vấn đề tiềm năng.

Tôi không chắc chắn về sản phẩm của bạn, nhưng trong trường hợp của chúng tôi, nếu hiệu suất không đủ, điều đó có nghĩa là rất nhiều công việc được yêu cầu để "khắc phục" điều đó. Vì vậy, thời gian quay vòng, khi chúng ta để điều này hoàn toàn cho QA là khủng khiếp. Ngoài ra, các bản sửa lỗi hiệu năng sẽ có tác động nghiêm trọng đến một phần lớn của cơ sở mã, làm cho khoảng trống công việc QA trước đó bị vô hiệu hóa. Trên tất cả, một quy trình làm việc rất không hiệu quả và không thỏa mãn.

Điều đó đang được nói, đây là một số điểm cho các vấn đề tương ứng của bạn:

• Về mặt khái niệm: đó là sự thật, rằng đây không phải là những gì bài kiểm tra đơn vị nói về. Nhưng miễn là mọi người biết, thử nghiệm không phải xác minh bất cứ điều gì QA nên làm, nó vẫn ổn.

• Visual Studio: không thể nói bất cứ điều gì về điều đó, vì chúng tôi không sử dụng khung kiểm tra đơn vị từ VS.

• Máy: Phụ thuộc vào sản phẩm. Nếu sản phẩm của bạn là thứ được phát triển cho người dùng cuối với các máy tính để bàn tùy chỉnh, thì thực tế sẽ thực tế hơn khi thực hiện các thử nghiệm trên các máy của các nhà phát triển khác nhau. Trong trường hợp của chúng tôi, chúng tôi phân phối sản phẩm cho một máy có thông số cụ thể và chúng tôi chỉ thực hiện các thử nghiệm hiệu suất này trên máy đó. Thật vậy, không có nhiều điểm trong việc đo hiệu năng trên máy phát triển lõi kép của bạn, khi máy khách cuối cùng sẽ chạy 16 lõi trở lên.

• TDD: Mặc dù thất bại ban đầu là điển hình, nhưng đó không phải là điều bắt buộc. Trong thực tế, việc viết các bài kiểm tra này sớm làm cho nó phục vụ nhiều hơn như một bài kiểm tra hồi quy hơn là một bài kiểm tra đơn vị truyền thống. Rằng thử nghiệm thành công sớm là không có vấn đề. Nhưng bạn có lợi thế, rằng bất cứ khi nào nhà phát triển thêm chức năng làm chậm mọi thứ, bởi vì họ không nhận thức được yêu cầu hiệu năng phi chức năng, thử nghiệm TDD này sẽ phát hiện ra nó. Xảy ra rất nhiều, và đó là phản hồi tuyệt vời. Hãy tưởng tượng rằng trong công việc hàng ngày của bạn: bạn viết mã, bạn cam kết, bạn đi ăn trưa và khi bạn quay lại, hệ thống xây dựng sẽ cho bạn biết mã này khi được thực thi trong môi trường tải nặng quá chậm. Điều đó đủ tốt để tôi chấp nhận, rằng thử nghiệm TDD ban đầu không thất bại.

• Thời gian chạy: Như đã đề cập, chúng tôi không chạy các thử nghiệm này trên các máy của nhà phát triển, mà là một phần của hệ thống xây dựng trong một loại thử nghiệm tích hợp.

Tôi chủ yếu là nội tuyến với suy nghĩ của bạn. Chỉ cần đưa ra lý luận của tôi với dòng chảy độc lập.

1. Làm cho nó hoạt động trước khi làm cho nó tốt hơn / nhanh hơn
Trước khi mã cung cấp bất kỳ thước đo hiệu suất nào (huống chi là đảm bảo) trước tiên nó phải được thực hiện chính xác, tức là làm cho nó hoạt động chức năng. Tối ưu hóa mã sai chức năng không chỉ lãng phí thời gian, mà còn gây trở ngại trong quá trình phát triển.

2. Hiệu suất của một hệ thống chỉ có ý nghĩa trên toàn bộ hệ thống
Thông thường, mọi hiệu suất có ý nghĩa luôn phụ thuộc vào một cơ sở hạ tầng nhất định và nó chỉ nên được nhìn thấy trong một hệ thống đầy đủ. Ví dụ: trong quá trình kiểm tra giả nếu mô-đun nhận được câu trả lời từ tệp văn bản cục bộ nhưng trong môi trường sản xuất, nó sẽ tìm nạp từ cơ sở dữ liệu, trước đó của bạn

3. Việc mở rộng hiệu suất nên được thực hiện theo mục tiêu
Một khi bạn có hệ thống chức năng, bạn cần phân tích hiệu suất của hệ thống và tìm ra các nút thắt để hiểu nơi bạn cần mở rộng hiệu suất. Cố gắng tối ưu hóa mọi phương thức ngay cả trước khi bạn biết hiệu năng của một hệ thống đầy đủ có thể phải chịu một lượng công việc vô ích (tối ưu hóa các phương pháp không quan trọng) và có thể tạo mã của bạn một cách không cần thiết.

Tôi không bỏ qua chức năng Visual studio, nhưng nhìn chung bạn cần công cụ định hình rộng hơn.

Tôi đã có nhiệm vụ tương tự một thời gian trước đây và giải pháp cuối cùng nằm ở đâu đó giữa thử nghiệm đơn vị và thử nghiệm hiệu suất tự động toàn diện.

Một số cân nhắc không theo thứ tự cụ thể, có thể hữu ích:

• Kiểm tra hiệu suất của QA rất tốn công và có lịch trình riêng (giả sử, một lần trong vòng lặp), do đó, việc kiểm soát nguồn không phải là vấn đề.
• Hệ thống của chúng tôi lớn và mô-đun, các bài kiểm tra đơn vị quá chi tiết cho nhu cầu của chúng tôi và chúng tôi đã tạo ra các bài kiểm tra đơn vị "béo" đặc biệt được chế tạo cẩn thận để gây ra các vấn đề về hiệu suất trong các lĩnh vực cụ thể (chúng cũng được phân loại, nhưng đây là một chi tiết thực hiện).
• Các ràng buộc thông thường cho các bài kiểm tra đơn vị vẫn được áp dụng: chúng phải nhỏ, nhanh và đúng điểm.
• Để loại trừ ảnh hưởng của khung kiểm tra, chúng được chạy bởi một trình bao bọc đặc biệt, vì vậy chúng tôi biết chính xác thời gian của thao tác đã cho.
• Có thể viết chúng trước khi thực hiện hoàn tất (kết quả có thể không liên quan hoặc hữu ích, tùy thuộc vào quá trình, có thể các nhà phát triển vẫn đang thử nghiệm triển khai và muốn xem nó sẽ diễn ra như thế nào).
• Họ đã được chạy bởi máy chủ CI sau mỗi xây dựng, vì vậy tổng thời gian chạy nên được giữ tương đối ngắn (nếu không phải như vậy, việc xác định thay đổi chính xác đã gây ra sự cố) trở nên khó khăn hơn đáng kể.
• Máy chủ CI rất mạnh và đã sửa lỗi phần cứng, vì vậy chúng tôi đã tính đây là máy chuyên dụng (có thể sử dụng máy chủ thực sự chuyên dụng bằng cách sử dụng tác nhân xây dựng từ xa).
• Trình bao bọc kiểm tra đã thu thập tất cả thông tin liên quan (thông số kỹ thuật phần cứng, tên / danh mục kiểm tra, tải hệ thống, thời gian trôi qua, v.v.) và xuất nó dưới dạng báo cáo hoặc vào cơ sở dữ liệu.
• Chúng tôi đã có một tiện ích cho JIRA lấy các báo cáo đó và vẽ các biểu đồ đẹp theo tên / danh mục / số bản dựng với một số điều khiển (lớp phủ phát hành trước đó cho hiện tại, v.v.), vì vậy các nhà phát triển có thể nhanh chóng thấy tác động của họ và người quản lý có thể có được cái nhìn tổng quan (một số màu đỏ, tất cả màu xanh lá cây, bạn biết đấy, nó quan trọng đối với họ).
• Có thể phân tích dự án đang diễn ra theo thời gian bằng cách sử dụng số liệu thống kê thu thập được.

Vì vậy, cuối cùng, chúng tôi đã có hệ thống có thể mở rộng, linh hoạt và có thể dự đoán được, chúng tôi có thể nhanh chóng điều chỉnh các yêu cầu đặc biệt của mình. Nhưng nó đòi hỏi một số nỗ lực để thực hiện.

Trở lại câu hỏi. Các bài kiểm tra đơn vị về mặt khái niệm không dành cho điều đó, nhưng bạn có thể tận dụng các tính năng của khung kiểm tra của mình. Tôi chưa bao giờ coi thời gian chờ kiểm tra là một phương tiện để đo lường, nó chỉ là một mạng lưới an toàn để treo và những thứ như vậy. Nhưng nếu cách tiếp cận hiện tại của bạn có hiệu quả với bạn, thì hãy tiếp tục sử dụng nó, hãy thực tế. Bạn luôn có thể đi ưa thích sau này nếu có nhu cầu.

Tôi nghĩ rằng bạn đang làm tốt. Đây chính xác là điểm có thời gian chờ kiểm tra đơn vị: để kiểm tra xem có thứ gì đang diễn ra hay không , lâu hơn mức cần thiết. Có những hạn chế đối với phương pháp này, nhưng dường như bạn đã nhận thức được chúng, vì vậy miễn là bạn giữ những hạn chế đó trong tâm trí, tôi không thấy có vấn đề gì.