I. KIỂM THỬ PHẦN MỀM

1. Giới thiệu

Như một nhà phát triển phần mềm có kinh nghiêm đã nói “quá trình kiểm thử một

phần mềm thật sự không bao giờ kết thúc, quá trình này chỉ chuyển từ bạn ( một

nhà phát triển phần mềm) sang một người khác( khách hàng). Và mỗi khi khách

hàng sử dụng chương trình, thì quá trình này lại tiếp diễn. Nhưng bằng cách áp

dụng các quá trình kiểm thử có tính chất hệ thống, những kỹ sư phần mềm có thể

kiểm định một cách hoàn chỉnh và cũng bằng cách đó quá trình kiểm thử có thể

phát hiện và chỉnh sửa phần lớn các lỗi trước khi quá trình kiểm thử mới của

khách hàng bắt đầu. Và kiểm thử phần mềm là luôn luôn cần thiết với mỗi sản phẩm vì không có sản phẩm nào là tuyệt đối không có lỗi .

Quá trình phát triển một hệ thống phần mềm bao gồm một chuỗi các hoạt động

sản sinh ra mã lênh, tài liệu. Nơi mà những sai sót của con người có thể xảy ra bất

kỳ lúc nào. Một lỗi có thể bắt đầu xuất hiện ngay tại lúc bắt đầu của quá trình phát

triển, thiết kế, cài đặt. Do đó quá trình phát triển một phần mềm phải kết hợp với

một quá trình kiểm thử

Quá trình thiết kế các trường hợp có khả năng phát hiện các lỗi/sai sót khiếm

khuyết của phần mềm. Có thể phân thành 2 loại kỹ thuật thiết kế : kỹ thuật kiểm

thử “white box” và “black box”.

“White box” là kỹ thuật tập trung kiểm tra trên cầu trúc điều kiển của chương

trình, các trường trường hợp kiểm thử được tạo ra có thể đảm bảo tất cả các câu

lệnh được viết trong chương trình được thực thi ít nhất một lần trong quá trình

kiểm thử và rằng tất cả các điều kiện logic trong trương trình cũng đã được kiểm

thử trong đó.

Trong khi “white box” được mô tả như là một phương pháp kiểm thử trên diện

nhỏ và là một phương pháp tiêu biểu để kiểm thử các thành phần nhỏ của

chương trình như module, hay những nhóm nhỏ các module. Thì “black box” lại

tập trung vào hướng kiểm thử trên diện rộng, các trường hợp được thiết kế tập

trung phân tích/phân mảnh vùng thông tin đầu vào và đầu ra của chương trình.

2. Mục đích của kiểm thử phần mềm.

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

lỗi/các yếu điểm của chương trình.

ØMột trường hợp kiểm thử tốt là một trường hợp có khả năng lớn trong việc tìm ra những lỗi chưa được phát hiện.

ØMột trường hợp kiểm thử không tốt ( không thành công) là một trường hợp mà khả năng tìm thấy những lỗi chưa biết đến là rất ít.

Mục tiêu của kiểm thử phần mềm là thiết kế những trượng hợp kiểm thử để có thể

phát hiện một cách có hệ thống những loại lỗi khác nhau và thực hiện việc đó với

lượng thời gian và tài nguyên ít nhất có thể.

3.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

-Thiết kế test case

-Phát triển test script

-Thực hiện test

-Đánh giá kết quả test

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

•Kiểm thử luồng dữ liệu liên quan đến việc chọn đường đi với mục tiêu bao phủ các cặp gán (definition) và dùng (use) dữ liệu, được gọi là các tiêu chuẩn luồng dữ liệu

•Qui trình tổng quát của kiểm thử luồng dữ liệu là:

–Vẽ đồ thị luồng dữ liệu cho chương trình

–Chọn tiêu chuẩn kiểm thử luồng dữ liệu

–Xác định các đường đi trong đồ thị để thỏa mãn tiêu chuẩn lựa chọn (all-defs, all-uses, all-P-uses/some-C-uses, v.v..)

–Tạo các ca kiểm thử cho các đường đi đã xác định

Đỉnh gán (defining node) cho biến v nếu giá trị của v được thiết lập tại lệnh ở đỉnh n.

Đỉnh sử dụng của biến v là đỉnh giá trị của v được đọc ra bằng lệnh ở đỉnh n.

Đỉnh sử dụng là sử dụng mệnh đề (P-use) nếu lệnh tương ứng là lệnh mệnh đề, ngược lại là sử dụng tính toán (C-use)

Đỉnh tương ứng với P-use luôn có số cạnh ra >= 2, đỉnh C-use có số cạnh ra <= 1.

Một số định nghĩa

•Gọi PATHS(P) là tập tất cả các đường đi có thể trong CFG của chương trình P.

•Một đường đi du-path (def-use) cho biến v là đường đi trong PATHS(P) thỏa mãn

–Tồn tại DEF(v, m) và USE(v, n) sao cho m và n tương ứng là đỉnh đầu và cuối của đường đi

•Một đường đi dc-path với biến v là một du-path với các đỉnh đầu DEF(v, m) và USE(v,n) sao cho không có đỉnh nào ở trên đường đi đó gán giá trị cho v.

•Gán toàn cục của biến x ở đỉnh n là DEF(x, n) và tồn tại một đường đi từ n đến một đỉnh m nào đó chứa C-use hoặc P-use toàn cục của x.

•Một C-use toàn cục của x tại đỉnh n là một C-use của x ở n và x chưa được gán ở đỉnh nào khác ngoài n

•Đường đi đơn giản là đường có đỉnh đầu và cuối không trùng nhau.

•Đường đi không có vòng lặp là đường tất cả các đỉnh ko trùng nhau.

•Đường đi đầy đủ là đường từ đỉnh vào đến đỉnh ra của CFG

•Du-path với biến x ở đỉnh n1 là đường đi n1..nk mà

–n1 có gán toàn cục cho x và

–nk có c-use của x và đường đi này là đơn giản, hoặc

–nk có p-use của x và đường đi này là không có vòng lặp với x.

Ví dụ liên kết def-use

read (z)

x = 0

y = 0

if (z>=0)

  { x = sqrt \(z\) 

   if \(0<=x && x<=5\)

             y = f \(x\)  
     else 

               y = h \(z\)}

y = g (x, y)

print (y)

def-use cho biến z

read (z)
x = 0
y = 0
if (z³0)
{

x = sqrt (z)
if (0£x && x£5)
y = f (x)
else
y = h (z)

}

y = g (x, y)

print (y)

Tiêu chuẩn bao phủ kiểm thử DU-Path

•Ý tưởng

–Sử dụng thông tin def-use và tiêu chuẩn cụ thể để nhận được các đường đi cụ thể trong đồ thị CFG

•Từ đó xác định các ca kiểm thử

•Chúng ta giả sử T là tập các đường đi đầy đủ và khả thi trong CFG của chương trình P và V là tập tất cả các biến trong P

•All-P-Uses/Some-C-Uses

–Với mọi v, T gồm các đường đi dc-path từ mọi đỉnh gán của v đến mọi đỉnh p-use của v và nếu một định nghĩa của v không có p-use thì tồn tại một đường đi dc-path đến ít nhất một c-use

•All-C-Uses/Some-P-Uses

–Với mọi v, T gồm các đường đi dc-path từ mọi đỉnh gán của v đến mọi đỉnh c-use của v và nếu một định nghĩa của v không có c-use thì tồn tại một đường đi dc-path đến ít nhất một p-use

•All-DU-Paths

–Với mọi v, T gồm các đường đi dc-path từ mọi đỉnh gán của v đến mọi đỉnh dùng của v và đến đỉnh tiếp theo của mỗi USE(v, n) và các đường đi này hoặc là lặp một lần hoặc không lặp

Ví dụ All-DU-Paths: pow(x,y)

1. void pow (int x, y)

2. {

3. float z;

4. int p;

5. if (y < 0)

6. p = 0 – y;

7. else p = y;

8. z = 1.0;

9. while (p != 0)

10. {

11. z = z * x;

12. p = p – 1;

13. }

14. if (y < 0)

15. z = 1.0 / z;

16. printf(z);

17. }

All-DU-Paths vơi biến x

All-DU-Paths với biến y

**
**

Bài toán kiểm Thử Dòng Dữ Liệu

I.Bài toán

Chương trình vay vốn UOB lãi xuất 0% đối với sinh viên đang theo học tại các trường Đại học

-Đầu vào

• Kết quả học tập đạt loại trung bình trở lên (điểm trung bình >= 2.0)

• Điểm rèn luyện đạt loại khá trở lên (điểm rèn luyện >= 70)

• Hoàn cảnh gia đình (Hộ nghèo/ hộ cận nghèo/ Gia đình dân tộc thiểu số)

-Đầu ra

• Dữ liệu không hợp lệ

• Không được vay

• Được vay 10.000.000/năm (đối với những sinh viên có đủ điều kiện điểm học tập, điểm rèn luyện, gia đình hộ nghèo hoặc là người dân tộc thiểu số)

• Được vay 5.000.000/năm (đối với những sinh viên có đủ điều kiện điểm học tập, điểm rèn luyện, gia đình hộ cận nghèo)

II.Mã Nguồn

public static int vayVon(float &diemHocTap,

                     int &diemRenLuyen, String &hoanCanh\){

int ketqua = -1;

if\(diemHocTap < 0 \|\| diemHocTap > 4 \|\| diemRenLuyen < 0\){

    ketqua = -1;

}else if\(diemHocTap < 2.0 \|\| diemRenLuyen < 70\){

    ketqua = 0;

}else{

    if\(hoanCanh.equals\("ho ngheo"\) 

          \|\| hoanCanh.equals\("dan toc thieu so" \)\)

         ketqua = 10000000;

    else 

        ketqua = 500000;

}

return ketqua;

}

IV.Du-pair

1.Biến diemHocTap

2.Biến diemRenLuyen

3.Bien hoanCanh

V.Complete path

1.Biến diemHocTap

2.Bien diemRenLuyen

3.Bien hoanCanh

VI.Test Report

II. KIỂM THỬ TỰ ĐỘNG

Kiểm thử thủ công được thực hiện bởi con người, ngay tại chỗ ngồi và trước máy tính, cẩn thận thực hiện các bước kiểm tra. Automation Testing nghĩa là sử dụng một công cụ tự động để thực hiện các test case.

Các phần mềm tự động hóa cũng có thể nhập dữ liệu thử nghiệm vào System Under Test, so sánh kết quả mong đợi và kết quả thực tế và tạo các báo cáo kiểm tra chi tiết.

Kiểm tra tự động đòi hỏi khoản đầu tư đáng kể tiền bạc và nguồn lực. Chu kỳ phát triển kế tiếp sẽ đòi hỏi phải thực hiện lặp lại test suite nhiều lần. Sử dụng một công cụ kiểm thử tự động (test automation tool) nó có thể ghi lại các test suite này và re-play lại như yêu cầu. Các test suite này là tự động, không cần sự can thiệp của con người. Điều này cải thiện ROI của Automation Testing.

ROI là tỷ lệ lợi nhuận ròng so với chi phí. ROI =(Doanh thu – Chi phí) / Chi phí

Mục tiêu của tự động hóa là để giảm số testcase và giảm thiểu loại bỏ kiểm tra thủ công.

1. Tại sao sử dụng Automate Testing?

Kiểm tra tự động là rất quan trọng vì những lý do sau:

·Kiểm thử bằng tay cho tất cả các flow, field và scenario là tốn thời gian/chi phí

·Khó để kiểm tra các trang web đa ngôn ngữ bằng tay

·Tự động hóa không đòi hỏi sự can thiệp của con người. Có thể chạy automated test mà không cần giám sát

·Tự động hóa làm tăng tốc độ thực hiện kiểm tra

·Manual testing có thể trở nên nhàm chán và do đó dễ bị sót lỗi

2. Những Test case nào để chạy Automate?

Test case dùng để test tự động có thể được lựa chọn bằng cách sử dụng các tiêu chí sau đây để tăng automation ROI

·Rủi ro cao (high risk) – Business Critical test case

·Những Test case mà được thực hiện lặp lại

·Những Test case rất tẻ nhạt hoặc khó thực hiện bằng tay

·Test case tốn thời gian

Các loại sau đây của các Test case không phù hợp để tự động hóa:

·Test case được thiết kế mới và chưa được thực hiện bằng tay ít nhất một lần

·Test case mà yêu cầu được thay đổi thường xuyên

·Test case được thực hiện trên nền tảng add-hoc

3. Quy trình tự động hóa

Sau đây là các bước tiếp theo trong một quá trình tự động

4. Lựa chọn công cụ kiểm tra

Công cụ kiểm tra lựa chọn chủ yếu phụ thuộc vào các công nghệ mà Application Under Test được xây dựng trên. Ví dụ QTP không hỗ trợ Informatica. Vì vậy, QTP không thể được sử dụng để test các ứng dụng Informatica.

5. Xác định phạm vi của Automation

Phạm vi của tự động hóa là những khu vực mà Application Under Test sẽ được test tự động hóa. Những điểm sau đây giúp xác định phạm vi:

·Tính năng rất quan trọng cho các doanh nghiệp

·Kịch bản có số lượng lớn dữ liệu

·Chức năng phổ biến trên các ứng dụng

·Tính khả thi

·Mức độ mà các thành phần được tái sử dụng

·Độ phức tạp của test case

·Khả năng sử dụng các test case tương tự để test trình duyệt chéo

6. Lập kế hoạch, thiết kế và phát triển

Trong giai đoạn này, tạo Automation strategy và plan chi tiết

·Công cụ Automation tool

·Thiết kế framwork và các tính năng cho nó

·Các item in-scope và out of scope

·Schedule và Timeline cho kịch bản và thực hiện

·Phân phối các automation test

7. Test Execution

Automation Scripts được thực hiện trong giai đoạn này. Các kịch bản cần nhập test data trước khi thiết lập để chạy. Sau khi thực hiện nó sẽ cho ra các test report

Execution có thể được thực hiện bằng cách sử dụng automation tool trực tiếp hoặc thông qua các Test Management tool và sẽ gọi các automation tool.

Khi chức năng mới được bổ sung vào System Under Test với các chu kỳ liên tiếp, Automation Scripts cần phải được bổ sung, xem xét và duy trì cho mỗi release cycle. Bảo trì là cần thiết để cải thiện hiệu quả của các Automation Scripts. Automation tools sau đây là các công cụ kiểm tra phổ biến nhất:

**QTP:**Quick Test Professional của HP (đuợc biết đến như là HP Functional Test) đứng đầu trong các Functional Testing Tool. Công cụ này hỗ trợ rất nhiều các môi trường bao gồm cả SAP, Java, Delphi. QTP có thể được sử dụng kết hợp với Quality Center, được khuyên dùng cho web hoặc ungứ dụng client / server.

**Rational Robot:**Là một IBM tool sử dụng để tự động hóa kiểm tra hồi quy, chức năng và cấu hình cho client server, thương mại điện tử cũng như các ứng dụng ERP. Nó có thể được sử dụng với Rational Test Manager- hỗ trợ các hoạt động quản lý.

**Selenium:**một mã nguồn mở của Web Automation Tool. Nó hỗ trợ tất cả các loại trình duyệt web.

8. Làm thế nào để chọn một công cụ tự động hóa (Automation Tool)?

Lựa chọn đúng công cụ có thể là một nhiệm vụ khó khăn. Tiêu chí sau sẽ giúp bạn chọn công cụ tốt nhất yêu cầu của bạn:

·Environment Support

·Dễ sử dụng

·Database

·Xác định đối tượng

·Kiểm tra hình ảnh

·Error Recovery Testing

·Object Mapping

·Ngôn ngữ kịch bản sử dụng

·Hỗ trợ cho nhiều loại hình kiểm tra – bao gồm functional, test management, mobile, etc…

·Hỗ trợ cho nhiều testing frameworks

·Dễ dàng để debug các automation software scripts

·Khả năng nhận biết objects trong nhiều môi trường

·Mở rộng cho Test reports và test results

·Giảm thiểu chi phí hướng dẫn đào tạo sừ dụng tool

Công cụ lựa chọn là một trong những thách thức lớn nhất phải được giải quyết trước khi đi cho tự động hóa.Đầu tiên, xác định các yêu cầu, tìm hiểu các công cụ khác nhau và khả năng của mình, thiết lập những kỳ vọng từ tool.

**Framework trong Automation:**Một framework được thiết lập cho automation guidelines giúp cho:

·Duy trì tính nhất quán của Testing

·Cải thiện kiểm tra cấu trúc

·Sử dụng tối thiểu code

·Ít bảo trì code

·Cải thiện khả năng tái sử dụng

·Tester không có kiến thức kĩ thuật cũng có thể thực hiện

·Giảm thời gian đào tạo sử dụng tool

Có bốn loại framework được sử dụng trong software automation testing:

·Data Driven Automation Framework

·Keyword Driven Automation Framework

·Modular Automation Framework

·Hybrid Automation Framework

9. Cách chọn Automation tốt nhất:

Để có được tối đa ROI tự động hóa, quan sát những điều sau đây

·Phạm vi của tự động hóa cần phải được xác định cụ thể trước khi bắt đầu dự án. Điều này đặt ra những kỳ vọng trong Automation

·Chọn công cụ tự động hóa phù hợp: Một công cụ không được lựa chọn dựa trên tính phổ biến mà nó cần phù hợp với yêu cầu

·Chọn framework phù hợp

·Tiêu chuẩn Scripting phải được tuân theo trong khi viết kịch bản cho automation. Một vài tiêu chuẩn như sau:

+Tạo kịch bản thống nhất, scripts, comment, code

+Có thể xử lý ngoại lệ

+Làm thế nào lỗi hoặc hành vi người dùng có thể đuợc kiểm soát

·Measure metrics – thành công của tự động hóa không thể được xác định bằng cách so sánh hiệu quả thực hiện bằng tay với thực hiện tự động, nhưng nó có thể đuợc thể hiện thông qua số liệu sau đây.

+%của các defects tìm thấy

+Thời gian cần thiết để thử nghiệm tự động hóa cho mỗi chu kỳ phát hành

+Thời gian tối thiểu để thực hiện automation testing cho mỗi cycle và toàn bộ cycle

+Chỉ số hài lòng của khách hàng

+Nâng cao năng suất

Các hướng dẫn ở trên nếu được quan sát sẽ có thể trợ giúp trong việc automation test của bạn thành công.

10. Lợi ích của việc kiểm tra tự động

Sau đây là những lợi ích của automated testing:

·70% nhanh hơn so với kiểm tra thủ công

·Test coverage rộng hơn

·Kết quả đáng tin cậy

·Đảm bảo tính nhất quán

·Tiết kiệm thời gian và chi phí

·Cải thiện độ chính xác

·Không cần sự can thiệp của con người

·Tăng hiệu quả

·Tái sử dụng test scripts

·Kiểm tra thường xuyên và triệt để

·Đưa ra thị trường được sớm hơn

11. Kết luận

Lựa chọn chính xác automation tool, testing process, team là yếu tố giúp automation testing thành công. Phương pháp thủ công và tự động hóa nên được thực hiện kết hợp với nhau