请选择 进入手机版 | 继续访问电脑版
 找回密码
 立即注册
  • 便民服务
  • 关注我们
  • 社区新手
  • 为什么要测试?
    • 非正常的运行
    • 自身的缺陷,代码-文档
    • 环境也会影响软件
    • 软件测试活动只是关键的质量保证活动之一
  • 什么是测试?
    • 制造业的定义:以检验产品是否满足需求为目标
    • 软件行业的定义,有多种说法:
      • 验证软件的正确性
      • 发现软件中的缺陷
  • 周期阶段
    • 乐视TV---无
    • 生命周期阶段
      • 客户问题引入
      • 可行性分析
        • 产品经理  项目经理  开发经理  学而思 架构师 技术大佬
        • 成本(人力  天数  )
        • 商业/法律
        • 政治风险:诋毁国家
        • 技术难关,根据公司现有的技术能力是否能够解决实现项目功能
      • 项目招投标
        • 看谁要得钱 谁相关的工作经历  时间周期
      • 项目立项
        • 成立项目小组
        • 人力安排 时间安排
        • 采购服务器
      • 需求分析
        • 产品经理 手机客户需求 输出需求文档 ;进行需求分析
        • 参与人员:所有参与项目研发的人员
        • 需求分析由谁主导:产品经理去宣导(哪个页面加什么功能 例:打印当前有页面的数据)
      • 开发阶段
        • 设计  编码  测试
        • UI设计师 :输出效果图
        • 开发工程师:进行编写代码
        • 测试过程师:对项目软件测试验证  (验证数据是否正确 )
        • 交付给客户进行验收
      • 维护
    • 生命周期模型有哪些?
      • 瀑布模型
      • V模型
        • 需求分析--产品经理根据用户的需求提炼为项目需求
          • 召开需求澄清会议
          • 经过多轮讨论分析最终形成一个基线化文档,叫需求规格说明书,简称SRS     
          • 基线文档:代表各方对该文档达成一致。可以进入下一阶段
        • 概要设计--HLD  项目分模块A、模块b、模块c》开发输出概要设计文档
        • 详细设计--LLD   针对每个模块中具体的功能怎么实现 》开发输出详细设计文档
        • 编码和实现:开发人员编写代码(代码打成压缩包文件 .war/.jar)
        • 单元测试:UT   又称白盒测试   对代码进行测试,由开发人员完成
        • 集成测试:IT   模块A、模块b、模块c        单独测试没有问题,放在一起 经常测试   又称灰盒测试   接口(api)测试
        • 系统测试 :ST  功能测试 黑盒测试 ,除了保证当前的软件功能正常使用还需要保证与第三方系统对接不会出现问题

          • 系统集成测试
            • SIT1:又称全量测试,需要测试所有编写的测试用例==》编写1000条测试用例需要全部在执行测试完成
            • SIT2:称回归测试==》450条
              • 回归测试测试哪些内容?
                • 测上一轮发现BUG的用例
                • 测试与上一轮发现BUG相关模块的用例
                • 每一轮都执行冒烟用例
                • 测试新增的用例
            • SIT3:回归测试==》120条
            • SIT4:回归测试==》50条
            • 上线硬性标准 0 BUG
              • 允许带易用性BUG上线(易用性BUG不会影响功能使用)
              • 当前版本发现的易用性BUG如果要留到下一个版本中解决
              • 必须做好记录并邮件告知项目相关成员
        • 2.png
        • 验收测试:UAT
          • α测试
            • 公司内部的开发和测试人员模拟用户行为操作软件,对此时发现的BUG进行修复
          • β测试
            • 产品已经交付到客户手中,此时出现BUG,客户进行收集发生抄送邮件
        • 上线 (发布)
          • 3.png
      • W模型
        • 4.png
          • srs澄清:需求评审,得到需求规格说明书
          • TPM:测试经理编写测试计划(规定的测试范围,人力安排,软件与硬件的资源,测试进度,风险评估)
          • 风险评估:
            • 新人参与测试
            • 项目需求延期提测
          • 项目组常用的评审
            • 交叉评审:测试组内同事之间进行评审
            • 组内评审:项目中开发、产品、UI设计、测试进行评审
            • 会议评审:项目中开发、产品、UI设计、测试进行评审、客户参与
        • testlink:是一款用例管理工具
          • TPM或测试骨干或运维人员搭建测试环境
            • 公司有哪些测试环境?
              • 开发环境:开发人员编码使用的环境
              • 测试环境:测试人员测试当前项目软件的环境
              • 预发布环境:模拟用户使用场景,产品经理验收使用
              • 生产环境:线上环境,真实环境
            • 环境搭建好之后,开发人员将开发的功能代码打包,交友TPM或者运维人员精选部署测试环境,部署完成之后重启服务器,就可以通过浏览器访问,项目部署一般都是在服务器上
      • H模型
        • 5.jpg
          • 冒烟测试
            • 冒烟测试SIT1系统集成测试之前执行,在测试用例中选取部分用例进行测试
            • 冒烟测试定义:用主体功能进行测试
            • QQ登录功能主体功能是什么?qq能登陆成功
            • QQ注册功能主体功能是什么?成功注册新的QQ
            • 冒烟测试不通过,版本打回,开发人员再次重新编码修复,修改完之后再次进行打包,再次打包部署,再次进行冒烟测试,直到冒烟测试通过为止
          • 项目与产品:先有项目然后才有产品   
          • 项目与版本:一个项目有多个版本出现
      • 敏捷开发模型
        • 周期短:1-2周一个版本
        • 轻量级:每个版本的任务量不会太大
        • 晨会:15分钟
          • 对前一天工作总结
          • 对当天开发工作进度安排
          • 是否存在延期风险
      • 迭代开发模型
        • 将复杂且周期长的项目,划分多个独立的功能模块分索格版本开发上线
      • 增量开发模型
  • 测试的基本原则?
    • 测试的标准是用户需求
    • 测试部仅仅是单纯的软件本身的测试
      • 了解功能背景目的
      • 软件是否受到外界因素的影响(弱网/断网)
    • 软件外在没有失效不代表软件系统是可用的
    • 软件的完美度每天完全正确的,测试只能帮助软件更加完美,更加正确
    • 穷尽测试是不可能的
    • 测试应该尽早介入
      • 需求分析评审对需求理解更加透彻,为后面输出测试用例和测试工作打好基础
      • 确保开发、测试和TPM对接是一致的,规避后面更能开发出现错误
      • 尽最大可能降低项目延期风险
    • 二八原则
      • 二八定律
        • 80%的错误出现在20%的区域
    • 杀虫剂效应
    • 测试活动依赖测试对象
    • 尽量选择第三方测试
  • 测试活动的生命周期
    • 6.jpg

分享至 : QQ空间
收藏

0 个回复

您需要登录后才可以回帖 登录 | 立即注册