标签：策略 程序代码 效果 程序开发 测试 mamicode src 过程 逻辑
一种观点：为发现错误而执行程序的过程
另一种观点：评价程序或系统属性为目的的活动，是对软件质量的度量。
什么是软件缺陷：
1）软件未实现规格说明书中的功能
2）功能出现了不应有的错误
3）软件功能超出规格说明书范围
4）软件未达到应达到的目标
5）软件难以理解，不易使用、运行速度缓慢
V模型（较常用）：
单元测试：测试详细设计中的功能是否全部实现
集成测试：测试概要设计中的功能是否全部实现
系统测试：测试需求分析中的功能是否全部实现
验收测试：测试用户需求是否全部实现
其中，单元测试和集成测试一般公司不会采用。
该模型的缺陷：
1）周期较长：开发阶段和测试阶段是顺序进行的，没有进行并行工作，导致周期比较长；
2）问题发现较迟：比如在系统测试的时候发现有个需求是错误的，那么按V模型的话就要重新修订需求文档——概要设计——详细设计——编码——单元测试——集成测试——系统测试，这样一连串的工作下来可能时间就来不及了。
W模型（较常用）
黄色箭头表示开发，绿色箭头表示测试，两者并行进行。需求分析文档整理好后就进行系统测试用例设计，概要设计好后就进行集成测试用例设计，详细设计好后就进行单元测试用例设计，编码好后集成运用前面设计好的集成测试用例进行集成测试，然后编码实施时运用前面设计好的系统测试用例进行系统测试，最后验收交付。
该模型的优点：
1）将部分测试工作提前进行，缩短了整个项目的周期
2）一些问题在测试用例设计阶段可以提早发现，为解决问题争取更多的时间
X模型
H模型
测试计划：明确测试的范围（哪些功能需要测试，哪些功能不需要测试）、明确测试策略（采用哪些用例的测试方法进行测试、怎么算通过怎么算不通过）、明确人员进度安排
测试分析：了解需求文档、了解各个模块的功能，哪些功能需要哪些用例来测试，进行构思
测试设计（技术含量较高，工作量比较大）：采用用例设计技术进行用例设计（例如黑盒测试：等价类、边界值、因果图法、决策树等）
测试执行：执行测试用例，提交缺陷，反馈给开发进行修改
测试评估：对测试活动进行总结，对软件系统质量进行评估
注意：单元测试、集成测试、系统测试分别会产生相应的测试计划文档、测试用例文档、测试缺陷报告文档、测试报告文档
静态分析：不需要执行软件
动态测试：需要执行软件
黑盒测试（又名功能测试、数据驱动测试）：顾名思义，就像是用一个黑色的盒子将程序代码盖住，我们不关心程序内部结构，只需要知道输入什么样的值（IN）得到什么样的结果（OUT）
白盒测试（又名结构测试、逻辑驱动测试）：需要了解程序内部的逻辑机构
灰盒测试：黑盒测试和白盒测试的结合，即需要了解程序的内部逻辑结构，又需要输入输出值
单元测试：通常在代码完成之后进行，主要是测试函数的功能是否正确实现
集成测试：通常在单元测试之后，各个模块代码完成后集成在一起时进行，主要测试各个模块之间的调用、接口参数之间的传递是否正确
系统测试：集成测试之后进行，主要验证需求规格是否被正确实现
验收测试：用户能否接受软件系统
回归测试：开发人员将缺陷修改好提交后，需要测试该功能是否正确实现以及是否影响到其他功能引起新的缺陷
冒烟测试：程序开发完成后，如基本功能都不能实现（就像一通电电路板就冒烟了），那么我们就将测试申请驳回。因为基本功能都未实现的情况下，测试效率是很低下或无效的，浪费测试资源。
α测试（用户在开发环境下进行系统操作）：当测试人员测试好后，邀请一些用户在开发环境下进行系统操作，看是否有问题
β测试（用户在用户环境下进行系统操作）：软件测好后发布了一个β测试版本，用户在本地安装后进行操作，看是否有问题。一些大的软件公司会发布β版本，比如腾讯的QQ的β版本
尽早的和不断的进行软件测试（尽早的发现问题，以保证修改问题的代价是最小的，这就是V模型发展成W模型的原因）
应避免测试自己的程序
pareto原则（80/20原则）（80%的缺陷是在20%的模块中发现的，当测试时发现某个模块问题比较多的时候要增加人手进行充分测试以发现更多的缺陷）
测试用例由输入和预期的输出结果组成（要根据预期的输出结果来判断测试用例是否通过，所以输入和预期的输出结果必须成对存在）
程序修改后要回归测试
穷举测试是不可能的
什么是黑盒测试技术：不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。
测试步骤：同上面测试的生命周期
为什么要设计测试用例：
1）良好的测试用例可以缩短实施测试的时间（测试准备工作是跟开发并行的，只有测试执行的时间是单独进行的，从整体上缩短了项目周期）
2）确保测试的系统性、全面性
3）提高测试的可复用性（如有测试人员变动，交接人员会根据测试用例很快熟悉系统，减少对人员的依赖）
2、黑盒测试用例设计方法
等价类划分法：把程序所有可能输入的数据划分为若干子集，每一子集的代表性数据在测试中的作用等价于这一子集的其他值，每一个子集就是一个等价类。等价类需要考虑有效等价类和无效等价类
设计步骤：1）划分等价类 2）确定测试用例
边界值法：长期测试经验表明，大量错误发生在输入和输出范围的边界上，而不是发生在输入输出范围的内部。因此，对各种边界设计测试用例，能取得良好的效果。
将边界值测试用例补充到上面等价类划分法中：
判定表驱动法：是分析和表达较为复杂逻辑条件下软件状态和行为的有效工具。用它可以设计出完成的测试用例集合，将复杂问题的各种可能情况罗列出，是测试内容变得简单明了而避免遗漏。
判定表设计步骤：
1）确定规则的个数，条件数为n，规则个数=2n
2）列出所有的条件桩和动作桩
3）填入条件项
4）填入动作项
5）简化判定表，合并相似规则
列出所有的条件桩和动作桩：
进行简化合并后：
"—"处无论是Y或N对输出结果都没有影响。
因果图法
设计步骤：
1）从程序规格说明中找出因（条件项）和果（结果项），并分析因果关系，以及因因、果果之间的约束关系，绘制因果图
2）通过因果图转为判定表
3）将判定表中不符合约束条件的规则去除
4）然后将判定表简化，将每一规则简化为一个测试用例
该例的因果图：
注：该例中不存在条件约束，如果在实际工作中遇到有条件约束的，要用上面的条件约束的符号将其标出来。
将因果图转化为判定表：
标签：策略 程序代码 效果 程序开发 测试 mamicode src 过程 逻辑
原文地址：https://www.cnblogs.com/nietzsche2019/p/10864725.html
