Badboy：基于
Web的
自动化测试工具，通过协议包进行交换，响应速度快，安装文件较小简单，安装环境不限制，很容易上手且无需编写复杂的代码，功能强大https的加密请求也可以进行模拟录制
案例：在web架构的平台上添加大量的用户
思路：利用badboy先录制添加一个用户的步骤，再整理脚本提高效率，接着参数化脚本，设置excel传值，最后执行play
步骤：
1.打开badboy，新建一个脚本，默认添加一个录制步骤，点击暂停录制，在地址栏输入要录制的平台WebIP地址，如https://172.10.39.130,点击右侧的转入或按键盘回车键展示平台登录页面，登录系统切换到用户管理模块，打开添加用户对话框，点击开始录制按钮，输入用户相关信息点击save保存（即用户添加完成），此时点击暂停录制。可以看到badboy的左侧script栏step下多了一条https请求，下方的Summary栏展示录制过程的响应时间
2.参数化设备信息。在tools中选中Data Source，右键菜单选择properties；在弹出框中选择excel类型，选择excel路径（事先可以先创建好excel文档，首行写列名，接下来填数据，也可以添加一列seq作为序列），保存后右键菜单选择Add to script
3.选择要参数化的变量，本案例中由于用户名是唯一的需要对用户名参数化，再step的脚本中找到userInfo.name=test,我们对
test进行参数化赋值给变量如${name}
4.循环，选中step右键菜单选择properties，选择循环按照参数表，即完成循环添加用户的脚本（如果选择下拉框为空，先执行下datasource脚本）
5.执行，web页面停留在添加用户对话框，右键step选择play whole test，即完成添加用户的操作
PS：在录制过程中为什么要从添加用户开始呢？
刚开始测试时遇到几个问题1）用badboy回放登录平台无法实现2）登录后badboy无法定位到用户管理模块
根据我们的最终目的我们可以直接避开这两点直接从添加用户开始，这样做的好处还有一个减少冗余请求执行更快
特点：本案例添加用户成功后【add user】对话框不关闭
做手机APP测试也有2年多了，在这方面也有不少感慨，看了很多分享者，觉得大伙都是好样的，读后有感，把自己近年来的手机APP方面的
测试经验也写下来，希望能对同行多少有点帮助，不足之处，还请留言，一起讨论：
一 手机APP测试基本思路：
测试计划--测试方案--测试用例--执行：
很多小公司都没有具体的需求，项目时间也比较紧，而且流程也不是很严谨，在这样的情况之下，作为测试的我们，该怎样去对项目进行用例的设计？个人觉得，项目到手，不是马上就进入测试
工作，而是，先熟悉下整个项目的流程，把大致的框架过一遍，不懂的地方记录下来，再问开发，把流程都掌握了，再对照已有的文档给予项目立项（测试计划、测试方案），用例不必写的太过于详细（app模块变动较大，过于详细维护成本太高，而且项目经理给你的时间短，会浪费项目执行时间），把每个功能模块罗列出来，大致的功能点，用什么方法去测试，都给标注，然后再根据测试需求执行测试（目前我用例都只是罗列大概的执行方法，不具体详写，改起来方便）；
二 手机APP测试测试要点：
功能测试（流程测试、功能点测试）、兼容性测试、交叉测试、安装卸载测试（包括应用的升级）、压力测试（接口压力测试）；
功能测试：对具体功能点一一测试，确保每个点都能正确实现相应功能；
兼容性测试：对市场上主流的设备安装应用执行测试，确保都能正常运行；
交叉测试：对于正在运行的应用，若进入短信、电话等其他软件响应的情况，不会影响所测试应用，且会保证应用都能正确运行；
安装卸载测试：确保应用都能正确安装、卸载，且能正确运行（注意应用的升级测试：升级前后的状态）；
压力测试：用户量大，交互性高的应用需对接口执行压力测试，确保不会应用在大用户量的情况下能正常运行。
三 注意事项：
闪退（内存不足等情况），在
手机上，该类问题出现的几率很大，应着重测试，比如，返回访问某个模块(数据时时获取的模块)，切换应用，重复提交、来电交互等都是闪退几率大的原因。
以上就是本人所列点，写的不好的地方，请多包容，第一次写这个。大家一起
学习，一起进步。
什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些
规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。
什么是三大范式：
第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要
求，否则，将有很多基本操作在这样的关系模式中实现不了。
第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。
第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF.
注：关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性
理解三大范式
第一范式
1、每一列属性都是不可再分的属性值，确保每一列的原子性
2、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据。
如果需求知道那个省那个市并按其分类，那么显然第一个表格是不容易满足需求的，也符合第一范式。
显然第一个表结构不但不能满足足够多物品的要求，还会在物品少时产生冗余。也是不符合第一范式的。
第二范式
每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。
一个人同时订几个房间，就会出来一个订单号多条数据，这样子联系人都是重复的，就会造成数据冗余。我们应该把他拆开来。
这样便实现啦一条数据做一件事，不掺杂复杂的关系逻辑。同时对表数据的更新维护也更易操作。
第三范式
数据不能存在传递关系，即没个属性都跟主键有直接关系而不是间接关系。像：a-->b-->c 属性之间含有这样的关系，是不符合第三范式的。
比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）
这样一个表结构，就存在上述关系。 学号--> 所在院校 --> (院校地址，院校电话)
这样的表结构，我们应该拆开来，如下。
（学号，姓名，年龄，性别，所在院校）--（所在院校，院校地址，院校电话）
最后：
三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。
一、流的分类
1、按功能分
读取流：InputStream Reader
写出流：OutPutStream Writer
2、按流的类型分类
字节流：InputStream OutputStream
字符流：Reader Writer
二、流功能分析
读取流是从输入设备或数据对象中读取数据到程序，用程序进行处理读入的数据，写出流是把程序处理的数据输出到
输出设备上比如硬盘和控制台。
字节流读取和写入的数据单位是字节，可以读取和写入任何类型的数据。字符流读取跟写入的数据单位是字符，只能
读取和
写入文本类型的数据。当需要读取或写入文本型的数据时要用字符流，因为它会比字节流读写字符更方便和高效，相反当数
据不是文本型时只能用字节流来读取跟写入。
三、流中读写方法的示例。(当用到IO流时就有可能出现IO异常，所以需要处理可能的异常)
字节流：
FileOutputStream fos = new FileOutputStream("D://xxx.xxx");
fos.write("dsfdsf".getBytes());//写入字节数组
fos.close(); //用完后需要关闭流，释放资源。字节流不需要Flush
FileInputStream fis = new FileInputStream("D://xxx.xxx");
fis.read(); //读取一个字节
fis.close();
字符流：
FileWriter fw = new FileWriter("D:\\xxx.txt");
fw.write("sdfsdfsdf");//可以直接写入字符串
fw.flush(); //写完后需要Flush，才能真正写道输出设备
fw.close(); //close（）时也会Flush。
FileReader fr = new FileReader("D:\\xxx.txt");
fr.read(char[] ch);//可以读取一个字符数组的内容
fr.close();
四、转换流
当需要流之间的转换时会用到转换流。
1、把字节读取流转换成字符读取流
InputStreamReader isr = new InputStreamReader(new FileInputStream("xxx.xxx"));
2、把字符输出流转化成字节输出流
OutputStreamWriter osw = new OutputStreamWriter(new FileOutputStream("xx.xxx"));
五、缓冲流
需要提高流的读写效率时会用到缓冲流
1、字节缓冲流
BufferedInputStream bis = new BufferedInputStream(new FileInputStream("xx"));
BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream("xx"));
2、字符缓冲流
BufferedReader br = new BufferedReader(new FileReader("xx.txt"));
BufferedWriter bw = new BufferedWriter(new FileWriter("xx.txt"));
缓冲流对读写功能进行了增强，而且使用缓冲技术提高了读写效率，所以当需要提高程序的读写效率时要使用缓冲流。
六、File类的使用
1、创建
boolean createNewFile()：在指定位置创建文件，如果该文件已经存在，则不创建，返回false。
和输出流不一样，输出流对象已建立创建文件。而且文件已经存在，会覆盖。
boolean mkdir（）创建文件夹
boolean mkdirs（） 创建多级文件夹
2、删除。
boolean delete();删除失败时返回false。如果文件正在被使用，则删除不了返回false。
void deleteOnExit（）；在程序退出时删除指定文件。
3、判断
boolean exists();文件是否存在。
isFile():是不是文件
isDirectory();是不是文件夹
isHidden();是不是隐藏文件
isAbsolute();是不是绝对路径
4、获取信息
getName();文件名
getPath();文件路径
getParent();上一层路径
getAbsolutePath();绝对路径
一、对于上传文件， 从手动操作我们可以看出， 需要对window 窗体进行操作， 而对于selenium webdriver 在这方面应用就受到了限制。 但是， 庆幸的是， 对于含有input element的上传， 我们可以直接通过sendkeys来传入文件路径，省略了对window 窗体的操作来实现文件上传， 具体实现过程如下：
1）找到上传控件element，并输入路径：
WebElement element = driver.findElement(By.id("cloudFax-attachment-form-upload-input"));
element.sendKeys(getFilePath(text.txt));
2）路径的处理：
private String getFilePath(String resource) { URL path = this.getClass().getResource(resource); return path.toString().replaceAll("file:/",""); } |
这样把代码和文件上传到服务器， 就可以找到该文件进行上传。
这里需要注意的几点：
The element you want to put filepath is the "whole" input element rather than the "readonly" input element,as below, the first locator is right but the second locator will throw an exception.
直接调用element.sendkeys ， 不需要再做一次element.clear()，否则会出现该异常：Element must be user-editable in order to clear it.
二、对于如下控件的上传方式， 暂时无法实现：
第一部分：潺潺流水化田园
很多人认为一个好的
测试工程师必须做到在第一时间发现所有的bug，然后以最快的速度测试完毕所有的task。以显示其
测试技术的高超。
您是否想过
1：在一个task完成之后，这个task就真的如此果断的结束了吗？这个task对于整个软件，会产生什么作用？
2：这个测试人员所谓的最快速度，究竟是何等的快，快的原因是什么？
就算运用了自动化或者
性能测试工具，这些工具的运用是否恰如其分？
3：这些“高超的技术”会给公司带来什么？会带来公司文化的提升吗？公司的文化是什么呢？
从拿到需求起，我就会先通读需求，逐句分析，一一尝试，一直到需求中的每一步，每一句都能融会贯通，同时将需求中涉及的每一个步骤在有必要的情况之下，一遍又一遍的执行，在执行的过程中，提出疑问。
在疑问得到解答之后，在必要的前提之下，开出非常详细的bug，在bug中不但有步骤，还有个人感受，体会，甚至还会有建议。
在很多时候，我的疑问，会有助于优化需求，我的bug也会很有可能被设置为by design，或者defer to another User Story。
将成为另外一个需求的初始地。
而我们的PM，都认为这样做是正确的，他们也乐于为我解答每一个疑惑。不论疑惑是大的还是小的，他们都会不厌其烦的为我进行解答。他们会理解我不是随便提的问题，因为我的问题必定是经过深思熟虑而提出的。
他们会在置为by design的bug中，为我写明原因，而且还会对我所提出的bug或者疑惑进行鼓励，thank you，you are welcome是我们邮件中运用最多的词汇。
就是在这样互相尊重，时时鼓励的氛围之下，我感觉每一天的
工作是愉悦的，有价值的。
我还会将每次的task都总结起来，时刻回顾分析，系统的每一个模块也在我的一遍一遍的分析之下，成为一个有机整体，合理，有序，有逻辑化，不紧不慢，每一天，每一刻，都是一个小进步。
看着整个系统渐渐成熟，如同一片田园，就是因为有测试工程师这样的流水，才能从荒芜渐渐变成一片美好景象一般。心中不免有一丝欣慰。仿佛呼吸着田园带来的清新空气享受春风吹过般的感觉。
而闲暇时候，我还
学习一些
自动化测试，性能测试，还学习数学理论，并与同事分享成果。
谁会在乎你是否第一时间发现bug呢？这有何重要呢？
第二部分：分出高下的埋没人性
有的软件公司会在试用期期间招募一批测试人员，然后短期时间内就分出个高与低，这种高于低的区分不是靠工作的热忱度，也不是靠对于测试的投入多少，往往靠几句花言巧语，或者耍耍花腔和所谓的资历。
最终结局往往还会是，被“淘汰”的人会被那些没有被淘汰的人举行隆重的“葬礼”，然后灰溜溜的离开这个公司或者离开这个职位。
而要继续“重生”，他们逐渐学会了如何“耍花腔”。我承认他们很理解测试的流程，测试的理念，测试的工具的使用，比如自动化测试，或者性能测试，甚至，他们的智慧都是超高的。
但是他们在测试的过程中，对其测试的主体：这个软件。却并不怎么了解，也不想了解。他们只想应付工作，想升职，想当测试经理，甚至，想找工资更高的工作！
他们的中心思想，也就是银子，为了银子不顾一切，人性被埋没了，人格也消失了。
这不是测试人员的错，这是制度的错。
而这样的软件公司，不在乎测试人员与开发人员之间的沟通，更不会关注测试人员的感受，尤其是那些所谓的初级测试人员的感受：
体现在：
1：每天完成大量工作，测试人员彼此很少沟通，彼此是竞争对手。（人干嘛非要你争我夺，累死累活）
2：他们的绩效是开bug的数量，而且还不成文的规定是开被fix的bug的数量。
（by design 的bug也是智慧的结晶，不能歧视有缺陷的儿童嘛，人家又不是故意开bug，人家开bug也很费力气，很多也是需求问题造成的。在此，人性也很缺乏）
3：没有必要的前提下搞性能测试和自动化测试。自动化测试，性能测试团队和普通测试团队分离，显得自动化，性能高于普通团队。（我从来都认为劳动的含金量不是靠工具来决定的，而是靠一颗热忱的心,自动化一段时间不用就会忘记，但是热忱的心不会改变）
4：他们的软件质量好是碰运气，质量差是测试人员的不是，有人要承担后果。（由于是金钱上的后果，所有人都
生活在恐惧之中，氛围紧张）
第三部分：黑暗团队之封建社会 在一个多年的测试团队中，新分派一个根本不了解这个软件人作为测试团队的头领。仅仅因为这个人有某种特权，或者有某种资历。
先且不谈这个团队中原本是存在着对于这个软件有着系统了解的组员的感受了。
这样的头领必须每日花费所有时间来了解整个软件，才可能赶上其他测试人员的步伐，与此同时还要鉴别所有测试人员的测试成果，做出决策，这恐怕是比登天还难的事情。
而黑暗团队的组成模式是可以轻松实现这种比登天还难的事情的：
测试头领以“保住自己的有利地位和有利工资”为主线。
结果扼杀团队成员的想法和活力，因为测试的头领想留住对自己有利的人，而不是去思考如何将软件的质量进一步提升，更不是想让人人都了解软件。
这样的测试头领会想让某些人“不知”，或者“后知后觉”，而另一些人却“先知”，可是“先知”的那些人真的能做到知无不言，真的是勇于探索的吗？
那些被新的“头领”认可的人必然会歧视其他人，同时因为自己已经取得了有利“地位”而不需要进行更多的探索和努力，变得更为懒散。
将所谓的重复的“任务”分配给“后知后觉”的苦命人。
这些任务因为是那些“皇帝”，“地主”设置的，往往有很多“特点”：
1： 很多是不必要的任务，做了一天下来发现是白白做了，冠冕堂皇的说让你做你做就是了。
2：“皇帝”，“地主”认为不需要告诉“后知后觉”们为什么要做这些任务，因为他们是奴隶，只需要听从主子的安排就是了。
3：“苦命人”每天累得腰酸背痛，都不知道在做什么，还心情低落，无处申诉。
4： 如果有什么后果，就是那些“苦命人”来承担。所以，加班，后果，裁员都是由“后知后觉”承担。（此时的“苦命人”早已知道自己的地位，也不再恐惧了，受罚的肯定是自己了，所以可以“笑对一切”，难不成就是个回家继续找工作咯！）
以上就是黑暗团队。想象地主挥舞鞭子抽打着奴隶的样子，还要奴隶为他们服务吧。
第四部分：敏捷测试迎来改革开放晨光，劳苦大众翻身做主人
---人人迸发智慧的光芒
敏捷测试真的优点多多
1：不会把人累倒
因为每个周期会有2，3周时间，每个人以自己的方式尽快测试完毕，发挥自身的潜能。就算到时候无法完毕，也不是大不了的事情，因为在每天的交流之中，人人都了解你付出的努力，你是有理由这样的，人都是讲道理的。
不会出现每天加班没法完成任务的景象。
2：独立的测试，不需要依赖别人，界限分明，彼此敬重，不争不抢
因为你的任务就是你的任务，不需要给别人插手，如果是别人做的，也可以将任务分配给那个人就行了，你可以在日后研究别人的测试用例，取长补短。
以人为本的敏捷测试会让十个测试人员有十种光芒，您会说他们也许会七嘴八舌，也许会有重复的。
可是，当他们人人都深入了解软件，软件本身的功能与内涵就会如同一条主线贯穿于每个人的脑海，因为有着共同的目标和热诚，软件在每个人的心中都如同一种纽带，一种信仰，让所有的测试人员彼此的心，相通了。 所谓的测试经理只需要开个会，一一记录，并给予每个人以正确引导和鼓励，相信这会是高效的，愉悦的大会。
而每一次的大会，会像潺潺流水一般滋润到整个软件中，滋润到每个人的心中。
软件-心灵-生命-热诚，甚至是关爱，对测试人员的关爱，对软件的热情， 这同时也升华成为团队的一种文化，公司的文化。
在任何公司文化中，都不免会有一些人被淘汰，而敏捷测试所淘汰的人，必定是那些自愧不如的人，因为谁对软件了解多少，如何了解，必定会在每一次的交流中得到充分体现，思如泉涌的人会体现，碌碌无为的人难道能够混过去吗？
谁做测试经理，自然是对软件最最了解的，自然是热忱度最高的那一位。所以测试经理应该是在团队运行一段时间后逐渐，自然形成的。相信这样的测试经理会是一个拥有一颗善良的心的，关心团队中每一个成员的好人，更不会做出“皇帝”的样子来，“地主”的样子来。
人心凝聚了，当然也不会有人总是离职，有那么好的职员，团队也不会那么容易裁员。而离职的人，一定是希望有更高的收入，不在乎自己辛苦钻研的软件的人，也就让他去吧。
如果您说，您在一家公司是测试经理，因此您希望在新的公司也要做测试经理，我想这个愿望不太可能立刻达成。因为您要做的事情太多太多，您要成为整个团队的主心骨，您要成为这个软件的专家，您不能懈怠。
如若您碰巧真的是立刻达成了此愿，那么请尊重每一个人，尊重每一个组员，让他们为软件付出的同时得到您真诚客观的鼓励，并将他们的成果转换为您自己的idea，与大家密切分享，并时刻努力，这样下去，团队将在您的带领之下蒸蒸日上。
而在您离职的时候，请将您的职位传授给最最了解这个软件的人。所谓公道自在人心，相信这会是您气度的体现，相信上天还会因此而继续保佑公司，保佑您！
最后，我想，敏捷测试适合长期的项目，因为它有一个潺潺流水化田园的过程，但是对于短期项目的同学们，你们可要做好继续奋斗的准备，因为路就在脚下，永远不需要气馁，永远不需要低头，曙光是前方明亮的，上天会保佑不断奋斗的人，51testing是精神家园。 对于长期项目的人亦是如此。
不管是长期项目，还是短期项目，都是一个锻炼的过程，对于人生来说，都是一段回忆，而人生的田园需要您不断的灌溉，用真诚，友善的心来面对一切事物吧。
这就是人生中的潺潺流水化田园的寓意所在。
版权声明：本文出自 wchair 的51Testing软件测试博客：http://www.51testing.com/?153101
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
一、页面上对引起 大量数据提交的 按钮/链接 点击一次后， disable
需求：
对于重要的表单、数量庞大/响应慢的系统，在做提交时， 又有页面还在loading状态， 此时连续做两次点击， 经常引起各种报错，这种情况下， 需要提出 对 按钮/链接 点击一次后， 做 disable
1）、查看页面源代码是否有脚本控制，例如：
<a href="javascript: $('#next').val('true'); buttonDisable();headerFormSubmit();" type="submit" class="btn" id="nextButton"> Next </a> function buttonDisable(){ $("#nextButton").attr("disabled", "disabled"); } |
2）、对脚本进行调试，
可以借助firebug工具，在Script Tab上，在$("#nextButton").attr("disabled", "disabled");这行脚本设置disable， 点击nextButton，检查运行到断点处停止，按钮无法再次点击。运行断点后， disable解除。
1）、从数据库检查起， 检查相关表： 原表、历史表、与其同步库的表 有没有都添上该字段，并且注意在每个表中， 字段类型是否统一
2）、校验：考虑字段本身类型， 判空、边界、唯一性、特殊字符、正确性允许的data
特别， 在做判空时，若字段不允许为空时，考虑： 需要提交脚本初始化历史数据set dafault value
3）、流程覆盖：考虑该字段覆盖到哪几个相关页面， 测试到整个流程， 每个页面校验要一致；
三、查log测试的几个操作
一般情况下， 项目都部署在linux环境上， 测试时， 有些需要查log， 或者有些服务需要自己去重启， 此时就需要一些基本的linux操作命令：
1）、首先连接到linux系统的机器上，可以使用putty软件， 要有 服务器地址+端口+协议 loginName+password，就可以登录
2）、cd到脚本或者log放置的文件夹位置去重启服务或查看log，还有一些常用的命令
less 文件名(W向上翻页、F向下翻页，Shift+F自动翻页，Ctrl+C停止自动翻页)；
grep "findString" 文件名；
执行脚本： ../脚本名 或者 sh./脚本名