软件测试工作流程总结分享

软件测试一直是图零直播的重点课程，近几年通过图零直播学习软件测试的新学员特别多。今天就软件测试的基本工作过程为大家整理一些简单的介绍，通过相关资料的学习，大家可以了解软件测试基本的工作方式，更方便日后的学习工作。

　　Q：什么是软件测试？

　　答：特定的环境、特定的条件下运行软件，验证其能正常运行，并发现其缺陷，对软件的质量进行评估的过程。

　　Q：软件测试的工作过程有哪几步？

　　答：需求、计划、方案、用例、执行、总结。

　　1、测试需求

　　测试需求分析：分析识别测试范围，解决测什么的问题，方便测试的跟踪和管理。

　　测试需求分析的流程：需求采集—>需求分析—>需求评审。

　　测试需求分析的评审：完整性、准确性、一致性、易理解性、无歧义性。

　　测试需求分析的时间：开发需求完成后。

　　参考依据：

　　（1）狭义依据：需求规格；

　　（2）广义依据：参照上面的测试需求分析来源。

　　Q：在测试需求不明确的情况下，如何保证测试质量？

　　（1）多方收集需求；

　　（2）多与开发人员沟通；

　　（3）若有以前的系统，参照以前的系统；

　　（4）找类似的产品熟悉；

　　（5）到网上查找与系统相关的业务知识、专业术语。

　　测试需求分析的来源：

　　（1）开发文档：需求规格、概设、详设、数据库结构设计文档、模块功能图等；

　　（2）用户需求：与用户或需求分析人员沟通，需求调研的会议纪要，与用户邮件往来；

　　（3）软件雏形：可运行软件，软件的框架；

　　（4）相关的规划及标准：各行各业的标准、国家标准、行业标准、企业标准、项目标准、国家法律法规；

　　（5）类似的产品：公司内部相同的旧版本产品，行业其他公司类似的产品；

　　（6）测试知识经验库：测试人员的业务背景、系统业务知识的积累、个人的测试经验积累；

　　（7）其他隐性的需求：产品利益相关者的建议、会议纪要、备忘录、沟通记录、邮件往来等。

　　测试需求分析的内容：

　　（1）业务流程图的分析；

　　（2）用户和角色的分析；

　　（3）数据库结构的分析；

　　（4）测试要点的分析。

　　测试需求分析的方法：

　　（1）测试功能点分析法；

　　（2）功能交互分析法；

　　（3）质量特性分析法；

　　（4）测试类型分析法。

　　2、测试计划

　　测试计划：管理层文档，对测试过程、测试活动起到指导的作用，解决做什么的问题，5W。

　　测试计划编写时间：测试需求完成之后。

　　评审人：项目经理、QA、开发、产品、设计人员。

　　输出文档：总的测试计划文档。

　　测试计划的内容：

　　（1）项目背景，缩略语（专业术语）；

　　（2）测试的参考文档、测试的交付文档；

　　（3）测试目标、测试范围、测试环境、测试工具、测试策略、测试风险；

　　（4）人力资源的分配、工作量的估算；

　　（5）测试时间、进度安排、任务分配、培训计划等；

　　（6）出入口准则（准入准出标准）等。

　　测试风险：质量、时间进度、成本、变更、人员变动等；

　　QA与QC的区别：QA为质量保证、QC为质量控制。

　　冒烟测试：在测试之前，对软件进行可测性检查，保证基本功能，基本流程可通，提高工作效率。

　　回归测试：包括完全回归和部分回归（根据操作频率和风险选择）。

　　集成策略： 

　　（1）非增量式集成：大爆炸式集成；

　　（2）增量式集成：自顶向下、自底向上、三明治。

　　测试准入条件：

　　（1）测试用例编写，测试评审完成；

　　（2）开发人员完成编码，并完成自测；

　　（3）冒烟测试通过；

　　（4）开发组提交了测试申请单；

　　测试准出条件：

　　（1）时间标准：项目时间用尽；

　　（2）缺陷修复：致命/严重缺陷比率为0%，一般<5%，轻微<10%;

　　（3）测试用例执行覆盖率为100%；

　　（4）测试用例对需求覆盖率>95%;

　　（5）缺陷修复率达到一定的标准；

　　（6）收益比：存在bug，但是修复需要花费的时间大于受益，测试停止；

　　（7）完成软件测试验收报告，并且报告结果达到认可。

　　3、测试方案

　　测试方案：技术层面文档，主要对被测软件测试特性、方法、环境等进行规范，解决怎么做的问题。

　　测试方案的编写时间：测试计划完成之后。

　　参考依据：测试计划、测试需求分析、测试规格、概设、详设。

　　评审人员：测试人员、开发人员、项目经理、QA。

　　测试内容：

　　（1）项目背景、测试目标、测试范围、测试环境、测试策略、测试工具；

　　（2）测试特性的分析；

　　（3）测试特性方法的分析；

　　以最少的用例更全面的覆盖需求，测试不能发现潜在的缺陷；

　　缺陷的级别：致命、严重、一般（不超过15%）、轻微（不超过20%）、建议。

　　缺陷处理状态迁移图：新建—打开—已修正—已关闭—拒绝—延迟—重新打开。

　　缺陷优先级的考虑方面：

　　（1）缺陷本身的严重级别；

　　（2）功能的重要性方面；

　　（3）功能发布的时间进度；

　　（4）功能的可见性方面；

　　（5）从操作频率方面；

　　（6）从安全性方面。

　　4、测试用例

　　参考依据：参考方案、需求分析的结果、需求规格。

　　评审人：测试工程师、QA、开发人员、测试经理。

　　输出文档：测试用例文档。

　　Q：用例设计需考虑的方面有哪些（以最少的用例更全面的覆盖需求，以此发现更多的缺陷）？

　　（1）编写所有必填项（一个用例）；

　　（2）编写所有项包括必填和非必填（一个用例）；

　　（3）一个完整的流程一次性走完（一个用例）；

　　（4）编写预期结果：包括前台、后台、数据库等方面；

　　（5）新增和修改的链接为同一界面（代码一致为前提）：在修改中只需测试进入界面的默认情况，其余字段只需在新增上测试，修改所有字段点击保存、重置，修改后直接返回需要提示；

　　（6）删除：子信息有调用情况（全删、不能删除），例：品牌和商品，删除品牌时则提示，物理删除：可到数据库中回滚，数据库不存在；标志删除：到回收站用来做历史记录，后台可看，前台不可；

　　（7）登陆：账号长度限制，正确登陆，不正确登陆；

　　（8）业务流程图：场景法、基本流和备选流，串行用乘，并行用加；例：银行取款流程图；

　　（9）查询：精确查询和模糊查询，like“%x%”；多条件搜索可用正交法、再补充。

　　测试用例过程：

　　（1）输入—动作—输出；

　　（2）输入—测试环境—测试目的—执行条件—动作—输出；

　　（3）为了达到某种特定目标而设计的一组测试输入、执行条件和预期结果，其目的是为了检测某个程序或何时是否满足某个特定的需求。

　　测试用例的作用：便于软件质量的度量，方便测试任务的跟踪管理，方便缺陷的提交。

　　如何衡量测试用例的好坏：清晰、准确、完整、简洁、一致。

　　黑盒测试用例设计方法：包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等。

　　白盒测试用例设计方法：语句覆盖率、条件覆盖率、判定覆盖率、条件判定覆盖率、组合覆盖率、路径覆盖率。

　　关于因果图法：

　　（1）因果图关系：（输入与输出）恒等、非~、与^、或V；

　　（2）输入约束：异E最多只能一个为1、或I最少有一个为1、唯一O有且只有一个唯一；要求R两个取值一样如C1为1C2也为1；

　　（3）输出约束：强制M两个输出互异。

　　#对于搜索框的测试用例设计#

　　（1）单个条件；

　　（2）所有条件；

　　（3）任意几个条件组合：应用正交实验法再补充情况；

　　（4）不符合条件查询；

　　（5）条件中有相互冲突的条件，需单独测试；

　　（6）输入合理的查询条件后，点击返回需有提示。

　　5、测试执行

　　参考依据：测试用例（需求）。

　　输出：缺陷报告。

　　测试执行注意事项：

　　（1）注意用例执行的先后顺序：数据流向、优先级、时间进度安排；

　　（2）执行的前置条件、测试环境、备注里的特殊说明；

　　（3）发现问题/缺陷时，应立即保留证据，再重现缺陷；

　　（4）缺陷至少重现3次，并初步定位到问题；

　　（5）测试过程中，根据实际情况维护测试用例。

　　测试用例的执行结果：

　　（1）未测试：Not test；

　　（2）通过：pass；

　　（3）失败：failed；

　　（4）阻塞：black；因为其它的问题导致用例无法执行；

　　（5）观察：investigates。

　　Q：什么时候需要维护测试用例？

　　（1）需求、编码、设计发生了变更；

　　（2）执行过程中发现用例描述有错误；

　　（3）发现的缺陷不能对应用例，需补充用例；

　　（4）发现重复、冗余的用例需删除；

　　Q：什么是缺陷（遗漏、错误、额外实现）？

　　（1）需求规格说明书中明确要求实现的未实现；

　　（2）需求规格说明书中虽未明确规定，但实际需要实现的缺陷；

　　（3）未正确实现（错误实现）；

　　（4）实现了需求规格中明确不需要的功能（额外实现）或实际不需要的功能；

　　（5）性能、易用性等方面，站在用户的角度，会认为不够完美的。

　　bug的内容：bug描述、重现步骤、实际结果、预期结果。

　　缺陷的生命周期：

　　提交->确认->分配->修复->验证->关闭

　　缺陷的内容：

　　        缺陷编号、模块、项目名、版本、缺陷标题、缺陷级别、优先级、缺陷类型、测试环境、缺陷描述（bug描述、重现步骤、实际结果、预期结果、修改建议）、状态、缺陷引入原因、缺陷引入条件、发现人、发现时间、修改人、修改时间、关闭人、关闭时间、附件、对应的用例编号。

　　Q：对于偶然发现，并难以重现的缺陷如何处理？

　　（1）先保留证据（抓包、截图、视频等）；

　　（2）本机重现问题，无法重现则换电脑重现；

　　（3）若重现，则根据缺陷的实际影响情况定义缺陷的严重级别；若无法重现，则找开发人员协助重现；在开发人员的协助下仍未能重现，则需要对此问题边重现边录视频（最多两小时），若2小时内重现则从发现问题的前半小时开始分析，若2小时内未重现，则需直接提交缺陷，降低缺陷的级别，将缺陷改成延迟状态，该缺陷至少历经半年或者在用户现场历经多个版本后关闭。

　　6、测试报告

　　定义：对于测试过程、产品质量进行评估，并对测试结果进行总结、下结论。

　　依据：测试用例的执行情况，缺陷数据的统计结果。

　　评审人：整个项目人员。

　　测试报告评估人：测试经理、测试人员。

　　测试报告的内容：

　　        项目背景、测试目标、测试范围、测试环境、测试策略、测试工具、测试人力资源、测试时间、测试用例数据统计、缺陷数据统计、遗留问题、测试风险、测试过程开发、产品质量评估、测试结论、经验教训与建议、附录。

　　Q：编写测试报告的目的是什么？

　　（1）用于项目经理决策提供依据；

　　（2）用于下一个项目维护提供方便；

　　（3）对测试进行评估。

今日福利

【Java11期开课啦】

8大实战案例模块，历时三年沉淀，Java4.0震撼发布！

偷偷告诉你前50名，还可获得价值300元的京东购物卡呦~

如有疑问，请留言告知，或者咨询柠檬班软件测试培训机构：www.ceshiren.com官网客服哦