Longevity Testing là gì?

Longevity Testing là gì? Tại sao phải Longevity Testing? Lập kế hoạch và Thực hiện các Longevity Testing Những thuận và chống của Longevity Testing là gì?

Longevity Testing là gì?

Để kiểm tra các tính năng ổn định và tính khả dụng của hệ thống hoặc sản phẩm trong một khoảng thời gian dài hơn so với tải trọng và tình trạng căng thẳng phù hợp với lưu lượng truy cập thời gian thực và các ứng dụng Để giảm sự xuất hiện của các defect bề mặt tại trang web Khách hàng Sơ đồ luồng xử lý Các vấn đề được báo cáo của Khách hàng (Hình 1)

Nền tảng để Longevity Testing

1. Thông thường, trong vài tuần đầu tiên triển khai Sản phẩm hoặc sau khi nâng cấp lên phiên bản Phần mềm mới nhất tại trang khách hàng, mọi thứ đều chạy tốt. Tuy nhiên, trong một khoảng thời gian vài tuần, một khách hàng bắt đầu báo cáo các vấn đề.

2. Nhiều vấn đề có thể là các tính năng đơn giản vì chúng được báo cáo bởi khách hàng và không dễ reproducible . Họ cần rất nhiều thời gian và phân tích cẩn thận bởi Expert Team qua spec.

3. Một hoặc nhiều điều sau xảy ra khi khách hàng tìm thấy defect (Hình 1)

   • Mức độ nghiêm trọng của defect sẽ có ảnh hưởng trực tiếp đến hoạt động kinh doanh của Khách hàng như $$
   • Bất kỳ yêu cầu dịch vụ nào đến Trung tâm Hỗ trợ Kỹ thuật có giá $$ cho Tổ chức Sản xuất Kỹ thuật
   • Rất hiếm khi các vấn đề được đưa ra bởi khách hàng được giải quyết bởi đội hỗ trợ kỹ thuật phía trước
   • Yêu cầu hoặc vé như vậy được gửi đến Nhóm hỗ trợ nâng cấp
   • Khách hàng đặt cọc vé sẽ tốn thêm tiền cho Tổ chức
   • Nếu nhóm Escalation không thể giải quyết được vấn đề, bây giờ nó sẽ phải liên quan đến Nhóm Kỹ thuật (phát triển và QA)
   • Bây giờ chi phí tiền để giải quyết vấn đề cũng sẽ tăng lên đáng kể
   • Độ phân giải defect càng cao thì xác suất của khách hàng không hài lòng sẽ không đưa ra lệnh lặp lại và kịch bản tồi tệ nhất là khi khách hàng quyết định chuyển sang giải pháp của đối thủ cạnh tranh vào một thời điểm thích hợp. Tuy nhiên, trong cả hai trường hợp đó là một khoản thu nhập thua lỗ cho bất kỳ Tổ chức Sản xuất Kỹ thuật

4. Phần trăm cao hơn của các vấn đề được báo cáo bởi (các) khách hàng liên quan đến sự ổn định Hệ thống hoặc Sản phẩm điển hình kết hợp với topo khách hàng, cơ sở hạ tầng, giao thông và ứng dụng cụ thể.

Tại sao phải Longevity Testing?

1. Bất kỳ 'lỗi' nào phát sinh từ Khách hàng báo cáo vấn đề thường là Test Escape.

2. Bất kỳ khiếm khuyết như vậy chi phí cho Khách hàng cũng như Tổ chức Kỹ thuật cung cấp các giải pháp và dịch vụ cho khách hàng.

3. Trong một tình huống thông thường, lỗi phải được nhận thấy bên trong các chu kỳ thử nghiệm khác nhau bao gồm Kiểm tra hồi quy bởi một hoặc nhiều người kiểm tra từ Nhóm kiểm tra tùy thuộc vào sự phức tạp của vấn đề.

4. Quan trọng nhất, các defect phát sinh từ các vấn đề được báo cáo của khách hàng cũng chỉ ra một kịch bản thử nghiệm thích hợp hoặc một trường hợp thử nghiệm bị bỏ lỡ tại thời điểm thực hiện Kế hoạch Kiểm tra.

5. Nhiều người trong số các Người kiểm tra phải có kinh nghiệm rằng một tính năng đặc biệt là không ở vị trí của khách hàng nhưng đi qua trong nhà trong Testbeds khác nhau như

   • Feature
   • Regression
   • Load
   • Stress
   • Performance
   • System
   • Solution
   • Alpha
   • Beta

6. Những quan sát chính cần được xem xét -

   • Trong bất kỳ chu kỳ phát hành phần mềm nào, Thử nghiệm Hệ thống (SUT) hoặc Thiết bị Thử nghiệm (DUT) trong tất cả các Bài kiểm tra thường được khởi động lại mềm hoặc cứng vì muốn có những thứ như tải mã giảm mới, xác minh lỗi vv

   • Ngay cả các bộ kiểm tra hồi quy tự động thường khởi động lại hoặc đặt lại SUT hoặc DUT post thực thi một kịch bản lệnh thử nghiệm cụ thể hoặc một loạt các kịch bản trường hợp thử nghiệm

   • Vì vậy, SUT hoặc DUT không chạy đủ lâu mà không có một khởi động lại mềm hoặc cứng

   • Trong khi tình hình hoàn toàn khác biệt tại địa điểm khách hàng. Khách hàng không thể tiếp tục khởi động lại Hệ thống thường xuyên do đó dẫn đến sự gián đoạn năng suất

   • Khách hàng tuân theo thực tiễn đã được chứng minh, nơi họ thông báo một cửa sổ bảo dưỡng phù hợp cho đối tượng dự định và sau đó thực hiện nâng cấp Phần mềm hoặc Thay thế phần cứng vv

   • Các cửa sổ bảo trì như vậy có thể được thực hiện trong khoảng thời gian cụ thể từ hàng quý đến hàng năm tùy theo hướng dẫn và quy trình nội bộ của Tổ chức của Khách hàng

   • Trên thực tế, bức tranh về sức khoẻ thực tế của Hệ thống hoặc Sản phẩm tại địa điểm của khách hàng hoàn toàn khác với Testbeds trong suốt chu kỳ Phát hành Phần mềm cho bất kỳ Tổ chức Kỹ thuật Sản phẩm nào

   • Nhiều khách hàng cũng tìm kiếm một tài liệu có chất lượng được ủy quyền đã vượt qua thử nghiệm mô hình Dọc cụ thể đặc biệt là Tài chính, Chăm sóc sức khoẻ và Liên bang Dọc Xem xét vài khoảng trống thử như đã đề cập ở trên =>

   • Rõ ràng là Hệ thống hoặc Sản phẩm phải trải qua thời gian thử nghiệm dài hơn hoặc Longevity Testing với mô hình hoá hoặc kết thúc của khách hàng hoặc mô hình Ngắn hàng

   • Thời gian dài hơn có thể là 72-720 giờ. (3-30 ngày) hoặc thời gian thích hợp dựa trên dữ liệu EFD hoặc CFD và các trường hợp khách hàng cụ thể

   • Đó là một thực hành được đề nghị cho Quản lý đảm bảo chất lượng, Leads và Testers là thực hiện Longevity Testing là một hoạt động riêng biệt trong một chu kỳ Phát hành Phần mềm nhất định

   • Net-Net, Longevity Testing rất phù hợp với sự ổn định của Hệ thống hoặc Sản phẩm vì nó có quan hệ trực tiếp với dòng tiền cuối cùng của Tổ chức

Lập kế hoạch và Thực hiện các Longevity Testing

Điều quan trọng là Quản lý, Lãnh đạo và Kiểm tra chất lượng bao gồm Longevity Testing là một phần của Chiến lược Thử nghiệm chung của họ .

Lập kế hoạch

• Các tổ chức kỹ thuật thực hiện việc phân tích Thử nghiệm Thách đấu ( TEA ) trong nhà theo từng thời gian cho nhiều Sản phẩm (Phần cứng và Phần mềm). Một số thậm chí còn có một cơ chế tự động và tích hợp để khai thác dữ liệu Kiểm tra Thoát thường dựa trên 'Lỗi đã Tìm ra bên ngoài ( EFD )' hoặc 'Khách hàng Đã Tìm Hiểu ( CFD )' đã được đăng nhập bởi Nhóm Hỗ trợ Mở rộng
• EFDs hoặc CFDs cần được phân tích cẩn thận trong bối cảnh triển khai Live của khách hàng từ quan điểm cuối đến đầu cuối, không chỉ cho cơ sở hạ tầng mà còn các thiết bị, ứng dụng,

Hiểu Kiến thức của Khách hàng:

• Chăm sóc sức khỏe
• Bán lẻ
• Tài chính
• Giáo dục
• Vận chuyển
• Chế tạo
• Kỹ thuật
• Liên bang (Govt)

Hoạt động

1. Xây dựng Kế hoạch kiểm tra riêng biệt và Thử nghiệm để Longevity Testing. Điều này cũng sẽ giúp theo dõi quá trình thực hiện kiểm tra, khai thác lỗi, và xác minh

2. Xác định các trường hợp thử nghiệm dựa trên đầu vào Phân tích Kiểm tra Thoát - thường là các lỗi của EFDs hoặc CFDs

3. Điều rất quan trọng là nhóm kiểm định chất lượng bắt chước thử nghiệm giường của một hoặc nhiều ngành dọc tùy thuộc vào ngành kinh doanh của tổ chức với số ngành dọc

4. Test Bed(s) dành riêng cần có

• Cấu trúc liên kết mạng tương tự như cấu trúc dọc hoặc nhiều chiều dọc
• Cơ sở hạ tầng có các thiết bị chuyển mạch tương tự, bộ định tuyến, máy chủ back-end, tường lửa vv
• Các máy chủ ứng dụng thường xuyên và phổ biến nhất từ ​​(các)
• Hầu hết thường xuyên và phổ biến sử dụng tiện ích người dùng cuối từ (các)

1. Các công cụ thích hợp để tạo ra tải, căng thẳng và giao thông thời gian thực

2. Xác định tài nguyên thực hiện thủ công

3. Xác định tài nguyên / chiến lược Tự động hóa để thực hiện nhanh hơn và lặp đi lặp lại

4. Xác định START và END của Longevity Testing cho một bản phát hành nhất định

Hai phương pháp tiếp cận START và END của Longevity Testing: I) Cách tiếp cận 1:

Mã Phần mềm hoặc Phần cứng phải ở trong tình trạng ổn định START vào cuối FEATURE hoàn thành kiểm tra END trước khi Code Freeze II) Cách tiếp cận 2:

Thực hiện một lần nhấn nhỏ bằng cách cho phép mã hơi không ổn định START khi hoàn thành 70% chu kỳ kiểm tra FEATURE END trước khi Code Freeze 9) Xác minh lỗi cho các lỗi đã được giải quyết

1. Di chuyển Longevity Testing để hồi quy để kiểm tra hồi quy tiếp theo

Chấp hành

• Thiết lập Testbed để bắt chước một hoặc nhiều Dọc của Khách Hàng
• Đảm bảo rằng tất cả các Infra, ứng dụng và cơ sở dữ liệu back-end bao gồm hương vị tương tự như của khách hàng
• Đảm bảo rằng các thiết bị của người dùng cuối tương tự như sử dụng của khách hàng có sẵn và được sử dụng trong quá trình thực hiện Kế hoạch Kiểm tra
• Đảm bảo rằng các công cụ thích hợp có sẵn để tạo mức độ căng thẳng vừa phải của hệ thống hoặc sản phẩm
• Thực hiện toàn bộ bộ kiểm tra từ Kế hoạch kiểm định Tuổi thọ mà không có khởi động lại mềm hoặc cứng của SUT hoặc DUT, các máy chủ back-end khác liên quan đến thiết bị Infra
• Nhiều lần chạy các bài kiểm tra nên được chạy theo cách trên cho một khoảng thời gian không hạn định từ khe 72-720 giờ.
• Ghi lại kết quả
• Đăng nhập tất cả các lỗi được xác định
• Xác minh tất cả các lỗi

Ưu và khuyết điểm của Longevity Testing là gì?

Ưu điểm

• Giúp xác định các lỗi chính yếu trước khi khách hàng tìm thấy nó
• Giúp ổn định hệ thống hoặc sản phẩm cho tính năng có thể sử dụng được của nó có ý nghĩa quan trọng đối với năng suất và kinh doanh của Khách hàng
• Giúp nâng cao sự hài lòng của khách hàng
• Tiết kiệm rất nhiều chi phí cho Tổ chức - tiền tiết kiệm được tiền kiếm được!

Nhược điểm

• Chi phí ban đầu cho Bao gồm Longevity Testing và các hoạt động liên quan của nó như là một phần của một hoạt động đưa ra và Hoạt động hồi quy
• Phù hợp với mô hình thác nước
• Mô hình Agile / Scrum cần phải điều chỉnh thời gian và vùng phủ sóng

Phần kết luận

Nhiều lỗi phát sinh từ các sự cố Khách hàng được báo cáo chủ yếu là do Test Escape. Điều này, lần lượt, begs cho rất nhiều câu hỏi như phát triển kế hoạch kiểm tra, xem xét, bảo hiểm và thực hiện.

Các defect đã được tìm thấy bên ngoài (EFD) hoặc các lỗi do khách hàng tìm thấy (CFD) có tác động kinh doanhđối với khách hàng cũng như cho Tổ chức sản phẩm.

Longevity Testing là duy nhất, nên giúp bất kỳ Tổ chức Sản phẩm nào để cải thiện Sự hài lòng của Khách hàng bằng cách xác định và giải quyết các khiếm khuyết trước khi khách hàng bắt họ. Longevity Testing cũng giúp cải thiện tính ổn định dẫn đến Hệ thống hoặc Sản phẩm chất lượng cao.

Tham khảo tại nguồn: http://www.softwaretestinghelp.com/longevity-testing/