Luận văn Xây dựng ứng dụng Từ điển trên Pocket PC
Luận văn
Xây dựng ứng dụng Từ điển
trên Pocket PC
Lời cám ơn
Lời đầu tiên, chúng con xin gửi đến cha mẹ lòng biết ơn, sự tôn kính của chúng
con. Cha mẹ đã sinh dưỡng và không ngại khó khăn tạo mọi điều kiện tốt nhất cho
chúng con có được ngày hôm nay.
Chúng em xin chân thành cám ơn thầy Trần Đan Thư, thầy Nguyễn Trọng Tài
đã tận tâm hướng dẫn chúng em, giúp đỡ chúng em hoàn thành đề tài này.
Chúng em cũng xin cám ơn các anh chị làm việc trong phòng phát triển phần
mềm Trung tâm Tin học trường Đại học Khoa học Tự nhiên đã sẵn sàng giúp đỡ chúng
em, cung cấp các thông tin cho chúng em trong quá trình khảo sát. Chúng em cũng xin
cám ơn các thầy cô, cán bộ giảng viên trẻ đã nhiệt tình đóng góp những kinh nghiệm, ý
kiến quý báu cho chúng em.
Chúng em xin gửi lời cám ơn tất cả các quý thầy cô đã giảng dạy, cung cấp cho
chúng em vốn kiến thức quý báu suốt những năm học vừa qua.
Chúng em cám ơn khoa Công nghệ thông tin trường Đại học Khoa học Tự nhiên
đã tạo điều kiện cho chúng em thực hiện đề tài này.
Chúng tôi cũng xin cám ơn các bạn đã nhiệt tình giúp đỡ khi chúng tôi vướng
phải những khó khăn, động viên chúng tôi trong suốt quá trình thực hiện đề tài luận
văn tốt nghiệp này.
Mặc dù chúng em đã cố gắng rất nhiều để hoàn thành tốt luận văn, nhưng chắc
chắn không tránh khỏi những thiếu sót, chúng em rất mong được sự cảm thông và tận
tình giúp đỡ của quý thầy cô.
Tp. Hồ Chí Minh, 07/2004
Nhóm sinh viên thực hiện
Nguyễn Khánh Chi- Tăng Nguyễn Trung Hiếu
1
Lời mở đầu
Sau cuộc khủng hoảng trong ngành công nghệ thông tin vào đầu những năm
2000, đến nay, công nghệ sản xuất phần mềm trên thế giới và nhất là Việt Nam đang
tiến những bước tiến mạnh mẽ hơn. Vượt qua cuộc khủng hoảng này, ngoài những
kinh nghiệm trong kinh doanh, các công ty tin học Việt Nam nhận thức được rằng quy
trình sản xuất phần mềm của chính công ty họ cần được nâng cấp với mục tiêu đầu tiên
là nâng cao chất lượng, gia tăng tính chuyên nghiệp trong sản xuất phần mềm.
Một điều không thể tranh cãi , quy trình đóng một vai trò rất quan trọng trong
việc sản xuất phần mềm. Hiện nay có rất nhiều quy trình sản xuất phần mềm như Quy
trình RUP, Quy trình xoắc ốc, Quy trình thác nước.., nhưng điều cốt lõi nhất là ứng
dụng những quy trình đó như thế nào và ứng dụng như vậy sẽ đạt được những thuận lợi
gì, quá trình sản xuất phần mềm có tốt hơn không, chất lượng phần mềm có được nâng
cao hay không. Trong một quy trình sản xuất phần mềm, ngoài việc thành lập các
chuẩn coding, phân công sắp xếp các công việc cho các thành viên trong tổ chức, một
yếu tố rất quan trọng là việc quản lý các tài liệu bao gồm các bản đặc tả yêu cầu, bản
phân tích thiết kế chương trình, chương trình nguồn, các bản báo cáo kiểm thử và vô số
những tài liệu không tên khác.
Trong bối cảnh đó, chúng em đã thực hiện đề tài “Tìm hiểu về quản lý yêu cầu
và kiểm thử tại Phòng phát triển phần mềm Trung Tâm Tin Học trường
ĐHKHTN_Xây dựng phần mềm hỗ trợ” nhằm có thể hiểu rõ hơn việc quản lý yêu cầu
và kiểm thử, những mục tiêu, thuận lợi mà hai tiến trình này đem lại.
Đề tài này có thể được xem như một phần trong việc quản lý cấu hình, trong đó
chú trọng ở hai giai đoạn khảo sát và kiểm thử. Luận văn của chúng em được trình bày
với tám chương chính, bao gồm :
2
- Chương 1 Mở đầu
- Chương 2 Tổng quan về SQA (Software Quality Assurance) và các công
việc quản lý yêu cầu, quản lý kiểm thử
- Chương 3 Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử
hiện nay.
- Chương 4 Giới thiệu về ứng dụng “Phần mềm quản lý yêu cầu và quản lý
kiểm thử” (Requirements and Testing Management)
- Chương 5 Thực hiện _ Kiểm tra ứng dụng
- Chương 6 Tổng kết
3
Mục lục
Chương 1
Mở đầu................................................................................................................ 9
Khái quát vai trò quy trình phát triển phần mềm...........................................................9
Tầm quan trọng của việc quản lý quy trình .................................................................. 10
Hiện trạng phát triển phần mềm tại T3H...................................................................... 10
1.1
1.2
1.3
1.4
Đánh giá hiện trạng........................................................................................................ 19
Quản lý yêu cầu : ............................................................................................................................19
Quản lý kiểm thử :...........................................................................................................................19
1.4.1
1.4.2
1.5
Chương 2
2.1
Mục tiêu đề tài ................................................................................................................ 20
Tổng quan về SQA và các công việc quản lý yêu cầu, quản lý kiểm thử...... 21
Vai trò của việc quản lý chất lượng phần mềm ............................................................. 21
Tại sao cần quản lý chất lượng ?.................................................................................... 24
2.2
2.3
Tổng quan về quản lý yêu cầu........................................................................................ 25
Quản lý yêu cầu là gì ?....................................................................................................................25
Các thông tin cần quản lý trong quản lý yêu cầu. ..........................................................................25
Giới thiệu tiến trình RM (Requirement Management) trong CMMI...............................................27
2.3.1
2.3.2
2.3.3
2.4
Tổng quan về quản lý kiểm thử...................................................................................... 28
Mục tiêu của quản lý kiểm thử........................................................................................................28
Các thông tin cần quản lý trong quản lý kiểm thử...........................................................................29
Giới thiệu tiến trình Verification (VER) trong CMMI....................................................................30
2.4.1
2.4.2
2.4.3
Chương 3
Các công cụ hỗ trợ cho việc quản lý yêu cầu và quản lý kiểm thử hiện nay 32
3.1
Công cụ hỗ trợ quản lý yêu cầu...................................................................................... 32
Giới thiệu : ......................................................................................................................................32
Định nghĩa công cụ quản lý yêu cầu ...............................................................................................33
Các loại công cụ..............................................................................................................................33
Tại sao phải sử dụng các công cụ quản lý yêu cầu :........................................................................34
Kiến trúc chức năng : ......................................................................................................................35
So sánh với các phần mềm có chức năng tương tự : .......................................................................37
Đánh giá các công cụ quản lý yêu cầu ............................................................................................38
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.2
Công cụ kiểm thử : ......................................................................................................... 38
Các loại công cụ kiểm thử :.............................................................................................................38
Một số công cụ quản lý kiểm thử :..................................................................................................41
3.2.1
3.2.2
Chương 4
Xây dựng “Phần mềm quản lý yêu cầu và quản lý kiểm thử” (Requirements
and Testing Management)....................................................................................................... 44
4.1
4.2
4.3
Mục tiêu của ứng dụng................................................................................................... 44
Thủ tục cho các quy trình được xây dựng mới.............................................................. 44
Đặc tả yêu cầu................................................................................................................. 49
4
4.4
Thiết kế ứng dụng........................................................................................................... 51
Mô hình use case.............................................................................................................................51
Đặc tả use case................................................................................................................................52
4.4.1
4.4.2
4.5
Mô hình dữ liệu .............................................................................................................. 72
Kiến trúc hệ thống...........................................................................................................................73
Thiết kế màn hình ...........................................................................................................................77
4.5.1
4.5.2
Chương 5
Thử nghiệm ứng dụng..................................................................................... 89
5.1
Dữ liệu thử nghiệm......................................................................................................... 89
Giới thiệu project thử nghiệm : .......................................................................................................89
Bộ dữ liệu thử nghiệm :...................................................................................................................90
5.1.1
5.1.2
5.2
Kết quả thực hiện chương trình..................................................................................... 91
Tổng kết............................................................................................................ 92
Chương 6
6.1
Tự đánh giá..................................................................................................................... 92
Những kết quả đạt được :................................................................................................................92
6.1.1
6.2
Hướng phát triển của chương trình............................................................................... 93
Phụ lục ..................................................................................................................................... 95
Phụ lục A.
Phụ lục B.
Mô tả dữ liệu ................................................................................................... 95
RM Tool Survey Summary [INCOSE]............................................................ 98
5
Danh sách các hình
Hình 1-1 Mô hình phát triển phần mềm theo quy trình thác nước tại T3H.............................. 11
Hình 1-2 Sơ đồ tổ chức các vai trò của nhân sự trong 1 đề án phần mềm ............................... 14
Hình 1-3 Mô hình quản lý yêu cầu tại T3H.............................................................................. 16
Hình 1-4 Mô hình kiểm thử tại T3H......................................................................................... 18
Hình 2-1 Các hoạt động trong CM ........................................................................................... 22
Hình 2-2 Tổng quan về CM...................................................................................................... 23
Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI)............................................................. 27
Hình 5-1 Mô hình tiến trình quản lý yêu cầu cho hệ thống mới............................................... 45
Hình 5-2 Mô hình quản lý kiểm thử cho hệ thống mới ............................................................ 48
Hình 5-3 Mô hình usecase ....................................................................................................... 51
Hình 5-4 Kiến trúc hệ thống ..................................................................................................... 73
Hình 5-5 Kiến trúc Phần mềm quản lý yêu cầu và kiểm thử.................................................... 75
Hình 5-6 Các lớp xử lý yêu cầu................................................................................................ 76
Hình 5-7 Các lớp xử lý kiểm thử .............................................................................................. 76
Hình 5-8 Sơ đồ màn hình cho phần truy cập cơ sở dữ liệu ...................................................... 77
Hình 5-9 Sơ đồ các trang tổng quát .......................................................................................... 77
Hình 5-10 Sơ đồ nhóm các màn hình liên quan đến phần quản lý yêu cầu.............................. 78
Hình 5-11 Sơ đồ các màn hình liên quan đến phần kiểm thử................................................... 79
Hình 5-12 MH. Trang chính ..................................................................................................... 80
Hình 5-13 MH.Thông tin yêu cầu tổng quát............................................................................ 81
Hình 5-14 MH. Cập nhật tài liệu mô tả yêu cầu....................................................................... 82
Hình 5-15 MH. Cây kiến trúc của project ................................................................................ 83
Hình 5-16 MH. Thiết lập mối liên hệ giữa các yêu cầu và phân hệ ......................................... 84
Hình 5-17 MH. Các release trong Project................................................................................. 84
Hình 5-18 MH. Cập nhật môi trường kiểm tra. ........................................................................ 85
Hình 5-19 MH. Các release và file đã được lập testcase. ......................................................... 86
Hình 5-20 MH. Cập nhật thông tin review ............................................................................... 87
6
Thuật ngữ / Từ viết tắt / Khái niệm
Là những chương trình, những thủ tục
Phần mềm _Software
được gắn liền với các tài liệu mô tả và các
dữ liệu có liên quan đến tác vụ của một
hệ thống máy tính.[PGSQM]
Việc thỏa mãn một sản phẩm theo đúng sự
mong đợi của khách hàng, dựa vào những
yêu cầu cho sản phẩm.[PGSQM]
Chất lượng _Quality
Là một tập các hành động đã được dự
định trước đó nhằm dò tìm, dẫn chứng qua
các tài liệu, phân tích, và hiệu chỉnh các
lỗi của sản phẩm cũng như quản lý các
thay đổi của sản phẩm.[PGSQM]
Việc đảm bảo chất lượng _Quality
Assurance hay Kiểm soát chất lượng _
Quality Control
Là việc ủy nhiệm, xúc tiến nhà sản xuất
nhận ra, chấp thuận các cải tiến cho tiến
trình sản xuất sản phẩm.[PGSQM]
Quản lý chất lượng _ Quality
Management
Software Quality Assurance
SQA
SQS
CM
Software Quality System
Configuration management
T3H
Phòng phát triển phần mềm Trung tâm
Tin học trường Đại học Khoa học Khoa
học Tự nhiên.
Mỗi khi việc coding hoàn tất ở một phân
Internal release
7
hệ hay một phần cụ thể nào đó của
project, project manager hay coding
manager sẽ compile cho một bản release.
Bản release này sẽ được kiểm tra, sửa lỗi
dùng trong nội bộ cơ quan.
Release sẽ được giao cho khách hàng khi
chương trình đã hoàn tất
Release
Capability Maturity Model Integration
Requirement Management
CMMI
RM
8
Chương 1 Mở đầu
Chương 1 Mở đầu
1.1 Khái quát vai trò quy trình phát triển phần mềm
Thưở ban đầu của ngành công nghiệp máy tính nói chung và công nghệ phần
mềm nói riêng, việc phát triển phần mềm được xem như một quá trình “viết và sửa”
(code and fix), không có bất kỳ một kế hoạch nào trước đó. Quá trình này thành công
cho đến khi các chương trình phần mềm bắt đầu có quy mô lớn hơn, độ phức tạp cao
hơn, cần có sự hợp tác của nhiều người hơn, do đó các phương pháp phát triển phần
mềm hay quy trình phần mềm ra đời.Thực tế cho thấy, hầu hết các dự án thất bại do
các nguyên nhân sau 1 :
• Hiểu không đúng yêu cầu người dùng
• Không thể thích ứng với các thay đổi về yêu cầu đối với hệ thống.
• Các module không khớp với nhau.
• Phần mềm khó bảo trì và nâng cấp, mở rộng.
• Phát hiện trễ các lỗ hổng của dự án.
• Chất lượng phần mềm kém.
• Hiệu năng của phần mềm thấp.
• Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi nào, ở
đâu, tại sao phải thay đổi.
• Quá trình build-and-release không đáng tin cậy.
Để khắc phục những rủi ro này đòi hỏi việc phát triển phần mềm phải theo một
quy trình cụ thể đảm bảo phần mềm được xây dựng đảm bảo được chất lượng, thỏa
mãn các yêu cầu của người dùng.
1
[LVRUP99]
9
Chương 1 Mở đầu
1.2 Tầm quan trọng của việc quản lý quy trình
Như đã đề cập ở trên, việc thỏa mãn nhu cầu (Fitness for purpose) của người
dùng rất quan trọng, đó là đích cuối cùng cho mọi sản phẩm được sản xuất ra. Vì vậy,
việc đảm bảo chất lượng phần mềm cũng là một phần rất quan trọng trong quá trình
sản xuất phần mềm và do đó, việc quản lý chất lượng cũng được đặt ra.
Hơn thế nữa, quan điểm hiện đại về việc đảm bảo chất lượng ngày càng phức
tạp hơn, không còn giới hạn ở mục tiêu thỏa yêu cầu khách hàng. Một sản phẩm phần
mềm chất lượng cao (high quality product) phải kết hợp được nhiều nhân tố chất lượng
(quality factors) hay thuộc tính chất lượng (Quality Attributes), trong đó có thể chia
làm ba loại, đó là những nhân tố có thể tìm thấy trong đặc tả yêu cầu ví dụ như tính
linh động (portability), là “cutural factors” ví dụ như tính hiệu dụng (usability), và
những nhân tố mà người lập trình sẽ chú trọng nhưng người dùng thì không, đơn cử là
tính tái sử dụng (reusability). Để một sản phẩm đặt ra đạt được những nhân tố chất
lượng này không phải là một việc dễ dàng, vì vậy, việc quản lý chất lượng phần mềm
là một công việc không thể tránh khỏi trong công nghệ phần mềm.
1.3 Hiện trạng phát triển phần mềm tại T3H
T3H phát triển phần mềm theo quy trình thác nước bao gồm các giai đoạn sau :
• Khảo sát hiện trạng – xác định yêu cầu
• Lập giải pháp khả thi
• Phân tích
• Thiết kế
• Coding
• Kiểm thử
• Triển khai và bảo trì
Quy trình được minh họa qua sơ đồ
10
Chương 1 Mở đầu
NV quaûn lyù ñeà
aùn
Laäp keá hoaïch & theo doõi tieán ñoäâ
NV phaân tích _
thieát keá
NV quaûn trò heä
thoáng
Laäp giaûi phaùp
khaû thi
Khaûo saùt -
phaân tích
NV phaân tích _
thieát keá
NV phaân tích _
thieát keá
Thieát keá
phaàn meàm
Xaây döïng
phaàn meàm
NV laäp trình
NV phaân tích _
thieát keá
Kieåm tra & thöû
nghieäm noäi boä
NV kieåm tra
NV laäp trình
NV huaán luyeän
Trieån khai
NV huaán luyeän
NV phaân tích _
thieát keá
NV laäp trình
Hoaøn chænh saûn
phaåm
NV quaûn lyù
caáu hình
Quaûn lyù caáu hình
Hình 1-1 Mô hình phát triển phần mềm theo quy trình thác nước tại T3H
11
Chương 1 Mở đầu
MÔ TẢ CÁC GIAI ĐOẠN TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM
Gđoạn
Lập giải pháp khả thi
Khảo sát – phân tích
Tài liệu giải pháp khả thi
Thiết kế phần mềm
Xây dựng phần mềm
Kiểm tra và thử nghiệm nội
bộ
Tài liệu khảo sát phân tích
-
Tài liệu khảo sát phân tích -Tài liệu khảo sát phân tích
Tài liệu
đầu vào
- Tài liệu thiết kế phần -Tài liệu thiết kế phần mềm
mềm
-Chương trình
- Prototype chưong trình
1. Khảo sát khả thi
1. Khảo sát chi tiết
1. Thiết kế kiến trúc phần mềm
1. Thiết kế chung kỹ thuật:
- Biến dùng chung
- Thư viện hàm: các hàm - Kỹ thuật
dùng chung, các hàm hệ - Nghiệp vụ
1.Thiết kế kịch bản kiểm tra
2.Kiểm tra từng chức năng:
Mô
công việc
cụ thể
của giai
đoạn
tả
2. Mô tả và phân tích hiện 2. Mô tả và phân tích hiện trạng (chi tiết 2. Thiết kế dữ liệu mức vật lý.
trạng : chú trọng đến tính
khả thi của quy trình
nghiệp vụ sẽ được tin học
hóa.
hơn Giải pháp khả thi) :
- Quy trình nghiệp vụ
- Sơ đồ tổ chức xử lý
3. Thiết kế chiến lược:
- Các quy ước chung
- Cơ chế phát sinh khóa
- Kiểm tra RBTV
thống
3. Kiểm tra tích hợp
- Mối liên quan với hệ thống khác
- Các lớp đối tượng (hoặc 4.Chỉnh sửa các lỗi của chương
3. Xác định yêu cầu nghiệp 3. Phân tích sơ bộ
- Xử lý và thông báo lỗi
- Sao lưu và phục hồi dữ liệu
- Bảo mật
- Truyền (gửi/nhận) dữ liệu
4. Thiết kế chức năng:
- Sơ đồ màn hình
màn hình) cơ sở
2. Thiết kế chi tiết chức năng 5.Thủ nghiệm chuyển đổi từ dữ
3. Cài đặt CSDL liệu cũ
4. Lập trình và kiểm thử cục 6. Lập tài liệu hướng dẫn
bộ
trình
vụ
- Mô hình dữ liệu sơ bộ
4. Xác định yêu cầu kỹ thuật
5. Đề xuất giải pháp thực
hiện
- Kiến trúc kỹ thuật
- Vấn đề chuyển đổi, cập
nhật dữ liệu cũ
- Kinh phí
- Thời gian thực hiện
6. Thương thảo hợp đồng
- Yêu cầu nghiệp vụ
- Yêu cầu hệ thống
- Yêu cầu giao diện
- Yêu cầu sao lưu
- Yêu cầu bảo mật
- Yêu cầu đường truyền (gửi/nhận) dữ thực đơn
liệu -Màn hình
- Yêu cầu về chuyển đổi, cập nhật dữ - Báo biểu
- Màn hình chính và hệ thống
liệu cũ
- Thuật tóan xử lý chính trên các
4. Tập hợp các tài liệu đã thu thập từ quá màn hình và báo biểu
trình khảo sát
5. Xây dựng prototype chương
trình
1. Lập kế họach và theo dõi tiến độ
2. Quản lý cấu hình
Mô
công việc
tả
3. Xem xét và duyệt kết quả công việc
4. Tập huấn, chuyển giao kết quả công việc
-Tài liệu giải pháp khả Tài liệu khảo sát phân tích
thi
chung
- Tài liệu thiết kế phần mềm
- Prototype chương trình
- Tài liệu Xây dựng phần mềm
- Script phát sinh CSDL
- Chương trình
-Tài liệu Kết quả
-Kiểm tra chương trình
-Tài liệu hướng dẫn
-Chương trình đã kiểm
tra
Kết quả
đầu ra
-Hợp đồng đã ký
12
Chương 1 Mở đầu
• Các vai trò tham gia trong một quy trình phát triển phần mềm
- NVPhân tích thiết kế - Quản trị hệ thống : hoạt động chủ yếu trong giai đoạn
lập giải pháp khả thi & khảo sát phân tích, các hồ sơ, tài liệu cuối cùng được
lưu trữ chủ yếu là văn bản giấy, nếu có lưu trữ trên máy thì cũng lưu trữ trên
máy của nhân viên phụ trách.. Sau khi kết thúc quá trình khảo sát, nhân viên
ghi nhận các yêu cầu từ khách hàng, lưu lại dưới dạng document. Khi có sửa
đổi thì ghi nhận lại ngay trên document đó.
- NV Phân tích thiết kế : Khảo sát phân tích, thiết kế phần mềm lưu lại dưới
dạng các document, không theo chuẩn nhất định và cũng được sửa chồng khi
có sự thay đổi. Việc chuyển giao sang giai đoạn khác được thực hiện thông qua
việc ký nhận văn bản.
- NV Lập trình : chịu trách nhiệm lập trình, chỉnh sửa code, đưa ra các release.
Mỗi nhóm lập trình sẽ được phân công từng module cụ thể. Quản lý các phiên
bản bằng Visual Source Safe. Khi source code thay đổi sẽ phát sinh 1 phiên
bản mới, tuy nhiên nó không thể hiện được sự thay đổi này ảnh hưởng đến
những module nào. Việc phân công coding cũng được thực hiện bằng tay.
- NV Kiểm tra : Sau khi 1 module được coding xong hay đến 1 thời điểm quy
định, chương trình được test bởi nhóm NVKiểm tra. Việc kiểm tra được thực
hiện trên giấy. Khi phát hiện lỗi, nhân viên kiểm tra ghi nhận lại lỗi, và thực
hiện lặp lại cho đến hết module. Sau khi test xong một module, bảng tường
trình lỗi sẽ được gởi đến người chịu trách nhiệm đánh giá lỗi, thường là quản
lý dự án. Nếu là lỗi có thể sửa sẽ đựơc xác nhận và chuyển giao cho bộ phận
lập trình. Nếu lỗi có thể bỏ qua, người quản lý dự án sẽ xác nhận và kết thúc
việc test. (xem chi tiết mô hình bên dưới)
- NV quản lý đề án : là người có chức vụ cao nhất trong quy trình phát triển
phần mềm, quản lý toàn bộ các thành viên, chịu trách nhiệm phân công, lên kế
hoạch, theo dõi tiến độ thực hiện.
- Trưởng dự án : chịu trách nhiệm xem xét duyệt lại các tài liệu, kiểm soát các
tiến trình, đảm bảo các tiến trình được thực hiện đúng đắn và đúng tiến độ.
13
Chương 1 Mở đầu
- NV Quản lý cấu hình : chịu trách nhiệm về việc tổ chức quản lý những tài liệu
có liên quan đến đề án đang thực hiện như : quản lý các thành phần của từng
phiên bản có trong đề án, tạo các phiên bản test và phiên bản giao cho khách
hàng, đóng gói sản phẩm...
- NV Quản lý kiểm thử : chịu trách nhiệm về việc lên kế hoạch kiểm thử, cho
từng giai đoạn của đề án, đánh giá kết quả của việc kiểm thử. Và cùng với nhân
viên quản lý đề án, trưởng dự án quyết định khi nào thì ngưng việc kiểm thử
trong trường hợp chương trình vẫn còn lỗi nhưng những lỗi đó không nghiêm
trọng, có thể chấp nhận để giao cho khách hàng vì thời giao đã gần kề...
Wednesday, February 25, 2004
TRUNG TAÂM TIN HOÏC
Tröôøng ñaïi hoïc Khoa hoïc Töï nhieân
Ñaïi hoïc Quoác gia TpHCM
PHOØNG PHAÙT TRIEÅN PHAÀN MEÀM
2/25/2004
Sô ñoà caùc vai troø trong moät ñeà aùn
Subtitle
Quaûn lyù döï aùn
Tröôûng döï aùn
NV Quaûn lyù
caáu hình
NV Quaûn lyù
kieåm thöû
NV Quaûn trò heä
thoáng
NV Phaân tích
thieát keá
NV kieåm thöû
NV laäp trình
NV huaán luyeän
Hình 1-2 Sơ đồ tổ chức các vai trò của nhân sự trong 1 đề án phần mềm
Trong các quy trình phát triển trên, đề tài chú trọng đến hai tiến trình : Quản
lý yêu cầu và quản lý kiểm thử
14
Chương 1 Mở đầu
• Quản lý yêu cầu
-
Khách hàng đặt hàng, T3H đồng ý nhận đơn đặt hàng, chuẩn bị tiến
hành khảo sát
- Quản lý dự án lập kế hoạch ban đầu, đặc tả các nhiệm vụ, phân công.
Bảng kế hoạch được in giấy, phân phát cho nhân viên liên quan.
- Khảo sát viên tiến hành khảo sát, sau mỗi lần khảo sát, một bản mô tả
hiện trạng, yêu cầu khách hàng được thiết lập. Đến thời hạn, nhân
viên này đưa bản báo cáo cuối cùng cho Quản lý dự án. Khảo sát viên
hoàn toàn tự quản lý các tài liệu này và chỉ giao cho Quản lý dự án
bản cuối cùng.
- Khi tiến hành phân tích thiết kế, phân tích viên hay nhân viên thiết kế
sẽ làm việc trên tài liệu mà Quản lý dự án đưa. Nếu có thay đổi, nhân
viên đó sẽ thay đổi trên tài liệu này, ghi nhận và đến thời hạn sẽ giao
lại cho Quản lý dự án.
- Cuối giai đoạn này, một bản đặc tả yêu cầu và phân tích thiết kế được
đưa ra.
- Thông thường, khảo sát viên, nhân viên phân tích thiết kế là một và là
quản lý dự án.
Quá trình này được mô hình hóa thông qua mô hình sau :
15
Chương 1 Mở đầu
QUẢN LÝ YÊU CẨU (Hệ thống hiện tại)
Trưởng dự án
Quản lý dự án
Trưởng dự án
Khảo sát viên
Khảo sát viên
Nhận đơn đặt
hàng từ KH
Tiến hảnh khảo
sát
N
Tiếp xúc với KH
Đưa ra các yêu
cầu
Xem xét việc tiến
hành dự án
Bảng yêu cầu
(tự quản lý thông
tin)
N
Khách hàng chấp
thuận bản yêu cầu
Không thực hiện
dự án
Y
Y
Đặc tả nhiệm vụ &
phân công
Tài liệu đặc tả yêu
cầu cuối cùng
Kết thúc khảo sát
Toản bộ các tiến trình được thực hiện bằng tay. Các tài liệu được phát sinh trong giai đoạn này do người
phụ trách tự quản lý. Chỉ có bản yêu cầu cuối cùng được gửii cho các thành viên phát triển dự án
Hình 1-3 Mô hình quản lý yêu cầu tại T3H
16
Chương 1 Mở đầu
•
Quản lý kiểm thử :
-
Sau mỗi lần coding xong ra một internal release, công việc kiểm thử
được tiến hành.
-
Thông qua kinh nghiệm và kiến thức về nghiệp vụ, nhân viên kiểm tra
lập ra các bộ kiểm thử (test case) và ghi nhận lại kết quả này bằng tài
liệu kiểm thử.
-
Đến thời hạn, nhân viên này đưa lại cho trưởng bộ phận kiểm thử
(Test manager) xem xét đánh giá lỗi trên tài liệu kiểm thử và đưa lại
bản tài liệu đã được đánh giá cho người lập trình sửa lỗi.
Quá trình này được mô hình hóa bên dưới :
17
Chương 1 Mở đầu
Hình 1-4 Mô hình kiểm thử tại T3H
18
Chương 4 Đánh giá hiện trạng quản lý yêu cầu và quản lý kiểm thử tai T3H
1.4 Đánh giá hiện trạng
1.4.1 Quản lý yêu cầu :
• Hiện tại T3H làm phần mềm có quy trình, các nhân viên đều nắm được
nhưng việc thủ tục hóa từng quy trình không có, kết quả là không có một
mẫu biểu chuẩn ghi nhận lại nên thông tin có thể không nhất quán.
• Khi các yêu cầu thay đổi trong quá trình thực hiện đề án, nhân viên không
nhất thiết phải ghi lại thông tin thay đổi nên có thể họ sẽ quên một số thông
tin, điều này có thể gây ra sự bất đồng bộ trong việc thực hiện phần mềm ở
những bộ phận khác nhau.
• Đối với một công ty nhỏ như T3H chỉ gồm khoảng trên dưới 30 nhân viên thì
việc trao đổi thông tin bằng miệng như hiện nay rất dễ dàng. Khi có một
vướng mắc nào đó họ có thể hỏi ngay tại đó để làm rõ vấn đề. Nhưng đặt
trường hợp PPTPM mở rộng, phát triền hơn thì với việc quản lý như hiện
nay sẽ rất khó khăn.
• Khi yêu cầu thay đổi, yêu cầu mới được ghi chồng lên các yêu cầu cũ mà
không có sự ghi nhận rõ ràng ( người sửa, ngày sửa, nguyên nhân,…) do đó
không lưu vết được các yêu cầu, gây ra khó khăn khi cần xem xét lại tài liệu
hoặc truy cứu trách nhiệm khi yêu cầu sai.
•
Khi một yêu cầu được thay đổi người trưởng dự án không biết được yêu cầu
này ảnh hưởng đến những module nào, và khó biết yêu cầu mới có bị trùng
lặp với những yêu cầu cũ hay không.
1.4.2 Quản lý kiểm thử :
• Như phần hiện trạng đã đề cập ở trên, các test case được chính người kiểm
thử đề ra, và cũng người đó thực hiện việc kiểm tra, nên những người khác
hoàn toàn không biết về những test case này nếu nó không có xảy ra lỗi. Như
vậy các nhân viên khác khó có thể học hỏi kinh nghiệm test cũng như chưa
kể người thực hiện kiểm thử có thể quên hoặc thiếu một số trường hợp test.
19
Chương 4 Đánh giá hiện trạng quản lý yêu cầu và quản lý kiểm thử tai T3H
• Do thông tin về những lỗi không lưu lại, những lỗi xuất hiện trong đề tài nào
thì người phát triển đề tài đó biết. Đặt trường hợp nếu lỗi đó xuất hiện trong
một đề tài khác, do người khác phụ trách kiểm thử, nếu như người đó biết đã
có người gặp phải lỗi đó thì người đó có thể biết ngay cách chỉnh sửa. Nhưng
đặt trường hợp người đó không biết có người gặp phải lỗi này, thì người đó
có thể phải tự tìm tòi, chưa kể nếu lỗi đó xuất hiện nhiều lần lại phải tốn
nhiều công sức đầu tư.
• Do không quản lý phiên bản test, nên trong một sản phẩm, có những lỗi đã
được phát hiện rồi, sửa rồi, nhưng phiên bản cuối cùng lại là phiên bản cũ, có
lỗi.
• Từ việc chuyển giao các test case đến người lập trình viên để cập nhật kết
quả đến việc xem xét lại các testcase, cho đến việc kiểm và sữa chữa lỗi trải
qua nhiều giai đoạn, do đó các hồ sơ dễ bị thất lạc và không đúng phiên bản
hiện hành.
1.5 Mục tiêu đề tài
Tìm hiểu về việc quản lý yêu cầu và quản lý kiểm thử trong quá trình phát
triển phần mềm. Ứng dụng xây dựng phần mềm hỗ trợ việc quản lý yêu cầu và kiểm
thử tại T3H
• Tìm hiểu công việc quản lý yêu cầu và quản lý kiểm thử nhằm bảo đảm
chất lượng phần mềm. Trong đó, chú trọng các thông tin cần phải quản lý
trong hai tiến trình này.
• Ứng dụng những kiến thức đó, xây dựng chương trình nhằm cải tiến và
hỗ trợ công việc quản lý yêu cầu và quản lý kiểm thử tại Phòng phát triển
phần mềm, Trung tâm Tin học trường Đại học Khoa học Tự nhiên.
20
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
Chương 2 Tổng quan về SQA và các công việc quản lý yêu cầu,
quản lý kiểm thử
2.1 Vai trò của việc quản lý chất lượng phần mềm
Hệ thống quản lý chất lượng SQA hay SQS có hai mục tiêu chính :
• Đưa vào việc quản lý chất lượng ngay từ khi bắt tay vào xây dựng phần
mềm
• Đảm bảo chất lượng trong suốt quá trình xây dựng phần mềm
Để đạt được hai mục tiêu trên, SQS đòi hỏi sự kết hợp của 10 yếu tố :
• Standards : là một yếu tố mấu chốt trong SQS. Các chuẩn là nền tảng để
có thể đánh giá các hoạt động. Hơn nữa, chúng cung cấp những phương
thức thông thường mà theo đó cùng một công việc sẽ được hoàn thành
theo cùng một cách mỗi khi nó được thực hiện. Khi áp dụng các chuẩn
trong phát triển phần mềm sẽ giúp cho việc đánh giá sự phát triển được
đồng đều.
• Reviewing : là một hoạt động rất quan trọng trong kiểm soát chất lượng.
Việc kiểm soát chất lượng liên quan với việc tìm kiếm các lỗi ở nhiều loại
sản phẩm phần mềm trong suốt quá trình phát triển chúng. Nếu như việc
thanh tra mã nguồn cũng liên quan đến việc tìm lỗi thì việc kiểm duyệt lại
tỏ ra hiệu quả hơn vì nó tìm các lỗi sớm hơn.
• Testing : mục đích của việc kiểm thử là tìm các lỗi và kiểm tra lại xem
phần mềm có thỏa yêu cầu của người dùng đưa ra hay không. Trong một
số trường hợp, công việc kiểm thử lại chú trọng vào việc kiểm tra xem
phần mềm chạy đúng hay sai hơn là xem phần mềm có thỏa yêu cầu
người dùng hay không. Điều này hơi đi chệch hướng với mục đích của
việc kiểm thử chương trình. Nếu công việc kiểm thử không dựa trên mục
tiêu thỏa mãn yêu cầu thì chỉ phí thời gian.
21
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
• Defect analysing : hầu hết các tổ chức dùng thuật ngữ chất lượng
(quality) để ngụ ý không có hoặc có ít lỗi. Một số khác cho rằng đó là chỉ
việc phần mềm thỏa mong đợi của người dùng hay khách hàng. Ở đây, cả
hai quan niệm đó đều đúng. Bất cứ lúc nào, khi phần mềm không thể hiện
được như mong đợi của người dùng, lúc đó xem như một lỗi đã được bắt.
Đây có thể là trường hợp lỗi trong code, thiếu yêu cầu người dùng hay chỉ
là thiếu một hàm. Khi phát hiện ra một lỗi, công việc đòi hỏi cần thực
hiện là sửa lại cho nó đúng. Việc phân tích lỗi được thực hiện trên tất cả
các lỗi nhằm khắc phục các thiếu sót hiện tại và giảm thiểu số lượng lỗi
trong tương lai.
• Configuration management (CM) : CM đảm bảo tại bất kỳ thời điểm nào,
tình trạng của phần mềm đều được xác định rõ và có thể tái cấu trúc lại.
CM bao gồm ba yếu tố cơ bản : định danh cấu hình (configuration
identification CID), kiểm soát cấu hình (configuration control CC) và
configuration accounting (CA) tạm dịch là sự diễn giải cấu hình.
Hình 2-1 Các hoạt động trong CM
CID cung cấp một phương pháp nhằm nhận dạng sự đặc trưng và tính duy
nhất của mỗi instance (ví dụ như release, version) trong một sản phẩm
phần mềm hay một tập các sản phẩm phần mềm. Bằng cách sử dụng một
chuẩn đặt tên để định danh mỗi một instance của sản phẩm, mỗi một hồ
22
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
sơ tài liệu mới, mỗi phần mới được hoàn tất, mỗi một phần vừa được
build.
CC là một yếu tố nhằm đảm bảo bất kỳ sự thay đổi nào của một instance
đều được biết, được kiểm soát và được ghi nhận lại. CC bao gồm các hoạt
động thay đổi trong bảng kiểm soát (control board CCB) như xem xét và
kiểm soát các thay đổi đối với các tài liệu và code.
CA giữ vai trò theo vết các tình trạng của các instance sản phẩm. Điều
này ngày càng quan trọng hơn trong việc tích hợp các phần hay module
vào các hệ thống hoặc các hệ thống con. CA theo vết các thay đổi của yêu
cầu, thiết kế, kiểm thử, code, v.v...
Hình 2-2 Tổng quan về CM
• Security : Các hoạt động bảo đảm an ninh được thực hiện đối với dữ liệu
và trung tâm lưu trữ dữ liệu. Một hệ thống quản lý chất lượng tốt nhất nếu
không có trung tâm lưu trữ dữ liệu sẽ rất dễ bị hư hại hoặc phá hủy hoàn
23
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
toàn. Các tai nạn như vỡ ống dẫn nước, cháy nhà, chưa kể những trường
hợp bị hacker, viruses… Vì vậy, đảm bảo an toàn dữ liệu cũng như trung
tâm lưu trữ dữ liệu cũng là một điều cần thiết.
• Education : Việc huấn luyện hay đào tạo bảo đảm những thành viên phát
triển dự án hoặc những người sẽ sử dụng phần mềm khi nó được hoàn tất
đều có thể thực hiện công việc của họ một cách đúng đắn.
Một điều rất quan trọng trong việc đảm bảo chất lượng phần mềm là
thành viên sản xuất phải được đào tạo để có thể sử dụng nhiều công cụ
phát triển khi được yêu cầu. Vai trò của người đảm bảo chất lượng phần
mềm là xem xét những kiến thức nào sẽ cần đến trong tương lai và trang
bị những kiến thức đó cho nhân viên của mình.
• Vendor management : khi một phần mềm được hoàn tất, công việc phát
hành cũng rất quan trọng. Việc quản lý những công việc nhỏ nhặt xung
quanh việc phát triển phần mềm như liên hệ mua bản quyền các phần
mềm hỗ trợ cho việc phát triển, các phần mềm chống virus… cũng là một
yếu tố trong việc đảm bảo chất lượng.
• Safety : Mỗi đề án đều bắt buộc phải đảm bảo an toàn cho chính phần
mềm đó và cho cả hệ thống. Kế hoạch quản lý dự án nên có phần mô tả
các giải pháp bảo đảm an toàn.
• Risk management : Bất kỳ một đề án nào cũng chứa đựng nhiều loại rủi
ro, có loại rủi ro đơn giản đến những rủi ro có thể làm phá sản hoàn toàn
đề án. Do đó, rủi ro và những giải pháp cho các giải pháp đó là một phần
cần thiết trong kế hoạch quản lý dự án.
2.2 Tại sao cần quản lý chất lượng ?
• Như đã trình bày ở trên, mục tiêu đầu tiên của phần mềm là thỏa mãn yêu
cầu được đặt ra từ phía khách hàng.
• Sự thành công của một dự án phụ thuộc vào một hệ thống quản lý yêu
cầu hiệu quả.
24
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
• Các lỗi xuất phát từ đặc tả hay nhầm lẫn yêu cầu là những lỗi thường
xuyên nhất và gây tốn kém nhất trong các loại lỗi phát sinh trong quá
trình thực hiện phần mềm
• Bằng một ít kỹ năng trong quản lý nhưng ta có thể giảm đáng kể các lỗi
yêu cầu và vì vậy chất lượng phần mềm cũng được cải thiện.
2.3 Tổng quan về quản lý yêu cầu
2.3.1 Quản lý yêu cầu là gì ?
Quản lý yêu cầu là một cách tiếp cận có hệ thống nhằm suy ra, tổ chức lại, ghi
nhận ra tài liệu các yêu cầu. Đây là một tiến trình cho phép thiết lập và duy trì hợp
đồng giữa khách hàng và nhóm phát triển phần mềm khi có sự thay đổi yêu cầu trên
hệ thống.2
Ở đây, chúng tôi xin đề cập một chút về các khái niệm quan trọng trong định
nghĩa trên :
• Đầu tiên, bất kỳ ai đã từng có liên quan đến các hệ thống phần mềm phức
tạp đều nhận ra rằng việc suy ra được các yêu cầu từ khách hàng là một
kỹ năng chủ yếu trong tiến trình khảo sát và đặc tả yêu cầu khách hàng.
• Tiếp nữa, nếu một phần mềm chỉ cần hai người làm, độ mươi mười yêu
cầu thì không có vấn đề gì, nhưng một hệ thống có cả trăm, nếu không
muốn nói hàng ngàn yêu cầu, thì việc quản lý thông tin đó thực sự rất cần
thiết.
• Cuối cùng, có một điều rõ ràng là bộ óc chúng ta chỉ nhớ khoảng vài chục
thông tin, vì vậy việc ghi nhận bằng tài liệu các yêu cầu cũng cần thiết,
nhằm hỗ trợ mối liên lạc hiệu quả với khách hàng.
2.3.2 Các thông tin cần quản lý trong quản lý yêu cầu.
Tài liệu đầu tiên mà nhóm phát triển phần mềm nhận được từ khách hàng là
bản liệt kê các yêu cầu. Thông thường, tài liệu này rất trừu tượng. Bản liệt kê có hai
2 [MSR] , Chapter 2, What is requirement management ?
25
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
loại một được trình bày tổng quát, dành cho Senior Management của khách hàng,
bản thứ hai được trình bày chi tiết hơn, dành cho người trực tiếp thực hiện các công
việc đó. Cả hai tài liệu này đều quan trọng, tuy nhiên vấn đề là tài liệu này không
được tổ chức và cấu trúc hóa.
Bản liệt kê yêu cầu gồm có hai phần quan trọng nhất, đó là các yêu cầu chức
năng và yêu cầu ràng buộc. Yêu cầu chức năng mô tả hệ thống cần làm những việc
gì, trong khi đó các yêu cầu ràng buộc có thể ràng buộc về sản phẩm hay ràng buộc
trong tiến trình. Ràng buộc sản phẩm chứa đựng các thông tin, tính chất mà sản
phẩm sau khi được hoàn thành sẽ có. Ràng buộc tiến trình quy định cách mà tiến
trình phần mềm hay tập các tiến trình được thực hiện.
Tài liệu quan trọng nhất trong bất kỳ đề án nào là bản đặc tả yêu cầu. Đây là
tài liệu cơ bản cho các tiến trình sau phân tích thiết kế và đặc tả yêu cầu như : đánh
giá chi phí chi tiết, thiết kế hệ thống, cấu trúc hệ thống, lập các bộ test và soạn các
tài liệu hướng dẫn.
Bản đặc tả được phân cấp thành nhiều phần ví dụ như phân chia các hệ thống
con, đặc tả dữ liệu, các chế độ của hệ điều hành, giao diện.
Một bản đặc tả yêu cầu thường có các phần3 :
Tittle
Contents
Introduction
About this document
Glossary
System requirements
Target system environment
Customer-imposed constraints
Phần About this document : mô tả các quy ước đặt tên, phạm vi của tài liệu,
các chủ đề chính, các thành viên có liên quan, các chuẩn, cách mà bản đặc tả được
thực hiện, và cuối dùng là danh sách các đặc tả.
3 The structure of the requirements specification [SQA]
26
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
Glossary chức đựng danh sách các thuật ngữ được dùng và các định nghĩa của
chúng.
Phần chủ yếu Requirement specification bao gồm đặc tả chi tiết các yêu cầu
của hệ thống.
Target system environment : mô tả môi trường hệ thống sẽ được thiết lập.
Phần cuối cùng Customer-imposed constraints sẽ liệt kê danh sách các ràng
buộc được đưa ra từ khách hàng.
2.3.3 Giới thiệu tiến trình RM (Requirement Management) trong CMMI
CMMI (Capability Maturity Model Integration) tích hơp các tiến trình cải tiến
phần mềm, được phát hành phiên bản đầu tiên vào năm 2000. CMMI đưa ra năm
mức độ trưởng thành hay năm tầng trưởng thành theo năng lực phần mềm theo thứ
tự từ cao xuống thấp như sau : Optimizing (Tối ưu hóa), Quantitatively
Management (Được quản lý dựa vào định lượng), Defined (Được định nghĩa),
Managed (Được quản lý), Initial (Khởi động).
Hình 2-3 Năm cấp độ (tầng trưởng thành của CMMI)
27
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
Tiến trình RM nằm ở mức 2 trong 5 tầng trưởng thành của CMMI. Mục đích
của RM là quản lý những yêu cầu đặt ra cho sản phẩm, thành tố được sản sinh bởi
các đề án và nhận ra những điểm không nhất quán giữa những yêu cầu này so với
các bảng hoạch định đề án và các sản phẩm.
Các quy tắc thực tiễn chuyên biệt cho vùng tiến trình này :
• Hiểu rõ yêu cầu (Optain an understanding of Requirement), phát triển một
sự hiểu biết với những người cung cấp yêu cầu dựa trên ý nghĩa các yêu
cầu.
• Thống nhất về thực hiện yêu cầu (Obtain Commitment to Requirements)
giữa các thành viên thực hiện dự án.
• Quản lý thay đổi yêu cầu (Manage Requirement Changes) khi có sự thay
đổi phát sinh trong suốt quá trình thực hiện dự án.
• Duy trì mối liên hệ hai chiều (Mantain Bidirectional Tracebility of
Requirements) giữa các yêu cầu, hoạch định đề án và các công việc sản
xuất sản phẩm.
• Xác định mâu thuẫn giữa yêu cầu và sản phẩm công việc (Identify
Inconsistencies between Project work and Requirement ).
Các vùng tiến trình liên quan đến RM : Phát triển yêu cầu_Requirement
Development (RD), Hoạch định đề án_Project Plan (PP), Giải pháp kỹ thuật_
Technical Solution (TS), Quản lý cấu hình_Configuration Management (CM),
Theo dõi và kiểm soát đề án_Project Monitoring and Control (PMC), Quản lý
rủi ro_Risk Management (RKSM).
2.4 Tổng quan về quản lý kiểm thử
2.4.1 Mục tiêu của quản lý kiểm thử.
• Gồm có ba mục tiêu chính : quản lý testcase, lập kế hoạch test, quản lý
testscript.
• Bảo đảm tiến trình kiểm thử được thực hiện một cách đúng đắn.
28
Chương 2 Tổng quan về SQA và quản lý yêu cầu, quản lý kiểm thử
• Kiểm soát quá trình kiểm thử tốt hơn, hiệu quả hơn, phát hiện lỗi càng
sớm càng tốt.
• Theo dõi được các kịch bản kiểm thử, tránh trường hợp trùng lắp các kịch
bản cho mỗi đợt kiểm tra.
• Theo vết các lỗi, xác định tình trạng của một lỗi tại bất kỳ thời điểm nào.
2.4.2 Các thông tin cần quản lý trong quản lý kiểm thử.
Có rất nhiều tài liệu mô tả hệ thống và các tiến trình test trong giai đoạn này
bao gồm :
• Tài liệu đặc tả thiết kế test .
• Đặc tả kịch bản kiểm thử
• Thủ tục kiểm thử
• Test log
• Bảng báo cáo lỗi
• Tổng kết kiểm thử
Tài liệu đặc tả thiết kế test : đây là một trong những tài liệu mô tả cách nào
các tính năng và các nhóm tính năng liên quan được kiểm thử. Tài liệu này không
chú trọng vào bất kỳ một kịch bản kiểm thử nào, ở đây chỉ mô tả đến các thuật ngữ
dùng trong quá trình kiểm thử.
Đặc tả kịch bản kiểm thử : tài liệu này mô tả các kịch bản test thành phần.
Mỗi kịch bản kiểm thử được đánh mã duy nhất. Trong kịch bản kiểm thử còn có :
Test input : bao gồm danh sách các dữ liệu được dùng cho việc kiểm thử.
Nếu dữ liệu được lưu trong một file thì tên file đó phải được nêu.
Test output : Kết quả mong đợi sau khi kiểm tra.
Yêu cầu về cứng và phần mềm : mô tả những yêu cầu cho phần cứng và phần
mềm để thực hiện kịch bản kiểm tra bao gồm cả những phần mềm hay công cụ hỗ
trợ việc kiểm tra và phiên bản hệ điều hành, các phiên bản các phần mềm hỗ trợ
khác.
29
Tải về để xem bản đầy đủ
105 trang
29/04/2025
130
Bạn đang xem 30 trang mẫu của tài liệu "Luận văn Xây dựng ứng dụng Từ điển trên Pocket PC", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- luan_van_xay_dung_ung_dung_tu_dien_tren_pocket_pc.pdf
