Thứ Tư, 7 tháng 6, 2017

[ISTQB]Chương 6: Tool Suport for Testing

1. Types of Test Tools

a, Tool Support for Testing

Test tools có thể được sử dụng cho 1 or nhiều hoạt động để hỗ trợ những thử nghiệm đó
Bao gồm:
- Tools đó được sử dụng trực tiếp trong kiểm thử như test execution tools, test data generation tools and result comparison tools
- Tools đó giúp trong quản lý test process như datas, test result, requirements, incidents, defects ... và cho báo cáo và giám sát thực hiện thử nghiệm
- Tools đó được sử dụng trong trinh sát
- Tool bất kỳ viện trợ trong testing

Tool hỗ trợ cho Testing có thể có 1 or nhiều mục đích tùy theo bối cảnh:
- Cải tiến hiệu quả các hoạt động test bằng cách tự động lặp đi lặp lại các task or hỗ trợ các hoạt động test thủ công như test planning, test design, test reporting và monitoring
- Tự động hóa các hoạt động không thể thực hiện thủ công được
- Tự động hóa các hoạt động yêu cầu tài nguyên đáng kể khi hoàn thành manual
- Tăng độ tin cậy của testing

Điều kiện "Test framework" cũng thường xuyên được sử dụng trong công nghiệp
- Có thể dùng lại được và có khả năng mở rộng thư viện kiểm thử đó có thể được sử dụng để build test tool
- A type of design of test automation (data driven, keywork driven)
- Overall process of execution of testing

b, Test Tool Classification 


c, Tool Support for Management of Testing and Tests

Test Management Tool
Requirement Management Tools
Incident Management Tool (defect tracking tool)
Configuration Management Tools

d, Tool Support for Static Testing

Review Tool
Static Analysis Tool
Modeling Tool

e, Tool Support for Test Specification 

Test Design Tools
Test Data Preparation Tools

f, Tool Support for Test Execution and Logging 

Test Execution Tools
Test Harness/Unit Framework Tools
Test Comparators
Coverage Measurement Tools
Security Testing Tools

g, Tool Support for Performance and Monitoring

Dynamic Analysis Tools
Performance Testing/Load Testing/Stress Testing Tools
Monitoring Tools

h, Tool Support for Specific Testing Needs

Data Quality Assessment

2. Effective Use of Tools: Potential Benefits and Risks

a, Potential Benefits and Risks of Tool Support for Testing

Potential benefits:
- Repetitive work is reduced: Công việc lặp đi lặp lại được giảm
- Greater consistency and repeatability: Tính nhất quán và tính lặp lại tốt
- Objective assessment: Đánh giá mục tiêu
- Ease of access to information about tests of testing: Dễ dàng tiếp cận thông tin về kiểm thử
Risks:
- Unrealistic expectations for the tool: Mong muốn không thực tế cho tool
- Underestimating the time, cost and effort for initial introduction of a tool: Đánh giá thấp thời gian, giá và nỗ lực cho sự giới thiệu đầu tiên của tool
- Đánh giá thấp thời gian và nỗ lực cần để hoàn thành đáng kể và lợi ích tiếp theo từ tool
- Đánh giá thấp nỗ lực được yêu cầu để bảo trì tài sản kiểm thử được tạo bởi tool
- Over-reliance on the tool: Quá phụ thuộc vào tool
- Bỏ bê kiểm soát phiên bản của tài sản kiểm thử bên trong tool
- Bỏ mặc mối quan hệ và khả năng tương tác vấn đề giữa các tool quan trọng như requirement management tools, version control tools, incident management tools, defects tracking tools and tools from multiple vendors
- Rủi ro của nhà cung cấp tool mất đi nghiệp vụ, Tool dừng hoạt động or được bán cho nhà cung cấp khác
- Phản hồi kém từ nhà cung cấp cho việc hỗ trợ, nâng cấp, fix lỗi
- Không lường trước được, như không có khả năng để hỗ trợ cho nền tảng mới
- Rủi ro bị treo mã nguồn mở

b, Special Considerations for Some Types of Tools

Test Execution Tools
 Static Analysis Tools
Test Management Tools

3. Introduction a Tool into an Organization

Các xem xét chính trong lựa chọn tool cho 1 tổ chức:
- Đánh giá của tổ chức trưởng thành, điểm mạnh, điểm yếu và nhận biết của các cơ hội cho cải tiến test pprocess được hỗ trợ bởi tool
- Đánh giá chống lại các yêu cầu rõ ràng và tiêu chuẩn mục tiêu
- Chứng minh khái niệm, sử dụng test tool trong giai đoạn đánh giá để thiết lập liệu nó thực hiện hiệu quả với phần mềm dưới test và bên trong cơ sở hạ tầng hiện tại or để nhận biết thay đổi để cơ sở hạ tầng đó sử dụng hiệu quả tool
- Đánh giá của nhà cung cấp
- Nhận biết các yêu cầu bên trong cho huấn luyện và tư vấn sử dụng tool
- Đánh giá đào tạo cần xem xét nhóm test hiện tại, các kỹ năng test auto
- Ước tính tỉ lệ chi phí-lợi ích dựa trên trường hợp nghiệp vụ
Giới thiệu tool được chọn cho tổ chức bắt đầu với 1 dự án thí điểm:
- Học chi tiết về tool
- Đánh giá tool phù hợp với qui trình và thực hành đã tồn tại và mục đích những gì cần thay đổi
- Quyết định các chuẩn sử dụng, quản lý, bảo trì tool và test assets
- Đánh giá liệu các lợi ích sẽ được hoàn thành với chi phí hợp lý
Yếu tố thành công cho việc triển khai tool bên trong tổ chức:
- Đưa ra tool cho phần còn lại của tổ chức theo từng bước
- Sửa đổi và cải tiến qui trình để phù hợp với việc sử dụng tool
- Cung cấp đào tạo, huấn luyện, tư vấn cho người dùng mới
- Thực hiện cách thu thập thông tin sử dụng từ việc dùng thực tế
- Định nghĩa hướng dẫn sử dụng
- Giám sát sử dụng và lợi ích tool
- Hỗ trợ cung cấp tool cho test team
- Thu thập các bài được học từ tất cả các team






Thứ Ba, 6 tháng 6, 2017

[ISTQB]Chương 5: Test Management

1. Test Organization 

a, Test Organization and Independence

Hiệu quả của việc tìm kiếm các lỗi bởi kiểm thử và đánh giá có thể đc cải tiến bằng việc sửa dụng các Tester độc lập
Các lựa chọn:
- Không có Tester độc lập, Dev kiểm tra chính code của họ
- Tester độc lập bên trong Dev teams
- Group or teams kiểm tra độc lập bên trong tổ chức, báo cáo để quản lý dự án or quản lý sự thực hiện
- Testers độc lập từ tổ chức nghiệp vụ or cộng đồng người dùng
- Chuyên gia (specialists) kiểm tra độc lập cho các loại kiểm tra riêng như Usability Tester, Security Tester, Certification Tester
- Tester độc lập được thuê bên ngoài or bên trong của tổ chức

Lợi ích của sự độc lập
- Tester độc lập thấy được sự khác  biệt các lỗi và không thiên vị
- 1 Tester độc lập có thể xác thực giả thiết người làm trong đặc điểm kỹ thuật và sự thực thi của hệ thống

Hạn chế:
- Cô lập từ nhóm phát triển
- Dev mất đi cảm giác tương ứng về chất lượng
- Tester độc lập có thể như là 1 thắt nút cổ chai or đổ lỗi cho các sự chậm trễ trong khi phát hành


b, Task of the Test Leader and Tester

Test Leader còn được gọi là Test manager or Test coordinator (điều phối viên). Vai trò của Test Leader có thể được thực hiện bởi PM, Dev manager, QA manager or người quản lý của nhóm kiểm thử. Ở các dự án lớn  có thể tồn tại 2 vị trí: Test Leader or Test manager.

Leader task:
- Điều phối kế hoạch và chiến lược kiểm tra với PM or người khác
- Viết or đánh giá chiến lược kiểm thử cho dự án và chính sách kiểm thử cho tổ chức
- Đóng góp các quan điểm kiểm thử cho các hoạt động dự án khác, như là tích hợp kế hoạch
- Kế hoạch kiểm thử - xem xét bối cảnh và hiểu mục tiêu kiểm thử và rủi ro - bao gồm chọn các kiểm thử tiếp cận, ước tính thời gian, cố gắng và giá của kiểm thử, mua lại tài nguyên, định nghĩa các mức độ kiểm thử, các chu kỳ, kế hoạch quản lý biến cố.
- Bắt đầu đặc tả, chuẩn bị, thực thi và thực hiện kiểm thử, giám sát kết quả kiểm thử và kiểm tra tiêu chuẩn đầu ra
- Phỏng theo kế hoạch dựa trên kết quả kiểm thử và quy trình và lấy bất kỳ hoạt đông cần thiết để bù lại cho các vấn đề
- Thiết lập đầy đủ quản lý cấu hình của kiểm thử phần cho việc truy xuất nguồn gốc
- Giới thiệu các số liệu thích hợp cho việc đo lường quy trình kiểm thử và đánh giá chất lượng kiểm thử và sản phẩm
- Quyết định những gì nên tự động, trình độ gì và như thế nào
- Chọn các công cụ hỗ trợ kiểm thử và tổ chức đào tạo sử dụng công cụ cho Tester
- Quyết định về sự thực hiện của môi trường kiểm thử
- Viết báo cáo kiểm thử tổng quát dựa trên các thông tin tập hợp lại trong khi kiểm thử

Tester task:
- Đánh giá và góp phần cho kế hoạch kiểm thử
- Phân tích, đánh giá các yêu cầu người dùng, các đặc tả và mô hình có khả năng kiểm thử
- Tạo đặc tả kiểm thử
- Thiết lập môi trường kiểm thử
- Chuẩn bị và thu lại dữ liệu kiểm thử
- Thực thi các kiểm thử trên tất cả các mức độ, thực hiện và ghi log kiểm thử, đánh giá kết quả và ghi lại độ lệch của kết quả mong muốn
- Sử dụng các công cụ quản lý kiểm thử và giám sát như đã yêu cầu
- Automate tests
- Đo lương hiệu suất của thành phần và hệ thống
- Đánh giá các kiểm thử được phát triển bởi người khác


2. Test Planning and Estimation 

a, Test planning

Đề cương của tài liệu Test planning được bao phủ bởi "Standard for software test document" (IEEE Std 829-1998)
Test planning là 1 hoạt động liên tiếp và được thực hiện trong tất cả vòng đời quy trình và các hoạt động
Phản hồi từ các hoạt động kiểm thử đã từng sử dụng để nhìn nhận lại thay đổi của rủi ro vì vậy planning có thể được điều chỉnh.


b, Test planning activities 

Hoạt động cho 1 phần or toàn bộ hệ thống có thể bao gồm:
- Xác đinh phạm vi và các rủi ro và nhận định các mục tiêu của kiểm thử
- Định nghĩa các tiếp cận của kiểm thử, bao gồm định nghĩa các mức độ kiểm thử, tiêu chuẩn đầu vào và đầu ra
- Tích hợp và điều phối các hoạt động kiểm thử đến các hoạt động của vòng đời phần mềm
- Tạo các quyết định về những gì để kiểm thử, những vai trò gì sẽ thực hiện các hoạt động kiểm thử, các hoạt động kiểm thử như thế nào nên hoàn thành, kết quả kiểm thử như thế nào sẽ được đánh giá
- Lên lich phân tích kiểm thử và hoạt đông thiết kế
- Lên lịch thực hiện , đánh giá kiểm thử
- Phân công tài nguyên (resources) cho các hoạt động khác đươc định nghĩa
- Định nghĩa chi tiết số tiền, mức độ, cấu trúc và bản mẫu cho tài liệu kiểm thử
- Chọn số liệu cho giám sát và điều khiển chuẩn bị kiểm thử, thực hiện, vấn đề rủi ro và độ phân giải lỗi
- Thiết lập chi tiết các mức độ cho thủ tục kiểm thử trong thứ tự cung cấp đủ thông tin để hỗ trợ tái sản xuất sự chuẩn bị và thực hiện kiểm thử


c, Entry criteria

- Môi trường kiểm thử khả dụng và sẵn sàng
- Công cụ kiểm thử sẵn sàng trong môi trường kiểm thử
- Code khả dụng có thể kiểm thử
- Dữ liệu kiểm thử sẵn sàng


d, Exit criteria

- Các biện pháp triệt để như là bao phủ code, chức năng or rủi ro
- Giá
- Ước tính được mật độ lỗi or biện pháp tin cậy
- Rủi ro dư như các lỗi chưa fix or thiếu độ bao phủ kiểm thử trong 1 vùng nhất định
- Sắp xếp như những người dựa trên thời gian để thị trường


e, Test estimation 

Có 2 tiếp cận cho ước tính nỗ lực thử nghiệm:
- Cách tiếp cận dựa trên số liệu:
- Cách tiếp cận dựa trên chuyên gia: ước tính tasks dựa trên ước tính được làm bởi chủ các task đó or bởi chuyên gia
Nỗ lực thử nghiệm tùy theo số các yếu tố, bao gồm:
- Đặc điểm của sản phẩm: Chất lượng của đặc tả và thông tin khác được sử dụng để kiểm thử các mô hình, kích thước của sản phẩm, độ phức tạp của problem domain, các yêu cầu cho độ tin cậy và bảo mật và các yêu cầu cho tài liệu
- Đặc điểm của quá trình phát triển: Sự ổn định của tổ chức, tools test, test process, skills của người tham gia, áp lực thời gian
- Kết quả của thử nghiệm: Số lỗi và số tiền yêu cầu làm việc lại


f, Test strategy and test approach 

Test approach là sự thực hiện của Test strategy cho 1 dự án riêng
Test approach được định nghĩa và lọc trong test plan và test design 
Test approach là điểm bắt đầu cho kế hoạch test process, cho sự lựa chọn test design techniques và test type để ứng dụng và cho định nghĩ tiêu chuẩn đầu vào và đầu ra.
Lựa chọn tiếp cận tùy theo bối cảnh và có thể xem xét rủi ro, nguy hiểm và an toàn, tài nguyên sẵn sàng, skills, technology, bản chất của hệ thống, các mục tiêu và quy định thử nghiệm.
Approaches bao gồm:
- Analytical approaches (Phân tích tiếp cận), như là thử nghiệm dựa trên rủi ro
- Model-based approaches (Tiếp cận dựa trên mô hình)
- Methodical approaches (Phương pháp tiếp cận), như: failure-based, experience-based, checklist-based và chất lương characteristic-based 
- Process or standard-compliant approaches
- Dynamic and Heuristic approaches
- Consultative approaches  (Tư vấn tiếp cận,)
- Regression-averse approaches (Tiếp cận hồi tưởng ngược)

3. Test Progress Monitoring and Control 

a, Test Progress Monitoring 

Mục đích của Test monitoring là để cung cấp các phản hồi và khả thi về các hoạt động kiểm thử. Thông tin được giám sát có thể được thu thập tự động or thủ công và có thể sử dụng để đo tiêu chuẩn đầu ra như dộ bao phủ.
Common test metrics:
- Phần trăm công việc hoàn thành trong sự chuẩn bị test case
- Phần trăm công việc hoàn thành trong sự chuẩn bị môi trường test
- Thực thi test case
- Thông tin lối
- Thử nghiệm bao phủ các yêu cầu, rủi ro or code
- Niềm tin chủ quan của Tester trong sản phẩm
- Ngày tháng của các mốc kiểm thử
- Giá kiểm thử

b, Test Reporting

Test reporting liên quan với việc tóm tắt thông tin về nỗ lực kiểm thử, bao gồm:- Những gì đã xảy ra trong gia đoạn kiểm thử
- Phân tích thông tin và số liệu để hỗ trợ sự giới thiệu và quyết định về hoạt động tương lai, như đánh giá các lỗi còn lại, các rủi ro nổi bật, mức độ tự tin của phần mềm đã kiểm thử.
Dùng chuẩn "Standard for software test documentation" (IEEE std 829-1998)
Số liệu nên được thu thập trong khi và kết thúc 1 mức độ kiểm thử theo thứ tự để đánh giá:
- Đầy đủ các mục tiêu kiểm thử cho mức độ kiểm thử đó
- Đầy đủ kiểm thử tiếp cận 
- Hiệu quả của việc kiểm thử với sự tôn trọng các mục tiêu

c, Test Control

Ví dụ các hoạt động Test control, bao gồm:
- Tạo ra các quyết định dựa trên thông tin từ thử nghiệm giám sát
- Tái ưu tiên các thử nghiệm khi được nhận định rủi ro xảy ra

4. Configuration Management 

Mục đích là để thiết lập và bảo trì toàn vẹn sản phẩm, phần mềm, hệ thống qua vòng đời của dự án và sản phẩm
For testing:
- Tất cả các mục của phần mềm được nhận định, version controlled, theo dõi sự thay đổi, liên quan đến nhau và liên quan tới các mục phát triển vì vậy truy xuất nguồn gốc có thể được bảo trì khắp qui trình kiểm thử
- Tất cả các tài liệu được nhận định và các mục phần mềm được tham khảo rõ ràng trong tài liệu kiểm thử
For Tester:
- Giúp nhận định duy nhất Test items, test document

5. Risk and Testing

a, Project risk 

Organizational factors: (Yếu tố tổ chức)
- Skill, training và thiếu nhân viên
- Các vấn đề nhân viên
- Các vấn đề chính trị
- Thái độ không đúng cách or sự mong đợi  của testing
Technical issues: (Vấn đề kỹ thuật)
- Vấn đề trong việc định nghĩa đúng các yêu cầu
- Phạm vi các yêu cầu đó không thể đáp ứng được các hạn chế đang tồn tại
- Môi trường thử nghiệm không sẵn sàng đúng thời hạn
- Late data conversion, migration planing and development and testing data conversion/migration tools
- Design, code, cấu hình dữ liệu, test data chất lượng thấp
Supplier issues: (vấn đề nhà cung cấp)
- Failure of third party: Thất bại của bên thứ 3
- Contractual issues: Vấn đề về hợp đồng

b, Product risk 

Bao gồm:
- Phần mềm thất bại được đưa ra
- Tiềm năng mà phần mềm, phần cứng có thể là nguyên nhân làm hại đến cá nhân hay công ty
- Đặc điểm phần mềm kém
- Sự toàn vẹn và chất lượng dữ liệu kém
- Phần mềm không thể thực hiện được các chức năng dự định của nó.
Các rủi ro được sử dụng để quyết định bắt đầu testing ở đâu và test nhiều hơn ở đâu; 

6. Incident Management 

Mục tiêu của Incident report :
- Cung cấp người phát triển và các bên khác với phần hồi về vấn đề để cho phép nhận biết, cô lập và chỉnh sửa khi cần thiết
- Cung cấp Test leader để theo dõi chất lượng hệ thống và tiến độ của testing
- Cung cấp các ý tưởng để cải tiến qui trình test
Detail of incident report:
- Ngày phát hành, tổ chức phát hành và tác giả
- Kết quả thực tế và mong muốn
- Nhận biết các mục và môi trường kiểm thử
- Qui trình vòng đời của phần mềm or hệ thống, trong đó các sự cố đã được quan sát
- Miêu tả sự cố để cho phép tái sản xuất và độ phân giải, bao gồm logs
- Phạm vi or trình độ của các tác động người liên quan
- Tác động nghiêm trọng trên hệ thống
- Ưu tiên để sửa chữa
- Trạng thái của sự cố
- Kết luận, giới thiệu và phê duyệt
- Global issues (vấn đề toàn cầu)
- Change history
- References

Thứ Năm, 1 tháng 12, 2016

GENERAL TEST CASE FOR WEBSITE

Kịch bản thử nghiệm chung

1. Lĩnh vực Tất cả bắt buộc phải được đánh giá và chỉ định bởi dấu hoa thị (*) biểu tượng 
2. Thông báo lỗi xác nhận nên được hiển thị đúng ở đúng vị trí 
3. Tất cả các thông báo lỗi sẽ được hiển thị trong cùng một phong cách CSS (ví dụ như sử dụng màu đỏ) 
4. Tin nhắn xác nhận chung sẽ được hiển thị bằng cách sử dụng CSS phong cách khác so với các thông báo lỗi kiểu (ví dụ như sử dụng màu xanh lá cây) 
5. Công cụ lời khuyên văn bản phải có ý nghĩa 
6. Lĩnh vực thả xuống nên phải nhập đầu tiên là trống hoặc văn bản như 'Chọn' 
7. Xóa chức năng cho bất cứ hồ sơ trên trang nên yêu cầu xác nhận 
8. Chọn / bỏ chọn tất cả các hồ sơ tùy chọn cần được cung cấp nếu trang hỗ trợ ghi thêm / xóa / cập nhật chức năng 
9. Giá trị Số tiền sẽ được hiển thị với các biểu tượng chính xác tệ 
10. Mặc định trang phân loại cần được cung cấp 
11. Chức năng của nút reset nên thiết lập các giá trị mặc định cho tất cả các lĩnh vực 
12. Tất cả các giá trị bằng số phải được định dạng đúng 
13. Lĩnh vực đầu vào cần được kiểm tra giá trị trường tối đa. Đầu vào giá trị lớn hơn giới hạn tối đa quy định nên không được chấp nhận hoặc được lưu trữ trong cơ sở dữ liệu 
14. Kiểm tra tất cả các lĩnh vực đầu vào cho các ký tự đặc biệt 
15. Lĩnh vực nhãn có lĩnh vực ví dụ như tiêu chuẩn tên đầu tiên chấp nhận của người dùng phải được dán nhãn đúng là 'Tên' 
16. Kiểm tra trang phân loại chức năng sau khi thêm / sửa / xóa các hoạt động trên bất kỳ kỷ lục 
17. Kiểm tra các chức năng thời gian chờ. Các giá trị thời gian chờ nên được cấu hình. Kiểm tra hành vi ứng dụng sau khi hoạt động thời gian chờ 
18. Kiểm tra các tập tin cookie được sử dụng trong một ứng dụng 
19. Kiểm tra nếu tập tin tải về được trỏ đến sửa đường dẫn tập tin 
20. Tất cả các phím nguồn lực phải được cấu hình trong cấu hình các tập tin hoặc cơ sở dữ liệu thay vì cứng mã hóa 
21. Ước chuẩn nên được theo dõi trong suốt để đặt tên cho phím nguồn 
22. Xác nhận đánh dấu cho tất cả các trang web (xác nhận HTML và CSS cho các lỗi cú pháp) để chắc chắn rằng nó phù hợp với các tiêu chuẩn 
23. Sự cố ứng dụng hoặc các trang không có sẵn sẽ được chuyển hướng tới trang bị lỗi 
24. Kiểm tra văn bản trên tất cả các trang chính tả và lỗi ngữ pháp 
25. Kiểm tra các lĩnh vực đầu vào dạng số với giá trị ký tự đầu vào.Nhắn xác nhận thích hợp sẽ xuất hiện 
26. Kiểm tra cho số âm nếu được phép cho trường số 
27. Kiểm tra các lĩnh vực số tiền với số thập phân giá trị 
28. Kiểm tra chức năng của nút có sẵn trên tất cả các trang 
29. Người dùng không nên có thể gửi trang hai lần bằng cách nhấn nút gửi liên tiếp. 
30. Chia cho số không lỗi nên được xử lý cho bất kỳ tính toán 
31. Dữ liệu đầu vào với trống vị trí đầu tiên và cuối cùng phải được xử lý một cách chính xác

GUI và khả năng sử dụng các kịch bản thử nghiệm

1. Tất cả các mục trên trang (ví dụ như hộp văn bản, tùy chọn radio, danh sách thả xuống) nên được sắp xếp đúng 
2. Các giá trị số nên được quyền biện minh trừ khi có quy định khác 
3. Đủ không gian cần được cung cấp giữa các lĩnh vực nhãn, cột, dòng, thông báo lỗi, vv 
4. Thanh cuộn nên chỉ kích hoạt khi cần thiết 
5. Cỡ chữ, phong cách và màu sắc cho dòng tiêu đề, mô tả văn bản, nhãn, dữ liệu nội đồng, và thông tin điện lưới nên được tiêu chuẩn theo quy định tại SRS 
6. Mô tả hộp văn bản nên được nhiều dòng 
7. Lĩnh vực khuyết tật nên được chuyển sang màu xám và người sử dụng không nên có thể thiết lập tập trung vào các lĩnh vực này 
8. Sau khi bấm vào bất kỳ trường văn bản đầu vào, con chuột mũi tên con trỏ nên được thay đổi để trỏ 
9. Người dùng không nên có thể gõ vào thả xuống chọn danh sách 
10. Thông tin đầy bởi người sử dụng sẽ được giữ nguyên khi có thông báo lỗi trên trang trình. Người sử dụng sẽ có thể nộp đơn lại bằng cách sửa chữa các lỗi 
11. Kiểm tra nếu lĩnh vực nhãn thích hợp được sử dụng trong các thông báo lỗi 
12. Giá trị trường thả xuống sẽ được hiển thị trong định nghĩa thứ tự sắp xếp 
13. Tab và Shift + Tab để nên hoạt động đúng 
14. Tùy chọn mặc định radio nên được chọn trước trên trang tải 
15. Lĩnh vực cụ thể và mức độ trang trợ giúp thông điệp nên có sẵn 
16. Kiểm tra nếu các lĩnh vực chính xác đã được nhấn mạnh trong trường hợp lỗi 
17. Kiểm tra xem các tùy chọn danh sách thả xuống là có thể đọc được và không phải cắt ngắn do kích thước giới hạn lĩnh vực 
18. Tất cả các nút trên trang nên có thể truy cập bằng phím tắt và người dùng sẽ có thể thực hiện tất cả các hoạt động sử dụng bàn phím 
19. Kiểm tra tất cả các trang bị bể hình 
20. Kiểm tra tất cả các trang liên kết hỏng 
21. Tất cả các trang nên có tiêu đề 
22. Thông báo xác nhận sẽ được hiển thị trước khi thực hiện bất kỳ bản cập nhật hoặc xóa các hoạt động 
23. Giờ kính sẽ được hiển thị khi ứng dụng đang bận 
24. Trang văn bản nên để biện minh 
25. Người sử dụng sẽ có thể lựa chọn chỉ có một lựa chọn đài phát thanh và bất kỳ sự kết hợp với hộp kiểm tra.

Kịch bản thử nghiệm cho Bộ lọc tiêu chuẩn

1. Người sử dụng sẽ có thể lọc kết quả sử dụng tất cả các thông số trên trang 
2. Tinh chỉnh chức năng tìm kiếm nên tải trang tìm kiếm với tất cả các thông số tìm kiếm người dùng lựa chọn 
3. Khi có ít nhất một trong các tiêu chí lọc là cần thiết để thực hiện các hoạt động tìm kiếm, đảm bảo thông báo lỗi thích hợp được hiển thị khi người dùng gửi trang mà không chọn bất kỳ tiêu chí lọc. 
4. Khi có ít nhất một trong các tiêu chí lọc lựa chọn không phải là người sử dụng bắt buộc sẽ có thể gửi trang và mặc định tiêu chí tìm kiếm nên được sử dụng để truy vấn kết quả 
5. Thư xác nhận thích hợp nên được hiển thị cho các giá trị hợp lệ cho tiêu chí lọc

Kịch bản thử nghiệm cho kết quả Lưới

Biểu tượng tải 1. Page sẽ được hiển thị khi nó lấy nhiều hơn thời gian mặc định để tải các trang kết quả 
2. Kiểm tra xem tất cả các thông số tìm kiếm được sử dụng để lấy dữ liệu hiển thị trên kết quả lưới điện 
3. Tổng số kết quả sẽ được hiển thị trên kết quả lưới 
4. Tiêu chí tìm kiếm sử dụng để tìm kiếm sẽ được hiển thị trên kết quả lưới 
5. Giá trị lưới kết quả nên được sắp xếp theo cột mặc định. 
6. Cột được sắp xếp sẽ được hiển thị với biểu tượng phân loại 
7. Lưới kết quả nên bao gồm tất cả các cột chỉ định với giá trị đúng 
8. Tăng dần và giảm dần chức năng phân loại nên làm việc cho cột được hỗ trợ với các dữ liệu phân loại 
9. Lưới kết quả sẽ được hiển thị với cột thích hợp và liên tiếp khoảng cách 
10. Phân trang nên được kích hoạt khi có kết quả hơn so với kết quả mặc định đếm mỗi trang 
11. Kiểm tra kế tiếp, trước, đầu tiên và trang cuối pagination chức năng 
12. Hồ sơ trùng lặp không được hiển thị trong kết quả lưới điện 
13. Kiểm tra xem tất cả các cột được hiển thị và ngang thanh cuộn được kích hoạt nếu cần thiết 
14. Kiểm tra dữ liệu cho cột năng động (cột có giá trị được tính toán tự động dựa trên các giá trị cột khác) 
15. Đối với lưới kết quả cho thấy các báo cáo kiểm tra hàng 'Totals' và xác minh tổng thể cho mỗi cột 
16. Đối với lưới kết quả cho thấy các báo cáo kiểm tra dữ liệu hàng 'Totals' khi pagination được kích hoạt và dùng điều hướng đến trang tiếp theo 
17. Kiểm tra xem các ký hiệu thích hợp được sử dụng để hiển thị các giá trị cột ví dụ như biểu tượng% sẽ được hiển thị để tính tỷ lệ 
18. Kiểm tra dữ liệu kết quả lưới nếu phạm vi ngày được kích hoạt

Kịch bản thử nghiệm cho một cửa sổ

1. Kiểm tra xem kích thước cửa sổ mặc định là chính xác 
2. Kiểm tra xem kích thước cửa sổ con là đúng 
3. Kiểm tra nếu có bất kỳ lĩnh vực trên trang tập trung mặc định (nói chung, trọng tâm cần được thiết lập trên lĩnh vực đầu vào đầu tiên của màn hình) 
4. Kiểm tra nếu cửa sổ con đang nhận được đóng cửa vào bế mẹ / mở cửa sổ 
5. Nếu cửa sổ con được mở ra, người sử dụng không nên có thể sử dụng hoặc cập nhật bất kỳ lĩnh vực trên nền hoặc cha mẹ cửa sổ 
6. Kiểm tra cửa sổ tối thiểu, tối đa hóa và chức năng gần 
7. Kiểm tra nếu cửa sổ được tái khá lớn 
8. Kiểm tra chức năng thanh cuộn cho cha mẹ và con windows 
9. Kiểm tra hủy bỏ chức năng của nút cho cửa sổ con

Cơ sở dữ liệu kiểm tra kịch bản thử nghiệm

1. Kiểm tra xem dữ liệu chính xác là nhận được lưu trong cơ sở dữ liệu trên trang thành công trình 
2. Kiểm tra giá trị cho các cột mà không được chấp nhận giá trị null 
3. Kiểm tra tính toàn vẹn dữ liệu. Dữ liệu sẽ được lưu trữ trong các bảng một hoặc nhiều dựa trên thiết kế 
4. Tên chỉ mục nên được đưa ra theo các tiêu chuẩn, ví dụ như IND_ <tablename> _ <ColumnName> 
5. Bàn nên có khóa chính cột 
6. Cột bảng cần phải có thông tin mô tả có sẵn (trừ cột kiểm toán như ngày tạo ra, tạo ra bởi vv) 
7. Đối với mỗi cơ sở dữ liệu thêm / cập nhật bản ghi hoạt động nên được bổ sung 
8. Chỉ số bảng cần phải được tạo ra 
9. Kiểm tra xem dữ liệu được cam kết cơ sở dữ liệu chỉ khi hoạt động được hoàn thành 
10. Dữ liệu nên được cuộn lại trong trường hợp giao dịch thất bại 
11. Tên cơ sở dữ liệu nên được đưa ra theo các loại ứng dụng thử nghiệm tức, uất, sandbox, sống (mặc dù đây không phải là một tiêu chuẩn nó là hữu ích để bảo trì cơ sở dữ liệu) 
12. Cơ sở dữ liệu tên logic cần được theo tên cơ sở dữ liệu (một lần nữa đây không phải là tiêu chuẩn nhưng hữu ích để bảo trì DB) 
13. Thủ tục lưu trữ không nên được đặt tên với tiền tố "sp_" 
14. Kiểm tra là giá trị cho các cột kiểm toán bảng (như CreatedDate, createdby, UpdateDate, updatedby, isDeleted, deleteddate, deletedby vv) được dân cư đúng 
15. Kiểm tra xem dữ liệu đầu vào không được cắt ngắn trong khi tiết kiệm. Dài trường cho thấy người sử dụng trên trang và trong lược đồ cơ sở dữ liệu nên được cùng 
16. Kiểm tra số lĩnh vực với mức tối thiểu, tối đa, và float giá trị 
17. Kiểm tra số lĩnh vực có giá trị âm (cho cả hai chấp nhận và không chấp nhận) 
18. Kiểm tra xem nút radio và danh sách thả xuống tùy chọn sẽ được lưu trong cơ sở dữ liệu một cách chính xác 
19. Kiểm tra nếu các lĩnh vực cơ sở dữ liệu được thiết kế với kiểu dữ liệu chính xác và độ dài dữ liệu 
20. Kiểm tra xem tất cả các ràng bảng như Tiểu học trọng điểm, vv chính nước ngoài được thực hiện một cách chính xác 
21. Kiểm tra thủ tục lưu trữ và trigger với dữ liệu đầu vào mẫu 
22. Đầu vào lĩnh vực hàng đầu và dấu không gian nên được cắt ngắn trước khi cam kết dữ liệu vào cơ sở dữ liệu 
23. Giá trị null không được phép cho cột khóa chính

Kịch bản thử nghiệm cho hình ảnh tính năng tải lên

(Cũng được áp dụng cho các chức năng upload file khác)
1. Kiểm tra các đường dẫn hình ảnh tải lên 
2. Kiểm tra tải hình ảnh và thay đổi chức năng 
3. Kiểm tra chức năng tải hình ảnh với các tập tin hình ảnh của các phần mở rộng khác nhau (ví dụ như JPEG, PNG, BMP, vv) 
4. Kiểm tra chức năng upload hình ảnh với hình ảnh có không gian hoặc bất kỳ phép nhân vật đặc biệt khác trong tên tập tin 
5. Kiểm tra tên trùng lặp hình ảnh tải lên 
6. Kiểm tra tải hình ảnh với kích thước hình ảnh lớn hơn tối đa kích thước cho phép. Thông báo lỗi thích hợp nên được hiển thị. 
7. Kiểm tra chức năng tải hình ảnh với các loại file khác với hình ảnh (ví dụ như txt, doc, pdf, exe vv). Thông báo lỗi thích hợp nên được hiển thị 
8. Kiểm tra nếu hình ảnh của chiều cao và chiều rộng (nếu đã xác định) quy định ghi là trường hợp từ chối 
9. Tải hình ảnh lên thanh tiến trình sẽ xuất hiện cho hình ảnh kích thước lớn 
10. Kiểm tra nếu hủy chức năng của nút đang làm việc ở giữa quá trình tải lên 
11. Kiểm tra xem hộp thoại chọn tập tin chỉ hiển thị được hỗ trợ các tập tin được liệt kê 
12. Kiểm tra nhiều hình ảnh tải lên chức năng 
13. Kiểm tra chất lượng ảnh sau khi upload. Chất lượng hình ảnh không được thay đổi sau khi tải lên 
14. Kiểm tra xem người dùng có thể sử dụng / xem các hình ảnh tải lên

Kịch bản thử nghiệm cho việc gửi email

(Trường hợp thử nghiệm để sáng tác hoặc xác nhận email sẽ không bao gồm) 
(Hãy chắc chắn để sử dụng địa chỉ email giả trước khi thực hiện các bài kiểm tra email liên quan)
1. Gửi email mẫu nên sử dụng CSS tiêu chuẩn cho tất cả các email 
2. Địa chỉ email phải được xác nhận trước khi gửi email 
3. Ký tự đặc biệt trong email mẫu cơ thể cần được xử lý đúng cách 
4. Ký tự ngôn ngữ cụ thể (ví dụ như ký tự tiếng Nga, Trung, Đức) phải được xử lý đúng cách trong email cơ thể mẫu 
5. Tiêu đề email không nên để trống 
6. Lĩnh vực giữ chỗ được sử dụng trong email mẫu nên được thay thế bằng giá trị thực tế ví dụ như {FirstName} {lastname} nên được thay thế với các cá nhân đầu tiên và cuối cùng tên đúng cho tất cả người nhận 
7. Nếu báo cáo với các giá trị năng động mới có trong nội dung email, dữ liệu báo cáo phải được tính toán một cách chính xác 
8. Email tên người gửi không nên để trống 
9. Email nên được kiểm tra trong các khách hàng email khác như Outlook, Gmail, Hotmail, Yahoo! Mail, vv 
10. Kiểm tra chức năng gửi email sử dụng TO, CC và BCC lĩnh vực 
11. Kiểm tra email văn bản đồng bằng 
12. Kiểm tra định dạng HTML email 
13. Kiểm tra tiêu đề email và footer cho logo của công ty, chính sách bảo mật và các liên kết khác 
14. Kiểm tra email với file đính kèm 
15. Kiểm tra gửi các chức năng email để đơn, hoặc danh sách phân phối nhận 
16. Kiểm tra nếu trả lời đến địa chỉ email là chính xác 
17. Kiểm tra gửi khối lượng email

Kịch bản thử nghiệm cho Excel Export năng

1. Tập tin nên được xuất khẩu trong tập tin thích hợp mở rộng 
2. Tên cho file Excel được xuất nên được theo các tiêu chuẩn, ví dụ như nếu tên tập tin được sử dụng dấu thời gian, nó nên được thay thế đúng vào thời điểm thực tế tại thời điểm xuất khẩu các tập tin 
3. Kiểm tra định dạng ngày nếu tập tin Excel xuất khẩu chứa các cột ngày 
4. Kiểm tra định dạng số cho giá trị số hoặc tiền tệ. Định dạng nên được giống như hiển thị trên trang 
5. Tập tin xuất khẩu nên có cột với tên cột đúng 
6. Mặc định trang phân loại phải được tiến hành trong tập tin xuất cũng 
7. Dữ liệu tập tin Excel nên được định dạng đúng với tiêu đề và chân trang văn bản, ngày tháng, số trang, vv giá trị cho tất cả các trang 
8. Kiểm tra xem dữ liệu hiển thị trên trang và tập tin Excel xuất khẩu là cùng 
9. Kiểm tra chức năng xuất khẩu khi pagination được kích hoạt 
10. Kiểm tra xem nút xuất được hiển thị biểu tượng thích hợp theo loại tập tin xuất khẩu ví dụ như Excel file icon cho các file xls 
11. Kiểm tra chức năng xuất khẩu cho các tập tin có kích thước rất lớn 
12. Kiểm tra chức năng xuất khẩu cho các trang có chứa ký tự đặc biệt. Kiểm tra xem các ký tự đặc biệt được xuất khẩu đúng trong tập tin Excel

Hiệu suất kịch bản thử nghiệm

1. Kiểm tra thời gian tải trang là trong phạm vi chấp nhận được 
2. Kiểm tra tải trang trên các kết nối chậm 
3. Kiểm tra thời gian phản ứng đối với bất kỳ hành động dưới điều kiện tải nhẹ, bình thường, trung bình và nặng 
4. Kiểm tra thực hiện các thủ tục cơ sở dữ liệu được lưu trữ và gây ra 
5. Kiểm tra truy vấn cơ sở dữ liệu thời gian thực hiện 
6. Kiểm tra để kiểm tra tải trọng của ứng dụng 
7. Kiểm tra căng thẳng thử nghiệm của ứng dụng 
8. Kiểm tra CPU và bộ nhớ sử dụng trong điều kiện phụ tải đỉnh

An ninh kiểm tra kịch bản thử nghiệm

1. Kiểm tra để tiêm tấn công SQL 
2. Trang an toàn nên sử dụng giao thức HTTPS 
3. Trang tai nạn không nên tiết lộ ứng dụng hoặc thông tin máy chủ.Trang lỗi sẽ được hiển thị cho điều này 
4. Thoát khỏi nhân vật đặc biệt trong đầu vào 
5. Thông báo lỗi không nên tiết lộ bất kỳ thông tin nhạy cảm 
6. Tất cả các thông tin cần được chuyển qua một kênh được mã hóa 
7. Bảo mật mật khẩu kiểm tra và thực thi chính sách mật khẩu 
8. Kiểm tra ứng dụng logout chức năng 
9. Kiểm tra cho Brute Force tấn công 
10. Thông tin cookie sẽ được lưu trữ trong định dạng mã hóa chỉ có 
11. Kiểm tra thời gian cookie phiên và kết thúc phiên sau khi thời gian chờ hoặc logout 
11. Session tokens nên được truyền qua kênh bảo đảm 
13. Mật khẩu không nên được lưu trữ trong cookie 
14. Thử nghiệm cho từ chối dịch vụ tấn công 
15. Thử nghiệm cho bộ nhớ rò rỉ 
16. Kiểm tra ứng dụng truy cập trái phép bằng cách thao tác các giá trị biến trong thanh địa chỉ trình duyệt 
17. Tập tin thử nghiệm mở rộng bàn giao để các file exe không được tải lên và thực hiện trên máy chủ 
18. Các lĩnh vực nhạy cảm như mật khẩu và thông tin thẻ tín dụng không nên có tự động hoàn toàn kích hoạt 
19. Chức năng upload file nên sử dụng hạn chế loại tập tin và cũng chống virus để quét các tập tin được tải lên 
20. Kiểm tra xem danh sách thư mục bị cấm 
21. Mật khẩu và các lĩnh vực nhạy cảm khác nên được đeo mặt nạ trong khi đánh máy 
22. Kiểm tra xem chức năng quên mật khẩu được đảm bảo với các tính năng như tạm thời mật khẩu giờ hết sau khi đã xác định và câu hỏi bảo mật được yêu cầu trước khi thay đổi hoặc yêu cầu mật khẩu mới 
23. Xác minh tính năng CAPTCHA 
24. Kiểm tra xem các sự kiện quan trọng được ghi lại trong các file log 
25. Kiểm tra nếu đặc quyền truy cập được thực hiện một cách chính xác