精华内容
下载资源
问答
  • 软件测试计划
    万次阅读 多人点赞
    2019-09-24 09:03:28
    • 引言:

     

    编号

    确定项目

    描述

    1

    确定范围

    确定被测项目中功能模块,子功能模块等需要测试的范围。

    2

    确定需求

    确定每个功能结果定义,确定此功能是否存在缺陷。

    3

    确定策略

    确定对项目做哪些测试。如:功能测试,性能测试等。

    4

    确定方法

    确定对每个策略是用哪些方法。如:边界值,等价类等。

    5

    确定工具

    : 功能测试使用Seleium,性能测试使用Jmeter等。

    6

    确定资源

    测试需要的设备,服务器、参与测试的人员、测试任务的分工,测试工作的进度。

    7

    交付文档

    确定测试工作中生成哪些文档,可提交文档有哪些。

     

    1. 测试项目:

    项目名称

    XX项目

    使用背景

    // 用户 协会分会负责人、期刊客户

    开发者

    XX集团

    项目简介

     学术专著出版平台” 定位是一家图书产品联合创建、销售、返利的平台;平台联合各专业协会、学会、出版社等机构,组织大批专家人才建立“专家指导委员会”,为图书进行策划、上报、审校、出版、运营等服务;主要业务情景是:策划人寻求参编人,共同创建图书及销售,参编人支付参编图书的预购款,该笔资金作为公司运营图书的成本,等待图书出版后,让消费者以个人名片或链接的形式进行购买图书,参编人员不仅可以通过图书评职称、扩大知名度、传播学术价值,另外让参编人通过销售,实现“0”元出书并且获得额外收入;策划人在发展参编和策划人同时,获得相应奖励。

     

    1. 测试目的:

    编号

    目的

    1

    软件测试是为了发现错误而执行程序的过程。

    2

    测试是为了证明程序有错,而不是证明程序无错。

    3

    一个好的测试用例在于它发现至今未发现的错误。

    4

    一个成功的测试是发现了至今未发现的错误的测试。

     

    1. 文档受众:

    编号

    人员

    原因

    1

    产品设计人员

    明确说明测试范围,方法,工作周期信息。

    2

    产品研发人员

    明确说明测试范围,方法,工作周期信息。

    3

    产品测试人员

    明确说明测试范围,方法,任务分工,预计完成时间。

    4

    备注

    此为内部开发文档,不做外部参考。

     

     

     

     

    1. 测试参考文档

    编号

    文档名称

    作用

    1

    需求文档

    确定项目功能模块,功能运行结果。

    2

    技术文档

    确定项目中使用开发语言,数据库数据限制。

    3

    项目模型文档

    初步了解项目页面内容,方便编写用例。

     

    1. 测试提交文档:

     

    编号

    文档名称

    作用

    1

    测试计划

    明确说明测试范围,方法,工作周期信息。

    2

    测试用例

    明确说明测试工作的细节测试工作。

    3

    缺陷报告

    明确说明项目中的缺陷描述,与修复情况。

    4

    测试报告

    明确说明测试结果,测试模块,缺陷分布情况等等信息。

     

     

    • 术语定义:

     

    1. 项目术语:

    编号

    缩写、术语

    解释

    1

     

     

    2

     

     

     

    1. 测试专业术语:

    编号

    术语

    解释

    1

    单元测试

    开发者编写的一小段代码,检验被测代码的一个很小的、很明确的功能是否正确。

    2

    集成测试

    开发者编写的多个段代码单元,组合到一起形成集成测试,检查多个单元组合功能是否正确。

    3

    冒烟测试

    针对产品的基本功能进行测试。

    4

    功能测试

    又称正确性测试,它检查软件的功能是否符合规格说明。

    5

    可靠性测试

    对服务器施加一定压力,测试服务器是否可以长期稳定运行。

    6

    压力测试

    对服务器施加一定压力后进行功能测试,测试服务器在一定压力下是够可以正常计算。

    7

    负载测试

    对服务器施加压力,测试服务器可以容纳多少人访问,多少人访问后出现BUG

    8

    易用性测试

    主要从使用的合理性和方便性等角度对软件系统进行检查。用户来测。

    9

    兼容性测试

    测试Web页面是否支持所有浏览器,访问后页面所有功能无异常。

    10

    安全测试

    服务器数据安全性,用户数据安全性,用户操作安全性,用户财产安全性、公司财产安全性。

    11

    数据完整性测试

    对数据及数据库能否正常运行访问的测试。

    12

    回归测试

    开发修改后的BUG在测试一遍。

    13

     

     

    14

     

     

     

    1. 缺陷优先级:

    级别

    描述

    P0

    严重级别比较高的,影响测试进行或者系统无法继续操作,立即修复,1天。

    P1

    基本功能没有实现,对系统操作有影响,23天。

    P2

    一般性功能,页面缺陷,45天。

    P3

    准备在下一轮测试前修改完毕,准备在下一版本中修改。

     

    1. 严重程度定义:

    级别

    严重程度描述

    S0

    数据丢失,数据计算错误、数据传递错误、对数据库造成破坏,造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。

    S1

    应用系统崩溃、非正常关闭和无响应,但没有造成数据丢失。系统的主要功能不能正确实现或不完整。

    S2

    规定的非主要功能没有实现或不完整、影响系统的运行;设计不合理造成性能低下。

    S3

    不影响业务运行的功能问题。

    S4

    软件设计和功能实现等不完全合理之处提出建议。

     

    1. 用例优先级定义:

    级别

    优先级描述

    P0

    确保系统基本功能及主要功能的测试用例

    P1

    确保系统功能的完善方面的测试用例

    P2

    关于用户体验,输入输出的验证;较少使用或辅助功能的测试用例。

     

    • 测试策略:

    1、单元测试

     

    单元测试

    测试目标

    开发者编写的一小段代码,检验被测代码的一个很小的、很明确的功能是否正确。

    测试范围

    测试整个项目中的每一行代码进行测试。

    完成标准

    代码的一个很小的、很明确的功能都正确。

    需要考虑的特殊事项

    //

    使用工具

    Python + Selenium + unittest

     

     

     

     

     

     

    2、集成测试:

     

     

    集成测试

    测试目标

    开发者编写的多个段代码单元,组合到一起形成集成测试,检查多个单元组合功能是否正确。

    测试范围

    开发者编写的多个段代码单元,组合到一起形成的集合。

    完成标准

    多个单元组合功能正确。

    需要考虑的特殊事项

    //

    使用工具

     

     

    3、冒烟测试:

     

    冒烟测试

    测试目标

    版本是否值得系统测试

    测试范围

    1、返测上一版本提交的测试报告。
    2、测试系统的基本功能。

    完成标准

    基本功能通过,并继续测试。

    需要考虑的特殊事项

    此阶段不超过1天。

     

    4、功能测试:

     

    功能测试

    测试目标

    确保测试计划中所列出的测试范围,保证其功能正常。

    测试范围

    1、按照测试计划所规定的测试范围。
    2、利用有效的和无效的数据来执行各个用例、用例流或功能
    3、以核实以下内容:
    1)在使用有效数据时得到预期的结果。
    2)在使用无效数据时显示相应的错误消息或警告消息。

    完成标准

    按照测试计划的测试通过标准,完成测试。

    需要考虑的特殊事项

    确定或说明那些将对功能测试的实施和执行造成影响的事项或因素。(内部的或外部的)

    使用工具

    Seleium + python + 谷歌

     

    1. 易用性测试:

     

    易用性测试

    测试目标

    模拟真实用户,无经验用户,测试系统的易用性

    测试范围

    前台

    完成标准

    成功地核实出前台各个网页符合可接受易用性标准。

    需要考虑的特殊事项

     

     

     

     

     

     

    7、兼容测试:

     

    兼容测试

    测试目标

    测试Web页面是否支持所有浏览器,访问后页面所有功能无异常

    测试范围

    前台

    完成标准

    使用多个不同浏览器访问后界面无异常即为通过。

    需要考虑的特殊事项

    浏览器版本;浏览器类型是否都测到。

     

    8、可靠性测试:

     

    可靠性测试

    测试目标

    使用LR模拟真实用户对服务器施加一定压力

    测试范围

    项目服务器。

    完成标准

    持续运行特定时间不出现问题。

    需要考虑的特殊事项

    测试机是否满足需求。

     

    9、压力测试:

     

    压力测试

    测试目标

    使用LR模拟真实用户对服务器施加压力。

    测试范围

    项目服务器。

    完成标准

    直到服务器卡死。获得服务器资源,最大与链接数等数据。

    需要考虑的特殊事项

    测试机是否满足需求。

    使用工具

    Jmeter + fiddler + 火狐

     

    10、负载测试:

     

    负载测试

    测试目标

    使用LR模拟真实用户对服务器施加一定压力,对服务器进行主要功能测试。

    测试范围

    项目服务器&前台界面

    完成标准

    对服务器施加一定压力后前台功能正常,访问时间3-8之内。

    需要考虑的特殊事项

    测试机是否满足需求。

    使用工具

    Jmeter + fiddler + 火狐

     

    11、数据完整性测试:

     

    数据完整性测试

    测试目标

    确保数据库设计完整性。

    测试范围

    数据库及表结构

    完成标准

    数据库约束、完整性等设置达到需求标准。

    需要考虑的特殊事项

    数据遭到破坏,易恢复性。

     

     

     

     

     

     

    12、回归测试:

     

    回归测试

    测试目标

    确保BUG修复的完整性。

    测试范围

    项目中出BUG 的部分

    完成标准

    项目中出现的BUG完成修复,并将缺陷保存下来。

    需要考虑的特殊事项

    BUG的功能和BUG相关的功能都需要回测。

     

    13、功能测试范围:

    模块

    功能

    应用策略

    备注

     

     

     

     

     

     

     

     

     

    四、测试规则:

    1、准入规则

    编号

    测试策略

    进入准则

    1

    单元测试

    项目编码阶段,开发人员每编写完一个单元时进入测试

    2

    集成测试

    项目编码阶段,开发人员每编写完多个单元时进入测试

    3

    功能测试

    项目系统测试阶段,开发人员根据需求开发完成时,进入测试。

    4

    易用测试

    功能测试完成后进入测试。

    5

    兼容测试

     

    6

    可靠测试

    功能测试完成后进入测试。

    7

    压力测试

     

    8

    负载测试

     

    9

    数据完整性

    性能测试完成后进入测试。

    10

    回归测试

    提交的缺陷报告修改后。

     

    2、暂停/退出规则

     

    编号

     

    1

    软件系统在进行单元、集成、确认、系统、安装、验收测试时,发现缺陷达到一定数量或出现重大错误导致无法测试时,暂停测试返回开发。

    2

    发生其他未知因素需要暂停时,测试应随之暂停,并备份暂停点数据。

     

    • 测试资源:

     

    1. 硬件资源

    编号

    CPU

    内存

    硬盘

    系统

    软件

    1

    2.5

    4+

    100+

    Win7

    JmeterseleiumAppScan

     

     

     

     

    1. 测试人力资源:

    编号

    角色

    人员

    具体职责

    1

    确认需求

     

    明确需求

    2

    制定计划

     

    决定测试策略,人员分工,测试周期

    3

    准备测试环境

     

    测试工作开始前准备工作

    4

    执行测试工作

     

    编写用例,执行用例,提交缺陷报告,回测等。

    5

    编写测试报告

     

    编写项目的测试结果。

     

     

    1. 测试工作进度:

    编号

    任务

    范围

    人员

    时间

    1

    确认需求

     

     

     

    2

    定制测试计划

     

     

     

    3

    准备测试环境

     

     

     

    4

    单元测试

     

     

     

    5

    集成测试

     

     

     

    6

    冒烟测试

    功能测试

    兼容测试

    易用性测试

     

     

     

    7

    可靠性测试

    压力测试

    负载测试

     

     

     

    8

    安全测试

     

     

     

    9

    数据完整性测试

     

     

     

    10

    回归测试

     

     

     

    11

    编写测试报告

     

     

     

     

    • 系统风险

    1、系统风险:

    (1)、计划的测试时间,不能满足测试组的要求,主要是功能冻结后的系统测试的时间可能不够。

    (2)、测试资源的及时到位(设备和人员)。

    (3)、需求不明确可能导致开发的产品与目标不一致。

    (4)、测试人员对测试工具的使用熟悉程序不够;

    (5)、被测试产品存在重大错误,以至于测试无法继续,需要开发组进行额外的调试和修改才能继续;

    (6)、硬件、软件或网络环境出现故障等

    2、应急措施:

    (1)、如果上述潜在的可能事件发生,则通过适当加班来保证计划的按时完成。

    (2)、如果是由于被测试产品存在重大错误而严重影响测试进度,则考虑按照测试暂停标准来暂停该测试。

    (3)、如遇到功能需求不明确,需要沟通协商解决。

    (4)、人员不足,则加班、或者进行不同组人员调动,按照测试进度完成测试任务。

    测试的完成标准

     

    • 完成标准
    1. 单元测试完成标准:

    (1)、按照单元测试计划完成了所有规定单元的测试

    (2)、达到了测试计划中关于单元测试所规定的覆盖率的要求

    (3)、软件单元功能与设计一致

    (4)、在单元测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    2、集成测试完成标准

    (1)、按照集成构件计划及增量集成策略完成了整个系统的集成测试

    (2)、达到了测试计划中关于集成测试所规定的覆盖率的要求

    (3)、被测试的集成工作版本每千行代码必须发现至少2个错误(不含优化级别错误)

    (4)、集成工作版本满足设计定义的各项功能、性能要求

    (5)、在集成测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    3、功能/易用测试完成标准

    (1)、功能测试用例设计已经通过评审

    (2)、按照功能测试计划完成了功能测试

    (3)、达到了功能测试计划中关于功能测试所规定的覆盖率的要求

    (4)、系统达到详细设计定义的各项功能,性能

    (5)、在功能测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    4、兼容测试完成标准

    (1)、兼容测试用例设计已经通过评审

    (2)、按照兼容测试计划完成了兼容测试

    (3)、达到了兼容测试计划中关于兼容测试所规定的浏览器的要求

    (4)、在兼容测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    5、系统测试完成标准

    (1)、系统测试用例设计已经通过评审

    (2)、按照系统测试计划完成了系统测试

    (3)、达到了测试计划中关于系统测试所规定的覆盖率的要求

    (4)、被测试的系统每千行代码必须发现至少1个错误(不含五级错误)

    (5)、系统满足需求规格说明书的要求

    (6)、在系统测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    6、验收测试完成标准

    (1)、软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。

    (2)、在验收测试中发现的错误已经得到修改,各级缺陷修复率达到标准

    (3)、所有测试项没有残余紧急、严重级别错误。

    (4)、需求分析文档、设计文档和编码实现一致。

    (5)、验收测试工件齐全(测试计划、测试用例、测试日志、测试通知单、测试分析)

    7、可靠/压力/负载测试完成标准

    (1)、性能测试用例设计已经通过评审

    (2)、按照性能测试计划完成了性能测试

    (3)、达到了性能测试计划中关于性能测试所规定要求

    (4)、在性能测试中不通过的用例已经得到修改,性能达到预计标准

    8、缺陷修复率标准

    (1)、紧急、严重级别错误修复率应达到100%

    (2)、普通级别错误修复率应达到95%以上

    (3)、优化级别错误修复率应达到60%以上

    注:项目紧急时,普通级别错误修复率达60%以上;优化级别错误修复率达20%即可。

    9、覆盖率标准

    (1)、测试用例执行覆盖率应达到100%(功能测试用例均已执行)

    (2)、测试需求执行覆盖率应达到100%(业务测试用例均已执行)

    更多相关内容
  • 软件测试-测试计划

    千次阅读 2019-04-18 19:36:29
      相信大多数的软件测试工程师都听说过或者简单了解过测试计划,但是你真的知道什么是测试计划么?你真的知道如何编写测试计划么?大多数人应该是一脸茫然。百度的结果五花八门,有没有相对规范的标准呢?答案是...

      相信大多数的软件测试工程师都听说过或者简单了解过测试计划,但是你真的知道什么是测试计划么?你真的知道如何编写测试计划么?大多数人应该是一脸茫然。百度的结果五花八门,有没有相对规范的标准呢?答案是没有,至少我没有找到。那么今天我就结合经验和对一些国内技术前沿的公司跟大家聊一聊什么是测试计划以及如何编写测试计划。
      计划的必要性
      在我们日常的工作和生活中,经常需要做计划。古人云:凡事预则立,不预则废(《礼记.中庸》),也就是强调预先计划的重要性和必要性。
      我们做项目,项目需要定项目计划;测试作为项目中的一部分,当然也需要制定测试计划。

    • 测试计划就像是我们写论文一样,首先做好提纲,才能一步一步的完善填充,有了测试计划就掌握了整个项目的进度和方向,在工作中可以有个指导的作用,不至于偏离工作方向;
    • 测试计划规定预期的目标,以什么样的程度完成和在预期多久内完成,这样的规定能够使工作人员做好心理准备,合理的期限和目标能够使工作人员不松懈,有效率的完成一个项目;
    • 计划作为对未来工作的规划,肯定会受到突发的或者不稳定的因素影响而导致整个项目出现延期甚至无法进行的结果。因此计划中对于风险评估的必要性就在于罗列出影响整个项目进行的因素,并制定相应紧急方案,将损失降至最小化;
    • 人员的安排呈现合理化。任何一个项目内的工作都有难易繁简的划分,因而才需要有专长的工程师进行对应的测试。难度较大的由资深测试人员安排,难度小的由新进实习生来进行,整个项目的进行就会显得合理化层次化条理化。同时将职责清晰地具体划分到个人身上,也有利于日后的纠错,及时发现哪个环节出现问题;
    • 测试计划的制作是在需求分析完成之后所进行,所以测试计划的执行在一定程度上也是对需求分析的进一步的检验,若在制定过程中,发现有不合理的因素存在,还能及时反馈,进行调整,不至于使众多的人力做了无用功;
    • 测试计划的安排也是一个项目中多个部门间合作的工作指导,一环扣一环,工作的交接在时间上做好详细的备注,才能让部门的合作显得默契。

      一个测试计划制定者的素养:

    • 有多年从事测试工作的经验,能够条例清晰的罗列出测试中的流程和应当留心的步骤,以及不可缺少的风险规避的意识
    • 对于部门的员工能力要有一定程度的了解,才能合理的安排工作内容
    • 高压下的冷静处理能力,一旦项目出现突发的严重问题,能够冷静找出出错环节。
    • 人际沟通的能力,一个测试计划也是有与其他部门之间的合作关系,需要与其保持及时有效的沟通,了解到他们的需求

      那么我们什么时候来做测试计划呢?
      一般来说,在产品需求确认,做过测试需求分析之后我们就要开始编写测试计划。当然测试计划编写的工作要根据工作实际来决定,也就是具体情况具体分析(政治课学的哈~)
      其实,要想做好测试计划必须有一定的测试经验。那么下面我就结合工作实际,跟大家聊一聊测试计划的内容。
      测试计划的内容:

    • 测试范围 明确测什么?比如:产品的具体业务需求有哪些?产品是web端的还是移动端的,还是两者都有?

    • 测试策略 明确怎么测?对不同业务需求,具体要有哪些测试类型、测试场景、测试方法。

    • 资源安排 包括测试人员的安排,测试环境是怎样的,测试工具的选择等。

    • 进度安排 在明确测试范围、方法和人员之后,我们要考虑什么时候开始测试,预计要测试多久?以便和开发计划、上线计划衔接。

    • 发布标准 发布标准是测试完成和产品上线需要满足的条件,以便项目内所有角色都有一致认可的目标。怎样才算是测完了?达到怎样的标准才可以上线?

    • 风险预防 最后,我们需要对整个测试过程中可能存在的风险,以及当这些风险发生时的应对措施提前进行一些考虑和准备,并在测试计划中体现出来。

      我们把这些内容模板化,形成测试计划的模板。无论是在实际的工作中还是大家学习编写测试计划,都可以用这样的模板来使用。

    在此模板的基础上,我们一点点来剖析如何编写测试计划。
    在这里插入图片描述在这里插入图片描述
    这里的参考资料可以有:(可行性分析报告、软件需求定义、软件系统分析、软件概要设计、软件详细设计、软件测试需求、硬件可行性分析报告、硬件需求分析、硬件概要设计、硬件原理图设计、硬件结构设计、硬件测试需求、模块开发手册、测试时间表及人员安排、测试计划、测试方案、测试报告、测试分析报告、用户操作手册、安装指南等)
    2 测试范围
    测试范围的确定来自于需求文档,依据是项目的交互稿和需求分析结果
    2.1功能测试范围的分析
    功能点的拆分、接口测试、UI测试
    2.2系统测试范围的分析
    (1)容错处理
    (2)兼容性要求
    (3)配置要求
    (4)性能要求
    (5)安全性要求
    (6)可靠性、日志文件
    在这里插入图片描述
    3.测试策略
    为了更好确定软件测试策略,可以问如下一些问题:
    (1).回归测试的范围如何确定?
    (2).如何利用可重复性的测试?
    (3).测试缺乏可预见性,如何收集衡量测试结果的指标?
    (4).如何建立稳定的、模拟系统实际运行的测试环境?
    (5).如何从无穷的输入数据中选择合理的、有效的测试数据集?
    (6).如何衡量这份测试策略的有效性?
    1、基于测试技术的测试策略
    (1).任何情况下都要使用边界值分析方法
    (2).等价类划分法是对边界值分析方法的有效补充
    (3).如果功能的输入数据/条件存在多种组合情况,则使用因果图
    (4).错误推测法
    (5).对照程序逻辑来审查已有测试用例的逻辑覆盖程度
    (6).白盒测试
    2、分阶段的测试策略
    (1).严格执行代码审查
    (2).单元测试和集成测试,准备自动化测试
    (3).系统测试中,以每次发布用户基线为结束标志
    (4).不能忽略安全性测试、可用性测试、配置测试和数据完整性测试
    (5).在功能测试、安全性测试、配置测试中进行探索性测试
    3、基于测试方案的综合测试策略
    (1).测试优先级,优先级越高,越早测试,测试力度越大
    (2).使用尽可能少的测试用例,发现尽可能多的程序错误
    (3).测试策略尽量简单、清晰
    (4).基于缺陷分析的测试策略
    在这里插入图片描述
    4、测试资源
    测试人力资源包含两个维度:
    1、测试人员数量
    2、测试人员经验、能力。
    环境资源一般包括:
    1、测试服务器环境(尽量与线上环境保持一致)
    2、终端环境(PC配置,手机型号)
    3、测试工具(bug管理工具,用例管理工具,性能测试工具等)
    在我们的测试计划中,测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。
    在这里插入图片描述
    5、进度安排
    测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间,并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素,来评估不同阶段、不同类型的测试工作的工作量。
    可以用工作分解结构表方法评估工作量:
    1、列出本项目需要完成的各项任务
    2、细化每个任务,尤其是测试阶段,需要对模块进行拆分,拆分到可衡量和细化的维度
    3、预先设计测试点,按照测试点来估算
    4、给每个维度估算时间,需要优化和重复操作的部分
    5、在已估算结果上浮动10%-15%
    在这里插入图片描述
    6、发布标准
    测试完成的标准,也就是说做到什么样算是测试工作做完了。主要包括:
    1、测试计划里所有测试类型都已经完成了
    2、功能上、兼容性上没有影响用户使用的Bug
    3、允许遗留小部分影响不是很大的Bug,但这个数量应该小于一个值
    4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。
    在满足了测试本身的前提下,产品要发布还需要满足要求:
    1、产品需求都已完成
    2、交互视觉走查都已完成
    3、一流的小部分Bug项目组完成了风险评估,都认可且问题不大
    4、产品使用说明或用户手册或更新log都已完备等等。
    在这里插入图片描述
    7、风险说明
    测试风险分类:
    1、测试范围的风险,测试遗漏、需求变更;比如说一开始测试需求分析不准确、不到位漏了测试点,甚至某个测试类型遗漏了,这样问题就比较大了,所以测试需求分析是整个测试工作的基础,还有就是产品需求变更的风险,加需求、减需求、改需求都需要重新进行测试需求分析,需要测得一定要测到,不需要测的就不要浪费人力物力和工作量;
    2、测试进度的风险,工作量预估不准确、耦合任务延迟、测试人员变动;比如说做计划时工作量估计的不准,测试做着做着发现时间不够导致项目延期,还有测试依赖开发,可能开发工作没有按时完成或改bug不及时导致进度延后,还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动;
    3、产品质量的风险,代码质量、测试人员能力;比如开发的代码质量比较低或者测试人员是新人对业务不熟悉,能力和经验有所欠缺等等。
    测试风险的控制方法:
    1、根据风险发生的概率和带来的影响确定风险的优先级,然后才去措施避免那些可以避免的风险;
    2、风险转移,比如去掉新功能,转移风险;
    3、不可避免的风险,就设法降低风险,如提高测试用例的覆盖率;
    4、事先做好风险管理计划,喜欢里程碑和验收管理;
    5、有一套应急、有效的处理方法,比如全员了解,注意日常观察,及时发现风险出现的征兆;
    6、做计划时,要留有余地
    7、制定文档标准。
    在这里插入图片描述
      到这里我们就完成了一份测试计划。有的人可能依旧存在疑问:做计划真的有那么重要么?我们实际工作中有很多项目根本就没有计划依旧可以完成的啊!我们来看一下不做计划可能会有哪些问题~
     首先,如果没有计划我们无法预估工作量和需要的测试人员数量。一个项目的工作量和需要的人员数量都没有依据,在公司里怎么来协调和安排呢?
     其次,测试人员的分工明确,会导致工作重复和遗漏。出了问题大家可能都觉得不是自己的问题,导致工作混乱效率低下。
    再就是测试进度失控。到底什么时候做完没有一个预期,其他的团队怎么安排工作呢?进度有没有失控也没有判断依据,临到预计的上线时间才发现还有很多没有测到、没测完,直接影响整个项目的进行。
    还有就是应对需求变更困难,对可能出现的风险没有准备。一旦出现问题,大家一片混乱,很容易导致测试遗漏和项目延期。
     最后就是没有统一发布标准,上线意见不一致。测试团队认为Bug太多不能上线,开发团队认为都是小Bug不要紧,先上线再说,导致争执不下的局面。、
     当然根据项目不同还可能存在其他一些列问题…
     总而言之,测试计划的作用非常重要。

    • 指导测试过程
    • 协调项目安排
    • 提高测试效率
    • 提高测试质量
      做测试计划对测试人员的能力和要求是非常高的,从另一个角度来说,测试计划可以体现一个测试人员的自我修养。一个测试人员需要很好的经验沉淀、有很多好的全局意识才能做好一个项目的测试计划。
      希望大家都能够很好的胜任编写测试计划这项工作。
    展开全文
  • 软件测试工作流程

    千次阅读 2021-04-13 11:42:56
    软件测试工作流程一、概括软件测试工作流程主要包括:具体而言:二、测试需求分析的目的1.把用户需求转化为功能需求:2.明确测试活动的五个要素:三、测试需求分析1.确认功能2.场景分析3.挖掘隐性需求(需要测试...

    一、概括

    软件测试工作流程主要包括:

    ① 测试需求分析阶段;
    ② 测试计划阶段;
    ③ 测试设计阶段;
    ④ 测试执行阶段;
    ⑤ 测试评估阶段。

    具体而言:

    ① 测试需求分析阶段:阅读需求,理解需求,主要是对业务的学习,分析需求点,参与需求评审会议。
    ② 测试计划阶段:主要任务是编写测试计划,参考软件需求规格说明书,项目总体计划,内容包括测试范围(来自需求文档),进度安排,人力物力的分配,整体测试策略的制定。风险评估与规避措施有一个制定。
    ③ 测试设计阶段:主要是编写测试用例,会参考需求文档(原型图),概要设计,详细设计等文档,用例编写完成之后会进行评审。
    ④ 测试执行阶段:搭建环境,执行冒烟测试(预测试),然后进入正式测试,bug管理直到测试结束。
    ⑤ 测试评估阶段:出测试报告,确认是否可以上线。

    二、测试需求分析的目的

    1.把用户需求转化为功能需求:

    1)对测试范围进行度量;
    2)对处理分支进行度量;
    3)对需求业务的场景进行度量;
    4)明确其功能对应的输入、处理和输出;
    5)把隐式需求转变为明确。

    2.明确测试活动的五个要素:

    1)测试需求是什么:测试需求需要做到尽可能的详细明确,以避免测试遗漏和误解。
    2)决定怎么测试;
    3)明确测试时间;
    4)确定测试人员;
    5)确定测试环境:测试中需要的技能,工具以及相应的背景知识,测试过程中可能遇到的风险等等。

    三、测试需求分析

    1.确认功能

    1)业务功能:与用户实际业务直接相关的功能或者细节;
    2)辅助功能:辅助完成业务功能的一些功能或者细节,例如:设置过滤条件;
    3)数据约束:功能的细节,主要是用于控制在执行功能时,数据的显示范围,数据之间的关系等;
    4)易用性需求:功能的细节,产品中必须提供,便于功能操作使用的一些细节,例如:快捷键等;
    5)编辑约束:功能的细节,在功能执行时,对输入数据项目的一些约束条件,例如:只能输入数字等;
    6)参数需求:功能的细节,在功能执行时,需要根据参数设置不同,进行不同处理的细节;
    7)权限需求:功能的细节,在功能执行的过程,根据不同的权限进行不同的处理,不包括直接限制某个功能的权限;
    8)性能约束:功能的细节,执行功能时,必须满足的性能需求。

    2.场景分析

    1)考虑场景的调用者:考虑每一个场景提供的服务是供哪些外部模块或者系统调用的,找出所有调用者。调用前提,约束都要考虑。每一个调用都可以考虑成一个大的业务流程(一般和外部有交互的业务出错率比较大,需要重点关注);
    2)考虑系统内部各个场景之间的:形成内部业务流程,需要分析每个场景之间的约束关系,执行条件,组织出各种业务流程图。

    3.挖掘隐性需求(需要测试工程师的经验积累)

    1)常用的或者规定的业务流程
    2)各个业务流程分支的遍历
    3)明确规定不可使用的业务流程
    4)没有明确规定但是应该不可使用的业务流程
    5)其他异常或者不符合规定的操作

    以上是粗略的讲解了如何进行测试需求分析,在需求分析过程中通过参考需求规格说明书来编写整个测试计划,这个阶段一般情况下是测试主管编写的。包括测试人员,测试时间,测试工具,以及测试方法等。

    四、测试用例设计

    测试用例是测试工作的最核心的模块,在执行任何测试之前,首先必须完成测试用例的编写。测试用例是指导你执行测试,帮助证明软件功能或发现软件缺陷的一种说明。用例设计好后进行审核。这个地方该讲的东西就多了,如何设计测试用例,设计测试用的方法,怎么进行测试用例的审核等等。

    1.如何进行测试用例的设计

    编写测试用例之前我们需要对项目的需求有清晰的了解,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数,作为测试用例的编写者不仅了解要有常见的测试用例编写方法,同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。

    2.步骤:

    1)测试需求分析:

    从项目部拿到软件的需求规格说明书后,开始对项目的需求进行分析,通过自己的分析、理解,整理成为测试需求, 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系,即一个或多个测试用例集对应一个测试需求。

    2)业务流程分析:

    分析完需求后,明确每一个功能的业务处理流程,不同的功能点作业务的组合,以及项目的隐式需求。如遇复杂的测试用例设计前,先画出软件的业务流程。从业务流程上,应得到以下信息:
    ① 主流程是什么?
    ② 条件备选流程是什么?
    ③ 数据流向是什么?
    ④ 关键的判断条件是什么?

    3.测试用例设计

    完成以上两步则可进行测试用例设计,功能测试用例,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。
    设计测试用例的常见方法:
    1)等价类
    2)边界值
    3)因果图
    4)判定表
    5)状态迁移
    6)正交实验
    7)场景法
    8)错误推断
    注意:编写测试用例时,我们尽可能取的不应该是有效等价类而应该是无效等价类

    4.编写完成后自我检查以及部门内部评审:

    1)测试用例本身的描述是否清晰,语言准确;是否存在二义性;
    2)测试用例内容是否完整,是否清晰的包含输入和预期输出的结果;测试步骤是否清晰;
    3)测试用例中使用的测试数据是否恰当,准确;
    4)测试用例是否具有指导性,是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷,而不是限制他们的思维;
    5)是否考虑到测试用例执行的效率。对于不断重复执行的步骤,是否保证了验证点相同;或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下;
    6)画出软件需求跟踪矩阵,验证测试用例是否完全覆盖了需求,验证测试用例的覆盖性;
    7)测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系,应该视具体情况而定。

    注:具体详细内容可参考《如何有效的进行测试用例评审》

    5.测试用例更新完善

    测试用例编写完成之后需要不断完善,如遇需求更改或功能新增时,测试用例必须配套修改更新,同时在测试过程中发现设计测试用例时考虑不周,需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。
    五、测试用例执行过程
    首先搭建测试环境,准备好测试数据,进行预测,预测通过之后,按照测试用例进入正式测试,有效的测试执行可以将测试用例发挥最大的价值。因此,测试用例规范执行有助于更好的发现代码中存在的缺陷。

    根据个人测试工作经验,好的测试执行应该包含如下内容:

    1.测试执行中评估测试执行时间不足,需及时上报风险。满足质量优先,进度其次原则。
    2.测试用例按优先级顺序执行,通常是基本、详细和异常顺序执行。
    3.未执行用例、标志为删除或者无效的用例,需注明原因。
    4.执行过程中有疑问的测试用例(场景、操作步骤、检查点等)需找测试设计人员澄清。
    5.测试执行需对用例描述的检查点逐一检查,避免遗漏。
    6.重视不易重现的缺陷场景,可能是一个bug。
    7.执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。
    8.建议测试人员交叉执行重复测试用例,用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。
    9.如有需要,建议保留测试结果,结果可视。也便于不同版本间的测试结果对比。
    10.已确认问题需及时按照问题单提单要求(规范和缺陷定级)提单。
    11.跟踪问题单修复情况并回归验证问题单。
    12.测试结束,将最终测试用例文档上传到归档目录,实现用例重用。

    在测试用例执行过程中,包含了:功能测试阶段、缺陷跟踪阶段(bug tracking)、回归测试阶段、系统测试阶段、验收测试阶段等(系统已满足测试条件(开发完成),按照已经评审过的测试用例依次执行,执行过程中及时记录问题,将问题及时提交到禅道上,要跟踪缺陷。等开发修复后进行回归测试,确认修复后关闭缺陷。

    六、测试报告

    最后已达到准出要求的根据测试情况写测试报告,对整个测试过程和版本的质量做一个评估。
    测试报告是指把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力,一份详细的测试报告包含足够的信息,包括产品质量和测试过程的评价,测试报告基于测试中的数据采集以及对最终的测试结果分析。

    测试的内容可以总结为以下目录(根据实际情况进行具体调整):

    ① 首页
    ② 引言(目的、背景、缩略语、参考文献)
    ③ 测试概要(测试方法、范围、测试环境、工具)
    ④ 测试结果与缺陷分析(功能、性能)
    ⑤ 测试结论与建议(项目概况、测试时间 测试情况、结论性能汇总)
    ⑥ 附录(缺陷统计)

    至此并不算最后的完结工作,软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议 等。这样才算是软件测试最终结束,软件测试是贯穿于整个软件生命周期的。

    附录

    测试工作流程图解(网图)
    在这里插入图片描述
    注:所有的内容均整理自各路大神,帮助喜欢测试的朋友,谢谢!

    展开全文
  • 软件测试管理—如何写好软件测试计划

    万次阅读 多人点赞 2018-06-16 20:59:19
    如何写好软件测试计划书 软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。 详细的测试计划可以帮助测试项目之外的人...

    如何写好软件测试计划书

    软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。

    详细的测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。它非常有用但是测试项目组之外的人却很少去读它。

    什么样的测试计划书符合要求

    软件测试计划作为软件项目计划的子计划,在项目启动初期是必须规划的。在越来越多公司的软件开发中,软件质量日益受到重视,测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中,这样,如何规划整个项目周期的测试工作;如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为:“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排,以及任何偶发事件的风险。”软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

    案例:一份看似“不错的”软件测试计划书

    下面是某项的测试计划书

    一个软件测试计划书的目录

    提纲挈领,透过这份测试计划书的目录,如何对这份测试计划书进行评价?
    在回答这个问题之前,我们先看看测试过程中的一个重要的活动或者阶段——测试计划阶段都需要做什么?这个阶段的产出物是什么?

    测试计划阶段的任务

    测试计划可以在项目计划或主测试计划中文档化,也可以在不同的测试级别(如系统测试和验收测试)的测试计划中文档化。测试计划文档的大纲可以参考“软件测试文档标准”(IEEE Std 829-1998)。

    测试计划受到很多因素的影响:组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测试性和资源的可用性等。随着项目和测试计划的不断推进,将有更多的信息和具体细节包含在计划中。

    测试计划是个持续的活动,需要在整个生命周期过程和活动中进行。从测试中得到的反馈信息可以识别变化的风险,从而对计划作相应的调整。

    测试计划阶段需要做的事情

    对整个系统或部分系统可能的测试计划活动包括:

    • 确定测试的范围和风险,明确测试的目标;
    • 决定总体测试方法,包括测试级别、入口和出口准则的界定;
    • 把测试活动整合和协调到整个软件生命周期活动中去(采购、供应、开发和运维);
    • 决定测试什么?测试由什么角色来执行?如何进行测试?如何评估测试结果?
    • 为测试分析和设计活动安排时间进度;
    • 为测试实现、执行和评估安排时间进度;
    • 为已定义的不同测试活动分配资源;
    • 定义测试文档的数量、详细程度、结构和模板;
    • 为监控测试准备和执行、缺陷解决和风险问题选择度量项;

    明确了测试计划阶段需要完成工作,就很容易思考一份高质量的测试计划书中应该包括什么内容了。

    软件测试计划的文档化(产出物)——软件测试计划书

    下面是根据IEEE 829标准编写的一份测试计划的目录:

    这里写图片描述

    这份测试计划中:

    • 在第2部分明确了被测软件系统(产品)待测的特性和不测试的特性。
    • 在第3部分明确了测试目标
    • 在第4部分明确定义了准入/准出规则;通过和失败的标准;暂停标准和测试恢复需求

    这些内容都是很重要的内容。

    最后还描述了:

    • 测试提交产出物

    对比以上两份软件测试计划书的目录,可以看出第二份软件测试计划书的内容更加合理一些。

    如何写好软件测试计划书的内容?

    这个问题其实是“仁者见仁,智者见智”。不同的软件测试项目经理或者测试负责人、Test Leader等都有自己的看法。什么内容该写进去?写道什么程度?是否真的用心去写好每一个章节的内容?

    现实中,大多数软件测试项目经理或者测试负责人、Test Leader其实内心都是恐惧写文档的。很多时候不是不会写,而是不重视或者只是为了应付工作。原因其实很简单,无外乎有以下几种:

    • “文档无用论”,写文档还不如多用一些时间在解决项目问题上;
    • 写了软件测试计划其实也没有几个人看;
    • 文档其实不被重视;
    • 仅仅是为了应付公司品质部门、QAO的检查或者CMMI评估;
    • 在工作中测试管理的具体实践活动,依赖的是经验,而不是一份写在纸上的测试计划书;
    • 敏捷过程是“轻文档”化的;
    • 其它种种原因……

    软件测试计划真的仅仅只是一份文档吗?
    软件测试计划真的没有用吗?
    敏捷过程就真的不需要测试计划了吗?

    这些显然是一些借口或者错误的认识。

    为什么我们需要测试计划?

    无论做什么工作,都是计划先行,然后按照所制定的计划去执行、跟踪和控制。软件测试也一样,先要制定测试计划,是做好整个测试工作的前提。所以在进行实际测试之前,应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架,不断收集产品特性信息,对测试的不确定性(测试范围、测试风险等)进行分析,将不确定性的内容慢慢转化为确定性的内容,该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算,从而对测试策略、方法、人力、日程等做出决定或安排。

    在编写测试计划之前,可以考虑下面几个问题:

    • 为什么要编写测试计划?
      (1)Test Manager/测试主管等能够根据测试计划做宏观调控,进行相应资源配置等;
      (2)测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等;
      (3)便于其他人员了解测试人员的工作内容,进行有关配合工作
    • 什么时间开始编写测试计划?
      (测试需求分析前总体测试计划书/测试需求分析后详细测试计划书)
    • 由谁来编写测试计划?
      具有丰富经验的测试负责人Test Leader
    • 测试计划编写的基本思路(5W1H)
      (1)why——为什么要进行这些测试;
      (2)what—测试哪些方面,不同阶段的工作内容;
      (3)when—测试不同阶段的起止时间;
      (4)where—相应文档,缺陷的存放位置,测试环境等;
      (5)who—项目有关人员组成,安排哪些测试人员进行测试
      (6)how—如何去做,使用哪些测试工具以及测试方法进行测试。

    测试计划的要点

    测试规划与软件开发活动同步进行,在需求分析时,就开始测试策划,确定测试需求、目标、资源等。测试计划可以按不同的测试阶段(集成测试、系统测试等)来组织,也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

    测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等,其关键是制定有效的测试策略,界定清楚地测试范围,识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法,针对不同的测试目标或阶段确定测试方法,对测试工作量及所需的资源、时间进行合理的估算。所有这些,都是为了两个根本目的:测试的质量和效率。

    测试计划中需要明确测试范围

    测试主要依据“产品设计规格说明书”、代码所发生的变化及其影响的区域,来确定哪些功能和特性要测试,哪些功能和特性不需要测试。在确定测试范围时,主要考虑的因素有:

    • 优先级最高的需求功能
    • 新增加的功能和编码改动较大的已有功能
    • 容易出现问题的部分功能
    • 过去测试不够充分的地方
    • 经常被用户使用的功能和配置(占20%)
    • 哪些不需要测试的功能和特性(排除出测试范围)

    在实际的测试实施中,有时候存在测试执行到一定阶段,由于某种原因(例如:环境不具备、测试账号的问题、测试数据的问题、公司安全策略的限制等等导致测试条件不满足,从而一些之前计划在测试范围内的功能,需要排除出测试范围)测试范围需要发生变更。那么这就需要遵守变更流程,并且更新测试计划文档,以及更新后的测试计划获得审批。

    这个环节其实常常被Test Leader和Test Manager或忽视。

    我遇到过很多类似的情况,没有遵守变更流程,并且更新测试计划获得审批,这最终导致的结果是测试功能混乱;经历2-3个版本迭代之后,被测需求难以追溯。一旦存在产品发布之后出现功能上的问题,用户抱怨不断。其实这就反映出测试计划不合理而导致的问题。

    测试估算:所需资源和日程安排

    为了合理、准确地安排日程,对测试工作量要进行正确的估计。除了对工作量的估计之外,还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式,要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难,但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理,并适当增加10%-20%的余量,估算结果就比较准确了。
      
    在估算的基础上,进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的,所以人力资源的计划要有一定的灵活性和动态性,形成有机的动态平衡,保证测试的进度和资源的使用的效率。

    需要精心编写准备测试计划

    要做好测试计划,测试设计人员要仔细阅读有关资料,包括用户需求规格说明书、设计文档等,全面熟悉系统,并建议注意以下方面:

    • 让所有合适的相关人员参与测试项目的计划制定,特别是在测试计划早期;
    • 测试所需的时间、人力及其它资源的预估,尽量做到客观、准确、留有余地;
    • 测试项目的输入、输出和质量标准,应与各方达成一致;

    测试计划的主要内容

    测试计划的主要内容包括以下要点:

    1. 测试计划标识
    2. 版本修订记录
    3. 简介(目的)
    4. 主要阅读者
    5. 测试项(交付测试的一切内容)
    6. 需要测试的功能
    7. 不需要测试的功能
    8. 测试项通过/失败的准则
    9. 测试准则(入口准则、出口准则、暂停和恢复准则)
    10. 测试交付物/产出物
    11. 测试任务
    12. 进度计划(可以与10.测试任务合并做出一个进度和任务的矩阵,关键里程碑点的描述)
    13. 环境需求
    14. 工具
    15. 职责矩阵
    16. 人员和培训的需求
    17. 风险和缓解风险/预防风险的对策
    18. 批准(测试计划需要进行评审和审批)

    有一些时候对上述内容可以进行裁剪。还有一些测试团队/组织会将测试计划与测试策略合并成为一个文档。
    我在测试管理中,允许一些小的测试项目或者临时性的测试项目将测试计划(Test Plan)和测试策略(Test Strategy)进行合并。事实上,很多Test Leader,Test Manager是不愿意花费太多的精力去写文档、维护文档的。即便如此,2-3页纸的测试计划还是需要的。此时,测试策略(Test Strategy)就尤为重要了。

    测试计划需要评审

    测试计划不可能一气呵成,而是要经过计划初期、起草、讨论、审查等不同阶段,才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节,包括测试组织内部的自我评审、讨论和修改,然后交到评审会进行正式的评审,直至测试计划得到审批。

    测试计划的正式评审,项目中的每个人(产品经理、项目经理、开发工程师等)都应当参与。计划的审查是必不可少的,每一个参与者都可能根据其经验及专长提出问题或建议,弥补在测试范围、工作量、风险等各方面的不足,进一步完善测试计划。

    (更新完)

    展开全文
  • 软件测试计划的主要内容

    千次阅读 2021-04-02 10:13:12
    是对整个信息系统应用软件组装测试和确认测试。 它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。 测试计划可以有效预防计划的风险,保障计划的顺利实施。 测试计划的目的 (1)为测试各项活动...
  • 软件测试计划

    千次阅读 2019-10-01 23:26:37
    测试软件中的各个功能模块是否满足用户要求,并测试是否存bug。预期达到能够使系统进行快速的改进和系统的提高。为了在软件投入生产性运行之前,尽可能多地发现软件的错误。 1.2. 背景 a. 为方便学习和工作比较...
  • 软件测试工作基本流程

    千次阅读 多人点赞 2019-06-24 19:54:13
    最近在为面试新工作做准备,所以想想整理一下软件测试的基本工作流程,大致梳理一遍,这样也便于自己在面试过程中可以沉着的面对面试官的测试工作如何进行的问题。 首先,作为测试人员需要学习并了解业务,分析需求...
  • 软件测试工作总结(一)

    千次阅读 2018-11-04 22:01:11
    1、为什么要在一个团队中开展软件测试工作?  因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试工作。在测试的...
  • 软件测试工程师工作总结

    万次阅读 多人点赞 2018-04-18 21:02:05
    1、为什么要在一个团队中开展软件测试工作? 因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试工作。在测试的过程...
  • 测试开发之测试计划

    千次阅读 2021-07-25 05:58:09
    一、 测试计划的定义与原则1 ... 软件测试计划是指导测试过程的纲领性文档。计划可以统一认识,可以规划过程。 测试计划包含了产品概述、测试区域/测试范围(测试项)、 测试目标(被测特征)、测试优先级、测试配...
  • 软件测试之测试计划与工具(一)

    万次阅读 2019-08-04 19:15:27
    一丶测试计划与工具的学习导图 二丶QC介绍 三丶QC的安装 四丶QC的使用 一丶测试计划与工具的学习导图 二丶QC介绍 1.Quality Center是一个基于Web的测试BUG管理工具 Quality Center是一个基于Web的测试管理...
  • 软件测试计划模板

    万次阅读 多人点赞 2019-04-01 16:30:20
    软件测试计划 一.概述 1.1编写目的 此计划编写的目的是为使物业管理系统v1.0版能够达到与系统说明书所描述的功能一致,并且检验系统是否运行稳定。 1.2参考资料 A.《物业管理系统需求分析说明书》 B.《物业...
  • 软件测试管理

    千次阅读 2020-04-01 17:12:52
     软件测试过程管理主要集中在软件测试项目启动、测试计划制定、测试用例设计、测试执行、测试结果审查和分析,以及如何开发或使用测试过程管理工具。 (一)测试的组织  实施一个测试的首要步骤之一就是考虑测试...
  • 一份标准的软件测试计划文档 | 新手可以拿走

    万次阅读 多人点赞 2018-06-26 16:09:23
    简介1.1目的项目名称>的这一“测试计划”文档有助于实现以下目标:[确定现有项目的信息和应测试软件构件。列出推荐的测试需求(高级需求)。推荐可采用的测试策略,并对这些策略加以说明。确定所需的资源,并对...
  • 软件测试大纲

    千次阅读 2020-11-28 16:39:51
    软件包含哪些内容 数据 程序 文档 ...计划 需求分析 设计 编码 测试 运行-维护 螺旋模型 螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。 ...
  • 2021年软件测试面试题大全

    万次阅读 多人点赞 2020-11-30 15:16:59
    3、根据最终确定的需求文档编写测试计划。 4、编写测试用例(等价类划分法、边界值分析法等)。 5、用例评审(主要参与人员:开发、测试、产品、测试leader)。 6、开发提交代码至SVN或者GIT ,配管搭建测试环境。...
  • 软件测试工程师工作经验分享

    千次阅读 2019-03-11 10:28:23
    1989年,我在田纳西大学读研究生的时候,完成了从软件开发人员到软件测试人员的转型。而这一转型并非出于我自己的选择。我命运的改变发生在一个早晨,我的教授质问我为什么缺席那么多开发会议。我解释说因为会议被...
  • 软件测试工作流程总结

    万次阅读 多人点赞 2018-07-10 16:13:06
    Q:软件测试工作过程有哪几步?答:需求、计划、方案、用例、执行、总结。1、测试需求测试需求分析:分析识别测试范围,解决测什么的问题,方便测试的跟踪和管理。测试需求分析的流程:需求采集—>需求分析...
  • 软件测试工作流程概括与总结

    万次阅读 多人点赞 2018-08-08 23:37:45
    最近在为面试新工作做准备,所以想想整理一下软件测试的基本工作流程,大致梳理一遍,这样也便于自己在面试过程中可以沉着的面对面试管的测试工作如何进行的问题。 首先,作为测试人员需要学习并了解业务,分析需求...
  • 软件测试面试题(含答案)

    万次阅读 多人点赞 2021-03-01 15:15:38
    软件测试面试题(含答案)
  • 大概介绍一下个人情况,女,本科,三年多测试工作经验,懂python,会写脚本,会selenium,会性能,然而到今天都没有收到一份offer!从年后就开始准备简历,年后上班的第一天就开始投,开始只是投了一些官网已久的...
  • 软件测试基础知识 + 面试理论(超详细)

    万次阅读 多人点赞 2021-02-25 10:47:13
    三、软件测试工程师的工作内容四、常见的软件生命周期模型五、软件开发的几个阶段六、软件bug的五个要素七、软件测试的分类八、什么是测试用例九、测试用例几大要素【面试理论知识】1、你的测试职业发展是什么?...
  • 一、软件测试的基本概念 1.测试是软件生存周期中十分重要的一个过程,是产品发布、提交给最终用户前的稳定化阶段。 2.软件测试是为了发现错误而执行程序的过程。或者说,软件测试是根据软件开发各阶段的规格说明和...
  • 软件测试学习总结

    千次阅读 2022-04-15 15:01:18
    1.软件测试基本概念 1.1定义
  • 问:软件测试的原则? 答:https://blog.csdn.net/weixin_30363263/article/details/102986878 问:你在测试中发现了一个 bug ,但是开发经理认为这不是一个 bug ,你应该怎样解决。 1、将问题提交到缺陷...
  • 软件测试——集成测试篇

    千次阅读 2021-11-30 19:06:18
    集成测试是软件测试的一个级别,其中将各个单元组合并进行测试,以验证它们在集成时是否按预期工作。这里的主要目的是测试模块之间的接口。 由于多种原因,仅单元测试是不够的,例如: 模块/单元通常由单独的软件...
  • 软件工程导论—软件测试

    万次阅读 多人点赞 2020-05-13 21:26:49
    1. 软件测试基础 2. 单元测试 3. 集成测试 4. 确认测试 5. 白盒测试技术 6. 黑盒测试技术 7. 调试 8. 软件可靠性
  • 软件测试——工作业务流程

    千次阅读 2020-04-25 11:14:29
    软件测试工作流程 一、作为测试人员需要学习并了解业务,分析需求点 为什么测试人员需要参加需求分析?也就是进行测试需求分析的目的是什么? 把用户需求转化为功能需求:1)对测试范围进行度量 2)对处理分支...
  • 一、软件测试的定义 软件测试的经典定义是在规定条件下对程序进行操作,以发现错误,对软件质量进行评估。因为软件是由文档、数据以及程序组成的,所以软件测试的对象也就不仅仅是程序本身,而是包括软件形成过程的...
  • 关于银行项目的软件测试At some point during his or her career, a programmer might come across the following argument, presented by some colleague, partner, or decision maker:在他或她的职业生涯中的某个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 106,677
精华内容 42,670
热门标签
关键字:

软件测试组工作计划