What Is Testing & QS in My Mind?

Job

我理解的测试及质量保证

测试是保证软件质量的下策

可以从两方面验证一个软件正确性：

  • Formal Verification（形式证明）
    给出一个描述，软件应该怎么样，通过逻辑分析或数学推理，证明我这个功能是100%不会出错的，没有特例。
  • 测试
    根据预设的条件，选取一些正常的，特殊的或边际点，看能否得出预期的正确的或错误的结论，肯定有一些路径是没有测试到的，只有一部分测到的地方把握没错。

可知，这两者在覆盖度是不可同日而语的，做Formal Verification更加严谨。
但是经常做Formal Verification 花时间或不可能，比如：规则不明，需求不明确，只有通过测试，在快速迭代过程中，书写足够多的单元测试以及进行回归测试，来尽可能保证相对稳定的产品质量。
总之，测试虽然是下策，但能够给你一个清晰的客观的指标，给你信心进行下一个迭代。

为什么都讨厌测试？

  1. 代码经过严密推敲，已证明了。
  2. 写测试(机械劳动)很痛苦枯燥，没有在创造东西（上帝视角）。
  3. 可测试的代码，必然是啰嗦的，通常是实现功能代码的两倍，甚至更多。
  4. 好的逻辑分析可以减轻测试。

质量保证是什么？ 在业界怎么做的？一个系统工程

涉及一个产品的各个方面，从需求、设计到编码、测试、发布，这就需要巨大的资源投入与研发，比如：CMMI3，MSF , 与我们情况类似的是互联网startup企业，他们最为看中的三个环节：

编码阶段：规范及Code Review:

  • phabricator（http://phabricator.org/） from facebook
  • google’s C++ coding style guide for all dev languages
  • 开发流程：
    在 Phabricator 上建立 task -> 提交 diff 并关联 task -> 单元测试 -> reviewer 审查代码 -> 合并 diff -> 上线测试 -> 关闭 task。

测试与持续集成、发布阶段：

  • 为什么大家都用持续集成（CI）？

    1. 尽快发现build break
      CI系统会在build break的时候自动发email给所有人，上面写明了是哪个revision的问题，是谁提交的，非常有助于快速发现修复问题。而且工程师也容易养成习惯，在提交代码后，看到一封build成功通知email后再下班走人。
      所有的build事故都有记录，方便我们发现团队管理的问题。
    2. 用基本的测试用例尽快发现问题
      CI系统不仅是编译，还会做代码规范检查，静态代码扫描，跑自动测试用例，记录下崩溃异常，内存泄漏 cpu占用异常等问题，尽快发现问题尽快修复，保证当天能提供一个基本没问题的build给测试组。
    3. 多版本发行
      复杂系统需要编译生成多个发行版，比如跨平台的软件要有 Windows Linux MacOS版本，还要有32bit 64bit版本，有个还能跨CPU，生成x86 arm版本。众多的release只能靠CI自动配置完成，手工做是不可能的。

  • 测试与持续集成：
    Test
    jenkins
    相辅相成，一个典型的场景：
    jenkins 被动触发（代码check in之后）

    • 代码的静态扫描，编写风格、安全风险等
    • 执行UT
    • 执行BVT，基础的UI自动化功能测试
    • 编译，混淆，打包测试
    • 客户端与服务器交互的api 测试
    • 服务器纯api 测试
    • 自动化部署

    jenkins 主动触发（定时的测试）

    • 主要核心功能的ui自动化
    • 多分辨率，多版本自动化测试
    • 自动化性能测试（10项左右指标）
    • 老版本的回归测试
    • 自动化部署

    UT：单元测试
    BVT：Build Verification Testing），也就是所谓的小版本验证测试，冒烟测试
    IT：Integration testing
    ST：System Test
    UAT：User acceptance testing 用户接受测试
    自动化部署: 如何把最新版本的应用快速的部署到测试用户的机器上以收集反馈，或者做一些探索性的测试。

  • 发布阶段

    • 发布审核
    • 灰度发布
      从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。在此过程中，产品团队根据用户的反馈及时完善产品相关功能。
    • 正式发布

产品发布后，数据收集分析与监控告警

  • 线上：诊断、监控告警、质量报告
  • 线下：数据分析、告警、错误分析
  • Crash：SDK、分析
  • 舆情反馈

so，一个互联网企业的大概的研发流程大概是这样的：
image

当前环境

  1. 多个项目：支付、家庭组、融合通讯、卡组、多媒体…
  2. 多种开发语言： C++、Java、Python、PHP、JSP、C#
  3. 终端类型：Window、Linux、IOS、Android、Web
  4. 产品类型：参差多态。不同类型、产品测试要求也不同，比如支付和多媒体测试的要求完全不同

结合当前实际情况，能做的：

组织架构与流程

  • 独立：成立测试池，统一分配测试资源，对相似测试类型的产品进行统一归纳总结，建立测试问题库，并抽象形成自动化工具。
  • 服务：专项专人，每个项目配备专门的测试人员为其服务，对出问题较多的模块进行重点分析同时反馈给研发项目组。
  • 流程：建立测试、发布流程，产品要发布，必须按照测试清单上的测试项目，通过测试，提交测试报告，署名通过，署名发布。

善用自动化测试与测试工具方面

  • 指标驱动，细化以Jenkins为中心的持续测试、集成工作
    以下是基本的单元测试目标：

    1. 每千行代码缺陷个数小于4个
    2. 单元测试通过率100%，行覆盖达到75%以上
    3. 静态代码检查一级缺陷0个
    4. 测试用例需求覆盖度100%
    5. 测试用例密度30个/千行
    6. 确保经过现网商用标准测试，稳定性达到 99.99%

    科管已提供基本的Jenkins工具，但是还需要根据项目的实际情况以及需要测试的项目，添加各种自动化插件（比如代码覆盖率的插件、代码静态检查插件等等），编写大量的自动化脚本 ，（这也是科管的Jenkins用不起来的一个原因）

  • 善用及开发自动化测试工具

    1. 引入多种静态扫描引擎，并定制多种规则：适配规则、Crash规则、框架约定规则、安全规则等，并且不断地将测试阶段、线上问题等总结抽象成新的扫描规则补充进入扫描引擎。
    2. 在测试阶段包种插入相应的测试SDK，并且这种SDK不会侵入应用代码，所以只需要在发布的时候去掉测试SDK即可。测试SDK可以在测试人员（包括外包适配测试人员）正常使用过程中自动检测并上报问题，这样就可以在同一的平台上看到研发过程中的质量情况并进行修复。
    3. 流量、电量、内存、性能、适配等非功能专项测试工具。

    需要根据项目实际情况，研发或购买相应的服务（比如手机适配测试，国内已经有专业的公司提供服务，友声科技，http://www.uusense.com/

完善数据收集分析与监控告警

  • 在线诊断、监控告警、错误分析
  • Crash：SDK、分析

  • 增加用户反馈入口

    需要根据项目实际情况，一些已有，一些需要研发

目录

  1. 1. 我理解的测试及质量保证
    1. 1.1. 测试是保证软件质量的下策
    2. 1.2. 为什么都讨厌测试？
    3. 1.3. 质量保证是什么？ 在业界怎么做的？一个系统工程
      1. 1.3.1. 编码阶段：规范及Code Review:
      2. 1.3.2. 测试与持续集成、发布阶段：
      3. 1.3.3. 产品发布后，数据收集分析与监控告警
    4. 1.4. 当前环境
    5. 1.5. 结合当前实际情况，能做的：
      1. 1.5.1. 组织架构与流程
      2. 1.5.2. 善用自动化测试与测试工具方面
      3. 1.5.3. 完善数据收集分析与监控告警