『软件测试』大家聊聊关于测试环境管理吧。
本帖最后由 saarchinese 于 2013-9-18 10:40 编辑就是如何监控和管理测试环境 (Testumgebung)，好像现在还没有一个较好的软件来统一管理和监控测试环境，基本都是看信看ticket才知道哪里有问题，有人知道，有没有什么比较好的，这方面的管理监控软件啊？
举个例子：
很多 Systeme 和 Applikationen 互相交互链接组成一个大的集成系统来完成特定的 Geschaeftsfall，在一个 release 里增加新功能，就要对整个集成系统在不同的 Geschaeftsfaelle 下进行测试，但 Systeme 和 Applikationen 太多以至于一个地方 nicht verfuegbar，整个 Geschaeftsfall 的测试都被 blockieren 了。所以真正留给测试的时间其实并不多，如果测了一半才发现系统环境的问题就会更郁闷，一些项目会更具自己需要写一些小的程序，比如监控 Systeme 和 Applikationen 的端口或者监控开的 Ticket，生成 Statuspage 之类的东西，来更好的监控环境，其他一些项目就根本没有监控管理环境的软件，只靠看各个部门发的信和开的 Ticket，然后自己决定是否能进行测试，这样不但很辛苦，而且经常会出现比如 Testdatenproblem 或者 Umgebungsproblem 之类的问题，以至浪费不必要的时间和精力，需要重新测试。还有很多项目有不止一个测试环境，这样就更复杂了。
上面的例子是针对比较大或者系统比较多的项目而言。现在市场上有没有比较成熟的测试环境监控或者管理的软件呢？ 本帖最后由 fusion 于 2013-9-18 10:29 编辑
有挺多的，比如hp Quality Center， vector也有，还有n多的这样的。。。我建议你去参加每年在斯图的那个testing的展会，你就发现不是有没有的问题，而是选哪个的问题。。。各有好处，最好就是自己写，我以前公司还是我做的，现在公司也是公司自己写的，我接触的其他公司大多也是自己弄的或找人弄的，即使买的，也是要根据自己再加plugin的 本帖最后由 saarchinese 于 2013-9-18 11:41 编辑
fusion 发表于 2013-9-18 11:28
有挺多的，比如hp Quality Center， vector也有，还有n多的这样的。。。我建议你去参加每年在斯图的那个tes ...
HP QC 之类的不能监控和管理测试环境。。。重点：测试环境～～～
说软件的话其实更多是指一个 Framework，例如可以进行二次开发。写自己想要的东西，但监控端口或者ticket，生成报表或者 Statuspage，downtime Email Vorlage 等功能是自带的或者简单 anpassen 即可，这种软件还没有吧。 saarchinese 发表于 2013-9-18 10:38
HP QC 之类的不能监控和管理测试环境。。。重点：测试环境～～～
说软件的话其实更多是指一个 Frame ...
QC可以再开发的呀。。。你这种的每个公司需求不一样，很少有commercial的直接买了就用的。。。最多也就想atlassian出很多模块，但是每个模块都有interface fusion 发表于 2013-9-18 12:55
QC可以再开发的呀。。。你这种的每个公司需求不一样，很少有commercial的直接买了就用的。。。最多也就想 ...
再说一次吧，QC 不能监控管理测试环境。。。
聊的软件和公司需求也没半毛钱关系。。。
本帖最后由 fusion 于 2013-9-18 12:19 编辑
saarchinese 发表于 2013-9-18 12:05
再说一次吧，QC 不能监控管理测试环境。。。
聊的软件和公司需求也没半毛钱关系。。。
我本来说的就是再开发，我都可以把doors再开发成管理监控软件，关键是找个适合的framework。qc当然可以，我做过
我忘问了，你面向的target是啥呀，测试的是哪个领域的系统啊，是白盒还是黑盒。
不过也可能我们碰到的问题不一样，一般我接触的都是ticket System，configuration System，requirement system都是以给的，是不可变的，然后只能基于这些提供的interface再开发个测试环境，所以我们在选tool 上的限制很大，一般就自己开发的 本帖最后由 saarchinese 于 2013-9-18 13:32 编辑
fusion 发表于 2013-9-18 13:08
我本来说的就是再开发，我都可以把doors再开发成管理监控软件，关键是找个适合的framework。qc当然可以 ...
qc 可以二次开发，但不能监控和管理测试环境。。。我讨论的是测试环境的监控和管理，不是二次开发。。。
上面的例子里 Systeme 和 Applikationen 都是各自独立的系统，技术可以是各自不同的，比如 SAP, Siebel, Unix, MVS等，不是指哪个特定领域，测试内容黑盒和白盒都包括，但所聊的软件和测试内容没有任何关系。
每个公司在不用方面的工具是给定的也是不同的，这不是问题，每个公司都是如此，我的问题是在测试环境管理和监控方面没有一个比较规范和市场上统一的工具。 saarchinese 发表于 2013-9-18 12:27
qc 可以二次开发，但不能监控和管理测试环境。。。我讨论的是测试环境的监控和管理，不是二次开发。。。
...
好吧，我明白了，我们说的不是一个领域的，我是做嵌入式的，你应该是纯软件IT的吧。。。
但我还是很有兴趣了解下，如果各个系统相互独立，是不是说你需要一个自动检测的软件在不同的系统间notification别的系统的变更？ 本帖最后由 saarchinese 于 2013-9-19 10:47 编辑
fusion 发表于 2013-9-18 13:33
好吧，我明白了，我们说的不是一个领域的，我是做嵌入式的，你应该是纯软件IT的吧。。。
但我还是很有兴 ...
汽车领域里除了嵌入式开发外，其实也有很多类似我上面举的那个例子，IT 在汽车领域没记错的话分为三层，以BMW为例，最上面那层就是慕尼黑的那个 IT Zentrum，除了 roll out 软件外，所有的 IT Strategy 也由它决定，比如用 SAP 还是 Siebel ，最下层是每个 Werkstatt，比如售后服务这块， 客户在Werkstatt 有 Beschwerde 的时候，如何在系统里 erfassen，涉及到的就不止一个系统，比如汽车被修理的时候一定要通过每个 Werkstatt 的服务终端，导入客户信息 Kundendatenverwaltungsystem，也肯定要访问文件管理系统 DMS 调入汽车部件的图纸，输入预约信息 Terminbuchungssystem 等，如果有 Rückrufaktionen 的时候，就涉及统管 Rückruf 的 Systeme 和 Applikationen。这都是例子，涉及到的 Geschaeftsfaelle 都是要很多系统一起来完成的。嵌入式有自己的一套开发和测试机制，涉及硬件较多，和我上面的例子是不一样的。不能说是纯 it，只能笼统的说是基于 Geschaeftsfaelle 的测试。面向的更多的是客户或用户。和底层研发还是有区别的。也因此涉及的系统很多。在哪个领域并不是决定性的，凡是涉及很多 IT 系统的，测试时候都有着同样的以上所说的测试环境问题。 本帖最后由 nomel 于 2013-9-18 20:21 编辑
{:2_226:} 本帖最后由 fatdolphin 于 2013-9-18 23:26 编辑
不知道我有没有理解lz的意思，感觉lz这个要求有点网络管理的意思，就是实时监测各个系统的运行情况以及指定端口是否有效。找找snmp相关的集成系统吧，比如nagios。 fatdolphin 发表于 2013-9-18 23:24
不知道我有没有理解lz的意思，感觉lz这个要求有点网络管理的意思，就是实时监测各个系统的运行情况以及指定 ...
对于网络监控或者网络管理来说 nagios 确实是很好的选择。
对于测试环境的管理，监控端口只是其中的一个手段，然而因为系统的复杂性和多样性，很多情况下是无法实现监控端口的，我只是举了一个例子来实现监控系统是否 verfuegbar 。也有很多其他情况，比如负责系统的人或者机器按时按量发送系统 downtime 的提示，或者针对不同系统随时开的有可能 blockieren 掉系统的 ticket，或者还有不为人知的由于某种原因系统 nicht verfuegbar 的情况（比如被监控到的，或者被每天的 Antest / 计划的 regressiontest / 不定时的 ad hoc test 等发现的），被发现后，如何能及时让所有人用特定方式知道相关信息，等等。我指的测试环境管理，重点是对各方面环境信息的管理和信息发布的及时性的实现。
ok,总结一下你的需求
1 随时监控系统和相应端口的情况
2 支持ticket系统， 此处包括machine/application/system owner发布的downtime以及人工发现的system down。
3 ticket系统支持自动request和自动handling
如果只是这些的话，nagios有好多插件支持，比如Nagios XI，另外nagios不少插件都是开源的，可以进行2次开发 the non-deterministic Tests should be eradicated. 这种跨系统的测试要做到完完全全就根本不可能。 适当能过得去就行了，任何事情务必不要追求完美，那可太苦了自己。 雪候鸟 发表于 2013-9-19 22:14
这种跨系统的测试要做到完完全全就根本不可能。 适当能过得去就行了，任何事情务必不要追求完美，那可太苦 ...
测试如果是基于 business case 的话，测试还是可以达到百分之百覆盖率的，不是太辛苦了自己，而是公司这么要求的。测试环境管理好的话，就能让测试的人工作更有效率，进而不那么辛苦。 本帖最后由 ljrky 于 2013-9-20 09:43 编辑
一个比较取巧的办法是获得开发人员的帮助,通过调用系统的API来准备测试数据. 比如说根据需要生成某种类型的账户,最方便的办法是直接对数据库的值进行操作. 不过这样的做法和做一个mock没有特别大的区别,在有很多外围系统的情况下,这种做法需要考虑到开发这类工具的投资回报. 本帖最后由 saarchinese 于 2013-9-20 10:42 编辑
ljrky 发表于 2013-9-20 09:41
一个比较取巧的办法是获得开发人员的帮助,通过调用系统的API来准备测试数据. 比如说根据需要生成某种类型的 ...
我们这里有专门负责生成测试数据的组，比如生成特定客户，设定特定资源等等。这是测试领域的另外一个 Thema：测试数据。经常遇到的问题就是测试数据本身有问题或者不符合测试的要求，也会造成同样的测试质量不高，测试拖延的问题。我这里主要想就测试环境的管理和监控进行讨论。看看有没有什么好的软件支持。
另外，针对你说的 mock 方法，就涉及到测试层次的问题，如果底层的 integration 就需要 stubs 和 drivers，软件的话通常用所谓的 simulator 完成，如果高层 integraion，基本完成后就进 produktion 的话，就必须全部要用真实的系统了，有时甚至测试数据都要用 produktion 的（根据保密条款，是需要预处理一下的）。
页:
[1]