软件风险控制笔记

一. 软件需求

1. 软件需求不清晰，或者理解不准确有偏差（让有决策权的核心用户看到产品已经实现的每个阶段的功能，如果不是用户想要的东西尽早提出来，总之要让用户参与进来 ）
2. 需求变更频繁，在项目后期提出的需求变更；导致用例来不及更新，还有时间限制导致测试不充分（对于后期用户不停的提出需求变更作为开发商来说，应该多和有决策权的核心用户多沟通，争取更充分的研发时间和测试时间，或者最好能把后期提出的功能放到下一个版本中实现）

二. 人员风险
1. 核心测试人员的请假、离职（ 对于离职而延误测试的情况，测试管理者可以平时给核心人员配置一些可以候补的测试人员来向他们学习，可以立即补充上来）
2. 测试人员的态度、工作状态差（考评监督工作，如果发现不符，可约谈）
3. 测试人员测试技术，如产生测试的思维定式，有些问题的地方始终测试不到位（每个测试工程师的思维方式肯定有差别，所以可让测试工程师在测试每一轮后，进行不同模块的交叉测试）

三. 代码质量
1. 提测代码质量差，缺陷很多，对于测试工程师来说漏测的风险越大（对提测代码在前期做好单元测试，对核心模块代码一定要做codereview）

四. 测试环境风险
1. 测试环境不可能100%完全和用户环境一致，这样就会存在风险，因为有些软件缺陷只有在特定环境下（包括硬件、操作系统、不同软件补丁、和用户实际数据等）才会出现（尽可能的模拟用户环境，在测试时尽量和用户沟通要到真实用户数据进行测试，以减少风险）
2.
五. 测试工程师对产品的业务不熟悉
1. 不了解用户如何操作该产品和用户操作习惯（可找一些相关行业专家给测试人员培训，或者询问用户操作习惯）
2. 测试工程师介入项目时间短（在项目前期测试人员就应该介入到项目中，熟悉产品）

六. 测试深度和广度风险
1. 广度：测试工程是不能100%覆盖千变万化的操作。有些极端的情况容易被遗漏、测试不到
2. 深度：比如有些软件只有在特定的情况下；比如多用户并发使用软件过程中才会产生软件的缺陷bug；
（编写用例时尽量提高测试用例覆盖度（用例评审工作），特别是一些边界值、深层次的逻辑关系等。以及用户实际使用环境场景，如大用户量并发操作）

七. 测试工具本身可能存在误差
1. 测试工具模拟用户手工操作，但是工具本身存在误差或者使用者操作不当产生的误差；如QTP进行回归测试时，若修改了某脚本导致每次QTP测试都能通过，可能脚本该坏了
2. 进行性能测试时使用的Jmeter、Loadrunner等，这些工具不能100%模拟用户并发操作；比如模拟500个用户同时并发登录，但是这些并发都是从一台或者某几台测试机器上发出的请求，并不是真实用户实际环境的情况下
（1.对于自动化的测试工具，一定要选择一些知名大企业比较成熟的测试工具，比如：HP公司的Loadrunner，QTP或者IBM的系列测试工具
2. 测试工程师在使用测试工具的过程中应该大胆的排除一些不合理的测试值，比如：进行了5次的大用户的并发测试，其中有一次的测试结果与另外4次的测试结果偏差较大，那么测试工程师就可以排除这1次偏差较大的测试（因为这1次测试结果可能受到一些其他因素的影响而导致不准确，比如受到网络因素的影响等）。
3.另外测试工具仅仅是提高测试效率的，由于测试工程师在使用测试工具的过程中某些参数设置不合理而导致测试结果不准确。所以不要过分的相信测试工具，最后一定要进行人工的审核和检查才可靠。
4.另外可以用不同的测试工具运行相同的测试场景，如果不同的测试工具运行相同的测试场景的测试结果相近的话，可以认为这种测试是有效的）
八. 测试资源不充分
1. 硬件资源
2. 人力资源
3. 时间资源
（向公司里申请更多的测试资源，如购置独立的测试服务器把测试环境和研发环境分开；要求招聘更多的测试人员；测试管理者应当做好测试风险的预估，比如：在制定测试计划的时候要预留一定的多余时间以应对临时变化的一些特殊情况）