离开网易的转型之路2：无悔选择测试之路-路上的抉择、进取

Infoq发布了文章，这里我仍是吐槽原文，未修改的，让你们品味下：

 

2、无悔选择测试之路-路上的抉择、进取

 

 

有了流程规范，接下来是实施和持续改进，运用在一个项目上，先作了三个月吧，不停地测试，编写功能测试用例，也走了2条弯路：

 

 

一、用例花了大量时间编写，就连：打开浏览器，输入xx，点击登陆，这个也记录了（这种是早期情况）。

 

 

二、我竟然还请缨加入开发，由于看到一些任务完成不了，后来雷叔也指明，测试作测试应该去作的，若是我当时帮忙作开发，那么不少测试都完成不了，同样保证不了质量。

 

 

因此，测试人员除了要了解业务以外，使用简单、清晰的语言结构来进行测试以外，还应该准肯定位本身，明白本身在整个版本迭代中，控制质量的位置！

 

 

你们可能想知道，那段日子锻炼了什么？那三个月没法忘记，天天高强度测试，用的最多的就是，功能测试：边界值、场景法；白盒测试。其实就是锻炼了测试的基础技能和流程管理。

 

 

后来测试管理逐步创建，可是在测试过程当中，应当如何提升代码质量，也参考了敏捷开发中高质量 Java 代码开发实践:http://www.ibm.com/developerworks/cn/java/j-lo-agile/，作了一些适合团队的改进：

 

 

 

 

这6点不言而喻，这种迭代版本中java代码质量提高的模式，已经采用了将近一年，很是有效果。

 

 

   同年Q2，对测试管理进行了改进，其中是受到，@段念-段文韬，组织敏捷测试（http://www.infoq.com/cn/news/2011/01/dn-agile-test-3）影响，采用相似“一页纸计划”的测试文档（在此要感谢@段念-段文韬）在redmine进行管理，以前每次整理测试计划，发送给开发人员，实际上耗费了一些时间，而且成效不大，如今的任务：需求、开发、测试，所有交给redmine管理，全部事情一目了然，对任何人都是可见的，有没有完成，进度如何，很是清晰。

 

 

ok，以前不是讲过检查表的作法吗？虽然覆盖了很多范围，用了一段时间，收效不大，决定改进，变成季度性检查，包括的方面比较多。

 

 

后来为了规范整个开发测试流程的管理，包括开发、测试的交互，又制定了SQA框架，轻量级的：

 

 

 

 

图 最初制定的SQA框架（2011年3月31日）

 

 

后来发生了比较大的变化，作的更好、更轻量级，无独有偶，买了一本@朱少民老师，的：《全程软件测试》，发觉这个SQA框架也是***到目前的每一个环节，更适合目前团队的scrum模式，在此也要感谢@朱少民老师，真是相见恨晚，否则能够少走不少弯路！！！

 

 

你们可能会问，scrum模式，有不少用户故事，测试人员怎么利用？为何想到这个，当知道遗漏了测试场景，会很不爽，怎么避免呢？加上@Aullyxiao的《软件测试之魂》提到分层测试的想法，想了想，还能够结合这么整：

 

 

 

 

 

 

对于目前的开发架构来讲，一个用户故事，或许涉及这四个点，能够从这个四个点入手来进行质量保证，如何作呢？单元测试就开发人员处理了，代码审查，测试人员能够参与和监督，其实就是要保证将：开发任务与提交到svn的代码进行关联，这样子，当测试人员检查开发任务的时候，就能够找到改变过的代码，曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。固然，在此期间，看过@架构师Jack，《功能测试用例基础设计模型》，也采用了其中一些；还有@季哥来自淘宝，的探索式测试，我以为本身还须要时间来消化。