关于软件测试

因为测试时从来不希望检测被测系统所有可能的输入、路径和状态，那么应该选择什么？什么时候应该停止测试？什么时候应该暂停测试？怎样编写一个测试包，它可以检测足够多的消息和状态的组合来说明没有失败的操作，但是从实用性来说它又足够的小？
测试提出了许多基本的但却令人困惑的难题，带着这些问题，参加了几次实用软件测试培训。
由于软件的复杂导致了测试的复杂，所以不能指望培训能给我们很多工作中的实际指导。偏重理论是肯定的，但并非没有意义，虽然理论同样可以从相关的文献资料上得到。
有一些心得，零零散散，记录下来，与大家交流。

一，软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以关闭。仔细思考后，我觉得此目标包含三个含义。
1．软件测试员的基本目标是发现软件缺陷。
这似乎是个不言而喻的事实，但有必要再次强调。因为有时开发小组要测试员只是为了证实软件可以运行，而不是找缺陷。在这种情况下，测试人员也就缺乏不懈努力发现缺陷的探索精神和热情。所以做好测试的首要条件是明确软件测试员的基本目标是发现软件缺陷。
2．软件测试员追求的是尽可能早地找出软件缺陷。
因为软件的修复费用，随着时间的推移，将数十倍的增长，所以软件测试员应尽可能早地找出软件缺陷。对于大型的软件，在软件开发的同时，就应该有紧随其后的测试，如果等到产品已经开发完毕才开始测试，非常有可能引起大量耗时费力的返工。而如何尽可能早的找出缺陷？理论上有一些测试方法：静态黑盒测试、动态黑盒测试、静态白盒测试、动态白盒测试；配置测试、兼容性测试、易用性测试……，怎样才能有效的用这些方法尽早的发现软件缺陷，需要在工作实践中不断的摸索、总结，不断的提高测试能力。针对公司的情况，如果软件的规模不是很大，开发中的测试工作可能由开发人员完成比较合适。
3．软件测试人员必需确保找出的软件缺陷得以关闭。
并不是每个软件缺陷都有必要修复的。可能是由于没有足够的时间、不算作真正的软件缺陷、修复的风险太大等原因，产品开发小组决定对一些软件缺陷不作修复。但是，测试人员必需确保找出的软件缺陷得以关闭，也就是说一旦登记了软件缺陷，就要跟踪其生命周期，监视其状态，提供必要的信息确保其得到修复和关闭。

二，关于Testware。
有个很简洁明了的定义，software development engineers produce software, software test engineers produce testware. 那么testware包含哪些内容呢？test strategy, test plan, test specifications, test procedures, test cases, test reports, test data, test scripts, defects data等等。同软件一样，testware也需要很好地维护。例如，由于修复缺陷改变了软件的接口，那么case和自动测试脚本script都要做相应的修改。

三，对产品说明书的测试。
软件的产品功能说明书对产品最终需要实现的功能作了描述。这些功能是最终确定的需要满足的客户需求，也包括软件必须具备的能力。在规范的软件开发流程中，产品功能说明书应在确定用户需求后，进行系统概要设计前确定。
至于为什么要进行产品说明书的测试，统计资料表明，很多软件的缺陷都是因为产品功能说明书不够全面，经常更改造成的；另外，只有详细的阅读了产品功能说明书，确认产品需要实现的功能，才能拟定切实可行的测试方案。
其方法，具体地说有以下几种。
1．参照需求说明，检查产品功能说明书描述的产品将要实现的功能是否已经完整、准确、一致、合理的描述了产品的功能，并确保这些功能是可测试的。
2．研究产品说明书是否符合现有的软件设计开发的标准或规范。
3．研究同类软件，预测产品的最终结果。
可是如果应用到实际的开发流程中，又有着一定的困难。因为很难做到让软件测试人员在项目的初期就参与项目，一般要等到软件的雏形出来后才会让软件测试人员着手进行测试。即便是在初期测试人员参与项目，也只是根据产品说明书和设计计划制定测试计划。测试人员没有被赋予责任去检查产品说明书。

四，经济的测试。
测试是一项复杂的工作。因此要考虑其效率。经济的测试有几个原则。
1． 如果一个case（X）依赖另一个（Y），如果Y失败，那么X可以不要测试。
2． 针对一个子集，如果一个输入导致了失败，那么剩下的输入可以不要测试。
3． 针对一个case，如果一个测试子集产生了失败，那么其他的子集可以不要测试。
由此，联想到一个实际问题。开发人员一次送测，按流程，应进行一轮全面的测试。但如果在测试初期发现了缺陷，此轮测试是否要继续？不继续，则此轮测试不完整，无法产出测试报告。继续到完全测试，如果发现的缺陷是严重的必须解决的缺陷，则后面的测试是不经济的，因为此缺陷修复后仍要进行全面的测试。
按照测试的原则，发现缺陷要及时地反馈给开发人员，以便及时了解软件状态。但在实际操作中，开发人员得到反馈后常常随即给出一个修复版，然后再一轮测试。造成的情况是，到项目结束，发现多少个缺陷，往往就经过多少轮测试，每一轮测试仅仅是验证对一个缺陷的修复。
所以我觉得，对于什么时候暂停测试，是否需要暂停，开发人员什么时候送测新的修复版本，应该有一个良好的控制。

五，自动测试
我们是用Rational Robot编写自动测试脚本进行自动测试。主要用与一些AP的UI测试。由于编写SQA Basic代价较高，所以应用于稍具复杂度的程序或需多轮回归测试的项目是比较经济的，如果是简单的UI，或不需进行多轮回归测试的项目，就要比较编写脚本的投入和实施自动测试的经济了。
如果多轮回归测试间程序变化比较多，改写脚本也是负担很重的工作。

以上是一点点心得，零散写下。