软件测试方法

功能测试 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能 性能测试 验证系统在不同的业务场景下的响应时间和资源利用率等性能指标是否符合预期定义的标准 这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。 性能测试类型 基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考 负载测试：是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等 。 压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。 稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。 并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题 安全性测试 用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入 异常测试 兼容性测试 来源： https://www.cnblogs.com/hwlc--/p/11769474.html

一 软件测试分类 软件测试的分类五花八门，最关键的是：在系统或非系统学习了软件质量与测试之后，要明白在什么阶段、什么情况下主要使用什么方法做软件测试。 　　1.以是否执行程序：静态测试、动态测试。 　　　　静态测试：桌面检查、走查、审查、软件评审。 　　　　动态测试： 　　　　　　黑盒测试： 等价类划分法、边界值分析法、因果图法 、判定表法、 场景法 、错误推测法等。 　　　　　　白盒测试：语句覆盖法、 判定覆盖法 、条件覆盖法、判定/条件覆盖法、条件组合覆盖法、 路径覆盖法 、 基本路径覆盖法 、 程序插桩测试法 、程序变异测试法、循环语句测试法、代码检查法（含： 代码评审[静态测试方法] 、 基于缺陷模式测试 等）等。 　　2.以是否重点关注程序内部程序或外部输出结果分：黑盒测试与白盒测试。 　　3.以时间阶段划分： 单元测试 / 集成测试 / 系统测试 / 验收测试 原文：https://www.cnblogs.com/johnnyzen/p/9247713.html

软件测试基础知识 一、 软件测试发展历程 二、 软件测试目的 （1）测试并不仅仅是为了找出错误，而且要通过分析错误产生的原因和错误的发生趋势，帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进。 （2）测试分析帮助测试人员设计出有针对性的测试方法，以改善测试的效率和有效性。 （3） 三、 软件测试原则 （1）“尽早和不断地进行软件测试”作为软件开发者的座右铭，实践证明单元测试 junit jtest （2）测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。 （3）应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试） （4） （5） （6）严格执行测试计划，排除测试的随意性。 （7）应当对每一个测试结果做全面的检查。 （8）妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。 四、软件测试分类 分为：单元测试、集成测试、确认测试、系统测试、验收测试等。 分为：开发方测试、用户测试、第三方测试。 “验收测试”或“ α ”。在软件开发环境中，开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。 β测试，指把软件有计划地，免费地分发到目标市场，让用户大量使用、评价和检查软件。 第三方测试是指由第三方测试机构来进行的测试，也称独立测试。 静态测试是指计算机不真正运行被测试的程序，而是人工对程序和文档进行分析与检查

1. 提测质量差 　　问题描述：第一个提测版本差，有些均未通过 冒烟测试 　　问题分析 　　A. 版本提测质量差，但基于发布时间已在，因此，在提测差时就开始测试 　　提测质量差的点：- 基于上每项功能的完成度都不高 - 有些功能均未实现 - 　　B. 新的团队，团队处于磨合期 　　C. 在提测时，对提测要求不明确，在时间点到后，匆忙提测 　　解决方式： 　　明确版本提测要求，并且开发得到了足够的时间。 2. 版本控制 　　问题描述： 　　最初阶段，每天出一个版本，基于新版本测试，记录每个版本上测试的功能。版本过于频繁，质量把控不好 　　问题分析： 　　A. 基于版本提测质量差，而且每天出一个版本，差上加差， 　　B. 虽然记录每个版本上测试的功能，但仍然无法把控当前版本的质量状况。 　　解决方式：暂停每天发布一个版本 　　前期：将全功能版本作为下一个版本发布目标，但由于一些功能并没有完成，因而，全功能版本分成了好几个阶段 　　后期：以测试一轮周期，发布最新版本 3. 功能反复 　　问题描述：在上一个版本是OK的功能，在新版本中功能失常 　　功能反复分两点：一是大功能反复， 二是小功能（如：某个bug）反复 　　问题分析： 　　大功能反复：情况主要发生成项目前期和中期 　　A. 功能未完成，在完善功能时，未考虑到与该功能相关的点 　　B. 在提测之后，发现一些问题，导致了整个模块重构

目标：快速构建软件测试体系（对象――>方法――>流程――>How――>持续改进） 做某件事情，思路如下： 以上过程，理解为： 针对x一个对象，围绕特定的目的，利用具备的方法，按一定的流程做事情，并反复思考总结，这样做是否达到目的。 软件测试基础，核心框架理解为： 测试目的：保障软件质量 or 提高软件质量 测试对象：软件（代码、数据、文档） 测试方法：黑or白，其它 测试流程：v、敏捷 经验分享 ： 实际工作中， 参考相关文档 （如：产品需求文档、UI界面原型、相关技术文档、竞品分析等）， 确定并分析测试对象 （如：文档、接口、功能模块、系统、用户场景等），依照不同的测试对象，选取合适的： 测试类型（策略）+ 测试方法 ， 完善 相关 分析过程 和 工作件文档 ，按照 执行流程 ，完成测试工作。 常见相关面试题： 什么是软件测试？ 软件测试是做什么的？ 软件测试的目的是什么？ 功能测试主要测什么？ 转载请标明出处: 随心测试_软测基础_003<构建测试体系 > 文章来源: 随心测试_软测基础_003<构建测试体系 >

1、测试用例包括： （1）测试输入（Test Input）：测试数据 （2）测试预言（Test Oracle）：预期输出 （3）其他设置：环境 2、Testing vs Debugging： （1）测试：为了执行程序并测试失效，即测试和预期不一样的地方。 （2）调试：找出bug所在位置并进行修正。 3、Verification vs Validation： （1）Validation：确认规格文档是否满足用户的需求，是用户最终想要的 （2）Verification：确认规格文档和最终的实现是否一致，测试就是这一类。 4、静态测试 vs 动态测试： （1）Static Testing：不需要运行程序 （2）Dynamic Testing：需要运行程序 5、黑盒测试 vs 白盒测试： （1）black-box Testing：不需要源代码 （2）white-box Testing：需要源代码 （3）gray-box Testing：通过其他软件制品或者反编译手段获得了部分软件结构信息进而进行测试。 【notice】白盒测试+黑盒测试≠灰盒测试 6、测试层次：（Testing Level） （1）Unit testing：测试函数、方法等，最基本最小的测试单元 （2）Module testing：模块级的输入输出测试 （3）Integration testing：多个模块级组合起来的测试

速读《构建之法（第三版）》总结 花了两天的时间，终于是把这本《构建之法》粗略的阅读完毕，我在阅读的过程对于感兴趣的部分进行了仔细阅读，其中也碰到了一些问题。但我认为领悟这本书所传达的思想及思维方式是非常重要的，在此提出自己阅读时所收获的一些问题，不对的地方还望大家及时指正。 问题一 在软件的开发过程中，即便我们有了一定的软件开发能力后，为什么我们还要必须具备软件工程的工程思维？ 从以下几个主要方面进行简单分析 软件开发的变化 追溯到计算机刚起步的时候，软件设计只是为了个特定的应用而在指定的计算机上设计和编制，当时的语言使用还是机器代码或汇编语言，软件的规模也比较小，很少使用系统化的开发方法，软件设计几乎就是在个人编程。随着现在计算机整个行业的发展，软件的增多，高级语言的出现等，软件的规模越来越大，复杂程度也越来越高，软件的可靠性问题突显出来。在这个软件开发越发成熟的今天，从软件的立项到最后软件的发出，中间的开发过程慢慢的形成了各式各样固定的体系，当软件开发还处于幼年时期时，产品大多遵循[分析→设计→实现（制造）→销售→维护]，弊端是具有单向、不可逆性。后来，Winston Royce提出了具有相邻回溯的“瀑布模型”以及改进后的最终版本，后续又出现了很多“瀑布模型”的变形版。 图1.1 相邻回溯 图1.2 最终版 软件开发的模型有很多种，不同的软件可能适合不同的开发模型。

七、测试评估方法和测试误区（第8章和第9章） 　　良好的测试是无法确认的。但是我们可以通过很多方法，知道或估算出不好的测试是什么样的。识别出有关测试的主要误区，可以更好的进行测试。　　 　　测试的评估方法　 　　1、永远无法确切地知道良好的测试 　　完美的测试具有如下特点：a)它会检测出一个系统中的所有缺陷；b)它永远不会将不是缺陷的情况判断为缺陷；3)它能让我们完全确信它完成了a和b；d)针对我们的需要，它可以足够迅速和廉价地实现a、b和c。你会发现完美的测试和很糟糕的测试具有惊人的相似性，一个很糟糕的测试也可能会满足a、b、c和d。 　　良好的测试是描述测试与某个实现之间的特定关系的属性。我们是无法知道测试是良好的，但是我们我们可以根据一些元信息知道测试是否糟糕。 　　2、根据事实来评估良好性 　　1）根据系统中缺陷的多少，来评估一组测试的良好性。 　　　　对这些缺陷进行追踪，分析他们的具体使用情况，可以得到一些信息。比如，测试有多好，以及好在哪些方面；将来可以如何对测试加以改进；测试会经常遗漏哪种缺陷。 　　2）根据长时间积累的缺陷，进行评估 　　3）其他评估方法 　　　　将测试覆盖范围和故障理论进行比较；随机改变测试来了解问题如何出现；对不同类型测试进行比较。 　　3、植入缺陷进行评估 　　　　插入已知的缺陷而不告诉测试人员

1、 软件测试阶段有哪些任务 ①、制定测试大纲（测试计划） ②、制作测试数据（测试方案） ③、单元测试（程序测试，一般由开发人员进行） ④、功能测试 ⑤、性能测试 ⑥、集成测试（子系统测试） ⑦、系统测试 ⑧、验收测试 ⑨、测试报告及向下阶段提交系统运行、维护用户手册 2 、 自动化测试 概念：为了提高工作效率，节省人力和成本，把人为驱动的测试转化为机器执行 3、自动化测试的过程 需求分析 测试计划 框架搭建（附带工具选择） 测试用例设计（编写测试用例或开发测试脚本，并文档化） 测试——调试测试（针对自动化测试脚本） 评估（评估测试结果并改进测试过程） 4、 自动化测试技术 录制/回放（依赖工具） 脚本技术 数据驱动（data driven)的自动化测试 关键字驱动（keyword driven）的自动化测试 业务驱动 5、自动化测试方案选择需要考虑的方面 ①、项目的影响（能否帮助项目进度、覆盖率、风险） ②、复杂度（是否容易实现，包括数据和其他环境等） ③、时间（实现自动化需要多少时间） ④、早期需求和代码的稳定性（需求或代码能否证明是在范围内变化的） ⑤、维护工作量（代码能否能长期保持相对稳定） ⑥、覆盖率（自动化测试能否覆盖程序的关键特性和功能） ⑦、资源（是否拥有足够的人力、硬件和数据资源来运行自动化测试） ⑧、执行（负责执行的人员是否有足够的技能和时间去运行） ⑨

　　今天有人问了我一个问题：“老师，做测试更好还是做开发更好？”。 　　其实这个问题其实没有唯一的答案，我自己做过开发，做过QA，做过测试，做过售前支持，甚至还临时做了一段时间的人力（因为我们公司的人力怀孕，我临时代她几个月）。现在我在做软件测试培训讲师和企业内训的事情，也在Atstudy网校上线了Python全栈测试开发等等很多课程。这一路走来，IT公司基本上相关的岗位我都有涉及到一些，做开发和做测试的时间最长，10年以上了。客观来讲，我自己最喜欢的工作是目前的这个老师的职位，因为可以和大家有许多的分享和交流。 　　01 　　IT公司里面有不少的岗位，需求量最大，提升空间最大的职位其实主要还是开发和测试这两类。很多人想进入IT行业，也是因为看重了它的快速发展。这两个职位并不是相互独立的，因为一名开发人员如果只知道低头写代码，而很少分析需求和业务是否存在问题，那么有可能无论代码技术有多强，也可能会由于需求本身就存在严重的问题，而导致自己辛辛苦苦写的代码被付之东流（因为需求本身是错误的，代码无论怎么写，都不会是正确的。），或者说自己只是钻研编码技术，而忽略了自身代码质量的问题的话，那么就会陷入不断修改bug，不断产生bug的泥潭，而很难有更多技术的提升，更谈不上发展了。最要命的是有一天，公司告知我们，这个编码技术不再使用了，我们要用更新的语言去替换