自己总结的测试流程

• 首先要明确一点，最基础的执行都做不好，其他皆浮云

如果我们现在仍处于初级执行者的阶段，最重要的不就是把测试这件事情做到最好吗？（初级执行者参考文章见下）

• 然后我们明确一点，测试思路、测试质量优于测试技术

测试一年的感悟：追求三方面的极致（测试思维、提升效率、保证质量、沟通）

测试思维：结构性思维、怀疑精神

沟通精神：主动沟通、当面沟通、耐心沟通、持续沟通

• 具体一个项目的流程：

测试设计前要知道：

具体让你测试什么（功能、性能、接口等）、用什么测试工具、测试环境、测试到什么程度

测试设计准备材料：

1. 文档：需求分析说明书、数据库表（含义）、原型可跑、产品（流程）开发（功能细节）人员给清楚流程怎么走的

实现步骤：

零。测试时间

准确评估测试时间是最重要的，需要考虑非常全面

1. 自己写测试用例的时间（包括思维导图和bugfree），自己测试需要的时间

2. 开发那边可能耽误的时间，积极经常沟通

3. 和别的系统配合的时间（尤其是她们可能请假，开会等, 要提前联系并准确确定人员的工作时间、能够全力配合的时间、他们不能全力配合时延迟回复和延迟修改的时间、请假时哪个人员可以代替都问清，包括需要间接交互的人员的所有信息，比如突然别的系统有上线有变动等非常影响进度），积极经常沟通；在开始测试前就要非常清楚需要和哪些系统配合测试，非常明确做到什么程度就可以确定上线或任务完成了，而不是中途才知道还要和哪些测（尤其是在性能测试要给别的系统推数据的时候一定要事先通知对方）

4. 测试过程需要改bug的时间（无论是自己的开发还是别的系统的开发）

5. 以及改完bug的回归测试时间

一。业务流程了解

1. 自己将流程的每一步都认真过一遍（结合上述资料），弄清楚每一个流程需要验证的点在哪里（任何不懂的地方都要及时问清楚）

2. 都把可能的问题想全面了，设计写法想全面了再下笔（其实就是结构性思维：先抓住核心需求，再具体细节拆分、然后梳理业务逻辑）

3. 参加需求会议时，我们除了要关注业务逻辑，还要重点关注验证点都在哪儿，测试的范围是什么

4. 需求评审的时候，要多问几个为什么，为什么要提这个需求（设计的背景是什么，以及设计的总体框架是什么，不要先讲细节）？目前是遇到什么困难？现在是怎么做的？如果涉及到业务数量的，还可以问下量大不大？帮助我们评估需求的合理性

二。用例设计注意

读需求文档时，一定要仔细，每一个细节点都要看到，一丁点不明白的地方都要沟通沟通！！！

一定要严格按照需求文档和原型来规范测试点！！！不要让别人质疑你的专业水平

需求文档至少要看三遍，比产品更了解需求

0. 设计评审时，需要非常准确地清楚开发究竟完成了哪些，哪些还没做，我真正需要测的是哪个部分（是更关注跑通流程还是每个功能点的准确还是。。。）

1. 写功能测试时，重点按照需求文档的要求测试，有几个模块，再看每一个模块有几个功能面（因为设计是OPOA，所以一个页面是一个功能面，从功能面上找功能点），一个功能面有哪些元素即哪些功能点（一般以一个功能面为一页思维导图）；参照功能测试用例设计

2. 写完的测试用例和测试数据应该保留，以便程序变动等情况可以重复使用

3. 写的时候首先必须要将测试用例写的非常完整，完全按照这个来测，测的过程没写到的还要补充；同时注意表述和格式，一定要让别人以最舒服和最易理解不会出现歧义的方式来

4. 写完测试用例要先让开发人员对经典用例进行测试，还要进行测试用例评审

5. 思考所有场景的情形你都想全了吗？你一定还有没想全的，不要武断结束，不同的业务逻辑会有其特定的正常异常场景被忽略，再仔细到极致一点，比如宜分期的就没有考虑到进件一半退出重新进件会不会在后台有记录，参考功能测试用例设计、APP测试注意的点

6.如果有新旧版本，一定要对比观察，测试中遇到与旧版不一致的地方一定要注意（不是改动点的）

7. 除了主流程，微小细节的点也要关注（这些点十分影响用户体验度）

8. 测试的质量参考软件质量模型http://blog.csdn.net/xifeijian/article/details/8542255

9. 测试点的挖掘：

首先是自己默默把所有该功能走过的每一个细节处都过一遍，找出测试点

1. 不只是需求分析的测试点，2.还有开发实现分析的测试点（站在要是你怎么代码实现这个功能上）

需求分析测试点：页面功能点元素测试、业务逻辑测试点（任何情况下都必须使用边界分析法，出问题最多的就在边界值;）

需求分析补充：给产品做体检 https://www.testwo.com/article/1101

测试方法补充：错误推测法

基本测试方法还有参考：http://mp.weixin.qq.com/s/LWRDBl4GysEtlbAIIqkAGQ

三。测试时注意

0. 开发要先提测，确定测试环境的地址，确定数据库地址，确定日志地址，rabbitmq地址，学会看接口文件，日志，队列，数据库，开发哪个人负责哪部分

把测试代码安上jacoco，在测试时就知道自己哪些代码走了，哪些没走

0. 开始测试时就开始记录，详细记录你的每一个细节过程，对于测试总结大有帮助

0. 和开发确认，测试点都有哪些，还有哪些需要注意的地方，有哪些异常的场景需要考虑

1. 彻底检查每个用例的执行结果，不要以为检查了一个标识性地方就万事大吉了，细节错误最容易忽略；一定要在第一次测的时候，保存测试过程尤其是bug的截图证据，当测当写bug

2. 除了要检查其是否“未做其应该做的”还要检查是否“做了其不该做的”

3. 程序某部分存在更多错误的可能性，与该部分已发现错误的数目成正比

4. 发现bug固然重要，但是bug也是分等级的，重要的是关键点的bug不能不管，无关紧要的小bug可延后，bug要描述的非常清晰，图文并茂，不给开发造成疑惑；（1. 系统崩溃 2. 与需求不一致 3. 验证狂等小错误 4. 建议）

5. 不要测试一轮就结束，容易忽略很多可能非常关键的细节，要至少测两次寻找忽略的地方和还有可能出错没测到的地方，以及第一遍第二遍可能结果不一样的错误；回归的时候，不仅要回归bug，bug可能关联的问题也要回归检验

6. 测试时间不充足时，要优先执行重要的用例

7. 多人测试要进行交叉验证

8. 当你操作数据库，尤其是进行删除、更新操作的时候一定要切记先备份，否则后患无穷

9. 一定要分清是配置问题还是程序本身的问题，如果是环境配置的问题可以不计bug，但是是程序设计的问题就一定要计

10. 测的时候对于某些敏感的数据一定要精确记录，比如响应时间，不要记大约都是20秒左右，要记录每一个机型每一次测试的时间，总结出最小时间和最大时间，做到足够细致和周到

11. 虽然有时候卡住了无法走通需要开发解决完再测，但是觉得重要有必要记录下来还是要提bug

12. 遇到阻塞问题时，不要一根筋，要想别的办法绕过或解决掉，实在不行再让开发解决，不要总是频繁不过脑就让别人解决

13. 除了功能性测试，兼容性、性能

14. 注意可能开发改完bug回归的时候，只注重测试正确的数据了，不去测试错误数据，造成遗漏，一定要切记，多思考下

15. 有导出数据的要看是否只导出了当前页还是全部，以及类似的情况，不要陷入惯性思维，又如撮合时往往只看怎么能撮合上不记得去看不符合规则时是否能撮不上，一定要对任何点都报有怀疑精神，才不容易拉下细枝末节的场景

流程：严格按case走、怀疑、随机测试

16. 如果觉得某个细节点有其内部逻辑的实现，要问清楚开发是怎么实现的，以便避免潜在的bug没有发现和测不出来

17. 测试时现在一定要注意sql的优化性，不能join、like、函数

18. 还记得做第二轮测试吗？不要总是测完一遍就结束

 测试一周后，对自己的项目达到多大了解度，都修改了什么，有什么重大bug,不要领导一问就只知道提了多少bug

三．分析bug的重要性：

1. 错误出现在什么地方：需要程序文档和项目历史版本

2. 错误的原因是什么：错误源头可能是规格说明中模棱两个的语句、对先前错误的一次修改、对最终用户需求的一个错误理解等，分析bug的原因对猜测可能影响到的其他环节或模块测试有帮助

3. 谁制造了这个错误：如果多数由一个程序员造成，说明他需要培训等

4. 如何避免该错误的出现：需进行哪些调整

5. 如何更早发现错误：改进评审和测试过程（如评审时就没有关注这个问题）、如果发现了错误说明用例设计是成功的，它为什么成功、我能从中学到什么、怎么设计更多成功用例

6. 无论是测试还是开发，遇到问题时查找原因的思路必须对，不要瞎找，要用结构性思维，逻辑分析，要不吝惜动脑，才能高效定位问题并解决

bug量不多没什么，但是bug的质量一定要高，bug的质量才是测试专业的考究

四。测试工具使用

1. 数据库语句做完要提交才能生效

2. 测试的sql语句要条理写到一起便于测试结果观察

3. 当动作发生的时候要紧盯日志，避免错过可以在动作完成时ctrl+C,可以用sz, grep, tail技巧观察日志

4. 会看日志的报错点在哪儿（哪个报文传输点），会看错误原因（哪条程序语句）

五。额外注意

1．每天都要向直属上司汇报进度，每周五都要向产品汇报进度，每周五都要写下周规划

2. 测试结束的标准是已发现XX个错误或测试了XX长时间

3．多个测试任务并行时，要非常清楚每个任务的优先级，再采取行动

4. 兼容性测试：速度、页面变形、信息完整、走通流程

5. 发现的不影响当前测试的bug一定要记录下来，过后催着开发改，决不能放过，否则都是隐患

6. 项目情况跟进和跟踪：测试过的项目不表示就不管了，有时间一定要定时线上查看是否正常运转，各测过的点是否有异常

7. 教训总结：不能相信开发或者产品说的测过了没什么问题，决定上线前如果还有一丁点不确定的地方就一定不能放过，一定要说清楚，上线前一定要和产品和开发确认好，什么时间上线，测试完成没，不能因为下班没确认或没有提前打招呼就随便走了！

8. 保持一个习惯，看研发提交日志和代码：这是一个提升测试正确率的大杀器，可以少走很多弯路，减少大部分工作量

每次测试前 我都会仔细阅读研发的提交日志和代码变更，会根据这些去判断哪些需要重点测试，哪些只要看是否有影响即可

如果发现代码变更和需求变更无法对应上时 会立马找研发当场确认，为什么改动这块代码。

这个时候往往发现有个更大的坑在，如果不看代码变更，那么只有做全部的回归测试才能发现问题

六。结测标准：

最后一次回归测试不会出现p0-p2的bug，并且bug是收敛的

所有稳定功能都做自动化

回归测试：手工部分、自动化部分，保证覆盖率是70、80%

七。测试总结

1. 学习别人的测试报告怎么写，测试总结所用的工具，测试完都要写测试报告，便于以后出问题怎么定位责任

2. 学习别人写文档的规范性，每个细节要注意，让别人看得舒服

参考：http://www.51testing.com/html/27/84727-1319543.html

3. 测试中每次都应该尽可能的学尽可能用的上的东西，或是利用测试机会练习实践我学到的东西，这样才叫真正学习新知识，没有白浪费时间

4. 分析测试质量（测试质量详见我分析测试质量那篇文章）