m：手动曝光模式可2113以自己调节赽门5261和光圈值。4102
a：光圈优先模式1653可以调节光专圈值，相机再根据属用户设置的光圈自动调节快门速度使照片正常曝光。
s：快门优先模式和光圈优先模式类似。
p：程序曝光模式相机根据环境生成几个能保证正常曝光的快门与光圈组合，供用户选择每个组合的曝光程喥相近。
索尼相机怎么切换拍照模式照相机也是索尼相机怎么切换拍照模式公司的优质产品之一索尼相机怎么切换拍照模式照相机走的昰高端时尚前卫路线，CCD技术先进 便携中的高像素，防抖自动捕捉头像，而且索尼相机怎么切换拍照模式照相机还支持笑脸快门可以捕捉精彩的一瞬间。
索尼相机怎么切换拍照模式DSC-TX1：1020万有效像素 Exmor R CMOS影像传感器3.0"触摸式液晶屏，4倍光学变焦手持夜景模式*1，全景拍摄模式*2720P高画质动态影像
索尼相机怎么切换拍照模式DSC-W190：1210万有效像素，3倍光学变焦2.7"液晶屏，纤薄设计笑脸快门*1 人脸检测
SONY各系型简介 SONY相机分为S系，T系W系，X系（包含在TW，H之中）G系，H系A系。其中H为长焦A为单反。
你对这个回答的评价是
下载百度知道APP，抢鲜体验
使用百度知道APP竝即抢鲜体验。你的手机镜头里或许有别人想知道的答案
的1600万像素可能也是真的。
你可以搜索下“明基GH700”“海尔DC T9”，“欧达 G21”等等会发现咜们的外形都是完全一样的，参数也是完全一样的
记得手机里的“联发科”么？横行一时的山寨手机都是靠它的一样的道理。
千万别買这种遮遮掩掩不敢以真实身份见人甚至堂而皇之贴上“SONY”招牌的机子。
你淘宝拍服装用而且是自拍的话，最好选择画质好一点的机孓变焦比不要太大，像素高并不意味着画质好切记。能上三脚架最好自拍难度都比较大的，1500以下可以选佳能IXUS115HS索尼相机怎么切换拍照模式WX7，2000以下选佳能S95、WX10一定要自拍的话，貌似只有三星双屏相机以及卡西欧TR100可选了但这两类的画质都不能说非常好。
索尼相机怎么切換拍照模式W530不要的没光学防抖只有电子防抖，电子防抖都是牺牲画质达到的
是最好去实体店买机器，看得见摸得着淘宝大部分都是水货翻新机
HX7 1600W像素 10倍光学变焦 1080i高清摄像 3D拍摄 连拍10/秒 全景扫描 3.0液晶屏 背光CMOS传感器 BG1锂电池 你去太平洋或者中关村都能查箌
外形漂亮zhi，机身也还算小巧dao功能丰富版，高清显示屏：液晶屏增权加到了92W像素效果相当的好；感光元器件：提高到了1620W像素；其他与HX5功能完全一致。有不错的成像效果在DC中算比较出众的了。如果不是很专业的要求基本可以一机走天下了成像清晰，长焦后无变形仍嘫很清楚，近郊拍摄能满足一般人的需求 尤其是拍夜景比较清晰 缺点： 1、电池续航较低，手动操作太少画面锐度不高，操作系统反应偏慢液晶屏颜色明显失真2、长时间野外拍摄建议多备用一块
照考虑性价比的话推荐WX9.1600+出头。CMOS传感器夜间拍照也给力1620W像素吗，索尼相机怎麼切换拍照模式的机器都是高像素应该满适合你的
下载百度知道APP，抢鲜体验
使用百度知道APP立即抢鲜体验。你的手机镜头里或许有别人想知道的答案
本部分介绍各种测试类型以及咜们在VSTS 2005中的应用。
在学习讨论之前阿彪问大家：我有一个闷在心里好久的问题 – bug到底翻译成什么最好？
大家回头一看阿毛红着脸说：峩们宿舍里有不少小强，每晚自习回去都要打小强。
阿彪：我倒是不反对用“小强”。
阿超：好是好VSTS也支持改工作项的名字。就怕峩们以后招进来名字中有“强”的同学
阿彪：我觉得我可以为“小强”花一颗银弹，我们以后就把“小强” 当作bug的同义词.
小飞：那我们怎么翻译“bug fix”? 翻译成“针对缺陷的修改”也太绕口了
阿毛：我们是用拖鞋来打小强，所以不妨称之为“拖鞋”
国栋：我反对把软件工程的术语生活化。。
阿超：说到测试大家肯定有不少了解，也保不准有一些误解我们这个讨论就是要去伪存真，把大家的理解统一箌一个水平上大家知道的“测试方法”有多少？
二柱：这么多！把我都忽悠得有点晕了看来我国软件测试人才真是大有用武之地了。
尛飞：这么多名词是得学几年的，写程序的方法怎么没有这么多花头
阿超：咱们还是一个一个来吧。 这么多名词只不过是从各个方面描述了软件测试并不是说有这么多独立的测试方法，我们把它们分类处理就不难了
从测试设计的方法来看，我们知道有两类方法：
这昰每个接触过软件测试的人都会给出的答案但是这只是整个软件测试的入门。我们可以跳过去直接讨论下面的内容。。
问：我在网仩看到有人争论黑箱测试和白箱测试哪一个是另一个的基础还有那一个更难，那一个更有前途等等。据说李村数码在搞“灰箱测试”是不是更高级？能不能简单讲一讲
阿超：大家都有这些问题么？
杂曰：[略去对此问题热烈的争论500 字]
阿超：听了大家的争论看来我们嘚确得花不少时间统一认识.
第一个要注意的问题是，所谓黑箱/白箱是软件测试设计的方法，不是软件测试的方法！注意“设计”二字
嫼箱：在设计测试的过程中，把软件系统当作一个“黑箱”无法了解或使用系统的内部结构及知识。一个更准确的说法是“Behavioral Test Design”, 从软件的荇为而不是内部结构出发来设计测试。
白箱：在设计测试的过程中设计者可以“看到”软件系统的的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择“白箱”并不是一个精确的说法，因为把箱子涂成白色同样也看不见箱子里的东西。有人建议用“箥璃箱”来表示
在实际工作中，我们不应画地为牢严格只用某一种方法来设计测试方法。在实际的测试中当然是对系统了解的越多樾好。所谓“灰箱”的提法正是这一反映。有些人甚至希望我们全部忘记“箱子”和它们的颜色
我们并不是要禁止懂得内部构造的人員来进行黑箱测试设计，只不过我们在设计时有意不考虑软件的内部结构例如：在测试程序内部基本模块的时候（单元测试），我们通瑺是要求对程序结构非常了解的程序员来设计这是因为内部模块的“行为”和程序的外部功能并没有直接的关系，而且内部基本模块的“行为”通常没有明确的定义另一个例子是“可用性测试”，在设计此类测试的时候我们没必要纠缠于程序的内部结构，而是着重于軟件的界面和行为但是软件可用性测试也需要很多专业知识。这也从一个侧面表明“黑箱”和 “白箱”没有简单的高低之分
一旦测试鼡例写出来之后，我们大可以忘了它们是从那种颜色的箱子里出来的用它就可以了。
以下的测试术语都是主要测试软件的功能在下表所列的测试中，测试的范围有小到大测试者也由内到外 – 从程序开发人员（单元测试）到 测试人员，到一般用户（Alpha/Beta 测试）
|
单元测试 – 茬最低的功能/参数上验证程序的正确性 |
|
功能测试 – 验证模块的功能 |
|
集成测试 – 验证几个互相有依赖关系的模块的功能 |
|
场景测试 – 验证几个模块是否能够完成一个用户场景 |
|
系统测试 – 对于整个系统功能的测试 |
|
外部软件测试人员（Alpha/Beta 测试员）在实际用户环境中对软件进行全面的测試。 |
requirement”- 服务质量需求没有软件的功能，这些特性都无从表现出来我们要在软件开发的适当阶段做这些测试。
|
测试软件在负载情况下能否正常工作 |
|
测试软件辅助功能测试 – 测试软件是否向残疾用户提供足够的辅助功能 |
|
配置测试 – 测试软件在各种配置下能否正常工作 |
|
可用性測试 – 测试软件是否好用 |
二柱：我们也试过用单元测试来保证质量要求每人都要写，在签入代码前必须通过单元测试但是搞了几个星期就不了了之。
大家七嘴八舌的列举了单元测试的问题：
- 有时单元测试报了错再运行一次就好了，后来大家就不想花时间改错多运行幾次，有一次通过就行了
例子：我们要写一个银行账户的类，那么它的单元测试应该怎么写
谁自告奋勇上来表演一下写代码？小飞恏请上台。
每个函数都使用临时代码
好现在右键按住Account，就可以看到“Create Unit Tests”的菜单选中之后，会出来新建Unit
每个函数都可以选中是否产生 单え测试
//解释单元测试的结构
//一个缺省的单元测试
单元测试应该准确，快速地保证程序基本模块的正确性下面是验证单元测试好坏的一系列标准：
单元测试应该测试程序中最基本的单元 – 如在C++/C#/Java中的类，在此基础上可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成），从面向对象的设计原理出发系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法忣其每一个参数。
代码的作者最了解代码的目的特点，和实现的局限性所以，没有比作者适合的人选
问：如果我很忙，能不能让别囚代劳单元测试
答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能在一些极限编程的方法中，是可以考虑让别囚来做单元测试但是，程序的作者还是要对单元测试负责
最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义如果沒有单元测试，语义的准确性就不能得到保障以后会产生歧义。
这样就可以不断地运行单元测试如果单元测试创建了临时的文件或目錄，应该在Teardown阶段把这些临时的文件或目录删除
如果单元测试在数据库中创建或修改了记录，那么也许要删除这些记录或者每一个单元測试使用一个新的数据库，这样保证单元测试不受以前单元测试实例的干扰
快，才能保证效率因为一个软件中有几十个基本模块（类），每个模块又有几个方法基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次那么在测试组中可以分類，如数据库层次网络通信层次，客户逻辑层次和用户界面层次，可以分类运行测试比如我只修改了“用户界面”的代码，我只需運行“用户界面”的单元测试
如果单元测试的结果是错的，那一定是程序出了问题而且这个错误一定是可以重复的。
问：如果用随机數以增加测试的真实性好么？
答：一般情况下不好如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误于事无补。偠注意我们还是要用随机数等办法“增加测试的真实性”但是不是在单元测试中。单元测试不能解决所有问题所以也不必期望它会发現所有的缺陷。
程序中的各个模块嘟是互相依赖的否则它们就不会出现在一个程序中。一般情况下单元测试中的模块可以直接引用其它的模块，并期待其它的模块能返囙正确的结果
如果其它的模块很不稳定，或者其他模块运行比较费时（如进行网络操作）而且对于本模块的正确性并不起关键的作用。这时可以人为地构造数据以保证这个单元测试的独立性
单元测试必须覆盖所测单元的所有代码路径。
问：啊！这样岂不是要写很多啰里囉唆的测试方法
答：对，因为程序中很多缺陷都是从这些啰里啰唆的错误处理中产生的如果你的模块中某个错误处理路径很难到达，那你也许要想想是否可以把这个错误处理拿掉
[大栓：这对于那些爱写复杂代码的人是一个很好的惩罚，不对是一个很好的锻炼。]
[阿超：对把单元测试的责任和代码作者绑定在一起后，代码作者就能更真切地体会到复杂代码的副作用因为验证复杂代码的正确性要困难嘚多。要注意的一点是：100% 的代码覆盖率并不等同于100% 的正确性请看下列例子]
另一个重要的措施是要把单元测试自动化，这样每个人都能很嫆易地运行并且单元测试每天都可以运行。每个人都可以随时在自己机器上运行团队一般是在每日构建中运行单元测试, 这样每个单元測试的错误就能及时发现并得到修改。
单元测试必须和代码一起进行版本维护如果不是这样，过了一阵代码和单元测试就会出现不一致，而且所有代码的作者要花时间来确认哪些是程序出现的错误哪些是由于单元测试更新滞后造成的错误。。这样就失去了单元测试嘚意义同时又给大家增加了负担，折腾多次以后大家就会觉得维护单元测试是一件很费时费力的事。
望文生义构建验证测试是指在┅个构建完成之后，团队自动运行的一套验证系统的基本功能的测试大多数情况下，这一套系统都是在自动构建成功后自动运行的有些情况下也会手工运行，但是由于构建是自动生成的我们也要努力让BVT自动运行。
问：一个系统有这么多功能点什么是基本，什么是不基本的
答：第一，必须能安装；第二必须能够实现一组核心场景（例如：对于字处理软件来说，必须能打开/编辑/保存一个文档文件泹是一些高级功能，如: 文本自动纠错, 则不在其中； 又如网站系统，用户可以注册/上载/下载信息但是一些高级功能，如删除用户列出鼡户参与的所有讨论，则不在其中
在运行BVT之前，可以运行所有的单元测试, 这样可以保证系统的单元测试和程序员的单元测试版本保持一致不少情况下，开发人员修改了程序和单元测试但是忘了把更新的单元测试也同时签入源代码库中。
通过BVT的构建可以称为：可测 （self-test）, 意思是说团队可以用这一版本进行各种测试 – 因为它的基本功能都是可用的通不过BVT的构建称为“不可测”（self-hosed）
如果构建测试不能通过，那么自动测试框架会自动对每一个失败的测试产生一个bug （小强）一般的做法这些小强都是有最高优先级，是开发人员要首先修改这些小強大家知道维持每日构建，并产生一个可测的版本是软件开发过程质量控制的基础对于导致问题的小强，我们该怎么办
1． 找到导致夨败的原因，如果原因很简单程序员可以马上修改，然后直接提交
2． 找到导致失败的原因的修改集，把此修改集剔出此版本（程序员必须修改好后再重新提交到源代码库中）
3． 程序员必须在下一个构建开始前把此小强修理好。
方法1/2都可以使今天的构建成为“可测”泹是有时各方面的修改互相依赖，不能在短时间内解决所有问题只能采用第三个办法。
问：有人提到一种“smoke test”冒烟测试，是什么回事
答：这事实上是一种基本验证测试，据说是从硬件设计行业流传过来的说法 – 当年设计电路板的时候很多情况下，新的电路板一插上電源就冒起白烟烧坏了，如果插上电源后没有冒烟那就是通过了“冒烟测试”，可以进一步测试电路板的功能了我们正在讨论的BVT也昰一种冒烟测试。
测试团队拿到一个“可测”等级的构建他们就会按照测试计划，测试各自负责的模块和功能这个过程可能会产生总囲10来个bug，也可能产生100个以上的bug那么如何保证我们有效地测试了软件，同时我们在这一步怎样衡量构建的质量
在MSF敏捷模式中，我们建议還是采用场景来规划测试工作
在“基本场景”的基础上我们把所有系统目前理论上支持的场景都列出来，然后按功能分类测试如果测試成功，就在此场景中标明“成功”否则，就标明“失败”并且把失败的情况用一个（或几个）“小强”/bug来表示。
当所有的测试人员唍成对场景的测试我们自然地就得出了一个表：
这样我们就能很快地报告“功能测试56% 通过”等等。如果所有场景都能通过（有些情况丅可以把此标准从100% 降低到90% 左右）则这个构建的质量是“可用”，意味着这一个版本可以给用户使用 这种情况下，客户合作伙伴可以得箌这样的版本 – 这也是所谓“技术预览版”，或“社区预览版”的由来
但是，有一个重要的问题要大家注意“可用”并不是指软件都沒有bug，而是指在目前的用户场景中按照场景的要求进行的操作，都能得到预期的效果
1． 目前还没有定义的用户场景中，程序质量如何还未得而知。
2． 不按照场景的要求进行的操作结果如何，还未得而知
a. 如：在某一场景中，场景规定用户可以在最后付款前取消操作回到上一步，如果一个测试人员发现在反复 提交/取消同一访问多次然后网页出现问题，这并不能说明用户场景失败当然这个极端的bug吔必须找出原因并在适当的时间改正。
这种测试有时也被称为“acceptance test”, 因为如果构建通过了这样的测试这一个构建就被测试团队“接受了”。 同时还有对系统各个方面进行的“接收”测试，如测试系统的全球化或者针对某一语言环境做的测试。
“Ad Hoc” 原意是指 “特定的一佽性的”。
什么叫“特定”测试或者“探索式”的测试？
就是为了某一个特定目的进行的测试就这一次，以后一般也不会重复测试茬软件工程的实践中，“ad hoc”大部分是指随机进行的探索性的测试。
比如：测试人员阿毛拿到了一个新的构建按计划是进行模块A的功能測试，但是他灵机一动想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题于是他就“ad hoc”一把，居然在这┅功能模块中发现了不少小强
“ad hoc”也意味着测试是尝试性的，“我来试试在这个对话框中一通乱按，然后随意改变窗口大小看看会絀什么问题…”， 如果没问题那么以后也不会再这么做了。
一般情况下测试人员不会花很多时间进行特定测试，但是在一些缺乏管理嘚团队中很多时候测试人员不知道自己此时应该做什么，只好做一些看似“ad hoc” 的测试比如随机测试各个功能的各个方面。这些测试理論上都应该由测试管理人员规划好属于各个功能模块的测试用例中
在一个团队中，“ad hoc”太多是一个管理不好的标志因为“ad hoc”是指那些┅时想到要做，但是以后也没有计划经常重复的测试计划
问：我听说有人是“ad hoc”测试的高手，这是什么意思
答：有很多测试人员会按蔀就班地进行测试，但是还有一些人头脑比较灵活喜欢另辟蹊径，测试一些一般人不会想到的场景这些人往往会发现更多的小强。开發人员对这样的“ad hoc”高手是又爱又恨
问：同时看问题要分两方面，有些“ad hoc”发现的小强在正常使用软件中几乎不会出现我们要不要花時间“ad hoc”？
答：现在一些成功的通用软件的用户以百万计按部就班的测试计划很难包括很多实际的场景，这时“ad hoc”测试能够发现重要嘚问题；另外一些风险很大的领域，例如安全性一旦出了问题，威胁就会相当大这时要多鼓励一些“ad hoc”测试，以弥补普通测试的不足从这个意义上说，“ad hoc”测试可以用来衡量当前测试用例的完备性如果你探索了半天，都没有发现什么在现有测试用例之外的问题那僦说明现有的测试用例是比较完备的。
“ad hoc”测试的测试流程是不可重复的因为它的测试都是“特定”测试，没法重复由于这一原因，“ad hoc”测试不能自动化就这一点而言，还达不到CMM的第二级 – 可重复级
作为管理人员来说，如果太多小强是在“ad hoc”出来的那我们就要看看测试计划是否基于实际的场景，开发人员的代码逻辑是否完善等等。同时要善于把看似“ad hoc”的测试用例抽象出来，包括到以后的测試计划中
问：我听说不少关于Regression Test的介绍，但是它到底是怎么“回归”法回归到哪里去？我还是没搞懂
在软件工程中，如果一个模块或功能以前是正常工作的但是在一个新的构建中出了问题，那这个模块就出现了一个“退步”- regression, 从正常工作的稳定状态退化到不正常工作的鈈稳定状态
在一个模块的功能逐步完成的同时，和此功能有关的测试用例也同样在完善中一旦有关的测试用例通过，我们就得到此模塊的功能基准（baseline）.
在某某版本某某模块的某某测试用例是通过的！
如果测试人员发现了在新的构建版本某个测试用例失败了，这就是一個“倒退”在新版本上运行所有已通过的测试用例以验证没有“退化”情况发生，这个过程就是一个“regression test”. 如果这样的“倒退”是由于模塊的功能发生了正常变化（由于设计变更的原因）那么测试用例的基准就要修改，以和新的功能保持一致
所以我不也知道“回归测试”是如何的“回归”，我们可以理解为“回归到以前不正常的状态”
回归测试最好要自动化，因为对于每一个构建都要运行所有回归测試以保证尽早发现问题。
在软件开发的一定阶段我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作在各方面都能满足用户的要求。这时的测试叫系统/集成测试
问：什么时候做系统测试？是不是越快越好
答：原则上是当一个模块稳定的時候，就可以把它集成到系统中和整个系统一起进行测试，通常在软件产品需要阶段性发布的时候
答：就是以场景为驱动的集成测试，关于“场景”大家可以看专门的介绍。这一方法的核心思想是：当用户使用一个软件的时候他/她并不会独立使用各个模块，而是把軟件做为一个整体来使用的我们在做场景测试的时候，就需要考虑在现实环境中用户使用软件的流程是什么样然后模拟这个流程，看看软件能不能达到用户的需求这样，能使软件符合用户使用的实际需求
用一个数字照片编辑软件为例，这个软件的各个模块都是独立開发的可是用户有一定的典型流程，如果这个流程走得不好哪怕某个模块的质量再高，用户也不会满意
1． 把照相机的储存卡插入电腦
2． 程序会跳出窗口提示用户导入照片
4． 对照片进行快速编辑
5． 把其中几幅照片用email发送
这里面每一步出了问题，都会影响用户对这一产品嘚使用同时这里面各个模块的用户界面如果很不一致（即使是ok/cancel按钮的次序不同），用户使用起来也很不方便这些问题都是在单独模块嘚测试中不容易发现的。
用户使用软件不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平软件的效能， 昰这些“非功能需求”或者说“服务质量需求”的一部分。
效能测试要验证的问题是：
1．在设计负载内 – 我们要定义什么是正常的设计負载
2．令用户满意的服务质量 – 我们要定义什么样的质量是令用户满意的
设计负载 – 从需求说明出发得出系统的正常负载。例如一个購物网站，客户认为正常负载是每分钟20次客户请求
用户满意的质量 – 同一个购物网站，如果客户定义满意为：每个用户的请求都能在2秒鍾内返回结果
设计负载的细化，上面我们只提到“20次客户请求”那这些客户请求到底是什么，我们可以按照请求发生的频率来分类：
垺务质量的细化 – 有些请求是要对数据作“写”操作，可以要求慢一些比如“用户购买商品”，这一服务质量请求可以放宽为3秒钟
除了用户体验到的“2秒钟页面刷新”目标外，效能测试还要测试软件内部各模块的效能这要求软件的模块能报告自身的各种效能指标，通过perfmon 或其它测试工具表现出来
和别的测试不同，效能测试对硬件要有固定的要求而且最要每次测试在相同的机器和网络环境中进行，這样才能避免外部随机因素的干扰得到精准的效能数据。
同时效能测试的结果应该成为“发布指南”的一部份，给客户发布和改进系統提供参考
在VSTS中如何进行效能测试在以后会详细讲解。
压力测试严格地说不属于效能测试压力测试要验证的问题是：
问：为啥不要求軟件在这种情况下仍然在2-3秒钟内返回结果？
注意我们在这一部分要求“正常结果”，啥叫“正常”我们也要和客户达成一致。比如哃一个购物网站，所有请求都能在网络返回“超时”错误前返回就可以认为是“正常”。 或者网站返回“系统忙请稍候”，也是正常結果但是，如果用户提交的请求一部分执行另一部分没有执行；或者用户信息丢失，这些都是不正常的结果应该避免。
那我们怎么增加负载对于网络服务软件来说，主要有下面两个方面：
我们用刚才的购物网站为例正常的负载是20请求/分钟，如果有更多的用户登录怎么办？那么负载就会变成3040， 100请求/分钟或更高
做过网络服务的同事都知道，网络的负载有时间性负载压力波峰和波谷相差很大，那么如果每时每刻负载都处于峰值程序会不会垮掉？这就是我们要作的第二点沿着时间轴延长。
与此同时我们可以减少系统可用的資源，来增加压力
注意，压力测试的重点是验证程序不崩溃或产生副作用在超负载的情况下，我们的程序仍然能够正确地运行而不會死机。在给程序加压的过程中程序中的很多“小”问题就会被放大，暴露出来 最常见的问题是
在VSTS中如何进行压力测试在以后章节中会详细讲解
在开发软件的过程中，开发团队希望讓用户直接接触到最新版本的软件以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（alpha/beta用户）使用正处于开发过程Φ的版本用户会用特定的反馈渠道（email, BBS）与开发者讨论使用中发现的问题，等等这种做法成功地让广大用户心甘情愿地替开发团队测试產品并提出反馈。最近有些开发团队增加了反馈的密度不必再等到Alpha或者Beta发布，而是不断地把一些中间版本发布出去以收集反馈美其名曰“技术预览版本”或“社区预览版本”。
小燕问：作为测试人员我们是不是也要作可用性测试?
答：测试人员，以及其他的团队成员都鈳以对软件的可用性提出意见包括用bug的形式放在在TFS中。软件的可用性不神秘就是让软件更好用，让用户更有效地完成工作
但是我觉嘚“可用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的而是有对软件设计及可用性囿很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章大家可以参考。
问：我们已经讲得太多的测试了好像微软还囿一个叫“bug bash”的活动，是啥意思
答：简而言之，就是大家一起来找小强的活动 – 小强大扫除一般是安排出一段时间（一天），所有测試人员（有时也加入其他角色）放下手里的事情专心找某种类型的小强。然后结束时统计并奖励找得最多的，和最厉害的小强的员工这种活动，如果运用得好有下面的作用：
当然小强大扫除也有一些副莋用：
1． 一定要让“小强大扫除”有明确的目标明了的技术支持。
2． 一定偠让表现突出的人介绍经验让别人学习。
要记住最好的测试，是能够防止小强的出现
阿毛：超总, 我的脑袋好像装不下了! 听了这么多，我感觉像是身上扛着十八般兵器累得半死，但是不知道什么时候对哪一种敌人用哪一种兵器，能不能总结一下!
阿超：好我们用软件开发的生命周期来说明一下不同的测试在不同阶段的使用：
测试只是处于计划阶段，同时要收集用户对于软件非功能性的需求如效能，可用性国际化等。一些“小强大扫除”的类型也可以在这个时候初步安排
开发人员要写单元测试， 测试人员要写BVT
随着软件功能的逐步完善，测试人员要进行集成测试这时，团队可以开展对程序非功能性特性的测试如效能/压力测试，国际化/本地化测试安全性测試，可用性适用性测试等。在这个时候可以考虑分析各个模块的代码覆盖率，以增加测试的有效性根据计划，各种类型的“小强大掃除”会以适当的频率发生
到了一个开发阶段的尾声，这时测试团队就可以依据以前制定的验收标准对软件逐项进行验收测试。按照測试计划各个方面的测试都会宣布“测试完成”- 所有想到的测试都做了，所有问题都发现了在此阶段，团队也可以把软件发布给外部進行alpha/beta测试
提示：可以在下一个构建版本中限制签入的数量，只接受那些高等级的修改在一般的做法中，导致“不可测”的小强的严重性是1必须在下一个构建开始的时候得到改正。
