知识体系-经验库是必须的,我要整理我的经验库
1,软件测试的特殊字符问题,alert(1),特殊字符转译的问题,script标签注入的问题!!!
2,软件测试的样式问题,数据不够导致的问题,必须要重视!!!
功能测试经验库
需求阶段
- 这个过程要搞清楚,
- 需求分析的过程
- 要严格按照需求进行,测试可以提出自己的疑问,但是一定要严格,
研发阶段
- 这个过程如果有开发方案,拿过来评审一下,
- 不同的人要区别对待,有的人开发的功能比较差,就要认真一点
- 开发文档要阅读,
- 接口要测试,尽早的介入测试,
测试阶段
历史需求
- 历史功能要清晰,
- 你越是清晰,就越能发现问题,这里面有一个思维的发散,深入的问题,
沟通
- 要多和产品沟通,
- 要多和开发沟通
测试进度
- 需要提前测试,
- 需要提前暴露问题,
测试用例
- 要有用例编写,用例评审,
- 这个要留有文档,留有痕迹,
测试执行
- 一定要严格,否则你测试放松一点,问题就要放大好几倍,
- 实际测试完了也不能保证一定没有问题,但是如果你不严格,出问题的概率会放大好几倍,
测试角度
- 功能
- 性能
- 安全
- 页面展示
- 兼容性
功能测试
异常测试,
- 超时测试
- 降级测试,
bug管理
- bug要全数录入,这是数据,要留有痕迹,
- bug量太少是有问题的,
回归测试
- 功能的回归测试,
- 性能的回归测试,这是很多人会漏掉的,
- 这一块可以使用自动化进行
测试报告
- 测试范围的问题
- 上面的用例都要融入
- 上面的bug都要融入
文档管理
- 需求管理
- 用例管理,这个如果不更新就不能起到作用,
- bug管理
- 报告管理
维护阶段
- 现网问题是一个大的经验,必须要仔细认真的分析,思考,
- 要有自动化拨测
- 要先于客户发现问题,
- 现网问题,测试部门要有回溯报告的,
- 持续测试,
测试理念
- 尽早介入测试
- 持续测试,-自动化,在回归测试,和持续测试上是有价值的,
系统的维度
- 可靠性
- 可维护性
- 可信,
测试规范总结!!!! 仅自己可见
###########
复制代码
背景:
12月26日的宕机事件,我有很大的责任,所以我必须要做一个测试规范出来
测试规范的来源:
我认为至少来自5个方面,
1,直接的本次宕机暴露的问题,
2,我自己的以往的测试经验
3,测试bug现网问题,这些现网问题都是因为测试有遗漏导致的,
4,风险控制,
5,流程控制,
复制代码
##############
测试规范
第一部分:来自本次事故保留的问题
1,必须测试开发打印的日志,这个要在开发提测邮件中有体现!!你打印了那些日志,路径在哪里?
2,必须测试功能相关的数据库,这个要在开发提测邮件中有体现!!你使用到了哪些表?
3,必须做大数据量的测试!!
4,所有涉及到外部接口的地方,必须做放通的测试!!我想问现在所有涉及到外部调接口的地方,开发能清晰的理出来吗?每一个页面做了哪些请求,开发能清晰的理出来吗?
5,所有涉及对对外部提供的接口,必须通过测试才提供出去!!
6,所有涉及到大数量查询的地方,涉及到大并发的业务场景,必须做性能测试!!
7,所有的计划任务,必须要打印日志,否则根本没有办法定位是跑了没有生效,还是生效了但是脚本有问题!!!
第二部分:来自论坛测试的经验
1,需求评审阶段
1.1 第一件事情提前发给开发测试,先开发测试自己看,然后开会做内部需求评审,
对于需求不合理的,要尽快的,尽早的,马上提出来,不然就是开发走偏,测试走偏,时间都浪费了,
1.2 需求要发需求邮件,并且附上本期功能所有的原型,高保真,图片,样式,否则需求延后,就导致开发延后,
对于需求内部评审的结果直接在邮件回复,
所有涉及到和外部对接口的,不再提前提供接口,做好同步调试,同步测试,同步上线,否则就会导致大量的信息不同步,导致很被动,打乱开发测试节奏
1.3 开发人员确认需求没有大问题之后,要估算自己的开发时间,这就是一个提测的时间线,
测试人员确认了需求没有大问题之后,要估算自己的写测试用例,做测试的时间,这就是一个验收的时间线,
2,开发阶段&编写用例阶段,
2.1 开发人员,开始开发,必须要输出开发方案,
完成开发方案之后发邮件给大家做评审,
2.2 测试人员必须输出测试用例,理出本期功能所有的测试点,测试场景,这就是执行测试的标准,
完成用例之后,发给开发需求做用例评审,
2.3 开发过程中,测试用例写作过程中,需要和产品沟通的,都尽量建群沟通,做好信息同步,不要单独沟通,防止开发测试信息不同步,
2.4 开发或者测试期间如果涉及到需求要大改,或者估算有误的情况下,就要报风险!
3,开发结束
3.1 开发如果在估算的时间内没有及时完成开发,必须报风险!!!!开发延后就会导致测试延后,导致上线延后,
3.2 开发人员必须做自测,然后发提测邮件,邮件包括涉及的数据库,涉及的打印日志路径,
测试人员收到提测功能,对功能冒烟测试不通过的直接打回,不继续做细节测试!!并且在提测邮件直接打回,并附上冒烟测试结论!
如果被打回,这个时候开发评估修复时间,如果时间过长,也要报风险!!!
3.3 这些都没有问题,进入测试阶段
4,测试阶段
4.1 在提测之后,并且冒烟测试通过之后,开始执行测试,
如果测试过程发现大量的bug,而大量的bug要占用大量的时间才可以修复,这个时候也要报风险,因为开发修复时间长,就会占用测试时间,影响测试进度,
4.2 测试过程中,如果发现重大的需求逻辑问题,不是短时间能解决的, 这个时候也要报风险,!!
4.3 测试过程中,如果一个一般功能,一个bug也没有,这个时候也不对,这说明测试不够深入,必须再去继续深入测试,
4.4 测试过程中,除了本期功能,必须要周边功能的测试,防止开发有改动,影响了其他的地方,
5,验收阶段
5.1 测试结束之后,开始验收,
如果验收的时间线到了,还没有测试结束,必须要说明原因,而且必须要报风险,
5.2 如果验收过程中,出现了大量的bug,或者不符合需求的地方,
这个时候也要说明原因,是测试用例覆盖不够,还是测试用例执行有遗漏,还是需求认为做出的效果不符合需求,需要改需求,而且如果花费时间过大,必须报风险!!!
6,上线灰度
6.1 如果上线灰度有大量的问题,导致大家都搞到了1点,2点,必须报风险,并且说明原因!!
可能是代码包有问题,导致的,
可能是本期功能测试遗漏导致的,
可能是本期功能上线,影响到了老的功能,影响范围扩大,导致的回归未覆盖全,
可能是灰度和现网的数据不一样,现网的数据更加的丰富导致的,测试环境没有测试出来,
7,上线现网
7.1 如果上线现网有大量的问题,导致大家都搞到了1点,2点,必须报风险,并且说明原因!!
为什么灰度没有测试出来,
是不是现网有什么特别的地方,
8,上线之后跟踪版本
8.1 如果版本上线之后有很多的现网问题,也要分析原因,为什么会有这个问题,
第三部分,现网问题,
1,本期测试场景未覆盖全,
比如多端测试,wap和pc,漏掉了一端,
2,测试回归历史功能未覆盖全,
比如导出是好的,但是影响到了其他地方的导出,这些地方不是在本期的功能
3,
测试是不容易的
改动一个地方,至少要测试多个地方
1,本个功能点要看,
2,本个功能相关的功能点要看,
两个可怕:
1,
最可怕的是你想到了,但是你想当然了,没有实际去测试,
可能是相信开发了,可能是相信自己了,可能是自己太累了,可能是心情不好了,可能是时间不够了,
2,
更可怕的是你根本没有想到这个地方,没有测试到,这个太可怕了,
这个就是你不知道他影响到了哪里,可能是一个完全想不到的地方,这怎么预测没办法预测,总不能做全量测试吧
接口测试的要点
1,功能
包括分页,分页数量,排序,
2,是否符合restful的规范啊,
比如错误码,