运行

1）App安装完成后的试运行，可正常打开软件。

2）App打开测试，是否有加载状态进度提示。
3）App页面间的切换是否流畅，逻辑是否正确。
4）注册
　　同表单编辑页面
　　用户名密码长度
　　注册后的提示页面
　　前台注册页面和后台的管理页面数据是否一致
　　注册后，在后台管理中页面提示
5）登录
　　使用合法的用户登录系统
　　系统是否允许多次非法的登录，是否有次数限制
　　使用已经登录的账号登录系统是否正确处理
　　用户名、口令（密码）错误或漏填时能否登陆
　　删除或修改后的用户，原用户名登陆
　　不输入用户口令和重复点“确定/取消”按钮，是否允许登录
　　登陆后，页面中登录信息
　　页面中有注销按钮

　　登录超时的处理

02

应用的前后台切换

1）App切换到后台，再回到App，检查是否停留在上一次操作界面。
2）App切换到后台，再回到App，检查功能及应用状态是否正常。
3）App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
4）手机锁屏解锁后进入App注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
5）当App使用过程中有电话进来中断后再切换到App，功能状态是否正常。
6）当杀掉App进城后，再开启App，App能否正常启动。
7）出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。

8）对于有数据交换的页面，每个页面都必须要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。

03

免登陆

　　很多应用提供免登陆功能，当应用开启时自动以上一次登录的用户身份来使用App。
1）考虑无网络情况时能否正常进入免登录状态。
2）切换用户登陆后，要校验用户登录信息以及数据内容是否相应更新，确保原用户退出。
3）根据Mtop的现有规则，一个账户只允许登陆一台机器。所以，需要检查一个账户登录多台手机的情况。原手机里的用户需要被退出，给出友好提示。
4）App切换到后台，在切换回前台的校验。
5）切换到后台，再切换回到前台的测试。
6）密码更换后，检查有数据交换时是否进行了有效身份的校验。
7）支持自动登录的应用在进行数据校验时，检查系统是否能自动登录成功并且数据操作无误。

8）检查用户主动退出登录后，下次启动App，应停留在登录界面。

04

离线浏览

　　很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。
1）在无线网络情况可以浏览本地数据。
2）退出App再开启App时能正常浏览。
3）切换到后台再回到前台可以正常浏览。
4）锁屏后再解锁回到应用前台可以正常浏览。

5）在对服务器段的数据有更新时回给予离线的相应提示。

05

App更新

1）当客户端有新版本时，有更新提示。
2）当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动App时，仍出现更新提示。
3）当版本为强制升级版时，但给出强制更新后用户没有做更新时，退出客户端。下次启动App时，仍出现强制升级提示。
4）当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。
5）当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。

6）当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。

06

定位、照相机服务

1）App有用到相机，定位服务时，需要注意系统版本差异。
2）有用到照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。
3）测试照相机服务时，需要采用真机进行测试。

07

PUSH测试

1）检查Push消息是否按照指定的业务规则发送。
2）检查不接收推送消息时，用户不会在接收到Push消息。
3）如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到Push。在非免打扰时间段内，用户能正常收到Push。
4）当Push消息是针对登录用户的时候，需要检查收到的Push与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。

5）测试Push时，需要采用真机进行测试。
​如果有任何疑问，欢迎添加qq群测试入门大神 755431660 共同学习~
​​

“吐槽”一词，是指从对方的语言或行为中找到一个漏洞或关键词作为切入点，发出带有调侃意味的感慨或疑问。普通话里相当于相声的“捧哏”。

那么为什么要谈的是测试如何提交有效缺陷却说到“吐槽”去了呢，二者之间是否有什么联系呢？大家不妨先思考一下，下面进入正题：

大家对吐槽都不陌生，可以说每天都在吐槽，而大家每天吐槽的点基本上都差不多。比如：为什么我找不到功能测试的好工作呢；为什么我在公司里不被重视呢；为什么我提交的缺陷开发总是不乐意改呢，等等。其实这些吐槽都是比较表面的，没什么作用的吐槽，更像是一种抱怨和茫然。

不知道大家做测试的时候有没有遇到一个现象：

当你提出一个问题，开发会不认可你，或者客户也不认可你。

你就会说公司软件bug那么多，大家又不接受我提交的缺陷，那我有什么办法。

最后结论是：这公司不适合我，我的工作不受重视。

但是大家更深层次的想过问题的根源吗：

1、你提交的bug到底是不是bug？

2、开发为什么要为你提出的问题去花时间去改？

所以最重要的问题就是：当你提交bug给开发，让开发去改的时候，如果你不能让他信服，人家凭什么配合你去改这个BUG？

所以说回来我们日常的吐槽，每个人都会吐槽，但是并不是每个人都能吐槽到正确的点上。

其实很多事情都是存在争议的，并没有绝对的对与错，看待一个问题更多的是站在不同的角度和环境下能得出不同的结论。

那么在这么一个前提下，我们测试工程师的工作就显得比较富有意义了，因为软件测试是一种过程，在这个过程中，你需要做的就是找出缺陷，让开发改掉它，并得出软件质量能达到预期的最终结论（也就是上线）。

而且不管你现在做的功能测试，还是将来要做的接口、自动化、性能等等，你要考虑的首要问题都是如何提交bug以及让开发人员能心甘情愿的改掉这个bug，最牛逼的就是你提出一个bug，开发不但不反感还觉得你提的bug避免了未来可能会出现的事故。一个好的测试工程师总能做到这点，而且他总是团队里面的“润滑剂”，协调好开发、产品、运维之间的关系，贯穿于软件质量生命周期的全过程。

是否能有效地提交缺陷始终是界定一个测试人员的标准，而测试人员掌握代码知识也是为了更好地进行有效缺陷地提交。了解一下测试大师们是如何优雅地提交bug，在团队中混得如鱼得水，加群记得备注（缺陷），希望大家可以一起交流进步。

下面帮大家梳理一下从有效吐槽到有效缺陷的转变过程：

一，我们为何要吐槽（提缺陷）？

我们吐槽可能有很多原因，基本上可以总结为下面三点：

• 主观意识的提升

首先你会意识到与自己有关，与我无关的事情没人会去吐槽，或者说根本不知道要怎么吐槽好。突然想到这也可能会是一个尬聊的原因，如果你根本不了解一个人，他和你的槽点都不一样的话，两个人一定是没话说的。

其次意识到自己的责任和义务，比如在测试人员在公司上班的时候，就算你不想吐槽，为了工作的正常进行，你也不得不吐槽（提缺陷）。

• 为了工作环境的和谐

人人都是有自己的思想的，不可能大家不进行交流也能把工作做好，大家都需要把自己的想法说出来，表明自己工作中需要得到的帮助和协调，然后再一起努力并最终完成工作。

• 证明与表达自己

基本上每个人都预测过某些事情，比如他如果不这么做，就会怎么怎么样。通过自己的得到的信息资源的整合，做出一个预测其实也是一种知识的体现。

二、如何进行有效吐槽（提缺陷）

• 吐槽要吐到点上

1. 内容准确：作为一个测试工程师需要保证提交的缺陷内容上是准确的，如果开发看到都不知道你写的缺陷是什么那怎么修改。
2. 结果清晰：要把缺陷的结果清晰的描述出来，更加方便开发知道哪里出错，定位缺陷做出修改。不要只考虑自己工作的完成，开发花时间定位bug浪费的是大家的时间。
3. 符合逻辑：提交缺陷的时候一定是要符合逻辑的，问题的出现总是有前因后果，不可能因为我努力学习所以他考上了大学。

• 吐槽要引起共鸣

1. 代表大多数人的想法：要为自己的观点树立坚实的群众基础，如果大家都认为你是对的，工作就能很轻松的进行下去。但是不是你找出一个缺陷它就一定是一个缺陷。
2. 制造不同观点的讨论：也可以提出不同观点让大家来讨论，特别是你自己都不确定是否是缺陷的时候，提前发现总比被开发怼回来强。

三、吐槽和缺陷

吐槽的主要原因是每个人看待问题的方式和维度不同，它一般是基于支持的体系、你的大局观，你的利益。举个栗子，我是火箭的球迷那我肯定是要为火箭说话的，吐槽的点都是裁判判罚的是否对火箭有利。这是基于一个球迷的角度。

缺陷和吐槽要有一致性。缺陷的提出总是基于公司的利益，为了让公司的软件质量更高你需要提缺陷。那么基于软件技术提缺陷你能否做到测试左移？你能在系统测试级别还是在集成测试级别还是在单元测试级别甚至在需求级别就能找到缺陷？基于用户需求提出缺陷成本是很低的，但这需要你不断的思考。

比如说钉钉，钉钉有个功能是已读回执，老板发了一条信息，只要你点开了老板就知道你已经读取了这条信息，这会给你压力，让你尽快回复老板的信息。你可能觉得这个功能很烂，给你造成了压迫感。但是从整个使用环境来说这能有效地提升工作效率，增强公司上下沟通能力。

很多设计都是基于吐槽而来的，比如产品需求分析的时候，有人吐槽说以后使用的人变多了怎么办？那么这就是一个有效的吐槽，开发人员会根据将发生的情况做出合理的设计避免负载严重。

四、有效缺陷

有的缺陷提的太表面，比如字体大小不一致，选择框一个上一个下。很多时候我们提缺陷的时候，业务不够精通不能站在用户的角度去说服开发的时候，那么这时候你需要的就是考虑用技术。所以说现在做测试为什么越来越需要开发的能力，你需要懂得调试的功能，只有这样你才能明白这是底层的问题还是表面的问题。

比如点击提交失败，开发一般是不乐意改这样的bug的，因为你的缺陷不够有效，不能结合相关的数据定位到问题的所在。开发要花很多时间帮你排查这到底是业务问题还是底层问题。所以为什么功能测试真的很轻松，因为这都是别人花了大量的时间帮你把本来属于你的工作任务完成掉了。可能你不会认同我的观点，但事实就是这样，开发和测试和运维的界限不是那么明显。

当开发觉得他可以自测试，自验证的时候他就可以把你干掉了，因为你根本没有什么存在的价值。而所谓的开发不能测试自己的程序，他只要把程序再给其他开发再测一遍就行了。

因此测试人员在devops团队的时候，通常都会有一种感觉，就是自己的存在价值太低了。在整个团队进行快速迭代敏捷开发的时候本身留给测试的时间就不多了，如果你不能快速，准确定位问题并提交。在一周迭代一次的版本中，那确实没什么存在必要。

那么，作为软件测试工程师的你，将会如何选择未来的路？

更多测试经验+测试问答，可添加 qq群 测试入门到大神 我们共同进步~

首先我们来想下测试用例的前世今生：

1.测试用例因何产生？

2.测试用例为谁而写？

这两个问题我们各用一句话来回答：测试用例是产品原型下的衍生物，为想要了解这个系统（需求）的人而写，且随着产品原型的调整及时更新。

了解一个系统更多时候不是从已经使用的案例中抽取其中之一作为了解对象，而是从需求原型中，梳理分析，整合成测试用例来帮助用户去理解。而一个覆盖性强的测试用例，可以保障系统的强健性。

​

从大的方面讲，测试用例分为功能测试、非功能测试两个方面；

增删改查是基础，也是重中之重。这一点不仅我们测试人员重视，研发也同样了解，因此在提测之前，增删改查的部分大多数情况下已经由研发人员验证过一次。若非如此，测试人员还是有权力拒测或执行一键驳回的，直到醒目达到最基本的提测状态。

GUI页面检查以及元素验证。这类验证几乎在我们的日常工作中均有涉及，从设备来讲PC项目，移动端（Android，IOS）；从系统应用来说，办公系统，娱乐网站，直播平台，交易系统等等，均离不开用户与系统之间的交互。可以说，GUI部分的验证占据了测试人员大量的工作时长，所以我们回顾罗列的测试用例，大范围陈述了页面元素的验证：字符限长，非法验证，非空校验，提示语，二次弹窗，非空集合等等。这部分工作繁琐冗长，往往是研发人员忽视的部分，稍有不慎就会引发问题，需要测试人员从不同角度多次验证。

数据准确性。我们在验证数据准确性的时候，更多侧重于已经产生的数据，在数据的生命周期中验证其准确性，往往忽视了数据的初始化及消亡两个极端。以往我测试过一个WEB系统，测试数据是由研发人员导入的线上数据，但是在测试过程中，发现这批线上测试数据的生命周期并没有异常，反而是我自己通过系统导入的初始数据，在接下来的页面交互中出现不少问题。这就涉及到了前端如何处理初始数据的问题，假如自己同样忽视数据的产生，上线后，就是引发测试事故的重要漏洞。

业务逻辑的正确性。这个问题往往是产品原型产生初期就被遗漏的问题，带来的后果是用户体验度差。举个例子，用户通过手持端进入领取优惠页面，一系列验证用户操作完毕后，提示领取成功。现在，作为一个用户，大多数情况下应该会找使用优惠券的入口，或者去查看这个优惠券如何使用。然并卵，产品经理忽视了最终的体验对象，只是将用户领取优惠完成来当做这一动作的终结。所以说，测试不仅仅是去验证产品原型，还要考虑业务逻辑是否正常。

　后端的特殊验证。这类测试多出现在前端UI界面简易，后端判断复杂。例如，文档的上传下载，上传一批手机号到服务器，实现发送短信的目的。给出几个错误验证的例子，一，导入Excel文件中，同一个手机号连续输入两次，查看发送短信条数（此部分验证的是短信攻击性）；二，导入Excel文件中，同一个手机号不连续输入多次，查看发送短信条数（此部分验证的是数据去重性）。

业务关联性。例如数据变更等信息同步问题时，有关联的业务之间产生联系，会出现此类验证。举个例子，ES数据实现同步功能，在首批数据导入后，不同业务之间共享同一批数据，当某一条数据进入生命周期时，此时不仅要观察当前数据库中的数据变化，还要观察使用ES技术同步后的数据是否一致。

　并发操作。此类问题的产生情景在较多用户共享同一批数据，且同时对此数据进行同一功能操作下产生的问题。此类问题需要测试人员使用两个浏览器即可完成问题复现，左右各开一个显示器，同时对一个数据进行编辑后的提交，查看界面反馈。

以上罗列的功能测试点和处理的例子尚有不完整之处，在此不再多做赘述。功能测试过程中，上述常见测试要点，酌情参考，每个测试需求不同，不能统一照搬，在原有经验的基础上，更进测试方法，达到测试目的。

此外，除了功能测试还有非功能测试需要在梳理测试用例时覆盖到。

　浏览器兼容。目前市场上广泛使用的浏览器较多，Firefox，Chrome，IE，UC，猎豹，Opera等等，在测试过程中，摘选主要2-3个应用广泛的作为重点测试对象，其次，酌情考虑项目参与人员的意见，如研发或产品人员，并入测试范围。

　压力。目前各个公司有自己的压力测试平台，考虑当前项目的使用人数后酌情进行压力测试。

　接口。更多时候是在界面上不能完成增删改查操作时，使用手动接口测试，查看返回值。

　安全和风险。这个也要看所测试的项目需要关注此类问题。

此外，测试用例评审，测试用例更新完善等环节也是对测试用例的查漏补缺。

覆盖性强的测试用例是需要我们针对项目具体制定的测试用例，以上所梳理的测试点，是在大多数工作中需要考虑的方面，总而言之，言而总之，测试用例不能照搬照抄，可以参考不同测试用例的思考点，以这种思考的方式来当做当前项目的切入点，达到测试目的：发现程序的错误。

0. 文档介绍

提示：请用户根据项目的实际测试状况，裁剪本测试用例模板。

0.1 文档目的

0.2 文档范围

0.3 读者对象

0.4 参考文献

提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：

[标识符] 作者，文献名称，出版单位（或归属单位），日期

例如：

[AAA] 作者，《立项建议书》，机构名称，日期

[SPP-PROC-ST] SEPG，系统测试规范，机构名称，日期

0.5 术语与缩写解释

　1. 接口－路径测试用例

1.1 被测试对象（单元）的介绍

1.2 测试范围与目的

1.3 测试环境与测试辅助工具的描述

1.4 测试驱动程序的设计

1.5 接口测试用例

1.6 路径测试的检查表

2. 功能测试用例

2.1 被测试对象的介绍

2.2 测试范围与目的

2.3 测试环境与测试辅助工具的描述

2.4 测试驱动程序的设计

2.5 功能测试用例

3. 健壮性测试用例

3.1 被测试对象的介绍

3.2 测试范围与目的

3.3 测试环境与测试辅助工具的描述

3.4 测试驱动程序的设计

3.5 容错能力/恢复能力测试用例

4. 性能测试用例

4.1 被测试对象的介绍

4.2 测试范围与目的

4.3 测试环境与测试辅助工具的描述

4.4 测试驱动程序的设计

4.5 性能测试用例

5. 图形用户界面测试用例

5.1 被测试对象的介绍

5.2 测试范围与目的

5.3 测试环境与测试辅助工具的描述

5.4 测试驱动程序的设计

5.5 测试人员分类

5.6 用户界面测试的检查表

6. 信息安全性测试用例

6.1 被测试对象的介绍

6.2 测试范围与目的

6.3 测试环境与测试辅助工具的描述

6.4 测试驱动程序的设计

6.5 信息安全性测试用例

7. 压力测试用例

7.1 被测试对象的介绍

7.2 测试范围与目的

7.3 测试环境与测试辅助工具的描述

7.4 测试驱动程序的设计

7.5 压力测试用例

8. 可靠性测试用例

8.1 被测试对象的介绍

8.2 测试范围与目的

8.3 测试环境与测试辅助工具的描述

8.4 测试驱动程序的设计

8.5 可靠性测试用例

9. 安装/反安装测试用例

9.1 被测试对象的介绍

9.2 测试范围与目的

9.3 测试环境与测试辅助工具的描述

9.4 测试驱动程序的设计

9.5 安装/反安装测试用例

本文来源：http://www.51testing.com/html/98/n-3724598.html

　　那么对于Web应用来说，该测试哪些方面，该如何测试呢？来看看作者 Abhimanyu Ghoshal给出的这些建议。
　　一、首先应该测试什么？
　　当测试Web应用的时候，首先要明确你的应用要用来做什么，比如帮助用户编辑照片、发送票据、联系朋友或跟踪社交媒介等。你通常需要着眼于这四大领域：
　　1.  功能性测试
　　几乎所有的用户都期望自己所使用的Web应用功能准确、迅速、一致。这就意味着开发者必须精益求精，帮助用户实现某种形式上的结果。下面是一些需要全面测试的常见的功能元素：
　　表单：无论是反馈调查、创建任务计划，还是订阅新闻，都需要用到表单。你需要检查提交操作是否正常，是否能够提交连接并提交到你的数据中，所有字段是否能够接收输入的内容。
　　文件操作和计算：这其中涉及图像和文档的上传、编辑、计算功能和正确的输出值。首先，要确保你能想象得到会有多少用户会使用你的应用，并尽可能地针对他们进行调节。另外，要考虑一下如何使你的App更有效地计算并显示出结果，给用户提供一个更加流畅的用户体验。
　　搜索：如果你的应用允许用户搜索内容、文档或文件，那么就要保证你的搜索引擎能够索引这些信息，并定期更新，以便能够让用户实现快速查找，并根据查找条件快速显示相关结果。
　　媒体播放组件：测试音频、视频、动画和互动媒体播放组件（如游戏和图形工具）的时候，这些组件应该像预期的功能效果一样，在加载和运行的时候不能影响（暂停或减缓）其他应用的运行。
　　脚本和类库：确保你的脚本（比如图像显示或Ajax页面加载）在各种浏览器之间是相互兼容的，因为不同的用户可能会使用不同的浏览器访问你的应用，同时你可以测量不同浏览器的加载时间来进行性能优化。如果你的脚本只能和某些浏览器相互兼容，那么就要确保应用中的其他组件有更好的性能，这样所有的用户就能得到最好的应用体验。
　　最后，就是要全面检查其他组件的功能，包括提示系统、用户配置文件和管理仪表板等。

更多内容请关注51testing软件测试网...

　　因为存取频繁，所以这几个表的数据存在内存中，更新数据后使用，语句来进行内存更新
　　当然执行这个命令需要reload权限
FLUSH PRIVILEGES

　　用户登录时需检查，mysql.user中的user host pass 三个字段，如果允许任何主机外部链接可以吧host设置成%
　　用户登录通过后，mysql会自上而下的检查用户权限，首先在mysql.user中读取对应用户的权限。

51Testing软件测试论坛圣诞活动火热进行中 ipad 大奖等你拿  详情请上51testing软件测试网论坛

开发或者测试互联网产品的过程中，同学们一定遇到过connection timed out和socket read timed out两种和网络相关的异常。今天我们并不分析引起这些异常的原因，也不谈发生异常以后的解决办法，我们来说说如何制造这类异常，从而模拟对应的异常场景。
　　了解tcp协议就知道connection即建立连接的过程，其实和socket read即传输数据的过程并没有太大的差别，两者都是请求应答模式，而只是前者的请求数据量很小而已。要使两者超时，我们可以采用相同的方法即限制网络传输的带宽来达到目的。
　　Tc即traffic control就是这样一款能够限制网络流量的工具。Tc中主要的概念包括类class和过滤器filter。
　　我们可以用class把网络设备的带宽划分成不同的区间
　　tc class add dev $DEV parent 1: classid 1:11 htb rate 90mbps ceil 100mbps
　　tc class add dev $DEV parent 1: classid 1:12 htb rate 90bps ceil 100bps
　　如上，11这个class对应的带宽为90到100mbps，12这个class对应的带宽只有90到100bps。划分好了class，我们就可以用filter把符合特定条件的数据包归入不同的class中
　　tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32 match ip sport $PORT 0xffff match ip dst $IP flowid 1:12
　　如上就把源端口是$PORT，目的地址是$IP的数据包归入12这个class中了，这样就把符合该条件的数据流量限制到了90到100bps。在正在运行的系统中开启上述tc限制，即把特定数据流限制到一个极小值，我们就能模拟出connection timed out异常了。关于tc更详细的教程可以参考1、2。
　　那么socket read timed out异常又该如何模拟呢，我们怎么才能区分建立连接和数据传输这两个过程，tc工具还能满足我们的需求吗？在寻找问题答案的过程中，另一个linux内核组件iptables进入了我们的视野。
　　Iptables是linux系统中常用的防火墙组件，功能十分强大，网上有十分丰富的资料。由于其能够识别数据包中的syn、ack等标志位，故能把建立连接和后续的数据传输过程区分开来。
　　iptables -A INPUT -p tcp --src $IP --dport $PORT ! --syn -j DROP
　　如上，在目的机器上加入该条iptables规则，可以实现将未设置syn标志位的数据包丢弃的功能，这样连接能够建立完成但后续的数据传输将无响应。
　　另外，Iptables具有一种连接跟踪机制，即能够记录连接的状态。这些状态分别是NEW、ESTABLISHED、RELATED和INVALID。我们可以利用该特性实现相同的效果。
　　iptables -A INPUT -p tcp -m state --state ESTABLISHED -s $IP --dport $PORT -j DROP
　　如上，在目的机器上加入该条iptables规则，当匹配了ip和端口，并且数据包所对应的连接状态是ESTABLISHED时将其丢弃。
　　至此read timed out异常也能轻松模拟了。Tc和Iptables是linux网络模块中强有力的工具，除了能够利用它们开发功能，也能够在网络异常测试中发挥关键的作用。

51Testing软件测试论坛圣诞活动期待您的参与~ipadmini 惠普平板 京东购物卡等你来抢！

　　1.测试脚本组织上不太了解应用在实际项目中怎样的组织编写方式，如何定义action、事务，检查点一般使用在什么情况下，是用文字、图还是函数，是否有规范的要求。

　　先简单解答一下什么是Action 什么是事务：

　　Action :是一组事务或是一个独立的事务，一个Action可能和服务器有多次交互，完成活动目的

　　Transaction:在Loadrunner 中定义是用来度量服务器相应VU的请求相应时间。

　　检查点：在每次事务提交后，服务器端都会返回响应信息，要通过对相应信息的检查来确认每次事务请求处理结果是否正确。具体采用什么样的检查方法，根据实际情况来确定，返回的是文字就验证文字，返回图片验证图片，返回数字验证数字。

　　2.测试场景中哪些监控器是常用的监控器，监控器中的监控指标也不太清楚常用的监控指标有哪些。

　　监控指标分为系统监控，应用监控，事务监控

　　事务监控：必须要监控的是事务平均相应时间，每秒处理事务数，事务成功率，事务失败率等

　　系统监控：分为CPU使用率，内存使用率，磁盘IO，网络IO 等具体指标说明见

　　应用监控：JVM，web服务器，apache IIS，数据库 oracle ，informix，中间件tuxedo weblogic等等

　　每种应用的架构不一样监控的指标也不一样，如tuxedo 使用MQ技术那么监控要看其消息对列大小变化，队列越长说明处理能力下降。

　　具体指标代表什么意思可以去网上查资料。上次发的文档里有一篇文章《Computer Performance Monitoring》是专门介绍监控指标的可以参考。

　　3.测试场景中如何使用IP Spoofer，什么情况下使用。

　　在一些系统中为防止网络攻击，对请求IP地址进行限制，当多个并发时候会拒绝请求。在这种情况下通过Loadrunner IP欺骗技术，构造数据包时候修改来源IP地址欺骗服务端IP过滤功能。

　　4.测试场景在项目中一般是否定义服务水平协议(SLA),在什么情况下需要使用SLA。与基于目标的场景有什么区别。

　　SLA是针对事务级别做阀值设置，设置数据在结果分析时有效

　　目标场景的设置是对控制台有效，影响测试执行。

　　5.测试分析中没有如何分析的思路，一般对哪些图表进行怎样的分析能够分析出问题。建议将‘Load Test(loadrunner).ppt’中的‘应用Loadrunner测试心得’进行培训。

　　这个可以安排时间组织讨论。

　　6.LR11中在录制脚本过程中没有录制下thinktime，而且没有找到在哪里设置录制时记录thinktime的地方。

　　11没找到设置位置，这个问题保留吧。如实在需要直接手工插入think时间。

　　7.在使用ip 欺骗时候如何判断vu用户使用的虚拟ip  

          更多精彩文章请上51Testing软件测试网查看

阅读全文

阅读全文

　　（1） 掌握主流嵌入式微处理器的结构与原理（初步定为arm9）

　　（2） 必须掌握一个嵌入式操作系统 （初步定为uclinux或linux,版本待定）

　　（3） 必须熟悉嵌入式软件开发流程并至少做一个嵌入式软件项目。

 阅读全文

        以我个人的经验，学习java应分以下几个阶段：

阅读全文

　　--数据操作

　　SELECT --从数据库表中检索数据行和列

　　INSERT --向数据库表添加新数据行

　　DELETE --从数据库表中删除数据行

　　UPDATE --更新数据库表中的数据

　　--数据定义

阅读全文

阅读全文