(123doc) Nghien Cuu Va Ung Dung Ky Thuat Kiem Thu Hop Den Trong Kiem Thu Website Thi Dua Khen TH Ong [PDF]

Zitiervorschau

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƢỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT HÀ NỘI

NGUYỄN THỊ VÂN 1221050117

ĐỒ ÁN TỐT NGHIỆP NGÀNH CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI

NGHIÊN CỨU VÀ ỨNG DỤNG KỸ THUẬT KIỂM THỬ HỘP ĐEN TRONG KIỂM THỬ WEBSITE THI ĐUA KHEN THƢỞNG

Hà Nội, 2017

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƢỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT

ĐỒ ÁN TỐT NGHIỆP CHUYÊN NGÀNH TIN HỌC TRẮC ĐỊA

ĐỀ TÀI

NGHIÊN CỨU VÀ ỨNG DỤNG KỸ THUẬT KIỂM THỬ HỘP ĐEN TRONG KIỂM THỬ WEBSITE PHẦN MỀM THI ĐUA KHEN THƢỞNG

SINH VIÊN THỰC HIỆN

GIÁO VIÊN HƢỚNG DẪN

NGUYỄN THỊ VÂN

ThS. NGUYỄN TUẤN ANH Bộ môn Tin học trắc địa

Lớp Tin học trắc địa K57

Hà Nội, 2017

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

MỤC LỤC DANH MỤC CÁ C HÌ NH VẼ .................................................................................. 6 DANH MỤC CÁ C BẢNG BIỂU ............................................................................ 7 KÝ HIỆU THUẬT NGỮ ......................................................................................... 8 LỜI CẢM ƠN......................................................................................................... 10 THÔNG TIN NGHIÊN CỨU ................................................................................ 11 1. Thông tin chung .............................................................................................. 11 2. Mục tiêu .......................................................................................................... 11 3. Nội dung chính................................................................................................ 11 MỞ ĐẦU ................................................................................................................ 12 1. Giới thiệu tổng quan ...................................................................................... 12 2. Tính cấp thiết, ý nghĩa khoa học và thực tiễn của đề tài ............................... 13 CHƢƠNG 1: TỔNG QUAN VỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM ........................................................................................................... 15 1.1. Định nghĩa chất lƣợng phần mềm ............................................................... 15 1.2. Định nghĩa đảm bảo chất lƣợng phần mềm ................................................ 15 1.3. Lỗi phần mềm .............................................................................................. 15 1.3.1. Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm ......................... 15 1.3.2. Các nguyên nhân gây lỗi phần mềm .................................................... 15 1.3.3. Chi phí cho việc sửa lỗi phần mềm ...................................................... 17 1.3.4. Quy trình xử lý lỗi phần mềm .............................................................. 17 1.4. Kiểm thử phần mềm .................................................................................... 17 1.4.1. Khái niệm kiểm thử phần mềm ............................................................ 17 1.4.2. Lý do cần kiểm thử phần mềm ............................................................. 18 1.4.3. Mục tiêu của kiểm thử phần mềm ........................................................ 18 1.4.4. Các nguyên tắc cơ bản của kiểm thử phần mềm .................................. 18 1.4.5. Các phƣơng pháp kiểm thử .................................................................. 19 1.4.5.1. Kiểm thử tĩnh – Static testing ............................................................ 19 1.4.5.3. Kiểm thử hộp đen - Black box testing .............................................. 20 1.5. Quy trình kiểm thử phần mềm .................................................................... 21

Nguyễn Thị Vân

3

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

1.5.1. Các bƣớc trong một quy trình kiểm thử phần mềm ............................. 21 1.5.2. Mô hình phát triển và kiểm thử phần mềm hình chữ V ........................ 22 1.5.3. Nhân lực kiểm thử phần mềm .............................................................. 25 1.5.4. Quy trình xây dựng kế hoạch kiểm thử ................................................ 25 1.6. Các cấp độ kiểm thử phần mềm. ................................................................. 28 1 .6.1. Kiểm thử đơn vị – Unit test ................................................................. 29 1.6.2. Kiểm thử tích hợp – Intergration Test .................................................. 30 1.6.3. Kiểm thử hệ thống – System Test ........................................................ 31 1.6.4. Kiểm thử chấp nhận sản phẩm – Acceptance Test............................... 34 1.6.5. Một số cấp độ kiểm thử khác ............................................................... 34 1.7. Nguyên tắc kiểm thử phần mềm.................................................................. 35 CHƢƠNG 2: CÁC KỸ THUẬT KIỂM THỬ HỘP ĐEN ..................................... 36 2.1. Giới thiệu ..................................................................................................... 36 2.2 Quy trình kiểm thử hộp đen tổng quát ......................................................... 36 2.3. Equivalence Partitioning – Kỹ thuật phân lớp tƣơng đƣơng ...................... 37 2. 4 Boundary Value Analysis – Kỹ thuật phân tích giá trị biên ....................... 39 2.5. Decision Tables – Kỹ thuật sử dụng bảng quyết định................................. 39 2.6 Pairwise Testing – Kỹ thuật kiểm thử các bộ n thần kỳ............................... 42 2.7. State Transition/Diagram Testing - Kỹ thuật biểu đồ chuyển trạng thái .... 47 2.8. Use case Testing – Kỹ thuật sử dụng use case ............................................ 47 2.9. Cause-Effect Diagram – Kỹ thuật dùng đồ thị nhân quả ............................ 48 2.10. Kỹ thuật đoán lỗi ....................................................................................... 52 2.11. Kết luận ..................................................................................................... 53 CHƢƠNG 3: TRIỂN KHAI KIỂM THỬ WEBSITE THI ĐUA KHEN THƢỞNG54 3.1. Kiểm thử ứng dụng Website........................................................................ 54 3.2. Kiểm thử website thi đua khen thƣởng tỉnh thanh hóa ............................... 55 3.2.1 Giới thiệu bài toán ................................................................................. 55 3.2.2. Biểu đồ mô tả các chức năng sẽ đƣợc thực hiện kiểm thử hộp đen ..... 56 3.2.3. Thiết kế định hƣớng trƣờng hơp kiểm thử ........................................... 57 3.3 Thiết kế bộ các test case ............................................................................... 61

Nguyễn Thị Vân

4

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

3.3.1. Test case kiểm thử chức năng đăng nhập, thay đổi mật khẩu, đăng xuất. ................................................................................................................ 61 3.3.2. Test case kiểm thử chức năng đăng kí ................................................. 67 3.3.3. Testcase kiểm thử chức năng Quản lý đợt thi đua ............................... 69 3.3.4. Test case kiểm thử chức năng Hồ sơ lƣu ............................................. 79 3.3.5. Test case sử dụng kỹ thuật use case ..................................................... 84 3.3.6. Testcase kiểm thử Giao diện ................................................................ 88 3.4 Thực thi test và báo cáo kết quả . ................................................................. 89 TÀI LIỆU THAM KHẢO ...................................................................................... 92

Nguyễn Thị Vân

5

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

DANH MỤC CÁC HÌ NH VẼ Hình 1-1. Mô hình phát triển và kiểm thử phần mềm hình chữ V ..................................21 Hình 1-2. Sơ đồ nhân lực kiểm thử phần mềm............................................................... 22 Hình 1- 3. Xây dựng kế hoạch kiểm thử ....................................................................... 23 Hình1- 4. Sơ đồ các cấp độ kiểm thử .............................................................................26 Hình 2-1. Quy trình kiểm thử hộp đen tổng quát ............................................................34 Hình 2-2. Giao diện đăng nhập hệ thống. ...................................................................... 36 Hình 2-3. Cấu trúc bảng quyết định .............................................................................. 38 Hình 2-4. Giao diện PictMaster Tool............................................................................. 44 Hình 2-5. Đồ thị nhân – quả cho bài toán tính thuế thu nhập ...................................... 48 Hình 3-1. Giao diện phần mềm thi đua khen thƣởng .....................................................53 Hình 3-2. Biểu đồ quản lý testcase ...............................................................................54 Hình 3-3. Màn hình đăng nhập thi đua khen thƣởng...................................................... 58 Hình 3-4. Màn hình chức năng đăng kí ......................................... .............................. 64 Hình 3-5. Màn hình quản lý đợt thi đua ........................................................................ 66 Hình 3-6. Màn hình quản lý hồ sơ ................................................................................. 75 Hình 3-7. Biểu đồ use case thi đua khen thƣởng ........................................... .......... 80

Nguyễn Thị Vân

6

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

DANH MỤC CÁC BẢNG BIỂU Bảng 1-1. Kiểm thử giao diện ngƣời sử dụng ................................................................30 Bảng 2-1. Bảng quyết định bài toán kiểm tra thẻ đƣờng sắt ...........................................39 Bảng 2-2. Bảng các trƣờng hợp kiểm thử sử dụng kỹ thuật pairwise testing ................ 43 Bảng 2-3. Khuôn mẫu đặc tả use case theo Alistair Cockburn .................................... 46 Bảng 2-4. Bảng các ký hiệu sử dụng trong đồ thị nguyên nhân – hệ quả ..................... 46 Bảng 2-5. Bảng quyết định cho đồ thị nhân – quả bài toán tính thuế thu nhập............ 49 Bảng 2-6. Bảng testcase sử dụng kỹ thuật dùng đồ thị nhân – quả.............................. 50 Bảng 3-1. Bảng thiết kế quy trình kiểm thử.................................................................. 58 Bảng 3-2. Test case đăng nhập – đăng xuất – thay đổi mật khẩu phần mềm thi đua khen thƣởng ............................................................................................................................ 59 Bảng 3-3. Bảng dùng kỹ thuật quyết định chức năng đăng kí ....................................... 64 Bảng 3-4. Testcase đăng kí thi đua .............................................................................. 66 Bảng 3-5. Testcase đợt thi đua .......................................................................................68 Bảng 3-6. Testcase quản lý hồ sơ ................................................................................. 76 Bảng 3-7. Testcase giao diện ....................................................................................... 78 Bảng 3-8. Mô tả use case ...............................................................................................82 Bảng 3-9. Testcase sử dụng kỹ thuật use case .................................................. .......... 82 Bảng 3-10. Bảng báo cáo .............................................................................................. 85

Nguyễn Thị Vân

7

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

KÝ HIỆU THUẬT NGỮ

Ký hiệu/ Thuật ngữ

Ý nghĩa

Static testing

Kiểm thử tĩnh

Dynamic testing

Kiểm thử động

Blackbox Testting

Kiểm thử hộp đen

White box testing

Kiểm thử hộp trắng

Unit Tests

Kiểm thử đơn vị

Intergration Tests

Câu hỏi và trả lời

System Tests

Kiểm thử hệ thống

Acceptance Tests

Kiểm thử chấp nhận

Test case

Trƣờng hợp kiểm thử

Test suite

Tập hợp các trƣờng hợp kiểm thử trong Selenium

Test script

Tập hợp các trƣờng hợp kiểm thử

Selenium RC

Selenium Remote Control

Test Manager

Ngƣời quản lí kiểm thử

Test Leader

Quản lí nhóm kiểm thử

Test Analyst

Phân tích kiểm thử

Test Designer

Thiết kế kiểm thử

Test Executing

Thi hành kiểm thử

Nguyễn Thị Vân

8

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Test Report

Báo cáo kiểm thử

QC team

Đội kiểm tra chất lƣợng

Developers

Lập trình viên

PM

Quản lídự án

Customer

Khách hàng

Test Analyst

Phân tích kiểm thử

Test Designer

Thiết kế kiểm thử

Project Leader

Quản lí dự án

API

Application Programming Interface

Nguyễn Thị Vân

9

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

LỜI CẢM ƠN Đồ án tốt nghiệp này đƣợc thực hiện tại Trƣờng đại học Mỏ - Địa chất. Em xin cảm ơn các thầy cô giáo Bộ môn Tin học trắc địa và khoa Công nghệ thông tin Trƣờng đại học Mỏ - Địa chất đã tạo mọi điều kiện thuận lợi về mặt thủ tục trong quá trình em làm đồ án. Em xin chân thành cảm ơn thầy giáo Ths. Nguyễn Tuấn Anh đã trực tiếp tận tình hƣớng dẫn, giúp đỡ, tạo mọi điều kiện thuận lợi trong suốt quá trình em làm đồ án, luôn theo sát và đƣa ra những lời khuyên, động viên kịp thời giúp em hoàn thành đồ án một cách suất sắc nhất; cảm ơn các thầy cô giáo đã trực tiếp giảng dạy trong suốt thời gian học tập tại trƣờng. Để thực hiện đƣợc các thử nghiệm trong nghiên cứu này, em xin chân thành cảm ơn Công ty cổ phẩn đầu tƣ và phát triển Tâm Việt đã tạo điều kiện thuận lợi cho em đƣợc thực tập tốt nghiệp tại công ty. Đặc biệt em xin gửi lời cảm ơn tới Giám Đốc Lƣơng Thanh Bình – đảm bảo chất lƣợng phần mềm đã trực tiếp hƣớng dẫn, giúp đỡ tận tình để em có thể nắm bắt công việc, nghiên cứu kiến thức về kiểm thử phần mềm và vận dụng những kiến thức đƣợc học vào thực hành dự án. Bên cạnh đó, con xin gửi lời cảm ơn tới bố mẹ chị gái và em trai đã giúp đỡ, sát cánh bên con trong những hoàn cảnh khó khăn nhất. Và con cũng xin gửi lời cảm ơn tới các bác, các anh chị đã và luôn động viên tinh thần giúp con có thêm nghị lực phấn đấu trong học tập và cuộc sống. Mặc dù đã hết sức cố gắng hoàn thành đồ án với toàn bộ nỗ lực của bản thân, nhƣng với năng lực kiến thức bản thân còn hạn chế nên đồ án không tránh khỏi những thiếu sót. Kính mong thầy cô và các bạn góp ý, giúp đỡ em để em có thể hoàn thiện kiến thức của bản thân nhiều hơn và phát triển đồ án, định hƣớng mới hơn trong tƣơng lai. Một lần nữa, em xin trân trọng gửi lời cảm ơn tới tất cả mọi ngƣời và em mong sẽ nhận đƣợc nhiều sự góp ý quý báu của các thầy cô và các bạn. Em xin chân thành cảm ơn!

Nguyễn Thị Vân

10

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

THÔNG TIN NGHIÊN CỨU 1. Thông tin chung - Tên đề tài: Nghiên cứu và ứng dụng kiểm thử hộp đen trong kiểm thử website phần mềm thi đua khen thƣởng - Sinh viên thực hiện: Nguyễn Thị Vân - Mã sinh viên 1221050117 - Lớp: Tin học Trắc Địa – K57 - Hệ đào tạo: Chính quy - Điện thoại: 01679826134 - Email: [email protected] - Đồ án tốt nghiệp đƣợc thực hiện tại: Hà Nội - Thời gian thực hiện: 2017 2. Mục tiêu Mục tiêu chính của đề tài là đƣa ra cái nhìn tổng quan về các kỹ thuật kiểm thử và đi sâu vào việc tìm hiểu các kỹ thuật kiểm thử hộp đen đã và đang đƣợc sử dụng. Đồng thời áp dụng đƣợc các kỹ thuật đó vào quy trình kiểm thử cho phần mềm Thi đua khen thƣởng 3. Nội dung chính - Xác định mục tiêu đề tài - Nghiên cứu các vấn đề kiểm thử - Tìm hiểu phân tích các kỹ thuật kiểm thử hộp đen - Tìm hiểu quy trình nghiệp vụ của phần mềm - Lựa chọn các kỹ thuật kiểm thử thích hợp - Thiết kế test case cho phần mềm - Thực hiện kiểm thử - Đƣa ra kết quả kiểm thử và kết luận 4. Kết quả chính đạt đƣợc  Hoàn thành tìm hiểu về kiểm thử, nắm đƣợc các kỹ thuật kiểm thử hộp đen cơ bản, áp dụng vào các bài toán cụ thể.  Hoàn thành việc tìm hiểu về dự án, chức năng của phần mềm cần kiểm thử tại đơn vị phụ trách.  Hoàn thành việc nghiên cứu quy trình kiểm thử, vận dụng các kỹ thuật đã nghiên cứu vào việc thiết kế bộ các trƣờng hợp kiểm thử.

Nguyễn Thị Vân

11

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

MỞ ĐẦU 1. Giới thiệu tổng quan Tổng quan tình hình nghiên cứu thuộc lĩnh vực của đề tài. Trong giai đoạn phát triển của công nghệ thông tin, ngành công nghệ phần mềm đang ngày chiếm một vị trí quan trọng trong xu hƣớng phát triển kinh tế công nghiệp hóa hiện đại hóa của đất nƣớc ta. Cùng với sự phát triển của công nghệ phần mềm, lỗi phần mềm và chất lƣợng phần mềm luôn là thách thức với bản thân ngành phần mềm khi thực tế đã chứng minh, kiểm thử phần mềm là giai đoạn chiếm đến hơn 40% thời gian, kinh phí và nguồn nhân lực phát triển dự án phần mềm hiện nay. Bên cạnh đó số lƣợng kỹ sƣ kiểm thử phần mềm Việt Nam hiện nay vẫn chƣa đáp ứng đƣợc nhu cầu thị trƣờng. Các dự án lập trình phần mềm trên thế giới, trung bình cứ 3 lập trình viên có1 kiểm thử viên trong khi đó ở Việt Nam số lƣợng đó là 5 : 1. Tại hội nghị quốc tế kiểm thử tự động năm 2011 tại TP.HCM cho biết với đà phát triển của ngành công nghiệp phần mềm nhƣ hiện nay thìViệt Nam trong thời gian tới sẽ thiếu khoảng 10.000 tester. Chúng ta đã và đang chứng kiến sự tăng trƣởng đáng kinh ngạc của ngành công nghiệp phần mềm trong vài thập kỷ qua. Nếu nhƣ trƣớc đây phần mềm máy tính chỉ đƣợc sử dụng để tính toán khoa học kỹ thuật và xử lý dữ liệu thìngày nay nó đã đƣợc ứng dụng vào mọi mặt của của đời sống hàng ngày của con ngƣời, từ các ứng dụng nhỏ để điều khiển các thiết bị dùng trong gia đình đến các ứng dụng lớn hơn nhƣ trợ giúp điều khiển các phƣơng tiện và hệ thống giao thông, trả tiền cho các hoá đơn, quản lý và thanh toán về tài chính, v.v...Vìthế con ngƣời ngày càng phụ thuộc chặt chẽ vào các sản phẩm phần mềm và do vậy đòi hỏi về chất lƣợng của các sản phẩm phần mềm ngày càng cao, tức là các phần mềm phải đƣợc sản xuất với giá thành hạ, dễ dùng, an toàn và tin cậy đƣợc. Kiểm thử có phƣơng pháp là một hoạt động không thể thiếu trong quy trình sản xuất phần mềm để đảm bảo các yếu tố chất lƣợng nêu trên của các sản phẩm phần mềm. Kiểm thử phần mềm là đề tài đang ngày càng nhận đƣợc sự quan tâm, nghiên cứu lớn bởi tầm quan trọng của nó. Các kỹ thuật kiểm thử đã và đang đƣợc nghiên cứu phát triển trong ngành phần mềm trên khắp thế giới, nổi bật nhƣ ISTQB (International Software Testing Quanlifications Board) là một tổ chức phi lợi nhuận cung cấp chứng chỉ thẩm định chất lƣợng của kiểm thử phần mềm có giá trị toàn cầu đã đƣa ra hệ thống một loạt các tài liệu, sách cung cấp kiến thức về lý thuyết kiểm thử và kỹ thuật kiểm thử phần mềm. Ở nƣớc ta, trong khoa Công nghệ thông tin thuộc các trƣờng đại học đã đặt kiểm thử phần mềm thành một môn học chính thức và xây dựng giáo trình, bài giảng riêng cho môn học này, ví dụ nhƣ bài giảng điện tử môn học kiểm thử và bảo đảm chất lƣợng phần mềm của tác giả Thạc Bình Cƣờng, Khoa Công nghệ thông tin, Trƣờng đại học Bách khoa Hà Nội đã trình bày khá chi tiết về lý thuyết các kỹ thuật kiểm thử. Ngoài ra là các đề tài nghiên cứu đi sâu vào một kỹ thuật kiểm thử riêng. Nguyễn Thị Vân

12

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Tuy nhiên, trong quá trình tìm hiểu làm đồ án thì chƣa có đề tài cụ thể nào về việc vận dụng tất cả các kỹ thuật kiểm thử vào việc phân tích, kiểm thử cho một sản phẩm phần mềm thực tế nào mà phần lớn mới chỉ dừng lại ở việc chỉ ra những ví dụ demo đơn lẻ cho từng kỹ thuật. Đặc biệt kiểm thử phần mềm thi đua đua khen thƣởng là một lĩnh vực kiểm thử khá mới mẻ và đang thu hút các công ty phát triển phần mềm thì đề tài về vấn đề này hiện chƣa đƣợc nghiên cứu cụ thể trong một đề tài nào. 2. Tính cấp thiết, ý nghĩa khoa học và thực tiễn của đề tài 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. Mặc dù công việc kiểm thử phần mềm không xa lạ song những khái niệm và kỹ thuật lại khá rắc rối. Ở mỗi loại và mỗi miền ứng dụng riêng biệt lại có các đặc thù riêng và cần đƣợc bổ trợ bởi các kỹ thuật kiểm thử riêng cho chúng. Ngƣời kiểm thử có thể hiểu và tự phát triển các kỹ thuật kiểm thử thích hợp cho các hệ thống phức tạp và chuyên dụng hơn dựa trên các kỹ thuật cơ bản. Phần mềm đã và đang đƣợc ứng dụng vào trong tất cả mọi mặt của cuộc sống hàng ngày, trong đó thi đua khen thƣởng là lĩnh vực đƣợc cho là cơ hội lớn đối với ngành phần mềm trong nƣớc khi mà các dự án về giáo dục, hành chính luôn đƣợc chú trọng. Để giải quyết việc thủ tục hồ sơ khen thƣởng giấy tờ cồng kềnh phức tạp. Việc tạo ra một sản phẩm có thể bán đƣợc trên thị trƣờng đòi hỏ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ƣợng dò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ản phẩm, thƣ viện lập trình,...của nhiều tổ chức khác nhau...Từ đó đòi hỏi việc kiểm thử phần mềm càng ngày càng trở nên rất quan trọng. Sự ra đời của phần mềm thi đua khen thƣởng mang đến hàng loạt các giải pháp cho thủ tục hồ sơ hành chính đi kèm mang lại những hiệu quả to lớn trong công tác quản lý hồ sơ, mặt khác còn là công cụ giúp Lãnh đạo, cán bộ giám sát kiểm soát hoạt đông thi đua khen thƣởng tỉnh giám sát, kiểm soát hoạt động thi đua khen thƣởng ở các đơn vị cơ sở .Điều này mở ra một thời cơ lớn cho ngành công nghệ phần mềm đồng thời với đó là sự cạnh tranh về hiệu quả, chất lƣợng phần mềm của các đơn vị thực hiện. 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. Kiểm thử là 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. Ngƣời làm phần mềm đều hiểu rõ vai trò quan trọng của nó, tuy nhiên không phải ai (trong ngành và ngoài ngành) cũng đều 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”.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 thử phần mềm ngày càng phát triển và mang tính khoa học. Mỗi một cơ quan, đơn vị lại có yêu cầu riêng về kỹ năng đối với

Nguyễn Thị Vân

13

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

ngƣời phụ trách kiểm thử. Đứng trƣớc một phần mềm cần kiểm thử mà ngƣời kiểm thử không có kiến thức hay thông tin nào về thông tin hiện thực phần mềm nhƣ mã nguồn của phần mềm, giải thuật đƣợc dùng, các dữ liệu xử lý...thìkiểm thử hộp đen là chính chiến lƣợc cho vấn đề này. Việc hiểu và nắm vững các kỹ thuật kiểm thử hộp đen là yêu cầu cơ bản, quan trọng hàng đầu đối với một ngƣời thực hiện công việc kiểm thử. Từ những phân tích trên, xác định đƣợc việc nắm rõ các kỹ thuật kiểm thử là yêu cầu tiên quyết của một ngƣời thực hiện công việc kiểm thử. Trong báo cáo đồ án này đƣợc chia thành 3 chƣơng với nội dung nhƣ sau: Chƣơng 1: Tổng quan về Chất lƣợng phần mềm và Kiểm thử phần mềm: Chƣơng này trình bày về những định nghĩa cơ bản về phần mềm, ngành công nghệ phần mềm, lỗi phần mềm, và qui trình xử lý lỗi phần mềm. Kiến thức cơ bản về kiểm thử phần mềm nhƣ các nguyên tắc kiểm thử, các phƣơng pháp kiểm thử, các giai đoạn kiểm thử phần mềm, kiểm thử hộp đen, kiểm thử hộp trắng. Chƣơng 2: Trình bày các kỹ thuật kiểm thử hộp đen: Kỹ thuật phân lớp tƣơng đƣơng, kỹ thuật phân tích giá trị biên, kỹ thuật dùng bảng quyết định, kỹ thuật kiểm thử n bộ, kỹ thuật dùng lƣợc đồ trạng thái, kỹ thuật dùng use case, kỹ thuật dùng đồ thị nhân quả và kỹ thuật đoán lỗi Chƣơng 3: Kiểm thử giao diện ứng dụng Website. Chƣơng này trình bày khái quát về Kiểm thử ứng dụng Website, đặc điểm về chất lƣợng của một ứng dụng Website, áp dụng viết kịch bản và thực thi kiểm thử cho một số chức năng cơ bản của ứng dụng website Thi đua khen thƣởng.

Nguyễn Thị Vân

14

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

CHƢƠNG 1: TỔNG QUAN VỀ CHẤT LƢỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM 1.1. Định nghĩa chất lƣợng phần mềm Có rất nhiều định nghĩa về chất lƣợng phần mềm đƣợc đƣa ra bởi các tổ chức, cá nhân khác nhau. Trong phạm vi của đồ án này trình bày một số định nghĩa tiêu biểu. Định nghĩa theo IEEE (1991): -

Định nghĩa 1: Chất lƣợng phần mềm là một mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng đƣợc yêu cầu đã đƣợc đặc tả. Định nghĩa 2: Chất lƣợng phần mềm là mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng đƣợc yêu cầu và sự mong đợi của khách hàng hay ngƣời sử dụng.

1.2. Định nghĩa đảm bảo chất lƣợng phần mềm Định nghĩa theo Daniel Galin: Đảm bảo chất lƣợng phần mềm (Soft are Quality Assure) là một tập hợp các hành động cần thiết đƣợc lên kế hoạch một cách hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp để thành lập các yêu cầu chức năng kỹ thuật cũng nhƣ các yêu cầu quản lý theo lịch trình và hoạt động trong giới hạn ngân sách. 1.3. Lỗi phần mềm 1.3.1. Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm - Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềm nhƣng có thể hiểu và phát biểu một cách đơn giản thì"Lỗi phần mềm là sự không khớp giữa chƣơng trình và đặc tả của nó". - Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng: + Lỗi sai: Sản phẩm phần mềm đƣợc xây dựng khác với đặc tả. + Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả nhƣng lại không có trong sản phẩm thực tế. + Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu đặc tả. 1.3.2. Các nguyên nhân gây lỗi phần mềm Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả các nguyên nhân chủ quan và các nguyên nhân khách quan. Dƣới đây là chín nguyên nhân chủ yếu gây ra lỗi phần mềm:

Nguyễn Thị Vân

15

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầu thƣờng nằm ở phía khách hàng. - Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Những lỗi này thƣờng xuất hiện trong giai đoạn đầu của dự án. Một số lỗi hay gặp phải: hiểu sai chỉ dẫn trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàng trình bày bằng lời nói và tài liệu, hiểu sai về phản hồi và thiếu quan tâm đến những đề cập của khách hàng.  Giải pháp khắc phục: Cần có ủy ban liên kết giữa khách hàng và nhà cung cấp để tránh lỗi trong giao tiếp. Ủy ban do quản trị dự án đứng đầu và khách hàng phải giới thiệu những ngƣời hiểu về mặt nghiệp vụ vào ủy ban đó. - Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trƣờng hợp các nhà phát triển cố tình làm sai lệch các yêu cầu trong tài liệu đặc tả. Nguyên nhân của việc này đến từ các áp lực thời gian, ngân sách, hay cố tình sử dụng lại các môđun từ các dự án trƣớc mà chƣa phân tích đầy đủ những thay đổi để thích nghi với các yêu cầu mới.  Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem giải pháp nhƣ thế nào, sắp xếp ƣu tiên xem bỏ đƣợc yêu cầu nào hay sử dụng lại đƣợc mô-đun nào. - Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyên gia thiết kế hệ thống, các kiến trúc sƣ hệ thống, kỹ sƣ phần mềm, các nhà phân tích xây dựng phần mềm theo yêu cầu. Các lỗi điển hình bao gồm: + Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai. + Quy trình định nghĩa có chứa trình tự lỗi. + Sai sót trong các định nghĩa biên nhƣ > 3 hay ≥ 3. + Thiếu sót các trạng thái hệ thống phần mềm đƣợc yêu cầu. + Các lỗi lập trình: Có rất nhiều lý do dẫn đến việc các lập trình viên gây ra các lỗi lập trình. Những lý do này bao gồm: Sự hiểu sai các tài liệu thiết kế, ngôn ngữ; sai sót trong ngôn ngữ lập trình; sai sót trong việc áp dụng các công cụ phát triển; sai sót trong lựa chọn dữ liệu... + Không tuân thủ theo các tài liệu hƣớng dẫn và tiêu chuẩn lập trình: Các lỗi phần mềm có thể đến từ việc không tuân thủ các tài liệu và tiêu chuẩn lập trình của các tổ chức phát triển phần mềm. + Thiếu sót trong quá trình kiểm thử: Lỗi phần mềm có thể đến từ chính quá trình kiểm thử khi mà ngƣời kiểm thử để lọt lỗi.  Những lỗi này đến từ các nguyên nhân sau đây: + Kế hoạch kiểm thử chƣa hoàn chỉnh, để sót yêu cầu cần kiểm thử. + Lỗi trong tài liệu và báo cáo kiểm thử. + Việc sửa chữa các lỗi đƣợc phát hiện không hoàn chỉnh do áp lực thời gian hay do thiếu cẩn thận. -

Nguyễn Thị Vân

16

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Giải pháp khắc phục: Lên kế hoạch kiểm thử cụ thể tại giai đoạn đầu của dự án. - Các lỗi thủ tục: Các thủ tục hƣớng dẫn cho ngƣời sử dụng tại từng bƣớc của tiến trình. Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm phức tạp mà các tiến trình đƣợc thực bằng nhiều bƣớc, mỗi bƣớc có thể có nhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian. Các lỗi có thể đến từ việc viết các thủ tục. - Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo trì đôi khi có những sai sót trong các tài liệu liên quan. Những lỗi này có thể là nguyên nhân gây ra lỗi trong giai đoạn phát triển kế tiếp và giai đoạn bảo trì. 1.3.3. Chi phí cho việc sửa lỗi phần mềm Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn nào của vòng đời phần mềm.Tuy nhiên công việc này nên đƣợc thực hiện càng sớm càng tốt vì càng về giai đoạn sau của vòng đời phần mềm, chi phícho việc tìm và sửa lỗi càng tăng, đặc biệt là đến giai đoạn đã triển khai phần mềm thìchi phícho sửa lỗi sẽ trở nên rất lớn và ảnh hƣởng trực tiếp đến uy tín của tổ chức phát triển phần mềm. 1.3.4. Quy trình xử lý lỗi phần mềm - Quy trình xử lý lỗi có thể bao gồm 6 bƣớc chính: Bƣớc 0: Bắt đầu: Phát hiện phần mềm có lỗi. Bƣớc 1: Đƣa lỗi lên hệ thống quản lý lỗi. Bƣớc 2: Gán lỗi cho nhân viên phát triển. Bƣớc 3: Xử lý lỗi. Bƣớc 4: Kiểm thử lại. Bƣớc 5: Đóng lỗi. 1.4. Kiểm thử phần mềm 1.4.1. Khái niệm kiểm thử phần mềm Kiểm thử phần mềm là quy trình đƣợc sử dụng để đánh giá, kiểm tra chất lƣợng phần mềm ở nhiều khía cạnh khác nhau dựa trên các yêu cầu của ngƣời sử dụng đối với sản phẩm phần mềm, nhằm đảm bảo phần mềm hoạt động tốt trong các môi trƣờng, các trƣờng hợp khác nhau. Có thể định nghĩa một cách dễ hiểu nhƣ sau:

Nguyễn Thị Vân

17

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gìkhông mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa? 1.4.2. Lý do cần kiểm thử phần mềm  Phần mềm nào cũng có lỗi bởi vì nó do con ngƣời làm ra.  Kiểm thử độ tin cậy của phần mềm.  Các lỗi đang dùng trong thực tế có thể rất tốn chi phí cũng nhƣ gây nguy hiểm đến con ngƣời.  Tránh kiện tụng của khách hàng.  Phát triển doanh nghiệp.  Lỗi phát hiện càng sớm thìchi phíkhắc phục càng nhỏ. 1.4.3. Mục tiêu của kiểm thử phần mềm  Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm đƣợc kiểm thử.  Tiến hành sửa lỗi ở các phần mềm đƣợc kiểm thử và kiểm thử lại cho đến khi đạt một mức độ chất lƣợng phần mềm chấp nhận đƣợc.  Thực thi những trƣờng hợp kiểm thử một cách hiệu quả trong một giới hạn ngân sách và lịch trình cho phép. 1.4.4. Các nguyên tắc cơ bản của kiểm thử phần mềm Có 7 nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc đó là:  Kiểm thử để chứng minh sự có mặt của lỗi và không chứng minh điều ngƣợc lại: Kiểm thử có thể cho thấy sự có mặt của lỗi nhƣng không thể chứng minh điều ngƣợc lại là chƣơng trình không có lỗi. Việc kiểm thử giảm nguy cơ không tìm thấy lỗi trong phần mềm nhƣng ngay cả khi không tìm thấy lỗi thì cũng không thể chứng minh đƣợc sản phẩm phần mềm đƣợc phát triển hoàn toàn chính xác.  Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện đƣợc cho tất mọi trƣờng hợp kiểm thử. Do vậy thay vì kiểm thử mọi khía cạnh, ta phải tập trung vào kiểm thử những yếu tố quan trọng và nhiều rủi ro.  Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm, và nên tập trung và những mục tiêu kiểm thử nhất định.  Phân cụm lỗi: Một số lƣợng nhỏ các mô-đun phần mềm có thể chứa hầu hết các lỗi đƣợc phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung hầu hết các lỗi vận hành.

Nguyễn Thị Vân

18

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Kiểm thử ngƣợc: Nếu một phƣơng pháp kiểm thử đƣợc lặp đi lặp lại nhiều lần, các trƣờng hợp kiểm thử giống nhau sẽ không phát hiện đƣợc triệt để lỗi mới. Để khắc phục điều này ta có thể sử dụng nguyên tắc "kiểm thử ngƣợc", các trƣờng hợp kiểm thử cần phải đƣợc xem xét và duyệt lại một cách đều đặn, và việc kiểm thử mới cần phải đƣợc viết lại để thực thi những phần khác của phần mềm hay hệ thống để tìm ra nhữ ng lỗi tiềm ẩn.  Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử đƣợc thực hiện trong những hoàn cảnh khác nhau thì khác nhau.  Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp đƣợc gì nếu hệ thống không dùng đƣợc hoặc không đáp ứng đƣợc yêu cầu và sự mong đợi của khách hàng. 1.4.5. Các phƣơng pháp kiểm thử Phân loại dựa vào các yếu tố: Chiến lƣợc kiểm thử; Phƣơng pháp kiểm thử; Kỹ thuật kiểm thử.  Chiến lƣợc kiểm thử + Kiểm thử thủ công + Kiểm thử tự động  Phƣơng pháp tiến hành kiểm thử + Kiểm thử tĩnh + Kiểm thử động  Kỹ thuật kiểm thử + Kiểm thử hộp đen + Kiểm thử hộp trắng +Kiểm thử hộp xám 1.4.5.1. Kiểm thử tĩnh – Static testing Là phƣơng pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chƣơng trình. Kiểu kiểm thử này thƣờng đƣợc sử dụng bởi chuyên viên thiết kế ngƣời mà viết mã lệnh một mình. Kiểm thử tĩnh cũng có thể đƣợc tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chƣơng trình đƣợc phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về cú pháp của chƣơng trình.

Nguyễn Thị Vân

19

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

1.4.5.2. Kiểm thử động – Dynamic testing Là phƣơng pháp thử phần mềm thông qua việc dùng máy chạy chƣơng trình để điều tra trạng thái tác động của chƣơng trình. Đó là kiểm thử dựa trên các ca kiểm thử xác định bằng sự thực hiện của đối tƣợng kiểm thử hay chạy các chƣơng trình. Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự đƣợc biên dịch và chạy. Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có nhƣ mong muốn hay không. Các phƣơng pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests… 1.4.5.3. Kiểm thử hộp đen - Black box testing Một trong những chiến lƣợc kiểm thử quan trọng là kiểm thử hộp đen, hƣớng dữ liệu, hay hƣớng vào/ra. Kiểm thử hộp đen xem chƣơng trình nhƣ là một “Hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cƣ xử và cấu trúc bên trong của chƣơng trình không thực hiện theo đặc tả của nó. Theo hƣớng tiếp cận này, dữ liệu kiểm tra đƣợc lấy chỉ từ các đặc tả. Các phƣơng pháp kiểm thử hộp đen:  Phân lớp tƣơng đƣơng – EQUIVALENCE PARTITIONING.  Phân tích giá trị biên BOUNDARY VALUE ANALYSIS.  Kiểm thử mọi cặp ALL-PAIRS TESTING .  Kiểm thử Fuzz FUZZ TESTING .  Kiêm thử dựa trên mô hình – MODEL-BASED TESTING .  Ma trận dấu vết TRACEABILITY MATRIX .  Kiểm thử thăm dò EXPLORATORY TESTING .  Kiểm thử dựa trên đặc tả SPECIFICATION -BASE TESTING . Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tƣợng kiểm thử. Mức kiểm thử viên mà khi đó có thể xác minh là đối tƣợng với dữ liệu đầu vào đã cho, giá trị đầu ra (cách thức hoạt động) có giống với giá trị mong muốn đã đƣợc xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhƣng không đủ để ngăn chặn những rủi ro chắc chắn.  Ƣu, nhƣợc điểm Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là một mã lệnh phải có lỗi, sử dụng nguyên tắc “Hãy đòi hỏi và bạn đƣợc nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không Nguyễn Thị Vân

20

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

tìm ra. Nhƣng mặt khác, ngƣời cũng nói kiểm thử hộp đen “Giống nhƣ là đi trong bóng tối mà không có đen vậy” Bởi vìkiểm thử viên không biết các phần mềm đƣợc kiểm tra thực sự đƣợc xây dựng nhƣ thế nào. Đó là lí do mà có nhiều trƣờng hợp mà một kiểm thử duy nhất, và/hoặc một số phần mềm của chƣơng trình không đƣợc kiểm tra chút nào. Do vậy, kiểm thử hộp đen có ƣu điểm của “Một sự đánh giá khách quan”, mặt khác nó lại có nhƣợc điểm của “Thăm dò mù”. 1.4.5.4. Kiểm thử hộp trắng – White box testing Là một chiến lƣợc kiểm thử khác, trái ngƣợc hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hƣớng logic cho phép bạn khảo sát cấu trúc bên trong của chƣơng trình. Chiến lƣợc này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chƣơng trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chƣơng trình (và cả mã lệnh thực hiện chúng).  Các phƣơng pháp kiểm thử hộp trắng:  Kiểm thử giao diện lập trình ứng dụng - API testing (application programming interface): là phƣơng pháp kiểm thử của ứng dụng sử dụng các API công khai và riêng tƣ.  Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu chuẩn về bao phủ mã lệnh.  Các phương pháp gán lỗi – Fault injection.  Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.  Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh.  Phƣơng pháp kiểm thử hộp trắng cũng có thể đƣợc sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà đƣợc tạo cùng với các phƣơng pháp kiểm thử hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của một hệ thống ít khi đƣợc kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã đƣợc kiểm tra. 1.5. Quy trình kiểm thử phần mềm 1.5.1. Các bƣớc trong một quy trình kiểm thử phần mềm Thuật ngữ: Software Test Process là 1 chuỗi các hoạt động, phƣơng thức thực hiện mà con ngƣời phải làm để thực hiện kiểm thử cho hệ thống phần mềm.  Quy trình kiểm thử phần mềm bao gồm các bƣớc:  Lập kế hoạch kiểm tra.  Phân tích, thiết kế test case.  Thực hiện test.  Đánh giá kết quả test.  Tổng kết quá trình kiểm thử. a) Lập kế hoạch :

Nguyễn Thị Vân

21

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Nhiệm vụ quan trọng trong phần lập kế hoạch kiểm thử là xác định đƣợc các yếu tố sau:  Các giai đoạn kiểm thử áp dụng cho dự án  Các phƣơng pháp kiểm thử  Các công cụ kiểm thử  Nguồn lực kiểm thử  Tài nguyên môi trƣờng kiểm thử, bao gồm các tài nguyên phần cứng và phần mềm  Mốc bàn giao các tài liệu kiểm thử  Nhằm chỉ định và mô tả các loại kiểm tra sẽ đƣợc triển khai và thực hiện. Kết quả của bƣớc lập kế hoạch là bản tài liệu kế hoạch KTPM bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lƣợc kiểm tra, cho đến thời gian và phân định lực lƣợng kiểm tra viên, xác định tiêu chíkết thúc kiểm thử. b) Phân tích và thiết kế test Nhằm chỉ định các testcase và các bƣớc kiểm tra chi tiết cho mỗi phiên PM. Giai đoạn thiết kế test là hết sức quan trọng, nó đảm bảo tất cả các tình huống kiểm tra hết tất cả các yêu cầu Các bƣớc thiết kế test :  Xác định và mô tả test case  Mô tả các bƣớc chi tiết để kiếm tra  Xem xét và khảo sát độ bao phủ của việc kiểm tra  Xem xét testcase và các bƣớc kiểm tra c) Thực hiện test Mục đích thực hiện các bƣớc kiểm tra đã thiết kế và ghi nhận kết quả d) Đánh giá test Mục đích: Đánh giá toàn bộ quá trình kiểm tra bao gồm xem xét và đánh giá kết quả kiểm tra lỗi, chỉ định các yêu cầu thay đổi và tính toán số liệu liên quan, đến quá trình kiểm tra. e) Tổng kết quá trình kiểm thử Viết báo cáo tổng kết.

1.5.2. Mô hình phát triển và kiểm thử phần mềm hình chữ V

Nguyễn Thị Vân

22

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Các tính chất cần ghi nhận trên mô hình chữ V: Requirements

Preparation Acceptance

Preparation

Preparation

Integration

Unit/Component Specification

Hình 1-1 Mô hình phát triển và kiểm thử phần mềm hình chữ V  Bƣớc 1: Requirements Definition (Xác định yêu cầu): Đóng vai trò xác định yêu cầu bài toán, tính chất công việc, khi bƣớc này hoàn thành thi đƣợc đƣa vào bƣớc kiểm thử Acceptance Test (kiểm thử chấp nhận).  Bƣớc 2: Functional system design (Thiết kế chức năng hệ thống): Bƣớc này đƣợc xảy ra trên kỹ thuật hệ thống và thiết kế, nó là bƣớc mức độ cao vìthời điểm này, nó phải cung cấp đƣợc tổng quan về giải pháp xử lý, nền tảng xây dựng, hệ thống sản phẩm, và các dịch vụ. Sau khi bƣớc này đƣợc hoàn thành nó chuyển sang mức System Test(kiểm thử hệ thống)  Bƣớc 3: Technical system design (Thiết kế kỹ thuật hệ thống): Sau khi hoàn thành bƣớc này chuyển sang mức test: Integration (tich hợp).  Bƣớc 4: Component Specification (Đặc tả thành phần): Đây là bƣớc mức độ thấp của thiết kế, là giai đoạn mà sản phẩm phần mềm đã đƣợc tiến hành thiết kế thực tế, bắt đầu đi vào xác định các yếu tố logic, các sơ đồ lớp với mọi phƣơng thức, mối liên quan giữa các lớp, giai đoạn này có thể phát sinh các mâu thuẫn, sự phùhợp hay không phùhợp….Sau khi bƣớc này đƣợc thực hiện thành công thì đƣợc chuyển đến công đoạn test gọi là Unit/Component Test (kiểm thử đơn vị, thành phần).  Ƣu điểm và Nhƣợc Điểm.  Ƣu điểm.

Nguyễn Thị Vân

23

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

- Đơn giản dễ sử dụng. - Có hoạt động, kế hoạch cụ thể cho quá trình test. - Tiết kiệm đƣợc thời gian, và có cơ hội thành công cao hơn waterfall. - Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bƣớc đầu.  Nhược điểm. - Độ linh hoạt ít và còn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau mỗi step thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức tạp và dễ hiểu, thì việc thực hiện nhiều công đoạn test nhƣ vậy là tốn thời gian. - Giống với waterfall, sản phẩm của dự án chỉ đƣợc xuất hiện khi tất cả các bƣớc đƣợc hoàn thành xong, không có nguyên mẫu ngay từ ban đầu. Không đáp ứng đƣợc yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm. - Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bƣớc đầu tiên, thực hiện lại, update lại tài liệu.  Áp dụng cho những dự án nhƣ thế nào.   

Dự án có kích thƣớc nhỏ, và trung bình, các yêu cầu dự án là rõ ràng, cố định. Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn có để đảm bảo đƣợc yêu cầu, đọc nhanh, test nhanh và coding nhanh. Nếu khách hàng có sự tự tin cao trong yêu cầu thiết kế (nghĩa là ít thay đổi, ít dao động) thì V model là lựa chọn cần thiết.

Các hoạt động hiện thực và các hoạt động kiểm thử đƣợc tách biệt nhƣng độ quan trọng là nhƣ nhau. Chữ V minh họa các khía cạnh của hoạt động Verification và Validation. Cần phân biệt giữa các mức độ kiểm thử ở đó mỗi mức kiểm thử là kiểm thử trên mức phát triển phần mềm tƣơng ứng. Mô hình phát triển tăng tiến - tƣơng tác :  Qui trình thiết lập các yêu cầu phần mềm, thiết kế, xây dựng, kiểm thử hệ thống phần mềm đƣợc thực hiện nhƣ 1 chuỗi các chu kỳ phát triển ngắn hơn.  Hệ thống có đƣợc từ một bƣớc lặp đƣợc kiểm thử ở nhiều cấp trong việc phát triển hệ thống đó.  Kiểm thử hồi quy có độ quan trọng tăng dần theo các bƣớc lặp (không cần trong bƣớc đầu tiên).  Thanh kiểm tra và kiểm định có thể ₫ƣợc thực hiện theo kiểu tăng dần trên từng bƣớc lặp. Các tính chất của qui trình kiểm thử tốt :  Cần có 1 mức độ kiểm thử cho mỗi công đoạn phát triển phần mềm.  Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêu đặc thùcủa mình.

Nguyễn Thị Vân

24

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Việc phân tích và thiết kế test case cho 1 mức độ kiểm thử nên bắt đầu sớm nhất nhƣ có thể có.  Các tester nên xem xét các tài liệu sớm nhƣ có thể có, ngay sau khi các tài liệu này đƣợc tạo ra trong chu kỳ phát triển phần mềm.  Số lƣợng và cƣờng độ của các mức kiểm thử đƣợc điều khiển theo các yêu cầu đặc thùcủa project phần mềm đó.  Sơ đồ tổ chức phổ biến của đội kiểm thử. 1.5.3. Nhân lực kiểm thử phần mềm

1.5.4. Quy trình xây dựng kế hoạch kiểm thử Ghi chú quan trọng: Sau khi xây dựng xong kế hoạch kiểm thử, ta có thể thay đổi nó nhƣng phải tuân thủ quy trình yêu cầu thay đổi. Các hoạt động chính trong việc xây dựng kế hoạch kiểm thử: -

Định nghĩa mục đích, phạm vi, chiến lƣợc, cách tiếp cận, các điều kiện chuyển, các rủi ro, kế hoạch giảm nhẹ và tiêu chíchấp thuận. Định nghĩa cách thức thiết lập môi trƣờng và các tài nguyên đƣợc dùng cho việc kiểm thử. Thiết lập cơ chế theo dõi lỗi phát hiện. Chuẩn bị ma trận theo dõi bao phủ mọi yêu cầu phần mềm. Báo cáo trạng thái kiểm thử.

Nguyễn Thị Vân

25

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

-

Phát hành leo thang (Escalating Issues). Raising Testing related PIR (Process Improvement Request)/ PCR (Process Change Request). Các thành phần chính trong kế hoạch kiểm thử. Test Planning (Kế hoạch kiểm thử)

 Xây dựng kế hoạch kiểm thử Gồm có 4 bƣớc sau: Bƣớc 1: Kế hoạch Kiểm thử. Bƣớc 2: Phân tích & thiết kế kiểm thử.

Test Analysis – Design (Phân tích & thiết kế kiểm thử)

Bƣớc 3: Thi hành kiểm thử. Bƣớc 4: Báo cáo kiểm thử.

Test Executing (Thi hành kiểm thử)

Test Report – Evaluation (Báo cáo kiểm thử)

Hình 1-3 Xây dựng kế hoạch kiểm thử Bƣớc 1  Kế hoạch kiểm thử: Test Planning Test Manager (Ngƣời quản lí kiểm thử) hoặc Test Leader (Quản lí nhóm kiểm thử sẽ xây dựng kế hoạch ban đầu về kiểm thử. Định nghĩa phạm vi kiểm thử. Định nghĩa các chiến lƣợc kiểm thử. Nhận dạng các rủi ro và yếu tố bất ngờ. Nhận dạng các hoạt động kiểm thử nào là thủ công, kiểm thử nào là tự động hay cả hai. - Ƣớc lƣợng chi phíkiểm thử và xây dựng lịch kiểm thử. - Nhận dạng môi trƣờng kiểm thử. Kế hoạch kiểm thử cần đƣợc: -

Nguyễn Thị Vân

26

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Xem lại bởi QC team (đội kiểm tra chất lƣợng), Developers (lập trình viên), Business Analysis (Phân tích Kinh doanh), TA (if need), PM (quản lí dự án) and Customer (khách hàng). - Chấp thuận bởi: Project Manager (Quản lídự án) and Customer (khách hàng). - Hiệu chỉnh trong suốt chu kỳ kiểm thử để phản ánh các thay đổi nếu cần thiết. Nhiệm vụ của Test Plan (Kế hoạch kiểm thử): -

Xác định phạm vi kiểm thử, các rủi ro, mục tiêu. Xác định cách tiếp cận (đối tƣợng kiểm thử, độ bao phủ, số ngƣời tham gia, các tài liệu liên quan). - Thực thi chính sách, chiến lƣợc kiểm thử. - Xác định nguồn lực tham gia kiểm thử (con ngƣời, phần cứng, phần mềm, thiết bị, công cụ hỗ trợ). - Lên kế hoạch phân tích, thiết kế, thực thi, đánh giá. - Xác định tiêu chíkết thúc kiểm thử. Bƣớc 2 -

 Phân tích & thiết kế kiểm thử (Test Analysis – Design ) Test Analyst (Phân tích kiểm thử) hoặc Test Designer (Thiết kế kiểm thử) sẽ thiết kế (định nghĩa) các testcase từ các yêu cầu liên quan (thídụ từ thông tin trong usecase) Sẽ thiết kế (định nghĩa) các testcase từ các yêu cầu chức năng và các yêu cầu không chức năng của phần mềm. - Các testcase cần bao phủ tất cả khía cạnh kiểm thử cho từng yêu cầu phần mềm. - Các testcase cần bao phủ tất cả yêu cầu trong các chiến lƣợc kiểm thử. - Nếu cần kiểm thử tự động, Test Designer (Nhân viên thiết kế kiểm thử) sẽ xây dựng các kịch bản dựa trên các testcase/Test procedures. Các testcase cần đƣợc: -

-

Xem xét lại bởi Project Leader (Quản lí dự án), Developer (Lập trình viên) có liên quan, các Testers (nhân viên kiểm thử) khác, Test Leader (Quản lí nhóm test), Business Analysis và Customer (Khách hàng). - Chấp thuận bởi Test Leader (quản línhóm test) hoặc Customer (Khách hàng). - Hiệu chỉnh/cập nhật nếu Tester đã tìm đƣợc những lỗi mà không nằm trong các testcase hiện có. Bƣớc 3  Thi hành kiểm thử (Test Executing) - Tester sẽ đƣợc bố trí công việc bởi Test Leader (Quản lí nhóm kiểm thử) để thi hành kiểm thử.

Nguyễn Thị Vân

27

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

-

Thi hành kiểm thử theo từng testcase. Thực hiện kiểm thử đặc biệt . Thực hiện kịch bản kiểm thử mà không đƣợc định nghĩa trong testcase. Kiểm thử lại các lỗi đã đƣợc sửa. Tester sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi chúng cho đến khi chúng đã đƣợc xử lý. - Ở công đoạn kiểm thử độ chấp thuận, Customer sẽ thi hành kiểm thử để kiểm định xem hệ thống phần mềm có thỏa mãn các nhu cầu ngƣời dùng không . Bƣớc 4  Báo cáo kiểm thử (Test Report and Evaluation) Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ thống theo dõi các lỗi. - Tạo các báo cáo lỗi. - Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi. - Tính và phân phối các thông tin đo lƣờng hoạt động kiểm thử. - Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi. - Xác định xem đã đạt tiêu chí thành công và để hoàn thành kiểm thử chƣa. Nhiệm vụ -

Kiểm tra sản phẩm thực tế so với kế hoạch. Đóng các báo cáo về sự cố hoặc ghi chép các thay đổi cho bất cứ vấn đề nào còn đang mở. Viết biên bản chấp nhận phần mềm. Lƣu lại các sản phẩm kiểm thử, môi trƣờng kiểm thử, cơ sở hạ tầng để sử dụng lần sau (Đặc biệt kiểm thử bảo trì). Phân tích các bài học. Sử dụng tài liệu thu thập đƣợc để sử dụng định kì.

1.6. Các cấp độ kiểm thử phần mềm. Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm. Các kỹ thuật đƣợc dùng cho mỗi kiểu kiểm thử trong project:     

Kiểm thử tích hợp (Integration Testing). Kiểm thử hệ thống (System Testing). Kiểm thử độ chấp thuận (Acceptance Testing). Kiểm thử chức năng của ngƣời dùng (Functionality Testing). Kiểm thử hồi qui (Regression Testing).

Nguyễn Thị Vân

28

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Kiểm thử việc phục hồi sau lỗi (Failover and Recovery Testing).  Kiểm thử việc kiểm soát an ninh và truy xuất (Security and Access Control Testing).  Kiểm thử việc cấu hình và cài đặt (Configuration and Installation Testing).  Kiểm thử đặc biệt (Ad-hoc Testing).  Kiểm thử hiệu suất (Performance Testing).

Hình 1-4. Sơ đồ các cấp độ kiểm thử. 1 .6.1. Kiểm thử đơn vị – Unit test Kiểm thử đơn vị hỗ trợ tìm lỗi nhanh hơn, giúp thiết kế tốt hơn, giảm chi phí. Kiểm thử đơn vị đƣợc chia ra làm 4 loại chính: - Kiểm thử câu lệnh - Kiểm thử rẽ nhánh - Kiểm thử điều kiện - Kiểm thử đƣờng đi Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử đƣợc. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phƣơng thức (Method) đều có thể đƣợc xem là Unit. Vì Unit đƣợc chọn để kiểm tra 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

Nguyễn Thị Vân

29

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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ùng trong một đơn thể Unit đang kiểm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ đƣợc đền bùbằng việc tiết kiệm rất nhiều thời gian và chi phícho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó. Unit Test thƣờng do lập trình viên thực hiện. Công đoạn này cần đƣợc thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Thông thƣờng, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chƣơng trình. Mục đích của Unit Test là bảo đảm thông tin đƣợc xử lý và xuất (khỏi Unit) là chính xác, trong mối tƣơng quan với dữ liệu nhập và chức năng của Unit. Điều này thƣờng đòi hỏi tất cả các nhánh bên trong Unit đều phải đƣợc kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thƣờng là một chuỗi các lệnh đƣợc thực thi trong một Unit.Vídụ: chuỗi các lệnh sau điều kiện If và nằm giữa then ... else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa. Cùng với các mục kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trƣớc các ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ liệu đầu vào, các bƣớc thực hiện và dữ liệu đầu ra mong muốn. Các Test case và Test script này nên đƣợc giữ lại để tái sử dụng. 1.6.2. Kiểm thử tích hợp – Intergration Test Kiểm thử tích hợp đảm bảo tích hợp các chức năng, các module tuân theo thiết kế của sản phẩm, đảm bảo giao tiếp, liên kết giữa các chức năng module hoạt động đƣợc, đúng theo yêu cầu. Integration test 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 Unit Test kiểm tra các thành phần và Unit riêng lẻ thìIntgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. Hai mục tiêu chính của Integration Test: -

Phát hiện lỗi giao tiếp xảy ra giữa các Unit. Tích hợp các Unit đơ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ểm thử ở mức hệ thống (System Test). Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự

Nguyễn Thị Vân

30

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

đƣợc kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test. Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã đƣợc kiểm tra cẩn thận trƣớc đó bằng Unit Test, và tất cả các lỗi mức Unit đã đƣợc sửa chữa. Một số ngƣời hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thìkhông cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác. Một chiến lƣợc cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm đƣợc tích hợp vào một nhóm các Unit khác đã tích hợp trƣớc đó và đã hoàn tất các đợt Integration Test trƣớc đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trƣớc đó, điều này sẽ làm cho số lƣợng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể. Có 4 loại kiểm thử trong Integration Test: -

-

-

Kiểm thử cấu trúc (Structure Test): Tƣơng tự White Box Test, kiểm thử cấu trúc nhằm bảo đảm các thành phần bên trong của một chƣơng trình chạy đúng và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chƣơng trình chẳng hạn các câu lệnh và nhánh bên trong. Kiểm thử chức năng (Functional Test): Tƣơng tự Black Box Test, kiểm thử chức năng chỉ chú trọng đến chức năng của chƣơng trình, mà không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chƣơng trình theo yêu cầu kỹ thuật. Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ thống. Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống.

1.6.3. Kiểm thử hệ thống – System Test a. Mục đích của Kiểm thử hệ thống + Nhằm đảm bảo chức năng, các đặc tính của sản phẩm được đúng và đủ của sản phẩm phầm mềm đó. + Môi trường thực hiện gần giống với môi trường người dùng cuối. Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không. System Test bắt đầu khi tất cả các bộ phận của phần mềm đã đƣợc tích hợp thành công. Thông thƣờng loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trƣờng hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc

Nguyễn Thị Vân

31

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, ngƣời kiểm thử cũng tìm kiếm các lỗi, nhƣng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lƣợng của toàn hệ thống. Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể 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 Unit Test và Integration Test để bảo đảm mọi Unit và sự tƣơng tác giữa chúng hoạt động chính xác trƣớc khi thực hiện System Test. Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã đƣợc hình thành cùng với các thành phần đã đƣợc kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm nhƣ một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. System Test kiểm thử cả các hành vi chứ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ện lợ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 cho việ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ạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thƣờng đã sẵn sàng cho khách hàng hoặc ngƣời dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (Alpha/Beta Test). Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thƣờng đƣợc thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm: Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế. Việc kiểm thử chức năng chú trọng đến 2 phần chính là kiểm thử giao diện ngƣời dùng (User interface) và kiểm thử luồng nghiệp vụ (Bussiness Flow Testing). b) Kiểm thử giao diện người sử dụng Kiểm thử giao diện ngƣời sử dụng gọi tắt kiểm thử giao diện là việc kiểm tra các tƣơng tác của ngƣời dùng với phần mềm. Mục tiêu của kiểm thử giao diện là để đảm bảo rằng giao diện ngƣời dùng cung cấp cho ngƣời sử dụng cách truy cập và sử dụng các chức năng của hệ thống một cách thích hợp. Ngoài ra, kiểm thử giao diện còn để đảm bảo rằng các đối tƣợng trên giao diện giống nhƣ thiết kế và phù hợp với tổ chức hoặc chuyên ngành.

Nguyễn Thị Vân

32

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Bảng 1-1. Kiểm thử giao diện ngƣời sử dụng Mục đích kiểm thử

Cách thức thực hiện

Điều kiện hoàn thành các vấn đề

Kiểm tra: Việc sử dụng thông qua mục tiêu kiểm thử phản ánh đúng các chức năng và yêu cầu nghiệp vụ, bao gồm màn hình đến màn hình, trƣờng đến trƣờng và sử dụng các phƣơng pháp truy cập (phím tabs, di chuột, tổ hợp phím). Các đối tƣợng và thuộc tính màn hình nhƣ menus, size, posittion, state. Tạo ra và chỉnh sửa kịch bản kiểm thử cho mỗi màn hình để kiểm tra việc sử dụng đúng cách và tình trạng các đối tƣợng cho mỗi màn hình và đối tƣợng của ứng dụng. Mỗi màn hình đƣợc kiểm tra thành công đúng phiên bản kiểm tra hoặc phạm vi chấp nhận đƣợc Không phải toàn bộ các thuộc tính của các đối tƣợng đều có thể chấp nhận đƣợc.

Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ƣu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu nhƣ thời gian xử lý hay đáp ứng câu truy vấn... - Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận hành đúng dƣới áp lực cao (vídụ nhiều ngƣời truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thƣờng nhƣ đang giao dịch thìngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị nhƣ POS, ATM...)... - Kiểm thử cấu hình (Configuration Test). - Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống. - Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trƣớc đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch nhƣ ngân hàng trực tuyến... Nhìn từ quan điểm ngƣời dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng bảo đảm hệ thống đủ khả năng làm việc trong môi trƣờng thực. -

Nguyễn Thị Vân

33

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Lƣu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trƣng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, ngƣời Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào. 1.6.4. Kiểm thử chấp nhận sản phẩm – Acceptance Test Thông thƣờng, sau giai đoạn System Test là Acceptance Test, đƣợc khá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 đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khá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). Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trƣờng hợp, các phép kiểm thử của System Test và Acceptance Test 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. Đối với những sản phẩm dành bán rộng rãi trên thị trƣờng cho nhiều ngƣời sử dụng, thông thƣờng sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta – Beta Test. Với Alpha Test, ngƣời dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ đƣợc gửi tới cho ngƣời dùng để kiểm thử ngay trong môi trƣờng thực, lỗi hoặc phản hồi cũng sẽ gửi ngƣợc lại cho lập trình viên để sửa chữa. Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thìkết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử trƣớc đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng nhƣ sự mong chờ của khách hàng. Vídụ đôi khi một phần mềm xuất sắc vƣợt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án, nhƣng khách hàng khi kiểm thử sau cùng vẫn thất vọng vìbố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v... Kết luận Kiểm thử phần mềm là một ngành mới, có rất nhiều những quan điểm, khái niệm về kiểm thử đã đƣợc đƣa ra. Việc xác định và nắm chắc nội dung cơ bản về kiểm thử là nền tảng để tìm hiểu và có những hƣớng phát triển rộng hơn, sâu hơn. Chƣơng 1 đã giới thiệu những kiến thức cơ bản nhất về kiểm thử phần mềm, xác định đƣợc tầm quan trọng và đƣa ra những mặt còn hạn chế của việc kiểm thử. 1.6.5. Một số cấp độ kiểm thử khác Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác nhƣ: -

Kiểm thử hồi quy – Regression Testing

Nguyễn Thị Vân

34

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

-

Kiểm thử tính đúng – Correctness testing Các phương pháp kiểm thử con người

1.7. Nguyên tắc kiểm thử phần mềm Để kiểm thử đạt hiệu quả thìkhi tiến hành kiểm thử phần mềm cần phải tuân thủ một số quy tắc sau: Quy tắc 1: Một phần quan trọng của một ca kiểm thử là định nghĩa của đầu ra hay kết quả mong muốn. Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chƣơng trình của mình. Quy tắc 3: Nhóm lập trình không nên kiểm thử chƣơng trình của chính họ. Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra. Quy tắc 5: Các ca kiểm thử phải đƣợc viết cho các trạng thái đầu vào không hợp lệ và không mong muốn, cũng nhƣ cho các đầu vào hợp lệ và mong muốn. Quy tắc 6: Khảo sát một chƣơng trình để xem liệu chƣơng trình có thực hiện cái mà nó cần thực hiện chỉ là một phần, phần còn lại là xem liệu chƣơng trình có thực hiện cái mà nó không cần phải thực hiện hay không. Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chƣơng trình thực sự là một chƣơng trình bâng quơ. Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm thấy lỗi. Quy tắc 9: Xác suất tồn tại lỗi trong một đoạn chƣơng trình là tƣơng ứng với số lỗi đã tìm thấy trong đoạn đó. Quy tắc 10: Kiểm thử là một nhiệm vụ cực kỳ sáng tạo và có tính thử thách trítuệ.

Nguyễn Thị Vân

35

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

CHƢƠNG 2: CÁC KỸ THUẬT KIỂM THỬ HỘP ĐEN 2.1 Giới thiệu Kiểm thử hộp đen là một kỹ thuật kiểm thử động nổi bật nhất, quan trọng và cần thiết nhất. Kỹ thuật này thích hợp cho mọi mức độ kiểm thử từ kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, hay kiểm thử độ chấp nhận của ngƣời dùng. Đây là chiến lƣợc kiểm thử theo góc nhìn từ ngoài vào, ngƣời tham gia kiểm thử khi dùng kỹ thuật này không cần có kiến thức về mã nguồn hay giải thuật đƣợc dùng. Có nhiều kỹ thuật kiểm thử hộp đen đã và đang đƣợc phát triển, công nhận mang lại hiệu quả cho việc kiểm thử, chƣơng 2 sẽ trình bày 8 kỹ thuật cơ bản, bao gồm: Kỹ thuật phân lớp tƣơng đƣơng, kỹ thuật phân tích giá trị biên, kỹ thuật dùng bảng quyết định, kỹ thuật kiểm thử n bộ, kỹ thuật dùng lƣợc đồ trạng thái, kỹ thuật dùng use case, kỹ thuật dùng đồ thị nhân quả và kỹ thuật đoán lỗi. Đây là 8 kỹ thuật luôn luôn đƣợc sử dụng trong suốt quá trình kiểm thử phần mềm. 2.2 Quy trình kiểm thử hộp đen tổng quát

Hình 2-1. Quy trình kiểm thử hộp đen tổng quát Testcase (trƣờng hợp kiểm thử) là một tập hợp các giá trị nhập, các điều kiện tiên quyết thực thi, các kết quả mong đợi và các điều kiện kết thúc, đƣợc xây dựng cho mục đích hoặc điều kiện kiểm thử riêng biệt, nhƣ thực hiện một đƣờng dẫn chƣơng trình riêng hoặc để kiểm tra lại có đúng với một yêu cầu cụ thể hay không. (Trích “Hƣớng dẫn phƣơng pháp xác định chi phíkiểm thử chất lƣợng phần mềm” Kèm theo Công văn số 3787 /BTTT-THH ngày 26/12/2014 của Bộ Thông tin và Truyền thông) testcase mô tả một dữ liệu gồm:

Nguyễn Thị Vân

36

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

-

Đầu vào (input)

-

Hành động (action)

-

Sự kiện (event)

- Một kết quả mong đợi (expected result) Để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không. Một testcase có thể có các phần đặc thù khác nhau nhƣ mã testcase, tên testcase, các bƣớc thực hiện, mục tiêu kiểm thử, các điều kiện kiểm thử, các yêu cầu dữ liệu vào và các kết quả mong đợi. Mức chi tiết có thể đƣợc định nghĩa khác nhau dựa vào ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm. Một testcase đƣợc cho là hiệu quả: -

Testcase hiệu quả là testcase mà tìm thấy bug.

-

Tìm đƣợc nhiều bug khó.

-

Chỉ ra những điểm ban đầu mà khi thực hiện test không tìm ra vấn đề.

-

Tuân theo đúng các con số thống kê bug.

-

Theo dõi các lỗi theo các trƣờng hợp đã đƣợc tìm thấy.

-

Đáp ứng đƣợc các kỹ thuật kiểm thử.

Vì chiến lƣợc kiểm thử hộp đen thích hợp cho mọi mức độ kiểm thử nên nhiều ngƣời đã nghiên cứu tìm hiểu và đƣa ra nhiều kỹ thuật kiểm thử khác nhau. Nắm vững các kỹ thuật cơ bản là yêu cầu tiên quyết của một ngƣời thực hiện công việc kiểm thử phần mềm. 2.3. Equivalence Partitioning – Kỹ thuật phân lớp tƣơng đƣơng Tinh thần của kỹ thuật này là cố gắng phân các testcase ra thành nhiều nhóm khác nhau. Các test case trong mỗi nhóm sẽ kích hoạt thành phần phần mềm thực hiện cùng một hành vi. Mỗi nhóm testcase thỏa mãn tiêu chuẩn trên đƣợc gọi là một lớp tƣơng đƣơng. Chỉ cần xác định một testcase đại diện cho nhóm và dùng testcase này để kiểm thử, từ đó giảm đƣợc rất nhiều testcase cần định nghĩa và kiểm thử nhƣng chất lƣợng kiểm thử không bị giảm sút. Điều này dựa vào các kỳ vọng sau: -

Nếu một testcase trong lớp tƣơng đƣơng nào đó gây lỗi thìcác testcase trong lớp này cũng sẽ gây lỗi nhƣ vậy. Nếu một testcase trong lớp tƣơng đƣơng nào đó không gây lỗi thìcác testcase trong lớp này cũng sẽ không gây lỗi.

Nguyễn Thị Vân

37

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Việc xác định các lớp tƣơng đƣơng đầu vào cần: -

Dựa vào các điều kiện vào/ra trong đặc tính kỹ thuật/mô tả kỹ thuật. Định nghĩa các lớp tƣơng đƣơng đại diện các testcase chứa các giá trị đầu vào hợp lệ (valid) và không hợp lệ (invalid). Dựa vào chuẩn đoán (heuristics) và chuyên gia.

Xét bài toán kiểm thử chức năng đăng nhập vào phần mềm Thi đua khen thƣởng với yêu cầu “tên đăng nhập” là ô text chỉ cho phép ngƣời dùng nhập vào số ký tự từ 6-20.

Hình 2-2. Giao diện đăng nhập hệ thống Á p dụng kỹ thuật phân lớp tƣơng đƣơng, dữ liệu cho “tên đăng nhập” sẽ đƣợc phân thành 3 lớp: -

Nhập vào số ký tự thuộc khoảng [6-20] ký tự Nhập vào số ký tự < 6 Nhập vào số ký tự >20 Nhập vào ký tự không phải là chữ và để trống không nhập gì  Có 4 test case ết kế test case kiểm thử cho yêu cầu trên:

Test case 1: Nhập giá trị từ 6 → 20 ký tự => pass. Test case 2: Nhập giá trị < 6 ký tự => hiển thị lỗi “Bạn chỉ đƣợc phép nhập chuỗi từ 6 => 20 ký tự”. Test case 3: Nhập giá trị > 20 ký tự => hiển thị lỗi “Bạn chỉ đƣợc phép nhập chuỗi từ 6 => 20 ký tự”.

Nguyễn Thị Vân

38

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Test case 4: Để trống không nhập gì=> hiển thị lỗi “Chƣa điền tên đăng nhập”. 2. 4 Boundary Value Analysis – Kỹ thuật phân tích giá trị biên Không phải bài toán nào cũng đều có thể áp dụng kỹ thuật phân lớp tƣơng đƣơng, bởi có thể bị thiếu lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tƣơng đƣơng. Kinh nghiệm trong cuộc sống đời thƣờng cũng nhƣ trong lập trình các giải thuật lặp cho chúng ta biết rằng lỗi thƣờng nằm ở biên của một khoảng liên tục nào đó. Kiểm thử giá trị biên là một trong những kỹ thuật đƣợc áp dụng phổ biến nhất trong kiểm thử hộp đen. Chúng ta sẽ coi một chƣơng trình là một hàm toán học với đầu vào của chƣơng trình tƣơng ứng với các tham số của hàm và đầu ra của chƣơng trình là giá trị trả về của hàm. Vìhàm toán học là ánh xạ từ miền xác định của hàm đến miền giá trị của hàm. Chúng ta sẽ tập trung vào các giá trị biên và cạnh biên của hai miền đầu vào và đầu ra này của hàm để xây dựng các ca kiểm thử. Khi chúng ta dùng biên đầu ra tức là chúng ta cho các kết quả mong đợi nằm ở trên biên và cạnh biên đầu ra bao gồm: [biên nhỏ, biên lớn, biên nhỏ -1, biên lớn + 1]. Á p dụng cho bài toán đăng nhập vào phần mềm Thi đua khen thƣởng (Mục 2.3), số ký tự cho kiểm tra “tên đăng nhập” thỏa mãn từ 6 đến 20 ký tự. Ta sẽ có các trƣờng hợp kiểm thử giá trị biên sau: - Tên đăng nhập = 6 ký tự => Pass - Tên đăng nhập = 20 ký tự => Pass - Tên đăng nhập = 5 ký tự => Fail - Tên đăng nhập = 21 ký tự => Fail 2.5. Decision Tables – Kỹ thuật sử dụng bảng quyết định Kỹ thuật kiểm thử phân lớp tƣơng đƣơng và kiểm thử dựa vào phân tích giá trị biên thích hợp cho các hàm có các biến đầu vào không có quan hệ ràng buộc với nhau. Kỹ thuật kiểm thử sử dụng bảng quyết định phù hợp cho các thành phần phần mềm có các hành vi khác nhau dựa trên tính chất của bộ giá trị đầu vào. Kiểm thử sử dụng bảng quyết định là phƣơng pháp chính xác nhất trong các kỹ thuật kiểm thử chức năng. Bảng quyết định là phƣơng pháp hiệu quả để mô tả các sự kiện, hành vi sẽ xảy ra khi một số điều kiện thỏa mãn. Là công cụ rất hữu ích để đặc tả các yêu cầu phần mềm / bảng thiết kế hệ thống phần mềm. Miêu tả các quy tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dƣới dạng dễ đọc và dễ kiểm soát. Cấu trúc của một bảng điều kiện có dạng:

Nguyễn Thị Vân

39

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Hình 2-3. Cấu trúc bảng quyết định -

Trong đó: Condition 1 tới condition n miêu tả điều kiện dữ liệu nhập khác nhau có thể có. Rule mô tả giá trị điều kiện nhập: T (true) / F (false), Y (yes) / N (no)... Action 1 tới action n miêu tả n hoạt động khác nhau mà hệ thống có thể thực hiện phụ thuộc vào tổ hợp điều kiện dữ liệu nhập vào. Mỗi cột miêu tả một luật cụ thể: tổ hợp điều kiện nhập cụ thể và các hoạt động cụ thể cần thực hiện.Các hoạt động cần thực hiện không phụ thuộc vào thứ tự các điều kiện nhập, nó chỉ phụ thuộc vào giá trị các điều kiện nhập.Để xác định các ca kiểm thử dựa vào bảng quyết định, ta dịch các điều kiện thành các đầu vào và các hành động thành các đầu ra. Đôi khi các điều kiện sẽ đƣợc xác định các lớp tƣơng đƣơng của đầu vào và các hành động tƣơng ứng ở các mô- đun xử lý chức năng đang kiểm thử.

Vídụ: Á p dụng kỹ thuật sử dụng bảng quyết định để xây dựng các trƣờng hợp kiểm thử cho bài toán với đề là: Nếu bạn có thẻ đƣờng sắt over 60s thì đƣợc giảm giá 34% trên tất cả các vé bạn mua.Nếu bạn đi cùng trẻ em (dƣới 16 tuổi), thìbạn sẽ đƣợc giảm 50% nến bạn có thẻ family rail card, ngƣợc lại bạn sẽ đƣợc giảm 15%. Bản chỉ đƣợc sử dụng một loại thẻ đƣờng sắt.

Nguyễn Thị Vân

40

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Bảng 2-1. Bảng quyết định bài toán kiểm tra thẻ đƣờng sắt Điều kiện Có thẻ over 60s Đi cùng trẻ em dƣới 16t Có thẻ family rail card Kết quả Giảm 34% Giảm 50% Giảm 15%

1 y

2 y

3 y

4 y

5 n

6 n

7 n

8 n

y

y

n

n

y

y

n

n

y

n

y

n

y

n

y

n

x

x

x

x

x

x

x x

Không đƣợc giảm

Bảng sau khi gộp Điều kiện Có thẻ over 60s Đi cùng trẻ em dƣới 16t Có thẻ family rail card Kết quả Giảm 34% Giảm 50% Giảm 15% Không đƣợc giảm

1 y

2 y

3 y

4

5 n

6 n

y y

y n

n -

n

y y

n -

x

x

x

x

x x

Trên thực tế không phải tổ hợp đầu vào nào cũng là hợp lệ, do đó khi sử dụng bảng quyết định thƣờng ta phải bổ sung thêm một giá trị đặc biệt “-” (không quan tâm) có thể hiểu là luôn sai, không hợp lệ để đánh dấu các điều kiện không thể cùng xảy ra này. Nếu các điều kiện chỉ là T/F hay Y/N ta có 2n cột quy tắc. Mỗi giá trị “-” sẽ đại diện cho 2 cột. Khi tổng số cột ứng với giá trị “-” bằng 2n cho ta biết số quy tắc đã đủ.

Nguyễn Thị Vân

41

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Kết quả kiểm tra số rule bài toán kiểm tra tam giác thể hiện ở dòng Rules.  Từ bảng quyết định, tiến hành xây dựng 6 trƣờng hợp kiểm thử cho bài toán: o TH1: Có thẻ Over 60s và có thẻ Family Rail Card và đi cùng trẻ em => Đƣợc giảm 50% o TH2: Có thẻ Over 60s và không có thẻ Family Raul Card và đi cùng trẻ em => đƣợc giảm 34% o TH3: Có thẻ Over 60s và không đi cùng trẻ em => đƣợc giảm 34% o TH4: Không có thẻ Over 60s và có thẻ Family Raid Card và đi cùng trẻ em =>đƣợc giảm50% o TH5: Không có thẻ Over 60s và không có thẻ Family Raid Card và đi cùng trẻ em =>đƣợc giảm 15% o TH6: Không có thẻ Over 60s và không đi cùng trẻ em => không đƣợc giảm. 2.6 Pairwise Testing – Kỹ thuật kiểm thử các bộ n thần kỳ Trong kiểm thử chất lƣợng phần mềm, giả thuyết thông thƣờng là kiểm tra càng nhiều càng tốt, và thử nghiệm các trạng thái của một biến, cũng nhƣ kiểm tra tất cả các khả năng có thể kết hợp đƣợc của các biến với các trạng thái khác nhau, đảm bảo là tìm thấy tất cả các lỗi. Tuy nhiên, trong thực tế chúng ta sẽ không có đủ thời gian để có thể kiểm tra đƣợc tất mọi trƣờng hợp trên. Hơn nữa khi kiểm thử một phần mềm, không bao giờ chúng ta có thể tìm ra đƣợc tất cả các lỗi của nó, chúng ta chỉ có thể cố gắng tìm ra đƣợc nhiều nhất những lỗi có thể xảy ra trong những điều kiện đƣợc cho phép về thời gian và chi phí. Vídụ chúng ta cần kiểm thử một Form có 10 đối tƣợng và mỗi đối tƣợng đó có thể nhận giá trị trong bộ 10 giá trị khác nhau. Vậy nếu để test toàn diện hết các trƣờng hợp thìchúng ta sẽ cần phải test (1010) = 10 tỷ tổ hợp khác nhau. Trong trƣờng hợp này, việc kiểm tra toàn diện nhƣ vậy là không thể thực hiện đƣợc.Câu hỏi đặt ra là vậy làm thế nào để chúng ta có thể xác nhận rằng sản phẩm của mình đã đƣợc đảm bảo chất lƣợng và sẵn sàng để bàn giao cho khách hàng mà không cần phải thực hiện kiểm tra tất cả mọi tổ hợp test case nhƣ trên? Làm thế nào để đảm bảo đƣợc chất lƣợng của sản phẩm trong điều kiện thời gian và chi phícho sản phẩm bị giới hạn? Xét bài toán kiểm thử có một trang Web có các đối tƣợng cần kiểm tra với các giá trị tƣơng ứng sau: + + + +

List Box: 0;1;2;3;4;5;6;7;8;9 = 10 giá trị. Check Box: Checked hoặc Unchecked = 2 giá trị Radio Button: On hoặc Off = 2 giá trị, Text Box: Bất kỳ giá trị nào từ 1 đến 100= 100 giá trị.

Nguyễn Thị Vân

42

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

=>Nếu kiểm tra đủ các trƣờng hợp thìchúng ta sẽ có 10*2*2*100 = 4000 test cases cần phải tạo và thực hiện test. Thời gian để hoàn thành việc kiểm tra đầy đủ nhƣ vậy là rất lớn. Vậy làm thế nào để chúng ta có thể xác nhận rằng sản phẩm của mình đã đƣợc đảm bảo chất lƣợng và sẵn sàng để bàn giao cho khách hàng mà không cần phải thực hiện kiểm tra tất cả mọi tổ hợp test case nhƣ trên? Làm thế nào để đảm bảo đƣợc chất lƣợng của sản phẩm trong điều kiện thời gian và chi phícho sản phẩm bị giới hạn? Ta có thể đặt ra nhiều chiến lƣợc kiểm thử khác nhau cho bài toán: Không kiểm thử bộ n nào cả (vìáp lực số lƣợng quá lớn). Kiểm thử tất cả bộ n, nhƣ vậy sẽ phải delay dự án quá lâu và làm mất thị trƣờng. Kiểm thử một hay hai bộ n và hi vọng là đủ. Chọn các bộ n đã kiểm thử rồi cho project khác. Chọn các bộ n dễ dàng tạo ra và kiểm thử nhất, mà không để ý đến chất lƣợng của chúng ra sao 6. Tạo tất cả bộ n và chọn một ít bộ n đầu tiên trong danh sách. 7. Tạo tất cả bộ n và chọn 1 ít bộ n theo cơ chế ngẫu nhiên 8. Chọn 1 tập con đủ nhỏ bộ n mà tạo đƣợc điều kỳ diệu là chất lƣợng kiểm thử không bị giảm sút. Bằng cách nào nếu có? 1. 2. 3. 4. 5.

Một giải pháp đó là sử dụng các phƣơng pháp test, cùng với các công cụ hỗ trợ để giúp chúng ta có thể tối ƣu hóa việc kiểm tra chất lƣợng sản phẩm với số lƣợng testcase là ít nhất. Và một trong các phƣơng pháp giảm thiểu số testcase mà vẫn đảm bảo đƣợc chất lƣợng của sản phẩm là sử dụng Pairwise testing. Pairwise testing (hay còn gọi là All-pairs testing) là một phƣơng pháp test kết hợp mỗi cặp 2 tham số đầu vào của 1 bộ các đối tƣợng có liên quan đến nhau, tạo ra bộ giá trị kiểm thử: Ta sẽ kiểm tra tất cả các khả năng có thể kết hợp các giá trị của cặp 2 tham số đó với nhau. Thực hiện kiểm tra theo cặp nhƣ vậy sẽ giúp làm giảm thời gian hơn rất nhiều so với việc phải kiểm tra đầy đủ mọi khả năng kết hợp của tất cả các giá trị của bộ nhiều các thông số với nhau. Số testcase phát triển từ kỹ thuật này đƣợc tính bằng tích của số lƣợng giá trị lớn nhất của các biến số và số lƣợng vùng giá trị lớn thứ 2 trong số các biến.Tiến hành phân tích và xây dựng test case cho bài toán trên qua các bƣớc: Bước 1: Sử dụng các kỹ thuật kiểm thử thông thƣờng để chia các vùng cần kiểm tra cho từng biến: 1. List Box: 0,1,2,3,4,5,6,7,8,9 - chia thành 2 vùng kiểm tra: "0" và các giá trị khác ("others") 2. Check Box: Checked hoặc Unchecked - giữ nguyên 2 giá trị Nguyễn Thị Vân

43

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

3. Radio Button: ON hoặc OFF - giữ nguyên 2 giá trị 4. Text Box: Bất kỳ value nào từ 1 đến 100 - kiểm tra 3 vùng giá trị: số nguyên nằm trong khoảng 1 đến 100, số nguyên ngoài khoảng, ký tự không phải dạng số nguyên (Valid Integer, Invalid Integer, Alpha-Special Character) Nhƣ vậy số test case giảm xuống còn 2*2*2*3 = 24 test case. Bước 2: Ứng dụng kỹ thuật Pairwise testing để làm giảm sự kết hợp các vùng kiểm tra với nhau theo cách sau: Xác định số testcase = 3*2 = 6 testcase và thực hiện: 1) Sắp xếp các biến theo thứ tự giảm dần số lƣợng vùng giá trị: biến có nhiều vùng giá trị nhất sắp xếp đầu tiên. Biến có số lƣợng vùng giá trị ít nhất để ở cuối cùng. =>tạo thành 1 bảng có các cột tƣơng ứng với các biến. Text Box List Box Check Box Radio Button

2) Điền các vùng giá trị tƣơng ứng vào bảng lần lƣợt theo các cột. Bắt đầu từ cột thứ 2: "List Box". Cột này có thể lấy 2 giá trị là "0" hoặc "others". Text Box List Box Check Box Radio Button 0 others 0 others 0 others 3) Điền vùng giá trị cho cột tiếp theo: "Check box": có thể nhận đƣợc 2 giá trị: "check" và "uncheck" đồng thời kiểm tra để đảm bảo rằng chúng ta đã cover đƣợc hết các trƣờng hợp kết hợp các vùng giá trị của "List box" và "Check box". Text Box List Box Check Box Radio Button

Nguyễn Thị Vân

0

check

others

uncheck

0

uncheck

others

check

44

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

0

check

others

uncheck

4) Tiếp tục điền giá trị cho cột "Radio button" theo cách tƣơng tự nhƣ trên. "Radio button" có thể lấy 2 giá trị: "on" hoặc "off". Text Box List Box Check Box Radio Button 0

check

on

others

uncheck

off

0

uncheck

off

others

check

on

0

check

off

others

uncheck

on

5) Kiểm tra nhằm đảm bảo rằng tất cả các cặp giá trị đều đƣợc cover nhƣ trong bảng kết quả sau: Text Box List Box Check Box Radio Button Valid int

0

check

on

Valid int

others

uncheck

off

Invalid int

0

uncheck

off

Invalid int

others

check

on

AlphaSpecialCharacter 0

check

off

AlphaSpecialCharacter others

uncheck

on

Các trƣờng hợp kiểm thử: Bảng 2-2. Bảng các trƣờng hợp kiểm thử sử dụng kỹ thuật pairwise testing

Text Box

List Box

Check Box

Radio Button

1

0

check

on

50

1

uncheck

off

-1

0

uncheck

off

1,5

5

check

on

Kytu

0

check

off

!@#$%^&*/\

9

uncheck

on

Nhận xét: Kỹ thuật Pairwise Testing giúp giảm đi một lƣợng khá lớn các test case mà vẫn đảm bảo hiệu quả của các testcase tạo ra. Tuy nhiên với một lƣợng lớn số lƣợng các điều kiện cần kiểm thử cộng với mỗi điều kiện lại có một số lƣợng lớn các giá trị cần kiểm thử thì việc thực hiện thủ công cũng gây tốn thời gian và rất có Nguyễn Thị Vân

45

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

thể xảy ra trƣờng hợp bỏ sót hoặc trùng test case. Vấn đề đặt ra là tìm kiếm một công cụ tự động sinh ra các ca kiểm thử đầy đủ và tối ƣu cho kỹ thuật này. PICTMASTER – Pairwise Independent Combinatorial Testing Tool (© IWATSU System & Software Co., Ltd.) là một công cụ tạo test case hàng dọc tự động, giúp cho việc tạo ra bộ test case với số lƣợng hợp lý mà vẫn không bị sót trƣờng hợp test. PictMaster là một công cụ viết bằng excel macro, yêu cầu máy tính đã cài đặt môi trƣờng pict33.msi.

Hình 2-4 .Giao diện PictMaster Tool Trong đó:

-

Parameters: Thông tin về các parameters sẽ kiểm tra

-

Value hierarchy: Thông tin về các giá trị của parameters

-

Execute: Chạy tạo test case tự động từ các parameter và value đã nhập vào

-

Edit: Thực hiện chỉnh sửa format của test case sau khi đã tạo tự động

-

Settings: Thiết lập môi trƣờng để tạo test case

Sau khi nhập đầy đủ thông tin về các parameters với giá trị tƣơng ứng, chọn Build, chƣơng trình sẽ xử lý và tự động cho ra một sheet mới chứa các test case kết quả.

Nguyễn Thị Vân

46

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa Bảng 2-3 .Bảng các trƣờng hợp kiểm thử sử dụng PictMaster Tool

2.7. State Transition/Diagram Testing - Kỹ thuật biểu đồ chuyển trạng thái Biểu đồ trạng thái là một loại sơ đồ đƣợc sử dụng trong khoa học máy tính và các lĩnh vực liên quan để mô tả hành vi của hệ thống. Biểu đồ trạng thái đòi hỏi hệ thống đƣợc mô tả bao gồm một hữu hạn các trạng thái. Cũng giống nhƣ bảng quyết định, lƣợc đồ chuyển trạng thái là công cụ hữu ích để đặc tả các yêu cầu phần mềm hoặc để đặc tả bảng thiết kế hệ thống phần mềm. Thay vì miêu tả quy tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dƣới dạng dễ đọc và dễ kiểm soát nhƣ bảng quyết định, lƣợc đồ chuyển trạng thái ghi nhận các sự kiện xảy ra, rồi đƣợc hệ thống xử lý cũng nhƣ những đáp ứng của hệ thống. Khi hệ thống phải nhớ trạng thái trƣớc đó của mình, hay phải biết trình tự các hoạt động nào là hợp lệ, trình tự các hoạt động nào là không hợp lệ thìáp dụng kỹ thuật dùng lƣợc đồ chuyển trạng thái là rất thích hợp. Đặc điểm của lƣợc đồ trạng thái: -

Là sơ đồ mô hình hóa hành vi của hệ thống chứ không phải là sơ đồ mô tả các câu lệnh trong code. Cho phép các Tester xem sự phát triển phần mềm trong một số điều kiện nhập đầu vào và các sự kiện kích hoạt thay đổi trạng thái. Bổ sung các ca kiểm thử để phát hiện ra lỗi mà không thể phát hiện đƣợc bằng điều kiện input, output bởi các phƣơng pháp khác.

2.8. Use case Testing – Kỹ thuật sử dụng use case Trong quy trình phát triển phần mềm phải thực hiện nhiều workflows khác nhau: nắm bắt yêu cầu phần mềm, phân tích từng yêu cầu, thiết kế chi tiết để giải quyết từng yêu cầu, hiện thực từng phần bảng thiết kế, kiểm thử kết quả.

Nguyễn Thị Vân

47

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Về nguyên tắc, khi kiểm thử một thành phần phần mềm, ta có thể vận dụng bất kỳ thông tin nào trong bất kỳ mô hình nào. Kỹ thuật kiểm thử dùng thông tin trong use case là kỹ thuật định nghĩa các test case dựa vào các kịch bản thực hiện usecase. o Use case là gì? o Use case là một danh sách các bƣớc để giúp đạt đƣợc một mục đích nào đó trong hệ thống. o Các bƣớc này xác định sự tƣơng tác giữa actor với hệ thống. o Use case “nắm bắt” đƣợc các yêu cầu về chức năng của hệ thống. o Use case cũng định nghĩa các hệ quả gây ra bởi các lỗi trong suốt quá trình hệ thống hoạt động. o Use case xác định các kịch bản chính và các mong đợi của kịch bản đó. Mô hình use case miêu tả hệ thống phần mềm theo góc nhìn bên ngoài: nó cung cấp những chức năng nào cho những user nào. Thành phần thiết yếu nhất của mô hình use case là các lƣợc đồ use case. Mỗi lƣợc đồ use case thể hiện một bộ phận nhỏ của phần mềm bao gồm nhiều chức năng và mỗi chức năng tƣơng tác với actor nào. Trong cuốn “Writing Effect Use Cases” Alistair Cockburn đã đề nghị khuôn mẫu chi tiết để đặc tả use case nhƣ sau: Bảng 2-4 .Khuôn mẫu đặc tả use case theo Alistair Cockburn Main Succcess Scenario Step Action A (Actor): S (System):

1

2 … Extensions

Các kịch bản phát sinh từ các lỗi khi có những yêu cầu biến thể khác.

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

Nguyễn Thị Vân

48

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Đồ thị nhân - quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần phần mềm. Mỗi nguyên nhân đƣợc biểu diễn nhƣ một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả đƣợc biểu diễn nhƣ là một biểu thức Bool biểu diễn một kết một kết quả tƣơng ứng cho những thành phần vừa thực hiện. Dƣới đây là bảng các ký hiệu đƣợc đơn giản hóa sử dụng trong đồ thị nhân- quả: Bảng 2-5. Bảng các ký hiệu sử dụng trong đồ thị nguyên nhân – hệ quả STT Ký hiệu Ý Giải thích nghĩ Identity(Tƣơng đƣơng)a 1 Nếu a đúng thì b đúng

2

Not

Nếu a sai thì b đúng

3

And

Nếu a đúng và b đúng thì c đúng

4

Or

Nếu a đúng hoặc b đúng thì c đúng

5

Exclusive (Loại Nếu a đúng thì b sai hoặc nếu a sai thì b trừ) đúng

6

Inclusive (Bao a hoặc b hoặc c đúng; cả a, b, c không hàm) đồng thời sai

7

Only one (Duy nhất) Chỉ a hoặc b đúng

Nguyễn Thị Vân

49

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Requires (Yêu cầu)

8

Mask (Mặt nạ)

9

Nếu a đúng thì b phải đúng

Nếu a đúng thì b phải sai

Quy trình định nghĩa các testcase dùng kỹ thuật đồ thị nhân - quả gồm các bƣớc sau: o Bƣớc 1: Đặc tả của phần mềm đƣợc chia nhỏ ra nhiều phần để có thể làm việc dễ dàng (nếu không, đồ thị nhân - quả sẽ rất phức tạp). o Bƣớc 2: Nhận dạng các nguyên nhân và hệ quả của phần nhỏ đang xử lý. o Bƣớc 3: Tìm mối quan hệ giữa các nguyên nhân và hệ quả, mỗi mối quan hệ đƣợc vẽ thành 1 đƣờng nối. o Bƣớc 4: Xác định các ràng buộc giữa các nguyên nhân và chú thích vào đồ thị. o Bƣớc 5: Chuyển đồ thị nhân quả về bảng quyết định. o Bƣớc 6: Từ bảng quyết định chuyển thành các testcase. Ví dụ: Bài toán tính thuế thu nhập dựa vào mô tả sau: Ngƣời vô gia cƣ nộp 4% thuế thu nhập. Vídụ: Bài toán tính thuế thu nhập dựa vào mô tả sau: - Ngƣời vô gia cƣ nộp 4% thuế thu nhập. -

Ngƣời có nhà ở nộp thuế theo quy định sau:

+ Thu nhập ≤ 5.000.000 nộp 4% thuế + Thu nhập > 5.000.000 nộp 6% thuế Xác định đồ thị nhân - quả cho bài toán:

Nguyễn Thị Vân

50

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Hình 2-5 Đồ thị nhân – quả cho bài toán tính thuế thu nhập.  Từ đồ thị nhân quả xây dựng bảng quyết định: Bảng 2-6. Bảng quyết định cho đồ thị nhân – quả bài toán tính thuế thu nhập. Trƣờng hợp Nguyên nhân 1 2 3 4 Ngƣời có nhà ở N Y Y Có tổng thu nhập ≤ 5.000.000 Y N Y Có tổng thu nhập > 5.000.000 N Y Hệ quả

-

-

-

-

Nộp thuế 4%

X

X

-

X

Nộp thuế 6%

-

-

X

-

 Từ bảng quyết định chuyển thành các testcase: Bảng 2-6. Bảng test case sử dụng kỹ thuật dùng đồ thị nhân – quả ID 1 2

3

4

Tên Testcase Quy trình thực hiện Kết quả mong đợi Kiểm tra mức thuế cho Chọn đối tƣợng: Thông báo mức thuế ngƣời vô gia cƣ Ngƣời vô gia cƣ phải nộp là 4% Kiểm tra mức thuế cho Chọn đối tƣợng ngƣời có nhà ở, thu Ngƣời có nhà ở, chọn Thông báo mức thuế nhập ≤ 5.000.000 thu nhập ≤ 5.000.000 phải nộp là 4% Kiểm tra mức thuế cho ngƣời có nhà ở, thu nhập > 5.000.000 Kiểm tra mức thuế cho ngƣời có thu nhập ≤ 5.000.000

Nguyễn Thị Vân

Chọn đối tƣợng Ngƣời có nhà ở, chọn thu nhập > 5.000.000 Chọn đối tƣợng có mức thu nhập ≤ 5.000.000

51

Điều kiện tiền đề -

Thông báo mức thuế phải nộp là 6%

-

Thông báo mức thuế phải nộp là 4%

-

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Nhận xét về kỹ thuật: -

-

Đồ thị nhân - quả yêu cầu chuyển một đặc tả thành một mạng logic Boolean, nó cung cấp một triển vọng và sự hiểu biết sâu về đặc tả. Trên thực tế, sự phát triển của một đồ thị nhân - quả là cách hay để khám phá sự mơ hồ và chƣa đầy đủ trong các đặc tả. Mặc dùviệc vẽ đồ thị nhân - quả tạo ra tập các ca kiểm thử hữu dụng, nhƣng thông thƣờng nó không tạo ra đƣợc tất cả các ca kiểm thử hữu dụng, ngoài ra đồ thị nhân - quả không khảo sát thỏa đáng các điều kiện giới hạn. Dĩ nhiên ngƣời kiểm thử có thể cố gắng bao phủ các điều kiện giới hạn trong suốt quá trình. Tuy nhiên, vấn đề này làm cho đồ thị rất phứ tạp và dẫn đến số lƣợng lớn các ca kiểm thử.

2.10. Kỹ thuật đoán lỗi Tester đƣợc đƣa cho một chƣơng trình đặc biệt, họ phỏng đoán cả bằng trực giác và kinh nghiệm, các loại lỗi có thể và sau đó viết các trƣờng hợp kiểm thử để đƣa ra các lỗi. Thật khó để đƣa ra một quy trình cho kỹ thuật đoán lỗi vìnó là một quy trình có tính trực giác cao và không thể dự đoán trƣớc. Ý tƣởng cơ bản là liệt kê một danh sách các lỗi có thể hay các trƣờng hợp để dễ xảy ra lỗi và sau đó viết các trƣờng hợp kiểm thử dựa trên danh sách đó. Một ý tƣởng khác để xác định các ca kiểm thử có liên đới với các giả định mà lập trình viên có thể đã thực hiện khi đọc đặc tả (tức là những thứ bị bỏ sót khỏi đặc tả hoặc là do tình cờ, hoặc là vì ngƣời viết có cảm giác những đặc tả đó là rõ ràng). Nói cách khác, tester liệt kê các trƣờng hợp đặc biệt mà có thể đã bị bỏ xót khi chƣơng trình đƣợc thiết kế. Vídụ: Trong quá trình làm việc của mình, tester gặp nhiều quy trình xử lý công việc nên khi gặp một dự án mới, một phần mềm mới, tester sẽ biết đƣợc dạng phần mềm hay loại màn hình này thì thƣờng gặp những loại lỗi gì, hoặc sau khi thực hiện một vài thao tác thìkết quả phải xảy ra nhƣ thế nào… Đối với màn hình tìm kiếm:  Thƣờng xảy ra với lỗi tìm kiếm cả những bản ghi đã bị xóa. Vìvậy khi thiết kế testcase và test màn hình tìm kiếm thìnên thêm vào testcase này - nếu những bản ghi này đƣợc hiển thị thìmàn hình sai.  Danh sách sau khi tìm kiếm phân trang bị lỗi: Nhiều khi lập trình viên quên không xử lý phân trang thìkhi tìm kiếm đƣợc nhiều hơn số bản ghi chứa trong một trang thìbị lỗi hoặc hiển thị tất cả trên một trang. Đối với màn hình đăng nhập: Nguyễn Thị Vân

52

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Lỗi đôi khi lập trình viên khi code gán user là “admin” và password rỗng hoặc để bằng “123”.  Lỗi không xử lý action enter (Không login đƣợc khi nhấn enter mà phải click button login.  Đối với những website có tính bảo mật cao, khi user đang đăng nhập trên một trình duyệt thìkhi copy link trình duyệt này sang trình duyệt khác không thể vào đƣợc nếu chƣa đăng nhập. Trƣờng hợp thực hiện testcase này mà paste link đăng nhập trình duyệt khác thành công tức là lỗi. Đối với màn hình Thêm/Sửa/Xóa:  Ở loại màn hình này thƣờng xảy ra lỗi là khi thêm mới vào lần thứ hai trở đi thìbáo lỗi exception. Lý do là do cách xử lý ID khi thêm mới, thêm mới lần hai bị trùng với ID với lần trƣớc nên Database Server không cho insert thêm dẫn đến lỗi – nguyên tắc là sau mỗi lần thêm mới thìload lại dữ liệu).  Nếu chƣơng trình có yêu cầu xử lý deadlock thì thƣờng xảy ra lỗi khi hai ngƣời ngồi trên hai máy tính khác nhau cùng sửa trên 1 bàn ghi cùng lúc. 2.11. Kết luận Chƣơng 2 đã nêu ra 8 kỹ thuật thiết kế testcase kiểm thử cơ bản và cũng là quan trọng, hay sử dụng nhất trong các bài toán kiểm thử áp dụng kỹ thuật kiểm thử hộp đen. Ứng với mỗi kỹ thuật là một bài toán cụ thể để demo quy trình thực hiện kỹ thuật kiểm thử tƣơng ứng. Mỗi một yêu cầu cụ thể sẽ áp dụng một kỹ thuật hoặc kết hợp nhiều kỹ thuật để mang lại hiệu quả nhất, bao quát tối ƣu các lỗi của sản phẩm kiểm thử. Chƣơng 3 của đồ án sẽ tiến hành phân tích, lựa chọn áp dụng kỹ thuật kiểm thử hộp đen tƣơng ứng để kiểm website phần mềm “Thi đua khen thƣởng” tƣơng ứng.

Nguyễn Thị Vân

53

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

CHƢƠNG 3: TRIỂN KHAI KIỂM THỬ WEBSITE THI ĐUA KHEN THƢỞNG 3.1. Kiểm thử ứng dụng Website Kiểm thử ứng dụng Website là một trƣờng hợp trong kiểm thử phần mềm, ở chƣơng này sẽ đi sâu nghiên cứu loại ứng dụng kiểm thử Website về khái niệm, các loại kiểm thử ứng dụng Website, chất lƣợng của một ứng dụng web cần đạt đƣợc, các công việc khi kiểm thử một ứng dụng website và sẽ giới thiệu một số công cụ hỗ trợ kiểm thử cho ứng dụng website. Bởi có rất nhiều chức năng quan trọng cho ngƣời sử dụng ứng dụng nhƣ: tính hiệu năng, tính dễ sử dụng, độ tin cậy và tính bảo mật cần đƣợc xem xét. Những yêu cầu và mong đợi của ngƣời sử dụng, những vấn đề về nền tảng và cấu hình, mô hình nghiệp vụ, sự phát triển và chi phí cho việc kiểm thử là những vấn đề thƣờng hay gặp phải và thay đổi liên tục đổi xuyên suốt chu trình của một ứng dụng Website. Ngƣời sử dụng không chỉ mong đợi chƣơng trình của họ sẽ vận hành một cách ổn định, chính xác mà họ còn yêu cầu một số chức năng nào đó phải luôn sẵn sàng trên 24 giờ trong một ngày và bảy ngày trong tuần. Hơn nữa, ngƣời sử dụng còn mong đợi ở chƣơng trình những ƣu điểm sau: tính dễ sử dụng, độ tin cậy, tốc độ, tƣơng thích với các hệ thống khác nhau và tƣơng thích với các phiên bản trong tƣơng lai. Còn với một ứng dụng Website, thìnhững yêu cầu về chất lƣợng bao gồm: Yêu cầu về chức năng: sự hiện diện của các chức năng đáp ứng những yêu cầu đƣợc xác định. Các yêu cầu cần có nữa là tính phù hợp, chính xác, khả năng tƣơng tác, tuân thủ và bảo mật. - Yêu cầu về độ tin cậy: khả năng của một ứng dung để duy trìsự hiệu quả của nó trong một điều kiện cụ thể và trong một khoảng thời gian xác định. - Yêu cầu về khả năng sử dụng: Tính dễ sử dụng và hiệu quả của một ứng dụng. Vấn đề này có thể đƣợc thẩm định bởi một nhóm ngƣời dùng giả định. - Yêu cầu về hiệu quả: Tỷ lệ giữa mức độ hiệu quả của một ứng dụng và các tài nguyên mà nó sử dụng trong các điều kiện cụ thể. Các yêu cầu về chất lƣợng đóng một vai trò thiết yếu khi thử nghiệm các ứng dụng Website. Mặc dù nhìn chung thì chúng tƣơng tự nhƣ những yêu cầu về chất lƣợng cho các hệ thống phần mềm truyền thống. Tuy nhiên, chúng có thể có mức độ đòi hỏi cao hơn về chiều sâu. -

Do ý nghĩa quan trọng của các đặc điểm về chất lƣợng và sự khác biệt ở cách mà chúng đƣợc kiểm thử, nhiều phƣơng pháp để kiểm thử một ứng dụng Website tập trung vào một vài đặc điểm.

Nguyễn Thị Vân

54

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

3.2. Kiểm thử website thi đua khen thƣởng tỉnh thanh hóa 3.2.1 Giới thiệu bài toán Là sản phẩm của Đề tài KHCN cấp tỉnh của Ban Thi đua Khen thƣởng tỉnh Thanh Hóa. Hệ thống giúp Ban Thi đua Khen thƣởng tỉnh, các đơn vị cơ sở Quản lý, lƣu trữ, khai thác các hồ sơ đề nghị khen thƣởng từ đó tổ chức quản lý theo dõi thông tin hồ sơ cá nhân, tổ chức đƣợc trình khen thƣởng dựa trên các thành tích đã đạt đƣợc. Nhờ việc lƣu trữ lại tất cả các thông tin dữ liệu trong quá trình làm việc nên phần mềm có thể thống kê tổng hợp kết quả khen thƣởng theo nhiều mẫu biểu khác nhau để phục vụ cho công tác quản lý và các mục đích nghiên cứu.

Hình 3-1 Giao diện phần mềm thi đua khen thƣởng  Nghiệp vụ Quản lý Thi đua khen thƣởng tỉnh thanh hóa: + Quản trị hệ thống; Quản lý thông tin cán bộ (thông tin chung; quá trình công tác; Quá trình khen thƣởng; kỷ luật…). + Quản lý thi đua (quản lý phong trào thi đua, đăng ký thi đua, tổ chức thực hiện thi đua, đánh giá, xét tặng thi đua…); Quản lý khen thƣởng (quản lý khen thƣởng thƣờng xuyên, quản lý loại hình khen thƣởng ngoài ngành, cập nhật thông tin lịch sử khen thƣởng, tổng kết khen thƣởng…). + Danh sách đề nghị xét duyệt. + Danh sách đƣợc khen thƣởng, lịch sử khen thƣởng…). + Đồng thời, trợ giúp các hoạt động nghiệp vụ thi đua, khen thƣởng gồm: Công tác thi đua (tổ chức, phát động, đăng ký thi đua, tổ chức thực hiện phong trào thi đua), tổ chức công tác kiểm tra, giám sát; tổng hợp, đánh giá kết quả phong trào thi đua (tổng kết, chấm điểm, bình xét thi đua). Nguyễn Thị Vân

55

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Công tác khen thƣởng: hồ sơ xét thƣởng (báo cáo tổng kết thi đua, điểm thi đua, đề nghị khen thƣởng); Báo cáo thành tích khen thƣởng; Hỗ trợ quy trình thẩm. 3.2.2. Biểu đồ mô tả các chức năng sẽ đƣợc thực hiện kiểm thử hộp đen Từ việc phân tích tài liệu mô tả yêu cầu mức cao và tài liệu đặc tả chức năng, áp dụng các kỹ thuật kiểm thử hộp đen đã nghiên cứu tại Chƣơng 2 tiến hành xây dựng bộ các testcase cho quản lý đăng kí thi đua.  Xác định quy trình kiểm thử phần mềm

Hình 3-2a Quy trình kiểm thử phần mềm thi đua khen thƣởng  Mô hình quản lý testcase

Hình 3-2b. Biểu đồ quản lý testcase mo-đun phần mềm thi đua khen thƣởng Nguyễn Thị Vân

56

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

3.2.3 Thiết kế định hƣớng trƣờng hơp kiểm thử Bảng 3-1. Bảng thiết kế trƣờng hợp kiểm thử

STT I

PHƢƠNG THỨC TEST TEST CHỨC NĂNG

DANH MỤC

PHƢƠNG ÁN TEST

Tạo tài khoản ngƣời dùng, đơn vị.

I.1

Chức năng của tài khoản

-

-

Sửa tài khoản ngƣời dùng, đơn vị.

-

Nguyễn Thị Vân

57

Kiểm thử thông báo khi không nhập các trƣờng yêu cầu bắt buộc. Kiểm thử thông báo khi nhập đúng, sai định dạng của trƣờng nhập. Kiểm thử độ dài tối đa của từng trƣờng cho phép nhập Kiểm thử tình trạng của các nút bấm (Nhấp nhiều hơn 1 lần khi cập nhật) Kiểm tra nội dung các trƣờng theo thông tin hiện tại đang có (tên địa danh, danh mục nghề nghiệp .... các thông tin có thể thay đổi theo thời gian). Kiểm thử trang đƣợc chuyển hƣớng khi thêm thành công tài khoản. Kiểm thử thông báo khi thêm tài khoản thất bại Xác định các trƣờng đƣợc sửa, các trƣờng không đƣợc sửa Kiểm thử thông báo khi chọn chỉnh sửa trƣờng không đƣợc chỉnh sửa. Kiểm thử thông báo khi chọn chỉnh sửa trƣờng cho phép chỉnh sửa. Kiểm thử hiển thị khi chỉnh sửa thành công một trƣờng dữ liệu Kiểm thử hiển thị khi làm mới trang nhƣng chỉnh sửa chƣa đƣợc cập nhật.

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

-

-

Xóa tài khoản ngƣời dùng, đơn vị

-

Đăng nhập Đăng xuất

-

-

Nguyễn Thị Vân

58

Kiểm thử thƣ viện của trang "SỬA TÀI KHOẢN NGƢỜI DÙNG" và trang "TẠO TÀI KHOẢN NGƢỜI DÙNG" có đồng nhất. Kiểm thử hiển thị của danh sách tài khoản khi chọn tài khoản bất kỳ để chỉnh sửa Kiểm thử thông báo khi xóa ngƣời dùng đang có hoạt động. Xác định xóa ngƣời dùng là khóa vĩnh viễn hoặc xóa tạm thời. Trang đƣợc chuyển tiếp khi xóa ngƣời dùng thành công. Trang đƣợc chuyển tiếp khi xóa ngƣời dùng không thành công Nhập phạm vi 6-12 kí tự(user name) Phần mềm cho phép đăng nhập nhiều tài khoản cùng 1 thiết bị. Đăng nhập có yêu cầu token Cơ chế kiểm tra khi đăng nhập sai nhiều lần (5-10-15 lần). Kiểm thử thông báo khi đăng nhập nhiều thiết bị cùng 1 tài khoản. Kiểm thử thao tác của tài khoản từ các thiết bị khác nhau. Kiểm thử user, pass có khoảng trống trƣớc, sau, giữa. Cho phép đăng xuất 1 lần từ tất cả các thiết bị. Thời gian đăng xuất khỏi phần mềm. Tắt ứng dụng nhƣng chƣa đăng xuất, khi mở lại có cho phép tiếp tục phiên đăng nhập Chuyển hƣớng trang web khi đăng xuất. Kiểm thử sử dụng nút BACKLớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

FORWARD của trình duyệt sau khi đăng xuất Lấy lại mật khẩu

-

Thay đổi mật khẩu

-

I.2

BTĐKT

Đăng kí

-

Nguyễn Thị Vân

59

Kiểm thử lấy lại mật khẩu nhiều lần Kiểm thử thông báo khi nhập sai email Kiểm thử thông báo từ 1 thiết bị gửi nhiều lần lấy lại mật khẩu Kiểm thử thông tin phản hồi từ mail ->nhập mã lấy lại mật khẩu Đổi mật khẩu của từng tài khoản theo ý muốn (thay đổi mới so với mật khẩu mặc định). Kiểm thử khi không nhập xác nhận pass mới. Kiểm thử khi pass mới và pass cũ trùng nhau. Kiểm thử thay đổi mật khẩu thành công nhƣng đăng nhập pass cũ. Kiêm thử khi nhập pass mới quá ngắn. Kiểm thử đồng bộ kí tự giữa đăng nhập và thay đổi mật khẩu. Kiểm thử thông báo khi đang đăng nhập và tài khoản đƣợc đổi mật khẩu ở thiết bị khác Kiểm thử khi không điền tên hoặc một số trƣờng bắt buộc. Kiểm thử đăng kí khi không trong đợt đăng kí. Kiểm thử đăng kí trong đợt đăng kí. Kiểm thử đăng kí khi chƣa đăng kí lần nào. Kiểm thử đăng kí khi đã đăng kí

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Quản lý đợt đăng kí thi đua.

-

Kiểm thử hồ sơ lƣu -

III.3

Interface

Nguyễn Thị Vân

a. Menus, size, position, state, màu sắc, font b. Zoom to nhỏ, Sai lỗi chính tả, ảnh, mẫu in c. Textbox, option (radio button), check boxes, command button, combo boxes list boxes, Label, Icon

60

-

-

Kiểm thử Thêm mới đợt thi đua (thành công, không thành công). Kiêm thử Sửa đợt thi đua. Kiểm thử Không nhập các trƣờng bắt buộc khi thêm mới đợt thi đua Kiểm thử Tự chấm điểm đợt thi đua Kiểm thử chức năng tạo tên khi chấm điểm Kiểm thử Xóa đợt thi đua. Kiểm thử Tìm kiếm đợt thi đua Kiểm thử tìm kiếm hồ sơ Kiểm thử Thêm mới hồ sơ với đối tƣợng chƣa biên chế. Kiểm thử Thêm mới, sửa, xóa Danh hiệu đối tƣợng chƣa biên chế. Kiểm thử Thêm, sửa, xóa Quyết đinh. Kiểm thử khi không điền đủ thông tin. Màu sắc hài hoà hợp lý, font: Time New Roman. Trên các list ở hình phải sort đƣợc theo các cột thông tin: Thời gian Order mới nhất. Size: 13 vừa tầm mắt. Đảm bảo có thể zoom to nhỏ. Kiểm thử mắc lỗi chính tả. Ảnh yêu cầu nhìn rõ 2D, 3D. Mẫu in hiển thị chính xác thông tin, không lặp từ sai lỗi chính tả. Ngôn từ sử dụng tế nhị. Kiểm thử phân trang (khi list quá dài ) Kiểm thử hiển thị thông tin đúng với từng chức năng

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

3.3 Thiết kế bộ các testcase 3.3.1 Testcase kiểm thử chức năng đăng nhập, thay đổi mật khẩu, đăng xuất.

Hình 3-3. Màn hình đăng nhập Thi đua khen thƣởng Tài khoản đƣợc phép đăng nhập vào hệ thống là tài khoản Ban thi đua khen thƣởng đã đƣợc tạo thành công tại hệ thống phía trung tâm. User không nhập sai tên đăng nhập và mật khẩu, thay đổi mật khẩu phải đúng với thông tin tài khoản. Mỗi tài khoản đăng nhập thỏa mãn: Tên đăng nhập: Từ 6 đến 12 ký tự không chứa ký tự trắng bao gồm các ký tự chữ và số. - Mật khẩu: Từ 6 đến 12 ký tự. Á p dụng kỹ thuật giá trị biên cho các trƣờng hợp của tên đăng nhập và mật khẩu: -

-

Đăng nhập thành công: Nhập đúng [Tên đăng nhập] và [Mật khẩu].

-

Đăng nhập không thành công: Nhập sai thông tin một trong hai trƣờng [Tên đăng nhập] / [Mật khẩu] hoặc không nhập thông tin đăng nhập, nhập thông tin đăng nhập nhƣng không đăng nhập. Tên đăng nhập và mật khẩu sai. Nhập sai mật khẩu cũ và không nhập xác nhận mật khẩu hoặc nhập xác nhận mật khẩu không đúng. Hình thành bộ testcase cho chức năng đăng nhập hệ thống với tài khoản đăng nhập chuẩn là btdkt/123456:

-

Nguyễn Thị Vân

61

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Bảng 3-2 Testcase Đăng nhập – đăng xuất – thay đổi mật khẩu phần mềm thi đua khen thƣởng

ID

Test Case Description

Test Case Procedure

Expected Output

Inter-test case Dependen ce

Open form

User have account

Test Function Van_Account Van_login_01

Van_login_02

Van_login_03

Van_login_05

Check Login _logout_ successfully Check login 1. Start successfully Check form have enough component 1. Start up (Texbox,submit ...) 1. Start 2.Input username Check login 3.Input password 4.Click login 1. Start 2.Input space last Check space username last username 3.Input password 4.Click login

Display true

login successful

User have account

login successfull

User have account

Van_login_06

Check "Forget pass"

Start 2.Input phone 3.Input Mã hóa

Receive new pass

User have account

Van_logout_0 1

Check logout

1. start 2.click logout

login successfull

User have login

Check Login_logout unsuccessfully

Nguyễn Thị Vân

62

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Van_login_07

Van_login_08

Van_login_09

Van_login_10

Van_login_11

Van_login_12

Nguyễn Thị Vân

Check input space before,after password

1. Start 2.Input html username 3.Input space before,after password 4.Click login

Check wrong user name

1. Start 2.Input wrong username 3.Input password 4.Click login

Check wrong password

1. Start 2.Input username 3.Input wrong password 4.Click login

1. Start 2.Not Input Check not input username anything 3.Not Input password 4.Click login 1. Start Check input 2.Input username password 12 character 4.Click login 1. Start 2.Input username 3.Input password =12 character 4.Click login

Check password have space at mid\

User have account

Display message"pa ssword 6-12 character"

User have account

1. Display error message "Input wrong password "

User have account

Van_change password successful

Van_Change_ pass_01

Start

Van_Change_ pass_02

Check change oldpass = newpass

Nguyễn Thị Vân

1. Start 2.Input username 3.Input password have space 4.Click login

Display message"pa ssword 6-12 character"

64

1. Click [Thay đổi mật khẩu ]button 2.Input old pass 3.Input new pass successful 4.Xác nhận lại newpass 5.Click[Save] 6.Relogin 1. Click [Thay đổi mật khẩu ]button 2.Input old pass 3.Input new pass= oldpass successful 4.Xác nhận lại newpass 5.Click[Save] 6.Relogin

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Van_change password unsuccessful Van_Change_ pass_02

Van_Change_ pass_03

Van_Change_ pass_04

Van_Change_ pass_05

Nguyễn Thị Vân

1. Click [Thay đổi mật khẩu ]button Check not 2.Input old pass input newpass 3.Not Input new but input pass confirm 4.Input confirm password newpass Vídụ (pass : 1 ) 5.Click[Save] 6.Relogin 1. Click [Thay đổi mật khẩu ]button 2.Input old pass Check input 3.Input new pass newpass max max short short 4.Xác nhận lại Vídụ (pass : 1 ) newpass 5.Click [Save] 6.Relogin 1. Click [Thay đổi mật khẩu ]button 2.Input old pass Check have 3.Input new pass change pass Xác nhận lại .but login old newpass pass 5.Click [Save] 6.Relogin= old pass 1. Click [Thay đổi mật khẩu ]button 2.Input wrong old Check input pass wrong old pass 3.Input new pass 4.Xác nhận lại newpass 5.Click [Save]

65

1. Display message" please input this field"

User have account

1. Display message" input pass not safe "

User have account

1. Display message" input wrong pass or pass have change before " 2.unsuccessf ul

User have account

1. Display message" input old pass not true " 2.unsuccessf ul

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

6.Relogin

Van_Change_ pass_06

Van_Change_ pass_07

Van_Change_ pass_08

Van_Change_ pass_09

Nguyễn Thị Vân

1. Click [Thay đổi mật khẩu] button 2.Input old pass Check Not 3.Not Input new input newpass pass but confirm 4.Xác nhận lại password mới newpass 5.Click [Save] 6.Relogin 1. Click [Thay đổi mật khẩu ]button Check input 2.Input old pass newpass khác 3.Input new pass với new max short confirm 4.Xác nhận lại password mới newpass 5.Click [Save] 6.Relogin 1. Click [Thay đổi mật khẩu] button 2.Input old pass Check input 3.Input new pass have space mix max short old pass 4.Xác nhận lại newpass 5.Click [Save] 6.Relogin 1. Click [Thay đổi mật khẩu] button 2.Input old pass. Check input old 3.Input new pass pass and new max short pass. 4.Xác nhận lại Click cancel newpass 5.Click [Save] 6.Relogin

66

1. Display message"Co nfirm password not true " 2.unsuccessf ul

User have account

1. Display message"Co nfirm password not true " 2.unsuccessf ul

User have account

1. Display message" input old pass not true " 2.unsuccessf ul

User have account

1.unsuccessf ul

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

3.3.2 Testcase kiểm thử chức năng đăng kí Mục đích : Đăng kí Mô tả :  Ngƣời sử dụng có thể xem đợt đăng kí.  Đăng kí  Chấm điểm  Duyệt chấm điểm  Duyêt lại chấm điểm Luồng sự kiện  Phải nằm trong đợt đăng kí và chƣa đăng kí

Hình 3-4: Màn hình chức năng đăng kí Từ mô tả và luồng sự kiện đƣa kỹ thuật áp dụng kiểm thử chức năng đăng kí: Sử dụng kỹ thuật kiểm thử bảng quyết định.

Nguyễn Thị Vân

67

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Điều kiện Trong đợt đăng kí Chƣa đăng kí Kết Đƣợc đăng kí quả Không đƣợc đăng kí

1 y y x

2 y n

3 n y

4 n n

x

x

x

Bảng sau khi gộp Điều kiện

Kết quả

1

2

3

Trong đợt đăng kí

y

y

n

Chƣa đăng kí

y

n

y

Đƣợc đăng kí

x x

x

Không đƣợc đăng kí

Bảng 3-3. Bảng testcase dùng kỹ thuật quyết định chức năng đăng kí Đăng kí thi đua

Đăng kí thi đua successful

DKTD_01

Check[Đăng kí thi đua]cá nhân

DKTD_02

Check[Đăng kí thi đua]tập thể

Nguyễn Thị Vân

1. Click [Đăng kí thi đua] 2. Click [Cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 1. Click [Đăng kí thi đua] 2. Click [Tập thể]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật]

68

successful

successful

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

DKTD_03

Check[Đăng kí thi đua]danh sách cá nhân

DKTD_04

Check time on[Thời gian đăng kí] and havent resgister

DKTD_06

Check [thời gian diễn ra ]=[thời gian hiện tại]

1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật]

successful

successful

successful

Đăng kí thi đua unsƣccessful

DKTD_09

Check [Đăng kí ] tỉme havent [Thời gian đăng kí] and havent resgister

DKTD_08

Check [Đăng kí ] time on [thời gian đăng kí] and registed

1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân].

1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đơt thi đua]

Display

message "Have nt on time register" Display

message "Haven register"

Bảng 3- 4. Testcase Đăng kí thi đua. 3.3.3. Testcase kiểm thử chức năng Quản lý đợt thi đua Mục đích : Quản lý đợt thi đua Mô tả :  Ngƣời sử dụng có thể xem list đợt thi đua  Thêm, sửa, xóa đợt thi đua  Đăng kí đợt thi đua  Chấm điểm đợt thi đua Luồng sự kiện  View đợt thi đua

Nguyễn Thị Vân

69

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Thêm mới, sửa xóa đợt thi đua.  Chấm điểm thi đua: STT là số cho tiêu chí, STT là chữ /số La Mã cho nhóm.

Hình 3-5 Màn hình quản lý đợt thi đua  Lớp tương đương cho trƣờng Ngày diễn ra, ngày đăng kí, ngày chấm điểm lại, ngày duyệt. Theo đó, ngày không thể chọn đƣợc ngày thuộc lớp các ngày lớn hơn hoặc nhỏ hơn ngày hiện tại, hoặc ngày diễn ra không đƣợc nhỏ hơn ngày đăng kí.  Các testcase khác sẽ phụ thuộc vào việc đặc tả chức năng và tuân thủ theo quy định về giao diện màn hình, quy định về font chữ riêng đƣợc quy định trong tài liệu đặc tả chức năng.  Dùng bảng quyết định để kiểm thử Chấm điểm cá nhân, chấm điểm tập thể: STT là số cho tiêu chí, STT là chữ /số La Mã cho nhóm.

Đợt thi đua

Van_ĐTĐ_01

Nguyễn Thị Vân

Bảng 3-6 Testcase Đợt thi đua [Đợt thi đua] successful 1. Click [Thêm mới đợt thi đua] 2. Click [Cấp phát Check [Thêm động] mới] 3. Click [Đơn vị phát động] 4. Click [Ngày bắt đầu] 5. Input [Tên đợt thi

70

successful

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

đua] 6. Click [Trạng thái] 7. Input [Kế hoạch]

Van_ĐTĐ_02

Check [Danh hiệu đã đƣợc đăng kí]

Van_ĐTĐ_03

Check[Hình thức đã đƣợc đăng kí]

Nguyễn Thị Vân

71

1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 7. Click [Thời gian diễn ra] 8. Click [Thời gian đăng kí] 9. Click [Thời gian tự chấm điểm] 10. Click [Thời gian chấm điểm lại] 11. Click [Thời gian xét tặng] 12. Click [Danh hiệu đã đƣợc tặng] 13. Click button [Danh hiệu] 1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 7. Click [Thời gian diễn ra] 8. Click [Thời gian đăng kí] 9. Click [Thời gian tự

successful

User have account

successful

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Van_ĐTĐ_04

Check [Sửa]

Van_ĐTĐ_05

Check [Xóa]

Van_ĐTĐ_06

chấm điểm] 10. Click [Thời gian chấm điểm lại] 11. Click [Thời gian xét tặng] 12. Click [Danh hiệu đã đƣợc tặng] 13. Click button [Danh hiệu] 14.Click button[Hình thức đã đƣợc đăng kí] 15. Click [Ghi lại] 1. Click [Đợt thi đua] 2. Click [Sửa] 3. Click [Ghi lại] 1. Click [Đợt thi đua] 2. Click [Xóa]

Check [kế hoach] after [Thêm mới đợt thi đua] successful

Van_ĐTĐ_07

Check [Chấm điểm cá nhân]

Van_ĐTĐ_08

Check [Chấm điểm tập thể ]

Van_ĐTĐ_09

Check[Duyệt kết

Nguyễn Thị Vân

72

1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 7. Click [Kế hoạch] 8. Click [Cập nhật] 1. Click [Quản lý thi đua] 2. Click [Chấm điểm cá nhân] 1. Click [Quản lý thi đua] 2. Click [Chấm điểm tập thể ] 1. Click [Quản lý thi

successful

successful

User have account User have account

successful

User have account

successful

User have account

successful

User have account

successful

User

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

đua] 2. Click [Duyệt kết quả chấm] 1. Click [Quản lý thi Check [Chấm đua] điểm lại] 2. Click [Chấm điểm lại] 1. Click [Quản lý thi Check [Thi đua đua] tập thể] 2. Click [Thi đua tập thể] 1. Click [Quản lý thi Check [Thi đua cá đua] nhân] 2. Click [thi đua cá nhân] 1. Click [Quản lý thi Check [Duyệt đua] điểm ] 2. Click [Duyệt điểm ] [ Đợt thi đua] unsuccessful 1. Click [Thêm mới đợt thi đua] 2. Click [Cấp phát động] Check [Thêm mới 3. Click [Đơn vị phát đợt thi đua ] but động] not input [Tên đợt 4. Click [Ngày bắt đầu] thi đua] 5. Not Input [Tên đợt thi đua] 6. Click [Trạng thái] 7. Input [Kế hoạch] 1. Click [Thêm mới đợt thi đua] Check [Thêm mới 2. Click [Hình thức đợt thi đua ] but phát động] not input [Tên đợt 3. Click [Cấp phát thi đua] động] 4. Click [Đơn vị phát quả chấm]

Van_ĐTĐ_10

Van_ĐTĐ_11

Van_ĐTĐ_12

Van_ĐTĐ_13

Van_ĐTĐ_14

Van_ĐTĐ_15

Nguyễn Thị Vân

73

have account

successful

User have account

successful

User have account

successful

User have account

successful

User have account

Display message " Please input this field"

User have account

Display message " Please input this field"

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Van_ĐTĐ_16

Van_ĐTĐ_17

Van_ĐTĐ_18

Nguyễn Thị Vân

động] 5. Click [Ngày bắt đầu] 6. Not Input [Tên đợt thi đua] 7. Click [Trạng thái] 8. Input [Kế hoạch] 1. Click [Thêm mới đợt thi đua] 2. Not Click [Hình thức phát động] 3. Click [Cấp phát Check [Thêm mới động] đợt thi đua ] but 4. Click [Đơn vị phát not click[Hình động] thức phát động] 5. Click [Ngày bắt đầu] 6. Input [Tên đợt thi đua] 7. Click [Trạng thái] 8. Input [Kế hoạch] 1. Click [Thêm mới đợt thi đua] 2. Click [Hình thức phát động] 3. Not Click [Cấp phát Check [Thêm mới động] đợt thi đua ] but 4. Click [Đơn vị phát not click [Cấp động] phát động] 5. Click [Ngày bắt đầu] 6. Input [Tên đợt thi đua] 7. Click [Trạng thái] 8. Input [Kế hoạch] 1. Click [Tiêu chíchấm Check [Tiêu chí điểm] chấm điểm] input 2. Input STT = A and "string" but input [Tên] = Tên tiêu chí [tên tiêu chí] 3. Click [Cấp phát động]

74

Display message " Please input this field"

User have account

Display message " Please input this field"

User have account

Cann’t input continue field

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Van_ĐTĐ_19

Van_ĐTĐ_20

Nguyễn Thị Vân

Check [Tiêu chí chấm điểm] input "number " but input [tên nhóm

Check [Đợt thi đua] not click [Danh hiệu ]

75

4. Click [Đơn vị phát động] 5. Click [Ngày bắt đầu] 6. Input [Tên đợt thi đua] 7. Click [Trạng thái] 8. Input [Kế hoạch] 1. Click [Tiêu chíchấm điểm] 2. Input STT = A and [Tên] = Tên tiêu chí 3. Click [Cấp phát động] 4. Click [Đơn vị phát động] 5. Click [Ngày bắt đầu] 6. Input [Tên đợt thi đua] 7. Click [Trạng thái] 8. Input [Kế hoạch] 1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Not Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 7. Click [Thời gian diễn ra] 8. Click [Thời gian đăng kí] 9. Click [Thời gian tự chấm điểm] 10. Click [Thời gian chấm điểm lại] 11. Click [Thời gian

Cann’t input continue field

User have account

Display message " Please choose [danh hiệu]"

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

xét tặng]

Van_ĐTĐ_21

Check [Đợt thi đua] not click [Hình thức]

Van_ĐTĐ_22

Check [Đăng kí thi đua] not click [Thời gian diễn ra]

Nguyễn Thị Vân

76

1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Not Click [Hình thức] 6. Click [Cập nhật] 7. Click [Thời gian diễn ra] 8. Click [Thời gian đăng kí] 9. Click [Thời gian tự chấm điểm] 10. Click [Thời gian chấm điểm lại] 11. Click [Thời gian xét tặng] 1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 7. Not Click [Thời gian diễn ra] 8. Click [Thời gian đăng kí] 9. Click [Thời gian tự chấm điểm] 10. Click [Thời gian chấm điểm lại] 11. Click [Thời gian

Display message " Please choose [hình thức] "

User have account

Display message " Please input this field"

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

xét tặng]

Van_ĐTĐ_23

Ceck [Đợt thi đua] not click [Thời gian tự chấm điểm]

Van_ĐTĐ_24

Check [Đợt thi đua] not click [Thời gian chấm điểm lại]

Nguyễn Thị Vân

77

1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 7. Click [Thời gian diễn ra] 8. Click [Thời gian đăng kí] 9. Not Click [Thời gian tự chấm điểm] 10. Click [Thời gian chấm điểm lại] 11. Click [Thời gian xét tặng] 1. Click [Đăng kí thi đua] 2. Click [Danh sách cá nhân]. 3. Click [Đợt thi đua] 4. Click [Danh hiệu] 5. Click [Hình thức] 6. Click [Cập nhật] 7. Not Click [Thời gian diễn ra] 8. Click [Thời gian đăng kí] 9. Click [Thời gian tự chấm điểm] 10. Click [Thời gian chấm điểm lại] 11. Click [Thời gian xét tặng]

Display message " Please input this field"

User have account

Display message " Please input this field"

User have account

Lớp Tin Trắc Địa K57

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Van_ĐTĐ_25

Check [Đợt thi đua] not click [Thời gian đăng xét tặng]

Van_ĐTĐ_26

Check [Đợt thi đua] [Thời gian diễn ra ]