Tài liệu kiểm thử phần mềm

     

Trong các công ty phần mềm chủ yếu họ thường gặp gỡ "kiểm thử" ở sắc thái là các thiếu nữ gái (xinh đẹp và cá tính) ngồi viết test case dựa trên những tài liệu biểu hiện và aceptance criterial. Sau đó, dựa vào test case sẽ triển khai "test" ứng dụng do các lập trình viên có tác dụng ra. Mỗi khi phát hiện ra lỗi, bà mẹ tester call nó là "bug" mà bạn bè developer thì bao biện lại là "feature".

Bạn đang xem: Tài liệu kiểm thử phần mềm

*

Một câu chuyện vui vậy thôi, dù là "bug" tuyệt "feature" trường hợp nó có tác động đến quality phần mềm thì developer sẽ buộc phải là tín đồ sửa (tùy vào đặc điểm urgent cơ mà sửa luôn luôn hoặc sắp lịch mà fix-bug).

Để bảo vệ chất lượng phần mềm, không chỉ cần một vài fan mở đi lật lại phần mềm, lặp đi tái diễn một vào thao tác bằng tay thủ công hoặc bởi một vài lao lý là đủ,câu chuyện bên trên chỉ là một trong trong số các các phương thức kiểm test phần mềm. Trong nội dung bài viết này, tôi xin share một số "keyword" về kiểm test phần mềm, các bạn cũng có thể tìm hiểu sâu rộng về nghề nghiệp và công việc này bằng cách search google hoặc đọc các tài liệu về software testing nhé.

1. Kiểm thử ứng dụng là gì?

Là một tiến trình hay như là một tập hợp các tiến trình có thiết kế ra để:

Đảm bảo phần mềm thực hiện đúng theo phần nhiều thứ mà bọn chúng đã được thiết kế.Trong quy trình sử dụng ứng dụng không vạc sinh bất cứ thứ gì không hy vọng muốn.

Đây là một trong những pha quan trọng đặc biệt trong quy trình phát triển hệ thống phần mềm:

Giúp cho người tiêu dùng thấy được sản phẩm đề ra đã thỏa mãn nhu cầu được yêu cầu hay chưa.Đảm bảo chất lượng phần mềm khi giới thiệu sử dụng. Tránh các rủi ro lúc cho người sử dụng khi đưa phần mềm vào sử dụng.Giảm thời hạn và giá cả phát sinh vị bảo trì (fix lỗi) mang đến người viết phần mềm.

Có 2 kiểu kiểm thử phần mềm:

Kiểm test tĩnh (Static testing)Kiểm thử rượu cồn (Dynamic testing)1.1. Kiểm test tĩnh (Static testing)Là phương pháp kiểm thử phần mềm thủ công.Phương pháp này hay được những người phân tích kiến tạo phần mượt (IT-BA) thực hiện.

Cách thực hiện:Dùng giấy, bút và trí "tưởng tượng" để khám nghiệm logic, đánh giá từng chi tiết luồng nghiệp vụ theo yêu ước đề bài bác mà không đề xuất chạy chương trình.

Mục đích:Cách làm cho này có thể sẽ giúp cha phát hiện ra hầu như thiếu xót trong đề bài để bổ sung cập nhật tài liệu trước lúc chuyển sang mang lại DEV.

Đôi khi static testing có khả năng sẽ bị nhầm lẫn với việc bố đưa tài liệu cho những bên tương quan (khách hàng/đại diện khách hàng hàng/product owner) để reviews trước khi bàn giao tài liệu sang pharse bắt đầu (DEV).

1.2. Kiểm thử đụng (Dynamic testing)

Phương pháp thử ứng dụng thông qua vấn đề chạy công tác để quan sát và theo dõi trạng thái, tác dụng của từng bước / toàn bộ công việc trong quy trình thực thi phần mềm.

Cách triển khai dựa trên những ca kiểm thử (test case) xác định bằng sự buổi giao lưu của đối tượng kiểm test hay toàn bộ chương trình.

Kiểm tra phương pháp hoạt rượu cồn động của mã lệnh, bao gồm luôn cả chất vấn sự phản ứng thứ lý từ khối hệ thống tới các biến luôn biến hóa theo thời gian.

Mục đích:Trong kiểm test động, tester suy xét dữ liệu đầu vào và output đầu ra đầu ra.

Với từng tập dữ liệu đầu vào đang phát hình thành một tập dữ liệu output

Nếu chương trình nhận đầu vào để “chạy” tiếp đến đưa ra dữ liệu output hệt như yêu cầu. Có thể nói đó là ứng dụng đã hoạt động thành công.

Các phương pháp phân nhiều loại kiểm demo động:Có hai phe cánh phân loại kiểm thử

1. Phân loại theo kế hoạch kiểm thử2. Phân loại theo mức độ kiểm thử

2. Các cách phân loại kiểm test động

2.1. Phân loại theo chiến lược kiểm thử

Black box testing

Xem chương trình như một “hộp đen”.Kiểm thử dựa trên đặc tả của phần mềm.Không quan tiền tâm cấu trúc bên trong của chương trình, tập trung tìm các trường hợp mà chương trình không thực hiện theo đặc tả của nó.

*

Đặc điểm:

Không cần biết tới code và cấu trúc chương trình.Đánh giá chương trình khách quan.Hạn chế: nhiều trường hợp áp dụng nhiều ca kiểm thử để kiểm tra trong lúc chỉ cần 1 trộn kiểm thử duy nhất “Thăm dò mù”.

Các phương pháp:

Phân lớp tương tự - Equivalence partitioningPhân tích quý hiếm biên - Boundary value analysisKiểm thử gần như cặp - ALl-pairs testingKiểm test fuzz - Fuzz tesingKiểm demo dựa trên mô hình - Model-based testingMa trận vệt viết - Traceability matrixKiểm test thăm dò - Exploratory testingKiểm thử dựa vào đặc tả - Specification-base testing

White box testing

Còn được gọi là clear box testing, glass box testing, transparent box testing.Thường thiết kế những trường hợp kiểm test dựa vào cấu trúc bên phía trong của phần mềm

*

Đặc điểm:

WBT đòi hỏi chuyên môn lập trình am hiểu cấu trúc phía bên trong của phần mềm ( các xúc tích và ngắn gọn nghiệp vụ, luồng dữ liệu, chức năng, kết quả ).Phương thức: Chọn các đầu vào và xem những đầu ra.Phụ thuộc vào các setup hiện tại của khối hệ thống và của phần mềm, nếu bao gồm sự vậy đổi thì bài xích test cũng phải thay đổi theo.Được ứng dụng trong số kiểm tra ở cấp độ module ( điển hình), tích hợp ( có công dụng ) và khối hệ thống của quá trình test phần mềm.

Các phương pháp:

Kiểm test API: Là cách thức kiểm thử ứng dụng sử dụng những public và private API.Bao đậy mã lệnh (code coverage): Tạo các kiểm tra để đáp ứng một số tiêu chuẩn chỉnh về kiểm thử mã lệnh.Các phương thức gán lỗi (Fault injection)Các phương thức kiểm test hoán gửi (mutation testing method)Gray (grey) box testing

Kết đúng theo của black-box với white-box testing.

2.2. Phân loại theo nấc độ

Mức độ ở đó là mỗi quy trình tiến độ kiểm test sẽ thỏa mãn nhu cầu các yêu cầu hoặc tế bào tả tương xứng nào.

Xem thêm: Đề Tài Liệu Xử Lý Nước Thải Sinh Hoạt, (Pdf) Giáo Trình Công Trình Xử Lý Nước Thải

*

Unit Testing:

Kiểm test trên các thành phần độc lập nhỏ tuổi nhất của phần mềm.

Thông thường, ứng dụng được chia bé dại ra những thành phần tự do nhau: Function -> Class -> Module -> Package. Xây dựng viên sau khi lập trình ra các thành phần, từ viết chương trình unit testing để bảo đảm dữ liệu vì chưng mình chế tạo ra vận động bình thường.

Unit-testing thường xuyên được thực hiện bởi những developer có tác dụng trực tiếp hoặc các leader viết nhằm kiểm thử source code của team phạt triển. Ở một số công ty câu hỏi viết unit-test gần như là là yêu cầu và từng lần chuyển đổi source code câu hỏi pass qua các bài unit-test trước khi đưa sản phẩm nên PRODUCTION.

Tất nhiên là việc viết unit-test sẽ chiếm kha khá thời hạn của các developer phải trong thực tế nhiều công ty/team quăng quật qua câu hỏi này. Nếu bỏ lỡ unit-test thì "gánh nặng" về quality phần mềm sẽ đè xuống giai đoạn kiểm demo tiếp theo.

Intergration Test: Kiểm demo tích hợp

Thực hiện tại test câu hỏi kết nối, ghép nối giữa những unit/module.

Mục tiêu:

Phát chỉ ra lỗi tiếp xúc giữa những unitPhát hiện tại lỗi giao tiếp giữa hệ thống và các khối hệ thống khác (DB, Queue, …)Chuẩn bị cho System test

Ở tiến độ này, developer và tester bắt đầu có sự kết hợp với nhau để làm việc (đặc biệt là các team làm việc theo Scrum framework). Developer phối kết hợp với thành phần hạ tầng IT/devops nhằm xây dựng những kết nối giữa các khối hệ thống (cron-job, queue/background job, database, api,...). Tiếp nối tester có thể bước đầu các bài bác test về liên kết giữa những module.

System kiểm tra – Kiểm thử hệ thống:

Kiểm thử thiết kế và toàn bộ hệ thống (sau lúc tích hợp) có thỏa mãn yêu cầu đặt ra xuất xắc không.

System test bao gồm các nhiều loại kiểm thử:

Kiểm thử chức năng (Functional Test)Kiểm thử hiệu năng (Performance Test)Kiểm thử khả năng chịu tải (Stress demo hay Load Test)Kiểm thử cấu hình (Configuration Test)Kiểm thử bảo mật (Security Test)Kiểm thử khả năng phục hồi (Recovery Test)

Giai đoạnsystem testlà giai đoạn phối hợp giữa tất cả các thành phần trong khối technology thông tin nhằm thực hiện. Ví dụ:Functional Testdo những tester tiến hành dựa trên những mô tả/yêu ước của phần mềm.Security demo do bộ phận an toàn thông tin thực hiện.Recovery Testsẽ do bộ phận quản trị cơ sở tài liệu thực hiện.....

--> sẵn sàng cho Acceptance test

Acceptance kiểm tra – Kiểm thử chấp nhận sản phẩm:

Chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm.

Khách hàng hoàn toàn có thể tự test hoặc thuê bên thứ ba tiến hành test.

Kiểm thử Alpha (Alpha Test) và kiểm thử Beta (Beta Test).

Kiểm test Alpha: Được tiến hành trong nội bộ của ban phạt triển ứng dụng với các cộng tác viên là những tester, người tiêu dùng nội bộ hoặc các khách hàng được mời.

Kiểm demo Beta: Được tiến hành với số lượng các "tester" to hơn nhằm phát hiện tại các đổi khác hoặc lỗi trong quá trình đưa ra với người dùng.

Nếu chúng ta có đùa game, sẽ biết đến các event như Open-beta, Closed-Beta,... Là những cách nhà xuất bạn dạng game chuyển sản phẩm reviews các game thủ.

Release Testing:

Release testing được thực hiện sau khi triển khai phần mềm lên khối hệ thống thật.

Các bộ phận liên quan tiền sẽ chuẩn bị tập dữ liệu để kiểm demo trên hệ thống production. Đây là giai đoạn cực kỳ quan trọng, quyết định sản phẩm sẽ đưa ra để khách hàng sử dụng giỏi hoãn lại (nếu tất cả thể) hoặc rollback lại version trước đó.

Kết luận

Với con số keyword phía trên hy vọng để giúp đỡ mọi người bổ sung thêm các góc nhìn về kiểm thử phần mềm.

Tùy vào khả năng quản lý và vận hành và bài bản của dự án/sản phẩm mà những công ty sẽ áp dụng các phương pháp kiểm thử đảm bảo chất lượng ứng dụng khác nhau. đặc trưng nhất là khả năng kết hợp giữa các thành phần trong tiến trình phát triển phần mềm sẽ mang lại một thành phầm tốt.