- 论坛徽章:
- 59
|
本帖最后由 renxiao2003 于 2021-04-11 19:41 编辑
沙发坐起。
1.敏捷开发过程中开展自动化测试的先决条件有哪些?
CSDN观点1(针对普通自动化测试):
a、 自动化测试是长期的,只有长期的,多次重复的测试才能发挥自动化测试的作用。
b、 要有足够的资源,包括人员和技能。保证脚本的开发和维护。
c、 确保软件的成熟稳定。
CSDN观点2(针对敏捷下的自动化测试):
a、对于自动化工程师的要求更高,除了解决种种突发异常的自动化技能以外,还需要对项目的业务知识有比较多的了解。
在敏捷模式中,文档不会像传统的模式中那样完备,测试的case可能会相对简易,不少内容都只是口口相传,敏捷团队的成员也不可能专门派一个人出来辅助自动化工程师解决业务问题,那么就要求自动化工程师对于业务知识比较了解了,就算对项目了解有限,但至少要有背景知识,大多数情况下能理解一句话中所包含甚至是隐含的一系列业务操作。
b、项目成员结构上,自动化工程师需要成为敏捷团队的一员,而不是编外人士。理由很简单,敏捷团队经常会召开类似头脑风暴的会议,一个短暂而激烈的会议足以决定一个变更,然后大家立马投入工作中。这时自动化工程师若作为编外人士,那很可能就得不到这第一手的消息了,很可能吭哧吭哧好不容易码完的脚本还没跑过就得改了。
c、对于项目、产品的要求。被测系统必须是非常适合自动化的,在自动化脚本开发过程中不应当遇到被某个技术实现难倒的问题,敏捷模式下是没可能有几天甚至一周的时间去处理某个自动化的技术细节的。这就需要在接受项目前做自动化可行性评估的时候考虑周全,是否有某些核心的功能无法被自动化,可以接受多少功能不被自动化。
另外各story间不能有太强的依赖,因为很可能自动化工程师无法完成对所有功能的自动化,而一个story的需求变更也不应导致其它story有太多变化。
d、对于BA的要求。BA需要对产品的主要功能非常了解,非常清楚哪些功能是不太会变更,而哪些部分是不太有把握的,同时对客户也要有一定的掌控能力。这样除了提供主要的测试点以外,还能结合变更来给同为最高级别的测试点附加上自动化优先级,在很大的程度上避免自动化工程师的重复劳动。
总的来说,要实施自动化,对团队的成员素质要求非常高,也要求成员间的配合比较默契。说实话,真的很难,但并不是不可实现。
51testing观点:
1)软件需求变动不频繁。
进行测试时能发现Bug可以提高测试人员的自信心。在自动化测试的执行过程中,如果被测软件不稳定,可能会导致自动化测试失败,出现崩溃性错误,这会极大地打击自动化测试执行人员的自信心。
2)项目周期足够长。
这一点我们在前面已经讨论过了,此处不再赘述。
3)产品结构相对复杂。
对于产品结构相对复杂的软件建议采用自动化测试。
4)资源投入相对充裕。
对于人力及财力资源相对充足的项目使用自动化测试。
5)测试时间相对长,且存在大量需要执行回归测试的软件项目。
对于整个项目周期较短的测试,使用自动化测试会入不敷出。
6)待测软件系统界面基本稳定,没有较大的功能上的更改。
一定要等到待测软件系统界面基本稳定时,才能使用自动化测试工具进行功能、性能等测试。
2.敏捷测试中的分层自动化测试如何开展?
CSDN观点1(针对普通自动化测试):
a、 选取适合的项目
b、 选取适当的时间,太早软件不成熟,变化太多,太晚影响项目进度。
c、 选择合适的测试人员
d、 做好成本预算
CSDN观点2(针对敏捷下的自动化测试):
a、需求,需求通常来自于PM,在一个release周期的开始,QA通常没太多事情需要做,比较重要的工作就是跟PM沟通当前feature的一些情况,在这个时候,QA可以做一些自动化测试的准备。例如在某个release里面我知道在接下来的测试当中我需要频繁地比较CSV文件,那么作为QA就应该在项目还不是很紧张的时候就开支准备自动化测试的脚本,例如刚才说的这个CSV文件比较工作
b、开始开发,如果公司是实时TDD开发,那么这个时候QA可以做的事情大概有2个,帮助开发写单元测试用例,并且实施自动化测试(主要是单元测试),另一个是review(虽然不是自动化测试的内容)
c、正式提交测试,OK,这个时候是我们QA比较忙的时候了,这时候很有可能出现几个情况,1. 跟我的预想一样,我真的需要一个CSV文件比较工作,并且只需要这一个工具,并且我已经完成了,那么就可以进行测试了。2. 可能有一些新的自动化测试需求跑出来了,例如每天晚上自动比较几万个CSV文件并且把测试结果发给相关的人,这时候作为QA,在考虑资源允许的情况下,应该尽早完成这个工具,而不是每天晚上爬起来看结果并非法邮件
c、发布完毕以后,回过头来看工具,是否有值得改进的地方,是否能够改进一下就能够给整个Team使用
3.自动化测试用例的覆盖对全面开展自动化测试是否是最优的选择?为什么?请做简单论述。
个人感觉不是。
敏捷开发也是开发,产品不是孙悟空,不会某一天就从石头里面爆出来了。在产品开发的前期(例如0.1, 0.2版本之类),尽可能地想办法搭建一个自动化回归测试的框架,这个框架的特点有:1. 快速完成回归测试; 2.能够快速地添加测试用例并且跑起来;3.能够随着产品的演化而不断改进(不能是那种用1~2个release就要扔的东西);4.维护的成本要低(在一个release周期里面如果自动化测试需求有变化,不应该需要超过1个星期的时间才能改好,当然翻天覆地的变化除外)
a、至少一个自动化回归测试框架,保证release前能够对产品进行覆盖较为全面的回归测试
b、工作中*不断地*开发自动化测试工具,提高自己的生产率
4.如何构建分层自动化接口测试和UI测试?如何设计自动化框架?
下面观点来自网络:
对自动化测试金字塔结构的解读可以分为以下几个方面:
越下层投入应当越多,这是金字塔结构主要提出的观点,认为单元测试的稳定性和投入保证了产品质量;
越下层效率会越高,因为软件的漏洞最终是落在具体的程序代码上的,所以底层的测试效率是最容易发现和修改错误(BUG)的;
越下层成本会越低,因为底层代码测试进行的最早,此时发现错误修改起来较为容易,牵连的其他内容也很少,越向上再发现问题往往需要修改的代码量会成倍增多,所以说下层测试和修改的各项成本都是相对低的;
越下层实现专业性要求越高,虽然底层的修改是直接且容易的,但是这是基于拥有经验丰富的程序员或测试员的前提下,高度的专业性意味着人才的需求和人力成本的提高。
与UI测试的区别
接口测试比UI测试更容易发现底层问题。
接口测试的介入时间可以比UI测试更早,更容易提前发现问题。
接口测试的介入时间
只要接口开发好了,就可以进行接口测试了。
建议:
如果时间允许,至少应该进行一轮以上的接口测试,以检测底层问题。
只要后端控制好了,剩下的问题就都是前端的了,更方便定位问题。
如果绕过前端直接往接口发送非法数据,接口是否有相应的处理措施,这是很重要的测试点。
|
|