3.7 Non-Functional TestingThe tests

3.7 Non-Functional Testing
The tests described in the previous sections are functional tests. These tests are adequate for demonstrating the software meets it’s requirements and does not fail. However, GUI applications have non-functional modes of failure also. We propose three additional GUI test types (that are likely to be automated).
Soak Testing
In production, systems might be operated continuously for many hours. Applications may be comprehensively tested over a period of weeks or months but are not usually operated for extended periods in this way. It is common for client application code and bespoke middleware to have memory-leaks. Soak tests exercise system transactions continuously for an extended period in order to flush out such problems.
These tests are normally conducted using an automated tool. Selected transactions are repeatedly executed and machine resources on the client (or the server) monitored to identify resources that are being allocated but not returned by the application code.
Compatibility Testing
Whether applications interface directly with other desktop products or simply co-exist on the same desktop, they share the same resources on the client. Compatibility Tests are (usually) automated tests that aim to demonstrate that resources that are shared with other desktop products are not locked unnecessarily causing the system under test or the other products to fail.
These tests normally execute a selected set of transactions in the system under test and then switch to exercising other desktop products in turn and doing this repeatedly over an extended period.
Platform/Environment Testing
In some environments, the platform upon which the developed GUI application is deployed may not be under the control of the developers. PC end-users may have a variety of hardware types such as 486 and Pentium machines, various video drivers, Microsoft Windows 3.1, 95 and NT. Most users have PCs at home nowadays and know how to customise their PC configuration. Although your application may be designed to operate on a variety of platforms, you may have to execute tests of these various configurations to ensure when the software is implemented, it continues to function as designed. In this circumstance, the testing requirement is for a repeatable regression test to be executed on a variety of platforms and configurations. Again, the requirement for automated support is clear so we would normally use a tool to execute these tests on each of the platforms and configurations as required.
4 Test Automation
4.1 Justifying Automation
Automating test execution is normally justified based on the need to conduct functional regression tests. In organisations currently performing regression test manually, this case is easy to make - the tool will save testers time. However, most organisations do not conduct formal regression tests, and often compensate for this ‘sub-consciously’ by starting to test late in the project or by executing tests in which there is a large amount of duplication.
In this situation, buying a tool to perform regression tests will not save time, because no time is being spent on regression testing in the first place. In organisations where development follows a RAD approach or where development is chaotic, regression testing is difficult to implement at all - software products may never be stable enough for a regression test to mature and be of value. Usually, the cost of developing and maintaining automated tests exceeds the value of finding regression errors.
We propose that by adopting a systematic approach to testing GUIs and using tools selectively for specific types of tests, tools can be used to find errors during the early test stages. That is, we can use tools to find errors pro-actively rather than repeating tests that didn’t find bugs first time round to search for regression errors late in a project.
4.2 Automating GUI Tests
Throughout the discussion of the various test types in the previous chapter, we have assumed that by designing tests with specific goals in mind, we will be in a better position to make successful choices on whether we automate tests or continue to execute them manually. Based on our experience of preparing automated tests and helping client organisations to implement GUI test running tools we offer some general recommendations concerning GUI test automation below.
Pareto law • We expect 80% of the benefit to derive from the automation of 20% of the tests.
• Don’t waste time scripting low volume complex scripts at the expense of high volume simple ones.
Hybrid Approach • Consider using the tools to perform navigation and data entry prior to manual test execution.
• Consider using the tool for test running, but perform comparisons manually or ‘off-line’.
Coded scripts • These work best for navigation and checklist-type scripts.
• Use where loops and case statements in code leverage simple scripts.
• Are relatively easy to maintain as regression tests.
Recorded Scripts • Need to be customised to make repeatable.
• Sensitive to changes in the user interface.
Test Integration • Automated scripts need to be integrated into some form of test harness.
• Proprietary test harnesses are usually crude so custom-built harnesses are required.
Migrating Manual Test Scripts • Manual scripts document automated scripts
• Delay migration of manual scripts until the software is stable, and then reuse for regression tests.
Non-Functional Tests • Any script can be reused for soak tests, but they must exercise the functionality of concern.
• Tests of interfaces to desktop products and server processes are high on the list of tests to automate.
• Instrument these scripts to take response time measurements and re-use for performance testing.
From the discussion above, we are now in a position to propose a test automation regime that fits the GUI test process. Table 4 - Manual versus automated execution presents a rough guideline and provides a broad indication of our recommended approach to selecting tests to automate.

Kết quả (Việt) 1:

3.7 thử nghiệm không hoạt độngCác bài kiểm tra mô tả trong phần trước là thử nghiệm chức năng. Các xét nghiệm được đầy đủ cho thể hiện mức độ đáp ứng phần mềm đó là yêu cầu và không thất bại. Tuy nhiên, ứng dụng GUI có các chế độ không có chức năng của sự thất bại cũng. Chúng tôi đề nghị ba bổ sung GUI thử nghiệm loại (mà có thể được tự động).Ngâm thử nghiệmTrong sản xuất, Hệ thống có thể được vận hành liên tục trong nhiều giờ. Ứng dụng có thể được kiểm tra toàn diện trong một khoảng thời gian vài tuần hoặc vài tháng nhưng không thường hoạt động trong thời gian dài theo cách này. Nó là phổ biến cho khách hàng ứng dụng mã và middleware bespoke có rò rỉ bộ nhớ. Khám xét nghiệm tập thể dục hệ thống giao dịch liên tục trong một thời gian dài để tuôn ra vấn đề như vậy. Các xét nghiệm này thường được thực hiện bằng cách sử dụng một công cụ tự động. Lựa chọn giao dịch được thực hiện liên tục và máy tài nguyên trên khách hàng (hoặc các máy chủ) theo dõi để xác định nguồn tài nguyên đang giao nhưng không trả lại bởi các ứng dụng mã.Khả năng tương thích thử nghiệmCho dù ứng dụng giao tiếp trực tiếp với các sản phẩm máy tính để bàn khác hoặc chỉ đơn giản là cùng tồn tại trên cùng một máy tính để bàn, họ chia sẻ các tài nguyên cùng một trên máy khách. Kiểm tra khả năng tương thích là tự động (thường) thử nghiệm mà mục đích là để chứng minh rằng nguồn lực được chia sẻ với các sản phẩm máy tính để bàn được không bị khóa không cần thiết gây ra hệ thống kiểm tra hoặc các sản phẩm khác không.Các xét nghiệm này thường thực hiện một tập hợp được lựa chọn của các giao dịch trong hệ thống kiểm tra và sau đó chuyển sang tập thể dục các sản phẩm máy tính để bàn khác lần lượt và làm điều này nhiều lần trong một khoảng thời gian dài.Nền tảng/môi trường thử nghiệmTrong một số môi trường, nền tảng mà phát triển ứng dụng GUI triển khai có thể không dưới sự kiểm soát của các nhà phát triển. PC người dùng cuối cùng có thể có một loạt các loại phần cứng như 486 và Pentium máy, trình điều khiển video khác nhau, Microsoft Windows 3.1, 95 và NT. Hầu hết người dùng có máy tính ở nhà ngày nay và biết làm thế nào để tùy chỉnh cấu hình PC của họ. Mặc dù ứng dụng của bạn có thể được thiết kế để hoạt động trên một loạt các nền tảng, bạn có thể cần phải thực hiện các xét nghiệm của các cấu hình khác nhau để đảm bảo khi phần mềm được thực hiện, nó tiếp tục hoạt động như thiết kế. Trong trường hợp này, yêu cầu thử nghiệm là cho một bài kiểm tra hồi quy lặp lại được thực hiện trên một loạt các nền tảng và cấu hình. Một lần nữa, yêu cầu cho tự động hỗ trợ là rõ ràng, do đó, chúng tôi thường sẽ sử dụng một công cụ để thực hiện các bài kiểm tra trên mỗi người trong số các nền tảng và cấu hình theo yêu cầu.4 kiểm tra tự động hóa4.1 chứng minh tự động hóaTự động hoá kiểm tra thực hiện thường là hợp lý dựa trên sự cần thiết để tiến hành các xét nghiệm chức năng hồi quy. Trong tổ chức hiện hồi qui kiểm tra theo cách thủ công, trường hợp này là dễ dàng để thực hiện - công cụ sẽ tiết kiệm thời gian thử nghiệm. Tuy nhiên, hầu hết các tổ chức không tiến hành thử nghiệm chính thức hồi qui, và thường bù đắp cho điều này 'phụ có ý thức' bằng cách bắt đầu để kiểm tra vào cuối dự án hoặc bằng cách thực hiện các bài kiểm tra trong đó có một số lượng lớn của sao chép. Trong tình huống này, mua một công cụ để thực hiện các bài kiểm tra hồi quy sẽ không tiết kiệm thời gian, bởi vì không có thời gian được chi tiêu vào hồi qui kiểm tra tại địa điểm đầu tiên. Trong tổ chức nơi phát triển theo một cách tiếp cận RAD hoặc nơi phát triển là hỗn loạn, hồi qui kiểm tra là khó khăn để thực hiện ở tất cả - sản phẩm phần mềm có thể không bao giờ được ổn định, đủ cho một bài kiểm tra hồi qui để trưởng thành và có giá trị. Thông thường, các chi phí phát triển và duy trì tự động thử nghiệm vượt quá giá trị của việc tìm kiếm các hồi quy lỗi.Chúng tôi đề xuất rằng bằng việc áp dụng một cách tiếp cận có hệ thống để kiểm tra GUIs và sử dụng công cụ chọn lọc cho các loại hình cụ thể của thử nghiệm, các công cụ có thể được sử dụng để tìm thấy lỗi trong giai đoạn đầu của thử nghiệm. Có nghĩa là, chúng tôi có thể sử dụng công cụ để tìm lỗi ủng hộ tích cực thay vì lặp lại thử nghiệm mà không tìm thấy lỗi đầu tiên vòng để tìm kiếm các hồi quy lỗi vào cuối một dự án.4.2 tự động hoá GUI bài kiểm traTrong suốt các cuộc thảo luận của các loại thử nghiệm trong chương trước, chúng tôi đã giả định rằng bằng cách thiết kế thử nghiệm với các mục tiêu cụ thể trong tâm trí, chúng tôi sẽ ở một vị trí tốt hơn để lựa chọn thành công vào việc chúng tôi tự động hóa xét nghiệm hay tiếp tục thực hiện chúng theo cách thủ công. Dựa trên kinh nghiệm chuẩn bị tự động thử nghiệm và giúp đỡ khách hàng tổ chức để thực hiện thử nghiệm GUI chạy công cụ chúng tôi cung cấp một số khuyến nghị chung liên quan đến GUI kiểm tra tự động hóa dưới đây.Pareto luật • chúng tôi mong đợi 80% của lợi ích để lấy được từ tự động hóa của 20% của các bài kiểm tra. • Không lãng phí thời gian kịch bản kịch bản phức tạp khối lượng thấp chi phí của số lượng lớn những cái đơn giản. Kết hợp phương pháp tiếp cận • xem xét sử dụng các công cụ để thực hiện mục nhập điều hướng và dữ liệu trước khi thực hiện hướng dẫn sử dụng thử nghiệm. • Xem xét sử dụng các công cụ cho các bài kiểm tra chạy, nhưng thực hiện so sánh bằng tay hoặc 'off-line'. Mã kịch bản • những công việc tốt nhất cho kịch bản chuyển hướng và danh sách kiểm tra-loại. • Sử dụng nơi vòng và các báo cáo trường hợp trong mã tận dụng kịch bản đơn giản. • Tương đối dễ dàng để duy trì do những bài kiểm tra hồi quy. • Kịch bản ghi cần phải được điều chỉnh để làm cho lặp lại. • Nhạy cảm với những thay đổi trong giao diện người dùng. Thử nghiệm hội nhập • tự động kịch bản cần phải được tích hợp vào một số hình thức kiểm tra khai thác. • Kiểm tra độc quyền bảo hiểm thường thô để theo đặc thù bảo hiểm được yêu cầu. Di chuyển lệnh kiểm tra hướng dẫn sử dụng hướng dẫn sử dụng • kịch bản tài liệu tự động kịch bản • Di chuyển chậm trễ của hướng dẫn sử dụng kịch bản cho đến phần mềm là ổn định, và sau đó tái sử dụng cho regression bài kiểm tra. Kiểm tra phòng không chức năng thử nghiệm • bất cứ kịch bản có thể được tái sử dụng cho ngâm, nhưng họ phải thực hiện các chức năng của mối quan tâm. • Kiểm tra các giao diện để sản phẩm máy tính để bàn và máy chủ quá trình là cao trong danh sách của các xét nghiệm để tự động hoá. • Dụng cụ các kịch bản để có phản ứng thời gian đo lường và tái sử dụng để thử nghiệm hiệu suất. Từ các cuộc thảo luận ở trên, chúng tôi đang ở một vị trí để đề xuất một chế độ tự động hóa kiểm tra phù hợp với quá trình thử nghiệm GUI. Bảng 4 - hướng dẫn sử dụng so với tự động thực hiện trình bày một hướng dẫn thô và cung cấp một dấu hiệu rộng của chúng tôi cách tiếp cận được đề nghị để lựa chọn các xét nghiệm để tự động hoá.

Kết quả (Việt) 2:

3.7 Non-Functional Testing
Các xét nghiệm được mô tả trong các phần trước là thử nghiệm chức năng. Các xét nghiệm này đủ để chứng minh các phần mềm đáp ứng các yêu cầu của nó và không thất bại. Tuy nhiên, giao diện ứng dụng có chế độ phi chức năng thất bại cũng. Chúng tôi đề xuất thêm ba loại giao diện thử nghiệm (có khả năng được tự động).
Ngâm Testing
Trong sản xuất, hệ thống có thể hoạt động liên tục trong nhiều giờ. Ứng dụng có thể được kiểm tra toàn diện trong thời gian vài tuần hoặc vài tháng, nhưng thường không được hoạt động trong thời gian dài theo cách này. Nó được phổ biến cho các mã ứng dụng client và middleware bespoke để có bộ nhớ bị rò rỉ. Ngâm giao dịch kiểm tra hệ thống tập luyện liên tục trong một thời gian dài để tuôn ra những vấn đề như vậy.
Các xét nghiệm này được tiến hành bình thường bằng cách sử dụng một công cụ tự động. Giao dịch được chọn sẽ được liên tục thực hiện và nguồn lực máy trên máy khách (hoặc máy chủ) theo dõi để xác định nguồn lực đang được phân bổ nhưng không được trả về bởi các mã ứng dụng.
Kiểm tra tương thích
dù giao diện ứng dụng trực tiếp với các sản phẩm máy tính để bàn khác hoặc chỉ đơn giản là cùng tồn tại trên cùng máy tính để bàn, họ chia sẻ các nguồn tài nguyên trên cùng một khách hàng. Các thử nghiệm khả năng tương thích (thường) kiểm tra tự động mà mục đích là để chứng minh rằng các tài nguyên được chia sẻ với các sản phẩm máy tính để bàn khác không bị khoá không cần thiết gây ra hệ thống đo kiểm hoặc các sản phẩm khác thất bại.
Các xét nghiệm này thường thực hiện một tập hợp lựa chọn các giao dịch trong hệ thống theo kiểm tra và sau đó chuyển sang thực hiện các sản phẩm máy tính để bàn khác lần lượt, và làm điều này nhiều lần trong một thời gian dài.
Platform / Môi trường kiểm tra
Trong một số môi trường, nền tảng mà trên đó các ứng dụng GUI phát triển được triển khai có thể không được dưới sự kiểm soát của nhà phát triển. PC người dùng cuối có thể có nhiều loại phần cứng như 486 và các máy Pentium, trình điều khiển video khác nhau, Microsoft Windows 3.1, 95 và NT. Phần lớn người dùng máy tính tại nhà ngày nay và biết làm thế nào để tùy chỉnh cấu hình máy tính của họ. Mặc dù ứng dụng của bạn có thể được thiết kế để hoạt động trên nhiều nền tảng, bạn có thể phải thực hiện các bài kiểm tra của các cấu hình khác nhau để đảm bảo khi phần mềm được thực hiện, nó vẫn tiếp tục hoạt động như thiết kế. Trong trường hợp này, các yêu cầu thử nghiệm là một bài kiểm tra hồi quy lặp lại được thực hiện trên nhiều nền tảng và cấu hình. Một lần nữa, các yêu cầu về hỗ trợ tự động là rõ ràng vì vậy chúng tôi sẽ thường sử dụng một công cụ để thực hiện các bài kiểm tra trên mỗi nền tảng và cấu hình theo yêu cầu.
4 Kiểm tra tự động
4.1 Biện minh Tự động hóa
Tự động thực hiện thử nghiệm thường được biện minh dựa trên sự cần thiết phải tiến hành hồi chức năng các bài kiểm tra. Trong các tổ chức đang thực hiện bài kiểm tra hồi quy bằng tay, trường hợp này rất dễ dàng để thực hiện - công cụ này sẽ tiết kiệm thời gian thử nghiệm. Tuy nhiên, hầu hết các tổ chức không tiến hành kiểm tra hồi quy chính thức, và thường thường bù đắp cho điều này "tiểu ý thức" bằng cách bắt đầu thử nghiệm vào cuối dự án hoặc bằng cách thực hiện các bài kiểm tra, trong đó có một số tiền lớn của nhân bản.
Trong tình huống này, mua một công cụ để thực hiện các bài kiểm tra hồi quy sẽ không tiết kiệm thời gian, bởi vì không có thời gian đang được chi cho kiểm tra hồi quy ở nơi đầu tiên. Trong các tổ chức, nơi phát triển sau một cách tiếp cận RAD hoặc nơi phát triển là hỗn loạn, kiểm tra hồi quy là khó thực hiện ở tất cả - các sản phẩm phần mềm có thể không bao giờ được ổn định, đủ cho một bài kiểm tra hồi quy để trưởng thành và có giá trị. Thông thường, chi phí phát triển và duy trì kiểm tra tự động vượt quá giá trị của việc tìm kiếm lỗi hồi quy.
Chúng tôi đề nghị rằng bằng việc áp dụng một cách tiếp cận có hệ thống để kiểm tra ảnh minh hoạ và sử dụng các công cụ chọn lọc với nhiều loại cụ thể của các bài kiểm tra, các công cụ có thể được sử dụng để tìm ra các lỗi trong quá trình thử nghiệm đầu giai đoạn. Đó là, chúng ta có thể sử dụng các công cụ để tìm lỗi chủ động chứ không phải là xét nghiệm lặp đi lặp lại mà không tìm thấy lỗi lần đầu tiên vòng để tìm kiếm các lỗi hồi quy trễ trong một dự án.
4.2 Tự động hoá giao diện thử nghiệm
suốt các cuộc thảo luận về các loại xét nghiệm khác nhau trong chương trước, chúng ta đã giả định rằng bằng cách thiết kế các thử nghiệm với mục tiêu cụ thể, chúng ta sẽ được ở một vị trí tốt hơn để làm cho sự lựa chọn thành công vào việc chúng ta tự động kiểm tra hoặc tiếp tục thực hiện một cách thủ công. Dựa trên kinh nghiệm của chúng tôi chuẩn bị kiểm tra tự động và giúp các tổ chức khách hàng để thực hiện các công cụ GUI chạy thử chúng tôi cung cấp một số kiến nghị chung liên quan đến giao diện tự động kiểm tra dưới đây.
Pareto luật • Chúng tôi hy vọng 80% của lợi ích xuất phát từ việc tự động hóa 20% các bài kiểm tra .
• Không lãng phí thời gian scripting khối lượng thấp các kịch bản phức tạp tại các chi phí của khối lượng cao những cái đơn giản.
hybrid Approach • Xem xét việc sử dụng các công cụ để thực hiện điều hướng và nhập dữ liệu trước khi thực hiện kiểm tra thủ công.
• Xem xét việc sử dụng các công cụ để chạy thử, nhưng thực hiện so sánh tay hoặc "off-line".
kịch bản Coded • Những công việc tốt nhất cho các menu và danh sách kiểm tra kiểu kịch bản.
• Sử dụng nơi các vòng lặp và báo cáo trường hợp trong mã đòn bẩy kịch bản đơn giản.
• Có tương đối dễ dàng để duy trì như các bài kiểm tra hồi quy.
Scripts ghi • cần phải được tùy chỉnh để làm lặp lại.
• Nhạy cảm với những thay đổi trong giao diện người dùng.
Tích hợp thử nghiệm • script tự động cần phải được tích hợp vào một số hình thức khai thác thử nghiệm.
• Dây nịt thử nghiệm phần mềm sở hữu thường thô để khai thác tùy chỉnh xây dựng được yêu cầu.
Chuyển Manual Scripts test • script Manual tài liệu các kịch bản tự động
• Trễ di cư của các kịch bản dẫn đến khi phần mềm ổn định, và sau đó tái sử dụng cho các bài kiểm tra hồi quy.
Các xét nghiệm Non-Chức năng • Bất kỳ kịch bản có thể được tái sử dụng để ngâm các bài kiểm tra, nhưng họ phải thực hiện các chức năng quan tâm.
• Các xét nghiệm của các giao diện cho các sản phẩm máy tính để bàn và máy chủ xử lý được cao trong danh sách các xét nghiệm để tự động hoá.
• Instrument các kịch bản để lấy số đo thời gian phản hồi và tái sử dụng để thử nghiệm hiệu suất.
Từ các cuộc thảo luận ở trên, bây giờ chúng ta đang ở trong một vị trí để đề xuất một chế độ tự động kiểm tra phù hợp với quá trình thử nghiệm giao diện đồ họa. Bảng 4 - Hướng dẫn sử dụng so với thực hiện tự động trình bày một phương châm thô và cung cấp một chỉ rộng của phương pháp tiếp cận của chúng tôi đề nghị để lựa chọn các xét nghiệm để tự động hoá.