一些有意义的条目：
1、考虑自动化是否能发现有价值的缺陷，是否经得起时间的考验，是否值得付出维护费用
2、决定需要测试什么和何时测试
*对于每一个被发现的缺陷，明确的讨论它应该在什么时候被发现
3、决定如何测试
*是否有一种特殊的路径引导人员找到这个缺陷
*这种功能或特许最好用哪种给定的方法来测试
*知道当前已经进行了哪些测试，以及我们目前和将要进行的测试如何才能增加总体测试效果
*发现软件问题，需要实际用户在实际的环境中，用实际的数据，去做实际的工作
*简单重复的工作实现测试自动化
4、测试中最困难的部分是：决定测什么，决定测试的完整性，确认用户场景等
5、哪些是好的测试，哪些是不好的测试；完成测试后，团队学会了什么？
测试修行：（很重要）
1、将测试分为两部分，即“测试今天的项目，准备明天的项目”
*保证当前的测试项目获得成功
*学习应该做些什么以便下一个测试项目更紧容易
2、警惕重复做一件事情，尝试能不能自动化
3、思考：
*我们用什么技术找到了那个缺陷？
*我们是否可以创建一种方法来找到更多这类缺陷？
*是否可以记住一些实际的测试经验并不断加以应用来提高测试效率？
*软件的哪些症状可以提示我们它有缺陷？
*我们将来能否从那些症状中得到更多的警示？
*这个缺陷教会了我们什么？
因而总结一系列的测试技术、建议和工具
4、反思：
*自己的测试流程是否有问题？
*测试流程里有没有缺陷？
*这里面是否存在妨碍我提高效率的障碍
*例如：
1）收集我们发布给用户的所有缺陷（特别是安全漏洞或者数据缺陷）：
反思我们是否有流程问题，思路是否有方向性错误，或者是否犯了错误
2）分析每个缺陷，争取做到：
停止写出类似的缺陷；更擅长寻找类似的缺陷；当类似缺陷发生时，该如何识别它们
3）能让团队的开发人员、测试人员或者策划等，知道和明白自己所写过的每个缺陷
4）将学到的内容整理成文档，构成已知缺陷的知识体系的基础部分，也尝试通过新的方法，或者自动化的方式来预防错误
5、当发布每个缺陷时，多问问自己几个why 和how：
*一开始是什么错误导致了这个缺陷？能帮助开发小组建立一套系统知识，来减少错误么？
*出现什么样的失败症状时，能告诉我们现在存在这个缺陷？如何将有缺陷的行为从正确行为中分离出来？
*哪些测试技术可以找到这个缺陷
6、学会使用工具，和掌握信息，了解信息如何影响测试
*来自应用程序的信息，包括：需求、体系结构、代码结构、源代码、程序执行时做了哪些事情的运行信息
*确认代码更新或缺陷修复时，哪些测试会受到影响
对自己的训练：
1、理解软件：
*软件可以做什么？本意是什么？
*它使用哪些外部资源来完成任务？
*它的的主要行为是什么？
*它如何和环境交互？
2、理解软件故障：
*是否存在某些编程习惯或者程序语言特别倾向于导致这种类型的故障
*这些特定的故障是否可能出现在某些特定类型的软件行为中
*这些特定的故障是如何使自己显示为失效的
3、理解软件失效：
*为什么软件失效
*软件如何失效
*是否有软件失效的症状可以揭露我们的应用程序的健康状况
*某些功能是否有系统问题
*我们如何迫使特定的功能失效
自我总结：
1、记录测试完整性的部分
*测试用例的执行情况
*测试用例的覆盖面
*版本更新情况和用例维护情况的对比
*版本复杂度和重要性，与用例的覆盖的对比
2、考虑哪些可以用图形来表示：
*测试了哪些，哪些没测试
*测试的功能模块的复杂度
*功能模块内部的依赖关系和外部的依赖关系
*哪些需要重点测试
*测试了的部分的完成度，特别是针对重点模块的
3、找出软件缺陷的能力，需要同考虑如何减少软件中的错误结合起来，这样的能力才是真正的有意义。（回顾起来这也是我以前做的很不好的一点）
*想起以前看到的一个有意思的观点是：
“软件测试的真正价值并不体现在代码中找到多少缺陷，而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足。”
PS：我不是自动化测试的fans，也不是人工测试的fans；不相信有包治万灵的银弹，但是如果只有一种锤子，那么所有的钉子也会被看成是同一种钉子了！那是悲剧，不是福音！
这些要是都做到了，自己成了专家，同时也可以按照一套体系帮助更多的人一起更好的测试了（hoho）
从新整理了一下思路，发现其实要做的，要改进的东西还很多，需要加油！
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/