môn học kiểm chứng phần mềm

Môn học

Kiểm chứng phần mềmTh.S Nguyễn Thị Kiêm Ái

Giới thiệu

Mức độ KTPM

Kỹ thuật và chiến lược KTPM

Xây dựng test plan

Quản lý tiến trình kiểm thử

Các khía cạnh test trên web

Các thành phần và chuẩn UI

Công cụ kiểm thử

Rèn luyện

Báo cáo

Kiến thức tổng quan Web testing

Nội dung

Đặt vấn đề

• Tại sao cần quản lý chất lượng?– Thỏa mãn yêu cầu được đặt ra từ

phía khách hàng/ người dùng– Hạn chế tối đa những lỗi có thể xảy

ra– Tạo uy tín cho công ty– ....

• Software Testing: Software testing is the process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.

Mục tiêu testing trên các quan điểm

• Stakeholders : programmers, test engineers, project managers và customers.

• Các stakeholder nhìn nhận quy trình test từ nhiều quan điểm khác nhau:– It does work: khi thực thi một đơn vị chương

trình, các programmers muốn biết nó có hoạt động hay không trong trường hợp bình thường. Đối với toàn hệ thống cũng cùng ý tưởng, khi toàn hệ thống được tích hợp developers muốn test hệ thống có thực hiện các chức năng cơ bản hay không. muốn chỉ ra rằng hệ thống hoạt động.

– It does not work: khi các programmers (đội ngũ phát triển) hài lòng khi một đơn vị (hệ thống) hoạt động ở mức độ nhất định, thêm các test được tiến hành với mục tiêu tìm ra faults muốn làm cho hệ thống fail.

– Giảm rủi ro failure : hầu hết các hệ thống phần mềm phức tạp đều có fault làm cho hệ thống fail theo thời gian. Khái niệm “failing from time to time” làm phát sinh khái niệm failure rate. Khi fault được tìm ra và fix thì failure rate giảm xuống mục tiêu của việc thực hiện test là giảm rủi ro fail xuống mức có thể chấp nhận được.

– Giảm chi phí testing: chi phí thiết kế, bảo trì và thực hiện test case, chi phí phân tích kết quả thực hiện mỗi test case, chi phí document test case, chi phí hệ thống thực thi thực sự và document nó.

• Như vậy, càng ít test case càng giảm chi phí liên quan. Mục tiêu cao nhất của thực hiện test là tạo ra sản phẩm rủi ro thấp (low – risk software) với ít test case nhất effectiveness of test cases, Test engineers phải lựa chọn test case ít nhất mà hiệu quả nhất.

Các vấn đề trung tâm trong testing

• Chúng ta nhận ra rằng xoay quanh vấn đề thử nghiệm(testing) là phát hiện ra tất cả các lỗi. Đây là nhiệm vụ khó có thể thực hiện. Vì vậy, điều tiếp theo tốt nhất là chọn input domain phù hợp và phủ tốt để thử nghiệm chương trình.

• Đề cập đến Hình 1.5, Lấy D là miền đầu vào của một chương trình P. Giả sử chúng ta chọn một tập hợp con D1 của D, D1 ⊂D, để test chương trình P. Phần test trong D1 chỉ là một phần P1, có nghĩa là, P1 ⊂P, hành vi thực hiện của P, trong đó trường hợp lỗi với các phần khác, P 2, sẽ không bị phát hiện.

• Bằng cách chọn một tập hợp con của lĩnh vực đầu vào D 1, các kỹ sư kiểm tra cố gắng để suy ra các thuộc tính của toàn bộ chương trình P bằng cách quan sát hành vi của một phần P 1 của toàn bộ hành vi của P dựa trên đầu vào D 1.

• Vì vậy, lựa chọn các tập hợp con của miền đầu vào phải được thực hiện một cách có hệ thống và cẩn thận để khấu trừ là chính xác và đầy đủ nhất có thể.Ví dụ, các ý tưởng được xem xét khi lựa chọn các trường hợp thử nghiệm.

Hoạt động kiểm thử - Testing Activities

• Để kiểm tra một chương trình, một kỹ sư kiểm tra phải thực hiện một chuỗi các hoạt động thử nghiệm.Hầu hết các hoạt động này đã được thể hiện trong hình 1.6 và được giải thích sau đây. Những giải thích này tập trung vào một trường hợp thử nghiệm duy nhất.

• Identify an objective to be tested: Hoạt động đầu tiên là xác định một mục tiêu để được kiểm tra.Mục tiêu xác định mục đích, hoặc thiết kế một hoặc nhiều trường hợp thử nghiệm để đảm bảo rằng chương trình hỗ trợ mục tiêu. Một mục đích rõ ràng phải được liên kết với tất cả các trường hợp thử nghiệm.

Các nhân tố chất lượng của phần mềm

Mô hình MCCall

Độ đo chất lượng phần mềm

• McCall đã đưa ra các độ đo chất lượng phần mềm như sau:

• Kiểm toán được: Có thể kiểm tra dễ dàng việc tuân thủ các chuẩn.

• Độ chính xác• Tính đầy đủ: Mức độ đáp ứng đầy đủ các

yêu cầu đã được đặt ra.• Tính súc tích: Độ gọn của chương trình.• Tính nhất quán: Tính nhất quán trong toàn

bộ chương trình.• Phổ biến dữ liệu: Việc dùng các cấu trúc

và kiểu dữ liệu chuẩn trong chương trình.• Dung sai: Những ảnh hưởng khi chương

trình bị lỗi có thể chấp nhận được.• Hiệu quả thực hiện: Hiệu năng khi chạy

chương trình.• Tính mở rộng được: Mức độ mà theo đó

các thiết kế kiến trúc, dữ liệu hay chức năng có thể mở rộng được.

• Tính tổng quát• Độc lập phần cứng: Mức tách biệt của

phần mềm đối với phần cứng.• Tính môđun: Tính độc lập của các thành

phần.• Tính vận hành: Tính dễ vận hành của

chương trình.• Tính an toàn: khả năng kiểm soát hay bảo

vệ chương trình và dữ liệu.• Tính sưu liệu: Khả năng đáp ứng đầy đủ

các thông tin trong quá trình phát triển phần mềm.

• Tính đơn giản: Mức độ người dùng có thể hiểu được chương trình một cách dễ dàng.

• Tính độc lập hệ thống phần mềm: Mức độ mà theo đó chương trình được độc lập với các tính năng và các ràng buộc với các môi trường khác.

• Tính huấn luyện: Mức độ mà chương trình trợ giúp người dùng thực hiện các thao tác.

Một số khái niệm trong KTPM

• Phân biệt QC & QAQC: Quality Control

Điều khiển chất lượngQA: Quality Assurance

Đảm bảo chất lượng

- Tập hợp các hoạt động được tạo ra nhằm đánh giá chất lượng sản phẩm, bảo đảm sản phẩm đúng đặc tả yêu cầu

- Tập các hoạt động được tạo ra nhằm đảm bảo tiến trình phát triển sản phẩm là phù hợp, hệ thống sẽ đáp ứng các mục tiêu

- Trực tiếp kiểm tra chất lượng của sản phẩm

- Chịu trách nhiệm toàn bộ về tiêu chuẩn, quy trình kiểm tra để đảm bảo chất lượng

- Có nhiệm vụ khảo sát, chạy thử và báo cáo lỗi

- Có nhiệm vụ giám sát các tiêu chuẩn và quy trình sản xuất PM được định nghĩa và tuân thủ nghiêm túc.

Một số khái niệm trong KTPM(tt)

• Ví dụ: Xác định công việc QC? QA?– Kiểm tra để bảo đảm các giải thuật khi viết

code phải được chú thích rõ ràng– Kiểm tra module “đăng ký học phần” trong dự

án hoạt động đúng như yêu cầu không?


• Phân biệt kiểm thử black box & white box– Black box: kiểm thử hộp đen

• Đặc tính của hộp đen là chỉ nhìn thấy bên ngoài, ko thể nhìn thấy được cấu tạo bên trong của hộp. Do đó, BlackBox là loại test mà ta không cần biết cấu trúc bên trong mà chỉ cần quan tâm đến Input và Output, nó dùng trong functional test, thường là QC làm.

– White box: kiểm thử hộp trắng• đặc tính của hộp trắng có thể thấy được bên trong

của hộp. Do đó, WhiteBox là loại test mà ta cần phải biết cấu trúc bên trong, nó dùng trong unit test, thường do developer làm.


• Manual Testing và Automation Testing.

Test Case

• Test case là trường hợp kiểm tra, được thiết kế nhằm xác nhận một đối tượng có thỏa mãn yêu cầu đặt ra hay không

• Gồm các thành phần cơ bản:– Tập các giá trị nhập– Các điều kiện tiên quyết, các bước thực thi – Các kết quả mong đợi

Thế nào là testcase tốt?

• 1. Chính xác:Test case được thiết kế ra có thể test được mọi thứ như đã thiết kế.

2. Ngắn gọn:Các bước mô tả thực hiện test gọn gàng, không dư thừa, chỉ mô tả chính xác những step cần phải thực hiện.

3. Có thể tái sử dụng:Viết test case sao cho có thể dùng lại hoặc tái sử dụng nó vào các dự án khác (có thể chỉ một phần)

4. Có thể quản lý thay đổi:Có thể quản lý các lần thay đổi test case dựa vào spec (thêm sheet revision, không xóa dòng cũ mà gạch ngang)

5. Có thể sử dụng để test: Có thể thực hiện theo các bước ghi trong test case để thực hiện test sản phẩm, phù hợp với người thực hiện test và môi trường test mà khách hàng mong muốn.

6. Độc lập với người viết: Người đọc test case và test có thể không phải là người thiết kế ra test case, vì vậy đảm bảo sao cho tester khác cũng có thể đọc, hiểu test case và thực hiện test được.

7. Tự làm sạch: Qua các lần thay đổi, cập nhật, test case sẽ được tinh chỉnh lại cho phù hợp hơn, tốt hơn.

Test Case (tt)

• Ví dụ:– Textbox cho phép nhập số dương– Chương trình cho phép người dùng nhập 3

cạnh của tam giác, tính chu vi tam giác.– Viết testcase cho màn hình “Login”

Giới thiệu

Mức độ KTPM







Rèn luyện

Báo cáo


Nội dung

Mức độ kiểm thử cơ bản

Mức đơn vị

(Unit Test)• Các bộ phận đơn lẻ

Mức tích hợp

(Intergration Test)

• Các nhóm bộ phận

Hệ thống

(System Test)• Toàn bộ hệ thống

Mức chấp nhận sản

phảm

(Acceptance Test)

• Toàn bộ hệ thống• Nhìn từ khác

hàng

Mối tương quan giữa phát triển và kiểm tra phần mềm

Unit Test – Kiểm tra mức đơn vị

• Unit là phần nhỏ nhất của mã nguồn (source code) có thể được biên dịch, liên kết và load (compiled, linked, loaded)

• Các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit.

• Unit testing được thực hiện bởi Lập trình viên (Developers)

• Sử dụng phương pháp test hộp trắng (White box testing)

Intergration Test- Kiểm tra tích hợp

• Software Integration là quá trình hợp nhất các unit đơn lẻ vào thành một hệ thống (hoặc một tiểu hệ thống).

• Integration testing là test các liên kết giữa các unit thành phần, phát hiện lỗi giao tiếp xảy ra giữa các Unit.

• Integration testing đòi hỏi các module phải được unit test trước.

System Test- Kiểm tra hệ thống• Mục đích: kiểm tra 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, bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

• 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

• Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc 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

System Test- Kiểm tra hệ thống(tt)

• Điểm khác nhau then chốt giữa Integration Test và System 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 tra viên hoàn toàn độc lập với nhóm phát triển dự án.

• Test dựa trên yêu cầu hệ thống, test chức năng, hiệu năng, bảo mật, cấu hình..

Acceptance Test - Kiểm tra chấp nhận

• Thực hiện sau sau giai đoạn System Test • Khách hàng hoặc ủy quyền cho một nhóm

thứ ba thực hiện• Mục đích là để chứng minh PM 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 trước khi nghiệm thu

Installation Test- Kiểm tra cài đặt

• Test các bước thực hiện cài đặt dựa trên Tài liệu hướng dẫn cài đặt, chứng minh Tài liệu hướng dẫn cài đặt đã qui chuẩn để chuyển giao khách hàng.

• Installation test được thực hiện bởi Nhóm test

Regression Test - Kiểm tra hồi quy

• Regression Test không phải là một mức kiểm tra, như các mức khác đã nói ở trên.

• Đơn thuần kiểm tra lại PM sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản PM mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt.

• Regression test có thể thực hiện tại mọi mức kiểm tra.

Giới thiệu

Mức độ KTPM







Rèn luyện

Báo cáo


Nội dung

Các phương pháp kỹ thuật test

• Equivalence class partitioning – Phân lớp tương đương– Phân các test cases theo nhóm các TEST

CASE cùng loại, gọi là class hay lớp các TEST CASE.

– Trong mỗi class chọn test chỉ một vài test case.

– Nên test nhiều class thay cho test nhiều test cases trong cùng một class.

Các phương pháp kỹ thuật test(tt)

• Control flow testing – Luồng điều khiển– Phân loại các TEST CASE theo sơ đồ mô

hình luồng xử lý (Đó là sơ đồ mô hình hoá 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).

– Mỗi rẽ nhánh trong luồng xử ký là 1 TEST CASE.

– Đây là 1 kỹ thuật test căn bản, áp dụng hiệu quả được cho hầu hết các hệ thống, áp dụng được cho mọi giai đoạn test.


• Data flow testing – Luồng dữ liệu– Áp dụng cho loại hệ thống đòi hỏi và xử lý

nhiều dữ liệu (data-intensive)– Phân loại các TEST CASE theo sơ đồ mô

hình luồng dữ liệu


• Transaction testing – Giao dịch– Áp dụng cho các hệ thống xử lý giao dịch

(các giao dịch trong ngân hàng, đặt vé máy bay, đặt phòng khách sạn…)

– Phân loại TEST CASE theo loại các giao dịch, chú trọng việc xác định điểm khởi đầu, điểm kết thúc, và hàng đợi các điểm giao dịch cần xử lý.


• Syntax testing – Cú pháp– Áp dụng test các câu lệnh, các trường toán tử

có định dạng xác định.– Phân tích, nắm rõ các cú pháp để thiết kế các

TEST CASE, sử dụng kỹ thuật phân lớp tương đương, và theo loại đúng hoặc sai cú pháp.


• State machine testing – Trạng thái– Áp dụng cho loại hệ thống có đặc trưng

chuyển đổi trạng thái, các “menu driven application” – Chương trình điều khiển bằng trình đơn, các hệ thống thiết kế bằng phương pháp hướng đối tượng.

– Các TEST CASE được phân loại từ việc lập các biểu đồ chuyển đổi trạng thái của hệ thống, theo loại chuyển đổi trạng thái hợp lệ và không hợp lệ.


• Loop testing – Vòng lặp– Áp dụng trong whitebox testing: quan tâm đến

vòng lặp trong code.– Áp dụng trong blackbox testing: quan tâm đến

vòng lặp trong hành vi của hệ thống. – Phân loại các TEST CASE theo số giá trị đặc

biệt lần rẽ nhánh các vòng lặp.


• Domain testing – vùng– Áp dụng cho loại hệ thống xử lý nhiều vùng

giá trị của biến.– Phân loại các TEST CASE theo vùng giá trị

của biến, đặc biệt chú trọng các TEST CASE quanh biên ranh giới, nơi hệ thống có những xử lý khác nhau so với các giá trị biến khác.

Chiến lược test

• Danh sách các ưu tiên test - “where to focus testing”– Những vùng quan trọng nhất của phần mềm– Những vùng phần mềm hay được dùng nhất– Những vùng có đặc trưng riêng, khác biệt hẳn

với các vùng khác của phần mềm– Những vùng phần mềm dễ bị ảnh hưởng nhất

của các thay đổi vừa có (khi regression test)

Chiến lược test (tt)

– Những lỗi dễ xảy ra nhất– Những lỗi (người dùng) dễ nhìn thấy nhất– Những loại lỗi khó fix nhất– Những loại lỗi mà tester biết rõ nhất– Những loại lối mà tester biết lờ mờ nhất– Positive test trước, negative test sau (test các

trường hợp hợp lệ trước, các trường hợp không hợp lệ sau)

Chiến lược test (tt)

• Ưu tiên sắp xếp test theo quality dimension– Số 1: thường là Function testing, và phải bao

quát được bussines cycle của hệ thống.– Số 2: Usability testing, chú ý test GUI, đảm

bảo đúng syntax, theo standards và user friendly.

Giới thiệu

Mức độ KTPM







Rèn luyện

Báo cáo


Nội dung

Testplan

• Tài liệu mô tả kế hoạch của hoạt động test dự kiến, bao gồm:– Mục tiêu, phạm vi, phương pháp tiếp cận,

nhân lực, tài nguyên, lịch biểu.– Nhiệm vụ test, môi trường test– Kỹ thuật thiết kế test, tiêu chuẩn test– Lý do lựa chọn và rủi ro có thể xảy ra

Testplan (tt)

• Các hạng mục có trong testplan– Tiêu đề– Version của phần mềm– Quá trình hiệu chỉnh tài liệu như tác giả, ngày

cập nhật, duyệt– Mục lục– Mục đích/ mục tiêu của tài liệu– Giới thiệu tổng quan về sản phẩm– Tài liệu liên quan như spec, tài liệu thiết kế,

các kế hoạch test khác,...

Testplan (tt)

– Phạm vi và giới hạn test– Các vấn đề ưu tiên và tập trung test– Phân công nguồn nhân lực– Môi trường test– Công cụ test– Qui trình test– Phương pháp test– …

Testplan (tt)

• Làm thế nào để xây dựng testplan tốt?– Dựa trên đặc tả yêu cầu, thiết kế sản phẩm– Áp dụng các kỹ thuật test– Kế hoạch test phải tiến hành sớm– Phân chia nhân lực và nguồn tài nguyên hợp

lý– Dựa trên kinh nghiệm các dự án tương tự

• Các mẫu testplan tham khảo

Giới thiệu

Mức độ KTPM







Rèn luyện

Báo cáo


Nội dung

Hoạt động QC trong QT PTPM

Các giai đoạn kiểm thử

• Lập kế hoạch kiểm thử testplan• Xây dựng các trường hợp kiểm thử

testcase• Thực thi excute• Đánh giá, báo cáo lỗi bug report

• http://hcmus.byethost32.com/client/index.php

• Danh sách opensource• http://www.opensourcetesting.org/bugdb.p

hp• Công cụ quản lý lỗi:

http://hcmus.byethost32.com/client/index.php

http://hcmus.byethost32.com/client/index.php

http://www.opensourcetesting.org/bugdb.php







Click to edit title style

ThemeGallery is a Design Digital

Content & Contents mall developed by Guild Design Inc.

ThemeGallery is a Design Digital

Content & Contents mall developed by Guild Design Inc.

Description of the contents




ThemeGallery is a Design Digital Content & Contents mall developed by Guild Design Inc.

Giới thiệu



30%30%

60%60%

80%80%

60%60%

Text in hereText in here






Title

Title

Title






Text in here Text in here

Contents

Contents



• Description of the contents


Description of the business




Description of the contentsDescription of the contents Description of the contentsDescription of the contents


Title in here

Title in hereTitle in here

Title in here

Description of the

contents

A

D B

C


feature 01 feature 02

55%

16%

45%

41%16%

50%

A product

B product

C product

• ContentsThemeGallery is a Design Digital Content & Contents mall developed by Guild Design Inc.


Text

Text

Text

TextThemeGallery is a Design Digital Content & Contents mall developed by Guild Design Inc.






ThemeGallery is a Design Digital Content &

Contents mall developed by Guild Design Inc.

ThemeGallery is a Design Digital Content &

Contents mall developed by Guild Design Inc.

120%Description of the contents 140% Description of

the contents

Title in here


Title

• Description of the sub contents







Title Title Title

[Image Info] www.wizdata,co,kr Note to customers : This image has been licensed to be used within this PowerPoint template only. You may not extract the image for any other use.


- ThemeGallery is a Design Digital Content & Contents mall developed by Guild Design Inc.



Description of the company’s sub contentsDescription of the company’s sub contents




2008

2007

2006

2005

2004

2003

2002

2001

2000















BeforeBefore AfterAfter





2000 2004 2008

“ThemeGallery is a Design Digital Content & Contents mall developed

by Guild Design Inc.”





Text in here

Description of the contents Description of the contents

ThemeGallery is a Design Digital Content & Contents mall

developed by Guild Design Inc.

ThemeGallery is a Design Digital Content & Contents mall

developed by Guild Design Inc.



Title in here






Title in here

Title in here

Title in here


20%

40%

80%

100%

120%

140%

160%

2000 2002 2004 2006 2008 2010

Description of the

contents

Description of the

contents

90% Text in here

155% Text in here

contents

contents



ThemeGallery is a Design Digital Content & Contents

mall developed by Guild Design Inc.

ThemeGallery is a Design Digital Content & Contents

mall developed by Guild Design Inc.

Description of the sub contents



Title in here

Title in here

Title in here


Title in here






Text in here

Text in here

Text in here

Text in here






M1 M2

M4 M3

ThemeGallery is a Design Digital Content & Contents mall developed

by Guild Design Inc.

Text in here

Text in here

Text in here






Text in here



Text in here



Text in here



Text in here





Title in here Title in here Title in here Title in here

AA BB CC DD

Describe a vision of company or strategic contents.



50%

65%

83%75%

70%90%




Title in here

• Description of the contents• Description of the contents


• Description of the contents• Description of the contents


Text in here

Text in here

Text in here

Text in here

Text in here

Text in here

Text in here

Text in here





Description ofthe contents

Description ofthe contents

Text in here

Text in here

Title in here


Company

LOGO

2008. 01

2006 ~ 2007

2005 ~ 2006

2004 ~ 2005






Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text inhere

Text in here

CEO

• Your text in here











Tài liệu tham khảo4. Beizer, B. (1995), Black- box Testing, Wiley.

5. Boehm. B. W. (1976), Software Engineering, IEEE Transactions onComputers.

6. British Standard (1998), BS 7925- 1 - Standard for Software Component

Vocabulary, British Computer Society.7. British Standard (1998), BS 7925- 2 - Standard for Software

ComponentTesting, British Computer Society, p. 1- 15.

8. Cem Kaner, Jack Falk, Hung Quoc Nguyen (1999), Testing ComputerSoftware, John Wiley & Sons, Inc., p. 27- 141.

Your company slogan in here

www.themegallery.com

Thank You!

môn học kiểm chứng phần mềm

Documents