Testing là gì?
Thường thì mọi người hiểu khái niệm test chỉ là chạy test, chạy phần mềm nhưng đó chỉ là một phần không phải tất cả các hoạt động test.
Các hoạt động test tồn tại trước và sau khi chạy PM bao gồm: lên kế hoạch và kiểm soát, chọn điều kiện test, thiết kế và chạy test case, test kết quả, đánh giá tiêu chí kế hoạch, báo cáo trong quy trình test và các hoạt động đóng sau khi giai đoạn test hoàn thành.
Test bao gồm cả review tài liệu, source code, phân tích.
Cả dynamic và static testing được sử dụng đồng thời để đạt được mục đích giống nhau và sẽ cung cấp thông tin để cái tiến hệ thống đang được test và các quy trình.
Các mục tiêu điển hình của Testing
- Để đánh giá các sản phẩm như requirements, user stories, design and code.
- Để xác minh xem tất cả các yêu cầu đã được thực hiện đầy đủ chưa?
- Để xác thực xem đối tượng test đã hoành thành chưa? và hoạt động có như người dùng và các bên liên quan khác mong đợi không?
- Để xây dựng sự tự tin về mức độ chất lượng.
- Để ngăn ngừa lỗi.
- Để tìm failures và lỗi
- Cung cấp đầy đủ thông tin cho các bên liên quan để cho phép họ đưa ra quyết định sáng suốt, đặc biệt là về mức độ chất lượng của đối tượng test.
- Để giảm mức độ rủi ro về chất lượng phần mềm không đầy đủ
- Tuân tủ các yêu cầu hoặc tiêu chuyển theo hợp đồng, pháp lý hoặc theo quy trình để xác minh đối tượng test tuân thủ các yêu cầu hoặc tiêu chuẩn đó.
Các mục đích khác nhau trong từng giai đoạn test:
- Trong component testing, một mục tiêu có thể là tìm ra càng nhiều lỗi các tốt để các defect cơ bản được xác định và khắc phục sớm. Một mục tiêu khác có thể là tăng độ bao phủ test của các thành phần.
- Trong quá trình test chấp nhận (acceptance testing), một mục tiêu có thể là xác nhận rằng hệ thống hoạt động như mong đợt và đáp ứng các yêu cầu. Một mục tiêu khác của test này có thể là cung cấp thông tin cho các bên liên quan về rủi ro của phát hành hệ thống tại một thời điểm nhất định.
Sự khác nhau giữa Testing và Debugging
| Testing | Debugging |
| Test động tìm ra các hỏng học gọi là lỗi. | Debugging là hoạt động phát triển phần mềm để tìm, phân tích và sửa các lỗi đó |
| Test xác nhận xem các bản sửa lỗi có giải quyết được chính xác lỗi không |
Testing bao nhiêu là đủ
Phụ thuộc vào RISK:
- Rủi ro của việc không nhìn thấy các lỗi quan trọng
- Rủi ro của việc phát sinh chi phí lỗi
- Rủi ro của việc phát hành phần mềm chưa được kiểm tra
- Nguy cơ mất uy tín và thị trường
- Nguy cơ thiếu một cánh cửa thị trường
- Rủi ro trong việc test quá mức, test không hiệu quả.
Thời gian test luôn bị giới hạn – Sử dụng RISK để xác định:
- Test gì trước?
- Test gì nhiều hơn?
- Làm thế nào để kiểm tra kỹ lưỡng từng hạng mục
- Cái gì không test?
- Phân bố thời gian hợp lý cho việc testing bằng việc phân thứ tự ưu tiên
Tại sao lại cần Testing?
- Đảm bảo các chức năng của hệ thống chạy đúng
- Đảm bảo các chất lượng của hệ thống: độ tin cậy, tính sử dụng, bảo trì, tái sử dụng, khả năng test…
- Chất lượng được đo đạc bằng lỗi được tìm thấy trong các yêu cầu và đặt tính về chức năng và phi chức năng Ví dụ độ đo: Công sức tìm lỗi: số lỗi/ thời gian bỏ ra; Tỷ lệ lỗi lọt sang KH= số lỗi KH tìm đc / Tổng số lỗi ( đội dự án + KH).
- Có thể giảm rủi ro cho các vấn đề có thể xảy ra trong quá trình vận hành phần mềm.
- Khi phát hiện lỗi và sau đó sửa lỗi đó, điều này góp phần vào chất lượng của các thành phần hoặc hệ thống.
- Test PM cũng là 1 yêu cầu trong hợp đồng và các yêu cầu pháp lý hoặc chuẩn công nghiệp.
Đóng góp của Testing vào PM
Kiểm thử đóng góp vào sự thành công trong việc phát triển và bảo trì phần mềm tổng thể. Ví dụ:
| Giai đoạn | Đóng góp |
| Test than gia vào đánh giá yêu cầu hoặc sàng lọc yêu cầu người dùng có thể phát hiện lỗi | Giảm nguy cơ chức năng không chính xác hoặc không thể kiểm chứng đang được phát triển |
| Tester làm việc chặt chẽ với designer trong khi hệ thống đang được thiết kế có thể tăng hiểu biết và cách test. | Giảm nguy cơ lỗi thiết kế cơ bản và cho phép các test được xác định ở giai đoạn đầu |
| Tester làm việc chặt chẽ với developer trong khi code có thể tăng sự hiểu biết và cach test. | Giảm nguy cơ lỗi trong code và các bài test |
| Tester xác minh và xác thực phần mềm trước khi phát hành có thể phát hiện lỗi | Tăng khả năng phần mềm đáp ứng nhu cầu của các bên liên quan và đáp ứng các tiêu chuẩn. |
Phân biệt đảm bảo chất lượng (Quality Assurance) và Testing
Đảm bảo chất lượng và Test không giống nhau, nhưng chúng có liên quan:
- Quản lý chất lượng (Quality management) bao gồm tất cả các hoạt động chỉ đạo và kiểm soát một tổ chức về chất lượng, bao gồm cả đảm bảo chất lượng và kiểm soát chất lượng.
- Đảm bảo chất lượng thường tập trung vào việc tuân thủ các quy trình thích hợp, để đảm bảo rằng mức độ chất lượng phù hợp sẽ đạt được.
- Đảm bảo chất lượng góp phần ngăn ngừa defect
- Kiểm soát chất lượng liên quan đến các hoạt động khác nhau, bao gồm các hoạt động test, hỗ trợ đạt được mức chất lượng phù hợp. Các hoạt động test là một phần của quy trình bảo trì hoặc phát triển phần mềm tổng thể.
- Vì đảm bảo chất lượng liên quan đến việc thực hiện đúng toàn bộ quy trình, đảm bảo chất lượng hỗ trợ test thích hợp.
Phân biệt Errors, Defects and Failures
Error: một hành động của con người tạo ra một kết quả không chính xác Defects/Fault: một biểu hiện của một lỗi trong phần mềm(sai tài liệu)
Failures: độ lệch giữa phần mềm thực tế sai khác với mong đợi
Lỗi(Errors) có thể xảy ra vì nhiều lý do, chẳng hạn như:
- Áp lực về thời gian
- Người tham gia dự án thiếu kinh nghiệm hoặc không đủ kỹ năng
- Thông tin sai lệch giữa những người tham gia dự án, bao gồm cả thông tin sai lệch về các yêu cầu và thiết kế.
- Độ phức tạp của code, thiết kế, kiến trức, vấn đề cơ bản cần giải quyết và/hoặc các công nghệ được sử dụng
- Những hiểu lầm về giao diện giữa hệ thống và liên hệ thống, đặt biệt là khi các tương tác giữa hệ thống và liên hệ thống đó có số lượng lớn
- Công nghệ mới, lạ
- Ngoài các lỗi gây ra do lỗi trong code, các lỗi cũng có thể được gây ra bởi các điều kiện môi trường
Không phải tất cả các kế quả test không mong muốn đều là Failure:
- False có thể xảy ra do sai trong cách thực hiện các test hoặc do lỗi trong dữ liệu test, môi trường hoặc các phần mềm test khác hoặc vì lý do khác. Tình huống nghịch đảo cũng có thể xảy ra, trong đó các lỗi hoặc defect tương tự dẫn đến lỗi sai.
Cái giá của defect:
- Chi phí tìm kiếm và sửa chữa các lỗi tăng lên đáng kể trong suốt vòng đời
- Phần mềm có chất lượng kém mất chi phí nhiều hơn để sử dụng
- Người dùng mất thời gian nhiều hơn để hiểu những gì để làm
- Người dùng thực hiện nhiều sai phạm trong khi sử dụng nó
- Gây áp lực về tinh thần
- Năng suất thấp
Defects, Root Causes và Effects
- Nguyên nhân gốc rẻ của defect là những hành động hoặc điều kiện sớm nhất góp phần tạo ra nhiều defect
- Xác định nguyên nhân gốc rễ của sự failure có thể.
- Giảm sự xuất hiện của các defect tương tự trong tương lai
- Cải tiến quy trình ngăn chặn một số lượng đánh kể các defect trong tương lai
Nguyên lý cơ bản của testing
Kiểm thử chứng minh sự hiển diện của lỗi
- Test có thể chỉ ra lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi.
- Test làm giảm xác suất của các lỗi chưa được khám phá vẫn còn trong phần mềm nhưng ngay cả khi không có 1 lỗi nào được tìm thấy, nó cũng không phỉa là một bằng chứng về tính đúng đắn phần mềm.
Kiểm thử toàn bộ là không thể
- Test tất cả mọi thứ (tất cả các kết hợp của đầu vào và điều kiện) là không khả thi
- Thay vì test tất cả, phân tích rủi ro và sắp xếp thứ tự ưu tiên nên được sử dụng để taaph trung trong testing
Kiểm thử càng sớm càng tốt
- Các hoạt động test nên bắt đầu càng sớm càng tốt trong chu kỳ phần mềm hoặc toàn bộ vòng đời phát triển và nên tập trung vào mục tiêu được xác định
- Thực hiện test và review càng sớm thì lỗi càng càng được phát hiện khi đó ít tồn công để tìm và sửa chữa.
Lỗi thường được phân bố tập trung
- Một số lượng nhỏ các mô-đun thường có chứa hầu hết các lỗi được phát hiện trong quá trình test trước khi phát hành, hoặc là chịu trách nhiệm cho hầu hết các failure của hệ thống.
- Quy tắc 80/20: Module lỗi thường chứa 80% lỗi. (80% số lượng lỗi được tìm thấy trong 20% tính năng của hệ thống)
Nghịch lý thuốc trừ sâu
- Nếu các case test tương tự được lặp đi lặp lại nhiều lần, không có lỗi mới nào có thể được tìm thấy.
- Để khắc phục nghịch lý thuốc trừ sâu này, các test case cần phải được thường xuyên rà soát và sửa đổi; Test mới và khác đi để tìm ra nhiều lỗi tiềm ẩn hơn
Kiểm thử phụ thuộc vào ngữ cảnh
- Test được thực hiện khác nhau trong bối cảnh khác nhau
- VD: Phần mềm an toàn qua trọng được test khác nhau với một trang web thương mại điện tử
Quan niệm về “hết lỗi” trong phần mềm
- Tất cả các yêu cầu được chỉ định và sửa tất cả các lỗi được tìm thấy vẫn có thể tạo ra một hệ thống khó sử dụng, không đáp ứng nhu cầu và mong đợi của người dùng, hoặc kém hơn so với các hệ thống cạnh tranh khác. (Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường)
(https://viblo.asia/p/cac-khai-niem-co-ban-ve-testing-cho-nguoi-bat-dau-Eb85oVJWl2G)
Bài viết khác
Golang
Golang là gì? Go hay còn gọi là Golang là ngôn ngữ lập trình mã nguồn mở, được thiết kế tại Google bởi Robert Griesemer, Rob Pike, and Ken Thompson. Go có cú pháp giống với C và tất nhiên nó là ngôn ngữ lập trình biên dịch (compiled programming language) Cú pháp của ngôn […]
Elasticsearch
Elasticsearch là gì? Elasticsearch là một search engine (công cụ tìm kiếm) rất mạnh mẽ. Elasticsearch cũng có thể coi là một document oriented database, nó chứa dữ liệu giống như một database và thực hiện tìm kiếm trên những dữ liệu đó. Đại khái là thay vì bạn tìm kiếm trên file, trên các […]
Web Security
Có rất nhiều lý do để học về web security như: Bạn là một người dùng lo lắng về việc thông tin cá nhân bị rò rỉ. Bạn là một web developer muốn làm cho trang web của bạn bảo mật hơn. Bạn là một web developer đang tìm việc, và bạn muốn sẵn sàng […]
Cache
Trong vài năm trở lại đây, công nghệ thông tin đã trở thành bàn đạp cho sự cải thiện mạnh mẽ cho vô số các loại hình kinh doanh. Song song, kiến trúc của các phần mềm cũng ngày càng trở nên phức tạp và số lượng người dùng của chúng đã và đang tăng […]
Docker
Docker là gì? Docker là một nền tảng phần mềm giúp bạn building, deploying và running ứng dụng dễ dàng hơn bằng cách sử dụng các containers (trên nền tảng ảo hóa). Docker ban đầu Docker được viết bằng PyDockerthon, hiện tại đã chuyển sang Golang. Docker đóng gói phần mềm thành các container tiêu […]
Gin vs Iris Framework
Từ 2018, Golang nổi lên là một ngôn ngữ lập trình rất phù hợp để lập trình web, microservice cạnh tranh mạnh với (Node.js + JavaScript), (ASP.net Core + C#), (Spring Boot + Java), (Laravel + PHP). Đặc điểm của Golang là ngôn ngữ lập trình đơn giản dễ học, không có những pattern OOP […]
Khoá học lập trình game con rắn cho trẻ em 
