Tổng quan về solfware testing

Nguồn: http://noteformyself.blogspot.com/

Chương 1: Tổng quan về test phần mềm      
 1.1 Các giai đoạn test       
1.2 Định nghĩa về test       
1.3 Mục tiêu của test       
1.4 Vai trò và nhiệm vụ của Tester.

Chương 2: Những yêu cầu cần thiết khi thực hiện test      
2.1 Ý nghĩa những tài liệu tester cần hiểu trước khi bắt đầu test      
2.2 Hướng test cụ thể trong phần mềm

Chương 3: Quy trình test     
Sơ đồ tổng quát.

Chương 4: Phương pháp test và kỹ thuật thiết kế testcase     
4.1 Phương pháp test     
4.2 Loại test     
4.3 Test case

Chương 5: Lỗi phổ biến trong phần mềm và cách Report Bug     
5.1 13 lỗi phổ biến trong phần mềm (Bug type).     
5.2 Report Bug Template.

Chương 6: Test Plan và thế nào là Tester tốt
A. TEST PLAN    
 I. Definitions:     
II. Some components of test plan:     
III. Main contents of a Test Plan:     
IV. Details of Main contents:
B.Thế nào là tester tốt.

Chương 1: Tổng quan về test phần mềm

Mục tiêu:

- Hiểu được những giai đọan test của  phần mềm.

- Hiểu đươc khái niệm về test phần mềm.

- Mục tiêu của test phần mềm.

- Hiểu đươc vai trò và nhiệm vụ của tester

1.1 Các giai đoạn test

Test Phase	Pre-Alpha	Alpha	Beta	Release
	Unit	Integration	System	User Acceptance
Performed by	Developer	Tester	Tester	Tester với tư cách người sử dụng cuối cùng
Goal	fix code, kiểm tra các hàm có chạy đúng không, tên biến đúng không...	Do tester thực hiện để tìm lỗi chức năng của ứng dụng và học về ứng dụng.	Do tester thực hiện xem các phần mềm có đáp ứng những yêu cầu hệ thống, khả năng bảo mật, chịu tải, chạy theo data flow, scenarios..	Do Tester thực hiện xem có đáp ứng những yêu cầu hay không.

1.2 Định nghĩa về test

-Test là một qui trình trải nghiệm phần mềm, từ đó tìm ra điểm yếu, rủi ro của phần mềm. Bảo đảm chất lượng và ổn định của phần mềm trước khi chuyển giao cho khách hàng.

1.3 Mục tiêu của test

Muc tiêu của việc test là tìm thấy càng nhiều vấn đề của phần mềm càng sớm càng tốt, đặc biệt là những lỗi nghiêm trọng, Tester giỏi sẽ tìm được nhiều lỗi được fix.

1.4 Vai trò và nhiệm vụ của Tester.

1.4.1 Vai trò

- Tìm bug và report bug.

- Xác định rủi ro của phần mềm.

- Hỗ trợ khách hàng trong việc sử dụng phần mềm.

- Đưa ra những quyết định nghiệp vụ cho bugs tìm thấy.

1.4.2 Nhiệm vụ

- Tìm ra vấn đề: tìm lỗi,  tìm những cách hiệu quả để tìm thấy lỗi.

-  Liên lạc :  báo cáo bugs, báo cáo quá trình test sản phẩm, báo cáo về sự ổn đinh của sản phẩm.  

- Nhiệm vụ khác: lập test plan và schedules, hướng dẫn tester khác tìm thấy bugs.

Chương 2: Những yêu cầu cần thiết khi thực hiện  test       

Mục tiêu:

- Hiểu những tài liệu liên quan đến phần mềm.

- Hiểu đươc nên test những gì trong phần mềm .

2.1 Ý nghĩa những tài liệu tester cần hiểu trước khi bắt đầu test

Thông thường sẽ có 3 loại tài liệu tester cần phải hiểu trước khi bắt đầu test.

Requirement documents : Những yêu cầu, mong muốn, suy nghĩ của khách hàng về phần mềm mà họ muốn.

Specification documents  : Những ý tưởng, dự định của chúng ta để hiện thực hóa những yêu cầu, mong muốn của khách hàng.

Design documents : Cụ thể, chi tiết  về việc chúng ta sẽ làm việc đó thế nào.

ví dụ:

Requirement documents : Khách hàng muốn chỉ có họ đươc sử dụng phần mềm này thôi

Specification documents  : Người dùng sẽ phải đăng nhập mật khẩu.

Design documents :  phải có 2 textfield username, password,  password phai dài 8 ký tự….

2.2 Hướng test cụ thể trong phần mềm

Functional Requirement ( yêu cầu chức năng ) : test theo những chức năng chính mà phần mềm cần phải có.

Non-functional Requirement ( yêu cầu phi chức năng ) : test những chức năng mà phần mềm nên có hoặc nên giống như thế. Gồm 3 loại non-functional:

- Look and feel (cảm giác người dùng ) : theo cảm giác của người sử dụng, thường đươc ưu tiên sau cùng vì không ảnh hưởng nhiều tới phần mềm  

- Boundary (biên) : kiểm tra những giới hạn có thể có của  phần mềm.

- Negative (bất thường): kiểm tra chuyện gì xảy ra khi không đi theo đúng quy luật phần mềm, đây là lọai test có thể tìm đươc những lỗi quan trọng, tùy vào kinh nghiệm của tester.

Ví dụ: A tới B tới C là bình thường, vậy điều gì xảy ra cho A tới C.     

Minh họa với Form login gồm có 2 fields username, password và một nút submit login.

Username	cybridge
Password	**********
	Login

Functional: User can login successfully with valid account.

(Chức năng chính là login thành công với valid account)

Look and feel: Login button is highlighted when hovering mouse over.

(Theo cảm giác của user thì button nên highlight khi con trỏ đi qua nó)

Boundary: User cannot input more than 20 characters to Username textbox.

(giới hạn biên tối đa là 20 ký tự đươc phép nhập)

Negative: Error message displays when user tries to login with space character in username textbox.

(khỏang trắng là ký tự bất thường mà ít người nghĩ tới và có thể gây nên lỗi)

Chương 3: Quy trình test

Mục tiêu:

Hiểu được quy trình test phần mềm.

Sơ đồ tổng quát.

Understand Requirement: Tester phải hiểu đươc những yêu cầu từ khách hàng và những gì mà developer sẽ thực hiện từ đó có thể định hướng là cần phải test những gì, [xem Chương 2 mục 2.1].

Test Approaches: Tester sẽ cân nhắc lựa chọn những phương pháp test phù hợp với dự án như là test theo Black-box hay  White-Box hay Gray-box.[ xem chương 4 muc 4.1].

Test Type: Tester cân nhắc lựa chọn những loại test cần phải thực hiện trong dự án như là requirement test, Smoke test, Monkey test, Regression test…

- Bug type: Đinh hướng tester cần tập trung tìm những loại bug gì vd: bug liên quan đến interface, hay bug liên quan giá trị biên…[chương 5 mục 5.1]

- Interface : Xác định những interface nào cần đươc test, mối liên quan của từng interface với nhau.

- Stability: Xác định độ ổn định của ứng dụng dựa trên tiêu chí nào, mức tối thiểu nào có thể chấp nhận ứng dụng trươc khi giao cho khách hàng.

Test Phases: Xác đinh những giai đọan nào sẽ bắt đầu quá trình test trong dự án [Xem chương 1 mục 1.1] ,  từ đó xác đinh thời gian, nhân sự, chuẩn bị cho việc test.

Design Method: Tạo ra những Form thống nhất , quy định về testcase, report bug nhằm chuẩn bị cho việc test đươc tiến hành ở những bước kế tiếp.

Test Tool: Lựa chọn Tool phục vụ cho việc test tự động vd nhự Quick test Pro Tool, Selenium,TestArchitec..

Test Plan: Quản lý tiến độ, phân công trong việc test dự án.

Test Case: Tạo ra những trường hợp cần phải test của ứng dụng.

Chương 4: Phương pháp test và kỹ thuật thiết kế testcase.

Mục tiêu:

- Giới thiệu những phương pháp test, loại test và làm thế nào để áp dụng vào việc test phần mềm.

- Giới thiệu về tescase và những kỹ thuật tạo ra testcase.

4.1 Phương pháp test

Glass-box testing: Tester thường là những programmer sẽ sử dụng kiến thức về lập trình, hiểu về sourcecode và cấu trúc bên trong của phần mềm.

Vd: kiểm tra từng chức năng mỗi hàm có lỗi không, hàm nào dư không sử dụng..

Black-box testing: Tester không cần biết bên dưới code là gì, chỉ quan tâm input và output để tạo ra testcase.

Ví du: Testcase cho form login vơi username and password.

Steps	Summary	input	output
1	Open login form
2	Enter a valid username	cybridge
3	Enter a valid password	12345
4	Submit		Welcome screen displays

Gray-box Tesing : Kết hợp Glass-box và Black-box testing để tạo ra testcase.

Ví dụ: testcase cho form login vơi username and password sử dụng kiến thức HTML.

Steps	Summary	input	output
1	Open login form
2	Enter HTML command in  username	</body>
3	Enter HTML command password	</html>
4	Submit		Welcome screen displays

4.2 Loại test

- Requirement Testing: Test dựa vào thông tin yêu cầu từ requirement , lập ra testcase cho mỗi yêu cầu .Bao gồm non-functinal testing và functional test [xem chương 2, mục 2.2]

- Smoke Testing: Loại test đươc thực hiện đầu tiên để xem phần mềm có sẵn sàng cho việc test chưa, có đủ môi trường cho việc test chưa.

vd: test xem phần mềm có install đươc trên winxp hay không...     

- Monkey Testing: Test dựa vào cảm tính, sáng tạo  để tìm ra lỗi, đây là loại test dễ tìm ra lỗi nhất.

- Regression Testing: Test độ ổn định của phần mềm sau khi developer fix lỗi, test lại những chức năng có liên quan đến những lỗi đã fix, đây là loại test đuơc thực hiện trong giai đọan sắp giao phần mềm cho khách hàng.

4.3 Test case

4.3.1 Tại sao phải viết test case.

- Tìm Bugs

- Không bị trùng lắp khi test.

- Không bị sót so với test theo cảm tính.

- Có thể tái sử dụng tiết kiệm thời gian test cho những project gần giống nhau.

- Testcase sẽ giúp bao phủ lỗi của phần mềm.

- Ước lượng đươc thời gian test.

- Việc test thưc thi chính xác hơn.

- Dùng để training cho tester mới.

4.3.2 Thành phần chính của test case.

- Testcase ID : Dùng để phân biệt các testcase với nhau.

- Summary : mô tả ngắn gọn mục đích của testcase, đây là thanh phần quan trọng nhất của testcase.

- Preconditions: Điều kiện tiên quyết để thực hiện testcase. ví dụ: phải có điện thoại FU mới test đươc chức năng FU trong Docomo.

- Steps: Hướng dẫn để thực hiện theo đúng mục đích của testcase.

- Expected result: Kết quả mong muốn ra khi chạy testcase.

- Observed Result: Kết quả thực tế quan sát đươc khi chạy testcase.

- Status: Passed, Failed, Blocked(không thể thực hiện theo các bươc để chạy testcase).

- Environment : Môi trường test của phần mềm, Firefox, Chrome, IE6,7,8,9…

- Note: Ghi chú của tester khi test.

- BugID: Ghi nhớ bug chỉ với  testcase bị failed.

Testcase mẫu:

Testcase_ID	Summary	Steps	Expectation	Observed	Status
UC_01	Welcone screen displays with valid account.	1.Lauch application 2.Input valid username. 3.Input valid password. 4.Click login button	‘Hello world’ message displays	No message displays	Failed

4.3.3 Kỹ thuật thiết kế  test case.

- Boundary Analysis (phân tích biên) : Tạo ra test case dựa vào điểm giới hạn, thông thường sẽ có 9 testcase cho điểm giới hạn.

Vd: Viết testcase cho textbox chỉ cho nhập số từ 1 đến 5 -999---------------------------0-[1]-2----------3-----------4-[5]-6-----------------------------------------999

Như vậy có 9 testcase tương ứng để kiểm tra trường hợp này: -999, 0, 1, 2, 3, 4, 5, 6, 999

- Constraint Analysis (phân tích ràng buộc): tạo ra testcase dựa vào ràng buộc dữ liệu.

Ví dụ: 2 text box yêu cầu nhập ngày bắt đầu và ngày kết thúc, Testcase ràng buộc là ngày bắt đầu không đươc lớn hơn ngày kết thúc.

- State Transition (chuyển trạng thái) : tạo ra testcase dựa vào mối quan hệ giữa hành động, sự kiện của một trạng thái này tác động đến một trạng thái khác, mỗi trạng thái sẽ là một testcase.

Ví dụ: Testcase cho đèn giao thông [ Xanh > Vàng > Đỏ] , mối quan hệ trạng thái là Xanh kết thúc sẽ tới Vàng, Vàng kết thúc sẽ tới Đỏ, Đỏ kết thúc sẽ tới Xanh.

1	Xanh	Vang	Do
2	Vang	Do	Xanh
3	Do	Xanh	Vang

- Condition combination (điều kiện phối hợp): tạo ra testcase dựa vào mối quan hệ phối hợp của những giá trị, mỗi điều kiện phối hợp sẽ là một testcase.

Vd:

- 1 list box A gồm các thành phần [ muối, đường, dấm ];

- 1 list box  B  gồm các thành phần [nước, trà, cafe ]

- 1 nút submit có tên phối hợp.

Mỗi sự phối hợp sẽ là 1 testcase.

Testcase_Id	Listbox A	Listbox B	Expected result
1	muối	nước	muối nước
2	muối	trà	muối trà
3	muối	cafe	muối cafe
4	đường	nước	đường nước
5	đường	trà	đường trà
6	đường	cafe	đường cafe
7	dấm	nước	dấm nước
8	dấm	trà	dấm trà
9	dấm	cafe	dấm cafe

Chương 5: Lỗi phổ biến trong phần mềm và cách Report Bug.

Mục tiêu:

Hiểu đươc những lỗi phổ biến trong phần mềm.

Hiểu đươc cách report bug.

5.1 13 lỗi phổ biến trong phần mềm (Bug type).

User Interface: Lỗi giao diện hiển thị khác với design

Error Handling: Xử lý lỗi sót và báo lỗi hệ thống ví dụ như lỗi 404 not found.

Boudary-Related : Lỗi vươt giới hạn input.

Calculation: Lỗi tính tóan sai.

Initial and Later State: Lỗi khởi tạo sai

Control Flow: Đi sai luồng xử lý.

Handling or Interpreting Data:Lỗi chuyển dữ liệu sai từ luồng này đến luồng khác.

Race Conditon: vd:yêu cầu thưc hiện 5 steps mới ra kết quả, nhưng 2 step đã ra.

Load Conditon: (đang cập nhật)

Hardware/Enviroment Compatibility: lỗi không tương thích phần mềm, phần cứng.

Source, Version: lỗi sử dụng sai phiên bản phần mềm.

Testing: lỗi do Tester test sai.

Documentation: Lỗi do tài liệu mô tả sai.  

5.2 Report Bug Template.

BugID : Phân biệt các bug với nhau.

Summary: Mô tả ngắn gọn về bug đươc tìm thấy.

Step to Reproduce: Bước để tái hiện bugs

Serverity: Mức độ nghiêm trọng của bug

- Critical: Bug cực kỳ nghiêm trọng không thể ship nếu không fix bug này.

- Serious: Bug xấu gây mất dữ liệu hoăc crash.

- Minor: Bug không nghiêm trọng có thể fix sau.

Frequency: Always, Often, Seldom.

Status: Tình trạng của bug

- New : Bug mới tìm thấy

- Fixed : Bug đã đươc sửa.

- Closed

- Not Reproduce: không thể tái hiện bug.

- To be fixed: Bug đang đươc sửa.

Expected result: Kết quả mong muốn.

Observed: Kết quả quan sát được.

Ví dụ:Template bug report.

BugID	Summary	Reproduce	Expected result	Obser result	Status
1	User can login with invalid account	1.Open application 2.input invalid account	Waring message displays	Wecome screen displays	New

Chương 6: Test Plan và thế nào là Tester tốt.

A. TEST PLAN

I. Definitions:

A document that describes the scope, approach, resources and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.

The main purpose of preparing a Test Plan is that everyone concerned with the project are in sync with regards to the scope, responsibilities, deadlines and deliverables for the project. It is in this respect that reviews and a sign-off are very important since it means that everyone is in

agreement of  the contents of the test plan and this also helps in case of any dispute during the

course of the project (especially between the developers and the testers).

A Test Plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.

II.  Some components of test plan:

1. Title of the document, project name, date create test plan, …

2. Identification of software including version/release numbers

3. Revision history of document including authors, dates, approvals

4. Table of Contents

5. Purpose of document, intended audience

6. Objective of testing effort

7. Software product overview

8. Relevant related document list, such as requirements, design documents, other test plans,…

9. Relevant standards or legal requirements

10. Traceability requirements

11. Relevant naming conventions and identifier conventions

12. Overall software project organization and personnel/contact-info/responsibilties

13. Test organization and personnel/contact-info/responsibilities

14. Assumptions and dependencies

15. Project risk analysis

16. Testing priorities and focus

17. Scope and limitations of testing

18. Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable

19. Outline of data input equivalence classes, boundary value analysis, error classes

20. Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems

21. Test environment validity analysis - differences between the test and production systems and their impact on test validity.

22. Test environment setup and configuration issues

23. Software migration processes

24. Software CM processes

25. Test data setup requirements

26. Database setup requirements

27. Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs

28. Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs

29. Test automation - justification and overview

30. Test tools to be used, including versions, patches,…

31. Test script/test code maintenance processes and version control

32. Problem tracking and resolution - tools and processes

33. Project test metrics to be used

34. Reporting requirements and testing deliverables

35. Software entrance and exit criteria

36. Initial sanity testing period and criteria

37. Test suspension and restart criteria

38. Personnel allocation

39. Personnel pre-training needs

40. Test site/location

41. Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues

42. Relevant proprietary, classified, security, and licensing issues.

43. Open issues

44. Appendix - glossary, acronyms,...

Depending on the specific project we use the items necessary to build a test plan in clear and details.

III. Main contents of a Test Plan:

1. Purpose

2. Scope

3. Test Approach

4. Entry Criteria

5. Resources

6. Tasks / Responsibilities

7. Exit Criteria

8. Schedules / Milestones

9. Hardware / Software Requirements

10. Risks & Mitigation Plans

11. Tools to be used

12. Deliverables

13. References

  a. Procedures

  b. Templates

  c. Standards/Guidelines

  d. Project related documents (RSD, ADD, FSD etc)

14. Annexure

15. Sign-Off

 

IV. Details of  Main contents:

1. Purpose: This section should contain the purpose of preparing the test plan

2. Scope: This section should talk about the areas of the application which are to be tested by the QA team and specify those areas which are definitely out of scope (screens, database, mainframe processes etc).

3. Test Approach: This would contain details on how the testing is to be performed and whether any specific strategy is to be followed (including configuration management).

4. Entry Criteria: This section explains the various steps to be performed before the start of a test (i.e.) pre-requisites. For example: Timely environment set up, starting the web server / app server, successful implementation of the latest build ...

5. Resources: This section should list out the people who would be involved in the project and their designation …

6. Tasks / Responsibilities: This section talks about the tasks to be performed and the responsibilities assigned to the various members in the project.

7. Exit criteria: Contains tasks like bringing down the system / server, restoring system to pre-test environment, database refresh ...

8. Schedules / Milestones: This sections deals with the final delivery date and the various milestone dates to be met in the course of the project.

9. Hardware / Software Requirements: This section would contain the details of PC’s / servers required (with the configuration) to install the application or perform the testing; specific software that needs to be installed on the systems to get the application running or to connect to the database; connectivity related issues etc.

10. Risks & Mitigation Plans: This section should list out all the possible risks that can arise during the testing and the mitigation plans that the QA team plans to implement incase the risk actually turns into a reality.

11. Tools to be used: This would list out the testing tools or utilities (if any) that are to be used in the project (e.g.) WinRunner, Test Director, PCOM, WinSQL.

12. Deliverables: This section contains the various deliverables that are due to the client at various points of time (i.e.) daily, weekly, start of the project, end of the project etc. These could include Test Plans, Test Procedure, Test Matrices, Status Reports, Test Scripts etc. Templates for all these could also be attached.

13. References:

  a. Procedures

  b. Templates (Client Specific or otherwise)

  c. Standards / Guidelines (e.g.) QView

        d. Project related documents (SRS, RSD, ADD, FSD etc)

14. Annexure: This could contain embedded documents or links to documents which have been / will be used in the course of testing (e.g.) templates used for reports, test cases ... Referenced documents can also be attached here.

15. Sign-Off: This should contain the mutual agreement between the client and the QA team with both leads / managers signing off their agreement on the Test Plan.

B.Thế nào là tester tốt.

- Là người thực sự đam mê, và khát vọng trở thành một 1 tester chuyên nghiệp, đồng thời cũng có đầy đủ tố chất để trở thành tester như: tỉ mỉ, cẩn thẩn, luôn đặt ra câu hỏi, luôn tò mò và ham học...

- Là 1 tester tự tin và thể hiện rõ khả năng trong việc tìm ra lỗi, không chỉ về số lượng mà còn cả chất lượng

- Là một tester luôn hoàn thành tốt công việc của mình trong mọi hoàn cảnh, và luôn giúp đỡ đồng nghiệp trong công việc.

Nguồn: http://noteformyself.blogspot.com/