Kiểm thử và bảo trì phần mềm

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (458.98 KB, 33 trang )

Bạn đang đọc: Kiểm thử và bảo trì phần mềm – Tài liệu text

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

BÀI TẬP LỚN
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
Nội dung : Kiểm thử và bảo trì phần mềm
Giáo viên hướng dẫn : PGS. TS. Huỳnh Quyết Thắng
Sinh viên thực hiện

1. Bùi Thanh Liêm

– 20061779

2. Mai Thị Ngoan

– 20062264

3. Trương Thảo Nguyên

– 20062306

4. Nguyễn Tài Thanh

– 20062815

Lớp : Công nghệ phần mềm K51
HÀ NỘI 04 – 2010

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

Mục lục
I.

Tìm hiểu lý thuyết ………………………………………………………………………………………………..3

Kiểm thử phần mềm ………………………………………………………………………………………………3
1. Tổng quan về kiểm thử phần mềm ………………………………………………………………………..3
2. Các kĩ thuật kiểm thử phần mềm…………………………………………………………………………..4
3. Chiến lược kiểm thử phần mềm ……………………………………………………………………………6

Kiểm thử đơn vị – Unit test …………………………………………………………………………..7

Kiểm thử tích hợp – Intergration Test ……………………………………………………………..7

Kiểm thử hệ thống – System Test …………………………………………………………………..8

Kiểm thử chấp nhận sản phẩm – Acceptance Test ……………………………………………10

Một số chiến lược kiểm thử khác………………………………………………………………….10

Bảo trì phần mềm ……………………………………………………………………………………………….12
1. Tổng quan về bảo trì phần mềm. …………………………………………………………………………12
2. Quy trình bảo trì phần mềm. ………………………………………………………………………………14
3. Khó khăn của bảo trì phần mềm………………………………………………………………………….15
4. Nhiệm vụ của bảo trì phần mềm. ………………………………………………………………………..17
5. Ý nghĩa của bảo trì phần mềm. …………………………………………………………………………..17
6. Phương pháp bảo trì phần mềm ………………………………………………………………………….17
7. Các vấn đề khác của bảo trì phần mềm. ……………………………………………………………….20

II. Thực tế áp dụng tại các công ty ……………………………………………………………………………22
III. Bài học kinh nghiệm và đánh giá kết luận của nhóm ……………………………………………..24
IV. Tài liệu tham khảo ……………………………………………………………………………………………..25
V. Phụ lục………………………………………………………………………………………………………………26
1. Biên bản khảo sát công ty trách nhiệm hữu hạn SeLab……………………………………………26
2. Biên bản khảo sát công ty FPT Software………………………………………………………………28
3. Biên bản khảo sát công ty MISA…………………………………………………………………………31

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

Tìm hiểu lý thuyết

A. Kiểm thử phần mềm
1. Tổng quan về kiểm thử phần mềm
a. Khái niệm kiểm thử phần mềm
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện
xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay
thành phần đó. (Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ nghệ phần mềmIEEE Standard Glossary of Software Engineering Terminology).
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi. (Theo “The
Art of Software Testing” – Nghệ thuật kiểm thử phần mềm).
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong
đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan
những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử
phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối
ưu của phần mềm trong nhiều ngành khác nhau. (Theo Bách khoa toàn thư mở Wikipedia).
Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình hay một
tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã
được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây là một pha quan
trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy
được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa
b. Phân loại
Có hai loại kiểm thử phần mềm chính đó là kiểm thử tĩnh (static testing) và kiểm thử động
(dinamic testing).


Kiểm thử tĩnh – Static testing

Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng tay,
thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chương
trình. Kiểu kiểm thử này thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh

một mình.
Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các
chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về
cú pháp của chương trình.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm


Kiểm thử động – Dynamic testing

Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng
thái tác động của chương trình. Đó là kiểm thử dựa trên các ca kiểm thử xác định bằng sự thực
hiện của đối tượng kiểm thử hay chạy các chương trình. Kiểm thử động kiểm tra cách thức hoạt
động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi
theo thời gian. Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử
động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu
ra có như mong muốn hay không. Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit
Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử
chấp nhận sản phẩm – Acceptance Tests.
c. Mục tiêu của kiểm thử phần mềm


Kiểm thử là một quá trình thực thi chương trình với mục đích là tìm ra lỗi/ các yếu điểm
của chương trình.



Một trường hợp kiểm thử tốt là một trường hợp có khả năng lớn trong việc tìm ra những
lỗi chưa được phát hiện.



Một trường hợp kiểm thử không tốt ( không thành công ) là một trường hợp mà khả năng
tìm thấy những lỗi chưa biết đến là rất ít.



Mục tiêu của kiểm thử phần mềm là thiết kế những trường hợp kiểm thử để có thể phát
hiện một cách có hệ thống những loại lỗi khác nhau và thực hiện việc đó với lượng thời
gian và tài nguyên ít nhất có thể.

2. Các kĩ thuật kiểm thử phần mềm.
Ba trong số các kĩ thuật kiểm thử phần mềm là kiểm thử hộp đen, kiểm thử hộp trắng, và
kiểm thử hộp xám.
a. Kiểm thử hộp đen – Black box testing
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu,
hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của
bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình.
Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các
đặc tả của nó. Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.
Các phương pháp kiểm thử hộp đen
o Phân lớp tương đương – Equivalence partitioning.
o Phân tích giá trị biên – Boundary value analysis.
o Kiểm thử mọi cặp – All-pairs testing.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
o Kiểm thử fuzz – Fuzz testing.
o Kiểm thử dựa trên mô hình – Model-based testing.

o Ma trận dấu vết – Traceability matrix.
o Kiểm thử thăm dò – Exploratory testing.
o Kiểm thử dựa trên đặc tả – Specification-base testing.
Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo
những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ
đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung
cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị
đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca
kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn
chặn những rủi ro chắc chắn.
Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn
giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được
nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra.
Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà
không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự
được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp
đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra
bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra
chút nào. Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt
khác nó lại có nhược điểm của “thăm dò mù”.
b. Kiểm thử hộp trắng – White box testing
Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp
trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình.
Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình.
Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã
lệnh thực hiện chúng).
Các phương pháp kiểm thử hộp trắng
o Kiểm thử giao diện lập trình ứng dụng – API testing (application programming
interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và
riêng tư.

o Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu chuẩn
về bao phủ mã lệnh.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
o Các phương pháp gán lỗi – Fault injection.
o Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
o Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh.
Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của
một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều này cho phép
các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng
những điểm chức năng quan trọng nhất đã được kiểm tra.
c. Kiểm thử hộp xám – Gray box testing
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho
những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp
đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như
một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta
vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử
tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác
nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm
cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.
3. Chiến lược kiểm thử phần mềm
Kiểm thử phần mềm có nhiều chiến lược khác nhau: kiểm thử đơn vị, kiểm thử tích hợp,
kiểm thử hệ thống và kiểm thử chấp nhận sản phẩm

Hình 01: Sơ đồ phân loại chiến lược kiểm thử

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
a. Kiểm thử đơn vị – Unit test

Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các
hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được
xem là Unit.
Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản,
chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử.
Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ
khoanh vùng trong một đơn thể Unit đang kiểm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian
tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm
thử và sửa lỗi ở các mức kiểm thử sau đó.
Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm
càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Thông thường,
Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của
Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan
với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit
đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các
lệnh được thực thi trong một Unit. Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else
là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết Unit
đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.
Cùng với các mục kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử
(Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ liệu đầu vào, các bước
thực hiện và dữ liệu đầu ra mong muốn. Các Test case và Test script này nên được giữ lại để tái
sử dụng.
b. Kiểm thử tích hợp – Intergration Test
Integration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã
hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết
hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.
Hai mục tiêu chính của Integration Test:
o Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
o Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là
nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống

(System Test).
Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội
tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với các thành phần liên
quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự được kiểm tra đầy đủ khi các
Unit tích hợp với nhau trong khi thực hiện Integration Test.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra
cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người
hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải
thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống
hoàn toàn khác.
Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit
tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất
các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào
với hệ thống các Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi
rất nhiều, và sai sót sẽ giảm đáng kể.
Có 4 loại kiểm thử trong Integration Test:
o Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thử cấu trúc
nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng và chú
trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn
các câu lệnh và nhánh bên trong.
o Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm thử chức
năng chỉ chú trọng đến chức năng của chương trình, mà không quan tâm đến cấu
trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.
o Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ thống.
o Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống.
c. Kiểm thử hệ thống – System Test
Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa

mãn yêu cầu đặt ra hay không.
System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công.
Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp,
việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các
ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người
kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và
các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.
Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các
hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể
hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và
Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi
thực hiện System Test.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với
các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt
đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên
bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu.
System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng
như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích
hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi
“tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thường
đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm
(Acceptance Test) hoặc dùng thử (Alpha/Beta Test).
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được
thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án. Bản thân
System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm:
o Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống thỏa mãn đúng
yêu cầu thiết kế.

o Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống
(ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn…
o Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận hành đúng
dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng
thái tới hạn, các “điểm chết”, các tình huống bất thường như đang giao dịch thì ngắt kết nối
(xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM…)…
o Kiểm thử cấu hình (Configuration Test).
o Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ
thống.
o Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả năng khôi phục
trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng
đối với các hệ thống giao dịch như ngân hàng trực tuyến…
Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng bảo đảm hệ
thống đủ khả năng làm việc trong môi trường thực.
Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc
trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người.
Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
d. Kiểm thử chấp nhận sản phẩm – Acceptance Test
Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện
(hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng
minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và
trả tiền thanh toán hợp đồng).
Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các
phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách
thức thực hiện lại rất khác biệt.
Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông
thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta –

Beta Test. Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm,
lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần
mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi
cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.
Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển
phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả
các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ
của khách hàng. Ví dụ đôi khi một phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng
thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì
bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách
hàng v.v…
Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi
kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèm phải được cập nhật và
kiểm thử chặt chẽ.
e. Một số chiến lược kiểm thử khác
Ngoài các chiên lược trên, còn một số các chiến lược kiểm thử khác như:


Kiểm thử hồi quy – Regression Testing:

Theo chuẩn IEEE610.12-90, kiểm thử hồi quy là “sự kiểm tra lại có lựa chọn của một hệ
thống hay thành phần để xác minh là những sự thay đổi không gây ra những hậu quả không
mong muốn…”. Trên thực tế, quan niệm này là chỉ ra rằng phần mềm mà đã qua được các kiểm
tra trước đó vẫn có thể được kiểm tra lại. Beizer định nghĩa đó là sự lặp lại các kiểm tra để chỉ ra
rằng cách hoạt động của phần mềm không bị thay đổi, ngoại trừ tới mức như yêu cầu. Hiển nhiên
là sự thỏa hiệp phải được thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quy mỗi lần
thực hiện một sự thay đổi và những tài nguyên được yêu cầu thực hiện điều đó.


Kiểm thử tính đúng – Correctness testing:

Tính đúng đắn là yêu cầu tối thiểu của phần mềm, là mục đích chủ yếu của kiểm thử. Kiểm
thử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cách hoạt động đúng đắn từ cách

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
hoạt động sai lầm. Kiểm thử viên có thể biết hoặc không biết các chi tiết bên trong của các
modun phần mềm được kiểm thử, ví dụ luồng điều khiển, luông dữ liệu, v.v …. Do đó, hoặc là
quan điểm hộp trắng, hoặc là quan điểm hộp đen có thể được thực hiện trong kiểm thử phần
mềm.


Các phương pháp kiểm thử con người

Hai phương pháp kiểm thử con người chủ yếu là Code Inspections và Walkthroughs. Hai
phương pháp này bao gồm một nhóm người đọc và kiểm tra theo mã lệnh của chương trình. Mục
tiêu của chúng là để tìm ra lỗi mà không gỡ lỗi.
Một Inspection hay Walkthrough là 1 sự cải tiến của phương pháp kiểm tra mà lập trình viên
đọc chương trình của họ trước khi kiểm thử nó. Inspections và Walkthroughs hiệu quả hơn là bởi
vì những người khác sẽ kiểm thử chương trình tốt hơn chính tác giả của chương trình đó.
Inspections/Walkthroughs và kiểm thử bằng máy tính bổ sung cho nhau. Hiệu quả tìm lỗi sẽ
kém đi nếu thiếu đi 1 trong 2 phương pháp. Và đối với việc sửa đổi chương trình cũng nên sử
dụng các phương pháp kiểm thử này cũng như các kỹ thuật kiểm thử hồi quy.


Tổng duyệt – Walkthrough

Walkthrough là một thuật ngữ mô tả sự xem xét kỹ lưỡng của một quá trình ở mức trừu
tượng trong đó nhà thiết kế hay lập trình viên lãnh đạo các thành viên trong nhóm và những
người có quan tâm khác thông qua một sản phẩm phần mềm, và những người tham gia đặt câu

hỏi, và ghi chú những lỗi có thể có, sự vi phạm các chuẩn phát triển và các vấn đề khác.
Walkthrough mã lệnh là 1 tập các thủ tục và các công nghệ dò lỗi cho việc đọc nhóm mã lệnh.
Trong một Walkthrough, nhóm các nhà phát triển – với 3 hoặc 4 thành viên là tốt nhất – thực
hiện xét duyệt lại. Chỉ 1 trong các thành viên là tác giả của chương trình.
Một ưu điểm khác của walkthroughs, hiệu quả trong chi phí gỡ lỗi, là 1 thực tế mà khi một
lỗi được tìm thấy, nó thường được định vị chính xác trong mã lệnh. Thêm vào đó, phương pháp
này thường tìm ra 1 tập các lỗi, cho phép sau đó các lỗi đó được sửa tất cả với nhau. Mặt khác,
kiểm thử dựa trên máy tính,chỉ tìm ra triệu chứng của lỗi (chương trình không kết thúc hoặc đưa
ra kết quả vô nghĩa), và các lỗi thường được tìm ra và sửa lần lượt từng lỗi một.


Thanh tra mã nguồn – Code Inspection

Thanh tra mã nguồn là 1 tập hợp các thủ tục và các kỹ thuật dò lỗi cho việc đọc các nhóm mã
lệnh. Một nhóm kiểm duyệt thường gồm 4 người. Một trong số đó đóng vai trò là người điều tiết
– một lập trình viên lão luyện và không được là tác giả của chương trình và phải không quen với
các chi tiết của chương trình. Người điều tiết có nhiệm vụ: phân phối nguyên liệu và lập lịch cho
các buổi kiểm duyệt, chỉ đạo phiên làm việc, ghi lại tất cả các lỗi được tìm thấy và đảm bảo là
các lỗi sau đó được sửa. Thành viên thứ hai là một lập trình viên. Các thành viên còn lại trong
nhóm thường là nhà thiết kế của chương trình ( nếu nhà thiết kế khác lập trình viên) và một
chuyên viên kiểm thử.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
B. Bảo trì phần mềm
1. Tổng quan về bảo trì phần mềm.
a. Định nghĩa
Bảo trì phần mềm là giai đoạn cuối cùng và tốn kém nhất trong quy trình phát triển phần
mềm. Các nhà nghiên cứu đã đưa ra nhiều định nghĩa về bảo trì phần mềm như:
o Bảo trì phần mềm là sự thay đổi phần mềm sau khi nó đã được bàn giao cho khách

Xem thêm: Maintainability Testing Là Gì & Quy Trình Thực Hiện, Test Type Là Gì

hàng.(theo Martin & McLure 1983)
o Bảo trì phần mềm bao hàm vòng đời phần mềm từ lúc nó được triển khai đến kết
thúc.(Von Mayrhauser 1990).
o Bảo trì phần mềm là sự thay đổi mã nguồn và các tài liệu liên quan vì một vấn đề hoặc vì
sự cần thiết phải phát triển. mục đích là biến đổi phần mềm hiện có trong khi vẫn giữ
nguyên tính toàn vẹn của nó.(ISO/IEC 12207 1995).
o Bảo trì phần mềm là sự cải tiến của một sản phẩm phần mềm sau khi đã được bào giao
nhằm sửa lỗi, tăng hiệu suất hoặc các thuộc tính khác, hoặc làm cho phần mềm thích ứng
với các thay đổi trong môi trường.(IEE 1219 1998).
Vậy chúng ta có thể hiểu bảo trì phần mềm là là quá trình sửa đổi một bộ phận hoặc toàn bộ
sản phẩm phần mềm sau khi đã bàn giao nhằm sửa lỗi,cải thiện tính năng hoặc để phần mềm có
thể đáp ứng các thay đổi của môi trường.
b. Phân loại
Bảo trì phần mềm bao gồm: Bảo trì tu sửa(Corrective Maintenance), bảo trì thích
nghi(Adaptive Maintenance),bảo trì cải tiến(Perfective Maintenance) và bảo trì phòng ngừa.


Bảo trì tu sửa: là bảo trì nhằm sửa các lỗi hoặc hỏng hóc phát sinh. Lỗi và hỏng hóc phát
sinh có thể do các nguyên nhân sau:
o Lỗi do sơ ý của lập trình viên hoặc do kiểm thử chưa chặt
o Lỗi do phân tích yêu cầu khách hàng chưa chính xác và đầy đủ
o Tính năng của phần mềm chưa đáp ưng được yêu cầu thực tế của khách hàng: bộ
nhớ,thiết kế…
o Thiếu sự chuẩn hóa trong phát triển phần mềm…
Bảo trì tu sửa thường sử dụng kỹ thuật dịch ngược(reverse enginnering) dò theo thiết kế để
tìm lỗi



Bảo trì thích nghi: (Adaptive Maintenance) là chỉnh sửa phần mềm theo sự thay đổi của môi

trường như sự thay đổi của phần cứng,OS hoặc các thiết bị đi kèm.
Bảo trì cải tiến: thay đổi phần mềm theo những yêu cầu ngày càng hoàn thiện hơn, đầy đủ
hơn, hợp lý hơn. Đây là hình thái bảo trì phổ biến nhất trong thực tế. Chức năng đáng quan
tâm của hình thức bảo trì này là nâng cao hệ thống và tăng các hoạt động thực thi của hệ
thống, giúp thay đổi giao diện của hệ thống với người sử dụng. Một phần thành công của
việc chăm sóc phần mềm sẽ giúp cho các thay đổi tiếp theo. Các nguyên nhân chính của bảo
trì này là:
o Muốn nâng cao hiệu suất nên thường cải tiến phương thức truy nhập
o Mở rộng thêm chức năng cho hệ thống.
o Cải tiến quản lý làm cải tiến tư liệu vận hành và trình tự công việc.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
o Thay đổi người dùng hoặc thao tác.
Hình thức bảo trì này thường sử dụng kỹ thuật gọi là “tái kỹ nghệ”(re-engineering)để đưa ra
một hệ thống cùng chức năng nhưng có chất lượng cao hơn. Có thể tiến hành theo các bước: xây
dựng lưu đồ phần mềm,tìm biểu thức Bun cho từng dãy xử ly, biên dịch bảng chân lý và tái cấu
trúc phần mềm.


Bảo trì phòng ngừa: là sự tu chỉnh phần mềm có tính đến tương lai của phần mềm đó sẽ
được mở rộng và thay đổi như thế nào. Bảo trì phòng ngừa bao gồm các hoạt động để tăng
khả năng duy trì của hệ thống, như cập nhật dữ liệu, thêm module. Việc sử đổi đối với một
hệ thống mới là rất phức tạp, có thể làm hư hại các cấu trúc.Với phần mềm được thiết kế tốt
thì hình thái bảo trì này gần như không gặp. Sự sửa đổi này nhằm đáp ứng yêu cầu thay đổi
của người sử dụng.
Hình thức này trước tiên cần thực hiện những thay đổi trên thiết kế không tường minh của
phần mềm, hiểu rõ hoạt động của phần mềm, tiến hành thiết kế và lập trình lại.
Hình thức bảo trì phòng ngừa rất ít đươc sử dụng trong thực tế, đa số vẫn là hình thức bảo trì
cải tiến. Biểu đồ sau cho ta thấy sự tương quan giữa 3 hình thức bảo trì đầu tiên.

Hình xx: Tỉ lệ các hình thức bảo trì phần mềm
c. Những đặc điểm của phần mềm tác động tới bảo trì phần mềm.
Tiến hành bảo trì phần mềm cần phải biết những đặc tính nào của phần mềm sẽ ảnh hưởng
tới công việc bảo trì chính nó. Theo Martin và McClure thì kích thước của hệ thống, tuổi hệ

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
thống, số lượng và đầu ra dữ liệu, loại chương trình ứng dụng, ngôn ngữ lập trình và cấp độ cấu
trúc là những đặc điểm ảnh hưởng trực tiếp tới công việc bảo trì phần mềm.
Hệ thống càng lớn thì yêu cầu càng cao sự bảo trì để hệ thống ổn định và gọn gàng hơn, giảm
thiểu khó khăn do sự phức tạp của các chức năng gây nên. Theo Van Vliet thì việc bảo trì phần
mềm sẽ ít cần thiết hơn nếu có càng ít dòng mã. Độ dài mã nguồn là vấn đề chính để xác định
tổng chi phí trong suốt quá trình bảo trì cũng như quá trình phát triển phần mềm.
2. Quy trình bảo trì phần mềm.
Quy trình của bảo trì phần mềm tương tự như quy trình phát triển phần mềm: phân tích, thiết
kế, thực hiện, kiểm thử. Bảo trì có thể là sửa đổi phần mềm cũ, cũng co thể tiến hành xây dựng
phần mềm mới hoàn toàn.
Hiểu phần mềm

Loại bảo

Xây dựng phần mềm mới

trì?
Chỉnh phần mềm đã có

Kiểm thử tính nhất quán

Kiểm thử sau bảo trì

Lập biểu bảo trì

Hình xx: Quy trình bảo trì phần mềm


Hiểu phần mềm: hiểu là nắm chắc các chức năng,đặc tả chi tiết, điều kiện kiểm thử…, cần
dò đọc chương trình nguồn, hiểu trình tự xử lý chi tiết của hệ thống. Hiểu phần mềm thực
chất là có những hiểu biết sâu sắc về hệ thống phần mềm đang làm gì, nó liên quan gì tới môi
trường của nó như thế nào,nhận ra đâu là các thay đổi có hiệu quả và có các hiểu biết sâu sắc
về các phần được sửa lại làm việc như thế nào. Để co thể thành công trong việc tạo ra các
thay đổi đến hệ thống, vấn đề của từng bộ phận, hiệu quả thi hành,sự liên quan của nguyên

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm




nhân, kết quả, sự liên quan của sản phẩm-môi trường và các đặc điểm hỗ trợ quyết định cần
được hiểu. Mọi thành viên của đội bảo trì phải hiểu một cách toàn diện và hệ thống. Nếu
bảo trì bằng cách tu sửa chương trình phần mềm đã có thì cần tạo ra các module mới và dịch
lại. Thực hiện kiểm thử unit và tu chỉnh những mục liên quan trong tài liệu đặc tả. Cần theo
sát tác động của module mới đến các thành phần khác trong hệ thống.
Xây dựng phần mềm mới: nếu tiến hành xây dựng phần mềm mới thì cần chú ý: khi xây
thêm chức năng mới phải phát triển cho phù hợp với yêu cầu.
Kiểm thử tính nhất quán: kiểm chứng tính nhất quán bằng kiểm thử kết hợp: đưa unit đã

được kiểm thử vào hoạt động trong hệ thống, điều chỉnh sự tương thích giữa các modul, dùng
các dữ liệu trước đây khi kiểm thử để kiểm tra lại tính nhất quán.
Kiểm tra sau bảo trì: kiểm tra khi hoàn thành bảo trì cần kiểm tra sự sửa đổi trong tài liệu
đặc tả đi kèm, cách ghi tư liệu có phù hợp với mô tả môi trường phần mềm mới hay không.
Lập biểu bảo trì: Lập biểu quản lý tình trạng bảo trì: tình trạng bảo trì rất cần được kiểm
soát chặt chẽ, cần lập biểu để quản lý, bao gồm các thông tin: thời gian, nguyên nhân, tóm tắt
cách khắc phục, chi tiết cách khắc phục, hiệu ứng đi kèm sự thay đổi, người tiến hành bảo trì,
số công.

3. Khó khăn của bảo trì phần mềm.
Thực tế là bảo trì phần mềm là mảng kiến thức không được giảng dạy một cách hệ thống
trong các trường đại học, sinh viên khi ra trường thiếu sót nền tảng, sự hiểu biết và các kỹ thuật,
công cụ hỗ trợ trong lĩnh vực bảo trì. Ngay trong các công ty phát triển phần mềm ở Việt Nam,
quy trình bảo trì phần mềm cũng chưa được thực hiện một cách hệ thống, chưa có chuẩn trong
việc bảo trì phần mềm, chưa được đầu tư thích đáng.
Khó khăn cho bảo trì có thể nhìn thấy từ góc nhìn của khách hàng cũng có thể tới tư phía
nhân viên phát triển phần mềm. Dekleva đưa ra một báo cáo khảo sát, từ góc nhìn của một nhân
viên bảo trì phần mềm đưa ra danh sách 19 vấn đề chính của bảo trì phần mềm.
Một vấn đề được chấp nhận rộng rãi là, bảo trì phần mềm đã trở thành một nguồn lợi lớn với
các công ty phần mềm. một số cuộc điều tra trong vòng 10 năm gần đây chỉ ra, với hầu hết các
phần mềm thì bảo trì phần mềm chiếm tỷ lệ lớn trong chi phí của một phần mềm trong suốt vòng
đời phát triển của nó. Một số chuyên ra đưa ra tỉ lệ cụ thể như sau: theo Foster la từ 40 tới 90%,
theo Rand là 75%,Tony Scott là 50 đến 80%. Các cuộc điều tra dựa trên ý kiến những người
tham gia, xác nhận thông tin người dùng rằng giá trị của bảo trì là rất lớn. Sau đây là bảng 19
khó khăn của bảo trì phần mềm dưới góc độ của một nhân viên:

Khó khăn

STT
1

Đi theo sự thay đổi các ưu tiên

Thiếu kinh nghiệm kiểm thử

Khó khăn để đo hiệu năng

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
4

Tài liệu về phần mềm là không đầy đủ

Thích nghi với sự thay đổi nhanh của tổ chức người dùng

Yêu cầu cần quá Nihau

Khó khăn để đánh giá sự đóng góp của bảo trì trong vòng đời phần mềm.

Tinh thần làm việc thấp vì thiếu hiểu biết và quan tâm

Ít chuyên gia kinh nghiệm.

Ít phương pháp, thiếu các chuẩn, thủ tục hoặc công cụ sử dụng.

Mã nguồn của phần mềm đã có là phức tạp và không có cấu trúc

Sự tích hợp, chồng chéo và không tương thích của hệ thống đã có.

Đào tạo ở bậc thấp cho đội ngũ nhân viên bảo trì.

Không có kế hoạch chiến lược cho bảo trì

Khó khán để hiểu và đáp ứng được yêu cầu của người dùng.

Thiếu sự thấu hiểu và giúp đỡ từ người quản lý.

Phần mềm của hệ thống được bảo trì hoạt động trong môi trường lỗi thời

Ít dự định để tái thiết kế phần mềm đã co.

Thiếu nhân lực có chuyên môn.

Một thực tế đã được kiểm nghiệm là yêu cầu của khách hàng chủ yếu (55%) là yêu cầu thêm
mới chứ không phải yêu cầu sửa đổi. Các đặc điểm đặc biệt của phần mềm cũng gây khó khăn
cho quá trình bảo trì. Banker chỉ ra rằng kích thước và độ phức tạp của một phần mềm có ảnh
hưởng tới giá thành bảo trì và các nỗ lực chỉnh sửa phần mềm đó. Boehm đưa ra nhận định cứ 1$
đầu tư cho phát triển phần mềm thì sẽ phải dùng 2$ cho việc bảo trì.
Lehman cho biết cấu trúc mã phần mềm ngày càng trở nên phức tạp do Nihau thay đổi tác dông
lên phân mềm, điều này làm tăng số lượng nhân viên dành cho bảo trì phần mềm. Osborne và
chikosky kết hợp tuổi đời hoạt động và độ phức tạp của hệ thống. Họ chỉ ra rằng trong quá khứ,
các phần mềm không sử dùng các kỹ thuật kiến trúc tiên tiến, các phần mềm cũ co cấu trúc bên
trong phức tạp, kỹ thuật lập trình kém, thiêu tài liệu đặc tả, dẫn tới giá thành và nỗ lực bảo trì
lớn. Hewletet chỉ ra nhân tố chính dẫn tới giá thành bảo trì phần mềm cao là số lượng và kinh
nghiệm của lập trình viên, chất lượng của tại liệu kỹ thuật, tài liệu người dùng, các công cụ hỗ
trợ cho nhân viên bảo trì, cấu trúc và khả năng bảo trì của chính phần mềm.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
4. Nhiệm vụ của bảo trì phần mềm.
Nhiệm vụ của bảo trì phần mềm được xác định theo từng giai đoạn của quá trình bảo trì:
phân tích/ cô lập, thiết kế,thực thi, kiểm thử,văn bản hóa.







Phân tích/ cô lập: là nhiệm vụ gồm có sự phân tích tác động, phân tích những giá trị lợi ích
và cô lập.phân tích những tác động và phân tích lợi ích bao gồm những công việc khác nhau:
quản lý thao tác cũng như các chi phí. Cô lập co liên quan đến thời gian sử dụng để hiểu
được vấn đề do đâu.
Thiết kế: thiết kế lại hệ thống bao gồm những hiểu biết cần thiết làm sao để thay đổi. cũng
như việc thay thế các tài liệu phi hình thức, tài liệu chưa có trên thực tế.
Thực thi: thay thế các mã và kiểm soát từng đơn vị thành phần, việc thay thế các mã và kiểm
soát đơn vị co liên quan đến thời gian lập trình cũng như kiểm nghiệm những thay đổi. Nó
cũng bao gồm những văn bản phi hình thức giống như các phần mềm kiểm tra kế hoạch,
kiểm tra từng đơn vị thông thường chỉ được làm trên phạm vi làm việc của từng người dùng.
Kiểm thử: bao gồm sự hợp nhất sự công nhân các phép kiểm thử. Tập hợp các kiểm thử đều
liên quan đến thời gian sử dụng của chính thành phần đó. Sự công nhận các phép kiểm thử
được thực hiện bởi chính người sử dụng để đảm bảo những thay đổi đó đều đã được thực
hiện thành công. Phép thử hồi quy đảm bảo những thay đổi đó không ảnh hưởng tới những
chức năng của các thành phần khác trong hệ thống.

Văn bản hóa: gồm hệ thống, người dùng và những tài liệu đi kèm. Hệ thống tài liệu này rất
quan trong trong tương lai.

5. Ý nghĩa của bảo trì phần mềm.
Hệ thống dù xây dựng tốt tới đâu cũng không thể hoạt động ổn định trong một thời gian dài
nếu không có bảo trì.Do đó cần phải cân đối giữa tài nguyên và công việc bảo trì phần mềm. Bảo
trì phần mềm hàng năm ở Mỹ khoảng 70 tỷ đô la cho khoảng 10 tỷ dòng code. Nokia phải dùng
tới 90 nghìn đô để sửa lỗi Y2K. Nhiêu nghiên cứu được thực hiện để xem xét giá trị của bảo trì
phần mềm, hay tỷ lệ giữa công việc phát triển phần mềm với bảo trì phần mềm. Tổng giá trị bảo
trì hệ thống khoảng 50% tổng giá trị của cả vòng đời phần mềm.
6. Phương pháp bảo trì phần mềm
Bảo trì phần mềm có thể được thực hiện theo một số phương pháp nhất định, phổ biến là ba
phương pháp:
o Quick-fix
o Interative-enhancement
o Full-reusE
a. Quick-fix

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

Hình xx: Mô tả phương pháp Quick-fix
Phương pháp nay thực hiện sự thay đổi với code của chương trình nguồn, sau đó update sự
thay đổi với các file doc đi kèm. Đây là phương pháp bảo trì đạt được tốc độ nhanh chóng nhưng
mang đến những nhược điêm như:
Vai trò của file doc bị giảm sút, do yêu cầu của người sử dụng thay đổi nhanh và có thể
đủ nhỏ để chỉ thay đổi về chương trình nguồn mà không cập nhập vào fiel docs. Hơn thế, do thay
đổi trực tiếp vào code của chương trình nguồn, quá trình bảo trì rất có thể sẽ làm vỡ thiết kế ban
đầu của phần mềm.
b. Interative-enhancement

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

Hình xx: Mô tả phương pháp Interative-enhancement
Dựa trên nhận định rằng một hệ thống khi xây dựng rất khó có thể đã đáp ứng được hết yêu
cầu của người sử dụng, phương pháp interative- enhance tiến hành xây dựng hệ thống hoàn
chỉnh dựa trên cơ sở phân tích bước đầu về yêu cầu của hệ thống, tiến hành phân tích sâu hơn
yêu cầu đặt ra đối với phần mềm dựa trên phản hồi của người sử dụng để xây dựng hệ thống
mới.
Có thể nhận thấy ưu điểm nổi bật của phương pháp này so với quick-fix là file docs của hệ thống
được cập nhật thường xuyên với mọi sự thay đổi của hệ thống.
c. Full-reuse

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

Hình xx: Mô tả phương pháp Full-reuse
Mục đích của tái sử dụng lại là nhằm tăng năng suất, chất lượng và tao điều kiện thuận lợi
cho việc chuyển đổi mã,giảm bớt thời gian chi phí để bảo trì. Có thể hiểu định nghĩa của việc tái
sử dụng phần mềm như sau: đó là việc sử dụng lại các kinh nghiệm đã co từ chính hệ thống đó
hay các hệ thống tương tự nhằm giảm bớt nỗ lực để phát triển hay bảo trì hệ thống.
Ứng dụng tư tưởng tái sử dụng, phương pháp full-reuse xây dựng hệ thống mới trên cơ sở tái
sử dụng những yếu tố phù hợp trong từng giai đoạn khi xây dựng hệ thống cũ. Do đó, phương
pháp này thích hợp cho việc xây dựng những hệ thống có vòng đời ngắn.Tăng khả năng tái sử
dụng của các component hệ thống.
Đặc biệt, khi kết hợp full-reuse và interative-enhancement có thể tăng đáng kể hiệu quả kinh
tế của quá trình bảo trì phần mềm.
7. Các vấn đề khác của bảo trì phần mềm.
a. Tăng hiệu quả quá trình bảo trì phần mềm.

Bảo trì phần mềm là giai đoạn hết sức tốn kém cả về thời gian và ngân sách, do đó cần co
những phương phát triển phần mềm và bảo trì hợp lý để giảm thiểu hao tốn do bảo trì. Chúng ta
cần áp dụng những thay đổi nhỏ với quá trình phát triển phần mềm, với quá trình bảo trì phần
mềm và phát triển kỹ thuật hỗ trợ cho quá trình bảo trì phần mềm.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
Trong quy trình phát triển phần mềm, có thể tăng hiệu năng bảo trì phần mềm bằng cách để
người chủ chốt trong quá trình bảo trì tham gia vào giai đoạn phân tich và thiết kế, như thế họ có
cơ hội hiểu sâu sắc các vấn đề của phần mềm họ cần bảo trì. Thêm vào đó, cần chuẩn hóa mọi
khâu trong phát triển phần mềm, việc chuẩn hóa sẽ giúp cho quá trình tra cứu hay sửa đổi được
thuận tiện hơn. Bản thiết kế của phần mềm cần được thiết kế sao cho dễ bảo trì.
Trong quy trình bảo trì phần mềm co thể áp dụng một số biện pháp như:


Sử dụng các công cụ hỗ trợ phát triển phần mềm. vì như đã đề cập ở trên, quá trình bảo
trì phần mềm cũng tương tự như quá trình phát triển phần mềm, việc sử dụng các công cụ
hỗ trợ phát triển phần mềm là rất cần thiết.
 Chuẩn hóa thao tác bảo trì và thiết bị môi trường bảo trì.
 Việc lưu lại thông tin bảo trì là rất cần thiết, cần phải nắm rõ tiến độ, hiệu quả cũng như
thiếu sót của quá trình bảo trì, tra cứu thông tin bảo trì thường xuyên để có những thay
đổi về kế hoạch cho phù hợp.
 Bảo trì tốt cần phải hiểu thật rõ yêu cầu cũng như thiết kế, đặc tính của phần mềm đó,
chính vì thế, đội phát triển dự án nên cử người chủ chốt của mình tiến hành bảo trì phần
mềm sau khi dự án kết thúc giai đoạn phát triển.
Trong việc phát triển những công cụ hỗ trợ bảo trì:


Cần đầu tư phát triển các công cụ hỗ trợ bảo trì phần mềm như các công cụ dịch
ngược(reverse engineering)…

 Đầu tư cho công cụ xây dựng và quản lý database cho bảo trì, các công cụ quản lý hồ sơ,
dữ liệu, chương trình nguồn, dữ liệu thử, lịch sử bảo trì.
b. Tìm hiểu về kỹ thuật dịch ngược (Reverse – engineering)
Kỹ thuật dịch ngược là một quá trình phân tích xử lý hệ thống để nhận ra các thành phần của
hệ thống và mối liên hệ giữa chúng, tạo các miêu tả về hệ thống trong một thể khác hoặc tại cấp
độ cao hơn của sự trừu tượng hóa. Kỹ thuật đảo ngược yêu cầu khi cần xử lý để hiểu một hệ
thống phần mềm trong một thời gian dài bị lỗi, các tài liệu hết hạn sử dụng, sự phức tạp của hệ
thông và thiếu hiểu biết về bảo trì hệ thống.
Mục đích của kỹ thuật dịch ngược là lấy lại các thông tin đã mất, làm chuyển đổi dễ dàng
giữa các flatfom, để cải tiến hay cung cấp các tài liệu, để cung cấp các lựa chọn xem xét, trích ra
các thành phần sử dụng lại để đối phó với sự phức tạp, để chỉ ra các mặt hiệu quả và giảm công
sức bảo trì.
Một số tool reverser phổ biến như: Decompiler/Disassembler Archive, HEX Editing Archive,
HCU Tools Archive, Miscellaneous Tools Archive…

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

II. Thực tế áp dụng tại các công ty
Trong quá trình làm bài tập lớn, chúng em đã tiến hành khảo sát đánh giá ở bốn công ty phần
mềm trên địa bàn Hà Nội


Công ty trách nhiệm hữu hạn SeLab



Công ty cổ phần Fsoft



Công ty Fitech



Công ty MISA

Tại bốn công ty này, chúng em đã tiến hành khảo sát về quy trình kiểm thử và bảo trì, cũng như
khảo sát các công cụ mà các công ty đó sử dụng. Trong đó trình đó, chúng em nhận thấy các vấn
đề sau tại các công ty:


Các công ty này đều quan tâm đến vấn đề kiểm thử, đánh giá chất lượng sản phầm của
mình. Các công ty đều có xây dựng cho mình một đội ngũ các tester chuyên biệt để đáp
ứng được yêu cầu sử dụng của mình



Các công ty trong quá trình kiểm thử đều thực hiện đầy đủ các chiến lược kiểm thử. Hầu
hết, unit test đều được đặt ở khâu lập trình viên – người phát triển hệ thống. Bộ phận
kiểm thử thực hiện các khâu khác của quá trình kiểm thử.



Hầu hết các công ty chỉ sử dụng phương pháp kiểm tra hộp đen (có thể cùng hộp xám)
chứ không sử dụng phương pháp kiểm tra hộp trắng. Phương pháp kiểm tra hộp trắng chỉ
được sử dụng trong một vài trường hợp đặc biệt. Ví dụ như khảo sát MISA chúng em
nhận được khẳng định của anh trưởng phòng là hiện tại MISA chỉ sử dụng kiểm thử hộp
đen và không sử dụng các phương pháp kiểm thử khác.



Bên cạnh một số phương pháp và chiến lược kiểm thử nêu trong phần cơ sở lý thuyết,
một số công ty còn sử dụng các phương pháp khác như kiểm thử tải. Đây là loại kiểm
thử xác định khả năng chịu đựng của hệ thống, phần mềm trước nhiều yêu cầu khác nhau
cùng lúc từ phía khách hàng…



Hầu hết các công ty chưa có quy trình chuẩn trong kiểm thử phần mềm mà chỉ làm việc
dựa trên thói quen làm việc hàng ngày. Một số công ty như MISA,Fsoft có áp dụng cho
mình một vài chuẩn riêng trong các khâu làm việc. Tuy nhiên xét trên cả quá trình kiểm
thử thì các công ty này vẫn chưa xây dựng được một chuẩn thống nhất, một quy trình
xuyên suốt.



Hầu hết các công ty đều chưa có công cụ hỗ trợ kiểm thử. Tuy nhiên một số công ty đã
sử dụng một hay một vài công cụ để hỗ trở kiểm thử, quản lý lỗi. Ví dụ như Fsoft, mỗi
team, mỗi dự án họ sử dụng một công cụ hỗ trợ quản lý lỗi riêng, tùy theo từng dự án.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
Tuy nhiên nếu dự án đó không cung cấp các công cụ hỗ trợ thì trong bản thân Fsoft cũng
có một hệ thống quản lý lỗi của riêng mình là DMS (defect manager system). Mỗi nhân
viên khitham gia vào trong công ty đều được học cách sử dụng hệ thống này. Tuy nhiên
hầu như không được sử dụng đến do mỗi dự án đều có công cụ riêng của mình. Công ty
MISA lại sử dụng nhiều công cụ hơn như Bug Jira để quản lý lỗi (đây là hệ thống được
đánh giá tốt nhất và phù hợp nhất với thực tế của MISA). Exel để quản lý tescase, Source
vault để quản lý tài liệu (xem thêm phần phụ lục các biên bản khảo sát).



Hầu hết các công ty đã khảo sát, việc bảo trì không được chú trọng hoặc không được tách
riêng ra thành một nhóm, một phòng ban. Việc bảo trì hệ thống đươc mặc định gần như
100% là do những người phát triển hệ thống xử lý vì họ là người hiểu hệ thống nhất.

Bên cạnh nhưng công cụ khảo sát được tai các công ty, hiện nay cũng có khá nhiều tool hỗ trợ
kiểm thử như:


UCM(Unified Change Management).



Junit framework hỗ trợ xây dựng testing tự động trên Java



QuickTest proessional 8.2

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm

III. Bài học kinh nghiệm và đánh giá kết luận của nhóm
Trong quá trình tìm hiểu đề tài, cả nhóm chúng em đã rút ra được những bài học và kết luận
sau:


Kiểm thử và bảo trì phần mềm là hai quá trình vô cùng quan trọng trong vòng đời phát
triển một phần mềm. Đây là những quá trình không thể thiếu trong việc phát triển một

Xem thêm: Bạn đã biết Việt Nam hiện có những dịch vụ 5 sao nào???

phần mềm thương mại.



Kiểm thử và bảo trì phần mềm có nhiều kĩ thuật khác nhau, và thực tế các công ty trên
địa bàn Hà Nội cũng chỉ sử dụng các kĩ thuật đó trong công việc của mình. Tuy nhiên,
dựa trên đặc thù của từng công ty, việc bảo trì, kiểm thử phần mềm sẽ có những đặc điểm
khác nhau. Ví dụ như kiểm thử hộp trắng chỉ được fsoft sử dụng với các chương trình
nhỏ như lập trình mobile, còn các hệ thống lớn thì không sử dụng. Còn với MISA chỉ sử
dụng kiểm thử hộp đen trong quá trình kiểm thử và cho rắng đây là phương pháp kiểm
thử thích hợp nhất đối với công ty mình.



Trong thực tế, khi một tổ đội xây dưng phần mềm chưa nhiều, và còn hạn hẹp về mặt
quân số cũng như chất lượng, một số công ty không tách chuyên biệt các cá nhân vào
trong một nhóm (một phòng) quản lý chất lượng phần mềm. Các công ty sử dụng việc đa
nhiệm vụ cho một cá nhân. Từ đó cũng nâng cao được chất lượng, thời gian kiểm thử.
Tuy nhiên những phương pháp đó không áp dùng được với các phần mềm hệ thống lớn.
Do người kiểm thử và người lập trình là một nên không mở rộng được các góc nhìn,
không có các đánh giá chuẩn xác, khách quan về phần mềm cần kiểm thử, bảo trì.Bên
cạnh đó, nếu quá trình phát triển phần mềm, kiểm thử phần mềm không được tách ra
chuyên biện, lập trình viên sẽ bị trồng chéo công việc dễ bị nhầm lẫn.



Trong quá trình xây dựng và phát triển phần mềm, việc sử dụng công cụ hỗ trợ là vô cùng
cần thiết. Có những công cụ hỗ trợ sử dủng rất đơn giản như exel, word ..vv Điểm quan
trọng là cần biết phối hợp các công cụ này với công việc đặc thù của công ty mình. Qua
nhận xét đánh giá, chúng em nhận thấy MISA là một mô hình điển hình của việc áp dụng

hiệu quả các công cụ hỗ trợ kiểm thử trong việc quản lý testcase, quản lý bug, quản lý tài
liệu, quản lý các release phần mềm.



Việc bảo trì phần mềm theo chúng em cần được đề cao hơn. Mặc dù phần này sẽ ít cần
thiết nếu như kiểm thử phần mềm càng ngày càng nâng cao chất lượng của mình để phần
mềm hoàn thiện hơn trước khi được cung cấp rộng rãi tới các khách hàng. Tuy nhiên vãn
cần đẩy mạnh bảo trì phần mèm để đáp ứng các nhu cầu khác nhau của người sử dụng.
Từ đó nâng cao chất lượng của khách hàng.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm
Tài liệu tham khảo


Roger S.Pressman, Ph.D: Software engineering A practitioner ‘s approach fifth
edition – MCGraw – Hill series in computer science (file pdf)



Ian Sommerville: Software engineering, 8th Edition (file pdf)



Cem Kaner,J.D., Ph.D: Exploratory Testing (file ppt) Keynote at QAI November
17,2006.



John E. Bentley, Wachovia Bank, Charlotte NC : Software Testing Fundamentals—
Concepts, Roles, and Terminology (file pdf)



Gerardo Canfora and Aniello Cimitile (University of Sannio, Faculty of Engineering
at Benevento Palazzo Bosco Lucarelli, Piazza Roma 82100, Benevento Italy):
Software Maintenance – 29 November, 2000



The Art of Software Testing, Glenford J. Myers, Second Edition, John Wiley and
Sons, Inc.

Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmMục lụcI. Tìm hiểu triết lý ……………………………………………………………………………………………….. 3A. Kiểm thử phần mềm ……………………………………………………………………………………………… 31. Tổng quan về kiểm thử phần mềm ……………………………………………………………………….. 32. Các kĩ thuật kiểm thử phần mềm ………………………………………………………………………….. 43. Chiến lược kiểm thử phần mềm …………………………………………………………………………… 6B. a. Kiểm thử đơn vị chức năng – Unit test ………………………………………………………………………….. 7 b. Kiểm thử tích hợp – Intergration Test …………………………………………………………….. 7 c. Kiểm thử mạng lưới hệ thống – System Test ………………………………………………………………….. 8 d. Kiểm thử gật đầu loại sản phẩm – Acceptance Test …………………………………………… 10 e. Một số kế hoạch kiểm thử khác …………………………………………………………………. 10B ảo trì phần mềm ………………………………………………………………………………………………. 121. Tổng quan về bảo trì phần mềm. ………………………………………………………………………… 122. Quy trình bảo trì phần mềm. ……………………………………………………………………………… 143. Khó khăn của bảo trì phần mềm …………………………………………………………………………. 154. Nhiệm vụ của bảo trì phần mềm. ……………………………………………………………………….. 175. Ý nghĩa của bảo trì phần mềm. ………………………………………………………………………….. 176. Phương pháp bảo trì phần mềm …………………………………………………………………………. 177. Các yếu tố khác của bảo trì phần mềm. ………………………………………………………………. 20II. Thực tế vận dụng tại những công ty …………………………………………………………………………… 22III. Bài học kinh nghiệm tay nghề và nhìn nhận Tóm lại của nhóm …………………………………………….. 24IV. Tài liệu tìm hiểu thêm …………………………………………………………………………………………….. 25V. Phụ lục ……………………………………………………………………………………………………………… 261. Biên bản khảo sát công ty nghĩa vụ và trách nhiệm hữu hạn SeLab …………………………………………… 262. Biên bản khảo sát công ty FPT Software ……………………………………………………………… 283. Biên bản khảo sát công ty MISA. ……………………………………………………………………….. 31B ài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmI. Tìm hiểu lý thuyếtA. Kiểm thử phần mềm1. Tổng quan về kiểm thử phần mềma. Khái niệm kiểm thử phần mềmKiểm thử phần mềm là quy trình khảo sát một mạng lưới hệ thống hay thành phần dưới những điều kiệnxác định, quan sát và ghi lại những hiệu quả, và nhìn nhận một góc nhìn nào đó của mạng lưới hệ thống haythành phần đó. ( Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ nghệ phần mềmIEEE Standard Glossary of Software Engineering Terminology ). Kiểm thử phần mềm là quy trình thực thi một chương trình với mục tiêu tìm lỗi. ( Theo “ TheArt of Software Testing ” – Nghệ thuật kiểm thử phần mềm ). Kiểm thử phần mềm là hoạt động giải trí khảo sát thực tiễn mẫu sản phẩm hay dịch vụ phần mềm trongđúng môi trường tự nhiên chúng dự tính sẽ được tiến hành nhằm mục đích cung ứng cho người có quyền lợi liên quannhững thông tin về chất lượng của mẫu sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thửphần mềm là tìm ra những lỗi hay khiếm khuyết phần mềm nhằm mục đích bảo vệ hiệu suất cao hoạt động giải trí tốiưu của phần mềm trong nhiều ngành khác nhau. ( Theo Bách khoa toàn thư mở Wikipedia ). Có thể định nghĩa một cách dễ hiểu như sau : Kiểm thử phần mềm là một tiến trình hay mộttập hợp những tiến trình được phong cách thiết kế để bảo vệ mã hóa máy tính triển khai theo cái mà chúng đãđược phong cách thiết kế để làm, và không thực thi bất kể thứ gì không mong ước. Đây là một pha quantrọng trong quy trình tăng trưởng mạng lưới hệ thống, giúp cho người kiến thiết xây dựng mạng lưới hệ thống và người mua thấyđược mạng lưới hệ thống mới đã cung ứng nhu yếu đặt ra hay chưab. Phân loạiCó hai loại kiểm thử phần mềm chính đó là kiểm thử tĩnh ( static testing ) và kiểm thử động ( dinamic testing ). Kiểm thử tĩnh – Static testingLà chiêu thức thử phần mềm yên cầu phải duyệt lại những nhu yếu và những đặc tả bằng tay, trải qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết cụ thể mà không cần chạy chươngtrình. Kiểu kiểm thử này thường được sử dụng bởi nhân viên phong cách thiết kế người mà viết mã lệnhmột mình. Kiểm thử tĩnh cũng hoàn toàn có thể được tự động hóa. Nó sẽ thực thi kiểm tra hàng loạt gồm có cácchương trình được nghiên cứu và phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ vềcú pháp của chương trình. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmKiểm thử động – Dynamic testingLà giải pháp thử phần mềm trải qua việc dùng máy chạy chương trình để tìm hiểu trạngthái tác động ảnh hưởng của chương trình. Đó là kiểm thử dựa trên những ca kiểm thử xác lập bằng sự thựchiện của đối tượng người dùng kiểm thử hay chạy những chương trình. Kiểm thử động kiểm tra phương pháp hoạtđộng động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ mạng lưới hệ thống tới những biến luôn thay đổitheo thời hạn. Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thửđộng thực sự gồm có thao tác với phần mềm, nhập những giá trị nguồn vào và kiểm tra xem liệu đầura có như mong ước hay không. Các giải pháp kiểm thử động gồm có kiểm thử Unit – UnitTests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử mạng lưới hệ thống – System Tests, và Kiểm thửchấp nhận mẫu sản phẩm – Acceptance Tests. c. Mục tiêu của kiểm thử phần mềmKiểm thử là một quy trình thực thi chương trình với mục tiêu là tìm ra lỗi / những yếu điểmcủa chương trình. Một trường hợp kiểm thử tốt là một trường hợp có năng lực lớn trong việc tìm ra nhữnglỗi chưa được phát hiện. Một trường hợp kiểm thử không tốt ( không thành công xuất sắc ) là một trường hợp mà khả năngtìm thấy những lỗi chưa biết đến là rất ít. Mục tiêu của kiểm thử phần mềm là phong cách thiết kế những trường hợp kiểm thử để hoàn toàn có thể pháthiện một cách có mạng lưới hệ thống những loại lỗi khác nhau và triển khai việc đó với lượng thờigian và tài nguyên tối thiểu hoàn toàn có thể. 2. Các kĩ thuật kiểm thử phần mềm. Ba trong số những kĩ thuật kiểm thử phần mềm là kiểm thử hộp đen, kiểm thử hộp trắng, vàkiểm thử hộp xám. a. Kiểm thử hộp đen – Black box testingMột trong những kế hoạch kiểm thử quan trọng là kiểm thử hộp đen, hướng tài liệu, hay hướng vào / ra. Kiểm thử hộp đen xem chương trình như thể một “ hộp đen ”. Mục đích củabạn là trọn vẹn không chăm sóc về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung chuyên sâu vào tìm những trường hợp mà chương trình không triển khai theo cácđặc tả của nó. Theo hướng tiếp cận này, tài liệu kiểm tra được lấy chỉ từ những đặc tả. Các chiêu thức kiểm thử hộp đeno Phân lớp tương tự – Equivalence partitioning. o Phân tích giá trị biên – Boundary value analysis. o Kiểm thử mọi cặp – All-pairs testing. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmo Kiểm thử fuzz – Fuzz testing. o Kiểm thử dựa trên quy mô – Model-based testing. o Ma trận dấu vết – Traceability matrix. o Kiểm thử thăm dò – Exploratory testing. o Kiểm thử dựa trên đặc tả – Specification-base testing. Kiểm thử dựa trên đặc tả tập trung chuyên sâu vào kiểm tra tính thiết thực của phần mềm theonhững nhu yếu thích hợp. Do đó, kiểm thử viên nhập tài liệu vào, và chỉ thấy tài liệu ra từđối tượng kiểm thử. Mức kiểm thử này thường nhu yếu những ca kiểm thử triệt để được cungcấp cho kiểm thử viên mà khi đó hoàn toàn có thể xác định là so với tài liệu nguồn vào đã cho, giá trịđầu ra ( hay phương pháp hoạt động giải trí ) có giống với giá trị mong ước đã được xác lập trong cakiểm thử đó hay không. Kiểm thử dựa trên đặc tả là thiết yếu, nhưng không đủ để để ngănchặn những rủi ro đáng tiếc chắc như đinh. Kiểm thử hộp đen không có mối tương quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơngiản tâm niệm là : một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy yên cầu và bạn sẽ đượcnhận ”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “ giống như là đi trong bóng tối màkhông có đèn vậy ”, chính bới kiểm thử viên không biết những phần mềm được kiểm tra thực sựđược thiết kế xây dựng như thế nào. Đó là nguyên do mà có nhiều trường hợp mà một kiểm thử viên hộpđen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ hoàn toàn có thể chỉ cần kiểm trabằng 1 ca kiểm thử duy nhất, và / hoặc 1 số ít phần của chương trình không được kiểm trachút nào. Do vậy, kiểm thử hộp đen có ưu điểm của “ một sự nhìn nhận khách quan ”, mặtkhác nó lại có điểm yếu kém của “ thăm dò mù ”. b. Kiểm thử hộp trắng – White box testingLà một kế hoạch kiểm thử khác, trái ngược trọn vẹn với kiểm thử hộp đen, kiểm thử hộptrắng hay kiểm thử hướng logic được cho phép bạn khảo sát cấu trúc bên trong của chương trình. Chiến lược này xuất phát từ tài liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy vấn vào cấu trúc tài liệu và giải thuật bên trong chương trình ( và cả mãlệnh thực thi chúng ). Các chiêu thức kiểm thử hộp trắngo Kiểm thử giao diện lập trình ứng dụng – API testing ( application programminginterface ) : là chiêu thức kiểm thử của ứng dụng sử dụng những API công khai minh bạch vàriêng tư. o Bao phủ mã lệnh – Code coverage : tạo những kiểm tra để cung ứng 1 số ít tiêu chuẩnvề bao trùm mã lệnh. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmo Các giải pháp gán lỗi – Fault injection. o Các chiêu thức kiểm thử hoán chuyển – Mutation testing methods. o Kiểm thử tĩnh – Static testing : kiểm thử hộp trắng gồm có mọi kiểm thử tĩnh. Phương pháp kiểm thử hộp trắng cũng hoàn toàn có thể được sử dụng để nhìn nhận sự hoàn thành xong củamột bộ kiểm thử mà được tạo cùng với những giải pháp kiểm thử hộp đen. Điều này cho phépcác nhóm phần mềm khảo sát những phần của 1 mạng lưới hệ thống ít khi được kiểm tra và bảo vệ rằngnhững điểm công dụng quan trọng nhất đã được kiểm tra. c. Kiểm thử hộp xám – Gray box testingKiểm thử hộp xám yên cầu phải có sự truy vấn tới cấu trúc tài liệu và giải thuật bên trong chonhững mục tiêu phong cách thiết kế những ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộpđen. Việc thao tác tới tài liệu nguồn vào và định dạng tài liệu đầu ra là không rõ ràng, giống nhưmột chiếc “ hộp xám ”, do tại nguồn vào và đầu ra rõ ràng là ở bên ngoài “ hộp đen ” mà chúng tavẫn gọi về mạng lưới hệ thống được kiểm tra. Sự độc lạ này đặc biệt quan trọng quan trọng khi quản trị kiểm thửtích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai nhân viên phong cách thiết kế khácnhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám hoàn toàn có thể cũng bao gồmcả phong cách thiết kế so sánh để quyết định hành động, ví dụ, giá trị biên hay thông tin lỗi. 3. Chiến lược kiểm thử phần mềmKiểm thử phần mềm có nhiều kế hoạch khác nhau : kiểm thử đơn vị chức năng, kiểm thử tích hợp, kiểm thử mạng lưới hệ thống và kiểm thử gật đầu sản phẩmHình 01 : Sơ đồ phân loại kế hoạch kiểm thửBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềma. Kiểm thử đơn vị chức năng – Unit testMột đơn vị chức năng là một thành phần phần mềm nhỏ nhất mà ta hoàn toàn có thể kiểm thử được. Ví dụ, cáchàm ( Function ), thủ tục ( Procedure ), lớp ( Class ) hay phương pháp ( Method ) đều hoàn toàn có thể đượcxem là Unit. Vì Unit được chọn để kiểm tra thường có size nhỏ và tính năng hoạt động giải trí đơn thuần, tất cả chúng ta không khó khăn vất vả gì trong việc tổ chức triển khai kiểm thử, ghi nhận và nghiên cứu và phân tích tác dụng kiểm thử. Nếu phát hiện lỗi, việc xác lập nguyên do và khắc phục cũng tương đối thuận tiện vì chỉkhoanh vùng trong một đơn thể Unit đang kiểm tra. Một nguyên tắc đúc rút từ thực tiễn : thời giantốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm chi phí rất nhiều thời hạn và ngân sách cho việc kiểmthử và sửa lỗi ở những mức kiểm thử sau đó. Unit Test thường do lập trình viên thực thi. Công đoạn này cần được thực thi càng sớmcàng tốt trong tiến trình viết code và xuyên suốt chu kỳ luân hồi tăng trưởng phần mềm. Thông thường, Unit Test yên cầu kiểm thử viên có kỹ năng và kiến thức về phong cách thiết kế và code của chương trình. Mục đích củaUnit Test là bảo vệ thông tin được giải quyết và xử lý và xuất ( khỏi Unit ) là đúng chuẩn, trong mối tương quanvới dữ liệu nhập và công dụng của Unit. Điều này thường yên cầu toàn bộ những nhánh bên trong Unitđều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi cáclệnh được thực thi trong một Unit. Ví dụ : chuỗi những lệnh sau điều kiện kèm theo If và nằm giữa then … elselà một nhánh. Thực tế việc lựa chọn những nhánh để đơn giản hóa việc kiểm thử và quét hết Unitđòi hỏi phải có kỹ thuật, đôi lúc phải dùng thuật toán để lựa chọn. Cùng với những mục kiểm thử khác, Unit Test cũng yên cầu phải chuẩn bị sẵn sàng trước những ca kiểm thử ( Test case ) hoặc ngữ cảnh kiểm thử ( Test script ), trong đó chỉ định rõ tài liệu nguồn vào, những bướcthực hiện và tài liệu đầu ra mong ước. Các Test case và Test script này nên được giữ lại để táisử dụng. b. Kiểm thử tích hợp – Intergration TestIntegration test tích hợp những thành phần của một ứng dụng và kiểm thử như một ứng dụng đãhoàn thành. Trong khi Unit Test kiểm tra những thành phần và Unit riêng không liên quan gì đến nhau thì Intgration Test kếthợp chúng lại với nhau và kiểm tra sự tiếp xúc giữa chúng. Hai tiềm năng chính của Integration Test : o Phát hiện lỗi tiếp xúc xảy ra giữa những Unit. o Tích hợp những Unit đơn lẻ thành những mạng lưới hệ thống nhỏ ( Subsystem ) và ở đầu cuối lànguyên mạng lưới hệ thống hoàn hảo ( System ) chuẩn bị sẵn sàng cho kiểm thử ở mức mạng lưới hệ thống ( System Test ). Trong Unit Test, lập trình viên nỗ lực phát hiện lỗi tương quan đến công dụng và cấu trúc nộitại của Unit. Có 1 số ít phép kiểm thử đơn thuần trên tiếp xúc giữa Unit với những thành phần liênquan khác, tuy nhiên mọi tiếp xúc tương quan đến Unit chỉ thật sự được kiểm tra không thiếu khi cácUnit tích hợp với nhau trong khi triển khai Integration Test. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmTrừ 1 số ít ít ngoại lệ, Integration Test chỉ nên triển khai trên những Unit đã được kiểm tracẩn thận trước đó bằng Unit Test, và toàn bộ những lỗi mức Unit đã được thay thế sửa chữa. Một số ngườihiểu sai rằng Unit một khi đã qua quá trình Unit Test với những tiếp xúc giả lập thì không cần phảithực hiện Integration Test nữa. Thực tế việc tích hợp giữa những Unit dẫn đến những tình huốnghoàn toàn khác. Một kế hoạch cần chăm sóc trong Integration Test là nên tích hợp dần từng Unit. Một Unittại một thời gian được tích hợp vào một nhóm những Unit khác đã tích hợp trước đó và đã hoàn tấtcác đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm thử tiếp xúc của Unit mới thêm vàovới mạng lưới hệ thống những Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đirất nhiều, và sai sót sẽ giảm đáng kể. Có 4 loại kiểm thử trong Integration Test : o Kiểm thử cấu trúc ( Structure Test ) : Tương tự White Box Test, kiểm thử cấu trúcnhằm bảo vệ những thành phần bên trong của một chương trình chạy đúng và chútrọng đến hoạt động giải trí của những thành phần cấu trúc nội tại của chương trình chẳng hạncác câu lệnh và nhánh bên trong. o Kiểm thử công dụng ( Functional Test ) : Tương tự Black Box Test, kiểm thử chứcnăng chỉ chú trọng đến công dụng của chương trình, mà không chăm sóc đến cấutrúc bên trong, chỉ khảo sát tính năng của chương trình theo nhu yếu kỹ thuật. o Kiểm thử hiệu năng ( Performance Test ) : Kiểm thử việc quản lý và vận hành của mạng lưới hệ thống. o Kiểm thử năng lực chịu tải ( Stress Test ) : Kiểm thử những số lượng giới hạn của mạng lưới hệ thống. c. Kiểm thử mạng lưới hệ thống – System TestMục đích System Test là kiểm thử phong cách thiết kế và hàng loạt mạng lưới hệ thống ( sau khi tích hợp ) có thỏamãn nhu yếu đặt ra hay không. System Test mở màn khi tổng thể những bộ phận của phần mềm đã được tích hợp thành công xuất sắc. Thông thường loại kiểm thử này tốn rất nhiều sức lực lao động và thời hạn. Trong nhiều trường hợp, việc kiểm thử yên cầu 1 số ít thiết bị phụ trợ, phần mềm hoặc phần cứng đặc trưng, đặc biệt quan trọng là cácứng dụng thời hạn thực, mạng lưới hệ thống phân bổ, hoặc mạng lưới hệ thống nhúng. Ở mức độ mạng lưới hệ thống, ngườikiểm thử cũng tìm kiếm những lỗi, nhưng trọng tâm là nhìn nhận về hoạt động giải trí, thao tác, sự đáng tin cậy vàcác nhu yếu khác tương quan đến chất lượng của toàn mạng lưới hệ thống. Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng cáchành vi và lỗi trên toàn mạng lưới hệ thống, còn Integration Test chú trọng sự tiếp xúc giữa những đơn thểhoặc đối tượng người tiêu dùng khi chúng thao tác cùng nhau. Thông thường ta phải triển khai Unit Test vàIntegration Test để bảo vệ mọi Unit và sự tương tác giữa chúng hoạt động giải trí đúng chuẩn trước khithực hiện System Test. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmSau khi triển khai xong Integration Test, một mạng lưới hệ thống phần mềm đã được hình thành cùng vớicác thành phần đã được kiểm tra rất đầy đủ. Tại thời gian này, lập trình viên hoặc kiểm thử viên bắtđầu kiểm thử phần mềm như một mạng lưới hệ thống hoàn hảo. Việc lập kế hoạch cho System Test nênbắt đầu từ tiến trình hình thành và nghiên cứu và phân tích những nhu yếu. System Test kiểm thử cả những hành vi tính năng của phần mềm lẫn những nhu yếu về chất lượngnhư độ đáng tin cậy, tính tiện nghi khi sử dụng, hiệu năng và bảo mật thông tin. Mức kiểm thử này đặc biệt quan trọng thíchhợp cho việc phát hiện lỗi tiếp xúc với phần mềm hoặc phần cứng bên ngoài, ví dụ điển hình những lỗi ” ùn tắc ” ( deadlock ) hoặc chiếm hữu bộ nhớ. Sau quy trình tiến độ System Test, phần mềm thườngđã chuẩn bị sẵn sàng cho người mua hoặc người dùng sau cuối kiểm thử gật đầu loại sản phẩm ( Acceptance Test ) hoặc dùng thử ( Alpha / Beta Test ). Đòi hỏi nhiều sức lực lao động, thời hạn và tính đúng mực, khách quan, System Test thường đượcthực hiện bởi một nhóm kiểm thử viên trọn vẹn độc lập với nhóm tăng trưởng dự án Bất Động Sản. Bản thânSystem Test lại gồm nhiều loại kiểm thử khác nhau, phổ cập nhất gồm : o Kiểm thử tính năng ( Functional Test ) : Bảo đảm những hành vi của mạng lưới hệ thống thỏa mãn nhu cầu đúngyêu cầu phong cách thiết kế. o Kiểm thử hiệu năng ( Performance Test ) : Bảo đảm tối ưu việc phân chia tài nguyên mạng lưới hệ thống ( ví dụ bộ nhớ ) nhằm mục đích đạt những chỉ tiêu như thời hạn giải quyết và xử lý hay cung ứng câu truy vấn … o Kiểm thử năng lực chịu tải ( Stress Test hay Load Test ) : Bảo đảm mạng lưới hệ thống quản lý và vận hành đúngdưới áp lực đè nén cao ( ví dụ nhiều người truy xuất cùng lúc ). Stress Test tập trung chuyên sâu vào những trạngthái tới hạn, những ” điểm chết “, những trường hợp không bình thường như đang thanh toán giao dịch thì ngắt liên kết ( Open nhiều trong kiểm tra thiết bị như POS, ATM. .. ) … o Kiểm thử thông số kỹ thuật ( Configuration Test ). o Kiểm thử bảo mật thông tin ( Security Test ) : Bảo đảm tính toàn vẹn, bảo mật thông tin của tài liệu và của hệthống. o Kiểm thử năng lực hồi sinh ( Recovery Test ) : Bảo đảm mạng lưới hệ thống có năng lực khôi phụctrạng thái không thay đổi trước đó trong trường hợp mất tài nguyên hoặc tài liệu ; đặc biệt quan trọng quan trọngđối với những mạng lưới hệ thống thanh toán giao dịch như ngân hàng nhà nước trực tuyến … Nhìn từ quan điểm người dùng, những Lever kiểm thử trên rất quan trọng : Chúng bảo vệ hệthống đủ năng lực thao tác trong môi trường tự nhiên thực. Lưu ý là không nhất thiết phải triển khai tổng thể những loại kiểm thử nêu trên. Tùy nhu yếu và đặctrưng của từng mạng lưới hệ thống, tuỳ năng lực và thời hạn được cho phép của dự án Bất Động Sản, khi lập kế hoạch, người. Quản lý dự án Bất Động Sản sẽ quyết định hành động vận dụng những loại kiểm thử nào. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmd. Kiểm thử đồng ý mẫu sản phẩm – Acceptance TestThông thường, sau quá trình System Test là Acceptance Test, được người mua thực thi ( hoặc ủy quyền cho một nhóm thứ ba triển khai ). Mục đích của Acceptance Test là để chứngminh phần mềm thỏa mãn nhu cầu toàn bộ nhu yếu của người mua và người mua gật đầu mẫu sản phẩm ( vàtrả tiền thanh toán giao dịch hợp đồng ). Acceptance Test có ý nghĩa rất là quan trọng, mặc dầu trong hầu hết mọi trường hợp, cácphép kiểm thử của System Test và Acceptance Test gần như tương tự như, nhưng thực chất và cáchthức triển khai lại rất độc lạ. Đối với những mẫu sản phẩm dành bán thoáng rộng trên thị trường cho nhiều người sử dụng, thôngthường sẽ trải qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta – Beta Test. Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi tăng trưởng phần mềm, lập trình viên sẽ ghi nhận những lỗi hoặc phản hồi, và lên kế hoạch sửa chữa thay thế. Với Beta Test, phầnmềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong thiên nhiên và môi trường thực, lỗi hoặc phản hồicũng sẽ gửi ngược lại cho lập trình viên để sửa chữa thay thế. Thực tế cho thấy, nếu người mua không chăm sóc và không tham gia vào quy trình phát triểnphần mềm thì tác dụng Acceptance Test sẽ xô lệch rất lớn, mặc dầu phần mềm đã trải qua tất cảcác kiểm thử trước đó. Sự xô lệch này tương quan đến việc hiểu sai nhu yếu cũng như sự mong chờcủa người mua. Ví dụ đôi lúc một phần mềm xuất sắc vượt qua những phép kiểm thử về chức năngthực hiện bởi nhóm triển khai dự án Bất Động Sản, nhưng người mua khi kiểm thử ở đầu cuối vẫn tuyệt vọng vìbố cục màn hình hiển thị nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của kháchhàng v.v… Gắn liền với tiến trình Acceptance Test thường là một nhóm những dịch vụ và tài liệu đikèm, thông dụng như hướng dẫn thiết lập, sử dụng v.v… Tất cả tài liệu đi kèm phải được update vàkiểm thử ngặt nghèo. e. Một số kế hoạch kiểm thử khácNgoài những chiên lược trên, còn 1 số ít những kế hoạch kiểm thử khác như : Kiểm thử hồi quy – Regression Testing : Theo chuẩn IEEE610. 12-90, kiểm thử hồi quy là “ sự kiểm tra lại có lựa chọn của một hệthống hay thành phần để xác định là những sự đổi khác không gây ra những hậu quả khôngmong muốn … ”. Trên trong thực tiễn, ý niệm này là chỉ ra rằng phần mềm mà đã qua được những kiểmtra trước đó vẫn hoàn toàn có thể được kiểm tra lại. Beizer định nghĩa đó là sự tái diễn những kiểm tra để chỉ rarằng cách hoạt động giải trí của phần mềm không bị biến hóa, ngoại trừ tới mức như nhu yếu. Hiển nhiênlà sự thỏa hiệp phải được thực thi giữa sự bảo vệ được đưa ra bởi kiểm thử hồi quy mỗi lầnthực hiện một sự đổi khác và những tài nguyên được nhu yếu triển khai điều đó. Kiểm thử tính đúng – Correctness testing : Tính đúng đắn là nhu yếu tối thiểu của phần mềm, là mục tiêu đa phần của kiểm thử. Kiểmthử tính đúng sẽ cần một kiểu người đáng tin nào đó, để chỉ ra cách hoạt động giải trí đúng đắn từ cáchBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmhoạt động sai lầm đáng tiếc. Kiểm thử viên hoàn toàn có thể biết hoặc không biết những chi tiết cụ thể bên trong của cácmodun phần mềm được kiểm thử, ví dụ luồng tinh chỉnh và điều khiển, luông tài liệu, v.v …. Do đó, hoặc làquan điểm hộp trắng, hoặc là quan điểm hộp đen hoàn toàn có thể được triển khai trong kiểm thử phầnmềm. Các chiêu thức kiểm thử con ngườiHai giải pháp kiểm thử con người đa phần là Code Inspections và Walkthroughs. Haiphương pháp này gồm có một nhóm người đọc và kiểm tra theo mã lệnh của chương trình. Mụctiêu của chúng là để tìm ra lỗi mà không gỡ lỗi. Một Inspection hay Walkthrough là 1 sự nâng cấp cải tiến của giải pháp kiểm tra mà lập trình viênđọc chương trình của họ trước khi kiểm thử nó. Inspections và Walkthroughs hiệu suất cao hơn là bởivì những người khác sẽ kiểm thử chương trình tốt hơn chính tác giả của chương trình đó. Inspections / Walkthroughs và kiểm thử bằng máy tính bổ trợ cho nhau. Hiệu quả tìm lỗi sẽkém đi nếu thiếu đi 1 trong 2 chiêu thức. Và so với việc sửa đổi chương trình cũng nên sửdụng những chiêu thức kiểm thử này cũng như những kỹ thuật kiểm thử hồi quy. Tổng duyệt – WalkthroughWalkthrough là một thuật ngữ miêu tả sự xem xét kỹ lưỡng của một quy trình ở mức trừutượng trong đó nhà phong cách thiết kế hay lập trình viên chỉ huy những thành viên trong nhóm và nhữngngười có chăm sóc khác trải qua một loại sản phẩm phần mềm, và những người tham gia đặt câuhỏi, và ghi chú những lỗi hoàn toàn có thể có, sự vi phạm những chuẩn tăng trưởng và những yếu tố khác. Walkthrough mã lệnh là 1 tập những thủ tục và những công nghệ tiên tiến dò lỗi cho việc đọc nhóm mã lệnh. Trong một Walkthrough, nhóm những nhà tăng trưởng – với 3 hoặc 4 thành viên là tốt nhất – thựchiện xét duyệt lại. Chỉ 1 trong những thành viên là tác giả của chương trình. Một ưu điểm khác của walkthroughs, hiệu suất cao trong ngân sách gỡ lỗi, là 1 trong thực tiễn mà khi mộtlỗi được tìm thấy, nó thường được xác định đúng chuẩn trong mã lệnh. Thêm vào đó, phương phápnày thường tìm ra 1 tập những lỗi, được cho phép sau đó những lỗi đó được sửa toàn bộ với nhau. Mặt khác, kiểm thử dựa trên máy tính, chỉ tìm ra triệu chứng của lỗi ( chương trình không kết thúc hoặc đưara tác dụng không có ý nghĩa ), và những lỗi thường được tìm ra và sửa lần lượt từng lỗi một. Thanh tra mã nguồn – Code InspectionThanh tra mã nguồn là 1 tập hợp những thủ tục và những kỹ thuật dò lỗi cho việc đọc những nhóm mãlệnh. Một nhóm kiểm duyệt thường gồm 4 người. Một trong số đó đóng vai trò là người điều tiết – một lập trình viên lão luyện và không được là tác giả của chương trình và phải không quen vớicác chi tiết cụ thể của chương trình. Người điều tiết có trách nhiệm : phân phối nguyên vật liệu và lập lịch chocác buổi kiểm duyệt, chỉ huy phiên thao tác, ghi lại tổng thể những lỗi được tìm thấy và bảo vệ làcác lỗi sau đó được sửa. Thành viên thứ hai là một lập trình viên. Các thành viên còn lại trongnhóm thường là nhà phong cách thiết kế của chương trình ( nếu nhà phong cách thiết kế khác lập trình viên ) và mộtchuyên viên kiểm thử. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmB. Bảo trì phần mềm1. Tổng quan về bảo trì phần mềm. a. Định nghĩaBảo trì phần mềm là quy trình tiến độ sau cuối và tốn kém nhất trong quá trình tăng trưởng phầnmềm. Các nhà nghiên cứu đã đưa ra nhiều định nghĩa về bảo trì phần mềm như : o Bảo trì phần mềm là sự đổi khác phần mềm sau khi nó đã được chuyển giao cho kháchhàng. ( theo Martin và McLure 1983 ) o Bảo trì phần mềm bao hàm vòng đời phần mềm từ lúc nó được tiến hành đến kếtthúc. ( Von Mayrhauser 1990 ). o Bảo trì phần mềm là sự đổi khác mã nguồn và những tài liệu tương quan vì một yếu tố hoặc vìsự thiết yếu phải tăng trưởng. mục tiêu là đổi khác phần mềm hiện có trong khi vẫn giữnguyên tính toàn vẹn của nó. ( ISO / IEC 12207 1995 ). o Bảo trì phần mềm là sự nâng cấp cải tiến của một loại sản phẩm phần mềm sau khi đã được bào giaonhằm sửa lỗi, tăng hiệu suất hoặc những thuộc tính khác, hoặc làm cho phần mềm thích ứngvới những đổi khác trong thiên nhiên và môi trường. ( IEE 1219 1998 ). Vậy tất cả chúng ta hoàn toàn có thể hiểu bảo trì phần mềm là là quy trình sửa đổi một bộ phận hoặc toàn bộsản phẩm phần mềm sau khi đã chuyển giao nhằm mục đích sửa lỗi, cải tổ tính năng hoặc để phần mềm cóthể phân phối những biến hóa của môi trường tự nhiên. b. Phân loạiBảo trì phần mềm gồm có : Bảo trì tu sửa ( Corrective Maintenance ), bảo trì thíchnghi ( Adaptive Maintenance ), bảo trì nâng cấp cải tiến ( Perfective Maintenance ) và bảo trì phòng ngừa. Bảo trì tu sửa : là bảo trì nhằm mục đích sửa những lỗi hoặc hỏng hóc phát sinh. Lỗi và hỏng hóc phátsinh hoàn toàn có thể do những nguyên do sau : o Lỗi do sơ ý của lập trình viên hoặc do kiểm thử chưa chặto Lỗi do nghiên cứu và phân tích nhu yếu người mua chưa đúng mực và đầy đủo Tính năng của phần mềm chưa đáp ưng được nhu yếu trong thực tiễn của người mua : bộnhớ, phong cách thiết kế … o Thiếu sự chuẩn hóa trong tăng trưởng phần mềm … Bảo trì tu sửa thường sử dụng kỹ thuật dịch ngược ( reverse enginnering ) dò theo phong cách thiết kế đểtìm lỗiBảo trì thích nghi : ( Adaptive Maintenance ) là chỉnh sửa phần mềm theo sự biến hóa của môitrường như sự đổi khác của phần cứng, OS hoặc những thiết bị đi kèm. Bảo trì nâng cấp cải tiến : đổi khác phần mềm theo những nhu yếu ngày càng hoàn thành xong hơn, đầy đủhơn, hài hòa và hợp lý hơn. Đây là hình thái bảo trì phổ cập nhất trong trong thực tiễn. Chức năng đáng quantâm của hình thức bảo trì này là nâng cao mạng lưới hệ thống và tăng những hoạt động giải trí thực thi của hệthống, giúp đổi khác giao diện của mạng lưới hệ thống với người sử dụng. Một phần thành công xuất sắc củaviệc chăm nom phần mềm sẽ giúp cho những đổi khác tiếp theo. Các nguyên do chính của bảotrì này là : o Muốn nâng cao hiệu suất nên thường nâng cấp cải tiến phương pháp truy nhậpo Mở rộng thêm công dụng cho mạng lưới hệ thống. o Cải tiến quản trị làm nâng cấp cải tiến tư liệu quản lý và vận hành và trình tự việc làm. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmo Thay đổi người dùng hoặc thao tác. Hình thức bảo trì này thường sử dụng kỹ thuật gọi là “ tái kỹ nghệ ” ( re-engineering ) để đưa ramột mạng lưới hệ thống cùng tính năng nhưng có chất lượng cao hơn. Có thể triển khai theo những bước : xâydựng lưu đồ phần mềm, tìm biểu thức Bun cho từng dãy xử ly, biên dịch bảng chân lý và tái cấutrúc phần mềm. Bảo trì phòng ngừa : là sự tu chỉnh phần mềm có tính đến tương lai của phần mềm đó sẽđược lan rộng ra và đổi khác như thế nào. Bảo trì phòng ngừa gồm có những hoạt động giải trí để tăngkhả năng duy trì của mạng lưới hệ thống, như update tài liệu, thêm module. Việc sử đổi so với mộthệ thống mới là rất phức tạp, hoàn toàn có thể làm hư hại những cấu trúc. Với phần mềm được phong cách thiết kế tốtthì hình thái bảo trì này gần như không gặp. Sự sửa đổi này nhằm mục đích cung ứng nhu yếu thay đổicủa người sử dụng. Hình thức này thứ nhất cần triển khai những biến hóa trên phong cách thiết kế không tường minh củaphần mềm, hiểu rõ hoạt động giải trí của phần mềm, thực thi phong cách thiết kế và lập trình lại. Hình thức bảo trì phòng ngừa rất ít đươc sử dụng trong thực tiễn, đa phần vẫn là hình thức bảo trìcải tiến. Biểu đồ sau cho ta thấy sự đối sánh tương quan giữa 3 hình thức bảo trì tiên phong. Hình xx : Tỉ lệ những hình thức bảo trì phần mềmc. Những đặc thù của phần mềm tác động ảnh hưởng tới bảo trì phần mềm. Tiến hành bảo trì phần mềm cần phải biết những đặc tính nào của phần mềm sẽ ảnh hưởngtới việc làm bảo trì chính nó. Theo Martin và McClure thì size của mạng lưới hệ thống, tuổi hệBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmthống, số lượng và đầu ra tài liệu, loại chương trình ứng dụng, ngôn từ lập trình và Lever cấutrúc là những đặc điểm ảnh hưởng trực tiếp tới việc làm bảo trì phần mềm. Hệ thống càng lớn thì nhu yếu càng cao sự bảo trì để mạng lưới hệ thống không thay đổi và ngăn nắp hơn, giảmthiểu khó khăn vất vả do sự phức tạp của những tính năng gây nên. Theo Van Vliet thì việc bảo trì phầnmềm sẽ ít thiết yếu hơn nếu có càng ít dòng mã. Độ dài mã nguồn là yếu tố chính để xác địnhtổng ngân sách trong suốt quy trình bảo trì cũng như quy trình tăng trưởng phần mềm. 2. Quy trình bảo trì phần mềm. Quy trình của bảo trì phần mềm tương tự như như quy trình tiến độ tăng trưởng phần mềm : nghiên cứu và phân tích, thiếtkế, thực thi, kiểm thử. Bảo trì hoàn toàn có thể là sửa đổi phần mềm cũ, cũng co thể triển khai xây dựngphần mềm mới trọn vẹn. Hiểu phần mềmLoại bảoXây dựng phần mềm mớitrì ? Chỉnh phần mềm đã cóKiểm thử tính nhất quánKiểm thử sau bảo trìLập biểu bảo trìHình xx : Quy trình bảo trì phần mềmHiểu phần mềm : hiểu là nắm chắc những tính năng, đặc tả chi tiết cụ thể, điều kiện kèm theo kiểm thử …, cầndò đọc chương trình nguồn, hiểu trình tự giải quyết và xử lý chi tiết cụ thể của mạng lưới hệ thống. Hiểu phần mềm thựcchất là có những hiểu biết thâm thúy về mạng lưới hệ thống phần mềm đang làm gì, nó tương quan gì tới môitrường của nó như thế nào, nhận ra đâu là những đổi khác có hiệu suất cao và có những hiểu biết sâu sắcvề những phần được sửa lại thao tác như thế nào. Để co thể thành công xuất sắc trong việc tạo ra cácthay đổi đến mạng lưới hệ thống, yếu tố của từng bộ phận, hiệu suất cao thi hành, sự tương quan của nguyênBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmnhân, tác dụng, sự tương quan của sản phẩm-môi trường và những đặc thù tương hỗ quyết định hành động cầnđược hiểu. Mọi thành viên của đội bảo trì phải hiểu một cách tổng lực và mạng lưới hệ thống. Nếubảo trì bằng cách tu sửa chương trình phần mềm đã có thì cần tạo ra những module mới và dịchlại. Thực hiện kiểm thử unit và tu chỉnh những mục tương quan trong tài liệu đặc tả. Cần theosát tác động ảnh hưởng của module mới đến những thành phần khác trong mạng lưới hệ thống. Xây dựng phần mềm mới : nếu thực thi kiến thiết xây dựng phần mềm mới thì cần chú ý quan tâm : khi xâythêm công dụng mới phải tăng trưởng cho tương thích với nhu yếu. Kiểm thử tính đồng nhất : kiểm chứng tính đồng nhất bằng kiểm thử tích hợp : đưa unit đãđược kiểm thử vào hoạt động giải trí trong mạng lưới hệ thống, kiểm soát và điều chỉnh sự thích hợp giữa những modul, dùngcác tài liệu trước kia khi kiểm thử để kiểm tra lại tính đồng nhất. Kiểm tra sau bảo trì : kiểm tra khi hoàn thành xong bảo trì cần kiểm tra sự sửa đổi trong tài liệuđặc tả đi kèm, cách ghi tư liệu có tương thích với diễn đạt thiên nhiên và môi trường phần mềm mới hay không. Lập biểu bảo trì : Lập biểu quản trị thực trạng bảo trì : thực trạng bảo trì rất cần được kiểmsoát ngặt nghèo, cần lập biểu để quản trị, gồm có những thông tin : thời hạn, nguyên do, tóm tắtcách khắc phục, chi tiết cụ thể cách khắc phục, hiệu ứng đi kèm sự đổi khác, người thực thi bảo trì, số công. 3. Khó khăn của bảo trì phần mềm. Thực tế là bảo trì phần mềm là mảng kiến thức và kỹ năng không được giảng dạy một cách hệ thốngtrong những trường ĐH, sinh viên khi ra trường thiếu sót nền tảng, sự hiểu biết và những kỹ thuật, công cụ tương hỗ trong nghành bảo trì. Ngay trong những công ty tăng trưởng phần mềm ở Nước Ta, quy trình tiến độ bảo trì phần mềm cũng chưa được thực thi một cách mạng lưới hệ thống, chưa có chuẩn trongviệc bảo trì phần mềm, chưa được góp vốn đầu tư thích đáng. Khó khăn cho bảo trì hoàn toàn có thể nhìn thấy từ góc nhìn của người mua cũng hoàn toàn có thể tới tư phíanhân viên tăng trưởng phần mềm. Dekleva đưa ra một báo cáo giải trình khảo sát, từ góc nhìn của một nhânviên bảo trì phần mềm đưa ra list 19 yếu tố chính của bảo trì phần mềm. Một yếu tố được đồng ý thoáng rộng là, bảo trì phần mềm đã trở thành một nguồn lợi lớn vớicác công ty phần mềm. một số ít cuộc tìm hiểu trong vòng 10 năm gần đây chỉ ra, với hầu hết cácphần mềm thì bảo trì phần mềm chiếm tỷ suất lớn trong ngân sách của một phần mềm trong suốt vòngđời tăng trưởng của nó. Một số chuyên ra đưa ra tỉ lệ đơn cử như sau : theo Foster la từ 40 tới 90 %, theo Rand là 75 %, Tony Scott là 50 đến 80 %. Các cuộc tìm hiểu dựa trên quan điểm những ngườitham gia, xác nhận thông tin người dùng rằng giá trị của bảo trì là rất lớn. Sau đây là bảng 19 khó khăn vất vả của bảo trì phần mềm dưới góc nhìn của một nhân viên cấp dưới : Khó khănSTTĐi theo sự biến hóa những ưu tiênThiếu kinh nghiệm tay nghề kiểm thửKhó khăn để đo hiệu năngBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmTài liệu về phần mềm là không đầy đủThích nghi với sự biến hóa nhanh của tổ chức triển khai người dùngYêu cầu cần quá NihauKhó khăn để nhìn nhận sự góp phần của bảo trì trong vòng đời phần mềm. Tinh thần thao tác thấp vì thiếu hiểu biết và quan tâmÍt chuyên viên kinh nghiệm tay nghề. 10 Ít chiêu thức, thiếu những chuẩn, thủ tục hoặc công cụ sử dụng. 11M ã nguồn của phần mềm đã có là phức tạp và không có cấu trúc12Sự tích hợp, chồng chéo và không thích hợp của mạng lưới hệ thống đã có. 13 Đào tạo ở bậc thấp cho đội ngũ nhân viên cấp dưới bảo trì. 14K hông có kế hoạch kế hoạch cho bảo trì15Khó khán để hiểu và phân phối được nhu yếu của người dùng. 16T hiếu sự đồng cảm và giúp sức từ người quản trị. 17P hần mềm của mạng lưới hệ thống được bảo trì hoạt động giải trí trong thiên nhiên và môi trường lỗi thời18Ít dự tính để tái thiết kế phần mềm đã co. 19T hiếu nhân lực có trình độ. Một thực tiễn đã được kiểm nghiệm là nhu yếu của người mua đa phần ( 55 % ) là nhu yếu thêmmới chứ không phải nhu yếu sửa đổi. Các đặc thù đặc biệt quan trọng của phần mềm cũng gây khó khăncho quy trình bảo trì. Banker chỉ ra rằng size và độ phức tạp của một phần mềm có ảnhhưởng tới giá tiền bảo trì và những nỗ lực chỉnh sửa phần mềm đó. Boehm đưa ra đánh giá và nhận định cứ 1 $ góp vốn đầu tư cho tăng trưởng phần mềm thì sẽ phải dùng 2 $ cho việc bảo trì. Lehman cho biết cấu trúc mã phần mềm ngày càng trở nên phức tạp do Nihau đổi khác tác dônglên phân mềm, điều này làm tăng số lượng nhân viên cấp dưới dành cho bảo trì phần mềm. Osborne vàchikosky tích hợp tuổi đời hoạt động giải trí và độ phức tạp của mạng lưới hệ thống. Họ chỉ ra rằng trong quá khứ, những phần mềm không sử dùng những kỹ thuật kiến trúc tiên tiến và phát triển, những phần mềm cũ co cấu trúc bêntrong phức tạp, kỹ thuật lập trình kém, thiêu tài liệu đặc tả, dẫn tới giá tiền và nỗ lực bảo trìlớn. Hewletet chỉ ra tác nhân chính dẫn tới giá tiền bảo trì phần mềm cao là số lượng và kinhnghiệm của lập trình viên, chất lượng của tại liệu kỹ thuật, tài liệu người dùng, những công cụ hỗtrợ cho nhân viên cấp dưới bảo trì, cấu trúc và năng lực bảo trì của chính phần mềm. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềm4. Nhiệm vụ của bảo trì phần mềm. Nhiệm vụ của bảo trì phần mềm được xác lập theo từng quy trình tiến độ của quy trình bảo trì : nghiên cứu và phân tích / cô lập, phong cách thiết kế, thực thi, kiểm thử, văn bản hóa. Phân tích / cô lập : là trách nhiệm gồm có sự nghiên cứu và phân tích tác động ảnh hưởng, nghiên cứu và phân tích những giá trị lợi íchvà cô lập. nghiên cứu và phân tích những ảnh hưởng tác động và nghiên cứu và phân tích quyền lợi gồm có những việc làm khác nhau : quản trị thao tác cũng như những ngân sách. Cô lập co tương quan đến thời hạn sử dụng để hiểuđược yếu tố do đâu. Thiết kế : phong cách thiết kế lại mạng lưới hệ thống gồm có những hiểu biết thiết yếu làm thế nào để biến hóa. cũngnhư việc sửa chữa thay thế những tài liệu phi hình thức, tài liệu chưa có trên trong thực tiễn. Thực thi : sửa chữa thay thế những mã và trấn áp từng đơn vị chức năng thành phần, việc thay thế sửa chữa những mã và kiểmsoát đơn vị chức năng co tương quan đến thời hạn lập trình cũng như kiểm nghiệm những đổi khác. Nócũng gồm có những văn bản phi hình thức giống như những phần mềm kiểm tra kế hoạch, kiểm tra từng đơn vị chức năng thường thì chỉ được làm trên khoanh vùng phạm vi thao tác của từng người dùng. Kiểm thử : gồm có sự hợp nhất sự công nhân những phép kiểm thử. Tập hợp những kiểm thử đềuliên quan đến thời hạn sử dụng của chính thành phần đó. Sự công nhận những phép kiểm thửđược thực thi bởi chính người sử dụng để bảo vệ những biến hóa đó đều đã được thựchiện thành công xuất sắc. Phép thử hồi quy bảo vệ những biến hóa đó không tác động ảnh hưởng tới nhữngchức năng của những thành phần khác trong mạng lưới hệ thống. Văn bản hóa : gồm mạng lưới hệ thống, người dùng và những tài liệu đi kèm. Hệ thống tài liệu này rấtquan trong trong tương lai. 5. Ý nghĩa của bảo trì phần mềm. Hệ thống dù kiến thiết xây dựng tốt tới đâu cũng không hề hoạt động giải trí không thay đổi trong một thời hạn dàinếu không có bảo trì. Do đó cần phải cân đối giữa tài nguyên và việc làm bảo trì phần mềm. Bảotrì phần mềm hàng năm ở Mỹ khoảng chừng 70 tỷ đô la cho khoảng chừng 10 tỷ dòng code. Nokia phải dùngtới 90 nghìn đô để sửa lỗi Y2K. Nhiêu điều tra và nghiên cứu được triển khai để xem xét giá trị của bảo trìphần mềm, hay tỷ suất giữa việc làm tăng trưởng phần mềm với bảo trì phần mềm. Tổng giá trị bảotrì mạng lưới hệ thống khoảng chừng 50 % tổng giá trị của cả vòng đời phần mềm. 6. Phương pháp bảo trì phần mềmBảo trì phần mềm hoàn toàn có thể được thực thi theo một số ít chiêu thức nhất định, thông dụng là baphương pháp : o Quick-fixo Interative-enhancemento Full-reusEa. Quick-fixBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmHình xx : Mô tả chiêu thức Quick-fixPhương pháp nay thực thi sự đổi khác với code của chương trình nguồn, sau đó update sựthay đổi với những file doc đi kèm. Đây là giải pháp bảo trì đạt được vận tốc nhanh gọn nhưngmang đến những nhược điêm như : Vai trò của file doc bị giảm sút, do nhu yếu của người sử dụng đổi khác nhanh và có thểđủ nhỏ để chỉ đổi khác về chương trình nguồn mà không cập nhập vào fiel docs. Hơn thế, do thayđổi trực tiếp vào code của chương trình nguồn, quy trình bảo trì rất hoàn toàn có thể sẽ làm vỡ phong cách thiết kế banđầu của phần mềm. b. Interative-enhancementBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmHình xx : Mô tả giải pháp Interative-enhancementDựa trên nhận định và đánh giá rằng một mạng lưới hệ thống khi kiến thiết xây dựng rất khó hoàn toàn có thể đã phân phối được hết yêucầu của người sử dụng, giải pháp interative – enhance triển khai kiến thiết xây dựng mạng lưới hệ thống hoànchỉnh dựa trên cơ sở nghiên cứu và phân tích trong bước đầu về nhu yếu của mạng lưới hệ thống, triển khai nghiên cứu và phân tích sâu hơnyêu cầu đặt ra so với phần mềm dựa trên phản hồi của người sử dụng để thiết kế xây dựng hệ thốngmới. Có thể nhận thấy ưu điểm điển hình nổi bật của giải pháp này so với quick-fix là file docs của hệ thốngđược update liên tục với mọi sự đổi khác của mạng lưới hệ thống. c. Full-reuseBài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmHình xx : Mô tả chiêu thức Full-reuseMục đích của tái sử dụng lại là nhằm mục đích tăng hiệu suất, chất lượng và tao điều kiện kèm theo thuận lợicho việc quy đổi mã, giảm bớt thời hạn ngân sách để bảo trì. Có thể hiểu định nghĩa của việc táisử dụng phần mềm như sau : đó là việc sử dụng lại những kinh nghiệm tay nghề đã co từ chính mạng lưới hệ thống đóhay những mạng lưới hệ thống tương tự như nhằm mục đích giảm bớt nỗ lực để tăng trưởng hay bảo trì mạng lưới hệ thống. Ứng dụng tư tưởng tái sử dụng, giải pháp full-reuse kiến thiết xây dựng mạng lưới hệ thống mới trên cơ sở táisử dụng những yếu tố tương thích trong từng quy trình tiến độ khi kiến thiết xây dựng mạng lưới hệ thống cũ. Do đó, phươngpháp này thích hợp cho việc kiến thiết xây dựng những mạng lưới hệ thống có vòng đời ngắn. Tăng năng lực tái sửdụng của những component mạng lưới hệ thống. Đặc biệt, khi tích hợp full-reuse và interative-enhancement hoàn toàn có thể tăng đáng kể hiệu suất cao kinhtế của quy trình bảo trì phần mềm. 7. Các yếu tố khác của bảo trì phần mềm. a. Tăng hiệu suất cao quy trình bảo trì phần mềm. Bảo trì phần mềm là quá trình rất là tốn kém cả về thời hạn và ngân sách, do đó cần conhững phương tăng trưởng phần mềm và bảo trì hài hòa và hợp lý để giảm thiểu hao tốn do bảo trì. Chúng tacần vận dụng những biến hóa nhỏ với quy trình tăng trưởng phần mềm, với quy trình bảo trì phầnmềm và tăng trưởng kỹ thuật tương hỗ cho quy trình bảo trì phần mềm. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmTrong quá trình tăng trưởng phần mềm, hoàn toàn có thể tăng hiệu năng bảo trì phần mềm bằng cách đểngười chủ chốt trong quy trình bảo trì tham gia vào quá trình phân tich và phong cách thiết kế, như vậy họ cócơ hội hiểu thâm thúy những yếu tố của phần mềm họ cần bảo trì. Thêm vào đó, cần chuẩn hóa mọikhâu trong tăng trưởng phần mềm, việc chuẩn hóa sẽ giúp cho quy trình tra cứu hay sửa đổi đượcthuận tiện hơn. Bản thiết kế của phần mềm cần được phong cách thiết kế sao cho dễ bảo trì. Trong quy trình tiến độ bảo trì phần mềm co thể vận dụng 1 số ít giải pháp như : Sử dụng những công cụ tương hỗ tăng trưởng phần mềm. vì như đã đề cập ở trên, quy trình bảotrì phần mềm cũng tương tự như như quy trình tăng trưởng phần mềm, việc sử dụng những công cụhỗ trợ tăng trưởng phần mềm là rất thiết yếu.  Chuẩn hóa thao tác bảo trì và thiết bị môi trường tự nhiên bảo trì.  Việc lưu lại thông tin bảo trì là rất thiết yếu, cần phải nắm rõ quy trình tiến độ, hiệu suất cao cũng nhưthiếu sót của quy trình bảo trì, tra cứu thông tin bảo trì tiếp tục để có những thayđổi về kế hoạch cho tương thích.  Bảo trì tốt cần phải hiểu thật rõ nhu yếu cũng như phong cách thiết kế, đặc tính của phần mềm đó, chính do đó, đội tăng trưởng dự án Bất Động Sản nên cử người chủ chốt của mình thực thi bảo trì phầnmềm sau khi dự án Bất Động Sản kết thúc tiến trình tăng trưởng. Trong việc tăng trưởng những công cụ tương hỗ bảo trì : Cần góp vốn đầu tư tăng trưởng những công cụ tương hỗ bảo trì phần mềm như những công cụ dịchngược ( reverse engineering ) …  Đầu tư cho công cụ thiết kế xây dựng và quản trị database cho bảo trì, những công cụ quản trị hồ sơ, tài liệu, chương trình nguồn, tài liệu thử, lịch sử vẻ vang bảo trì. b. Tìm hiểu về kỹ thuật dịch ngược ( Reverse – engineering ) Kỹ thuật dịch ngược là một quy trình nghiên cứu và phân tích giải quyết và xử lý mạng lưới hệ thống để nhận ra những thành phần củahệ thống và mối liên hệ giữa chúng, tạo những miêu tả về mạng lưới hệ thống trong một thể khác hoặc tại cấpđộ cao hơn của sự trừu tượng hóa. Kỹ thuật đảo ngược nhu yếu khi cần giải quyết và xử lý để hiểu một hệthống phần mềm trong một thời hạn dài bị lỗi, những tài liệu hết hạn sử dụng, sự phức tạp của hệthông và thiếu hiểu biết về bảo trì mạng lưới hệ thống. Mục đích của kỹ thuật dịch ngược là lấy lại những thông tin đã mất, làm quy đổi dễ dànggiữa những flatfom, để nâng cấp cải tiến hay cung ứng những tài liệu, để phân phối những lựa chọn xem xét, trích racác thành phần sử dụng lại để đối phó với sự phức tạp, để chỉ ra những mặt hiệu suất cao và giảm côngsức bảo trì. Một số tool reverser phổ cập như : Decompiler / Disassembler Archive, HEX Editing Archive, HCU Tools Archive, Miscellaneous Tools Archive … Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmII. Thực tế vận dụng tại những công tyTrong quy trình làm bài tập lớn, chúng em đã triển khai khảo sát nhìn nhận ở bốn công ty phầnmềm trên địa phận Hà NộiCông ty nghĩa vụ và trách nhiệm hữu hạn SeLabCông ty CP FsoftCông ty FitechCông ty MISATại bốn công ty này, chúng em đã triển khai khảo sát về quy trình tiến độ kiểm thử và bảo trì, cũng nhưkhảo sát những công cụ mà những công ty đó sử dụng. Trong đó trình đó, chúng em nhận thấy những vấnđề sau tại những công ty : Các công ty này đều chăm sóc đến yếu tố kiểm thử, nhìn nhận chất lượng sản phầm củamình. Các công ty đều có thiết kế xây dựng cho mình một đội ngũ những tester chuyên biệt để đápứng được nhu yếu sử dụng của mìnhCác công ty trong quy trình kiểm thử đều thực thi không thiếu những kế hoạch kiểm thử. Hầuhết, unit test đều được đặt ở khâu lập trình viên – người tăng trưởng mạng lưới hệ thống. Bộ phậnkiểm thử thực thi những khâu khác của quy trình kiểm thử. Hầu hết những công ty chỉ sử dụng chiêu thức kiểm tra hộp đen ( hoàn toàn có thể cùng hộp xám ) chứ không sử dụng giải pháp kiểm tra hộp trắng. Phương pháp kiểm tra hộp trắng chỉđược sử dụng trong một vài trường hợp đặc biệt quan trọng. Ví dụ như khảo sát MISA chúng emnhận được chứng minh và khẳng định của anh trưởng phòng là hiện tại MISA chỉ sử dụng kiểm thử hộpđen và không sử dụng những chiêu thức kiểm thử khác. Bên cạnh một số ít chiêu thức và kế hoạch kiểm thử nêu trong phần cơ sở kim chỉ nan, 1 số ít công ty còn sử dụng những chiêu thức khác như kiểm thử tải. Đây là loại kiểmthử xác lập năng lực chịu đựng của mạng lưới hệ thống, phần mềm trước nhiều nhu yếu khác nhaucùng lúc từ phía người mua … Hầu hết những công ty chưa có quy trình tiến độ chuẩn trong kiểm thử phần mềm mà chỉ làm việcdựa trên thói quen thao tác hàng ngày. Một số công ty như MISA, Fsoft có vận dụng chomình một vài chuẩn riêng trong những khâu thao tác. Tuy nhiên xét trên cả quy trình kiểmthử thì những công ty này vẫn chưa thiết kế xây dựng được một chuẩn thống nhất, một quy trìnhxuyên suốt. Hầu hết những công ty đều chưa có công cụ tương hỗ kiểm thử. Tuy nhiên một số ít công ty đãsử dụng một hay một vài công cụ để hỗ trở kiểm thử, quản trị lỗi. Ví dụ như Fsoft, mỗiteam, mỗi dự án Bất Động Sản họ sử dụng một công cụ tương hỗ quản trị lỗi riêng, tùy theo từng dự án Bất Động Sản. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmTuy nhiên nếu dự án Bất Động Sản đó không cung ứng những công cụ tương hỗ thì trong bản thân Fsoft cũngcó một mạng lưới hệ thống quản trị lỗi của riêng mình là DMS ( defect manager system ). Mỗi nhânviên khitham gia vào trong công ty đều được học cách sử dụng mạng lưới hệ thống này. Tuy nhiênhầu như không được sử dụng đến do mỗi dự án Bất Động Sản đều có công cụ riêng của mình. Công tyMISA lại sử dụng nhiều công cụ hơn như Bug Jira để quản trị lỗi ( đây là mạng lưới hệ thống đượcđánh giá tốt nhất và tương thích nhất với thực tiễn của MISA ). Exel để quản trị tescase, Sourcevault để quản lý tài liệu ( xem thêm phần phụ lục những biên bản khảo sát ). Hầu hết những công ty đã khảo sát, việc bảo trì không được chú trọng hoặc không được táchriêng ra thành một nhóm, một phòng ban. Việc bảo trì mạng lưới hệ thống đươc mặc định gần như100 % là do những người tăng trưởng mạng lưới hệ thống giải quyết và xử lý vì họ là người hiểu hệ thống nhất. Bên cạnh nhưng công cụ khảo sát được tai những công ty, lúc bấy giờ cũng có khá nhiều tool hỗ trợkiểm thử như : UCM ( Unified Change Management ). Junit framework tương hỗ kiến thiết xây dựng testing tự động hóa trên JavaQuickTest proessional 8.2 Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmIII. Bài học kinh nghiệm tay nghề và nhìn nhận Tóm lại của nhómTrong quy trình tìm hiểu và khám phá đề tài, cả nhóm chúng em đã rút ra được những bài học kinh nghiệm và kết luậnsau : Kiểm thử và bảo trì phần mềm là hai quy trình vô cùng quan trọng trong vòng đời pháttriển một phần mềm. Đây là những quy trình không hề thiếu trong việc tăng trưởng mộtphần mềm thương mại. Kiểm thử và bảo trì phần mềm có nhiều kĩ thuật khác nhau, và trong thực tiễn những công ty trênđịa bàn Thành Phố Hà Nội cũng chỉ sử dụng những kĩ thuật đó trong việc làm của mình. Tuy nhiên, dựa trên đặc trưng của từng công ty, việc bảo trì, kiểm thử phần mềm sẽ có những đặc điểmkhác nhau. Ví dụ như kiểm thử hộp trắng chỉ được fsoft sử dụng với những chương trìnhnhỏ như lập trình mobile, còn những mạng lưới hệ thống lớn thì không sử dụng. Còn với MISA chỉ sửdụng kiểm thử hộp đen trong quy trình kiểm thử và cho rắng đây là chiêu thức kiểmthử thích hợp nhất so với công ty mình. Trong thực tiễn, khi một tổ đội xây dưng phần mềm chưa nhiều, và còn hạn hẹp về mặtquân số cũng như chất lượng, một số ít công ty không tách chuyên biệt những cá thể vàotrong một nhóm ( một phòng ) quản trị chất lượng phần mềm. Các công ty sử dụng việc đanhiệm vụ cho một cá thể. Từ đó cũng nâng cao được chất lượng, thời hạn kiểm thử. Tuy nhiên những giải pháp đó không áp dùng được với những phần mềm mạng lưới hệ thống lớn. Do người kiểm thử và người lập trình là một nên không lan rộng ra được những góc nhìn, không có những nhìn nhận chuẩn xác, khách quan về phần mềm cần kiểm thử, bảo trì. Bêncạnh đó, nếu quy trình tăng trưởng phần mềm, kiểm thử phần mềm không được tách rachuyên biện, lập trình viên sẽ bị trồng chéo việc làm dễ bị nhầm lẫn. Trong quy trình kiến thiết xây dựng và tăng trưởng phần mềm, việc sử dụng công cụ tương hỗ là vô cùngcần thiết. Có những công cụ tương hỗ sử dủng rất đơn thuần như exel, word .. vv Điểm quantrọng là cần biết phối hợp những công cụ này với việc làm đặc trưng của công ty mình. Quanhận xét nhìn nhận, chúng em nhận thấy MISA là một quy mô nổi bật của việc áp dụnghiệu quả những công cụ tương hỗ kiểm thử trong việc quản trị testcase, quản trị bug, quản trị tàiliệu, quản trị những release phần mềm. Việc bảo trì phần mềm theo chúng em cần được đề cao hơn. Mặc dù phần này sẽ ít cầnthiết nếu như kiểm thử phần mềm ngày càng nâng cao chất lượng của mình để phầnmềm triển khai xong hơn trước khi được phân phối thoáng đãng tới những người mua. Tuy nhiên vãncần tăng cường bảo trì phần mèm để phân phối những nhu yếu khác nhau của người sử dụng. Từ đó nâng cao chất lượng của người mua. Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử và bảo trì phần mềmTài liệu tham khảoRoger S.Pressman, Ph. D : Software engineering A practitioner ‘ s approach fifthedition – MCGraw – Hill series in computer science ( file pdf ) Ian Sommerville : Software engineering, 8 th Edition ( file pdf ) Cem Kaner, J.D., Ph. D : Exploratory Testing ( file ppt ) Keynote at QAI November17, 2006. John E. Bentley, Wachovia Bank, Charlotte NC : Software Testing Fundamentals — Concepts, Roles, and Terminology ( file pdf ) Gerardo Canfora and Aniello Cimitile ( University of Sannio, Faculty of Engineeringat Benevento Palazzo Bosco Lucarelli, Piazza Roma 82100, Benevento Italy ) : Software Maintenance – 29 November, 2000T he Art of Software Testing, Glenford J. Myers, Second Edition, John Wiley andSons, Inc .

Source: https://thevesta.vn
Category: Dịch Vụ