TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

****************************

Bài tập lớn môn học:

KỸ THUẬT PHẦN MỀM

ĐỀ TÀI:

TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM

(SOFTWARE TESTING)

Giảng viên hướng dẫn: TS Vũ Thị Hương Giang

Sinh viên thực hiện: Lê Văn Duy 20070506 CNPM – K52

Vũ Trọng Quý 20062628 CNPM – K52

Nguyễn Sơn Hà 20070955 CNPM – K52

Lại Đức Hiệp 20071155 CNPM – K52

Hà Nội, 10-2011

1

Các kỹ thuật kiểm thử phần mềm 2011

MỤC LỤC

LỜI NÓI ĐẦU.....................................................................................................4

BẢNG PHÂN CÔNG CÔNG VIỆC.................................................................5

Chương I: CÁC KHÁI NIỆM CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM.......6

1. Bài toán Kiểm thử phần mềm..................................................................6

2. Khái niệm Kiểm thử phần mềm...............................................................6

3. Các thuật ngữ...........................................................................................7

4. Mục tiêu của Kiểm thử phần mềm...........................................................8

5. Các nguyên tắc kiểm thử..........................................................................9

6. Vòng đời của việc kiểm nghiệm (Testing Life Cycle).................................9

7. Quá trình kiểm thử phần mềm...............................................................11

8. Phân loại các kiểm thử...........................................................................12

Chương II: CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM...........................14

1. Khái quát................................................................................................14

2. Kỹ thuật Kiểm thử hộp trắng (White-box Testing)................................16

2.1. Kiểm thử đường diễn tiến của chương trình....................................17

2.2. Kiểm định cấu trúc điều khiển.........................................................20

3. Kiểm thử Hộp đen (Black-box Testing).................................................24

3.1. Phân vùng tương đương...................................................................25

3.2. Phân tích giá trị biên........................................................................26

3.3. Kỹ thuật Cause – Effect Graphing...................................................27

2


Chương III: CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM...............................30

1. Tiếp cận chiến lược kiểm thử phần mềm...............................................30

1.1. Kiểm chứng và hợp lệ hóa...............................................................30

1.2. Tổ chức kiểm thử phần mềm...........................................................31

1.3. Chiến lược kiểm thử phần mềm.......................................................32

1.4. Tiêu chuẩn hoàn thành kiểm thử......................................................35

2. Kiểm thử thành phần..............................................................................36

3. Kiểm thử tích hợp..................................................................................38

3.1. Tích hợp trên xuống.........................................................................39

3.2. Tích hợp dưới lên.............................................................................42

3.3. Kiểm thử hồi quy.............................................................................43

3.4. Gợi ý về việc kiểm thử tích hợp......................................................45

3.5. Lập tài liệu về kiểm thử tích hợp.....................................................46

4. Kiểm thử phát hành................................................................................49

5. Kiểm thử hệ thống..................................................................................53

6. Nghệ thuật gỡ lỗi....................................................................................54

6.1. Quá trình gỡ lỗi................................................................................55

6.2. Xem xét tâm lý.................................................................................56

6.3. Cách tiếp cận gỡ lỗi.........................................................................57

Chương IV: THỰC TẾ TẠI CÁC CÔNG TY VÀ BÀI HỌC CỦA BẢN THÂN.................................................................................................................60

1. Thực tế áp dụng vào các công ty tại Việt Nam......................................60

3


A: THÔNG TIN VỀ CÔNG TY KHẢO SÁT FSOFT...............................62

B: THÔNG TIN VỀ CÔNG TY KHẢO SÁT MISA.................................65

2. Bài học kinh nghiệm và đánh giá kết luận của nhóm............................67

TÀI LIỆU THAM KHẢO..................................................................................69

4


LỜI NÓI ĐẦ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.”

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 kiế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 định trên diện nhỏ và là một phương pháp tiêu biểu để kiểm định 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 định 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.

5


BẢNG PHÂN CÔNG CÔNG VIỆCHỌ VÀ TÊN MSSV NỘI DUNG CÔNG VIỆC

LÊ VĂN DUY 20070506

Tìm hiểu chung về Kiểm thử phần mềm, tìm kiếm tài liệu

và lập báo cáo

VŨ TRỌNG QUÝ 20062628 Các kỹ thuật kiểm thử

NGUYỄN SƠN HÀ 20070955 Các kỹ thuật kiểm thử

LẠI ĐỨC HIỆP 20071155 Các chiến lược kiểm thử

Khảo sát ở các công ty tất cả các thành viên đều tham gia

6


Chương I: CÁC KHÁI NIỆM CƠ BẢN VỀ KIỂM THỬ PHẦN MỀM

1. Bài toán Kiểm thử phần mềmQuá 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ử.

Kiểm thử phần mềm có thể đươc hiểu như là một quá trình bất thường thú vị. Thật sự thì trong giai đoạn ban đầu của quá trình phân tích, thiết kế và phát triển, Những kỹ sư lập trình đã cố gắng xây dựng một phần mềm từ những khái niệm khá trù tượng ngoài thực tế để hình thành một chương trình cụ thể. Và bây giờ đến giai đoạn kiểm thử họ lại tạo ra các trường hợp kiểm thử để nhằm “đánh đổ” phần mềm đã xây dựng. Thật sự thì quá trình kiểm đình là một bước trong quá trình phát triển phần mềm có tình chất tiêu cực nhằm bác bỏ hơn là xây dựng như các bước khác.

2. Khái niệm Kiểm thử phần mềmTheo IEEE, tổng quan về kiểm thử phần mềm có thể được phát biểu như sau:

Kiểm thử phần mềm là một hoạt động được thực hiện để kiểm tra chất lượng sản phẩm phần mềm, cải thiện nó, bằng cách định ra các nhược điểm và vấn đề của nó. Kiểm thử bao gồm các xác minh về sự đáp ứng của phần mềm trước một tập các test case, được lựa chọn phù hợp từ các module thực thi phổ biến của phần mềm, so sánh với các đáp ứng đáng mong đợi.

Như vậy, kiểm thử phần mềm là một khâu mấu chốt trong công nghệ sản xuất phần mềm, nhằm đảm bảo chất lượng phần mềm, trước khi nó được xuất xưởng. Quá trình kiểm thử cũng có thể coi như là một nghệ thuật trong việc phát hiện ra lỗi từ tài liệu đặc tả cho đến thiết kế, mã hóa.

7


Một kiểm thử thành công là phát hiện ra lỗi, ngược lại một kiểm thử tồi là không thể phát hiện ra lỗi. (Sue A. Conger – The New SE).

Các khó khăn trong Kiểm thử phần mềm:

- Do kiểm thử là chạy thử chương trình với tập dữ liệu giả nên không thể khẳng định tính đúng của chương trình do bản chất quy nạp không hoàn toàn của nó.

- Trong nhiều trường hợp, việc kiểm thử thường được thực hiện từ những giai đoạn đầu của quá trình cài đặt sản phẩm.

- Các chương trình nên được kiểm chứng theo hai kỹ thuật: kiểm thử và chứng minh. Và nếu có thể nên khẳng định tính đúng của chương trình thông qua văn bản chương trình

- Như vây, một chương trình tuyệt đối đúng phải được thực hiện thông qua: tính đúng đắn của thuật toán và tính tương đương của chương trình với thuật toán (được thể hiện ở chứng minh thông qua văn bản chương trình).

- Thêm vào trong quá trình kiểm thử, ta thưòng mắc phải các đặc trưng của nguyên lý chủ quan như sau:

- Bộ dữ liệu Test không thay đổi trong quá trình xây dựng phần mềm:

o Chỉ Test các trường hợp chính thống, hợp lệ, không quan tâm đến các cận và các sự cố.

o Cài đặt chức năng nào thì chỉ Test riêng chức năng đó, không chỉ Test tổng hợp chức năng vừa cài đặt với các chức năng đã cài đặt trước đó.

o Người Test đồng thời là người xây dựng phần mềm tức vừa đá bóng, vừa thổi còi.

8


3. Các thuật ngữTrong quá trình kiểm thử, ta luôn sử dụng các thuật ngữ dưới đây:

Lỗi (Error): Là các lỗi lầm do con người gây ra.

Sai sót (Fault): Các sai sót gây ra lỗi. Có thể phân chia các sai sót làm 2 loại: Sai sót do dư thừa và Sai sót do bỏ sót

o Sai sót do dư thừa: Chúng ta đưa ra một vài thứ không chính xác vào mô tả yêu cầu phần mềm.

o Sai sót do bỏ sót: Người thiết kế bỏ sót một vài phần đáng lẽ ra phải có trong mô tả yêu cầu phần mềm, điều này dẫn tới sai sót.

Hỏng hóc (Failure): Xảy ra khi các sai sót được thực thi.

Kết quả không mong đợi, hậu quả (Incident): Là những kết quả do sai sót đem đến. Hậu quả là các triệu chứng liên kết với một hỏng hóc và báo hiệu cho người sử dụng biết sự xuất hiện của hỏng hóc.

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

Thẩm tra (Verification): Là tiến trình xác định đầu ra của một công đoạn trong việc phát triển phần mềm có phù hợp với công đoạn trước đó hay không.

Xác nhận (Validation): là tiến trình xác nhận hệ thống đã phát triển xong phù hợp với mô tả yêu cầu.

4. Mục tiêu 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.

9


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

5. Các nguyên tắc kiểm thử Nguyên tắc khách quan: Người kiểm thử không phải là tác giả của phần

mềm đang kiểm thử.

Nguyên tắc ngẫu nhiên: Dữ liệu và chức năng được chọn, tuy có cùng chủ đích, nhưng không nhất thiết phải theo trình tự nhất định.

Nguyên tắc “người sử dụng kém”: Hệ thống được một ngưởi sử dụng ở trình độ thấp (có thể chấp nhận được) sử dụng. Người này có thể gây ra các sự cố không lường trước được của hệ thống.

Nguyên tắc “kẻ phá hoại”: Hệ thống rơi vào tay người sử dụng có trình độ cao, chủ ý phá hoại.

* “Trình độ” ở đây thuộc lĩnh vực công nghệ thông tin hoặc lĩnh vực phần mềm đang hướng tới.

6. Vòng đời của việc kiểm nghiệm (Testing Life Cycle)Dưới đây là các công đoạn của phát triển phần mềm và cách khắc phục lỗi:

10


Hình 1 - Vòng dời của kiểm nghiệm

Sự tương ứng giữa vòng đời dự án và quá trình kiểm thử:

Hình 2 - Sự tương ứng giữa vòng đời dự án và kiểm thử

11


7. Quá trình kiểm thử phần mềmMột mô hình cho quá trình kiểm định được mô tả dưới Hình 3. Thông tin

đầu vào được cung cấp cho quá trinh kiểm định gồm:

Thông tin cấu hình của phần mềm: các thông tin này bao gồm: mô tả về yêu cầu của phần mềm (Software Requirement Specification). Mô tả về thiết kế của chương trình (Design Specification) và mã của chương trình.

Thông tin cầu hình về kiểm thử bao gồm : kế hoạch kiểm thử, và thủ tục kiểm thử và các chương trình chạy kiểm thử như: chương trình giả lập môi trương, chương trình tạo các trường hợp kiểm thử… Các trương hợp kiểm thử phải đi cùng với kềt quả mong muốn, Trong thực tế những thông tin này cũng là một phần của software configuration ở trên.

Từ những thông tin đầu vào chương trình được chạy kiểm thử và kết quả của sau bước này sẽ được đánh giá/ so sánh với một tập các kết quả mong đợi. khi kết quả của quá trình so sánh thất bại thì một lỗi được phát hiện và quá trình gở lỗi (debugging) bắt đầu. Gở lỗi là một quá trình không thể đoán trước được do một lỗi gây ra bởi sự khác nhau giữa kết quả kiểm thử và kết quả mong đọi có thể tốn một giờ, một ngày hay một tháng để tìm ra nguyên nhân và chỉnh sửa. Và cũng chính sự không chắc chắn cố hữu này mà làm cho quá trình kiểm định rất khó đưa ra một lịch biểu chắc chắn.

Lúc mà kết quả kiểm định được thống kê và đánh giá. Chất lượng và độ tin cậy của một phần mềm được ước lượng. Nếu có những lỗi nghiêm trọng xãy ra thường xuyên những lỗi dẫn đến cần phải thay đổi thiết kế của chương trình thì chất lượng của chương trình rất không tốt. Nhưng nếu ngược lại các module/hàm đều hoạt động đúng đắn như thiết kế ban đầu và những lỗi được tìm thấy có thể chỉnh sửa dễ dàng, thì có 2 kết luận có thể được đưa ra :

Chất lượng của phần mềm là chấp nhận được

Những kiểm định có thể không thoả đáng/thích hợp để phát hiện ra những lỗi nghiêm trọng đã đề cập trên.

12


Vậy thì cuối cùng là nều mà quá trình kiểm định phát hiện không có lỗi thì. Ở đây có một chút nghi ngờ rằng những thông tin cầu hình về kiểm thử không đủ và rằng lỗi vẫn tồn tại trong phần mềm. Những lỗi này sẽ được phát hiện sau này bởi người sử dụng và được chỉnh sửa bởi lập trình viên nhưng ở tại giai đoạn bảo trì và chi phí của những công việc này sẽ tăng lên 60 đến 100 lần so với chi phí cho mổi chỉnh sửa trong giai đoạn phát triển.

Ta thấy rằng chi phí tiêu tốn quá nhiều cho quá trình bảo trì để chỉnh sửa môt lỗi do đó cần phải có những kỹ thuật hiệu quả để tạo được các trường hợp kiểm thử tốt.

13


Hình 3 - Quá trình kiểm thử

8. Phân loại các kiểm thửCó hai loại kiểm thử phần mềm chính đó là kiểm thử tĩnh (static testing) và

kiểm thử động (dynamic testing).

Kiểm thử tĩnh – Static testing

Kiểm Thử

(Testing)

Ước Lượng

(Evaluation)

Debug

Kết quả mong đợi

Kết quả của quá trình kiểm thử

Lỗi(Errors)

Sửa lổi

Thông tin cấu hình của một phần mềm

( Software Configuration)

Thông tin cấu hình cho quá trình kiểm thử( Test Configuration)

14


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.

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.

15


Chương II: CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM

1. Khái quátHiện tại phát triển rất nhiều phương thức thiết kế các trường hợp kiểm thử

cho phần mềm. Những phương pháp này đều cung cấp một hướng kiểm thử có tính hệ thống. Quan trọng hơn nữa là chúng cung cấp một hệ thống có thể giúp đảm bảo sự hoàn chỉnh của các trường hợp kiểm thử phát hiện lổi cho phần mềm.

Một sản phẩm đều có thể được kiểm thử theo 2 cách:

Hiểu rõ một chức năng cụ thể của một hàm hay một module. Các trường hợp kiểm thử có thể xây dựng để kiểm thử tất cả các thao tác đó.

Hiểu rõ cách hoạt động của một hàm/module hay sản phẩm. Các trường hợp kiểm thử có thể được xây dựng để đảm bảo tất cả các thành phần con khớp với nhau. Đó là tất cả các thao tác nội bộ của hàm dựa vào các mô tả và tất cả các thành phần nội bộ đã được kiểm thủ một cách thoả đáng.

Cách tiếp cận đầu tiên được gọi là kiểm thử hộp đen (Black-box testing) và cách tiếp cận thứ hai là gọi là kiểm thử hộp trắng (White-box testing).

Khi đề cập đến kiểm thử phần mềm, black-box testing còn được biết như là kiểm thử ở mức giao diện (interface). Mặc dù thật sự thì chúng được thiết kế để phát hiện lỗi. Black-box testing còn được sử dùng để chứng minh khả năng hoạt động của hàm hay module chương trình và có thể cả một chương trình lớn: các thông số đầu vào được chấp nhận như mô tả của hàm, giá trị trả về cũng hoạt đông tốt, đảm bảo các dữ liệu từ bên ngoài ví dụ như file dữ liệu được giữ/đảm bảo tính nguyên vẹn của dữ liệu khi thực thi hàm.

White-box testing là kỹ thuật tập trung vào khảo sát chặc chẽ thủ tục một cách chi tiết. Tất cả những đường diễn tiến logic trong chương trình được kiểm tra bằng những trường hợp kiểm thử kiểm tra trên các tập điều kiện và cấu trúc lặp cụ thể. Kỹ thuật này sẽ kiểm tra trạng thái của chương trình tại rất nhiều

16


điểm trong chương trình nhằm xác giá trị mong đợi tại các điểm này có khớp với giá trị thực tế hay không.

Với tất cả các mục tiêu kiểm định trên thì kỹ thuật White-box testing có lẽ sẽ dẫn đến một chương trình chính xác tuyệt đối. Tất cả những gì chúng ta cần bây giờ là thiết kế tất cả các đường logic của chương trình và sau đó là cài đặt tất cả các trường hợp kiểm định có được. Tuy nhiên việc kiểm định một cách thấu đáo tất cả các trường hợp là một bài toán quá lớn và tốn rất nhiều chi phí. Chúng ta hãy xem xét ví dụ sau:

Hình 4 - FlowChart

Bên trái là flowchart cho một chương trình đơn giản được viết bằng khoản 100 dòng mã với một vòng lặp chính thực thi đoạn mã bên trong và lăp lại không quá 20 lần. Tuy nhiên khi tính toán cho thấy đối với chương trình này có đến khoảng 1014 đường có thể được thực hiện.

Chúng ta làm tiếp một phép tính nhanh để thấy được chi phí dùng để kiểm thử đoạn chương trình nay một cách thấu đáo và chi tiết. Ta giả sử rằng để kiểm định một trường hợp cần chạy trung bình tốn một giây. Và chương trình kiểm thử sẽ được chạy 24 giờ một ngày và chạy suốt 365 ngày một năm. Vậy thì để chạy kiểm thử cho tất cả các trường hợp này cũng cần phải tốn khoản 3170 năm.

17


Do đó kiểm thử một cách thấu đáo là một việc bất khả thi cho những hệ thống lớn. Mặc dù kỹ thuật này không thể hiện thực được trong thực tế với lượng tài nguyên có hạn, tuy nhiên với một số lượng có giới hạn các đường diễn tiến logic quan trọng có chọn lựa trước để kiểm thử. Phương pháp này có thể là rất khả thi.

Ngoài ra các trường hợp kiểm thử còn có thể là sự kết hợp của cả hai kỹ thuật trên nhằm đạt được các mục tiêu của việc kiểm thử.

Chúng ta sẽ đi và chi tiết thảo luận về kỹ thuật kiểm thử hộp trắng.

2. Kỹ thuật Kiểm thử hộp trắng (White-box Testing)Trước tiên ta thảo luận một số khái niệm cần thiết cho các phần trình bày

sau: Khái niệm một đường diễn tiến của chương trình là một tập hợp lệnh được thực thi có thứ tự trong chương trình. Để đơn giản hơn có thể hiểu một đoạn chương trình hay một chương trình chứa rất nhiều các đường diễn tiến tại một lênh điều kiện rẽ nhánh tạo ra một tập đường mới.

Hình 5 - Đường diễn tiến

Trong ví dụ trên ta sẽ có 2 đường một đường khi điều kiện A nhận giá trị đúng và một đường khi điều kiện A mang giá trị sai.

Trong kiểm thử hộp trắng, các trường hợp kiểm thử được thiết kế để xem xét trên cấu trúc nội bộ của module và cấu trúc logic và cấu trúc điều kiển. Các trường hợp kiểm thử sẽ duyệt qua tất cả các lệnh trong chương trình.Tuy nhiên

Điều Kiện A

Lệnh thực hiện

False

True

18


điều này cũng gặp các khó khăn như trình bày ở trên bởi số lượng công việc phải làm. Vậy tại sao ta không tập trung vào chỉ thiết kế các trường hợp kiểm thử dựa trên kỹ thuật kiểm thử hộp đen. Câu trả lỏi nằm trong nhưng yếu điểm tự nhiên của phần mềm.

Những lỗi về lý luận và những giả sử không chính xác có xác xuất xảy ra tương đương vói những trường hợp đúng. Những lỗi có khuynh hướng xuất hiện khi chúng ta thiết kế và cài đặc chương trình, các biểu thức điều kiện, hoặc các biểu thức điều khiển, và các lỗi thường có khuynh hướng xuất hiện ở các trường hợp đặc biệt.

Chúng ta thường tin rằng một đường diễn tiến nào đó sẽ không được thực thi. Tuy nhiên thực tế thì nó có thể được thực thi. Luồng diễn tiến của chương trình đôi khi chỉ là mang tính trực giác, có thể hiểu là một giả định tưởng tượng của người lập trình về luồng điều kiển và dữ liệu đã làm cho chúng ta tạo ra lỗi. Lỗi loại này có thể được phát hiện bằng một trường hợp kiểm thử trên một đường diễn tiến.

Những lỗi về cài đặt sai do lỗi gõ phím là ngẫu nhiên và có thể xuất hiện tại bất kỳ đâu trong chương trình. Khi một chương trình được chuyển đổi từ ý tưởng thiết kế sang thành mã chương trình. một số lỗi do dánh sai hiểu sai xuất hiện. Phần lớn có thể được phát hiện bỏi những hệ thống kiểm tra cú pháp của ngôn ngữ, nhưng một số khác sẽ không được phát hiện cho đến khi chạy kiểm thử.

Mỗi một lý do giải thích tại sao phải tạo ra các trường hợp kiểm thử dựa trên kỹ thuật hộp trắng. Hộp đen cũng được nhưng có thể một số loại lỗi ở trên sẽ không được phát hiện bởi các trường hợp sử dụng phương pháp này.

Vậy cho nên thiết kế các trường hợp kiểm thử này cần phải xem xét đến sự cân bằng giữa mức độ kiểm định và khả năng hiện thực của thiết kế. Phần sau là những cấp độ kiểm định dựa trên kỹ thuật kiểm thử hộp trắng.

19


2.1. Kiểm thử đường diễn tiến của chương trìnhĐây là khái niệm chỉ đến việc thiết kế các trường hợp kiểm thử trên từng

lệnh trong chương trình sẽ thực hiện ít nhât một lần. Kỹ thuật này không quan tâm đến ảnh hưởng lên các đường quyết định (decisions path).

Các bước để xây dựng tập hợp kiểm thử có thể theo những bước sau đây:

1) Dùng tài liệu thiết kế hay source code để vẽ ra một đồ thị mô tả flow chart của chương trình hay hàm.

2) Xác định đồ thị V(G).

3) Từ đồ thị xác định tập đường độc lập tuyến tính lẫn nhau.

4) Xây dựng những trường hợp kiểm thử dựa trên tâp đường xác định ở bước trên.

Ví dụ: Tất cả các lệnh được thực thi sẽ nằm trên một đường thực thi của chương trình. Trong phần này chúng ta xét thủ tục average. (Trang bên)

Hình 6 - Code của hàm average

20


1) Phân tích thủ tục average. Mã lệnh của thủ tục được phân tích và biểu diễn thành flow chart tương ứng.

2) Tạo một đồ thị flow graph biểu diễn tương ứng với flow chart của hàm average.

Hình 7 - Flow Graph của thủ tục Average

3) Trong trường hợp này ta có thể xác định có 6 trường hợp kiểm thử như sau :

Đường 1 : 1-2-10-11-13Đường 2 : 1-2-10-12-13Đường 3 : 1-2-3-10-11-13Đường 4 : 1-2-3-4-5-8-9-2 ...Đường 5 : 1-2-3-4-5-6-8-9-2 ...Đường 6 : 1-2-3-4-5-6-7-8-9-2 ...

Ba chấm sau những đường 4, 5, 6 cho biết rằng một đường đi bất kì qua phần còn lại của câu trúc điều kiển đều được chấp nhận.

4) Tạo các trường hợp kiểm định dựa trên các đường trên

21


Bảng 1- Các trường hợp kiểm định:

Mô Tả

1 value[k] = là một giá trị hợp lệ, với k < ivalue[i] = -999 vơi một giá trị 2<=i <=100

Giá trị mong đợi

Giá trị trung bình mong đợi là giá trị trung bình đúng của tât cả giá trị k.

2 value[1] = -999Giá trị mong đợi :

Giá trị trung bình mong đợi là giá trị trung bình -999, những biền chứa giá trị tổng cộng khác đều bằng 0.

3 Cố gắng thực hiện tiến trình cho 101 giá trị hoặc hơn, 100 giá trị đầu trong value là những giá trị hợp lệGiá trị mong đợi :

giống như trường hợp 1

4 value[i] = giá trị hợp lệ khi i< 100value[k]< minimum khi k < iGiá trị mong đợi :

Giá trị trung bình mong đợi là giá trị trung bình đúng trên k giá trị và tổng nhận giá trị đúng

5 value[i] = là một giá trị hợp lệ khi i <100value[k] > maximum khi k<=i

Giá trị mong đợi :

Giá trị trung bình mong đợi là giá trị trung bình đúng trên n giá trị và tổng nhận giá trị đúng

6 value[i] = là một giá trị hợp lệ khi i <100Giá trị mong đợi :

Giá trị trung bình mong đợi là giá trị trung bình đúng trên n giá trị và tổng nhận giá trị đúng

Mỗi trường hợp được chạy và so sánh với kết quả mong đợi. Nếu tất cả các trường hợp kiểm định đều cho kết quả như mong muốn thì có thể khẳng định rằng tất cả các dòng lệnh trong thủ tục average đều được kiểm thử ít nhất một lần.

2.2. Kiểm định cấu trúc điều khiển2.2.1 Kiểm thử các biểu thức điều kiện

Kiểm thử biểu thức điều kiện là phương pháp kiểm thử trên những điều kiện logic của hàm hay module. Một điều kiện đơn giản là một biến boolean hoặc là một biểu thức quan hệ:

22


X hay Not X một điều kiện logic đơn giản.

Biểu thức quan hệ thường có dạng : E1 <phép toán quan hệ> E2

E1, E2 là các biểu thức số học và phép toán quan hệ là một trong các phép toán sau : <, <=, ==, != , > hay >=. Một điều kiện kết hợp của 2 hay nhiều điều kiện đơn giản, các phép toán boolean : OR ( | |, AND (&) and NOT (!)

Các loại lỗi của điều kiện bao gồm

Lỗi trong các thao tác luận lý (lỗi tồn tại một biểu thức không đúng, thiếu hoặc thừa các thao tác luận lý):

o Lỗi do giá trị của biến luận lý

o Lỗi do dấu ngoặc

o Lỗi do phép toán quan hệ

o Lỗi trong biểu thức toán học

Mục đích của kiểm thử cấu trúc điều kiển là phát hiện không chỉ lỗi trong điều kiện mà còn những lỗi khác trong chương trình. Nếu một tập kiểm thử cho một chương trình P là hiệu quả cho việc phát hiện lỗi trong điều kiện của P,thì bộ kiểm thử đò cũng có thể phát hiện các lỗi khác trong P.

E1 <phép toán quan hệ> E2

Ba trường hợp kiểm thử được yêu cầu để kiểm tra là giá trị E1 lớn hơn, nhỏ hơn và bằng giá trị của E2. Nếu <phép toán quan hệ> là không đúng và E1, E2 là đúng thì 3 loại kiểm thử trên có đảm bảo có thể xác định được lỗi trong phép toán quan hệ. Để phát hiện lỗi trong E1và E2 thì các trường hợp kiểm thử E1 lớn hơn, nhỏ hơn E2 có thể phát hiện ra được lỗi.

Một biểu thức có n biến, thì có 2n khả năng kiểm thử xảy ra khi (n>0).

2.2.2 Kiểm thử luồng dữ liệu (DFT)

23


Phương pháp kiểm thử luồng dữ liệu chọn lựa một số đường diễn tiến của chương trình dựa vào việc cấp phát, định nghĩa, và sử dụng những biến trong chương trình.

Để hình dung ra cách tiếp cận này ta giả sử rằng mỗi câu lệnh của chương trình được gán một số duy nhất và rằng mỗi hàm không được thay đổi thông số của nó và biến toàn cục.

DEF(S) = { X | lệnh S chứa định nghĩa X }USE(S) = { X | lệnh S chứa một lệnh/biểu thức sủ dụng X }

Nếu S là câu lệnh if hay loop, thì tập DEF của S là rỗng và USE là tập dựa trên điều kiện của câu lệnh S.

Định nghĩa 1: Biến X tại câu lênh S được cho là vẫn còn sống tại câu lênh S’ nếu như tồn tại một đường từ câu lệnh S đến câu lệnh S’ không chứa bất kỳ định nghĩa nào của X.

Định nghĩa 2: Một chuỗi dùng của biến X ( gọi là DU của X) ký hiệu [X, S, S’] là định nghĩa của X trong câu lệnh S vẫn sống trong câu lênh S’.

Phương pháp kiểm thử luồng dữ liệu yêu cầu rằng tất cả các chuỗi DU đều được kiểm thử ít nhất một lần. Có thể thấy rằng bộ kiểm thử cho luồng dữ liệu có thể không bao trùm tất cả các nhánh của chương trình. Tuy nhiên nếu môt nhánh đảm bảo được sẽ được phát hiện bởi phương pháp kiểm thử này. Trong một số hiếm trường hợp như là cấu trúc lệnh if-then trong phần then không có định nghĩa thêm một biến nào và phần else không tồn tại. Trong tình huống này thì nhánh else của câu lênh if trên không cần thiết phải bảo hộ bởi phương pháp này.

DFT rất hữu ích cho các loại kiểm thử một chương trình có nhiều lệnh if và lệnh lặp lồng nhau nhiều cấp.

2.2.3 Kiểm thử vòng lặp

Vòng lặp là một trong những nền tảng cho rất nhiều các thuật toán được cài đặt trong các phần mềm. tuy nhiên cho đến lúc này chúng ta vẫn còn ít chú ý đến việc xây dựng các trường hợp để kiểm thử.

24


Kiểm thử vòng lặp tập trung vào tính chất của cấu trúc vòng lặp. Có 4 cầu trúc vòng lặp như sau: vòng lặp đơn giản, vòng lặp móc nối, vòng lặp tạo thành tổ, và vòng lặp không cầu trúc.

Hình dưới đây mô tả các cấu trúc lặp:

25


Hình 8 - Các cấu trúc lặp

vòng lặp đơn giản

vòng lặp tạo thành

tổ

vòng lặp móc nối

vòng lặp không cầu

trúc

26


(1) Vòng lặp đơn

Tập hợp tiếp theo là các trường hợp kiểm thử cho vòng lặp đơn, với n là maximum số lần lặp.

Bỏ tính toàn vẹn của vòng lặp

Chỉ cần một lần duyệt xuyên qua cả vòng lặp

Hai lần duyệt xuyên qua cả vòng lặp

m lần duyệt xuyên qua cả vòng lặp

n-1, n, n+1 lần duyệt xuyên qua cả vòng lặp

(2) Vòng lặp tạo tổ

Nếu như chúng ta mở rộng phương pháp kiểm thử cho vòng lặp đơn thì số lượng trường hợp kiểm thử sẽ tăng rất nhiều. Sau đây là một cách là giảm sồ lượng trường hợp kiểm thử :

Bắt đầu tại vòng lặp con trong cùng. Thiết lập tất cả các vòng lặp khác là giá trị minimum.

Kiểm soát vòng lặp ở trong cùng trong khi giữ các vòng lặp bên ngoài lặp lại với giá trị là minimum thông số ảnh hưởng nhau ( thông số đó có thể là biến lặp). Thêm môt số trường hợp ngoài phạm vi của biến lặp và một số giá trị đặc biệt.

Thực hiên như bước trên và tiến ra ngoài dần

Thực hiện tiếp cho đến khi tất cả các vòng lặp được kiểm thử hết.

(3) Vòng lặp móc nối

Đối với kiểu này có thể kiểm thử bằng cách như với vòng lặp đơn ở trên nếu các biền lặp độc lập với nhau. Tuy nhiên nếu 2 vòng lặp là móc nối và biến

27


lặp của vòng lặp thứ nhất được sử dụng như là biến khởi tạo cho vòng lặp 2 thì 2 vòng lặp này không còn độc lặp nữa. Phương pháp dùng cho vòng lặp tạo tổ sẽ được sử dụng ở đây.

(4) Vòng lặp không có cấu trúc

Khi nào gặp các cầu trúc lặp như vậy thì nên thiết kế lại. Việc kiểm thử rất phức tạp.

3. Kiểm thử Hộp đen (Black-box Testing)Là phương pháp tập trung vào yêu cầu về mặt chức năng của phần mềm.

Có thể tạo ra một bộ các điều kiện các input để kiểm thử tất cả các chức năng của một chương trình. Kiểm thử hộp đen về bản chất không phải là môt phương pháp trái ngược với kiểm thử hộp trắng. Đúng hơn đây là phương pháp bổ xung cho phương pháp kiểm thử hộp trắng để phát hiện tất cả các loại lỗi khác nhau nhiều hơn là phương pháp kiểm thử hộp trắng đã biết.

Kiểm thử hộp đen cố gắng phát hiện các loại lỗi như sau:

Không đúng hay mất một số hàm/module

Giao diện không phù hợp/ lỗi về interface.

Lỗi về cấu trúc dữ liệu hay thao tác lên data bên ngoài.

Lỗi thực thi.

Lỗi về khởi động và hủy dữ liệu, biến.

Không giống như phương pháp kiểm thử hộp trắng có thể được thực hiện ở những giai đoạn đầu của quá trình kiểm thử phần mềm, Phương pháp này tập trung vào phần sau của quá trình kiểm thử. Mục đích của quá trình kiểm thử là tập trung trên vùng thông tin chư không phải trên vùng mã chương trình. Các trường hợp kiểm thử để trả lời các câu hỏi sau:

Như thế nào là hàm/chức năng hợp lệ?

28


Lớp gì của thông tin đầu vào sẽ tạo ra những trường hợp kiểm thử tốt ?

Hệ thống có khả năng bị thương tổn vói một giá trị nhập vào nào đó không?

Ranh giới của các vùng dữ liệu có đôc lập với nhau hay không ?

Tỷ lệ và kích thước dữ liệu mà hệ thống có thể hứng chịu là bao nhiêu?

3.1. Phân vùng tương đươngĐây là kỹ thuật chia vùng thông tin nhập vào của chương trình thành các lớp

thông tin/dữ liệu. Lớp tương đương biểu diễn thành một tập các giá trị hợp lệ và không hợp lệ. Nhưng lớp dữ liệu tương đương này có thể được xác định theo những cách sau:

Nếu thông tin đầu vào chỉ định một vùng các giá trị, thì ta có một lớp dữ liệu hợp lệ và hai không hợp lệ được định nghĩa.

Nếu thông tin đầu vào chỉ định một giá trị, thì ta có một lớp dữ liệu hợp lệ và hai không hợp lệ được định nghĩa.

Nếu thông tin đầu vào chỉ định một giá trị của một tập, thì ta có một lớp dữ liệu hợp lệ và hai không hợp lệ được định nghĩa.

Nếu thông tin đầu vào chỉ định một giá trị boolean, thì ta có một lớp dữ liệu hợp lệ và một không hợp lệ được định nghĩa.

Ví dụ: Một khách hàng có thể liên lạc với ngân hàng bằng máy tính cá nhân, họ gởi một mật khẩu gồm 6 chữ số và các thao tác khởi động một số chức năng của ngân hàng. Phần mềm hỗ trợ cho các ứng dụng của ngân hàng chấp nhận dữ liệu theo dạng sau:

Mã vùng - rỗng hay 3 chữ sốTiền tố - 3 chữ số không bắt đầu bằng 0 hay 1.Hậu tố - 4 chữ sốMật khẩu – 6 ký tự alphanumbericThao tác/nghiệp vụ ngân hàng – “xemtàikhoản”, “gửitàikhoản” , rúttàikhoản” …

29


Áp dụng kỹ thuật phân vùng thông tin để tạo các bộ kiểm thử như sau :

Dữ liệu vào Mô Tả

Mã vùng Boolean – giá trị của mã vùng có thể được nhập hoặc không

Range – giá trị của mã vùng có thể được định nghĩa từ 200 đến 999.

Tiền tố Range – Xác định các giá trị >200

Hậu tố Value - một chuỗi 4 số

Mật khẩu Boolean – giá trị của mật khẩu có thể được nhập hoặc không

Value – giá trị nhận là một chuỗi 6 ký tự

Thao tác/nghiệp vụ ngân hàng

Set - một tập các thao tác được ghi bên trên.

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

Thực tế thì phần lớn các lỗi có khuynh huớng xuất hiện tại biên của vùng thông tin đầu vào hơn là ở tại những vị trí ở giữa vùng. Do đó kỹ thuật phân tích giá trị biên (BVA) được phát triển. Kỹ thuật này sẽ lựa chọn một số trường hợp kiểm thử tại các giá trị biên và là kỹ thuật bổ xung cho kỹ thuật phân vùng tương đương ở trên, hơn là việc chọn một giá trị bất kỳ trong vùng này.

Nguyên tắc của BVA có phần tương tự với phương pháp phân vùng thông tin:

1. Nếu điều kiện đầu vào xác định một phạm vi được chỉ định bởi 2 giá trị a và b, những trường hợp kiểm thử sẽ được thiết kế tại các giá trị biên a và b, và trên a và dưới b.

2. Nếu điều kiện đầu vào xác định một phạm vi được chỉ định bởi tập hợp nhiều giá , những trường hợp kiểm thử sẽ được thiết kế tại các giá trị biên min và max của tập hơp đó, các giá trị lớn hơn max và nhỏ hơn min cũng được kiểm thử.

3. Áp dụng 1, 2 cho giá trị trả về.

30


3.3. Kỹ thuật Cause – Effect Graphing

Ta thấy rằng 2 kỹ thuật trên dữ liệu đầu vào đã được phân loại để phân tích. Tuy nhiên kỹ thuật sắp trình bày dưới đây cho phép xác định ra các trường hợp kiểm thử hiệu quả nhất ngay cả trong lúc dữ liệu đầu vào là khó phân loại thành các lớp như trong 2 kỹ thuật trên.

Kỹ thuật này gồm có 4 bước như sau :

1. Xác định Cause (điều kiện nhập vào) và effect (là hành động) cho mỗi một module cần kiểm định.

2. Xây dựng đồ thị cause-effect.

3. Đồ thị được chuyển thành bảng quyết định

4. Những phần/luật trong bảng quyết định được chuyển thành các trường hợp kiểm thử.

Ví dụ:

Mô tả của một module:

Sồ lượng vấn đề cần kiểm tra là 5.

Kết quả

“Pass” - nếu kết quả của 4 hay nhiều hơn 4 chủ để là thành công.

“Temporary pass” - nếu kết quả của 2 hay 3 chủ để là thành công

“Failure” - nếu kết quả có duy nhất 1 chủ để là thành công

Bước 1: Xác định quan hệ giữa input & output của module trên

Bảng Mối Quan Hệ Giữa input & output

Cause( Dữ Liệu Nhập) Result (Dữ Liệu Xuất )

1. Nếu kết quả của 4 hay nhiều hơn 4 chủ để là thành công

2. Nếu kết quả của 2 hay 3 chủ để là thành công

4. Pass

5. Temporary Pass

6. Failure

31


Bước 2: Biểu diễn quan hệ giữa cause và result trên đồ thị

Hình 9 - Một đồ thị Cause - Effect

31

2

4

5

AE

32


Hình 10 - Một Số Ký Hiệu Sử Dụng Trong Đồ Thị cause - effect

Bảng Quyết Định

Cause & Result T1 T2 T3

Cau

s

1. Pass 4 hay nhiều hơn 4 chủ đề Y N N

xác địnhBA

BA NOT

A

B

CA AND

A

B

CO OR

A

BE

Exclusive-

if A== true then B = false

if B== true then A = false

A

B

Include-

I

A

B

require-

33


e 2. “Pass” 2 hay nhiêu hơn 2 chủ đề - Y N

Res

ult 3. “Pass” là kết quả xuất ra X - -

4. “Temporary Pass” là kết quả xuất ra - X -

5. “Failure” là kết quả xuất ra - - X

Chú thích cho bảng quyết định : Dòng chỉ định điều kiện: mỗi dòng bao gồm các điều kiện để quyết định cho chương trình: ( đây là các dòng có màu xâm hơn trên bảng )

34


Chương IV: THỰC TẾ TẠI CÁC CÔNG TY VÀ BÀI HỌC CỦA BẢN THÂN

1. Thực tế áp dụng vào các công ty tại Việt Nam

Trong quá trình làm bài tập lớn, chúng em đã tiến hành khảo sát đánh giá ở một số công ty phần mềm trên địa bàn Hà Nội

Công ty cổ phần Fsoft

Công ty Misa

Tại các công ty này, chúng em đã tiến hành khảo sát về quy trình kiểm thử , cũng như khảo sát các công cụ mà các công ty đó sử dụng. Trong đó trình đó, chúng em nhận thấy các vấn đề sau tại các công ty:

Các công ty này đều quan tâm đến vấn đề kiểm thử , đánh giá chất lượng sản phầm của mình. Các công ty đều có xây dựng cho mình một đội ngũ các tester chuyên biệt để đáp ứng được yêu cầu sử dụng của mình

Các công ty trong quá trình kiểm thử đều thực hiện đầy đủ các chiến lược kiểm thử. Hầu hết, unit test đều được đặt ở khâu lập trình viên – người phát triển hệ thống. Bộ phận kiểm thử thực hiện các khâu khác của quá trình kiểm thử.

Hầu hết các công ty chỉ sử dụng phương pháp kiểm tra hộp đen (có thể cùng hộp xám) chứ không sử dụng phương pháp kiểm tra hộp trắng. Phương pháp kiểm tra hộp trắng chỉ được sử dụng trong một vài trường hợp đặc biệt.

Bên cạnh một số phương pháp và chiến lược kiểm thử nêu trong phần cơ sở lý thuyết, một số công ty còn sử dụng các phương pháp khác như kiểm thử tải. Đây là loại kiểm thử xác định khả năng chịu đựng của hệ thống, phần mềm trước nhiều yêu cầu khác nhau cùng lúc từ phía khách hàng…

35


Hầu hết các công ty chưa có quy trình chuẩn trong kiểm thử phần mềm mà chỉ làm việc dựa trên thói quen làm việc hàng ngày.

Hầu hết các công ty đều chưa có công cụ hỗ trợ kiểm thử . Tuy nhiên một số công ty đã sử dụng một hay một vài công cụ để hỗ trở kiểm thử, quản lý lỗi. Ví dụ như Fsoft, mỗi team, mỗi dự án họ sử dụng một công cụ hỗ trợ quản lý lỗi riêng, tùy theo từng dự án. Tuy nhiên nếu dự án đó không cung cấp các công cụ hỗ trợ thì trong bản thân Fsoft cũng có một hệ thống quản lý lỗi của riêng mình là DMS (defect manager system). Mỗi nhân viên khi tham gia vào trong công ty đều được học cách sử dụng hệ thống này. Tuy nhiên hầu như không được sử dụng đến do mỗi dự án đều có công cụ riêng của mình. Công ty MISA lại sử dụng nhiều công cụ hơn như Bug Jira để quản lý lỗi (đây là hệ thống được đánh giá tốt nhất và phù hợp nhất với thực tế của MISA). Exel để quản lý tescase, Source vault để quản lý tài liệu (xem thêm phần phụ lục các biên bản khảo sát).

Hầu hết các công ty đã khảo sát, việc bảo trì không được chú trọng hoặc không được tách riêng ra thành một nhóm, một phòng ban. Việc bảo trì hệ thống đươc mặc định gần như 100% là do những người phát triển hệ thống xử lý vì họ là người hiểu hệ thống nhất.

Bên cạnh nhưng công cụ khảo sát được tai các công ty, hiện nay cũng có khá nhiều tool hỗ trợ kiểm thử như:

UCM(Unified Change Management).

Junit framework hỗ trợ xây dựng testing tự động trên Java

QuickTest proessional 8.2

36


A: THÔNG TIN VỀ CÔNG TY KHẢO SÁT FSOFT

Tên công ty: FPT Software

Thông tin liên hệ:

o Website: http://fpt-software.com o Địa chỉ: FPT Building, Pham Hung St., Cau Giay District, Hanoi,

Vietnamo Email: o Điện thoại/Fax: Tel.: +84 (4) 3 768 9048 / Fax: +84 (4) 3 768 9049o Thông tin khác:

Chức năng: FPT Software là nhà cung cấp các dịch vụ gia công phần mềm tại Việt Nam. Với một đội ngũ nhân lực trẻ trung có khả năng nhất trong khu vưc, chúng tôi đã cung cấp dịch vụ chất lượng cao:

o Phát triển phần mềm và bảo trì, các giải pháp ERP kiểm tra đảm bảo chất lượng Embedded Systems, và nhiều dịch vụ khác.

o Chúng tôi cũng tự hào về kinh nghiệm của chúng tôi trong các lĩnh vực khác nhau, cụ thể là Ngân hàng & Tài chính, Viễn thông, chế tạo, bảo hiểm, Chính phủ và công cộng, bán lẻ, cơ sở hạ tầng, và dịch vụ và tiện ích.

Quy mô: N/A

THÔNG TIN VỀ CÔNG VIỆC Công việc của người khảo sát

o Làm việc trong dự án Notess migration: Mảng CMT for notes. Đây là một tools chuyển mails từ outlook sang notes (một hệ thống quản ly mail khác)

Phương pháp:

http://fpt-software.com/

37


o Black box trong dự áno White box có thể với mobile.o Unit test, regresion test, system test, acceptem test. Test tải (thỉnh

thoảng ).

Quy trình kiểm thử và bảo trìo Training: Nhân viên được training về hệ thống notes xem hệ thống này

thao tác với email như thế thế nàoo Làm việc với đối tác:

Bên yêu cầu test sẽ gửi phiên bản sử dụng hiện thời để các nhân viên làm quen

Bên yêu cầu test gửi tài liệu về tool (giới thiệu sơ bộ về tool, các chức năng của tool, hướng dẫn cách config ..).

o Nhân viên: liệt kê các chức năng của tool, tính toán khối lượng công việc (bao nhiêu testcase cho 1 chức năng, thời gian cần thiết cho 1 chức năng, tổng hợp số lượng testcase và thời gian, nhân lực cần cho các chức năng này là bao nhiêu?

o Lập kế hoạch cho thời gian viết testcase (mỗi người bao nhiêu testcase / khoảng thời gian)

o Viết testcase . Sau đó review test case (thường được tiến hành chéo). Trong dự án đề cập đã xây dựng hơn 300 testcase do 2 người viết. Số testcase này dự kiến được tính toán thực hiện trong 20-25 ngày

o Đợi đẩy bản build về yêu cầu test.o Khi có build về thì lập plan test (theo yêu cầu của bên đối tác mà chọn1

trong 2 loại) Test full : Kiểm tra hết Regresion test: chỉ theo những case cảm giác có lỗi. VD những case

test giao diện thì chỉ cần xem qua cũng phát hiện lỗi ko ? Tập trung vào test data.

Quá trình tạo plan (số lượng testcase): tính toán thời gian test cho 1 case là bao nhiêu (cho từng case tổng thể), số lượng người tham gia số lượng case của 1 người test trong 1 ngày số lượng ngày cần test là bao nhiêu?

38


o Gửi lại plan cho bên yêu cầu xem đã hợp lý chưa? Các kế hoạch test như vậy thường được thực hiện theo round.

o Tiến hành test: Tạo test serial: dùng hệ thống của đối tác để quản lý lỗi. TestScript sẽ

lưu toàn bộ testcase của tester và test serial. Tiến hành test:

Kết quả sẽ được lưu vào test serial Lưu lại hình ảnh của các bước Nếu có lỗi thì phải kiểm tra xem lỗi đã tồn tại chưa? (bằng hệ

thống) Nếu lỗi chưa tồn tại: thì tạo Devtask (1 loại lưu dạng lỗi), log

lỗi vào vào hệ thống Nếu lỗi đã tồn tại: refer đến Devtask

o Khi tiến hành xong 1 round sẽ tiến hành fix các version và lặp lại. Thỉnh thoảng đối tác đẩy 1 số Devtask về cho bên fsoft test kèm theo ver mới về với hai yêu cầu: Nếu mọi Devtask pass thì bên đối tác sẽ chọn 1 trong 2:

Regresion test: Unit test: Chỉ định 1 số cây cụ thể

Nếu test Devtask mà lỗi thì sẽ đặt tráng thái lỗi trong quá trình test đợi bên đối tác fix.

o Xong 1 round nếu bên đối tác ko hiểu Devtask thì sẽ gửi lại cho bên kiểm thử với trạng thái waiting information Test lại trả lời đối tác.

Chú ý:

o Tùy theo từng dự án mà có 1 quy trình riêng, templates riêng. Chuẩn tài liệu riêng

o Tùy theo từng dự án có sử dụng công cụ hỗ trợ kiểm thử riêng với dụ án. Trong dự án này sử dụng công cụ BT để hỗ trợ kiểm thử. Tuy nhiên trong Fsoft cũng sử dụng một hệ thống chuẩn để quản lý lỗi gọi là DMS (defect manager system)

o Phần bảo trì là do Developer thực hiện, không do tester thực hiện

39


B: THÔNG TIN VỀ CÔNG TY KHẢO SÁT MISA Tên công ty: Công ty cổ phần MISA

Thông tin liên hệ:

o Website: http://www.misa.com.vn/o Địa chỉ: Khách sạn La Thành: 218 Đội Cấn, Q. Ba Đình, Tp.Hà Nộio Email: [email protected] Điện thoại/Fax: Tel:+84(4) 3 762 7981 Fax: +84 (4) 3 762 9746o Thông tin khác:

Chức năng:

o Cung cấp các phần mềm đóng gói về kế toán Quy mô: Phòng kiểm soát chất lượng hiện tại có 30 người

THÔNG TIN VỀ CÔNG VIỆC Công việc của người khảo sát

o Trưởng phòng kiểm soát chất lượng. Chịu trách nhiệm nhận các dự án, chuẩn bị nhân lực cho các dự án đó. Đồng thời chịu trách nhiệm đào tạo nhân lực cho phòng.

Quy trình kiểm thử và bảo trì:o Cơ cấu tổ chức phòng kiểm soát chất lượng

1 trưởng phòng: đào tạo nhân viên(kĩ năng), điều phối nhân sự cho các dự án(),

1 phó phòng: trợ lý cho trưởng phòng về công tác nghiệp vụ tài chính kế toán.

Trưởng nhóm: phụ trách dự án liên quan đến hành chính sự nghiệp, (phụ trách dự án liên quan đến tài chính kế toán) Là người trực tiệp lập kế hoạch cho một dự án.

Các nhóm: theo dự án (dự án nhỏ trong 1 lĩnh vực lớn ở trên)o 2 loại dự án:

Dự án bảo trì Dự án mới

o 1 team 3 người.o 1 leader.

mailto:[email protected]

http://www.misa.com.vn/

40


o Quy trình kiểm thử: Chia thành nhiều phase. Với mỗi phase tuân theo các quy chuẩn: Lập kế hoạch test:

Work Break down. (Chia công việc thành các công việc nhỏ): Mã công việc, tên công việc, phân loại công việc… đến mức chi tiết. (teamleader)

Work Estimate: một công việc chia nhỏ mất bao nhiêu giờ, xác định resource xác định resource cho phase trong dự án. (team leader)

Review kế hoạch dự án: Trưởng phòng và trưởng dự án. Design testcase (trưởng dự án làm)

Đầu vào: Tài liệu của bên tư vấn nghiệp vụ bản thiết kế của bên phát triển phần mềm

Đầu ra: Các tình huống có thể xẩy ra với 1 chức năng: Số liệu đầu vào Hành động thực hiện. Kết quả kì vọng (kết quả đúng) Kết quả thực tế. (chức năng không thành công/thành công) Người design, người modify, ai add.

Testcase đuợc lưu trên file exel. (test suite). do người dùng quản lý. (form – chức năng sheet)

Review testcase: Các bước Mời đại diện các bên, trưởng phòng, trưởng dự án review Nếu ok: Gửi lại biên bản chấp nhận Nếu ko ok: Biên bản chưa ổn, sửa lại gửi lại triển khai

Kiểm tra theo testcase Leader chia việc cho các thành viên trong nhóm Tiến hành thực hiện test sản phẩm dựa trên testcase… Đầu vào: gửi email, chỉ ra đường dẫn đến bộ cài đóng gói của release …

(ver) Quy trình xử lý lỗi:

Kiểm soát chất lượng: Post lỗi lên hệ thống: Trưởng dự án (pm) chuyển lỗi cho người có trách nhiệm sửa. (resovle) Sau khi người có trách nhiệm sửa đã fix lỗi này: cán bộ kiểm soát

chất lượng kiểm tra lỗi đã được fix chưa Close lỗi

41


Reopen() yêu cầu mở lại Bàn giao sản phẩm

o Các công cụ sử dụng hỗ trợ quá trình kiểm thử phần mềm:

Caliber : Quản lý requirement

User requirement

Software requirement

Jira: Công cụ quản lý bug (bug tracking)

Exel: Thiết kế testcase, quản lý testcase, checklist.

Microsoft project: Hỗ trợ quản lý công việc của nhân viên.

Source vault : Quản lý tài liệu

2. Bài học kinh nghiệm và đánh giá kết luận của nhóm Trong quá trình tìm hiểu đề tài, cả nhóm chúng em đã rút ra được những bài

học và kết luận sau:

Kiểm thử là quá trình vô cùng quan trọng trong vòng đời phát triển một phần mềm. Đây là những quá trình không thể thiếu trong việc phát triển một phần mềm thương mại.

Kiểm thử phần mềm có nhiều kĩ thuật khác nhau, và thực tế các công ty trên địa bàn Hà Nội cũng chỉ sử dụng các kĩ thuật đó trong công việc của mình. Tuy nhiên, dựa trên đặc thù của từng công ty, việc bảo trì, kiểm thử phần mềm sẽ có những đặc điểm khác nhau. Ví dụ như kiểm thử hộp trắng chỉ được Fsoft sử dụng với các chương trình nhỏ như lập trình mobile, còn các hệ thống lớn thì không sử dụng. Còn với MISA chỉ sử dụng kiểm thử hộp đen trong quá trình kiểm thử và cho rằng đây là phương pháp kiểm thử thích hợp nhất đối với công ty mình.

42


Trong thực tế, khi một tổ đội xây dưng phần mềm chưa nhiều, và còn hạn hẹp về mặt quân số cũng như chất lượng, một số công ty không tách chuyên biệt các cá nhân vào trong một nhóm (một phòng) quản lý chất lượng phần mềm. Các công ty sử dụng việc đa nhiệm vụ cho một cá nhân. Từ đó cũng nâng cao được chất lượng, thời gian kiểm thử. Tuy nhiên những phương pháp đó không áp dùng được với các phần mềm hệ thống lớn. Do người kiểm thử và người lập trình là một nên không mở rộng được các góc nhìn, không có các đánh giá chuẩn xác, khách quan về phần mềm cần kiểm thử, bảo trì. Bên cạnh đó, nếu quá trình phát triển phần mềm , kiểm thử phần mềm không được tách ra chuyên biện, lập trình viên sẽ bị trồng chéo công việc dễ bị nhầm lẫn.

Trong quá trình xây dựng và phát triển phần mềm, việc sử dụng công cụ hỗ trợ là vô cùng cần thiết. Có những công cụ hỗ trợ sử dủng rất đơn giản như exel, word ..vv . Điểm quan trọng là cần biết phối hợp các công cụ này với công việc đặc thù của công ty mình.

43


TÀI LIỆU THAM KHẢO

Slide bài giảng của TS.Vũ Hương Giang.

The Art of Software Testing - Glenford J. Myers.

McGraw Hill - Software Engineering - A Practitioner's Approach – Press Man – 5th Edition – 2001.

Bài giảng điện tử “Kiểm thử và bảo đảm phần mềm” – Thạc Bình Cường – ĐHBKHN.

Education

TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM