摘要：
“你在测什么”，我现在耳边总是回响着那句话。因为无论我们现在做得多么深入，总是无法摆脱我们实际面临的问题，我们到底要测些什么，才能保证软件的质量。想想小时候我们做数学考卷，我们是如何保证答案的正确性的，无非是要么每一步再算一遍，要么是换种方法再求证一遍。如果换到软件开发的话，似乎开发只要做好足够的... 阅读全文
摘要：
最近的一项工作内容是比对数据，在这里把主要的一些思考过程和思路整理一下。 工作的目标是比对源数据和目标数据，逐字段逐条记录比较，找出不同的字段以及缺少的记录。由于数据量比较庞大，大约有七百多万条，源数据和目标数据分别是以文本方式来存储，因为数据量大，所以源数据和目标数据都会被拆分成多个文件，比如源数据会拆分成4个文件，目标数据可能会拆分成7个文件，每个文件可能都会有几十兆的大小，当然源数据和目标数据都会有唯一化一条记录的编号，类似数据库中的主键，可以通过此编号来进行比对。 由于数量实在太大，之前公司内部使用的EXCEL比对工具无法完全读取所有记录，无法胜任此项工作，因此寻求另一种比较有... 阅读全文
摘要：
一个项目如果有性能需求，那恭喜你，你接到活了，于是你开始着手开始性能测试。 首先第一步，你会先去了解业务，与此同时，产品或者项目经理也会给出他们的一些性能需求，和相关的指标要求，这个时候，你可以凭借你的经验和业务的实际情况深入一步挖掘量化性能指标，因为这直接影响到的测试终止条件，所以第一步尤为重要。可以根据以往项目的经验，给出你的一些测试通过标准，然后与相关人员确认，这样测试的目标就会非常明确，达到事半功倍的效果。 好了，你的目标有了，你该提供你的测试方法了，你心中有了对整个业务的认识和理解，它可能包含了几个流程，你脑海中开始勾勒你要测试的场景。假如说你测的是一个购物下单的业务性能，购物包含. 阅读全文
摘要：
不知道大家在做性能测试的时候，测试数据是如何准备的，笔者在实际工作中发现测试数据的准备会遇到以下几个问题： 其一，由于性能测试需要具备一定的并发量，尤其在实际系统所能承受最大并发量未知的情况下，测试数据的量也必须满足预期业务并发量的一个量的需求，如何准备这些量的数据是第一个问题； 其二，除了量的需求，数据也必须是符合业务逻辑的，是可用或者可测试用的数据，不是脏数据或无效数据。比如表与表之间是具备一定的关联关系，记录之间也有关联关系，所有的测试数据要符合这些规则，如何完全了解掌握这些规则，并且根据规则来生成测试数据是第二个问题； 其三，性能测试往往是安排在功能测试完成之后，在项目进度非... 阅读全文
摘要：
看了一篇关于软测的文章，文中说到软测的三个阶段，最后一个阶段是说以人为本的测试，笔者略有感触，所以也来谈谈“以人为本”的测试。 刚进公司的时候，笔者也非常痴迷于测试流程，CMMI之类，觉得流程框架之类很伟大，指引并驱动着我们的工作，每一项工作都应该有输入输出，并且符合标准，基线化犹如心中女神一般，充满向往，心醉神往。然而软件工程发展至今，即便像出现了各种各样的开发流程，但由于其复杂性，易变性，等诸多其它人为因素，导致整个软件工程中的各个阶段都不可能百分百符合要求，甚至连百分之五十都没有，于是最后到测试人员手中的交付物可能寥寥无几，甚至质量低下，这不能说是其他人员的不努力，只能说是现状仍然... 阅读全文
摘要：
很基础，但是却搞很久，在这里总结一下。class User < ActiveRecord::Base has_many :borrows has_many :books, :through => :borrowsendclass Book < ActiveRecord::Base has_many :borrows has_many :users, :through => :borrowsendclass Borrow < ActiveRecord::Base belongs_to :user belongs_to :bookend非常基础的多对多关系模型，需要注 阅读全文
摘要：
问题描述：场景中设置的vuser数量为1，每间隔一段时间做一次上传文件的操作，上传的文件内容为500条手机号码，导入后等待系统批处理执行手机充值业务。在测试结果中发现，上传文件的这个事务随着场景执行时间的增长，响应时间逐渐递增，但实际的并发用户一直为1，并未有并发上的压力，每次上传文件的时间间隔也有10分钟，为什么响应时间会逐渐增大。原因：然后手工进行一次业务操作，发现实际的响应时间确实非常长，但是之前操作的时候并未发现此现象。然后发现，原来在上传文件之后，系统会进行一个与之前上传的文件进行比对的操作，因此随着上传文件数量的增加，每次比对的数量就会增加，所以整个业务的响应时间会增长。但实际上此 阅读全文