测试流程图

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