软件测试工作是必需的吗?(3)

发表于:2014-06-26来源:csdn作者:rickyqiuTX点击数: 标签:软件测试
- 有一套 自动化 验收的 用例 ,可以挂接到自动部署之后或者daily build。前提是我们的 自动化 要足够的问题,效果才会好。 这个阶段除了业务测试的努力

  - 有一套自动化验收的用例,可以挂接到自动部署之后或者daily build。前提是我们的自动化要足够的问题,效果才会好。

  这个阶段除了业务测试的努力,也体现出了QA的价值。这里的QA是指质量管理,有的地方叫SQA,专注在质量度量和研发流程的管理上。

  到这个阶段,发现事情顺了很多,质量也有更大程度的提升,并有改善额趋势。

  第三个阶段:推动全面的质量提升

  到上面第二个阶段,我们发现质量有了一定的提升,但是还是有不少的问题,而且有些问题需要我们把思路和眼界拓宽来看。这里讨论的一些东西可能更适合互联网的产品。

  这里列一些我们可以去做的事情,受限于个人的经验,可能还很片面。

  1. 研发流程的梳理

  其实在阶段2的时候也可能有些团队已经开始做这样的事情,因为在分析质量和效率问题的时候,我们发现很多问题不单纯是代码的问题,可能还涉及研发流程的很多方面,比如:

  - 需求不清楚

  - 跨团队的配合问题

  - 代码版本管理

  - 技术方面的评审和大家的理解

  所以整个研发流程的规范和梳理,以及配合对应的需求和版本管理的系统也是非常的必要,实际中发现效果也是比较的明显。而且还有一点体会,在接手一个很混乱的状况时,这样角度的数量和调整比技术方案的引入更重要和切中要点,能从40分到60分,技术是往80分走的过程效果更明显。

  2. 提交测试前后做的一些事情

  - 代码的静态扫描

  这个方法很多的团队都在做,但是实际的效果似乎差别很多,而且ROI也很难说,不过从方法本身来说还是值得去做的,对测试人员也提出来更高的要求。

  - code review

  这个开发应该要做,特别是开发间的交叉review,非常的有帮助。不过这个也和自测一样,取决于开发负责人的态度。另外,测试也应该去做,特别是对于 diff 代码的review,我们检查做了大概两个月的时间,发现还是非常的有收获。发现了一些黑盒难以发现的问题,以及开发的代码夹带,并且对于这个版本影响范围的评估也更准确。但问题是短期会花费测试更多时间,以及需要测试人员有一定的技术能力。

  3. 测试能力的提升

  测试阶段有很多的事情可以去做,觉得最主要的还是两个方面

  - 自动化。 越来越觉得这个是绕不开的话题,要想尽办法去做,做得更高效更全面。前面有篇blog也提到了一些轻量级的做法,业务测试的团队可以参考 http://blog.csdn.net/superqa/article/details/20644285

  - 辅助手段,比如代码覆盖率,特别是差异的覆盖率。这个大家都比较容易理解就不展开了。

  - 拓展测试的类型

  这个方面说起来有些泛,需要结合团队和业务的情况,比如安全测试,性能测试,兼容性测试等,去发现一些对于产品来说很重要的风险。

  这方面有两个前提,一是我们的基本功能质量到了一个阶段,可以让大家腾出手去拓展测试的面,另一方面我们测试人员的能力要跟得上。

  4. 发布环节的质量把控

  这个方面和传统的测试不太一样,而且了解到不同的组织做法不同,执行发布的人员可能不同,有开发,运维,专职的版本管理或者测试来做。

  在我们的实践中,发布后来都逐步收到测试这边,回头来看觉得还是有不少有帮助的地方。当然也不绝对的必须测试来做。

  - DO分离,避免了随意的发布,特别是在开发手上的时候。所有的bugfix都经过测试发布,可以更准确的度量质量(除非这个问题可以不修复,否则肯定要过发布环节)

  - 知道最近发了什么,可能的影响是什么,需要线上关注什么。

  - 灰度。 互联网产品常用的一个控制风险和节奏的手段。

  - 扩容的快速自动化检查,这方面也依赖于自动化的建设。

  - 发布过程支持灰度的控制,备份和快速的回滚。对发布系统有一定的要求,而且有可追溯性。

原文转自:http://blog.csdn.net/superqa/article/details/21485737