软件测试方法

文章目录 一个测试活动完整的过程 测试计划工作的目的、测试计划文档的内容包括什么？ 测试用例通常包括那些内容？ 测试人员在软件开发过程中的任务是什么？ 软件测试分为几个阶段，各阶段的测试策略和要求是什么？ 单元测试 请回答集成测试和系统测试的区别，以及它们的应用场景主要是什么？ 你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎么解决？ 请问你觉得测试项目具体工作是什么？ 软件测试方法 黑盒测试 边界值分析法 因果图法 判定表法 白盒测试 语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 性能测试 性能测试类型 负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，知道系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等 压力测试:压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。 恢复测试 强度测试 疲劳强度测试 每一阶段测试基于的文档 一个测试活动完整的过程 项目立项前测试人员不需要提供任何工件 项目经理 通过和客户交流，完成 需求文档 ，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。 项目经理通过综合开发人员、测试人员以及客户的意见，完成 项目计划 。然后SQA进入项目

1.你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 　　1. 将问题提交到缺陷管理库里面进行备案 2. 要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 　　3. 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 　　4. 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 　　等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2. 给你一个网站，你如何测试？ 　　首先查找需求说明，网站设计等相关文档，分析测试需求 　　制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；性能测试；数据库测试；安全性测试；兼容性测试 　　测试用例设计： 功能性测试 ： 连接测试，连接是否能够正常跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回 提交功能的测试 多媒体功能能否正常加载和显示 多语言支持是否能够正常的显示选择的语言等 界面测试 ： 1. 页面是否风格统一，美观 2. 页面内容是否合理，重点内容和热点内容是否突出 3.

测试的定义 ：通过人工或自动的手段，对被测对象进行检测的活动，目的在于发现被测对象是否实现用户的需求，或者弄清楚实际结果与预期结果之间的差异。 测试的目的 ：1.发现被测对象与用户需求间的差异—俗称找bug。 　　　　　　2.通过测试活动发现并解决缺陷，增加人们对被测对象的质量信心。 　　　　　　3.通过测试活动，获取被测对象的质量信息，为决策提供数据依据。 　　　　　　4.通过测试活动，预防缺陷，从而降低项目或产品的风险。 测试原则 ：1.测试证明软件存在缺陷 　　　　　2.不可能执行穷尽测试 　　　　　3.测试应该尽早启动，尽早介入 　　　　　4.缺陷存在群集现象 　　　　　5.杀虫剂悖论 　　　　　6.不同的测试活动依赖不同的测试背景 　　　　　7.不存在缺陷的谬论 测试级别 ： 单元测试 ：针对被测系统最小的组成单元实施的测试活动，一般是类或函数，也可能是最小的功能单元。 　　　 集成测试 ：针对组件/单元与组件/单元之间的接口实施的测试活动，验证接口设计是否与设计相符。分成3种集成：1.函数间集成。2.模块间集成。3.子系统间集成。 　　　 系统测试 （国内公司接触得最最最多的）：将通过集成测试的软件，部署在真实的用户环境下执行测试。 　　　 验收测试 ：以用户为主的测试，验收组应该由项目组成员、用户代表组成。面试可能会问到： 　　　　　　 α测试

1.你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 　　1. 将问题提交到缺陷管理库里面进行备案 2. 要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 　　3. 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 　　4. 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 　　等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2. 给你一个网站，你如何测试？ 　　首先查找需求说明，网站设计等相关文档，分析测试需求 　　制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；性能测试；数据库测试；安全性测试；兼容性测试 　　测试用例设计： 功能性测试 ： 连接测试，连接是否能够正常跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回 提交功能的测试 多媒体功能能否正常加载和显示 多语言支持是否能够正常的显示选择的语言等 界面测试 ： 1. 页面是否风格统一，美观 2. 页面内容是否合理，重点内容和热点内容是否突出 3.

软件测试的原则： 1、所有的测试都应追溯到用户需求（视频网站，点击后最大化） 2、应当把“尽早和不断地测试”作为座右铭 3、测试工作应该由专业的软件测试机构来完成 4、Pareto原则，测试发现的错误中80%很可能起源于20%的模块中 5、设计测试用例时，应该考虑各种情况 6、对测试出的错误结果一定要有一个确认的过程（描述缺陷报告） 7、制定严格的测试计划 8、完全测试是不可能的，测试需要终止 9、注意回归测试的关联性。 10、妥善保存一切测试过程文档。 提示：回归测试指修改了旧代码后，重新进行测试以确定修改没有引入新的错误或导致其他代码产生错误。 软件产品质量模型（ISO/IEC9126） 软件产品质量模型对产品设计时需要考虑的地方进行了高度概括。 六大特性： 1、功能性：是指软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。 2、可靠性：是指在特定条件下使用时，软件产品维持规定的性能级别能力。第一层：设备最好不要出故障；第二层：设备出现故障了不要影响主要的功能和业务；第三层：如果影响了主要功能和业务，系统可以尽快定位并恢复。 3、易用性：是指用户在指定条件下使用产品时，产品被用户理解、学习、使用和吸引用户的能力。简单10个字：易懂、易学、易用、漂亮好看（用户体验好）。 4、效率：是指在规定条件下，相对于所有资源的数量，软件产品可提供适当的性能的能力。通常

　　所谓的测试效率就是测试产出和测试时间之比，假设测试产出是一个定值，那要提高测试效率，就是要缩短测试时间 　　那要怎么オ能减少测试时间呢？ 　　(1)不要做无效的测试 　　一般项目前期bug都是较多的，而且极为不稳定的，如果有多个较严重的bug，可以拒绝继续测试。一方面继续测试也没有意义，因为阻塞测试的地方会有很多，也无法测试全面：另方面即便继续测试出很多bug，也可能是由于那些bug引起的，倒不如等这些修复之后再继续测试。这样对于前期来说可以节约不少测试时间，把做无效测试的时间留出来想想如何优化测试顺序。 　　要做到这点的前提是要对整个项目的架构、相互之间的联系等要十分了解，这样可以避免很多看似不同的测试点，但实际只是一个测试点，仅是外面包装的不同而已。于是当这一个测试点有bug，那些其他看似不同的测试点其实也不用测试了，肯定也是有问题的，那提bug的时候可以列出核心问题所在，并将其他涉及的点列出来，等验证的时候再把那些点都再验证一遍。这样等于少做了很多测试，只是在验证的同时把测试再覆盖全 　　对于测试来说肯定需要测试很多轮，每一个测试版本作为一个测试轮 第一轮:只测试大致功能，不需要细测，列出主要bug。 第二轮:验证第一轮bug，然后全面细测，列出所有能发现的bug 第三轮到第x轮:验证上一轮的bug。 最后一轮:验证全部bug，并全面细测。 　

质量很重要，毋庸置疑的。但是进入新时代-- service -based software 的大量普及，软件测试所处的环境发生变化，是值得软件测试人员思考， 认真思考一下。 “测试之死” 并不仅仅是一个噱头。 首先看看软件测试所在的环境变化： 1. "fix defect " 的成本变越来越低成本。 　　传统的软件发布是基于一个软件包（package），有时很大，需要四五张光盘才能安装。软件发布出去后，如果有严重问题，需要修复，那是个很头疼的事。想想丰田汽车如何被召回的。现在软件运行在浏览器，有问题只需要改一下服务器，甚至不需要重启就直接修复了。 比较一下二者的成本，就这到为什么传统的软件测试人员千方百计的在软件发布前找到尽可能多的缺陷。而现在，主要矛盾已经由软件质量本身的担忧转移为对软件发布的速度上面。 2. 软件持续发布。 持续发布，跟传统软件一年一发布策略有着天然的优势：反馈快速快，应对需求变化快，更好让用户参与，提高交付满意度等等。 比如现在用的chrome，3年多发布17个版本。然而这些对软件测试提出了新的挑战，测试要快，至少不能拖慢开发节奏。如果测试影响软件发布的时间，这是不可接受的。传统软件测试，耗时耗力。尽管自动化测试的呼声，以及对应的想法，工具，数不胜数，但是面对如此短的发布周期，软件测试人员已经有点吃力。 3. 软件的测试理论没有什么重大突破 。 　

今天，我们面临着越来越多的测试新软件的方法以及越来越多的工具来完成这些测试。但谁真的有时间跟踪那里的数百种（和数量）工具？ 在您想要找到满足您需求的最佳软件测试工具的Google深度索引中迷失之前，这边将会介绍几种类型的工具，以供您参考 本次的工具介绍将从以下几个方面进行概述： 测试工具摘要 UI屏幕截图 主要特点 你需要知道什么 客户评论的链接（如适用） 定价（如果有） 将此类工具细分为8个类型如下： --01-- 测试自动化 测试自动化是最成熟的软件测试领域之一。目前，良好的开源选项的兴起以及对DevOps和多渠道模型的推动正在改变这一细分市场。 我们可以将测试自动化工具分解为两个子类别： 功能测试 集成/ API测试 >>功能软件测试工具<< 为何使用功能测试工具？功能测试工具通过与应用程序的UI层交互来推动自动化测试。这些工具通常提供记录和回放界面，使非技术测试人员更容易提供自动化覆盖。但是，这些测试可能会很慢而且很脆弱。 1 这些工具通常提供记录和回放界面，使非技术测试人员更容易提供自动化覆 盖。 1. Tricentis Tosca Testsuite 摘要：提供基于模型的测试自动化，侧重于测试用例设计与问题解决。Tosca Testsuite还提供端到端测试和记录功能。 特征： 提供对敏捷的支持 包括围绕测试数据管理和业务流程的更完整的工具集 提供基于模型的自动化支持

解决错误 开发人员 发现错误 测试人员 软件不可能没有任何bug 测试人员是极其重要的 单元测试的定义： 单元测试：（模块测试 unit testing） 是针对程序模块（软件设计的最小单元）来进行正确检验的测试工作 单元测试的目标： 信息的正确流入和流出单元 工作中，内部数据的完整性 验证设置的边界值是否正确工作 单元是否达到一个覆盖率 总而言之，验证代码的功能、逻辑是否正确 单元测试的必要性： 尽早介入越好 编写单元测试 ： 学会使用断言（assertion） 最大化测试覆盖率 避免重复的测试代码 不要依赖测试方法的执行顺序 来源： CSDN 作者： 爱跳的小海豚 链接： https://blog.csdn.net/u013761415/article/details/51519287

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