[活动]迎五一，庆周年，盖高楼(活动结束)

水上飘

从是否关心软件内部结构和具体实现的角度划分
　　A.白盒测试
　　B.黑盒测试
　　C.灰盒测试

六月的雪

软件缺陷
　　软件未达到产品说明书表明的功能。
　　软件出现了产品说明书指名不会出现的错误。
　　软件功能超出产品说明书指名范围。
　　软件未达到产品说明书虽未指出但应达到的目标。
　　软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
　　一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
　　所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误(software error)，如代码中加法写成减法。软件错误导致软件缺陷(software defect)，如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)，故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效(software failure)。
　　我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。

六月的雪

如何成为一名优秀的测试工程师：内功（基础知识：计算机硬件、网络、操作系统、数据库等）、测试技术（黑盒测试中等价类、边界值、因果图等，白盒测试中的语句覆盖、分支覆盖、路径覆盖等）

   1）、不断学习充电

   2）、阅读原版书籍

   3）、阅读缺陷管理系统中的缺陷报告

   4）、阅读高手写的测试用例

   5）、学习产品相关的业务知识

水上飘

Zero Bug与Good Enough：本条给我们灌输的是一种测试执行通过的标准。显示任何测试通过不可能达到0 bug。那我们就应该达到Good Enough。这条原则是一种权衡投入/产出比的原则：测试既不能不充分也能过，我们需要制定测试通过标准和测试内容，比如：遗留的bug数&严重程度，测试用例的执行率&通过率等来解决上面的问题。

六月的雪

质量目标

通过测试管理工作的加强，力求在测试阶段尽可能多的发现软件错误与缺陷，尽可能少的将问题带给用户，确保软件的质量及其可靠性，提高用户满意程度，使作为质量管理中心的质量管理部真正的把好产品的质量关，尽量在测试阶段发现软件错误和软件缺陷减轻客户服务部的压力，提高金益康公司产品的质量与市场竞争力，营造公司良好的形象。

水上飘

可用性测试是指在设计过程中被用来改善易用性的一系列方法。我们为用户提供一系列操作场景和任务让他们去完成，这些场景和任务与您的产品或服务密切相关。通过观察，我们来发现过程中出现了什么问题、用户喜欢或不喜欢哪些功能和操作方式，原因是什么。针对问题所在，我们会提出改进的建议。

水上飘

边界值分析方法的考虑：
  长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
  使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

六月的雪

软件缺陷
　　软件未达到产品说明书表明的功能。
　　软件出现了产品说明书指名不会出现的错误。
　　软件功能超出产品说明书指名范围。
　　软件未达到产品说明书虽未指出但应达到的目标。
　　软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
　　一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
　　所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误(software error)，如代码中加法写成减法。软件错误导致软件缺陷(software defect)，如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)，故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效(software failure)。
　　我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。

六月的雪

敏捷测试


测试大体上可分为手工测试和自动化测试。根据敏捷原则，要确保能用自动化测试的事情决不要用手工测试。同时要做到适合手工测试的内容决不要花高昂地成本做成自动化测试。另外，不要因为某方面不能自动化测试而不做测试。

水上飘

兼容测试：测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。


　　比较测试：与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。


　　Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。


　　Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

wolf1130

软件测试工程师主要职责为：
1、 负责项目/产品的测试工作，分析产品需求，建立测试环境和计划，保证产品

质量以及测试工作的顺利进行；

2、 按照软件工程规范和项目管理流程，实施、管理和知道软件开发不同阶段的

各种测试，并提交测试报告。测试的计划安排包括人员安排、进度、使用的软硬

件环境、测试的流程等；
3、 提交测试报告，并撰写用户说明书；
4、 参与软件测试技术和规范的改进和制定。

walker1020

Acceptance Testing－－可接受性测试
一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。

actual outcome－－实际结果        
被测对象在特定的条件下实际产生的结果。

Ad Hoc Testing－－随机测试        
测试人员通过随机的尝试系统的功能，试图使系统中断。

algorithm－－算法        
（1）一个定义好的有限规则集，用于在有限步骤内解决一个问题；（2）执行一个特定任务的任何操作序列。

algorithm analysis－－算法分析        
一个软件的验证确认任务，用于保证选择的算法是正确的、合适的和稳定的，并且满足所有精确性、规模和时间方面的要求。

Alpha Testing－－Alpha测试        
由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。

walker1020

analysis－－分析        
（1）分解到一些原子部分或基本原则，以便确定整体的特性；（2）一个推理的过程，显示一个特定的结果是假设前提的结果；（3）一个问题的方法研究，并且问题被分解为一些小的相关单元作进一步详细研究。

anomaly－－异常        
在文档或软件操作中观察到的任何与期望违背的结果。

application software－－应用软件        
满足特定需要的软件。

architecture－－构架        
一个系统或组件的组织结构。

ASQ－－自动化软件质量（Automated Software Quality）
使用软件工具来提高软件的质量。

assertion－－断言        
指定一个程序必须已经存在的状态的一个逻辑表达式，或者一组程序变量在程序执行期间的某个点上必须满足的条件。

assertion checking－－断言检查        
用户在程序中嵌入的断言的检查。

水上飘

灰盒测试，介于白盒测试与黑盒测试之间，灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

水上飘

软件缺陷
　　软件未达到产品说明书表明的功能。
　　软件出现了产品说明书指名不会出现的错误。
　　软件功能超出产品说明书指名范围。
　　软件未达到产品说明书虽未指出但应达到的目标。
　　软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
　　一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
　　所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误(software error)，如代码中加法写成减法。软件错误导致软件缺陷(software defect)，如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)，故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效(software failure)。
　　我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。

happymouce

什么是ad hoc 测试啊？它跟monkey 测试有什么联系吗？ad hoc有什么技巧吗？
(*^__^*) 嘻嘻……，测试新手，就不发表什么见解了，呵呵……纯粹是友情支持一下！
原谅原谅

水上飘

常见错误分析
  -用户界面问题
  •输入无合法性检查和值域检查。
  •界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。
  •表达不清或过于模糊的信息提示。
  •要求用户输入多余的本来系统可以自己得到的数据。
  •为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。      
  •不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。
  •不经用户确认就对系统或数据进行了重大修改

贝贝酷

常用的功能测试方法
　　功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
　　1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
　　3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。
　　4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
　　5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
　　6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
　　7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
　　8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
　　9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
　　10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
　　11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
　　12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
　　14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
　　15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
　　16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
　　19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
　　20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

贝贝酷

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

a 软件未达到客户需求的功能和性能；

b 软件超出客户需求的范围；

c 软件出现客户需求不能容忍的错误；

d 软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

水上飘

软件缺陷
　　软件未达到产品说明书表明的功能。
　　软件出现了产品说明书指名不会出现的错误。
　　软件功能超出产品说明书指名范围。
　　软件未达到产品说明书虽未指出但应达到的目标。
　　软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
　　一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
　　所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误(software error)，如代码中加法写成减法。软件错误导致软件缺陷(software defect)，如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)，故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效(software failure)。
　　我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。