(Tiểu luận) kiểm thử thủ công chức năng quản lý chất lượng hàng trước khi xuất của sản phẩm tai nghe bluetooth và kiểm thử tự động

Nội dung bài thảo luận Tiến độ bài thảo luận - Lý thuyết cơ bản đã hoàn thành - Bài tập : thực hiện kiểm thử thủ cơng hồn thành được 80% và đang trong giai đoạn hoàn thành kiểm thử tự độ

Trang 1

TRƯỜNG ĐẠI HỌC THƯƠNG MẠI KHOA HỆ THỐNG THÔNG TIN KINH TẾ THƯƠNG MẠI ĐIỆN TỬ 

Trang 2

BẢNG PHÂN CÔNG CÔNG VIỆC Thành viên nhóm Công việc

Vũ Diệu Linh Viết testcase kiểm thử thủ công + Đánh giá TH kiểm thử tự động

Vũ Thị Loan Tạo bảng giá trị, báo cáo nhận xét các TH kiểm thử thủ công +

Kiểm thử tự động Trần Thị Lụa Viết code + kiểm thử tự động + Kiểm tra tính đúng đắn các TH

kiểm thử Trần Thị Khánh

Mai

Viết testcase kiểm thử thủ công + Đánh giá TH kiểm thử tự động

Đỗ Tuấn Minh

( S1)

Viết testcase kiểm thử thủ công + Đánh giá TH kiểm thử tự động

Đỗ Văn Minh (S2) Viết testcase kiểm thử thủ công + Đánh giá TH kiểm thử tự động

Đỗ Văn Minh (S3) Viết testcase kiểm thử thủ công + Đánh giá TH kiểm thử tự động

Vũ Thị Trà My Lập kế hoạch kiểm thử, đánh giá nhận xét các TH kiểm thử Đào Văn Nam Viết testcase kiểm thử thủ công + Đánh giá TH kiểm thử tự động

Trang 3

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập – Tự do – Hạnh phúc

-***

-BIÊN BẢN HỌP NHÓM THẢO LUẬN LẦN 1

I Thời gian và địa điểm

1 Địa điểm: Phòng họp tại trường ĐH Thương Mại

2 Thời gian: h ngày 9 04 tháng 10 năm 2022

II Số thành viên tham gia: 9/9

9 Đào Văn Nam

III Nội dung bài thảo luận

Xây dựng dàn ý chi tiết cho bài thảo luận

Hà Nội, ngày 04 tháng 10 năm 2022 Nhóm trưởng

Trà My

Vũ Thị Trà My

Trang 4

-***

1 Địa điểm: Phòng họp tại trường ĐH Thương Mại

2 Thời gian: 18h ngày 18 tháng 10 năm 2022

9 Đào Văn Nam ( Vắng có phép )

Tiến độ bài thảo luận

- Lý thuyết cơ bản đã hoàn thành

- Bài tập : thực hiện kiểm thử thủ công hoàn thành được 80% và đang trong giai đoạn hoàn thành kiểm thử tự động

Các thành viên tổ chức họp để tổng hợp, chỉnh sửa lại nội dung phần lý thuyết và bài tập

Hà Nội, ngày 18 tháng 10 năm 2022 Nhóm trưởng

Trà My

Vũ Thị Trà My

Trang 5

-***

1 Địa điểm: Phòng họp Google Meet

2 Thời gian: 22h ngày 4 tháng 11 năm 2022

9 Đào Văn Nam

- Tiến độ bài thảo luận : Lý thuyết và bài tập đã hoàn thành

45 Vũ Diệu Linh Có đóng góp ý kiến Lý thuyết đầy đủ và hực hiện t

kiểm thử dòng dữ liệu còn phải chỉnh sửa

8,75

46 Vũ Thị Loan Có đóng góp ý kiến Lý thuyết đầy đủ Thực hiện

kiểm thủ tự động và đánh giá kiểm thử thủ công tương đối hoàn chỉnh

8,75

47 Trần Thị Lụa Có đóng góp ý kiến, đánh giá và kiểm tra các

trường hợp kiểm thử đầy đủ Thực hiện kiểm thử

Trang 6

biên còn phải chỉnh sửa

52 Đỗ Văn Minh (s2) Chưa có đóng góp kiến Còn chậm ý deadline và

thực hiện kiểm thử lớp tương đương còn phải chỉnh sửa

8

53 Đỗ Văn Minh (s3) Chưa có đóng góp kiến ý Lý thuyết đầy đủ Thực

hiện kiểm thử dòng điều khiển còn phải chỉnh sửa

8,5

54 Vũ Thị Trà My Chỉnh sửa nội dung thuyết và đánh giá kiểm thử lý

thủ công và tự động hoàn chỉnh

9

55 Đào Văn Nam Chưa có đóng góp kiến Còn chậm ý deadline và

thực hiện kiểm thử theo ca đặc tả còn phải chỉnh sửa

Trang 7

KL Chu Thi Hong Hai

Tu Thi Ngoc Anh K22…kiểm thử phần

117

Kiểm thử thủ công hệ thống bán vé máy ba…kiểm thử phần

77

19 Phạm-Văn-Đoan 20D191008…

Trang 8

Preparing Vocabulary FOR UNIT 6

Led hiển thị 100% (2)

10

Trang 10

2

DANH MỤC HÌNH Ẽ V

Hình 4.4 2: Đồ ị th dòng dữ liệu t ng thể cho tất cả các biếổ n 47

Hình 5.3 15: Báo cáo về bài test giao diện đăng nhập web ZingID 69

Trang 11

3

A.CƠ SỞ LÝ THUY T Ế PHẦN I T NG QUAN V Ổ Ề PHẦN M M Ề

1.1. Khái niệm phần mềm

Phần mềm được hiểu là tập hợp các chức năng có mối liên hệ chặt ch v i nhau, gi ẽ ớ ữvai trò thực hiện một số nhiệm vụ, chức năng nào đó trên thiết bị điện tử Các tập tin này có thể bao gồm: các file mã nguồn được vi t b ng m t ho c k t h p nhiế ằ ộ ặ ế ợ ều ngôn ngữ ập trình lkhác nhau, các file dữ ệu, các file hướ li ng dẫn

Thực hiện các chức năng bằng cách gửi các chỉ thị đến Hardware (Ph n c ng) hoầ ứ ặc cung c p dấ ữ liệu để phục vụ các chương trình và phần mềm khác nhau.Có thể ự độ t ng hoặc

thực hiện theo các thông tin, dữ ệu đầu vào khi thực thi nhiệm vụ Phần mềm muốn thực lithi được phải có phần cứng đi kèm như: máy tính, các thiết bị điện tử…

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

Phân loại theo mục đích và lĩnh vực sử dụng

Phần mềm máy tính (phần mềm ứng dụng): Được sử dụng riêng cho máy tính giúp thực hiện các chức năng đặc biệt cũng như cung cấp các chức năng bên ngoài những hoạt động cơ bản của máy tính nhằm phục vụ công việc và giải trí Ví dụ như phần mềm bán hàng, phần mềm quản lý tiệm vàng, phần mềm LMS, phần mềm quản lý du lịch,…

Phần mềm hệ thống: Được dùng để quản lý hành vi của phần cứng trong máy tính, phần mềm cung cấp các chức năng cơ bản mà người dùng yêu cầu hay phần mềm khác để

có thể chạy đúng Các phần mềm hệ thống cơ bản bao gồm:

- Hệ điều hành (còn gọi là operating system): Đây là bộ sưu tập thi t y u c a ph n ế ế ủ ầ

mềm để quản lý tài nguyên cũng như cung cấp nh ng d ch vữ ị ụ chung dành cho các

ph n mầ ềm khác đang chạy trên đỉnh của chúng

- Trình điều khiển thiết bị (còn được gọi là drive): Đây là thiết bị cụ thể thường được

gắn vào máy tính, mỗi thiết bị ẽ ần ít nhất là một trình điề s c u khi n ể

- Tiện ích (còn gọi là utility): Đây là chương trình máy tính có mục đích hỗ trợ người dùng để ảo trì cũng như chăm sóc máy tính b

Phần mềm độc h i: ạ loại ph n mầ ềm này được phát triển nh m mằ ục đích gây hại đồng thời phá hỏng máy tính, có liên quan chặt chẽ và mật thiết với các tội phạm máy tính Phân loại theo bản chất hoặc miền thực thi

Các ứng dụng dành cho máy tính để bàn như: trình duyệt web, Microsoft office, các ứng dụng dành cho điện thoại thông minh hay máy tính bảng

Trang 12

4

Các tập lệnh JavaScript: Đây là phần mềm nhúng truyền thống được dùng trong các trang web và được chạy trực tiếp bên trong trình duyệt web mà không cần plugin trình khác Phần mềm máy chủ: Bao gồm ứng dụng web được chạy trên máy chủ để xuất các trang web đượ ạo động qua trình duyệt web, ví dụ như: Java, ASP, NET,… hay các JavaScript c tđược chạy trên máy chủ

Plugin và các tiện ích mở ộng: Đây là phầ r n mềm dùng để mở rộng hoặc sửa đổi chức năng từ một phần mềm nào đó, yêu cầu phần mềm đó s phải được sử dụng trong hoạt động ẽ

Ví dụ: OpenSSL gồm phần mềm nguồn mở dùng để triển khai các giao thức mạng, các

mã hóa như SSL và TLS Thư viện gốc viết bằng ngôn ngữ C Nó sẵn có phần mềm cho phép dùng thư viện OpenSSL trong nhiều ngôn ngữ, cung cấp những chức năng mật mã

tổng quát để mã hóa và giải mã OpenSSL cũng được dùng từ dòng lệnh để yêu cầu, tạo

m i, quớ ản lý những ch ng th c sứ ự ố Các trang web thường mua SSL để có thể đảm bảo được tính bảo m t ậ

Phần mềm nhúng cư trú: Có thể ể đế k n firmware trong hệ thống nhúng hoặc thi t b ế ịdành riêng để sử dụng đơn lẻ hay các công dụng như xe hơi và tivi Ở trong bối cảnh của hệ

thống nhúng, đôi khi không có sự phân biệt th t sậ ự rõ ràng giữa phần m m h ề ệthống và phần

mềm ứng d ng ụ

Microcode: Là phần mềm nhúng rất đặc biệt, do đó tương đối khó đọc hiểu cho b n ảthân bộ xử lý biết cách thực thi mã máy Chính vì vậy nên chúng có cấp độ thường thấp hơn

mã máy

Phân loại theo các công cụ lập trình

Các công cụ lập trình chính là một loại phần mềm được sử dụng dưới dạng chương trình hay ứng dụng đã được các nhà phát triển về phần mềm sử dụng để tạo, gỡ lỗi và hỗ trợ

ph n mầ ềm

Các phần mềm có thể được viết từ một hoặc nhiều ngôn ngữ ập trình khác nhau Mỗ l i ngôn ngữ sẽ có ít nhất một cách triển khai và đi kèm một bộ công cụ ập trình riêng Các lcông cụ này sẽ là các chương trình khép kín như trình dịch biên, trình gỡ ỗi, trình liên kế l t hay trình soạn thảo,…

Trang 13

- Dựa trên mô hình iterative and incremental

- Các yêu cầu và giải pháp phát triển dựa trên sự kết hợp của các function

- Trong Agile, các tác vụ được chia thành các khung thời gian nhỏ để cung cấp các tính năng cụ thể cho bản phát hành cuối

Mô hình tiếp cận lặp

- Thay vì phát triển phần mềm từ spec đặc tả rồi mới bắt đầu thực thi thì mô hình này

có thể review dần dần để đi đến yêu cầu cuối cùng

- Một mô hình được lặp đi lặp lại từ khi start cho đến khi làm đầy đủ spec.Quá trình này sau đó được lặp lại, tạo ra một phiên bản mới của phần mềm

Mô hình tăng trưởng

- Spec được chia thành nhiều phần Chu kỳ chia thành các module nhỏ, dễ quản lý

- Mỗi module sẽ đi qua các yêu cầu về thiết kế, thực hiện, … như 1 vòng đời phát triển thông thường

Mô hình chữ V

- Mô hình chữ V là một phần mở rộng của mô hình thác nước và được dựa trên sự kết hợp của một giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng Đây là một mô hình có tính kỷ luật cao và giai đoạn tiếp theo chỉ bắt đầu sau khi hoàn thành giai đoạn trước

- Với V model thì công việc test được tham gia ngay từ đầu

Trang 14

6

PHẦN II KI M TH Ể Ử PHẦN M M Ề

2.1 Khái niệm kiểm thử phần mềm

Kiểm thử ph n mầ ềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi

Kiểm th ph n mử ầ ềm đảm b o s n ph m ph n mả ả ẩ ầ ềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra

Kiểm th ph n mử ầ ềm 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 việc đánh giá và hiểu rõ các rủi ro khi thực thi test

Kiểm th ph n m m tử ầ ề ạo điều ki n cho b n t n d ng tệ ạ ậ ụ ối đa tư duy đánh giá và sáng tạo

để bạn có thể phát hiện ra những điểm mà người khác chưa nhìn thấy

2.2 Các mức kiểm thử

➢ Mức độ 1: Unit Testing – Kiểm thử mức đơn vị

Unit Testing là giai đoạn đầu tiên trong kiểm thử phần mềm Unit Testing được thực hiện nhằm kiểm tra và xác định các module riêng lẻ thuộc mã nguồn có hoạt động đúng hay không Mục đích của kiểm thử mức đơn vị như sau:

+ Xác định mỗi đơn vị phần mềm có đang thực hiện theo đúng thiết kế ban đầu hay không

+ Thông qua thử nghiệm sẽ giúp khắc phục những phát sinh do việc thay đổi hay bảo trì code

+ Unit Testing giúp tiết kiệm chi phí, thời gian và thể diện khi phát hiện ra lỗi

➢ Mức độ 2: Integration Testing – Kiểm thử tích hợp

M i dỗ ự án phần mềm được hoàn thành bở ấi r t nhi u module do nhiề ều người code khác nhau Integration Testing là cấp độ ki m th ph n mể ử ầ ềm tích hợp của các đơn vị riêng lẻđược kết hợp và thử nghiệm thành một nhóm thông qua việc tập trung vào kiểm tra truyền

d u giữ liệ ữa các module

Mục đích của giai đoạn ki m thể ử Integration Testing đó là tìm và phát hiệ ỗi khi tích n l

hợp các module lạ ới v i nhau Để tiến hành Integration Testing có 4 phương pháp tiếp c n ậbao gồm: big bang, top down, bottom up và sandwich/hybrid

➢ Mức độ 3: System Testing – Kiểm th h ử ệ thống

System Testing là giai đoạn thứ 3 của kiểm thử phần mềm cho phép phần mềm hoàn chỉnh và tích hợp được kiểm tra System Testing tập trung nhiều hơn vào các chức năng của toàn bộ hệ thống Kiểm thử hệ thống bao gồm kiểm thử chức thăng và kiểm thử phi chức thăng

Trang 15

7

Mục đích của System Testing đó là kiểm tra thi t kế ế và toàn bộ ệ thống sau khi tích h

hợp có tuân thủ những yêu cầu đã được định sẵn trước đó hay không Do đó System Testing rất chú trọng các hành vi và lỗi xuất hiện trên hệ thống Người thực hiện giai đoạn System Testing thường là kiểm thử viên hoàn toàn độc lập so với nhóm phát triển dự án

➢ Mức độ 4: Acceptance Testing – Kiểm thử chấp nhận

Acceptance Testing được thực hiện bởi khách hàng hoặc y quyủ ền cho nhóm thứ ba

nh m kiằ ểm tra hệ thống vừa xây dựng đã phù hợp với yêu cầu của khách hàng trước đó hay chưa Mục đích của Acceptance Testing đó là xác nhận lại sự tin tưởng vào hệ thống, các

đặc tính thu c về chức năng hoặộ c phi chức năng của hệ th ng ố

Có 2 loại ki m thử chấp nhể ận đó là Alpha Testing và Beta Testing

2.3 Các kĩ thuật kiểm thử

a Phương pháp kiểm thử phần mềm White box testing

White box testing (Ki m tra hể ộp màu trắng) là mộ ỹt k thu t ki m tra cậ ể ấu trúc bên trong của phần mềm và lấy dữ liệu th nghi m tử ệ ừ logic / mã chương trình Là phương pháp kiểm

thử mà các chuyên gia tester tập trung vào các dữ ệu đầu vào và ra, truy cậli p thẳng vào bên trong source code Các tên khác của thử nghiệm hộp trắng là thử nghiệm hộp mở, kiểm tra theo hướng logic hoặc thử nghiệm điều khiển đường dẫn ho c thử nghi m cấu trúc ặ ệ

- Dễ dàng tự động hóa

- Cung cấp các quy tắc dựa trên kỹ

thuật rõ ràng cho thời điểm ngừng thử

nghiệm

- Buộc các chuyên gia thử nghiệm phải

suy luận cẩn thận về việc test lỗi vì

vậy lỗi sẽ được triệt để

- Khá tốn thời gian và công sức

- Vẫn sẽ tồn tại lỗi

- Để kiểm tra được bằng phương pháp này cần có kinh nghiệm và trình độ chuyên sâu về kiểm thử

b Phương pháp kiểm thử phần mềm Black box testing

Black box testing (Ki m th hể ử ộp đen) là một phương pháp kiểm th ph n m m kiử ầ ề ểm tra chức năng của ứng d ng dụ ựa trên các đặc điểm kỹ thuật của nó Nó còn được gọi là thửnghiệm dựa trên thông số ỹ thuật k

Việc ki m thể ử được tiến hành dựa vào việc ki m thể ử chức năng của ph n mầ ềm xem nó

có phù hợp với yêu cầu của người dùng hay không Vì vậy, các tester nhập data vào phần

mềm và chỉ ầ c n xem kết quả ủ c a ph n mầ ềm và các mục tiêu test

Trang 16

8

- Các tester khi dùng phương pháp này

sẽ không cần liên quan đến code

- Có thể tìm được nhiều bug hơn

- Việc kiểm thử được thực hiện bởi một

cách độc lập với các Dev, cho phép

quan điểm khách quan và tránh sự

thiên vị

- Chỉ có một số lượng nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương trình hoặc 1 vài phần cuối sẽ không được kiểm tra

- Các thử nghiệm có thể thừa nếu nhà thiết kế/nhà phát triển phần mềm đã chạy thử nghiệm

Vì vậy, black box testing có ưu điểm là sản phẩm phần mềm được kiểm tra theo một quan điểm độc lập tuy vậy vẫn còn khá nhiều nhược điểm đáng lưu ý

c Phương pháp kiểm thử phần mềm Grey box testing

Phương pháp Gray box testing là một trong các phương pháp test phần mềm phổ biến nhất hiện nay Có thể nói phương pháp Gray Box testing là phương pháp của sự kết hợp giữa White box testing và Black box testing Kiểm tra hộp màu xám cho khả năng kiểm tra cả hai mặt của một ứng dụng, lớp trình bày cũng như phần mã Nó chủ yếu là hữu ích trong kiểm thử tích hợp và kiểm tra thâm nhập Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần, Tester

có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế test case, nhưng khi test thì test như là người dùng cuối hoặclà ở mức hộp đen

Là sự kết hợp c a kiủ ểm th hộp đen vàử

h p trộ ắng nên sẽ ối ưu hơn t

Kiểm tra bằng phương pháp hộp màu

xám có thể thiết kế kịch bản thử nghiệm

phức tạp một cách thông minh hơn

Rất khó để liên kế ỗt l i khi th c hiự ện

ki m tra hể ộp xám cho một ứng dụng có hệthống phân tán

Trên đây là 3 phương pháp kiểm thử phần mềm cơ bản nhất mà bất cứ một lập trình viên nào cũng cần nắm được Việc lựa chọn phương pháp nào phụ thuộc vào khả năng cũng như dự án mà bạn thực hiện

Trang 17

9

PHẦN III KI M TH Ể Ử PHẦN MỀ M TỰ ĐỘNG

3.1 Định nghĩa kiểm thử tự động

Kiểm th tử ự động là thực hi n ki m th ph n m m mệ ể ử ầ ề ột cách tự động các bước trong

m t k ch b n ki m th b ng mộ ị ả ể ử ằ ột chương trình đặc bi t v i rệ ớ ất ít hoặc không có sự tương tác của con người, giúp cho người thực hiện việc kiểm thử phần mềm không phả ặp đi lặi l p lại các bước nhàm chán

Công cụ kiểm thử tự động có thể lấy dữ liệu từ file bên ngoài (Excel, csv…) nhập vào

ứng dụng, so sánh kết quả mong đợi (t file Excel, csv…) với kết quả th c tế và xuất ra báo ừ ựcáo kết qu ki m thử ả ể

Kiểm th tử ự động sẽ được s d ng khi dử ụ ự án không đủ tài nguyên (thời gian, nhân lực

và chi phí), phải thực hiện kiểm thử hồi quy khi sản phẩm được sửa đổi hoặc nâng cấp và cần kiểm th lử ại các tính năng đã thực hiện tốt trước đó, kiểm tra khả năng vận hành của sản

phẩm trong các môi trường đặc biệt (đo tốc độ ử lý trung bình ứ x ng v i mớ ỗi yêu cầu, xác

định khả năng chị ải t i đa, kiểm tra các cơ chế an ninh và an toàn, ) u t ố

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

+ Các công cụ kiểm thử

+ Nguồn lực kiểm thử

+ Môi trường kiểm thử, bao gồm tài nguyên phần cứng và phần mềm

+ Mốc bàn giao các tài liệu kiểm thử

Trang 18

10

Thiết kế Test case

Mục đích: Nhằm xác định các test case và các bước kiểm tra chi ti t cho mỗi phiên ế

b n ph n mả ầ ềm Giai đoạn thi t kế ế test case là hế ứt s c quan trọng, nó bảo đảm t t cấ ả các tình

hu ng kiố ểm thử “quét” hết t t cấ ả yêu cầu c n kiầ ểm tra

Phát triển Test Script

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

tự động hóa một trình tự ki m thể ử, giúp cho việc ểki m thử nhanh hơn, hoặc cho nh ng ữtrường hợp mà kiểm thử bằng tay sẽ rất khó khăn hoặc không khả thi

Thực hiện kiểm thử

Mục đích: Thực hiện các bước kiểm tra đã thiết kế hoặc thực thi các test script nếu tiến hành kiểm tra tự động và ghi nhận kết quả

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

Mục đích: Đánh giá toàn bộ quá trình kiểm thử, bao gồm xem xét và đánh giá kết quả

kiểm thử ệt kê lỗi, chỉ định các yêu cầu thay đổi, và tính toán các số liệu liên quan đến quá , litrình kiểm thử như số giờ, th i gian kiờ ểm thử, s ố lượng lỗi, phân loại lỗi…

3.3 So sánh kiểm thử tự động và kiểm thử thủ công

Định nghĩa Sử dụng các công cụ tự động hóa để thực

thi các trường hợp kiểm thử

Trong kiểm thử thủ công các trường hợp kiểm thử được thực thi bởi tester (con người) và các phần mềm

Thời gian

xử lý

Kiểm thử tự động nhanh hơn đáng kể so

với cách tiếp cận thủ công

Việc kiểm thủ công tốn nhiều thời gian và nhân lực

Thời gian

đầu tư ban

đầu

Số vốn đầu tư cho kiểm thử tự động cao

hơn, tuy nhiên về lâu dài sẽ tốt hơn

Số vốn đầu tư thấp hơn nhưng

về lâu dài không lại không đem lại hiệu quả cao

Độ tin cậy Phương thức đáng tin cậy, được thực

hiện bởi công cụ và tập lệnh

Không chính xác vì có khả năng

là do lỗi của con người

Trang 19

11

Đầu tư Cần đầu tư cho các công cụ kiểm tra

cũng như các kỹ sư tự động hóa

Cần đầu tư cho nguồn nhân lực

Với kiểm thử tự động hóa, tất cả các bên

liên quan có thể đăng nhập vào hệ thống

tự động hóa và kiểm tra kết quả thực

hiện kiểm tra

Thử nghiệm thường được ghi lại trong Excel hoặc word, kết quả kiểm tra không sẵn có

Sự quan

sát của con

người

Kiểm thử tự động không liên quan đến

sự xem xét của con người Vì vậy, nó

không đảm bảo thân thiện với người

dùng và trải nghiệm khách hàng tích cực

Phương pháp kiểm tra thủ công cho phép con người quan sát, có thể hữu ích để cung cấp hệ thống thân thiện với người dùng

Kiểm tra

năng suất

Kiểm tra hiệu suất như Kiểm tra tải,

Kiểm tra căng thẳng, Kiểm tra Spike

bắt buộc phải được kiểm tra bằng một

Bắt buộc phải có kiến thức lập trình Không cần hiểu rõ lập trình

3.4 Một số công cụ kiểm thử tự động phổ biến

Trang 20

12

B THỰC HÀNH KIỂM THỬ PHẦN IV KI M TH Ể Ử THỦ CÔNG

4.1. Mô tả bài toán

Xây dựng chương trình mô phỏng chức năng quản lý chất lượng hàng trước khi xuất của các sản phẩm tai nghe Bluetooth của kho thành phẩm công ty Bluecom

Trong kho sẽ có tai nghe Bluetooth Loại I và Loại II (những công ty khác thường sẽ có loại không đạt chất lượng hoặc những loại khác vì vậy không chỉ có tai nghe Bluetooth Loại

I và Loại II) giá của Loại I là 2 triệu đồng và giá nhập của Loại I là 500 nghìn đồng Chương trình xử lý một phần việc của công ty là phần kiểm tra chất lượng của hàng hóa chuẩn bị xuất và sẽ xuất đi khi nhận đơn của khách hàng muốn đặt tai nghe với một số lượng nhất định trong khoảng [250;5000] con hàng Khi khách hàng liên hệ đến công ty để

đặt số lượng con hàng và yêu cầu về sản phẩm loại mấy c a tai nghe (Loại I hoặc Loại II) ủthì quản lý của kho sẽ đứng ra và nhận đơn hàng để ắt đầ b u xử lý hàng trong kho Sau khi

nhận đơn của khách hàng, người quản lý sẽ là người chia số lượng con hàng theo lô hàng

xuất và bắt đầu kiểm tra hàng để xuất

Sau đó, quản lý kho sẽ xem mỗi lô hàng được chuẩn bị đem đi xuất là Loại I hay Loại

II Quản lý sẽ ki m tra bể ằng cách đi kiểm tra mức sử ụ d ng c a mủ ột sản phẩm tai nghe và sau khi ki m tra xong sể ẽ nhập vào hệ thống Hệ thống sẽ so sánh thông tin được nhập vào với thông tin cho sẵn từng loại I và loại II để đưa ra kết quả Nếu không đúng yêu cầu của khách hàng thì để ại lô đấ l y về kho Quản lý kho sẽ là người kiểm tra lô hàng đến khi đạt đủ số lô khách hàng yêu cầu thì thôi

Vì trước khi hàng về kho đã được kiểm tra hàng đạt chuẩn hay chưa và phân loại thành

từng lô ở một phân đoạn khác của công ty Vì vậy, khi xuất đi chỉ ầ ấy xác suấ c n l t m t con ộhàng trong lô để ểm tra tính đúng đắ ki n của từng lô hàng

Hệ thống sẽ so sánh và hiển thị độ đạt chuẩn của lô hàng cho người quản lý:

Số lượng lô hàng quy định: Một lô hàng chỉ được tối đa là 5000 và tối thi u 250 s ể ố

lượng con hàng Nếu khách hàng đặt với số ợlư ng nhiều hơn số ối đa sẽ t được hệ thống tách

ra làm nhiều lô hàng để vận chuyển Và mỗ ần khách hàng chỉ được đặi l t số lượng hàng hóa

tối thiểu là 250 và tối đa là 5000 con hàng

Trang 21

13

Giá trị của t ừng lô hàng: Giá của tai nghe Loại I sẽ đắt hơn tai nghe Loại II (vì tính năng) Tính theo mức giá của từng sản phẩm Loại mấy, giá xuất sẽ được tăng lên 25% so

với giá gốc của từng loại Và theo công thức chung là

giá = số lượng * giá nhập * 1.25

=> Nếu lô hàng được kiểm tra có lỗi thì sẽ không xuất được và kiểm tra lô hàng khác

b Xác định các kịch bản hành vi

STT UC name : Quản lý chất lượng hàng

1 Tác nhân chính: Quản lý kho

2 Mục tiêu: Quản lý chất lượng trước khi xuất các sản phẩm tai nghe Bluetooth Hiển thị số lô hàng mà khách đặt, giá tiền xuất đi của sản phẩm Loại I hoặc Loại

II

3 Mô tả hoạt động: Quản lý kho nhận thông tin số lượng con hàng mà khách hàng

đặt, sau đó chia thành các lô hàng để xuất đi Trước khi xuất hàng, quản lý kho sẽ xem mỗi lô hàng được chuẩn bị đem đi xuất là Loại I hay Loại II Quản lý sẽ kiểm tra mức sử dụng của một sản phẩm tai nghe và sau đó sẽ nhập vào hệ thống Hệ thống sẽ so sánh thông tin được nhập vào với thông tin cho sẵn từng loại I và loại

II để đưa ra kết quả Nếu không đúng yêu cầu của khách hàng thì để lại lô đấy về kho Quản lý sẽ kiểm tra lô hàng đến khi đạt đủ số lô khách hàng yêu cầu thì thôi

4 Ngoại lệ/ràng buộc để thực hiện: Quản lý kho sẽ là người thực hiện đoạn

chương trình kiểm tra chất lượng hàng

Trang 22

14

5 Mối quan hệ:

- Có liên quan đến các phân đoạn khác của công ty

- Có liên quan đến thống kế, báo cáo chất lượng hàng

6 Luồng sự kiện chính:

1 Quản lý chọn chức năng “ Quản lý chất lượng hàng” trong hệ thống

2 Hệ thống hiển thị thông tin số lượng con hàng khách hàng đặt

3 Quản lý thực hiện chia thành các lô hàng để xuất

4 Hệ thống hiển thị form quản lý chất lượng hàng

5 Hệ thống yêu cầu nhập loại hàng

6 Quản lý chọn loại hàng là loại I hoặc loại II

7 Hệ thống hiển thị mức sử dụng của sản phẩm tai nghe loại I hoặc II

8 Hệ thống so sánh thông tin nhập vào và thông tin có sẵn từng loại hàng

9 Kết thúc ca sử dụng

7 Luồng phụ: Kiểm tra sản phẩm

7.1 Tai nghe loại I

- Quản lý chọn chức năng “Tai nghe loại I”

- Hệ thống hiển thị thông tin Tai nghe loại I

- Quản lý nhập thời gian sử dụng pin của sản phẩm

- Quản lý nhập giá sản phẩm

- Hệ thống hiển thị mức sử dụng pin của sản phẩm

- Hệ thống tính giá sản phẩm và giá được tính lên 25% so với giá gốc

- Kết thúc ca sử dụng

7.2 Tai nghe loại II

- Quản lý chọn chức năng “Tai nghe loại II”

- Hệ thống hiển thị thông tin Tai nghe loại II

- Quản lý nhập thời gian sử dụng pin của sản phẩm

- Quản lý nhập giá sản phẩm

- Hệ thống hiển thị mức sử dụng pin của sản phẩm

- Hệ thống tính giá sản phẩm và giá được tính lên 25% so với giá gốc

- Kết thúc ca sử dụng

Trang 23

a. Giới thiệu ngôn ngữ lập trình

- Ngôn ngữ sử dụng cho bài toán là ngôn ngữ C++

- Ngôn ngữ lập trình C++ là một ngôn ngữ lập trình hướng đối tượng, được phát triển trên nền tảng của ngôn ngữ lập trình C

Trang 24

16

- Ngôn ngữ lập trình C++ có thể được dùng để làm những công việc sau:

+ C++ được thiết kế để viết những hệ thống lớn, thậm chí C++ được dùng để tạo nên hệ điều hành máy tính (Linux, Mac OS X, Windows )

+ Gần như toàn bộ các game bom tấn trên thị trường hiện nay cũng dùng C++

để phát triển Một số công cụ sử dụng trong việc lập trình game có sử dụng C++ như Unreal engine, Cocos2d-x framework,

+ Các sản phẩm phần mềm nổi tiếng khác được phát triển bằng C++ như MS Office, Photoshop, Maya / 3ds, Autocad

Những cấu hình cụ thể cần thiết RAM tối thiểu: 4GB DDR3

Ở cứng tối thiểu : 500Gb CPU: Core i5 Màn hình Bảng 4.2 3: Yêu cầu v ph n c ng ề ầ ứ

- Thiết lập môi trường kiểm thử phần mềm

+ Sử dụng ngôn ngữ C++

+ Mạng

- Mạng thiết lập theo yêu cầu kiểm tra Nó bao gồm:

+ Thiết lập Internet

+ Thiết lập mạng LAN Wifi

+ Thiết lập mạng riêng: Đảm bảo rằng khi tình trạng nghẽn mạng xảy ra trong quá trình kiểm thử không ảnh hưởng đến các thành viên khác (lập trình viên, nhà thiết kế, vv)

• Cài đặt PC: Yêu cầu cài đặt Visual Studio

• Báo cáo lỗi: Công cụ báo cáo lỗi kiểm thử

Trang 25

17

d Chương trình cho bài toán thủ công

Hình 4.3 1: Chương trình4.4. Thiết kế kiểm thử chức năng

a. Dựa trên giá trị biên

Bước 1: Xác định biên của các giá trị đầu vào

- Miền xác định cho đầu vào

Trang 26

#Case Input Expected Output System Output Result

1 Loại 1 -1 249 Số liệu không hợp lệ Số liệu không hợp lệ Passed

Trang 27

19

8 Loại 1 0 249 Số liệu không hợp lệ Số liệu không hợp lệ Passed

9 Loại 1 0 250 Lô hàng không đạt chuẩn Lô hàng không đạt chuẩn Passed

23 Loại 1 8 250 Số lô hàng được xuất là 1,

lô hàng đạt chuẩn loại 1, giá của lô hàng là 625.000đ

Số lô hàng được xuất là 1, lô hàng đạt chuẩn loại 1, giá của

lô hàng là 625.000đ

Passed

lô hàng đạt chuẩn loại 1, giá

Passed

Trang 28

20

của lô hàng là 7.500.000đ lô hàng là 7.500.000đ

lô hàng đạt chuẩn loại 1, giá của lô hàng là 12.497.500đ

Số lô hàng được xuất là 10,

Passed

lô hàng là 7.500.000đ

Passed

Lô hàng không đạt chuẩn Failed

Trang 29

21

Trang 30

22

Passed

Trang 31

23

của lô hàng là 3.124.375đ của lô hàng là 3.124.375đ

Passed

Trang 32

24

Trang 33

25

107 Loại 3 0 250 Số liệu không hợp lệ Số liệu không hợp lệ Failed

Trang 34

26

Bảng 4.4 2: Kiểm thử biên với Version 1

Trang 35

27

Kết luận :

- Phát hiện ra 5 fail test cases Chương trình có lỗi với bộ testcase T

- Nguyên nhân: 5 failed test cases xảy ra ở biên của thời gian max là 15, có khả năng sai dấu kiểm tra điều kiện ở vị trí này

Bước 3: Kiểm thử với version 2

- Version 2 đã kiểm tra lại và debug tại vị trí nghi ngờ xuất hiện lỗi trong lần kiểm thử đầu tiên

#Case Input Expected Output System Output Result

Trang 36

28

Passed

Trang 37

29

Passed

lô hàng đạt chuẩn loại 1, giá của lô hàng là 7.500.0 00đ

Passed

Lô hàng không đạt chuẩn Passed

Trang 38

30

Trang 39

31

Passed

Trang 40

32

Passed

Tiêu đề	Kiểm Thử Thủ Công Chức Năng Quản Lý Chất Lượng Hàng Trước Khi Xuất Của Sản Phẩm Tai Nghe Bluetooth Và Kiểm Thử Tự Động Chức Năng Đăng Nhập Web Zing Id Bằng Phần Mềm Testcomplete
Tác giả	Vũ Diệu Linh, Đỗ Văn Minh (S2), Vũ Thị Loan, Đỗ Văn Minh (S3), Trần Thị Lụa, Vũ Thị Trà My (NT), Trần Thị Khánh, Đào Văn Nam, Đỗ Tuấn Minh
Người hướng dẫn	Th.S. Vũ Diệu Hương
Trường học	Trường Đại Học Thương Mại
Chuyên ngành	Hệ Thống Thông Tin Kinh Tế Thương Mại Điện Tử
Thể loại	tiểu luận
Năm xuất bản	2021
Thành phố	Hà Nội

Định dạng
Số trang	81
Dung lượng	10,8 MB