禅道在使用的过程当中有什么问题

我用的是免费版的，我的使用后感受是写用例方面
1、工具问题：CSV导入字段必须不能为空；
解决方式：重新下载模板、把有问题文件的记录粘贴到模板上，重新导入；
2、坑大（用例：文件格式（csv）双引号问题""）：A、数据库；B、字符串拆分规则
解决方式：在上传用例数据时，不能使用英文的双引号，除非必须要用，就要用中文的。
以上是我写测试用例得出来的经验，希望能跟大家分享！！！

用例等级

allure对用例的等级划分成五个等级：

blocker　 阻塞缺陷（功能未实现，无法下一步）

critical严重缺陷（功能点缺失）

normal 一般缺陷（边界情况，格式错误）

minor　 次要缺陷（界面错误与ui需求不符）

trivial 轻微缺陷（必须项无提示，或者提示不规范）

使用方法：@allureseverity("blocker")

定义项目名称

例如：  @allureepic("项目名称: 会所资源管理系统")

定义用例模块名称

例如：  @allurefeature("审核模块")

定义用例名称

例如：   @allurestory("用例的标题: 对会所资源进行增、删、改、查")

用例标题

例如：@alluretitle(用例的标题)

用例的描述

allure为测试用例添加描述 有3中方式：
1、 使用装饰器@alluredescription ，传递一个字符串参数用来描述测试用例；

 例如：     @alluredescription("""多行描述语：这是通过传递字符串参数的方式添加的一段描述语""")

2、直接 在测试用例方法中 通过 编写文档注释 的方式来添加描述；

3、使用装饰器@alluredescription_html，传递一段HTML文本，这将在测试报告的"Description"部分渲染出来；

用例的步骤描述

@allurestep(“ *** 作步骤: 修改资源身份信息”)

---------------------------------------------------------------------------------------------------------

@allureissue(">禅道是一个测试管理工具，可以在里面进行项目管理以及bug用例管理，是一个非常好用的管理工具。
当测试环境搭建完成后，测试人员将在自己搭建的环境上执行测试用例，开展测试工作。
测试人员在执行测试用例的过程中，如发现实际结果与预期结果不一致， 则意味着出现Bug (缺陷、错误、问题)。当测试人员发现了Bug之后，就需要把Bug提交给开发人员进行修复。

前面几期我们谈及了如何将测试的介入时间提前， 从而提早发现问题， 提早解决， 并介绍了两个实践：持续集成和测试先行。这个两个一个是从业务上面预防问题， 一个是从技术方面提早发现问题。是质量内建中用于提早发现问题的常用实践。

但貌似这些实践都着力于测试之外的范围， 是否有着力于测试本身的招式去将软件测试做的更加完善， 有效。这期， 我们就来感受一下软件测试本领域的内卷 -- 测试用例版本管理

通常我们的测试用例， 本质上是对软件需求的各个功能点展开与组合。开始， 在需求逐步增加的情况下，这是很容易的。一般的实践中测试用例分两种：

测试需求类型的测试用例

测试动作类型的测试用例

测试需求类型的测试用例描述的是需要测试什么， 例如：测试登录页面-进入登录页面-进行登录-查看结果 这是很不专业但是很常见的测试用例书写方法， 写这种用例的好处就是可以快速的生成成吨的用例的测试不同的功能点。

测试动作类型的测试用例则描述的是怎么测试， 例如：浏览器中输入 >没有测试用例可以用禅道进行测试
写好一个软件的测试用例的建议有：
1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。
2、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。
3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可 *** 作性。
4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
5、测试用例级别要划分清楚，这样在测试执行时有主次之分。
6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。一个用例检查的情况太多，会导致用例的目的不明确。而且这样组织用例，有利于需求覆盖率的统计。一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。

---