软件测试计划

<font face="微软雅黑"， size=6> 首先 软件测试之灵魂拷问三连： 1.软件测试是什么鬼？ 2.软件测试如何分类？ 3.软件测试有没有Rule要遵循？ 卧槽，软件测试这么复杂，还有这么多道道，不就是"点点点"么？ 说这话的同学，请你尊重一下软件工程这个专业，好么？软件测试好歹也是软件工程的主干课程哦。 同时，说这话的同学也暴露了自己只做了纯执行的那部分工作。 好了，接下来我们要严肃的回答四连同志们的深刻提问。 1. 软件测试是什么鬼？ 按照 Standard for Software Test Documentation(IEEE Std 829-1998) 中软件测试的定义 软件测试：分析某个软件项以发现现存和要求的条件之差别并评价此软件项的特性。 软件的测试是为了确保软件的质量以及软件开发方向的正确性。 2. 软件测试如何分类？ 黑盒测试，白盒测试，灰盒测试，单元测试，集成测试，系统测试，确认测试，验收测试，冒烟测试...傻傻分不清楚。 当各位看官看完这篇解说文档，再有童鞋将黑盒测试，单元测试，白盒测试，系统测试，冒烟测试，验收测试这些概念混为一谈时，你基本可以判定，说这话的童鞋不是一名合格的测试攻城狮。 软件测试从不同的角度有不同的分类： 从软件测试技术来划分，软件测试可以分为： 黑盒测试，白盒测试，灰盒测试 从软件开发阶段来划分，软件测试可以分为：

众所周知，软件测试是把控软件质量的重要防线，但软件测试过程中也会存在潜在的风险。 软件测试的风险是指软件测试过程出现的或潜在的问题。 造成的原因主要是： 测试计划不充分 测试方法有误 测试过程偏离，造成测试的补充以及结果不准确 测试的不成功导致产品交付潜藏着问题，一旦在运行时爆发就会带来巨大的商业风险。 软件测试风险管理主要是对 测试计划执行的风险分析与制定要采取的应急措施，防止软件测试产生的风险造成危害 。 测试计划的风险一般指测试进度滞后或出现非计划事件，就是针对计划好的测试工作造成消极影响的所有因素。 对于计划风险分析的工作是制定计划风险发生时应采取的应急措施。 在软件测试过程中常见的计划风险主要有7类： 1、测试时间进度风险 用户需求发生重大变更或设计计划的大幅调整压缩了测试时间，测试人员，测试环境，测试资源的不能准时到位也会对测试计划造成影响 2、测试质量目标风险 测试的质量目标不清晰，如易用性测试，用户文档的测试目标存在见仁见智的问题 3、测试范围认知风险 对产品质量需求或产品特性理解不准确，造成测试范围分析误差，出现测试盲区或验证标准错误 4、测试人员风险 测试开始后，测试人员，技术支持人员因故不能及时到位 5、测试充分性风险 部分测试用例设计时忽视了边界条件和深层次的逻辑关系，部分测试用例被测试人员有意无意的忽略执行 6、测试环境风险 测试环境无法与生产环境一致

软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码（coding）->测试（testing）->运行与维护（running maintrnacne） 1 ，问：你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。 答： 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 ，问：给你一个网站，你如何测试？ 答： 首先，查找需求说明、网站设计 m 等相关文档，分析测试需求，制定测试计划，确定测试范围和测试策略，一般包括以下几个部分： 功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面：

1.开发模式 瀑布模型 过程：需求分析-设计-编码-实现-软件测试-完成-维护 优点：各个阶段比较清晰，适用于需求比较稳定的产品，强调早期计划和调查 改良：过程中加入少量的迭代过程（重复工作[例如再一次和产品经理等人确认需求]） 快速原型模型 过程 快速分析-需求说明-构造原型-原型-运行原型-评价原型-修改意见 适合于不确定需求的系统 螺旋模型（瀑布模型重复进行）不建议使用 2.测试模型 V模型 过程：需求分析-概要设计-详细设计-编码-单元测试（单一模块）-集成测试（所有模块）-系统测试（功能，性能，兼容） -验收测试（α测试（测试人员测 许多bug） β测试（用户测试）γ gamma测试） 优点：底层测试：单元测试 高层测试：系统测试 阶段清晰，便于把控 缺点：错误不能及时发现 线性关系，返工量大，灵活性低 改良：步骤添加少量的迭代 W模型 优点：开发和测试同时进行，趁早找出缺陷 分阶段工作，便于项目管理 缺点：线性模型，返工量大，灵活性低 没有文档，w基本不适用 实现难，对技术人员要求高 H模型基本不用 3.测试分类 随机测试：以前发现重大bug，新功能，重要功能，特殊情况进行二次测试，结合回归测试。 来源： https://www.cnblogs.com/1617-fung/p/11343218.html

1、单元测试概念 1）单元测试是对软件基本组成单元进行的测试，如函数（fuction或procedure）或一个类的方法（method）。这里，基本单元不一定是指一个具体的函数（fuction或procedure）或一个类的方法（method），在具体实现时，也可能对应的是多个程序文件中的一组函数。 2）在软件系统中，单元也具有一些基本属性，如：明确的功能、规格定义、明确的与其他部分的接口定义等，可清晰的与同一程序的其他单元划分开来。 2、单元测试的目的 1)单元测试的目的在于发现各模板内部可能存在的各种错误，主要是基于白盒测试。 2)软件产品不仅仅包含代码，还包含各种文档，因此测试应从三方面考虑: a.针对文档的测试; b.针对代码的测试; c.针对文档和代码是否一致的测试。 3）单元测试阶段，对应的文档时详细设计说明书，对应的代码是单元代码，因此单元测试的目的主要有三方面： a.验证单元代码和详细设计文档的一致性; b.跟踪详细设计文档中设计的实现，发现详细设计文档中存在的错误; c.发现在编码过程中引入的错误(编码过程中引入的错误包含两类:和设计不符引入的错误;和设计相符但由于编码出现疏漏导致错误),这里其实是针对文档和代码是否一致的测试。 3、单元测试中常见错误（单元测试关注重点） 单元的常见错误一般出现在5个方面：代码的稳定、易读、规范、易维护、专业。 因此

软件测试-测试分类 一、按软件测试阶段： a. 单元测试 b. 集成测试 c. 系统测试 d. 验收测试 1、单元测试 单元测试的原则： 1、尽可能保证部没测测试用例相互独立 2、一般由代码的编写人员来实施 单元测试的优点： 1、能尽早发现缺陷 2、有利于重构 3、可以简化集成 单元测试的缺陷 1、不可能穷尽测试，即测试用例不可能覆盖所有的执行路径，不可能捕捉到所有的错误 2、每一行代码需要3-5行测试代码来完成测试 单元测试框架 xUnit，比如：JUnit 例：eclipse->new->Java project->(finish)->右键项目->properties->Java Build Path->Add library->选择JUnit->next->选择Junit版本->finish 选中需要测试的类，在上右键->new->junit test case(勾选setUp()和tearDown() )->next( 选择需要测试类中待测试的方法 ) -> finish() 2、集成测试 在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块，子系统或者系统的过程中各部分工作是否达到或者实现相应3技术指标及要求的活动。 集成测试实施方案 1、BIg Bang（一次性集成/大爆炸）：把大部分开发模块耦合起来，形成一个完整的软件系统

1、常见的 测试 用例设计 方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计 工作 中的应用。 　　1）等价类划分 　　常见的 软件测试 面试 题划分等价类: 等价类是指某个输入域的子集合.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类 其它 值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 　　2）边界值分析法 　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误. 　　使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据. 　　3）错误推测法 　　基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法. 　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 例如， 在 单元测试

1、对软件测试的认识 其实软件测试的定义是：发现之前未发现的错误 在运营答疑、大领导那，他们可能会认为： “软件测试 是证明软件不存在错误” “软件测试 目的在于证明软件能够正确完成其预定的功能” 这类情况，需要向他们澄清。 提高程序的可靠性，是指找出并最终修改了程序的bug. 测试阶段的工作流程 在这里可以看到，编写测试计划前，确定测试策略，那测试策略要描述哪些内容：欢迎展开讨论。 然后，在编写测试计划时，需要结合开发计划，确定各个时间点具体可以测试的内容、以及模块交叉测试、兼容测试的统筹安排 计划评审及用例评审 转测 1.3.4 其他流程，按项目实际情况设计 ======================================================= 设计测试用例 ======================================================= ========================================================================== 如何进行接口测试： ========================================================================== 接口测试，用例设计方向： 正常功能验证 参数组合验证 ，比如必填项验证

1.软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码 （coding）->测试（testing）->运行与维护（running maintrnacne） 2、问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准：根据需求说明书、产品说明、原型图、设计文档等，确认实际结果 是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据， 1）可以根据同行或类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 2）根据用户的一般使用习惯，来确认是否是缺陷； 3）与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 3、给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性 能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转