21 Điều Khoản Chung Cho Kiểm Thử

1. Testing:

Kiểm thử là một bộ các hoạt động bao gồm lập kế hoạch và kiểm soát, chọn điều kiện kiểm tra, thiết kế và thực hiện các trường hợp kiểm tra, kiểm tra kết quả, đánh giá tiêu trí, báo cáo và hoàn thiện. Kiểm thử cũng bao gồm xem xét tài liệu và tiến hành phân tích. Testing cũng có thể xem như là quá trình thẩm định và thẩm tra (validating and verifying) phần mềm/chương trình/ứng dụng/sản phẩm để:

• Đáp ứng được các yêu cầu công việc và kỹ thuật đã được qui định trong thiết kế và trong lúc phát triển;
• Làm việc như mong đợi;
• Và có thể thực thi với các đặc tính giống nhau.

2. Test case:

Test case mô tả một dữ liệu đầu vào (input), hành động (action) hoặc sự kiện (event) và một kết quả mong đợi (expected response), để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không. Một test case có thể có các phần đặc thù khác nhau như mã test case, tên test case, mục tiêu test, các điều kiện test, các yêu cầu data input, các bước thực hiện và các kết quả mong đợi. Testcase hiểu nôm na là một tình huống kiểm tra, được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Nó bao gồm 3 bước cơ bản :

• Mô tả : đặc tả các điều kiện cần cố để tiến hành kiểm tra.
• Nhập : đặc tả đối tượng hoặc dữ liệu cần thiết, được sử dụng làm đầu vào để thực hiện kiểm tra.
• Kết quả mong chờ : kết quả trả về từ đối tượng kiểm tra. Lưu ý: Quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng. Vì lý do này, việc chuẩn bị test case sớm nhất có thể trong qui trình phát triển phần mềm là rất hữu ích.

3. Test Suite:

Là một tập hợp các test case cho một mục đích nhất định, ví dụ như Regression Test Suite được chạy để verify những feature cũ. Sơ đồ kiểm tra Suite:

4. Test:

Là một tập hợp của một hoặc nhiều trường hợp kiểm thử.

5. Test basis:

Là tất cả các tài liệu có yêu cầu của một bộ phận hoặc hệ thống mà có thể suy luận. Các tài liệu có thể dựa vào để kiểm thử.

6. 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ử.

7. Test charter

Một tuyên bố của các mục tiêu thử nghiệm, và có thể thử nghiệm các ý tưởng về làm thế nào để kiểm tra. Điều lệ kiểm tra được sử dụng trong kiểm tra thăm dò.

8. Test plan

Test plan là một tài liệu mô tả phạm vi, nhân lực và kế hoạch của các hoạt động test dự kiến. Nó các định giữa các hạng mục test khác nhau, các chức năng sẽ được test, các nhiệm vụ test, ai sẽ thực hiện task nào, mức độ độc lập của testser, môi trường test, các kỹ thuật thiết kế test và tiêu chuẩn test và tiêu chuẩn kết thúc test sẽ được sử dụng, và lý do cho việc lựa chọn và bất kỳ rủi ro đòi hỏi phải lập kế hoạch dự phòng. Đây là hồ sơ của quá trình lập kế hoạch test.

9. Test strategy

Chiến lược test: là một bản phác họa mô tả phần kiểm thử của một qui trình phát triển phần mềm. Nó được tạo ra để thông báo đến các quản lý dự án, tester và DEV về một số vấn đề chính của quá trình kiểm thử. Bao gồm mục tiêu kiểm thử, các phương pháp dùng để kiểm thử các chức năng mới, tổng thời gian và nguồn nhân lực được yêu cầu cho dự án và môi trường kiểm thử.

Các chiến lược test mô tả làm thế nào để các rủi ro sản phẩm của các bên liên quan được giảm bớt ở các mức test, loại kiểm thử nào sẽ được thực hiện, và sẽ áp dụng điều kiện bắt đầu và kết thúc kiểm thử nào. Chúng được tạo ra dựa trên các tài liệu thiết kế phát triển phần mềm. Các tài liệu thiết kế hệ thống được sử dụng chủ yếu và đôi khi cũng tham khảo tài liệu thiết kế khái niệm. Các tài liệu thiết kế mô tả chức năng của phần mềm sẽ được kích hoạt trong đợt phát hành sắp tới. Ở mọi giai đoạn (chặng) thiết kế phát triển, một chiến lược kiểm thử tương ứng sẽ được tạo để kiểm thử các tập đặc điểm mới (vì ở mỗi chặng phát triển phần mềm thì có các đặc điểm riêng cần test).

*Một ví dụ sưu tầm: * Với yêu cầu đặt ra là làm sao để test được 5000 test cases trong một ngày. Nếu không test kịp thì phải làm thế nào? Theo mình, không thể thực hiện được 5000 test cases trong ngày vì giả sử 1 test case mất 1 phút để test, thì tổng thời gian phải mất là 5000 phút. 5000 phút / 60 = ~832 giờ = 104 ngày làm việc ~ 5 tháng. Vậy thì phải làm gì? Để test kịp thì phải phân loại, sắp xếp và gán độ ưu tiên cho test case, rồi test những test case có độ ưu tiên cao trước. Với các test case về chức năng thì ưu tiên hàng đầu, tiếp theo là test case về GUI (test theo thiết kế), sau đó test case về performance, tiếp theo là test case về look and feel (test GUI theo cảm tính và các vấn đề khác như đẹp xấu, dễ sử dụng hay không, tiện lợi hay không,...). Trên đây là 1 chiến lược để thực hiện test 5000 test cases trong 1 ngày (hiển nhiên là phải tốn thời gian cho việc sắp xếp test case).

10. Test automation:

Automation Testing nghĩa là sử dụng một công cụ tự động để thực hiện các test case. Các phần mềm tự động hóa cũng có thể nhập dữ liệu thử nghiệm vào System Under Test, so sánh kết quả mong đợi và kết quả thực tế và tạo các báo cáo kiểm tra chi tiết. Kiểm tra tự động đòi hỏi khoản đầu tư đáng kể tiền bạc và nguồn lực. Chu kỳ phát triển kế tiếp sẽ đòi hỏi phải thực hiện lặp lại test suite nhiều lần. Sử dụng một công cụ kiểm thử tự động (test automation tool) nó có thể ghi lại các test suite này và re-play lại như yêu cầu. Các test suite này là tự động, không cần sự can thiệp của con người. Điều này cải thiện ROI của Automation Testing. Mục tiêu của tự động hóa là để giảm số test casevà giảm thiểu loại bỏ kiểm tra thủ công.

11. Unit testing

Unit Test – Kiểm tra mức đơn vị Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ PTPM. Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then ... else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.

12. System testing

System testing là quá trình kiểm tra của một sản phẩm đã hoàn chỉnh và tích hợp đầy đủ. Sau khi Integration test và Unit test Thông thường 1 sản phẩm phần mềm chỉ được test trên 1 vì môi trường demo, nhưng system test đảm bảo cho hệ thống vận hành trên nhiều môi trường khác nhau, tích hợp với nhiều phần mềm và hệ thống khác nhau. System test thuộc loại kiểm thử hộp đen. System liên quan đến các hoạt động bên ngoài của phần mềm từ quan điểm của người sử dụng. Trong quá trình hoàn thiện sản phẩm system test là vô cùng quan trọng, system test sẽ đảm bảo cho ứng dụng của bạn có khả năng tương thích cao với môi trường thực trước khi sản phẩm được ra mắt. Một số system testing điển hình:

• Usability Testing – Kiểm tra tính khả dụng của ứng dụng
• Load Testing – Kiểm tra tốc độ vận hành của sản phẩm
• Regression Testing – Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra một thay đổi mã chính
• Recovery Testing – Kiểm thử phục hồi là kiểm thử được thực hiện sau khi có các sự cố hệ thống dẫn đến chương trình lỗi, không hoạt động được.
• Migration Testing – Kiểm thử di động được thực hiện để đảm bảo tính linh động của phần mềm, phần mềm có thể di chuyển được chuyển từ cơ sở hạ tầng hệ thống cơ sở hạ tầng hệ thống cũ để hiện tại không có bất kỳ vấn đề
• Functional Testing – Kiểm thử chức năng nhằm đảm bảo chức năng phần mềm được vận hành theo đúng mục đích đưa ra
• Hardware/Software Testing – Đây là khi các thử nghiệm tập trung chú ý về sự tương tác giữa các phần cứng và phần mềm trong quá trình thử nghiệm hệ thống.

13. Exploratory Testing:

kiểm thử thăm dò là cách tiếp cận quá trình test cho phép bạn áp dụng năng lực, kỹ năng và kỹ xảo của người kiểm thử (QA) một cách hữu hiệu nhất.

14. Regression Testing

Kiểm thử hồi quy: Được thực hiện tự động hóa, thực hiện khi sản phẩm đã được đưa vào sử dụng. Sau khi sản phẩm đã được đưa vào sử dụng, người làm phần mềm thêm vào những chức năng mới->thực hiện test lại để xem sự thay đổi đó có gây ra những hậu quả ko mong muốn hay ko?-> nếu có thì loại bỏ: đó goi là regression testing.

15. Retesting:

Re-test: Đồng nghĩa với confirmation testing (kiểm tra xác nhận) Là thực hiện test để kiểm tra xem bug mình đã post có được fixed hay chưa (kiểm tra lại xem đã hết bị lỗi mà mình đã gặp chưa). Nếu đã được sửa xong thì mình báo cáo Close bug Ngược lại, nếu vẫn còn lỗi thì báo cáo re-open để DEV sửa lại.

16. Integration testing:

Integration Testing là công việc kiểm thử tích hợp 1 nhóm các module riêng lẻ với nhau cùng với các Unit Test riêng lẻ trong từng module. Một dự án phần mềm điển hình bao gồm nhiều module phần mềm, được code bởi nhiều người khác nhau. Tích hợp thử nghiệm tập trung vào kiểm tra truyền dữ liệu giữa các module.

Ví dụ: 1 trường hợp mẫu Integration Test cho các kịch bản sau đây: Ứng dụng có 3 module gồm: ‘Login Page, ‘mail box’ và ‘delete mail’. Trong đó tập trung chủ yếu vào phần Mail Box: Kiểm tra tích hợp của nó để delete mail.

17. Compatibility testing:

Kiểm thử khả năng tương thích của phần mềm nghĩa là kiểm tra xem phần mềm của bạn có tương tác và chia sẻ thông tin chính xác với các phần mềm khác nhau không. Sự tương tác này có thể xảy ra giữa 2 chương trình chạy đồng thời trên cùng một máy tính, hoặc thậm chí trên các máy tính khác nhau được kết nối Internet ở cách nhau tới hàng nghìn dặm. Việc tương tác cũng có thể đơn giản như việc lưu dữ liệu ở một đĩa mềm và chuyển nó bằng tay tới một máy khác qua những căn phòng. *Ví dụ: *Lưu dữ liệu về các phép tình từ một chương trình có trang bảng tính và sau đó load nó bởi một chương trình bảng tính khác hoàn toàn

18. Baseline

Một tài liệu kỹ thuật hoặc sản phẩm phần mềm đã được review hoặc phê duyệt chính thức, và xem đó như là cơ sở cho việc phát triển tiếp theo, và nó có thể được thay thông qua một qui trình kiểm soát thay đổi chính thức.

19. Validation

Kiểm định là để chắc chắn rằng sản phẩm được thiết kế để cung cấp tất cả các chức năng cho khách hàng. Kiểm định được thực hiện từ lúc bắt đầu của quá trình phát triển phần mềm. Nó bao gồm các đánh giá và các cuộc họp, rà soát, kiểm tra, ... để đánh giá tài liệu, kế hoạch, việc lập trình, các yêu cầu và các thông số kỹ thuật.

20. Verification

Thẩm định là xác định xem hệ thống có phù hợp với yêu cầu và thực hiện các chức năng mà nó được dự định và đáp ứng các mục tiêu của tổ chức và nhu cầu của người dùng hay không. Thẩm định được thực hiện vào cuối của quá trình phát triển và diễn ra sau khi việc kiểm định được hoàn thành.

21. Usability

Usability (tính khả dụng) là thước đo khả năng của một sản phẩm để phục vụ các mục tiêu của người sử dụng. Trong công nghệ thông tin, thuật ngữ này thường được sử dụng liên quan đến các ứng dụng phần mềm và các trang web, nhưng nó cũng có thể được sử dụng liên quan đến bất kỳ sản phẩm nào khác. Một số yếu tố được sử dụng để đánh giá tính khả dụng của một sản phẩm có thể là tính năng dễ sử dụng, tính thống nhất về hình ảnh, và một quy trình phát triển web rõ ràng. Trong SEO việc kiểm tra tính khả dụng (Usability) là một phương pháp kiểm tra xem người sử dụng sản phẩm khi thực hiện hành vi của mình trên website có dễ dàng hay không. Việc kiểm tra tính khả dụng của một ứng dụng hoặc trang web sẽ giúp các bạn quản trị web tối ưu được trang web của mình thân thiện hơn với khách hàng từ đó cung cung cấp cho người dùng những tiện ích phù hợp với mục tiêu tìm kiếm của họ.