软件测试流程与文档写作.doc

软件测试流程与文档写作由安博测试空间技术中心/提供软件测试的各个阶段：PDCA戴明循环：是一个质量持续改进模型，包括持续改进与不断学习四个循环反复的步骤，即计划plan，执行do，检查check/study，处理action，戴明循环有时也被称为戴明轮或持续改进螺旋测试需求检查软件需求（规格说明书）:是否覆盖了用户提出的所有需求项用词是否清晰,语义是否存在歧义的现象是否清晰的描述了软件系统需要做什么、不做什么是否描述了软件使用的目标环境，包括软硬件环境是否对需求进行了合理的编号需求项是否前后一致，彼此不冲突是否清晰描述了软件系统的性能要求需求的优先级是否合理分配是否描述了各种约束条件测试需求的定义：确切的讲，所谓的测试需求就是在项目中要测试什么。首先需要明确测试需求（what），才能决定怎么测how，测试时间when，需要多少人who，测试的环境是什么where。测试中需要的技能、工具以及相应背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。 而测试需求是测试计划的基础与重点。为什么要做测试需求 明确任务、目标、风险、策略等 有效的制定测试计划 测试需求的依据与收集 1与待测软件相关的各种文档资料，如软件需求规格，usedcase，界面设计，项目会议或与客户沟通是有关于需求信息的会议记录，其他技术文档等。 2与客户或系统分析员的沟通 3业务背景资料，如待测软件业务领域的知识等。 4正式与非正式的培训 5如果依旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。 在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。测试需求的分析 系统测试阶段，需求分析更注重于技术层面，即软件是否实现了具备的功能。 待测软件的特性。不同软件业务背景不同，所要求的特性也不相同，测试的侧重点自然也不同。 测试的焦点。测试的焦点是指根据所测得功能点进行分析、分解，从而得出的着重于某一方面的测试，如界面、业务流等。测试需求的优先级测试需求的覆盖率和覆盖程度 测试需求的覆盖率通常是有测试需求与软件需求所建立的对应关系来确定的，如果一个软件的需求已经跟测试需求存在一对一或者一对多的对应关系，可以说测试需求已经覆盖了该功能点。 如果确定了所有的软件需求都建立了对应的测试需求，那么测试需求的覆盖率便是测试需求覆盖点/软件需求功能点=100%，但并不意味着测试需求的覆盖程度高。 根据软件需求不断的完善或实际测试中发生的缺陷，可以对测试需求进行补充或优化，并更新进测试用力中，以此来提高测试需求的覆盖程度。 注意：测试需求覆盖率不能完全说明测试设计的好坏软件测试流程（需求阶段） 需求分析阶段测试人员需要做哪些工作 活动项 作用参与需求调研 了解产品基本情况和 产品测试需求调研测试需求撰写测试计划 明确测试目标和方法，测试计划便于闭队交流配置测试环境 为执行测试做准备 独立有效的测试环境测试计划 定义：将测试计划定义为“一个叙述了预定的测试活动的范围、途径、资金及进度安排的文档，它确认了测试项，被测特征，测试任务，人员安排，以及任何偶发事件的风险。” 注意：重要的是计划过程，而不是产生的文档 在工作过程中，如果无法按照自己预定的进入完成，也不要害怕或者沮丧，进度的作用就像一把尺子，要用尺子来衡量自己，那些地方需要调整。 测试计划由谁来写？测试工程师 测试计划根据什么来写？用户手册等撰写测试计划测试计划注意事项 增强测试计划的实用性 坚持5W1H规则，明确内容与过程 采用评审和更新机制，保证测试计划满足实际需求 分别创建测试计划与测试策略测试计划的内容 1简介 1.1目的why：明确目标和方法便于团队交流 通过测试希望达到的目标，功能、性能、界面方面的 1.2背景：测什么产品参考需求说明书 1.3范围：测试流程的各个阶段要测什么 分别简要列出测试和不进行测试的性能指标和功能点 2测试参考文档和提交文档 2.1测试参考文档XX批文，XXX合同，可行性分析，需求规格说明书，用户手册 2.2测试提交文档测试计划 测试用例 测试日志缺陷报告测试报告3术语和定义（可选） 4测试策略 4.1测试策略（how）测试策略描述测试小组用于测试整体和每个阶段的方法。确定测试策略要从模块，功能，整体，系统，版本，压力，性能，配置和安装等各个方面来考虑。4.2测试工具5测试计划的内容（what） 功能的测试；整体考虑；如何确定优先级6资源6.1人力资源6.2系统资源7测试速度（when）各测试阶段资源要求及时间安排；项目里程碑8测试人员的任务分配9风险和问题测试设计 设计阶段的任务 需交付产品 测试设计的内容 对于设计进行评审测试的执行 测试执行 主要工作 测试用例的合理选择 BVT测试与冒烟测试 BVT测试 冒烟测试测试记录与缺陷跟踪（要有记录和报告） 测试记录 Bug 简单地说，bug就是软件做了没有期望它去做的事。 有些问题看似错误但不是缺陷；有些问题看似正确但却是缺陷，同一现象的既可能是bug，也可能不是。 Bug与软件缺陷的关系：软件缺陷是一个软件中的需求、体系结构、设计和应用上的错误。而bug是软件缺陷的实际证明。 软件缺陷有可能成为bug，但并非所有软件缺陷都产生bug 判断bug的方法 程序员希望改正的bug 使程序员拒绝花费时间的bug Bug的分类： 按严重程度（Severity）：系统崩溃、严重、一般、次要、建议按优先级（priorty）：高、中、低按测试种类按生命周期 Bug的严重程度和优先级 Bug的识别 Bug的定义 正确识别bug 再现bug 关于软件中随机出现的bug Bug复现 怎样有效记录bug 1尽可能减少开发人员的阅读时间 2包含所有重现缺陷的必要步骤 3方便阅读 4尽量简单一个缺陷一个报告 跟踪一个bug的生命周期New：新发现的bug，未经过评审Open：确认bug，打开bugFixed：修改缺陷Rejected：如果认为不是bug，则拒绝修改Delay：如果认为暂时不需要修改或者暂时不能修改，则延后Closed：修改状态的bug经过测试人员的测试验证通过Reopen：经过验证bug仍然存在，则需要重新打开bug，开发人员重新修改Bug的评审应该注意的问题：回归测试 重点：一是有没有产生新的漏洞，而是缺陷是否真的消除 主要目的：是验证对系统的变更没有影响以前的功能，并且保证功能的变更是正确的。测试的总结和报告 是对测试的过程和结果的汇总描述 其核心内容是两个： 一个是测试结果的汇总报告，是针对所测软件本身，使给所测软件一个客观真实的评价 一个是测试过程的汇总总结，使针对过程改进，回顾测试流程中存在的不足，加以总结改进 测试报告的编写软件测试的度量 软件质量评估 覆盖评价RFT：测试需求总数TX测试过程或测试用例表示的已执行的测试数TS是用完全成功没有缺陷的测试过程或测试用例表示的已经执行的测试数TC用代码