测试开发入门
作者：互联网
推荐书籍：google软件测试之道，测试工程师全栈技术进阶与实践
测试开发的意义：尽早发现问题，降低解决问题的成本
软件开发模型：瀑布模型，V模型，W模型，敏捷模型
软件测试开发流程：
- 需求分析：分析功能点，核心竞争力，Kano模型，马斯洛需求分析，上下文分析法
- 制定测试用例：
- 使用思维导图，先收后放。提炼重点，删除冗余。
- 边界值法，等价类划分法，错误推测法，因果图法
- 根据测试大纲制定测试用例，需包含模块名，测试优先级，操作步骤，期望结果，测试结果
- 评审测试用例
- 执行测试
- 发现问题，保留现场
- 提交BUG，并推动BUG解决
- 提交BUG，详细记录测试步骤，划分BUG等级
- 推动开发解决问题
- 回归验证
- 验证已修复的BUG
- 对BUG所在模块进行基本功能测试；整体进行冒烟测试，确保其他功能不会受影响
- 编写并提交测试方法
- 使用金字塔原理设计测试报告，先总后分
- 汇总BUG，指定BUG发现及解决曲线图
软件测试方法
- 白盒测试
- 优点：增大代码的覆盖率，提高代码质量，发现代码中隐藏的问题
- 缺点：系统庞大时，开销大，难以测试所有路径；测试基于代码，无法验证代码合理性，可能会遗漏功能需求
- 黑盒测试
- 优点：较为简单，与软件内部实现无关；从用户角度出发，实际考虑用户使用的功能及可能的问题
- 等价类
- 等价类划分：有效等价类和无效等价类
- 边界值分析法：作为对等价类划分的补充
- 错误猜测法：基于经验
- 因果图法：输入条件之间的相互组合
- 场景分析法：根据用户场景模拟用户操作
- 大纲法：将需求转化为大纲
- 随机测试法：完全站在用户的角度测试
- 灰盒测试：白盒与黑盒之间
- 动态测试：实际运行程序，输入用测，验证程序的正确性，有效性和可靠性，并分析系统运行的效率和健壮性
- α测试：一个用户在开发环境下的受控测试，模拟实际操作环境
- β测试：多个用户在实际使用环境下进行的测试
- 冒烟测试：大规模测试前，先对基本，核心，主要功能进行测试
- 回归测试：代码修正后的测试
- 随机测试：纯随机
- 探索测试：有思想的测试一些复杂，不常用的功能
引入自动化测试的原因：
- 降低成本
- 节省时间
- CI和DevOps：持续集成，fail fast, fail early
- 准确，可靠
- 性能测试：可是同时模式数百万用户，手动测试做不到
- 增加对软件的信心，确保所有事情按预期工作
- 衡量质量标准：代码覆盖率，技术债，代码语义检查
总而言之，如果追求产品质量，自动化测试是必不可少的
自动测试框架：
- 基础模块
- 可重用组件：日志模块，时间模块
- 配置文件：测试环境的配置和应用程序的配置
- 管理模块
- 测试数据管理：实时创建，事先创建
- 测试文件管理：Page类文件，测试类文件，对象库文件
- 统计模块
- 测试报告：测试用例条数统计，测试用例成功失败百分比，总执行时间。对每一条测试用例，要有测试用例ID、运行结果、运行时间、所属模块、测试失败时刻系统截图、测试的日志
- 日志模块：出错时进行排查和定位
- 运行模块
- 测试用例调度，驱动机制
- 错误恢复机制
- 持续集成支持：测试框架应与CI系统低成本集成
常用的测试框架类型
- 模块化测试框架：基于OOP思想和PO模式
- 一个业务或一个页面，是一个Page对象，有一个Page类，类中存放着所有Page所属的页面对象和元素操作
- 页面对象和元素操作组成测试类方法，供测试用例层调用
- 优点：方便维护，测试用例可以由不同的模块和不同的对象组成
- 缺点：需要深入了解系统及模块划分
- 数据驱动框架
- 主要解决测试数据问题，python中DDT最为有名
- 关键字驱动框架：
- 把代码封装为关键字，通过组合关键字生成测试用例
- 混合模型
- 根据需求灵活选择
测试框架设计原则：
- 清晰明了，学习成本低；代码规范，模块清晰明确
- 通用性强，可维护，可拓展
- 高效处理错误，系统日志清晰
- 运行效率高，支持测试环境切换，支持外部数据驱动，支持顺序并发，远程运行
- 支持版本控制——回溯复盘和持续集成
设计测试案例
「好的」测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
一个“好的”测试用例，必须具备以下三个特征 。
-
整体完备性 ：「好的」测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
-
等价类划分的准确性 ： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
-
等价类集合的完备性 ： 需要保证所有可能的边界值和边界条件都已经正确识别。
三种最常用的测试用例设计方法： 等价类划分法、边界值分析法、错误推测方法。
第一，等价类划分法
只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。一个具体的例子：学生信息系统中有一个考试成绩的输入项，成绩的取值范围是 0~100 之间的整数，考试成绩及格的分数线是 60。为了测试这个输入项，显然不可能用 0~100 的每一个数去测试。通过需求描述可以知道，输入 0~59 之间的任意整数，以及输入 60~100 之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。那么这就可以在 0~59 和 60~100 之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的“有效等价类”。
你不要觉得进行到这里，已经完成了等价类划分的工作，因为等价类划分方法的另一个关键点是要找出所有「无效等价类」 。显然，如果输入的成绩是负数，或者是大于100的数等都构成了“无效等价类”。
在考虑了无效等价类后，最终设计的测试用例为：
有效等价类1：0~59之间的任意整数；
有效等价类2：59~100之间的任意整数；
无效等价类1：小于0的负数；
无效等价类2：大于100的整数；
无效等价类3：0~100之间的任何浮点数；
无效等价类4：其他任意非数字字符。
第二，边界值分析方法
边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。
第三，错误推测方法
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。** 这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也显而易见，那就是难以系统化，并且过度依赖个人能力。
总结：深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
标签：入门,测试,边界值,模块,等价,测试用例,开发,100 来源： https://www.cnblogs.com/yuan-sen/p/15435601.html