阶段性小节

很久没有把学习的东西记录下来了，最近身体欠佳，因为这身体应付工作上的事情已经很是吃力了，所以就没有时间在在电脑前总结点东西下来。现在，就在这里总结一下最近看得见的自己的进步。

第一，  引进自动化

大家都知道，对于测试来说，保证 Lean的前提是尽可能的实现自动化。但这里所指的自动化并不是单单地讲将测试自动的去执行，而是指电脑协助测试。测试自动化可以从测试用例的执行去看，也可以是其他电脑可以提供帮助的方法，例如自动生成测试数据，自动执行安装等。所有自动化的目标都是高效。所以，从高效的角度出发，提出

1.       自动 daily build

我用 bat脚本写了一个 schedule task，目的是每天下午 5点自动从 p4上 sync代码， rebuild项目。再将生成的执行文件拷贝到 daily build的文件夹。这样大大节省了每天手动编译的时间。第一次，用 command 语言写脚本文件，虽然难度并不大，还是有点小成就感。

2.       产品回归测试自动化

与以往不同，这次的自动化设计并没有完全依赖于工具来实现。考虑到项目的架构，我们将自动化分为两部分，后台（ .net）和前端（ html）。后台的测试是由编程序完成，前端则是计划用自动化测试工具实现。这样，即能准确的定位问题，又可以规避一般的开源自动化工具的不足。

 

第二，  深入讨论性能策略

一个需要读取数据的软件或是网络应用，无论面向的是个体用户还是企业用户，性能方面总是一个必须考虑的问题。吸取以前在开发后期才考虑性能缺陷而导致基于架构的性能瓶颈很难修复的教训，在产品功能开发的第一个阶段，我们便大刀阔斧的对现有架构的性能进行测试，并从架构和代码化的角度进行全方位的 tuning。简单讲，分三步走：

1.       制定性能指标

·         硬件

·         软件环境

·         操作平台

2.       性能测试 – 检测我们现在的性能情况

·         不同数据量的反映时间

·         不同功能模块的执行速度

这个过程需要做的事情比较多，例如写测试页面，准备测试数据，加载测试脚本，测试用例执行等。

3.       改进

·         定义瓶颈

·         优化算法

我们组做性能优化的小伙们不但将 architecture优化，还互相分享了关于 C#和 JS编写习惯给性能造成的压力的知识。例如， JS中“ .”会增加 CPU处理负担； If (int i=0, i <length, i ++ ), 需要将 int i 移出 if语句，以减少 initiate时，对 memory的负荷等等。

 

第三，  Lean开发模型中的流程改进

每次 sprint结束，都会有 retrospect，分析什么是我们做的好的需要继续保持的，什么是做的不好的需要改进的。几个 sprint下来，就真的可以看到越来越 lean了。这里只列几个，

1.       Lean model应该以 pull模式去 fix bug，而不应该等着写模块的人去 fix所有跟此模块相关的 bug

2.       一个 scrum里面，有一个 quality engineer负责真正质量保证，其中包括质量标准的订制，测试活动的组织，测试策略的编写等。而每个人包括 PO， developer， scrum master都可是是 test engineer来随机的 pick已有的测试工作。

3.       每天都有一个可运行可测试的软件 build出来。 1个小时的时间，所有 test engineer来做 daily test，尽早发现 defect。

4.       Planning meeting还有 task break down，会议结束时，每个人都可以重复口述会议的内容核心，以确保大家的理解无误。

 

第四，  产品深入

虽然，我把这一项列在最后，但是我觉得对于一个测试人员来说，对产品的了解是非常重要的。对产品的了解，绝不是读读需求文档，看看设计架构这么简单。也许，每个测试人员只是在一个 scrum里面负责一部分事情，但是我们必须清楚为什么要生产这个产品出来？它这个 release的目标是什么，具体到每一个细节？然后在看，自己 scrum的目标是什么？ 结合真正的用户需求市场定位用户体验，以及真正 solving problem for user的思维去设计测试用例。在专注每个细节的同时，都不能忘记产品的 big map。同时，又要多产品在公司产品群中的定位有所了解才不能偏颇。前几天听到一个 chief product manager的观点很受启发。一个轻量级的产品总是在用户的不断要求下做的越来越重，可是当重到一定程度的时候。 Casual user不在可以驾驭这样的产品，可是又远达不到 power user的需求。当产品处于这样的境地，就意味着重新定位。成熟的产品线，会用不同的产品去覆盖不同的客户群。这不同的产品的自己的定位就显得尤为重要。因为无谓的 overlap带来的就是浪费和风险。