基于testrail的对于功能测试的一点思考 (一)

首先testrail这个工具根据我的工作经历来看,外企用的多, 当然国内企业也有用的,比如我之前所在的银行项目, leader是来自外企的, 引入了这个工具.

    总体评价下, 这个工具还是很好的: 测试用例库和掌控测试progress, 自我感觉这2点很犀利.

• 测试用例库：

你可以想象，你们项目从远古时代到现在的所有测试用例，你都丢进这个库里，当然，该更新的更新，该删除的删除，还是要避免臃肿。等到运行测试用例的时候，需要哪些测试用例，则从这个库里面挑，组成一个testrun（这是testrail里面的概念）, 我在下一条会再说下, 比如我们要执行某个版本的regression testing, 则可以从我们的用例库里面挑出在回归测试里面需要执行的cases.  而且testrail支持导入excel版测试用例, 所以, 骚年们, 找leader推荐吧, 拿预算吧.

 

•  掌控测试流程:

唉, 博客写的少, 排版头疼.

自我感觉很多测试leader担心的一个问题是, 给某个人分配了任务,比如50个cases, 这个人最终测完给了结果, 那这个结果靠不靠谱, 这个人有没有偷懒. 我们怎么 track, 其实这个问题我相信大家肯定心中有自己的答案. 当然, 没有绝对的解决办法. 任何工具也不行. 只能说我们尽量避免这类问题, testrail里,

1. 当我们在testrun(上面提到的) 里面执行每一条用例的时候, 可以点击一个开始按钮, 执行完再点击一个结束按钮, 这样执行完就会有个时间记录, 当然肯定有人会说, 这个中间肯定会被各种事情打断, 不太有用, 有时又忘记点击结束了, 比如我现在的公司确实弃用了, 但我自我感觉, 如果记录的这个时间比较好的, 一般是测试认真的. 而且可以记录下来这些cases执行所用的时间.

2. 执行每个case, testrail提供增加comment, 可以增加各种多媒体文件, 为执行了这个case提供各种佐证, 我们现在采用的是记录测试的一些版本号信息, failed的case, 我们现在采用的是记录bug url和截图, 以及bug 标题. 这里testrail可以和各种工具集成, 比如jira 

3. 每条case执行, testrail都会有相应记录, 组成了每天的activity, 所以可以查员工每天执行的情况.  testrail这里面还有一张类似sprint燃尽图的testrun燃尽图, 其实我们一般应该设定这个testrun的结束日期, 这样可以大概的参考整个testrun执行的过程是否安排合理, 以及一开始预估的时间是否合理.

 

第一节先到这吧,这酸爽, 谁用谁知道吧.