1. Trang chủ
  2. » Luận Văn - Báo Cáo

thiết kế và xây dựng quy trình kiểm thử tự động

33 1,1K 2

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 33
Dung lượng 842,24 KB

Nội dung

Tình hình nghiên cứu Trong quy trình công nghệ phần mềm, kiểm thử chiếm khoảng 40% khối lượng công việc và là khâu quyết định chất lượng cũng như uy tín của phần mềm, tuy nhiên kiểm thử

Trang 1

MỤC LỤC

MỞ ĐẦU……… 2

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ VÀ KIỂM THỬ TỰ ĐỘNG 5

1.1 Chất lượng phần mềm và kiểm thử phần mềm 5

1.1.1 Vòng đời phát triển phần mềm và kiểm thử 5

1.1.2 Kiểm thử phần mềm và chất lượng phần mềm 8

1.1.3 Các giai đoạn kiểm thử và điểm xác định 9

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

1.2 Kiểm thử tự động 10

1.2.1 Khái niệm về kiểm thử tự động: 10

1.2.2 Mục tiêu 10

CHƯƠNG 2 MỘT SỐ QUY TRÌNH KIỂM THỬ TỰ ĐỘNG 13

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

2.2 Khái quát về quy trình kiểm thử tự động 20

2.3 Các bước cơ bản của quá trình KTTĐ: 22

CHƯƠNG 3 CÔNG CỤ KIỂM THỬ TỰ ĐỘNG 24

3.1 Tổng quan về công cụ kiểm thử tự động 24

3.1.1 Công cụ kiểm thử tự động mã trình 24

3.1.2 Công cụ kiểm thử tự động dữ liệu 24

3.1.3 Công cụ kiểm thử tự động cài đặt 25

3.2 Giới thiệu và đánh giá một số công cụ KTTĐ 25

3.2.1 QuickTest Pro 26

3.2.2 Load Runner 30

KẾT LUẬN ……… 32

TÀI LIỆU THAM KHẢO 33

Trang 2

MỞ ĐẦU

1 Lý do chọn đề tài

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 đỡ vất vả 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ẽ

Kiểm thử tự động là một lĩnh vực nhằm thu hút được lợi ích tối đa với nỗ lực tối thiểu đối với các công việc lặp đi lặp lại Lợi ích tối đa ở đây chính là khả năng gia tăng hiệu quả các nguồn nhân lực, gia tăng độ bao phủ của việc kiểm thử, nâng cao chất lượng và độ tin cậy của phần mềm Với những quy trình phần mềm hiện đại, thời gian sản xuất phần mềm ngày càng ngắn, trong khi chi phí về nhân lực cũng như kinh tế ngày càng thấp đòi hỏi việc tự động hóa trong quá trình sản xuất phần mềm Kiểm thử tự động trở thành một yêu cầu bức xúc với các công ty sản xuất phần mềm hiện nay Chính vì lý do đó, tôi mong muốn tìm hiểu về “Kiểm thử

tự động” nhằm đưa ra những cái nhìn khái quát về loại hình kiểm thử này

2 Tình hình nghiên cứu

Trong quy trình công nghệ phần mềm, kiểm thử chiếm khoảng 40% khối lượng công việc và là khâu quyết định chất lượng cũng như uy tín của phần mềm, tuy nhiên kiểm thử phần mềm chưa được coi trọng trong các nền công nghiệp phần mềm nhỏ, chẳng hạn như Việt Nam Việc áp dụng các kỹ thuật kiểm thử còn mang tính cục bộ ở các công ty phần mềm và quá trình kiểm thử hầu như được thực hiện một cách thủ công gây ra hạn chế trong việc phát hiện lỗi, cũng như thời gian hoàn thành dự án; Kiểm thử tự động đang trở thành xu thế của ngành công nghiệp phần

Trang 3

mềm, do vậy việc nghiên cứu lý thuyết, quy trình cũng như tìm hiểu, đánh giá các công cụ kiểm thử tự động đang là một đòi hỏi bức thiết Trong phạm vi đề tài của mình, tôi mong muốn đưa ra cái nhìn tổng quan về kiểm thử tự động, quy trình thực hiện và việc lựa chọn sử dụng công cụ kiểm thử tự động phù hợp

3 Mục đích nghiên cứu

Nghiên cứu về kiểm thử, đặc biệt là vấn đề kiểm thử tự động (KTTĐ) nhằm tìm hiểu những lý thuyết cơ bản về KTTĐ, quy trình KTTĐ và nghiên cứu đánh giá một số công cụ KTTĐ đang được sử dụng hiện nay

Trau dồi kiến thức về kiểm thử, đặc biệt là xu hướng kiểm thử phần mềm hiên nay nhằm phục vụ cho việc giảng dạy học phần “Nhập môn Công nghệ phần mềm”

4 Đối tượng nghiên cứu

 Lý thuyết kiểm thử và đánh giá chất lượng phần mềm, vai trò, nhiệm vụ của

giai đoạn kiểm thử trong một số quy trình phần mềm

 Kiểm thử tự động và quy trình kiểm thử tự động

Một số công cụ kiểm thử tự động

5 Phạm vi nghiên cứu

 Lý thuyết cơ bản về quy trình phần mềm, kiểm thử và vai trò của kiểm thử trong quy trình phần mềm

 Kiểm thử tự động, quy trình kiểm thử tự động

 Nghiên cứu, thực nghiệm và đánh giá một số công cụ kiểm thử tự động

6 Phương pháp nghiên cứu

Trong quá trình thực hiện đề tài tôi đã sử dụng những phương pháp nghiên cứu sau:

 Phương pháp tư liệu: Thu thập và phân tích các tài liệu liên quan đến quy trình phần mềm, kiểm thử và KTTĐ

 Phương pháp thực nghiệm: Tìm hiểu QTP, cài đặt và đánh giá phần mềm

7 Đóng góp của đề tài

Tổng hợp lý thuyết liên quan đến kiểm thử, kiểm thử tự động; Tìm hiểu quy trình kiểm thử tự động khi áp dụng vào dự án phần mềm Nghiên cứu và đánh giá một số công cụ kiểm thử tự động

8 Bố cục

Đề tài gồm 3 chương

Trang 4

Chương 1 Tìm hiểu lý thuyết chung về kiểm thử, đưa ra 1 số quy trình phần mềm phổ biến để đánh giá vai trò của kiểm thử, tính cần thiết của kiểm thử tự động

Chương 2 Đưa ra những kiến thứ cơ bản về quy trình kiểm thử tự động Chương 3 Nghiên cứu, phân loại và đánh giá một số công cụ kiểm thử tự động

Kết luận

Trang 5

CHƯƠNG 1 TỔNG QUAN VỀ KIỂM THỬ VÀ KIỂM THỬ TỰ ĐỘNG 1.1 Chất lượng phần mềm và kiểm thử phần mềm

1.1.1 Vòng đời phát triển phần mềm và kiểm thử

Đặc điểm của mô hình Agile:

 Cá nhân và các tương tác quan trọng hơn quy trình và công cụ

 Tập trung làm cho phần mềm chạy được thay vì viết tài liệu

 Cộng tác trực tiếp với khách hàng thay vì dựa trên hợp đồng

 Phản ứng với các thay đổi thay vì tuân theo một kế hoạch định sẵn

 Dự án thực hiện với mô hình Agile thường có rất nhiều test unit được thực hiện bởi các người phát triển (developer)

Các dự án có đặc điểm sau đây có thể phù hợp với Agile:

 Mức độ rủi ro thấp

 Thành viên nhóm có kinh nghiệm

 Yêu cầu thay đổi thường xuyên

 Kích thước nhóm nhỏ Các thành viên làm việc cùng một địa điểm

 Văn hóa công ty ưa thích sự “không trật tự” (thrive on chaos)

Trang 6

Hình 2 Mô hình Alige 1.1.1.3 Sản phẩm phần mềm và vấn đề lỗi phần mềm

Quá trình sản xuất 1 phần mềm dù sử dụng quy trình nào thì cũng bao gồm nhiều giai đoạn chứ không đơn giãn chỉ là viết code chương trình, 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

Trang 7

Hình 3 Sản phẩm phần mềm

Khi phần mềm thực thi không đúng với đặc tả thì ta nói phần mềm xuất hiện lỗi Lỗi phần mềm được chia thành các dạng :

 Sai: Sản phẩm được xây dựng khác với đặc tả

 Thiếu: Một yêu cầu đã được đưa vào đặc tả nhưng lại không có trong sản phẩm phần mềm đã xây dựng

 Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả hoặc yêu cầu khác với đặc tả

Ngoài ra lỗi phần mềm có thể do tính khó hiểu, khó sử dụng, chậm hoặc giao diện không phù hợp với đối tượng sử dụng…

Nguyên nhân xuất hiện lỗi phần mềm cũng rất đa dạng, khác với sự cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do lập trình Nhiều nghiên cứu đã được thực hiện trong các dự án từ rất nhỏ đến các dự án rất lớn và kết quả luôn giống nhau Số lỗi do đặc tả gây ra là nhiều nhất, chiếm khoảng 80% Có một

số nguyên nhân làm cho đặc tả tạo ra nhiều lỗi nhất Trong nhiều trường hợp, đặc tả không được viết ra Các nguyên nhân khác có thể do đặc tả không đủ cẩn thận, nó hay thay đổi, hoặc do chưa phối hợp tốt trong toàn nhóm phát triển Sự thay đổi yêu cầu của khách hàng cũng là nguyên nhân dễ gây ra lỗi phần mềm Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu như phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành Nếu có nhiều

Trang 8

sự thay đổi, rất khó nhận biết hết được phần nào của dự án phụ thuộc và phần nào không phụ thuộc vào sự thay đổi Nếu không giữ được vết thay đổi rất dễ phát sinh

“không nói lên được” Một điều cũng hiển nhiên là nhiều lỗi xuất hiện trên bề mặt lập trình nhưng thực ra lại do lỗi của đặc tả hoặc thiết kế Một nguyên nhân khác tạo

ra lỗi là do bản thân các công cụ phát triển phần mềm cũng có lỗi như công cụ trực quan, thư viện lớp, bộ biên dịch,…

Khi phần mềm có lỗi chi phí để sửa lỗi phụ thuộc vào thời điểm phát hiện lỗi, lỗi phát hiện càng muộn thì chi phí càng cao

1.1.2 Kiểm thử phần mềm và chất lượng phần mềm

1.1.2.1 Kiểm thử phần mềm

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í

1.1.2.2 Chất lượng phần mềm

Chất lượng phần mềm là một khái niệm đa chiều, không dễ định nghĩa đơn giản theo cách chung cho các sản phẩm là: “Sản phẩm được phát triển phù hợp với đặc tả của nó.” [8] Có một số vấn đề khó trong hệ thống phần mềm, đó là:

Trang 9

 Đặc tả phải định hướng theo những đòi hỏi về chất lượng của khách hàng(như tính hiệu quả, độ tin cậy, tính dễ hiểu, tính bảo mật,…) và những yêu cầu của chính tổ chức phát triển phần mềm vốn không có trong đặc t(như các yêu cầu về khả năng bảo trì, tính sử dụng lại, )

 Một số yêu cầu về chất lượng cũng rất khó chỉ ra một cách rõ ràng

 Những đặc tả phần mềm thuờng không đầy đủ và hay mâu thuẫn

Hình 4 Ngữ cảnh kiểm thử phần mềm

Trên quan điểm qui trình, kiểm thử phần mềm là một phần của xác minh và thẩm định phần mềm Xác minh và thẩm định nằm trong công nghệ phần mềm, công nghệ phần mềm lại là một phần của công nghệ hệ thống (Hình4a) Nhìn từngữ cảnh chất lượng (Hình 4b), kiểm thử phần mềm cũng là một phần của xác minh và thẩm định phần mềm, nên cũng có thể xem như là một phần của đảm bảo chất lượng phần mềm Nếu phần mềm là thành phần của hệ thống lớn hơn thì kiểm thử phần mềm cũng được xem như là một phần của quản lý và đảm bảo chất lượng

Và để đạt phần mềm chất lượng cao, thì kiểm thử có thể coi là một thành phần chủ yếu của hoạt động đảm bảo chất lượng phần mềm

1.1.3 Các giai đoạn kiểm thử và điểm xác định

Test

phrase

Pre- Alpha Alpha Beta GM/Release

Unit (Đơn vị) Intergration

(Tích hợp)

System (Hệ thống)

Acceptance (Chấp nhận) Thực

hiện

Developer Developer /

Technical Tester

kiểm tra các đơn vị code

Là mức độ kiểm thử toàn bộ chức năng hệ thống

Kiểm tra như sản phẩm được đưa ra

Đánh giá phần mềm

có đáp ứng được các yêu cầu của người dùng đã đề ra hay không? Có thể triển

Trang 10

 Giai đoạn phát triển: là một khối thời gian trong vòng đời của việc phát triển phần mềm với một số các hoạt động phải làm trong khối thời gian này

 Mốc phát triển: Đánh dấu một sự kiện trong tiến trình phát triển phần mềm, khi phần mềm di chuyển từ giai đoạn này qua giai đoạn khác

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

Để tăng hiệu quả của quá tình kiểm thử cần sử dụng các kỹ thuật kiểm thử như những công cụ được thiết kế để đảm bảo rằng tất cả các khía cạnh của sản phẩm đều được khảo sát Mặt khác, các kỹ thuật kiểm thử là những công cụ để dễ dàng đạt được hiệu quả kiểm thử Các kỹ thuật kiểm thử thường được chia thành hai loại: các kỹ thuật kiểm thử hộp đen (black-box testing) và kỹ thuật kiểm thử hộp trắng (white-box testing)

Kiểm thử black-box Các kiểm thử black-box tìm các lỗi như thiếu các chức năng, khả năng sử dụng và các yêu cầu phi chức năng

Các kỹ thuật kiểm thử white-box yêu cầu hiểu biết về cấu trúc chương trình bên trong và các kiểm thử nhận được từ đặc tả thiết kế bên trong hoặc từ mã

1.2 Kiểm thử tự động

1.2.1 Khái niệm về kiểm thử tự động:

Kiểm thử tự động (KTTĐ) là việc sử dụng các phần mềm để kiểm soát việc thực hiện các thử nghiệm, so sánh kết quả thực tế kết quả dự đoán, thiết lập các điều kiện tiên quyết cho các thử nghiệm, và các chức năng kiểm cũng như báo cáo kết quả thử nghiệm Thông thường, KTTĐ bao hàm việc việc tự động hoá một quy trình làm việc bằng tay đã được sử dụng như một quá trình kiểm thử chính thức

1.2.2 Mục tiêu

Mục tiêu của KTTĐ là làm giảm các hoạt động kiểm thử thủ công và các hoạt động kiểm thử dư thừa bằng cách sử dụng một giải pháp có hệ thống để đạt

khi nó làm việc chung môi trường với nhau

sử dụng khai cho công việc

Tìm lỗi, xác nhận giá tri hệ thống, luồng dữ liệu…

Xác nhận các yêu cầu của người sử dụng

Trang 11

được một phạm vi và độ bao phủ các trường hợp kiểm thử tốt hơn, giảm chi phí và thời gian kiểm thử trong suốt vòng đời phần mềm Qua đó, nâng cao chất lượng, tăng độ tin cậy, tăng tốc độ làm việc và hiệu quả của quá trình kiểm thử, đạt được các tiêu chí kiểm thử, giải phóng cho các kỹ sư kiểm thử phần mềm thoát khỏi việc thực hiện kiểm thử cách tẻ nhạt và lặp lại nhàm chán

Để đạt được những mục tiêu đó, quy trình KTTĐ đặt ra nhiều yêu cầu thiết yếu Việc phải thành lập một đội ngũ kỹ sư chuyên dụng cho KTTĐ với một kế hoạch và chiến lược rõ ràng, các kỹ sư phải giỏi kĩ năng lập trình Các công cụ kiểm thử phải phù hợp với chiến lược đặt ra, phù hợp với ngân sách dành riêng cho KTTĐ và tiến độ của dự án Việc bảo trì các ca kiểm thử cũng là một yêu cầu thiết yếu của KTTĐ Việc kiểm thử phải được thực thi nhiều lần, do đó yêu cầu phải có một quy trình phát triển cụ thể, song song đó, nên có quy trình kiểm thử tại chỗ – chủ yếu là thủ công Cuối cùng, cần phải xem xét đến các chi phí liên quan đên chi phí của công cụ kiểm thử và chi phí đào tạo nếu có

Để KTTĐ thì cần sử dụng các test tool, nhưng không phải trong mọi trường hợp đều có thể sử dụng Test tool thay cho việc kiểm thử thủ công KTTĐ được xem xét trong một số trường hợp sau đây:

Không đủ tài nguyên: Khi số lượng Test Case quá nhiều mà KTV không thể

hoàn tất trong thời gian cụ thể

Ví dụ: Khi kiểm thưr chức năng của 1 website với 6 môi trường gồm 3 trình duyệt và 2 hệ điều hành Tình huống này đòi hỏi số lần kiểm tra tăng lên và lặp lại 6 lần so với việc kiểm tra cho một môi trường cụ thể

Kiểm tra hồi quy: Trong quá trình phát triển phần mềm, nhóm lập trình

thường đưa ra nhiều phiên bản phần mềm liên tiếp để kiểm tra Thực tế cho thấy việc đưa ra các phiên bản phần mềm có thể là hàng ngày, mỗi phiên bản bao gồm những tính năng mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp Việc bổ sung hoặc sửa lỗi code cho những tính năng ở phiên bản mới có thể làm cho những tính năng khác đã kiểm tra tốt chạy sai mặc dù phần code của nó không hề chỉnh sửa Để khắc phục điều này, đối với từng phiên bản, tester không chỉ kiểm tra chức năng mới hoặc được sửa, mà phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước

đó Điều này khó khả thi về mặt thời gian nếu kiểm tra thủ công

Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt: Đây là

kiểm tra nhằm đánh giá xem vận hành của PM có thỏa mãn yêu cầu đặt ra hay không Thông qua đó KTV có thể xác định được các yếu tố về phần cứng, phần

Trang 12

mềm ảnh hưởng đến khả năng vận hành của PM Có thể liệt kê một số tình huống kiểm tra tiêu biểu thuộc loại này như sau:

+ Đo tốc độ trung bình xử lý một yêu cầu của Web server

+ Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm tra tình huống 1000 người dùng truy xuất web cùng lúc

+ Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấu hình máy thấp nhất mà tốc độ xử lý của PM vẫn có thể hoạt động ở mức cho phép

+ Xác định cấu hình máy thấp nhất mà PM vẫn có thể hoạt động tốt Việc kiểm tra thủ công cho những tình huống trên là cực khó, thậm chí "vô phương"

Ngoài ra, một số trường hợp sử dụng KTTĐ nhằm mục đích kiểm tra, phát hiện những lỗi của PM trong những trường hợp đoán trước Điều này cũng có nghĩa

là nó thường được thực hiện sau khi đã thiết kế xong các ca kiểm thử (test case) Tuy nhiên, như đã nói, không phải mọi trường hợp kiểm tra đều có thể hoặc cần thiết phải tự động hóa, trong tất cả test case thì tester phải đánh giá và chọn ra những test case nào phù hợp hoặc cần thiết để áp dụng KTTĐ dựa trên những tiêu chí đã đề cập bên trên

Trang 13

CHƯƠNG 2 MỘT SỐ QUY TRÌNH KIỂM THỬ TỰ ĐỘNG

Ngày nay, các chuyên gia phần mềm đang phải đối mặt với những thách thức

về việc xây dựng các hệ thống với ít nhân lực, tài nguyên trong một khoảng thời gian ngày càng bị thu hẹp Các công ty không chỉ muốn kiểm thử phần mềm một cách đầy đủ, mà còn đòi hỏi việc kiểm thử phải đưa lại kết quả chính xác

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

Mục đích của kiểm thử phần mềm là đánh giá chất lượng của công việc được thực hiện ở từng bước của qui trình phát triển phần mềm Người quản lí kiểm thử phải lập kế hoạch kiểm thử lúc bắt đầu của dự án đồng thời với lúc người quản lí dự

án lập kế hoạch cho các hoạt động dự án Bản kế hoạch kiểm thử nên bao gồm các thủ tục kiểm thử, trường hợp kiểm thử, thông tin lỗi, lịch biểu kiểm thử, và dữ liệu hiệu năng được dùng cho kiểm thử phần mềm Người kiểm thử không nên chờ đợi kiểm thử mọi thứ ở lúc cuối của nỗ lực phát triển, sau khi viết mã đã được thực hiện Họ phải làm việc với người phát triển qua qui trình phát triển để đảm bảo rằng phần mềm được phát triển như dự định, và để cải tiến chất lượng, tính tin cậy và tính bảo trì phần mềm

Việc kiểm thử phần mềm thường bắt đầu ở mức cấu phần (kiểm thử đơn vị, kiểm thử chức năng) rồi đi lên tới sản phẩm phần mềm (kiểm thử tích hợp, kiểm thử

rà lại, kiểm thử hệ thống, kiểm thử chấp nhận v.v) Trong dự án nhỏ, những người phát triển thường làm cả việc viết mã và kiểm thử Trong dự án lớn hơn, nên có nhóm kiểm thử độc lập làm kiểm thử để tránh thiên lệch của người phát triển khi làm kiểm thử công việc riêng của họ Điều này không có nghĩa là người phát triển không kiểm thử và người kiểm thử phải làm mọi kiểm thử Về căn bản, cả người phát triển và người kiểm thử đều phải làm việc cùng nhau trong toàn dự án để đảm bảo rằng mọi kiểm thử được tiến hành đúng Người phát triển phải kiểm thử mã riêng của họ để loại bỏ các lỗi, đảm bảo thực hiện đúng, và luồng thông tin cũng như kiểm tra dữ liệu để đảm bảo rằng tính toàn vẹn được bảo trì (như kiểm thử mô đun, kiểm thử đơn vị) trước khi người kiểm thử bắt đầu các hoạt động kiểm thử của

họ

Người kiểm thử thường bắt đầu bằng “kiểm thử chức năng” để làm lộ ra các lỗi chức năng trong phần mềm rồi tiến hành "kiểm thử tích hợp" để đảm bảo mọi chức năng làm việc đúng và luồng thực hiện đang xảy ra như dự định Người kiểm thử phải tiến hành "kiểm thử nội dung thông tin" để kiểm lỗi trong cấu trúc dữ liệu cục bộ hay toàn cục Họ phải kiểm thử "tính toàn vẹn giao diện" để chắc cả giao diện trong và ngoài làm việc đúng, đặc biệt khi mô đun mới được thêm vào cho

Trang 14

phần mềm Khi thay đổi xảy ra, họ phải tiến hành "kiểm thử rà lại" để kiểm các lỗi

có thể lan truyền từ mô đun nọ sang mô đun kia và đảm bảo toàn bộ sản phẩm phần mềm làm việc được

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

Sau khi thẩm tra rằng sản phẩm phần mềm làm việc đúng, người kiểm thử có thể tiến hành "kiểm thử hệ thống" để chắc cả phần cứng và phần mềm đều làm việc như đã lập kế hoạch Trong kiểm thử này, người kiểm thử sẽ cho chạy "kiểm thử an ninh" để thẩm tra bảo vệ hệ thống chạy đúng để ngăn cản việc thâm nhập không đúng hay thay đổi dữ liệu Họ tiến hành "kiểm thử chịu căng thẳng" để kiểm tra xem nó giải quyết tốt đến đâu với nhưng yêu cầu tài nguyên bất thường (như, chất lượng, tần xuất, hay khối lượng) và "kiểm thử hiệu năng" để kiểm tra hiệu năng khi chạy của phần mềm, đặc biệt phần mềm thời gian thực Họ có thể tiến hành "kiểm thử phục hồi" để kiểm tra khả năng của hệ thống phục hồi từ hỏng hóc

Nếu mọi kiểm thử trong "kiểm thử hệ thống" đều qua được, người kiểm thử

có thể làm việc cùng khách hàng để chuẩn bị cho "kiểm thử chấp nhận" nơi họ đảm bảo phần mềm làm việc đúng với người dùng được dự định trong môi trường làm việc của họ Hai kiểm thử chính trong thời gian này: “kiểm thử Alpha” là thời kì kiểm thử mà sản phẩm phần mềm sẵn sàng được dùng trong "môi trường kiểm thử" của khách hàng nhưng có thể có một số lỗi nhỏ Nó là cơ hội cuối cùng để được trắc nghiệm từ khách hàng rằng phần mềm làm việc như được dự định “Kiểm thử Beta"

là thời kì kiểm thử trong đó sản phẩm phần mềm là đầy đủ không có lỗi và dùng được trong môi trường "sản xuất" Mục đích của kiểm thử Beta là kiểm thử khả

Trang 15

năng của công ti hỗ trợ cho sản phẩm Kiểm thử Beta phục vụ như bằng chứng rằng sản phẩm phần mềm là sẵn sàng cho việc gửi đi cho mọi khách hàng

Mục đích của kiểm thử là thiết kế một chuỗi các trường hợp kiểm thử mà có khả năng phát hiện lỗi cao Để cho việc kiểm thử đạt được kết quả tốt cần có sự chuẩn bị về kế hoạch kiểm thử, thiết kế các trường hợp kiểm thử và các dữ liệu kiểm thử cho các trường hợp Đây chính là đầu vào cho giai đoạn kiểm thử; kết quả của giai đoạn kiểm thử là “báo cáo kiểm thử” mô tả tất cả các trường hợp kiểm thử

đã chạy, dữ liệu đầu vào, đầu ra mong đợi, đầu ra thực tế và mục đích của kiểm thử,… (như Hình 5)

Hình 6 Quy trình kiểm thử phầm mềm

Qui trình kiểm thử bao gồm một số giai đoạn:

 Lập kế hoạch kiểm thử Bước đầu tiên là lập kế hoạch cho tất cả các hoạt động sẽ được thực hiện và các phương pháp được sử dụng Các chuẩn IEEE bao gồm các thông tin về tác giả chuẩn bị kế hoạch, danh sách liệt kê của kế hoạch kiểm thử Vấn đề quan trọng nhất đối với kế hoạch kiểm thử [6,7]:

+ Mục đích: Qui định về phạm vi, phương pháp, tài nguyên và lịch biểu của các hoạt động kiểm thử

+ Các tài liệu tham khảo

Trang 16

 Thiết kế các truờng hợp kiểm thử: Các truờng hợp kiểm thử là các đặc tả đầu vào cho kiểm thử và đầu ra mong đợi của hệ thống cùng với các câu lệnh đuợc kiểm thử

+ Các phương pháp hộp đen để kiểm thử dựa trên chức năng

+ Các phương pháp hộp trắng để kiểm thử dựa vào cấu trúc bên trong

 Xử lý do luờng kiểm thử bằng cách thu thập dữ liệu

 Ðánh giá sản phẩm phần mềm để xác nhận sản phẩm có thể sẵn sàng phát hành được chưa?

Mô hình chung của qui trình kiểm thử phần mềm được thể hiện trong hình 6

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

Các pha được cụ thể hóa theo bảng sau:

Ngày đăng: 18/09/2014, 20:54

HÌNH ẢNH LIÊN QUAN

Hình 1. Mô hình thác nước  1.1.1.2  Phương pháp Agile - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 1. Mô hình thác nước 1.1.1.2 Phương pháp Agile (Trang 5)
Hình 2. Mô hình Alige  1.1.1.3   Sản phẩm phần mềm và vấn đề lỗi phần mềm - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 2. Mô hình Alige 1.1.1.3 Sản phẩm phần mềm và vấn đề lỗi phần mềm (Trang 6)
Hình 3. Sản phẩm phần mềm - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 3. Sản phẩm phần mềm (Trang 7)
Hình 4. Ngữ cảnh kiểm thử phần mềm - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 4. Ngữ cảnh kiểm thử phần mềm (Trang 9)
Hình 5. Quy trình kiểm thử phần mềm - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 5. Quy trình kiểm thử phần mềm (Trang 14)
Hình 6. Quy trình kiểm thử phầm mềm - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 6. Quy trình kiểm thử phầm mềm (Trang 15)
Hình 7. Quy trình kiểm thử phần mềm - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 7. Quy trình kiểm thử phần mềm (Trang 16)
Hình 8.  Quy trình kiểm thử tự động - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 8. Quy trình kiểm thử tự động (Trang 20)
Hình 9. Mô hình kiến trúc của quy trình KTTĐ - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 9. Mô hình kiến trúc của quy trình KTTĐ (Trang 21)
Hình 10. Các giai đoạn chính của quy trình KTTĐ - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 10. Các giai đoạn chính của quy trình KTTĐ (Trang 22)
Hình 11. Các bước thực hiện KTTĐ - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 11. Các bước thực hiện KTTĐ (Trang 23)
Bảng sau mô tả rõ hơn các bước phát triển tiến tới đánh giá: - thiết kế và xây dựng quy trình kiểm thử tự động
Bảng sau mô tả rõ hơn các bước phát triển tiến tới đánh giá: (Trang 23)
Hình 12. Quick Test Pro - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 12. Quick Test Pro (Trang 28)
Hình 13. Ví dụ minh hoa QTP - thiết kế và xây dựng quy trình kiểm thử tự động
Hình 13. Ví dụ minh hoa QTP (Trang 30)

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w