Đã đăng vào thg 3 26, 2015 5:39 CH 32 phút đọc

6.8K

Tìm hiểu chương hai và chương ba của giáo trình ISTQB_CTFL_Syll 2011

Bài đăng này đã không được cập nhật trong 3 năm

Trong bài viết "Tìm hiểu chương một và chương hai của giáo trình ISTQB_CTFL_Syll 2011" (http://viblo.framgia.vn/LeThi/posts/3OEqGj0lR9bL) mình đã tìm hiểu về chương một và một nửa chương hai của giáo trình. Trong bài viết này mình sẽ tiếp tục trình bày phần còn lại của chương hai và chương ba.

2.3: Các loại kiểm thử - Test types

Các định nghĩa

Kiểm thử hộp đen - Black-box testing : Kiểm thử chức năng hoặc phi chức năng, không tham chiếu đến cấu trúc bên trong của thành phần hoặc hệ thống.
Độ bao phủ mã - Code coverage : Một phương pháp nhằm xác định các bộ phận của phần mềm đã được thực hiện bằng các bộ kiểm thử(test suite) và phần nào không được thực hiện. Ví dụ : bao phủ câu lệnh (statement coverage), bao phủ quyết định (decision coverage) hoặc bao phủ điều kiện (condition coverage).
Kiểm thử chức năng - Functional testing : Kiểm thử dựa trên sự phân tích các đặc điểm kỹ thuật của các chức năng , của một thành phần hoặc hệ thống.
Kiểm thử khả năng tương tác - Interoperability testing : Quá trình kiểm thử để xác định khả năng tương tác của một sản phẩm phần mềm.
Kiểm thử độ tải - Load testing : Một loại của kiểm thử hiệu năng thực hiện để đánh giá hành vi của một thành phần hoặc hệ thống với việc tăng độ tải (load). ví dụ: số người cùng sử dụng, số các giao dịch, để xác định những gì được tải mà có thể xử lý bởi các thành phần hoặc hệ thống .
Kiểm thử bảo trì - Maintainability testing : Các quá trình kiểm thử để xác định khả năng bảo trì của một sản phẩm phần mềm.
Kiểm thử hiệu năng - Performance testing : Quá trình kiểm thử để xác định hiệu năng của một sản phẩm phần mềm.
Kiểm thử tính di động - Portability testing : Quá trình kiểm thử để xác định tính di động của một sản phẩm phần mềm.
Kiểm thử độ tin cậy - Reliability testing : Quá trình kiểm thử để xác định độ tin cậy của một sản phẩm phần mềm.
Kiểm thử bảo mật - Security testing : Kiểm thử để xác định tính bảo mật của sản phẩm phần mềm.
Stress testing : Một loại của kiểm thử hiệu năng thực hiện để đánh giá một hệ thống hoặc thành phần tại hoặc vượt trên giới hạn dự kiến hoặc độ tải công việc yêu cầu, hoặc giảm nguồn tài nguyên như là truy cập vào bộ nhớ hoặc máy chủ (server).
Kiểm thử tính khả dụng - Usability testing : Kiểm thử để xác định phạm vi mà các sản phẩm phần mềm được hiểu rõ, dễ dàng tìm hiểu, dễ dàng hoạt động và thu hút người sử dụng trong các điều kiện quy định.
Kiểm thử hộp trắng - White-box testing : Kiểm thử dựa trên sự phân tích cấu trúc nội bộ của thành phần hoặc hệ thống.

Có các loại kiểm thử :

Kiểm thử chức năng
Kiểm thử phi chức năng
Kiểm thử cấu trúc/ kiến trúc phần mềm
Kiểm thử liên quan đến thay đổi

2.3.1 : Kiểm thử chức năng - Testing of Function (Functional Testing)

Kiểm thử chức năng là kiểm thử những "cái gì" mà hệ thống thực hiện.
Các chức năng mà một hệ thống , hệ thống con hoặc một thành phần thực hiện có thể được mô tả trong:
- Các yêu cầu đặc điểm kỹ thuật (Requirements specification)
- Các trường hợp sử dụng (use cases)
- Một đặc tả chức năng
- Hoặc có thể không có tài liệu.
Kiểm thử chức năng được dựa trên các chức năng và tính năng ( được mô tả trong tài liệu hoặc được hiểu bởi những người kiểm thử ( testter)) và khả năng tương tác của tester với hệ thống.
Được thực hiện ở tất cả các mức độ kiểm thử ( test levels).
Các kỹ thuật dựa trên đặc tả yêu cầu kỹ thuật có thể được sử dụng để lấy các điều kiện kiểm thử và các trường hợp kiểm thử từ các chức năng của phần mềm hoặc hệ thống.
Kiểm thử chức năng xem xét các hành vi bên ngoài của phần mềm . Kỹ thuật phổ biến sử dụng trong kiểm thử chức năng là kiểm thử hộp đen ( black-box testing).
Một loại của kiểm thử chức năng là kiểm thử bảo mật, điều tra các chức năng liên quan đến việc phát hiện các mối đe dọa như vius... Một loại khác của kiểm thử chức năng là kiểm thử tương tác để đánh giá khả năng của sản phẩm phần mềm tương tác với một hoặc nhiều thành phần cụ thể hoặc hệ thống.

2.3.2: Kiểm thử phi chức năng các đặc tính phần mềm - Testing of Non-functional Software Characteristics

Kiểm thử phi chức năng là kiểm thử “ làm thế nào” hệ thống làm việc tốt và nhanh hơn .
Kiểm thử phi chức năng bao gồm
- Kiểm thử hiệu năng (performance testing)
- Kiểm thử độ tải (load testing)
- Kiểm thử stress (stress testing)
- Kiểm thử tính khả dụng (usability testing)
- Kiểm thử bảo trì (maintainability testing)
- Kiểm thử độ tin cậy (reliability testing)
- Kiểm thử tính di động (portability testing)
Kiểm thử phi chức năng có thể thực hiện ở tất cả các mức độ kiểm thử. Nó mô tả các kiểm thử cần thiết để đo lường các đặc tính của hệ thống và phần mềm như là thời gian trả lời của hệ thống.
Kiểm thử phi chức năng xem xét các hành vi bên ngoài của phần mềm .

2.3.3: Kiểm thử cấu trúc/ kiến trúc phần mềm - Testing of Software Structure/Archit cture (Structural Testing)

Kiểm thử cấu trúc ( white -box) có thể được thực hiện ở tất cả các mức độ kiểm thử
Kỹ thuật kiểm thử cấu trúc được sử dụng tốt nhất sau các kỹ thuật dựa trên các đặc điểm kỹ thuật( specification-based). Giúp đo lường kỹ lưỡng kiểm thử thông qua đánh giá độ bao phủ của loại cấu trúc.
Độ bao phủ là phạm vi mà một cấu trúc đã được thực hiện bởi một bộ kiểm thử, tính theo phần trăm của các mục đã được bao phủ. Nếu độ bao phủ không phải là 100% các kiểm thử sẽ được thiết kế để kiểm tra các mục đã bị bỏ lỡ để tăng độ bao phủ.
Kiểm thử cấu trúc thực hiện tại tất cả các mức độ kiểm thử, nhưng đặc biệt là kiểm thử thành phần (component testing) và kiểm thử tích hợp thành phần.
Phương pháp kiểm thử cấu trúc cũng có thể áp dụng ở các mức độ như kiểm thử tích hợp hệ thống hoặc kiểm thử chấp nhận.
Kỹ thuật sử dụng : Kỹ thuật dựa vào cấu trúc . các mô hình luồng điều khiển thường được sử dụng để hỗ trợ.

2.3.4: Kiểm thử liên quan đến thay đổi - Testing Related to Changes: Re-testing and Regression Testing

Sau khi một lỗi được phát hiện và sửa chữa, phần mềm nên được kiểm thử lại để xác nhận lỗi ban đầu đã được xóa bỏ thành công gọi là kiểm thử xác nhận (Confirmation testing).
Kiểm thử hồi quy là các kiểm thử lặp đi lặp lại của một chương trình đã được kiểm thử, sau khi sửa đổi .

Việc phát hiện bất kỳ lỗi nào được coi như là kết quả của việc thay đổi. Các lỗi này có thể trong các phần mềm đang được kiểm thử, hoặc trong một thành phần phần mềm liên quan hoặc không liên quan.
Kiểm thử hồi quy thực hiện khi phần mềm hoặc môi trường thay đổi.
Phạm vi của kiểm thử hồi quy dựa trên rủi ro của các lỗi không được tìm thấy trong phần mềm đã làm việc trước đó.

Kiểm thử hồi quy có thể được thực hiện tại tất cả mức độ kiểm thử , bao gồm kiểm thử chức năng, phi chức năng và kiểm thử cấu trúc.

2.4: Kiểm thử bảo trì - Maintenance Testing

Định nghĩa : Kiểm thử những thay đổi tới hoạt động hệ thống hoặc tác động của thay đổi môi trường tới hoạt động hệ thống.

Sau khi triển khai, một hệ thống phần mềm thường được phục vụ trong nhiều năm hoặc nhiều thập kỷ. Trong thời gian này cấu hình dữ liệu hoặc môi trường của hệ thống thường được sửa chữa, thay đổi và mở rộng. Việc lập kế hoạch của các phiên bản phát hành trước đó là quan trọng cho kiểm thử bảo trì thành công.
Kiểm thử bảo trì được thực hiện trên hệ thống đã tồn tại, và được thực hiện khi có sự thay đổi, di chuyển hoặc rút lui của phần mềm hoặc hệ thống.

Kiểm thử bảo trì cho việc thay đổi : Bao gồm việc lập kế hoạch cải tiến thay đổi như là lập kế hoạch nâng cấp cơ sở dữ liệu, hệ điều hành.
Kiểm thử bảo trì cho việc di chuyển : Bao gồm kiểm tra hoạt động của môi trường mới , các phần mềm đã thay đổi. Kiểm thử di chuyển ( kiểm thử chuyển đổi) cũng cần thiết khi dữ liệu từ một ứng dụng khác sẽ được di chuyển vào hệ thống đang được bảo trì.
Kiểm thử bảo trì cho việc rút lui của một hệ thống : Bao gồm kiểm thử chuyển đổi dữ liệu hoặc lưu trữ dữ liệu

Kiểm thử bảo trì bao gồm kiểm thử hồi quy đến các bộ phận thay đổi của hệ thống .
Phạm vi của kiểm thử bảo trì liên quan đến rủi ro của việc thay đổi , kích thước của hệ thống hiện có, và kích thước của sự thay đổi
Kiểm thử bảo trì được thực hiện tại bất kỳ hoặc tất cả các mức độ kiểm thử hoặc tất cả các loại kiểm thử .
Kiểm thử bảo trì có thể khó khăn nếu đặc điểm kỹ thuật lỗi thời hoặc biến mất or người kiểm thử không có sẵn các kiển thức về miền (domain).

3. Kỹ thuật kiểm thử tĩnh - Static Techniques

3.1: Kỹ thuật kiểm thử tĩnh và tiến trình kiểm thử - Static Techniques and the Test Process

Các định nghĩa:

Kiểm thử động - Dynamic testing : Kiểm thử liên quan đến việc thực hiện của phần mềm, của một thành phần hoặc hệ thống.

Kiểm thử tĩnh - Static testing : Kiểm thử một thành phần hoặc hệ thống theo đặc tả mà không cần thực hiện phần mềm . Ví dụ như đánh giá ( review) hoặc phân tích tĩnh ( static analysis).

Kỹ thuật kiểm thử tĩnh dựa trên việc kiểm tra thủ công (reviews) và phân tích tĩnh tự động ( static analysis) của mã( code) hoặc tài liệu dự án mà không thực thi mã chương trình.

Đánh giá (reviews) là một cách kiểm thử sản phẩm công việc phần mềm ( bao gồm cả code) được thực hiện trước kiểm thử động. Các lỗi được phát hiện trong quá trình review sớm trong chu trình vòng đời ( ví dụ các lỗi được tìm thấy trong đặc tả) rẻ hơn nhiều so với các lỗi được phát hiện bằng cách chạy kiểm thử thi hành các mã.
Một đánh giá(review) được thực hiện như thế nào :
- Đánh giá thủ công (Review manually)
- Dùng công cụ hỗ trợ (Automated Analysis by Tool).
Đối tượng đánh giá bao gồm pecifications)

Thiết kế thông số kỹ thuật (design specifications)
Mã(Code)
Kế hoạch kiểm thử (test plans)
Kỹ thuật kiểm thử( test specifications)
Các trường hợp kiểm thử( test cases)
Các kịch bản kiểm thử ( test scripts)
Hướng dẫn sử dụng( user guides)
Các trang web (web pages).

Lợi ích của đánh giá (review)

Sớm phát hiện lỗi và điều chỉnh
Cải thiện năng suất phát triển
Giảm khoảng thời gian phát triển
Giảm chi phí và thời gian kiểm thử
Ít lỗi và cải thiện liên lạc

Loại khiếm khuyết trong đánh giá (reviews) bao gồm:

Độ lệch tiêu chuẩn (deviations from standards)
Khiếm khuyết trong yêu cầu ( requirement defects)
Khiếm khuyết trong thiết kế ( design defects)
Không đủ khả năng bảo trì code (insufficient maintainability)
Chi tiết kỹ thuật giao diện không chính xác (incorrect interface specifications).

Đánh giá có thể tìm các thiếu sót mà không có khả năng tìm thấy trong kiểm thử động . Ví dụ như thiếu sót trong yêu cầu kỹ thuật.
Sự giống nhau và khác nhau của kiểm thử động và kiểm thử tĩnh

Screenshot from 2015-03-26 08:57:29.png

3.2: Quy trình đánh giá - Review Process

Các định nghĩa:

Tiêu chí đầu vào - Entry criteria: Tập hợp các điều kiện chung và cụ thể. Mục đích của tiêu chí đầu vào là ngăn cản một nhiệm vụ từ khi bắt đầu sẽ gây ra lãng phí nỗ lực, để loại bỏ các tiêu chí đầu vào lỗi.
Đánh giá chính thức - formal review : Một đặc tính đánh giá bằng tài liệu và yêu cầu kỹ thuật.
Đánh giá không chính thức - informal review: Một đánh giá không dựa trên quy trình chính thức
Kiểm tra - inspection; Một loại đánh giá dựa trên kiểm tra trực quan tài liệu để phát hiện các lỗi.
Số liệu- metric: Một thang đo lường và các phương pháp được sử dụng để đo lường.
Người điều hành - moderator: Các trưởng nhóm (leader) và người chịu trách nhiệm chính cho việc kiểm tra(inspection) hoặc tiến trình đánh giá khác.
Đánh giá ngang hàng - peer review: Một đánh giá của một sản phẩm phần mềm giữa các đồng nghiệp của nhà sản xuất ra sản phẩm với mục đích xác định các lỗi và cải tiến.
Người đánh giá - reviewer: Những người tham gia vào việc đánh giá và mô tả sự bất thường trong sản phẩm hoặc dự án được đánh giá. Người đánh giá có thể được chọn để đưa ra các quan điểm khác nhau và vai trò trong quá trình review.
Người ghi chép: Người ghi lại từng khiếm khuyết được đưa ra và bất kỳ đề xuất cải tiến quy trình trong cuộc họp review .
Đánh giá kỹ thuật - technical review: Một hoạt động thảo luận nhóm mà tập trung vào việc đạt được sự đồng thuận về các phương pháp kỹ thuật được thực hiện.
Walkthrough : Nội dung của tài liệu được trình bày từng bước một bởi tác giả của tài liệu để thu thập thông tin và thiết lập hiểu biết chung.

3.2.1: Các hoạt động của một đánh giá chính thức - Activities of a Formal Review

Một đánh giá chính thức điển hình có các hoạt động chính sau đây :

Kế hoạch - Planning

Xác định tiêu chí đánh giá
Lựa chọn nhân sự
Phân bổ vai trò
Xác định tiêu chí đầu vào và tiêu chí kết thúc cho nhiều loại đánh giá chính thức (ví dụ : inspections)

Khởi động - Kick-off

Phân phối các tài liệu
Giải thích mục tiêu, quy trình ,các tài liệu cho người tham gia

Chuẩn bị cá nhân- Individual Preparation

Chuẩn bị cho cuộc họp đánh giá bằng cách xem xét các tài liệu
Ghi nhận các lỗi tiềm năng, các câu hỏi và các bình luận

Kiểm tra/ đánh giá/ ghi kết quả ( trong cuộc họp đánh giá) - Examination/Evaluation/Recording of Result (Review Meeting)

Thảo luận hoặc ghi lại kết quả trong tài liệu được lập
Ghi nhận các lỗi, kiến nghị liên quan đến việc xử lý các lỗi, đưa ra quyết định về các lỗi.
Kiểm tra/ đánh giá và ghi lại các vẫn đề trong cuộc họp hoặc theo dõi bất kỳ nhóm thông tin liên lạc điện tử .

Làm việc lại - Rework

Sửa các lỗi tìm thấy ( thường được thực hiện bởi tác giả)
Ghi lại trang thái đã cập nhật của lỗi

Bước thực hiện tiếp theo - Follow-up

Kiểm tra lại các lỗi đã được giải quyết
Thu thập các số liệu
Kiểm tra tiêu chí kết thúc

3.2.2 : Vai trò và trách nhiệm - Roles and Responsibilities

Một đánh giá điển hình sẽ bao gồm các vai trò sau:

Quản lý :
Quyết định về việc thực hiện các đánh giá
Phân bổ thời gian trong dự án và xác định các mục tiêu đánh giá đã được đáp ứng hoặc chưa được đáp ứng.
Người điều hành :
Người lãnh đạo việc đánh giá các tài liệu hoặc thiết lập các tài liệu, bao gồm kế hoạch đánh giá, điều hành cuộc họp, bước thực hiện tiếp theo sau cuộc họp.
Dàn xếp giữa các quan điểm khác nhau để đánh giá thành công.
Tác giả :
Người viết hoặc người có trách nhiệm chính đối với các tài liệu được đánh giá.
Người đánh giá:
Những cá nhân với một nền tảng kỹ thuật hoặc doanh nghiệp , sau khi chuẩn bị những thứ cần thiết, xác định và mô tả những phát hiện trong sản phẩm được đánh giá.
Người ghi chép :
Ghi chép tài liệu về tất cả các vấn đề và các quan điểm mở được xác định trong cuộc hop đánh giá.

3.2.3: Các loại đánh giá - Types of Reviews

Một sản phẩm phần mềm hoặc sản phẩm công việc liên quan có thể là đối tượng của nhiều hoặc một đánh giá. Nếu nhiều hơn một loại đánh giá được sử dụng, thứ tự có thể thay đổi.

Ví dụ : Đánh giá không chính thức ( informal review) có thể được thực hiện trước đánh giá kỹ thuật(technical review). Hoặc một kiểm tra (inspection ) có thể được thực hiện trên yêu cầu đặc điểm kỹ thuật trước một walkthough với khách hàng.

Các đặc điểm, lựa chọn và mục đích chính của các loại đánh giá là:

Đánh giá không chính thức (Informal Review)

Không có quy trình chính thức
Có thể lấy mẫu(form) của các chương trình hoặc của một trưởng nhóm kỹ thuật đánh giá thiết kế và code.
Kết quả có thể được ghi lại
Thay đổi lợi ích phụ thuộc vào những người đánh giá
Mục đích chính: + Chi phí thấp để có được một số lợi ích + Tìm các lỗi

Walkthrough

Quy trình đánh giá chính thức.
Cuộc họp bởi tác giả
Có thể lấy mẫu(form) của các kịch bản ,việc vận hành thử , nhóm tham gia.
Phiên họp mở-kết thúc ( Open-ended sessions) - Tùy chọn trước cuộc họp sự chuẩn bị của người đánh giá - Tùy chọn chuẩn bị báo cáo đánh giá bao gồm danh sách của các phát hiện. + Tùy chọn người ghi chép( người không phải là tác giả)
Mục đích chính : + Tìm hiểu + Đạt được sự hiểu biết + Tìm các lỗi.

Đánh giá kỹ thuật

Quy trình đánh giá chính thức
Lập tài liệu, xác định quá trình phát hiện những sai sót bao gồm người điều hành, các đồng nghiệp, các chuyên gia kỹ thuật.
Ý tưởng được dẫn dắt bởi người điều hành( không phải tác giả)
Tùy chọn sử dụng các danh sách kiểm tra (checklists)
Chuẩn bị báo cáo đánh giá bao gồm danh sách các phát hiện, các quyết định xem sản phẩm phần mềm có đáp ứng được các yêu cầu, kiến nghị liên quan đến các phát hiện.
Mục đích chính: + Thảo luận + Đưa ra các quyết định + Đánh giá các lựa chọn thay thế + Tìm các lỗi + Giải quyết các vấn đề kỹ thuật + Kiểm tra sự phù hợp với các thông số kỹ thuật, kế hoạch, quy định và tiêu chuẩn.

Inspection

Quá trình đánh giá chính thức
Được dẫn dắt bởi người điều hành( không phải tác giả)
Tiến hành như một đánh giá ngang hàng ( đánh giá giữa các đồng nghiệp)
Xác định các vai trò
Thu thập các số liệu
Quá trình đánh giá chính thức dựa trên các nguyên tắc và danh sách kiểm tra
Quy định tiêu chí đầu vào và tiêu chí kết thúc
Chuẩn bị cuộc họp
Kiểm tra báo cáo bao gồm danh sách các phát hiện
Quá trình các bước tiếp theo ( với việc tùy chọn tiến trình cải tiến các thành phần)
Tùy chọn người đọc
Mục đích chính : + Phát hiện các lỗi

3.2.4: Các yếu tố thành công cho đánh giá - Success Factors for Reviews

Các yếu tố thành công cho đánh giá bao gồm:

Mỗi đánh giá có mục tiêu rõ ràng được xác định trước
Những người phù hợp với các mục tiêu đánh giá được tham gia
Người kiểm thử là người đánh giá có giá trị đóng góp vào việc đánh giá và cũng tìm hiểu về sản phẩm để họ chuẩn bị cho các kiểm thử sớm.
Các khiếm khuyết tìm thấy được tiếp nhận và bày tỏ quan điểm
Vấn đề con người và khía cạnh tâm lý được giải quyết
Đánh giá được tiến hành trong không khí tin tưởng ,kết quả sẽ không được sử dụng cho việc đánh giá những người tham gia.
Danh sách kiểm tra(checklist) hoặc các vai trò được sử dụng phù hợp để tăng hiệu quả của việc xác định các khiếm khuyết.
Đào tạo được đưa ra trong kỹ thuật đánh giá, đặc biệt là các kỹ thuật chính thức như là inspection.
Hỗ trợ quản lý là một quá trình đánh giá tốt
Tầm quan trọng trong việc học tập và cải tiến quá trình.

3.3 : Phân tích tĩnh bằng công cụ

Các định nghĩa :

Trình biên dịch - Compiler : Một công cụ phần mềm biên dịch các chương trình bằng một ngôn ngữ bậc cao thành ngôn ngữ máy.
Sự phức tạp - complexity : Mức độ mà một thành phần hoặc hệ thống có một thiết kế hoặc cấu trúc bên trong khó hiểu
Luồng điều khiển - control flow : Một chuỗi các sự kiện( đường dẫn) trong việc thực hiện thông qua một thành phần hoặc hệ thống.
Luồng dữ liệu - data flow : Một đại diện của các trình tự có thể thay đổi trạng thái của đối tượng dữ liệu, trạng thái của đối tượng có thể là sự tạo thành(creation), cách sử dụng (usage), sự tiêu hủy (destruction).
Phân tích tĩnh - static analysis : Phân tích hiện vật phần mềm (ví dụ như yêu cầu của code), thực hiện mà không cần thực thi các hiện vậtt phát triển phần mềm.

Mục tiêu của phân tích tĩnh là tìm ra các khiếm khuyết trong mã nguồn (source code) phần mềm và trong mô hình phần mềm. Phân tích tĩnh được thực hiện mà không cần chạy phần mềm, được kiểm tra bằng công cụ. Công cụ phân tích tĩnh phân tích mã chương trình (ví dụ : luồng điều khiển và luồng dữ liệu).

Lợi ích của phân tích tĩnh:

Phát hiện sớm các lỗi trước khi thực hiện kiểm thử
Cảnh báo sớm về những khía cạnh đáng ngờ của code hoặc thiết kế bằng cách tính toán các số liệu.
Xác định các lỗi không dễ dàng tìm được trong kiểm thử động.
Xác định phần phụ thuộc và không nhất quán trong mô hình phần mềm.
Cải thiện khả năng bảo trì của code và thiết kế
Ngăn ngừa các lỗi , cải thiện chất lượng.

Các khiếm khuyết điển hình được phát hiện bằng công cụ phân tích tĩnh bao gồm :

Tham chiếu một biến với một giá trị không xác định
Giao diện không đồng nhất giữa các modules và các thành phần
Các biến không được sử dụng hoặc khai báo không đúng
Làm chết code
Logic thiếu và sai( vòng lặp vô hạn)
Cấu trúc quá phức tạp
Vi phạm tiêu chuẩn chương trình
Lỗ hổng bảo mật
Vi phạm cú pháp của mã (code) và mô hình phần mềm

Phân tích tĩnh bằng công cụ khi nào và do ai thực hiện:

Sử dụng bởi các nhà phát triển trước và trong kiểm thử thành phần và kiểm thử tích hợp
Khi kiểm tra trong code bằng công cụ quản lý cấu hình và thực hiện bởi người phát triển
Trong mô hình phần mềm thực hiện bởi người thiết kế.

Phân tích tĩnh bằng công cụ có thể tạo ra một số lượng lớn các tin nhắn cảnh báo, cần quản lý tốt để sử dụng công cụ một cách hiệu quả nhất.
Trình biên dịch có thể hỗ trợ phân tích tĩnh, bao gồm cả tính toán các số liệu.

Trên đây là những tìm hiểu của mình khi nghiên cứu chương 2 và chương 3 của giáo trình. Trong bài tiếp theo mình sẽ trình bày về chương 4 và chương 5 của giáo trình.

Testing

Mục lục