朱少民全程测试第三讲

KISS – Keep it simple, stupid Don’t make me think
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
非功能性需求
非功能性质量需求，包括系统性能、安全性、兼容性、扩 充性，其测试需求会因不同的项目类型差异较大。 客户端软件，如字处理软件、媒体播放软件等占用较少资 源，在容错性、兼容性等方面要求高。 Web应用系统对性能、安全性等有很高要求 客户端/服务器应用系统。 大型复杂企业级系统。
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
软件即服务SaaS
SaaS (Software as a Service)是软件服务模式，厂商将应 用软件统一部署在自己的服务器上，客户可以根据自己实 际需求定购所需的应用软件服务。 On-Demand Service On-Premise Service 软件运行的服务质量（QoS, Quality of service） QoS要求是指定某些系统特性的技术规范。
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
用户界面及其显示要求
用户界面是和用户进行交互的窗口，其友好程度直接影响 用户对于软件产品或软件服务的满意度。良好的用户体 验，简单、方便和明了，让用户舒畅、愉悦
通用框架、浮动窗口和文字等整体布局合理 文字显示正常，且内容格式正确、美观。 色彩协调，风格前后一致， 文字标记和超链接可以打开和跳转成功 … …
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
主题
测试计划的作用与内容 需求评审 设计验证 测试范围分析 测试策略 测试风险
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
主题
测试计划的作用与内容
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
测试计划的内容
确认测试目标、范围和需求 识别测试风险，制订相应的测试策略 对测试任务和工作量进行估算 确定所需的时间和资源 进度安排和资源分派，包括团队角色、责任和培训 测试阶段划分，包括阶段性任务和成果 跟踪和控制机制
需求评审 设计验证 测试范围分析 测试策略 测试风险
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
什么是测试计划？
子曰：凡事预则立，不预则废，预即是计划。要想成功完 成软件测试这项工作，必须首先建立测试计划。
测试计划是项目计划的组成部分 测试计划依赖于软件组织过程、质量文化和方针。 测试计划是指导今后一系列测试活动的文件 测试计划更是一个过程，随着项目的进展不断更新
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
工作量估计
测试工作量是根据测试范围、策划任务和开发阶段来确定 的，测试范围和测试任务是测试工作量估算的主要依据。 测试任务由质量需求、测试目标决定 测试范围由产品（新）功能特性或测试任务决定。 代码质量越低，测试越要充分，回归测试次数与频率加大。 处在不同的开发阶段测试工作量不同。 自动化程度高，测试工作量就越低。 针对不同的应用领域、技术、编程语言，其估算方法不同。
需求评审归为静态测试范畴，包含了文档评审和技术评审 双重内容，通常通过正式的评审会议来进行。而测试人员 主要起着评审员的作用，检查需求定义是否合理和清楚。 明确自己的角色和责任 熟悉评审内容，为评审做好准备 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
SaaS的非功能性需求
性能要求，系统响应能力。 可用性, 7x24 不间断服务 可伸缩性，系统容量扩充能力，使系统可以支持来 自扩大用户群体的额外负载。 安全性要求，确定可能潜在的安全威胁并找到处理 策略。 可维护性要求，对部署系统进行维护的难易程度， 可维护性与可用性之间关系密切
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
功能性测试需求
功能性测试需求主要是根据产品规格说明书来检验被测试 的系统是否满足软件各方面的功能的使用要求，包括用户 界面的友好性。 程序安装、启动正常，有相应的提示框、错误提示 各项功能符合设计要求，正常运行并输出正确结果 功能逻辑合理，并能处理各种异常操作 能接受正确的数据输入，输出结果准确，格式清晰 系统的各种状态按照业务流程而变化并保持稳定 支持各种应用环境，能配合硬件设备 … …
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
需求评审重要性表现方面
发现需求定义中的问题，尽早发现缺陷，降低劣质成本。 保证软件需求的可测试性。 与市场、产品、开发等相关人员在需求理解上认识一致， 以免后期的争吵。 更好的理解产品的功能性与非功能性需求，为制定测试计 划打下基础。 确定测试目标与范围。虽然此后需求会发生变更，但能得 到有效控制，降低测试风险。
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
测试计划标准格式 -1
16 components of Test Plan (IEEE,1983)
1. 2. 3. 4. 5. 6. 7. 8. Test plan identifier （测试计划标识) Instruction (引言） Test Items （定义或主题词) Features to be tested （需要被测试的功能) Features not to be tested (无需被测试的功能) Approach (方法和途径） Items pass/ fail criteria （测试通过、失败的标准) Suspension criteria and resumption requirements （延迟 的标准和再恢复的要求) 9. Test deliverables (测试交付的内容) 10.Testing Tasks (测试任务
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
主题
测试计划的作用与内容 需求评审 设计验证
测试范围分析
测试策略 测试风险
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
测试范围分析
如何通过测试的执行来满足测试的需求，这就需要分析测 试的范围、任务和其他条件，从而估算工作量和测试时 间，安排测试进度和配置资源 功能测试范围，可以借助流程图和框图进行分析确定。 系统测试范围，性能、兼容性、适用性、安全性，需要 根据系统架构设计、业务需求和标准等进行分析确定。
zhu.kerry@gmail.com
测试计划标准格式 – 2
16 components of Test Plan (IEEE,1983)
11.Environmental needs （必备的环境) 12.Responsibilities (职责) 13.Staffing and training needs (人员和必需的培训) 14.Schedule (时间进度表) 15.Risk and contingencies (风险和相关费用） 16.Approvals （批准)
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
系统详细设计审查
作为需求定义和产品设计的重要输出，软件产品设计说明 书是用户与开发人员双方对于软件需求取得共同理解的基 础上达成的协议，对开发软件的功能、性能、用户界面及 运行环境等做出详细描述。 各方人员开发人员达成一致 软件设计规格说明书的审查 高层次审查与低层次审查 界面设计的评审
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
需求评审的标准
正确性 完备性 易理解性 一致性 可行性 易修改性 易测试性 易追溯性
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
测试人员在需求评审中作用
全程软件测试(3)
测试计划
Kerry Zhu
Zhu.Kerry@Gmail.com
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
隆中对
益州险塞，沃野千里，天府之土，高祖 因之以成帝业。刘璋暗弱，张鲁在北， 民殷国富而不知存恤，智能之士思得明 君。将军既帝室之胄，信义著于四海， 总揽英雄，思贤如渴，若跨有荆、益， 保其岩阻，西和诸戎，南抚夷越，外结 好孙权，内修政理；天下有变，则命一 上将将荆州之军以向宛、洛，将军身率 益州之众出于秦川，百姓孰敢不箪食壶 浆，以迎将军者乎？诚如是，则霸业可 成，汉室可兴矣
测试工作量的估算依赖于测试任务的细化，对每项测试任务 进行分解，然后根据分解的子任务进行估算。通常分解粒度 越小，估算精度越高。 列出本项目需要完成的各项任务：测试计划、需求和设 计评审、测试设计、脚本开发、测试执行等。 对每个任务进一步细分，可进行多层次的细分，直到不 能细分为止。这建立在对于每一阶段工作的细致把握。 列出需要完成的所有任务之后，根据任务的层次给进行 编号，就形成了完整的工作分解结构表。
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
系统部署设计的审查
系统部署设计的审查是基于软件服务的质量目标，用来审 查软件部署的目标、策略是否合理，是否得到彻底的执行。 着重是否服从和遵守部署设计的技术规范 逻辑设计的审查 物理设计的审查 可用性设计的审查 可伸缩型设计的验证 安全性设计的验证
测试需求
测试目标取决于软件质量需求，而这种需求分为功能性需 求和非功能性需求，功能性的需求相对容易确定，非功能 性的测试需求难以确定。 在制定测试计划之前，必须清楚测试需求 明确测试需求的优先级 测试需求分解得越细，对测试用例的设计质量越有帮助 详细的测试需求还是衡量测试覆盖率的重要依据 测试需求是规划具体项目资源和时间的基础。
问题
为什么在测试计划中谈需求评审？
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
需求缺陷
软件缺陷并不只是在编程阶段才产生，需求和设计阶段同 样会产生缺陷。
为什么软件需求定义中存在很多缺陷最多？
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
zhu.kerry@gmail.com
估算方法
工作分解结构表方法 功能点方法、 对象点方法 代码行预估 历史数据推算（相似规模、同类型） 经验法 （资深人员或专家小组） 综合方法
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
工作分解结构表方法WBS
模板：中文
测试计划 和 英文
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
主题
测试计划的作用与内容
需求评审
设计验证 测试范围分析 测试策略 测试风险
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
主题
测试计划的作用与内容 需求评审
设计验证
测试范围分析 测ຫໍສະໝຸດ Baidu策略 测试风险
zhu.kerry@gmail.com http://blog.csdn.net/Kerryzhu
系统设计的评审标准
设计技术评审标准。稳定、清晰、合理 非功能性质量特性的设计评审要求。安全、性能 、稳定、扩展、可靠。 评审的输入：体系结构文档、设计规范与指南、 风险列表 评审的输出：经认可的软件体系结构文档、变更 需求、评审记录 评审的检查点：软件体系结构、设计模式、部署 视图、进程视图、封装体、协议。