大型项目的大致软件测试
本帖最后由 shyoldboy 于 2021-10-21 23:42 编辑#### 软件测试流程
###### 1、需求澄清
相关概念：
① 需求：来源于客户 ，由BA/产品经理整理归纳，描述系统应该做什么的文档。
② 原始需求： 客户提出的需求
③ 需求澄清：由BA/产品经理组织开发，测试。诵读需求，进行需求对齐工作，为保证个人员需求理解一致，由开发、测试人员进行反串讲
④ 需求变更CR： 由客户提出，客户需求总是在变化的，一般会有公司会进行CCB（需求变更仲裁会议）。由（项目经理，开发人员，测试人员，产品经理）决定是否变更。
###### 2、测试计划（求大佬补一下测试计划模板）
测试计划包含的内容： 时间，地点，人员分工，测试方法，测试风险，退出机制。
退出机制： 1、软件测试用例覆盖率达到100%
2、软件用例执行度达到100%
3、软件缺陷遗留率2-5%
4、缺陷遗留率已得到合理的解决方案
###### 3、测试设计（上一步是用思维导图整理出业务线，画出功能点）
测试设计要素包含：模块，子模块，测试场景，测试点，编写人
编写用例 : 对软件预期执行结果托编写的标准文档
用例要素：用例编号，用例标题，执行步骤，用例优先级，前提条件，期望结果
用例优先级判定：
p0级 ： 核心功能测试用例（冒烟测试），确定此版本是否可测的测试用例，此部分用例如果失败会阻碍大部分其他测试用例的验证
p1级 ： 高优先级的测试用例，最常执行以保证功能性是稳定的，基本的功能测试，和主要的错误，边界测试。
p2级 : 中优先级的测试用例，更全面的验证功能的各个方面，异常测试，边界，中断，断网，容错，UI等测试用例
p3级 ：低优先级的测试用例，不常常被执行，性能，压力，兼容性，稳定性，安全，可用性等等
此处提高用例覆盖度的方法：
1、仔细阅读需求，对需求彻底理解
2、设计测试用例时使用各种测试用例设计方法
3、评审用例 （项目评审，小组评审）
###### 4、搭建测试环境
###### 5、执行用例
注意： 1、没有经过评审的用例不能执行
2、经过评审的用例必须执行
3、缺陷遗留率，2-5%之间
4、所有遗留问题已得到合理的解决方案
###### 6、提交缺陷
什么是缺陷？
不满足/超越客户需求，软件中存在的错误，缺失的异常处理。
缺陷要素？
缺陷编号，缺陷标题，重现步骤，缺陷优先级，缺陷等级，期望结果，实际结果，附件。
缺陷严重程度
致命：引起系统崩溃或者重要模块的整体功能无法使用。
严重：整个功能模块无法使用，或重要模块流程无法跑通
一般：软件中一个功能点没实现
轻微： 一般是界面显示问题
缺陷回归测试：然后进行一个轮回，直到测试通过
遗留问题：
你们公司在缺陷回归的时候是不是全部要进行回归？
待完善。。。。。。（求大佬补一下）
###### 7、测试报告
包含测试内容，测试方法，测试结果，测试结论，缺陷，缺陷分布，缺陷处理方案
如下是测试报告涵盖的内容和章节!
上面先是初版，后面在工作中慢慢优化。有大佬能给小弟指导一二，小弟感激不尽 我以前也做个大型项目软件测试，看你写的测试列表这么规范，真的是浪费时间，1、需求2、测试计划 3、测试设计 4、搭建测试环境 5、执行用例 6、提交缺陷（bug） 7、测试报告 弄这么繁琐没有几年沉浸都无法整完整个项目。几年后你们整完都过时代了。 有一说一，这么规范大多都是用在面试上 我们是做的游戏测试，流程大致相同，关于回归是全部要测一遍的，还要跑一遍冒烟。 补一句，确实像楼上说的一样，规范归规范，测多了就不会按照规范来跑了。
规范写的是挺规范的，但是在项目工期比较赶然后测试的东西多了之后很多人就不会按照标准规范来跑了 一边写一边测。。 回归肯定是所有用例都再执行一遍，，不过用例用不着那么多，测的时候测细一点就得，面试时能那么详细时再好不过了 本帖最后由 精神科王医生 于 2021-10-22 10:25 编辑
整个行业都在向敏捷靠拢，强调沟通，强调随机应变。
严苛的流程走下来会大大拉长工作周期 这个需要衡量一下
文档内还需要补充项目缺陷管理系统的使用规范
这个在实际工作中的意义会更大一些 打包一下 发出来吧 给热心.
页:
[1]
2