特意去搜了一下
问题一:BC 覆盖方法的测试条件
对于输入参数 A(A1, A2)、B(B1, B2, B3)、C(C1, C2)、D(D1, D2, D3, D4),使用基本选择(BC)方法时,测试条件如下:
选择每个参数的基本值:假设选各参数的第一个值作为基本值(A1, B1, C1, D1)。
生成测试条件:对于每个参数的非基本值,生成一个测试条件,其他参数取基本值。
测试条件列表:
A2, B1, C1, D1
A1, B2, C1, D1
A1, B3, C1, D1
A1, B1, C2, D1
A1, B1, C1, D2
A1, B1, C1, D3
A1, B1, C1, D4
总数:7 个测试条件。
问题二:边界值法结合基本选择法的测试用例
参数范围:
l ∈ [1500, 1800](整数)
m ∈ [2, 15](整数)
n ∈ [3, 25](整数)
策略:
边界值法:为每个参数选择最小值(min)、最大值(max)和中间值(nominal)。
l: 1500(min), 1650(nominal), 1800(max)
m: 2(min), 8.5 → 9(nominal), 15(max)
n: 3(min), 14(nominal), 25(max)
基本选择法:以中间值为基本值,生成用例覆盖各参数的 min 和 max。
测试用例:
基本组合:l=1650, m=9, n=14
l 的边界值:
l=1500, m=9, n=14(l 的 min)
l=1800, m=9, n=14(l 的 max)
m 的边界值:
l=1650, m=2, n=14(m 的 min)
l=1650, m=15, n=14(m 的 max)
n 的边界值:
l=1650, m=9, n=3(n 的 min)
l=1650, m=9, n=25(n 的 max)
最少用例数:7 个。
你这样说就极端了,做不完加班,无话可说。我指的卷是卷王,那种没事不下班还在那坐着内耗的这种。而且我的说的是技术一般的,不是不行。
一线都这么难,二线更难了,现在是供大于求,先找一个合适的,薪资比预期降低 20%~30%,现在还在招人的公司,大部分不会太差,太差的也不会招人。当然外包公司除外,外包是一直招人。还是有实力的,能收到这么多家公司的面试邀请
银行、国央企、事业单位、政府部门,这些企业都是外包相对而言要舒服点的
看学历不看专业,因为很多 HR 不懂,只看的懂全日制和非全日制
二线城市,测试能过万就不错了,很多公司只要点点点的,6、7 千就能找到。
自动化的、有开发提效工具的、有专项测试的,可以过万,但是有多少公司实际需要呢?
二线城市,好点的公司都是要统招一本了,我在武汉也一样,都是卡学历,不是统招本不要,内推都过不了,最后选择的外包。
建议在二线找工作:不要排斥外包,有的外包很舒服,早 9 晚 5,双休,就是工资和福利都不行,有时候大企业的外包比本地小企业还稳定。
感觉比去年好,今年 2 周至少还能发几份简历出去,去年几个月都没几份
现在非统招本科,内推都没机会投,哎
8 字真言:幽默风趣,勇于搭讪
好吧,我现在需要帮助用户解决他们在公司遇到的一个自动化测试难题。用户已经运行了三年的平台,现在面临一些挑战,尤其是如何提升自动化效率和 KPI,同时他们只有一个高级测试人员负责 QA 工作。
首先,我要理解用户的背景:他们是一个小公司,100 人左右,研发团队 30 人,QA 团队只有一个人,负责高级测试。他们的平台已经运行了三年,目前有 600 个左右的 API 接口需要自动化测试。用户提到每次上线前会运行一次自动化脚本,检查接口响应码和预期结果是否匹配。
当前的问题在于领导希望提高 KPI,而他们想提升自动化效率,但找不到有效的方法或工具。用户的困难是无法找到合适的自动化方案,尤其是因为公司应用迭代快,不适合自动化,但被要求来做。
接下来,我需要分析用户提供的现有情况:
API 自动化:已经有脚本处理 600 个左右的接口,每次上线前运行一次。这说明他们已经在做自动化测试,但可能效率较低或不够智能。
App 自动化:Android 和 iOS 平台都有自动化测试脚本,每次发布新版本时触发脚本。这部分自动化依赖于手动操作模拟器,可能需要调整包安装和重启。
现有挑战:
领导的需求:寻找新的工具、新技术或总结大会上的展示点来提高业绩。
基于以上分析,我需要思考可能的解决方案:
1. 智能化脚本优化
当前脚本可能是手动触发,逐个接口运行。可以考虑将脚本改为智能触发,比如在某些条件变化时自动检测并执行相关接口测试。例如,如果某个接口的响应码异常或参数变化,自动化测试会自动重新运行该接口的检查。
2. 路径自动化
对于应用端的 Android 和 iOS 自动化,用户已经使用 Appium、Allure 进行测试。可以考虑将这些测试路径记录为可重用的脚本,并且在每次发布时自动触发相关测试路径,而不是手动操作模拟器。这需要让开发团队按照固定的步骤提交代码,减少人工干预。
3. 报告优化
自动化报告的质量和分析功能可能影响测试人员的工作效率。可以利用生成详细的 HTML 报告,并结合机器学习算法,预测潜在的问题或异常情况,提前提醒相关人员。
4. 分散化测试
如果自动化脚本过于集中,可能导致维护困难。可以通过分阶段、分批次的方式运行测试,比如每次发布前仅测试部分接口和关键路径,而不是整个应用。
5. 集成工具
寻找一些集成工具或平台,将 API 测试和 App 测试更紧密地结合在一起,可能实现自动化测试的统一管理和执行,提升整体效率。
6. 智能化测试策略
基于历史数据和结果,可以建立一个模型来预测哪些接口在上线时更容易出现问题。这样,在每次发布前,优先测试这些高风险接口,从而提高整体的成功率。
7. 技术能力提升
虽然现在自动化效率有限,但可以通过学习新工具和技术,提升自己的能力。例如,学习 Cypress、Splunk 等工具,并将其与现有的脚本集成起来,以实现更高效的测试和数据分析。
8. 用户反馈机制
建立一个持续的反馈机制,让用户能够即时了解接口测试的结果变化,并根据需要调整自动化策略。这可能包括实时报告或动态调整脚本触发条件。
综上所述,用户可以从以下几个方面入手:
通过这些方法,用户可以在有限的资源下,尽可能提升自动化测试的效果,同时满足领导对 KPI 的要求。虽然目前效率有限,但通过持续改进和技术学习,未来仍有提升的空间。
根据上述思考,以下是分步骤的解决方案:
优化现有自动化脚本:
引入路径自动化工具:
提升报告分析能力:
分散化自动化执行:
探索集成自动化工具:
持续学习和提升技术能力:
通过以上步骤,用户可以在现有资源限制下,尽可能提升自动化测试的效果,并满足领导对 KPI 的需求。虽然目前效率有限,但通过持续改进和技术学习,未来仍有显著提升的空间。
现在没以前那么影响大了,还是看外包去的有没有大厂背景,外包去大厂,并且一直做了很多年,比不知名的公司做很多年要好
大厂流程都很严谨,但是执行流程的人就一言难尽了
我们是这样
openai 根据需求和模板生成测试用例和通过接口参数生成相关接口测试用例,这些可不是光靠测试可以做到的,产品的需求文档质量、开发的接口 API 质量,这些同样非常重要,羡慕你们有认真负责的产品和开发。
想靠 AI 降本不太可能,高配置的机器、硬件、AI 人才、AI 训练成本,这些加起来花的钱可以请好几个功能测试,花大价钱请的 AI 人才还不一定能达到想要的效果,项目很大概率会失败,即使成功顶多也是增效提质。再如果领导想让搞 AI 的去做功能测试,得被怼到地底,不又得招功能测试,然后呢,就会发现,功能测试人员没少几个,但是多了 AI、高配置的机器和硬件成本、AI 训练成本,最后得到一个年终 AI 在测试行业落地项目评奖的 PPT。
一周运动 3 次,每次运动 1 小时,力量加有氧,到年底发现越减越肥
年前 6~9 月份试了 4 个月的水,是真惨,今年 3、4 月份我准备再试下
定期给钱、公司稳定、项目一直有做的就行,其他的交给时间
以前我一直认为多关注测试圈前辈,可以从他们身上吸取经验和教训,应该可以少走些弯路。这几年渐渐发现,除了经验是真的有用外,教训是没法吸取的。谁能想到 2020 年、2021 年经济形势一片大好,股市飞起,到了 2022 年经济就跳了悬崖,到 2025 年已经 3 年了,还不见经济有点点能站起来的趋势。
嗯嗯,只期望不被赶下饭桌就好
从一线回武汉时降了,2022 年在武汉被裁员后进了外包公司,工资涨了点,武汉出了名的工资低,除了大厂分部外,其他企业不会超过 15K。
软件
周一~周五:8:30~5:00
周末双休
春节假期:14 天
我一个亲戚 30 还在美国留学呢,最近刚毕业,而我这个年龄却过上了柴米油盐酱醋茶的生活,还担心年龄大了找不到好工作,我也像你这样去比较,那不得原地跳楼