CHƯƠNG 1: NHỮNG NGUYÊN TẮC CƠ BẢN CỦA WEB APPLICATION PERFORMANCE TESTING (PHẦN 2)

The Relationship Between Performance Testing and Tunning

Khi kiểm thử hiệu suất end-to-end cho thấy các chỉ số của hệ thống hoặc ứng dụng được coi là không thể chấp nhận, nhiều nhóm thay đổi hướng tập trung của họ từ các kiểm thử hiệu suất để điều chỉnh hiệu suất, khám phá những gì là cần thiết để làm cho các ứng dụng thực hiện có thể chấp nhận được. Một nhóm nghiên cứu cũng có thể thay đổi quan điểm của mình để điều chỉnh khi chỉ tiêu thực hiện đã được đáp ứng nhưng nhóm nghiên cứu muốn giảm số lượng tài nguyên được sử dụng để tăng nền tảng khoảng không, giảm âm lượng của phần cứng cần thiết, và / hoặc nâng cao hơn nữa hiệu suất hệ thống.

Cooperative Effort (Nỗ lực hợp tác)

Mặc dù điều chỉnh (tuning) không phải là trách nhiệm trực tiếp của hầu hết các kiểm thử hiệu suất, nhưng quá trình điều chỉnh đạt hiệu quả nhất khi nó là một nỗ lực hợp tác giữa tất cả những bên liên quan với các ứng dụng hoặc hệ thống kiểm thử, bao gồm:

• Các nhà cung cấp sản phẩm
• Nhân viên thiết kế thiết kế
• Nhân viên phát triển (developer)
• Nhân viên kiểm thử (tester)
• Quản trị cơ sở dữ liệu
• Quản trị hệ thống
• Quản trị mạng

Nếu như không có sự hợp tác phối hợp của một nhóm đa chức năng, điều đó gần như không thể đạt được các phối hợp cần thiết trên toàn bộ hệ thống để giải quyết vấn đề hiệu suất một cách hiệu quả hoặc hiệu quả.

Một cá nhân hay nhóm kiểm thử hiệu suất, là một thành phần quan trọng của tổ hợp tác này như là điều chỉnh thông thường đòi hỏi thêm sự kiểm soát của các thành phần, nguồn lực và thời gian đáp ứng theo một loạt các điều kiện tải trọng và cấu hình. Nói chung, nhân viên kiểm thử hiệu suất là người có các công cụ và chuyên môn để cung cấp thông tin này một cách hiệu quả, là người có khả năng tự điều chỉnh.

Tuning Process Overview (Tổng quan về quy trình điều chỉnh)

Điều chỉnh tuân theo một quá trình lặp đi lặp lại, nó thường được tách biệt, nhưng không độc lập, cách kiểm thử hiệu suất tiếp cận một dự án như sau. Sau đây là một tổng quan ngắn gọn của một quá trình điều chỉnh tiêu biểu:

• Các kiểm thử được tiến hành với các hệ thống hoặc ứng dụng đã được triển khai trong một môi trường thử nghiệm đã được xác định và kiểm soát theo thứ tự để đảm bảo rằng cấu hình và kết quả kiểm thử vào lúc bắt đầu của dự án kiểm thử được biết đến và tái sản xuất.
• Khi việc kiểm thử cho thấy răng chỉ số hiệu suất là không thể chấp nhận, thì kiểm thử hiệu suất và đội ngũ điều chỉnh sẽ tham gia vào chẩn đoán và giai đoạn khắc phục (điều chỉnh) mà sẽ phải yêu cầu thay đổi để được áp dụng cho các môi trường thử nghiệm và / hoặc các ứng dụng. Nó không phải là không phổ biến để có sự thay đổi tạm thời mà được cố tình thiết kế để mở rộng một vấn đề cho các mục đích chẩn đoán, hoặc thay đổi môi trường thử nghiệm để xem, nếu thay đổi đó dẫn đến hiệu suất tốt hơn.
• Việc thử nghiệm và điều chỉnh hợp tác nhóm thường được sử dụng đầy đủ và là kiểm soát duy nhất trong môi trường thử nghiệm để tối đa hóa hiệu quả của giai đoạn điều chỉnh.
• Các kiểm thử được thực hiện, hoặc thực hiện lại sau mỗi lần thay đổi về môi trường kiểm tra, tiếp theo là đo lường tác động của khắc phục hậu quả thay đổi.
• Quá trình điều chỉnh thường bao gồm một chuỗi thay đổi và kiểm tra nhanh. Quá trình này có thể mất nhiều thời gian hơn theo cấp số nhân nếu như sự hợp tác của một kiểm thử và nhóm điều chỉnh không phải là hoàn toàn có sẵn và dành toàn bộ sức lực khi ở một giai đoạn điều chỉnh.
• Khi một giai đoạn điều chỉnh là hoàn chỉnh, môi trường kiểm thử thường được thiết lập lại trạng thái ban đầu của nó, những thay đổi khắc phục hậu quả thành công được áp dụng một lần nữa, và bất kỳ thay đổi khắc phục hậu quả không thành công (cùng với thiết bị đo đạc và chẩn đoán thay đổi tạm thời) sẽ bị bỏ đi. Các kiểm thử hiệu suất nên được lặp đi lặp lại để chứng minh rằng những thay đổi chính xác đã được xác định. Đó cũng có thể là trường hợp môi trường kiểm thử tự thay đổi để phản ánh kỳ vọng mới như môi trường sản xuất theo yêu cầu tối thiểu. Điều này là thường hiếm xảy ra, nhưng đó là một kết quả tiềm năng của các nỗ lực điều chỉnh.

Performance, Load, and Stress Testing

Các kiểm thử hiệu suất thường được mô tả gắn liền với một trong ba loại sau:

• Performance testing Đây là loại kiểm thử xác định hoặc xác nhận các tốc độ, khả năng mở rộng, và / hoặc các đặc tính ổn định của hệ thống hoặc các ứng dụng đang kiểm thử. Hiệu suất là có liên quan với việc đạt được thời gian đáp ứng, thông qua, và mức độ tài nguyên sử dụng đáp ứng các mục tiêu hiệu suất cho các dự án hoặc sản phẩm. Trong hướng dẫn này, kiểm thử hiệu suất đại diện cho tất cả các tiểu thể loại kiểm thử liên quan khác.

• Load testing. Loại tiểu kiểm thử hiệu suất này tập trung vào việc xác định hoặc xác nhận đặc tính hiệu suất của hệ thống hoặc các ứng dụng đang kiểm thử khi chịu khối lượng công việc và số lượng tải được dự đoán trong các hoạt động sản xuất.

• Stress testing Loại tiểu kiểm thử hiệu suất này tập trung vào việc xác định hoặc xác nhận đặc tính hiệu suất của hệ thống hoặc các ứng dụng đang kiểm thử khi chịu điều kiện vượt ra ngoài những dự đoán trong các hoạt động sản xuất. Stress testing cũng có thể bao gồm các loại kiểm thử tập trung vào việc xác định hoặc xác nhận đặc tính hiệu suất của hệ thống hoặc các ứng dụng đang kiểm thử khi chịu điều kiện căng thẳng khác, chẳng hạn như bộ nhớ hạn chế, không đủ không gian đĩa hoặc máy chủ thất bại. Các kiểm thử được thiết kế để xác định rằng điều kiện nào thì một ứng dụng sẽ thất bại, làm thế nào nó sẽ thất bại, và những gì có thể được giám sát để cảnh báo về một thất bại sắp xảy ra.

Baselines

Tạo một baseline là quá trình chạy một loạt các thử nghiệm để thu thập dữ liệu, số liệu hiệu suất cho các mục đích đánh giá hiệu quả của việc thay đổi hiệu suất cải thiện tiếp theo cho hệ thống hoặc ứng dụng. Một khía cạnh quan trọng của một baseline là tất cả các chỉ tiêu và các tùy chọn cấu hình ngoại trừ những cái đặc biệt có thể biến động để so sánh còn lại đều phải bất biến. Mỗi một phần của hệ thống nếu như không phải cố tình biến động để so sánh với baseline đã được đổi, thì các baseline cơ bản không còn hợp lệ để so sánh.

Đối với các ứng dụng Web, bạn có thể sử dụng baseline để xác định hiệu suất được cải thiện hay suy giảm và tìm độ lệch qua các bản build và phiên bản khác nhau. Ví dụ, bạn có thể đo thời gian tải, số lượng các giao dịch xử lý trên một đơn vị thời gian, số lượng các trang web phục vụ trên một đơn vị thời gian, và tận dụng tài nguyên như bộ nhớ sử dụng và bộ vi xử lý. Một số cân nhắc về việc sử dụng baseline gồm có:

• Baseline có thể được tạo ra cho một hệ thống, thành phần, hoặc ứng dụng. Một baseline cũng có thể được tạo ra cho các lớp khác nhau của ứng dụng, bao gồm một cơ sở dữ liệu, các dịch vụ Web, và một số thứ tương tự như vậy.

• Một baseline có thể thiết lập các tiêu chí để so sánh, để theo dõi tối ưu hóa hoặc hồi quy trong tương lai. Điều quan trọng là để xác nhận rằng kết quả của baseline là lặp lại, bởi vì những sai sót đáng kể có thể xảy ra trên kết quả kiểm tra do đặc điểm môi trường và khối lượng công việc.

• Baseline có thể giúp xác định những thay đổi trong hoạt động. Baseline có thể giúp các nhóm sản phẩm xác định những thay đổi trong hoạt động phản ánh sự xuống cấp hoặc tối ưu hóa quá trình của vòng đời phát triển. Xác định những thay đổi so với trạng thái đã biết hoặc cấu hình thường làm cho việc giải quyết vấn đề hiệu suất trở nên đơn giản.

• Baseline nên có thể tái sử dụng. Baseline là có giá trị nhất nếu chúng được tạo ra bằng cách sử dụng một tập hợp kiểm thử hữu ích có thể tái sử dụng. Điều quan trọng như là các kiểm thử mô phỏng chính xác chỉ số khối lượng công việc lặp lại và thực hiện được.

• Baseline là các chỉ số. Kết quả của baseline có thể được khớp nối bằng cách sử dụng một tập hợp các chỉ số hoạt động quan trọng, bao gồm cả thời gian đáp ứng, khả năng xử lý, sử dụng bộ nhớ, dung lượng đĩa và băng thông mạng.

• Đường cơ sở đóng vai trò như một khung được chia sẽ để tham khảo. Chia sẽ các kết quả của baseline cho phép nhóm của bạn xây dựng một kho chung bao gồm các kiến thức thu được về các đặc tính hiệu suất của một ứng dụng hoặc thành phần.

• Baseline không nên khái quát quá. Nếu dự án của bạn đòi hỏi một tái cấu trúc lại các chức năng của ứng dụng, bạn cần phải thiết lập baseline để kiểm thử ứng dụng đó. Một baseline là 1 ứng dụng cụ thể và hữu dụng nhất để so sánh hiệu suất giữa các phiên bản khác nhau. Đôi khi, những phiên bản sau của một ứng dụng rất khác so với các baseline trước đó, mà không còn giá trị để so sánh.

• Biết hành vi của ứng. Đó là một ý tưởng tốt để đảm bảo rằng bạn hoàn toàn hiểu được hành vi của ứng dụng vào thời điểm baseline được tạo ra. Nếu không làm như vậy trước khi thực hiện thay đổi vào hệ thống với mục tiêu tối ưu hóa là thường phản tác dụng.

• Phát triển baseline. Vào những lúc bạn sẽ phải xác định lại baseline của bạn bởi vì các thay đổi đã được thực hiện từ thời điểm ban đầu đã bị chiếm

Benchmarking

Benchmarking (điểm chuẩn) là quá trình so sánh hiệu suất của hệ thống với một cơ sở mà bạn đã tạo ra trong nội bộ hoặc với một tiêu chuẩn công nghiệp được xác nhận bởi một số tổ chức khác.

Trong trường hợp là ứng dụng Web, bạn sẽ chạy một loạt các thử nghiệm mà thực hiện theo các thông số kỹ thuật của một tiêu chuẩn công nghiệp để nắm bắt các số liệu hiệu suất cần thiết để xác định điểm chuẩn của ứng dụng. Sau đó bạn có thể so sánh các ứng dụng của bạn với các hệ thống hoặc các ứng dụng đã được tính toán dựa trên Benchmarking đó. Bạn có thể điều chỉnh hiệu suất của ứng dụng để đạt được hoặc vượt qua một số chuẩn nhất định. Một số cân nhắc về điểm chuẩn bao gồm:

• You need to play by the rules Bạn cần phải chơi theo luật. Một điểm chuẩn có thể đạt được bằng cách làm việc với các thông số kỹ thuật hoặc porting một cài đặt sẵn có để đáp ứng các tiêu chuẩn đó. Benchmarking đòi hỏi những thành phần cần thiết để chạy với nhau, thị trường sản phẩm, và các số liệu cụ thể đo được.

• Because you play by the rules, you can be transparent. Bởi vì bạn chơi theo các quy tắc, nên bạn được minh bạch. Kết quả Benchmarking có thể được công bố với bên ngoài. Để sản phẩm của bạn có thể cạnh tranh với đối thủ, bạn sẽ muốn sử dụng một tập hợp chặt chẽ của các phương pháp tiêu chuẩn để thử nghiệm và dữ liệu để đảm bảo kết quả là đáng tin cậy.

• You divulge results across various metrics.** Bạn tiết lộ kết quả trên số liệu khác nhau. Số liệu hiệu suất có thể liên quan đến thời gian tải, số lượng giao dịch xử lý trên một đơn vị thời gian, các trang web truy cập trên một đơn vị thời gian, sử dụng bộ vi xử lý, bộ nhớ sử dụng, thời gian tìm kiếm, v.v...

Terminology (Thuật ngữ)

Những định nghĩa bên dưới đây được dùng để tra cứu trong guide này. Rất nhiều công sức được tiêu tốn để đảm bảo rằng những thuật ngữ và định nghĩa đều đã được sử dụng một cách đồng nhất với cách dùng chung và tiêu chuẩn chung trong công nghiệp phần mềm, tuy nhiên, một vài thuật ngữ thì lại được biết đến một cách dẫn dụ và chắc chăn một cách xe kẽ, phụ thuộc vào từng tổ chức hoặc công nghiệp. Hãy ghi nhớ trong đầu rằng những định nghĩa này được dùng để hỗ trợ giao tiếp chứ không phải một cố gắng nhất định để tao nên chuẩn hóa toàn cầu.

|Term / Concept|Description|
|Capacity|‘ capacity’ của một hệ thống là tổng công tải/ mức độ tải công việc mà nó có thể xử lý một cách mượt mà, không vi phạm các tiêu chí đánh giá về hiệu suất đã được đề ra sẵn.|
|Capacity test|Một ‘capacity test’ sẽ bổ sung phần kiểm thử về hoạt động tải bằng cách xác định điểm chịu đựng cuối cùng cho server của bạn, và ngươc lại, load testing sẽ quan sát kết quả ở nhiều cấp cho hoạt động tải và mảnh lưu lương. Bạn thực hiện capacity testing kết hợp với lên kế hoạch sức chứa, mà bạn sử dụng để lập kế hoạch cho sự phát triển trong tương lai, chẳng hạn như một cơ sở người dùng tăng hoặc tăng khối lượng dữ liệu. Ví dụ, để chứa tải trong tương lai, bạn cần phải biết có bao nhiêu nguồn lực bổ sung (chẳng hạn như khả năng xử lý, sử dụng bộ nhớ, dung lượng đĩa, hoặc băng thông mạng) là cần thiết để hỗ trợ mức độ sử dụng trong tương lai. kiểm tra khả năng giúp bạn xác định một chiến lược mở rộng quy mô để xác định xem bạn nên quy mô lên hoặc quy mô ra.|
|Component test|Một ‘component test’ là bất kỳ một phép test hiệu suất nào đó mà trỏ tới một thành phần trong cấu trúc của ứng dung. Những phần kiểm thử theo components phổ biến bao gồm servers, databases, networks, firewalls, và thiết bị lưu trữ.|
|Endurance test (Kiểm thử sức chịu đựng)|Một ‘endurance test ‘ là một loại kiểm thử về hiệu suất nhưng tập trung vào việc xác đinh / xác nhận tính hợp lê của những đặc thù hiệu suất của sản phẩm đang chịu kiểm tra khi chịu khối lượng mô hình công việc và khối lượng tải dự đoán trong các hoạt động sản xuất trong một thời gian cố đính có thể mở rộng thêm. Endurance test  là một tập nhiều phép Load Testing.|
|Investigation|Investigation là một hoạt động dựa vào việc thu thập dữ liệu liên quan đến tốc độ, khả năng mở rộng và hoăc đăc thù mở rộng của sản phẩm đang được kiểm thử, mà có thể có giá trị trong việc xác định hoặc cải thiện chất lượng sản phẩm. Investigation được thường xuyên sử dụng để chứng minh hay bác bỏ giả thuyết về nguyên nhân gốc rễ của một hoặc nhiều vấn đề hiệu suất cần chú trọng.|
|Latency|Latency là một thông số phản ứng đại diện cho thời gian cần để hoàn thành việc thực hiện các yêu cầu. Độ trễ cũng có thể đại diện cho tổng của một số độ trễ hoặc tác vụ con.|
|Metrics|Metrics là số liệu được đo thu được bằng cách chạy các bài kiểm tra được thể hiện trên một quy mô phổ biến và nhiều người hiểu. Một số số liệu thường được thông qua bởi các bài kiểm tra bao gồm việc sử dụng bộ vi xử lý theo thời gian và bộ nhớ sử dụng bởi tải.|
|Performance|Performance phản ánh thời gian mà ứng dụng phản hồi, băng thông và mức độ sử dụng nguồn nhân lực|
|Performance Test|Performance Test một cuộc nghiên cứu kỹ thuật được thực hiện để xác định hoặc xác nhận các chỉ sô tốc độ, khả năng mở rộng, và / hoặc tính ổn định của sản phẩm được kiểm tra. Performance Test là superset có chứa tất cả các loại kiểm thử con được mô tả trong chương này.|
|Performance budgets or allocations|Performance budgets (or allocations) là những hạn chế đặt trên các nhân viên phát triển phần mềm liên quan đến tiêu thụ tài nguyên cho phép đối với các thành phần của họ.|
|Performance goals|Performance goals là những tiêu chí mà nhóm của bạn mong muốn được gặp trước khi phát hành sản phẩm, mặc dù các tiêu chí này có thể được thoả thuận trong những hoàn cảnh nhất định. Ví dụ, nếu một giao tác được thiết lập thời gian phản hồi là 3 giây, nhưng thời gian phản hồi thực tế là 3,3 giây, có khả năng là các bên liên quan sẽ chọn để phát hành các ứng dụng và trì hoãn việc điều chỉnh hiệu suất của giao giao đó sẽ phát hành trong tương lai.|
|Performance objectives|Performance objectives thường quy định về thời gian phản hồi, băng thông (giao tác trên mỗi giây), và mức độ tài nguyên sử dụng và thường tập trung vào các chỉ số có thể liên quan trực tiếp đến sự hài lòng của người sử dụng.|
|Performance requirements|Performance requirements là những tiêu chí mà hoàn toàn không thể thương lượng do nghĩa vụ hợp đồng, thỏa thuận cấp độ dịch vụ (SLA), hoặc các nhu cầu kinh doanh cố định. Bất kỳ tiêu chí hiệu suất nào mà sẽ không phải là nghi ngờ hàng đầu dẫn đến một quyết định hoãn phát hành cho đến các tiêu chí đi không hoàn toàn cần thiết - và do đó, đáy không phải là một yêu cầu.|
|Performance targets| Performance targets là các giá trị mong muốn cho các số liệu xác định cho dự án của bạn thuộc một tập hợp các điều kiện, thường được chỉ định về thời gian phản hồi, băng thông, và mức độ tài nguyên sử dụng. Mức tài nguyên sử dụng bao gồm dung lượng bộ xử lý, bộ nhớ, đĩa I/O, và mạng I/O mà ứng dụng của bạn tiêu thụ. Performance targets (Mục tiêu thực hiện) thường đánh đồng với các mục tiêu của dự án.|
|Performance thresholds|Performance thresholds là những giá trị tối đa có thể chấp nhận cho các số liệu xác định cho dự án của bạn thuộc một tập hợp các điều kiện, thường được chỉ định về thời gian phản hồi, băng thông, và mức độ tài nguyên sử dụng. Mức tài nguyên sử dụng bao gồm dung lượng bộ xử lý, bộ nhớ, đĩa I/O, và mạng I/O mà ứng dụng của bạn tiêu thụ. Performance thresholds thường đánh đồng với yêu cầu|
|Resource utilization|Resource utilization là chi phí của dự án về tài nguyên hệ thống. Các nguồn tài nguyên chính là bộ xử lý, bộ nhớ, đĩa I/O, và mạng I/O.|
|Response time|Response Time là một biện pháp để biết phản hồi của 1 ứng dụng hoặc một hệ thống con đên yêu cầu của khách hàng như thế nào|
|Saturation|Saturation đề cập đến điểm mà tại đó một nguồn tài nguyên đã được sử dụng vừa đủ|
|Scenarios (kịch bản)|Trong bối cảnh thực hiện thử nghiệm, một kịch bản là một chuỗi các bước trong ứng dụng của bạn. Một kịch bản có thể đại diện cho một trường hợp sử dụng hoặc một chức năng như tìm kiếm một danh mục sản phẩm, thêm một mục vào giỏ hàng, hoặc đặt hàng.|
|Smoke test|Smoke test dùng để chạy lần đầu của một thử nghiệm, nó được thực hiện để xem ứng dụng có thể thực hiện các hoạt động theo một tải bình thường được hay không.|
|Spike test|Spike test là một loại của thử nghiệm hiệu suất, tập trung vào việc xác định hoặc xác nhận đặc tính hiệu suất của sản phẩm được kiểm tra khi chịu khối lượng công việc và khối lượng tải liên tục tăng vượt dự đoán trong thời gian ngắn. Spike test là một tập hợp con của Stress test.|
|Stability|Trong bối cảnh thử nghiệm hiệu suất, tính ổn định thể hiện độ tin cậy tổng thể, vững mạnh, toàn vẹn chức năng và dữ liệu, sẵn có, và / hoặc tính nhất quán của các phản ứng cho hệ thống dưới các điều kiện khác nhau.|
|Stress test|Stress test là một loại của thử nghiệm hiệu suất, được thiết kế để đánh giá hành vi của một ứng dụng khi nó được đẩy vượt ra ngoài điều kiện tải trọng bình thường hoặc cao điểm. Mục tiêu của Stress test là để lộ lỗi ứng dụng trong điều kiện tải cao. Những lỗi có thể bao như các vấn đề đồng bộ hóa, điều kiện đua, và rò rỉ bộ nhớ. Stress test cho phép bạn xác định các điểm yếu của ứng dụng của bạn, và cho thấy cách ứng xử trong điều kiện cao.|
|Throughput|Băng thông là số lượng đơn vị của công việc đó có thể được xử lý trên một đơn vị thời gian; Ví dụ, các yêu cầu trên mỗi giây, các calls theo mỗi ngày, số lượt truy cập mỗi giây, báo cáo mỗi năm, vv|
|Unit test|Trong bối cảnh thực hiện thử nghiệm, một kiểm thử đơn vị là bất kỳ kiểm tra nhằm vào mô-đun code nào đó trên ứng dụng, nó tập trung vào các đặc tính hiệu suất. Các mô đun thường được thử nghiệm bao gồm các chức năng, thủ tục, quy trình, đối tượng, phương thức, và các lớp. Kiểm tra đơn vị thường được tạo ra và được thực hiện bởi các nhà phát triển,  người đã viết các mô đun đang được thử nghiệm.|
|Utilization|Trong bối cảnh thực hiện thử nghiệm, sử dụng là tỷ lệ phần trăm thời gian mà một tài nguyên là để phục vụ cho yêu cầu người dùng. Tỷ lệ còn lại của thời gian được coi là thời gian nhàn rỗi.|
|Validation test|Một kiểm tra xác nhận là so sánh đặc điểm tốc độ, khả năng mở rộng, và / hoặc tính ổn định của sản phẩm được kiểm tra với những mong đợi mà đã được thiết lập hoặc giả định cho sản phẩm đó.|
|Workload|Khối lượng công việc là gói kích thích áp dụng cho một hệ thống, ứng dụng, hoặc các thành phần để mô phỏng một mô hình sử dụng, liên quan đến đồng thời và / hoặc các dữ liệu đầu vào. Khối lượng công việc bao gồm tổng số người sử dụng, người sử dụng hoạt động đồng thời, dữ liệu, và giao dịch, cùng với sự pha trộn giao dịch. Đối với mô hình hoạt động, bạn liên kết một khối lượng công việc với một kịch bản riêng.|

TỔNG KẾT

Kiểm thử hiệu suất giúp xác định tắc nghẽn trong một hệ thống, thiết lập baseline để kiểm thử trong tương lai, hỗ trợ sức lực điều chỉnh hiệu suất, và đưa ra nhận định phù hợp với mục tiêu và yêu cầu. Bao gồm kiểm thử hiệu suất rất sớm trong vòng đời phát triển sẽ giúp tăng giá trị đáng kể cho dự án.

Đối với một dự án kiểm thử hiệu suất, muốn thành công, kiểm thử phải phù hợp với bối cảnh của dự án, điều đấy giúp bạn tập trung vào những yếu tố thật sự quan trọng.

Nếu các chỉ tiêu hiệu suất là không thể chấp nhận, bạn sẽ thường muốn chuyển trọng tâm từ các kiểm thử hiệu suất để điều chỉnh làm thế nào cho các ứng dụng thực hiện chấp nhận được. Bạn sẽ phải tập trung vào việc điều chỉnh nếu bạn muốn giảm bớt số lượng tài nguyên được sử dụng và / hoặc nâng cao hơn nữa hiệu suất hệ thống.

Performance, Load, and Stress Testing là tiểu thể loại thử nghiệm hiệu suất, mỗi loại sẽ được ứng dụng cho một mục đích khác nhau.

Tạo một baseline dựa vào đó để đánh giá hiệu quả của những thay đổi hiệu suất cải thiện tiếp theo cho hệ thống hoặc ứng dụng nói chung sẽ làm tăng hiệu quả của dự án.