软件质量保证复习总结大纲及问题

Module1 《软件工程实践》

1、软件工程实践通过解决问题的根源来指导软件开发。

2、软件工程实践之间相辅相成。

3、过程指导一个团队在什么时候做什么以及如何做。

4、软件工程过程为实现软件工程实践提供了上下文和支持。

Module2 《软件质量》

1、什么是Quality？

软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的和隐含特征相一致的程度。

2、都有谁是Stakeholders？

用户、客户、开发人员、销售人员、上层管理

3、什么是Defect？

Stakeholders眼中的缺陷可以包括任何使程序具有更低价值的程序。

4、Quality的维度都有哪一些？(FURPS)

1) Functionality

2) Usablity

3) Reliability

4) Performance

5) Supportability

5、什么是SQA?

SQA是Software Quality Assurance。

一套系统的、有计划的行动，以保证软件系统产品的软件开发过程或维护过程符合既定的功能和技术要求，

以及保持进度和在预算范围内操作的管理要求。

6、SQA都包含那些组件？

1）工作项目前期工作质量组件 Pre-project quality components

2）项目生命周期质量组件 Project life cycle quality components

3）基础设施错误预防和改进组件  Infrastructure error preventive and improvement components

4）软件质量管理组件 Software quality management components

5）标准化、认证和SQA评估组件 Standardization, certification and SQA assessment components

6）组织SQA人类组件 Organizing for SQA the human components

Module3 《软件测试导论》

-1、推荐的程序是使用黑盒方法开发测试用例，然后用白盒方法开发辅助测试用例。

0、 Testing is the process of executing a program with the intent of finding errors.

1、什么是Software Testing？

软件测试是一个过程，或者是一系列的过程，目的是确保计算机代码做它被所设计来做的事情，

并且它不会做任何意想不到的事情。

2、软件测试的Models是什么？

1) V模型（一般开发过程为古老的瀑布模型）

仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段 ；

忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。（缺陷）

2) W模型

测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。（缺陷）

测试的活动与软件开发同步进行；　测试的对象不仅仅是程序，还包括需求和设计； 　　尽早发现软件缺陷可降低软件开发的成本。（优点）

3、 什么是功能性(Functional)测试？

功能性测试是一种对除性能以外的软件外可见的或可测量的属性感兴趣的测试，在功能性测试中，我们把程序看成是一组功能的集合。

4、什么是测试思想(Test Ideas)？

一个测试的想法是一个简短的陈述，用来确定一个可能有用的测试。

5、测试思想(Test Ideas)与测试用例(Test Case)的区别？

测试思想与测试用例不同，测试思想不包含测试工作的规范，只是测试背后思想的本质。

测试思想是测试用例的生成器:潜在的测试用例来自于测试思想列表。

6、测试思想(Test Ideas)在什么地方有用处？

暂定

7、给出一些测试思想的例子。

8、什么是Test-Ideas Catalog？

测试思想目录是在许多情况下可用的相关测试思想的列表。

9、说明a catalog of测试思想如何应用到测试矩阵(Test Matrix)上?

（列表头是测试思想，行表头是输入框）

Module4 《RUP测试规程》

1、什么是“统一软件开发过程”(RUP-Rational Unified Process)?

Rational统一过程(Rational Unified Process,RUP)是一个软件工程过程框架，它

为在软件开发组织中分配任务和职责提供了一个有序而灵活的方法。

2、RUP's goal:

在可预测的进度和预算中生产满足最终用户需求的高质量软件。

3、 RUP的4个阶段

1) Inception(初始阶段)

2) Elaboration(细化阶段)

3) Construction(构造阶段)

4) Transition(交付阶段)

4、里程碑

5、角色、活动、工件。

角色:一组相关的职责，可以分配给开发组织中的个人或团队。

活动:一个角色可以被要求执行的工作单元。

工件:一种活动产生、修改或使用的信息。

6、测试中的角色

1) Test Manager(测试经理) 测试经理角色的任务是负责测试工作的成功。

2) Test Analyst(测试分析师)  测试分析人员角色负责最初确定和定义所需的测试，然后评估测试工作的结果。

3) Test Designer(测试设计人员) 测试设计人员角色负责定义测试方法并确保其成功实现。

4) Tester (测试人员)  测试人员角色负责测试工作的核心活动，包括进行必要的测试并记录测试结果。

7、RUP测试过程工作流（The RUP Test Discipline Workflow）

1)  Define Evaluation Mission 定义评估任务

2) Test and Evaluate 测试和评估

3) Achieve Acceptable Mission 达成可接受的任务

4) Verify Test Approach  验证测试方法 

5) Validate Build Stability 验证构建稳定性

6) Improve Test Assets  改进测试资产

8、RUP Test Discipline总结：

1) 提出了可迭代的测试过程

2) 可伸缩和可定制

3) 灵活性

Module 5 《定义评估任务》

-1、什么是 Evaluation Mission？

定义测试的目标、范围、边界，给出所用的测试方法，定义如何监视评估测试过程。

0、测试的目的(Purpose)？

1）找Bug。

2）评估产品的整体状况。

1、什么是测试任务(Test Mission)?

Find defects
Maximize bug count
Block premature product releases
Help managers make ship / no-ship decisions
Assess quality
Minimize technical support costs
Conform to regulations
Minimize safety-related lawsuit risk
Assess conformance to specification
Find safe scenarios for use of the product (find
ways to get it to work, in spite of the bugs)
Verify correctness of the product
Assure quality

2、 什么是一个好的测试方法(Approach)?

1）Diversified  多样化的
2）Risk-focused 关注风险的
3）Product-specific 产品特异
4）Practical 现实的
5）Defensible 可辩解的

3.0、测试文档

1）Test Plan

2）Test-design specification

3）Test-case specification

4）Test-proprocedure specification

5）Test-item transmittal report

6）Test-log

3、什么是测试文档(Test Documentation Mission)的目标?

a）测试文档集将主要支持我们在这个版本中发现bug、委派工作和跟踪状态。

b）测试文档集将支持持续的产品和测试维护至少10年，将为新成员提供培训材料，并将创建适合于管理或诉讼使用的档案。

Module 6 《测试&评估》

1、有关测试(Test)

1）对于每个测试周期，该工作主要集中在:在测试和评估工作中达到适当的广度和深度。

2）这是测试周期的核心，测试本身并分析结果。

2、测试技术的5个维度。

1）Testers（测试人员）

2）Coverage（测试什么）

3）Potential Problems（潜在问题）

4）Activities（活动）

5）Evaluation（评估）

3、十种测试方法

1）Function testing 功能测试

Coverage：每个功能和用户可见的变量。

Testers：Any

盲点：没有考虑功能间的交互。

评估：只要能工作就行。

2）Equivalence analysis 等价类划分

Coverage：所有的数据字段

Testers：Any

潜在问题：数据、配置、错误处理。

优点：a）用较小的测试用例集合找出最可能的缺陷。b）方法直观，概括性好。

盲点：边界或明显特殊情况下的错误。以及取值集合实际上不可知。

步骤：a）确定等价类 b）定义测试用例

评估：取决于数据选取。

3）Specification-based testing 基于规格说明书的测试

Tag Line：验证每个需求。

Coverage：文档需求、特性。

Testers：Any

Activities：编写和执行基于spec的测试。审查和跟踪管理文档。

评估：行为符合sepc吗。

优点：有效管理规则驱动测试的范围。降低了技术支持成本和客户抱怨。

盲点：没有出现在规格说明书中或者记录不准确的。

*用户手册、软件备忘录、产品资料等可以作为缺少spec时的替代品。

4）Risk-based testing 基于风险测试

3key meanings：

1>找到缺陷 2>管理找缺陷过程 3>管理测试项目以及由测试与整个项目的关系导致的风险。

Testers：Any

目标：按优先级排序，根据我们可以测试的问题的相对风险来改进测试

Activities：使用【服务质量】、【风险启发式】和【缺陷模式】来识别风险

优点：最佳优先级，大功率测试。

缺点：不确定的风险可能更容易发生风险。测试人员主观性太强。

5）Stress testing 压力测试

Testers:Specialists

Activites：创建自动化测试套件，并针对每个(主要)构建运行

Evaluation：Varies

优点：暴露风险，暴露安全中出现的弱点。

缺点：压力测试不会明显暴露的一些缺陷测不到。

6）Regression testing 回归测试

tag：变革后的自动测试

目标：发现软件变化后不可预见的错误。

Testers：Varies

优点：执行成本低，配置化测试，监管友好。

坏处：**维护回归测试套件的成本。

7）Exploratory testing 探索性测试

tag：同时学习，计划和测试

目标：同时了解产品及其测试策略，以揭示产品及其缺陷

Activites：学习、计划、测试

优点：以风险为中心，以客户为中心。适应不断变化的环境。查找其他的遗漏错误。

缺点：富有技巧性。受限于测试者的弱点。

Testers：Explorers

8）User testing 用户测试

目标：整个系统上识别错误。

Testers：Users

Coverge：很难度量

Activites：直接由用户进行

评估：由用户进行评估。

缺陷百分比= 100*（1-（1-L）^n）

n是用户人数，L是一个用户找问题的概率。

9）Scenario testing 情景测试

目标：用具有挑战性的案例来反应真实适用情况。

潜在问题：经验丰富的用户使用的复杂交互。

Activites：Interview Stakeholders，write screenplays。

Testers:any

Coverage：故事触及到的地方。

优点：可以处理过于复杂的情况。随着时间推移暴露缺陷。

缺点：单功能缺陷使得测试效率低下。必须仔细考虑才能达到良好的覆盖率。

理想场景有4个特征：

a）realistic

b）easy to evaluate 容易评估测试通过与否

c）complex

d）测试不通过这个场景就会有stakeholder表示抗议。

10）Stochastic or Random testing 随机测试

Coverage：Broad but Shaddow

Testers：Machines

Activites：Focus on test generation

Evaluation：基于状态的

4、测试技术在项目开发中不断改变。

5、path testing

白盒测试、结构性测试、基于代码的测试、可以严格定义和数学分析

6、覆盖结构性指标

1）DD-path路径覆盖 （decision-to-decision path）判定到判定路径

2）路径覆盖

3）点覆盖（语句覆盖）

4）边覆盖

5）分支覆盖

Module 7 《Analyze Test Failures》

1、Evaluate： This module focuses on the activity Analyze Test Failures

2、变更请求（request change）的目的是什么？

变更:任何事件、缺陷或潜在改进报告要求对正在开发的软件进行更改请求。

3、缺陷报告：缺陷报告是用来说服某人分配时间和精力来修复bug的工具。

1）Visibility  可见性

2）Effectiveness  有效性

4、缺陷报告格式：

1）报告ID

2）报告人

3）报告日期

4）测试项

5）版本号

6）前置条件

7）可否重现

8）严重程度

9）优先级

10）报告类型（例如编码错误、设计问题、文档查询）

11）摘要

12）关键词

13）复现步骤

14）建议解决方案

15）状态（Open\closed）

16）解决方案

17）解决方案版本

18）解决者

19）解决方案测试：

20）变更版本

21）评论

22）小结

5、高级测试人员评审提交的缺陷，然后标记为Open并分配给开发人员。

Module 8 《Achieve Acceptable Mission》

1、目的：

我们将实时监控正在实现的任务，并报告测试工作的状态。

为测试工作的利益相关者提供一个有用的评估结果。

2、在每个测试周期中，工作关注：

1）积极地优先考虑必须进行的最低限度的测试，以完成评估任务。

2）主张解决对评价任务有重大负面影响的重要问题。

3）提倡适当的质量。

4）在适当的情况下，根据评估结果修改评估任务，以便向项目团队提供有用的信息。

3、Status Reporting 的维度

1）Product

2）Plan

3）Results

4）Effort

5）Obstacles

6）Risk

7）Quality of Testing

8）History across projects

4、常见报告的总体结构

1）Part1：Risks and responsibilities （风险和责任）

2）Part2：Progress against plan or multidimensional chart （违反计划的过程或多维图表）

3）part3：Project bug metrics （项目bug度量 ;bug发现曲线）

4）part4：Deferred and no-change change requests（延迟和不改变“变更请求”）

5、保持测试报告频繁提交、简单并且易于理解。

6、选择一个合适的方法来度量测试范围。

7、使用标准的报告格式使得重点鲜明。

8、“DashBoard”是一个有用的总结工具。

Module 9 《测试&评估》

1、Veryfy Test Approach（验证测试方法）目的

达到适当的广度和深度的测试工作，以便对目标测试项目进行充分的评估

关注点：

1）Definition of the workflow detail 工作流细节定义

2）Checking whether your approach is workable 检查方法是否可行

3）Considerations for testability 考虑可测试性

可测性包括a）Visibility b）Control

2、风险分析是RUP中的一个基本活动。

3、Validate Build Stability （验证构建稳定性），目的：验证构建是否可以被测试/评估。这有助于防止浪费的测试工作。

重要：

1）Bad builds can waste an enormous amount。

2）构建验证是配置管理过程的一部分，可以防止带有错误组件的版本。

3）频繁进行构建是一个有价值的风险管理活动。

of testing time

4、Validate Build Stability：

This work is also referred to as a smoke test, build verification test, build regression test,sanity check or acceptance into testing.

译文：这项工作也被称为烟雾测试、建立验证测试、构建回归测试、完整性检查或验收测试。

5、Improve Test Assets：维护和改进测试资产。

这一点很重要，特别是如果意图是在随后的测试周期中重用当前测试周期中开发的资产

6、测试资产都有哪些？

Test data

Test script

Test suite

Test automation architecture

Test environment configuration

Test plan

Test evaluation summary

7、 Iterations are the “heartbeat” or rhythm of the project and a governing principle for testing in RUP.

译文：迭代是项目的心跳节奏，是RUP中测试的指导原则。

8、Each Build Is a Candidate for a Cycle of Testing。