标签：基本 需求 纸杯 软件产品 概述 测试 软件 软件测试
- 软件质量概述
1）软件质量：
软件产品基本满足需求及隐式需求的程度。
2）软件产品满足基本需求
指其能满足软件开发时所规定需求的特性，其次是软件产品满足隐式需求的程度。
3）软件质量的三个层次
- 满足需求规定：软件产品符合开发者明确定义的目标，并且能可靠运行。
- 满足用户需求：软件产品的需求是由用户产生的，软件最终目的就是满足用户需求，解决用户的实际问题
- 满足用户隐式需求：软件如果满足用户的隐式需求，极潜在的可能需要在将来开发的功能。将会极大的提升用户的满意度，这就意味着软件质量更高。
4）如何评价一款软件的质量
- 功能性：在指定条件下，软件满足用户显示需求和隐式需求的能力。
- 可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。
- 可使用性：在指定条件下，软件产品被使用、理解、学习能力。
- 效率：在指定条件下，相对于所有资源的数量，软件产品可提供适当性能的能力。
- 可维护性：指软件产品被修改的能力。修改包括修正、优化和功能规格变更的说明。
- 可移植性：指软件产品从一个环境迁移到另一个环境的能力。
这六大特性及其子特性是软件质量标准的核心，软件测试工作就从这 6 个特性和 27 个子特性去测试、评价一款软件产品。
“纸杯测试”：
- 测试项目：纸杯
- 需求测试：查看纸杯说明书是否完整
- 界面测试：观察纸杯外观，表面是否光滑、手感是否舒适
- 功能测试：用纸杯装水，观察是否漏水
- 安全测试：纸杯是否有毒或细菌
- 易用性测试：用纸杯盛放开水是否烫手、纸杯是否易滑、是否方便饮用
- 兼容性测试：用纸杯分别盛放水、酒精、饮料、汽油等，观察是否有渗漏现象
- 可靠性测试：从不同的高度摔下来，观察纸杯的损坏程度
- 可移植性测试：将纸杯放在温度、湿度等不同的环境中，查看纸杯是否还能正常使用
- 可维护性：将纸杯揉捏变形，看其是否能恢复
- 压力测试：用一根针扎在纸杯上不断增加力量，记录多大压强时能穿透纸杯
- 疲劳测试：用纸杯分别盛放水、汽油放置 24 小时，观察其渗漏情况（时间和程度）
- 跌落测试：纸杯（加包装）从高度落下，查看达到破损的高度
- 震动测试：纸杯（加包装）六面震动，评估它是否能应对恶劣的公路 / 铁路 / 航空运输等
- 测试数据：编写具体测试数据（略），其中可能会用到场景法、等价类分法、边界值分析法等测试方法
- 期望输出：期望输出需求查阅国际标准及用户的使用需求
- 用户文档：使用手册是否对纸杯的用法、使用条件、限制条件等有详细描述
- 说明书测试：查看纸杯说明书的正确性、准确性及完整性
- 影响软件质量的因素：
- 需求模糊
- 软件开发缺乏规范性文件指导
- 软件开发人员问题
- 缺乏软件质量控制管理
- 软件缺陷管理：
软件由于自身的特点和开发模式，隐藏在软件内部的缺陷无法根除。软件测试工作就是查找软件中存在的缺陷，反馈给开发人员使之修改，从而确保软件的质量，因此软件测试要求测试人员对软件缺陷有一个深入理解。
- 需求不明确
- 软件结构复杂
- 编码问题
- 项目期限短
- 使用新技术
|
划分标准
|
缺陷类型
|
|
测试种类
|
界面类
|
功能类
|
性能类
|
安全性类
|
兼容性类
|
|
严重程度
|
严重………………一般………………次要………………建议
|
|
优先级
|
立即解决………………高优先级………………正常排队………………低优先级
|
|
发生阶段
|
需求阶段
|
架构阶段
|
设计阶段
|
编码阶段
|
测试阶段
|
基本流程都要经过提交、分配、确认、处理、复测、关闭。
- 常见的软件缺陷管理工具
- Bugzilla
- 禅道
- JIRA
- 软件测试简介
- 测试：找到软件中存在的缺陷（find bugs）
- 调试：根据 所发现的错误而进行代码跟踪和分析，确定缺陷产生的原因，即为了修正缺陷（fix bug）而进行Debug
- 软件测试的目的
- 对于软件开发：软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发模式、工具、技术等方面的问题与不足，预防下次缺陷的产生
- 对于软件测试：使用最少的人力、物力、财力、时间找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富经验
- 对于客户需求：软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户审评软件提供有力的依据
- 软件测试的分类
- 按照测试阶段分类
- 单元测试：验证软件单元是否符合软件需求与设计，开发人员自测
- 冒烟测试：软件构建版本建立后，对系统的基本功能进行简单的测试，这种测试重点验证的时程序的主要功能，而不会对具体功能进行深入测试
- 集成测试：冒烟测试之后，将已经测试过的软件单元组合到一起测试它们之间的接口，用于验证软件是否满足设计需求
- 系统测试：将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试
- 验收测试：主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项需求
- 黑盒测试：把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎样实现的
- 白盒测试：测试人员了解软件程序逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程
- 功能测试：测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等
- 性能测试：测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等
- 手工测试：测试人员一条一条的执行代码完成测试工作。费时费力且很验证保证测试效果。
- 自动化测试：借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。
- 安全性测试：试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。
- 文档测试：以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。
- α测试：软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。
- β测试：软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。
- 回归测试：对修改后的程序重新进行测试确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。
- 随机测试：没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。
- 常见的软件测试模型
优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。
缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。
优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。
缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。
H模型将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。
X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。
优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。
缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。
- 软件测试原则
● 测试应基于客户需求。
● 测试要尽早进行。
● 穷尽测试是不可能的。
● 遵循GoodEnough原则。
● 测试缺陷要符合“二八”定理。
● 避免缺陷免疫。
- 软件测试流程
基本流程：
- 分析测试需求
- 制定测试计划
- 设计测试用例
- 执行测试
- 编写测试报告
标签：基本,
需求,
纸杯,
软件产品,
概述,
测试,
软件,
软件测试
From： https://www.cnblogs.com/tsdby/p/16829683.html