测试英语短语
- 格式：doc
- 大小：38.00 KB
- 文档页数：5
软件测试常用单词：1．静态测试：Non-Execution-Based Testing或Static testing 代码走查：Walkthrough代码审查：Code Inspection技术评审：Review2．动态测试：Execution-Based Testing3．白盒测试：White-Box Testing4．黑盒测试：Black-Box Testing5．灰盒测试：Gray-Box Testing6．软件质量保证SQA：Software Quality Assurance7．软件开发生命周期：Software Development Life Cycle 8．冒烟测试：Smoke Test9．回归测试：Regression Test10．功能测试：Function Testing11．性能测试：Performance Testing12．压力测试：Stress Testing13．负载测试：Volume Testing14．易用性测试：Usability Testing15．安装测试：Installation Testing16．界面测试：UI Testing17．配置测试：Configuration Testing18．文档测试：Documentation Testing19．兼容性测试：Compatibility Testing20．安全性测试：Security Testing21．恢复测试：Recovery Testing22．单元测试：Unit Test23．集成测试：Integration Test24．系统测试：System Test25．验收测试：Acceptance Test26．测试计划应包括：测试对象：The Test Objectives,测试范围：The Test Scope,测试策略：The Test Strategy测试方法：The Test Approach,测试过程：The test procedures,测试环境：The Test Environment,测试完成标准：The test Completion criteria测试用例：The Test Cases测试进度表：The Test Schedules风险：RisksEtc27．主测试计划：a master test plan28．需求规格说明书：The Test Specifications29．需求分析阶段：The Requirements Phase30．接口：Interface31．最终用户：The End User31．正式的测试环境：Formal Test Environment32．确认需求：Verifying The Requirements33．有分歧的需求：Ambiguous Requirements34．运行和维护：Operation and Maintenance.35．可复用性：Reusability36．可靠性：Reliability/Availability37．电机电子工程师协会IEEE：The Institute of Electrical and Electronics Engineers) 38．要从以下几方面测试软件：正确性：Correctness实用性：Utility性能：Performance健壮性：Robustness可靠性：Reliability关于Bugzilla：1．Bug按严重程度（Severity）分为：Blocker，阻碍开发和/或测试工作Critical，死机，丢失数据，内存溢出Major，较大的功能缺陷Normal，普通的功能缺陷Minor，较轻的功能缺陷Trivial，产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等Enhancement，建议或意见2．Bug按报告状态分类（Status）待确认的（Unconfirmed）新提交的（New）已分配的（Assigned）问题未解决的（Reopened）待返测的（Resolved）待归档的（Verified）已归档的（Closed）3．Bug处理意见（Resolution）已修改的（Fixed）不是问题（Invalid）无法修改（Wontfix）以后版本解决（Later）保留（Remind）重复（Duplicate）无法重现（Worksforme）Testing activityTesting activityTesting is an integral componentυof the software processTesting is a critical element of softwareυquality assuranceTesting is an activity that must be carried outυthroughout the software develop ment life cycleSoftware Testing Principles:All tests should be traceable to customer requirements.Tests should be planned long before testing beginsThe Pareto principle applies to software testing. (80/20 rule)Testing should begin “in the small” and progress toward testing “in the large.”Exhaustive testing is not possible.To be most effective, testing should be conducted by an independent third party.Attributes of A “Good” TestA good test has a highυprobability of finding an error.A good test is not redundant.υAυgood test should be neither too simple nor too complex.υ Else?What Should Be Tested?CorrectnessUtilityPerformanceRobustnessReliabilityCorrectnessThe extent to which a program satisfies its specification and fulfills the customer’s mission objectives.If input that satisfies the input specifications is provided and the product is given al l the resources it needs, then the product is correct if the output satisfies the outp ut specification.If a product satisfies its specification, then this product is correct.Questions:Suppose a product has been tested successfully against a broad variety of test dat a. Does this mean that the product is acceptable?UTILITYUtility is the extent to which a user’s needs are met when a correct product is use d under condition permitted by its specifications.It focus on how easy the product is to use, whether the product performs useful fu nctions, and whether the product is cost effective compared to competing products.If the product is not cost effective, there is no point in buying it.And unless the product is easy to use, it will not be used at all or it will be used incorrectly.Therefore, when considering buying an existing product, the utility of the product sh ould be tested first; and if the product fails on that score, testing should stop.PerformanceIt is the extent to which the product meets its constraints with regard to response t ime or space requirements.Performance is measured by processing speed, response time, resource consumpti on, throughput and efficiency.Performance: For example, a nuclear reactor control system may have to sample t he temperature of the core and process the data every 10th of a second. If the sy stem is not fast enough to be able to handle interrupts from the temperature senso r every 10th of a second, then data will be lost and there is no way of ever recov ering the data; the next time that the system receives temperature data, they will b e the current temperature, not the reading that was missed. If the reactor is on the point of a meltdown, then it is critical that all relevant information be both receive d and processed as laid down in the specifications.With all real-time system, the performance must meet every time constraint listed in the specifications.RobustnessRobustness essentially is aυfunction of a number of factors, such as the range of operating conditions, the possibility of unacceptable results with valid input, and the acceptability of effects when the product is given invalid input.A product with a wideυrange of permissible operating condition is more robust than a product that is more restrictive.It is difficult to come up with a preciseυdefinition…A robust product should not yield unacceptable results whenυthe input satisfies its specifications.υFor example, when theυtester gives a system (or program) with a invalid data, the system responds with a message such as “Incorrect data, try again”, it is mor e robust than a system that crashes whenever the data deviate even slightly from what is required.υReliabilityIf a program repeatedly and frequentlyυfails to perform, it matters little whether other software quality factors are acceptable.Software Reliability is defined in statistical terms as “theυprobability of failure-fr ee operation of a computer program in a specified environment for a specified tim e.”It is necessary to know how often theυproduct fails. (MTBF)When a product fails, an important issue is howυlong it takes, on average , to repair it. (MTTR)Measure of Reliability:υ MTBF = MTTF + MTTRMTBF: mean-time-between-failureυMTTF:υmean-time-to-failureMTTR: mean-time-to-repairυυSoftwareυavailability is the probability that a program is operating according to requirements at a given point in time.Measure of Reliability:υυ MTBF = MTTF + MTTRMeasure of Availability:υAvailabilityυ= [MTTF/(MTTF + MTTR)] * 100%υHow can it be know when to stop testing?This can be difficult to determine. Many modern software applications are so compl ex, and run in such an interdependent environment, that complete testing can neve r be done. Common factors in deciding when to stop are:Deadlines (release deadlines, testing deadlines, etc.)Test budget depletedTest cases completed with certain percentage passedCoverage of code/functionality/requirements reaches a specified pointBug rate falls below a certain levelWhat if there isn’t enough time for thorough testing?Use risk analysis to determine where testing should be focused. Risk analysis is a ppropriate to most software development projects. This requires judgment skills, co mmon sense, and experience. Considerations can include:Which functionality is most important to the project's intended purpose?Which functionality is most visible to the user?Which functionality has the largest safety/financial impact?Which aspects of similar/related previous projects had large maintenance expenses? Which parts of the code are most complex, and thus most subject to errors?。
