软件测试
测试用例要素
用例编号、测试项目、测试用例标题、前置条件、测试输入、预期结果、操作步骤、重要级别、测试结果、开发人员、开发时间
外观界面测试，易用性测试，兼容性测试
涉及原则：代表性（功能相似用例要合并）简洁性、测试结果唯一，陈述语句，不用修饰词
等价类划分
抽象合并法：确定有效等价类，无效等价类（测试程序的健壮性）。等价类是输入域的集合。涉及的时候要考虑到无效等价类。
例子：QQ登录。无效等价类（账号非数字，超出规定位数、数字）
无效等价类：数字、小数、负数、英文字符、特殊字符、空格、空（什么都不写)
边界值法
闭区间取外面的值，开区间取里面的值。是等价类划分法的补充，等价类划分法是任意一个数据作为代表，边界值分析法是每个边界值都要作为测试条件。
上点：输入范围的边界点
离点：离边界最近的点
内点：输入范围内的任意一点
因果图法
输入条件的相互制约和组合关系，输出条件对输入条件的依赖关系。前两种都没有考虑组合关系
如果输入条件组合是天文数字，需要用因果图法
恒等：原因出现，结果出现；原因不出现，结果不出现
取钱，打印凭条
非：原因不出现，结果出现；原因出现，结果不出现
搜索有结果，不提示错误，无结果提示错误
或：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现
与：若几个原因都出现，则结果出现，若几个原因都不出现，则结果不出现
正交法
判定表法
由因果图法生成
场景法
一般适用于冒烟测试，看整个流程能不能走通，猜测可能发生的场景，基本流表示最顺畅的，除了基本流场景外发生的都是备选流
流程分析法
针对场景法的测试子项进行流程分析；画出业务流程，覆盖所有可能路径
错误推断法
直觉推测出可能存在的各种错误
总结
根据程序的重要性和一旦发生故障带来的损失，确定测试等级和重点
用尽可能少的用例发现尽可能多的错误
先关注主要功能的业务流程是否实现，考虑场景法
需要输入数字的地方，考虑等价类划分法
任务情况都可以使用边界法
如果程序功能包括条件组合，选取因果图或者判定表法
对于配置类软件，需要考虑参数的组合情况，考虑正交法
采用错误推断法
开发模型
瀑布模型
缺点 缺乏灵活性：瀑布模型的线性结构导致其缺乏灵活性，一旦一个阶段完成，就很难进行更改，这可能会导致项目延迟和成本增加。同时，它也难以适应项目中需求的不断变化，由于早期阶段的冻结，对范围或要求的任何更改都可能对后续阶段产生重大影响。 早期缺陷检测困难：在瀑布模型中，缺陷通常在开发的后阶段才会检测到，这可能会导致代价高昂的返工和修复工作。 开发时间长：瀑布模型的线性结构导致较长的开发时间，每个阶段都必须完成，才能进入下一个阶段，这可能会减慢项目的进展。 客户反馈有限：客户在开发后期阶段才会看到成品，这可能会导致成品与期望不符，需要进行昂贵的修改。
优点 结构清晰：将软件开发流程划分为明确的阶段，如需求收集、设计、开发、测试和部署，每个阶段都有明确的任务和目标，以及明确的交付物和审查点 顺序明确：每个阶段必须按照固定的顺序依次进行，并且当前一阶段的工作完成并通过评审后，才能进入下一阶段，这使得开发过程可控，易于管理和跟踪进度。 文档完善：在瀑布模型中，每个阶段都会生成详细的文档，包括需求规格说明书、系统设计说明书等。 需求稳定性好：瀑布模型侧重于项目初期的需求分析和设计，在后续的开发阶段，需求变更的可能性相对较低， 便于阶段审计：瀑布模型提供了清晰的项目阶段和里程碑，这使得项目的审计变得相对简单。
快速模型：减少由于需求不明确带来的开发风险，适合预先不能确定需求的软件开发。缺点：精细度不足，需求变更困难，产品质量风险
增量模型
优点 灵活的人员分配：增量模型允许在项目开始时不用投入大量的人力资源，因此具有更高的灵活性。 较早的客户反馈：这有助于获取客户的反馈并进行及时的调整。客户也有机会对建立好的模型作出反应，从而提高系统可靠性、稳定性和可维护性。 风险管理：增量模型有助于将风险分散到各个增量中，通过逐步增加功能，可以更容易地识别和管理潜在的技术或业务风险。 成本控制：整个项目的资金不会被提前消耗，因为首先开发和交付了主要功能和高风险功能。 适用于需求变化：增量模型相对于瀑布模型等其他模型，具有更强的适应需求变化的能力。
缺点 对软件体系结构的要求：由于各个构件是逐渐并入已有的软件体系结构中的，增量模型要求软件必须具备开放式的体系结构，以便新的构件能够顺利地集成到现有的系统中。 容易退化为边做边改模型：增量模型的灵活性可能会导致项目团队在开发过程中不断适应需求的变化，使得开发过程逐渐退化为边做边改的模型。 增量粒度难以选择：如果增量粒度过大，可能会导致开发周期过长，难以在短时间内向客户交付可用的产品；如果增量粒度过小，则可能会增加管理的复杂性，提高开发成本。 确定业务需求困难：在增量模型中，确定所有的基本业务需求可能会比较困难，因为需求可能会在开发过程中不断变化
螺旋开发模型
优点 风险管理：螺旋模型将风险管理置于软件开发过程的核心，对软件开发中的不确定性和风险进行了全面而系统的管理，减少项目失败的风险。 灵活性：根据项目需求进行定制和调整，更好地满足客户需求，提高软件开发过程的质量。 用户参与：螺旋模型要求开发团队与客户之间进行持续的沟通和协商，确保项目的透明度和可见性。 迭代开发：螺旋模型采用迭代式开发，可以在每个迭代中快速反馈和调整 成本控制：螺旋模型在每个迭代阶段累计开发成本，使支出状况容易掌握，有助于开发团队更好地管理项目成本，避免不必要的浪费和资源浪费。
缺点 风险分析依赖：螺旋模型强调风险分析。这可能导致在某些情况下，客户对风险分析的接受度不高，从而影响项目的顺利进行。 协调困难：螺旋模型的开发过程过于灵活，不利于已经签署合同的客户与开发者之间的协调。 适用范围受限：螺旋模型主要适用于大型软件项目，对于小型软件项目可能不太适用。 迭代次数多：过多的迭代次数可能会增加开发成本，延迟提交时间。
迭代开发模型：和增量模型的区别在于，迭代开发模型不能并行，必须在开发一版之后才能迭代。增量开发模型可以不同功能并行。
适用场景 迭代开发模型 适用于需求不甚明确、难度比较大的软件开发项目。 适用于需要快速响应市场变化、功能复杂或团队成员分散等场景。 增量开发模型 适用于需求比较明确、架构比较稳定的软件开发项目。 适用于可以模块化、组件化的软件系统开发。
敏捷开发模型：可以理解为快速开发模型
需求比较明确，产品比较明确的时候建议用瀑布开发模型，其他的模型都是在瀑布模型的基础上针对缺点进行强化的模型
测试模型
V模型
测试滞后：V模型的主要缺点是测试活动滞后于开发活动，导致一些早期的问题无法被及时发现和解决。
缺乏灵活性：每个阶段都按照固定的顺序进行，无法适应需求变化频繁和迭代开发的项目。
串行过程：V模型中的开发阶段和测试阶段是串行的，即一个阶段完成后才能开始下一个阶段。这种串行过程可能导致开发和测试之间的衔接不够紧密，
优点，每个阶段都清晰明了，便于控制开发的每个过程，既包括单元测试，又包括系统测试
w模型
优点 测试与开发并行：W模型强调测试与开发活动的同步进行，并行有助于更早地发现潜在问题 测试对象广泛：W模型的测试对象不仅仅是程序代码，还包括需求和设计。 早期缺陷检测：更早地发现需求不明确、设计不合理等潜在问题。 全程质量保障：W模型贯穿了软件开发的整个生命周期，每个阶段都有相应的测试活动进行质量监控。 增强团队协作：在W模型中，开发团队和测试团队在整个项目过程中紧密合作
开发和测试呈线性关系：虽然测试与开发同步进行，但W模型中开发和测试依然是线性的关系。这意味着上一阶段完全结束，才可正式开始下一个阶段工作，无法支持迭代、自发性以及变更调整。在实际项目中，需求的变更和调整是常见的，如果遇到需求频繁变更的情况，W模型可能会导致项目进度受阻。 对文档依赖度高：W模型要求有完整、准确的文档作为测试的依据。如果缺乏文档或文档质量不高，测试人员将难以制定有效
测试分类
1、测试开发阶段
单元测试
编码完成后，对模块、类或者函数和方法进行测试，通常是开发人员和白盒测试人员
集成测试
单元测试完成后，测试模块和模块之间的内容，开发人员和白盒测试人员
系统测试
集成测试完成之后，对整个的系统，软件，APP，等进行测试，黑盒人员可以来测试
验收测试
系统测试之后，阿尔法测试（内测）贝塔测试（公测—邀请用户）
缺陷报告
在测试后发现缺陷，应该生成缺陷报告，记录测试结果。为后期统计缺陷提供依据
状态
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
