测试流程图

设计测试用例如下：
测试用例 x=4,y=6,z=5 x=2,y=5,z=5 通过路径 abd ace 条件取值 T1,T2,T3,T4 -T1,T2,-T3, -T4 T1,-T2,T3, -T4 覆盖方式 bd ce cd
x=4,y=5,z=15 a c d
上面的测试用例不但覆盖了所有分支的真假两个分支， 而且覆盖了判断中的所有条件的可能值
判定覆盖
如果设计两个测试用例则可以满足分支覆盖的 要求： 测试用例的输入为： {x=4 , y=5 , z=5} {x=2 , y=5 , z=5} 虽然可以满足分支覆盖的要求，但是也不能对 判断条件做完整的检查
条件覆盖
对于这个简单例子的所有条件取值加以标记。 如： 对于第一个判断： 条件x>3,取真值为T1，取假值为-T1 条件z<10,取真值为T2，取假值为-T2 对于第二个判断： 条件x=4,取真值为T3，取假值为-T3 条件y>5,取真值为T4，取假值为-T4
分支条件覆盖
根据定义只需要设计以下两个测试用例便可以 覆盖8个条件值以及4个判断分支
测试用例 x=4,y=6,z=5 通过路径 abd 条件取值 覆盖分支
x=2,y=5,z=11 a c e
T1,T2, bd T3,T4 -T1,-T2, -T3, c e -T4
分支条件覆盖
条件分支覆盖从表面上看，它测试了所有条件的取 值，但是实际上某些条件掩盖了另外的一些条件， 例如对于条件表达式（x>3）&&（z<10）来说， 必须两个条件都满足才能确定表达式为真。如果（ x<3）为假，则一般的编译器不再判断是否（z<10 了，对于第二个表达式（x==4）||（y>5）来说， 若x==4测试结果为真，就认为表达式的结果为真 ，这是不在检查（y>5）的条件了。因此，采用分 支条件覆盖，逻辑表达式的错误不一定能够查出来 了。
白盒测试
逻辑wenku.baidu.com动测试
基本路径测试
逻辑驱动测试
逻辑驱动测试： 主要是测试覆盖率，以程序内在逻辑结构为基础的测 试。包括以下6种类型： 1.语句覆盖 2.判断覆盖 3.条件覆盖 4.判定-条件覆盖 5.条件组合覆盖 6.路径覆盖
逻辑驱动测试
主要是测试覆盖率，以程序内在逻辑结构为基础的测试。包括 以下6种类型：
同行评审
.评审的输入
--待评审的文档，代码 --《XXX评审检查表》 .评审的输出
--《评审报告》
-- 《评审过程检查表》
正确看待文档
.文档是所有事情能够继承的保证 .如果认为不必要，多一分也是多，如果认为 必要，多少都不够
.文档是一个人水平高低的体现
.需要提高每个人的写作能力，练好内功
软件开发模型—瀑布型
1.语句覆盖：语句覆盖就是设计若干个测试用例，运行测试程序，使得每一条可执行语句至
少执行一次
2.判断覆盖：也叫分支覆盖设计若干个测试用例，运行测试程序，使得每个判断的取真分支
和取假分支至少执行一次
3.条件覆盖：设计足够多的测试用例，运行测试程序，使得每个判断的每个条件的每个可能
取值至少执行一次
4.判定-条件覆盖：设计足够多的测试用例，运行测试程序，使得每个判断的所有可能的条
1.需求
2.设计
3.代码 4.测试 5.运行/维护
软件开发模型—原型
1.用户需求不明确是采用
2.快速设计，快速开发
3.迭代的过程 4.与用户一起明确需求 5.最终会被抛弃
软件开发模型—演化模型
.线性迭代
.每个线性过程产生一个版本
.分阶段提供给用户
敏捷式开发
1.是一种以人为核心、迭代、循序渐 进的开发方法。
Level 5
基于对过程中的固有偏差的一般原因的定量理解， 持续的进行过程改进 通过渐进的和革新的技术改进，集中在持续地过程 性能改进上 指出过程偏差的一般原因和可测地改进组织过程的 过程改进得到识别，评估和实施 敏捷和创新的过程优化依赖于授权员工的参与，他 们与业务价值和组织目标保持一致
Level 2
测试用例如下：
但是如果设计了下面的测试用例，则虽然满足 了条件覆盖，但是只覆盖了第一个条件的取假 分支和第二个条件的取真分支，不满足分支覆 盖的要求
测试用例 通过路径 条件取值 -T1,T2, -T3,T4 T1,-T2, T3, -T4 覆盖分支 cd cd
x=2,y=6,z=5 a c d x=4,y=5,z=5 a c d
作为3级基础的组织标准过程集已经简历和不 断改进。 2，3级的区别在于标准，过程和规程的范围 3级比2级的描述更具体和更严格
Level 4
使用统计和量化技术进行控制 建立了质量和过程性能的量化目标，作为过程管理 的准则 收集了过程性能的详细度量，进行统计分析 质量和过程性能度量数据组成组织的度量库，来支 持将来的基于事实的决策 3，4级的区别在于过程性能的可预测性。
CMM2： 可重复性 KPA： 软件配置管理 软件质量保证 子合同管理
Level 2
软件项目跟踪和监控 软件项目计划
需求管理
配置管理
1.定义并文档化配置项的功能和物理属性 2.控制这些属性的变更 3.记录和报告变更处理结果和实施状态
4.遵从制定的需求进行验证
同行评审
为什么进行评审？ .促进文档化，提升可读性，易理解性等 .查找错误，收集建议 .扩散知识，产生后备力量 评审什么？ .项目中的一系列计划 .项目各阶段的输出：文档，代码等 谁来评审？ 项目组成员，PPQA，上级领导，客户等
测试总体流程图
立项 A测试计划、测试 设计
B单元测试
C整合测试
D系统测试
E性能测试
F验收测试
结束
测试分类
.黑盒测试
.白盒测试 .灰盒测试
软件中的难题
1.开发的不是客户需要的
2.计划赶不上变化，进度无法按期完成 3.挖坑还是开渠？永远的资源不足 4.不能正确实现功能 5.如何维护大量的已有软件？
软件与硬件的区别
CMMI阶段模型
5.优化级 ：持续过程改进，组织性快速重新 配置 4.量化管理级： 过程和产品被量化度量并控 制，组织性能提升 3.已定义级：组织内项目改进和执行 2.已管理级：能重复以前的成功，有纪律性 1.初始级：过程能力不可预测，无秩序
Level 1
在级别1： 过程是随机，混乱和无序的。这种通常没有一个稳 定的环境，它的成功依赖于组织中个人的能力和 英雄主意，而不是依赖使用经过验证的过程。尽 管这种混乱，无序的环境，对成熟度1的组织也 经常能制造出能工作的产品和服务，但是，他们 的项目经常是超成本和进度的。 它们有过度承诺的趋势，在危机时放弃过程，不能 重复他们过去的成功。
用于软件开发过程和开发能力的改进与评估的模型
对软件工程的全过程进行考察和评估
不告诉你怎么做，但告诉你不用成熟度应该关注的关键过程
何为CMM/CMMI
CMMI，目标：第一个是质量，第二个是时间表，第三就是 要用最低的成本。 与原有的能力成熟度模型CMM相比，CMMI涉及面更广， 专业领域覆盖软件工程、系统工程、集成产品开发和系统采 购 CMMI即CMM集成，是系统工程和软件工程的集成成熟度 模型，CMMI更适合于信息系统集成企业。CMMI是在 CMM基础上发展起来的，它继承并发扬了CMM的优良特 性，借鉴了其他模型的优点，融入了新的理论和实际研究成 果。它不仅能够应用在软件工程领域，而且可以用于系统工 程及其他工程领域。
软件 易变 非组件化 随时间而消退 硬件 确定，需求和产物 组件化，由构建组成 随时间而磨损
成本在研发上，copy过程 几乎没有成本
生产工程成本高
软件工程
1.软件工程是为创造高质量软件提供的一个框架
2.将系统化，规范化，可度量的方法应用于软件的开发， 运行和维护，即将工程化应用于软件中 3.包括过程，方法和工具三个层面 4.过程，方法和人对质量的影响
静态测试和动态测试
1.静态测试：指不用执行程序的测试。主要 采用Review，代码走查，同级评审，check list 检查单的方法对软件产品进行测试。 2.动态测试：通过执行程序，找出产品问题 的测试过程。黑盒，白盒都是动态测试。
白盒测试
白盒测试发现的错误类型：
1.语法错误 2.编译错误 3.逻辑错误 4.判定条件问题 5.编程规范 6.Memory Leak 7.Performance Problem
件取值组合至少执行一次
5.条件组合覆盖：设计足够多的测试用例，运行测试程序，使得程序中每个判断的所有可能
的条件取值组合至少执行一次
6.路径覆盖：设计足够多的测试用例，运行测试程序，要覆盖程序中所有可能的路径
For Example
Void DoWork(int x , int y , int z) { int k=0,j=0; if ((x>3)&&(z<10)) { k=x*y-1; //语句块1 j=sqrt（k）;
测试原则
所有测试都应该追溯到用户需求 应该在测试工作真正开始的较长时 间内就进行测试 测试中发现的80%的问题可能集中 在模块的20%中
测试原则
测试顺序应从简单到复杂，从模块到集成 ，从白到黑 穷举测试是不可能的
Bug不可避免
常用的测试技术
1.在产品成型前，对规约，设计，代码进行 Review，确认与需求是否一致---静态测试 2.了解产品内部结构，确认内部逻辑是否符 合需求，且内部构件被充分利用---白盒测试 3.如果了解特定的功能，在各种功能中寻找 错误—黑盒测试
过
程
1.过程是项目管理的基础 2.定义关键过程区域框架
3.CMM中的KPA
方
1.技术上需要如何做？
法
2.方法涵盖一系列的任务：需求，设计，编 码，测试，维护
工
具
1.为工程，方法提供自动，半自动化的支持 2.组建起来被另外一个工具使用 3.组成软件工程环境
过程篇—关于CMM
CMM（Capability Maturity Model） 能力成熟度模型
Level 2
1.组织中的项目确保需求得到管理，过程已经计划，执行， 度量和控制。 2.即使在时间压力下，依然能够保留现有的实践。 3.管理层在某些已定义点上对工作产品的状态和提交的服务 具有可视性。 4.在干系人（风险承担者）之间建立了承诺，在必要的时候 进行修正。
Level 3
工程得到很好地表现和理解，被描述成标准， 规程，关键和方法。
}
if((x==4)||(y>5)) { j=x*y+10; //语句块2 } j=j%3；//语句块3 }
流程图如下：
开始 （x>3） &&(z<10)
Yes No 执行语句块1
（x==4） ||(y>5)
Yes 执行语句块2
No
执行语句块3
结束
语句覆盖
为了说明简略，分别对各个判断的取真，取假分支编号为 b， c，d，e 为了测试语句覆盖率只要设计一个测试用例就可以把三个执 行语句块中的语句覆盖。 测试用例输入为：{x=4，y=5, z=5} 程序执行的路径是：a b d 该测试用例虽然覆盖了可执行语句，但是并不能检查判断逻 辑是否有问题，例如在第一个判断中把&&错误的写成||，上 面的测试用例仍然可以覆盖所有的执行语句。可以说语句覆 盖率是最弱的逻辑覆盖准则
条件组合覆盖
设计足够多的测试用例，运行测试程序，使得程序中每个 判断的所有可能的条件取值组合至少执行一次。 现在对例子中的各个判断的条件取值组合加以标记如下： x>3,z<10 记做T1，T2， 第一个判断的取真分支 x>3,z>=10 记做T1，-T2， 第一个判断的取假分支 x<=3,z<0 记做-T1，T2， 第一个判断的取假分支 x<=3,z>=10 记做-T1，-T2， 第一个判断的取假分支 x=4,y>5 记做T3，T4， 第一个判断的取真分支 x=4,y<=5 记做T3，-T4， 第一个判断的取真分支 x!=4,y>5 记做-T3，T4， 第一个判断的取真分支 x!=4,y<=5 记做-T3，-T4，第一个判断的取假分支
2.在敏捷开发中，软件项目的构建被 切分成多个子项目，各个子项目的成 果都经过测试，具备集成和可运行的 特征。
决定软件质量的因素
1.过程 2.方法
3.工具
4.人
测试目的
在产品投入使用前，通过综合的智力活动 ，发现程序中的显性和隐形的错误和缺陷
。控制发布产品的质量，提升客户满意度
测试目的
测试的目的是发现和确认系统有问题，而不是 验证系统没有问题 确认软件生命周期中的各个阶段的产品是否正 确 确认最终交付的产品是否符合用户需求 使用测试数据检验系统运行的行为是否是按照 预期目标执行的