Ôn tập công nghệ phần mềm chương 9

Đối với những phần mềm thương mại, cần kiểm tra cho tất cả các hệ thống… Để phát hiện ra những tình huống mà chương trình xử lý không đúng, không thỏa đáng hoặc không phù hợp với đặc tả.

SOFTWARE TESTING

Table of Contents

Mục đích của Program Testing 2

Validation và Defect Testing 2

Mục tiêu của qui trình Testing 2

Validation Testing 2

Một test thành công thể hiện rằng một hệ thống đang hoạt đọng đúng với yêu mà nó cần phải thực hiện 2

Defect Testing 2

Black – Gray – White Box Testing 3

Giải quyết Coverage cho White Box Testing 4

Verification và Validation 5

Mối quan hệ giữa Verification và Validation (V&V) 5

Inspections và Testing 5

Software inspections: 6

Lợi ích của Inspections: 6

Inspections và testing 6

Những giai đoạn của testing: 7

Development Testing 7

Unit Testing 8

Chiến lược Testing 11

Testing là nhằm để chạy lại các chức năng mà phần mềm cần phải làm và tìm ra những nhược điểm trước khi đem vào sử dụng

Khi test một chương trình, chúng ta cần thực thi chương trình sử dụng những dữ liệu giả do tester đặc ra

Cần kiểm tra các lỗi, các điểm không bình thường hoặc những thông tin về phần non-functional ở kết quả thực thi

…

Testing là một phần của qui trình Geneneral Verification và Validation Process, và static validation process

Mục đích của Program Testing

Để chứng minh cho Developer và khách hàng rằng phần mềm đã đáp ứng đủ yêu cầu của Requirement

 Đối với những phần mềm đặc hàng, ít nhất cần có một test cho mỗi yêu cầu trong tài liệu Requirement Đối với những phần mềm thương mại, cần kiểm tra cho tất cả các hệ thống…

Để phát hiện ra những tình huống mà chương trình xử lý không đúng, không thỏa đáng hoặc không phù hợp với đặc tả

 Testing những nhược điểm của chương trình cần quan tâm đến việc xử lý khôn thỏa đáng của hệ thống như là crash, những tương tác không cần thiết đến các

hệ thống khác, tính toán sai và dữ liệu bị hư hỏng

Validation và Defect Testing

Mục đích thứ nhất dẫn đến Validation testing : chúng ta cần những hệ thống hoạt động một cách chính xác, sử dụng những test case – phản ánh được những nhu cầu

sử dụng của hệ thống

Mục đích thứ 2 dẫn đếnDefect Testing: những test case được thiết kế để tìm ra yếu điểm Test case trong defect testing không cần phải phản ánh những nhu cầu sử dụng bình thường của hệ thống (chạy những case sai coi nó làm sao ấy mà >.< nói dài dòng dịch mệt vãi)

Mục tiêu của qui trình Testing

Validation Testing

Để chứng minh cho Developer và khách hàng rằng phần mềm đã đáp ứng đủ yêu cầu của Requirement

Một test thành công thể hiện rằng một hệ thống đang hoạt đọng đúng với yêu mà nó cần phải thực hiện

Defect Testing

Để phát hiện ra những tình huống mà chương trình xử lý không đúng, không thỏa đáng hoặc không phù hợp với đặc tả

Một test thành công là một test làm cho hệ thống hoạt động sai và chỉ ra những yếu điểm của hệ thống

Black – Gray – White Box Testing

Black Box: Dữ liệu vào là những case phù hợp với requirement Kết quả so sánh lại với kết quả của requirement

White Box: Design elements -> Xác định xem hoạt động có như mong đợi hay không Gray Box: Kết hợp của Black Box và White Box

Kết quả trả về đúng nhưng line (3) sai rồi

Giải quyết Coverage cho White Box Testing

Assertion-based Testing: A white box testing

Trong nhiều trường hợp, assertion = invariant

 Xác nhận vào trong source code

 Định nghĩa assertion

 Đưa assertion vào trong source code

Verification và Validation

Verification:

"Are we building the product right” – Chúng ta đang xây dựng chương trình đúng?

Phần mềm cần phù hợp với đặc tả

Validation:

"Are we building the right product” – Chúng ta đang xây dựng đúng chương trình?

Phần mềm cần làm đúng những gì mà mà khách hàng yêu cầu

Mối quan hệ giữa Verification và Validation (V&V)

Mục đích của V&V là để xác lập độ tin cậy rằng hệ thống đã đầy đủ ‘fit for purpose’ Dựa vào mục tiêu của hệ thống, người dùng mong đợi(User expectations)

và môi trường thương mại (Marketting Environment)

 Mục tiêu hệ thống : Mức độ tun cậy phụ thược vào cấu trúc tổ chức của phần mềm

 User Expectatins : Người dùng có thể mong đợi ít hơn ở phần mềm

 Marketting Environment : Làm cho phần mềm được bán chạy có thể quan trọng hơn là tìm ra những yếu điểm của phần mềm

Inspections và Testing

Software inspection quan tâm đến việc phân tích những hệ thống tĩnh để tìm ra lỗi

Software testing quan tâm đến việc áp dụng và quan sát việc xử lý của sản phẩm

Software inspections:

Nghiên cứu trên mô hình với mục đích phát hiện ra những điểm bất thường và yếu điểm

Inspection không yêu cầu phải thực thi chương trình vì thế có thể được sử dụng trước khi hiện thực chương trình

Có thể sử dụng nhiều loại mô hình khác nhau của hệ thống như (đặc tả, thiết kể, cấu trúc dữ liệu, kiểm tra dữ liệu,…)

Ngoài ra còn có một số kỹ thuật khác để tìm ra lỗi của hệ thống

Inspection và testing bổ sung cho nhau và không trái ngược nhau trong kỹ thuật verification

Lợi ích của Inspections:

Trong khi testing, một lỗi này có thể che khuất đi lỗi khác Nhưng trái lại, inspection

là một quá trình tĩnh, nên ta không cần quan tâm đến các tương tác giữa các lỗi Một phiên bản chưa hoàn thành của một hệ thống có thể được inspected mà không tốn thêm chi phí phát sinh Nếu một chương trình chưa hoàn tất, ta cần phải phát triển những bộ test riêng biệt để test cho những phần đã hoàn thành

Để tìm kiếm những yếu điểm của hệ thống, inspection có thể hướng đến những thuộc tính rộng hơn của một chương trình như phù hợp tiêu chẩn, portability, dễ bảo trì

Inspections và testing

Cả hai đều được sử dụng trong qui trình V & V

Inspection có thể kiểm tra thỏa mãn đặc tả nhưng không bắt buộc phải thỏa mãn nhu cầu thực tế của khách hàng

Inspection không kiểm tra được cả chi tiết non-functional như là performance, dễ sử dụng, …

Những giai đoạn của testing:

Development testing là hệ thống được test trong quá trình phát triển phần mềm để tìm ra bug và yếu điểm

Release Testing là những team testing bắt đầu test một phiên bản hoàn chỉnh của hệ thống trước khi giao cho khách hàng

User Testing, người dùng sử dụng phần mềm test hệ thống trên môi trường làm việc của chính họ

Development Testing

Development testing bao gồm tất cả hoạt động testing được thực hiện bởi team developing

hệ thống

Unit Testing: những đơn vị chương trình độc lập hoặc object class sẽ được tested Unit Testing nên tập trung vào test những phần functionnall của object hoặc method Component Testing: những đơn vị độc lập được tổng hợp lại thành những thành phần phức Nên tập trung vào test theo interface của component

System Testing những component được tổng hợp lại và được test tất cả Phần này nên tập trung vào test những tương tác của các component

Unit Testing

Unit Testing là quá trình testing những thành phần riêng lẻ của hệ thống một cách độc lập với các thành phần khác

Đây là một quá trình defect testing

Một Unit có thể là:

 Hàm hoặc phương thức trong một đối tượng

 Object Classes với nhiều thuộc tính hoặc phương thức

 Những thành phần phức với những interface đã được định sẵn để truy xuất hàm chức năng

Perform Method Testing

1 Kiểm tra hoạt động với những tham số bình thường

2 Kiểm tra hoạt động với những tham số giới hạn

3 Kiểm tra hoạt động với những tham số bên ngoài

4 Chắc chắn rằng tất cả các câu lệnh được thực hiện

5 Kiểm tra đường đi, bao gồm các tất cả các nhanh của câu lệnh

6 Kiểm tra viêc sử dụng các câu lệnh gọi đối tượng

7 Kiểm tra việc quản lý cấu trúc dữ liệu

8 Kiểm tra việc quản lý tập tin

9 Kiểm tra các vòng lặp có được ngưng lại hay không

10 Kiểm tra việc ngừng bất thường của vòng lặp

11 Kiểm tra việc ngừng lại của câu lệnh đệ qui

12 Kiểm tra việc ngừng bất thường của lệnh gọi đệ qui

13 Kiểm tra việc quản lý các điều kiện xảy ra lỗi

14 KIểm tra thời gian và đồng bộ

15 Kiểm tra phần cứng

Class Unit Test

1 Áp dụng việc kêt hợp các phương thức

Thường dùng 2 đến 5 methods

Chọn những dãy kết hợp thông thường

Bao gồm những dãy sẽ dẫn đến defects

Yêu cầu tính toán bằng tay để đưa ra kết quả

2 Tập trung unit test trên các thuộc tính

Khởi tạo, thực thi các dãy method ảnh hưởng đến thuộc tính này

3 Kiểm tra việc các hằng không thay đổi

Gán giá trị khởi tạo

Thực thi chuổi các function

4 Kiểm tra lại việc hằng có thay đổi

Kiểm tra các đối tượng strong các trạng thái mong đợi

Dự định các trạng thái trong chuỗi sự kiện

Khởi tạo các đối tượng trong trạng thái khởi tại bằng cài đặt các biến

Cung cấp sự kiện và kiểm tra việc chuyển trạng thái

Object Class Testing

Kiểm tra hoàn chỉnh những gì liên quan đến Class

 Kiểm tra những hoạt động liên qua đến object

 Cài đặt và sử dụng những object attribute

 Áp dụng đối tượng vào những trạng thái có thể xảy ra

Thừa kế làm cho việc thiết kế object test trở nên phức tạp hơn, vì các thông tin để test không còn local nữa

WEATHER STATION TESTING

 Cần phải tạo test case dành cho reportWeather, calibrate, test, startup, shutdown

 Sử dụng mô hình trạng thái, định ra các chuỗi chuyển đổi trạng thái để test and các chuỗi sự kiện để dẫn đến việc chuyển trạng thái

 Ví dụ:

Shutdown -> Running -> Shutdown

Configuring -> Running -> Testing -> Transmitting -> Running

Running -> Collecting -> Running -> Summarizing -> Transmitting -> Running

Testing tự động

Bất cứ khi nào có thể, unit testing nên được tự động test không cần can thiệp bằng tay

Khi tự động unit test, cần phải tạo ra một bộ test tự động, có thể sử dụng Junit để viết và chạy chương trình test

Unit testing frameworks cung cấp test cho nhiều loại class, ta dùng những bộ test này để tạo ra những bộ test riêng Framework này có thể chạy tât cả các test mà mình implement và báo cáo lại thông thường qua GUI, khi thành công

Những thành phần của test tự động

Phần setup, phần này ta cần khởi tạo cho hệ thống những test case, đưa vào những input và expected ouput

Phần gọi, phần này gọi các đối tượng hoặc các method cần tested

Phần xác nhận, khi so sánh kết quả của phần call với phần expected output, xác nhận là true nếu test thành công, ngược lai nếu failed

Tác dụng của Unit Test

Test cần cần phải thể hiện được những thành phần đang test cần phải làm

Nếu có yếu điểm ở thành phần đó, nó cần phải được chỉ ra bởi một test case

Vì thế có 2 dạng của unit test case:

 Dạng đầu tiên nên phản ánh được những hoạt động bình thường của chương trình và nên thể hiện được rằng các thành phần hoạt động theo như mong đợi

 Dạng thứ 2 là dạng test case dựa trên kinh nghiệm test, chỗ nào thường dẫn ra lỗi Vì thế cần phải có các test case không bình thường để kiểm tra rằng các tiến trình hoạt động chính xác và không bị crash thành phần đó

Chiến lược Testing

Phân vùng testing: cần phân ra các nhóm input có những đặc tính giống nhau và được thực hiện cùng một cách

Testing theo những chức năng: dựa vào những chức năng mà phần sử dụng test case