2.2 Test Levels (K2)

2.2.1 Component Testing (K2)

Test basis: Component requirements, detailed design, Code

Typical test objects: Components, Programs, Data conversion / migration programs, Database modules

• Component testing (also known as unit, module or program testing) searches for defects in, and verifies the functioning of, software modules, programs, objects, classes, etc., that are separately testable.- Test thành phần ( còn được biết đến như là Unit test, program test) để tìm ra lỗi trong các chức năng, module, chương trình, đối tượng, lớp,… Cái mà có thể test được riêng rẽ từng cái 1
• Done in isolation from the rest of the system, depending on the context of the development life cycle and the system. Harness: Stubs, drivers and simulators may be used. -Việc test tiến hành độc lập với các phần khác của HT, sử dụng Stubs, drivers và simulator để phục vụ cho việc test

 

• Include testing of functionality and specific non-functional characteristics: robustness, security – Test thành phần bao gồm cả test về mặt chưacs năng và phi chức năng
• Test cases are derived from work products such as a specification of the component, the software design or the data model, source code. – Test case được viết dựa trên code, đặc tả của thành phần, bản thiết kế, mô hình dữ liệu
• Component testing occurs with access to the code being tested and with the support of a development environment, such as a unit test framework or debugging tool. – thực hiện bằng cách truy cập vào các đoạn code, sử dụng môi trường lập trình như là các framework cho unit test và các tool debug.
• Component testing usually involves the programmer who wrote the code.- Được thực hiện bởi lập trình viên
• Defects are typically fixed as soon as they are found, without formally managing these defects. -Lỗi được sửa sớm ngay khi tìm ra, ko cần quản lý lỗi
• One approach to component testing is to prepare and automate test cases before coding. This is called a test-first approach or test-driven development. – Thường áp dụng test tự động và test trước khi code ( còn gọi là phương pháp TDD)

2.2.2 Integration Testing (K2)

Test basis: Software and system design, Architecture, Workflows,  Use cases

Typical test objects:  Subsystems, Database implementation,  Infrastructure, Interfaces, System configuration and configuration data

• Integration testing tests interfaces between components, interactions with different parts of a system, such as the operating system, file system and hardware, and interfaces between systems. – Kiểm tra giao tiếp giữa các thành phần, các tương tác với các thành phần khác nhau của HT: hệ điều hành, file HT, phần cứng, và giao tiếp với HT khác
• There may be more than one level of integration testing and it may be carried out on test objects of varying size as follows- Có một số mức độ của test tích hợp:

1. Component integration testing tests the interactions between software components and is done after component testing – Test tích hợp thành phần để ktra các tương tác giữa các thành phần với nhau, hoàn thành trong GD component test.
2. System integration testing tests the interactions between different systems or between hardware and software and may be done after system testing. – Test tích hợp HT để kiể tra tương tác giữa các hệ thống khác nhau hơcj giữa phần cứng với phần mềm, hoàn thành trong giai đoạn System test

• The greater the scope of integration, the more difficult it becomes to isolate defects to a specific component or system, which may lead to increased risk and additional time for troubleshooting. – Phạm vi của việc tích hợp càng lớn, thì độ khó để phát hiện được lỗi trong thành phần hoặc hệ thống càng khó, điều này dẫn đến tang rủi ro và cần them thời gian để xử lý các vấn đề rắc rối

Chiến lược tích hợp

Big-bang integration – Tích hợp big-bang

• In theory- lý thuyết:
  • If we have already tested components why not just combine them all at once? Wouldn’t this save time? – Nếu đã test từng thành phần rồi thì sao ta ko kết hợp chúng cùng 1 lúc, để tiết kiệm thời gian
  • (based on false assumption of no faults)- dựa trên giả định sai lầm về không có lỗi
• In practice- thực tế:
  • Takes longer to locate and fix faults – Mất nhiều thời gian để đặt và sửa lỗi
  • Re-testing after fixes more extensive – phải test lại rộng hơn sau khi sửa lỗi
  • End result? Takes more time – Tốn nhiều thời gian

Incremental integration – tích hợp gia tăng

• Baseline 0 tested component
• Baseline 1: two components
• Baseline 2: three components, etc.
• Advantages:
  • Easier fault location and fix – Dễ xác định vị trí và sửa lỗi
  • Easier recovery from disaster/ problems – Dễ phục hồi sau khi xảy ra vấn đề tích hợp
  • Interfaces should have been tested in component tests, but ..- Các giao tiếp nên được test ở mức test thành phần
  • Add to tested baseline – them được bản baseline được test

2.2.3 System Testing (K2)

Test basis: System and software requirement specification, Use cases, Functional specification,  Risk analysis reports.

Typical test objects: System, user and operation manuals, System configuration and configuration data

• System testing is concerned with the behavior of a whole system/product. – Test HT tập trung vào kiểm tra hành vi của toàn HT hoặc SP.
• The test environment should correspond to the final target or production environment as much as possible in order to minimize the risk of environment-specific failures not being found in testing. – Trong test HT, môi trường test nên tương đối gần với môi trường thật để có thể giảm tối thiểu các rủi ro do lỗi của môi trường gây ra
• Include tests based on risks and/or on requirements specifications, business processes, use cases, or other high level text descriptions or models of system behavior, interactions with the operating system, and system resources. – Test hệ thống bao gồm test dựa trên rủi ro and/ or Đặc tả yêu cầu, quy trình nghiệp vụ, trường hợp sửa dụng hoặc đặc tả mức cao, kiểu mẫu hành vi của hệ thống, tương tác với Hên điều hành và tài nguyên của hệ thống
• Investigate functional and non-functional requirements of the system, and data quality characteristics (operational testing). – Test hệ thống nên nghiên cứu để test được cả mặt chức năng và phi chức năng, các đặc tính chất lượng của dữ liệu
• Testers also need to deal with incomplete or undocumented requirements. – Tester cần sử dụng cả tài liệu ko đầy đủ hoặc ko đc mô tả.
• System testing of functional requirements starts by using the most appropriate specification-based (black-box) techniques for the aspect of the system to be tested. – Test hệ thống cho yêu cầu về chức năng nên sử dụng kỹ thuật tiếp cận là black-box dựa trên đặc tả để thực hiện test.

An independent test team often carries out system testing. – Test HT thường được thực hiện bởi team test độc lập

2.2.4 Acceptance Testing (K2)

Test basis: User requirements, System requirements, Use cases, Business processes, Risk analysis reports

Typical test objects: Business processes on fully integrated system, Operational and maintenance processes, User procedures, Forms, Reports, Configuration data

• Acceptance testing is often the responsibility of the customers or users of a system; other stakeholders may be involved as well.

Test chấp nhận được thực hiện bởi KH hoặc người sử dụng HT, hoặc có thể là nhà đầu tư

• The goal is to establish confidence in the system, parts of the system or specific non-functional characteristics of the system.

Mục tiêu của test chấp nhận là để tạo sự tự tin về hệ thống, 1 phần của hệ thống hoặc các đặc tính phi chức năng của hệ thống

• Finding defects is not the main focus in acceptance testing.

Tìm lỗi không phải là trọng tâm chính của acceptance testing.

• Acceptance testing may assess the system’s readiness for deployment and use

Để đánh giá được mức độ sẵn sang của hệ thống để đưa vào sử dụng

Acceptance testing may occur at various times in the life cycle- AT có thể diễn ra vài lần trong chu trình dự án

For example:

• A COTS software product may be acceptance tested when it is installed or integrated

PM thương mại hoá có thể được test chấp nhận ngay khi nó đc cài đặt hoặc tích hợp

• Acceptance testing of the usability of a component may be done during component testing

Test chấp nhận khả năng sử dụng của 1 thành phần được thực hiện trong giai đoạn component testing

• Acceptance testing of a new functional enhancement may come before system testing

Test chấp nhận 1 chức năng mới được thêm vào được thực hiện trước khi system test

Typical forms of acceptance testing include the following – Các hình thức điển hình của test chấp nhận:

1. User acceptance testing

Typically verifies the fitness for use of the system by business users.- xác minh sự phù hợp về tính năng sử dụng của hệ thống bởi người dùng cuối

2. Operational (acceptance) testing

The acceptance of the system by the system administrators, including- Chấp nhận bởi những người điều hành hệ thống (admin):

• Testing of backup/restore or disaster recovery
• User management
• Maintenance tasks
• Data load and migration tasks
• Periodic checks of security vulnerabilities

3. Contract and regulation acceptance testing– Chấp nhận dựa trên hợp đồng và các quy định

• Contract acceptance testing is performed against a contract’s acceptance criteria for producing custom-developed software.

Test chấp nhận được thực hiện bằng cách đối chiếu với các điều khoản của hợp đồng

• Regulation acceptance testing is performed against any regulations that must be adhered to, such as government, legal or safety regulations.

Test chấp nhận được thực hiện bằng các đối chiếu với tất cả các quy định được áp dụng cho SP này vd như quy định của chính phủ, luật, quy định an toàn,…

4. Alpha and beta (or field) testing- Test Alpha và beta

• Alpha testing is performed at the developing organization’s site but not by the developing team. – Alpha testing được thực hiện ở nơi mà phần mềm được phát triển nhưng ko phải bởi đội dự án
• Beta testing, or field-testing, is performed by customers or potential customers at their own locations. – Beta testing hay còn gọi là field testing được thực hiện bởi KH hoặc KH tiểm năng ở môi trường của chính họ

2.3 Test Types (K2)

2.3.1 Functional system testing – Test chức năng hệ thống

Requirements-based testing – Test dựa trên các yêu cầu

• Uses specification of requirements as the basis for identifying tests – Sử dụng đặc tả các yêu cầu làm cơ sở cho việc xác định các test
  • Table of contents of the requirements spec provides an initial test inventory of test conditions – Tài liệu đặc tả cung cấp những điều kiện test ban đầu
  • For each section/ paragraph/ topic/ functional area, – Đối với mỗi phần / đoạn / chủ đề / khu chức năng,
    • Risk analysis to identify most important/ critical – Phân tích rủi ro để xác định quan trọng nhất / cấp thiết nhất
    • Decide how deeply to test each functional area – Quyết định cách sâu sắc để kiểm tra từng khu chức năng

Business process- based testing – Test dựa trên các quy trình nghiệp vụ

• Expected user profiles – Dự kiến hồ sơ người dùng
  • What will be used most often – Phần nào hay được sử dụng nhiều?
  • What is critical to the business – Những nghiệp vụ nào là quan trọng?
• Business scenarios – Kịch bản nghiệp vụ
  • Typical business transactions (birth to death) – Các giao dịch nghiệp vụ điển hình
• Use cases – trường hợp sử dụng
  • Prepared case based on real situations- chuẩn bị các trường hợp dựa trên tình huống thật

Note: Security investigates the functions (eg.. firewall) relating to detection of the threats, such as viruses, from malicious outsiders

Interoperability testing evaluates the capability of the software product to interact with one or more specified components or systems

2.3.2 Non-functional system testing – Test các yêu cầu chất lượng của hệ thống

• Different types of non-functional system tests – Sự khác nhau giữa các loại test non-functional:

Performances tests – Test hiệu năng

• Timing tests- Test thời gian
  • Response and service times – Thời gian phản hồi và phục vụ
  • Database back-up times – Thời gian back-up dữ liệu

Load test và volume test

• Capacity & volume tests – Test khả năng lớn
  • Maximum amount or processing rate – dữ liệu lớn hoặc tỷ lệ xử lý lớn
  • Number of records on the system – Số lượng record của hệ thống
  • Graceful degradation – Khả năng khai báo
• Endurance tests (24-hr operation?) – Test khoản thời gian
  • Robustness of the system – tính mạnh mẽ của hệ thống
  • Memory allocation – Cho phép bộ nhớ

Multi-User tests – Test nhiều người dung cùng lúc

• Concurrency tests- Truy cập đồng thời kiểm tra
  • Small numbers, large benefits – Một số lượng nhỏ, lợi ích lớn
  • Detect record locking problems- Phát hiện vấn đề khóa kỷ lục
• Load tests – Kiểm tra tải
  • The measurement of system behavior under realistic multi-user load – Các phép đo của hệ thống hành vi dưới tải đa người dùng thực tế
• Stress tests – Kiểm tra căng thẳng
  • Go beyond limits for the system- know what will happen – Vượt qua giới hạn của hệ thống- biết điều gì sẽ xảy ra
  • Particular relevance for e-commerce – liên quan cụ thể đối với thương mại điện tử

Usability tests – kiểm tra khả năng sử dụng

• Messages tailored and meaningful to (real) users? – Tin nhắn phù hợp và có ý nghĩa cho người sử dụng (thực tế)?
• Coherent and consistent interface?- Giao diện mạch lạc và nhất quán
• Sufficient redundancy of critical information? – Có đầy đủ dự phòng thông tin quan trọng?
• Within the “human envelope”? (7 choices) – Trong “phong bì của con người”? (7 lựa chọn)
• Feedback (wait messages)?- Phản hồi (chờ tin nhắn)?
• Clear mappings (how to escape) – làm thế nào để thoát?

Security tests

• Passwords
• Encryption – mã hóa
• Hardware permission devices – Thiết bị cho phép phần cứng
• Levels of access to information – Mức độ truy cập thông tin
• Authorization – Ủy quyền Covert channels
• Physical security- Bảo mật vật lý

Configuration and installation – Cấu hình và cài đặt

• Configuration tests – Test cấu hình
  • Different hardware or software environment – Trong điều kiện môi trường phần cứng và phần mềm khác nhau
  • Configuration of the system itself – Test với cấu hình mặc định của hệ thống
  • Upgrade paths- may conflict – Nâng cấp phiên bản- có thể xung đột
• Installation tests – Test cài đặt
  • Distribution (CD, network,etc..) and timings – Phân phối (CD, mạng, vv ..) và thời gian
  • Physical aspects: electromagnetic fields, heat, humidity, motion, chemicals, power supplies – khía cạnh vật lý: trường điện từ, nhiệt độ, độ ẩm, chuyển động, hóa chất, vật tư điện
  • Uninstall ( removing installation) – gỡ bỏ cài đặt

Reliability/ Qualities – Độ bền / chất

• Reliability
  • “system will be reliable” – how to test this? – “hệ thống sẽ được tin cậy” – làm thế nào để kiểm tra điều này?
  • “2 failures per year over ten years” –  “2 lỗi mỗi năm trải qua mười năm”
  • Mean Time Between Failures (MTBF) – Khoảng thời gian ý nghĩa giữa những lần bị lỗi
  • Reliability growth models – Độ bền mô hình tăng trưởng
• Other qualities – Chất lượng khác
  • Maintainability ( modulability ), portability, adaptability, etc.. – Bảo trì, tính di động, khả năng thích ứng, vv ..

Back-up and Recovery- Back-up và phục hồi

• Back-ups
  • Computer functions – là chức năng của máy tính
  • Manual procedures (where are tapes stored) – hoặc thủ tục bằng tay
• Recovery
  • Real test of back-up – Kiểm tra lại hoạt động back-up
  • Manual procedures unfamiliar – Thủ tục bằng tay không theo thong thường
  • Should be regularly rehearsed – Nên lặp lại thường xuyên
  • Documentation should be detailed, clear and thorough – Tài liệu hóa nên chi tiết, rõ ràng

2.3.3 Testing of Software Structure/Architecture (Structural Testing) (K2)

• Structural (white-box) testing may be performed at all test levels. – Test cấu trúc( white-box test) được thực hiện ở tất cả các level test.
• Coverage is the extent that a structure has been exercised by a test suite, expressed as a percentage of the items being covered. If coverage is not 100%, then more tests may be designed to test those items that were missed to increase coverage. – Độ đo coverage chỉ ra cấu trúc code được test bới bộ TC tự động, thể hiện % item được bao phủ, nếu coverate chưa đạt 100% thì cần tạo them các test.

2.3.4 Testing Related to Changes: Re-testing and Regression Testing (K2)

Re-testing – confirmation testing

• After a defect is detected and fixed, the software should be re-tested to confirm that the original defect has been successfully removed. – Sau khi 1 lỗi được phát hiện và sửa, PM nên được kiểm tra lại để kiểm chứng là lỗi ban đầu đã được loại bỏ.

1. Regression test

• Regression testing is the repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the change(s). – Regression test là hoạt động lặp lại của testing trên chương trình đã được test, sau khi chỉnh sửa, để đảm bảo ko còn lỗi nào xuẩt hiện hoặc phần thay đổi chưa được kiểm tra đến.
• These defects may be either in the software being tested, or in another related or unrelated software component. It is performed when the software, or its environment, is changed. – Các lỗi có thể còn xuất hiện trong phần đã được test hoặc những thành phần có liên quan, vì thể cần thực hiện regression test mỗi khi PM, hoặc môi trường thay đổi.
• The scope of regression testing is based on the risk of not finding defects in software that was working previously. – Phạm vi thực hiện regression test dựa trên xác định rủi ro của việc ko tìm thấy lỗi trong PM.

Regression test characteristics

• To look for any unexpected side-effects- Tìm kiếm những vùng mà ko mong đợi bị ảnh hưởng
• At any level (unit, integration, system, acceptance) – Test hồi quy thực hiện ở tất cả các level
• Well worth automating – Rất tốt khi được tự động hóa
• A developing asset but needs to be maintained – Một tài sản đang phát triển nhưng cần phải được duy trì
• Regression tests are performed – Test hồi quy được thực hiện khi:
  • After software changes, including faults fixed – Sau khi phần mềm được thay đổi theo yêu cầu, bảo gồm cả sửa lỗi
  • When the environment changes, even if application functionality stays the same – Khi môi trường thay đổi, ngay cả khi các chức năng vẫn như cũ
  • For emergency fixes (possibly a subset) – Đối với các bản sửa lỗi khẩn cấp (hoặc chỉ là một tập hợp con)

2.4  Maintenance Testing (K2)

• Maintenance testing is done on an existing operational system, and is triggered by modifications, migration, or retirement of the software or system. – Test bảo trì là thực hiện test trên HT đã tồn tại, nó chỉ giới hạn trong các phần được chỉnh sửa, chuyển đổi hoặc xoá bỏ của PM hoặc HT
• Maintenance testing (conversion testing) for:

• Migration (e.g., from one platform to another) should include operational tests of the new environment as well as of the changed software. – Test bảo trì cho việc chuyển đổi ( từ nền tảng này sang nền tảng khác) nên bao gồm cả test hệ điều hành của môi trường mới giống như là test các phần thay đổi của PM
• Migrated data from another application into the system being maintained – Test chuyển đổi dữ liệu từ ứng dụng khác được chuyển đổi sang cho HT đang đc bảo trì
• Retirement of a system or a part of system. – Test bảo trì cho 1 HT nghỉ hưu hoặc 1 phần của sản phẩm

• In addition test has been changed, maintenance testing includes regression testing to parts of the system that have not been changed. – Ngoài việc test những phần được thay đổi thì test bảo trì cũng bao gồm cả regression test những phần mà HT ko thay đổi
• The scope of maintenance testing is related to the risk of the change, the size of the existing system and to the size of the change.- Phạm vi test bảo trì dựa vào rủi ro của việc thay đổi, kích thước của HT cũ và kích thước của phần thay đổi.
• Depending on the changes, maintenance testing may be done at any or all test levels and for any or all test types. – Dựa vào sự thay đổi mà Test bảo trì có thể hoàn thành ở bất cứ khi nào, tất cả các level test, tất cả các loại hình test
• Determining how the existing system may be affected by changes is called impact analysis, and is used to help decide how much regression testing to do. – Việc xác định xem HT cũ bị ảnh hưởng như thế nào bởi các thay đổi đc gọi là phân tích ảnh hưởng, nó giúp cho việc ra quyết định test hồi quy bao nhiêu lần là đủ.
• Maintenance testing can be difficult if specifications are out of date or missing, or testers with domain knowledge are not available. – Test bảo trì sẽ khá khó khăn nếu các đặc tả bị quá cũ, thiếu thông tin hoặc Tester ko có kinh nghiệm với HT.