当前国内测试现状：
1. 没有明确统一的测试标准
换言之，没有比较标准的测试模式，大家较多基于对业务的理解，再结合工作经验进行测试点拆解，但没有统一的测试标准，项目就会存在因人的测试思维差异，在质量方面比较难持久的保证质量。
2. 容易忽略难复现的问题
项目中无法避免一些难复现、难修复的问题，而这部分问题排查投入精力多，也相对比较容易被忽略，排查不及时或被搁置的情况，就导致存在一定的隐患。
3. 自动化覆盖不全
当前国内自动化测试缺口还是比较大，大多数仍处于手工测试阶段，产品质量的稳定性相对较不可控，人力投入比较大，产出效率也相对低些。
4. 测试员投入较多精力在测试执行
以往对测试岗的定位就是测试执行，发现Bug，验收Bug等，做了一定测试之后，就会发现测试员最大的价值是在于测试思维，即如何将测试设计做的“精而简”，能够以精简的测试用例覆盖更全的测试点；测试员的精力应该更多投入在测试设计，据了解Google，测试执行转到各自模块负责的开发同学执行。
PS：推荐大家一本书《Google软件测试之道》，文中提到Google内部测试员主要负责测试设计，至于测试执行由测试员提供详尽的测试方案及测试设计，由开发同学执行。
5. 程序与测试沟通，较难传递并识别风险
测试与程序的岗位差异，及岗位关注点不同，程序偏向深度，而普通的测试偏向广度，配合时就容易出现信息沟通不到位的情况，外加也存在一个比较现实的情况，很多人初学者对测试岗位有个认知，当下测试岗入门门槛比较低，是很多想从事软件行业但能力不足的首选岗位，导致测试岗的整体水平相对比较低，也就出现了测试对程序语言、实现机制、架构不了解，在程序与测试沟通上，出现难沟通、信息传递不到位的问题，从而比较难识别到风险存在，导致测试覆盖不全的情况。
6. 故事开发过程中，容易忽略用户真实需求
这点同时也适用于开发同学，很多时候都是按着需求文档进行实现，只是纯粹的实现功能，但忽略了用户的真实需求，所以就有可能出现到交付出去后，才发现需求不合理的情况，或是在测试阶段才发现需求不合理，从而再次优化，导致开发节奏受影响，用户体验不好等问题。
7. 质量保证不止测试负责，是项目全员的职责
包括到现在，很多项目内仍存在这样的思维，认为质量保证属于测试职责，与其他岗位无直接关联，这也就导致了跨部门配合、需求迭代等各种问题，实际上，版本质量是项目全员的职责，大家都需要共同承担质量保障，这样才能快速有效的产出符合预期的产品。
质量保证赋能：
流程除了当前常规的流程外，还可以在以下几点继续优化。
1. 测试左移
主要提到尽早参与测试，尽早发现问题，从而降低开发成本并保持质量，同时也提高了用户体验，测试左移不止局限于项目前期，而是贯通整个版本周期。
从版本前期测试开始参与，除了了解需求，还可进行需求分析，暴露设计漏洞，沟通实现方案，产出测试方案，提高用户体验等，能力足够的情况，也可以给开发提供可行性的建议；
持续集成，可以让反馈回路更短，同时也减少一些人力的投入，使一切尽可能自动化，快速迭代。
2. 测试右移
测试右移，主要是在测试后或版本发布之后，针对线上版本进行性能监控、安全监控、问题日志上报、及用户体验反馈等。
规范
1. 测试角度的需求分析、测试方案
前期进行需求分析、产出测试方案，供设计、开发同学在前期设计阶段、开发阶段产出更有效的版本交付给测试，降低版本迭代成本。
2. 相对完整的可执行标准
当前比较难有完整的可执行标准，可以通过之前遇到的问题进行复盘，整理问题提供设计、开发、测试进行回溯、总结、产出可执行的解决方案、并落地推行，包括测试点补充、规避方案、保护机制、完善模板等。
3. 发布清单及注意事项
如当前正在执行的Checklist。
4. 线上问题诊断信息收集清单
除了收集线上问题外，还需要复盘，同第二点。
结对与评审
1. 需求评审、单元测试、自动化测试、日志监控等
需求评审：可以协助产品、设计同学产出较为完善的需求案，包括开发的设计方案；
单元测试：目前主要开发在做（个人在这方面也是欠缺的）；
自动化测试：（个人在这方面也是欠缺的）尽可能做到能与版本同步；
日志监控部分：目前对保存在客户端本地的日志，获取比较难，单靠联系用户来获取的方式，显得有些被动，建议可以将客户端本地产出的日志，自动上传到某一地址，便于获取日志进行问题排查。
2. 头脑风暴测试方案测试方案评审
（个人偏向产出脑图后，以简短的快速碰撞，不用纠结一些表现细节（细节体现在测试用例上））。
3. 业务价值驱动测试
最好的状态是：项目全员都能对产品熟悉，了解产品定位及针对的用户群体，结合自己岗位的优势，在版本各阶段都能站用户角度，提出建设性的建议，共同产出更靠近用户的真实需求的产品。
4. 提升设计、开发、测试、运维的配合
配合默契，可以无形中提升质量与效率。
