任务评估和风险项分析报告.docxVIP

软件产品项目任务评估和风险分析软件测试是一项高风险的工作，它是不可避免的，总是存在的。软件产品项目测试过程中不可避免地存在风险。蓝色字体为需要编辑的内容软件需求的风险软件需求本身不清晰或者开发商对产品的需求特性理解不准确有偏差，这样导致最终开发的产品功能可能不是用户真正想要的功能。由于软件产品项目是自主研发的产品，在产品设计初期，根据其他公司做的同类软件的相关功能，定制了软件产品的需求说明，这些需求在某些程度上可能不满足客户的全部需求，这就需要在软件产品的1.0版本发布后，根据客户的具体需求进行定制版的研发和测试。人员的风险：软件产品开发测试阶段，测试人员和开发人员的招聘从未停止，测试人员流动性较强，而且每个测试工程师测试的思维方式肯定有差别，所以测试工作多让这些工程师在测试每一轮后，再进行不同模块的交叉测试，从而导致测试的时间比预期延长。同时很多测试工程师介入到项目测试的时间太短，短期内不能全面的提交比较有质量的bug。测试环境的风险测试人员在测试过程中搭建的测试环境，虽然原则上是尽可能模拟用户实际使用的环境。但是不可能100%完全和用户的环境一下，尤其是车载环境，用于测试的3G上网卡只有几张，不能够搭建客户的实际使用环境，测试环境中基本用虚拟车台代替，这样就会存在一定的风险，因为有些软件的缺陷只有在特定的环境下（包括硬件、操作系统、杀毒软件和软件的不同版本的补丁和用户实际使用的数据等）才能出现。软件产品软件项目测试过程中主要以会议室环境为测试环境，会议室环境是有网通专网和电信外网环境组成。此测试环境不能应用于所有客户的使用环境。测试深度和广度的风险测试的广度，用户的操作肯定是千变万化的，测试工程师在测试的时候肯定不能100%覆盖到这些千变万化得操作。有些极端的情况容易被遗漏、测试不到。测试的深度，实际项目使用过程中，用户的并发操作是常见的现象。很多bug可能只能在用户并发的情况才会出现，而软件产品项目测试过程中由于具体条件限制不能模拟用户并发的情况，从而不能发现这些bug。测试工具本身可能产生误差测试过程中使用QTP等工具来模拟用户的手工操作，但是这种工具本身就存在误差、或者使用者操作不当产生的误差，比如：在项目后期的回归测试的时候使用自动化功能测试工具QTP进行回归测试的时候，由于修改了某些脚本导致QTP每次测试都能通过，但是到用户现场的话有可能会最简单的功能都通不过测试web客户端时，还用到了Loadrunner模拟并发测试环境，用Selenium IDE录制web客户端操作，并连接/s?wd=selenium%20rcrsp=3f=1oq=seleniumtn=baiduhome_pgie=utf-8rsv_ers=xn1rs_src=0selenium rc+eclipse junit编辑脚本进行强度测试。软件产品测试过程中使用到的工具还有抓包工具、进程资源利用检查工具、processxp、检查数据库的工具等，这些工具的功能没有经过严格测试，本身的误差不能忽视。测试资源的不充分硬件资源不够：具体监控项目中使用所有车载设备都是用3G卡连接，由于硬件限制，目前软件产品项目仅能使用4、5张电信、联通卡进行测试。软件资源不充分：软件产品平台属于应用软件，用户使用的操作系统、PC硬件多种多样，测试过程中不能完全模拟用户使用的软件环境来进行测试。软件产品平台测试认证服务器数据节点数量时，由于环境限制，测试中模拟了2万个节点，不能完全模拟10万个节点存储， 测试方法的执行和设计通过软件产品测试总结的报告可以看出，提交的bug很大一部份是web客户端、监控点管理、现场预览、轨迹分析、回放功能模块的缺陷，软件产品平台软件的主要功能模块就是这一部分。Bug修复情况表可以看出所有级别bug修复率都达到了92%以上，但是无效bug占用较多，达到13%，可见由于该项目前期需求不明确，是首次发布，所以提出了很多被归为“设计如此”的bug。软件维护阶段的风险软件维护包含两个主要的维护阶段：一个是软件生产完毕到软件试运行阶段的维护，这个阶段是一种真实环境的测试性维护，其主要目的是发现在测试环境中不能或未发现的问题；另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运行环境（包括硬件平台，软件环境等）时进行的软件维护，具体可能是软件版本的升级或软件移植等。对系统可维护性的轻视是大型软件系统的最大风险。在软件系统运营期间，主要的风险源自技术支持体系的无效运转。总结综上所述，该项目产品测试过程风险不可控制，随着客户需求的变化，风险会越来越大。下面是“十个小故事大道理”不需要的朋友可以下载后编辑删除！！！谢谢！！！小故事1、《扁鹊的医术》　魏文王问名医扁鹊说：“你们家兄弟三人，都精于医术，到底哪一位最好呢?　扁鹊答：“长兄最好，中兄次之，我最差。