Kiểm thử và 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

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

A.

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

B.

a.

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

b.

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

c.

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

d.

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

e.

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

I.

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

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

2

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

3

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 đủ

5

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

6

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

7

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

8

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

9

Ít chuyên gia kinh nghiệm.

10

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

11

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

12

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

13

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

14

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

15

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

16

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

17

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

18

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

19

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

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.