Giới thiệu Ad-Hoc Testing - Phương pháp kiểm thử phần mềm tùy hứng bạn nên thử

1) Ad - Hoc Testing là gì ?

Bạn kiểm thử phần mềm dựa theo kinh nghiệm hoặc " tùy hứng" - không theo một kế hoạch hoặc một tài liệu nào thì đó là bạn đang kiểm thử theo Ad-Hoc testing

2) Đặc điểm của kỷ thuật Ad-Hoc testing

- Ad-hoc testing là phương pháp kiểm thử phần mềm được thực hiện một cách rất ngẫu hứng, không theo bất kỳ một kế hoạch hay tài liệu nào. Và nó cũng dự định chỉ được chạy một lần, trừ khi có lỗi xảy ra.

=> Kiểm thử viên có thể tùy hứng, tha hồ test theo ý của mình, phán đoán các case hóng búa nhất, hay xảy ra lỗi nhất tuy nhiên không thể chắc chắn bao phủ hết các trường hợp và cũng không thể ghi nhớ hết các case mình đã test do đó rất khó để tái hiện lỗi. Tuy nhiên - ưu điểm của phương pháp kiểm thử này là nhanh chóng - không bị ràng buộc

 -Ad-hoc testing là phương pháp kiểm thử phần mềm ít chính thức nhất vì bị chỉ trích là không có cấu trúc, khó tái hiện lỗi vì không có test cases  và khó kiểm soát .

- Ad-hoc testing yêu cầu kiểm thử viên thực  hiện phải có kiến thức tốt về hệ thống, về ứng dụng đang test, vì bản thân cách kiểm thử này gần giống như là việc đoán lỗi. 

-  Ad-hoc testing được dùng nhiều nhất trong kiểm thử ứng dụng hoặc trò chơi. Bất cứ ứng dụng hay trò chơi nào cũng cần đến việc kiểm thử ngẫu nhiên nhằm đoán được đến mức tối đa hành vi của users mà test cases dù có viết kỹ thế nào cũng không thể lường được hết.

3. Cách tiếp cận Ad-hoc testing

Không có một định nghĩa hay cách tiếp cận chính xác nào cho Ad-hoc testing, vì đây là việc thực hiện kiểm thử một cách ngẫu hứng. Nó phụ thuộc vào kinh nghiệm, quan điểm, cách suy nghĩ của người thực hiện kiểm thử trước một hệ thống, một ứng dụng hay trò chơi. Các tester có kinh nghiệm có thể tìm ra nhiều khiếm khuyết của hệ thống thông qua Ad-hoc testing bởi họ hiểu được những scenario thông dụng và cái gì có thể gây ra lỗi cho hệ thống mà họ kiểm thử. Tuy nhiên, người muốn tìm hiểu về Ad-hoc testing cũng có thể tiếp cận nó qua những tóm tắt sau đây:

3.1 Tiếp cận Ad-Hoc testing bằng cách -Tìm kiếm nhóm khiếm khuyết

Nhóm khiếm khuyết là một khu vực trên hệ thống, nơi có khả năng xảy ra số lượng lỗi lớn nhất. Khi thực hiện Ad-hoc testing, tester có thể thử kịch bản xem có thể tìm thấy lỗi ở những khu vực khác nhau hay không. Có người có thể tìm ra nhóm khiếm khuyết bằng cách phân tích lịch sử kiểm thử bằng test case đã được thực hiện trước đó, cũng có người tìm ra bằng cách dự đoán nơi có khả năng xảy ra lỗi.

3.2 Chú ý Sự tác động qua lại giữa các bộ phận cấu thành

Sự tác động qua lại, ảnh hưởng lẫn nhau giữa các chức năng con trên hệ thống là một kịch bản thường thấy khi có lỗi xảy ra. Khi thực hiện Ad-hoc testing, tester có thể chỉ ra sự ảnh hưởng đó giữa các module với nhau, từ đó tìm ra những trạng thái bất bình thường của hệ thống.

3.3 Suy nghĩ như một developer

Khi thực hiện Ad-hoc testing, nếu suy nghĩ như một developer, nhìn vào hệ thống và thử nghĩ xem mình có thể làm gì, làm như thế nào khi phải phát triển chức năng này, và tester sẽ biết được liệu có phần nào của chức năng hoặc một yêu cầu nào đó đối với chức năng đó có bị thiếu không. Sau đó kiểm tra code và có thể sẽ tìm ra lỗi.

3.4 Phải hiểu rõ về hệ thống

Tester phải có sự hiểu biết thật rõ về hệ thống để đảm bảo người đó có thể nghĩ ra và thử nhiều kịch bản khác nhau đối với hệ thống. Ad-hoc testing yêu cầu càng nhiều kịch bản càng tốt, và càng thực hiện được nhiều kịch bản thì khả năng tìm ra lỗi càng cao.

3.5 Kinh nghiệm của bản thân tester

Trong Ad-hoc testing, tester có kinh nghiệm bao giờ cũng tìm ra được nhiều lỗi hơn là người mới vì người đó đã từng test nhiều hệ thống khác nhau, cũng có thể là đã test những hệ thống tương tự nên thu thập được kinh nghiệm và sự hiểu biết để thực hiện Ad-hoc testing. Ghi chú, góp nhặt là phương pháp tốt để tích lũy kinh nghiệm

3.6 Test theo session

Hãy kiểm thử ứng dụng hay một phần mềm theo từng phần, tức là mỗi lần chỉ test một chức năng, nó sẽ giúp cho tester có thể chú trọng và lý giải được những vấn đề xảy ra (nếu có).

3.7 Học cách sử dụng những công cụ khác

Hiện nay có một số công cụ giúp tìm ra khiếm khuyết như công cụ debug, profilers hay task monitors, vì vậy học cách sử dụng những công cụ này có thể khiến cho vấn đề trở nên đơn giản hơn rất nhiều.

3.8 Ghi lại những gì đã tìm được

Hãy ghi lại những lỗi, khiếm khuyết mà mình tìm ta được, ghi rõ cả chức năng, khi nào thì lỗi xảy ra…Những record này sẽ giúp cho developer và cả tester trong tương lai khi họ phát triển những hệ thống hoặc ứng dụng khác. Cũng nên ghi lại những lỗi do người khác tìm ra chứ không phải mình tìm ra, để có cơ sở tham khảo về sau.

4. Kết luận:

Mặc dù thực hiện Ah-hoc testing là hoàn toàn ngẫu hứng nhưng người thực hiện cần phải có đủ kiến thức cũng như kinh nghiệm để phán đoán các kịch bản khác nhau có thể xảy ra với hệ thống hoặc ứng dụng, hoặc game đang cần test. Người thực hiện test cũng cần phải có hiểu biết chính xác và sâu sắc về đối tượng đang test để biết trường hợp nào là lỗi, khiếm khuyết do developer, do hành vi của người dùng, trường hợp nào là hạn chế của hệ thống (không thể khắc phục)…để có phương án cải thiện. 

(st)

Xem Chi tiết

CÁC LOẠI KIỂM THỬ HỌP ĐEN MÀ BẠN CẦN PHẢI BIẾT RÕ

Tiếp theo phần 1 trong topic học kiểm thử phần mềm  -bài  Tổng quan về Kiểm thử hợp đen và ưu nhược điểm. Sang phần 2, chúng ta sẽ cùng tìm hiểu các loại kiểm thử họp đen nhé

2. Các loại kiểm thử phần mềm hợp đen mà bạn cần phải biết  

2.1.   Kiểm thử tích hợp là gì?

            Integration test (kiểm thử tích hợp ) là  kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Hai mục tiêu chính của Integration Test:
 

·         Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

·         Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).

            Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

            Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể.

Có 3 loại kiểm thử hộp đen trong Integration Test:

·         Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm thử chức năng chỉ chú trọng đến chức năng của chương trình, mà không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.

·         Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ thống.
·         Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống.

2.2.   Kiểm thử hệ thống là gì ?

            Mục đích System Test ( kiểm thử hệ thống) là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

            System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.

            Điểm khác nhau then chốt giữa Integration Test (kiểm thử tích hợp )  và System Test ( kiểm thử hệ thống)  là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. 

Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.

            Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu.

            System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

            Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự án. Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm:

·         Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế dựa trên use case hoặc tính năng nghiệp vụ và nguyên tắc nghiệp vụ
·         Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn...
·         Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM...)...
·         Kiểm thử cấu hình (Configuration Test).
·         Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
·         Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến...

            Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

            Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào.

Xem Chi tiết

MÁCH BẠN ƯU NHƯỢC ĐIỂM CỦA KIỂM THỬ HỌP ĐEN VÀ CÁC PHƯƠNG PHÁP KIỂM THỬ HỌP ĐEN

1.    Tổng quan về kỹ thuật test hộp đen

            Trong quy trình kiểm thử phần mềm sử dụng chiến lược kiểm thử hộp đen gồm kiểm thử tích hợp và kiểm thử hệ thống.

            Vậy kiểm thử hợp đen trong kiểm thử phần mềm là gì và mục đích của Kiểm thử họp đen ?

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp đen”. 

Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó.

Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.

1.1.   Các phương pháp kiểm thử hộp đen

·         Phân lớp tương đương – Equivalence partitioning.

·         Phân tích giá trị biên – Boundary value analysis.

·         Kiểm thử mọi cặp – All-pairs testing.

·         Kiểm thử fuzz – Fuzz testing.

·         Kiểm thử dựa trên mô hình – Model-based testing.

·         Ma trận dấu vết – Traceability matrix.

·         Kiểm thử thăm dò – Exploratory testing.

·         Kiểm thử dựa trên đặc tả – Specification-base testing.

            Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

1.2.   Ưu, nhược điểm của kiểm thử họp đen

            Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. 

Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.

            Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

Xem thêm, Các loại kiểm thử phần mềm  họp đen 

Xem Chi tiết

Bài 3 : Tìm hiểu quy trình kiểm thử phần mềm

Học kiểm thử phần mềm 

 - Bài 3 : Tìm hiểu Quy trình SDLC , STLC sẽ  giải thích SDLC (Software Development Life-cycle/chu kỳ phát triển phần mềm) , Software Test Life Cycle - STLC ( Quy tắc kiểm thử) và một số mô hình kiểm thử thường áp dụng 

I. Tình huống 

- Gỉa sử Bạn/ Team bạn/ Công ty nhận một dự án phần mềm của một khách hàng . Việc phát triển  - Kiểm thử - Bàn giao sẽ trải qua các giai đoạn sau: 

1) Thu thập càng nhiều thông tin càng tốt về tất cả các yêu cầu cụ thể về kỷ thuật, logic, giao diện, mục đích sử dụng và các mong muốn khác. Càng cụ thể càng tốt . Đó là giai đoạn  THU THẬP YÊU CẦU PHẦN MỀM  (Requirement Analysis). 

Kiểm thử phần mềm sẽ phụ thuộc rất nhiều vào giai đoạn này và việc kiểm thử bắt đầu luôn tại đây. Những yêu cầu còn mơ hồ hoặc những thắc mắc phải được làm rõ để có 1 kết quả cụ thể nhất . Đây còn được gọi vui là giai đoạn lắng nghe, thấu hiểu và hỏi đáp . 

2) Từ những yêu cầu có được ở giai đoạn 1, Lập kế hoạch cho các ngôn ngữ lập trình như Java, php, .net ...Cơ Sở dữ liệu như Oracle, My SQL,SQL Server...để đáp ứng đầy đủ  với yêu cầu chức năng và yêu cầu kỷ thuật cho các chức năng hiện tại và những yêu cầu trong tương lai có thể được giải quyết. Đây là giai đoạn THIẾT KẾ (Software Architecture/Design). 

Giai đoạn này giúp các kiểm thử viên xác định lựa chọn tool và cài đặt môi trường thích hợp để thực hiện việc kiểm thử phần mềm

3) Sau khi đã có thiết kế, đội ngũ Developer sẽ thực hiện xây dựng phần mềm dựa trên những đặc tả thiết kế . Đây là giai đoạn CODING ( Development). 

Giai đoạn này QC/Tester thường ít " nhúng tay" vào mà để dev tự Unit test cho việc kiểm thử 

4) Tiếp đến,  thử nghiệm các chức năng được xây dựng ở giai đoạn 3  để xác minh rằng nó đúng với yêu cầu của khách hàng . Đây là giai đoạn KIỂM THỬ PHẦN MỀM (Software Testing) .

Giai đoạn chính trong kiểm thử , đây còn được gọi vui là bắt đầu càng quét bug sau những chuẩn bị ở giai đoạn 1,2,3 

5) Một khi sản phẩm phần mềm đã sẵn sàng, Việc bảo trì,nâng cấp để giải quyết các vấn đề nảy sinh hoặc các yêu cầu mới từ khách hàng . Đây sẽ là giai đoạn BẢO TRÌ (Maintenance) . 

Kiểm thử phần mềm ở giai đoạn này thực hiện việc báo cáo kết quả kiểm thử, đánh giá mức độ thân thiện và cập nhật testcase nếu có yêu cầu

II. Quy Trình phần mềm và Chu kỳ kiểm thử

1- Quy trình phần mềm

Những giai đoạn ở tình huống trên nằm trong chu kỳ phát triển phần mềm . 
Vậy quy trình phát triển phần mềm (SDLC) là gì? Nó là qui trình chung của một tổ chức, trình tự các hoạt động để phát triển 1 ứng dụng. 

Có rất nhiều quy trình phát triền phần mềm khác nhau như : Mô hình thác nước, mô hình chữ V, Mô hình xoắn ốc ...hoặc kết hợp các mô hình.

2-  Qui trình kiểm thử phần mềm (STLC) 

 Là những  hoạt động của QC -Tester Team để kiểm thử một ứng dụng phần mềm. Bao gồm: 

1)  Preparing the test strategy : Phương pháp kiểm thử tiếp cận, xác định chiến lược kiểm thử , tùy theo yêu cầu của khách hàng mà nên ưu tiên những vấn đề nào trước. Thường giai đoạn này ta sẽ tự đặt câu hỏi: Sẽ kiểm thử cái gì và kiểm thử như thế nào 

2) Preparing the test plan: Lập kế hoạch kiểm thử . Xác định và phân chia họp lý thời gian, nhân sự , các tool được sử dụng cho từng chắc năng 

3) Creating the test environment: Chuẩn bị môi trường, nền tảng cho công việc kiểm thử phần mềm, gồm Hệ điều hành(Win 7, win 8, linux , IOS...) , Trình duyệt (IE, Safari, Opera...), thiết bị ( Mobile, tablet, desktop...)

3)Write test cases/Test script: Viết testcase cho các trường họp sẽ test bao gồm cả 3 trường họp : True, Fail và không xác định kết quả ( case nảy sinh, không có trong tài liệu đặc tả (spec) . Viết test script nếu có dùng tool để thực hiện automation test cho test chức năng, giao diện hoặc các kịch bản 

4) Executing the test scripts/ test cases: Thực thi các case trong testcase/test scrips để thực hiện việc kiểm thử, quá trình này có thể có update thêm một số case còn thiếu (nếu có hoặc phát sinh thêm) 

5) Analyzing the results and reporting the bugs: Phân tích kết quả test để tìm hiểu nguyên nhân gây bug định hướng cách khắc phục đồng thời  post bug lên các bug tracking (Jira, mantis...) 

6) Doing regression testing : Test quy hồi sau khi bug đã được fixed. 

7) Test exiting: Kết thúc công việc kiểm thử - báo cáo hoặc ghi lại các kinh nghiệm đã gặp phải trong dự án này. Các vấn đề "can not fix" đồng thời thống kê lại số liệu các bug 

----------------------------------------------------------

http://kiemthuphanmemvvn.blogspot.com/

Face: https://www.facebook.com/KiemThuPhanMemVvn

Group: https://www.facebook.com/groups/1549328495322684/ 

Chọn "Đăng ký nhận bài qua mail" để nhận bài viết mới nhất nhé 

Học kiểm thử phần mềm tự đông 

Xem Chi tiết

Bài 2- 7 NGUYÊN TẮC QUAN TRỌNG TRONG KIỂM THỬ - BÍ KÍP "TRUY LÙNG BUG "

Đau đầu lớn nhất của kiểm thử viên chính là những bug tìm ẩn của ứng dụng. Làm thế nào để truy lùng hết các bug gây khó chịu cho người dùng. Một số phương châm chung cho kiểm thử phần mềm , gồm những nguyên tắc cơ bản sau đây:

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

Không fix bug triệt để  mà tránh né bug bằng cách sửa chức năng này thành chức năng khác không dùng được và không đáp ứng yêu cầu thiết kế , hoặc Fix bug tạm bợ để chương trình không có lỗi khi bàn giao cho khách hàng nhưng khi sử dụng một thời gian thì gây ra bug thì cũng như là thất bại mặc dù đã test xong

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

Việc kiểm thử phụ thuộc vào ngữ cảnh, và thực hiện kiểm tra với nhiều ngữ cảnh khác nhau
Ví dụ: Kiểm thử cho một chương trình tính toán , nếu là cấp 1 thì chỉ cần test cho các trường họp cộng trừ nhân chia là đủ , Nếu là cấp 2 thì chú trọng đến số mũ , căn bậc 2, phương trinh. Cấp 3 thì test đạo hảm, tích phân...

Nguyên tắc kiểm thử thứ 5 – Nghịch lý thuốc trừ sâu

Có người nói vui rằng kiểm thử là một nghệ thuật, đã là nghệ thuật thì phải có ý tưởng và cảm hứng, và đôi khi, cảm hứng cạn kiệt, không tìm thấy lỗi mới nào đối với những ca kiểm thử thông thường. Cũng giống như nếu ta cứ phun một loại thuốc trừ sâu với liều lượng như nhau thì một số loại sâu sẽ lờn thuốc, không được diệt sạch ( nên được gọi là nghịch lý thuốc trừ sâu), Để khắc phục, ta phải thường xuyên làm phong phú bộ testcase  và thực hiện nhiều trường họp để tránh trường họp này

Nguyên tắc kiểm thử thứ  4 – Sự tập trung của lỗi

Tập trung một cách cân đối vào mật độ dự kiến lỗi và lỗi phát hiện sau khi kiểm thử các moulde. Quáchú trọng  vào một hay một vài chức năng nào đó  thường gây ra thiếu sót vì thời gian release là có hạn,dành nhiều thời gian cho mô-đun này sẽ khó tránh khỏi việc không kịp kiểm thử full case cho các mô-đun khác . Và Một điều đặc biệt chú ý, nếu bug ở mô- đun này thì tất nhiên, chức năng tương tự hoặc liên quan ở mô-đun khác tất nhiên cũng sẽ bị lỗi,

Nguyên tắc kiểm thử thứ 3 – Kiểm thử sớm

Để phát hiện được lỗi sớm nhất có thể, kiểm thử nên bắt đầu từ giai đoạn đầu của dự án, giúp phát hiện sớm những rủi ro ngay từ giai đoạn đầu 

Nguyên tắc kiểm thử thứ 2 – Kiểm thử đầy đủ là không thể 

Kiểm thử tất cả các trường họp là không thể do yếu tố thời gian và chi phí, vì vậy việc phân tích các rủi ro và đưa ra mức độ ưu tiên để kiểm tra các trường họp cần thiết nhất, có khả năng gây ra lỗi nghiêm trọng nhất trước rồi sau đó, tùy thuộc vào tiến trình của dự án mà kiểm tra các trường họp còn lại theo mức độ ưu tiên thấp hơn 

Nguyên tắc kiểm thử đầu tiên  – Kiểm thử đưa ra lỗi

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng phần mềm không có lỗi. Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm, thậm chí là không còn lỗi nào, nó không phải là bằng chứng của sự chính xác.

Xem Chi tiết

Bài 1- Software testing là cái chi chi ???

1) Kiểm thử phần mềm là gì?
Kiểm Thử Phần Mềm  (Software testing ) đơn giản chỉ là đảm bảo phần mềm hoạt động đúng với mong muốn của khách hàng và trong quá trình sử dụng, chắc chắn không xảy ra khiếm khuyết ngoài ý muốn.

Vậy  công việc của Kiểm thử viên là gì ???? Rất đơn giản nhé , Chỉ có 2 việc :

Xem Chi tiết