Question

在测试工作中，主要的风险表现有以下几点：

1.需求风险

产品需求的不明确，对产品需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，测试用例维护成本增加，实时更新时存在误差。

2.测试用例风险

测试用例设计不完整，忽视了边界条件、异常输入等情况，用例覆盖率没有做到足够覆盖，测试用例没有得到全部执行，有些用例被有意或者无意的漏测，需求变更导致的测试时间被压缩等情况。

3.缺陷风险

某些缺陷偶发，难以重现，容易被遗漏；缺陷跟踪不够积极主动，没做好缺陷记录和及时更新，同样的缺陷，导致的原因可能不同，对这点没意识到导致的线上生产问题等。

4.代码质量风险

代码质量差，可读性差，重构性差，没做好注释等原因导致缺陷较多，修改难度增大；另外还有系统架构设计的不足，导致的扩展性不足，性能兼容差等问题。

5.测试环境风险

测试环境和生产环境配置不同，测试环境交叉影响较大，测试环境数据量不足导致的测试结果误差等问题。

6.测试技术风险

某些项目存在技术难度，测试能力和经验所限，技术水平相对较差导致测试进展缓慢，测试结果准确性不够。

7.回归测试风险

经常出现的问题可能是前端代码，当前端修改过一个问题后，可能会产生其他的前端问题。另外一个问题可能是刚开始项目交接的时候，本身该项目没有需求文档，以及产品经理，测试需求点的介入需要强依赖开发的口头沟通。

8.沟通协调风险

项目进行过程中需要多方沟通协调，不同部门，岗位之间的沟通、协作，难免存在误解、沟通不畅的情况，比如需求变更没有及时沟通，开发代码提交没有及时告知，测试结果的反馈不及时等问题。

9.研发流程风险

其中包括从产品需求评审、研发设计、代码提交、测试发布等一些列流程，流程的不规范不协调很可能导致很多问题；比如开发在不告知其他成员的情况下提交代码，发布没有预生产环境，生产出现问题无法及时回滚等。

10.其它不可预计风险

一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。对于这种情况，往往一时无法解决，建议做好备份方案和容灾机制，或者采用灰度发布等措施。

在写风险点的时候尽可能和开发在意见上达成一致。

其次，除了遗漏Bug等一些质量风险，项目风险的话尽可能由“大”到“小”的去思考，“大”是指方向性，比如兼容性，安全，性能，异常等等的角度入手，“小”是结合产品所在的一些细节。比如，一个移动端的产品要上线，可能因为测试时间有限我兼容性只测了一部分，兼容性问题可能是我的一个风险点；再比如，后端新增一个接口或者新增一个服务 ，性能和异常这块可能要考虑是不是一个风险点。