想想

测试进行时片： 

    没事，闲着，零碎地写写关于测试这个行业。

    搞来搞去，测试也就这么个流程：从需求分析，测试计划，用例编写或者加个自动化用例，测试执行（dev,test,预发三个环境中依次干），一轮结束后的覆盖率分析，测试报告，总结，如出现线上故障则回溯分析，项目结束后文档统一存放管理。

    其实一般的功能性测试，主要还是需要熟悉业务，之后才能更具业务的维度发散性地设计测试用例，当然中间简单的遇到一些很常见的方法：边界值，等价类划分，场景。其他正交分解之类的方法也有，但是不怎么常用。总的来说，小软件由于业务比较少，走的维度少了各个测试的路径容易想到去覆盖。但当一个大型系统，新增一个小的功能点，可能涉及的范围比较广，比如修改了某个java的头文件，而这个头文件被很多业务引用，那么除了我们新增的业务点需要关注外，还需要去回归相关的业务，这里也反应出了对业务熟悉度的重要性，假如新人来做这个项目的评估，可能会造成很多困扰。

   除了上述测试用例，我觉得么，测试中还有一个需要重视的是总结，其实也就是需要我们对业务了解度不断深化。当然流程的东西，也要去重视，林子大了什么鸟都有，信流程就像信春哥一样，能得永生。

 

测试困扰片：

    一般测试3年左右都会遇到此问题，也看了51很多其他同僚的感叹或者展望，对此，也并没有什么具体的感想，无疑两条路：测试管理方向，或技术方向。这个困扰比较难解开，还得因人而异，还得同性情挂钩。

 

写在最后片：

    尽量去完善各方法的技能：比如linux常用命令，数据库常用的SQL，系统框架的基本架构以及原理，测试小工具应用等到之类的。总之，万剑归宗，全面攻击，最后深化某一个技能，来个单体攻击，KO对方。

 

测试么要么死在这个月，这个月不死下个月死，下个月不死可安度2个月，需求搞死人啊。