Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm và phát hiện ra các lỗi của phần mềm, đảm bảo phần mềm chính xác, đúng và trọn vẹn theo yêu cầu của khách hàng, yêu cầu của sản phẩm đã đặt ra. Software testing cũng gửi tới mục tiêu, cái nhìn độc lập về phần mềm điều này cho phép đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Căn cứ là gì? Hãy cùng LVN Group nghiên cứu thông qua nội dung trình bày dưới đây
1. Bug là gì?
Bug là những lỗi phần mềm được tạo ra trong quá trình code. Lỗi này có thể do code sai hoặc gặp các vấn đề không tương thích. Cũng có thể là lỗi do không hiểu ý tưởng và code sai lệch với yêu cầu ban đầu.
Thông thường bug sẽ được các tester kiểm định chất lượng và phát hiện, xử lý trước khi đưa sản phẩm đến người dùng. Quá trình tìm lỗi gọi là Debug và quá trình sửa bug thì gọi là Fixbug. Đây là cách nâng cao chất lượng của một sản phẩm trước khi chúng được người dùng trải nghiệm.
2. Kiểm thử là gì?
Đây là một trong những loại kiểm thử phần mềm cần thiết để xác nhận xem hệ thống có hoạt động đúng yêu cầu được không. Ở tất cả các mức độ kiểm thử đều được kiểm thử chức năng.
Testing of function là một trong những loại kiểm thử phần mềm cần thiết
Testing of function có thể thực hiện theo 2 quan điểm: business – process – based và requirements-based. Với business – process – based, kiểm thử viên sẽ sử dụng các kiến thức về quy trình nghiệp vụ (mô tả các kịch bản liên quan đến nghiệp vụ của hệ thống mỗi ngày).
Trong khi đó, requirements-based sử dụng các đặc tả yêu cầu của hệ thống làm cơ sở để design test. Để đảm bảo những thành phần cần thiết nhất đều được kiểm thử, hãy xem xét độ ưu tiên của yêu cầu dựa trên tiêu chí rủi ro, theo đó, chúng ta sẽ sử dụng độ ưu tiên để kiểm thử.
Các bước kiểm thử chức năng gồm:
Bước 1: Xác định phần mềm sẽ kiểm thử và chức năng của nó
Bước 2: Dựa trên tài liệu đặc tả chức năng để tạo dữ liệu đầu vào
Bước 3: Dựa vào tài liệu đặc tả chức năng để xác định đầu ra
Bước 4: Thực hiện các trường hợp kiểm thử phần mềm
Bước 5: So sánh kết quả thực tiễn với mong muốn đạt được
3. Tại sao phần mềm lại có bug?
Có rất nhiều lý do cho lỗi phần mềm. Lý do phổ biến nhất là những sai lầm của con người trong việc thiết kế phần mềm và mã hóa. Một khi bạn đã biết nguyên nhân gây ra lỗi thì bạn sẽ dễ dàng khắc phục và giảm thiểu các lỗi này.
3.1. Thiếu hoặc không nhận được thông tin chính xác
Thành công của bất kỳ ứng dụng phần mềm nào đều phụ thuộc vào quá trình giao tiếp giữa các bên liên quan, giữa đội ngũ phát triển và kiểm thử phần mềm. Unclear requirements – Yêu cầu không rõ ràng và giải thích sai các yêu cầu là 2 yêu tố chính gây ra lỗi trong phần mềm.
→ Làm rõ ràng thông tin ngay khi nhận được nó. Đảm bảo tính đúng đắn của thông tin mà bạn nhận được.
3.2. Phần mềm phức tạp
Sự phức tạp của các ứng dụng hiện tại có thể khó để hiểu cho bất cứ ai không có kinh nghiệm trong việc phát triển phần mềm.Các giao diện kiểu Windows, client-server và distributed applications, cơ sở dữ liệu quan trọng và kích thước các ứng dụng làm tăng size ứng dụng, hệ thống hay việc sử dụng các kỹ thuật hướng đối tượng phức tạp ngay từ ban đầu. Một dự án được thiết kế kỹ lưỡng ngay từ ban đầu thì sẽ có thể được đơn giản hóa đi rất nhiều.
3.3. Lỗi lập trình
Các lập trình viên thì cũng giống như bất kỳ con người nào trên thế giới và đều có thể mắc lỗi. Không phải tất cả nhà phát triển đều là chuyên gia. Các lập trình viên thiếu kinh nghiệm hoặc kiến thức không tốt có thể mắc những sai lầm trong khi code. Hoặc họ không có giải pháp để viết dòng code đơn giản, hay kiểm tra hay gỡ lỗi. Đó cũng là 1 lý do phổ biến cho hầu hết các vấn đề trong giai đoạn phát triển
Hãy học hỏi và áp dụng những công nghệ mới nhất vào dòng code của mình. Nhưng cần đảm bảo được chất lượng dòng code của mình.
3.4. Yêu cầu thay đổi liên tục
Khách hàng họ không hiểu hoặc có thể hiểu được tác động của những thay đổi, thiết kế lại phần mềm, thay đổi kế hoạch, thời gian khi mà yêu cầu từ ban đầu bị thay đổi. Khi mà công việc từ yêu cầu ban đầu đã xong nhưng vẫn bị ném đi hoặc yêu cầu chỉnh sửa, thay đổi to hay nhỏ thì đều ảnh hưởng tới phần mềm và dễ dàng dẫn đến lỗi phần mềm khi lập trình viện không thể giải quyết hết những vấn đề liên quan, hoặc không thể nhận ra những thay đổi có tầm ảnh hưởng tới chức năng khác như thế nào. Lý do này ngày càng trở nên phổ biến trong hiện nay.
Trong môi trường hiện nay, các yêu cầu liên tục được thay đổi để phù hợp hơn với cuộc sống và nó cũng là một thực tế. Trong trường hợp này thì người quản lý cần đưa ra những rủi ro khi sửa đổi, QA và DEV cần phải lên kế hoạch cho việc phát triển và kiểm thử những thay đổi này để không bị ảnh hưởng hay gây lỗi cho chức năng liên quan.
3.5. Hạn chế thời gian
Việc lên kế hoạch cho các dự án phần mềm là khó khăn nhất, thường là những tính toán phỏng đoán. Khi deadline đến và khủng hoảng xảy ra, sẽ có những sai lầm. Scheduling được lên trước và dựa theo kinh nghiệm của lập trình viên, kiểm thử viên, thiết kế phần mềm. Nếu như họ không thể đảm bảo được đúng theo kế hoạch đã gửi khách hàng ban đầu, họ sẽ không đủ thời gian để code, kiểm tra, thiết kế dự án một các đúng đắn thì khi đó dự án sẽ sót bug.
3.6. Người tự tin thái quá
Vấn đề này rất phức tạp,chúng ta sẽ dễ dàng mắc nhiều lỗi
Chúng ta không thể hiểu được những dòng code cũ,…
3.7. Tài liệu code nghèo nàn
Thật khó khăn trong việc duy trì và sửa đổi code cũ hay code kém. Kết quả là lỗi phần mềm. Trong dự án thì quản lý sẽ yêu cầu dev viết tài liệu hoặc code rõ ràng dễ hiểu, nhưng thực tế thì điều đó khó thực hiện được. Họ chỉ quan tâm làm sao nhanh chóng hoàn thành công việc, và code đó là an toàn nếu không ai khác có thể hiểu được.
Bất kỳ lập trình viên mới bắt đầu làm việc trên dòng code này thì có thể bị lẫn lỗn do sự phức tạp của dự án và tài liệu kém. Họ sẽ phải mất nhiều thời gian hơn để học và thực hiện những thay đổi nhỏ trong dòng code này
Tạo thói quen viết tài liệu cho dòng code của mình, đon giản hóa dòng code của mình.
3.8. Công cụ phát triển phần mềm
Visual tools, class libraries, compilers, scripting tools,…thường đưa ra lỗi của họ nhưng docmented ghi chép lại thì sơ xài, dẫn đến người dùng khi dùng công cụ trên thì vẫn gặp lỗi. Thay đổi liên tục công cụ phần mềm thường được lập trình viên sử dụng. Giữ tiến độ giữa các versions khác nhau và tính tương thích của chúng cũng chính là một vấn đề.
Khi thay đổi versions của công cụ bạn cần đảm bảo những nơi bạn dùng công cụ đều không bị lỗi, hạn chế update versions theo trào lưu.
3.9. Kịch bản tự động hóa lỗi thời
Viết kịch bản test tự động mất rất nhiều thời gian, đặc biệt là các kịch bản phức tạp. Nếu các nhóm tự động record/write bất kỳ kịch bản kiểm thử nào nhưng quên không cập nhật nó trong 1 khoảng thời gian thì kịch bản test có thể bị lỗi thời. Nếu các kịch bản test tự động không phải là xác nhận dựa trên yêu cầu đúng đắn nhất thì nó không thể kiểm tra hết các lỗi được.
Thường xuyên cập nhật kịch bản test tự động, nếu không có thời gian cập nhật thì chỉ nên kế thừa kịch bản test này.
3.10. Kinh nghiệm test còn non kém
Tester có tay nghề với kiến thức là vô cùng cần thiết cho sự thành công của bất kỳ dự án. Nhưng việc chỉ định tất cả các tester có kinh nghiệm là không thể cho tất cả các công ty.
Kiến thức và khả năng tìm lỗi tốt có thể tạo ra phần mềm chất lượng cao. Các Tester ít kinh nghiệm có làm việc cặp cùng với một Tester kinh nghiệm để đảm bảo chất lượng phần mềm, vừa tăng kinh nghiệm của những Tester non kém. Và quan trọng họ cần phải tự bổ sung kiến thức còn thiếu của bản thân mình.Một vài lý do cũng có thể sẽ ảnh hưởng tới chất lượng phần mềm:
- Không có môi trường test
- Viết code hoặc test case mà không hiểu rõ yêu cầu
- Thiết kế không chính xác dẫn đến các vấn đề trong tất cả các giai đoạn của quy trình phát triển phần mềm
- Releasing software và các bản vá phần mềm mà không cần tuân theo vòng đời phát triển phần mềm
- Không đào tạo nguồn lực có kỹ năng cần thiết để phats triển hay kiểm thử phần mềm
- Không dành thời gian cho kiểm thử hồi quy
- Không ưu tiên việc kiểm thử
- Thay đổi trong phút chót