2022最新软件测试自学教程 新手小白30天软件测试入门最强教程
- 基础环境搭建
- 1.LNMP:linuc(操作系统)，nginx,mysql,php
- 2.WAMP:windows,apache,mysql,php
测试的目的：以最小的人力 、物力和时间找出软件中潜在的错误和缺陷
软件测试原则：
- 证明软件中存在缺陷；
- 不能穷尽测试；
- 测试应该尽早介入；
- 28原则；（80%的用户只用到20%的功能，80%的错误都出现在20%的地方）
- 不存在缺陷谬论；
- 妥善保存一切文档；
测试的基本要求：
- 外观界面测试；
- 易用性测试；
- 兼容性测试；
- 安全性测试；
- 性能测试；
- 功能测试；
测试与开发模型：
- 需求分析（阅读需求文档，产品文档，产品详细设计书，分析需求的点， 参与需求评审）
- 制定测试计划和测试方案
- 测试计划：测试整个项目的总体的规划（测试范围，进度的安排，人力物力的安排，整体测试策略，风险评估，风险的规避）
- 测试方案：（被测试的目标，选取什么样的测试工具，测试的方法，测试的重点）
3.设计测试用例：
4.执行测试用例：
5.评估阶段；（测试报告）
开发模型
- 瀑布模型（ 瀑布模型是文档驱动的模型，遵守这个约束可使软件维护变得比较容易一些，从而显著降低软件预算）
- 增量模型（把瀑布弄下的顺序特征与快速原型法的迭代特征相结合，将软件看作一系列的增量，在开发过程的各次迭代中，每次完成其中一个增量 ）
- 快速模型（快速建立起来的可以在计算机上运行的程序）
- 螺旋开发模型、迭代开发模型、敏捷开发模型；
测试模型
- V模型（描述了基本的开发过程和测试模型）
- W模型（测试伴随整个软件开发周期，而且测试的对象不仅仅是程序、需求、功能和设计同样要测试，测试与开发是同步进行的，从而有利于尽早的发现问题）
测试与开发的关系
- 目标相同
- 相辅相成
- 侧重点不同：开发侧终于从无到有，从有到优，
软件测试分类
- 测试（开发）阶段：
- 单元测试（编码完成前或后；模块 类 函数 方法；开发人员，白盒测试人员）
- 集成测试（模块已经完成编码；模块与模块之间的内容；开发人员和白盒测试人员）
- 系统测试（程序 软件 APP 系统 网站 项目；集体测试；开发白盒黑盒）
- 验收（交付）测试（α测试 β测试；媒体用户）
2.是否覆盖源码：
- 黑盒测试：不覆盖源码，功能测试（UI、业务功能、文档、易用性、安装卸载、兼容性）、性能测试（一般性测试、稳定性、负载测试、压力测试）
- 白盒测试：覆盖源码，透明的可以看到源码 ；（语句覆盖、判断覆盖、条件覆盖、路径覆盖）
- 灰盒测试：关系输入输出、考虑程序运行的状态
3.是否运行：
- 静态测试：测试程序的结构、接口是否正常、程序过程、代码的风格是否符合标准；
- 动态测试：
4.是否自动化：
- 手工测试：
- 自动化测试：
5.地域测试：
- 本地化测试
- 国际化测试
6.其他测试分类：
- 回归测试
- 冒烟测试
- 随机测试（monkey）
- 探索测试
测试用例：
定义：测试用例又叫test csse ,是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，一遍测试某个程序路劲或核实是否满足某个特定需求。
特性：
- 有效性：测试用例的能够被使用，且被不同的人员使用测试结果一致。
- 可复用性：良好的测试用例具有重复使用的功能，如：回归测试；
- 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用；
- 可评估性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准；
- 可管理性：从测试管理的角度，测试用例的通过率和软件缺陷的数目是软件产品质量好坏的测试标准；
测试用例的要素：
- 测试编号：编号由字符和数字组合成的字符串，用例编号具有唯一性、容易识别
- 测试项目/模块：属于哪个项目或者被测试的需求、被测试的模块、 被测试的单元等
- 预置（前提）条件：执行测试用例需要的前提条件，如果前提条件不满足，则后面的测试步骤不能进行或者得不到预期结果；
- 测试输入：测试用例执行过程中需要加工的外部信息，根据测试用例的具体条件有手工输入、数据库等；
- 预期输出：测试用例的预期输出结果，包括返回值内容、界面响应结果等；
- 操作步骤：执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例
- 测试用例标题：简单描述，描述测试用例的测试点，每个测试用例的标题不能重复，因为侧重点不一样；
- 级别：重要程度的区分
- 其他要素：设计者、日期、开发人员、结果、类型；
测试用例的设计原则：明确性、代表性、间接性
测试用例设计方法总结：
测试用例的本质（基于需求）
- 理解需求，反应需求
- 需求会变化，则测试用例也应该会变化
- 及时响应变更比遵循计划更有价值
原则
- 根据程序的重要性和一旦发生故障带来的损失，来确定测试等级和测试重点
- 认真选择测试策略。用尽可能少的测试用例发现尽可能多的错误。测试用例不足会导致风险的增大；测试过度导致资源的浪费。需要找到平衡点
方法选取
- 先关注主要功能业务流程、业务逻辑是否正确现实、考虑场景
- 需要输入数据的地方，考虑等价类划分法
- 在任何情况下都使用边界法
- 如果程序的功能中包含输入条件的组合情况，则选取因果图和判定表法
- 对于配置类软件，需要考虑参数的组合情况，考虑使用正交排列法
- 对照程序逻辑，如果发现没有达到要求的覆盖标准，适当补充更多的测试用例
- 采用错误推断法，追加其他测试用例
测试用例的审评
- 同行审评：“个体和叫交互比过程和工具更有价值”由测试小组内部进行相互评审，达到思想的碰撞，通过探讨、协作完成测试用例的设计
- 用户评审：顾客的协作比合同谈判更有价值/·如果测试是对产品的批判，则顾客指最终用户或者顾客代表/在公司内部可以是市场调查人员或者相关领域专家/ ·如果测试是为软件开发提供帮助和支持，那么顾客就是程序员。
缺陷的基本概念
- 定义：缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户的需求
- 具体包含（程序、数据、文档）：
- 1.未达到需求规格说明书中的功能
- 2.出现了需求规则说明书中指名不会出现的错误
- 3.功能超出了需求规格说明书的范围
- 4.未达到需求说明书中虽然没有指明，但应该达到的目标
- 5.测试人员或者用户认为软件难以理解、不易使用、运行速度慢或者最终用户认为不好
表现形式
- 功能、特性没有实现或者部分实现
- 设计不合理、功能特性不明确，逻辑不清楚或者存在矛盾
- 产品实际结果和所期望的结果不一致
- 没有达到需求规格说明书所规定的性能指标
- 运行出错、中断、崩溃、界面混乱
- 数据不正确、精度不够、不完整、格式不统一
- 用户不能接受的其他问题，超时、界面丑陋
- 硬件或者系统软件上存在的其他问题
缺陷产生的原因：
- 需求解释或者记录错误
- 用户需求说明存在错误
- 编码说明、程序代码有误
- 硬件或者系统存在错误
- 文档、内存不正确、拼写错误
缺陷产生的根源
- 交流不充分
- 软件的复杂性
- 开发任务的错误
- 需求的变化
- 进度压力
缺陷的修复费用：越到后期缺陷修复的费用越高
