Báo cáo môn kiểm thử và đảm bảo chất lượng phần mềm

Báo cáo môn kiểm thử và đảm bảo chất lượng phần mềm code quản lí siêu thị bằng laravel full chức năng như đăng kí đang nhập quản lí hoá đơn quản li bán hàng, quản lí nhân viên, nhập xuất kho. Dùng cho các sinh viên các trường đại học cntt nói chung và các trường khác.

Tổng quan lý thuyết kiểm thử phần mềm

Kiểm thử phần mềm là gì?

Kiểm thử phần mềm (software testing) 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

Theo IEEE: Kiểm thử phần mềm 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 đó.

Theo 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.

Lỗi là kết quả của những sai sót Sai sót là sự nhầm lẫn hay hiểu sai trong quá trình phát triển phần mềm của người phát triển Khi lỗi trở nên quá nhiều hoặc gây ảnh hưởng lớn đến hệ thống khi đó sẽ gây ra hỏng hóc, khiến chương trình không thể hoạt động hoặc hoạt động thiếu chính xác và tin cậy.

Lý do phải kiểm thử phần mềm

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.

Các lý do khiến một phần mềm cần phải kiểm thử:

- Tiết kiệm chi phí: Việc phát hiện lỗi sớm sẽ giảm chi phí để sửa so với các giai đoạn sau cũng như giảm thiểu rủi ro sản phẩm bị hỏng hóc.

- Bảo mật: Một phần mềm gây rò rỉ thông tin cá nhân người dùng sẽ không được cấp phép hoạt động.

- Chất lượng của sản phẩm: Dựa theo độ hoàn thiện chức năng của yêu, chức năng càng hoàn thiện, yêu cầu càng thực hiện trọn vẹn, chất lượng của sản phẩm được đánh giá cao.

- Sự hài lòng của khách hàng: Chất lượng cao nhưng đặc biệt phải có được sự hài lòng từ người dùng phần mềm.

- Tối ưu quá trình phát triển: Việc phát hiện lỗi sớm, lỗi sẽ được nhanh chóng sửa chữa vì nó còn đơn giản Lỗi được phát hiện muộn màng sẽ gây khó khăn và rối rắm khi chỉnh sửa lại, làm chậm tiến trình phát triển phần mềm.

- Dễ dàng thêm mới tính năng: Với việc kiểm thử được trọn vẹn hoàn thành, nhà phát triển có thể tự tin phát triển các tính năng mới mà không cần lo nghĩ sẽ vo tình phá vỡ cấu trúc các tính năng cũ.

- Xác định hiệu suất của phần mềm: Hiệu suất của phần mềm cực kỳ quan trọng trong việc có được lòng tin của khách hàng.

KẾT LUẬN: Để có thể thực hiện kiểm thử phần mềm, thì hiểu được lý do tại sao kiểm thử phần mềm là cực kỳ quan trọng, nó sẽ đưa ra mục tiêu và điểm đích của công việc kiểm thử đang diễn ra với một sản phẩm cụ thể nào đó.

Vai trò của kiểm thử phần mềm?

Sản phẩm đến tay của khách hàng phải đảm bảo về yêu cầu, giao diện, cấu trúc, tính năng và một số các yêu cầu đặc hữu khác đồng thời đảm bảo không còn tồn tại lỗi trong hệ thống.

Sản phẩm phải đảm bảo đầy đủ về tính năng, tuân thủ những yêu cầu đã được đặt ra Trong quá trình phát triển rất có thể sẽ phát sinh thêm nhiều nhiều yêu cầu từ khách hàng Kiểm thử cần bảo đảm các yêu cầu được hoàn thiện và hoàn thành đúng với kết quả mà yêu cầu giao.

Một sản phẩm chỉn chu, hoàn thiện tạo ra được những trải nghiệm người dùng tốt nhất sẽ đạt được niềm tin của đối tác, khách hàng về sau.

Việc phát hiện lỗi sớm sẽ mang lại nhiều lợi ích trong quá trình phát triển Giảm chi phí vận hành chính là một trong số đó Phát hiện lỗi sớm có thể kịp thời sửa chữa và dự đoán những lỗi có thể bắt gặp trong tương lai, mở rộng tầm nhìn và thu hẹp phạm vi lỗi được xác định.

Xử lý lỗi ở giai đoạn đầu sẽ mất chi phí ít hơn là giai doạn sau bởi nó dễ dàng xử lý và không có nhiều khó khăn Ở giai đoạn sau, khi chương trình được kiểm thử hoặc đã được phát hành thì chi phí sửa chữa thường cao hơn do có nhiều khó khăn trong việc xử lý đồng thời cũng sẽ ảnh hưởng đến độ tin cậy của phần mềm

KẾT LUẬN: Kiểm thử phần mềm là một phần không thể thiếu trong quá trình phát triển phần mềm, đóng vai trò quan trọng trong việc đảm bảo chất lượng và tính ứng dụng của sản phẩm Mục tiêu của kiểm thử là phát hiện lỗi, đánh giá chất lượng,đảm bảo độ tin cậy, kiểm tra tính năng, và xác thực yêu cầu Điều này đóng góp quan trọng vào việc cung cấp sản phẩm phần mềm chất lượng cao cho khách hàng và bảo vệ danh tiếng của tổ chức phát triển.

Mục tiêu của kiểm thử phần mềm?

Mục tiêu chính của kiểm thử phần mềm là phát hiện và xác định các lỗi trong phần mềm Các lỗi này có thể là lỗi logic, lỗi giao diện người dùng, lỗi hiệu suất, hoặc lỗi bảo mật Để đảm bảo tính ổn định và đáng tin cậy của sản phẩm, các lỗi này cần phải được báo cáo và sửa chữa.

Kiểm thử phần mềm giúp đánh giá chất lượng của sản phẩm Điều này bao gồm việc kiểm tra tính năng, hiệu suất, bảo mật, và tương thích với các môi trường khác nhau Đánh giá chất lượng giúp đảm bảo rằng sản phẩm đáp ứng tiêu chuẩn chất lượng của công ty và mong đợi của khách hàng.

1.4.3 Đảm bảo độ tin cậy

Mục tiêu khác của kiểm thử phần mềm là đảm bảo độ tin cậy của phần mềm. Điều này đảm bảo rằng phần mềm hoạt động đáng tin cậy và không gây ra sự cố không mong muốn Độ tin cậy là một yếu tố quan trọng đối với sự hài lòng của khách hàng và danh tiếng của sản phẩm.

Kiểm thử phần mềm kiểm tra tính năng của sản phẩm để đảm bảo rằng nó hoạt động theo cách được thiết kế và đáp ứng nhu cầu của người dùng Điều này bao gồm kiểm tra các tính năng cơ bản cũng như các tính năng phức tạp.

Mục tiêu cuối cùng của kiểm thử phần mềm là xác minh rằng phần mềm tuân thủ các yêu cầu đã được đặt ra ban đầu Điều này đảm bảo tính nhất quán và chính xác của sản phẩm, và giúp đảm bảo rằng sản phẩm hoạt động theo cách mà khách hàng mong đợi.

KẾT LUẬN: Kiểm thử phần mềm là một phần không thể thiếu trong quá trình phát triển phần mềm, đóng vai trò quan trọng trong việc đảm bảo chất lượng và tính ứng dụng của sản phẩm Mục tiêu của kiểm thử là phát hiện lỗi, đánh giá chất lượng,đảm bảo độ tin cậy, kiểm tra tính năng, và xác thực yêu cầu Điều này đóng góp quan trọng vào việc cung cấp sản phẩm phần mềm chất lượng cao cho khách hàng và bảo vệ danh tiếng của tổ chức phát triển.

Các phương pháp kiểm thử phần mềm?

1.5.1 Kiểm thử đơn vị (Unit Testing) Đây là phần quan trọng nhất của quá trình kiểm thử phần mềm

Trong kiểm thử đơn vị, các đơn vị nhỏ nhất của mã nguồn, như các hàm hoặc phương thức được kiểm tra độc lập để đảm bảo tính đúng đắn của chúng Thường thực hiện bởi nhà phát triển.

Kiểm thử đơn vị giúp phát hiện và sửa lỗi ngay từ khi chúng xuất hiện.

1.5.2 Kiểm thử tích hợp (Intergration Testing)

Sau khi các đơn vị đã được kiểm thử đơn lẻ, kiểm thử tích hợp đảm bảo rằng cho chúng hoạt động đúng cách khi được kết hợp lại với nhau

Mục tiêu là phát hiện lỗi liên quan đến sự tương tác giữa các thành phần với nhau và đảm bảo rằng tích hợp hoạt động mượt mà.

1.5.3 Kiểm thử hệ thống (System Testing)

Kiểm thử hệ thống là bước kiểm tra toàn bộ ứng dụng hoặc hệ thống sau khi đã được tích hợp hoàn chỉnh.

Giai đoạn này, người kiểm thử đảm bảo rằng hệ thống hoạt động như một thực thể duy nhất và đáp ứng các yêu cầu chức năng và phi chức năng.

1.5.4 Kiểm thử chấp nhận (Acceptance Testing)

Loại kiểm thử này tập trung vào việc đảm bảo rằng phần mềm đáp ứng các yêu cầu của khách hàng và có khả năng sử dụng trong môi trường thực tế.

Kiểm thử chấp nhận có thể chia thành kiểm thử chấp nhận người dùng (UAT) do khách hàng thực hiện kiểm thử và kiểm thử chấp nhận hệ thống (SAT) do người kiểm thử độc lập thực hiện.

Các chiến lược kiểm thử?

1.6.1 Kiểm thử từ trên xuống (Top – Down Testing)

Trong chiến lược này, kiểm thử bắt đầu từ thành phần cấp cao hơn của hệ thống và sau đó lan tỏa xuống các thành phần cấp thấp hơn Điều này giúp kiểm tra sự tích hợp của các thành phần và đảm bảo tích hợp đúng cách

Top – Down Testing cũng giúp xác định các thành phần giả thiết (stub) cho các thành phần chưa hoàn thành.

1.6.2 Kiểm thử từ dưới lên (Bottom – Up Testing)

Chiến lược này là ngược lại với Top – Down Nó bắt đầu từ các thành phần cấp thấp và sau đó tích hợp chúng lên các thành phần cao hơn.

Thường sử dụng khi các thành phần cấp cao hơn chưa hoàn thành

1.6.3 Kiểm thử hộp đen (Black Box Testing)

Trong kiểm thử hộp đen, người kiểm thử không cần quan tâm cấu trúc nội bộ của phần mềm Họ chỉ quan tâm đến cách phần mềm hoạt động từ bên ngoài và kiểm tra các đầu vào – dầu ra để đảm bảo tính đúng đắn.

1.6.4 Kiểm thử hộp trắng (White Box Testing)

Kiểm thử hộp trắng liên quan đến việc kiểm tra cấu trúc nội bộ của mã nguồn. Người kiểm thử sử dụng kiến thức về mã nguồn để tạo các bộ kiểm tra dựa trên mã nguồn để đảm bảo tính logic và đúng đắn của phần mềm.

1.6.5 Kiểm thử hồi quy (Regression Testing)

Chiến lược này đảm bảo rằng các thành phần đã kiểm thử trước đó không bị ảnh hưởng bởi các thay đổi sau này trong mã nguồn.

Regression Testing đảm bảo tính ổn định của phần mềm sau mỗi lần cập nhật hoặc thay đổi.

1.6.6 Kiểm thử tương quan (Concurrent Testing)

Kiểm thử này kiểm tra khả năng của hệ thống hoạt động đúng cách trong môi trường có nhiều tương tác đồng thời (ví dụ có nhiều người dùng truy cập cùng lúc).

KẾT LUẬN: Thông qua sự kết hợp và lựa chọn phương pháp kiểm thử và chiến lược kiểm thử phù hợp, nhà phát triển có thể đảm bảo chất lượng và tính ổn định của sản phẩm phần mềm của họ Quá trình kiểm thử phần mềm là một quá trình quan trọng trong quy trình phát triển, và cải thiện liên tục là điều không thể thiếu để đáp ứng yêu cầu của thị trường.

Nguyên tắc kiểm thử phần mềm?

1.7.1 Nguyên tắc 1: Test chỉ chứng tỏ được việc có lỗi

Kiểm thử chỉ có thể chứng minh được rằng sản phẩm có lỗi Kiểm thử phần mềm không thể chứng mình rằng sản phẩm không còn lỗi Nghĩa là sản phẩm luôn có lỗi cho dù có kiểm thử nhiều bao nhiêu Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt.

1.7.2 Nguyên tắc 2: Không thể Test toàn bộ

Trừ khi sản phẩm được kiểm thử quá đơn giản cũng như không có nhiều giá trị đầu vào (chẳng hạn như “Hello World”) thì việc chứng minh sản phẩm không còn bug cho dù có kiểm thử nhiều đến đâu là không khả thi

Hầu hết các sản phẩm ngày nay rất đa dạng và phức tạp do được phát triển trên nhiều nền tảng, công nghệ phong phú cũng như khả năng lưu trữ kết nối dữ liệu lớn, khiến việc kiểm thử trở nên khó khăn và việc kiểm thử toàn bộ là gần như không thể

Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ phi nó chỉ bao gồm ít trường hợp thì có thể kiểm thử toàn bộ Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn.

1.7.3 Nguyên tắc 3: Test từ giai đoạn đầu

Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của vòng đời phát triển phần mềm

Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn Nó cho phép chuyển giao phần mềm theo yêu cầu đúng thời gian với chất lượng dự kiến

Ngoài ra ai làm phần mềm cũng biết được rằng việc phát hiện lỗi càng trể bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu Tương tự, việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phí thay đổi tính năng trong hệ thống.

1.7.4 Nguyên tắc 4: Sự phân bổ không đồng đều của lỗi

Thông thường, phần lớn lỗi tập trung vào những module, thành phần chức năng chính của hệ thống Điều này cũng thuận theo nguyên lý Pareto: 80% số lượng lỗi được tìm thấy trong 20% tính năng của hệ thống

Nếu bạn thành công xác định được điều này, bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả

1.7.5 Nguyên tắc 5: Nghịch lý thuốc trừ sâu

Trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test case thì có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này Nguyên nhân là do khi hệ thống ngày càng hoàn thiện, những lỗi được tìm thấy lúc trước đã được sửa trong khi những trường hợp kiểm thử đã cũ

Do đó, khi một lỗi được sửa hay một tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi qui) nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng khác của sản phẩm.

1.7.6 Nguyên tắc 6: Test tùy thuộc vào điều kiện

Theo nguyên tắc này thì nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì điều đó là sai lầm Chiến lược để kiểm thử nên khác nhau và phụ thộc vào chính ứng dụng đó Chiến lược cho test web application phải khác với ứng dụng android mobile.

1.7.7 Nguyên tắc 7: Cạm bẫy không có BUG

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường

Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.

KẾT LUẬN: Kiểm thử không phải chỉ đơn thuần là một hoạt động riêng lẻ mà là một loạt các hoạt động liên quan và bổ sung cho nhau và phức tạp Tuy nhiên, việc dựa theo 7 nguyên tắc trên sẽ giúp cho chúng ta có cái nhìn tổng quát hơn về kiểm thử cũng như giúp chúng ta đánh giá được tính hiệu quả của hoạt động kiểm thử được thực thi.

Quy trình kiểm thử phần mềm – Test Process

 Đầ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 như: 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ó) …

- 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.

- QA team 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 khách hàng Qua hoạt động này, QA team sẽ nắm bắt được các yêu cầu mà dự án đưa ra bao gồm yêu cầu kiểm thử chức năng/ phi chức năng nào.

- 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 team sẽ đưa ra câu hỏi với các bên liên quan như BA(Business Analysis), PM( Project Manager), team leader, khách hàng để hiểu chính xác hơn về yêu cầu của sản phẩm Những câu hỏi này sẽ được lưu trữ vào file Q&A (Question and Answer) Các câu hỏi nên được đưa ra dưới dạng Yes/No question hoặc các lựa chọn để tiết kiệm thời gian trả lời cũng như hỗ trợ đưa ra những gợi ý hay để xây dựng sản phẩm ngay từ đầu Như vậy, đương nhiên là chúng ta không nên nêu ra những câu hỏi dạng là gì, như thế nào, tại sao, Những câu hỏi như thế thường mất thời gian để giải thích và cũng khó có thể giải thích một cách chi tiết nhất có thể Hơn nữa, đối với khách hàng không có sự hiểu biết về lĩnh vực phần mềm mà họ yêu cầu thì càng không thể trả lời những câu hỏi mang tính chuyên môn cao Chính chúng ta sẽ là người hỗ trợ và đưa ra giải pháp thích hợp cho khách hàng lựa chọn.

 Đầ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.

1.8.2 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à 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.

Dựa vào các tài liệu được cung cấp và cập nhật mới nhất, thông thường, test manager hoặc test leader sẽ là người lập kế hoạch kiểm thử cho cả QA team Lập kế hoạch kiểm thử nhằm xác định một số yếu tố quan trọng sau:

- Xác định phạm vi (Scope) dự án: 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 lịch trình thực hiện cho từng công việc nhỏ sao cho phù hợp với toàn bộ đội dự án.

- Xác định phương pháp tiếp cận: Nói về cách tiếp cận để kiểm thử cho một đối tượng nào đó, thì phải dựa vào nhiều thứ, ví dụ như: Thời gian cho phép test có phù hợp với con số ước lượng, nhiều hay ít, yêu cầu chất lượng từ phía khách hàng thế nào? Cao, thấp hay khắc khe hay sao cũng được? Công nghệ / kỹ thuật sử dụng để phát triển ứng dụng này là gì? Lĩnh vực của hệ thống/sản phẩm đang được test (domain) là gì? Từ đó, test manager có thể đưa ra những phương pháp và kế hoạch phù hợp nhất cho cả quá trình thực hiện dự án sao cho đúng với các tiêu chí chấp nhận 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

Con người: Bao nhiêu người tham gia dự án, ai sẽ test phần nào, bao nhiêu tester tham gia? Tester và nhóm phát triển có kinh nghiệm về lĩnh vực này không?

Thiết bị: số lượng server, version, máy tính, mobile để thực hiện test là bao nhiêu.

- Lên kế hoạch thiết kế công việc test: Bản kế hoạch kiểm thử sẽ bao gồm các nội dung:

Liệt kê các chức năng cần kiểm thử. Để 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 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. 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.

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 lập kế hoạch bao gồm các tài liệu như test plan, test estimation, test schedule.

1.8.3 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.

- Review tài liệu: Đầu tiên, các kiểm thử viên cần review 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ừ đó, vừa có thể tiết kiệm thời gian mà vẫn đưa ra được một 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 các 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 ra các test case chi tiết, đội kiểm thử 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 thành viên trong đội kiểm thử hoặc test leader cũng cần review lại test case đã tạo để có thể bổ sung, hỗ trợ lẫn nhau nhằm tránh những sai sót trong thiết kế test case và rủi ro về sau.

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 bao gồm: test design, test case, check list, test data, test automation script.

1.8.4 Thiết lập môi trường kiểm thử

 Đầu ra Đầu vào của giai đoạn cài đặt môi trường kiểm thử là test plan, smoke test case, test data.

Lập kế hoạch test

 Website test: myphamthainguyen.com.vn

Hệ thống cung cấp các chức năng quản lý hàng hóa, sản phẩm, thanh toán đơn hàng cho siêu thị

+ App: Quét QR, Đổi mật khẩu, Cập nhật thông tin cá nhân, Xem thông tin cá nhân.

+ Web: Thêm sửa xóa hàng hóa, Thêm sửa xóa loại hàng hóa, Thêm sửa xóa nhà cung cấp, Quản lý hóa đơn (tạo mới).

- Các chức năng không test: Đăng kí, đăng nhập, quên mật khẩu, Thống kê.

Nhân sự Nhiệm vụ Kết quả

Triệu Hoàng Đức Kiểm thử app chức năng quét QR, đổi mật khẩu ĐÃ HOÀN THÀNH

Trần Văn Hải Kiểm thử website chức năng quản lý hàng hóa ĐÃ HOÀN THÀNH

Trần Nguyên Bình Kiểm thử website chức năng quản lý nhà cung cấp ĐÃ HOÀN THÀNH

Phạm Quang Minh Kiểm thử website chức năng quản lý hóa đơn ĐÃ HOÀN THÀNH

Bế Chí Kiên Kiểm thử app chức năng đổi thông tin cá nhân ĐÃ HOÀN THÀNH

 Mô tả chi tiết công việc:

Họ tên Công việc Mô tả

Triệu Hoàng Đức Kiểm thử app chức năng quét QR, đổi mật khẩu

- Chọn kĩ thuật kiểm thử

- Tìm hiểu về công cụ katalon

- Kiểm thử chức năng quét QR

- Kiểm thử chức năng đổi mật khẩu

- Báo cáo kết quả Trần Văn Hải Kiểm thử website chức năng quản lý hàng hóa

- Kiểm thử chức năng thêm hàng hóa

- Kiểm thử chức năng sửa hàng hóa

- Kiểm thử chức năng xóa hàng hóa

- Kiểm thử api gửi thông tin hàng hóa từ barcode

- Báo cáo kết quả Trần Nguyên Bình Kiểm thử website chức năng quản lý nhà cung cấp

- Kiểm thử chức năng thêm nhà cung cấp

- Kiểm thử chức năng sửa nhà cung cấp

- Kiểm thử chức năng xóa nhà cung cấp

- Kiểm thử chức năng nhập hàng

Phạm Quang Minh Kiểm thử website chức năng quản lý hóa đơn

- Kiểm thử chức năng tạo hóa đơn

Bế Chí Kiên Kiểm thử app chức năng đổi thông tin cá nhân

- Tìm hiểu về lý thuyết kiểm thử

- Chọn kỹ thuật kiểm thử

- Kiểm thử app chức năng đổi thông tin cá nhân

 Môi trường test (Công cụ): Katalon, Chrome (Version 77.0.3865.120 (Official

 Phân tích, đánh giá rủi ro

Giới thiệu về công cụ kiểm thử katalon

Giới thiệu về kiểm thử tự động

Automation testing là quá trình sử dụng phần mềm để thực hiện các bài kiểm thử tự động mà không cần sự can thiệp thủ công của người kiểm thử Các công cụ automation có thể thực hiện các tác vụ kiểm thử lặp đi lặp lại một cách nhanh chóng và chính xác hơn so với thủ công.

 Một số lợi ích chính của Automation testing:

- Tốc độ nhanh: Các script có thể chạy các bài kiểm thử lặp lại nhiều lần trong thời gian ngắn.

- Giảm chi phí: Giảm nhân lực cần thiết để thực hiện kiểm thử thủ công.

- Độ chính xác: Các script sẽ luôn thực hiện chính xác các bước đã định nghĩa mà không mắc lỗi con người.

- Bao phủ tốt: Có thể chạy nhiều ca kiểm thử hơn so với thủ công để tăng độ bao phủ.

- Các báo cáo chi tiết: Kết quả kiểm thử có thể được lưu lại và báo cáo một cách chi tiết.

 Ưu nhược điểm của Automation Ưu điểm của Automation Testing:

- Tiết kiệm thời gian và chi phí do tự động hóa các quy trình kiểm thử.

- Giúp bao phủ nhiều ca kiểm thử trong thời gian ngắn.

- Giảm sai sót do yếu tố con người.

- Có thể chạy liên tục không giới hạn thời gian.

- Cung cấp kết quả chính xác và mức độ tin cậy cao.

- Hỗ trợ tái sử dụng lại các ca kiểm thử.

Nhược điểm của Automation Testing:

- Đòi hỏi kỹ năng và thời gian ban đầu để xây dựng các script kiểm thử.

- Bảo trì các script tốn nhiều công sức khi có thay đổi ứng dụng.

- Không thích hợp với tất cả các loại kiểm thử.

- Khó khăn trong xử lý lỗi và điều tra nguyên nhân.

- Đòi hỏi chi phí cao cho công cụ và nhân lực.

Tổng quan về lịch sử ra đời của công cụ kiểm thử katalon

Katalon Studio là một giải pháp kiểm thử tự động được phát triển bởi Katalon LLC, một công ty phần mềm có trụ sở tại Việt Nam Công cụ này được xây dựng dựa trên các khung tự động hóa nguồn mở Selenium và Appium với giao diện IDE chuyên dụng để kiểm thử ứng dụng web, API, di động và máy tính để bàn.

Katalon Studio được phát triển bởi một nhóm kỹ sư của KMS Technology, một công ty công nghệ thông tin hàng đầu Việt Nam Dự án bắt đầu vào năm 2014 với mục tiêu tạo ra một giải pháp kiểm thử tự động dễ sử dụng và hiệu quả hơn cho các doanh nghiệp vừa và nhỏ.

Bản phát hành đầu tiên của Katalon Studio là vào tháng 1 năm 2015 Phiên bản này chỉ hỗ trợ kiểm thử ứng dụng web Đến tháng 9 năm 2016, Katalon Studio được phát hành phiên bản 2.0, bổ sung thêm khả năng kiểm thử API và di động.

Sự phát triển của Katalon Studio

Kể từ khi ra mắt, Katalon Studio đã nhanh chóng trở thành một trong những công cụ kiểm thử tự động phổ biến nhất trên thế giới Theo thống kê của Gartner, Katalon Studio hiện đang được sử dụng bởi hơn 200.000 người dùng trên 100 quốc gia.

Tương lai của Katalon Studio

Katalon LLC đang tiếp tục phát triển Katalon Studio để đáp ứng nhu cầu ngày càng cao của người dùng Trong thời gian tới, Katalon Studio sẽ được bổ sung thêm các tính năng mới như:

- Hỗ trợ kiểm thử AI/ML

- Hỗ trợ kiểm thử tích hợp liên tục (CI/CD)

- Hỗ trợ kiểm thử đa nền tảng

Tính năng chính

Katalon Studio cung cấp một loạt các tính năng phong phú để hỗ trợ quá trình kiểm thử tự động toàn diện:

 Hỗ trợ kiểm thử giao diện người dùng (GUI)

- Sử dụng Selenium WebDriver để tự động hóa các thao tác trên trình duyệt web.

- Có các object spy, script recorder để ghi lại và tạo object repository.

- Tự động hóa các thao tác như: click, input text, chụp ảnh màn hình, scroll, drag/ drop.

- Xác thực các popup alert, iframes, windows.

- Tìm kiếm và xử lý các element dựa trên CSS, XPath

 Hỗ trợ kiểm thử API

- Gửi các request đến API và xác nhận response.

- Hỗ trợ nhiều loại request: GET, POST, PUT, DELETE.

- Kiểm tra status code, response body.

- Tích hợp với Postman để nhập dữ liệu kiểm thử.

 Tích hợp BDD với Cucumber

- Viết các feature file với ngôn ngữ tự nhiên (Gherkin).

- Chuyển đổi các feature thành các test case tự động.

- Tương thích với các framework BDD phổ biến

- Tích hợp Katalon với các CI/CD tool như Jenkins, CircleCI, Azure DevOps

- Chạy tự động kiểm thử trong pipeline.

- Tạo các báo cáo sau mỗi lần chạy kiểm thử.

 Object Spy và Script Recorder

- Object Spy để chụp lại các object trên UI.

- Script Recorder để ghi lại tự động các thao tác thành script.

- Cho phép chạy các tác vụ Katalon từ dòng lệnh.

- Tự động hóa các quy trình bằng script.

- Cộng đồng plugin phong phú để mở rộng khả năng Katalon.

- Hỗ trợ tích hợp nhiều công nghệ và framework khác.

 Báo cáo và phân tích kết quả

- Báo cáo chi tiết về kết quả chạy kiểm thử

- Phân tích thống kê để cải thiện quy trình kiểm thử.

- +ích hợp chia sẻ báo cáo trên nhiều nền tảng.

 Tool hỗ trợ đa ngôn ngữ

- Hỗ trợ các ngôn ngữ phổ biến: Java, Groovy, Python, C#, Ruby.

- Dễ dàng mở rộng cho các ngôn ngữ lập trình khác.

Nhìn chung, Katalon Studio cung cấp một giải pháp tự động hóa kiểm thử end-to-end,tích hợp đầy đủ các tính năng để xây dựng và thực thi các ca kiểm thử tự động hiệu quả.

Ưu, nhược điểm

- Giao diện đồ họa trực quan, thân thiện với người dùng mới bắt đầu.

- Không yêu cầu kiến thức lập trình sâu rộng Cú pháp script đơn giản, dễ hiểu.

- Hỗ trợ nhiều ngôn ngữ lập trình phổ biến như Java, Groovy, Python.

- Tích hợp sẵn framework kiểm thử UI Selenium và API Cucumber Không phải cài đặt riêng.

- Object Spy và Script Recorder giúp ghi lại các thao tác và tạo script tự động.

- Cung cấp các built-in keywords để thao tác với các điều khiển UI.

- Báo cáo chi tiết về kết quả chạy và thống kê kiểm thử.

- Khả năng mở rộng với các plugin và API tùy chỉnh.

- Tích hợp CI/CD để chạy tự động kiểm thử.

- Tốc độ chạy script có thể chậm hơn so với các công cụ khác.

- Khả năng xử lý lỗi và tìm nguyên nhân còn hạn chế.

- Chưa hỗ trợ một số tính năng debug nâng cao.

- Khó khăn trong việc tùy biến và mở rộng các keyword.

- Chưa hỗ trợ tốt cho môi trường lập trình hướng đối tượng.

- Cần cải thiện khả năng xử lý với các ứng dụng phức tạp và thay đổi liên tục.

- Chi phí cao khi sử dụng bản Enterprise với nhiều tính năng nâng cao.

- Cộng đồng người dùng và tài liệu hỗ trợ chưa nhiều như một số công cụ khác.

Hướng dẫn cài đặt, hướng dẫn sử dụng công cụ

3.5.1 Bắt đầu với Katalon Studio

- Tải phần mềm theo đường link sau: https://www.katalon.com/

- Sau khi tải về, vào file theo đường dẫn cài đặt lúc tải về.

- Để khởi động Katalon Studio, nhấp đúp vào katalon.exe (Microsoft

Sau khi khởi động, màn hình sẽ hiển thị như sau:

Sau khi khởi chạy Katalon Studio, hãy cung cấp tên người dùng và mật khẩu đã đăng ký để kích hoạt Katalon Studio Tên người dùng và mật khẩu giống như tên mà người dùng đã đăng ký để tải xuống Katalon Studio từ https://www.katalon.com/

Nếu như gặp sự cố khi kích hoạt Katalon Studio do sự cố proxy, người dùng có thể nhấp vào Cấu hình proxy để định cấu hình cài đặt proxy phù hợp.

Khi project được kích hoạt, màn hình Quick Guide được hiển thị để hướng dẫn nhanh qua tất cả các tính năng chính Người dùng có thể bỏ qua phần này và xem Quick

Guide từ phần Help trong menu.

3.5.3 Hướng dẫn chạy chương trình demo

1 Mở folder chứa Project đã được tải về

2 Mở các file sau và quan sát: Test cases, Object Repository, Data Files.

- Object Repository chứa các Object được lấy về từ trang web:

- Nhấp nút Add và chọn những Test Case muốn chạy. à Hiển thị những Test Case được chọn.

- Click vào Show Data Binding để hiển thị những dữ liệu ràng buộc.

- Click vào Add trong Test Data để thêm file Cơ sở dữ liệu vào Test Suites Sau đó chọn cơ sở dữ liệu phù hợp.

- Sau khi thêm được Cơ sở dữ liệu, Có thể tùy chọn cho mỗi Test case sử dụng những dòng dữ liệu tương ứng trong cơ sở dữ liệu Click vào thuộc tính của DataIteration để điều chỉnh.

- Điều chỉnh các biến ràng buộc như trong bảng sau trong phần Variable

Binding (góc phải màn hình) để có thể lấy được ra dữ liệu tương ứng từ bảng cơ sở dữ liệu.

- Sau đó, lựa chọn Trình duyệt và Thực thi

- Job Progress sẽ được kích hoạt tự động để hiển thị Progress trong khi Test suittes/ Test Case đang được thực thi.

- Phần Log Viewer hiển thị report/log trong thời gian thực của việc thực thi test.Các kết quả sẽ được hiển thị ở đây

- Cuối cùng, vào trong Report, lựa chọn file vừa chạyà hiển thị report như sau:

- Để Export được kết quả, chọn Report và làm như sau:

So sánh với công cụ khác

Tính năng Selenium QTP/UFT Katalon Studio

Nền tảng phát triển kiểm thử

Cross-platform Window Cross-platform

Web apps Windows desktop, Web,

Mobile apps, API/ Web services

Web, Mobile, API/ Web services

Java, C#, Perl, Python, JavaScript, Ruby, PHP

Tính năng Selenium QTP/UFT Katalon Studio

Kĩ năng nâng cao cần thiết để tích hợp cho các công cụ khác nhau.

Không yêu cầu Đề xuất cho các kịch bản nâng cao.

Dễ cài đặt và sử dụng

Yêu cầu cài đặt và tích hợp các công cụ khác nhau

Dễ dàng cài đặt và chạy Dễ dàng cài đặt và chạy

Thời gian tạo kịch bản

Lưu trữ và bảo trì đối tượng

XPath, bản đồ UI Kho lưu trữ đối tượng tích hợp, phát hiện và điều chỉnh đối tượng thông minh

Kho lưu trữ đối tượng tích hợp, XPath, nhận dạng lại đối tượng

Kiểm thử dựa trên hình ảnh

Yêu cầu cài đặt thư viện bổ sung

Hỗ trợ tích hợp, nhận dạng đối tượng dựa trên hình ảnh

Không Không Katalon phân tích

Loại giấy phép Mã nguồn mở (Apache

Bản quyền Phần mềm miễn phí

Phí Miễn phí Phí giấy phép và bảo trì Miễn phí

Giới thiệu về hệ thống quản lý siêu thị

Mô tả chung về sản phẩm phần mềm

Hệ thống quản lý siêu thị có thể ứng dụng vào các siêu thị vừa và nhỏ, nhằm đơn giản hóa việc quản lý nhập hàng, xuất hóa đơn và báo cáo thống kê hàng tháng Hệ thống bao gồm 1 website giúp quản lý hàng hóa, loại hàng hóa, quản lý nhân viên, quản lý nhà cung cấp, báo cáo thống kê 1 ứng dụng di động hỗ trợ việc tạo hóa đơn bằng các quét mã vạch từ điện thoại.

Đặc tả chức năng

STT Chức Năng Mô Tả

Hệ thống cho phép thêm hàng hóa mới, sửa hàng hóa đã tồn tại, xóa hàng hóa đã hết và xem thông tin hàng hóa

2 Quản lý nhà cung cấp

Hệ thống cho phép xem lại các nhà cung cấp, thêm nhà cung cấp mới, sửa nhà cung cấp.

Hệ thống cho phép nhập hàng mới và xem danh sách phiếu nhập hàng cũ

4 Quản lý xuất hóa đơn

Hệ thống cho phép xuất hóa đơn mới, xem danh sách hóa đơn đã xuất

5 Quét mã QR App trên điện thoại có thể quét mã QR của sản phẩm để hỗ trợ cho chức năng xuất hóa đơn

6 Quản lý thông tin cá nhân

Chức năng này giúp người dùng có thể xem và cập nhật thông tin quá nhân của mình qua app

Demo giao diện

4.3.2 Quản lý nhà cung cấp

4.3.6 Cập nhật thông tin cá nhân

Báo cáo kết quả buổi test tổng thể

Kiểm thử hộp đen

5.1.1 Chức năng thêm hàng hóa

 Phương pháp lựa chọn: Kiểm thử bằng bảng quyết định

- Điều kiện 1: nhập thông tin mã hàng hóa

- Điều kiện 2: nhập thông tin tên hàng hóa

- Điều kiện 3: nhập thông tin đơn vị tính

- Điều kiện 4: nhập thông tin barcode

- Điều kiện 5: nhập thông tin giá bán

- Điều kiện 6: chọn loại hàng hóa

Giá trị của điều kiện: 3, đúng (T), sai (F), Rỗng ( B)

- Thêm hàng hóa thành công (T) hay không (F)

 Bảng quyết định chức năng thêm hàng hóa Điều kiện TH1 TH2 TH3 TH4 TH5 TH6 TH7 TH8 TH9 TH10 ĐK1 T T T T T T T T F B ĐK2 T T T T T T T B - - ĐK3 T T T T T T B - - - ĐK4 T T T T F B - - - - ĐK5 T T F B - - - - ĐK6 T B - - - -

Thêm thành công hay không

 Kịch bản chức năng thêm hàng hóa

ID Tiêu đề Mô tả kịch bản Kết quả mong đợi Kết quả thực tế Kết quả

Thêm hàng hóa thành công

1 Nhập mã hàng là duy nhất

Thông báo thêm thành công

Thêm hàng hóa không thành công

6 Bỏ trống chọn loại hàng

Thông báo chưa chọn loại hàng

5 Nhập giá bán nhỏ hơn không

Thông báo giá bán không hợp lệ

TC4 Thêm hàng hóa không

Thông báo chưa nhập giá bán thành công

4 Nhập barcode đã tồn tại

Thông báo barcode đã tồn tại

Thông báo chưa nhập barcode.

3 Bỏ trống đơn vị tính

Thông báo chưa nhập đơn vị tính.

Thông báo chưa nhập tên hàng

Thông báo mã hàng hóa đã tồn tại TC10

1 Bỏ trống mã hàng Thông báo chưa nhập tên hàng

 Bảng kết quả testcase Thêm hàng hóa

Thêm hàng hóa thành công

1 Nhập mã hàng là duy nhất

Thông báo thêm thành công PASS

Thông báo chưa chọn loại hàng PASS

5 Nhập giá bán nhỏ hơn không

Thông báo chưa chọn loại hàng FAIL

Thông báo chưa nhập giá bán

Thông báo chưa nhập giá bán PASS

4 Nhập barcode đã tồn tại

Thông báo barcode đã tồn tại PASS

Thông báo thêm thành công FAIL

Thông báo chưa nhập tên hàng PASS

1 Nhập mã hàng trùng Thông báo mã hàng hóa đã tồn tại

Thông báo mã hàng hóa đã tồn tại PASS

TC10 Thêm hàng 1 Bỏ trống mã hàng Thông báo chưa Thông báo chưa nhập PASS hóa không thành công nhập tên hàng tên hàng

 Bảng test report chức thêm hàng hóa

Số lượng testcase Số lượng passed Số lượng Fail Số lượng test không chạy

5.1.2 Chức năng sửa hàng hóa

- Điều kiện 1: sửa thông tin mã hàng hóa

- Điều kiện 2: sửa thông tin tên hàng hóa

- Điều kiện 3: sửa thông tin đơn vị tính

- Điều kiện 4: sửa thông tin barcode

- Điều kiện 5: sửa thông tin giá bán

- Điều kiện 6: sửa loại hàng hóa

Giá trị của điều kiện: 3, đúng (T), sai (F), Rỗng ( B)

- Sửa hàng hóa thành công (T) hay không (F)

 Bảng quyết định chức năng sửa hàng hóa Điều kiện TH1 TH2 TH3 TH4 TH5 TH6 TH7 TH8 TH9 TH10 ĐK1 T T T T T T T T F B ĐK2 T T T T T T T B - - ĐK3 T T T T T T B - - - ĐK4 T T T T F B - - - - ĐK5 T T F B - - - - ĐK6 T B - - - -

Sửa thành công hay không

 Kịch bản test chức năng sửa hàng hóa

TC1 Sửa hàng hóa thành công

1 Đăng nhập với tài khoản admin

2 Sửa mã hàng là duy nhất

Thông báo cập nhật thành công

TC2 Sửa hàng hóa không thành công

Thông báo chưa chọn loại hàng TC3 Sửa hàng hóa không thành công

2 Sửa giá bán nhỏ hơn không

Thông báo chưa nhập giá bán TC5 Sửa hàng hóa không thành công

2 Sửa barcode đã tồn tại

Thông báo barcode đã tồn tại TC6 Sửa hàng hóa không thành công

2 Sửa mã hàng trùng Thông báo mã hàng hóa đã tồn tại TC10 Sửa hàng hóa không thành công

Thông báo chưa nhập tên hàng TC11 Sửa hàng hóa không thành công

1 Đăng nhập với tài khoản nhân viên

Thông báo lỗi không có quyền truy cập

 Bảng kết quả testcase Sửa hàng hóa

TC1 Sửa hàng hóa thành công

2 Sửa mã hàng là duy nhất

Kết quả thực tế Kết quả

2 Sửa giá bán nhỏ hơn không

2 Sửa barcode đã tồn tại

2 Sửa mã hàng trùng Thông báo mã hàng hóa đã tồn tại

1 Đăng nhập với tài khoản nhân viên

Thông báo lỗi không có quyền truy cập

Thông báo chưa nhập mã hàng

 Bảng test report chức năng sửa hàng hóa

5.1.3 Chức năng xóa hàng hóa

- Điều kiện 1: Xác nhận chắc chắn xóa

Giá trị của điều kiện: 3, đúng (T), sai (F)

- Xóa hàng hóa thành công (T) hay không (F)

 Bảng quyết định chức năng sửa hàng hóa Điều kiện TH1 TH2 ĐK1 T F

Xóa thành công hay không T F

 Kịch bản test chức năng xóa hàng hóa

TC1 Xóa hàng hóa thành công

2 Xác nhận xóa hàng hóa

Thông báo xóa thành công TC2 Xóa hàng hóa không thành công

2 Bấm quay lại, không xác nhận

Thông báo xóa không thành công

 Bảng kết quả testcase Xóa hàng hóa

TC1 Xóa hàng hóa thành công

2 Xác nhận xóa hàng hóa

Thông báo xóa thành công

TC2 Xóa hàng hóa không thành công

2 Bấm quay lại, không xác nhận

Thông báo xóa không thành công

 Bảng test report chức năng xóa hàng hóa

Số lượng test không chạy

5.1.4 Chức năng thêm nhà cung cấp

- Điều kiện 1: Nhập thông tin mã nhà cung cấp

- Điều kiện 2: Nhập thông tin tên nhà cung cấp

- Điều kiện 3: Nhập thông tin số điện thoại

- Điều kiện 4: Chọn trạng thái

- Điều kiện 5: Nhập địa chỉ

Giá trị của điều kiện: 3, đúng (T), sai (F), Rỗng (B)

- Thêm nhà cung cấp thành công (T) hay không (F)

 Bảng quyết định chức năng thêm nhà cung cấp Điều kiện TH

TH1 0 ĐK1 T T T T T T T T B F ĐK2 T T T T T T B F - - ĐK3 T T T T B F - - - - ĐK4 T T T B - - - - ĐK5 T B F - - - -

Thêm thành công hay không

 Kịch bản chức năng thêm nhà cung cấp

TC1 Thêm nhà cung cấp thành công

2 Nhập mã nhà cung cấp là duy nhất

3 Nhập tên nhà cung cấp

TC2 Thêm nhà cung cấp không thành công

2 Nhập mã nhà cung cấp

6 Bỏ trống nhập địa chỉ

Thông báo chưa nhập địa chỉ

6 Nhập địa chỉ vượt quá số lượng kí tự cho phép

Thông báo nhập địa chỉ quá số lượng kí tự cho phép

Thông báo chưa chọn trạng thái

4 Bỏ trống nhập số điện thoại

Thông báo chưa nhập số điện thoại

4 Nhập sai định dạng số điện thoại

Thông báo nhập sai định dạng số điện thoại

3 Bỏ trống nhập tên nhà cung cấp

Thông báo chưa nhập tên nhà cung cấp

2 Bỏ trống nhập mã nhà cung cấp

Thông báo chưa nhập mã nhà cung cấp

TC9 Thêm nhà 1 Đăng nhập với tài khoản admin Thông báo mã nhà cung cấp không thành công

2 Nhập trùng mã nhà cung cấp cung cấp đã tồn tại

1 Đăng nhập với tài khoản nhân viên Thông báo không có quyền truy cập

 Bảng kết quả testcase Thêm nhà cung cấp

TC1 Thêm nhà cung cấp thành công

TC2 Thêm nhà cung cấp không thành

PASS công 4 Nhập số điện thoại

TC6 Thêm nhà cung cấp không thành

PASS công 4 Nhập sai định dạng số điện thoại

2 Nhập trùng mã nhà cung cấp

Thông báo mã nhà cung cấp đã tồn tại

Thông báo không có quyền truy cập

 Bảng test report chức thêm nhà cung cấp

5.1.5 Chức năng sửa nhà cung cấp

- Điều kiện 1: Sửa thông tin mã nhà cung cấp

- Điều kiện 2: Sửa thông tin tên nhà cung cấp

- Điều kiện 3: Sửa thông tin số điện thoại

- Điều kiện 4: Chọn trạng thái

- Điều kiện 5: Sửa thông tin địa chỉ

Giá trị của điều kiện: 3, đúng (T), sai (F), Rỗng (B)

- Sửa nhà cung cấp thành công (T) hay không (F)

 Bảng quyết định chức năng sửa nhà cung cấp Điều kiện TH

0 ĐK1 T T T T T T T T B F ĐK2 T T T T T T B F - - ĐK3 T T T T B F - - - - ĐK4 T T T B - - - - ĐK5 T B F - - - -

Sửa thành công hay không

 Kịch bản chức năng sửa nhà cung cấp

TC1 Sửa nhà cung cấp thành công

Thông báo sửa thành công

TC2 Sửa nhà cung cấp không thành công

Thông báo nhập địa chỉ quá số lượng kí tự cho phép TC4 Sửa nhà cung cấp không thành công

Thông báo chưa nhập số điện thoại TC6 Sửa nhà cung 1 Đăng nhập với tài khoản admin Thông báo nhập sai cấp không thành công

2 Nhập sai định dạng số điện thoại định dạng số điện thoại TC7 Sửa nhà cung cấp không thành công

Thông báo chưa nhập mã nhà cung cấp TC9 Sửa nhà cung cấp không thành công

 Bảng kết quả testcase Sửa nhà cung cấp

TC1 Sửa nhà cung 1 Đăng nhập với tài khoản admin Thông báo sửa Thông báo sửa thành PASS cấp thành công

6 Nhập địa chỉ thành công công

2 Nhập sai định dạng số điện thoại

TC7 Sửa nhà cung 1 Đăng nhập với tài khoản admin Thông báo chưa Thông báo chưa nhập PASS cấp không thành công

2 Bỏ trống nhập tên nhà cung cấp nhập tên nhà cung cấp tên nhà cung cấp

Thông báo không có quyền truy cập

 Bảng test report chức năng sửa nhà cung cấp

Số lượng Fail Số lượng test không chạy

5.1.6 Chức năng tạo hóa đơn

- Điều kiện: o C1 = Nhập ngày xuất hóa đơn o C2 = Nhập tên người mua o C3 = Nhập địa chỉ người mua o C4 = Nhập sản phẩm o C5 = Nhập số lượng

- Giá trị điều kiện: o True (T): Đúng o False (F): Sai o Blank (B): Rỗng

- Hành động hệ thống: H = Đổi mật khẩu thành công? (T/F)

Bảng quyết định Điều kiện TH1 TH2 TH3 TH4 TH5 TH6

Kịch bản cho chức năng đổi mật khẩu tài khoản đã đăng ký

1 Tạo hóa đơn thành công

1 Nhập ngày xuất hóa đơn

3 Nhập địa chỉ người mua

Thông báo tạo hóa đơn thành công

2 Thêm hóa đơn không thành công với số lượng bị bỏ trống

Báo lỗi số lượng bỏ trống

3 Thêm hóa đơn không thành công với 0 sản phẩm

Báo lỗi không có sản phẩm nào được thêm vào

4 Thêm hóa đơn không thành công

Báo lỗi địa chỉ người mua trống với địa chỉ người mua trống

3 Bỏ trống địa chỉ người mua

5 Thêm hóa đơn không thành công với tên người mua trống

2 Bỏ trống tên người mua

Báo lỗi tên người mua trống

6 Thêm hàng hóa không thành công với ngày xuất hóa đơn trống

1 Bỏ trống ngày xuất hóa đơn

Báo lỗi ngày nhập hóa đơn trống

 Bảng test report chức năng đổi mật khẩu (APP)

Kiểm thử hộp trắng

Kiểm thử bằng Đồ thị luồng điều khiển: Được Tom McCabe đề xuất năm 1976 Đồ thị luồng điều khiển được xây dựng bằng cách gộp những câu lệnh tuần tự liên tiếp và rẽ nhánh sau nó thành một nút (Node), thay các lệnh rẽ nhánh hay điểm hợp nhất của các đường rẽ nhánh thành một nút (Node) Các đường nối giữa các nút (Node) là cung (Edge).

Nhóm chúng em thực hiện kiểm thử hộp trắng cho các chức năng dưới đây của ứng dụng dùng kỹ thuật Kiểm thử bằng Đồ thị luồng điều khiển bởi vì:

- Có được mã nguồn của app

- Ngôn ngữ mà app được viết lên chúng em có thể hiểu được

- Sau khi phân tích luồng, đồ thị luồng điều khiển của các chức năng được test tương đối đơn giản

5.2.1 Chức năng App Quét Mã QR của hàng hóa (APP)

 Đồ thị luồng điều khiển

- C: là độ phức tạp (Số lần thực thi tuyến tính độc lập cần phải thực hiện kiểm thử tối thiểu)

- P: là số đỉnh, số nút quyết định (Node có 2 nhánh mũi tên hướng ra ngoài) o C = (E – N) + 2 = (12 – 10) + 2 = 4 o C = P + 1 = 2 + 1 = 3

Vậy đồ thị trên không là đồ thị dòng điều khiển nhị phân vì các đỉnh quyết định có một nút không rẽ 2 nhánh. Độ phức tạp là C = 4

Các cấp độ phủ của test path

C2: Phủ tất cả các cung

ID Test Path Data Test

(valid QR) Xuất thông tin từ

(QR null) Thông báo lỗi

4 1 2 (C1) (no QR) Màn hình vẫn chờ mã QR

5.2.2 Chức năng đổi mật khẩu (APP)

- P: là số đỉnh, số nút quyết định (Node có 2 nhánh mũi tên hướng ra ngoài)

Vậy đồ thị trên là đồ thị dòng điều khiển nhị phân vì các đỉnh quyết định đều rẽ

2 nhánh. Độ phức tạp là C = 2

 Các cấp độ phủ của test path

C1: Phủ các câu lệnh C2: Phủ tất cả các cung C3: Phủ các quyết định

Data Test (oldPassword, password, passwordConfirmation)

Thông báo đổi mật khẩu thành công

(invalid, bechikien,neikihceb) Thông báo lỗi mật khẩu cũ

5.2.4 Chức năng cập nhật thông tin (APP)

- P: là số đỉnh, số nút quyết định (Node có 2 nhánh mũi tên hướng ra ngoài)

Vậy đồ thị trên là đồ thị dòng điều khiển nhị phân vì các đỉnh quyết định đều rẽ

2 nhánh. Độ phức tạp là C = 2

 Các cấp độ phủ của test path

C1: Phủ các câu lệnh C2: Phủ tất cả các cung C3: Phủ các quyết định

ID Test Path Data Test (name, date, address, gender)

(kien@*&@#^duc, hai 00 hai, t2uyen, 1)

Thông báo cập nhật không thành công

5.2.5 Tổng hợp Test Case Kiểm thử hộp trắng các chức năng của App (QR, đổi mật khẩu, cập nhật thông tin)

Số lượng passed Số lượng Fail Số lượng test không chạy

Định dạng
Số trang	79
Dung lượng	2,68 MB

Tiêu đề	Báo cáo môn kiểm thử và đảm bảo chất lượng phần mềm
Chuyên ngành	Kiểm thử và đảm bảo chất lượng phần mềm
Thể loại	báo cáo