TỔNG QUAN VỀ CÔNG TY VÀ VỊ TRÍ TESTER
Giới thiệu tổng quát về doanh nghiệp thực tập
Hình 1.1 Logo công ty TMA Solutions Bình Định
Công ty TNHH Giải pháp Phần mềm Tường Minh Bình Định (TMA Solutions Bình Định) có trụ sở tại địa chỉ 12 Đại lộ Khoa học, Khu vực 2, Phường Ghềnh Ráng, Thành phố Quy Nhơn, Bình Định Để biết thêm thông tin, bạn có thể liên hệ qua email: contact@tma-binhdinh.vn.
Website: https://www.tma-binhdinh.vn/
TMA Solutions, được thành lập vào năm 1997, đã có 25 năm phát triển vững mạnh và hiện là công ty phần mềm hàng đầu tại Việt Nam Công ty đã liên tiếp giành huy chương vàng trong lĩnh vực xuất khẩu phần mềm trong suốt 16 năm qua và nằm trong Top 10 công ty FinTech, AI và IoT.
4000 kỹ sư tài năng đang làm việc, cùng nhau xây dựng hình ảnh TMA năng động và chuyên nghiệp trên bản đồ công nghệ thông tin toàn cầu
Tháng 6 năm 2018, TMA đã mở chi nhánh tại Bình Định Sau 4 năm, TMA Bình Định đã phát triển nhanh chóng với hơn 400 kỹ sư, trong đó có nhiều kỹ sư đang làm việc tại TP.HCM đã trở về làm việc tại quê hương
Người thành lập: CEO là bà Bùi Ngọc Anh, Chủ tịch công ty là ông Nguyễn Hữu Lệ
Trụ sở chính: 111, Đường Nguyễn Đình Chính, Quận Phú Nhuận, Thành phố Hồ Chí Minh, Việt Nam
Số lượng trụ sở: 12 trụ sở
1.1.3 Tầm nhìn và sứ mệnh
TMA Solutions hướng tới việc trở thành công ty công nghệ thông tin hàng đầu toàn cầu, đồng thời đóng góp vào việc xây dựng cộng đồng thông tin phát triển bền vững Công ty cam kết mang lại giá trị tối đa cho khách hàng và tạo ra môi trường làm việc sáng tạo, cởi mở nhằm thu hút nhân tài.
Sứ mệnh của TMA Solutions là cung cấp giải pháp công nghệ thông tin hàng đầu và dịch vụ phần mềm chất lượng cao, nhằm nâng cao hiệu suất kinh doanh và tăng cường sự cạnh tranh cho khách hàng Chúng tôi cam kết mang đến sự hài lòng thông qua các sản phẩm và dịch vụ chất lượng, đáng tin cậy và đổi mới công nghệ, góp phần vào sự thành công bền vững của khách hàng.
Hình 1.2 Giá trị cốt lõi của TMA Solutions
Cung cấp các giải pháp, dịch vụ viễn thông Đào tạo sinh viên và nhân viên về kiến thức phần mềm và kỹ năng mềm
1.1.6 Một số sản phẩm tiêu biểu
Công ty TMA là một trong những công ty công nghệ 4.0 hàng đầu tại Việt Nam, chuyên cung cấp các sản phẩm đa dạng nhằm đáp ứng nhu cầu của khách hàng trong nhiều lĩnh vực khác nhau.
Hộp Camera Thông Minh – Smart Camera Box
Giải Pháp Phân Tích Cuộc Gọi – Call Analytics
Quản Lý Phòng Lab/Server Từ Xa – Lab Monitor Ứng Dụng Hỗ Trợ Tuyển Dụng Sử Dụng AI – Candidate Machining
Giải Pháp Phân Tích Người Học Online Ứng Dụng Đánh Giá Học Sinh
Phần Mềm Xác Định Người Tiếp Xúc
Hộp Khử Khuẩn Thông Minh – UV Box
Hệ Thống Hỗ Trợ Giám Sát Sức Khỏe Người Cao Tuổi – Elder Care
Giải Pháp Theo Dõi Sức Khỏe Từ Xa – mCare
Giải Pháp Tối Ưu Hoạt Động Của Thiết Bị - Machine Optimization
Dự Báo Bảo Trì Hệ Thống
Giải Pháp Đọc Tài Liệu Tự Động – Document Parser
Giải Pháp Chuyển Đổi Thiết Bị Thành Thông Minh
Tổng quan về vị trí việc làm
1.2.1 Mô tả về vị trí Tester
Vị trí Tester đóng vai trò quan trọng trong phát triển phần mềm, với nhiệm vụ chính là kiểm tra, đánh giá và đảm bảo chất lượng sản phẩm trước khi ra mắt Tester tìm kiếm lỗi, thiếu sót và các vấn đề khác trong phần mềm, sau đó báo cáo để nhóm phát triển có thể thực hiện sửa chữa kịp thời.
1.2.2 Nhiệm vụ của một Tester
Thiết kế kiểm thử là quá trình quan trọng trong kiểm thử phần mềm, trong đó tester phân tích yêu cầu và xây dựng các trường hợp cùng kịch bản kiểm thử Mục tiêu của giai đoạn này là đảm bảo rằng mọi khía cạnh của phần mềm đều được kiểm tra một cách toàn diện.
- Thực hiện kiểm thử: Tester thực hiện các trường hợp kiểm thử theo kế hoạch, bao gồm kiểm tra chức năng, hiệu suất, bảo mật
Khi phát hiện lỗi trong quá trình kiểm thử, Tester cần ghi lại chi tiết lỗi và lập báo cáo để gửi cho nhóm phát triển, nhằm hỗ trợ quá trình sửa chữa hiệu quả.
- Đảm bảo chất lượng: Tester đảm bảo rằng phần mềm đáp ứng các tiêu chí chất lượng, bao gồm độ tin cậy, khả năng sử dụng và hiệu suất
Tester hợp tác chặt chẽ với nhóm phát triển để nắm bắt yêu cầu dự án, đảm bảo các vấn đề được giải quyết kịp thời và các lỗi được khắc phục hiệu quả.
Đảm bảo tiêu chuẩn chất lượng là nhiệm vụ quan trọng của tester, người áp dụng các tiêu chuẩn và quy trình kiểm thử để thực hiện quy trình này một cách hiệu quả và đáng tin cậy.
1.2.3 Các kỹ năng cần có của một Tester
Kiến thức về kiểm thử phần mềm là rất quan trọng đối với tester, bao gồm việc hiểu rõ các phương pháp, kỹ thuật và quy trình kiểm thử Điều này bao gồm kiểm thử đơn vị, kiểm thử hệ thống, kiểm thử chấp nhận người dùng, kiểm thử hiệu suất và kiểm thử tự động, giúp đảm bảo chất lượng phần mềm hiệu quả.
Để làm việc hiệu quả trong môi trường phát triển phần mềm, Tester cần nắm vững quy trình phát triển như Waterfall, Agile, Scrum và DevOps Sự hiểu biết này không chỉ giúp Tester tương tác tốt hơn với các thành viên trong nhóm mà còn nâng cao hiệu suất công việc.
Kiến thức về ngôn ngữ lập trình như Java, Python, C# và JavaScript là rất quan trọng đối với Tester để thực hiện kiểm thử tự động hiệu quả Bên cạnh đó, việc nắm vững các công nghệ web, cơ sở dữ liệu, giao diện người dùng (UI) và ứng dụng di động sẽ mang lại lợi thế lớn trong quá trình kiểm thử.
- Kỹ sư kiểm thử phần mềm: 3-5 năm kinh nghiệm
- Leader QA: 5-6 năm kinh nghiệm
- Quản lý: 8 – 11 năm kinh nghiệm
- Quản lý cấp cao: trên 14 năm kinh nghiệm
CƠ SỞ LÝ THUYẾT
Khái niệm, nguyên tắc, quy trình kiểm thử phần mềm
2.1.1 Khái niệm về kiểm thử phần mềm
Kiểm thử phần mềm là phương pháp xác minh sự phù hợp của sản phẩm phần mềm với các yêu cầu mong đợi và đảm bảo rằng không có khiếm khuyết nào Quá trình này có thể thực hiện qua kiểm thử thủ công hoặc tự động, giúp phát hiện lỗi và các yêu cầu thiếu sót hoặc trái ngược với yêu cầu thực tế.
2.1.2 Quy trình kiểm thử phần mềm
Quy trình kiểm thử phần mềm xác định các giai đoạn trong kiểm thử phần mềm Quy trình kiểm thử bao gồm những giai đoạn sau:
1 Requirement analysis - Phân tích yêu cầu
2 Test planning - Lập kế hoạch kiểm thử
3 Test case development - Thiết kế kịch bản kiểm thử
4 Test environment set up - Thiết lập môi trường kiểm thử
5 Test execution - Thực hiện kiểm thử
6 Test cycle closure - Đóng chu trình kiểm thử
Hình 2.1 Vòng đời kiểm thử phần mềm
2.1.3 Các nguyên tắc của kiểm thử phần mềm
Kiểm thử phần mềm chỉ có khả năng phát hiện lỗi mà không thể đảm bảo rằng sản phẩm hoàn toàn không còn lỗi Điều này có nghĩa là, bất kể số lần kiểm thử, sản phẩm phần mềm vẫn có thể gặp phải lỗi.
Do đó, điều quan trọng là chúng ta tập trung thiết kế càng nhiều test case để tìm ra càng nhiều bug càng tốt
Kiểm thử toàn bộ là không khả thi, ngoại trừ trong những trường hợp nhỏ Thay vì kiểm thử từng chi tiết, chúng ta nên áp dụng phân tích rủi ro và ưu tiên để tập trung vào những điểm có nguy cơ lỗi cao nhất.
Kiểm thử phần mềm sớm trong vòng đời phát triển là nguyên tắc quan trọng giúp phát hiện lỗi nhanh chóng Bắt đầu kiểm tra từ giai đoạn đầu không chỉ tiết kiệm thời gian mà còn giảm chi phí phát triển Việc này đảm bảo chất lượng sản phẩm và tăng hiệu quả trong quy trình phát triển phần mềm.
Lỗi thường xuất hiện theo cụm, chủ yếu tập trung vào các module và thành phần chức năng chính của hệ thống Việc xác định được những khu vực này sẽ giúp người dùng tập trung vào việc tìm kiếm và khắc phục lỗi hiệu quả hơn.
Nghịch lý thuốc trừ sâu cho thấy rằng việc sử dụng lặp đi lặp lại một bộ dữ liệu test sẽ không phát hiện ra các lỗi mới Sau nhiều lần thực hiện, hiệu quả của các test case sẽ giảm sút Do đó, việc cập nhật thường xuyên các bộ dữ liệu test là cần thiết để phát hiện ra những lỗi mới.
Kiểm thử phụ thuộc vào ngữ cảnh là nguyên tắc quan trọng trong quy trình kiểm thử phần mềm Việc tiếp cận kiểm thử cần phải linh hoạt và phù hợp với từng ngữ cảnh cụ thể Nếu bạn áp dụng cùng một chiến lược kiểm thử cho cả ứng dụng web và ứng dụng di động, điều đó là không đúng Mỗi loại ứng dụng yêu cầu một chiến lược kiểm thử riêng biệt để đảm bảo hiệu quả và chất lượng sản phẩm.
Phần mềm có thể đạt đến 99% không có lỗi, nhưng vẫn có thể không sử dụng được nếu hệ thống không được xây dựng đúng theo yêu cầu của khách hàng Kiểm thử không chỉ nhằm phát hiện lỗi mà còn để đảm bảo phần mềm đáp ứng đầy đủ nhu cầu nghiệp vụ của khách hàng.
2.1.4 Xác minh (Verification) và xác nhận (Validation)
Xác minh là quá trình xác nhận tính chính xác của các chức năng cụ thể trong phần mềm Trong giai đoạn này của quy trình phát triển phần mềm, việc phát hiện và loại bỏ các lỗi là rất quan trọng nhằm đảm bảo độ tin cậy của sản phẩm.
Xác nhận sản phẩm phần mềm là quá trình đánh giá khả năng đáp ứng yêu cầu nghiệp vụ của khách hàng Quy trình này được thực hiện thông qua việc thực thi các trường hợp kiểm thử, nhằm đảm bảo rằng sản phẩm cuối cùng đáp ứng đầy đủ các tiêu chí đã đề ra.
Vòng đời phát triển phần mềm (SDLC)
SDLC, hay Vòng đời phát triển phần mềm, là quy trình nhằm phát triển phần mềm chất lượng cao với chi phí thấp và thời gian ngắn nhất Quy trình này cung cấp các giai đoạn có cấu trúc rõ ràng, giúp tăng tốc độ phát triển phần mềm sẵn sàng cho người dùng.
Hình 2.2 Vòng đời phát triển phần mềm
2.2.2 Các giai đoạn của vòng đời phát triển phần mềm
Giai đoạn 1: Requirement gathering and analysis
- Các yêu cầu được PM và Stakeholders thu thập ở giai đoạn này
- Sẽ trả lời các câu hỏi:
Ai sử dụng hệ thống?
Họ sử dụng hệ thống như thế nào?
Những dữ liệu nào được nhập vào hệ thống?
Những dữ liệu nào được xuất ra khỏi hệ thống?
- Cuối cùng, một tài liệu đặc tả yêu cầu được tạo nhằm phục vụ mục đích hướng dẫn cho giai đoạn tiếp theo của mô hình
- Trong giai đoạn này, thiết kế hệ thống và phần mềm được chuẩn bị từ các đặc tả yêu cầu đã được nghiên cứu trong giai đoạn đầu tiên
- Dựa vào câu chữ trong tài liệu vẽ ra các kiến trúc cơ bản
- Trong giai đoạn này, các design đã được thiết kế ở giai đoạn trước developer tiến hành code theo
Sau khi hoàn tất quá trình lập trình, nhóm kiểm thử sẽ tiến hành kiểm tra dựa trên các yêu cầu đã được thu thập ở giai đoạn đầu nhằm đảm bảo sản phẩm đáp ứng đúng mong đợi của khách hàng.
- Trong giai đoạn này, sẽ thực hiện kiểm thử chức năng như unit testing, integration testing, system testing, acceptance testing và các kiểm thử phi chức năng
Sau khi sản phẩm được kiểm thử thành công, nó sẽ được triển khai cho khách hàng Ngay khi nhận sản phẩm, khách hàng sẽ tiến hành kiểm thử Beta Mọi thay đổi hoặc lỗi phát hiện trong quá trình này sẽ được báo cáo cho nhóm phát triển.
Khi khách hàng bắt đầu sử dụng hệ thống đã phát triển, các vấn đề thực tế sẽ xuất hiện và cần được giải quyết theo thời gian Thời gian bảo trì thường dao động từ 1 đến 3 tháng.
2.2.3 Mô hình Agile a Mô hình Agile là gì?
Mô hình Agile là phương pháp quản lý dự án linh hoạt, tập trung vào việc chia nhỏ các dự án lớn thành những nhiệm vụ nhỏ hơn và dễ quản lý hơn Phương pháp này cho phép thực hiện các nhiệm vụ trong các chu kỳ ngắn, giúp tăng cường khả năng thích ứng và cải tiến liên tục trong quá trình phát triển dự án.
Mô hình Agile mang lại nhiều lợi ích cho các nhóm trong suốt vòng đời của dự án, bao gồm khả năng thực hiện các lần lặp ngắn, giúp đẩy nhanh tiến độ công việc và thích ứng linh hoạt với những thay đổi Agile tối ưu hóa quy trình làm việc, cho phép các nhóm chuẩn bị tốt hơn để dễ dàng thay đổi hướng khi cần thiết.
Tăng cường trải nghiệm khách hàng là một yếu tố quan trọng trong quy trình Agile Bằng cách thu hút khách hàng tham gia vào quá trình phát triển, các nhóm Agile tạo ra sự kết nối và thể hiện sự coi trọng ý kiến của họ Các bên liên quan mong muốn được tham gia xuyên suốt vòng đời dự án, giúp họ cung cấp phản hồi kịp thời và đảm bảo sản phẩm cuối cùng đáp ứng đúng nhu cầu của họ.
Cải thiện chất lượng là một trong những nguyên tắc cốt lõi của phương pháp Agile, với cách tiếp cận lặp đi lặp lại trong quản lý dự án Qua mỗi chu kỳ lặp lại, các quy trình được tối ưu hóa, giúp nâng cao chất lượng sản phẩm Sự tập trung liên tục vào cải tiến và kiểm soát chất lượng này góp phần tạo ra những sản phẩm ưu việt.
Agile là phương pháp quản lý dự án nổi bật với khả năng thích ứng linh hoạt, cho phép các nhóm dễ dàng điều chỉnh kế hoạch và ưu tiên khi có sự thay đổi, ngay cả vào phút cuối Điều này giúp đảm bảo rằng quá trình phân phối dự án không bị gián đoạn, đồng thời phù hợp với các mục tiêu cập nhật một cách hiệu quả.
Mô hình Agile nổi bật với khả năng dự đoán nhờ vào các khoảng thời gian ngắn, thường được gọi là chạy nước rút Những khoảng thời gian cố định này không chỉ giúp người quản lý dự án dễ dàng đo lường hiệu suất của nhóm mà còn hỗ trợ trong việc phân bổ nguồn lực một cách hợp lý.
Giao tiếp hiệu quả là yếu tố then chốt trong mô hình làm việc này, với ưu tiên cho các cuộc trao đổi mặt đối mặt và tương tác liên tục Đội ngũ thường tổ chức các cuộc họp hàng ngày để đảm bảo mọi thành viên đều hướng tới cùng một mục tiêu Việc duy trì liên lạc thường xuyên giúp loại bỏ những hiểu lầm tiềm ẩn, từ đó tăng cường khả năng đạt được thành công trong công việc.
2.2.4 Phương pháp Scrum a Khái niệm Scrum
Scrum là phương pháp phát triển phần mềm linh hoạt, dựa trên cơ chế lặp và tăng trưởng, nhằm hỗ trợ việc tạo ra, phân phối và cải tiến các sản phẩm phức tạp Quy trình Scrum được thực hiện qua các vòng lặp gọi là sprint, giúp tối ưu hóa quy trình phát triển.
Product Owner là người đại diện cho khách hàng hoặc người sử dụng cuối trong quá trình phát triển sản phẩm Vai trò của họ bao gồm xác định và quản lý yêu cầu sản phẩm, cũng như xây dựng và duy trì Product Backlog Họ có trách nhiệm quyết định về việc phát triển các tính năng và ưu tiên công việc cho đội ngũ Scrum.
Scrum Master là người dẫn dắt và hướng dẫn quy trình Scrum, đảm bảo thực thi đúng cách và tối ưu hóa hiệu suất của đội Scrum Vai trò của Scrum Master bao gồm việc tạo ra môi trường làm việc tích cực, hỗ trợ đội giải quyết vấn đề và loại bỏ các rào cản trong quá trình phát triển.
Nhóm phát triển là đội ngũ chịu trách nhiệm thực hiện các công việc cần thiết để sản xuất sản phẩm cuối cùng Họ tự tổ chức và quản lý công việc của mình trong suốt quá trình phát triển, đòi hỏi sự hợp tác, trách nhiệm và khả năng làm việc nhóm từ tất cả các thành viên để đạt được mục tiêu của Sprint.
Các phương pháp kiểm thử phần mềm
Kiểm thử hộp đen là phương pháp kiểm tra không yêu cầu người kiểm thử có kiến thức về mã nguồn hoặc thuật toán của chương trình Phương pháp này tập trung vào việc kiểm tra các chức năng của hệ thống, dựa trên những gì được mô tả trong các "Đặc tả yêu cầu" Các trường hợp kiểm thử thường được xây dựng xung quanh các yêu cầu này, giúp đảm bảo rằng hệ thống hoạt động đúng như mong đợi.
● Tester có thể không phải là IT chuyên nghiệp, không cần phải biết ngôn ngữ lập trình hoặc làm thế nào các phần mềm đã được thực hiện
● Không cần truy cập mã nguồn
● Phù hợp và hiệu quả khi số lượng các dòng lệnh của hệ thống là lớn
● Phân biệt rõ ràng quan điểm của người dùng với quan điểm của nhà phát triển thông qua các vai trò được xác định rõ ràng
● Kiểm thử không hiệu quả, do thực tế tester bị hạn chế kiến thức về hệ thống
● Không có độ bao phủ, vì người kiểm thử không thể kiểm tra các đoạn mã nguồn hoặc tập trung vào các đoạn mã bị lỗi
● Rất khó để thiết kế được hầu hết các trường hợp kiểm thử cho hệ thống
Trong kiểm thử hộp trắng, người kiểm thử xem xét cấu trúc mã và thuật toán của chương trình để thiết kế các trường hợp kiểm thử Họ có quyền truy cập vào mã nguồn, giúp kiểm tra và hỗ trợ quá trình kiểm thử một cách hiệu quả Ưu điểm của phương pháp này là khả năng phát hiện lỗi sâu hơn và cải thiện chất lượng phần mềm.
● Kiểm thử có thể bắt đầu ở giai đoạn sớm hơn, không cần phải chờ đợi để có thể kiểm thử
● Kiểm thử kỹ càng hơn, có thể bao phủ hầu hết các đường dẫn
● Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong code
● Cho phép tìm kiếm các lỗi ẩn bên trong
● Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối đa nhất
● Vì các bài kiểm tra rất phức tạp, đòi hỏi có các nguồn lực có tay nghề cao, với kiến thức sâu rộng về lập trình và thực hiện
Phương pháp kiểm thử này gắn liền với ứng dụng cần kiểm tra, do đó, các công cụ hỗ trợ cho mọi loại triển khai có thể không dễ dàng tìm thấy.
API là một hình thức kiểm thử phần mềm, tập trung vào việc kiểm tra trực tiếp các giao diện lập trình ứng dụng Đây là một phần quan trọng của kiểm thử tích hợp, nhằm xác định xem phần mềm có đáp ứng được các yêu cầu về chức năng, hiệu suất, độ tin cậy và bảo mật hay không.
Một request thường sử dụng 4 phương thức chính đó:
Các cấp độ kiểm thử phần mềm
Kiểm thử đơn vị là quá trình kiểm tra các thành phần phần mềm riêng lẻ trong giai đoạn phát triển ứng dụng Lỗi được phát hiện trong giai đoạn này thường được sửa chữa ngay lập tức, không cần lưu trữ hay quản lý như ở các cấp độ kiểm thử khác.
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 kết hợp lại và kiểm tra theo nhóm Mỗi dự án phần mềm thường bao gồm nhiều module do nhiều lập trình viên khác nhau thực hiện, do đó, kiểm thử tích hợp chú trọng vào việc kiểm tra sự tương tác và luồng dữ liệu giữa các module.
Phương pháp Top Down là kỹ thuật kiểm thử tích hợp từ trên xuống dưới, theo dòng điều khiển của hệ thống phần mềm Việc áp dụng phương pháp này giúp dễ dàng phát hiện lỗi trong từng module, đồng thời cho phép xác định nhanh chóng các lỗi lớn trong các module ưu tiên.
- Phương pháp Bottom Up: Là phương pháp kiểm thử tích hợp từ trên xuống dưới theo dòng điều khiển của hệ thống phần mềm Sử dụng Top Down
15 sẽ giúp việc tìm kiếm bug trong từng module dễ dàng hơn rất nhiều và có thể tìm được lỗi lớn trong các module được ưu tiên
- Phương pháp Hybrid: Là sự kết hợp của phương pháp Top Down và
Kiểm thử theo phương pháp Bottom Up bao gồm việc kiểm tra các module hàng đầu cùng với các module thấp hơn Đồng thời, các module thấp hơn cũng được tích hợp với các module hàng đầu và trải qua quá trình kiểm thử để đảm bảo tính chính xác và hiệu quả.
Kiểm thử phần mềm là quy trình đánh giá hệ thống hoặc phần mềm đã được tích hợp hoàn chỉnh, nhằm xác định xem nó có đáp ứng các yêu cầu đã được chỉ định hay không.
Phân loại: Dưới đây là một số loại kiểm thử được thực hiện trong System Testing
- Kiểm thử chức năng: 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 khách hàng
- Kiểm thử bảo mật: Là kiểm tra hệ thống không bị đánh cắp dữ liệu, thông tin trước các tấn công từ bên ngoài
- Kiểm thử khả dụng: Là kiểm tra hệ thống có thân thiện với người dùng và có dễ sử dụng không
- Kiểm thử hiệu năng: Là kiểm tra sự tuân thủ của hệ thống với các yêu cầu được chỉ định về hiệu năng
- Kiểm thử phục hồi: Là kiểm tra hệ thống có khả năng phục hồi khi gặp các sự cố bất ngờ không
Kiểm thử phần mềm là quy trình do người dùng cuối hoặc khách hàng thực hiện nhằm xác định xem phần mềm có đáp ứng đầy đủ các yêu cầu và mong đợi của người dùng hay không.
Phân loại: Trong kiểm thử chấp nhận được chia thành hai loại
- Alpha Testing: Loại kiểm thử phần mềm hoặc hệ thống được tiến hành bởi người dùng cuối nhưng thực hiện ngay tại chỗ của đội dev
Beta Testing là giai đoạn kiểm tra cuối cùng trước khi bàn giao ứng dụng Trong giai đoạn này, ứng dụng hoặc phần mềm được phát hành dưới dạng phiên bản thử nghiệm để người dùng có thể trải nghiệm và kiểm tra tại nơi làm việc của họ.
Các loại kiểm thử phần mềm
2.6.1 Kiểm thử thủ công: Manual testing
Kiểm thử thủ công là phương pháp kiểm thử phần mềm mà không sử dụng công cụ tự động Trong quy trình này, người kiểm thử sẽ đóng vai trò như người dùng cuối, thực hiện kiểm tra phần mềm nhằm phát hiện các lỗi không mong muốn.
2.6.2 Kiểm thử tự động: Automation testing
Kiểm thử tự động là kỹ thuật kiểm thử phần mềm sử dụng công cụ phần mềm đặc biệt để tự động hóa quy trình kiểm thử thủ công Phương pháp này cho phép chạy nhanh chóng và lặp đi lặp lại các kịch bản kiểm thử đã được thực hiện trước đó.
Kiểm thử tự động không chỉ được áp dụng cho kiểm thử hồi quy mà còn cho kiểm tra tải, hiệu năng và hiệu suất của ứng dụng Phương pháp này mở rộng phạm vi kiểm tra, nâng cao độ chính xác và giúp tiết kiệm thời gian cũng như chi phí so với kiểm thử thủ công.
Các kỹ thuật thiết kế kiểm thử
Phân vùng tương đương là kỹ thuật phân chia các điều kiện đầu vào thành những nhóm tương đồng, trong đó mọi giá trị đều mang lại kết quả đầu ra giống nhau 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 Phương pháp này giúp tối ưu hóa quy trình kiểm thử và tiết kiệm thời gian.
Phân vùng tương đương giúp chia nhỏ các giá trị đầu vào thành nhiều nhóm khác nhau, mỗi nhóm đại diện cho một giá trị cụ thể Nhờ đó, quy trình kiểm thử sẽ giảm thiểu số lượng test case cần thực hiện, tiết kiệm thời gian và nâng cao hiệu quả trong quá trình kiểm thử phần mềm.
Việc kiểm thử các giá trị trung gian trong vùng giá trị tương đương có thể dẫn đến việc bỏ sót các lỗi ở giá trị biên Do đó, việc kết hợp phân tích giá trị biên và phân vùng tương đương trong quá trình kiểm thử là rất quan trọng, vì nó ảnh hưởng trực tiếp đến kết quả của toàn bộ quá trình kiểm thử.
2.7.2 Phân tích giá trị biên
Phân tích giá trị biên là một phương pháp kiểm thử phần mềm quan trọng, trong đó các test case được thiết kế để kiểm tra các giá trị nằm ở các biên Khi dữ liệu đầu vào nằm trong giới hạn giá trị biên, quá trình này được gọi là Positive testing, ngược lại, nếu dữ liệu nằm ngoài giới hạn, đó là Negative testing Phương pháp này giúp phát hiện lỗi hiệu quả và đảm bảo tính chính xác của phần mềm.
- Tiết kiệm thời gian viết và thực hiện test case
- Quá trình tìm kiếm và phát hiện lỗi ở giá trị biên sẽ tối ưu và hiệu quả hơn
Phương pháp phân tích giá trị biên chú trọng vào việc kiểm thử giá trị biên và dữ liệu đầu vào, thay vì chỉ tập trung vào việc kiểm tra dữ liệu của vùng tương đương.
Từ đó giúp quá trình thực hiện test case đơn giản hơn
Kỹ thuật phân tích giá trị biên chỉ hiệu quả khi áp dụng cho các giá trị đầu vào độc lập Trong trường hợp phần mềm, khi các giá trị đầu vào chỉ bị ảnh hưởng bởi một giá trị duy nhất, việc sử dụng phân tích giá trị biên sẽ mang lại tối ưu và hiệu quả cao nhất.
2.7.3 Bảng quyết định (Decision Table)
Kiểm thử bảng quyết định là kỹ thuật kiểm thử phần mềm nhằm đánh giá hành vi của hệ thống với các kết hợp đầu vào khác nhau Phương pháp này sử dụng bảng để ghi lại các kết hợp đầu vào và hành vi hệ thống tương ứng Ưu điểm của kiểm thử bảng quyết định bao gồm khả năng phát hiện lỗi hiệu quả và giảm thiểu thời gian kiểm thử.
Hệ thống xử lý đầu vào khác nhau một cách linh hoạt, và việc sử dụng phân vùng tương đương hay phân tích giá trị biên không mang lại hiệu quả Thay vào đó, bảng quyết định có thể là công cụ hữu ích để cải thiện quy trình này.
- Việc trình bày rất đơn giản, có thể dễ dàng giải thích và được sử dụng để phát triển
- Bảng này sẽ giúp thực hiện các kết hợp hiệu quả và có thể đảm bảo phạm vi bao phủ tốt hơn để kiểm thử
- Bất kỳ điều kiện nghiệp vụ phức tạp nào cũng có thể dễ dàng khi sử dụng bảng quyết định
- Có thể bao phủ 100% khi kết hợp đầu vào thấp, kỹ thuật này có thể đảm bảo phạm vi bao phủ
- Nhược điểm chính là khi số lượng đầu vào tăng lên, bảng sẽ trở nên phức tạp hơn
2.7.4 Chuyển đổi trạng thái (State Transition)
Khi áp dụng kỹ thuật chuyển đổi trạng thái, tester cần phân tích phần mềm theo một trình tự nhất định, tương ứng với thứ tự chuyển đổi trạng thái trong sơ đồ chuyển đổi Kỹ thuật này được sử dụng để kiểm thử khả năng nhập, thoát và chuyển đổi trạng thái của phần mềm, mang lại nhiều lợi ích trong việc đảm bảo chất lượng phần mềm.
Kỹ thuật kiểm thử này cung cấp hình ảnh hoặc bảng mô tả cách thức hoạt động của hệ thống, giúp tester có cái nhìn tổng quát và hiểu rõ hơn về quy trình xử lý của hệ thống một cách hiệu quả.
- Bằng cách sử dụng kiểm thử này, tester có thể xác minh rằng tất cả các điều kiện được bao phủ và kết quả được ghi lại
- Chúng ta không thể sử dụng kỹ thuật này trong hệ thống không theo thứ tự tuần tự, kỹ thuật này không thể được sử dụng
- Chỉ phù hợp với hệ thống nhỏ, không phù hợp với hệ thống phức tạp
2.7.5 Đoán lỗi (Error guessing) Đ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, trong đó nhà phân tích kiểm thử sử dụng kinh nghiệm của mình để đoán phần có vấn đề hoặc có lỗi của ứng dụng kiểm thử Ưu điểm:
- Đã chứng minh được hiệu quả khi sử dụng kết hợp với các kỹ thuật kiểm thử phần mềm chính thức khác
Kỹ thuật này cho phép phát hiện những lỗi không được mô tả trong tài liệu đặc tả, mà các phương pháp kiểm thử chính thức có thể bỏ qua Nhờ đó, những tester có kinh nghiệm có thể tiết kiệm đáng kể thời gian và công sức trong quá trình kiểm thử.
- Rất hữu ích để đoán các vùng có vấn đề của phần mềm
- Những tester có kinh nghiệm mới có thể thực hiện kỹ thuật kiểm thử này
Đôi khi việc đoán lỗi quá lan man có thể dẫn đến việc tiêu tốn nhiều thời gian trong thiết kế test case và thực hiện kiểm thử, nhưng lại không phát hiện ra lỗi nào, từ đó không đạt được hiệu quả cao trong quá trình kiểm thử.
TRIỂN KHAI DỰ ÁN
Giới thiệu về hệ thống cần kiểm thử
Link hệ thống: https://demo.guru99.com/
Guru99 Bank là một trang web mô phỏng ngân hàng ảo, cung cấp các dịch vụ ngân hàng tiện ích cho khách hàng Người dùng có thể dễ dàng quản lý thông tin cá nhân, thực hiện giao dịch, chuyển tiền và tra cứu lịch sử giao dịch một cách nhanh chóng và hiệu quả.
- Đăng nhập, Đăng xuất, Đổi mật khẩu
- Quản lý thông tin khách hàng (New Customer, Edit Customer, Delete Customer)
- Quản lý dòng tiền (Deposit, Withdrawal, Fun Transfer, Balance Enquiry)
- Quản lý tài khoản (New Account, Edit Account, Delete Account)
Mô tả chức năng “New Customer”
3.2.1 Đặc tả màn hình “New Customer”
Hình 3.2 Đặc tả màn hình “New Customer”
3.2.2 Đặc tả chức năng “New Customer”
Tên chức năng New Customer
Mô tả Chức năng “New Customer” được sử dụng để tạo mới một khách hàng trên website Demo Guru99 Bank
Sự kiện kích hoạt cho phép Người quản lý thêm mới khách hàng, với điều kiện trước tiên là Người dùng phải đăng nhập vào hệ thống thành công Sau khi hoàn tất việc đăng nhập, điều kiện tiếp theo là Người dùng cần tạo mới khách hàng thành công trong hệ thống.
Bước 1: Người dùng đăng nhập thành công vào hệ thống
Bước 2: Người dùng chọn chức năng “New Customer” từ giao diện chính
Bước 3: Hệ thống hiển thị một biểu mẫu để người dùng nhập thông thông tin khách hàng mới bao gồm:
● Customer Name: tên khách hàng
● Date of Birth: Ngày sinh
● Mobile Number: Số điện thoại
Bước 4: Người dùng nhập thông tin các trường trên biểu mẫu và nhấn “Submit” để gửi thông tin đăng ký
Bước 5: Hệ thống kiểm tra tính hợp lệ của thông tin đăng ký và tạo khách hàng mới nếu đúng
Step 6: The notification system confirms successful customer registration with a message stating, "Customer registration successful!!!" It displays essential information including Customer ID, Customer Name, Gender, Birthdate, Address, City, State, Pin, Mobile No, and Email.
Luồng xử lý ngoại lệ:
A1: Người dùng nhấn nút “Submit”
Khi người dùng nhấn nút “Submit” mà chưa nhập thông tin hoặc nhập thiếu thông tin
1 Hệ thống hiển thị thông báo “Vui lòng nhập đầy đủ thông tin”
A2: Người dùng nhấn nút “Submit”
Khi người dùng nhấn nút “Submit” mà nhập thông tin không hợp lệ
1 Hệ thống hiển thị thông báo lỗi tương ứng và yêu cầu người dùng nhập lại
A3: Người dùng nhấn nút “Reset”
Khi người dùng nhấn nút “Reset” hệ thống sẽ hủy các thông tin đã nhập
Bảng 3.1 Đặc tả Use Case “New Customer”
Mô tả chức năng “New Account”
3.3 Mô tả chức năng “New Account”
3.3.1 Đặc tả màn hình “New Account”
Hình 3.3 Đặc tả màn hình “New Account”
3.3.2 Đặc tả chức năng “New Account”
Tên chức năng New Account
Mô tả Chức năng “New Account” được sử dụng để tạo mới một tài khoản trên website Demo Guru99 Bank
Sự kiện kích hoạt Người quản lý muốn thêm tài khoản mới cho khách hàng hiện tại Điều kiện trước Người dùng đăng nhập vào hệ thống thành công
Người dùng đã tạo khách hàng mới Điều kiện sau Người dùng tạo tài khoản mới cho khách hàng thành công
Bước 1: Người dùng đăng nhập thành công vào hệ thống
Bước 2: Người dùng chọn chức năng “New Account” trên trang web Demo Guru99
Bước 3: Hệ thống hiển thị một biểu mẫu để người dùng nhập thông tin tài khoản mới,
● Customer Id: Mã định danh duy nhất của khách hàng
● Account Type: Loại tài khoản (Savings, Current)
● Initial deposit: Số tiền ban đầu để mở tài khoản
Bước 4: Người dùng nhập thông tin vào vào trường trên biểu mẫu và nhấn “Submit” để gửi yêu cầu tạo tài khoản mới
Bước 5: Khi người dùng nhấn “Submit”, hệ thống sẽ kiểm tra tính hợp lệ của thông tin và tạo tài khoản nếu thông tin đúng
Bước 6: Hệ thống thông báo “Đã tạo tài khoản thành công!!!” và hiển thị các thông tin
Account ID, Customer ID, Customer Name, Email, Account Type, Date of Opening, Current Amount nếu thành công
Luồng xử lý ngoại lệ:
A1: Người dùng nhấn nút “Submit”
Khi người dùng nhấn nút “Submit” mà chưa nhập thông tin hoặc nhập thiếu thông tin
1 Hệ thống hiển thị thông báo “Vui lòng nhập đầy đủ thông tin”
A2: Người dùng nhấn nút “Submit”
Khi người dùng nhấn nút “Submit” mà thông tin không hợp lệ
1 Hệ thống hiển thị thông báo lỗi tương ứng và yêu cầu người dùng nhập lại
A3: Người dùng nhấn nút “Reset”
Khi người dùng nhấn nút “Reset” hệ thống sẽ hủy các thông tin đã nhập
Bảng 3.2 Đặc tả Use Case “New Account”
THỰC HIỆN KIỂM THỬ WEBSITE
Môi trường kiểm thử
Truy cập vào Google Sheet
Viết test case và thực thi kiểm thử
Truy cập trang web: https://demo.guru99.com/
Dữ liệu kiểm thử
Tài khoản để truy cập trang web bao gồm:
Bảng 4.1 Tài khoản sử dụng
Trạng thái của Test Case
Passed: Nếu test case đã được thực hiện và kết quả kiểm thử đùng như kết quả mong đợi
Failed: Nếu test case đã được thực hiện và kết quả đã kiểm thử không đúng với kết quả mong đợi
Nếu một test case cần được thực hiện nhưng không thể tiến hành do có lỗi xảy ra ở một trong các bước, nó sẽ được đánh dấu là "Blocked".
Nếu test case cần thực hiện nhưng không có sẵn trong môi trường kiểm thử, có thể do thiếu thiết bị hoặc môi trường cần thiết, dẫn đến việc không thể tiến hành kiểm thử.
Un – Test: Nếu một phần hoặc toàn bộ test case chưa được thực hiện hoặc chưa được kiểm thử
KẾT QUẢ KIỂM THỬ
Chức năng “New Customer”
Total TCs Passed Failed Blocked N/A UnTest
Bảng 5.1 Kết quả kiểm thử chức năng “New Customer”
Hình 5.1 Biểu đồ kết quả kiểm thử chức năng “New Customer”
Chức năng “New Account”
Total TCs Passed Failed Blocked N/A UnTest
Bảng 5.2 Kết quả kiểm thử chức năng “New Account”
Hình 5.2 Biểu đồ kết quả kiểm thử chức năng “New Account”
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
Trong thời gian thực tập tại TMA Solutions Bình Định, tôi đã trải nghiệm môi trường làm việc thực tế và học hỏi nhiều kiến thức quý giá nhờ sự hỗ trợ tận tình từ mentor và các anh chị trong công ty Sau 10 tuần, tôi đã đạt được những kết quả tích cực.
- Áp dụng được những kiến thức đã học vào thực tế, xây dựng các kịch bản kiểm thử phần mềm, viết test case để kiểm tra hệ thống
- Được bổ sung những kiến thức cũng như kỹ năng cần thiết tại môi trường làm việc công ty
- Nắm được cách giao tiếp trong nhóm làm việc
Tuy nhiên, trong thời gian hoàn thành báo cáo vẫn còn những hạn chế:
- Các trường hợp kiểm thử hệ thống chưa đầy đủ
- Vẫn còn những chức năng khác của hệ thống chưa được thiết kế kịch bản kiểm thử
Với đề tài này, tôi sẽ tiếp tục thiết kế kịch bản kiểm thử cho các chức năng còn lại của hệ thống Đồng thời, tôi sẽ tìm hiểu và thực hiện kiểm thử tự động cho hệ thống để nâng cao hiệu quả kiểm tra.
1 Tài liệu training của Công ty TMA Solutions Bình Định
2 https://www.testing.vn/7-nguyen-tac-kiem-thu-phan-mem/
3 https://www.tutorialspoint.com/sdlc/sdlc_overview.htm
4 https://tryqa.com/what-is-verification-in-software-testing-or-what-is- software-verification/
5 https://tryqa.com/what-is-validation-in-software-testing-or-what-is- software-validation/
6 https://daotaotester.com/api-testing-kiem-thu-api-la-gi/
7 https://www.guru99.com/levels-of-testing.html
8 https://vietnix.vn/test-case-la-gi/
9 https://vn.got-it.ai/blog/khai-quat-ve-ky-thuat-thiet-ke-test-case-trong- kiem-thu-phan-mem
CHECK LIST CỦA BÁO CÁO
STT Nội dung công việc Có Không Ghi chú
1 Báo cáo được trình bày (định dạng) đúng với yêu cầu X
2 Báo cáo có số lượng trang đáp ứng đúng yêu cầu (30-50 trang) X
Báo cáo trình bày được phần mở đầu bao gồm: Mục tiêu, Phạm vi và đối tượng, kết cấu …
Báo cáo này sẽ trình bày chi tiết về công ty và vị trí việc làm, bao gồm mô tả công việc, các kiến thức và kỹ năng cần thiết, cũng như con đường phát triển sự nghiệp Bên cạnh đó, sẽ có phần phân tích cơ sở lý thuyết liên quan đến nội dung đề tài, đảm bảo báo cáo có độ dài tối đa từ 10 đến 12 trang.
Báo cáo có sản phẩm cụ thể phù hợp với mục tiêu đặt ra của đề tài
6 Báo cáo có phần kết luận và hướng phát triển của đề tài X
Link Test Case: Test Case for Guru99 Bank
1 Test Case chức năng “New Customer”