公司开发与测试工作的现状
- 开发基本不自测，甚至没有自测的环境，特别是涉及多个系统的对接。
- 提测后很多基本的功能都不能正常使用。
- 项目管理比较混乱，但是最终的发布日期又被项目经理定死，所以测试时间常常被压缩。
- 没有对于开发人员的质量方面的考核。
这就造成版本提测后测试人员需要快速展开测试，尽可能多的发现bug，众所周知一些高等级的bug发现的越早后期研发的维护成本越低，所以如何在短的时间内快速复现一些严重级别的bug至关重要。
以下从个人的测试经验和测试流程上说一下个人 的想法。
测试坚持的原则
测试前做好工作计划
俗话说不打无准备的仗，测试前做好工作计划，首先明白该版本如何开展测试，这个版本的测试重点在哪里，这个前期可以加强跟研发的沟通，弄明白测试的重点。然后根据重点规划测试工作。
尽早开展测试
版本提测后尽早展开测试工作，一方面缺陷越早的暴露后期研发的维护成本越低，另一方面根据自己的测试经验来看一个测试周期中发现bug的曲线图是一个不对称的抛物线，前期的工作效率是非常高的，这可能跟测试人员的求知欲有关，测试周期越长后期发现bug的概率越低，所以版本提测后尽快展开测试如果没有高优先级的任务不要中断测试，不然反过头来在进行测试时已找不到了当时灵敏的嗅觉了。
二八原则
软件中80%的bug存在于20%的代码中，这要求测试人员对产品的业务及内部逻辑比较了解，知道哪一块的代码容易出问题。
及时反馈
无论是软件开发还是软件测试沟通是必不可少的，测试发现bug后除了将bug的毕现的步骤及详细结果提交到缺陷管理库中还需要知会相关的研发人员，缩短bug的流转周期。实时将软件的质量情况上报到项目经理或产品经理，他们可以根据版本质量情况作出相应的调整。及时反馈客服、生产、用户的问题并将问题转化为需求或测试用例。
软件测试方法及技巧
代码驱动测试
一段程序已经发生的错误越多，其中存在的错误概率也就越大，错误集中发生的现象，可能和程序员的编程水平和习惯有很大关系，因此对发生错误较多的程序段，因进行更深的测试。
bug驱动测试
Bug具有连带效应，发现一个bug之后如果举一反三能尽早发现更多类似的bug。Bug的修复往往会引入新的bug，应该着重测试与该问题相关的业务。
状态机测试
态机是一种用来对对象行为进行建模的工具，其作用主要是描述对象在它的生命周期内所经历的状态序列，以及如何响应来自外界的各种事件。在计算机科学中，有限状态机被广泛用于建模应用行为、硬件电路系统设计、软件工程，编译器、网络协议、和计算与语言的研究。
状态机可归纳为4个要素，即现态、条件、动作、次态。
状态机在通信领域的应用，在一次呼叫中，从建立连接到通话完毕，要经历摘机、拨号、应答、进行通话、挂机等过程，话机的状态及状态迁移如下：
状态的迁移需要条件（通常说的事件）和动作（即处理函数）来触发，所以我们测试时除了测试稳定的状态外，更应着重测试从现态迁移到次态的这个过程。
运行日志或log日志驱动测试
日志一般用于记录程序运行信息，从而使开发者方便开发调试，无论是在调试还是测试的时候，日志都可以帮助我们解决问题，尤其是在测试驱动的开发中，日志更是我们的得力助手。从运行日志或log日志中可以参悟到研发的一些设计思路及业务流程，这样我们可以从中得到一些测试点。
测试流程上的优化
案例
项目：综合客服项目
时间点：项目10月中旬开始调研，客户要求1月15号项目上线。
项目实际里程碑如下：
实际项目开发周期
该项目计划14周结项，实际用时29周左右，维护时间17周大于开发时间。
项目中bug统计如下：
bug类型统计中设计类型的问题占57%，中间需求多次变更。urgent和high等级的bug占比为41%，前期开发时间较长留给测试时间较短，问题在后面集中爆发，且严重问题较多，造成研发维护成本提高。
从案例中可以看出造成项目浪费的关键因素在于前期需求不明确，需求多次变更，测试介入时间晚很多严重问题后期才爆发，造成研发工作返工。所以我认为测试可以提前到需求阶段，让测试人员参与需求的制定及评审。从该项目的需求包可以看出给出的需求很泛泛，未能明确具体的细节，在这个阶段研发人员和测试人员的关注点不同，研发人员更关注的是怎么实现这个功能，测试人员更能从用户角度出发怎么去使用，如何使用更方便，这样有利于需求澄清与细化，让需求更加的明确。
在软件设计阶段和开发阶段测试人员提供测试用例驱动开发进行工作，同时测试人员需要提高自己的专业技能最好能够在开发阶段进行单元测试。经验数据表明，编码阶段的一个问题遗留到验收测试去解决，所须费用将增加5倍，如下图，一个问题越遗留到后面阶段解决，付出代价就越高，而且是成倍递增关系。
