关于测试流程
在项目需求定下后，就需要进行需求分析，并编写测试计划和测试用例。测试计划可以大致列出各阶段的测试过程。最理想的情况是，测试越早参与到项目中越好。比如，代码编写后的单元测试，即针对单个模块内部逻辑，输入输出进行测试。这一部分通常由开发人员完成。
测试人员介入最好在代码进行到一定阶段后，就开始接口测试。可以提前编写关于接口测试的用例和自动化脚本。在代码工作完成得差不多的时候，就可以开始进行全面的功能测试了。功能测试细分为几个阶段：冒烟测试、全面功能测试、回归测试。
冒烟测试，最早起源于电路板的测试，当出现严重短路问题时电路板会烧掉冒烟。可想而知，这一阶段，是为了验证软件的正向主干流程，即：软件最重要的主干流程正向跑通。跑不通则返回给开发进行修改，这一阶段暂时不会涉及到小功能点的bug查找。只有在冒烟测试通过后，才会进入下一阶段，全面功能测试，即覆盖所有的功能点，保证所有功能测试过一遍。而回归测试会贯穿在整个测试过程中，指的测试人员提交的bug，由开发人员修改完成后，测试人员再次遍历验证是否全部修复。
待功能测试阶段软件比较稳定时，可以开始兼容性测试，保证在不同机型不同系统下软件功能正常。资源有限的情况下，苹果机型选择当前最新的2,3款即可，系统最近的2,3个版本即可。Android机型系统众多，选主流的几款，Android端工作量会相对偏大。如果是纯软件，无需硬件配合使用的项目，其实可以在网上通过众测平台去测兼容性，比较大的有testin，百度众测等。同时，也可以开始性能测试，比如影响手机电量、流量、内存的情况，比如弱网测试等等。
关于测试用例
测试流程过程中，当然包含测试用例的编写，也是最为重要的一部分。当接触到自动化测试后，会觉得自动化只是工具，是实现测试用例并将其高效化的一种方式，测试的核心仍在于如何设计高质量的测试用例，即：用最少的用例实现最大化覆盖率。
最近百人计划很多关于测试用例方面的经验分享。有一些我工作中接触不到的感觉很有用。
比如用例评审很重要。用例编写完成后需要所有相关人员整体过一遍，确保一些逻辑流程无争议，避免一些功能在项目后期需推翻重来的情况。
（五娃）用例评审时，正向的用例简单说下就可以，最主要的是异常用例。在评审时，不要一条条的念，而是把你的关注点说清楚以及有疑问的地方提出来并能够解决。
另外，五娃的分享中也提到：测试用例的细化程度可以作为阶段性排期的一个依据。例如，我们根据usecase图流程图，加上业务规则，可以估算出用例的大概数量，那么测试执行时间可以估算为测试天数+20%预留时间。预留时间是因为用例的难度不同。PS：这种估算只能在没有真实可依赖数据时作为参考。
另外想起一点，关于风险评估，想起之前在《Google软件测试》中看到的一些方法。书中提到ACC原则（Attribute特质、Component组件、Capability能力），即：确定产品的属性（特质，产品所交付的核心价值），组件（可以理解为产品的主要模块、组件、子系统等），然后快速简明的列出保证待测验证系统能正常运作的最重要的能力。依赖这个能力列表，可以再细化出测试用例。并且，可以用失败频率和影响给每项能力打分。从而评定风险级别，基于‘特质-组件‘表，可生成一个风险区域热图。比较好的一点建议是：可以自己先完成风险热图后展示给开发、项目经理、销售等，他们自然会提出自己的意见。与其询问他们关于某个模糊概念的看，不如拿一个明确的结论来引起辩论。
ACC建模参考：http://www.cnblogs.com/liangshi/archive/2012/04/23/2465897.html
最后，时间管理。
目前工作中比较高效的时候，基本是这样的。早上到公司后，马上写下待完成的事，然后优先级分类，比如哪些一定要今天完成，其中哪些必须优先完成。另外，如果有空闲时间，可以做些什么其它的事。比较烦恼的一点是，工作过程中经常被别人打断...都是那种突然好像要马上做的小事。尽量做到，将这些事情集中到某一段时间处理吧。
