知识体系-经验库是必须的，我要整理我的经验库
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的规范啊，
比如错误码，
