THIỆU CÔNG TY
Tổng quan về doanh nghiệp PSCD
- Địa chỉ : Tầng 3 Tòa nhà HaNoi Telecom, 121 Đặng Huy Trứ, Phường Hoà Minh, Quận Liên Chiểu, Đà Nẵng
Mô tả
Công ty TNHH PSCD, được thành lập vào tháng 11 năm 2014, có trụ sở chính tại Đà Nẵng, Việt Nam, cùng với một chi nhánh tại Thung lũng Silicon PSCD được hình thành từ Softdevelop, đánh dấu sự phát triển mạnh mẽ trong lĩnh vực công nghệ.
Đội ngũ VN đã hoạt động từ năm 2012, với hơn 7 năm kinh nghiệm, PSCD hiện có hơn 30 nhà phát triển Web và Ứng dụng Chúng tôi sử dụng nguồn lực chất lượng cao cùng công nghệ tiên tiến để cung cấp dịch vụ phát triển cho khách hàng Tính đến nay, PSCD đã hoàn thành hơn 500 dự án và có 200 khách hàng hài lòng, trong đó 40% khách hàng quay lại hợp tác.
Sứ mệnh – Triết lý công ty
Cung cấp một cơ sở hạ tầng CNTT hiện đại và mạnh mẽ là yếu tố then chốt cho sự phát triển kinh tế xã hội của đất nước, giúp đáp ứng nhu cầu về công nghệ thông tin của khách hàng mọi lúc, mọi nơi.
- Tôn vinh giá trị đích thực của nhân viên trong môi trường kinh doanh mới
- Tham gia các sáng kiến trong các hoạt động trách nhiệm xã hội
- Lấy khách hàng làm trung tâm – Cam kết về chất lượng – Đảm bảo hiệu suất
- Cách tiếp cận lấy khách hàng làm trung tâm: luôn đặt khách hàng làm cốt lõi trong chiến lược kinh doanh và phát triển
- Phương pháp cam kết chất lượng: Chất lượng là trọng tâm trong công việc và giá trị cung cấp cho khách hàng
- Phương pháp đảm bảo hiệu suất: coi năng suất là thước đo tăng trưởng, lợi thế cạnh tranh cũng như trách nhiệm của công ty đối với xã hội
Mô tả vị trí thực tập
1.4.1 Vị trí việc làm Tester
- Xem xét yêu cầu phần mềm và chuẩn bị các kịch bản kiểm thử
- Thực hiện các bài kiểm tra về khả năng sử dụng phần mềm
- Phân tích kết quả kiểm tra về tác động cơ sở dữ liệu hoặc lỗi và khả năng sử dụng
- Tham gia đánh giá phần mềm và cung cấp đầu vào theo yêu cầu, thiết kế sản phẩm và phát hiện các vấn đề tiềm ẩn
Môi trường làm việc hiện đại và phát triển nhanh chóng mang đến cơ hội tiếp cận công nghệ tiên tiến, cho phép nhân viên tham gia vào các dự án đổi mới của công ty Điều này không chỉ giúp nâng cao kiến thức chuyên môn mà còn thúc đẩy sự hoàn thiện bản thân, tạo điều kiện cho sự phát triển nghề nghiệp bền vững.
- Cơ hội thăng tiến cao nếu có kiến thức và ý chí ham học hỏi
TỔNG QUAN VỀ CƠ SỞ LÝ THUYẾT
Tổng quan về lý thuyết
2.1.1 Khái niệm về kiểm thử phần mềm
Kiểm thử phần mềm là quá trình thực thi chương trình hoặc ứng dụng nhằm phát hiện lỗi phần mềm, đồng thời xác định tính đúng đắn, đầy đủ và chất lượng của phần mềm máy tính đã phát triển.
Kiểm thử phần mềm được thực hiện theo hai hướng chính: Kiểm thử tích cực (Positive) và Kiểm thử tiêu cực (Negative) Quá trình kiểm tra này dựa trên các yêu cầu đặc tả, chức năng của hệ thống và khả năng chịu tải của dự án.
2.1.2 Tầm quan trọng của Kiểm thử phần mềm
Kiểm thử phần mềm là một bước quan trọng vì sai lầm là điều không thể tránh khỏi trong quá trình phát triển Dù một số sai lầm có thể không đáng kể, nhưng nhiều lỗi khác lại có thể gây tốn kém hoặc nguy hiểm Do đó, việc kiểm tra kỹ lưỡng mọi sản phẩm và quy trình là cần thiết, bởi vì con người luôn có khả năng mắc lỗi.
- Kiểm thử phần mềm thực sự là cần thiết để chỉ ra các khiếm khuyết và lỗi đã được thực hiện trong các giai đoạn phát triển
- Điều cần thiết là vì nó đảm bảo rằng khách hàng thấy tổ chức đáng tin cậy và sự hài lòng của họ trong ứng dụng được duy trì
Đảm bảo rằng ứng dụng không gặp phải lỗi là điều vô cùng quan trọng, vì những lỗi này có thể gây tốn kém trong tương lai hoặc trong quá trình phát triển sau này.
2.1.3 Mục tiêu của Kiểm thử phần mềm
- Đảm bảo chất lượng của sản phẩm
- Phòng ngừa và phát hiện khiếm khuyết
- Sẵn sàng tích hợp và sửa đổi thành phần
- Cung cấp thông tin để đưa ra quyết định cho giai đoạn tiếp theo
- Công việc phải được thực hiện theo quy trình xác định trước và SRS
- Xác minh và xác thực yêu cầu của người dùng
- Thảo luận về cách tạo các trường hợp thử nghiệm
- Có được sự tự tin trong công việc
- Tìm ra các khiếm khuyết từ phần mềm trước khi khách hàng phát hiện ra chúng
- Các khiếm khuyết được nhà phát triển sửa chữa
2.1.4 Bảy nguyên tắc của Kiểm thử
Trong kiểm thử phần mềm, việc nắm vững 7 nguyên tắc là rất quan trọng vì chúng giúp tiết kiệm thời gian và công sức trong việc tìm kiếm lỗi ẩn trong ứng dụng Bỏ qua bất kỳ nguyên tắc nào có thể làm giảm hiệu quả của quá trình kiểm thử hệ thống.
Hình 2.1: 7 Nguyên tắc kiểm thử
Kiểm thử phần mềm giúp phát hiện và giảm thiểu lỗi, nhưng không thể đảm bảo rằng sản phẩm hoàn toàn không còn lỗi khi đưa vào môi trường thực tế Người dùng cuối có thể gặp phải nhiều lỗi chưa được phát hiện trong quá trình kiểm thử, cho thấy rằng kiểm thử chỉ chứng minh sự hiện diện của lỗi mà không thể khẳng định sự vắng mặt của chúng.
Kiểm thử toàn bộ hệ thống là một nhiệm vụ không khả thi do sự đa dạng và phức tạp của các sản phẩm phần mềm hiện nay, được phát triển trên nhiều nền tảng và công nghệ mới Việc kết hợp các module, tính năng, đầu vào và đầu ra trong quá trình kiểm tra trở nên khó khăn Thay vì cố gắng kiểm thử toàn bộ, các nhóm phát triển nên xác định mức độ quan trọng và độ ưu tiên của các module để tập trung vào việc kiểm thử hiệu quả hơn.
Kiểm thử sớm trong phát triển phần mềm là nguyên tắc quan trọng giúp phát hiện lỗi ngay từ giai đoạn đầu, như nghiên cứu yêu cầu và thiết kế Việc phát hiện bug càng sớm sẽ giảm chi phí xử lý và nâng cao hiệu quả của quá trình phát triển Do đó, thực hiện kiểm thử ngay từ những bước đầu là cần thiết để đảm bảo chất lượng sản phẩm.
Nguyên lý phân bố lỗi chỉ ra rằng một số ít module chứa phần lớn lỗi phát hiện, thường là các thành phần chính của hệ thống, theo nguyên lý Pareto 80-20: 80% lỗi nằm trong 20% module Các QA/Tester có thể xác định các module rủi ro để tìm lỗi nhanh chóng và hiệu quả Tuy nhiên, việc lặp lại kiểm thử tương tự có thể khiến việc phát hiện lỗi mới trở nên khó khăn.
Nghịch lý thuốc trừ sâu trong nông nghiệp cho thấy rằng việc lặp lại một liều thuốc sẽ dẫn đến sâu bệnh thích nghi và trở nên “nhờn” với thuốc Tương tự, trong kiểm thử phần mềm, việc lặp đi lặp lại một test case sẽ giảm khả năng phát hiện lỗi do hệ thống đã được cải thiện và lỗi trước đó đã được sửa Để khắc phục hiệu ứng “thuốc trừ sâu” trong kiểm thử, cần thường xuyên xem xét và chỉnh sửa test case, cũng như bổ sung nhiều test case mới để phát hiện lỗi mới (regression test) Hơn nữa, QA/Testers không nên quá phụ thuộc vào các kỹ thuật kiểm thử có sẵn.
Kiểm thử phụ thuộc vào ngữ cảnh là một yếu tố quan trọng trong quy trình kiểm thử phần mềm Việc kiểm thử một trang thương mại điện tử sẽ khác biệt so với việc kiểm thử một ứng dụng đọc tin tức Do đó, cần áp dụng các phương pháp, kỹ thuật và loại kiểm thử phù hợp với từng loại phần mềm, ứng dụng hoặc website cụ thể.
Quan niệm sai lầm về việc "hết lỗi" trong phần mềm là một vấn đề phổ biến Một phần mềm có thể sạch bug tới 99% nhưng vẫn không thể sử dụng được nếu nó được kiểm thử dựa trên một yêu cầu sai Kiểm thử phần mềm không chỉ nhằm phát hiện lỗi mà còn để đảm bảo rằng phần mềm đáp ứng đúng nhu cầu của người dùng Do đó, khái niệm "không còn lỗi" hay "hết lỗi" là hoàn toàn sai lầm.
2.1.5 Vòng đời kiểm thử phần mềm
Quy trình kiểm thử phần mềm bao gồm các giai đoạn xác định rõ ràng, mặc dù không có một STLC tiêu chuẩn nào được áp dụng toàn cầu Tuy nhiên, các giai đoạn cơ bản trong quy trình kiểm thử thường bao gồm: lập kế hoạch kiểm thử, thiết kế kiểm thử, thực hiện kiểm thử, báo cáo kết quả và đánh giá.
Hình 2.2: Quy trình kiểm thử phần mềm
Giai đoạn 1: Requirement Analysis – Phân tích yêu cầu
Trong giai đoạn phân tích yêu cầu, đầu vào quan trọng 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, và yêu cầu của khách hàng về các tiêu chí chấp nhận sản phẩm Ngoài ra, bản prototype từ khách hàng (nếu có) cũng là một phần không thể thiếu trong quá trình này.
Phân tích yêu cầu là bước đầu tiên trong quy trình kiểm thử phần mềm, nơi QA team nghiên cứu và hiểu rõ các yêu cầu từ tài liệu dự án hoặc khách hàng Qua đó, đội ngũ QA nắm bắt được các yêu cầu kiểm thử chức năng và phi chức năng Trong quá trình này, nếu phát sinh câu hỏi hoặc đề xuất, QA team sẽ liên hệ với các bên liên quan như BA, PM, team leader và khách hàng để làm rõ yêu cầu sản phẩm Các câu hỏi sẽ được lưu trữ trong file Q&A, ưu tiên dạng Yes/No hoặc lựa chọn để tiết kiệm thời gian và hỗ trợ xây dựng sản phẩm hiệu quả từ đầu Cần tránh đặt câu hỏi mở rộng như "là gì", "như thế nào", hay "tại sao", vì chúng thường mất thời gian và khó giải thích, đặc biệt là với khách hàng không có kiến thức chuyên môn về phần mềm QA team sẽ đóng vai trò hỗ trợ và cung cấp giải pháp phù hợp cho khách hàng.
Các kỹ thuật kiểm thử phần mềm
2.2.1 Kiểm thử hộp đen ( Black box testing )
Kiểm thử hộp đen (Black box testing) là phương pháp kiểm thử phần mềm tập trung vào việc 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 xác định Phương pháp này còn được biết đến với tên gọi thử nghiệm dựa trên thông số kỹ thuật.
Hình 2.3: Kiểm thử hộp đen
Mục đích của việc kiểm tra phần mềm là để xác định xem nó có hoạt động đúng theo yêu cầu trong tài liệu và có đáp ứng được kỳ vọng của người dùng hay không Đối tượng kiểm tra có thể bao gồm các thành phần phần mềm như hàm chức năng, module chức năng hoặc phân hệ chức năng.
Tạo test case và Thực hiện test case
- Khi viết test case: dựa vào yêu cầu và giao diện bên ngoài của chương trình (ko can thiệp vào code)
- Khi thực hiện test: thực hiện trên giao diện của chương trình ( phải chạy được mới test được)
2.2.2 Kiểm thử hộp trắng ( White box testing )
Kiểm thử hộp màu trắng (White box testing) là một kỹ thuật kiểm tra cấu trúc bên trong phần mềm, sử dụng dữ liệu thử nghiệm từ logic và mã chương trình Phương pháp này tập trung vào việc phân tích dữ liệu đầu vào và đầu ra, cho phép các chuyên gia tester truy cập trực tiếp vào mã nguồn Ngoài tên gọi "kiểm thử hộp màu trắng", phương pháp này còn được biết đến với các tên khác như kiểm thử hộp mở, kiểm tra theo hướng logic, thử nghiệm điều khiển đường dẫn, và thử nghiệm cấu trúc.
Hình 2.4: Kiểm thử hộp trắng
Kiểm thử phần mềm không chỉ tập trung vào chức năng mà còn vào cấu trúc và thuật toán bên trong, yêu cầu tester, chủ yếu là lập trình viên, viết test case để kiểm tra tất cả các nhánh trong code Phương pháp kiểm thử đơn vị (Unit test) được áp dụng cho từng thành phần của phần mềm như chức năng, module hoặc phân hệ Tuy nhiên, đối với các phần mềm lớn, phương pháp này có thể tốn nhiều thời gian và công sức mà hiệu quả không cao, do đó không phù hợp cho kiểm thử hệ thống hay kiểm thử chấp nhận.
Tạo testcase và thực hiện test
- Khi viết test case: dựa vào yêu cầu & nội dung Source Code -> viết test code vào bên trong Source
- Khi thực hiện test: thực thi test trong code - không cần chạy chương trình (sử dụng framework hỗ trợ)
2.2.3 Kiểm thử hộp xám ( Gray box testing )
Là sự kết hợp giữa black box test và white box test -> cấu trúc bên trong sản phẩm được biết một phần
Hình 2.5: Kiểm thử hộp xám
Phương pháp này thường được áp dụng trong Kiểm thử tích hợp, nhưng tùy thuộc vào thuật toán và chức năng, nó còn có thể được sử dụng ở nhiều mức kiểm thử khác nhau.
Tạo testcase và thực hiện test
- Khi viết test case: dựa vào yêu cầu và nội dung Source Code - can thiệp vào bên trong Code
- Khi thực hiện test: trên giao diện của chương trình (chương trình phải chạy), không can thiệp vào code
Các mức test level
Hình 2.6 : Các mức test level
2.3.1 Unit Test - Kiểm thử đơn vị
Khái niệm: các đơn vị/thành phần đơn lẻ của phần mềm được kiểm tra như: Hàm (Function), Lớp (Class),
Trong quá trình phát triển ứng dụng, phương thức thực hiện là rất quan trọng Các lỗi ở cấp độ này thường được sửa chữa ngay lập tức khi phát hiện mà không cần lưu trữ hay quản lý như các cấp độ kiểm tra khác.
- Tách riêng từng phần để kiểm tra và chứng minh chúng thực hiện chính xác các yêu cầu trong đặc tả
- Lỗi được sửa sớm trong chu trình phát triển phần mềm vì vậy tiết kiệm thời gian và chi phí sửa lỗi
- Mã nguồn được tái sử dụng nhiều hơn
- Tăng sự tin tưởng trong việc thay đổi hoặc bảo trì
- Mã nguồn đáng tin cậy hơn
Sử dụng phương pháp: Kiểm thử hộp trắng
Người thực hiện: Thường là developer thực hiện
2.3.2 Integration Test - Kiểm thử tích hợp
Kiểm thử tích hợp là quá trình kiểm tra các module phần mềm hoặc chức năng riêng lẻ khi chúng được tích hợp lại với nhau Mỗi dự án phần mềm thường bao gồm nhiều module được phát triển bởi các lập trình viên khác nhau, do đó, kiểm thử tích hợp tập trung vào việc xác minh tính chính xác của việc truyền dữ liệu giữa các module này.
Mục đích của bài viết là phát hiện lỗi tương tác giữa các Unit, tập trung vào các giao diện và thông tin giữa các module Bài viết cũng nhấn mạnh việc tích hợp các Unit đơn lẻ thành những hệ thống nhỏ hơn để nâng cao hiệu quả hoạt động.
Big Bang là phương pháp kiểm thử phần mềm trong đó tất cả các thành phần được tích hợp và kiểm thử đồng thời Cách tiếp cận này được áp dụng khi nhóm kiểm thử nhận được toàn bộ phần mềm, giúp đảm bảo tính toàn vẹn và hoạt động của hệ thống trước khi triển khai.
Hình 2.7: Big bang Integration testing
Kiểm tra theo phương pháp Top Down diễn ra từ cấp cao nhất đến cấp thấp hơn, theo luồng điều khiển của hệ thống Các đơn vị cấp cao được kiểm tra trước, sau đó các cấp đơn vị thấp hơn sẽ được kiểm tra từng bước một.
Phương pháp tiếp cận Bottom Up trái ngược với Top Down, trong đó các đơn vị cấp thấp được kiểm tra trước, sau đó mới đến các cấp đơn vị cao hơn.
Phương pháp Sandwich/Hybrid kết hợp giữa hai phương pháp Top Down và Bottom Up Trong đó, các module cấp cao được kiểm tra đồng thời với các module cấp thấp, và các module cấp thấp được tích hợp với các module cấp cao để thực hiện kiểm thử.
Người thực hiện: Thường là Tester thực hiện
Ví dụ: Có 2 module Login, Tạo tài khoản cho người dùng
2.3.3 System Test - Kiểm thử hệ thống
Khái niệm: Kiểm thử hệ thống là kiểm thử toàn bộ chức năng và giao diện của hệ thống
Mục đích: Đánh giá hệ thống có đáp ứng theo đúng yêu cầu nghiệp vụ, yêu cầu về chức năng đưa ra
- Kiểm thử chức năng (Functional Test): Là kiểm thử toàn bộ hệ thống, đảm bảo hệ thống hoạt động đúng theo yêu cầu được đưa ra trước đó
Kiểm thử hiệu năng là quá trình đánh giá sự tuân thủ của hệ thống đối với các yêu cầu hiệu năng đã được chỉ định Nó giúp xác định các thuộc tính chất lượng quan trọng của hệ thống, bao gồm khả năng mở rộng và độ tin cậy.
Kiểm thử cơ sở dữ liệu là quá trình xác minh xem dữ liệu hiển thị trên hệ thống có khớp với dữ liệu trong cơ sở dữ liệu hay không.
Kiểm thử khả năng bảo mật là quá trình đánh giá hệ thống nhằm đảm bảo an toàn, ngăn chặn việc đánh cắp dữ liệu và thông tin trước các cuộc tấn công từ bên ngoài.
- Kiểm thử tính khả dụng (Usability Test): Kiểm tra tính thân thiện với người dùng và tính dễ sử dụng của hệ thống
Kiểm tra tính tương thích (Compatibility Test) là quy trình xác định xem hệ thống có tương thích với các yếu tố khác như trình duyệt, hệ điều hành và phần cứng mà nó sẽ hoạt động cùng hay không.
Kiểm tra khả năng phục hồi (Recovery Test) là quy trình đánh giá hệ thống nhằm xác định khả năng khôi phục về trạng thái ổn định sau khi gặp phải các sự cố bất thường.
Sử dụng phương pháp: Kiểm thử hộp đen là phổ biến
Người thực hiện: Thường là Tester thực hiện
2.3.4 Acceptance Test - Kiểm thử chấp nhận
Kiểm thử chấp nhận là quá trình xác minh xem phần mềm đã đáp ứng đầy đủ các yêu cầu của khách hàng hay chưa, đồng thời đánh giá xem khách hàng có chấp nhận sản phẩm cuối cùng hay không.
Mục đích: Để nghiệm thu hệ thống trước khi hệ thống được đưa vào hoạt động
Alpha test là giai đoạn kiểm thử phần mềm do các thành viên nội bộ của đơn vị phát triển thực hiện, thường là những người không trực tiếp tham gia vào dự án, như các thành viên quản lý sản phẩm Giai đoạn này diễn ra trước khi tiến hành kiểm thử Beta.
Beta test là quá trình thử nghiệm được thực hiện bởi người dùng cuối, thường là khách hàng, trong môi trường riêng của họ Trong giai đoạn này, người dùng sẽ sử dụng hệ thống để đánh giá tính năng và hiệu suất của sản phẩm.
Sử dụng phương pháp: Kiểm thử hộp đen
Người thực hiện: Khách hàng hoặc bên thứ 3
Test Case
Kịch bản kiểm thử (test case - TCs) là công cụ quan trọng giúp Tester xác định tính đúng đắn của ứng dụng, hệ thống phần mềm hoặc chức năng cụ thể Mỗi test case mô tả dữ liệu đầu vào, hành động thực hiện và kết quả mong đợi Nội dung test case có thể khác nhau tùy thuộc vào ngữ cảnh dự án và quy mô công ty, nhưng thường bao gồm mã test case, tên, mục đích, dữ liệu đầu vào, các bước thực hiện và kết quả mong đợi Test case được xây dựng dựa trên tài liệu nghiệp vụ (SRS) và có thể được thiết kế bằng Excel, Word hoặc các công cụ hỗ trợ khác Việc viết test case hiệu quả giúp đảm bảo tất cả các yêu cầu hệ thống được kiểm tra, đồng thời phát hiện lỗi sớm trong quá trình phát triển, từ đó giảm thiểu chi phí phát sinh.
2.4.2 Cấu trúc của một Test Case
Cấu trúc của một test case bao gồm:
- Mã test case (ID test case): Giá trị cần để xác định số lượng trường hợp cần để kiểm thử
- Mục đích kiểm thử (test case description): Mô tả ngắn gọn cho người kiểm tra biết họ sẽ kiểm tra chức năng gì
- Dữ liệu kiểm thử (Test Data): Dữ liệu cần chuẩn bị để thực hiện việc kiểm thử, có thể có hoặc không tùy từng quy mô dự án
Các bước thực hiện kiểm thử (Test Steps) cần được mô tả một cách ngắn gọn và rõ ràng Điều này giúp đảm bảo rằng không có sự kiện thiết yếu nào bị bỏ qua, từ đó dễ dàng tái hiện lại quy trình khi phát sinh lỗi.
- Kết quả mong muốn (Expected results): Hiển thị kết quả mong đợi từ những bước kiểm thử
- Kết quả thực tế (Test results): Hiển thị kết quả thực tế từ những bước thực hiện trên môi trường của hệ thống, thường sẽ là pass hoặc fail
2.4.3 Các kỹ thuật viết Test Case
Phân vùng tương đương là phương pháp chia nhỏ các điều kiện đầu vào thành những vùng tương đương, trong đó tất cả các giá trị trong mỗi vùng sẽ tạo ra cùng một kết quả đầu ra Nhờ đó, chúng ta có thể kiểm tra một giá trị đại diện cho toàn bộ vùng tương đương, giúp tối ưu hóa quy trình kiểm thử.
Phân tích giá trị biên là một kỹ thuật kiểm thử phần mềm, được coi là một trường hợp đặc biệt của phân vùng tương đương Kỹ thuật này giúp tester xác định các giá trị biên giữa các phân vùng tương đương và lựa chọn các test case phù hợp để kiểm tra tính chính xác của phần mềm.
Phương pháp Đoán lỗi (Error Guessing) là một kỹ thuật kiểm thử phần mềm mang tính trực giác, không tuân theo quy trình cụ thể Phương pháp này phù hợp nhất với những tester có kinh nghiệm, những người sử dụng trực giác và dữ liệu lịch sử về các lỗi đã xảy ra để phỏng đoán các lỗi tiềm ẩn Sau đó, họ sẽ viết các trường hợp kiểm thử nhằm phát hiện những lỗi đó.
Vòng đời của bug- report bug
Bug là những error, flaw, failure, hay fault tạo ra một kết quả sai, hoặc không lường đến được
Vòng đời của bug: là từ khi tìm thấy bug đến khi close bug
Hình 2.11: Vòng đời của bug
Khi log bug cần lưu ý các điểm sau:
- What: Bug này là bug gì,độ nghiêm trọng của nó như thế nào?
- Where: Xác định lỗi ở đâu,trên môi trường nào (web thì browser nào,app thì trên hệ điều hành nào)
- When: Bug xảy ra khi nào (nghĩa là thực hiện những bước nào thì xảy ra Bug)
- How: Hướng sửa Bug đó như thế nào? (expected result)
- Who: Bug do code của ai gây ra
- Project Code: Dự án hay sản phẩm xuất hiện bug
- Title: Miêu tả ngắn gọn bug
- Description: Miêu tả chi tiết bug
- Severity: Mức độ nguy hại của bug
- Status: Trạng thái hiện tại của bug
- Stage detected: Phạm vi hoạt động của dự án xác định vòng đời khi lỗi được phát hiện
- Activity: Các bước mô tả
- Process origin: Tên hay mã nguồn của đoạn phần mềm mà trong đó bug là nguồn gốc
- Creator: Người phát hiện bug
- Create date:: Ngày baó cáo bug
- Assign to: Người chịu trách nhiệm về bug
- Due date: Hạn chót cho việc hoàn thành bug
- Close date: ngày close bug
- Attached: ảnh hoặc video mô tả
- Critical: Những lỗi nghiêm trọng khiến người dùng không thể sử dụng được ứng dụng(crash, không cài được hệ thống )
Sản phẩm gặp phải vấn đề nghiêm trọng khi chức năng chính không hoạt động, ví dụ như ứng dụng game không thể thực hiện tính năng chơi game hoặc website quản lý thông tin sinh viên không hiển thị được thông tin của sinh viên.
Sản phẩm hoặc ứng dụng có thể không đáp ứng đầy đủ các tiêu chí cần thiết và vẫn tồn tại một số hành vi không mong muốn, nhưng các chức năng khác của hệ thống vẫn hoạt động bình thường.
Lỗi nhỏ thường không ảnh hưởng đến chức năng tổng thể, nhưng vẫn cần được khắc phục Ví dụ, các lỗi như sai văn bản hoặc vị trí của nút bấm cũng cần được sửa chữa để đảm bảo trải nghiệm người dùng tốt nhất.
- High: Bug phải được sửa ngay lập tức
- Medium: Bug có thể được sửa trong lần cập nhật phiên bản sau
- Low: Bug không cần sửa ngay, có thể sửa sau khi các bug High và Medium đã được sửa hết
Mối quan hệ giữa priority và severity
- High Priority – High Severity bug có độ nghiêm trọng cao- độ ưu tiên cao
- High Severity – Low Priority bug có độ nghiêm trọng cao- độ ưu tiên thấp
- High Priority – Low Severity bug có độ nghiêm trọng thấp- độ ưu tiên cao
- Low Priority – Low Severity bug bug có độ nghiêm trọng thấp - độ ưu tiên thấp
TỔNG QUAN VỀ WEBSITE VÀ TIẾN HÀNH KIỂM THỬ
Tổng quan về website PSCD user side
PSCD user side là một website được phát triển nhằm hỗ trợ doanh nghiệp trong việc quản lý hiệu quả các lĩnh vực như nhân sự và dự án Với giao diện thân thiện và các công cụ mạnh mẽ được tích hợp, PSCD user side trở thành một trợ thủ đáng tin cậy, giúp tối ưu hóa quy trình làm việc và nâng cao hiệu quả cho doanh nghiệp.
3.1.2 Tóm tắt các chức năng chính của PSCD User Side:
Quản lý user Quản lý profile user Admin có thể cung cấp thông tin như tên, địa chỉ email, vị trí công việc, và quyền truy cập tương ứng.
Quản lý quyền truy cập Admin cho phép xác định quyền truy cập cho từng tài khoản người dùng, đảm bảo rằng mỗi người chỉ có thể truy cập thông tin và chức năng cần thiết cho công việc của họ.
Admin có quyền khóa hoặc mở khóa tài khoản người dùng khi cần thiết, như khi nhân viên nghỉ việc hoặc trong các tình huống liên quan đến bảo mật.
Admin có khả năng theo dõi hoạt động của các tài khoản người dùng, đảm bảo rằng mọi hành động đều tuân thủ quy định và không xảy ra các hành vi không đáng tin cậy.
Trong một số trường hợp cần thiết, quản trị viên có quyền xóa tài khoản người dùng khỏi hệ thống Thao tác này thường được thực hiện khi người dùng không còn là thành viên của tổ chức hoặc khi tài khoản đó không còn cần thiết nữa.
Quản lý dự án cho phép Admin tạo và quản lý các dự án mới trong hệ thống Họ có thể cung cấp thông tin quan trọng như tên dự án, mô tả, ngày bắt đầu và kết thúc, cùng với các chi tiết khác cần thiết.
Admin có quyền phân quyền và quản lý nhiệm vụ trong dự án, bao gồm việc giao việc cụ thể cho các thành viên Họ có thể thiết lập nhiệm vụ, đặt thời hạn hoàn thành và theo dõi tiến độ thực hiện của từng nhiệm vụ.
Admin có khả năng xác định mức độ ưu tiên cho các dự án và nhiệm vụ, đồng thời thiết lập thời hạn cho mỗi nhiệm vụ để đảm bảo tiến độ được thực hiện đúng hạn.
Admin có thể theo dõi tiến trình dự án thông qua biểu đồ Gantt, bảng điều khiển và danh sách nhiệm vụ Việc này giúp họ nắm bắt tình hình một cách rõ ràng và thực hiện các điều chỉnh cần thiết kịp thời.
Admin có vai trò quan trọng trong việc giao tiếp và cộng tác, tham gia vào các cuộc thảo luận, chia sẻ thông tin với các thành viên trong dự án Họ có khả năng gửi thông báo, chia sẻ tài liệu và duy trì các cuộc thảo luận, đảm bảo giao tiếp hiệu quả trong nhóm.
Admin có thể tạo báo cáo chi tiết về tiến độ dự án, hiệu suất thành viên và nguồn lực sử dụng Những báo cáo này cung cấp thông tin quan trọng, hỗ trợ đưa ra quyết định thông minh và tối ưu hóa quản lý dự án.
Bảo mật quyền truy cập Admin cho phép quản lý quyền truy cập của từng thành viên trong dự án, đảm bảo rằng thông tin nhạy cảm chỉ được cung cấp cho những người thực sự cần biết.
Admin có khả năng chỉnh sửa hoặc xóa dự án khi cần thiết, đặc biệt là khi dự án đã hoàn thành hoặc không còn cần thiết nữa.
Quản lý ngân sách Admin có thể theo dõi và quản lý ngân sách cho mỗi dự án
Họ có khả năng gán nguồn lực tài chính, xác định ngân sách dự kiến và theo dõi các chi phí thực tế.
Quản lý tài liệu Admin có thể quản lý và chia sẻ tài liệu liên quan đến dự án
Họ có khả năng tạo, lưu trữ và chia sẻ tài liệu như hợp đồng, báo cáo, và tài liệu hướng dẫn.
Admin có khả năng xác thực các dự án sau khi hoàn thành, nhằm đảm bảo rằng mọi yêu cầu và tiêu chuẩn đã được đáp ứng đầy đủ.
Quản lý rủi ro là nhiệm vụ quan trọng của Admin, cho phép họ xác định và kiểm soát các rủi ro có thể ảnh hưởng đến dự án Với khả năng xây dựng kế hoạch phòng ngừa và ứng phó, Admin đảm bảo rằng dự án diễn ra một cách suôn sẻ và hiệu quả.
Giao diện và triển khai test case
Do tính chất bảo mật của dự án, dưới đây là những hình ảnh và testcase mà tôi được phép thực hiện và sử dụng trong báo cáo.
Hình 3: Giao diện Sign in
3.2.2 Thiết kế và triển khai test case
Tên chức năng Sign up
Người kiểm tra Đặng Thị Bích Giang
Người kiểm tra Đặng Thị Bích Giang
3.Chức năng của admin khi login
Tên chức năng Admin login
Người kiểm tra Đặng Thị Bích Giang
4.Chức năng của user khi login
Tên chức năng User login
Người kiểm tra Đặng Thị Bích Giang
3.2.3 Danh sách bug và hình ảnh
Link test case: https://docs.google.com/spreadsheets/d/1H0_M00D1B4xEz09QJ91f1kVA4AKIblLKvd7XaWW CEqw/edit?usp=sharing
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
1 Kết quả đạt được Thông qua hai tháng thực tập tại công ty PSCD và quá trình thực hiện báo cáo thì thu được một số kết quả như sau:
- Nắm được lý thuyết kiểm thử thủ công và kiểm thử tự động Hiểu được tầm quan trọng của việc kiểm thử
- Nắm được kỹ năng làm việc của một kiểm thử viên, các phương pháp thiết kế test cases, cách làm việc của kiểm thử viên
- Được tham gia trải nghiệm thực tế môi trường làm việc, áp dụng các kỹ năng học được vào dự án giả lập của công ty
- Áp dụng lý thuyết để thực hiện kiểm thử thủ công vào các chức năng của một hệ thống
2 Hướng phát triển Mặc dù đã được đào tạo trong môi trường thực tế của doanh nghiệp nhưng bản thân em vẫn còn nhiều thiếu sót, cần hoàn thiện hơn trong tương lai
Cải thiện kỹ năng viết test cases là rất quan trọng để áp dụng phương pháp thiết kế hiệu quả hơn Việc có cái nhìn tổng quan về hệ thống giúp phát hiện các lỗi tiềm ẩn và đảm bảo chất lượng sản phẩm.