Theo dõi hiệu suất của các ứng dụng WebRTC của bạn có thể cải thiện đáng kể trải nghiệm người dùng của bạn

Điều cuối cùng mà một doanh nghiệp muốn được biết đến là một dịch vụ không đáng tin cậy và hoạt động kém, đặc biệt nếu có các giải pháp tương tự cách đó vài cú nhấp chuột. Vì vậy, cần phải biết về hiệu suất của ứng dụng WebRTC hoặc bất kỳ giải pháp phần mềm nào khác để tránh các sự cố trong tương lai. Một giải pháp có thể được phát triển bởi những người có kinh nghiệm và được thử nghiệm trước khi phát hành, nhưng ngay cả như vậy không có nghĩa là sự suy giảm hiệu suất sẽ không bao giờ xuất hiện. Nhận thấy các vấn đề sớm và thực hiện hành động phù hợp có thể giúp ích rất nhiều để người dùng có trải nghiệm tốt hơn.

Hãy tưởng tượng rằng ứng dụng gọi video của bạn gặp sự cố khi xảy ra mất gói . Mất gói có thể khiến âm thanh bị rè, video bị đơ hoặc thiếu khung hình video, khiến người dùng khó hiểu những gì đang được nói hoặc nhìn thấy những gì đang diễn ra trong cuộc gọi. Mất gói dữ liệu cao cũng có thể khiến ứng dụng khó thiết lập và duy trì kết nối, dẫn đến cuộc gọi hoặc cuộc trò chuyện video bị gián đoạn. Nếu bạn và nhóm của bạn không gặp phải tình trạng mất gói trong khi phát triển ứng dụng, thì có một cách để bạn có thể phát hiện ra vấn đề – một khách hàng thất vọng có thể thông báo cho bạn về trải nghiệm khó chịu của họ. Tất nhiên, sẽ tốt hơn rất nhiều nếu tìm hiểu về vấn đề và khắc phục nó trước khi người dùng gặp phải.

Đây là lý do tại sao giám sát là một phương pháp hữu ích – thường xuyên quan sát hiệu suất và hành vi của sản phẩm theo thời gian cho phép bạn phản ứng nhanh với mọi vấn đề phát sinh và duy trì dịch vụ đáng tin cậy và hiệu suất cao. Điều này không chỉ cải thiện trải nghiệm người dùng, dẫn đến tăng sự hài lòng và lòng trung thành của khách hàng mà còn mang lại cho doanh nghiệp của bạn lợi thế cạnh tranh trên thị trường.

Lợi ích từ việc giám sát ứng dụng thường xuyên:

• Nhận thông báo về các vấn đề sớm. Bằng cách thiết lập thông báo lỗi giám sát và thử nghiệm, bạn sẽ được cảnh báo về các sự cố trong thời gian thực và có thể thực hiện hành động kịp thời trước khi người dùng có trải nghiệm kém.
• Giám sát cung cấp các báo cáo chi tiết có thể giúp bạn xác định nguyên nhân gốc rễ của lỗi và xác định chính xác các khu vực trong ứng dụng của bạn cần cải thiện.
• Tiết kiệm rất nhiều thời gian. Quá trình giám sát là một quy trình tự động, có nghĩa là bạn có thể tạo giải pháp một lần và chỉ cần để giải pháp đó hoạt động mà không cần bảo trì.
• Tự tin rằng giải pháp của bạn hoạt động tốt. Khi có sẵn tính năng giám sát, bạn có thể yên tâm rằng ứng dụng của mình đang được kiểm tra thường xuyên và hoạt động tốt nếu gần đây bạn không nhận được bất kỳ thông báo nào.
• Khả năng so sánh hiệu suất theo thời gian. Khi thiết lập giám sát của bạn thường xuyên chạy các thử nghiệm giống nhau và thực hiện các phép đo, sau đó bạn có thể tổng hợp dữ liệu và xem hiệu suất thay đổi như thế nào theo thời gian.

Cách giám sát ứng dụng WebRTC hoạt động với Loadero

Loadero là một công cụ kiểm tra hiệu suất và tải có khả năng mô phỏng hành vi và tương tác của người dùng thực với các trang web bằng cách sử dụng các công nghệ tự động hóa web, chẳng hạn như “Javascript + Nightwatch”, “Java + TestUI” hoặc “Python + Py-TestUI”. Cùng với đó, nó cung cấp cho bạn tất cả WebRTC cần thiết và các số liệu thống kê về máy như FPS, tốc độ bit, jitter, thời gian khứ hồi và những thứ khác, được thu thập trong quá trình chạy thử nghiệm và có khả năng xác nhận chúng.

Vì việc giám sát đòi hỏi phải quan sát liên tục, ví dụ: chạy thử nghiệm liên tục trong trường hợp của chúng tôi, chúng tôi cũng cần kích hoạt chạy thử nghiệm định kỳ. Vì mục đích đó, đường dẫn CI/CD là một lựa chọn tuyệt vời vì nó linh hoạt và không phức tạp để định cấu hình cho nhiệm vụ của chúng tôi. Bên cạnh việc chạy thử nghiệm định kỳ, quy trình cũng có thể được sử dụng để tự động hóa thử nghiệm sau mỗi lần triển khai nhằm đảm bảo hiệu suất hoạt động tốt.

Để bắt đầu theo dõi giải pháp WebRTC của bạn với Loadero, cần có một thiết lập bao gồm 3 phần:

1. Thử nghiệm Loadero sẽ đánh giá hiệu suất của ứng dụng WebRTC của bạn. Bạn có thể tìm thấy một ví dụ ở đây .
2. Tập lệnh sử dụng API Loadero để khởi chạy thử nghiệm, nhận kết quả và thông báo về lỗi.
3. Một đường dẫn CI/CD để tự động chạy tập lệnh.

Thiết lập thử nghiệm cho thiết lập giám sát

Hãy bắt đầu bằng cách thiết lập kiểm tra Loadero cho ví dụ thiết lập giám sát của chúng tôi. Nếu bạn đã có thử nghiệm trong Loadero, thử nghiệm này có thể được khởi chạy để kiểm tra một số chỉ số hiệu suất, bạn có thể bỏ qua phần này và chuyển sang phần khởi chạy thử nghiệm thông qua quy trình. Nếu đây là lần đầu tiên bạn làm thử nghiệm trong Loadero, bạn có thể tìm thấy hướng dẫn từng bước đầy đủ về cách tạo thử nghiệm trong Loadero trong bài đăng trên blog này . Nếu bạn đã có kiểm tra hiệu suất WebRTC trong một dịch vụ khác, hãy xem cách bạn có thể di chuyển kiểm tra của mình sang Loadero tại đây . Trong trường hợp của chúng tôi, chúng tôi sẽ có bài kiểm tra “Javascript + Nightwatch”. Kịch bản của nó sẽ là một cuộc gọi trực tiếp kéo dài một phút ở Jitsi .

Trong thử nghiệm, hai người tham gia sẽ tham gia một cuộc gọi và ở trong đó trong một phút, chụp một vài ảnh chụp màn hình giữa chừng để xác minh kết nối bổ sung.

Những người tham gia sẽ kết nối từ Oregon của Hoa Kỳ, sẽ sử dụng phiên bản Google Chrome mới nhất (109v khi viết blog này) và sẽ sử dụng video + âm thanh mặc định để mô phỏng tín hiệu đầu ra.

Chúng tôi cũng sẽ sử dụng các xác nhận sau khi chạy của Loadero. Chúng cho phép bạn chỉ định tiêu chí "đạt" cho WebRTC và/hoặc chỉ số máy trong thử nghiệm của bạn, chẳng hạn như "nếu FPS trung bình ≥ 10 thì đạt". Sau khi quá trình chạy hoàn tất, kết quả xác nhận được tính toán tự động cho từng người tham gia để kiểm tra xem các giá trị đã cho có đáp ứng tiêu chí vượt qua hay không. Nếu xác nhận không thành công đối với người tham gia, thì trạng thái của người tham gia này trong báo cáo kết quả cũng sẽ là "Không đạt".

Với các xác nhận, chúng tôi sẽ đánh giá tốc độ bit và gói đến và đi cho cả âm thanh và video cũng như FPS.

Cấu hình thử nghiệm của chúng tôi sẽ giống như thế này:

• Chế độ kiểm tra: 'Kiểm tra hiệu suất'
• Chiến lược gia tăng: 'Người tham gia tuyến tính'
• Khoảng thời gian bắt đầu: 1 giây
• Thời gian chờ của người tham gia: 5 phút

Trong ví dụ này, chúng tôi có tập lệnh kiểm tra Loadero được viết bằng Javascript + Nightwatch, nhưng điều tương tự cũng có thể được thực hiện với Java + TestUI hoặc Python + Py-TestUI.

 client => { client // Open the page .url(`https://meet.jit.si/LoaderoTests`) // Wait until the username field is visible // And enter the username .waitForElementVisible('[placeholder]', 30 * 1000) .sendKeys('[placeholder]', 'User') // Wait until the "Join" button is visible // And join the call by pressing the button .waitForElementVisible('[aria-label="Join meeting"]', 10 * 1000) .click('[aria-label="Join meeting"]') // Another thing you can do is to take screenshots during the test // Which could help you to identify the cause of a failure // And give visual feeback about the test run .takeScreenshot('pre_call_screenshot.png') // Stay in the call for half a minute .pause(30 * 1000) // Take a mid-call screenshot .takeScreenshot('mid_call_screenshot.png') // Stay in the call for another half a minute .pause(30 * 1000) // Take a post-call screenshot .takeScreenshot('post_call_screenshot.png'); }

Đặt kỳ vọng về hiệu suất WebRTC

Mỗi ứng dụng WebRTC là khác nhau và sẽ có hiệu suất hơi khác nhau. Ở đây, chúng tôi nhằm mục đích xác định các ngưỡng mà chúng tôi muốn được thông báo ngay lập tức nếu các kỳ vọng về hiệu suất không được đáp ứng, ngay cả khi điều đó xảy ra vào ban đêm. Để làm điều này, chúng tôi sẽ sử dụng một tập hợp các xác nhận sau khi chạy của Loadero cho các chỉ số WebRTC, điều này sẽ khiến toàn bộ quá trình chạy thử nghiệm không thành công nếu các giá trị chỉ số hiệu suất WebRTC không tốt như chúng tôi muốn. Do đó, các giá trị mục tiêu không nên được đặt ở biên độ hẹp, nhưng chúng ta nên cho phép các thử nghiệm đôi khi kém hơn một chút so với mong muốn lý tưởng của chúng ta, nhưng vẫn ở mức hiệu suất hợp lý. Các giá trị chúng tôi đã đặt ở đây là các ví dụ và bạn có thể muốn điều chỉnh chúng dựa trên các chi tiết cụ thể của ứng dụng (ví dụ: nếu bạn ưu tiên tốc độ khung hình cao hơn băng thông mạng, bạn có thể muốn tăng tốc độ khung hình tối thiểu mà bạn muốn xem và giảm giới hạn tốc độ bit). Để bắt đầu, bạn có thể sử dụng danh sách xác nhận từ bên dưới:

Dưới đây là danh sách các xác nhận và giá trị của chúng mà chúng tôi đặt cho thử nghiệm mẫu này:

• Khẳng định rằng video có ít nhất 10 khung hình mỗi giây trong hơn 75% thời lượng cuộc gọi ở cả luồng video đến và đi. Ngoài ra, hãy kiểm tra xem các biến động về tốc độ khung hình có nhỏ không, không quá 2 khung hình mỗi giây, bằng cách đặt xác nhận về độ lệch chuẩn:

  • webrtc/video/fps/out/25th >= 10

  • webrtc/video/fps/in/25th >= 10

  • webrtc/video/fps/out/stddev < 2

  • webrtc/video/fps/in/stddev < 2

    
    

• Việc kiểm tra giá trị của các gói được gửi mỗi giây là rất quan trọng để đảm bảo rằng hiệu suất là tối ưu. Gửi quá nhiều gói mỗi giây sẽ gây ra nhiều chi phí hoạt động hơn, nhưng bằng cách gửi nhiều gói hơn, jitter có thể thấp hơn do độ trễ giữa các gói nhỏ hơn. Một sự cân bằng tốt phải được tìm thấy và nó có thể khác nhau giữa các ứng dụng. Trong ví dụ này, chúng tôi sẽ kiểm tra xem các gói được gửi trên mỗi giây có nằm trong khoảng từ 40 đến 100 hay không:

  • webrtc/audio/packets/out/avg > 40/sec

  • webrtc/video/packets/out/avg > 100/sec

  • webrtc/audio/packets/in/avg > 40/sec

  • webrtc/video/packets/in/avg > 100/sec

    
    

• Tốc độ bit cho biết lượng dữ liệu được gửi mỗi giây. Nói chung, phương tiện truyền thông chất lượng cao hơn được gửi, tốc độ bit càng cao. Tuy nhiên, một số ứng dụng sẽ cố gắng giảm thiểu tốc độ bit để hoạt động tốt hơn trên các mạng kém và tiêu thụ ít dữ liệu hơn. Với những xác nhận này, chúng tôi kiểm tra xem mức tiêu thụ dữ liệu không vượt quá giá trị đã đặt là 25 kbit/giây đối với âm thanh đến và đi và 1000 kbit/giây đối với video đến và đi trong 95% thời lượng thử nghiệm:
  • webrtc/audio/bitrate/out/95th <= 25 kbit/sec
  • webrtc/video/bitrate/out/95th <= 1000 kbit/sec
  • webrtc/audio/bitrate/in/95th <= 25 kbit/sec
  • webrtc/video/bitrate/in/95th <= 1000 kbit/sec

Định cấu hình người tham gia thử nghiệm và chạy thử nghiệm

Cuối cùng, chúng ta phải cấu hình những người tham gia thử nghiệm. Chúng tôi sẽ có 1 nhóm người tham gia sẽ có 2 người tham gia có cùng cấu hình sẽ tham gia cuộc gọi. Thiết lập của người tham gia như sau:

• Tiêu đề – 'Người tham gia'
• Đếm – 2
• Đơn vị tính toán: G2
• Trình duyệt – 'Google Chrome mới nhất'
• Vị trí – 'Miền Tây Hoa Kỳ – Oregon'
• Mạng – 'Cài đặt mạng mặc định'
• Nguồn cấp dữ liệu âm thanh – 'Nguồn cấp dữ liệu âm thanh mặc định'
• Nguồn cấp dữ liệu video – 'Nguồn cấp dữ liệu video mặc định'

Mẹo: nếu bạn muốn có nhiều người tham gia có cùng cấu hình, thì trong menu cấu hình, hãy tăng giá trị Count . Để tiết kiệm thời gian của bạn, chúng tôi khuyên bạn chỉ nên tạo riêng từng người tham gia trong trường hợp họ cần có các cấu hình khác nhau.

Đối với cấu hình thử nghiệm sẽ là như vậy. Tuy nhiên, vì chúng tôi dự định chạy thử nghiệm thường xuyên, nên trước khi chúng tôi tiến hành định cấu hình thiết lập giám sát của mình, hãy chạy thử nghiệm và xác minh rằng tập lệnh không bị lỗi bằng cách kiểm tra nhật ký Selenium và ảnh chụp màn hình mà người tham gia đã chụp trong quá trình chạy thử nghiệm. Nếu đây là lần đầu tiên bạn khởi chạy thử nghiệm trong Loadero hoặc bạn không chắc liệu nó có được định cấu hình đúng hay không, hãy sử dụng bài đăng trên blog này để kiểm tra xem thử nghiệm của bạn đã sẵn sàng để khởi chạy chưa .

Như đã đề cập trước đây, người tham gia vẫn có thể thất bại nếu xác nhận số liệu WebRTC không thành công và tỷ lệ thành công có thể không phải là 100%. Điều này cũng xảy ra với thử nghiệm của chúng tôi.

Điều này không nhất thiết có nghĩa là thử nghiệm bị lỗi, mà chỉ là ứng dụng không đáp ứng các tiêu chí xác nhận mà bạn đã đặt. Nhưng nếu bài kiểm tra của bạn không thành công do một lý do khác, không phải do các xác nhận đã đặt, thì bài đăng trên blog này sẽ giải thích một số cách để gỡ lỗi bài kiểm tra của bạn.

Các xác nhận mà chúng tôi đặt chỉ là cơ sở chung không phù hợp với ứng dụng mà chúng tôi kiểm tra. Bạn có thể sử dụng danh sách và bắt đầu với những giá trị đó, nhưng ứng dụng mà bạn thử nghiệm có thể khác và kết quả chỉ số cũng có thể rất khác.

Mẹo: Một cách hay để thiết lập các xác nhận của riêng bạn là thực hiện 5 lần chạy thử, xem xét các chỉ số của người tham gia và đánh giá các mục tiêu hợp lý.

Đặt các xác nhận đó và phân tích kết quả để tìm hiểu lý do tại sao các xác nhận không thành công là một nhiệm vụ phức tạp, vì vậy chúng tôi sẽ không đi sâu vào chi tiết về vấn đề này trong bài đăng trên blog này. Ngoài ra, thực tế là thử nghiệm mẫu của chúng tôi không thành công do xác nhận không thành công mô phỏng chính xác trường hợp chúng tôi cần, khi thử nghiệm không thành công và thông báo về lỗi được gửi, vì vậy chúng tôi sẽ để nguyên như vậy. Nếu nhật ký Selenium cho thấy bạn không gặp phải bất kỳ lỗi nào và ảnh chụp màn hình xác nhận rằng tất cả các hành động cần thiết đã được thực hiện, thì quá trình thử nghiệm vẫn tốt.

Khởi chạy thử nghiệm thường xuyên từ đường ống

Nhóm của chúng tôi đã chuẩn bị một số bài đăng trên blog về cách tích hợp các thử nghiệm trong quy trình phát triển của bạn: sử dụng ứng dụng khách Python của JS và Loadero. Vì vậy, ở đây chúng tôi sẽ dựa vào họ. Đối với thiết lập của chúng tôi, chúng tôi sẽ sử dụng những gì được đề xuất trong bài đăng trên blog sử dụng Python, GitHub và triển khai CI/CD của nó – Quy trình công việc cùng với ứng dụng khách Loadero Python.

Lưu ý: một số thông tin có thể bị bỏ qua. Để biết hướng dẫn chuyên sâu, hãy tham khảo bài đăng trên blog gốc của Loadero Python .

Đối với quy trình làm việc của chúng tôi, chúng tôi sẽ cần:

• Kho lưu trữ GitHub
• Tệp YAML xác định quy trình làm việc
• Tập lệnh Python để chạy thử nghiệm Loadero và báo cáo kết quả

Tạo kho lưu trữ mới trên GitHub hoặc sử dụng kho lưu trữ hiện có.

Trong kho lưu trữ của bạn trong thư mục .github/workflows hãy tạo tệp notify-on-fail.yml . Đây là tệp sẽ chứa các hướng dẫn về cách thiết lập môi trường và khởi chạy thử nghiệm Loadero.

Hãy bắt đầu xác định quy trình công việc bằng cách chỉ định trình kích hoạt trong notify-on-fail.yml .

 on: schedule: - cron: '0 9-18 * * *' workflow_dispatch:

schedule cho phép bạn kích hoạt quy trình làm việc tại thời điểm đã lên lịch. Do đó, đây là nơi bạn xác định tần suất chạy thử nghiệm. Trong ví dụ của chúng tôi, chúng tôi đã đặt lịch chạy thử nghiệm mỗi giờ từ 9 giờ sáng đến 6 giờ chiều, vì đó là thời điểm nhóm có nhiều khả năng phản ứng với thất bại nhất. Trong trường hợp bạn có thể cần chạy thử nghiệm trong suốt chu kỳ ngày đêm, bạn có thể muốn chạy chúng sau mỗi 4 giờ hoặc lâu hơn. Do đó, bạn giám sát ứng dụng ngay cả khi không có ai thức. Hãy chú ý, schedule đó sử dụng một cú pháp cụ thể mà bạn có thể tìm hiểu thêm tại đây .

Mẹo : Khi đặt tần suất kiểm tra, hãy lưu ý rằng khoảng thời gian giữa các lần chạy kiểm tra phải dài hơn thời lượng kiểm tra, vì các lần kiểm tra của bạn có thể ảnh hưởng lẫn nhau.

Trình kích hoạt thứ hai – workflow_dispatch – cho phép kích hoạt quy trình theo cách thủ công thông qua ứng dụng web GitHub nếu cần.

Trong phần jobs của tập lệnh, chúng tôi chỉ định môi trường và tất cả các phụ thuộc mà chúng tôi sẽ sử dụng. Đối với mục đích của chúng tôi, cấu hình từ bài đăng trên blog Loadero Python hoàn toàn phù hợp, vì vậy đừng ngần ngại sao chép-dán nó.

 jobs: notify-on-fail: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 with: python-version: "3.10" - run: pip install loadero-python - run: python run.py env: LOADERO_ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }} LOADERO_PROJECT_ID: ${{ secrets.PROJECT_ID }} LOADERO_TEST_ID: ${{ secrets.TEST_ID }}

Quan trọng: hãy chú ý rằng trong dòng - run: python run.py , sau python, chúng tôi có đường dẫn đến tệp run.py của bạn so với thư mục gốc của kho lưu trữ. Trong trường hợp của tôi, cấu trúc tệp sẽ trông như thế này:

Một điều khác cần chú ý là thông tin xác thực. Đầu tiên, bạn có thể tìm ID thử nghiệm và ID dự án trong Loadero, nhưng bạn cũng sẽ cần mã thông báo truy cập API dự án – hiện tại, mã thông báo truy cập dự án có được bằng cách yêu cầu chúng từ nhóm hỗ trợ của chúng tôi. Thứ hai, thông tin đăng nhập được sử dụng làm bí mật của GitHub Actions. Điều này giữ mã thông báo truy cập Loadero của bạn ở chế độ riêng tư. Bí mật có thể được định cấu hình trong cài đặt kho lưu trữ -> Bảo mật -> Bí mật và biến -> Hành động -> Bí mật kho lưu trữ mới.

Để biết hướng dẫn từng bước chi tiết về các bí mật, hãy tham khảo bài đăng trên blog đã đề cập trước đó.

Vì vậy, cấu hình quy trình làm việc bây giờ sẽ giống như thế này:

 name: Notify about failing tests in Loadero on: schedule: - cron: '0 9-18 * * *' workflow_dispatch: jobs: notify-on-fail: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 with: python-version: "3.10" - run: pip install loadero-python - run: python run.py env: LOADERO_ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }} LOADERO_PROJECT_ID: ${{ secrets.PROJECT_ID }} LOADERO_TEST_ID: ${{ secrets.TEST_ID }}

Bây giờ, hãy thêm tập lệnh Python để tương tác với Loadero vào thiết lập của chúng ta. Một lần nữa, tập lệnh từ blog Loadero Python là một điểm khởi đầu tuyệt vời, vì vậy chúng tôi sẽ sử dụng nó và sửa đổi nó sau này cho phù hợp với nhu cầu của chúng tôi.

 import os from loadero_python.api_client import APIClient from loadero_python.resources.test import Test project_id = os.environ.get("LOADERO_PROJECT_ID", None) access_token = os.environ.get("LOADERO_ACCESS_TOKEN", None) test_id = os.environ.get("LOADERO_TEST_ID", None) if project_id is None or access_token is None or test_id is None: raise Exception( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) APIClient( project_id=project_id, access_token=access_token, ) run = Test(test_id=test_id).launch().poll() print(run) for result in run.results()[0]: print(result) if run.params.success_rate != 1: raise Exception("Test failed")

Gửi thông báo về các bài kiểm tra không thành công

Bây giờ là lúc sửa đổi tập lệnh Python của chúng tôi để triển khai các thông báo của chúng tôi. Trong ví dụ này, cảnh báo sẽ được gửi đến kênh Discord. Mặc dù cách bạn thực hiện các thông báo là hoàn toàn không bắt buộc, vì nó phụ thuộc vào sở thích cá nhân của bạn.

Hãy cập nhật tệp Python của chúng ta bằng cách nhập thư viện yêu cầu, các lớp ResultStatus và AssertStatus .

 import requests import os from loadero_python.api_client import APIClient from loadero_python.resources.test import Test from loadero_python.resources.classificator import ResultStatus, AssertStatus

Cũng như cập nhật tệp YAML của chúng tôi để cài đặt thư viện yêu cầu.

 - run: pip install loadero-python - run: pip install requests - run: python run.py

Trong trường hợp đường dẫn bị định cấu hình sai và giá trị của bất kỳ thông tin đăng nhập nào là Không, chúng ta nên thông báo cho kênh Discord của mình về điều đó bằng cách gửi yêu cầu POST kèm theo thông báo lỗi.

 missing_credentials_message = ( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) def send_notification(message): requests.post( "https://discordapp.com/api/webhooks/{id}", data={"content": message}, ) if project_id is None or access_token is None or test_id is None: send_notification(missing_credentials_message) raise Exception(missing_credentials_message)

Nếu thử nghiệm thất bại, chúng tôi muốn biết lý do. Ở đây chúng tôi thêm xác minh của người tham gia. Nếu một người tham gia không thành công, chúng tôi sẽ gửi thông báo lỗi với cấu trúc sau:

• Tên của người tham gia
• kết quả selen
• Trạng thái
• Đường dẫn xác nhận không thành công
• trạng thái chạy

Ngoài ra, chúng ta nên loại bỏ ngoại lệ mà tập lệnh ban đầu có, vì ở đây quá nhiều

 run_failure_message = "" for result in run.results()[0]: result.params.run_id = run.params.run_id result.read() if ( result.params.selenium_result.value != ResultStatus.RS_PASS or result.params.status.value != ResultStatus.RS_PASS ): run_failure_message += ( f"{result.params.participant_details.participant_name}:\n" f"-Selenium result: {result.params.selenium_result.value}\n" f"-Participant status: {result.params.status.value}\n" ) if result.params.asserts: run_failure_message += "-Failing asserts:\n" for assertion in result.params.asserts: if assertion.status != AssertStatus.AS_PASS: run_failure_message += f"--{assertion.path.value}\n" run_failure_message += "\n" run_failure_message += f"Run status: {run.params.status.value}" if run.params.success_rate != 1: send_notification(run_failure_message)

Và cũng hãy gửi một tin nhắn cho việc chạy thử thành công:

 if run.params.success_rate != 1: send_notification(run_failure_message) else: send_notification(f"The {run.params.test_name} test has been finished successfully")

Là bước xác minh cuối cùng, chúng ta nên đưa toàn bộ lệnh gọi API vào try-except trường hợp kết nối với API Loadero bị lỗi. Tập lệnh python cuối cùng trông như thế này:

 import os import requests from loadero_python.api_client import APIClient from loadero_python.resources.test import Test from loadero_python.resources.classificator import ResultStatus, AssertStatus project_id = os.environ.get("LOADERO_PROJECT_ID", None) access_token = os.environ.get("LOADERO_ACCESS_TOKEN", None) test_id = os.environ.get("LOADERO_TEST_ID", None) missing_credentials_message = ( "Please set the " "LOADERO_PROJECT_ID and LOADERO_ACCESS_TOKEN AND LOADERO_TEST_ID " "environment variables." ) def send_notification(message): requests.post( "https://discordapp.com/api/webhooks/{id}", data={"content": message}, ) if project_id is None or access_token is None or test_id is None: send_notification(missing_credentials_message) raise Exception(missing_credentials_message) try: APIClient( project_id=project_id, access_token=access_token, ) run = Test(test_id=test_id).launch().poll() print(run) run_failure_message = "" for result in run.results()[0]: result.params.run_id = run.params.run_id result.read() if ( result.params.selenium_result.value != ResultStatus.RS_PASS or result.params.status.value != ResultStatus.RS_PASS ): run_failure_message += ( f"{result.params.participant_details.participant_name}:\n" f"-Selenium result: {result.params.selenium_result.value}\n" f"-Participant status: {result.params.status.value}\n" ) if result.params.asserts: run_failure_message += "-Failing asserts:\n" for assertion in result.params.asserts: if assertion.status != AssertStatus.AS_PASS: run_failure_message += f"--{assertion.path.value}\n" run_failure_message += "\n" run_failure_message += f"Run status: {run.params.status.value}" if run.params.success_rate != 1: send_notification(run_failure_message) else: send_notification( f"The {run.params.test_name} test has been finished successfully" ) except Exception as err: send_notification(f"Error while running Loadero test: {err}")

Kiểm tra kết quả giám sát WebRTC

Giờ đây, thử nghiệm của chúng tôi tự động chạy mỗi giờ từ 9 giờ sáng đến 6 giờ chiều và đánh giá xem ứng dụng có hoạt động như mong đợi hay không.

Sau khi thực hiện kiểm tra kết thúc, trong trường hợp kiểm tra không thành công, bạn sẽ nhận được thông báo về lỗi.

Trong trường hợp của chúng tôi, thử nghiệm Jitsi không thành công do FPS và các gói không đáp ứng tiêu chí của chúng tôi, có thể thấy điều này trong tab Khẳng định của kết quả thử nghiệm. Kết quả xác nhận cũng có thể truy cập được đối với từng người tham gia riêng lẻ, vì vậy bạn có thể xác minh xem sự cố đã xảy ra với tất cả những người tham gia hay chỉ một phần trong số họ.

Các giá trị được cung cấp ở trên cho các xác nhận có thể đóng vai trò là tham chiếu ban đầu và có vẻ như trong trường hợp của chúng tôi, chúng không phù hợp với hiệu suất mục tiêu của Jitsi. Vì vậy, đừng ngần ngại khám phá cách ứng dụng của bạn hoạt động và xác nhận nào phù hợp nhất với ứng dụng của bạn, để đảm bảo rằng quy trình giám sát là tối ưu.

Lưu ý: chỉ bằng cách xem xét các xác nhận của bài kiểm tra, chúng tôi có thể lưu ý rằng có toàn bộ các phần cho kết quả bằng 0 trong suốt quá trình chạy kiểm tra, điều này cuối cùng sẽ ảnh hưởng đến kết quả kiểm tra.

Mẹo: Nếu thử nghiệm của bạn không thành công, bạn có thể điều hướng đến tab thống kê WebRTC, nơi bạn có thể tìm thấy các biểu đồ khác nhau có dữ liệu và nhận thêm thông tin về chỉ số gây ra lỗi.

Trong bài đăng trên blog này, chúng tôi đã cung cấp một ví dụ về cách bạn có thể giám sát ứng dụng WebRTC của mình với sự hỗ trợ của quy trình công việc Loadero và GitHub. Với việc sử dụng giám sát, bạn được trang bị tốt hơn để xử lý mọi vấn đề có thể phát sinh trong ứng dụng của mình. Cũng có thể là khôn ngoan khi tạo các kịch bản khác với các điều kiện khác để có cái nhìn tổng thể hơn về hiệu suất của ứng dụng. Thiết lập giám sát như vậy có thể là một nhiệm vụ khá phức tạp. Bạn có muốn nhóm Loadero tạo một thiết lập giám sát tương tự cho bạn không? Vui lòng liên hệ với chúng tôi tại [email protected] và hãy thảo luận về cách chúng tôi có thể giúp bạn theo dõi thường xuyên và tự động giải pháp WebRTC của bạn.