Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Báo cáo thực tập tốt nghiệp đại học
1 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Lời nói đầu
Để có được thành quả học tập như n...
Báo cáo thực tập tốt nghiệp đại học
2 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Mục lục
Table of Contents
Lời nói đầu ...........
Báo cáo thực tập tốt nghiệp đại học
3 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
2.4.Ưu điểm / Nhược điểm của White Box Testing...
Báo cáo thực tập tốt nghiệp đại học
4 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
2.1.Các phần mềm thương mại......................
Báo cáo thực tập tốt nghiệp đại học
5 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Lí do lựa chọn đề tài
Ngày nay công nghệ thông...
Báo cáo thực tập tốt nghiệp đại học
6 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Chương I Khái quát về phần mềm và kiểm thử phầ...
Báo cáo thực tập tốt nghiệp đại học
7 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
-Phần mềm ứng dụng: để người sử dụng có thể ho...
Báo cáo thực tập tốt nghiệp đại học
8 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Qui trình có thể hiểu là phương pháp thực hiện...
Báo cáo thực tập tốt nghiệp đại học
9 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
• Mô hình mẫu (Prototype)
• Mô hình tiến hóa (...
Báo cáo thực tập tốt nghiệp đại học
10 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Hình 1. Kiểm thử thông qua các framework xUni...
Báo cáo thực tập tốt nghiệp đại học
11 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Như với thử nghiệm truyền thống, hệ thống càn...
Báo cáo thực tập tốt nghiệp đại học
12 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Phát triển phần mềm và kiểm thử phần mềm có m...
Báo cáo thực tập tốt nghiệp đại học
13 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
2. Tổng quan về kiểm thử phần mềm
2.1.Khái ni...
Báo cáo thực tập tốt nghiệp đại học
14 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Trong game Monopoly, người chơi
có thể được c...
Báo cáo thực tập tốt nghiệp đại học
15 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
phẩm phần mềm. Việc kiểm thử cũng vì thế phải...
Báo cáo thực tập tốt nghiệp đại học
16 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
+ Sai sót do dư thừa: chúng ta đưa một vài th...
Báo cáo thực tập tốt nghiệp đại học
17 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Thêm vào đó, kiểm tra chất lượng phần mềm lại...
Báo cáo thực tập tốt nghiệp đại học
18 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
XIII. Thu thập bảo trì và ghi nhớ báo cáo
Việ...
Báo cáo thực tập tốt nghiệp đại học
19 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
-Kiểm thử trên Mobile: ngày nay xã hội đang p...
Báo cáo thực tập tốt nghiệp đại học
20 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
1.4.Nguyên lý thực hiện của BBT
Kiểm thử hộp ...
Báo cáo thực tập tốt nghiệp đại học
21 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Các bước : 3 bước
o Đối với dữ liệu đầu vào ,...
Báo cáo thực tập tốt nghiệp đại học
22 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Cơ sở : lỗi thường xuất hiện gần các giá trị ...
Báo cáo thực tập tốt nghiệp đại học
23 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
3, 4, 5, 6 Bốn giá trị
3 Chỉ 1 giá trị
Dữ liệ...
Báo cáo thực tập tốt nghiệp đại học
24 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
 B2: Tính tổng số kết hợp giữa các cause
o T...
Báo cáo thực tập tốt nghiệp đại học
25 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
o Ghép các cột với lội dung giống nhau thành ...
Báo cáo thực tập tốt nghiệp đại học
26 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
o B1: Phân chia hệ thống thành vùng hoạt động...
Báo cáo thực tập tốt nghiệp đại học
27 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
-CEG #3 : Nếu tuổi từ 64 trở lên , phí bảo hi...
Báo cáo thực tập tốt nghiệp đại học
28 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
 B5: Thiết lập danh sách các test case từ bả...
Báo cáo thực tập tốt nghiệp đại học
29 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
 Kiểm thử dựa trên yêu cầu - Specification-b...
Báo cáo thực tập tốt nghiệp đại học
30 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
của chương trình. Kiểm thử viên sẽ truy cập v...
Báo cáo thực tập tốt nghiệp đại học
31 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
. Xét ví dụ với đoạn mã lệnh JAVA sau:
public...
Báo cáo thực tập tốt nghiệp đại học
32 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Hình 9: Các trường hợp kiểm thử đường dẫn
Tro...
Báo cáo thực tập tốt nghiệp đại học
33 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
2. A=2, B=1, X=1
bao phủ tất cả các kết quả đ...
Báo cáo thực tập tốt nghiệp đại học
34 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
- Các bước cần kiểm tra cho vòng lặp nối tiếp...
Báo cáo thực tập tốt nghiệp đại học
35 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
 Chính xác: “Việc thực hiện một white box te...
Báo cáo thực tập tốt nghiệp đại học
36 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Chương III Các cấp độ hay giai đoạn kiểm thử ...
Báo cáo thực tập tốt nghiệp đại học
37 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Giá thành sẽ càng bị đội lên nếu không phát h...
Báo cáo thực tập tốt nghiệp đại học
38 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
 Kiểm tra cấu trúc (structure): Tương tự Whi...
Báo cáo thực tập tốt nghiệp đại học
39 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
2.2.Tích hợp từ dưới lên
Kiểm thử tích hợp từ...
Báo cáo thực tập tốt nghiệp đại học
40 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
Nhược điểm chính của kiểm thử tích hợp từ dướ...
Báo cáo thực tập tốt nghiệp đại học
41 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
- Có các yêu cầu thực hiện không rõ ràng.
Các...
Báo cáo thực tập tốt nghiệp đại học
42 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
cho việc phát hiện lỗi giao tiếp với các phần...
Báo cáo thực tập tốt nghiệp đại học
43 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
hoặc phản hồi, và lên kế hoạch sửa chữa. Với ...
Báo cáo thực tập tốt nghiệp đại học
44 | P a g e
NguyễnVươngQuyền,lớpCNPMK53
dữ liệu vào của người dùng. Các loại hoạt đọn...
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Thực tập kiểm thử phần mềm
Upcoming SlideShare
Loading in …5
×

Thực tập kiểm thử phần mềm

10,388 views

Published on

Thực tập kiểm thử phần mềm

Published in: Education
  • Login to see the comments

Thực tập kiểm thử phần mềm

  1. 1. Báo cáo thực tập tốt nghiệp đại học 1 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Lời nói đầu Để có được thành quả học tập như ngày hôm nay, ngoài sự nỗ lực phấn đấu không ngừng của bản thân thì một phần không nhỏ đóng góp nên thành công ấy là nhờ sự hướng dẫn, dạy dỗ của các thầy cô trong viện CNTT&TT nói riêng và trong trường ĐHBK Hà Nội nói chung trong suốt gần năm năm em học tập và nghiên cứu tại ĐHBK Hà Nội. Em xin gửi lời cảm ơn chân thành đến thầy Ths. Thạc Bình Cường – giảng viên bộ môn Công nghệ phần mềm, Viện Công nghệ thông tin và Truyền thông, trường Đại Học Bách Khoa Hà Nội đã định hướng, hướng dẫn và chỉ bảo tận tình trong quá trình em làm báo cáo thực tập tốt nghiệp này. Em xin chúc thầy và gia đình luôn luôn mạnh khỏe và hạnh phúc. Cuối cùng, em xin được cảm ơn đến gia đình, ta bè đã động viên, chăm sóc, đóng góp ý kiến và giúp đỡ trong quá trình học tập, nghiên cứu và hoàn thành báo cáo thực tập tốt nghiệp này. Tuy nhiên, do thời gian và trình độ có hạn nên báo cáo không thể tránh khỏi những thiếu sót. Chính vì vậy, em rất mong có được sự góp ý từ các thầy cô giáo và toàn thể các ta. Sinh viên thực hiện Nguyễn Vương Quyền
  2. 2. Báo cáo thực tập tốt nghiệp đại học 2 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Mục lục Table of Contents Lời nói đầu ...................................................................................................................................... 1 Mục lục............................................................................................................................................ 2 Lí do lựa chọn đề tài........................................................................................................................ 5 Chương I Khái quát về phần mềm và kiểm thử phần mềm.............................................................. 6 1.Tổng quan về phần mềm........................................................................................................... 6 1.1. Định nghĩa............................................................................................................................6 1.2.Phân loại phần mềm...............................................................................................................6 1.3. Quy trình phát triển phần mềm...............................................................................................7 2. Tổng quan về kiểm thử phần mềm......................................................................................... 13 2.1.Khái niệm ...........................................................................................................................13 2.2.Vai trò của kiểm thử phần mềm ............................................................................................14 2.3.Các thuật ngữ chính sử dụng trong kiểm thử phần mềm..........................................................15 2.4.Chất lượng phần mềm và đảm bảo chất lượng phần mềm .......................................................16 2.5.Các kĩ thuật kiểm thử phần mềm...........................................................................................18 2.6.Các giai đoạn hay cấp độ kiểm thử phần mềm........................................................................18 2.7. Một số loại hình kiểm thử phổ biến ......................................................................................18 Chương II Các kĩ thuật cơ bản kiểm thử phần mềm...................................................................... 19 1.Kiểm thử hộp đen (Black Box Testing -BBT)......................................................................... 19 1.1.Định nghĩa ..........................................................................................................................19 1.2.Các phương pháp kiểm thử hộp đen ......................................................................................19 1.3.Đặc điểm BBT.....................................................................................................................19 1.4.Nguyên lý thực hiện của BBT...............................................................................................20 1.5.Các trường hợp ứng dụng .....................................................................................................20 1.6.Ưu điểm/ Nhược điểm của BBT............................................................................................29 2.Kiểm thử hộp trắng (White Box Testing - WBT)..................................................................... 29 2.1.Định nghĩa ..........................................................................................................................29 2.2.Đặc điểm của WBT..............................................................................................................30 2.3.Các kĩ thuật kiểm thử của WBT............................................................................................30
  3. 3. Báo cáo thực tập tốt nghiệp đại học 3 | P a g e NguyễnVươngQuyền,lớpCNPMK53 2.4.Ưu điểm / Nhược điểm của White Box Testing......................................................................34 3.Kiểm thử hộp xám (Gray Box Testing - GBT)......................................................................... 35 3.1.Định nghĩa ..........................................................................................................................35 3.2.Ứng dụng ............................................................................................................................35 3.3.Ưu điểm và Nhược điểm ......................................................................................................35 Chương III Các cấp độ hay giai đoạn kiểm thử phần mềm............................................................ 36 1. Kiểm thử đơn vị (Unit Testing)............................................................................................... 36 2. Kiểm thử tích hợp (Integration Test)...................................................................................... 37 2.1.Tích hợp từ trên xuống.........................................................................................................38 2.2.Tích hợp từ dưới lên.............................................................................................................39 3. Kiểm thử hồi quy.................................................................................................................... 41 4. Kiểm thử hệ thống (System Testing)....................................................................................... 41 5. Kiểm thử chấp nhận (Acceptance Testing)............................................................................. 42 Chương IVMột số loại hình kiểm thử hiện nay............................................................................. 43 1.Tổng quan về kiểm thử Website .............................................................................................. 43 1.1.Giới thiệu............................................................................................................................43 1.2.Khái niệm ...........................................................................................................................45 1.3.Mục đích của kiểm thử Website............................................................................................45 1.4.So sánh kiểm thử web với kiểm thử phần mềm truyền thống (trên Desktop).............................46 1.5.Các phương pháp testing ......................................................................................................49 2.Khái quát về kiểm thử trên SmartPhone................................................................................. 50 2.1.Giới thiệu............................................................................................................................50 2.2. Các yếu tố ảnh hưởng đến hoạt động của phần mềm trên SmartPhone ....................................51 2.3.Lựa chọn thiết bị SmartPhone để Testing...............................................................................51 2.4. Kiểm thử tự động................................................................................................................51 Chương V các công cụ kiểm thử tự động và ứng dụng................................................................... 53 1. Tổng quan về kiểm thử tự động.............................................................................................. 53 1.1. Khái niệm...........................................................................................................................53 1.2. Quy trình kiểm thử tự động..................................................................................................53 1.3. Ưu và nhược điểm...............................................................................................................54 2.Các công cụ hỗ trợ kiểm thử tự động....................................................................................... 55
  4. 4. Báo cáo thực tập tốt nghiệp đại học 4 | P a g e NguyễnVươngQuyền,lớpCNPMK53 2.1.Các phần mềm thương mại...................................................................................................55 2.2.Các công cụ mã nguồn mở....................................................................................................57 3.Demo JUnit(Java) – NUnit(C#)............................................................................................... 60 3.1 Thiết kế testcase trong JUnit (trong Java) ..............................................................................60 3.2 Thiết kế các testcase trong NUnit (trong C#)..........................................................................62 Kết luận......................................................................................................................................... 65 Những vấn đề đã đạt được ......................................................................................................... 65 Hướng phát triển của đề tài trong tương lai............................................................................... 65 Tài liệu tham khảo......................................................................................................................... 65
  5. 5. Báo cáo thực tập tốt nghiệp đại học 5 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Lí do lựa chọn đề tài Ngày nay công nghệ thông tin đang ngày càng phát triển nhanh chóng, kéo theo đó là hệ thống mạng và các phần mềm cũng gia tăng cả về số lượng theo quy mô rộng và cả về chất lượng phần mềm theo chiều sâu. Nhưng cũng từ đó đã nảy sinh ra nhiều vấn đề về lỗi hỏng hóc phần mềm không đáng có gây ra các ảnh hưởng nghiêm trọng đến xã hội, kinh tế,...Những lỗi này có thể do tự bản thân phần mềm bị hỏng do không được kiểm duyệt kĩ lưỡng trước khi đưa cho người dùng cuối hay cũng có thể do có người cố tình phá hoại nhằm đánh cắp thông tin cá nhân như mã số tài khoản ngân hàng, số điện thoại, danh bạ, tin nhắn,...Những vấn đề nan giải và cấp thiết này càng có xu hướng mở rộng trong các năm gần đây, điển hình như sự cố máy tính Y2K năm 2000 làm tê liệt nhiều hệ thống máy tính lớn hay như càng có nhiều loại virus phá hoại mới xuất hiện, tấn công vào các lỗ hổng bảo mật phần mềm làm tê liệt nhiều hệ thống phần mềm và phần cứng. Từ đây ta dễ dàng nhận ra là mặc dù phần mềm phát triển ngày càng phức tạp nhưng vấn đề chất lượng vẫn là một dấu hỏi lớn cần xem xét cẩn thận. Do đó yêu cầu đặt ra là cần có công tác kiểm thử phần mềm thật kĩ lưỡng nhằm ngăn chặn các lỗi hay hỏng hóc còn tiềm tàng bên trong phần mềm mà ta chưa kịp nhận ra. Tuy nhiên vì phần mềm ngày càng lớn, hàng nghìn module, có thể do cả một công ty hàng nghìn người phát triển vì vậy để kiểm thử được một phần mềm lớn như vậy sẽ tốn rất nhiều công sức và thời gian nếu làm thủ công, chưa kể đến chất lượng kiểm thử sẽ không cao va thật chính xác phù hợp cho yêu cầu. Theo nhiều tính toán thì công việc kiểm thử đóng vai trò hết sức quan trọng trong quy trình phát triển phần mềm, nó đóng góp tới 40% tổng toàn bộ chi phí cho việc sản xuất phần mềm. Vì vậy cần có các hệ thống kiểm thử phần mềm một cách tự động cho phép ta thực hiện được các công việc một cách nhanh chóng và độ an toàn, chính xác cao nhất có thể. Và đó chính là lí do em lựa chọn đề tài này để nghiên cứu, tìm hiểu và đề ra các giải pháp mới để cải tiến các quy trình kiểm thử như hiện nay sao cho có năng suất cao nhất.
  6. 6. Báo cáo thực tập tốt nghiệp đại học 6 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Chương I Khái quát về phần mềm và kiểm thử phần mềm 1.Tổng quan về phần mềm 1.1. Định nghĩa Có nhiều định nghĩa về phần mềm, sau đây là một vài định nghĩa tiêu biểu -Theo Wikipedia thì Phần mềm máy tính (tiếng Anh: Computer Software) hay gọi tắt là Phần mềm (Software) là một tập hợp những câu lệnh hoặc chỉ thị (Instruction) được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải quyết một vấn đề cụ thể nào đó. -Phần mềm là tập hợp của tất cả các câu lệnh do các nhà lập trình viết ra để hướng máy tính làm một số việc cụ thể nào đó ,không như các thiết bị điện tử khác, máy vi tính mà không có phần mềm thì nó không hoạt động gì cả . Để có được phần mềm, các nhà lập trình phải sử dụng các ngôn ngữ lập trình để viết, ngôn ngữ lập trình là ngôn ngữ trung gian giữa ngôn ngữ giao tiếp của con người với ngôn ngữ máy, ngôn ngữ càng gần với ngôn ngữ con người thì gọi là ngôn ngữ bậc cao, càng gần ngôn ngữ máy gọi là ngôn ngữ bậc thấp .Sử dụng ngôn ngữ lập trình để điều khiển máy tính. 1.2.Phân loại phần mềm Có nhiều cách thức phân loại phần mềm, song có thể chia thành hai loại chính sau: 1.2.1.Theo phương thức hoạt động -Phần mềm hệ thống dùng để vận hành máy tính và các phần cứng máy tính, ví dụ như các hệ điều hành máy tính Windows, Linux, Unix, các thư viện động (còn gọi là thư viện liên kết động; tiếng Anh: dynamic linked library - DLL) của hệ điều hành, các trình điều khiển (driver), phần sụn (firmware) và BIOS. Đây là các loại phần mềm mà hệ điều hành liên lạc với chúng để điều khiển và quản lý các thiết bị phần cứng.
  7. 7. Báo cáo thực tập tốt nghiệp đại học 7 | P a g e NguyễnVươngQuyền,lớpCNPMK53 -Phần mềm ứng dụng: để người sử dụng có thể hoàn thành một hay nhiều công việc nào đó, ví dụ như các phần mềm văn phòng (Microsoft Office, OpenOffice), phần mềm doanh nghiệp, phần mềm quản lý nguồn nhân lực, phần mềm giáo dục, cơ sở dữ liệu, phần mềm trò chơi, chương trình tiện ích, hay các loại phần mềm độc hại. -Các phần mềm chuyển dịch mã bao gồm trình biên dịch và trình thông dịch: các loại chương trình này sẽ đọc các câu lệnh từ mã nguồn được viết bởi các lập trình viên theo một ngôn ngữ lập trình và dịch nó sang dạng ngôn ngữ máy mà máy tính có thể hiểu đưọc, hay dịch nó sang một dạng khác như là tập tin đối tượng (object file) và các tập tin thư viện (library file) mà các phần mềm khác (như hệ điều hành chẳng hạn) có thể hiểu để vận hành máy tính thực thi các lệnh. -Các nền tảng công nghệ như .NET, 1C:DOANH NGHIỆP... 1.2.2.Theo khả năng ứng dụng - Những phần mềm không phụ thuộc, nó có thể được bán cho bất kỳ khách hàng nào trên thị trường tự do. Ví dụ: phần mềm về cơ sở dữ liệu như Oracle, đồ họa như Photoshop, Corel Draw, soạn thảo và xử lý văn bản, bảng tính,... Ưu điểm: Thông thường đây là những phần mềm có khả năng ứng dụng rộng rãi cho nhiều nhóm người sử dụng. Khuyết điểm: Thiếu tính uyển chuyển, tùy biến. - Những phần mềm được viết theo đơn đặt hàng hay hợp đồng của một khách hàng cụ thể nào đó (một công ty, bệnh viện, trường học,...). Ví dụ: phần mềm điều khiển, phần mềm hỗ trợ bán hàng,... Ưu điểm: Có tính uyển chuyển, tùy biến cao để đáp ứng được nhu cầu của một nhóm người sử dụng nào đó. Khuyết điểm: Thông thường đây là những phần mềm ứng dụng chuyên ngành hẹp. 1.3. Quy trình phát triển phần mềm 1.3.1.Tổng quan Cũng như mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án.Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao, điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm củng cố và phát triển cùng với nền công nghiệp phần mềm đầy cạnh tranh.Bài viết phần nào giúp ta quyết định lựa chọn mô hình thích hợp khi xây dựng qui trình phát triển phần mềm chung cho cấp tổ chức hay cấp dự án. Qui trình là gì?
  8. 8. Báo cáo thực tập tốt nghiệp đại học 8 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm. Tương tự như vậy, SEP chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm. Thông thường một qui trình bao gồm những yếu tố cơ bản sau: • Thủ tục (Procedures) • Hướng dẫn công việc (Activity Guidelines) • Biểu mẫu (Forms/templates) • Danh sách kiểm định (Checklists) • Công cụ hỗ trợ (Tools) Với các nhóm công việc chính: • Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng. • Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn các yêu cầu được chỉ ra trong “Đặc tả yêu cầu”. • Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”. • Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng. Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng. 1.3.2.Các mô hình SEP Các mô hình SEP còn được gọi là chu trình hay vòng đời phần mềm (SLC - Software Life Cycle). SLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có khá nhiều mô hình SLC khác nhau, trong đó một số được ứng dụng khá phổ biến trên thế giới: Các mô hình một phiên bản (Single-version models) • Mô hình Waterfall (Waterfall model) • Mô hình chữ V (V-model) • Các mô hình nhiều phiên bản (Multi-version models)
  9. 9. Báo cáo thực tập tốt nghiệp đại học 9 | P a g e NguyễnVươngQuyền,lớpCNPMK53 • Mô hình mẫu (Prototype) • Mô hình tiến hóa (Evolutionary) • Mô hình lặp và tăng dần (Iterative and Incremental) • Mô hình phát triển ứng dụng nhanh (RAD) • Mô hình xoắn ốc(Spiral) • Mô hình phát triển dựa trên kiểm thử (Test Driven Development-TDD) 1.3.3. Mô hình phát triển dựa trên kiểm thử (TDD) a) Định nghĩa: Phát triển dựa trên kiểm thử (Test Driven Development-TDD) là một phương pháp tiếp cận cải tiến để phát triển phần mềm trong đó kết hợp phương pháp Phát triển kiểm thử trước (Test First Development) và phương pháp Điều chỉnh lại mã nguồn (Refactoring). Mục tiêu quan trọng nhất của TDD là gì? Có quan điểm cho rằng mục tiêu của TDD là đặc tả (specification) chứ không phải là xác nhận tính đúng đắn (validation). Nói cách khác, đó là một cách để nghĩ về thiết kế của ta trước khi viết mã nguồn cho chức năng. Một quan điểm khác lại cho rằng TDD là một kỹ thuật lập trình. Nhưng nhìn chung, mục tiêu của TDD là viết mã nguồn sáng sủa, rõ ràng và có thể chạy được. b) Các cải tiển của TDD -TDD hoàn toàn thay đổi cách phát triển truyền thống. Khi ta bắt đầu thực hiện một tính năng mới, câu hỏi đầu tiên đặt ra là liệu thiết kế hiện tại có phải là thiết kế tốt nhất cho phép ta thực hiện các chức năng hay không. Nếu có, ta tiến hành thông qua một phương pháp Phát triển kiểm thử trước TFD. Nếu không, ta điều chỉnh lại nó một cách cục bộ để thay đổi riêng phần thiết kế bị ảnh hưởng bởi tính năng mới, cho phép ta dễ dàng bổ thêm các tính năng có thể. Kết quả là chất lượng thiết kế của ta sẽ luôn luôn được nâng cao, do đó sẽ thuận lợi hơn khi làm việc với nó trong tương lai. -Một giả định cơ bản của TDD là ta có sẵn một nền tảng (framework) cho kiểm thử mức đơn vị (unit-test). Những lập trình viên phần mềm theo phương pháp Agile thường sử dụng các công cụ mã nguồn mở thuộc họ xUnit, như JUnit hay VBUnit, mặc dù các công cụ thương mại cũng là những lựa chọn khả dĩ. Nếu không có những công cụ như vậy thì TDD hầu như không thể thực hiện được. Hình 1 trình bày một sơ đồ trạng thái trên UML thể hiện cách mà mọi người thường làm việc với các công cụ xUnit.
  10. 10. Báo cáo thực tập tốt nghiệp đại học 10 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Hình 1. Kiểm thử thông qua các framework xUnit Hai nguyên tắc đơn giản cho TDD: Trước tiên, ta nên viết mã xử lý nghiệp vụ mới chỉ khi mẫu kiểm thử tự động thực hiện không thành công. Thứ hai, ta nên loại bỏ bất kỳ sự trùng lặp mà ta tìm thấy. Những quy tắc đơn giản: - Ta thiết kế với mã nguồn mà chúng chạy được và tạo ra kết quả phản hồi giữa các quyết định. - Ta viết các mẫu kiểm thử cho riêng ta bởi vì ta không thể chờ đợi 20 lần mỗi ngày một người nào khác viết thay ta. - Môi trường phát triển của ta phải cung cấp được kết quả nhanh với những thay đổi nhỏ (ví dụ như ta cần một trình biên dịch nhanh và chuỗi kiểm thử hồi quy (regression test) - Thiết kế của ta phải bao gồm những thành phần gắn kết, sự phụ thuộc lẫn nhau nhỏ (loosely coupled) để thực hiện các mẫu kiểm thử dễ dàng hơn (điều này cũng làm cho quá trình nâng cấp và bảo trì các hệ thống của ta dễ dàng hơn). c) TDD và cách kiểm thử truyền thống TDD là một kỹ thuật thiết kế với một hiệu ứng phụ là việc đảm bảo toàn bộ mã nguồn của ta được thực hiện kiểm thử mức đơn vị. Tuy nhiên, có những điều còn quan trọng hơn cả việc thực hiện kiểm thử. Ta sẽ vẫn cần xem xét các kỹ thuật kiểm thử khác như kiểm thử chấp nhận sản phẩm (acceptance test) hay kiểm thử dò hỏi (investigative test) theo kiểu Agile. Ta có thể thực hiện nhiều những kiểu kiểm thử này trong dự án nếu như ta chọn làm điều đó (và ta nên làm). Với kiểu kiểm thử truyền thống, một mẫu kiểm thử thành công sẽ tìm ra một hoặc nhiều lỗi. Tương tự với TDD, khi một mẫu kiểm thử thất bại thì ta cũng có sự tiến triển bởi vì bây giờ ta biết rằng ta cần phải giải quyết một số vấn đề. Quan trọng hơn, ta có một cách đo rõ ràng về sự thành công khi mẫu kiểm thử không thất bại nữa. TDD tăng niềm tin về hệ thống của ta đáp ứng được các yêu cầu được định nghĩa cho nó, và hệ thống của ta đang hoạt động và do đó ta có thể tiếp tục với một sự tự tin.
  11. 11. Báo cáo thực tập tốt nghiệp đại học 11 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Như với thử nghiệm truyền thống, hệ thống càng có nhiều rủi ro lớn càng cần phải có nhiều mẫu kiểm thử được thực hiện. Với cả hai kiểu kiểm thử truyền thống và TDD ta không phấn đấu cho sự hoàn hảo, thay vào đó ta kiểm thử tầm quan trọng của hệ thống. Một hiệu ứng phụ thú vị của TDD là ta đạt được 100% khi kiểm thử độ phủ mã nguồn (coverage test) - mọi dòng mã đều được kiểm thử - điều mà kiểm thử truyền thống không bảo đảm dù cho nó khuyến khích điều đó. Không có gì ngạc nhiên khi nói rằng TDD là một kỹ thuật đặc tả (specification technique), với một tác dụng phụ có giá trị là nó đem lại kết quả trong việc kiểm thử mã nguồn tốt hơn đáng kể so với các kỹ thuật truyền thống. d) Tại sao nên dùng TDD ? Một lợi thế đáng kể của TDD là nó cho phép ta thực hiện các bước nhỏ khi viết phần mềm.Đây là một thực tế mà người ta đã phát huy trong nhiều năm qua bởi vì nó mang lại hiệu quả nhiều hơn so với cố gắng viết mã trong những bước lớn. Ví dụ, giả sử ta thêm một số mã nguồn cho chức năng mới, biên dịch, và kiểm thử nó. Khả năng rất lớn là các kiểm thử của ta sẽ thất bại bởi những lỗi có trong mã nguồn mới. Sẽ dễ dàng hơn nhiều trong việc tìm kiếm, và sau đó sửa chữa những lỗi đó nếu ta đã viết thêm hai dòng mã mới thay vì hai nghìn dòng. Nhiều người cho rằng các kỹ thuật Agile hoạt động rất ổn với những dự án nhỏ, cần một số ít người trong một vài tháng, nhưng chúng không hoạt động đối với những dự án thực sự lớn hơn. Tuy nhiên, điều đó không hoàn toàn đúng. Người ta đã đưa ra một bản báo cáo rằng làm việc với một hệ thống Smalltalk sử dụng hoàn toàn phương pháp hướng kiểm thử (test-driven) hết 4 năm với chi phí nhân công 40 man-year, ra kết quả gồm 250,000 dòng mã nguồn chức năng và 250,000 dòng mã kiểm thử. Có 4000 mẫu kiểm thử chạy dưới 20 phút, còn với bộ mẫu kiểm thử đầy đủ thì cần chạy vài ngày. Điều đó chứng tỏ rằng TDD vẫn hoạt động tốt với những dự án có kích thước lớn. e) Công cụ: Các công cụ phục vụ cho TDD, thường là các nền tảng cho kiểm thử mã nguồn mức đơn vị (unit test): cppUnit, csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DBUnit, HTMLUnit, HTTPUnit, JMock, JUnit, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, Test::Unit (Ruby), VBUnit, XTUnit. 1.4.Mối quan hệ giữa quy trình phát triển phần mềm và kiểm thử phần mềm
  12. 12. Báo cáo thực tập tốt nghiệp đại học 12 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Phát triển phần mềm và kiểm thử phần mềm có mối quan hệ khăng khít với nhau. Phát triển phần mềm ngay từ những pha đầu tiên như phân tích yêu cầu, phân tích thiết kế hệ thống,... phải được tiến hành kiểm thử một cách độc lập bởi một đội ngũ có kinh nghiệm để nếu có phát hiện ra sai sót thì phải tiến hành sửa chữa kịp thời, nếu càng để về sau mới phát hiện ra lỗi thì chi phí để sửa chữa là vô cùng lớn. Đồ thị dưới đây minh họa cho điều này Nhìn vào mô hình ta cũng có thể dễ dàng nhận thấy là ở những pha đầu tiên của quy trình phát triển phần mềm thì chi phí là nhỏ không đáng kể nhưng càng để về sau thì chi phí tăng lên rất nhiều lần. Vì vậy ta không thể chủ quan mà lơ là việc kiểm thử ngay từ giai đoạn đầu của phát triển phần mềm. Điều này là cần thiết nhất là đối với các dự án phần mềm lớn của các doanh nghiệp ngày nay.
  13. 13. Báo cáo thực tập tốt nghiệp đại học 13 | P a g e NguyễnVươngQuyền,lớpCNPMK53 2. Tổng quan về kiểm thử phần mềm 2.1.Khái niệm Hiện nay Có thể có nhiều cách định nghĩa kiểm thử và sau đây là một số cách định nghĩa chính mà ta sẽ xem xét và thảo luận trong báo cáo thực tập này: Kiểm thử là quá trình vận hành hệ thống hoặc thành phần dưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành phần đó (IEEE) Kiểm thử là quá trình thực thi một chương trình với mục đích tìm ra lỗi (Mayer – The art of software testing) 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 những 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. (Wikipedia) Mỗi cách định nghĩa đều đưa ra các khía cạnh khác trong trong việc tìm hiểu kiểm thử phần mềm. Software testing là một trong những kĩ thuật phần mềm “ xác minh và xác nhận “ (verification and validation hay gọi tắt là V&V). Verification (chữ V đầu tiên) là quá trình đánh giá một hệ thống hoặc thành phần để xác định xem các sản phẩm của một giai đoạn phát triển nhất định đáp ứng các điều kiện áp đặt vào lúc bắt đầu của giai đoạn đó hay không. Các hoạt động Verification bao gồm việc kiểm thử và đánh giá. Ví dụ trong phần mềm chơi game Monopoly, chúng ta có thể xác minh rằng hai người choi không thể sở hữu cùng một nhà. Validationis quá trình đánh giá một hệ thống hoặc một thành phần trong hoặc ở cuối của quá trình phát triển để xác định xem nó đáp ứng yêu cầu quy định Verification Validation Thông qua Verification chúng ta muốn chắc chắn rằng phần mềm có các hành vi đúng như chúng ta mong đợi. Ví dụ: Thông qua Validation chúng ta sẽ xác nhận rằng những nỗi không đúng với yêu cầu của khách hàng sẽ không được thực hiện tiếp theo trong suốt quá trình xây dựng xây dựng phần mềm. Validation luôn luôn liên quan tới việc so sánh với các yêu cầu của khách hàng. Ví dụ khách hàng yêu cầu là làm cho họ game Monopoly
  14. 14. Báo cáo thực tập tốt nghiệp đại học 14 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Trong game Monopoly, người chơi có thể được cộng 200 điểm nếu họ hạ cánh trên sân hoặc đi qua Go nhưng người lập trình lại cài đặt là người chơi phải đi qua Go(?!). nhưng đội ngũ phát triển lại làm đưa cho game Life vì họ nghĩ là game Life hay hơn game Monopoly như yêu cầu ban đầu (?!). 2.2.Vai trò của kiểm thử phần mềm Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta gọi là qui trình phát triển phần mềm, bắt đầu từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩm phần mềm thực thi. Khối lượng công việc trong từng giai đoạn của quá trình sản xuất phần mềm cũng thay đổi theo thời gian. Bảng 1.1 minh họa cụ thể hơn về điều này. Bảng 1.1 - Tỉ lệ công việc của các giai đoạn phát triển phần mềm Như vậy, một sản phẩm phần mềm không chỉ đơn giản là các đoạn mã chương trình mà còn rất nhiều phần ẩn đằng sau nó (Hình 1.1). Vì vậy, việc mắc lỗi không chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công đoạn khác của qui trình phát triển một sản
  15. 15. Báo cáo thực tập tốt nghiệp đại học 15 | P a g e NguyễnVươngQuyền,lớpCNPMK53 phẩm phần mềm. Việc kiểm thử cũng vì thế phải được tiến hành trong tất cả các phần tạo nên một sản phẩm phần mềm 2.3.Các thuật ngữ chính sử dụng trong kiểm thử phần mềm - Error: Là một lỗi lầm trong phần mềm do con người gây ra. Một từ ñồng nghĩa là mistake, là một sự nhầm lẫn hay một sự hiểu sai trong quá trình phát triển phần mềm của con người. Khi lập trình viên gây ra lỗi trong quá trình viết mã thì chúng ta gọi lỗi này là bugs. -Sai sót (Fault): Xuất hiện trong phần mềm nhưlà kết quảcủa error. Có thể phân loại nhưsau:
  16. 16. Báo cáo thực tập tốt nghiệp đại học 16 | P a g e NguyễnVươngQuyền,lớpCNPMK53 + Sai sót do dư thừa: chúng ta đưa một vài thứ không chính xác vào mô tảyêu cầu phần mềm. + Sai sót do bỏsót: Người thiết kế có thể gây ra sai sót do bỏsót, kết quả là thiếu một số phần đáng ra phải có trong mô tả yêu cầu phần mềm. -Hỏng hóc (Failture): Là kết quả của một lỗi xuất hiện làm chương trình không hoạt động được hoặc hoạt động nhưng không cho kết quả như mong đợi. Xảy ra sai sót khi thực thi. (Khi thực thi chương trình tại các nơi bị sai thì sẽ xảy ra trạng thái hỏng hóc). -Kết quả không mong đợi, hậu quả (Incident): là các kết quả không đúng với các yêu cầu đã đặt ra như chương trình chạy không đúng, muốn thêm bản ghi vào cơ sở dữ liệu nhưng không thêm được, hoặc đơn giản như ghi dữ liệu vào file nhưng không đóng file sau khi thực hiện xong sẽ làm mất dữ liệu sau khi kết thúc chương trình nên sau khi mở lại file sẽ không thấy dữ liệu đã thao tác đâu. -Trường hợp kiểm thử (Test case): Là một bộ bao gồm một tập các dữ liệu đầu vào, các điều kiện thực thi và các kết quả mong đợi với tập các đầu vào đó. -Kịch bản kiểm thử (Test Scenario): Các bước thực hiện khi kiểm thử -Kiểm thử viên (Tester): Người thực hiện kiểm thử phần mềm 2.4.Chất lượng phần mềm và đảm bảo chất lượng phần mềm Kiểm tra chất lượng phần mềm là một hoạt động khó khăn để chấp nhận về mặt ý thức vì chúng ta đang cân nhắc công việc của chúng ta hoặc của đồng nghiệp để tìm lỗi. Sau quá trình làm việc trong nhóm và trở thành thành viên, chúng ta ngại tìm ra lỗi và không phát hiện được ra chúng thông qua kiểm tra. Khi một người nào đó tiến hành kiểm tra lại không phải là thành viên của dự án, ví dụ một chuyên gia kiểm tra, họ được nhìn nhận như là một kẻ thù.
  17. 17. Báo cáo thực tập tốt nghiệp đại học 17 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Thêm vào đó, kiểm tra chất lượng phần mềm lại là một hoạt động khó được chấp nhận đối với việc quản lý vì nó tốn kém, mất thời gian và hiếm khi phát hiện được lỗi. Kết quả là phần lớn các ứng dụng không được kiểm tra đầy đủ và được phát hành với lỗi tiềm ẩn. Tuy vậy, chất lượng phần mềm cao là một mục tiêu quan trọng của nhóm phát triển phần mềm. Do vậy, cần và phải đảm bảo các tiêu chuẩn của phần mềm như đã đề cập ở chương 2. Đảm bảo chất lượng phần mềm là một hoạt động có hệ thống và kế hoạch. Nó bao gồm nhiều nhiệm vụ liên kết với các hoạt động chính sau: + Áp dụng các phương pháp kỹ thuật, + Tiến hành các cuộc xét duyệt kỹ thuật chính thức, + Kiểm thử phần mềm, + Buộc tôn trọng các chuẩn, + Kiểm soat thay đổi, + Đo chất lượng, + Báo cáo, lưu giữ kết quả. Theo chuẩn ANSI/IEEE, kế hoạch đảm bảo chất lượng phần mềm như sau: I. Mục đích của kế hoạch II. Tham khảo III. Quản lý A. Tổ chức B. Nhiệm vụ C. Trách nhiệm IV. Tài liệu A. Mục đích B. Tài liệu công nghệ phần mềm cần thiết C. Các tài liệu khác V. Chuẩn, thực hành và quy ước A. Mục đích B. Quy ước VI. Xét duyệt và kiểm toán A. Mục đích B. Các yêu cầu xét duyệt 1. Xét duyệt yêu cầu phần mềm 2. Xét duyệt thiết kế 3. Kiểm chứng phần mềm và xét duyệt hợp lệ 4. Kiểm toán chức năng 5. Kiểm toán vật lý 6. Kiểm toán trong tiến trình 7. Xét duyệt quản lý VII. Quản lý cấu hình phần mềm VIII. Báo cáo vấn đề và cách sửa chữa IX. Công cụ, kỹ thuật và phương pháp luận X. Kiểm soát mã XI. Kiểm soát phương tiện XII. Kiểm soát người cung cấp
  18. 18. Báo cáo thực tập tốt nghiệp đại học 18 | P a g e NguyễnVươngQuyền,lớpCNPMK53 XIII. Thu thập bảo trì và ghi nhớ báo cáo Việc đảm bảo chất lượng phần mềm là một hoạt động bản chất cho bất kỳ nhóm phát triển phần mềm nào sản xuất ra phần mềm cho người sử dụng. 2.5.Các kĩ thuật kiểm thử phần mềm -Kiểm thử hộp đen (Black Box testing): dùng để kiểm tra chức năng mà không xem xét mã nguồn cũng như cấu chúc chương trình bên trong. Thường kiểm thử hộp đen quan tâm nhiều đến các bộ dữ liệu kiểm thử đầu vào. -Kiểm thử hộp trắng (White Box testing): khác với kiểm thử hộp đen, kiểm thử hộp trắng xem xét mọi module trong chương trình, các luồng thực hiện công việc để từ đó đưa ra các chiến lược kế hoạch cụ thể cho việc kiểm thử. -Kiểm thử hộp xám (Grey Box Testing): đây là một kĩ thuật kiểm thử mới dựa trên những đặc tính của cả kiểm thử hộp đen và hộp trắng. Mục tiêu chính của kiểm thử hộp xám là kiểm thử các ứng dụng trên nền web (web based). 2.6.Các giai đoạn hay cấp độ kiểm thử phần mềm -Kiểm thử đơn vị (Unit test): kiểm thử từng module nhỏ trong chương trình để tìm ra các lỗi và khắc phục. -Kiểm thử tích hợp: sau khi đã thực hiện thành công kiểm thử đơn vị, ta sẽ tiến hành tích hợp các module này với nhau và kiểm thử trên toàn bộ khối mã lệnh đã tích hợp này. -Kiểm thử hệ thống (System test): kiểm thử trên toàn bộ ứng dụng. -Kiểm thử chấp nhận (Acceptance Test): khâu này do khách hàng trực tiếp đảm nhận trước khi bàn giao sản phẩm chính thức -Kiểm thử hồi quy là hoạt động trợ giúp để đảm bảo rằng các thay đổi không đưa ra những hành vi hoặc những lỗi bổ sung không mong đợi. 2.7. Một số loại hình kiểm thử phổ biến Hiện nay, do sự phát triển mạnh mẽ của công nghệm phần mềm nên có một số loại hình kiểm thử tiêu biểu như: -Kiểm thử các phần mềm trên Desktop: đây là các ứng dụng được cài đặt trực tiếp trên máy tính cá nhân nhằm thực hiện các chức năng theo yêu cầu người dùng. Đây vẫn đang là những ứng dụng phổ biến nhất. -Kiểm thử Web: với sự lớn mạnh của Internet thì các ứng dụng web cũng ngày càng phát triển và đang dần thay thế các ứng dụng trên Desktop truyền thống như Google Document,...
  19. 19. Báo cáo thực tập tốt nghiệp đại học 19 | P a g e NguyễnVươngQuyền,lớpCNPMK53 -Kiểm thử trên Mobile: ngày nay xã hội đang phát triển nhanh chóng, các thiết bị di động (điện thoại thông minh, máy tính bảng) cũng đang phát triển manh mẽ, cùng với đó là số lượng phần mềm phục vụ cho nhu cầu cũng tăng cao vì vậy đây là một lĩnh vực đầy tiềm năng và thách thức. Chương II Các kĩ thuật cơ bản kiểm thử phần mềm 1.Kiểm thử hộp đen (Black Box Testing - BBT) 1.1.Định nghĩa Định nghĩa: Kiểm thử hộp đen hay còn gọi là kiểm tra chức năng và thử nghiệm hành vi. Xem chương trình như là một “hộp đen” , 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ó. 1.2.Các phương pháp kiểm thử hộp đen Phân lớp tương đương – Equivalence partitioning. Phân tích giá trị biên – Boundary value analysis. Kiểm thử mọi cặp – All-pairs testing. Kiểm thử fuzz – Fuzz testing. Kiểm thử dựa trên mô hình – Model-based testing. Ma trận dấu vết – Traceability matrix. Kiểm thử thăm dò – Exploratory testing. Kiểm thử dựa trên đặc tả – Specification-base testing 1.3.Đặc điểm BBT 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ềmtheo 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ấydữ 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.
  20. 20. Báo cáo thực tập tốt nghiệp đại học 20 | P a g e NguyễnVươngQuyền,lớpCNPMK53 1.4.Nguyên lý thực hiện của BBT 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à ta sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lậptrì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ý domà 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ử duynhấ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. Các bước : o Ban đầu yêu cầu và thông số kỹ thuật của hệ thống được kiểm tra. o Tester chọn đầu vào hợp lệ (tích cực thử nghiệm kịch bản) để kiểm tra liệu SUT(Software Under Test) xử lý chúng một cách chính xác. Ngoài ra một số nguyên liệu đầu vào không hợp lệ (tiêu cực thử nghiệm kịch bản) được lựa chọn để xác minh rằng SUT có thể phát hiện ra chúng. o Tester xác định kết quả đầu ra dự kiến cho tất cả những yếu tố đầu vào. o Thử phần mềm xây dựng trường hợp thử nghiệm với các yếu tố đầu vào được lựa chọn. o Các trường hợp kiểm tra được thực hiện. o Phần mềm thử so sánh kết quả thực tế với kết quả mong đợi. o Khuyết tật nếu có được cố định và thử nghiệm lại. 1.5.Các trường hợp ứng dụng  Phân lớp tương đương - Equivalence partitioning. Ý tưởng : phân hoạch miền dữ liệu vào thành các dữ liệu có lien hệ với nhau Mỗi lớp dùng để kiểm thử 1 chức năng , gọi là lớp tương đương.
  21. 21. Báo cáo thực tập tốt nghiệp đại học 21 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Các bước : 3 bước o Đối với dữ liệu đầu vào , xác định các lớp tương đương từ miền dữ liệu. o Chọn dữ liệu đại diện cho mỗi lớp tương đương o Kết hợp các dữ liệu thử bởi tích đề các để tạo ra bộ dữ liệu kiểm thử. Nguyên tắc phân hoạch các lớp tương đương o Nếu dữ liệu vào phụ thuộc một khoảng , xây dựng  1 lớp các giá trị lớn hơn  1 lớp các giá trị nhỏ hơn  N các giá trị hợp lệ o Nếu dữ liệu là tập hợp các giá trị , Xây dựng  1 lớp tập rỗng  1 lớp quá nhiều các giá trị  N lớp hợp lệ o Nếu dữ liệu đầu vào là điều kiện ràng buộc , xây dựng  1 lớp các ràng buộc được thỏa mãn.  1 lớp với ràng buộc không được thỏa mãn. Ví dụ : Bài toán tam giác Nhọn Vuông Tù Thường 6,5,3 3,4,5 5,6,10 Cân 6,1,6 √2, 2, √2 7,4,4 Đều 4,4,4 Không thể Không thể Không là tam giác -1,2,8  Phân tích giá trị biên - Boundary value analysis.:
  22. 22. Báo cáo thực tập tốt nghiệp đại học 22 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Cơ sở : lỗi thường xuất hiện gần các giá trị biên của miền dữ liệu. Tập trung phân tích các giá trị biên của miền dữ liệu để xây dựng dữ liệu kiểm thử. Nguyên tắc kiểm thử các dữ liệu bao gồm: o Giá trị nhỏ nhất. o Giá trị gần kề lớn hơn giá trị nhỏ nhất. o Giá trị bình thường. o Giá trị gần kề nhỏ hơn giá trị lớn nhất o Giá trị lớn nhất Nguyên tắc chọn dữ liệu thử o Nếu dữ liệu vào thuộc một khoảng , chọn  2 Giá trị biên.  4 giá trị = Giá trị biên ± sai số nhỏ nhất o Nếu giá trị vào phụ thuộc danh sách các giá trị , chọn phần tử lớn thứ nhất , phần tử thứ hai , phần tử kế cuối , phần tử cuối. o Nếu dữ đầu vào là điều kiện ràng buộc số giá trị , chọn số giá trị tối thiểu và số giá trị tối đa và một số giá trị không hợp lệ. Ví dụ : Chương trình nhận vào ba số thực , kiểm tra xem có phải là độ dài ba cạnh tam giác hay không ? nếu là độ dài ba cạnh tam giác thì kiểm tra xem là tam giác thường , cân , vuông , nhọn , tù . Các giá trị cần kiểm tra: Dữ liệu thử 1, 1, 2 Không là tam giác 0, 0, 0 Chỉ là một điểm 4, 0, 3 Một cạnh bằng không 1, 2, 3.000001 Gần là 1 tam giác 0.001, 0.001, 0.001 Tam giác rất nhỏ 99999, 99999, 99999 Tam giác rất lớn 3.00001, 3, 3 Tam giác gần đều 2.99999, 3, 4 Tam giác gần cân 3, 4, 5.000001 Tam giác gần vuông
  23. 23. Báo cáo thực tập tốt nghiệp đại học 23 | P a g e NguyễnVươngQuyền,lớpCNPMK53 3, 4, 5, 6 Bốn giá trị 3 Chỉ 1 giá trị Dữ liệu rỗng -3, -4, -5 Giá trị âm  Bảng quyết định- Decision Table Bases testing -Làm giảm số lượng tets casse không cần thiết so với 2 kỹ thuật trên vì nó loại trừ các phép kết hợp không cần thiết giữa các giá trị biến đầu vào. -Liệt kê nguyên nhân (cause) – kết quả (result) trong một ma trận. Mỗi cột ma trận đại diện cho 1 phép kết hợp giữa các cause trong trong việc tạo ra 1 result - Các bước để tạo bảng quyết định o Liệt kê các nguyên nhân trong bảng quyết định o Tính tổng số lượng kết hợp giữa các cause o Điền vào các cột với tất cả các kết hợp có thể có o Rút bớt số lượng các phép kết hợp dư thừa o Kiểm tra các phép kết hợp có bao phủ hết mọi trường hợp hay không o Bổ xung kết quả vào bảng quyết định Ví dụ : Bài toán kiểm tra loại chiều dài 3 cạnh a,b,c  B1: Liệt kê tất cả các nguyên nhân o Điền giá trị vào từng cause o Nhóm các cause có liên quan o Sắp xếp các Cause theo thứ tự
  24. 24. Báo cáo thực tập tốt nghiệp đại học 24 | P a g e NguyễnVươngQuyền,lớpCNPMK53  B2: Tính tổng số kết hợp giữa các cause o Tổng số phép kết hợp = (Số lượng value cause 1)*…*(Số lượng value của cause n). Ví dụ: Mỗi cause có 2 giá trị true , false -> Tổng số phép kết hợp là : 26 = 64.  B2: Điền giá trị các cột vào trong bảng o Thuật toán  Xác định số lần lặp lại (RF) trong từng giá trị của cause bằng cách lấy tổng số phép kết hợp còn lại chia cho số values mà cause có thể nhận  Điền dữ liệu cho dòng thứ i : Điền RF lần giá trị đầu tiên của cause i , tiếp theo RF lần theo giá trị tiếp theo của cause I cho đến khi dòng đầy  Chuyển sang dòng kế tiếp và quay lại bước 1 thực hiện Ví dụ :  Bước 4 : Giảm số phép kết hợp o Duyệt qua tất cả các ô trong từng cột, ô nào mà kết quả của nó không ảnh hưởng đến result thì đặt giá trị trên ô này là “-”
  25. 25. Báo cáo thực tập tốt nghiệp đại học 25 | P a g e NguyễnVươngQuyền,lớpCNPMK53 o Ghép các cột với lội dung giống nhau thành 1 cột  Bước 5 : Kiểm tra độ bao phủ của các phép kết hợp o Tính rule-count trên từng cột(số lượng phép kết hợp) mà cột này có thể thực hiện. o Với các dòng có giá trị là “-” thì lũy thừa 2 o Nếu tổng của các rule-count bằng với tổng số kết hợp giữa các cause trong bước 2 thì bẳng quyết định này đầy đủ  Bước 6 : Bổ xung kết quả vào trong bảng o Duyệt qua từng cột và check vào kết quả o Nhiều cột khác nhau có thể cho ra cùng 1 kết quả giống nhau  Đồ thị nguyên nhân kết quả. -Là kỹ thuật thiết kế test case dựa tên đồ thị -Tập trung vào việc xác định các mối kết hợp giữa các điều kiện và kết quả mà các mối kết hợp mang lại. -Các bước xây dựng đồ thị:
  26. 26. Báo cáo thực tập tốt nghiệp đại học 26 | P a g e NguyễnVươngQuyền,lớpCNPMK53 o B1: Phân chia hệ thống thành vùng hoạt động o B2: Xác định nguyên nhân kết quả o B3: Chuyển nội dung ngữ nghĩa trong đặc tả thành đồ thị liên kết các cause và result o B4: Chuyển đổi đồ thị thành bảng quyết định o B5: Thiết lập danh sách test case từ bảng quyết định. Mỗi test case tương ứng với 1 cột trong bảng quyết định  B1: Phân chia hệ thống thành các vùng hoạt động o Phân rã các yêu cầu chức năng thành danh sách các functions hay sub_functions  B2:Xác định nguyên nhân kết quả o Dựa vào đặc tả , xác định các cause và chỉ định mỗi cause này định danh ID.  Mỗi 1 cause có thể xem như là 1 input conditions hoặc là đại diện của 1 lớp tương đương input conditions o Dựa vào đặc tả xác định kết quả hoặc thay đổi trạng thái của hệ thống và chỉ định mỗi kết quả 1 định danh ID  Kết quả có thể là ouput action , output option hay là đại diện của 1 lớp tương đương output conditions. Ví dụ : Xét đặc tả hệ thống tính phí bảo hiểm xe ô tô  Đối với nữ < 65 tuổi , phí bảo hiểm là : 500$  Đối với nam < 25 tuổi , phí bảo hiểm là : 3000$  Đối với nam từ 25 tuổi đến 64 tuổi , phí bảo hiểm là : 1000$  Nếu tuổi từ 65 trở lên, phí bảo hiểm là : 1500$ Có 2 yếu tố xác định phí bảo hiểm : giới tính và tuổi  B3: Chuyển nội dung ngữ nghĩa thành đồ thị liên kết -CEG #1: Đối với nam từ 25 đến 64 , phí bảo hiểm 1000$ -CEG #2 : Đối với nam <25 tuổi, phí bảo hiểm 3000$
  27. 27. Báo cáo thực tập tốt nghiệp đại học 27 | P a g e NguyễnVươngQuyền,lớpCNPMK53 -CEG #3 : Nếu tuổi từ 64 trở lên , phí bảo hiểm là : 1500$ -CEG #4 : Đối với nữ <65 tuổi , phí bảo hiểm là :500$  B4: Chuyển đổi đồ thị thành bảng quyết định
  28. 28. Báo cáo thực tập tốt nghiệp đại học 28 | P a g e NguyễnVươngQuyền,lớpCNPMK53  B5: Thiết lập danh sách các test case từ bảng quyết định
  29. 29. Báo cáo thực tập tốt nghiệp đại học 29 | P a g e NguyễnVươngQuyền,lớpCNPMK53  Kiểm thử dựa trên yêu cầu - Specification-based testing. Phương pháp kiểm thử dựa vào chức năng - Specification-based testing: Việc kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem nó có phù hợp với yêu cầu của người dùng hay không. Vì vậy, các tester nhập data vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu test. Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test, khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đợi đã được viết trong test case, điền kết quả test vào test case là OK (OK = is – chương trình làm đúng theo mong đợi) hay NG (not good = is not – chương trình không làm đúng theo mong đợi). Specification-based testing là cần thiết, nhưng nó không đủ để bảo đảm chắc chắn các rủi ro xảy ra (nó chỉ là điều điện cần chứ không phải là điều kiện đủ). 1.6.Ưu điểm/ Nhược điểm của BBT Ưu diểm:  Hiệu quả hơn trên các đơn vị code lớn hơn kiểm tra hộp thủy tinh (Glass box testing).  Tester và người lập trình độc lập với nhau.  Tester không cần kiến thức thực hiện, bao gồm cả ngôn ngữ lập trình cụ thể.  Tester thực hiện trên quan điểm của người sử dụng.  Giúp phát hiện bất kỳ sự mơ hồ hoặc không nhất quán trong các đặc tả chức năng.  Trường hợp kiểm tra có thể được thiết kế như là ngay sau khi các đặc tả kỹ thuật hoàn thành. Nhược điểm:  Chỉ có một số nhỏ các yếu tố đầu vào có thể thực sự có thể được thử nghiệm, để kiểm tra tất cả các dòng đầu vào có thể sẽ mất gần như mãi mãi.  Mà không cần các chi tiết kỹ thuật rõ ràng và xúc tích, kiểm tra trường hợp rất khó để thiết kế.  Có thể được lặp đi lặp lại không cần thiết của đầu vào thử nghiệm nếu người thử không có thông tin về trường hợp thử nghiệm các lập trình viên đã thử nghiệm.  Có thể để lại nhiều phần chương trình chưa được kiểm tra.  Không thể được hướng dẫn đối với các phân đoạn cụ thể của mã mà có thể rất phức tạp.  Hầu hết các thử nghiệm nghiên cứu liên quan đã được hướng vào việc kiểm tra hộp trắng. 2.Kiểm thử hộp trắng (White Box Testing - WBT) 2.1.Định nghĩa Là phương pháp kiểm nghiệm dựa vào cấu trúc/mã lệnh chương trình. Phương pháp white-box kiểm nghiệm một chương trình (một phần chương trình, hay một hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm cả các giá trị không đúng hay không theo dự định 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
  30. 30. Báo cáo thực tập tốt nghiệp đại học 30 | P a g e NguyễnVươngQuyền,lớpCNPMK53 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). Hình 7 : Kiểm thử hộp trắng 2.2.Đặc điểm của WBT  Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần mềm đó có thực hiện đúng không.  Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định để có thể thông hiểu chi tiết về đoạn code cần kiểm thử.  Thường tốn rất nhiều thời gian và công sức nếu mức độ kiểm thử được nâng lên ở cấp kiểm thử tích hợp hay kiểm thử hệ thống.  Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị. Trong lập trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1 class chức năng nào đó.  Có 2 hoạt động kiểm thử hộp trắng :  Kiểm thử luồng điều khiển.  Kiểm thử dòng dữ liệu. Phụ thuộc vào các cài đặt hiện tại của hệ thống và của phần mềm, nếu có sự thay đổi thì các bài test cũng thay đổi theo Được ứng dụng trong các kiểm tra ở cấp độ mô đun, tích hợp và hệ thống của quá trình test phần mềm. 2.3.Các kĩ thuật kiểm thử của WBT Phương pháp kiểm nghiệm white-box dựa trên:  Các câu lệnh (statement) : Thiết kế quá trình kiểm tra sao cho mỗi câu lệnh của chương trình được thực hiện ít nhất một lần. Phương pháp kiểm tra này xuất phát từ ý tưởng: Từ phi một câu lệnh được thực hiện, nếu không ta không thể biết được có lỗi xảy ra trong câu lệnh đó hay không Nhưng việc kiểm tra với một giá trị đầu vào không đảm bảo là sẽ đúng cho mọi trường hợp
  31. 31. Báo cáo thực tập tốt nghiệp đại học 31 | P a g e NguyễnVươngQuyền,lớpCNPMK53 . Xét ví dụ với đoạn mã lệnh JAVA sau: public void foo (int a, int b, int x){ if (a>1 && b==0) { x=x/a;} if (a==2||x>1){ x=x+1; } } Hình 8:Sơ đồ luồng Có thể thực hiện mọi câu lệnh bằng việc viết 1 ca kiểm thử đơn đi qua đường ace. Tức là, bằng việc đặt A=2, B=0 và X=3 tại điểm a, mỗi câu lệnh sẽ được thực hiện 1 lần (thực tế, X có thể được gán bất kỳ giá trị nào).  Đường dẫn (path) Là phương pháp kiểm tra bao trùm mọi đường dẫn của chương trình và cần kết hợp với lược đồ tiến trình. Tư tưởng: Viết đủ các ca kiểm thử mà mỗi quyết định có kết luận đúng hay sai ít nhất 1 lần. Nói cách khác, mỗi hướng phân nhánh phải được xem xét kỹ lưỡng ít nhất 1 lần.
  32. 32. Báo cáo thực tập tốt nghiệp đại học 32 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Hình 9: Các trường hợp kiểm thử đường dẫn Trong ví dụ trên: Kiểm thử đường dẫn có thể đạt được bởi ít nhất hai ca kiểm thử bao phủ các đường abe và abd hoặc acd và abe. Nếu chọn khả năng thứ hai thì hai đầu vào test case là: A=3, B=0, X=3 và A=2, B=1, X=1. Nhận xét: Phương pháp kiểm tra theo đường dẫn phụ thuộc nhiều vào các biểu thức điều kiện. Tuy nhiên, có những trường hợp số lượng đường dẫn quá lớn (trường hợp vòng lặp). Vì vậy thường không phải là lựa chọn thực tế để tiến hành việc kiểm tra tính đúng đắn của chương trình.  Các điều kiện (condition) Là phương pháp kiểm tra các biểu thức điều kiện trên 2 giá trị true và false.  Viết đủ các ca kiểm thử để đảm bảo rằng mỗi điều kiện trong một quyết định đảm nhận tất cả các kết quả có thể ít nhất một lần. Trong ví dụ trên: có 4 điều kiện: A>1, B=0, A=2, X>1. Do đó các ca kiểm thử đầy đủ là cần thiết để thúc đẩy những trạng thái mà A>1, A<=1, B=0 và B<>0 có mặt tại điểm a và A=2, A<>2, X>1, X<=1 có mặt tại điểm b. Số lượng đầy đủ các ca kiểm thử thỏa mãn tiêu chuẩn và những đường đi mà được đi qua bởi mỗi ca kiểm thử là: 1. A=2, B=0, X=4 ace 2. A=1, B=1, X=1 abd Ví dụ, 2 ca kiểm thử khác: 1. A=1, B=0, X=3
  33. 33. Báo cáo thực tập tốt nghiệp đại học 33 | P a g e NguyễnVươngQuyền,lớpCNPMK53 2. A=2, B=1, X=1 bao phủ tất cả các kết quả điều kiện, nhưng chúng chỉ bao phủ 2 trong 4 kết quả quyết định (cả 2 đều bao phủ đường đi abd và do đó, không sử dụng kết quả true của quyết định đầu tiên và kết quả false của quyết định thứ hai). Nhận xét: Khi kiểm tra bằng phương pháp kiểm tra theo điều kiện cần xem xét kết hợp các điều kiện với nhau.  Vòng lặp (loop) Là phương pháp tập trung vào tính hợp lệ của các cấu trúc vòng lặp. Hình 10: Kiểm thử vòng lặp - Các bước cần kiểm tra cho vòng lặp đơn: + Bỏ qua vòng lặp. + Lặp một lần. + Lặp hai lần. + Lặp m lần (m<n). + Lặp (n-1), n, (n+1) lần. Trong đó n là số lần lặp tối đa của vòng lặp. - Các bước cần kiểm tra cho vòng lặp dạng lồng nhau: + Khởi đầu với vòng lặp nằm bên trong nhất. Thiết lập các tham số lặp cho các vòng lặp bên ngoài về giá trị nhỏ nhất. + Kiểm tra với tham số min+1, 1 giá trị tiêu biểu, max-1 và max cho vòng lặp bên trong nhất trong khi các tham số lặp của các vòng lặp bên ngoài là nhỏ nhất. + Tiếp tục tương tự với các vòng lặp liền ngoài tiếp theo cho đến khi tất cả vòng lặp bên ngoài được kiểm tra.
  34. 34. Báo cáo thực tập tốt nghiệp đại học 34 | P a g e NguyễnVươngQuyền,lớpCNPMK53 - Các bước cần kiểm tra cho vòng lặp nối tiếp: + Nếu các vòng lặp là độc lập với nhau thì kiểm tra như trường các vòng lặp dạng đơn, nếu không thì kiểm tra như trường hợp các vòng lặp lồng nhau. Ví dụ: với đoạn code Java sau Giá trị đầu vào Kết quả (Số lần lặp) 11 0 (bỏ qua vòng lặp) 10 1 (chạy 1 lần lặp) 9 2 (chạy 2 lần lặp) 5 6 (trường hợp chạy m lần lặp khi m<n) 2 9 (chạy N-1 lần lặp) 1 10 (chạy N lần lặp) 0 0 (bỏ qua vòng lặp) 2.4.Ưu điểm / Nhược điểm của White Box Testing  Ưu điểm  Kiểm tra được toàn bộ chương trình nguồn  Phát hiện lỗi tại chỗ  Tự động hóa kiểm thử
  35. 35. Báo cáo thực tập tốt nghiệp đại học 35 | P a g e NguyễnVươngQuyền,lớpCNPMK53  Chính xác: “Việc thực hiện một white box testing tốt có thể đưa đến một chương trình đúng tuyệt đối.”  Nhược điểm  Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình. Do đó đòi hỏi tài nguyên nhân lực và máy tốn kém.  Có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi  Không kiểm thử hết đường đi với các vòng lặp lớn, phức tạp  Khó thực hiện và chi phí thực hiện cao 3.Kiểm thử hộp xám (Gray Box Testing - GBT) 3.1.Định nghĩa GBT là một phương pháp kiểm thử phần mềm được kết hợp giữa Phương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp trắng). Trong Kiểm thử hộp đen, Tester kiểm thử các hạng mục mà không cần biết cấu trúc bên trong của nó, còn trong Kiểm thử Hộp trắng thì Tester biết được cấu trúc bên trong của chương trình. Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, Tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc là ở mức hộp đen. Được gọi là Gray Box Testing vì trong chương trình phần mềm, mắt của Tester giống như hộp xám/bán trong suốt - nhìn qua hộp này ta chỉ có thể thấy được một phần. 3.2.Ứng dụng Mặc dù phương pháp Gray Box Testing có thể ứng dụng vào nhiều mức test khác nhau nhưng chủ yếu nó hữu dụng trong mức Integration Testing - kiểm thử tích hợp. 3.3.Ưu điểm và Nhược điểm Ưu điểm và nhược điểm của Kiểm thử Hộp xám được quyết định dựa vào sự kết hợp các ưu điểm của Black Box Testing và White Box Testing.
  36. 36. Báo cáo thực tập tốt nghiệp đại học 36 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Chương III Các cấp độ hay giai đoạn kiểm thử phần mềm Hình dưới mô tả các bước kiểm thử có trong quy trình phát triển phần mềm Hình 2 - Các loại kiểm thử Dưới đây ta sẽ trình bày một cách chi tiết từng kỹ thuật kiểm thử trên 1. Kiểm thử đơn vị (Unit Testing) Trước hết ta sẽ định nghĩa khái niệm đơn vị. Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm tra đượ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. Do đó kiểm thử đơn vị là kiêm tra sự thực thi của các đơn vị chương trình riêng rẽ. Do các Unit được kiểm tra thường có kích thước nhỏ và chức năng hoạt động tương đối đơn giản nên chúng ta sẽ không gặp mấy khó khăn trong việc tổ chức kiểm tra ghi nhận và phân tích kết quả kiểm tra. 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. Trong thực tiễn thường thì thời gian chi phí 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 tra và sửa lỗi ở các mức kiểm tra sau đó. Do đó nếu trong bước này chúng ta làm cẩn thận thì các bước test sau sẽ ít gặp lỗi hơn nhiều.
  37. 37. Báo cáo thực tập tốt nghiệp đại học 37 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Giá thành sẽ càng bị đội lên nếu không phát hiện thấy lỗi ở ngay bước Unit Testing 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 tra 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 ra khỏi Unit là chính xác trong mối tương quan giữa dữ liệu nhập và chức năng của unit. Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng 2. Kiểm thử tích hợp (Integration Test) Integration test kết hợp các thành phần của một ứng dụng và kiểm tra 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 và truyền thông điệp giữa chúng. Các mục tiêu chính của Integration Test bao gồm:  Phát hiện lỗi giao tiếp xảy ra giữa các Unit.  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 tra ở 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 tra đơ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 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. 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 mà nhóm các Unit đó đã đượ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 tra 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 làm cho số lượng kiểm tra sẽ giảm đi rất nhiều và sai sót sẽ giảm đáng kể. Có 4 loại kiểm tra trong Integration Test:
  38. 38. Báo cáo thực tập tốt nghiệp đại học 38 | P a g e NguyễnVươngQuyền,lớpCNPMK53  Kiểm tra cấu trúc (structure): Tương tự White Box Test tức là kiểm tra 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, 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 lệnh và nhánh bên trong.  Kiểm tra chức năng (functional): Tương tự Black Box Test tức là kiểm tra chỉ chú trọng đến chức năng của chương trình, 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.  Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.  Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống. 2.1.Tích hợp từ trên xuống Tích hợp từ trên xuống là cách tiếp cận tăng dần tới việc xây dựng cấu trúc chương trình. Các module được tích hợp bằng cách đi dần xuống qua các bậc điều khiển bắt đầu với module chính. Các module phụ thuộc và module điều khiển sẽ được tổ hợp dần vào trong cấu trúc theo chiều sâu trước hay chiều rộng trước. Các bước thực hiện tiến trình tích hợp: - Module kiểm thử chính được dùng như một bộ phận điều khiển kiểm thử và các stub được thế vào cho tất cả các module phụ thuộc trực tiếp vào các module điều khiển chính. - Tùy theo cách tiếp cận tích hợp được lựa chọn các module phụ thuộc được thay thế từng cái một mỗi lần bằng các module thực tại. - Việc kiểm thử được tiến hành khi từng module được tích hợp vào. - Khi hoàn thành từng tập các phép kiểm thử, stub khác sẽ được thay thế bằng các module thực. - Kiểm thử hồi qui có thể được tiến hành để đảm bảo rằng những lỗi mới không được đưa thêm vào. Hình 3.2. Kiểm thử tích hợp top-down
  39. 39. Báo cáo thực tập tốt nghiệp đại học 39 | P a g e NguyễnVươngQuyền,lớpCNPMK53 2.2.Tích hợp từ dưới lên Kiểm thử tích hợp từ dưới lên bắt đầu xây dựng và kiểm thử với các module ở mức thấp nhất của chương trình. Chiến lược tích hợp từ dưới lên có thể được thực hiện qua những bước sau: - Các module mức thấp được tổ hợp vào các cluster thực hiện cho một chức năng phần mềm nhỏ cụ thể. - Một trình điều khiển kiểm thử được xây dựng để kết hợp các trường hợp kiểm thử vào ra. - Kiểm thử các cluster. - Loại bỏ trình điều khiển kiểm thử và các chùm được tổ hợp di chuyển lên trong cấu trúc chương trình. Các module được kết hợp tạo thành các nhóm 1, 2, 3. Mỗi nhóm được kiểm thử sử dụng bộ điều khiển. Các module trong nhóm 1 và 2 là mức dưới của Ma. Các bộ điều khiển D1 và D2 được loại bỏ và các nhóm được giao tiếp trực tiếp với Ma. Tương tự, bộ điều khiển D3 cho nhóm 3 được loại bỏ trước khi tích hợp với module Mb. Cả hai Ma và Mb cuối cùng sẽ được tích hợp với module Mc,….. Hình 3.3. Tích hợp bottom-up Kiểm thử tích hợp nhằm nhận được một phần hay toàn bộ hệ thống như mong đợi. Khi tích hợp các thành phần có thể gặp sai sót: - Dữ liệu bị mất khi đi qua một giao diện. - Hiệu ứng bất lợi một module vô tình gây ra đối với các module khác. - Sự kết hợp các chức năng phụ có thể không sinh ra chức năng chính mong muốn. - Sự phóng đại các sai sót riêng rẽ có thể bị đến mức không chấp nhận được. - Vấn đề của cấu trúc dữ liệu toàn cục có thể để lộ ra.
  40. 40. Báo cáo thực tập tốt nghiệp đại học 40 | P a g e NguyễnVươngQuyền,lớpCNPMK53 Nhược điểm chính của kiểm thử tích hợp từ dưới lên là chương trình như một thực thể chưa tồn tại cho đến khi module cuối cùng được thêm vào. Các chiến lược kiểm thử tích hợp top-down và bottom-up có những ưu và nhược điểm khác nhau. Ưu điểm của chiến lược này có xu hướng là nhược điểm của chiến lược kia. Bảng so sánh dưới đây sẽ cho một cái nhìn chi tiết hơn: Kiểm thử top-down Kiểm thử bottom-up Ưu điểm - Có ưu điểm nếu lỗi tập trung trên đỉnh của chương trình. - Khi các chức năng I/O được bổ sung thì đưa ra các trường hợp kiểm thử sớm hơn. - Việc có chương trình khung sẽ sớm tạo ra một tư duy rõ ràng hơn và tạo tâm lý tốt khi kiểm thử. - Có ưu điểm nếu lỗi chính xuất hiện phía dưới của chương trình. - Các điều kiện kiểm thử dễ dàng được tạo ra. - Việc quan sát các kết quả kiểm thử là dễ hơn. Nhược điểm - Module nhánh cụt bắt buộc phải được tạo. - Module nhánh cụt thường phức tạp hơn trong lần xuất hiện đầu tiên. - Trước khi những chức năng I/O được thêm, việc đưa ra các trường hợp kiểm thử tại nhánh cụt có thể rất khó khăn. - Việc tạo ra các điều kiện kiểm thử là không thể hoặc rất khó khăn. - Việc quan sát đầu ra kiểm thử là khó khăn hơn. - Làm cho người ta nghĩ nhầm rằng việc thiết kế chương trình và kiểm thử là chồng chéo nhau. - Gây ra sự trì hoãn việc hoàn thành một module nào đó. - Các module điều khiển bắt buộc phải được tạo ra. - Chương trình như là một thực thể không tồn tại cho đến khi module cuối cùng được tạo ra. Bảng 3.1. So sánh kiểm thử top-down và bottom-up Khi kiểm thử tích hợp được thực hiện, người kiểm thử cần chỉ ra các module tới hạn. Module tới hạn có một hoặc nhiều đặc trưng sau: - Lựa chọn một số yêu cầu phần mềm. - Có mức điều khiển cao. - Là phức tạp hoặc dễ xảy ra lỗi.
  41. 41. Báo cáo thực tập tốt nghiệp đại học 41 | P a g e NguyễnVươngQuyền,lớpCNPMK53 - Có các yêu cầu thực hiện không rõ ràng. Các module tới hạn cần được kiểm thử sớm nhất có thể. Hơn nữa, các kiểm thử hồi quy cần tập trung trên chức năng của module tới hạn. 3. Kiểm thử hồi quy Kiểm thử hồi qui là hoạt động trợ giúp để đảm bảo rằng các thay đổi không đưa ra những hành vi hoặc những lỗi bổ sung không mong đợi. Kiểm thử hồi quy có thể được thực hiện thủ công, bằng cách thực hiện lại tập con tất cả các trường hợp kiểm thử hoặc sử dụng các công cụ tự động. Bộ kiểm thử hồi quy gồm ba lớp các trường hợp kiểm thử khác nhau: - Một mẫu đại diễn của các kiểm thử sẽ được thực hiện tất cả các chức năng của phần mềm. - Các trường hợp kiểm thử bổ sung tập trung vào các chức năng phần mềm có khả năng bị tác động khi có sự thay đổi. - Các kiểm thử tập trung vào các thành phần phần mềm vừa bị thay đổi. Kiểm thử hồi quy là một trong những loại kiểm thử tốn nhiều thời gian và công sức nhất. Tuy nhiên, việc bỏ qua kiểm thử hồi quy là điều không thể vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta tưởng rằng những lỗi đó hoặc không có hoặc đã kiểm thử và sửa chữa rồi. 4. Kiểm thử hệ thống (System Testing) System test bao gồm một loạt những kiểm nghiệm nhằm xác minh toàn bộ các thành phần của hệ thống được tích hợp một cách đúng đắn. Mục đích của kiểm thử hệ thống là đảm bảo toàn bộ hệ thống hoạt động như khách hàng mong muốn. 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 tra 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 tra đòi hỏi yên cầu phải có môi trường kiểm thử thích hợp. Ví dụ như 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 độ của kiểm thử hệ thống thì tester cũng tìm kiếm các lỗi, nhưng trọng tâm của loại kiểm thử này là đánh giá về chức năng, 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 thực thể hoặc đối tượng khi chúng làm việc cùng nhau. Trong quy trình kiểm thử thì thông thường ta phải thực hiện Unit Test và Integration Test để đảm bảo mọi đơn vị và giao tiếp, tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test. 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 tester sẽ bắt đầu kiểm tra phần mềm như một hệ thống hoàn chỉnh. Và 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 của phần mềm. System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu phi chức nă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 tra này đặc biệt thích hợp
  42. 42. Báo cáo thực tập tốt nghiệp đại học 42 | P a g e NguyễnVươngQuyền,lớpCNPMK53 cho việc phát hiện lỗi giao tiếp với các phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi bế tăc (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 tra để chấp nhận (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 tra viên hoàn toàn độc lập với nhóm phát triển dự án System test bao gồm một số loại kiểm tra sau:  Kiểm tra chức năng (Functional Testing): Kiểm tra hệ thống sau khi tích hợp có hoạt động đúng chức năng với yêu cầu đặt ra trong bản mô tả yêu cầu hay không. VD: Với hệ thống xử lý văn bản thì kiểm tra các chức năng như: tạo tài liệu, sửa tài liệu, xóa tài liệu… có hoạt động đúng theo yêu cầu hay không.  Kiểm tra hiệu năng (Performance Testing): Đảm bảo tối ưu việc phân bổ tài nguyên hệ thống nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn.  Kiểm tra mức độ đáp ứng (Stress Testing): Thực thi hệ thống với giả thiết là các tài nguyên hệ thống yêu cầu không đáp ứng được về chất lượng, ổn định, số lượng. Loại kiểm tra này tập trung vào các điểm tới hạn, điểm chết, các tình huống bất thường của hệ thống.  Kiểm tra cấu hình (Configuration Network): Phân tích hệ thống với các thiết lập cấu hình khác nhau  Kiểm nghiệm ổn định (Robustness Testing): Kiểm nghiệm dưới các điều kiện không mong đợi. Ví dụ như người dùng gõ lệnh sai hay nguồn điện bị ngắt.  Kiểm tra khả năng phục hồi (Recorvery Testing): Đảm bảo 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. Điều này đặc biệt quan trọng với các hệ thống giao dịch như ngân hàng trực tuyến.  Kiểm tra khả năng bảo mật (Security Testing): Đảm bảo tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.  Kiểm tra quá tải (Overload Testing): Đánh giá hệ thống khi nó vượt qua giới hạn cho phép.  Kiểm tra chất lượng (Quality Testing): Đánh giá sự tin tưởng, vấn đề duy tu, tính sẳn sàng của hệ thống. Bao gồm cả việc tính toán thời gian trung bình hệ thống sẽ bị hỏng và thời gian trung bình để khắc phục.  Kiểm tra cài đặt (Installation Testing): Người dùng sử dụng các chức năng của hệ thống và ghi lại các lỗi tại vị trí sử dụng thật sự. VD: Một hệ thống điều khiển một lò nấu thép phải đảm bảo không chịu sự ảnh hưởng của nhiệt độ. 5. Kiểm thử chấp nhận (Acceptance Testing) Sau giai đoạn System Test là Acceptance Test, đây là giai đoạn kiểm tra được khách hàng 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 tra của System Test và Accepatnce 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 tra gọi là Alpha Test và Beta Test. Với Alpha Test, người sử dụng kiểm tra 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
  43. 43. Báo cáo thực tập tốt nghiệp đại học 43 | P a g e NguyễnVươngQuyền,lớpCNPMK53 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 sử dụng để kiểm tra 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. Trên thực tế, 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ì thường kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra 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 PM xuất sắc vượt qua các phép kiểm tra 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 tra 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… Chương IV Một số loại hình kiểm thử hiện nay 1.Tổng quan về kiểm thử Website 1.1.Giới thiệu Một hệ thống máy tính bao gồm cả phần cứng và phần mềm có thể nhận đầu vào từ người dùng sau đó lưu trữ vào đâu đó như bộ nhớ trong ( ví dụ RAM) hay bộ nhớ ngoài ( ổ HDD). Hệ thống có thể tính toán các câu lệnh của bộ xử lí trung tâm.và sau khi thực thi xong sẽ trả về kết quả cho người dùng hay làm đầu vào cho một hệ thống khác. Thông qua giao diện, người dùng có thể tương tác với ứng dụng như nhập liệu dưới nhiều dạng để cho ứng dụng tính toán, xử lí kết quả và thu nhận kết quả trả về. Trong các hệ thống máy tính lớn (như Mainframe), tất cả các xử lí quan trọng đều được thực thi ở máy chủ, các điều khiển giao diện chỉ được thực thi tại các thiết bị đầu cuối (dumb terminal) dưới dạng các văn bản. Hệ thống mạng kết nối các máy tính đầu cuối với các máy chủ trung tâm. Người dùng có thể gửi dữ liệu dưới dạng câu lệnh hay điều khiển đến máy tính thông qua các thiết bị thu nhận đầu vào (bàn phím). Các hệ thống máy tính cá nhân để bàn thì đều hợp nhất tất cả các xử lí từ giao diện qua các luật xử lí cho đến các hệ thống tệp trên một máy tính đơn. Các hệ thống máy tính cá nhân có thể hỗ trợ giao diên văn bản hay giao diện đồ họa. Các hệ thống Client – Server web based cần có hệ thống mạng và ít nhất hai máy tính hoạt động đồng thời để thực hiện công việc: trong đó một máy tính sẽ đóng vai trò làm Server và máy kia là Client. Client đơn giản chỉ là gửi các yêu cầu do người dùng hay một hệ thống khác yêu cầu đến Server, và tại đây mọi xử lí diễn ra, sau khi có được kết quả Server sẽ trả về ngay cho Client và Client cũng đơn giản chỉ là hiện thị lên kết quả. Đối với phần lớn các ứng dụng website thì thì một trình duyệt web (web browser), một web browser hoạt đọng như là một chương trình giao diện trên Client. Server nhận các yêu cầu Client và áp dụng các luật logic cyar ứng dụng để xử lí dữ liệu. Các luật logic là những tính toán mà một ứng dụng được thiết kế để thực hiện dựa trên
  44. 44. Báo cáo thực tập tốt nghiệp đại học 44 | P a g e NguyễnVươngQuyền,lớpCNPMK53 dữ liệu vào của người dùng. Các loại hoạt đọng này có thể yêu cầu đọc ghi cơ sở dữ liệu . Đầu ra của Server sau đó có thể được browser hiển thị cho người dùng. Một hệ thống web có thể bao gồm nhiều Server và Client tùy thuộc độ lớn nhỏ của hệ thống. Phía Server của hệ thống web có thể hỗ trợ tập hợp cả phần cứng và phần mềm, và như thế trở lơn phức tạp hơn so với hệ thống máy tính lớn về góc độ khả năng tương thích và cấu hình. Đã từ lâu việc kiểm thử website đặt ra nhiều thách thức với các nhà phát triển web. Ngày nay hầu hết các ứng dụng đều phải dựa trên nền tảng, dựa trên sức mạnh ngày càng mạnh mẽ của Internet, việc một trang web sau khi được xây dựng thành công xong và đưa lên Server thì dù tại bất kì đâu trên thế giới đều có thể truy cập vào được. Một điểm mạnh nữa của các ứng dụng web đó là nó có thể được truy cập từ bất kì thiết bị đầu cuối nào mà có cài đặt một trình duyệt web và hoạt động trên đa nền tảng, từ các hệ điều hành phổ biến chạy trên PC như Microsoft Windows, Mac OSX, Linux cho đến các hệ điều hành nhúng đơn giản nhỏ gọn chạy trên các thiết bị di động như Google Android, Apple Iphone, RIM Blackbery,...Tính năng cơ động này càng trở nên phổ biến khi các thiết bị Smart Phone có số lượng người dùng tăng lên đột biến trong các năm trở lại đây. Sự phát triển của xã hội cộng với trào lưu dùng mạng xã hội để chai sẻ và giao lưu giữa con người như Facebook, Twitter,... làm cho công nghệ web ngày càng phát triển mạnh, cùng với đó là một nền tảng Điện toán đám mây (cloud computing) với các ứng dụng cần thiết đều có sẵn trên máy chủ web Server, các máy tính Client chỉ đơn giản là có một kết nối tới Internet là có thể sử dụng các dịch vụ có sẵn của Server mà không hề cần cài đặt, điều này giảm đáng kể chi phí mua bản quyền phần mềm và nhân công để quản trị từng máy tính đơn lẻ vì tất cả các công việc này đều được xử lí tập trung tại Server. Tóm lại, với sự phát triển như vũ bão của Internet trong hơn chục năm trở lại đây đã kéo theo hàng loạt các công nghệ và dịch phát triển điển hình có thể kể đến các nền tảng mới như xuất hiện càng nhều các thiết bị di đọng chạy hệ điều hành nhúng (Smart phone, Iphone) mà trước đây có rất ít, các mạng xã hội cũng thu hút số lượng người dùng tăng lên đột biến (nhu Facebook được giới thiệu sau chỉ vài năm mà số lượng người dùng đã tăng lên hơn một tỷ người, cùng với đó cũng có rất nhiều mạng xã hội được mở ra như Google Plus,...trong Việt Nam cũng có khá nhiều mạng xã hội mới có thể kể tới như Zing Me, Yume,...) và cuối cùng một nền tảng nữa cũng không thể không nhắc tới và hứa hẹn sẽ phát triển mạnh mẽ vào tương lai là công nghệ điện toán đám mây, có thể kể đến các ứng dụng nổi bật như Google Document, Microsoft Sky live Office là các ứng dụng văn phòng trực tuyến khá phổ biến cho phép ta tạo và lưu trữ ngay trên Server mà không cần cài đặt trên Client các phần mềm văn phòng này, hay như các dịch vụ lưu trữ trực tuyến cho phép người dùng lưu trữ, chia sẻ, đồng bộ dữ liệu giữa các thiết bị di động hay máy tính cá nhân giúp ta không bao giờ bị mất dữ liệu nếu chẳng may máy tính có bị hỏng thì toàn bộ dữ liệu của ta vẫn còn an toàn trên Server mà không hề bị mất mát, các dịch vụ nổi tiếng hiện nay như Google Drive, Microsoft Sky drive, Mediafire, Box,...Sự phát triển mạnh mẽ này đặt ra hàng loạt các vấn đề nảy sinh bên cạnh sự tiện dụng của nó như vấn đề dữ liệu riêng tư cá nhân hay các tìa liệu quan trọng mang tính an ninh quốc gia có thể bị một người không có thẩm quyền

×