软件测试方法

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

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

软件研发流程和质量 最常见软件开发模型：瀑布模型（v、w模型） 　　　　　　　　　　快速原型模型 　　　　　　　　　　敏捷开发模型 V模型 　　 需求分析、概要设计、详细设计、编码、单元测试（独立的模块测试）、集成测试（模块联调）、系统测试（整体流程）、验收测试（验证是否满足需求） 。 v模型的优点： v模型清楚地标识出了软件开发的各个阶段； 清楚地描述了测试阶段与开发过程各阶段的对应关系与开发同步（引入检测机制，需求分析做的好不好，看验收测试）；它采用自顶向下逐步求精的方式把整个开发过程分为不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程：阶段划分清晰，方便工作的整体把控。 v模型的测试既包括了底层测试（检验源代码质量的测试：单元测试），又包括了高层测试（需求级的测试：系统测试）。 v模型的缺点： 它仅仅把测试过程作为需求分析，概要设计，详细设计，编码之后的一个阶段，容易让人理解为测试是软件开发的最后一个阶段； 和瀑布模型一样，流程也是单向的。到了测试阶段，程序已完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。 没有明确说明早期的测试，不符合越早测试和不断地进行测试的原则（用户需求对不对要到验收测试才能发现）。 W模型-双V模型 开发一个v，测试一个v，开发和测试并行。 开发V：需求分析、概要设计、详细设计、编码、集成、实施、交付。

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