Kiểm thử tự động api với phần mềm postman

● Giai đoạn 4: Test environment set up - thiết lập môi trường kiểm thử Thiết lập môi trường thử nghiệm là một hoạt động độc lập và có thể được bắtđầu cùng với giai đoạn phát triển kịch

TRƯỜNG ĐẠI HỌC KINH TẾ

KHOA THỐNG KÊ – TIN HỌC

BÁO CÁO THỰC TẬP NGHỀ NGHIỆP NGÀNH HỆ THỐNG THÔNG TIN QUẢN LÝ CHUYÊN NGÀNH TIN HỌC QUẢN LÝ

LỜI CẢM ƠN

Đầu tiên, em xin chân thành cảm ơn cô Nguyễn Thị Uyên Nhi- giáo viên hướngdẫn đã tận tình giúp đỡ em trong suốt thời gian thực tập hè vừa qua, em cũng xinchân thành cảm ơn anh Nguyễn Đại Từ Chương đã chỉ bảo em trong nghiệp vụcủa kiểm thử viên, chia sẻ cho em các kinh nghiệm và hướng dẫn em đi đúngcông việc mà một kiểm thử viên cần làm, giúp em hoàn thành đề tài này tốt hơn

Em cũng xin cảm ơn Công ty cổ phần phần mềm SIVIP đã tạo điều kiện, bỏ thờigian và công sức để giúp em có thể học tập tốt tại công ty Bởi vì còn thiếu sót rấtnhiều kinh nghiệm nên trong quá trình thực tập em không thể tránh khỏi có nhữngsai sót, vì vậy em rất mong quý thầy cô có thể góp ý cho em để từ đó em có thêmkinh nghiệm, hoàn thiện kỹ năng của bản thân đồng thời có thể bổ sung, nâng caokiến thức của mình

Một lần nữa, em xin cảm ơn quý Công ty cổ phần phần mềm SIVIP, cảm ơn côNguyễn Thị Uyên Nhi và anh Nguyễn Đại Từ Chương đã giúp đỡ em trong quátrình thực hiện đề tài này

LỜI CAM ĐOAN

Em xin cam đoan đề tài: “Kiểm thử tự động API với phần mềm Postman” là một

công trình nghiên cứu độc lập của em dưới sự hướng dẫn của giáo viên hướng dẫnNguyễn Thị Uyên Nhi và anh Mentor Nguyễn Đại Từ Chương, ngoài ra không cóbất cứ sự sao chép của người khác

Đề tài, nội dung báo cáo thực tập là sản phẩm mà em đã nghiên cứu trong quátrình học tập tại Công ty cổ phần phần mềm SIVIP Kết quả được trình bày trongbáo cáo là hoàn toàn trung thực, em xin chịu hoàn toàn trách nhiệm, kỷ luật của

bộ môn, khoa và nhà trường về sự cam đoan này

MỤC LỤC

1.1 Giới thiệu tổng quát về doanh nghiệp thực tập 2

2.2 Các mô hình phát triển phần mềm 10 2.3 Các phương pháp kiểm thử phần mềm 11

Hình 2.8 Thêm mới thông tin khách hàng 21

Bảng 1 Phân biệt QA và QC 9 Bảng 2 Phân biệt Manual Test và Automation Test 10

LỜI MỞ ĐẦU

1 Mục tiêu của đề tài

- Đề tài này nghiên cứu về kiến thức, nghiệp vụ, kĩ năng của kiểm thử tự động APIcủa phần mềm SIVIP thông qua phần mềm Postman (danh mục khách hàng)

2 Đối tượng và phạm vi nghiên cứu

- Đối tượng: API

- Phạm vi: Các kiến thức cơ bản và tổng quát về kiểm thử phần mềm

3 Kết cấu của đề tài

Đề tài được tổ chức gồm phần mở đầu, 3 chương nội dung và phần kết luận

- Chương 1: Tổng quan

- Chương 2: Lý thuyết

- Chương 3: Thiết kế và thực thi kiểm thử API

- Kết luận và hướng phát triển

CHƯƠNG 1 TỔNG QUAN

1.1 Giới thiệu tổng quát về doanh nghiệp thực tập

Công ty Cổ phần Phần mềm Sivip được thành lập từ tháng 6/2011, chuyên sâutrong lĩnh vực phần mềm kế toán online và giải pháp quản lý toàn diện doanhnghiệp

Sản phẩm chính của chúng tôi là Sivip Online, một phiên bản đột phá, chạy hoàntoàn trên web, làm việc mọi lúc mọi nơi, trên mọi thiết bị Ngoài phiên bản chuẩn,Sivip còn có phiên bản chỉnh sửa theo đặc thù doanh nghiệp

Lợi thế của Sivip là xây dựng thành công phần mềm lõi, khả năng tùy biến caotheo từng quy trình, tốc độ xử lý nhanh trên dữ liệu lớn, hướng đến đa kết nối vàhợp nhất số liệu, giúp tiết kiệm thời gian triển khai Từ đó mang lại nhiều giá trịgia tăng cho khách hàng

Hình 1.1 Công ty cổ phần phần mềm SIVIP

1.2 Tổng quan về vị trí việc làm

● Hiểu rõ được các sản phẩm cần phải kiểm tra

● Cần nắm rõ cách lập kế hoạch các chiến lược thử nghiệm để tìm ra đượcnhững vấn đề cần giải quyết và thực hiện các thử nghiệm

● Thực hiện phân tích rõ ràng các ưu điểm, nhược điểm hoặc giải quyết dễdàng hơn các rủi ro liên quan đến từng thành phần cũng như giao diện của sảnphẩm.

● Kiểm tra rồi báo cáo lại cho các nhóm kĩ thuật để có thể cải thiện đượcnhững lỗi phát sinh

1.3 Cơ sở lý thuyết

1.3.1 Tester là gì?

Tester chính là những người có nhiệm vụ thực hiện các công việc chính như kiểmtra các lỗi, đảm bảo chất lượng phần mềm được tốt nhất và hoạt động trơn tru nhấttrước khi phân phối đến tay khách hàng Tester tùy thuộc vào tầm quan trọng cũngnhư quy mô của dự án để đánh giá mức độ ảnh hưởng

1.3.2 Các kỹ năng cần có của một Tester

1.3.3 Cơ hội việc làm

Với sự phát triển vượt bậc của Công nghệ thông tin hiện nay cơ hội việc làm đốivới Tester rất chuyên nghiệp

Có thể thấy rằng đối với nghề lập trình sự nhạy bén của tuổi trẻ rất quan trọng, tuynhiên đối với nghề Tester thì kinh nghiệm đã được tích lũy nhiều năm mới là điềuquan trọng nhất

Nếu như một người Tester giỏi tiếng Anh thì lại càng có nhiều cơ hội để làm ở cáccông ty phần mềm lớn với các dự án outsourcing của nước ngoài với mức lươngrất cao.

Nghề nghiệp ổn định, thường xuyên được cập nhật những công nghệ mới và tiếpxúc với những dự án khác nhau, học được nhiều thứ mới lạ nên không nhàm chán

2.1.2 Tại sao kiểm thử phần mềm quan trọng

Kiểm thử phần mềm rất quan trọng vì nếu có bất kỳ lỗi hoặc lỗi nào trongphần mềm, nó có thể được xác định sớm và có thể được giải quyết trước khichuyển giao sản phẩm phần mềm Sản phẩm phần mềm được kiểm tra đúng cáchđảm bảo độ tin cậy, bảo mật và hiệu suất cao, giúp tiết kiệm thời gian, hiệu quả chiphí và sự hài lòng của khách hàng

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

1 Thử nghiệm cho thấy sự hiện diện của lỗi

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứngminh rằng phần mềm không có lỗi Kiểm thử làm giảm xác suất lỗi chưa tìm thấyvẫn còn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn cóthể có lỗi Vì vậy, phải tìm được càng nhiều lỗi càng tốt

2 Thử nghiệm toàn diện là không thể

Thử nghiệm toàn diện là không thể Thay vào đó, chúng ta cần số lượng thửnghiệm tối ưu dựa trên đánh giá rủi ro của ứng dụng Chúng ta sẽ nhận ra rằng cáclỗi có thể được tìm thấy trong hoạt động đa tác vụ và cần được kiểm tra kỹ lưỡng,điều này đưa chúng ta đến nguyên tắc tiếp theo là Phân cụm lỗi

3 Thử nghiệm sớm

Nguyên tắc kiểm thử sớm có nghĩa là việc kiểm thử cần được thực hiện càngsớm càng tốt trong vòng đời phát triển phần mềm Nguyên tắc này cho thấy ta cầnphát hiện bug ngay từ các bước đầu tiên như nghiên cứu yêu cầu hay design

4 Phân cụm lỗi

Phân cụm lỗi cho biết một số lượng nhỏ các mô-đun chứa hầu hết các lỗi đượcphát hiện Nếu các bài kiểm tra giống nhau được lặp đi lặp lại nhiều lần, cuối cùngcác trường hợp kiểm tra tương tự sẽ không còn tìm thấy lỗi mới

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

Nếu cùng một tập hợp các kiểm thử lặp đi lặp lại được tiến hành, phươngpháp này sẽ vô dụng để phát hiện ra các lỗi mới

Để khắc phục điều này, các trường hợp thử nghiệm cần được xem xét và sửađổi thường xuyên, thêm các trường hợp thử nghiệm mới và khác nhau để giúp tìm

ra nhiều lỗi hơn

6 Thử nghiệm phụ thuộc vào ngữ cảnh

Tất cả các phần mềm được phát triển không giống nhau Bạn có thể sử dụngmột cách tiếp cận, phương pháp, kỹ thuật và loại thử nghiệm khác nhau tùy thuộcvào loại ứng dụng

7 Không có sai lầm ngụy biện

Có thể phần mềm không có lỗi 99% vẫn không sử dụng được Đây có thể làtrường hợp nếu hệ thống được kiểm tra kỹ lưỡng cho yêu cầu sai Kiểm thử phầnmềm không chỉ đơn thuần là tìm lỗi mà còn để kiểm tra xem phần mềm có đápứng được nhu cầu kinh doanh hay không Việc không có lỗi là sai lầm, tức là việctìm và sửa các lỗi không giúp ích gì nếu bản dựng hệ thống không sử dụng được

và không đáp ứng nhu cầu & yêu cầu của người dùng

2.1.4 Vòng đời của kiểm thử

Hình 2.1: Vòng đời của kiểm thử

Vòng đời kiểm thử phần mềm (SOFTWARE TEST LIFE CYCLE) là quytrình kiểm thử được thực hiện theo hệ thống và có kế hoạch rõ ràng Trong quátrình kiểm thử, rất nhiều giai đoạn khác nhau được thực hiện một cách trình tự.Mỗi giai đoạn đều có đầu vào và đầu ra khác nhau nhưng đều hướng tới mục tiêucuối đảm bảo chất lượng sản phẩm

Các giai đoạn điển hình trong 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 này, tester sẽ phân tích tài liệu đặc tả yêu cầu để kiểm tra cácyêu cầu do khách hàng đưa ra Yêu cầu được chia làm 2 dạng: Functional (Chứcnăng) và Non-Functional (Phi chức năng) Cuối cùng, tester sẽ xác định loại kiểmthử sẽ dùng và độ ưu tiên của các hoạt động kiểm thử, xác định môi trường testcần chuẩn bị

● Giai đoạn 2: Test planning - lập kế hoạch kiểm thử

▪ Sau giai đoạn một, tester tiến hành Lập kế hoạch kiểm thử để kiểmtra xem phần mềm có đáp ứng các yêu cầu hay không Kế hoạchkiểm thử là một tài liệu tổng quan về việc kiểm thử dự án bao gồmnhững thông tin sau: Phạm vi kiểm thử, hướng tiếp cận, quy trìnhkiểm thử, tài nguyên và nhân lực test

▪ Các chức năng/module cần được kiểm tra; các công cụ và môi trườngkiểm thử cần có.

▪ Ai test chức năng nào? Khi nào bắt đầu thực hiện viết và hoàn thànhtest case? Khi nào bắt đầu thực hiện và hoàn thành test?

● Giai đoạn 3: Test case development - thiết lập kịch bản kiểm thử

Trong giai đoạn này, tester sẽ đọc hiểu tất cả các tài liệu, từ đó xác địnhnhững việc cần làm, chức năng nào cần test hoặc không Sau đó, dựa vào kế hoạch

và kỹ thuật thiết kế kịch bản kiểm thử, Tester sẽ bắt đầu viết test case

Yêu cầu của test case: Thể hiện tất cả các trường hợp kiểm thử có thể phátsinh để đáp ứng yêu cầu sản phẩm Ngoài test case, Tester cũng cần chuẩn bị các

dữ liệu cần thiết khác như test data, test script, test design, test automation script

● Giai đoạn 4: Test environment set up - thiết lập môi trường kiểm thử

Thiết lập môi trường thử nghiệm là một hoạt động độc lập và có thể được bắtđầu cùng với giai đoạn phát triển kịch bản kiểm thử Môi trường kiểm thử sẽ dodevelopers tạo ra để deploy sản phẩm đã được hoàn thiện về phần lập trình

Sau khi thiết lập môi trường thử nghiệm, tester thực hiện nhanh SmokeTesting (Kiểm thử khói) để kiểm tra tính sẵn sàng của môi trường thử nghiệmđồng thời tính ổn định của bản build sản phẩm Trường hợp xuất hiện lỗi như môitrường không ổn định hay bản build lỗi chức năng chính, tester sẽ báo lạidevelopers sửa ngay Nếu môi trường và bản build đã đủ ổn định để tiến hành testchi tiết, tester sẽ tiến hành giai đoạn tiếp theo - Thực hiện kiểm thử

● Giai đoạn 5: Test execution - thực hiện kiểm thử

Theo test case đã thiết kế và môi trường kiểm thử đã hoàn tất cài đặt, Tester

sẽ báo cáo bug lên tool quản lý lỗi và theo dõi đến khi fix bug thành công Tiếp

đó, Tester thực hiện retest để verify các fix bug và regression test trong trường hợp

có sự thay đổi Sau khi hoàn tất giai đoạn này, các chuyên viên kiểm thử cần cóđược test results (kết quả kiểm thử) và defect reports (danh sách các lỗi tìm được)

● Giai đoạn 6: Test cycle closure - đóng chu trình kiểm thử

Ở giai đoạn cuối cùng, tester chuẩn bị báo cáo kết thúc kiểm thử, tổng hợp lạicác chỉ số trong quá trình test Cả team phát triển sẽ ngồi họp để đánh giá toàn bộcác tiêu chí xác định kiểm thử đã đủ hay chưa Những tiêu chí này khác nhau tùytheo từng dự án, thông thường bao gồm:

▪ Số lượng test case tối đa được thực thi Passed

▪ Tỷ lệ lỗi giảm xuống dưới mức nhất định

▪ Deadline được chốt từ giai đoạn làm kế hoạch kiểm thử.

2.1.5 Phân biệt 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 cho các bên liên quan

● QC (Quality Control): Là kỹ sư quản lý chất lượng Đây là những người

trực tiếp làm kiểm tra cho các sản phẩm thực tế từng công đoạn của sảnxuất

Định nghĩa Đảm bảo chất lượng Kiểm soát chất lượng

Mục đích Ngăn ngừa những lỗi sai và

ngăn ngừa những rủi ro liên quan đến chất lượng

Nhằm phát hiện lỗi sai trong sản phẩm và tiến hành sửa chữa chúng

Kiểm soát chất lượng, hướng dẫn, thử nghiệm, điều tra, đánh giá kết quả, đưa ra phương án khác

chuẩn chất lượng.

Bảng 1 Phân biệt QA và QC 2.1.6 Phân biệt Manual Test và Automation Test

Định nghĩa Trong kiểm thử thủ công các

trường hợp kiểm thử được thực thi bởi tester (con người)

và các phần mềm

Sử dụng các công cụ tự động hóa để thực thi các trường hợp kiểm thử

Thời gian xử lý Việc kiểm thủ công tốn nhiều

thời gian và nhân lực

Kiểm thử tự động nhanh hơn đáng kể so với cách tiếp cận thủ công

Thời gian đầu

tư ban đầu

Số vốn đầu tư thấp hơn nhưng

về lâu dài không lại không đem lại hiệu quả cao

Số vốn đầu tư cho kiểm thử

tự động cao hơn, tuy nhiên

về lâu dài sẽ tốt hơn

Độ tin cậy Chính xác thấp vì có khả năng

là do lỗi của con người

Phương thức đáng tin cậy, được thực hiện bởi công cụ

và tập lệnhKiểm tra năng suất Không khả thi theo cách thủ công Bắt buộc phải được kiểm tra

bằng một công cụ tự động hóa.Kiểm thử hàng loạt Không thể thực hiện kiểm

2.2 Các mô hình phát triển phần mềm

● Waterfall model (Mô hình thác nước)

Waterfall model được coi là mô hình phát triển phần mềm đầu tiên được sửdụng Đây là mô hình áp dụng theo tính tuần tự của các giai đoạn phát triển phầnmềm; giai đoạn sau chỉ được thực hiện tiếp khi giai đoạn trước đã kết thúc Dotính chất này, mỗi giai đoạn của mô hình thác nước phải được xác định chính xác

● V model (Mô hình chữ V)

Khi áp dụng V model, toàn bộ quy trình phát triển phần mềm được chiathành 2 giai đoạn tiến hành song song tương ứng nhau: Phát triển và Kiểm thử.Trong mô hình chữ V, việc kiểm thử được diễn ra ngay từ giai đoạn lấy yêu cầunên lỗi được tìm ra ngay từ sớm để khắc phục Muốn áp dụng được mô hình chữ Vthì yêu cầu phần mềm phải xác định rõ ràng; công nghệ phần mềm và các công cụphải được tìm hiểu kỹ

● Spiral model (Mô hình xoắn ốc)

Spiral model (Mô hình xoắn ốc) là quy trình phát triển định hướng rủi ro chocác dự án phần mềm Mô hình chú trọng vào phân tích rủi ro dự án, bắt đầu vớiyêu cầu/mục tiêu thiết kế và kết thúc với việc khách hàng kiểm tra tiến độ củatừng giai đoạn Mô hình xoắn ốc là một cách tiếp cận thực tế để phát triển các sảnphẩm phần mềm quy mô lớn Ngoài ra, nhà phát triển và khách hàng hiểu rõ hơn

và phản ứng với các rủi ro ở mỗi cấp độ phát triển

● Agile model & Scrum Process (Mô hình Agile và quy trình Scrum)

Hình 2.2 Mô hình Agile

▪ Scrum Process

Scrum là một “khung quản lý dự án” được áp dụng rất rộng rãi từ những dự

án đơn giản với một nhóm phát triển nhỏ cho đến những dự án có yêu cầu rất phứctạp với hàng trăm người tham gia Ngoài ra, Scrum Process cũng phù hợp vớinhững dự án đòi hỏi khung thời gian cố định

Trong Scrum, công việc sẽ được chia nhỏ thành nhiều giai đoạn gọi làSprint Mỗi Sprint chỉ kéo dài từ 1 đến 4 tuần, không quá một tháng Đầu Sprint sẽlên kế hoạch làm những yêu cầu nào rồi thực hiện code và test Cuối Sprint là mộtsản phẩm hoàn thiện cả code lẫn test có thể demo và chạy được

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

Có ba phương pháp kiểm thử phần mềm:

● Kiểm thử hộp trắng (White box testing)

Trong kiểm thử hộp trắng, cấu trúc mã hoặc thuật toán của chương trìnhđược đưa vào xem xét Các trường hợp kiểm thử được thiết kế dựa vào cấu trúc

mã hoặc cách thức làm việc của chương trình Người kiểm thử truy cập vào mãnguồn của chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việckiểm thử

Hình 2.3 Kiểm thử hộp trắng

● Kiểm thử hộp đen (Black box testing)

Kiểm thử hộp đen là phương pháp test dựa trên đầu vào và đầu ra củachương trình để test mà không quan tâm tới code bên trong được viết ra sao Kiểmthử hộp đen không yêu cầu kỹ sư kiểm thử cần phải có bất kỳ kiến thức về mãhoặc thuật toán của chương trình

● Kiểm thử hộp xám (Gray box testing)

2.4 Kiểm thử tự động

2.4.1 Khái niệm

Kiểm thử tự động là một kỹ thuật kiểm thử phần mềm thực hiện bằng cách

sử dụng các công cụ phần mềm kiểm thử tự động đặc biệt để thực hiện bộ trườnghợp kiểm thử

Phần mềm kiểm tra tự động hóa cũng có thể nhập dữ liệu kiểm tra vào hệthống đang kiểm tra, so sánh kết quả mong đợi và kết quả thực tế, đồng thời tạobáo cáo kiểm tra chi tiết Software Test Automation đòi hỏi đầu tư đáng kể về tiềnbạc và nguồn lực

Các chu kỳ phát triển liên tiếp sẽ yêu cầu thực hiện lặp đi lặp lại cùng một

bộ thử nghiệm Sử dụng công cụ tự động kiểm tra, có thể ghi lại bộ kiểm tra này

và phát lại theo yêu cầu Khi bộ thử nghiệm được tự động hóa, không cần sự canthiệp của con người Điều này đã cải thiện ROI của Test Automation

2.4.2 Mục tiêu chính của kiểm thử tự động

Mục đích của kiểm thử tự động là giảm thiểu thời gian, công sức và kinhphí, tăng độ tin cậy, tăng tính hiệu quả và giảm sự nhàm chán cho người kiểm thửtrong quá trình kiểm thử sản phẩm phần mềm

Kiểm thử tự động sẽ được sử dụng khi dự án không đủ tài nguyên (thời gian,nhân lực và chi phí), phải thực hiện kiểm thử hồi quy khi sản phẩm được sửa đổihoặc nâng cấp và cần kiểm thử lại các tính năng đã thực hiện tốt trước đó, kiểm trakhả năng vận hành của sản phẩm trong các môi trường đặc biệt

2.4.3 Quy trình thử nghiệm tự động

Hình 2.5 Quy trình thử nghiệm tự động

● Bước 1 Lựa chọn công cụ kiểm tra

Việc lựa chọn công cụ kiểm tra phần lớn phụ thuộc vào công nghệ mà ứngdụng đang kiểm tra được xây dựng trên đó

● Bước 2 Xác định phạm vi Tự động hóa

Phạm vi tự động hóa là khu vực ứng dụng đang thử nghiệm của bạn sẽ được

tự động hóa Các điểm sau giúp xác định phạm vi:

▪ Các tính năng quan trọng đối với doanh nghiệp

▪ Các kịch bản có lượng dữ liệu lớn

▪ Các chức năng phổ biến trên các ứng dụng

▪ Tính khả thi kỹ thuật

▪ Mức độ mà các thành phần kinh doanh được sử dụng lại

▪ Độ phức tạp của các trường hợp thử nghiệm

▪ Khả năng sử dụng các trường hợp thử nghiệm giống nhau để thử nghiệm

trên nhiều trình duyệt

● Bước 3 Lập kế hoạch, Thiết kế và Phát triển

Trong giai đoạn này, bạn tạo chiến lược & kế hoạch Tự động hóa, bao gồmcác chi tiết sau:

▪ Công cụ tự động hóa được chọn

▪ Thiết kế khung và các tính năng của nó

▪ Các mục tự động hóa trong phạm vi và ngoài phạm vi

▪ Chuẩn bị thử nghiệm tự động hóa

▪ Lịch trình và Dòng thời gian của kịch bản và thực thi

▪ Sản phẩm của kiểm thử tự động hóa

● Bước 4 Thực hiện kiểm tra

Các tập lệnh tự động hóa được thực thi trong giai đoạn này Các tập lệnh cần

dữ liệu thử nghiệm đầu vào trước khi được thiết lập để chạy Sau khi thực hiện, họcung cấp các báo cáo thử nghiệm chi tiết

Việc thực thi có thể được thực hiện trực tiếp bằng công cụ tự động hóa hoặcthông qua công cụ Quản lý kiểm tra sẽ gọi công cụ tự động hóa.

● Bước 5 Bảo trì

Phương pháp bảo trì bảo trì tự động hóa thử nghiệm là giai đoạn thửnghiệm tự động hóa được thực hiện để kiểm tra xem các chức năng mới đượcthêm vào phần mềm có hoạt động tốt hay không Bảo trì trong kiểm thử tự độnghóa được thực hiện khi các tập lệnh tự động hóa mới được thêm vào và cần đượcxem xét và bảo trì để cải thiện hiệu quả của các tập lệnh tự động hóa với mỗi chu

kỳ phát hành liên tiếp

2.4.4 Lợi ích của kiểm thử tự động

▪ Nhanh hơn 70% so với thử nghiệm thủ công

▪ Phạm vi thử nghiệm rộng hơn của các tính năng ứng dụng

▪ Đáng tin cậy trong kết quả, đảm bảo tính nhất quán

▪ Tiết kiệm thời gian và chi phí, cải thiện độ chính xác

▪ Sự can thiệp của con người là không cần thiết trong khi thực hiện

▪ Tăng hiệu quả, tốc độ tốt hơn trong việc thực hiện các bài kiểm tra

▪ Các kịch bản thử nghiệm có thể tái sử dụng, kiểm tra thường xuyên và kỹlưỡng

▪ Có thể đạt được nhiều chu kỳ thực hiện hơn thông qua tự động hóa

2.5 Testcase

2.5.1 Khái niệm

Test case (kịch bản kiểm thử) là một tập hợp các hành động được thực thi

để xác minh một function, một hệ thống phần mềm có hoạt động đúng hay không.Test case mô tả dữ liệu đầu vào, hành động hoặc sự kiện và một kết quả mong đợi(expected result), để xác định kiểm tra một chức năng của ứng dụng phần mềmhoạt động đúng hay không

2.5.2 Các thông số điển hình của Testcase

Tùy thuộc vào từng template của từng công ty nên cấu trúc của test case sẽkhác nhau Về cơ bản thì test case bao gồm các thành phần chính sau đây: