I. Khái quát chung về Test

1. Khái niệm về Kiểm thử (Test)

Kiểm thử là quá trình đánh giá một hệ thống hoặc bộ phận của nó để xem nó có thỏa mãn yêu cầu hay không. Nói một cách đơn giản, testing là thực hiện chạy một hệ thống để tìm ra những chỗ thiếu sót, lỗi hay phần yêu cầu bị thiếu so với yêu cầu thực tế. Theo tiêu chuẩn ANSI/IEEE 1059 thì testing được định nghĩa là một quá trình phân tích một nội dung phần mềm để tìm ra sự khác nhau giữa điều kiện đang có và điều kiện yêu cầu (Đó chính là thiếu sót/Sai lầm/Lỗi kỹ thuật) và để đánh giá những đặc tính của sản phẩm phầm mềm.

2. Ai thực hiện việc test?

Điều này phụ thuộc vào quy trình và các bên liên quan trong dự án. Trong giới IT, các công ty lớn sẽ có một nhóm chịu trách nhiệm đánh giá phần mềm đã được phát triển trong bối cảnh yêu cầu được đưa ra. Tuy nhiên, người lập trình viên cũng tiến hành test và được gọi là Unit Testing. Trong nhiều trường hợp, các chuyên gia sau cũng liên quan đến việc kiểm thử một hệ thống trong quyền hạn tương ứng.

• Software Tester
• Software Developer
• Project Lead/Manager
• End User

Các công ty khác nhau sẽ có những chỉ định khác nhau cho người thực hiện kiểm thử phần mềm dựa vào kinh nghiệm và sự hiểu biết của họ như là: Software Tester, Software Quality Assurance Engineer, QA Analyst, etc. Không thể test phần mềm trong bất kỳ thời gian nào của vòng đời SDLC (Software Development Life Cycle). Việc test sẽ được bắt đầu và kết thúc ở 2 giai đoạn như sau

3. Khi nào bắt đầu kiểm thử?

Bắt đầu test sớm sẽ giảm chi phí và thời gian rework cũng như đưa ra những lỗi – free software mà sẽ có thể deliver cho khách hàng. Tuy nhiên, trong vòng đời phát triển phần mềm (SDLC), việc test sẽ được thực hiện từ phase tập hợp yêu cầu và được tiếp tục cho đến khi deploy phần mềm. Nó cũng phụ thuộc vào model phát triển được sử dụng. Ví dụ, ở model Watefall (thác nước) thì hình thức kiểm thử sẽ được thực hiện ở phase testing, nhưng ở model gia tăng thì việc test sẽ được thực hiện ở cuối của mỗi lần tăng/lặp và toàn bộ ứng dụng sẽ được test đến cuối. Việc kiểm thử được thực hiện theo các kiểu khác nhau ở mỗi phase của SDLC:

• Trong phase tập hợp yêu cầu, việc phân tích và xác minh yêu cầu cũng được coi như là kiểm thử.

• Việc review thiết kế ở phase design nhằm tăng chất lượng design cũng được coi như là kiểm thử.

• Việc developer thực hiện test khi hoàn thành code cũng được coi như là kiểm thử.

4. Khi nào dừng kiểm thử?

Thật là khó để quyết định khi nào dừng kiểm bởi kiểm thử là chu trình không bao giờ kết thúc và không ai có thể cam đoan rằng phần mềm đã được kiểm thử 100%. Ở các khía cạnh sau sẽ được coi như là dừng quá trình test:

• Hết deadline test
• Hoàn thành việc test theo testcase
• Hoàn thành chức năng và bao phủ code ở mức độ nhất định
• Tỷ lệ bug thấp hơn mức độ nhất định và không còn bug có độ ưu tiên cao nữa
• Quyết định quản lý

5. Kiểm tra và xác nhận

Rất nhiều người bối rối với hai thuật ngữ này và sử dụng thay thế chúng cho nhau. Trong bảng dưới đây, sẽ chỉ ra những điểm khác biệt giữa kiểm tra và xác nhận.

STT	Kiểm tra (Verification)	Xác nhận (Validation)
1	Kiểm tra giải quyết thắc mắc:”Bạn đang build đúng sản phẩm không?”	Xác nhận giải quyết thắc mắc: “Bạn đang build sản phẩm đúng không?”
2	Đảm bảo hệ thống phần mềm đáp ứng tất cả chức năng.	Đảm bảo rằng tất cả chức năng đáp ứng cơ chế hoạt động đã định.
3	Việc kiểm tra được thực hiện đầu tiên và bao gồm check tài liệu, code, etc.	Việc xác nhận được thực hiện sau khi kiểm tra và chủ yếu liên quan đến check toàn bộ sản phẩm.
4	Do developer thực hiện	Do tester thực hiện
5	Nó bao gồm các hoạt động tĩnh như collect reviews, walkthroughs và xem xét kỹ để kiểm tra phần mềm.	Nó bao gồm các hoạt động động như thực hiện test phần mềm ngược lại với yêu cầu.
6	Đây là một quá trình khách quan và không có quyết định chủ quan được thêm vào để kiểm tra một phần mềm	Đây là một quá trình chủ quân và liên quan đến những quyết định chủ quan xem một phần mềm hoạt động tốt như thế nào.

II. Những lời đồn về kiểm chứng phần mềm

1. Lời đồn 1: Việc kiểm thử quá đắt

Thực tế: Có một câu nói trả ít tiền cho kiểm thử trong suốt quá trình phát triển phần mềm hoặc trả nhiều tiền để maintain hoặc fix lỗi sau đó. Việc tiến hành kiểm thử sớm sẽ tiết kiệm chi phí về thời gian và tiền bạc ở nhiều khía cạnh. Tuy nhiên, giảm thiểu chi phí bằng cách không có kiểm thử sẽ có thể dẫn đến thiết kế không đúng của ứng dụng phần mềm, đưa ra sản phẩm không hữu ích.

2. Lời đồn 2: Việc kiểm thử tiêu tốn thời gian

Thực tế: Trong các phase của SDLC thì việc kiểm thử không bao giờ là quy trình tốn thời gian cả. Tuy nhiên, việc chuẩn đoán và fix lỗi được phát hiện trong quá trình test đúng là tốn thời gian nhưng là hoạt động hữu hiệu.

3. Lời đồn 3: Chỉ có sản phẩm đã phát triển xong mới được kiểm thử

Thực tế: Không nghi ngờ gì việc kiểm thử phải phụ thuộc vào source code nhưng việc review yêu cầu và testcase đã tạo thì không phụ thuộc vào code đã phát triển. Tuy nhiên, việc lặp lại hoặc gia tăng như model vòng đời phát triển có thể giảm sự phụ thuộc của testing vào phần mềm đã phát triển xong.

4. Lời đồn 4: Có thể kiểm thử trọn vẹn

Thực tế: Sẽ là một vấn đề nếu khách hàng hoặc tester nghĩ rằng có thể kiểm thử trọn vẹn. Team có thể test tất cả các hướng nhưng sẽ không bao giờ test hết các trường hợp được. Sẽ có thể có vài trường hợp sẽ không bao giờ được team hay khách hàng kiểm thử trong suốt vòng đời phát triển phần mềm nhưng lại có thể xảy ra dù chỉ một lần ở dự án đã được deploy.

5. Lời đồn 5: Phần mềm đã test thì sẽ không có bug

Thực tế: Đây là một lời đồn đã được rất nhiều khách hàng, người quản lý hệ thống và team lead tin vào. Không ai có thể cam đoan chắc chắn là ứng dụng phần mềm sẽ 100% bug-free cho dù là ứng dụng đã được kiểm thử bởi một tester có kỹ năng test siêu đẳng.

6. Lời đồn 6: Những lỗi bị test thiếu là do lỗi của tester

Thực tế: Thật là không đúng nếu đổ lỗi cho test vì còn bug sau khi đã hoàn thành việc kiểm thử. Lời đồn này liên quan đến Thời gian, Chi phí và Yêu cầu thay đổi giằng buộc. Tuy nhiên, chiến lược test cũng có thể dẫn đến việc team test bỏ qua bug.

7. Lời đồn 7: Tester chịu trách nhiệm về chất lượng sản phẩm

Thực tế: Có một suy nghĩ sai lầm phổ biến là tester là người chịu trách nhiệm về chất lượng sản phẩm. Trách nhiệm của tester bao gồm phát hiện bug cho khách hàng và sau đó khách hàng sẽ quyết định xem sẽ fix bug hay release phần mềm. Việc release phần mềm vào một thời điểm nào đó sẽ đặt nhiều áp lực vào tester cũng như là sẽ đổ lỗi cho tester vì bất kỳ lỗi nào.

8. Lời đồn 8: Việc test tự động nên được dùng bất kỳ khi nào có thể để giảm thời gian

Thực tế: Đúng là test tự động sẽ giảm thời gian test nhưng không thể bắt đầu test tự động bất cứ lúc nào trong khi phát triển phần mềm. Test tự động nên được bắt đầu khi phần mềm đã được test bằng tay rồi và đã ổn định ở một mức nhất định. Ngoài ra, test tự động sẽ không thể sử dụng nếu yêu cầu thay đổi liên tục.

9. Lời đồn 9: Ai cũng có thể kiểm thử phần mềm

Thực tế: Dân ngoài lĩnh vực IT nghĩ rằng thậm chí tin rằng ai cũng có thể kiểm thử một phần mềm và testing không phải là một công việc sáng tạo. Tuy nhiên, tester thì biết chắc chắn rằng đó chỉ là một lời đồn thôi. Tester sẽ nghĩ ra các kịch bản có thể xảy ra, thử phần mềm ở mọi khía cạnh để phát hiện ra những lỗi mà dev không thể nghĩ ra.

10. Lời đồn 10: Tester chỉ có mỗi một việc là tìm bug

Thực tế: Tìm bug ở một phần mềm là task của tester nhưng đồng thời họ cũng là chuyên gia của một phần mềm đặc biệt. Dev thì chỉ có trách nhiệm cho một phần spec được assign nhưng tester thì phải hiểu toàn bộ hoạt động của phần mềm và những mối liên quan rằng buộc là gì, ảnh hưởng của module này lên model khác.

III. QA, QC & Testing

1. Sự khác nhau giữa QA, QC và Testing

Nhiều người bối rối không biết sự khác biệt giữa Quality Assurance (Đảm bảo chất lượng), Quality Control (Quản lý chất lượng) và Testing (Kiểm thử). Chúng có mối quan hệ với nhau và liên quan đến một vài sự mở rộng, chúng có thể coi như là hoạt động giống nhau nhưng vẫn có vài điểm khác biệt giữa chúng. Bảng sau list ra những điểm khác biệt giữa QA, QC và Testing.

Quality Assurance (Đảm bảo chất lượng)	Quality Control (Quản lý chất lượng)	Testing (Kiểm thử)
QA bao gồm các hoạt động đảm bảo việc thực hiện quy trình, trình tự và tiêu chuẩn trong nội dung kiểm tra phần mềm đã phát triển và những yêu cầu được đề ra.	QC bảo gồm các hoạt động để đảm bảo việc kiểm tra một phần mềm đã phát triển đáp ứng những yêu cầu trong tài liệu yêu cầu (hoặc trong vài trường hợp).	Testing bao gồm các hoạt động đảm bảo việc phát hiện ra bug/lỗi/nhầm lẫn trong một phần mềm.
Tập trung vào quy trình và trình tự hơn là quản lý việc test thực tế trên hệ thống.	Tập trung vào việc test thực tế bằng cách thực hiện trên phần mềm nhằm phát hiện ra bug/Lỗi/Nhầm lẫn thông qua việc thực hiện các quá trình và trình tự.	Tập trung vào hoạt động test thực tế.
Các hoạt động có quy trình được định hướng rồi.	Các hoạt động có quy trình được định hướng rồi.	Các hoạt động có quy trình được định hướng rồi.
Các hoạt động có tính chất phòng trừ.	Đây mà một quy trình hiệu chỉnh.	Đây là một quy trình phòng ngừa.
Đây là một tập hợp con của Vòng đời phát triển phần mềm (STLC).	QC có thể coi là một tập hợp con của Quality Assurance (Đảm bảo chất lượng).	Testing là một tập hợp con của Quality Control (Quản lý chất lượng).

2. Audit và Inspection

Audit (Kiểm tra): Đây là một quy trình có hệ thống để quyết định xem quy trình kiểm thử thực tế nên được thực hiện như thế nào trong một tổ chức hoặc một team. Nói chung, đây là một sự kiểm tra độc lập các quy trình liên quan trong suốt quá trình kiểm thử phần mềm. Theo IEEE thì đó là review một quy trình được văn bản hóa mà tổ chức sẽ thực hiện và follow theo. Các loại audit bao gồm Audit theo pháp luật, Audit nội bộ và Audit hệ thống.

Inspection (Xem xét kỹ): Đây là kỹ thuật chính thức liên quan đến việc review kỹ thuật chính thức hoặc không chính thức bất kỳ giả định nào bằng cách nhận dạng lỗi hoặc lỗ hổng nào đó. Theo như IEEE94, xem xét kỹ là một kỹ thuật đánh giá chính thức trong yêu cầu phần mềm, thiết kế hoặc code mà được kiểm tra kỹ bởi một người hoặc một nhóm không phải là tác giá phát hiện ra lỗi, vi phạm tiêu chuẩn phát triển và các vấn đề khác.

Các meeting xem xét kỹ chính thức có thể bao gồm trong chu trình sau: Lên kế hoạch, Chuẩn bị khái quát, Meeting xem xét kỹ, Rework và Follow-up.

3. Testing và Debugging

Testing: Liên quan đến việc phát hiện bug/lỗi/sai lầm trong một phần mềm mà không kèm theo fix nó. Thông thường, chuyên gia với nền tảng đảm bảo chất lượng sẽ liên quan đến việc phát hiện bug. Testing sẽ được thực hiện ở phase kiểm chứng.

Debugging: Liên quan đến việc phát hiện, phân tích và fix vấn đề/bug. Người lập trình viên mà code phần mềm sẽ thực hiện debug trên sự bắt gặp một lỗi trong code. Debug là một phần của White Box Testing hoặc Unit Testing. Debug có thể thực hiện trong giai đoạn phát triển khi thực hiện Unit Testing hoặc ở giai đoạn fix những bug được báo cáo.

IV. Các loại test

Phần này mô tả các loại khác nhau của testing mà có thể được dùng trong kiểm thử một phần mềm trong SDLC.

1. Kiểm thử bằng tay

Kiểm thử bằng tay bao gồm kiểm thử một phần mềm bằng tay mà không sử dụng công cụ tự động hoặc bất kỳ kịch bản nào. Ở loại này, tester sẽ đảm nhận vai trò của một end-user và test phần mềm để tìm ra bất kỳ hoạt động hoặc bug không mong đợi nào. Có các khâu khác nhau để test bằng tay như là Unit Test, Test tích hợp, Test hệ thống và Test chấp thuận user. Tester sẽ sử dụng test plan, testcase hoặc kịch bản test để kiểm thử một phần mềm nhằm đảm bảo tính trọn vẹn của testing. Kiểm thử bằng tay cũng bao gồm testing tìm kiếm như tester khám phá phần mềm để tìm lỗi trong nó.

2. Kiểm thử tự động

Kiểm thử tự động được biết đến là Tự động test sẽ được thực hiện khi tester viết kịch bản và sử dụng phần mềm khác để kiểm thử sản phẩm. Chu trình này liên quan ddeeens tự động của một chu trình bằng tay. Kiểm thử tự động được dùng để chạy lạ một kịch bản test mà được thực hiện bằng tay một cách nhanh chóng và lặp lại. Ngoài test quy hồi, test tự động cũng được dùng để test ứng dụng từ load, tính năng, quan điểm stress. Nó sẽ tăng độ bao phủ test, cải thiện độ chính xác, và tiết kiệm thời gian, tiền bạc so với test bằng tay.

2.1. Tự động là gì?

Sẽ không thể tự động mọi thứ trong một phần mềm. Những khu vực mà một người dùng có thể thực hiện như form login hoặc form đăng ký, bất cứ khu vực nào một số lượng lớn user có thể đồng thời truy cập phần mềm thì nên được thực hiện tự động. Ngoài ra, tất cả item của GUI, mọi kết nối với databases, field validation, etc.. có thể được kiểm thử hiệu quả bằng cách thực hiện quy trình bằng tay.

2.2. Khi nào thực hiện tự động?

Tự động test nên được dùng bằng cách xem xét các khía cạnh sau của một phần mềm:

• Các dự án lớn và tới hạn
• Các dự án yêu cầu kiểm thử các khu vực giống nhau thường xuyên
• Các yêu cầu không thường xuyen thay đổi
• Truy cập ứng dụng để để kiểm tra load và performance với nhiều user ảo.
• Phần mềm ổn định với đáp ứng test bằng tay
• Sẵn sàng bất cứ khi nào

2.3. Thực hiện tự động như thế nào?

Việc thực hiện tự động được thực hiện bằng cách sử dụng ngôn ngữ máy tính hỗ trợ giống như VB scripting và một ứng dụng phần mềm được tự động. Có rất nhiều tool có sẵn mà chúng ta có thể sử dụng để viết script tự động. Trước khi đề cập đến tool, chúng ta hãy nhận biết quy trình mà được sử dụng để thực hiện tự động quy trình test:

• Nhận biết các khu vực trong một phần mềm mà có thể tự động test được
• Chọn tool thích hợp để tự động test
• Viết kịch bản test
• Phát triển bộ test
• Thực hiện kịch bản test
• Tạo báo cáo kết quả
• Nhận biết các bug tiềm tàng hoặc vấn đề về performance (Hiệu suất)

2.4. Các công cụ kiểm thử phần mềm

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

V. Phương thức Test

Có rất nhiều phương thức khác nhau được dùng để kiểm thử phần mềm. Nhưng phần này chỉ đề cập sơ qua một vài phương thức có hiệu quả.

1. Black-Box Testing

Kỹ thuật test mà không cần phải biết về cơ chế làm việc bên trong của ứng dụng được gọi là Black –box testing. Tester không chú ý đến cấu trúc hệ thống và không phải access source code. Nói chung khi thực hiện black-box test thì người tester sẽ tác động qua lại với giao diện người dùng hệ thống bằng cách cho input và kiểm tra output ra mà không cần phải biết input hoạt động như thế nào và ở đâu. Bảng sau liệt kê những ưu điểm và nhược điểm của Black-Box testing.

| Ưu điểm | Nhược điểm | |---------| | Lên kịch bản tốt và có hiệu quả cho những đoạn code lớn. | Mức độ bao phủ có giới hạn vì chỉ một số lượng kịch bản test đã chọn được thực hiện mà thôi. | | Không yêu cầu access code | Việc kiểm thử không hiệu quả bởi tester chỉ có hiểu biết giới hạn về ứng dụng. | | Phân biệt rõ ràng tiến độ của tester và tiến độ của developer thông qua những quy tắc đã được định nghĩa rõ ràng. | Mức độ bao phủ mờ nhạt vì tester không thể đặt mục tiêu vào những đoạn code rõ ràng hoặc các khu vực có khả năng bug cao. | | Một số lượng lớn tester có kỹ năng vừa phải có thể test ứng dụng mà không cần biết gì về coding, ngôn ngữ chương trình hoặc hoạt động của hệ thống. | Rất khó để thiết kế testcase. |

2. White-Box Testing

White-box Testing là điều tra chi tiết logic bên trong và cấu trúc của code. White-box testing cũng được gọi là glass testing hoặc open-box testing. Để thực hiện white-box testing một ứng dụng thì người tester cần phải biết cơ chế làm việc bên trong của code. Tester cần có cái nhìn bên trong source code và tìm ra phần nào của code đang hoạt động không đúng. Bảng sau liệt kê những ưu điểm và nhược điểm của white-box testing.

Ưu điểm	Nhược điểm
•Vì tester biết về source code nên sẽ dễ dàng tìm ra loại data có thể giúp kiểm thử ứng dụng một cách hiệu quả.	•Vì cần tester có kỹ năng thực hiện white-box testing nên chi phí sẽ tăng lên.
•Nó giúp đánh giá một cách lạc quan code.	•Vì có rất nhiều con đường sẽ phải test nhưng đôi khi lại không thể đi sâu vào mọi ngõ ngách để tìm ra các bug tiềm ẩn.
• Có thể bỏ những dòng code thừa mà có nguy cơ mang lại bug tiềm tàng.	•Rất khó để maintain white-box testing bởi vì nó đòi hỏi các công cụ đặc biệt như người phân tích code và công cụ debug.
• Vì tester có hiểu biết về code nên có thể đạt được độ bao phủ lớn nhất khi viết kịch bản test.

3. Grey-Box Testing

Grey-box testing là một kỹ thuật để kiểm thử ứng dụng mà có sự hiểu biết nhất định về hoạt động bên trong của ứng dụng. Trong kiểm thử phần mềm, bạn biết càng nhiều phrase thì càng tốt khi test một ứng dụng. Tester có am hiểu về domain của hệ thống sẽ luôn vượt trội hơn người có sự am hiểu hạn chế về domain. Không giống như black-box testing mà người tester chỉ test giao diện người dùng của ứng dụng, ở grey-box testing, tester sẽ tiếp cận tài liệu thiết kế và database. Có sự hiểu biết này thì tester có thể chuẩn bị data test và kịch bản test tốt hơn khi làm test plan.

Ưu điểm	Nhược điểm
Đưa ra lợi ích kết hợp black-box và white-box testing bất cứ khi nào có thể.	Vì không phải lúc nào cũng access được source code nên có thể sẽ bỏ qua code và độ bao phủ của test bị hạn chế.
Grey box tester không phụ thuộc vào source code mà chỉ phụ thuộc vào định nghĩa giao diện và mô tả chức năng.	Việc test có thể bị thừa nếu người thiết kế phần mềm vừa chạy một testcase.
Dựa vào những hiểu biết nhất định, grey-box tester có thể thiết kế kịch bản test thông minh xung quanh communication protocol và loại data sử dụng.	Việc kiểm thử có thể đi vào một dòng chảy không có thật và làm lãng phí nhiều thời gian. Do đó, nhiều ngả đường trong chương trình sẽ không được kiểm thử.
Việc test được thực hiện theo quan điểm của người dùng chứ không phải quan điểm của người thiết kế.

4. So sánh các phương thức test

Bảng sau list ra các điểm khác nhau giữa black-box testing, grey-box testing và white-box testing.

Black-Box Testing	Grey-Box Testing	White-Box Testing
Không cần biết cơ chế hoạt động bên trong của ứng dụng.	Tester có sự hiểu biết hạn chế về cơ chế hoạt động bên trong của ứng dụng.	Tester phải có sự hiểu biết đầy đủ về cơ chế hoạt động bên trong của ứng dụng.
Cũng được biết đến là closed-box testing, data-driven testing (Test chạy data) hay function testing (Test chức năng).	Cũng được biết đến là translucent testing (Kiểm thử trong mờ) bởi tester có hiểu biết hạn chế về bên trong ứng dụng	Cũng được biết đến là clear-box testing, structural testing (test cấu trúc), hoặc code-based testing (test dựa vào code).
Được thực hiện bởi end-user và tester và developer.	Kiểm thử được thực hiện dựa trên biểu đồ cơ sở dữ liệu mức độ cao và biểu đồ luồng data.	Vì am hiểu sâu sắc cơ chế hoạt động bên trong nên tester có thể thiết kế test data phù hợp.
Thực hiện đầy đủ và tốn ít thời gian.	Tiêu tốn kha khá thời gian và thực hiện đầy đủ.	Loại test tiêu tốn thời gian và thực hiện đầy đủ nhất.
Không thích hợp cho test thuật toán.	Không thích hợp cho test thuật toán.	Thích hợp cho test thuật toán.
Chỉ có thể thực hiện bằng phương pháp trial-and error.	Có thể test data domain và ranh giới bên trong nếu biết.	Có thể test data domain và ranh giới bên trong tốt hơn.

Ngoài các nội dung nói trên, còn có nhiều khái niệm cơ bản khác về kiểm thử phần mềm. Tôi sẽ tiếp tục đề cập về các nội dung đó ở báo cáo tháng tiếp theo.

Link nguồn tham khảo: http://www.tutorialspoint.com/software_testing/software_testing_overview.htm