Nghiên cứu quy trình và phương pháp kiểm thử Unit Test và TDD

Kiểm thử phần mềm cũng có thể được ghi như quá trình kiểm chứng và thẩmđịnh rằng một chương trình phần mềm / ứng dụng / sản phẩm:  Đáp ứng các yêu cầu chức năng và kỹ thuật và hướng dẫn

BM CễNG NGHỆ THễNG TIN

BÁO CÁO CHUYấN ĐỀ TỐT NGHIỆP

Tên đề tài:

NGHIấN CỨU QUY TRèNH và PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM UNIT TEST, TDD

Sinh viờn thực hiện: VŨ THỊ THU TRANG

Giảng viờn hướng dẫn : Th.s NGUYỄN TRUNG TUẤN

Hà Nội 08/2011

MỤC LỤC

LỜI NÓI ĐẦU 1

CHƯƠNG 1: GIỚI THIỆU CHUNG VỀ CƠ SỞ THỰC TẬP 2 1.1 Giới thiệu chung về công ty cổ phần Thiên Đức 2 1.2 Lĩnh vực hoạt động của công ty cổ phần Thiên Đức 3 1.3 Sơ đồ tổ chức của công ty 3 1.4 Mục tiêu của công ty 4 CHƯƠNG 2: NGHIÊN CỨU QUY TRÌNH VÀ PP KIỂM THỬ 5 1 Tổng quan 5 2 Các định nghĩa 5 3 Kiểm thử phần mềm 6 4 Các thuật ngữ 7 5 So sánh giữa thẩm tra và xác nhận 9 6 Vòng đời 9 7 Phạm vi 9 8 Kiểm thử chức năng - phi chức năng 10

9 Lỗi và Hỏng 10

10 Phát hiện lỗi 11

11 Khả năng tương thích 11

12 Kiểm thử tĩnh và động 12

13 Các đội kiểm thử PM 12

14 Quản lý chất lượng PM 12

15 Phương pháp kiểm thử 13

15.1 Kiểm nghiệm hộp trắng 13

15.2 Kiểm nghiệm hộp đen 13

16 Các cấp độ kiểm thử 14

16 1.Kiểm thử đơn vị 14

3.6 Lỗ hổng 48

1.3 Test Case cho phần Điều động, khen thưởng/ kỷ luật 55

LỜI NÓI ĐẦU

Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một sốđánh giá là còn yếu của các công ty phần mềm Việt Nam Một số công ty trongnước hiện đã đạt các chuẩn quốc tế CMM/CMMI trong nâng cao năng lực vàquản lý chất lượng phần mềm, song chỉ đếm được trên đầu ngón tay, và hiệncũng chỉ gói gọn trong vài công ty gia công cho thị trường nước ngoài

Lâu nay, nói đến chất lượng phần mềm, không ít người nghĩ ngay đếnvấn đề là xác định xem phần mềm đó có phát sinh lỗi hay không, có "chạy" đúngnhư yêu cầu hay không và cuối cùng thường quy về vai trò của hoạt động kiểm thửphần mềm (software testing) như là hoạt động chịu trách nhiệm chính

Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quantâm nội tình của hoạt động phát triển phần mềm, điều họ cần quan tâm là liệu sảnphẩm cuối cùng giao cho họ có đúng hạn hay không và làm việc đúng như họmuốn hay không

Với thực tế trên, Em chọn đề tài “ Nghiên cứu quy trình và phương pháp kiểm thử Unit Test và TDD” cho báo cáo thực tập

Em xin b à y t ỏ l ời cảm ơn chân thành tới Thạc Sĩ Nguyễn Trung Tuấn,người đã tận tình hướng dẫn em trong suốt quá trình em thực hiện đề tài Em xingửi lời cảm ơn sâu sắc tới ban lãnh đạo và toàn thể các cán bộ công ty cổphần Thiên Đức nơi em đã thực tập, các thầy cô trong khoa CNTT đã cung cấp một

số tài liệu, số liệu để em có thể hoàn thành được đề tài này

Hà nội, ngày tháng năm 2011

Sinh viên

Vũ Thị Thu Trang

CHƯƠNG 1 GIỚI THIỆU CHUNG VỀ CƠ SỞ THỰC TẬP

1.1 Giới thiệu chung về công ty cổ phần Thiên Đức

Công ty cổ phần Thiên Đức là một công ty trẻ có tiềm năng phát triển tronglĩnh vực viễn thông và công nghệ thông tin tại tỉnh Vĩnh Phúc Tuy mới thành lậpnhưng công ty đã có những bước tiến đáng kể, công ty chuyên cung cấp các giải phápviễn thông tổng thể cho các doanh nghiệp, các tổ chức tài chính, khách sạn với độingũ chuyên nghiệp phát triển phần mềm ( website, phần mềm quản lý, mã vạch ).Công ty đã và đang tiếp tục khai thác những tiềm năng của công nghệ Internet, trithức và nội lực sáng tạo để tạo nên những sản phẩm và dịch vụ phần mềm chất lượngcao phục vụ góp phần cho sự phát triển kinh tế của tỉnh Vĩnh Phúc

Tóm tắt về công ty:

Tên công ty: Công ty cổ phần Thiên Đức

Tên viết tắt: Thiên Đức ,JSC

Trụ sở chính:Số 68, đường Mê Linh, phường Liên Bảo, tp Vĩnh Yên, tỉnh Vĩnh Phúc

Vốn điều lệ: 5tỷ VNĐ

Nguồn nhân lực: 36 người

Để xây dựng uy tín của Thiên Đức ,JSC, công ty luôn coi trọng công tác quản

lý doanh nghiệp, mọi hoạt động đều hướng tới thực hiện tốt, năng động và hiệu quảcủa các dự án khách hàng Với một tập thể kỹ sư, cử nhân có khả năng làm chủ, nắmbắt nhanh các công nghệ mới, có phong cách làm việc khoa học, tâm huyết, lao độnghăng say và luôn luôn đoàn kết một lòng vì công việc Đội ngũ nhân sự công ty lànhân tố quan trọng, phục vụ tận tuỵ và luôn làm hài lòng khách hàng, luôn suy nghĩ

và hành động nhằm giải quyết các vấn đề của khách hàng đặt ra một cách hiệu quảnhất

Yếu tố quan trọng dẫn đến thành công trong kinh doanh công ty là sự chủđộng quan hệ hợp tác với các đối tượng trong và ngoài nước Được sự hỗ trợ công ty

đã nắm bắt được các công nghệ mới, đáp ứng tốt nhất cho các nhu cầu của kháchhàng

1.2 Lĩnh vực hoạt động của công ty cổ phần Thiên Đức

* Viễn thông:

- Cung cấp, tư vấn các giải pháp tổng đài viễn thông

- Cung cấp, tư vấn các giải pháp thiết bị mạng viễn thông

- Cung cấp hệ thống tính cước, truy nhập cho các hệ thống tổng đài, hệ thống truynhập Internet qua cáp Ethernet, Wifi, Wimax

- Lắp đặt, bảo trì, bảo dưỡng các hệ thống viễn thông ( thiết bị mạng viễn thông, cápquang, mạng không dây, các hệ thống viễn thông khác)

* Công nghệ thông tin:

- Tư vấn giải pháp phát triển hệ thống phần mềm

- Cung cấp, thiết kế và gia công phần mềm

- Xác thực và bảo mật trong giao dịch online

- Quảng cáo trực tuyến và khai thác các dịch vụ giá trị gia tăng trên nền VAS và Web

1.3 Sơ đồ tổ chức của công ty cổ phần Thiên Đức

Công ty có đội ngũ nhân viên đầy nhiệt huyết và giàu kinh nghiệm về lĩnh vựccông nghệ thông tin và truyền thông, đã từng tham gia nhiều dự án tin học viễnthông

ty đã và đang phát triển, cải thiện và nâng cao chất lượng sản phẩm, áp dụng các côngnghệ mới, hoàn thiện dịch vụ, tiến đến thỏa mãn các yêu cầu của khách hàng với chấtlượng cao nhất Mục tiêu của công ty là mở rộng thị trường, tập trung phát triển quản

lý cho hệ thống các doanh nghiệp lớn, các tập đoàn sản xuất có quy mô lớn và phức tạphơn

CHƯƠNG 2

Phó Giám đốc

Phòng Viễn thông

NGHIÊN CỨU QUY TRÌNH VÀ PHƯƠNG PHÁP KIỂM THỬ

PHẦN MỀM (Software Test)

1 Tổng quan

Kiểm thử có thể không bao giờ hoàn toàn xác định tất cả các khiếm khuyết

trong phần mềm Thay vào đó, nó cung cấp được một lời phê bình hay so sánh, so sánh

phát biểu và hành vi của sản phẩm đối với tài liệu hướng dẫn - nguyên tắc hoặc các cơchế mà người ta có thể nhận ra một vấn đề Tài liệu hướng dẫn có thể bao gồm (nhưngkhông giới hạn) chi tiết kỹ thuật, hợp đồng, sản phẩm tương đương, các phiên bảntrước của cùng một sản phẩm, suy luận về dự định hoặc dự kiến mục đích, người dùnghoặc khách hàng mong đợi, các tiêu chuẩn liên quan, pháp luật, hoặc tiêu chuẩn khác

Tất cả các sản phẩm phần mềm có một đối tượng mục tiêu Ví dụ, các khán giảdành cho phần mềm trò chơi video là hoàn toàn khác nhau từ phần mềm ngân hàng Vìvậy, khi một tổ chức phát triển hoặc đầu tư vào một sản phẩm phần mềm, kiểm thử cóthể đánh giá liệu các sản phẩm phần mềm sẽ được chấp nhận cho người dùng cuối,

khán giả mục tiêu của mình, người mua sản phẩm, và các bên liên quan khác Kiểm thử phần mềm cố gắng đưa ra đánh giá này

Một nghiên cứu tiến hành bởi NIST năm 2002 báo cáo rằng chi phí cho lỗi phầnmềm ở Mỹ 59.5 tỷ Đô la Mỹ mỗi năm Hơn một phần ba chi phí này có thể tránh đượcnếu sử dụng phần mềm kiểm thử tốt hơn

2 Các định nghĩa

“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống Chúng ta dù cố gắng đếnmức nào thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không cóthể lúc nào cũng viết được những đoạn mã không có lỗi Tính trung bình, ngay cảmột lập trình viên loại tốt thì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh Người ta ước

lượng rằng việc kiểm tra để tìm ra các lỗi này chiếm phân nửa khối lượng công việc

phải làm để có được một phần mềm hoạt động được” (Software Testing

Techniques, Second Edition, by Boris Beizer, Van Nostrand Reinhold, 1990, ISBN 1850328803).

Trên đây là một nhận định về công việc kiểm nghiệm (testing) chương trình

Thật vậy, ngày nay càng ngày các chương trình (các phần mềm) càng trởlên phức tạp và đồ sộ Việc tạo ra một sản phẩm có thể bán được trên thị trường đòihỏi sự nổ lực của hàng chục, hàng trăm thậm chí hàng ngàn nhân viên Số lượngdòng mã lên đến hàng triệu Và để tạo ra một sản phẩm thì không phải chỉ do một tổchức đứng ra làm từ đầu đến cuối, mà đòi hỏi sự liên kết, tích hợp của rất nhiều sảnphẩm, thư viện lập trình, … của nhiều tổ chức khác nhau… Từ đó đòi hỏi việckiểm nghiệm phần mềm càng ngày càng trở nên rất quan trọng và rất phức tạp

Song song với sự phát triển các công nghệ lập trình, các ngôn ngữ lập trình…thì các công nghệ và kỹ thuật kiểm nghiệm phần mềm ngày càng phát triển vàmang tính khoa học Bản báo cáo này với mục đích là tập hợp, nghiên cứu, phântích các kỹ thuật, các công nghệ kiểm nghiệm phần mềm đang được sử dụng vàphát triển hiện nay

3 Kiểm thử phần mềm:

Là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúngmôi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liênquan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy Mục đíchcủa kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảohiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau

Kiểm thử phần mềm cũng có thể được ghi như quá trình kiểm chứng và thẩmđịnh rằng một chương trình phần mềm / ứng dụng / sản phẩm:

 Đáp ứng các yêu cầu chức năng và kỹ thuật và hướng dẫn thiết kế và pháttriển của nó

 Các công việc như dự kiến

 Có thể được thực hiện với những đặc điểm tương tự

Kiểm thử phần mềm tùy thuộc vào phương pháp thử nghiệm được sử dụng, cóthể được thực hiện tại bất kỳ thời gian trong quá trình phát triển Tuy nhiên, hầu hếtcác nỗ lực thử nghiệm xảy ra sau khi các yêu cầu đã được xác định và quá trình mã hóa

đã được hoàn thành Như vậy, các phương pháp thử nghiệm được quy định bởi cácphương pháp phát triển phần mềm

Mô hình phát triển phần mềm khác nhau sẽ tập kiểm thử tại các thời điểm khácnhau trong quá trình phát triển Mô hình phát triển mới hơn, chẳng hạn như Agile,thường sử dụng phương pháp TDD và đặt một phần gia tăng của các thử nghiệm vàotay các nhà phát triển, trước khi nó đến tay đội kiểm thử Trong một mô hình truyềnthống, hầu hết các thực hiện thử nghiệm xảy ra sau khi các yêu cầu đã được xác định

và quá trình mã hóa đã được hoàn thành

• Sai sót do đưa ra dư thừa – chúng ta đưa một vài thứ không chính xác vào

mô tả yêu cầu phần mềm

• Sai sót do bỏ sót – Người thiết kế có thể gây ra sai sót do bỏ sót, kết quả làthiếu một số phần đáng ra phải có trong mô tả yêu cầu phần mềm

4.3 Hỏng hóc (Failure):

– Xảy ra khi sai sót được thực thi (Khi thực thi chương trình tại các nơi bị saithì sẽ xảy ra trạng thái hỏng hóc)

4.4 Kết quả không mong đợi, hậu quả (Incident)

– Là những kết quả do sai sót đem đến Hậu quả là các triệu chứng liên kếtvới một hỏng hóc và báo hiệu cho người dùng biết sự xuất hiện của hỏng hóc

4.5 Trường hợp thử (Test case)

– Trường hợp thử được liên kết tương ứng với hoạt động của chương trình.Một trường hợp thử bao gồm một tập các giá trị đầu vào và một danh sách các kếtquả đầu ra mong muốn

5 So sánh giữa Thẩm tra và Xác nhận:

ƒ Thẩm định: thẩm định quan tâm đến việc ngăn chặn lỗi giữa các công đoạn

ƒ Kiểm chứng: kiểm chứng quan tâm đến sản phẩm cuối cùng không còn lỗi

6 Vòng đời của việc kiểm nghiệm (testing life cycle):

Bảng dưới đây mô tả các công đoạn phát triển một phần mềm và cách khắc

phục lỗi Lỗi có thể xảy ra trong tất cả các công đoạn từ “Mô tả yêu cầu”, “Thiết kế”

đến “Lập trình” Từ công đoạn này chuyển sang công đoạn khác thường nảy sinh các

sai sót (do dư thừa hoặc thiếu theo mô tả yêu cầu) Đến công đoạn kiểm nghiệm

chúng ta sẽ phát hiện ra các hậu quả (các kết quả không mong muốn) Quá trình sửa

lỗi bao gồm “phân loại lỗi”, “cô lập lỗi” (tìm ra nguyên nhân và nơi gây lỗi), đề ra

“giải pháp sửa lỗi” và cuối cùng là khắc phục lỗi

Hình 2.1

Mục đích chính của kiểm thử là phát hiện các lỗi phần mềm đó là các khuyết

điểm có thể được phát hiện và sửa chữa Đây là một sự theo dõi quan trọng Kiểm thử

không thể thiết lập một chức năng sản phẩm đúng theo tất cả các điều kiện nhưng có

Vòng đời của kiểm nghiệm

Phân loại lỗiSai sót

Kiểm nghiệm

thể thiết lập cho nó hoạt động đúng theo các điều kiện cụ thể Phạm vi của kiểm thửphần mềm thường bao gồm kiểm tra mã cũng như thực thi mã trong các môi trườngkhác nhau và điều kiện cũng như xem xét các khía cạnh của mã như: hiện nó thực hiệnnhững gì và làm những gì nó cần phải làm Trong môi trường phát triển phần mềmhiện tại, bộ phận thử nghiệm có thể được tách biệt với nhóm phát triển Các thành viêntrong đội kiểm thử có vai trò khác nhau Thông tin thu được từ thử nghiệm phần mềm

có thể được sử dụng để sửa các lỗi trong quá trình phát triển phần mềm

8 Kiểm thử chức năng - kiểm thử phi chức năng

Chức năng kiểm thử liên quan đến hoạt động kiểm thử một hành động cụ thểhoặc chức năng của mã này Đây là những mã được tìm thấy trong tài liệu yêucầu.Chức năng kiểm thử trả lời câu hỏi "người sử dụng có thể làm được tính năng này"hoặc "không thực hiện được tính năng đặc biệt này"

Kiểm thử phi chức năng đề cập đến các khía cạnh của phần mềm mà có thểkhông được liên quan đến một chức năng cụ thể hoặc hành động của người dùng,chẳng hạn như khả năng mở rộng hoặc bảo mật Kiểm thử phi chức năng có xu hướng

để trả lời những câu hỏi như "có bao nhiêu người có thể đăng nhập cùng một lúc"

9 Lỗi và hỏng

Không phải tất cả lỗi phần mềm gây ra bởi mã lỗi Một trong những nguồn gốccủa các khuyết điểm thông thường là do khoảng cách yêu cầu, ví dụ như, yêu cầukhông được công nhận, dẫn đến lỗi của thiếu sót của người thiết kế chương trình Mộtnguồn gốc của thiếu sót yêu cầu là yêu cầu phi chức năng như khả năng kiểm thử, khảnăng mở rộng, bảo trì, khả năng sử dụng, hiệu suất, và bảo mật

Phần mềm xảy ra lỗi trong xử lý: Lập trình viên gây ra lỗi (sai lầm), kết quả cómột lỗi trong mã nguồn Nếu lỗi này được thực hiện, trong những tình huống nhất định

hệ thống sẽ tạo ra kết quả sai, gây ra một thất bại Không phải tất cả các khuyết điểmnhất thiết sẽ dẫn đến thất bại Ví dụ, lỗi trong mã đã chết sẽ không bao giờ dẫn đến thấtbại Một khuyết điểm có thể chuyển thành thất bại một khi môi trường thay đổi Ví dụ

về những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên một phầncứng nền tảng mới, thay đổi trong nguồn dữ liệu hay tương tác với phần mềm khácnhau Một khiếm khuyết duy nhất có thể dẫn đến một loạt các triệu chứng thất bại

10 Phát hiện lỗi:

Thông thường chi phí cho việc tìm lỗi rẻ hơn việc sửa lỗi Bảng sau đây chothấy chi phí sửa chữa các lỗi phụ thuộc vào theo giai đoạn được tìm thấy Ví dụ, nếumột vấn đề trong các yêu cầu chỉ được tìm thấy sau phát hành, sau đó nó sẽ có chi phí1-10 lần để sửa chữa hơn là nếu nó đã được tìm thấy bởi các xem xét các yêu cầu

Kiểm thử hệ thống

Phát hành Thời gian giới

Ví dụ, trong một trường hợp thiếu tính tương thích ngược, điều này có thể xảy ra bởi vìcác lập trình viên phát triển và thử nghiệm phần mềm duy nhất trên phiên bản mới nhấtcủa môi trường mục tiêu, mà không phải tất cả người dùng có thể chạy Điều này dẫnđến hậu quả không lường trước rằng phiên bản mới nhất không có chức năng trên cácphiên bản trước đó của môi trường mục tiêu, hoặc trên phần cứng cũ hơn phiên bản

trước của môi trường mục tiêu là khả năng sử dụng Đôi khi các vấn đề như vậy có thểđược cố định bằng cách chủ động trừu tượng hóa chức năng hệ điều hành vào mộtchương trình riêng biệt module hay thư viện.

12 Kiểm thử tĩnh và động

Có nhiều phương pháp để kiểm thử phần mềm: Trao đổi, thảo luận nhóm pháttriển, hoặc xét duyệt được coi là kiểm thử tĩnh, trong khi thực hiện mã lập trình vớimột tập hợp các trường hợp thử nghiệm được gọi là thử nghiệm động Kiểm thử tĩnh cóthể được bị bỏ đi Kiểm thử động diễn ra khi chương trình chính nó là sử dụng lần đầutiên (mà thường được coi là sự khởi đầu của giai đoạn thử nghiệm) Kiểm thử động cóthể bắt đầu trước khi chương trình được hoàn thành 100% để kiểm tra phần cụ thể của

mã (mô-đun hoặc chức năng) Kỹ thuật tiêu biểu cho điều này là một trong hai phươngpháp Stubs/ drives hoặc thực hiện từ một trình gỡ rối

13 Các đội kiểm thử phần mềm

Kiểm thử phần mềm được thực hiện bằng cách thử phần mềm Cho đến nhữngnăm 1980 thuật ngữ "phần mềm kiểm thử" đã được sử dụng chung, nhưng sau đó nócũng được xem là một nghề riêng biệt Về các thời kỳ và các mục tiêu khác nhau trong

kiểm thử phần mềm, vai trò khác nhau đã được thiết lập: quản lý, Nhóm trưởng, kiểm

thử thiết kế, Kiểm thử viên, phát triển tự động hóa, và quản trị kiểm thử.

14 Quản lý chất lượng phần mềm (SQA)

Mặc dù gây tranh cãi, kiểm thử phần mềm có thể được xem như là một phầnquan trọng trong quá trình quản lý chất lượng phần mềm (SQA) Trong SQA, phầnmềm chuyên xử lý và kiểm thử viên có một cái nhìn rộng hơn về phần mềm và pháttriển của nó Họ kiểm tra và thay đổi quy trình công nghệ phần mềm riêng của mình để

giảm số lượng lỗi mà kết thúc trong các phần mềm được gửi: được gọi là Tỷ lệ lỗi

Điều tạo nên "tỷ lệ lỗi chấp nhận được" phụ thuộc vào bản chất của các phầnmềm; Một trò chơi mô phỏng chuyến bay video sẽ có sự khoan dung lỗi cao hơn nhiều

so với phần mềm cho một máy bay

Mặc dù có liên kết chặt chẽ với SQA, đội kiểm thử thường tồn tại độc lập, và cóthể không có chức năng SQA trong một số công ty

Kiểm thử phần mềm là một công việc dự định để phát hiện lỗi trong phần mềmbằng cách so sánh kết quả của một chương trình máy tính dự kiến với kết quả thực tếcủa nó trong một tập hợp của các yếu tố đầu vào Ngược lại, QA (đảm bảo chất lượng)

là việc thực hiện các chính sách và thủ tục nhằm ngăn ngừa các khuyết điểm ngay từđầu

15 Phương pháp kiểm thử

15.1 Kiểm nghiệm hộp trắng (white-box testing)

Còn gọi là kiểm nghiệm cấu trúc Kiểm nghiệm theo cách này là loại kiểmnghiệm sử dụng các thông tin về cấu trúc bên trong của ứng dụng Việc kiểm nghiệmnày dựa trên quá trình thực hiện xây dựng phần mềm

Tiêu chuẩn của kiểm nghiệm hộp trắng phải đáp ứng các yêu cầu như sau:

 Bao phủ dòng lệnh: mỗi dòng lệnh ít nhất phải được thực thi 1 lần

 Bao phủ nhánh: mỗi nhánh trong sơ đồ điều khiển (control graph) phải

được đi qua một lần

 Bao phủ đường: tất cả các đường (path) từ điểm khởi tạo đến điểm cuối

cùng trong sơ đồ dòng điều khiển phải được đi qua

15.2 Kiểm nghiệm hộp đen ( black-box testing )

Còn gọi là kiểm nghiệm chức năng Việc kiểm nghiệm này được thực hiện

mà không cần quan tâm đến các thiết kế và viết mã của chương trình Kiểmnghiệm theo cách này chỉ quan tâm đến chức năng đã đề ra của chương trình Vì

vậy kiểm nghiệm loại này chỉ dựa vào bản mô tả chức năng của chương trình, xemchương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng haykhông mà thôi.

Kiểm nghiệm hộp đen dựa vào các định nghĩa về chức năng của chương trình.Các trường hợp thử nghiệm (test case) sẽ được tạo ra dựa nhiều vào bản mô tả chứcnăng chứ không phải dựa vào cấu trúc của chương trình

Những loại bài kiểm tra thường được viết bởi nhà phát triển khi họ làm việc trên

mã (trắng-box phong cách), để đảm bảo rằng các chức năng cụ thể là làm việc như mongđợi Một chức năng có thể có nhiều thử nghiệm, để bắt kịp các trường hợp góc, ngànhkhác trong các mã Đơn vị kiểm tra một mình không thể xác minh các chức năng củamột phần mềm, mà là được sử dụng để đảm bảo rằng các khối xây dựng phần mềm sửdụng làm việc độc lập với nhau

Đơn vị kiểm tra còn được gọi là thành phần thử nghiệm

16.2 Kiểm thử hệ thống

Hệ thống gồm hai hoặc nhiều thành phần tích hợp nhằm thực hiện các chức nănghoặc đặc tính của hệ thống Sau khi tích hợp các thành phần tạo nên hệ thống, quá trìnhkiểm thử hệ thống được tiến hành Trong quá trình phát triển lặp đi lặp lại, kiểm thử hệ

thống liên quan với kiểm thử một lượng công việc ngày càng tăng để phân phối chokhách hàng; trong quy trình thác nước, kiểm thử hệ thống liên quan với kiểm thử toàn

 Kiểm thử phát hành: Một phiên bản của hệ thống có thể được pháthành tới người dùng được kiểm thử Đội kiểm thử tập trung vào việc hợp lệ cácyêu cầu của hệ thống và đảm bảo tính tin cậy của hệ thống Kiểm thử phát hànhthường là kiểm thử “hộp đen”, đội kiểm thử tập trung vào mô tả các đặc tính hệthống có thể làm được hoặc không làm được Các vấn đề được báo cáo cho đội pháttriển để gỡ lỗi chương trình Khách hàng được bao hàm trong kiểm thử phát hành,thường được gọi là kiểm thử chấp nhận Nếu hệ thống phát hành đủ tốt, khách hàng

có thể chấp nhận nó để sử dụng

Về cơ bản, bạn có thể nghĩ kiểm thử tích hợp như là kiểm thử hệ thống chưađầy đủ bao gồm một nhóm các thành phần Kiểm thử phát hành liên quan đếnkiểm thử hệ thống phát hành có ý định phân phối tới khách hàng Tất nhiên, có sựgối chồng lên nhau, đặc biệt khi phát triển hệ thống và hệ thống đuợc phát hành khichưa hoàn thành Thông thường, sự ưu tiên hàng đầu trong kiểm thử tích hợp làphát hiện ra khiếm khuyết trong hệ thống và sự ưu tiên hàng đầu trong kiểm thử hệthống là làm hợp lệ các yêu cầu của hệ thống Tuy nhiên trong thực tế, có vài kiểmthử hợp lệ và vài kiểm thử khiếm khuyết trong các quá trình

16.3 Kiểm thử tích hợp

Quá trình kiểm thử tích hợp bao gồm việc xây dựng hệ thống từ các thành

phần và kiểm thử hệ thống tổng hợp với các vấn đề phát sinh từ sự tương tác giữacác thành phần Các thành phần được tích hợp có thể trùng với chính nó, các thànhphần có thể dùng lại được có thể thêm vào các hệ thống riêng biệt hoặc thành phầnmới được phát triển Với rất nhiều hệ thống lớn, có tất cả 3 loại thành phần được sửdụng Kiểm thử tích hợp kiểm tra trên thực tế các thành phần làm việc với nhau,được gọi là chính xác và truyền dữ liệu đúng vào lúc thời gian đúng thông qua giaodiện của chúng.

Hệ thống tích hợp bao gồm một nhóm các thành phần thực hiện vài chức năngcủa hệ thống và được tích hợp với nhau bằng cách gộp các mã để chúng làm việccùng với nhau Thỉnh thoảng, đầu tiên toàn bộ khung của hệ thống được phát triển,sau đó các thành phần được gộp lại để tạo nên hệ thống Phương pháp này được gọi

là tích hợp từ trên xuống (top-down) Một cách lựa chọn khác là đầu tiên bạn tích hợpcác thành phần cơ sở cung cấp các dịch vụ chung, như mạng, truy cập cơ sở dữ liệu,sau đó các thành phần chức năng được thêm vào Phương pháp này được gọi làtích hợp từ dưới lên (bottom-up) Trong thực tế, với rất nhiều hệ thống, chiến lượctích hợp là sự pha trộn các phương pháp trên Trong cả hai phương pháp top-down

và bottom-up, bạn thường phải thêm các mã để mô phỏng các thành phần khác và chophép hệ thống thực hiện

Một vấn đề chủ yếu nảy sinh trong lúc kiểm thử tích hợp là các lỗi cục bộ Cónhiều sự tương tác phức tạp giữa các thành phần của hệ thống, và khi một đầu ra bấtthường được phát hiện, bạn có thể khó nhận ra nơi mà lỗi xuất hiện Để việc tìmlỗi cục bộ được dễ dàng, bạn nên thường xuyên tích hợp các thành phần của hệ thống

và kiểm thử chúng Ban đầu, bạn nên tích hợp một hệ thống cấu hình tối thiểu vàkiểm thử hệ thống này Sau đó bạn thêm dần các thành phần vào hệ thống đó vàkiểm thử sau mỗi bước thêm vào

Hình 3.3 Kiểm thử tích hợp lớn dần Hình 2.3

Trong ví dụ trên hình 2.4, A,B,C,D là các thành phần và T1, T2, T3, T4, T5

là tập các thử nghiệm kết hợp các đặc trưng của hệ thống Đầu tiên, các thànhphần A và B được kết hợp để tạo nên hệ thống (hệ thống cấu hình tối thiểu), vàcác thử nghiệm T1, T2, T3 được thực hiện Nếu phát hiện có khiếm khuyết, nó

sẽ được hiệu chỉnh Sau đó, thành phần C được tích hợp và các thử nghiệm T1,T2 và T3 được làm lặp lại để đảm bảo nó không tạo nên các kết quả không mongmuốn khi tương tác với A và B Nếu có vấn đề nảy sinh trong các kiểm thử này,

nó hầu như chắc chắn do sự tương tác với các thành phần mới Nguồn gốc của vấn

đề đã được khoanh vùng, vì vậy làm đơn giản việc tìm và sửa lỗi Tập thử nghiệmT4 cũng được thực hiện trên hệ thống Cuối cùng, thành phần D được tích hợp vào

hệ thống và kiểm thử được thực hiện trên các thử nghiệm đã có và các thử nghiệmmới

Khi lập kế hoạch tích hợp, bạn phải quyết định thứ tự tích hợp các thànhphần Trong một quá trình như XP, khách hàng cũng tham gia trong quá pháttriển, khách hàng quyết định các chức năng nên được thêm vào trong mỗi bướctích hợp hệ thống Do đó, tích hợp hệ thống được điều khiển bởi sự ưu tiên củakhách hàng Trong cách tiếp cận khác để phát triển hệ thống, khi các thành phần

và các thành phần riêng biệt được tích hợp, khách hàng có thể không tham giavào quá trình tích hợp hệ thống và đội tích hợp quyết định thứ tự tích hợp cácthành phần

Trong trường hợp này, một quy tắc tốt là đầu tiên tích hợp các thành phầnthực hiện hầu hết các chức năng thường sử dụng của hệ thống Điều này cónghĩa là các thành phần thường được sử dụng hầu hết đã được kiểm thử Ví dụ,trong hệ thống thư viện, LIBSYS, đầu tiên bạn nên tích hợp chức năng tìm kiếmtrong hệ thống tối thiểu, để người dùng có thể tìm kiếm các tài mà họ cần Sau

đó, bạn nên tích hợp các chức năng cho phép người dùng tải tài liệu từ trênInternet và dần thêm các thành phần thực hiện các chức năng khác của hệ thống

Tất nhiên, thực tế ít khi đơn giản như mô hình trên Sự thực hiện các chứcnăng của hệ thống có thể liên quan đến nhiều thành phần Để kiểm thử một đặctính mới, bạn có thể phải tích hợp một vài thành phần khác nhau Kiểm thử có thểphát hiện lỗi trong khi tương tác giữa các thành phần riêng biệt và các phần kháccủa hệ thống Việc sửa lỗi có thể khó khăn bởi vì một nhóm các thành phần thựchiện chức năng đó có thể phải thay đổi Hơn nữa, tích hợp và kiểm thử một thànhphần mới có thể thay đổi tương tác giữa các thành phần đã được kiểm thử Các lỗi

có thể được phát hiện có thể đã không được phát hiện trong khi kiểm thử hệ thốngcấu hình đơn giản

Những vấn đề này có nghĩa là khi một hệ thống tích hợp mới được tạo ra,cần phải chạy lại các thử nghiệm trong hệ thống tích hợp cũ để đảm bảo cácyêu cầu các thử nghiệm đó vẫn thực hiện tốt, và các kiểm thử mới thực hiện tốtcác chức năng mới của hệ thống Việc thực hiện kiểm thử lại tập các thử nghiệm

cũ gọi là kiểm thử hồi quy Nếu kiểm thử hồi quy phát hiện có vấn đề, thì bạnphải kiểm tra có lỗi trong hệ thống cũ hay không mà hệ thống mới đã phát hiện ra,hoặc có lỗi do thêm các chức năng mới

Rõ ràng, kiểm thử hồi quy là quá trình tốn kém, không khả thi nếu không có

sự hỗ trợ tự động Trong lập trình cực độ, tất cả các thử nghiệm được viết như

mã có thể thực thi, các đầu vào thử nghiệm và kết quả mong đợi được xác định

rõ và được tự động kiểm tra Khi được sử dụng cùng với một khung kiểm thử tựđộng như Junit (Massol và Husted, 2003), điều này có nghĩa là các thử nghiệm cóthể được tự động thực hiện lại Đây là nguyên lý cơ bản của lập trình cực độ, khitập các thử nghiệm toàn diện được thực hiện bất cứ lúc nào mã mới được tíchhợp và các mã mới này không được chấp nhận cho đến khi tất cả các thử nghiệm

được thực hiện thành công.

16.4 Kiểm thử phát hành

Kiểm thử phát hành là quá trình kiểm thử một hệ thống sẽ được phânphối tới các khách hàng Mục tiêu đầu tiên của quá trình này là làm tăng sự tincậy của nhà cung cấp rằng sản phẩm họ cung cấp có đầy đủ các yêu cầu Nếuthỏa mãn, hệ thống có thể được phát hành như một sản phẩm hoặc được phân phốiđến các khách hàng Để chứng tỏ hệ thống có đầy đủ các yêu cầu, bạn phải chỉ

ra nó có các chức năng đặc tả, hiệu năng, và tính tin cậy cao, nó không gặp saisót trong khi được sử dụng bình thường

Kiểm thử phát hành thường là quá trình kiểm thử hộp đen, các thử nghiệmđược lấy từ đặc tả hệ thống Hệ thống được đối xử như chiếc hộp đen, các hoạtđộng của nó chỉ có thể được nhận biết qua việc nghiên cứu đầu vào và đầu ra của

nó Một tên khác của quá trình này là kiểm thử chức năng, bởi vì người kiểm trachỉ tập trung xem xét các chức năng và không quan tâm sự thực thi của phầnmềm

Hình 2.5 Kiểm thử hộp đen

Hình 2.5 minh họa mô hình một hệ thống được kiểm thử bằng phươngpháp kiểm thử hộp đen Người kiểm tra đưa đầu vào vào thành phần hoặc hệthống và kiểm tra đầu ra tương ứng Nếu đầu ra không như dự báo trước (ví dụ,nếu đầu ra thuộc tập Oe), kiểm thử phát hiện một lỗi trong phần mềm.

Khi hệ thống kiểm thử được thực hiện, bạn nên thử mổ sẻ phần mềm bằngcách lựa chọn các trường hợp thử nghiệm trong tập Ie (trong hình 2 5) Bởi vì,mục đích của chúng ta là lựa chọn các đầu vào có xác suất sinh ra lỗi cao (đầu ranằm trong tập Oe) Bạn sử dụng các kinh nghiệm thành công trước đó và cácnguyên tắc kiểm thử để đưa ra các lựa chọn

Các tác giả như Whittaker (Whittaker, 2002) đã tóm lược những kinhnghiệm kiểm thử của họ trong một tập các nguyên tắc nhằm tăng khả năng tìm

ra các thử nghiệm khiếm khuyết Dưới đây là một vài nguyên tắc:

 Lựa chọn những đầu vào làm cho hệ thống sinh ra tất cả các thôngbáo lỗi

 Thiết kể đầu vào làm cho bộ đệm đầu vào bị tràn

 Làm lặp lại với các đầu vào như nhau hoặc một dãy các đầu vàonhiều lần

 Làm sao để đầu ra không đúng được sinh ra

 Tính toán kết quả ra rất lớn hoặc rất nhỏ

Để xác nhận hệ thống thực hiện chính xác các yêu cầu, cách tiếp cận tốtnhất vấn đề này là kiểm thử dựa trên kịch bản, bạn đưa ra một số kịch bản vàtạo nên các trường hợp thử nghiệm từ các kịch bản đó Ví dụ, kịch bản dướiđây có thể mô tả cách hệ thống thư viện LIBSYS, đã thảo luận trong chươngtrước, có thể được sử dụng:

Một sinh viên ở Scốt-len nghiên cứu lịch sử nước Mỹ đã được yêu cầuviết một bài luận về “Tâm lý của người miền Tây nước Mỹ từ năm 1840 đếnnăm 1880” Để làm việc đó, cô ấy cần tìm các tài liệu từ nhiều thư viện Cô ấyđăng nhập vào hệ thống LIBSYS và sử dụng chức năng tìm kiếm để tìm xem cô

ấy có được truy cập vào các tài liệu gốc trong khoảng thời gian ấy không Cô ấytìm được các nguồn tài liệu từ rất nhiều thư viện của các trường đại học của Mỹ,

và cô ấy tải một vài bản sao các tài liệu đó Tuy nhiên, với một vài tài liệu, cô ấycần phải có sự xác nhận từ trường đại học của cô ấy rằng cô ấy thật sự là một sinhviên và các tài liệu được sử cho những mục đích phi thương mại Sau đó, sinhviên đó sử dụng các phương tiện của LIBSYS để yêu cầu sự cho phép và đăng kýcác yêu cầu của họ Nếu được xác nhận, các tài liệu đó sẽ được tải xuống từ máychủ của thư viện và sau đó được in Cô ấy nhận được một thông báo từ LIBSYSnói rằng cô ấy sẽ nhận được một e-mail khi các tài liệu đã in có giá trị để tậphợp.

Từ kịch bản trên, chúng ta có thể áp dụng một số thử nghiệm để tìm ramục đích của LIBSYS:

 Kiểm thử cơ chế đăng nhập bằng cách thực hiện các đăng nhập đúng

và đăng nhập sai để kiểm tra người dùng hợp lệ được chấp nhận

và người dùng không hợp lệ không được chấp nhận

 Kiểm thử cơ chế tìm kiếm bằng cách sử dụng các câu hỏi đã biếtcác tài liệu cần tìm để kiểm tra xem cơ chế tìm kiếm có thực sự tìmthấy các tài liệu đó

 Kiểm thử sự trình bày hệ thống để kiểm tra các thông tin về tài liệu

có được hiển thị đúng không

 Kiểm thử cơ chế cho phép yêu cầu tải tài liệu xuống

 Kiểm thử e-mail trả lời cho biết tài liệu đã tải xuống là sẵn sàng sửdụng

Hình 2.6 Biểu đồ dãy tập hợp dữ liệu về thời tiết

Với mỗi thử nghiệm, Người kiểm thử ( Tester ) nên thiết kế một tập các thửnghiệm bao gồm các đầu vào hợp lệ và đầu vào không hợp lệ để sinh ra các đầu

ra hợp lệ và đầu ra không hợp lệ Tester cũng nên tổ chức kiểm thử dựa trênkịch bản, vì thế đầu tiên các kịch bản thích hợp được thử nghiệm, sau đó cáckịch bản khác thường và ngoại lệ được xem xét, vì vậy sự cố gắng của bạn dànhcho các phần mà hệ thống thường được sử dụng

Nếu Tester đã sử dụng trường hợp người dùng để mô tả các yêu cầu của

hệ thống, các trường hợp người dùng đó và biểu đồ liên kết nối tiếp có thể là cơ

sở để kiểm thử hệ thống Để minh họa điều này, em sử dụng một ví dụ từ hệ thốngtrạm dự báo thời tiết

Hình 2.6 chỉ ra các thao tác lần lượt được thực hiện tại trạm dự báo thờitiết khi nó đáp ứng một yêu cầu để tập hợp dữ liệu cho hệ thống bản vẽ Bạn cóthể sử dụ biểu đồ này để nhận biết các thao tác sẽ được thử nghiệm và giúp choviệc thiết kế các trường hợp thử nghiệm để thực hiện các thử nghiệm Vì vậy để

đưa ra một yêu cầu cho một báo cáo sẽ dẫn đến sự thực hiện của một chuỗi cácthao tác sau:

CommsController:request → WheatherStation:report → WeatherData:summarise

Biểu đồ đó có thể được sử dụng để nhận biết đầu vào và đầu ra cần tạo racho các thử nghiệm:

 Một đầu vào của một yêu cầu báo cáo nên có một sự thừa nhận vàcuối cùng báo cáo nên xuẩt phát từ yêu cầu Trong lúc kiểm thử, bạnnên tạo ra dữ liệu tóm tắt, nó có thể được dùng để kiểm tra xem báocáo được tổ chức chính xác

 Một yêu cầu đầu vào cho một báo cáo về kết quả của WeatherStationtrong một báo cáo tóm tắt được sinh ra Tester có thể kiểm thử điềunày một cách cô lập bằng cách tạo ra các dữ liệu thô tương ứngvới bản tóm tắt, bạn đã chuẩn bị để kiểm tra CommosController vàkiểm tra đối tượng WeatherStation đã được đưa ra chính xác trongbản tóm tắt

 Dữ liệu thô trên cũng được sử dụng để kiểm thử đối tượngWeatherData

Tất nhiên, em đã làm đơn giản biểu đồ trong hình 2.6 vì nó không chỉ racác ngoại lệ Một kịch bản kiểm thử hoàn chỉnh cũng phải có trong bản kê khai

và đảm bảo nắm bắt được đúng các ngoại lệ

16.5 Kiểm thử hiệu năng

Ngay khi một hệ thống đã được tích hợp đầy đủ, hệ thống có thể được kiểmtra các thuộc tính nổi bất như hiệu năng và độ tin cậy Kiểm thử hiệu năng phảiđược thiết kế để đảm bảo hệ thống có thể xử lý như mong muốn Nó thường baogồm việc lập một dãy các thử nghiệm, gánh nặng sẽ được tăng cho nên khi hệthống không thể chấp nhận được nữa

Cùng với các loại kiểm thử khác, kiểm thử hiệu năng liên quan đến cảviệc kiểm chứng các yêu cầu của hệ thống và phát hiện các vấn đề và khiếmkhuyết trong hệ thống Để kiểm thử các yêu cầu hiệu năng đạt được, bạn phải xây

dụng mô tả sơ lược thao tác Mô tả sơ lược thao tác là tập các thử nghiệm phảnánh sự hòa trộn các công việc sẽ được thực hiện bởi hệ thống Vì vậy, nếu 90%giao dịch trong hệ thống có kiểu A, 5% kiểu B và phần còn lại có kiểu C, D và E,thì chúng ta phải thiết kế mô tả sơ lược thao tác phần lớn tập trung vào kiểm thửkiểu A Nếu không thì Tester sẽ không có được thử nghiệm chính xác về hiệunăng hoạt động của hệ thống.

Tất nhiên, cách tiếp cận này không nhất thiết là tốt để kiểm thử khiếmkhuyết Như tôi đã thảo luận, theo kinh nghiệm đã chỉ ra cách hiệu quả để pháthiện khiếm khuyết là thiết kế các thử nghiệm xung quanh giới hạn của hệ thống.Trong kiểm thử hiệu năng, điều này có nghĩa là nhấn mạnh hệ thống (vì thế nó

có tên là kiểm thử nhấn mạnh ) bằng cách tạo ra những đòi hỏi bên ngoài giớihạn thiết kế của phần mềm

Ví dụ, một hệ thống xử lý các giao dịch có thể được thiết kế để xử lý đến

300 giao dịch mỗi giây; một hệ thống điều khiển có thể được thiết kế để điềukhiển tới 1000 thiết bị đầu cuối khác nhau Kiểm thử nhấn mạnh tiếp tục các thửnghiệm bên cạnh việc thiết kế lớn nhất được nạp vào hệ thống cho đến khi hệthống gặp lỗi Loại kiểm thử này có 2 chức năng:

 Nó kiểm thử việc thực hiện lỗi của hệ thống Trường hợp này cóthể xuất hiện qua việc phối hợp các sự kiện không mong muốn bằng cáchnạp vượt quá khả năng của hệ thống Trong trường hợp này, sai sót của

hệ thống làm cho dữ liệu bị hư hỏng hoặc không đáp ứng được yêu cầucủa người dùng Kiểm thử nhấn mạnh kiểm tra sự quá tải của hệ thốngdẫn tới ‘thất bại mềm’ hơn là làm sụp đổ dưới lượng tải của nó

 Nó nhấn mạnh hệ thống và có thể gây nên khiếm khuyết trở nên

rõ ràng mà bình thường không phát hiện ra Mặc dù, nó chứng tỏ nhữngkhiếm khuyết không thể dẫn đến sự sai sót của hệ thống trong khi sửdụng bình thường, có thể hiếm gặp trong trường hợp bình thường màkiểm thử gay cấn tái tạo

Kiểm thử gay cấn có liên quan đặc biệt đến việc phân phối hệ thống dựatrên một một mạng lưới máy xử lý Các hệ thống thường đưa ra đòi hỏi cao khichúng phải thực hiện nhiều công việc Mạng trở thành bị làm mất tác dụng với dữ

liệu kết hợp mà các quá trình khác nhau phải trao đổi, vì vậy các quá trình trở nênchậm hơn, như khi nó đợi dữ liệu yêu cầu từ quá trình khác.

Kiểm thử thành phần (thỉnh thoảng được gọi là kiểm thử đơn vị) là quátrình kiểm thử các thành phần riêng biệt của hệ thống Đây là quá trình kiểmthử khiếm khuyết vì vậy mục tiêu của nó là tìm ra lỗi trong các thành phần.Khi thảo luận trong phần giới thiệu, với hầu hết các hệ thống, người pháttriển các thành phần chịu trách nhiệm kiểm thử các thành phần Có nhiềuloại thành phần khác nhau, ta có thể kiểm thử chúng theo các bước sau:

 Các chức năng và cách thức riêng biệt bên trong đối tượng

 Các lớp đối tượng có một vài thuộc tính và phương thức

 Kết hợp các thành phần để tạo nên các đối tượng và chức năng khácnhau Các thành phần hỗn hợp có một giao diện rõ ràng được sử dụng

để truy cập các chức năng của chúng

Các chức năng và phương thức riêng lẻ là loại thành phần đơn giản nhất

và các thử nghiệm của Tester là một tập các lời gọi tới các thủ tục với tham sốđầu vào khác nhau Tester có thể sử dụng cách tiếp cận này để thiết kế trườnghợp kiểm thử (được thảo luận trong phần sau), để thiết kế các thử nghiệm chứcnăng và phương thức

Khi bạn kiểm thử các lớp đối tượng, bạn nên thiết kế các thử nghiệm đểcung cấp tất cả các chức năng của đối tượng Do đó, kiểm thử lớp đối tượng nênbao gồm:

 Kiểm thử tất cả các thao tác cô lập liên kết tạo thành đối tượng

 Bố trí và kiểm tra tất cả các thuộc tính liên kết tạo thành đối tượng

 Kiểm tra tất cả các trạng thái của đối tượng Điều này có nghĩa là tất cảcác sự kiện gây ra các trạng thái khác nhau của đối tượng nên được môphỏng

Ví dụ, trạm dự báo thời tiết có giao diện trình bày trên hình 3.6 Nó chỉ cómột thuộc tính, là định danh của nó Nó có một hằng số là tập thông số khi trạm

dự báo thời tiết được thiết đặt Do đó, bạn chỉ cần một thử nghiệm để kiểm tra nó

đã được thiết đặt hay chưa Bạn cần xác định các trường hợp kiểm thử để kiểmtra reportWeather, calibrate, test, startup và shutdown Trong trường hợp lýtưởng, bạn nên kiểm thử các phương thức riêng biệt, nhưng trong một vàitrường hợp, cần có vài thử nghiệm liên tiếp Ví dụ để kiểm thử phương thứcshutdown bạn cần thực hiện phương thức startup

Sử dụng mô hình này, bạn có thể nhận biết thứ tự của các trạng thái chuyểntiếp phải được kiểm thử và xác định thứ tự chuyển tiếp các sự kiện Trong nguyêntắc này, bạn nên kiểm thử mọi trạng thái chuyển tiếp có thể xảy ra, mặc dù trongthực tế, điều này có thể rất tốn kém.Ví dụ dãy trạng thái nên kiểm thử trong trạm

dự báo thời tiết bao gồm:

Shutdown → Waiting → Shutdown

Waiting → Calibrating → Testing → Transmitting → Waiting

Waiting → Collecting → Waiting → Summarising → Transmitting →

lớp con, tất cả các lớp con nên được kiểm thử tất cả các thao tác kế thừa Lý do

là các thao tác kế thừa có thể đã thay đổi các thao tác và thuộc tính sau khi được

kế thừa Khi một thao tác của lớp cha được định nghĩa lại, thì nó phải được kiểmthử

Khái niệm lớp tương đương, được thảo luận trong phần 23.3.2, có thể cũngđược áp dụng cho các lớp đối tượng Kiểm thử các lớp tương đương giống nhau cóthể sử dụng các thuôc tính của đối tượng Do đó, các lớp tương đương nên đượcnhận biết như sự khởi tạo, truy cập và cập nhật tất cả thuộc tính của lớp đối tượng

16.7 Kiểm thử giao diện

Nhiều thành phần trong một hệ thống là sự kết hợp các thành phần tạo nênbởi sự tương tác của một vài đối tượng Kiểm thử các thành phần hỗn hợp chủyếu liên quan đến kiểm thử hoạt động giao diện của chúng thông qua các đặc tả

Hình 2.8 minh họa quá trình kiểm thử giao diện Giả sử các thành phần

A, B, và C đã được tích hợp để tạo nên một thành phần lớn hoặc một hệ thốngcon Các thử nghiệm không chỉ áp dụng vào các thành phần riêng lẻ mà còn được

áp dụng vào giao diện của các thành phần hỗn hợp được tạo nên bằng cách kết hợpcác thành phần đó

Kiểm thử giao diện đặc biệt quan trọng trong việc phát triển phần mềmhướng đối tượng và các thành phần cơ sở Các đối tượng và các thành phần đượcxác định qua giao diện của chúng và có thể được sử dụng lại khi liên kết với cácthành phần khác trong các hệ thống khác nhau Các lỗi giao diện trong thànhphần hỗn hợp không thể được phát hiện qua việc kiểm thử các đối tượng và cácthành phần riêng lẻ Sự tương tác giữa các thành phần trong thành phần hỗn hợp

có thể phát sinh lỗi

Có nhiều kiểu giao diện giữa các thành phần chương trình, do đó có thểxuất hiện các kiểu lỗi giao diện khác nhau:

 Giao diện tham số: Khi dữ liệu hoặc tham chiếu chức năng được đưa

từ thành phần này tới thành phần khác

 Giao diện chia sẻ bộ nhớ: Khi một khối bộ nhớ được chia sẻ giữacác thành phần Dữ liệu được để trong bộ nhớ bởi một hệ thống con vàđược truy xuất bởi một hệ thống khác

 Giao diện thủ tục: Một thành phần bao gồm một tập các thủ tục cóthể được gọi bởi các thành phần khác Các đối tượng và các thành phầndùng lại có dạng giao diện này

 Giao diện truyền thông điệp: Một thành phần yêu cầu một dịch vụ

từ một thành phần khác bằng cách gởi một thông điệp tới thành phần

đó Thông điệp trả lại bao gồm các kết quả thực hiện dịch vụ Một vài

hệ thống hướng đối tượng có dạng giao diện này như trong hệ thống khách (client-server)

chủ-Các lỗi giao diện là một dạng lỗi thường gặp trong các hệ thống phức tạp(Lutz, 1993) Các lỗi này được chia làm 3 loại:

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

C

Hình 2.8 Kiểm thử giao diện

 Dùng sai giao diện: Một thành phần gọi tới thành phần khác và tạonên một lỗi trong giao diện của chúng Đây là loại lỗi rất thườnggặp trong giao diện tham số: các tham số có thể được truyền sai kiểu,sai thứ tự hoặc sai số lượng tham số.

 Hiểu sai giao diện: Một thành phần gọi tới thành phần khác nhưnghiểu sai các đặc tả giao diện của thành phần được gọi và làm saihành vi của thành phần được gọi Thành phần được gọi không hoạtđộng như mong đợi và làm cho thành phần gọi cũng hoạt độngkhông như mong đợi Ví dụ, một thủ tục tìm kiếm nhị phân có thểđược gọi thực hiện trên một mảng chưa được xếp theo thứ tự, kếtquả tìm kiếm sẽ không đúng

 Các lỗi trong bộ đếm thời gian: Các lỗi này xuất hiện trong các hệthống thời gian thực sử dụng giao diện chia sẻ bộ nhớ hoặc giaodiện truyền thông điệp Dữ liệu của nhà sản xuất và dữ liệu củakhách hàng có thể được điều khiển với các tốc độ khác nhau Nếukhông chú ý đến trong thiết kế giao diện, thì khách hàng có thể truycập thông tin lỗi thời bởi vì thông tin của nhà sản xuất chưa đượccập nhật trong giao diện chia sẻ

Kiểm thử những khiếm khuyết trong giao diện rất khó khăn bởi vì một sốlỗi giao diện chỉ biểu lộ trong những điều kiện đặc biệt Ví dụ, một đối tượng cóchứa một danh sách hàng đợi với cấu trúc dữ liệu có chiều dài cố định Giả sửdanh sách hàng đợi này được thực hiện với một cấu trúc dữ liệu vô hạn vàkhông kiểm tra việc tràn hàng đợi khi một mục được thêm vào Trường hợpnày chỉ có thể phát hiện khi kiểm thử với những thử nghiệm làm cho tràn hàngđợi và làm sai hành vi của đối tượng theo những cách có thể nhận biết được

Những lỗi khác có thể xuất hiện do sự tương tác giữa các lỗi trong cácmôđun và đối tượng khác nhau Những lỗi trong một đối tượng có thể chỉ đượcphát hiện khi một vài đối tượng khác hoạt động không như mong muốn Ví dụ,một đối tượng có thể gọi một đối tượng khác để nhận được một vài dịch vụ vàgiả sử được đáp ứng chính xác Nếu nó đã hiểu sai về giá trị được tính, thì giátrị trả về là hợp lệ nhưng không đúng Điều này chỉ được phát hiện khi các tính