素材docx.docx

1. 应用软件特点我这里提及的应用软件系统是指完成某一种特定应用功能的软件系统，它的特点是按照客户给定的具体需求，为客户量身定做一个软件系统，如：银行储蓄系统，公积金管理系统，商场或超市收银系统等，系统的应用限制在客户给定的范围内。应用软件系统的需求可以分为：业务功能需求（前台需求），批处理需求（后台需求），接口需求和响应需求四类，这些需求90％以上由客户给定，不到10％由项目组提出建议，由客户确认。2. 测试要领我这里说的要领不是具体的测试方法，而是需要中、高层领导和项目经理理解的，较宏观的测试方略。2.1. 要领一：给予重视多年来的实践证明，应用软件系统测试做不好的主要原因是：中、高层领导和项目经理对应用软件系统测试的不重视，表现在做项目计划时对系统的黒\盒测试（功能测试）没有留有足够的时间，没有指定测试责任人（在测试阶段专职负责测试）。是否对测试重视，关键看是否为黒\盒测试留有足够的时间，多长为足够的时间？开发周期的三分之一以上，如：计划项目开发周期为三个月，那么计划项目的测试时间应不少于一个月。注意，这里说的是开发周期的三分之一以上，而不是开发工作量的三分之一以上。测试跟开发（特别是编码）不同，不能采用人多-短期完成任务，应该采用小组（3到5人），有计划、步骤地，有充足时间地去完成测试工作。需要指出的是：测试工作可以与开发工作“并行”，方法是把整个系统分成逻辑上相对独立的子系统，如：系统S＝子系统A＋子系统B＋子系统C，子系统A开发完成后，测试与开发开始并行，测试组测试子系统A的时候，开发组开发子系统B，依此类推。当然，如果时间许可，整个系统开发完成后在进入测试，项目的管理更容易。是否对测试重视，关键看是否为黒\盒测试指派了有经验的测试责任人，测试组是否与开发组相对独立。测试责任人（测试组组长）最好是由有测试管理经验，或有责任心、懂业务的人担当。是否对测试重视，关键看是否为独立的测试组配置了至少是逻辑上独立的测试环境。测试环境必须与开发环境在逻辑上独立开来，最好在物理上也独立开来，否则系统版本无法控制，测试工作也无法有效进行。2.2. 要领二：客户参与应用软件系统将来是由客户使用的，需求是客户提出来的，或经客户认可的，所以应用系统的功能测试必须有客户的参与，我的经验证明，客户参与功能测试是一个双赢的方案，对加速开发进程，提高产品质量，使客户认可系统、掌握系统功能大有好处。为保证客户愿意，且有准备地参与系统功能测试，需要在与客户签订开发合同之前给予引导，最好得到客户高层领导的承诺，或以合同的形式确定客户参与系统功能测试任务。上一节提到，测试责任人是测试组的组长，测试组长应该是承接项目公司的成员，参加测试的客户统一受测试责任人的管理，特别是参加测试的客户的测试任务是由测试责任人分配的，否则测试工作将出现本该避免的混乱。2.3. 要领三：管理控制测试责任人负责整个测试工作的管理控制，其控制点为：指明测试点：以书面的形式说明当前允许测试的功能，以防止测试人员去测试开发还未完成的功能。明确测试任务：以书面的形式，以人天为单位分配测试任务。[Page]交换测试任务：假设第一天分配给甲、乙的测试任务分别为A、B，当他们都完成测试任务后，进行任务交换，即让甲测试任务B，乙测试任务A，这是提高测试覆盖率的一个简单有效的方法。严格测试流程：测试CASE的执行--填写问题表--问题表处理--系统升级--回归测试（问题跟踪确认）。测试CASE执行时，一旦发现问题，必须填写《问题表》。问题表由四部分组成：1 项目信息＋CASE ID＋测试CASE执行人信息； 2 问题描述＋签字； 3 项目组对问题的处理描述＋签字； 4 回归测试＋签字。问题表的第一、二部分由测试CASE执行人填写，第三部分由项目组填写，第四部分是在系统升级后，完成回归测试后，由回归测试人填写。实践证明，《问题表》用手工填写工作效率更高，因为手工描述可以图文并茂，易于不懂电脑，仅懂业务的测试人上手；其二是纸页《问题表》易于在测试组、项目组、配置管理组之间轮转。需要注意的是一张《问题表》最好对应一个问题，否则会给《问题单》的轮转带来不便。3. 测试的重要性软件开发过程可分为：需求，设计，实现和测试四个阶段，需求是项目组的输入，测试的系统是项目组的输出，重视项目组的输入和输出，就把住了产品的质量关。成熟的客户一定会积极参与测试，测试不到家时是不会允许系统投产的；成熟的项目组一定会安排充足的时间对系统进行测试，测试不到家时是不会将系统发布的。我们都明白：系统的问题越早发现，改正的成本越低，破坏性越小，所以，在系统发布前，要尽量多地把系统的问题找出来，其手段就是有计划、有组织地进行充分的测试。系统投产后发现的问题，其危害性被成倍放大，直接损坏了客户的利益和声誉，同时，客户将毫不留情地把“