Thực hiện kiểm thử hệ thống quản lý sâu bệnh hại lúa trên tỉnh bình định

GIỚI THIỆU TỔNG QUAN VỀ CÔNG TY VÀ VỊ TRÍ THỰC TẬP

Tổng quan về vị trí thực tập

TMA đã thành lập nhiều quỹ nhằm hỗ trợ nhân viên và cộng đồng, bao gồm Quỹ từ thiện "Khát vọng TMA" giúp đỡ tài chính cho những người có hoàn cảnh khó khăn trên toàn quốc, Quỹ Team Building hỗ trợ các hoạt động ngoại khóa hàng năm cho nhân viên, và Quỹ khen thưởng hàng Quý với tổng giá trị lên đến 1 tỷ đồng mỗi năm cho những nhân viên xuất sắc.

Chúng tôi cung cấp các khóa đào tạo toàn diện cho nhân viên mới và nhân viên tiềm năng, bao gồm kiến thức nền tảng về kỹ thuật như Frameworks, case studies, Bootstrap và IoT Bên cạnh đó, chúng tôi cũng chú trọng phát triển các kỹ năng mềm như teamwork, presentation và email writing Đặc biệt, chúng tôi tổ chức các chương trình dành riêng cho nhân viên tiềm năng và các khóa đào tạo chuyên môn cho những bộ phận cần nâng cao kiến thức, bao gồm kỹ năng lãnh đạo.

1.2 Tổng quan về vị trí thực tập

Kiểm tra phần mềm là quy trình xác định xem sản phẩm có đáp ứng các yêu cầu mong đợi hay không Phương pháp này giúp đảm bảo rằng sản phẩm không có lỗi và đáp ứng đầy đủ các yêu cầu của khách hàng cũng như tiêu chuẩn đã đặt ra.

- Giao tiếp với khách hàng

- Nghiên cứu, phân tích yêu cầu

- Viết kế hoạch kiểm thử, thiết kế testcase

- Thực hiện kiểm thử để phát hiện, nhận diện các lỗi của phần mềm

- Viết Bug Report (nếu có) , viết báo cáo kiểm tra chất lượng phần mềm

1.2.2 Yêu cầu kiến thức và kĩ năng

- Nắm rõ một số quy trình phát triển phần mềm (SDLC), Quy trình kiểm thử phần mềm (STLC)

- Nắm được một hay một số ngôn ngữ lập trình ở mức cơ bản để từ đó hiểu về kiến trúc hệ thống đang thực hiện

- Nắm rõ kỹ thuật, thuật ngữ chuyên ngành về Testing : Test Case, Bug, Defect, Black Box Testing , White Box Testing,

- Biết về các công cụ : Test Management tools (Quản lý hoạt động kiểm thử); Defect Tracking tools; các Automation tools như Selenium, Test Complete

- Kỹ năng phân tích yêu cầu: giúp nắm vững yêu cầu của khách hàng đối với sản phẩm

- Kỹ năng làm việc nhóm: giúp dễ dàng kết nối với các thành viên khác (Dev, BA, ) trong nhóm làm việc

- Kỹ năng giao tiếp : giúp dễ dàng trao đổi trong các buổi họp hằng ngày, dễ dàng truyền đạt với thành viên trong công ty

- Kỹ năng viết báo cáo : người kiểm thử cần viết báo cáo chi tiết, dễ hiểu để báo cáo tình trạng của phần mềm

- Ngoài ra Tester cần có những tính cách như : cẩn thận, chú ý những chi tiết nhỏ, điều này có thể giúp Tester không bỏ sót lỗi

1.2.3 Công việc của thực tập

Công việc theo một số kế hoạch như sau:

- Phần 1: Tổng quan về Testing Software - kiểm thử phần mềm:

- Phần 2 : Vòng đời phát triển phần mềm (SDLC)

- Phần 3 : Phương pháp kiểm thử phần mềm

- Phần 4 : Các loại kiểm thử, Cấp độ kiểm thử

- Phần 5 : Viết testcase và kiểm thử thủ công

- Phần 6: Cơ bản Selenium và kiểm thử tự động

1.2.4 Mức lương tại công ty thực tập

Mức lương của tester ngoài thị trường là:

- Intern Tester : chưa có kinh nghiệm, thực tập sinh : 1.000.0000 đồng đến 2.000.000 đồng/tháng

- Fresher Tester : đã có kiến thức cơ bản, nắm vững các quy trình testing, hiểu rõ cách viết test case, đã thực tập 4 - 6 tháng: 3.000.000 đồng/tháng

- Tester: đã có kinh nghiệm từ 2-3 năm, mức lương dao động trong khoảng 10.000.000 đồng - 14.000.000 đồng/tháng

Hình 4: Con đường phát triển của kiểm thử

Ngày nay, với sự phát triển nhanh chóng của nhiều phần mềm phục vụ cho nhu cầu quản lý, cơ hội nghề nghiệp cho người kiểm thử phần mềm ngày càng rộng mở Dưới đây là lộ trình phát triển nghề nghiệp của một kiểm thử viên.

Vị trí Fresher Tester là cơ hội lý tưởng cho những người mới tốt nghiệp mà không yêu cầu kinh nghiệm Ứng viên cần nắm vững các khái niệm cơ bản về kiểm thử phần mềm và hiểu rõ về nhiệm vụ mà mình sẽ thực hiện trong công việc.

Vị trí Junior Tester thường dành cho những người có từ 1-2 năm kinh nghiệm, cho phép họ kiểm thử các trường hợp phức tạp hơn Junior Tester yêu cầu nhiều kỹ năng hơn so với các ứng viên fresher, giúp nâng cao chất lượng quy trình kiểm thử.

● Senior tester : Vị trí này dành cho những người đã có hiểu biết, kinh nghiệm dày dặn trong lĩnh vực kiểm thử Có thời gian làm việc từ 3-5 năm

Test Leader là vị trí phát triển từ Senior Tester, đảm nhận vai trò quản lý và giám sát đội ngũ tester Người này không chỉ phân công công việc mà còn hỗ trợ các thành viên trong nhóm hoàn thành nhiệm vụ của mình.

Quản lý kiểm thử đóng vai trò quan trọng trong sự thành công của dự án, chịu trách nhiệm về hoạt động kiểm thử chất lượng, lập kế hoạch, quản lý tài nguyên và giải quyết các vấn đề cản trở quá trình kiểm thử.

Với những lợi thế hiện có, tester chỉ cần bổ sung một số kỹ năng như làm việc với khách hàng để dễ dàng chuyển sang vai trò Business Analyst (BA).

CƠ SỞ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM

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

Kiểm thử phần mềm là quy trình đánh giá xem sản phẩm phần mềm có đáp ứng được các yêu cầu mong đợi hay không Mục tiêu chính của kiểm thử là phát hiện các lỗi, lỗ hổng và những yêu cầu chưa được đáp ứng so với tiêu chuẩn thực tế.

Kiểm thử phần mềm đóng vai trò quan trọng trong việc phát hiện và khắc phục lỗi trước khi sản phẩm được bàn giao Quy trình kiểm tra kỹ lưỡng đảm bảo độ tin cậy, bảo mật và hiệu suất cao của phần mềm, từ đó tiết kiệm thời gian, giảm chi phí và nâng cao sự hài lòng của khách hàng.

Bảy nguyên tắc trong kiểm thử phần mềm

Hình 5: Bảy nguyên tắc trong kiểm thử phần mềm Kiểm thử chỉ ra sự hiện diện của lỗi

Kiểm thử là một hoạt động quan trọng nhằm phát hiện và kiểm tra lỗi trong phần mềm Quá trình này đảm bảo rằng tất cả các lỗi tiềm ẩn có thể bị bỏ qua trong giai đoạn phát triển sẽ được phát hiện kịp thời, giúp nâng cao chất lượng sản phẩm cuối cùng.

Kiểm thử toàn bộ là điều không thể

Người kiểm thử cần thừa nhận rằng việc kiểm tra mọi khía cạnh của ứng dụng là không khả thi Thay vì cố gắng kiểm tra toàn bộ, họ nên tập trung vào những phần quan trọng nhất để đảm bảo chất lượng sản phẩm.

Việc phân tích rủi ro theo 9 bộ giúp xác định các điểm cần tập trung kiểm thử, từ đó ưu tiên những khu vực có nguy cơ lỗi cao hơn.

Kiểm thử càng sớm càng tốt

Kiểm thử sớm đóng vai trò quan trọng trong việc đảm bảo chất lượng ứng dụng, giúp tiết kiệm thời gian và chi phí cho dự án Việc tiến hành kiểm thử ngay từ giai đoạn đầu của quá trình phát triển phần mềm là cần thiết, thay vì chỉ thực hiện kiểm tra khi sản phẩm đã hoàn thành.

Lỗi thường được phân bố tập trung

Nguyên tắc mật độ phân bổ lỗi trong sản phẩm cho thấy rằng hầu hết các lỗi được phát hiện trong quá trình kiểm thử thường tập trung ở một số module nhất định Theo nguyên lý Pareto, 80% lỗi xuất hiện trong chỉ 20% tính năng của hệ thống Dựa trên kinh nghiệm, người kiểm thử có khả năng nhận diện trước các module có nguy cơ cao.

Nghịch lý thuốc trừ sâu

Việc thực hiện một bộ test cases lặp đi lặp lại sẽ không còn hiệu quả trong việc phát hiện lỗi mới Do đó, các test cases cần được cập nhật và điều chỉnh thường xuyên Các tester cần liên tục cải thiện các phương pháp kiểm thử hiện tại để nâng cao hiệu quả kiểm tra.

Kiểm thử phụ thuộc vào ngữ cảnh

Cần áp dụng các phương pháp và kỹ thuật kiểm thử đa dạng, vì loại hình kiểm thử phụ thuộc vào từng loại phần mềm, ứng dụng hoặc website Mỗi dự án phần mềm có đặc điểm riêng, do đó chiến lược kiểm thử cũng cần được điều chỉnh để phù hợp với yêu cầu cụ thể của từng sản phẩm.

Quan niệm sai lầm về việc “hết lỗi”

Việc không phát hiện lỗi trong quá trình kiểm thử thường do bộ kiểm thử chỉ tập trung vào việc kiểm tra các tính năng đã được thực hiện đúng theo yêu cầu Do đó, các lỗi mới có thể không được phát hiện, dẫn đến việc không thể tìm kiếm và sửa chữa Vì vậy, việc không tìm thấy lỗi trên sản phẩm không có nghĩa là sản phẩm hoàn toàn không có lỗi.

Các cấp độ trong kiểm thử phần mềm

Hình 6: Các cấp độ trong kiểm thử phần mềm

2.3.1 Kiểm thử đơn vị (Unit Testing)

Một đơn vị là thành phần phần mềm nhỏ nhất có thể kiểm thử, bao gồm các hàm, thủ tục, lớp hoặc phương thức Kiểm thử đơn vị thường được thực hiện bởi lập trình viên trước khi chuyển giao cho đội kiểm thử để thực hiện các test case.

2.3.2 Kiểm thử tích hợp (Integration Testing)

Kiểm thử tích hợp là quá trình kiểm tra sự kết nối giữa các thành phần của chương trình để xác định chức năng hoạt động chính xác Nó tập trung vào việc kiểm tra luồng dữ liệu giữa các module khác nhau Loại kiểm thử này thường được thực hiện bởi các tester chuyên nghiệp.

Có hai kiểu kiểm thử tích hợp : Tích hợp từ dưới đi lên ( Bottom-up integration) và tích hợp đi trên đi xuống (Top-down integration)

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

Kiểm thử hệ thống nhằm xác định xem thiết kế và toàn bộ hệ thống đã được tích hợp có đáp ứng các yêu cầu đã đặt ra hay không Quá trình này bao gồm việc kiểm tra cả yêu cầu chức năng của phần mềm lẫn các yêu cầu chất lượng như hiệu suất, độ tin cậy, độ bền, khả năng chịu tải và bảo mật.

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

Kiểm thử chấp nhận nhằm đảm bảo rằng sản phẩm đáp ứng đầy đủ các yêu cầu của khách hàng và được khách hàng chấp nhận, xác nhận khả năng chấp nhận cuối cùng của sản phẩm.

Trong giai đoạn kiểm thử chấp nhận, khách hàng đóng vai trò là người kiểm tra phần mềm Họ sẽ đánh giá sản phẩm dựa trên những thao tác sử dụng quen thuộc, từ đó đảm bảo rằng phần mềm đáp ứng đúng yêu cầu và mong đợi của họ Việc thực hiện kiểm tra ở giai đoạn này rất quan trọng để tránh hiểu sai yêu cầu và đảm bảo sự hài lòng của khách hàng.

Phương pháp kiểm thử phần mềm

Hình 7: Hai phương pháp kiểm thử phần mềm

Kiểm thử hộp trắng là phương pháp kiểm thử phần mềm mà người kiểm thử hiểu rõ cấu trúc nội bộ của ứng dụng Các trường hợp kiểm thử được xây dựng dựa trên cấu trúc mã nguồn và cách thức hoạt động của chương trình Để thực hiện kiểm thử hộp trắng hiệu quả, kiến thức lập trình là yếu tố không thể thiếu.

Kiểm thử hộp đen là phương pháp kiểm thử phần mềm mà không yêu cầu hiểu biết về cấu trúc bên trong của ứng dụng Người kiểm thử chỉ dựa vào đầu vào và đầu ra của chương trình để thực hiện các bài kiểm tra.

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

2.5.1 Phân tích vùng tương đương

Phân tích vùng tương đương là kỹ thuật chia nhỏ các điều kiện đầu vào thành các vùng tương đương nhằm tối ưu hóa số lượng trường hợp kiểm thử Mục tiêu của phương pháp này là giảm thiểu số lượng trường hợp cần kiểm tra, từ đó nâng cao hiệu quả của quá trình kiểm thử phần mềm.

Với các giá trị đầu vào chia thành các vùng tương đương:

- Vùng tương đương hợp lệ: tập hợp các giá trị kiểm thử thỏa mãn điều kiện của hệ thống

- Vùng tương đương không hợp lệ: Tập hợp các giá trị kiểm thử mô tả trạng thái khác của hệ thống: sai, thiếu, không đúng,

2.5.2 Phân tích giá trị biên

Phân tích giá trị biên tập trung vào việc xác định giá trị ranh giới trong một phạm vi giá trị nhất định để kiểm tra tính chấp nhận của hệ thống Kỹ thuật này lựa chọn các giá trị nằm ở ranh giới để thực hiện kiểm thử hiệu quả.

Bảng quyết định là một kỹ thuật kiểm thử hiệu quả, giúp kiểm tra các hành vi của hệ thống thông qua việc sử dụng các kết hợp dữ liệu đầu vào khác nhau Phương pháp này mang tính hệ thống, cho phép ghi lại kết quả của các kết hợp đầu vào và hành vi tương ứng của hệ thống dưới dạng bảng, từ đó hỗ trợ trong việc phân tích và đánh giá hiệu suất của hệ thống.

2.5.4 Đoán lỗi Đoán lỗi là một kỹ thuật kiểm thử phần mềm dựa trên việc đoán lỗi có thể chiếm ưu thế trong code Đây là một kỹ thuật dựa trên kinh nghiệm Người kiểm thử vận dụng kinh nghiệm của mình để đoán chức năng có vấn đề hoặc có lỗi của hệ thống đang kiểm thử

PHÂN TÍCH HỆ THỐNG

Phân tích use case “Quản lý tài khoản”

3.2.1 Sơ đồ use case tổng quát cho chức năng “Quản lý tài khoản”

Hình 10: Usecase chức năng Quản lý tài khoản

3.2.2 Phân tích use case “Đổi mật khẩu” a, Sơ đồ hoạt động của “Đổi mật khẩu”

Hình 11: Sơ đồ hoạt động của chức năng Đổi mật khẩu

16 b, Đặc tả yêu cầu cho use case “Đổi mật khẩu”

- Điều kiện tiên quyết: Tài khoản đã đăng nhập vào hệ thống

- Mô tả khái quát: Use case này được thực hiện khi người dùng mong muốn đổi mật khẩu của họ

Bước 1: Người dùng thực hiện đăng nhập vào web bằng “Tên đăng nhập” và “Mật khẩu” rồi chọn nút “Đăng nhập”

Hình 12: Màn hình đăng nhập

Bước 2: Hệ thống xác nhận và đưa người dùng vào màn hình chính Tại đây người dùng chọn “Thông tin cá nhân” và chọn “Đổi mật khẩu”

Hình 13: Màn hình quản lý thông tin tài khoản

Bước 3: Hệ thống sẽ tiếp nhận yêu cầu và hiển thị màn hình “Đổi mật khẩu” Tại đây, người dùng cần nhập thông tin gồm Mật khẩu cũ, Mật khẩu mới, và Nhập lại mật khẩu mới Sau khi hoàn tất, hãy chọn “Lưu” để xác nhận.

Hình 14: Màn hình Đổi mật khẩu

Bước 4: Hệ thống kiểm tra dữ liệu nhập vào

- Nếu thông tin đổi mật khẩu hợp lệ thì hệ thống sẽ hiện popup thông báo thành công

- Nếu thông tin đổi mật khẩu không hợp lệ thì hệ thống sẽ báo lỗi :

Tên trường Yêu cầu kiểm tra

Mật khẩu cũ - Nếu nhập mật khẩu sai thì thông báo lỗi “Mật khẩu sai”

Mật khẩu mới - Nếu mật khẩu khẩu mới giống mật khẩu cũ thông báo

“Mật khẩu mới trùng với mật khẩu cũ”

- Nếu nhập mật khẩu mới ít hơn 6 kí tự thì hệ thống thông báo lỗi “Mật khẩu phải nằm trong khoảng 6 đến

- Nếu nhập mật khẩu mới nhiều hơn 20 kí tự thì hệ thống thông báo lỗi “Mật khẩu phải nằm trong khoảng 6 đến 20 kí tự”

Nhập lại mật khẩu mới - Nếu nhập lại khẩu mới không giống mật khẩu cũ thông báo “Mật khẩu không trùng khớp”

Bảng 1: Yêu cầu kiểm tra của chức năng Đổi mật khẩu

3.2.3 Phân tích use case “Chỉnh sửa thông tin tài khoản” a, Sơ đồ hoạt động của chức năng “Chỉnh sửa thông tin tài khoản”

Hình 15: Sơ đồ hoạt động của chức năng Chỉnh sửa thông tin tài khoản b, Đặc tả yêu cầu cho use case “Chỉnh sửa thông tin tài khoản”

- Mô tả khái quát: Use case này được thực hiện khi người dùng mong muốn chỉnh sửa thông tin cá nhân của họ

Bước 1: Người dùng thực hiện đăng nhập vào web bằng “Tên đăng nhập” và “Mật khẩu” rồi chọn nút “Đăng nhập” (Hình 12: Màn hình đăng nhập)

Bước 2: Hệ thống xác nhận và đưa người dùng vào màn hình chính Tại đây người dùng chọn “Thông tin cá nhân”

Hình 16: Màn hình Quản lý thông tin tài khoản

Bước 3: Hệ thống hiển thị màn hình “Thông tin tài khoản” Tại đây người dùng chọn

Hình 17: Màn hình chỉnh sửa thông tin tài khoản (1)

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Chỉnh sửa thông tin tài khoản”

, tại đây người dùng nhập thông tin chỉnh sửa bao gồm: Họ và tên, số điện thoại, email Sau đó chọn “Lưu”

Hình 18: Màn hình chỉnh sửa thông tin tài khoản (2)

 Nếu thông tin chỉnh sửa hợp lệ thì hệ thống sẽ thông báo “Cập nhật thông tin tài khoản thành công”

 Nếu thông tin chỉnh sửa không hợp lệ thì hệ thống sẽ báo lỗi

Họ và tên - Nếu bỏ trống thì thông báo “Họ và tên không hợp lệ”

- Nếu chỉnh sửa “Họ và tên” quá 50 kí tự thì hệ thống thông báo “ Họ và tên không được vượt quá 50 kí tự”

Số điện thoại - Nếu số điện thoại ít hơn 10 số hoặc là nhiều hơn 11 số thì thông báo lỗi “Số điện thoại không hợp lệ”

- Nếu nhập kí tự khác số hiển thị thông báo “Số điện thoại không hợp lệ”

- Nếu bỏ trống thì thông báo “Số điện thoại không hợp lệ”

Email - Nếu email nhập vào không đúng format String@domain thì , hiển thị thông báo lỗi “Email không hợp lệ”

- Email là không bắt buộc nhập

Bảng 2: Yêu cầu kiểm tra của chức năng Chỉnh sửa thông tin tài khoản

Phân tích use case “Quản lý dữ liệu người dùng”

3.3.1 Sơ đồ use case tổng quát cho chức năng “Quản lý dữ liệu người dùng”

Hình 19: Usecase chức năng Quản lý dữ liệu người dùng

3.3.2 Phân tích use case “Thêm thông tin người dùng” a, Sơ đồ hoạt động của chức năng “Thêm thông tin người dùng”

Hình 20: Sơ đồ hoạt động của chức năng Thêm người dùng

22 b, Đặc tả yêu cầu cho use case “Thêm thông tin người dùng”

- Mô tả khái quát: Use case này được thực hiện khi admin mong muốn thêm người dùng mới cho hệ thống

Bước 1: Người dùng thực hiện đăng nhập vào web bằng “Tên đăng nhập” và “Mật khẩu” rồi nhấn nút “Đăng nhập” (Hình 12: Màn hình đăng nhập)

Bước 2: Hệ thống xác nhận và đưa người dùng vào màn hình chính Tại đây người dùng chọn “Quản lý dữ liệu” và chọn “Người dùng”

Hình 21: Màn hình Thêm người dùng (1)

Bước 3: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Danh sách người dùng” , tại đây người dùng chọn “Thêm người dùng”

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Thêm người dùng” , tại đây người dùng nhập thông tin bao gồm:

Tên trường Trường bắt buộc

Bảng 3: Phân tích usecase Thêm người dùng

Sau đó click nút “Lưu”

 Nếu thông tin người dùng hợp lệ thì hệ thống sẽ hiện thông báo “Thêm người dùng thành công”

 Nếu thông tin người dùng không hợp lệ thì hệ thống sẽ không cho cho phép thêm dữ liệu

Họ tên - Nếu bỏ trống họ và tên thì thông báo lỗi “Họ và tên là bắt buộc”

- Nếu nhập họ và tên quá 50 kí tự thì thông báo “Họ và tên vượt quá kí tự cho phép”

Số điện thoại - Nếu nhập ký tự khác số hiển thị thông báo “Số điện thoại không hợp lệ”

- Nếu số điện thoại ít hơn 10 số hoặc là nhiều hơn 11 số thì thông báo lỗi “Số điện thoại không hợp lệ”

- Nếu không nhập số điện thoại thì thông báo lỗi “Số điện thoại là bắt buộc”

- Nếu nhập số điện thoại trùng thì với số điện thoại đã tồn tại thì thông báo lỗi “Số điện thoại đã tồn tại trong hệ thống”

Email - Nếu email nhập vào không đúng format String@domain thì , hiển thị thông báo lỗi “Email không hợp lệ”

- Nếu Email nhập vượt quá 50 kí tự thì thông báo “Email vượt quá kí tự cho phép”

Email không bắt buộc phải nhập Nếu trường "Vai trò" bị bỏ trống, hệ thống sẽ hiển thị thông báo lỗi "Vai trò là bắt buộc" Tương tự, nếu trường "Địa chỉ" không được điền, người dùng sẽ nhận được thông báo lỗi "Địa chỉ là bắt buộc".

Mô tả - Nếu nhập mô tả quá 225 kí tự thì thông báo lỗi “Mô tả vượt quá kí tự cho phép”

- Nếu bỏ trống trường “Tên đăng nhập” thì thông báo lỗi “Tên đăng nhập là bắt buộc”

- Nếu tên đăng nhập sử dụng kí tự đặc biệt,chữ có dấu,có dấu cách thì thông báo lỗi “Tên đăng nhập không đúng định dạng”

- Nếu tên đăng nhập quá 20 kí tự thì thông báo lỗi “Tên đăng nhập không được vượt quá 20 kí tự”

Mật khẩu - Nếu bỏ trống trường “Mật khẩu” thì thông báo lỗi “Mật khẩu là bắt buộc nhập”

- Nếu nhập mật khẩu ít hơn 6 kí tự thì thông báo lỗi “Mật khẩu phải có ít nhất 6 kí tự”

- Nếu mật khẩu nhập quá 20 kí tự thì thông báo lỗi “Mật khẩu không được vượt quá 20 kí tự”

- Nếu bỏ trống trường “mật khẩu nhập lại” thì thông báo lỗi “Mật khẩu là bắt buộc nhập”

- Nếu nhập“Mật khẩu nhập lại” không trùng khớp với “Mật khẩu” thì thông báo lỗi “Mật khẩu không trùng khớp”

Bảng 4: Yêu cầu kiểm tra của chức năng Thêm người dùng

3.3.3 Phân tích use case “Chỉnh sửa thông tin người dùng” a, Sơ đồ hoạt động của chức năng “Chỉnh sửa thông tin người dùng”

Hình 24: Sơ đồ hoạt động của chức năng Chỉnh sửa thông tin người dùng b, Đặc tả yêu cầu cho use case “Chỉnh sửa thông tin người dùng”

- Điều kiện tiên quyết: Tài khoản đăng nhập thành công vào hệ thống

- Mô tả khái quát: Use case này được thực hiện khi admin mong muốn chỉnh sửa thông tin người dùng

Bước 1: Người dùng thực hiện đăng nhập vào web bằng “Tên đăng nhập” và “Mật khẩu” rồi chọn nút “Đăng nhập” (Hình 12: Màn hình đăng nhập)

Bước 2: Hệ thống xác nhận và đưa người dùng vào màn hình chính Tại đây người dùng chọn nút “Quản lý dữ liệu” và chọn “Người dùng”

Bước 3: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Danh sách người dùng” , tại đây người dùng chọn biểu tượng “mắt”

Hình 25: Màn hình Chỉnh sửa thông tin người dùng (1)

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Thông tin người dùng” , tại đây người dùng chọn nút “Chỉnh sửa”

Hình 26: Màn hình chỉnh sửa thông tin người dùng (2)

Bước 5: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Chỉnh sửa người dùng” , tại đây người dùng nhập thông tin chỉnh sửa bao gồm:

Bảng 5: Phân tích usecase Chỉnh sửa thông tin người dùng

Sau đó chọn nút “Lưu”

Hình 27: Màn hình chỉnh sửa thông tin người dùng (3)

- Nếu thông tin chỉnh sửa là hợp lệ thì hệ thống sẽ hiện thông báo “Cập nhật người dùng thành công!”

- Nếu thông tin chỉnh sửa là không hợp lệ thì hệ thống sẽ thông báo lỗi:

Họ tên - Nếu để trống họ tên thì thông báo lỗi “Họ và tên là bắt buộc”

- Nếu nhập họ và tên quá 50 kí tự thì thông báo “Họ và tên vượt quá kí tự cho phép”

Email - Nếu chỉnh sửa email nhập vào không đúng format

String@domain thì , hiển thị thông báo lỗi “Email không hợp lệ”

- Nếu Email nhập vượt quá 50 kí tự thì thông báo “Email vượt quá kí tự cho phép”

Khi điền thông tin, vai trò và địa chỉ là những trường bắt buộc Nếu bạn bỏ trống vai trò, hệ thống sẽ hiển thị thông báo lỗi “Vai trò là bắt buộc” Tương tự, nếu trường “Địa chỉ” không được điền, bạn sẽ nhận được thông báo lỗi “Địa chỉ là bắt buộc”.

Mô tả - Nếu nhập quá 225 kí tự thì thông báo lỗi “Mô tả vượt quá kí tự cho phép”

Bảng 6: Yêu cầu kiểm tra của chức năng Chỉnh sửa thông tin người dùng

3.3.4 Phân tích use case “Vô hiệu hóa/kích hoạt trạng thái người dùng” a, Sơ đồ hoạt động của chức năng “Vô hiệu hóa/kích hoạt trạng thái người dùng”

Hình 28: Sơ đồ hoạt động của chức năng Vô hiệu hóa/kích hoạt trạng thái người dùng

31 b, Đặc tả yêu cầu cho use case “Vô hiệu hóa/kích hoạt trạng thái người dùng”

+ Tài khoản đã đăng nhập vào hệ thống + Người dùng phải tồn tại trong hệ thống

- Mô tả khái quát: Use case này được thực hiện khi admin mong muốn vô hiệu hóa hoặc kích hoạt một tài khoản có trong hệ thống

Bước 1: Người dùng thực hiện đăng nhập vào hệ thống bằng “Tên đăng nhập” và “Mật khẩu” rồi chọn nút “Đăng nhập” (Hình 12: Màn hình đăng nhập)

Bước 2: Hệ thống xác nhận và đưa người dùng vào màn hình chính Tại đây người dùng chọn nút “Quản lý dữ liệu” và chọn “Người dùng”

Bước 3: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Danh sách người dùng” , tại đây người dùng chọn biểu tượng “mắt”

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Thông tin người dùng”

 Tại đây người dùng chọn vào nút “Vô hiệu hóa” nếu tài khoản đang ở trạng thái hoạt động

Hình 29: Màn hình vô hiệu hóa người dùng

 Tại đây người dùng chọn vào nút “Kích hoạt” nếu tài khoản đang ở trạng thái vô hiệu hóa

Hình 30: Màn hình kích hoạt người dùng

Bước 5: Hệ thống tiếp nhận yêu cầu và hiển thị popup xác nhận:

Để vô hiệu hóa tài khoản, người dùng cần nhấn nút “Xác nhận” nếu quyết định thực hiện hành động này Nếu muốn trở lại trang Xem thông tin người dùng, hãy chọn nút “Hủy”.

Để kích hoạt tài khoản, người dùng cần nhấn vào nút “Xác nhận” Nếu không muốn tiếp tục và muốn trở lại trang Xem thông tin người dùng, hãy chọn nút “Hủy”.

Bước 6: Trường hợp người dùng nhấn nút “Xác nhận” thì hệ thống tiếp nhận và hiển thị thông báo “Cập nhật người dùng thành công!”

Phân tích use case “Quản lý dữ liệu sinh vật gây hại”

3.4.1 Sơ đồ use case tổng quát của chức năng “Quản lý dữ liệu sinh vật gây hại”

Hình 31: Usecase của chức năng Quản lý dữ liệu sinh vật gây hại

3.4.2 Phân tích use case “Thêm thông tin sinh vật gây hại” a, Sơ đồ hoạt động của “Thêm thông tin sinh vật gây hại”

Hình 32: Sơ đồ hoạt động của chức năng Thêm dữ liệu sinh vật gây hại

34 b, Đặc tả yêu cầu cho use case “Thêm sinh vật gây hại”

- Mô tả khái quát: Use case này được thực hiện khi admin muốn thêm dữ liệu sinh vật gây hại mới cho hệ thống

Bước 2: Hệ thống xác nhận và đưa người dùng vào màn hình chính Tại đây người dùng chọn nút “Quản lý dữ liệu” và chọn “Sinh vật gây hại”

Hình 33: Màn hình Thêm dữ liệu sinh vật gây hại (1)

Bước 3: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Danh sách sinh vật gây hại” , tại đây người dùng chọn nút “Thêm dữ liệu”

Hình 34 : Màn hình Thêm dữ liệu sinh vật gây hại (2)

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Thêm dữ liệu” , tại đây người dùng nhập thông tin bao gồm:

Tên sinh vật gây hại X

Tên khoa học Đặc điểm Biện pháp phòng trừ

Bảng 7: Phân tích usecase Thêm sinh vật gây hại

Hình 35 : Màn hình Thêm dữ liệu sinh vật gây hại (3)

 Nếu thông tin nhập hợp lệ thì hệ thống sẽ hiện thông báo “Lưu thành công”

 Nếu thông tin nhập không hợp lệ thì sẽ không cho phép lưu thông tin chinh

Tên sinh vật gây hại - Nếu nhập tên sinh vật gây hại trùng thì thông báo

“Tên sinh vật gây hại đã tồn tại”

- Nếu để trống tên sinh vật gây hại thì thông báo lỗi

“Tên sinh vật gây hại là bắt buộc”

- Nếu nhập tên sinh vật gây hại quá 20 kí tự thì thông báo “Tên sinh vật gây hại vượt quá kí tự cho phép”

Tên khoa học - Nếu nhập Tên khoa học quá 20 kí tự thì thông báo

“Tên khoa học vượt quá kí tự cho phép” Đặc điểm - Nếu nhập Đặc điểm quá 255 kí tự thì thông báo “Đặc điểm vượt quá kí tự cho phép”

Biện pháp phòng trừ - Nếu nhập Biện pháp phòng trừ quá 255 kí tự thì

37 thông báo “Biện pháp phòng trừ vượt quá kí tự cho phép”

Bảng 8: Yêu cầu kiểm tra của chức năng Thêm sinh vật gây hại

3.4.2 Phân tích use case “Chỉnh sửa thông tin sinh vật gây hại” a, Sơ đồ hoạt động của chức năng “Chỉnh sửa thông tin sinh vật gây hại”

Hình 36: Sơ đồ hoạt động của chức năng Chỉnh sửa thông tin sinh vật gây hại

38 b, Đặc tả yêu cầu cho use case “Chỉnh sửa thông tin sinh vật gây hại”

- Mô tả khái quát: Use case này được thực hiện khi admin mong muốn chỉnh sửa thông tin sinh vật gây hại

Bước 3: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Danh sách sinh vật gây hại” , tại đây người dùng chọn biểu tượng “mắt”

Hình 37: Màn hình chỉnh sửa thông tin sinh vật gây hại (1)

Bước 4 : Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Thông tin sinh vật gây hại” chi tiết , tại đây người dùng chọn nút “Chỉnh sửa”

Bước 5: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Chỉnh sửa sinh vật gây hại” , tại đây người dùng nhập thông tin chỉnh sửa bao gồm:

Tên sinh vật gây hại X

Tên khoa học Đặc điểm Biện pháp phòng trừ

Bảng 9: Phân tích usecase Chỉnh sửa thông tin sinh vật gây hại

Bước 6: Hệ thống kiểm tra dữ liệu nhập vào:

 Nếu thông tin chỉnh sửa là hợp lệ thì hệ thống sẽ hiện thông báo “Cập nhật thông tin thành công!”

 Nếu thông tin chỉnh sửa là không hợp lệ thì hệ thống không cho phép cập nhật

Tên sinh vật gây hại

- Nếu nhập tên sinh vật gây hại trùng thì thông báo “Tên sinh vật gây hại đã tồn tại”

- Nếu không nhập tên sinh vật gây hại thì thông báo lỗi

“Tên sinh vật gây hại là bắt buộc”

- Nếu nhập tên sinh vật gây hại quá 20 kí tự thì thông báo “Tên sinh vật gây hại vượt quá kí tự cho phép”

Tên khoa học - Nếu nhập Tên khoa học quá 20 kí tự thì thông báo

“Tên khoa học vượt quá kí tự cho phép” Đặc điểm - Nếu nhập Đặc điểm quá 255 kí tự thì thông báo “Đặc điểm vượt quá kí tự cho phép”

- Nếu nhập Biện pháp phòng trừ quá 255 kí tự thì thông báo “Biện pháp phòng trừ vượt quá kí tự cho phép”

Bảng 10: Yêu cầu kiểm tra của chức năng Chỉnh sửa thông tin sinh vật gây hại

3.4.3 Phân tích use case “Xóa thông tin sinh vật gây hại” a, Sơ đồ hoạt động của chức năng “Xóa thông tin sinh vật gây hại”

Hình 40: Sơ đồ hoạt động của chức năng Xóa thông tin sinh vật gây hại

Quản trị viên có thể thực hiện chức năng quản lý dữ liệu thành công tùy thuộc vào loại dữ liệu Hệ thống không cho phép xóa dữ liệu gốc, trong khi dữ liệu do quản trị viên thêm vào trong quá trình sử dụng có thể được xóa.

42 b, Đặc tả yêu cầu cho use case “Xóa thông tin sinh vật gây hại”

- Mô tả khái quát: Use case này được thực hiện khi admin mong muốn xóa thông tin sinh vật gây hại

➔ Trường hợp: Xóa một thông tin sinh vật gây hại bằng nút Xóa ở màn hình Xem thông tin sinh vật gây hại

Bước 3: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Danh sách sinh vật gây hại” , tại đây người dùng chọn biểu tượng “mắt”

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị màn hình “Thông tin sinh vật gây hại” chi tiết , tại đây người dùng chọn nút “Xóa”

Hình 41: Màn hình xóa thông tin sinh vật gây hại khi xem chi tiết

Bước 5: Hệ thống tiếp nhận yêu cầu và hiển thị popup thông báo “Bạn có muốn xóa thông tin này” Tại đây người dùng có hai lựa chọn

Hình 42: Pop up xác nhận xóa

Khi người dùng nhấn “Xác nhận”, hệ thống sẽ xử lý yêu cầu và xóa thông tin về dữ liệu sinh vật gây hại, kèm theo thông báo “Xóa thành công!” để xác nhận việc xóa đã hoàn tất.

 Nếu người dùng chọn “Hủy”, hệ thống tiếp nhận yêu cầu và trở về

 Trường hợp : Xóa một thông tin sinh vật gây hại bằng biểu tượng xóa (icon thùng rác)

Hệ thống sẽ nhận yêu cầu và hiển thị màn hình “Danh sách sinh vật gây hại” Tại đây, người dùng có thể chọn biểu tượng “thùng rác” bên cạnh dòng dữ liệu của sinh vật gây hại mà họ muốn xóa.

Hình 43: Màn hình xóa thông tin sinh vật gây hại bằng biểu tượng "Xóa"

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị popup thông báo “Bạn có muốn xóa thông tin này” (Hình 41) Tại đây người dùng có hai lựa chọn

Khi người dùng nhấn "Xác nhận", hệ thống sẽ tiếp nhận yêu cầu và tiến hành xóa thông tin dữ liệu về sinh vật gây hại, đồng thời hiển thị thông báo "Xóa thành công!" để xác nhận quá trình hoàn tất.

 Nếu người dùng chọn “Hủy”, hệ thống tiếp nhận yêu cầu và trở về màn hình xem thông tin sinh vật gây hại

 Trường hợp Xóa nhiều thông tin sinh vật gây hại bằng nút xóa

Bước 3: Hệ thống sẽ nhận yêu cầu và hiển thị màn hình "Danh sách sinh vật gây hại" Tại đây, người dùng cần tích chọn vào ô vuông nhỏ bên cạnh dòng dữ liệu muốn xóa, sau đó nhấn nút "Xóa" để hoàn tất quá trình.

Hình 44: Màn hình xóa nhiều sinh vật gây hại bằng nút xóa ở màn hình danh sách

Bước 4: Hệ thống tiếp nhận yêu cầu và hiển thị popup thông báo “Bạn có muốn xóa thông tin này” (Hình 41) Tại đây người dùng có hai lựa chọn

Khi người dùng nhấn “Xác nhận”, hệ thống sẽ tiếp nhận yêu cầu và tiến hành xóa thông tin dữ liệu về sinh vật gây hại, kèm theo thông báo “Xóa thành công” để xác nhận quá trình hoàn tất.

 Nếu người dùng chọn “Hủy”, hệ thống tiếp nhận yêu cầu và trở về màn hình xem thông tin sinh vật gây hại

THỰC HIỆN KIỂM THỬ

Lập kế hoạch kiểm thử

Hình 45: Kế hoạch kiểm thử

4.1.1 Viết testcase và quản lý kiểm thử

4.1.1.1 Kỹ thuật viết testcase Để xây dựng những bộ testcase đầy đủ, Tester phải áp dụng các kỹ thuật thiết kế phù hợp Đối với dự án mà nhóm em đang tham gia lần này, sử dụng những kỹ thuật viết testcase: phân tích vùng tương đương, phân tích giá trị biên

Tùy thuộc vào từng công ty và dự án, cách tạo test case có thể khác nhau Trong dự án hiện tại mà nhóm em tham gia, chúng em sử dụng một mẫu test case cụ thể.

- Name : Tên của testcase, bao gồm số thứ tự của testcase

- Steps : Quy trình từng bước để thực hiện kiểm thử

- Expected : Kết quả mong đợi của một trường hợp kiểm thử

- Results : Kết quả kiểm thử

- Status : Trạng thái của kiểm thử (Pass/Fail/Pending/Block)

- Assignee : Người thực hiện kiểm thử

- Description : Mô tả trường hợp kiểm thử

- Due date : Thời điểm thực hiện xong kiểm thử

- Test Automation/Manual : Hình thức thực hiện kiểm thử

- Test Activities : Loại kiểm thử được thực hiện

Hiện nay, có nhiều công cụ quản lý test case hiệu quả như Google Sheets, MS Excel, Spiratest và IBM Engineering Test Management Trong dự án mà nhóm tôi tham gia, chúng tôi đã chọn Google Sheets để quản lý test case Công cụ này cho phép trình bày dưới dạng bảng tính, giúp dễ dàng tùy chỉnh cách thức hiển thị test case.

Hình 46: Giao diện Google Sheet

Tên chức năng Số lượng testcase Đổi mật khẩu 13

Chỉnh sửa thông tin tài khoản 16

Chỉnh sửa thông tin người dùng 17

Vô hiệu hóa/ Kích hoạt người dùng 10

Thêm sinh vật gây hại 18

Xóa sinh vật gây hại 6

Chỉnh sửa thông tin sinh vật gây hại 15

Tài khoản để truy cập trang web:

Role Tên tài khoản Mật khẩu

Bảng 12: Dữ liệu kiểm thử

Trong giai đoạn này, Tester sẽ tiến hành kiểm thử thủ công dựa trên các kế hoạch kiểm thử đã được chuẩn bị, theo từng màn hình bao gồm:

1 Màn hình “Đổi mật khẩu” của quản trị viên

2 Màn hình “Chỉnh sửa thông tin tài khoản ” của quản trị viên

3 Màn hình “Thêm người dùng ” của quản trị viên

4 Màn hình “Chỉnh sửa thông tin người dùng ” của quản trị viên

5 Màn hình “Vô hiệu hóa/kích hoạt người dùng ” của quản trị viên

6 Màn hình “Thêm sinh vật gây hại” của quản trị viên

7 Màn hình “Xóa thông tin sinh vật gây hại ” của quản trị viên

8 Màn hình “Chỉnh sửa thông sinh vật gây hại” của quản trị viên

(Vì số lượng trang giới hạn nên phần thông tin chi tiết về các test case được nhóm trình bày ở phần phụ lục)

Kết quả kiểm thử

Sau khi tiến hành kiểm thử, kết quả có được như sau :

(Vì số lượng trang giới hạn nên phần thông tin chi tiết về kết quả kiểm thử được nhóm trình bày ở phần phụ lục)

- Thích ứng với môi trường làm việc ở công ty

- Nâng cao được khả năng tự học, đọc tài liệu bằng tiếng anh

- Cải thiện được khả năng đọc, nghe tiếng Anh

- Nắm vững được quy trình, cách thức làm việc

- Học được các kĩ năng mềm cần thiết ở môi trường làm việc

- Nắm được kiến thức về công việc kiểm thử, Manual testing và được thực hiện kiểm thử dự án thực tế

- Hoàn thiện bản thân sau kỳ thực tập và hiểu rõ hơn công việc trong tương lai

- Về đề tài còn tồn tại một số điểm hạn chế chưa được giải quyết như sau:

Dự án áp dụng phương pháp Scrum, dẫn đến việc cập nhật thường xuyên, do đó không thể nắm bắt đầy đủ và toàn bộ các logic của hệ thống.

 Thời gian thực hiện bài báo cáo còn hạn chế, nên chưa áp dụng hình thức kiểm thử tự động vào quá trình thực thi kiểm thử

 Xây dựng trường hợp kiểm thử còn hạn chế

Với kiến thức học được tại công ty, tôi sẽ nỗ lực nâng cao hiểu biết về kiểm thử, nhằm xây dựng các trường hợp kiểm thử toàn diện hơn Tôi sẽ tìm hiểu lý thuyết kiểm thử tự động và các công cụ cần thiết để áp dụng kiểm thử hiệu quả Bên cạnh đó, tôi cũng sẽ cải thiện kỹ năng tiếng Anh để dễ dàng tiếp cận tài liệu và mở ra cơ hội nghề nghiệp tốt hơn trong tương lai.

Sau khi hoàn thành 10 tuần thực tập tại TMA, tôi sẽ áp dụng kiến thức đã học và mở rộng hiểu biết về chuyên ngành kiểm thử Tôi định hướng phát triển theo hướng Test automation, nâng cao kỹ năng lập trình và phân tích Điều này sẽ giúp tôi tự tin hơn và tích lũy thêm kiến thức cho kỳ thực tập năm 4 sắp tới.

Tiêu đề	Thực Hiện Kiểm Thử Hệ Thống Quản Lý Sâu Bệnh Hại Lúa Trên Tỉnh Bình Định
Người hướng dẫn	ThS. Cao Thị Nhâm
Trường học	Trường Đại Học Kinh Tế
Chuyên ngành	Hệ Thống Thông Tin Quản Lý
Thể loại	Báo Cáo Thực Tập Nghề Nghiệp
Thành phố	Bình Định

Định dạng
Số trang	85
Dung lượng	9,23 MB