51Testing第二十四期软件测试沙龙（杭州站）提问回复
首先综合回答一下朋友们提到的问题，随后对具体问题一一进行解答。容量是建设系统（尤其是大型而又复杂的系统）时遇到的一个问题，为了解决这个问题，人们提出了容量的规划问题；目的是分析、解决系统面对的容量问题。
容量规划不是一个独立的问题，是一个系统工程。有效的容量规划的完成有赖于设计、开发、质量控制、运营、维护一个系统的各个部门的支持；在这些部门的支持下，可以有专门的人员进行系统的容量规划。
系统容量是系统质量的一个重要参数。质量是制造出来的，而不是测试出来的；质量的提高最终有赖于开发部门对系统的重构、优化。质量控制部门会从系统内部和系统外部两个方面入手，与开发部门一起，创建高质量的系统。
开发部门为了解决容量问题而进行的努力的驱动力来自于两个，一个来自于其自身，另一个是来自于外部。质量控制部门会从自己的角度，帮助开发部门解决系统容量问题。对于51 Testing 的网友来说，我们需要了解到容量规划远不只是质量控制部门的职责，尽管容量规划和性能测试联系紧密；容量规划需要高层的重视，并且在团队建设上给予支持。
容易进行容量规划是良好组织产生的良好系统的副产品。
另外，从投入产出比上考虑，保证系统在大容量时仍然可以顺利运行，需要相当的成本；我们需要考虑做到多么好的程度就已经可以满足市场、业务上的需求，而不是纯粹地站在纯技术的角度来看待这个问题。
在容量规划的角度，可以把系统目前的状态分成如下五个级别：
第一，原始级：没有进行度量，容量不可预测；俗称“听天由命”
第二，入门级：系统从外部进行初步度量（例如Load Runner等第三方工具）；但是大并发状态下的系统行为难以预测，事实上难以预测的最终原因是没有深入到系统的内部。
第三，进阶级：系统从内部可度量；特殊业务量下可以保证正常运行；即便发生异常也能够较准地定位原因
第四，提高级：系统进行了标准化、成熟化，具备自己的测量标准参数；积累了异常处理经验。自定义的系统标准参数的重要来源，是此前定位到的产生容量问题的原因。
第五，成熟级：系统行为可以被较好的监控、预测；具备可靠的规划、预警能力。
现在一个重要的概念是，有没有可能一次就可以建设出成熟级的系统？理论上有可能，现实中很困难。成熟的系统是时间沉淀的结果；软件开发容易，修改困难；设计容易，重构困难。
不过，如果我们从最开始做设计的时候，就认真分析过系统的容量，从而在设计数据库表格、划分系统模块等问题上为此进行过优化，此后再面对容量问题时就会变得容易。
一、容量规划工具：
1、何种工具，适合的最佳规划方式，还是容量规划有通用性？
工具是经验的沉淀，适用于成熟的产品。
对于项目开发，需要对所在的项目进行具体分析，主要关注CPU、内存、磁盘、网络等使用情况；当项目开发不断提炼，形成产品之后，可以提炼出很多有用的工具。
2、桩模块测试如何进行，在测此方面内容时，如何将某一模块作为测试项？
这个问题我不了解。
3、关于前段时间发现的SQL注入漏减是如何解决的？有什么好的方法可以避免？测试的时候使用什么方法或工具？
SQL注入漏洞属于开发人员的失误。需要对用户的输入进行判断，可以避免SQL注入攻击。
4、请分享一些在软件测试过程中对于风险评估需要考虑的方面和评估的办法？（请结合某一实例具体回答）
我没有做过类似的工作。
5、测试工具推进，在系统上线前，是如何规划的？
这句话的意思似乎是说，质量保证部门，在系统上线前如何使用各种工具保证系统的质量。
重要的是质量保证部门在项目的不同阶段需要做些什么；为了更好地完成任务，可以采用辅助工具。工具是思想的产物；工具是经验的沉淀；工具不是万能的；工具是人造的；工具是有待改进的。所以，不必迷信工具。
系统上线前，可以分为：需求、设计、开发、集成等过程。每一个过程的进行中，都有质量保证部门的跟进。需求阶段QA步步跟进，并对需要文档进行评审。设计阶段重要决定都经过QA，涉及结果也经过评审。开发阶段QA分两部分，一部分进行从系统内部着手，理想状态下每一行代码都经过了检查，没有通过检查的代码无法签入；另一部分从系统外部入手，测试每一个系统功能。集成阶段QA主要从系统外部进行测试。
之所以上面的步骤中没有测试，是因为测试已经融入到每一个步骤中了。
6、容量规划中测试部门和开发部门那个做更合适？
这是一个非常好的问题。
容量规划是个横向的问题，需要多个部门的合作才能够完成。容量规划的最终完成，例如真正的数据采集，由开发部门完成；对于系统的内部、外部度量，需要测试部门完成；对于用户行为分析、系统关键参数的监控等需要其他部门完成。
7、哪种工具可以方便的建立用户访问模型（获取访问数据，生成访问模型）？
我没有使用过相关的第三方的工具。
8、软件的测试方法，测试环境，以及如何开展测试？
测试及质量保证是根据产品、项目的特点进行的。
方法主要分为两方面：第一，从系统外部测试，例如ALAC等；第二，从系统内部测试，如文档评审、代码检查等。
环境可以分为三个：开发环境、QA环境、发布环境；外部测试在第一个环境中进行，内部测试在第二个环境中进行；第三个环境全真模拟客户的生产环境。
二、容量规划设计
1、如何评价一个好的容量规划？是合理还是不合理？
评价容量规划结果的实际方法是看上线后有没有Big Surprise。没出问题，就是最好的结果。
2、在何时算为好?比如在软件需求分心前？
产品和项目各有不同。
产品开发一定在需求、设计阶段就已经开始，一直持续到产品生命周期的最后阶段。
项目开发主要看项目需求和项目组的能力。大型项目在一开始就需要做充分的规划，因为其要求更为苛刻；中小型项目可以在成型后再进行具体分析。
3、需求不明确的情况下，如何进行测试用例的设计？
有代码的地方就需要测试；有文档的地方就需要评审，无论是正式还是非正式的。
快速原型、Scrum等方法可以在用户需求不明确的情况下帮助用户不断确定需求。
内部测试针对代码和开发文档，可以根据开发部门的节奏、和项目进展逐步进行。
外部测试需要系统初步成型之后再开始。
4、系统的缺陷如何进行预估？
这个我不知道。
5、软件测试与SQA这样有效结合高效的保证软件质量？
SQA在成熟的组织中可以很好的保证软件开发的质量。
QA和测试的区别在于，QA关注过程，QA相信，如果执行了正确的执行过程，就可以有很好的结果。测试关注结果，测试能够通过，就已经证明结果是好的。
由于软件产品或项目“金玉其外、败絮其中”的情况屡见不鲜，SQA能够更好的解决这个问题。
6、作为一个测试人员有哪些方面的书必须读的？
质量保证人员分为两类：一类关注系统内部，另一类关注系统外部。第一类由资深的开发人员组成；第二类可以没有开发背景。
书很多，必须读的谈不上。没有什么事情是必须要做的；事变时移，需要具体问题具体分析。
现在自己书架上相关的书籍有四本，仅供参考：
人月神话，The Mythical Man-Month，作者Frederick P. Brooks Jr.
个体CMM指南，The People Capability Maturity Model，作者Bill Curtis等
PSP软件工程师的自我改进过程, PSP: A Self-Improvement Process for Software Engineers，作者Watts S. Humphrey
软件测试，Software Testing, 作者Ron Patton
7、怎样去做对测试人员的测试？
对测试人员的评价，我没有经验。
8、容量规划是否必须建立在充分的性能测试基础之上？
对照容量规划的五个级别：原始级、入门级、进阶级、提高级、成熟级，性能测试在第二级（入门级）十分有用。第二级能够从外部对系统进行度量；性能测试是第二级的主要方法。
三、容量规划实现与测试
1、容量规划合理性测试方法及注意事项？
容量规划曾经提到了四点：系统需要被调优，系统需具备可扩展性，项目人员需要有容量意识，系统可以被度量。
对照前面关于容量规划的五个级别：原始级、入门级、进阶级、提高级、成熟级，可以评估目前所在的位置，分析需要采取的下一步行动。
2、变更较快、较频繁时，如何更有效的执行测试？
测试分为内部、外部两种。自动化测试用例是系统内部测试的基础；需求和功能规范是系统外部测试的基础。
在需求变更频繁时，开发过程遵循了测试优先的原则时，内部测试可以顺利进行；用户需求被文档化（非正式或正式文档，Wiki等）后，外部测试可以顺利进行。
3、考虑计算用户数的时候还要考虑模块使用频率，长短连接的问题吗？
用户行为模式分析是进行系统规划的基础数据。通常有两种方法：统计和建模。
对于成熟产品，最好采用统计和数据挖掘方法；对于新建项目，可以采用用户群细分等方法进行预估，预估结果很有可能与实际情况相差很大。
不同用户使用系统的情况差别很大，需要考虑用户行为模式对系统压力的不同。
4、SAP自带的测试工具是怎么做测试？SAP有没有好的流程管理？
测试工具采用eCATT（Extended Computer Aided Test Tool）；流程管理采用PIL（Product Innovation Lifecycle）。
5、测试技能的一个大方向是怎样？
职业生涯规划是一个难题，需要专业人员根据每个人的情况进行咨询。
6、容量规划工具中得到的数据该怎样获取？是采用性能测试收集还是监控生产环境数据？
监控真实环境数据是最好的方法。
性能测试是系统上线之前对模拟系统采用的方法，上线之后主要任务是对生产系统的监控。我们的原则是，一旦有了生产系统的监测数据，之前模拟环境就没有价值了。
四、其他
1、
阿里巴巴测试流程、管理工具、测试管理未来发展方向
答：测试流程发展方向：目前由专门的SQA团队负责规划这个领域，未来将在项目项目、需求文档、架构设计文档、编码规范、单元测试规范、测试评审、发布标准等方面深入审计。确保每一个环节的输出物高质量、切实吻合流程。另外，可能也会尝试测试驱动开发
管理工具： 项目管理采用ibm RPM，用例与缺陷管理平台 ：Quanlity center，文档平台conflucense，版本管理工具SVN。
测试管理：目前已经细分为SQA、SCM、QA架构组 、QA业务组。将来还在QA业务组细分测试设计、测试执行的角色。细分更加专业的角色，完善强大的测试用例库、模板库、自动化脚本。
2、
软件测试人员如何进行考核？阿里巴巴是怎么操作的？
答：考核分2层面的，50%价值观+50%业绩。
业绩一般为项目与需求测试结果+项目过程控制+对团队的贡献+工作效率提升。
3、
容量规划思想主要用于ERP相关系统，涉及到服务器，负载等，那么对于其他行业，那些对服务器负载不敏感的应用软件类，有何指导意义呢？或者说容量规划思想如何扩展到其他领域？
答：“ 容量规划思想主要用于ERP相关系统“ 这个我不认同。实际上，中国电信很多BSS/OSS系统都做容量规划。
容量规划本质上更适合，对价格敏感的大型系统，比如服务器采用高端小型机。因为容量规划过程成本非常高昂。
4、
开发人员与测试人员应该如何合作？是开发导向测试，还是测试督促开发？
答：测试人员专业的把每一个测试环节做得最好，用实力与专业赢得开发尊重。并不断引导开发把发现BUG 的时机往前提，从而预防BUG。
测试驱动开发最好。但真要做得相当有挑战，需要强大的自动化测试体系保证，比如建立daily build+daily test环境，让BUG 主动跳出来。
5、
如何把握测试深度？以一个测试经理的角度看是希望测试人员只要从用户角度把功能测遍就够了，还是尽可能地钻研到模块里面更好？
答：本质上是一个成本效益度量的问题。
从短期看测试测得很浅就发布，没有全面系统的性能测试、安全测试等，成本确实很低。但一旦出现严重的质量问题，长远就会影响用户对产品乃至公司的印象，这种打击可能是毁灭性的。
回到现实中来，由于时间与成本关系，仅仅做系统级别的测试而没有单元级别的测试的公司很多，确保没有严重级别高的BUG就发布。但作为测试人员应该明白，这是一种妥协。
6、
在测试时，会听到开发人员说：“你们不需要懂那么多，不需要了解那么细，只要从用户角度来测就可以了。”如何面对这种情况？
答：从目前看，开发普遍对测试存在误解。误以为测试是对项目工时的一个附加。做测试不仅仅要测试自己看到的，更需要测试看不到的冰山之下。比如判断是否有内存泄露、是否有死锁、是否存在不良SQL、是否满足性能需求、是否满足安全需求、扩展性需求、容灾需求等等，这些纯用户角度无法度量。
做测试需要扎得很深才能把深层次的BUG挖掘出来。
[ 本帖最后由 星子 于 2008-7-7 17:46 编辑 ] 很好
页:
[1]
