软件架构设计
我发现通过阅读,经常能够看到作者对某个我们已经熟悉的概念的扩展。就像现在讨论的软件测试架构一样,作者就能提到一个高度上去,将测试架构分为“测试管理架构”“测试技术架构”。也许我们通常在工作中也会涉及到这些方面,但却提不到这个高度上来。
废话少说了,看看书中书的。
以上是软件测试架构设计范围示意图。其实这是我们都很清楚了,软件测试团队一方面要和其他相关部门打交道,另一方面当关起门来在自己的部门时,就是围绕以“测试流程”“测试工具”“测试技术”“测试方面”为工具对“软件产品”进行工作,进而产生“合格的产品”。用我自己总结的话说“不成熟的产品,经过测试人员测试,出来的要是合格的产品”“不规范的文档,经过测试人员测试,要出一个合格的文档”,我们的任务就是“由不完善到完善”。
有测试架构设计范围,得出测试架构,测试架构分为“软件测试管理架构”“软件技术架构”。在论坛上涉及架构时够多的是说的技术架构。
有关测试管理架构,我想应该属于管理学分支了。通常我们能看网络上讨论的“测试的职业方向”就属于这一类。作者并没有多说,我想后面我会继续从其他地方来学习。作者举例了,我想讨论一下。“让每个测试人员(每个层次)都能看到希望”。这其实不仅适用于软件测试吧,让每个人都能看到自己成长的方向,是往技术上走,还是在管理上有提高,这都是必要的。我通常在想“作为一个工作的人,他们关注什么呢?一是工资福利好不好?二是能不能学到东西?有没有发展?其次再讨论其他一些吧”。在不同的阶段,每个人关注的重点不一样,让每个层次的人,都能获得自己希望的。技术上提供了,管理水平上去了,工资涨了。这展开说,将是一个很大的话题,涉及到测试人员结构分布,领导对测试的支持等等。
那么具体展开的时候,这两种测试架构又包括哪些内容呢?
其实我想,在现实的世界了,我们并不一定要把某个工作分的很清楚,它到底是技术架构的,还是管理架构的。例如对一些常见模块的用例整理,以后设计用例时就按这个来做,它就是技术上的积累,又是管理上的规范。
两种的关系
软件测试的一个一个业务就像一座一座小山一样,我们用测试技术这个剑去解决它,而“流程控制”就是我们的管理,没有规矩不成方圆。
那么到底我们怎么开始我们最初的测试架构呢?很有幸,我曾经搭建过一个测试团队,那时候很笼统,没有什么理论概念,但大体上和作者提到的差不多。
在最开始的时候,我们这样开展
1、业务功能测试框架:可重用的测试思路/框架列出了各种测试点以及测试方法
2、测试数据:特别是影响性能的测试数据,包括一些数据或者程序,集中管理起来。并加以说明,方便以后使用
3、自动化测试脚本,接口函数测试套件,进行版本控制。
4、回归bug,将bug分类并说明原因,形成一个如果控制bug的可行性方案
5、测试文档设计模板,最好每个都给出例子
6、指定测试设计/审核机制,用例/bug描写规范,并不断改进测试过程。
相关链接: