Techacademy sẽ giới thiệu với các bạn về BIẾN TRONG PYTHON. Một phần tuy cơ bản nhưng rất quan trọng trong lập trình và nó sẽ theo bạn mãi cho tới khi bạn còn code.

I. Trong Python Biến Là Gì

Có hai trường phái định nghĩa biến trong python như sau:

Trường phái đầu tiên coi biến trong python giống như 1 cái hộp để lưu trữ dữ liệu. Các dữ liệu này có thể là số hoặc chuỗi mà bạn có thể ưu trữ vào biến và dùng nhiều lần. Kết quả của những phép xử lý như tính toán giá trị số, chỉnh sửa chuỗi ký tự sẽ tạm thời được giữ vào biến và dùng để sử dụng cho chương trình sau này.

Trường phái thứ hai coi biến trong python giống như thẻ ghi địa chỉ của dữ liệu. Các dữ liệu được lưu giữ tại các vị trí riêng biệt trong bộ nhớ với địa chỉ khác nhau, và biến trong python là thẻ dùng để ghi địa chỉ của dữ liệu đó trong bộ nhớ. Khi dùng dữ liệu, chúng ta sẽ truy cập vào địa chỉ được ghi trên biến của dữ liệu đó.

Bạn cũng không cần quá chú ý trường phái nào đúng, chỉ cần ghi nhớ khái niệm biến trong python bằng 1 trong hai cách trên là được.

II. Các Kiểu Biến Trong Python

Dữ liệu mà được lưu trữ trong bộ nhớ có thể có nhiều kiểu khác nhau. Ví dụ, lương của công nhân đươc lưu trữ dưới dạng một giá trị số còn địa chỉ của họ được lưu trữ dưới dạng những ký tự chữ-số. Python có đa dạng kiểu dữ liệu chuẩn được dùng để xác định các hành động có thể xảy ra trên chúng và phương thức lưu trữ cho mỗi kiểu.

Python có 5 kiểu dữ liệu chuẩn là:

1. Kiểu Number
2. Kiểu String
3. Kiểu List
4. Kiểu Tuple
5. Kiểu Dictionary

Ngoài kiểu Number và kiểu String mà có thể bạn đã được làm quen với các ngôn ngữ lập trình khác thì ở trong Python còn xuất hiện thêm ba kiểu dữ liệu đó là List, Tuple và Dictionary.

III. Kiểm Tra Kiểu Dữ Liệu Của Biến Trong Python

Trong Python, chúng ta có thể sử dụng nhiều cách khác nhau để kiểm tra dữ liệu input là chuỗi hay số.

Cách 1: Chuyển đổi thành int hoặc float để kiểm tra input là số hay chuỗi

Với cách này thì ta sử dụng hai hàm int() và float() để ép kiểu dữ liệu, dựa vào kết quả trả về ta sẽ biết chính xác người sử dụng nhập vào 1 chuỗi hay 1 số.

Ta phải đặt nó trong lệnh try .. except, bởi hai hàm ép kiểu trên sẽ không thể ép một chuỗi thành một số trong trường hợp giá trị của chuỗi không phải là số. Ví dụ bạn chuyển chuỗi “freetuts.net” thành số là hoàn toàn sai.

Quá trình kiểm tra như sau: Nếu ép kiểu thành công thì là số, ngược lại thì một Exception sẽ được bung ra nên nó là một chuỗi.

print ("Chương trình đăng tại freetuts.net")
user_input = input("Nhập tuổi của bạn ")
 
print("\n")
try:
    val = int(user_input)
    print("Dữ liệu nhập vào là int = ", val)
except ValueError:
    try:
        val = float(user_input)
        print("Dữ liệu nhâp vào là float = ", val)
    except ValueError:
        print("Dữ liệu nhập vào không phải là number")

Cách 2: Sử dụng hàm isdigit để kiểm tra là number hay string

Hàm này công dụng khá đơn giản như sau:

print ("Chương trình đăng tại freetuts.net")
num = input("Nhập số của bạn ")
 
print("\n")
if num.isdigit():
    print("Dữ liệu nhập vào là số ")
else:
    print("Dữ liệu nhập vào là chuỗi ")

Tuy nhiên hàm này chủ hoạt động với số nguyên dương. Nếu bạn nhập vào là một số thực hoặc một số âm thì nó sẽ trả về là chuỗi. Vì vậy, giải pháp tốt nhất vẫn là chọn phương án 1 nhé cả nhà.

IV. Ép Kiểu Dữ Liệu Của Biến Trong Python

Đây là thao tác tự động chuyển đổi một loại dữ liệu sang loại dữ liệu khác của Python, quá trình này không cần bất kỳ sự tham gia của lập trình viên.

Chúng ta hãy xem ví dụ dưới đây, trong đó Python chuyển đổi kiểu dữ liệu thấp hơn (số nguyên) sang kiểu dữ liệu cao hơn (float) để tránh mất dữ liệu.

num_int = 123
num_flo = 1.23
 
num_new = num_int + num_flo
 
print("Kiểu dữ liệu của num_int:",type(num_int))
print("Kiểu dữ liệu của num_flo:",type(num_flo))
 
print("Giá trị của num_new:",num_new)
print("Kiểu dữ liệu của num_new:",type(num_new))

Kết quả của chương trình này như sau:

Kiểu dữ liệu của num_int: <class 'int'>
Kiểu dữ liệu của num_flo: <class 'float'>
Giá trị của num_new: 124.23
Kiểu dữ liệu của num_new: <class 'float'>

Trong chương trình trên thì:

• Mình đã định nghĩa hai biến num_int và num_flo, sau đó tạo một biến num_new để lưu trữ tổng của hai biến đó.
• Tiếp theo sẽ dùng hàm type để kiểm tra kiểu dữ liệu của cả ba biến, thật bất ngờ vì num_new đã mang kiểu float vì đây là kiểu số lớn hơn kiểu int. Như vậy biến num_new đã được chuyển đổi ngầm.

Bây giờ, hãy thử thêm một chuỗi và một số nguyên và xem Python xử lý thế nào.

Ví dụ: Bổ sung kiểu dữ liệu chuỗi (cao hơn) và kiểu dữ liệu số nguyên (thấp hơn)

num_int = 123
num_str = "456"
 
print("Kiểu dữ liệu của num_int:",type(num_int))
print("Kiểu dữ liệu của num_str:",type(num_str))
 
# Dòng này sẽ lỗi vì string và number không chuyển ngầm được
print(num_int+num_str)

Khi chạy chương trình trên, kết quả sẽ là:

Traceback (most recent call last):
  File "C:\Users\gf63\IdeaProjects\LearnPython\helloworld.py", line 7, in <module>
    print(num_int+num_str)
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Kiểu dữ liệu của num_int: <class 'int'>
Kiểu dữ liệu của num_str: <class 'str'>

Như vậy mặc định Python không thể tự động chuyển đổi ngầm giữa string và number.

V. Biến Global Trong Python Là Gì

Trong ngôn ngữ lập trình Python, một biến được khai báo bên ngoài hàm hoặc trong phạm vi toàn cục được gọi là biến toàn cục hay biến global. Biến toàn cục có thể được truy cập từ bên trong hoặc bên ngoài hàm

Hãy xem ví dụ về cách tạo biến toàn cục trong Python.

x = "Biến toàn cục" #khai báo biến x
#Gọi x từ trong hàm vidu()
def vidu():
    print("x trong hàm vidu() :", x)

vidu()
#Gọi x ngoài hàm vidu()
print("x ngoài hàm vidu():", x)

Trong ví dụ trên, ta khai báo biến x là biến toàn cục, và định nghĩa hàm vidu() để in biến x. Cuối cùng ta gọi hàm vidu() để in giá trị của biến x. Chạy code trên ta sẽ được kết quả là:

x trong hàm vidu(): Biến toàn cục
x ngoài hàm vidu(): Biến toàn cục

Chuyện gì sẽ xảy ra nếu bạn thay đổi giá trị của x trong hàm?

x = 2 
def vidu():
   x=x*2    
   print(x)

vidu()

Nếu chạy code này bạn sẽ nhận được thông báo lỗi:

UnboundLocalError: local variable 'x' referenced before assignment

Lỗi này xuất hiện là do Python xử lý x như một biến cục bộ và x không được định nghĩa trong vidu().

Để thay đổi biến toàn cục trong một hàm bạn sẽ phải sử dụng từ khóa global. Chúng tôi sẽ nói kỹ hơn trong bài về từ khóa global.

VI. Biến Cục Bộ Trong Python Là Gì

Biến được khai báo bên trong một hàm hoặc trong phạm vi cục bộ được gọi là biến cục bộ hay biến local.

def vidu():
 y = "Biến cục bộ"
vidu()
print(y)

Khi chạy code trên bạn sẽ nhận được thông báo lỗi:

NameError: name 'y' is not defined

Lỗi này xuất hiện là do chúng ta đã cố truy cập vào biến cục bộ y trong phạm vi toàn cục, nhưng y chỉ làm việc trong hàm vidu() hoặc phạm vi cục bộ.

Thông thường, để tạo một biến cục bộ, chúng ta sẽ khai báo nó trong một hàm như ví dụ dưới đây:

def vidu():
 y = "Biến cục bộ"
 print(y)
vidu()

Chạy code trên ta sẽ được kết quả

Biến cục bộ

VII. Biến Static Trong Python Là Gì

Hàm staticmethod() được coi là un-Pythonic (ngôn ngữ không chính thống của Python). Trong các phiên bản mới hơn của Python, bạn nên sử dụng decorator @staticmethod để thay thế.

Cú pháp của @staticmethod là:

@staticmethod
def func(args, ...)

Cú pháp của hàm staticmethod() trong Python

Hàm staticmethod() được xác định bằng cú pháp sau:

staticmethod(function)

Tham số của hàm staticmethod()

Hàm staticmethod() có một tham số duy nhất:

• Hàm: Hàm cần được chuyển thành một static method

Giá trị trả về của hàm staticmethod()

Hàm staticmethod() trả về một static method cho một hàm tham số mà bạn đưa vào.

VIII. Biến Hằng Trong Python Là Gì

Biến là một đối tượng trong chương trình. Mỗi biến sẽ có một vị trí riêng trong bộ nhớ để lưu trữ dữ liệu (giá trị) được gán. Biến trong Python được đặt theo nguyên tắc định danh

Câu lệnh gán giá trị cho biến là: <tên biến> = <giá trị gán cho biến>

Biến trong Python không cần khai báo trước, không gần khai báo kiểu dữ liệu. Khi đặt tên và gán giá trị Python tự động nhận dạng và tùy biến theo kiểu dữ liệu được gán.

Ví dụ 1:

number = 10

number = 1.1

print(number)

input()

Ở ví dụ trên, biến được đặt tên là number, được gán giá trị là 10 sau đó lại được gán giá trị là 1.1. Như vậy sau sau 2 câu lệnh trên giá trị của biến number lưu sẽ là 1.1. Kết quả khi chạy chương trình là: 1.1.

Hằng là 1 loại biến đặc biệt, giá trị của hằng là không đổi trong suốt chương trình sau lần gán giá trị đầu tiên. Tên hằng được viết hoàn toàn bằng chữ hoa và dấu gạch dưới (nếu cần).

Ví dụ:

PI = 3.14 # đây là hằng
bankinh = 20 # đây là biến

Trong thực tế, việc đặt tên Hằng bằng những ký tự in hoa là để phân biệt với biến chứ nó không có tác dụng ngăn cản việc gán giá trị mới cho Hằng.

Đối với các chương trình lớn, Hằng số thường được khai báo riêng trong một mô-đun. Mô-đun là một tệp riêng chứa các biến, hàm, v.v. được nhập (import) vào tệp chính.

Ví dụ:

Tạo 1 file mới với tên “hang.py” trong cùng thư mục với file “thuchanh.py”.

– Nội dung file hang.py:

PI = 3.14
GRAVITY = 9.8

– Nội dung file thuchanh.py:

import hang

print(hang.PI)

print(hang.GRAVITY)

input()

Chạy file thuchanh.py sẽ cho kết quả là:

3.14 9.8

IX. Gán Biến Trong Python Thế Nào

Sau khi gán một giá trị cho biến trong Python, chúng ta có thể sử dụng biến để đại diện cho giá trị đó trong chương trình. Việc gán biến trong python có thể thực hiện cùng lúc hoặc sau khi bạn đã khai báo biến trong python. Bạn có thể gán một giá trị khác với giá trị khởi tạo ban đầu vào biến, hoặc gán giá trị một biến cho một biến khác. Hãy cùng học cách gán biến trong python sau bài học này.

Gán biến trong python bằng một giá trị khác giá trị khởi tạo

Khi khởi tạo và khai báo biến trong python, chúng ta cần chỉ định giá trị ban đầu để gán cho biến đó.

Tuy nhiên sau khi đã gán một giá trị cụ thể cho biến thì chúng ta vẫn có thể gán một giá trị khác cho biến đó như ví dụ sau đây:

price = 100
price = 200

print(price)
#>> 200

Trong bài biến trong python là gì bạn đã biết biến trong python không phải là địa chỉ của vị trí chứa giá trị trong bộ nhớ, mà chỉ là thẻ ghi địa chỉ của dữ liệu đó mà thôi. Do đó khi gán một giá trị khác cho một biến đã xác định, chúng ta chỉ đơn giản là thay đổi dòng địa chỉ ghi trên biến mà thôi.

Do đó, bản chất biến không thay đổi, chỉ là địa chỉ của giá trị trong bộ nhớ mà nó được gán đã thay đổi mà thôi.

Lại nữa, các giá trị dùng để gán vào biến tuy có thể thuộc các dạng dữ liệu khác nhau, tuy nhiên biến trong python lại được tự động nhận diện kiểu dữ liệu khi được gán giá trị.

Do đó, bạn có thể gán một biến có kiểu dữ liệu khác với kiểu dữ liệu ban đầu vào cùng một biến như ví dụ sau:

name = "Kiyoshi"
name = 30

print(name)

#>> 30

Trong ví dụ trên, mặc dù biến name được khai báo với giá trị dưới dạng chuỗi, nhưng sau đó, nó vẫn có thể được gán bởi giá trị dưới dạng số. Đó là nhờ trong python, các biến sẽ được tự động nhận diện kiểu giá trị được gán vào nó.

Gán giá trị một biến cho một biến khác

Chúng ta có thể gán giá trị một biến đã được khai báo cho một biến khác, như ví dụ sau đây:

num1 = 100
num2 = num1

print("num1",num1)
#>> num1 100
print("num2",num2)
#>> num2 100

Trong trường hợp này, cả hai biến num1 và num2 đều cùng ghi và trỏ về một địa chỉ, đó là vị trí của giá trị 100 trong bộ nhớ.

Tuy nhiên cần lưu ý, nếu lúc này chúng ta gán một giá trị mới vào biến num1, thì giá trị của biến num2 vẫn sẽ không thay đổi.

num1 = 100
num2 = num1

num1 = 200
print("num1",num1)
#>> 200
print("num2",num2)
#>> 100

Nếu bạn gán một giá trị khác cho num1 thay vì lưu trữ giá trị mới ở vị trí mà num1 đang tham chiếu, num1 sẽ ghi địa chỉ của giá trị mới đó trong bộ nhớ.

Tại thời điểm này, biến num2 vẫn đang tham chiếu đến vị trí ban đầu, do đó, biến num1 tham chiếu đến vị trí có giá trị 200 còn biến num2 thì tham chiếu đến vị trí có giá trị 100.

Do đó khi in ra màn hình, giá trị của hai biến này sẽ khác nhau:

num1 200
num2 100

X. Nhập Biến Trong Python Thế Nào

Hướng dẫn cách Nhập biến trong python. Bạn sẽ học được cách nhập giá trị của biến từ bàn phím bằng hàm inpput () trong python sau bài học này.

Để nhập biến trong python, chúng ta cần sử dụng một hàm dựng sẵn là hàm inpput () trong python.

Hàm input() sẽ giúp chúng ta nhập liệu từ bàn phím và gán giá trị đó vào biến với cú pháp sau đây:

tên biến= input()

Trong đó:

• input dùng để gọi hàm. Khi hàm được gọi, một dòng nhập dữ liệu sẽ hiện ra để người dùng có thể nhập liệu từ bàn phím.
• tên biến được đặt theo Quy tắc đặt tên biến trong Python mà bạn đã học trong bài Biến trong python là gì

Sau khi người dùng có thể nhập liệu từ bàn phím, chuỗi nhập vào sẽ được gán vào tên biến dưới dạng kiểu dữ liệu string.

Bạn cũng có thể dùng cú pháp sau đây để màn hình nhập liệu trở nên đẹp hơn:

tên biến= input(">>")

Ví dụ, chúng ta có chương trình nhập tên tuổi và in ra màn hình như sau:

print("Hay nhap ten cua ban : ")
name=input(">>")

print("Hay nhap tuoi cua ban : ")
old=input(">>")

user = "\n Ten ban : " + name + "\n Tuoi ban : " +old
print(user)

Hãy lưu lại chương trình trên với tên user.py và chạy trên Anaconda Prompt. Kết quả sẽ như sau:

XI. In Biến Ra Màn Hình Thế Nào Trong Python

Hàm print() trong Python có tác dụng hiển thị dữ diệu ra màn hình khi chương trình thực thi.

Cú pháp đầy đủ của print():

print(*objects, sep=' ', end='\n', file=sys.stdout, flush=False)

Tham số của hàm print():

• objects: đối tượng được in, có thể có nhiều đối tượng. Sẽ được chuyển đổi thành chuỗi trước khi hiển thị ra màn hình.
• sep: cách tách riêng các đối tượng, giá trị mặc định là một khoảng trắng.
• end: giá trị cuối cùng được in ra màn hình.
• file: mặc định hàm print sẽ ghi nội dung vào file sys.stdout.
• flush: giá trị mặc định giá trị là False.

Lưu ý: sep, end, file và flush đều là các tham số keyword. Nếu bạn muốn sử dụng tham số sep, bạn phải dùng như này:

print(*objects, sep = 'separator')

không được sử dụng:

print(*objects, 'separator')

Ví dụ 1: Cách print() hoạt động trong Python

print("Học Python rất thú vị.")

a = 5
# 2 object
print("a =", a)

b = a
# 3 object
print('a =', a, '= b')

Chạy chương trình, kết quả trả về là:

Học Python rất thú vị.
a = 5
a = 5 = b

Trong 3 câu lệnh ở ví dụ trên, chỉ có duy nhất tham số object được sử dụng trong các câu lệnh.

Ví dụ 2: print () với các tham số separator và end

a = 5
print("a =", a, sep='00000', end='\n\n\n')
print("a =", a, sep='0', end='')

Chạy chương trình, kết quả trả về là:

a =000005



a =05

XII. Quy Tắc Đặt Tên Biến Trong Python

Để đặt tên cho biến trong python, chúng ta cần tuân theo Quy tắc đặt tên biến trong Python như dưới đây:

1/ Các ký tự có thể được sử dụng để đặt tên cho biến trong python là a đến z, A đến Z, 0 đến 9, gạch dưới _, chữ hán tự , tiếng việt có dấu v.v.

2/ Không thể sử dụng các giá trị số (0 đến 9) cho ký tự đầu tiên.

3/ Có thể sử dụng gạch dưới cho ký tự đầu tiên. Tuy nhiên vì gạch dưới thường được sử dụng trong các trường hợp đặc biệt, nên tốt hơn là không sử dụng nó.

4/ Phân biệt chữ hoa chữ thường khi đặt tên cho biến trong python

5/ Không thể sử dụng các từ khóa của Python.

Chúng ta sẽ cùng tìm hiểu chi tiết về các Quy tắc đặt tên biến trong Python ở trên như sau.

Dùng ký tự alphabet, chữ số, gạch dưới để đặt tên biến trong Python

Từ Python 3 trở đi, chúng ta có thể dùng chữ hán tự và tiếng Việt có dấu để Đặt tên cho biến trong python, tuy nhiên Kiyoshi không khuyến khích bạn dùng cách này.

tên = "Kiyoshi"
tuổi =30

名前 = "Kiyoshi"
年齢 = 30

Không dùng các giá trị số cho ký tự đầu tiên của biến

Chúng ta không thể sử dụng các giá trị số cho ký tự đầu tiên của biến trong python, bởi vì lỗi SyntaxError sẽ xuất hiện.

7up = 100

Lỗi SyntaxError:

File "Main.py", line 1
    7up = 100
     ^
SyntaxError: invalid syntax

Phân biệt chữ hoa chữ thường khi đặt tên biến trong Python

Phân biệt chữ hoa chữ thường khi Đặt tên cho biến trong python. Ví dụ hai biến trong ví dụ dưới đây là khác nhau và cho ra kết quả cũng khác nhau:

str = "Tôi yêu"
STR = "Việt Nam"
print(str, STR)

>> Tôi yêu Việt Nam

Không dùng các từ khóa của Python để đặt tên biến trong python

Chúng ta Không thể sử dụng các từ khóa của Python để đặt tên biến trong python. Các từ khóa (keyword) là các từ chỉ dành riêng cho Python và bạn không thể dùng chúng để đặt tên biến được.

Bạn có thể kiểm tra Danh sách các từ khóa trong python bằng câu lệnh dưới đây.

import sys
import keyword
 
print ("Python version: ", sys.version_info)
print ("Python keywords: ", keyword.kwlist)

Và đây là bảng các từ khóa trong python.

False    await    else    import    pass
None    break    except    in    raise
True    class    finally    is    return
and    continue    for    lambda    try
as    def    from    nonlocal while
assert    del    global    not    with
async    elif    if    or    yield

Nếu bạn dùng các từ khóa trong python ở bảng trên để đặt tên biến trong Python thì lỗi SyntaxError sẽ trả về như ví dụ sau:

from = "Việt Nam"

Lỗi SyntaxError:

 File "Main.py", line 1
    from = "Việt Nam"
         ^
SyntaxError: invalid syntax

 

The post Biến Trong Python first appeared on Techacademy.

source https://techacademy.edu.vn/bien-trong-python/

Trong ngữ cảnh testing, 2 tư tưởng Verification (Xác minh) và Validation (Xác nhận) được thực hiện rộng rãi. Trong phần nhiều những trường vừa lòng, bọn họ thường coi bọn chúng có thuộc nghĩa tuy nhiên thực tế nó là 2 tư tưởng không giống nhau. Hãy cùng Techacademy đi tìm hiểu verification testing là gì qua bài viết dưới đây nhé.

I. Validation Testing Là Gì

Validation là quá trình đánh giá sản phẩm cuối cùng để kiểm tra xem phần mềm có đáp ứng được yêu cầu nghiệp vụ không? Hoạt động validation bao gồm smoke testing, functional testing, regression testing, systems testing etc… Để dễ hiểu hơn, chúng ta cùng xem qua thí dụ sau:

Xác Minh		Xác Nhận
“Are you building it right?” (Bạn đang xây dựng nó phải không?)		“Are you building the right thing?” (Bạn đang xây dựng là đúng đắn?)
Đảm bảo phần mềm đáp ứng tất cả các chức năng.		Đảm bảo các chức năng đáp ứng đúng với các hành vi dự định, có trong yêu cầu đã đề ra.
Việc xác minh cần phải là đầu tiên và bao gồm việc kiểm tra tài liệu, code, v.v..		Xác nhận xảy ra sau khi xác minh và phần chính liên quan đến kiểm tra tổng thể.
Hoàn thành bởi Developer.		Hoàn thành bởi Tester.

 

II. Tại Sao Phải Validation Testing?

+ Theo mô hình trưởng thành năng lực (CMM), chúng ta có thể định nghĩa thẩm định là quá trình kiểm tra những phần mềm trong hoặc ở cuối của quá trình phát triển để xác định xem nó đáp ứng các yêu cầu và quy định không.

+ Một sản phẩm có thể đạt yêu cầu trong khi thẩm định, vì nó được thực hiện trên giấy và không chạy hoặc chức năng ứng dụng nào được yêu cầu. Tuy nhiên, khi cùng một thời điểm đó sản phẩm đã được thẩm định trên giấy nhưng sau đó các sản phẩm chạy có thể thất bại trong khi kiểm định. Điều này có thể xảy ra vì lúc một sản phẩm hoặc ứng dụng được xây dựng theo các đặc điểm kỹ thuật nhưng những thông số kỹ thuật không chính xác vì thế họ không thể giải quyết các yêu cầu của người sử dụng.

+ Ưu điểm của kiểm định phần mềm:

• Trong quá trình kiểm định nếu một số khiếm khuyết bị bỏ qua sau đó trong quá trình thẩm định nó có thể được phát hiện thì là lỗi.
• Nếu trong quá trình kiểm định 1 số đặc điểm kỹ thuật bị hiểu nhầm và việc phát triển đã xảy ra sau đó trong quá trình thẩm định khi thực hiện chức năng đó là sự khác biệt giữa kết quả thực tế và kết quả mong đợi có thể được hiểu.
• Thẩm định được thực hiện trong quá trình kiểm thử như kiểm thử chức năng, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử tải, kiểm thử tương thích, …
• Thử nghiệm giúp trong việc xây dựng các sản phẩm đúng theo yêu cầu của khách hàng và đáp ứng nhu cầu của họ.

+ Thẩm định là bước cơ bản được thực hiện bởi các kiểm thử viên trong suốt quá trình kiểm thử. Trong quá trình thẩm định sản phẩm nếu một vài sai lệch được tìm thấy trong kết quả thực tế từ kết quả mong đợi thì sau đó một lỗi sẽ được báo cáo hoặc một sự cố sẽ được đề cập. Không phải hầu hết các sự cố đều là lỗi. Nhưng tất cả các lỗi đều là sự cố. Sự cố cũng có thể là kiểu ‘câu hỏi’ những chỗ nào các chức năng của sản phẩm không rõ ràng dành cho các kiểm thử viên.

+ Do đó, thẩm định giúp đưa ra các chức năng chính xác của các tính năng và giúp các kiểm thử viên hiểu được sản phẩm một cách tốt hơn. Nó giúp việc tạo các sản phẩm thân thiện hơn đối với người sử dụng.

III. Sự Khác Nhau Giữa Verification Và Validation

+ Verification:

1. Đánh giá các sản phẩm trung gian để kiểm tra xem nó có đáp ứng các yêu cầu cụ thể của từng giai đoạn không.
2. Kiểm tra xem sản phẩm có được xây dựng đúng theo yêu cầu và đặc điểm kỹ thuật thiết kế không.
3. Kiểm tra xem “Chúng tôi xây dựng sản phẩm đúng không”?
4. Điều này được thực hiện mà không cần chạy phần mềm.
5. Bao gồm tất cả các kỹ thuật test tĩnh Ví dụ bao gồm các bài đánh giá, kiểm tra và hướng dẫn

+ Validation:

1. Đánh giá sản phẩm cuối cùng để kiểm tra xem nó có đáp ứng được yêu cầu nghiệp vụ không.
2. Xác định xem phần mềm có phù hợp với nhu cầu sử dụng và đáp ứng yêu cầu nghiệp vụ không.
3. Kiểm tra “Chúng tôi xây dựng đúng sản phẩm”?
4. Được thực hiện cùng với việc chạy phần mềm.
5. Bao gồm tất cả các kỹ thuật test động Ví dụ bao gồm tất cả các loại test như smoke test, regression test, functional test, systems test và UAT

IV. Verification Và Validation Trong Các Giai Đoạn Khác Nhau Của Vòng Đời Phát Triển

Một vòng đời phát triển có các giai đoạn khác nhau. Verification và validation được thực hiện trong từng giai đoạn của vòng đời. Chúng ta hãy cùng tìm hiểu

#1. V & V tasks – Lập kế hoạch:

• Xác minh hợp đồng
• Đánh giá tài liệu khái niệm
• Phân tích rủi ro

#2. V & V tasks – Phân tích yêu cầu:

• Đánh giá các yêu cầu phần mềm
• Đánh giá / phân tích các giao diện
• Lập kế hoạch systems test
• Lập kế hoạch Acceptance test

#3. V&V tasks – Giai đoạn thiết kế:

• Đánh giá thiết kế phần mềm
• Đánh giá / Phân tích giao diện (UI)
• Lập kế hoạch Integration test
• Lập kế hoạch Component test
• Tạo test design

#4. V&V Tasks – Giai đoạn triển khai:

• Đánh giá source code
• Đánh giá tài liệu
• Tạo test case
• Tạo test proceduce
• Thực hiện các component test case

#5. V&V Tasks – Giai đoạn test:

• Thực hiện các system test case
• Thực hiện các acceptance test case
• Update tracebility metrics
• Phân tích rủi ro

#6. V&V Tasks – Giai đoạn cài đặt và kiểm tra:

• Kiểm tra việc cài đặt và cấu hình
• Kiểm tra lần cuối cài đặt candidate build (bản build phát hành nội bộ)
• Tạo test report cuối cùng

#7. V&V Tasks – Giai đoạn hoạt động:

• Đánh giá những hạn chế mới
• Đánh giá những đề xuất thay đổi

#8. V&V Tasks – Giai đoạn bảo trì:

• Đánh giá các bất thường
• Đánh giá migration
• Đánh giá tính năng retrial
• Đánh giá những đề xuất thay đổi
• Xác nhận các vấn đề của production

The post Verification Testing Là Gì ? first appeared on Techacademy.

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

Quá trình kiểm thử phần mềm liên quan đến hai loại kiểm thử khác nhau – thủ công và tự động. Có sự khác biệt rõ ràng giữa các loại thử nghiệm này. Kiểm thử thủ công đòi hỏi thời gian và nỗ lực để bảo đảm code phần mềm làm được mọi thứ. Ngoài ra, những người kiểm tra thủ công phải ghi lại những phát hiện của mình. Trong bài viết này, Techacademy sẽ cùng bạn đọc tìm hiểu Automation testing là gì và nó hoạt động như thế nào.

I. Automation Testing Là Gì

Automation testing (Kiểm thử tự động) là quá trình sử dụng các công cụ, script và phần mềm để thực hiện những trường hợp kiểm thử, bằng cách lặp lại những hành động được xác định trước. Automation testing tập trung vào việc thay thế hoạt động thủ công của con người bằng các hệ thống hoặc thiết bị.

Bởi vì Automation testing được thực hiện thông qua một công cụ tự động hóa, nên nó tiêu tốn ít thời gian hơn trong các thử nghiệm khám phá và hiệu quả hơn trong việc duy trì các script kiểm tra, đồng thời nâng cao phạm vi kiểm tra tổng thể.

Automation testing thích hợp nhất cho các dự án lớn yêu cầu kiểm tra lặp lại các khu vực giống nhau và những dự án đã trải qua quá trình thử nghiệm thủ công ban đầu.

II. Ưu, Nhược Điểm Của Automation Testing So Với Manual Testing

+ Ưu điểm:

• Độ tin cậy cao: công cụ kiểm thử tự động có sự ổn định cao hơn so với con người, đặc biệt trong trường hợp nhiều test cases, nên độ tin cậy cao hơn so với kiểm thử thủ công.
• Khả năng lặp: công cụ kiểm thử tự động ra đời là để giúp cho các tester không phải lặp đi lặp lại các thao tác (ví dụ: nhập dữ liệu, click, check kết quả…) 1 cách nhàm chán với độ tin cậy và ổn định cao.
• Khả năng tái sử dụng: với 1 bộ kiểm thử tự động, người ta có thể sử dụng cho nhiều phiên bản ứng dụng khác nhau, đây được gọi là tính tái sử dụng.
• Tốc độ cao: do thực thi bởi máy nên tốc độ của kiểm thử tự động nhanh hơn nhiều so với tốc độ của con người. Nếu cần 5 phú để thực thi một test case một cách thủ công thì có thể người ta chỉ cần khoảng 30s để thực thi một cách tự động.
• Chi phí thấp: nếu áp dụng kiểm thử tự động đúng cách, người ta có thể tiết kiệm được nhiều chi phí, thời gian và nhân lực, do kiểm thử tự động nhanh hơn nhiều so với kiểm thử thủ công, đồng thời nhân lực cần để thực thi và bảo trì scripts không nhiều.

Nhược điểm:

• Khó mở rộng, khó bảo trì: trong cùng một dự án, để mở rộng phạm vi cho kiểm thử tự động khó hơn nhiều so với kiểm thử thủ công vì cập nhật hay chỉnh sửa yêu cầu nhiều công việc như debug, thay đổi dữ liệu đầu vào và cập nhật code mới.
• Khả năng bao phủ thấp: do khó mở rộng và đòi hỏi nhiều kỹ năng lập trình nên độ bao phủ của kiểm thử tự động thấp xét trên góc nhìn toàn dự án.
• Vấn đề công cụ và nhân lực: hiện nay cũng có nhiều công cụ hỗ trợ kiểm thử tự động khá tốt nhưng chúng vẫn còn nhiều hạn chế. Ngoài ra nhân lực đạt yêu cầu (có thể sử dụng thành thạo các công cụ này) cũng không nhiều.

III. Automation Test Làm Những Công Việc Gì?

Thông thường những công việc của automation test sẽ bao gồm:

– Automate TC (ATC): thực hiện các bước trong MỘT kịch bản test, mô phỏng các thao tác của người sử dụng một cách tự động hóa

– Automate automated TC (AATC): thực hiện chạy TOÀN BỘ các kịch bản test (test suite) một cách tự động hóa và report.

Chi tiết:

ATC bao gồm các bước

– Chuẩn bị test data (nếu cần): ví dụ lựa chọn test data hợp lệ bao gồm 1 email và 1 password ngẫu nhiên để đăng ký tài khoản mới, bạn phải tự động tạo 1 email hợp lệ sau mỗi test case.

– Thực hiện mô phỏng các thao tác của người dùng trong kịch bản test bằng việc viết các script sử dụng các ngôn ngữ hỗ trợ khác nhau.

– Thực hiện việc so sánh kết quả thực tế và kết quả mong đợi trong mỗi kịch bản test

– Cập nhật kết quả test của kịch bản test

AATC bao gồm các bước:

– Chuẩn bị môi trường để test: bước này có thể sẽ phải triển khai môi trường cho automation test, hoặc chuẩn bị các file cài đặt, các test data….

– Khởi chạy test suite: theo cấu hình hoặc yêu cầu từ trước, ví dụ như: chạy các test case UAT, hoặc các nhóm test case liên quan tới 1 function nào đó….

– Báo cáo: việc báo cáo có thể được thực hiện update dần thông qua từng kịch bản test (như extend report, allure report), hoặc có thể tạo DB report riêng và dashboard riêng để hiển thị kết quả. Ngoài ra, tùy theo yêu cầu của project mà report được thông báo với các bên liên quan thông qua các công cụ hỗ trợ, như slack, skype, email, jira…..

IV. Quy Trình Automation Test

Thành công trong tự động hóa việc thử nghiệm đòi hỏi việc lập kế hoạch và thiết kế cẩn thận. Các bước sau được thực hiện theo quy trình tự động hóa:

+ Lựa chọn công cụ kiểm thử

Trước khi áp dụng Automation testing, bạn nên xác định mục tiêu. Bây giờ, lúc bạn chắc chắn mình đang thực hiện loại kiểm tra nào, bạn cần chọn công cụ kiểm thử phần mềm. Bạn cần cân nhắc những điểm sau khi chọn công cụ:

• Nó có dễ dàng để phát triển và duy trì các script cho công cụ hay không?
• Nó có hoạt động trên các nền tảng như web, điện thoại di động, máy tính để bàn, v.v… không?
• Công cụ có chức năng báo cáo kiểm thử không?
• Công cụ này có thể hỗ trợ bao nhiêu loại kiểm thử?
• Công cụ hỗ trợ bao nhiêu ngôn ngữ?

+ Xác định phạm vi tự động hóa

• Tiếp theo, bạn cần xác định phạm vi tự động hóa. Vì vậy, bạn cần quyết định trường hợp kiểm thử nào sẽ tự động hóa dựa trên những điều sau:
• Các tình huống có một lượng lớn dữ liệu
• Những trường hợp thử nghiệm có chức năng chung trên các ứng dụng
• Tính khả thi về kỹ thuật
• Mức độ có thể sử dụng lại các thành phần của doanh nghiệp
• Sự phức tạp của các trường hợp kiểm thử

+ Lập kế hoạch, thiết kế và phát triển

Sau khi xác định mục tiêu và loại thử nghiệm nào cần tự động hóa, bạn nên quyết định những hành động mà Automation testing sẽ thực hiện. Việc lập kế hoạch, thiết kế và phát triển bao gồm:

– Phát triển các trường hợp kiểm thử: Các bài kiểm tra tự động lớn, phức tạp luôn rất khó chỉnh sửa và gỡ lỗi. Tốt nhất nên chia các bài kiểm tra thành nhiều bài kiểm tra đơn giản, logic và nhỏ hơn.

– Phát triển bộ kiểm thử: Bộ thử nghiệm bảo đảm rằng các trường hợp thử nghiệm tự động chạy lần lượt mà không cần bất kỳ sự can thiệp thủ công nào. Bây giờ, điều này có thể dễ dàng được thực hiện bằng cách tạo 1 bộ kiểm thử có nhiều trường hợp thử nghiệm, một thư viện và công cụ dòng lệnh chạy bộ kiểm thử.

+ Thực thi kiểm thử

Các script tự động hóa được thực thi trong giai đoạn này. Ngoài ra, việc thực thi có thể được thực hiện bằng cách sử dụng công cụ tự động hóa trực tiếp hoặc thông qua công cụ quản lý kiểm thử sẽ gọi công cụ tự động hóa.

+ Bảo trì

Khi những trường hợp kiểm thử được thực thi, bước tiếp theo là tạo báo cáo để những hành động thực hiện trong quá trình thử nghiệm được ghi lại. Khi các chức năng mới được thêm vào phần mềm mà bạn đang thử nghiệm với những chu kỳ liên tiếp, các script tự động hóa cần được thêm, xem xét và duy trì cho mỗi chu kỳ phát hành. Do đó, việc bảo trì trở nên cần thiết để nâng cao hiệu quả của tự động hóa.

V. Khi Nào Nên Áp Dụng Automation Testing

• Trường hợp kiểm thử cần thực hiện nhiều lần, thường xuyên phải thực hiện regression test, một số lượng test data lớn cần hoàn thành trong một thời gian ngắn.
• Kiểm thử cần thực hiện ở môi trường khác nhau
• Áp dụng với những project ổn định, đặc điểm kĩ thuật được xác định trước, chức năng không thay đổi trong tương lai
• Kiểm thử hoạt động cơ bản mà phải thực hiện lặp lại với lượng test data lớn
• Kiểm tra nhiều màn hình trong thời gian ngắn, liên tục
• Thực thi test performance test hoặc load test thì kiểm thử tự động gần như là lựa chọn duy nhất

VI. Học Gì Để Trở Thành Automation Tester ?

+ Nắm kiến thức về Manual Testing

• Các loại kiểm thử: Unit Test, Intergration Test, System Test, Acceptance Test, Regression Test, Sanity Test, Smoke Test… là gì?
• Các kiến thức căn bản: Phân tích giá trị biên, phân vùng tương đương, biểu đồ kết quả, đoán lỗi…
• Rèn luyện khả năng quan sát và nhìn nhận vấn đề đối với 1 case nào đó bất kỳ. Cần kiểm tra cái gì, đến mức độ nào, cái nào quan trọng hơn cái nào,…Để sau còn biết cái nào mang sang Auto Test cái nào giữ lại cho Manual Test.

Tại sao phải trang bị những kiến thức này, bởi vì một Automation Tester sẽ không design được đúng hoặc đủ tất cả những Cases mà mình cần nếu không nắm chắc những nội dung này. Và trong trường hợp bạn phải ôm xô cả vai trò của Manual Tester hoặc phải design Test Case trước khi thực hiện viết kịch bản Auto thì chắc hơi căng đấy =))

+ Hiểu về HTML, CSS và Xpath

• Để nhận dạng đúng Test Objects/ Elements mà mình cần thao tác cho auto test.
• Vô cùng quan trọng: việc nhận dạng đúng đối tượng cần thao tác sẽ tăng sự ổn định và độ chính xác của Test Script.

+ Học ít nhất một ngôn ngữ lập trình

Để hỗ trợ cho việc viết kịch bản trên test tools

• Java/ C#/ Python/ Ruby/ Javascript/ Groove…

Đây là phần cực kì quan trọng nếu bạn muốn làm tốt và phát triển công việc của một Automation Tester.

Riêng ở Việt Nam thì An gợi ý là học ngôn ngữ Java để kết hợp Selenium Java. Các công ty đang làm và tuyển dụng phổ biến.

+ Sử dụng thư viện hỗ trợ auto test

Phần này khá là quan trọng trong thời điểm hiện tại, Selenium được sử dụng tại hầu hết các công ty có làm Automation cho Website (open source, dễ sử dụng, cộng đồng lớn).

Song song đó thì chúng ta dùng Appium để auto test cho Mobile.

+ Tự build code với Framework Testing

JUnit/ TestNG/ Cucumber/ Specflow/ NUnit/ XUnit/ MSTest/ Pytest…

Việc sử dụng thành thạo sẽ giúp bạn rất nhiều trong việc build framework, hỗ trợ trong việc phân nhóm, quản lí test script, report, prepare data/ environment/ browsers.

+ Học hỏi công nghệ mới trong mảng Automation Testing

Khi mà đã code được hoàn thiện dự án automation test rồi thì bước tiếp theo sẽ là nghiên cứu học hỏi các công nghệ mới bổ trợ cho mình về sau lâu dài để nâng cao kiến thức, hiệu quả cũng như năng suất cho auto test.

• Build tools: Maven, ANT,…
• CI/CD: Jenkins, TeamCity, CircleCI, TFS, Docker, …
• Cloud: AWS, Saucelab, Browserstack, Testingbot,…
• BDD: Cucumber, Serenity, Specflow,…
• Big Data: Hadoop, HBase, Kafka, Spark, Hive,…
• Mobile: Appium, Perfecto,…
• Automation Testing Tools: Katalon Studio, Katalon Recoder, Selenium IDE,…và một số Extensions trên Browser

+ Tìm hiểu về Software Design Pattern

Để build framework/ common library mục đích làm cho source code mình nó bài bản hơn. Sau này dễ custom dễ optimize.

+ Build Framework với kiểu Page Object Model pattern (POM)

Hầu hết các framework nổi tiếng hiện nay đều kế thừa ý tưởng từ pattern này nên việc bạn sử dụng thành thạo POM sẽ không khó lúc tiếp cận một công nghệ/ framework mới.

Sau khi build thành công framework, apply vào một dự án thực tế bất kì để kiểm nghiệm.

+ Kĩ năng về Coding/ IDE

Khi mà đã biết code rồi thì rèn luyện code nhanh hơn, mượt hơn, nghiên cứu các cách xử lý lỗi xảy ra để cứng tay hơn =))

• Debug, coding convention, source version control (GIT, SVN,…)
• Cách dùng IDE: Visual Studio, Eclipse, IntelliJ,…
• Cài  những Extension bổ trợ hoặc viết luôn Extension cho IDE để code bá cháy hơn

+ Làm việc với Database

Hầu hết dự án phần mềm nào cũng có thao tác với DB, nắm vững kiến thức về truy vấn, verify data, ràng buộc dữ liệu,.. sẽ giúp bạn rất nhiều trong công việc hàng ngày của Automation Tester.

VII. Những Kỹ Năng Nào Là Cần Thiết Dành Cho Một Automation Tester?

1) Hiểu nguyên lý nhận dạng test objects. Nếu làm Web Automation Test cần nắm rõ HTML và XPath. Bạn có thể học hai mảng này ở W3School.

2) Hiểu nguyên lý lập trình, và thành thạo ít nhất 1 ngôn ngữ lập trình. Web Automation Engine được dùng phổ biến ở thị trường hiện nay là Selenium WebDriver, có kết hợp cho những ngôn ngữ Java, C#, Ruby, Python…

Ngoài ra các bạn có thể tham khảo thêm các ngôn ngữ scripting phổ biến như VBScript, JavaScript hoặc Groovy nếu cần.

3) Không bỏ qua SQL và XML. Hai mảng này bạn có thể học tại TutorialsPoint và W3School.

Đa số các dự án lập trình đều cần có cơ sở dữ liệu. XML được hiểu như một phần của portal database và SML cũng được dùng tương đối nhiều hiện nay.

4) Những bạn muốn đi sâu vào thiết kế tốt framework/common library thì nên tìm hiểu sâu về software design pattern.

5) Làm Automation Tester là liên quan đến coding nên các bạn cần quan tâm tới những kỹ năng của code như debug, source version control, coding convention, unit testing… Tìm kiếm các từ khoá này trên Google là thấy ngay tài liệu.

6) Nên ham học hỏi những cái mới trong chuyên môn.

Ví dụ, xu thế Automation Test và software development hiện tại là kỹ thuật tích hợp (integration). Đó là 1 chuỗi khép kín, tương tác giữa development, deploy và test. Anh đang nghiên cứu kỹ thuật này vì nó là xu hướng chung, không học hỏi sẽ bị tụt hậu.

VIII. Các Tool Automation Test

Với sự gia tăng trong việc áp dụng các phương pháp Agile và DevOps, ngành công nghiệp kiểm thử phần mềm đang trải qua một sự thay đổi mô hình. Automation test đang ngày càng được ưa chuộng vì chỉ cần rất ít thời gian để thực hiện kiểm thử. Các công cụ kiểm tra tự động hóa không chỉ cung cấp tự động hóa một cách thông minh mà còn cung cấp các hướng phân tích để giải quyết mọi thách thức khi tiến hành kiểm thử.

Dưới đây là danh sách 5 công cụ và khung kiểm tra tự động hóa hàng đầu có thể cải thiện đáng kể kết quả kiểm thử phần mềm của bạn.

+ Selenium

Selenium được dùng để kiểm tra trình duyệt chéo ( cross-browser testing) và tự động hóa kiểm tra trình duyệt web (web-browser test automation). Để sử dụng công cụ này, người kiểm tra phải có kỹ năng lập trình nâng cao để viết các kịch bản kiểm tra phức tạp và nâng cao.

Những kỹ năng này là cần thiết để xây dựng các khung và thư viện tự động hóa cho các nhu cầu kiểm thử cụ thể. Selenium là một công cụ nguồn mở thường được sử dụng bởi các nhà phát triển và người thử nghiệm, những người thông thạo các ngôn ngữ lập trình như Java, C #, Perl, Python, Scala, Groovy, PHP & Ruby.

Selenium được trang bị Selenium WebDriver mạnh mẽ cho phép bạn tạo các bộ kiểm tra và tự động hồi quy dựa trên trình duyệt. Một trong những lợi thế chính của công cụ này là nó cho phép bạn chia tỷ lệ và phân phối các tập lệnh trên nhiều môi trường.

+ IBM Rational Functional Tester (RFT)

IBM RFT rất phù hợp để kiểm thử hồi quy (regression testing) và kiểm thử chức năng (functional testing). Đây là một nền tảng kiểm thử (testing platform) dựa trên dữ liệu hỗ trợ các ứng dụng như .Net, Java, SAP, Flex và Ajax. Các ngôn ngữ kịch bản được sử dụng bởi RFT là .Net và Java.

Một trong những tính năng độc đáo của IBM RFT là kiểm thử Storyboard (Storyboard testing) giúp đơn giản hóa kiểm thử trực quan bằng cách ghi lại và trực quan hóa các hành động của người dùng với sự trợ giúp của các ảnh chụp màn hình ứng dụng theo định dạng bảng phân cảnh. Nó cũng cho phép chỉnh sửa bằng ngôn ngữ tự nhiên. Nó cũng cung cấp tích hợp với quản lý vòng đời ứng dụng IBM Jazz như IBM Rotational Team Concert và Rational Quality Manager.

+ Cucumber

Cucumber là khung phát triển hướng hành vi (BDD) cho phép xác thực chức năng theo định dạng dễ hiểu và dễ đọc. BDD là một cách tiếp cận mở rộng của Phát triển hướng thử nghiệm (Test Driven Development) và nó được sử dụng để kiểm tra hầu hết hệ thống thay vì kiểm tra một đoạn mã cụ thể.

Cucumber là 1 công cụ để làm việc với các thông số kỹ thuật thực thi. Các thông số kỹ thuật thực thi được sử dụng cho sự hợp tác lớn hơn giữa các nhóm CNTT và doanh nghiệp. Công cụ này hữu ích để viết acceptance tests cho ứng dụng web. Cucumber cung cấp các tệp tính năng có thể được sử dụng làm tài liệu của các Nhà phân tích, Nhà phát triển và Người kiểm tra, v.v. Cucumber hỗ trợ các ngôn ngữ như Perl, PHP, Python, Net, v.v.

+ TestComplete

TestComplete cho phép bạn xây dựng và chạy các kiểm thử giao diện người dùng chức năng (functional UI tests). Đây là một công cụ kiểm tra tự động hóa rất phù hợp để kiểm tra các ứng dụng máy tính để bàn, thiết bị di động và web. Công cụ cho phép bạn tạo ra các trường hợp kiểm thử bằng hầu hết các ngôn ngữ phổ biến như Python, JavaScript và VBScript, v.v …

Nó cho phép bạn ghi lại và phát lại các bài kiểm thử. Nó cung cấp các khả năng nhận dạng đối tượng GUI UI tự động phát hiện và cập nhật các đối tượng UI. Nó giúp giảm bớt những nỗ lực cần thiết để duy trì các kịch bản kiểm thử (test scripts) . Với TestComplete, việc kiểm thử quy mô trên 1500+ môi trường thử nghiệm thực tế là tươg đối dễ dàng để cung cấp phạm vi kiểm tra hoàn chỉnh.

+ eggPlant

Một trong những công cụ kiểm tra tự động hóa tốt nhất cho ứng dụng và kiểm tra GUI là eggPlant. TestPlant đã phát triển eggPlant cho tester để thực hiện các loại kiểm thử khác nhau. Trong khi hầu hết các công cụ tự động hóa tuân theo cách tiếp cận dựa trên đối tượng, eggPlant hoạt động theo cách tiếp cận dựa trên hình ảnh.

Công cụ cho phép người kiểm tra tương tác với ứng dụng giống như cách endusers sẽ làm. Trong eggPlant, bạn có thể sử dụng một tập lệnh duy nhất để thực hiện kiểm thử trên nhiều nền tảng như Windows, Mac, Linux và Solaris, v.v. eggPlant cung cấp một bộ công cụ tự động hóa kiểm thử để thực hiện các loại kiểm thử khác nhau.

Công cụ kiểm tra chức năng eggPlant được sử dụng để kiểm tra chức năng và hiệu suất eggPlant được sử dụng để kiểm tra hiệu suất, tải và ứng suất (performance testing, load testing và stress testing).

IX. Các Câu Hỏi Phỏng Vấn Automation Test

+ Tại sao cần Automation Test? (Why need automation test?)

Câu hỏi này để đánh giá kiến thức sơ bộ của bạn về automation test và việc bạn có biết mục đích sử dụng automation test để sử dụng nó có hiệu quả.

• Giúp tiết kiệm tiền bạc và thời gian: nhất là trong giai đoạn bảo trì của những dự án lớn. Mỗi tuần chúng ta phải thực hiện regression test từ 1 đến 2 lần với số lượng test case rất lớn trong 1 tới 2 ngày. ĐIều này gần như không thể thực hiện bằng cách thủ công, trong lúc với kiểm thử tự động chúng ta hoàn toàn có thể với nguồn nhân lực vô cùng khiêm tốn.
• Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các test case với độ chính xác cao hơn.
• Độ bao phủ cao: Như đã nói ở trên, khi dùng kiểm thử tự động, chúng ta có thể thực thi số lượng lớn test case trong một thời gian ngắn. Nên độ bao phủ của nó rất cao. Điều này giúp chúng ta nâng cao độ bao phủ trong giai đoạn regression test.
• Hoàn thành những công việc mà con người không thể làm được: Nếu chúng ta muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất.

Các trường hợp cần sử dụng automation test:

a) Kiểm thử hồi quy (Regression testing): Trong trường hợp sửa lỗi hoặc triển khai module mới, tester phải đảm bảo rằng chức năng đã được triển khai hoặc không thay đổi không bị ảnh hưởng. Trong trường hợp này, tester kết thúc chạy test case hồi quy nhiều lần.

Ví dụ: Sau mỗi yêu cầu thay đổi hoặc sửa lỗi, sau mỗi lần lặp trong trường hợp tiếp cận phát triển gia tăng, v.v.

b) Kiểm thử phi chức năng: Kiểm thử các khía cạnh phi chức năng của một ứng dụng.

Ví dụ: kiểm thử tải (load testing) hoặc kiểm thử hiệu suất (performance testing), vv rất khó cho con người theo dõi và phân tích.

c) Kiểm thử tính toán phức tạp: các test scenario dễ bị lỗi khi kiểm thử thủ công.

d) Thực hiện lặp lại các kiểm thử giống nhau: Đôi khi, tester phải chạy cùng một bộ test case cho một bộ dữ liệu khác nhau hoặc sau mỗi lần phát hành bản dựng hoặc trên nhiều phần cứng, phần mềm hoặc kết hợp cả hai.
Kiểm thử tự động các test case trong các tình huống trên giúp đạt được tốc độ kiểm thử và giảm thiểu lỗi của con người.

+ Framework là gì? (What is the framework?)

Câu hỏi để đánh giá sơ bộ cách build framework của bạn và liệu frame work đó có hiệu quả không?

Framework là một tập hợp cấu trúc của toàn bộ bộ kiểm thử tự động. Nó cũng là một hướng dẫn, mà nếu tuân theo có thể dẫn đến một cấu trúc dễ bảo trì và nâng cao.

Những hướng dẫn này bao gồm:

– Tiêu chuẩn mã hóa

– Xử lý dữ liệu kiểm thử

– Duy trì và xử lý các phần tử (kho đối tượng trong QTP)

– Xử lý tệp môi trường và tệp thuộc tính

– Báo cáo dữ liệu

– Xử lý nhật ký

+ Automation test framework là gì?

Có thể hiểu đơn giản đó là một application project được dựng lên để tự động hóa việc kiểm thử một ứng dụng nào đó. Như vậy, bản thân framework cũng chính là một ứng dụng. Nó cũng phải được thiết kế hoàn chỉnh, được apply những design pattern, và cũng phải dựa trên những định nghĩa, quy tắc cơ bản nhất của ngôn ngữ lập trình được sử dụng để phát triển nên framework đó. Framework có thể được deploy như một ứng dụng hoàn chỉnh, hoặc cũng có thể được đóng gói thành các thư viện để được tiếp tục được phát triển.

+ Trách nhiệm của một Automation Engineer?

Automation Engineer không chỉ làm công việc viết automation script. Họ trước hết vẫn phải là một QA Tester đúng nghĩa. Đó là phải có sự am hiểu về mặt nghiệp vụ (business) của hệ thống. Có thể hiểu ít nhất mức độ quan trọng của việc kiểm thử, biết cách viết test case, log defect. Thực tế công việc thì người Automation Engineer sẽ kiêm luôn công việc của một Manual QA, và khi đã feature nào đã được hoàn tất, họ sẽ bắt tay vào việc implement các test case liên quan tới feature đó thành automation.

Trên thực tế, từ một QA thuần manual để chuyển sang Automation QA thực sự không phải là việc dễ dàng vì có dính tới code, và cũng đòi hỏi nhiều mindset, kỹ năng của một developer. Vì vậy, bạn cũng đừng ngạc nhiên khi thấy có nhiều Developer chuyển sang làm Automation QA nhưng từ Manual QA mà chuyển sang Automation thành công lại khá hiếm.

Đó là bởi vì developer đã có sẵn dev skills và coding mindset, là những thứ cần rất nhiều thời gian + năng khiếu mới có được. Khi đó, chỉ cần học hỏi thêm mindset và kỹ năng cơ bản của một Manual QA là đã có thể bắt đầu con đường của một Automation QA được rồi.

Tuy nhiên, một full-stack QA không chỉ cần có Manual và Automation skills mà còn cần phải có ít nhiều kỹ năng của một DevOps để có thể tự deploy và maintain những gì mình đã xây dựng. Và cuối cùng là khả năng ngoại ngữ + giao tiếp để có thể deliver những gì mình đã và đang làm tới khách hàng.

+ Nêu 4 tính chất cơ bản của Lập trình hướng đối tượng OOP (Object-Oriented Programming)?

Phần lớn các automation framework hiện nay được xây dựng dựa trên Selenium kết hợp với một ngôn ngữ lập trình hướng đối tượng (phổ biến nhất có lẽ là Java và C#). Vậy nên dĩ nhiên các câu hỏi phỏng vấn sẽ ít nhiều liên quan tới OOP.

4 tính chất cơ bản của OOP thì có lẽ ai cũng biết, đó là:

– Encapsulation (tính đóng gói).

– Abstraction (tính trừu tượng).

– Inheritance (tính kế thừa).

– Polymorphism (tính đa hình).

Nhưng để hiểu và giải thích được cặn kẽ cả 4 tính chất này thì bạn cần ít nhất 1-2 tiếng đồng hồ để thử practice và nghiền ngẫm qua các ví dụ đầy rẫy trên mạng.

X. Khóa Học Automation Testing Ở Đâu Tốt Nhất

Hiện nay có nhu cầu tuyển Tester tăng cao, rất nhiều nhà tuyển dụng lớn như Seta Cinq (Mỹ và Nhật), Exoplatform (Pháp), Sumy(Cty VN có các dự án ở Malaysia) … Nên việc xin việc đối với các học viên sau Khoá học Automation testing của Techacademy.edu.vn là điều dễ dàng. Đây là thời cơ rất tốt cho những bạn sinh viên học CNTT.

Phương pháp đào tạo

Cụm từ “tự động hóa” đã và đang được nhắc đến cực kỳ nhiều mục đích thường rất đa dạng, phụ thuộc vào yêu cầu đặc thù của từng lĩnh vực. Tuy nhiên điểm chung nhất vẫn là giảm nhân lực thời gian và sai sót.

Ngành CNTT mà cụ thể là phát triển phần mềm cũng không ngoại lệ. Đặc biệt với sự phát triển như vũ bão về công nghệ, ý tưởng mới như hiện nay đòi hỏi cách doanh nghiệp phần mềm phải rút ngắn thời gian đưa sản phẩm ra thị trường (time to market) với chất lượng tốt nhất.

Kiểm thử tự động bởi thế có thêm nhiều cơ hội và thách thức mới trở thành ngành “hot” đang được tìm kiếm và quan tâm nhất.

Ngoài ưu điểm về giảm thiểu thời gian và nhân lực trong kiểm tra hồi quy (regression test) thì để thích ứng với mô hình Agile, test tự động còn phải đáp ứng thêm những yêu cầu sau:

– Đáp ứng nhanh các yêu cầu của kiểm thử viên về cả kiểm tra hồi quy (regression) và các chức năng mới (new test cases).

– Thời gian scripting ngắn, dễ dàng review + đối chiếu với SRS, và khả năng tái sử dụng cao (maintenance).

– Phản hồi thông tin nhanh cho đội phát triển về chất lượng phần mềm (Quick feedback to development team).

– Dễ dàng mở rộng và thích ứng với các công nghệ mới.

– Chi phí thấp

Trước các yêu cầu mới này ICT – HÀ NỘI phối hợp với các doanh nghiệp lớn đã xây dựng chương trình đào tạo kiểm thử phần mềm tự động với mục đích:

– Giúp học viên nắm được công cụ và quy trình làm test tự động.

– Sẵn sàng tham gia vào quá trình áp dụng và triển khai kiểm thử phần mềm tự động cho các dự án Web, Desktop, Mobile vừa và lớn.

– Có khả năng mở rộng xây dựng các framework, cập nhật các công nghệ kiểm thử tự động mới.

– Đặc biệt giúp công ty nơi học viên sau khi kết thúc khóa học làm việc có được các phương pháp mới nhất với chi phí thấp nhất về test tự động theo mô hình ATDD (acceptance test driven development) để có khả năng đấu thầu các dự án lớn trên thế giới.

The post Automation Testing Là Gì ?(Kiểm Thử Tự Động Là Gì ?) first appeared on Techacademy.

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

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

System Testing	Acceptance Testing
1. Kiểm thử hệ thống được thực hiện để kiểm tra xem phần mềm đáp ứng các yêu cầu đã quy định.	1. Kiểm thử chấp nhận là kiểm thử chức năng, được thực hiện để kiểm tra xem phần mềm đáp ứng những yêu cầu của khách hàng.
2. Kiểm thử hệ thống được thực hiện bởi những người phát triển và các nhân viên kiểm thử.	2. Kiểm thử chấp nhận được thực hiện bởi khách hàng , người dùng và các bên liên quan.
3. Kiểm thử hệ thống kiểm tra cả các yêu cầu chức năng và phi chức năng	3. Kiểm thử chấp nhận kiểm tra các yêu cầu chức năng
4. Trong kiểm thử hệ thống, sẽ kiểm tra cách toàn bộ hệ thống được thực hiện, thực hiện kiểm tra các chức năng.	4. Trong kiểm thử chấp nhận sẽ kiểm tra hệ thống đáp ứng các nhu cầu kinh doanh của tổ chức, khả năng sử dụng của sản phẩm
5. Được thực hiện với dữ liệu demo và không phải là dữ liệu thực tế.	5. Được thực hiện với các dữ liệu thời gian thực tế.
6. Kiểm thử phần mềm cho đặc tả yêu cầu đầy đủ bao gồm cả phần cứng và phần mềm, bộ nhớ và số lượng người dùng.	6. Kiểm thử phần mềm cho các nhu cầu sử dụng và nhu cầu của người sử dụng được đáp ứng trong phát triển phần mềm.
7. Kiểm thử hệ thống bao gồm kiểm thử hệ thống và kiểm thử tích hợp hệ thống	7. Kiểm thử chấp nhận bao gồm kiểm thử alpha và kiểm thử beta.
8. Kiểm thử hệ thống được tiến hành trước kiểm thử chấp nhận	8. Kiểm thử chấp nhận được thực hiện sau kiểm thử hệ thống.
9. Kiểm thử hệ thống liên quan tới kiểm thử phi chức năng là hiệu suất tải (performance load) và kiểm thử stress .	9. Kiểm thử chấp nhận liên quan đến kiểm thử chức năng đó là phân tích giá trị biên, phân vùng tương đương và bảng quyết định.
10. Kiểm thử hệ thống được thực hiện bởi nhóm các nhân viên kiểm thử, nó sẽ chứa nhiều trường hợp kiểm thử bất thường (abnormal test cases) .	10. Kiểm thử chấp nhận chứa nhiều các trường hợp kiểm thử thông thường (normal test cases) .
11. Các lỗi tìm thấy trong kiểm thử hệ thống có thể được sửa dựa trên độ ưu tiên.	11. Các lỗi tìm thấy trong kiểm thử chấp nhận được xem như là sự thất bại của sản phẩm.
12. Kiểm thử hệ thống cho tất cả các dữ liệu đầu vào giả có thể.	12. Kiểm thử với các dữ liệu ngẫu nhiên

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

Unit Testing	Integration Testing	Functional Testing
Định nghĩa và mục đích	Kiểm thử riêng biệt từng đơn vị hoặc từng module	Kiểm thử tích hợp hai hay nhiều đơn vị/modules kết hợp cùng với nhau để hoàn thành nhiệm vụ	Kiểm tra các hành vi của các ứng dụng theo yêu cầu.
Mức độ phức tạp	Không hề phức tạp vì nó bao gồm các dòng code nhỏ nhất	Phức tạp hơn một chút so với kiểm thử đơn vị	Phức tạp hơn so với kiểm thử đơn vị và kiểm thử tích hợp
Kỹ thuật kiểm thử	Kiểm thử hộp trắng	Kiểm thử hộp trắng, đen và xám	Kiểm thử hộp đen
Những điểm cần lưu ý chính	Những đơn vị hoặc module riêng lẻ	Tích hợp những đơn vị hoặc module	Toàn bộ chức năng ứng dụng
Lỗi/vấn đề được tìm thấy	Tìm các vấn đề có thể xảy ra thường xuyên trong các module	Tìm các vấn đề có thể xảy ra trong lúc tích hợp các module khác nhau	Tìm thấy vấn đề không cho phép 1 ứng dụng thực hiện các chức năng của nó. Điều này bao gồm một số vấn đề dựa trên kịch bản dựa test.
Lọt bug	Không có cơ hội lọt bug	Ít có cơ hội	Nhiều cơ hội lọt issue lúc danh sách chức năng phải test luôn là vô hạn.

 

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

1. Định nghĩa	– Kiểm tra hộp đen là cách thử nghiệm phần mềm được ѕử dụng để đánh giá những phần mềm mà không quan tâm tới cấu trúc bên trong của chương trình.	– Kiểm tra hộp trắng là cách kiểm thử phần mềm, ѕử dụng để kiểm tra phần mềm mà уêu cầu phải biết cấu trúc bên trong của chương trình.
2. Trách nhiệm	– Thử nghiệm được thực hiện bên ngoài, không liên quan đến nhà phát triển phần mềm.	– Thông thường, các thử nghiệm được thực hiện bởi nhà phát triển phần mềm.
3. Cấp độ teѕt ѕử dụng	– Thử nghiệm áp dụng ở cấp độ cao như: kiểm tra hệ thống (Sуѕtem teѕt), kiểm tra chấp nhận (Acceptance teѕt)	– Thử nghiệm được áp dụng ở mức độ thấp hơn như thử nghiệm đơn ᴠị (Unit Teѕt), thử nghiệm hội nhập (Integration teѕt)
4. Biết lập trình	– Không уêu cầu hiểu biết ᴠề Lập trình	– Yêu cầu hiểu biết nhất định ᴠề lập trình.
5. Biết ᴠiệc thực hiện chương trình	– Không уêu cầu hiểu ᴠề cấu trúc bên trong chức năng, ᴠà không cẩn hiểu làm thế nào để có được chức năng đó	– Yêu cầu hiểu cấu trúc bên trong chức năng được thực hiện như nào.
6. Cơ ѕở tạo Teѕt Caѕeѕ	– Kiểm tra hộp đen được bắt đầu dựa trên tài liệu уêu cầu kỹ thuật	– Kiểm tra hộp trắng được bắt đầu dựa trên các tài liệu thiết kế chi tiết

 

 

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:

Ưu điểm	Nhược điểm
Phù hợp và hiệu quả khi số lượng các dòng lệnh của hệ thống là lớn.	Bị giới hạn bởi độ bao phủ của các trường hợp kiểm thử
Không cần truy cập mã nguồn.	Kiểm thử không hiệu quả, do thực tế tester bị hạn chế kiến ​​thức về hệ thống.
Phân biệt rõ ràng quan điểm của người dùng với quan điểm của nhà phát triển thông qua các vai trò được xác định rõ ràng.	Không có độ bao phủ, vì người kiểm thử không thể kiểm tra các đoạn mã nguồn hoặc tập trung vào các đoạn mã bị lỗi.
Một số lượng lớn tester có kỹ năng vừa phải có thể kiểm tra ứng dụng mà không cần có nhiều kiến ​​thức, ngôn ngữ lập trình hoặc hệ điều hành.	Rất khó để thiết kế được hầu hết các trường hợp kiểm thử cho hệ thống.

 

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

1. Định nghĩa	– Kiểm tra hộp đen là phương pháp thử nghiệm phần mềm được ѕử dụng để đánh giá những phần mềm mà không quan tâm tới cấu trúc bên trong của chương trình.	– Kiểm tra hộp trắng là phương pháp kiểm thử phần mềm, ѕử dụng để kiểm tra phần mềm mà уêu cầu phải biết cấu trúc bên trong của chương trình.
2. Trách nhiệm	– Thử nghiệm được thực hiện bên ngoài, không liên quan đến nhà phát triển phần mềm.	– Thông thường, các thử nghiệm được thực hiện bởi nhà phát triển phần mềm.
3. Cấp độ teѕt ѕử dụng	– Thử nghiệm áp dụng ở cấp độ cao như: đánh giá hệ thống (Sуѕtem teѕt), kiểm tra chấp nhận (Acceptance teѕt)	– Thử nghiệm được áp dụng ở mức độ thấp hơn như thử nghiệm đơn ᴠị (Unit Teѕt), thử nghiệm hội nhập (Integration teѕt)
4. Biết lập trình	– Không уêu cầu hiểu biết ᴠề Lập trình	– Yêu cầu hiểu biết nhất định ᴠề lập trình.
5. Biết ᴠiệc thực hiện chương trình	– Không уêu cầu hiểu ᴠề cấu trúc bên trong chức năng, ᴠà không cẩn hiểu làm thế nào để có được chức năng đó	– Yêu cầu hiểu cấu trúc bên trong chức năng được thực hiện như nào.
6. Cơ ѕở tạo Teѕt Caѕeѕ	– Kiểm tra hộp đen được bắt đầu dựa trên tài liệu уêu cầu kỹ thuật	– Kiểm tra hộp trắng được bắt đầu dựa trên các tài liệu thiết kế chi tiết

 

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/