软件测试流程梳理

软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等6个阶段。
系统测试是将软件系统与硬件、外设和网络等其他因素结合，对整个软件系统进行测试。
常见的系统测试主要有恢复测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试等。
    单元测试以白盒为主，测试单元内部独立路径、逻辑结构、规范等；
    集成测试也是以白盒为主，黑盒辅助，注重测试模块间接口数据传递、参数的个数、属性和顺序的正确性
    测试粒度最大：验收
        

    单元测试 最小单位测试
    集成测试 按说明书组装测试
        接口测试
    确认测试 确认性能，功能
    系统测试 计算机，网络，硬件组合测试。
             同行评审目的:发现小规模工作产品的错误,系统测试计划属于项目阶段性关键文档，同行评审是必须的
        安全测试
        性能测试
        压力测试
        功能测试
        回归测试：用于判断“新引入的变化没有给现有软件造成破坏”的测试方法
    验收测试 按验收流程测试
     
    可能的测试有恢复测试、压力测试、回归测试、验收测试
    
软件测试对软件质量的意义
    度量与评估软件的质量
    保证软件质量
    改进软件开发过程
    对被调试的程序进行“错误定位”是程序调试的必要步骤
    程序调试通常也称为Debug
    软件测试应严格执行测试计划，排除测试的随意性
    软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。
    软件测试的测试目标是发现一些可以通过测试避免的开发风险。
    软件测试的原则之一是测试应该尽早进行，最好在需求阶段就开始介入。
    软件测试主要工作内容是验证（verification）和确认（validation）
    
    
    
    
    软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等6个阶段。

系统测试是将软件系统与硬件、外设和网络等其他因素结合，对整个软件系统进行测试。
常见的系统测试主要有恢复测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试等。
    单元测试以白盒为主，测试单元内部独立路径、逻辑结构、规范等；
    集成测试也是以白盒为主，黑盒辅助，注重测试模块间接口数据传递、参数的个数、属性和顺序的正确性
    测试粒度最大：验收
        

    单元测试 最小单位测试
    集成测试 按说明书组装测试
    确认测试 确认性能，功能
    系统测试 计算机，网络，硬件组合测试
    验收测试 按验收流程测试
    
软件测试对软件质量的意义
    度量与评估软件的质量
    保证软件质量
    改进软件开发过程

根据不同的测试阶段，测试可以分为单元测试、集成测试、系统测试和验收测试。
体现了测试由小到大、又内至外、循序渐进的测试过程和分而治之的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

粒度从小到大顺序：
单元->集成->系统->验收

v模型

用户需求————————————————>验收测试
需求测试(设计文档）————————————>系统测试        
概要设计————————>集成测试              
详细设计————>单元测试 
编码                  

SOW:statement of work，工作任务说明书    
HLD: High Level Design,概要设计说明书
LLD: Low Level Design，详细设计说明书
UTC: Unit Testing Cases，单元测试用例

工作说明书—SOW       制定测试的进度
概要设计说明书-HLD  设计测试的用例
详细设计说明书-LLD  程序员编码实现

单元测试用例-UTC    单元测试使用

设计系统测试计划    （工作任务说明书）
    需要参考的项目文挡：
        软件测试计划
        软件需求规范
        迭代计划
    软件测试计划评审：
        项目经理
        sqa负责人
        配置负责人
        测试组
        
        
测试工具：
    LoadRunner-负载压力测试：预测系统性能。
    JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制 
    功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。 
    Junit：白盒测试工具：针对代码测试 
    测试管理工具：对测试需求、计划、用例、实施进行管理 
    测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备 
    负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。 
    功能测试： QTP(quicktest professional):自动测试工具 
    白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试） 
    缺陷管理工具：Mantis、BugFree、QC、TD 
    用例管理工具：TestLink、QC 
    测试辅助工具：SVN，git
    
  

测试案例设计：
    用判定覆盖设计的测试数据：
        a＝5 （判定表达式的值为“真”）
        a＝0 （判定表达式的值为“假”）
        这里不需要管b的取值，就已经满足判定覆盖的条件了。
    
    用条件覆盖设计的测试数据：
        语句if（a>5 && b<0）满足条件组合覆盖需要设计测试用例的个数为
        a＝5 （条件a>1的值为“真”）
        a＝0（条件a>1的值为“假”）
        b＝5 （条件b>1的值为“真”）
        b＝0 （条件b>1的值为“假”）
        这里不考虑 a>1 or b>1 这个表达式的取值的情况，但必须把a>1 和 b>1 这两个条件的取值考虑全。
        
        
        为下列代码设计测试用例，要求满足条件组合覆盖，需要设计测试用例的个数为（ ）
        BEGIN
I       NPUT(A,B)
        IF(A>5)AND(B<O)
        THEN
        X=A+B
        ELSE
        X=A-B
        END

    基本路径V（G）
        1、V（G）=P+1 （P是判定节点）
        2、V（G）=D （D是区域数）
        3、V（G）=E-N+2（E是边的条数，N是节点数）
  
        只要看见switch就要注意每个case后有没有break，请注意，语句覆盖，case2没有break，因此case2和case3可以同时在value=2时得到覆盖
    
    针对程序段：IF（A||B||C）THEN  W=W/X，对于(A,B,C)的取值，（ ）测试用例能够满足MCDC（修正条件逻辑判定）的要求。
            （A||B||C）一共有2^3=8,8种2组合，但是因为是或，or 或语句只要判断前面的，
            若第一项为T，后面无论是啥，都为真，（T X X）  =（T T F）=（T T T）=（T F F）=（T F T）等效    4种
            若第一项为F，则判断第二项，第二项为T，则后面无需判断，（F T X）   =（F T F）=（F T T）等效    2种
            第二项为F，则判断第三项，第三项为T      （F F T）     1种
            第二项为F，则判断第三项，第三项为F      （F F F）     1种
            (T,F,F) (F,T,F) (F,F,T) (F,F,F)
    

测试用例设计方法：

    1、等价类划分
    2、边界值分析
    3、因果图
    4、功能图分析
    5、错误推测
    6、判定表驱动分析
    7、正交实验设计
    8、场景设计
    

测试用例包含因素：
    软件测试用例主要由测试输入数据和测试的预期结果两部分组成
    测试用例的八大要素：用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、测试步骤、预期结果。
    
测试方法可以分成哪几种?
    人工测试：个人复查、抽查和会审。
    机器测试：黑盒测试和白盒测试

单元测试
    主要技术手段：
        驱动代码
        Stub代码
        Mock代码
    单元测试的策略：
        逻辑覆盖、
        循环覆盖、
        同行评审、
        桌前检查、
        代码走查、
        代码评审、
        代码评审的内容：
            编码规范问题：命名不规范、magic number、 System.out……
            代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合
            工具、框架使用不当：Spring、Hibernate、AJAX
            实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好
            测试问题：测试覆盖度不够、可测试性不好
            代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决    
            静态数据流分析

（单元测试已经完成，并提交《单元测试报告》、代码走查完成，已进入受控库并完成产品集成）
集成测试的基础策略有很多，通常分为两种：非增量式集成测试策略和增量式集成测试策略
    第一种：非增量式集成测试策略，非增量式集成测试策略也叫做大爆炸集成、一次性集成；    (每个模块测试完了再连接；)
        即在最短的时间内把所有的系统组件一次性集成到被测系统中，并通过最少的用例来验证整个系统，不考虑各组件之间的相互依赖性或者可能存在的风险。 
        优点：
            容易理解，比较简单
            可以多人并行工作，对人力物力资源的利用率较高。
        缺点：
            即使被测系统能够被一次性集成，但是还会有许多接口上测试被遗漏，甚至会躲过测试遗留在系统中。
        适用场景：
            适用于维护型的项目，并且新增的项目只有少数的模块被增加或修改
    第二种：增量式集成测试策略，增量式集成的策略有很多种：自顶向下集成，自底向上集成，三明治集成，基于功能集成，基于风险集成，基于分布式集成等。(测一个模块，就连接一个模块。)
        该策略最大的特点就是：支持故障隔离、定位问题
            1、自顶向下集成:(个人理解：随着底层不断增加，测试越来越难以全面。)
                自顶向下集成首先要集成主控制模块，然后从软件控制层次结构向下逐步集成，可以采用深度优先或者广度优先进行集成测试，主要验证接口的稳定性。
                假定一个系统包括6个模块（ABCDEF），其中B、C、D是A的子模块，E是B的子模块、F是D的子模块,采用先深度后广度的增量测试方法
                    ABECDF
                自顶向下测试：是从程序的初始模块开始测试。
                    1）该方***在早期发现顶层的错误。
                    2）早期的程序框架可以进行演示
                    3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。
                    4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。
                    优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
                    缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。
                    使用场景：接口变化比较小的项目并且控制结构比较清晰。
            2、自底向上集成(对底层模型的行为进行较早的验证，早期可能出现并行的测试.)
                    1）I/O操作可以提前测试，更好提交测试用例。
                    2）测试后比较容易观察输出。
                    3）需要开发驱动模块。
                    4）直到最后一个模块提交，程序才能完整的系统测试。
                    优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
                    缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
                    自底向上集成需要测试员编写驱动程序。
                    这里的驱动模块，就像程序里的main方法，就是程序运行的入口。
                    使用场景：顶层接口变化比较复杂的，变化比较频繁的系统
            3、三明治集成：三明治集成属于混合式集成，综合了自顶向下和自底向上集成的优缺点；测试的时候，将被测软件分成三份，中间一份为目标层，目标层的上部分采用自顶向下集成策略，下部分采用自底向上集成策略。最后在目标层进行会和。
                    缺点：最大的缺点就是对中间层的测试不够充分；
                    使用场景：适用于大多数项目。使用时要尽可能的减少驱动模块和桩模块的数量。    
            4.基于功能集成：基于功能角度出发，按照功能的关键程度对功能模块进行集成。
                    缺点：对一些接口测试不充分。系统很复杂的时候，功能之间的相互联系很难分析清楚，会造成大量的冗余测试
            5.基于风险集成：是一种假设，系统风险度较高的模块间的集成往往是错误集中的地方。
                    优点：加速系统的稳定性。
                    关键点：风险的识别和评估。通常跟基于功能集成合用
            6.基于分布式集成：主要是验证松散耦合的同级模块之间的交互稳定性。在一个分布式系统中，由于没有专门的控制轨迹，没有专门的服务层，所以构造测试包非常困难，主要验证远程主机之间的接口是否具有最低限度的可操作性。
                    使用场景：主要用在分布式系统中。                

            

黑盒测试：
    界面元素测试包括：窗口测试、菜单测试、图标测试、文字测试、鼠标测试

白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试。
    白盒测试的主要方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。
    语句覆盖＜判定覆盖＜条件覆盖＜语句/判定覆盖＜条件组合覆盖＜路径覆盖
    白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
        1.语句覆盖每条语句至少执行一次。
        2.判定覆盖每个判定的每个分支至少执行一次。
        3.条件覆盖每个判定的每个条件应取到各种可能的值。
        4.判定/条件覆盖同时满足判定覆盖条件覆盖。
        5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
        6.路径覆盖使程序中每一条可能的路径至少执行一次。

    动态分析：代码运行结束后。模块功能检查和系统压力测试，必须执行代码后才能分析。
    静态分析：代码运行之前。数据流分析和代码覆盖率，不需要执行代码就可分析。
        静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
                人工测试技术主要包含三种静态测试技术，分别是走查、审查和正式评审。

    比较判断与控制流常常紧密相关，测试时注意下列错误：
        1. 不同数据类型的对象之间进行比较;
        2. 错误地使用逻辑运算符或优先级;
        3. 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等;
        4. 比较运算或变量出错;
        5. 循环终止条件或不可能出现;
        6. 迭代发散时不能退出;
        7. 错误地修改了循环变量。

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用（需求规格说明与概要设计说明)
黑盒测试主要的方法有：等价类划分法、边界值分析法、错误推测法、因果图法、决策表法、场景法等。
    等值分析测试=等价类划分+边界值分析测试（使用最广)
    有效等价类：短信内容长度在70个汉字以内。无效等价类：短信内容长度为0、短信内容长度大于70。
        手机发送短信长度限定在70个汉字以内（包括70），若对该功能进行等价类测试，无效等价类为（      ）
        某程序要求每次输入只能是正整数，并且每次输入的数值要求必须是100的倍数且小于等于500，则下列哪个是正确的无效等价类(        )
    边界值法：
        取值范围在1~10，一般解读就是取值[1,10]，那么它的边界值应该是0，1，10，11
        因果图法：
    判定表组成法：
    正交试验设计：
    错误推测法：
    场景法

性能测试：
    负载测试：在一定的工作负荷下，系统的负荷及响应时间。（负载测试是性能在极限情况下能坚持多久）
    强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
    容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），（压力测试是测试软件的瓶颈和极限）
               系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。 
    容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。

    LoadRunner（预测系统行为和性能的负载测试工具）
       1、VuGen:脚本编辑和脚本运行（脚本生产器）
       2、Controller:测试执行，压力调度和监控系统
       3、Analysis：结果分析工具

验收测试：
    验收测试是在功能测试和系统测试之后进行的，所以验收测试的前提条件是系统或软件产品已通过了内部测试。然后和用户一起验收软件，在真实环境下运行软件，看是否存在与用户需求不一致的问题或违背产品规格书的要求。由于测试人员不可能完全用户实际使用情况，所以软件是否真正满足最终用户的要求，应由用户进行一系列的验收测试。
    1）验收测试定义：
        检查软件是否符合合同要求，包括需求规格说明、设计规格说明和用户手册等。
    2）测试内容：  
        易用性测试（用户界面和可用性测试）
        兼容性测试（软件兼容性测试、数据共享兼容性测试、硬件兼容性测试）
        安装测试和可恢复性测试
        文档测试（如用户手册、操作手册）
    3）测试人员：
        用户和测试部门共同完成
    4）测试依据：
        国家规范、行业标准、合同条款、用户确认的需求规格说明书。
    5）α，β测试
        α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
        经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
        6）用户界面测试的要素：符合标准和规范：良好的用户界面应该遵守操作系统的界面标准，比如在windows系统中，出现红色叉号对话框意味着严重警告或错误。
        直观性：这里有一个直观地例子（www.jaspermorrison.com/），其中的链接或功能都是通过直观地图形展示给用户的。
        一致性
        灵活性
        舒适性
        正确性
        实用性
    7）向前和向后兼容：
     向后兼容是指可以使用以前版本的软件，而向前兼容是指可以使用未来版本的软件。如word2003能向后兼容以前的word2000甚至MS-DOS下的字处理软件的所有版本的文件格式。而向前兼容指windows XP能否运行将来的word 2007，或者说word 2003能否打开word 2007文件。
    8）文档测试的重要性：
       软件文档是软件的重要组成部分，文档错误也是软件缺陷。
       错误的解释可能会引导用户无法完成某些软件已有的功能。
       用户通过文档可以掌握具体的使用方法，提高了易用性。

    验收测试的标准：
    软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
    所有测试项没有残余一级、二级和三级错误。
    立项审批表、需求分析文档、设计文档和编码实现一致。
    验收测试工件齐全。
    Beta 测试是验收测试的一种。
    α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
    α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。
    β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

针对手机软件的系统测试，通常包含以下角度：
    <1>功能模块测试：首先分析功能模块的功能项，测试每一个功能项是否能够实现对应功能。一般根据测试用例和软件本身的流程就可以完成基本功能测试。
    <2>交叉事件测试：又叫做事件或者冲突测试，是指一个功能正在执行过程中，同时另外一个事件或者操作对该过程进行干扰的测试。例如通话过程中接收到短信或者闹铃触发，应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机、花屏等严重问题。
    <3>压力测试：又叫做边界值容错测试或极限负载测试。即测试过程中，已经达到某一软件功*能[存储、网络、响应能力]的最大容量、边界或者最大承受极限，仍然对其进行相关操作*。例如连续接收或者发送短信，超过收信箱和SIM卡所能存储的最大条数，仍然进行接收或者发送，依次来检测软件在超常态下的表现，进而进行评估用户能否接受。
对手机可以施加的压力测试类型主要包括：
    ->存储压力：由于手机采用的是栈式存储，所以当一个存储块满了之后，程序员不做相应处理的话，就会导致其他存储区被删除。
    ->边界压力:边界处理问题一直是容易被忽略的地方
    ->响应能力压力：有时 某些操作可能处理的时间较长，如果在处理期间，继续进行其他操作时候就会出现问题。
    ->网络流量压力：执行较大数据流量的功能同时，在进行其他操作，使得网络流量始终处于很高的状态，检验各个功能是否依然正常工作，是否存在因为网络流量瓶颈引起的某功能异常。
    <4>容量测试：即存储空间已满时候的测试，包括用户可用内存/SIM卡所有空间被完全使用的测试。此时在对可编辑模块和存储空间进行操作，如果软件在极容状态下处理不好，将会导致死机或者花屏等问题。
    <5>兼容性测试：不同品牌、型号手机，不同网络，不同容量大小的SIM卡之间的兼容性测试。例如：中国电信的小灵通接收到中国移动或者中国联通GSM发来的短消息，需要验证显示和回复是否正常。
    <6>易用性、用户体验测试：在指定条件下，软件产品被理解、学习、使用和吸引用户的能力，是交互的适应性、功能性和有效性的集中体现。

OCUnit 是 OC 官方测试框架， 现在被 XCTest 所取代。
XCTest 是与 Foundation 框架平行的测试框架。
GHUnit 是第三方的测试框架。
OCMock都是第三方的测试框架。

网络管理员编写了shell程序prog1.sh,测试时程序死循环无法结束,可以通过下列方式结束程序

        

      

软件测试对于一个软件开发项目的成功与否具有十分重要的意义，但是在实际的项目开发与管理中仍然存在很多管理上或者技术上的误区，其中包括
    期望用测试自动化代替大部分人工劳动
    忽视软件测试人员在需求阶段的项目参与

根据不同的测试阶段，测试可以分为单元测试、集成测试、系统测试和验收测试。
体现了测试由小到大、又内至外、循序渐进的测试过程和分而治之的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。

粒度从小到大顺序：
单元->集成->系统->验收

v模型

用户需求————————————————>验收测试
需求测试(设计文档）————————————>系统测试           系统设计文档
概要设计————————>集成测试               概括设计文档
详细设计————>单元测试                   详细设计文档 
编码

SOW:statement of work，工作任务说明书
HLD: High Level Design,概要设计说明书
LLD: Low Level Design，详细设计说明书
UTC: Unit Testing Cases，单元测试用例

设计系统测试计划    （工作任务说明书）
    需要参考的项目文挡：
        软件测试计划
        软件需求规范
        迭代计划
    测试设计员的职责有：
        设计测试用例
        设计测试过程、脚本
        
    软件测试计划评审：
        项目经理
        sqa负责人
        配置负责人
        测试组
        
        
测试工具：
    LoadRunner-负载压力测试：预测系统性能。
    JMeter+Badboy：基于JAVA的压力测试工具，Badboy用来进行脚本的录制 
    功能测试：通过自动录制、检测和回放用户的应用操作。将输出记录同预先给定的记录比较。 
    Junit：白盒测试工具：针对代码测试 
    测试管理工具：对测试需求、计划、用例、实施进行管理 
    测试辅助工具：本身不执行，可以生成测试数据，为测试提供数据准备 
    负载压力测试：LoadRunner:预测系统行为和性能的工业标准级负载测试工具。模拟上千万用户同时实施并发操作，来实时监控可能发生的问题。 
    功能测试： QTP(quicktest professional):自动测试工具 
    白盒测试：C++ TEST（做C和C++的白盒测试）、JUnit（Java白盒测试） 
    缺陷管理工具：Mantis、BugFree、QC、TD 
    用例管理工具：TestLink、QC 
    测试辅助工具：SVN，git
    
    以下属于软件调试技术的是
        强行排错法
        回溯法
        原因排除法

编写测试案例的目的：
    从测试用例追溯回功能需求以确保没有需求被疏忽
    用测试用例来验证产品需求模型的正确性
    通过测试用例以确认是否达到了产品期望的要求

测试案例设计：
    用判定覆盖设计的测试数据：
        a＝5 （判定表达式的值为“真”）
        a＝0 （判定表达式的值为“假”）
        这里不需要管b的取值，就已经满足判定覆盖的条件了。
    
    用条件覆盖设计的测试数据：
        语句if（a>5 && b<0）满足条件组合覆盖需要设计测试用例的个数为
        a＝5 （条件a>1的值为“真”）
        a＝0（条件a>1的值为“假”）
        b＝5 （条件b>1的值为“真”）
        b＝0 （条件b>1的值为“假”）
        这里不考虑 a>1 or b>1 这个表达式的取值的情况，但必须把a>1 和 b>1 这两个条件的取值考虑全。
        
        
        为下列代码设计测试用例，要求满足条件组合覆盖，需要设计测试用例的个数为（ ）
        BEGIN
I       NPUT(A,B)
        IF(A>5)AND(B<O)
        THEN
        X=A+B
        ELSE
        X=A-B
        END

    基本路径V（G）
        1、V（G）=P+1 （P是判定节点）
        2、V（G）=D （D是区域数）
        3、V（G）=E-N+2（E是边的条数，N是节点数）
  
        只要看见switch就要注意每个case后有没有break，请注意，语句覆盖，case2没有break，因此case2和case3可以同时在value=2时得到覆盖
    
    针对程序段：IF（A||B||C）THEN  W=W/X，对于(A,B,C)的取值，（ ）测试用例能够满足MCDC（修正条件逻辑判定）的要求。
            （A||B||C）一共有2^3=8,8种2组合，但是因为是或，or 或语句只要判断前面的，
            若第一项为T，后面无论是啥，都为真，（T X X）  =（T T F）=（T T T）=（T F F）=（T F T）等效    4种
            若第一项为F，则判断第二项，第二项为T，则后面无需判断，（F T X）   =（F T F）=（F T T）等效    2种
            第二项为F，则判断第三项，第三项为T      （F F T）     1种
            第二项为F，则判断第三项，第三项为F      （F F F）     1种
            (T,F,F) (F,T,F) (F,F,T) (F,F,F)
    

测试用例设计方法：

    1、等价类划分
    2、边界值分析
    3、因果图
    4、功能图分析
    5、错误推测
    6、判定表驱动分析
    7、正交实验设计
    8、场景设计
    
测试用例包含因素：
    测试用例的八大要素：用例编号、测试项目、测试标题、重要级别、预置条件、测试输入、测试步骤、预期结果。
    
测试方法可以分成哪几种?
    人工测试：个人复查、抽查和会审。
    机器测试：黑盒测试和白盒测试

单元测试
    主要技术手段：
        驱动代码
        Stub代码
        Mock代码
    单元测试的策略：
        逻辑覆盖、
        循环覆盖、
        同行评审、
        桌前检查、
        代码走查、
        代码评审、
        代码评审的内容：
            编码规范问题：命名不规范、magic number、 System.out……
            代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合
            工具、框架使用不当：Spring、Hibernate、AJAX
            实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好
            测试问题：测试覆盖度不够、可测试性不好
            代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决    
            静态数据流分析
    单元测试工具：
        

（单元测试已经完成，并提交《单元测试报告》、代码走查完成，已进入受控库并完成产品集成）
集成测试的基础策略有很多，通常分为两种：非增量式集成测试策略和增量式集成测试策略
    第一种：非增量式集成测试策略，非增量式集成测试策略也叫做大爆炸集成、一次性集成；    (每个模块测试完了再连接；)
        即在最短的时间内把所有的系统组件一次性集成到被测系统中，并通过最少的用例来验证整个系统，不考虑各组件之间的相互依赖性或者可能存在的风险。 
        优点：
            容易理解，比较简单
            可以多人并行工作，对人力物力资源的利用率较高。
        缺点：
            即使被测系统能够被一次性集成，但是还会有许多接口上测试被遗漏，甚至会躲过测试遗留在系统中。
        适用场景：
            适用于维护型的项目，并且新增的项目只有少数的模块被增加或修改
    第二种：增量式集成测试策略，增量式集成的策略有很多种：自顶向下集成，自底向上集成，三明治集成，基于功能集成，基于风险集成，基于分布式集成等。(测一个模块，就连接一个模块。)
        该策略最大的特点就是：支持故障隔离、定位问题
            1、自顶向下集成:(个人理解：随着底层不断增加，测试越来越难以全面。)
                自顶向下集成首先要集成主控制模块，然后从软件控制层次结构向下逐步集成，可以采用深度优先或者广度优先进行集成测试，主要验证接口的稳定性。
                假定一个系统包括6个模块（ABCDEF），其中B、C、D是A的子模块，E是B的子模块、F是D的子模块,采用先深度后广度的增量测试方法
                    ABECDF
                自顶向下测试：是从程序的初始模块开始测试。
                    1）该方***在早期发现顶层的错误。
                    2）早期的程序框架可以进行演示
                    3）需要开发桩模块辅助测试。有些甚至需要多个桩模块辅助，加大了桩模块本来的错误影响。
                    4）测试完一个上层模块后，挑选哪个模块作为下一个测试模块，以及测试的顺序没有唯一的界定标准。
                    优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。
                    缺点：柱的开发量大；底层验证被推迟；底层组件测试不充分。
                    使用场景：接口变化比较小的项目并且控制结构比较清晰。
            2、自底向上集成(对底层模型的行为进行较早的验证，早期可能出现并行的测试.)
                    1）I/O操作可以提前测试，更好提交测试用例。
                    2）测试后比较容易观察输出。
                    3）需要开发驱动模块。
                    4）直到最后一个模块提交，程序才能完整的系统测试。
                    优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。
                    缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。
                    自底向上集成需要测试员编写驱动程序。
                    这里的驱动模块，就像程序里的main方法，就是程序运行的入口。
                    使用场景：顶层接口变化比较复杂的，变化比较频繁的系统
            3、三明治集成：三明治集成属于混合式集成，综合了自顶向下和自底向上集成的优缺点；测试的时候，将被测软件分成三份，中间一份为目标层，目标层的上部分采用自顶向下集成策略，下部分采用自底向上集成策略。最后在目标层进行会和。
                    缺点：最大的缺点就是对中间层的测试不够充分；
                    使用场景：适用于大多数项目。使用时要尽可能的减少驱动模块和桩模块的数量。    
            4.基于功能集成：基于功能角度出发，按照功能的关键程度对功能模块进行集成。
                    缺点：对一些接口测试不充分。系统很复杂的时候，功能之间的相互联系很难分析清楚，会造成大量的冗余测试
            5.基于风险集成：是一种假设，系统风险度较高的模块间的集成往往是错误集中的地方。
                    优点：加速系统的稳定性。
                    关键点：风险的识别和评估。通常跟基于功能集成合用
            6.基于分布式集成：主要是验证松散耦合的同级模块之间的交互稳定性。在一个分布式系统中，由于没有专门的控制轨迹，没有专门的服务层，所以构造测试包非常困难，主要验证远程主机之间的接口是否具有最低限度的可操作性。
                    使用场景：主要用在分布式系统中。                

            

黑盒测试：
    界面元素测试包括：窗口测试、菜单测试、图标测试、文字测试、鼠标测试

白盒测试也称结构测试或逻辑驱动测试，是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件的测试。
    白盒测试的主要方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。
    语句覆盖＜判定覆盖＜条件覆盖＜语句/判定覆盖＜条件组合覆盖＜路径覆盖
    白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
        1.语句覆盖每条语句至少执行一次。
        2.判定覆盖每个判定的每个分支至少执行一次。
        3.条件覆盖每个判定的每个条件应取到各种可能的值。
        4.判定/条件覆盖同时满足判定覆盖条件覆盖。
        5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
        6.路径覆盖使程序中每一条可能的路径至少执行一次。

    动态分析：代码运行结束后。模块功能检查和系统压力测试，必须执行代码后才能分析。
    静态分析：代码运行之前。数据流分析和代码覆盖率，不需要执行代码就可分析。
        静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
                人工测试技术主要包含三种静态测试技术，分别是走查、审查和正式评审。
                编码规则检查
                程序结构分析
                程序复杂度分析

    比较判断与控制流常常紧密相关，测试时注意下列错误：
        1. 不同数据类型的对象之间进行比较;
        2. 错误地使用逻辑运算符或优先级;
        3. 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等;
        4. 比较运算或变量出错;
        5. 循环终止条件或不可能出现;
        6. 迭代发散时不能退出;
        7. 错误地修改了循环变量。

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用（需求规格说明与概要设计说明)
黑盒测试主要的方法有：等价类划分法、边界值分析法、错误推测法、因果图法、决策表法、场景法等。
    等值分析测试=等价类划分+边界值分析测试（使用最广)
    有效等价类：短信内容长度在70个汉字以内。无效等价类：短信内容长度为0、短信内容长度大于70。
        手机发送短信长度限定在70个汉字以内（包括70），若对该功能进行等价类测试，无效等价类为（      ）
        某程序要求每次输入只能是正整数，并且每次输入的数值要求必须是100的倍数且小于等于500，则下列哪个是正确的无效等价类(        )
    边界值法：
        取值范围在1~10，一般解读就是取值[1,10]，那么它的边界值应该是0，1，10，11
            给定了有效输入，使用边界值分析法。对数组的有效范围进行测试。
        这里的有效范围是 [0,100]。
            可以测试越界的，这里可以使用 -1、101，数组的前两位 0、1，数组的最后两位 99、100，中部一位 67。可以测试所有情况。
        另附上常见的边界值，来自牛客网的测试面试宝典
            常见的边界值
                1)对16-bit 的整数而言 32767 和 -32768 是边界
                2)屏幕上光标在最左上、最右下位置
                3)报表的第一行和最后一行
                4)数组元素的第一个和最后一个
                5)循环的第 0 次、第 1 次和倒数第 2 次、最后一次
    因果图法：
    判定表组成法：
    正交试验设计：
    错误推测法：
    场景法

性能测试：
    负载测试：在一定的工作负荷下，系统的负荷及响应时间。（负载测试是性能在极限情况下能坚持多久）
    强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
    容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），（压力测试是测试软件的瓶颈和极限）
               系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。 
    容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。

    以下哪些是服务器性能测试中的性能指标
        吞吐量  
        响应时间
        CPU使用率
           
    
    
    
    
    
    
    
    
    LoadRunner（预测系统行为和性能的负载测试工具）
       1、VuGen:脚本编辑和脚本运行（脚本生产器）
       2、Controller:测试执行，压力调度和监控系统
       3、Analysis：结果分析工具

验收测试：
    验收测试是在功能测试和系统测试之后进行的，所以验收测试的前提条件是系统或软件产品已通过了内部测试。然后和用户一起验收软件，在真实环境下运行软件，看是否存在与用户需求不一致的问题或违背产品规格书的要求。由于测试人员不可能完全用户实际使用情况，所以软件是否真正满足最终用户的要求，应由用户进行一系列的验收测试。
    1）验收测试定义：
        检查软件是否符合合同要求，包括需求规格说明、设计规格说明和用户手册等。
    2）测试内容：  
        易用性测试（用户界面和可用性测试）
        兼容性测试（软件兼容性测试、数据共享兼容性测试、硬件兼容性测试）
        安装测试和可恢复性测试
        文档测试（如用户手册、操作手册）
    3）测试人员：
        用户和测试部门共同完成
    4）测试依据：
        国家规范、行业标准、合同条款、用户确认的需求规格说明书。
    5）α，β测试
        α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
        经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
        6）用户界面测试的要素：符合标准和规范：良好的用户界面应该遵守操作系统的界面标准，比如在windows系统中，出现红色叉号对话框意味着严重警告或错误。
        直观性：这里有一个直观地例子（www.jaspermorrison.com/），其中的链接或功能都是通过直观地图形展示给用户的。
        一致性
        灵活性
        舒适性
        正确性
        实用性
    7）向前和向后兼容：
     向后兼容是指可以使用以前版本的软件，而向前兼容是指可以使用未来版本的软件。如word2003能向后兼容以前的word2000甚至MS-DOS下的字处理软件的所有版本的文件格式。而向前兼容指windows XP能否运行将来的word 2007，或者说word 2003能否打开word 2007文件。
    8）文档测试的重要性：
       软件文档是软件的重要组成部分，文档错误也是软件缺陷。
       错误的解释可能会引导用户无法完成某些软件已有的功能。
       用户通过文档可以掌握具体的使用方法，提高了易用性。

    验收测试的标准：
        软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。
        所有测试项没有残余一级、二级和三级错误。
        立项审批表、需求分析文档、设计文档和编码实现一致。
        验收测试工件齐全。
        注意：alpha测试Beta测试都需要用户参加。
              但是，alpha测试是用户在开发环境或者是公司内部模拟实际操作环境的测试。
              Beta是由最终用户来测试，例如我们下载软件时经常带有Beta字样的版本。
        Beta 测试是验收测试的一种。
        α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
        α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。
        β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

针对手机软件的系统测试，通常包含以下角度：
    <1>功能模块测试：首先分析功能模块的功能项，测试每一个功能项是否能够实现对应功能。一般根据测试用例和软件本身的流程就可以完成基本功能测试。
    <2>交叉事件测试：又叫做事件或者冲突测试，是指一个功能正在执行过程中，同时另外一个事件或者操作对该过程进行干扰的测试。例如通话过程中接收到短信或者闹铃触发，应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机、花屏等严重问题。
    <3>压力测试：又叫做边界值容错测试或极限负载测试。即测试过程中，已经达到某一软件功*能[存储、网络、响应能力]的最大容量、边界或者最大承受极限，仍然对其进行相关操作*。例如连续接收或者发送短信，超过收信箱和SIM卡所能存储的最大条数，仍然进行接收或者发送，依次来检测软件在超常态下的表现，进而进行评估用户能否接受。
对手机可以施加的压力测试类型主要包括：
    ->存储压力：由于手机采用的是栈式存储，所以当一个存储块满了之后，程序员不做相应处理的话，就会导致其他存储区被删除。
    ->边界压力:边界处理问题一直是容易被忽略的地方
    ->响应能力压力：有时 某些操作可能处理的时间较长，如果在处理期间，继续进行其他操作时候就会出现问题。
    ->网络流量压力：执行较大数据流量的功能同时，在进行其他操作，使得网络流量始终处于很高的状态，检验各个功能是否依然正常工作，是否存在因为网络流量瓶颈引起的某功能异常。
    <4>容量测试：即存储空间已满时候的测试，包括用户可用内存/SIM卡所有空间被完全使用的测试。此时在对可编辑模块和存储空间进行操作，如果软件在极容状态下处理不好，将会导致死机或者花屏等问题。
    <5>兼容性测试：不同品牌、型号手机，不同网络，不同容量大小的SIM卡之间的兼容性测试。例如：中国电信的小灵通接收到中国移动或者中国联通GSM发来的短消息，需要验证显示和回复是否正常。
    <6>易用性、用户体验测试：在指定条件下，软件产品被理解、学习、使用和吸引用户的能力，是交互的适应性、功能性和有效性的集中体现。

OCUnit 是 OC 官方测试框架， 现在被 XCTest 所取代。
XCTest 是与 Foundation 框架平行的测试框架。
GHUnit 是第三方的测试框架。
OCMock都是第三方的测试框架。

网络管理员编写了shell程序prog1.sh,测试时程序死循环无法结束,可以通过下列方式结束程序