Kiểm thử hệ thống

BTL môn Công Nghệ Phần Mềm Đề Tài: Kiểm Thử Hệ Thống

Lời mở đầuCông nghệ phần mềm là 1 trong những ngành mũi nhọn của ngành công nghệ thông tin,

những phần mềm đã được sáng tạo và phát triển nhằm phục vụ những công việc khó khăn

nhất trong tất cả các lĩnh vực của đời sống xã hội, lĩnh vực nào cũng đang được dần tự

động hóa, cụ thể là những công việc thủ công đang dần được thay thế bằng những phần

mềm chuyên dụng đã giúp cho năng suất lao động tăng nhanh, giúp phát triển nền kinh tế

1 cách hiệu quả nhất. Sử dụng phần mềm chúng ta không thể không nhắc tới nguồn gốc

của phần mềm, đó chính là sản phẩm của những công ty phần mềm, nhưng để phát triển 1

phần mềm thì phải trải qua rất nhiều giai đoạn khác nhau, trong đó giai đoạn kiểm thử là

không thể thiếu trong bất kỳ quá trình sản xuất phần mềm nào. Đây chính là 1 hoạt động

mang tính sống còn trong các dự án sản xuất hoặc gia công phần mềm. Thông qua bài tập

lớn này chúng em mong có thể giúp mọi người hiểu biết rõ hơn về quá trình kiểm thử, đặc

biệt chúng em đi sâu về đề tài kiểm thử hệ thống. Đây là bước quyết định trong quy trình

quản lý chất lượng phần mềm. Do thời gian làm bài có giới hạn và có nhiều khó khăn

trong việc dịch tài liệu tiếng anh nên bài làm còn nhiều thiếu sót, chúng em mong cô

hướng dẫn và nhận xét cụ thể để chúng em có thể xây dựng bài tốt hơn.

CHÚNG EM XIN CHÂN THÀNH CẢM ƠN

Nhóm 8_ Lớp ĐH KHMT1 K2

1


MỤC LỤCLời nói đầu ……………………………………………………………….1

Phần I: Tổng quan về kiểm thử ………..…………………………………4

1. Kiểm thử phần mềm là gì …………………………………………5

2. Lý do kiểm thử ……………………………………………………5

3. Vai trò của kiểm thử ………………………………………………5

4. Mục tiêu của kiểm thử phần mềm ………………………………...5

5. Nguyên tắc kiểm thử ………………………………………………5

6. Các hạn chế của kiểm thử ………………………………………....5

7. Nội dung các nhiệm vụ trong quá trình kiểm thử phần mềm ……..6

8. Các giai đoạn trong quá trình kiểm thử……………………..……10

9. Phân loại 1 số công cụ kiểm thử tự động …………………….….11

10. Kỹ thuật kiểm thử …………………………………………....…13

11. Các phương pháp kiểm thử ………………………………..…....13

a. Kiểm thử hộp đen …………………………………..……13

b. Kiểm thử hộp trắng ……………………………………...14

c. Kiểm thử top-down ……………………………………..16

d. Kiểm thử bottom-up …………………………………….16

Phần II: Kiểm thử hệ thống …………………………………………….18

1. Khái niệm kiểm thử hệ thống ……………………………….18

2. Điều kiện kiểm thử hệ thống ………………………………..18


2


3. Tại sao kiểm thử hệ thống lại quan trọng …………………18

4. Các bước để thực hiện kiểm thử hệ thống …………………19

5. Những yếu tố ảnh hưởng tới sự thành công

của việc kiểm thử hệ thống ……………………………19

6. Các kiểu kiểm thử hệ thống ……………………………….20

a. Kiểm thử chức năng ………………………………..20

b. Kiểm thử phục hồi ………………………………….26

c. Kiểm thử an ninh ……………………………………26

d. Kiểm thử chịu tải ……………………………………27

e. Kiểm thử vận hành …………………………………..28

f. Kiểm thử cấu hình ……………………………………33

Phần III: Kiểm thử ứng dụng dựa trên Web …………………………….35


3


Phần I. Tổng quan về kiểm thử:1. Kiểm thử phần mềm là gì ?

Người ta thường nói một chương trình mới được tạo ra chứa vài lỗi trong 100 dòng .

Trong những dòng này, lỗi từ quá trình lập trình và lỗi từ quá trình thiết kế đều có cả.

Nếu 1 chương trình chứa lỗi được dùng để vận hành 1 hệ thống trực tuyến, thì những

hư hỏng nghiêm trọng phát sinh ra không chỉ ảnh hưởng tới công ty vận hành hệ thống

đó mà còn ảnh hưởng cả tới công chúng lớn bên ngoài.

Do đó việc kiểm thử phần mềm phải được tiến hành trước khi chuyển giao sản phẩm

công nghiệp. Việc kiểm thử phần mềm cũng phải được tiến hành theo 1 trình tự kiểm

thử đặc biệt để kiểm chứng rằng chương trình và hệ thống mà nó điều khiển có thể vận

hành tương ứng với các đặc tả. Mặc dù chúng ta không thể đảm bảo loại bỏ hoàn toàn

hết lỗi trong chương trình nhưng chúng vẫn có thể làm giảm số lỗi đó tới mực tối thiểu

nhất nếu chúng ta kiểm thử chương trình theo cách chính xác, hiệu quả.

Một hoạt động mang tính sống còn trong các dự án sản xuất hoặc gia công phần

mềm, đó là kiểm tra (Testing). Người làm phần mềm chắc hẳn không ai nghi ngờ vai

trò quan trọng của nó, tuy nhiên không phải ai (cả trong ngành và ngoài ngành) cũng

hiểu rõ hoạt động này. Bản thân công việc kiểm thử phần mềm cũng là một lĩnh vực

hoạt động độc lập và khá “hấp dẫn”. Cùng với các dự án gia công sản xuất phần

mềm, hiện cũng có khá nhiều dự án mà nội dung công việc chỉ là kiểm tra những

phần mềm đã được khách hàng phát triển sẵn.

Thực tế cho thấy kiểm thử phần mềm là công việc mà bất cứ người nào từng

tham gia phát triển phần mềm đều biết và từng làm. Theo nghĩa thông thường nhất,

kiểm thử phần mềm bao gồm việc "chạy thử" phần mềm hay một chức năng của phần

mềm, xem nó "chạy" đúng như mong muốn hay không. Việc kiểm tra này có thể thực

hiện từng chặng, sau mỗi chức năng hoặc module được phát triển, hoặc thực hiện sau

cùng, khi phần mềm đã được phát triển hoàn tất.

Kiểm thử phần mềm đứng ở vị trí hết sức nhạy cảm, nó là bước đệm giữa giai đoạn

xây dựng phần mềm và sử dụng phần mềm, trước khi giao sản phẩm hoàn chỉnh cho

khách hàng.


4


Do đó kiểm thử một sản phẩm phần mềm là xây dựng một cách có chủ đích

những tập dữ liệu và dãy thao tác nhằm đánh giá một số hoặc toàn bộ các tiêu chuẩn

của sản phẩm phần mềm đó.

Thử nghiệm có hai mục đích: chỉ ra hệ thống phù hợp với đặc tả và đưa ra được các khuyết

tật của hệ thống.

2. Lý do kiểm thử:

- Muốn nhìn thấy phần mềm như 1 phần tử của hệ thống hoạt động

- Hạn chế chi phí cho các thất bại do lỗi gây ra sau này

- Có kế hoạch nâng cao chất lượng trong suốt quá trình phát triển

3. Vai trò của kiểm thử:

- Kiểm thử là pha quan trọng trong quá trình phát triển hệ thống, giúp người xây dựng hệ

thống và khách hàng thấy được hệ thống mới đã thoả mãn những yêu cầu đã đề ra chưa, là

tiến trình nhằm phát hiện lỗi bằng cách xem xét lại đặc tả thiết kế và mã hoá.

- Kiểm thử tốt sẽ giảm chi phí phát triển và tăng độ tin cậy của phần mềm.

4. Mục tiêu của kiểm thử phần mềm:

- Tạo ra các ca kiểm thử để chỉ ra lỗi của phần mềm

- Có 1 chương trình tốt với chi phí xây dựng ít.

5. Nguyên tắc kiểm thử :

- Nguyên tắc khách quan: người kiểm thử không phải là tác giả của phần mềm đang kiểm

thử

- Nguyên tắc ngẫu nhiên: dữ liệu và chức năng được chọn tuy có chủ đích nhưng không phải

xuất hiện theo thứ tự nhất định.

- Nguyên tắc “người sử dụng kém”: hệ thống được 1 người sử dụng có trình độ thấp dùng

thử, người này có thể gây các sự cố có thể không lường trước được của hệ thống.

- Nguyên tắc “kẻ phá hoại”: hệ thống rơi vào tay người có trình độ nghiệp vụ cao, họ có chủ

ý phá hoại.

6. Các hạn chế của kiểm thử:


5


Do kiểm thử là chạy thử chương trình với tập dữ liệu giả nên không thể khẳng định

tính đúng đắn của chương trình do bản chất quy nạp không hoàn toàn của nó.

Trong nhiều trường hợp, việc kiểm thử thường được thực hiện từ những giai đoạn đầu

của quá trình cài đặt sản phẩm

Các chương trình nên được kiểm chứng theo 2 kỹ thuật: kiểm thử và chứng minh.

Nếu có thể nên khẳng định tính đúng của chương trình thông qua văn bản chương

trình.

Như vậy, 1 chương trình tuyệt đối đúng phải được thực hiện thông qua: tính đúng của

thuật toán và tính tương đương của chương trình với thuật toán.

Việc kiểm thử chương trình chỉ là nhìn sự kiện đưa ra kết luận do vậy không thể

khẳng định 1 chương trình tuyệt đối đúng bằng kiểm thử. Tuy vậy, bộ dữ liệu kiểm

thử phải phủ kín mọi trường hợp cần đánh giá. Thêm vào đó, trong quá trình kiểm

thử, ta thường mắc phải các đặc trưng của nguyên lý chủ quan như sau:

+ Bộ dữ liệu kiểm thử không thay đổi trong quá trình xây dựng phần mềm

+ Chỉ kiểm thử các trường hợp chính thống, hợp lệ, không quan tâm đến các cận và

các sự cố

+ Cài đặt chức năng nào thì chỉ kiểm thử riêng chức năng đó, không chỉ kiểm thử

tổng hợp chức năng vừa cài đặt với các chức năng đã cài đặt trước đó

+ Người kiểm thử đồng thời là người xây dựng phần mềm

7. Nội dung các nhiệm vụ trong quá trình kiểm thử:

a. Lập kế hoạch kiểm thử:

Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ

được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng

được dùng để xác định nhu cầu nhân lực.

Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá trình

cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra

viên quá yếu, không hiểu rõ yêu cầu.


6


Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện việc

kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉ

định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều

kiện để xác định thời gian kiểm tra.

Xác định nhân lực,vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng,

phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra.

Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định chi

tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá

trình kiểm tra.

Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch chi

tiết.

Hình 1: Bản kế hoạch chính và bản kế hoạch chi tiết

Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người có

liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc xem xét nhằm bảo

đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các

sai sót trong các bản kế hoạch.


7


Hình 2: Thời điểm phù hợp để thiết lập các kế hoạch kiểm thử

b. Chuẩn bị môi trường kiểm thử :

Thiết kế hệ thống kiểm thử:

Có những trường hợp máy được dùng cho các vận hành nghiệp vụ phải được dùng

cho chạy chương trình để kiểm thử. Tuy nhiên nếu máy này lưu giữ các tệp hay cơ

sở dữ liệu vẫn được truy nhập tới trong vận hành hàng ngày, hay 1 tải lượng lớn bị

áp vào máy trong khi kiểm thử, thì việc sản xuất sẽ bị gây rối loạn. Dó đó cần phải

phát triển hay thiết kế cùng hệ điều hành, tệp và cơ sở dữ liệu nhưng sẽ là đối

tượng được dùng trong việc chạy sản xuất thực.

Thiết kế chương trình kiểm thử và dữ liệu kiểm thử: Chương trình kiểm thử

phải được thiết kế, dữ liệu kiểm thử phải được chuẩn bị và các trường hợp

kiểm thử phải được thiết kế bằng việc dùng nhiều phương pháp. Công cụ phát

triển mới đây có thể dễ dàng sinh ra dữ liệu kiểm thử dựa trên các tham biến

cơ bản có thể được dùng. Một công cụ như vậy là rất thuận tiện vì dữ liệu sai

có thể sinh ra 1 cách có chú ý.

Thiết đặt các công cụ kiểm thử: Các công cụ kiểm thử cần phải được thiết đặt,

các chương trình tiện ích của hệ điều hành nói chung được dùng làm công cụ

kiểm thử. Các gói phần mềm được thiết kế làm công cụ kiểm thử bây giờ rất

sẵn có môi trường vận hành của gói như vậy nên được kiểm tra và đưa vào để

làm giảm chi phí phát triển và làm tăng tính hiệu quả, chất lượng của kiểm thử.

c. Tiến hành kiểm thử:

Nhiều loại kiểm thử phải được tiến hành trong điều kiện môi trường được chuẩn bị tốt.


8


d. Kiểm tra kết quả của kiểm thử:

Kiểm thử được tiến hành tương ứng với các kế hoạch kiểm thử và đặc tả kiểm thử, và kết

quả của việc kiểm thử phải được kiểm tra lại.

e. Phân tích hỏng hóc, phân tích hiệu năng:

Các lỗi và các hỏng hóc bị phát hiện phải được phân tích chặt chẽ bằng việc dùng các công

cụ và các kĩ thuật kiểm tra chất lượng đa dạng.

f. Sửa chữa và cải tiến tài liệu, chương trình gốc:

Nếu lỗi hay sai sót thiết kế được tìm thấy và nếu chúng có thể được sửa chữa ngay lập tức

thì chương trình nguồn phải được sửa chữa hay cải tiến. Phần của tài liệu thiết kế liên quan

tới các lỗi hay sai sót thiết kế như vậy cũng phải được sửa chữa. Nếu chỉ chương trình nguồn

được sửa chữa thì sự nhất quán giữa chương trình nguồn và tài liệu thiết kế sẽ bị mất, và rắc

rối có thể xuất hiện khi công việc kiểm chứng các phần khác hay việc bảo trì được tiến hành.

g. Lấy hành động thích hợp sau 1 kiểm thử hoàn tất:

Sau khi 1 kiểm thử đã được hoàn tất và chương trình đã được sửa chữa, thì các hành động

sau phải được tiến hành:

- Quản lý tiến trình kiểm thử và báo cáo: Người chịu trách nhiệm phải báo cáo về tiến độ của

việc kiểm thử bằng việc dùng báo cáo công việc hàng tuần hay báo cáo kiểm thử. Sau khi

kiểm thử được hoàn tất, người đó phải báo cáo kết quả của việc kiểm thử bằng việc dùng

báo cáo hoàn thành kiểm thử.

- Kiểm soát dữ liệu liên quan tới hỏng hóc: Dữ liệu về lỗi hay khiếm khuyết được tìm ra

trong khi kiểm thử phải được tích lại. Cũng vậy, lỗi xuất hiện trong tình huống nào, hành

động sửa chữa nào đã tiến hành và các thông tin chi tiết khác được cất giữ.

- Xem lại tài liệu vận hành ngược dòng: 1 sai lầm được tìm ra trong giao diện con người hay

trong giao diện các hệ con có thể được quy cho thiết kế trong. Không chỉ phần của chương

trình dẫn tới sai lầm đó phải được sửa lại, và cả bản thân tài liệu thiết kế trong cũng phải

được chữa lại để ngăn cản cùng sai lầm đó xảy ra nữa. Để ngăn cản việc lặp lại các lỗi gây ra

bởi 1 sai lầm phạm phải trong quá trình ngược dòng trước, 1 chương trình hay 1 phần của tài

liệu thiết kế liên quan tới sai lầm đó cũng như tài liệu vận hành tương ứng, phải được sửa lại

hay xem xét lại để ngăn cản sự xuất hiện nữa của cùng sai lầm.


9


8. Các giai đoạn trong quá trình kiểm thử

Giai đoạn kiểm thử là quá trình kiểm tra sản phẩm phần mềm để tìm kiếm lỗi. Quy

trình kiểm thử phẩn mềm được chia thành nhiều giai đoạn :

Hình 3: Các giai đoạn trong quá trình kiểm thử

Kiểm thử đơn vị ( unit testing) : được tiến hành tại những giai đoạn sớm nhất trong

pha kiểm thử, mục tiêu kiểm thử là từng modul.

Kiểm thử tích hợp ( integration testing) : được tiến hành sau khi kiểm thử đơn vị được

hoàn tất, tập trung vào sự tích hợp của các modul.

Kiểm thử hệ thống ( system testing )

Kiểm thử chấp nhận ( Acceptance testing )

Hình dưới cho thấy mối tương quan với các giai đoạn phát triển phần mềm trong mô hình V-

model


10


Hình 4: Mô hình V-model

9. Phân loại 1 số công cụ kiểm thử tự động:

Vì kiểm thử phần mềm thường chiếm tới 40% tất cả các nổ lực dành cho một dự án

xây dựng phần mềm, nên công cụ có thể làm giảm thời gian kiểm thử (không làm

giảm tính kỹ lưỡng) sẽ rất có giá trị. Thừa nhận lợi ích tiềm năng này, các nhà nghiên

cứu và người thực hành đã phát triển một số thế hệ các công cụ kiểm thử tự động:

Bộ phân tích tĩnh. Các hệ thống phân tích chương trình này hỗ trợ cho "việc

chứng minh" các lý lẽ tĩnh - những mệnh đề yếu kém về cấu trúc và định dạng của

chương trình.

Bộ kiểm toán mã. Những bộ lọc chuyên dụng này được dùng để kiểm tra chất

lượng của phần mềm để đảm bảo rằng nó đáp ứng các chuẩn mã hoá tối thiểu.

Bộ xử lý khẳng định. Những hệ thống tiền xử lý/hậu xử lý này được sử dụng để

cho biết liệu những phát biểu do người lập trình nêu, được gọi là các khẳng định, về

hành vi của chương trình có thực sự được đáp ứng trong việc thực hiện chương trình

thực hay không.


11


Bộ sinh tệp kiểm thử. Những bộ xử lý này sinh ra, và điền các giá trị đã xác định,

vào các tệp đọc vào điển hình cho chương trình đang được kiểm thử.

Bộ sinh dữ liệu kiểm thử. Những hệ thống phân tích tự động này hỗ trợ cho người

dùng trong việc chọn dữ liệu kiểm thử làm cho chương trình hành xử theo một cách

đặc biệt.

Bộ kiểm chứng kiểm thử. Những công cụ này đo mức bao quát kiểm thử bên trong,

thường được diễn tả dưới dạng có liên quan tới cấu trúc điều khiển của sự vật kiểm

thử, và báo cáo về giá trị bao quát cho chuyên gia đảm bảo chất lượng.

Dụng cụ kiểm thử. Lớp các công cụ này hỗ trợ cho việc xử lý các phép kiểm thử

bằng cách làm gần như không khó khăn để (1) thiết lập một chương trình ứng cử viên

trong môi trường kiểm thử, (2) nạp dữ liệu vào, và (3) mô phỏng bằng các cuống cho

hành vi của các module phụ.

Bộ so sánh cái ra. Công cụ này làm cho người ta có thể so sánh một tập cái ra từ

một chương trình này với một tập cái ra khác (đã được lưu giữ trước) để xác định sự

khác biệt giữa chúng.

Hệ thống thực hiện ký hiệu. Công cụ này thực hiện việc kiểm thử chương trình

bằng cách dùng cái vào đại số, thay vì giá trị dữ liệu số. Phần mềm được kiểm thử

vậy xuất hiện để kiểm thử các lớp dữ liệu, thay vì chỉ là một trường hợp kiểm thử đặc

biệt. Cái ra là đại số và có thể được so sánh với kết quả trông đợi cũng được xác định

dưới dạng đại số.

Bộ mô phỏng môi trường. Công cụ này là một hệ thống dựa trên máy tính giúp

người kiểm thử mô hình hoá môi trường bên ngoài của phần mềm thời gian thực và

rồi mô phỏng các điều kiện vận hành thực tại một cách động.

Bộ phân tích luồng dữ liệu. Công cụ này theo dõi dấu vết luồng dữ liệu đi qua hệ

thống (tương tự về nhiều khía cạnh với bộ phân tích đường đi) và cố gắng tìm ra

những tham khảo dữ liệu không xác định, đặt chỉ số sai và các lỗi khác có liên quan

tới dữ liệu.

Hiện nay việc dùng các công cụ tự động hoá cho kiểm thử phần mềm đang phát triển,

và rất có thể là ứng dụng đó sẽ phát triển nhanh trong thập kỷ tới. Các công cụ kiểm


12


thử có thể sẽ gây ra những thay đổi lớn trong cách chúng ta kiểm thử phần mềm và do

đó cải tiến độ tin cậy của các hệ thống dựa trên máy tính.

10. Kỹ thuật kiểm thử:

Kỹ thuật đối xứng: dựa vào tính đối xứng của các thao tác hoặc tập dữ liệu để xây

dựng bộ dữ liệu Test.

Kỹ thuật đám đông

Kỹ thuật kiểm thử trên dữ liệu thật: cho hệ thống vận hành với các tập dữ liệu thật

đã thu được từ trước để so sánh và đánh giá kết quả

Kỹ thuật kiểm thử trên thị trường thật: cho hệ thống vận hành trên thị trường thật

(không chính thức) để so sánh với các hệ thống chính được dùng và đánh giá kết

quả.

Kỹ thuật đối sánh: cho thực hiện với một vài sản phẩm khác với cùng các chức

năng giống nhau và trên cùng các tập dữ liệu rồi lập bảng so sánh các chức năng.

11. Các phương pháp kiểm thử:

a/ Kiểm thử hộp đen

Kiểm tra hộp đen, black-box, coi xử lý kết quả như là minh chứng bởi dữ liệu.

Khái niệm kiểm tra là black-box không quan tâm logic. Khuynh hướng này hiệu quả

đối với các modul chức năng đơn và các hệ thống cấp cao.

Ba phương pháp chính là:

Phân hoạch cân bằng: Mục đích của phương pháp này là tối thiểu các trường hợp

kiểm tra cho trước, các mục dữ liệu vào được chia thành các nhóm dữ liệu có vai

trò cân bằng nhau, mỗi nhóm đại diện cho một tập dữ liệu. Nguyên tắc là bằng

cách kiểm tra triệt để một mục của mỗi tập hợp, chúng ta có thể chấp nhận tất cả

các mục tương đương khác của tập hợp đó cũng sẽ được kiểm tra một cách kỹ

càng.

Phân tích cực biên: Phân tích giá trị cực biên là một dạng nghiêm ngặt của phân

hoạch cân bằng có sử dụng các giá trị biên hơn là bất cứ giá trị nào trong tập cân

bằng. Ví dụ: miền giá trị của tháng là 1 – 12 và ngoài là 0 và 13. Thì 4 kiểm tra


13


ứng với bốn trường hợp sẽ được kiểm tra phân tích cực biên thường xuyên được

dùng tại các mức modul để xác định các mục dữ liệu đặc trưng cho testing.

Đoán lỗi: Dựa trên cơ sở trực giác và kinh nghiệm, các chuyên gia có thể dễ dàng

kiểm tra các điều kiện lỗi bằng cách đoán cái nào dễ xảy ra nhất. Ví dụ, chia 0,

nếu modul có phép chia, nên dùng phép chia 0. Vì dựa trên trực giác, nên phép

thử này khó tìm hết các lỗi.

Một nhược điểm của phân hoạch cân bằng và phân tích cực biên là tổ hợp của

các miền hợp không được xác định. Để bổ sung, người ta dùng sơ đồ nguyên nhân –

kết quả (Cause – Effect Graphing). Sơ đồ nguyên nhân – kết quả chỉ ra các đầu ra và

thông tin di chuyển như là hệ quả và các đầu vào gây ra hệ quả trên. Các ký hiệu

graphic xác định tương tác, lựa chọn, logic và các điều kiện tương đương. Một vòng

đại diện một dãy các thao tác không có điểm quyết định hoặc điều khiển. Mỗi dòng

biểu diễn một lớp cân bằng của dữ liệu và các điều kiện sử dụng nó. Mỗi lần graph

được thực hiện thì ít nhất một giá trị có nghĩa và một không có nghĩa cho mỗi tập

được thử.

b/ Kiểm thử hộp trắng

Có ba loại kiểm tra hộp trắng là kiểm tra logic, chứng minh toán học và kiểm

tra phòng trống.

1. Kiểm tra logic:

Logic test có thể được chi tiết đến mức lệnh. Trong khi thực hiện của mọi lệnh

là mục đích đáng khen ngợi, nó có thể không kiểm tra tất cả các điều kiện thuộc

chương trình. Ví dụ, ít nhất 2 kiểm tra cho một kiểm tra 2 điều kiện (1 đúng và 1 sai).

Cố gắng kiểm tra tất cả các điều kiện lẽ dĩ nhiên là không thể thực hiện được về thực

tiễn. Ví dụ trong 1 module có 10 thao tác qua 4 vòng lặp thì có 5,5 triệu trường hợp

kiểm tra. Do đó phải có phương pháp lựa chọn.

Logic kiểm tra nhìn vào mỗi quyết định trong module và sản sinh các dữ liệu

để tạo tất cả các kết quả ra có thể. Có một vấn đề với logic test tại mức này là chúng

không test tình trạng của module đối với đặc tả. Nếu kiểm tra được phát triển dựa trên

đặc tả, mà đặc tả được dịch khác nhau bởi người lập trình thì kiểm tra sẽ không đúng.


14


Giải pháp là đòi hỏi đặc tả chương trình đủ chi tiết và logic. Điều này có thể phù hợp

với ngôn ngữ thế hệ 1 và 2.

Các kiểm tra nhiều điều kiện tạo mỗi kết quả ra của tiêu chuẩn đa quyết định

và nhiều điểm vào module. Các kiểm tra đòi hỏi việc phân tích xác định được bên

quyết định đa tiêu chuẩn. Nếu các biên được xác định không chính xác, thì kiểm tra

không hiệu quả. Khi được thiết kế phù hợp, test logic đa điều kiện có thể tối thiểu hoá

các trường hợp kiểm tra để kiểm tra nhiều nhất các điều kiện. Sự sử dụng kỹ thuật

này đòi hỏi luyện tập và kỹ năng.

2. Chứng minh bằng toán học

Một phương pháp theo cách tiếp cận giảm thiếu sót về 0 là áp dụng suy diễn

toán học cho đòi hỏi logic, chứng minh tính đúng đắn của chương trình. Phương pháp

này đòi hỏi đặc tả ngôn ngữ dạng hình thức.

3. Kiểm tra phòng trống:

Kiểm tra phòng trống là mở rộng của phương pháp chứng minh bằng toán học.

Lý thuyết của kỹ thuật này là bằng cách ngăn chặn các lỗi tại các đầu vào của quá

trình xử lý, giá thành sẽ giảm, độ tin cậy tăng lên và tiệm cận tới không có lỗi.

Phương pháp này được phát triển tại IBM đầu những năm 1980 bởi Mills,

Dyer, Linger. Các đặc tả hình thức được dùng và việc kiểm tra thủ công được tiến

hành bởi các đội kiểm tra. Các chương trình khó đọc sẽ được viết lại và kiểm tra hoàn

toàn trên giấy.

Cleanroom testing là kỹ thuật kiểm tra toán học hình thức và hội ý

(walkthrough). Mục đích là phân tích mọi module thành các chức năng và liên kết.

Các phép kiểm tra chức năng dùng kỹ thuật toán học, các kiểm tra liên kết sử dụng

thuyết tập hợp.

Sau khi thực hiện kiểm tra (verification), đội kiểm tra độc lập sẽ dịch và thực

hiện mã. Dữ liệu kiểm tra được dịch bởi các phân tích đặc tả chức năng và được thực

hiện thể hiện các tỷ lệ xác suất của dữ liệu được giả định cho hệ thống thực. Thêm

vào các dữ liệu chuẩn thì các loại lỗi nghiêm trọng được tạo để kiểm tra ứng dụng.

Bất lợi của phương pháp này bắt buộc là đòi hỏi kỹ năng cao về: toán, thống

kê, logic và ngôn ngữ đặc tả hình thức.


15


c. Kiểm thử top- down

Phương pháp kiểm tra top-down cần một mã ngoài, được hiểu như là một bộ

khung để gắn các chức năng gốc, các modul, và các phần khác của ứng dụng. Bộ

khung này thường bắt đầu với ngôn ngữ điều khiển công việc và logic chính của ứng

dụng. Logic chính được kiểm tra và lập khung theo các hệ thống phân rã. Đầu tiên chỉ

có các thủ tục thiết yếu và các logic điều khiển được kiểm tra.

Khi các module thiết yếu nhất đã được kiểm tra và chạy tốt thì mã của các

modul ít quan trọng hơn sẽ được gắn vào khung và tiếp tục kiểm tra. Về lý thuyết thì,

top-down sẽ tìm thấy các lỗi thiết kế sớm hơn trong kiểm tra thao tác (testing process)

hơn các khuynh hướng khác. Phương pháp này ít hiệu quả trong việc cải thiện chất

lượng của các phần mềm chuyển giao vì bản chất tương tác của kiểm tra.

Kiểm tra top-down dễ dàng hỗ trợ giao diện người dùng và thiết kế màn hình.

Trong các ứng dụng tương tác, thường là bộ điều khiển màn hình được kiểm tra đầu

tiên. Người dùng có thể kiểm tra sự điều khiển thông qua màn hình với các phát triển

tạo mẫu.

d. Kiểm thử bottom-up:

Nguyên tắc của bottom-up là kiểm tra mọi thay đổi tại module có thể ảnh

hưởng tới chức năng của nó. Trong kiểm tra bottom-up, toàn bộ khối là đơn vị để

đánh giá. Tất cả các module được mã hoá và kiểm tra riêng rẽ.

Các trường hợp kiểm tra: các trường hợp kiểm tra là dữ liệu vào được tạo để

thể hiện từng khối và toàn bộ hệ thống thoả mãn tất cả các yêu cầu thiết kế.

Mỗi trường hợp kiểm tra nên được phát triển để kiểm tra nghiệm các đòi hỏi

thiết kế đặc trưng, thiết kế chức năng, hoặc mã đã được thoả mãn. Hơn nữa các

trường hợp kiểm tra cần dự đoán các output.

Mỗi đơn nguyên của ứng dụng (Ví dụ: module, subroutine, program, utility,...)

phải được kiểm tra với ít nhất hai trường hợp kiểm tra: một trường hợp chạy tốt và

một trường hợp không chạy. Trong trường hợp chạy sai hệ phải đưa được thông báo,

quay lại (rollback) được trạng thái ban đầu của giao dịch.

Để chắc chắn rằng các trường hợp được toàn diện nhất, người ta thường dùng

ma trận. Chúng được dùng cho:


16


Kiểm tra đơn khối để định nhánh logic, điều kiện logic, các phần dữ liệu hoặc

biên dữ liệu để kiểm tra trên cơ sở đặc tả chương trình.

Kiểm tra tổ hợp để định ra yêu cầu về dữ liệu và quan hệ trong số các tương tác.

Kiểm tra hệ thống để xác định yêu cầu về người dùng và hệ thống từ các yêu cầu

chức năng và các yêu cầu chấp nhận.


17


Phần II. Kiểm thử hệ thống:1. Khái niệm kiểm thử hệ thống:

Kiểm thử hệ thống được tiến hành để kiểm chứng sự thích hợp với thiết kế ngoài.

Trong việc tiến hành kiểm thử này, phần lớn chú ý được dành cho giao diện giữa

các hệ con. Kiểm thử hệ thống được gọi là kiểm thử toàn diện và được tiến hành

bởi 1 nhóm chuyên kiểm thử. Nó là kiểm thử cuối cùng được tiến hành bởi tổ chức

phát triển hệ thống.

Yêu cầu của kiểm thử hệ thống:

Mô phỏng dữ liệu xấu và các sai tiềm tàng tại giao diện phần mềm

Kiểm thử kết quả của mỗi đường liên kết

Báo cáo các kết quả kiểm thử phân định từng phần từng loại làm chứng cứ

đổ lỗi cho nhau.

Việc hoạch định và thiết kế các ca kiểm thử hệ thống theo những cách nhìn

khác nhau sao cho đảm bảo phần mềm được kiểm thử đầy đủ chính xác các

loại yêu cầu.

2. Điều kiện kiểm thử hệ thống:

- Tất cả các thành phần cần được kiểm thử đơn vị 1 cách thành công.

- Tất cả các thành phần cần được tương thích và kiểm thử tích hợp cần phải hoàn toàn.

- Cần tạo ra 1 môi trường gần giống với môi trường sản xuất, khi cần thiết phải lặp đi

lặp lại sự kiểm thử trong nhiều môi trường.

3. Tại sao kiểm thử hệ thống lại quan trọng:

Kiểm thử hệ thống là bước quyết định trong quy trình quản lý chất lượng:

- Trong vòng đời phát triển phần mềm, kiểm thử hệ thống là mức đầu tiên nơi mà hệ

thống được kiểm tra 1 cách tổng thể.

- Hệ thống được kiểm tra để xác minh nó có phù hợp với các yêu cầu chức năng và

công nghệ.

- Ứng dụng hoặc hệ thống được kiểm tra trong 1 môi trường mà nó gần giống với môi

trường sản xuất nơi mà các ứng dụng sẽ được phát triển cuối cùng.


18


- Kiểm thử hệ thống cho phép chúng ta kiểm tra, xác minh và làm có hiệu quả cả 2 yêu

cầu của doanh nghiệp như là kiến trúc, ứng dụng.

4. Các bước để thực hiện kiểm thử hệ thống:

Lập kế hoạch kiểm thử hệ thống

Nêu ra các trường hợp có thể xảy ra

Xây dựng dữ liệu để nhập vào cho hệ thống kiểm tra

Tạo ra những nguyên bản để xây dựng môi trường và tự động hoá sự thực hiện

của các trường hợp kiểm thử

Thực thi các trường hợp kiểm thử

Chỉnh sửa những hỏng hóc nếu có và kiểm tra lại mã

Lặp lại quá trình kiểm thử nếu cần thiết

5. Những yếu tố ảnh hưởng tới sự thành công của việc kiểm thử hệ thống:

Phạm vi kiểm thử: Kiểm thử hệ thống chỉ có hiệu quả trong phạm vi

các trường hợp kiểm thử

Theo dõi những khiếm khuyết: phải theo dõi những khiếm khuyết

trong suốt quá trình kiểm thử, sau đó phải lặp đi lặp lại các trường hợp

kiểm thử để xác minh xem phải chăng khiếm khuyết này là cố định.

Sự vận hành kiểm thử: Các trường hợp kiểm thử nên được thực thi

theo phương thức cụ thể.

Tự động hoá quá trình thiết kế: sẽ có nhiều lỗi xuất hiện vì thiết kế

không thích hợp. Thiết kế là sự biên dịch của nhiều thành phần tạo nên

những ứng dụng được triển khai trong môi trường thích hợp. Kết quả

của kiểm thử sẽ không đúng nếu ứng dụng không được xây dựng đúng

hoặc trong môi trường không được cài đặt như dự kiến. Quá trình tự

động hoá này sẽ giúp giảm bớt những lỗi bằng tay.

Kiểm tra sự tự động hóa: quy trình kiểm thử tự động có thể giúp

chúng ta nhiều cách:

- Kiểm thử có thể được lặp lại với các lỗi bị bỏ quên ít hơn


19


- Khi sự thử tự động, 1 vài kịch bản có thể được mô phỏng chẳng hạn như mô phỏng 1

số lượng lớn người sử dụng hoặc mô phỏng số lượng dữ liệu đầu vào/ ra tăng lên.

Tư liệu: tài liệu thích hợp giúp theo dõi thực hiện kiểm thử, nó cũng giúp tạo

ra 1 cơ sở kiến thức cho cácdự án hiện tại và tương lai. Những thước đo chính

xác, những thông tin được thống kê có thể được lưu lại để làm kiểm chứng có

hiệu quả các thiết kế kiến trúc/ kỹ thuật.

6. Các kiểu kiểm thử hệ thống:

Hình 4: Các kiểu kiểm thử hệ thống

a. Kiểm thử chức năng

Chức năng mức hệ thống bao gồm các chức năng giao diện, các chức năng

mức người dùng hay đầu ra cuối cùng khỏi hệ thống.Các chức năng này

thường mang tính tích hợp nên sau khi phát hiện sai phải quay lại kiểm thử

từng phần cấu thành trước nó.Các giao diện được xem như điểm phân định

giữa các phần để kiểm thử.

Kỹ thuật kiểm thử hệ thống mức chức năng:


20


Kỹ thuật kiểm thử chức năng được thiết kế để đảm bảo những yêu cầu

và đặc điểm kỹ thuật của hệ thống đã đạt được.

Mục đích: những quy trình bình thường bao gồm việc tạo ra các điều

kiện kiểm thử, sau đó sử dụng chúng để đánh giá sự phát triển đúng

của hệ thống.

Các kỹ thuật khác nhau của kiểm thử chức năng là:

- Kiểm thử nhu cầu

- Kiểm thử hồi quy

- Kiểm thử khắc phục lỗi

- Kiểm thử hỗ trợ- hướng dẫn

- Kiểm thử song song

1) Kiểm thử nhu cầu:

Được sử

dụng

- Để đảm bảo hệ thống thực hiện đúng

- Để đảm bảo độ chính xác có thể được duy trì liên tục trong những

khoảng thời gian đáng cân nhắc

- Hệ thống có thể được kiểm tra sự đúng đắn qua tất cả các giai đoạn,

nhưng ngoài sự an toàn, các chương trình nên là nơi làm cho hệ thống

làm việc

Mục đích - Hệ thống xử lý thành công những yêu cầu của người sử dụng

- Sự bảo trì chính xác qua khoảng thời gian đáng cân nhắc

- Quy trình ứng dụng tuân theo những nguyên tắc và phương pháp của

cấu tạo

- Người sử dụng thứ 2 phải là: nhân viên an ninh, người kiểm tra bên

trong, người kiểm soát

Sử dụng

như thế nào

Tạo ra các điều kiện kiểm thử: điều kiện kiểm thử này được suy rộng ra tạo ra

những trường hợp kiểm thử. Điều kiện kiểm thử sẽ có hiệu quả hơn khi tạo ra

từ những yêu cầu của người sử dụng. Nếu tạo ra từ những tập tài liệu, nếu tài


21


liệu đó có bất kỳ lỗi nào thì kiểm thử có thể không có khả năng tìm thấy lỗi.

Điều kiện kiểm thử nếu tạo ra từ những nguồn khác thì sự bắt lỗi sẽ có hiệu

quả.

Sử dụng khi

nào

- Mọi ứng dụng nên được kiểm thử yêu cầu

- Nên bắt đầu từ giai đoạn yêu cầu và nên tiến hành cho tới giai đoạn vận

hành và bảo dưỡng

- Cách thức sử dụng để mang lại kiểm thử yêu cầu và phạm vi của nó là

quan trọng

Ví dụ - Tạo ra những kiểm thử gốc để chứng minh rằng những yêu cầu hệ

thống như dữ liệu là những yêu cầu mà người sử dụng đòi hỏi.

- Tạo ra danh sách kiểm tra để kiểm chứng rằng ứng dụng tuân theo

những nguyên tắc và phương pháp của cấu tạo

2) Kỹ thuật kiểm thử hồi quy:

Khái quát - 1 bộ phận của hệ thống được phát triển và kiểm thử hoàn toàn

- 1 bộ phận khác thay đổi có ảnh hưởng xấu tới bộ phận kiểm thử

- Sự thực thi thay đổi, dữ liệu và những đặc trưng mới được tạo ra sự

thay đổi trong các phần đã kiểm thử

Sử dụng Tất cả các hướng của hệ thống còn các chức năng sau khi kiểm thử.

Sự thay đổi của 1 phần không làm thay đổi chức năng của các phần khác.

Mục đích Xác định tài liệu hệ thống hiện thời vẫn còn, dữ liệu kiểm thử hệ thống và

điều kiện kiểm thử hiện thời vẫn còn.

Trước sự kiểm thử chức năng 1 cách đúng đắn mà không có sự ảnh hưởng,

mặc dù sự thay đổi được tạo ra trong mỗi phần khác của hệ thống ứng dụng.

Sử dụng

như thế nào

- Các trường hợp kiểm thử được sử dụng trước đó cho những phần đã

kiểm thử, chạy lại để chắc chắn rằng kết quả của phần kiểm thử hiện


22


thời và kết quả của phần kiểm thử trước là như nhau.

- Tự động hoá sự thử là cần thiết để thực thi những giao dịch kiểm thử,

trái lại quy trình sẽ tốn nhiều thời gian và thiếu hấp dẫn.

- Trong trường hợp này chi phí và lợi ích của kiểm thử nên được đánh

giá cẩn thận trái lại sự cố gắng kiểm thử có thể nhiều hơn và thu được

lợi ích nhỏ hơn.

Sử dụng khi

nào

- Khi có rủi ro cao mà sự thay đổi mới có thể ảnh hưởng tới những phạm

vi không thay đổi của hệ thống ứng dụng.

- Trong quá trình phát triển: sự kiểm thử hồi quy nên được thực hiện sau

khi đã xác định sự thay đổi được đưa vào trong hệ thống ứng dụng.

- Trong giai đoạn bảo trì: kiểm thử hồi quy nên được thực hiện nếu có rủi

ro cao mà sự mất mát có thể xuất hiện khi hệ thống thay đổi.

3) Kiểm thử khắc phục lỗi:

Khái quát - Trước sự xác định của những đặc điểm khắc phục lỗi cơ bản là sự khác

nhau giữa hệ thống tự động và bằng tay

- Hệ thống bằng tay có thể chua các vấn đề như chúng xuất hiện

- Hệ thống tự động: nên là các chương trình khắc phục lỗi trước

Cách sử

dụng

- Nó xác định khả năng của hệ thống ứng dụng để xử lý chính xác những

giao dịch sai.

- Những lỗi vây quanh tất cả những điều kiện không ngờ

- Trong 1 vài hệ thống khoảng 50% ảnh hưởng của chương trình sẽ được

dành để điều khiển điều kiện lỗi.

Mục đích Xác định: hệ thống ứng dụng nhận dạng tất cả những điều kiện lỗi, trách

nhiệm giải trình của xử lý lỗi được gán giá trị và nhiệm vụ cung cấp xác xuất

xuất hiện lỗi cao.

Sử dụng

như thế nào

- 1 nhóm chuyên gia được yêu cầu dự đoán trước cái gì có thể sai trong


23


hệ thống ứng dụng

- Nó cần tất cả ứng dụng của nhóm chuyên gia tập hợp lại để hợp nhất

hiểu biết của họ thành phạm vi người sử dụng, kiểm tra, quản lý và theo

dõi lỗi.

- Sau đó kiểm tra logic những điều kiện lỗi nên được tạo ra trên cơ sở

thông tin được tập hợp này.

- Kỹ thuật khắc phục lỗi nên kiểm tra: lỗi, quá trình xử lý lỗi, điều kiện

quản lý, sự trở lại của điều kiện là đúng hoặc không.

- Tính lặp nên được sử dụng nơi các lỗi đầu tiên trong hệ thống bị bắt

đúng và sau đó hệ thống đúng nên được kiểm tra lại để kiểm tra sự tin

cậy của ứng dụng vận hành và để hoàn thành vòng kiểm thử khắc phục

lỗi.

- Người kiểm thử nên xác định hệ thống có thể bị sập như thế nào để họ

có thể xác định nếu phần mềm có thể xử lý 1 cách chính xác các dữ liệu

sai.

Sử dụng khi

nào

- Sự va chạm từ những lỗi có thể được xác định và sửa chữa để làm giảm

các lỗi tới mức cho phép.

- Được dùng để trợ giúp quy trình xử lý lỗi của phát triển và bảo trì hệ

thống.

4) Kiểm thử hỗ trợ- hướng dẫn:

Cách sử

dụng

Nó bao hàm kiểm thử tất cả các chức năng thực hiện bởi người sửa chữa dữ

liệu và sử dụng các dữ liệu này từ hệ thống tự động.

Mục đích - Kiểm tra các tài liệu và biện pháp hỗ trợ hướng dẫn là đúng.

- Xác định trách nhiệm hỗ trợ hướng dẫn là đúng, hỗ trợ hướng dẫn mọi

người là thoả đáng, hỗ trợ hướng dẫn và tự động hoá từng phần là sự

liên kết chính xác.

Sử dụng - Nó bao gồm: sự đánh giá của quá trình thích hợp, sự thực hiện của quá


24


như thế nào trình, đánh giá quá trình

- Thay vì sửa chữa, sự thực hiện và đưa sự thử nghiệm giao dịch vận

hành và giám sát nhân viên có thể sử dụng kết quả của quá trình từ hệ

thống ứng dụng

Khi nào sử

dụng

- Kiểm tra chức năng chính xác của hệ thống hướng dẫn nên được điều

khiển

- Thực hiện tốt nhất trong giai đoạn cài đặt để mọi người không được sử

dụng hệ thống hiện thời trước hệ thống đi tới sản xuất

5) Kỹ thuật kiểm thử song song:

Cách sử

dụng

Để đảm bảo rằng quá trình của phiên bản mới là nhất quán với sự liên quan

tới quá trình xử lý của phiên bản ứng dụng trước.

Mục đích - Dẫn quá trình liên kết thừa để dảm bảo rằng phiên bản mới hoặc ứng

dụng mới thực hiện đúng.

- Chứng minh tính vững vàng và không vững vàng giữa 2 phiên bản của

ứng dụng.

Sử dụng

như thế nào

Giống dữ liệu đầu vào nên được chạy qua 2 phiên bản giống hệ thống ứng

dụng.

Kiểm thử song song có thể được thực hiện với toàn bộ hệ thống hoặc từng

phần của hệ thống.

Sử dụng khi

nào

- Khi có sự bất định về độ chính xác của quá trình ứng dụng mới nơi

phiên bản mới và cũ là tương tự nhau.

- Trong các ứng dụng về tài chính như trong ngân hàng nơi có nhiều ứng

dụng tương tự như quy trình có thể được kiểm chứng cho những phiên

bản cũ và mới qua kiểm thử song song.


25


b. Kiểm thử phục hồi

Nhiều hệ thống không cần phải phục hồi sau lỗi để tiếp tục xử lí trong một thời gian đã

đặc tả trước có thể :

- Hệ thống không cần thử lỗi nghĩa là xử lí lỗi bắt buộc không được làm ngừng

hoạt động của toàn hệ thống.

- Lỗi phải được khắc phục dần theo chu kì đặc tả

Kiểm thử phục hồi là bắt phần mềm phải thất bại để xem khả năng phục hồi của nó

đến đâu. Độ tin cậy là một độ đo đánh giá khả năng phục hồi.

Có 2 cách phục hồi :

- Phục hồi tự động : bằng việc khởi động lại, sau khi phục hồi dữ liệu hệ thống

tiếp tục hay khởi động lại thì đựợc đánh giá là đúng đắn.

- Phục hồi có sự can thiệp của con người :Lúc này cần đánh giá thời hạn trung

bình để sửa chữa trong giới hạn cho phép hay không.

Ví dụ như 1 website nên có 1 bản sao hoặc 1 bản dự phòng để sự lưu thông được luân phiên

khi máy chủ ban đầu bị sập. Và bộ phận định tuyến cho dữ liệu có thể được kiểm thử. Nếu 1

người sử dụng tìm thấy dịch vụ của bạn không có trong 1 khoảng thời gian dài, người dùng

sẽ chuyển sang hoặc tìm 1 website của các đối thủ khác. Nếu vị trí không thể phục hồi nhanh

chóng sau khi thông báo cho người sử dụng khi đó vị trí này sẽ có giá trị và chức năng.

c. Kiểm thử an ninh

Là kiểm tra mọi cơ chế bảo vệ đựợc xây dựng trong hệ thống xem có đạt hiệu quả đề ra

trước khi đột nhập hay không? Khi xét tất cả các loại đột nhập có thể “ trước mặt , ngang

sườn , sau lưng “

Khi kiểm thử an ninh thì người kiểm thử sẽ đóng vai trò của kẻ đột nhập.

Về nguyên tắc :Mọi đột nhập là có thể nếu đủ thời gian và nguồn lực.Vì vậy bài toán

thiết kế an ninh đặt ra là : Làm cho việc đột nhập tốn chi phí nhiều hơn giá trị thu đựợc do

đột nhập.Công sức bỏ ra xây dựng công cụ bảo vệ phải ít hơn giá trị mất đi nếu bị đột nhập .

Chi phí công cụ bảo vệ < lợi ích do bảo vệ khỏi đột nhập

Chi phí để đột nhập > lợi ích thu đựợc do đột nhập.


26


Có lẽ tiêu chuẩn xác định phổ biến nhất cho ứng dụng mạng là sự an toàn. Nhu cầu để điều

chỉnh truy nhập tới thông tin, để kiểm chứng sự đồng nhất người dùng, và mã hóa thông tin

là quan trọng hơn. Thông tin thẻ tín dụng, thông tin y học, thông tin tài chính và thông tin

đoàn thể cần được bảo vệ tránh những kẻ trộm cắp từ những người ghé thăm đến những tinh

tặc. Có nhiều lớp bảo vệ, từ sự bảo mật bằng mật khẩu đến những chứng chỉ số, mỗi một lớp

đều có sự tán thành và phản đối nó.

Chúng ta có thể tạo ra những trường hợp kiểm thử an ninh theo các bước:

Máy chủ mạng nên được cài đặt để những người dùng trái phép không thể truy tìm

những danh mục và những bản ghi mà trong đó tất cả dữ liệu từ trang web lưu trữ.

Dự án sớm, khuyến khích những người phát triển sử dụng lệnh gửi ở bất kỳ chỗ nào

có thể vì lệnh thông báo được sử dụng cho dữ liệu lớn.

Khi kiểm thử, kiểm tra các địa chỉ tài nguyên để đảm bảo rằng không có thông tin dò

dỉ vì thông tin chính xác được đặt trong địa chỉ tài nguyên trong khi sử dụng câu lệnh

GET.

1 cookie là 1 file văn bản được đặt trong 1 hệ thống trang web của những người ghé

thăm cái được đồng nhất với người sử dụng. Cookie được khôi phục khi người dùng

lại ghé thăm tại 1 địa điểm ở thời gian sau. Cookie có thể được quản lý bởi người sử

dụng, dù họ có muốn cho phép chúng hay không. Nếu người sử dụng không chấp

nhận cookie, địa điểm này vẫn sẽ làm việc không?

Thông tin chính xác có thể được lưu trữ trong cookie không? Nếu đa người sử dụng 1

trạm, người thứ 2 có khả năng đọc chính xác thông tin lưu từ người ghé thăm đầu

tiên. Thông tin trong cookie nên được mã hoá hoặc được mã hoá.

d. Kiểm thử chịu tải :

Kiểm thử chịu tải là vận hành hệ thống khi sử dụng nguồn lực với số lượng tần suất và

cường độ dị thường. Một loại khác của thử nghiệm áp lực là kiểm thử độ nhạy : Cố gắng làm

bộc lộ các tổ hợp dữ liệu hay sự kiện mà có thể gây ra việc xử lí không ổn định hoặc không

chính xác. Kiểm thử tải là quá trình tạo ra yêu cầu trên 1 hệ thống hoặc thiết bị và đo lường

trách nhiệm của nó.

Trong kỹ nghệ phần mềm, nó là 1 thời kỳ che phủ mà được sử dụng theo nhiều cách khác

nhau qua nhóm người kiểm thử phần mềm chuyên nghiệp. Kiểm thử tải nói chúng hướng tới


27


việc thực hành của mô hình mong đợi cách dùng của 1 chương trình phần mềm bởi sự mô

phỏng đa người sử dụng truy nhập vào những dịch vụ trùng nhau của chương trình. Kiểm

thử này có liên quan nhiều tới hệ thống đa người sử dụng, thường xây dựng cho mô hình

khách/ chủ như máy chủ web. Tuy nhiên, các hệ thống phần mềm khác cũng có thể được

kiểm thử tải. Ví dụ, 1 bộ xử lý từ hoặc bộ soạn thảo đồ hoạ có thể bị bắt buộc đọc 1 tài liệu

lớn, hoặc 1 gói tài chính có thể bị bắt buộc phát sinh 1 báo cáo dựa trên độ rộng của vài năm

dữ liệu. Sự kiểm thử tải chính xác nhất xuất hiện trên thực tế, hơn lý thuyết và các kết quả.

Khi sự tải đặt trên hệ thống được phát triển ngoài những cách dùng bình thường, để kiểm tra

sự đáp lại của hệ thống ở mức cao khác thường hoặc đỉnh tải, nó được biết như kiểm thử áp

lực. Tải thông thường là lớn mà điều kiện lỗi là kết quả được mong đợi, mặc dù không có

ranh giới rõ ràng nào tồn tại khi 1 hoạt động dừng kiểm thử tải và trở thành kiểm thử áp lực.

Giới hạn thường được sử dụng tương đương với kiểm thử vận hành, kiểm thử tin cậy và

kiểm thử dung lượng.

e. Kiểm thử vận hành:

Với việc nhúng và hệ thời gian thực phần mềm cung cấp chức năng nhưng không phù

hợp với các yêu cầu thi hành đều là không chấp nhận được.

Kiểm thử thi hành được thiết kế để kiểm thử việc vận hành của phần mềm khi hệ thống

đựợc tích hợp.

Kiểm thử thi hành xuất hiện trong tất cả các bước của quá trình kiểm thử tuy nhiên chỉ khi

tất cả các phần tử của hệ thống đã được tích hợp thì kiểm thử mới được chắc chắn.Việc thi

hành đúng bao gồm cả số lượng và chất lượng.

Kiểm thử thi hành thường gắn liền với kiểm thử áp lực vì cả 2 thường đòi hỏi các dụng cụ

phần cứng và phần mềm chuyên dụng.Vì cần đo sự tổng hợp nguồn lực và nhờ dụng cụ

ngoại lai để giám sát các khoảng vận hành các sự kiên ngắt khi nó xuất hiện có thể lấy mẫu

các trạng thái máy .

Có thể làm bộc lộ các tình thế dẫn đến sự suy giảm hiệu năng hoặc thất bại hệ thống tiềm ẩn.

Tại sao kiểm thử vận hành là quan trọng ? Lý do chính là :

- Vận hành đã trở thành chỉ tiêu quan trọng của chất lượng sản phẩm và chấp

nhận sự nghiên cứu trong thị trường năng động và cạnh tranh ngày nay.


28


- Khách hàng đang trở nên cực kỳ phụ thuộc vào chất lượng của bề ngoài và

có cái nhìn rõ ràng về vận hành khách quan

- Ngày nay, mỗi khách hàng đang tìm kiếm 1 tốc độ lớn hơn, tính biến đổi

được, sự tin cậy, hiệu quả và sự chịu đựng của tất cả các ứng dụng – có thể

nó là đa lớp ứng dụng, ứng dụng web căn bản hoặc ứng dụng khách chủ.

Mục tiêu của kiểm thử vận hành:

- Để tiến hành giải thích những nguyên nhân cốt lõi của vận hành liên quan tới

những vấn đề thường thấy, hiếm có và nghĩ ra kế hoạch để giải quyết chúng.

- Để giảm bớt thời gian đáp ứng của ứng dụng với sự đầu tư nhỏ của phần

cứng.

- Để xác định nguyên nhân của các vấn đề gây ra trục trặc hệ thống và chỉnh

sửa chúng trước khi sản phẩm đưa vào hoạt động. Sửa chữa những lỗi trong

suốt các giai đoạn sau của phần mềm

- Những ứng dụng tiêu chuẩn, với 1 dạng để lọc chiến lược của công ty theo

hướng thu thập phần mềm lần sau.

- Đảm bảo rằng hệ thống mới phù hợp với các tiêu chuẩn vận hành theo lý

thuyết.

- Để rút ra sự so sánh giữa sự vận hành của 2 hay nhiều hệ thống.

Cấu trúc điển hình của mô hình kiểm thử vận hành :

- B1: Tập hợp các nhu cầu – Bước chính và quan trọng nhất của mô hình kiểm

thử vận hành.

- B2: Sự nghiên cứu hệ thống

- B3: Thiết kế chiến lược kiểm thử - có thể bao gồm như sau

Sự chuẩn bị của những tài liệu nhánh ngang

Bản thảo công việc

Cài đặt môi trường kiểm thử

Sự triển khai kiểm tra

- B4: Sự vận hành thử có thể bao gồm:


29


Đường gốc vận hành thử

Sự cải tiến vận hành thử

Chẩn đóan vận hành thử

- B5: Giải thích và chuẩn bị báo cáo sơ bộ

- B6: Thực thi lời giới thiệu từ bước 5

- B7: Chuẩn bị hoàn thành báo cáo

Những thuộc tính của sự thiết lập kiểm thử vận hành tốt

a) Tính khả dụng của tài liệu cơ sở trình bày chi tiết sự vận hành của hệ thống và tác

dụng như 1 đường cơ sở hữu hiệu. Tài liệu cơ sở này có thể thuận tiện cho việc so

sánh những dự tính khi điều kiện hệ thống xảy ra thay đổi.

b) Nền tảng của kiểm thử vận hành và môi trường kiểm thử nên được chia ra và sao

chép lại ở môi trường sản xuất xa nhất có thể.

c) Môi trường kiểm thử vận hành không nên liên kết với môi trường phát triển.

d) Tài nguyên dẫn tới lấp đầy mục tiêu như:

Sự triển khai biên chế với những hiểu biết âm thanh

Lập kế hoạch thận trọng và có hệ thống

Nghiên cứu cấu trúc hạ tầng hiện thời

Sự chuẩn bị chính xác

Giải thích khoa học

Báo cáo hiệu quả

Tuy nhiên, ngày nay có nhiều công ty đang bắt đầu làm việc với phần kiểm thử dưới môi

trường thực, điều này giúp họ thiết lập các kinh nghiệm khác nhau trong suốt hệ thống kiểm

thử và hệ thống thực.

Làm sao để tăng tốc cho kiểm thử vận hành :

a) Xác định điều kiện vận hành: Điều đầu tiên chúng ta cấn xác định điều kiện vận hành

liên quan tới yêu cầu chức năng như tốc độ, độ chính xác và nhu cầu nguồn dự trữ.

Nguồn dự trữ có thể là yêu cầu về bộ nhớ, yêu cầu nơi lưu trữ và hệ thống giao tiếp

băng thông.


30


b) Nghiên cứu về lược tả các thao tác : Lược tả thao tác bao gồm chi tiết kiểu dáng sử

dụng và môi trường hệ thống thực. Nó bao gồm sự mô tả phương pháp vận hành, môi

trường vận hành, phần tải, kỳ vọng giao dịch … Khi dữ liệu đòi hỏi là không thể, dữ

liệu từ đặc tả kiểm thử có thể là gần đúng nếu kiểm thử không được thực hiện dưới

môi trường thật.

c) Chuẩn bị những trường hợp kiểm thử vận hành tốt: Trong khi thiết kế các trường hợp

kiểm thử vận hành, sự cố gắng của chúng ta cần phải để :

Hiểu được các mức trình bày vận hành và sử dụng thông tin cho đánh giá tính

năng về sau

Đánh giá yêu cầu vận hành của hệ thống chống lại những khuôn mẫu xác định

Chỉ rõ hệ thống nhập vào và chờ đợi đầu ra, khi hệ thống được đưa ra để xác

định điều kiện tải như hình dạng của kiểm thử, môi trường kiểm thử và thời

gian kiểm thử …

Những cách kiểm thử vận hành:

Có 2 phương pháp để kiểm thử vận hành đó là:

1) Kiểm thử vận hành bằng tay:

Để phát triển sự tin cậy thích hợp, thời gian đáp ứng là 1 chỉ tiêu tốt của sự thực hiện

giao tác có thể được đo bằng vài phút trong suốt quá trình kiểm thử. Sử dụng đồng hồ

bấm giờ theo dõi bởi nhiều người là cách cũ nhất và có hiệu quả để đo lường kiểm thử

vận hành. Tuỳ thuộc vào cơ sở hạ tầng sẵn có, các phương tiện khác cũng có thể được

đưa ra.

2) Kiểm thử vận hành tự động: Nhiều cách tiếp cận có thể được thực hành ở đây. Chúng

ta có thể sử dụng phần mềm tự động cái có thể bắt chước hoạt động của người sử

dụng và có thể đồng thời ghi lại thời gian đáp ứng và nhiều hệ thống tham số khác

nhau như sự truy nhập của các đĩa lưu trữ, cách sử dụng của bộ nhớ và độ dài hàng

đợi cho nhiều thông điệp khác nhau.

Chúng ta có thể cung cấp dữ liệu tải bổ sung qua hệ thống, thông qua nhiều chương trình

hữu ích, chương trình tạo bản sao thông báo, lô dữ liệu và nhiều công cụ giao thức phân

tích.


31


Những quan tâm quan trọng để thiết kế các trường hợp kiểm thử tốt:

Ứng lực: để bảo dưỡng khả năng của 1 hệ thống hoặc các thành phần của nó để di

chuyển bên ngoài những giới hạn xác định của yêu cầu vận hành.

Khả năng: Để bao trùm số lượng lớn nhất có thể chứa đựng, hoặc tạo ra, hoặc

hoàn toàn chiếm giữ thực thể.

Hiệu quả: để chú ý tới hiệu quả đo lường mong muốn như tỷ lệ dung tích của dữ

liệu xử lý và số lượng tài nguyên tiêu thụ cho xử lý đặc biệt .

Thời gian đáp ứng: Chú ý tới những yêu cầu xác định của thời gian đáp ứng. Ví

dụ tổng thời gian trôi qua từ lúc sự kiện bắt đầu yêu cầu tới thời gian thu lại.

Độ tin cậy: phải có khả năng để chuyển giao kết quả chờ đợi với sự nhất quán cao

Độ rộng băng thông: phải có khả năng để đo lường và ước tính yêu cầu của độ

rộng băng thông. Ví dụ như số lượng dữ liệu đi qua hệ thống

Độ an toàn: phải có khả năng để ước lượng sự cẩn mật của người dùng, quyền

truy nhập và chú ý tới khả năng bảo trì trong hệ thống.

Tính phục hồi: phải có khả năng để đưa hệ thống dưới dự thử tải cao, và đo lường

thời gian nó cần trong trạng thái bình thường sau khi sự tải được rút đi.

Tính biến đổi được: Cần có khả năng để điều khiển nhiều tải hơn bằng cách thêm

nhiều thành phần phần cứng hơn mà không có bất kỳ sự thay đổi nào.

Chúng ta có thể tạo ra các trường hợp kiểm thử vận hành theo các bước:

Xác định quy trình phần mềm ảnh hưởng trực tiếp tới toàn bộ hệ thống vận hành.

Mỗi quá trình định nghĩa, chỉ định nghĩa đồng nhất dữ liệu đầu vào đặc trưng cái ảnh

hưởng tới hệ thống vận hành.

Tạo ra các kịch bản sử dụng bằng giá trị hiện thực xác định cho những đặc trưng dựa

trên sử dụng cuối. Bao gồm toàn bộ giá trị trung bình và kịch bản làm việc dày. Xác

định ô cửa quan sát trong thời gian này.

Nếu không có dữ kiện lịch sử để căn cứ vào dữ liệu đặc trưng, sử dụng việc dự đoán

dựa trên những yêu cầu, phiên bản cũ hoặc 1 hệ thống tương tự.


32


Nếu có 1 đặc trưng nơi giá trị đã ước lượng dạng 1 khoảng, lựa chọn giá trị có thể

đúng để bộc lộ thông tin hữu ích về hệ thống vận hành. Mỗi giá trị nên được tạo ra

trong 1 trường hợp kiểm thử riêng biệt.

Kiểm thử vận hành có thể được thực hiện qua cửa sổ của trình duyệt, hoặc trực tiếp trên

máy chủ. Nếu thực hiện trên máy chủ, trong 1 vài thời gian vận hành trình duyệt đó

không tạo ra 1 tài khoản.

f. Kiểm thử cấu hình:

Loại kiểm thử này bao gồm :

- Nền tảng hệ điều hành sử dụng

- Loại mạng kết nối

- Nhà cung cấp dịch vụ mạng

- Trình duyệt sử dụng (bao gồm cả các phiên bản)

Thực tế việc làm cho loại kiểm thử này đang được đảm bảo những yêu cầu và giả thuyết

được hiểu bởi nhóm phát triển, và môi trường kiểm thử với những sự lựa chọn này được đặt

đúng chỗ để kiểm tra nó 1 cách chính xác.

Phần III: Kiểm thử ứng dụng dựa trên Web


33


Chúng ta đã biết rằng kiểm thử là quá trình luyện thử phần mềm với ý định tìm ra lỗi. Triết

lý nền tảng này không thay đổi cho ứng dụng web. Trong thực tế, bởi vì ứng dụng và hệ

thống dựa trên web nằm trên mạng và liên tác với nhiều hệ điều hành khác, các trình duyệt,

các nền phần cứng và các giao thức truyền thông nên việc tìm lỗi biểu thị 1 thách thức có ý

nghĩa cho người kỹ sư web.

Cách tiếp cận tới kiểm thử web chấp nhận các nguyên lý cơ bản cho mọi kiểm thử web và áp

dụng các chiến lược, chiến thuật đã được khuyến cáo cho hệ thống hướng sự vật.

Các bước sau đây tóm tắt cách tiếp cận này:

1. Mô hình nội dung cho ứng dụng web được xem xét để phát hiện ra lỗi: Hoạt động

kiểm thử này là tương tự theo nhiều khía cạnh với việc biên tập 1 tài liệu viết. Trong

thực tế, 1 website lớn có thể thu nhận các dịch vụ biên tập chuyên nghiệp để phát hiện

các lỗi in ấn, lỗi chính tả, lỗi nhất quán nội dung, lỗi biểu diễn đồ hoạ và lỗi tham

chiếu chéo.

2. Mô hình thiết kế cho ứng dụng web được xem xét để phát hiện lỗi dẫn lái: Các trường

hợp sử dụng, được suy dẫn như 1 phần của hoạt động phân tích, cho phép người kỹ

sư web thực tập từng kịch bản sử dụng theo thiết kế kiến trúc và dẫn lái. Về bản chất,

những kiểm thử không thực hiện này giúp phát hiện ra lỗi trong dẫn lái (như 1 trường

hợp khi người sử dụng không thể đạt tới nút dẫn lái). Bên cạnh đó, các móc nối dẫn

lái được xem xét để đảm bảo rằng chúng tương ứng với những dẫn lái đã đặc tả trong

từng nút người dùng.

3. Các cấu phần xử lý đã lựa và các trang web đã được kiểm thử: Khi ứng dụng web

được xem xét, khái niệm về đơn vị được thay đổi. Mỗi trang web bao bọc 1 nội dung,

móc nối dẫn lái và phần tử xử lý (mẫu, chữ viết…). Không phải bao giờ cũng có thể

hay thực tế kiểm thử được từng đặc trưng này 1 cách riêng biệt. Trong nhiều trường

hợp, đơn vị kiểm thử nhỏ nhất là trang web. Không giống như việc kiểm thử đơn vị

của phần mềm quy ước, có khuynh hướng hội tụ vào chi tiết thuật toán của modul và

dữ liệu chảy qua giao diện modul, việc kiểm thử mức trang cho ứng dụng web được

hướng theo nội dung, xử lý và móc nối được bao bọc bởi trang web.

4. Kiến trúc được xây dựng và kiểm thử tích hợp được tiến hành: Chiến lược cho việc

kiểm thử tích hợp tuỳ thuộc vào kiến trúc đã được chọn cho ứng dụng web. Nếu ứng


34


dụng web đã được thiết kế theo cấu trúc tuyến tính, lưới hay cấp bậc đơn giản, thì tích

hợp các trang web tương tự như chúng ta tích hợp các modul trong các phần mềm

quy ước. Việc kiểm thử dựa trên các mạch có thể được dùng để tích hợp tập các

trang web được yêu cầu để đáp ứng cho biến cố người dùng. Mỗi mạch lại được tích

hợp và kiểm thử riêng rẽ. Kiểm thử rà lại được áp dụng để đảm bảo không hiệu quả

phụ nào xuất hiện. Các trường hợp kiểm thử được suy dẫn để phát hiện lỗi trong sự

hợp tác.

5. Ứng dụng web đã lắp ráp được kiểm thử cho chức năng toàn thể và việc chuyển giao

nôi dung: Giống như việc làm hợp lệ các hệ thống, các quy ước và ứng dụng dựa trên

web hội tụ vào những hành động người dùng thấy được và người dùng nhận biết được

từ hệ thống. Để trợ giúp trong việc suy ra các kiểm thử hợp lệ, người kiểm thử phải

dựa vào các trường hợp sử dụng. Trường hợp sử dụng cung cấp kịch bản có nhiều khả

năng làm lộ ra lỗi trong yêu cầu tương tác với người sử dụng.

6. Ứng dụng web được cài đặt trong nhiều cấu hình môi trường khác nhau và được kiểm

thử cho tính tương hợp với từng cấu hình: ma trận tham chiếu chéo xác định tất cả các

hệ điều hành có thể có, các trình duyệt, các nền phần cứng và các giao thức truyền

thông được tạo ra. Sau đó, việc kiểm thử được tiến hành để phát hiện lỗi liên kết với

từng cấu hình có thể có.

7. Ứng dụng web được kiểm thử bằng việc người dùng điều phối và kiểm soát: 1 số

đông người dùng được chọn ra, ứng dụng web được thực tập bởi những người dùng

này và kết quả tương tác của họ với hệ thống được đánh giá về lỗi nội dung và việc

dẫn lái, mối quan tâm sử dụng, mối quan tâm tương tác và tính tin cậy của ứng dụng

web cùng hiệu năng.

Bởi vì nhiều ứng dụng web phát triển liên tục nên tiến trình kiểm thử là hoạt động tiếp

diễn, do các nhân viên hỗ trợ web tiến hành, những người dùng kiểm thử rà lại được suy

dẫn ra từ các kiểm thử được phát triển khi ứng dụng web lần đầu tiên được chế tạo.


35

Documents

Kiểm thử hệ thống