Site icon Nhạc lý căn bản – nhacly.com

Phân biệt Performance Testing, Load Testing và Stress Testing | Anh Tester

Trong hướng dẫn này, tất cả chúng ta sẽ đàm đạo về từng loại test này để hiểu sự độc lạ đúng chuẩn giữa chúng .Trong nghành nghề dịch vụ kiểm thử ứng dụng, tất cả chúng ta phát hiện những thuật ngữ như Performance Testing, Load Testing và Stress Testing, … Những thuật ngữ này thường bị hiểu nhầm và diễn giải là những khái niệm tựa như nhau. Tuy nhiên, có một sự độc lạ đáng kể giữa ba loại test này và đó là điều quan trọng cho một tester để hiểu được sự độc lạ đó .Chủ đề của bài viết là sự độc lạ giữa Performance Testing, Load Testing và Stress Testing với những ví dụ đi kèm. Nếu bạn muốn tìm hiểu và khám phá sâu hơn về riêng Performance Testing, bạn hoàn toàn có thể tìm hiểu thêm thêm chuỗi bài viết ở đường link sau đây .

1. Performance Testing

1.1. Performance Testing là gì

Test hiệu năng là bài test được thực hiện để xác định các thành phần của hệ thống đang hoạt động như thế nào trong một tình huống nhất định.

Việc sử dụng tài nguyên, năng lực lan rộng ra và độ đáng tin cậy của loại sản phẩm cũng được xác nhận theo bài test này. Bài test này là tập hợp con của kỹ thuật kiểm tra hiệu năng, tập trung chuyên sâu vào xử lý những yếu tố hiệu năng trong phong cách thiết kế và kiến trúc của một loại sản phẩm ứng dụng .

Phân biệt Performance Testing, Load Testing và Stress Testing | Anh Tester

Hình bên trên lý giải rõ ràng cho tất cả chúng ta rằng test hiệu năng ( Performance Testing ) là là một khái niệm lớn và gồm có cả Load Testing và Stress Testing. Các loại test khác có trong test hiệu năng là Spike testing, Volume testing, Endurance testing, và Scalability testing. Vì vậy, kiểm tra hiệu năng về cơ bản là một thuật ngữ rất rộng .

1.2. Mục đích của Performance Testing

Mục tiêu chính của test hiệu năng gồm có thiết lập hành vi chuẩn ( benchmark behavior ) của mạng lưới hệ thống. Có 1 số ít điểm chuẩn được đã được định nghĩa sẵn cần được cung ứng trong quy trình kiểm tra hiệu năng .
Kiểm tra hiệu năng không nhằm mục đích mục tiêu tìm ra lỗi trong ứng dụng. Nó cũng không có khái niệm như đã vượt qua hoặc đã bị lỗi khi chạy bài test. Thay vào đó, nó xử lý trách nhiệm quan trọng là thiết lập điểm chuẩn ( benchmark ) và tiêu chuẩn ( standard ) cho một ứng dụng. Kiểm tra hiệu năng nên được triển khai rất đúng mực. Giám sát ngặt nghèo hiệu năng của ứng dụng / mạng lưới hệ thống là đặc thù chính của kiểm tra hiệu năng .
Điểm chuẩn và tiêu chuẩn của ứng dụng nên được đặt theo những thuộc tính như vận tốc, thời hạn phản hồi, thông lượng, sử dụng tài nguyên và độ không thay đổi. Tất cả những thuộc tính này được kiểm tra trong một bài kiểm tra hiệu năng .

1.3. Ví dụ về Performance Testing

Chẳng hạn, bạn hoàn toàn có thể kiểm tra hiệu năng mạng của ứng dụng trải qua biểu đồ Tốc độ liên kết so với độ trễ. Độ trễ là chênh lệch thời hạn giữa tài liệu cần tiếp cận từ nguồn đến đích. Một trang 70 kb sẽ không mất quá 15 giây để tải trong trường hợp liên kết tồi tệ nhất của modem 28,8 kbps ( độ trễ là 1000 mili giây ), trong khi trang có cùng size sẽ Open trong vòng 5 giây cho liên kết trung bình 256 kbps DSL ( độ trễ là 100 mili giây ). Một liên kết T1 1,5 mbps ( độ trễ là 50 mili giây ) sẽ có điểm chuẩn hiệu năng là 1 giây để đạt được tiềm năng này .
Một ví dụ khác là quy mô Yêu cầu – Phản hồi. Chúng ta hoàn toàn có thể đặt điểm chuẩn là chênh lệch thời hạn giữa việc tạo nhu yếu và xác nhận phản hồi phải nằm trong khoanh vùng phạm vi x ms ( mili giây ) và y ms, trong đó x và y là những chữ số tiêu chuẩn .
Một bài test hiệu suất thành công xuất sắc nên dự kiến hầu hết những yếu tố về hiệu năng, hoàn toàn có thể tương quan đến cơ sở tài liệu, mạng, ứng dụng, phần cứng, …


2. Load Testing

2.1. Load Testing là gì

Load Testing là kiểm tra mạng lưới hệ thống bằng cách tăng tải liên tục và đều đặn cho mạng lưới hệ thống cho đến khi đạt đến số lượng giới hạn ngưỡng. Nó là một tập hợp con của test hiệu năng .
Kiểm tra tải hoàn toàn có thể thuận tiện triển khai bằng cách sử dụng bất kỳ công cụ tự động hóa tương thích nào có sẵn trên thị trường. WAPT và LoadRunner là hai công cụ nổi tiếng tương hỗ kiểm tra tải. Load Testing cũng nổi tiếng bởi những tên như : Kiểm tra khối lượng và kiểm tra độ bền .
Tuy nhiên, kiểm tra khối lượng hầu hết tập trung chuyên sâu vào cơ sở tài liệu. Trong khi đó, kiểm tra độ bền triển khai kiểm tra mạng lưới hệ thống bằng cách giữ nó dưới một tải trọng đáng kể trong một khoảng chừng thời hạn duy trì .
Mục đích duy nhất của kiểm tra tải ( Load Testing ) là gán cho mạng lưới hệ thống việc làm lớn nhất mà nó hoàn toàn có thể giải quyết và xử lý để kiểm tra độ bền của mạng lưới hệ thống và theo dõi tác dụng. Một thực tiễn mê hoặc ở đây là đôi lúc mạng lưới hệ thống được cung ứng một tác vụ trống để xác lập hành vi của mạng lưới hệ thống trong trường hợp không tải .
Các thuộc tính được theo dõi trong kiểm tra tải gồm có hiệu suất cao nhất, thông lượng sever, thời hạn phân phối dưới những mức tải khác nhau ( dưới ngưỡng ngắt ), tính thỏa đáng của thiên nhiên và môi trường H / W, có bao nhiêu ứng dụng người dùng hoàn toàn có thể giải quyết và xử lý mà không ảnh hưởng tác động đến hiệu suất .

2.2. Mục đích của Load Testing

Các tiềm năng của kiểm tra tải gồm có :

  • Phơi bày các khiếm khuyết của một ứng dụng liên quan đến lỗi tràn bộ đệm, rò rỉ bộ nhớ và quản lý sai bộ nhớ. Các vấn đề cuối cùng sẽ xuất hiện do thử nghiệm tải có thể bao gồm các vấn đề cân bằng tải, vấn đề băng thông, công suất của hệ thống hiện tại, …
  • Để xác định giới hạn trên của tất cả các thành phần của ứng dụng như cơ sở dữ liệu, phần cứng, mạng, … để ứng dụng có thể quản lý tải được dự đoán trong tương lai.
  • Để đặt SLA cho ứng dụng.

2.3. Ví dụ về Load Testing

Chúng ta hãy xem xét việc kiểm tra tính năng email của một ứng dụng, hoàn toàn có thể bị tràn ngập với 1000 người dùng cùng một lúc. Hiện nay, 1000 người dùng hoàn toàn có thể kích hoạt những thanh toán giao dịch email ( đọc, gửi, xóa, chuyển tiếp, vấn đáp ) theo nhiều cách khác nhau .
Nếu tất cả chúng ta triển khai một thanh toán giao dịch cho mỗi người dùng mỗi giờ, thì đó sẽ là 1000 thanh toán giao dịch mỗi giờ. Bằng cách mô phỏng 10 thanh toán giao dịch / người dùng, tất cả chúng ta hoàn toàn có thể tải thử nghiệm sever email bằng cách chiếm 10000 thanh toán giao dịch / giờ .
Một ví dụ khác về kiểm tra tải được hiển thị trong hình dưới đây :

Hình trên miêu tả một bài kiểm tra tải được thực thi trong công cụ có tên là JMeter. Bài test này được triển khai để xác lập có bao nhiêu người dùng mà một mạng lưới hệ thống hoàn toàn có thể giải quyết và xử lý. Trong thử nghiệm này, 100 người dùng được thêm sau mỗi 30 giây cho đến khi tải đạt 1000 người dùng. Mỗi bước mất 30 giây để hoàn thành xong và JMeter đợi trong 30 giây trước khi khởi đầu bước tiếp theo .
Khi tải đạt 1000 luồng, toàn bộ chúng sẽ liên tục chạy trong 300 giây ( 5 phút ) cùng nhau và ở đầu cuối dừng 10 luồng sau mỗi 3 giây .


3. Stress Testing

3.1. Stress Testing là gì

Dưới Stress Testing, những hoạt động giải trí khác nhau để làm quá tải những tài nguyên hiện có với những việc làm dư thừa khác nhau sẽ được thực thi trong nỗ lực phá vỡ mạng lưới hệ thống. Thử nghiệm xấu đi ( negative testing ), gồm có vô hiệu những thành phần khỏi mạng lưới hệ thống cũng được thực thi như một phần của Stress Testing .
Stress Testing còn được gọi là kiểm tra độ mỏi ( fatigue testing ), bài test này sẽ chớp lấy được tính không thay đổi của ứng dụng bằng cách kiểm tra nó vượt quá năng lực băng thông của nó .
Do đó, về cơ bản, Stress Testing nhìn nhận hành vi của một ứng dụng vượt quá tải tối đa và những điều kiện kèm theo thông thường .

Mục đích của Stress Testing là để xác định sự thất bại của hệ thống và theo dõi cách hệ thống phục hồi. Thách thức ở đây là thiết lập một môi trường được kiểm soát trước khi khởi chạy bài test để chúng ta có thể nắm bắt chính xác hành vi của hệ thống nhiều lần trong các tình huống khó lường nhất.

Các yếu tố sau cuối Open do Stress Testing hoàn toàn có thể gồm có những yếu tố đồng nhất hóa, rò rỉ bộ nhớ, …
Nếu Stress Testing kiểm tra cách mạng lưới hệ thống giải quyết và xử lý trong trường hợp tăng bất thần số lượng người dùng, sau đó nó được gọi là bài kiểm tra việc tăng đột biến .
Nếu Stress Testing là để kiểm tra tính vững chắc của mạng lưới hệ thống trong một khoảng chừng thời hạn trải qua việc tăng số lượng người dùng một những chậm rãi, thì nó được gọi là bài test ngâm .

3.2. Mục đích của Stress Testing

Mục tiêu của Stress Testing là nghiên cứu và phân tích những báo cáo giải trình sau sự cố để xác lập hành vi của ứng dụng sau thất bại .
Thách thức lớn nhất là bảo vệ để mạng lưới hệ thống không bị ảnh hưởng tác động đến bảo đảm an toàn của những tài liệu nhạy cảm sau sự cố. Trong một bài stress testing thành công xuất sắc, mạng lưới hệ thống sẽ trở lại trạng thái thông thường cùng với toàn bộ những thành phần của nó ngay cả sau sự cố nghiêm trọng nhất .

3.3. Ví dụ về Stress Testing

Ví dụ, một trình giải quyết và xử lý văn bản như Writer 1.1.0 của OpenOffice. org được sử dụng để tăng trưởng những vần âm, bản trình diễn, bảng tính, … Mục đích của việc stress test của tất cả chúng ta là tải nó với những ký tự thừa. Để làm điều này, chúng tôi sẽ liên tục paste ( dán ) một dòng tài liệu, cho đến khi nó đạt đến số lượng giới hạn ngưỡng của nó để giải quyết và xử lý một khối lượng lớn văn bản. Ngay khi size ký tự đạt 65.535 ký tự, đơn thuần là nó sẽ khước từ gật đầu nhiều tài liệu hơn .
Kết quả kiểm tra căng thẳng mệt mỏi trên Writer 1.1.0 tạo ra tác dụng rằng nó không bị sập dưới ứng suất và nó giải quyết và xử lý trường hợp một cách nhẹ nhàng, bảo vệ rằng ứng dụng hoạt động giải trí đúng chuẩn ngay cả trong những điều kiện kèm theo stress khắt khe .
Một ví dụ khác về stress test miêu tả bài test tăng đột biến trải qua việc tăng bất thần 7000 người dùng được hiển thị bên dưới :


4. Câu hỏi thường gặp

Đã có nhiều những cuộc bàn luận về Performance Testing, Stress Testing và Load Testing, giờ đây tất cả chúng ta hãy xem xét một số ít câu hỏi thường gặp tương quan mà một tester luôn tìm kiếm câu vấn đáp .

Câu hỏi #1) Kiểm tra tải và kiểm tra hiệu năng có giống nhau không?

Trả lời: Câu trả lời cho điều này là “Không”. Chúng không giống nhau.

Đến giờ đây bạn phải hiểu rõ sự độc lạ giữa kiểm tra hiệu năng và kiểm tra tải. Bạn hoàn toàn có thể tìm hiểu thêm tóm tắt dạng bảng ở bên dưới đây để xem cách kiểm tra hiệu năng và tải có những tiềm năng, thuộc tính khoanh vùng phạm vi khác nhau để nghiên cứu và điều tra và những yếu tố cần tò mò .

Câu hỏi #2) Đây có phải là một bài test không hợp lý khi thực hiện Stress Testing cùng lúc khi bạn thực hiện Load Testing không?

Trả lời: Đây cũng là một câu hỏi phổ biến trong nhiều cuộc phỏng vấn test phần mềm và kiểm tra chứng chỉ vì có không hợp lý khi thực hiện kiểm tra căng thẳng và kiểm tra tải một cách song song hay không? Câu trả lời cho điều này là “Không”. Không phải là không hợp lý khi thực hiện stress testing cùng một lúc khi bạn đang thực hiện kiểm tra tải.

Không có bài kiểm tra nào là thừa. Là một tester, việc làm của bạn là tìm ra những yếu tố. Tuy nhiên, thực tiễn của việc test ứng dụng hoàn toàn có thể được vận dụng và mọi yếu tố mà bạn phát hiện trong trường hợp này hoàn toàn có thể không được khắc phục .

Câu hỏi #3) Kiểm tra phục hồi (Recovery Testing) có phải là một phần của kiểm tra hiệu năng (Performance Testing) không?

Trả lời: Có, kiểm tra phục hồi được phân loại theo kiểm tra hiệu năng và đôi khi nó cũng được tiến hành với kiểm tra tải (Load Testing). Trong bài test khôi phục, nó đánh giá một ứng dụng có khả năng phục hồi tốt như thế nào từ các lỗi, sự cố, lỗi phần cứng và các vấn đề tương tự khác.

Trong hoạt động giải trí này, ứng dụng buộc phải thất bại và sau đó nó được xác định nếu nó hoàn toàn có thể hồi sinh đúng cách hay không. Ví dụ, khởi động lại mạng lưới hệ thống bất ngờ đột ngột khi một ứng dụng đang chạy và sau đó xác định tính toàn vẹn tài liệu của ứng dụng .

Câu hỏi #4) Kiểm tra hiệu năng có yêu cầu có kiến thức lập trình không?

Trả lời: Kiểm thử hiệu năng không yêu cầu bạn phải có kiến thức lập trình ở mức cao. Tuy nhiên, có kiến ​​thức cơ bản về lập trình là một lợi thế bổ sung.

Ví dụ, nếu bạn đang sử dụng JMeter, thì tốt nhất là bạn nên biết những nguyên tắc cơ bản của Java. Nó hoàn toàn có thể giúp bạn gỡ lỗi một số ít thứ và bạn cũng hoàn toàn có thể viết ngữ cảnh của riêng mình nếu cần .

Câu hỏi #5) Bài test tăng đột biến (Spike Testing) trong bài test hiệu năng là gì?

Trả lời: Trong thử nghiệm tăng đột biến (Spike Testing), tải bị tăng hoặc giảm đột ngột bởi một số lượng lớn người dùng và sau đó hành vi hệ thống được quan sát. Spike Testing chủ yếu được thực hiện để kiểm tra xem hệ thống có thể xử lý các thay đổi đột ngột về tải không.


5. Sự khác biệt giữa Performance Testing, Load Testing và Stress Testing

Tóm tắt lại, tất cả chúng ta hãy cùng xem sự độc lạ chính giữa kiểm tra tải ( Load Testing ), kiểm tra stress, sức chịu ( Stress Testing ) cũng như kiểm tra hiệu năng ( Performance Testing ) trong bảng dưới đây :

  Performance Testing Load testing Stress Testing
Miền Bao hàm của Load testing và Stress testing Nằm trong performance testing Nằm trong performance testing
Phạm vi Phạm vi rất rộng. Bao gồm – Kiểm tra tải, Kiểm tra căng thẳng, kiểm tra năng lực, kiểm tra khối lượng, kiểm tra độ bền, kiểm tra tăng đột biến, kiểm tra khả năng mở rộng và kiểm tra độ tin cậy, … Phạm vi hẹp hơn so với thử nghiệm hiệu năng. Bao gồm kiểm tra khối lượng và kiểm tra độ bền. Phạm vi hẹp hơn so với thử nghiệm hiệu năng. Bao gồm kiểm tra ngâm và kiểm tra tăng đột biến.
Mục đích chính Để thiết lập điểm chuẩn và tiêu chuẩn cho ứng dụng. Để xác định giới hạn trên của hệ thống, hãy đặt SLA của ứng dụng và xem cách hệ thống xử lý khối lượng tải nặng. Để xác định cách hệ thống hoạt động dưới tải trọng lớn và cách nó phục hồi từ thất bại. Về cơ bản, để chuẩn bị ứng dụng của bạn cho lưu lượng truy cập tăng đột biến.
Giới hạn tải Cả hai – cả ngưỡng dưới và trên ngưỡng nghỉ ngơi.ngưỡng trên của điểm break. Từ dưới đến điểm break. Trên điểm break.
Những thuộc tính được thực thi Sử dụng tài nguyên, độ tin cậy, khả năng mở rộng, thời gian đáp ứng, thông lượng, tốc độ, … Hiệu suất cao nhất, thông lượng máy chủ, thời gian đáp ứng dưới các mức tải khác nhau (dưới ngưỡng ngắt), tính thỏa đáng của môi trường H/W, số lượng ứng dụng người dùng có thể xử lý, yêu cầu cân bằng tải, … Tính ổn định vượt quá dung lượng băng thông, thời gian đáp ứng (trên ngưỡng ngắt), …
Những vấn đề được chỉ ra sau bài test này Tất cả các lỗi về hiệu năng bao gồm thời gian chạy, phạm vi để tối ưu hóa, các vấn đề liên quan đến tốc độ, độ trễ, thông lượng, … Về cơ bản – mọi thứ liên quan đến hiệu năng! Vấn đề cân bằng tải, vấn đề băng thông, vấn đề dung lượng hệ thống, thời gian đáp ứng kém, vấn đề thông lượng, … Các lỗ hổng bảo mật với tình trạng quá tải, vấn đề dò ghỉ dữ liệu ở tình trạng quá tải, chậm, rò rỉ bộ nhớ, …


6. Sự khác biệt giữa Load Testing, Stress Testing và Volume Testing

Đến giờ đây chúng tôi đã biết về load testing và stress testing cùng với sự độc lạ giữa hai loại test này. Bây giờ tất cả chúng ta hãy mày mò volume testing là gì và nó khác với load testing và stress testing như thế nào. Kiểm tra khối lượng ( volume testing ) cũng là một loại kiểm tra hiệu năng tập trung chuyên sâu đa phần vào cơ sở tài liệu .

Trong kiểm tra khối lượng, nó kiểm tra xem hệ thống hoạt động như thế nào đối với một khối lượng dữ liệu nhất định. Do đó, các cơ sở dữ liệu được nhồi với dung lượng tối đa và mức hiệu suất của chúng như thời gian đáp ứng và thông lượng máy chủ được theo dõi.

Để cho đơn thuần, sự độc lạ giữa kiểm tra tải, căng thẳng mệt mỏi và khối lượng được hiển thị dưới đây :

Volume testing Load testing Stress testing
Một khối lượng lớn của dữ liệu. Một số lượng lớn của người dùng. Quá nhiều dữ liệu, quá nhiều người dùng dẫn đến hệ thống quá tải.


7. Kết luận

Trong hướng dẫn này, tất cả chúng ta đã thấy và hiểu trải qua những ví dụ về cách kiểm tra hiệu năng, kiểm tra tải và kiểm tra căng thẳng mệt mỏi khác nhau như thế nào và khoanh vùng phạm vi của từng loại test là gì .
Chúng ta cũng đã có một cái nhìn ngắn gọn về nhiều hạng mục của kiểm tra hiệu năng như kiểm tra tăng đột biến, kiểm tra Phục hồi, kiểm tra khối lượng, … và hiểu mỗi loại này khác nhau như thế nào .

Tài liệu tham khảo

Exit mobile version