前段时间遇到这类难题. 没有去解决,最后抛给开发自己去测试了.
最后测试人员这里只关注几个关键点:
1, 能按名称前匹配
2, 能中英文混合搜索
3, 手机能全匹配 -- 才能搜索 (也就是 10 位数字允许搜索不到)
产品列出一个点就测试一个点.
测试方法: 埋数据.
示例:
修改数据库某数据为"Java ABC",然后测试"java"能不能搜索到它.
修改数据库某数据为"Java 开发",然后测试"java"能不能搜索到它.
修改数据库某数据为"工程师",然后测试"工程"能不能搜索到它.
验证是只看看有没有期待的数据就行了.不看结果有多少个.
至于搜索结果 是不是多了,少了,错了这个还是得人工测试.
个人观点: PO 模式不适合快速项目. 它适合母语为英语系的去搞. 多 1 倍 2 倍代码对我们来说不是问题,但是自己写的代码自己看不懂就是问题了.这是涉及代码复杂度的问题.
个人经验 :
测试代码和业务紧密相关,所以我是按模块分目录来组织代码的.我讨厌再分一级 PO 层.遇到可以公用部分,再建一个公共目录.
示例:
--做单目录
- 前A端加工
- 前B加工
- 公共登陆
--数据库工具
--Mock工具
代码的复杂度越低,新人越好理解.
再说说 UI 自动化.
我们在做测试过程发现: 一直淹没在查找元素问题上. 60% 以上的时间在查找元素. 这时再给他们讲要优化代码把公共代码提取为 PO 模式是找打
UI 自动化测试的重点是: 如何做数据分离. (就像 robot-framework 哪样).
大家都想写这样的测试用例:
手机登陆 18912345678 123456
打开首页
存在 欢迎你
点击翻页
存在 正在加载
这才是大家想要的
估计就是对不可信证书强制信任,然后忽略而已.
访问这样的地址 (https://192.168.100.1/test) ,不通的话,可以让 httpclient 强制信任证书的.
如果测试代码是跑在浏览器上的,必须得动态修改 host 文件