Kiến thức nền tảng Software Testing

Software Testing – Overview

What is Testing?

Testing là quá trình đánh giá một hệ thống hay các thành phần của hệ thống đó với mục đích tìm xem liệu có đáp ứng các yêu cầu được chỉ định hay không. Nói một cách đơn giản, testing là thực thi một hệ thống để xác định bất kỳ lỗ hổng, lỗi hoặc yêu cầu thiếu sót trái với yêu cầu thực tế.

Kiểm thử (Testing) cũng có thể được xem như là quá trình phân tích một phần mềm để phát hiện sự khác biệt giữa điều kiện hiện có và bắt buộc (mục đích tìm kiếm khuyết điểm/nhược điểm, sai lầm, lỗi) và để đánh giá các tính năng của phần mềm.

Who does Testing?

Người được chỉ định kiểm thử phụ thuộc vào qui trình và các bên liên quan của dự án. Trong ngành CNTT, các công ty lớn có một đội ngũ có trách nhiệm đánh giá phần mềm dựa vào bối cảnh các yêu cầu đã đưa ra. Ngoài ra, các nhà phát triển (developers) cũng có thể tiến hành kiểm thử – được gọi là Kiểm Thử Đơn Vị. Trong hầu hết các trường hợp, các chuyên gia sau đây được tham gia vào kiểm thử hệ thống trong phạm vi năng lực của họ:

  • Người kiểm thử phần mềm (Tester)
  • Người phát triển phần mềm (developer)
  • Trưởng nhóm / Giám đốc dự án
  • Người dùng cuối

Các công ty khác nhau có các chỉ định khác nhau cho người kiểm thử phần mềm dựa trên kinh nghiệm và kiến thức của họ như Chuyên viên kiểm thử phần mềm (Tester), kỹ sư đảm bảo chất lượng phần mềm (QA), nhà phân tích nghiệm vụ (BA), v.v.

When to Start Testing?

Kiểm thử sớm làm giảm chi phí và thời gian làm lại và tạo ra phầm mềm không có lỗi được bàn giao cho khách hàng. Tuy nhiên, trong chu trình phát triển phần mềm (Software Development Life Cycle), kiểm thử có thể được bắt đầu từ giai đoạn thu thập yêu cầu và tiếp tục cho đến khi triển khai phần mềm. Nó cũng phụ thuộc vào mô hình phát triển đang được sử dụng. Ví dụ, trong mô hình thác nước, kiểm thử chính thức được tiến hành trong giai đoạn thử nghiệm; nhưng trong mô hình gia tăng, kiểm thử được thực hiện vào cuối mỗi lần tăng / lặp và toàn bộ ứng dụng được kiểm tra ở cuối.

Kiểm thử được làm xong dưới nhiều hình thức khác nhau ở mọi giai đoạn của chu trình phát triển phần mềm:

  • Trong giai đoạn thu thập yêu cầu, việc phân tích và xác minh yêu cầu cũng được coi là kiểm thử.
  • Việc xem xét thiết kế trong giai đoạn thiết kế với mục đích cả thiện thiết kế cũng được coi là kiểm thử.
  • Kiểm tra được thực hiện bởi nhà phát triển khi hoàn thành code cũng được coi như là một loại kiểm thử.

When to Stop Testing?

Rất khó để xác định thời điểm dừng kiểm thử, vì kiểm thử là một quá trình không bao giờ kết thúc và không ai có thể tuyên bố rằng một phần mềm đã được kiểm tra 100%. Các khía cạnh sau đây sẽ được xem xét để dừng quá trình kiểm thử:

  • Thời hạn kiểm thử
  • Hoàn thành việc thực thi thử nghiệm
  • Hoàn thành bao phủ chức năng và code tới một điểm nhất định
  • Tỷ lệ lỗi giảm xuống dưới một mức nhất định và không có lỗi ưu tiên cao nào được xác định
  • Quyết định từ nhà quản lý

Verification & Validation

Bảng sau đây nêu bật sự khác biệt giữa xác minh (verification) và xác nhận (validation):

STT Verification Validation
1 Xác minh giải tỏa băn khoăn: “Chúng ta xây dựng đúng sản phẩm chưa?” Xác nhận giải tỏa băn khoăn: “Chúng ta xây dựng sản phẩm đúng chưa?”
2 Đảm bảo rằng hệ thống phần mềm đáp ứng tất cả các chức năng. Đảm bảo rằng các chức năng đáp ứng hành vi dự định.
3 Xác minh diễn ra trước và bao gồm vieejce kiểm tra tài liệu, code, … Xác nhận xảy ra sau khi xác minh và chủ yếu liên quan đến việc kiểm tra tổng thể sản phẩm.
4 Được thực hiện bởi developers. Được thực hiện bởi testers.
5 Xác minh có các hoạt động tĩnh, vì nó bao gồm việc thu thập các đánh giá, hướng dẫn và kiểm tra để xác minh một phần mềm. Xác nhận có các hoạt động năng động, vì nó bao gồm việc thực thi phần mềm chống lại các yêu cầu.
6 Xác minh là một quá trình khách quan và không cần quyết định chủ quan để xác minh một phần mềm. Xác nhận là một quá trình chủ quan và liên quan đến các quyết định chủ quan về cách một phần mềm làm việc tốt như thế nào.

7 nguyên tắc kiểm thử phần mềm

Một số nguyên tắc kiểm thử đã được đề nghị từ 40 năm về trước và đã đưa ra một số phương châm chung phổ biến cho kiểm thử phần mềm, bao gồm các nguyên tắc sau:

Nguyên tắc 1 – Kiểm thử đưa ra lỗi

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, thậm chí là không còn lỗi nào, nó không phải là bằng chứng của sự chính xác.

Nguyên tắc 2 – Kiểm thử toàn diện là điều không thể

Kiểm thử mọi thứ (tất cả các tổ hợp của điều kiện và đầu vào) không thể thực hiện được, trừ phi nó chỉ bao gồm một số trường hợp bình thường (ít trường hợp tổ hợp thì có thể test toàn bộ được). Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết.

Nguyên tắc 3 – Kiểm thử sớm

Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong qui trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động đã định trước.

Principle 4 – Defect clustering

Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗi phát hiện ra sau đó trong các mô-đun. Một số ít các mô-đun thường chứa nhiều lỗi không phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu trách nhiệm cho hầu hết các lỗi hoạt động của phần mềm.

Để hiểu rõ hơn nguyên tắc này, ta cần xem xét 3 điều sau:
1. Nguyên tắc tổ gián: chỗ nào có 1 vài con gián thì ở đâu đó xung quanh nó sẽ có cả tổ gián -> có rất nhiều gián >>> chỗ nào có 1 vài con bug thì xung quanh, gần gần chỗ đó sẽ có nhiều bug.
2. Nguyên tắc 80/20: thông thường 20% chức năng quan trọng trong một chương trình có thể gây ra đến 80% tổng số bug phát hiện được trong chương trình đó.
3. Exhaustive testing is impossible (nguyên tắc thứ 2): do đó cần phải ananlysis (phân tích) + priorities (tính toán mức độ ưu tiên) để quyết định tập trung vào test chỗ nào.

=> Test kỹ chức năng quan trọng => found bug => test những gì liên quan + những chức năng gần nó để tìm ra bug nhiều hơn.

Nguyên tắc 5 – Nghịch lý thuốc trừ sâu

Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ có một số trường hợp kiểm thử (ca kiểm thử – test case) sẽ không còn tìm thấy bất kỳ lỗi nào mới. Để khắc phục “nghịch lý thuốc trừ sâu” này, các trường hợp kiểm thử cần phải được xem xét và sửa đổi thường xuyên, và cần phải viết các test case mới và khác nhau để thực hiện nhiều phần khác nhau của phần mềm hoặc hệ thống để tìm ra lỗi tiềm ẩn nhiều hơn nữa.

Nguyên tắc này giống như việc trừ sâu trong nông nghiệp, nếu chúng ta cứ phun một loại thuốc với nồng độ giống nhau trong một khoảng thời gian dài thì có một số con sâu sẽ quen dần và cuối cùng việc phun thuốc giống như là tắm chúng vậy (bị lờn thuốc) => lúc đó chúng ta không thể diệt sạch chúng được. Do vậy, để diệt sạch sâu một cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, mỗi loại chỉ dùng trong khoảng thời gian ngắn.

Nguyên tắc 6 – Kiểm thử theo các ngữ cảnh độc lập

Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều ngữ cảnh khác nhau.
Để hiểu rõ hơn chúng ta xem ví dụ sau:

Ví dụ, cũng với một chương trình calculator có rất nhiều chức năng, nhưng:
– Nếu test chương trình này cho mẫu giáo thì chỉ cần test cộng trừ là OK
– Nếu test chương trình này cho cấp 2 thì cộng trừ nhân chia
– Nếu test chương trình này cho đại học thì tích phân, đạo hàm, v.v….

Principle 7 – Sự sai lầm về việc không có lỗi

Việc tìm và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống được xây dựng xong nhưng không thể dùng được và không đáp ứng được nhu cầu và sự mong đợi của người dùng.
(Nghĩa là nếu sau khi code, test rồi fix bug, làm đủ tất cả các trường hợp và cuối cùng cho ra một sản phẩm không như mong đợi hoặc không đáp ứng được nhu cầu của khách hàng thì dự án phần mềm đó coi như thất bại mặc dù đã được test xong).

Software Testing – QA, QC & Testing

Testing, Quality Assurance, and Quality Control

Hầu hết mọi người bị lẫn lộn khi nói đến sự khác biệt giữa đảm bảo chất lượng (QA), điều khiển chất lượng (QC) và Kiểm thử phầm mềm (Testing). Mặc dù chúng có liên quan tới nhau và ở một mức độ nào đó chúng có thể được coi là các hoạt động tương tự, tuy nhiên vẫn tồn tại các điểm khác biệt để tách chúng ra.

Quality Assurance Quality Control Testing
Bao gồm các hoạt động được lập ra để đảm bảo tiến trình phát triển và/hoặc duy trì là phù hợp để chắc chắn một hệ thống sẽ đáp ứng các mục tiêu của nó. Bao gồm những hoạt động để đảm bảo việc phát triển phần mềm đúng với các yêu cầu trong các tài liệu đặc tả liên quan của phần mềm. Quá trình thực thi hệ thống với ý định tìm kiếm các thiếu sót của phần mềm (bugs/erors/defects).
Tập trung vào các quy trình và phương pháp (processes and procedures) hơn là tiến hành thử nghiệm thực tế trên hệ thống. Tập trung vào thử nghiệm thực tế bằng cách thực hiện phần mềm với mục đích xác định bugs/erors/defects bằng cách áp dụng các quy trình cũng như các phương pháp kiểm thử. Tập trung vào thử nghiệm thực tế.
Các hoạt động chủ yếu hướng tới quy trình. Các hoạt động chủ yếu thực hiện trên sản phẩm. Các hoạt động chủ yếu thực hiện trên sản phẩm.
Các hoạt động mang tính phòng ngừa. Là một quá trình khắc phục. Là một quá trình phòng ngừa.
QA là một phần của vòng đời kiểm thử phần mềm. QC có thể được coi là một phần của QA. Testing là một phần của QC.
Nói thêm về QA và QC:

QC: Kiểm tra và kiểm soát chất lượng sản phẩm. Đây là khâu kiểm tra được đặt xen kẽ giữa các công đoạn sản xuất và ở khâu thành phẩm để kiểm tra chất lượng của các sản phẩm. Các khâu kiểm tra chất lượng này sẽ phân sản phẩm ra ít nhất là 3 loại: Chính phẩm, thứ phẩm, và phế phẩm.

QA: Giám sát, quản lý và bản hành chất lượng.
Đây là bộ phận có quyền và có trách nhiệm quy định sẽ đặt khâu kiểm tra chất lượng sản phẩm ở công đoạn nào, kiểm tra sản phẩm theo phương pháp, tiêu chuẩn nào, sẽ dùng dụng cụ gì để kiểm tra, và sản phẩm phải đạt được mức độ nào thì sẽ được công nhận là chính phẩm. Khuyết tật nào sẽ quy ra là thứ phẩm,v.v..

Nói chung, QA là bộ phận chỉ huy, chịu trách nhiệm toàn bộ về tiêu chuẩn, quy trình kiểm tra để đảm bảo chất lượng. QC là bộ phận thi hành những quy định, hướng dẩn của QA trong việc kiểm tra, phân loại chất lượng sản phẩm.

Audit and Inspection

Audit : Đây là một quy trình bải bản với mục đích để cho việc kiểm thử thực tế được tiến hành trong tổ chức cũng như trong một team. Hoặc có thể nói đây là một quy trình kiểm tra độc lập có tính liên quan trong suốt quá trình kiểm thử phần mềm. Theo IEEE, đây là một quy trình kiểm tra các tài liệu mà tổ chức đang sử dụng và thực hiện. Các loại Audit đó là: Legal Compliance Audit, Internal Audit và System Audit.

Inspection : Đây là một kỹ thuật có liên quan đến việc review xác định ra các Error và GAP trong quá trình phát triển. Theo IEEE, inspection là một kỹ thuật đánh giá bài bản, đối tượng là các yêu cầu đặc tả phần mềm, các thiết kế cũng như các dòng lệnh sẽ được kiểm tra bởi một người hoặc nhóm người độc lập khác với tác giả của chúng để tìm ra các faults, các vi phạm đối với chuẩn khi phát triển phần mềm và các lỗi khác.

Cuộc họp inspection bao gồm các bước theo quy trình: Planning, Overview Preparation, Inspection Meeting, Rework, and Follow-up.

Testing and Debugging

Testing : Là những hoạt động liên quan đến việc phát hiện ra bug/error/defect của phầm mềm không bao gồm việc sửa chúng. Thông thường các chuyên gia có kiến thức về QA sẽ tham gia trong quá trình tìm bugs. Testing sẽ được thực hiện ở Testing phase.

Debugging : Là những hoạt động liên quan đến việc tìm, phân tích và sửa các bugs. Các lập trình viên, những người phát triển phần mềm sẽ tham gia quá trình debugging khi gặp phải lỗi ở trong code. Debugging là một phần của White Box Testing hoặc Unit Testing. Debugging có thể được thực hiện ở development phase song song Unit Testing đang tiến hành hoặc trong giai đoạn sửa và báo cáo lỗi.

Software Testing – ISO Standards

Many organizations around the globe develop and implement different standards to improve the quality needs of their software. This chapter briefly describes some of the widely used standards related to Quality Assurance and Testing.

ISO/IEC 9126

This standard deals with the following aspects to determine the quality of a software application:

  • Quality model
  • External metrics
  • Internal metrics
  • Quality in use metrics

This standard presents some set of quality attributes for any software such as:

  • Functionality
  • Reliability
  • Usability
  • Efficiency
  • Maintainability
  • Portability

The above-mentioned quality attributes are further divided into sub-factors, which you can study when you study the standard in detail.

ISO/IEC 9241-11

Part 11 of this standard deals with the extent to which a product can be used by specified users to achieve specified goals with Effectiveness, Efficiency and Satisfaction in a specified context of use.

This standard proposed a framework that describes the usability components and the relationship between them. In this standard, the usability is considered in terms of user performance and satisfaction. According to ISO 9241-11, usability depends on context of use and the level of usability will change as the context changes.

ISO/IEC 25000:2005

ISO/IEC 25000:2005 is commonly known as the standard that provides the guidelines for Software Quality Requirements and Evaluation (SQuaRE). This standard helps in organizing and enhancing the process related to software quality requirements and their evaluations. In reality, ISO-25000 replaces the two old ISO standards, i.e. ISO-9126 and ISO-14598.

SQuaRE is divided into sub-parts such as:

  • ISO 2500n – Quality Management Division
  • ISO 2501n – Quality Model Division
  • ISO 2502n – Quality Measurement Division
  • ISO 2503n – Quality Requirements Division
  • ISO 2504n – Quality Evaluation Division

The main contents of SQuaRE are:

  • Terms and definitions
  • Reference Models
  • General guide
  • Individual division guides
  • Standard related to Requirement Engineering (i.e. specification, planning, measurement and evaluation process)

ISO/IEC 12119

This standard deals with software packages delivered to the client. It does not focus or deal with the clients’ production process. The main contents are related to the following items:

  • Set of requirements for software packages.
  • Instructions for testing a delivered software package against the specified requirements.

Miscellaneous

Some of the other standards related to QA and Testing processes are mentioned below:

Standard Description
IEEE 829 A standard for the format of documents used in different stages of software testing.
IEEE 1061 A methodology for establishing quality requirements, identifying, implementing, analyzing, and validating the process, and product of software quality metrics.
IEEE 1059 Guide for Software Verification and Validation Plans.
IEEE 1008 A standard for unit testing.
IEEE 1012 A standard for Software Verification and Validation.
IEEE 1028 A standard for software inspections.
IEEE 1044 A standard for the classification of software anomalies.
IEEE 1044-1 A guide for the classification of software anomalies.
IEEE 830 A guide for developing system requirements specifications.
IEEE 730 A standard for software quality assurance plans.
IEEE 1061 A standard for software quality metrics and methodology.
IEEE 12207 A standard for software life cycle processes and life cycle data.
BS 7925-1 A vocabulary of terms used in software testing.
BS 7925-2 A standard for software component testing.

Software Testing – Types of Testing

Dưới đây là các loại kiểm thử khác nhau có thể được sử dụng trong suốt quá trình phát triển phần mềm.

Manual Testing

Kiểm thử thủ công: là tester làm mọi công việc hoàn toàn bằng tay, tức là không sử dụng bất kỳ công cụ hay kịch bản tự động nào, từ viết test case đến thực hiện test, mọi thao tác như nhập điều kiện đầu vào hay thực hiện một số sự kiện khác như click button và quan sát kết quả thực tế, sau đó so sánh kết quả thực tế với kết quả mong muốn trong test case, điền kết quả test.

Có các giai đoạn khác nhau để kiểm thử thủ công như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận. Kiểm thử thủ công cũng bao gồm cả kiểm thử thăm dò, khi tester khám khá phần mềm để xác định lỗi trong đó.

Automation Testing

Kiểm thử tự động: là khi tester viết các kịch bản và sử dụng một phần mềm khác để kiểm tra sản phẩm. Quá trình này bao hàm việc sử dụng rất ít hoặc không có sự tương tác của con người, giúp cho tester không phải lặp đi lặp lại các bước nhàm chán.

Công cụ kiểm thử tự động có thể lấy dữ liệu từ file bên ngoài (excel, csv…) nhập vào ứng dụng, so sánh kết quả mong đợi (từ file excel, csv…) với kết quả thực tế và xuất ra báo cáo kết quả kiểm thử.

Ngoài kiểm thử hồi quy ra, kiểm thử tự dộng cũng được sử dụng để kiểm tra ứng dụng từ việc tải, hiệu suất và quan sát stress point. Nó làm tăng phạm vi kiểm thử, cải thiện độ chính xác và tiết kiệm thời gian, tiền bạc so với kiểm thử thủ công.

What is Automate?

Tự động hóa mọi thứ trong phần mềm là điều không thể. Trong trường hợp như các form đăng nhập hoặc đăng ký, khu vực có số lượng người dùng truy cập lớn và đồng thời cùng lúc sẽ được tự động hóa.

Hơn nữa, tất cả các GUI items, kết nối cơ sở dữ liệu, các trường xác nhận (field validations), … có thể được kiểm tra hiệu quả bằng cách tự động hóa quy trình thủ công.

When to Automate?

Tự động hóa kiểm thử nên được sử dụng bằng việc cân nhắc các khía cạnh sau của phần mềm:

  • Các dự án lớn và quan trọng
  • Các dự án yêu cầu kiểm tra cùng một khu vực thường xuyên
  • Yêu cầu không thường xuyên thay đổi
  • Khi muốn thực thi performance test hoặc load test với nhiều người dùng ảo
  • Kiểm thử thủ công với phần mềm có tính ổn định
  • Tính khả dụng của thời gian

How to Automate?

Automation is done by using a supportive computer language like VB scripting and an automated software application. There are many tools available that can be used to write automation scripts. Before mentioning the tools, let us identify the process that can be used to automate the testing process:

  • Identifying areas within a software for automation
  • Selection of appropriate tool for test automation
  • Writing test scripts
  • Development of test suits
  • Execution of scripts
  • Create result reports
  • Identify any potential bug or performance issues

Software Testing Tools

Các công cụ sau có thể được sử dụng cho kiểm thử tự động:

  • HP Quick Test Professional
  • Selenium
  • IBM Rational Functional Tester
  • SilkTest
  • TestComplete
  • Testing Anywhere
  • WinRunner
  • LaodRunner
  • Visual Studio Test Professional
  • WATIR

Software Testing – Methods

Black-Box Testing

Kiểm thử hộp đen là kiểu test mà Tester thực hiện không chú ý gì đến code (hoặc là một hình thức test mà ứng dụng đang test được xem như một hộp đen và hành vi bên trong của chương trình hoàn toàn được bỏ qua. Việc test xảy ra dựa trên các đặc tả bên ngoài. Cũng hiểu như test hành vi, chỉ hành vi bên ngoài của ứng dụng là được đánh giá và phân tích).

Ưu điểm Nhược điểm
  • Rất phù hợp và hiệu quả cho các phân đoạn code lớn.
  • Không cần truy cập code.
  • Phân tách rõ ràng quan điểm của người dùng và quan điểm của nhà phát triển –> Vai trò xác định rõ ràng.
  • Tester có thể kiểm tra ứng dụng mà không có kiến thức về triển khai, ngôn ngữ lập trình hoặc hệ điều hành.
  • Phạm vi giới hạn, vì chỉ có một số trường hợp kiểm thử được chọn thực sự được thực hiện.
  • Kiểm thử không hiệu quả, do thực tế là tester chỉ có kiến thức hạn chế về một ứng dụng.
  • Vùng phủ sóng không rõ ràng, vì tester không thể nhắm tới các phân đoạn code cụ thể hoặc vùng dễ bị lỗi .
  • Test cases khó thiết kế.

White-Box Testing

Kiểm thử hộp trắng là kiểu test mà các tester tìm kiếm lỗi bên trong code. Tester phải xem xét code và tìm ra đoạn mã nào đang vận hành không thích hợp.
White-box testing cũng được gọi là glass testing hoặc open-box testing.

Ưu điểm Nhược điểm
  • Khi tester có kiến thức về mã nguồn, việc tìm ra loại dữ liệu nào giúp kiểm thử ứng dụng hiệu quả trở nên một cách dễ dàng.
  • Giúp tối ưu code.
  • Gỡ bỏ các dòng code mang lỗi ẩn.
  • Do Tester có kiến thức về mã nguồn, việc viết kịch bản thử nghiệm (test scenario) đạt được mức độ tối đa.
  • Chi phí tăng lên do tester có kỹ năng cao.
  • Nhiều đường dẫn có thể không được kiểm tra –> đôi khi không thể tìm ra các lỗi ẩn.
  • Rất khó để duy trì kiểm thử hộp trắng, vì nó đòi hỏi các công cụ chuyên dụng như máy phân tích lỗi và công cụ gỡ lỗi.

Grey-Box Testing

Kiểm thử hộp xám là phương pháp kiểm thử phần mềm được kết hợp giữa kiểm thử hộp đen và kiểm thử hộp trắng, thường được sử dụng trong Kiểm thử tích hợp. Trong kiểm thử hộp xám, tester chỉ biết được một phần cấu trúc bên trong của sản phẩm, có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc là ở mức hộp đen.

Được gọi là Gray Box Testing vì trong chương trình phần mềm, mắt của Tester giống như hộp xám/bán trong suốt – nhìn qua hộp này ta chỉ có thể thấy được một phần.

Ưu điểm và nhược điểm của Grey-Box Testing được quyết định dựa vào sự kết hợp các ưu nhược điểm của Black-Box Testing và White-Box Testing

A Comparison of Testing Methods

Bảng sau đây liệt kê các điểm khác nhau giữa kiểm thử hộp đen, kiểm thử hộp xám và kiểm thử hộp trắng.

Black-Box Testing Grey-Box Testing White-Box Testing
Không cần biết hoạt động nội bộ của ứng dụng. Tester biết một phần hoạt động nội bộ. Tester có kiến thức đầy đủ về các hoạt động nội bộ.
Còn được gọi là kiểm thử hộp kín (closed-box testing), kiểm thử theo hướng dữ liệu hoặc chức năng. Còn được gọi là kiểm thử mờ (translucent testing). Còn được gọi là kiểm thử rõ ràng (clear-box testing), kiểm thử cấu trúc hoặc dựa trên mã nguồn.
Thực hiện bởi người dùng cuối, tester, developer. Thực hiện bởi người dùng cuối, tester, developer. Thực hiển bởi tester và developer.
Đầy đủ và tốn ít thời gian nhất. Đầy đủ và tiêu tốn một phần thời gian. Đầy đủ nhất và tiêu tốn nhiều thời gian nhất.
Không thích hợp để kiểm tra thuật toán. Không thích hợp để kiểm tra thuật toán. Thích hợp kiểm tra thuật toán.

Software Testing – Levels

Các mức kiểm thử bao gồm các phương pháp khác nhau có thể được sử dụng trong khi tiến hành kiểm thử phần mềm. Các mức chính của kiểm thử phần mềm là:

  • Kiểm thử chức năng
  • Kiểm thử phi chức năng

Functional Testing – Kiểm thử chức năng

Đây là một loại kiểm thử hộp đen, là xác nhận – verify – một ứng dụng bằng cách kiểm tra nó dựa vào các tài liệu thiết kế hoặc đặc tả kỹ thuật, test case của nó được dựa trên đặc tả của ứng dụng phần mềm đang test. Các chức năng được test bằng cách nhập vào các giá trị nhập và kiểm tra kết quả đầu ra, ít quan tâm đến cấu trúc bên trong của ứng dụng.

Kiểm thử chức năng thường bao gồm 5 bước:

Steps Nội dung
1 Việc xác định các chức năng mà phần mềm mong muốn sẽ thực hiện.
2 Việc tạo ra các dữ liệu đầu vào dựa trên các tài liệu đặc tả kỹ thuật của các chức năng.
3 Việc xác định kết quả đầu ra dựa trên các tài liệu đặc tả kỹ thuật của các chức năng.
4 Việc viết các kịch bản thử nghiệm và thực hiện các trường hợp kiểm thử.
5 Việc so sánh kết quả thực tế và kết quả mong muốn.

Ý kiến khác: Kiểm thử chức năng là một loại kiểm thử giao diện (GUI checklist) của các chức năng của ứng dụng đang test.

Unit Testing – Kiểm thử đơn vị

Unit testing đề cập đến các kiểm thử để xác minh chức năng của một phần riêng biệt của code, thường ở mức hàm (function level). Trong một môi trường hướng đối tượng (object-oriented environment), kiểm thử đơn vị thường được sử dụng ở mức lớp (class) và kiểm thử các đơn vị nhỏ nhất bao gồm các hàm constructor và destructor.

Loại kiểm thử này thường được viết bởi các DEV như công việc của họ trong việc code (là loại test white-box), để bảo đảm rằng từng hàm riêng biệt hoạt động đúng theo mong muốn. Một hàm có thể có nhiều kiểm thử, để bắt được các trường hợp hoặc các nhánh trong code. Unit testing một mình không thể bảo đảm chức năng của một bộ phận của phần mềm mà là sử dụng để bảo đảm rằng các khối kiến trúc của phần mềm làm việc độc lập với nhau.

Unit testing (kiểm thử đơn vị) cũng được gọi là component testing (kiểm thử thành phần).

Integration Testing – Kiểm thử tích hợp

Kiểm thử tích hợp được định nghĩa là kiểu test kiểm tra xem các module được kết hợp hay chưa kết hợp của một ứng dụng có hoạt động chính xác hay không.
(Do mỗi lập trình viên thực hiện trên các module khác nhau, khi họ hoàn thành đoạn code của họ, nhóm quản lý cấu hình ráp chúng lại với nhau và chuẩn bị biên dịch. Các tester cần chắc chắn rằng các module này bây giờ đã được kết hợp và làm việc theo như yêu cầu – đạt được kết quả như tài liệu yêu cầu đã được xác định)
Kiểm thử tích hợp có thể được thực hiện theo hai cách: kiểm thử tích hợp từ dưới lên (Bottom-up integration testing) và kiểm thử tích hợp từ trên xuống (Top-down integration testing).

S.N. Phương pháp kiểm thử tích hợp
1 Tích hợp từ dưới lên

Kiểu kiểm thử này bắt đầu với kiểm tra đơn vị (unit), tiếp theo là kiểm tra các tổ hợp đơn vị cấp cao hơn – module và build.

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

Trong kiểu kiểm thử này, các module cấp cao nhất được kiểm tra đầu tiên và dần dần các module cấp thấp hơn được điểm tra sau đó.

Trong môi trường phát triển phần mềm toàn diện, kiểm thử từ dưới lên thường được thực hiện trước, sau đó là kiểm thử từ trên xuống.

System Testing – Kiểm thử hệ thống

Kiểm thử hệ thống là kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu.

Là khi tester hoàn thành công việc test (tester test phần mềm trong môi trường test với dữ liệu giả, không test trên dữ liệu thật), phần mềm phải được test trên môi trường thật. Nghĩa là chúng ta phải chắc chắn rằng phần mềm làm việc tốt trong môi trường thật với dữ liệu thật.

Regression Testing – Kiểm thử hồi quy

Khi một chức năng mới được thêm vào phần mềm, chúng ta cần chắc chắn rằng phần chức năng mới được thêm vào không phá hỏng các phần khác của phần mềm. Hoặc khi lỗi đã được chỉnh sửa, chúng ta cần chắc chắn rằng lỗi chỉnh sửa không phá hỏng các phần khác trong phần mềm (hoặc các lỗi đã được fixed trước đây bị lại). Để kiểm tra điều này chúng ta thực hiện kiểu test lặp đi lặp lại gọi là kiểm thử hồi quy.

Kiểm thử hồi quy là quan trọng vì những lý do sau đây:

  • Giảm thiểu những lỗ hổng trong kiểm thử khi một ứng dụng có thay đổi.
  • Kiểm tra các thay đổi mới để xác minh rằng các thay đổi được thực hiện không ảnh hưởng đến bất kỳ khu vực nào khác của ứng dụng.
  • Giảm thiểu rủi ro.
  • Phạm vi kiểm tra được tăng lên mà không ảnh hưởng đến thời gian đưa ra.
  • Tăng tốc độ tiếp thị sản phẩm.

Acceptance Testing – Kiểm thử chấp nhận

Kiểm thử chấp nhận được thực thi bởi khách hàng (tester cũng có thể thực hiện hoặc khách hàng có các tester của riêng họ để thực hiện), thường được thực hiện trong môi trường phần cứng của họ, được biết như là kiểm thử chấp nhận người dùng (UAT). Acceptance Testing có thể được thực hiện như là một phần của quá trình chuyển giao (hand-off) giữa hai pha của quá trình phát triển phần mềm.

Alpha Testing – Kiểm thử Alpha

Alpha Testing là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng / khách hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất phần mềm. Alpha Testing thường dùng cho phần mềm đóng gói sẵn để bán (ví dụ như MS Office, Window, chương trình diệt Virus) là một hình thức kiểm thử chấp nhận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta.

Beta Testing – Kiểm thử Beta

Kiểm thử Beta được thực hiện sau khi kiểm thử Alpha đã được thực hiện thành công – còn được gọi là kiểm thử trước khi phát hành (pre-release testing). Các phiên bản của phần mềm – được biết như là các phiên bản beta – chúng được phát hành tới một số lượng giới hạn người dùng bên ngoài nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một số nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm có một số bug. Thỉnh thoảng, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi từ một lượng người sử dụng tương lai lớn nhất.
Trong giai đoạn này, người dùng sẽ kiểm tra những điều sau:

  • Người dùng sẽ cài đặt, chạy ứng dụng và gửi phản hồi tới nhóm dự án.
  • Lỗi đánh máy, gây nhầm lẫn luồng ứng dụng và thậm chí gặp sự cố.
  • Nhận được phản hồi, nhóm dự án có thể khắc phục các vấn đề trước khi phát hành phần mềm cho người dùng thực tế.
  • Bạn càng khắc phục nhiều vấn đề từ người dùng thực, chất lượng ứng dụng của bạn càng cao.
  • Có một ứng dụng chất lượng cao hơn khi bạn phát hành nó cho công chúng nói chung sẽ làm tăng sự hài lòng của khách hàng.

Non-Functional Testing – Kiểm thử phi chức năng

Các phương pháp đặt biệt tồn tại để test các khía cạnh phi chức năng của phần mềm như hiệu suất, bảo mật, giao diện người dùng,… Kiểm thử phi chức năng chứng thực rằng các chức năng của phần mềm có thể hoạt động bình thường ngay cả khi nó nhận được các dữ liệu đầu vào không mong đợi hoặc không hợp lệ.

Một số loại kiểm thử phi chức năng thường được sử dụng:

Performance Testing – Kiểm thử hiệu năng

Performance testing được sử dụng để xác định bất kỳ tắc nghẽn hoặc vấn đề hiệu suất hơn là tìm lỗi trong phần mềm. Có nhiều nguyên nhân khác nhau góp phần làm giảm hiệu suất của phần mềm:

  • Độ trễ mạng
  • Xử lý phía máy khách
  • Xử lý trao đổi cơ sở dữ liệu
  • Cân bằng tải giữa các máy chủ
  • Hiển thị dữ liệu

Performance testing được coi là một trong những loại thử nghiệm quan trọng và bắt buộc về các khía cạnh sau:

  • Tốc độ (thời gian phản hồi, hiển thị và truy cập dữ liệu)
  • Công suất
  • Tính ổn định
  • Khả năng mở rộng

Performance testing có thể là định tính hoặc định lượng và có thể được chia thành các loại khác nhau như: Load testingStress testing.

Load Testing

Test tải dữ liệu là kiểu test kiểm tra thời gian đáp lại người dùng với ứng số lượng người dùng bất kỳ trong một ngữ cảnh nào đó của cùng một ứng dụng tại cùng một thời điểm. (Xác định khả năng tối đa của phần mềm và hành vi của phần mềm vào lúc cao điểm)

Hầu hết load testing được thực hiện với sự trợ giúp của các công cụ tự dộng như Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test, etc.

Người dùng ảo (Virtual users) được định nghĩa trong công cụ kiểm thử tự động và các kịch bản được thực hiện để xác minh khả năng chịu tải của phần mềm. Số lượng người dùng ảo có thể được tăng hoặc giảm đồng thời hoặc gia tăng dựa trên các yêu cầu.

Stress Testing

Stress testing includes testing the behavior of a software under abnormal conditions. For example, it may include taking away some resources or applying a load beyond the actual load limit.

The aim of stress testing is to test the software by applying the load to the system and taking over the resources used by the software to identify the breaking point. This testing can be performed by testing different scenarios such as:

  • Shutdown or restart of network ports randomly
  • Turning the database on or off
  • Running different processes that consume resources such as CPU, memory, server, etc.

Usability Testing

Usability testing is a black-box technique and is used to identify any error(s) and improvements in the software by observing the users through their usage and operation.

According to Nielsen, usability can be defined in terms of five factors, i.e. efficiency of use, learn-ability, memory-ability, errors/safety, and satisfaction. According to him, the usability of a product will be good and the system is usable if it possesses the above factors.

Nigel Bevan and Macleod considered that usability is the quality requirement that can be measured as the outcome of interactions with a computer system. This requirement can be fulfilled and the end-user will be satisfied if the intended goals are achieved effectively with the use of proper resources.

Molich in 2000 stated that a user-friendly system should fulfill the following five goals, i.e., easy to Learn, easy to remember, efficient to use, satisfactory to use, and easy to understand.

In addition to the different definitions of usability, there are some standards and quality models and methods that define usability in the form of attributes and sub-attributes such as ISO-9126, ISO-9241-11, ISO-13407, and IEEE std.610.12, etc.

UI vs Usability Testing

UI testing involves testing the Graphical User Interface of the Software. UI testing ensures that the GUI functions according to the requirements and tested in terms of color, alignment, size, and other properties.

On the other hand, usability testing ensures a good and user-friendly GUI that can be easily handled. UI testing can be considered as a sub-part of usability testing.

Security Testing

Security testing involves testing a software in order to identify any flaws and gaps from security and vulnerability point of view. Listed below are the main aspects that security testing should ensure:

  • Confidentiality
  • Integrity
  • Authentication
  • Availability
  • Authorization
  • Non-repudiation
  • Software is secure against known and unknown vulnerabilities
  • Software data is secure
  • Software is according to all security regulations
  • Input checking and validation
  • SQL insertion attacks
  • Injection flaws
  • Session management issues
  • Cross-site scripting attacks
  • Buffer overflows vulnerabilities
  • Directory traversal attacks

Portability Testing

Portability testing includes testing a software with the aim to ensure its reusability and that it can be moved from another software as well. Following are the strategies that can be used for portability testing:

  • Transferring an installed software from one computer to another.
  • Building executable (.exe) to run the software on different platforms.

Portability testing can be considered as one of the sub-parts of system testing, as this testing type includes overall testing of a software with respect to its usage over different environments. Computer hardware, operating systems, and browsers are the major focus of portability testing. Some of the pre-conditions for portability testing are as follows:

  • Software should be designed and coded, keeping in mind the portability requirements.
  • Unit testing has been performed on the associated components.
  • Integration testing has been performed.
  • Test environment has been established.

Software Testing – Documentation

Testing documentation involves the documentation of artifacts that should be developed before or during the testing of Software.

Documentation for software testing helps in estimating the testing effort required, test coverage, requirement tracking/tracing, etc. This section describes some of the commonly used documented artifacts related to software testing such as:

  • Test Plan
  • Test Scenario
  • Test Case
  • Traceability Matrix

Test Plan

A test plan outlines the strategy that will be used to test an application, the resources that will be used, the test environment in which testing will be performed, and the limitations of the testing and the schedule of testing activities. Typically the Quality Assurance Team Lead will be responsible for writing a Test Plan.

A test plan includes the following:

  • Introduction to the Test Plan document
  • Assumptions while testing the application
  • List of test cases included in testing the application
  • List of features to be tested
  • What sort of approach to use while testing the software
  • List of deliverables that need to be tested
  • The resources allocated for testing the application
  • Any risks involved during the testing process
  • A schedule of tasks and milestones to be achieved

Test Scenario

It is a one line statement that notifies what area in the application will be tested. Test scenarios are used to ensure that all process flows are tested from end to end. A particular area of an application can have as little as one test scenario to a few hundred scenarios depending on the magnitude and complexity of the application.

The terms ‘test scenario’ and ‘test cases’ are used interchangeably, however a test scenario has several steps, whereas a test case has a single step. Viewed from this perspective, test scenarios are test cases, but they include several test cases and the sequence that they should be executed. Apart from this, each test is dependent on the output from the previous test.

Test Scenario

Test Case

Test cases involve a set of steps, conditions, and inputs that can be used while performing testing tasks. The main intent of this activity is to ensure whether a software passes or fails in terms of its functionality and other aspects. There are many types of test cases such as functional, negative, error, logical test cases, physical test cases, UI test cases, etc.

Furthermore, test cases are written to keep track of the testing coverage of a software. Generally, there are no formal templates that can be used during test case writing. However, the following components are always available and included in every test case:

  • Test case ID
  • Product module
  • Product version
  • Revision history
  • Purpose
  • Assumptions
  • Pre-conditions
  • Steps
  • Expected outcome
  • Actual outcome
  • Post-conditions

Many test cases can be derived from a single test scenario. In addition, sometimes multiple test cases are written for a single software which are collectively known as test suites.

Traceability Matrix

Traceability Matrix (also known as Requirement Traceability Matrix – RTM) is a table that is used to trace the requirements during the Software Development Life Cycle. It can be used for forward tracing (i.e. from Requirements to Design or Coding) or backward (i.e. from Coding to Requirements). There are many user-defined templates for RTM.

Each requirement in the RTM document is linked with its associated test case so that testing can be done as per the mentioned requirements. Furthermore, Bug ID is also included and linked with its associated requirements and test case. The main goals for this matrix are:

  • Make sure the software is developed as per the mentioned requirements.
  • Helps in finding the root cause of any bug.
  • Helps in tracing the developed documents during different phases of SDLC.

Software Testing – Estimation Techniques

Estimating the efforts required for testing is one of the major and important tasks in SDLC. Correct estimation helps in testing the software with maximum coverage. This section describes some of the techniques that can be useful in estimating the efforts required for testing.

Functional Point Analysis

This method is based on the analysis of functional user requirements of the software with the following categories:

  • Outputs
  • Inquiries
  • Inputs
  • Internal files
  • External files

Test Point Analysis

This estimation process is used for function point analysis for black-box or acceptance testing. The main elements of this method are: Size, Productivity, Strategy, Interfacing, Complexity, and Uniformity.

Mark-II Method

It is an estimation method used for analyzing and measuring the estimation based on end-user’s functional view. The procedure for Mark-II method is as follows:

  • Determine the viewpoint
  • Purpose and type of count
  • Define the boundary of count
  • Identify the logical transactions
  • Identify and categorize data entity types
  • Count the input data element types
  • Count the functional size

Miscellaneous

You can use other popular estimation techniques such as:

  • Delphi Technique
  • Analogy Based Estimation
  • Test Case Enumeration Based Estimation
  • Task (Activity) based Estimation
  • IFPUG method

Nguồn: tutorialspoint, testingvn.com

Bình luận