Bạn đang tìm kiếm định nghĩa Manual Testing là gì? Bạn đang phân vân không viết Manual Testing (MT) có những ưu điểm và nhược điểm nào? Hoặc đang phân vân giữa điểm khác nhau cơ bản của Manual Testing và Automation Testing. Hãy cùng nhau tìm hiểu những vấn đề trên qua bài viết sau đây.

I. Manual Testing Là Gì?

Manual Testing là 1 trong những công việc theo dạng kiểm thử phần mềm, hoặc là một chương trình được thực hiện bằng tay bởi các tester mà không thông qua bất kỳ công cụ hỗ trợ nào.

Nó hoạt động dựa vào mục đích phát hiện các lỗi bug từ nhỏ cho đến lớn trong phần mềm. Từ đó, đưa ra các định hướng giải quyết để có thể đảm bảo cho phần mềm hoạt động ổn định nhất lúc giao cho khách hàng.

II. Nhược Điểm Và Ưu Điểm Của Manual Testing

+ Ưu điểm:

• Tester có phản hồi trực quan nhanh và chính xác
• Ít tốn kém hơn vì chúng ta không cần phải chi ngân sách cho các công cụ và các quy trình tự động hóa.
• Có thêm khả năng phán đoán của con người
• Một yêu cầu thay đổi cũng không làm kiểm thử thủ công trở lên quá phức tạp.

+ Nhược điểm:

• Manual testing ít tin cậy hơn bởi nó được thực hiện bởi con người => Dễ xảy ra sai sót hơn
• Quá trình kiểm thử không thể ghi lại
• Với một số task khó thực hiện thủ công như performance testing/kiểm thử hiệu năng và stress testing/kiểm thử tải thì manual testing rất khó để thực hiện.

III. Khi Nào Nên Áp Dụng Manual Testing ?

• Kiểm thử thăm dò: Đây là loại kiểm thử đòi hỏi phải thử nghiệm của kiến thức, kinh nghiệm, phân tích / logic kỹ năng, sáng tạo và trực giác. Xét nghiệm này được đặc trưng bởi các tài liệu ở đây kém bằng văn bản kỹ thuật, hoặc một thời gian ngắn để thực hiện. Chúng ta cần những kỹ năng của con người để thực hiện quá trình kiểm thử trong kịch bản này.

• Usability Testing: Đây là một lĩnh vực mà bạn cần để đo độ thân thiện, hiệu quả, hoặc thuận tiện phần mềm hoặc sản phẩm cho người dùng cuối. Ở đây, quan sát con người là yếu tố quan trọng nhất, do đó, một phương pháp thủ công là một lợi thế.

• Kiểm thử Ad-hoc: Trong kịch bản này, không có phương pháp cụ thể. Nó là một phương pháp hoàn toàn không có kế hoạch kiểm thử nơi sự hiểu biết và cái nhìn sâu sắc của các thử nghiệm là yếu tố quan trọng duy nhất.

IV. Các Loại Manual Testing

Dưới đây là sơ đồ mô tả các loại Manual Testing . Trong thực tế, bất kỳ loại kiểm thử phần mềm nào cũng có thể được thực hiện bằng tay cũng như sử dụng một công cụ tự động hóa.

• Black Box Testing
• White Box Testing
• Unit Testing
• System Testing
• Integration Testing
• Acceptance Testing

V. Quy Trình Manual Testing

+ Hiểu rõ các yêu cầu

Để thực hiện kiểm thử đạt hiệu quả cao, tester cần hiểu rõ những yêu cầu của phần mềm, cách mà phần mềm đó phải hoạt động. Phần tài liệu ghi chép toàn bộ thông tin liên quan đến sản phẩm đang được kiểm thử được gọi là Requirement, hoặc đôi lúc được trình bày dưới dạng User story.

Những tài liệu này giúp tester hiểu được mục đích của sản phẩm, các phạm vi cần phải kiểm thử, các công việc cần phải làm, và các khái niệm về defect.

Việc nắm rõ các thông tin này trước khi chuẩn bị kiểm thử là rất cần thiết, bởi mục tiêu của mọi hoạt động kiểm thử là giúp sản phẩm có ít lỗi nhất có thể.

Trong 1 số ít giả dụ mà tester không tiếp cận được với requirement hay user story, bạn sẽ cần phải trở nên linh hoạt và sáng tạo hơn một chút để hiểu cách hoạt động của sản phẩm thông qua các nguồn khác nhau.

+ Viết test case

Sau khi đọc và hiểu rõ các requirement, ta sẽ đi đến bước tạo test case.

Test case đóng vai trò là người dẫn đường cho các tester, đưa ra những bước chi tiết, hướng dẫn thực hiện kiểm thử các tính năng và bối cảnh khác nhau của phần mềm đó.

Viết một test case chi tiết là rất cần thiết bởi nó sẽ giúp công việc kiểm thử trở nên mượt mà hơn và đảm bảo bao quát được rộng nhất. Test case cũng cần phải đủ chi tiết để dễ dàng thực hiện lại phần kiểm thử nếu cần thiết. Điều này giúp những tester tham gia vào sau có thể nhanh chóng bắt kịp công việc, dễ dàng thực hiện kiểm thử hoặc chạy lại các phần kiểm thử cũ mà không cần quá nhiều thời gian hỏi lại.

Có nhiều tester vẫn sử dụng Excel để làm test case, tuy nhiên hiện nay có nhiều phần mềm quản lý test case như TestLodge có thể giúp sắp xếp test case hiệu quả hơn, từ đó có thể tăng năng suất khi thực hiện kiểm thử.

+ Thực hiện kiểm thử

Khi đã có test case và chuẩn bị xong môi trường test, ta sẽ bắt tay vào thực hiện kiểm thử.

Mỗi phần kiểm thử được thực hiện xong phải có ghi chú đã vượt qua (passed), thất bại (failed) hay bỏ qua (skipped).

Khi thực hiện kiểm thử thủ công, hãy nhớ ghi chép lại những gì đã làm cho việc kiểm thử thất bại để có thể dễ dàng tái hiện và lên kế hoạch xử lý chúng trong tương lai.

+ Điều tra sâu hơn

Không thể phủ nhận lợi ích của việc bám sát một test case chi tiết để thực hiện kiểm thử. Tuy nhiên trong vài trường hợp, thực hiện xen kẽ kiểm thử thăm dò (exploratory testing) có thể giúp khám phá ra những lợi ích to lớn mà trước đây chúng ta chưa phát hiện được.

Kiểm thử thăm dò cho phép các tester hoạt động không theo kịch bản cho sẵn, mà phụ thuộc hoàn toàn vào trí tưởng tượng của người đó. “Nghịch ngợm” một chút có thể giúp tester khám phá những phạm vi mới để bổ sung vào các giai đoạn kiểm thử về sau, tìm ra gợi ý để điều tra các phần kiểm thử thất bại, và bổ sung dữ liệu khi test case chưa bao quát được 100%.

+ Viết Báo cáo bug

Cùng với việc kiểm thử, tester còn có nhiệm vụ ghi chép lại chi tiết về các lỗi đã tìm được trong quá trình kiểm thử. Ghi chép một cách chi tiết thông tin về lỗi sẽ có ích rất nhiều cho đội phát triển về sau.

Hãy chuẩn bị sẵn bằng cách viết một báo cáo lỗi thật chi tiết để giúp team và chính bạn, đồng thời có thể tiết kiệm được rất nhiều thời gian nếu bạn phải giải trình về những lỗi bạn tìm được.

Báo cáo bug cần phải được đặt tên dễ nhận diện để giúp tìm kiếm dễ dàng hơn về sau.

Nội dung của báo cáo cần có chi tiết các bước để tái hiện lỗi (thường là các bước trong test case), kết quả trả về mong muốn, và kết quả trả về trên thực tế. Ngoài ra, cần đính kèm những tài liệu nhằm giúp team hiểu rõ vấn đề hơn như: ảnh chụp màn hình, video quay lại các bước thực hiện, hoặc các file trích xuất,…

+ Báo cáo về kết quả test

Sau khi thực hiện toàn bộ công việc test, chúng ta sẽ cần nhìn lại một cách tổng quan về kết quả của quá trình. Ví dụ như: Đã triển khai bao nhiêu test case? Bao nhiêu testcase đã thất bại? Bao nhiêu testcase đã bị bỏ qua?

Có một bản báo cáo tổng thể sẽ giúp chúng ta nhìn rõ được những con số này, từ đó có kế hoạch hợp lý để triển khai tiếp các công việc trong tương lai, ví dụ như có phải thực hiện lại test case nào không,…

VI. Các Tool Hỗ Trợ Manual Testing

• Selenium
• QTP
• Jmeter
• Loadrunner
• TestLink
• Quality Center(ALM)

VII. Những Công Việc Của Một Manual Testing

Theo khái niệm Manual Testing là gì ở phía trên thì công việc của một MT là kiểm tra cũng như bảo đảm chất lượng của phần mềm. Từ đó, để phát hiện nhanh chóng hơn các lỗi còn tồn tại trên phần mềm rồi kịp thời báo lại cho bộ phận kỹ thuật để được fix lỗi trước khi giao sản phẩm cho khách hàng.

Chính vì vậy, với những MT khi mới bắt đầu vào nghề thì cần trau dồi được toàn bộ kỹ năng cũng như kiến thức cơ bản cho việc nắm bắt để thực hiện tốt công việc của mình. Dưới đây là 1 số vấn đề bạn cần chuẩn bị như sau:

• Hiểu rõ những kỹ thuật test manual cơ bản, cần xây dựng tư duy phân tích để tìm được ra lỗi tốt cũng như nắm vững hầu hết quy định liên quan đến kỹ thuật test.
• Phải nâng cao trình độ đọc hiểu tiếng anh để quá trình tìm hiểu các tài liệu hướng dẫn của nước ngoài được dễ dàng hơn. Đây cũng là một trong những yếu tố bạn cần lưu ý để có thể ghi điểm với nhà tuyển dụng.

VIII. Học Gì Để Trở Thành Manual Testing

Để trở thành một chuyên viên manual testing giỏi bạn cần phải xác định được hướng đi đúng đắn của bản thân mình, nên đầu tư vào cái nào, học hỏi cái gì, rèn luyện những kỹ năng nào,… để giúp bạn thắp sáng ngọn lửa yêu thích của mình

+ Kiến thức chung cần biết:

• Thành thạo kiến thức về máy tính cũng như việc cài đặt phần, sử dụng máy tính cũng như tin học
• các kiến thức về lập trình như các câu lệnh SQL, HTML, CSS,..
• Hiểu rõ những khái niệm test, các thuật ngữ chuyên sử dụng trong lĩnh vực test phần mềm các quy trình sản xuất, hoạt động của phần mềm
• chịu khó tìm hiểu, học hỏi các kiến thức liên quan đến test và các tài liệu liên quan
• Hiểu rõ về các loại test: Structural testing, change relate testing, …

+ Các kiến thức cần nắm vững

• Thiết kế các test case: Cần phải hiểu roc và viết thành thạo các test case để các test case được hiệu quả, tối ưu phù với các quy trình test ở các loại phần mềm khác
• Test reporting: Đây là cách viết report giúp cho việc viết các báo cáo kết quả test được dễ dàng và hoàn thiện các báo cáo khi kiểm tra được các lỗi kỹ thuật
• Tạo một test plan: Đây là một cách biết test plan cơ bản và cách viết thông thường, phù hợp và chính xác
• Lập trình: Cần hiểu và nắm vững thành thạo 1 ngôn ngữ lập trình để có thể hoàn thiện được ngôn ngữ lập trình nâng cao

The post Manual Testing Là Gì ? (Kiểm Thử Bằng Tay Là Gì ?) first appeared on Techacademy.

source https://techacademy.edu.vn/manual-testing-la-gi/

Acceptance Testing là một trong 4 mức độ kiểm thử và cũng là bước cuối cùng trước khi sản phẩm được đưa ra hoạt động hoặc trước khi phân phối sản phẩm phải được chấp nhận.

Acceptance Testing là một trong những giai đoạn thuộc lĩnh vực kiểm thử phần mềm. Vậy, Acceptance Testing là gì? Có những loại Acceptance Testing nào? Ngay sau đây Techacademy sẽ giúp bạn giải đáp những thắc mắc trên đây, cùng tham khảo nhé.

I. Kiểm Thử Chấp Nhận Là Gì

Acceptance Testing (Kiểm thử chấp nhận) là 1 kiểm thử nhằm xác định hệ thống phần mềm có đạt yêu cầu kỹ thuật hay không. Bằng việc đánh giá những hành vi của hệ thống qua dữ liệu thực tế, kiểm thử chấp nhận sẽ xác định có hay không việc hệ thống đáp ứng được các tiêu chí lẫn yêu cầu của khách hàng. Một số kỹ thuật được dùng trong Acceptance Testing đó là phân tích giá trị biên giới, phân vùng tương đương và sử dụng bảng quyết định.

II. Acceptance Testing Sẽ Được Thực Hiện Khi Nào

Đây thường là bước cuối cùng trước khi sản phẩm được đưa ra hoạt động hoặc trước lúc phân phối sản phẩm phải được chấp nhận.

Acceptance Testing được thực hiện sau khi bản thân sản phẩm được kiểm tra kỹ lưỡng (tức là sau khi kiếm thử hệ thống ).

III. Ai Sẽ Thực Hiện Kiểm Thử Chấp Nhận?

• Khách hàng
• Người dùng cuối cùng

IV. Điều Kiện Tiên Quyết Của Acceptance Testing

Điều kiện tiên quyết của kiểm thử chấp nhận là:

• Cần phải bảo đảm những yêu cầu nghiệp vụ quan trọng của ứng dụng hoạt động;
• Phần mềm đã hoàn thiện tốt nhất có thể;
• Các khâu kiểm thử như Unit Testing, Integration Testing và System Testing đều đã hoàn thành;
• Không tồn tại lỗi quan trọng trong hệ thống;
• Lỗi về thẩm mỹ đã được chấp nhận trước kiểm thử chấp nhận;
• Regression Testing phải được hoàn thành, không có lỗi lớn;
• Mọi lỗi đã phát hiện đều phải được sửa, kiểm tra kỹ trước kiểm thử chấp nhận;
• Môi trường Acceptance Test đã được chuẩn bị sẵn sàng;
• Nhà phát triển cần phải chắc chắn rằng hệ thống đã sẵn sàng thực hiện kiểm thử chấp nhận.

V. Các Bước Thực Hiện Acceptance Testing

• Phân tích các yêu cầu nghiệp vụ của phần mềm
• Tạo kế hoạch kiểm tra Acceptance Testing
• Xác định các kịch bản kiểm thử
• Tạo các trường hợp kiểm tra Acceptance Testing
• Chuẩn bị data test (giống với data thật nhất)
• Thực hiện kiểm thử
• Ghi nhận kết quả
• Xác nhận các chức năng của sản phẩm

VI. Một Số Vấn Đề Liên Quan Đến Kiểm Thử Chấp Nhận

Để tăng tỉ lệ thành công của kiểm thử chấp nhận (UAT), ta có thể xem xét các vấn đề sau:

• Chuẩn bị sớm các kế hoạch kiểm thử chấp nhận trong vòng đời của dự án
• Chuẩn bị các checklists đầy đủ trước khi tiến hành kiểm thử chấp nhận
• Thực hiện Pre-UAT trong giai đoạn kiểm thử hệ thống
• Đặt kì vọng và xác định rõ phạm vi của kiểm thử chấp nhận
• Chỉ kiểm thử với vai trò người dùng cuối và không lặp lại quá trình kiểm thử hệ thống
• Kiểm thử với dữ liệu sẽ dùng trong thực tế, không sử dụng dữ liệu giả
• Có tư duy của một người dùng bất kỳ lúc tiến hành kiểm thử
• Cần có quá trình phản hồi trước khi kết thúc kiểm thử chấp nhận và chuyển sang giai đoạn sử dụng thực tế.

The post Acceptance Testing Là Gì ? (Kiểm Thử Chấp Nhận Là Gì ?) first appeared on Techacademy.

source https://techacademy.edu.vn/acceptance-testing-la-gi/

Trong kiểm thử phần mềm, người kiểm thử thực hiện nhiều cấp độ kiểm thử khác nhau. Từ unit testing tới acceptance testing,  bảo đảm rằng tất cả các thành phần của sản phẩm được kiểm tra kỹ lưỡng, không có bất kỳ trở ngại nào. Được thực hiện sau lúc integration testing và trước khi acceptance tests, system test là một trong những cấp độ kiểm thử phần mềm, sẽ được thảo luận chi tiết bên dưới.

I. Kiểm Thử Hệ Thống Là Gì

Kiểm thử hệ thống là 1 cách theo dõi và đánh giá hành vi của sản phẩm hoặc hệ thống phần mềm hoàn chỉnh và đã được tích hợp đầy đủ, dựa vào đặc tả và các yêu cầu chức năng đã được xác định trước. Đó là giải pháp cho câu hỏi “Liệu hệ thống hoàn chỉnh có hoạt động đúng với yêu cầu hay không?”

System test được thử nghiệm trong hộp đen, tức là chỉ có các tính năng làm việc bên ngoài của phần mềm được đánh giá trong quá trình thử nghiệm này. Nó không đòi hỏi bất kỳ kiến thức nội bộ nào về codinh, lập trình, thiết kế, v.v. và hoàn toàn dựa trên quan điểm của người dùng.

II. Đặc Điểm Của System Test

• Trong Vòng đời phát triển phần mềm (SDLC), đây là thử nghiệm thực hiện nhiệm vụ kiểm tra đa số phần mềm hoặc hệ thống.
• Đánh giá chức năng của hệ thống hoàn chỉnh theo yêu cầu chức năng được quyết định trước.
• Cùng với những yêu cầu chức năng, nó cũng xác minh và xác nhận các yêu cầu nghiệp vụ và kiến trúc của phần mềm.
• Staging server có thể hoạt động như một môi trường để thực hiện thử nghiệm.
• Một loại thử nghiệm hộp đen.
• Nó có thể bao gồm, cả thử nghiệm chức năng và phi chức năng.
• Giảm sự cố và bảo trì sau khi triển khai.
• Yêu cầu đội ngũ thử nghiệm độc lập với nhóm phát triển.

III. Khi Nào Thực Hiện System Testing

Như đã nêu trước đó, vòng đời kiểm thử phần mềm bao gồm nhiều cấp độ kiểm thử khác nhau, điều này khiến chúng ta phải hiểu khi nào, trong STLC mà system testing được thực hiện bởi những người kiểm thử. Dưới đây là các tình huống lúc người kiểm thử có thể thực hiện system testing, bằng tay hoặc với sự hỗ trợ của các công cụ kiểm tra.

• Sau lúc hoàn thành unit & integration testing.
• Trước khi bắt đầu acceptance testing
• Sau khi tích hợp hoàn toàn các mô-đun.
• Sau khi hoàn thành quy trình phát triển phần mềm, dựa trên đặc tả yêu cầu phần mềm (SRS).
• Sau khi môi trường thử nghiệm sẵn sàng.

IV. Điều Kiện Tiên Quyết Của System Testing

Dưới đây là một số điều kiện tiên quyết quan trọng của system testing:

• Phải bảo đảm phần mềm được thống nhất kiểm tra.
• Kiểm thử tích hợp đã được thực hiện trên sản phẩm.
• Phần mềm nên được phát triển hoàn chỉnh.
• Trước khi thực hiện quy trình kiểm tra hệ thống, phải đảm bảo rằng môi trường kiểm tra đã sẵn sàng.

V. Các Loại Kiểm Thử Hệ Thống

Dưới đây là danh sách các loại kiểm thử hệ thống mà các công ty phát triển phần mềm lớn thường sử dụng:

1. Kiểm thử khả năng sử dụng – Usability Testing: Kiểm thử khả năng sử dụng chủ yếu tập trung vào việc người dùng dễ dàng dùng ứng dụng, linh hoạt trong việc kiểm soát xử lý và khả năng của hệ thống để đáp ứng những mục tiêu.
2. Kiểm thử tải – Load Testing: Kiểm thử tải là cần thiết để biết rằng 1 phần mềm sẽ thực hiện theo tải thực tế.
3. Kiểm thử hồi quy – Regression Testing: Kiểm thử hồi quy bao gồm kiểm thử được thực hiện để đảm bảo không có sự thay đổi nào phát sinh ra lỗi mới trong quá trình triển phần mềm. Nó cũng bảo đảm không có lỗi cũ xuất hiện từ việc bổ sung các module mới theo thời gian.
4. Kiểm thử phục hồi – Recovery Testing: Kiểm thử phục hồi được thực hiện để chứng minh một giải pháp phần mềm là đáng tin cậy và có thể phục hồi thành công lúc các sự cố xảy ra.
5. Kiểm thử di chuyển – Migration Testing: Kiểm thử di chuyển được thực hiện để đảm bảo rằng phần mềm có thể được chuyển từ cơ sở hạ tầng hệ thống cũ sang cơ sở hạ tầng hệ thống m mà không gặp sự cố nào.
6. Kiểm thử chức năng – Functional Testing: Còn được gọi là kiểm thử tính đầy đủ của chức năng. Tester có thể lập danh sách các chức năng bổ sung mà sản phẩm có thể phải cải thiện trong quá trình kiểm thử chức năng.
7. Kiểm thử phần cứng / phần mềm – Hardware/Software Testing: IBM gọi kiểm thử phần cứng / phần mềm là Kiểm thử CTNH / SW, là khi tester tập trung sự chú ý của mình vào các tương tác giữa phần cứng và phần mềm trong quá trình kiểm thử hệ thống.

VI. Quy Trình Kiểm Thử Hệ Thống

Bước 1: Lên plan test

Bước 2: Phân tích và thiết kế ( Tạo testcase và các bước kiểm tra chi tiết cho mỗi version)

Bước 3: Thực thi test bao gồm thực hiện test và chạy test( chuẩn bị data test, chạy case và so sánh kết quả)

Bước 4: Đánh giá kết quả thực thi và báo cáo kết quả test:

Bước 5: Đóng hoạt động kiểm thử

VII. Ví Dụ Về Kiểm Thử Hệ Thống

Một nhà sản xuất xe hơi thường sẽ không sản xuất toàn bộ chiếc xe. Mỗi thành phần của xe như ghế ngồi, tay lái, gương, cáp, động cơ, khung xe, bánh xe, v.v sẽ.được sản xuất riêng biệt,

Sau khi sản xuất, từng thành phần sẽ được kiểm tra độc lập để xác định xem có hoạt động đúng cách hay không và xác minh này được gọi là Unit testing/kiểm thử Đơn vị.

Bây giờ, với việc một thành phần được ráp với thành phần khác, chúng sẽ được kiểm tra xem nếu việc lắp ráp gây ra bất kỳ tác động nào đến chức năng của từng thành phần và liệu cả hai thành phần này có hoạt động trơn tru cùng với nhau hay không, thì được gọi là kiểm thử tích hợp.

Và khi tất cả các bộ phận được lắp ráp, có phải chiếc xe đã sẵn sàng? Thực ra thì chưa.

Toàn bộ chiếc xe cần được kiểm tra khả năng thỏa mãn theo các yêu cầu cụ thể như: vô lăng điều khiển có mượt mà, phanh xe, bánh xe và các chức năng khác có hoạt động bình thường?, xe liệu vẫn chạy bền bỉ sau 2500 dặm liên tục, màu xe mcos hài hòa, xe có thể lái được trên bất kỳ loại địa hình nào, từ bằng thẳng đến gập ghềnh hay không v.v… Toàn bộ quá trình kiểm tra này được gọi là kiểm thử hệ thống và hoàn toàn tách biệt với kiểm thử tích hợp.

VIII. Sự Khác Biệt Giữa System Testing & Acceptance Testing

The post Kiểm Thử Hệ Thống Là Gì ? (What Is System Testing ?) first appeared on Techacademy.

source https://techacademy.edu.vn/kiem-thu-he-thong-la-gi/

Integration Testing là gì? Tại sao cần phải Integration Testing? Các Phương pháp tiếp cận, chiến lược của Integration Testing…Và để hiểu rõ hơn về loại kiểm thử này Techacademy sẽ giới thiệu với các bạn một chút về Integration Testing.

I. Integration Test Là Gì

• Kiểm thử tích hợp (Integration testing) hay còn gọi là tích hợp và kiểm thử (integration and testing, viết tắt: I&T) là 1 giai đoạn trong kiểm thử phần mềm. Mỗi môđun phần mềm riêng biệt được kết hợp lại và kiểm thử theo nhóm.
• Kiểm thử tích hợp xảy ra sau kiểm thử đơn vị (Unit Test) và trước kiểm thử xác nhận. Kiểm thử tích hợp nhận các môđun đầu vào đã được kiểm thử đơn vị, nhóm chúng vào những tập hợp lớn hơn, áp dụng các ca kiểm thử đã được định nghĩa trong kế hoạch kiểm thử tích hợp vào tập hợp đó, và cung cấp đầu ra cho hệ thống tích hợp.

II. Integration Test Có Mục Tiêu Chính Là Gì

Intergration test có mục đích là cho ra hai ứng dụng tốt nhất, mượt mà nhất mà người dùng cần đến. Từ đó, loại bỏ được các Bug cũng như những nguy cơ có thể xảy ra gây ra lỗi cho hệ điều hành trước khi chuyển đến tay người tiêu dùng. Chắc chắn rằng, bất kỳ hệ điều hành nào cũng mong muốn rằng mình có thể đạt được các chất lượng tốt nhất.

Mà muốn đạt được những điều đó thì buộc bạn phải trải nghiệm qua 3 bài đánh giá vô cùng quan trọng và nó có tên đại diện chính là Integration testing. Đây là một thuật ngữ đã được viết tắt bởi I&T và còn được hiểu là ý nghĩa kiểm thử và trang bị. Integration test là giai đoạn quan trọng không thể thiểu để bảo đảm hiệu quả cho hệ điều hành, trong khi đó thì các mô đun thường sẽ được trang bị phần mềm riêng và được đánh giá dựa theo từng nhóm.

Đây được xem là một trong những quá trình trung gian nằm giữa bài kiểm tra Unit Testing các thủ tục sử dụng cũng như vận hành cho các công ty nguồn hoặc Acceptance test. Đây là một dạng kiểm thử xác nhận, ở đó thì tester và khách hàng sẽ có khả năng kiểm thử tại địa chỉ thiết kế phần mềm rồi đánh giá hầu hết tính năng của phần mềm này sau khi chuyển hướng hoạt động về nền tảng của họ.

III. Tại Sạo Lại Phải Thực Hiện Kiểm Thử Tích Hợp

Mặc dù mỗi module đều được unit test nhưng các lỗi vẫn còn tồn tại với những lý do khác nhau:

• Một Module nói chung được thiết kế bởi một lập trình viên có hiểu biết và logic lập trình có thể khác với các lập trình viên khác.
• Kiểm thử tích hợp là cần thiết để bảo đảm tính hợp nhất của phần mềm.
• Tại thời điểm phát triển module vẫn có thể có đổi thay trong spec của khách hàng, những thay đổi này có thể không được kiểm tra ở giai đoạn unit test trước đó.
• Giao diện và cơ sở dữ liệu của các module có thể chưa hoàn chỉnh lúc được ghép lại
• Khi tích hợp hệ thống các module có thể không tương thích với cấu hình chugn của hệ thống
• Thiếu các xử lý ngoại lệ có thể xảy ra

IV. Ví Dụ Về Kiểm Thử Tích Hợp

Giả sử bạn làm việc cho 1 tổ chức CNTT đã được yêu cầu phát triển trang web mua sắm trực tuyến cho Camp World, một công ty bán dụng cụ cắm trại. Sau khi thu thập yêu cầu, phân tích và thiết kế hoàn tất, một nhà phát triển đã được chỉ định để phát triển từng mô-đun bên dưới.

• Đăng ký và xác thực người dùng / Đăng nhập
• Danh mục sản phẩm
• Giỏ hàng
• Thanh toán
• Tích hợp cổng thanh toán
• Theo dõi vận chuyển và gói hàng

Sau khi mỗi mô-đun được gán cho nhà phát triển, nhà phát triển bắt đầu mã hóa chức năng trên những máy riêng lẻ của họ. Họ đã triển khai các mô-đun tương ứng trên các máy của mình để xem những gì đã hoạt động và những gì đã làm, khi họ bắt đầu phát triển mô-đun.

Sau khi họ hoàn thành việc phát triển, các nhà phát triển đã kiểm tra các chức năng cá nhân của họ như là một phần của kiểm thử đơn vị của họ và tìm thấy một số khiếm khuyết. Họ đã sửa những khuyết điểm này. Tại thời điểm này, họ cảm thấy các mô-đun của họ đã hoàn thành.

Kiểm tra tích hợp nên được thực hiện để xác nhận rằng tất cả các mô-đun hoạt động cùng nhau. Khi họ triển khai tất cả mã của họ trong một máy chung, họ thấy rằng ứng dụng không hoạt động như mong đợi vì các mô-đun riêng lẻ không hoạt động tốt với nhau. Có một số lỗi như – sau khi đăng nhập, giỏ hàng của người dùng không hiển thị các mục họ đã thêm trước đó, số tiền hóa đơn không bao gồm chi phí vận chuyển, v.v.

Theo cách này, Kiểm thử tích hợp giúp chúng ta xác định, khắc phục các sự cố và bảo đảm rằng hầu hết ứng dụng hoạt động như mong đợi.

V. Cách Tiếp Cận, Phương Pháp, Chiến Lược Của Kiểm Thử Tích Hợp

Có 2 cách tiếp cận trong Kiểm thử tích hợp:

+ Cách tiếp cận Big Bang:

+ Cách tiếp cận tăng dần (Incremental), được chia thành các cách sau:

1. Cách tiếp cận từ trên xuống (Top Down)
2. Cách tiếp cận từ dưới lên (Bottom Up)
3. Phương pháp tiếp cận Sandwich – Kết hợp từ trên xuống và từ dưới lên

Dưới đây là các chiến lược, cách thực hiện và những ưu điểm cũng như những nhược điểm của chúng.

Cách tiếp cận Big Bang

Tất cả các thành phần được tích hợp cùng 1 lúc, sau ấy tiến hành kiểm thử.

Ưu điểm:

Thuận tiện cho các hệ thống nhỏ.

Nhược điểm:

• Khó khăn trong việc phát hiện bug.
• Với số lượng giao diện cần được kiểm thử theo phương pháp này, một số giao diện liên kết cần kiểm thử có thể dễ dàng bị bỏ qua.
• Vì kiểm thử Tích hợp chỉ có thể bắt đầu sau khi tất cả các module được thiết kế, nên nhóm kiểm thử sẽ có ít thời gian thực hiện hơn trong giai đoạn kiểm thử.
• Vì tất cả các module được kiểm thử đồng thời, các module quan trọng có rủi ro cao không bị cô lập và được ưu tiên kiểm thử. Các module có liên quan tới giao diện người dùng cũng không bị cô lập và được ưu tiên kiểm thử.

Cách tiếp cận tăng dần

Trong cách này, kiểm thử được thực hiện bằng cách ghép hai hoặc nhiều module có liên quan đến logic. Sau đó, các module liên quan khác được thêm vào và kiểm thử chức năng thích hợp. Quá trình tiếp tục cho đến khi tất cả các module được thêm và hoàn thành quá trình kiểm thử.

Cách tiếp cận tăng dần được thực hiện bởi hai Phương pháp khác nhau:

• Từ dưới lên (Bottom Up)
• Từ trên xuống (Top Down)

Stub và Driver là gì?

Phương pháp tiếp cận tăng dần được thực hiện bằng cách sử dụng các chương trình giả lập là Stub và Driver. Stub và Driver không thực hiện toàn bộ logic của module mà chỉ mô phỏng kết nối dữ liệu với module đang được gọi.

Stub: Được gọi bởi module đang kiểm thử.

Driver: Gọi module để được kiểm thử.

Tích hợp từ dưới lên

Trong cách tích hợp từ dưới lên, mỗi module ở các cấp thấp hơn được kiểm thử với các module cao hơn cho đến khi tất cả các module được kiểm thử. Tích hợp từ dưới lên cần sự hỗ trợ của Driver để kiểm thử

Sơ đồ biểu diễn cách tiếp cận từ dưới lên:

Ưu điểm:

• Việc phát hiện lỗi dễ dàng hơn.
• Không bị lãng phí thời gian chờ đợi tất cả các module được xây dựng, không giống như phương pháp Big-bang

Nhược điểm:

• Các module quan trọng (ở cấp cao nhất của kiến ​​trúc phần mềm) có luồng điều khiển được kiểm thử lần cuối nên dễ bị sót lỗi.
• Thực hiện kiểm thử tích hợp từ dưới lên từ sớm là không thể

Tích hợp từ trên xuống

Trong cách tiếp cận từ trên xuống, kiểm thử diễn ra từ trên xuống dưới theo luồng điều khiển của hệ thống phần mềm. Cần sự hỗ trợ của Stub để kiểm thử.

Sơ đồ biểu diễn cách tiếp cận từ trên xuống:

Ưu điểm:

• Việc phát hiện lỗi dễ dàng hơn.
• Có khả năng thực hiện tích hợp từ trên xuống từ sớm.
• Các module quan trọng được ưu tiên kiểm thử; lỗi thiết kế quan trọng có thể được tìm thấy và sửa chữa đầu tiên.

Nhược điểm:

• Cần nhiều Stub.
• Các module ở mức thấp hơn không được kiểm thử đầy đủ.

Tích hợp Hybrid/ Sandwich

Chiến lược sandwich / hybrid là sự kết hợp của phương pháp Top Down và Bottom up. Các module trên cùng được kiểm thử cùng thời điểm với các module thấp hơn, đồng thời các module thấp hơn được tích hợp với các module ở trên và được thực hiện kiểm thử. Chiến lược này sử dụng Stubs cũng như Drivers.

VI. Sự Khác Nhau Giữa Integration Test Và System Test

The post Integration Testing Là Gì (Kiểm Thử Tích Hợp Là Gì ?) first appeared on Techacademy.

source https://techacademy.edu.vn/integration-testing-la-gi/

Bất kỳ 1 sản phẩm phần mềm nào cũng chắc chắn có lỗi, vì sản phẩm phầm mềm do con người xây dựng nên, dù có cẩn trọng, có giỏi đến mức nào thì cũng không thể bảo đảm sản phẩm mình tạo ra là không có lỗi. Do đó, sẽ cần 1 người, nhóm hoặc tổ chức độc lập kiểm thử xem sản phẩm đó có vấn đề hay có lỗi gì hay không.

Để kiểm thử phần mềm thì chúng ta cần phải có kế hoạch, chiến lược kiểm thử cũng như các kỹ thuật các phương pháp kỹ thuật hiệu quả cho mỗi mức độ kiểm thử. Kiểm thử phần mềm gồm hai phần việc đòi hỏi những kỹ năng khác nhau đó là kiểm thử hộp trắng (white-box testing) và kiểm thử hộp đen (black-box testing).

Trong đề tài này, tôi sẽ đi sâu vào tìm hiểu kiểm thử hộp trắng. Để hiểu rõ hơn về kỹ thuật kiểm thử hộp trắng (White-box testing) thì chúng ta lần lượt tìm hiểu các nội dung dưới đây:

I. Kiểm Thử Hộp Trắng Là Gì

Kiểm thử Hộp Trắng (còn gọi là Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing hoặc Structural Testing) là 1 phương pháp kiểm thử phần mềm trong đó tester biết về cấu trúc nội bộ / thiết kế. Người kiểm tra chọn đầu vào để thực hiện các đường dẫn thông qua mã và xác định đầu ra thích hợp. Kiến thức lập trình và kiến thức thực hiện là rất cần thiết trong kiểm thử hộp trắng.

Kiểm thử hộp trắng bao gồm phân tích dòng dữ liệu, điều khiển dòng, dòng thông tin, mã thực hành, ngoại lệ và những lỗi trình bày trong hệ thống để đánh giá những hành động của phần mềm không được định hướng trước.

II. Các Phương Pháp Kiểm Thử Hộp Trắng

+ Kiểm thử đường cơ bản – Đồ thị dòng

• Là một kỹ thuật dùng trong kiểm thử hộp trắng được Tom McCabe đưa ra đầu tiên. Đồ thị dòng gần giống đồ thị luồng điều khiển của chương trình.
• Là một trong nhiều phương pháp miêu tả thuật giải. Đây là phương pháp trực quan cho chúng ta thấy dễ dàng các thành phần của thuật giải và mối quan
• hệ trong việc thực hiện các thành phần này.
• Kỹ thuật đường cơ bản – đồ thị dòng có thể giúp những người thiết kế ca kiểm thử nhận được một độ phức tạp của 1 logic thủ tục.
• Gồm 2 loại thành phần : các nút và các cung nối kết giữa chúng.
• Các loại nút trong đồ thị dòng điều khiển :

• Các kiểu cấu trúc thành phần đồ thị dòng :

• Thí dụ :

• Nếu đồ thị dòng điều khiển chỉ chứa các nút quyết định nhị phân thì ta gọi nó là đồ thị dòng điều khiển nhị phân. Ta luôn có thể chi tiết hóa 1 đồ thị dòng điều khiển bất kỳ thành đồ thị dòng điều khiển nhị phân.

• Độ phức tạp Cyclomatic C Độ phức tạp Cyclomatic C = V(G) của ₫ồ thị dòng ₫iều khiển ₫ược tính bởi 1 trong các công thức sau : ƒ V(G) = E – N + 2, trong ₫ó E là số cung, N là số nút của ₫ồ thị. ƒ V(G) = P + 1, nếu là ₫ồ thị dòng ₫iều khiển nhị phân (chỉ chứa các nút quyết ₫ịnh luận lý – chỉ có 2 cung xuất True/False) và P số nút quyết ₫ịnh. Độ phức tạp Cyclomatic C chính là số ₫ường thi hành tuyến tính ₫ộc lập của TPPM cần kiểm thử.

+ Kiểm thử dựa trên luồng điều khiển

• Đường thi hành (Execution path) : là 1 kịch bản thi hành đơn vị phần mềm tương ứng, cụ thể nó là danh sách có thứ tự các lệnh được thi hành ứng với 1 lần chạy cụ thể của đơn vị phần mềm, bắt đầu từ điểm nhập của đơn vị phần mềm đến điểm kết thúc của đơn vị phần mềm.
• Mỗi TPPM có từ 1 đến n (có thể rất lớn) đường thi hành khác nhau.
• Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọi đường thi hành của ₫ơn vị phần mềm cần kiểm thử đều chạy đúng. Rất tiếc trong thực tế, công sức và thời gian để đạt mụctiêu trên đây là rất lớn, ngay cả trên những đơn vị phần mềm nhỏ.
• Thí dụ ₫oạn code sau : for (i=1; i<=1000; i++) for (j=1; j<=1000; j++) for (k=1; k<=1000; k++) doSomethingWith(i,j,k); chỉ có 1 đường thi hành, nhưng rất dài : dài 100010001000 = 1 tỉ lệnh gọi hàm doSomething(i,j,k) khác nhau.
• Còn đoạn code gồm 32 lệnh if else độc lập sau : if (c1) s11 else s12; if (c2) s21 else s22; if (c3) s31 else s32; … if (c32) s321 else s322; có 2^32 = 4 tỉ đường thi hành khác nhau.
• Mà cho dù có kiểm thử hết được toàn bộ các đường thi hành thì vẫn không thể phát hiện những đường thi hành cần có nhưng không (chưa) được hiện thực : if (a>0) doIsGreater(); if (a==0) dolsEqual(); // thiếu việc xử lý trường hợp a < 0 – if (a<0) dolsLess();
• Một ₫ường thi hành đã kiểm tra là đúng nhưng vẫn có thể bị lỗi khi dùng thật (trong 1 vài trường hợp đặc biệt) : int phanso (int a, int b) { return a/b; } khi kiểm tra, ta chọn b <> 0 thì chạy đúng, nhưng khi dùng thật trong trường hợp b = 0 thì hàm phân số bị lỗi.

III. Những Kỹ Thuật Kiểm Thử Hộp Trắng

Khi thực hiện kiểm thử bằng whitebox testing thì ta phải có một bộ test cho chương trình đó. Tuy nhiên làm sao để biết chắc chắn được là bộ test của chúng ta đã đầy đủ cho tất cả các trường hợp hay chưa? Lúc này ta sẽ áp dụng các kiến thức của coverage tesing để đo đạc kết quả của chương trình khi thực hiện bộ kiểm thử.

Coverage testing có thể hiểu nôm na là tỉ lệ (tính theo %) test case đã được thực hiện trên tổng số test case cần thiết cho ứng dụng. Nếu tỉ lệ này càng cao thì ứng dụng càng được test kỹ. Mặc dù việc đảm bảo ứng dụng có test coverage là 100% trong một số trường hợp là bất khả thi, nhưng ta vẫn sẽ luôn cố gắng để đạt được kết quả gần với con số đó nhất.

Có 3 kĩ thuật

• Bao phủ câu lệnh(Statement Coverage): Kiểm thử sao cho mỗi câu lệnh được thực thi ít nhất 1 lần. Ví dụ đọan mã:

Public int foo(int x, int y) Int z = 0; If (x > 0 && y > 0) { z = x; } Return z; }

Nếu ta gọi foo(1,1) thì dòng z = x sẽ được thực hiện, còn nếu gọi foo(0,1) thì dòng z = x sẽ không được thực hiện, lúc đó test case của ta sẽ không thỏa điều kiện bao phủ câu lệnh.

• Bao phủ điều kiện(Branch Coverage, Decision coverage): Kiểm thử đòi hỏi phải đủ trường hợp thử nghiệm như vậy mà mỗi điều kiện trong một quyết định có trên tất cả các kết quả có thể ít nhất một lần. Đó là các nhánh (quyết định) lấy cả 2 trường hợp đúng và sai. Nó giúp trong việc chứng thực tất cả các ngành có mã đảm bảo rằng đó không có chi nhánh dẫn đến hành vi bất thường của ứng dụng. Ví dụ đoạn mã:

Ta có thể sinh các test case bao phủ các điều kiện của nhánh:

• Bao phủ nhánh(Path Coverage): Trong các trường hợp kiểm thử được thực hiện trong một cách mà mọi con đường được thực hiện ít nhất một lần. Tất cả các con đường kiểm soát có thể được thực hiện, bao gồm tất cả những con đường vòng lấy bằng không, một lần, và nhiều (lý tưởng là tối đa) các trường hợp thử nghiệm được chuẩn bị dựa trên các biện pháp phức tạp logic của một thiết kế thủ tục. Để hoàn thiện bao phủ nhánh, chúng ta phải xét thêm 2 trường hợp bug(a) khi đúng và khi sai.

IV. Khác Nhau Giữa Kiểm Thử Hộp Trắng Và Hộp Đen

The post Kiểm Thử Hộp Trắng Là Gì ? (What Is White-box Testing ?) first appeared on Techacademy.

source https://techacademy.edu.vn/kiem-thu-hop-trang-la-gi/

Trong lĩnh vực khoa học công nghệ, điện toán và kỹ thuật thì hộp đen được hiểu là một thiết bị, hệ thống hoặc là đối tượng được xem xét theo các yếu tố đầu vào và đầu ra của nó. Không có bất cứ kiến thức nào về hoạt động bên trong của nó. Để có thể hiểu chi tiết hơn về Black Box là gì và Black Box Testing là gì, cùng chúng tôi lý giải ở bài viết dưới đây nhé!

I. Kiểm Thử Hộp Đen Là Gì

Kiểm thử hộp đen: là 1 phương pháp kiểm thử phần mềm được thực hiện mà không biết được cấu tạo bên trong của phần mềm, là cách mà các tester kiểm tra xem hệ thống như một chiếc hộp đen, không có cách nào nhìn thấy bên trong của cái hộp.

• Nó còn được gọi là kiểm thử hướng dữ liệu hay là kiểm thử hướng in/out.
• Người kiểm thử nên xây dựng những nhóm giá trị đầu vào mà sẽ thực thi hầu hết đa số các yêu cầu chức năng của chương trình.
• Cách tiếp cận của những tester đối với hệ thống là không dùng bất kỳ một kiến thức về cấu trúc lập trình bên trong hệ thống, xem hệ thống là 1 cấu trúc hoàn chỉnh, không thể can thiệp vào bên trong.

Black Box Testing chủ yếu là được thực hiện trong Function test và System test.

Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm, trong con mắt của các tester, giống như một hộp đen; bên trong mà người ta không thể nhìn thấy. Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:

• Chức năng không chính xác hoặc thiếu.
• Lỗi giao diện.
• Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài.
• Hành vi hoặc hiệu suất lỗi.
• Khởi tạo và chấm dứt các lỗi.

Mọi kỹ thuật nào cũng có ưu điểm và nhược điểm của nó. Các hệ thống thường phải được sử dụng nhiều phương pháp kiểm thử khác nhau để bảo đảm được chất lượng của hệ thống khi đến tay người dùng.

II. Cách Kiểm Thử Hộp Đen

Khi thực hiện kỹ thuật kiểm thử này, tester không cần quan tâm bên trong hệ thống hoạt động ra sao, không cần hiểu source code thế nào. Thông thường, trong lúc thực hiện kiểm thử hộp đen, tester sẽ tương tác với giao diện người dùng của hệ thống bằng cách cung cấp đầu vào và kiểm tra kết quả đầu ra mà không cần biết cách thức làm việc bên trong của hệ thống.
Bảng sau đây liệt kê các ưu điểm và nhược điểm của kiểm thử hộp đen:

III. Khác Nhau Giữa Kiểm Thử Hộp Đen Và Hộp Trắng

IV. Ví Dụ Kiểm Thử Hộp Đen

Cho 1 ô test box nhập vào giá trị nguyên từ 1 đến 100

Giải thích:

Áp dụng phân tích giá trị biên vào cho bài toán sẽ có 2 cách lấy giá trí biên là 2 biên và 3 biên.

+ Trường hợp 2 biên (nghĩa là tại mỗi giá trị biên sẽ lấy 2 giá trị) và sẽ có các biên:

• Tại min: min -1, min
• Tại max: max, max + 1

Vậy áp dụng cho bài toán ta có các giá trị biên như sau: 0;1;100;101

+ Trường hợp 3 biên (nghĩa là tại mỗi giá trị ta sẽ lấy 3 giá trị) ta sẽ có các biên:

• Tại min: min -1, min , min + 1
• Tại max: max – 1, max, max + 1

Vậy áp dụng cho bài toán ta có các giá trị biên như sau: 0;1;2;99;100;101

Chú ý: Thường thì sẽ sử dụng kết hợp 2 kỹ thuật phân vùng tương đương và phân tích giá trị biên cùng với nhau để cho bài toán không bị thiếu case hoặc dư thừa case. Với bài toán trên áp dụng cả phân vùng tương đương và giá trị biên thì cần test các case:

• Case hợp lệ: 1;50;100
• Case không hợp lệ: 0;101

The post Kiểm Thử Hộp Đen Là Gì ? (What Is Black-box Testing ?) first appeared on Techacademy.

source https://techacademy.edu.vn/kiem-thu-hop-den-la-gi/

Kiểm thử phần mềm là quá trình vận hành một chương trình nhằm tìm ra lỗi của nó. Để phần mềm hoạt động trơn tru, nó cần phải sạch lỗi. Và nếu kiểm thử phần mềm được thực hiện thành công, việc này sẽ khiến các lỗi không còn xuất hiện. Tuy nhiên, để tiết kiệm thời gian và công sức truy tìm các lỗi, có 7 nguyên tắc kiểm thử quan trọng mà bạn cần tuân theo.

I. 7 Nguyên Tắc Kiểm Thử Phần Mềm

Dưới đây là 7 nguyên tắc Kiểm thử phần mềm đó:

• Kiểm thử chứng minh sự hiện diện của lỗi
• Kiểm thử toàn bộ là không khả thi
• Kiểm thử càng sớm càng tốt
• Lỗi thường phân bổ tập trung
• Nghịch lý thuốc trừ sâu
• Kiểm thử phụ thuộc vào ngữ cảnh
• Quan niệm sai lầm về việc “hết lỗi”

Hãy cùng Techacademy tìm hiểu kỹ hơn 7 nguyên tắc kiểm thử này nhé:

+ Kiểm thử phần mềm chứng minh sự hiện diện của lỗi

Bằng việc kiểm thử, chúng ta có thể làm giảm lượng bugs lúc áp dụng nhiều cách kiểm thử lên phần mềm. Tuy nhiên lúc được đưa lên môi trường thật, người sử dụng cuối hoàn toàn có thể thấy nhiều lỗi khác không tìm thấy trong quá trình kiểm thử. Kiểm thử chứng minh được sản phẩm có lỗi nhưng không thể chứng minh rằng sản phẩm không còn lỗi.

Điều này có nghĩa là, sẽ luôn có lỗi không được phát hiện trong phần mềm, ngay cả khi không tìm thấy lỗi, cũng không đồng nghĩa rằng phần mềm đúng hoàn toàn.

+ Kiểm thử toàn bộ là không khả thi

Đúng vậy, rất khó để kiểm tra hầu hết các module cũng như những tính năng, kết hợp với đầu vào và đầu ra trong suốt quá trình kiểm tra. Các sản phẩm phần mềm hiện nay cực kỳ đa dạng và phức tạp, được phát triển trên nhiều nền tảng, thêm vào đó, ngày càng có nhiều công nghệ mới, khả năng kết nối dữ liệu lớn… khiến việc kiểm thử toàn bộ gần như là không thể.

Thay vì cố gắng kiểm thử toàn bộ, hãy xác định mức độ quan trọng và độ ưu tiên của các module để kiểm thử những phần cần thiết hoặc gặp nhiều nguy cơ hơn.

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

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àng sớm càng tốt trong vòng đời phát triển phần mềm. Vậy ở bước nào thì được coi là sớm? Nguyên tắc này cho thấy ta cần phát hiện bug ngay từ các bước đầu tiên như nghiên cứu yêu cầu (requirement) hay design.

Phát hiện lỗi càng muộn, chi phí bỏ ra để xử lý càng cao. Vì vậy, việcthay đổi yêu cầu không đúng từ sớm sẽ khiến tốn ít chi phí để thay đổi tính năng hơn.

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

Nguyên lý về phân bố lỗi chỉ ra rằng, chỉ một số ít module chứa phần lớn số lỗi phát hiện được. Những module này thường là những thành phần, chức năng chính của hệ thống. Điều này cũng đúng theo nguyên lý Pareto: 80 – 20: 80% số lỗi tìm thấy ở chỉ 20% module. Bằng kinh nghiệm, các QA/ Tester có thể xác định được những module có tính rủi ro và nhiều lỗi như vậy, giúp tập trung tìm kiếm lỗi nhanh và hiệu quả hơn.

Tuy nhiên, cách tiếp cận này cũng ẩn chứa vấn đề: nếu thực hiện kiểm thử tương tự lặp đi lặp lại, dễ thấy rằng những test case cũ sẽ khó tìm thêm được bug mới.

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

Trong trồng trọt, nếu người nông dân sử dụng lặp lại một liều trừ sâu, các loại sâu bệnh sẽ dần dần thích nghi và trở nên “nhờn” với loại thuốc trừ sâu đó. Tương tự với kiểm thử phần mềm, khi lặp đi lặp lại một test case, thì xác suất tìm được lỗi là rất thấp. Nguyên nhân là hệ thống hoàn thiện hơn, lỗi tìm thấy đã được sửa theo test case cũ. Để xử lý hiệu ứng “thuốc trừ sâu” này, test case cần được thường xuyên xem lại và chỉnh sửa, thêm nhiều test case mới để tìm lỗi mới (regression test).

Thêm vào đó, QA/ Tester cũng không nên phụ thuộc quá nhiều vào các kỹ thuật test sẵn có. Bạn cần liên tục cải tiến các phương pháp có sẵn để làm việc kiểm thử hiệu quả hơn.

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

Kiểm thử phụ thuộc vào ngữ cảnh, nói một cách đơn giản, là việc kiểm thử một trang thương mại điện tử sẽ phải khác cách test một ứng dụng đọc tin tức. Tất cả các phần mềm đều được phát triển theo cách khác nhau. Và việc áp dụng chung một “cách giải” là sai lầm. Bạn cần sử dụng cách tiếp cận khác nhau, phương thức, kỹ thuật test khác nhau, loại test phụ thuộc vào loại phần mềm/ ứng dụng/ website.

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

Một phần mềm sạch bug 99% vẫn có thể không sử dụng được. Đây là trường hợp phần mềm được kiểm thử bằng một requirement sai. Kiểm thử không chỉ để tìm ra lỗi, mà còn để kiểm tra xem phần mềm có đáp ứng được đúng nhu cầu hay không. Chính vì vậy, việc Không còn lỗi hay Hết lỗi là quan niệm sai lầm.

Quan điểm: “Nguyên tắc kiểm thử chỉ là để tham khảo, không có tính ứng dụng thực tế”?

Đây là quan điểm cực kỳ sai lầm. Các nguyên tắc kiểm thử giúp tạo ra một chiến lược kiểm thử rõ ràng và tạo ra những trường hợp kiểm thử sát sao, dễ bắt được bug. Những tester dày dạn kinh nghiệm áp dụng những nguyên tắc kiểm thử nhuần nhuyễn đến độ họ không nghĩ rằng họ đang áp dụng chúng. Vì vậy, việc nguyên tắc kiểm thử không có tính ứng dụng thực tế là sai lầm.

II. Quy Trình Kiểm Thử Phần Mềm

Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm, phát hiện các lỗi của phần mềm

Kiểm thử phần mềm bảo đảm sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra.

Kiểm thử phần mềm cho bạn cơ hội dùng khả năng sáng tạo, phân tích để tìm ra những thứ mà người khác không thấy được. Bạn phải có cách nghĩ khác về những việc và các tình huống mà người khác ko nghĩ ra vì trường hợp các bug dễ nhìn thấy thì nó đã không tồn tại.

Kiểm thử thực chất là 1 quy trình hơn là một hoạt động đơn lẻ. Quá trình này bắt đầu từ việc lập kế hoạch kiểm thử, sau đó là thiết kế các trường hợp kiểm thử, chuẩn bị cho việc thực thi và đánh giá kết quả thực thi cho đến lúc kết thúc hoạt động kiểm thử.

Về cơ bản thì gồm các bước sau đây:

1. Lập kế hoạch và kiểm soát việc kiểm thử
2. Phân tích yêu cầu và Thiết kế testcase
3. Thực thi – Chạy test
4. Đánh giá tiêu chí dừng test và làm Báo cáo
5. Đóng hoạt động kiểm thử

+ Lập kế hoạch và kiểm soát việc kiểm thử

Lập kế hoạch kiểm thử theo các bước quan trong sau:

– Xác định scope, risk và mục đích của hoạt động kiểm thử

– Xác định các tiếp cận kiểm thử

– Xác định quy định kiểm thử hoặc chiến lượng kiểm thử

– Xác định yêu cầu về nguồn nhân lực như con người, môi trường kiểm thử, thiết bị,…

– Lên lịch trình cho việc phân tích kiểm thử và thiết kế các trường hợp kiểm thử, thực thi kiểm thử và đánh giá kết quả kiểm thử.

– Xác định các tiêu chí kết thúc việc kiểm thử

+ Phân tích yêu cầu và Thiết kế testcase

Hoạt động phân tích và thiết kế kiểm thử có các nhiệm vụ chủ yếu sau đây:

• Rà soát các yêu cầu cần thiết trước khi tiến hành kiểm thử như tài liệu đặc tả, tài liệu thiết kế, tài liệu giao diện, v.v
• Xác định các điều kiện kiểm thử
• Thiết kế test case
• Đánh giá tính khả thi trong việc kiểm thử của yêu cầu cũng như của hệ thống.
• Chuẩn bị môi trường test cũng như xác định các yêu cầu về cơ sở hạ tầng và các công cụ kiểm thử tương ứng.

+ Thực thi – Chạy test

Hoạt động chạy test có nhiệm vụ chủ yếu sau đây:

• Sử dụng các kĩ thuật kiểm thử và tạo các dữ liệu kiểm thử để phát triển và đưa ra độ ưu tiên các trường hợp kiểm thử
• Tạo test suites từ các trường hợp kiểm thử để thực hiện kiểm thử hiệu quả.
• Thực hiện và xác minh môi trường
• Hoạt động chạy test có nhiệm vụ chủ yếu sau đây:
• Thực thi test suites và trường hợp kiểm thử riêng lẻ theo các phương thức kiểm thử
• Chạy lại các case bị failed trước đó để xác nhận là case đó đã được sửa
• So sánh kết quả ghi nhận được khi thực thi với kết quả mong đợi
• Đánh giá kết quả kiểm thử (Passed/Failed) cho các trường hợp kiểm thử
• Viết báo cáo lỗi cho những trường hợp kết quả ghi nhận được và kết quả mong đợi không giống nhau

+ Đánh giá tiêu chí dừng test và làm Báo cáo

Dựa trên đánh giá rủi ro của dự án, chúng ta sẽ thiết lập các tiêu chí cho từng hoạt động kiểm thử tương ứng để từ đó có thể xác định được liệu kiểm thử đã đủ hay chư.Những tiêu chí này khác nhau tùy từng dự án và được gọi tiêu chí kết thúc kiểm thử (exit criteria). Các tiêu chí này bao gồm:

1. Số lượng test case tối đa được thực thi Passed
2. Tỷ lệ lỗi giảm xuống dưới mức nhất định
3. Khi đến deadline
4. Đóng hoạt động kiểm thử

Các hoạt động kiểm thử thường chỉ được kết thúc khi các phần mềm được bàn giao cho khách hàng. Ngoài ra, hoạt động kiểm thử có thể kết thức trong các trường hợp sau:

• Khi tất cả các thông tin đã được thu thập đầy đủ cho hoạt động kiểm thử
• Khi 1 dự án bị hủy bỏ
• Khi các mục tiêu chính đã hoàn thành
• Khi việc bảo trì hoặc cập nhật đã hoàn thành.

III. Các Loại Kiểm Thử Phần Mềm

“Kiểm thử”- chỉ 2 từ nhưng nó thực ra rất rộng lớn và phức tạp. Tùy theo nhu cầu và mục đích cụ thể, chúng ta sẽ có những loại kiểm thử khác nhau. Trong bài viết này các bạn sẽ hiểu được các loại kiểm thử phần mềm, mục đích sử dụng của từng loại cũng như giá trị của chúng.

+ Kiểm thử cài đặt (Installation testing)

Kiểm thử cài đặt, như tên gọi của nó, thường sẽ xoay quanh việc cài đặt, tháo gỡ các ứng dụng trên các môi trường khác nhau.

Kiểm thử cài đặt đóng vai trò vô cùng quan trọng. Vì sao? Vì nếu sản phẩm của bạn cần phải cài đặt để có thể hoạt động và giả sử người dùng không thể cài đặt (hay có lỗi ở phần cài đặt) thì hậu quả là….chẳng ai sử dụng được sản phẩm của bạn.

Khi nào sử dụng kiểm thử cài đặt?

Bạn nên bắt đầu hoạt động kiểm thử cài đặt càng sớm càng tốt và trường hợp sản phẩm của bạn cần phải cài đặt thì bạn nên tập trung nhiều vào phần này.

Các câu hỏi trong lúc kiểm thử cài đặt:

• Ứng dụng có thể cài đặt thành công trên [bạn điền môi trường test của bạn như PC (Windows, Linux), Mobile (Android, iOS)]?
• Các bước cài đặt/tháo dỡ có dễ dàng tường minh hay không?
• Sản phẩm có thể cài đặt tháo dỡ thành công trên [bạn điền môi trường test của bạn như PC (Windows, Linux), Mobile (Android, iOS)]?
• Sản phẩm có thể cài đặt trên những thư mục khác nhau không?
• Sản phẩm sau khi tháo gỡ còn sót file hoặc folder nào không?
• Sản phẩnm có thể cài đặt từ CD/DVD?
• Người dùng có thể cập nhật, nâng cấp ứng dụng đã cài đặt?

+ Kiểm thử “khói” (Smoke test)

Thuật ngữ smoke test được bắt đầu trong ngành điện tử, phần cứng. Đây là hoạt động kiểm thử đầu tiên cần phải thực hiện lúc kỹ sư bật công tắc hay cắm nguồn điện để xem….có “khói bốc lên cao hay không”. Nếu không có khói (nghĩa là sản phẩm ok để test tiếp), nếu có khói (sản phẩm đã chết) thì buộc phải sửa ngay tức khắc.

Tương tự, trong phát triển phần mềm thì smoke test là loại test nhằm đánh giá xem sản phẩm, build được xây dựng bởi dev có lỗi gì nghiêm trọng hay không để có thể tiếp tục các hoạt động khác.

Loại kiểm thử này chỉ nhằm mục đích đánh giá sơ khởi xem build nhận được có ok để test tiếp hay không. Lí do ta phải sử dụng smoke test là việc phát hiện sớm những lỗi quan trọng sẽ giúp tránh lãng phí khi chúng ta dành thời gian cho những hoạt đông kiểm thử khác.

Smoke test (một số nơi có thể gọi là sanity test, build validation test, build acceptance test) thường là một bộ kiểm thử đơn giản và chứa một số các test case cơ bản đi qua những tính năng quan trọng nhất của sản phẩm. Khi bạn làm việc với sản phẩm bạn sẽ phải biết được những tính năng nào là quan trọng nhất (nghĩa là những tính năng này là giá trị gốc, là sống còn đối với sản phẩm hoặc công ty). Nếu bạn vẫn chưa biết thì tốt nhất là tìm hiểu hoặc hỏi ngay.

Khi nào nên sử dụng kiểm thử “khói”?

Khi dev giao build cho đội test thì việc trước tiên là thực thi bộ smoke test này. Bộ smoke test thường nhỏ nên bạn sẽ thường mất khoảng 1-2 giờ để thực thi. Nếu build fail, bạn báo ngay cho sếp, developer hoặc các bên liên quan để đánh giá tình hình. Trả build về và không nên test tiếp những tính năng khác.

+ Kiểm thử tương thích (Compatability test)

Đây là kiểu kiểm thử nhằm mục đích đánh giá sự tương thích giữa ứng dụng với các môi trường, nền tảng khác nhau. Loại kiểm thử này quan trọng vì ngày nay ngày càng xuất hiện nhiều nền tảng công nghệ, hệ điều hành, trình duyệt khác nhau và người dùng luôn mong đợi sản phẩm của họ phải hoạt động tốt trên các môi trường khác nhau này.

Các hoạt động kiểm thử tương thích thường áp dụng cho:

• Các trình duyệt web khác nhau như Chrome, FireFox, Safari và các version khác nhau của từng loại
• Các hệ điều hành khác nhau như Windows, Linux, Mac OS và các version khác nhau của từng loại
• Các nền tảng khác nhau như PC, Mobile, Desktop, Laptop

Dĩ nhiên, tùy theo đặc thù của ứng dụng mà có những loại kiểm thử tương thích cụ thể như kiểm thử tương thích cho các mạng viễn thông khác nhau, kiểm thử tương thích cho các ngôn ngữ chuyển đổi, kiểm thử tương thích cho loại người dùng khác nhau, v.v. Lời khuyên là bạn hãy tìm hiểu về người dùng cuối của sản phẩm như thị hiếu, thói quen, môi trường để từ đó xác định loại kiểm thử tương thích tương ứng.

Tuy nhiên, kiểm thử tương thích cũng có những khó khăn riêng của nó trong đó nổi bật là 2 khó khăn sau:

• Chuẩn bị cho môi trường test: Việc phải kiểm thử trên nhiều môi trường test khác nhau sẽ khiến việc chuẩn bị, setup gặp nhiều khó khăn về mặt chi phí, thời gian, kỹ thuật. Giải pháp là có thể sử dụng máy ảo để hỗ trợ việc chuẩn bị môi trường nhanh hơn hoặc các dịch vụ cung cấp các browser có sẵn.
• Độ bao phủ kiểm thử rất rất lớn. Giả sử bạn có 500 test case cần phải thực thi và bạn phải chạy 500 test case này trên các trình duyệt Chrome, FireFox, Safari, IE và mỗi trình duyệt lại có những version khác nhau. Bạn tự nhân và có thể thấy khối lượng test case cần phải chạy là “khổng lồ”. Giải pháp là giảm số lượng môi trường test hoặc tăng nguồn nhân lực hoặc cũng có thể tự động hóa bộ kiểm thử để giảm thời gian thực thi.

+ Kiểm thử hồi quy (Regression test)

Đây có thể được coi là loại test phổ biến nhất và hầu hết tester đều biết qua loại test này.

Kiểm thử hồi qui nhằm mục đích kiểm tra xem những thay đổi trong một build ở một tính năng (như thêm mới tính năng, thay đổi một tính năng, sửa lỗi) không làm ảnh hưởng đến những tính năng khác hay tạo thêm lỗi mới.

Loại kiểm thử này quan trọng và gần như là không thể thiếu trong hoạt động kiểm thử vì chúng ta không thể (hoặc khó) đoán được liệu những thay đổi dù là nhỏ nhất có thể ảnh hưởng đến những module khác hay không. Dĩ nhiên một số thay đổi có thể đoán được, một số thay đổi thì không. Do đó việc chạy hồi qui được coi là giải pháp an toàn nhất.

Kiểm thử hồi qui được thực thi như sau:

Giả sử bạn có 1000 test case cho toàn bộ sản phẩm của bạn, sau khi developer đưa ra 1 build mới, bạn phải thực thi toàn bộ 1000 test case này trên buiild mới và cứ mỗi lần ra build mới bạn sẽ phải thực thi lại 1000 test case này.

Những khó khăn thường gặp phải đối với loại kiểm thử này? Do phải thực thi với số lượng lớn test case sau mỗi đợt build nên kiểm thử hồi qui thường tốn kém (thời gian, nhân lực) và “boring”. Giải pháp cho vấn đề này thường thì kiểm thử hồi qui được tự động hóa để tăng độ bao phủ hay có thể giảm số lượng trường hợp kiểm thử (chỉ chọn những trường hợp quan trọng) hoặc có thể tăng nhân lực. Còn tùy những điều kiện khác nhau sẽ quyết định giải pháp nào là phù hợp.

+ Kiểm thử nghiệm thu (Acceptance test)

Kiểm thử nghiệm thu là loại kiểm thử được thực hiện bởi khách hàng hay chủ sản phẩm để đánh giá chất lượng của sản phẩm liệu xem có chấp nhận sản phẩm hay không. Loại kiểm thử này thường thấy ở các dự án outsource.

Bộ kiểm thử nghiệm thu thường chứa những test case cơ bản quan trọng của sản phẩm và thường được thực thi độc lập bởi khách hàng hoặc một bên thứ 3. Trong thực tế, một số dự án thì kiểm thử nghiệm thu cũng thường được sử dụng như là kiểm thử smoke test để đánh giá build từ developer để xem có chấp nhận để có thể test tiếp hay không.

+ Kiểm thử hiệu năng

Kiểm thử hiệu năng là một loại hình kiểm thử nhằm đánh giá khả năng hoạt động của hệ thống cũng như độ ổn định của hệ thống. Có 2 loại test cơ bản trong kiểm thử hiệu năng:

• Stress test: Là một dạng của kiểm thử hiệu năng trong đó hệ thống được đẩy lên ngưỡng cao nhất đến khi nào hệ thống “die” thì thôi. Mục đích là tìm được ngưỡng của hệ thống.
• Load test: Kiểm thử chịu tải là loại kiểm thử nhằm đánh giá xem liệu hệ thống có thể hoat động khi hoạt động dưới 1 lượng tải nhất định (thường là lượng user truy cập)

Loại test này cực kỳ quan trọng vì nó giúp chúng ta đánh giá được khả năng chịu tải của hệ thống của mình tới đâu để có kế hoạch nâng cấp, sửa chữa kịp thời.

Loại kiểm thử này thường được áp dụng trên những hệ thống đòi hỏi load dữ liệu lớn hay số lượng truy cập lớn mà việc tải chậm, chập chờn hoặc ngưng trệ có thể ảnh hưởng đến sự sống còn của sản phẩm. Loại test này thường được áp dụng cho các website hoặc ứng dụng thương mại điện tử, tin tức, v.v

Một số tool hỗ trợ cho loại test này như LoadUI, JMeter, LoadComplete.

IV. Trắc Nghiệm Kiểm Thử Phần Mềm Có Đáp Án

Câu 1: Quá trình lập kế hoạch kiểm thử diễn ra theo trình tự như thế nào?

Chọn một câu trả lời

A) Lập bản kế hoạch chính rồi thực thi các bản kế hoạch chi tiết đồng thời Sai

B) Lập bản kế hoạch chi tiết rồi đến bản kế hoạch chính Sai

C) Lập bản kế hoạch chính, các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án Đúng

D) Lập đồng thời cả hai loại bản kế hoạch là bản kế hoạch chính và bản kế hoạch chi tiết Sai.

Đáp án đúng là: C) “Lập bản kế hoạch chính, các bản kế hoạch chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án.”.Vì: Khi lập bản kế hoạch kiểm thử thì lập bản kế hoạch chính, các bản kế hoạch kiểm thử chi tiết lần lượt được thiết kế theo trình tự thời gian phát triển của dự án.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”

Câu 2: Chỉ số trưởng thành phần mềm SMI là viết tắt của từ tiếng Anh nào sau đây?

Chọn một câu trả lời

A) Software Multirity Index Đúng

B) Save Multirity Index Sai

C) Software Maturity Index Sai

D) Software Manyfacture Iterface Sai 

Đáp án đúng là: A) “Software Multirity Index”.Vì: Chỉ số chất lượng bảo trì hay chỉ số trưởng thành phần mềm SMI (Software Muturity Index – IEEE standard 982.1-1988): cho biết tính ổn định của sản phẩm phần mềm đã được phát triển.

Tham khảo: giáo trình “Giáo trình công nghệ phần mềm” , Chương 4 mục “Đảm bảo, kiểm thử và bảo trì phần mềm

Câu 3: Số lõi tiềm tàng trong công thức tính DRE là …?

Chọn một câu trả lời

A) Toàn bộ lỗi phát hiện trong một tháng Sai

B) Toàn bộ lỗi phát hiện trong một ngày Sai

C) Số lỗi đã khử được và số lỗi tìm được sau này Đúng

D) Toàn bộ lỗi phát hiện trong một giờ Sai

Đáp án đúng là: C) Số lỗi đã khử được và số lỗi tìm được sau này”.Vì: Công thức tính Defect Removal Effectiveness có mẫu số là số lỗi tiềm tàng chính là toàn bộ lỗi phát hiện = Số lỗi đã khử được + Số lỗi tìm được sau này (do khách hàng báo lại, do tình cờ…).

Tham khảo: giáo trình “Giáo trình công nghệ phần mềm” , Chương 4 mục “Đảm bảo, kiểm thử và bảo trì phần mềm”

Câu 4: DSQI có giá trị nằm trong miền nào sau đây?

Chọn một câu trả lời

A) -1 đến 1 Sai

B) 0 đến 1 Đúng

C) 0 đến 2 Sai

D) -1 đến 0 Sai

Đáp án đúng là: B) “0 đến 1”.Vì: Chỉ số chất lượng về cấu trúc của thiết kế (Design Structured Quanlity Index – DSQI – IEEE Standard 982.1 – 1988). Có giá trị nằm trong miền từ 0 đến 1

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, Chương 9 mục “Quản lý chất lượng phần mềm”

Câu 5: Lý thuyết của Halstead để đo độ đo nào sau đây?

Chọn một câu trả lời

A) Chỉ số chất lượng cấu trúc Sai

B) Độ hoàn hảo của phần mềm Sai

C) Khối lượng chương trình Đúng

D) Mật độ lỗi Sai

Đáp án đúng là: C“Khối lượng chương trình”.Vì: Để đo khối lượng chương trình thì có nhiều chỉ số và nhiều cách đo. Tuy nhiên, ở đây giới thiệu cách đo của Halstead để đo khối lượng của chương trình hay khối lượng mã nguồn và đo mức của ngôn ngữ.

Tham khảo: giáo trình “Giáo trình công nghệ phần mềm” , Chương 4 mục “Đảm bảo, kiểm thử và bảo trì phần mềm

V. Các Công Cụ Kiểm Thử Phần Mềm Phổ Biến

Trong thời kỳ kết nối hiện nay, phần mềm trở nên cần thiết và phổ biến. Do vậy nên nhu cầu kiểm thử phần mềm cũng tăng theo. Dưới đây là 5 công cụ kiểm thử phần mềm hiệu quả đều chạy trên Cloud. Các công cụ này áp dụng cho những dự án lập trình web, mobile trên các platform khác nhau.

+ Công cụ kiểm thử phần mềm LoadStorm

Công cụ đầu tiên nên dùng để kiểm thử phần mềm trên website và mobile là LoadStorm. Nhìn chung LoadStorm là công cụ có khả năng chịu tải vô cùng tốt. Bạn đọc có thể kiểm tra hiệu năng của app thông qua lượng traffic và user. Điểm đặc trưng ở công cụ này là nó có thể thiết lập hàng trăm nghìn, thậm chí hàng triệu user để khai thác lỗ hổng trong ứng dụng.

Mặt khác, tester có thể dễ dàng điều chỉnh kịch bản test khi sử dụng công cụ này. Sau khi tiến hành pentest, bạn sẽ nhìn thấy một bản báo cáo chi tiết.

+ Công cụ SOASTA CloudTest

CloudTest giúp bạn kiểm tra các website và ứng dụng trên di động 1 cách linh hoạt, nhanh chóng. SOASTA CloudTest có thể kiểm tra khả năng chịu tải của các ứng dụng theo vị trí địa lý khác nhau, đặc biệt 2 khâu integration và phân tích thời gian thực giữa các monitoring, test design, reporting đều được tiến hành một cách liền mạch.

+ Công cụ Nessus

Nessus là công cụ chuyên sử dụng để pentest hệ thống, rà quét lỗ hổng bảo mật, và mã độc. Công cụ này cho phép bạn dùng thử miễn phí. Điểm khác biệt ở công cụ này so với các công cụ pentest khác là Nessus chứa các plugin về bảo mật hàng đầu thế giới, có thể rà quét lỗ hổng trong windoes, linux một cách toàn diện.

Công cụ này cũng cho phép quét những lỗ hổng tồn tại bên trong ứng dụng web, trình duyệt, phần mềm và các thiết bị mạng nội bộ. Sau khi rà quét xong nó sẽ báo cáo chi tiết về lỗ hổng, mức độ nguy hiểm và phương án phòng tránh, xử lý mã độc. Đây là một trong những công cụ kiểm thử phần mềm hàng đầu được mọi người tin dùng.

+ Công cụ BlazeMeter

BlazeMeter là công cụ cho phép bạn có thể test các hạng mục như: end-to-end load; performance và load testing, cho phép testing trên apps, mobiles, website, và APIs. BlazeMeter có khả năng giả lập lượng user khá lớn gần 1 triệu người. Khi tiến hành testing, bạn sẽ thấy công cụ này sẽ report trong thời gian thực cùng với sự chính xác cao của phần đo hiệu năng.

+ Công cụ App Thwack

App Thwack là công cụ chuyên dùng cho hệ điều hành iOS, Android và webapp trên thiết bị cụ thể. App Thwack dễ dàng tương thích với các nền tảng tự động hóa như: Calabash,Robotium, UI tự động hóa,…Ngoài ra những chức năng cơ bản như hỗ trợ báo cáo, hỗ trợ các nền tảng, dễ dàng sử dụng, dễ dàng cấu hình… cũng là những tính năng tối thiểu của công cụ để kiểm thử phần mềm này.

VI. Vai Trò Của Kiểm Thử Phần Mềm

Thời gian gần đây, ngành công nghệ thông tin, công nghệ phần mềm có vẻ vẫn đang đứng top các ngành, nghề có sức hút lớn, đặc biệt trong bối cảnh khủng hoảng mọi mặt về kinh tế, xã hội do đại dịch Covid gây ra. Vậy điều gì ấn tượng nhất ngay khi bạn nhắc tới ngành này, có phải là hình ảnh các anh kĩ sư máy tính, các lập trình viên thông minh cùng những dòng code phức tạp, khó hiểu.

Bên cạnh đó, tham gia vào việc đảm bảo chất lượng của các sản phẩm phần mềm, đứng song song vị trí với các lập trình viên là sự tham gia kiểm tra, thử nghiệm gọi tắt là kiểm thử phần mềm của các nhà Kiểm thử viên hay còn gọi là Tester. Trong bài viết lần này, hãy cùng mình tìm hiểu kĩ hơn về công việc của một Kiểm thử viên nhé.

Vai trò của Kiểm thử phần mềm

Công việc kiểm thử phần mềm là kiểm tra, kiếm tìm các lỗi của phần mềm, ứng dụng hoặc xác minh, thẩm định liệu phần mềm đó đã đáp ứng được các yêu cầu kỹ thuật và yêu cầu nghiệp vụ hay không.

Kiểm thử phần mềm thể hiện được những “trách nhiệm” cao cả dưới đây:

Thứ nhất, trách nhiệm hiệu quả về chi phí. Kiểm thử phần mềm giúp nhanh chóng phát hiện các lỗi của phần mềm, giúp giảm giá thành sửa chữa.

Thứ hai, trách nhiệm bảo mật. Sản phẩm được phát hiện và sửa lỗi giúp loại bỏ những rủi ro và các vấn đề sớm, làm tăng độ tin cậy cho sản phẩm. Đối với ngành công nghệ phần mềm, vấn đề bảo mật là yếu tố cực kỳ nhạy cảm, nó liên quan trực tiếp đến việc sở hữu, sử dụng của người dùng. Vì vậy, việc kiểm thử phần mềm giúp hoàn thiện nhất sản phẩm phần mềm, hạn chế những lỗ hổng bảo mật đáng tiếc, tăng độ tin tưởng cho người sử dụng.

Thứ ba, trách nhiệm về chất lượng sản phẩm. Ngoài vấn đề bảo mật như trên, sản phẩm phần mềm được kiểm tra sẽ đảm bảo được độ tin cậy, hiệu suất hoạt động cao, bảo đảm được các yêu cầu, tính năng cần thiết của nó. Sản phẩm đưa đến tay khách hàng phải là một sản phẩm đạt đủ các yêu cầu của khách hàng về hình thức, giao diện, cấu trúc, tính năng,…và đảm bảo không còn bất cứ lỗi nào trên sản phẩm.

Thứ tư, trách nhiệm với niềm tin của khách hàng. Một sản phẩm càng chỉn chu, càng hoàn thiện, chất lượng càng cao sẽ tạo ra những trải nghiệm người dùng tốt nhất, từ đó càng tạo được niềm tin và uy tín với khách hàng và đối tác.

Như vậy, Kiểm thử phần mềm là hoạt động không thể tách rời trong quá trình phát triển phần mềm.

The post 7 Nguyên Tắc Kiểm Thử Phần Mềm first appeared on Techacademy.

source https://techacademy.edu.vn/7-nguyen-tac-kiem-thu-phan-mem/

Trong xã hội hiện đại ngày nay, khi công nghệ thông tin lên ngôi và phát triển liên tục mạnh mẽ, sinh hoạt chúng ta hằng ngày đều gắn liền với việc sử dụng các thiết bị điện tử nhằm hỗ trợ cho công việc, sinh hoạt hay cả các hoạt động vui chơi giải trí. Hầu như bất kì thiết bị hay ứng dụng nào đều cũng phải trải qua một quá trình lập trình và được kiểm thử bởi tester trước khi sản phẩm đến tay người dùng.

Đó là một trong những công đoạn mà không một đội ngũ kỹ thuật, lập trình viên nào có thể bỏ qua. Để hiểu rõ hơn về kiểm thử phần mềm, chúng ta sẽ cùng tìm hiểu cụ thể thông qua bài viết dưới đây.

I. Kiểm Thử Phần Mềm Là Gì

Kiểm thử phần mềm là phương pháp kiểm tra xem sản phẩm phần mềm đó trên thực tế có phù hợp với các yêu cầu đã đặt ra hay không, và đảm bảo rằng không có lỗi hay khiếm khuyết. Nó bao gồm việc kiểm tra, phân tích, quan sát và kiểm tra những khía cạnh khác nhau của sản phẩm.

Người kiểm thử phần mềm (Tester) sử dụng kết hợp các công cụ thủ công và tự động. Sau khi tiến hành kiểm thử, Tester báo cáo kết quả cho team phát triển. Mục đích là xác định các lỗi, khiếm khuyết hoặc các yêu cầu còn thiếu so với yêu cầu thực tế.

Cần hiểu được tầm quan trọng của việc kiểm thử đối với mỗi công ty phát triển phát mềm. Với kiểm thử phần mềm, nếu có bất kỳ lỗi nào, nó có thể được xác định sớm và giải quyết trước khi giao sản phẩm.

Nhiều công ty phát triển phần mềm thường bỏ qua bước này vì ngân sách eo hẹp và cho rằng nó sẽ không dẫn đến hậu quả lớn. Nhưng để tạo những trải nghiệm tốt nhất cho khách hàng, chất lượng sản phẩm cần phải được đặt lên hàng đầu. Và vì vậy, việc kiểm thử sản phẩm để tìm lỗi là điều gần như bắt buộc.

Doanh nghiệp chỉ có thể mang đến giá trị cho khách hàng khi sản phẩm cung cấp được coi là lý tưởng. Và để đạt được điều đó, các công ty phải bảo đảm rằng người dùng không gặp phải bất kỳ vấn đề nào lúc dùng sản phẩm của mình. Cách tốt nhất để làm điều đó là tạo ra sản phẩm không có lỗi.

Thêm nữa, khi khách hàng sử dụng sản phẩm, họ rất có thể phải tiết lộ một số thông tin cá nhân. Để ngăn chặn tin tặc nắm được dữ liệu này, việc kiểm tra bảo mật là điều bắt buộc trước khi phần mềm đến tay người dùng. Sản phẩm phần mềm được kiểm thử kỹ càng qua quy trình phù hợp sẽ đảm bảo độ tin cậy, bảo mật, giúp tiết kiệm thời gian, chi phí, mang đến sự hài lòng cho khách hàng.

Một lý do nữa khiến việc kiểm thử ngày càng trở nên quan trọng đó là phát hiện khả năng tương thích với các thiết bị và nền tảng khác nhau. Giả sử khi phát triển một trang web, Tester phải kiểm tra xem trang web có chạy trên độ phân giải thiết bị khác nhau, các trình duyệt khác nhau hay không?

Những gì hoạt động tốt trên Chrome có thể không chạy tốt trên Safari hoặc Internet Explorer. Điều này làm phát sinh nhu cầu kiểm tra trình duyệt chéo, bao gồm kiểm tra tính tương thích của ứng dụng trên các trình duyệt khác nhau.

II. Tại Sao Cần Kiểm Thử Phần Mềm

Dù đối với bất kì dự án lập trình phần mềm thì kiểm thử phần mềm là khâu đóng một vai trò quan trọng không thể bỏ qua bởi việc phát hiện lỗi sớm và tìm hướng khắc phục nó chính là cách nhanh nhất và hiệu quả để hoàn thiện sản phẩm trước lúc tới tay người dùng.

Việc kiểm thử phần mềm sẽ giúp đánh giác được hiệu quả chức năng của một ứng dụng phần mềm nhằm mục đích phát hiện những lỗi sai, hay rủi ro, nguy cơ tìm ẩn, ảnh hưởng đến danh tiếng thường, giúp phần mềm đáp ứng được những yêu cầu thiết yếu cụ thể để bảo toàn chất lượng sản phẩm

Một sản phẩm sau khi trải qua quá trình kiểm thử sẽ bảo đảm được độ tin cậy, uy tín, tính bảo mật, hiệu suất cao cũng như giúp tiết kiệm thời gian và chi phí cho khách hàng và người sử dụng. Nếu như sơ sài trong quá trình kiểm thử để xảy ra một lỗi nhỏ hay một thiếu sót cũng có thể gây ra các thiệt hại lớn về kinh tế cũng như con người,…

III. Mục Đích Của Kiểm Thử Phần Mềm

• Kiểm thử là 1 quá trình thực thi chương trình với mục đích là tìm ra lỗi/các yếu điểm của chương trình.
• Một trường hợp kiểm thử tốt là 1 trường hợp có khả năng lớn trong việc tìm ra những lỗi chưa được phát hiện.
• Một trường hợp kiểm thử không tốt ( không thành công) là một trường hợp mà khả năng tìm thấy những lỗi chưa biết tới là rất ít.

Mục tiêu của kiểm thử phần mềm là thiết kế các trường hợp kiểm thử để có thể phát hiện một cách có hệ thống các loại lỗi khác nhau và thực hiện việc đó với lượng thời gian và tài nguyên ít nhất có thể.

IV. Các Phương Pháp Kiểm Thử Phần Mềm

Có nhiều phương pháp kiểm thử khác nhau có thể được các testers sử dụng trong kiểm thử phần mềm. Bài viết này sẽ mô tả ngắn gọn các phương pháp truyền thống, đó là các phương pháp: Kiểm thử hộp đen (Black-Box Testing), Kiểm thử hộp trắng (White-Box Testing) và Kiểm thử hộp xám (Grey-Box Testing).

+ Kiểm thử hộp đen

Khi thực hiện kỹ thuật kiểm thử này, tester không cần quan tâm bên trong hệ thống hoạt động ra sao, không cần hiểu source code thế nào. Thông thường, trong khi thực hiện kiểm thử hộp đen, tester sẽ tương tác với giao diện người dùng của hệ thống bằng cách cung cấp đầu vào và kiểm tra kết quả đầu ra mà không cần biết cách thức làm việc bên trong của hệ thống.
Bảng sau đây liệt kê những ưu điểm và nhược điểm của kiểm thử hộp đen:

+ Kiểm thử hộp trắng

Kiểm thử hộp trắng là kiểm tra chi tiết về logic luồng hoạt động cũng như source code. Kiểm thử hộp trắng cũng được gọi là Glass testing hay open-box testing. Để thực hiện kiểm thử hộp trắng trên một phần mềm, tester cần phải nghiên cứu hoạt động bên trong của phần mềm cũng như source code để tìm ra đơn vị / đoạn mã nào đang hoạt động không thích hợp.
Bảng sau đây liệt kê những ưu điểm và nhược điểm của kiểm thử hộp trắng:

+ Kiểm thử hộp xám

Kiểm thử hộp màu xám là một kỹ thuật để kiểm thử phần mềm đòi hỏi tester có kiến ​​thức nhất định về các luồng hoạt động bên trong của phần mềm.

Nắm vững domain của 1 hệ thống luôn mang lại cho tester một lợi thế lớn hơn một tester có kiến ​​thức về domain hạn chế. Không giống như kiểm thử hộp đen, phương pháp mà tester quan tâm duy nhất là kiểm thử thông qua giao diện người dùng thì trong kiểm thử hộp xám, tester có quyền truy cập vào tài liệu thiết kế và cơ sở dữ liệu.

Do đó, một tester có thể chuẩn bị dữ liệu kiểm thử cũng như chuẩn bị các kịch bản kiểm thử tốt hơn trong quá trình thực hiện kế hoạch kiểm thử hệ thống.

V. Công Cụ Kiểm Thử Phần Mềm

+ Selenium

Selenium là một công cụ kiểm thử phần mềm tự động mã nguồn mở miễn phí cho các ứng dụng web trên nhiều trình duyệt và nền tảng khác nhau như Windows, Mac và Linux. Selenium giúp Tester thực hiện kiểm thử bằng nhiều ngôn ngữ lập trình khác nhau như Java, PHP, C#, Python, Groovy, Ruby và Perl.

Selenium hiện có 3 loại: Selenium Webdriver, Selenium IDE, Selenium Grid. Tùy vào kỹ năng, nền tảng và yêu cầu mà bạn có thể lựa chọn sử dụng loại Selenium phù hợp.

Công cụ này phổ biến với tất cả các trình duyệt nổi tiếng hiện tại như Chrome, Mozila Firefox, Microsoft Edge, Apple Safari, Opera. Vì vậy, Selenium chắc chắn là nền tảng cho hầu hết các công cụ kiểm thử phần mềm khác.

+ TestingWhiz

TestingWhiz là công cụ kiểm thử phần mềm tự động với phiên bản Enterprise cung cấp một gói hoàn chỉnh gồm nhiều giải pháp test tự động khác nhau. Trong đó bao gồm: test web, test phần mềm, test database (cơ sở dữ liệu), test API, test ứng dụng di dộng, bảo trì bộ kiểm tra hồi quy, tối ưu hóa và tự động hóa cũng như kiểm thử trên nhiều trình duyệt.

Ngoài ra, TestingWhiz cung cấp nhiều tính năng quan trọng khác nhau như:

• Kiểm thử theo hướng từ khóa (key-word driven), theo hướng dữ liệu (data driven) và kiểm thử phân tán (distributed)
• Kiểm thử tiện ích mở rộng trong trình duyệt
• Object Eye Internal Recorder
• SMTP Integration
• Tích hợp với các công cụ theo dõi lỗi như Jira, Mantis, TFS và FogBugz
• Tích hợp với các công cụ quản lý kiểm thử như HP Quality Center, Zephyr, TestRail và Microsoft VSTS
• Centralized Object Repository (Kho lưu trữ đối tượng tập trung)
• Version Control System Integration (Tích hợp hệ thống kiểm soát phiên bản)
• Customized Recording Rule (Quy tắc ghi tùy chỉnh)

+ HPE Unified Functional Testing (HP – UFT formerly QTP)

HPE UFT cung cấp tính năng tự động hóa kiểm thử để kiểm thử chức năng và kiểm thử hồi quy cho các ứng dụng phần mềm. Ngôn ngữ script Visual Basic Scripting Edition được ứng dụng bởi công cụ này để đăng ký các quá trình kiểm thử và vận hành các đối tượng và điều khiển khác nhau trong việc test các ứng dụng.

Ngoài ra, QTP cung cấp các tính năng khác như:

• Tích hợp với Mercury Business Process Testing và Mercury Quality Center
• Nhận dạng Unique Smart Object
• Cơ chế xử lý lỗi
• Tạo các tham số cho đối tượng, checkpoint và bảng điều hướng dữ liệu
• Tài liệu tự động

+ TestComplete

TestComplete là một nền tảng kiểm thử chức năng cung cấp các giải pháp khác nhau để tự động kiểm thử. Công cụ này sử dụng cho máy tính để bàn, web và các ứng dụng di động.

• TestComplete cung cấp các tính năng sau:
• GUI testing
• Hỗ trợ ngôn ngữ test – JavaScript, Python, VBScript, JScript, DelphiScript, C++ Script & C# Script
• Kiểm thử trình hiển thị
• Kiểm thử theo script (Scripted testing)
• Kiểm thử ghi và phát lại (Test recording and playback)

+ Ranorex

Ranorex Studio cung cấp các công cụ tự động hóa testing khác nhau bao gồm việc test tất cả các ứng dụng máy tính để bàn, web và thiết bị di động.

Cụ thể hơn, Ranorex cung cấp các tính năng sau:

• Kiểm thử GUI
• Có thể tái sử dụng test code
• Phát hiện bug
• Tích hợp với nhiều công cụ khác nhau
• Ghi và phát lại

+ Sahi

Sahi là một công cụ kiểm thử phần mềm tự động hóa áp dụng cho việc test các ứng dụng web. Mã nguồn mở Sahi được viết bằng ngôn ngữ lập trình Java và JavaScript.

Sahi cung cấp các tính năng sau:

• Thực hiện kiểm thử nhiều trình duyệt cùng lúc
• Hỗ trợ các framework ExtJS, ZK, Dojo, YUI, v.v.
• Ghi lại và phát lại khi test trình duyệt

+ Watir

Watir là một công cụ kiểm thử mã nguồn mở được tạo thành từ các thư viện Ruby để tự động kiểm thử ứng dụng web.

Công cụ này cung cấp các tính năng sau:

• Kiểm thử bất kỳ ứng dụng web dựa trên ngôn ngữ nào
• Kiểm thử trên nhiều trình duyệt
• Tương thích với các công cụ phát triển theo định hướng kinh doanh như RSpec, Cucumber và Test / Unit
• Kiểm thử các nút, biểu mẫu, liên kết và phản hồi của chúng trên trang web

+ Tosca Testsuite

Tosca Testsuite là một công cụ phần mềm để thực hiện tự động kiểm thử phần mềm chức năng và hồi quy. Ngoài chức năng tự động hóa thử nghiệm, TOSCA bao gồm quản lý kiểm thử tích hợp, giao diện người dùng đồ họa (GUI), giao diện dòng lệnh (CLI) và giao diện lập trình ứng dụng (API).

Tosca Testsuite đi kèm với các tính năng sau:

• Lập kế hoạch và thiết kế trường hợp thử nghiệm
• Kiểm tra cung cấp dữ liệu
• Dịch vụ mạng ảo hóa
• Kiểm tra ứng dụng di động
• Quản lý tích hợp
• Bảo hiểm rủi ro

+ Telerik TestStudio

Telerik TestStudio cung cấp giải pháp để tự động kiểm thử ứng dụng trên máy tính để bàn, web và thiết bị di động bao gồm kiểm thử giao diện người dùng, load và hiệu suất.

Công cụ này cung cấp nhiều khả năng tương thích khác nhau như:

• Hỗ trợ các ngôn ngữ lập trình như HTML, AJAX, ASP.NET, JavaScript, Silverlight, WPF và MVC
• Tích hợp với Visual Basic Studio 2010 và 2012
• Ghi và phát lại
• Kiểm thử trên nhiều trình duyệt
• Kiểm thử thủ công
• Tích hợp với các công cụ theo dõi bug

+ Katalon Studio

Katalon Studio là một công cụ kiểm thử phần mềm tự động hóa miễn phí được phát triển bởi Katalon LLC. Công cụ này được xây dựng dựa trên các framework tự động hóa mã nguồn mở Selenium, Appium với giao diện IDE chuyên biệt để kiểm tra API, web và thiết bị di động. Công cụ này bao gồm một gói đầy đủ các tính năng mạnh mẽ giúp dễ dàng tự động hóa kiểm thử giao diện người dùng web.

Katalon Studio bao gồm các tính năng sau:

• Kho lưu trữ đối tượng tích hợp, XPath, nhận dạng lại đối tượng
• Hỗ trợ các ngôn ngữ script Java / Groovy
• Hỗ trợ tích hợp cho kiểm thử dựa trên hình ảnh
• Hỗ trợ các công cụ Tích hợp liên tục như Jenkins & TeamCity
• Hỗ trợ Duel-editor Interface
• Quy trình thực thi có thể tùy chỉnh

VI. Trắc Nghiệm Kiểm Thử Phần Mềm Có Đáp Án

Câu 1: Mô hình kiểm thử phần mềm TMM là viết tắt của từ tiếng anh nào sau đây?

Chọn một câu trả lời

A) Testing Maturity Model Đúng

B) Testing Model Manufactory Sai

C) Testing Manufactory Model Sai

D) Testing Manual Machanic Sai

Đáp án đúng là: A) “Testing Maturity Model”.Vì: Mô hình kiểm thử phần mềm TMM là viết tắt của từ tiếng Anh: “Testing Maturity Model”.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp.

Câu 2: Phát biểu nào sau đây là sai về thiết kế kiểm thử?

Chọn một câu trả lời

A) Thực thi sau khi có bản kế hoạch kiểm thử Sai

B) Chỉ định các test case cũng như các bước kiểm thử Sai

C) Có thể dùng cho mọi phiên bản phần mềm Đúng

D) Bảo đảm tất cả các tình huống kiểm thử được quét hết Sai

Đáp án đúng là: C) “Có thể dùng cho mọi phiên bản phần mềm”.Vì: Mỗi phiên bản phần mềm sẽ phải có một bản thiết kế kiểm thử riêng, nó có thể kế thừa từ phiên bản trước đó.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp.

Câu 3: Đâu là thứ tự thực hiện các bước kiểm thử cơ bản?

Chọn một câu trả lời

A)

• Xác định và mô tả test case
• Mô tả các bước chi tiết kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử
• Xem xét test case và các bước kiểm thử  Đúng

B)

• Xác định và mô tả test case
• Mô tả các bước chi tiết kiểm thử
• Xem xét test case và các bước kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử Sai

C)

• Mô tả các bước chi tiết kiểm thử
• Xác định và mô tả test case
• Xem xét test case và các bước kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử Sai

D)

• Xem xét test case và các bước kiểm thử
• Mô tả các bước chi tiết kiểm thử
• Xác định và mô tả test case
• Xem xét và khảo sát độ bao phủ của việc kiểm thử Sai

Đáp án đúng là: A

• “Xác định và mô tả test case
• Mô tả các bước chi tiết kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử
• Xem xét test case và các bước kiểm thử”.

Vì: Các bước thiết kế kiểm thử cơ bản là: ”Xác định và mô tả test case, mô tả các bước chi tiết kiểm thử, xem xét và khảo sát độ bao phủ của việc kiểm thử, xem xét test case và các bước kiểm thử”

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp

Câu 4: Một quy trình kiểm thử phần mềm thì có … test case?

Chọn một câu trả lời

A) Nhiều Đúng

B) Một Sai

C) Có thể không cần Sai

D) Phải luôn là hai Sai

Đáp án đúng là: A)  “Nhiều”.Vì: Trong quy trình kiểm thử phần mềm có khâu thiết kế test. Trong khâu thiết kế test này nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phiên bản phần mềm.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”

Câu 5: Phát biểu nào sau đây về test script là sai?

Chọn một câu trả lời

A) Một Test Script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra. Sai

B) Giúp cho việc kiểm tra nhanh hơn Sai 

C) Cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi Sai

D) Test script là kiểm thử bằng tay Đúng

Đáp án đúng là: D)  “Test script là kiểm thử bằng tay” Vì: Một Test Script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”

Câu 6: Trong các bước sau, đâu không phải là thành phần của test case?

Chọn một câu trả lời

A) Mô tả Sai

B) Nhập Sai

C) Kết quả mong chờ Sai

D) Xuất Đúng

Đáp án đúng là: D) “Xuất”. Vì: Các thành phần cơ bản của một test case là: mô tả, nhập và kết quả mong chờ

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”

Câu 7: Lập kế hoạch kiểm thử để làm gì?

Chọn một câu trả lời

A) Để chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện Đúng

B) Để lập kế hoạch cho test case Sai

C) Để lập kế hoạch cho test script Sai 

D) Để lập kiểm định dự án phần mềm Sai

Đáp án đúng là: A) “Để chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện”. Vì: Lập kế hoạch kiểm thử để nhằm mục đích chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp

The post Kiểm Thử Phần Mềm Là Gì ? Tại Sao Cần Kiểm Thử Phần Mềm first appeared on Techacademy.

source https://techacademy.edu.vn/kiem-thu-phan-mem-la-gi/

Trong xã hội hiện đại ngày nay, khi công nghệ thông tin lên ngôi và phát triển liên tục mạnh mẽ, sinh hoạt chúng ta hằng ngày đều gắn liền với việc sử dụng các thiết bị điện tử nhằm hỗ trợ cho công việc, sinh hoạt hay cả các hoạt động vui chơi giải trí. Hầu như bất kì thiết bị hay ứng dụng nào đều cũng phải trải qua một quá trình lập trình và được kiểm thử bởi tester trước khi sản phẩm đến tay người dùng.

Đó là một trong những công đoạn mà không một đội ngũ kỹ thuật, lập trình viên nào có thể bỏ qua. Để hiểu rõ hơn về kiểm thử phần mềm, chúng ta sẽ cùng tìm hiểu cụ thể thông qua bài viết dưới đây.

I. Kiểm Thử Phần Mềm Là Gì

Kiểm thử phần mềm là phương pháp kiểm tra xem sản phẩm phần mềm đó trên thực tế có phù hợp với các yêu cầu đã đặt ra hay không, và đảm bảo rằng không có lỗi hay khiếm khuyết. Nó bao gồm việc kiểm tra, phân tích, quan sát và kiểm tra những khía cạnh khác nhau của sản phẩm.

Người kiểm thử phần mềm (Tester) sử dụng kết hợp các công cụ thủ công và tự động. Sau khi tiến hành kiểm thử, Tester báo cáo kết quả cho team phát triển. Mục đích là xác định các lỗi, khiếm khuyết hoặc các yêu cầu còn thiếu so với yêu cầu thực tế.

Cần hiểu được tầm quan trọng của việc kiểm thử đối với mỗi công ty phát triển phát mềm. Với kiểm thử phần mềm, nếu có bất kỳ lỗi nào, nó có thể được xác định sớm và giải quyết trước khi giao sản phẩm.

Nhiều công ty phát triển phần mềm thường bỏ qua bước này vì ngân sách eo hẹp và cho rằng nó sẽ không dẫn đến hậu quả lớn. Nhưng để tạo những trải nghiệm tốt nhất cho khách hàng, chất lượng sản phẩm cần phải được đặt lên hàng đầu. Và vì vậy, việc kiểm thử sản phẩm để tìm lỗi là điều gần như bắt buộc.

Doanh nghiệp chỉ có thể mang đến giá trị cho khách hàng khi sản phẩm cung cấp được coi là lý tưởng. Và để đạt được điều đó, các công ty phải bảo đảm rằng người dùng không gặp phải bất kỳ vấn đề nào lúc dùng sản phẩm của mình. Cách tốt nhất để làm điều đó là tạo ra sản phẩm không có lỗi.

Thêm nữa, khi khách hàng sử dụng sản phẩm, họ rất có thể phải tiết lộ một số thông tin cá nhân. Để ngăn chặn tin tặc nắm được dữ liệu này, việc kiểm tra bảo mật là điều bắt buộc trước khi phần mềm đến tay người dùng. Sản phẩm phần mềm được kiểm thử kỹ càng qua quy trình phù hợp sẽ đảm bảo độ tin cậy, bảo mật, giúp tiết kiệm thời gian, chi phí, mang đến sự hài lòng cho khách hàng.

Một lý do nữa khiến việc kiểm thử ngày càng trở nên quan trọng đó là phát hiện khả năng tương thích với các thiết bị và nền tảng khác nhau. Giả sử khi phát triển một trang web, Tester phải kiểm tra xem trang web có chạy trên độ phân giải thiết bị khác nhau, các trình duyệt khác nhau hay không?

Những gì hoạt động tốt trên Chrome có thể không chạy tốt trên Safari hoặc Internet Explorer. Điều này làm phát sinh nhu cầu kiểm tra trình duyệt chéo, bao gồm kiểm tra tính tương thích của ứng dụng trên các trình duyệt khác nhau.

II. Tại Sao Cần Kiểm Thử Phần Mềm

Dù đối với bất kì dự án lập trình phần mềm thì kiểm thử phần mềm là khâu đóng một vai trò quan trọng không thể bỏ qua bởi việc phát hiện lỗi sớm và tìm hướng khắc phục nó chính là cách nhanh nhất và hiệu quả để hoàn thiện sản phẩm trước lúc tới tay người dùng.

Việc kiểm thử phần mềm sẽ giúp đánh giác được hiệu quả chức năng của một ứng dụng phần mềm nhằm mục đích phát hiện những lỗi sai, hay rủi ro, nguy cơ tìm ẩn, ảnh hưởng đến danh tiếng thường, giúp phần mềm đáp ứng được những yêu cầu thiết yếu cụ thể để bảo toàn chất lượng sản phẩm

Một sản phẩm sau khi trải qua quá trình kiểm thử sẽ bảo đảm được độ tin cậy, uy tín, tính bảo mật, hiệu suất cao cũng như giúp tiết kiệm thời gian và chi phí cho khách hàng và người sử dụng. Nếu như sơ sài trong quá trình kiểm thử để xảy ra một lỗi nhỏ hay một thiếu sót cũng có thể gây ra các thiệt hại lớn về kinh tế cũng như con người,…

III. Mục Đích Của Kiểm Thử Phần Mềm

• Kiểm thử là 1 quá trình thực thi chương trình với mục đích là tìm ra lỗi/các yếu điểm của chương trình.
• Một trường hợp kiểm thử tốt là 1 trường hợp có khả năng lớn trong việc tìm ra những lỗi chưa được phát hiện.
• Một trường hợp kiểm thử không tốt ( không thành công) là một trường hợp mà khả năng tìm thấy những lỗi chưa biết tới là rất ít.

Mục tiêu của kiểm thử phần mềm là thiết kế các trường hợp kiểm thử để có thể phát hiện một cách có hệ thống các loại lỗi khác nhau và thực hiện việc đó với lượng thời gian và tài nguyên ít nhất có thể.

IV. Các Phương Pháp Kiểm Thử Phần Mềm

Có nhiều phương pháp kiểm thử khác nhau có thể được các testers sử dụng trong kiểm thử phần mềm. Bài viết này sẽ mô tả ngắn gọn các phương pháp truyền thống, đó là các phương pháp: Kiểm thử hộp đen (Black-Box Testing), Kiểm thử hộp trắng (White-Box Testing) và Kiểm thử hộp xám (Grey-Box Testing).

+ Kiểm thử hộp đen

Khi thực hiện kỹ thuật kiểm thử này, tester không cần quan tâm bên trong hệ thống hoạt động ra sao, không cần hiểu source code thế nào. Thông thường, trong khi thực hiện kiểm thử hộp đen, tester sẽ tương tác với giao diện người dùng của hệ thống bằng cách cung cấp đầu vào và kiểm tra kết quả đầu ra mà không cần biết cách thức làm việc bên trong của hệ thống.
Bảng sau đây liệt kê những ưu điểm và nhược điểm của kiểm thử hộp đen:

+ Kiểm thử hộp trắng

Kiểm thử hộp trắng là kiểm tra chi tiết về logic luồng hoạt động cũng như source code. Kiểm thử hộp trắng cũng được gọi là Glass testing hay open-box testing. Để thực hiện kiểm thử hộp trắng trên một phần mềm, tester cần phải nghiên cứu hoạt động bên trong của phần mềm cũng như source code để tìm ra đơn vị / đoạn mã nào đang hoạt động không thích hợp.
Bảng sau đây liệt kê những ưu điểm và nhược điểm của kiểm thử hộp trắng:

+ Kiểm thử hộp xám

Kiểm thử hộp màu xám là một kỹ thuật để kiểm thử phần mềm đòi hỏi tester có kiến ​​thức nhất định về các luồng hoạt động bên trong của phần mềm.

Nắm vững domain của 1 hệ thống luôn mang lại cho tester một lợi thế lớn hơn một tester có kiến ​​thức về domain hạn chế. Không giống như kiểm thử hộp đen, phương pháp mà tester quan tâm duy nhất là kiểm thử thông qua giao diện người dùng thì trong kiểm thử hộp xám, tester có quyền truy cập vào tài liệu thiết kế và cơ sở dữ liệu.

Do đó, một tester có thể chuẩn bị dữ liệu kiểm thử cũng như chuẩn bị các kịch bản kiểm thử tốt hơn trong quá trình thực hiện kế hoạch kiểm thử hệ thống.

V. Công Cụ Kiểm Thử Phần Mềm

+ Selenium

Selenium là một công cụ kiểm thử phần mềm tự động mã nguồn mở miễn phí cho các ứng dụng web trên nhiều trình duyệt và nền tảng khác nhau như Windows, Mac và Linux. Selenium giúp Tester thực hiện kiểm thử bằng nhiều ngôn ngữ lập trình khác nhau như Java, PHP, C#, Python, Groovy, Ruby và Perl.

Selenium hiện có 3 loại: Selenium Webdriver, Selenium IDE, Selenium Grid. Tùy vào kỹ năng, nền tảng và yêu cầu mà bạn có thể lựa chọn sử dụng loại Selenium phù hợp.

Công cụ này phổ biến với tất cả các trình duyệt nổi tiếng hiện tại như Chrome, Mozila Firefox, Microsoft Edge, Apple Safari, Opera. Vì vậy, Selenium chắc chắn là nền tảng cho hầu hết các công cụ kiểm thử phần mềm khác.

+ TestingWhiz

TestingWhiz là công cụ kiểm thử phần mềm tự động với phiên bản Enterprise cung cấp một gói hoàn chỉnh gồm nhiều giải pháp test tự động khác nhau. Trong đó bao gồm: test web, test phần mềm, test database (cơ sở dữ liệu), test API, test ứng dụng di dộng, bảo trì bộ kiểm tra hồi quy, tối ưu hóa và tự động hóa cũng như kiểm thử trên nhiều trình duyệt.

Ngoài ra, TestingWhiz cung cấp nhiều tính năng quan trọng khác nhau như:

• Kiểm thử theo hướng từ khóa (key-word driven), theo hướng dữ liệu (data driven) và kiểm thử phân tán (distributed)
• Kiểm thử tiện ích mở rộng trong trình duyệt
• Object Eye Internal Recorder
• SMTP Integration
• Tích hợp với các công cụ theo dõi lỗi như Jira, Mantis, TFS và FogBugz
• Tích hợp với các công cụ quản lý kiểm thử như HP Quality Center, Zephyr, TestRail và Microsoft VSTS
• Centralized Object Repository (Kho lưu trữ đối tượng tập trung)
• Version Control System Integration (Tích hợp hệ thống kiểm soát phiên bản)
• Customized Recording Rule (Quy tắc ghi tùy chỉnh)

+ HPE Unified Functional Testing (HP – UFT formerly QTP)

HPE UFT cung cấp tính năng tự động hóa kiểm thử để kiểm thử chức năng và kiểm thử hồi quy cho các ứng dụng phần mềm. Ngôn ngữ script Visual Basic Scripting Edition được ứng dụng bởi công cụ này để đăng ký các quá trình kiểm thử và vận hành các đối tượng và điều khiển khác nhau trong việc test các ứng dụng.

Ngoài ra, QTP cung cấp các tính năng khác như:

• Tích hợp với Mercury Business Process Testing và Mercury Quality Center
• Nhận dạng Unique Smart Object
• Cơ chế xử lý lỗi
• Tạo các tham số cho đối tượng, checkpoint và bảng điều hướng dữ liệu
• Tài liệu tự động

+ TestComplete

TestComplete là một nền tảng kiểm thử chức năng cung cấp các giải pháp khác nhau để tự động kiểm thử. Công cụ này sử dụng cho máy tính để bàn, web và các ứng dụng di động.

• TestComplete cung cấp các tính năng sau:
• GUI testing
• Hỗ trợ ngôn ngữ test – JavaScript, Python, VBScript, JScript, DelphiScript, C++ Script & C# Script
• Kiểm thử trình hiển thị
• Kiểm thử theo script (Scripted testing)
• Kiểm thử ghi và phát lại (Test recording and playback)

+ Ranorex

Ranorex Studio cung cấp các công cụ tự động hóa testing khác nhau bao gồm việc test tất cả các ứng dụng máy tính để bàn, web và thiết bị di động.

Cụ thể hơn, Ranorex cung cấp các tính năng sau:

• Kiểm thử GUI
• Có thể tái sử dụng test code
• Phát hiện bug
• Tích hợp với nhiều công cụ khác nhau
• Ghi và phát lại

+ Sahi

Sahi là một công cụ kiểm thử phần mềm tự động hóa áp dụng cho việc test các ứng dụng web. Mã nguồn mở Sahi được viết bằng ngôn ngữ lập trình Java và JavaScript.

Sahi cung cấp các tính năng sau:

• Thực hiện kiểm thử nhiều trình duyệt cùng lúc
• Hỗ trợ các framework ExtJS, ZK, Dojo, YUI, v.v.
• Ghi lại và phát lại khi test trình duyệt

+ Watir

Watir là một công cụ kiểm thử mã nguồn mở được tạo thành từ các thư viện Ruby để tự động kiểm thử ứng dụng web.

Công cụ này cung cấp các tính năng sau:

• Kiểm thử bất kỳ ứng dụng web dựa trên ngôn ngữ nào
• Kiểm thử trên nhiều trình duyệt
• Tương thích với các công cụ phát triển theo định hướng kinh doanh như RSpec, Cucumber và Test / Unit
• Kiểm thử các nút, biểu mẫu, liên kết và phản hồi của chúng trên trang web

+ Tosca Testsuite

Tosca Testsuite là một công cụ phần mềm để thực hiện tự động kiểm thử phần mềm chức năng và hồi quy. Ngoài chức năng tự động hóa thử nghiệm, TOSCA bao gồm quản lý kiểm thử tích hợp, giao diện người dùng đồ họa (GUI), giao diện dòng lệnh (CLI) và giao diện lập trình ứng dụng (API).

Tosca Testsuite đi kèm với các tính năng sau:

• Lập kế hoạch và thiết kế trường hợp thử nghiệm
• Kiểm tra cung cấp dữ liệu
• Dịch vụ mạng ảo hóa
• Kiểm tra ứng dụng di động
• Quản lý tích hợp
• Bảo hiểm rủi ro

+ Telerik TestStudio

Telerik TestStudio cung cấp giải pháp để tự động kiểm thử ứng dụng trên máy tính để bàn, web và thiết bị di động bao gồm kiểm thử giao diện người dùng, load và hiệu suất.

Công cụ này cung cấp nhiều khả năng tương thích khác nhau như:

• Hỗ trợ các ngôn ngữ lập trình như HTML, AJAX, ASP.NET, JavaScript, Silverlight, WPF và MVC
• Tích hợp với Visual Basic Studio 2010 và 2012
• Ghi và phát lại
• Kiểm thử trên nhiều trình duyệt
• Kiểm thử thủ công
• Tích hợp với các công cụ theo dõi bug

+ Katalon Studio

Katalon Studio là một công cụ kiểm thử phần mềm tự động hóa miễn phí được phát triển bởi Katalon LLC. Công cụ này được xây dựng dựa trên các framework tự động hóa mã nguồn mở Selenium, Appium với giao diện IDE chuyên biệt để kiểm tra API, web và thiết bị di động. Công cụ này bao gồm một gói đầy đủ các tính năng mạnh mẽ giúp dễ dàng tự động hóa kiểm thử giao diện người dùng web.

Katalon Studio bao gồm các tính năng sau:

• Kho lưu trữ đối tượng tích hợp, XPath, nhận dạng lại đối tượng
• Hỗ trợ các ngôn ngữ script Java / Groovy
• Hỗ trợ tích hợp cho kiểm thử dựa trên hình ảnh
• Hỗ trợ các công cụ Tích hợp liên tục như Jenkins & TeamCity
• Hỗ trợ Duel-editor Interface
• Quy trình thực thi có thể tùy chỉnh

VI. Trắc Nghiệm Kiểm Thử Phần Mềm Có Đáp Án

Câu 1: Mô hình kiểm thử phần mềm TMM là viết tắt của từ tiếng anh nào sau đây?

Chọn một câu trả lời

A) Testing Maturity Model Đúng

B) Testing Model Manufactory Sai

C) Testing Manufactory Model Sai

D) Testing Manual Machanic Sai

Đáp án đúng là: A) “Testing Maturity Model”.Vì: Mô hình kiểm thử phần mềm TMM là viết tắt của từ tiếng Anh: “Testing Maturity Model”.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp.

Câu 2: Phát biểu nào sau đây là sai về thiết kế kiểm thử?

Chọn một câu trả lời

A) Thực thi sau khi có bản kế hoạch kiểm thử Sai

B) Chỉ định các test case cũng như các bước kiểm thử Sai

C) Có thể dùng cho mọi phiên bản phần mềm Đúng

D) Bảo đảm tất cả các tình huống kiểm thử được quét hết Sai

Đáp án đúng là: C) “Có thể dùng cho mọi phiên bản phần mềm”.Vì: Mỗi phiên bản phần mềm sẽ phải có một bản thiết kế kiểm thử riêng, nó có thể kế thừa từ phiên bản trước đó.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp.

Câu 3: Đâu là thứ tự thực hiện các bước kiểm thử cơ bản?

Chọn một câu trả lời

A)

• Xác định và mô tả test case
• Mô tả các bước chi tiết kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử
• Xem xét test case và các bước kiểm thử  Đúng

B)

• Xác định và mô tả test case
• Mô tả các bước chi tiết kiểm thử
• Xem xét test case và các bước kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử Sai

C)

• Mô tả các bước chi tiết kiểm thử
• Xác định và mô tả test case
• Xem xét test case và các bước kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử Sai

D)

• Xem xét test case và các bước kiểm thử
• Mô tả các bước chi tiết kiểm thử
• Xác định và mô tả test case
• Xem xét và khảo sát độ bao phủ của việc kiểm thử Sai

Đáp án đúng là: A

• “Xác định và mô tả test case
• Mô tả các bước chi tiết kiểm thử
• Xem xét và khảo sát độ bao phủ của việc kiểm thử
• Xem xét test case và các bước kiểm thử”.

Vì: Các bước thiết kế kiểm thử cơ bản là: ”Xác định và mô tả test case, mô tả các bước chi tiết kiểm thử, xem xét và khảo sát độ bao phủ của việc kiểm thử, xem xét test case và các bước kiểm thử”

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp

Câu 4: Một quy trình kiểm thử phần mềm thì có … test case?

Chọn một câu trả lời

A) Nhiều Đúng

B) Một Sai

C) Có thể không cần Sai

D) Phải luôn là hai Sai

Đáp án đúng là: A)  “Nhiều”.Vì: Trong quy trình kiểm thử phần mềm có khâu thiết kế test. Trong khâu thiết kế test này nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phiên bản phần mềm.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”

Câu 5: Phát biểu nào sau đây về test script là sai?

Chọn một câu trả lời

A) Một Test Script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra. Sai

B) Giúp cho việc kiểm tra nhanh hơn Sai 

C) Cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi Sai

D) Test script là kiểm thử bằng tay Đúng

Đáp án đúng là: D)  “Test script là kiểm thử bằng tay” Vì: Một Test Script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi.

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”

Câu 6: Trong các bước sau, đâu không phải là thành phần của test case?

Chọn một câu trả lời

A) Mô tả Sai

B) Nhập Sai

C) Kết quả mong chờ Sai

D) Xuất Đúng

Đáp án đúng là: D) “Xuất”. Vì: Các thành phần cơ bản của một test case là: mô tả, nhập và kết quả mong chờ

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp”

Câu 7: Lập kế hoạch kiểm thử để làm gì?

Chọn một câu trả lời

A) Để chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện Đúng

B) Để lập kế hoạch cho test case Sai

C) Để lập kế hoạch cho test script Sai 

D) Để lập kiểm định dự án phần mềm Sai

Đáp án đúng là: A) “Để chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện”. Vì: Lập kế hoạch kiểm thử để nhằm mục đích chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện

Tham khảo: giáo trình “Kiểm thử và bảo đảm chất lượng phần mềm”, chương 7, mục “Kiểm thử phần mềm trong công nghiệp

The post Kiểm Thử Phần Mềm Là Gì ? Tại Sao Cần Kiểm Thử Phần Mềm first appeared on Techacademy.

source https://techacademy.edu.vn/kiem-thu-phan-mem-la-gi-tai-sao-can-kiem-thu-phan-mem/

Học tester là 1 cách rất hay nếu như bạn đang làm hay đang học ở lĩnh vực khác mà muốn lấn sân sang công nghệ thông tin. Nhưng không phải ai cũng biết điều này hay biết làm thế nào để việc này trở nên thuận lợi. Học tester mất bao lâu là câu hỏi mà bạn nào có ý định đi theo nghề Software Tester đều thắc mắc. Vậy hãy cùng tìm câu trả lời nhé!

I. Học Tester Mất Bao Lâu?

Kiến thức căn bản: Giai đoạn này sẽ mất 3-6 tháng hoặc hơn thế nữa tùy vào khả năng tiếp thu kiến thức của bạn. Bạn sẽ được học tri thức căn bản về máy tính, về tin học văn phòng, cài đặt phần mềm, sử dụng internet. Sau đó là kiến thức về lập trình: SQL, HTML, CSS và kiến thức tổng quan về test bao gồm việc hiểu định nghĩa cơ bản, những thuật ngữ, quy trình phần mềm, quy trình test…

Phần kiến thức riêng: Giai đoạn này sẽ ngắn hơn mất khoảng 2-3 tháng.

– Manual Test:

Đây là danh sách những kiến thức bạn nên tìm hiểu sâu thêm nếu sẽ làm test theo hướng manual.

Create a Test Plan: Các thành phần cần có trong một test plan cơ bản, cách viết test plan.

Design Test case: Cách tạo và viết 1 testcase thông dụng.

Test Design Techniques: Các kỹ thuật thiết kế testcase, giúp cho testcase hiệu quả và tối ưu hơn.

Test reporting, Daily status reports – cách viết report để báo cáo kết quả test của mình.

Defect management: Finding defects, Logging defects, Tracking and managing defects – Học cách report & quản lý một bug cũng như sử dụng tools tracking thông dụng như Jira, Mantis, Bugzilla, Application Lifecycle Management (ALM).

Mobile application testing (iOS, Android, Windows Phone): Cách cài đặt và test ứng dụng mobile, cách giả lập thiết bị điện thoại trên máy tính.

Windows, Website testing & Tools support: Cách test 1 ứng dụng desktop, một trang web và giả lập các trình duyệt khác nhau trên máy tính.

Risk based testing process and implementation: Đánh giá rủi ro trong kiểm thử, đây là phần nâng cao nhưng cũng nên tìm hiểu qua.

Coding: SQL, HTML, CSS.

– Automation Test:

Học thêm về lập trình: Java, C# (.Net) là hai ngôn ngữ căn bản mà những người làm automation hay sử dụng, ngoài ra có các ngôn ngữ khác dùng để hỗ trợ như AutoIT, Python.

Học về các Automation Tool/Framework phổ biến như: Ranorex, Selenium, Appium, TestComplete.

Các Tools khác như: Jmeter, SoapUI.

II. Học Tester Như Thế Nào Để Trở Thành Kiểm Thử Viên Giỏi?

Bài viết này chia sẻ với những bạn sinh viên có dự định học Tester và đi làm trong tương lai, hy vọng sẽ cung cấp thêm thông tin giúp các bạn dễ dàng có được định hướng cho con đường của mình

+ Học Tester sau sẽ làm những công việc gì?

Nhìn chung công việc chính của tester là đảm bảo chất lượng của phần mềm, kiểm tra để phát hiện các lỗi đang tồn tại trước lúc giao sản phẩn cho khách hàng, tùy thuộc vào dự án cũng như công ty mà vai trò của tester tham gia sâu đến mức nào. Tester thường chia ra làm 2 hướng chính là Manual test và Automation test.

• Manual testing: đây là lựa chọn của đa số các bạn bắt đầu làm test, với lựa chọn này bạn không cần nhiều kiến thức về lập trình cũng như sẽ ít đụng vào code trong lúc làm, tuy nhiên cần phải nắm khá vững về các định nghĩa, kỹ thuật test manual và có tư duy tìm lỗi tốt.
• Automation testing: đây thường là lựa chọn của các bạn đang làm Developer mà muốn chuyển sang làm Tester, hoặc các bạn làm manual lâu năm muốn học hỏi thêm cái gì đó mới mẻ và nâng cao trình độ của mình. Automation test có thể nói là Dev trong Test, công việc chính là sẽ viết code để thực hiện việc kiểm tra một cách tự động và phần lớn thời gian sẽ làm việc với code như một developer.
• Người làm automation sẽ không cần thiết phải nắm sâu về các kiến thức test manual nhưng thay vào đó phải biết rõ về các automation tools & frameworks cũng như có thể làm việc được trên nhiều ngôn ngữ lập trình khác nhau như Java, C#, AutoIT, Python, C++ v.v, tùy theo yêu cầu dự án.

Automation không phải là nâng cao của manual vì nó là hai nhánh khác nhau, cả hai đều quan trọng cũng như có độ khó nhất định nếu phải học và tìm hiểu sâu. Người làm manual tốt không chắc có thể viết code được và người làm automation cũng chưa chắc sẽ có được tư duy, khả năng quan sát & kiến thức kiểm thử manual nên bạn cứ chọn một hướng phù hợp với khả năng và bắt đầu học, không nên tìm hiểu cùng lúc cả hai trong giai đoạn mới vào sẽ tốn rất nhiều thời gian.

+ Tester cần những kiến thức gì?

– Đầu tiên, tester cũng giống như bất cứ ngành nào khác trong lĩnh vực phần mềm là cần 1 nền tảng căn bản về máy tính. Kiến thức căn bản này bạn có thể học được trong chương trình cao đẳng, đại học. Hiện nay giáo trình đào tạo cao đẳng, đại học về công nghệ thông tin của các trường cũng khá đầy đủ, bao quát nhiều kiến thức như hệ điều hành, database, lập trình, mạng….

Những kiến thức này tuy có vẻ không ứng dụng được gì trong lúc học nhưng sẽ rất hữu ích cho việc học test và đi làm sau này, nếu bạn tập trung học trong giai đoạn sinh viên thì sau khi ra trường việc học thêm một khóa về kiểm thử là khá nhanh và đơn giản hơn nhiều.

– Nếu bạn học ngành khác nhưng muốn chuyển sang làm test (chưa học gì nhiều về công nghệ thông tin trong trường) thì sẽ khó khăn và tốn nhiều thời gian hơn vì bạn phải học lại căn bản, cũng như sẽ bị sót nhiều kiến thức nếu chỉ đăng ký một khóa học test ngắn hạn.

Nhưng nói vậy không có nghĩa là không thể, cũng có nhiều bạn đang làm test và khá thành công nhưng xuất phát từ các ngành khác như sư phạm, kinh tế. Nếu bạn cũng đang học trái ngành thì có 2 bước cần thực hiện đó là dành thời gian học cách sử dụng tốt máy tính, tin học văn phòng, đọc thêm các sách căn bản về máy tính, lập trình (có thể mượn từ các bạn đang học CNTT).

Giai đoạn này sẽ tốn khoảng 3 tới 6 tháng (hoặc hơn), tuy hơi dài nhưng sẽ rất có giá trị. Tiếp theo bạn cần học thêm về các kiến thức chuyên ngành testing, giai đoạn này sẽ ngắn hơn, thường là khoảng 2 đến 3 tháng, chi tiết học gì tôi sẽ nói ở phần sau.

– Tiếng Anh, cái này không liên quan test nhưng rất quan trọng, tiếng Anh tốt bạn có nhiều cơ hội để đậu vào các công ty hơn cũng như dễ dàng học thêm về test sau này vì tài liệu đa số là tiếng Anh.

Vậy tóm tắt lại, có 3 kiến thức tester cần trang bị là Nền tảng về máy tính + Kiến thức Test căn bản + Tiếng Anh

+ Học gì để trở thành tester?

*Kiến thức chung: (dù bạn chọn theo hướng nào thì cũng nên nắm các kiến thức này).

– Kiến thức căn bản về máy tính, tin học văn phòng căn bản, cài đặt phần mềm, sử dụng internet.

– Kiến thức về lập trình: Căn bản SQL, HTML, CSS. Đây là 3 món tôi nghĩ rất cần thiết khi làm test, bạn không cần phải học sâu để viết code nhưng ít ra phải đọc hiểu được và có thể chỉnh sửa code đơn giản.

– Kiến thức tổng quan về test, bao gồm việc hiểu các định nghĩa cơ bản, các thuật ngữ, quy trình phát triển phần mềm, quy trình test. Bạn có thể học theo cuốn ISTQB Foundation hoặc tham khảo các mục gợi ý sau:

• What is Software Testing? – Tìm hiểu phần này để biết được testing là gì? các định nghĩa, khái niệm căn bản về kiểm thử phần mềm.
• Why is Software Testing Important? – Tại sao testing lại quan trọng và cần thiết? nếu không có tester thì sản phẩm sẽ ra sao?
• Software Development life cycle: Vòng đời phát triển phần mềm, vị trí của testing trong các giai đoạn phát triển sản phẩm.
• Software Test life cycle: Vòng đời của kiểm thử, thứ tự các công việc kiểm thử.
• Defect Life Cycle: Vòng đởi của lỗi và trạng thái qua các giai đoạn.
• Quality Assurance vs. Quality control, Verification vs Validation: Phân biêt sự giống nhau và khác nhau giữa một số khái niệm.
• Software Testing Levels: Các mức độ trong kiểm thử, đi từ nhỏ nhất đến các mức độ cao nhất.
• Software Testing types: Các loại testing thư Functional testing, Non-functional testing, Structural testing, Change related testing.

*Phần kiến thức riêng:

Manual Test:

Đây là danh sách các kiến thức bạn nên tìm hiểu sâu thêm nếu sẽ làm test theo hướng manual:

• Create a Test Plan: Các thành phần cần có trong một test plan cơ bản, cách viết test plan.
• Design Test case: Cách tạo và viết một testcase thông dụng.
• Test Design Techniques: Các kỹ thuật thiết kế testcase, giúp cho testcase hiệu quả và tối ưu hơn.
• Test reporting, Daily status reports – cách viết report để báo cáo kết quả test của mình.
• Defect management: Finding defects, Logging defects, Tracking and managing defects – Học cách report & quản lý một bug cũng như sử dụng tools tracking thông dụng như Jira, Mantis, Bugzilla, Application Lifecycle Management (ALM).
• Mobile application testing (iOS, Android, Windows Phone): Cách cài đặt và test ứng dụng mobile, cách giả lập thiết bị điện thoại trên máy tính.
• Windows, Website testing & Tools support: Cách test một ứng dụng desktop, một trang web và giả lập các trình duyệt khác nhau trên máy tính.
• Risk based testing process and implementation: Đánh giá rủi ro trong kiểm thử, đây là phần nâng cao nhưng cũng nên tìm hiểu qua.
• Coding: SQL, HTML, CSS.

Một số trang để tự học các kiến thức về manual testing căn bản, các trang này cung cấp đầy đủ các kiến thức bên trên cũng như mở rộng thêm khá nhiều kiến thức liên quan đến test khác:

• Software Testing Tutorial – Guru99
• Software Testing Tutorial – Tutorials Point
• Software Testing Class
• Software Testing Help
• W3Schools (HTML, CSS)
• SQL Tutorial – W3Schools
• SQL Tutorial – TutorialsPoint

Automation Test:

Học thêm về lập trình: Java, C# (.Net) là hai ngôn ngữ căn bản mà những người làm automation hay sử dụng, ngoài ra có các ngôn ngữ khác dùng để hỗ trợ như AutoIT, Python.

• Học về các Automation Tool/Framework phổ biến như: Ranorex, Selenium, Appium, TestComplete.
• Các Tools khác như: Jmeter, SoapUI.

Các địa chỉ học về Automation & Lập trình:

• Selenium User Guide
• Selenium Tutorials – Guru99
• Selenium Training Tutorials – Software Testing Help
• Ranorex User Guide
• Jmeter
• SoapUI
• Java2S
• Python tutorial – TutorialsPoint
• C# Tutorial – TutorialsPoint

Nếu chưa biết nên bắt đầu từ đâu bạn có thể bắt đầu với bộ tools Selenium (thường dùng Java) hoặc Ranorex (C# hoặc .Net nói chung). Với Selenium (miễn phí) bạn có thể làm được automation cho website còn Ranorex thì có thể làm được trên website, mobile application và desktop application nhưng có tốn phí khá cao.

+ Học test ở đâu?

Có ba cách cơ bản để học test là tự học, học ở trung tâm và học nhóm. Đa số các tester thuộc thế hệ 8x hay 9x đời đầu đều tự học mà làm vì giai đoạn đó testing chưa phát triển và cũng chưa có trung tâm chuyên đào tạo, các trường đại học cũng chưa đưa vào chương trình dạy. Đa số tester ở giai đoạn này thường xuất thân từ CNTT nên việc tự học và học thêm về test cũng khá nhanh. Để tự học test bạn có thể vào các nguồn tôi cung cấp ở phần bên trên, nó khá đầy đủ kiến thức căn bản.

Thứ hai là có thể đi học ở trung tâm hay một nhóm nào đó, các trung tâm thường có các khóa đào tạo ngắn hạn trong khoảng 3 tháng đỗ lại, một số trung tâm thì có chương trình dài hơn nhưng thường không quá 6 tháng. Stanford là trung tâm đào tạo bài bản và chất lượng về kiểm thử phần mềm bạn sẽ được thực hành qua dự án thực tế để có thể đi làm ngay sau khóa học.

Ngoài ra còn một cách học khác là học nhóm, dạy kèm test, phương pháp này khá hiệu quả vì nó vừa linh động về thời gian và số lượng học viên thường giới hạn ít nên sẽ dễ tiếp thu hơn, thời gian học khoảng 1 đến 2 tháng.

III. Học Gì Để Trở Thành Một Tester?

Trong lĩnh vực phần mềm Tester hay còn gọi là Engineer là nghề kiểm tra chất lượng phần mềm. Tester sẽ là người kiểm tra những sản phẩm (phần mềm hay ứng dụng) mà các lập trình viên đã làm ra. Vậy học gì để trở thành tester?

+ Kiến thức chung

• Kiến thức căn bản về máy tính, tin học văn phòng căn bản, cài đặt phần mềm, dùng internet.
• Kiến thức về lập trình: Căn bản SQL, HTML, CSS. Đây là 3 món tôi nghĩ rất cần thiết lúc làm test, bạn không cần phải học sâu để viết code nhưng ít ra phải đọc hiểu được và có thể chỉnh sửa code đơn giản.
• Kiến thức tổng quan về test, bao gồm việc hiểu những định nghĩa cơ bản, các thuật ngữ, quy trình phát triển phần mềm, quy trình test. Bạn có thể học theo cuốn ISTQB Foundation hoặc tham khảo các mục gợi ý sau:
• What is Software Testing? – Tìm hiểu phần này để biết được testing là gì? các định nghĩa, khái niệm căn bản về kiểm thử phần mềm.
• Why is Software Testing Important? – Tại sao testing lại quan trọng và cần thiết? giả dụ không có tester thì sản phẩm sẽ ra sao?
• Software Development life cycle: Vòng đời phát triển phần mềm, vị trí của testing trong các giai đoạn phát triển sản phẩm.
• Software Test life cycle: Vòng đời của kiểm thử, thứ tự các công việc kiểm thử.
• Defect Life Cycle: Vòng đởi của lỗi và trạng thái qua các giai đoạn.
• Quality Assurance vs. Quality control, Verification vs Validation: Phân biêt sự giống nhau và khác nhau giữa một số khái niệm.
• Software Testing Levels: Các mức độ trong kiểm thử, đi từ nhỏ nhất tới các mức độ cao nhất.
• Software Testing types: Các loại testing thư Functional testing, Non-functional testing, Structural testing, Change related testing.

+ Phần kiến thức bổ sung

Manual Test:

Đây là danh sách các kiến thức bạn nên tìm hiểu sâu thêm nếu sẽ làm test theo hướng manual.

• Create a Test Plan: Các thành phần cần có trong một test plan cơ bản, cách viết test plan.
• Design Test case: Cách tạo và viết một testcase thông dụng.
• Test Design Techniques: Các kỹ thuật thiết kế testcase, giúp cho testcase hiệu quả và tối ưu hơn.
• Test reporting, Daily status reports – cách viết report để báo cáo kết quả test của mình.
• Defect management: Finding defects, Logging defects, Tracking and managing defects – Học cách report & quản lý một bug cũng như sử dụng tools tracking thông dụng như Jira, Mantis, Bugzilla, Application Lifecycle Management (ALM).
• Mobile application testing (iOS, Android, Windows Phone): Cách cài đặt và test ứng dụng mobile, cách giả lập thiết bị điện thoại trên máy tính.
• Windows, Website testing & Tools support: Cách test một ứng dụng desktop, một trang web và giả lập các trình duyệt khác nhau trên máy tính.
• Risk based testing process and implementation: Đánh giá rủi ro trong kiểm thử, đây là phần nâng cao nhưng cũng nên tìm hiểu qua.
• Coding: SQL, HTML, CSS.

Automation Test:

• Học thêm về lập trình: Java, C# (.Net) là hai ngôn ngữ căn bản mà những người làm automation hay sử dụng, ngoài ra có các ngôn ngữ khác dùng để hỗ trợ như AutoIT, Python.
• Học về các Automation Tool/Framework phổ biến như: Ranorex, Selenium, Appium, TestComplete.
  Các Tools khác như: Jmeter, SoapUI.

IV. Chi Phí Học Tester Bao Nhiêu Tiền, Có Đắt Không?

Hiện nay, do nhu cầu của các bạn trẻ khá nhiều nên rất nhiều trung tâm đào tạo Tester đã được mở ra với nhiều mức chi phí khác nhau. Chính điều này đã khiến cho mọi người hoang mang không biết chi phí học Tester bao nhiêu tiền?

Theo như tìm hiểu của chúng tôi thì chi phí học Tester hiện nay không cố định, tại một trung tâm lại có mức chi phí khác nhau. Cụ thể mức chi phí học hiện nay thường dao động từ hơn 3 triệu – 7 triệu đồng.

Bên cạnh đó, có rất nhiều địa chỉ không uy tín mở ra những khóa học rẻ tiền để lôi kéo học viên nhưng khi học viên tham gia khóa học thì sẽ không được giảng dạy chu đáo. Bởi vậy, khi lựa chọn khóa học thì các bạn nên đến các địa chỉ uy tín để tránh mất tiền oan nhé.

Techacademy – Trung tâm đào tạo Tester hàng đầu với chi phí phải chăng

Là một trong số các trung tâm đào tạo Tester hàng đầu hiện nay Techacademy đang trở thành sự lựa chọn của rất nhiều học viên.

Hiện tại, khóa học Tester tại Techacademy gồm có lộ trình học đầy đủ và học trong vòng 1 tới 1,5 tháng với mức học phí là khoảng 3 triệu đồng.

Khi đến với Techacademy bạn sẽ được:

– Trang bị đầy đủ kiến thức với lộ trình phù hợp

Các khóa học tester mà Techacademy xây dựng từ các khóa học tester cho người mới bắt đầu tới những kiến thức chuyên sâu để giúp bạn nắm được kiến thức và thực hành thành thạo trong thời gian nhanh nhất.

Đặc biệt, Techacademy còn rèn luyện cho học viên các kỹ năng kiểm thử thông qua các tình huống thực tế. Điều này sẽ giúp các học viên có thể thích nghi nhanh với công việc này khi làm việc tại các doanh nghiệp.

– Kiến thức được chia sẻ kinh nghiệm từ giảng viên lâu năm

Các giảng viên của Techacademy đều là các chuyên gia Tester. Với phương pháp giáo dục tiên tiến và không ngừng sáng tạo, các giảng viên sẽ mang đến môi trường học với nhiều kiến thức bổ ích lý thú. Điều này giúp các học viên cảm thấy tiết học luôn cuốn hút để tiếp thu đầy đủ kiến thức.

Không chỉ vậy, các giảng viên còn chia sẻ những kinh nghiệm thực tế tại từ các dự án thực tế để giúp các học viên có thêm những kỹ năng mềm cho quá trình làm việc tại các doanh nghiệp.

– Cấp chứng chỉ cho học viên sau lúc hoàn thành khóa học tester.

Sau khi kết thúc khóa học, trung tâm sẽ cấp chứng chỉ cho các học viên. Đồng thời, trung tâm còn hỗ trợ giới thiệu thông tin việc làm cho các học viên có thành tích xuất sắc ngay sau khóa học với các doanh nghiệp liên kết với trung tâm.

The post Học Tester Mất Bao Lâu? first appeared on Techacademy.

source https://techacademy.edu.vn/hoc-tester-mat-bao-lau/