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

kuailederen

有些人平时不添砖加瓦，专门瞄着整数楼层
强烈抗议啊

kuailederen

其实目前我们所做的主要工作就是质量控制阶段的测试部分，让它独立的去承担质量的风险，而我们所测试的基本都是一致性质量，对于设计质量很少涉及。那么我们应该怎么去测试设计质量，由什么职能的人员和部门去完成，都是需要思考的。

月上百合

网站测试清单
通用

　　◇ 所有测试是否运行在干净系统上？

　　◇ 系统是否正常运行？

　　◇ 是否显示正确输出？

　　◇ 系统是否能提供所需功能？

　　◇ 普通用户是否能轻松地操作该系统？

　　◇ 是否易学易用？

　　◇ 系统是否会为客户提供服务？如响应的、有帮助的、正确的服务？

　　◇ 是否可以简单辨别系统的正确性与可靠性？

　　◇ 是否能轻易地修复或修改系统？

　　◇ 当系统需要提交或修复时，开发人员是否可以在限期内完成？

　　◇ 新版本中未经修改的功能是否能与老版本保持一致？

　　◇ 系统是否能使硬件、网络及人力资源得到有效利用？

　　◇ 系统是否能匹配相关的技术水平？

　　◇ 系统是否能匹配适当调整的需求？

　　◇是否可以有效验证系统的工作方式是适当的？

　　◇ 本系统内一些组成部分是否可以被其他的系统再利用？

　　◇ 不同用户不同平台上安装系统是否同样快捷便利？

　　◇ 系统是否设置有未来更新的路径？

　　◇ 是否可以方便地获取信息？

　　◇ 网站是否能被搜索

月上百合

可用性、界面及导航

　　◇ 系统为一个用户、十个用户或一千个用户服务时，是否同样工作正常？

　　◇ 是否可以快速登陆主页？

　　◇ 网站的操作方法是否清晰地展示给用户？

　　◇ 如果按操作方法进行操作是否可以得到预期结果？

　　◇ 是否所有新用户都理解网站内的所有术语？

　　◇ 是否所有窗体都有导航栏？

　　◇ 导航栏的位置是否始终保持一致？

　　◇ 是否导航栏仅作用于使用中的文本？

　　◇ 用户是否可以在不用鼠标的情况下使用导航栏功能？

　　◇ 视力障碍者是否可以使用网站？红绿色盲，少于 20/20

　　◇ 网站标志是否风格一致？

　　◇ 每个单独页面内是否包含主页链接？

　　◇ 每个页面的排版是否统一？

　　◇ 每个页面的管理风格是否一致？

　　◇ 网站内图表的使用是否协调？

　　◇ 快速下载的图表是否质量优化？

　　◇所有图片是为页面添彩，还是浪费网速？

　　◇ 是否使用了图表的最佳尺寸？

　　◇ 图表/图片周围的文字布局是否合理？

　　◇ 是否对所有的参考网站或电子邮件地址都设置了超链接？

　　◇ 超链接颜色设置是否标准？

　　◇ 网站在 640 x 480、600x800 等像素下是否显示正常？

　　◇ 字体是否太小（切忌并非每个人都能获得相同的视图效果）？

　　◇ 字体是否太大？

　　◇ 所有文本是否排列适当？

　　◇ 所有图标是否排列适当？

　　◇ 图片是否能被完整打印？

　　◇ 网站内是否有站内地图？

　　◇ 站内地图的每个超链接是否有对应的目标链接页？

　　◇ 站内地图是否包含了网站内所有的超链接？

　　◇ 每个页面的超链接是否正常工作？

　　◇ 内容是合法正确的（非单元测试期间开发者设置的填充内容）

　　◇ 页面背景（颜色）是否会分散注意力？

　　◇ 返回按钮是否正常工作？不会打开一个新的浏览器窗口，或重定向其他站点。

　　◇ 返回上页或转至新页面时，是否会导致本页面内容丢失？

　　◇ 从主页开始是否可以通过 3 次或更少的点击数到达目标页面？

　　◇ 图表或表格中的内容是否完整？是否正确列出？是否能确定所选文本处于图表或表格的正确区域内？

　　◇ 页面上的链接是否和先前一致？有没有新出来的或消失的链接？

houzeal

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。

      验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

      通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。

       1.验收测试标准   实现软件确认要通过一系列墨盒测试。验收测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。 验收测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

       2.配置复审   验收测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。

      3.α、β测试  事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。 α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。 一般包括功能度、安全可靠性、易用性、可扩充性、兼容性、效率、资源占用率、用户文档八个方面。

xiaohy

测试的目标
Myers对测试目标作了如下归纳：
测试是程序的一个执行过程，其目的在于发现错误；
一个好的测试用例在于能找到至今尚末发现的错误；
一个成功的测试是发现了至今尚末发现的错误。
      
总之，测试是为了发现错误，这不仅从技术角度为软件测试下了定义，而且从心理学和经济学的角度规定了软件测试的基本任务。在我们给出的测试定义中，已经将“执行程序”扩展成“分析和执行程序”。

xiaohy

软件测试的原则

所有的测试都应追溯到需求。因最严重的错误是（用户的观点）导致程序无发满足需求的错误；
软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如审查、评审和走查等）;
软件开发人员应避免检查自已的程序，软件质量保证活动应由独立于软件开发单位的机构来承担；
在设计测试用例时，测试用例应由输入数据和与之对应的期望输出结果这两部分组成，在输入数据中应当包括合理的输入条件和不合理的输入条件；
穷举测试是不可能的；
在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果。

︶ㄣ乖寶貝﹎

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
　　测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳．目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一．
　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
　　随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。
　　要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项操作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。
　　既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
　　确定测试用例之所以很重要，原因有以下几方面。
　　测试用例构成了设计和制定测试过程的基础。
　　测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
　　判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。
　　测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
　　测试设计和开发的类型以及所需的资源主要都受控于测试用例。
　　测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：
　　·一个测试用例用于证明该需求已经满足，通常称作正面测试用例；
　　·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
　　一、测试用例是软件测试的核心
　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

e.lite

测试用例如何设计更能覆盖完全需求呢

︶ㄣ乖寶貝﹎

测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计

月上百合

网站测试清单
有没有链接失败的情况？

　　◇ 点击链接是否能到达正确的目标页面？

　　◇ 目标页面是否存在？

　　◇ 站主的联系信息是否能从网站中获得（姓名、电话、电子邮件地址、邮寄地址、传真号）？

　　◇ 如果用户需要为某个页面作标签，该页面的名称是否易懂？

　　◇ 如果用户有获取历史页面纪录的权限，那网站地址是否会出现在 History 列表中？

　　◇ 网站页面的状态栏是否真实反映出页面登陆的进度、信息等？

　　表格

　　◇ 表格是否过长，经常需要通过拖动滚动条才能看到表格右边的栏目？

　　◇ 表格是否能正确打印？

　　◇ 表格内的列宽和行高是否合适？

　　◇ 会不会因为某个输入而使行高变化异常？

　　框架

　　◇ 是否会出现浏览器不支持的框架？

　　◇ 框架是否能自动准确地调整大小？用户是否可以操控框架的尺寸？

　　◇ 滚动条是否会适时出现？

　　◇ 框架页面上是否有明确的数据供书签或收藏夹识别？

　　◇ 搜索引擎是否可以找到框架中的内容？

　　◇ 框架边框是否美观？

　　◇ 框架内更新是否会出现问题？

　　数据认证

　　◇ 网站内面向用户的数据描述是否清楚？

　　◇ 隐私制度是否制定清楚？用户能否看到该制度？

　　◇ 保存的数据是否准确？

　　◇ 工作站是否对数据进行认证？

　　◇ 服务器是否对数据进行认证？

　　◇ 是否可以确保用户在工作站录入的信息可以被服务器正确接收？

　　◇ 在不同的时间段是否可以避免录入相同的信息（订单表等）？

　　◇ 是否为每个用户分配有唯一标识符，用于录入表格数据，保证表格对象的唯一性？

　　◇ 要求用户录入的信息是否是进程所必需的？例如：要求用户录入生日信息是用于其订单编号？或是仅仅为了多获得一些用户信息？

　　◇ 数字录入区域是否可以录入文字？

　　◇ 搜索中能否使用通配符？

　　◇ 是否可以在域内录入空格和空值？

　　◇ 是否可以录入长串？

　　◇ 域内是否可以录入文本最大的数量？

　　◇ 复选框和控件按钮的初值是否设置正确？

　　◇ 一个组内的控件按钮是每次只能选中一个？

　　◇ 复选框是否会触发预期事件？

　　◇在表格域内用户是否不能输入 HTML 代码？

　　◇智能错误处理是否会引发数据认证？ IE.如生日域的需求格式为 MM/DD/YYYY，则用户输入出声年份为 1857 是不匹配的。

witcher2002

测试生命周期
　　测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估
　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试

witcher2002

测试生命周期
　　测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估
　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试

fishsky

测试的目标
Myers对测试目标作了如下归纳：
测试是程序的一个执行过程，其目的在于发现错误；
一个好的测试用例在于能找到至今尚末发现的错误；
一个成功的测试是发现了至今尚末发现的错误。

yun_004

自动化测试应该在项目什么时候做准备?

namisang

恭喜吖
Why Labels For Test Techniques?

belie

手机终端软件测试:
随着GSM、CDMA、WCDMA、CDMA2000及我国自主研发的TD-SCDMA等手机新技术的不断涌现，基于业务应用层面开发和测试比重的增加，复杂度的不断提高以及手机和传统上基于PC的应用服务的快速融合,使得手机终端软件也越来越多，手机终端软件测试也应运而生，在这里简单的描述下手机终端软件测试的方法。
　　一、功能测试
　　手机终端软件的测试和其他PC上使用的软件的在测试方法上，或者说是测试策略上基本是一致的。软件测试贯穿于整个软件生命周期，同样也是需求评审-测试计划-测试案例/环境搭建-测试执行-测试报告输出-测试总结。
　　1.手机终端软件测试，需要测试人员，在需求阶段就介入其中，要参与需求的评审，这样才能够更透彻的了解需求，为测试案例的准备打下良好的基础。
　　2.在需求明确的情况下，测试人员就需要开始执行测试计划，搭建测试环境、准备测试案例。为确保能覆盖所有的功能点以及测试案例的高效、准备，最好是能够发起测试案例的评审，请需求人员、开发人员以及测试同行对测试案例进行评审。
　　3.当收到版本后，进入系统测试阶段，执行测试案例。
　　4.测试结束后，提交测试报告。
　　5.测试总结，其实也是测试环节中较重要的环节。测试完成后，对测试环节中好的方面和暴露出来的问题进行有效的总结，对软件测试过程进行改进，就是测试经验的积累很重要的一个过程。
　　二、性能测试
　　手机终端软件的性能测试，主要是针对手机终端软件本身的性能测试，手机终端软件的性能测试主要分为终端软件运行速度、终端软件运行资源消耗、终端功耗、终端网络流量等方面，主要运用第三方的一些工具，监控软件在运行特定业务的场景时手机资源的消耗情况。

namisang

其实目前我们所做的主要工作就是质量控制阶段的测试部分，让它独立的去承担质量的风险，而我们所测试的基本都是一致性质量，对于设计质量很少涉及。那么我们应该怎么去测试设计质量，由什么职能的人员和部门去完成，都是需要思考的。

namisang

测试生命周期
　　测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估
　　测试计划就是定义一个测试项目的过程，以便能够正确的度量和控制测试

namisang

测试的目标
Myers对测试目标作了如下归纳：
测试是程序的一个执行过程，其目的在于发现错误；
一个好的测试用例在于能找到至今尚末发现的错误；
一个成功的测试是发现了至今尚末发现的错误。