DATN
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.73 MB, 89 trang )
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
1. Thông tin chung
Tên đề tài
Kiểm thử website twentyfive.vn bằng
công cụ Selenium
Họ và tên sinh viên:
Điện thoại liên lạc:
Email:
Lớp:
Hệ đào tạo:
Đại học chính quy
Đồ án tốt nghiệp được thực hiện tại:
Hà Nội
Thời gian làm ĐATN:
2. Mục tiêu của ĐATN
Nghiên cứu tổng quan về kiểm thử phần mềm, công cụ kiểm thử tự động Selenium,
ứng dụng công cụ để kiểm thử website.
3. Các nhiệm vụ cụ thể của ĐATN
-
Tìm hiểu về phần mềm, lỗi phần mềm và kiểm thử phần mềm.
Nghiên cứu về công cụ kiểm thử tự động Selenium.
Nắm rõ được cách thử sử dụng công cụ Selenium WebDriver
Ứng dụng các kiển thức đã tìm hiểu về kiểm thử phần mềm và cơng cụ Selenium
WebDriver để tiến hành viết testcase và kiểm thử website.
4. Lời cam đoan của sinh viên:
Hà Nội, ngày
tháng
năm
Tác giả ĐATN
1
1
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
5. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép
bảo vệ:
Hà Nội, ngày tháng
năm
Cán bộ hướng dẫn
2
2
Đồ án tốt nghiệp chun ngành Cơng Nghệ Phần Mềm
TĨM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP
Đồ án giới thiệu về lý thuyết phần mềm, kiểm thử phần mềm, một số công cụ kiểm
thử tự động, trọng tâm là công cụ Selenium. Ngồi ra đề tài đi sâu vào tìm hiểu, cách sử
dụng cơng cụ Selenium Webdriver:
-
Trình bày hướng dẫn các bước cài đặt Selenium WebDriver, framework hỗ
-
trợ và cách sử dụng.
Ứng dụng các kiến thức đã tìm hiểu và học được để xây dựng được kịch bản
kiểm thử và tiến hành kiểm thử với trang web.
Nội dung đồ án tốt nghiệp gồm có các phần sau
-
-
-
-
Mở đầu: Trình bày lý do chọn đề tài, mục tiêu nghiên cứu và bố cục của đồ
án.
Chương 1: Tổng quan phần mềm và lỗi phần mềm. Chương này trình bày các
khái niệm của phần mềm, đảm bảo chất lượng phần mềm và lỗi phần mềm.
Chương 2: Tổng quan về kiểm thử phần mềm. Chương này trình bày về khái
niệm, mục tiêu, quy trình, các giai đoạn và phương pháp kiểm thử phần mềm.
Đồng thời giới thiệu về kiểm thử tự động.
Chương 3: Tổng quan về Selenium: Chương này trình bày tổng quan kiến
thức về Selenium, đặc biệt là Selenium WebDriver. Trình bày được cách cài
đặt, sử dụng Selenium WebDriver với ngôn ngữ lập trình JavaScript và
framework hỗ trợ.
Chương 4: Kết quả cài đặt và thử nghiệm: Chương này trình bày các chức
năng của trang web twentyfive.vn, xây dựng testcase và báo cáo kết quả kiểm
thử.
Kết luận và hướng phát triển: Đưa ra kết quả đạt được từ đồ án và hướng phát
triển trong tương.
3
3
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
LỜI CẢM ƠN
Em xin chân thành cảm ơn các thầy cô giáo của Khoa Công nghệ thông tin của
Trường Đại học Mỏ - Địa chất Hà Nội, và các thầy cô giáo Bộ mơn Cơng nghệ phần mềm
đã nhiệt tình giảng dạy, truyền đạt kiến thức và tạo điều kiện thuận lợi cho em trong suốt
quá trình học tập 5 năm qua cũng như trong quá trình thực hiện đồ án tốt nghiệp.
Em xin gửi lời cảm ơn đặc biệt đến Thạc sĩ– Bộ mơn Cơng nghệ phần mềm đã nhiệt
tình hướng dẫn, chỉ bảo cho em trong suốt thời gian thực hiện đồ án.
Và cuối cùng em xin gửi lời cảm ơn chân thành tới gia định, bạn bè đã động viên,
giúp đỡ trong quá trình học tập, thời gian nghiên cứu và hoàn thành đồ án tốt nghiệp.
Hà Nội, ngày……tháng……năm
Sinh viên thực hiện
4
4
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
MỤC LỤC
5
5
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
DANH MỤC CÁC HÌNH VẼ
6
6
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
DANH MỤC CÁC BẢNG BIỂU
7
7
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
DANH MỤC CÁC TỪ VIẾT TẮT
S
T
T
Từ viết Từ tiếng Anh
tắt
Từ và nghĩa tiếng
Việt
1
Test case
Trường hợp kiểm
thử
2
Test suite
Một bộ bao gồm
nhiều test case liên
quan với nhau
3
Test script
Một nhóm mã lệnh
đặc tả kịch bản để
tự động hóa trình tự
kiểm thử
4
Validate
Thuật ngữ trong
kiểm thử phần mềm
dùng để kiểm tra
tính hợp lệ của dữ
liệu
5
Framework
Là một tập hợp các
thư viện hoặc các
lớp có thể sử dụng
lại được
8
8
MỞ ĐẦU
1. Tổng quan tình hình nghiên cứu thuộc lĩnh vực của đề tài
Thời đại công nghệ 4.0, công nghệ thông tin ngày càng phát triển mạnh mẽ ở nhiều
lĩnh vực khác nhau, kéo theo đó là hệ thống mạng và các phần mềm, ứng dụng cũng gia
tăng cả về số lượng lẫn chất lượng. Cùng với sự phát triển đó, lỗi phần mềm và chất lượng
phần mềm ln là thách thức lớn khi ngành này thực tế đã chứng mình kiểm thử phần mềm
là giai đoạn chiếm hơn 40% thời gian, kinh phí và nguồn nhân lực phát triển phần mềm.
Tự động hóa cũng đã và đang được nghiên cứu và ứng dụng trong nhiều lĩnh vực
khác nhau, kiểm thử phần mềm cũng không là ngoại lệ. Khi mà kiểm thử phần mềm tiêu
tốn một lượng lớn thời gian, kinh phí và nhân lực trong một dự án thì song song với kiểm
thử thủ công, sự ra đời của các công cụ kiểm thử tự động giúp cho công việc kiểm thử trở
nên nhanh, chính xác và bớt nhàm chán hơn.
2. Tính cấp thiết, ý nghĩa khoa học và thực tiễn của đề tài
Selenium là một công cụ kiểm thử ứng dụng web mã nguồn mở, hoàn toàn miễn phí.
Tuy cơng cụ này hiện nay đã khá là cũ nhưng vẫn được nhiều cơng ty phần mềm sử dụng
vì sự đơn giản, tiện lợi và khơng tốn chi phí nào.
Với mong muốn có cái nhìn xác thực, rõ ràng hơn về kiểm thử phần mềm cũng như
công cụ kiểm thử tự động Selenium, em chọn đề tài này cho đồ án tốt nghiệp của mình.
Trong khn khổ đồ án, do thời gian và kinh nghiệm thực tế còn nhiều hạn chế nên phần
nào chưa được thực hiện tốt, em rất mong nhận được sự góp ý của thầy cơ và các bạn để đề
tài được hoàn thiện hơn.
CHƯƠNG 1 TỔNG QUAN PHẦN MỀM VÀ LỖI PHẦN MỀM
1.1 Định nghĩa phần mềm
Phần mềm là một tập hợp những câu lệnh được viết bằng một hoặc nhiều ngôn ngữ
lập trình theo một trật tự xác định nhằm tự động thực hiện một số chức năng hoặc giải
quyết một bài tốn nào đó. Phần mềm được thực thi trên máy, thường là máy tính.
Phần mềm có 4 thành phần cơ bản:
-
Chương trình máy tính
Các thủ tục
Tài liệu
Dữ liệu cần thiết để vận hành
1.2 Đặc trưng của phần mềm
-
Phần mềm được thiết kế, chế tạo như các loại sản phẩm công nghiệp khác,
-
nhưng khơng được định hình trước.
Q trình phát triển phần mềm quyết định giá thành và chất lượng phần mềm.
Các phần mềm chỉ thực sự tìm được ra lỗi trong pha phát triển.
Phần mềm có tính phức tạp và luôn thay đổi.
Phần mềm là một hệ thống logic với nhiều khái niệm và các mối liên hệ logic
khác nhau
1.3 Vòng đời phần mềm
Vòng đời phần mềm là khoảng thời gian tính từ khi phần mềm được đề xuất cho đến
khi bỏ đi. Cụ thể là từ khi được đặt hàng, phát triển, sử dụng và cho đến khi bị loại bỏ.
Vòng đời phần mềm được phân chia thành các pha chính: xác định yêu cầu, triển
khai, kiểm thử, bảo trì (vận hành). Phạm vi, thứ tự các pha khác nhau tùy vào từng mơ
hình, dự án cụ thể.
Các giai đoạn
Các hoạt động
Thu thập yêu cầu
Thu thập các thông tin về chi tiết, thông số kỹ thuật của
phần mềm mà khách hàng mong muốn.
Thiết kế
Lên kế hoạch lập trình sử dụng ngơn ngữ lập trình, cơ sở
dữ liệu phù hợp với dự án, cũng như một số chức năng
và kiến trúc phức tạp.
Xây dụng
Sau giai đoạn thiết kế là giai đoạn xây dựng, giai đoạn
này là viết code xây dựng phần mềm.
Kiểm thử
Kiểm thử phần mềm để xác minh rằng phần mềm được
xây dựng theo yêu cầu do khách hàng cung cấp.
Triển khai
Triển khai ứng dụng phần mềm trong môi trường thực tế.
Bảo trì
Khi hệ thống đi vào hoạt động, ta có thể thay đổi code
theo yêu cầu của khách hàng.
Bảng 1–1 Vòng đời của phần mềm
1.4 Chất lượng phần mềm và đảm bảo chất lượng phần mềm
1.4.1 Chất lượng phần mềm
Định nghĩa chất lượng phần mềm theo IEEE (1991):
-
Định nghĩa 1: Chất lượng phần mềm là một mức độ mà một hệ thống, thành
-
phần hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặc tả.
Định nghĩa 2: Chất lượng phần mềm là một hệ thống, thành phần hệ thống
hay tiến trình đáp ứng được yêu cầu và sự mong đợi của khách hàng hay
người sử dụng.
Định nghĩa theo Pressman: Chất lượng phần mềm là sự phù hợp của các yêu cầu cụ
thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phần mềm được ghi lại rõ rang
bằng tài liệu với các đặc tính ngầm định của tất cả các phần mềm được phát triển chuyên
nghiệp. Định nghĩa của Pressman đề xuất ba yêu cầu với chất lượng phần mềm phải được
đáp ứng khi phát triển phần mềm:
-
Các yêu cầu chức năng rõ ràng là nhân tố chính quyết định chất lượng đầu ra
-
của phần mềm.
Các tiêu chuẩn chất lượng phần mềm sẽ được nói đến trong hợp đồng.
Các đặc tính ngầm định cần được đáp ứng trong q trình phát triển cho dù
khơng được nói đến rõ ràng trong hợp đồng.
1.4.2 Đảm bảo chất lượng phần mềm
-
Định nghĩa theo Daniel Galin: Đảm bảo chất lượng phần mềm (Software
quality assure - SQA) là một tập hợp các hành động cần thiết được lên kế
hoạch một cách hệ thống để cung cấp đủ niềm tin rằng quá trình phát triển
phần mềm phù hợp để thành lập các yêu cầu chức năng kỹ thuật, cũng như
các yêu cầu quản lý theo lịch trình và hoạt động trong giới hạn ngân sách.
1.4.3 Một số tiêu chí trong đảm bảo chất lượng phần mềm:
-
Tính năng: là khả năng cung cấp các chức năng thỏa mãn yêu cầu, mục đích
-
đã xác định khi bắt đầu triển khai phần mềm. Các tính năng bao gồm:
o Tính phù hợp
o Tính chính xác
o Khả năng tương tác
o Tính bảo mật
Độ tin cậy: Nguyên nhân của độ tin cậy kém là do cấu trúc phần mềm khơng
-
kết hợp được với mã hóa. Việc đánh giá độ tin cậy của một phần mềm cung
cấp ước tính mức độ rủi ro kinh doanh và khả năng xảy ra các lỗi tiềm ẩn của
ứng dụng khi thử nghiệm. Mục đích của việc kiểm tra và giám sát độ tin cậy
là để giảm thiểu lỗi phần mềm cũng như ngừng hoạt động hay các lỗi ảnh
hưởng trực tiếp đến người dùng.
o Tính hồn thiện cấu trực ứng dụng
o Quy trình mã hóa
o Tính phức tạp của của thuật toán
o Khả năng xử lý và chịu lỗi
o Khả năng phục hồi, quản lý tài nguyên
o Phần mềm quản lý tính tồn vẹn và tính thống nhất của dữ liệu
Hiệu quả: Là khả năng đáp ứng hiệu năng một cách thích hợp nhằm tiết kiệm
-
tài nguyên, tăng hiệu suất ứng dụng và khả năng mở rộng của phần mềm.
Tính tốn nguồn lực, mã nguồn đảm bảo hiệu năng cao khi phần mềm chạy
trên hệ thống. Việc phân tích này cung cấp những rủi ro tiềm ẩn, nguy hại do
sự trì trệ của phần mềm theo thời gian. Đánh giá tính hiệu quả của phần mềm
dưới các điều kiện sau:
o Cấu trúc ứng dụng
o Độ tương tác thích hợp với các nguồn tài nguyên
o Hiệu suất, thời gian truy cập và quản lý dữ liệu
o Quản lý bộ nhớ, mạng và khơng gian đĩa
o Quy trình mã hóa, lập trình
Tính bảo mật: Có biện pháp bảo vệ, ngăn chặn khả năng xảy ra các phạm vi
bảo mật đến phần mềm, dữ liệu của hệ thống và ngăn chặn nguy cơ tấn công
các lỗ hổng bảo mật gây tổn hại cho người dùng, doanh nghiệp; đáp ứng mức
độ rủi ro chấp nhận được đối với người dùng, phần mềm hay mơi trường sử
dụng. Để đánh giá độ an tồn, bảo mật cần kiểm tra các thuộc tính sau:
o Cấu trúc ứng dụng
o Sự tuân thủ thiết kế nhiều lớp
-
o Vấn đề thực tế bảo mật
o Quy trình mã hóa, lập trình
o Bảo mật truy cập vào hệ thống, kiểm sốt các chương trình
Khả năng bảo trì: Khả năng bảo trì bao gồm các khả năng kiểm tra, nâng cấp,
thay đổi và phát triển phần mềm sao cho phù hợp với u cầu, chức năng và
mơi trường. Tính duy trì bao gồm khả năng thích ứng, tính di động và khả
năng chuyển đổi. Cần phải cập nhật công nghệ hay những thay đổi về thị
trường, doanh nghiệp đảm bảo luôn cung cấp thông tin, phần mềm chất lượng
đến tay người dùng. Đánh giá khả năng bảo trì qua các thuộc tính sau:
o Cấu trúc phần mềm và lập trình hướng đối tượng
o Khả năng phân tích
o Mức độ phức tạp của thuật tốn
o Kiểm sốt mức độ mã hóa
o Tính ổn định của phần cứng, hệ điều hành, thành phần trung gian, cơ
-
sở dữ liệu độc lập
o Khả năng kiểm thử được
Kích thước: Đo lường kích thước phần mềm u cầu tồn bộ mã nguồn phải
được thu thập chính xác, bao gồm các tập lệnh cấu trúc cơ sở dữ liệu, mã
nguồn thao tác dữ liệu, các tiêu đề thành phần, các tệp cấu hình… Có hai loại
kích thước phần mềm cần được đo là kích thước kỹ thuật và kích thước chức
năng:
o Phương pháp đánh số kỹ thuật phổ biến nhất là số dịng mã trên mỗi
cơng nghệ, số lượng tệp tin, chức năng, các lớp, bảng biểu.
o Để đo kích thước chức năng phổ biến nhất là phân tích điểm chức
năng được phân phối từ quan điểm, yêu cầu của người dùng. Họ cung
cấp mô tả về kích thước, giá trị và chức năng cho bên phát triển phần
mềm. Các giá trị kích thước này được kết hợp với nhiều biện pháp để
định lượng, đánh giá việc phân phối và thực hiện phần mềm.
1.5 Lỗi phần mềm
1.5.1 Định nghĩa
Một lỗi phần mềm là một lỗi hay hỏng hóc trong một chương trình hoặc hệ thống
máy tính khiến nó tạo ra kết quả khơng chính xác hoặc khơng mong muốn hoặc hành xử
theo những cách không lường trước được. Quá trình tìm và sửa lỗi được gọi là gỡ lỗi và
thường sử dụng các kỹ thuật hoặc công cụ để xác định lỗi và từ những năm 1950, một số
hệ thống máy tính đã được thiết kế để ngăn chặn, phát hiện hoặc tự động sửa các lỗi máy
tính khác nhau trong q trình hoạt động.
Hoặc ta có định nghĩa đơn giản hơn: Lỗi phần mềm là sự khơng khớp của chương
trình với đặc tả của nó.
Dựa theo định nghĩa trên, ta có thể phân loại lỗi phần mềm thành 3 dạng:
-
Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả.
Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả nhưng lại
-
khơng có trong sản phẩm thực tế.
Lỗi thừa: Sản phẩm thực tế có những tính năng khơng có trong tài liệu đặc tả.
1.5.2 Các nguyên nhân gây ra lỗi phần mềm
Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả nguyên
nhân chủ quan và khách quan. Dưới đây là các nguyên nhân phổ biến gây ra lỗi phần mềm:
-
Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầu thường
-
nằm ở phía khách hàng. Một số lỗi thường gặp là: định nghĩa sai yêu cầu,
thiếu các yêu cầu quan trọng hoặc quá chú trọng vào các yêu cầu không cần
thiết.
Lỗi trong giao tiếp với khách hàng và nhà phát triển phần mềm: Hiểu lầm
-
trong giao tiếp giữa khách hàng và nhà phát triển phần mềm cũng là nguyên
nhân gây ra lỗi. Những lỗi này thường xuất hiện trong giai đoạn đầu của dự
án.
Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trường hợp các
nhà phát triển cố tình làm sai lệch các yêu cầu trong tài liệu đặc tả. Nguyên
nhân của việc này đến từ áp lực về thời gian, ngân sách, hay cố tình sử dụng
lại các module từ các dự án trước mà chưa phân tích đầy đủ những thay đổi
để thích nghi với các yêu cầu mới.
o Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem giải
-
pháp như thế nào, sắp xếp ưu tiên để xem có thể bỏ được yêu cầu nào
hoặc sử dụng lại được module nào.
Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong q trình những người phân
-
tích thiết kế hệ thống, lập trình viên xây dựng phần mềm theo yêu cầu. Các
lỗi điển hình:
o Định nghĩa các yêu cầu phần mềm bằng thuật tốn sai.
o Quy trình định nghĩa có chứa trình tự lỗi.
o Sai sót trong các định nghĩa biên như > 3 hay ≥ 3.
o Thiếu sót các trạng thái hệ thống phần mềm được yêu cầu.
Các lỗi lập trình: Có nhiều lý do gây ra lỗi lập trình: hiểu sai tài liệu thiết kế,
-
ngơn ngữ; sai sót trong ngơn ngữ lập trình; sai sót trong việc áp dụng các
cơng cụ phát triển; sai sót trong lựa chọn dữ liệu.
Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình: Các lỗi
phần mềm có thể đến từ việc khơng tn thủ tài liệu và tiêu chuẩn lập trình
của các tổ chức phát triển phần mềm.
-
Thiếu sót trong q trình kiểm thử: Lỗi phần mềm có thể đến từ chính q
trình kiểm thử khi mà người kiểm thử để sót lỗi. Những lỗi này đến từ
nguyên nhân sau:
o Kế hoạch kiểm thử chưa hoàn chỉnh, để sót yêu cầu cần kiểm thử.
o Lỗi trong tài liệu và báo cáo kiểm thử.
o Việc sửa chữa các lỗi được phát hiện khơng hồn chỉnh do áp lực về
-
thời gian hoặc do kiểm thử chưa kĩ lưỡng.
Các lỗi về thủ tục: Các thủ tục hướng dẫn cho người sử dụng tại từng bước
-
của tiển trình. Chúng có tầm quan trọng đặc biệt trong hệ thống phần mềm
phức tạp mà các tiến trình được thực hiện bằng nhiều bước, mỗi bước có thể
có nhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian. Các lỗi có
thể đến từ việc viết các thủ tục.
Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo
trì khi có những sai sót trong các tài liệu liên quan. Những lỗi này có thể là
nguyên nhân gây ra lỗi trong giai đoạn kế tiếp hoặc giai đoạn bảo trì.
1.5.3 Một số quy tắc xác định lỗi phần mềm
-
Phần mềm không thực hiện một số thứ như mô tả trong bản đặc tả phần mềm
Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu không được thực
-
hiện.
Phần mềm thực hiện một số chức năng mà trong bản đặc tả không đề cập tới.
Phần mềm không thực hiện một số việc mà bản đặc tả không đề cập đến,
-
nhưng là việc nên làm.
Trong vị trí của người kiểm thử, phần mềm khó hiểu, khó sử dụng, thực hiện
chậm đối với người sử dụng.
1.5.4 Vòng đời của lỗi
Định nghĩa: Vòng đời của lỗi là tập hợp các trạng thái cụ thể mà lỗi đi qua trong suốt
vịng đời của nó. Mục đích của vịng đời là để dễ dàng phối hợp với các sự thay đổi của
trạng thái với người được chuyển giao và làm cho q trình sửa lỗi có hệ thống.
Các trạng thái trong vòng đời của lỗi:
-
New: Khi một lỗi mới được ghi lại và đăng lên lần đầu, nó sẽ được gán trạng
-
thái là “New”.
Assigned: Khi lỗi được đăng lên bởi người kiểm thử, trưởng nhóm kiểm thử
-
sẽ phê duyệt lỗi và chuyển giao lỗi cho lập trình viên.
Open: Lập trình viên phân tích và sửa lỗi.
Fixed: Khi lập trình viên đã sửa xong lỗi, người đó sẽ chuyển trạng thái của
-
lỗi sang “Fixed”.
Retest: Người kiếm thử tiến hành kiểm tra lại xem lỗi cịn khơng.
-
Re-opened: Khi lỗi vẫn cịn đó sau khi lập trình viên đã sửa lỗi, người kiểm
-
thử sẽ đổi trạng thái của lỗi sang “Re-opened”, khi đó lỗi sẽ quay lại vòng
đời.
Verified: Người kiểm thử kiểm tra lại lỗi sau khi lập trình viên đã sửa lỗi và
-
nếu khơng phát hiện ra, lỗi sẽ được chuyển trạng thái sang “Verified”.
Closed: Nếu lỗi đó khơng cịn thì người kiểm thử sẽ chuyển trạng thái lỗi
-
sang “Closed”.
Duplicate: Lỗi đăng lên bị trùng.
Rejected: Nếu lập trình viên thấy đó khơng phải là lỗi, họ có thể chuyển lỗi
-
sang trạng thái này.
Deferred: Lỗi được chấp nhận có thể sửa vào phiên bản phát hành sau,
thường là do độ ưu tiên thấp hoặc lỗi khơng có ảnh hưởng lớn đến phần mềm.
Hình 1-1 Sơ đồ vịng đời của lỗi
1.5.5 Quy trình xử lý lỗi phần mềm
Hình 1-2 Quy trình xử lý lỗi phần mềm
Theo sơ đồ, quy trình xử lý lỗi bao gồm 6 bước chính:
-
Bước 0: Phát hiện phần mềm có lỗi.
Bước 1: Đưa lỗi lên hệ thống quản lý lỗi
Bước 2: Gán lỗi cho lập trình viên
Bước 3: Xử lý lỗi
Bước 4: Kiểm thử lại
Bước 5: Đóng lỗi
A. Đưa lỗi lên phần mềm quản lý lỗi
-
Người thực hiện: quản trị dự án, nhóm kiểm thử.
Trạng thái của lỗi là New.
Một số thơng tin cần có về lỗi:
o Category: Thư mục lỗi dùng để phân loại lỗi, lỗi thuộc phần chức
năng nào phải chọn đúng phần thư mục lỗi tương ứng để thuận tiện
cho việc tra cứu, thống kê lỗi của chức năng.
o Severity (mức độ nghiêm trọng): mức độ nghiêm trọng của lỗi sẽ có
các mức sau:
Critical: Lỗi này cản trở việc thử nghiệm chức năng/ sản phầm
hoặc người dùng không thể sử dụng được ứng dụng/ hệ thống.
Major: Khi chức năng đã hoàn thành nhưng kết quả không đáp
ứng đúng yêu cầu đã đặt ra.
Minor: Khi chức năng không đáp ứng đúng yêu cầu nhưng tác
động không đáng kể hoặc không gây ảnh hưởng lớn đến phần
mềm.
Low: Lỗi này không gây ra tác động đến phần mềm. Ví dụ như
lỗi về layout, font-size hoặc lỗi chính tả.
o Reproducibility (khả năng tái lập): Khi phát hiện ra lỗi, người kiểm
thử cần thực hiện lại chức năng lỗi để xét khả năng tái lập lỗi.
o Priority: Mức độ ưu tiên sửa lỗi.
o Summary: Tóm tắt nội dung của lỗi.
o Description: Mô tả lỗi, phải nêu rõ được 3 nội dung:
Các bước thực hiện.
Kết quả trả về, kết quả mong muốn.
Notes: dùng để đưa các lưu ý, trao đổi về lỗi của các thành
viên trong đội dự án.
B. Gán lỗi cho lập trình viên
-
Người kiểm thử thực hiện gán lỗi cho lập trình viên – người chịu trách nhiệm
-
cho phần chức năng bị lỗi.
Trạng thái của lỗi là Assigned.
C. Xử lý lỗi
Lập trình viên kiểm tra lỗi được gán cho mình
-
Nếu thấy đúng là lỗi, lập trình viên tiến hành sửa lỗi và sau khi xong sẽ
-
chuyển trạng thái lỗi sang Fixed.
Nếu trường hợp khơng phải là lỗi hoặc lỗi có thể chấp nhận được, lập trình
viên sẽ chuyển trạng thái lỗi sang Rejected hoặc Deferred.
D. Kiểm thử lại
Người kiểm thử sẽ thực hiện kiểm thử lại khi các lỗi đã được chuyển trạng thái sang
Fixed.
-
Nếu lỗi đã được sửa thì chuyển về Verified, sau đó là Closed khi khơng cịn
-
lỗi.
Nếu lỗi chưa được sửa hoặc mới sửa một phần thì chuyển sang Re-opened,
sau đó là Assigned để chuyển giao lại cho lập trình viên để họ tiến hành sửa
tiếp.
CHƯƠNG 2 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
Phần này sẽ viết tóm tắt về những gì sẽ viết ở chương này, có thể nêu tóm tắt một
chút về những gì viết ở chương trước đó.
2.1 Định nghĩa kiểm thử phần mềm
Kiểm thử phần mềm là việc kiểm tra kết quả thực hiện của chương trình máy tính
xem có đúng với mục tiêu đã đặt ra hay không thông qua việc thực hiện ở một số mẫu thử.
Kiểm thử phần mềm là việc tìm ra lỗi trong phiên bản phần mềm, việc kiểm thử này
trong phần mềm sẽ hiển thị ra những thiếu sót mà ta có thể nhận thấy trong hành vi của
phần mềm, và tìm ra những phần mềm khơng tn theo quy định, đi lệch ra khỏi những
yêu cầu của phần mềm.
Theo một số nhà nghiên cứu, kiểm thử phần mềm được định nghĩa như sau:
-
Định nghĩa của Dijkstra: Kiểm thử sẽ hiển thị lỗi hiện có nhưng khơng hiển
-
thị lỗi chưa thấy.
Theo hiệp hội IEEE: Kiểm thử là tiến trình vận hành hệ thống hoặc thành
-
phần dưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra
đánh giá về hệ thống hoặc thành phần đó.
Định nghĩa của Myers: Kiểm thử là tiến trình thực thi chương trình với mục
đích tìm thấy lỗi.
2.2 Mục tiêu của kiểm thử phần mềm
Việc kiểm thử phần mềm nhằm mục tiêu:
-
Đảm bảo phần mềm đáp ứng đúng yêu cầu đề ra.
Giúp ta biết rằng phần mềm đang được thử nghiệm thành công.
Giúp xác nhận được rằng phần mềm đủ điều kiện đến tay người dung.
Để đảm bảo chất lượng phần mềm.
Cung cấp và duy trì một sản phẩm chất lượng cho khách hàng.
2.3 Quy trình kiểm thử phần mềm
Hình 2-3 Quy trình kiểm thử phần mềm
2.3.1 Requirement analysis (Phân tích u cầu)
Đầu vào
Đầu vào của giai đoạn phân tích yêu cầu bao gồm các tài liệu: tài liệu đặc tả yêu cầu,
tài liệu thiết kế hệ thống, tài liệu khách hàng yêu cầu về các tiêu chí chấp nhận của sản
phẩm, bản prototype của khách hàng yêu cầu (nếu có)…v…v.
Hoạt động
•
•
Phân tích yêu cầu là giai đoạn đầu tiên trong quy trình kiểm thử phần mềm.
Bộ phận QA (Quality Assurance – Đảm bảo chất lượng) sẽ thực hiện đọc
•
hiểu, nghiên cứu và phân tích cụ thể các yêu cầu trong tài liệu đặc tả của dự
án hoặc tài liệu của khách hàng. Qua hoạt động này, QA sẽ nắm bắt được các
yêu cầu mà dự án đưa ra.
Ngoài ra, trong q trình phân tích, nghiên cứu tài liệu, nếu có câu hỏi phát
sinh hay đề xuất giải quyết, QA sẽ đưa ra câu hỏi với các bên liên quan như
BA (Business Analyst), PM (Project Manager) và khách hàng để hiểu chính
xác hơn về yêu cầu của sản phẩm.
Đầu ra
Đầu ra của giai đoạn phân tích yêu cầu bao gồm tài liệu chứa các câu hỏi và câu trả
lời liên quan đến nghiệp vụ của hệ thống, tài liệu báo cáo tính khả thi, phân tích rủi ro của
việc kiểm thử phần mềm.
2.3.2 Test planning (Lập kế hoạch kiểm thử)
Đầu vào
Đầu vào của giai đoạn lập kế hoạch kiểm thử là các tài liệu đặc tả đã được cập nhật
thông qua các câu hỏi và câu trả lời được đưa ra trong giai đoạn phân tích yêu cầu, tài liệu
báo cáo tính khả thi, phân tích rủi ro của việc kiểm thử phần mềm.
Hoạt động
•
Xác định phạm vi dự án (Scope): Dự án thực hiện trong thời gian bao lâu?
•
Bao gồm những cơng việc gì cho từng khoảng thời gian xác định? Từ đó đưa
ra kế hoạch thực hiện cho từng công việc nhỏ sao cho phù hợp với đội dự án.
Xác định phương pháp tiếp cận: Phương pháp sẽ dựa vào nhiều thứ: Thời
•
gian cho phép test có phù hợp với hay khơng, u cầu chất lượng từ phía
khách hàng như thế nào? Công nghệ sử dụng để phát triển ứng dụng là
gì?...v…v. Từ đó ta có thể đưa ra các phương pháp và kế hoạch phù hợp nhất
cho quá trình thực hiện của đội dự án sao cho đúng với các tiêu chí của sản
phẩm và kịp tiến độ với các mốc thời gian bàn giao, phát hành.
Xác định các nguồn lực:
o Con người: Có bao nhiêu người tham gia dự án? Ai sẽ thực hiện việc
test phần nào? Có bao nhiêu tester tham gia? Tester và lập trình viên
có kinh nghiệm về lĩnh vực này khơng?
o Thiết bị: Số lượng server, máy tính, điện thoại để thực hiện test là bao
nhiêu?
•
Lên kế hoạch thiết kế công việ test: Bản kế hoạch kiểm thử sẽ bao gồm các
nội dung:
o Liệt kê các chức năng cần kiểm thử.
o Để thực hiện test chức năng này thì cần làm những cơng việc gì, trong
thời gian là bao lâu, cái nào thực hiện trước, cái nào thực hiện sau, ai
là người thực hiện?
o Xác định điều kiện bắt đầu: Xác định những điều kiện tối thiểu để bắt
đầu hoạt động kiểm thử cho từng chức năng.
o Xác định điều kiện kết thúc: Khi có những điều kiện nào thì sẽ kết
thúc việc kiểm thử?
Đầu ra
Đầu ra của giai đoạn này bao gồm các tài liệu như test plan, test estimation, test
schedule.
2.3.3 Test case development (Thiết kế kịch bản kiểm thử)
Đầu vào
Đầu vào của giai đoạn thiết kế kịch bản kiểm thử là test plan, test estimation, test
schedule, các tài liệu đặc tả được cập nhật.
Hoạt động
•
Review tài liệu: Đầu tiên tester cần xem lại tất cả các tài liệu để xác định
•
cơng việc cần làm, các cơng việc có khác gì so với dự án trước khách hàng
đưa cho, chức năng nào cần test, chức năng nào khơng cần test lại nữa. Từ đó
có thể tiết kiệm thời gian mà vẫn có thể đưa ra kịch bản kiểm thử đầy đủ và
hiệu quả.
Viết test case/ check list: Sau đó tester bắt tay vào việc viết test case chi tiết
•
dựa vào kế hoạch đã đưa ra và vận dụng kỹ thuật thiết kế kịch bản kiểm thử.
Test case cần bao phủ được tất cá các trường hợp kiểm thử có thể xảy ra cũng
như đáp ứng đầy đủ các tiêu chí của sản phẩm. Đồng thời tester cũng cần
đánh giá mức độ ưu tiên cho từng test case.
Chuẩn bị dữ liệu kiểm thử: Cùng với việc tạo test case chi tiết, tester cũng cần
•
chuẩn bị trước các dữ liệu kiểm thử cho các trường hợp cần thiết như test
data, test script.
Review test case/ check list: Sau khi hoàn thành, các tester cần xem lại các
test case đã tạo để có thể bổ sung, hỗ trợ lẫn nhau nhằm tranh sai sót trong
thiết kế test case và rủi ro về sau.
Đầu ra
Sau khi hoàn thành thiết kế kịch bản kiểm thử, đội kiểm thử sẽ có các tài liệu: test
design, test case, check list, test data, test script.
2.3.4 Test environment setup (Thiết lập môi trường kiểm thử)
Đầu vào
Đầu vào của giai đoạn cài đặt môi trường kiểm thử là test plan, test case, test data.
Hoạt động
•
Việc cài đặt mơi trường kiểm thử là giai đoạn quan trọng trong vịng đời của
•
phát triển phần mềm. Môi trường kiểm thử sẽ được quyết định dựa trên
những yêu cầu của khách hàng, hay đặc thù của sản phẩm ví dụ như server,
client, network…
Tester cần chuẩn bị một vài test case để kiểm tra xem môi trường cài đặt sẵn
đã sẵn sàng cho việc kiểm thử hay chưa.
Đầu ra
Đầu ra của giai đoạn này là môi trường đã được cài đặt đúng theo yêu cầu, sẵn sàng
cho việc kiểm thử.
2.3.5 Test execution (Thực hiện kiểm thử)
Đầu vào
Tài liệu đầu vào của giai đoạn thực hiện kiểm thử là test plan, test design, test case,
check list, test data, test script.
Hoạt động
•
•
Thực hiện các test case như thiết kế và mức độ ưu tiên đã đưa ra.
So sánh với kết quả mong đợi, báo cáo các bug xảy ra lên tool quản lý lỗi và
•
theo dõi trạng thái của lỗi cho đến khi được sửa thành công.
Thực hiện re-test để xác nhận lỗi đã được sửa hay chưa và thực hiện kiểm thử
•
hồi quy khi có sự thay đổi liên quan.
Đo và phân tích tiến độ: Tester cũng cần kiểm sốt chặt chẽ tiến độ cơng việc
•
của mình bằng cách so sánh tiến độ thực tế với kế hoạch, nếu chậm cần phải
điều chỉnh sao cho kịp với tiến độ dự án, nếu nhanh cũng cần phải điều chỉnh
vì có thể kế hoạch chưa được sát với thực tế của dự án. Từ đó có thể sửa chữa
test plan để phù hợp với tiến độ dự án đã đề ra.
Báo cáo thường xuyên cho PM và khách hàng về tình hình tiến độ dự án:
Cung cấp thơng tin trong quá trình kiểm thử đã làm được những chức năng
nào, cịn những chức năng nào, đã hồn thành được bao nhiêu phần trăm
công việc, báo cáo các trường hợp phát sinh sớm, tránh ảnh hưởng đến tiến
độ công việc.
Đầu ra
Đầu ra của giai đoạn này là test results (kết quả kiểm thử), defect reports (danh sách
các lỗi tìm được).
2.3.6 Test cycle closure (Đóng chu trình kiểm thử)
Đầu vào
Đầu vào của giai đoạn đóng chu trình kiểm thử là bao gồm tất cả các tài liệu liên
quan đã được tổng hợp, ghi chép và hồn thiện đầy đủ trong suốt q trình kiểm thử của dự
án: tài liệu phân tích đặc tả yêu cầu, test plan, test results, defect reports…
Hoạt động
•
•
Đây là giai đoạn cuối cùng trong quy trình kiểm thử phần mềm.
Ở giai đoạn này, QA sẽ thực hiện tổng kết, báo cáo kết quả về việc thực thi
•
test case, bao nhiêu case pass/fail, bao nhiêu case đã được fix, mức độ
nghiêm trọng của lỗi, lỗi còn nhiều ở chức năng nào…Chức năng nào đã
hoàn thành test, chưa hoàn thành test, trễ tiến độ bàn giao.
Đánh giá các tiêu chí hồn thành như phạm vi kiểm thử, chất lượng, chi phí,
•
thời gian, mục tiêu.
Ngoài ra, giai đoạn này cũng thảo luận tất cả những điểm tốt, điểm chưa tốt
và rút ra bài học kinh nghiệm cho các dự án sau, giúp cải thiện quy trình kiểm
thử.
Đầu ra
Đầu ra của giai đoạn này là các tài liệu: test report, test results (final).
2.4 Các giai đoạn kiểm thử phần mềm
2.4.1 Unit testing (Kiểm thử đơn vị)
-
Định nghĩa:
o Một đơn vị phần mềm (Unit) là một thành phần phần mềm nhỏ nhất mà ta
kiểm tra được. Nó bao gồm các hàm (function), thủ tục (procedure), lớp
(class) hoặc các phương thức (method).
o Kiểm thử đơn vị (Unit test) được thực hiện để kiểm tra xem các module
riêng lẻ của mã nguồn có hoạt động đúng hay không. Tức là kiểm tra từng
đơn vị của ứng dụng một cách riêng biệt bởi người lập trình trong mơi
trường phát triển. Đây là thử nghiệm module. Unit tesing là kiểu white box
testing.
