test plan
请教:想知道一些有关手机测试test plan的知识,有没有这方面的讲演稿和试题?期盼各位的帮助,不甚感激!!!! 测试计划还是测试用例？ 是测试计划,手机软件测试的测试计划?
谢谢站长!!! http://www.51testing.com/N_download/salonDL.htm
古乐胶片中有测试计划的内容 太感谢站长了.
可是那个pdf档里面只讲了"测试计划的管理",对测试计划的内容没有作太多的讲解,有点可惜.
请问站长:是否有相关的资料是有关"测试计划内容"的,比如:如何来制定一个测试计划,面对一个测试项目,该如何制定一个测试计划呢?
手机软件测试计划
分阶段来考虑吧！开发过程无非就是mmi单元模块测试、系统测试和field trial验证测试！ 如果针对某一个单元模块测试来说,我应该怎样制定一个测试计划呢?如果拿到一个模块就没有计划的去测,会带来很多的重复劳动或者"盲点"。
如果是一个项目的话，就必须要有一个完善的测试计划。
我现在对一个测试计划一点概念也没有，不知从何下手。
多多指教！！！谢谢！！！
需要区分几个概念
测试类型或阶段，测试层次；前者必须认清测试“哪些方面”，后者请认清“由谁组织并完成”。测试计划主要依据质量特性来制定，如功能性测试类型体现在用户行为，交互连通性测试类型体现在针对接口部分测试，性能测试类型体现在大量冲突或批量数据处理带来的负载强度，还有是否符合标准符合生产规程等
针对某一个单元模块测试来说,应该协调详细设计文档、接口文档和业界标准来制定用例和测试计划
手机系统测试过于复杂所以重要
上述建议虽处在系统测试阶段，但过于复杂，所以重要。再则目前大多基于参考设计开发模式，单元测试和集成测试实施上造成很多困难。另参看“每日一帖”
“测试计划－－挂起准则和恢复需求” 谢谢版主,看了你的回复,让我受益不少.
测试计划要针对不同阶段不同类型的测试来制定,还要考虑资源以及其右它一些辅助因素.
我查在相关资料,觉得这份资料是不错的,版主你看看这个测试计划是否适用于手机软件测试.因为我觉得手机测试本身也带有一些特殊性.对于手机软件的黑盒测试者来说就更要注重测试的方法,这样才能结累更多的测试经验,学到更多的测试方法.
“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。
产品基本情况调研：
这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。
具体的要点有：
目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置，粗略的估计测试大致需要的周期和最终测试报告递交的时间。
变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。
技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。
产品规格：就是制造商和产品版本号的说明。
测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。
项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。
测试需求说明：
这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：
功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。
设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。
整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。
测试的策略和记录：
这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下：
公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。
测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。
特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。
经验判断：对以往的测试中，经常出现的问题加以考虑。
设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。
测试资源配置：
项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。
计划表：
测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。
问题跟踪报告：
在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。
问题描述尽可能是定量的，分门别类的列举，问题有几种：
1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。
2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。
3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。
测试计划的评审：
又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。
结果：
计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。 好贴，顶上去大家看！呵呵
页:
[1]
