软件测试的流程是什么？
回答·122
最热
最新
- 需求评审 测试用例编写 测试用例评审 开发自测 冒烟测试 功能测试(包含兼容性测试) 性能测试 上线回归测试 测试用例持续集成，自动化测试(有条件可选)
- 1、需求评审（看看哪些功能需要作废）； 2、测试计划（看看需要哪些测试人员加班并编写测试计划）； 3、测试策略和要点（思维导图梳理测试策略和测试要点）； 4、测试用例（拿着测试要点对着写就行了）； 5、用例评审（看看测试用例到位不到位）； 6、测试实施（执行测试用例并记录缺陷日志）； 7、提交缺陷（提醒程序员加班）； 8、回归测试（看看缺陷解决情况）； 9、根据项目实际情况与产品经理项目经理老板看看是否再次深入修复缺陷； 10、测试报告（形成测试报告）； 11、测试总结（看看自己有哪些环节没有做好的，反思改进）
- 需求分析 测试计划 测试方案 编写测试用例 评审测试用例 环境搭建 等待开发包 冒烟测试 执行测试 缺陷提交 回归测试 测试报告
- 我讲讲所在的项目组的流程吧 1、添加新功能必定会需求评审(一般是产品、开发、测试一起) 2、项目排期 3、编写测试用例 4、需求评审(不一定，除非是重要功能) 5、开发自测(测试上传p1级别用例，开发自测通过才能提测) 6、搭建测试环境 7、介入测试 8、提交bug 9、二轮测试(一轮bug修复的情况下，进行二轮测试) 10、验证通过，更新测试状态 11、ui产品验收 12、产品申请上线 13、预发布测试(只过p1、p2级别用例了) 14、预发布没问题产品确认通过，进行上线 15、上线回测(只过p1) 16、用例归档(用做全功能回测用) 17、编写测试报告
- 软件测试的基本过程共有几个步骤？ 1，第一步要做的是需求分析，根据测评中心收到项目的需求规格说明书和原型图来做需求分析。 1）先将需求规格说明书阅读一遍，熟悉项目的基本需求，对项目有个大概的框架思路； 2）时间充足的情况下，可以利用画流程图的方法来理清需求和自己的思路； 3）对照需求规格说明书将原型图仔细翻看一遍，对每个字段的来源去向有个思考，页面之间的跳转考虑清楚； 4）在以上几个步骤的过程中，整理出需要注重的点，以及不能理解的问题，利用和同事之间讨论或是和项目经理确认，解决掉问题。 2，编写测试用例， 编写测试用例可以进一步理清自己的思路，以及项目的细节，锻炼自己的测试思维，使测试的时候对需求更加清楚； 测试用例编写完成，需提交对应的项目日志。 3，测试开展 功能测试第一轮，首先关注主流程能够走通，没有阻碍流程的问题存在，出现这类问题，及时和开发人员交流，解决问题； 功能测试第二轮，关注各个端口的单独功能可以完全实现，没有阻碍，所有功能点均能实现； 系统测试第一轮，各个端口综合在一起，各个端口的交互可以正常实现，并关注界面和用户体验的问题； 兼容性测试，包括 app 和网页，app 兼容测试根据测评中心设备测试，适应主流设备；网页需要兼容主流浏览器，如谷歌，火狐，IE，360 等； 每一轮功能测试结束，及时提交对应的项目日志，对测试情况进行总结； 及时的进行 bug 复查，需复查项目管理系统上所有已解决和反馈给测评中心人员的反馈的 bug。 4，编写测试报告 项目的测试过程结束后，要及时的编写测试报告，把测试的情况、过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。
- 1、立项，需求评审，分配需求熟悉需求。 2、需求分析，根据功能点设计用例，发送评审。 3、执行冒烟测试和ST系统测试用例。 4、发现bug，提交开发修复，跟踪定位问题，协助解决问题。 5、进入回归测试阶段，主要业务流程。 6、自动化测试需求分析脚本或性能测试需求脚本执行 7、交由用户验收测试。 8、提交测试报告，分析结果，编写用户操作手册。
- 1：需求分析 2：编制测试计划 3：编写测试用例 4：评审→（通过，搭建测试环境）→（不通过，继续编写测试用例） 5：进行冒烟测试 6：执行测试用例 7：缺陷跟踪（验证 BUG 有效性，开发修改 bug 后回归测试） 8：修复后进行上线 9：上线后进行测试总结
- 测试流程大部分都差不多，我所在的项目直接需求分析评审放一起，确定该需求可以上的有哪些，有哪些需要再优化或者来不及人力做，分优先级上，然后测试计划和测试用例，使用那种测试方式，测试要点划分，测试人员配置，测试环境搭建，案例编写和案例评审，评审主要是看测试能否覆盖所要上线版本的能力，场景是否遗漏等，确认需求的不明确然后可以在评审后更改案例。然后执行测试，一般情况下开发提交测试日期比计划日期稍微晚，所以留给测试的时间会被压缩，冒烟测试看下总体的功能实现和 UI 界面实现，发现缺陷，保留现场提交 bug，跟踪缺陷的状态，系统测试结束需要 uat 产品经理看下那些不符合需求，然后留一天时间进行回归测试，基本没问题就等待发版本。后面生产反馈问题需要深刻反省缺陷的遗漏原因，为什么会遗漏到生产，就是我们的测试总结。整个项目大致测试流程如此
- 需求评审——测试计划——测试策略——测试要点——测试用例——用例评审——测试执行——缺陷提交——缺陷回归——测试报告——测试总结
- 软件测试一般流程 需求分析 测试计划编写 用例编写 用例执行 问题回归 测试报告输出 但是很多公司内部测试人员没有时间精力去分析需求，编写测试计划，或者接触根本不到需求，开发出好版本就上手测试。这是典型的顾此失彼，需求分析和测试计划决定了测试工作的质量，而测试用例编写决定了测试产品最终使用质量。 测试计划中应该设计到用到哪些测试种类，单元测试，模块测试，系统测试，集成测试，稳定性测试，性能测试，健壮性测试等等，合理的分析何时需要何种测试种类，比如说在进行了底层修改的代码合入后，这个时间节点上应当及时的进行基本功能测试，保证后续修改有一个基准质量。如果后续才发现有基本功能问题，要不然，这个需求看掉，要不然，项目延期。因为此时修改底层可能会牵一发而动全身。这时候的时间成本被无限放大。 很多测试人员在刚开始觉得测试计划没有什么实质性意义，纯属浪费时间，但是，测试工作旧了发现，有一个良好的测试计划就能事半功倍，更何谈优秀的测试计划，想写出优秀的测试计划可是一门大学问，需要考虑的东西很多，是一个经验技能。其实，这个很多测试人员也包括我自己。 需求分析和测试计划编写在比重上要等于测试用例的编写，优秀的测试计划可以指导后续测试工作的稳步进行，也可以尽可能保证在交付时限前进行交付。测试工作应该从需求出发，一切建立在用户的使用角度上进行，因为最终交付是给客户而不是测试经理，开发经理，产品经理等等。 测试的软件千万种，很难找到一个绝对标准，不同的产品还可能包含着不同的测试需求。比如说手机应用主要考虑耗电量，web应用测试需要考虑浏览器兼容性等等，针对不同的应用或者产品指定合理的测试流程，也是一个不断摸索的过程。 还在加班中，看到这个，想起这三年的测试工作突然有感，希望能对你有帮助，测试其实一点不无脑，只有动脑才能做好测试工作，软件测试，下线高，上线也高。与君共勉