Kiểm thử và tiêu chuẩn, quy trình đánh giá chất lượng phần mềm quân sự

Qui trình kiểm thử phần mềm Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà cókhả năng phát hiện lỗi cao.. Một số kỹ thuật kiểm thử 2.4.1 Kỹ thuật kiềm thử hộp trắ

ĐẠI HỌC THÁI NGUYÊN

ĐẠI HỌC CÔNG NGHỆ THÔNG TIN & TRUYỀN THÔNG

LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

NGƯỜI HƯỚNG DẪN KHOA HỌC

TS BÙI VĂN THANH

Thái Nguyên 4 - 2014

LỜI CAM ĐOAN

Tôi xin cam đoan: luận văn “Kiểm thử và tiêu chuẩn, quy trình đánh giá chất lượng phần mềm quân sự” là công trình nghiên cứu của cá nhân tôi,

các nội dung nghiên cứu và trình bày trong luận văn trung thực, rõ ràng.

LỜI CẢM ƠN

Tôi xin cảm ơn Trường Đại học Công nghệ thông tin và Truyền thông - Đạihọc Thái Nguyên đã tạo điều kiện thuận lợi cho tôi hoàn thành khóa học và khóaluận này

Tôi xin gửi lời cảm ơn chân thành nhất tới TS Bùi Văn Thanh, Thầy đã cho

tôi những định hướng nghiên cứu, giúp đỡ tôi trong suốt thời gian hoàn thành luậnvăn này

Để hoàn thành khóa học còn có công sức vô cùng to lớn của các thầy, cô đãnhiệt tình giảng dạy, trang bị cho tôi những kiến thức quý báu trong thời gian họctập tại trường

Cảm ơn các bạn trong lớp đã nhiệt tình giúp đỡ trong suốt thời gian học tậptại trường

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN iii

LỜI NÓI ĐẦU 1

CHƯƠNG 1: TỔNG QUAN 3

1 Đặc thù của phần mềm dùng trong quân sự 3

1.1 Các lĩnh vực có ứng dụng công nghệ thông tin trong quân sự 3

1.2 Đặc thù của phần mềm dùng trong quân sự 3

2 Khái quát về phần mềm và kiểm thử phần mềm 4

2.1 Sản phẩm phần mềm và kiểm thử phần mềm 4

2.1.1 Sản phẩm phần mềm là gì? 4

2.1.2 Thế nào là lỗi phần mềm? 6

2.1.3 Tại sao lỗi phần mềm xuất hiện? 6

2.1.4 Chi phí cho việc sửa lỗi 7

2.1.5 Kiểm thử phần mềm là gì? 8

2.2 Chất lượng phần mềm 8

2.3 Qui trình kiểm thử phần mềm 9

2.4 Một số kỹ thuật kiểm thử 11

2.4.1 Kỹ thuật kiềm thử hộp trắng (White-Box Testing) 11

2.4.2 Kiểm thử đường dẫn cơ sở (Basic Path Testing) 13

2.4.3 Kỹ thuật kiểm thử hộp đen (Black-Box Testing) 13

2.4.3.1 Phân hoạch tương đương 14

2.4.3.2 Phân tích giá trị biên (BVA - Boundary Value Analysis) 15

2.4.3.3 Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph) 16

2.4.3.4 Kiểm thử so sánh 19

2.4.4 Đoán lỗi 20

CHƯƠNG 2: BỘ TIÊU CHUẨN ĐÁNH GIÁ CHẤT LƯỢNG PHẦN MỀM 21

1 Tiêu chuẩn về chức năng 21

1.1 Mục đích 21

1.2 Các tài liệu liên quan 21

1.3 Căn cứ đánh giá 21

1.4 Định nghĩa 21

1.5 Trách nhiệm 22

1.6 Nội dung thực hiện 22

1.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 22

1.6.2 Thực hiện việc đánh giá 23

2 Tiêu chuẩn TIN CẬY 27

2.1 Mục đích 27

2.2 Các tài liệu liên quan 27

2.3 Căn cứ đánh giá 27

2.4 Định nghĩa 28

2.5 Trách nhiệm 28

2.5.1 Đối với đơn vị sản xuất phần mềm 28

2.5.2 Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM có sẵn trên thị trường 28

2.5.3 Đối với đơn vị đánh giá 28

2.6 Nội dung thực hiện 28

2.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 29

2.6.2 Thực hiện việc đánh giá 29

3 Tiêu chuẩn Tính khả dụng 34

3.1.Mục đích 34

3.2 Các tài liệu liên quan 34

3.3 Căn cứ đánh giá 34

3.4 Định nghĩa 34

3.5 Trách nhiệm 35

3.5.1 Đối với đơn vị sản xuất phần mềm 35

3.5.2 Đối với đơn vị đánh giá 35

3.6 Nội dung thực hiện 35

3.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 35

3.6.2 Thực hiện việc đánh giá 36

4 Tiêu chuẩn HIỆU QUẢ 40

4.1 Mục đích 40

4.2 Các tài liệu liên quan 40

4.3 Căn cứ đánh giá 40

4.4 Định nghĩa 40

4.5 Trách nhiệm 41

4.5.1 Đối với đơn vị sản xuất phần mềm 41

4.5.2 Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM có sẵn trên

thị trường 41

4.5.3 Đối với đơn vị đánh giá 41

4.6 Nội dung thực hiện 41

4.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 41 4.6.2 Thực hiện việc đánh giá 41

5 Tiêu chuẩn cập nhật bảo trì 43

5.1 Mục đích 43

5.2 Các tài liệu liên quan 43

5.3 Căn cứ đánh giá 44

5.4 Định nghĩa 44

5.5 Trách nhiệm 44

5.5.1 Đối với đơn vị sản xuất phần mềm 44

5.5.2 Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM có sẵn trên thị trường 45

5.5.3 Đối với đơn vị đánh giá 45

5.6 Nội dung thực hiện 45

5.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 45 5.6.2 Thực hiện việc đánh giá 45

6 Tiêu chuẩn phát triển hệ thống 49

6.1 Mục đích 49

6.2 Các tài liệu liên quan 49

6.3 Căn cứ đánh giá 50

6.4 Định nghĩa 50

6.5 Trách nhiệm 50

6.5.1 Đối với đơn vị sản xuất phần mềm 50

6.5.2 Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM có sẵn trên thị trường 50

6.5.3 Đối với đơn vị đánh giá 51

6.6 Nội dung thực hiện 51

6.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 51 6.6.2 Thực hiện việc đánh giá 51

7 Tiêu chuẩn an toàn bảo mật 57

7.1 Mục đích 57

7.2 Các tài liệu liên quan 57

7.3 Căn cứ đánh giá 58

7.4 Định nghĩa 58

7.5 Trách nhiệm 58

7.5.1 Đối với đơn vị sản xuất phần mềm 58

7.5.2 Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM 58

7.5.3 Đối với đơn vị đánh giá 58

7.6 Nội dung thực hiện 58

7.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 58 7.6.2 Thực hiện việc đánh giá 59

8 Tiêu chuẩn chuyển giao và bảo hành sản phẩm 60

8.1 Mục đích 60

8.2 Các tài liệu liên quan 60

8.3 Đối với đơn vị sản xuất phần mềm 608.3.1 Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM có sẵn trên thị trường 618.3.2 Đối với đơn vị đánh giá 618.4 Nội dung thực hiện 618.4.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá 618.4.2 Thực hiện việc đánh giá 61CHƯƠNG 3: QUY TRÌNH ĐÁNH GIÁ CHẤT LƯỢNG SẢN PHẨM PHẦNMỀM 68

1 Mô hình TCCL-SPPM ISO 9126-1 68

2 Quy trình tổng quát đánh giá chất lượng sản phẩm phầm mềm: TCLPM-04 69

3 Mô hình chất lượng sản phẩm phần mềm quản lý cơ sở dữ liệu TCDL - 200471

4 Kết quả áp dụng thử 75KẾT LUẬN 79TÀI LIỆU THAM KHẢO 80

LỜI NÓI ĐẦU

Kiểm thử phần mềm là một hoạt động giữ vai trò rất quan trọng để bảo đảmchất lượng phần mềm và là hoạt động mang tính sống còn trong các dự án sản xuấthoặc gia công phần mềm Vì vậy, kiểm thử phần mềm đã trở thành qui trình bắtbuộc trong các dự án phát triển phần mềm trên thế giới Ở Việt Nam, ngành côngnghiệp phần mềm đang phát triển thì không thể xem nhẹ việc kiểm thử phần mềm

vì xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm có uy tínđều đặt ra yêu cầu nghiêm ngặt là nếu một phần mềm không có tài liệu kiểm thử đikèm thì sẽ không được chấp nhận Tuy nhiên, hoạt động kiểm thử thường gặp nhiềukhó khăn:

* Thứ nhất, kiểm thử các hệ thống phức tạp đòi hỏi rất nhiều nguồn tàinguyên và chi phí cao

* Thứ hai, tiến trình phát triển phần mềm luôn trải qua nhiều hoạt động biếnđổi thông tin, sự mất mát thông tin trong quá trình biến đổi là yếu tố chính làm chohoạt động kiểm thử khó khăn

* Thứ ba, kiểm thử chưa được chú trọng trong đào tạo con người

* Cuối cùng, không tồn tại kỹ thuật kiểm thử cho phép khẳng định một phầnmềm hoàn toàn đúng đắn hay không chứa lỗi

Kiểm thử phần mềm là một hoạt động giữ vai trò rất quan trọng để bảo đảm chấtlượng phần mềm và là hoạt động mang tính sống còn trong các dự án sản xuất hoặcgia công phần mềm Vì vậy, kiểm thử phần mềm đã trở thành qui trình bắt buộctrong các dự án phát triển phần mềm trên thế giới Ở Việt Nam, ngành công nghiệpphần mềm đang phát triển thì không thể xem nhẹ việc kiểm thử phần mềm vì xácsuất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm có uy tín đều đặt

ra yêu cầu nghiêm ngặt là nếu một phần mềm không có tài liệu kiểm thử đi kèm thì

sẽ không được chấp nhận

Chất lượng sản phẩm phần mềm đã và đang được quan tâm bởi nhiều tổ chức

và chính phủ đặc biệt là trong lĩnh vực quốc phòng – quân sự của các nước trên thếgiới Thời gian gần đây, kiểm thử và đánh giá chất lượng phần mềm là lĩnh vực

được Bộ Quốc phòng quan tâm đặc biệt trong quá trình xây dựng các phần mềmphục vụ trực tiếp cho các hoạt động quân sự Tuy nhiên việc xây dựng phần mềmtrong lĩnh vực quốc phòng - quân sự còn có nhiều bất cập và hạn chế, là một vấn đềđược đề cập nhưng chưa được giải quyết trọn vẹn do chưa có một tiêu chuẩn chínhthức về chất lượng SPPM cũng như đánh giá chất lượng SPPM

+ Phần mềm dùng trong quân sự được sản xuất với tiêu chuẩn tự do, xâydựng theo nhiệm vụ, đặc thù riêng của từng đơn vị, quá trình sử dụng là thước đocủa chất lượng

Xuất phát từ những vấn đề nêu trên việc đề xuất xây dựng bộ tiêu chuẩn vàquy trình đánh giá chất lượng phần mềm quân sự là vấn đề cấp bách để tạo nền tảngthống nhất cho công tác xây dựng phần mềm trong quân đội

CHƯƠNG 1 TỔNG QUAN

1 Đặc thù của phần mềm dùng trong quân sự

1.1 Các lĩnh vực có ứng dụng công nghệ thông tin trong quân sự

Để quân đội thực hiện tốt nhiệm vụ bảo vệ tổ quốc, đánh thắng các cuộcchiến tranh xâm lược của các thế lực thù địch bảo vệ toàn vẹn lãnh thổ, lãnh hảithiêng liên của tổ quốc, quân đội cần được hiện đại hóa các vũ khí, khí tài, mộttrong những lĩnh vực được ưu tiên phát triển đó là ứng dụng công nghệ thông tintrong các hoạt động quân sự Các lĩnh vực có ứng dụng là: quản lý, điều hành cáchoạt động tác chiến thống qua các hệ thống kỹ thuật (mạng máy tính, thông tin liênlạc, vệ tinh, ); ổn định bắn trên xe tăng thế hệ cũ đã được cải tiến; điều khiển vũkhí phòng không; các tầu hải quân và hoạt động tác chiến trên biển; dây chuyền sảnxuất vũ khí bộ binh; ngành công nghiệp đóng tàu chiến; phục vụ quản lý chỉ huyđiều hành hàng ngày; truyền số liệu quân sự; cổng thông tin điện tử Bộ Quốcphòng

1.2 Đặc thù của phần mềm dùng trong quân sự

Phần mềm quân sự là phần mềm được gia công theo từng nhiệm vụ cụ thểphục vụ cho các hoạt động chỉ huy, quản lý, các hoạt động tác chiến của quân đội

Nó được chia làm các loại sau:

- Phần mềm quản lý: quản lý cán bộ, quản lý đảng viên, quản lý tài chính,quản lý học viên, quản lý kho v.v

- Phần mềm tác chiến: phần mềm trợ giúp người chỉ huy trong tác chiến(phần mềm bản đồ số 2D, phần mềm tác chiến trên bản đồ, phần mềm truyền tin )

- Phần mềm điều khiển các hệ thống vũ khí: điều khiển bay, điều khiển ra đa,điều khiển tên lửa, điều khiển trên tầu chiến

- Phần mềm mô phỏng: phần mềm mô phỏng nhằm giảm bớt các chi phítrong các hoạt động huấn luyện các kỹ năng chiến đấu của quân đội

Và một số phần mềm khác phục vụ cho các trợ giúp tính toán tầm bắn phục

vụ cho pháo binh, bia điện tử

Phần mềm ứng dụng dùng trong quân sự đòi hỏi phải có thời gian nhanh,chính xác, an toàn bảo mật cao hỗ trợ kịp thời cho các hoạt động chỉ huy, quản lý,điều hành hàng ngày của các đơn vị trong quân đội, là thành phần quan trọng trong

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 tagọ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ủaquá 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

Giai đoạn

Phần tích yêu cầu

Thiết

kế sơ bộ

Thiết

kế chi tiết

Lập trình

và kiểm thử đơn vị

Tích hợp và kiểm thử tích hợp

Theo một tài liệu khác [4], chi phí liên quan từng giai đoạn của vòng đời phần mềmnhư sau:

Các giai đoạn phát triển Tỷ lệ Giai đoạn sản phẩm Tỷ lệ

Phân tích yêu cầu 3% Vận hành và bảo trì 67%

Hình 1.1 - Sản phẩm phần mềm

- Sai: Sản phẩm được xây dựng khác với đặc tả. 

- Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩmđược xây dựng

- Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùngchấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi

Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu, khó

sử dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm hoạt động không đúng

2.1.3 Tại sao lỗi phần mềm xuất hiện?

Khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do

lập trình Nhiều nghiên cứu đã được thực hiện trong các dự án từ rất nhỏ đến các dự

án rất lớn và kết quả luôn giống nhau, số lỗi do đặc tả gây ra là nhiều nhất, chiếmkhoảng 80% (hình 1.2) Có một số nguyên nhân làm cho đặc tả tạo ra nhiều lỗi nhất.Trong nhiều trường hợp, đặc tả không được viết ra Các nguyên nhân khác có thế dođặc tả không đủ cẩn thận, nó hay thay đổi, hoặc do chưa phối hợp tốt trong toàn

nhóm phát triển Sự thay đổi yêu cầu của khách hàng cũng là nguyên nhân dễ gây ra

Hình 1.2 Nguyên nhân gây lỗi phần mềm

lỗi phần mềm Khách hàng thay đổi yêu cầu không cần quan tâm đến những tácđộng sau khi thay đổi yêu cầu như phải thiết kế lại, lập lại kế hoạch, làm lại nhữngviệc đã hoàn thành Nếu có nhiều sự thay đổi, rất khó nhận biết hết được phần nàocủa dự án phụ thuộc và phần nào không phụ thuộc vào sự thay đổi Nếu không giữđược vết thay đổi rất dễ phát sinh ra lỗi.

Nguồn gây ra lỗi lớn thứ hai là thiết kế Đó là nền tảng mà lập trình viên dựavào để nỗ lực thực hiện kế hoạch cho phần mềm

Lỗi do lập trình gây ra cũng khá dễ hiểu Ai cũng có thể mắc lỗi khi lập trình.Thời kì đầu, phát triển phần mềm có nghĩa là lập trình, công việc lập trình thì nặngnhọc, do đó lỗi do lập trình gây ra là chủ yếu Ngày nay, công việc lập trình chỉ làmột phần việc của quá trình phát triển phần mềm, cộng với sự hỗ trợ của nhiều công

cụ lập trình cao cấp, việc lập trình trở nên nhẹ nhàng hơn, mặc dù độ phức tạp phầnmềm lớn hơn rất nhiều Do đó, lỗi do lập trình gây ra cũng ít hơn Tuy nhiên,nguyên nhân để lập trình tạo ra lỗi lại nhiều hơn Đó là do độ phức tạp của phầnmềm, do tài liệu nghèo nàn, do sức ép thời gian hoặc chỉ đơn giản là những lỗi

“không nói lên được” Một điều cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặtlập trình nhưng thực ra lại do lỗi của đặc tả hoặc thiết kế

Một nguyên nhân khác tạo ra lỗi là do bản thân các công cụ phát triển phầnmềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch,

2.1.4 Chi phí cho việc sửa lỗi

Theo tài liệu trích dẫn của Martin và McCable [7], bảo trì là phần chi phíchính của phần mềm vả kiểm thử là hoạt động chi phí đắt thứ hai, ước tính khoảng40% (15/33) chi phí trong quá trình phát triển ban đầu của sản phẩm phần mềm.Kiểm thử cũng là phần chi phí chính của giai đoạn bảo trì do phải tiến hành kiểmthử lại những thay đổi trong quá trình sửa lỗi và đáp ứng yêu cầu người dùng

Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòngđời phần mềm Tuy nhiên chi phí

cho việc tìm và sửa lỗi tăng một

cách đáng kể trong quá trình phát

triển

Trong tài liệu Boehm [5],

có trích dẫn kết quả nghiên cứu

của IBM, GTE và TRW, tổng kết

rằng lỗi được phát hiện càng

muộn thì chi phí cho việc sữa lỗi

càng lớn Chi phí tăng theo hàm mũ (Hình 1.3) Hình 1.3 - Chi phí sửa

lỗi theo thòi gian phát hiện lỗi

2.1.5 Kiểm thử phần mềm là gì?

Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được pháthiện Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ ra lỗi Kiểm thử phầnmềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó

có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không

Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm mộtcách sớm nhất và đảm bảo rằng lỗi đã được sửa, mà kiểm thử phần mềm không làmcông việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi

Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệthống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công sức

và chi phí

2.2 Chất lượng phần mềm

Chất lượng phần mềm là một khái niệm đa chiều, không dễ định nghĩa đơngiản theo cách chung cho các sản phẩm là: “Sản phẩm được phát triển phù hợp vớiđặc tả của nó [8] Có một số vấn đề khó trong hệ thống phần mềm, đó là:

- Đặc tả phải định hướng theo những đòi hỏi về chất lượng của khách hàng(như tính hiệu quả, độ tin cậy, tính dễ hiểu, tính bảo mật, ) và những yêu cầu củachính tổ chức phát triển phần mềm vốn không có trong đặc tả (như các yêu cầu vềkhả năng bảo trì, tính sử dụng lại, )

- Một số yêu cầu về chất lượng cũng rất khó chỉ ra một cách rõ ràng. 

- Những đặc tả phần mềm thường không đầy đủ và hay mâu thuẫn

Hình 1.4 - Kiểm thử phần mềm trong một số ngữ cảnh

Trên quan điểm qui trình, kiểm thử phần mềm là một phần của xác minh vàthẩm định phần mềm Xác minh và thẩm định nằm trong công nghệ phần mềm,công nghệ phần mềm lại là một phần của công nghệ hệ thống (Hình 1.4a) Nhìn từngữ cảnh chất lượng (Hình 1.4b), kiểm thử phần mềm cũng là một phần của xácminh và thẩm định phần mềm, nên cũng có thể xem như là một phần của đảm bảochất lượng phần mềm Nếu phần mềm là thành phần của hệ thống lớn hơn thì kiểmthử phần mềm cũng được xem như là một phần của quản lý và đảm bảo chất lượng

Và để đạt phần mềm chất lượng cao, thì kiểm thử có thể coi là một thành phần chủyếu của hoạt động đảm bảo chất lượng phần mềm

2.3 Qui trình kiểm thử phần mềm

Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà cókhả năng phát hiện lỗi cao Để cho việc kiểm thử đạt được kết quả tốt cần có sựchuẩn bị về kế hoạch kiểm thử, thiết kế các trường hợp kiểm thử và các dữ liệukiểm thử cho các trường hợp Đây chính là đầu vào cho giai đoạn kiểm thử Vàsản phẩm công việc của giai đoạn kiểm thử chính là “báo cáo kiểm thử” mà tài

liệu hóa tất cả các trường hợp kiểm thử đã chạy, dữ liệu đầu vào, đầu ra mongđợi, đầu ra thực tế và mục đích của kiểm thử (như Hình 1.5)

Hình 1.5 - Giai đoạn kiểm thử trong xử lý phần mềm

Qui trình kiểm thử bao gồm một số giai đoạn:

- Lập kế hoạch kiểm thử Bước đầu tiên là lập kế hoạch cho tất cả các hoạtđộng sẽ được thực hiện và các phương pháp được sử dụng Các chuẩn IEEE baogồm các thông tin về tác giả chuẩn bị kế hoạch, danh sách liệt kê của kế hoạch kiểmthử vấn đề quan trọng nhất đối với kế hoạch kiểm thử [6,7]:

+ Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu củacác hoạt động kiểm thử

+ Các tài liệu tham khảo

- Thiết kế các trưởng hợp kiểm thử Các trường hợp kiểm thử là các đặc tảđầu vào cho kiểm thử và đầu ra mong đợi của hệ thống cùng với các câu lệnh đượckiểm thử.

+ Các phương pháp hộp đen để kiểm thử dựa trên chức năng

+ Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong

- Xử lý đo lường kiểm thử bằng cách thu thập dữ liệu

- Đánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng pháthành được chưa?

Mô hình chung của qui trình kiểm thử phần mềm (Hình 1.6)

Hình 1.6 - Qui trình kiểm thử phần mềm

2.4 Một số kỹ thuật kiểm thử

2.4.1 Kỹ thuật kiềm thử hộp trắng (White-Box Testing)

Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tracấu trúc bên trong của phần mềm với mục đích đảm bảo rằng tất cả các câu lệnh vàđiều kiện sẽ được thực hiện ít nhất một lần

Hộp trắng đúng nghĩa phải gọi là hộp trong suốt Chính vì vậy, kỹ thuật này còn cómột số tên khác là kiểm thử hộp thuỷ tinh (Glass-Box Testing), hay kiểm thử hộptrong suốt (Clear-Box Testing) Người kiểm thử truy nhập vào mã nguồn chươngtrình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử

Tương tự như vấn đề kiểm thử đầu vào trong kỹ thuật kiểm thử hộp đen, đó là vấn

đề kiểm thử các đường dẫn lệnh trong kỹ thuật hộp trắng Nếu phải thực hiện tất cảcác đường dẫn của lưu trình điều khiển trong chương trình thông qua việc chạy tất cảcác trường hợp kiểm thử thì có thể nói rằng chương trình đã được kiểm thử triệt để.Tuy nhiên điều đó không thể thực hiện được vì số đường dẫn logic khác nhau trongmột chương trình là cực kỳ lớn Ví dụ trong hình 2.2, sơ đồ khối của một chu trìnhđiều khiển Sơ đồ biểu diễn một vòng lặp từ 1 đến 20 lần Trong thân của vòng lặp cómột tập các lệnh điều kiện rẽ nhánh lồng nhau, số đường dẫn trong vòng lặp là 5 Nhưvậy, tổng số đường dẫn có thể là (5 + 52 + 53 + + 520) khoảng xấp xỉ 1014

Ngoài những điều bất khả thi như trên, chương trình cũng có thể còn nhiều lỗi

do các nguyên nhân khác Đây chính là nhược điểm của kỹ thuật kiểm thử hộp trắng

- Việc kiểm thử bằng kỹ thuật hộp trắng không thể đảm bảo rằng chươngtrình đã tuân theo đặc tả

- Một chương trình sai do thiếu đường dẫn Việc kiểm thử hộp trắng khôngthể biết được sự thiếu sót này

- Việc kiểm thử bằng kỹ thuật hộp trắng không thể phát hiện được lỗi do dữ liệu.Như vậy, việc kiểm thử chỉ dùng kỹ thuật hộp trắng là không đủ để phát hiệnlỗi Vì vậy, khi thiết kế các trường hợp kiểm thử thường cần phải kết hợp với cả kỹthuật kiểm thử hộp đen

Nguyên tắc của kỹ thuật kiểm thử hộp trắng là:

- Thực hiện mọi đường dẫn độc lập ít nhất một lần. 

- Thực hiện mọi điều kiện logic (if-then-else) trên các giá trị true và false của chúng

- Thực hiện mọi vòng lặp (các vòng lặp for, while-do) tại các biên và trongphạm vi hoạt động của chúng

- Thực hiện mọi cấu trúc dữ liệu bên trong để đảm bảo tính hợp lệ của chúng

Hình 2.1- Ví dụ chu trình điều khiển

2.4.2 Kiểm thử đường dẫn cơ sở (Basic Path Testing)

Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do TomMcCabe đề xuất Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợpkiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép

đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện.Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở Các trường hợpkiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần

g quá trình kiểm thử

2.4.3 Kỹ thuật kiểm thử hộp đen (Black-Box Testing)

Kỹ thuật kiểm thử hộp đen còn được gọi là kiểm thử hướng dữliệu (data-driven) hay là kiểm thử hướng vào/ra (input/outputdriven)

Trong kỹ thuật này, người kiểm thử xem phần mềm như là mộthộp đen Người kiểm thử hoàn toàn không quan tâm cấu trúc vàhành vi bên trong của phần mềm Người kiểm thử chỉ cần quan tâm đến việc tìmcác hiện tượng mà phần mềm không hành xử theo đúng đặc tả của nó Và vì thế, dữliệu kiểm thử sẽ xuất phát từ đặc tả

Như vậy, cách tiếp cận kiểm thử hộp đen tập trung vào các yêu cầu chứcnăng của phần mềm Kiểm thử hộp đen cho phép các kỹ sư kiểm thử xây dựng cácnhóm giá trị đầu vào mà sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chươngtrình Kiểm thử hộp đen không thay thế kỹ thuật hộp trắng, nhưng nó bổ sung khảnăng phát hiện các lớp lỗi khác với các phương pháp hộp trắng

Kiểm thử hộp đen cố gắng tìm các loại lỗi sau:

- Các chức năng thiếu hoặc không đúng

- Các lỗi giao diện

- Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài

cả các lỗi trong chương trình thì điều kiện bắt buộc là phải kiểm thử tất cả các đầuvào, tức là mỗi một điều kiện đầu vào có thể có là một trường hợp kiểm thử Bởi vìnếu chỉ kiểm thử một số điều kiện đầu vào thì không đảm bảo được chương trình đãhết lỗi Tuy nhiên, điều này thực tế không thể thực hiện được

2.4.3.1 Phân hoạch tương đương

Như đã trình bày, việc kiểm thử tất cả các đầu vào của chương trình là không thể

Vì thế, khi kiểm thử chương trình nên giới hạn một tập con tất cả các trường hợpđầu vào có thể có

Một tập con như vậy cần có hai tính chất:

- Mỗi trường hợp kiểm thử nên gồm nhiều điều kiện đầu vào khác nhau cóthể để giảm thiểu tổng số các trường hợp cần thiết

- Nên cố gắng phân hoạch các miền đầu vào của một chương trình thành một

số xác định các lớp tương đương, sao cho có thể giả định hợp lý rằng việc kiểm thửmột giá trị đại diện của mỗi lớp là tương đương với việc kiểm thử một giá trị bất kỳtrong cùng lớp Hai vấn đề xem xét ở trên tạo thành một phương pháp của kỹ thuậthộp đen và gọi là phân hoạch tương đương, vấn đề thứ hai được sử dụng để pháttriển một tập các điều kiện cần quan tâm phải được kiểm thử vấn đề thứ nhất được

sử dụng để phát triển một tập cực tiểu các trường hợp kiểm thử phủ các điều kiệntrên.

Thiết kế trường hợp kiểm thử bằng phân hoạch tương đương được xử lý theohai bước: phân hoạch các miền đầu vào/ra thành các lớp tương đương, và thiết kếcác trường hợp kiểm thử đại diện cho mỗi lóp

2.4.3.2 Phân tích giá trị biên (BVA - Boundary Value Analysis)

Khi thực hiện việc kiểm thử phần mềm theo dữ liệu, chúng ta kiểm tra xemđầu vào của người dùng, kết quả nhận được và kết quả tạm thời bên trong có được

xử lý chính xác hay không

Các điều kiện biên là tình trạng trực tiếp ở phía trên và dưới của các lớptương đương đầu vào và lớp tương đương đầu ra Việc phân tích các giá trị biênkhác với phân hoạch tương đương theo hai điểm:

- Từ mỗi lớp tương đương, phân hoạch tương đương sẽ chọn phần tử bất kỳlàm phần tử đại diện, trong khi việc phân tích giá trị biên sử dụng một hoặc một sốphần tử Như vậy, mỗi biên của lớp tương đương chính là đích kiểm thử

- Không chỉ chú ý tập trung vào những điều kiện đầu vào, các trường hợpkiểm thử cũng được suy ra từ việc xem xét các kết quả ra (tức các lớp tương đươngđầu ra)

Rất khó có thể có thể liệt kê hết các hướng dẫn cụ thể cho các trường hợp.Tuy nhiên, cũng có một số nguyên tắc phân tích giá trị biên như sau:

1 Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, các trườnghợp kiểm thử sẽ được thiết kế với giá trị a và b, và các giá trị sát trên và sát dưới a

và b

2 Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợpkiểm thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cực tiểu Các giá trịsát trên và dưới giá trị cực đại, cực tiểu cũng được kiểm thử

3 Nguyên tắc 1 và 2 được áp dụng cho các điều kiện đầu ra

4 Nếu cấu trúc dữ liệu chương trình bên trong được qui định các biên (chẳnghạn, mảng được định nghĩa giới hạn 100 mục), tập trung thiết kế trường hợp kiểmthử để thực thi cấu trúc dữ liệu tại biên của nó.

Ngoài ra, người kiểm thử có thể sử dụng sự xét đoán và sáng tạo của mình đểtìm các điều kiện biên

Tóm lại, chúng ta phải kiểm thử mỗi biên của một lớp tương đương về tất cảcác phía Một chương trình nếu vượt qua những trường hợp kiểm thử đó có thể vượtqua các kiểm thử khác từ lớp đó

2.4.3.3 Kỹ thuật đồ thị nhân-quả (Cause-Effect Graph)

Trong nhiều trường hợp, việc cố gắng chuyển một chính sách hoặc một thủtục trong ngôn ngữ tự nhiên vào phần mềm dẫn đến sự thất bại và các vấn đề khóhiểu Đồ thị nhân - quả là một phương pháp thiết kế trường hợp kiểm thử trên cơ sởđưa ra một sự mô tả súc tích các điều kiện logic và các hành vi kèm theo

Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân vàkết quả cho thành phần phần mềm Mỗi nguyên nhân được biểu diễn như một điềukiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào Mỗi kết quả đượcbiểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho nhữngthành phần vừa thực hiện

Đồ thị nhân - quả được tạo như sau:

- Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) được liệt

kê dựa trên đặc tả và được định danh cho mỗi nhân - quả

- Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (các đầura) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic

- Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyên nhân vàkết quả Dữ liệu kiểm thử được sinh ra dựa trên các qui tắc trong các bảng này.Các ký hiệu được đơn giản hoá sử dụng trong đồ thị nhân quả, gồm các phần tử mô

tả như bảng 2.1

Bảng 2.1 - Các ký hiệu trong đồ thị nhân quả

Các qui tắc trong bảng quyết định được mô tả như sau:

Qui tắc Tên bảng: cho biết tên logic Tên bảng 1 2 … n Qui tắc: đánh số để phân biệt các qui tắc quyết

Điều kiện 1 Y Y Y định logic

Điều kiện 2 Y Y Các dòng điều kiện: Mỗi dòng bao gồm các Điều kiện 3 Y N điều kiện để tạo quyết định cho chương trình

Điều kiện n Y N: “false”

Hành động 1 X X X : Không có quyêt định được tạo ra

Ví dụ: Để tính thuế thu nhập, người ta có mô tả sau:

- Người vô gia cư nộp 4% thuế thu nhập

- Người có nhà ở nộp thuế theo bảng sau:

<=5.000.000 đồng 4%

> 5.000.000 đồng 6%

Quan hệ giữa nguyên nhân (đầu vào) và kết quả (đầu ra) như sau:

Bảng 2.2 - Ví dụ bảng quyết định

để đảm bảo rằng tất cả cung cấp đầu ra y như nhau Sau đó tất cả các phiên bảnđược thực thi song song với so sánh thời gian thực các kết quả để đảm bảo tính chắcchắn Các phiên bản độc lập là cơ sở của kỹ thuật kiểm thử hộp đen được gọi làkiếm thử so sánh hay kiếm thử back-to-back.

Kiểm thử so sánh là không rõ ràng Nếu đặc tả mà tất cả các phiên bản đượcphát triển trên đó là có lỗi, thì tất cả các phiên bản sẽ có khả năng dẫn đến lỗi Hơnnữa, nếu mỗi phiên bản độc lập tạo ra giống nhau, nhưng không đúng, các kết quả,kiểm thử điều kiện sẽ thất bại trong việc phát hiện lỗi

2.4.4 Đoán lỗi

Không cần một phương pháp đặc biệt nào, một số chuyên gia có thể kiểm tracác điều kiện lỗi bằng cách đoán lỗi dễ xảy ra Trên cơ sở trực giác và kinh nghiệm,với các chương trình cụ thể, các chuyên gia đoán trước các loại lỗi có thể, rồi viếtcác trường hợp kiếm thử để phơi ra các lỗi này

Một ý tưởng khác là chỉ ra các trường hợp kiểm thử liên quan đến giả địnhrằng lập trình viên đã mắc phải khi đọc đặc tả

CHƯƠNG 2

BỘ TIÊU CHUẨN ĐÁNH GIÁ CHẤT LƯỢNG PHẦN MỀM

1 Tiêu chuẩn về chức năng

1.1 Mục đích

Tiêu chuẩn này đánh giá khả năng phần mềm cung cấp đầy đủ các chức năngđáp ứng các nhu cầu sử dụng theo nội dung đặc tả yêu cầu, tiêu chuẩn bao gồm một sốvấn đề liên quan trực tiếp tới đảm bảo chức năng khi hoạt động của phần mềm nhưtính chính xác trong thiết kế, cấu trúc dữ liệu, tương thích, an ninh an toàn

1.2 Các tài liệu liên quan

- Tài liệu Tư vấn

- Tài liệu Khảo sát

- Tài liệu Đặc tả yêu cầu

- Tài liệu Giải pháp tổng thể

+ Tài liệu Phân tích hệ thống

+ Tài liệu Thiết kế

+ Tài liệu Phát triển hệ thống

+ Tài liệu Kiểm tra chất lượng

+ Tài liệu đào tạo, hướng dẫn quản trị, hướng dẫn sử dụng

1.3 Căn cứ đánh giá

Việc đánh giá tiêu chuẩn Chức năng căn cứ vào các tài liệu được xác nhận củacác bên liên quan đã nêu trong mục Chú ý rằng, nếu phần mềm không có ít nhất là mộttrong các tài liệu này thì việc đánh giá phần đó bỏ qua và cho điểm 0

1.4 Định nghĩa

a Đánh giá thuộc tính thiết kế là đánh giá việc thiết kế phần mềm có phù hợp

và đầy đủ so với yêu cầu đặt ra hay không (việc đánh giá có thể căn cứ vào yêu cầuban đầu ở các tài liệu đi kèm)

b Đánh giá thuộc tính Chính xác: là việc đánh giá dựa trên khả năng phần

mềm có cung cấp kết quả đúng, các kết quả chính xác sau khi thực hiện các chức năngtác nghiệp độc lập hoặc theo ngữ cảnh

c Đánh giá thuộc tính Tương thích: là việc đánh giá dựa trên khả năng phần

mềm có thể tương tác với các hệ thống khác, đặc biệt đối với các phần mềm quản trịCSDL, dữ liệu phải có thể tích hợp được và chuyển đổi giữa các hệ dữ liệu phổ biến

1.5 Trách nhiệm

a Đối với đơn vị sản xuất phần mềm

- Cung cấp đầy đủ tài liệu có liên quan: tài liệu tư vấn, tài liệu khảo sát, tài liệuđặc tả yêu cầu, tài liệu phân tích, thiết kế hệ thống, tài liệu hướng dẫn người dùng (nếucó) và các tài liệu liên quan hỗ trợ cho công tác đánh giá tiêu chuẩn chức năng củaphần mềm

- Cung cấp hệ thống phần mềm và các tiện ích kèm theo

- Hỗ trợ quá trình đánh giá khi có yêu cầu

b Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM

- Phối hợp và hỗ trợ quá trình đánh giá

c Đối với đơn vị đánh giá

- Chuẩn bị lực lượng, kế hoạch đánh giá, lấy góp ý của các bên liên quan

- Thiết lập đầy đủ thủ tục, quy trình thực hiện việc đánh giá phần mềm

- Đưa ra kết quả có mức độ chính xác cao, phù hợp với thực tế

1.6 Nội dung thực hiện

1.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá

- Chuẩn bị tài liệu

- Chuẩn bị các công cụ hỗ trợ việc đánh giá (nếu có)

- Chuẩn bị nhân sự cho việc đánh giá và phân công nhiệm vụ cụ thể cho từng

cá nhân tham gia đánh giá

- Mô tả sơ bộ về việc đánh giá tiêu chuẩn Chức năng đối với mỗi phần mềm

- Thiết lập các trọng số cho tiêu chuẩn Chức năng và các thuộc tính của tiêuchuẩn và từng tiêu chí của mỗi thuộc tính Đây là bước quan trọng, nó ảnh hưởng trựctiếp đến kết quả của việc đánh giá tiêu chuẩn này

1.6.2 Thực hiện việc đánh giá

- Các thuộc tính chất lượng của tiêu chuẩn Chức năng:

Tiêu chuẩn Mã Thuộc tính chất lượng

CHỨC NĂNG TCPM-CSDL-01.01 Chức năng

TCPM-CSDL-01.02 Chính xácTCPM-CSDL-01.03 Tương thích

- Quá trình thực hiện đánh giá tiêu chuẩn chất lượng Chức năng được chi tiết hóa vàđánh giá dựa trên các tiêu chí cụ thể như sau:

a Chức năng

* Đầy đủ chức năng

- Kiểm tra phần mềm đảm bảo đủ chức năng theo thiết kế sản phẩm phần mềm

- Thông thường, trong quá trình xây dựng phần mềm, việc khảo sát thực tế,viết tài liệu đặc tả yêu cầu người dùng là vấn đề khởi đầu mang tính quan trọngtrong dự án

- Để đánh giá một phần mềm có đảm bảo đầy đủ về chức năng hay không cầncăn cứ vào tài liệu đặc tả các yêu cầu người sử dụng, tài liệu giải pháp tổng thể có xácnhận của người sử dụng và căn cứ vào việc kiểm tra phần mềm Lưu ý rằng ở đây, ta chỉquan tâm chủ yếu đến tính đủ của các chức năng đã mô tả trong phần đặc tả yêu cầu vàtài liệu thiết kế so với các chức năng có trong phần mềm

- Căn cứ đánh giá: Tài liệu Đặc tả yêu cầu, tài liệu giải pháp và căn cứ trực tiếptrên phần mềm để kiểm tra Tính tỉ lệ chức năng có trong phần mềm so với số chứcnăng theo thiết kế X=A/B

A: Số chức năng đã được triển khai trong phần mềm

B: Số chức năng theo đã mô tả trong phần đặc tả yêu cầu

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Mức độ hoàn chỉnh

- Đánh giá mức độ hoàn chỉnh của từng chức năng có trong tài liệu thiết kế

- Trong tài liệu đặc tả yêu cầu, tài liệu thiết kế, đơn vị sản xuất phần mềm đã

mô tả và thiết kế chi tiết tới từng chức năng cụ thể Bản thân mỗi chức năng sẽ có cácthành phần nhỏ (ta tạm gọi là các chức năng con)

- Việc đánh giá mức độ hoàn chỉnh sẽ dựa vào sự hoàn thành các chức năng

con này trong mỗi chức năng lớn hơn.

- Mỗi chức năng trong sản phẩm phần mềm phải thực hiện những nhiệm vụ cụthể và phù hợp với yêu cầu trong phần thiết kế

- Căn cứ đánh giá: Căn cứ vào việc kiểm tra phần mềm so với tài liệu thiết kế.Kiểm tra các chức năng có được triển khai đủ so với thiết kế hay không

- Tính tỉ lệ số chức năng hoàn chỉnh so với số chức năng có trong phần mềm.X=A/B

A: Số chức năng hoàn chỉnh

B: Số chức năng theo thiết kế

- Lưu ý rằng: ở đây B là số chức năng theo thiết kế, không phải là số chức năng

có trong chương trình phần mềm là đúng vì điều đó sẽ đảm bảo tính “bình đẳng” chocác phần mềm khác

A: Số chức năng được phân rã

B: Số chức năng đã mô tả trong phần đặc tả yêu cầu

chức năng có quy trình thực hiện không, có hợp lý không Tính tỉ lệ số chức năng cótrình tự thực hiện so với số chức năng chương trình cần thực hiện theo trình tự X=A/B

- Đảm bảo độ chính xác của từng chức năng theo số liệu kiểm tra

- Căn cứ đánh giá: Việc đánh giá này có thể dựa vào các số liệu đã có của bên

A (bên đặt hàng), dữ liệu của người đánh giá chuẩn bị sẵn để đối chiếu giữa kết quảcủa việc chạy chương trình với kết quả đã có sẵn đó

Dữ liệu có thể lấy từ 3 nguồn:

A: Số chức năng được triển khai chính xác

B: Số chức năng được triển khai

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Mức độ sai lệch

- Các kết quả sai trong quá trình kiểm tra

- Căn cứ đánh giá: Dựa vào việc kiểm định trực tiếp phần mềm Tính tỉ lệ sốkết quả sai trong quá trình kiểm tra/số kết quả kiểm tra X=1-A/B

A: Số kết quả sai trong quá trình kiểm tra

B: Số kết quả kiểm tra

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Kết quả không cần thiết

- Các kết quả không trông đợi có thể nảy sinh trong quá trình kiểm tra

- Trong quá trình kiểm tra, việc xuất hiện các kết quả không theo ý người sử dụng, nóicách khác là không có tác dụng đối với một quy trình nghiệp vụ của người sử dụng thìcác kết quả đó hiển thị cho người dùng là các kết quả không cần thiết.

- Căn cứ đánh giá: Dựa vào việc kiểm định trực tiếp phần mềm

Tính tỉ lệ số kết quả thừa trong quá trình kiểm tra

X=1-A/B

A: Số kết quả thừa trong quá trình kiểm tra

B: Số kết quả kiểm tra

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Dữ liệu mẫu

- Dữ liệu mẫu để kiểm tra các chức năng trong chương trình

- Căn cứ đánh giá: Dựa vào việc kiểm định trực tiếp phần mềm Tính tỉ lệ sốchức năng có sẵn dữ liệu mẫu/số chức năng của chương trình X=A/B

A: Số chức năng có sẵn dữ liệu mẫu

B: Số chức năng có trong chương trình

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Tính đúng đắn của dữ liệu

- Chương trình phải có chức năng kiểm tra tính đúng đắn của dữ liệu

- Căn cứ đánh giá: Có thể kiểm tra chức năng này bằng cách test với các kiểu

dữ liệu khác nhau cho dữ liệu đầu vào, test với độ lớn của dữ liệu đầu vào, …

Tính tỉ lệ số chức năng có sự kiểm tra dữ liệu mẫu/số chức năng của chươngtrình X=A/B

A: Số chức năng có kiểm tra dữ liệu mẫu

B: Số chức năng của chương trình

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

c Tương thích

* Chuyển đổi dữ liệu

Lựa chọn hệ quản trị CSDL có thể dễ dàng chuyển đổi sang các hệ quản trịCSDL phổ biến khác Tính tỉ lệ số hệ CSDL chuyển đổi được/số hệ CSDL phổ biến

X=A/B A: Số hệ CSDL đã chuyển đổi được; B: Số hệ CSDL phổ biến

5: Trên 90%; 4: Từ 75-90%; 3: Từ 50-75%; 2: Từ 20-50%; 1: Dưới 20%

* Kết xuất dữ liệu

Có thể kết xuất dữ liệu bằng chức năng chương trình ra các tệp CSDL hoặc cácdạng khác nhau Tính tỉ lệ số FileType đó kết xuất thành công/số FileType yêu cầuX=A/B

A: Số FileType đã kết xuất thành công

B: Số FileType yêu cầu/cần thiết

5: Trên 90%; 4: Từ 75-90%; 3: Từ 50-75%; 2: Từ 20-50%; 1: Dưới 20%

* Nguồn dữ liệu

Có thể nhập dữ liệu từ nhiều nguồn khác nhau Tính tỉ lệ số kiểu input đó cậpnhật thành công/số kiểu Input phổ biến X=A/B

A: Số kiểu input đã cập nhật thành công

B: Số kiểu input phổ biến

2.2 Các tài liệu liên quan

- Tài liệu Đặc tả yêu cầu người sử dụng phần mềm

- Tài liệu Khảo sát

- Tài liệu Thiết kế chức năng

- Tài liệu Thiết kế CSDL

2.3 Căn cứ đánh giá

- Việc đánh giá tiêu chuẩn Tin cậy căn cứ vào các tài liệu đã nêu trong mục 2.2Chú ý rằng, nếu phần mềm không có các tài liệu này, hoặc thiếu đi một trong các tàiliệu đã nêu trong mục 2.2 thì việc đánh giá phần đó bỏ qua và cho điểm 0

- Việc đánh giá tiêu chuẩn này còn dựa trên việc thao tác trực tiếp trên phần

- Đánh giá thuộc tính Sẵn sàng: là việc đánh giá khả năng có thể đáp ứng các yêu cầu

sử dụng chức năng đúng thời gian Đặc biệt, dữ liệu luôn sẵn sàng cho các giao dịch

2.5 Trách nhiệm

2.5.1 Đối với đơn vị sản xuất phần mềm

- Cung cấp đầy đủ tài liệu có liên quan: tài liệu khảo sát, tài liệu đặc tả yêu cầu,tài liệu phân tích, thiết kế hệ thống, tài liệu hướng dẫn người dùng (nếu có), …

- Cung cấp hệ thống phần mềm và các tiện ích kèm theo

- Hỗ trợ quá trình đánh giá khi có yêu cầu

2.5.2 Đối với các đơn vị đặt hàng phần mềm, đơn vị mua SPPM có sẵn trên thị trường

- Phối hợp và hỗ trợ quá trình đánh giá

2.5.3 Đối với đơn vị đánh giá

- Thiết lập đầy đủ thủ tục, quy trình thực hiện việc đánh giá phần mềm

- Đưa ra kết quả có mức độ chính xác cao, phù hợp với thực tế

2.6 Nội dung thực hiện

2.6.1 Lập kế hoạch, hồ sơ cho việc xây dựng và chuẩn bị tiền đánh giá

- Chuẩn bị tài liệu đã nêu trong mục 2.2

- Chuẩn bị các công cụ hỗ trợ việc đánh giá (nếu có).

- Chuẩn bị nhân sự cho việc đánh giá và phân công nhiệm vụ cụ thể cho từng

cá nhân tham gia đánh giá

- Mô tả sơ bộ về việc đánh giá tiêu chuẩn Tin cậy đối với mỗi phần mềm

- Thiết lập các trọng số cho tiêu chuẩn Tin cậy và các thuộc tính của tiêu chuẩn

và từng tiêu chí của mỗi thuộc tính Đây là bước quan trọng, nó ảnh hưởng trực tiếpđến kết quả của việc đánh giá tiêu chuẩn này

2.6.2 Thực hiện việc đánh giá

- Các thuộc tính chất lượng của tiêu chuẩn Tin cậy:

Tiêu chuẩn mã thuộc tính chất lượng

Tiêu chuẩn Mã Thuộc tính chất lượng

TIN CẬY

TCPM-CSDL-02.01 Độ tin cậyTCPM-CSDL-02.02 Chống chịu lỗiTCPM-CSDL-02.03 Toàn vẹn dữ liệuTCPM-CSDL-02.04 Phục hồi

- Căn cứ đánh giá: Căn cứ vào việc kiểm tra trực tiếp trên phần mềm

Tính số lượng lỗi xảy ra trong một khoảng thời gian kiểm tra

5: Không có; 4: Rất ít; 3: Không nhiều; 2: Khá nhiều; 1: Quá nhiều

* Phân tích lỗi

- Là việc đánh giá khả năng tìm ra nguyên nhân gây ra lỗi khi sử dụng chương trình

- Căn cứ đánh giá: Căn cứ vào việc kiểm tra trực tiếp trên phần mềm

- Tính tỉ lệ lỗi tìm ra được nguyên nhân một cách nhanh chóng X=A/B

A: Số lỗi nhanh chóng được tìm ra nguyên nhân

B: Số lỗi xảy ra trong quá trình kiểm tra.

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Khắc phục lỗi

- Các lỗi phần mềm có thể khắc phục được ngay

- Căn cứ đánh giá: Căn cứ vào việc kiểm tra trực tiếp trên phần mềm

Tính tỉ lệ lỗi khắc phục được ngay X=A/B

A: Số lượng lỗi đã khắc phục được

B: Số lượng lỗi xảy ra trong quá trình kiểm tra

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

b Chống chịu lỗi

* Tránh lỗi với điều kiện biên

- Khả năng tránh được những lỗi khi thực hiện kiểm tra, đặc biệt là kiểm tra điều kiệnbiên

- Căn cứ đánh giá: Căn cứ vào việc kiểm tra trực tiếp trên phần mềm

Đánh giá các trường hợp xảy ra lỗi khi chạy thử chương trình với các điều kiện biên

và điều kiện đặc biệt X = A/B

A: Số trường hợp đã tránh được lỗi khi chạy với trường hợp đặc biệt

B: Số trường hợp đặc biệt được kiểm tra

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Tránh lỗi với thao tác sai

- Khả năng tránh được lỗi khi thực hiện sai các thao tác Để đánh giá luật này, ngườikiểm tra sẽ sử dụng phần mềm và chủ động thực hiện sai các thao tác, không đúngchức năng thực hiện, để đánh giá xem chương trình có tránh được các lỗi nàykhông

- Căn cứ đánh giá: Dựa vào việc kiểm tra trực tiếp trên phần mềm Trong quá trìnhkiểm tra, cố tình thực hiện các thao tác sai Tính tỉ lệ chương trình tránh được lỗi.X=A/B

A: Số trường hợp đã tránh được lỗi khi thao tác sai

B: Số lần thực hiện các thao tác sai

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Hạn chế thao tác sai của người sử dụng

- Kiểm tra xem chương trình có hạn chế người sử dụng thực hiện sai chức năng haykhông

- Căn cứ đánh giá: Dựa vào việc kiểm tra, thao tác trực tiếp trên phần mềm Đánhgiá dựa vào các chức năng có sự hạn chế các thao tác sai từ người sử dụng Việc đánhgiá theo công thức: X=A/B

A: Các chức năng có sự hạn chế thao tác sai

B: Số chức năng của chương trình

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Khả năng thao tác của người sử dụng

- Người sử dụng không thể thao tác khi có lỗi xảy ra

- Căn cứ đánh giá: Dựa vào việc kiểm tra, thao tác trực tiếp trên phần mềm Tính tỷ lệ

số lần người sử dụng không thể thao tác khi gặp lỗi Đánh giá theo công thức: X=1-A/B

A: Số lần người sử dụng không thể thao tác khi gặp lỗi

B: Số lần gặp lỗi

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

c Toàn vẹn dữ liệu

* Dữ liệu mẫu

- Dữ liệu mẫu để kiểm tra các chức năng trong chương trình

- Căn cứ đánh giá: Dựa vào việc kiểm định trực tiếp phần mềm Tính tỉ lệ số chứcnăng có sẵn dữ liệu mẫu/số chức năng của chương trình X=A/B

A: Số chức năng có sẵn dữ liệu mẫu

B: Số chức năng có trong chương trình

5: Trên 90%; 4: Từ 75% - 90%; 3: Từ 50% - 75%; 2: Từ 20% - 50%; 1: Dưới 20%

* Tính đúng đắn của dữ liệu

- Chương trình phải có chức năng kiểm tra tính đúng đắn của dữ liệu

- Căn cứ đánh giá: Có thể kiểm tra chức năng này bằng cách test với các kiểu dữ liệu