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ử 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ử 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 : Bùi Thanh Liêm - 20061779 Mai Thị Ngoan - 20062264 Trương Thảo Nguyên - 20062306 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ử bảo trì phần mềm Mục lục I Tìm hiểu lý thuyết A Kiểm thử phần mềm Tổng quan kiểm thử phần mềm Các kĩ thuật kiểm thử phần mềm Chiến lược kiểm thử phần mềm .6 B a Kiểm thử đơn vị – Unit test 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 Tổng quan bảo trì phần mềm 12 Quy trình bảo trì phần mềm 14 Khó khăn bảo trì phần mềm 15 Nhiệm vụ bảo trì phần mềm .17 Ý nghĩa bảo trì phần mềm 17 Phương pháp bảo trì phần mềm .17 Các vấn đề khác bảo trì phần mềm .20 II Thực tế áp dụng công ty .22 III Bài học kinh nghiệm đánh giá kết luận nhóm .24 IV Tài liệu tham khảo 25 V Phụ lục 26 Biên khảo sát công ty trách nhiệm hữu hạn SeLab 26 Biên khảo sát công ty FPT Software 28 Biê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ử bảo trì phần mềm I Tìm hiểu lý thuyết A Kiểm thử phần mềm Tổng quan 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 trình khảo sát hệ thống hay thành phần điều kiện xác định, quan sát ghi lại kết quả, đánh giá khía cạnh hệ thống hay thành phần (Theo Bảng giải thuật ngữ chuẩn IEEE Thuật ngữ kỹ nghệ phần mềmIEEE Standard Glossary of Software Engineering Terminology) Kiểm thử phần mềm trình thực thi 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 hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm môi trường chúng dự định triển khai nhằm cung cấp cho người có lợi ích liên quan thông tin chất lượng sản phẩm hay dịch vụ phần mềm Mục đích kiểm thử phần mềm tìm lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu hoạt động tối ưu phần mềm nhiều ngành khác (Theo Bách khoa toàn thư mở Wikipedia) Có thể định nghĩa cách dễ hiểu sau: Kiểm thử phần mềm tiến trình hay tập hợp tiến trình thiết kế để đảm bảo mã hóa máy tính thực theo mà chúng thiết kế để làm, không thực thứ không mong muốn Đây pha quan trọng trình phát triển hệ thống, giúp cho người xây dựng hệ thống khách hàng thấy hệ thống đáp ứng yêu cầu đặt hay chưa b Phân loại Có hai loại kiểm thử phần mềm kiểm thử tĩnh (static testing) 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 yêu cầu đặc tả tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần chi tiết mà không cần chạy chương trình Kiểu kiểm thử thường sử dụng chuyên viên thiết kế người mà viết mã lệnh Kiểm thử tĩnh tự động hóa Nó thực kiểm tra toàn bao gồm chương trình phân tích trình thông dịch biên dịch mà xác nhận tính hợp lệ cú pháp chương trình Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử 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 chương trình Đó kiểm thử dựa ca kiểm thử xác định thực đối tượng kiểm thử hay chạy chương trình Kiểm thử động kiểm tra cách thức hoạt động động mã lệnh, tức kiểm tra phản ứng vật lý từ hệ thống tới biến thay đổi theo thời gian Trong kiểm thử động, phần mềm phải thực biên dịch chạy Kiểm thử động thực bao gồm làm việc với phần mềm, nhập giá trị đầu vào kiểm tra xem liệu đầu có 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, Kiểm thử chấp nhận sản phẩm – Acceptance Tests c Mục tiêu kiểm thử phần mềm  Kiểm thử trình thực thi chương trình với mục đích tìm lỗi/ yếu điểm chương trình  Một trường hợp kiểm thử tốt trường hợp có khả lớn việc tìm lỗi chưa phát  Một trường hợp kiểm thử không tốt ( không thành công ) trường hợp mà khả tìm thấy lỗi chưa biết đến  Mục tiêu kiểm thử phần mềm thiết kế trường hợp kiểm thử để phát cách có hệ thống loại lỗi khác thực việc với lượng thời gian tài nguyên Các kĩ thuật kiểm thử phần mềm Ba số kĩ thuật kiểm thử phần mềm kiểm thử hộp đen, kiểm thử hộp trắng, kiểm thử hộp xám a Kiểm thử hộp đen – Black box testing Một chiến lược kiểm thử quan trọng kiểm thử hộp đen, hướng liệu, hay hướng vào/ra Kiểm thử hộp đen xem chương trình “hộp đen” Mục đích bạn hoàn toàn không quan tâm cách cư xử cấu trúc bên chương trình Thay vào đó, tập trung vào tìm trường hợp mà chương trình không thực theo đặc tả Theo hướng tiếp cận này, liệu kiểm tra lấy từ đặ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ử 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ử bảo trì phần mềm o Kiểm thử fuzz – Fuzz testing o Kiểm thử dựa 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 đặc tả – Specification-base testing Kiểm thử dựa đặc tả tập trung vào kiểm tra tính thiết thực phần mềm theo yêu cầu thích hợp Do đó, kiểm thử viên nhập liệu vào, thấy liệu từ đối tượng kiểm thử Mức kiểm thử thường yêu cầu ca kiểm thử triệt để cung cấp cho kiểm thử viên mà xác minh liệu đầu vào cho, giá trị đầu (hay cách thức hoạt động) có giống với giá trị mong muốn xác định ca kiểm thử hay không Kiểm thử dựa đặc tả cần thiết, không đủ để để ngăn chặn rủi ro chắn Kiểm thử hộp đen mối liên quan tới mã lệnh, kiểm thử viên đơn giản tâm niệm là: mã lệnh phải có lỗi Sử dụng nguyên tắc “ Hãy đòi hỏi bạn nhận”, kiểm thử viên hộp đen tìm lỗi mà lập trình viên không tìm Nhưng, mặt khác, người ta nói kiểm thử hộp đen “giống bóng tối mà đèn vậy”, kiểm thử viên phần mềm kiểm tra thực xây dựng Đó lý mà có nhiều trường hợp mà kiểm thử viên hộp đen viết nhiều ca kiểm thử để kiểm tra thứ mà cần kiểm tra ca kiểm thử nhất, và/hoặc số phần chương trình không kiểm tra chút Do vậy, kiểm thử hộp đen có ưu điểm “một đánh giá khách quan”, mặt khác lại có nhược điểm “thăm dò mù” b Kiểm thử hộp trắng – White box testing Là 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 chương trình Chiến lược xuất phát từ liệu kiểm thử kiểm thử tính logic chương trình Kiểm thử viên truy cập vào cấu trúc liệu giải thuật bên chương trình (và mã lệnh thực 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): phương pháp kiểm thử ứng dụng sử dụng API công khai riêng tư o Bao phủ mã lệnh – Code coverage: tạo kiểm tra để đáp ứng số tiêu chuẩn 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ử 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 kiểm thử tĩnh Phương pháp kiểm thử hộp trắng sử dụng để đánh giá hoàn thành kiểm thử mà tạo với phương pháp kiểm thử hộp đen Điều cho phép nhóm phần mềm khảo sát phần hệ thống kiểm tra đảm bảo điểm chức quan trọng 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ó truy cập tới cấu trúc liệu giải thuật bên cho mục đích thiết kế ca kiểm thử, kiểm thử mức người sử dụng hay mức hộp đen Việc thao tác tới liệu đầu vào định dạng liệu đầu không rõ ràng, giống “hộp xám”, đầu vào đầu rõ ràng bên “hộp đen” mà gọi hệ thống kiểm tra Sự khác biệt đặc biệt quan trọng quản lý kiểm thử tích hợp – Intergartion testing modun mã lệnh viết hai chuyên viên thiết kế khác nhau, giao diện đưa để kiểm thử Kiểm thử hộp xám bao gồm thiết kế đối chiếu để định, ví dụ, giá trị biên hay thông báo lỗi 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 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ử bảo trì phần mềm a Kiểm thử đơn vị – Unit test Một đơn vị thành phần phần mềm nhỏ mà ta kiểm thử Ví dụ, hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) xem Unit Vì Unit chọn để kiểm tra thường có kích thước nhỏ chức hoạt động đơn giản, không khó khăn việc tổ chức kiểm thử, ghi nhận phân tích kết kiểm thử Nếu phát lỗi, việc xác định nguyên nhân khắc phục tương đối dễ dàng khoanh vùng đơn thể Unit kiểm tra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test đền bù việc tiết kiệm nhiều thời gian chi phí cho việc kiểm thử sửa lỗi mức kiểm thử sau Unit Test thường lập trình viên thực Công đoạn cần thực sớm tốt giai đoạn viết code 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 thiết kế code chương trình Mục đích Unit Test bảo đảm thông tin xử lý xuất (khỏi Unit) xác, mối tương quan với liệu nhập chức Unit Điều thường đòi hỏi tất nhánh bên Unit phải kiểm tra để phát nhánh phát sinh lỗi Một nhánh thường chuỗi lệnh thực thi Unit Ví dụ: chuỗi lệnh sau điều kiện If nằm then else nhánh Thực tế việc chọn lựa nhánh để đơn giản hóa việc kiểm thử quét hết Unit đòi hỏi phải có kỹ thuật, phải dùng thuật toán để chọn lựa Cùng với mục kiểm thử khác, Unit Test đòi hỏi phải chuẩn bị trước ca kiểm thử (Test case) kịch kiểm thử (Test script), định rõ liệu đầu vào, bước thực liệu đầu mong muốn Các Test case Test script nên giữ lại để tái sử dụng b Kiểm thử tích hợp – Intergration Test Integration test kết hợp thành phần ứng dụng kiểm thử ứng dụng hoàn thành Trong Unit Test kiểm tra thành phần Unit riêng lẻ Intgration Test kết hợp chúng lại với kiểm tra giao tiếp chúng Hai mục tiêu Integration Test: o Phát lỗi giao tiếp xảy Unit o Tích hợp Unit đơn lẻ thành hệ thống nhỏ (Subsystem) cuối 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 lỗi liên quan đến chức cấu trúc nội Unit Có số phép kiểm thử đơn giản giao tiếp Unit với thành phần liên quan khác, nhiên giao tiếp liên quan đến Unit thật kiểm tra đầy đủ Unit tích hợp với thực Integration Test Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm Trừ số ngoại lệ, Integration Test nên thực Unit kiểm tra cẩn thận trước Unit Test, tất lỗi mức Unit sửa chữa Một số người hiểu sai Unit qua giai đoạn Unit Test với giao tiếp giả lập không cần phải thực Integration Test Thực tế việc tích hợp Unit dẫn đến tình hoàn toàn khác Một chiến lược cần quan tâm Integration Test nên tích hợp dần Unit Một Unit thời điểm tích hợp vào nhóm Unit khác tích hợp trước hoàn tất đợt Integration Test trước Lúc này, ta cần kiểm thử giao tiếp Unit thêm vào với hệ thống Unit tích hợp trước đó, điều làm cho số lượng can kiểm thử giảm nhiều, sai sót giảm đáng kể Có loại kiểm thử 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 thành phần bên chương trình chạy trọng đến hoạt động thành phần cấu trúc nội chương trình chẳng hạn câu lệnh nhánh bên o Kiểm thử chức (Functional Test): Tương tự Black Box Test, kiểm thử chức trọng đến chức chương trình, mà không quan tâm đến cấu trúc bên trong, khảo sát chức chương trình theo yêu cầu kỹ thuật o Kiểm thử hiệu (Performance Test): Kiểm thử việc vận hành hệ thống o Kiểm thử khả chịu tải (Stress Test): Kiểm thử giới hạn hệ thống c Kiểm thử hệ thống – System Test Mục đích System Test kiểm thử thiết kế toàn hệ thống (sau tích hợp) có thỏa mãn yêu cầu đặt hay không System Test bắt đầu tất phận phần mềm tích hợp thành công Thông thường loại kiểm thử tốn nhiều công sức thời gian Trong nhiều trường hợp, việc kiểm thử đòi hỏi số thiết bị phụ trợ, phần mềm phần cứng đặc thù, đặc biệt ứng dụng thời gian thực, hệ thống phân bố, hệ thống nhúng Ở mức độ hệ thống, người kiểm thử tìm kiếm lỗi, trọng tâm đánh giá hoạt động, thao tác, tin cậy yêu cầu khác liên quan đến chất lượng toàn hệ thống Điểm khác then chốt Integration Test System Test System Test trọng hành vi lỗi toàn hệ thống, Integration Test trọng giao tiếp đơn thể đối tượng chúng làm việc Thông thường ta phải thực Unit Test Integration Test để bảo đảm Unit tương tác chúng hoạt động xác trước thực System Test Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm Sau hoàn thành Integration Test, hệ thống phần mềm hình thành với thành phần kiểm tra đầy đủ Tại thời điểm này, lập trình viên kiểm thử viên bắt đầu kiểm thử phần mềm hệ thống hoàn chỉnh Việc lập kế hoạch cho System Test nên giai đoạn hình thành phân tích yêu cầu System Test kiểm thử hành vi chức phần mềm lẫn yêu cầu chất lượng độ tin cậy, tính tiện lợi sử dụng, hiệu bảo mật Mức kiểm thử đặc biệt thích hợp cho việc phát lỗi giao tiếp với phần mềm phần cứng bên ngoài, chẳng hạn lỗi "tắc nghẽn" (deadlock) chiếm dụng nhớ Sau giai đoạn System Test, phần mềm thường sẵn sàng cho khách hàng người dùng cuối kiểm thử chấp nhận sản phẩm (Acceptance Test) dùng thử (Alpha/Beta Test) Đòi hỏi nhiều công sức, thời gian tính xác, khách quan, System Test thường thực 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 gồm: o Kiểm thử chức (Functional Test): Bảo đảm hành vi hệ thống thỏa mãn yêu cầu thiết kế o Kiểm thử hiệu (Performance Test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ nhớ) nhằm đạt tiêu thời gian xử lý hay đáp ứng câu truy vấn o Kiểm thử khả chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận hành áp lực cao (ví dụ nhiều người truy xuất lúc) Stress Test tập trung vào trạng thái tới hạn, "điểm chết", tình bất thường giao dịch ngắt kết nối (xuất nhiều kiểm tra thiết bị 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 liệu hệ thống o Kiểm thử khả phục hồi (Recovery Test): Bảo đảm hệ thống có khả khôi phục trạng thái ổn định trước tình tài nguyên liệu; đặc biệt quan trọng hệ thống giao dịch ngân hàng trực tuyến Nhìn từ quan điểm người dùng, cấp độ kiểm thử quan trọng: Chúng bảo đảm hệ thống đủ khả làm việc môi trường thực Lưu ý không thiết phải thực tất loại kiểm thử nêu Tùy yêu cầu đặc trưng hệ thống, tuỳ khả thời gian cho phép dự án, lập kế hoạch, người Quản lý dự án định áp dụng loại kiểm thử Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử 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 Acceptance Test, khách hàng thực (hoặc ủy quyền cho nhóm thứ ba thực hiện) Mục đích Acceptance Test để chứng minh phần mềm thỏa mãn tất yêu cầu khách hàng khách hàng chấp nhận sản phẩm (và trả tiền toán hợp đồng) Acceptance Test có ý nghĩa quan trọng, hầu hết trường hợp, phép kiểm thử System Test Acceptance Test gần tương tự, chất cách thức thực lại khác biệt Đối với sản phẩm dành bán rộng rãi thị trường cho nhiều người sử dụng, thông thường thông qua hai loại kiểm thử gọi kiểm thử Alpha – Alpha Test kiểm thử Beta – Beta Test Với Alpha Test, người dùng kiểm thử phần mềm nơi phát triển phần mềm, lập trình viên ghi nhận lỗi phản hồi, lên kế hoạch sửa chữa Với Beta Test, phần mềm gửi tới cho người dùng để kiểm thử môi trường thực, lỗi phản hồi gửi ngược lại cho lập trình viên để sửa chữa Thực tế cho thấy, khách hàng không quan tâm không tham gia vào trình phát triển phần mềm kết Acceptance Test sai lệch lớn, phần mềm trải qua tất kiểm thử trước Sự sai lệch liên quan đến việc hiểu sai yêu cầu mong chờ khách hàng Ví dụ phần mềm xuất sắc vượt qua phép kiểm thử chức thực nhóm thực dự án, khách hàng kiểm thử sau thất vọng bố cục hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng khách hàng v.v Gắn liền với giai đoạn Acceptance Test thường nhóm dịch vụ tài liệu kèm, phổ biến hướng dẫn cài đặt, sử dụng v.v Tất tài liệu kèm phải cập nhật kiểm thử chặt chẽ e Một số chiến lược kiểm thử khác Ngoài chiên lược trên, số 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 “sự kiểm tra lại có lựa chọn hệ thống hay thành phần để xác minh thay đổi không gây hậu không mong muốn…” Trên thực tế, quan niệm phần mềm mà qua kiểm tra trước kiểm tra lại Beizer định nghĩa lặp lại kiểm tra để cách hoạt động phần mềm không bị thay đổi, ngoại trừ tới mức yêu cầu Hiển nhiên thỏa hiệp phải thực đảm bảo đưa kiểm thử hồi quy lần thực thay đổi tài nguyên yêu cầu thực điều  Kiểm thử tính – Correctness testing: Tính đắn yêu cầu tối thiểu phần mềm, mục đích chủ yếu kiểm thử Kiểm thử tính cần kiểu người đáng tin đó, để cách hoạt độ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ử bảo trì phần mềm Hình xx: Mô tả phương pháp Interative-enhancement Dựa nhận định hệ thống xây dựng khó đáp ứng hết yêu cầu 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 sở phân tích bước đầu yêu cầu hệ thống, tiến hành phân tích sâu yêu cầu đặt phần mềm dựa phản hồi người sử dụng để xây dựng hệ thống Có thể nhận thấy ưu điểm bật phương pháp so với quick-fix file docs hệ thống cập nhật thường xuyên với thay đổi 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ử bảo trì phần mềm Hình xx: Mô tả phương pháp Full-reuse Mục đích tái sử dụng lại nhằm tăng suất, chất lượng 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 việc tái sử dụng phần mềm sau: việc sử dụng lại kinh nghiệm co từ hệ thống hay 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 sở tái sử dụng yếu tố phù hợp giai đoạn xây dựng hệ thống cũ Do đó, phương pháp thích hợp cho việc xây dựng hệ thống có vòng đời ngắn.Tăng khả tái sử dụng component hệ thống Đặc biệt, kết hợp full-reuse interative-enhancement tăng đáng kể hiệu kinh tế trình bảo trì phần mềm Các vấn đề khác bảo trì phần mềm a Tăng hiệu trình bảo trì phần mềm Bảo trì phần mềm giai đoạn tốn thời gian ngân sách, cần co phương phát triển phần mềm bảo trì hợp lý để giảm thiểu hao tốn bảo trì Chúng ta cần áp dụng thay đổi nhỏ với trình phát triển phần mềm, với trình bảo trì phần mềm phát triển kỹ thuật hỗ trợ cho 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ử bảo trì phần mềm Trong quy trình phát triển phần mềm, tăng hiệu bảo trì phần mềm cách để người chủ chốt trình bảo trì tham gia vào giai đoạn phân tich thiết kế, họ có hội hiểu sâu sắc vấn đề phần mềm họ cần bảo trì Thêm vào đó, cần chuẩn hóa khâu phát triển phần mềm, việc chuẩn hóa giúp cho trình tra cứu hay sửa đổi thuận tiện Bản thiết kế phần mềm cần thiết kế cho dễ bảo trì Trong quy trình bảo trì phần mềm co thể áp dụng số biện pháp như:  Sử dụng công cụ hỗ trợ phát triển phần mềm đề cập trên, trình bảo trì phần mềm tương tự trình phát triển phần mềm, việc sử dụng công cụ hỗ trợ phát triển phần mềm cần thiết  Chuẩn hóa thao tác bảo trì thiết bị môi trường bảo trì  Việc lưu lại thông tin bảo trì cần thiết, cần phải nắm rõ tiến độ, hiệu thiếu sót trình bảo trì, tra cứu thông tin bảo trì thường xuyên để có thay đổi 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 thiết kế, đặc tính phần mềm đó, thế, đội phát triển dự án nên cử người chủ chốt tiến hành bảo trì phần mềm sau dự án kết thúc giai đoạn phát triển Trong việc phát triển công cụ hỗ trợ bảo trì:  Cần đầu tư phát triển công cụ hỗ trợ bảo trì phần mềm công cụ dịch ngược(reverse engineering)…  Đầu tư cho công cụ xây dựng quản lý database cho bảo trì, công cụ quản lý hồ sơ, liệu, chương trình nguồn, liệu thử, lịch sử bảo trì b Tìm hiểu kỹ thuật dịch ngược (Reverse - engineering) Kỹ thuật dịch ngược trình phân tích xử lý hệ thống để nhận thành phần hệ thống mối liên hệ chúng, tạo miêu tả hệ thống thể khác cấp độ cao trừu tượng hóa Kỹ thuật đảo ngược yêu cầu cần xử lý để hiểu hệ thống phần mềm thời gian dài bị lỗi, tài liệu hết hạn sử dụng, phức tạp hệ thông thiếu hiểu biết bảo trì hệ thống Mục đích kỹ thuật dịch ngược lấy lại thông tin mất, làm chuyển đổi dễ dàng flatfom, để cải tiến hay cung cấp tài liệu, để cung cấp lựa chọn xem xét, trích thành phần sử dụng lại để đối phó với phức tạp, để mặt hiệu 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ử bảo trì phần mềm II Thực tế áp dụng công ty Trong trình làm 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 đị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 quy trình kiểm thử bảo trì, khảo sát công cụ mà công ty sử dụng Trong trình đó, chúng em nhận thấy vấn đề sau công ty:  Các công ty quan tâm đến vấn đề kiểm thử , đánh giá chất lượng sản phầm Các công ty có xây dựng cho đội ngũ tester chuyên biệt để đáp ứng yêu cầu sử dụng  Các công ty trình kiểm thử thực đầy đủ chiến lược kiểm thử Hầu hết, unit test đặ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 khâu khác trình kiểm thử  Hầu hết công ty sử dụng phương pháp kiểm tra hộp đen (có thể hộp xám) 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 sử dụng vài trường hợp đặc biệt Ví dụ khảo sát MISA chúng em nhận khẳng định anh trưởng phòng MISA sử dụng kiểm thử hộp đen không sử dụng phương pháp kiểm thử khác  Bên cạnh số phương pháp chiến lược kiểm thử nêu phần sở lý thuyết, số công ty sử dụng phương pháp khác kiểm thử tải Đây loại kiểm thử xác định khả chịu đựng hệ thống, phần mềm trước nhiều yêu cầu khác lúc từ phía khách hàng…  Hầu hết công ty chưa có quy trình chuẩn kiểm thử phần mềm mà làm việc dựa thói quen làm việc hàng ngày Một số công ty MISA,Fsoft có áp dụng cho vài chuẩn riêng khâu làm việc Tuy nhiên xét trình kiểm thử công ty chưa xây dựng chuẩn thống nhất, quy trình xuyên suốt  Hầu hết công ty chưa có công cụ hỗ trợ kiểm thử Tuy nhiên số công ty sử dụng hay vài công cụ để hỗ trở kiểm thử, quản lý lỗi Ví dụ Fsoft, team, dự án họ sử dụng công cụ hỗ trợ quản lý lỗi riêng, tùy theo dự án Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm Tuy nhiên dự án không cung cấp công cụ hỗ trợ thân Fsoft có hệ thống quản lý lỗi riêng DMS (defect manager system) Mỗi nhân viên khitham gia vào công ty học cách sử dụng hệ thống Tuy nhiên không sử dụng đến dự án có công cụ riêng Công ty MISA lại sử dụng nhiều công cụ Bug Jira để quản lý lỗi (đây hệ thống đánh giá tốt phù hợp với thực tế MISA) Exel để quản lý tescase, Source vault để quản lý tài liệu (xem thêm phần phụ lục biên khảo sát)  Hầu hết công ty khảo sát, việc bảo trì không trọng không tách riêng thành nhóm, phòng ban Việc bảo trì hệ thống đươc mặc định gần 100% người phát triển hệ thống xử lý họ người hiểu hệ thống Bên cạnh công cụ khảo sát tai công ty, có nhiều tool hỗ trợ kiểm thử như:  UCM(Unified Change Management)  Junit framework hỗ trợ xây dựng testing tự động 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ử bảo trì phần mềm III Bài học kinh nghiệm đánh giá kết luận nhóm Trong trình tìm hiểu đề tài, nhóm chúng em rút học kết luận sau:  Kiểm thử bảo trì phần mềm hai trình vô quan trọng vòng đời phát triển phần mềm Đây trình thiếu việc phát triển phần mềm thương mại  Kiểm thử bảo trì phần mềm có nhiều kĩ thuật khác nhau, thực tế công ty địa bàn Hà Nội sử dụng kĩ thuật công việc Tuy nhiên, dựa đặc thù công ty, việc bảo trì, kiểm thử phần mềm có đặc điểm khác Ví dụ kiểm thử hộp trắng fsoft sử dụng với chương trình nhỏ lập trình mobile, hệ thống lớn không sử dụng Còn với MISA sử dụng kiểm thử hộp đen trình kiểm thử cho rắng phương pháp kiểm thử thích hợp công ty  Trong thực tế, tổ đội xây dưng phần mềm chưa nhiều, hạn hẹp mặt quân số chất lượng, số công ty không tách chuyên biệt cá nhân vào 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 cá nhân Từ nâng cao chất lượng, thời gian kiểm thử Tuy nhiên phương pháp không áp dùng với phần mềm hệ thống lớn Do người kiểm thử người lập trình nên không mở rộng góc nhìn, đánh giá chuẩn xác, khách quan phần mềm cần kiểm thử, bảo trì.Bên cạnh đó, trình phát triển phần mềm , kiểm thử phần mềm không tách chuyên biện, lập trình viên bị trồng chéo công việc dễ bị nhầm lẫn  Trong trình xây dựng phát triển phần mềm, việc sử dụng công cụ hỗ trợ vô cần thiết Có công cụ hỗ trợ sử dủng đơn giản exel, word vv Điểm quan trọng cần biết phối hợp công cụ với công việc đặc thù công ty Qua nhận xét đánh giá, chúng em nhận thấy MISA mô hình điển hình việc áp dụng hiệu công cụ hỗ trợ kiểm thử việc quản lý testcase, quản lý bug, quản lý tài liệu, quản lý release phần mềm  Việc bảo trì phần mềm theo chúng em cần đề cao Mặc dù phần cần thiết kiểm thử phần mềm ngày nâng cao chất lượng để phần mềm hoàn thiện trước cung cấp rộng rãi tới khách hàng Tuy nhiên vãn cần đẩy mạnh bảo trì phần để đáp ứng nhu cầu khác người sử dụng Từ nâng cao chất lượng khách hàng Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử 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ử bảo trì phần mềm IV Phụ lục Biên khảo sát công ty trách nhiệm hữu hạn SeLab Ngày khảo sát Khảo sát viên 10/03/2010 Trương Thảo Nguyên Ngày update Tài liệu tham chiếu 10/03/2010 Selab Công ty Người Hoàng Minh Thảo – Nhân viên vấn 1.0 Version THÔNG TIN VỀ CÔNG TY KHẢO SÁT  Tên công ty: Công ty trách nhiệm hữu hạn Selab  Thông tin liên hệ: o o o o o  Website: www.selab.vn Địa chỉ: 181 Nguyễn Lương Bằng Email: N/A Điện thoại/Fax: N/A Thông tin khác: Giám đốc Đào Kiến Quốc Chức năng: Cung cấp sản phẩm o Netoffice: Phần mềm quản lý văn điều hành qua mạng o CMS - Phần mềm quản trị nội dung website o MRTEST – Phần mềm tổ chức thi trắc nghiệm với khả chấm nhận dạng quang học o Portal – Phần mềm cổng giao tiếp điện tử  Quy mô: 10 thành viên THÔNG TIN VỀ CÔNG VIỆC  Quy trình làm phần mềm B1: Giám đốc đàm phán hợp đồng B2: Giám đốc gửi hợp đồng yêu cầu xuống cho teamleader B3: Leader phân chia công việc bao gồm o Làm việc với khách hàng để khảo sát hệ thống o Xây dựng hệ thống phù hợp với yêu cầu (build từ đầu từ prototype có sẵn) o Kiểm thử nội Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm B4: Nhân viên tiến hành bàn giao, nghiệm thu với khách hàng B5: Đào tạo sử dụng, quản lý hệ thống theo yêu cầu khách hàng (1 phòng ban nhiều phòng ban) B6: Bảo trì Bao gồm hai loại:    o Sửa lỗi trình sử dụng (ghi nhân sửa lỗi Quản lý qua excel) o Nâng cấp theo version prototype Quy trình kiểm thử Ở công ty thực loại kiểm thử sau: o Component test: Coder tự test trước module o Validation test: Sử dụng hộp đen để kiểm tra chức Thông thường lập kịch kiểm tra luồng (quy trình nghiệp vụ), chức nhỏ để phát lỗi Sau kiểm tra lại độ chinh xác mặt liệu Bảo trì Như trình bày trên, bảo trì gồm hai loại Các phần mềm sử dụng Hiện công ty chưa sử dụng phần mềm hỗ trợ kiểm thử bảo trì Chú ý: Trong bước thực công ty không sử dụng mẫu văn mà tùy vào người thực Tuy nhiên có tham khảo số mẫu văn (Xem tài liệu tham chiếu) Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm Biên khảo sát công ty FPT Software Ngày khảo sát Khảo sát viên 20/03/2010 Trương Thảo Nguyên Ngày update Tài liệu tham chiếu 20/03/2010 Công ty Người vấn Version FPT software Đào Thị Hường– Nhân viên (Daohuong2003@gmail.com) 1.0 THÔNG TIN VỀ CÔNG TY KHẢO SÁT  Tên công ty: FPT Software  Thông tin liên hệ: o o o o o  Website: http://fpt-software.com Địa chỉ: FPT Building, Pham Hung St., Cau Giay District, Hanoi, Vietnam Email: Điện thoại/Fax: Tel.: +84 (4) 768 9048 / Fax: +84 (4) 768 9049 Thông tin khác: Chức năng: FPT Software nhà cung cấp dịch vụ gia công phần mềm Việt Nam Với đội ngũ nhân lực trẻ trung có khả khu vưc, cung cấp dịch vụ chất lượng cao: o Phát triển phần mềm bảo trì, giải pháp ERP kiểm tra đảm bảo chất lượng Embedded Systems, nhiều dịch vụ khác o Chúng tự hào kinh nghiệm lĩnh vực khác nhau, cụ thể Ngân hàng & Tài chính, Viễn thông, chế tạo, bảo hiểm, Chính phủ công cộng, bán lẻ, sở hạ tầng, dịch vụ tiện ích    Quy mô: N/A THÔNG TIN VỀ CÔNG VIỆC Công việc người khảo sát o Làm việc dự án Notess migration: Mảng CMT for notes Đây tools chuyển mails từ outlook sang notes (một hệ thống quản ly mail khác) Phương pháp: o Black box dự án o White box với mobile o Unit test, regresion test, system test, acceptem test Test tải (thỉnh thoảng ) Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm  Quy trình kiểm thử bảo trì o Training: Nhân viên training hệ thống notes xem hệ thống thao tác với email thế o Làm việc với đối tác:  Bên yêu cầu test gửi phiên sử dụng thời để nhân viên làm quen  Bên yêu cầu test gửi tài liệu tool (giới thiệu sơ tool, chức tool, hướng dẫn cách config ) o Nhân viên: liệt kê chức tool, tính toán khối lượng công việc (bao nhiêu testcase cho chức năng, thời gian cần thiết cho chức năng, tổng hợp số lượng testcase thời gian, nhân lực cần cho chức bao nhiêu? o Lập kế hoạch cho thời gian viết testcase (mỗi người testcase / khoảng thời gian) o Viết testcase Sau review test case (thường tiến hành chéo) Trong dự án đề cập xây dựng 300 testcase người viết Số testcase dự kiến tính toán thực 20-25 ngày o Đợi đẩy build yêu cầu test o Khi có build lập plan test (theo yêu cầu bên đối tác mà chọn1 loại)  Test full : Kiểm tra hết  Regresion test: theo case cảm giác có lỗi VD case test giao diện cần xem qua phát lỗi ko ? Tập trung vào test data  Quá trình tạo plan (số lượng testcase): tính toán thời gian test cho case (cho case  tổng thể), số lượng người tham gia  số lượng case người test ngày  số lượng ngày cần test bao nhiêu? o Gửi lại plan cho bên yêu cầu xem hợp lý chưa? Các kế hoạch test thường thực theo round o Tiến hành test:  Tạo test serial: dùng hệ thống đối tác để quản lý lỗi TestScript lưu toàn testcase tester test serial  Tiến hành test:  Kết lưu vào test serial  Lưu lại hình ảnh bước  Nếu có lỗi phải kiểm tra xem lỗi tồn chưa? (bằng hệ thống)  Nếu lỗi chưa tồn tại: tạo Devtask (1 loại lưu dạng lỗi), log lỗi vào vào hệ thống  Nếu lỗi tồn tại: refer đến Devtask  o Khi tiến hành xong round tiến hành fix version lặp lại Thỉnh thoảng đối tác đẩy số Devtask cho bên fsoft test kèm theo ver với hai yêu cầu:  Nếu Devtask pass bên đối tác chọn 2:  Regresion test:  Unit test: Chỉ định số cụ thể Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm  Nếu test Devtask mà lỗi đặt tráng thái lỗi trình test  đợi bên đối tác fix o Xong round bên đối tác ko hiểu Devtask gửi lại cho bên kiểm thử với trạng thái waiting information  Test lại  trả lời đối tác  Chú ý: o Tùy theo dự án mà có quy trình riêng, templates riêng.chuẩn tài liệu riêng o Tùy theo dự án có sử dụng công cụ hỗ trợ kiểm thử riêng với dụ án Trong dự án sử dụng công cụ BT để hỗ trợ kiểm thử Tuy nhiên Fsoft sử dụng hệ thống chuẩn để quản lý lỗi gọi DMS (defect manager system) o Phần bảo trì Developer thực hiện, không tester thực Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm Biên khảo sát công ty MISA Ngày khảo sát Khảo sát viên 19/03/2010 Trương Thảo Nguyên Ngày update Tài liệu tham chiếu 19/03/2010 Công ty Người vấn Version MISA Đỗ Mạnh Linh – trưởng phòng kiểm soát chất lượng 1.0 THÔNG TIN VỀ CÔNG TY KHẢO SÁT  Tên công ty: Công ty cổ phần MISA  Thông tin liên hệ: o o o o o Website: http://www.misa.com.vn/ Địa chỉ: Email: Điện thoại/Fax: Thông tin khác:  Chức năng:  o Cung cấp phần mềm đóng gói kế toán Quy mô: Phòng kiểm soát chất lượng có 30 người   THÔNG TIN VỀ CÔNG VIỆC Công việc người khảo sát o Trưởng phòng kiểm soát chất lượng Chịu trách nhiệm nhận dự án, chuẩn bị nhân lực cho dự án Đồng thời chịu trách nhiệm đào tạo nhân lực cho phòng Quy trình kiểm thử bảo trì: o Cơ cấu tổ chức phòng kiểm soát chất lượng  trưởng phòng: đào tạo nhân viên(kĩ năng), điều phối nhân cho dự án(),  phó phòng: trợ lý cho trưởng phòng công tác nghiệp vụ tài kế toàn  Truơng nhóm: phú trách dự án liên quan đến hành nghiệp, (phụ trách dự án liên quan đến tài kế toán) Là người trực tiệp lập kế hoạch cho dự án  Các nhóm: theo dự án (dự án nhỏ lĩnh vực lớn trên) o loại dự án:  Dự án bảo trì  Dự án o team người o leader o Quy trình kiểm thử: Chia thành nhiều phase Với phase tuân theo quy chuẩn: Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm  Lập kế hoạch test:  Work Break down (Chia công việc thành công việc nhỏ): Mã công việc, tên công việc, phân loại công việc…  đến mức chi tiết (teamleader)  Work Estimate: công việc chia nhỏ giờ, xác định resource  xác định resource cho phase dự án (team leader)  Review kế hoạch dự án: Trưởng phòng trưởng dự án  Design testcase (trưởng dự án làm)  Đầu vào: Tài liệu bên tư vấn nghiệp vụ thiết kế bên phát triển phần mềm  Đầu ra: Các tình xẩy với chức năng:  Số liệu đầu vào  Hành động thực  Kết kì vọng (kết đúng)  Kết thực tế (chức ko thành công/thành công,  Người design, người modify, add  Testcase đuợc lưu file exel (test suite)  người dùng quản lý (form – chức  sheet)  Review testcase: Các bước  Mời đại diện bên, trưởng phòng, trưởng dự án review  Nếu ok: Gửi lại biên chấp nhận  Nếu ko ok: Biên chưa ổn, sửa lại gửi lại  triển khai  Kiểm tra theo testcase  Leader chia việc cho thành viên nhóm  Tiến hành thực test sản phẩm dựa testcase…  Đầu vào: gửi email, đường dẫn đến cài đóng gói release …(ver)  Quy trình xử lý lôi:  Kiểm soát chất lượng:  Post lỗi lên hệ thống:  Trưởng dự án (pm) chuyển lỗi cho người có trách nhiệm sửa (resovle)  Sau người có trách nhiệm sửa fix lỗi này:  cán kiểm soát chât lượng kiểm tra lỗi fix chưa  Close lỗi  Reopen()  yêu cầu mở lại  Bàn giao sản phẩm o Các công cụ sử dụng hỗ trợ trình kiểm thử phần mềm:  Caliber : Quản lý requirement  User requirement  Software requirement Bài tập lớn nhâp môn công nghệ phần mềm – Kiểm thử bảo trì phần mềm  Jira: Công cụ quản lý bug (bug tracking)  Exel: Thiết kế testcase, quản lý testcase, checklist  Microsoft project: Hỗ trợ quản lý công việc nhân viên  Source vault : Quản lý tài liệu [...]... 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... 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. .. 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... 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... 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... 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ô... 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... 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. .. ổ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... 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ì