测试流程
2024-10-31 14:40:59 0 举报AI智能生成
测试流程是确保软件、硬件或系统质量的关键步骤。首先，进行需求分析以明确测试目标。然后，设计测试方案，包括测试用例和测试数据。接着，执行测试并记录测试结果。如果发现缺陷，需要报告并修复。最后，评估测试覆盖率和测试质量，生成测试报告。在整个测试过程中，可能需要对测试进行迭代和更新，以确保产品满足客户需求。
作者其他创作
大纲/内容
执行活动
需求评审（静态测试范畴）
开发：取源码，构建
可发布的版本
通知相关的测试人员取版本
部署在测试环境
版本发布（发包）
1：开发负责人，构建，可能通过QQ、邮件直接发给测试人员
2：CMO配置管理员构建发布：SVN（配置管理工具）：开发人员把代码上传到SVN，CMO取代码，编译，构建，然后通知相关测试人员到SVN的某个路径下取版本
3：测试负责人来构建
4：工具构建：持续集成、每日构建，开发把代码传到CI工具，工具会自动取代码，编译，检错，会形成版本。以发送消息给开发与测试团队
发包常见形式
当开发把版本转给测试之后，13;意味着测试以此版本为基础，进行测试
开发给的版本：配置文件丢失，13;导致有些功能，前台页面不能用
导致一些最基本的功能无法使用，13;如：页面无响应，报错，版本只能打回，开发修改，测试玩
为了避免以上情况，引入了：转验收活动
直接执行
开发
测试
需求
who
1：需求人员确定需求13;2：开发人员：按需求实现13;3：测试人员：测试开发实现的东西与需求的符合度
环境：测试环境上执行
用例：1级用例（当前模块你认为最基本的用例）执行
通过之后测试接收版本，进行测试
通过但是会出现bug，测试接收版本，进行测试
不通过，bug级别高，很严重，按本打回，提交缺陷，验收不通过
灵活处理
执行结果：
角色：开发、测试
（内部）转验收
买电脑、开机配置
转验收活动
转测试、转验收、测试接收版本
冒烟测试，来自于硬件测试（办卡和电源）
目的:暴露最基本，验证，正确性的问题
找测试人员提供用例，如果没有用例，可以用简易的checklist测
环境：开发环境，真实环境
执行结果：如果出现缺陷，开发提交缺陷单
没有问题，自验通过，转验收
开发人员在转版本转验收之前做
单个模块，转验收
单个模块：也可以在全面测试之前测试
测试人员在转版本转验收之后做
测试人员做
用例：1+2级正向
环境：测试环境
问题：提单，或者版本打回
建议：每一轮开始测试前，都应该做冒烟测试
子系统，系统级，产品级？
测试人员与开发人员都可以做冒烟测试
冒烟测试（预测试）
现状：1：很多时候会产生需求变更，变更记录一般是滞后，开发给你的包/版本，有可能和原计划不一致（这样很可能出现偏差）
现状：2：开发把bug修改后，没有及时的更新bug的状态，可能就不会针对这个bug进行测试
现状：3：延期，模块复杂度比较高，不能够按计划如期完成
开发把报构建好，不告诉测试相关的情况，有可能会
子主题 5
版本信息内容（内部版本）（明确13;开发给的源码包是你想要的）
功能新增、减少、变化
需求变更
修改bug
代码优化、移植平台
软件代码会变更
bug本身有没有被修改完成
修改bug过程中有没有引入新的bug
有没有改变原有功能（老功能）
目的
针对bug的测试
优先做预测试（老功能+新功能的1级）
针对bug，进行测试
优先级
执行全部
优先级1级
用例发现bug
补用例
非用例发现bug
执行部分
执行用例
测试人员：提交的bug，需要自己分析，有没有相互影响的地方
查看：相互影响的部分，是否有用例与之对应，如果没有，重新设计编写用例
执行bug单本身对应的用例，还需要执行新加的相互影响的用例
补充（修改影响法）
更多解决：修改bug过程中引入新的bug13;以及对相互影响部分的老功能，造成有问题
开发不愿意看到bug单很多
开发也不愿意看到bug单少单严重度高
开发不希望看到一个bug单的不通过次数多
1：回归不通过，引入新的问题，将新问题列清楚，把缺陷单的状态改为reopen，重新给开发
2：开发要求你们，关闭本身的bug单，重新提价一个新的相互影响的bug单。13;
避免：1：本身项目组bug严重度高的单数量超高，可以不提交，但是在回归的时候一定要做完整2：需要重新补：避免新的bug单和操作步奏与老的bug单一模一样
回归记录说明
引入新bug13;老功能有影响
how
回归策略
回归测试
交叉测试
发散测试
全面测试
指的是单个模块在这个测试中，没有轮次
story测试
第一轮（528-529）
第二轮（531-61）
迭代测试
SIT第一轮（518-520）
SIT第二轮（22-23）
SIT第三轮（26-30）
上线
测试活动
测试执行
0 条评论
回复 删除
下一页
