51Testing软件测试论坛

标题: 测试人员如何快速掌握被测软件业务流程？（2010-1-27）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2010-1-27 10:29
标题: 测试人员如何快速掌握被测软件业务流程？（2010-1-27）（获奖名单已公布）
测试人员如何快速掌握被测软件业务流程?

此话题由会员mihuxu520提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	shine2001	50元手机话费充值卡	6#

作者: keevinl 时间: 2010-1-27 10:46
先坐一下，楼下说

作者: keevinl 时间: 2010-1-27 10:48
1.先大致看一下,业务流程以及业务需求说明书.
2.通过功能测试用例,简单的跑一下被测软件
3.再次温习业务流程及业务需求说明书

作者: liping4186 时间: 2010-1-27 11:19
顶楼上，首先可以通过文档，比如需求说明书、策划案，有用户手册最好了，用户手册对客户有一个指引作用，可以让我们了解项目的框架以及大概的流程，其次可以通过执行别人写的测试用例，测试用例对于每个流程都应该是写的很清楚

作者: myklin 时间: 2010-1-27 13:52
顶楼上
回楼主：你说的应该是新入职测试，或者从其它组借调过来的测试人员吧，
一般情况下测试人员从需求、设计评审就已经介入了，等软件做出来，测试人员对整个软件业务流程就应该已经很熟悉了

作者: shine2001 时间: 2010-1-27 16:16
被测软件的业务流程是开展测试工作的重要准备活动，同时在测试过程中起到十分重要的参考和分析依据作用

这个问题很简单但是又很难。简单是因为软件业务流程可以顺藤摸瓜，难是因为不知从何入手

“被测软件”听起来有点大，被测软件的行业背景、软件的大体作用，总的框架结构这些“大”方面的信息比较容易获取和理解。实际上软件是由众多功能组成的，在实际工作中，功能模块的业务流程对测试起到了直接的指导和参考作用（例如测试用例的编写，测试结果的分析等等），不掌握业务流程则不足以很好的测试

测试人员想要获悉软件功能模块的业务流程，就必然要牵涉到开发人员，也就是要涉及到开发与测试的接口
这个问题想要解决，有很大程度要依赖于测试与开发的合作。开发测试体系是否规范和健全非常影响这一结合点乃至影响整个测试的流程。不同的公司，不同的项目，甚至同一个公司不同的项目组在这个方面都可能存在很大的偏差，这个问题是无法逃避的。

我在论坛中，在QQ群中经常看到某某项目，什么资料都没有，什么会议都没参加，就让我们测试，我们怎么测试啊。偶尔也能看到有的项目从需求、从设计阶段测试人员就介入了进来，从而测试人员测试的时候非常顺畅，流程进展的也比较顺利。

这两种情况简单的总结一下就是测试人员的“知”与“不知”，“早知”与“晚知”
当测试人员遇到“一穷二白”（什么都不知道，什么材料都没有）的情况时，这就是“不知”
如何应对这种情况呢？首先请务必不能抱怨，在你抱怨的同时其实也伤害了你自己。
我常常对新人说，站起来，不要老是坐在位置上。不要依赖于outlook，聊天工具，电话。
请务必现场找到这个软件功能模块涉及的开发人员，最好能够找到一个“头”（也可以由你的头找到他们的头），OK，下面就是真人PK，刚开始这很折磨人，你什么都不知道，但是你必须得问，一定要把某个点弄明白（例如功能模块中的某个程序是做什么的，这个功能模块是谁谁谁负责，这个功能模块涉及到了界面、数据库），找到这个点就可以顺藤摸瓜，把所有涉及的开发人员问个遍（有条件的话，可以所有涉及的人员坐下来探讨一下，对测试人员对开发人员都有好处，要知道负责不同功能的开发人员很可能对项目的其他开发人员负责的部分一窍不通，对整个业务也是糊里糊涂）。沟通的同时要记得互惠互利，你知道的，也要告诉不知道的人，在你以后的沟通交流生涯中，形成一种良性的互惠活动，而非一味的索取答案。

通过良性的循环，使得测试人员从“不知”变为“晚知”
当然“晚知”相对于“早知”花费的气力和代价大很多，但这恰恰是很多人遇到的情况，不得不面对
对于有着良好的开发测试流程体系的团队来说，则要幸福很多，可以“早知”
但是也不要放松自己，因为“早知”不代表你“明知”（正确明白的知道）。
在测试过程中，随着测试的覆盖和深入，必然引发各种问题和疑问，需要去判断和分析。这个时候依然需要测试人员和开发人员协力合作，促成双方对业务流程、功能细节、原始需求等方面的加深理解

当开发与测试团队互相配合，互相信任时，管理和流程上的不足的影响也会被弱化，测试和开发之间的“瓶塞”会被淡化。对于一般的测试人员而言，请不要轻易对种种不完善，不好，不行做出负面评价。因为这对于大家而言没有好处，也无法改变现状，不是吗？！

作者: Jackc 时间: 2010-1-27 17:23
顶顶LS, 说的很实在。

看需求规范谁都知道，可惜在神奇的土地上，只有少部分公司才有需求规范滴~

作者: 菜也快乐着 时间: 2010-1-28 19:08
顶楼上的，要是文档都那么规范，我想提问题的就不用这么头疼了吧。

作者: 讨厌鬼 时间: 2010-1-28 21:32
根据分析文档说明，了解业务流程。或者问业务人员进行了解....

作者: zhang1987yuan 时间: 2010-1-29 08:35
标题: 小公司全靠自己领悟，那来个啥子需求文档以及各种说明啊。
小公司全靠自己领悟，那来个啥子需求文档以及各种说明啊。

作者: keevinl 时间: 2010-1-29 09:01
查看软件流程图

作者: winnertesting 时间: 2010-1-29 11:02
1、看该项目的需求规格说明书；
2、询问老员工软件的流程和爱出错的地方；
3、自己实际使用此软件进行流程熟悉。

我总结就这几点，楼下继续阐述！

作者: shine2001 时间: 2010-1-29 11:05
树是死的，人是活的
要掌握业务是没有捷径的，唯一的捷径就是勤奋
条件是人创造的，规范是人制定的，过程是人改进的
从无到有离不开刻苦，勤奋，努力，坚持

同样的事情，同样的做法，同样的过程，人与人之间是有差别的
有的人聪明，悟性高，一模一样的做法也会事半功倍
有的人底子弱，一模一样的做法却事倍功半
方法一样，过程一样，有人快有人慢，不可比也

因此，与其说如何快速掌握，不如说如何找到学习方法，如何找到“致富”的路
条件再好（资料，规范，流程齐全）也是人创造的
条件再好也需要人去利用才能发挥条件的价值

以不变（求知，求学，进取的心）应万变，万法归一

作者: shine2001 时间: 2010-1-29 11:07
阿弥陀佛，一激动，我唐僧了

作者: Carina_yan 时间: 2010-1-29 14:06
如果没有较好的文档的话，个人觉得最好的办法就是沟通。多和产品、开发人员聊聊，从他们的嘴中挖些自己想要的东西。

作者: dumb_dora 时间: 2010-1-29 14:46
觉得还是沟通重要，运气好的能够遇到一个好的需求，一个好相处的开发，可万一运气不好呢，就不能说不去沟通了吧
另外，参考市场上的同类产品的功能也觉得是个不错的办法哦，有助于理解被测软件的业务流程

作者: test_fairy 时间: 2010-1-29 15:14
目前正在为了更好地明白软件而进行专业方面的学习，所以也就此发表一下自己的看法：
正如楼上各位所说的那样：
1、最好是能得到一个好的测试需求，这样就可以省去你自己做需求的过程，而通过这个好的需求你还可以更好地把握系统本身，为将来的测试提供一个好的帮助；
2、比较明白和细致的开发人员，这个有助于你在遇到问题的时候寻求帮助，减少开发人员和测试人员之间不必要的冲突，因为就像测试与开发之间的关系说的不好听点有些类似于警察与小偷之间的关系，有冲突是必然的，你净找人家的麻烦任何人都不会舒服的，大家说呢？！
3、提供比较完善的用户帮助手册，这样即使是你没有使用过该软件也可通过流程来熟练自己的操作，但是也只是了解和熟练而已。
4、我要说的比较关键的一点就是：必须了解相关的业务。是的，就是相关的业务。
有很多的业务不是简单地用一个流程就可以看明白和操作明白的，他背后有强大的理论支撑，作为一个测试人员，如果单单去根据手册跑完流程是简单的，但是我相信，这样的测试肯定是不完全的，其中可能隐含的原则性问题你肯定也将发现不了，因为你不了解业务，你只能从别人给你的一点点东西中来寻找错误，那么如果所给你的东西本身就是个错误哪，你又会怎么办呢？
举个例子，这个也是我曾经遇到的事情，建设银行的U盾，大家都知道银行的U盾有密码，并且只能在使用的时候一次实验10次，然后就会锁定，大家肯定说这有什么稀奇，但是大家不知道的是，以前建行的U盾在实验10次以后就报废掉，因为它的密码是不能被重置的，这个估计曾经对建行U盾做过测试的人员没有想到的吧，但是这个却是事实，因为这是硬件本身的问题，同时也是软件的问题。
5、所以说要想快速掌握被测试软件业务流程，不能仅仅从上面几个方面来把握，入手可以，但是把握还是不够，我们还必须在长期的工作过程中了解业务流程背后的东西，有了足够的理论作指导，将来在把握起被测试软件的流程上才能更快速，更准确，更全面。
不知道大家是不是这么想的

作者: gemingshamo 时间: 2010-1-29 15:43
画流程图给人讲解

作者: yj_fx 时间: 2010-1-29 16:48
标题: 回复 13# 的帖子
顶你，说的很好

作者: herah 时间: 2010-1-30 00:14

原帖由 test_fairy 于 2010-1-29 15:14 发表
目前正在为了更好地明白软件而进行专业方面的学习，所以也就此发表一下自己的看法：
正如楼上各位所说的那样：
1、最好是能得到一个好的测试需求，这样就可以省去你自己做需求的过程，而通过这个好的需求你还可以更 ...

说的挺不错的

作者: shine2001 时间: 2010-1-30 11:00
LS的请仔细看我的内容中提到了原始需求，也提到了提交（各种资源）
我并不是说依赖于开发人员，但是请不要脱离现实
不要把什么事情都想的那么理想，你想要流程图就给你流程图
想要客户需求，就一定有客户需求

如果这些东西都有，那么哪来的这个问题呢？
我想正是因为缺乏这些条件，才提出了这样的疑问

如果是一个有着比较正规流程的公司，我想在工作中应该是可以比较好的接触到这些东西的
同时也可能会有人指点你如何去做事情

而对于很多人而言，他们在做测试时根本就找不到需求
这听起来很荒唐，但是事实的确如此。有可能一个新的功能就是领导的一句话，一个想法
有可能是用户的一个抱怨。软件是一点一点做起来的，按照道理，应该具备逐渐积累和深入了解需求的条件。但是这个事情是需要人去做的，关键是，谁去做？如果有人去做，那我只需要找这个人获取条件就可以了。如果没人做呢？或者说，如果相关资源几乎都集中在开发部门或者信息资源没有产出呢？（我在论坛、各个群中经常遇到这样的情况。），我们不能不谈理论，但是我们必须要将理论结合实际来进行运用

作者: shine2001 时间: 2010-1-30 11:01
上文“也提到了提交” 为“也提到了条件”，宝宝在旁边骚扰，不好意思

作者: shine2001 时间: 2010-1-30 11:22
我再以自己做一个典型的坏例子

我们很多的开发人员，工程人员，客户技术支持人员，客服人员
他们很多人对业务流程都不熟悉。
我作为一个测试人员，经常被他们光顾
这听起来很不可思议
开发人员会问我这个功能是干什么的啊？怎么测试啊
工程人员会问，这个功能为什么要这么装啊？干什么用的啊？怎么检查啊？
客户技术支持人员会问这个功能的实现的原理是什么？为什么这么设计？
客服人员会问，某某用户的需求有没有实现啊？某个问题你帮我看看确认下啊？

这些问题难不倒我，虽然我没有流程图，没有原始需求说明，没有设计文档
但我依然活的很好，也让他们大多时候都能够满意而归

于是，渐渐的产生了某某某综合依赖症，渐渐的我吃不消了
由于我以往的表现使得我现在站在了一定的高度了，于是我开始思考并行动，不能在这样下去了，必须要改变现状，于是一群狼坐在一起开始讨价还价。最后呈现在大家面前的就是流程的改进，制度的规范等等变化

作者: shine2001 时间: 2010-1-30 11:23
标题: 回复 24# 的帖子
看看上面的，是依赖吗？
请不要把团队合作理解为“依赖”

作者: shine2001 时间: 2010-1-30 11:26
每一个“新生儿”都需要团队的力量去抚育使其成长
在一段时间内，“新生儿”们不得不依赖他们的衣食父母，但是终有一天，他们会长大
会为整个“家庭”付出回报并贡献自己的力量

作者: shine2001 时间: 2010-1-30 11:30
封笔，谢谢。
也请大家多提提看法，为我们的提问人员给予可能的帮助

作者: msnshow 时间: 2010-1-31 09:52
标题: 这个话题很好！
这个话题很好，快速掌握被测软件业务流程，在大多数开发流程不是很正规的公司或外包公司都是需要的
1、外包公司
特点：有较完善的文档

办法：
>1、让开发人员做产品介绍
>2、从文档下手；
>3、另外测试人员也需要提高自己的理解能力（如在空闲时间掌握同行业类似软件的业务流程之类的）

2、不正规的公司
特点：没有完善的文档，可能连需求都不太完善

办法：
>1、让开发人员做产品介绍（需求方、开发、测试人员一起参与）
>2、靠经验（了解同行业类似软件的业务流程）

作者: mitutu 时间: 2010-1-31 17:33
标题: 关于掌握业务流程的一点浅见
工作也快一年了，个人感觉对于测试行业本身来说，熟悉业务和掌握技术是五五分的关系。但熟悉业务最好先行，对症下药往往见效很快。要如何才能掌握好业务流程呢？有以下几点比较重要：
一了解主体的业务框架，不必追求分支细节。先对总体业务有一个印象，知道一些概念性的东西，混个面熟；
二了解为什么要有这个业务，最原始的需求来自于哪里。可以跳出当前的这个业务流程思维，考虑下最源头的业务驱动，原本这个业务是解决一个或者一类什么问题的。这样也算是有的放矢了。
三站在用户或业务需求本身的角度来理解分支细节。这个时候可以充分发挥我们的想象力去理解这些东东，也可以找一个熟悉这块业务或类似业务的同事来聊聊，或许会有很多意外的收获。
四将分支和主干全部都串起来，一体化思考整个业务流程。重新梳理你对整个业务流程的理解，如果还有不通的地方，可以再次去求证。这个时候你对业务可能就不再仅仅是理解，或许你还可以发现其中不合理的地方，一切皆有可能。
另外，不要把自己限制在测试人员的角色里，在熟悉和理解业务的时候，需要从多个维度去思考问题，比如：从需求方的角度去考虑业务本身的价值走向；从开发的角度去推断业务的逻辑构架；从测试的角度去分析业务的合理和完整性；从用户的角度去体验业务的易用性。

作者: fangfangcome 时间: 2010-2-1 16:00
我都是直接去问老大......多交流交流才能捕获更多书面上没有的东西

作者: carol_wen 时间: 2010-2-2 14:41
标题: 回复 6# 的帖子
说得太棒了
小公司就是这样，需求、设计什么都没有。。。
以前也没有测试，对于整个公司测试都是后加进来的。。。
两眼一抹黑。。。啥也不知道……

作者: carol_wen 时间: 2010-2-2 14:58
标题: 回复 25# 的帖子
“这些问题难不倒我，虽然我没有流程图，没有原始需求说明，没有设计文档
但我依然活的很好，也让他们大多时候都能够满意而归”

您是如何做到的啊？？？请赐教~

作者: 夜魅 时间: 2010-2-3 08:26
顶，太强了

作者: juanyu1984 时间: 2010-2-3 10:47
标题: 顶
6楼说的，首先了解被测软件的行业背景及其作用，非常赞同，这个也非常重要，学习了

作者: chengning 时间: 2010-2-3 11:46

说的很好啊

作者: chengning 时间: 2010-2-3 12:50
1，在需求文档，设计文档等相当的规范的情况下，当然是先拿到文档后熟悉业务流程，一般在业务流程比较了解的情况下，公司会有开发做产品和技术的介绍，这样可以比较深入的了解开发的背景，以及一些技术的特点，也可以了解到测试的侧重点等等。。。
2，在没有详细的需求文档时，一般有2中情况，一种是有设计文档，看以先看看设计文档，熟悉业务的流程图，这样的话测试人员要花比较多的时间在流程上，希望在开发讲解产品和技术介绍之前，能够补上没有需求文档带来的业务不熟悉。。。。
第2种情况是既没有需求文档也没有设计的详细文档，那个人建议多和开发沟通，不懂，不清楚的都只有找开发口传需求了，这样估计效率不叫低，
3需求一直变？那最好的办法是多和开发，需求设计人员沟通吧，沟通在没有详细的文档的时候是最有效的了，
4开发部好沟通。。。。。。。。事情不好做哦

作者: liujinqi 时间: 2010-2-3 15:27
冒个泡，说点好操作的～～
1、不建议找需求～（主要是原始需求或包需求给了你，也没啥太大帮助，太粗了～），如果公司有规格，去参看一下规格还是可以的；（优先级低）
2、先请项目经理或其他有经验的老员工挑选出一些典型的不太复杂的用例，执行上1周左右～，期间参考一些项目文档（可以是一些开发文档，或测试部以前的一些总结文档）。（优先级中）
3、多向有经验的人（也可以是你们老大）请教，最好定期（推荐双日）组织一下技术交流或业务交流，互相讨论或请熟悉的人培训一下，见效最快，也好操作（当然这个要看公司或部门的文化和氛围了～～，如果知识共享不是那么顺畅，这个也就白搭了～）（优先级高）

作者: 白袍大法mm 时间: 2010-2-3 21:58
我还没毕业，说点小小的看法，抛个转。

我认为这个问题应该分几种情况来对待吧。
1. 目前该软件的业务已经比较成熟稳定了，例如像CRM，ERP这样的软件，但对于个人来说完全不熟悉的这种情况，就很容易解决。例如用百度，Google，直接看说明书，甚至直接问用过的朋友或者同事就能了解的差不多了。
2.目前该类软件还处在探索阶段，市场上的版本基本稳定，核心功能基本差不多。这种情况如果有需求就很好解决，百度+查看SRS就OK了。
3.如果该软件只是为某个客户定制的，且完全是创新来的，市场上完全找不到相关软件来参考。这种情况主要要靠个人能力和知识的积累了，如果没有明确的SRS,想要快速了解业务估计只能跟客户或者需求分析人员多多沟通了，或者直接把自己当做该软件的用户来充分发挥你的想象力了。

作者: diewuyezi 时间: 2010-2-4 16:29
软件开发会提供AR（用户需求）可能还会提供低保真如ppt、图形界面，高保真如html文件。我们可以通过低保真或高保真结合需求文档来更快的熟悉业务

作者: liangxianquan85 时间: 2010-2-7 11:35
顶6#的哥们，说得太好了

学习了

作者: baileyqw 时间: 2010-2-8 11:12
测试人员加入项目需求过程，同时作为需求分析人员可能能够在项目早期尽早的进入项目角色，跟踪需求变化；同时也可以为开发人员提供需求明确方面的辅助。

作者: majun915 时间: 2010-2-8 14:20
6楼说的太好了呵呵学习学习

作者: parater 时间: 2010-2-23 19:19
说的太复杂，我觉得：

1.缠着开发教操作

2.缠着懂的测试人员教

3.前面2点缠够了，自己研究需求，研究透

作者: joyjjjz 时间: 2010-2-25 22:06
讨论的真精彩

作者: xiaoking 时间: 2010-2-26 13:16
标题: 回复 6# 的帖子
看了很受用，谢谢谢谢
个人觉得，作为新人还可以多看看已有的测试用例比看需求、设计有效的多...

作者: msnshow 时间: 2010-4-26 13:44
沟通的重要性

作者: zwb131442 时间: 2011-2-25 16:05
回复 6# shine2001

专业

作者: moonylts 时间: 2011-3-4 16:44
本帖最后由 moonylts 于 2011-3-4 16:50 编辑

我再以自己做一个典型的坏例子
我们很多的开发人员，工程人员，客户技术支持人员，客服人员
他们很多人 ...
shine2001 发表于 2010-1-30 11:22

这个和我现在在做的这个项目的测试是一样的，我都愁坏了，凡事都要问测试，好像我们是做需求的、是设计系统的、是具体编码的、是具体实施的、是给客户服务的；
目前我也处于讨论流程的阶段，但是新来这个公司不到一年，公司也才开始逐渐重视测试，讨论来讨论去，最后只能自己表面全力做测试，实际还是各式各样的活都干....

不过事情总是多方面的，在帮助其他岗位的同时，自己好像也经历了多个岗位的锻炼一样，另外，站在不同的角度看我们的软件和系统，有不同的收获和感受，对于我们测试来说也是有一点好处的；唯一不太爽的事是，明明承担了很多很多工作，还有其他人说，测试闲的无聊...哎！

路漫漫其修远兮吾将上下而求索``

作者: feifei956998 时间: 2011-5-30 20:02

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)