时下仅仅靠主业已经不是最保险的生活方式了，副业成为人们的刚需。而副业的发展形式如果不能与主业相结合，很可能会浪费大量时间 ，同时还会影响到主业的正常运行。那么适合软件测试人员的副业有哪些呢？这里介绍几个与软件测试有关的副业，在发展副业的同时，还可以辅助主业，同时可以平行运行，也为业余生活多了一份收入。

一、众测平台

任务时长一般在1-5日内，可以利用碎片时间找寻缺陷 ，集中一个小时来提交，有可以测试的手机，找到缺陷后按照平台要求的格式提交即可。收入按照缺陷的等级积分总和来计算，注册后需要先通过平台考核，才可以开始接任务。典型的众测平台有：testin、Alltesting等。

二、招聘平台

在招聘平台上发布兼职简历，有些外包公司有紧急任务时，会在招聘平台寻找可以周末兼职的测试人员，薪资一般是日结。可以长期挂着，如果有靠谱的HR时，可以发展为长期兼职。

三、第三方企业外包服务平台

需要自己寻找任务，最好是有一个自己的圈子，接任务后大家分工合作，是比较有保障的方式 。国内做得比较久的企业外包服务平台有威客网、猪八戒网等。

四、网上教学

如果在测试领域已经有丰富的经验，或是在某个垂直领域的行业内有所建树，可以尝试在网上开公开课，如比较集中的行业有游戏类、银行类、金融类、保险类等等。 越是细分 用户群体越精准，前期可以开放免费课程，积累人脉。针对互联网行业的在线教育平台比较多如B站、网易云课堂、知乎等等。

五、兼职讲师

如果从事性能测试、自动化测试、安全测试、渗透测试等专项测试的话，可以尝试联系到软件测试课程的培训机构，可以作为兼职讲师专讲实践类课程，特别是有大厂背景、大型项目的负责工作，会更有说服力。同时培训机构也会与企业有签约，接受企业培训的日薪也不菲。作为讲师需要有一定的沟通表达能力，我们可以在平时的工作中多多练习，以为日后的机遇做好准备。

六、知识付费平台

需要在业界有一定的影响力，如果有在线教学的经历二者结合更好，也是用户付费学习的一种方式 。目前比较火的付费平台有知乎LIVING、知识星球、豆瓣、喜马拉雅FM等 ，前期可以先加入相关的圈子 ，学习知识的同时也看看别人是怎么开讲的。

七、私活

与第三方企业外包服务平台类似，需要看机遇，现在很多互联网的创业公司或小型私企都比较少招测试人员，但在上线前会需要大量测试，一般会有熟人介绍，自身能力比较出色的话也会有很多人推荐。类似地，开发项目外包时也会算上测试人员，也是靠人脉的积累。比如：前同事接到一个50K的私活，自己去找了两个前端、一个后端、一个测试，计算了大概工作量后分出每人的收入，就可以利用下班时间做了。

八、产品内测

一些大公司经常会有内测任务，如电商网站上线前均会招募大量用户来做灰度测试，平时可以留意下官网的信息和QQ群，内测任务一般按照提交缺陷的严重等级来计算，当然是按照对客户的影响程度，如果提交不错的话，一般会有现金或内部的优惠券作为测试奖励（也是赚取零花钱的一种形式吧~~）测试过程需要足够认真，而不是走马观花，提升自己技能的同时还可以结交更多同行。

九、业务专家

业务专家算是测试人员的一个可以转行的岗位了，像网上教学细分行业，如果自己在某个专业深耕多年 ，且经常与客户、用户一起工作，可以尝试往业务专家方向转，有一定的深入后，可以作为咨询、顾问的角色来服务于其他公司的用户，比如，公司内一个资深的测试人员转为产品经理两年后，凭着对产品及业务功能的深入理解，接受了业务专家的考核，通过后自己就多了一个Title，还可以多一份薪水。

十、测试或开发平台投稿

非常适合平时喜欢做总结的测试人员，可以把自己对工作的一些见解或总结整理成文稿，通过不断打磨文章技巧，可以投稿到一些大的支持技术平台，如今日头条、CSDN、程序员、软件测试部落等等。

十一、博客或公众号

作为一名有着丰富经验和阅历的测试员，如果书面表达能力较好，经营一个博客或公众号也是一个不错的选择。即传播了软件测试知识，交流了测试思想，还能挣到一些额外的收入，何乐而不为呢？

总之 ，只要不断地学习、总结、继而融会贯通，所有与测试行业相关的副业也都是相通的，当然，这些都需要时间的积累，积极进取，不断充实自己的知识库才可以走得更远。

本文由51ste.com网友编辑，未经授权，不得转载使用上述作品盈利；个人转载，需标明作者及出处。

最近这两周在做服务端的压力测试，之前也写了一系列的机器人入门教程，我用着这套框架进行压测，这次分享压测的一些使用方法和打包到服务器上进行压测，主要使用docker把运行环境和设置好挂载路径。

使用multiProcess并发

我这里用的多进程的方式进行，每个进程上大约100个玩家，每个玩家3个线程，每个进程由一个心跳线程对所有的线程进行广播，原本的框架里是每个玩家自带一个心跳，放在sendActor里执行，为了sendActor的性能我把它迁出来。

导入进程池模块

from multiprocessing import Pool

机器人登录

这里有个随机角色名字，可自由定义

def players(min=1,max=2):

name='test'

for i in range(min,max):

send=Main(account=f'{name}{i}',actor_name=random_actor_name(),server_id=server_id)

yield send

定义运行方法

test_data: 账号起止数据和remote里要调用的方法 heart_timer: 我自定义的心跳广播方法，等会说到 player_list: 根据登录账号段自动登录，执行测试在for循环的call里面，具体的方法在机器人第4篇有写到

def one_process(test_data,player_stop=False):

start_num,end_num, remote_method=test_data

player_list=list(players(start_num,end_num))

heart_timer()

for _ in range(100):

for call in player_list:

if remote_method:

call(remote_method)

time.sleep(6)

if player_stop:

for st in player_list:

st.stop()

pykka.ActorRegistry.stop_all()

广播心跳

第一次这样尝试保持心跳，如果后续有问题，再优化上来；它这里的实现方式是通过ActorRegistry 来广播给指定的Actor，我在playerActor增多一个消息类型MSG_HEART ，广播消息后，playerActor 的on_receive 会收到这条信息，然后通过SendActor发送给服务端保持心跳。

def heart_timer():

if pykka.ActorRegistry.get_by_class_name('Player'):

pykka.ActorRegistry.broadcast('MSG_HEART', 'Player')

timer=threading.Timer(20, heart_timer)

timer.start()

心跳处理方法 发送自己项目的心跳协议，要参数的带上参数

if case(MSG_HEART):

# 判断发送线程是否活着

if self.send_actor.is_alive():

self.send_actor.tell({MSG_PROTO: ['send_heart_XXX']})

并发

维持执行的进程总数为4，当一个进程执行完毕后会添加新的进程进去 调用join之前，先调用close函数，否则会出错。执行完close后不会有新的进程加入到pool,join函数等待所有子进程结束

def main():

player_pool=Pool(4)

for case in test_case:

player_pool.apply_async(one_process,(case,))

player_pool.close()

player_pool.join()

if __name__=='__main__':

main()

docker打包部署

前面我有提到我这里用的协议类型是sproto，协议解析打包用的是GitHub的开源框架，当我想在Windows上运行的时候发现一个问题，无法生成动态链接库，尝试几遍失败后就想着转到虚拟机运行吧，后面也要部署到Linux上运行，不浪费功夫研究，为了方便部署就打起了docker的心思，之前也用docker+Jenkins部署自动化。关于docker的使用，这里跳转到菜鸟教程

创建镜像dockerFile

可以直接用docker命令来执行也可以用dockerFile执行，可以参考我的dockerFile看看。

# 机器人压测 Dockerfile

# Version 1.0

# Base images 基础镜像

FROM python:3.6.9

#MAINTAINER 维护者信息

MAINTAINER AJian

# 开启权限

USER root

#ENV 设置环境变量

ENV PATH /usr/local/python3/bin:$PATH

#ADD 文件放在当前目录下，拷过去会自动解压

ADD '要运行的代码' /usr/local/robotTest/

ADD '第三方库的路径' /usr/local/lib/python3.6/site-packages

# 可以挂载文件路径

VOLUME /usr/local/robotTest

CD到dockerFile的目录下，执行build命令

docker build -t xxx_test:1.0 .

启动容器

这里设置了挂载目录

docker run -it --name XXXTest -v '你的本地目录':/usr/local/robotTest AJian/xxx_test:1.1

进入容器运行看看，查验下有没有问题

docker exec -it XXXTest /bin/bash

进入容器，找到自己的代码运行看看，没问题就可以推送镜像，当然也可以完善你的容器再打包成镜像

推送镜像

这里要说一下镜像命名，如果要推送上去的镜像要加上自己的账号名，也可以用tag命令重命名

docker push AJian/xxx_test:1.1

到这里，在本机的操作已经完成，接下来可以进入自己的服务器拉取镜像

拉取镜像

拉取完镜像后执行：docker images 看看是否出现了刚推送的镜像 接下来再启动容器即可

docker pull AJian/xxx_test:1.1

源自公众号 游戏测试技术分享

本文由51ste.com网友编辑，未经授权，不得转载使用上述作品盈利；个人转载，需标明作者及出处。

软件测试有三种模型，分别是V模型，W模型和H模型。每种模型都有自己的优点和缺点。

V模型

V模型如下图所示：

V模型的优点

V模型明确地标识出了在开发过程中一般应完成的测试级别，以及这些测试级别与代码生成前各项开发活动的对应关系——单元测试依据详细设计检查代码是否正确实现了单元的功能；集成测试依据概要设计检查各单元间的接口是否正确实现；系统测试依据需求规格检查软件是否作为一个整体有效运行；验收测试则是由用户代表依据用户需求检查软件是否真正满足用户的实际需要。

V模型的缺点

V模型把测试活动全部安排在编码活动之后，这样可能会导致需求开发和设计阶段的错误直到编码完成之后才发现，这不符合尽早测试的原则，会增加很多开发成本，以至于影响软件交付工期。

W模型

W模型如下图所示：

W模型的优点

W模型是对V模型的一种改进。W模型中，软件开发和测试是紧密结合的，每个开发活动完成后就同步进行测试活动——需求分析完成后进行需求测试；设计完成后进行设计测试；编码完成后进行单元测试；集成完成后进行集成测试；系统构建完成后进行系统测试；完成交付准备工作之后进行验收测试。

W模型的缺点

W模型中开发活动都是串行的，开发和测试也是一种线性的关系——只有开发活动完成了才能进行测试活动。这种方式使得W模型无法适应敏捷、迭代开发，以及灵活的变更调整。

H模型

H模型如下图所示：

H模型的优点

H模型中的测试活动是一个独立的流程，只要满足了测试就绪条件，就可以开始测试活动。这种灵活的组织方式，使得H模型完全具备了前两个模型的优点——既可以与所有的开发活动紧密结合，又足够灵活满足敏捷和迭代的开发模型。

H模型的缺点

H模型的灵活也造就它难以驾驭的特点。如果管理者没有足够的经验就实施H模型，可能会事倍功半，测试活动的成本收益比会比较低。

根据以上测试3种模型的特点，建议一般的软件开发过程采用W模型，实施敏捷和迭代开发的可以考虑采用H模型。

源自公众号 软件工程之思

本文由51ste.com网友编辑，未经授权，不得转载使用上述作品盈利；个人转载，需标明作者及出处。

如果你是电影迷，那么可能听说过《豪勇七蛟龙》或《十二金刚》。好吧，我谈谈听起来不太吸引人的“测试8板斧”。测试8板斧并不是最新好莱坞大片的名称，而是指八项测试基础，其原理可以应用于任何开发方法，以确保其交付成果的质量。

如今，开发方法在不断变化，新的流行语和定义不断涌现。DevOps、Scrum和Kanban的敏捷和精益方法结合了传统的瀑布模型和V模型。随着向敏捷开发的转变以及人们对这些方法的误解，人们倾向于将注意力聚焦在交付速度上，这有时会损害质量。显然，对于任何软件开发而言，高效交付和按时交付都是至关重要的，但我们不应忽略有助于确保交付的产品符合目的的基本原则。

与普遍的看法相反，质量保证不必费力或费时。就如古老的谚语所说——“一针及时省九针。” 从长远来看，在开发生命周期的早期使用基本的QA技术将节省大量的时间、痛苦和精力；毕竟，就项目而言，尽早清除问题要比在生命周期后期修复相同的问题更经济。这听上去很简单，但是考虑到当前对精益和敏捷的需求，要如何实现这一点呢？

如果这是一部牛仔电影，那么“测试8板斧”将横空出世。

1、明确测试范围

都应知道要计划进行的测试，这似乎不是问题！但实际情况是不总是像你期望的那么清楚，因为某些功能可能由于测试团队无法控制的各种原因而进入和退出开发范围。试图确保交付质量时，明确范围至关重要。如果不清楚交付的内容，则无法衡量成功，因此需要在项目团队内部商定测试范围的摘要，并形成文档以供参考。

2、分享和评审

还记得小时读书交作业之前让父母检查一遍吗？当应用于IT开发时，相同的做法也会带来好处。无论采用哪种开发方法，对需求、设计、测试需求和测试用例的评审都应作为标准。在需求收集阶段识别和解决需求问题要比让问题渗透到设计中并成为后来由测试确定的软件缺陷廉价得多。评审还可以促进项目团队内部的协作和知识传递，使不同的团队对彼此的成果有更好的了解和欣赏。

3、测试可追溯

一旦确定了范围并提取了测试需求，就必须证明测试的可追溯性。这可以通过简单地在每个测试和其来源之间提供可追溯性来实现。这可能是需求、设计或原型图。测试的可追溯性很重要，因为它证明测试范围覆盖了测试需求。项目团队对可追溯性文档进行审查可以突出显示任何遗漏或不应测试的区域。

4、测试排优先级

任何有经验的测试专家都会告诉你，测试时间总是会被挤压。即使不是这种情况，采用基于风险的方法对测试进行优先级排序也很有意义，这使你对重要功能的测试更有信心。抽取测试用例后，从失败风险和失败影响的角度对它们进行评级很重要——高、中或低测试优先级。可以通过与开发团队讨论来确定失败的风险，而失败的影响则需要业务或技术支持团队参与评估。高优先级，高影响力的功能测试应优先考虑，以识别潜在问题，并尽早在测试时间内对这些功能建立信心。

5、计划执行工作

一旦为测试用例分配了优先级，并且通过了评审，下一步就是做测试计划。计划执行高、中、低优先级用例的顺序。计划好测试日程需要交付的成果物，并预留好处理紧急问题和重新测试的时间。该计划还将提供一种度量，一旦开始执行测试，就可以据此报告进度。

6、了解测试入口标准

输入标准详细说明了能够启动测试所需满足的条件。这些标准将包括外部依赖性，例如批准的需求/设计文档，范围定义，测试环境，测试数据，测试用户以及测试团队的活动，例如测试准备、完成和审查。入口标准应作为测试执行的质量门，以确保在开始执行之前已满足所有要求的条件。通常会与相关的交付利益相关者举行一次入口会议，以审查这些标准并做出明智的决定，以确定是否满足所有入口标准，让各方意见统一。

7、知道测试退出标准

建立并统一退出标准对于测试的任何阶段都是至关重要的。退出标准列出了测试旨在达到的目标以及成功的情况。作为计划的一部分，需要确定测试需要完成的工作，然后才能将测试视为完成。这些标准通常是测试覆盖率以及缺陷数量和类型的度量。例如，你的条件可以是：

所有高优先级和中优先级的测试100％执行。

没有严重性或优先级为1或2的缺陷。

只要定义了可接受的解决过程和时间表，严重性或优先级为3的缺陷就可能很严重。

8、传达测试报告

报告可以分为进度报告和完成报告：

进度报告：在测试执行过程中准确、高效地报告进度至关重要，因为它为测试中交付物的质量提供了晴雨表。现在，许多测试工具都可以方便出进度报告，但简单来说，报告应提供针对计划的测试、已执行的测试和正执行的测试，通过、失败、阻塞等情况进行度量，并对缺陷的数量和优先级/严重性进行统计。报告应足够详细，以突出显示任何潜在的问题；因此，有必要在各个功能区域以及每个功能区域的高、中和低优先级测试的状态上提供粒度。通常每天生成报告，以便向感兴趣的干系人提供更新。

完成报告：简短的完成报告总结了在测试执行期间完成的测试。这也应该足够细化，以提供测试覆盖范围和测试各个功能区域的结果，并总结在执行结束时发现、解决和未解决的缺陷。理想情况下，此报告还将提供对已发现缺陷的根本原因分析，以便用于解决今后出现的问题。该文档将使开发团队和干系人了解所测的可交付成果的质量，并让他们判断是否达到预期。

“测试8板斧”不会出现在电影屏幕上，而是被用来提高应用或IT系统的质量！如你所见，其中一些基础知识取决于项目团队内部的协作，并适合于交互式会议和研讨会。讨论和意见统一是好的，但是如果不记录讨论的结果，则可能会丢失重要的项目决策，因此质量保证取决于一定程度的文档。

现在，尽管“文档”一词可能会引起许多在敏捷或精益开发环境中扎根的IT专业人员的恐惧，但其实无需如此。可以采用一种常识性的方法来确保支持这些基本原理的细节被捕获和记录，以补充而不是抑制正在使用的开发方法。这些细节可能包括关键需求、决策、项目资产和测试用例等等。通过简短的文档或电子表格可以很容易地记录这些信息。这些内容记录分发给干系人进行审批时，只需清晰易懂即可，但必须保证这些记录已达成统一。

质量保证要记住的重要一件事是在管理与开发速度之间取得适当的平衡。正确的管理级别可以确保你的组织所依赖的系统的质量而不会造成繁琐的工作，使大家充满信心，提供你和你的客户需要和期望的功能。

-- End --

文末寄语：人生就是一场醒悟，不要昨天，不要明天，只要今天。有些事，不是不在意，而是在意了又能怎样。人生没有如果，只有后果和结果。成熟，就是用微笑来面对一切小事。

本文由51ste.com网友编辑，未经授权，不得转载使用上述作品盈利；个人转载，需标明作者及出处。

在过去的50年里，自动化，即让机器或计算机在没有人为干预的情况下执行其任务的过程，已经彻底改变了制造业。自动化过程控制着计算机芯片的制造，装卸机器以人类无法达到的精度组装电路板，机器人组装汽车的速度如此之快，以至于一些汽车厂可以做到 每两分钟生产一辆新车。

在过去的十年里，自动化已经变得越来越普遍。 机器人过程自动化 现在大企业经常使用它来提高日常和重复性任务的效率。测试自动化是一项大生意，它允许测试在没有它的情况下是不可能的。

在许多情况下，这种自动化是纯机械驱动的，例如，使用巧妙设计的运动顺序，让机器人拿起一个零件，将其旋转到位，并将其固定。最近增加了某种程度的智力。例如，允许拾取和放置机器“看到”正在拾取的零件，以便它们可以旋转它们并确保它们的位置正确。在这个博客中，我们将研究更广泛的行业和测试自动化中的不同自动化水平。

什么是自动化

韦氏词典 定义自动化 作为“使一个装置、一个过程或一个系统自动运行的技术”或“用机械或电子装置代替人类劳动对一个装置、过程或系统进行自动控制的操作”，这些定义抓住了这样一个观点：自动化就是让一台机器扮演一个人的角色来接管一项任务。通常，这是为了使任务更快更有效，但在某些情况下，这可能是因为任务是危险的（例如。 清除受污染的核废料 或者是因为人力成本相对较高。

在测试行业，自动化就是让计算机自动执行QA测试。从测试网站前端的哑脚本，到跨多种浏览器类型测试web应用，甚至到使用机器学习自动生成测试的系统。在这里，主要目的是增加能够执行的测试的数量和范围。这并不是要把人从测试中完全排除，而是要确保尽可能多的重复测试是自动完成的，尤其是 回归测试。

自动化模型

大量的研究人员试图定义模型来评估给定过程或系统实现的自动化水平。在这里，我们将看到几个更有趣的。一般来说，这些模型要么从控制过程的人的角度考虑问题，要么从机器实际操作的角度考虑问题。

最著名的以机器为中心的模型之一是汽车工程师协会 分类学 自动驾驶车辆的自动化水平。如果包含非自动化的0级，它们将定义6个自动化级别。

驾驶员辅助。在这里，车辆只能在巡航控制和车道保持等方面提供帮助。

部分自动化。在这里，车辆接管了更多的转向和加速/制动元素，但仅在严格控制的情况下。例如自动换道或自动停车。

条件自动化。在这里，车辆不仅可以控制转向和加速/制动，还可以监控环境，并在驾驶员需要收回控制权时发出警告。这类似于特斯拉汽车的自动驾驶模式。

自动化程度高。在这里，车辆本身执行大多数驾驶任务，只要它保持在定义的用例内，比如在两个已知位置之间驾驶。人类驾驶员根本不起任何积极作用，但仍然能够收回控制权。

全自动化。在这个级别上，车辆完全自主地执行所有驾驶操作。现在没有人驾驶，实际上，车上也没有人操纵的控制装置。

在他们1999年的论文中 Parasuraman、Sheridan和Wickens建立了一个人类与自动化交互的类型和级别模型，确定了采取任何行动需要完成的四项主要任务。这些是信息获取或感知；信息分析；决策与行动选择；行动和执行。Endsley和Kaber 提出了一个模型，该模型基于人类还是计算机执行这4项任务。

同样，在他1980年的论文《计算机控制与人的疏离》中，谢里丹考察了自动化在决策方面的10个阶段：

1.人类考虑替代方案，做出并实施决策。

2.计算机提供了一套人类在决策时可能忽略的备选方案。

3.计算机提供了一组有限的备选方案，由人类决定实施哪种方案。

4.计算机提供了一组有限的备选方案并提出了建议，但人类仍然做出并实施最终决策。

5.计算机提供了一组受限制的备选方案，并提出了一个建议，如果人类同意，它将予以实施。

6.计算机做决定，但在实施前给人否决权的选择权。

7.计算机作出并执行决策，但必须事后通知人。

8.计算机作出并执行决策，只有在被要求时才通知人类。

9.计算机作出并执行决策，只有当它认为有必要时才通知人类。

10.如果计算机认为应该做决定，它就做出并执行决定，只有当它认为这是必要的时候，它才会通知人类。

所有这些模型都有一个共同点，即自动化过程涉及决策和对决策采取行动。

在一个 2017年博客，Gil Tayar，一位 Applitools，研究了如何将自动驾驶汽车的SAE模型应用于测试自动化。在自动化的各个阶段，他都用同样的名字。

1、协助。在这里，人类编写测试，并且必须维护它以反映任何更改。人工智能仅用于执行简单的验证步骤，并协助前端进行目视检查。

2、部分自动化。在这里，人类仍然需要编写测试并监视更改，但是人工智能能够协助验证更改。

3、条件自动化。在这里，人类编写测试，但人工智能验证每一个变化，并作出任何需要的更新。

4、自动化程度高。在这里，人工智能承担着编写测试的角色，但是人引导着过程并定义了测试应该做什么。

5、全自动化。在这里，人工智能完全负责编写和维护测试，而无需任何人工指导。

将此模型应用于函数化

结论

有许多模型可以对自动化程度进行分类。在这里，我们只看了一小部分。正如我们所看到的，这些模型既可以从人的角度看自动化，也可以从机器的角度看自动化。最广泛引用的车型之一是自动驾驶汽车的SAE分类法。我们看到了Applitools的朋友们如何将这个模型应用于测试自动化。根据他们的模型，我们的自动化测试已经非常接近实现全自动化。然而，我们觉得仍有改进需要改进，我们的测试工程师正在不断努力改进我们的软件，推进最先进的测试自动化水平！

源自公众号 筋斗云Tester

本文由51ste.com网友编辑，未经授权，不得转载使用上述作品盈利；个人转载，需标明作者及出处。

为了确保自动化测试的顺利进行，自动化测试应当遵循以下规范：

设计自动化测试用例应以主场景为先

在设计自动化测试用例时，应遵循以下顺序：主场景，扩展场景，流程。因为主场景包含了常用的，使用次数最多的功能需求。

保持自动化测试脚本的可读性

设计自动化测试脚本时，应尽量使其保持简单，让一个单元只做一件事，同时，为脚本加上必要的注释，使其具有很好的可读性。

保持自动化测试脚本的可维护性

可维护性意味着维护自动化测试脚本的成本降低，使得自动化测试可持续改进。所以，测试人员设计测试脚本的时候应避免“硬编程”，将固定的值或者测试依赖的数据写入脚本当中。

使用统一的脚本语言

虽然一些自动化测试工具支持多种脚本语言，但在设计自动化测试脚本时应统一使用同一种语言，这样有利于测试人员与各利益相关方之间的交流。

尽量避免复杂控件的测试

复杂的控件测试难度高，易出错，会大大提高自动化测试的成本。所以，测试人员应当尽量避开复杂控件的测试，或者请求开发人员开发更多的测试接口，甚至更换控件。

遵循基本的测试流程开发自动化测试脚本

自动化测试脚本的开发最后也遵循测试的基本流程，比如，先定义预期的输出结果，再输入测试数据，执行测试步骤，将实际输出结果与预期的输出结果比较，记录比较结果，给出结论。

不要轻易地将检查某个错误的脚本注释掉

某些情况下，自动化测试发现的缺陷不能全部及时地修改，这时候的自动化测试会对其中为修复的缺陷给出同样的错误信息。需要注意的是，测试人员不能为了自动化测试流程不被这种情况中止就简单地将检查这个缺陷的脚本删除或注释掉，因为这样可能会使得这个缺陷被“遗忘”。正确的做法是测试人员设计用来检查缺陷状态的脚本，当检查到缺陷是“已修复”状态时，就执行对应的自动化测试脚本，否则，不执行该脚本。

源自公众号 软件工程之思

本文由51ste.com网友编辑，未经授权，不得转载使用上述作品盈利；个人转载，需标明作者及出处。