软件测试技术归类--您擅长哪些呢？
软件测试技术水平划分有：手动测试，自动测试，静态测试，动态测试，功能(黑盒)测试，结构(白盒)测试等．而垂直划分有很多种，并且与水平划分相交．下面是归类小结：
1）手动测试－－验收测试，随机测试，Ａlpha测试，Beta测试，比较测试，兼容性测试，桌面检查，端到端测试，探索测试，直方图，增量集成测试，代码审查，集成测试，JAD，负载测试，突变测试，正交矩阵测试，帕雷托分析法，性能测试，缺陷历史预测试，恢复性测试，基于风险测试，运行图，健全性测试，安全性测试，统计概况测试，压力测试，结构化走查，系统测试，单元测试，易用性测试，用户验收测试。

2）自动测试--验收测试，基本路径测试，黑盒测试，自底向上测试，边界值测试，分支覆盖测试，分支/条件测试，因果图，比较，兼容性，条件覆盖，CRUD测试，数据库测试，决策表，端到端，等价类，异常，自由形式，灰盒测试，增量集成，集成，负载测试，突变测试，性能测试，正反测试，原型法，随机，范围测试，恢复性测试，三明治测试，健全性测试，安全性测试，状态转换，语句覆盖测试，压力，语法，系统测试，表测试，线序测试，自顶向下测试，单元测试，易用性，用户验收测试，白盒测试。

3）静态测试--代码审查，正交矩阵测试，缺陷历史预测，基于风险的测试，运行图，统计概况测试，语法测试，单元测试。

4）动态测试--很多了，不敲了，哪些不能动态测试的我列一下：随机，兼容性，端到端，直方图，JAD，正交矩阵，帕雷托分析，缺陷历史预测，基于风险测试，运行图，安全性，统计概况，单元测试。

5）功能测试--也很多，有测试经验的都可以说出来，自己理解吧。

6）结构测试--基本路径，自底向上，自顶向下，条件、分支覆盖，兼容性，数据库，桌面检查，灰盒测试，代码审查，JAD，负载，性能，恢复性，三明治测试，安全性，语句覆盖，结构化走查，表测试，线序测试，单元测试。
 

1.熟悉SAAS产品

IT人员配备和随需应变的咨询公司Bluewolf的共同创始人和负责人Michael Kirven说，SAAS（软件服务）知识在用人要求条件中的比例已经从三年前的5%提高到了35%。拥有这方面知识的人可能很快提高自己的薪酬，无论他们是否知道alesforce、Google Apps或者WorkDay。每一个人都需要知道这些产品如何适合当前的IT架构。

2.获得SAP知识或者经验

位于费城的人才和外包服务公司Yoh Services复杂战略和营销的副总裁Jim Lanzalotto称，他支持拥有SAP技术的人，因为SAP技术顾问的需求量和现有人员之间的缺口有3至4万。

3.获得一个行业的垂直的技术专长

Kirven说，做一个Java程序员或者一个熟练的.Net开发人员就是一件很好的事情。但是，随着系统越来越复杂，企业不仅需要这些人学些这些编程语言，而且还要了解具体的垂直市场知识，如金融、零售或者媒体，并且了解所有这些知识。

4.获得一个虚拟化项目

IT job board Dice网站称，它看到招聘列表中对虚拟化知识人才的需求在过去的六个月里提高了40%，特别是需要了解VMware技术的人。

5.提高你的商务技能

Lanzalotto认为，商务经验对于提高IT专业人员的薪金水平是非常重要的。他说，最好的首席信息官不仅仅是一个技术人员，而且应该是能够在技术和业务两个方面都能够工作的业务人员。

6.获得开源软件产品开发经验

Kirven说，由于时代已经发生了变化，首席信息官采用MySQL和其它开源软件技术不会有失去工作的风险。事实上，业务人员经常会喜欢开源软件，因为它可能为公司省钱。

7.更近一步了解能够让你的公司赚钱的技术

在大型银行或者金融机构工作的人都知道你越接近能够让你的公司赚钱的技术，你的工作岗位对于你的公司就越重要。IT人员也是如此。参与让你的公司增加收入或者节省金钱的项目的IT人员很少会被人忽略。

8.首席信息官需要架构技能

Kirven称，IT架构是一个极好的职场道路，不仅因为这是一个高级的职位，而且还因为这些职位几乎完全是不会外包出去的。

9.付费参加项目管理认证学习的人

许多研究报名，虽然并非所有的证书都比印刷证书的成本值钱，但是，企业继续付出高价的费用聘用拥有关键证书的人才。其中最最主要的两个项目管理证书是PMP（项目管理专业人员）和PMO（项目管理办公室）。

10.跳槽

IT专业人员从一个地方搬迁的另一个地方的比例提高了20%。当你在你的技术专长领域寻求进一步发展时，换一个地理环境也许会有帮助。不同地区对于IT专业人员的技术需求是不同的。

特别留意的按钮：ESC键，退格键；IE快捷键或常用键,

退格键:令TOMCAT曾经出现的错误：Software caused connection abort: socket write error

1.参考不能过滤;(%号,字符等因素

2.网页加载的信息是否正确(是返回上一操作的信息?)

3.参考有时有记录但不能选择得到记录;
4.并发操作(多人操作,有一个出现错误后,是继续等待,还是相互之间不受影响)

5.数据是否错乱;(同一单据看到的信息是另一用户的信息?)

6.网页操作速度慢(网络问题?内存问题?并发操作?

7.多层页面是否相互影响,网页失效问题,登录系统不操作是自动退出系统登录界面,
进行的操作能不能保存?

8工具栏设置是否恰当,按钮是否能引导用户进行操作,

9.不需要的功能或者测试过程中有问题(可有可无的功能)最好不要在用户使用过程中出现;

10.执行SQL语句或过程时,是否重复操作;

11.先确定,后取消,返回的值是否恰当;

12.不同IE版本,不同公司的浏览器,制作的控件是否都能运行起来,最好设置一些脚本帮助用户设置;

13.用户的不同权限和不同系统:(销售操作员,人事系统,财务系统,哪些人可以看到金额)

14.JS编辑的规则是否跳过,或者编辑的规则不合理?

15.光标是否定位在编辑上或者焦点上;

16.参考有多页面时,(第一条,最后一条,第一页,下一页,最后一页选择的数据是否正确)

17.在经常出现错误的地方,经常操作就会发现一定的规律或者错误;

18.录入数据时,输入法是否为全角或者半角,注意出现错误的环境;

以上只是根据现在测试遇到的情况,如有不符请根据自己情况自行总结!
因为我觉得自己都有很多东西要去总结,写得不对或者有建议都希望指出不足的地方!

NBA进入激烈状态,湖人会出局,凯尔特人会夺冠?

欧洲杯来了,看好荷兰和葡萄牙夺冠!会实现?其实西班牙也不错,这三支队现在很热,
但我们办公室刚刚很冷了..

同事要走了,我们一起来,却不是一起走,和同事有很多的话要说,我们共同努力过,却因为一些意外
,而选择离开,我其实心里感觉很不爽,又要重新找到更好的Partner,不过生活就是这样,有时不是你要选择,
而是学会适应,但我们却不一定再见面,留给最好的工作态度给别人吧..自己也一定要继续努力了!

精彩赛事的到来,每晚只看半场好球,已感到满足了,因为白天还要上班的缘故..

哈哈刚好十二点开始睇球,却是有些感触...看这些球赛是享受...而中国队呢?失望而回,
真的希望中国足球有好的环境,更多年轻球员有更好的技术,
地大人多,真的找不到好球员?期待中...看看我们的羽毛球,
还是我们的团队还不够好?多人的比赛,我们不行?
今次世界杯预选赛,我们希望失败,
因为失败更能让我们前进,
他们生活太过优越了,但却没发挥自己应该有的水平,能怪谁?
地震让我们团结起来,我们要自强才能自救,
技术跟不上,最好的条件也不达成目标,
中国加油,四川加油,汶川加油!还有更多的加油等着我们..

某甲问道：「测试做太多的话，会不会使得bug解不完？」 

　　某乙回答：「还不简单。只要不做测试，就没有bug。」 

　　上述对话，反应出许多软件工作人员对于测试的想法。对多数软件开发人员而言，测试大概是仅次于维护之外，最令人讨厌的工作。对软件研发主管来说，测试是必要之恶：做得不够后患无穷，做得过多又增加成本，延误商机。因此，如何能够规画与执行一个最经济有效的测试工作，当是软件研发主管们须研究的一个课题。 

　　软件测试的困难，在于它不仅是产品的测试，更是产品设计程序的检验。由于关乎设计的测试，准则不易寻找，经验未必得以再用，他山之石也有应用的局限性，因此难度颇高。欲提高测试的效益，有赖全盘的规画，确实的执行，与事后的检讨改进动作。许多小型软件研发单位，对于软件测试并不重视，但从许多稍具规模的软件公司均配置常设测试人员，乃至于测试品保部门来看，测试工作显然有其学问与价值的。 

　　测试工作没有最佳方法可依循，是因为不同的软件所需的测试手段不同。譬如小型软件与大型系统的做法不同；订制软件与软件包的要求不同；系统软件的测试往往无法采用应用软件所使用的技巧；游戏软件与库存系统有其各自需面对的测试标的。因此，测试人员必须因应软件的特性与资源的限制，加上过去相关的经验，规画最适合的测试方式。并随着经验的累积，不断改进作法，才能找出最佳的测试方法。 

　　由此可知，要做好有效的测试，不只是埋头苦干而已，它需要良好的管理，使整件工作获致最佳的成果。关于测试的管理工作，可从组织、规画、执行与检讨几个角度来探讨。以下谨就笔者粗浅的经验野人献曝一番，希望提供读者基本的协助。 

1)测试组织之设计 

　　由于人性总自认为自己的最好最正确，完全由软件开发人员兼任测试人员，并不值得推荐。实务上往往因软件开发单位的经济规模不够，使得开发人员经常兼任测试人员。但若可行，研发单位应尽可能配置专任的测试人员，尤其是独立于开发小组之外的测试负责人员。尽管是否应设置独立测试小组业界仍有争议，许多人甚至以为保障软件品质唯有从改进软件开发的程序做起，但大部份美国的软件公司均设有独立测试或品保人员乃至于部门，这说明了独立测试仍有其不可摇撼的地位。 

　　许多的软件研发单位将测试视为次等的工作，从而配置次等人员负责相关工作。如此一来，优秀人员无从参与，也缺乏意愿参与测试工作。结果软件品质不易度量，研发的成果常常被不佳的品质抵销，实为令软件开发人员泄气之事。主管是否能体认到软件测试的重要性，通常是成功的关键。软件测试固然是支持性工作，仍应配置合理的资源，以获取整体之成效。在当前的环境下，给予测试人员较多的关注，毋宁是必要的作法。 

2)测试工作规划

　　测试工作的规划，至少包含两项要点：测试目标的订定与测试资源的配置。攻击需要目标，测试亦然。测试的目的在于找出软件的问题，提供改进之参考。目标若不明，测试人员即不知如何着手。 

　　测试目标的订定，最重要的在于软件通过的准则，亦即测试何时方可结束。常见的情形是：软件开发的进度不断落后，最后剩余的时间仅有两个星期，于是测试人员的目标就是把最后两周用完，尽人事听天命。究竟测试多完整，隐藏的多少错误，测试工作的生产力如何？皆一概不知。反正产品卖出去或上线后有的是时间改进。然而产品销售后再改进，成本往往大幅增高，甚至原有开发人员离职他调，连亡羊补牢都倍感困难。经验一再显示，事前的测试除错绝对比事后维护省时省钱，唯有卖不出去或不能用的软件例外。 

　　对于测试的要求可简单区分为二：一种是通过目标所订之软件品质；一种是在既定资源内达到最佳成效。前者要求山头一定要攻下，不达目的绝不停止。譬如目标为单位测试时间的错误发现率须低于某数字，若超过了就得延长测试。此种方式适用于品质要求较高的软件。至于后者则是上市时间已宣布，无法更改者，其目标着重于铲除最严重的错误。此种测试较着重测试的准备、经常对测试执行与除错设定时限与数量要求，其中最容易遵循的准则即为：重要功能永远先测。这两类测试的需求不同，足以影响到测试的计划、测试的顺序与关心的重点。读者不可不察。 

　　至于测试资源配置适当性，则是评估测试目标能否达成的重要参考指标。测试人员需要合理的测试资源，譬如要求总研发人力的20%以上。总时程的1/3以上。人力不足，测试流于形式，时程过短，找到错误也来不及除错，均不可取。除了测试在研发的比重，也需注意测试工作本身在规画管理、规格个案订定、测试执行、回归测试、训练准备工作的人力分配。人员的训练与设备的安排尤其容易轻忽，需加以注意。不同阶段测试的资源配置，也必须加以考量，如此可避免测试集中于功能测试，忽略系统测试。这些工作的适切安排，有助于协助测试工作时时都执行最重要，也最有效的测试。

设计不合理,再多的测试都只会发现更多的问题,
 程序员在修改程序时先想想会有什么影响,如果为了
解决一个问题,而引起另外一个问题,
反反复复,程序永远也改不完,
需求不确认时,我们是否要拿出几套设计文档让客户选择
他们实际的需求,
程序写得最多,很多都不合理,不如不写,让程序变得太过
复杂,根本自己都不能控制,又有什么意义呢?
如果系统始终跟着客户方向去走,自己做的东西只能满足某一
客户的需求,如果另外一个客户又不希望这样做,除了改代码,
还有什么可以满足呢?
所以,设计一定要以自己为主,自己控制能控制的点,再增加一些
特殊客户的需求就可以了,
但真正能做到的却很少,
因为做程序一般对自己做的很有信心,
而却没有从别人的观点却看问题...
按自己的常规操作是对的,但往往出错的却是非常规操作,
有些时,错了就错了,没有更多的理由,
只能将该问题先解决掉再说..
我始终认为,好的设计,离成功其实很近的!

1、需求不确定，客户和开发人员观点存在差异，没有达成共识；

2、测试环境和用户环境有出入，没有配置正确的环境，
    导致有些BUG没有重现出来；

3、系统所有单据状态没有统一规则，使系统流向不明确；

4、用户需求和理论分析有区别，比如仓库要符合进出原则，
    产品进多少，产品就应该出多少，但客户没有明确规定，
    出的数量可以大于入的数量都允许；

5、单据被引用后，再修改单据数据，导致单据数据没有确定关系；

6、测试员不能和用户进行有效的沟通，了解客户所需要系统的功能，
    会使测试效率得不到有效提高，测试员应该尽可能地到用户的工作环境来了解；

7、每个开发人员都可能有自己的观点时，如果开发人员没有主见，任由客户
   说了  算, 虽然解决了问题，但使系统过于复杂化，系统不能实时跟踪到问题；

8、开发人员对自己系统不负责，只完成自己的职责，而不是更好完善自己的产品；
    因为开发人员对自己的产品比测试人员了解得更清楚；

9、每修改一次系统，都进行回归测试，会使测试人员的时间分配不合理；

10、做系统时，没有按行业进行规范和设计，使系统面向不同客户时，都要重新设计，系统面向一个客户时，都要做成通用的系统，并增加客户的特殊需求就可以了；

一、需求分析:
 需求确定或讨论:
1、财务审核后:没有显示哪个人审核的,
2、不能让其他操作者（生管）知道该单据是锁定的;
3、单据没有审核,财务也可进行财务审核:(而我们单据设置是审核后才能预览的;)
4、财务审核后,用不用做到要该操作者审核后,只有该操作者才能弃审;
5、列表工具栏和单据明细工具应该是对应的；
6、如果功能基本可以做到以上要求，可以引导操作者要这样操作才能符合系统的要求

二、测试用例：

用例一：都是在有效日期范围内的；
1、产品分类价格有报价，没有产生产品价格，产品价格也没有报价，所以发生业务的产品没有价格；

2、产品分类价格没有报价，产品价格有报价，发生业务的产品应该以产品价格为准

3、产品分类价格有报价，也产生产品价格了，发生业务的产品是以产品价格为依据

4、产品分类价格没有报价，产品价格也没有报价，所以发生业务的产品是没有价钱；

5、4.9新增产品分类价格,4.10新增产品分类价格;4.10素材入库该产品,
只更新4.9生效日期的产品分类价格, 发生业务的产品还是以4.9的价格为依据的;

6、产品价格4.10号有价钱 ,再产生4.9产品分类的价格,
  4.9产品发生业务的应该以4.9的产品分类价格为准,
  4.10产品发生业务的产品应该以4.10的产品价格为准;

7、产品是4.2入库的,4.1有产品价格,4.2产生对账单后,
  再新增4.2产品的价格,对账单的价格是以哪个为准?

8、产品价格和产品分类价格都有报价时，新增素材入库没有更新得到价格时的处理方式；
 （如有该现象，系统是否能做到正确：）

9、4.1产品有价格1元,4.1产生该产品分类价格2元,应该以产品分类价格的为准;

   1仓库人员：最关心库存的准确性，财务人员：报表能否直观反映报表的正确性；

   2结存数,盘点,数据继承接转;盈亏分析,数据的完整性:

   3员工应该区分所属的部门(货管,财务,销售),在选择员工可实现过滤不相关的数据;

   4客户要修改时,单据编号和之前的编码有区别的;(比如以前编码为PC,后来变为PK)

   5用户能跟踪得到单据和报表的关联性;

   6生产单号或者单据是否完成或结束,所带的参考应该是客户所需的正确数据;

   7新做系统时,如果和之前系统的表结构有很大出入,怎样把之前的旧数据继承过来;

   8单据被引用后,是否有作废,删单功能,要保证参考结存数年的正确性;

   9产品有KG数和PCS数,或者两个数量的其一的应对方式;


   10操作速度的慢与快,直接影响用户对系统的依赖性,和可持续性;

   11盘点出来要输入实盘数时动用的人力和物力；

   12系统能引导用户操作;(导航测试,系统误操作,不常规操作,系统是否都能有异常的处理;)

   13设计就要首先要为用户先想到，把自己的想法讲比管理层，让他们觉得ERP系统可以省他们一些烦心事，并数据的稳定性和录单时有些规范；

1、数据过滤，  
2、日期逻辑问题； 
3、产品进出逻辑关系；
4查询和动态查询的合理性;
(是否可查询该字段,查询的条件是否自动清除)  
4过滤不该有的功能(检查工具栏,右键)
5客户操作异常,给出的提示信息,用户是否接受  
6用户点击记录是否为当前记录(审核,选择)
7用户是否跳过系统定出的规则;   
8用户保存的数据是否一致;(没有多余的数据或缺少数据;)
9单据新增,保存,刷新(单据编号都应该是唯一的;) 
10产生对账单,盘点单时,应该要秀出来(系统自动启动到单据明细中) 
11单据明细,序号的连续性和唯一性; 
12哪些数据信息是用户必填和可选择的;  
13用户的破坏性操作  
14升级版本问题
(是在系统开发库原有基础上升级,还是在用户使用环境中增加新增的功能;)  
15界面显示的信息是否通用,用户是否一看就明白;
16系统默认值的测试;(用户看不到的数据系统就不能有该数据)  
16-1 给出的提示重复:新增时提示一次,保存时提示一次,审核时提示一次,新增同一条记录又提示一次;
 
17系统规则为了保存数据正确,在不同的点上多做几个检测,会使用户眼花缭乱,并对速度有所影响;

  纯属个人测试所用，如引用，请根据自己情况而定！写得很乱，只不过为自己资料而留低，没有进行好的编辑！