Tìm hiểu quy trình kiểm thử phần mềm và xây dựng ứng dụng minh họa

Nước ta đang trong quá trình xây dựng một ngành công nghiệp phần mềm thì không thể xem nhẹ việc kiểm thử phần mềm vì xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm c

KHOA CÔNG NGHỆ THÔNG TIN

-

TRẦN THỊ THẢO

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC

Đề tài:

TÌM HIỂU QUY TRÌNH KIỂM THỬ PHẦN MỀM VÀ

XÂY DỰNG ỨNG DỤNG MINH HỌA

KHOA CÔNG NGHỆ THÔNG TIN

-

BÁO CÁO

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC

Đề tài:

TÌM HIỂU QUY TRÌNH KIỂM THỬ PHẦN MỀM VÀ

XÂY DỰNG ỨNG DỤNG MINH HỌA

Sinh viên thực hiện: Trần Thị Thảo

Mã sinh viên: 0851070249

Lớp: 49K -Tin

Giáo viên hướng dẫn: ThS Nguyễn Công Nhật

Nghệ An, tháng 12 năm 2012

LỜI CẢM ƠN

Để hoàn thành đồ án này, em đã nhận được sự quan tâm, chỉ bảo nhiệt tình của thầy giáo hướng dẫn, các thầy cô trong khoa, các anh chị trong công ty TNHH phần mềm FPT tại Đà Nẵng và sự động viên của gia đình, bạn bè Với lòng biết ơn chân

thành và sâu sắc nhất em xin trân trọng cảm ơn thầy giáo Nguyễn Công Nhật, người

đã tận tình hướng dẫn và giúp đỡ em hoàn thành đồ án này Em xin trân trọng cảm ơn các thầy, cô giáo trong khoa Công Nghệ Thông Tin của trường Đại Học Vinh đã tận tình chỉ bảo, giúp đỡ em trong suốt thời gian học đại học và trong quá trình thực hiện

MỤC LỤC

Trang

LỜI CẢM ƠN 1

LỜI NÓI ĐẦU 4

CHƯƠNG 1: CƠ SỞ LÝ THUYẾT 6

1.1 Tìm hiểu về quy trình kiểm thử phần mềm 6

1.1.1 Sản phẩm phần mềm là gì? 6

1.1.2 Kiểm thử phần mềm là gì? 6

1.1.3 Quy trình kiểm thử phần mềm 8

1.2 Các loại kiểm thử phần mềm 10

1.2.1 Test Plan ( Kế hoạch kiểm thử) 10

1.2.1.1 Khái niệm 10

1.2.1.2 Quy trình Test Plan 10

1.2.1.3 Mẫu tài liệu của Test plan 11

1.2.2 Test case ( Kiểm thử các trường hợp) 17

1.2.2.1 Khái niệm 17

1.2.2.2 Mục đích của việc tạo test case 17

1.2.2.3 Các thành phần của test case 18

1.2.2.4 Một số tài liệu mẫu về viết test case và lời khuyên để viết test case tốt 20

1.2.3 Test report (Báo cáo kiểm thử) 22

1.2.3.1 Khái niệm 22

1.2.3.2 Tìm hiểu về các loại lỗi và đánh giá kết quả kiểm thử tạo biểu đồ trong test report 23

1.2.3.3 Một số tài liệu mẫu tạo test report 28

CHƯƠNG 2: ỨNG DỤNG TẠO TEST CASE – CHỤP EVIDENCE – TẠO TEST REPORT CHO CHỨC NĂNG THÊM BẠN BÈ (ADD CONTACT) CỦA PHẦN MỀM SKYPE 30

2.1 Đặc tả chức năng thêm bạn bè (Add contact) của phần mềm Skype 30

2.1.1 Giới thiệu về phần mềm Skype 30

2.1.2 Đặc tả chức năng thêm bạn bè (Add contact) của phần mềm Skype 31

2.2 Tạo testcase cho chức năng thêm bạn bè (Add contact) của phần mềm skype 32

2.3 Chụp Evidence cho các kết quả kiểm thử theo từng test – case viết cho chức năng thêm bạn bè (Add contact) của phần mềm skype 36 2.3.1 Khái niệm chụp evidence 36 2.3.2 Mẫu chụp Evidence cho các kết quả kiểm thử theo từng test – case viết cho chức năng thêm bạn bè (Add contact) của phần mềm skype 36 2.4 Tạo test report cho chức năng thêm bạn bè (Add contact) của phần mềm skype 47 KẾT LUẬN 48 TÀI LIỆU THAM KHẢO 49

LỜI NÓI ĐẦU

Với sự phát triển như vũ bão của công nghệ thông tin nói chung và công nghệ phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi nhiều công

cụ tiên tiến, giúp cho việc xây dựng phần mềm đỡ mệt nhọc và hiệu quả hơn Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn về thời gian và chi phí, cho dù các hoạt động đảm bảo chất lượng phần mềm nói chung và kiểm thử nói riêng ngày càng chặt chẽ và khoa học, vẫn không đảm bảo được rằng các sản phẩm phần mềm đang được ứng dụng không có lỗi Lỗi vẫn luôn tiềm ẩn trong mọi sản phẩm phần mềm và cũng có thể gây những thiệt hại khôn lường

Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng Các kỹ thuật kiểm thử phần mềm đã, đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành qui trình bắt buộc trong các dự án phát triển phần mềm trên thế giới Kiểm thử phần mềm là một hoạt động rất tốn kém, mất thời gian, và khó phát hiện được hết lỗi Vì vậy, việc kiểm thử phần mềm đòi hỏi phải có chiến lược phù hợp, một kế hoạch hợp lý và việc thực hiện được quản lí chặt chẽ

Ở Việt Nam, trong thời gian qua việc kiểm thử phần mềm bị xem nhẹ, với công

cụ lập trình hiện đại, người ta cảm tính cho rằng không kiểm thử cũng không sao, nên chưa có nhiều sự quan tâm, nghiên cứu Những năm gần đây, một số tổ chức nghiên cứu và phát triển phần mềm đã bắt đầu có những quan tâm hơn đến vấn đề kiểm thử phần mềm Tuy nhiên, vấn đề kiểm thử phần mềm hầu như vẫn chưa được đầu tư và quan tâm đúng mức Nước ta đang trong quá trình xây dựng một ngành công nghiệp phần mềm thì không thể xem nhẹ việc kiểm thử phần mềm vì xác suất thất bại sẽ rất cao, hơn nữa, hầu hết các công ty phần mềm có uy tín đều đặt ra yêu cầu nghiêm ngặt

là nếu một phần mềm không có tài liệu kiểm thử đi kèm thì sẽ không được chấp nhận

Trong một quy trình sản xuất phần mềm, ngoài việc thành lập các chuẩn coding, phân công sắp xếp các công việc cho các thành viên trong tổ chức, quản lý các tài liệu như các bản đặc tả yêu cầu, bản phân tích thiết kế chương trình, chương trình nguồn, thì một yếu tố cũng rất quan trọng là hỗ trợ quản lý tiến trình kiểm thử bao gồm hỗ trợ quản lý các trường hợp kiểm thử, các bản báo cáo kiểm thử, các lỗi

Vì vậy em đã thực hiện đề tài: " Tìm hiểu về quy trình kiểm thử phần mềm và xây dựng ứng dụng minh họa " nhằm hiểu rõ tiến trình kiểm thử, các loại kiểm thử,

cách kiểm thử, việc quản lý kiểm thử, những mục tiêu, thuận lợi mà tiến trình này đem lại

Đồ án của em được chia làm 2 chương gồm:

- Chương 1: Cơ sở lý thuyết : tìm hiểu về quy trình kiểm thử phần mềm và các loại kiểm thử phần mềm

- Chương 2: Ứng dụng kiểm thử trên modul add contact của phần mềm skype với bản mẫu được sử dụng dựa vào bản mẫu trong kiểm thử viết cho thị trường nhật tại công ty TNHH FPT software chi nhánh tại Đà nẵng

- Tổng kết

- Phụ lục

Tuy nhiên do thời gian có hạn và kinh nghiệm của bản thân chưa nhiều nên đề tài không tránh khỏi những hạn chế và thiếu sót Em rất mong nhận được những ý kiến góp ý và chỉ bảo thêm của các thầy giáo, cô giáo và toàn thể các bạn để đề tài này có thể phát triển và hoàn thiện hơn

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

Sinh viên thực hiện

Trần Thị Thảo

CHƯƠNG 1: CƠ SỞ LÝ THUYẾT 1.1 Tìm hiểu về quy trình kiểm thử phần mềm

1.1.1 Sản phẩm phần mềm là gì?

Phần mềm là một chương trình được cài đặt trên máy tính nhằm thực hiện một nhiệm vụ tương đối độc lập nhằm phục vụ cho một ứng dụng cụ thể việc quản lý họat động của máy tính hoặc áp dụng máy tính trong các họat động kinh tế, quốc phòng, văn hóa, giáo dục, giải trí…

Việc tạo ra một sản phẩm phần mềm phải trải qua nhiều giai đoạn, người ta gọi

là quy trình phát triển phần mềm, bắt đầu từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản phẩm phần mềm Khối lượng công việc trong từng giai đoạn của quá trình sản xuất phần mềm cũng thay đổi theo thời gian

Giai đoạn

Phân tích yêu cầu

Thiết

kế sơ

bộ

Thiết kế chi tiết

Lập trình

và kiểm thử đơn vị

Tích hợp

và kiểm thử tích hợp

Kiểm thử hệ thống

Tỉ lệ công việc của các giai đoạn phát triển phần mềm

Như vậy, một sản phẩm phần mềm không chỉ đơn giản là các đoạn mã chương trình mà còn rất nhiều phần ẩn đằng sau nó Vì vậy, việc mắc lỗi không chỉ xảy ra trong khi lập trình mà còn xảy ra cao hơn trong các công đoạn khác của qui trình phát triển một sản phẩm phần mềm Việc kiểm thử cũng vì thế phải được tiến hành trong tất

cả các phần tạo nên một sản phẩm phần mềm

1.1.2 Kiểm thử phần mềm là gì?

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau

Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát hiện Tuy nhiên, có nhiều bối cảnh kiểm thử không bộc lộ ra lỗi Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không

Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một cách sớm nhất và đảm bảo rằng lỗi đã được sửa, mà kiểm thử phần mềm không làm công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi

Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công sức

và chi phí

Kiểm thử và sửa lỗi có thể được thực hiện tại bất kỳ giai đoạn nào của vòng đời phần mềm Quá trình kiểm thử là việc kiểm tra phần mềm sau khi được tạo ra đã đúng theo các đặc tả và yêu cầu của khách hàng hay chưa (đi tìm lỗi và kiểm tra các chức năng đã đúng theo theo các yêu cầu mà khách hàng mong muốn)

Trong quy trình phát triển phần mềm thì giai đoạn kiểm thử phần mềm là một trong những giai đoạn quan trọng và then chốt trong việc tạo ra phần mềm

Quy trình phát triển phần mềm

1.1.3 Quy trình kiểm thử phần mềm

a Lập kế hoạch kiểm thử

- Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra Yêu cầu kiểm tra cũng được dùng

để xác định nhu cầu nhân lực

- Xây dựng kế hoạch kiểm thử tổng thể, đưa ra các mẫu tài liệu kiểm thử cho các cấp độ kiểm thử khác nhau Liệt kê các công việc cần thực hiện và các tài liệu cần thiết, cũng như các nhân lực sẽ thực thi các công việc

Lập kế hoạch kiểm thử

Thiết kế các tình huống, các kịch bản kiểm thử

Phát triển các kịch bản kiểm thử tự động

Tiến hành kiểm thử

Xác định lỗi

Đánh giá kết quả kiểm thử Chuẩn bị môi trường kiểm thử

b Thiết kế các tình huống kiểm thử, các kịch bản kiểm thử

- Dựa vào các yêu cầu, các tính năng của sản phẩm, các cấp độ kiểm thử đã xác định trong kế hoạch kiểm thử, xác định các tình huống kiểm thử cần thiết trong từng cấp Thiết kế các kịch bản kiểm thử (một chuỗi các tình huống kiểm thử có quan hệ với nhau) nhằm kiểm thử các tình huống sử dụng xác định

c Phát triển các kịch bản kiểm thử tự động

- Bước này thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các đoạn mã có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở bước thiết kế kiểm thử

d Chuẩn bị môi trường kiểm thử

- Cài đặt hệ điều hành, các phần mềm cần thiết, cài đặt hệ thống trên các máy tính vật lý hoặc máy ảo Tiến hành sao lưu toàn bộ hệ thống thành file ảnh để có thể phục hồi lại trạng thái ban đầu khi cần

- Sau khi kết thúc, kết quả kiểm tra cần được xem xét để bảo đảm kết quả nhận được là đáng tin cậy, cũng như nhận biết được những lỗi xảy ra không phải do phần mềm mà do dữ liệu dùng để kiểm tra, môi trường kiểm tra hoặc các bước kiểm tra (hoặc các đoạn mã kịch bản kiểm thử) gây ra Nếu thực sự lỗi xảy ra do quá trình

kiểm tra, cần phải sửa chữa và kiểm tra lại từ đầu

g Đánh giá kết quả kiểm thử

- Đá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, liệt kê lỗi, chỉ định các yêu cầu thay đổi và tính toán các số liệu liên quan đến quá trình kiểm tra (chẳng hạn số giờ, thời gian kiểm tra, số lượng lỗi, phân loại lỗi )

- Tổng hợp kết quả các bước ở trên và lập báo cáo kết quả kiểm thử gửi cho tất

cả những người có liên quan Báo cáo ở bước này phải là báo cáo mang tính toàn cục của hệ thống

- Requirements/ Scope

- Specified (what will be test?)

- Test Estimation Test Plan

Project plan( kế hoạch dự án): trả lời cho câu hỏi những thông tin nào cần nhận được?

- Khi các yêu cầu đặc điểm kỹ thuật đầy đủ và sẵn sàng

- Khi có các thiết kế chi tiết

- Khi giai đoạn đầu tiên của việc kiểm thử có thể bắt đầu

- Ngày bắt đầu thực hiện dự án

Customer requirements and Acceptance criteria (những yêu cầu của khách hàng và tiêu chí chấp nhận)

- SRS (Software Requirement Specification): Tài liệu đặc tả phần mềm

- Đưa ra những tiêu chí để phần mềm được chấp nhận

Test plan document (tài liệu kế hoạch kiểm thử) được dùng để:

- Xác định những thông tin dự án và các phần dự án cần được kiểm thử

- Liệt kê những yêu cầu kiểm thử (Test Requirements)

- Nêu ra những phương pháp, chiến lược kiểm thử nên sử dụng

- Xác định nguồn lực cần và tính công

- Liệt kê những kết quả, tài liệu có được sau khi thực hiện kiểm thử

1.2.1.3 Mẫu tài liệu của Test plan

1 Giới thiệu

1.1 Mục đích

- Những vấn đề chính trong chiến lược test là các kỹ thuật được áp dụng và điều kiện để biết khi nào việc test được hoàn thành

- Mô tả các kiểu test dùng trong dự án

- Liệt kê với mỗi kiểu test tương ứng test cho chức năng nào

- Việc test có thể dừng khi nào

+ Unit Test – kiểm thử mức đơn vị: bảo đảm thông tin được xử lý và xuất đưa

ra 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 từng đơn vị thành phần nhỏ nhất của phần mềm Unit Test thường thường do lập trình viên thực hiện trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script) + Integration Test – kiểm thử tích hợp: 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 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

+ System Test - kiểm thử mức hệ thống: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 ngay sau Integration Test,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

+ Acceptance Test - kiểm thử chấp nhận sản phẩm: 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 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 (và trả tiền thanh toán hợp đồng)

Đã nhận được

Người tạo / Nguồn Ghi chú

Tài liệu mô tả

yêu cầu

Requirements

Specification

 Có  Chưa

 Có  Chưa

Tài liệu mô tả

chức năng

Functional

Specification

 Có  Chưa

 Có  Chưa

Tài liệu kế

hoạch dự án

 Có  Chưa

 Có  Chưa Tài liệu phân

tích thiết kế

 Có  Chưa

 Có  Chưa Tài liệu hướng

dẫn sử dụng

 Có  Chưa

 Có  Chưa

2 Yêu cầu kiểm thử

- Chỉ ra những hạng mục (yêu cầu chức năng, yêu cầu hệ thống, yêu cầu ngòai chức năng ) cần phải kiểm thử

- Mô tả những hạng mục kiểm thử

3 Chiến lược kiểm thử

- Chiến lược kiểm thử (Test Strategy) trình bày những phương pháp để kiểm thử các ứng dụng phần mềm Ở phần Yêu cầu kiểm thử thì mô tả những thứ cần được kiểm thử còn phần Chiến lược kiểm thử nêu ra những cách được dùng để kiểm thử

- Kỹ thuật và tiêu chuẩn đánh giá là những nội dung chính cần quan tâm

3.1 Các loại kiểm thử

Bảng các lọai kiểm thử có thể tiến hành và phục vụ cho các mục đích khác nhau thông qua các giai đọan của dự án

Giai đọan Unit Test Integration Test System Test

Giai đoạn 1 Liệt kê những lọai

hình (cách thức) kiểm thử trong giai đọan này

Liệt kê những lọai hình (cách thức) kiểm thử trong giai đọan này

Liệt kê những lọai hình (cách thức) kiểm thử trong giai đọan này

Giai đọan 2

- Các loại kiểm thử thường được sử dụng

+ Kiểm thử chức năng (Functional Test)

+ Kiểm thử hiệu năng (Performance Test)

+ Kiểm thử khả năng chịu tải (Stress Test)

+ Kiểm thử an ninh và kiểm soát quền truy cập (Security and Access Control Testing)

+ Kiểm thử đệ quy (Regression Testing)

+ Kiểm thử khả năng chịu tải (Stress Test hay Load Test)

+ Kiểm thử cấu hình (Configuration Test)

+ Kiểm thử trường hợp khi dữ liệu lớn (volume testing)

+ Kiểm thử dữ liệu và kiểm tra tính toàn vẹn cơ sở dữ liệu (Data and database integrity testing) …

- 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

Nhân viên kiểm thử

Thực hiện việc kiểm thử Nhiệm vụ:

Máy chủ CSDL (Database Server)

5 Thời gian kiểm thử

Kế họach

Thực hiện kiểm thử

Đánh giá kết quả kiểm thử

1.2.2 Test case ( Kiểm thử các trường hợp)

1.2.2.2 Mục đích của việc tạo test case

Test case là điều kiện để tester quyết định xem liệu một yêu cầu của ứng dụng

có được thỏa mãn các điều kiện Test case là tài liệu được sử dụng trong kiểm thử, Tester chuẩn bị nó càng nhiều càng tốt để kiểm thử các chức năng của ứngdụng Sau đây là mục đích của việc viết TestCase:

- Test case sẽ nói lên những bước nào của yêu cầu nên thực hiện để chắc rằng các yêu cầu được thực hiện theo như kế hoạch

- Test case giữ gìn các dữ liệu test và các tester luôn luôn biết dữ liệu nào nên sử dụng trước khi test

- Test case là kiến thức cơ bản từ yêu cầu Khi các tester thay đổi các đặc thù của công việc test, hầu như họ sẽ không cần phải chuyển giao lại kiến thức

- Test case là cách tốt nhất để chuyển cho các tester mới bằng cách nào để test các yêu cầu

- Tình trạng của test case là phải chính xác để QA lead biết cái gì của ứng dụng

sẽ được test và cái gì không được test, phần nào nhiều lỗi, và đặc thù nào là ít lỗi sau

1.2.2.3 Các thành phần của test case

………

USER_MGT_Delete_01 USER_MGT_Delete_02 USER_MGT_Delete_03

……

USER_MGT_Login_01

b Test case description (mô tả các trường hợp kiểm thử)

- Mô tả mục tiêu hoặc điều kiện cần kiểm thử cái gì?

- Mô tả tóm tắt trường hợp cần kiểm thử cho một trường hoặc chức năng của một mô-đun nào đó

Ví dụ: Chức năng tạo mới người dùng

Mô tả các trường hợp của chức năng thêm mới người dùng thêm người dùng thành công hoặc không thể thêm người sử dụng với các ký tự đặc biệt hoặc không thể thêm người dùng mà tên người dùng đã tồn tại hoặc không thể thêm người sử dụng mà không có email

c Test case procedure (Các bước thực hiện)

- Một tập hợp các bước / hành động cần phải được chạy, thực hiện để hoàn thành một mục tiêu hay điều kiện của một chức năng hoặc mô-đun cho một trường hợp kiểm thử được mô tả ở trên

- Mô tả các bước để thực hiện một test case nào đó

Ví dụ: Các bước thực hiện cho trường hợp được mô tả “Thêm người dùng thành công”

1 Trên màn hình danh sách người dùng, bấm vào nút [+]

2 Đầu vào tên người dùng chưa tồn tại (Ví dụ: “test”)

3 Nhập Họ, tên, email (Ví dụ: “test”, testinsight@fsoft.com.vn)

4 Sử dụng các giá trị khác theo mặc định và nhấp chuột vào nút [Save]

d Expected Output (Kết quả đầu ra theo dự kiến)

- Một tập hợp các đầu ra / kết quả theo dự kiến của các bước được thực hiện ở trên

Ví dụ: Đầu ra các kết quả dự kiến của từng bước cho trường hợp được kiểm thử “ Thêm mới người dùng thành công ”

1 Hiển thị màn hình thêm mới người dùng

2-4 Người dùng tên “Test” được hiển thị trong danh sách người dùng với thứ tự

của số lượng, danh sách tên người dùng tăng lên 1

e Inter-test case Dependence (Kiểm tra các trường hợp phụ thuộc)

- Một hoặc nhiều trường hợp kiểm thử là đầu vào cho những trường hợp kiểm thử khác Nếu các trường hợp kiểm thử trước bị chặn thì không thể chạy các trường hợp tiếp theo

Ví dụ: Kiểm thử cho trường hợp có tên mô tả “ Thêm mới người dùng thành công ” thì điều kiện trước khi hiển thị màn hình thêm mới người dùng thì phải hiển thị nút [+] trên màn hình danh sách người dùng

1.2.2.4 Một số tài liệu mẫu về viết test case và lời khuyên để viết test case tốt

a Một số tài liệu mẫu về viết test case

Mẫu 1:

Mẫu 2:

b Lời khuyên giúp cho việc viết test case tốt

Để viết được các Test case tốt cần nhớ 5 lời khuyên sau đây:

1 Cấu trúc của test case phải rõ ràng và hợp lý

2 Thực hiện theo yêu cầu chặt chẽ

3 Bao gồm tất cả các trường hợp có thể xảy ra

4 Tiêu đề dễ hiểu và bao gồm yêu cầu (như người sử dụng, tôi có thể làm hoặc không thể làm )

1.2.3 Test report (Báo cáo kiểm thử)

1.2.3.1 Khái niệm

Test Report là tài liệu báo cáo kết quả thực hiện kiểm thử, các tester sẽ điền kết quả test vào test case và tạo báo cáo kết quả test và cho biết phần mềm đã test có sẵn sàng để bàn giao cho khách hàng hay chưa (việc này là ứng với system test, còn đối với những cấp nhỏ hơn thì việc “phát hành” được hiểu như là màn hình hoặc modul

đã test là sạch lỗi)

- Báo cáo kết quả kiểm thử thật sự

đối chiếu với test plan

- Đưa ra đánh giá, kết luận về độ tin

Mục đích của test report

- Test Manager hoặc Test Leader sử dụng test report để phân tích các lỗi và theo dõi lỗi trong hệ thống

- Đá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

Để xây dựng các biểu đồ, tính phần trăm tỷ lệ các trường hợp kiểm thử đã được thực hiện hay chưa thực hiện, mô-đun đã chạy đã đúng theo các yêu cầu trong test report dựa vào các trạng thái thực hiện test case sau:

- Passed/OK : Thực tế chương trình khi chạy có kết quả đáp ứng yêu cầu

- Failed/NOK/NG : Kết quả thực tế của chương trình không đáp ứng yêu cầu

- Blocked : Có thể không được thực hiện vì điều kiện trường hợp kiểm thử trước bị

lỗi

- NA/Skipped : Không áp dụng trên phạm vi kiểm thử ( dữ liệu lớn, phần cứng không đảm bảo đủ điều kiện để thự hiện…)

Test report

- Not Tested : Không thực hiện kiểm thử được

1.2.3.2 Tìm hiểu về các loại lỗi và đánh giá kết quả kiểm thử tạo biểu đồ trong

test report

a Tìm hiểu về các loại lỗi

i Kiểu lỗi

1 Chức năng Hàm đặc tả không hoạt động

2 Giao diện người sử dụng Các lỗi trên giao diện

3 Thực hiện Tốc độ xử lý chậm,vấn đề bộ

nhớ,

4 Thiết kế Các vấn đề liên quan đến thiết

kế chi tiết

5 Chuẩn viết code

Vấn đề với các chuẩn viết code như: căn lề, hiển thị, chú

thích,

6 Lỗi tài liệu

Lỗi tìm thấy khi review tài liệu:

kế hoạch dự án, bản đặc tả yêu cầu, kế hoạch test,

7 Tích hợp dữ liệu và cơ sở Vấn đề xử lý dữ liệu hoặc

luồng

8 Điều khiển bảo mật và truy cập Vấn đề về bảo mật, phân quyền

sử dụng

9 Hiệu suất Chậm dần, không phản ứng

như thời gian dự kiến

10 Các kiểu khác Không thuộc các kiểu trên