kiểm thử compare function trong dịch vụ đám mây azure cloud backup đồ án ii hệ thống thông tin quản

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (5.18 MB, 60 trang )

Trang 1<div class="page_container" data-page="1">

ĐẠI HỌC BÁCH KHOA HÀ NỘIVIỆN TOÁN ỨNG DỤNG VÀ TIN HỌC

ĐỀ TÀI:

KIỂM THỬ COMPARE FUNCTION TRONG DỊCH VỤ ĐÁMMÂY AZURE CLOUD BACKUP

ĐỒ ÁN II

Chuyên ngành: HỆ THỐNG THƠNG TIN QUẢN LÝ

GVHD: TS. Đồn Duy TrungSVTH: Hồng Thanh BìnhMSSV: 20195950

Lớp:Hệ thống thơng tin quản lý

HÀ NỘI – 2023

</div>Trang 2<div class="page_container" data-page="2">

NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN

1. Mục đích và nội dung của đồ án

2. Kết quả đạt được

3. Ý thức làm việc của sinh viên

Hà Nội, ngày 2 tháng 03 năm 2023

Giảng viên hướng dẫn

TS. Đoàn Duy Trung

</div>Trang 3<div class="page_container" data-page="3">

Lời cảm ơn

Đầu tiên, em xin gửi lời cảm ơn chân thành đến TS. Đồn Duy Trung đã lnhướng dẫn tận tình, chu đáo và tạo điều kiện nghiên cứu giúp em hoàn thành đồán này. Trong thời gian tham gia tìm hiểu, em đã có thêm cho mình nhiều kiếnthức bổ ích, tinh thần học tập hiệu quả, nghiêm túc. Đây chắc chắn sẽ là nhữngkiến thức quý báu, là hành trang để em có thể vững bước sau này. Tuy nhiên,với điều kiện thời gian cũng như kinh nghiệm, kiến thức của bản thân còn hạnchế dẫn đến đồ án này khơng tránh khỏi những thiếu sót. Do đó, em mong sẽnhận được sự đóng góp từ các thầy cơ để đồ án được hoàn thiện hơn.

Em xin chân thành cảm ơn!

Hà Nội, ngày 02 tháng 03 năm 2022

Sinh viên

Hoàng Thanh Bình

</div>Trang 4<div class="page_container" data-page="4">

Mục lục

1.1 Kiểm thử phần mềm và một số khái niệm liên quan . . . 3

1.4.1 Các nguyên tắc cơ bản của kiểm thử . . . 10

1.4.2 Kỹ thuật kiểm thử hộp trắng (White - Box Testing) . . . . 12

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

1.5 Kỹ thuật thiết kế Test case . . . 16

1.5.1 Cấu trúc của test case . . . 16

1.5.2 Phân vùng tương đương . . . 18

1.5.3 Phân tích giá trị biên . . . 20

1.5.4 Đốn lỗi . . . 22

</div>Trang 5<div class="page_container" data-page="5">

1.6 Tạo Bug report . . . 23

1.6.1 Bug và Bug report . . . 24

1.6.2 Cấu trúc một Bug report . . . 24

1.6.3 Severity và Priority . . . 25

Chương 2 Kiểm thử chức năng Compare function trong dịch vụđám mây Azure Cloud Backup272.1 Giới thiệu . . . 27

3.1.1 Thiết kế test case cho giao diện người dùng . . . 39

3.1.2 Thiết kế test case cho chức năng Compare . . . 41

3.1.3 Thiết kế test case cho chức năng Restore . . . 43

</div>Trang 6<div class="page_container" data-page="6">

Danh sách hình vẽ

1.1 Quy trình kiểm thử phần mềm . . . 6

1.2 Luồng thông tin kiểm thử . . . 11

1.3 Minh họa kiểm thử hộp đen . . . 15

1.4 Minh họa một một số test case . . . 18

1.5 Minh họa một form đăng nhập . . . 19

1.6 Minh họa một Bug report . . . 25

2.1 Giao diện Compare job. . . 31

2.2 Giao diện khi thực hiện chức năng Restore . . . 37

3.1 Một số test case viết cho UI . . . 41

3.2 Một số test case viết cho chức năng Restore Users . . . 44

3.3 Một số test case viết cho chức năng Restore Groups . . . 45

3.4 Một Bug report về UI . . . 47

3.5 Một bug report về chức năng Compare . . . 48

</div>Trang 7<div class="page_container" data-page="7">

Lời mở đầu

Lý do chọn đề tài: Với sự phát triển như vũ bão của công nghệ thơng tin

nói chung và cơng nghệ phần mềm nói riêng, việc phát triển phần mềm ngàycàng được hỗ trợ bởi nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềmđỡ mệt nhọc và hiệu quả hơn. Tuy nhiên, vì độ phức tạp của phần mềm và nhữnggiới hạn về thời gian và chi phí, cho dù các hoạt động đảm bảo chất lượng phầnmềm nói chung và kiểm thử nói riêng ngày càng chặt chẽ và khoa học, vẫn khôngđảm bảo được rằng các sản phẩm phần mềm đang được ứng dụng khơng có lỗi.Lỗi vẫn ln tiềm ẩn trong mọi sản phẩm phần mềm và cũng có thể gây nhữngthiệt hại khôn lường. Kiểm thử phần mềm là một quá trình liên tục, xuyên suốtmọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn cácyêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng. Các kỹthuật kiểm thử phần mềm đã và đang được nghiên cứu, và việc kiểm thử phầnmềm đã trở thành quy trình bắt buộc trong các dự án phát triển phần mềmtrên thế giới. Kiểm thử phần mềm là một hoạt động rất tốn kém, mất thời gian,và khó phát hiện được hết lỗi. Vì vậy, việc kiểm thử phần mềm địi hỏi phải cóchiến lược phù hợp, một kế hoạch hợp lý và việc thực hiện được quản lí chặt chẽ.Theo nhiều tính tốn thì cơng việc kiểm thử có vai trị hết sức quan trọng và nóchiếm tới 40% tổng chi phí cho việc xây dựng sản xuất phần mềm. Và đó là lí doem em chọn đề tài này để nghiên cứu, tìm hiểu và tìm ra các giải pháp để cảitiến quy trình kiểm thử như hiện nay sao cho có năng suất cao nhất.

Mục đích của đồ án: Đề tài tìm hiểu cơ sở lý thuyết về kiểm thử nói chung

</div>Trang 8<div class="page_container" data-page="8">

và kiểm thử thủ công trên dịch vụ đám mây Azure Cloud Backup nói riêng. Từđó, cần thiết để đưa ra một chiến lược hiệu quả cho việc kiểm thử mà có thể baoquát được giới hạn tổng thể và rộng lớn những yêu cầu, chức năng qua đó có thểgiúp cho sản phẩm tránh được những rủi ro có thể gặp.

Đối tượng phạm vi nghiên cứu: Đồ án nghiên cứu lý thuyết kiểm thử

phần mềm. Từ đó áp dụng vào kiểm thử Compare function trong dịch vụ saolưu và phục hồi Azure Cloud Backup.

Phương pháp nghiên cứu: Nghiên cứu tổng quan về kiểm thử phần mềm

và áp dụng kĩ thuật kiểm thử hộp đen (Black-box testing) vào một số chức năngcủa Azure Cloud Backup.

Với mục tiêu đặt ra như vậy, những nội dung và kết quả nghiên cứu chínhcủa đồ án được trình bày trong ba chương như sau:

Chương 1: Các kiến thức cơ bản

Chương 2: Kiểm thử chức năng phục hồi dữ liệu của Compare functiontrong dịch vụ đám mây Azure Cloud Backup.

Chương 3: Thực nghiệm và kết quả kiểm thử.

Phần kết luận đưa ra những đánh giá về những kết quả đạt được và nhữngkhó khăn gặp phải trong quá trình nghiên cứu thực hiện đồ án

</div>Trang 9<div class="page_container" data-page="9">

1.1 Kiểm thử phần mềm và một số khái niệm liên quan

1.1.1 Kiểm thử phần mềm

Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp chocác bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểmthử. Nó cung cấp các nguyên lý, phương pháp, kỹ thuật, tiêu chuẩn và các quytrình để kiểm tra và đánh giá tính đúng đắn của phần mềm.

Các nguyên lý của kiểm thử phần mềm bao gồm:

• Kiểm thử phần mềm khơng thể đảm bảo tất cả các lỗi sẽ được phát hiện,mà chỉ có thể cố gắng giảm thiểu số lượng lỗi.

• Kiểm thử phần mềm phải được thực hiện bởi những người khác với nhữngngười phát triển phần mềm để đảm bảo tính khách quan và độc lập.

</div>Trang 10<div class="page_container" data-page="10">

• Kiểm thử phần mềm phải được thực hiện theo các phương pháp, kỹ thuật,tiêu chuẩn và quy trình được định nghĩa trước để đảm bảo tính nhất quánvà tối ưu hiệu quả.

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bấtcứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì các nỗlực kiểm thử được tiến hành sau khi các u cầu được xác định và việc lập trìnhđược hồn tất nhưng trong Agile (là một tập hợp các phương pháp phát triểnphần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểmthử được tiến hành trong suốt quá trình xây dựng phần mềm. Như vậy, mỗi mộtphương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhấtđịnh.

1.1.2 Một số khái niệm liên quan

Software quality (chất lượng phần mềm): là mức độ mà một hệ thống, thành

phần hay quy trình đáp ứng các yêu cầu của đặc tả phần mềm, các nhu cầumong đợi của khách hàng hoặc người sử dụng.

SQA (Software Quality Assurance): bộ phận giám sát, quản lý và đảm bảo

chất lượng phần mềm. Đây là bộ phận có quyền và có trách nhiệm quy định sẽ đặtkhâu kiểm tra chất lượng sản phẩm theo phương pháp nào, tiêu chuẩn nào và dùngphương án gì để kiểm tra sản phẩm đạt chất lượng tốt nhất và đúng theo yêu cầu.

Validation (thẩm định): là xác định xem một hệ thống có phù hợp vowisi yêu

cầy và thực hiện các chức năng mà nó dự định và đáp ứng các mục tiêu của tổchức và người dùng hay không.

Verification (kiểm định): là để chắc chắn rằng sản phẩm được thiết kế để

cung cấp tất cả các chức năng cho khách hàng. Hoạt động này được thực hiệntừ lúc bắt đầu phát triển phần mềm, bao gồm các đánh giá, các cuộc họp, rà

</div>Trang 11<div class="page_container" data-page="11">

Fault (sai): là kết quả của lỗi, hay nói khác đi, lỗi sẽ dẫn đến sai.

Failure (thất bại): xuất hiện khi một lỗi được thực thi.

Incident (sự cố): khi thất bại xuất hiện, nó có thể hiển thị hoặc khơng, tức

là rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử. Sự cốlà triệu chứng liên kết với một thất bại và thể hiện cho người dùng hoặc ngườikiểm thử về sự xuất hiện của thất bại này.

Test case (ca kiểm thử): gồm một tập các dữ liệu đầu vào và một xâu các giá

trị đầu ra mong đợi đối với phần mềm, mục đích là dựa vào đó để kiểm tra xemphần mềm có thỏa các yêu cầu đặt ra hay không.

Test script (Kịch bản kiểm thử): là một nhóm mã lệnh dạng đặc tả kịch bản

dùng để tự động hóa một quy trình hay một ca kiểm tra, giúp cho việc kiểm tranhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khănhoặc khơng khả thi.

1.2 Quy trình kiểm thử

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

</div>Trang 12<div class="page_container" data-page="12">

sản phẩm cơng việc của giai đoạn kiểm thử chính là “báo cáo kiểm thử” mà tàiliệu hóa tất cả các trường hợp kiểm thử đã chạy, dữ liệu đầu vào, đầu ra mongđợi, đầu ra thực tế và mục đích của kiểm thử.

Hình 1.1: Quy trình kiểm thử phần mềm

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

– Mục đích: Quy định về phạm vi, phương pháp, tài nguyên và lịch biểu

của các hoạt động kiểm thử.

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

– Khái quát về kiểm định và thẩm định (V&V): tổ chức, tài nguyên,

trách nhiệm, các công cụ, kỹ thuật và các phương pháp luận.

– Vòng đời của V&V: các nhiệm vụ, các dữ liệu vào và các kết quả trên

một giai đoạn vòng đời.

– Báo cáo V&V phần mềm: mô tả nội dung, định dạng và thời gian cho

tất cả các báo cáo V&V.

– Các thủ tục quản lý V&V bao gồm các chính sách, thủ tục, các chuẩn,

thực nghiệm và các quy ước.

</div>Trang 13<div class="page_container" data-page="13">

• Phân tích và thiết kế: Việc kiểm thử thường phải tiến hành một cách độclập và các nhóm độc lập có trách nhiệm tiến hành các họat động kiểm thử.Thiết kế các trường hợp kiểm thử là các đặc tả đầu vào cho kiểm thử vàđầu ra mong đợi của hệ thống:

– Các kỹ thuật kiểm thử hộp đen để kiểm thử dựa trên chức năng.– Các kỹ thuật kiểm thử hộp trắng để kiểm thử dựa vào cấu trúc bên

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

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

Các mức kiểm thử phần mềm thơng thường:•Unit test: Kiểm thử mức đơn vị.

•Integration test: Kiểm thử tích hợp.

•Acceptance test: Kiểm thử chấp nhận sản phẩm.•Regression test: Kiểm thử hồi quy.

1.3.1 Kiểm thử mức đơn vị

Một đơn vị kiểm thử là một thành phần phần mềm nhỏ nhất mà ta có thểkiểm thử được. Theo định nghĩa này, các hàm (Function), thủ tục (Procedure),lớp (Class), hoặc các phương thức (Method) đều có thể được xem là đơn vị kiểmthử. Vì đơn vị kiểm thử được chọn để kiểm thử thường có kích thước nhỏ vàchức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức,kiểm thử, ghi nhận và phân tích kết quả kiểm thử. Nếu phát hiện lỗi,việc xácđịnh nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùngtrong một đơn vị đang kiểm thử. Một nguyên lý đúc kết từ thực tiễn: thời gian

</div>Trang 14<div class="page_container" data-page="14">

Cũng như các mức kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩnbị trước các ca kiểm thử hoặc kịch bản kiểm thử, trong đó chỉ định rõ dữ liệuvào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các ca kiểm thử và kịchbản này nên được giữ lại để tái sử dụng. Kiểm thử đơn vị thường sử dụng cácUnit Test Framework, đó là các khung chương trình được viết sẵn để hộ trợ choviệc test các mô đun, các đơn vị phần mềm.

1.3.2 Kiểm thử mức tích hợp

Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thửnhư một ứng dụng đã hoàn thành. Trong khi kiểm thử đơn vị kiểm thử các thànhphần và đơn vị phần mềm riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại vớinhau và kiểm thử sự giao tiếp giữa chúng.

Kiểm thử tích hợp có 2 mục tiêu chính:

</div>Trang 15<div class="page_container" data-page="15">

•Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị kiểm thử.

• Tích hợp các đơn vị kiểm thử đơn lẻ thành các hệ thống nhỏ (subsystem)và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểmthử ở mức hệ thống.

1.3.3 Kiểm thử hồi quy

Kiểm thử hồi quy là kiểm thử được thực hiện sau khi thực hiện các thay đổiđối với sản phẩm phần mềm và kiểm tra lại các phần của sản phẩm có thể đã bịảnh hưởng bởi lỗi.

Ví dụ: một ứng dụng phần mềm có thể cho phép giáo viên thêm, lưu, xóa và

làm mới trong một công cụ học tập trực tuyến. Sau đó, các Developer deploy 1version mới với chức năng bổ sung để cập nhật. Chức năng mới được kiểm trađể xác nhận rằng bản cập nhật hoạt động như mong đợi. Trong trường hợp này,kiểm tra hồi quy có thể cải thiện chất lượng tổng thể của sản phẩm.

1.3.4 Kiểm thử chấp nhận sản phẩm

Thông thường, sau giai đoạn kiểm thử hệ thống là kiểm thử chấp nhận, đượckhách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đíchcủa kiểm thử chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu cầu củakhách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).Kiểm thử chấp nhận có ý nghĩa hết sức quan trọng, mặc dù trong hầu hếtmọi trường hợp, các phép kiểm thử của kiểm thử hệ thống và kiểm thử chấpnhận gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

</div>Trang 16<div class="page_container" data-page="16">

•Kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống.• Kiểm thử tích hợp chú trọng sự giao tiếp giữa các đơn vị hoặc đối tượng

khi chúng làm việc cùng nhau.

Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để bảođảm mọi đơn vị phần mềm và sự tương tác giữa chúng hoạt độngchính xác trướckhi thực hiện kiểm thử hệ thống. Kiểm thử hệ thống kiểm tra cả các hành vichức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiệnlợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp choviệc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạncác lỗi “bế tắc” (deadlock) hoặc chiếm dụng bộ nhớ.

1.4 Các kĩ thuật kiểm thử

Có thể chia các kỹ thuật kiểm thử phần mềm thành hai loại: các kỹ thuậtkiểm thử hộp đen (black-box testing) và kỹ thuật kiểm thử hộp trắng (white-box testing). Các kiểm thử hộp đen tìm các lỗi như thiếu các chức năng, khảnăng sử dụng và các yêu cầu phi chức năng. Trong khi các kỹ thuật kiểm thửhộp trắng yêu cầu hiểu biết về cấu trúc chương trình bên trong và các kiểm thửnhận được từ đặc tả thiết kế bên trong hoặc từ mã.

1.4.1 Các nguyên tắc cơ bản của kiểm thử

Kiểm thử là một bước trong quy trình phần mềm mà có thể được xem xétbởi đội ngũ phát triển bằng cách phá vỡ thay vì xây dựng. Các kỹ sư phần mềmchính là những người xây dựng và kiểm thử yêu cầu họ vượt qua các khái niệmcho trước về độ chính xác và giải quyết mâu thuẫn khi các lỗi được xác định.

•Mục tiêu kiểm thử

Các nguyên tắc được xem như mục tiêu kiểm thử là:

– Kiểm thử là một quá trình thực thi chương trình với mục đích tìm lỗi.

</div>Trang 17<div class="page_container" data-page="17">

– Một trường hợp kiểm thử tốt là trường hợp kiểm thử mà có khả năng

cao việc tìm thấy các lỗi chưa từng được phát hiện.

– Một kiểm thử thành công là kiểm thử mà phát hiện lỗi chưa từng được

phát hiện.

•Luồng thơng tin kiểm thử

Luồng thơng tin cho kiểm thử được biểu diễn bởi mơ hình trong hình dướiđây. Hai kiểu của đầu vào được truyền cho quá trình kiểm thử:

– Cấu hình phần mềm: gồm các đặc tả yêu cầu, đặc tả thiết kế, và mã

– Cấu hình kiểm thử: gồm có kế hoạch kiểm thử, các thủ tục, trường

hợp kiểm thử, và các công cụ kiểm thử.

Hình 1.2: Luồng thơng tin kiểm thử

•Thiết kế trường hợp kiểm thử

– Thiết kế kiểm thử phần mềm có thể là một q trình thu thập, phân

tích và thực hiện yêu cầu. Mục tiêu của kiểm thử là phải thiết kế cáctrường hợp kiểm thử có khả năng cao nhất trong việc phát hiện nhiềulỗi nhất với thời gian và công sức tối thiểu. Như vậy, vấn đề quantrọng nhất trong kiểm thử phần mềm là thiết kế và tạo ra các trườnghợp kiểm thử có hiệu quả. Lý do về tầm quan trọng của việc thiết kế

</div>Trang 18<div class="page_container" data-page="18">

các trường hợp kiểm thử xuất phát từ thực tế: Kiểm thử “vét cạn” làđiều không thể, và như vậy, kiểm thử một chương trình phải ln xácđịnh là không thể vét cạn. Vấn đề quan trọng là cố gắng làm giảm sự“khơng thể vét cạn” nhiều nhất có thể.

– Kiểm thử phần mềm cịn có các ràng buộc về thời gian, chi phí, v.v.– Bất kỳ sản phẩm cơng nghệ nào có thể được kiểm thử trong hai cách:

∗Biết về các chức năng cụ thể mà sản phẩm đã được thiết kế đểthực hiện.

∗Biết cách hoạt động bên trong của sản phẩm, kiểm thử có thể đượcthực hiện để đảm bảo rằng “tất cả các thành phần ăn khớp nhau”.Cách tiếp cận kiểm thử đầu tiên được gọi là kiểm thử hộp đen và cáchthứ hai là kiểm thử hộp trắng.

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

Kiểm thử hộp trắng: Là kỹ thuật kiểm thử dựa trên đặc tả bên trong củachương trình, dựa vào mã nguồn, cấu trúc chương trình. Kiểm thử hộp trắngthường phát hiện các lỗi lập trình. Loại kiểm thử này khá khó thực hiện và chiphí cao. Với các module quan trọng, thực thi việc tính tốn chính của hệ thống,phương pháp này là cần thiết. Có 2 kỹ thuật kiểm thử hộp trắng phổ biến:

•Kiểm thử luồng dữ liệu

Phương pháp kiểm thử luồng dữ liệu lựa chọn các đường dẫn kiểm thửcủa chương trình dựa vào vị trí khai báo và sử dụng các biến trong chươngtrình. Với kiểm thử luồng dữ liệu mỗi câu lệnh trong chương trình đượcgán số hiệu lệnh duy nhất và mỗi hàm khơng thay đổi tham số của nó vàbiến tồn cục. Cho một lệnh với là số hiệu câu lệnh. Ta định nghĩa,S

DEF (S) =là tập các biến được khai báo trong S.U SE(S) =là tập các biến được sử dụng trong S.

</div>Trang 19<div class="page_container" data-page="19">

Một chiến lược kiểm thử luồng dữ liệu cơ bản là chiến lược mà mỗi chuỗiDU được phủ ít nhất một lần. Chiến lược này được gọi là chiến lược kiểmthử DU. Kiểm thử DU không đảm bảo phủ hết tất cả các nhánh của mộtchương trình. Tuy nhiên, một nhánh khơng đảm bảo được phủ bởi kiểmthử DU chỉ trong rất ít tình huống như cấu trúc if-then-else mà trong đóphần then khơng có một khai báo biến nào và có dạng khuyết (khơng tồntại phần else). Trong tình huống đó, nhánh else của lệnh if là không cầnthiết phải phủ bằng kiểm thử DU.

Chiến lược kiểm thử luồng dữ liệu là rất hữu ích cho việc lựa chọn cácđường dẫn kiểm thử của chương trình có chứa các lệnh if hoặc vịng lặplồng nhau.

•Kiểm thử luồng điều khiển

Đường thi hành (Execution path): là 1 kịch bản thi hành đơn vị phần mềmtương ứng: danh sách có thứ tự các lệnh được thi hành ứng với một lầnchạy cụ thể của đơn vị phần mềm, bắt đầu từ điểm nhập của đơn vị phầnmềm đến điểm kết thúc của đơn vị phần mềm.

Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọiđường thi hành của đơn vị phần mềm cần kiểm thử đều chạy đúng. Rấttiếc trong thực tế, công sức và thời gian để đạt mục tiêu trên đây là rấtlớn, ngay cả trên những đơn vị phần mềm nhỏ. Mà cho dù có kiểm thử hếtđược tồn bộ các đường thi hành thì vẫn khơng thể phát hiện những đườngthi hành cần có nhưng khơng (chưa) được hiện thực. Do đó, ta nên kiểmthử số ca kiểm thử tối thiểu mà kết quả độ tin cậy tối đa.

Phủ kiểm thử (Test Coverage): là một kỹ thuật xác định xem các trườnghợp thử nghiệm có thực sự bao trùm mã ứng dụng hay không và bao nhiêu

</div>Trang 20<div class="page_container" data-page="20">

mã được thực hiện khi chạy các trường hợp thử nghiệm đó. Nếu có 10 yêucầu và 100 thử nghiệm được tạo và nếu 90 thử nghiệm được thực hiện thìphạm vi thử nghiệm là 90%. Bây giờ, dựa trên số liệu này, người kiểm tracó thể tạo các trường hợp kiểm tra bổ sung cho các kiểm tra còn lại.Dưới đây là một số lợi thế của test coverage.

– Có thể xác định các lỗ hổng trong yêu cầu, trường hợp kiểm tra và lỗi

ở cấp độ sớm và cấp mã.

– Có thể ngăn ngừa rị rỉ lỗi khơng mong muốn bằng cách sử dụng phân

tích test coverage.

– Test coverage cũng giúp kiểm tra hồi quy, ưu tiên trường hợp kiểm

thử, tăng cường bộ kiểm thử và tối thiểu hóa bộ kiểm thử.•Ưu điểm:

– Kiểm tra được tồn bộ chương trình nguồn.– Phát hiện lỗi tại chỗ.

– Tự động hóa kiểm thử.

•Nhược điểm:

– u cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình.

Do đó đòi hỏi tài nguyên nhân lực và máy tốn kém.

– Có khả năng tồn tại có tổ hợp lệnh khác nhau gây lỗi.– Khơng kiểm thử hết đường đi, vịng lặp lớn, phức tạp.– Khó thực hiện và chi phí thực hiện cao.

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

Kiểm thử hộp đen: là một phương pháp kiểm thử phần mềm được thực hiệnmà không biết được cấu tạo bên trong của phần mềm, là cách mà các testerkiểm tra xem hệ thống như một chiếc hộp đen, khơng có cách nào nhìn thấy bên

</div>Trang 21<div class="page_container" data-page="21">

15trong của cái hộp.

Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm,trong con mắt của các tester, giống như một hộp đen; bên trong mà người takhơng thể nhìn thấy. Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:

•Chức năng khơng chính xác hoặc thiếu.•Lỗi giao diện.

•Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngồi.•Hành vi hoặc hiệu suất lỗi.

•Khởi tạo và chấm dứt các lỗi.

Hình 1.3: Minh họa kiểm thử hộp đen

•Ưu điểm:

– Kỹ sư kiểm thử có thể khơng phải IT chuyên nghiệp.

– Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác.– Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức

năng được xác định.

</div>Trang 22<div class="page_container" data-page="22">

16•Nhược điểm:

– Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn.– Khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào,

và thiếu cả thời gian cho việc tập hợp này.

– Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao.

Mọi kỹ thuật nào cũng có ưu điểm và nhược điểm của nó. Các hệ thống thườngphải được sử dụng nhiều phương pháp kiểm thử khác nhau để đảm bảo đượcchất lượng của hệ thống khi đến tay người dùng.

1.5 Kỹ thuật thiết kế Test case

Q trình phát triển test case (ca kiểm thử) có thể giúp tìm ra lỗi trong cácyêu cầu hoặc thiết kế của ứng dụng, vì nó địi hỏi phải tư duy hồn tồn thơngqua các hoạt động của ứng dụng. Vì lý do này, việc chuẩn bị test case sớm nhấtcó thể trong quy trình phát triển phần mềm là rất hữu ích.

Các trường hợp kiểm thử phải bao phủ được tồn bộ luồng xử lý chức năngmơ tả trong tài liệu phân tích và thiết kế; các yêu cầu về bảo mật an tồn thơngtin, u cầu hiệu năng của hệ thống.

1.5.1 Cấu trúc của test case

Dưới đây là cấu trúc của test case:

– Case ID: giá trị cần để xác định số lượng trường hợp cần để kiểm thử.– Suite: Tên một chức năng, đối tượng hoặc tập hợp các trường hợp

kiểm thử có liên quan tới nhau.

– Subsuite: tương tự như Suite, nhưng được chia nhỏ hơn.

– Title: tiêu đề, tên của case, đảm bảo rõ ràng và mô tả đầy đủ nội

dung của case.

</div>Trang 23<div class="page_container" data-page="23">

– Summary: mơ tả sơ lược về mục đích của case đó.

– Priority: mức độ ưu tiên của case, gồm có 3 mức độ là High, Normal,

và Low

– Step: mơ tả các bước để thực hiện case đó.

– Expected results: kết quả mong đợi từ các bước thực hiện trên.– Results: kết quả thực tế khi chạy chương trình.

– Note: cột này dùng để ghi chú những thông tin liên quan khi thực

hiện test case.

Các bước xác định test case:

– Bước 1: Xác định mục đích kiểm thử, cần hiểu rõ đặc tả yêu cầu của

khách hàng.

– Bước 2: Xác định chức năng cần kiểm tra: cần phải biết làm thế nào

phần mềm được sử dụng bao gồm các hoạt động, tổ chức chức năngkhác nhau.

Các bước thực hiện chỉ mơ tả các bước thực hiện đứng từ phía ngườidùng cuối bao gồm nhập dữ liệu, nhấn button, v.v.

– Bước 3: Xác định các yêu cầu phi chức năng, yêu cầu phần cứng, hệ

điều hành, các khía cạnh an ninh.

– Bước 4: Xác định biểu mẫu cho test case: bao gồm giao diện UI, chức

năng, khả năng tương thích và hiệu suất.

– Bước 5: Xác định tính ảnh hưởng giữa các nguyên tắc module, mỗi

một ca kiểm thử nên được thiết kế để có thể che phủ được sự ảnhhưởng của các module với nhau ở mức độ cao nhất.

Ta sẽ minh họa một vài ca kiểm thử:

</div>Trang 24<div class="page_container" data-page="24">

Hình 1.4: Minh họa một một số test case

1.5.2 Phân vùng tương đương

Phân vùng tương đương là phương pháp chia các điều kiện đầu vào thànhnhững vùng tương đương nhau. Tất cả các giá trị trong một vùng tương đươngsẽ cho một kết quả đầu ra giống nhau. Vì vậy chúng ta có thể test một giá trịđại diện trong vùng tương đương.

Mục đích: Giảm đáng kể số lượng ca kiểm thử cần phải thiết kế vì với mỗi lớp

tương đương ta chỉ cần test trên các phần tử đại diện. Thiết kế ca kiểm thử bằngkỹ thuật phân vùng tương đương tiến hành theo 2 bước:

Bước 1: Xác định các lớp tương đương.

Ta chia miền dữ liệu kiểm thử thành các miền con sao cho dữ liệu trongmỗi miền con có cùng tính chất đối với chương trình. Sau khi chia miềndữ liệu của chương trình thành các miền con tương đương, ta chỉ cần chọnmột phần tử đại diện của mỗi miền con này làm bộ dữ liệu kiểm thử. Cácmiền con này chính là các lớp tương đương.

Bước 2: Xây dựng test case tương ứng với mỗi lớp tương đương.

Ví dụ về một Form đăng nhập:

•User name: text-box

</div>Trang 25<div class="page_container" data-page="25">

19•Password: text-box

Hình 1.5: Minh họa một form đăng nhập

•Yêu cầu:

– Thiết kế ca kiểm thử sao cho người dùng nhập vào ô text-box username

chỉ cho nhập ký tự chữ với độ dài trong khoảng 6-20.

– Nếu nhập giá trị với số ký tự không nằm trong khoảng 6-20.

⇒Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.

– Nếu để trống ô hoặc nhập ký tự khác ký tự chữ.

⇒ Hiển thị lỗi “Tên người dùng chưa hợp lệ! Vui lòng nhập ký tự chữ”.

Dựa vào u cầu bài tốn ta có thể có các lớp tương đương (phân vùng)sau:

– Phân vùng 1: Nhập giá trị hợp lệ từ 6-20.– Phân vùng 2: Nhập giá trị không hợp lệ < 6 ký tự.– Phân vùng 3: Nhập giá trị không hợp lệ > 20 ký tự.

</div>Trang 26<div class="page_container" data-page="26">

– Phân vùng 4: Trường hợp để trống khơng nhập gì hay nhập ký tự

không phải dạng chữ.

Sau khi áp dụng phân vùng tương đương có thể chọn được các case sau:

– Case 1: Nhập giá trị từ 6–20 ⇒ Pass.

– Case 2: Nhập giá trị < 6 ký tự (có thể chọn nhập 1, 2, 3, 4 hoặc 5 ký

tự) ⇒ Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.

– Case 3: Nhập giá trị > 20 ký tự (có thể chọn nhập 21, 22, 23,. . . ký

tự) ⇒ Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.

– Case 4: Để trống không nhập gì hay nhập ký tự khơng phải dạng chữ.

⇒ Hiển thị lỗi “Tên người dùng chưa hợp lệ! Vui lịng nhập ký tự chữ”.•Ưu điểm:

Vì mỗi vùng tương đương ta chỉ cần kiểm tra trên các phần tử đại diện nênsố lượng test case được giảm đi khá nhiều nhờ đó mà thời gian thực hiệnkiểm thử cũng giảm đáng kể.

•Nhược điểm:

Khơng phải với bất kỳ bài tốn nào đều có thể áp dụng kỹ thuật này. Cóthể bị thiếu sót lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tươngđương.

1.5.3 Phân tích giá trị biên

•Phương pháp:

Hầu hết các lỗi được tìm thấy khi kiểm tra ở các giá trị biên. Vì vậy phươngpháp này tập trung vào việc kiểm thử các giá trị biên này. Đây là phươngpháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vàovà dữ liệu ra.

Chúng ta sẽ tập trung vào các giá trị biên chứ khơng test tồn bộ dữ liệu.Thay vì chọn nhiều giá trị trong lớp đương tương để làm đại diện, phân

</div>Trang 27<div class="page_container" data-page="27">

∗Giá trị biên nhỏ nhất – 1∗Giá trị biên nhỏ nhất∗Giá trị biên lớn nhất∗Giá trị biên lớn nhất + 1

Nhưng nếu bạn muốn kiểm tra sâu hơn thì bạn cũng có thể lựa chọn theoquy tắc:

∗Giá trị biên nhỏ nhất - 1∗Giá trị biên nhỏ nhất∗Giá trị biên nhỏ nhất + 1∗Giá trị biên lớn nhất - 1∗Giá trị biên lớn nhất∗Giá trị biên lớn nhất + 1•Ví dụ: Vẫn lấy form đăng nhập hình 1-5.

Theo phương pháp phân vùng tương đương ở trên ta xây dựng được cácmiền tương đương:

– Phân vùng 4: Trường hợp để trống khơng nhập gì hay nhập ký tự

khơng phải dạng chữ.

Áp dụng kỹ thuật phân tích giá trị biên ta chọn được các case sau:

</div>Trang 28<div class="page_container" data-page="28">

22∗Case 1: Nhập giá trị với 5 ký tự.

⇒Hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự”.∗Case 2: Nhập giá trị với 6 ký tự⇒pass.

∗Case 3: Nhập giá trị với 20 ký tự⇒pass.∗Case 4: Nhập giá trị với 21 ký tự.

⇒Hiển thị lỗi "Bạn chỉ được phép nhập chuỗi từ 6-20 ký tự".∗Case 5: Để trống khơng nhập gì hay nhập ký tự khơng phải dạng

</div>Trang 29<div class="page_container" data-page="29">

Sử dụng phương pháp đốn lỗi có thể giúp kiểm thử viên tìm ra những lỗiđiển hình thường xảy ra trong phần mềm hoặc những lỗi không thể tìmthấy khi thiết kế ca kiểm thử theo hình thức thơng thường.

•Nhược điểm:

Phương pháp đốn lỗi thường được thực hiện bởi các kiểm thử viên có kinhnghiệm và khơng theo một quy tắc nhất định, thiết kế ca kiểm thử dựanhiều vào cảm tính.

1.6 Tạo Bug report

Bug report là một phần rất quan trọng và không thể thiếu trong quy trìnhthực hiện kiểm thử. Khi phần mềm xảy ra lỗi, kiểm thử viên phải tạo được racác Bug report và gửi cho nhà phát triển phần mềm đó. Một Bug report đượcviết rõ ràng và rành mạch, sẽ luôn gây ấn tượng và hiệu ứng tốt hơn đối với mộtBug report sơ xài và cẩu thả. Làm cho người sửa bug đó và cả người xác nhậnlại bug đó khơng có cảm giác khó chịu khi phải đọc một Bug report sơ xài.

</div>Trang 30<div class="page_container" data-page="30">

1.6.1 Bug và Bug report

• Bug: lỗi lập trình làm cho một chương trình hoặc một hệ máy tính chạy bị

lỗi, cho kết quả sai, hoặc đổ vỡ.

• Bug report: được hiểu là những mô tả lỗi phần mềm thực thi test phần

mềm đó. Các phần mềm quản lý task như Redmine, Jira,. . . Thông thườngdân IT hay gọi bug report dưới cái tên vui tai là log Bug.

1.6.2 Cấu trúc một Bug report

Một Bug report sẽ bao gồm những thông tin cơ bản sau:

– Project: tên của dự án phần mềm.

– Reported by: kiểm thử viên tạo Bug report.

– Bug name, Bug ID và Date: tên của bug, ID, và thời gian tạo

– Assigned to: cá nhân hoặc tổ chức chịu trách nhiệm phần đó.– Status: trạng thái thực hiện của report.