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

Báo cáo bài tập lớn kiểm thử website cửa hàng bán Điện thoại

56 6 0
Tài liệu được quét OCR, nội dung có thể không chính xác
Tài liệu đã được kiểm tra trùng lặp

Đ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

Tiêu đề Báo Cáo Bài Tập Lớn Kiểm Thử Website Cửa Hàng Bán Điện Thoại
Tác giả Đăng Thị Trà My, Mai Văn Hoa, Đàm Quang Huy, Ngụ Văn Phi, Chu Xuân Việt
Người hướng dẫn Th.s Đặng Thị Khánh Linh
Trường học Trường Đại Học Thành Đê
Chuyên ngành Đảm Bảo Chất Lượng Phần Mềm
Thể loại Báo cáo
Năm xuất bản 2022
Thành phố Hà Nội
Định dạng
Số trang 56
Dung lượng 4,62 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Nhìn chung, một quy trình phát triển phần mềm bao gồm các giai đoạn chính như sau: 1.3.2 Giải pháp, yêu cầu Nhiệm vụ: Thực hiện khảo sát chi tiết yêu cầu của khách hàng đề từ đó tông hợp

Trang 1

BAO CAO BAI TAP LON Kiém Thử Website Cửa Hàng Bán Điện Thoại

Giang Viên Hướng Dẫn

Mai Van Hoa Msv: 2000215 Dam Quang Huy Msv: 2000235 Ngô Văn Phi Msv: 2000223

Chu Xuan Viét

Msv: 2000023

Hà Nội, Năm 2022

Trang 2

MUC LUC

Contents

MỤC LỤC 22-221 22112112211221122112211211211121122121101121212121211221 1e 2 DANH MỤC CÁC HÌNH 225-221 22122112211221122112111211221121101112222 21a 5 CHƯƠNG I: TỎNG QUAN VỀ KIỀM THỬ PHÂN MÉM - 2252 2 2E E22 sec 7

1.2 Phân loại phần DEM coe cccccscscscsesesevevevevevesevavscsvavacstavstsssvstssststsessseseseseresesevevsevevsvevesesees 7

1.3 Quy trinh phat trién phan MEM cece ccccecseesesseseeseesessestssesevsvesesevsvssteevstsssevevsseees 8 1.3.1 Quy trình phát triển phan MOM ceccccecceccssesceseesessessesesecsecevsecsecsvssnsevsvsevecseees 8

1.3.2 Giải pháp, yêu cầu - c1 1221 12H 1n 1 1n 2tr re 8

1.3.3 Thiết kỂ - 2121 211212211211222121121121111111211112111222 rau 8 1.3.4 Lap trim cccccecccesesesseesssessessvesssessvessitsareesssssisssesssiessesssesseetavesiteareavessesees 9 1.3.5 Kiểm thử - 2-21 221 212211211221121121112112111211 211121121 11121221112 a 9 1.3.6 Triển khai 2-2 221 21121121122112112211211221121122112111112111121121121221212 1 re 9

1.4 Một số mô hình phát triển phần mềm 2-1 1 E1 1E 1E E2EEE1112112111 E1 1 xe rre 9

1.4.2 Mô hình Agile (Quy trình Scrum)) - - c1 2c 121112123121 1111211115115 rez II

1.5 Lỗi phần mềm 2-21 E1 1211 1112111111111 112111 12111 121111 ng ng gr rug 16 1.6 Kiểm thử phần mềm ¿6 St 1 E1 E11121E112111111211112112111121 111 11rrro 17 1.7 Các kỹ thuật kiêm thử phần mềm - S2 1 EEEEE1E1121111 117111 11 Xe 17 1.8 Kiểm thử tự động c2 t2 1211 11 222 11 12 11 1 n1 ngu 18

1.8.1 Khái niệm về kiểm thử tự động - L0 112 222211211110 TH H11 115111111 ke ryu 18

1.8.2 Quy trình kiểm thử tự đông 1-5 St HE 1x 1111 HH Huy 20

1ã3 Mu ca

Trang 3

su dung kiécm

thưc tự đông

Trang 4

1.8.4 Sử dụng kiểm thử tự động vào khi nảo - 5c nề 2E 1 21tr Hee 21

185 Mô |

ta SÔ công cu akiêcm thưc tự đông L1 2 22212121111 111221221118 1tr

CHƯƠNG 2: GIỚI THIỆU DỰ ÁN VÀ THỰC HIỆN KIEM THỬ -:-: 22

1 Giới thiệu về dự án - 2c HH HH2 Hư ườu 22 1.2 Phân tích yêu cầu hệ thống 2-5 1S 2112121121121211 2112111 1E tre 22

I8 an 22

1.2.2 Chi tiết chức năng - St 1E 12 121111111 112111 121111211121 1n Hài 23 1.2.3 Ưu, nhược điểm : 5 HH HH2 Hưng 24

1.4 Giao diện sản phâm - 5c sc t SE 111121121111 Ẹ1171111 1 111011 111g g Hy 25

2 Quy trình thực hiện fest Q0 1211112122111 121 11211101111 5151 1811111115 111g key 30 2.1 Thiết kế testplan cho dự án L0 220 1211111112 215 11511501 111 2x khay 30

P Ni on 30 2.1.2 Test ca nh 30 2.1.3 Test Items/ Features to be Tested cty 112 1 ke 30 PP oi na e 31 2.1.5 Test Strategy ccc cccccccccceccsscccsccecnsceceeeeecesseeeesseeeseeeesseeeceseeeceseeecssseeessseeesseeenseees 31 PB na ÏŠ6 (q 32 2.1.7 Công số và schedule - 5: scs 2x 11211112112 111 11 111101122111 ngưng 32 2.1.8 Thành viên tham g1a - 2 2211222111211 1211 1121512111151 1 1811101118111 1 1111k kg 32

2.1.9 Tiêu chuẩn kết thúc tt HH 0H àờ 33

2.1.10 Tiêu chí tạm ngừng và tiêu chí bắt đầu lại(sau khi tạm ngừng) -. 33

"em n ae 33

Trang 5

2.1.12 Cong cu

Trang 6

2.2 Thiét ké cAc testCase c cccccccccccssssvevsvesessssevevesesssvsvaressssseavsvavssessssaveevesessatsssevavavstecsesees 34 2.2.1 Testcase Form đăng ký L Q0 1n v12 12 115115 121111111 5111 111k tk 35 2.2.2 Test form đăng nhập Q20 02011122112 1111 1157122 1115115111 He 43

2.2.3 Test case thêm sự kiện cho website bán hàng 2 2 2c 12221222 sen 48

Churong 3 KET LUAN occcccccccscccscsssessessessvssessvssvssscsvssresussessucsvssavsusssesevsuesevsessvsesevsvsevsvsevevess 52

Trang 7

1 Giao diện đăng nhập - c0 2012221212111 1111211121111 11151120111 T118 1g 11kg 25

2 Giao diện đăng nhập - 0 200222121211 1211 1121512111111 151120111 51118111 1 1k1 key 26

4 Giao diện quản Ïý cece 1211122112 1121152 15 11515 111k tk k kg xen 27

5 Giao điện thêm sản phẩm - S1 SE E1 1121111211212 121210111 1 1tr rug 28

Trang 8

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

Tuy nhiên, hoạt động kiêm thử thường gặp nhiều khó khăn:

- Thứ nhất, kiểm thử các hệ thống phức tạp đòi hỏi rất nhiều nguồn tài nguyên và chỉ phí cao

- Thứ hai, tiến trình phát triển phần mềm luôn trải qua nhiều hoạt động biến đối thông tin, sự mắt mát thông tin trong quá trình biến đôi là yếu tô chính làm cho hoạt động kiêm thử khó khăn

- Thứ ba, kiểm thử chưa được chú trọng trong đào tạo con người

- Cuối cùng, không tôn tại kỹ thuật kiểm thử cho phép khăng định một phần mềm hoàn toàn

đúng đắn hay không chứa lỗi Với mục đích phát hiện lỗi, kiêm thử phần mềm thường phải

trải qua các bước: tạo dữ liệu thử, thực thị phan mềm trên dữ liệu thử va quan sát kết quả

nhận được Trong các bước này, bước tạo đữ liệu đóng vai trò quan trọng nhất, bởi vì chúng

ta không thể tạo ra mọi dữ liệu từ miền vào của chương trình, mà chúng ta chỉ có thể tạo ra

các dữ liệu thử có khả năng phát hiện lỗi cao nhất Vấn đề đặt ra là làm thế nào đề đánh giá

được khả năng phát hiện lỗi của một bộ dữ liệu thử?

Trang 9

CHUONG 1: TONG QUAN VE KIEM THU PHAN MEM

Việc thực thi nhiệm vụ có thê thể là tự động hoặc thực hiện theo các thông tin, dữ

liệu đầu vào

Phải có phần cứng thì phần mềm mới thực thi được Thông thường là máy tính, các thiết bị giải trí truyền thông, bộ điều khiển trên máy công cụ - ô tô V.v

1.2 Phân loại phần mềm

Phần mềm được chia thành 2 loại chính xét theo từng mục đích sử dụng khác nhau:

-_ Theo phương thức hoạt động: Phân theo phương thức hoạt động thì được chia

thành các loại khác nhau bao gồm các loại như sau :

» _ Phần mềm hệ thống dùng đề vận hành máy tinh nói riêng và các thiết bị điện tử

nói chung Ví dụ: hệ điều hành may tinh Windows, Linux, Unix; Các trình diéu khiển (driver), phan syn (firmware) va BIOS Hé diéu hanh di déng ios, Android, Windows Phone

se Phần mềm ứng dụng - phần mềm máy tính : Các phần mềm văn phòng (Microsoft Office, openoffice), trò chơi điện tử (game), các công cụ & tiện ích khác (ví dụ như phần mềm quản lý chỉ tiêu cá nhân, phần mềm quản lý công việc,

`

Trang 10

¢ Phan mém dich ma (trinh dich) Bao gém trinh bién dich và trình thông dịch,

cụ thê là chứng dịch các câu lệnh từ mã nguồn của ngôn ngữ lập trình sang dạng ngôn ngữ máy sao cho thiết bị thực thi có thê hiểu được

e Nén tảng ứng dụng: như ASP.NET - nền táng ứng dụng web của Microsoft, cái

này hỗ trợ việc tạo ra các ứng dụng web, dịch vu web (web service)

- Theo kha nang hay quyền hạn can thiệp vào mã nguồn thì được chia thành các loại như sau:

¢ Phần mềm mã nguồn đóng (closed source software): Là phần mềm mà mã nguồn của nó không được công bố Đề sử dụng phần mềm nguồn đóng phải được cấp bản quyền (mua, tặng là tùy)

e Phần mềm mã nguồn mở (open source software): Là phần mềm mà mã nguồn của nó được công bồ rộng rãi, công khai và cho phép mọi người tiếp tục phát triển phan mềm đó Thường thì loại phần mềm này miễn phí

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

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

Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản xuất ra một sản phẩm phần mềm Nhìn chung, một quy trình phát triển phần mềm bao gồm các giai đoạn chính như sau: 1.3.2 Giải pháp, yêu cầu

Nhiệm vụ: Thực hiện khảo sát chi tiết yêu cầu của khách hàng đề từ đó tông hợp vào tài liệu giải pháp Tài liệu này phải mô tả đầy đủ các yêu cầu về chức năng, phi chức năng

và giao diện

Kết quả: Đầu ra của giai đoạn này là Tài liệu đặc tả yêu cầu

1.3.3 Thiết kế

Nhiệm vụ : Thực hiện thiết kế và tổng hợp vào tài liệu thiết kế

Kết quả: Tài liệu thiết kế tổng thẻ, thiết kế module, thiết kế CSDL

10

Trang 11

1.3.4 Lap trinh

Nhiệm vụ: Lập trình viên thực hiện lập trình dựa trên tài liệu Giải pháp và Thiết kế

đã được phê duyệt

Kết quả: Source code

1.3.5 Kiểm thứ

Nhiệm vụ: Tester tạo kịch bản kiêm thử (test case) theo tài liệu đặc tả yêu câu, thực hiện kiểm thử và cập nhật kết quả vào kịch bản kiểm thử, log lỗi trên các tool quản lý lỗi Kết quả: Test case, lỗi trên hệ thông quản lý lỗi

1.3.6 Triển khai

Nhiệm vụ: Triên khai sản phâm cho khách hàng

Kết quả: Biên bản triển khai với khách hàng

1.4 Một số mô hình phát triển phần mềm

1.4.1 Mô hình chữ V

Giới thiệu về mô hình chữ V:

Trong kiểm thử phần mềm (V Model) còn được gọi là mô hình xác thực hay mô hình xác minh Nó là mô hình có tính ký luật cao, trong đó, giai đoạn kiểm thử chạy song song với mỗi giai đoạn phát triển phần mềm

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

- - Hoạt động tốt với các dự án có quy mô vừa và nhỏ

- Dễ đàng quản lý vì mỗi giai đoạn có các mục tiêu và mục tiêu được xác định rõ ràng

Trang 12

- Toan bé quy trinh duge chia thanh 2 nhom giai đoạn tương ứng nhau là phát triển

và kiểm thử Mỗi giai đoạn phát triển sẽ tiến hành song song với một giai đoạn kiêm thử tương ứng Do đó, các lỗi được phát hiện sớm ngay từ đầu

Uu điêm nhược điểm của mô hình chữ V:

Ngay từ lúc nhận được tài liệu đặc tả yêu cầu, tester sẽ tham gia vào review tải

liệu đặc tả yêu cầu sau đó lên kế hoạch và thực hiện viết test case Lỗi được phát

hiện từ giai đoạn này sẽ ít tốn thời gian và chỉ phí hơn các giai đoạn sau

°® Nhược điểm

Trong mô hình chữ V, các yêu cầu vẫn được đưa vào thực hiện cùng l lúc mà rủi

ro về thay đôi yêu cầu từ phía khách hàng là rất lớn Do đó, mô hình này vẫn có thê gặp rắc rối khi khách hàng thường xuyên thay đôi yêu cầu

12

Trang 13

1.4.2 Mo hinh Agile (Quy trinh Scrum)

Team members describe:

~ Whatf've done since

Backlog the last Scrum meeting items What I pian to do expanded

by team 30 DAYS ieouee | have thet |

heed help to resolve New Functionality

Hình 1 2 Toc D6 Xứ Lý Của Phan Mém

mềm hoạt động thực tế

“+ Dac điểm của mô hình Agile: là một phương pháp phát triển phần mềm linh hoạt

đề làm sao đưa sản phẩm đến tay người dùng cảng nhanh càng tốt

+* Đặc trưng của mô hình Agile

Trang 14

Tinh lap (Interactive):

Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại Các phân đoạn (được gọi

là Interation hoặc Sprint) này thường có khung thời gian ngắn ( từ I đến 4 tuần) Trong mỗi phân đoạn này , nhóm phát triển phải thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cau, thiết ké, triển khai, kiểm thử đề cho ra các phần nhỏ của sản phẩm Các phân đoạn Sprint lặp đi lặp lại trong Agile: các phương pháp Agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất

có thể, không thực hiện lập kế hoạch dài hạn

Tính tiệm tiến và tiễn hóa:

Cuối các phân doan Sprint, nhom phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng Các phần nhỏ này thường đầy đủ, có khả năng chạy tốt, được kiểm thử cần thận và có thể sử dụng được ngay Theo thời gian, các phân đoạn này nối tiếp các phân đoạn kia, các phần chạy được tích lũy và lớn dân lên cho tới khi toàn bộ yêu cầu của

khách hàng được thỏa mãn

Tính thích ứng:

Do cae sprint chi kéo dài trong khoảng 1 thời gian ngắn và việc lập kế hoạch cũng được điều chính liên tục, nên các thay đổi trong quá trình phát triển đều có thể áp dụng theo cách thích hợp Theo đó, các quy trình Agile thường thích ứng rất tốt với các thay

đối

“+ Cac cong cu (artifacts) Scrum:

Product backlog: Day la danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án Product

Owner chiu trach nhiệm sap xếp độ ưu tiên cho từng hạng mục (Product Backlog Item)

trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa

Sprint backlog: Đây là bản kế hoạch cho một Sprint, là kết quả của buôi họp lập

kế hoạch (Sprint Planning) Với sự kết hợp của Product Owner, nhóm sẽ phân tích các

14

Trang 15

Backlog dưới dạng danh sách công việc (TODO list)

Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng

mục được sắp theo thứ tự ưu tiên Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn tr | đến 4 tuần làm việc

(gọi là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment)

Đội sản xuất cùng họp với Product Owner đề lập kế hoạch cho từng Sprint Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cân làm trong suôt một Sprint

Cac Sprint sé duoc lap đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất

Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) đề chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau Nhóm được trao quyên đề tự quản lí và

tô chức lấy công việc của mình đề hoàn thành công việc trong Sprint

Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh, sẵn sảng chuyên giao (shippable) cho khác hang Budi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thê chuyên giao những

gi, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiền

Trang 16

Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ chức họp Cai tién Sprint (Sprint Retrospective) dé tim kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint s* Bao gồm 4 cuộc họp như sau:

Sprint Planning (Hop ké hoach Sprint)

Nhóm phát triển họp với Product Owner để lên kế hoạch làm việc cho một

một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghĩ với các tình

hình thực tiễn trong tiến trình đi đến sản phẩm

Daily Scrum (Hop Scrum hang ngay)

Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phut

dé Nhóm Phát triển chia sẻ tiến độ công việc Trong cuộc hợp này, từng người trong

nhóm phát triển lần lượt trình bày dé tra lời 3 câu hỏi sau:

- _ Hôm qua đã làm gi?

- _ Hôm nay sẽ làm gi?

l6

Trang 17

- Co kho khan tro ngai gi khéng?

Sprint Review (Hop So két Sprint)

Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay

đôi cần thiết cho sản phẩm

Sprint Retrospective (Hop Cai tién Sprint)

Dưới sự trợ giúp của Scrum Master, nhóm phát trién sé ra soat lai toan diện Sprint vừa kết thúc và tìm cách cải tiễn quy trình làm việc cũng như bản thân sản pham.Hop cai tién sprint bao gém 3 vai trò:

Product Owner: Là người chịu trách nhiệm về sự thành công dự án, người

định nghĩa các yêu cầu cho sản phẩm và đánh giá đầu ra cuối cùng của các nhà phát triển phần mềm

Scrum Master: Là người đảm bảo các sprint được hoàn thành theo đúng quy trinh Scrum, giúp đỡ loại bỏ các trở ngại cho đội dự án

Development Team: Là tập hợp của từ 5 đến 9 thành viên chịu trách nhiệm trực tiếp tham gia sản xuất Tùy theo quy mô của dự án đề bố trí số thành viên cho phủ hợp

Ưu điểm: Phù hợp với các yêu cầu / nghiệp vụ hay thay đổi, hoặc hệ thống nghiên cứu

do làm theo từng giai đoạn ngắn ngày, có thê nhìn thấy những rủi ro hay những điểm

chưa phù hợp đề thay đổi

Nhược điểm

- _ Thiếu sự nhân mạnh về thiết kế và tải liệu cần thiết

- _ Quy mô nhân lực thường giới hạn , sẽ có trở ngại lớn nếu nguồn nhân lực yêu

cầu vượt quá con 36 này ví dụ trong các cuộc họp trao đôi

- _ Yêu cầu nguôn nhân lực phải có kiên thức và am hiéu vé Agile

Trang 18

1.5 Léi phan mém

Lỗi phần mềm là một lỗi hay hỏng hóc trong 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

R

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ụ chính thứ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 quá trình hoạt động

Hầu hết các lỗi phát sinh từ các lỗi và sai lầm được tạo ra trong mã nguồn của chương trình hoặc thiết kế của chương trình hoặc trong các thành phần và hệ điều hành được sử dụng bởi các chương trình đó Một số ít các lỗi được gây ra bởi trình biên địch sản xuất mã không chính xác Một chương trình có chứa nhiều lỗi (bug) hoặc lỗi ảnh hưởng nghiêm trọng đến chức năng của nó, (2zgøy) Lỗi có thê kích hoạt các lỗi khác tạo ra hiệu ứng gợn

Lỗi có thể có hiệu ứng hoặc khiến chương trình bị sập hoặc treo máy tính Các lỗi khác như

chỉnh sửa điều kiện truy cập là lỗi bảo mật và có thê giúp cho phép một số người dùng qua được các hàng rào bảo mật để truy cập một số trang web trái phép hoặc mua bán qua các nên tảng công nghệ bị cắm bởi chính phủ

Một số lỗi phần mềm có thê nghiêm trọng tới mức thảm họa Lỗi trong mã điều khiển máy xạ trị Therac-25 đã trực tiếp khiến bệnh nhân tử vong trong những năm 1980 Năm

1996, tên lửa Ariane 5 của Cơ quan Vũ trụ Châu Âu trị giá | ty USD đã bị phá hủy chưa đầy một phút sau khi phóng đo lỗi trong chương trình máy tính hoa tiêu cài đặt trên tàu Vào tháng 6 năm 1994, một máy bay trực thăng Chmook của Không quân Hoang gia da đâm vào Mull of Kintyre, giết chết 29 người Điều này ban đầu được coi là lỗi phi công, nhưng một cuộc điều tra của Computer Weekly đã thuyết phục một cuộc điều tra của House

of Lords rằng nó có thê là đo lỗi phần mềm trong may tính điều khiển động cơ của máy bay

Năm 2002, một cuộc điều tra do Mỹ Bộ Thương mại của Viện Tiêu chuẩn và Công

nghệ kết luận rằng "lỗi phần mềm, hoặc sai sót trong lập trình là nguyên nhân phô biến và

18

Trang 19

gây hại đến nỗi chúng đã hao tốn nền kinh tế Mỹ ước tính khoảng 59 tỷ USD mỗi năm, tương đương khoảng 0,6% tổng sản phẩm quốc nội"

1.6 Kiểm thứ phần mềm

Kiém thir phan mém (software tcsting) là hoạt động nhằm tìm kiếm và phát hiện ra các lỗi của phần mềm, đảm bảo phần mềm chính xác, đúng và đầy đủ theo yêu cầu của khách hàng, yêu cầu của sản phâm đã đặt ra Software testing cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm điều này cho phép đánh giá và hiều rõ các rủi ro khi thực thi phần mềm Ngoài ra kiểm thử phần mềm sẽ giúp ching ta:

- Han ché nhiing thất bại sau này,nâng cao chất lượng cho sự ohats trienr cho sản phẩm

- Chí phí kiểm thử chiếm 4-50% tổng coonng sức phát triển

- ->30% tông thời igan phát triển

- Với câc sản phâm liên quan đến tỉnh mạng thì có thể gấp từ 3-5 lần

Kiểm thử tốt sẽ :

- _ Giảm chỉ phí phát triển

- _ Tăng độ tin cây của sản phâm phần mềm

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

Các phương pháp kiếm thử phần mềm bao gồm:

- _ Kiểm thử hộp trăng (white box testing): Trong kiêm thử hộp trắng cầu trúc mã, thuật toán được đưa vào xem xét Người kiểm thử truy cập vào mã nguồn của chương trình

đề có thê kiểm tra nó

- Kiém thir hop den (black box testing) : Kiém tra các chức năng của hệ thông dựa trên

ban dac ta yéu cau

- Kiém tht hép xam (gray box testing): La sw két hop gitra black box testing va white box testing

Kiểm thử phần mềm đóng vai trò rat quan trong :

Trang 20

Kiểm thử phần mềm là hoạt động đảm bảo chất lượng phần mềm và mang tính sống còn trong các dự án sản xuất phần mềm Vì vậy nó đã trở thành quy trình bắt buộc trong các dự án phần mềm hiện nay

Kiểm thử phần mềm đề tránh những rủi ro, lỗi phát sinh trong suốt quá trình tạo ra sản phâm

Lỗi càng phát hiện ra sớm càng giúp tránh được rủi ro và chỉ phí

Mục đích của kiểm thử phần mềm:

Kiểm thử phần mềm đề đánh giá phần mềm có đạt yêu cầu mong đợi hay có sai sót nào không?

Phần mềm có làm việc như mong muốn không?

Phần mềm có giải quyết được yêu cầu của khách hàng không?Nó làm được gì mà người dùng mong đợi?

Người dùng có thích nó không?

Nó có tương thích với các hệ thông khác của chúng ta hay không?

1.8 Kiểm thử tự động

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

Kiểm thử tự động: Là xử lý một cách tự động các bước thực hiện các testcase, kiểm thử tự động bằng một công cụ nhằm rút ngắn thời gian kiểm thử.Là một kỹ thuật tự động trong đó người kiêm thử tự viết các tập lệnh và sử dụng phần mềm phù hợp để kiêm thử phan mềm Nó về cơ bản là một quá trình tự động hóa của một quy trình kiêm thử thủ công Giống như kiểm thử hồi quy, kiểm thử tự động cũng được sử dụng để kiểm thử ứng dụng theo quan diém tải, hiệu năng và ứng suất

Ưu điềm của kiêm thử tự động

- _ Đâu tiên, chúng ta sẽ cùng tìm hiệu về hiệu quả của việc kiêm thử tự động

- _ Các bài kiểm tra có thể được thực hiện một cách nhanh chóng

20

Trang 21

Nói chung ưu điểm của kiểm thử tự động là nó chạy nhanh hon kiểm thử thủ

công Tuy nhiên, hãy nhớ rằng tốc độ thực thi sẽ khác nhau tùy thuộc vào nội

dung được thực thi va các công cụ được sử dụng

Có thê phát hiện sớm các lỗi

Bằng cách chạy các bài kiểm thử tự động mỗi khi quá trình phát triển của bạn

được hoàn thành như bổ sung tính năng mới, sửa lỗi Bạn có thể phát hiện sớm các lỗi và thực hiện hành động ngay lập tức Việc kết hợp kiểm thử tự động vào

quy trình thực thi CI có thê hiệu quá hơn

Có thể thực hiện kiểm tra một cách chính xác

Loại bỏ lỗi của con người khi thực hiện các bài kiểm tra, cho phép các bài kiểm

tra chính xác hơn

Có thể thực hiện kê cả thiếu nguồn nhân lực

Bằng cách tự động hóa việc kiêm tra, bạn có thể kiểm tra ngay cá khi bạn thiểu nhân lực để thực hiện việc kiểm tra đối với ứng dụng, phần mềm của bạn Kiểm tra thủ công cũng cho phép kiểm tra hiệu suất quy mô lớn không thực tế và kiếm

tra so sánh lượng lớn đữ liệu

Nhược điểm của kiểm thử tự động

Tiếp theo, chúng ta sẽ tìm hiểu về nhược điểm của việc kiểm thử tự động Không

phải tất cả các bài kiểm tra đều có thê tự động hóa Để có hiệu quả với tự động hóa, điều quan trọng là phải xác định thử nghiệm nào để tự động hóa Dưới đây là

một số điều cần ghi nhớ cho điều đó

Có thê bỏ sốt lỗi do con người

Kiểm thử tự động bao gồm các bài kiểm tra tốt và không tốt Ví dụ, với các thử nghiệm đễ xáy ra lỗi do con người và các thử nghiệm được lặp lại thì các thử nghiệm được thực hiện không thường xuyên hoặc quy trình không cô định thì

không phù hợp với tự động hóa

Hoạt động bảo trì

Trang 22

Kiểm thử tự động không có hiệu quả ngay lập tức Hiệu quả có thể đạt được bằng

cách tiếp tục vận hành nó nhiều lần Hoạt động bảo tri la cần thiết để kiểm thử tự động được tiếp tục hoạt động

Kiểm tra tự động chỉ có thê kiểm tra những gì chúng ta thiết kê

- Chỉ nội dung kiêm thử đã được thiết kế dé thử nghiệm mới có thê được tự động

hóa

- Chi phi cao

- Chi phi ban dau cao hon voi kiém thử thủ công, chăng hạn như chỉ phí viết mã

kiểm tra và chi phí học cách sử dụng thành thạo các công cụ

1.8.2 Quy trình kiểm thử tự đông

Quy trình kiểm thử tự động bao gồm:

- Tester sử dụng các kịch bản tự động (automation scripts) và thực thi cac script dé chạy ứng dụng với sự giúp sức của các automation tool Một khi script đã sẵn sàng thì việc thực thi kiểm thử có thê điễn ra nhanh chóng và hiệu quả

- - Các hoạt động của kiểm thử tự đông:

- _ Phân tích yêu cầu/Xác định môi trường/công cụ

- _ Xác định tiêu chí đầu ra

- _ Lên kế hoạch và kiểm soát

- _ Thiết lập môi trường kiêm thử

- _ Triển khai thiết kế kiểm thử

- _ Thực thi kiểm thử

- - Phân tích, báo cáo

1.83 Mu đích cưa việc sử dụng kiếm thư tư đông

£

- Kiểm thử tự động với các mục đích:

- _ Giảm bớt công sức và thời gian thực hiện quá trình kiểm thử

- Tang độ tin cậy

22

Trang 23

- Rén luyén k¥ nang lập trình cho kiểm thử viên

- _ Giảm chỉ phí cho tông quá trình kiểm thử

1.8.4 Sử dụng kiểm thử tự động vào khỉ

nào Khi nào cần kiểm thử tự động:

- Không đủ tài nguyên: Khi số lượng testcase quá nhiều mà kiểm thử viên không thê hoàn tất trong thời gian cụ thê

- - Kiểm tra hồi quy: Nâng cấp phần mềm, kiểm tra lại các tính năng đã chạy tốt và những tính năng đã sửa Tuy nhiên, việc này khó đảm bảo về mặt thời gian

- Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt (Đo tốc độ trung bình xử lý một yêu cầu của Web server, xác định cầu hình máy thấp nhất

mà phần mềm vẫn có thể hoạt động tốt)

185 số công cụ kiểm thư tự đông

Môt số công cụ giu p Ích trong kiểm thư tự đông:

Trang 24

CHUONG 2: GIOI THIEU DU AN VA THUC HIEN KIEM THU

1 Giới thiệu về dự án

Hiện này nhu cầu mua sắm đồ dùng thiết bị thông minh đang trở lên rất phố biến các hình thức mua bán cũng ngày càng đa dạng đề bắt kịp với xu hướng hiện đại hóa.Các trang

web bán hàng cũng xuất hiện vô cùng nhiều.Chính vì thế nhóm em xin giới thiệu tới thay

cô và các bạn mô hình trang web bán đồ dùng thiết bị điện thoại thông minh

Các chức năng chính của trang web:

Thêm sửa,xóa sản phâm

1.2 Phân tích yêu cầu hệ thống

1.2.1 Mô ta dự án

Trang web phải đáp ứng được nhưng yêu cầu:

-Đối với khách hàng:

+ Yêu cầu xem được các thông tin chỉ tiết về các sản phẩm

+ Trang web phải có giới thiệu và địa chỉ liên hệ rõ ràng

+ Hỗ trợ tin tức về thị trường, khuyến mãi, giúp khách hàng nắm bắt đầy đủ thông tin để khách hàng mua được sản phẩm ưng ý nhất

+ Chức năng tìm kiếm: hỗ trợ khách hàng tìm kiếm nhanh chóng sản phẩm cần tìm

24

Trang 25

+ Liên lạc, tư vấn, hỗ trợ : Theo dõi và trả lời những thắc mắc của khách hàng, khi

họ gặp vấn đề kỹ thuật cần được giải quyết nhanh chóng Đưa ra những câu hỏi và câu trả lời cho các sự cô hay gập phải đề khách hàng có đầy đủ thông tin đề không phải chờ đợi + Đặt hàng qua trang web: để cho khách hàng có thê mua hàng và đặt hang theo yêu cầu của mình một cách dễ dàng và nhanh chóng kết hợp kiểm tra thông tin sản phẩm trước khi mua

- Đối với người quản trị:

+ Website: Người quản trị dé dang quan ly va sử dụng các chức năng của trang web như thêm, sửa, xóa, lưu trữ thông tim,

+ Chức năng: Chức năng phải thực hiện đúng yêu cầu, không gặp phải lỗi, hiển thị

đầy đủ thông tin yêu cầu

Thêm sản phâm : Chọn chức năng thêm sản phẩm hệ thống sẽ chuyên đến trang thêm sản pham G đây người quản trị nhập thôn tin sản phẩm sau đó gửi thông tin đã nhập cho hệ thong

Sửa sản phâm: Người quản trị chọn chức năng này sẽ được hệ thống chuyền đến trang sửa, chỉnh sửa thông tin cần sửa sau đó gửi thông tin đã nhập cho hệ thống

Xóa sản phẩm: người quản trị chọn sản phẩm cần xóa, hệ thống sẽ gửi thông tin sản phẩm

mà người dùng muốn xóa về đatabase, sản phâm sẽ được xóa ở database

Trang 26

1.2.3 Ưu, nhược điểm:

- Ưu điểm:

+Tiết kiệm được chi phí quản lý bán hàng

+ Tiếp cận với khách hàng một cách nhanh chóng và tiện lợi

+ Mua ban moi luc moi noi

-Nhuoc diém:

+ Độ bảo mật còn thấp chưa an toàn

+ Khó tạo dựng được độ tin cậy của khách hàng

+ Thường xuyên phải nâng cấp và hay gặp lỗi

1.3 Thực biện thiết kế các form

2 | FONT-END WLB DT PANG NHAP | Đăng Nhập OK 1 1

WLB DT TRANG CHU | Trang Chủ OK 1 3 WLB DT vở

Trang 27

Hình 2 1 Giao điện đăng nhập

Trang 28

b Giao diện đăng ký

L Tôi đồng ý với các điều khoản bào mật cá nhân

Đăng ký nhận bản tin khuyến mãi qua email hoặc điện thoại

Ngày đăng: 23/02/2025, 21:28

HÌNH ẢNH LIÊN QUAN

Hình  1.  2  Toc  D6  Xứ  Lý  Của  Phan  Mém - Báo cáo bài tập lớn kiểm thử website cửa hàng bán Điện thoại
nh 1. 2 Toc D6 Xứ Lý Của Phan Mém (Trang 13)
Hình  2.  1  Giao  điện  đăng  nhập - Báo cáo bài tập lớn kiểm thử website cửa hàng bán Điện thoại
nh 2. 1 Giao điện đăng nhập (Trang 27)
Hình  2.  2  Giao  điện  đăng  nhập - Báo cáo bài tập lớn kiểm thử website cửa hàng bán Điện thoại
nh 2. 2 Giao điện đăng nhập (Trang 28)
Hình  2.  4  Giao  điện  quản  ly - Báo cáo bài tập lớn kiểm thử website cửa hàng bán Điện thoại
nh 2. 4 Giao điện quản ly (Trang 29)
Hình  2.  5  Giao  diện  thêm  sản  phẩm - Báo cáo bài tập lớn kiểm thử website cửa hàng bán Điện thoại
nh 2. 5 Giao diện thêm sản phẩm (Trang 30)
Hình  2.  6  Giao  diện  sửa  sản  phẩm - Báo cáo bài tập lớn kiểm thử website cửa hàng bán Điện thoại
nh 2. 6 Giao diện sửa sản phẩm (Trang 31)

TỪ KHÓA LIÊN QUAN

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

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm