上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)第4章 Fundamental theory and methods of software test

上游充通大 SHANGHAI JIAO TONG UNIVERSITY 1896 1935 1987 ,2006 Chapter 4 Fundamental theory and methods of software test
¾1896 ¾1935 ¾1987 ¾2006 Chapter 4 Fundamental theory and methods of software test

© 4.1 Non-execution based Verification 4.2 Execution based Verification 4.3 Formal verification 4.4 Other methods >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President 4.1 Non-execution based Verification 4.2 Execution based Verification 4.3 Formal verification 4.4 Other methods

图 4.1 Non-execution based Verification Not execute the program, tester could use some tools to review and analyze the specification and program code. walk through Inspection >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President 4.1 Non-execution based Verification Not execute the program, tester could use some tools to review and analyze the specification and program code. walk through Inspection

③ 4.1.1 Walk through -Consist a walk through test group -Check program code logic -Generate test case,include input data and expect result. -Put the data into program code,if the calculate result unequal the expect result. find an error. -Check the code line by line. >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President 4.1.1 Walk through —Consist a walk through test group —Check program code logic —Generate test case, include input data and expect result. —Put the data into program code, if the calculate result unequal the expect result, find an error. —Check the code line by line

The walkthrough team should consist of four to six individuals,including at least a representative and the manager of the phase being tested (implementation),a representative of the team that will perform the next phase in the product's life cycle(integration testing), and a client representative. The team should be chaired by a member of the SQA group,because SQA is the group in the developer's organization that has the greatest stake in assuring the correctness of the code.Participants should receive material in advance of the walkthrough and prepare lists of items they do not understand and items they believe to be incorrect. >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President The walkthrough team should consist of four to six individuals, including at least a representative and the manager of the phase being tested (implementation), a representative of the team that will perform the next phase in the product’s life cycle (integration testing), and a client representative. The team should be chaired by a member of the SQA group, because SQA is the group in the developer’s organization that has the greatest stake in assuring the correctness of the code. Participants should receive material in advance of the walkthrough and prepare lists of items they do not understand and items they believe to be incorrect

The goal of the walkthrough team is to detect faults,not to correct them.The person leading the walkthrough guides the other members of the team through the code.The walkthrough can be driven by the lists of issues compiled by team members or by the code itself,with team members raising their concerns at the appropriate time.In both cases,each issue will be discussed as it comes up and resolved into either a fault that needs to be addressed or a point of confusion that will be cleared up in the discussion >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President The goal of the walkthrough team is to detect faults, not to correct them. The person leading the walkthrough guides the other members of the team through the code. The walkthrough can be driven by the lists of issues compiled by team members or by the code itself, with team members raising their concerns at the appropriate time. In both cases, each issue will be discussed as it comes up and resolved into either a fault that needs to be addressed or a point of confusion that will be cleared up in the discussion

4.1.2 Inspection An inspection is a far more formal activity than a code walkthrough.It is conducted by a team of three to six people that includes representatives from the group responsible for the current phase (implementation, testing)and representatives from the next phase or phases (integration testing).One member of the team plays the role of moderator(缓和剂),leading and managing the team.Another team member is the recorder,who writes down the faults found during the inspection. >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President 4.1.2 Inspection An inspection is a far more formal activity than a code walkthrough. It is conducted by a team of three to six people that includes representatives from the group responsible for the current phase (implementation, testing) and representatives from the next phase or phases (integration testing). One member of the team plays the role of moderator(缓和剂), leading and managing the team. Another team member is the recorder, who writes down the faults found during the inspection

The review process consists of five formal steps: In the overview step,the author of the module gives a presentation to the team. In the preparation step,the participants try to understand the code in detail and compile lists of issues,ranked in order of severity(严重性).They are aided in this process by a checklist of potential faults for which to be on the lookout. In the inspection step,a thorough walkthrough of the code is performed,aiming for fault detection through complete coverage of the code.Within a day of the inspection,the moderator produces a meticulous(小心翼翼)written report. In the rework step,the individual responsible for the code resolves all faults and issues noted in the written report. In the follow-up step,the moderator must make sure that each issue has been resolved by either fixing the code or clarifying confusing points. >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President The review process consists of five formal steps: In the overview step, the author of the module gives a presentation to the team. In the preparation step, the participants try to understand the code in detail and compile lists of issues, ranked in order of severity(严重性). They are aided in this process by a checklist of potential faults for which to be on the lookout. In the inspection step, a thorough walkthrough of the code is performed, aiming for fault detection through complete coverage of the code. Within a day of the inspection, the moderator produces a meticulous(小心翼翼) written report. In the rework step, the individual responsible for the code resolves all faults and issues noted in the written report. In the follow-up step, the moderator must make sure that each issue has been resolved by either fixing the code or clarifying confusing points

An important product of an inspection is the number and kinds of faults found rated by severity.If a module comes through an inspection exhibiting a significantly larger number of faults than other modules in the system,it is a good candidate for rewriting. If the inspection of two or three modules reveals a large number of errors of specific types,this may warrant (re)checking other modules for similar errors.A detailed breakdown of types,severity,and number of errors found will also help in conducting a second inspection of the module later. If more than 5 percent of the material inspected must be reworked,the team must reconvene for a full re- inspection. >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President An important product of an inspection is the number and kinds of faults found rated by severity. If a module comes through an inspection exhibiting a significantly larger number of faults than other modules in the system, it is a good candidate for rewriting. If the inspection of two or three modules reveals a large number of errors of specific types, this may warrant (re)checking other modules for similar errors. A detailed breakdown of types, severity, and number of errors found will also help in conducting a second inspection of the module later. If more than 5 percent of the material inspected must be reworked, the team must reconvene for a full reinspection

4.2 Execution-based Verification Use test cases to execute the program,get all results from the execution. There are two basic approaches to testing modules,each with its own weaknesses. Testing to Specifications,also known as black-box test. Testing to Code,also called glass-box white-box test. >校长办公室 >Office of the President
¾校长办公室 ¾Office of the President 4.2 Execution-based Verification Use test cases to execute the program, get all results from the execution. There are two basic approaches to testing modules, each with its own weaknesses. • Testing to Specifications, also known as black-box test. • Testing to Code, also called glass-box, white-box test
按次数下载不扣除下载券;
注册用户24小时内重复下载只扣除一次;
顺序:VIP每日次数-->可用次数-->下载券;
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)第2章 Prerequisites Mathematics knowledge of software test.pdf
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)第3章 Test environment and tools.pdf
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)第1章 Introduction of software testing.pdf
- 《软件工程概论》课程教学资源(参考资料)软件工程知识体系指南(2004版).pdf
- 《软件工程概论》课程教学资源(参考资料)Guide to the Software Engineering Body of Knowledge(SWEBOK)Version 3.0.pdf
- 中华人民共和国国家标准(GB/T8567一2006 代替GB/T8567-1988)计算机软件文档编制规范 Specification for computer software documentation.pdf
- 上海交通大学:《理论力学》课程教学资源(PPT讲稿)平面矢量.ppt
- 上海交通大学:《计算机硬件技术》课程PPT教学课件(计算机概论,孙德文).ppt
- 上海交通大学:《程序设计基础》课程教学资源(PPT课件讲稿)第9章 数据封装——结构体.ppt
- 上海交通大学:《程序设计基础》课程教学资源(PPT课件讲稿)第8章 间接访问——指针.ppt
- 上海交通大学:《程序设计基础》课程教学资源(PPT课件讲稿)第7章 数组.ppt
- 上海交通大学:《程序设计基础》课程教学资源(PPT课件讲稿)第6章 过程封装——函数.ppt
- 上海交通大学:《程序设计基础》课程教学资源(PPT课件讲稿)第4-5章 控制结构.ppt
- 上海交通大学:《程序设计基础》课程教学资源(PPT课件讲稿)第1-2章 计算机简介、C++编程入门.ppt
- 上海交通大学:《程序设计基础》课程教学讲义(密西根学院)Sample Exam Questions_Midterm 2008 sample.pdf
- 上海交通大学:《程序设计基础》课程教学讲义(密西根学院)Sample Exam Questions_midterm 2 sample solution.pdf
- 上海交通大学:《程序设计基础》课程教学讲义(密西根学院)Recitation Notes_recitation 14.pdf
- 上海交通大学:《程序设计基础》课程教学讲义(密西根学院)Recitation Notes_Recitation 11.pdf
- 上海交通大学:《程序设计基础》课程教学讲义(密西根学院)Other Resources_intrduction to computer and programming with C++ and MATLAB.pdf
- 上海交通大学:《程序设计基础》课程教学讲义(密西根学院)Assignments_assignment13.pdf
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)Chapter 2 fundamentals of software test.pdf
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)chapter 1 Introduction of software testing.pdf
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)教学大纲(高级软件测试).doc
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)chapter 3 Test environment and tools.pdf
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)Chapter 2 fundamentals of software test.pdf
- 上海交通大学:《软件测试与质量控制》课程教学资源(课件讲稿)chapter 4 test case generation 1.pdf
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)01 Introduction to Object Technology.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)02 Introduction to Visual Modeling.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)04 Interaction Diagrams.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)05 ClassDiagrams.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)06 Other UML Diagrams.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)07 Design Pattern.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)08 Requirements Overview.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)09 Analysis and Design Overview.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)10 Architectural Analysis.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)11 Use-Case Analysis.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)12 Architecture Design.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)13 Use-Case Design.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)14 Subsystem Design.ppt
- 上海交通大学:《面向对象分析与设计 Object Oriented Analysis and Design》课程教学资源(PPT课件讲稿)16 Database Design.ppt