Nội dung:

1.1 Why is Testing Necessary (K2)- Tại sao phải testing

1.2 What is Testing? K2)- Testing là gì

1.3 Seven Principles of Testing – 7 nguyên lý cơ bản của testing

1.4 Fundamental test process – Quy trình và giai đoạn kiểm thử phần mềm

1.5 Psychology of testing -Khía cạnh khác của kiểm thử phần mềm

1.1 Why is Testing Necessary (K2)- Tại sao phải testing

 1.1.1 Software Systems Context (K1) – Ngữ cảnh về hệ thống phần mềm

• Software systems are an integral part of life, from business applications (e.g., banking) to consumer products (e.g., cars).

Phần mềm là 1 phần của cuộc sống hiện đại, từ những phần mềm nghiệp vụ đến những sản phẩm phục vụ con người

• Most people have had an experience with software that did not work as expected.

Hầu hết mọi người đều có lúc trải qua việc PM làm việc ko đúng mong đợi

• Software that does not work correctly can lead to many problems, including loss of money, time or business reputation, and could even cause injury or death.

Phần mềm làm việc ko chính xác có thể dẫn đến nhiều rắc rối, ví dụ như mất tiền, thời gian, quan hệ, hoặc mạnh hơn là gây ra chấn thương và cái chết

1.1.2 Causes of Software Defects (K2) – Nguyên nhân gây ra lỗi

• As we all are human beings and human beings make mistakes during development à Chúng ta đều là con người và con người thì có thể nhầm lẫn trong quá trình phát triển phần mềm
• Error: a human action that produces an incorrect result – một hành động của con người tạo ra một kết quả không chính xác.
• Fault: a manifestation of an error in software – một biểu hiện của một lỗi trong phần mềm:
• Also known as a defect or bug- Được biết đến như defect hoặc bug
• If executed, a fault may cause a failure – Khi chạy phần mềm, fault có thể gây ra failure
• Failure: deviation of the software from its expected delivery or service – Failure là độ lệch giữa phần mềm thực tế sai khác với mong đợi.
• Some of the errors do not impact much on our day to day life and can be ignored, however some errors are so severe that they can break the whole system or software. – Một lỗi ko ảnh hưởng đến cuộc sống hàng ngày và có thể bỏ qua, tuy nhiên một vài lỗi khá nghiêm trọng có thể gây phá vỡ toàn hệ thống.

Why do faults occur in software? – Tại sao lại xảy ra lỗi trong phần mềm

• Software is written by human beings – Phần mềm được viết bởi con người:
• Who know something, but not everything – Con người có giới hạn về kiến thức
• Who have skills, but aren’t perfect – Con người thiếu kỹ năng
• Who do make mistakes (errors) – Con người tạo ra nhầm lẫn
• Under increasing pressure to deliver to strict deadlines – Chịu sức ép rất lớn để bàn giao sản phẩm đúng hạn
• No time to check but assumptions may be wrong – Thiếu thời gian để kiểm tra
• Systems may be incomplete – Hệ thống chưa hoàn thành

Failures must be corrected in the software- Failures bắt buộc phải sửa trong phần mềm:

• It is not just defects that give rise to failure.

Không phải tất cả defect đều dẫn đến failure

• Failures can also be caused by environmental conditions as well: for example, a radiation burst, a strong mag- netic field, electronic fields, or pollution could cause faults in hardware or firmware.

Failures cũng có thể gây ra bởi các điều kiện môi trường

• Failures may also arise because of human error in interacting with the software, perhaps a wrong input value being entered or an output being misinterpreted.

Failures cũng có thể sinh ra bởi thao tác sai của con người, có thể là nhập input sai hoặc 1 output được biên dịch sai

• Failures may also be caused by someone deliberately trying to cause a failure in a system – malicious damage.

Failures cũng có thể bởi ai đó cố ý làm cho hệ thống bị lỗi

When do defect arise?

What is the cost of defect?

• The cost of finding and fixing defects rises considerably across the life cycle

Các chi phí tìm kiếm và sửa chữa các lỗi tăng lên đáng kể trong suốt vòng đời

• Poor quality software costs more to use – Phần mềm có chất lượng kém mất chi phí nhiều hơn để sử dụng
  • Users take more time to understand what to do – Người dùng mất thời gian nhiều hơn để hiểu những gì để làm
  • Users make more mistakes in using it – Người dùng thực hiện nhiều sai phạm trong khi sử dụng nó
  • Morale suffers – Gây áp lực về tinh thần
  • Lower productivity – Năng suất thấp

1.1.3 Role of Testing in Software Development, Maintenance and Operations(K2)

Vai trò của testing trong phát triển, duy trì và vận hành phần mềm

• Rigorous testing of systems and documentation can help to reduce the risk of problems occurring during operation and contribute to the quality of the software system, if the defects found are corrected before the system is released for operational use.

Test một cách cẩn trọng HT và tài liệu có thể giúp giảm rủi ro cho các vấn đề có thể xảy ra trong quá trình vận hành PM và đảm bảo được chất lượng của HT, nếu lỗi được tìm và sửa trước khi HT được phát hành để sử dụng.

 

• Software testing may also be required to meet contractual or legal requirements, or industry-specific standards.

Kiểm thử PM cũng là 1 yêu cầu trong hợp đồng và các yêu cầu pháp lý hoặc chuẩn công nghiệp.

1.1.4 Testing and Quality (K2)

• Testing measures software quality -Testing đo đạc được chất lượng của phần mềm.

Ví dụ: Chất lượng của Nhật: 1bug/ 1000KLOC (K=1000 Line of code), 15/ KLOC,

• Testing can find faults; when they are removed, software quality ( and possibly reliability) is improved -Testing có thể tìm ra lỗi; khi lỗi được loại bỏ thì chất lượng ( độ tin cậy) được cải tiến

What does testing test – Test để làm gì?

• System function, correctness of operation

Đảm bảo các các thực hiện, chức năng của hệ thống chạy đúng

• Non-functional qualities: reliability, usability, maintainability, reusability, testability,etc. Đảm bảo các chất lượng của hệ thống: độ tin cậy, tính sử dụng, bảo trì, tái sử dụng, khả năng test…
• Testing is a part of quality assurance

Testing là 1 phần của Đảm bảo chất lượng

• We can measure the quality of software in terms of defects found for both functional and non-functional software requirements and characteristics

Chất lượng được đo đạc bằng lỗi được tìm thấy trong các yêu cầu và đặt tính về chức năng và phi chức năng

Ví dụ độ đo:

Công sức tìm lỗi: số lỗi/ thời gian bỏ ra

Tỷ lệ lỗi lọt sang KH= số lỗi KH tìm đc / Tổng số lỗi ( đội dự án + KH)

• Testing can give confidence in the quality of a software if it finds few or no defects and we have good test designs

Testing mang đến sự tự tin về chất lượng khi lỗi được tìm thấy ít hoặc ko có

• By learning lessons from previous projects, we can improve the process => Improve the quality of future system

Bằng các học các bài học kinh nghiệm từ dự án trước chúng ta cải tiến được quy trình từ đó cải tiến chất lượng cho HT trong tương lai

1.1.5 How Much Testing is Enough? (K2)

It depends on RISK– phụ thuộc vào RISK

• Risk of missing important faults – Rủi ro của việc không nhìn thấy các lỗi quan trọng
• Risk of incurring failure costs – Rủi ro của việc phát sinh chi phí lỗi
• Risk of releasing untested or under-tested software – Rủi ro của việc phát hành phần mềm chưa được kiểm tra
• Risk of losing credibility and market share – Nguy cơ mất uy tín và thị trường
• Risk of missing a market window – Nguy cơ thiếu một cánh cửa thị trường
• Risk of over-testing, ineffective testing – Rủi ro trong việc test quá mức, test không hiệu quả

Test time will always be limited – Using RISK to determine -Thời gian test luôn bị giới hạn– Sử dụng RISK để xác định:

• What to test first – Test gì trước
• What to test most – Test gì nhiều hơn
• How thoroughly to test each item – Làm thế nào để kiểm tra kỹ lưỡng từng hạng mục
• What not to test ( this time) – Cái gì không test
• Allocate the time available for testing by prioritising testing …- Phân bố thời gian hợp lý cho việc testing bằng việc phân thứ tự ưu tiên

1.2 What is Testing? K2)- Testing là gì

What is testing?

• A common perception of testing is that it only consists of running tests, i.e., executing the software. This is part of testing, but not all of the testing activities.

Thường mọi người hiểu khái niệm test chỉ là chạy test, chạy phần mềm nhưng đó chỉ là 1 phẩn ko phải tất cả các hoạt động test

• Test activities exist before and after test execution. These activities include planning and control, choosing test conditions, designing and executing test cases, checking results, evaluating exit criteria, reporting on the testing process and system under test, and finalizing or completing closure activities after a test phase has been completed.

Các hoạt động test tồn tại trước và sau khi chạy PM bao gồm: lên kế hoạch và kiểm soát, chọn điều kiện test, thiết kế và chạy test case, kiểm tra kết quả, đánh giá tiêu chí kết thúc, báo cáo trong quy trình test và các hoạt động đóng sau khi giai đoạn test hoàn thành.

• Testing also includes reviewing documents (including source code) and conducting static analysis.

Test thì bao gồm cả review tài liệu, source code, phân tích tĩnh

• Both dynamic testing and static testing can be used as a means for achieving similar objectives, and will provide information that can be used to improve both the system being tested and the development and testing processes.

Cả dynamic và static testing được sử dụng đồng thời để đạt được mục đích giống nhau và sẽ cung cấp thông tin để cải tiến HT đang đc test và các quy trình

Test Objectives:

Testing can have the following objectives- Test gồm các mục tiêu sau:

1. Finding defects – Tìm lỗi
2. Gaining confidence about the level of quality -Thu thập sự tự tin vào chất lượng
3. Providing information for decision-making – Cung cấp thông tin để ra quyết định
4. Preventing defects – Ngăn ngừa lỗi

• The thought process and activities involved in designing tests early in the life cycle (verifying the test basis via test design) can help to prevent defects from being introduced into code.

Quy trình và các hoạt động test được thực hiện sớm trong chu kỳ ( vd kiểm tra các tài liệu test) giúp ngăng ngừa lỗi xảy ra trong code.

• Reviews of documents (e.g., requirements) and the identification and resolution of issues also help to prevent defects appearing in the code.

Hoạt động review tài liệu ( TL yêu cầu) và việc phát hiện và giải quyết các vấn đề phát sinh cũng giúp cho ngăn ngừa lỗi xuất hiện trong code

Different viewpoints in testing take different objectives into account

Có các mục đích khác nhau trong từng giai đoạn test:

• In development testing (e.g., component, integration and system testing), the main objective may be to cause as many failures as possible so that defects in the software are identified and can be fixed.

Test trong giai đoạn phát triển PM  mục đích chính là tìm được càng nhiều lỗi có thể và có thể sửa sớm

• In acceptance testing, the main objective may be to confirm that the system works as expected, to gain confidence that it has met the requirements.

Test trong giai đoạn nghiệm thu là để xác nhận xem hệ thống đã làm việc đúng như mong đợi chưa, thu thập sự tự tin rằng là phần mềm đã đúng với yêu cầu.

• In some cases the main objective of testing may be to assess the quality of the software (with no intention of fixing defects), to give information to stakeholders of the risk of releasing the system at a given time.

Trong một vài TH thì là để đánh giá chất lượng  của PM, để đưa ra thông tin cho nhà đầu tư về rủi ro của việc phát hành HT tại thời điểm đó

• Maintenance testing often includes testing that no new defects have been introduced during development of the changes.

Test trong giai đoạn bảo trì phải bao gồm test để đảm bảo ko có lỗi mới xuất hiện trong quá trình thay đổi, chỉnh sửa

• During operational testing, the main objective may be to assess system characteristics such as reliability or availability.

Trong quá trình test vận hành thì mục đính chính là đánh giá các đặc tính chất lượng của hệ thống như độ tin cậy, tính sẵn sàng

Debugging and testing are different.

• Dynamic testing can show failures that are caused by defects. Debugging is the development activity that finds, analyzes and removes the cause of the failure..

Test động tìm ra các hỏng học gọi là lỗi. Debugging là hoạt động của phát triển phẩn mềm để tìm, phân tích và sửa nguyên nhân gây ra hỏng hóc.

• Subsequent re-testing by a tester ensures that the fix does indeed resolve the failure. The responsibility for these activities is usually testers test and developers debug

Và tester phải thực hiện test lại để đảm bảo là các hoạt động sửa lỗi được giải quyết triệt để. Nên khi phân vai trò ta thấy tester là người thực hiện test, developer thực hiện debug

1.3 Seven Principles of Testing – 7 nguyên lý cơ bản của testing

1. Testing shows presence of defects – Testing chỉ ra lỗi
2. Exhaustive testing is impossible – Test toàn bộ là không thể
3. Early testing – Test sớm
4. Defect clustering – Cụm lỗi
5. Pesticide paradox – Hiệu ứng thuốc trừ sâu
6. Testing is context dependent – Testing trong ngữ cảnh độc lập
7. Absence of error fallacy – Vắng mặt của lỗi

Testing shows presence of defects

• Testing can show that defects are present, but cannot prove that there are no defects.

Kiểm thử có thể chỉ ra lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi.

• Testing reduces the probability of undiscovered defects remaining in a software but, even if no defects are found, it is not a proof of correctness

Kiểm thử làm giảm xác suất của các lỗi chưa được khám phá vẫn còn trong phần mềm nhưng ngay cả khi không có 1 lỗi nào được tìm thấy, nó cũng không phải là một bằng chứng về tính đúng đắn phần mềm.

Exhaustive testing is impossible – Complete test

• Test everything ( all combination of inputs and preconditions) is not feasible

Kiểm tra tất cả mọi thứ (tất cả các kết hợp của đầu vào và điều kiện) là không khả thi

• Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts

Thay vì kiểm thử tất cả, phân tích rủi ro và sắp xếp thứ tự ưu tiên nên được sử dụng để tập trung trong testing.

Early testing

• Testing activities should start as early as possible in the software or software development life cycle and should focus on defined objectives

Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong chu kỳ phần mềm hoặc toàn bộ vòng đời phát triển và nên tập trung vào mục tiêu được xác định

• Perform the test design and review activities early can finds defects early on when they are cheap to find and fix.

Thực hiện các test và review càng sớm thì lỗi càng được phát hiện sớm khi đó ít tốn công để để tìm và sửa chữa.

Defect clustering: defect density

• A small numbers of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures

Một số lượng nhỏ của các mô-đun thường có chứa hầu hết các lỗi được phát hiện trong quá trình kiểm thử trước khi phát hành, hoặc là chịu trách nhiệm cho hầu hết các thất bại của hệ thống.

• Rule 80/20: Module core often contains 80% defects

Quy tắc 80/20: Module lõi thường chứa 80% lỗi

Pesticide paradox

• If the same tests are repeated over and over again, no new defects can be found – Nếu các kiểm thử tương tự được lặp đi lặp lại nhiều lần, không có lỗi mới nào có thể được tìm thấy.
• To overcome this pesticide paradox, test cases need to be regularly reviewed and revised; new and different tests need to be written to exercise different parts of the software to find potentially more defects

Để khắc phục nghịch lý thuốc trừ sâu này, các test case cần phải được thường xuyên rà soát và sửa đổi; Test mới và khác đi để tìm ra nhiều lỗi tiềm ẩn hơn.

Testing is context dependent

• Testing is done differently in different context

Kiểm thử được thực hiện khác nhau trong bối cảnh khác nhau

• Ex: Safety-critical software is tested differently from an ecommerce site

Ví dụ: phần mềm an toàn quan trọng được kiểm tra khác nhau  với một trang web thương mại điện tử

Absence of error fallacy

• Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations

Tìm và sửa lỗi không giúp gì nếu hệ thống được xây dựng là không sử dụng được và không đáp ứng nhu cầu và mong đợi của người sử dụng