软件测试基本概念

一、软件测试：

      在需求正确的前提下，验证软件功能是否满足用户需求，并对软件质量进行度量，弄清预期结果与实际结果之间的区别，以满足安全性、稳定性。

二、软件测试与研发的测试：

    首先，

         软件测试和软件调试的区别：

        目的不同：测试是发现程序中的缺陷、调试是定位并且解决程序中的问题；

        人员不同：测试主要由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行；调试由开发人员完成。

         阶段不同：测试贯穿整个软件开发生命周期，调试一般在开发阶段。

   其次，

        技能要求：测试要求更广泛，即需要业务能力、设计和架构分析能力、测试手段和工具的使用，用户模型分析和理解，编程能力。

       难易程度：开发广度小，专业度高；测试广度大，专业度低。

       发展前景：自动化测试、安全测试等领域发展前景和研发基本一致。

       繁忙程度：一般比研发轻松，但敏捷模式下差距不大，产品发布前压力较大。

三、选择软件测试的原因：

      思维模式：

              逆向思维：开发盖房子，测试拆房子。不走寻常路。

              发散性思维：探求多项答案，例如：测试一台自动售票机。要多方面考虑：正向、逆向、边界、压力、性能、耗电量、断电、外观、没零钱等。

      兴趣及性格特征：

              好奇心、不浮躁、批判性思维。

      责任感：

              测试往往是产品的最后一个检验者，测试的工作成效很难衡量，测试用例执行、bug数目的多少都无法说明产品是否能够交给用户使用。所以，责任感是最重要的测试必备素质之一。

       能力：

              快速学习能力、沟通能力、文字能力、开发能力。

       压力：

              来自开发人员、用户、上级、自己的压力。测试人员的压力比想象中的更大。    

四、需求：

       用户需求：即甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。在开发的过程中，满足官方文档所需要的条件和职能；

       软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能，即系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件和权能。包括功能性需求和非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求、质量标准、或者设计限制。软件需求是用户需求的具体实现，是测试人员进行测试工作的基本依据。

五、bug:

      即程序错误，当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误；

      当没有需求规格说明书时，判断标准以最终用户为准，当程序没有实现其最终用户合理预期的功能需求时，就是软件错误。

六、测试用例：

       为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

七、软件的生命周期：

        需求分析、计划、设计、编码、测试、测试、运行维护。

八、开发模型：

（1）瀑布模型：

         start >>> 需求分析 >>> 计划 >>> 设计 >>> 编码 >>> 测试 >>> End

         是所有其他模型的基础框架，每个阶段都只执行一次，是线性顺序进行的软件开发模式；

         优点：强调开发的阶段性、强调早期计划及需求调查、强调产品测试；

         缺点：风险往往迟至后期的测试阶段才显露，，因而失去及早纠正的机会。

（2）螺旋模型：

         一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式，螺旋模式是渐进式开发模型的代表之一。对规模庞大、复杂度高、风险大的项目尤其适合；

         优点：强调严格的全过程风险管理、强调个开发阶段的质量；

         缺点：引入非常严格的风险识别、风险分析和风险控制，对风险管理的技能水平提出了很高的要求，这需要人员、资金和时间的投入。

九、增量、迭代：

         增量是逐块建造的概念，例如画衣服人物画，可以先画人的头部、再画身体、再画手脚；

         迭代是反复求精的概念，同样是画人物画，可以先画整体轮廓，再勾勒出基本雏形，再细化、着色；

         增量开发能显著降低项目风险，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的可预防的方式驱动产品的开发。因此，在此开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试、开发人员需要更加密切地协作。

十、敏捷：

         敏捷是有关软件开发的 会工程，其主要贡献在于更多的思考了如何激发开发人员的工作热情，其中scrum是比较流行的一种。

（1）scrum:

         scrum 由 product owner（产品经理）、scrum master（项目经理）和 team（研发团队）组成。其中，产品经理，主要负责整理 user story（用户故事），定义其商业价值，对其进行排序，制定发布计划，对产品负责；项目经理，负责召开各种会议，协调项目，为研发团队服务；研发团队，由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

（2）迭代开发：

         与瀑布不同，scrum 将产品的开发分解为若干个小 sprint（迭代），其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是 5 到 9人。每次迭代要完成的 user story 是固定的。每次迭代会产生一次的交付。

（3）scrum 的基本流程：

         Product backlog  >>>  Sprint backlog  >>>  Daily scrum meeting  >>>  Potentially shippable product increment

         产品负责人负责整理 user story ，形成 product backlog；

         发布计划会议：product owner 负责讲解 user sytory ,对其进行评估和排序，发布计划会议的产出，即制定出这一期迭代要完成的 story 列表，sprint backlog；

         迭代计划会议：项目团队对每一个 story 进行任务分解，分解的标准是完成该 story 的所有任务，每个任务都有明确的负责人，并完成工时的初估计；

         每日例会：每天 scrum master 召集站立会议，团队成员回答昨天做了什么，今天计划做什么，有什么问题；

         演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家反馈记录下来，由 po 整理，形成新的 story;

          回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下次迭代继续改进，达到持续改进的效果。

十一、测试模型：

（1）软件测试v模型：

          用户需求 >> 需求分析与系统 >> 概要设计 >> 详细设计 >>编码<< 单元测试 << 集成测试 << 系统测试 << 验收测试

          目的：改进软件开发的效率和效果；

          其中，单元和集成测试检测程序的执行是否满足软件设计的要求；系统测试检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需求或合同的要求；

          局限性：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。

（2）软件测试W模型：

         增加了软件各开发阶段中应同步进行的验证和确认活动，即明确表示出了测试与开发的并行关系；

         特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的；

         优点：有利于尽早地全面地发现问题；

         局限性：需求、设计、编码等活动被视为串行的，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

十二、配置管理：

         通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可塑性的过程。

         好处：1）能够对项目中的文档、代码等的变化进行优先管理；

                    2）能够方便的重现某个文件的历史版本；

                    3）能够重新编译某个历史版本，使维护工作变得容易；

                    4）能够使异地多团队开发、并行开发成为现实；

                    5）可提高项目组间人员流动时的工作效率。

          测试人员应该从配置库取源代码编译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭。

十三、软件测试的生命周期：

          需求分析 >>> 测试计划>>> 测试设计、测试开发 >>> 测试执行 >>> 测试评估

十四、如何描述一个bug：

（1）发现问题的版本；

（2）问题出现的环境；

（3）错误重现的步骤；

（4）预期行为的描述；

（5）错误行为的描述；

（6）测试数据。

十五、如何定义bug的级别：

（1）Blocker（崩溃）：

          阻碍开发或测试工作的问题，造成系统崩溃、死机、死循环、导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能菜单不能使用。

（2）Critical（严重）：

          系统主要功能部分丧失、数据库保存调用错误、用户数据丢失、一级功能菜单不能使用但不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题稳定性等。例如：用户所要求的功能缺失，程序接口错误，数值计算统计错误。

（3）Major（一般）：

          功能没有完全实现但不影响使用，功能菜单存在缺陷但不会影响系统稳定性。例如：边界条件错误，数据库中字段过多。

（4）Minor（次要）：

          建议类问题，不影响操作功能的执行，可以优化性能的方案。例如：提示语丢失，用户体验感受不好。

十六、如何开启第一次测试：

(1）阅读所有项目有关的文档；

(2）参加项目会议；

(3）熟悉项目所使用的测试管理工具、配置管理工具、获取对应的地址和登录方式；

(4）阅读已有的测试方案和测试案例；

(5）阅读旧有的bug库，了解系统功能；

(6）了解公司规范要求。

十七、测试执行：

（1）打开待测系统；

（2）打开测试管理工具用例模块，开始执行用例；

（3）发现bug;

（4）记录bug;

（5）沟通bug；

（6）验证以前提交的bug；

（7）确认本次测试完成

（8）编写测试 告

十八、如何发现更多的bug：

1）软件测试同样存在二八原则，80%的故障集中于20%的模块；

2）开发人员也存在二八原则，80%的故障集中于20%的开发人员；

3）逆向、发散性思维；

4）不局限于用例的需求交替

5）今早介入项目。

十九、因为bug和开发人员发生争执怎么办：

1）先检查自身，是否bug描述不清楚

2）站在用户角度考虑问题；

3）bug定级要有理有据

4）提高自身的技术和业务水平，不光提出问题，也要能提出解决方案；

5）开发人员不接受时，不要争吵（三方评审）