GIỚI THIỆU VỀ CÔNG TY VÀ LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM…
Giới thiệu chung
Hình 1 1: Công ty TMA Bình Định
TMA Solutions Bình Định, được thành lập vào năm 1997, là một trong những tập đoàn công nghệ hàng đầu tại Việt Nam Với đội ngũ 4000 kỹ sư, TMA phục vụ cho các tập đoàn công nghệ cao hàng đầu thế giới từ 30 quốc gia Hiện tại, TMA có 7 chi nhánh tại Việt Nam, trong đó có 6 chi nhánh tại TP.HCM và 1 chi nhánh ở Bình Định.
Tp Quy Nhơn) cùng 6 chi nhánh ở nước ngoài (Mỹ, Úc, Canada, Đức, Nhật, Singapore)
Với 25 năm phát triển vững mạnh, TMA đã xây dựng được một đội ngũ với hơn 4,000 kỹ sư tài năng, nhiệt huyết luôn nhận được sự đánh giá cao từ phía khách hàng, cùng chung tay xây dựng hình ảnh TMA - đối tác tin cậy trên bản đồ công nghệ thông tin toàn cầu
Công viên Sáng tạo TMA, với môi trường làm việc hiện đại và tiêu chuẩn quốc tế, quy tụ hơn 4000 kỹ sư, không chỉ phục vụ cho sinh viên miền Trung mà còn thu hút nhân tài từ khắp cả nước Mối quan hệ hợp tác chiến lược với các Đại học lớn như ĐH Quy Nhơn, ĐH Tây Nguyên, ĐH Phú Yên, và ĐH Phạm Văn Đồng sẽ thúc đẩy sự phát triển công nghệ cao, khoa học kỹ thuật, giáo dục và kinh tế xã hội tại Bình Định và các tỉnh miền Trung.
Công viên Sáng tạo TMA có diện tích sử dụng hơn 15.000 m2 và bao gồm nhiều trung tâm quan trọng như Trung tâm phát triển phần mềm, Xưởng phần mềm, Trung tâm khoa học dữ liệu, Học viện công nghệ và Trung tâm nghiên cứu và chuyển giao công nghệ.
Lĩnh vực hoạt động
- Tài chính, ngân hàng và bảo hiểm
- Thương mại điện tử và phân phối
Giới thiệu về ngành nghề thực tập
Giới thiệu về tester
Tester là chuyên gia trong lĩnh vực công nghệ thông tin, có nhiệm vụ kiểm tra quy trình phát triển phần mềm nhằm đảm bảo rằng các hệ thống, chương trình và ứng dụng hoạt động đúng như mong đợi và không gặp phải rủi ro nào.
- Tester là người thử nghiệm, kiểm tra và tìm ra các lỗi phần mềm để báo lại cho nhóm phát triển sản phẩm
- Tester là người đồng hành cùng team IT cho đến khi sản phẩm đến tay khách hàng.
Kiến thức và kỹ năng cần thiết
Để thành công trong quy trình kiểm thử phần mềm, bạn cần nắm vững các giai đoạn quan trọng như yêu cầu, thiết kế, thực hiện, kiểm tra và báo cáo Việc hiểu rõ từng bước này sẽ giúp nâng cao chất lượng sản phẩm và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.
Kiến thức về kiểm thử phần mềm là rất quan trọng, bao gồm các phương pháp như kiểm thử hộp đen, kiểm thử hộp trắng, kiểm thử tích hợp và kiểm thử chấp nhận Những phương pháp này giúp đảm bảo chất lượng phần mềm và phát hiện lỗi hiệu quả.
Kiểm thử tự động là một kỹ năng thiết yếu trong ngành kiểm thử phần mềm hiện đại Để thành công, bạn cần nắm vững các kỹ thuật kiểm thử tự động, sử dụng các công cụ phổ biến và có kiến thức về ngôn ngữ lập trình để xây dựng kịch bản kiểm thử hiệu quả.
Để tạo ra các kịch bản kiểm thử hiệu quả, bạn cần có khả năng hiểu và phân tích các yêu cầu của khách hàng một cách chính xác.
Kỹ năng ghi chép và báo cáo là yếu tố then chốt trong công việc của một tester, vì việc viết và ghi lại kết quả kiểm thử một cách chi tiết và rõ ràng giúp đảm bảo sự minh bạch và hiệu quả trong quá trình kiểm tra phần mềm.
- Kỹ năng gỡ lỗi: Bạn cần có khả năng phân tích và sửa lỗi trong quá trình kiểm thử
Kỹ năng sử dụng các công cụ kiểm thử phần mềm như Selenium, Appium, JIRA và các công cụ khác là một lợi thế quan trọng Việc nắm vững kiến thức và kỹ năng này giúp nâng cao hiệu quả kiểm thử và đảm bảo chất lượng sản phẩm.
Cơ hội nghề nghiệp
Nghề tester hiện nay cung cấp nhiều vị trí phù hợp với từng năng lực khác nhau, với mức lương đa dạng cho mỗi vị trí Dưới đây là một số vị trí tester tiêu biểu.
Nhân viên Tester cấp độ đầu vào thường không cần có kinh nghiệm trước đó, và họ có thể nhận được đào tạo cũng như hướng dẫn từ những đồng nghiệp giàu kinh nghiệm trong công việc.
- Tester (Junior): Đòi hỏi từ 1 đến 3 năm kinh nghiệm làm việc trong kiểm thử phần mềm hoặc lĩnh vực liên quan
Tester (Cấp cao) yêu cầu từ 3 đến 5 năm kinh nghiệm trong lĩnh vực kiểm thử phần mềm hoặc các lĩnh vực liên quan Người đảm nhận vị trí này thường có khả năng lãnh đạo tốt và sở hữu kiến thức sâu rộng về kiểm thử phần mềm cùng các phương pháp kiểm thử hiệu quả.
Chuyên gia Tester (Expert/Senior Expert) yêu cầu ít nhất 5 năm kinh nghiệm trong lĩnh vực kiểm thử phần mềm hoặc các lĩnh vực liên quan Họ sở hữu kiến thức sâu rộng về kiểm thử phần mềm, công nghệ, quy trình và công cụ Với khả năng phát triển các phương pháp kiểm thử tiên tiến, chuyên gia tester thường đóng vai trò tư vấn cho nhóm kiểm thử, nâng cao hiệu quả và chất lượng sản phẩm.
LÝ THUYẾT VỀ KIỂM THỬ PHẦN MỀM
Giới thiệu về kiểm thử phần mềm
Kiểm thử phần mềm là quy trình xác định tính chính xác của phần mềm thông qua việc xem xét các thuộc tính như độ tin cậy, khả năng mở rộng, tính di động, khả năng tái sử dụng và khả năng sử dụng Mục tiêu của kiểm thử là đánh giá việc thực thi các thành phần phần mềm nhằm phát hiện lỗi, bugs, hoặc defects.
Đặc điểm của kiểm thử phần mềm
- Tìm lỗi: Một trong những mục tiêu chính của kiểm thử là xác định và phát hiện ra lỗi hoặc lỗi trong hệ thống phần mềm
- Đảm bảo chất lượng: Kiểm thử giúp xác minh rằng hệ thống phần mềm đáp ứng các yêu cầu và tiêu chuẩn chất lượng đã chỉ định
- Xác thực chức năng: Thử nghiệm nhằm mục đích xác thực rằng phần mềm thực hiện đúng và chính xác các chức năng dự định của nó
- Giảm thiểu rủi ro: Kiểm thử giúp xác định và giảm thiểu rủi ro tiềm ẩn liên quan đến phần mềm
2.1.3 7 nguyên tắc cơ bản của kiểm thử phần mềm
Hình 2 1: Nguyên tắc cơ bản của kiểm thử phần mềm a Kiểm thử phần mềm chứng minh sự hiện diện của lỗi
Kiểm thử phần mềm giúp giảm thiểu số lượng lỗi bằng cách áp dụng nhiều phương pháp khác nhau, nhưng khi sản phẩm được đưa vào môi trường thực tế, người dùng vẫn có thể gặp phải những lỗi chưa được phát hiện trong quá trình kiểm thử Kiểm thử chỉ có thể chứng minh rằng sản phẩm có lỗi, mà không thể khẳng định rằng sản phẩm hoàn toàn không còn lỗi Điều này cho thấy sẽ luôn tồn tại những lỗi chưa được phát hiện trong phần mềm, và việc kiểm thử toàn bộ là không khả thi.
Việc kiểm tra toàn bộ các module và tính năng trong phần mềm hiện nay gặp nhiều khó khăn do sự đa dạng và phức tạp của sản phẩm, cùng với sự phát triển của nhiều nền tảng và công nghệ mới Để nâng cao hiệu quả kiểm thử, thay vì cố gắng kiểm tra tất cả, các nhà phát triển nên xác định mức độ quan trọng và ưu tiên các module cần thiết hoặc có nguy cơ cao Hơn nữa, việc tiến hành kiểm thử càng sớm càng tốt sẽ giúp phát hiện và khắc phục lỗi kịp thời, giảm thiểu rủi ro cho sản phẩm cuối cùng.
Nguyên tắc kiểm thử sớm nhấn mạnh tầm quan trọng của việc thực hiện kiểm thử ngay từ giai đoạn đầu trong vòng đời phát triển phần mềm Việc phát hiện lỗi từ những bước đầu tiên như nghiên cứu yêu cầu và thiết kế giúp giảm thiểu chi phí sửa chữa, vì lỗi phát hiện muộn sẽ tốn kém hơn để khắc phục Do đó, thay đổi yêu cầu không chính xác ngay từ đầu sẽ tiết kiệm chi phí cho việc điều chỉnh tính năng sau này.
Nguyên lý phân bố lỗi cho thấy chỉ 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, phù hợp với nguyên lý Pareto 80-20, khi 80% lỗi xuất hiện ở 20% module Các QA/Tester có thể dựa vào kinh nghiệm để xác định các module rủi ro, từ đó tập trung tìm kiếm lỗi một cách nhanh chóng và hiệu quả Tuy nhiên, việc lặp đi lặp lại các kiểm thử tương tự có thể dẫn đến khó khăn trong việc phát hiện bug mới, tạo nên nghịch lý thuốc trừ sâu trong quy trình kiểm thử.
Trong kiểm thử phần mềm, việc lặp lại một test case sẽ giảm xác suất phát hiện lỗi do hệ thống đã được cải thiện và các lỗi trước đó đã được sửa Để khắc phục hiệu ứng "thuốc trừ sâu", cần thường xuyên xem xét và chỉnh sửa test case, đồng thời bổ sung thêm nhiều test case mới nhằm phát hiện lỗi mới trong quá trình kiểm thử hồi quy.
Kiểm thử phụ thuộc vào ngữ cảnh, có nghĩa là cách kiểm thử một trang thương mại điện tử sẽ khác với cách kiểm thử một ứng dụng đọc tin tức Mỗi phần mềm được phát triển theo những cách riêng biệt, do đó áp dụng một phương pháp kiểm thử chung cho tất cả là một sai lầm Để đạt được hiệu quả, cần phải sử dụng các phương pháp, kỹ thuật và loại hình kiểm thử khác nhau, tùy thuộc vào loại phần mềm, ứng dụng hoặc website cụ thể Một quan niệm sai lầm phổ biến là việc nghĩ rằng có thể "hết lỗi" trong quá trình kiểm thử.
Một phần mềm có tỷ lệ sạch bug lên tới 99% vẫn có thể không hoạt động hiệu quả nếu được kiểm thử dựa trên 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 để xác định xem phần mềm có đáp ứng đúng nhu cầu của người dùng hay không Do đó, quan niệm cho rằng phần mềm không còn lỗi là hoàn toàn đúng là một sai lầm.
Xác minh và xác thực
Xác minh là quá trình đánh giá các sản phẩm công việc trong một giai đoạn phát triển nhằm xác định xem chúng có đáp ứng các yêu cầu đã được chỉ định hay không.
Xác thực là quá trình quan trọng trong việc đánh giá sản phẩm phần mềm mới, nhằm đảm bảo rằng hiệu suất của nó đáp ứng đúng nhu cầu của người tiêu dùng.
QA và QC
- QA (Quality Assurance.): là người chịu trách nhiệm đảm bảo chất lượng sản phẩm thông qua việc đưa ra quy trình làm việc giữa các bên liên quan
QC (Kiểm soát chất lượng) là người đảm nhiệm việc kiểm tra chất lượng phần mềm Trong lĩnh vực này, có hai vị trí phổ biến: manual QC, không yêu cầu kỹ năng lập trình, và automation QC, yêu cầu có kiến thức lập trình.
QC là quy trình kiểm tra tỉ mỉ nhằm đảm bảo các yêu cầu chất lượng được thực hiện đúng cách Quy trình này giúp xác định và đánh giá mức độ đáp ứng các tiêu chuẩn chất lượng đã đề ra.
Mục đích của kiểm soát chất lượng là tìm và sửa lỗi
Mục tiêu của QA là loại bỏ các lỗi
QC là một kỹ thuật để đảm bảo chất lượng
Quá trình quản lý chất lượng được gọi là
QA Đó là một yêu cầu của QC để chạy phần mềm
Không cần thiết phải chạy chương trình trong QA Đối với QC, nhóm kiểm thử phụ trách QA là trách nhiệm của cả nhóm
QC minh họa: Xác nhận Minh họa QA: Xác minh
Bảng 2 1: So sánh QA và QC
Quy trình phát triển của phần mềm
Khái niệm
Vòng đời phát triển phần mềm (SDLC) là quy trình thiết yếu giúp các nhóm phát triển tiết kiệm thời gian và chi phí trong việc thiết kế và xây dựng phần mềm chất lượng cao Mục tiêu chính của SDLC là giảm thiểu rủi ro dự án bằng cách lập kế hoạch chi tiết, đảm bảo rằng phần mềm đáp ứng đầy đủ các yêu cầu và mong đợi của khách hàng trong suốt quá trình phát triển.
Quy trình
Hình 2 2: Quy trình phát triển phần mềm
Phân tích yêu cầu là giai đoạn đầu tiên trong quy trình phát triển phần mềm (SDLC), nơi các kỹ sư thu thập thông tin sơ bộ về phần mềm cần phát triển.
Sau khi hoàn thành phân tích yêu cầu, giai đoạn tiếp theo là trình bày và ghi lại các yêu cầu phần mềm một cách rõ ràng Việc này cần được thực hiện để nhận sự đồng thuận từ các bên liên quan của dự án.
- Designing: Thiết kế tổng thể, chi tiết về phần mềm muốn phát triển
Sau khi hoàn thiện thiết kế, bước tiếp theo là viết mã Các nhà phát triển cần tuân thủ các nguyên tắc mã hóa được quy định bởi các công cụ quản lý và lập trình, bao gồm trình biên dịch, trình thông dịch và trình gỡ lỗi, để đảm bảo quá trình phát triển và triển khai mã diễn ra suôn sẻ.
Sau khi mã được phát triển, quá trình kiểm tra diễn ra để đảm bảo rằng các sản phẩm đáp ứng đầy đủ các yêu cầu đã được xác định trong giai đoạn thu thập thông tin.
- Deployment: Sau khi phần mềm được chứng nhận và không có bugs hoặc error nào được nêu, thì phần mềm sẽ được triển khai
Bảo trì hệ thống là rất quan trọng khi khách hàng bắt đầu sử dụng các giải pháp đã phát triển, vì những vấn đề thực tế sẽ xuất hiện và cần được xử lý kịp thời.
Mô hình thác nước
Hình 2 3: Mô hình thác nước
• Đơn giản và dễ hiểu và dễ sử dụng
• Dễ quản lý do tính chặt chẽ của mô hình Mỗi giai đoạn có các sản phẩm cụ thể và một quy trình xem xét
• Các giai đoạn được xử lý và hoàn thành tại một thời điểm
• Hoạt động tốt cho các dự án nhỏ hơn, nơi các yêu cầu được hiểu rất rõ
• Các giai đoạn được xác định rõ ràng
• Các mốc quan trọng được hiểu rõ
• Dễ sắp xếp công việc
• Quá trình và kết quả được ghi chép đầy đủ
• Không có phần mềm làm việc được sản xuất cho đến cuối vòng đời
• Số lượng rủi ro và sự không chắc chắn cao
• Không phải là một mô hình tốt cho các dự án phức tạp và hướng đối tượng
• Mô hình kém cho các dự án dài và đang diễn ra
Mô hình quy trình này không thích hợp cho các dự án có yêu cầu có nguy cơ thay đổi từ trung bình đến cao, dẫn đến rủi ro và sự không chắc chắn cao.
• Rất khó để đo lường sự tiến bộ trong các giai đoạn
• Không thể đáp ứng yêu cầu thay đổi
• Việc điều chỉnh phạm vi trong vòng đời có thể kết thúc một dự án
Mô hình chữ V
• Các phương pháp kiểm thử như lập kế hoạch, thiết kế kiểm thử diễn ra tốt trước khi viết mã
• Điều này tiết kiệm rất nhiều thời gian Do đó, cơ hội thành công cao hơn so với mô hình thác nước
• Tránh dòng chảy đi xuống của các khuyết tật
• Hoạt động tốt cho các kế hoạch nhỏ nơi các yêu cầu được hiểu dễ dàng
• Rất cứng nhắc và ít linh hoạt nhất
• Không tốt cho một dự án phức tạp
• Phần mềm được phát triển trong giai đoạn triển khai, vì vậy không có nguyên mẫu ban đầu nào của phần mềm được tạo ra
• Nếu có bất kỳ thay đổi nào xảy ra giữa chừng, thì các tài liệu kiểm tra cùng với các tài liệu cần thiết phải được cập nhật.
Mô hình Agile
• Giao tiếp trực tiếp với khách hàng
• Thiết kế hiệu quả và đáp ứng yêu cầu kinh doanh
• Bất cứ lúc nào thay đổi được chấp nhận
• Nó làm giảm tổng thời gian phát triển
• Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết
Quy mô nhân lực thường chỉ từ 7 đến 10 người, và nếu số lượng yêu cầu vượt quá giới hạn này, sẽ gặp phải những trở ngại lớn, đặc biệt trong các cuộc họp trao đổi thông tin.
• Số lượng yêu cầu có thể nhiều và khó quản lý nếu như nó bao gồm nhiều khía cạnh khác nhau về dự án
Khi số lượng nhân lực gia tăng, việc kiểm soát chất lượng trở nên khó khăn hơn Để khắc phục nhược điểm này, việc kiểm tra mã thường xuyên và thiết lập các chỉ tiêu đánh giá năng lực cho lập trình viên là rất cần thiết.
Phương pháp Scrum
Scrum là một phương pháp Agile phổ biến trong phát triển sản phẩm, đặc biệt là phần mềm Nó cung cấp một khung quản lý dự án linh hoạt, phù hợp cho cả những dự án đơn giản với nhóm nhỏ lẫn những dự án phức tạp có hàng trăm người tham gia, bao gồm cả các dự án yêu cầu khung thời gian cố định.
Phương pháp Kanban
Phương pháp Kanban là một công cụ quản lý linh hoạt, giúp cải tiến liên tục và tối ưu hóa quy trình làm việc Phương pháp này cho phép dễ dàng theo dõi tiến độ của toàn bộ dự án chỉ trong chốc lát, mang lại sự minh bạch và hiệu quả trong quản lý công việc.
Phân loại kiểm thử phần mềm
Kiểm thử thủ công
Kiểm thử thủ công là quy trình kiểm thử phần mềm thực hiện các trường hợp kiểm thử mà không cần sử dụng công cụ tự động Tất cả các trường hợp thử nghiệm đều do người thử nghiệm thực hiện một cách thủ công, từ góc nhìn của người dùng cuối.
Kiểm thử tự động
Kiểm thử tự động là một kỹ thuật trong lĩnh vực kiểm thử phần mềm, trong đó người kiểm thử tự tạo ra các tập lệnh và sử dụng phần mềm chuyên dụng để tiến hành kiểm tra Phương pháp này giúp tăng hiệu quả và độ chính xác trong quá trình kiểm thử, đồng thời tiết kiệm thời gian và công sức so với kiểm thử thủ công.
Phương pháp kiểm thử phần mềm
Kiểm thử tĩnh – Static testing
Kiểm tra tĩnh là quy trình xác minh ứng dụng mà không cần triển khai mã, giúp tiết kiệm chi phí hiệu quả.
Kiểm thử động – Dynamic testing
Kiểm thử nghiệm động là quá trình thực thi mã ứng dụng để kiểm tra hành vi chức năng của hệ thống phần mềm Nó đánh giá việc sử dụng bộ nhớ, CPU và hiệu suất tổng thể của hệ thống Mục tiêu chính của kiểm thử động là xác nhận rằng sản phẩm phần mềm hoạt động đúng theo các yêu cầu đã đề ra.
Các phương pháp kiểm thử
Kiểm thử hộp đen là một phương pháp kiểm thử phần mềm tập trung vào việc đánh giá chức năng mà không cần xem xét cấu trúc nội bộ hay mã nguồn Kỹ thuật này chủ yếu dựa vào các yêu cầu được khách hàng cung cấp trong đặc điểm kỹ thuật.
Kiểm thử hộp trắng là một phương pháp kiểm thử phần mềm quan trọng, giúp đánh giá các thuật toán và cấu trúc mã nguồn bên trong sản phẩm Phương pháp này cho phép người kiểm thử nhìn xuyên qua lớp vỏ bên ngoài của phần mềm, từ đó hiểu rõ hơn về hoạt động nội tại của nó.
Greybox testing là phương pháp kiểm thử phần mềm kết hợp giữa kiểm thử hộp đen và hộp trắng, cho phép kiểm tra ứng dụng với một phần kiến thức về cấu trúc bên trong Phương pháp này sử dụng truy cập mã nguồn để thiết kế các trường hợp kiểm thử, đồng thời thực hiện kiểm thử ở cấp độ chức năng giống như kiểm thử hộp đen.
Cấp độ kiểm thử phần mềm
Kiểm thử đơn vị
Kiểm thử đơn vị là quy trình phát triển phần mềm, trong đó các phần nhỏ nhất của ứng dụng, gọi là đơn vị, được kiểm tra riêng lẻ để đảm bảo hoạt động đúng Các nhà phát triển phần mềm và nhân viên QA thực hiện kiểm thử đơn vị trong quá trình phát triển Mục tiêu chính của kiểm thử đơn vị là cô lập mã đã viết để xác định xem nó có hoạt động như mong đợi hay không.
Kiểm tra tích hợp
Kiểm thử tích hợp (Integration Test) được thực hiện sau khi hoàn thành kiểm thử đơn vị (Unit Test) Trong quá trình này, các mô đun phần mềm riêng lẻ sẽ được tích hợp và kiểm tra theo từng nhóm, vì một 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 Mục tiêu chính của kiểm thử tích hợp là phát hiện các lỗi trong sự tương tác giữa các module khi chúng được kết hợp, nhằm đảm bảo tính nhất quán và hiệu suất của phần mềm.
Kiểm thử hệ thống
Kiểm thử hệ thống là phương pháp đánh giá sản phẩm hoặc hệ thống phần mềm đã được tích hợp, dựa trên các yêu cầu chức năng đã xác định Mục tiêu của kiểm thử này là xác định xem hệ thống có hoạt động đúng theo yêu cầu và mục đích đã đề ra hay không Kiểm thử hệ thống thường được thực hiện theo phương pháp hộp đen, không yêu cầu kiến thức nội bộ về mã nguồn, lập trình hay thiết kế.
Kiểm thử chấp nhận
Kiểm thử chấp nhận là quá trình kiểm tra chính thức dựa trên yêu cầu của người dùng và chức năng của phần mềm Mục tiêu của kiểm thử này là xác định xem phần mềm có đáp ứng các yêu cầu đã được chỉ định và mong đợi của người dùng hay không Hình thức kiểm thử này thường được thực hiện như một thử nghiệm Hộp đen, trong đó có sự tham gia của một nhóm người dùng để đánh giá mức độ chấp nhận của hệ thống Đây là cấp độ thứ tư và cũng là cấp độ cuối cùng trong quy trình kiểm thử phần mềm.
Kỹ thuật thiết kế Testcase
Kỹ thuật thiết kế dựa trên đặc điểm kỹ thuật
Kỹ thuật kiểm tra dựa trên đặc điểm kỹ thuật, còn được gọi là kiểm tra hành vi và kiểm tra hộp đen, là phương pháp mà người kiểm tra xem phần mềm như một hộp đen Trong kỹ thuật này, người kiểm thử không cần biết cấu trúc bên trong của hệ thống hay các thành phần, mà chỉ tập trung vào chức năng và hiệu suất của phần mềm mà không quan tâm đến cách thức thực hiện.
- Các kỹ thuật bao gồm:
• Phân tích giá trị biên (BVA)
• Phân vùng tương đương (EP)
• Kiểm tra Bảng Quyết định
• Sơ đồ chuyển đổi trạng thái
• Kiểm tra trường hợp sử dụng
Phân vùng tương đương là một kỹ thuật quan trọng trong việc chia đầu vào thành các nhóm tương đương Kỹ thuật này cho rằng nếu một giá trị trong nhóm hoạt động chính xác, thì tất cả các giá trị khác trong nhóm đó cũng sẽ hoạt động đúng, và ngược lại.
Thiết kế Test-case bằng phương pháp phân vùng tương đương bao gồm hai bước chính: xác định các lớp tương đương và xác định các ca kiểm thử Khi áp dụng kỹ thuật phân vùng tương đương, đầu vào sẽ được chia thành các nhóm dựa trên nguyên tắc cụ thể.
- 1 lớp các giá trị lớn hơn
- 1 lớp các giá trị nhỏ hơn
- 1 lớp các giá trị hợp lệ
Hình 2 8: Phân vùng tương đương
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 tra tập trung vào các giá trị ở ranh giới của dữ liệu đầu vào và đầu ra Thay vì kiểm tra toàn bộ dữ liệu, các tester chỉ chú trọng vào các giá trị biên để đảm bảo tính chính xác và hiệu quả của hệ thống.
Do đó, thay vì phải kiểm thử toàn bộ dữ liệu vào và ra, ta có thể test từ 4 - 6 case mà vẫn đảm bảo hệ thống hoạt động tốt
Điều kiện biên là các vị trí nằm ở giữa, trên và dưới các biên của lớp tương đương Khi áp dụng kỹ thuật phân tích giá trị biên, người kiểm thử sẽ lựa chọn các giá trị phù hợp.
- Giá trị ngay dưới giá trị nhỏ nhất
- Giá trị ngay trên giá trị lớn nhất
Hình 2 9: Phân tích giá trị biên
Kiểm tra bảng quyết định
Là dùng bảng để hiển thị danh sách các thao tác phần mềm được quyết định trên các điều kiện khác nhau
Hình 2 10: Kiểm tra bảng quyết định
Chức năng đăng nhập Gmail yêu cầu người dùng nhập cả tên đăng nhập và mật khẩu Để đăng nhập thành công, thông tin phải chính xác; nếu không, hệ thống sẽ thông báo lỗi và yêu cầu người dùng nhập lại.
Sơ đồ chuyển đổi trạng thái
Biểu đồ chuyển đổi trạng thái thể hiện tất cả các trạng thái của một đối tượng, các sự kiện dẫn đến sự thay đổi trạng thái, điều kiện cần thiết trước khi quá trình chuyển đổi diễn ra, và các hoạt động diễn ra trong suốt vòng đời của đối tượng.
Nhược điểm: Nếu không xử lý theo tuần tự sẽ không hiểu được
Hình 2 11: Sơ đồ chuyển đổi trạng thái
Trong hệ thống này, người dùng sẽ đăng nhập thành công nếu nhập mật khẩu hợp lệ trong 4 lần thử đầu tiên Nếu nhập sai mật khẩu 3 lần, người dùng sẽ được yêu cầu nhập lại Tuy nhiên, nếu sai ở lần thử thứ 4, hệ thống sẽ bị khóa.
Kiểm tra trường hợp sử dụng
Kiểm thử ca sử dụng là một kỹ thuật kiểm thử phần mềm quan trọng, giúp xác định các trường hợp kiểm thử bao gồm toàn bộ hệ thống trong một giao dịch từ đầu đến cuối Những trường hợp kiểm thử này thể hiện sự tương tác giữa người dùng và ứng dụng phần mềm Phương pháp này không chỉ giúp phát hiện các lỗ hổng trong ứng dụng mà còn bổ sung thông tin cho các kiểm tra thành phần phần mềm riêng lẻ, từ đó nâng cao chất lượng và độ tin cậy của sản phẩm.
Kỹ thuật dựa trên kinh nghiệm
Phương pháp kiểm thử này không có quy trình cụ thể, vì nó chủ yếu dựa vào trực giác và kinh nghiệm của các Tester Những Tester có kinh nghiệm sẽ được cung cấp một chương trình và họ sẽ phỏng đoán các lỗi dựa trên trực giác, kinh nghiệm và dữ liệu lịch sử về các lỗi đã xảy ra trước đó Sau đó, họ sẽ viết các ca kiểm thử nhằm phát hiện những lỗi này.
Exploratory Testing: Thử nghiệm thăm dò
Kiểm thử thăm dò là một phương pháp kiểm thử phần mềm trong đó người kiểm thử không tạo trước các trường hợp kiểm thử mà thực hiện kiểm tra một cách nhanh chóng và linh hoạt Họ có thể ghi chú lại những ý tưởng cần kiểm tra trước khi tiến hành Phương pháp này tập trung vào việc kiểm tra như một hoạt động tư duy, dựa vào tài liệu yêu cầu của hệ thống và khám phá trong suốt quá trình kiểm thử Kiểm thử thăm dò khác biệt so với các loại kiểm thử có kịch bản khác bởi yêu cầu khả năng tư duy, khả năng đào sâu và khám phá cao hơn.
Vòng đời
- Ngay khi kỹ sư kiểm tra tìm thấy lỗi, trạng thái sẽ được đưa ra là Mới, điều này cho biết rằng lỗi vừa được tìm thấy
Lỗi mới này cần được thông báo cho Nhà phát triển liên quan bằng cách thay đổi trạng thái thành "Đã được chỉ định" để người phụ trách có thể xử lý lỗi hiệu quả.
Nhà phát triển sẽ xem xét các lỗi bằng cách đọc kỹ tất cả các bước điều hướng để xác định tính hợp lệ của lỗi đó.
Nếu bug được xác nhận là hợp lệ, nhà phát triển sẽ tiến hành sao chép lỗi trên ứng dụng Sau khi sao chép thành công, họ sẽ phân tích mã nguồn và thực hiện các thay đổi cần thiết, đồng thời cập nhật trạng thái lỗi thành "Đã sửa lỗi".
Khi các thay đổi mã được thực hiện và lỗi đã được sửa, kỹ sư kiểm tra sẽ tiến hành kiểm tra lại lỗi, tức là họ sẽ thực hiện lại các hành động tương tự như đã nêu trong báo cáo lỗi và cập nhật trạng thái tương ứng.
Quá trình sửa lỗi diễn ra liên tục: nếu lỗi được khắc phục đúng cách và chức năng hoạt động như yêu cầu, lỗi sẽ được đóng lại Ngược lại, nếu lỗi vẫn tồn tại hoặc không hoạt động đúng, nó sẽ được gửi lại cho Nhà phát triển để sửa chữa.
Mức độ nghiêm trọng và mức độ ưu tiên
Mức độ ưu tiên (Priority) được định nghĩa là thứ tự lỗi cần sửa Lỗi ưu tiên càng cao thì càng cần giải quyết sớm
Các lỗi khiến hệ thống phần mềm không sử dụng được ưu tiên cao hơn các lỗi khiến một chức năng nhỏ của phần mềm bị lỗi
Mức độ ưu tiên của lỗi có thể được phân thành 3 cấp độ:
Lỗi ở mức độ thấp là một vấn đề gây khó chịu, nhưng việc khắc phục chúng có thể được thực hiện sau khi các lỗi nghiêm trọng hơn đã được giải quyết.
Trong quá trình phát triển sản phẩm, các lỗi ở mức độ trung bình cần được giải quyết kịp thời Mặc dù có thể chờ đến khi phiên bản mới được phát hành, nhưng việc xử lý chúng trong quá trình phát triển là rất quan trọng để đảm bảo chất lượng sản phẩm cuối cùng.
Lỗi ở mức độ ưu tiên cao cần được khắc phục ngay lập tức vì nó gây ảnh hưởng nghiêm trọng đến hệ thống, dẫn đến việc không thể sử dụng cho đến khi vấn đề được giải quyết.
TÌM HIỂU VỀ API VÀ ỨNG DỤNG CÔNG CỤ POSTMAN 22 Tìm hiểu API
API là gì?
API, hay Giao diện lập trình ứng dụng (Application Programming Interface), là các phương thức và giao thức kết nối giữa các thư viện và ứng dụng khác nhau Nó cho phép truy cập vào một tập hợp các hàm thường dùng, từ đó tạo điều kiện cho việc trao đổi dữ liệu giữa các ứng dụng một cách hiệu quả.
API hoạt động như thế nào?
Hình 3 1: Quy trình hoạt động của API
Ví dụ về API làm gì?
Khi bạn sử dụng ứng dụng di động, ứng dụng sẽ kết nối Internet và gửi dữ liệu đến máy chủ Máy chủ nhận dữ liệu, xử lý và thực hiện các hành động cần thiết trước khi gửi lại thông tin cho điện thoại của bạn Cuối cùng, ứng dụng sẽ giải thích và trình bày dữ liệu đó một cách dễ đọc Đây chính là chức năng của một API.
Cấu trúc của API
API được xây dựng trên chính 2 thành phần: Request và Reponse
Một cái request đúng chuẩn cần có 4 thứ:
URL là địa chỉ duy nhất cho 1 request, thường là đường dẫn tới một hàm xử lí logic
HTTP request có tất cả 9 loại method, 2 loại được sử dụng phổ biến nhất là GET và POST
- GET: Sử dụng để lấy thông tin từ server theo URI đã cung cấp
- HEAD: Giống với GET nhưng response trả về không có body, chỉ có header
- POST: Gửi thông tin tới sever thông qua các parameters HTTP
- PUT: Ghi đè tất cả thông tin của đối tượng với những gì được gửi lên
- PATCH: Ghi đè các thông tin được thay đổi của đối tượng
- DELETE: Xóa resource trên server
- CONNECT: Thiết lập một kết nối tới server theo URI
- OPTIONS: Mô tả các tùy chọn giao tiếp cho resource
- TRACE: Thực hiện một bài test loop-back theo đường dẫn đến resource
Request chứa thông tin quan trọng mà người dùng cuối không nhận biết, bao gồm độ dài của request body, thời gian gửi request, loại thiết bị sử dụng và định dạng phản hồi mà client có thể đọc Tất cả thông tin này được tổ chức dưới dạng cặp khóa key - value.
Là nơi chứa thông tin mà client sẽ điền Thông tin này dưới dạng data
Sau khi nhận yêu cầu từ phía khách hàng, máy chủ sẽ xử lý yêu cầu đó và gửi lại cho khách hàng một phản hồi Cấu trúc của phản hồi tương đối giống với yêu cầu, nhưng mã trạng thái sẽ thay thế cho URL và phương thức Tóm lại, phản hồi có cấu trúc gồm ba phần chính.
Status code (Mã hóa trạng thái thường được gọi là mã trạng thái) là một số nguyên
3 ký tự, trong đó ký tự đầu tiên của Status-Code định nghĩa loại Response và hai ký tự cuối không có bất cứ vai trò phân loại nào
• 1xx: Information (Thông tin): Khi nhận được những mã như vậy tức là request đã được server tiếp nhận và quá trình xử lý request đang được tiếp tục
• 2xx: Success (Thành công): Khi nhận được những mã như vậy tức là request đã được server tiếp nhận, hiểu và xử lý thành công
• 3xx: Redirection (Chuyển hướng): Mã trạng thái này cho biết client cần có thêm action để hoàn thành request
• 4xx: Client Error (Lỗi Client): Nó nghĩa là request chứa cú pháp không chính xác hoặc không được thực hiện
• 5xx: Server Error (Lỗi Server): Nó nghĩa là Server thất bại với việc thực hiện một request nhìn như có vẻ khả thi
Phần Header và body tương đối giống với request.
Soap và Rest API
SOAP là một giao thức nhắn tin cho phép các chương trình hoạt động trên nhiều hệ điều hành khác nhau, như Linux và Windows, có thể giao tiếp với nhau thông qua Ngôn ngữ XML và Giao thức HTTP.
REST là một kiến trúc API sử dụng phương thức HTTP đơn giản để giao tiếp giữa các máy Nó dựa trên các thao tác CRUD (Create, Read, Update, Delete), tương ứng với các giao thức HTTP như POST, GET, PUT và DELETE.
JSON và XML
JSON, viết tắt của JavaScript Object Notation, là một định dạng dữ liệu văn bản phổ biến dùng để lưu trữ và trao đổi thông tin giữa các hệ thống Nó cho phép lưu trữ và chia sẻ dữ liệu một cách hiệu quả, với khả năng thể hiện cấu trúc dữ liệu thông qua đối tượng và mảng.
XML, hay còn gọi là eXtensible Markup Language, là ngôn ngữ đánh dấu có khả năng mở rộng, chủ yếu được sử dụng để trao đổi thông tin giữa các hệ thống, tương tự như CSV và JSON.
Postman là gì?
Postman là công cụ phổ biến cho phép người dùng thao tác với API, đặc biệt là REST, mà không cần viết mã Nó hỗ trợ tất cả các phương thức HTTP như POST, PUT, DELETE, PATCH và GET Đặc biệt, Postman cho phép lập trình viên lưu lại lịch sử các yêu cầu, giúp việc sử dụng lại trở nên tiện lợi hơn.
Tại sao phải sử dụng Postman
Với hơn 4 triệu người dử dụng bây giờ, Postman trở thành công cụ được lựa chọn vì những lý do sau:
Để sử dụng Postman, bạn chỉ cần đăng nhập vào tài khoản của mình, giúp dễ dàng truy cập các tệp mọi lúc, mọi nơi, miễn là ứng dụng Postman đã được cài đặt trên máy tính.
Postman cho phép người dùng tạo các bộ sưu tập (collections) cho các lệnh API, giúp tổ chức và quản lý các yêu cầu một cách hiệu quả Mỗi bộ sưu tập có thể chứa nhiều thư mục con và nhiều yêu cầu khác nhau, tạo điều kiện thuận lợi cho việc phát triển và kiểm thử API.
- Collaboration - Collections và môi trường có thể nhập hoặc xuất giúp dễ dàng chia sẻ tệp Một liên kết trực tiếp có thể sử dụng để chia sẻ collections
- Creating Environments - Có nhiều môi trường hỗ trợ ít lặp lại các thử nghiệm nên có thể sử dụng collection cho môi trường khác
- Creation of Tests - Test checkpoints kiểm tra trạng thái phản hồi HTTP thành công có thể thêm vào mỗi lệnh gọi API giúp đảm bảo phạm vi kiểm tra
- Automation Testing - Thông qua việc sử dụng Collection Runner hoặc Command line, kiểm thử có thể chạy nhiều lần lặp lại tiết kiệm thời gian
- Debugging - Bảng điều khiển Postman giúp kiểm tra dữ liệu nào đã được truy xuất giúp dễ dàng gỡ lỗi
- Continuous Integration - Với khả năng tích hợp liên tục, các hoạt động phát triển được duy trì
Giới thiệu về ứng dụng Avaya Spaces
Hình 3 4: Avaya Spaces Link Avaya spaces: https://spaces.avayacloud.com/
Avaya Spaces là ứng dụng hợp tác nhóm dựa trên đám mây dành cho doanh nghiệp, giúp người dùng dễ dàng gặp gỡ, gọi điện, trò chuyện, chia sẻ tệp, quản lý nhiệm vụ và nhận thông báo thời gian thực Ứng dụng này nổi bật với nhiều tính năng tiện ích.
Avaya Spaces đảm bảo bảo mật cao, tuân thủ các tiêu chuẩn HIPAA và GDPR, cùng với hơn 30 tính năng bảo mật nổi bật Nền tảng này cung cấp các không gian riêng tư độc quyền, giúp ngăn chặn tình trạng video-bombing, mang lại sự an toàn tối đa cho người dùng.
- Tích hợp với các ứng dụng khác: Avaya Spaces có thể kết nối với Google, Microsoft Office 365 và Teams, Salesforce, Slack và nhiều hơn nữa
Trí tuệ nhân tạo (AI) giúp bạn thay đổi nền video bằng hình ảnh hấp dẫn và loại bỏ tiếng ồn từ môi trường xung quanh Những tính năng AI ấn tượng này có thể hoạt động trên mọi thiết bị, dù là mới hay cũ.
Avaya Spaces Calling cho phép bạn thực hiện cuộc gọi thoại và video không giới hạn, chỉ với một cú nhấp chuột để chuyển đổi từ trò chuyện sang cuộc gọi Dịch vụ này được hỗ trợ bởi cơ sở hạ tầng đáng tin cậy của chúng tôi.
Chuẩn bị cho các cuộc họp lớn với khả năng mời lên đến 1000 người tham gia Tận dụng chế độ xem concert HD cho 61 người để nâng cao trải nghiệm giao tiếp trực tiếp trong phiên họp của bạn.
Giới thiệu chức năng personal/ group/ direct messages của spaces
Hình 3 5: Chức năng personal/group/direct messages của spaces
Chức năng "My meeting room" cho phép bạn truy cập vào không gian họp cá nhân của mình từ bảng Spaces ở bên trái màn hình Trong không gian này, bạn có thể mời mọi người tham gia các cuộc họp với tư cách là khách, nhưng không thể mời họ làm thành viên hoặc quản trị viên.
Khi lên lịch cuộc gọi trong My meeting room, tất cả người tham gia đều có thể gửi tin nhắn trò chuyện trong suốt quá trình cuộc gọi diễn ra Tuy nhiên, sau khi cuộc gọi kết thúc, chỉ có người chủ trì cuộc gọi mới có thể xem lại các tin nhắn trò chuyện trên tab Trò chuyện.
Nếu bạn ghi âm cuộc gọi trong My meeting room, bạn có thể dễ dàng truy cập bản ghi từ tab Meetings sau khi cuộc gọi kết thúc Tuy nhiên, các thành viên khác không thể xem bản ghi trong không gian này Bạn có thể tải xuống bản ghi và gửi nó cho người khác một cách riêng tư.
Những người khác cũng không thể nhìn thấy các bài đăng hoặc nhiệm vụ trong My meeting room
- Chức năng group spaces: là một cách tuyệt vời để cộng tác với một nhóm đồng nghiệp Bạn có thể tạo bao nhiêu spaces tùy thích
Trong group spaces, bạn có thể:
• Gửi tin nhắn trò chuyện cho mọi người trong spaces
• Tạo và sửa đổi bài viết
• Tạo, sửa đổi và phân công nhiệm vụ
Khi mời người tham gia vào Spaces, vai trò của họ sẽ quyết định quyền truy cập của họ Bạn có thể chỉ định một trong các vai trò như sau:
Nếu bạn là quản trị viên của Spaces, bạn có thể thay đổi chủ sở hữu thông qua mục Chỉnh sửa spaces > Chung Bạn có khả năng thăng cấp thành viên hoặc quản trị viên thành chủ sở hữu, tuy nhiên, chủ sở hữu mới cần phải thuộc cùng công ty với Spaces đang bị ảnh hưởng Giấy phép của chủ sở hữu ảnh hưởng đến các tính năng có sẵn trong Spaces, chẳng hạn như ghi âm và tùy chọn chia sẻ màn hình Nhập vai AI, chỉ khả dụng nếu chủ sở hữu có giấy phép Power Chủ sở hữu Spaces sẽ có quyền hạn tương tự như quản trị viên Spaces.
Chức năng tin nhắn trực tiếp cho phép bạn trò chuyện ngay lập tức với đồng nghiệp trong công ty, hỗ trợ cả cuộc trò chuyện cá nhân lẫn nhóm Ngoài ra, bạn còn có thể bắt đầu cuộc gọi từ tính năng này.
Trong không gian tin nhắn trực tiếp, tab Trò chuyện hiển thị các tin nhắn của bạn, trong khi tab Meetings cho phép bạn truy cập bản ghi cuộc gọi cho các cuộc gọi kỹ thuật số Avaya Spaces.
Từ direct messaging space với một người khác, bạn có thể:
• Trao đổi tin nhắn trò chuyện
• Thực hiện cuộc gọi kỹ thuật số Avaya Spaces
• Thực hiện cuộc gọi âm thanh đến số điện thoại của đồng nghiệp của bạn nếu nó được xuất bản
Direct messaging space trên Avaya Spaces cho phép tối đa 10 người tham gia Khi bạn thêm người mới vào một direct messaging space hiện có, hệ thống sẽ giữ nguyên không gian ban đầu và tạo một không gian mới cho những người bổ sung Lưu ý rằng bạn không thể xóa thành viên khỏi direct messaging space hiện tại.
THỰC HÀNH
Sử dụng Postman runner
Hình 4 4: Kết quả chạy auto trên Postman
Sử dụng Newman – Command line
Newman là một công cụ command-line dùng để chạy các collections trong Postman
Newman cho phép người dùng chạy và kiểm tra một collection của Postman trực tiếp từ command line, với khả năng mở rộng để tích hợp với các máy chủ và hệ thống xây dựng tích hợp liên tục (CI) Nó duy trì các tính năng tương tự như Postman, cho phép thực thi các collections giống như trong trình chạy của Postman Ngoài ra, người dùng cũng có thể chạy collections từ command line bằng Postman CLI Newman có hai cách sử dụng chính.
• Sử dụng như 1 thư viện của Nodejs Để chạy suite auto trên Command line thì ta sử dụng cú pháp sau: newman run
-e -r
Chạy lệnh trên Command: newman run -e
Hình 4 5: Chạy lệnh trên Command line
Hình 4 6: Kết quả report trên Newman
- Tổng số testcase đã chạy: 267
- Tổng số testcase bị bỏ qua: 0
- Collection: Kiểm tra API của Spaces
- Tổng dữ liệu nhận được: 316,79KB
- Thời gian phản hồi trung bình: 599m
Kết quả chạy đã đảm bảo rằng API hoạt động đúng như mong đợi và không có lỗi nào xảy ra
Chạy lệnh trên Command: newman run -e
Hình 4 7: Chạy lệnh trên Command line
Hình 4 8: Kết quả report trên Command line
- Tổng kịch bản kiểm thử: 122
- Tổng điều kiện tiên quyết: 63
- Tổng dữ liệu nhận được: 324.37kB
- Tổng thời gian phản hồi trung bình: 627ms
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN
Sau 2 tháng thực tập tại công ty, tôi đã nâng cao kỹ năng viết testcase API và học cách thiết kế, gọi, cũng như kiểm tra các API bằng Postman Postman là một ứng dụng giao diện người dùng hữu ích cho việc tạo và gửi yêu cầu API, cho phép nhận và xem phản hồi một cách dễ dàng Tôi cũng đã áp dụng công cụ Postman để kiểm tra ứng dụng Avaya Spaces và biết cách chạy, kiểm tra các bộ sưu tập Postman từ dòng lệnh bằng Newman.
- Cải thiện kỹ năng giao tiếp, kỹ năng tiếng anh và thuyết trình
- Thích nghi với môi trường làm việc tại công ty
- Em đã học được kiến thức cơ bản về manual testing và auto testing
- Em đã thực hành test API trên ứng dụng Avaya Spaces
Do thời gian thực tập tại công ty có hạn, em vẫn còn nhiều thiếu sót trong báo cáo và chưa thực hành được đầy đủ các chức năng trên Avaya Spaces.
Trong thời gian tới, tôi sẽ mở rộng kiến thức về testing và thực hành nhiều chức năng trên Avaya Spaces Tôi cam kết nỗ lực hoàn thiện bản thân để tiếp tục theo đuổi lĩnh vực này.
1 "javatpoint," [Online] Available : https://www.javatpoint.com/software-testing- tutorial
2 "Guru99," [Online] Available : https://www.guru99.com/software-testing- techniques.html
3 T Can, "Viblo," 20 3 2021 [Online] Available : https://viblo.asia/p/tim-hieu-kien- thuc-co-ban-ve-api-maGK7A4Mlj2
4 Tài liệu do công ty cung cấp