CHƯƠNG 3: THỰC HIỆN KIỂM THỬ HỆ THỐNG VỚI MANUAL TESTING
3.2. Thực thi kiểm thử
Để thực hiện kiểm thử đạt hiệu quả cao, tester cần hiểu rõ các 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 khi đượ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à những định nghĩa về defect. Việc nắm rõ những 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ể.
3.2.1.1. Review tài liệu đặc tả
Tài liệu đặc tả là một tài liệu được tạo bởi đội phát triển cùng với sự hợp tác của đội phân tích nghiệp vụ và đội môi trường/dữ liệu. Thông thường, tài liệu này sau khi được hoàn thành sẽ chia sẻ với đội đảm bảo chất lượng thông qua một cuộc họp nơi mà định hướng chi tiết đã được sắp xếp. Đôi khi, đối với một ứng dụng đã tồn tại, chúng ta có thể không cần đến một cuộc họp chính thức và chỉ cần có người hướng dẫn cho chúng ta thông qua tài liệu này. Từ đó chúng ta có thể có những thông tin cần thiết để làm điều này bởi chính mình.
3.2.1.2. Từng bước để review tài liệu đặc tả yêu cầu của phần mềm Step #1: Tài liệu qua nhiều lần sửa đổi, do đó hãy chắc chắn rằng chúng ta sẽ có phiên bản chuẩn của tài liệu tham khảo, tài liệu đặc tả yêu cầu.
Step #2: Xây dựng hướng dẫn về những gì sẽ được mong đợi ở cuối của quá trình review từ mỗi thành viên trong nhóm. Nói cách khác, quyết định về phân phối được mong đợi từ bước này – thông thường, đầu ra của bước này là xác định các kịch bản kiểm thử. Kịch bản kiểm thử sẽ không là gì nhưng một con tr™ dòng “Cái gì được test”
cho một chức năng nhất định.
Step #3: Ngoài ra những hướng dẫn về cách chuyển giao này là để trình bày - ý của tôi nghĩa là, các bản mẫu.
Step #4: Quyết định về việc mỗi thành viên của nhóm là làm việc trên toàn bộ tài liệu hoặc chia nhau. Điều này khuyến khích tất cả mọi người nên đọc tất cả mọi thứ vì nó sẽ ngăn chặn sự tập chung kiến thức với các thành viên trong đội. Nhưng trong trường hợp của một dự án khổng lồ, với tài liệu đặc tả yêu cầu chạy đến 1000 trang, cách tiếp cận là chia nh™ tài liệu ra thành từng module thông minh và phân chia cho các thành viên trong nhóm là điều thực tế nhất.
Step #5: Review tài liệu đặc tả yêu cầu cũng giúp ích trong việc hiểu biết tốt hơn nếu có bất kỳ điều kiện tiên quyết cụ thể cần thiết nào cho việc kiểm tra phần mềm.
Step #6: Là một sản phẩm phụ, một danh sách các truy vấn mà một số chức năng khó để hiểu hoặc nếu có nhiều thông tin cần thiết cần phải được đưa vào chức năng yêu cầu hoặc nếu có lỗi phát sinh trong quá trình làm tài liệu đặc tả yêu cầu đã được định nghĩa.
Hình 7:Hình ảnh tài liệu đặc tả yêu cầu chức năng đăng ký thành viên
Hình 8: Màn hình danh sách tuyến cáp 3.2.2.Thực hiện ghi test case
Sau khi đọc và hiểu rõ các requirement, thì 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. Ở đây em xử dụng Excel để ghi và kiểm soát test case
3.2.2.1. Thông tin test case bao gồm - Mô tả về những yêu cầu được kiểm thử.
- Giải thích về cách hệ thống sẽ được kiểm thử.
- Các thiết lập khi kiểm thử như: phiên bản ứng dụng đang kiểm thử, phần mềm, những tệp dữ liệu, hệ điều hành, phần cứng, truy cập bảo mật, ngày thực hiện, các điều kiện tiền đề và bất kỳ thông tin thiết lập nào khác phù hợp với các yêu cầu đang được kiểm thử.
- Đầu vào và đầu ra hoặc hành động và kết quả mong đợi.
- Bất kỳ bằng chứng hoặc tệp đính kèm.
- Sử dụng ngôn ngữ hoạt động.
- Test Case không được quá 15 bước.
- Kịch bản kiểm thử tự động được chú thích đầu vào, mục đích và kết quả mong đợi.
- Thiết lập những thay đổi cho các kiểm thử cần thiết trước.
3.2.2.2. Cách viết test case
3.2.2.2.1. Test case cần phải đơn giản minh bạch
Tạo các Test Cases đơn giản nhất có thể. Test Cases phải rõ ràng và ngắn gọn vì tác giả của Test Cases có thể không thực hiện chúng.
Sử dụng ngôn ngữ dễ hiểu như: đi đến trang chủ, nhập dữ liệu, click vào Submit...
Điều này làm cho việc hiểu các bước kiểm thử dễ dàng và thực hiện kiểm thử nhanh hơn.
3.2.2.2.2. Test case với vai trò như người dung cuối
Mục tiêu cuối cùng của dự án là tạo ra phần mềm đáp ứng yêu cầu của khách hàng và dễ sử dụng cũng như dễ vận hành. Người kiểm thử phải tạo Test Cases dựa trên quan điểm người dùng cuối.
3.2.2.2.3. Tránh lặp test case
Không lặp lại các Test Cases. Nếu một Test Cases là cần thiết để thực hiện một số Test Cases khác, hãy nêu Test Case Id trong cột điều kiện tiền đề.
3.2.2.2.4. Không phỏng đoán
Không ph™ng đoán các chức năng và tính năng của ứng dụng phần mềm trong khi chuẩn bị Test Cases. Phải bám sát các Tài liệu kỹ thuật.
3.2.2.2.5. Đảm bảo bao phủ 100%
Hãy chắc chắn rằng bạn viết các Test Cases để kiểm thử tất cả các yêu cầu phần mềm được đề cập trong tài liệu đặc tả. Sử dụng Ma trận truy xuất nguồn gốc (Traceability Matrix) để đảm bảo không có chức năng hay điều kiện nào chưa được kiểm thử.
3.2.2.2.6. Test case phải được xác định
Đặt tên các Test Cases sao cho chúng được xác định dễ dàng khi theo dõi lỗi hoặc xác định yêu cầu phần mềm ở giai đoạn sau.
3.2.2.2.7. Thực hiện các kỹ thuật kiểm thử
Không thể kiểm thử mọi điều kiện có thể có trong ứng dụng phần mềm. Cho nên em dung những kỹ thuật kiểm thử để cho Test Cases với khả năng tìm thấy lỗi tối đa.
Phân tích giá trị biên (Boundary Value Analysis - BVA): Đây là kỹ thuật kiểm thử xác định các ranh giới cho phạm vi giá trị được chỉ định.
Phân vùng tương đương (Equivalence Partition - EP): Kỹ thuật này phân vùng phạm vi thành các phần giống nhau hoặc nhóm có xu hướng có cùng kết quả.
Kỹ thuật chuyển trạng thái (State Transition Technique): Phương pháp này được sử dụng khi hệ thống có xử lý thay đổi từ trạng thái này sang trạng thái khác sau hành động cụ thể.
Kỹ thuật đoán lỗi (Error Guessing Technique): Dự đoán lỗi có thể phát sinh trong khi kiểm thử. Đây không phải là kỹ thuật chính thức và kỹ thuật này tận dụng trải nghiệm của tester với ứng dụng.
Hình 9: Test Summary
Hình 10.1: Danh sách chức năng hế thống
Hình 10.2: Danh sách chức năng hế thống
3.2.3.Thực thi 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.
3.2.4.Điều tra sâu hơ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%.
3.2.5.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,…
Hình 11.1: Thực thi báo cáo lỗi
Hình 11.2: Thực thi báo cáo lỗi
Hình 12: Lỗi bản đồ
3.2.5.1. Những điểm quan trọng khi viết báo cáo lỗi 3.2.5.1.1. Bug number/id
1 bug number hay 1 ID number (như swb001) giúp bug được report và tham chiếu dễ dàng hơn. Các dev có thể dễ dàng kiểm tra nếu 1 bug cụ thể đã được fix hay chưa.
Nó làm cho toàn bộ quá trình test và retest mượt mà và dễ dàng hơn.
3.2.5.1.2.Bug title
1 bug title được đọc thường xuyên hơn bất cứ phần nào khác của bug report. Nó sẽ nói tất cả về những gì đến trong bug.
Bug title nên gợi ý vừa đủ mà người đọc có thể hiểu nó. 1 bug title rõ ràng làm nó dễ hiểu và người đọc có thể biết được bug đã được report trước đó hay đã được fix.
3.2.5.1.3.Priority
Dựa vào mức động nghiêm trọng của bug, có thể đặt mức độ ưu tiên cho bug. Mỗi bug có thể là Blocker, Critial, Major, Minor, Trivial... Có thể đưa ra mức độ ưu tiên của lỗi từ P1-P5 để những bug quan trọng sẽ được ưu tiên trước.
3.2.5.1.4.Platform/Environment
OS và trình duyệt là điều rất cần thiết cho 1 báo cáo bug rõ ràng. Đây là cách tốt nhất để có thể dễ dàng tái hiện một bug.
Nếu không có platform hoặc môi trường chính xác, thì ứng dụng có thể hoạt động khác đi và bug trên thiết bị của tester sẽ không tái hiện được trên thiết bị của dev. Do đó, tốt nhất nên đề cập rõ ràng đến môi trường phát hiện ra bug.
3.2.5.1.5.Description
Bug description giúp các dev hiểu bug. Nó mô tả các vấn đề gặp phải. Description nghèo nàn sẽ tạo sự nhầm lẫn và lãng phí thời gian của các dev và các tester.
Cần truyền đạt rõ ràng về ảnh hưởng trong descripton. Cần sử dụng các câu hoàn chỉnh. Nó là 1 thói quen tốt để mô tả mỗi vấn đề 1 cách tách biệt thay vì phá vỡ hoàn toàn chúng. Đừng sử dụng các thuật ngữ như “tôi nghĩ” hay “tôi tin”.
3.2.5.1.6.Kết quả dự kiến và thực tế
1 bug description không đầy đủ nếu không có kết quả dự kiến và thực tế. Cần phải phác thảo kết quả của việc test và những gì user sẽ mong đợi. Người đọc sẽ biết kết quả chính xác của việc test là gì. Rõ ràng, đề cập đến những gì đã xảy ra trong quá trình test và kết quả là gì.
3.2.6. Báo cáo kết quả về 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,…
Hình 13: Test report
KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN