Test_star Test_star
关注数: 0 粉丝数: 9 发帖数: 44 关注贴吧数: 3
关于软件测试学园 软件测试学园是个学习软件测试的小班，我们在腾讯课堂开课，想学习软件测试的童鞋可以报我们的就业班哦
欢迎软件测试学园群的童鞋在这里提问 想学习软件测试的童鞋可以在这里发帖，本人有空的时候会回复的
如何准备性能测试数据 在软件性能测试过程中，测试数据的准备是一个非常系统化、工作量非常庞大一项工作。如何准备支持不同业务操作、不同测试类型的大量测试数据来满足负载压力测试的需求是性能测试过程中经常面对的一个重要话题。 　　中国软件评测中心在历来的性能测试过程中重视性能测试数据的准备工作，从而保证了性能测试工作的顺利进行，也保证的性能测试结果的准确性和有效性。中国评测在近期开展的某金字工程非功能测试项目使作者了解到数据准备工作得系统性、复杂性，由此作者将性能测试数据准备工作简单归纳，希望对从事性能测试工作的测试人员有一定的借鉴和参考。本文重点介绍一下性能测试要准备哪些数据及准备数据的常用方法。 　　一、需要准备的数据种类 　　在执行负载压力测试前，一般需要准备三类数据：初始化数据、铺底数据（历史数据）和参数化数据。 　　1. 初始化数据准备 　　业务系统安装部署完成后，并不能马上进行相关业务的负载压力测试，需要对系统进行初始化操作，系统初始化主要对增加系统中的基本角色信息、机构信息、权限信息、业务流程设置等数据，这些数据是业务系统能够开展相关业务的基础。初始化数据是为了识别数据状态并且验证用于测试的测试案例的数据，需要在业务系统搭建完成后按照系统实际运行要求实施导入，供测试中使用。 　　2. 铺底数据(历史数据) 　　当业务系统刚刚上线的时候，由于数据库中数据量相对较少，系统整体响应时间很快，用户使用体验较好。但随着业务的持续开展，业务系统数据库中的数据量会成倍的增加，业务系统的相关操作响应时间会因为数据库中业务数据的快速增长等而变的越来越长，用户使用体验会变得很难忍受，因此，在性能测试时，需要加入相当规模的铺底数据，来模拟未来几年业务增长条件下的系统相关操作的性能表现。例如：要测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。 　　3. 参数化数据 　　在负载压力测试过程中，为了模拟不同的虚拟用户操作的真实负载情况，同时由于业务系统中大部分业务操作的交易数据不能重复使用，因此，需要为不少用户输入信息准备大量参数化数据，以保证正常实施负载压力测试。参数化测试涉及的范围很多，例如，模拟不同用户登录系统，需要准备大量用户名及相应密码参数数据；模拟纳税人纳税申报，需要准备大量的纳税人识别号、纳税人内码或纳税人系统内部识别号等参数数据，这类数据准备要求符合实际运行要求并且保证数据表之间的关联关系。 　　二、数据准备的常用方法 　　1、对于业务系统的初始化数据一般采用手工创建和数据导入的方式来完成，其中新建系统或者新旧系统差异较大的这类系统需要手工创建，而具有遗留系统的升级系统很大一部分可以通过数据导入的方式完成数据初始化工作。 　　2、铺底数据的准备通常数据翻倍的方式来完成。 　　数据翻倍需要采用找出数据库之间的表结构关系，弄清楚数据库里面主表和附表之间的关系是一对多或多对多，对于一对多关系的要推算一张主表的一条记录大概对应附表的几条数据，并据此把数据翻倍。具体实施数据翻倍时可以利用 CPU 的运算能力高效率地生成的数据，并导入数据库，从而产生出所需的铺底数据。或者通过编写和执行存储过程来完成。 　　准备铺底数据要注意以下几个原则：1.数据库中的数据量要比内存大上若干倍；2.数据在准备的时候，要保持原表的约束关系；3.每张表的数据量要符合真实情况。 　　3、参数化数据准备一般采用从数据库提取现有数据或者人工添加数据的方式来完成。 　　1）使用数据库现有真实数据。如测试100个用户同时进行纳税申报的情况，如果已有100个真实的用户账号信息，没个用户也有可操作的若干组纳税户，那么在准备数据时，就可以直接调用这些现有的数据来完成。 　　2）人工添加准备数据。以登录测试为例，如果现在没有100个现成的真实用户账号信息，那么就需要自己手动去创建，当然创建的方式就有很多种了，可以使用LoadRunner进行创建，也可以写一段小程序去创建，当然还可以选择手动创建。但是当数据量很大时，选择手动创建就是一件很困难的事，如测试BOSS（Business & Operation Support System）系统，几千个虚拟用户并发，如果手动去准备这些数据就很麻烦。因此对于并发度较高的业务，我们可以采用数据库后台对可用数据进行数据翻倍的方式来完成，也可以通过LoadRunner执行并发测试来完成，例如可以通过执行用户注册并发测试来完成新用户创建。
软件测试要做多久是估不准的？ 很多开发人员在开发软件时, 会说他们的工作很难估得很准, 因为 spec 常常更改, 或者 spec 不明确, 所以无法确保要做多久。 测试的工作就能估得很准吗? 很多人会以为开发人员都已经写好了, 测试人员只是把 test cases 跑完就好, 哪有什么不确定的. 　 假设, 我们要执行 40 个 test case. 每个 test case 需要执行 2 分钟. 　 如果我们遇到 bug, 测试人员需要花 6 分钟来确认错误原因; 或者是否还有相关的问题; 或是确保这真的是 bug 而不是 user error; 或者是花时间把 bug report 写完. 　　所以, 如果没有找到任何 bug 的状况下, 40 个 test case 要执行完, 测试人员需要花 80 分钟. 　　当测试人员遇到第一个 bug, 他需要花 2 分钟执行, 外加 6 分钟去进一步探索相关事情. 因此在总时间不变的状况下, 他只能执行完 36 个 test case, 加原先那个, 在相同时间下, 他最多只能执行 37 个 test cases. 　　( 80 - (2+6) ) / 2 = 36 　　如果再遇到下一个 bug, 测试人员又要再花 8 分钟. 所以剩下的时间, 测试人员只能在执行 32 个 test case, 所以加上原先 2 个 test case,在相同时间下, 只能执行完 34 个 test cases. 　　( 80 - (2+6) - (2+6) ) / 2 = 32 　　See… 找到越多 bug, 会让测试需要花越多时间, 无法保证他何时可以做完. 　　所以, 所以, 所以 ….. 测试人员做不完...... 　　原来是开发人员的错, 没事产生这么多 bug XDDDD
软件测试常见风险有哪些 在测试工作中，主要的风险表现有以下几点： 　　（1）需求风险。对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，同步时存在误差。 　　（2）测试用例风险。测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求；测试用例没有得到全部执行，有些用例被有意或者无意的遗漏； 　　（3）缺陷风险。某些缺陷偶发，难以重现，容易被遗漏； 　　（4）代码质量风险。软件代码质量差，导致缺陷较多，容易出现测试的遗漏； （5）测试环境风险。有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差； 　　（6）测试技术风险。某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期； 　　（7）回归测试风险。回归测试一般不运行全部测试用例，可能存在测试不完全； （8）沟通协调风险。测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期； 　　（9）其它不可预计风险。一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。 　　以上是测试过程中可能发生的风险，其中有的风险是难以避免的，如缺陷风险等。有的风险从理论上可以避免，但实际操作过程中出于时间和成本的考虑，也难以完全回避，如回归测试风险等。对于难以避免的风险，我们的目标是将风险降到最低水平。
集成测试与单元测试的联系 集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。 　　集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。 　　集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。 　　集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。 　　所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。从图1可以看出，集成测试需要花费的时间远远超过单元测试，直接从单元测试过渡到系统测试是极不妥当的做法。
如何合理地减少测试工作量 减少冗余的测试 白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。 在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。 减少无价值的测试 无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。 如何“偷工减料” 有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。 “偷工减料”方法的测试优先级： 哪些功能是软件的特色？ 哪些功能是用户最常用的？ 如果系统可以分块卖的话，哪些功能块在销售时最昂贵？ 哪些功能出错将导致用户不满或索赔？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？ 哪些程序是全系统的性能瓶颈所在？ 哪些程序是开发者最没有信心的？
如果能够执行完美的黑盒测试，还需要进行白盒测试吗? 黑盒测试：从用户角度出发，根据规格说明设计测试用例，并不涉及程序的内部特性和内部结构，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试有两个显著特点： （1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以用。 （2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。 黑盒测试主要是为了发现以下几类错误： 1、是否有不正确、遗漏或额外的功能实现? 2、在接口上，输入是否能正确的接受?能否输出正确的结果? 3、是否有数据结构错误或外部信息（例如数据文件）访问错误? 4、性能上是否能够满足要求? 5、是否有初始化或终止性错误? 白盒测试：已知程序的内部结构，检查内部操作是否按规定执行。主要对程序细节进行严密检验，针对特定条件和循环设计测试用例，对程序的逻辑路径进行测试。通过在程序的不同点检查程序状态，确定实际状态是否与预期的状态一致。 白盒测试主要是想对程序模块进行如下检查： 1、程序的所有语句至少执行一次。 2、对所有的逻辑条件都能至少执行一次。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等。 从以上可以看出就算执行了完美的黑盒测试也是无法测试程序内部特定部位，另外当规格说明本身有误，也不能发现问题。而白盒测试能对程序的内部特定部位进行覆盖测试，所以黑盒和白盒测试为互补关系，结合起来进行测试用例的设计更为合理。 经验表明，通常在进行单元测试时采用白盒测试方法，集成测试采用灰盒测试方法，系统测试采用黑盒测试方法。
静态测试和动态测试的区别有哪些 静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。 动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。
自动化测试的优势有哪些? 快速 自动化运行测试比实际用户快得多。 可靠 测试每次运行时都会准确执行相同的操作，因此消除了人为的错误。 可重复 您可以通过重复执行相同的操作来测试网站或应用程序的反应。 可编程 您可以编写复杂的测试来找出隐藏的信息。 全面 您可以建立一套测试来测试网站或应用程序的所有功能。 可重用 您可以在不同版本的网站或应用程序上重复使用测试，甚至在用户界面更改的情况下也不例外。
如何清晰的描述BUG? BUG的基本属性都有哪些? 一个好的错误跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。好的故障描述应该包括十个基本部分：标题、项目、所属模块、优先级、重要性、异常等级、可重复性、现象、操作过程和附件。 ①标题 使用一两句话来描述错误，告诉经理、开发人员以及其他读者为什么应该关心该问题。好的标题应该着重于出现的bug现象。但是过于简洁易引起误导，使得原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。不重要的就描述比较轻微，例如：“联系人的email没有检查合法性”；重要的就要体现比较严重，例如：“填了运营商仍然提示运营商不能为空，使得无法进行下一步的操作”，会更容易让开发人员理解究竟是什么问题及其重要性，并及时处理。 ②项目 是指该错误属于哪一个项目，归哪个项目组解决，使不同的项目组看到和及时定位自己项目的错误。 ③所属模块 是指准确说明发异常等级生错误的模块，切忌发生错误指派模块，导致后续流程错误； ④优先级 分为以下4级：1级：“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求；2级：“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现；3级：“正常处理”，即进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的数据库等；4级：“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。 ⑤重要性 分为以下5级：1级：“非常严重”，表示缺陷不修改整个系统流程不能继续；2级：“比较严重”，表示缺陷不修改不影响系统其他流程，但是本模块流程不能继续；3级：“一般”，表示缺陷不影响流程；4级：“轻微”，表示缺陷可以延期解决；5级：“优化”，表示修改以后流程会更好。
软件测试中各种覆盖法的优缺点 语句覆盖 程序中每个语句至少都能被执行一次。 判定覆盖 程序中的每一个分支至少都通过一次（每个判定都取过真值假值）==也叫分支覆盖。 条件覆盖 使得判定中的每个条件获得各种可能的结果（真值假值）。 判定/条件覆盖 分支中每个条件取到各种可能的值(真假值)，每个分支（判定）取到各种可能的结果（真假值）。 条件组合覆盖 使得每个判定中条件取值的各种可能组合都至少出现一次。 路径覆盖 覆盖程序中所有可能的路径。 覆盖的优缺点： 语句覆盖法：可以很直观地从源代码得到测试用例，无须细分每条判定表达式 ；该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&&错误的写成了||，则上面的测试用例仍可以覆盖所有的执行语句。 一般认为“语句覆盖”是很不充分的一种标准，是最弱的逻辑覆盖准则。 判定覆盖法： 能够满足条件覆盖的要求，但是也不能对判断条件进行检查； “分支覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，则每个语句也就执行过了。但是，“分支覆盖”还是很不够的。 条件覆盖法：“条件覆盖”通常比“分支覆盖”强，因为它使一个判定中的每一个条件都取到了两个不同的结果，而判定覆盖则不保证这一点。 要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。 判定/条件覆盖法：分支/条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件。 条件组合覆盖法：上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径abe 路径覆盖法：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广 ；由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长(而指数级增长通常是设计算法时要尽力避免的)。
如何判断是否要进行自动化测试? 自动化测试并不一定总是比手工测试好， 在一些情况下手工测试更加合适，比如如果一个系统的用户交互变化非常频繁，这样的话自动化脚本需要经常重写，另外如果系统非常简单，用手工测试所花费的时间比创建自动化的时间要短，这样就没必要自动化。如果一个系统的进度非常紧，而且当前没有自动化，在这种测试进度非常紧张的情况下，手工测试是最好的解决方法。
什么是软件的可用性及可用性测试 可用性测试一般是在一定环境条件下（可用性实验室），让用户执行测试，观察用户的反映，找到系统的缺陷和需要改进的地方 国内现状：测试人员模拟用户 有些公司采用交换各项目组测试人员的方式组织专门的可用性测试 可用性测试可以从下面几个方面考虑 能否成功的完成一个任务 对于普通用户，完成典型任务需要多长时间 完成典型任务需要访问的的页面数 系统是否提供了层次结构明确、表达清楚的导航功能 对整个系统的感觉如何（形式） 信息是否正确、精确（内容） 帮助系统是否准确并且容易使用 系统是否提供搜索、网站地图等功能 页面下载时间用户能否接受
什么是冒烟测试(Smoke Test)? 简单的说，就是先保证系统能跑的起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费
用户文档的测试一般要关注文档那些特性? 1）、用户文档的完整性：用户文档应包含产品使用所需要的全部信息：（包括用户可调用的所有功能；所有边界值；如果安装能由用户来完成，则用户文档应包括安装手册；如果维护能由用户来完成，则用户文档应包括程序维护手册）； 2）、用户文档的正确性：用户文档中所有信息应是正确的，不能有歧义和错误的表达 3）、用户文档一致性：用户文档自身内容或相互之间以及与软件系统之间都不应相互矛盾。每个术语的含义宜处处保持一致，应保持95%的一致性； 4）、用户文档的易理解性：用户文档对于正常执行其工作任务的一般用户宜是易理解的；用户文档应条理清晰、功能模块明确、功能描叙详细易懂； 5）、用户文档的易浏览性：用户文档易浏览，相互关系明确，每个文档有目录和索引表；如果文档未提供印刷本，则应指明打印过程
Bug管理的一般流程 测试人员提交新的Bug入库，错误状态为New。 高级测试人员（测试经理）验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为 Closed，如没有解决置状态为Reopen。
1 下一页