一、QC的需求管理

1、  好需求的特征：

一致性：与其它软件需求或者高层（系统、业务）需求不相矛盾

准确性：用自然语言明确唯一的描述需求

完整性：完整的描述需求所完成的功能

可测试性：可以建立一个过多个测试用力来覆盖需求的所有方面

 

2、需求规范的流程：

   定义需求范围（功能测试、性能测试、界面测试、兼容性测试…）

   创建需求测试大纲；

   细化需求（细化到最小的点，如登陆功能的用户名、密码的输入）

   分析需求（考虑优先级）

 

3、  如何添加需求：

建立需求框架：填写需求名称和目的，组织整个需求的结构

细化每个需求：统一需求的描述方式，填写所有字段

需求评审：组织相关人员对需求进行评审，更改需求的状态为“已复查”

   分析测试结果

 

4、什么是测试集：一组为了完成某一目的的测试用例的集合

本章重点：

 

一、测试执行根据：《测试需求文档》《测试计划》《测试执行测试》《测试用例》

 

二、测试执行计划

执行计划是确保正常的实施测试活动

包含内容：

注意考虑：1.测试执行的轮次安排

2.测试执行的时间安排（参考程序发布计划）

 3.测试执行的人员分配

4.测试执行的环境要求和搭建

 

三、测试执行记录

•          做测试执行记录原因？

1.保证测试工作的可追溯性

2.记录测试人员的工作情况

3.绩效评估的重要数据

•          记录的内容

1.什么人－－测试执行人员

2.在什么时候－DATE

3.做了什么－－Case ID

4.结果如何－（Pass/fail ）

四、执行测试过程

1.设置测试环境，确保所需的全部构件（硬件、软件、工具、数据等）都已实施并处于测试环境中

2.将测试环境初始化，以确保所有构件都处于正确的初始状态，可以开始测试

 

八、测试执行活动结束或终止

1.正常终止：所有测试过程（或脚本）按预期方式执行至结束。

–         如果测试正常结束，则核实测试结果

2.异常或提前结束：测试过程（或脚本）没有按预期方式执行或没有完全执行。当测异常终止时，测试结果可能不可靠。在执行任何其他测试活动前，应确定并解决异常/ 提前终止的原因然后重新执行测试。

–         如果测试异常终止，则恢复暂停的测试

 

九、核实测试结果，真正的缺陷：

1.通常发生在实际结果与预期结果不匹配时

2.意外的GUI窗口（图形界面）

3.业务流程错误

 

十一、测试执行准备

1. 执行前，动员工作：阐述策略，回答问题，定义测试计划、测试范围
2. 严格审查测试环境，包括硬件、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本
3. 将测试用例分类进行有效整合，构造测试套件（test Suite）
4. 所有测试用例、测试套件、测试任务和测试执行结果通过测试管理系统进行管理，使测试执行的操作、过程记录在案，能跟踪、控制和追溯，保证测试进度和质量
5. 确保每个测试人员理解测试策略、测试目标，对测试进程进行审查，确保测试策略得到执行，可奖励手段，测试经理、组长要勇于承担风险，使测试人员有发挥、想象的空间，但同时也施加压力，提高工作效率和责任心

十二、测试执行过程

1.     记录测试记录，用例的执行状态使pass/fail

2.     记录缺陷报告捕获测试结果，提交给上级审查及实现人员进行修复

3.     缺陷跟踪和管理一般由特定工具来执行，对各模块、各测试人员、整体项目等进行事实跟踪。

4.     进行常规的缺陷审查，包括BUG的严重性、BUG的描述、BUG修正等

5.     对每个阶段测试结果进行分析，保证阶段性的测试任务得到完整的执行并达到预定的目标

6.     良好的沟通，测试人员之间，与项目组之间保持有效的沟通，如每周例会，可以及时发现测试中问题。

十四、常用测试工具简介

1)       WinRunner：企业级功能测试工具，自动录制、检测和回放用户的应用操作，有效的帮助测试人员对复杂的企业级应用的不同发布版本进行测试，提高工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行

2)       loadRunner：预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及时性能检测的方式来确认和查找问题，能对整个企业架构进行测试。能最大限度的缩短测试时间，优化性能和加速应用系统的发布周期。

本章重点：

 

1、BUG的产生

1)       软件的复杂性：功能越多，软件越复杂。

2)       程序员的错误：过于疲劳，不守规矩，过于热心，心不在焉。

3)       需求的变化：需求变化的后果会造成重新设计与日程调整，一个需求变化频繁的项目或者产品是没有任何测试价值的。

4)       时间的压力：时间是一种宝贵的资源。

5)       文档贫乏：要有良好的先文档后实现的习惯。文档代表着一种特殊的记忆，没有它的存在对人对己都不利。

6)       软件开发工具：实际上，现代的开发工具对整个软件质量尤其是可靠性并没有什么重大的影响。

 

2、BUG的种类

1)       需求阶段的BUG

2)       分析，设计阶段的BUG

3)       实现阶段的ＢＵＧ【主要发生在开发人员的身上】

4)       配置阶段的ＢＵＧ

5)       短视将来的ＢＵＧ

6)       静态文档的B U G

 

3、BUG的生命周期

1)       BUG的初始状态（Unconfirmed&New）

2)       BUG的分配状态（Assigned）

3)       BUG的重新分配状态（Ressigned）

4)       BUG修复状态（Resolved&Fixed）

5)       BUG验证状态（Vertified）

6)       BUG重新打开状态（）

7)       BUG关闭状态（）

 

4、BUG的严重等级

1)       危机的（Critical）

2)       重大的（Grave）

3)       严重的（）

4)       锁定的（Blocker）

5)       重要的（Important）

6)       常规的（Normal）

7)       轻微的（Minor）

8)       微不足道的（Trivial）

 

5、BUG处理的优先等级

1)       立刻修复（Immediate）

2)       尽快修复（Hight）

3)       正常修复（Normal）

4)       考虑修复（Low）

 

本章重点：

1.       测试文档的要求：

1)       测试文档是记录测试过程的数据

2)       测试文档必须保证为以后的缺陷跟踪提供依据

3)       测试文档要能证明测试的过程

4)       测试文档要能证明测试的步骤

5)       测试文档是贯穿整个测试流程的

6)       测试文档要覆盖软件开发生命周期

 

2.       测试文档的种类包括:

1)       需求类文档

2)       计划类文档

3)       设计类文档

4)       执行类文档

5)       缺陷记录类

6)       阶段汇总类

7)       测试总结类

 

3.       测试需求说明了在一个软件测试项目中：

1)       项目的测试范围

2)       项目的测试目标

 

4.       在测试项目中，我们需要进行开发生命周期中哪些阶段测试

1)       单元测试

2)       集成测试

3)       系统测试

4)       验收测试

 

5.       系统特性包括：功能、性能、易用性、安全性、兼容性。

 

6.       为什么测试需求很重要？

1)       测试团队、开发、客户之间的测试目标不一致

2)       因时间关系导致很多重要内容都来不及测试

3)       无法有效估计项目所需资源

4)       资源难以合理分配

5)       总是出现测试逃逸现象

6)       测试进度难以跟踪

7)       无法计算测试覆盖

 

7.       功能性测试需求描述了系统的特性或系统提供的服务，主要包括：

1)       系统功能

2)       业务流程

3)       界面功能和风格

4)       系统安装

 

8.       非功能性测试需求描述了施加于系统操作上的约束，主要包括：

1)       性能要求

2)       安全性要求

3)       兼容性要求

4)       移植性要求

9.       测试需求的组成：

1)       需求标识

2)       需求名称

3)       需求描述

 

10.    常见的开发文档和用户文档包括：

1)       系统需求分析说明书

2)       业务说明书

3)       概要设计说明书

4)       详细设计说明书

5)       用户手册

6)       安装手册

 

11.    在测试需求分析过程中，可以通过使用一些已经存在的系统来了解更多的信息。这些系统包括：

1)       旧的版本

2)       同类系统

3)       系统原型

4)       部分完成（或已经完成）的系统

 

12.    作为测试项目的基础，测试需求有5个需要依据的准则：

1)       完整性

2)       无歧异性

3)       一致性

4)       可跟踪性

5)       可测试性

 

13.    为什么需要测试用例

1)       根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪；

2)       减少回归测试的复杂程度；

3)       在软件版本更新后只需修正少量的测试用例便可以展开测试工作，降低工作强度、缩短项目周期；

4)       根据测试用例的操作步骤和执行结果，可以方便的书写软件测试缺陷报告；

5)       可以根据测试用例的执行等级，实施不同级别的测试；

 

14.    优质测试用例应具备的特性

1)       有效性

2)       可复用性

3)       易组织性

4)       可评估性

5)       可管理性

 

15.    划分等价类的原则

1)       如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类

2)       如果输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类

3)       如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类

4)       在规定了输入数据的一组值（假设N个）并且程序要对每一个输入值分别处理的情况下，可确立N个有效等价类和一个无效等价类。

5)       在规定了输入数据必须遵守的规则情况下可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

 

16.    因果图使用前提：

如果在测试时必须考虑输入条件的各种组合，就可使用因果图来设计测试用例。它适合于描述“对于多种条件的组合，会响应产生多个动作”的情况

 

17.    一张判定表的田字结构：条件桩、条件项、动作桩、动作项。

 

18.    所谓边界值，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

 

19.    测试用例书写标准

1)       标识符

2)       测试项

3)       文档拥有者、版本编号、创建日期

4)       测试环境要求

5)       测试动作描述

6)       预期值

7)       测试数据

 

20.    制定测试计划的步骤：

1)       确定测试范围

2)       确定测试策略

3)       确定自动化策略

4)       确定测试标准

5)       确定测试架构

6)       确定项目管理机制

7)       预估测试工作量

8)       评估风险并准备风险缓解计划

9)       测试计划评审

 

21.    系统测试前的四类标准

1)       进入标准

2)       退出标准

3)       暂停/ 继续标准

4)       通过/失败标准

5)       根据实际情况制定其他的标准

 

22.    测试环境包括：

1)       硬件要求：各种不同配置的硬件及其数量

2)       网络要求：测试时所需要的网络环境

3)       软件要求：测试时所需要的软件产品

4)       办公场所要求：进行测试时所需要的场地要求

 

23.    报告机制主要包括几个部分：

1)       报告类型：测试项目中有多种不同类型的报告，包括测试人员在定期工作报告、测试项目定期报告，项目阶段报告等

查看(667) 评论(0) 收藏 分享 管理

章节重点：

 

1、软件测试原则

1)       尽早和不断的测试

2)       彻底的测试不可能

3)       软件测试是有风险的行为

4)       并非所有的软件错误都能修复

5)       反相思维逻辑

6)       由小到大的测试范围

7)       避免检查自己的代码

8)       追溯至用户需求

 

2．为什么不能完全测试

1)       测试数据输入量太大

2)       输出结果太多

3)       软件的操作步骤太多

4)       软件说明书并非“盲人手册”

 

3、并非所有的错误都能修复，BUG不能被关闭的原因

1)       不算真正的软件错误

2)       没有足够的时间

3)       修复的风险太大

4)       不值得修复

 

4、错误集中发生现象

1)       错误前置逻辑

2)       实现人员的疲劳，造成大量代码坏块

3)       程序人员往往会犯同样的错误，因为大部分代码都是复制、粘贴而来

4)       软件的基础构架问题，有些软件的底层支撑系统因为“年久失修”变得越来越力不从心了。

5、发现缺陷的时间越早，BUG所造成的损失会越（小）。

 

6、“产品缺陷的（80％）”以上是在产品开发过程中的（需求定义阶段）引入的，

 

7、避免检查自己的代码的原因

1)       程序员从来都不会承认自己写的程序有错误

2)       程序员的测试思路有明显的局限性

3)       多数程序员没有经过严格正规的职业训练

4)       程序员无良好的BUG跟踪和回归测试经验。

 

8、错误集中表现在以下几方面

1)       找到的软件缺陷越多，就说明软件问题越多

2)       实现人员的疲劳，造成大量代码坏块

3)       程序人员往往会犯同样的错误

4)       软件的基础构架问题

章节重点：

 

1、什么是软件？文档＋数据＋程序

文档：包括软件需求说明书、软件概要设计说明书、软件详细说明书、用户操作手册

数据：表现形式多种多样

程序：代码，算法＋数据结构，算法

 

2、软件测试的划分？

（1）按照开发阶段划分

•          单元测试：单元测试又称为模块测试，是针对软件设计的最小单位一程序模块进行正确性检验的测试工作。

•          集成测试：将多个单元模块组合在一起实现多个功能保证模块与模块之间能互相访问，一次性集成方式、增殖式集成方式、混合增殖式测试。

•          系统测试：与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合。

•          确认测试：验证软件的功能和性能及其他特性是否与用户的要求一致。

•          验收测试：以用户为主的测试

 

（2）按照测试实施组织划分

•          开发方测试：开发方通过检测和提供客观证据，证实软件的实现是否满足规定的需求

•          用户测试：主要是把软件产品有计划的免费发到目标市场，让用户大量使用，并评价、检查软件。

•          第三方测试:介于软件开发方和用户方之间的测试组织的测试。第三方测试也成为独立测试。

（3）按照测试技术划分

•          白盒测试：

–         把测试对象看成是一个打开的盒子，程序内部的逻辑结构盒其他信息对测试人员都是公开的。白盒测试的方法有逻辑覆盖（语句覆盖、判定覆盖、条件组合覆盖、路径覆盖）基本路径测试等。

•          黑盒测试：

–         把测试对象看成是一个黑盒子，不考虑程序内部的逻辑结构盒内部特征，主要在软件的接口处进行测试，主要测试软件的功能。黑盒测试的方法包括等价类、边界值、错误推测法、因果图、功能图等

•          针对测试（特殊）

–         一种基于行业用户在使用产品过程中最容易遇到的错误而进行的一种有针对性的测试方法。多组测试条件汇集成一个测试库，测试人员依据测试库快速查找产品中的错误。由于剔除了测试阶段的盲目性，针对测试在实际运用中大大缩短了测试周期，降低了测试运行成本。针对测试对使用者有较高的要求，需要测试者有很长的测试积累周期并限定运用对象。

•          单元测试：单元测试又称为模块测试，是针对软件设计的最小单位一程序模块进行正确性检验的测试工作。

•          集成测试：将多个单元模块组合在一起实现多个功能保证模块与模块之间能互相访问，一次性集成方式、增殖式集成方式、混合增殖式测试。

•          系统测试：与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合

•          冒烟测试：

–         一个初始的快速的测试工作，以决定软件或者新发布的版本测试是否可以执行下一步的“正规”测试。如果软件或者新发布的版本每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够健全，目前不具备进一步测试的条件

•          回归测试

–         软件或环境的修复或更正后的“再测试”，自动测试工具对这类尤其有用

•          性能测试：

–         测试软件的运行性能。这种测试常与压力测试结合进行，如传输链接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。

•          负载测试：

–         测试软件在重负荷下的运行表现，系统的响应时间减慢或崩溃。

•          压力测试：

–         测试系统在某一条件达到最高限度时各项功能是否依旧运行。

•          可用性测试

–         测试用户是否能够满意使用。具体体现为操作是否方便、用户界面是否友好等。

•          安装/卸载测试

–         对软件的全部、部分、升级安装或卸载处理过程的测试

•          接受测试（可用测试、用户测试）

–         基于客户或最终用户的需求的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。

•          恢复测试：

–         采用人工的干扰使软件出错，中断使用，检测系统的恢复能力。

•          安全测试是

–         验证安装在系统内的保护机制确实能够对系统进行保护，使之不受各种干扰。

•          兼容测试

–         测试软件在多个硬件、软件、操作系统、网络等环境下是否能正常运行。

•          Alpha测试

–         在公司内部系统开发接近完成时对软件的测试，测试仍会有少量的设计变更。A测试时，开发者坐在用户旁边，随时记录用户发现的问题

•          Beta测试

–         当开发和测试根本完成所做的测试，而最终的错误和问题需要在最终发行前找到。B测试时开发者不在测试现场，是在开发者无法控制的环境下进行的测试，通常是由软件开发者向用户散发B版本软件，然后收集用户的意见。

 

3、软件测试的模型：V/W/H/X/前置模型等，其中重点掌握

 

优点：V模型反映了开发与测试的关系，明确的标出各个测试阶段及对应关系

缺陷：不适合的原因是软件测试在软件开发后才执行，延误了项目周期。

特点：

l         测试人员尽早的了解业务，测试需求在需求阶段就介入，测试和开发并行工作，更早介入、更早发现、更早纠正。

l         每个阶段测试都有文档产生！

l         验收测试检验软件实施的阶段，同时检验了软件需求分析，双重检验。

l         W模型比较适用于新项目的测试！

 

 

4、软件测试的生命周期

软件都要经历需求分析、设计、编码、测试、使用、淘汰的过程。 当软件不再被使用之后就标志生命周期结束。

 

5、软件测试项目周期：

（1）需求阶段

•          培训开发团队和客户，加强开发团队和客户对测试过程和测试标准的了解，影响其对测试的观点和态度

•          确定测试项目的高阶范围

•          确定测试项目的大致计划和安排

（2）测试设计阶段

•          制定测试标准

•          制定测试需求

•          制定测试计划

•          系统培训

（3）测试设计阶段

•          根据制定的测试需求、相关文档以及被测系统等设计测试用例

•          开发测试脚本、测试程序

•          设计测试数据

（4）测试执行阶段

•          按执行计划执行测试用例

•          记录测试过程

•          缺陷跟踪

（5）总结阶段

 

6、软件质量管理的八大原则：

•          原则1 以客户为关注焦点

•          原则2 领导作用

•          原则3 全员参与

•          原则4 过程方法

•          原则5 管理的系统方法

•          原则6 持续改进

•          原则7 基于事实的决策

•          原则8 互利的供应商关系

 

7、影响软件质量的因素

•          人的因素

•          软件需求不明确

•          质量总是可能出现在开始过程的各个环节上

•          测试的局限性

•          质量管理的困难

•          质量管理未能给予足够的重视

•          软件人员的传统习惯

•          开发规范

•          开发工具的支持不够

 

8、CMM/ISO9000

软件能力成熟度模型（Capability Maturity Model,CMM）

5个级别：初始级、可重复级、已定义级、已管理级、优化级

 

9、十大软件质量要素：

功能性质量因素：正确性，健壮性，可靠性

非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性

 

练习：

1、  什么是软件测试？

答：软件测试：软件测试是为了发现错误而执行程序的过程

 

2、  软件测试的目的？

答：充分利用有限的资源找出对用户影响最深的BUG和缺陷

 

3、软件测试与质量保证的区别

•          软件测试：是软件的执行者，目的是为了发现软件中存在的缺陷，通过静态和动态的操作来找出与预期要求不符的地方并向上级汇报。

•          质量保证：主要是指导并监督项目按照过程实施。着眼于软件开发活动中的过程、和产物，对项目进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，促进过程改进。

 

章节重点

 

(一)软件测试的现状与发展

 

1.       国外：软件测试是一个独立的产业；

2.       国内：大部分软件公司刚刚组建测试队伍；

 

测试发展速度仍落后于软件开发的速度，有挑战表现在：

a)       测试任务繁重，像神州五号的测试任务等等；

b)       软件越来越复杂的测试更重要，工作量很繁重；

c)       面向对象的测试，分布式系统（国防、电讯）、

嵌入式（朗讯贝尔实验室）整体测试还是难点、

实时系统、硬件的考虑；

d)       系统安全的测试与评估。

(二)国外测试的特点

 

1.       软件测试在软件公司中占有重要的地位；

2.       软件测试理论研究蓬勃发展，每年举办各样的测试技

   术年会，发表大量的软件测试论文，引领测试界潮流；

3.       软件测试市场繁荣。

(三)国内测试行业特点

 

1.       刚刚组建测试队伍，刚刚贯彻了独立测试的认识

2.       国家人事部和信息产业部2003年有了“软件测试”称号

3.       软件测试能力已经被定位评价公司技术能力的一项重要指标

4.       用户对软件质量要求越来越高，信息系统验收不再走过场

5.       软件测试正在成为部分软件学院的一门独立课程

6.       第三方测试机构得到了蓬勃发展

(四)软件测试发展趋势

 

1.       测试与质量保证体系的融合

2.       测试技术的细分

3.       测试工具的开发与自动化测试

4.       测试会走上专业化道路

(五)软件危机的形成※

 

1.       软件危机的概况

——软件危机（software Crisis）是计算机软件在它的开发和

维护过程中所遇到的一系列严重问题。概括的说，主要

包含两方面的问题：如果开发软件，怎样满足对软件日

益增长的需求：如何维护数量不断膨胀的已有软件。

 

2.       软件危机的原因

——硬件的进步，软件复杂度高，开发周期长，用户的需求

变更导致了软件危机。

 

3.       软件危机的体现

a)       对软件开发成本和进度的估计常常很不准确；

b)       用户对“已完成”的软件系统不满意的现象经常发生；

c)       软件产品的质量不稳定；

d)       软件的维护性低；

e)       软件缺少文档资料；

f)       软件成本在计算机系统总成本中所占比例逐年上升。

(六)软件测试从业人员的基本素质※

 

——具有操作系统、网络方面的知识，数据库的应用必须熟悉

          （基本的查询、增、删、查、改数据）！

1.       计算机专业技能

——有IT行业的背景

2.       测试专业技能

——关于测试概念和测试方法

3.       测试编程技能

——如果没有编程的技能只能从事简单的测试工作

4.       行业知识

——取决于社会经验和生活环境，需要各种开发语言和操作系

统、网络方面的知识比如TCP/IP协议还需了解，许多对此

协议进行的二次开发中间件WebLogic 。

5.       个人素养

—专心、细心、耐心、责任心、自信心