Đã đăng vào thg 3 16, 2015 1:02 SA 51 phút đọc

10.8K

Tìm hiểu chương một và chương hai của giáo trình ISTQB_CTFL_Syll 2011

Bài đăng này đã không được cập nhật trong 3 năm

Trong bài viết này mình sẽ tìm hiểu về chương 1- những nguyên tắc cơ bản của kiểm thử (Fundamentals of Testing) và chương 2 - Kiểm thử qua vòng đời phát triển phần mềm ( Testing Throughout the Software LifeCycle) .

Mục đích của bài viết này nhằm tổng hợp các kiến thức cơ bản của chương 1 và 2 để phục vụ cho quá trình ôn thi ISTQB và hiểu rõ hơn những kiến thức của kiểm thử phần mềm.

1. Những nguyên tắc cơ bản của kiểm thử ( Fundamentals of Testing)

Trong phần này chúng ta sẽ tìm hiểu các nguyên tắc cơ bản của kiểm thử :

Tại sao kiểm thử là cần thiết
Định nghĩa kiểm thử
Bẩy nguyên tắc kiểm thử
Quy trình kiểm thử cơ bản
Tâm lý học của kiểm thử

1.1. Tại sao kiểm thử là cần thiết

Trước khi tìm hiểu chi tiết phần này chúng ta cần phải hiểu được các định nghĩa sau:

Bug : Nhìn thấy các khiếm khuyết (defect)
Defect : Một lỗ hổng trong một thành phần hoặc hệ thống khiến các thành phần hoặc hệ thống không thực hiện các chức năng cần thiết.
Error : Do hành động của con người tạo ra kết quả không chính xác
Failure : Sai lệch của thành phần hoặc hệ thống với kết quả mong đợi
Fault : Nhìn thấy kiếm khuyết (defect)
Mistake : Nhìn thấy lỗi (error)
Chất lượng - Quality : Mức độ mà thành phần, hệ thống hoặc quy trình đáp ứng các yêu cầu quy định và nhu cầu , mong đợi của người dùng/ khách hàng.
Rủi ro - Risk :Một yếu tố có thể dẫn đến kết quả tiêu cực trong tương lai thường được biểu hiện như tác động (impact) và khả năng (likelihood).

1.1.1: Phạm vi hệ thống phần mềm

Hệ thống phần mềm là một phần không thể thiếu của cuộc sống, từ các ứng dụng kinh doanh tới các sản phẩm tiêu dùng. Phần mềm không làm việc một cách chính xác có thể dẫn đến nhiều vấn đề bao gồm việc mất tiền, thời gian, uy tín của doanh nghiệp , thậm chí có thể gây ra chấn thương hoặc tử vong.

1.1.2: Nguyên nhân của những khiếm khuyết phần mềm

Con người có thể làm ra lỗi(error - mistake) , tạo ra một khiếm khuyết trong mã chương trình hoặc trong tài liệu. Khiếm khuyết trong phần mềm, hê thống hoặc tài liệu có thể dẫn đến thất bại, nhưng không phải tất cả các khiếm khuyết đều như vậy.
Nguyên nhân con người tạo ra các khiếm khuyết:

Áp lực thời gian
Các đoạn mã(code) phức tạp
Sự phức tạp của cơ sở hạ tầng
Công nghệ thay đổi
Có nhiều tương tác hệ thống

Thất bại có thể được gây ra bởi điều kiện môi trường

1.1.3: Vai trò của kiểm thử trong phát triển phần mềm, bảo trì và vận hành

Kiểm thử nghiêm ngặt hệ thống và tài liệu, tìm thấy các khiếm khuyết và sửa chữa chúng trước khi phát hành để sử dụng sẽ giúp làm giảm rủi ro của các vấn đề xảy ra trong quá trình vận hành và nâng cao chất lượng của hệ thống phần mềm.

1.1.4: Kiểm thử và chất lượng

Kiểm thử có thể đo lường chất lượng của phần mềm về các khiếm khuyết được tìm thấy (cả yêu cầu phần mềm chức năng và phi chức năng) và cả các đặc tính:

Độ tin cậy
Khả năng sử dụng
Hiệu quả
Bảo trì
Tính di động

Kiểm thử tạo niềm tin vào chất lượng của phần mềm nếu tìm thấy rất ít hoặc không có lỗi.
Cải thiện chất lượng của hệ thống trong tương lai bằng cách rút ra những bài học từ những dự án trước. Hiểu được nguyên nhân gốc của các khiếm khuyết được tìm thấy trong dự án.
Kiểm thử là một trong những hoạt động đảm bảo chất lượng.

1.1.5: Bao nhiêu kiểm thử là đủ?

Bao nhiêu kiểm thử là đủ nên dựa vào mức độ rủi ro, bao gồm rủi ro về kinh doanh, bảo mật, kỹ thuật và những hạn chế của dự án như là thời gian và ngân sách.
Kiểm thử nên cung cấp đầy đủ thông tin cho các bên liên quan để quyết định việc phát hành phần mềm hoặc hệ thống sau khi đã được kiểm thử.

1.2. Kiểm thử là gì?

Trong phần này chúng ta cần hiểu một số các định nghĩ sau :

Gỡ lỗi - Debugging : Quá trình tìm , phân tích và loại bỏ những nguyên nhân gây thất bại trong phần mềm.
Yêu cầu - Requirement: Một điều kiện cần thiết để người phát triển giải quyết một vấn đề hoặc đạt được mục tiêu phải được đáp ứng để đáp ứng một hợp đồng, tiêu chuẩn, đặc điểm kỹ thuật.
Đánh giá - Review: Đánh giá tình trạng của sản phẩm hoặc dự án để xác định sự khác biệt từ kế quả dự định và đề nghị cải tiến. Bao gồm đánh giá quản lý, đánh giá thông tin, đánh giá kỹ thuật, kiểm tra (inspection) và walkthrough.
Trường hợp kiểm thử - Test case: Một tập giá trị đầu vào, thực hiện điều kiện tiên quyết, kết quả mong đợi, phát triển cho một mục tiêu cụ thể hoặc điều kiện kiểm thử.
Kiểm thử -Testing : Quá trình bao gồm tất cả các vòng đời của hoạt động, bao gồm cả kiểm thử tĩnh và kiểm thử động, liên quan đến việc lập kế hoạch, chuẩn bị và đánh giá các hoạt động phần mềm và các sản phẩm để xác định đáp ứng yêu cầu quy định, chứng minh rằng phù hợp với mục đích và để phát hiện các khuyết tật.
Mục tiêu kiểm thử - Test objective: : Lý do hoặc mục đích cho việc thiết kế và thực hiển kiểm thử.

**Định nghĩa **:

Kiểm thử là quá trình bao gồm:

Lập kế hoạch, chuẩn bị và đánh giá các hoạt động phần mềm và các sản phẩm.
Kiểm thử tĩnh và kiểm thử động

Xác định đáp ứng yêu cầu quy định.
Chứng minh phù hợp với mục đích.
Phát hiện các khiếm khuyết.

Hoạt động kiểm thử tồn tại trước và sau khi thực hiện kiểm thử, bao gồm các hoạt động sau:

Lập kế hoạch và kiểm soát
Lựa chọn các điều kiện kiểm thử
Thiết kế và thực hiện các trường hợp kiểm thử
Kiểm tra kết quả
Đánh giá tiêu chuẩn hoàn thành
Báo cáo về quá trình kiểm thử và hệ thống sau khi đã kiểm thử
Hoàn thành các hoạt động kiểm kết thúc kiểm thử sau một giai đoạn kiểm thử đã hoàn thành
Đánh giá tài liệu ( bao gồm cả mã nguồn(souce code)
Phân tích tĩnh

Kiểm thử có các mục tiêu sau:

Tìm các khiếm khuyết(defects).
Đạt được sự tin tưởng về chất lượng
Cung cấp các thông tin để đưa ra quyết định
Ngăn ngừa các khiếm khuyết

Mục tiêu của kiểm thử trong các giai đoạn khác nhau

Phát triển kiểm thử: Các khiếm khuyết được xác định và có thể được sửa chữa
Kiểm thử chấp nhận: Xác nhận hệ thống hoạt động như mong đợi và đạt được sự tin tưởng, phần mềm đã đáp ứng được yêu cầu.
Bảo trì : Đảm bảo không xuất hiện các khiếm khuyết mới khi thay đổi phần mềm.
Vận hành: Đánh giá các đặc điểm của hệ thống như độ tin cậy và tính sẵn có.

1.3. Bẩy nguyên tắc kiểm thử

Trong phần này chúng ta có định nghĩa sau:

Kiểm thử toàn bộ - exhaustive testing : Một phương pháp tiếp cận kiểm thử trong đó các bộ kiểm thử chứa tất cả các kết hợp của các giá trị đầu vào và điều kiện tiên quyết.

Nguyên tắc 1: Kiểm thử cho thấy sự hiện diện của các khiếm khuyết

Kiểm thử có thể cho thấy sự có mặt của các khiếm khuyết, nhưng không thể chứng minh phần mềm không có khiếm khuyết. Kiểm thử giảm xác suất của các khiếm khuyết chưa được tìm thấy vẫn còn trong phần mềm.

Nguyên tắc 2: Kiểm thử toàn bộ là không thể

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

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

Để tìm được các khiếm khuyết sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm hoặc hệ thống.

Nguyên tắc 4 – Sự tập trung của lỗi

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

Để hiểu rõ hơn nguyên tắc này, ta cần xem xét 3 điều sau:

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

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

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

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

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

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

Nguyên tắc này là việc kiểm thử phụ thuộc vào ngữ cảnh, kiểm thử trong nhiều ngữ cảnh khác nhau.

Để hiểu rõ hơn chúng ta xem ví dụ sau:

Ví dụ, cũng với một chương trình calculator có rất nhiều chức năng, nhưng:

Nếu test chương trình này cho mẫu giáo thì chỉ cần test cộng trừ là OK
Nếu test chương trình này cho cấp 2 thì cộng trừ nhân chia
Nếu test chương trình này cho đại học thì tích phân, đạo hàm, v.v....

**Nguyên tắc 7 – Sự sai lầm về việc không có lỗi **

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

1.4. Quy trình kiểm thử cơ bản

Các định nghĩa :

Kiểm thử xác nhận - Confirmation testing : Xem lại kiểm thử .
Kiểm thử lại - Re-testing : Kiểm thử chạy các trường hợp kiểm thử (test cases) đã thất bại để xác nhận thành công của các hoạt động khắc phục lỗi.
Tiêu chí hoàn thành - Exit criteria : Thiết lập các điều kiện chung và cụ thể , được thỏa thuận với các bên liên quan, cho phép một quá trình được hoàn thành. Tiêu chí hoàn thành được sử dụng để lập báo cáo và kế hoạch khi nào dừng kiểm thử.
Kiểm thử hồi quy - Regression testing : Kiểm thử một chương trình đã được kiểm thử trước đó, để đảm bảo không có khiếm khuyết (lỗi) xuất hiện trong những phần thay đổi của phần mềm. Kiểm thử hồi quy được thực hiện khi phần mềm hoặc môi trường thay đổi.
Cơ sở kiểm thử - Test basis : Tất cả các tài liệu mà từ đó yêu cầu của một thành phần hoặc hệ thống được suy ra. Các trường hợp kiểm thử(test cases) được dựa trên các tài liệu này.
Kiểm tra điều kiện - Test condition : Một mục hoặc sự kiện của một thành phần hoặc hệ thống có thể được xác nhận bằng một hoặc nhiều test cases.
Kiểm tra dữ liệu - Test data : Dữ liệu đang tồn tại (trong cơ sở dữ liệu) trước khi một thử nghiệm được thực thi, dữ liệu có ảnh hưởng hoặc bị ảnh hưởng bởi thành phần hoặc hệ thống trong khi thử nghiệm.
Thực hiện kiểm tra -Test execution: Các quá trình chạy một thử nghiệm trên các thành phần hoặc hệ thống, tạo ra kết quả thực tế.
Kiểm tra log - Test log : Một bản ghi lịch sử của các chi tiết liên quan đến việc thực hiện các thử nghiệm.
Kế hoạch kiểm tra -Test plan : Một tài liệu mô tả phạm vi , phương pháp, nguồn lực và tiến độ của các hoạt động thử nghiệm dự định. Xác định các mục kiểm tra, các tính năng sẽ được kiểm tra, nhiệm vụ kiểm thử, xác định người làm các nhiệm vụ, mức độ độc lập của người kiểm thử , môi trường thử nghiệm, các kỹ thuật thiết kế thử nghiệm, lý do của sự lựạ chọn , kế hoạch dự phòng của bất kỳ rủi ro nào.
Chính sách kiểm tra - Test policy : Tài liệu mức độ cao mô tả các nguyên tắc, phương pháp và mục tiêu chính của tổ chức về kiểm thử.
Bộ kiểm tra -Test suite : Một tập hợp của nhiều trường hợp kiểm thử cho một thành phần hoặc hệ thống trong kiểm thử.
Tóm tắt báo cáo kiểm tra -Test summary report : Một tài liệu tổng kết các hoạt động kiểm thử và kết quả.
Testware : Hiện vật được tạo ra trong quá trình thử nghiệm để lập kế hoạch, thiết kế và thực hiện kiểm tra như là tài liệu , kịch bản, đầu vào, kết quả mong đợi, các tập tin, cơ sở dữ liệu, môi trường và bất kỳ phần mềm bổ sung hoặc trình tiện ích được sử dụng trong kiểm thử.

Quy trình kiểm thử cơ bản bao gồm các hoạt động chính sau:

1.4.1: Lập kế hoạch và giám sát - Test Planning and Control

Kế hoạch kiểm thử là hoạt động xác định các mục tiêu của kiểm thử và các đặc điểm kỹ thuật của các hoạt động kiểm thử để đáp ứng các mục tiêu và nhiệm vụ.
Giám sát kiểm thử là hoạt động liên tục so sánh tiến độ thực tế với kế hoạch và báo cáo tình trạng, bao gồm cả sai lệch so với kế hoạch. Các hoạt động kiểm thử nên được theo dõi trong suốt dự án.

1.4.2: Phân tích và thiết kế -Test Analysis and Design

Là hoạt động mà trong đó các mục tiêu kiểm thử được chuyển thành các điều kiện kiểm thử và các trường hợp kiểm thử.
Hoạt động phân tích và thiết kế có các nhiệm vụ chủ yếu sau:

Xem xét các kiểm thử cơ bản(như là yêu cầu,mức độ rủi ro, phân tích báo cáo rủi ro, kiến trúc , thiết kế và đặc tả giao diện).
Đánh giá mức độ khả dụng của cơ sở kiểm thử và đối tượng kiểm thử.
Xác định độ ưu tiên của các điều kiện kiểm thử dựa trên việc phân tích các đặc điểm kỹ thuật, hành vi và cấu trúc của phần mềm.
Thiết kế và đánh giá các trường hợp kiểm thử có mức độ ưu tiên cao.
Xác định các dữ liệu kiểm thử cần thiết
Thiết kế và cài đặt môi trường kiểm thử , xác định cơ sở hạ tầng và các công cụ cần thiết.
Tạo ra định hướng truy tìm nguồn gốc giữ cơ sở kiểm thử và các trường hợp kiểm thử.

1.4.3: Thực hiện và thực thi - Test Implementation and Execution

Là hoạt động mà các thủ tục kiểm tra hoặc các kịch bản được đặc tả bằng sự kết hợp các trường hợp kiểm thử theo một thứ tự cụ thể và bao gồm các thông tin cần thiết cho việc thực thi kiểm thử, môi trường được thiết lập và kiểm thử được chạy.
Thực hiện và thực thi có nhiệm vụ chủ yếu dưới đây:

Hoàn thiện , thực hiện và đánh giá độ ưu tiên các trường hợp kiểm thử(bao gồm việc xác định dữ liệu kiểm thử).
Phát triển và đánh giá độ ưu tiên các thủ tục kiểm thử, tạo dữ liệu kiểm thử, tùy chọn(optionally), chuẩn bị khai thác kiểm thử (test harnesses) và viết các kịch bản kiểm thử tự động.
Tạo bộ kiểm thử từ những thủ tục kiểm thử để thực thi kiểm thử một cách hiệu quả.
Xác nhận môi trường kiểm thử đã được thiết lập chính xác
Xác nhận và cập nhật định hướng truy xuất nguồn gốc giữa cơ sở kiểm thử và các trường hợp kiểm thử .
Thực thi các thủ tục kiểm thử bằng tay hoặc bằng cách sử dụng các công cụ kiểm thử tự động.
Đưa ra các kết quả của việc thực thi test, ghi lại danh tính và các phiên bản của phần mềm, các công cụ kiểm thử và testware.
So sánh kết quả thực tế và kết quả mong đợi.
Báo cáo sự khác biệt và phân tích chúng để tìm ra nguyên nhân gây lỗi (ví dụ : lỗi trong code, dữ liệu đặc tả, tài liệu test, hoặc mistake trong khi kiểm thử được thực thi).
Lặp đi lặp lại các hoạt động kiểm thử

1.4.4: Đánh giá tiêu chí hoàn thành và báo cáo - Evaluating Exit Criteria and Reporting

Là hoạt động mà các hoạt động thực thi kiểm tra được đánh giá dựa trên các mục tiêu xác định. Nên được thực hiện đối với từng mức độ test.
Đánh giá tiêu chí hoàn thành có các nhiệm vụ chủ yếu sau:

Kiểm tra các test log đối với các tiêu chí hoàn thành quy định trong kế hoạch kiểm tra.
Đánh giá nếu test nhiều hơn cần thiết hoặc nếu các tiêu chuẩn hoàn thành nên được thay đổi.
Viết báo cáo tóm tắt test cho các bên liên quan .

1.4.5: Các hoạt động kết thúc kiểm thử - Test Closure Activities

Hoạt động kết thúc kiểm thử thu thập dữ liệu từ các hoạt động hoàn thành kiểm thử để củng cố kinh nghiệm , testware, các sự việc và các con số. Hoạt động đóng kiểm thử xảy ra tại các cột mốc của dự án như là khi phần mềm được phát hành, dự án kiểm thử đã hoàn thành hoặc bị hủy bỏ, một cột mốc đã đạt được, hoặc một phát hành bảo trì đã được hoàn thành.
Hoạt động kết thúc kiểm thử bao gồm các hoạt động chủ yếu sau:

Kiểm tra kế hoạch giao sản phẩm đã được chuyển giao.
Đóng các báo cáo sự cố hoặc nâng cao các bản ghi thay đổi cho bất kỳ những cái còn lại vẫn mở.
Lập tài liệu chấp nhận của hệ thống.
Hoàn thành và lưu trữ testware, môi trường kiểm thử và cơ sở hạ tầng kiểm thử.
Bàn giao testware cho bộ phận bảo trì.
Phân tích bài học kinh nghiệm để xác định những thay đổi cần thiết cho bản phát hành và các dự án trong tương lai.
Sử dụng thông tin thu thập để cải thiện kiểm thử.

1.5. Tâm lý học của kiểm thử - The Psychology of Testing

Trong phần này có các định nghĩa sau :

Đoán lỗi - Error guessing: Một kỹ thuật thiết kế kiểm thử mà các kinh nghiệm của tester được sử dụng để dự đoán những lỗi có thể xuất hiện trong thành phần hoặc hệ thống trong khi test.
Tính độc lập -Independence: Sự phân chia trách nhiệm khuyến khích hoàn thành mục tiêu kiểm thử.
Với suy nghĩ đúng đắn developers có thể kiểm tra và tìm thấy nhiều lỗi trong code của họ nhưng một mức độ nhất định của tính độc lập thường làm cho các tester có nhiều hiệu quả hơn trong việc tìm kiếm các lỗi và các thất bại.
Một số cấp độ của tính độc lập được định nghĩa từ thấp đến cao như dưới đây:

Các kiểm thử được thiết kế bởi những người viết phần mềm
Các kiểm thử được thiết kế bởi người khác (ví dụ như đội phát triên).
Các kiểm thử được thiết kế bởi người từ một nhóm tổ chức khác nhau hoặc chuyên gia kiểm thử.
Các kiểm thử được thiết kế bởi người từ một tổ chức hoặc công ty khác nhau.

Tìm kiếm những thất bại trong hệ thống đòi hỏi sự tò mò, tính bi quan chuyên nghiệp, một đôi mắt hay bình phẩm, chú ý đến từng chi tiết, giao tiếp tốt với các đồng nghiệp trong đội phát triển, kinh nghiệm với kỹ thuật đoán lỗi.
Những lỗi hoặc thất bại được truyền đạt một cách xây dựng có thể tránh được cảm giác tồi tệ giữa tester và các nhà phân tích, người thiết kế và các nhà phát triển.
Test leader và tester cần có kỹ năng giao tiếp tốt để truyền đạt thông tin thực tế về lỗi, tiến độ và rủi ro. Đối với tác giả của phần mềm hoặc tài liệu, thông tin về lỗi có thể giúp họ cải thiện kỹ năng. Lỗi được tìm thấy và sửa chữa trong thời gian kiểm thử sẽ tiết kiệm thời gian , tiền bạc và giảm thiểu rủi ro.
Một số cách để cải thiện giao tiếp và các mối quan hệ giữa tester và những người khác:

Bắt đầu với sự hợp tác thay vì trận chiến
Tuyền đạt phát hiện lỗi trên sản phẩm một cách trung lập, không chỉ trích người đã tạo ra lỗi.
Cố gắng hiểu người khác cảm thấy thế nào và lý do tại sao họ phản ứng như vậy.

+Xác nhận với người kia đã hiểu những gì bạn nói và ngược lại.

2. Kiểm thử thông qua vòng đời phát triển phần mềm - Testing Throughout the Software Life cycle

Trong chương này chúng ta sẽ tìm hiểu các mục sau:

Các mô hình phát triển phần mềm - SoftwareDevelopmentModels (K2)
Các mức độ test - TestLevels
Các loại test - TestTypes
Kiểm thử bảo trì - Maintenance Testing

2.1 : Các mô hình phát triển phần mềm

Trong phần này có các định nghĩa sau:

Xác nhận hợp lệ - Validation : Xác nhận bằng cách kiểm tra và thông qua việc cung cấp các bằng chứng khách quan rằng các yêu cầu cho mục địch sử dụng cụ thể hoặc ứng dựng đã được hoàn thành.
Xác minh - Verification : Xác nhận bằng cách kiểm tra và thông qua việc cung cấp các bằng chứng khách quan rằng các yêu cầu quy định đã được hoàn thành.

2.1.1 : V-model ( mô hình phát triển tuần tự) - V-model (Sequential Development Model)

V-model là một framework để mô tả các hoạt động vòng đời phát triển phần mềm từ các yêu cầu đặc tả để bảo trì. V- model mô tả làm thế nào các hoạt động kiểm thử có thể tích hợp vào từng giao đoạn của vòng đời phát triển phần mềm.

Bốn mức độ kiểm thử được sử dụng trong V-model:

Kiểm thử thành phần( đơn vị)
Kiểm thử tích hợp
Kiểm thử hệ thống
Kiểm thử chấp nhận

Bắt đầu sớm nhất có thể
Thực hiện trước khi kết thúc một giai đoạn coding
Thực hiện song song
Các lỗi thường được tìm thấy trong các tài liệu, cơ sở kiểm thử(test basis).

Trong thực tế V-model có thể có nhiều hơn , ít hơn các mức độ khác nhau của phát triển và kiểm thử , tùy thuộc vào các dự án và sản phẩm phần mềm.

Ưu điểm.

Đơn giản dễ sử dụng.
Có hoạt động, kế hoạch cụ thể cho quá trình test.
Tiết kiệm được thời gian, và có cơ hội thành công cao hơn waterfall.
Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu.

Nhược điểm.

Độ linh hoạt ít và còn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau mỗi step thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức tạp và dễ hiểu, thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian.
Giống với waterfall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu. Không đáp ứng được yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm.
Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, update lại tài liệu.

Áp dụng cho những dự án như thế nào.

Dự án có kích thước nhỏ, và trung bình, các yêu cầu dự án là rõ ràng, cố định.
Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn có để đảm bảo được yêu cầu, đọc nhanh, test nhanh và coding nhanh.
Nếu khách hàng có sự tự tin cao trong yêu cầu thiết kế (nghĩa là ít thay đổi, ít dao động) thì V model là lựa chọn cần thiết.

2.1.2: Mô hình phát triển Iterative-incremental

Mô hình phát triển Iterative-incremental là quá trình xây dựng các yêu cầu, thiết kế, xậy dựng và kiểm thử một hệ thống trong một loạt các chu kỳ phát triển ngắn.

Ví dụ như : nguyên mẫu (prototyping), Phát triển ứng dụng nhanh (RAD), Rational Unified Process (RUP) và mô hình phát triển agile.

Phân chia thành số gia (increments ) hoặc xây dựng (builds).
Các số gia ban đầu sẽ có các cơ sở hạ tầng cần thiết
Các số gia có thể được kiểm thử với nhiều mức trong mỗi lần lặp.
Các công việc thực hiện với số gia tiếp theo (Subsequent increments):

Kiểm thử các chức năng mới
Kiểm thử hồi quy các chức năng hiện có
Kiểm thử tích hợp cả phần mới và phần cũ

Xác minh và xác nhận hợp lệ có thể được thực hiện trong mỗi số gia.

Ưu điểm:

Sớm cung cấp ra thị trường
Đơn giản để quản lý
Giảm đầu tư ban đầu
Nhận được thông tin phản hồi sớm

2.1.3 ; Kiểm thử trong mô hình vòng đời - Testing within a Life Cycle Model

Trong bất kỳ mô hình vòng đời, có một số đặc điểm của kiểm thử tốt như dưới đây:

Mỗi hoạt động phát triển có một hoạt động kiểm thử tương ứng.
Mỗi cấp độ kiểm thử có mục tiêu kiểm thử cụ thể
Phân tích và thiết kế kiểm thử cho một mức độ kiểm thử nên bắt đầu trong các hoạt động phát triển tương ứng.
Tester nên tham gia vào việc xem xét các tài liệu ngay sau khi có tài liệu trong vòng đời phát triển phần mềm.

2.2: Các mức kiểm thử - Test levels

Trong phần này có các định nghĩa sau:

Alpha testing : Mô phỏng hoặc kiểm thử hoạt động thực tế của người dùng/ khách hàng hoặc một đội kiểm thử độc lập tại trang web của nhà phát triển, nhưng bên ngoài đội phát triển.
Beta testing : Kiểm thử hoạt động của người dùng hiện tại/ khách hàng tại một trang web bên ngoài không tham gia với những người phát triển. để xác định có hay không một thành phần hoặc hệ thống đáp ứng các nhu cầu của khách hàng và phù hợp với quy trình nghiệp vụ. Beta testing thường được sử dụng như một hình thức của kiểm thử chấp nhận bên ngoài cho phần mềm off-the-shelf để có được những phản hồi từ thị trường.
Kiểm thử thành phần - Component testing : Kiểm thử các thành phần phần mềm riêng lẻ.
Driver : Một thành phần phần mềm hoặc công cụ kiểm thử thay thế một thành phần giám sát hoặc gội đến một thành phần hoặc hệ thống.
Yêu cầu chức năng - Functional requirement : Một yêu cầu mà chỉ định một chức năng mà một thành phần hoặc hệ thống phải thực hiện.
Tích hợp - Integration : Quá trình kết hợp các thành phần hoặc các hệ thống vào tập hợp lớn hơn.
Kiểm thử tích hợp - Integration testing : Thực hiện kiểm thử để chỉ ra những lỗi trong giao diện và trong sự tương tác giữa các thành phần tích hợp hoặc hệ thống.
Yêu cầu phi chức năng - Non-functional requirement : Yêu cầu không liên quan đến chức năng nhưng liên quan đến các thuộc tính như độ tin cậy, tính hiệu quả, tính sử dụng , bảo trì và tính di động.
Kiểm thử độ bền - Robustness testing : Kiểm thử xác định độ bền của các sản phẩm phần mềm.
Stub : Thực hiện mục đích đặc biệt của một thành phần phần mềm, được sử dụng để phát triển hoặc thử nghiệm một thành phần mà gọi đến mục đích hoặc có thể bị phụ thuộc vào nó. Nó thay thế cho một thành phần được gọi.
Kiểm thử hệ thống - System testing : Quá trình kiểm thử một hệ thống tích hợp để xác định rằng đáp ứng các yêu cầu quy định.
Kiểm thử môi trường -Test environment : Một môi trường có chứa phần cứng, thiết bị đo, thiết bị mô phỏng , các công cụ phần mềm, và các thành phần hỗ trợ khác cần để tiến hành kiểm thử.
Mức độ kiểm thử - Test level : Một nhóm các hoạt động kiểm thử được tổ chức và quản lý với nhau.Một mức độ kiểm thử có liên quan đến trách nhiệm trong một dự án.
Phát triển định hướng kiểm thử - Test-driven development : Một cách phát triển phần mềm mà các test cases được phát triển và thường tự động hóa trước khi phần mềm được phát triển để chạy các test case .

2.2.1 : Kiểm thử thành phần - Component Testing

Cơ sở kiểm thử :

Các yêu cầu thành phần
Thiết kế chi tiết
Code

Đối tượng kiểm thử

Các thành phần
Chương trình
Chuyển đổi dữ liệu , thay đổi chương trình
Mô hình cơ sở dữ liệu

Kiểm thử thành phần ( còn gọi là kiểm thử đơn vị, mô-đun, chương trình) tìm kiếm các lỗi và kiểm tra các chức năng, module phần mềm, chương trình, đối tượng, các lớp(class)... Nó có thể được thực hiện biệt lập với phần còn lại của hệ thống, phụ thuộc vào vòng đời phát triển và hệ thống . Sơ khai (stubs), trình điều khiển, trình mô phỏng có thể được sử dụng
Kiểm thử thành phần bao gồm :

Kiểm thử chức năng và kiểm thử phi chức năng như là vận hành tài nguyên (tìm kiếm lỗ hổng bộ nhớ) hoặc kiểm thử độ bền , kiểm thử cấu trúc ( như bao phủ quyết định).
Các trường hợp kiểm thử bắt nguồn từ các sản phẩm công việc như là đặc điểm kỹ thuật của thành phần, thiết kế phần mềm hoặc các mô hình dữ liệu .

Kiểm thử thành phần thực hiện khi truy cập vào code . Người thực hiện kiểm thử là lập trình viên viết code.
Phương pháp tiếp cận kiểm thử thành phần là chuẩn bị và tự động hóa các trường hợp kiểm thử trước khi coding.

2.2.2 : Kiểm thử tích hợp - Integration Testing

Cơ sở kiểm thử :

Thiết kế hệ thống và phần mềm
Kiến trúc
Luồng công việc
Các trường hợp sử dụng

Đối tượng kiểm thử

Các hệ thống con
Cơ sở dữ liệu
Cơ sở hạ tầng
Giao diện
Cấu hình hệ thống và cấu hình dữ liệu

Kiểm thử tích hợp kiểm tra các giao diện giữa các thành phần, tương tác với các phần khác nhau của một hệ thống như là hệ điều hành, hệ thống file, phần cứng và các giao diện giữa các hệ thống.
Có nhiều hơn một mức độ kiểm thử tích hợp và nó có thể thực hiện trên các đối tượng của các quy mô khác nhau như sau:

Kiểm thử tích hợp thành phần, kiểm tra sự tương tác giữa các thành phần phần mềm và được thực hiện sau kiểm thử thành phần
Kiểm thử tích hợp hệ thống, kiểm tra sự tương tác giữa các hệ thống khác nhau hoặc giữa phần cứng và phần mềm . Được thực hiện sau kiểm thử hệ thống.

Kiểm thử tích hợp dựa trên kiến trúc hệ thống ( như là top-down và bottom-up), các nhiệm vụ chức năng, trình tự xử lý giao dịch hoặc một vài khía cạnh của hệ thống hoặc các phần mềm. Để dễ dàng sữa lỗi và phát hiện lỗi sớm phương pháp kiểm thử tích hợp thường được dùng là “big bang”.
Kiểm thử tích hợp có thể bao gồm kiểm thử phi chức năng (như kiểm thử hiệu suất).
Tester sẽ là người thực hiện kiểm thử tích hợp. Cả hai phương pháp tiếp cận chức năng ( functional) và cấu trúc (structural) sẽ được sử dụng.
Kiểm thử tích hợp được lên kế hoạch trước khi các thành phần và hệ thống được xây dựng.

2.2.3: Kiểm thử hệ thống - System Testing

Cơ sở kiểm thử

Yêu cầu đặc tả của phần mềm và hệ thống
Các trường hợp sử dụng
Đặc tả chức năng
Báo cáo phân tích rủi ro

Đối tượng kiểm thử

Hệ thống, người sử dụng, hướng dẫn hoạt động
Cấu hình hệ thống và cấu hình dữ liệu

Kiểm thử hệ thống có liên quan với các hành vi của cả hệ thống/sản phẩm.
Trong kiểm thử hệ thống, môi trường kiểm thử phải tưng ứng với các mục tiêu hoặc môi trường sản xuất để giảm thiểu các rủi ro của các sự cố môi trường không được tìm thấy trong kiểm thử.
Kiểm thử hệ thống bao gồm các kiểm tra dựa trên các rủi ro hoặc yêu cầu đặc tả, quy trình nghiệp vụ, các trường hợp sửa dụng, các mô hình hành vi của hệ thống, tương tác với các hệ điều hành và tài nguyên hệ thống.
Kiểm thử hệ thống kiểm tra các yêu cầu chức năng và phi chức năng và các đặc tính chất lượng dữ liệu. Kiểm thử chức năng sử dụng kỹ thuật kiểm thử hộp đen . Kiểm thử phi chức năng sử dụng các kỹ thuật kiểm thử hộp trắng.
Một đội kiểm thử độc lập thường thực hiện kiểm thử hệ thống .

2.2.4 : Kiểm thử chấp nhận - Acceptance Testing

Cơ sở kiểm thử

Các yêu cầu người dùng
Các yêu cầu hệ thống
Các trường hợp sử dụng
Quy trình nghiệp vụ
Báo cáo phân tích rủi ro

Đối tượng kiểm thử

Các quy trình nghiệm vụ trên hệ thống được tích hợp đầy đủ
Quá trình vận hành và bảo trì
Các dạng(forms)
Báo cáo
Cấu hình dữ liệu

Kiểm thử chấp nhận thường được thực hiện bởi khách hàng, người sử dụng hệ thống và các bên liên quan khác .
Mục đích của kiểm thử chấp nhận là để tạo niềm tin vào hệ thống, các bộ phận của hệ thống hoặc các đặc tính phi chức năng của hệ thống. Tìm các lỗi không phải là trọng tâm chính của kiểm thử chấp nhận . Kiểm thử chấp nhận không nhất thiết phải là mức cuối cùng của kiểm thử.
Kiểm thử chấp nhận có thể xảy ra vào các thời điểm khác nhau trong vòng đời phát triển phần mềm, ví dụ :

Một sản phẩm phần mềm COTS có thể được kiểm thử chấp nhận khi đã cài đặt hoặc tích hợp.
Kiểm thử chấp nhận kiểm tra tính tiện ích của một thành phần có thể được thực hiện trong kiểm thử đơn vị
Kiểm thử nâng cấp một chức năng mới có thể được thực hiện trước kiểm thử hệ thống

Kiểm thử chấp nhận bao gồm các hình thức dưới đây:

Người dùng kiểm thử chấp nhận

Xác nhận sự phù hợp cho việc sự dụng của hệ thống bởi người dùng

Vận hành kiểm thử

Sự chấp nhận của hệ thống bởi các quản trị viên hệ thống , bao gồm:

Kiểm thử sao lưu và phục hồi
Khắc phục thảm họa
Quản lý người dùng
Các nhiệm vụ bảo trì
Tải dữ liệu và các nhiệm vụ chuyển đổi
Kiểm tra định kỳ các lỗ hổng bảo mật

Hợp đồng và quy chế kiểm thử chấp nhận

Hợp đồng kiểm thử chấp nhận được thực hiện theo tiêu chí chấp nhận của hợp đồng. Tiêu chí chấp nhận phải được xác định bởi các bên thỏa thuận hợp đồng. Quy chế kiểm thử chấp nhận được thực hiện phải được tôn trọng như các quy định của chính phủ.

Kiểm thử Alpha và beta (or field)

Trên đây là một số tìm hiểu về chương 1 và một nửa chương 2 trong giáo trình ISTQB_CTFL_Syll 2011. Trong bài tiếp theo em sẽ tiếp tục tìm hiểu chương 2 và chương 3 của giáo trình.

Testing

Mục lục