Đồ án tốt nghiệp
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 (235.49 KB, 40 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ử chức năng website bán hàng
link kiện điện tự
Họ và tên sinh viên:
Lê Quang Huy
Điện thoại liên lạc:
Email:
Lớp:
Công Nghệ Phần Mềm
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ề phần mềm, lỗi phần mềm, kiểm thử phần mềm, ứng dụng
và xây dựng kịch bản kiểm thử cho 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ề kiểm thử chức năng.
- Nắm rõ được về kiểm thử chức năng.
- Ứng dụng các kiến thức đã tìm hiểu về kiểm thử phần mềm và kiểm thử
chức năng để tiến hành xây dựng các TestCase và kiểm thử website.
4. Lời cam đoan của sinh viên:
Tôi – Lê Quang Huy – cam kết ĐATN là cơng trình nghiên cứu của bản thân tơi dưới
sự hướng dẫn của GV. Ths. Hồng Anh Đức.
Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép tồn văn của bất
kỳ cơng trình nào khác.
Hà Nội, ngày
tháng
năm
Tác giả ĐATN
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ệ:
Lê Quang Huy
1
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
Hà Nội, ngày tháng
Cán bộ hướng dẫn
Lê Quang Huy
2
năm
Đồ á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, kiểm thử phần mềm
trên nền web. Ngoài ra đề tài đi sâu vào tìm hiểm kiểm thử chức nă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ử trang web.
Nội dung đồ án gồm có các phần sau:
-
-
-
-
Lê Quang Huy
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: Kết quả thử nghiệm: Chương này trình bày các chức năng
của trang web bán hàng điện tử, 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 lại.
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 … – 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. Thầy đã trực tiếp hướng
dẫn, chỉ bảo, giúp em khắc phục những khó khăn, thiếu sót để có thể hồn thành các phần
trong đồ án tốt nghiệp từ lý thuyết cho tới thực hành
Mặc dù đã cố gắng với tất cả nỗ lực của bản thân để hồn thiện đồ án, nhưng do thời
gian có hạn, năng lực và kinh nghiệm còn hạn chế nên đồ án khơng thể tránh khỏi những
thiếu sót. Kính mong nhận được sự đóng góp ý kiến từ phía thầy cơ, bạn bè để em có thể
nâng cao kiến thức của bản thân, hoàn thiện đồ án được tốt hơn.
Em xin chân thành cảm ơn!
Hà Nội, ngày……tháng……năm
Sinh viên thực hiện
Lê Quang Huy
Lê Quang Huy
4
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
MỤC LỤC
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP...............................................................I
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP..................................................................III
LỜI CẢM ƠN......................................................................................................................IV
MỤC LỤC.............................................................................................................................V
DANH MỤC CÁC HÌNH VẼ............................................................................................VII
DANH MỤC CÁC BẢNG BIỂU.....................................................................................VIII
DANH MỤC CÁC TỪ VIẾT TẮT......................................................................................IX
MỞ ĐẦU................................................................................................................................1
CHƯƠNG 1 TỔNG QUAN PHẦN MỀM VÀ LỖI PHẦN MỀM........................................2
1.1 Định nghĩa phần mềm.................................................................................................2
1.2 Đặc trưng của phần mềm.............................................................................................2
1.3 Vòng đời phần mềm....................................................................................................2
1.4 Chất lượng phần mềm và đảm bảo chất lượng phần mềm..........................................3
1.4.1 Chất lượng phần mềm..........................................................................................3
1.4.2 Đảm bảo chất lượng phần mềm...........................................................................3
1.4.3 Một số tiêu chí trong đảm bảo chất lượng phần mềm:........................................4
1.5 Lỗi phần mềm..............................................................................................................5
1.5.1 Định nghĩa...........................................................................................................5
1.5.2 Các nguyên nhân gây ra lỗi phần mềm................................................................6
1.5.3 Một số quy tắc xác định lỗi phần mềm................................................................7
1.5.4 Vòng đời của lỗi...................................................................................................7
1.5.5 Quy trình xử lý lỗi phần mềm............................................................................10
CHƯƠNG 2 TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM................................................13
2.1 Định nghĩa kiểm thử phần mềm................................................................................13
2.2 Vai trò của kiểm thử phần mềm.................................................................................13
2.3 Mục tiêu của kiểm thử phần mềm.............................................................................14
2.4 Quy trình kiểm thử phần mềm...................................................................................14
2.4.1 Requirement analysis (Phân tích yêu cầu).........................................................14
2.4.2 Test planning (Lập kế hoạch kiểm thử).............................................................15
2.4.3 Test case development (Thiết kế kịch bản kiểm thử)........................................16
2.4.4 Test environment setup (Thiết lập môi trường kiểm thử)..................................16
Lê Quang Huy
5
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
2.4.5 Test execution (Thực hiện kiểm thử).................................................................17
2.4.6 Test cycle closure (Đóng chu trình kiểm thử)....................................................17
2.5 Các giai đoạn kiểm thử phần mềm............................................................................18
2.5.1 Unit testing (Kiểm thử đơn vị)...........................................................................18
2.5.2 Integration testing (Kiểm thử tích hợp).............................................................19
2.5.3 System testing (Kiểm thử hệ thống)..................................................................19
2.5.4 Acceptance testing (Kiểm thử nghiệm thu).......................................................19
2.6 Các kỹ thuật kiểm thử phần mềm..............................................................................20
2.6.1 Kiểm thử hộp đen..............................................................................................20
2.6.2 Kiểm thử hộp trắng............................................................................................21
2.6.3 Kiểm thử hộp xám.............................................................................................22
2.7 Kiểm thử tự động.......................................................................................................23
2.7.1 Khái niệm kiểm thử tự động..............................................................................23
2.7.2 Tại sao phải kiểm thử tự động...........................................................................23
2.7.3 Ưu điểm và nhược điểm của kiểm thử tự động.................................................24
2.7.4 Khi nào nên sử dụng kiểm thử tự động?............................................................24
2.7.5 Một số công cụ kiểm thử tự động......................................................................25
2.8 Kiểm thử chức năng..................................................................................................25
2.8.1 Kiểm thử chức năng là gì?.................................................................................25
2.8.2 Mục đích của kiểm thử chức năng.....................................................................25
CHƯƠNG 3 Kết quả thử nghiệm.........................................................................................27
3.1 Bài toán kiểm thử......................................................................................................27
3.2 Kịch bản kiểm thử.....................................................................................................27
3.3 Báo cáo kết quả kiểm thử..........................................................................................27
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN............................................................................27
PHỤ LỤC.............................................................................................................................31
Lê Quang Huy
6
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
DANH MỤC CÁC HÌNH VẼ
Lê Quang Huy
7
Đồ á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
Lê Quang Huy
8
Đồ á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
STT Từ viết tắt Từ tiếng Anh
Từ và nghĩa tiếng Việt
1
Test case
Trường hợp kiểm thử
Test suite
Một bộ bao gồm nhiều test
case liên quan với nhau
TC
2
Lê Quang Huy
9
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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 luôn 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ở, hồn tồ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.
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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 toá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à ln 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 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
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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 quá trình phát triển cho dù
khơng được nói đến rõ ràng trong hợp đồng.
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
-
độ 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ố
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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.
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
-
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 tuân 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”.
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
-
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.
Đồ án tốt nghiệp chun ngành Cơng Nghệ Phần Mềm
Hình 1-1 Sơ đồ vòng đời của lỗi
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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:
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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 tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
-
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 đó.
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
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 Vai trị của kiểm thử phần mềm
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ừ từ khi bắt đầu có ý tưởng cho đến khi đưa ra sản
phẩm phần mềm thực tế thì 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ế
hệ thống
Hai thập kỷ
1960 - 1970
10%
Thập kỷ
1980
Thập kỷ
1990
Thiết kế
chi tiết
Lập trình
và kiểm
thử đơn vị
80%
20%
40%
Tích hợp
và kiểm
thử tích
hợp
10%
60%
30%
Kiểm thử
hệ thống
20%
30%
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
Như vậy, một sản phẩm phần mềm không chi đơ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, cơng 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 quy 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.
2.3 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.4 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.4.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 quá 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
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
Đầ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.4.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
Đồ án tốt nghiệp chuyên ngành Công Nghệ Phần Mềm
Đầ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.4.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.4.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
