Software Engineering

INT2208E
Lecture 08: Software Testing

1
 Last class…

• Design & Implementation

• Discussion: UI/UX Design
• Discussion: Clean code

2
 Questions (10’)

• Build vs. Buy Consideration:

• Project: Content Management System (CMS) for a University Website
• Scenario: Your university is looking to revamp its website. You need a system to manage
content creation, editing, and publishing across various departments. This includes news
articles, faculty profiles, course listings, and event calendars.
• Analyze the pros and cons of “Build” and “Buy” and give the decision factors for this scenario.

3
 Discussion

• Security vulnerabilities in the development process

• Data privacy regulations and compliance
• Scaling applications for high traffic and user base
• Cloud-native development challenges

4
 Discussion

• Buying:
• Building • Pros
• Pros: • Faster Time to Market
• Customization • Cost-effective (purchasing a Commercial off-the-
• Integration shelf solution)
• Data Ownership • Support (ongoing support and security updates
• Cons provided by vendors)
• Cost • Cons:
• Time • Customization
• Security • Integration
• Vendor lock-in

5
 Today…

• Software testing

6
 Software Quality

Software Quality

Functionality Usability Security Scalability Compliance

Reliability Performance Maintainability Compatibility

7
Software Testing

8
V-model
 Và kía cạnh chức năng

Software Quality

Functionality Usability Security Scalability Compliance

Reliability Performance Maintainability Compatibility

10
Lỗi trong chương trình phần mềm

11
Ví dụ về lỗi đơn giản trong mã nguồn

12
Bug đầu tiên, 9/9/1947 bởi Grace Hopper

13
 Một vài con số thực tế…

• Chỉ có 32% dự án phần mềm được coi là thành công (đầy đủ chức năng,
đúng thời hạn, đủ kinh phí)

• Trung bình, cứ mỗi 1.000 dòng lệnh có 10-15 lỗi

• 47.000 developers của Microsoft tạo ra khoảng 30.000 lỗi mỗi tháng

14
 Ví dụ về lỗi trong chương trình phần mềm

• Chiến hạm USS Yorktown (1997)

chìm dưới nước suốt 3 giờ
• Nguyên nhân: Lỗi chia cho 0

15
 Millennium Bug/Y2K Bug

• Vi mạch đồng hồ điện tử kiểu cũ

được lập trình để thay đổi chỉ 2
chữ số cuối của năm.
• 19XY → 1999
• 1999 → 1900

16
17
Gangnam Style Broke Youtube

18
Uber is at fault for fatal self-driving crash

19
 Ví dụ về lỗi trong chương trình phần mềm

• Lỗi phần mềm trên máy bay Boeing 737 Max

• Gây ra 2 vụ rơi máy bay: Indonesia, 10/2018 và Ethiopia 03/2019
• 346 người chết

20
Tìm lỗi thậm trí mệt mỏi hơn coding

21
 Thật không?

Tìm k số lớn nhất trong mảng arr

Discount! Elasticsearch

23
 Code của bạn đã đủ tốt?
Kỹ năng của bạn đã đủ tốt?

24
Phương pháp giảm thiểu lỗi

25
 Rà soát thủ công

• Rất khó để đánh giá tiến độ

• Có thể bỏ lỡ các lỗi phần mềm

26
Các phương pháp tự động giảm thiểu lỗi

28
 Các phương pháp tự động giảm thiểu lỗi

• Phân tích tĩnh: Xác định các loại lỗi cụ thể trong phần mềm bằng cách
quét các mẫu đáng ngờ trong code
• Hạn chế: (1) Giới hạn về loại lỗi và (2) Nhiều cảnh báo giả (false positives)

29
Các phương pháp tự động giảm thiểu lỗi

30
31
 Sonarlint: False positive

// reports S2259 'chosenConnection' is null on at

least one execution path.

32
 Các phương pháp tự động giảm thiểu lỗi

• Kiểm thử: Đưa input vào phần mềm và chạy thử để kiểm tra hành vi của
phần mềm có như kì vọng không
• Hạn chế: (1) Không thể có được tất cả các khả năng thực thi có thể, (2)
Cần đầu ra kì vọng để kiểm tra
33
Các phương pháp tự động giảm thiểu lỗi

34
35
 Các phương pháp tự động giảm thiểu lỗi

• Kiểm chứng: Xem xét tất cả các khả năng thực thi của chương trình và
chứng minh tính đúng đắn chương trình
• Hạn chế: (1) Khó có đặc tả, (2) Hầu hết các chương trình trong thực tế
đều quá đắt để chứng minh
36
Các phương pháp tự động giảm thiểu lỗi

Java Pathfinder
Simulink Design
37
Verifier
Alloy: Example

38
Alloy: Example

39
Counter example (aka. Flaw)
Kiểm thử, tại sao?

43
 Tại sao…?

• KIỂM THỬ vs. RÀ SOÁT CODE

• Đáng tin cậy hơn rà soát code thủ công

• KIỂM THỬ vs. PHÂN TÍCH TĨNH

• Ít cảnh báo giả và áp dụng được cho nhiều loại lỗi hơn

• KIỂM THỬ vs. KIỂM CHỨNG

• Dễ dàng mở rộng và áp dụng cho nhiều chương trình

44
Kiểm thử chương trình đơn giản

45
Kiểm thử một trình duyệt

46
V-model
 Software Quality

Software Quality

Functionality Usability Security Scalability Compliance

Reliability Performance Maintainability Compatibility

48
 Reliability

• Reliability: The software performs

consistently and functions as expected
without frequent crashes or errors
• Metrics:
• Mean Time Between Failures (MTBF)
• Mean Time To Repair (MTTR)
• Downtime and Uptime
• Availability = Uptime/(Uptime+Downtime) ~
MTBF/(MTBF+ MTTR)

• Testing:
• Stress Testing
• Load Testing
• Endurance Testing

49
 Availability of 99s

HOW TO BUILD TRUST AND PROVIDE

EVIDENCE FOR THIS REQUIREMENT?

50
 Usability

• (Un)Moderated Usability Testing:

• Involves recruiting participants who represent your target users.
• A facilitator guides them through tasks using the application while observing their actions and
collecting feedback through verbal prompts and screen recordings.

• Usability Heuristics Evaluation:

• A team of usability experts evaluates the application interface against established usability
principles (Nielsen heuristics) to identify potential usability issues.

• A/B Testing:
• Presents users with two different versions of a user interface element (e.g., button placement,
layout) and analyzes which version generates better user engagement or task completion rates.

52
How about data privacy?

54
 How about data privacy?

• Applicable regulations:
GDPR (Europe), CCPA (California), or industry-specific regulations

• Discuss/Confirm with Customers and Implement Data Privacy Features:

• Data minimization
• Data access control
• Data encryption
• User consent management
• Data breach notification

• Conduct Data Privacy Testing

• Static code analysis
• Penetration testing: Simulate cyberattacks to uncover weaknesses in your system's security controls
and data access mechanisms.
• Privacy impact assessment (PIA): Conduct a PIA to assess the potential privacy risks associated with
your system's data processing activities.
• Data flow mapping: Map the flow of user data throughout your system, pinpointing where data is
collected, stored, processed, and shared

55
 Test-driven development

• Test-driven development (TDD) is an approach to program development in

which you inter-leave testing and code development.
• Tests are written before code and ‘passing’ the tests is the critical driver of
development.

56
 Key points

• Software Quality
• Software Testing: What, Why, and How
• Functional and Non-functional testing
• Test-driven Development

57
 Next class

• Software Maintenance
• ???

58