5,179
社区成员
发帖
与我相关
我的任务
分享[自动化测试策略]请问有没有人做过针对工作流软件的自动化测试的设计？
我现在做一个工作流软件项目的测试工作，目前需要实现自动化，但是由于工作流软件本身的特质，每个用例之间前后依赖关系很紧密，测试数据独立的话会很费事，但是不独立，又不符合自动化测试一个用例检查一个输出的原则，不知道各位有没有好的经验讨论分享一下，谢谢！
本来是计划按照一般的逻辑先auto 优先级最高的case,但是优先级最高的case恰恰是前后逻辑最复杂关联最多的case,而且自动化跑这些case发现bug可能性也不太大。
我的想法是想尝试针对工作流软件的这种特性，先auto优先级低的简单的case,利用automation 提高test coverage, 而优先级高的case仍然依赖手工测试保证不miss bug。
不知各位有何高见，望不吝赐教！
本来是计划按照一般的逻辑先auto 优先级最高的case,但是优先级最高的case恰恰是前后逻辑最复杂关联最多的case,而且自动化跑这些case发现bug可能性也不太大。
我的想法是想尝试针对工作流软件的这种特性，先auto优先级低的简单的case,利用automation 提高test coverage, 而优先级高的case仍然依赖手工测试保证不miss bug。
不知各位有何高见，望不吝赐教！
...全文
请发表友善的回复…
发表回复
melon_xyj 2010-06-22
- 打赏
- 举报
不能顺利写出自动化测试程序，纯粹是pm在测试自动化方面的技术比较差（没有经验）造成的
自动测试程序可以永不停歇地随机抽取测试用例来反复测试，
如果你习惯于TDD（测试驱动）开发，根本不会去区分什么大项目、小项目
赞。向sp1234学习！！！
自动测试程序可以永不停歇地随机抽取测试用例来反复测试，
如果你习惯于TDD（测试驱动）开发，根本不会去区分什么大项目、小项目
赞。向sp1234学习！！！
cxy821228 2010-06-02
- 打赏
- 举报
路过，学习了。
bigsir 2010-05-26
- 打赏
- 举报
感谢翻出来的大侠，找很久这方面的分析了，建议sp1234多写写。
码农天天向上 2010-05-19
- 打赏
- 举报
好贴！
syjchyx 2010-05-18
- 打赏
- 举报
严重收藏
helloan 2009-04-24
- 打赏
- 举报
支持sp1234,自动化测试工具很诱人，但实际应用是很难实现的，而具也只会让测试崩溃。
以专业开发人员为伍 2009-02-15
- 打赏
- 举报
可以说，这是一个“新”技术，而且目前国内市场上大多数入门书本上都是抄袭15年前过时的概念和方法介绍。
以专业开发人员为伍 2009-02-15
- 打赏
- 举报
自动化测试对敏捷开发至关重要，可以说是本质特性。
如果你仅仅是对10年之前或者更古老一些的测试书籍上的自动化测试概念有所了解，那么就很难真正进行深入的自动化测试实践。那类过时的书本上，测试是软件开发出来之后的一个动作，就好像砌墙的民工不是一边砌墙一边注意拉好水平准线，而是随意地砌墙然后才测试砖码得是否整齐，甚至如果自己轻推一下墙不倒塌就认为没有再测试的必要了。
以我每天运行成千上万测试用例的经验来看，如果你习惯于TDD（测试驱动）开发，根本不会去区分什么大项目、小项目（学生的练习作品除外），如果你对一个产品事后进行全面的自动化测试很在行，那么你也会自然而然地在编码前就预先开发测试程序。反之，如果仅仅在编码之后蜻蜓点水地尝试摸一摸自动化测试的门槛，你的项目无法在实际操作上敏捷开发，而仅能“口头上”搬弄敏捷开发的理论。
如果你仅仅是对10年之前或者更古老一些的测试书籍上的自动化测试概念有所了解，那么就很难真正进行深入的自动化测试实践。那类过时的书本上，测试是软件开发出来之后的一个动作，就好像砌墙的民工不是一边砌墙一边注意拉好水平准线，而是随意地砌墙然后才测试砖码得是否整齐，甚至如果自己轻推一下墙不倒塌就认为没有再测试的必要了。
以我每天运行成千上万测试用例的经验来看，如果你习惯于TDD（测试驱动）开发，根本不会去区分什么大项目、小项目（学生的练习作品除外），如果你对一个产品事后进行全面的自动化测试很在行，那么你也会自然而然地在编码前就预先开发测试程序。反之，如果仅仅在编码之后蜻蜓点水地尝试摸一摸自动化测试的门槛，你的项目无法在实际操作上敏捷开发，而仅能“口头上”搬弄敏捷开发的理论。
Iris 2009-02-13
- 打赏
- 举报
如果是产品型的软件，可以考虑自动化测试去实现
项目型的软件，成本上不划算
项目型的软件，成本上不划算
Iris 2009-02-13
- 打赏
- 举报
davy 的说法比较赞同
shen_pl 2009-02-06
- 打赏
- 举报
各有利弊
以专业开发人员为伍 2009-01-31
- 打赏
- 举报
与手工测试测试用例不同，自动化测试的大多数测试用例是系统集成测试，即既不是白盒也不是黑盒的所谓“灰盒测试”。同时，自动化测试往往是随机产生测试数据（例如从数据库搜索出随机记录产生测试数据），并且假设有2000个测试用例，自动测试程序可以永不停歇地随机抽取测试用例来反复测试，也就是说每天可以将这2000个测试用例运行很多很多遍，而每一次的自动生成的测试数据都比较随机不同。最为关键的，自动化测试目的就是非常轻松地随时进行回归，而2000个测试用例让手动测试人员回归一次则是很困难的。
最后，有着多个交互步骤的复杂 UI 的测试用例（而不是调用一个功能然后就核对结果），也是可以自动化测试的。
最后，有着多个交互步骤的复杂 UI 的测试用例（而不是调用一个功能然后就核对结果），也是可以自动化测试的。
sitnc 2009-01-15
- 打赏
- 举报
自动化测试如果见效不大，大多和公司内缺少对自动化测试了解的上层领导人有关，可以想想一个根本不了解自动化测试的人又怎么能制定行之有效的自动化测试开发和测试策略，往往是南辕北辙，乱出主意
以专业开发人员为伍 2009-01-13
- 打赏
- 举报
说到底，自动化测试是一个技术要求稍微高一些的技术，所以我根据自己的共事过的经历，我可以说一个微软项目组或者一个很大的用户的项目，其测试经理对自动化测试的了解程度跟一些小公司比不一定就对实际方法了解的多。也就是说，这是一个空谈很多的领域。
以专业开发人员为伍 2009-01-13
- 打赏
- 举报
我所参与过的项目，手工测试背书最多的，在TD上有将近3000个测试用例。我可以说，这些基本上都可以自动化（一般来说，编写一个需要我上面所说的3、4个步骤的测试程序，大概需要30分钟左右）。
不能顺利写出自动化测试程序，纯粹是pm在测试自动化方面的技术比较差（没有经验）造成的故意强调“自动化测试无用论”，或者例如因为没有从一开始就招聘懂这方面编程的程序员（例如80个程序员中估计只有2、3个人有少量编写自动化测试程序的经验）而造成的。
不能顺利写出自动化测试程序，纯粹是pm在测试自动化方面的技术比较差（没有经验）造成的故意强调“自动化测试无用论”，或者例如因为没有从一开始就招聘懂这方面编程的程序员（例如80个程序员中估计只有2、3个人有少量编写自动化测试程序的经验）而造成的。
sitnc 2009-01-12
- 打赏
- 举报
自动化测试的主要目的是用来实现重复度高，劳动强度大的那部分Case，转化成自动化Case的原则应该是逻辑尽量简单，当然如果框架足够鲁棒的话一些相对复杂的Case也是可以覆盖的，但是，这些Case应该是针对自动化测试进行重新定义的，而不是直接转化传统的手工测试的Case，这样才能发挥出自动化测试的作用，提高其使用效率。此外，公司应该对自动化测试有个明确的定义，这样在设计自动化框架时才能准确。
以专业开发人员为伍 2009-01-05
- 打赏
- 举报
[Quote=引用楼主 mashenka123 的帖子:]
我现在做一个工作流软件项目的测试工作，目前需要实现自动化，但是由于工作流软件本身的特质，每个用例之间前后依赖关系很紧密，测试数据独立的话会很费事，但是不独立，又不符合自动化测试一个用例检查一个输出的原则，不知道各位有没有好的经验讨论分享一下，谢谢！
本来是计划按照一般的逻辑先auto 优先级最高的case,但是优先级最高的case恰恰是前后逻辑最复杂关联最多的case,而且自动化跑这些case发现bug可能性也不太大。
我的想法是想尝试针对工作流软件的这种特性，先auto优先级低的简单的case,利用automation 提高test coverage, 而优先级高的case仍然依赖手工测试保证不miss bug。
[/Quote]
自动化测试在不同的公司有不同的理解。我认为只有很精通软件开发，同时有着多年项目管理经验的人才能开发出自动化测试的简单的框架代码。也就是说，我怀疑你从来没有真正自己写过自动化测试引擎，大概最多是从网上下载或者看书。市面上没有什么通用的万能自动化测试引擎（也没有什么通俗的专著给你具体的描述代码开发），例如一个银行开发各种重要的业务系统都是自己写测试程序而不是靠网上流行那些所谓自动化测试工具，所以，你不可能凭想象来讨论自动化测试理论，要找人家亲自写过自动化测试程序的人去学学去。
关于“符合自动化测试一个用例检查一个输出的原则”，我觉得这是一个错误。如果你在那本书或者论文中看到这个“原则”，把这个作者从善于进行自动化测试的人名单中删除掉吧。有很多小公司搞了一些自动化测试小软件放到网上卖钱，它们可能给你一些“范例”，其中可能只能很弱智地进行着各种最简单的测试，甚至只能测试一个简单的登录界面而根本不能测试软件中经典和复杂的交互操作界面，使用那些自动化测试软件只能当作一种简单的知识，骗骗那些想通过招聘一些懂自动化测试的人员的公司的不懂自动化测试的hr招聘人员（因为这个技术领域其实并没有真正实用而又万能的流行的工具，所以hr的那种考察方法往往并不能发现真正会在项目中实干的人，只会让项目找来更多喜欢讲理论和买别人的工具的人）。
对于交互式应用程序进行测试，即使测试一个小部件（而不是一个大画面），往往也需要3、4个步骤，第一个步骤之前可能需要准备好测试数据，第一个步骤则可能仅仅是装入部件设置最基本的初始值进行显示（要知道很多显示都是异步多线程的），然后第二个步骤才是在某些地方输入测试数据然后在某些地方点击，此时进入第三个驱动步骤来再对当前新的界面结果输入一些新的测试数据并且执行会让他进入第四个步骤的事件，第四个步骤再重复或者结束。在每一个步骤中，因为都是前一个步骤的显示结果，都可以插入断言随时判断当前步骤的情况。实际上，在每一个步骤中，也还可以从数据库中临时查询出符合一定条件的随机测试数据，只要这个数据按照原来的设计要求应该可以让程序正常地进入下一个测试步骤。
关于“优先级高低”的case，我因为测试很多，通常仅有可能测试最近72小时的Case。没有什么优先级，随机顺序。并且，通常需要自动反复运行很多遍才能出现bug，而不是仅运行一遍。有些人仅仅把单元测试（传统的红绿灯测试）当作自动化测试，我不这样看。当我只有10个case要运行，我会让它们以随机次序总共被执行40次，平均来说每一个case执行了4次，但是我认为这样才能估计每一个case至少执行过1次。我一般仅执行最近72小时的case，然后在中午吃饭或者晚上才回归所有的case。
我现在做一个工作流软件项目的测试工作，目前需要实现自动化，但是由于工作流软件本身的特质，每个用例之间前后依赖关系很紧密，测试数据独立的话会很费事，但是不独立，又不符合自动化测试一个用例检查一个输出的原则，不知道各位有没有好的经验讨论分享一下，谢谢！
本来是计划按照一般的逻辑先auto 优先级最高的case,但是优先级最高的case恰恰是前后逻辑最复杂关联最多的case,而且自动化跑这些case发现bug可能性也不太大。
我的想法是想尝试针对工作流软件的这种特性，先auto优先级低的简单的case,利用automation 提高test coverage, 而优先级高的case仍然依赖手工测试保证不miss bug。
[/Quote]
自动化测试在不同的公司有不同的理解。我认为只有很精通软件开发，同时有着多年项目管理经验的人才能开发出自动化测试的简单的框架代码。也就是说，我怀疑你从来没有真正自己写过自动化测试引擎，大概最多是从网上下载或者看书。市面上没有什么通用的万能自动化测试引擎（也没有什么通俗的专著给你具体的描述代码开发），例如一个银行开发各种重要的业务系统都是自己写测试程序而不是靠网上流行那些所谓自动化测试工具，所以，你不可能凭想象来讨论自动化测试理论，要找人家亲自写过自动化测试程序的人去学学去。
关于“符合自动化测试一个用例检查一个输出的原则”，我觉得这是一个错误。如果你在那本书或者论文中看到这个“原则”，把这个作者从善于进行自动化测试的人名单中删除掉吧。有很多小公司搞了一些自动化测试小软件放到网上卖钱，它们可能给你一些“范例”，其中可能只能很弱智地进行着各种最简单的测试，甚至只能测试一个简单的登录界面而根本不能测试软件中经典和复杂的交互操作界面，使用那些自动化测试软件只能当作一种简单的知识，骗骗那些想通过招聘一些懂自动化测试的人员的公司的不懂自动化测试的hr招聘人员（因为这个技术领域其实并没有真正实用而又万能的流行的工具，所以hr的那种考察方法往往并不能发现真正会在项目中实干的人，只会让项目找来更多喜欢讲理论和买别人的工具的人）。
对于交互式应用程序进行测试，即使测试一个小部件（而不是一个大画面），往往也需要3、4个步骤，第一个步骤之前可能需要准备好测试数据，第一个步骤则可能仅仅是装入部件设置最基本的初始值进行显示（要知道很多显示都是异步多线程的），然后第二个步骤才是在某些地方输入测试数据然后在某些地方点击，此时进入第三个驱动步骤来再对当前新的界面结果输入一些新的测试数据并且执行会让他进入第四个步骤的事件，第四个步骤再重复或者结束。在每一个步骤中，因为都是前一个步骤的显示结果，都可以插入断言随时判断当前步骤的情况。实际上，在每一个步骤中，也还可以从数据库中临时查询出符合一定条件的随机测试数据，只要这个数据按照原来的设计要求应该可以让程序正常地进入下一个测试步骤。
关于“优先级高低”的case，我因为测试很多，通常仅有可能测试最近72小时的Case。没有什么优先级，随机顺序。并且，通常需要自动反复运行很多遍才能出现bug，而不是仅运行一遍。有些人仅仅把单元测试（传统的红绿灯测试）当作自动化测试，我不这样看。当我只有10个case要运行，我会让它们以随机次序总共被执行40次，平均来说每一个case执行了4次，但是我认为这样才能估计每一个case至少执行过1次。我一般仅执行最近72小时的case，然后在中午吃饭或者晚上才回归所有的case。
davy_chen 2009-01-05
- 打赏
- 举报
1、何谓自动化，就是能够自动做一系列事情，因此完成有一定关联，有前后依赖的任务对于自动化测试而言没有什么不合适；
2、一个用例检查一个输出的原则，是针对于用例在特定环境下的原则，非自动化测试的原则，不要混淆，自动化完全可以实现一系列的多项检查；
3、自动化跑case的主要目的在回归测试中不是发现bug，而是提高测试效率，节省人力成本，因此认为发现bug可能性不大的自动化没有意义是错误的；
4、case优先级高低不影响是否使用自动化，影响是用自动化还是手工，主要是投入产出比，哪个更合算，更能满足要求，就用哪个。
2、一个用例检查一个输出的原则，是针对于用例在特定环境下的原则，非自动化测试的原则，不要混淆，自动化完全可以实现一系列的多项检查；
3、自动化跑case的主要目的在回归测试中不是发现bug，而是提高测试效率，节省人力成本，因此认为发现bug可能性不大的自动化没有意义是错误的；
4、case优先级高低不影响是否使用自动化，影响是用自动化还是手工，主要是投入产出比，哪个更合算，更能满足要求，就用哪个。
