【测试】测试基础
其他
2018-08-14 05:18:56
阅读次数: 0
什么是测试
- 验证软件是否满足用户需求
- 是:即验证它是正确的
- 否:即要找出软件的bug(找bug是软件测试最基本的活动)
软件测试的目的和原则
- 目的:验证软件有没有问题
- 原则:以客户需求为中心,遵循软件测试的规范、流程、标准和要求
什么是需求
- 需求:满足客户期望或正式规定文档所具备的权能。这里的正式规定文档指的是:合同、标准、规范等。
- 需求包括用户需求和软件需求:
- 用户需求:用户想要干什么
- 软件需求:根据用户需求更细化、更具体。能够指导开发人员编写代码,指导测试人员编写测试用例
- 用户需求转换为软件需求需要和用户不断的进行沟通,确认,细化。具体
- 需求不一定是正确的,我们需要对需求进行测试
什么是bug
- 通俗的来讲,凡是实现效果与需求不符合的都可认为是bug,但是这个说法是不全面的
- 准确来说:如果有需求规格说明书且正确,那么程序与需求规格说明书之间不符合即可认为是bug。若无规格说明书,则一切以用户的需求为标准,当程序最终没有实现用户合理预期要求时,就是bug.
- 注意:对于测试人员来说,bug是找不完的,测试人员只是根据用户需求来进行测试,来让用户满意
什么是测试用例
- 测试用例:向被测试程序输入的一种集合。这组集合包含:测试环境、操作步骤、测试数据、预期结果等要素
- 测试人员在测试过程中可能会遇到一下问题:
- 不知道是否较全面的测试了所有功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施
- 存在大量冗余测试影响测试效率
- 测试用例的产生就是为了解决上述问题
开发模型
- 软件的生命周期:需求分析、计划、设计、编码、测试、运行维护
- 瀑布模型
- 适用于需求稳定、变化少的项目、公司以前做过类型的项目,可以参照使用瀑布模型
- 螺旋模型
- 强调风险分析,渐进式的开发模式
- 适用于:规模庞大、复杂度高、风险大的项目
- 增量与迭代
- 增量:块与块的拼接(逐块建造)
- 迭代:先轮廓、再细节(精益求精)
- 敏捷
- 注重人与人之间的交互、轻文档(对文档依赖度不高)、要求客户参与其中、拥抱变化
- 角色:PO(product owner),类似于产品经理;SM(scrum master),敏捷教练,类似于项目经理;team,团队
- 敏捷中的测试:轻文档、快速迭代
测试模型
- V模型(串行)
- 左为开发工作,右为测试工作
- 缺点:将测试放在了最后,会给人以舞蹈认为测试不重要
- 测试人员在编码阶段开始编写测试用例
- 单元测试:代码测代码;集成测试,一般由开发人员来测试
- 测试人员重点才能与系统测试(测试环境的搭建、测试数据的准备、……、撰写测试报告等);有时也会参与验收测试
- W模型(双V并行)
- 双V并行,两个V分别代表测试和开发
- W模型特点:测试的对象不仅是程序,需求、设计等同样要测试,测试与开发是同步进行的
- W模型优点:有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,显著减少总体测试时间,加快项目进度
- W模型局限性:需求、设计、编码等活动被视为串行的;测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临着困惑
ISO:质量的八大原则(扩展)
- 以客户的焦点为中心:组织依存于其顾客。因此组织应理解顾客当前和未来的需求,满足顾客并争取超越顾客期望
- 领导作用:领导者确立本组织统一的宗旨和方向。他们应该创造并保持使员工能充分参与实现组织目标的内部环境
- 全员参与:各级人员是组织之本,只有他们的充分参与,才能使他们的才干为组织获益
- 过程方法:将相关的活动和资源作为过程进行管理,可以更高效地得到期望的结果
- 管理的系统方法:识别、理解和管理作为体系的相互关联的过程,有助于组织实现其目标的效率和有效性
- 持续改进:组织总体业绩的持续改进应是组织的一个永恒的目标
- 基于事实的决策方法:有效决策是建立在数据和信息分析基础上
- 互利的供方关系:组织与其供方是相互依存的,互利的关系可增强双方创造价值的能力。
转载自blog.csdn.net/Aurora_pole/article/details/81447973