Chương I: 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).
Trang 1Chương I: 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)
Trang 21.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:
• 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ửachữ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:
o Độ tin cậy
Trang 3khuyế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 địnhviệ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ângâ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ộthợ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
Trang 4• 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
o Xác định đáp ứng yêu cầu quy định
o Chứng minh phù hợp với mục đích
o 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ử
Trang 5• 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
Trang 6Nguyê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ứngminh 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àngsớ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:
1. Nguyên tắc tổ gián: chỗ nào có 1 vài con gián thì ở đâu đó xung quanh nó sẽ
có cả tổ gián -> có rất nhiều gián -> chỗ nào có 1 vài con bug thì xung
quanh, gần gần chỗ đó sẽ có nhiều bug
Trang 72. Nguyên tắc 80/20: thông thường 20% chức năng quan trọng trong một chương trình có thể gây ra đến 80% tổng số bug phát hiện được trong
chương trình đó
3. 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
Trang 8Để 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àodừ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
Trang 9nhữ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ướckhi 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ử
Trang 10Quy 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
Trang 11• 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áckị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ử
• 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ử
Trang 121.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ạchkiể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 :
Trang 13• Đ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 trongcode 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:
o Các kiểm thử được thiết kế bởi những người viết phần mềm
o Các kiểm thử được thiết kế bởi người khác (ví dụ như đội phát triên)
o 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ử
o 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ếptố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:
o Bắt đầu với sự hợp tác thay vì trận chiến
Trang 14o 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.
o 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
Chương 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