didi / didi/AgileTC

建议支持在用例执行界面,调整用例内容(可通过权限或简单开关控制)

Open
#23 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
727
Forks
284
PR merge metrics
No merged PRs in 30d

Description

需求场景一:
测试原来计划按照需求需要测试4种场景,经过代码评审后发现内部实现其中3种是公用代码的,因此在测试执行时想优化用例为只需要2种场景。

需求场景二:
某个用例fail了,想要记录下失败点(一个简单的标签或者加个子节点记录缺陷记录地址即可),但发现没有任何手段可以做这个标记。

综上,个人在新功能测试执行过程中,调整用例是非常常见且频繁的场景,目前测试执行界面无法对用例内容进行除标记外的其他任何编辑,会变得很不方便,需要重新退出执行界面,回到用例编辑界面调整。

不知是否可以考虑,测试结果和现有用例的绑定关系,弱化为仅在创建时新建副本,后续相互独立?类似:
现在:
用例设计时编辑用例a,第一次测试时基于a新建测试任务、标记测试结果,第二次测试时继续基于a新建测试任务、标记测试结果
改为:
用例设计时编辑用例a,第一次测试时直接基于a标记测试结果。第二次测试时基于a新建一个测试任务b(内部实现是把a复制一份,去掉所有执行记录,创建完毕后b和a完全独立没有任何关联),然后基于b标记测试结果
至于需要确认保留的一定是最新的用例这个,可以通过用例名称来灵活处理。比如上面场景的a叫做 xx需求测试_1013,b叫做 xx需求测试_1024 。

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the test execution interface and the current relationship between test cases, execution records, and test results. Done should allow case content changes or failure annotations during execution, and let later test tasks use independent copies without retaining execution records.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.