“主要是接口测试的没问题,前端页面取错值,或者没展出出来”
“我们接口目前其实也只做了基本的一些断言,详细的字段校验还真没做”
你这两句回复可以看出,你们的接口测试并没有真正做。
换句话说,你们产品出的问题并没有定位清楚,可能出在前端,可能出在接口,也可能二者都有。
不太能认同这样的观点。
“需要把前端页面字段,跟后端返回数据,之间的对应关系整理出来” ---- 这个是 dev 的工作,不是 tester 的工作。
测试不需要整理这些对应关系就可以考虑测试自动化。
不可以直接从数据库取数据然后跟 ui 展示的数据对比哦,因为数据库里的数据也许就是错的呢!
正确的方式是将期望结果和实际结果做对比,是不是听起来像是照搬教科书里的话,呵呵
说明这个测试不合格,还需努力强化软硬技能
大佬,我有一批用例,这个平台能保证多台执行机(几乎)同时完成吗?或者说具备多机间的负载均衡功能吗?
另外,用例执行出现异常,能否自动跳过当前用例并自动跳转到下个用例?
postman 提供丰富的断言方法,足以覆盖绝大多数的测试需求。
你能否举例说明你们需要的个性化断言呢?
我也带领团队开发过自动化测试平台,让使用者〇编码实现功能测试 (基于 GUI)、接口测试和性能测试。
目前多数公司虽然都在自己封装框架,但投入的精力只占二分或更少,然后基于自研框架开发测试脚本,投入的精力占八分或更多。然而我认为正确的做法应该是 “八分框架,二分脚本”,这点我们的观点是一致的,因为我能体会你们在开发/封装框架方面做的工作。但这些都要基于需求存在为前提。
结算模块要针对金额做个性化断言,这里可以说的详细些吗?postman 具体做不到什么呢?
postman + newman + jenkins + HTML Publisher Plugin(或 jenkins 自带的 JUnit test result report) + Email Extension Plugin,解决不了你所列的问题吗?
你为什么要自研框架呢?postman 的功能还不够丰富吗,缺少哪些你需要的功能呢?
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
自动化测试工程师需要把精力投放在这种转化上。
示例代码喧宾夺主,违背了自动化测试的初衷。
“依据测试数据自动生成用例”,这个让人难以理解。一般都是依据测试用例构造生成测试数据。
最后一段话更难以理解。什么叫初始数据?什么叫初始公共数据?二者什么关系?渲染测试数据文件是什么样的操作过程?
如果接口设计文档规定的返回结构是没值的字段不允许返回,这就不是 bug,是 by design。
对于返回是 JSON 类型的接口,建议优先选用 JSON 提取器。
这能说明你们的系统庞大、测试环境占用资源多。如果开发环境也使用了差不多规模的资源,且开发和测试团队不存在环境共享,才能说明你们测试环境和开发环境是隔离的。
--“前端吐槽后台接口有时会更改返回的数据结构,返回的字段名与字段类型与接口文档不一致”。
前端和后台必须遵循共同/相同的接口文档。
如果后台按照接口文档更改返回的数据结构,则前端也需要按照接口文档去使用。
如果后台更改返回的数据结构不是按照接口文档来的,前端在使用的过程中一经发现,报告后台的这种不规范行为,要求改正即可。
通过管理手段可以轻松解决的问题,通过技术手段解决起来要麻烦好多。
一般来说,每个 team member 都能独占一套测试环境就已经是很理想的情况了。300+VM / 20+ 人,什么情况?是一套环境需要使用多台 VM 吗?
把所有的 for 去掉,你就明白什么叫软件测试了
变更频繁本身就已经不适用自动化测试了,不是 JS 能救的吧
这类应用数据验证的确很重要,但使用图片对比而不使用文字识别应该更具有可行性。在期望的位置上是否出现期望的数据,那么这个/些数据文字是可以使用图片对比来达到验证目的的。图片对比的确存在准确率问题,但文字识别也存在准确率问题,比较起来,前者应该更有优势吧。
按照常用的测试用例设计方法去设计用例就可以了。设计得精妙,什么意思呢?
没明白以需求为单位该怎么理解,能详细说下吗
用了 300+VM,你们 team 多少人?
同开发过测试平台,[握手]