苹果
夏末，趁园艺工人未剪枝前，在公司的园子里摘了几只未成熟的苹果，放置在办公桌上，添一抹绿，添一份清新。摘下的苹果却在我眼前稍无声息的展现了生命的过程，晃若人的一生。
刚采摘的苹果，小小的，泛着青绿色，光滑的表皮上蒙了一层雾样的白霜，朝阳的一面微微有些红色..
测试用例的价值
一个测试用例是一个正式的文件或记录，描述了测试活动是怎样具体执行的。一些测试参考资料指出测试用例的目的就是发现缺陷，但是测试用例的用处远远超出发现缺陷。测试用例可以验证程序功能正常或验证错误能被正确处理。测试用例的其他用处是可以尝试增加代码覆盖或专门用于覆盖很少使用的路径。
测试用例文档的价值在微软和软件测试行业之间有争论。有几个因素可以帮助决定是否选择测试用例文档。测试用例文档有如下一些好处：
历史借鉴。测试用例的存在要远远超过产品发布。持续工程以及产品未来版本的负责人往往..
最近我身边好多人都在忙着装修，或是结婚用房或是改善型住房，不管是出于哪方面的需要，经济和时间都是装修工程中需要面临的重要问题。对于上班族，即要保证工作时间，又要顾及装修中方方面面的琐事，的确不太容易。对于打算DIY装修的业主来说，制定好装修计划不仅能节约资金、时间，还能使装修变得更有条理，所以计划很重要。下面以期房为例，阐述装修的一些问题。
在购房完成后，业主可以根据开发商提供的户型图来了解房间的户型结构，如果是现房的话还可以实际测量一下。在得到户型图后，业主首先要考虑自己的居住需要，比..
Oracle 10g学习笔记（二）
主题：基本的SQL *PLUS报表及命令
内容：
一．建立简单的报表
1.break on告诉SQL *PLUS在报表的各部分间插入空格，或者将小计和、总计断开
Compute avg:求平均值
Compute sum:计算小计
Compute count:求和
Compute max:计算最大数
基本原则：
1) 每个break on命令必须有一个相关的order by命令；
2) 每个compute avg/sum/count/max命令必须有一个相关的br..
前言
很不好意思的坦白本人是刚刚学习oracle的菜鸟，以下内容是节取的书中一些值得注意的事项，因为只涉及oracle最初级的知识，并没有太深的内容，希望各位oralce高手们能够帮忙指点指点。
Oracle 10g学习笔记（一）
一．在安装数据库前，应考虑的问题
1.决定数据库的名称：DB_NAME,DB_DOMAIN
2.规划System表空间
3.规划数据文件在Oracle服务器上的位置，物理磁盘越多越好
4.初始化参数设置
5.选择数据库字符集和备选字符集
6.决定最优的数据块大小DB_BOLCK_SIZE
7.规划非系统表空间中存储非系统用户对象
8.规划如何实现自..
Oracle 9i初始参数文件设置
一．设定全局数据库名称
DB_NAME：数据库名称，文字字符串，不能超过8个字符
DB_DOMAIN：数据库服务器所在域名，用于分布式运算环境
二．设定控制文件的名称
执行CREATE DATABASE指令时设置
CONTROL_NAME：设定控制文件名称
CONTROL_FILE：设定控制文件路径
三．设备数据区块大小
DB_BLOCK_SIZE：设定“标准数据区块（Standard block）”的大小，合理范围2KB~32KB之间，也可将其设置为“操作系统区块”大小的整数倍，用于提升数据的访问性能。
DB_nk_CACHE_SIZE:设定..
第三章 代码检查、走查与评审
很多年以来，软件开发团队的主要工作是开发适用于机器运行，而不是供人阅读的程序，软件测试的唯一方法就是在机器上执行它。这种情况在上世纪70年代发生了改变，一些具有远见的软件工程师发现了代码走读在测试中的重要位置，并辅以DEBUG调试来更好的提高软件的质量。
如今，并不是所有的软件测试人员都要走读代码，但是了解代码设计的理念却在测试工程师中被越来越多的人所接受，得到了广泛的认同。以下几个因素会影响到特定的测试和调试工作需要人工实际阅读代码的可能性：软件的规模和复杂度..
用动态的眼光看测试
软件测试工程师到底是做什么的？很多书籍都会这样告诉你：黑盒测试工程师测试程序，白盒测试工程师测试代码。这样说的确没错，初学者可以这样理解，如果作为资深的软件测试工程师还是这样想的话，只能说是这几年的时间里你并没有任何进步。
简单点说资深软件测试工程师仅需要掌握测试技术和行业技术就足够了。但细品起来好像也不完全像..
我的一亩三分地
某年某月的某一天，村里分一块地给我，这块地处于山坡上，位置不太好。因为年老体衰，庄家活干不动了。于是乎在村头张贴了一张招聘广告，招一人帮忙种地。
第一天，来个小伙子，在外打过工，因为金融危机，工厂接不到单，失业回家来种地了。小伙子见过市面，经常看新闻联播，进门就给我说，“叔啊，你请我吧，你买个播种机和收割机，凭我这脑瓜，半天就学会”。我说为啥啊，小伙子说：“你看这不农业现代化，机器自动播种和自动收割，自动化操作多先进”。我纳闷，我那点坡地，给你自动..
软件测试中的行业技术
资深软件测试工程师应该具备哪些技能是很多软件测试网站和博客上的讨论重点，稍做总结大概可以归结为下几点：测试执行能力，测试设计能力，自动化测试能力，脚本等测试工具编写能..
http://g.51cto.com/tester
定义BUG状态
谈到BUG的状态，不得不提一下测试的工作模式，较为常见有以下两种：第一种工作模式为交互式，也就是说由测试工程师提交BUG到管理工具，通知软件工程师进行修改，软件工程师根据BUG状态做出反应或修改，然后将问题状态更新，提交测试版本后，由软件工程师确认并再次更新问题的状态，这种工作模式是较为理想化的，因为中间需要多次沟通协调，所以转换周期会长一些，比较适用于大型软件项目；那么单方触发的工作模式，以测试工程师为主导，发现问题并督促软件工作师修改，..
软件测试法则
继续本章开头所阐述的问题“在软件测试中心理因素占有重要的位置”，通过对心理学的了解，我们能够找出软件测试中重要的原则或者称为重要的指导方针。这些原则大部分都是浅显易懂，但在实际工作当中却很容易被忽视。表2.1概括了这些重要的原则，在下面的章节中将详细阐述。
表2.1 软件测试指南
原则ID
原则描述
1
定义预期输出或结果，是测试用例的重要组成部分
2
软件工程师应该尽量避免测试自己编写的程序
3
一个开发团队应该尽量避免测试自己编写的程序
4
彻底检查每个测试结果
5
测试用例中不但..
二、 白盒测试
另一种常用的测试方法是白盒测试法，也称为逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子，将程序中的每条语句至少执行一次，用以证明该程序对输入数据做出了正确的应答，但这是远远不够的。在这里不会对这个问题进行冗长的阐述，这部分内容将会在第四章中详细说明。在本章中将介绍一些我们都会想到使用的方法—比如穷举测试法，..
测试中的经济学
鉴于软件测试的定义，下一步将阐述是否有必要找出程序中的所有错误。尽管是最小的程序，我们都将给你否定的答案。一般来说这种做法是不可能实现的，因为我们不可能找出程序中的所有问题。假设测试人员要对某个程序开始测试，在这之前就必须编写测试用例，这些最基本的工作都能够体现出经济学与测试之间的联系。
为了表现测试与经济学的关联性，在开始前你必须判断应该采用哪种测试方式。我们将在接下来的内容中讨论最普遍采用的黑盒测试和白盒测试方法。
一、 黑盒测试
黑盒测试、数据驱动和输..
单元测试的组织方法
本文描述了三种单元测试的组织方法：自上而下法，自下而上法和分离法。组织方法是制定
单元测试策略和拟制测试计划的关键因素；选择不适当的方法会对单元测试成本和软件维护
开支造成不利影响。这里将推荐一种基于分离法的单元测试策略。
一、介绍
单元测试是对软件单个组件（单元）进行的测试。尽管它的编码是不同类型的，而且有两个
不同的阶段，但单元测试通常被认为是一种组合代码以及软件生命周期单元测试阶段的一部
分。在Ada，C 和C++程序中最基本的设计和代码单元是单个的子程序（如过程，函数，成员
函数..
曾经对软件测试很轻视，因为我那时很无知，只是一名普通的中国程序员，这也是那时绝大多数程序员的心态，那时中国程序员最讲究“编程才是硬道理”。
如今却非常热爱软件测试，包括软件测试工具，方法，理论，技术。因为我在3年的测试工作中，深刻体会到软件测试的重要性和趣味性。此时，我已经跳出了“小程序员”的圈子，以软件系统工程的更大视角审视软件测试这项工作。
很长时间以来我一直被下面的问题而困惑，有些问题至今仍然只是具有肤浅的认识，而且，我感觉我做的测试项目越多，阅读的测试书籍越多，我越感到我对软件测试理解..
增加测试用例状态的精确度
一般在工作中记录测试用例状态用到三种状态：通过(Pass),失败(Fail)和排队等待中(In Queue)。但是我倾向与更准确地表示一个一般测试用例的生命周期，尽管你的测试的周期会有变化。这里列出了我所使用的一个测试用例生命周期：
排队(In Queue)：测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。
进行中(IP)：该测试正在进行，并且会持续一段时间。(如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态)
阻塞(Bl..
如何正确对待需求的变更
1、对于需求和需求变更的理解
软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，它不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。
软件需求变更会给项目带来巨大的风险,会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降..
社区：
