软件测试方案相关风险 软件项目风险管理方案
软件测试过程中有哪些风险
测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。
在测试工作中，主要的风险有： 一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对； 二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏； 三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够； 四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智； 五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等； 六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差； 七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大； 八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。
前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。
最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。
针对上述软件测试的风险，有一些有效的测试风险控制方法，如： 测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查； 有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。
如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。
这时处理这个缺陷所带来的风险就很大，对策是去掉（Diasble）那个新功能，转移这种风险； 有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险； 为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如： 在做资源、时间、成本等估算时，要留有余地，不要用到100%； 在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中； 对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司， 项目不会受到严重影响，仍能可以继续下去； 制定文档标准，并建立一种机制，保证文档及时产生； 对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换； 对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。
要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。
与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。
软件测试过程中有哪些风险
风险： （1）没有详细设计说明书；解决方案：测试人员要在开发阶段对相关设计及需求文档进行分析，对大体模块功能进行分类，分析业务逻辑，在不清楚的地方及时与开发人员沟通。
风险： （2）没有统一的界面设计规范。
解决方案：与项目负责人确认测试标准。
开发方面：风险： （1）所有模块开发没有统一设计，开发人员有自己的设计方式；解决方案：与项目负责人确认标准方式，与标准方式不一致的地方全部以BUG形式提交。
风险： （2）需求变更开发。
解决方案：建议将需求变更形成文档，对没有文档的需求变更，在测试过程中发现及时与开发负责人确认，并存档相关变更文档。
测试本身：风险： （1）人力资源；解决方案：保证稳定的人员安排。
风险： （2）硬件资源；解决方案：事先分析测试所需硬件资源，及时申请，保证测试工作顺利进行。
风险： （3）版本控制；解决方案：严格控制版本，BUG以版本为单位进行提交。
在测试过程中及BUG确认阶段禁止任何代码更新。
风险： （4）测试时间不足。
解决方案：动员测试人员完成测试任务，必要时，应给予相应物质奖励。
测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。
在测试工作中，主要的风险有： 一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对； 二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏； 三、需求的临时突然变化，导致设计的修改和代码的重写，测试时间不够； 四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智； 五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等； 六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差； 七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大； 八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。
软件测试风险评估
基于风险的软件测试是指首先评估待测软件的风险点，然后根据不同的风险点采用不同的测试力度。
现在业界通常的对风险点的评估的做法，就是对每个功能点从业务和技术上考察。
业务上是指这项功能失效，对系统的影响。
从技术上考察是指实现这个功能的技术难度大不大，是移植的还是新研发的？一般将此两项称为重要性和概率，分别赋以1到5的权值，5为最大可能或最重要。
比如如果重要性为5，概率为4的一个功能点，那么乘积为20，这就是一个高的风险点。
对于高的风险点，那么就应该用充足的时间，充足的人员来进行测试。
你明白了吗？
软件测试的风险有哪些？
(1)合同风险 签订的合同不科学、不严谨，项目边界和各方面责任界定不清等是影响项目成败的重大因素之一。
预防这种风险的办法是项目建设之初项目经理就需要全面准确地了解合同各条款的内容、尽早和合同各方就模糊或不明确的条款签订补充协议。
（2）需求变更风险 需求变更是软件项目经常发生的事情。
一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损（实际上项目建设方也面临巨大的风险）。
预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更申请。
（3）沟通不良风险 项目组与项目各干系方沟通不良是影响项目顺利进展的一个非常重要的因素。
预防这种风险的办法是项目建设之初就和项目各干系方约定好沟通的渠道和方式、项目建设过程中多和项目各干系方交流和沟通、注意培养和锻炼自身的沟通技巧。
（4）缺乏领导支持风险 上层领导的支持是项目获得资源（包括人力资源、财力资源和物料资源等）的有效保障，也是项目遇到困难时项目组最强有力的“后台支撑”。
预防这种风险的办法是主动争取领导对项目的重视、确保和领导的沟通渠道畅通、经常向领导汇报工作进展。
（5）进度风险 有些项目对进度要求非常苛刻（进度要求不高的项目，我们同样要考虑该风险），项目进度的延迟意味着违约或市场机会的错失。
预防这种风险的办法一般是分阶段交付产品、增加项目监控的频度和力度、多运用可行的办法保证工作质量避免返工。
（6）质量风险 有些项目，用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。
软件测试的流程
一般测试流程：1.需求分析阶段：只要就是对业务的学习，分析需求点。
2.测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。
《测试方案》编写完成后也需要进行评审。
4.测试方案阶段：主要是对测试用例和规程的设计。
测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。
这时开始编写用例才能保证用例的可执行和对需求的覆盖。
测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。
其中操作步骤和预期结果需要编写详细和明确。
测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。
同样，测试用例也需要评审。
5.测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。
...
-