测试管理 高级培训教程 国家应用软件产品质量监督检验中心培训部.pptVIP

测试策略 策略：根据实际情况制定的行动方针和实施方式 测试策略：把软件测试用例的设计方法集成到一系列周密计划的测试流程中，为软件测试提供一个清晰的路线图，以指导软件测试的成功完成。 测试策略（2） 测试策略包括计划、测试case设计、测试执行、测试结果收集和分析 软件测试的组织 开发人员不适合测试自己的软件 独立测试组织（ITG）的存在必要性： 不受开发固有思维的影响 站在中立的角度，避免利益冲突 专职于查找问题，分工明确 更有利于VV中发挥作用 更利于对软件进行评估 ITG的测试活动（repeat） 独立测试组织的测试活动是软件质量保证的关键元素，代表了规约、设计和编码的最终检查 与开发独立，可以明确工作界面，减少开发人员和开发leader对测试结果的主观影响。 作为一个职能部门，与开发处于同等重要的作用。 ITG的职责 制定产品测试计划 划分每个测试阶段及测试重点 设计测试case 开发测试程序 执行测试，申报bug 向组织提交测试报告 进行技术转移 参加产品实施 贯穿瀑布模型的测试过程 测试流程举例 不成熟组织中的测试流程 测试有自己的周期，和开发生命周期并行 测试组和一个不成熟的开发组织一起工作，将感到非常痛苦 不成熟的开发组织将产生一个非产品化、混乱的、屡受搓折的环境中产生低质量的 不另人满意的结果 成熟组织中的测试流程 在一个成熟的开发组织中，测试组可以并能够集中精力在内部流程改进上 测试流程的有效改革将会成为促进不成熟组织改进开发流程的催化剂 测试什么时候开始 ？ 测试应从需求开始 测试越早开始，效率越高 缺陷放大 尽早开始测试 有50%的错误是在需求阶段产生的。修复这些缺陷的代价，远小于这些缺陷转移后的代价 抓住机会，在开发的早期进入测试，达到事半功备的效果 测试什么时候结束？ 测试没有止境，只是从开发转到测试，测试转到维护，维护转到客户 时间、资源不够的时候，就到了测试该结束的时候 量化的软件故障模型 测试结束的标准 建立在量化基础上 随着测试时间，单位之间里的bug数减少 当故障模型曲线趋近于直线，且单位时间发现bug很少，甚至为0时，可以做为一个milestone 随着运行环境、需求的变化，故障曲线会发生变化 测试因素（1） 在制定测试策略时，首先要分析出系统的主要测试因素。通过对测试因素的分析，制定出在整个软件生命周期中采用什么样的测试技术和方法。 测试因素（2） 符合度（Compliance） 确认系统与需求、标准、规则的符合程度。如系统设计是否符合产品需求，是否符合用户提出的业务标准、行业标准等。 此测试因素强调的是测试的依据是用户的需求、规范和标准。 正确性（Correctness） 系统的功能数据输入、处理流程、输出是否正确。 程序满足它的需求规约和实现用户需求的程度 测试因素（3） 易用性（Ease of Use） 这是一个共性问题，任何用户都希望自己所使用的系统是好用的。但对于不同的用户，对这个因素的要求程度不一样，有一些只运行在后台的进程，不需要操作员手工操作的系统，对此项的要求不高。 易掌握程度（Ease of operation） 这里强调的是系统的学习过程是否容易，指导手册是否完备、准确。使系统易学、易掌握。如windows等这种使用人数众多的通用系统，就要求非常容易的被掌握。 测试因素（4） 过程的可跟踪性（Audit trail） 操作的过程、轨迹是否有log记录，可以被跟踪。这在一些服务等级很高的系统中要求非常严格，如银行系统，要求对每个操作过程都有记录。 文件完整性（File Integrity） 对系统数据文件的完整性、安全性的要求。如数据库文件的完整性等。 服务等级（Service levels） 服务等级包括是否需要7*24小时不中断业务，是否需要非常高的保密控制，是否需要数据的决定准确等。测试系统需求说明书中对平均失效间隔时间(MTBF),故障停机时间(MTTR)的相关测试。 测试因素（5） 易维护性（Maintainability） 系统是否易于维护。 可以通过定位和修复一个错误所需要的工作量来衡量 权限控制（Authorization） 系统功能和数据的访问权限被分级 只有授权用户可以访问 加密方法安全，不容易破解 进程的连续性（Continuity of processing） 在临时或永久的软件故障和系统故障发生的时候，系统自动或手动进行恢复的可能性，系统其他相关软件能否正常运行的可能性 测试因素（6） 访问控制（Access Control） 检查系统的安全性，软件的安全性及保密性，是否有破坏软件安全性的方法和工具等。 可移植性（Portability） 可以在不同操作系统、不同数据库环境中运行 移植代码易于