Link tải luận văn miễn phí cho ae Kết Nối
Luận văn: Nghiên cứu kỹ thuật kiểm thử phần mềm trên cơ sở mô hình UML : Luận văn ThS. Công nghệ thông tin: 60 48 10
Chủ đề: Công nghệ phần mềm
Công nghệ thông tin
Luận văn ThS. Công nghệ phần mềm -- Trường Đại học Công nghệ. Đại học Quốc gia Hà Nội, 2009
Tổng quan về các vấn đề cơ bản của kiểm thử phần mềm, các nguyên tắc kiểm thử. Khái quát về phát triển phần mềm dựa trên cấu phần bao gồm: các khái niệm cơ bản như cấu phần, chuẩn tương tác, chuẩn kết hợp, cài đặt mô hình cấu phần, các mô hình cấu phần - dịch vụ cấu phần, tiếp cận ngôn ngữ mô hình hóa thống nhất (UML), và vai trò của UML đặc tả thiết kế, ứng dụng vào thử nghiệm. Nghiên cứu phương pháp luận kiểm thử phần mềm trên cơ sở cấu phần: mô hình kiểm thử đối với phần mềm dựa trên cấu phần, kiển thử tích hợp trên cơ sở các mô hình UML đối với phần mềm phát triển trên cấu phần. Đồng thời xây dựng các biểu đồUML hỗ trợ ca kiểm thử tích hợp. Phát triển thực nghiệm kiểm thử phần mềm trên cơ sở sử dụng các cấu phần có sẵn dựa trên bài toán ứng dụng được đưa ra; ngoài ra xây dựng các pha phân tích, thiết kế và thử nghiệm
Chương 1: Giới thiệu ............................................................................................................. 1
1.1. Giới thiệu nhiệm vụ chính của đề tài....................................................................... 1
1.2. Tình hình nghiên cứu trong và ngoài nước.............................................................. 2
1.3. Mục tiêu của luận văn............................................................................................. 3
Chương 2: Một số khái niệm cơ bản....................................................................................... 4
2.1 Phần mềm sử dụng cấu phần ........................................................................................ 5
2.1.1 Chuẩn tương tác [3] ............................................................................................... 6
2.1.2 Chuẩn kết hợp [3].................................................................................................. 7
2.2 Vòng đời phát triển phần mềm trên cơ sở cấu phần....................................................... 9
2.3 Các mô hình cấu phần và dịch vụ cấu phần................................................................. 12
2.3.1 Mô hình cấu phần ................................................................................................ 12
2.3.2 Sự cài đặt mô hình cấu phần và các dịch vụ ......................................................... 16
2.4 UML trong phát triển phần mềm ................................................................................ 19
2.4.1 Mục tiêu của UML .............................................................................................. 19
2.4.2 Vai trò, vị trí của các lược đồ UML trong vòng đời phần mềm............................. 21
2.4.3 Các công cụ xây dựng UML ................................................................................ 22
2.5 Lý thuyết kiểm thử ..................................................................................................... 24
2.5.1 Tại sao kiểm thử là cần thiết? [2] ......................................................................... 24
2.5.2 Nguyên nhân gây lỗi phần mềm........................................................................... 25
2.5.3 Vai trò của kiểm thử trong phát triển phần mềm .................................................. 28
Chương 3: Kiểm thử trên cơ sở các mô hình UML ............................................................... 34
3.1. Các thành phần của cấu phần ................................................................................ 34
3.2. UML và kiểm thử ................................................................................................. 35
3.3. Kiểm thử phần mềm trên cơ sở cấu phần .............................................................. 42
3.4. Các khía cạnh kiểm thử ........................................................................................ 46
3.3.1. Khía cạnh cấu trúc của kiểm thử ......................................................................... 47
3.3.2. Khía cạnh hành vi của kiểm thử .......................................................................... 48
3.5. Mô hình kiểm thử trong phần mềm cấu phần [5]................................................... 50
3.4.1 Mô hình tương tác ............................................................................................... 50
3.4.2 Mô hình hành vi .................................................................................................. 51
3.4.3 Cấu trúc điều khiển.............................................................................................. 52
3.4.4 Các quan hệ về tương tác dữ liệu ......................................................................... 52
3.6. UML trong pha kiểm thử tích hợp......................................................................... 53
3.5.1 Mô hình áp dụng cho kiểm thử tích hợp phần mềm cấu phần ............................... 55
3.5.2. Các tiếp cận kiểm thử tích hợp trên cơ sở UML ............................................ 58
Chương 4: Thực nghiệm kiểm thử phần mềm....................................................................... 64
4.1 Sử dụng cấu phần Text trong Java .............................................................................. 64
4.2 Bài toán ( Phát biểu)................................................................................................... 66
4.3 Quy trình xây dựng tài liệu kiểm thử dựa trên mô hình UML ..................................... 67
4.4 Mô hình xây dựng use-case với bài toán thực tế.......................................................... 67
4.4.1 Xây dựng luồng nghiệp vụ trên cơ sở cách tiếp cận mô hình cộng tác/tuần tự ...... 68
4.4.2 Quản lý kho ......................................................................................................... 70
4.4.3 Xây dựng chương trình........................................................................................ 94
4.4.4 Các bước thực hiện chương trình ......................................................................... 96
4.4.5 Xây dựng các tình huống kiểm thử ...................................................................... 97
Kết luận ............................................................................................................................. 103
Tóm tắt kết quả chính đã đạt được.................................................................................. 103
Tồn tại và hướng phát triển ............................................................................................ 104
Tài liệu tham khảo ............................................................................................................. 106
Chương 1: Giới thiệu
1.1. Giới thiệu nhiệm vụ chính của đề tài
Kiểm thử là một khâu không thể thiếu trong quá trình phát triển phần mềm.
Nhiều hệ thống phần mềm thất bại là do không tìm ra lỗi. Nguồn lực sử dụng
cho khâu kiểm thử là một yêu cầu khá lớn trong quá trình phát triển phần mềm.
Quá trình kiểm thử yêu cầu một số pha kết hợp gồm: 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.
Quy trình kiểm thử được xây dựng nhằm đạt các mục tiêu chính như sau:
Xem xét các yêu cầu đưa ra bởi khách hàng, đối chiếu với sản phẩm
phần mềm được lập trình bởi lập trình viên.
Phát hiện các sai sót hay lỗi trong phần mềm mà ở đó hành vi phần
mềm là không đúng, hay không tuân theo các đặc tả của nó.
Phương pháp hướng đối tượng (Object-Oriented) đã thể hiện rõ tính ưu việt
trong phát triển phần mềm. Trong đó, tính đóng gói, trừu tượng hóa và tính sử
dụng lại làm tăng chất lượng phần mềm. Theo Paul Allen thì hiện nay có đến
hơn 70% hệ thống phần mềm mới được phát triển dựa trên cơ sở cấu phần. Các
cấu phần thường được phát triển theo hướng đối tượng và được viết bằng các
ngôn ngữ khác nhau, chạy trên các môi trường khác nhau, có thể phân tán khắp
nơi và người phát triển phần mềm mới không được cung cấp các mã nguồn. Các
đặc tính này là nguyên nhân gây nhiều khó khăn trong việc kiểm thử hệ thống
phần mềm. Để tăng tính mềm dẻo khi nhìn nhận các chức năng, đặc điểm phần
mềm xây dựng, chúng ta sử dụng ngôn ngữ mô hình hóa chuẩn UML.
Ngôn ngữ mô hình hóa thống nhất (UML – Unified Modeling Language)
được công nhận là chuẩn công nghiệp cho việc phân tích và thiết kế các hệ
thống hướng đối tượng. UML cung cấp các ký pháp biểu đồ thể hiện các thông
tin thiết kế dưới các góc độ nhìn hệ thống. Trong những năm gần đây, đã có
nhiều nghiên cứu sử dụng mô hình UML như nguồn thông tin đầu vào cho kiểm
thử phần mềm. Thí dụ, biểu đồ trạng thái UML được sử dụng biểu diễn hành vi
bên trong của các đối tượng thành phần, các biểu đồ tương tác được được ứng
dụng trong kiểm thử tương tác các lớp trong cấu phần. Biểu đồ hoạt động biểu
diễn quan hệ giữa các thành phần trong cấu phần.
Thực tế cho thấy phương pháp Phát triển phần mềm theo cấu phần đã làm
giảm chi phí của dự án phát triển phần mềm. So với công nghệ truyền thống
chuẩn, công nghệ phần mềm trên cơ sở cấu phần quan tâm đến cách xây dựng
phần mềm nhiều hơn. Thông qua việc sử dụng lại các cấu phần, vòng đời phát
triển phần mềm được rút ngắn lại, đồng thời tăng tính mềm dẻo khi sử dụng và
bảo trì phần mềm. Hơn nữa, phát triển phần mềm có khả năng làm tăng chất
lượng phần mềm. Với tầm quan trọng như trên, đã có nhiều kết quả nghiên cứu
lý thuyết và sản phẩm công cụ hỗ trợ phát triển phần mềm trên cơ sở cấu phần.
Nội dung luận văn này nhằm mục tiêu khảo sát các vấn đề cơ bản và kỹ thuật
phát triển phần mềm theo cấu phần. Đặc biệt luận văn tập trung vào kỹ thuật
kiểm thử phần mềm phát triển dựa theo cấu phần với mục đích hướng tới ứng
dụng thực tế tại Việt Nam.
1.2. Tình hình nghiên cứu trong và ngoài nước
Năm 1975 Freed Brooks, một nhà quản lý dự án IBM, viết cuốn The
Mythical Man-month. Bài luận ngắn trong trong cuốn sách này mô tả những khó
khăn khi phát triển phần mềm phức tạp, Brooks viết một chương với tiêu đề là
“No Silver Bullet” giải thích rằng các hệ thống phần mềm là phức tạp. Ông dự
đoán sẽ không có kỹ thuật nào là duy nhất – no silver bullet – mà nó có thể cải
thiện năng suất theo danh sách yêu cầu cho mọi hệ thống. Trong chương này,
Brooker trích dẫn ra các lý do gây nên “khủng hoảng phần mềm”, và khủng
hoảng này sẽ còn tiếp tục cho đến khi một kỹ thuật mới như công nghệ phần
mềm trên cơ sở cấu phần (CBSE – Component based software engineering) trở
nên có tính khoa học và nó thực sự dựa trên tính khoa học.
Và như thế, CBSE đã đưa ra được “Những bài học hay nhất” về sản phẩm
công nghệ phần mềm trong suốt 30 năm tiếp theo. Brooks trình bày 2 phương
pháp khả thi giúp giảm mức độ phức tạp của phần mềm đó là “Buy before
Build” và “Reuse before Buy”. Các khái niệm mấu chốt được đưa ra nhằm giúp
giảm được chi phí trong công nghệ phát triển phần mềm.
Trong hội nghị thảo luận năm 1968, NATO đã tham gia tranh luận về thuật
ngữ khủng hoảng phần mềm. Thêm nhiều thuật ngữ khó hiểu như kẽ hở phần
mềm, … các thuật ngữ này dần dần được làm rõ khi trong quá trình phát triển
công nghệ phần mềm. Theo David và Fraser phát biểu năm 1968, “ Kẽ hở được
phát hiện tại thời điểm khi mà hậu quả việc hỏng hóc phần mềm tăng theo mọi
mức độ nghiêm trọng”. Để phát triển phần mềm trên cơ sở cấu phần chúng ta
phải học cách xây dựng các cấu phần đó dựa vào các yêu cầu, hay dựa trên việc
thiết kế các module thành phần hay các thiết kế trực tiếp các cấu phần. Các
khách hàng đặt hàng (các cấu phần) và việc tích hợp các cấu phần cung cấp bởi
nhà sản xuất sẽ đảm bảo rằng nó đáp ứng được yêu cầu khách hàng với các
mong muốn họ đưa ra.
Khái niệm về mô hình của cấu phần phần mềm được phát triển rộng rãi bởi
BradCox và đặt nền móng cho việc tạo một hạ tầng phát triển các cấu phần này
dựa trên ngôn ngữ lập trình C (Nội dung được đúc kết trong cuốn sách ObjectOriented Programming – An Evolution Approach 1986)
IBM tiên phong mở ra lối nghiên cứu về Mô hình đối tượng hệ thống ngay
đầu những năm 1990. Một số các đóng góp được ứng dụng trong phần mềm cấu
phần đó là OLE và COM. Mô hình cấu phần phần mềm vẫn tiếp tục thu được
những thành quả đáng kể.
1.3. Mục tiêu của luận văn
Luận văn này nhằm mục tiêu nghiên cứu khảo sát sơ bộ các kỹ thuật kiểm
thử phần mềm, với giải pháp áp dụng các mô hình UML vào kiểm thử phần
mềm trên cơ sở cấu phần. Từ đó, áp dụng các kết quả nghiên cứu lý thuyết vào
thực nghiệm kiểm thử một thiết kế phần mềm cụ thể mà luận văn đưa ra.
Nội dung nghiên cứu tập trung vào một số vấn đề sau:
1) Tổng quan về các vấn đề cơ bản của kiểm thử phần mềm, các nguyên
tắc kiểm thử. Tổng quan về phát triển phần mềm dựa trên cấu phần, bao gồm
các khái niệm cơ bản như cấu phần, chuẩn tương tác, chuẩn kết hợp, cài đặt
mô hình cấu phần, các mô hình cấu phần - dịch vụ cấu phần, tiếp cận UML,
và vai trò của UML đặc tả thiết kế, ứng dụng vào kiểm thử.
2) Nghiên cứu phương pháp luận kiểm thử phần mềm trên cơ sở cấu
phần, bao gồm mô hình kiểm thử đối với phần mềm dựa trên cấu phần, kiểm
thử tích hợp trên cơ sở các mô hình UML đối với phần mềm phát triển trên
cấu phần. Xây dựng các biểu đồ UML hỗ trợ ca kiểm thử tích hợp.
3) Phát triển thực nghiệm kiểm thử phần mềm trên cơ sở sử dụng các
cấu phần có sẵn dựa trên bài toán ứng dụng được đưa ra; xây dựng các pha
phân tích, thiết kế và kiểm thử.
Chương 2: Một số khái niệm cơ bản
Lập trình hướng cấu phần (COP – Component oriented programming) và
công nghệ phần mềm trên cơ sở cấu phần (CBSE – Component based software
engineering) đôi khi có thể hiểu là một. Tuy nhiên, CBSE là thuật ngữ rộng hơn,
và COP chỉ là một phần trong đó.
CBSE = COA + COD + COP + COM
Trong đó COA (component oriented analysis), COD (Component oriented
design) và COM (Component oriented management) thể hiện các thuật ngữ về
phân tích hướng cấu phần, thiết kế hướng cấu phần và quản lý hướng cấu phần.
Mục tiêu của CBSE là phát triển phần mềm một cách nhanh chóng, và giảm chi
phí bằng cách xây dựng các hệ thống thông qua việc thu thập các cấu phần có
sẵn. Thiết kế, phát triển, và duy trì các cấu phần nhằm mục đích sử dụng lại là
một quy trình rất phức tạp, với các yêu cầu ở mức cao không chỉ đáp ứng được
tính chức năng và mềm dẻo cấu phần mà còn đáp ứng việc phát triển phần mềm
một cách có tổ chức. CBSE bao gồm rất nhiều các nguyên tắc công nghệ phần
mềm và các kỹ thuật khác nhau.
Trong công nghệ phần mềm truyền thống, quy trình phát triển phần mềm bao
gồm các hoạt động hay các trạng thái tuần tự, cách đặt tên, phân tích, thiết kế,
ngôn ngữ lập trình, kiểm thử, và tích hợp. Trong CBSE, các giai đoạn phát triển
chính vẫn tuân thủ theo các bước thực hiện như quy trình phát triển truyền
thống, và bổ sung thêm bước tập hợp và lắp ghép các cấu phần. Ta có thể nhận
thấy rằng, điểm nổi bật trong CBSE so với công nghệ phần mềm truyền thống
chính nằm ở hướng thiết kế, bước thu thập và lắp ghép các cấu phần vào việc
xây dựng một hệ thống hoàn thiện.
Dưới cách nhìn về các cấu phần, có 2 loại hoạt động căn bản đó là: Phát triển
cấu phần để sử dụng lại (DF – Developing for reuse) và sử dụng lại các cấu phần
đã có sẵn (DW - Developing with reuse). Với việc phát triển cấu phần để sử
dụng lại có thể được tổ chức theo cách tiếp cận công nghệ phần mềm truyền
thống, nhấn mạnh vào các chuẩn cấu phần. Mỗi cấu phần cung cấp 2 loại giao
diện: (1) giao diện cung ứng – định nghĩa các dịch vụ quảng bá cấu phần này sẽ
cung ứng và (2) giao diện yêu cầu – đặc tả các dịch vụ mà cấu phần cần đến để
thể hiện khả năng làm việc.
Theo các nhìn hướng quy trình công nghệ, có 5 cách định nghĩa khác nhau
trong CBSE:
1. Đặc tả cấu phần (Component specification): Nó thể hiện đơn vị đặc tả của
phần mềm, mô tả hành vi của tập các đối tượng cấu phần và định nghĩa một đơn
vị thực hiện. Hành vi được định nghĩa dưới dạng tập các giao diện. Một đặc tả
cấu phần được nhận diện dưới dạng một thực thi cấu phần.
2. Giao diện cấu phần (Component interface): Giao diện thể hiện định nghĩa
tập các hành vi có thể được cung ứng thông qua một đối tượng cấu phần.
3. Sự thực thi cấu phần (Component implementation): Là một sự nhận diện
của đặc tả cấu phần, có khả năng triển khai độc lập. Điều này nghĩa là nó có thể
được cài đặt và thay thế một cách độc lập các cấu phần khác. Như thế không có
nghĩa là nó độc lập với các cấu phần khác – nó có rất nhiều sự phụ thuộc.
4. Cấu phần được cài đặt (Installed component): Là sự sao chép của
một thực thi cấu phần dưới hình thức cài đặt (hay triển khai). Một sự
thực thi cấu phần được triển khai bằng cách đăng ký nó với môi trường
khi chạy thật. Môi trường chạy thật định nghĩa khả năng của cấu phần
được cài đặt nhằm tạo một thể hiện khi thực hiện bước vận hành nó.
5. Đối tượng cấu phần (Component object): Một đối tượng cấu phần là một
thể hiện của cấu phần được cài đặt. Khái niệm này khá giống với khái niệm
trong lập trình hướng đối tượng, một đối tượng cấu phần trong lập trình hướng
cấu phần là một đối tượng có dữ liệu riêng và định nghĩa duy nhất, nó thực hiện
hành vi thực thi xác định. Một cấu phần cài đặt có thể có các đối tượng cấu
phần đa nhiệm hay đơn nhiệm.
2.1 Phần mềm sử dụng cấu phần
Để tìm hiểu, nghiên cứu về mục tiêu mà luận văn đã đề ra, trước tiên, ta đi
vào việc tìm hiểu các thuật ngữ cơ bản được sử dụng trong CBSE, ta đi từ các
khái niệm nhỏ nhất, đơn giản nhất về cấu phần.
Một phần tử phần mềm chứa chuỗi các lệnh cấp cao, các tính toán được thực
hiện bởi máy tính. Phần tử phần mềm là thực thi nếu: (1) máy tính trực tiếp thực
thi các lệnh hay (2) có một bộ thông dịch chạy trên máy tính dịch các câu lệnh
sang dạng máy thực thi được.
Mã nguồn phần mềm là tập các file máy có thể đọc được, chứa các câu lệnh
chương trình được viết ứng với một ngôn ngữ lập trình. Các câu lệnh này được
dịch thành các câu lệnh thực thi được hay nhờ vào bộ biên dịch hay bộ thông
dịch.
Một cấu phần phần mềm là một tập các phần tử phần mềm được lập trình.
Cấu phần đó được cài đặt, và đưa vào sử dụng. Sự khác nhau giữa phần tử phần
mềm và cấu phần phần mềm được thể hiện ở cách sử dụng. Phần mềm bao gồm
rất nhiều yếu tố trừu tượng, các đặc trưng chất lượng. Đó là thước đo để đánh
giá một cấu phần hay một quy trình có đáp ứng yêu cầu đặc tả hay không (theo
chuẩn IEEE 610.12 – 1990). Thuật ngữ phần tử được đặt trong phạm vi mô tả về
cấu phần phần mềm như sau:
Một cấu phần phần mềm là một phần tử phần mềm tuân theo một mô hình
cấu phần và có thể triển khai độc lập, được kết hợp mà không cần sửa đổi
theo một chuẩn kết hợp.
Một mô hình cấu phần định nghĩa các đặc tả tương tác và các chuẩn kết
hợp.
Một cài đặt mô hình cấu phần là một tập hợp các phần tử phần mềm xác
định cần có để hỗ trợ việc thực thi của các cấu phần tuân theo mô hình.
Hạ tầng của cấu phần phần mềm, là một tập hợp các cấu phần phần mềm
tương tác được thiết kế để đảm bảo rằng hệ thống phần mềm được xây
dựng sử dụng các cấu phần và giao diện này sẽ thỏa mãn các đặc tả hiệu
năng đã định nghĩa.
Các định nghĩa này thể hiện mối quan hệ quan trọng giữa hạ tầng của cấu
phần phần mềm, các cấu phần phần mềm và mô hình cấu phần.
Khả năng của cấu phần và cách dùng nó được đặc tả bởi giao diện. Giao diện
là một sự trừu tượng hóa dịch vụ, nó định nghĩa các thao tác mà dịch vụ hỗ trợ,
nó độc lập với bất kỳ sự thực thi đặc biệt nào. Một cấu phần phần mềm giao tiếp
và tương tác với thế giới bên ngoài thông qua giao diện của nó, với tài liệu đặc
tả giao diện và tương tác sẽ cho chúng ta biết được nó làm gì (what), nội dung
của mã thực thi trong cấu phần, quy trình xử lý (how) được ẩn hoàn toàn và
người sử dụng cấu phần không phải quan tâm tới việc nó làm như thế nào.
2.1.1 Chuẩn tương tác [3]
Chuẩn giao diện là các yêu cầu bắt buộc phải sử dụng và tuân theo đối với
cấu phần phần mềm để các phần tử phần mềm tương tác trực tiếp với các phần
tử khác. Chuẩn giao diện khai báo một giao diện có thể chứa cái gì.
Kết luận
Hiện nay, phát triển phần mềm hướng cấu phần (CBSE) đang thu hút các
nghiên cứu từ rất nhiều góc độ khác nhau như kỹ thuật xây dựng, đánh giá, kiểm
định phần mềm, quy trình khảo sát, phân tích thiết kế, quản lý.
Phát triển phần mềm hướng cấu phần (CBSE) là một công nghệ quan trọng
cho phép xây dựng những hệ thống phần mềm chất lượng cao, mở và các hệ
thống phần mềm lớn bằng cách tích hợp các cấu phần phần mềm đã tồn tại trước
đó. CBSE đã giảm bớt được giá thành phát triển phần mềm, xây dựng các hệ
thống một cách nhanh chóng, giảm bớt được việc bảo trì theo kiểu xoắn ốc liên
quan đến việc hỗ trợ và nâng cấp cho các hệ thống lớn. CBSE đang thu hút các
nghiên cứu rất nhiều từ góc độ các kỹ thuật xây dựng, đánh giá phần mềm cho
tới quy trình khảo sát, phân tích thiết kế, quản lý, đánh giá. Một trong những
hướng nghiên cứu hiện nay là thay đổi cách phát triển của các hệ thống phần
mềm: chuyển từ việc lập trình tạo ra các sản phẩm sang việc biên soạn các hệ
thống phần mềm, tức là chỉ tập trung vào việc lựa chọn và tích hợp các cấu phần
có sẵn để xây dựng nên các hệ thống. Trong phương pháp phát triển này việc
tìm kiếm các cấu phần và lựa chọn tích hợp các dịch vụ của các cấu phần đang
là hai vấn đề đang tập trung nghiên cứu.
UML hỗ trợ phát triển phần mềm hướng cấu phần đã đem đến cho các đối
tượng phát triển hệ thống cái nhìn rõ ràng về hệ thống xây dựng, giúp cho người
phân tích thiết kế thấy được các yếu tố ảnh hưởng trực tiếp tới hệ thống. Trên cơ
sở đó, cán bộ phân tích hệ thống xác định được các cấu phần cần tích hợp với hệ
thống.
Tham gia vào quy trình phát triển phần mềm luôn có sự góp mặt của bộ phận
kiểm định phần mềm. Với phương pháp phát triển phần mềm cấu phần trên, kết
hợp với bước kiểm định sẽ làm giảm thiểu một cách tối đa các lỗi trong phần
mềm. Tuy thế, Mặt khác, ta cũng không thể khẳng định rằng khi phát triển phần
mềm trên cơ sở cấu phần, với sự tham gia của UML trong thiết kế thì phần mềm
làm ra sẽ không còn lỗi.
Tóm tắt kết quả chính đã đạt được
Qua thời gian nghiên cứu tìm hiểu về phần mềm xây dựng trên cơ sở cấu
phần, áp dụng UML trong CBSE, kiểm thử phần mềm, tui đã áp dụng nghiên
cứu kiểm thử phần mềm vào phần mềm hướng cấu phần và đã đạt được những
kết quả nhất định. Một trong những công việc quan trọng của kỹ thuật kiểm thử
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
Luận văn: Nghiên cứu kỹ thuật kiểm thử phần mềm trên cơ sở mô hình UML : Luận văn ThS. Công nghệ thông tin: 60 48 10
Chủ đề: Công nghệ phần mềm
Công nghệ thông tin
Luận văn ThS. Công nghệ phần mềm -- Trường Đại học Công nghệ. Đại học Quốc gia Hà Nội, 2009
Tổng quan về các vấn đề cơ bản của kiểm thử phần mềm, các nguyên tắc kiểm thử. Khái quát về phát triển phần mềm dựa trên cấu phần bao gồm: các khái niệm cơ bản như cấu phần, chuẩn tương tác, chuẩn kết hợp, cài đặt mô hình cấu phần, các mô hình cấu phần - dịch vụ cấu phần, tiếp cận ngôn ngữ mô hình hóa thống nhất (UML), và vai trò của UML đặc tả thiết kế, ứng dụng vào thử nghiệm. Nghiên cứu phương pháp luận kiểm thử phần mềm trên cơ sở cấu phần: mô hình kiểm thử đối với phần mềm dựa trên cấu phần, kiển thử tích hợp trên cơ sở các mô hình UML đối với phần mềm phát triển trên cấu phần. Đồng thời xây dựng các biểu đồUML hỗ trợ ca kiểm thử tích hợp. Phát triển thực nghiệm kiểm thử phần mềm trên cơ sở sử dụng các cấu phần có sẵn dựa trên bài toán ứng dụng được đưa ra; ngoài ra xây dựng các pha phân tích, thiết kế và thử nghiệm
Chương 1: Giới thiệu ............................................................................................................. 1
1.1. Giới thiệu nhiệm vụ chính của đề tài....................................................................... 1
1.2. Tình hình nghiên cứu trong và ngoài nước.............................................................. 2
1.3. Mục tiêu của luận văn............................................................................................. 3
Chương 2: Một số khái niệm cơ bản....................................................................................... 4
2.1 Phần mềm sử dụng cấu phần ........................................................................................ 5
2.1.1 Chuẩn tương tác [3] ............................................................................................... 6
2.1.2 Chuẩn kết hợp [3].................................................................................................. 7
2.2 Vòng đời phát triển phần mềm trên cơ sở cấu phần....................................................... 9
2.3 Các mô hình cấu phần và dịch vụ cấu phần................................................................. 12
2.3.1 Mô hình cấu phần ................................................................................................ 12
2.3.2 Sự cài đặt mô hình cấu phần và các dịch vụ ......................................................... 16
2.4 UML trong phát triển phần mềm ................................................................................ 19
2.4.1 Mục tiêu của UML .............................................................................................. 19
2.4.2 Vai trò, vị trí của các lược đồ UML trong vòng đời phần mềm............................. 21
2.4.3 Các công cụ xây dựng UML ................................................................................ 22
2.5 Lý thuyết kiểm thử ..................................................................................................... 24
2.5.1 Tại sao kiểm thử là cần thiết? [2] ......................................................................... 24
2.5.2 Nguyên nhân gây lỗi phần mềm........................................................................... 25
2.5.3 Vai trò của kiểm thử trong phát triển phần mềm .................................................. 28
Chương 3: Kiểm thử trên cơ sở các mô hình UML ............................................................... 34
3.1. Các thành phần của cấu phần ................................................................................ 34
3.2. UML và kiểm thử ................................................................................................. 35
3.3. Kiểm thử phần mềm trên cơ sở cấu phần .............................................................. 42
3.4. Các khía cạnh kiểm thử ........................................................................................ 46
3.3.1. Khía cạnh cấu trúc của kiểm thử ......................................................................... 47
3.3.2. Khía cạnh hành vi của kiểm thử .......................................................................... 48
3.5. Mô hình kiểm thử trong phần mềm cấu phần [5]................................................... 50
3.4.1 Mô hình tương tác ............................................................................................... 50
3.4.2 Mô hình hành vi .................................................................................................. 51
3.4.3 Cấu trúc điều khiển.............................................................................................. 52
3.4.4 Các quan hệ về tương tác dữ liệu ......................................................................... 52
3.6. UML trong pha kiểm thử tích hợp......................................................................... 53
3.5.1 Mô hình áp dụng cho kiểm thử tích hợp phần mềm cấu phần ............................... 55
3.5.2. Các tiếp cận kiểm thử tích hợp trên cơ sở UML ............................................ 58
Chương 4: Thực nghiệm kiểm thử phần mềm....................................................................... 64
4.1 Sử dụng cấu phần Text trong Java .............................................................................. 64
4.2 Bài toán ( Phát biểu)................................................................................................... 66
4.3 Quy trình xây dựng tài liệu kiểm thử dựa trên mô hình UML ..................................... 67
4.4 Mô hình xây dựng use-case với bài toán thực tế.......................................................... 67
4.4.1 Xây dựng luồng nghiệp vụ trên cơ sở cách tiếp cận mô hình cộng tác/tuần tự ...... 68
4.4.2 Quản lý kho ......................................................................................................... 70
4.4.3 Xây dựng chương trình........................................................................................ 94
4.4.4 Các bước thực hiện chương trình ......................................................................... 96
4.4.5 Xây dựng các tình huống kiểm thử ...................................................................... 97
Kết luận ............................................................................................................................. 103
Tóm tắt kết quả chính đã đạt được.................................................................................. 103
Tồn tại và hướng phát triển ............................................................................................ 104
Tài liệu tham khảo ............................................................................................................. 106
Chương 1: Giới thiệu
1.1. Giới thiệu nhiệm vụ chính của đề tài
Kiểm thử là một khâu không thể thiếu trong quá trình phát triển phần mềm.
Nhiều hệ thống phần mềm thất bại là do không tìm ra lỗi. Nguồn lực sử dụng
cho khâu kiểm thử là một yêu cầu khá lớn trong quá trình phát triển phần mềm.
Quá trình kiểm thử yêu cầu một số pha kết hợp gồm: 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.
Quy trình kiểm thử được xây dựng nhằm đạt các mục tiêu chính như sau:
Xem xét các yêu cầu đưa ra bởi khách hàng, đối chiếu với sản phẩm
phần mềm được lập trình bởi lập trình viên.
Phát hiện các sai sót hay lỗi trong phần mềm mà ở đó hành vi phần
mềm là không đúng, hay không tuân theo các đặc tả của nó.
Phương pháp hướng đối tượng (Object-Oriented) đã thể hiện rõ tính ưu việt
trong phát triển phần mềm. Trong đó, tính đóng gói, trừu tượng hóa và tính sử
dụng lại làm tăng chất lượng phần mềm. Theo Paul Allen thì hiện nay có đến
hơn 70% hệ thống phần mềm mới được phát triển dựa trên cơ sở cấu phần. Các
cấu phần thường được phát triển theo hướng đối tượng và được viết bằng các
ngôn ngữ khác nhau, chạy trên các môi trường khác nhau, có thể phân tán khắp
nơi và người phát triển phần mềm mới không được cung cấp các mã nguồn. Các
đặc tính này là nguyên nhân gây nhiều khó khăn trong việc kiểm thử hệ thống
phần mềm. Để tăng tính mềm dẻo khi nhìn nhận các chức năng, đặc điểm phần
mềm xây dựng, chúng ta sử dụng ngôn ngữ mô hình hóa chuẩn UML.
Ngôn ngữ mô hình hóa thống nhất (UML – Unified Modeling Language)
được công nhận là chuẩn công nghiệp cho việc phân tích và thiết kế các hệ
thống hướng đối tượng. UML cung cấp các ký pháp biểu đồ thể hiện các thông
tin thiết kế dưới các góc độ nhìn hệ thống. Trong những năm gần đây, đã có
nhiều nghiên cứu sử dụng mô hình UML như nguồn thông tin đầu vào cho kiểm
thử phần mềm. Thí dụ, biểu đồ trạng thái UML được sử dụng biểu diễn hành vi
bên trong của các đối tượng thành phần, các biểu đồ tương tác được được ứng
dụng trong kiểm thử tương tác các lớp trong cấu phần. Biểu đồ hoạt động biểu
diễn quan hệ giữa các thành phần trong cấu phần.
Thực tế cho thấy phương pháp Phát triển phần mềm theo cấu phần đã làm
giảm chi phí của dự án phát triển phần mềm. So với công nghệ truyền thống
chuẩn, công nghệ phần mềm trên cơ sở cấu phần quan tâm đến cách xây dựng
phần mềm nhiều hơn. Thông qua việc sử dụng lại các cấu phần, vòng đời phát
triển phần mềm được rút ngắn lại, đồng thời tăng tính mềm dẻo khi sử dụng và
bảo trì phần mềm. Hơn nữa, phát triển phần mềm có khả năng làm tăng chất
lượng phần mềm. Với tầm quan trọng như trên, đã có nhiều kết quả nghiên cứu
lý thuyết và sản phẩm công cụ hỗ trợ phát triển phần mềm trên cơ sở cấu phần.
Nội dung luận văn này nhằm mục tiêu khảo sát các vấn đề cơ bản và kỹ thuật
phát triển phần mềm theo cấu phần. Đặc biệt luận văn tập trung vào kỹ thuật
kiểm thử phần mềm phát triển dựa theo cấu phần với mục đích hướng tới ứng
dụng thực tế tại Việt Nam.
1.2. Tình hình nghiên cứu trong và ngoài nước
Năm 1975 Freed Brooks, một nhà quản lý dự án IBM, viết cuốn The
Mythical Man-month. Bài luận ngắn trong trong cuốn sách này mô tả những khó
khăn khi phát triển phần mềm phức tạp, Brooks viết một chương với tiêu đề là
“No Silver Bullet” giải thích rằng các hệ thống phần mềm là phức tạp. Ông dự
đoán sẽ không có kỹ thuật nào là duy nhất – no silver bullet – mà nó có thể cải
thiện năng suất theo danh sách yêu cầu cho mọi hệ thống. Trong chương này,
Brooker trích dẫn ra các lý do gây nên “khủng hoảng phần mềm”, và khủng
hoảng này sẽ còn tiếp tục cho đến khi một kỹ thuật mới như công nghệ phần
mềm trên cơ sở cấu phần (CBSE – Component based software engineering) trở
nên có tính khoa học và nó thực sự dựa trên tính khoa học.
Và như thế, CBSE đã đưa ra được “Những bài học hay nhất” về sản phẩm
công nghệ phần mềm trong suốt 30 năm tiếp theo. Brooks trình bày 2 phương
pháp khả thi giúp giảm mức độ phức tạp của phần mềm đó là “Buy before
Build” và “Reuse before Buy”. Các khái niệm mấu chốt được đưa ra nhằm giúp
giảm được chi phí trong công nghệ phát triển phần mềm.
Trong hội nghị thảo luận năm 1968, NATO đã tham gia tranh luận về thuật
ngữ khủng hoảng phần mềm. Thêm nhiều thuật ngữ khó hiểu như kẽ hở phần
mềm, … các thuật ngữ này dần dần được làm rõ khi trong quá trình phát triển
công nghệ phần mềm. Theo David và Fraser phát biểu năm 1968, “ Kẽ hở được
phát hiện tại thời điểm khi mà hậu quả việc hỏng hóc phần mềm tăng theo mọi
mức độ nghiêm trọng”. Để phát triển phần mềm trên cơ sở cấu phần chúng ta
phải học cách xây dựng các cấu phần đó dựa vào các yêu cầu, hay dựa trên việc
thiết kế các module thành phần hay các thiết kế trực tiếp các cấu phần. Các
khách hàng đặt hàng (các cấu phần) và việc tích hợp các cấu phần cung cấp bởi
nhà sản xuất sẽ đảm bảo rằng nó đáp ứng được yêu cầu khách hàng với các
mong muốn họ đưa ra.
Khái niệm về mô hình của cấu phần phần mềm được phát triển rộng rãi bởi
BradCox và đặt nền móng cho việc tạo một hạ tầng phát triển các cấu phần này
dựa trên ngôn ngữ lập trình C (Nội dung được đúc kết trong cuốn sách ObjectOriented Programming – An Evolution Approach 1986)
IBM tiên phong mở ra lối nghiên cứu về Mô hình đối tượng hệ thống ngay
đầu những năm 1990. Một số các đóng góp được ứng dụng trong phần mềm cấu
phần đó là OLE và COM. Mô hình cấu phần phần mềm vẫn tiếp tục thu được
những thành quả đáng kể.
1.3. Mục tiêu của luận văn
Luận văn này nhằm mục tiêu nghiên cứu khảo sát sơ bộ các kỹ thuật kiểm
thử phần mềm, với giải pháp áp dụng các mô hình UML vào kiểm thử phần
mềm trên cơ sở cấu phần. Từ đó, áp dụng các kết quả nghiên cứu lý thuyết vào
thực nghiệm kiểm thử một thiết kế phần mềm cụ thể mà luận văn đưa ra.
Nội dung nghiên cứu tập trung vào một số vấn đề sau:
1) Tổng quan về các vấn đề cơ bản của kiểm thử phần mềm, các nguyên
tắc kiểm thử. Tổng quan về phát triển phần mềm dựa trên cấu phần, bao gồm
các khái niệm cơ bản như cấu phần, chuẩn tương tác, chuẩn kết hợp, cài đặt
mô hình cấu phần, các mô hình cấu phần - dịch vụ cấu phần, tiếp cận UML,
và vai trò của UML đặc tả thiết kế, ứng dụng vào kiểm thử.
2) Nghiên cứu phương pháp luận kiểm thử phần mềm trên cơ sở cấu
phần, bao gồm mô hình kiểm thử đối với phần mềm dựa trên cấu phần, kiểm
thử tích hợp trên cơ sở các mô hình UML đối với phần mềm phát triển trên
cấu phần. Xây dựng các biểu đồ UML hỗ trợ ca kiểm thử tích hợp.
3) Phát triển thực nghiệm kiểm thử phần mềm trên cơ sở sử dụng các
cấu phần có sẵn dựa trên bài toán ứng dụng được đưa ra; xây dựng các pha
phân tích, thiết kế và kiểm thử.
Chương 2: Một số khái niệm cơ bản
Lập trình hướng cấu phần (COP – Component oriented programming) và
công nghệ phần mềm trên cơ sở cấu phần (CBSE – Component based software
engineering) đôi khi có thể hiểu là một. Tuy nhiên, CBSE là thuật ngữ rộng hơn,
và COP chỉ là một phần trong đó.
CBSE = COA + COD + COP + COM
Trong đó COA (component oriented analysis), COD (Component oriented
design) và COM (Component oriented management) thể hiện các thuật ngữ về
phân tích hướng cấu phần, thiết kế hướng cấu phần và quản lý hướng cấu phần.
Mục tiêu của CBSE là phát triển phần mềm một cách nhanh chóng, và giảm chi
phí bằng cách xây dựng các hệ thống thông qua việc thu thập các cấu phần có
sẵn. Thiết kế, phát triển, và duy trì các cấu phần nhằm mục đích sử dụng lại là
một quy trình rất phức tạp, với các yêu cầu ở mức cao không chỉ đáp ứng được
tính chức năng và mềm dẻo cấu phần mà còn đáp ứng việc phát triển phần mềm
một cách có tổ chức. CBSE bao gồm rất nhiều các nguyên tắc công nghệ phần
mềm và các kỹ thuật khác nhau.
Trong công nghệ phần mềm truyền thống, quy trình phát triển phần mềm bao
gồm các hoạt động hay các trạng thái tuần tự, cách đặt tên, phân tích, thiết kế,
ngôn ngữ lập trình, kiểm thử, và tích hợp. Trong CBSE, các giai đoạn phát triển
chính vẫn tuân thủ theo các bước thực hiện như quy trình phát triển truyền
thống, và bổ sung thêm bước tập hợp và lắp ghép các cấu phần. Ta có thể nhận
thấy rằng, điểm nổi bật trong CBSE so với công nghệ phần mềm truyền thống
chính nằm ở hướng thiết kế, bước thu thập và lắp ghép các cấu phần vào việc
xây dựng một hệ thống hoàn thiện.
Dưới cách nhìn về các cấu phần, có 2 loại hoạt động căn bản đó là: Phát triển
cấu phần để sử dụng lại (DF – Developing for reuse) và sử dụng lại các cấu phần
đã có sẵn (DW - Developing with reuse). Với việc phát triển cấu phần để sử
dụng lại có thể được tổ chức theo cách tiếp cận công nghệ phần mềm truyền
thống, nhấn mạnh vào các chuẩn cấu phần. Mỗi cấu phần cung cấp 2 loại giao
diện: (1) giao diện cung ứng – định nghĩa các dịch vụ quảng bá cấu phần này sẽ
cung ứng và (2) giao diện yêu cầu – đặc tả các dịch vụ mà cấu phần cần đến để
thể hiện khả năng làm việc.
Theo các nhìn hướng quy trình công nghệ, có 5 cách định nghĩa khác nhau
trong CBSE:
1. Đặc tả cấu phần (Component specification): Nó thể hiện đơn vị đặc tả của
phần mềm, mô tả hành vi của tập các đối tượng cấu phần và định nghĩa một đơn
vị thực hiện. Hành vi được định nghĩa dưới dạng tập các giao diện. Một đặc tả
cấu phần được nhận diện dưới dạng một thực thi cấu phần.
2. Giao diện cấu phần (Component interface): Giao diện thể hiện định nghĩa
tập các hành vi có thể được cung ứng thông qua một đối tượng cấu phần.
3. Sự thực thi cấu phần (Component implementation): Là một sự nhận diện
của đặc tả cấu phần, có khả năng triển khai độc lập. Điều này nghĩa là nó có thể
được cài đặt và thay thế một cách độc lập các cấu phần khác. Như thế không có
nghĩa là nó độc lập với các cấu phần khác – nó có rất nhiều sự phụ thuộc.
4. Cấu phần được cài đặt (Installed component): Là sự sao chép của
một thực thi cấu phần dưới hình thức cài đặt (hay triển khai). Một sự
thực thi cấu phần được triển khai bằng cách đăng ký nó với môi trường
khi chạy thật. Môi trường chạy thật định nghĩa khả năng của cấu phần
được cài đặt nhằm tạo một thể hiện khi thực hiện bước vận hành nó.
5. Đối tượng cấu phần (Component object): Một đối tượng cấu phần là một
thể hiện của cấu phần được cài đặt. Khái niệm này khá giống với khái niệm
trong lập trình hướng đối tượng, một đối tượng cấu phần trong lập trình hướng
cấu phần là một đối tượng có dữ liệu riêng và định nghĩa duy nhất, nó thực hiện
hành vi thực thi xác định. Một cấu phần cài đặt có thể có các đối tượng cấu
phần đa nhiệm hay đơn nhiệm.
2.1 Phần mềm sử dụng cấu phần
Để tìm hiểu, nghiên cứu về mục tiêu mà luận văn đã đề ra, trước tiên, ta đi
vào việc tìm hiểu các thuật ngữ cơ bản được sử dụng trong CBSE, ta đi từ các
khái niệm nhỏ nhất, đơn giản nhất về cấu phần.
Một phần tử phần mềm chứa chuỗi các lệnh cấp cao, các tính toán được thực
hiện bởi máy tính. Phần tử phần mềm là thực thi nếu: (1) máy tính trực tiếp thực
thi các lệnh hay (2) có một bộ thông dịch chạy trên máy tính dịch các câu lệnh
sang dạng máy thực thi được.
Mã nguồn phần mềm là tập các file máy có thể đọc được, chứa các câu lệnh
chương trình được viết ứng với một ngôn ngữ lập trình. Các câu lệnh này được
dịch thành các câu lệnh thực thi được hay nhờ vào bộ biên dịch hay bộ thông
dịch.
Một cấu phần phần mềm là một tập các phần tử phần mềm được lập trình.
Cấu phần đó được cài đặt, và đưa vào sử dụng. Sự khác nhau giữa phần tử phần
mềm và cấu phần phần mềm được thể hiện ở cách sử dụng. Phần mềm bao gồm
rất nhiều yếu tố trừu tượng, các đặc trưng chất lượng. Đó là thước đo để đánh
giá một cấu phần hay một quy trình có đáp ứng yêu cầu đặc tả hay không (theo
chuẩn IEEE 610.12 – 1990). Thuật ngữ phần tử được đặt trong phạm vi mô tả về
cấu phần phần mềm như sau:
Một cấu phần phần mềm là một phần tử phần mềm tuân theo một mô hình
cấu phần và có thể triển khai độc lập, được kết hợp mà không cần sửa đổi
theo một chuẩn kết hợp.
Một mô hình cấu phần định nghĩa các đặc tả tương tác và các chuẩn kết
hợp.
Một cài đặt mô hình cấu phần là một tập hợp các phần tử phần mềm xác
định cần có để hỗ trợ việc thực thi của các cấu phần tuân theo mô hình.
Hạ tầng của cấu phần phần mềm, là một tập hợp các cấu phần phần mềm
tương tác được thiết kế để đảm bảo rằng hệ thống phần mềm được xây
dựng sử dụng các cấu phần và giao diện này sẽ thỏa mãn các đặc tả hiệu
năng đã định nghĩa.
Các định nghĩa này thể hiện mối quan hệ quan trọng giữa hạ tầng của cấu
phần phần mềm, các cấu phần phần mềm và mô hình cấu phần.
Khả năng của cấu phần và cách dùng nó được đặc tả bởi giao diện. Giao diện
là một sự trừu tượng hóa dịch vụ, nó định nghĩa các thao tác mà dịch vụ hỗ trợ,
nó độc lập với bất kỳ sự thực thi đặc biệt nào. Một cấu phần phần mềm giao tiếp
và tương tác với thế giới bên ngoài thông qua giao diện của nó, với tài liệu đặc
tả giao diện và tương tác sẽ cho chúng ta biết được nó làm gì (what), nội dung
của mã thực thi trong cấu phần, quy trình xử lý (how) được ẩn hoàn toàn và
người sử dụng cấu phần không phải quan tâm tới việc nó làm như thế nào.
2.1.1 Chuẩn tương tác [3]
Chuẩn giao diện là các yêu cầu bắt buộc phải sử dụng và tuân theo đối với
cấu phần phần mềm để các phần tử phần mềm tương tác trực tiếp với các phần
tử khác. Chuẩn giao diện khai báo một giao diện có thể chứa cái gì.
Kết luận
Hiện nay, phát triển phần mềm hướng cấu phần (CBSE) đang thu hút các
nghiên cứu từ rất nhiều góc độ khác nhau như kỹ thuật xây dựng, đánh giá, kiểm
định phần mềm, quy trình khảo sát, phân tích thiết kế, quản lý.
Phát triển phần mềm hướng cấu phần (CBSE) là một công nghệ quan trọng
cho phép xây dựng những hệ thống phần mềm chất lượng cao, mở và các hệ
thống phần mềm lớn bằng cách tích hợp các cấu phần phần mềm đã tồn tại trước
đó. CBSE đã giảm bớt được giá thành phát triển phần mềm, xây dựng các hệ
thống một cách nhanh chóng, giảm bớt được việc bảo trì theo kiểu xoắn ốc liên
quan đến việc hỗ trợ và nâng cấp cho các hệ thống lớn. CBSE đang thu hút các
nghiên cứu rất nhiều từ góc độ các kỹ thuật xây dựng, đánh giá phần mềm cho
tới quy trình khảo sát, phân tích thiết kế, quản lý, đánh giá. Một trong những
hướng nghiên cứu hiện nay là thay đổi cách phát triển của các hệ thống phần
mềm: chuyển từ việc lập trình tạo ra các sản phẩm sang việc biên soạn các hệ
thống phần mềm, tức là chỉ tập trung vào việc lựa chọn và tích hợp các cấu phần
có sẵn để xây dựng nên các hệ thống. Trong phương pháp phát triển này việc
tìm kiếm các cấu phần và lựa chọn tích hợp các dịch vụ của các cấu phần đang
là hai vấn đề đang tập trung nghiên cứu.
UML hỗ trợ phát triển phần mềm hướng cấu phần đã đem đến cho các đối
tượng phát triển hệ thống cái nhìn rõ ràng về hệ thống xây dựng, giúp cho người
phân tích thiết kế thấy được các yếu tố ảnh hưởng trực tiếp tới hệ thống. Trên cơ
sở đó, cán bộ phân tích hệ thống xác định được các cấu phần cần tích hợp với hệ
thống.
Tham gia vào quy trình phát triển phần mềm luôn có sự góp mặt của bộ phận
kiểm định phần mềm. Với phương pháp phát triển phần mềm cấu phần trên, kết
hợp với bước kiểm định sẽ làm giảm thiểu một cách tối đa các lỗi trong phần
mềm. Tuy thế, Mặt khác, ta cũng không thể khẳng định rằng khi phát triển phần
mềm trên cơ sở cấu phần, với sự tham gia của UML trong thiết kế thì phần mềm
làm ra sẽ không còn lỗi.
Tóm tắt kết quả chính đã đạt được
Qua thời gian nghiên cứu tìm hiểu về phần mềm xây dựng trên cơ sở cấu
phần, áp dụng UML trong CBSE, kiểm thử phần mềm, tui đã áp dụng nghiên
cứu kiểm thử phần mềm vào phần mềm hướng cấu phần và đã đạt được những
kết quả nhất định. Một trong những công việc quan trọng của kỹ thuật kiểm thử
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
You must be registered for see links
Last edited by a moderator: