测试流程-测试管理.doc

全程测试笔记 一、测试项目启动及测试计划 1、需求评审 需求评审的目的： 对软件进行正确性的检查，发现需求定义的问题，尽早发现软件缺陷，降低风险。 保证软件需求的可测试性，确认客户的需求和产品质量需求都是明确的、可预见的并被描述在文档中，将来可用某种方法来判断、验证这种需求或特性是否已实现。 使得大家认识一致，避免后期产生不同的理解，引起争执。 更好的理解产品的功能性和非功能性需求，为制定测试计划和测试方法打下基础，特别是为测试范围、工作量等方面的分析、评估工作积累充足的信息。 确定测试目标和范围，虽然此后会有需求的变更，但可以得到有效的控制，这样可降低测试的风险。 注意事项： 明确自己的角色和责任。 熟悉评审内容，为评审做好准备，做细做到位。 针对问题阐述观点，而不时针对个人。 分别讨论主要的问题和次要的问题。 在会议前或会议后可以就存在的问题提出自己建设性的意见。 提高自己的沟通能力，采取适当的、灵活的表述方式。 对发现的问题跟踪下去。 向自己问问题： 需求是否都是用户提出来的？有没有画蛇添足的需求？ 有没有漏掉什么需求？有没有忽视竞争对手的产品特性？ 需求文档中，是否正确描述了需求？ 我的理解和他们的理解一致吗？ 需求评审结果： 所有参与方达成一致。 已发现的问题被阐述清楚、被修正。 软件测试观点 软件测试的辩证观点： 验证软件是“工作的”，以正向思维方式，针对软件系统的所有功能点，逐个验证其正确性。 证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。 软件测试的风险观点：测试被定义为“对软件系统中潜在的各种风险进行评估的活动”。 有人将开发比作打靶，目标明确，就是按照设计规格说明书去实现系统的功能。把测试比作捞鱼，目标不明确，自己判断哪些地方鱼多，就去哪些地方捞，要捞什么鱼就选择什么样的网。 80/20原则，针对用户最常用的这20%功能的测试会得到完全、充分地执行，而优先级低80%的功能测试就可能由于时间或经费的限制，降低测试的要求、减少测试工作量。 软件测试的经济学观点：一个好的测试用例在于它能发现至今未发现的错误。 软件测试不仅仅局限于“和客户的需求的一致性、适用性”，而且要增加其他的要求“开发成本控制在预算内、按时发布软件、系统易于维护”等。 软件测试的标准观点：软件测试可以定义为“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试=VV。 “验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。相当于以软件产品设计规格说明书为标准进行软件测试的活动。 “有效性确认”是确认所开发的软件是否满足用户真正需求的活动。主要通过各种软件评审活动来实现，包括让客户参加评审和测试活动。 软件测试目标： 为了更快、更早地将软件产品或软件系统中所存在的问题找出来，并促进系统分析人员、设计人员和程序员尽快的解决这些问题。 3、测试组长的人选： 测试组长将来要负责测试组的日常管理，更重要的是确保软件测试计划、测试用例的执行和执行质量，使项目获得成功。测试组长不仅要有良好的技术、产品分析能力和解决问题的能力，包括对开发平台和系统运行平台的了解，在相关的数据库、网络、编程语言等领域的经验，而且要有丰富的测试工作经验，熟悉测试流程、测试方法和自动化技术，能解决测试工作中可能遇到的各种问题。 测试组长的责任偏重于测试项目的计划和跟踪、有效测试策略的制定和测试小组的团队管理等，其主要责任如下： a) 负责一个独立的测试项目及测试组的管理工作。 b) 制定整个项目的测试计划、测试策略，包括风险评估、日程表安排等。 c) 负责工作量的预估和测试项目内部的资源、任务安排。 d) 熟悉产品的功能、特性，审查产品需求规格说明书，并提出改进意见。 e) 审查系统、程序设计说明书。 f) 验证产品是否满足了规格说明书描述的需求。 g) 对项目组成员进行培训和指导。 h) 作为测试组代表，参与项目组的有关会议，如缺陷复审或清理会议。 i) 根据需求设计文档和代码，负责和参与测试用例的设计和评审。 j) 参与代码的审查、检查单元测试的状态。 k) 选择测试工具或拟定测试脚本的结果，指导或参与脚本的开发。 l) 确定和审查测试环境的配置，协助测试实验室管理员在本项目测试环境的工作。 m) 实施软件测试，控制测试进度，并对所发现的缺陷进行跟踪分析和报告。 n) 解决软件测试中的项目问题，或者将这些问题反馈给项目经理或测试经理，推动这些问题得到及时合理的解决。 o) 编写项目的整体测试报告，保证产品质量。 p) 负责项目的总结，总结经验、吸取教训。 产品质量不是靠测出来的，